diff --git a/.azure-pipelines/azure-pipelines.yml b/.azure-pipelines/azure-pipelines.yml index 44f481e3d23..de33c635093 100644 --- a/.azure-pipelines/azure-pipelines.yml +++ b/.azure-pipelines/azure-pipelines.yml @@ -46,7 +46,6 @@ stages: targets: - test: 1 - test: 2 - - test: 3 - stage: Units dependsOn: [] jobs: diff --git a/.azure-pipelines/commands/sanity.sh b/.azure-pipelines/commands/sanity.sh index 78046f65e1a..10c1968c277 100755 --- a/.azure-pipelines/commands/sanity.sh +++ b/.azure-pipelines/commands/sanity.sh @@ -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 diff --git a/.github/BOTMETA.yml b/.github/BOTMETA.yml index d9346a9b933..7000d29d2ee 100644 --- a/.github/BOTMETA.yml +++ b/.github/BOTMETA.yml @@ -59,20 +59,6 @@ files: .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/: diff --git a/MANIFEST.in b/MANIFEST.in index 4d75cf2480e..1dbe2e300cd 100644 --- a/MANIFEST.in +++ b/MANIFEST.in @@ -2,18 +2,11 @@ include COPYING include bin/* include changelogs/CHANGELOG*.rst include changelogs/changelog.yaml -include examples/ansible.cfg -include examples/hosts -include examples/scripts/ConfigureRemotingForAnsible.ps1 -include examples/scripts/upgrade_to_ps3.ps1 -include hacking/build-ansible.py -include hacking/templates/*.j2 include hacking/test-module.py include hacking/update-sanity-requirements.py include licenses/*.txt include requirements.txt recursive-include docs * -recursive-include hacking/build_library *.py recursive-include packaging *.py *.j2 recursive-include test/integration * recursive-include test/sanity *.in *.json *.py *.txt diff --git a/docs/bin/find-plugin-refs.py b/docs/bin/find-plugin-refs.py deleted file mode 100755 index 52946b2ebe7..00000000000 --- a/docs/bin/find-plugin-refs.py +++ /dev/null @@ -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.common.text.converters 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 `", 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 diff --git a/docs/bin/testing_formatter.sh b/docs/bin/testing_formatter.sh deleted file mode 100755 index f3a41e12d41..00000000000 --- a/docs/bin/testing_formatter.sh +++ /dev/null @@ -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 \`. - -.. 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 diff --git a/docs/docsite/.gitignore b/docs/docsite/.gitignore deleted file mode 100644 index 8fade815d19..00000000000 --- a/docs/docsite/.gitignore +++ /dev/null @@ -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 diff --git a/docs/docsite/.nojekyll b/docs/docsite/.nojekyll deleted file mode 100644 index e69de29bb2d..00000000000 diff --git a/docs/docsite/.templates/banner.html b/docs/docsite/.templates/banner.html deleted file mode 100644 index 91b0fcbbf5f..00000000000 --- a/docs/docsite/.templates/banner.html +++ /dev/null @@ -1,69 +0,0 @@ -{% if is_eol %} -{# Creates a banner at the top of the page for EOL versions. #} - -{% else %} - -{% endif %} diff --git a/docs/docsite/.templates/breadcrumbs.html b/docs/docsite/.templates/breadcrumbs.html deleted file mode 100644 index de006f65aa2..00000000000 --- a/docs/docsite/.templates/breadcrumbs.html +++ /dev/null @@ -1,52 +0,0 @@ -{%- extends "!breadcrumbs.html" %} -{%- block breadcrumbs_aside %} -
  • - {%- if hasdoc(pagename) and display_vcs_links %} - {%- if display_github %} - {%- if check_meta and 'github_url' in meta %} - - {{ _('Edit on GitHub') }} - {%- else %} - - {% if check_meta and pagename.endswith(( - '_module', '_become', '_cache', '_callback', - '_connection', '_inventory', '_lookup', - '_shell', '_strategy', '_vars', - )) %} - {# {{ _('Edit on GitHub') }} #} -
    - - {% elif pagename == 'index' %} -
    - - {% elif pagename.startswith('collections/') %} -
    - - {% elif check_meta and pagename.startswith('cli') and meta.get('source', None) %} - {{ _('Edit on GitHub') }} - {% elif (not 'list_of' in pagename) and (not 'category' in pagename) %} - {{ _('Edit on GitHub') }} - {% endif %} - {%- endif %} - {%- elif display_bitbucket %} - {%- if check_meta and 'bitbucket_url' in meta %} - - {{ _('Edit on Bitbucket') }} - {%- else %} - {{ _('Edit on Bitbucket') }} - {%- endif %} - {%- elif display_gitlab %} - {%- if check_meta and 'gitlab_url' in meta %} - - {{ _('Edit on GitLab') }} - {%- else %} - {{ _('Edit on GitLab') }} - {%- endif %} - {%- elif show_source and source_url_prefix %} - {{ _('View page source') }} - {%- elif show_source and has_source and sourcename %} - {{ _('View page source') }} - {%- endif %} - {%- endif %} -
    • -{%- endblock %} diff --git a/docs/docsite/.templates/version_chooser.html b/docs/docsite/.templates/version_chooser.html deleted file mode 100644 index c32a6ba5398..00000000000 --- a/docs/docsite/.templates/version_chooser.html +++ /dev/null @@ -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 %} diff --git a/docs/docsite/Makefile b/docs/docsite/Makefile deleted file mode 100644 index 961f7343cf9..00000000000 --- a/docs/docsite/Makefile +++ /dev/null @@ -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) ./version_helper.py --raw || echo error) -ifeq ($(findstring error,$(VERSION)), error) -$(error "version_helper failed") -endif - -MAJOR_VERSION := $(shell $(PYTHON) ./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) diff --git a/docs/docsite/Makefile.sphinx b/docs/docsite/Makefile.sphinx deleted file mode 100644 index 3bae705c6db..00000000000 --- a/docs/docsite/Makefile.sphinx +++ /dev/null @@ -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) diff --git a/docs/docsite/README.md b/docs/docsite/README.md deleted file mode 100644 index 4ad565eabe2..00000000000 --- a/docs/docsite/README.md +++ /dev/null @@ -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/). diff --git a/docs/docsite/_static/css/core-color-scheme.css b/docs/docsite/_static/css/core-color-scheme.css deleted file mode 100644 index c61c0b1837f..00000000000 --- a/docs/docsite/_static/css/core-color-scheme.css +++ /dev/null @@ -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; -} diff --git a/docs/docsite/ansible_2_9.inv b/docs/docsite/ansible_2_9.inv deleted file mode 100644 index 0f726711324..00000000000 Binary files a/docs/docsite/ansible_2_9.inv and /dev/null differ diff --git a/docs/docsite/ansible_6.inv b/docs/docsite/ansible_6.inv deleted file mode 100644 index a03b2b28a2b..00000000000 Binary files a/docs/docsite/ansible_6.inv and /dev/null differ diff --git a/docs/docsite/ansible_7.inv b/docs/docsite/ansible_7.inv deleted file mode 100644 index 4e9556f0591..00000000000 Binary files a/docs/docsite/ansible_7.inv and /dev/null differ diff --git a/docs/docsite/collection-plugins.yml b/docs/docsite/collection-plugins.yml deleted file mode 100644 index 499274b40b8..00000000000 --- a/docs/docsite/collection-plugins.yml +++ /dev/null @@ -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' diff --git a/docs/docsite/jinja2.inv b/docs/docsite/jinja2.inv deleted file mode 100644 index 37ed7968998..00000000000 Binary files a/docs/docsite/jinja2.inv and /dev/null differ diff --git a/docs/docsite/modules.js b/docs/docsite/modules.js deleted file mode 100644 index 103bc2cadb4..00000000000 --- a/docs/docsite/modules.js +++ /dev/null @@ -1,5 +0,0 @@ -function AnsibleModules($scope) { - $scope.modules = []; - - $scope.orderProp = "module"; -} \ No newline at end of file diff --git a/docs/docsite/python2.inv b/docs/docsite/python2.inv deleted file mode 100644 index 7ea2dc1dac2..00000000000 Binary files a/docs/docsite/python2.inv and /dev/null differ diff --git a/docs/docsite/python3.inv b/docs/docsite/python3.inv deleted file mode 100644 index d7ab8c267d9..00000000000 Binary files a/docs/docsite/python3.inv and /dev/null differ diff --git a/docs/docsite/requirements.txt b/docs/docsite/requirements.txt deleted file mode 100644 index edae31994b9..00000000000 --- a/docs/docsite/requirements.txt +++ /dev/null @@ -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-notfound-page >= 0.6 -sphinx-intl -sphinx-ansible-theme >= 0.10.2 -sphinx -resolvelib diff --git a/docs/docsite/rst/2.10_index.rst b/docs/docsite/rst/2.10_index.rst deleted file mode 100644 index 1ff97d0bae0..00000000000 --- a/docs/docsite/rst/2.10_index.rst +++ /dev/null @@ -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 `_, 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 diff --git a/docs/docsite/rst/404.rst b/docs/docsite/rst/404.rst deleted file mode 100644 index 4a869d22667..00000000000 --- a/docs/docsite/rst/404.rst +++ /dev/null @@ -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. diff --git a/docs/docsite/rst/ansible_index.rst b/docs/docsite/rst/ansible_index.rst deleted file mode 100644 index 079c7cf605e..00000000000 --- a/docs/docsite/rst/ansible_index.rst +++ /dev/null @@ -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 `_, 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 diff --git a/docs/docsite/rst/api/index.rst b/docs/docsite/rst/api/index.rst deleted file mode 100644 index 27afbe42cc3..00000000000 --- a/docs/docsite/rst/api/index.rst +++ /dev/null @@ -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 ` 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 diff --git a/docs/docsite/rst/collections/all_plugins.rst b/docs/docsite/rst/collections/all_plugins.rst deleted file mode 100644 index 35232f7db63..00000000000 --- a/docs/docsite/rst/collections/all_plugins.rst +++ /dev/null @@ -1,11 +0,0 @@ -.. _all_modules_and_plugins: - -Indexes of all modules and plugins ----------------------------------- - -.. toctree:: - :maxdepth: 1 - :caption: Plugin indexes - :glob: - - index_* diff --git a/docs/docsite/rst/collections_guide/collections_downloading.rst b/docs/docsite/rst/collections_guide/collections_downloading.rst deleted file mode 100644 index ab17ce89412..00000000000 --- a/docs/docsite/rst/collections_guide/collections_downloading.rst +++ /dev/null @@ -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 `. 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 \ No newline at end of file diff --git a/docs/docsite/rst/collections_guide/collections_index.rst b/docs/docsite/rst/collections_guide/collections_index.rst deleted file mode 100644 index 464db898b86..00000000000 --- a/docs/docsite/rst/collections_guide/collections_index.rst +++ /dev/null @@ -1,6 +0,0 @@ -.. _index_collections: - -Collections index -================= - -You can find an index of collections at :ref:`list_of_collections`. \ No newline at end of file diff --git a/docs/docsite/rst/collections_guide/collections_installing.rst b/docs/docsite/rst/collections_guide/collections_installing.rst deleted file mode 100644 index 6ee446aae14..00000000000 --- a/docs/docsite/rst/collections_guide/collections_installing.rst +++ /dev/null @@ -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 ` 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 `. - -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 ` 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 \ No newline at end of file diff --git a/docs/docsite/rst/collections_guide/collections_listing.rst b/docs/docsite/rst/collections_guide/collections_listing.rst deleted file mode 100644 index 03cf125127d..00000000000 --- a/docs/docsite/rst/collections_guide/collections_listing.rst +++ /dev/null @@ -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 diff --git a/docs/docsite/rst/collections_guide/collections_using_playbooks.rst b/docs/docsite/rst/collections_guide/collections_using_playbooks.rst deleted file mode 100644 index a7665edfe62..00000000000 --- a/docs/docsite/rst/collections_guide/collections_using_playbooks.rst +++ /dev/null @@ -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. diff --git a/docs/docsite/rst/collections_guide/collections_verifying.rst b/docs/docsite/rst/collections_guide/collections_verifying.rst deleted file mode 100644 index e3f93d43d4c..00000000000 --- a/docs/docsite/rst/collections_guide/collections_verifying.rst +++ /dev/null @@ -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 \ No newline at end of file diff --git a/docs/docsite/rst/collections_guide/index.rst b/docs/docsite/rst/collections_guide/index.rst deleted file mode 100644 index 04182c9e9cb..00000000000 --- a/docs/docsite/rst/collections_guide/index.rst +++ /dev/null @@ -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 `_. - -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 \ No newline at end of file diff --git a/docs/docsite/rst/command_guide/cheatsheet.rst b/docs/docsite/rst/command_guide/cheatsheet.rst deleted file mode 100644 index ee141a51937..00000000000 --- a/docs/docsite/rst/command_guide/cheatsheet.rst +++ /dev/null @@ -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 ` to match the :ref:`pattern `. - - ``-u`` - connects :ref:`over SSH ` as ``my_connection_user``. - - ``-k`` - asks for password which is then provided to SSH authentication. - - ``-f`` - allocates 3 :ref:`forks `. - - ``-T`` - sets a 30-second timeout. - - ``-t`` - runs only tasks marked with the :ref:`tag ` ``my_tag``. - - ``-m`` - loads :ref:`local modules ` from ``/path/to/my/modules``. - - ``-b`` - executes with elevated privileges (uses :ref:`become `). - - ``-K`` - prompts the user for the become password. - -See :ref:`ansible-playbook` for detailed documentation. - diff --git a/docs/docsite/rst/command_guide/command_line_tools.rst b/docs/docsite/rst/command_guide/command_line_tools.rst deleted file mode 100644 index 232cd25982c..00000000000 --- a/docs/docsite/rst/command_guide/command_line_tools.rst +++ /dev/null @@ -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 diff --git a/docs/docsite/rst/command_guide/index.rst b/docs/docsite/rst/command_guide/index.rst deleted file mode 100644 index 299743d30a3..00000000000 --- a/docs/docsite/rst/command_guide/index.rst +++ /dev/null @@ -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 `_. - -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 \ No newline at end of file diff --git a/docs/docsite/rst/command_guide/intro_adhoc.rst b/docs/docsite/rst/command_guide/intro_adhoc.rst deleted file mode 100644 index 2171f292d1e..00000000000 --- a/docs/docsite/rst/command_guide/intro_adhoc.rst +++ /dev/null @@ -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` and :ref:`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`. 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 ` 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 ` 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 `: - -.. 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 `), 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` module in a playbook. - -The :ref:`ansible.builtin.file` 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=" - - $ ansible all -m ansible.builtin.user -a "name=foo state=absent" - -See the :ref:`ansible.builtin.user ` 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 ` module documentation for details. - -Patterns and ad-hoc commands ----------------------------- - -See the :ref:`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 `. - -.. 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 `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/community/advanced_index.rst b/docs/docsite/rst/community/advanced_index.rst deleted file mode 100644 index b07b72ff17a..00000000000 --- a/docs/docsite/rst/community/advanced_index.rst +++ /dev/null @@ -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 diff --git a/docs/docsite/rst/community/code_of_conduct.rst b/docs/docsite/rst/community/code_of_conduct.rst deleted file mode 100644 index 776236a29fe..00000000000 --- a/docs/docsite/rst/community/code_of_conduct.rst +++ /dev/null @@ -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 `_, 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 diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_about.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_about.rst deleted file mode 100644 index d011fdb0642..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_integration_about.rst +++ /dev/null @@ -1,155 +0,0 @@ -.. _collection_integration_tests_about: - -Understanding integration tests -================================= - -.. note:: - - Some collections do not have integration tests. - -Integration tests are functional tests of modules and plugins. -With integration tests, we check if a module or plugin satisfies its functional requirements. Simply put, we check that features work as expected and users get the outcome described in the module or plugin documentation. - -There are :ref:`two kinds of integration tests ` used in collections: - -* integration tests that use Ansible roles -* integration tests that use ``runme.sh``. - -This section focuses on integration tests that use Ansible roles. - -Integration tests check modules with playbooks that invoke those modules. The tests pass standalone parameters and their combinations, check what the module or plugin reports with the :ref:`assert ` module, and the actual state of the system after each task. - -Integration test example -------------------------- - -Let's say we want to test the ``postgresql_user`` module invoked with the ``name`` parameter. We expect that the module will both create a user based on the provided value of the ``name`` parameter and will report that the system state has changed. We cannot rely on only what the module reports. To be sure that the user has been created, we query our database with another module to see if the user exists. - -.. code-block:: yaml - - - name: Create PostgreSQL user and store module's output to the result variable - community.postgresql.postgresql_user: - name: test_user - register: result - - - name: Check the module returns what we expect - assert: - that: - - result is changed - - - name: Check actual system state with another module, in other words, that the user exists - community.postgresql.postgresql_query: - query: SELECT * FROM pg_authid WHERE rolename = 'test_user' - register: query_result - - - name: We expect it returns one row, check it - assert: - that: - - query_result.rowcount == 1 - - -Details about integration tests --------------------------------- - -The basic entity of an Ansible integration test is a ``target``. The target is an :ref:`Ansible role ` stored in the ``tests/integration/targets`` directory of the collection repository. The target role contains everything that is needed to test a module. - -The names of targets contain the module or plugin name that they test. Target names that start with ``setup_`` are usually executed as dependencies before module and plugin targets start execution. See :ref:`collection_creating_integration_tests` for details. - -To run integration tests, we use the ``ansible-test`` utility that is included in the ``ansible-core`` and ``ansible`` packages. See :ref:`collection_run_integration_tests` for details. After you finish your integration tests, see to :ref:`collection_quickstart` to learn how to submit a pull request. - -.. _collection_integration_prepare: - -Preparing for integration tests for collections -================================================= - -To prepare for developing integration tests: - -#. :ref:`Set up your local environment `. - -#. Determine if integration tests already exist. - - .. code-block:: bash - - ansible-test integration --list-targets - - -If a collection already has integration tests, they are stored in ``tests/integration/targets/*`` subdirectories of the collection repository. - -If you use ``bash`` and the ``argcomplete`` package is installed with ``pip`` on your system, you can also get a full target list. - -.. code-block:: shell - - ansible-test integration - -Alternately, you can check if the ``tests/integration/targets`` directory contains a corresponding directory with the same name as the module. For example, the tests for the ``postgresql_user`` module of the ``community.postgresql`` collection are stored in the ``tests/integration/targets/postgresql_user`` directory of the collection repository. If there is no corresponding target there, then that module does not have integration tests. In this case, consider adding integration tests for the module. See :ref:`collection_creating_integration_tests` for details. - - -.. _collection_integration_recommendations: - -Recommendations on coverage -=========================== - -Bugfixes --------- - -Before fixing code, create a test case in an :ref:`appropriate test target` that reproduces the bug provided by the issue reporter and described in the ``Steps to Reproduce`` issue section. :ref:`Run ` the tests. - -If you failed to reproduce the bug, ask the reporter to provide additional information. The issue may be related to environment settings. Sometimes specific environment issues cannot be reproduced in integration tests, in that case, manual testing by issue reporter or other interested users is required. - -Refactoring code ----------------- - -When refactoring code, always check that related options are covered in a :ref:`corresponding test target`. Do not assume if the test target exists, everything is covered. - -.. _collections_recommendation_modules: - -Covering modules / new features -------------------------------- - -When covering a module, cover all its options separately and their meaningful combinations. Every possible use of the module should be tested against: - -- Idempotency - Does rerunning a task report no changes? -- Check-mode - Does dry-running a task behave the same as a real run? Does it not make any changes? -- Return values - Does the module return values consistently under different conditions? - -Each test action has to be tested at least the following times: - -- Perform an action in check-mode if supported. This should indicate a change. -- Check with another module that the changes have ``not`` been actually made. -- Perform the action for real. This should indicate a change. -- Check with another module that the changes have been actually made. -- Perform the action again in check-mode. This should indicate ``no`` change. -- Perform the action again for real. This should indicate ``no`` change. - -To check a task: - -1. Register the outcome of the task as a variable, for example, ``register: result``. Using the :ref:`assert ` module, check: - - #. If ``- result is changed`` or not. - #. Expected return values. - -2. If the module changes the system state, check the actual system state using at least one other module. For example, if the module changes a file, we can check that the file has been changed by checking its checksum with the :ref:`stat ` module before and after the test tasks. -3. Run the same task with ``check_mode: true`` if check-mode is supported by the module. Check with other modules that the actual system state has not been changed. -4. Cover cases when the module must fail. Use the ``ignore_errors: true`` option and check the returned message with the ``assert`` module. - -Example: - -.. code-block:: yaml - - - name: Task to fail - abstract_module: - ... - register: result - - - name: Check the task fails and its error message - assert: - that: - - result is failed - - result.msg == 'Message we expect' - -Here is a summary: - -- Cover options and their sensible combinations. -- Check returned values. -- Cover check-mode if supported. -- Check a system state using other modules. -- Check when a module must fail and error messages. diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_add.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_add.rst deleted file mode 100644 index a4c8a1096a4..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_integration_add.rst +++ /dev/null @@ -1,250 +0,0 @@ -.. _collection_creating_integration_tests: - -Creating new integration tests -================================= - -This section covers the following cases: - -- There are no integration tests for a collection or group of modules in a collection at all. -- You are adding a new module and you want to include integration tests. -- You want to add integration tests for a module that already exists without integration tests. - -In other words, there are currently no tests for a module regardless of whether the module exists or not. - -If the module already has tests, see :ref:`collection_updating_integration_tests`. - -Simplified example --------------------- - -Here is a simplified abstract example. - -Let's say we are going to add integration tests to a new module in the ``community.abstract`` collection which interacts with some service. - -We :ref:`checked` and determined that there are no integration tests at all. - -We should basically do the following: - -1. Install and run the service with a ``setup`` target. -2. Create a test target. -3. Add integration tests for the module. -4. :ref:`Run the tests`. -5. Fix the code and tests as needed, run the tests again, and repeat the cycle until they pass. - -.. note:: - - You can reuse the ``setup`` target when implementing other targets that also use the same service. - -1. Clone the collection to the ``~/ansible_collections/community.abstract`` directory on your local machine. - -2. From the ``~/ansible_collections/community.abstract`` directory, create directories for the ``setup`` target: - -.. code-block:: bash - - mkdir -p tests/integration/targets/setup_abstract_service/tasks - -3. Write all the tasks needed to prepare the environment, install, and run the service. - -For simplicity, let's imagine that the service is available in the native distribution repositories and no sophisticated environment configuration is required. - -Add the following tasks to the ``tests/integration/targets/setup_abstract_service/tasks/main.yml`` file to install and run the service: - -.. code-block:: yaml - - - name: Install abstract service - package: - name: abstract_service - - - name: Run the service - systemd: - name: abstract_service - state: started - -This is a very simplified example. - -4. Add the target for the module you are testing. - -Let's say the module is called ``abstract_service_info``. Create the following directory structure in the target: - -.. code-block:: bash - - mkdir -p tests/integration/targets/abstract_service_info/tasks - mkdir -p tests/integration/targets/abstract_service_info/meta - -Add all of the needed subdirectories. For example, if you are going to use defaults and files, add the ``defaults`` and ``files`` directories, and so on. The approach is the same as when you are creating a role. - -5. To make the ``setup_abstract_service`` target run before the module's target, add the following lines to the ``tests/integration/targets/abstract_service_info/meta/main.yml`` file. - -.. code-block:: yaml - - dependencies: - - setup_abstract_service - -6. Start with writing a single stand-alone task to check that your module can interact with the service. - -We assume that the ``abstract_service_info`` module fetches some information from the ``abstract_service`` and that it has two connection parameters. - -Among other fields, it returns a field called ``version`` containing a service version. - -Add the following to ``tests/integration/targets/abstract_service_info/tasks/main.yml``: - -.. code-block:: yaml - - - name: Fetch info from abstract service - abstract_service_info: - host: 127.0.0.1 # We assume the service accepts local connection by default - port: 1234 # We assume that the service is listening to this port by default - register: result # This variable will contain the returned JSON including the server version - - - name: Test the output - assert: - that: - - result.version == '1.0.0' # Check version field contains what we expect - -7. :ref:`Run the tests` with the ``-vvv`` argument. - -If there are any issues with connectivity (for example, the service is not accepting connections) or with the code, the play will fail. - -Examine the output to see at which step the failure occurred. Investigate the reason, fix it, and run again. Repeat the cycle until the test passes. - -8. If the test succeeds, write more tests. Refer to the :ref:`Recommendations on coverage` section for details. - -``community.postgresql`` example --------------------------------- - -Here is a real example of writing integration tests from scratch for the ``community.postgresql.postgresql_info`` module. - -For the sake of simplicity, we will create very basic tests which we will run using the Ubuntu 20.04 test container. - -We use ``Linux`` as a work environment and have ``git`` and ``docker`` installed and running. - -We also installed ``ansible-core``. - -1. Create the following directories in your home directory: - -.. code-block:: bash - - mkdir -p ~/ansible_collections/community - -2. Fork the `collection repository `_ through the GitHub web interface. - -3. Clone the forked repository from your profile to the created path: - -.. code-block:: bash - - git clone https://github.com/YOURACC/community.postgresql.git ~/ansible_collections/community/postgresql - -If you prefer to use the SSH protocol: - -.. code-block:: bash - - git clone git@github.com:YOURACC/community.postgresql.git ~/ansible_collections/community/postgresql - -4. Go to the cloned repository: - -.. code-block:: bash - - cd ~/ansible_collections/community/postgresql - -5. Be sure you are in the default branch: - -.. code-block:: bash - - git status - -6. Checkout a test branch: - -.. code-block:: bash - - git checkout -b postgresql_info_tests - -7. Since we already have tests for the ``postgresql_info`` module, we will run the following command: - -.. code-block:: bash - - rm -rf tests/integration/targets/* - -With all of the targets now removed, the current state is as if we do not have any integration tests for the ``community.postgresql`` collection at all. We can now start writing integration tests from scratch. - -8. We will start with creating a ``setup`` target that will install all required packages and will launch PostgreSQL. Create the following directories: - -.. code-block:: bash - - mkdir -p tests/integration/targets/setup_postgresql_db/tasks - -9. Create the ``tests/integration/targets/setup_postgresql_db/tasks/main.yml`` file and add the following tasks to it: - -.. code-block:: yaml - - - name: Install required packages - package: - name: - - apt-utils - - postgresql - - postgresql-common - - python3-psycopg2 - - - name: Initialize PostgreSQL - shell: . /usr/share/postgresql-common/maintscripts-functions && set_system_locale && /usr/bin/pg_createcluster -u postgres 12 main - args: - creates: /etc/postgresql/12/ - - - name: Start PostgreSQL service - ansible.builtin.service: - name: postgresql - state: started - -That is enough for our very basic example. - -10. Then, create the following directories for the ``postgresql_info`` target: - -.. code-block:: bash - - mkdir -p tests/integration/targets/postgresql_info/tasks tests/integration/targets/postgresql_info/meta - -11. To make the ``setup_postgresql_db`` target run before the ``postgresql_info`` target as a dependency, create the ``tests/integration/targets/postgresql_info/meta/main.yml`` file and add the following code to it: - -.. code-block:: yaml - - dependencies: - - setup_postgresql_db - -12. Now we are ready to add our first test task for the ``postgresql_info`` module. Create the ``tests/integration/targets/postgresql_info/tasks/main.yml`` file and add the following code to it: - -.. code-block:: yaml - - - name: Test postgresql_info module - become: true - become_user: postgres - community.postgresql.postgresql_info: - login_user: postgres - login_db: postgres - register: result - - - name: Check the module returns what we expect - assert: - that: - - result is not changed - - result.version.major == 12 - - result.version.minor == 8 - -In the first task, we run the ``postgresql_info`` module to fetch information from the database we installed and launched with the ``setup_postgresql_db`` target. We are saving the values returned by the module into the ``result`` variable. - -In the second task, we check the ``result`` variable, which is what the first task returned, with the ``assert`` module. We expect that, among other things, the result has the version and reports that the system state has not been changed. - -13. Run the tests in the Ubuntu 20.04 docker container: - -.. code-block:: bash - - ansible-test integration postgresql_info --docker ubuntu2004 -vvv - -The tests should pass. If we look at the output, we should see something like the following: - -.. code-block:: shell - - TASK [postgresql_info : Check the module returns what we expect] *************** - ok: [testhost] => { - "changed": false, - "msg": "All assertions passed" - } - -If your tests fail when you are working on your project, examine the output to see at which step the failure occurred. Investigate the reason, fix it, and run again. Repeat the cycle until the test passes. If the test succeeds, write more tests. Refer to the :ref:`Recommendations on coverage` section for details. diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_running.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_running.rst deleted file mode 100644 index 64e610da295..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_integration_running.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _collection_run_integration_tests: - -Running integration tests -============================ - -In the following examples, we will use ``Docker`` to run integration tests locally. Ensure you :ref:`collection_prepare_environment` first. - -We assume that you are in the ``~/ansible_collections/NAMESPACE/COLLECTION`` directory. - -After you change the tests, you can run them with the following command: - -.. code-block:: text - - ansible-test integration --docker - -The ``target_name`` is a test role directory containing the tests. For example, if the test files you changed are stored in the ``tests/integration/targets/postgresql_info/`` directory and you want to use the ``fedora34`` container image, then the command will be: - -.. code-block:: bash - - ansible-test integration postgresql_info --docker fedora34 - -You can use the ``-vv`` or ``-vvv`` argument if you need more detailed output. - -In the examples above, the ``fedora34`` test image will be automatically downloaded and used to create and run a test container. - -See the :ref:`list of supported container images `. - -In some cases, for example, for platform-independent tests, the ``default`` test image is required. Use the ``--docker default`` or just ``--docker`` option without specifying a distribution in this case. - -.. note:: - - If you have any difficulties with writing or running integration tests or you are not sure if the case can be covered, submit your pull request without the tests. Other contributors can help you with them later if needed. diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_tests.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_tests.rst deleted file mode 100644 index 9eef463613c..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_integration_tests.rst +++ /dev/null @@ -1,36 +0,0 @@ -.. _collection_integration_tests: - - -***************************************** -Adding integration tests to a collection -***************************************** - -This section describes the steps to add integration tests to a collection and how to run them locally using the ``ansible-test`` command. - -.. toctree:: - :maxdepth: 1 - - collection_integration_about - collection_integration_updating - collection_integration_running - collection_integration_add - - -.. seealso:: - - :ref:`testing_units_modules` - Unit testing Ansible modules - `pytest `_ - Pytest framework documentation - :ref:`developing_testing` - Ansible Testing Guide - :ref:`collection_unit_tests` - Unit testing for collections - :ref:`testing_integration` - Integration tests guide - :ref:`testing_collections` - Testing collections - :ref:`testing_resource_modules` - Resource module integration tests - :ref:`collection_pr_test` - How to test a pull request locally diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_updating.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_updating.rst deleted file mode 100644 index b519c4d4d1b..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_integration_updating.rst +++ /dev/null @@ -1,169 +0,0 @@ -.. _collection_updating_integration_tests: - -Adding to an existing integration test -======================================= - -The test tasks are stored in the ``tests/integration/targets//tasks`` directory. - -The ``main.yml`` file holds test tasks and includes other test files. -Look for a suitable test file to integrate your tests or create and include or import a separate test file. -You can use one of the existing test files as a draft. - -When fixing a bug ------------------ - -When fixing a bug: - -1. :ref:`Determine if integration tests for the module exist`. If they do not, see :ref:`collection_creating_integration_tests` section. -2. Add a task that reproduces the bug to an appropriate file within the ``tests/integration/targets//tasks`` directory. -3. :ref:`Run the tests`. The newly added task should fail. -4. If they do not fail, re-check if your environment or test task satisfies the conditions described in the ``Steps to Reproduce`` section of the issue. -5. If you reproduce the bug and tests fail, change the code. -6. :ref:`Run the tests` again. -7. If they fail, repeat steps 5-6 until the tests pass. - -Here is an example. - -Let's say someone reported an issue in the ``community.postgresql`` collection that when users pass a name containing underscores to the ``postgresql_user`` module, the module fails. - -We cloned the collection repository to the ``~/ansible_collections/community/postgresql`` directory and :ref:`prepared our environment `. From the collection's root directory, we run ``ansible-test integration --list-targets`` and it shows a target called ``postgresql_user``. It means that we already have tests for the module. - -We start with reproducing the bug. - -First, we look into the ``tests/integration/targets/postgresql_user/tasks/main.yml`` file. In this particular case, the file imports other files from the ``tasks`` directory. The ``postgresql_user_general.yml`` looks like an appropriate one to add our tests. - -.. code-block:: yaml - - # General tests: - - import_tasks: postgresql_user_general.yml - when: postgres_version_resp.stdout is version('9.4', '>=') - -We will add the following code to the file. - -.. code-block:: yaml - - # https://github.com/ansible-collections/community.postgresql/issues/NUM - - name: Test user name containing underscore - community.postgresql.postgresql_user: - name: underscored_user - register: result - - - name: Check the module returns what we expect - assert: - that: - - result is changed - - - name: Query the database if the user exists - community.postgresql.postgresql_query: - query: SELECT * FROM pg_authid WHERE rolename = 'underscored_user' - register: result - - - name: Check the database returns one row - assert: - that: - - result.query_result.rowcount == 1 - -When we :ref:`run the tests` with ``postgresql_user`` as a test target, this task must fail. - -Now that we have our failing test; we will fix the bug and run the same tests again. Once the tests pass, we will consider the bug fixed and will submit a pull request. - -When adding a new feature -------------------------- - -.. note:: - - The process described in this section also applies when you want to add integration tests to a feature that already exists, but is missing integration tests. - -If you have not already implemented the new feature, you can start by writing the integration tests for it. They will not work as the code does not yet exist, but they can help you improve your implementation design before you start writing any code. - -When adding new features, the process of adding tests consists of the following steps: - -1. :ref:`Determine if integration tests for the module exists`. If they do not, see :ref:`collection_creating_integration_tests`. -2. Find an appropriate file for your tests within the ``tests/integration/targets//tasks`` directory. -3. Cover your feature with tests. Refer to the :ref:`Recommendations on coverage` section for details. -4. :ref:`Run the tests`. -5. If they fail, see the test output for details. Fix your code or tests and run the tests again. -6. Repeat steps 4-5 until the tests pass. - -Here is an example. - -Let's say we decided to add a new option called ``add_attribute`` to the ``postgresql_user`` module of the ``community.postgresql`` collection. - -The option is boolean. If set to ``yes``, it adds an additional attribute to a database user. - -We cloned the collection repository to the ``~/ansible_collections/community/postgresql`` directory and :ref:`prepared our environment`. From the collection's root directory, we run ``ansible-test integration --list-targets`` and it shows a target called ``postgresql_user``. Therefore, we already have some tests for the module. - -First, we look at the ``tests/integration/targets//tasks/main.yml`` file. In this particular case, the file imports other files from the ``tasks`` directory. The ``postgresql_user_general.yml`` file looks like an appropriate one to add our tests. - -.. code-block:: yaml - - # General tests: - - import_tasks: postgresql_user_general.yml - when: postgres_version_resp.stdout is version('9.4', '>=') - -We will add the following code to the file. - -.. code-block:: yaml - - # https://github.com/ansible-collections/community.postgresql/issues/NUM - # We should also run the same tasks with check_mode: true. We omit it here for simplicity. - - name: Test for new_option, create new user WITHOUT the attribute - community.postgresql.postgresql_user: - name: test_user - register: result - - - name: Check the module returns what we expect - assert: - that: - - result is changed - - - name: Query the database if the user exists but does not have the attribute (it is NULL) - community.postgresql.postgresql_query: - query: SELECT * FROM pg_authid WHERE rolename = 'test_user' AND attribute = NULL - register: result - - - name: Check the database returns one row - assert: - that: - - result.query_result.rowcount == 1 - - - name: Test for new_option, create new user WITH the attribute - community.postgresql.postgresql_user: - name: test_user - register: result - - - name: Check the module returns what we expect - assert: - that: - - result is changed - - - name: Query the database if the user has the attribute (it is TRUE) - community.postgresql.postgresql_query: - query: SELECT * FROM pg_authid WHERE rolename = 'test_user' AND attribute = 't' - register: result - - - name: Check the database returns one row - assert: - that: - - result.query_result.rowcount == 1 - -Then we :ref:`run the tests` with ``postgresql_user`` passed as a test target. - -In reality, we would alternate the tasks above with the same tasks run with the ``check_mode: true`` option to be sure our option works as expected in check-mode as well. See :ref:`Recommendations on coverage` for details. - -If we expect a task to fail, we use the ``ignore_errors: true`` option and check that the task actually failed and returned the message we expect: - -.. code-block:: yaml - - - name: Test for fail_when_true option - community.postgresql.postgresql_user: - name: test_user - fail_when_true: true - register: result - ignore_errors: true - - - name: Check the module fails and returns message we expect - assert: - that: - - result is failed - - result.msg == 'The message we expect' diff --git a/docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst b/docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst deleted file mode 100644 index f8ba7edf373..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst +++ /dev/null @@ -1,341 +0,0 @@ -.. _collection_release_with_branches: - -Releasing collections with release branches -============================================ - -Collections MUST follow the `semantic versioning `_ rules. See :ref:`releasing_collections` for high-level details. - -.. contents:: - :local: - - -Release planning and announcement ----------------------------------- - -#. Announce your intention to release the collection in a corresponding pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel `_. Repeat the announcement in any other dedicated channels if they exist. - -#. Ensure all the other repository maintainers are informed about the time of the following release. - - -Releasing major collection versions -------------------------------------- - -The new version is assumed to be ``X.0.0``. - -1. Make sure that ``galaxy.yml`` contains the correct version number ``X.0.0``. If that is not the case, create a PR to update it. This will make sanity tests fail for all deprecations that have to be removed in ``X.0.0``, so this is potentially a lot of work and should have been done weeks before the major release. - -2. Check the collection for deprecations that are planned for removal in the major release that were not reported by the sanity tests. Use past changelogs or run ``grep -r `X.0.0` plugins/`` in the repository. - -3. If you are going to release the ``community.general`` and ``community.network`` collections, create a new ``backport-X`` label in the corresponding repositories. Copy the styles and descriptions from the corresponding existing labels. - -4. Ensure you are in a default branch in your local fork. These examples use ``main``. - - .. code-block:: bash - - git status - git checkout main # if needed - - -5. Update your local fork: - - .. code-block:: bash - - git pull --rebase upstream main - - -Creating the release branch -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. Create a branch ``stable-X``. Replace ``X`` with a correct number and push it to the **upstream** repository, NOT to the ``origin``.: - - .. code-block:: bash - - git branch stable-X main - git push upstream stable-X - - -2. Create and checkout to another branch from the ``main`` branch: - - .. code-block:: bash - - git checkout -b update_repo - - -3. Update the version in ``galaxy.yml`` in the branch to the next **expected** version, for example, ``X.1.0``. - - -Creating the changelogs -^^^^^^^^^^^^^^^^^^^^^^^^ - -1. Replace ``changelogs/changelog.yml`` with: - - .. code-block:: yaml - - ancestor: X.0.0 - releases: {} - - -2. Remove all changelog fragments from ``changelogs/fragments/``. Removing the changelog fragments ensures that every major release has a changelog describing changes since the last major release. - -3. Add and commit all the changes made. Push the branch to the ``origin`` repository. - -4. Create a pull request in the collection repository. If CI tests pass, merge the pull request since the ``main`` branch is expecting changes for the next minor/major versions - -5. Switch to the ``stable-X`` branch. - -6. In the ``stable-X`` branch, verify that ``galaxy.yml`` contains the correct version number ``X.0.0``. - -7. In the ``stable-X`` branch, ensure that ``changelogs/changelog.yml`` contains a correct ancestor's version: - - .. code-block:: yaml - - ancestor: X-1.0.0 - releases: {} - - -8. In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X.0.0.yml`` with the content: - - .. code-block:: yaml - - release_summary: |- - Write some text here that should appear as the release summary for this version. - The format is reStructuredText, but not a list as for regular changelog fragments. - This text will be inserted into the changelog. - - - For example: - - .. code-block:: yaml - - release_summary: This is release 2.0.0 of ``community.foo``, released on YYYY-MM-DD. - - -9. In the ``stable-X`` branch, generate the changelogs: - - .. code-block:: bash - - antsibull-changelog release --cummulative-release - - -10. In the ``stable-X`` branch, verify that the ``CHANGELOG.rst`` looks as expected. - -11. In the ``stable-X`` branch, update ``README.md`` so that the changelog link points to ``/tree/stable-X/`` and no longer to ``/tree/main/``, and change badges respectively, for example, in case of AZP, add ``?branchName=stable-X`` to the AZP CI badge (https://dev.azure.com/ansible/community.xxx/_apis/build/status/CI?branchName=stable-X). - -12. In the ``stable-X`` branch, add, commit, and push changes to ``README.md``, ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the **upstream** repository, NOT to the ``origin``. - - -Publishing the collection -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.0.0``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_. - - .. code-block:: bash - - git tag -n # see current tags and their comments - git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.0.0" - git push upstream NEW_VERSION - - -2. If the collection uses `Zuul `_ for publishing its releases, wait until the new version is published on the collection's `Ansible Galaxy `_ page. It will appear in a list of tarballs available to download. - -3. If the release tarball did not appear within several hours after pushing the tag, try to re-tag the release commit and push the tag again. In the ``stable-X`` branch being at the release commit: - - .. code-block:: bash - - git tag --delete NEW_VERSION - git push upstream :NEW_VERSION - git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.0.0" - git push upstream NEW_VERSION - - -4. Add a GitHub release for the new tag. The title should be the version and content, such as - ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``. - -5. Announce the release through the `Bullhorn Newsletter `_. - -6. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/Libera.Chat IRC channel `_. - -7. In the ``stable-X`` branch, update the version in ``galaxy.yml`` to the next **expected** version, for example, ``X.1.0``. Add, commit and push to the **upstream** repository. - - -Releasing minor collection versions -------------------------------------- - -The new version is assumed to be ``X.Y.0``. All changes that should go into it are expected to be previously backported from the default branch to the ``stable-X`` branch. - -Creating the changelogs -^^^^^^^^^^^^^^^^^^^^^^^^ - -1. In the ``stable-X`` branch, make sure that ``galaxy.yml`` contains the correct version number ``X.Y.0``. If not, update it. - -2. In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X.Y.0.yml`` with content: - - .. code-block:: yaml - - release_summary: |- - Write some text here that should appear as the release summary for this version. - The format is reStructuredText, but not a list as for regular changelog fragments. - This text will be inserted into the changelog. - - -3. In the ``stable-X`` branch, run: - - .. code-block:: bash - - antsibull-changelog release - - -4. In the ``stable-X`` branch, verify that ``CHANGELOG.rst`` looks as expected. - -5. In the ``stable-X`` branch, add, commit, and push changes to ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the **upstream** repository, NOT to the origin. - - -Publishing the collection -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.Y.0``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_. - - .. code-block:: bash - - git tag -n # see current tags and their comments - git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.1.0" - git push upstream NEW_VERSION - - -2. Wait until the new version is published on the collection's `Ansible Galaxy `_ page. The published version will appear in a list of tarballs available to download. - -3. Add a GitHub release for the new tag. The title should be the version and content, such as - ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``. - -4. Announce the release through the `Bullhorn Newsletter `_. - -5. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel `_. Additionally, you can announce it using GitHub's Releases system. - -6. In the ``stable-X`` branch, update the version in ``galaxy.yml`` to the next **expected** version, for example, if you have released ``X.1.0``, the next expected version could be ``X.2.0``. Add, commit and push to the **upstream** repository. - -7. Checkout to the ``main`` branch. - -8. In the ``main`` branch: - - #. If more minor versions are released before the next major version, update the version in ``galaxy.yml`` to ``X.(Y+1).0`` as well. Create a dedicated pull request and merge. - - #. If the next version will be a new major version, create a pull request where you update the version in ``galaxy.yml`` to ``(X+1).0.0``. Note that the sanity tests will most likely fail since there will be deprecations with removal scheduled for ``(X+1).0.0``, which are flagged by the tests. - - For every such deprecation, decide: - - * Whether to remove them now. For example you remove the complete ``modules/plugins`` or you remove redirects. - * Whether to add ignore entries to the corresponding ``tests/sanity/ignore-*.txt`` file and create issues, for example for removed features in ``modules/plugins``. - - Once the CI tests pass, merge the pull request. Make sure that this pull request is merged not too much later after the release - for ``version_added`` sanity tests not to expect the wrong version for the new feature pull request. - -.. note:: - - It makes sense to already do some removals in the days before the release. These removals must happen in the main branch and must not be backported. - - -Releasing patch versions -------------------------- - -The new version is assumed to be ``X.Y.Z``, and the previous patch version is assumed to be ``X.Y.z`` with ``z < Z``. ``z`` is frequently``0`` since patch releases are uncommon. - -Releasing when more minor versions are expected -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. Checkout the ``X.Y.z`` tag. - -2. Update ``galaxy.yml`` so that the version is ``X.Y.Z``. Add and commit. - -3. Cherry-pick all changes from ``stable-X`` that were added after ``X.Y.z`` and should go into ``X.Y.Z``. - -4. Add a changelog fragment ``changelogs/fragments/X.Y.Z.yml`` with content: - - .. code-block:: yaml - - release_summary: |- - Write some text here that should appear as the release summary for this version. - The format is reStructuredText but not a list as for regular changelog fragments. - This text will be inserted into the changelog. - - Add to git and commit. - -5. Generate the changelogs. - -.. code-block:: bash - - antsibull-changelog release - -6. Verify that ``CHANGELOG.rst`` looks as expected. - -7. Add and commit changes to ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments. - -**Publishing the collection** - - -1. Add an annotated tag to the last commit with the collection version ``X.Y.Z``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_. - - .. code-block:: bash - - git tag -n # see current tags and their comments - git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.1.1" - git push upstream NEW_VERSION - - -2. Wait until the new version is published on the collection's `Ansible Galaxy `_ page. It will appear in a list of tarballs available to download. - -3. Add a GitHub release for the new tag. The title should be the version and content, such as - ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``. - - .. note:: - - The data for this release is only contained in a tag, and not in a branch, in particular not in ``stable-X``. - This is deliberate, since the next minor release ``X.(Y+1).0`` already contains the changes for ``X.Y.Z`` as well, since these were cherry-picked from ``stable-X``. - - -4. Announce the release through the `Bullhorn Newsletter `_. - -5. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel `. - - -Releasing when no more minor versions are expected -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. In the ``stable-X`` branch, make sure that ``galaxy.yml`` contains the correct version number ``X.Y.Z``. If not, update it! - -2. In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X.Y.Z.yml`` with content: - - .. code-block:: yaml - - release_summary: |- - Write some text here that should appear as the release summary for this version. - The format is reStructuredText, but not a list as for regular changelog fragments. - This text will be inserted into the changelog. - - -3. Generate the changelogs in the ``stable-X`` branch. - - .. code-block:: bash - - antsibull-changelog release - - -4. In the ``stable-X`` branch, verify that ``CHANGELOG.rst`` looks as expected. - -5. In the ``stable-X`` branch, add, commit, and push changes to ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the **upstream** repository, NOT to the origin. - -**Publishing the collection** - - -1. In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.Y.Z``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_. - - .. code-block:: bash - - git tag -n # see current tags and their comments - git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.1.1" - git push upstream NEW_VERSION - - -2. Wait until the new version is published on the collection's `Ansible Galaxy `_ page. It will appear in a list of tarballs available to download. - -3. Add a GitHub release for the new tag. Title should be the version and content, such as: ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``. - -4. Announce the release through the `Bullhorn Newsletter `_. - -5. Announce the release in the pinned issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel `_. diff --git a/docs/docsite/rst/community/collection_contributors/collection_release_without_branches.rst b/docs/docsite/rst/community/collection_contributors/collection_release_without_branches.rst deleted file mode 100644 index 4cef33f03c8..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_release_without_branches.rst +++ /dev/null @@ -1,115 +0,0 @@ - -.. _collection_release_without_branches: - -Releasing collections without release branches -=============================================== - -Since no release branches are used, this section does not distinguish between releasing a major, minor, or patch version. - -.. contents:: - :local: - -Release planning and announcement ----------------------------------- - -#. Examine the collection to determine if there are merged changes to release. - -#. According to the changes made, choose an appropriate release version number. Keep in mind that the collections must follow the `semantic versioning `_ rules. See :ref:`collection_versioning_and_deprecation` for details. - -#. Announce your intention to release the collection in a corresponding pinned release issue or community pinboard of the collection and in the ``community`` :ref:`Matrix/IRC channel `. - -Creating the release branch ----------------------------- - -1. Ensure you are in a default branch in your local fork. We use ``main`` in the following examples. - - .. code:: bash - - git status - git checkout main # if needed - - -2. Update your local fork: - - .. code:: bash - - git pull --rebase upstream main - - -3. Checkout a new release branch from the default branch: - - .. code:: bash - - git checkout -b release_branch - -4. Ensure the ``galaxy.yml`` contains the correct release version number. - - -Generating the changelog -------------------------- - -1. Add a changelog fragment ``changelogs/fragments/X.Y.Z.yml`` with content: - - .. code:: yaml - - release_summary: |- - Write some text here that should appear as the release summary for this version. - The format is reStructuredText, but not a list as for regular changelog fragments. - This text will be inserted into the changelog. - - For example: - - .. code:: yaml - - release_summary: |- - This is the minor release of the ``community.mysql`` collection. - This changelog contains all changes to the modules and plugins in this collection - that have been made after the previous release. - - -2. If the content was recently moved from another collection (for example, migrating a module from one collection to another), ensure you have all related changelog fragments in the ``changelogs/fragments`` directory. If not, copy them previously. - -3. Run ``antsibull-changelog release --reload-plugins`` . This package should previously be installed with ``pip install antsibull-changelog``. - -4. Verify that the ``CHANGELOG.rst`` looks as expected. - -5. Commit and push changes to the ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the ``origin`` repository's ``release_branch``. - - .. code:: bash - - git commit -a -m "Release VERSION commit" - git push origin release_branch - - -6. Create a pull request in the collection repository. If CI tests pass, merge it. - -7. Checkout the default branch and pull the changes: - - .. code:: bash - - git checkout main - git pull --rebase upstream main - - -Publish the collection ------------------------------------ - -1. Add an annotated tag to the release commit with the collection version. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_. - - .. code:: bash - - git tag -n # see current tags and their comments - git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.postgresql: 1.2.0" - git push upstream NEW_VERSION - - - -2. Wait until the new version is published on the collection's `Ansible Galaxy `_ page. It will appear in a list of tarballs available to download. - -3. Update the version in the ``galaxy.yml`` file to the next **expected** version. Add, commit, and push to the ``upstream``'s default branch. - -4. Add a GitHub release for the new tag. Title should be the version and content ``See https://github.com/ansible-collections/community.xxx/blob/main/CHANGELOG.rst for all changes``. - -5. Announce the release through the `Bullhorn Newsletter issue `_. - -6. Announce the release in the pinned release issue/community pinboard of the collection mentioned in step 3 and in the ``community`` :ref:`Matrix/IRC channel `. diff --git a/docs/docsite/rst/community/collection_contributors/collection_releasing.rst b/docs/docsite/rst/community/collection_contributors/collection_releasing.rst deleted file mode 100644 index 481208b007a..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_releasing.rst +++ /dev/null @@ -1,106 +0,0 @@ - -.. _releasing_collections: -.. _Releasing: - -Releasing collections -====================== - -Collection maintainers release all supported stable versions of the collections regularly, -provided that there have been enough changes merged to release. - - -.. contents:: - :local: - -Preparing to release a collection --------------------------------------------- - - -The collections under the `ansible-collections organization `_ follow `semantic versioning `_ when releasing. See :ref:`collection_versioning_and_deprecation` for details. - -To prepare for a release, a collection must have: - -* A publicly available policy of releasing, versioning, and deprecation. This can be, for example, written in its README or in a dedicated pinned issue. -* A pinned issue when its release managers inform the community about planned or completed releases. This can be combined with the release policy issue mentioned above. -* A :ref:`changelog `. -* Releases of the collection tagged in the collection's repository. -* CI pipelines up and running. This can be implemented by using GitHub Actions, Azure Pipelines, Zuul. -* All CI tests running against a commit that releases the collection. If they do not pass, the collection MUST NOT be released. - -See :ref:`including_collection_ansible` if you plan on adding a new collection to the Ansible package. - -.. note:: - - Your collection must pass ``ansible-test sanity`` tests. See :ref:`testing_collections` for details. - - -.. _collection_versioning_and_deprecation: - -Collection versioning and deprecation --------------------------------------- - -.. note:: - - Collections MUST adhere to `semantic versioning `_. - -To preserve backward compatibility for users, every Ansible minor version series (5.1.x, 5.2.x, and so on) will keep the major version of a collection constant. For example, if Ansible 5.0.0 includes ``community.general`` 4.0.2, then each Ansible 5.X.x release will include the latest ``community.general`` 4.y.z release available at build time. Ansible 5.x.x will **never** include a ``community.general`` 5.y.x release, even if it is available. Major collection version changes will be included in the next Ansible major release (6.0.0 in this case). -Ensure that the current major release of your collection included in 6.0.0 receives at least bugfixes as long as new Ansible 6.X.X releases are produced. - -Since new minor releases are included, you can include new features, modules and plugins. You must make sure that you do not break backwards compatibility. See `semantic versioning `_. for more details. This means in particular: - -* You can fix bugs in **patch** releases but not add new features or deprecate things. -* You can add new features and deprecate things in **minor** releases, but not remove things or change behavior of existing features. -* You can only remove things or make breaking changes in **major** releases. - -Ensure that if a deprecation is added in a collection version that is included in 5.x.y, the removal itself will only happen in a collection version included in 7.0.0 or later. -Ensure that the policy of releasing, versioning, and deprecation is announced to contributors and users in some way. For an example of how to do this, see `the announcement in community.general `_. You could also do this in the collection README file. - -.. _collection_changelog: - -Collection changelogs ----------------------- - -Collections MUST include a changelog. To give a consistent feel for changelogs across collections and ensure changelogs exist for collections included in the ``ansible`` package, we suggest you use `antsibull-changelog `_ to maintain and generate this. - -Before releasing, verify the following for your changelogs: - -* All merged pull requests since the last release, except ones related to documentation and new modules/plugins, have :ref:`changelog fragments `. -* New module and plugin pull requests, except jinja2 test and filter plugins, do **not** need a changelog fragment, they are auto-detected by the changelog generator by their ``version_added`` value. -* All the fragments follow the :ref:`changelog entry format `. - -Options for releasing a collection ------------------------------------ - -There are several approaches on how to release a collection. If you are not aware of which approach to use, ask in the ``#ansible-community`` IRC channel or the ``community`` Matrix channel. - -This section assumes that publishing the collection is done with `Zuul `_ and that `antsibull-changelog `_ is used for the changelog. - -Releasing without release branches -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use releasing without release branches when: - -* There are no prior major releases of the collection. -* There are no breaking changes introduced since the ``1.0.0`` release of the collection. - -See :ref:`collection_release_without_branches` for details. - -When there is a need to introduce breaking changes, you can switch to the next approach. - -Hybrid approach -^^^^^^^^^^^^^^^^^^^^^ - -In this approach, releases for the current major version are made from the ``main`` branch, while new releases for older major versions are made from release branches for these versions. - -Releasing with release branches -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use releasing with release branches when breaking changes have been introduced. This approach is usually only used by the large community collections, ``community.general`` and ``community.network``. - -See :ref:`collection_release_with_branches` for details. - -.. toctree:: - :maxdepth: 1 - - collection_release_without_branches - collection_release_with_branches diff --git a/docs/docsite/rst/community/collection_contributors/collection_requirements.rst b/docs/docsite/rst/community/collection_contributors/collection_requirements.rst deleted file mode 100644 index 261c3effd00..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_requirements.rst +++ /dev/null @@ -1,499 +0,0 @@ -.. _collections_requirements: - -************************************************** -Ansible community package collections requirements -************************************************** - -This section describes the requirements for maintainers of Ansible community collections in the `ansible-collections `_ repository or included in the Ansible community package. - -.. contents:: - :local: - - -Overview -======== - -This section provides help, advice, and guidance on making sure your collections are correct and ready for inclusion in the Ansible community package. - -.. note:: - - `Inclusion of a new collection `_ in the Ansible package is ultimately at the discretion of the :ref:`community_steering_committee`. Every rejected candidate will get feedback. Differences of opinion should be taken to a dedicated `Community Topic `_ for discussion and a final vote. - -Feedback and communications -============================== - -As with any project it is very important that we get feedback from users, contributors, and maintainers. You can get feedback and help as follows: - -* Discussing in the `#community:ansible.com Matrix room `_, which is bridged with the ``#ansible-community`` channel on Libera.Chat IRC. See the :ref:`Ansible Communication Guide ` for details. -* Discussing in the `Community Working Group meeting `_. -* Creating `GitHub Issues `_ in the ``ansible-collections`` repository. - -Keeping informed -================ - -You should subscribe to: - -* The `news-for-maintainers repository `_ to track changes that collection maintainers should be aware of. Subscribe only to issues if you want less traffic. -* The `Bullhorn `_ Ansible contributor newsletter. - -.. _coll_infrastructure_reqs: - -Collection infrastructure -========================= - - -The following guidelines describe the required structure for your collection: - -* MUST have a publicly available issue tracker that does not require a paid level of service to create an account or view issues. -* MUST have a Code of Conduct (CoC). - - * The collection's CoC MUST be compatible with the :ref:`code_of_conduct`. - * The collections SHOULD consider using the Ansible CoC if they do not have a CoC that they consider better. - * The :ref:`Diversity and Inclusion working group ` may evaluate all CoCs and object to a collection's inclusion based on the CoCs contents. - * The CoC MUST be linked from the ``README.md`` file, or MUST be present or linked from the ``CODE_OF_CONDUCT.md`` file in the collection root. - -* MUST be published to `Ansible Galaxy `_. -* SHOULD NOT contain any large objects (binaries) comparatively to the current Galaxy tarball size limit of 20 MB, For example, do not include package installers for testing purposes. -* SHOULD NOT contain any unnecessary files such as temporary files. -* MUST only contain objects that follow the :ref:`Licensing rules `. - - -.. _coll_python_compatibility: - -Python Compatibility -==================== - -A collection MUST be developed and tested using the below Python requirements as Ansible supports a wide variety of machines. - -The collection should adhere to the tips at :ref:`ansible-and-python-3`. - -.. _coll_python_reqs: - -Python Requirements -------------------- - -Python requirements for a collection vary between **controller environment** and **other environment**. On the controller-environment, the Python versions required may be higher than what is required on the other-environment. While developing a collection, you need to understand the definitions of both the controller-environment and other-environment to help you choose Python versions accordingly: - -* controller environment: The plugins/modules always run in the same environment (Python interpreter, venv, host, and so on) as ansible-core itself. -* other environment: It is possible, even if uncommon in practice, for the plugins/modules to run in a different environment than ansible-core itself. - -One example scenario where the "even if" clause comes into play is when using cloud modules. These modules mostly run on the controller node but in some environments, the controller might run on one machine inside a demilitarized zone which cannot directly access the cloud machines. The user has to have the cloud modules run on a bastion host/jump server which has access to the cloud machines. - -.. _coll_controller_req: - -Controller environment -~~~~~~~~~~~~~~~~~~~~~~ - -Review the :ref:`support_life` for the versions of ``ansible-core`` that the collection supports. Collections MUST document the supported Python versions for plugins which cannot support all controller Python versions (for example, if required libraries do not support them). - -Other environment -~~~~~~~~~~~~~~~~~ - -Review the :ref:`support_life` for the versions of ``ansible-core`` that the collection supports. Collections MUST document the supported Python versions for modules which cannot support all target Python versions (for example, if required libraries do not support them). - -.. note:: - - If the collection does not support Python 2.6 and/or Python 3.5 explicitly then take the below points into consideration: - - - Dropping support for Python 2.6 in the other environment means that you are dropping support for RHEL6. RHEL6 ended full support in November, 2020, but some users are still using RHEL6 under extended support contracts (ELS) until 2024. ELS is not full support; not all CVEs of the python-2.6 interpreter are fixed, for instance. - - - Dropping support for Python 3.5 means that Python 2.7 has to be installed on Ubuntu Xenial (16.04) and that you have to support Python 2.7. - - Also, note that dropping support for a Python version for an existing module/plugin is a breaking change, and thus requires a major release. A collection MUST announce dropping support for Python versions in their changelog, if possible in advance (for example, in previous versions before support is dropped). - -.. _coll_python_docs_req: - -Python documentation requirements -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -* If everything in your collection supports the same Python versions as the collection-supported versions of ansible-core, you do not need to document Python versions. -* If your collection does not support those Python versions, you MUST document which versions it supports in the README. -* If most of your collection supports the same Python versions as ansible-core, but some modules and plugins do not, you MUST include the supported Python versions in the documentation for those modules and plugins. - -For example, if your collection supports Ansible 2.9 to ansible-core 2.13, the Python versions supported for modules are 2.6, 2.7, and 3.5 and newer (until at least 3.10), while the Python versions supported for plugins are 2.7 and 3.5 and newer (until at least 3.10). So if the modules in your collection do not support Python 2.6, you have to document this in the README, for example ``The content in this collection supports Python 2.7, Python 3.5 and newer.``. - -.. _coll_plugin_standards: - -Standards for developing module and plugin utilities -==================================================== - -* ``module_utils`` and ``plugin_utils`` can be marked for only internal use in the collection, but they MUST document this and MUST use a leading underscore for filenames. -* It is a breaking change when you make an existing ``module_utils`` private and in that case the collection requires a major version bump. -* Below are some recommendations for ``module_utils`` documentation: - - * No docstring: everything we recommend for ``other-environment`` is supported. - * The docstring ``'Python versions supported: same as for controller-environment'``: everything we recommend for ``controller-environment`` is supported. - * The docstring with specific versions otherwise: ``'Python versions supported: '``. - -.. _coll_repo_structure: - -Repository structure requirements -================================== - -galaxy.yml ----------- - -* The ``tags`` field MUST be set. -* Collection dependencies must meet a set of rules. See the section on `Collection Dependencies ` for details. -* The ``ansible`` package MUST NOT depend on collections not shipped in the package. -* If you plan to split up your collection, the new collection MUST be approved for inclusion before the smaller collections replace the larger in Ansible. -* If you plan to add other collections as dependencies, they MUST run through the formal application process. - -.. _coll_readme_req: - -README.md ---------- - -Your collection repository MUST have a ``README.md`` in the root of the collection, see `collection_template/README.md `_ for an example. - -meta/runtime.yml ----------------- -Example: `meta/runtime.yml `_ - -* The ``meta/runtime.yml`` MUST define the minimum version of Ansible which this collection works with. - - * If the collection works with Ansible 2.9, then this should be set to `>=2.9.10` - * It is usually better to avoid adding `<2.11` as a restriction, since this for example makes it impossible to use the collection with the current ansible-base devel branch (which has version 2.11.0.dev0) - -.. _coll_module-reqs: - -Modules & Plugins ------------------- - -* Collections MUST only use the directories specified below in the ``plugins/`` directory and - only for the purposes listed: - - :Those recognized by ansible-core: ``doc_fragments``, ``modules``, ``module_utils``, ``terminal``, and those listed in :ref:`working_with_plugins`. This list can be verified by looking at the last element of the package argument of each ``*_loader`` in https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/loader.py#L1126 - :plugin_utils: For shared code which is only used controller-side, not in modules. - :sub_plugins: For other plugins which are managed by plugins inside of collections instead of ansible-core. We use a subfolder so there aren't conflicts when ansible-core adds new plugin types. - - The core team (which maintains ansible-core) has committed not to use these directories for - anything which would conflict with the uses specified here. - -Other directories ------------------ - -Collections MUST not use files outside ``meta/``, ``plugins/``, ``roles/`` and ``playbooks/`` in any plugin, role, or playbook that can be called by FQCN, used from other collections, or used from user playbooks and roles. A collection must work if every file or directory is deleted from the installed collection except those four directories and their contents. - -Internal plugins, roles and playbooks (artifacts used only in testing, or only to release the collection, or only for some other internal purpose and not used externally) are exempt from this rule and may rely on files in other directories. - -.. _coll_docs_structure_reqs: - -Documentation requirements -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -All modules and plugins MUST: - -* Include a :ref:`DOCUMENTATION ` block. -* Include an :ref:`EXAMPLES ` block (except where not relevant for the plugin type). -* Use FQCNs when referring to modules, plugins and documentation fragments inside and outside the collection (including ``ansible.builtin`` for the listed entities from ansible-core. - -When using ``version_added`` in the documentation: - -* Declare the version of the collection in which the options were added -- NOT the version of Ansible. -* If you for some reason really have to specify version numbers of Ansible or of another collection, you also have to provide ``version_added_collection: collection_name``. We strongly recommend to NOT do this. -* Include ``version_added`` when you add new content (modules, plugins, options) to an existing collection. The values are shown in the documentation, and can be useful, but you do not need to add ``version_added`` to every option, module, and plugin when creating a new collection. - -Other items: - -* The ``CONTRIBUTING.md`` (or ``README.md``) file MUST state what types of contributions (pull requests, feature requests, and so on) are accepted and any relevant contributor guidance. Issues (bugs and feature request) reports must always be accepted. -* Collections are encouraged to use z:ref:`links and formatting macros ` -* Including a :ref:`RETURN ` block for modules is strongly encouraged but not required. - -.. _coll_workflow: - -Contributor Workflow -==================== - -.. _coll_changlogs_req: - -Changelogs ----------- - -Collections are required to include a changelog. To give a consistent feel for changelogs across collections and ensure changelogs exist for collections included in the ``ansible`` package we suggest you use `antsibull-changelog `_ to maintain and generate this but other options exist. Preferred (in descending order): - -#. Use antsibull-changelog (preferred). -#. Provide ``changelogs/changelog.yaml`` in the `correct format `_. (You can use ``antsibull-lint changelog-yaml /path/to/changelog.yaml`` to validate the format.) -#. Provide a link to the changelog file (self-hosted) (not recommended). - -Note that the porting guide is compiled from ``changelogs/changelog.yaml`` (sections ``breaking_changes``, ``major_changes``, ``deprecated_features``, ``removed_features``). So if you use option 3, you will not be able to add something to the porting guide. - -.. _coll_versioning_req: - -Versioning and deprecation -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -* Collections MUST adhere to `semantic versioning `_. -* To preserve backward compatibility for users, every Ansible minor version series (x.Y.z) will keep the major version of a collection constant. If ansible 3.0.0 includes ``community.general`` 2.2.0, then each 3.Y.z (3.1.z, 3.2.z, and so on) release will include the latest ``community.general`` 2.y.z release available at build time. Ansible 3.y.z will **never** include a ``community.general`` 3.y.z release, even if it is available. Major collection version changes will be included in the next Ansible major release (4.0.0 in this example). -* Therefore, ensure that the current major release of your collection included in 3.0.0 receives at least bugfixes as long as new 3.Y.Z releases are produced. -* Since new minor releases are included, you can include new features, modules and plugins. You must make sure that you do not break backwards compatibility! (See `semantic versioning `_.) This means in particular: - - * You can fix bugs in patch releases, but not add new features or deprecate things. - * You can add new features and deprecate things in minor releases, but not remove things or change behavior of existing features. - * You can only remove things or make breaking changes in major releases. -* We recommend that you ensure that if a deprecation is added in a collection version that is included in Ansible 3.y.z, the removal itself will only happen in a collection version included in Ansible 5.0.0 or later, but not in a collection version included in Ansible 4.0.0. -* Content moved from ansible/ansible that was scheduled for removal in 2.11 or later MUST NOT be removed in the current major release available when ansible 2.10.0 is released. Otherwise it would already be removed in 2.10, unexpectedly for users! Deprecation cycles can be shortened (since they are now uncoupled from ansible or ansible-base versions), but existing ones must not be unexpectedly terminated. -* We recommend you announce your policy of releasing, versioning and deprecation to contributors and users in some way. For an example of how to do this, see `the announcement in community.general `_. You could also do this in the README. - -.. _ coll_naming_req: - -Naming -====== - -Collection naming ------------------ - -For collections under ansible-collections the repository SHOULD be named ``NAMESPACE.COLLECTION``. - -To create a new collection and corresponding repository, first, a new namespace in Galaxy has to be created by submitting `Request a namespace `_. - -`Namespace limitations `_ lists requirements for namespaces in Galaxy. - -For collections created for working with a particular entity, they should contain the entity name, for example ``community.mysql``. - -For corporate maintained collections, the repository can be named ``COMPANY_NAME.PRODUCT_NAME``, for example ``ibm.db2``. - -We should avoid FQCN / repository names: - -* which are unnecessary long: try to make it compact but clear. -* contain the same words / collocations in ``NAMESPACE`` and ``COLLECTION`` parts, for example ``my_system.my_system``. - -If your collection is planned to be certified on **Red Hat Automation Hub**, please consult with Red Hat Partner Engineering through ``ansiblepartners@redhat.com`` to ensure collection naming compatibility between the community collection on **Galaxy**. - -.. _coll_module_name_req: - -Module naming -------------- - -Modules that only gather information MUST be named ``_info``. Modules that return ``ansible_facts`` are named ``_facts`` and do not return non-facts. -For more information, refer to the :ref:`Developing modules guidelines `. - -.. _coll_licensing_req: - -Collection licensing requirements -=================================== - -.. note:: - - The guidelines below are more restrictive than strictly necessary. We will try to add a larger list of acceptable licenses once we have approval from Red Hat Legal. - -There are four types of content in collections which licensing has to address in different -ways: - -:modules: must be licensed with a free software license that is compatible with the - `GPL-3.0-or-later `_ -:module_utils: must be licensed with a free software license that is compatible with the - `GPL-3.0-or-later `_. Ansible - itself typically uses the `BSD-2-clause - `_ license to make it possible for - third-party modules which are licensed incompatibly with the GPLv3 to use them. - Please consider this use case when licensing your own ``module_utils``. -:All other code in ``plugins/``: All other code in ``plugins/`` must be under the `GPL-3.0-or-later - `_. These plugins - are run inside of the Ansible controller process which is licensed under - the ``GPL-3.0-or-later`` and often must import code from the controller. - For these reasons, ``GPL-3.0-or-later`` must be used. -:All other code: Code outside ``plugins/`` may be licensed under another free software license that is compatible - with the `GPL-3.0-or-later `_, - provided that such code does not import any other code that is licensed under - the ``GPL-3.0-or-later``. If the file does import other ``GPL-3.0-or-later`` code, - then it must similarly be licensed under ``GPL-3.0-or-later``. Note that this applies in - particular to unit tests; these often import code from ansible-core, plugins, module utils, - or modules, and such code is often licensed under ``GPL-3.0-or-later``. -:Non code content: At the moment, these must also be under the `GPL-3.0-or-later - `_. - -Use `this table of licenses from the Fedora Project -`_ to find which licenses are -compatible with the GPLv3+. The license must be considered open source on both the Fedora License -table and the `Debian Free Software Guidelines `_ to be -allowed. - -These guidelines are the policy for inclusion in the Ansible package and are in addition to any -licensing and legal concerns that may otherwise affect your code. - -.. _coll_repo_management: - -Repository management -===================== - -Every collection MUST have a public git repository. Releases of the collection MUST be tagged in said repository. This means that releases MUST be ``git tag``\ ed and that the tag name MUST exactly match the Galaxy version number. Tag names MAY have a ``v`` prefix, but a collection's tag names MUST have a consistent format from release to release. - -Additionally, collection artifacts released to Galaxy MUST be built from the sources that are tagged in the collection's git repository as that release. Any changes made during the build process MUST be clearly documented so the collection artifact can be reproduced. - -We are open to allowing other SCM software once our tooling supports them. - -.. _coll_branch_config: - -Branch name and configuration ------------------------------ - -This subsection is **only** for repositories under `ansible-collections `_! Other collection repositories can also follow these guidelines, but do not have to. - -All new repositories MUST have ``main`` as the default branch. - -Existing repositories SHOULD be converted to use ``main``. - -Repository Protections: - -* Allow merge commits: disallowed - -Branch protections MUST be enforced: - -* Require linear history -* Include administrators - -.. _coll_ci_tests: - -CI Testing -=========== - -.. note:: - - You can copy the free-to-use `GitHub action workflow file `_ from the `Collection Template repository `_ to the `.github/workflows` directory in your collection to set up testing through GitHub actions. The workflow covers all the requirements below. - -* You MUST run the ``ansible-test sanity`` command from the `latest stable ansible-base/ansible-core branch `_. - - * Collections MUST run an equivalent of the ``ansible-test sanity --docker`` command. - * If they do not use ``--docker``, they must make sure that all tests run, in particular the compile and import tests (which should run for all :ref:`supported Python versions `). - * Collections can choose to skip certain Python versions that they explicitly do not support; this needs to be documented in ``README.md`` and in every module and plugin (hint: use a docs fragment). However we strongly recommend you follow the :ref:`Ansible Python Compatibility ` section for more details. - -* You SHOULD suggest to *additionally* run ``ansible-test sanity`` from the ansible/ansible ``devel`` branch so that you find out about new linting requirements earlier. -* The sanity tests MUST pass. - - * Adding some entries to the ``test/sanity/ignore*.txt`` file is an allowed method of getting them to pass, except cases listed below. - * You SHOULD not have ignored test entries. A reviewer can manually evaluate and approve your collection if they deem an ignored entry to be valid. - - * You MUST not ignore the following validations. They must be fixed before approval: - * ``validate-modules:doc-choices-do-not-match-spec`` - * ``validate-modules:doc-default-does-not-match-spec`` - * ``validate-modules:doc-missing-type`` - * ``validate-modules:doc-required-mismatch`` - * ``validate-modules:mutually_exclusive-unknown`` - * ``validate-modules:no-log-needed`` (use ``no_log=False`` in the argument spec to flag false positives!) - * ``validate-modules:nonexistent-parameter-documented`` - * ``validate-modules:parameter-list-no-elements`` - * ``validate-modules:parameter-type-not-in-doc`` - * ``validate-modules:undocumented-parameter`` - - * All entries in ignores.txt MUST have a justification in a comment in the ignore.txt file for each entry. For example ``plugins/modules/docker_container.py use-argspec-type-path # uses colon-separated paths, can't use type=path``. - * Reviewers can block acceptance of a new collection if they don't agree with the ignores.txt entries. - -* You MUST run CI against each of the "major versions" (2.10, 2.11, 2.12, etc) of ``ansible-base``/``ansible-core`` that the collection supports. (Usually the ``HEAD`` of the stable-xxx branches.) -* All CI tests MUST run against every pull request and SHOULD pass before merge. -* At least sanity tests MUST run against a commit that releases the collection; if they do not pass, the collection will NOT be released. - - - If the collection has integration/unit tests, they SHOULD run too; if they do not pass, the errors SHOULD be analyzed to decide whether they should block the release or not. -* All CI tests MUST run regularly (nightly, or at least once per week) to ensure that repositories without regular commits are tested against the latest version of ansible-test from each ansible-base/ansible-core version tested. The results from the regular CI runs MUST be checked regularly. - -All of the above can be achieved by using the `GitHub Action template `_. - -To learn how to add tests to your collection, see: - -* :ref:`collection_integration_tests` -* :ref:`collection_unit_tests` - - -.. _coll_wg_reqs: - -Collections and Working Groups -============================== - -The collections have: - -* Working group page(s) on a corresponding wiki if needed. Makes sense if there is a group of modules for working with one common entity, for example postgresql, zabbix, grafana, and so on. -* Issue for agenda (or pinboard if there are not regular meetings) as a pinned issue in the repository. - -.. _coll_migrating_reqs: - -When moving modules between collections -======================================= - -All related entities must be moved/copied including: - -* Related plugins and module_utils files (when moving, be sure it is not used by other modules, otherwise copy). -* CI and unit tests. -* Corresponding documentation fragments from ``plugins/doc_fragments``. - -Also: - -* Change ``M()``, examples, ``seealso``, ``extended_documentation_fragments`` to use actual FQCNs in moved content and in other collections that have references to the content. -* Move all related issues, pull requests, and wiki pages. -* Look through ``docs/docsite`` directory of `ansible-base GitHub repository `_ (for example, using the ``grep`` command-line utility) to check if there are examples using the moved modules and plugins to update their FQCNs. - -See :ref:`Migrating content to a different collection ` for complete details. - -.. _coll_development_conventions: - -Development conventions -======================= - -Besides all the requirements listed in the :ref:`module_dev_conventions`, be sure: - -* Your modules satisfy the concept of :ref:`idempotency `: if a module repeatedly runs with the same set of inputs, it will not make any changes on the system. -* Your modules do not query information using special ``state`` option values like ``get``, ``list``, ``query``, or ``info`` - - create new ``_info`` or ``_facts`` modules instead (for more information, refer to the :ref:`Developing modules guidelines `). -* ``check_mode`` is supported in all ``*_info`` and ``*_facts`` modules (for more information, refer to the :ref:`Development conventions <#following-ansible-conventions>`). - -.. _coll_dependencies: - -Collection Dependencies -======================= - -**Notation:** if foo.bar has a dependency on baz.bam, we say that baz.bam is the collection *depended on*, and foo.bar is the *dependent collection*. - -* Collection dependencies must have a lower bound on the version which is at least 1.0.0. - - * This means that all collection dependencies have to specify lower bounds on the versions, and these lower bounds should be stable releases, and not versions of the form 0.x.y. - * When creating new collections where collection dependencies are also under development, you need to watch out since Galaxy checks whether dependencies exist in the required versions: - - #. Assume that ``foo.bar`` depends on ``foo.baz``. - #. First release ``foo.baz`` as 1.0.0. - #. Then modify ``foo.bar``'s ``galaxy.yml`` to specify ``'>=1.0.0'`` for ``foo.baz``. - #. Finally release ``foo.bar`` as 1.0.0. - -* The dependencies between collections included in Ansible must be valid. If a dependency is violated, the involved collections must be pinned so that all dependencies are valid again. This means that the version numbers from the previous release are kept or only partially incremented so that the resulting set of versions has no invalid dependencies. - -* If a collection has a too strict dependency for a longer time, and forces another collection depended on to be held back, that collection will be removed from the next major Ansible release. What "longer time" means depends on when the next Ansible major release happens. If a dependent collection prevents a new major version of a collection it depends on to be included in the next major Ansible release, the dependent collection will be removed from that major release to avoid blocking the collection being depended on. - -* We strongly suggest that collections also test against the ``main`` branches of their dependencies to ensure that incompatibilities with future releases of these are detected as early as possible and can be resolved in time to avoid such problems. Collections depending on other collections must understand that they bear the risk of being removed when they do not ensure compatibility with the latest releases of their dependencies. - -* Collections included in Ansible must not depend on other collections except if they satisfy one of the following cases: - - #. They have a loose dependency on one (or more) major versions of other collections included in Ansible. For example, ``ansible.netcommon: >=1.0.0``, or ``ansible.netcommon: >=2.0.0, <3.0.0``. In case the collection depended on releases a new major version outside of this version range that will be included in the next major Ansible release, the dependent collection will be removed from the next major Ansible release. The cut-off date for this is feature freeze. - #. They are explicitly being allowed to do so by the Steering Committee. - -Examples --------- - -#. ``community.foo 1.2.0`` has a dependency on ``community.bar >= 1.0.0, < 1.3.0``. - - * Now ``community.bar`` creates a new release ``1.3.0``. When ``community.foo`` does not create a new release with a relaxed dependency, we have to include ``community.bar 1.2.x`` in the next Ansible release despite ``1.3.0`` being available. - * If ``community.foo`` does not relax its dependency on ``community.bar`` for some time, ``community.foo`` will be removed from the next Ansible major release. - * Unfortunately ``community.bar`` has to stay at ``1.2.x`` until either ``community.foo`` is removed (in the next major release), or loosens its requirements so that newer ``community.bar 1.3.z`` releases can be included. - -#. ``community.foonetwork`` depends on ``ansible.netcommon >= 2.0.0, <3.0.0``. - - * ``ansible.netcommon 4.0.0`` is released during this major Ansible release cycle. - * ``community.foonetwork`` either releases a new version before feature freeze of the next major Ansible release that allows depending on all ``ansible.netcommon 4.x.y`` releases, or it will be removed from the next major Ansible release. - -.. _coll_inclusion_reqs: - -Requirements for collections to be included in the Ansible Package -================================================================== - -To be included in the `ansible` package, collections must meet the following criteria: - -* :ref:`Development conventions `. -* `Collection requirements `_ (this document). - - * The `Collection Inclusion Criteria Checklist `_ covers most of the criteria from this document. -* :ref:`Ansible documentation format ` and the :ref:`style guide `. -* To pass the Ansible :ref:`sanity tests `. -* To have :ref:`unit `_and / or :ref:`integration tests ` according to the corresponding sections of this document. - - -Other requirements -=================== - -* After content is moved out of another currently included collection such as ``community.general`` or ``community.network`` OR a new collection satisfies all the requirements, add the collection to the ``ansible.in`` file in a corresponding directory of the `ansible-build-data repository `_. \ No newline at end of file diff --git a/docs/docsite/rst/community/collection_contributors/collection_reviewing.rst b/docs/docsite/rst/community/collection_contributors/collection_reviewing.rst deleted file mode 100644 index 4a379dcda62..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_reviewing.rst +++ /dev/null @@ -1,74 +0,0 @@ -.. _review_checklist: - -Review checklist for collection PRs -==================================== - -Use this section as a checklist reminder of items to review when you review a collection PR. - -Reviewing bug reports ----------------------- - -When users report bugs, verify the behavior reported. Remember always to be kind with your feedback. - -* Did the user make a mistake in the code they put in the Steps to Reproduce issue section? We often see user errors reported as bugs. -* Did the user assume an unexpected behavior? Ensure that the related documentation is clear. If not, the issue is useful to help us improve documentation. -* Is there a minimal reproducer? If not, ask the reporter to reduce the complexity to help pinpoint the issue. -* Is the issue a consequence of a misconfigured environment? -* If it seems to be a real bug, does the behaviour still exist in the most recent release or the development branch? -* Reproduce the bug, or if you do not have a suitable infrastructure, ask other contributors to reproduce the bug. - - -Reviewing suggested changes ---------------------------- - -When reviewing PRs, verify that the suggested changes do not: - -* Unnecessarily break backward compatibility. -* Bring more harm than value. -* Introduce non-idempotent solutions. -* Duplicate already existing features (inside or outside the collection). -* Violate the :ref:`Ansible development conventions `. - - -Other standards to check for in a PR include: - -* A pull request MUST NOT contain a mix of bug fixes and new features that are not tightly related. If yes, ask the author to split the pull request into separate PRs. -* If the pull request is not a documentation fix, it must include a :ref:`changelog fragment `. Check the format carefully as follows: - - * New modules and plugins (that are not jinja2 filter and test plugins) do not need changelog fragments. - * For jinja2 filter and test plugins, check out the `special syntax for changelog fragments `_. - * The changelog content contains useful information for end users of the collection. - -* If new files are added with the pull request, they follow the :ref:`coll_licensing_req`. -* The changes follow the :ref:`Ansible documentation standards ` and the :ref:`style_guide`. -* The changes follow the :ref:`Development conventions `. -* If a new plugin is added, it is one of the :ref:`allowed plugin types `. -* Documentation, examples, and return sections use FQCNs for the ``M(..)`` :ref:`format macros ` when referring to modules. -* Modules and plugins from ansible-core use ``ansible.builtin.`` as an FQCN prefix when mentioned. -* When a new option, module, plugin, or return value is added, the corresponding documentation or return sections use ``version_added:`` containing the *collection* version in which they will be first released. - - * This is typically the next minor release, sometimes the next major release. For example: if 2.7.5 is the current release, the next minor release will be 2.8.0, and the next major release will be 3.0.0). - -* FQCNs are used for ``extends_documentation_fragment:``, unless the author is referring to doc_fragments from ansible-core. -* New features have corresponding examples in the :ref:`examples_block`. -* Return values are documented in the :ref:`return_block`. - - -Review tests in the PR ----------------------- -Review the following if tests are applicable and possible to implement for the changes included in the PR: - - -* Where applicable, the pull request has :ref:`testing_integration` and :ref:`testing_units`. -* All changes are covered. For example, a bug case or a new option separately and in sensible combinations with other options. -* Integration tests cover ``check_mode`` if supported. -* Integration tests check the actual state of the system, not only what the module reports. For example, if the module actually changes a file, check that the file was changed by using the ``ansible.builtin.stat`` module.. -* Integration tests check return values, if applicable. - - -Review for merge commits and breaking changes ---------------------------------------------- - -* The pull request does not contain merge commits. See the GitHub warnings at the bottom of the pull request. If merge commits are present, ask the author to rebase the pull request branch. -* If the pull request contains breaking changes, ask the author and the collection maintainers if it really is needed, and if there is a way not to introduce breaking changes. If breaking changes are present, they MUST only appear in the next major release and MUST NOT appear in a minor or patch release. The only exception is breaking changes caused by security fixes that are absolutely necessary to fix the security issue. - diff --git a/docs/docsite/rst/community/collection_contributors/collection_test_pr_locally.rst b/docs/docsite/rst/community/collection_contributors/collection_test_pr_locally.rst deleted file mode 100644 index 7b01e2df8ce..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_test_pr_locally.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _collection_pr_test: - -**************************** -How to test a collection PR -**************************** - -Reviewers and issue authors can verify a PR fixes the reported bug by testing the PR locally. - -.. contents:: - :local: - -.. _collection_prepare_environment: - -Prepare your environment -======================== - -We assume that you use Linux as a work environment (you can use a virtual machine as well) and have ``git`` installed. - - -1. :ref:`Install Ansible ` or ansible-core. - -2. Create the following directories in your home directory: - - .. code:: bash - - mkdir -p ~/ansible_collections/NAMESPACE/COLLECTION_NAME - - For example, if the collection is ``community.general``: - - .. code:: bash - - mkdir -p ~/ansible_collections/community/general - - If the collection is ``ansible.posix``: - - .. code:: bash - - mkdir -p ~/ansible_collections/ansible/posix - - -3. Clone the forked repository from the author profile to the created path: - - .. code:: bash - - git clone https://github.com/AUTHOR_ACC/COLLECTION_REPO.git ~/ansible_collections/NAMESPACE/COLLECTION_NAME - -4. Go to the cloned repository. - - .. code:: bash - - cd ~/ansible_collections/NAMESPACE/COLLECTION_NAME - -5. Checkout the PR branch (it can be retrieved from the PR's page): - - .. code:: bash - - git checkout pr_branch - - -Test the Pull Request -===================== - -1. Include `~/ansible_collections` in `COLLECTIONS_PATHS`. See :ref:`COLLECTIONS_PATHS` for details. - -2. Run your playbook using the PR branch and verify the PR fixed the bug. - -3. Give feedback on the pull request or the linked issue(s). diff --git a/docs/docsite/rst/community/collection_contributors/collection_unit_tests.rst b/docs/docsite/rst/community/collection_contributors/collection_unit_tests.rst deleted file mode 100644 index 7a758c50155..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_unit_tests.rst +++ /dev/null @@ -1,162 +0,0 @@ - -.. _collection_unit_tests: - -****************************** -Add unit tests to a collection -****************************** - -This section describes all of the steps needed to add unit tests to a collection and how to run them locally using the ``ansible-test`` command. - -See :ref:`testing_units_modules` for more details. - -.. contents:: - :local: - -Understanding the purpose of unit tests -======================================== - -Unit tests ensure that a section of code (known as a ``unit``) meets its design requirements and behaves as intended. Some collections do not have unit tests but it does not mean they are not needed. - - -A ``unit`` is a function or method of a class used in a module or plugin. Unit tests verify that a function with a certain input returns the expected output. - -Unit tests should also verify when a function raises or handles exceptions. - -Ansible uses `pytest `_ as a testing framework. - -See :ref:`testing_units_modules` for complete details. - -Inclusion in the Ansible package :ref:`requires integration and/or unit tests ` You should have tests for your collection as well as for individual modules and plugins to make your code more reliable To learn how to get started with integration tests, see :ref:`collection_integration_tests`. - - -See :ref:`collection_prepare_local` to prepare your environment. - -.. _collection_unit_test_required: - -Determine if unit tests exist -============================= - -Ansible collection unit tests are located in the ``tests/units`` directory. - -The structure of the unit tests matches the structure of the code base, so the tests can reside in the ``tests/units/plugins/modules/`` and ``tests/units/plugins/module_utils`` directories. There can be sub-directories, if modules are organized by module groups. - -If you are adding unit tests for ``my_module`` for example, check to see if the tests already exist in the collection source tree with the path ``tests/units/plugins/modules/test_my_module.py``. - -Example of unit tests -===================== - -Let's assume that the following function is in ``my_module`` : - -.. code:: python - - def convert_to_supported(val): - """Convert unsupported types to appropriate.""" - if isinstance(val, decimal.Decimal): - return float(val) - - if isinstance(val, datetime.timedelta): - return str(val) - - if val == 42: - raise ValueError("This number is just too cool for us ;)") - - return val - -Unit tests for this function should, at a minimum, check the following: - -* If the function gets a ``Decimal`` argument, it returns a corresponding ``float`` value. -* If the function gets a ``timedelta`` argument, it returns a corresponding ``str`` value. -* If the function gets ``42`` as an argument, it raises a ``ValueError``. -* If the function gets an argument of any other type, it does nothing and returns the same value. - -To write these unit tests in collection is called ``community.mycollection``: - -1. If you already have your local environment :ref:`prepared `, go to the collection root directory. - - .. code:: bash - - cd ~/ansible_collection/community/mycollection - -2. Create a test file for ``my_module``. If the path does not exist, create it. - - .. code:: bash - - touch tests/units/plugins/modules/test_my_module.py - -3. Add the following code to the file: - - .. code:: python - - # -*- coding: utf-8 -*- - - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type - - from datetime import timedelta - from decimal import Decimal - - import pytest - - from ansible_collections.community.mycollection.plugins.modules.my_module import ( - convert_to_supported, - ) - - # We use the @pytest.mark.parametrize decorator to parametrize the function - # https://docs.pytest.org/en/latest/how-to/parametrize.html - # Simply put, the first element of each tuple will be passed to - # the test_convert_to_supported function as the test_input argument - # and the second element of each tuple will be passed as - # the expected argument. - # In the function's body, we use the assert statement to check - # if the convert_to_supported function given the test_input, - # returns what we expect. - @pytest.mark.parametrize('test_input, expected', [ - (timedelta(0, 43200), '12:00:00'), - (Decimal('1.01'), 1.01), - ('string', 'string'), - (None, None), - (1, 1), - ]) - def test_convert_to_supported(test_input, expected): - assert convert_to_supported(test_input) == expected - - def test_convert_to_supported_exception(): - with pytest.raises(ValueError, match=r"too cool"): - convert_to_supported(42) - - See :ref:`testing_units_modules` for examples on how to mock ``AnsibleModule`` objects, monkeypatch methods (``module.fail_json``, ``module.exit_json``), emulate API responses, and more. - -4. Run the tests using docker: - - .. code:: bash - - ansible-test units tests/unit/plugins/modules/test_my_module.py --docker - - -.. _collection_recommendation_unit: - -Recommendations on coverage -=========================== - -Use the following tips to organize your code and test coverage: - -* Make your functions simple. Small functions that do one thing with no or minimal side effects are easier to test. -* Test all possible behaviors of a function including exception related ones such as raising, catching and handling exceptions. -* When a function invokes the ``module.fail_json`` method, passed messages should also be checked. - -.. seealso:: - - :ref:`testing_units_modules` - Unit testing Ansible modules - :ref:`developing_testing` - Ansible Testing Guide - :ref:`collection_integration_tests` - Integration testing for collections - :ref:`testing_integration` - Integration tests guide - :ref:`testing_collections` - Testing collections - :ref:`testing_resource_modules` - Resource module integration tests - :ref:`collection_pr_test` - How to test a pull request locally diff --git a/docs/docsite/rst/community/collection_contributors/test_index.rst b/docs/docsite/rst/community/collection_contributors/test_index.rst deleted file mode 100644 index 19a61422cf3..00000000000 --- a/docs/docsite/rst/community/collection_contributors/test_index.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. _testing_collections_guide: - -********************************************** -Testing Collection Contributions -********************************************** - -This section focuses on the different tests a contributor should run on their collection PR. - -.. toctree:: - :maxdepth: 1 - - collection_test_pr_locally - collection_unit_tests - collection_integration_tests diff --git a/docs/docsite/rst/community/collection_development_process.rst b/docs/docsite/rst/community/collection_development_process.rst deleted file mode 100644 index 3c2f609cce7..00000000000 --- a/docs/docsite/rst/community/collection_development_process.rst +++ /dev/null @@ -1,255 +0,0 @@ -.. _collection_development_process: - -****************************************** -The Ansible Collections Development Cycle -****************************************** - -Ansible developers (including community contributors) add new features, fix bugs, and update code in many different repositories. These repositories contain plugins and modules that enable Ansible to execute specific tasks, like adding a user to a particular database or configuring a particular network device. These repositories contain the source code for collections. - -Development on collections occurs at the macro and micro levels. Each collection has its own macro development cycle. For more information on the collections development cycle, see :ref:`contributing_maintained_collections`. The micro-level lifecycle of a PR is similar in collections and in ``ansible-core``. - -.. contents:: - :local: - - -Macro development: roadmaps, releases, and projects -===================================================================== - -If you want to follow the conversation about what features will be added to the Ansible package for upcoming releases and what bugs are being fixed, you can watch these resources: - -* the :ref:`roadmaps` -* the :ref:`Ansible Release Schedule ` -* the `Ansible Community Working Group `_ . - -Micro development: the lifecycle of a PR -======================================== - -If you want to contribute a feature or fix a bug in a collection, you must open a **pull request** ("PR" for short). GitHub provides a great overview of `how the pull request process works `_ in general. The ultimate goal of any pull request is to get merged and become part of a collection. Each collection has its own contributor guidelines so please check there for specific details. - -Here's an overview of the PR lifecycle: - -* :ref:`Contributor opens a PR ` -* CI runs the test suite -* Developers, maintainers, community review the PR -* Contributor addresses any feedback from reviewers -* Developers, maintainers, community re-review -* PR merged or closed - - -Making your PR merge-worthy -=========================== - -We do not merge every PR. See :ref:`collection_quickstart` for tips to make your PR useful, attractive, and merge-worthy. - -.. _collection_changelog_fragments: - -Creating changelog fragments ------------------------------ - -Most changelogs should emphasize the impact of the change on the end user of the feature or collection, unless the change impacts developers directly. Consider what the user needs to know about this change and write the changelog to convey that detail. - -Changelogs help users and developers keep up with changes to Ansible collections. Many collections build changelogs for each release from fragments. For collections that use this model, you **must** add a changelog fragment to any PR that changes functionality or fixes a bug. - -You do not need a changelog fragment for PRs that: - -* add new modules and plugins, because Ansible tooling does that automatically; -* contain only documentation changes. - -.. note:: - Some collections require a changelog fragment for every pull request. They use the ``trivial:`` section for entries mentioned above that will be skipped when building a release changelog. - - -More precisely: - -* Every bugfix PR must have a changelog fragment. The only exception are fixes to a change that has not yet been included in a release. -* Every feature PR must have a changelog fragment. -* New modules and plugins (including jinja2 filter and test plugins) must have ``version_added`` entries set correctly in their documentation, and do not need a changelog fragment. The tooling detects new modules and plugins by their ``version_added`` values and announces them in the next release's changelog automatically. - -We build short summary changelogs for minor releases as well as for major releases. If you backport a bugfix, include a changelog fragment with the backport PR. - -.. _collection_changelogs_how_to_format: - -Creating a changelog fragment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -A basic changelog fragment is a ``.yaml`` or ``.yml`` file placed in the ``changelogs/fragments/`` directory. Each file contains a yaml dict with keys like ``bugfixes`` or ``major_changes`` followed by a list of changelog entries of bugfixes or features. Each changelog entry is rst embedded inside of the yaml file which means that certain constructs would need to be escaped so they can be interpreted by rst and not by yaml (or escaped for both yaml and rst if you prefer). Each PR **must** use a new fragment file rather than adding to an existing one, so we can trace the change back to the PR that introduced it. - -PRs which add a new module or plugin do not necessarily need a changelog fragment. See :ref:`community_changelogs`. Also see :ref:`changelogs_how_to_format` for the precise format changelog fragments should have. - -To create a changelog entry, create a new file with a unique name in the ``changelogs/fragments/`` directory of the corresponding repository. The file name should include the PR number and a description of the change. It must end with the file extension ``.yaml`` or ``.yml``. For example: ``40696-user-backup-shadow-file.yaml`` - -A single changelog fragment may contain multiple sections but most will only contain one section. The toplevel keys (bugfixes, major_changes, and so on) are defined in the `config file `_ for our `release note tool `_. Here are the valid sections and a description of each: - -**breaking_changes** - MUST include changes that break existing playbooks or roles. This includes any change to existing behavior that forces users to update tasks. Breaking changes means the user MUST make a change when they update. Breaking changes MUST only happen in a major release of the collection. Write in present tense and clearly describe the new behavior that the end user must now follow. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - breaking_changes: - - ec2_instance - instance wait for state behavior no longer waits for the instance monitoring status to become OK when launching a new instance. If plays require the old behavior, the action will need to specify ``state: started`` (https://github.com/ansible-collections/amazon.aws/pull/481). - - -**major_changes** - Major changes to ansible-core or a collection. SHOULD NOT include individual module or plugin changes. MUST include non-breaking changes that impact all or most of a collection (for example, updates to support a new SDK version across the collection). Major changes mean the user can CHOOSE to make a change when they update but do not have to. Could be used to announce an important upcoming EOL or breaking change in a future release. (ideally 6 months in advance, if known. See `this example `_). Write in present tense and describe what is new. Optionally, include a 'Previously..." sentence to help the user identify where old behavior should now change. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - major_changes: - - bitbucket_* modules - client_id is no longer marked as ``no_log=true``. If you relied on its value not showing up in logs and output, mark the whole tasks with ``no_log: true`` (https://github.com/ansible-collections/community.general/pull/2045). - -**minor_changes** - Minor changes to ansible-core, modules, or plugins. This includes new parameters added to modules, or non-breaking behavior changes to existing parameters, such as adding new values to choices[]. Minor changes are enhancements, not bug fixes. Write in present tense. - - .. code-block:: yaml - - minor_changes: - - nmcli - adds ``routes6`` and ``route_metric6`` parameters for supporting IPv6 routes (https://github.com/ansible-collections/community.general/issues/4059). - - -**deprecated_features** - Features that have been deprecated and are scheduled for removal in a future release. Write in past tense. Include an alternative, where available, for the feature being deprecated. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - deprecated_features: - - mail callback plugin - not specifying ``sender`` is deprecated and will be disallowed in ``community.general`` 6.0.0 (https://github.com/ansible-collections/community.general/pull/4140). - - -**removed_features** - Features that were previously deprecated and are now removed. Write in past tense. Include an alternative, where available, for the feature being deprecated. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - removed_features: - - acme_account_facts - the deprecated redirect has been removed. Use ``community.crypto.acme_account_info`` instead (https://github.com/ansible-collections/community.crypto/pull/290). - - -**security_fixes** - Fixes that address CVEs or resolve security concerns. MUST use security_fixes for any CVEs. Write in present tense. Include links to CVE information. - - .. code-block:: yaml - - security_fixes: - - win_psexec - ensure password is masked in ``psexec_``command return result (https://github.com/ansible-collections/community.windows/issues/43). - - -**bugfixes** - Fixes that resolve issues. SHOULD NOT be used for minor enhancements (use ``minor_change`` instead). Write in past tense to describe the problem and present tense to describe the fix. - - .. code-block:: yaml - - bugfixes: - - apt_repository - fix crash caused by a timeout. The ``cache.update()`` was raising an ``IOError`` because of a timeout in ``apt update`` (https://github.com/ansible/ansible/issues/51995). - - -**known_issues** - Known issues that are currently not fixed or will not be fixed. Write in present tense to describe the problem and in imperative tense to describe any available workaround. - - .. code-block:: yaml - - known_issues: - - idrac_user - module may error out with the message ``unable to perform the import or export operation`` because there are pending attribute changes or a configuration job is in progress. Wait for the job to complete and run the task again.(https://github.com/dell/dellemc-openmanage-ansible-modules/pull/303). - - -**trivial** - Changes where a formal release changelog entry isn't required. ``trivial`` changelog fragments are excluded from the published changelog output and may be used for changes such as housekeeping, documentation and test only changes. - You can use ``trivial`` for collections that require a changelog fragment for each pull request. - - .. code-block:: yaml - - trivial: - - aws_ec2 - fix broken integration test (https://github.com/ansible-collections/amazon.aws/pull/1269). - - -Each changelog entry must contain a link to its issue between parentheses at the end. If there is no corresponding issue, the entry must contain a link to the PR itself. - -Most changelog entries are ``bugfixes`` or ``minor_changes``. - - -Changelog fragment entry format -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When writing a changelog entry, use the following format: - -.. code-block:: yaml - - - scope - description starting with a lowercase letter and ending with a period at the very end. Multiple sentences are allowed (https://github.com/reference/to/an/issue or, if there is no issue, reference to a pull request itself). - -The scope is usually a module or plugin name or group of modules or plugins, for example, ``lookup plugins``. While module names can (and should) be mentioned directly (``foo_module``), plugin names should always be followed by the type (``foo inventory plugin``). - -For changes that are not really scoped (for example, which affect a whole collection), use the following format: - -.. code-block:: yaml - - - Description starting with an uppercase letter and ending with a dot at the very end. Multiple sentences are allowed (https://github.com/reference/to/an/issue or, if there is no issue, reference to a pull request itself). - - -Here are some examples: - -.. code-block:: yaml - - bugfixes: - - apt_repository - fix crash caused by ``cache.update()`` raising an ``IOError`` - due to a timeout in ``apt update`` (https://github.com/ansible/ansible/issues/51995). - -.. code-block:: yaml - - minor_changes: - - lineinfile - add warning when using an empty regexp (https://github.com/ansible/ansible/issues/29443). - -.. code-block:: yaml - - bugfixes: - - copy - the module was attempting to change the mode of files for - remote_src=True even if mode was not set as a parameter. This failed on - filesystems which do not have permission bits (https://github.com/ansible/ansible/issues/29444). - -You can find more example changelog fragments in the `changelog directory `_ for the community.general development branch. - -After you have written the changelog fragment for your PR, commit the file and include it with the pull request. - - -Changelog fragment entry format for new jinja2 plugins, roles, and playbooks -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -While new modules and plugins that are not jinja2 filter or test plugins are mentioned automatically in the generated changelog, jinja2 filter and test plugins, roles, and playbooks are not. To make sure they are mentioned, a changelog fragment in a specific format is needed: - -.. code-block:: yaml - - # A new jinja2 filter plugin: - add plugin.filter: - - # The following needs to be the name of the filter itself, not of the file - # the filter is included in! - name: to_time_unit - # The description should be in the same format as short_description for - # other plugins and modules: it should start with an upper-case letter and - # not have a period at the end. - description: Converts a time expression to a given unit - - # A new jinja2 test plugin: - add plugin.test: - - # The following needs to be the name of the test itself, not of the file - # the test is included in! - name: asn1time - # The description should be in the same format as short_description for - # other plugins and modules: it should start with an upper-case letter and - # not have a period at the end. - description: Check whether the given string is an ASN.1 time - - # A new role: - add object.role: - - # This should be the short (non-FQCN) name of the role. - name: nginx - # The description should be in the same format as short_description for - # plugins and modules: it should start with an upper-case letter and - # not have a period at the end. - description: A nginx installation role - - # A new playbook: - add object.playbook: - - # This should be the short (non-FQCN) name of the playbook. - name: wipe_server - # The description should be in the same format as short_description for - # plugins and modules: it should start with an upper-case letter and - # not have a period at the end. - description: Wipes a server diff --git a/docs/docsite/rst/community/committer_guidelines.rst b/docs/docsite/rst/community/committer_guidelines.rst deleted file mode 100644 index 7067a5a266c..00000000000 --- a/docs/docsite/rst/community/committer_guidelines.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. _community_committer_guidelines: - -********************* -Committers Guidelines -********************* - -These are the guidelines for people with commit privileges on the repositories in the ansible and ansible-collections GitHub organizations. - -Committers of `Ansible-core `_ are necessarily Red Hat employees acting as members of the Ansible Core team. Committers of `Ansible collections `_ are members of the community or Ansible Engineering. Please read the guidelines before you commit. - -These guidelines apply to everyone. At the same time, this is NOT a process document. So just use good judgment. You have been given commit access because we trust your judgment. - -That said, use the trust wisely. - -If you abuse the trust and break components and builds, and so on, the trust level falls and you may be asked not to commit or you may lose your commit privileges. - -Features, high-level design, and roadmap of ansible-core -======================================================== - -As a core team member, you are an integral part of the team that develops the :ref:`roadmap `. Please be engaged, and push for the features and fixes that you want to see. Also keep in mind that Red Hat, as a company, will commit to certain features, fixes, APIs, and so on, for various releases. Red Hat, the company, and the Ansible team must get these changes completed and released as scheduled. Obligations to users, the community, and customers must come first. Because of these commitments, a feature you want to develop yourself may not get into a release if it affects a lot of other parts within Ansible. - -Any other new features and changes to high level design should go through the proposal process (TBD), to ensure the community and core team have had a chance to review the idea and approve it. The core team has sole responsibility for merging new features based on proposals to `Ansible-core `_. - - -Features, high-level design, and roadmap of Ansible collections -=============================================================== - -Collections maintainers define features, high-level design, and roadmap of the collections themselves and are responsible for merging new features to `Ansible collections `_ based on proposals discussed with their communities. - -Our workflow on GitHub -====================== - -As a committer, you may already know this, but our workflow forms a lot of our team policies. Please ensure you are aware of the following workflow steps: - -* Fork the repository upon which you want to do some work to your own personal repository -* Work on the specific branch upon which you need to commit -* Create a pull request back to the upstream repository and tag the people you would like to review; assign someone as the primary "owner" of your pull request -* Adjust code as necessary based on the comments provided -* Ask someone from the repository committers to do a final review and merge - -Addendum to workflow for committers: ------------------------------------- - -The Core Team is aware that this can be a difficult process at times. Sometimes, the team breaks the rules by making direct commits or merging their own pull requests. This section is a set of guidelines. If you are changing a comma in documentation, or making a very minor change, you can use your best judgement. This is another trust thing. The process is critical for any major change, but for little things or getting something done quickly, use your best judgement and make sure people on the team are aware of your work. - -Roles on Core -============= -* Core committers: Fine to do pull requests for most things, but we should have a timebox. Hanging pull requests may merge on the judgement of these developers. -* :ref:`Module maintainers `: Module maintainers own specific modules and have indirect commit access through the current module pull request mechanisms. -* :ref:`Collection maintainers `: Collection maintainers own specific collections and have commit access to them. Each collection can set its own rules for contributions. - -.. _committer_general_rules: - -General rules -============= -Individuals with direct commit access are entrusted with powers that allow them to do a broad variety of things--probably more than we can write down. Rather than rules, treat these as general *guidelines*, individuals with this power are expected to use their best judgement. - -* Do NOT - - - Commit directly. - - Merge your own pull requests. Someone else should have a chance to review and approve the pull request merge. If you are a Core Committer, you have a small amount of leeway here for very minor changes. - - Forget about alternate environments. Consider the alternatives--yes, people have bad environments, but they are the ones who need us the most. - - Drag your community team members down. Discuss the technical merits of any pull requests you review. Avoid negativity and personal comments. For more guidance on being a good community member, read our :ref:`code_of_conduct`. - - Forget about the maintenance burden. High-maintenance features may not be worth adding. - - Break playbooks. Always keep backwards compatibility in mind. - - Forget to keep it simple. Complexity breeds all kinds of problems. - -* Do - - - Squash, avoid merges whenever possible, use GitHub's squash commits or cherry pick if needed (bisect thanks you). - - Be active. Committers who have no activity on the project (through merges, triage, commits, and so on) will have their permissions suspended. - - Consider backwards compatibility (goes back to "do not break existing playbooks"). - - Write :ref:`tests` and be sure that other's pull requests you are reviewing are covered well. Pull requests with tests are looked at with more priority than pull requests without tests that should have them included. While not all changes require tests, be sure to add them for new features, bug fixes, and functionality changes. - - Discuss with other committers, specially when you are unsure of something. - - Document! If your pull request is a new feature or a change to behavior, make sure you have updated all associated documentation or have notified the right people to do so. It also helps to add the version of ``ansible-core`` or ``collection`` against which this documentation is compatible (to avoid confusion between stable and devel docs, for backwards compatibility, and so on). - - Consider scope, sometimes a fix can be generalized. - - Keep it simple, then things are maintainable, debuggable, and intelligible. - -Committers are expected to continue to follow the same community and contribution guidelines followed by the rest of the Ansible community. diff --git a/docs/docsite/rst/community/communication.rst b/docs/docsite/rst/community/communication.rst deleted file mode 100644 index 14adfd6894b..00000000000 --- a/docs/docsite/rst/community/communication.rst +++ /dev/null @@ -1,180 +0,0 @@ -.. _communication: - -***************************************** -Communicating with the Ansible community -***************************************** - -.. contents:: - :local: - -Code of Conduct -=============== - -All communication and interactions in the Ansible Community are governed by our :ref:`code_of_conduct`. Please read and understand it! - -Asking questions over email -=========================== - -If you want to keep up with Ansible news, need help, or have a question, you can use one of the Ansible mailing lists. Each list covers a particular topic. Read the descriptions here to find the best list for your question. - -Your first post to the mailing list will be moderated (to reduce spam), so please allow up to a day or so for your first post to appear. - -* `Ansible Announce list `_ is a read-only list that shares information about new releases of Ansible, and also rare infrequent event information, such as announcements about an upcoming AnsibleFest, which is our official conference series. Worth subscribing to! -* `Ansible AWX List `_ is for `Ansible AWX `_ -* `Ansible Development List `_ is for questions about developing Ansible modules (mostly in Python), fixing bugs in the Ansible core code, asking about prospective feature design, or discussions about extending Ansible or features in progress. -* `Ansible Outreach List `_ help with promoting Ansible and `Ansible Meetups `_ -* `Ansible Project List `_ is for sharing Ansible tips, answering questions about playbooks and roles, and general user discussion. -* `Molecule Discussions `_ is designed to aid with the development and testing of Ansible roles with Molecule. - -The Ansible mailing lists are hosted on Google, but you do not need a Google account to subscribe. To subscribe to a group from a non-Google account, send an email to the subscription address requesting the subscription. For example: ``ansible-devel+subscribe@googlegroups.com``. - -.. _communication_irc: - -Real-time chat -============== - -For real-time interactions, conversations in the Ansible community happen over two chat protocols: Matrix and IRC. We maintain a bridge between Matrix and IRC, so you can choose whichever protocol you prefer. All channels exist in both places. Join a channel any time to ask questions, participate in a Working Group meeting, or just say hello. - -Ansible community on Matrix ---------------------------- - -To join the community using Matrix, you need two things: - -* a Matrix account (from `Matrix.org `_ or any other Matrix homeserver) -* a `Matrix client `_ (we recommend `Element Webchat `_) - -The Ansible community maintains its own Matrix homeserver at ``ansible.im``, however public registration is currently unavailable. - -Matrix chat supports: - -* persistence (when you log on, you see all messages since you last logged off) -* edits (Lets you fix typos and so on. **NOTE** Each edit you make on Matrix re-sends the message to IRC. Please try to avoid multiple edits!) -* replies to individual users -* reactions/emojis -* bridging to IRC -* no line limits -* images - -The room links in the :ref:`general_channels` or in the :ref:`working_group_list` list will take you directly to the relevant rooms. - -If there is no appropriate room for your community, please create it. - -For more information, see the community-hosted `Matrix FAQ `_. - -You can add Matrix shields to your repository's ``README.md`` using the shield in the `community-topics `_ repository as a template. - -Ansible community on IRC ------------------------- - -The Ansible community maintains several IRC channels on `irc.libera.chat `_. To join the community using IRC, you need one thing: - -* an IRC client - -IRC chat supports: - -* no persistence (you only see messages when you are logged on unless you add a bouncer) -* simple text interface -* bridging from Matrix - -Our IRC channels may require you to register your IRC nickname. If you receive an error when you connect or when posting a message, see `libera.chat's Nickname Registration guide `_ for instructions. To find all ``ansible`` specific channels on the libera.chat network, use the following command in your IRC client: - -.. code-block:: text - - /msg alis LIST #ansible* -min 5 - -as described in the `libera.chat docs `_. - -Our channels record history on the Matrix side. The channel history can be viewed in a browser - all channels will report an appropriate link to ``chat.ansible.im`` in their Chanserv entrymsg upon joining the room. Alternatively, a URL of the form ``https://chat.ansible.im/#/room/# {IRC channel name}:libera.chat`` will also work, for example - for the #ansible-docs channel it would be `https://app.element.io/#/room/#ansible-docs:libera.chat`. - -.. _general_channels: - -General channels ----------------- - -The clickable links will take you directly to the relevant Matrix room in your browser; room/channel information is also given for use in other clients: - -- `Community social room and posting news for the Bullhorn newsletter `_ - ``Matrix: #social:ansible.com | IRC: #ansible-social`` -- `General usage and support questions `_ - ``Matrix: #users:ansible.com | IRC: #ansible`` -- `Discussions on developer topics and code related to features or bugs `_ - ``Matrix: #devel:ansible.com | IRC: #ansible-devel`` -- `Discussions on community and collections related topics `_ - ``Matrix: #community:ansible.com | IRC: #ansible-community`` -- `For public community meetings `_ - ``Matrix: #meeting:ansible.im | IRC: #ansible-meeting`` - - We will generally announce these on one or more of the above mailing lists. See the `meeting schedule and agenda page `_ - -.. _working_group_list: - -Working groups --------------- - -Many of our community `Working Groups `_ meet in chat. If you want to get involved in a working group, join the Matrix room or IRC channel where it meets or comment on the agenda. - -- `AAP Configuration as Code `_ - Matrix: `#aap_config_as_code:ansible.com `_ -- `Amazon (AWS) Working Group `_ - Matrix: `#aws:ansible.com `_ | IRC: ``#ansible-aws`` -- `AWX Working Group `_ - Matrix: `#awx:ansible.com `_ | IRC: ``#ansible-awx`` -- `Azure Working Group `_ - Matrix: `#azure:ansible.com `_ | IRC: ``#ansible-azure`` -- `Community Working Group `_ (including Meetups) - Matrix: `#community:ansible.com `_ | IRC: ``#ansible-community`` -- `Container Working Group `_ - Matrix: `#container:ansible.com `_ | IRC: ``#ansible-container`` -- `Contributor Experience Working Group `_ - Matrix: `#community:ansible.com `_ | IRC: ``#ansible-community`` -- `DigitalOcean Working Group `_ - Matrix: `#digitalocean:ansible.im `_ | IRC: ``#ansible-digitalocean`` -- `Diversity Working Group `_ - Matrix: `#diversity:ansible.com `_ | IRC: ``#ansible-diversity`` -- `Docker Working Group `_ - Matrix: `#devel:ansible.com `_ | IRC: ``#ansible-devel`` -- `Documentation Working Group `_ - Matrix: `#docs:ansible.com `_ | IRC: ``#ansible-docs`` -- `Galaxy Working Group `_ - Matrix: `#galaxy:ansible.com `_ | IRC: ``#ansible-galaxy`` -- `JBoss Working Group `_ - Matrix: `#jboss:ansible.com `_ | IRC: ``#ansible-jboss`` -- `Kubernetes Working Group `_ - Matrix: `#kubernetes:ansible.com `_ | IRC: ``#ansible-kubernetes`` -- `Linode Working Group `_ - Matrix: `#linode:ansible.com `_ | IRC: ``#ansible-linode`` -- `Molecule Working Group `_ (`testing platform for Ansible playbooks and roles `_) - Matrix: `#molecule:ansible.im `_ | IRC: ``#ansible-molecule`` -- `MySQL Working Group `_ - Matrix: `#mysql:ansible.com `_ -- `Network Working Group `_ - Matrix: `#network:ansible.com `_ | IRC: ``#ansible-network`` -- `PostgreSQL Working Group `_ - Matrix: `#postgresql:ansible.com `_ -- `Remote Management Working Group `_ - Matrix: `#devel:ansible.com `_ | IRC: ``#ansible-devel`` -- `Security Automation Working Group `_ - Matrix: `#security-automation:ansible.com `_ | IRC: ``#ansible-security`` -- `Storage Working Group `_ - Matrix: `#storage:ansible.com `_ | IRC: ``#ansible-storage`` -- `VMware Working Group `_ - Matrix: `#vmware:ansible.com `_ | IRC: ``#ansible-vmware`` -- `Windows Working Group `_ - Matrix: `#windows:ansible.com `_ | IRC: ``#ansible-windows`` -- `Ansible developer tools Group `_ - Matrix: `#devtools:ansible.com `_ | IRC: ``#ansible-devtools`` - -Want to `form a new Working Group `_? - -Regional and Language-specific channels ---------------------------------------- - -- Comunidad Ansible en español - Matrix: `#espanol:ansible.im `_ | IRC: ``#ansible-es`` -- Communauté française d'Ansible - Matrix: `#francais:ansible.im `_ | IRC: ``#ansible-fr`` -- Communauté suisse d'Ansible - Matrix: `#suisse:ansible.im `_ | IRC: ``#ansible-zh`` -- European Ansible Community - Matrix: `#europe:ansible.im `_ | IRC: ``#ansible-eu`` - -Meetings on chat ----------------- - -The Ansible community holds regular meetings on various topics on Matrix/IRC, and anyone who is interested is invited to participate. For more information about Ansible meetings, consult the `meeting schedule and agenda page `_. - -Ansible Community Topics -======================== - -The `Ansible Community Steering Committee `_ uses the `community-topics repository `_ to asynchronously discuss with the Community and vote on Community topics in corresponding issues. - -Create a new issue in the `repository `_ if you want to discuss an idea that impacts any of the following: - -* Ansible Community -* Community collection best practices and `requirements `_ -* `Community collection inclusion policy `_ -* `The Community governance `_ -* Other proposals of importance that need the Committee or overall Ansible community attention - -Ansible Automation Platform support questions -============================================= - -Red Hat Ansible `Automation Platform `_ is a subscription that contains support, certified content, and tooling for Ansible including content management, a controller, UI and REST API. - -If you have a question about Ansible Automation Platform, visit `Red Hat support `_ rather than using a chat channel or the general project mailing list. - -The Bullhorn -============ - -**The Bullhorn** is our newsletter for the Ansible contributor community. Please `subscribe `_ to receive it. - -If you have any content you would like to share, please `contribute/suggest it `_ for upcoming releases. - -If you have any questions, please reach out to us at ``the-bullhorn@redhat.com``. - -Read past issues on the official Bullhorn's `wiki page `_. diff --git a/docs/docsite/rst/community/contributing_maintained_collections.rst b/docs/docsite/rst/community/contributing_maintained_collections.rst deleted file mode 100644 index f7c0d1d9168..00000000000 --- a/docs/docsite/rst/community/contributing_maintained_collections.rst +++ /dev/null @@ -1,304 +0,0 @@ - -.. _contributing_maintained_collections: - -*********************************************** -Contributing to Ansible-maintained Collections -*********************************************** - -The Ansible team welcomes community contributions to the collections maintained by Red Hat Ansible Engineering. This section describes how you can open issues and create PRs with the required testing before your PR can be merged. - -.. contents:: - :local: - -Ansible-maintained collections -================================= - -The following table shows: - -* **Ansible-maintained collection** - Click the link to the collection on Galaxy, then click the ``repo`` button in Galaxy to find the GitHub repository for this collection. -* **Related community collection** - Collection that holds community-created content (modules, roles, and so on) that may also be of interest to a user of the Ansible-maintained collection. You can, for example, add new modules to the community collection as a technical preview before the content is moved to the Ansible-maintained collection. -* **Sponsor** - Working group that manages the collections. You can join the meetings to discuss important proposed changes and enhancements to the collections. -* **Test requirements** - Testing required for any new or changed content for the Ansible-maintained collection. -* **Developer details** - Describes whether the Ansible-maintained collection accepts direct community issues and PRs for existing collection content, as well as more specific developer guidelines based on the collection type. - - -.. _ansible-collection-table: - -.. raw:: html - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Collection detailsTest requirements: Ansible collectionsDeveloper details
    Ansible collectionRelated community collectionSponsorSanityUnitIntegrationCI PlatformOpen to PRs*Guidelines
    amazon.awscommunity.awsAWS✓****✓Zuul✓AWS guide
    ansible.netcommon***community.networkNetwork✓✓✓Zuul✓Network guide
    ansible.posixcommunity.generalLinux✓Zuul✓Developer guide
    ansible.windowscommunity.windowsWindows✓✓****✓Azure Pipelines and Zuul✓Windows guide
    arista.eoscommunity.networkNetwork✓✓✓Zuul✓Network guide
    cisco.asacommunity.asaSecurity✓✓✓Zuul✓Developer guide
    cisco.ioscommunity.networkNetwork✓✓✓Zuul✓Network guide
    cisco.iosxrcommunity.networkNetwork✓✓✓Zuul✓Network guide
    cisco.nxoscommunity.networkNetwork✓✓✓Zuul✓Network guide
    ibm.qradarcommunity.qradarSecurity✓✓Zuul✓Developer guide
    junipernetworks.junoscommunity.networkNetwork✓✓✓Zuul✓Network guide
    kubernetes.corekubernetes.coreKubernetes✓✓✓GitHub Actions✓
    redhat.openshiftcommunity.okdKubernetes✓✓✓GitHub Actions✓
    openvswitch.openvswitchcommunity.networkNetwork✓✓✓Zuul✓Network guide
    splunk.escommunity.esSecurity✓✓Zuul✓Developer guide
    vyos.vyoscommunity.networkNetwork✓✓✓Zuul✓Network guide
    vmware.vmware_restvmware.vmware_restVMware✓✓✓Zuul✓VMware REST guide
    - - -.. note:: - - \* A ✓ under **Open to PRs** means the collection welcomes GitHub issues and PRs for any changes to existing collection content (plugins, roles, and so on). - - \*\* Integration tests are required and unit tests are welcomed but not required for the AWS collections. An exception to this is made in cases where integration tests are logistically not feasible due to external requirements. An example of this is AWS Direct Connect, as this service can not be functionally tested without the establishment of network peering connections. Unit tests are therefore required for modules that interact with AWS Direct Connect. Exceptions to ``amazon.aws`` must be approved by Red Hat, and exceptions to ``community.aws`` must be approved by the AWS community. - - \*\*\* ``ansible.netcommon`` contains all foundational components for enabling many network and security :ref:`platform ` collections. It contains all connection and filter plugins required, and installs as a dependency when you install the platform collection. - - \*\*\*\* Unit tests for Windows PowerShell modules are an exception to testing, but unit tests are valid and required for the remainder of the collection, including Ansible-side plugins. - - -.. _which_collection: - -Deciding where your contribution belongs -========================================= - -We welcome contributions to Ansible-maintained collections. Because these collections are part of a downstream supported Red Hat product, the criteria for contribution, testing, and release may be higher than other community collections. The related community collections (such as ``community.general`` and ``community.network``) have less-stringent requirements and are a great place for new functionality that may become part of the Ansible-maintained collection in a future release. - -The following scenarios use the ``arista.eos`` to help explain when to contribute to the Ansible-maintained collection, and when to propose your change or idea to the related community collection: - - -1. You want to fix a problem in the ``arista.eos`` Ansible-maintained collection. Create the PR directly in the `arista.eos collection GitHub repository `_. Apply all the :ref:`merge requirements `. - -2. You want to add a new Ansible module for Arista. Your options are one of the following: - - * Propose a new module in the ``arista.eos`` collection (requires approval from Arista and Red Hat). - * Propose a new collection in the ``arista`` namespace (requires approval from Arista and Red Hat). - * Propose a new module in the ``community.network`` collection (requires network community approval). - * Place your new module in a collection in your own namespace (no approvals required). - - -Most new content should go into either a related community collection or your own collection first so that is well established in the community before you can propose adding it to the ``arista`` namespace, where inclusion and maintenance criteria are much higher. - - -.. _ansible_collection_merge_requirements: - -Requirements to merge your PR -============================== - -Your PR must meet the following requirements before it can merge into an Ansible-maintained collection: - - -#. The PR is in the intended scope of the collection. Communicate with the appropriate Ansible sponsor listed in the :ref:`Ansible-maintained collection table ` for help. -#. For network and security domains, the PR follows the :ref:`resource module development principles `. -#. Passes :ref:`sanity tests and tox `. -#. Passes unit, and integration tests, as listed in the :ref:`Ansible-maintained collection table ` and described in :ref:`testing_resource_modules`. -#. Follows Ansible guidelines. See :ref:`developing_modules` and :ref:`developing_collections`. -#. Addresses all review comments. -#. Includes an appropriate :ref:`changelog `. diff --git a/docs/docsite/rst/community/contributions.rst b/docs/docsite/rst/community/contributions.rst deleted file mode 100644 index e3b3eb8c518..00000000000 --- a/docs/docsite/rst/community/contributions.rst +++ /dev/null @@ -1,29 +0,0 @@ -.. _community_contributions: - -******************************** -ansible-core Contributors Guide -******************************** - -.. toctree:: - :maxdepth: 2 - - reporting_bugs_and_features - documentation_contributions - development_process - other_tools_and_programs - - -If you have a specific Ansible interest or expertise (for example, VMware, Linode, and so on, consider joining a :ref:`working group `. - -Working with the Ansible repo -============================= - -* I want to make my first code changes to a collection or to ``ansible-core``. How do I :ref:`set up my Python development environment `? -* I would like to get more efficient as a developer. How can I find :ref:`editors, linters, and other tools ` that will support my Ansible development efforts? -* I want my code to meet Ansible's guidelines. Where can I find guidance on :ref:`coding in Ansible `? -* I would like to connect Ansible to a new API or other resource. How do I :ref:`create a collection `? -* My pull request is marked ``needs_rebase``. How do I :ref:`rebase my PR `? -* I am using an older version of Ansible and want a bug fixed in my version that has already been fixed on the ``devel`` branch. How do I :ref:`backport a bugfix PR `? -* I have an open pull request with a failing test. How do I learn about Ansible's :ref:`testing (CI) process `? -* I am ready to step up as a collection maintainer. What are the :ref:`guidelines for maintainers `? -* A module in a collection I maintain is obsolete. How do I :ref:`deprecate a module `? diff --git a/docs/docsite/rst/community/contributions_collections.rst b/docs/docsite/rst/community/contributions_collections.rst deleted file mode 100644 index 7b1aad4c6c0..00000000000 --- a/docs/docsite/rst/community/contributions_collections.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. _collections_contributions: - -************************************* -Ansible Collections Contributor Guide -************************************* - -.. toctree:: - :maxdepth: 2 - - collection_development_process - reporting_collections - create_pr_quick_start - collection_contributors/test_index - collection_contributors/collection_reviewing - collection_contributors/collection_requirements - maintainers - contributing_maintained_collections - steering/steering_index - documentation_contributions - other_tools_and_programs - - - -If you have a specific Ansible interest or expertise (for example, VMware, Linode, and so on, consider joining a :ref:`working group `. - -Working with the Ansible collection repositories -================================================= - -* How can I find :ref:`editors, linters, and other tools ` that will support my Ansible development efforts? -* Where can I find guidance on :ref:`coding in Ansible `? -* How do I :ref:`create a collection `? -* How do I :ref:`rebase my PR `? -* How do I learn about Ansible's :ref:`testing (CI) process `? -* How do I :ref:`deprecate a module `? -* See `Collection developer tutorials `_ for a quick introduction on how to develop and test your collection contributions. diff --git a/docs/docsite/rst/community/contributor_license_agreement.rst b/docs/docsite/rst/community/contributor_license_agreement.rst deleted file mode 100644 index b0a0f11736c..00000000000 --- a/docs/docsite/rst/community/contributor_license_agreement.rst +++ /dev/null @@ -1,7 +0,0 @@ -.. _contributor_license_agreement: - -****************************** -Contributors License Agreement -****************************** - -By contributing you agree that these contributions are your own (or approved by your employer) and you grant a full, complete, irrevocable copyright license to all users and developers of the project, present and future, pursuant to the license of the project. diff --git a/docs/docsite/rst/community/contributor_path.rst b/docs/docsite/rst/community/contributor_path.rst deleted file mode 100644 index 124505859f2..00000000000 --- a/docs/docsite/rst/community/contributor_path.rst +++ /dev/null @@ -1,114 +0,0 @@ -**************** -Contributor path -**************** - -This section describes the contributor's journey from the beginning to becoming a leader who helps shape the future of Ansible. You can use this path as a roadmap for your long-term participation. - -Any contribution to the project, even a small one, is very welcome and valuable. Any contribution counts, whether it's feedback on an issue, a pull request, a topic or documentation change, or a coding contribution. When you contribute regularly, your proficiency and judgment in the related area increase and, along with this, the importance of your presence in the project. - -.. contents:: - :local: - - - -Determine your area of interest -================================= - -First, determine areas that are interesting to you. Consider your current experience and what you'd like to gain. For example, if you use a specific collection, have a look there. See :ref:`how_can_i_help` for more ideas on how to help. - -Find the corresponding project -==================================== - -These are multiple community projects in the Ansible ecosystem you could contribute to: - -- `Ansible Core `_ -- `Collections `_ -- `AWX `_ -- `Galaxy `_ -- `ansible-lint `_ -- `Molecule `_ - -Learn -===== - -The required skillset depends on the area of interest and the project you'll be working on. Remember that the best way to learn is by doing. - -Specific knowledge for code developers ----------------------------------------- - -Code development requires the most technical knowledge. Let's sort out what an Ansible developer should learn. - - -You should understand at least the *basics* of the following tools: - -- `Python programming language `_ -- `Git `_ -- `GitHub collaborative development model through forks and pull requests `_ - -You can learn these tools more in-depth when working on your first contributions. - - -Each Ansible project has its own set of contributor guidelines. Familiarize yourself with these as you prepare your first contributions. - -* :ref:`Ansible Core development `. -* :ref:`Ansible collection development ` and the collection-level contributor guidelines in the collection repository. - - -Making your first contribution -============================== - -You can find some ideas on how you can contribute in :ref:`how_can_i_help`. - -If you are interested in contributing to collections, take a look at :ref:`collection contributions` and the `collection repository `_'s ``README`` and ``CONTRIBUTING`` files. To make your first experience as smooth as possible, read the repository documentation carefully, then ask the repository maintainers for guidance if you have any questions. - -Take a look at GitHub issues labeled with the ``easyfix`` and ``good_first_issue`` labels for: - -- `Ansible collections repositories `_ -- `All other Ansible projects `_ - -Issues labeled with the ``docs`` label in `Ansible collections `_ and `other `_ Ansible projects can be also good to start with. - -When you choose an issue to work on, add a comment directly on the GitHub issue to say you are looking at it and let others know to avoid conflicting work. -You can also ask for help in a comment if you need it. - -Continue to contribute -====================== - -We don't expect everybody to know everything. Start small, think big. When you contribute regularly, your proficiency and judgment in the related area will improve quickly and, along with this, the importance of your presence in the project. - -See :ref:`communication` for ways to communicate and engage with the Ansible community, including working group meetings, accessing the Bullhorn news bulletin, and upcoming contributor summits. - - -Teach others -============ - -Share your experience with other contributors through :ref:`improving documentation`, answering questions from other contributors and users on :ref:`Matrix/Libera.Chat IRC`, giving advice on issues and pull requests, and discussing `Community Topics `_. - -Become a collection maintainer -=============================== - -If you are a code contributor to a collection, you can get extended permissions in the repository and become a maintainer. A collection maintainer is a contributor trusted by the community who makes significant and regular contributions to the project and showed themselves as a specialist in the related area. See :ref:`maintainers` for details. - -For some collections that use the `collection bot `_, such as `community.general `_ and `community.network `_, you can have different levels of access and permissions. - -* :ref:`module_maintainers` - The stage prior to becoming a collection maintainer. The file is usually a module or plugin. File maintainers have indirect commit rights. -* supershipit permissions - Similar to being a file maintainer but the scope where a maintainer has the indirect commit is the whole repository. -* ``triage`` - Access to the repository that allows contributors to manage issues and pull requests. -* ``write`` access to the repository also known as ``commit``. In other words, become a committer. This access level allows contributors to merge pull requests to the development branch as well as perform all the other activities listed in the :ref:`maintainers`. - -For information about permission levels, see the `GitHub official documentation `_. - -Become a steering committee member -================================== - -.. note:: - - You do NOT have to be a programmer to become a steering committee member. - -The :ref:`Steering Committee ` member status reflects the highest level of trust which allows contributors to lead the project by making very important `decisions `_ for the Ansible project. The Committee members are the community leaders who shape the project's future and the future of automation in the IT world in general. - -To reach the status, as the current Committee members did before getting it, along with the things mentioned in this document, you should: - -* Subscribe to, comment on, and vote on the `Community Topics `_. -* Propose your topics. -* If time permits, join the `Community meetings `_. Note this is **NOT** a requirement. diff --git a/docs/docsite/rst/community/create_pr_quick_start.rst b/docs/docsite/rst/community/create_pr_quick_start.rst deleted file mode 100644 index b5a2a8d0b9a..00000000000 --- a/docs/docsite/rst/community/create_pr_quick_start.rst +++ /dev/null @@ -1,272 +0,0 @@ -.. _collection_quickstart: - -******************************************** -Creating your first collection pull request -******************************************** - -This section describes all steps needed to create your first patch and submit a pull request on a collection. - -.. _collection_prepare_local: - -Prepare your environment -======================== - -.. note:: - - These steps assume a Linux work environment with ``git`` installed. - - -1. Install and start ``docker`` or ``podman``. This ensures tests run properly isolated and in the same environment as in CI. - -2. :ref:`Install Ansible or ansible-core `. You need the ``ansible-test`` utility which is provided by either of these packages. - -3. Create the following directories in your home directory: - - .. code-block:: bash - - $ mkdir -p ~/ansible_collections/NAMESPACE/COLLECTION_NAME - - - For example, if the collection is ``community.mysql``, it would be: - - .. code-block:: bash - - $ mkdir -p ~/ansible_collections/community/mysql - - -4. Fork the collection repository through the GitHub web interface. - -5. Clone the forked repository from your profile to the created path: - - .. code-block:: bash - - $ git clone https://github.com/YOURACC/COLLECTION_REPO.git ~/ansible_collections/NAMESPACE/COLLECTION_NAME - - If you prefer to use the SSH protocol: - - .. code-block:: bash - - $ git clone git@github.com:YOURACC/COLLECTION_REPO.git ~/ansible_collections/NAMESPACE/COLLECTION_NAME - -6. Go to your new cloned repository. - - .. code-block:: bash - - $ cd ~/ansible_collections/NAMESPACE/COLLECTION_NAME - -7. Ensure you are in the default branch (it is usually ``main``): - - .. code-block:: bash - - $ git status - -8. Show remotes. There should be the ``origin`` repository only: - - .. code-block:: bash - - $ git remote -v - -9. Add the ``upstream`` repository: - - .. code-block:: bash - - $ git remote add upstream https://github.com/ansible-collections/COLLECTION_REPO.git - - This is the repository where you forked from. - -10. Update your local default branch. Assuming that it is ``main``: - - .. code-block:: bash - - $ git fetch upstream - $ git rebase upstream/main - -11. Create a branch for your changes: - - .. code-block:: bash - - $ git checkout -b name_of_my_branch - -Change the code -=============== - -.. note:: - - Do NOT mix several bug fixes or features that are not tightly related in one pull request. Use separate pull requests for different changes. - -You should start with writing integration and unit tests if applicable. These can verify the bug exists (prior to your code fix) and verify your code fixed that bug once the tests pass. - -.. note:: - - If there are any difficulties with writing or running the tests or you are not sure if the case can be covered, you can skip this step. Other contributors can help you with tests later if needed. - -.. note:: - - Some collections do not have integration tests. In this case, unit tests are required. - -All integration tests are stored in ``tests/integration/targets`` subdirectories. -Go to the subdirectory containing the name of the module you are going to change. -For example, if you are fixing the ``mysql_user`` module in the ``community.mysql`` collection, -its tests are in ``tests/integration/targets/test_mysql_user/tasks``. - -The ``main.yml`` file holds test tasks and includes other test files. -Look for a suitable test file to integrate your tests or create and include a dedicated test file. -You can use one of the existing test files as a draft. - -When fixing a bug, write a task that reproduces the bug from the issue. - -Put the reported case in the tests, then run integration tests with the following command: - -.. code-block:: bash - - $ ansible-test integration name_of_test_subdirectory --docker -v - -For example, if the test files you changed are stored in ``tests/integration/targets/test_mysql_user/``, the command is as follows: - -.. code-block:: bash - - $ ansible-test integration test_mysql_user --docker -v - -You can use the ``-vv`` or ``-vvv`` argument if you need more detailed output. - -In the examples above, the default test image is automatically downloaded and used to create and run a test container. -Use the default test image for platform-independent integration tests such as those for cloud modules. - -If you need to run the tests against a specific distribution, see the :ref:`list of supported container images `. For example: - -.. code-block:: bash - - $ ansible-test integration name_of_test_subdirectory --docker fedora35 -v - -.. note:: - - If you are not sure whether you should use the default image for testing or a specific one, skip the entire step - the community can help you later. You can also try to use the collection repository's CI to figure out which containers are used. - -If the tests ran successfully, there are usually two possible outcomes: - -- If the bug has not appeared and the tests have passed successfully, ask the reporter to provide more details. It may not be a bug or can relate to a particular software version used or specifics of the reporter's local environment configuration. -- The bug has appeared and the tests have failed as expected showing the reported symptoms. - -Fix the bug -============= - -See :ref:`module_contribution` for some general guidelines about Ansible module development that may help you craft a good code fix for the bug. - -Test your changes -================= - -1. Install ``flake8`` (``pip install flake8``, or install the corresponding package on your operating system). - -2. Run ``flake8`` against a changed file: - - .. code-block:: bash - - $ flake8 path/to/changed_file.py - - - This shows unused imports, which are not shown by sanity tests, as well as other common issues. - Optionally, you can use the ``--max-line-length=160`` command-line argument. - -3. Run sanity tests: - - .. code-block:: bash - - $ ansible-test sanity path/to/changed_file.py --docker -v - - If they failed, look at the output carefully - it is informative and helps to identify a problem line quickly. - Sanity failings usually relate to incorrect code and documentation formatting. - -4. Run integration tests: - - .. code-block:: bash - - $ ansible-test integration name_of_test_subdirectory --docker -v - - For example, if the test files you changed are stored in ``tests/integration/targets/test_mysql_user/``, the command is: - - .. code-block:: bash - - $ ansible-test integration test_mysql_user --docker -v - - You can use the ``-vv`` or ``-vvv`` argument if you need more detailed output. - - -There are two possible outcomes: - -- They have failed. Look at the output of the command. Fix the problem in the code and run again. Repeat the cycle until the tests pass. -- They have passed. Remember they failed originally? Our congratulations! You have fixed the bug. - -In addition to the integration tests, you can also cover your changes with unit tests. This is often required when integration tests are not applicable to the collection. - -We use `pytest `_ as a testing framework. - -Files with unit tests are stored in the ``tests/unit/plugins/`` directory. If you want to run unit tests, say, for ``tests/unit/plugins/test_myclass.py``, the command is: - -.. code-block:: bash - - $ ansible-test units tests/unit/plugins/test_myclass.py --docker - -If you want to run all unit tests available in the collection, run: - -.. code-block:: bash - - $ ansible-test units --docker - -Submit a pull request -===================== - -1. Commit your changes with an informative but short commit message: - - .. code-block:: bash - - $ git add /path/to/changed/file - $ git commit -m "module_name_you_fixed: fix crash when ..." - -2. Push the branch to ``origin`` (your fork): - - .. code-block:: bash - - $ git push origin name_of_my_branch - -3. In a browser, navigate to the ``upstream`` repository (http://github.com/ansible-collections/COLLECTION_REPO). - -4. Click the :guilabel:`Pull requests` tab. - - GitHub is tracking your fork, so it should see the new branch in it and automatically offer to create a pull request. Sometimes GitHub does not do it, and you should click the :guilabel:`New pull request` button yourself. Then choose :guilabel:`compare across forks` under the :guilabel:`Compare changes` title. - -5. Choose your repository and the new branch you pushed in the right drop-down list. Confirm. - - a. Fill out the pull request template with all information you want to mention. - - b. Put ``Fixes + link to the issue`` in the pull request's description. - - c. Put ``[WIP] + short description`` in the pull request's title. Mention the name of the module/plugin you are modifying at the beginning of the description. - - d. Click :guilabel:`Create pull request`. - -6. Add a :ref:`changelog fragment ` to the ``changelogs/fragments`` directory. It will be published in release notes, so users will know about the fix. - - a. Run the sanity test for the fragment: - - .. code-block:: bash - - $ ansible-test sanity changelogs/fragments/ --docker -v - - - b. If the tests passed, commit and push the changes: - - .. code-block:: bash - - $ git add changelogs/fragments/myfragment.yml - $ git commit -m "Add changelog fragment" - $ git push origin name_of_my_branch - -7. Verify the CI tests pass that run automatically on Red Hat infrastructure after every commit. - - You will see the CI status at the bottom of your pull request. If they are green and you think that you do not want to add more commits before someone should take a closer look at it, remove ``[WIP]`` from the title. Mention the issue reporter in a comment and let contributors know that the pull request is "Ready for review". - -8. Wait for reviews. You can also ask for a review in the ``#ansible-community`` :ref:`Matrix/Libera.Chat IRC channel `. - -9. If the pull request looks good to the community, committers will merge it. - -For more in-depth details on this process, see the :ref:`Ansible developer guide `. diff --git a/docs/docsite/rst/community/development_process.rst b/docs/docsite/rst/community/development_process.rst deleted file mode 100644 index d3457d296c1..00000000000 --- a/docs/docsite/rst/community/development_process.rst +++ /dev/null @@ -1,368 +0,0 @@ -.. _community_development_process: - -***************************** -The Ansible Development Cycle -***************************** - -Ansible developers (including community contributors) add new features, fix bugs, and update code in many different repositories. The `ansible/ansible repository `_ contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-core``. Other repositories contain plugins and modules that enable Ansible to execute specific tasks, like adding a user to a particular database or configuring a particular network device. These repositories contain the source code for collections. - -Development on ``ansible-core`` occurs on two levels. At the macro level, the ``ansible-core`` developers and maintainers plan releases and track progress with roadmaps and projects. At the micro level, each PR has its own lifecycle. - -Development on collections also occurs at the macro and micro levels. Each collection has its own macro development cycle. For more information on the collections development cycle, see :ref:`contributing_maintained_collections`. The micro-level lifecycle of a PR is similar in collections and in ``ansible-core``. - -.. contents:: - :local: - -Macro development: ``ansible-core`` roadmaps, releases, and projects -===================================================================== - -If you want to follow the conversation about what features will be added to ``ansible-core`` for upcoming releases and what bugs are being fixed, you can watch these resources: - -* the :ref:`roadmaps` -* the :ref:`Ansible Release Schedule ` -* the :ref:`ansible-core project branches and tags ` -* various GitHub `projects `_ - for example: - - * the `2.16 release project `_ - * the `core documentation project `_ - - -.. _community_pull_requests: - - -Micro development: the lifecycle of a PR -======================================== - -If you want to contribute a feature or fix a bug in ``ansible-core`` or in a collection, you must open a **pull request** ("PR" for short). GitHub provides a great overview of `how the pull request process works `_ in general. The ultimate goal of any pull request is to get merged and become part of a collection or ``ansible-core``. -Here's an overview of the PR lifecycle: - -* Contributor opens a PR (always against the ``devel`` branch) -* Ansibot reviews the PR -* Ansibot assigns labels -* Ansibot pings maintainers -* Azure Pipelines runs the test suite -* Developers, maintainers, community review the PR -* Contributor addresses any feedback from reviewers -* Developers, maintainers, community re-review -* PR merged or closed -* PR :ref:`backported ` to one or more ``stable-X.Y`` branches (optional, bugfixes only) - -Automated PR review: ansibullbot --------------------------------- - -Because Ansible receives many pull requests, and because we love automating things, we have automated several steps of the process of reviewing and merging pull requests with a tool called Ansibullbot, or Ansibot for short. - -`Ansibullbot `_ serves many functions: - -- Responds quickly to PR submitters to thank them for submitting their PR -- Identifies the community maintainer responsible for reviewing PRs for any files affected -- Tracks the current status of PRs -- Pings responsible parties to remind them of any PR actions for which they may be responsible -- Provides maintainers with the ability to move PRs through the workflow -- Identifies PRs abandoned by their submitters so that we can close them -- Identifies modules abandoned by their maintainers so that we can find new maintainers - -Ansibot workflow -^^^^^^^^^^^^^^^^ - -Ansibullbot runs continuously. You can generally expect to see changes to your issue or pull request within thirty minutes. Ansibullbot examines every open pull request in the repositories, and enforces state roughly according to the following workflow: - -- If a pull request has no workflow labels, it's considered **new**. Files in the pull request are identified, and the maintainers of those files are pinged by the bot, along with instructions on how to review the pull request. (Note: sometimes we strip labels from a pull request to "reboot" this process.) -- If the module maintainer is not ``$team_ansible``, the pull request then goes into the **community_review** state. -- If the module maintainer is ``$team_ansible``, the pull request then goes into the **core_review** state (and probably sits for a while). -- If the pull request is in **community_review** and has received comments from the maintainer: - - - If the maintainer says ``shipit``, the pull request is labeled **shipit**, whereupon the Core team assesses it for final merge. - - If the maintainer says ``needs_info``, the pull request is labeled **needs_info** and the submitter is asked for more info. - - If the maintainer says **needs_revision**, the pull request is labeled **needs_revision** and the submitter is asked to fix some things. - -- If the submitter says ``ready_for_review``, the pull request is put back into **community_review** or **core_review** and the maintainer is notified that the pull request is ready to be reviewed again. -- If the pull request is labeled **needs_revision** or **needs_info** and the submitter has not responded lately: - - - The submitter is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending action**, and the issue or pull request will be closed two weeks after that. - - If the submitter responds at all, the clock is reset. -- If the pull request is labeled **community_review** and the reviewer has not responded lately: - - - The reviewer is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending_action**, and then may be reassigned to ``$team_ansible`` or labeled **core_review**, or often the submitter of the pull request is asked to step up as a maintainer. -- If Azure Pipelines tests fail, or if the code is not able to be merged, the pull request is automatically put into **needs_revision** along with a message to the submitter explaining why. - -There are corner cases and frequent refinements, but this is the workflow in general. - -PR labels -^^^^^^^^^ - -There are two types of PR Labels generally: **workflow** labels and **information** labels. - -Workflow labels -""""""""""""""" - -- **community_review**: Pull requests for modules that are currently awaiting review by their maintainers in the Ansible community. -- **core_review**: Pull requests for modules that are currently awaiting review by their maintainers on the Ansible Core team. -- **needs_info**: Waiting on info from the submitter. -- **needs_rebase**: Waiting on the submitter to rebase. -- **needs_revision**: Waiting on the submitter to make changes. -- **shipit**: Waiting for final review by the core team for potential merge. - -Information labels -"""""""""""""""""" - -- **backport**: this is applied automatically if the PR is requested against any branch that is not devel. The bot immediately assigns the labels backport and ``core_review``. -- **bugfix_pull_request**: applied by the bot based on the templatized description of the PR. -- **cloud**: applied by the bot based on the paths of the modified files. -- **docs_pull_request**: applied by the bot based on the templatized description of the PR. -- **easyfix**: applied manually, inconsistently used but sometimes useful. -- **feature_pull_request**: applied by the bot based on the templatized description of the PR. -- **networking**: applied by the bot based on the paths of the modified files. -- **owner_pr**: largely deprecated. Formerly workflow, now informational. Originally, PRs submitted by the maintainer would automatically go to **shipit** based on this label. If the submitter is also a maintainer, we notify the other maintainers and still require one of the maintainers (including the submitter) to give a **shipit**. -- **pending_action**: applied by the bot to PRs that are not moving. Reviewed every couple of weeks by the community team, who tries to figure out the appropriate action (closure, asking for new maintainers, and so on). - - -Special Labels -"""""""""""""" - -- **new_plugin**: this is for new modules or plugins that are not yet in Ansible. - -**Note:** `new_plugin` kicks off a completely separate process, and frankly it doesn't work very well at present. We're working our best to improve this process. - -Human PR review ---------------- - -After Ansibot reviews the PR and applies labels, the PR is ready for human review. The most likely reviewers for any PR are the maintainers for the module that PR modifies. - -Each module has at least one assigned :ref:`maintainer `, listed in the `BOTMETA.yml `_ file. - -The maintainer's job is to review PRs that affect that module and decide whether they should be merged (``shipit``) or revised (``needs_revision``). We'd like to have at least one community maintainer for every module. If a module has no community maintainers assigned, the maintainer is listed as ``$team_ansible``. - -Once a human applies the ``shipit`` label, the :ref:`committers ` decide whether the PR is ready to be merged. Not every PR that gets the ``shipit`` label is actually ready to be merged, but the better our reviewers are, and the better our guidelines are, the more likely it will be that a PR that reaches **shipit** will be mergeable. - - -Making your PR merge-worthy -=========================== - -We do not merge every PR. Here are some tips for making your PR useful, attractive, and merge-worthy. - -.. _community_changelogs: - -Creating changelog fragments ------------------------------- - -Changelogs help users and developers keep up with changes to ansible-core and Ansible collections. Ansible and many collections build changelogs for each release from fragments. For ansible-core and collections using this model, you **must** add a changelog fragment to any PR that changes functionality or fixes a bug. - -You do not need a changelog fragment for PRs that: - -* add new modules and plugins, because Ansible tooling does that automatically; -* contain only documentation changes. - -.. note:: - Some collections require a changelog fragment for every pull request. They use the ``trivial:`` section for entries mentioned above that will be skipped when building a release changelog. - - -More precisely: - -* Every bugfix PR must have a changelog fragment. The only exception are fixes to a change that has not yet been included in a release. -* Every feature PR must have a changelog fragment. -* New modules and plugins (including jinja2 filter and test plugins) must have ``version_added`` entries set correctly in their documentation, and do not need a changelog fragment. The tooling detects new modules and plugins by their ``version_added`` values and announces them in the next release's changelog automatically. - -We build short summary changelogs for minor releases as well as for major releases. If you backport a bugfix, include a changelog fragment with the backport PR. - -.. _changelogs_how_to: - -Creating a changelog fragment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -A basic changelog fragment is a ``.yaml`` or ``.yml`` file placed in the ``changelogs/fragments/`` directory. Each file contains a yaml dict with keys like ``bugfixes`` or ``major_changes`` followed by a list of changelog entries of bugfixes or features. Each changelog entry is rst embedded inside of the yaml file which means that certain constructs would need to be escaped so they can be interpreted by rst and not by yaml (or escaped for both yaml and rst if you prefer). Each PR **must** use a new fragment file rather than adding to an existing one, so we can trace the change back to the PR that introduced it. - -PRs which add a new module or plugin do not necessarily need a changelog fragment. See the previous section :ref:`community_changelogs`. Also see the next section :ref:`changelogs_how_to_format` for the precise format changelog fragments should have. - -To create a changelog entry, create a new file with a unique name in the ``changelogs/fragments/`` directory of the corresponding repository. The file name should include the PR number and a description of the change. It must end with the file extension ``.yaml`` or ``.yml``. For example: ``40696-user-backup-shadow-file.yaml`` - -A single changelog fragment may contain multiple sections but most will only contain one section. The toplevel keys (bugfixes, major_changes, and so on) are defined in the `config file `_ for our `release note tool `_. Here are the valid sections and a description of each: - -**breaking_changes** - MUST include changes that break existing playbooks or roles. This includes any change to existing behavior that forces users to update tasks. Breaking changes means the user MUST make a change when they update. Breaking changes MUST only happen in a major release of the collection. Write in present tense and clearly describe the new behavior that the end user must now follow. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - breaking_changes: - - ansible-test - automatic installation of requirements for cloud test plugins no longer occurs. The affected test plugins are ``aws``, ``azure``, ``cs``, ``hcloud``, ``nios``, ``opennebula``, ``openshift`` and ``vcenter``. Collections should instead use one of the supported integration test requirements files, such as the ``tests/integration/requirements.txt`` file (https://github.com/ansible/ansible/pull/75605). - - -**major_changes** - Major changes to ansible-core or a collection. SHOULD NOT include individual module or plugin changes. MUST include non-breaking changes that impact all or most of a collection (for example, updates to support a new SDK version across the collection). Major changes mean the user can CHOOSE to make a change when they update but do not have to. Could be used to announce an important upcoming EOL or breaking change in a future release. (ideally 6 months in advance, if known. See `this example `_). Write in present tense and describe what is new. Optionally, include a 'Previously..." sentence to help the user identify where old behavior should now change. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - major_changes: - - ansible-test - all cloud plugins which use containers can now be used with all POSIX and Windows hosts. Previously the plugins did not work with Windows at all, and support for hosts created with the ``--remote`` option was inconsistent (https://github.com/ansible/ansible/pull/74216). - -**minor_changes** - Minor changes to ansible-core, modules, or plugins. This includes new parameters added to modules, or non-breaking behavior changes to existing parameters, such as adding additional values to choices[]. Minor changes are enhancements, not bug fixes. Write in present tense. - - .. code-block:: yaml - - minor_changes: - - lineinfile - add warning when using an empty regexp (https://github.com/ansible/ansible/issues/29443). - - -**deprecated_features** - Features that have been deprecated and are scheduled for removal in a future release. Use past tense and include an alternative, where available for what is being deprecated.. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - deprecated_features: - - include action - is deprecated in favor of ``include_tasks``, ``import_tasks`` and ``import_playbook`` (https://github.com/ansible/ansible/pull/71262). - - -**removed_features** - Features that were previously deprecated and are now removed. Use past tense and include an alternative, where available for what is being deprecated. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - removed_features: - - _get_item() alias - removed from callback plugin base class which had been deprecated in favor of ``_get_item_label()`` (https://github.com/ansible/ansible/pull/70233). - - -**security_fixes** - Fixes that address CVEs or resolve security concerns. MUST use security_fixes for any CVEs. Use present tense. Include links to CVE information. - - .. code-block:: yaml - - security_fixes: - - set_options -do not include params in exception when a call to ``set_options`` fails. Additionally, block the exception that is returned from being displayed to stdout. (CVE-2021-3620). - - -**bugfixes** - Fixes that resolve issues. SHOULD not be used for minor enhancements (use ``minor_change`` instead). Use past tense to describe the problem and present tense to describe the fix. - - .. code-block:: yaml - - bugfixes: - - ansible_play_batch - variable included unreachable hosts. Fix now saves unreachable hosts between plays by adding them to the PlayIterator's ``_play._removed_hosts`` (https://github.com/ansible/ansible/issues/66945). - - -**known_issues** - Known issues that are currently not fixed or will not be fixed. Use present tense and where available, use imperative tense for a workaround. - - .. code-block:: yaml - - known_issues: - - ansible-test - tab completion anywhere other than the end of the command with the new composite options provides incorrect results (https://github.com/kislyuk/argcomplete/issues/351). - - -Each changelog entry must contain a link to its issue between parentheses at the end. If there is no corresponding issue, the entry must contain a link to the PR itself. - -Most changelog entries are ``bugfixes`` or ``minor_changes``. The changelog tool also supports ``trivial``, which are not listed in the actual changelog output but are used by collections repositories that require a changelog fragment for each PR. - - - -.. _changelogs_how_to_format: - -Changelog fragment entry format -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When writing a changelog entry, use the following format: - -.. code-block:: yaml - - - scope - description starting with a lowercase letter and ending with a period at the very end. Multiple sentences are allowed (https://github.com/reference/to/an/issue or, if there is no issue, reference to a pull request itself). - -The scope is usually a module or plugin name or group of modules or plugins, for example, ``lookup plugins``. While module names can (and should) be mentioned directly (``foo_module``), plugin names should always be followed by the type (``foo inventory plugin``). - -For changes that are not really scoped (for example, which affect a whole collection), use the following format: - -.. code-block:: yaml - - - Description starting with an uppercase letter and ending with a dot at the very end. Multiple sentences are allowed (https://github.com/reference/to/an/issue or, if there is no issue, reference to a pull request itself). - - -Here are some examples: - -.. code-block:: yaml - - bugfixes: - - apt_repository - fix crash caused by ``cache.update()`` raising an ``IOError`` - due to a timeout in ``apt update`` (https://github.com/ansible/ansible/issues/51995). - -.. code-block:: yaml - - minor_changes: - - lineinfile - add warning when using an empty regexp (https://github.com/ansible/ansible/issues/29443). - -.. code-block:: yaml - - bugfixes: - - copy - the module was attempting to change the mode of files for - remote_src=True even if mode was not set as a parameter. This failed on - filesystems which do not have permission bits (https://github.com/ansible/ansible/issues/29444). - -You can find more example changelog fragments in the `changelog directory `_ for the 2.12 release. - -After you have written the changelog fragment for your PR, commit the file and include it with the pull request. - -.. _changelogs_how_to_format_playbooks: - -Changelog fragment entry format for new playbooks -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -While new modules, plugins, and roles are mentioned automatically in the generated changelog, playbooks are not. To make sure they are mentioned, a changelog fragment in a specific format is needed: - -.. code-block:: yaml - - # A new playbook: - add object.playbook: - - # This should be the short (non-FQCN) name of the playbook. - name: wipe_server - # The description should be in the same format as short_description for - # plugins and modules: it should start with an upper-case letter and - # not have a period at the end. - description: Wipes a server - -.. _backport_process: - -Backporting merged PRs in ``ansible-core`` -=========================================== - -All ``ansible-core`` PRs must be merged to the ``devel`` branch first. After a pull request has been accepted and merged to the ``devel`` branch, the following instructions will help you create a pull request to backport the change to a previous stable branch. - -We do **not** backport features. - -.. note:: - - These instructions assume that: - - * ``stable-2.15`` is the targeted release branch for the backport - * ``https://github.com/ansible/ansible.git`` is configured as a ``git remote`` named ``upstream``. If you do not use a ``git remote`` named ``upstream``, adjust the instructions accordingly. - * ``https://github.com//ansible.git`` is configured as a ``git remote`` named ``origin``. If you do not use a ``git remote`` named ``origin``, adjust the instructions accordingly. - -#. Prepare your devel, stable, and feature branches: - -.. code-block:: shell - - git fetch upstream - git checkout -b backport/2.15/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.15 - -#. Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary: - -.. code-block:: shell - - git cherry-pick -x [SHA_FROM_DEVEL] - -#. Add a :ref:`changelog fragment ` for the change, and commit it. - -#. Push your feature branch to your fork on GitHub: - -.. code-block:: shell - - git push origin backport/2.15/[PR_NUMBER_FROM_DEVEL] - -#. Submit the pull request for ``backport/2.15/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.15`` branch - -#. The Release Manager will decide whether to merge the backport PR before the next minor release. There isn't any need to follow up. Just ensure that the automated tests (CI) are green. - -.. note:: - - The branch name ``backport/2.15/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches. - -.. note:: - - If you prefer, you can use CPython's cherry-picker tool (``pip install --user 'cherry-picker >= 1.3.2'``) to backport commits from devel to stable branches in Ansible. Take a look at the `cherry-picker documentation `_ for details on installing, configuring, and using it. diff --git a/docs/docsite/rst/community/documentation_contributions.rst b/docs/docsite/rst/community/documentation_contributions.rst deleted file mode 100644 index 88ddf325539..00000000000 --- a/docs/docsite/rst/community/documentation_contributions.rst +++ /dev/null @@ -1,243 +0,0 @@ -.. _community_documentation_contributions: - -***************************************** -Contributing to the Ansible Documentation -***************************************** - -Ansible has a lot of documentation and a small team of writers. Community support helps us keep up with new features, fixes, and changes. - -Improving the documentation is an easy way to make your first contribution to the Ansible project. You do not have to be a programmer, since most of our documentation is written in YAML (module documentation) or `reStructuredText `_ (rST). Some collection-level documentation is written in a subset of `Markdown `_. If you are using Ansible, you already use YAML in your playbooks. rST and Markdown are mostly just text. You do not even need git experience, if you use the ``Edit on GitHub`` option. - -If you find a typo, a broken example, a missing topic, or any other error or omission on this documentation website, let us know. Here are some ways to support Ansible documentation: - -.. contents:: - :local: - -Editing docs directly on GitHub -=============================== - -For typos and other quick fixes, you can edit most of the documentation right from the site. Look at the top right corner of this page. That ``Edit on GitHub`` link is available on all the guide pages in the documentation. If you have a GitHub account, you can submit a quick and easy pull request this way. - -.. note:: - - The source files for individual collection plugins exist in their respective repositories. Follow the link to the collection on Galaxy to find where the repository is located and any guidelines on how to contribute to that collection. - -To submit a documentation PR from docs.ansible.com with ``Edit on GitHub``: - -#. Click on ``Edit on GitHub``. -#. If you don't already have a fork of the ansible repo on your GitHub account, you'll be prompted to create one. -#. Fix the typo, update the example, or make whatever other change you have in mind. -#. Enter a commit message in the first rectangle under the heading ``Propose file change`` at the bottom of the GitHub page. The more specific, the better. For example, "fixes typo in my_module description". You can put more detail in the second rectangle if you like. Leave the ``+label: docsite_pr`` there. -#. Submit the suggested change by clicking on the green "Propose file change" button. GitHub will handle branching and committing for you, and open a page with the heading "Comparing Changes". -#. Click on ``Create pull request`` to open the PR template. -#. Fill out the PR template, including as much detail as appropriate for your change. You can change the title of your PR if you like (by default it's the same as your commit message). In the ``Issue Type`` section, delete all lines except the ``Docs Pull Request`` line. -#. Submit your change by clicking on ``Create pull request`` button. -#. Be patient while Ansibot, our automated script, adds labels, pings the docs maintainers, and kicks off a CI testing run. -#. Keep an eye on your PR - the docs team may ask you for changes. - -Reviewing or solving open issues -================================ - -Review or solve open documentation issues for: - -- `Ansible projects `_ -- `Ansible collections `_ - -Reviewing open PRs -================== - -Review open documentation pull requests for: - -- Ansible `projects `_ -- Ansible `collections `_ - -To add a helpful review, please: - -- Test the change if applicable. -- Think if it can be made better (including wording, structure, fixing typos and so on). -- Suggest improvements. -- Approve the change with the ``looks good to me`` comment. - -Opening a new issue and/or PR -============================= - -If the problem you have noticed is too complex to fix with the ``Edit on GitHub`` option, and no open issue or PR already documents the problem, please open an issue and/or a PR on the correct underlying repo - ``ansible/ansible`` for most pages that are not plugin or module documentation. If the documentation page has no ``Edit on GitHub`` option, check if the page is for a module within a collection. If so, follow the link to the collection on Galaxy and select the ``repo`` button in the upper right corner to find the source repository for that collection and module. The Collection README file should contain information on how to contribute to that collection, or report issues. - -A great documentation GitHub issue or PR includes: - -- a specific title -- a detailed description of the problem (even for a PR - it's hard to evaluate a suggested change unless we know what problem it's meant to solve) -- links to other information (related issues/PRs, external documentation, pages on docs.ansible.com, and so on) - - -Verifying your documentation PR -================================ - -If you make multiple changes to the documentation on ``ansible/ansible``, or add more than a line to it, before you open a pull request, please: - -#. Check that your text follows our :ref:`style_guide`. -#. Test your changes for rST errors. -#. Build the page, and preferably the entire documentation site, locally. - -.. note:: - - The following sections apply to documentation sourced from the ``ansible/ansible`` repo and does not apply to documentation from an individual collection. See the collection README file for details on how to contribute to that collection. - -Setting up your environment to build documentation locally ----------------------------------------------------------- - -To build documentation locally, ensure you have a working :ref:`development environment `. - -To work with documentation on your local machine, you need to have python-3.9 or greater and install the `Ansible dependencies`_ and `documentation dependencies`_, which are listed in two files to make installation easier: - -.. _Ansible dependencies: https://github.com/ansible/ansible/blob/devel/requirements.txt -.. _documentation dependencies: https://github.com/ansible/ansible/blob/devel/docs/docsite/requirements.txt - -Drop the ``--user`` option in the following commands if you use a virtual environment (venv/virtenv). - -#. Upgrade pip before installing dependencies (recommended). - - .. code-block:: bash - - pip install --user --upgrade pip - -#. Install Ansible dependencies. - - .. code-block:: bash - - pip install --user -r requirements.txt - -#. Install either the unpinned or tested documentation dependencies. - - .. code-block:: bash - - pip install --user -r docs/docsite/requirements.txt # This file installs unpinned versions that can cause problems with the Ansible docs build. - pip install --user -r test/sanity/code-smell/docs-build.requirements.txt # This file installs tested dependency versions that are used by CI. - -.. note:: - - You may need to install these general pre-requisites separately on some systems: - - ``gcc`` - - ``libyaml`` - - ``make`` - - ``pyparsing`` - - ``wheel`` - - ``six`` - On macOS with Xcode, you may need to install ``six`` and ``pyparsing`` with ``--ignore-installed`` to get versions that work with ``sphinx``. - -.. note:: - - After checking out ``ansible/ansible``, make sure the ``docs/docsite/rst`` directory has strict enough permissions. It should only be writable by the owner's account. If your default ``umask`` is not 022, you can use ``chmod go-w docs/docsite/rst`` to set the permissions correctly in your new branch. Optionally, you can set your ``umask`` to 022 to make all newly created files on your system (including those created by ``git clone``) have the correct permissions. - -.. _testing_documentation_locally: - -Testing the documentation locally ---------------------------------- - -To test an individual file for rST errors: - -.. code-block:: bash - - rstcheck changed_file.rst - -Building the documentation locally ----------------------------------- - -Building the documentation is the best way to check for errors and review your changes. Once `rstcheck` runs with no errors, navigate to ``ansible/docs/docsite`` and then build the page(s) you want to review. - - .. note:: - - If building on macOS with Python 3.8 or later, you must use Sphinx >= 2.2.2. See `#6803 `_ for details. - - - -Building a single rST page -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To build a single rST file with the make utility: - -.. code-block:: bash - - make htmlsingle rst=path/to/your_file.rst - -For example: - -.. code-block:: bash - - make htmlsingle rst=community/documentation_contributions.rst - -This process compiles all the links but provides minimal log output. If you're writing a new page or want more detailed log output, refer to the instructions on :ref:`build_with_sphinx-build` - -.. note:: - - ``make htmlsingle`` adds ``rst/`` to the beginning of the path you provide in ``rst=``, so you can't type the filename with autocomplete. Here are the error messages you will see if you get this wrong: - - - If you run ``make htmlsingle`` from the ``docs/docsite/rst/`` directory: ``make: *** No rule to make target `htmlsingle'. Stop.`` - - If you run ``make htmlsingle`` from the ``docs/docsite/`` directory with the full path to your rST document: ``sphinx-build: error: cannot find files ['rst/rst/community/documentation_contributions.rst']``. - - -Building all the rST pages -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To build all the rST files without any module documentation: - -.. code-block:: bash - - MODULES=none make webdocs - -Building module docs and rST pages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To build documentation for a few modules included in ``ansible/ansible`` plus all the rST files, use a comma-separated list: - -.. code-block:: bash - - MODULES=one_module,another_module make webdocs - -To build all the module documentation plus all the rST files: - -.. code-block:: bash - - make webdocs - -.. _build_with_sphinx-build: - -Building rST files with ``sphinx-build`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Advanced users can build one or more rST files with the sphinx utility directly. ``sphinx-build`` returns misleading ``undefined label`` warnings if you only build a single page, because it does not create internal links. However, ``sphinx-build`` returns more extensive syntax feedback, including warnings about indentation errors and ``x-string without end-string`` warnings. This can be useful, especially if you're creating a new page from scratch. To build a page or pages with ``sphinx-build``: - -.. code-block:: bash - - sphinx-build [options] sourcedir outdir [filenames...] - -You can specify filenames, or ``–a`` for all files, or omit both to compile only new/changed files. - -For example: - -.. code-block:: bash - - sphinx-build -b html -c rst/ rst/dev_guide/ _build/html/dev_guide/ rst/dev_guide/developing_modules_documenting.rst - -Running the final tests -^^^^^^^^^^^^^^^^^^^^^^^ - -When you submit a documentation pull request, automated tests are run. Those same tests can be run locally. To do so, navigate to the repository's top directory and run: - -.. code-block:: bash - - make clean && - bin/ansible-test sanity --test docs-build && - bin/ansible-test sanity --test rstcheck - -Unfortunately, leftover rST-files from previous document-generating can occasionally confuse these tests. It is therefore safest to run them on a clean copy of the repository, which is the purpose of ``make clean``. If you type these three lines one at a time and manually check the success of each, you do not need the ``&&``. - -Joining the documentation working group -======================================= - -The Documentation Working Group (DaWGs) meets weekly on Tuesdays in the Docs chat (using `Matrix `_ or using IRC at `irc.libera.chat `_). For more information, including links to our agenda and a calendar invite, please visit the `working group page in the community repo `_. - -.. seealso:: - :ref:`More about testing module documentation ` - - :ref:`More about documenting modules ` diff --git a/docs/docsite/rst/community/getting_started.rst b/docs/docsite/rst/community/getting_started.rst deleted file mode 100644 index b35225163bd..00000000000 --- a/docs/docsite/rst/community/getting_started.rst +++ /dev/null @@ -1,33 +0,0 @@ -.. _community_getting_started: - -**************** -Getting started -**************** - -Welcome and thank you for getting more involved with the Ansible community. Here are some ways you can get started. - -.. toctree:: - :maxdepth: 2 - - code_of_conduct - contributor_license_agreement - communication - how_can_I_help - - - -Other ways to get involved -========================== - -Here are some other ways to connect with the Ansible community: - -* Find an `Ansible Meetup near me `_ - communication -* Learn more about Ansible: - - * `Read books `_. - * `Get certified `_. - * `Attend events `_. - * `Review getting started guides `_. - * `Watch videos `_ - includes Ansible Automates, AnsibleFest & webinar recordings. -* See where `new releases are announced `_ diff --git a/docs/docsite/rst/community/github_admins.rst b/docs/docsite/rst/community/github_admins.rst deleted file mode 100644 index 802b180dd1f..00000000000 --- a/docs/docsite/rst/community/github_admins.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _github_admins: - -************* -GitHub Admins -************* - -.. contents:: Topics - -GitHub Admins have more permissions on GitHub than normal contributors or even committers. There are -a few responsibilities that come with that increased power. - - -Adding and removing committers -============================== - -The Ansible Team will periodically review who is actively contributing to Ansible to grant or revoke -contributors' ability to commit on their own. GitHub Admins are the people who have the power to -actually manage the GitHub permissions. - - -Changing branch permissions for releases -======================================== - -When we make releases we make people go through a :ref:`release_managers` to push commits to that -branch. The GitHub admins are responsible for setting the branch so only the Release Manager can -commit to the branch when the release process reaches that stage and later opening the branch once -the release has been made. The Release manager will let the GitHub Admin know when this needs to be -done. - -.. seealso:: The `GitHub Admin Process Docs - `_ for instructions - on how to change branch permissions. diff --git a/docs/docsite/rst/community/how_can_I_help.rst b/docs/docsite/rst/community/how_can_I_help.rst deleted file mode 100644 index 38cb1db8d2a..00000000000 --- a/docs/docsite/rst/community/how_can_I_help.rst +++ /dev/null @@ -1,97 +0,0 @@ -.. _how_can_i_help: - -*************** -How can I help? -*************** - -.. contents:: - :local: - -Thanks for being interested in helping the Ansible project! - -There are many ways to help the Ansible project...but first, please read and understand the :ref:`code_of_conduct`. - -Become a power user -=================== - -A great way to help the Ansible project is to become a power user: - -* Use Ansible everywhere you can -* Take tutorials and classes -* Read the :ref:`official documentation ` -* Study some of the `many excellent books `_ about Ansible -* `Get certified `_. - -When you become a power user, your ability and opportunities to help the Ansible project in other ways will multiply quickly. - -Ask and answer questions online -=============================== - -There are many forums online where Ansible users ask and answer questions. Reach out and communicate with your fellow Ansible users. - -You can find the official :ref:`Ansible communication channels `. - -Review, fix, and maintain the documentation -=========================================== - -Typos are everywhere, even in the Ansible documentation. We work hard to keep the documentation up-to-date, but you may also find outdated examples. We offer easy ways to :ref:`report and/or fix documentation errors `. - -.. _ansible_community_meetup: - -Participate in your local meetup -================================ - -There are Ansible meetups `all over the world `_. Join your local meetup. Attend regularly. Ask good questions. Volunteer to give a presentation about how you use Ansible. - -If there is no meetup near you, we are happy to help you `start one `_. - -File and verify issues -====================== - -All software has bugs, and Ansible is no exception. When you find a bug, you can help tremendously by telling us about it: - -* Filing :ref:`issues for ansible-core `. -* Filing :ref:`issues for collections `. - - -If the bug you found already exists in an issue, you can help by verifying the behavior of the reported bug with a comment in that issue, or by reporting any additional information. - -Review and submit pull requests -=============================== - -As you become more familiar with how Ansible works, you may be able to fix issues or develop new features yourself. If you think you have a fix for a bug in Ansible, or if you have a new feature that you would like to share with millions of Ansible users, read all about the :ref:`development process ` to learn how to get your code accepted into Ansible. - -You can also get started with solving GitHub issues labeled with the ``easyfix`` and ``good_first_issue`` labels for: - -- `Ansible collections `_ -- `All other Ansible projects `_ - -When you choose an issue to work on, add a comment directly on the GitHub issue to say you are looking at it and let others know to avoid conflicting work. -You can also ask for help in a comment if you need it. - -Another good way to help is to review pull requests that other Ansible users have submitted. Ansible core keeps a full list of `open pull requests by file `_, so if a particular module or plugin interests you, you can easily keep track of all the relevant new pull requests and provide testing or feedback. Alternatively, you can review the pull requests for any collections that interest you. Click :guilabel:`Issue tracker` on the collection documentation page to find the issues and PRs for that collection. - -Become a collection maintainer -============================== - -Once you have learned about the development process and have contributed code to a collection, we encourage you to become a maintainer of that collection. There are hundreds of modules in dozens of Ansible collections, and the vast majority of them are written and maintained entirely by members of the Ansible community. - - See :ref:`collection maintainer guidelines ` to learn more about the responsibilities of being an Ansible collection maintainer. - -.. _community_working_groups: - -Join a working group -==================== - -Working groups are a way for Ansible community members to self-organize around particular topics of interest. We have working groups around various topics. To join or create a working group, please read the :ref:`Ansible Working Groups`. - - -Teach Ansible to others -======================= - -We are working on a standardized `Ansible workshop `_ that can provide a good hands-on introduction to Ansible usage and concepts. - -Social media -============ - -If you like Ansible and just want to spread the good word, feel free to share on your social media platform of choice, and let us know by using ``@ansible`` or ``#ansible``. We'll be looking for you. diff --git a/docs/docsite/rst/community/index.rst b/docs/docsite/rst/community/index.rst deleted file mode 100644 index b5ddb51d659..00000000000 --- a/docs/docsite/rst/community/index.rst +++ /dev/null @@ -1,24 +0,0 @@ -.. _ansible_community_guide: - -*********************** -Ansible Community Guide -*********************** - -.. 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 `_. - -Welcome to the Ansible Community Guide! - -The purpose of this guide is to teach you everything you need to know about being a contributing member of the Ansible community. All types of contributions are welcome and necessary for Ansible's continued success. - - -.. _community_toc: - -.. toctree:: - :maxdepth: 2 - - getting_started - contributor_path diff --git a/docs/docsite/rst/community/maintainers.rst b/docs/docsite/rst/community/maintainers.rst deleted file mode 100644 index bef1567ce6c..00000000000 --- a/docs/docsite/rst/community/maintainers.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. _maintainers: - -*************************************** -Guidelines for collection maintainers -*************************************** - -Thank you for being a community collection maintainer. This guide offers an overview of your responsibilities as a maintainer along with resources for additional information. The Ansible community hopes that you will find that maintaining a collection is as rewarding for you as having the collection content is for the wider community. - -.. toctree:: - :maxdepth: 1 - - maintainers_guidelines - maintainers_workflow - collection_contributors/collection_releasing - -In addition to the information here, module maintainers should be familiar with: - -* :ref:`General Ansible community development practices ` -* Documentation on :ref:`module development ` diff --git a/docs/docsite/rst/community/maintainers_guidelines.rst b/docs/docsite/rst/community/maintainers_guidelines.rst deleted file mode 100644 index cfdd0e9595b..00000000000 --- a/docs/docsite/rst/community/maintainers_guidelines.rst +++ /dev/null @@ -1,162 +0,0 @@ -.. _maintainer_requirements: - -Maintainer responsibilities -=========================== - -.. contents:: - :depth: 1 - :local: - -An Ansible collection maintainer is a contributor trusted by the community who makes significant and regular contributions to the project and who has shown themselves as a specialist in the related area. -Collection maintainers have :ref:`extended permissions` in the collection scope. - -Ansible collection maintainers provide feedback, responses, or actions on pull requests or issues to the collection(s) they maintain in a reasonably timely manner. They can also update the contributor guidelines for that collection, in collaboration with the Ansible community team and the other maintainers of that collection. - -In general, collection maintainers: - -- Act in accordance with the :ref:`code_of_conduct`. -- Subscribe to the collection repository they maintain (click :guilabel:`Watch > All activity` in GitHub). -- Keep README, development guidelines, and other general collections :ref:`maintainer_documentation` relevant. -- Review and commit changes made by other contributors. -- :ref:`Backport ` changes to stable branches. -- Address or assign issues to appropriate contributors. -- :ref:`Release collections `. -- Ensure that collections adhere to the :ref:`collections_requirements`. -- Track changes announced in `News for collection contributors and maintainers `_ and update a collection in accordance with these changes. -- Subscribe and submit news to the `Bullhorn newsletter `_. -- :ref:`Build a healthy community ` to increase the number of active contributors and maintainers around collections. -- Revise these guidelines to improve the maintainer experience for yourself and others. - -Multiple maintainers can divide responsibilities among each other. - -How to become a maintainer --------------------------- - -A person interested in becoming a maintainer and satisfying the :ref:`requirements` may either self-nominate or be nominated by another maintainer. - -To nominate a candidate, create a GitHub issue in the relevant collection repository. If there is no response, the repository is not actively maintained, or the current maintainers do not have permissions to add the candidate, please create the issue in the `ansible/community `_ repository. - -Communicating as a collection maintainer ------------------------------------------ - - Maintainers MUST subscribe to the `"Changes impacting collection contributors and maintainers" GitHub repo `_ and the `Bullhorn newsletter `_. If you have something important to announce through the newsletter (for example, recent releases), see the `Bullhorn's wiki page `_ to learn how. - - -Collection contributors and maintainers should also communicate through: - -* :ref:`communication_irc` appropriate to their collection, or if none exists, the general community and developer chat channels -* Mailing lists such as `ansible-announce `_ and `ansible-devel `_ -* Collection project boards, issues, and GitHub discussions in corresponding repositories -* Quarterly Contributor Summits. -* Ansiblefest and local meetups. - -See :ref:`communication` for more details on these communication channels. - -.. _wg_and_real_time_chat: - -Establishing working group communication ----------------------------------------------------------------- - -Working groups depend on efficient, real-time communication. -Project maintainers can use the following techniques to establish communication for working groups: - -* Find an existing :ref:`working_group_list` that is similar to your project and join the conversation. -* `Request `_ a new working group for your project. -* `Create `_ a public chat for your working group or `ask `_ the community team. -* Provide working group details and links to chat rooms in the contributor section of your project ``README.md``. -* Encourage contributors to join the chats and add themselves to the working group. - -See the :ref:`Communication guide ` to learn more about real-time chat. - -Community Topics ----------------- - -The Community and the `Steering Committee `_ asynchronously discuss and vote on the `Community Topics `_ which impact the whole project or its parts including collections and packaging. - -Share your opinion and vote on the topics to help the community make the best decisions. - -.. _expanding_community: - -Contributor Summits -------------------- - -The quarterly Ansible Contributor Summit is a global event that provides our contributors a great opportunity to meet each other, communicate, share ideas, and see that there are other real people behind the messages on Matrix or Libera Chat IRC, or GitHub. This gives a sense of community. Watch the `Bullhorn newsletter `_ for information when the next contributor summit, invite contributors you know, and take part in the event together. - -Weekly community Matrix/IRC meetings ------------------------------------- - -The Community and the Steering Committee come together at weekly meetings in the ``#ansible-community`` `Libera.Chat IRC `_ channel or in the bridged `#community:ansible.com `_ room on `Matrix `_ to discuss important project questions. Join us! Here is our `schedule `_. - -Expanding the collection community -=================================== - -.. note:: - - If you discover good ways to expand a community or make it more robust, edit this section with your ideas to share with other collection maintainers. - -Here are some ways you can expand the community around your collection: - - * Give :ref:`newcomers a positive first experience `. - * Invite contributors to join :ref:`real-time chats ` related to your project. - * Have :ref:`good documentation ` with guidelines for new contributors. - * Make people feel welcome personally and individually. - * Use labels to show easy fixes and leave non-critical easy fixes to newcomers and offer to mentor them. - * Be responsive in issues, PRs and other communication. - * Conduct PR days regularly. - * Maintain a zero-tolerance policy towards behavior violating the :ref:`code_of_conduct`. - * Put information about how people can register code of conduct violations in your ``README`` and ``CONTRIBUTING`` files. - * Include quick ways contributors can help and other documentation in your ``README``. - * Add and keep updated the ``CONTRIBUTORS`` and ``MAINTAINERS`` files. - * Create a pinned issue to announce that the collection welcomes new maintainers and contributors. - * Look for new maintainers among active contributors. - * Announce that your collection welcomes new maintainers. - * Take part and congratulate new maintainers in Contributor Summits. - - -.. _collection_new_contributors: - -Encouraging new contributors ------------------------------ - -Easy-fix items are the best way to attract and mentor new contributors. You should triage incoming issues to mark them with labels such as ``easyfix``, ``waiting_on_contributor``, and ``docs``. where appropriate. Do not fix these trivial non-critical bugs yourself. Instead, mentor a person who wants to contribute. - -For some easy-fix issues, you could ask the issue reporter whether they want to fix the issue themselves providing the link to a quick start guide for creating PRs. - -Conduct pull request days regularly. You could plan PR days, for example, on the last Friday of every month when you and other maintainers go through all open issues and pull requests focusing on old ones, asking people if you can help, and so on. If there are pull requests that look abandoned (for example, there is no response on your help offers since the previous PR day), announce that anyone else interested can complete the pull request. - -Promote active contributors satisfying :ref:`requirements` to maintainers. Revise contributors' activity regularly. - -If your collection found new maintainers, announce that fact in the `Bullhorn newsletter `_ and during the next Contributor Summit congratulating and thanking them for the work done. You can mention all the people promoted since the previous summit. Remember to invite the other maintainers to the Summit in advance. - -Some other general guidelines to encourage contributors: - -* Welcome the author and thank them for the issue or pull request. -* If there is a non-crucial easy-fix bug reported, politely ask the author to fix it themselves providing a link to :ref:`collection_quickstart`. -* When suggesting changes, try to use questions, not statements. -* When suggesting mandatory changes, do it as politely as possible providing documentation references. -* If your suggestion is optional or a matter of personal preference, please say it explicitly. -* When asking for adding tests or for complex code refactoring, say that the author is welcome to ask for clarifications and help if they need it. -* If somebody suggests a good idea, mention it or put a thumbs up. -* After merging, thank the author and reviewers for their time and effort. - -See the :ref:`review_checklist` for a list of items to check before you merge a PR. - -.. _maintainer_documentation: - -Maintaining good collection documentation -========================================== - -Maintainers look after the collection documentation to ensure it matches the :ref:`style_guide`. This includes keeping the following documents accurate and updated regularly: - -* Collection module and plugin documentation that adheres to the :ref:`Ansible documentation format `. -* Collection user guides that follow the :ref:`Collection documentation format `. -* Repository files that includes at least a ``README`` and ``CONTRIBUTING`` file. - -A good ``README`` includes a description of the collection, a link to the :ref:`code_of_conduct`, and details on how to contribute or a pointer to the ``CONTRIBUTING`` file. If your collection is a part of Ansible (is shipped with Ansible package), highlight that fact at the top of the collection's ``README``. - - The ``CONTRIBUTING`` file includes all the details or links to the details on how a new or continuing contributor can contribute to this collection. The ``CONTRIBUTING`` file should include: - -* Information or links to new contributor guidelines, such as a quick start on opening PRs. -* Information or links to contributor requirements, such as unit and integration test requirements. - -You can optionally include a ``CONTRIBUTORS`` and ``MAINTAINERS`` file to list the collection contributors and maintainers. diff --git a/docs/docsite/rst/community/maintainers_workflow.rst b/docs/docsite/rst/community/maintainers_workflow.rst deleted file mode 100644 index e14ce5c025d..00000000000 --- a/docs/docsite/rst/community/maintainers_workflow.rst +++ /dev/null @@ -1,95 +0,0 @@ -.. _maintainers_workflow: - - -Backporting and Ansible inclusion -================================== - -Each collection community can set its own rules and workflow for managing pull requests, bug reports, documentation issues, and feature requests, as well as adding and replacing maintainers. Maintainers review and merge pull requests following the: - -* :ref:`code_of_conduct` -* :ref:`maintainer_requirements` -* :ref:`Committer guidelines ` -* :ref:`PR review checklist` - -There can be two kinds of maintainers: :ref:`collection_maintainers` and :ref:`module_maintainers`. - -.. _collection_maintainers: - -Collection maintainers ----------------------- - -Collection-scope maintainers are contributors who have the ``write`` or higher access level in a collection. They have commit rights and can merge pull requests, among other permissions. - -When a collection maintainer considers a contribution to a file significant enough -(for example, fixing a complex bug, adding a feature, providing regular reviews, and so on), -they can invite the author to become a module maintainer. - - -.. _module_maintainers: - -Module maintainers ------------------- - -Module-scope maintainers exist in collections that have the `collection bot `_, -for example, `community.general `_ -and `community.network `_. - -Being a module maintainer is the stage prior to becoming a collection maintainer. Module maintainers are contributors who are listed in ``.github/BOTMETA.yml``. The scope can be any file (for example, a module or plugin), directory, or repository. Because in most cases the scope is a module or group of modules, we call these contributors module maintainers. The collection bot notifies module maintainers when issues/pull requests related to files they maintain are created. - -Module maintainers have indirect commit rights implemented through the `collection bot `_. -When two module maintainers comment with the keywords ``shipit``, ``LGTM``, or ``+1`` on a pull request -which changes a module they maintain, the collection bot merges the pull request automatically. - -For more information about the collection bot and its interface, -see to the `Collection bot overview `_. - - -Releasing a collection ----------------------- - -Collection maintainers are responsible for releasing new versions of a collection. Generally, releasing a collection consists of: - -#. Planning and announcement. -#. Generating a changelog. -#. Creating a release git tag and pushing it. -#. Automatically publishing the release tarball on `Ansible Galaxy `_ through the `Zuul dashboard `_. -#. Final announcement. -#. Optionally, `file a request to include a new collection into the Ansible package `_. - -See :ref:`releasing_collections` for details. - -.. _Backporting: - -Backporting ------------- - -Collection maintainers backport merged pull requests to stable branches -following the `semantic versioning `_ and release policies of the collections. - -The manual backport process is similar to the :ref:`ansible-core backporting guidelines `. - -For convenience, backporting can be implemented automatically using GitHub bots (for example, with the `Patchback app `_) and labeling as it is done in `community.general `_ and `community.network `_. - - -.. _including_collection_ansible: - -Including a collection in Ansible ------------------------------------ - -If a collection is not included in Ansible (not shipped with Ansible package), maintainers can submit the collection for inclusion by creating a discussion under the `ansible-collections/ansible-inclusion repository `_. For more information, see the `repository's README `_, and the :ref:`Ansible community package collections requirements `. - -Stepping down as a collection maintainer -=========================================== - -Times change, and so may your ability to continue as a collection maintainer. We ask that you do not step down silently. - -If you feel you don't have time to maintain your collection anymore, you should: - -- Inform other maintainers about it. -- If the collection is under the ``ansible-collections`` organization, also inform relevant :ref:`communication_irc`, the ``community`` chat channels on IRC or matrix, or by email ``ansible-community@redhat.com``. -- Look at active contributors in the collection to find new maintainers among them. Discuss the potential candidates with other maintainers or with the community team. -- If you failed to find a replacement, create a pinned issue in the collection, announcing that the collection needs new maintainers. -- Make the same announcement through the `Bullhorn newsletter `_. -- Please be around to discuss potential candidates found by other maintainers or by the community team. - -Remember, this is a community, so you can come back at any time in the future. diff --git a/docs/docsite/rst/community/other_tools_and_programs.rst b/docs/docsite/rst/community/other_tools_and_programs.rst deleted file mode 100644 index f507e5eabde..00000000000 --- a/docs/docsite/rst/community/other_tools_and_programs.rst +++ /dev/null @@ -1,109 +0,0 @@ -.. _other_tools_and_programs: - -************************ -Other Tools and Programs -************************ - -.. contents:: - :local: - -The Ansible community uses a range of tools for working with the Ansible project. This is a list of some of the most popular of these tools. - -If you know of any other tools that should be added, this list can be updated by clicking "Edit on GitHub" on the top right of this page. - - -Popular editors -=============== - - -Emacs ------ - -A free, open-source text editor and IDE that supports auto-indentation, syntax highlighting and built in terminal shell(among other things). - -* `yaml-mode `_ - YAML highlighting and syntax checking. -* `jinja2-mode `_ - Jinja2 highlighting and syntax checking. -* `magit-mode `_ - Git porcelain within Emacs. -* `lsp-mode `_ - Ansible syntax highlighting, auto-completion and diagnostics. - - -PyCharm -------- - -A full IDE (integrated development environment) for Python software development. It ships with everything you need to write python scripts and complete software, including support for YAML syntax highlighting. It's a little overkill for writing roles/playbooks, but it can be a very useful tool if you write modules and submit code for Ansible. Can be used to debug ``ansible-core``. For more information, see `PyCharm `_ - - -Sublime -------- - -A closed-source, subscription GUI text editor. You can customize the GUI with themes and install packages for language highlighting and other refinements. You can install Sublime on Linux, macOS and Windows. Useful Sublime plugins include: - -* `GitGutter `_ - shows information about files in a git repository. -* `SideBarEnhancements `_ - provides enhancements to the operations on Sidebar of Files and Folders. -* `Sublime Linter `_ - a code-linting framework for Sublime Text 3. -* `Pretty YAML `_ - prettifies YAML for Sublime Text 2 and 3. -* `Yamllint `_ - a Sublime wrapper around yamllint. - - -vim ---- - -An open-source, free command-line text editor. Useful vim plugins include: - -* `Ansible vim `_ - vim syntax plugin for Ansible 2.x, it supports YAML playbooks, Jinja2 templates, and Ansible's hosts files. -* `Ansible vim and neovim plugin `_ - vim plugin (lsp client) for Ansible, it supports autocompletion, syntax highlighting, hover, diagnostics, and goto support. - - -Visual studio code ------------------- - -An open-source, free GUI text editor created and maintained by Microsoft. Useful Visual Studio Code plugins include: - -* `Ansible extension by Red Hat `_ - provides autocompletion, syntax highlighting, hover, diagnostics, goto support, and command to run ansible-playbook and ansible-navigator tool for both local and execution-environment setups. -* `YAML Support by Red Hat `_ - provides YAML support through yaml-language-server with built-in Kubernetes and Kedge syntax support. - - -.. note:: - - the Visual Studio Code Ansible extension is maintained by the Ansible community and Red Hat. - - - - -Development tools -================= - -Finding related issues and PRs ------------------------------- - -There are various ways to find existing issues and pull requests (PRs) - -- `jctanner's Ansible Tools `_ - miscellaneous collection of useful helper scripts for Ansible development. - -.. _validate-playbook-tools: - - -Tools for validating playbooks -============================== - -- `Ansible Lint `_ - a highly configurable linter for Ansible playbooks. -- `Ansible Review `_ - an extension of Ansible Lint designed for code review. -- `Molecule `_ - a testing framework for Ansible plays and roles. -- `yamllint `__ - a command-line utility to check syntax validity including key repetition and indentation issues. - - - -Other tools -=========== - -- `Ansible Inventory Grapher `_ - visually displays inventory inheritance hierarchies and at what level a variable is defined in inventory. -- `Ansible Shell `_ - an interactive shell for Ansible with built-in tab completion for all the modules. -- `Ansible Silo `_ - a self-contained Ansible environment by Docker. -- `Ansigenome `_ - a command line tool designed to help you manage your Ansible roles. -- `antsibull-changelog `_ - a changelog generator for Ansible collections. -- `antsibull-docs `_ - generates docsites for collections and can validate collection documentation. -- `ARA `_ - ARA Records Ansible playbooks and makes them easier to understand and troubleshoot with a reporting API, UI and CLI. -- `Awesome Ansible `_ - a collaboratively curated list of awesome Ansible resources. -- `nanvault `_ - a standalone tool to encrypt and decrypt files in the Ansible Vault format, featuring UNIX-style composability. -- `OpsTools-ansible `_ - uses Ansible to configure an environment that provides the support of `OpsTools `_, namely centralized logging and analysis, availability monitoring, and performance monitoring. -- `ansibledb `_ - Flask API server that uses MongoDB to store Ansible reports and facts. Along with different query capabilities, this tool provides a web UI for viewing Ansible reports, facts, and logs. diff --git a/docs/docsite/rst/community/release_managers.rst b/docs/docsite/rst/community/release_managers.rst deleted file mode 100644 index 97949a55f7d..00000000000 --- a/docs/docsite/rst/community/release_managers.rst +++ /dev/null @@ -1,81 +0,0 @@ -.. _release_managers: - -************************** -Release Manager Guidelines -************************** - -.. contents:: Topics - -The release manager's purpose is to ensure a smooth release. To achieve that goal, they need to -coordinate between: - -* Developers with commit privileges on the `Ansible GitHub repository `_ -* Contributors without commit privileges -* The community -* Ansible documentation team - -Pre-releases: what and why -========================== - -Pre-releases exist to draw testers. They give people who don't feel comfortable running from source -control a means to get an early version of the code to test and give us feedback. To ensure we get -good feedback about a release, we need to make sure all major changes in a release are put into -a pre-release. Testers must be given time to test those changes before the final release. Ideally we -want there to be sufficient time between pre-releases for people to install and test one version for -a span of time. Then they can spend more time using the new code than installing the latest -version. - -The right length of time for a tester is probably around two weeks. However, for our three-to-four month -development cycle to work, we compress this down to one week; any less runs the risk -of people spending more time installing the code instead of running it. However, if there's a time -crunch (with a release date that cannot slip), it is better to release with new changes than to hold -back those changes to give people time to test between. People cannot test what is not released, so -we have to get those tarballs out there even if people feel they have to install more frequently. - - -Beta releases -------------- - -In a beta release, we know there are still bugs. We will continue to accept fixes for these. -Although we review these fixes, sometimes they can be invasive or potentially destabilize other -areas of the code. - -During the beta, we will no longer accept feature submissions. - - -Release candidates ------------------- - -In a release candidate, we've fixed all known blockers. Any remaining bugfixes are -ones that we are willing to leave out of the release. At this point we need user testing to -determine if there are any other blocker bugs lurking. - -Blocker bugs generally are those that cause significant problems for users. Regressions are -more likely to be considered blockers because they will break present users' usage of Ansible. - -The Release Manager will cherry-pick fixes for new release blockers. The release manager will also -choose whether to accept bugfixes for isolated areas of the code or defer those to the next minor -release. By themselves, non-blocker bugs will not trigger a new release; they will only make it -into the next major release if blocker bugs require that a new release be made. - -The last RC should be as close to the final as possible. The following things may be changed: - - * Version numbers are changed automatically and will differ as the pre-release tags are removed from - the versions. - * Tests and :file:`docs/docsite/` can differ if really needed as they do not break runtime. - However, the release manager may still reject them as they have the potential to cause - breakage that will be visible during the release process. - -.. note:: We want to specifically emphasize that code (in :file:`bin/`, :file:`lib/ansible/`, and - :file:`setup.py`) must be the same unless there are extraordinary extenuating circumstances. If - there are extenuating circumstances, the Release Manager is responsible for notifying groups - which would want to test the code. - - -Ansible release process -======================= - -The release process is kept in a `separate document -`_ -so that it can be easily updated during a release. If you need access to edit this, please ask one -of the current release managers to add you. diff --git a/docs/docsite/rst/community/reporting_bugs_and_features.rst b/docs/docsite/rst/community/reporting_bugs_and_features.rst deleted file mode 100644 index a972603af36..00000000000 --- a/docs/docsite/rst/community/reporting_bugs_and_features.rst +++ /dev/null @@ -1,59 +0,0 @@ - -.. _reporting_bugs_and_features: - -************************************** -Reporting bugs and requesting features -************************************** - -.. contents:: - :local: - -.. _reporting_bugs: - -Reporting a bug -=============== - -Security bugs -------------- - -Ansible practices responsible disclosure. To report security-related bugs, send an email to `security@ansible.com `_ for an immediate response. Do not submit a ticket or post to any public groups. - -Bugs in ansible-core --------------------- - -Before reporting a bug, search in GitHub for `already reported issues `_ and `open pull requests `_ to see if someone has already addressed your issue. Unsure if you found a bug? Report the behavior on the :ref:`mailing list or community chat first `. - -Also, use the mailing list or chat to discuss whether the problem is in ``ansible-core`` or a collection, and for "how do I do this" type questions. - -You need a free GitHub account to `report bugs `_ that affect: - -- multiple plugins -- a plugin that remained in the ansible/ansible repo -- the overall functioning of Ansible - -How to write a good bug report ------------------------------- - -If you find a bug, open an issue using the `issue template `_. - -Fill out the issue template as completely and as accurately as possible. Include: - -* your Ansible version -* the expected behavior and what you've tried, including the exact commands you were using or tasks you are running. -* the current behavior and why you think it is a bug -* the steps to reproduce the bug -* a minimal reproducible example and comments describing examples -* any relevant configurations and the components you used -* any relevant output plus ``ansible -vvvv`` (debugging) output -* add the output of ``ansible-test-env --show`` when filing bug reports involving ``ansible-test``. - -When sharing YAML in playbooks, ensure that you preserve formatting using `code blocks `_. For multiple-file content, use gist.github.com, more durable than Pastebin content. - -.. _request_features: - -Requesting a feature -==================== - -Before you request a feature, check what is :ref:`planned for future Ansible Releases `. Check `existing pull requests tagged with feature `_. - -To get your feature into Ansible, :ref:`submit a pull request `, either against ansible-core or a collection. See also :ref:`ansible_collection_merge_requirements`. For ``ansible-core``, you can also open an issue in `ansible/ansible `_ or in a corresponding collection repository (To find the correct issue tracker, refer to :ref:`Bugs in collections` ). diff --git a/docs/docsite/rst/community/reporting_collections.rst b/docs/docsite/rst/community/reporting_collections.rst deleted file mode 100644 index 1d8c2e60f9f..00000000000 --- a/docs/docsite/rst/community/reporting_collections.rst +++ /dev/null @@ -1,36 +0,0 @@ -.. _reporting_bugs_in_collections: - -*********************************** -Requesting changes to a collection -*********************************** - -.. contents:: - :local: - -Reporting a bug -=============== - -Security bugs -------------- - -Ansible practices responsible disclosure - if this is a security-related bug, email `security@ansible.com `_ instead of filing a ticket or posting to any public groups, and you will receive a prompt response. - - -Bugs in collections -------------------- - -Many bugs only affect a single module or plugin. If you find a bug that affects a module or plugin hosted in a collection, file the bug in the repository of the :ref:`collection `: - - #. Find the collection on `Galaxy `_. - #. Click on the Issue Tracker link for that collection. - #. Follow the contributor guidelines or instructions in the collection repo. - -If you are not sure whether a bug is in ansible-core or in a collection, you can report the behavior on the :ref:`mailing list or community chat channel first `. - -Requesting a feature -==================== - -Before you request a feature, check what is :ref:`planned for future Ansible Releases `. -The best way to get a feature into an Ansible collection is to :ref:`submit a pull request `, either against ansible-core or against a collection. See also the :ref:`ansible_collection_merge_requirements`. - -You can also submit a feature request by opening an issue in the collection repository. diff --git a/docs/docsite/rst/community/steering/community_steering_committee.rst b/docs/docsite/rst/community/steering/community_steering_committee.rst deleted file mode 100644 index 5a5f2672bf2..00000000000 --- a/docs/docsite/rst/community/steering/community_steering_committee.rst +++ /dev/null @@ -1,165 +0,0 @@ - -.. _steering_responsibilities: - -Steering Committee mission and responsibilities -=============================================== - -The Steering Committee mission is to provide continuity, guidance, and suggestions to the Ansible community to ensure the delivery and high quality of the Ansible package. In addition, the committee helps decide the technical direction of the Ansible project. It is responsible for approving new proposals and policies in the community, package, and community collections world, new community collection-inclusion requests, and other technical aspects regarding inclusion and packaging. -The Committee should reflect the scope and breadth of the Ansible community. - -Steering Committee responsibilities ------------------------------------- - -The Committee: - -* Designs policies and procedures for the community collections world. -* Votes on approval changes to established policies and procedures. -* Reviews community collections for compliance with the policies. -* Helps create and define roadmaps for our deliverables such as the ``ansible`` package, major community collections, and documentation. -* Reviews community collections submitted for inclusion in the Ansible package and decides whether to include them or not. -* Review other proposals of importance that need the Committee's attention and provide feedback. - -.. _steering_members: - -Current Steering Committee members ------------------------------------ - -The following table lists the current Steering Committee members. See :ref:`steering_past_members` for a list of past members. - - - -.. table:: Current Steering committee members - - +------------------+---------------+-------------+ - | Name | GitHub | Start year | - +==================+===============+=============+ - | Alexei Znamensky | russoz | 2022 | - +------------------+---------------+-------------+ - | Alicia Cozine | acozine | 2021 | - +------------------+---------------+-------------+ - | Andrew Klychkov | Andersson007 | 2021 | - +------------------+---------------+-------------+ - | Brad Thornton | cidrblock | 2021 | - +------------------+---------------+-------------+ - | Brian Scholer | briantist | 2022 | - +------------------+---------------+-------------+ - | Dylan Silva | thaumos | 2021 | - +------------------+---------------+-------------+ - | Felix Fontein | felixfontein | 2021 | - +------------------+---------------+-------------+ - | James Cassell | jamescassell | 2021 | - +------------------+---------------+-------------+ - | John Barker | gundalow | 2021 | - +------------------+---------------+-------------+ - | Mario Lenz | mariolenz | 2022 | - +------------------+---------------+-------------+ - | Markus Bergholz | markuman | 2022 | - +------------------+---------------+-------------+ - | Maxwell G | gotmax23 | 2022 | - +------------------+---------------+-------------+ - | Sorin Sbarnea | ssbarnea | 2021 | - +------------------+---------------+-------------+ - - -John Barker (`gundalow `_) has been elected by the Committee as its :ref:`chairperson`. - -Committee members are selected based on their active contribution to the Ansible Project and its community. See :ref:`community_steering_guidelines` to learn details. - -Creating new policy proposals & inclusion requests ----------------------------------------------------- - -The Committee uses the `community-topics repository `_ to asynchronously discuss with the Community and vote on Community topics in corresponding issues. - -You can create a new issue in the `community-topics repository `_ as a discussion topic if you want to discuss an idea that impacts any of the following: - - * Ansible Community - * Community collection best practices and requirements - * Community collection inclusion policy - * The Community governance - * Other proposals of importance that need the Committee's or overall Ansible community attention - - -To request changes to the inclusion policy and collection requirements: - -#. Submit a new pull request to the `ansible-collections/overview `_ repository. - -#. Create a corresponding issue containing the rationale behind these changes in the `community-topics repository `_ repository. - -To submit new collections for inclusion into the Ansible package: - -* Submit the new collection inclusion requests through a new discussion in the `ansible-inclusion `_ repository. - -Depending on a topic you want to discuss with the Community and the Committee, as you prepare your proposal, please consider the requirements established by: - -* :ref:`code_of_conduct`. -* :ref:`collections_requirements`. -* `Ansible Collection Inclusion Checklist `_. - -Community topics workflow -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The Committee uses the `Community-topics workflow `_ to asynchronously discuss and vote on the `community-topics `_. - -The quorum, the minimum number of Committee members who must vote on a topic in order for a decision to be officially made, is half of the whole number of the Committee members. If the quorum number contains a fractional part, it is rounded up to the next whole number. For example, if there are thirteen members currently in the committee, the quorum will be seven. - -Votes must always have "no change" as an option. - -In case of equal numbers of votes for and against a topic, the chairperson's vote will break the tie. For example, if there are six votes for and six votes against a topic, and the chairperson's vote is among those six which are for the topic, the final decision will be positive. If the chairperson has not voted yet, other members ask them to vote. - -For votes with more than two options, one choice must have at least half of the votes. If two choices happen to both have half of the votes, the chairperson's vote will break the tie. If no choice has at least half of the votes, the vote choices have to be adjusted so that a majority can be found for a choice in a new vote. - -Community topics triage -^^^^^^^^^^^^^^^^^^^^^^^ - -The Committee conducts a triage of `community topics `_ periodically (every three to six months). - -The triage goals are: - -* Sparking interest for forgotten topics. -* Identifying and closing irrelevant topics, for example, when the reason of the topic does not exist anymore or the topic is out of the Committee responsibilities scope. -* Identifying and closing topics that the Community are not interested in discussing. As indicators, it can be absence of comments or no activity in comments, at least, for the last six months. -* Identifying and closing topics that were solved and implemented but not closed (in this case, such a topic can be closed on the spot with a comment that it has been implemented). -* Identifying topics that have been in pending state for a long time, for example, when it is waiting for actions from someone for several months or when the topics were solved but not implemented. - -A person starting the triage: - -#. Identifies the topics mentioned above. -#. Creates a special triage topic containing an enumerated list of the topics-candidates for closing. -#. Establishes a vote date considering a number of topics, their complexity and comment-history size giving the Community sufficient time to go through and discuss them. -#. The Community and the Committee vote on each topic-candidate listed in the triage topic whether to close it or keep it open. - -Collection inclusion requests workflow -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When reviewing community collection `inclusion requests `_, the Committee members check if a collection adheres to the :ref:`collections_requirements`. - -#. A Committee member who conducts the inclusion review copies the `Ansible community collection checklist `_ into a corresponding `discussion `_. - -#. In the course of the review, the Committee member marks items as completed or leaves a comment saying whether the reviewer expects an issue to be addressed or whether it is optional (for example, it could be **MUST FIX:** or **SHOULD FIX:** under an item). - -#. For a collection to be included in the Ansible community package, the collection: - - * MUST be reviewed and approved by at least two persons, where at least one person is a Steering Committee member. - * For a Non-Steering Committee review to be counted for inclusion, it MUST be checked and approved by *another* Steering Committee member. - * Reviewers must not be involved significantly in development of the collection. They must declare any potential conflict of interest (for example, being friends/relatives/coworkers of the maintainers/authors, being users of the collection, or having contributed to that collection recently or in the past). - -#. After the collection gets two or more Committee member approvals, a Committee member creates a `community topic `_ linked to the corresponding inclusion request. The issue's description says that the collection has been approved by two or more Committee members and establishes a date (a week by default) when the inclusion decision will be considered made. This time period can be used to raise concerns. - -#. If no objections are raised up to the established date, the inclusion request is considered successfully resolved. In this case, a Committee member: - - #. Declares the decision in the topic and in the inclusion request. - #. Moves the request to the ``Resolved reviews`` category. - #. Adds the collection to the ``ansible.in`` file in a corresponding directory of the `ansible-build-data repository `_. - #. Announces the inclusion through the `Bullhorn newsletter `_. - #. Closes the topic. - -Community Working Group meetings ---------------------------------- - -See the Community Working Group meeting `schedule `_. Meeting summaries are posted in the `Community Working Group Meeting Agenda `_ issue. - -.. note:: - - Participation in the Community Working Group meetings is optional for Committee members. Decisions on community topics are made asynchronously in the `community-topics `_ repository. - -The meeting minutes can be found at the `fedora meetbot site `_ and the same is posted to `Ansible Devel Mailing List `_ after every meeting. diff --git a/docs/docsite/rst/community/steering/steering_committee_membership.rst b/docs/docsite/rst/community/steering/steering_committee_membership.rst deleted file mode 100644 index 1b636f1302e..00000000000 --- a/docs/docsite/rst/community/steering/steering_committee_membership.rst +++ /dev/null @@ -1,139 +0,0 @@ -.. _community_steering_guidelines: - -Steering Committee membership guidelines -========================================== - -This document describes the expectations and policies related to membership in the :ref:`Ansible Community Steering Committee ` (hereinafter the Committee). - -.. contents:: Topics: - -.. _steering_expectations: - -Expectations of a Steering Committee member -------------------------------------------- - - -As a Committee member, you agree to: - -#. Abide by the :ref:`code_of_conduct` in all your interactions with the Community. -#. Be a Community ambassador by representing its needs within the Committee and throughout the decision making process. -#. Asynchronously participate in discussions and voting on the `Community Topics `_. -#. Review other proposals of importance that need the Committee's attention and provide feedback. -#. Act for the sake of the Community by not promoting corporate or individual agenda during the decision making process. -#. Engage with the Community in a professional and positive manner, encourage community members to express their opinion. - -.. _Joining the committee: - -Joining the Steering Committee -------------------------------- - -Eligibility -^^^^^^^^^^^ - -A person is eligible to become a Committee member if they have: - -#. A wide knowledge of Ansible and/or its related projects. -#. Active contributions to Ansible and/or related projects in any form described in the :ref:`collections_contributions`. -#. A consent to follow the :ref:`steering_expectations`. - -Process -^^^^^^^^ - -The process to join the Steering Committee consists of the following steps: - -#. Any community member may nominate someone or themselves for Committee membership by contacting one of the :ref:`current Committee members `) or by sending an email to ``ansible-community@redhat.com``. -#. A Committee member who receives the nomination must inform the Committee about it by forwarding the full message. -#. The vote is conducted by email. Nominees must receive a majority of votes from the present Committee members to be added to the Committee. -#. Provided that the vote result is positive, it is announced via the `Bullhorn `_ newsletter and the new member is added to the :ref:`Committee member list `. - -Leaving the Steering Committee -------------------------------- - -Steering Committee members can resign voluntarily or be removed by the -rest of the Steering Committee under certain circumstances. See the details -below. - -.. _Voluntarily leaving process: - -Voluntarily leaving the Steering Committee -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -A Committee member can voluntarily leave the Committee. -In this case, they notify the other members, create an issue in the `Community Topics `_ repository announcing the resignation, and after that they are no longer considered Committee members. - -Committee members who resign and later change their mind can -rejoin the Committee by following the :ref:`Process for joining the Steering Committee`. - -Involuntarily leaving the Steering Committee -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -A Committee member will be removed from the Committee if they: - -#. Do not participate in asynchronous discussions and voting on the `Community Topics `_ for more than 3 months in a row. -#. Participate unreasonably irregularly (for example, once a month for several months). Unreasonably is defined by other Committee members considering circumstances in each particular case. -#. Violate the :ref:`code_of_conduct`. - -.. _Absence or irregular participation removal process: - -Absence or irregular participation in discussing topics and votes -.................................................................. - -In case of absence or irregular participation, the involuntarily removal process consists of the following steps: - -#. Another Committee member (hereinafter the initiator) contacts the person by email asking if they are still interested in fulfilling their Committee member's duties. -#. If they respond that they are not interested, the initiator asks the person to step down on their own following the :ref:`Voluntarily leaving process`. -#. If there has been no response or stepping down issue created by the person within a reasonable time, the initiator notifies other Committee members about the situation. -#. In case of agreement among the Committee about the need for removal, the initiator provides a draft of a corresponding topic's description to the Committee via email for discussion and approval. - - * The topic's title is ``Steering Committee member audit.``. It must not contain the person's name or other identifying information. - - * The description must not contain or imply any forms of condemnation. - - * It must mention that the person has been inactive for an unknown reason for the last N months and that, in accordance with the Steering Committee policies, their place should be freed for another person who can continue their great job. - - * The description must mention person's achievements and thanks for their time and effort they spent serving for the Community, Committee, and the Project, and a hope that one day they will come back. - -#. The initiator creates the topic in the `Community Topics `_ repository containing the description and the title from the draft. -#. The Committee members vote on the topic. - -Ansible Community Code of Conduct violations -............................................. - -In case of the `Ansible Community Code of Conduct `_ violations, the process is the same as above except steps 1-2. Instead: - -#. The initiator reports the case to the Committee via email. - -#. The Committee discusses the case internally, evaluates its severity, and possible solutions. - -#. If the Committee concludes that the violation is not severe, it develops a proposal to the person on how the situation can be corrected and further interactions with the Community improved. - -#. A Committee representative reaches out to the person with the proposal. - -#. The removal process starts if: - - * The Committee decided that the severity of the violation excludes a possibility of further membership. - - * The person does not respond to the proposal. - - * The person explicitly rejects the proposal. - -In case of starting the removal process, the topic's description in the reason's part changes correspondingly. - -.. _chairperson: - -Chairperson ------------- - -The chairperson election will happen once a year around the time of -Ansible Fest. If the current chairperson has to step down early, the election happens immediately. - -The process of the election consist of the following steps: - -#. Members interested in being the chairperson will inform a - person responsible for arranging the election about that. -#. Conduct anonymous voting somewhere. -#. Internally and publicly announce the elected candidate. - -The chairperson has the following powers unlike regular members: - -* The chairperson's vote breaks ties to resolve deadlocks when equal numbers of steering committee members vote for and against a `community topic `_. diff --git a/docs/docsite/rst/community/steering/steering_committee_past_members.rst b/docs/docsite/rst/community/steering/steering_committee_past_members.rst deleted file mode 100644 index 212617372a6..00000000000 --- a/docs/docsite/rst/community/steering/steering_committee_past_members.rst +++ /dev/null @@ -1,31 +0,0 @@ -.. _steering_past_members: - -Steering Committee past members -================================ - -The Ansible Community is very grateful to these amazing **nonreplaceable** -people for their great service to the Community and the project! - - -.. table:: Steering Committee past members - - +------------------+-----------+-------------------+ - | Name | GitHub | Years of service | - +==================+===========+===================+ - | Jill Rouleau | jillr | 2021-2022 | - +------------------+-----------+-------------------+ - | Tadej Borovšak | tadeboro | 2021-2022 | - +------------------+-----------+-------------------+ - | Toshio Kuratomi | abadger | 2021 | - +------------------+-----------+-------------------+ - - -We'd also like to thank our past chairpersons for their contributions to Ansible. - -.. table:: Steering Committee past chairpersons - - +------------------+-----------+-------------------+ - | Name | GitHub | Years of service | - +==================+===========+===================+ - | Tadej Borovšak | tadeboro | 2021-2022 | - +------------------+-----------+-------------------+ diff --git a/docs/docsite/rst/community/steering/steering_index.rst b/docs/docsite/rst/community/steering/steering_index.rst deleted file mode 100644 index 78d435a1252..00000000000 --- a/docs/docsite/rst/community/steering/steering_index.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. _community_steering_committee: - -************************************ -Ansible Community Steering Committee -************************************ - -This section focuses on the guidelines and membership of the Ansible Community Steering Committee. - -.. toctree:: - :maxdepth: 1 - - community_steering_committee - steering_committee_membership - steering_committee_past_members diff --git a/docs/docsite/rst/core_index.rst b/docs/docsite/rst/core_index.rst deleted file mode 100644 index e76fe7108c7..00000000000 --- a/docs/docsite/rst/core_index.rst +++ /dev/null @@ -1,110 +0,0 @@ -.. _ansible_core_documentation: - -.. - This is the index file for ansible-core. It gets symlinked to index.rst by the Makefile - -************************** -Ansible Core Documentation -************************** - -About ansible-core -=================== - -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 core, or ``ansible-core`` is the main building block and architecture for Ansible, and includes: - -* CLI tools such as ``ansible-playbook``, ``ansible-doc``. and others for driving and interacting with automation. -* The Ansible language that uses YAML to create a set of rules for developing Ansible Playbooks and includes functions such as conditionals, blocks, includes, loops, and other Ansible imperatives. -* An architectural framework that allows extensions through Ansible collections. - -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 `_, 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-core`` noted in the upper left corner of this page. We maintain multiple versions of ``ansible-core`` 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-core`` 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/core_porting_guides - -.. toctree:: - :maxdepth: 2 - :caption: Using Ansible Core - - 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 Core - - community/index - community/contributions - community/advanced_index - dev_guide/style_guide/index - -.. toctree:: - :maxdepth: 2 - :caption: Extending Ansible - - 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_core_roadmap_index.rst diff --git a/docs/docsite/rst/dev_guide/ansible_index.rst b/docs/docsite/rst/dev_guide/ansible_index.rst deleted file mode 100644 index a660df06e57..00000000000 --- a/docs/docsite/rst/dev_guide/ansible_index.rst +++ /dev/null @@ -1,92 +0,0 @@ -.. _developer_guide: - -*************** -Developer Guide -*************** - -.. 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 `_. - -Welcome to the Ansible Developer Guide! - -**Who should use this guide?** - -If you want to extend Ansible by using a custom module or plugin locally, creating a module or plugin, adding functionality to an existing module, or expanding test coverage, this guide is for you. We've included detailed information for developers on how to test and document modules, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository. - -Find the task that best describes what you want to do: - -* I'm looking for a way to address a use case: - - * I want to :ref:`add a custom plugin or module locally `. - * I want to figure out if :ref:`developing a module is the right approach ` for my use case. - * I want to :ref:`develop a collection `. - * I want to :ref:`contribute to an Ansible-maintained collection `. - * I want to :ref:`contribute to a community-maintained collection `. - * I want to :ref:`migrate a role to a collection `. - -* I've read the info above, and I'm sure I want to develop a module: - - * What do I need to know before I start coding? - * I want to :ref:`set up my Python development environment `. - * I want to :ref:`get started writing a module `. - * I want to write a specific kind of module: - * a :ref:`network module ` - * a :ref:`Windows module `. - * an :ref:`Amazon module `. - * an :ref:`oVirt/RHV module `. - * a :ref:`VMware module `. - * I want to :ref:`write a series of related modules ` that integrate Ansible with a new product (for example, a database, cloud provider, network platform, and so on). - -* I want to refine my code: - - * I want to :ref:`debug my module code `. - * I want to :ref:`add tests `. - * I want to :ref:`document my module `. - * I want to :ref:`document my set of modules for a network platform `. - * I want to follow :ref:`conventions and tips for clean, usable module code `. - * I want to :ref:`make sure my code runs on Python 2 and Python 3 `. - -* I want to work on other development projects: - - * I want to :ref:`write a plugin `. - * I want to :ref:`connect Ansible to a new source of inventory `. - * I want to :ref:`deprecate an outdated module `. - -* I want to contribute back to the Ansible project: - - * I want to :ref:`understand how to contribute to Ansible `. - * I want to :ref:`contribute my module or plugin `. - * I want to :ref:`understand the license agreement ` for contributions to Ansible. - -If you prefer to read the entire guide, here's a list of the pages in order. - -.. toctree:: - :maxdepth: 2 - - developing_locally - developing_modules - developing_modules_general - developing_modules_checklist - developing_modules_best_practices - developing_python_3 - debugging - developing_modules_documenting - sidecar - developing_modules_general_windows - developing_modules_in_groups - testing - module_lifecycle - developing_plugins - developing_inventory - developing_core - developing_program_flow_modules - developing_api - developing_rebasing - developing_module_utilities - developing_collections - migrating_roles - collections_galaxy_meta - overview_architecture diff --git a/docs/docsite/rst/dev_guide/core_branches_and_tags.rst b/docs/docsite/rst/dev_guide/core_branches_and_tags.rst deleted file mode 100644 index aaef4aa5695..00000000000 --- a/docs/docsite/rst/dev_guide/core_branches_and_tags.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. _core_branches_and_tags: - -****************************************** -``ansible-core`` project branches and tags -****************************************** - -``devel`` branch -================ - -All new development on the next version of ``ansible-core`` occurs exclusively in the ``devel`` branch, -and all bugfixes to prior releases must first be merged to devel before being backported to one or more stable branches -for inclusion in servicing releases. Around the Beta 1 milestone, a new ``stable-X.Y`` branch is cut from ``devel``, -which is then updated to host development of the ``X.Y+1`` release. External automated testing of Ansible content from -``devel`` is not generally recommended. - -``stable-X.Y`` branches -======================= - -All ``ansible-core`` ``X.Y.Z`` releases are created from a corresponding ``stable-X.Y`` branch. A -release's stable branch is typically cut from ``devel`` around ``X.Y.0 beta 1`` (when the release is feature complete). -All further bugfixes (no enhancements!) must be made against ``devel`` and backported to applicable stable branches. - -``vX.Y.Z`` tags -=============== - -Each ``ansible-core vX.Y.Z`` release is tagged from the release commit in the corresponding ``stable-X.Y`` branch, -allowing access to the exact source used to create the release. As of ``ansible-core`` 2.13, the auto-generated GitHub -tarball of the tag contents is considered the official canonical release artifact. - - -.. _milestone_branch: - -``milestone`` branch -==================== - -A ``milestone`` branch is a slow-moving stream of the ``devel`` branch, intended for external testing of ``ansible-core`` -features under active development. As described in the :ref:`ansible_core_roadmaps` for a given release, development is -typically split into three phases of decreasing duration, with larger and more invasive changes targeted to be merged to -``devel`` in earlier phases. The ``milestone`` branch is updated to the contents of ``devel`` at the end of each -development phase. This allows testing of semi-stable unreleased features on a predictable schedule without the exposure -to the potential instability of the daily commit "fire hose" from ``devel``. When a release reaches the Beta 1 milestone, -the ``milestone`` branch will be updated to the first ``devel`` commit after the version number has been increased. -Further testing of the same release should be done from the new ``stable-X.Y`` branch that was created. If a severe issue -that significantly affects community testing or stability is discovered in the ``milestone`` branch, the branch contents -may require unscheduled adjustment, but not in a way that prevents fast-forward updates (for example, ``milestone``-only -commits will not be created or cherry-picked from ``devel``). - -The following example is for illustrative purposes only. See the :ref:`ansible_core_roadmaps` for accurate dates. For example, the ``milestone`` branch in 2.13 ``ansible-core`` roadmap updated as follows: - -* 27-Sep-2021: 2.13 Development Phase 1 begins; ``milestone`` contents are updated to 2.12.0b1 with version number set to - ``2.13.0.dev0``. Automated content testing that includes version-specific ignore files (e.g., ``ignore-2.12.txt``) - should copy them for the current version (e.g., ``ignore-2.13.txt``) before this point to ensure that automated sanity - testing against the ``milestone`` branch will continue to pass. -* 13-Dec-2021: 2.13 Development Phase 2 begins; ``milestone`` contents are updated to the final commit from Development Phase 1 -* 14-Feb-2022: 2.13 Development Phase 3 begins; ``milestone`` contents are updated to the final commit from Development Phase 2 -* 11-Apr-2022: ``stable-2.13`` branch created with results from Development Phase 3 and freeze. ``2.13.0b1`` is released from - ``stable-2.13``. Automated content testing should continue 2.13 series testing against the new branch. The ``devel`` - version number is updated to ``2.14.0.dev0``, and ``milestone`` is updated to that point. diff --git a/docs/docsite/rst/dev_guide/core_index.rst b/docs/docsite/rst/dev_guide/core_index.rst deleted file mode 100644 index 3c2fdb73d46..00000000000 --- a/docs/docsite/rst/dev_guide/core_index.rst +++ /dev/null @@ -1,89 +0,0 @@ -.. _developer_guide: - -*************** -Developer Guide -*************** - -.. 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 `_. - -Welcome to the Ansible Developer Guide! - -**Who should use this guide?** - -If you want to extend Ansible by using a custom module or plugin locally, creating a module or plugin, adding functionality to an existing module, or expanding test coverage, this guide is for you. We've included detailed information for developers on how to test and document modules, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository. - -Find the task that best describes what you want to do: - -* I'm looking for a way to address a use case: - - * I want to :ref:`add a custom plugin or module locally `. - * I want to figure out if :ref:`developing a module is the right approach ` for my use case. - * I want to :ref:`develop a collection `. - * I want to :ref:`contribute to an Ansible-maintained collection `. - * I want to :ref:`contribute to a community-maintained collection `. - * I want to :ref:`migrate a role to a collection `. - -* I've read the info above, and I'm sure I want to develop a module: - - * What do I need to know before I start coding? - * I want to :ref:`set up my Python development environment `. - * I want to :ref:`get started writing a module `. - * I want to write a specific kind of module: - * a :ref:`network module ` - * a :ref:`Windows module `. - * I want to :ref:`write a series of related modules ` that integrate Ansible with a new product (for example, a database, cloud provider, network platform, and so on). - -* I want to refine my code: - - * I want to :ref:`debug my module code `. - * I want to :ref:`add tests `. - * I want to :ref:`document my module `. - * I want to :ref:`document my set of modules for a network platform `. - * I want to follow :ref:`conventions and tips for clean, usable module code `. - * I want to :ref:`make sure my code runs on Python 2 and Python 3 `. - -* I want to work on other development projects: - - * I want to :ref:`write a plugin `. - * I want to :ref:`connect Ansible to a new source of inventory `. - * I want to :ref:`deprecate an outdated module `. - -* I want to contribute back to the Ansible project: - - * I want to :ref:`understand how to contribute to Ansible `. - * I want to :ref:`contribute my module or plugin `. - * I want to :ref:`understand the license agreement ` for contributions to Ansible. - -If you prefer to read the entire guide, here's a list of the pages in order. - -.. toctree:: - :maxdepth: 2 - - developing_locally - developing_modules - developing_modules_general - developing_modules_checklist - developing_modules_best_practices - developing_python_3 - debugging - developing_modules_documenting - sidecar - developing_modules_general_windows - developing_modules_in_groups - testing - module_lifecycle - developing_plugins - developing_inventory - developing_core - developing_program_flow_modules - developing_api - developing_rebasing - developing_module_utilities - developing_collections - migrating_roles - collections_galaxy_meta - overview_architecture diff --git a/docs/docsite/rst/dev_guide/debugging.rst b/docs/docsite/rst/dev_guide/debugging.rst deleted file mode 100644 index 0ed23c5881c..00000000000 --- a/docs/docsite/rst/dev_guide/debugging.rst +++ /dev/null @@ -1,112 +0,0 @@ -.. _debugging_modules: - -***************** -Debugging modules -***************** - -.. contents:: - :local: - -.. _detailed_debugging: - -Detailed debugging steps -======================== - -Ansible modules are put together as a zip file consisting of the module file and the various Python module boilerplate inside of a wrapper script. To see what is actually happening in the module, you need to extract the file from the wrapper. The wrapper script provides helper methods that let you do that. - -The following steps use ``localhost`` as the target host, but you can use the same steps to debug against remote hosts as well. For a simpler approach to debugging without using the temporary files, see :ref:`simple debugging `. - - -#. Set :envvar:`ANSIBLE_KEEP_REMOTE_FILES` to ``1`` on the control host so Ansible will keep the remote module files instead of deleting them after the module finishes executing. Use the ``-vvv`` option to make Ansible more verbose. This will display the file name of the temporary module file. - - .. code-block:: shell-session - - $ ANSIBLE_KEEP_REMOTE_FILES=1 ansible localhost -m ping -a 'data=debugging_session' -vvv - <127.0.0.1> ESTABLISH LOCAL CONNECTION FOR USER: badger - <127.0.0.1> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo $HOME/.ansible/tmp/ansible-tmp-1461434734.35-235318071810595 `" && echo "` echo $HOME/.ansible/tmp/ansible-tmp-1461434734.35-235318071810595 `" )' - <127.0.0.1> PUT /var/tmp/tmpjdbJ1w TO /home/badger/.ansible/tmp/ansible-tmp-1461434734.35-235318071810595/AnsiballZ_ping.py - <127.0.0.1> EXEC /bin/sh -c 'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /home/badger/.ansible/tmp/ansible-tmp-1461434734.35-235318071810595/AnsiballZ_ping.py && sleep 0' - localhost | SUCCESS => { - "changed": false, - "invocation": { - "module_args": { - "data": "debugging_session" - }, - "module_name": "ping" - }, - "ping": "debugging_session" - } - -#. Navigate to the temporary directory from the previous step. If the previous command was run against a remote host, connect to that host first before trying to navigate to the temporary directory. - - .. code-block:: shell-session - - $ ssh remotehost # only if not debugging against localhost - $ cd /home/badger/.ansible/tmp/ansible-tmp-1461434734.35-235318071810595 - -#. Run the wrapper's ``explode`` command to turn the string into some Python files that you can work with. - - .. code-block:: shell-session - - $ python AnsiballZ_ping.py explode - Module expanded into: - /home/badger/.ansible/tmp/ansible-tmp-1461434734.35-235318071810595/debug_dir - - If you want to examine the wrapper file you can. It will show a small Python script with a large base64 encoded string. The string contains the module to execute. - -#. When you look into the temporary directory you'll see a structure like this: - - .. code-block:: shell-session - - ├── AnsiballZ_ping.py - └── debug_dir - ├── ansible - │   ├── __init__.py - │   ├── module_utils - │   │   ├── __init__.py - │   │   ├── _text.py - │   │   ├── basic.py - │   │   ├── common - │   │   ├── compat - │   │   ├── distro - │   │   ├── parsing - │   │   ├── pycompat24.py - │   │   └── six - │   └── modules - │   ├── __init__.py - │   └── ping.py - └── args - - * ``AnsiballZ_ping.py`` is the Python script with the module code stored in a base64 encoded string. It contains various helper functions for executing the module. - - * ``ping.py`` is the code for the module itself. You can modify this code to see what effect it would have on your module, or for debugging purposes. - - * The ``args`` file contains a JSON string. The string is a dictionary containing the module arguments and other variables that Ansible passes into the module to change its behavior. Modify this file to change the parameters passed to the module. - - * The ``ansible`` directory contains the module code in ``modules`` as well as code from :mod:`ansible.module_utils` that is used by the module. Ansible includes files for any :mod:`ansible.module_utils` imports in the module but not any files from any other module. If your module uses :mod:`ansible.module_utils.url` Ansible will include it for you. But if your module includes `requests `_, then you'll have to make sure that the Python `requests library `_ is installed on the system before running the module. - - You can modify files in this directory if you suspect that the module is having a problem in some of this boilerplate code rather than in the module code you have written. - -#. Once you edit the code or arguments in the exploded tree, use the ``execute`` subcommand to run it: - - .. code-block:: shell-session - - $ python AnsiballZ_ping.py execute - {"invocation": {"module_args": {"data": "debugging_session"}}, "changed": false, "ping": "debugging_session"} - - This subcommand inserts the absolute path to ``debug_dir`` as the first item in ``sys.path`` and invokes the script using the arguments in the ``args`` file. You can continue to run the module like this until you understand the problem. Then you can copy the changes back into your real module file and test that the real module works by using the ``ansible`` or ``ansible-playbook``. - - -.. _simple_debugging: - -Simple debugging -================ - -The easiest way to run a debugger in a module, either local or remote, is to use `epdb `_. Add ``import epdb; epdb.serve()`` in the module code on the control node at the desired break point. To connect to the debugger, run ``epdb.connect()``. See the `epdb documentation `_ for how to specify the ``host`` and ``port``. If connecting to a remote node, make sure to use a port that is allowed by any firewall between the control node and the remote node. - -This technique should work with any remote debugger, but we do not guarantee any particular remote debugging tool will work. - -The `q `_ library is another very useful debugging tool. - -Since ``print()`` statements do not work inside modules, raising an exception is a good approach if you just want to see some specific data. Put ``raise Exception(some_value)`` somewhere in the module and run it normally. Ansible will handle this exception, pass the message back to the control node, and display it. - diff --git a/docs/docsite/rst/dev_guide/developing_api.rst b/docs/docsite/rst/dev_guide/developing_api.rst deleted file mode 100644 index 3ea552a2132..00000000000 --- a/docs/docsite/rst/dev_guide/developing_api.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _developing_api: - -********** -Python API -********** - -.. contents:: Topics - -.. note:: This API is intended for internal Ansible use. Ansible may make changes to this API at any time that could break backward compatibility with older versions of the API. Because of this, external use is not supported by Ansible. If you want to use Python API only for executing playbooks or modules, consider `ansible-runner `_ first. - -There are several ways to use Ansible from an API perspective. You can use -the Ansible Python API to control nodes, you can extend Ansible to respond to various Python events, you can -write plugins, and you can plug in inventory data from external data sources. This document -gives a basic overview and examples of the Ansible execution and playbook API. - -If you would like to use Ansible programmatically from a language other than Python, trigger events asynchronously, -or have access control and logging demands, please see the `AWX project `_. - -.. note:: Because Ansible relies on forking processes, this API is not thread safe. - -.. _python_api_example: - -Python API example -================== - -This example is a simple demonstration that shows how to minimally run a couple of tasks: - -.. literalinclude:: ../../../../examples/scripts/uptime.py - :language: python - -.. note:: Ansible emits warnings and errors through the display object, which prints directly to stdout, stderr and the Ansible log. - -The source code for the ``ansible`` -command line tools (``lib/ansible/cli/``) is `available on GitHub `_. - -.. seealso:: - - :ref:`developing_inventory` - Developing dynamic inventory integrations - :ref:`developing_modules_general` - Getting started on developing a module - :ref:`developing_plugins` - How to develop plugins - `Development Mailing List `_ - Mailing list for development topics - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections.rst b/docs/docsite/rst/dev_guide/developing_collections.rst deleted file mode 100644 index d3fb4f7fcad..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. _developing_collections: - -********************** -Developing collections -********************** - -Collections are a distribution format for Ansible content. You can package and distribute playbooks, roles, modules, and plugins using collections. A typical collection addresses a set of related use cases. For example, the ``cisco.ios`` collection automates management of Cisco IOS devices. - -You can create a collection and publish it to `Ansible Galaxy `_ or to a private Automation Hub instance. You can publish certified collections to the Red Hat Automation Hub, part of the Red Hat Ansible Automation Platform. - -.. toctree:: - :maxdepth: 2 - :caption: Developing new collections - - developing_collections_creating - developing_collections_shared - developing_collections_testing - developing_collections_distributing - developing_collections_documenting - -.. toctree:: - :maxdepth: 2 - :caption: Working with existing collections - - developing_collections_migrating - developing_collections_contributing - developing_collections_changelogs - -.. toctree:: - :maxdepth: 2 - :caption: Collections references - - developing_collections_structure - collections_galaxy_meta - -For instructions on developing modules, see :ref:`developing_modules_general`. - -.. seealso:: - - :ref:`collections` - Learn how to install and use collections in playbooks and roles - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Ansible Collections Overview and FAQ `_ - Current development status of community collections and FAQ - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_changelogs.rst b/docs/docsite/rst/dev_guide/developing_collections_changelogs.rst deleted file mode 100644 index 3e164090d2b..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_changelogs.rst +++ /dev/null @@ -1,82 +0,0 @@ -.. _collection_changelogs: - -*************************************************************** -Generating changelogs and porting guide entries in a collection -*************************************************************** - -You can create and share changelog and porting guide entries for your collection. If your collection is part of the Ansible Community package, we recommend that you use the `antsibull-changelog `_ tool to generate Ansible-compatible changelogs. The Ansible changelog uses the output of this tool to collate all the collections included in an Ansible release into one combined changelog for the release. - -.. note:: - - Ansible here refers to the Ansible 2.10 or later release that includes a curated set of collections. - -.. contents:: - :local: - :depth: 2 - -Understanding antsibull-changelog -================================= - -The ``antsibull-changelog`` tool allows you to create and update changelogs for Ansible collections that are compatible with the combined Ansible changelogs. This is an update to the changelog generator used in prior Ansible releases. The tool adds three new changelog fragment categories: ``breaking_changes``, ``security_fixes`` and ``trivial``. The tool also generates the ``changelog.yaml`` file that Ansible uses to create the combined ``CHANGELOG.rst`` file and Porting Guide for the release. - -See :ref:`changelogs_how_to` and the `antsibull-changelog documentation `_ for complete details. - -.. note:: - - The collection maintainers set the changelog policy for their collections. See the individual collection contributing guidelines for complete details. - -Generating changelogs ---------------------- - -To initialize changelog generation: - -#. Install ``antsibull-changelog``: :code:`pip install antsibull-changelog`. -#. Initialize changelogs for your repository: :code:`antsibull-changelog init `. -#. Optionally, edit the ``changelogs/config.yaml`` file to customize the location of the generated changelog ``.rst`` file or other options. See `Bootstrapping changelogs for collections `_ for details. - -To generate changelogs from the changelog fragments you created: - -#. Optionally, validate your changelog fragments: :code:`antsibull-changelog lint`. -#. Generate the changelog for your release: :code:`antsibull-changelog release [--version version_number]`. - -.. note:: - - Add the ``--reload-plugins`` option if you ran the ``antsibull-changelog release`` command previously and the version of the collection has not changed. ``antsibull-changelog`` caches the information on all plugins and does not update its cache until the collection version changes. - -Porting Guide entries from changelog fragments ----------------------------------------------- - -The Ansible changelog generator automatically adds several changelog fragment categories to the Ansible Porting Guide: - -* ``major_changes`` -* ``breaking_changes`` -* ``deprecated_features`` -* ``removed_features`` - -Including collection changelogs into Ansible -============================================= - -If your collection is part of Ansible, use one of the following three options to include your changelog into the Ansible release changelog: - -* Use the ``antsibull-changelog`` tool. - -* If are not using this tool, include the properly formatted ``changelog.yaml`` file into your collection. See the `changelog.yaml format `_ for details. - -* Add a link to own changelogs or release notes in any format by opening an issue at https://github.com/ansible-community/ansible-build-data/ with the HTML link to that information. - -.. note:: - - For the first two options, Ansible pulls the changelog details from Galaxy so your changelogs must be included in the collection version on Galaxy that is included in the upcoming Ansible release. - -.. seealso:: - - :ref:`collection_changelogs` - Learn how to create good changelog fragments. - :ref:`collections` - Learn how to install and use collections. - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_contributing.rst b/docs/docsite/rst/dev_guide/developing_collections_contributing.rst deleted file mode 100644 index 86f5fea663b..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_contributing.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _hacking_collections: - -*************************** -Contributing to collections -*************************** - -If you want to add functionality to an existing collection, modify a collection you are using to fix a bug, or change the behavior of a module in a collection, clone the git repository for that collection and make changes on a branch. You can combine changes to a collection with a local checkout of Ansible (``source hacking/env-setup``). -You should first check the collection repository to see if it has specific contribution guidelines. These are typically listed in the README.md or CONTRIBUTING.md files within the repository. - -Contributing to a collection: community.general -=============================================== - -These instructions apply to collections hosted in the `ansible_collections GitHub organization `_. For other collections, especially for collections not hosted on GitHub, check the ``README.md`` of the collection for information on contributing to it. - -This example uses the `community.general collection `_. To contribute to other collections in the same GitHub org, replace the folder names ``community`` and ``general`` with the namespace and collection name of a different collection. - -Prerequisites -------------- - -* Include ``~/dev/ansible/collections/`` in :ref:`COLLECTIONS_PATHS` -* If that path mentions multiple directories, make sure that no other directory earlier in the search path contains a copy of ``community.general``. - -Creating a PR -------------- - - - -* Create the directory ``~/dev/ansible/collections/ansible_collections/community``: - -.. code-block:: shell - - mkdir -p ~/dev/ansible/collections/ansible_collections/community - -* Clone `the community.general Git repository `_ or a fork of it into the directory ``general``: - -.. code-block:: shell - - cd ~/dev/ansible/collections/ansible_collections/community - git clone git@github.com:ansible-collections/community.general.git general - -* If you clone from a fork, add the original repository as a remote ``upstream``: - -.. code-block:: shell - - cd ~/dev/ansible/collections/ansible_collections/community/general - git remote add upstream git@github.com:ansible-collections/community.general.git - -* Create a branch and commit your changes on the branch. - -* Remember to add tests for your changes, see :ref:`testing_collections`. - -* Push your changes to your fork of the collection and create a Pull Request. - -You can test your changes by using this checkout of ``community.general`` in playbooks and roles with whichever version of Ansible you have installed locally, including a local checkout of ``ansible/ansible``'s ``devel`` branch. - -.. seealso:: - - :ref:`collections` - Learn how to install and use collections. - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_creating.rst b/docs/docsite/rst/dev_guide/developing_collections_creating.rst deleted file mode 100644 index 90a13a64c21..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_creating.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. _creating_collections: - -******************** -Creating collections -******************** - -To create a collection: - -#. Create a :ref:`collection skeleton` with the ``collection init`` command. -#. Add modules and other content to the collection. -#. Build the collection into a collection artifact with :ref:`ansible-galaxy collection build`. -#. Publish the collection artifact to Galaxy with :ref:`ansible-galaxy collection publish`. - -A user can then install your collection on their systems. - -.. contents:: - :local: - :depth: 2 - -.. _creating_collections_skeleton: - -Creating a collection skeleton -============================== - -To start a new collection, run the following command in your collections directory: - -.. code-block:: bash - - ansible_collections#> ansible-galaxy collection init my_namespace.my_collection - -.. note:: - - Both the namespace and collection names use the same strict set of requirements. See `Galaxy namespaces `_ on the Galaxy docsite for those requirements. - -It will create the structure ``[my_namespace]/[my_collection]/[collection skeleton]``. - -.. hint:: If Git is used for version control, the corresponding repository should be initialized in the collection directory. - -Once the skeleton exists, you can populate the directories with the content you want inside the collection. See `ansible-collections `_ GitHub Org to get a better idea of what you can place inside a collection. - -Reference: the ``ansible-galaxy collection`` command - -Currently the ``ansible-galaxy collection`` command implements the following sub commands: - -* ``init``: Create a basic collection skeleton based on the default template included with Ansible or your own template. -* ``build``: Create a collection artifact that can be uploaded to Galaxy or your own repository. -* ``publish``: Publish a built collection artifact to Galaxy. -* ``install``: Install one or more collections. - -To learn more about the ``ansible-galaxy`` command-line tool, see the :ref:`ansible-galaxy` man page. - -.. seealso:: - - :ref:`collections` - Learn how to install and use collections. - :ref:`collection_structure` - Directories and files included in the collection skeleton - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_distributing.rst b/docs/docsite/rst/dev_guide/developing_collections_distributing.rst deleted file mode 100644 index 124d112439c..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_distributing.rst +++ /dev/null @@ -1,406 +0,0 @@ -.. _distributing_collections: - -************************ -Distributing collections -************************ - -A collection is a distribution format for Ansible content. A typical collection contains modules and other plugins that address a set of related use cases. For example, a collection might automate administering a particular database. A collection can also contain roles and playbooks. - -To distribute your collection and allow others to use it, you can publish your collection on one or more :term:`distribution server`. Distribution servers include: - -================================= =================================================================== -Distribution server Collections accepted -================================= =================================================================== -Ansible Galaxy All collections -:term:`Pulp 3 Galaxy` All collections, supports signed collections -Red Hat Automation Hub Only collections certified by Red Hat, supports signed collections -Privately hosted Automation Hub Collections authorized by the owners -================================= =================================================================== - -Distributing collections involves four major steps: - -#. Initial configuration of your distribution server or servers -#. Building your collection tarball -#. Preparing to publish your collection -#. Publishing your collection - -.. contents:: - :local: - :depth: 2 - -.. _config_distribution_server: - -Initial configuration of your distribution server or servers -============================================================ - -Configure a connection to one or more distribution servers so you can publish collections there. You only need to configure each distribution server once. You must repeat the other steps (building your collection tarball, preparing to publish, and publishing your collection) every time you publish a new collection or a new version of an existing collection. - -1. Create a namespace on each distribution server you want to use. -2. Get an API token for each distribution server you want to use. -3. Specify the API token for each distribution server you want to use. - -.. _get_namespace: - -Creating a namespace --------------------- - -You must upload your collection into a namespace on each distribution server. If you have a login for Ansible Galaxy, your Ansible Galaxy username is usually also an Ansible Galaxy namespace. - -.. warning:: - - Namespaces on Ansible Galaxy cannot include hyphens. If you have a login for Ansible Galaxy that includes a hyphen, your Galaxy username is not also a Galaxy namespace. For example, ``awesome-user`` is a valid username for Ansible Galaxy, but it is not a valid namespace. - -You can create additional namespaces on Ansible Galaxy if you choose. For Red Hat Automation Hub and private Automation Hub you must create a namespace before you can upload your collection. To create a namespace: - -* To create a namespace on Galaxy, see `Galaxy namespaces `_ on the Galaxy docsite for details. -* To create a namespace on Red Hat Automation Hub, see the `Ansible Certified Content FAQ `_. - -Specify the namespace in the :file:`galaxy.yml` file for each collection. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`. - -.. _galaxy_get_token: - -Getting your API token ----------------------- - -An API token authenticates your connection to each distribution server. You need a separate API token for each distribution server. Use the correct API token to connect to each distribution server securely and protect your content. - -To get your API token: - -* To get an API token for Galaxy, go to the `Galaxy profile preferences `_ page and click :guilabel:`API Key`. -* To get an API token for Automation Hub, go to `the token page `_ and click :guilabel:`Load token`. - -.. _galaxy_specify_token: - -Specifying your API token and distribution server -------------------------------------------------- - -Each time you publish a collection, you must specify the API token and the distribution server to create a secure connection. You have two options for specifying the token and distribution server: - -* You can configure the token in configuration, as part of a ``galaxy_server_list`` entry in your :file:`ansible.cfg` file. Using configuration is the most secure option. -* You can pass the token at the command line as an argument to the ``ansible-galaxy`` command. If you pass the token at the command line, you can specify the server at the command line, by using the default setting, or by setting the server in configuration. Passing the token at the command line is insecure, because typing secrets at the command line may expose them to other users on the system. - -.. _galaxy_token_ansible_cfg: - -Specifying the token and distribution server in configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default, Ansible Galaxy is configured as the only distribution server. You can add other distribution servers and specify your API token or tokens in configuration by editing the ``galaxy_server_list`` section of your :file:`ansible.cfg` file. This is the most secure way to manage authentication for distribution servers. Specify a URL and token for each server. For example: - -.. code-block:: ini - - [galaxy] - server_list = release_galaxy - - [galaxy_server.release_galaxy] - url=https://galaxy.ansible.com/ - token=abcdefghijklmnopqrtuvwxyz - -You cannot use ``apt-key`` with any servers defined in your :ref:`galaxy_server_list `. See :ref:`galaxy_server_config` for complete details. - -.. _galaxy_use_token_arg: - -Specifying the token at the command line -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can specify the API token at the command line using the ``--token`` argument of the :ref:`ansible-galaxy` command. There are three ways to specify the distribution server when passing the token at the command line: - -* using the ``--server`` argument of the :ref:`ansible-galaxy` command -* relying on the default (https://galaxy.ansible.com) -* setting a server in configuration by creating a :ref:`GALAXY_SERVER` setting in your :file:`ansible.cfg` file - -For example: - -.. code-block:: bash - - ansible-galaxy collection publish path/to/my_namespace-my_collection-1.0.0.tar.gz --token abcdefghijklmnopqrtuvwxyz - -.. warning:: - - Using the ``--token`` argument is insecure. Passing secrets at the command line may expose them to others on the system. - -.. _building_collections: - -Building your collection tarball -================================ - -After configuring one or more distribution servers, build a collection tarball. The collection tarball is the published artifact, the object that you upload and other users download to install your collection. To build a collection tarball: - -#. Review the version number in your :file:`galaxy.yml` file. Each time you publish your collection, it must have a new version number. You cannot make changes to existing versions of your collection on a distribution server. If you try to upload the same collection version more than once, the distribution server returns the error ``Code: conflict.collection_exists``. Collections follow semantic versioning rules. For more information on versions, see :ref:`collection_versions`. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`. -#. Run ``ansible-galaxy collection build`` from inside the top-level directory of the collection. For example: - -.. code-block:: bash - - collection_dir#> ansible-galaxy collection build - -This command builds a tarball of the collection in the current directory, which you can upload to your selected distribution server: - -.. code-block:: shell - - my_collection/ - ├── galaxy.yml - ├── ... - ├── my_namespace-my_collection-1.0.0.tar.gz - └── ... - -.. note:: - * To reduce the size of collections, certain files and folders are excluded from the collection tarball by default. See :ref:`ignoring_files_and_folders_collections` if your collection directory contains other files you want to exclude. - * The current Galaxy maximum tarball size is 2 MB. - -You can upload your tarball to one or more distribution servers. You can also distribute your collection locally by copying the tarball to install your collection directly on target systems. - - -.. _ignoring_files_and_folders_collections: - -Ignoring files and folders --------------------------- - -You can exclude files from your collection with either :ref:`build_ignore ` or :ref:`manifest_directives`. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`. - - -.. _build_ignore: - -Include all, with explicit ignores -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default the build step includes all the files in the collection directory in the tarball except for the following: - -* ``galaxy.yml`` -* ``*.pyc`` -* ``*.retry`` -* ``tests/output`` -* previously built tarballs in the root directory -* various version control directories such as ``.git/`` - -To exclude other files and folders from your collection tarball, set a list of file glob-like patterns in the ``build_ignore`` key in the collection's ``galaxy.yml`` file. These patterns use the following special characters for wildcard matching: - -* ``*``: Matches everything -* ``?``: Matches any single character -* ``[seq]``: Matches any character in sequence -* ``[!seq]``:Matches any character not in sequence - -For example, to exclude the :file:`sensitive` folder within the ``playbooks`` folder as well any ``.tar.gz`` archives, set the following in your ``galaxy.yml`` file: - -.. code-block:: yaml - - build_ignore: - - playbooks/sensitive - - '*.tar.gz' - -.. note:: - The ``build_ignore`` feature is only supported with ``ansible-galaxy collection build`` in Ansible 2.10 or newer. - - -.. _manifest_directives: - -Manifest Directives -^^^^^^^^^^^^^^^^^^^ - -.. versionadded:: 2.14 - -The :file:`galaxy.yml` file supports manifest directives that are historically used in Python packaging, as described in `MANIFEST.in commands `_. - -.. note:: - The use of ``manifest`` requires installing the optional ``distlib`` Python dependency. - -.. note:: - The ``manifest`` feature is only supported with ``ansible-galaxy collection build`` in ``ansible-core`` 2.14 or newer, and is mutually exclusive with ``build_ignore``. - -For example, to exclude the :file:`sensitive` folder within the ``playbooks`` folder as well as any ``.tar.gz`` archives, set the following in your :file:`galaxy.yml` file: - -.. code-block:: yaml - - manifest: - directives: - - recursive-exclude playbooks/sensitive ** - - global-exclude *.tar.gz - -By default, the ``MANIFEST.in`` style directives would exclude all files by default, but there are default directives in place. Those default directives are described below. To see the directives in use during build, pass ``-vvv`` with the ``ansible-galaxy collection build`` command. - -.. code-block:: - - include meta/*.yml - include *.txt *.md *.rst COPYING LICENSE - recursive-include tests ** - recursive-include docs **.rst **.yml **.yaml **.json **.j2 **.txt - recursive-include roles **.yml **.yaml **.json **.j2 - recursive-include playbooks **.yml **.yaml **.json - recursive-include changelogs **.yml **.yaml - recursive-include plugins */**.py - recursive-include plugins/become **.yml **.yaml - recursive-include plugins/cache **.yml **.yaml - recursive-include plugins/callback **.yml **.yaml - recursive-include plugins/cliconf **.yml **.yaml - recursive-include plugins/connection **.yml **.yaml - recursive-include plugins/filter **.yml **.yaml - recursive-include plugins/httpapi **.yml **.yaml - recursive-include plugins/inventory **.yml **.yaml - recursive-include plugins/lookup **.yml **.yaml - recursive-include plugins/netconf **.yml **.yaml - recursive-include plugins/shell **.yml **.yaml - recursive-include plugins/strategy **.yml **.yaml - recursive-include plugins/test **.yml **.yaml - recursive-include plugins/vars **.yml **.yaml - recursive-include plugins/modules **.ps1 **.yml **.yaml - recursive-include plugins/module_utils **.ps1 **.psm1 **.cs - # manifest.directives from galaxy.yml inserted here - exclude galaxy.yml galaxy.yaml MANIFEST.json FILES.json --*.tar.gz - recursive-exclude tests/output ** - global-exclude /.* /__pycache__ - -.. note:: - ``--*.tar.gz`` is expanded with the actual ``namespace`` and ``name``. - -The ``manifest.directives`` supplied in :file:`galaxy.yml` are inserted after the default includes and before the default excludes. - -To enable the use of manifest directives without supplying your own, insert either ``manifest: {}`` or ``manifest: null`` in the :file:`galaxy.yml` file and remove any use of ``build_ignore``. - -If the default manifest directives do not meet your needs, you can set ``manifest.omit_default_directives`` to a value of ``true`` in :file:`galaxy.yml`. You then must specify a full compliment of manifest directives in :file:`galaxy.yml`. The defaults documented above are a good starting point. - -Below is an example where the default directives are not included. - -.. code-block:: yaml - - manifest: - directives: - - include meta/runtime.yml - - include README.md LICENSE - - recursive-include plugins */**.py - - exclude galaxy.yml MANIFEST.json FILES.json --*.tar.gz - - recursive-exclude tests/output ** - omit_default_directives: true - - -.. _signing_collections: - -Signing a collection --------------------------- - -You can include a GnuPG signature with your collection on a :term:`Pulp 3 Galaxy` server. See `Enabling collection signing `_ for details. - -You can manually generate detached signatures for a collection using the ``gpg`` CLI using the following step. This step assume you have generated a GPG private key, but do not cover this process. - -.. code-block:: bash - - ansible-galaxy collection build - tar -Oxzf namespace-name-1.0.0.tar.gz MANIFEST.json | gpg --output namespace-name-1.0.0.asc --detach-sign --armor --local-user email@example.com - - - -.. _trying_collection_locally: - -Preparing to publish your collection -==================================== - -Each time you publish your collection, you must create a :ref:`new version ` on the distribution server. After you publish a version of a collection, you cannot delete or modify that version. To avoid unnecessary extra versions, check your collection for bugs, typos, and other issues locally before publishing: - -#. Install the collection locally. -#. Review the locally installed collection before publishing a new version. - -Installing your collection locally ----------------------------------- - -You have two options for installing your collection locally: - - * Install your collection locally from the tarball. - * Install your collection locally from your git repository. - -Installing your collection locally from the tarball -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To install your collection locally from the tarball, run ``ansible-galaxy collection install`` and specify the collection tarball. You can optionally specify a location using the ``-p`` flag. For example: - -.. code-block:: bash - - collection_dir#> ansible-galaxy collection install my_namespace-my_collection-1.0.0.tar.gz -p ./collections - -Install the tarball into a directory configured in :ref:`COLLECTIONS_PATHS` so Ansible can easily find and load the collection. If you do not specify a path value, ``ansible-galaxy collection install`` installs the collection in the first path defined in :ref:`COLLECTIONS_PATHS`. - -.. _collections_scm_install: - -Installing your collection locally from a git repository -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To install your collection locally from a git repository, specify the repository and the branch you want to install: - -.. code-block:: bash - - collection_dir#> ansible-galaxy collection install git+https://github.com/org/repo.git,devel - -.. include:: ../shared_snippets/installing_collections_git_repo.txt - -Reviewing your collection -------------------------- - -Review the collection: - -* Run a playbook that uses the modules and plugins in your collection. Verify that new features and functionality work as expected. For examples and more details see :ref:`Using collections `. -* Check the documentation for typos. -* Check that the version number of your tarball is higher than the latest published version on the distribution server or servers. -* If you find any issues, fix them and rebuild the collection tarball. - -.. _collection_versions: - -Understanding collection versioning ------------------------------------ - -The only way to change a collection is to release a new version. The latest version of a collection (by highest version number) is the version displayed everywhere in Galaxy and Automation Hub. Users can still download older versions. - -Follow semantic versioning when setting the version for your collection. In summary: - -* Increment the major version number, ``x`` of ``x.y.z``, for an incompatible API change. -* Increment the minor version number, ``y`` of ``x.y.z``, for new functionality in a backwards compatible manner (for example new modules/plugins, parameters, return values). -* Increment the patch version number, ``z`` of ``x.y.z``, for backwards compatible bug fixes. - -Read the official `Semantic Versioning `_ documentation for details and examples. - -.. _publish_collection: - -Publishing your collection -========================== - -The last step in distributing your collection is publishing the tarball to Ansible Galaxy, Red Hat Automation Hub, or a privately hosted Automation Hub instance. You can publish your collection in two ways: - -* from the command line using the ``ansible-galaxy collection publish`` command -* from the website of the distribution server (Galaxy, Automation Hub) itself - -.. _upload_collection_ansible_galaxy: -.. _publish_collection_galaxy_cmd: - -Publishing a collection from the command line ---------------------------------------------- - -To upload the collection tarball from the command line using ``ansible-galaxy``: - -.. code-block:: bash - - ansible-galaxy collection publish path/to/my_namespace-my_collection-1.0.0.tar.gz - -.. note:: - - This ansible-galaxy command assumes you have retrieved and stored your API token in configuration. See :ref:`galaxy_specify_token` for details. - -The ``ansible-galaxy collection publish`` command triggers an import process, just as if you uploaded the collection through the Galaxy website. The command waits until the import process completes before reporting the status back. If you want to continue without waiting for the import result, use the ``--no-wait`` argument and manually look at the import progress in your `My Imports `_ page. - -.. _upload_collection_galaxy: - -Publishing a collection from the website ----------------------------------------- - -To publish your collection directly on the Galaxy website: - -#. Go to the `My Content `_ page, and click the **Add Content** button on one of your namespaces. -#. From the **Add Content** dialogue, click **Upload New Collection**, and select the collection archive file from your local filesystem. - -When you upload a collection, Ansible always uploads the tarball to the namespace specified in the collection metadata in the ``galaxy.yml`` file, no matter which namespace you select on the website. If you are not an owner of the namespace specified in your collection metadata, the upload request fails. - -After Galaxy uploads and accepts a collection, the website shows you the **My Imports** page. This page shows import process information. You can review any errors or warnings about your upload there. - -.. seealso:: - - :ref:`collections` - Learn how to install and use collections. - :ref:`collections_galaxy_meta` - Table of fields used in the :file:`galaxy.yml` file - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_documenting.rst b/docs/docsite/rst/dev_guide/developing_collections_documenting.rst deleted file mode 100644 index 8f0c00d6460..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_documenting.rst +++ /dev/null @@ -1,30 +0,0 @@ -.. _documenting_collections: - -*********************** -Documenting collections -*********************** - -Documenting modules and plugins -=============================== - -Documenting modules is thoroughly documented in :ref:`module_documenting`. Plugins can be documented the same way as modules, that is with ``DOCUMENTATION``, ``EXAMPLES``, and ``RETURN`` blocks. - -Documenting roles -================= - -To document a role, you have to add a role argument spec by creating a file ``meta/argument_specs.yml`` in your role. See :ref:`role_argument_spec` for details. As an example, you can look at `the argument specs file `_ of the :ref:`sensu.sensu_go.install role ` on GitHub. - -.. _build_collection_docsite: - -Build a docsite with antsibull-docs -=================================== - -You can use `antsibull-docs `_ to build a Sphinx-based docsite for your collection: - -#. Create your collection and make sure you can use it with ansible-core by adding it to your :ref:`COLLECTIONS_PATHS`. -#. Create a directory ``dest`` and run ``antsibull-docs sphinx-init --use-current --dest-dir dest namespace.name``, where ``namespace.name`` is the name of your collection. -#. Go into ``dest`` and run ``pip install -r requirements.txt``. You might want to create a venv and activate it first to avoid installing this globally. -#. Then run ``./build.sh``. -#. Open ``build/html/index.html`` in a browser of your choice. - -If you want to add additional documentation to your collection next to the plugin, module, and role documentation, see :ref:`collections_doc_dir`. diff --git a/docs/docsite/rst/dev_guide/developing_collections_migrating.rst b/docs/docsite/rst/dev_guide/developing_collections_migrating.rst deleted file mode 100644 index 834ff92c6ca..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_migrating.rst +++ /dev/null @@ -1,136 +0,0 @@ -.. _migrate_to_collection: - -*************************************************** -Migrating Ansible content to a different collection -*************************************************** - -When you move content from one collection to another, for example to extract a set of related modules out of ``community.general`` to create a more focused collection, you must make sure the transition is easy for users to follow. - -.. contents:: - :local: - :depth: 2 - -Migrating content -================= - -Before you start migrating content from one collection to another, look at `Ansible Collection Checklist `_. - -To migrate content from one collection to another, if the collections are parts of `Ansible distribution `_: - -#. Copy content from the source (old) collection to the target (new) collection. -#. Deprecate the module/plugin with ``removal_version`` scheduled for the next major version in ``meta/runtime.yml`` of the old collection. The deprecation must be released after the copied content has been included in a release of the new collection. -#. When the next major release of the old collection is prepared: - - * remove the module/plugin from the old collection - * remove the symlink stored in ``plugin/modules`` directory if appropriate (mainly when removing from ``community.general`` and ``community.network``) - * remove related unit and integration tests - * remove specific module utils - * remove specific documentation fragments if there are any in the old collection - * add a changelog fragment containing entries for ``removed_features`` and ``breaking_changes``; you can see an example of a changelog fragment in this `pull request `_ - * change ``meta/runtime.yml`` in the old collection: - - * add ``redirect`` to the corresponding module/plugin's entry - * in particular, add ``redirect`` for the removed module utils and documentation fragments if applicable - * remove ``removal_version`` from there - * remove related entries from ``tests/sanity/ignore.txt`` files if exist - * remove changelog fragments for removed content that are not yet part of the changelog (in other words, do not modify `changelogs/changelog.yaml` and do not delete files mentioned in it) - * remove requirements that are no longer required in ``tests/unit/requirements.txt``, ``tests/requirements.yml`` and ``galaxy.yml`` - -To implement these changes, you need to create at least three PRs: - -#. Create a PR against the new collection to copy the content. -#. Deprecate the module/plugin in the old collection. -#. Later create a PR against the old collection to remove the content according to the schedule. - - -Adding the content to the new collection ----------------------------------------- - -Create a PR in the new collection to: - -#. Copy ALL the related files from the old collection. -#. If it is an action plugin, include the corresponding module with documentation. -#. If it is a module, check if it has a corresponding action plugin that should move with it. -#. Check ``meta/`` for relevant updates to ``runtime.yml`` if it exists. -#. Carefully check the moved ``tests/integration`` and ``tests/units`` and update for FQCN. -#. Review ``tests/sanity/ignore-*.txt`` entries in the old collection. -#. Update ``meta/runtime.yml`` in the old collection. - - -Removing the content from the old collection --------------------------------------------- - -Create a PR against the source collection repository to remove the modules, module_utils, plugins, and docs_fragments related to this migration: - -#. If you are removing an action plugin, remove the corresponding module that contains the documentation. -#. If you are removing a module, remove any corresponding action plugin that should stay with it. -#. Remove any entries about removed plugins from ``meta/runtime.yml``. Ensure they are added into the new repo. -#. Remove sanity ignore lines from ``tests/sanity/ignore\*.txt`` -#. Remove associated integration tests from ``tests/integrations/targets/`` and unit tests from ``tests/units/plugins/``. -#. if you are removing from content from ``community.general`` or ``community.network``, remove entries from ``.github/BOTMETA.yml``. -#. Carefully review ``meta/runtime.yml`` for any entries you may need to remove or update, in particular deprecated entries. -#. Update ``meta/runtime.yml`` to contain redirects for EVERY PLUGIN, pointing to the new collection name. - -.. warning:: - - Maintainers for the old collection have to make sure that the PR is merged in a way that it does not break user experience and semantic versioning: - - #. A new version containing the merged PR must not be released before the collection the content has been moved to has been released again, with that content contained in it. Otherwise the redirects cannot work and users relying on that content will experience breakage. - #. Once 1.0.0 of the collection from which the content has been removed has been released, such PRs can only be merged for a new **major** version (in other words, 2.0.0, 3.0.0, and so on). - - -Updating BOTMETA.yml --------------------- - -The ``BOTMETA.yml``, for example in `community.general collection repository `_, is the source of truth for: - -* ansibullbot - -If the old and/or new collection has ``ansibullbot``, its ``BOTMETA.yml`` must be updated correspondingly. - -Ansibulbot will know how to redirect existing issues and PRs to the new repo. The build process for docs.ansible.com will know where to find the module docs. - -.. code-block:: yaml - - $modules/monitoring/grafana/grafana_plugin.py: - migrated_to: community.grafana - $modules/monitoring/grafana/grafana_dashboard.py: - migrated_to: community.grafana - $modules/monitoring/grafana/grafana_datasource.py: - migrated_to: community.grafana - $plugins/callback/grafana_annotations.py: - maintainers: $team_grafana - labels: monitoring grafana - migrated_to: community.grafana - $plugins/doc_fragments/grafana.py: - maintainers: $team_grafana - labels: monitoring grafana - migrated_to: community.grafana - -`Example PR `_ - -* The ``migrated_to:`` key must be added explicitly for every *file*. You cannot add ``migrated_to`` at the directory level. This is to allow module and plugin webdocs to be redirected to the new collection docs. -* ``migrated_to:`` MUST be added for every: - - * module - * plugin - * module_utils - * contrib/inventory script - -* You do NOT need to add ``migrated_to`` for: - - * Unit tests - * Integration tests - * ReStructured Text docs (anything under ``docs/docsite/rst/``) - * Files that never existed in ``ansible/ansible:devel`` - -.. seealso:: - - :ref:`collections` - Learn how to install and use collections. - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_shared.rst b/docs/docsite/rst/dev_guide/developing_collections_shared.rst deleted file mode 100644 index 34db6aea696..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_shared.rst +++ /dev/null @@ -1,94 +0,0 @@ -.. _collections_shared_resources: - -************************************* -Using shared resources in collections -************************************* - -Although developing Ansible modules contained in collections is similar to developing standalone Ansible modules, you use shared resources like documentation fragments and module utilities differently in collections. You can use documentation fragments within and across collections. You can use optional module utilities to support multiple versions of ansible-core in your collection. Collections can also depend on other collections. - -.. contents:: - :local: - :depth: 2 - -.. _docfragments_collections: - -Using documentation fragments in collections -============================================ - -To include documentation fragments in your collection: - -#. Create the documentation fragment: ``plugins/doc_fragments/fragment_name``. - -#. Refer to the documentation fragment with its FQCN. - -.. code-block:: yaml - - extends_documentation_fragment: - - kubernetes.core.k8s_name_options - - kubernetes.core.k8s_auth_options - - kubernetes.core.k8s_resource_options - - kubernetes.core.k8s_scale_options - -:ref:`module_docs_fragments` covers the basics for documentation fragments. The `kubernetes.core `_ collection includes a complete example. - -If you use FQCN, you can use documentation fragments from one collection in another collection. - -.. _optional_module_utils: - -Leveraging optional module utilities in collections -=================================================== - -Optional module utilities let you adopt the latest features from the most recent ansible-core release in your collection-based modules without breaking your collection on older Ansible versions. With optional module utilities, you can use the latest features when running against the latest versions, while still providing fallback behaviors when running against older versions. - -This implementation, widely used in Python programming, wraps optional imports in conditionals or defensive `try/except` blocks, and implements fallback behaviors for missing imports. Ansible's module payload builder supports these patterns by treating any module_utils import nested in a block (e.g., `if`, `try`) as optional. If the requested import cannot be found during the payload build, it is simply omitted from the target payload and assumed that the importing code will handle its absence at runtime. Missing top-level imports of module_utils packages (imports that are not wrapped in a block statement of any kind) will fail the module payload build, and will not execute on the target. - -For example, the `ansible.module_utils.common.respawn` package is only available in Ansible 2.11 and higher. The following module code would fail during the payload build on Ansible 2.10 or earlier (as the requested Python module does not exist, and is not wrapped in a block to signal to the payload builder that it can be omitted from the module payload): - -.. code-block:: python - - from ansible.module_utils.common.respawn import respawn_module - -By wrapping the import statement in a ``try`` block, the payload builder will omit the Python module if it cannot be located, and assume that the Ansible module will handle it at runtime: - -.. code-block:: python - - try: - from ansible.module_utils.common.respawn import respawn_module - except ImportError: - respawn_module = None - ... - if needs_respawn: - if respawn_module: - respawn_module(target) - else: - module.fail_json('respawn is not available in Ansible < 2.11, ensure that foopkg is installed') - -The optional import behavior also applies to module_utils imported from collections. - -.. _collection_dependencies: - -Listing collection dependencies -=============================== - -We recommend that collections work as standalone, independent units, depending only on ansible-core. However, if your collection must depend on features and functionality from another collection, list the other collection or collections under ``dependencies`` in your collection's :file:`galaxy.yml` file. Use the :file:`meta/runtime.yml` file to set the ansible-core version that your collection depends on. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`. - -You can use git repositories for collection dependencies during local development and testing. For example: - -.. code-block:: yaml - - dependencies: {'git@github.com:organization/repo_name.git': 'devel'} - -.. warning:: - - Do not use git repositories as dependencies for published collections. Dependencies for published collections must be other published collections. - -.. seealso:: - - :ref:`collections` - Learn how to install and use collections. - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_structure.rst b/docs/docsite/rst/dev_guide/developing_collections_structure.rst deleted file mode 100644 index 77d4e8bf56d..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_structure.rst +++ /dev/null @@ -1,293 +0,0 @@ -.. _collection_structure: - -******************** -Collection structure -******************** - -A collection is a simple data structure. None of the directories are required unless you have specific content that belongs in one of them. A collection does require a ``galaxy.yml`` file at the root level of the collection. This file contains all of the metadata that Galaxy and other tools need in order to package, build and publish the collection. - -.. contents:: - :local: - :depth: 2 - -Collection directories and files -================================ - -A collection can contain these directories and files: - -.. code-block:: shell-session - - collection/ - ├── docs/ - ├── galaxy.yml - ├── meta/ - │ └── runtime.yml - ├── plugins/ - │ ├── modules/ - │ │ └── module1.py - │ ├── inventory/ - │ └── .../ - ├── README.md - ├── roles/ - │ ├── role1/ - │ ├── role2/ - │ └── .../ - ├── playbooks/ - │ ├── files/ - │ ├── vars/ - │ ├── templates/ - │ └── tasks/ - └── tests/ - -.. note:: - * Ansible only accepts ``.md`` extensions for the :file:`README` file and any files in the :file:`/docs` folder. - * See the `ansible-collections `_ GitHub Org for examples of collection structure. - * Not all directories are currently in use. Those are placeholders for future features. - -.. _galaxy_yml: - -galaxy.yml ----------- - -A collection must have a ``galaxy.yml`` file that contains the necessary information to build a collection artifact. See :ref:`collections_galaxy_meta` for details. - -.. _collections_doc_dir: - -docs directory --------------- - -Use the ``docs`` folder to describe how to use the roles and plugins the collection provides, role requirements, and so on. - -For certified collections, Automation Hub displays documents written in markdown in the main ``docs`` directory with no subdirectories. This will not display on https://docs.ansible.com. - -For community collections included in the Ansible PyPI package, docs.ansible.com displays documents written in reStructuredText (.rst) in a docsite/rst/ subdirectory. Define the structure of your extra documentation in ``docs/docsite/extra-docs.yml``: - -.. code-block:: yaml - - --- - sections: - - title: Scenario Guide - toctree: - - scenario_guide - -The index page of the documentation for your collection displays the title you define in ``docs/docsite/extra-docs.yml`` with a link to your extra documentation. For an example, see the `community.docker collection repo `_ and the `community.docker collection documentation `_. - -You can add extra links to your collection index page and plugin pages with the ``docs/docsite/links.yml`` file. This populates the links under `Description and Communications `_ headings as well as links at the end of the individual plugin pages. See the `collection_template links.yml file `_ for a complete description of the structure and use of this file to create links. - -Plugin and module documentation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Keep the specific documentation for plugins and modules embedded as Python docstrings. Use ``ansible-doc`` to view documentation for plugins inside a collection: - -.. code-block:: bash - - ansible-doc -t lookup my_namespace.my_collection.lookup1 - -The ``ansible-doc`` command requires the fully qualified collection name (FQCN) to display specific plugin documentation. In this example, ``my_namespace`` is the Galaxy namespace and ``my_collection`` is the collection name within that namespace. - -.. note:: The Galaxy namespace of an Ansible collection is defined in the ``galaxy.yml`` file. It can be different from the GitHub organization or repository name. - -.. _collections_plugin_dir: - -plugins directory ------------------ - -Add a 'per plugin type' specific subdirectory here, including ``module_utils`` which is usable not only by modules, but by most plugins by using their FQCN. This is a way to distribute modules, lookups, filters, and so on without having to import a role in every play. - -Vars plugins in collections are not loaded automatically, and always require being explicitly enabled by using their fully qualified collection name. See :ref:`enable_vars` for details. - -Cache plugins in collections may be used for fact caching, but are not supported for inventory plugins. - -.. _collection_module_utils: - -module_utils -^^^^^^^^^^^^ - -When coding with ``module_utils`` in a collection, the Python ``import`` statement needs to take into account the FQCN along with the ``ansible_collections`` convention. The resulting Python import will look like ``from ansible_collections.{namespace}.{collection}.plugins.module_utils.{util} import {something}`` - -The following example snippets show a Python and PowerShell module using both default Ansible ``module_utils`` and -those provided by a collection. In this example the namespace is ``community``, the collection is ``test_collection``. -In the Python example the ``module_util`` in question is called ``qradar`` such that the FQCN is -``community.test_collection.plugins.module_utils.qradar``: - -.. code-block:: python - - from ansible.module_utils.basic import AnsibleModule - from ansible.module_utils.common.text.converters import to_text - - from ansible.module_utils.six.moves.urllib.parse import urlencode, quote_plus - from ansible.module_utils.six.moves.urllib.error import HTTPError - from ansible_collections.community.test_collection.plugins.module_utils.qradar import QRadarRequest - - argspec = dict( - name=dict(required=True, type='str'), - state=dict(choices=['present', 'absent'], required=True), - ) - - module = AnsibleModule( - argument_spec=argspec, - supports_check_mode=True - ) - - qradar_request = QRadarRequest( - module, - headers={"Content-Type": "application/json"}, - not_rest_data_keys=['state'] - ) - -Note that importing something from an ``__init__.py`` file requires using the file name: - -.. code-block:: python - - from ansible_collections.namespace.collection_name.plugins.callback.__init__ import CustomBaseClass - -In the PowerShell example the ``module_util`` in question is called ``hyperv`` such that the FQCN is -``community.test_collection.plugins.module_utils.hyperv``: - -.. code-block:: powershell - - #!powershell - #AnsibleRequires -CSharpUtil Ansible.Basic - #AnsibleRequires -PowerShell ansible_collections.community.test_collection.plugins.module_utils.hyperv - - $spec = @{ - name = @{ required = $true; type = "str" } - state = @{ required = $true; choices = @("present", "absent") } - } - $module = [Ansible.Basic.AnsibleModule]::Create($args, $spec) - - Invoke-HyperVFunction -Name $module.Params.name - - $module.ExitJson() - -.. _collections_roles_dir: - -roles directory ----------------- - -Collection roles are mostly the same as existing roles, but with a couple of limitations: - - - Role names are now limited to contain only lowercase alphanumeric characters, plus ``_`` and start with an alpha character. - - Roles in a collection cannot contain plugins any more. Plugins must live in the collection ``plugins`` directory tree. Each plugin is accessible to all roles in the collection. - -The directory name of the role is used as the role name. Therefore, the directory name must comply with the above role name rules. The collection import into Galaxy will fail if a role name does not comply with these rules. - -You can migrate 'traditional roles' into a collection but they must follow the rules above. You may need to rename roles if they don't conform. You will have to move or link any role-based plugins to the collection specific directories. - -.. note:: - - For roles imported into Galaxy directly from a GitHub repository, setting the ``role_name`` value in the role's metadata overrides the role name used by Galaxy. For collections, that value is ignored. When importing a collection, Galaxy uses the role directory as the name of the role and ignores the ``role_name`` metadata value. - -playbooks directory --------------------- - -In prior releases, you could reference playbooks in this directory using the full path to the playbook file from the command line. -In ansible-core 2.11 and later, you can use the FQCN, ``namespace.collection.playbook`` (with or without extension), to reference the playbooks from the command line or from ``import_playbook``. -This will keep the playbook in 'collection context', as if you had added ``collections: [ namespace.collection ]`` to it. - -You can have most of the subdirectories you would expect, such ``files/``, ``vars/`` or ``templates/`` but no ``roles/`` since those are handled already in the collection. - -Also, playbooks within a collection follow the same guidelines as any playbooks except for these few adjustments: - - - Directory: It must be in the ``playbooks/`` directory. - - Hosts: The host should be defined as a variable so the users of a playbook do not mistakenly run the plays against their entire inventory (if the host is set to all). For example - ``hosts: '{{target|default("all")}}'``. - -To run the plays, users can now use such commands as ``ansible-playbook --e 'targets=webservers'`` or ``ansible-playbook --limit webservers``. Either way, the collection owner should document their playbooks and how to use them in the ``docs/`` folder or ``README`` file. - -.. _developing_collections_tests_directory: - -tests directory ----------------- - -Ansible Collections are tested much like Ansible itself, by using the `ansible-test` utility which is released as part of Ansible, version 2.9.0 and newer. Because Ansible Collections are tested using the same tooling as Ansible itself, by using the `ansible-test`, all Ansible developer documentation for testing is applicable for authoring Collections Tests with one key concept to keep in mind. - -See :ref:`testing_collections` for specific information on how to test collections with ``ansible-test``. - -When reading the :ref:`developing_testing` documentation, there will be content that applies to running Ansible from source code through a git clone, which is typical of an Ansible developer. However, it's not always typical for an Ansible Collection author to be running Ansible from source but instead from a stable release, and to create Collections it is not necessary to run Ansible from source. Therefore, when references of dealing with `ansible-test` binary paths, command completion, or environment variables are presented throughout the :ref:`developing_testing` documentation; keep in mind that it is not needed for Ansible Collection Testing because the act of installing the stable release of Ansible containing `ansible-test` is expected to setup those things for you. - -.. _meta_runtime_yml: - -meta directory and runtime.yml ------------------------------- - -A collection can store some additional metadata in a ``runtime.yml`` file in the collection's ``meta`` directory. The ``runtime.yml`` file supports the top level keys: - -- *requires_ansible*: - - The version of Ansible Core (ansible-core) required to use the collection. Multiple versions can be separated with a comma. - - .. code:: yaml - - requires_ansible: ">=2.10,<2.11" - - .. note:: although the version is a `PEP440 Version Specifier `_ under the hood, Ansible deviates from PEP440 behavior by truncating prerelease segments from the Ansible version. This means that Ansible 2.11.0b1 is compatible with something that ``requires_ansible: ">=2.11"``. - -- *plugin_routing*: - - Content in a collection that Ansible needs to load from another location or that has been deprecated/removed. - The top level keys of ``plugin_routing`` are types of plugins, with individual plugin names as subkeys. - To define a new location for a plugin, set the ``redirect`` field to another name. - To deprecate a plugin, use the ``deprecation`` field to provide a custom warning message and the removal version or date. If the plugin has been renamed or moved to a new location, the ``redirect`` field should also be provided. If a plugin is being removed entirely, ``tombstone`` can be used for the fatal error message and removal version or date. - - .. code:: yaml - - plugin_routing: - inventory: - kubevirt: - redirect: community.general.kubevirt - my_inventory: - tombstone: - removal_version: "2.0.0" - warning_text: my_inventory has been removed. Please use other_inventory instead. - modules: - my_module: - deprecation: - removal_date: "2021-11-30" - warning_text: my_module will be removed in a future release of this collection. Use another.collection.new_module instead. - redirect: another.collection.new_module - podman_image: - redirect: containers.podman.podman_image - module_utils: - ec2: - redirect: amazon.aws.ec2 - util_dir.subdir.my_util: - redirect: namespace.name.my_util - -- *import_redirection* - - A mapping of names for Python import statements and their redirected locations. - - .. code:: yaml - - import_redirection: - ansible.module_utils.old_utility: - redirect: ansible_collections.namespace_name.collection_name.plugins.module_utils.new_location - -- *action_groups* - - A mapping of groups and the list of action plugin and module names they contain. They may also have a special 'metadata' dictionary in the list, which can be used to include actions from other groups. - - .. code:: yaml - - action_groups: - groupname: - # The special metadata dictionary. All action/module names should be strings. - - metadata: - extend_group: - - another.collection.groupname - - another_group - - my_action - another_group: - - my_module - - another.collection.another_module - -.. seealso:: - - :ref:`distributing_collections` - Learn how to package and publish your collection - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_testing.rst b/docs/docsite/rst/dev_guide/developing_collections_testing.rst deleted file mode 100644 index 50d55ca5b58..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_testing.rst +++ /dev/null @@ -1,99 +0,0 @@ -.. _testing_collections: - -******************* -Testing collections -******************* - -Testing your collection ensures that your code works well and integrates well with the rest of the Ansible ecosystem. Your collection should pass the sanity tests for Ansible code. You should also add unit tests to cover the code in your collection and integration tests to cover the interactions between your collection and ansible-core. - -.. contents:: - :local: - :depth: 2 - -Testing tools -============= - -The main tool for testing collections is ``ansible-test``, Ansible's testing tool described in :ref:`developing_testing` and provided by both the ``ansible`` and ``ansible-core`` packages. - -You can run several sanity tests, as well as run unit and integration tests for plugins using ``ansible-test``. When you test collections, test against the ansible-core version(s) you are targeting. - -You must always execute ``ansible-test`` from the root directory of a collection. You can run ``ansible-test`` in Docker containers without installing any special requirements. The Ansible team uses this approach in Azure Pipelines both in the ansible/ansible GitHub repository and in the large community collections such as `community.general `_ and `community.network `_. The examples below demonstrate running tests in Docker containers. - -Sanity tests ------------- - -To run all sanity tests: - -.. code-block:: shell-session - - ansible-test sanity --docker default -v - -See :ref:`testing_sanity` for more information. See the :ref:`full list of sanity tests ` for details on the sanity tests and how to fix identified issues. - -Adding unit tests ------------------ - -You must place unit tests in the appropriate ``tests/unit/plugins/`` directory. For example, you would place tests for ``plugins/module_utils/foo/bar.py`` in ``tests/unit/plugins/module_utils/foo/test_bar.py`` or ``tests/unit/plugins/module_utils/foo/bar/test_bar.py``. For examples, see the `unit tests in community.general `_. - -To run all unit tests for all supported Python versions: - -.. code-block:: shell-session - - ansible-test units --docker default -v - -To run all unit tests only for a specific Python version: - -.. code-block:: shell-session - - ansible-test units --docker default -v --python 3.6 - -To run only a specific unit test: - -.. code-block:: shell-session - - ansible-test units --docker default -v --python 3.6 tests/unit/plugins/module_utils/foo/test_bar.py - -You can specify Python requirements in the ``tests/unit/requirements.txt`` file. See :ref:`testing_units` for more information, especially on fixture files. - -.. _collections_adding_integration_test: - -Adding integration tests ------------------------- - -You must place integration tests in the appropriate ``tests/integration/targets/`` directory. For module integration tests, you can use the module name alone. For example, you would place integration tests for ``plugins/modules/foo.py`` in a directory called ``tests/integration/targets/foo/``. For non-module plugin integration tests, you must add the plugin type to the directory name. For example, you would place integration tests for ``plugins/connections/bar.py`` in a directory called ``tests/integration/targets/connection_bar/``. For lookup plugins, the directory must be called ``lookup_foo``, for inventory plugins, ``inventory_foo``, and so on. - -You can write two different kinds of integration tests: - -* Ansible role tests run with ``ansible-playbook`` and validate various aspects of the module. They can depend on other integration tests (usually named ``prepare_bar`` or ``setup_bar``, which prepare a service or install a requirement named ``bar`` in order to test module ``foo``) to set-up required resources, such as installing required libraries or setting up server services. -* ``runme.sh`` tests run directly as scripts. They can set up inventory files, and execute ``ansible-playbook`` or ``ansible-inventory`` with various settings. - -For examples, see the `integration tests in community.general `_. See also :ref:`testing_integration` for more details. - -Since integration tests can install requirements, and set-up, start and stop services, we recommended running them in docker containers or otherwise restricted environments whenever possible. By default, ``ansible-test`` supports Docker images for several operating systems. See the `list of supported docker images `_ for all options. Use the ``default`` image mainly for platform-independent integration tests, such as those for cloud modules. The following examples use the ``fedora35`` image. - -To execute all integration tests for a collection: - -.. code-block:: shell-session - - ansible-test integration --docker fedora35 -v - -If you want more detailed output, run the command with ``-vvv`` instead of ``-v``. Alternatively, specify ``--retry-on-error`` to automatically re-run failed tests with higher verbosity levels. - -To execute only the integration tests in a specific directory: - -.. code-block:: shell-session - - ansible-test integration --docker fedora35 -v connection_bar - -You can specify multiple target names. Each target name is the name of a directory in ``tests/integration/targets/``. - -.. seealso:: - - :ref:`developing_testing` - More resources on testing Ansible - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_core.rst b/docs/docsite/rst/dev_guide/developing_core.rst deleted file mode 100644 index ce8b95ece4a..00000000000 --- a/docs/docsite/rst/dev_guide/developing_core.rst +++ /dev/null @@ -1,22 +0,0 @@ -*************************** -Developing ``ansible-core`` -*************************** - -Although ``ansible-core`` (the code hosted in the `ansible/ansible repository `_ on GitHub) includes a few plugins that can be swapped out by the playbook directives or configuration, much of the code there is not modular. The documents here give insight into how the parts of ``ansible-core`` work together. - -.. toctree:: - :maxdepth: 1 - - core_branches_and_tags - developing_program_flow_modules - -.. seealso:: - - :ref:`developing_api` - Learn about the Python API for task execution - :ref:`developing_plugins` - Learn about developing plugins - `Mailing List `_ - The development mailing list - `irc.libera.chat `_ - #ansible-devel IRC chat channel diff --git a/docs/docsite/rst/dev_guide/developing_inventory.rst b/docs/docsite/rst/dev_guide/developing_inventory.rst deleted file mode 100644 index 8697e943c30..00000000000 --- a/docs/docsite/rst/dev_guide/developing_inventory.rst +++ /dev/null @@ -1,514 +0,0 @@ -.. _developing_inventory: - -**************************** -Developing dynamic inventory -**************************** - -Ansible can pull inventory information from dynamic sources, including cloud sources, by using the supplied :ref:`inventory plugins `. For details about how to pull inventory information, see :ref:`dynamic_inventory`. If the source you want is not currently covered by existing plugins, you can create your own inventory plugin as with any other plugin type. - -In previous versions, you had to create a script or program that could output JSON in the correct format when invoked with the proper arguments. -You can still use and write inventory scripts, as we ensured backwards compatibility through the :ref:`script inventory plugin ` -and there is no restriction on the programming language used. -If you choose to write a script, however, you will need to implement some features yourself such as caching, configuration management, dynamic variable and group composition, and so on. -If you use :ref:`inventory plugins ` instead, you can use the Ansible codebase and add these common features automatically. - -.. contents:: Topics - :local: - - -.. _inventory_sources: - -Inventory sources -================= - -Inventory sources are the input strings that inventory plugins work with. -An inventory source can be a path to a file or to a script, or it can be raw data that the plugin can interpret. - -The table below shows some examples of inventory plugins and the source types that you can pass to them with ``-i`` on the command line. - -+--------------------------------------------+-----------------------------------------+ -| Plugin | Source | -+--------------------------------------------+-----------------------------------------+ -| :ref:`host list ` | A comma-separated list of hosts | -+--------------------------------------------+-----------------------------------------+ -| :ref:`yaml ` | Path to a YAML format data file | -+--------------------------------------------+-----------------------------------------+ -| :ref:`constructed ` | Path to a YAML configuration file | -+--------------------------------------------+-----------------------------------------+ -| :ref:`ini ` | Path to an INI formatted data file | -+--------------------------------------------+-----------------------------------------+ -| :ref:`virtualbox ` | Path to a YAML configuration file | -+--------------------------------------------+-----------------------------------------+ -| :ref:`script plugin ` | Path to an executable that outputs JSON | -+--------------------------------------------+-----------------------------------------+ - - -.. _developing_inventory_inventory_plugins: - -Inventory plugins -================= - -Like most plugin types (except modules), inventory plugins must be developed in Python. They execute on the controller and should therefore adhere to the :ref:`control_node_requirements`. - -Most of the documentation in :ref:`developing_plugins` also applies here. You should read that document first for a general understanding and then come back to this document for specifics on inventory plugins. - -Normally, inventory plugins are executed at the start of a run, and before the playbooks, plays, or roles are loaded. -However, you can use the ``meta: refresh_inventory`` task to clear the current inventory and execute the inventory plugins again, and this task will generate a new inventory. - -If you use the persistent cache, inventory plugins can also use the configured cache plugin to store and retrieve data. Caching inventory avoids making repeated and costly external calls. - -.. _developing_an_inventory_plugin: - -Developing an inventory plugin ------------------------------- - -The first thing you want to do is use the base class: - -.. code-block:: python - - from ansible.plugins.inventory import BaseInventoryPlugin - - class InventoryModule(BaseInventoryPlugin): - - NAME = 'myplugin' # used internally by Ansible, it should match the file name but not required - -If the inventory plugin is in a collection, the NAME should be in the 'namespace.collection_name.myplugin' format. The base class has a couple of methods that each plugin should implement and a few helpers for parsing the inventory source and updating the inventory. - -After you have the basic plugin working, you can incorporate other features by adding more base classes: - -.. code-block:: python - - from ansible.plugins.inventory import BaseInventoryPlugin, Constructable, Cacheable - - class InventoryModule(BaseInventoryPlugin, Constructable, Cacheable): - - NAME = 'myplugin' - -For the bulk of the work in a plugin, we mostly want to deal with 2 methods ``verify_file`` and ``parse``. - -.. _inventory_plugin_verify_file: - -verify_file method -^^^^^^^^^^^^^^^^^^ - -Ansible uses this method to quickly determine if the inventory source is usable by the plugin. The determination does not need to be 100% accurate, as there might be an overlap in what plugins can handle and by default Ansible will try the enabled plugins as per their sequence. - -.. code-block:: python - - def verify_file(self, path): - ''' return true/false if this is possibly a valid file for this plugin to consume ''' - valid = False - if super(InventoryModule, self).verify_file(path): - # base class verifies that file exists and is readable by current user - if path.endswith(('virtualbox.yaml', 'virtualbox.yml', 'vbox.yaml', 'vbox.yml')): - valid = True - return valid - -In the above example, from the :ref:`virtualbox inventory plugin `, we screen for specific file name patterns to avoid attempting to consume any valid YAML file. You can add any type of condition here, but the most common one is 'extension matching'. If you implement extension matching for YAML configuration files, the path suffix . should be accepted. All valid extensions should be documented in the plugin description. - -The following is another example that does not use a 'file' but the inventory source string itself, -from the :ref:`host list ` plugin: - -.. code-block:: python - - def verify_file(self, path): - ''' don't call base class as we don't expect a path, but a host list ''' - host_list = path - valid = False - b_path = to_bytes(host_list, errors='surrogate_or_strict') - if not os.path.exists(b_path) and ',' in host_list: - # the path does NOT exist and there is a comma to indicate this is a 'host list' - valid = True - return valid - -This method is just to expedite the inventory process and avoid unnecessary parsing of sources that are easy to filter out before causing a parse error. - -.. _inventory_plugin_parse: - -parse method -^^^^^^^^^^^^ - -This method does the bulk of the work in the plugin. -It takes the following parameters: - - * inventory: inventory object with existing data and the methods to add hosts/groups/variables to inventory - * loader: Ansible's DataLoader. The DataLoader can read files, auto load JSON/YAML and decrypt vaulted data, and cache read files. - * path: string with inventory source (this is usually a path, but is not required) - * cache: indicates whether the plugin should use or avoid caches (cache plugin and/or loader) - - -The base class does some minimal assignment for reuse in other methods. - -.. code-block:: python - - def parse(self, inventory, loader, path, cache=True): - - self.loader = loader - self.inventory = inventory - self.templar = Templar(loader=loader) - -It is up to the plugin now to parse the provided inventory source and translate it into Ansible inventory. -To facilitate this, the example below uses a few helper functions: - -.. code-block:: python - - NAME = 'myplugin' - - def parse(self, inventory, loader, path, cache=True): - - # call base method to ensure properties are available for use with other helper methods - super(InventoryModule, self).parse(inventory, loader, path, cache) - - # this method will parse 'common format' inventory sources and - # update any options declared in DOCUMENTATION as needed - config = self._read_config_data(path) - - # if NOT using _read_config_data you should call set_options directly, - # to process any defined configuration for this plugin, - # if you don't define any options you can skip - #self.set_options() - - # example consuming options from inventory source - mysession = apilib.session(user=self.get_option('api_user'), - password=self.get_option('api_pass'), - server=self.get_option('api_server') - ) - - - # make requests to get data to feed into inventory - mydata = mysession.getitall() - - #parse data and create inventory objects: - for colo in mydata: - for server in mydata[colo]['servers']: - self.inventory.add_host(server['name']) - self.inventory.set_variable(server['name'], 'ansible_host', server['external_ip']) - -The specifics will vary depending on API and structure returned. Remember that if you get an inventory source error or any other issue, you should ``raise AnsibleParserError`` to let Ansible know that the source was invalid or the process failed. - -For examples on how to implement an inventory plugin, see the source code here: -`lib/ansible/plugins/inventory `_. - -.. _inventory_object: - -inventory object -^^^^^^^^^^^^^^^^ - -The ``inventory`` object passed to ``parse`` has helpful methods for populating inventory. - -``add_group`` adds a group to inventory if it doesn't already exist. It takes the group name as the only positional argument. - -``add_child`` adds a group or host that exists in inventory to a parent group in inventory. It takes two positional arguments, the name of the parent group and the name of the child group or host. - -``add_host`` adds a host to inventory if it doesn't already exist, optionally to a specific group. It takes the host name as the first argument and accepts two optional keyword arguments, ``group`` and ``port``. ``group`` is the name of a group in inventory, and ``port`` is an integer. - -``set_variable`` adds a variable to a group or host in inventory. It takes three positional arguments: the name of the group or host, the name of the variable, and the value of the variable. - -To create groups and variables using Jinja2 expressions, see the section on implementing ``constructed`` features below. - -To see other inventory object methods, see the source code here: -`lib/ansible/inventory/data.py `_. - -.. _inventory_plugin_caching: - -inventory cache -^^^^^^^^^^^^^^^ - -To cache the inventory, extend the inventory plugin documentation with the inventory_cache documentation fragment and use the Cacheable base class. - -.. code-block:: yaml - - extends_documentation_fragment: - - inventory_cache - -.. code-block:: python - - class InventoryModule(BaseInventoryPlugin, Constructable, Cacheable): - - NAME = 'myplugin' - -Next, load the cache plugin specified by the user to read from and update the cache. If your inventory plugin uses YAML-based configuration files and the ``_read_config_data`` method, the cache plugin is loaded within that method. If your inventory plugin does not use ``_read_config_data``, you must load the cache explicitly with ``load_cache_plugin``. - -.. code-block:: python - - NAME = 'myplugin' - - def parse(self, inventory, loader, path, cache=True): - super(InventoryModule, self).parse(inventory, loader, path) - - self.load_cache_plugin() - -Before using the cache plugin, you must retrieve a unique cache key by using the ``get_cache_key`` method. This task needs to be done by all inventory modules using the cache, so that you don't use/overwrite other parts of the cache. - -.. code-block:: python - - def parse(self, inventory, loader, path, cache=True): - super(InventoryModule, self).parse(inventory, loader, path) - - self.load_cache_plugin() - cache_key = self.get_cache_key(path) - -Now that you've enabled caching, loaded the correct plugin, and retrieved a unique cache key, you can set up the flow of data between the cache and your inventory using the ``cache`` parameter of the ``parse`` method. This value comes from the inventory manager and indicates whether the inventory is being refreshed (such as by the ``--flush-cache`` or the meta task ``refresh_inventory``). Although the cache shouldn't be used to populate the inventory when being refreshed, the cache should be updated with the new inventory if the user has enabled caching. You can use ``self._cache`` like a dictionary. The following pattern allows refreshing the inventory to work in conjunction with caching. - -.. code-block:: python - - def parse(self, inventory, loader, path, cache=True): - super(InventoryModule, self).parse(inventory, loader, path) - - self.load_cache_plugin() - cache_key = self.get_cache_key(path) - - # cache may be True or False at this point to indicate if the inventory is being refreshed - # get the user's cache option too to see if we should save the cache if it is changing - user_cache_setting = self.get_option('cache') - - # read if the user has caching enabled and the cache isn't being refreshed - attempt_to_read_cache = user_cache_setting and cache - # update if the user has caching enabled and the cache is being refreshed; update this value to True if the cache has expired below - cache_needs_update = user_cache_setting and not cache - - # attempt to read the cache if inventory isn't being refreshed and the user has caching enabled - if attempt_to_read_cache: - try: - results = self._cache[cache_key] - except KeyError: - # This occurs if the cache_key is not in the cache or if the cache_key expired, so the cache needs to be updated - cache_needs_update = True - if not attempt_to_read_cache or cache_needs_update: - # parse the provided inventory source - results = self.get_inventory() - if cache_needs_update: - self._cache[cache_key] = results - - # submit the parsed data to the inventory object (add_host, set_variable, etc) - self.populate(results) - -After the ``parse`` method is complete, the contents of ``self._cache`` is used to set the cache plugin if the contents of the cache have changed. - -You have three other cache methods available: - - ``set_cache_plugin`` forces the cache plugin to be set with the contents of ``self._cache``, before the ``parse`` method completes - - ``update_cache_if_changed`` sets the cache plugin only if ``self._cache`` has been modified, before the ``parse`` method completes - - ``clear_cache`` flushes the cache, ultimately by calling the cache plugin's ``flush()`` method, whose implementation is dependent upon the particular cache plugin in use. Note that if the user is using the same cache backend for facts and inventory, both will get flushed. To avoid this, the user can specify a distinct cache backend in their inventory plugin configuration. - -constructed features -^^^^^^^^^^^^^^^^^^^^ - -Inventory plugins can create host variables and groups from Jinja2 expressions and variables by using features from the ``constructed`` inventory plugin. To do this, use the ``Constructable`` base class and extend the inventory plugin's documentation with the ``constructed`` documentation fragment. - -.. code-block:: yaml - - extends_documentation_fragment: - - constructed - -.. code-block:: python - - class InventoryModule(BaseInventoryPlugin, Constructable): - - NAME = 'ns.coll.myplugin' - -There are three main options in the ``constructed`` documentation fragment: - -``compose`` creates variables using Jinja2 expressions. This is implemented by calling the ``_set_composite_vars`` method. -``keyed_groups`` creates groups of hosts based on variable values. This is implemented by calling the ``_add_host_to_keyed_groups`` method. -``groups`` creates groups based on Jinja2 conditionals. This is implemented by calling the ``_add_host_to_composed_groups`` method. - -Each method should be called for every host added to inventory. Three positional arguments are required: the constructed option, a dictionary of variables, and a host name. Calling the method ``_set_composite_vars`` first will allow ``keyed_groups`` and ``groups`` to use the composed variables. - -By default, undefined variables are ignored. This is permitted by default for ``compose`` so you can make the variable definitions depend on variables that will be populated later in a play from other sources. For groups, it allows using variables that are not always present without having to use the ``default`` filter. To support configuring undefined variables to be an error, pass the constructed option ``strict`` to each of the methods as a keyword argument. - -``keyed_groups`` and ``groups`` use any variables already associated with the host (for example, from an earlier inventory source). ``_add_host_to_keyed_groups`` and ``add_host_to_composed_groups`` can turn this off by passing the keyword argument ``fetch_hostvars``. - -Here is an example using all three methods: - -.. code-block:: python - - def add_host(self, hostname, host_vars): - self.inventory.add_host(hostname, group='all') - - for var_name, var_value in host_vars.items(): - self.inventory.set_variable(hostname, var_name, var_value) - - strict = self.get_option('strict') - - # Add variables created by the user's Jinja2 expressions to the host - self._set_composite_vars(self.get_option('compose'), host_vars, hostname, strict=True) - - # Create user-defined groups using variables and Jinja2 conditionals - self._add_host_to_composed_groups(self.get_option('groups'), host_vars, hostname, strict=strict) - self._add_host_to_keyed_groups(self.get_option('keyed_groups'), host_vars, hostname, strict=strict) - -By default, group names created with ``_add_host_to_composed_groups()`` and ``_add_host_to_keyed_groups()`` are valid Python identifiers. Invalid characters are replaced with an underscore ``_``. A plugin can change the sanitization used for the constructed features by setting ``self._sanitize_group_name`` to a new function. The core engine also does sanitization, so if the custom function is less strict it should be used in conjunction with the configuration setting ``TRANSFORM_INVALID_GROUP_CHARS``. - -.. code-block:: python - - from ansible.inventory.group import to_safe_group_name - - class InventoryModule(BaseInventoryPlugin, Constructable): - - NAME = 'ns.coll.myplugin' - - @staticmethod - def custom_sanitizer(name): - return to_safe_group_name(name, replacer='') - - def parse(self, inventory, loader, path, cache=True): - super(InventoryModule, self).parse(inventory, loader, path) - - self._sanitize_group_name = custom_sanitizer - -.. _inventory_source_common_format: - -Common format for inventory sources ------------------------------------ - -To simplify development, most plugins use a standard YAML-based configuration file as the inventory source. The file has only one required field ``plugin``, which should contain the name of the plugin that is expected to consume the file. -Depending on other common features used, you might need other fields, and you can add custom options in each plugin as required. -For example, if you use the integrated caching, ``cache_plugin``, ``cache_timeout`` and other cache-related fields could be present. - -.. _inventory_development_auto: - -The 'auto' plugin ------------------ - -From Ansible 2.5 onwards, we include the :ref:`auto inventory plugin ` and enable it by default. If the ``plugin`` field in your standard configuration file matches the name of your inventory plugin, the ``auto`` inventory plugin will load your plugin. The 'auto' plugin makes it easier to use your plugin without having to update configurations. - - -.. _inventory_scripts: -.. _developing_inventory_scripts: - -Inventory scripts -================= - -Even though we now have inventory plugins, we still support inventory scripts, not only for backwards compatibility but also to allow users to use other programming languages. - - -.. _inventory_script_conventions: - -Inventory script conventions ----------------------------- - -Inventory scripts must accept the ``--list`` and ``--host `` arguments. Although other arguments are allowed, Ansible will not use them. -Such arguments might still be useful for executing the scripts directly. - -When the script is called with the single argument ``--list``, the script must output to stdout a JSON object that contains all the groups to be managed. Each group's value should be either an object containing a list of each host, any child groups, and potential group variables, or simply a list of hosts: - - -.. code-block:: json - - { - "group001": { - "hosts": ["host001", "host002"], - "vars": { - "var1": true - }, - "children": ["group002"] - }, - "group002": { - "hosts": ["host003","host004"], - "vars": { - "var2": 500 - }, - "children":[] - } - - } - -If any of the elements of a group are empty, they may be omitted from the output. - -When called with the argument ``--host `` (where is a host from above), the script must print a JSON object, either empty or containing variables to make them available to templates and playbooks. For example: - -.. code-block:: json - - { - "VAR001": "VALUE", - "VAR002": "VALUE" - } - -Printing variables is optional. If the script does not print variables, it should print an empty JSON object. - -.. _inventory_script_tuning: - -Tuning the external inventory script ------------------------------------- - -.. versionadded:: 1.3 - -The stock inventory script system mentioned above works for all versions of Ansible, but calling ``--host`` for every host can be rather inefficient, especially if it involves API calls to a remote subsystem. - -To avoid this inefficiency, if the inventory script returns a top-level element called "_meta", it is possible to return all the host variables in a single script execution. When this meta element contains a value for "hostvars", the inventory script will not be invoked with ``--host`` for each host. This behavior results in a significant performance increase for large numbers of hosts. - -The data to be added to the top-level JSON object looks like this: - -.. code-block:: text - - { - - # results of inventory script as above go here - # ... - - "_meta": { - "hostvars": { - "host001": { - "var001" : "value" - }, - "host002": { - "var002": "value" - } - } - } - } - -To satisfy the requirements of using ``_meta``, to prevent ansible from calling your inventory with ``--host`` you must at least populate ``_meta`` with an empty ``hostvars`` object. -For example: - -.. code-block:: text - - { - - # results of inventory script as above go here - # ... - - "_meta": { - "hostvars": {} - } - } - - -.. _replacing_inventory_ini_with_dynamic_provider: - -If you intend to replace an existing static inventory file with an inventory script, it must return a JSON object which contains an 'all' group that includes every host in the inventory as a member and every group in the inventory as a child. It should also include an 'ungrouped' group which contains all hosts which are not members of any other group. -A skeleton example of this JSON object is: - -.. code-block:: json - - { - "_meta": { - "hostvars": {} - }, - "all": { - "children": [ - "ungrouped" - ] - }, - "ungrouped": { - "children": [ - ] - } - } - -An easy way to see how this should look is using :ref:`ansible-inventory`, which also supports ``--list`` and ``--host`` parameters like an inventory script would. - -.. seealso:: - - :ref:`developing_api` - Python API to Playbooks and Ad Hoc Task Execution - :ref:`developing_modules_general` - Get started with developing a module - :ref:`developing_plugins` - How to develop plugins - `AWX `_ - REST API endpoint and GUI for Ansible, syncs with dynamic inventory - `Development Mailing List `_ - Mailing list for development topics - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_locally.rst b/docs/docsite/rst/dev_guide/developing_locally.rst deleted file mode 100644 index 2eefbc95280..00000000000 --- a/docs/docsite/rst/dev_guide/developing_locally.rst +++ /dev/null @@ -1,145 +0,0 @@ -.. _using_local_modules_and_plugins: -.. _developing_locally: - -********************************** -Adding modules and plugins locally -********************************** - -You can extend Ansible by adding custom modules or plugins. You can create them from scratch or copy existing ones for local use. You can store a local module or plugin on your Ansible control node and share it with your team or organization. You can also share plugins and modules by including them in a collection, then publishing the collection on Ansible Galaxy. - -If you are using a local module or plugin but Ansible cannot find it, this page is all you need. - -If you want to create a plugin or a module, see :ref:`developing_plugins`, :ref:`developing_modules_general` and :ref:`developing_collections`. - -Extending Ansible with local modules and plugins offers shortcuts such as: - -* You can copy other people's modules and plugins. -* When writing a new module, you can choose any programming language you like. -* You do not have to clone any repositories. -* You do not have to open a pull request. -* You do not have to add tests (though we recommend that you do!). - -.. contents:: - :local: - -.. _modules_vs_plugins: - -Modules and plugins: what is the difference? -============================================ -If you are looking to add functionality to Ansible, you might wonder whether you need a module or a plugin. Here is a quick overview to help you understand what you need: - -* :ref:`Plugins ` extend Ansible's core functionality. Most plugin types execute on the control node within the ``/usr/bin/ansible`` process. Plugins offer options and extensions for the core features of Ansible: transforming data, logging output, connecting to inventory, and more. -* Modules are a type of plugin that execute automation tasks on a 'target' (usually a remote system). Modules work as standalone scripts that Ansible executes in their own process outside of the controller. Modules interface with Ansible mostly via JSON, accepting arguments and returning information by printing a JSON string to stdout before exiting. Unlike the other plugins (which must be written in Python), modules can be written in any language; although Ansible provides modules in Python and Powershell only. - -.. _use_collections: - -Adding modules and plugins in collections -========================================= - -You can add modules and plugins by :ref:`creating a collection `. With a collection, you can use custom modules and plugins in any playbook or role. You can share your collection easily at any time through Ansible Galaxy. - -The rest of this page describes other methods of using local, standalone modules or plugins. - -.. _local_modules: - -Adding a module or plugin outside of a collection -================================================== - -You can configure Ansible to load standalone local modules or plugins in specific locations and make them available to all playbooks and roles (using configured paths). Alternatively, you can make a non-collection local module or plugin available only to certain playbooks or roles (via adjacent paths). - -Adding standalone local modules for all playbooks and roles ------------------------------------------------------------ - -To load standalone local modules automatically and make them available to all playbooks and roles, use the :ref:`DEFAULT_MODULE_PATH` configuration setting or the ``ANSIBLE_LIBRARY`` environment variable. The configuration setting and environment variable take a colon-separated list, similar to ``$PATH``. You have two options: - -* Add your standalone local module to one of the default configured locations. See the :ref:`DEFAULT_MODULE_PATH` configuration setting for details. Default locations may change without notice. -* Add the location of your standalone local module to an environment variable or configuration: - * the ``ANSIBLE_LIBRARY`` environment variable - * the :ref:`DEFAULT_MODULE_PATH` configuration setting - -To view your current configuration settings for modules: - -.. code-block:: text - - ansible-config dump |grep DEFAULT_MODULE_PATH - -After you save your module file in one of these locations, Ansible loads it and you can use it in any local task, playbook, or role. - -To confirm that ``my_local_module`` is available: - -* type ``ansible localhost -m my_local_module`` to see the output for that module, or -* type ``ansible-doc -t module my_local_module`` to see the documentation for that module - -.. note:: This applies to all plugin types but requires specific configuration and/or adjacent directories for each plugin type, see below. -.. note:: - - The ``ansible-doc`` command can parse module documentation from modules written in Python or an adjacent YAML file. If you have a module written in a programming language other than Python, you should write the documentation in a Python or YAML file adjacent to the module file. :ref:`adjacent_yaml_doc` - -Adding standalone local modules for selected playbooks or a single role ------------------------------------------------------------------------ - -Ansible automatically loads all executable files from certain directories adjacent to your playbook or role as modules. Standalone modules in these locations are available only to the specific playbook, playbooks, or role in the parent directory. - -* To use a standalone module only in a selected playbook or playbooks, store the module in a subdirectory called ``library`` in the directory that contains the playbook or playbooks. -* To use a standalone module only in a single role, store the module in a subdirectory called ``library`` within that role. - -.. note:: This applies to all plugin types but requires specific configuration and/or adjacent directories for each plugin type, see below. - -.. warning:: - - Roles contained in collections cannot contain any modules or other plugins. All plugins in a collection must live in the collection ``plugins`` directory tree. All plugins in that tree are accessible to all roles in the collection. If you are developing new modules, we recommend distributing them in :ref:`collections `, not in roles. - -.. _distributing_plugins: -.. _local_plugins: - -Adding a non-module plugin locally outside of a collection -========================================================== - -You can configure Ansible to load standalone local plugins in a specified location or locations and make them available to all playbooks and roles. Alternatively, you can make a standalone local plugin available only to specific playbooks or roles. - -.. note:: - - Although modules are plugins, the naming patterns for directory names and environment variables that apply to other plugin types do not apply to modules. See :ref:`local_modules`. - -Adding local non-module plugins for all playbooks and roles ------------------------------------------------------------ - -To load standalone local plugins automatically and make them available to all playbooks and roles, use the configuration setting or environment variable for the type of plugin you are adding. These configuration settings and environment variables take a colon-separated list, similar to ``$PATH``. You have two options: - -* Add your local plugin to one of the default configured locations. See :ref:`configuration settings ` for details on the correct configuration setting for the plugin type. Default locations may change without notice. -* Add the location of your local plugin to an environment variable or configuration: - * the relevant ``ANSIBLE_plugin_type_PLUGINS`` environment variable - for example, ``$ANSIBLE_INVENTORY_PLUGINS`` or ``$ANSIBLE_VARS_PLUGINS`` - * the relevant ``plugin_type_PATH`` configuration setting, most of which begin with ``DEFAULT_`` - for example, ``DEFAULT_CALLBACK_PLUGIN_PATH`` or ``DEFAULT_FILTER_PLUGIN_PATH`` or ``BECOME_PLUGIN_PATH`` - -To view your current configuration settings for non-module plugins: - -.. code-block:: text - - ansible-config dump |grep plugin_type_PATH - -After your plugin file is added to one of these locations, Ansible loads it and you can use it in any local module, task, playbook, or role. For more information on environment variables and configuration settings, see :ref:`ansible_configuration_settings`. - -To confirm that ``plugins/plugin_type/my_local_plugin`` is available: - -* type ``ansible-doc -t my_local_lookup_plugin`` to see the documentation for that plugin - for example, ``ansible-doc -t lookup my_local_lookup_plugin`` - -The ``ansible-doc`` command works for most plugin types, but not for action, filter, or test plugins. See :ref:`ansible-doc` for more details. - -Adding standalone local plugins for selected playbooks or a single role ------------------------------------------------------------------------ - -Ansible automatically loads all plugins from certain directories adjacent to your playbook or role, loading each type of plugin separately from a directory named for the type of plugin. Standalone plugins in these locations are available only to the specific playbook, playbooks, or role in the parent directory. - -* To use a standalone plugin only in a selected playbook or playbooks, store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``callback_plugins`` or ``inventory_plugins``) in the directory that contains the playbooks. These directories must use the ``_plugins`` suffix. For a full list of plugin types, see :ref:`working_with_plugins`. -* To use a standalone plugin only in a single role, store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``cache_plugins`` or ``strategy_plugins``) within that role. When shipped as part of a role, the plugin is available as soon as the role is executed. These directories must use the ``_plugins`` suffix. For a full list of plugin types, see :ref:`working_with_plugins`. - -.. warning:: - - Roles contained in collections cannot contain any plugins. All plugins in a collection must live in the collection ``plugins`` directory tree. All plugins in that tree are accessible to all roles in the collection. If you are developing new plugins, we recommend distributing them in :ref:`collections `, not in roles. - -.. _ansible.legacy.custom: - -Using ``ansible.legacy`` to access custom versions of an ``ansible.builtin`` module -=================================================================================== - -If you need to override one of the ``ansible.builtin`` modules and are using FQCN, you need to use ``ansible.legacy`` as part of the fully-qualified collection name (FQCN). For example, if you had your own ``copy`` module, you would access it as ``ansible.legacy.copy``. See :ref:`using_ansible_legacy` for details on how to use custom modules with roles within a collection. diff --git a/docs/docsite/rst/dev_guide/developing_module_utilities.rst b/docs/docsite/rst/dev_guide/developing_module_utilities.rst deleted file mode 100644 index 85ac7aab51e..00000000000 --- a/docs/docsite/rst/dev_guide/developing_module_utilities.rst +++ /dev/null @@ -1,73 +0,0 @@ -.. _developing_module_utilities: - -************************************* -Using and developing module utilities -************************************* - -Ansible provides a number of module utilities, or snippets of shared code, that -provide helper functions you can use when developing your own modules. The -``basic.py`` module utility provides the main entry point for accessing the -Ansible library, and all Python Ansible modules must import something from -``ansible.module_utils``. A common option is to import ``AnsibleModule``: - -.. code-block:: python - - from ansible.module_utils.basic import AnsibleModule - -The ``ansible.module_utils`` namespace is not a plain Python package: it is -constructed dynamically for each task invocation, by extracting imports and -resolving those matching the namespace against a :ref:`search path ` derived from the -active configuration. - -To reduce the maintenance burden in a collection or in local modules, you can extract -duplicated code into one or more module utilities and import them into your modules. For example, if you have your own custom modules that import a ``my_shared_code`` library, you can place that into a ``./module_utils/my_shared_code.py`` file like this: - -.. code-block:: python - - from ansible.module_utils.my_shared_code import MySharedCodeClient - -When you run ``ansible-playbook``, Ansible will merge any files in your local ``module_utils`` directories into the ``ansible.module_utils`` namespace in the order defined by the :ref:`Ansible search path `. - -Naming and finding module utilities -=================================== - -You can generally tell what a module utility does from its name and/or its location. Generic utilities (shared code used by many different kinds of modules) live in the main ansible/ansible codebase, in the ``common`` subdirectory or in the root directory of ``lib/ansible/module_utils``. Utilities used by a particular set of modules generally live in the same collection as those modules. For example: - -* ``lib/ansible/module_utils/urls.py`` contains shared code for parsing URLs -* ``openstack.cloud.plugins.module_utils.openstack.py`` contains utilities for modules that work with OpenStack instances -* ``ansible.netcommon.plugins.module_utils.network.common.config.py`` contains utility functions for use by networking modules - -Following this pattern with your own module utilities makes everything easy to find and use. - -.. _standard_mod_utils: - -Standard module utilities -========================= - -Ansible ships with an extensive library of ``module_utils`` files. You can find the module utility source code in the ``lib/ansible/module_utils`` directory under your main Ansible path. We describe the most widely used utilities below. For more details on any specific module utility, please see the `source code for module_utils `_. - -.. include:: shared_snippets/licensing.txt - -- ``api.py`` - Supports generic API modules -- ``basic.py`` - General definitions and helper utilities for Ansible modules -- ``common/dict_transformations.py`` - Helper functions for dictionary transformations -- ``common/file.py`` - Helper functions for working with files -- ``common/text/`` - Helper functions for converting and formatting text -- ``common/parameters.py`` - Helper functions for dealing with module parameters -- ``common/sys_info.py`` - Functions for getting distribution and platform information -- ``common/validation.py`` - Helper functions for validating module parameters against a module argument spec -- ``facts/`` - Directory of utilities for modules that return facts. See `PR 23012 `_ for more information -- ``json_utils.py`` - Utilities for filtering unrelated output around module JSON output, like leading and trailing lines -- ``powershell/`` - Directory of definitions and helper functions for Windows PowerShell modules -- ``pycompat24.py`` - Exception workaround for Python 2.4 -- ``service.py`` - Utilities to enable modules to work with Linux services (placeholder, not in use) -- ``six/__init__.py`` - Bundled copy of the `Six Python library `_ to aid in writing code compatible with both Python 2 and Python 3 -- ``splitter.py`` - String splitting and manipulation utilities for working with Jinja2 templates -- ``urls.py`` - Utilities for working with http and https requests - -Several commonly-used utilities migrated to collections in Ansible 2.10, including: - -- ``ismount.py`` migrated to ``ansible.posix.plugins.module_utils.mount.py`` - Single helper function that fixes os.path.ismount -- ``known_hosts.py`` migrated to ``community.general.plugins.module_utils.known_hosts.py`` - utilities for working with known_hosts file - -For a list of migrated content with destination collections, see the `runtime.yml file `_. diff --git a/docs/docsite/rst/dev_guide/developing_modules.rst b/docs/docsite/rst/dev_guide/developing_modules.rst deleted file mode 100644 index c78b8ed2386..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. _developing_modules: -.. _module_dev_should_you: - -**************************** -Should you develop a module? -**************************** - -Developing Ansible modules is easy, but often it is not necessary. Before you start writing a new module, ask: - -1. Does a similar module already exist? - -An existing module may cover the functionality you want. Ansible collections include thousands of modules. Search our :ref:`list of included collections ` or `Ansible Galaxy `_ to see if an existing module does what you need. - -2. Should you use or develop an action plugin instead of a module? - -An action plugin may be the best way to get the functionality you want. Action plugins run on the control node instead of on the managed node, and their functionality is available to all modules. For more information about developing plugins, read the :ref:`developing plugins page `. - -3. Should you use a role instead of a module? - -A combination of existing modules may cover the functionality you want. You can write a role for this type of use case. Check out the :ref:`roles documentation`. - -4. Should you create a collection instead of a single module? - -The functionality you want may be too large for a single module. If you want to connect Ansible to a new cloud provider, database, or network platform, you may need to :ref:`develop a new collection`. - -* Each module should have a concise and well defined functionality. Basically, follow the UNIX philosophy of doing one thing well. - -* A module should not require that a user know all the underlying options of an API/tool to be used. For instance, if the legal values for a required module parameter cannot be documented, that's a sign that the module would be rejected. - -* Modules should typically encompass much of the logic for interacting with a resource. A lightweight wrapper around an API that does not contain much logic would likely cause users to offload too much logic into a playbook, and for this reason the module would be rejected. Instead try creating multiple modules for interacting with smaller individual pieces of the API. - -If your use case isn't covered by an existing module, an action plugin, or a role, and you don't need to create multiple modules, then you're ready to start developing a new module. Choose from the topics below for next steps: - -* I want to :ref:`get started on a new module `. -* I want to review :ref:`tips and conventions for developing good modules `. -* I want to :ref:`write a Windows module `. -* I want :ref:`an overview of Ansible's architecture `. -* I want to :ref:`document my module `. -* I want to :ref:`contribute my module to an existing Ansible collection `. -* I want to :ref:`add unit and integration tests to my module `. -* I want to :ref:`add Python 3 support to my module `. -* I want to :ref:`write multiple modules `. - -.. seealso:: - - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - `Mailing List `_ - Development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_modules_best_practices.rst b/docs/docsite/rst/dev_guide/developing_modules_best_practices.rst deleted file mode 100644 index 20861ab58eb..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules_best_practices.rst +++ /dev/null @@ -1,176 +0,0 @@ -.. _developing_modules_best_practices: -.. _module_dev_conventions: - -******************************* -Conventions, tips, and pitfalls -******************************* - -.. contents:: Topics - :local: - -As you design and develop modules, follow these basic conventions and tips for clean, usable code: - -Scoping your module(s) -====================== - -Especially if you want to contribute your module(s) to an existing Ansible Collection, make sure each module includes enough logic and functionality, but not too much. If these guidelines seem confusing, consider :ref:`whether you really need to write a module ` at all. - -* Each module should have a concise and well-defined functionality. Basically, follow the UNIX philosophy of doing one thing well. -* Do not add ``get``, ``list`` or ``info`` state options to an existing module - create a new ``_info`` or ``_facts`` module. -* Modules should not require that a user know all the underlying options of an API/tool to be used. For instance, if the legal values for a required module option cannot be documented, the module does not belong in Ansible Core. -* Modules should encompass much of the logic for interacting with a resource. A lightweight wrapper around a complex API forces users to offload too much logic into their playbooks. If you want to connect Ansible to a complex API, :ref:`create multiple modules ` that interact with smaller individual pieces of the API. -* Avoid creating a module that does the work of other modules; this leads to code duplication and divergence, and makes things less uniform, unpredictable and harder to maintain. Modules should be the building blocks. If you are asking 'how can I have a module execute other modules' ... you want to write a role. - -Designing module interfaces -=========================== - -* If your module is addressing an object, the option for that object should be called ``name`` whenever possible, or accept ``name`` as an alias. -* Modules accepting boolean status should accept ``yes``, ``no``, ``true``, ``false``, or anything else a user may likely throw at them. The AnsibleModule common code supports this with ``type='bool'``. -* Avoid ``action``/``command``, they are imperative and not declarative, there are other ways to express the same thing. - -General guidelines & tips -========================= - -* Each module should be self-contained in one file, so it can be auto-transferred by ``ansible-core``. -* Module name MUST use underscores instead of hyphens or spaces as a word separator. Using hyphens and spaces will prevent ``ansible-core`` from importing your module. -* Always use the ``hacking/test-module.py`` script when developing modules - it will warn you about common pitfalls. -* If you have a local module that returns information specific to your installations, a good name for this module is ``site_info``. -* Eliminate or minimize dependencies. If your module has dependencies, document them at the top of the module file and raise JSON error messages when dependency import fails. -* Don't write to files directly; use a temporary file and then use the ``atomic_move`` function from ``ansible.module_utils.basic`` to move the updated temporary file into place. This prevents data corruption and ensures that the correct context for the file is kept. -* Avoid creating caches. Ansible is designed without a central server or authority, so you cannot guarantee it will not run with different permissions, options or locations. If you need a central authority, have it on top of Ansible (for example, using bastion/cm/ci server, AWX, or the Red Hat Ansible Automation Platform); do not try to build it into modules. -* If you package your module(s) in an RPM, install the modules on the control machine in ``/usr/share/ansible``. Packaging modules in RPMs is optional. - -Functions and Methods -===================== - -* Each function should be concise and should describe a meaningful amount of work. -* "Don't repeat yourself" is generally a good philosophy. -* Function names should use underscores: ``my_function_name``. -* The name of each function should describe what the function does. -* Each function should have a docstring. -* If your code is too nested, that's usually a sign the loop body could benefit from being a function. Parts of our existing code are not the best examples of this at times. - -Python tips -=========== - -* Include a ``main`` function that wraps the normal execution. -* Call your ``main`` function from a conditional so you can import it into unit tests - for example: - -.. code-block:: python - - if __name__ == '__main__': - main() - -.. _shared_code: - -Importing and using shared code -=============================== - -* Use shared code whenever possible - don't reinvent the wheel. Ansible offers the ``AnsibleModule`` common Python code, plus :ref:`utilities ` for many common use cases and patterns. You can also create documentation fragments for docs that apply to multiple modules. -* Import ``ansible.module_utils`` code in the same place as you import other libraries. -* Do NOT use wildcards (*) for importing other python modules; instead, list the function(s) you are importing (for example, ``from some.other_python_module.basic import otherFunction``). -* Import custom packages in ``try``/``except``, capture any import errors, and handle them with ``fail_json()`` in ``main()``. For example: - -.. code-block:: python - - import traceback - - from ansible.module_utils.basic import missing_required_lib - - LIB_IMP_ERR = None - try: - import foo - HAS_LIB = True - except: - HAS_LIB = False - LIB_IMP_ERR = traceback.format_exc() - - -Then in ``main()``, just after the argspec, do - -.. code-block:: python - - if not HAS_LIB: - module.fail_json(msg=missing_required_lib("foo"), - exception=LIB_IMP_ERR) - - -And document the dependency in the ``requirements`` section of your module's :ref:`documentation_block`. - -.. _module_failures: - -Handling module failures -======================== - -When your module fails, help users understand what went wrong. If you are using the ``AnsibleModule`` common Python code, the ``failed`` element will be included for you automatically when you call ``fail_json``. For polite module failure behavior: - -* Include a key of ``failed`` along with a string explanation in ``msg``. If you don't do this, Ansible will use standard return codes: 0=success and non-zero=failure. -* Don't raise a traceback (stacktrace). Ansible can deal with stacktraces and automatically converts anything unparsable into a failed result, but raising a stacktrace on module failure is not user-friendly. -* Do not use ``sys.exit()``. Use ``fail_json()`` from the module object. - -Handling exceptions (bugs) gracefully -===================================== - -* Validate upfront--fail fast and return useful and clear error messages. -* Use defensive programming--use a simple design for your module, handle errors gracefully, and avoid direct stacktraces. -* Fail predictably--if we must fail, do it in a way that is the most expected. Either mimic the underlying tool or the general way the system works. -* Give out a useful message on what you were doing and add exception messages to that. -* Avoid catchall exceptions, they are not very useful unless the underlying API gives very good error messages pertaining the attempted action. - -.. _module_output: - -Creating correct and informative module output -============================================== - -Modules must output valid JSON only. Follow these guidelines for creating correct, useful module output: - -* Module return data must be encoded as strict UTF-8. Modules that cannot return UTF-8 encoded data should return the data encoded by something such as base64. Optionally modules can make the determination if they can encode as UTF-8 and utilize ``errors='replace'`` to replace non UTF-8 characters making the return values lossy. -* Make your top-level return type a hash (dictionary). -* Nest complex return values within the top-level hash. -* Incorporate any lists or simple scalar values within the top-level return hash. -* Do not send module output to standard error, because the system will merge standard out with standard error and prevent the JSON from parsing. -* Capture standard error and return it as a variable in the JSON on standard out. This is how the command module is implemented. -* Never do ``print("some status message")`` in a module, because it will not produce valid JSON output. -* Always return useful data, even when there is no change. -* Be consistent about returns (some modules are too random), unless it is detrimental to the state/action. -* Make returns reusable--most of the time you don't want to read it, but you do want to process it and re-purpose it. -* Return diff if in diff mode. This is not required for all modules, as it won't make sense for certain ones, but please include it when applicable. -* Enable your return values to be serialized as JSON with Python's standard `JSON encoder and decoder `_ library. Basic python types (strings, int, dicts, lists, and so on) are serializable. -* Do not return an object using exit_json(). Instead, convert the fields you need from the object into the fields of a dictionary and return the dictionary. -* Results from many hosts will be aggregated at once, so your module should return only relevant output. Returning the entire contents of a log file is generally bad form. - -If a module returns stderr or otherwise fails to produce valid JSON, the actual output will still be shown in Ansible, but the command will not succeed. - -.. _module_conventions: - -Following Ansible conventions -============================= - -Ansible conventions offer a predictable user interface across all modules, playbooks, and roles. To follow Ansible conventions in your module development: - -* Use consistent names across modules (yes, we have many legacy deviations - don't make the problem worse!). -* Use consistent options (arguments) within your module(s). -* Do not use 'message' or 'syslog_facility' as an option name, because this is used internally by Ansible. -* Normalize options with other modules - if Ansible and the API your module connects to use different names for the same option, add aliases to your options so the user can choose which names to use in tasks and playbooks. -* Return facts from ``*_facts`` modules in the ``ansible_facts`` field of the :ref:`result dictionary` so other modules can access them. -* Implement ``check_mode`` in all ``*_info`` and ``*_facts`` modules. Playbooks which conditionalize based on fact information will only conditionalize correctly in ``check_mode`` if the facts are returned in ``check_mode``. Usually you can add ``supports_check_mode=True`` when instantiating ``AnsibleModule``. -* Use module-specific environment variables. For example, if you use the helpers in ``module_utils.api`` for basic authentication with ``module_utils.urls.fetch_url()`` and you fall back on environment variables for default values, use a module-specific environment variable like :code:`API__USERNAME` to avoid conflicts between modules. -* Keep module options simple and focused - if you're loading a lot of choices/states on an existing option, consider adding a new, simple option instead. -* Keep options small when possible. Passing a large data structure to an option might save us a few tasks, but it adds a complex requirement that we cannot easily validate before passing on to the module. -* If you want to pass complex data to an option, write an expert module that allows this, along with several smaller modules that provide a more 'atomic' operation against the underlying APIs and services. Complex operations require complex data. Let the user choose whether to reflect that complexity in tasks and plays or in vars files. -* Implement declarative operations (not CRUD) so the user can ignore existing state and focus on final state. For example, use ``started/stopped``, ``present/absent``. -* Strive for a consistent final state (aka idempotency). If running your module twice in a row against the same system would result in two different states, see if you can redesign or rewrite to achieve consistent final state. If you can't, document the behavior and the reasons for it. -* Provide consistent return values within the standard Ansible return structure, even if NA/None are used for keys normally returned under other options. - - -Module Security -=============== - -* Avoid passing user input from the shell. -* Always check return codes. -* You must always use ``module.run_command``, not ``subprocess`` or ``Popen`` or ``os.system``. -* Avoid using the shell unless absolutely necessary. -* If you must use the shell, you must pass ``use_unsafe_shell=True`` to ``module.run_command``. -* If any variables in your module can come from user input with ``use_unsafe_shell=True``, you must wrap them with ``pipes.quote(x)``. -* When fetching URLs, use ``fetch_url`` or ``open_url`` from ``ansible.module_utils.urls``. Do not use ``urllib2``, which does not natively verify TLS certificates and so is insecure for https. -* Sensitive values marked with ``no_log=True`` will automatically have that value stripped from module return values. If your module could return these sensitive values as part of a dictionary key name, you should call the ``ansible.module_utils.basic.sanitize_keys()`` function to strip the values from the keys. See the ``uri`` module for an example. diff --git a/docs/docsite/rst/dev_guide/developing_modules_checklist.rst b/docs/docsite/rst/dev_guide/developing_modules_checklist.rst deleted file mode 100644 index 292bb9061f3..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules_checklist.rst +++ /dev/null @@ -1,45 +0,0 @@ -.. _developing_modules_checklist: -.. _module_contribution: - -********************************************************** -Contributing your module to an existing Ansible collection -********************************************************** - -If you want to contribute a module to an existing collection, you must meet the community's objective and subjective requirements. Please read the details below, and also review our :ref:`tips for module development `. - -Modules accepted into certain collections are included in every Ansible release on PyPI. However, contributing to one of these collections is not the only way to distribute a module - you can :ref:`create your own collection `, embed modules in roles on Galaxy or simply share copies of your module code for :ref:`local use `. - -Contributing modules: objective requirements -=============================================== - -To contribute a module to most Ansible collections, you must: - -* write your module in either Python or Powershell for Windows -* use the ``AnsibleModule`` common code -* support Python 2.6 and Python 3.5 - if your module cannot support Python 2.6, explain the required minimum Python version and rationale in the requirements section in ``DOCUMENTATION`` -* use proper :ref:`Python 3 syntax ` -* follow `PEP 8 `_ Python style conventions - see :ref:`testing_pep8` for more information -* license your module under the GPL license (GPLv3 or later) -* understand the :ref:`license agreement `, which applies to all contributions -* conform to Ansible's :ref:`formatting and documentation ` standards -* include comprehensive :ref:`tests ` for your module -* minimize module dependencies -* support :ref:`check_mode ` if possible -* ensure your code is readable -* if a module is named ``_facts``, it should be because its main purpose is returning ``ansible_facts``. Do not name modules that do not do this with ``_facts``. Only use ``ansible_facts`` for information that is specific to the host machine, for example network interfaces and their configuration, which operating system and which programs are installed. -* Modules that query/return general information (and not ``ansible_facts``) should be named ``_info``. General information is non-host specific information, for example information on online/cloud services (you can access different accounts for the same online service from the same host), or information on VMs and containers accessible from the machine. - -Additional requirements may apply for certain collections. Review the individual collection repositories for more information. - -Please make sure your module meets these requirements before you submit your PR/proposal. If you have questions, reach out by using the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) or the `Ansible development mailing list `_. - -Contributing to Ansible: subjective requirements -================================================ - -If your module meets these objective requirements, collection maintainers will review your code to see if they think it's clear, concise, secure, and maintainable. They will consider whether your module provides a good user experience, helpful error messages, reasonable defaults, and more. This process is subjective, with no exact standards for acceptance. For the best chance of getting your module accepted, follow our :ref:`tips for module development `. - -Other checklists -================ - -* :ref:`Tips for module development `. -* :ref:`Windows development checklist `. diff --git a/docs/docsite/rst/dev_guide/developing_modules_documenting.rst b/docs/docsite/rst/dev_guide/developing_modules_documenting.rst deleted file mode 100644 index 20f4d881917..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules_documenting.rst +++ /dev/null @@ -1,504 +0,0 @@ -.. _developing_modules_documenting: -.. _module_documenting: - -******************************* -Module format and documentation -******************************* - -If you want to contribute your module to most Ansible collections, you must write your module in Python and follow the standard format described below. (Unless you're writing a Windows module, in which case the :ref:`Windows guidelines ` apply.) In addition to following this format, you should review our :ref:`submission checklist `, :ref:`programming tips `, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility `, as well as information about :ref:`testing ` before you open a pull request. - -Every Ansible module written in Python must begin with seven standard sections in a particular order, followed by the code. The sections in order are: - -.. contents:: - :depth: 1 - :local: - -.. note:: Why don't the imports go first? - - Keen Python programmers may notice that contrary to PEP 8's advice we don't put ``imports`` at the top of the file. This is because the ``DOCUMENTATION`` through ``RETURN`` sections are not used by the module code itself; they are essentially extra docstrings for the file. The imports are placed after these special variables for the same reason as PEP 8 puts the imports after the introductory comments and docstrings. This keeps the active parts of the code together and the pieces which are purely informational apart. The decision to exclude E402 is based on readability (which is what PEP 8 is about). Documentation strings in a module are much more similar to module level docstrings, than code, and are never utilized by the module itself. Placing the imports below this documentation and closer to the code, consolidates and groups all related code in a congruent manner to improve readability, debugging and understanding. - -.. warning:: **Copy old modules with care!** - - Some older Ansible modules have ``imports`` at the bottom of the file, ``Copyright`` notices with the full GPL prefix, and/or ``DOCUMENTATION`` fields in the wrong order. These are legacy files that need updating - do not copy them into new modules. Over time we are updating and correcting older modules. Please follow the guidelines on this page! - -.. note:: For non-Python modules you still create a ``.py`` file for documentation purposes. Starting at ansible-core 2.14 you can instead choose to create a ``.yml`` file that has the same data structure, but in pure YAML. - With YAML files, the examples below are easy to use by removing Python quoting and substituting ``=`` for ``:``, for example ``DOCUMENTATION = r''' ... '''` ` to ``DOCUMENTATION: ...`` and removing closing quotes. :ref:`adjacent_yaml_doc` - - -.. _shebang: - -Python shebang & UTF-8 coding -=============================== - -Begin your Ansible module with ``#!/usr/bin/python`` - this "shebang" allows ``ansible_python_interpreter`` to work. Follow the shebang immediately with ``# -*- coding: utf-8 -*-`` to clarify that the file is UTF-8 encoded. - -.. note:: Using ``#!/usr/bin/env``, makes ``env`` the interpreter and bypasses ``ansible__interpreter`` logic. -.. note:: If you develop the module using a different scripting language, adjust the interpreter accordingly (``#!/usr/bin/``) so ``ansible__interpreter`` can work for that specific language. -.. note:: Binary modules do not require a shebang or an interpreter. - -.. _copyright: - -Copyright and license -===================== - -After the shebang and UTF-8 coding, add a `copyright line `_ with the original copyright holder and a license declaration. The license declaration should be ONLY one line, not the full GPL prefix.: - -.. code-block:: python - - #!/usr/bin/python - # -*- coding: utf-8 -*- - - # Copyright: Contributors to the Ansible project - # GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -Additions to the module (for instance, rewrites) are not permitted to add additional copyright lines other than the default copyright statement if missing: - -.. code-block:: python - - # Copyright: Contributors to the Ansible project - -Any legal review will include the source control history, so an exhaustive copyright header is not necessary. -Please do not include a copyright year. If the existing copyright statement includes a year, do not edit the existing copyright year. Any existing copyright header should not be modified without permission from the copyright author. - -.. _ansible_metadata_block: - -ANSIBLE_METADATA block -====================== - -Since we moved to collections we have deprecated the METADATA functionality, it is no longer required for modules, but it will not break anything if present. - - -.. _documentation_block: - -DOCUMENTATION block -=================== - -After the shebang, the UTF-8 coding, the copyright line, and the license section comes the ``DOCUMENTATION`` block. Ansible's online module documentation is generated from the ``DOCUMENTATION`` blocks in each module's source code. The ``DOCUMENTATION`` block must be valid YAML. You may find it easier to start writing your ``DOCUMENTATION`` string in an :ref:`editor with YAML syntax highlighting ` before you include it in your Python file. You can start by copying our `example documentation string `_ into your module file and modifying it. If you run into syntax issues in your YAML, you can validate it on the `YAML Lint `_ website. - -Module documentation should briefly and accurately define what each module and option does, and how it works with others in the underlying system. Documentation should be written for broad audience--readable both by experts and non-experts. - * Descriptions should always start with a capital letter and end with a full stop. Consistency always helps. - * Verify that arguments in doc and module spec dict are identical. - * For password / secret arguments ``no_log=True`` should be set. - * For arguments that seem to contain sensitive information but **do not** contain secrets, such as "password_length", set ``no_log=False`` to disable the warning message. - * If an option is only sometimes required, describe the conditions. For example, "Required when I(state=present)." - * If your module allows ``check_mode``, reflect this fact in the documentation. - -To create clear, concise, consistent, and useful documentation, follow the :ref:`style guide `. - -Each documentation field is described below. Before committing your module documentation, please test it at the command line and as HTML: - -* As long as your module file is :ref:`available locally `, you can use ``ansible-doc -t module my_module_name`` to view your module documentation at the command line. Any parsing errors will be obvious - you can view details by adding ``-vvv`` to the command. -* You should also :ref:`test the HTML output ` of your module documentation. - - -Documentation fields --------------------- - -All fields in the ``DOCUMENTATION`` block are lower-case. All fields are required unless specified otherwise: - -:module: - - * The name of the module. - * Must be the same as the filename, without the ``.py`` extension. - -:short_description: - - * A short description which is displayed on the :ref:`list_of_collections` page and ``ansible-doc -l``. - * The ``short_description`` is displayed by ``ansible-doc -l`` without any category grouping, - so it needs enough detail to explain the module's purpose without the context of the directory structure in which it lives. - * Unlike ``description:``, ``short_description`` should not have a trailing period/full stop. - -:description: - - * A detailed description (generally two or more sentences). - * Must be written in full sentences, in other words, with capital letters and periods/full stops. - * Shouldn't mention the module name. - * Make use of multiple entries rather than using one long paragraph. - * Don't quote complete values unless it is required by YAML. - -:version_added: - - * The version of Ansible when the module was added. - * This is a string, and not a float, for example, ``version_added: '2.1'``. - * In collections, this must be the collection version the module was added to, not the Ansible version. For example, ``version_added: 1.0.0``. - -:author: - - * Name of the module author in the form ``First Last (@GitHubID)``. - * Use a multi-line list if there is more than one author. - * Don't use quotes as it should not be required by YAML. - -:deprecated: - - * Marks modules that will be removed in future releases. See also :ref:`module_lifecycle`. - -:options: - - * Options are often called `parameters` or `arguments`. Because the documentation field is called `options`, we will use that term. - * If the module has no options (for example, it's a ``_facts`` module), all you need is one line: ``options: {}``. - * If your module has options (in other words, accepts arguments), each option should be documented thoroughly. For each module option, include: - - :option-name: - - * Declarative operation (not CRUD), to focus on the final state, for example `online:`, rather than `is_online:`. - * The name of the option should be consistent with the rest of the module, as well as other modules in the same category. - * When in doubt, look for other modules to find option names that are used for the same purpose, we like to offer consistency to our users. - - :description: - - * Detailed explanation of what this option does. It should be written in full sentences. - * The first entry is a description of the option itself; subsequent entries detail its use, dependencies, or format of possible values. - * Should not list the possible values (that's what ``choices:`` is for, though it should explain what the values do if they aren't obvious). - * If an option is only sometimes required, describe the conditions. For example, "Required when I(state=present)." - * Mutually exclusive options must be documented as the final sentence on each of the options. - - :required: - - * Only needed if ``true``. - * If missing, we assume the option is not required. - - :default: - - * If ``required`` is false/missing, ``default`` may be specified (assumed 'null' if missing). - * Ensure that the default value in the docs matches the default value in the code. - * The default field must not be listed as part of the description, unless it requires additional information or conditions. - * If the option is a boolean value, you can use any of the boolean values recognized by Ansible - (such as ``true``/``false`` or ``yes``/``no``). Document booleans as ``true``/``false`` for consistency and compatibility with ansible-lint. - - :choices: - - * List of option values. - * Should be absent if empty. - - :type: - - * Specifies the data type that option accepts, must match the ``argspec``. - * If an argument is ``type='bool'``, this field should be set to ``type: bool`` and no ``choices`` should be specified. - * If an argument is ``type='list'``, ``elements`` should be specified. - - :elements: - - * Specifies the data type for list elements in case ``type='list'``. - - :aliases: - * List of optional name aliases. - * Generally not needed. - - :version_added: - - * Only needed if this option was extended after initial Ansible release, in other words, this is greater than the top level `version_added` field. - * This is a string, and not a float, for example, ``version_added: '2.3'``. - * In collections, this must be the collection version the option was added to, not the Ansible version. For example, ``version_added: 1.0.0``. - - :suboptions: - - * If this option takes a dict or list of dicts, you can define the structure here. - * See :ref:`ansible_collections.azure.azcollection.azure_rm_securitygroup_module`, :ref:`ansible_collections.azure.azcollection.azure_rm_azurefirewall_module`, and :ref:`ansible_collections.openstack.cloud.baremetal_node_action_module` for examples. - -:requirements: - - * List of requirements (if applicable). - * Include minimum versions. - -:seealso: - - * A list of references to other modules, documentation or Internet resources - * In Ansible 2.10 and later, references to modules must use the FQCN or ``ansible.builtin`` for modules in ``ansible-core``. - * Plugin references are supported since ansible-core 2.15. - * A reference can be one of the following formats: - - - .. code-block:: yaml+jinja - - seealso: - - # Reference by module name - - module: cisco.aci.aci_tenant - - # Reference by module name, including description - - module: cisco.aci.aci_tenant - description: ACI module to create tenants on a Cisco ACI fabric. - - # Reference by plugin name - - plugin: ansible.builtin.file - plugin_type: lookup - - # Reference by plugin name, including description - - plugin: ansible.builtin.file - plugin_type: lookup - description: You can use the ansible.builtin.file lookup to read files on the controller. - - # Reference by rST documentation anchor - - ref: aci_guide - description: Detailed information on how to manage your ACI infrastructure using Ansible. - - # Reference by rST documentation anchor (with custom title) - - ref: The official Ansible ACI guide - description: Detailed information on how to manage your ACI infrastructure using Ansible. - - # Reference by Internet resource - - name: APIC Management Information Model reference - description: Complete reference of the APIC object model. - link: https://developer.cisco.com/docs/apic-mim-ref/ - - - * If you use ``ref:`` to link to an anchor that is not associated with a title, you must add a title to the ref for the link to work correctly. - * You can link to non-module plugins with ``ref:`` using the rST anchor, but plugin and module anchors are never associated with a title, so you must supply a title when you link to them. For example ``ref: namespace.collection.plugin_name lookup plugin ``. - - -:notes: - - * Details of any important information that doesn't fit in one of the above sections. - * For example, whether ``check_mode`` is or is not supported. - -.. _module_documents_linking: - -Linking within module documentation ------------------------------------ - -You can link from your module documentation to other module docs, other resources on docs.ansible.com, and resources elsewhere on the internet with the help of some pre-defined macros. The correct formats for these macros are: - -* ``L()`` for links with a heading. For example: ``See L(Ansible Automation Platform,https://www.ansible.com/products/automation-platform).`` As of Ansible 2.10, do not use ``L()`` for relative links between Ansible documentation and collection documentation. -* ``U()`` for URLs. For example: ``See U(https://www.ansible.com/products/automation-platform) for an overview.`` -* ``R()`` for cross-references with a heading (added in Ansible 2.10). For example: ``See R(Cisco IOS Platform Guide,ios_platform_options)``. Use the RST anchor for the cross-reference. See :ref:`adding_anchors_rst` for details. -* ``M()`` for module names. For example: ``See also M(ansible.builtin.yum) or M(community.general.apt_rpm)``. A FQCN **must** be used, short names will create broken links; use ``ansible.builtin`` for modules in ansible-core. -* ``P()`` for plugin names. For example: ``See also P(ansible.builtin.file#lookup) or P(community.general.json_query#filter)``. This is supported since ansible-core 2.15. FQCNs must be used; use ``ansible.builtin`` for plugins in ansible-core. - -.. note:: - - For links between modules and documentation within a collection, you can use any of the options above. For links outside of your collection, use ``R()`` if available. Otherwise, use ``U()`` or ``L()`` with full URLs (not relative links). For modules, use ``M()`` with the FQCN or ``ansible.builtin`` as shown in the example. If you are creating your own documentation site, you will need to use the `intersphinx extension `_ to convert ``R()`` and ``M()`` to the correct links. - -.. note:: - To refer to a group of modules in a collection, use ``R()``. When a collection is not the right granularity, use ``C(..)``: - - - ``Refer to the R(kubernetes.core collection, plugins_in_kubernetes.core) for information on managing kubernetes clusters.`` - - ``The C(win_*) modules (spread across several collections) allow you to manage various aspects of windows hosts.`` - -.. note:: - - Because it stands out better, use ``seealso`` for general references over the use of notes or adding links to the description. - -.. _semantic_markup: - -Semantic markup within module documentation -------------------------------------------- - -You can use semantic markup to highlight option names, option values, and environment variables. The markup processor formats these highlighted terms in a uniform way. With semantic markup, we can modify how the output looks without changing underlying code. - -The correct formats for semantic markup are as follows: - -* ``O()`` for option names, whether mentioned alone or with values. For example: ``Required if O(state=present).`` and ``Use with O(force) to require secure access.`` -* ``V()`` for option values when mentioned alone. For example: ``Possible values include V(monospace) and V(pretty).`` -* ``RV()`` for return value names, whether mentioned alone or with values. For example: ``The module returns RV(changed=true) in case of changes.`` and ``Use the RV(stdout) return value for standard output.`` -* ``E()`` for environment variables. For example: ``If not set, the environment variable E(ACME_PASSWORD) will be used.`` - -The parameters for these formatting functions can use escaping with backslashes: ``V(foo(bar="a\\b"\), baz)`` results in the formatted value ``foo(bar="a\b"), baz)``. - -Rules for using ``O()`` and ``RV()`` are very strict. You must follow syntax rules so that documentation renderers can create hyperlinks for the options and return values, respectively. - -The allowed syntaxes are as follows: -- To reference an option for the current plugin/module, or the entrypoint of the current role (inside role entrypoint documentation), use ``O(option)`` and ``O(option=name)``. -- To reference an option for another entrypoint ``entrypoint`` from inside role documentation, use ``O(entrypoint:option)`` and ``O(entrypoint:option=name)``. The entrypoint information can be ignored by the documentation renderer, turned into a link to that entrypoint, or even directly to the option of that entrypoint. -- To reference an option for *another* plugin/module ``plugin.fqcn.name`` of type ``type``, use ``O(plugin.fqcn.name#type:option)`` and ``O(plugin.fqcn.name#type:option=name)``. For modules, use ``type=module``. The FQCN and plugin type can be ignored by the documentation renderer, turned into a link to that plugin, or even directly to the option of that plugin. -- To reference an option for entrypoint ``entrypoint`` of *another* role ``role.fqcn.name``, use ``O(role.fqcn.name#role:entrypoint:option)`` and ``O(role.fqcn.name#role:entrypoint:option=name)``. The FQCN and entrypoint information can be ignored by the documentation renderer, turned into a link to that entrypoint, or even directly to the option of that entrypoint. -- To reference options that do not exist (for example, options that were removed in an earlier version), use ``O(ignore:option)`` and ``O(ignore:option=name)``. The ``ignore:`` part will not be shown to the user by documentation rendering. - -Option names can refer to suboptions by listing the path to the option separated by dots. For example, if you have an option ``foo`` with suboption ``bar``, then you must use ``O(foo.bar)`` to reference that suboption. You can add array indications like ``O(foo[].bar)`` or even ``O(foo[-1].bar)`` to indicate specific list elements. Everything between ``[`` and ``]`` pairs will be ignored to determine the real name of the option. For example, ``O(foo[foo | length - 1].bar[])`` results in the same link as ``O(foo.bar)``, but the text ``foo[foo | length - 1].bar[]`` displays instead of ``foo.bar``. - -The same syntaxes can be used for ``RV()``, except that these will refer to return value names instead of option names; for example ``RV(ansible.builtin.service_facts#module:ansible_facts.services)`` refers to the :ref:`ansible_facts.services fact ` returned by the :ref:`ansible.builtin.service_facts module `. - -Format macros within module documentation ------------------------------------------ - -While it is possible to use standard Ansible formatting macros to control the look of other terms in module documentation, you should do so sparingly. - -Possible macros include the following: - -* ``C()`` for ``monospace`` (code) text. For example: ``This module functions like the unix command C(foo).`` -* ``B()`` for bold text. -* ``I()`` for italic text. -* ``HORIZONTALLINE`` for a horizontal rule (the ``
    `` html tag) to separate long descriptions. - -Note that ``C()``, ``B()``, and ``I()`` do **not allow escaping**, and thus cannot contain the value ``)`` as it always ends the formatting sequence. If you need to use ``)`` inside ``C()``, we recommend to use ``V()`` instead; see the above section on semantic markup. - -.. _module_docs_fragments: - -Documentation fragments ------------------------ - -If you are writing multiple related modules, they may share common documentation, such as authentication details, file mode settings, ``notes:`` or ``seealso:`` entries. Rather than duplicate that information in each module's ``DOCUMENTATION`` block, you can save it once as a doc_fragment plugin and use it in each module's documentation. In Ansible, shared documentation fragments are contained in a ``ModuleDocFragment`` class in `lib/ansible/plugins/doc_fragments/ `_ or the equivalent directory in a collection. To include a documentation fragment, add ``extends_documentation_fragment: FRAGMENT_NAME`` in your module documentation. Use the fully qualified collection name for the FRAGMENT_NAME (for example, ``kubernetes.core.k8s_auth_options``). - -Modules should only use items from a doc fragment if the module will implement all of the interface documented there in a manner that behaves the same as the existing modules which import that fragment. The goal is that items imported from the doc fragment will behave identically when used in another module that imports the doc fragment. - -By default, only the ``DOCUMENTATION`` property from a doc fragment is inserted into the module documentation. It is possible to define additional properties in the doc fragment in order to import only certain parts of a doc fragment or mix and match as appropriate. If a property is defined in both the doc fragment and the module, the module value overrides the doc fragment. - -Here is an example doc fragment named ``example_fragment.py``: - -.. code-block:: python - - class ModuleDocFragment(object): - # Standard documentation - DOCUMENTATION = r''' - options: - # options here - ''' - - # Additional section - OTHER = r''' - options: - # other options here - ''' - - -To insert the contents of ``OTHER`` in a module: - -.. code-block:: yaml+jinja - - extends_documentation_fragment: example_fragment.other - -Or use both : - -.. code-block:: yaml+jinja - - extends_documentation_fragment: - - example_fragment - - example_fragment.other - -.. _note: - * Prior to Ansible 2.8, documentation fragments were kept in ``lib/ansible/utils/module_docs_fragments``. - -.. versionadded:: 2.8 - -Since Ansible 2.8, you can have user-supplied doc_fragments by using a ``doc_fragments`` directory adjacent to play or role, just like any other plugin. - -For example, all AWS modules should include: - -.. code-block:: yaml+jinja - - extends_documentation_fragment: - - aws - - ec2 - -:ref:`docfragments_collections` describes how to incorporate documentation fragments in a collection. - -.. _examples_block: - -EXAMPLES block -============== - -After the shebang, the UTF-8 coding, the copyright line, the license section, and the ``DOCUMENTATION`` block comes the ``EXAMPLES`` block. Here you show users how your module works with real-world examples in multi-line plain-text YAML format. The best examples are ready for the user to copy and paste into a playbook. Review and update your examples with every change to your module. - -Per playbook best practices, each example should include a ``name:`` line: - -.. code-block:: text - - EXAMPLES = r''' - - name: Ensure foo is installed - namespace.collection.modulename: - name: foo - state: present - ''' - -The ``name:`` line should be capitalized and not include a trailing dot. - -Use a fully qualified collection name (FQCN) as a part of the module's name like in the example above. For modules in ``ansible-core``, use the ``ansible.builtin.`` identifier, for example ``ansible.builtin.debug``. - -If your examples use boolean options, use yes/no values. Since the documentation generates boolean values as yes/no, having the examples use these values as well makes the module documentation more consistent. - -If your module returns facts that are often needed, an example of how to use them can be helpful. - -.. _return_block: - -RETURN block -============ - -After the shebang, the UTF-8 coding, the copyright line, the license section, ``DOCUMENTATION`` and ``EXAMPLES`` blocks comes the ``RETURN`` block. This section documents the information the module returns for use by other modules. - -If your module doesn't return anything (apart from the standard returns), this section of your module should read: ``RETURN = r''' # '''`` -Otherwise, for each value returned, provide the following fields. All fields are required unless specified otherwise. - -:return name: - Name of the returned field. - - :description: - Detailed description of what this value represents. Capitalized and with trailing dot. - :returned: - When this value is returned, such as ``always``, ``changed`` or ``success``. This is a string and can contain any human-readable content. - :type: - Data type. - :elements: - If ``type='list'``, specifies the data type of the list's elements. - :sample: - One or more examples. - :version_added: - Only needed if this return was extended after initial Ansible release, in other words, this is greater than the top level `version_added` field. - This is a string, and not a float, for example, ``version_added: '2.3'``. - :contains: - Optional. To describe nested return values, set ``type: dict``, or ``type: list``/``elements: dict``, or if you really have to, ``type: complex``, and repeat the elements above for each sub-field. - -Here are two example ``RETURN`` sections, one with three simple fields and one with a complex nested field: - -.. code-block:: text - - RETURN = r''' - dest: - description: Destination file/path. - returned: success - type: str - sample: /path/to/file.txt - src: - description: Source file used for the copy on the target machine. - returned: changed - type: str - sample: /home/httpd/.ansible/tmp/ansible-tmp-1423796390.97-147729857856000/source - md5sum: - description: MD5 checksum of the file after running copy. - returned: when supported - type: str - sample: 2a5aeecc61dc98c4d780b14b330e3282 - ''' - - RETURN = r''' - packages: - description: Information about package requirements. - returned: success - type: dict - contains: - missing: - description: Packages that are missing from the system. - returned: success - type: list - elements: str - sample: - - libmysqlclient-dev - - libxml2-dev - badversion: - description: Packages that are installed but at bad versions. - returned: success - type: list - elements: dict - sample: - - package: libxml2-dev - version: 2.9.4+dfsg1-2 - constraint: ">= 3.0" - ''' - -.. _python_imports: - -Python imports -============== - -After the shebang, the UTF-8 coding, the copyright line, the license, and the sections for ``DOCUMENTATION``, ``EXAMPLES``, and ``RETURN``, you can finally add the python imports. All modules must use Python imports in the form: - -.. code-block:: python - - from module_utils.basic import AnsibleModule - -The use of "wildcard" imports such as ``from module_utils.basic import *`` is no longer allowed. - -.. _dev_testing_module_documentation: - -Testing module documentation -============================ - -To test Ansible documentation locally please :ref:`follow instruction`. To test documentation in collections, please see :ref:`build_collection_docsite`. diff --git a/docs/docsite/rst/dev_guide/developing_modules_general.rst b/docs/docsite/rst/dev_guide/developing_modules_general.rst deleted file mode 100644 index abffcf191c8..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules_general.rst +++ /dev/null @@ -1,186 +0,0 @@ -.. _developing_modules_general: -.. _module_dev_tutorial_sample: - -****************** -Developing modules -****************** - -A module is a reusable, standalone script that Ansible runs on your behalf, either locally or remotely. Modules interact with your local machine, an API, or a remote system to perform specific tasks like changing a database password or spinning up a cloud instance. Each module can be used by the Ansible API, or by the :command:`ansible` or :command:`ansible-playbook` programs. A module provides a defined interface, accepts arguments, and returns information to Ansible by printing a JSON string to stdout before exiting. - -If you need functionality that is not available in any of the thousands of Ansible modules found in collections, you can easily write your own custom module. When you write a module for local use, you can choose any programming language and follow your own rules. Use this topic to learn how to create an Ansible module in Python. After you create a module, you must add it locally to the appropriate directory so that Ansible can find and execute it. For details about adding a module locally, see :ref:`developing_locally`. - -If you are developing a module in a :ref:`collection `, see those documents instead. - -.. contents:: - :local: - -.. _environment_setup: - -Preparing an environment for developing Ansible modules -======================================================= - -You just need ``ansible-core`` installed to test the module. Modules can be written in any language, -but most of the following guide is assuming you are using Python. -Modules for inclusion in Ansible itself must be Python or Powershell. - -One advantage of using Python or Powershell for your custom modules is being able to use the ``module_utils`` common code that does a lot of the -heavy lifting for argument processing, logging and response writing, among other things. - -Creating a module -================= - -It is highly recommended that you use a ``venv`` or ``virtualenv`` for Python development. - -To create a module: - -1. Create a ``library`` directory in your workspace, your test play should live in the same directory. -2. Create your new module file: ``$ touch library/my_test.py``. Or just open/create it with your editor of choice. -3. Paste the content below into your new module file. It includes the :ref:`required Ansible format and documentation `, a simple :ref:`argument spec for declaring the module options `, and some example code. -4. Modify and extend the code to do what you want your new module to do. See the :ref:`programming tips ` and :ref:`Python 3 compatibility ` pages for pointers on writing clean and concise module code. - -.. literalinclude:: ../../../../examples/scripts/my_test.py - :language: python - -Creating an info or a facts module -================================== - -Ansible gathers information about the target machines using facts modules, and gathers information on other objects or files using info modules. -If you find yourself trying to add ``state: info`` or ``state: list`` to an existing module, that is often a sign that a new dedicated ``_facts`` or ``_info`` module is needed. - -In Ansible 2.8 and onwards, we have two type of information modules, they are ``*_info`` and ``*_facts``. - -If a module is named ``_facts``, it should be because its main purpose is returning ``ansible_facts``. Do not name modules that do not do this with ``_facts``. -Only use ``ansible_facts`` for information that is specific to the host machine, for example network interfaces and their configuration, which operating system and which programs are installed. - -Modules that query/return general information (and not ``ansible_facts``) should be named ``_info``. -General information is non-host specific information, for example information on online/cloud services (you can access different accounts for the same online service from the same host), or information on VMs and containers accessible from the machine, or information on individual files or programs. - -Info and facts modules, are just like any other Ansible Module, with a few minor requirements: - -1. They MUST be named ``_info`` or ``_facts``, where is singular. -2. Info ``*_info`` modules MUST return in the form of the :ref:`result dictionary` so other modules can access them. -3. Fact ``*_facts`` modules MUST return in the ``ansible_facts`` field of the :ref:`result dictionary` so other modules can access them. -4. They MUST support :ref:`check_mode `. -5. They MUST NOT make any changes to the system. -6. They MUST document the :ref:`return fields` and :ref:`examples`. - -The rest is just like creating a normal module. - -Verifying your module code -========================== - -After you modify the sample code above to do what you want, you can try out your module. -Our :ref:`debugging tips ` will help if you run into bugs as you verify your module code. - - -Verifying your module code locally ----------------------------------- - -The simplest way is to use ``ansible`` adhoc command: - -.. code:: shell - - ANSIBLE_LIBRARY=./library ansible -m my_test -a 'name=hello new=true' remotehost - -If your module does not need to target a remote host, you can quickly and easily exercise your code locally like this: - -.. code:: shell - - ANSIBLE_LIBRARY=./library ansible -m my_test -a 'name=hello new=true' localhost - -- If for any reason (pdb, using print(), faster iteration, etc) you want to avoid going through Ansible, - another way is to create an arguments file, a basic JSON config file that passes parameters to your module so that you can run it. - Name the arguments file ``/tmp/args.json`` and add the following content: - -.. code:: json - - { - "ANSIBLE_MODULE_ARGS": { - "name": "hello", - "new": true - } - } - -- Then the module can be tested locally and directly. This skips the packing steps and uses module_utils files directly: - -.. code:: console - - ``$ python library/my_test.py /tmp/args.json`` - -It should return output like this: - -.. code:: json - - {"changed": true, "state": {"original_message": "hello", "new_message": "goodbye"}, "invocation": {"module_args": {"name": "hello", "new": true}}} - - - -Verifying your module code in a playbook ----------------------------------------- - -You can easily run a full test by including it in a playbook, as long as the ``library`` directory is in the same directory as the play: - -- Create a playbook in any directory: ``$ touch testmod.yml`` -- Add the following to the new playbook file: - -.. code-block:: yaml - - - name: test my new module - hosts: localhost - tasks: - - name: run the new module - my_test: - name: 'hello' - new: true - register: testout - - name: dump test output - debug: - msg: '{{ testout }}' - -- Run the playbook and analyze the output: ``$ ansible-playbook ./testmod.yml`` - -Testing your newly-created module -================================= - -The following two examples will get you started with testing your module code. Please review our :ref:`testing ` section for more detailed -information, including instructions for :ref:`testing module documentation `, adding :ref:`integration tests `, and more. - -.. note:: - If contributing to Ansible, every new module and plugin should have integration tests, even if the tests cannot be run on Ansible CI infrastructure. - In this case, the tests should be marked with the ``unsupported`` alias in `aliases file `_. - -Performing sanity tests ------------------------ - -You can run through Ansible's sanity checks in a container: - -``$ ansible-test sanity -v --docker --python 3.10 MODULE_NAME`` - -.. note:: - Note that this example requires Docker to be installed and running. If you'd rather not use a container for this, you can choose to use ``--venv`` instead of ``--docker``. - - -Contributing back to Ansible -============================ - -If you would like to contribute to ``ansible-core`` by adding a new feature or fixing a bug, `create a fork `_ of the ansible/ansible repository and develop against a new feature branch using the ``devel`` branch as a starting point. When you have a good working code change, you can submit a pull request to the Ansible repository by selecting your feature branch as a source and the Ansible devel branch as a target. - -If you want to contribute a module to an :ref:`Ansible collection `, review our :ref:`submission checklist `, :ref:`programming tips `, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility `, as well as information about :ref:`testing ` before you open a pull request. - -The :ref:`Community Guide ` covers how to open a pull request and what happens next. - - -Communication and development support -===================================== - -Join the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) for discussions surrounding Ansible development. - -For questions and discussions pertaining to using the Ansible product, join the ``#ansible`` channel. - -To find other topic-specific chat channels, look at :ref:`Community Guide, Communicating `. - -Credit -====== - -Thank you to Thomas Stringer (`@trstringer `_) for contributing source -material for this topic. diff --git a/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst b/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst deleted file mode 100644 index b166dabc620..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst +++ /dev/null @@ -1,744 +0,0 @@ -.. _developing_modules_general_windows: - -************************************** -Windows module development walkthrough -************************************** - -In this section, we will walk through developing, testing, and debugging an -Ansible Windows module. - -Because Windows modules are written in Powershell and need to be run on a -Windows host, this guide differs from the usual development walkthrough guide. - -What's covered in this section: - -.. contents:: - :local: - - -Windows environment setup -========================= - -Unlike Python module development which can be run on the host that runs -Ansible, Windows modules need to be written and tested for Windows hosts. -While evaluation editions of Windows can be downloaded from -Microsoft, these images are usually not ready to be used by Ansible without -further modification. The easiest way to set up a Windows host so that it is -ready to by used by Ansible is to set up a virtual machine using Vagrant. -Vagrant can be used to download existing OS images called *boxes* that are then -deployed to a hypervisor like VirtualBox. These boxes can either be created and -stored offline or they can be downloaded from a central repository called -Vagrant Cloud. - -This guide will use the Vagrant boxes created by the `packer-windoze `_ -repository which have also been uploaded to `Vagrant Cloud `_. -To find out more info on how these images are created, please go to the GitHub -repo and look at the ``README`` file. - -Before you can get started, the following programs must be installed (please consult the Vagrant and -VirtualBox documentation for installation instructions): - -- Vagrant -- VirtualBox - -Create a Windows server in a VM -=============================== - -To create a single Windows Server 2016 instance, run the following: - -.. code-block:: shell - - vagrant init jborean93/WindowsServer2016 - vagrant up - -This will download the Vagrant box from Vagrant Cloud and add it to the local -boxes on your host and then start up that instance in VirtualBox. When starting -for the first time, the Windows VM will run through the sysprep process and -then create a HTTP and HTTPS WinRM listener automatically. Vagrant will finish -its process once the listeners are online, after which the VM can be used by Ansible. - -Create an Ansible inventory -=========================== - -The following Ansible inventory file can be used to connect to the newly -created Windows VM: - -.. code-block:: ini - - [windows] - WindowsServer ansible_host=127.0.0.1 - - [windows:vars] - ansible_user=vagrant - ansible_password=vagrant - ansible_port=55986 - ansible_connection=winrm - ansible_winrm_transport=ntlm - ansible_winrm_server_cert_validation=ignore - -.. note:: The port ``55986`` is automatically forwarded by Vagrant to the - Windows host that was created, if this conflicts with an existing local - port then Vagrant will automatically use another one at random and display - show that in the output. - -The OS that is created is based on the image set. The following -images can be used: - -- `jborean93/WindowsServer2012 `_ -- `jborean93/WindowsServer2012R2 `_ -- `jborean93/WindowsServer2016 `_ -- `jborean93/WindowsServer2019 `_ -- `jborean93/WindowsServer2022 `_ - -When the host is online, it can accessible by RDP on ``127.0.0.1:3389`` but the -port may differ depending if there was a conflict. To get rid of the host, run -``vagrant destroy --force`` and Vagrant will automatically remove the VM and -any other files associated with that VM. - -While this is useful when testing modules on a single Windows instance, these -host won't work without modification with domain based modules. The Vagrantfile -at `ansible-windows `_ -can be used to create a test domain environment to be used in Ansible. This -repo contains three files which are used by both Ansible and Vagrant to create -multiple Windows hosts in a domain environment. These files are: - -- ``Vagrantfile``: The Vagrant file that reads the inventory setup of ``inventory.yml`` and provisions the hosts that are required -- ``inventory.yml``: Contains the hosts that are required and other connection information such as IP addresses and forwarded ports -- ``main.yml``: Ansible playbook called by Vagrant to provision the domain controller and join the child hosts to the domain - -By default, these files will create the following environment: - -- A single domain controller running on Windows Server 2016 -- Five child hosts for each major Windows Server version joined to that domain -- A domain with the DNS name ``domain.local`` -- A local administrator account on each host with the username ``vagrant`` and password ``vagrant`` -- A domain admin account ``vagrant-domain@domain.local`` with the password ``VagrantPass1`` - -The domain name and accounts can be modified by changing the variables -``domain_*`` in the ``inventory.yml`` file if it is required. The inventory -file can also be modified to provision more or less servers by changing the -hosts that are defined under the ``domain_children`` key. The host variable -``ansible_host`` is the private IP that will be assigned to the VirtualBox host -only network adapter while ``vagrant_box`` is the box that will be used to -create the VM. - -Provisioning the environment -============================ - -To provision the environment as is, run the following: - -.. code-block:: shell - - git clone https://github.com/jborean93/ansible-windows.git - cd vagrant - vagrant up - -.. note:: Vagrant provisions each host sequentially so this can take some time - to complete. If any errors occur during the Ansible phase of setting up the - domain, run ``vagrant provision`` to rerun just that step. - -Unlike setting up a single Windows instance with Vagrant, these hosts can also -be accessed using the IP address directly as well as through the forwarded -ports. It is easier to access it over the host only network adapter as the -normal protocol ports are used, for example RDP is still over ``3389``. In cases where -the host cannot be resolved using the host only network IP, the following -protocols can be access over ``127.0.0.1`` using these forwarded ports: - -- ``RDP``: 295xx -- ``SSH``: 296xx -- ``WinRM HTTP``: 297xx -- ``WinRM HTTPS``: 298xx -- ``SMB``: 299xx - -Replace ``xx`` with the entry number in the inventory file where the domain -controller started with ``00`` and is incremented from there. For example, in -the default ``inventory.yml`` file, WinRM over HTTPS for ``SERVER2012R2`` is -forwarded over port ``29804`` as it's the fourth entry in ``domain_children``. - -Windows new module development -============================== - -When creating a new module there are a few things to keep in mind: - -- Module code is in Powershell (.ps1) files while the documentation is contained in Python (.py) files of the same name -- Avoid using ``Write-Host/Debug/Verbose/Error`` in the module and add what needs to be returned to the ``$module.Result`` variable -- To fail a module, call ``$module.FailJson("failure message here")``, an Exception or ErrorRecord can be set to the second argument for a more descriptive error message -- You can pass in the exception or ErrorRecord as a second argument to ``FailJson("failure", $_)`` to get a more detailed output -- Most new modules require check mode and integration tests before they are merged into the main Ansible codebase -- Avoid using try/catch statements over a large code block, rather use them for individual calls so the error message can be more descriptive -- Try and catch specific exceptions when using try/catch statements -- Avoid using PSCustomObjects unless necessary -- Look for common functions in ``./lib/ansible/module_utils/powershell/`` and use the code there instead of duplicating work. These can be imported by adding the line ``#Requires -Module *`` where * is the filename to import, and will be automatically included with the module code sent to the Windows target when run through Ansible -- As well as PowerShell module utils, C# module utils are stored in ``./lib/ansible/module_utils/csharp/`` and are automatically imported in a module execution if the line ``#AnsibleRequires -CSharpUtil *`` is present -- C# and PowerShell module utils achieve the same goal but C# allows a developer to implement low level tasks, such as calling the Win32 API, and can be faster in some cases -- Ensure the code runs under Powershell v5.1 and higher on Windows Server 2016 and higher; if higher minimum Powershell or OS versions are required, ensure the documentation reflects this clearly -- Ansible runs modules under strictmode version 2.0. Be sure to test with that enabled by putting ``Set-StrictMode -Version 2.0`` at the top of your dev script -- Favor native Powershell cmdlets over executable calls if possible -- Use the full cmdlet name instead of aliases, for example ``Remove-Item`` over ``rm`` -- Use named parameters with cmdlets, for example ``Remove-Item -Path C:\temp`` over ``Remove-Item C:\temp`` - -A very basic Powershell module `win_environment `_ incorporates best practices for Powershell modules. It demonstrates how to implement check-mode and diff-support, and also shows a warning to the user when a specific condition is met. - -A slightly more advanced module is `win_uri `_ which additionally shows how to use different parameter types (bool, str, int, list, dict, path) and a selection of choices for parameters, how to fail a module and how to handle exceptions. - -As part of the new ``AnsibleModule`` wrapper, the input parameters are defined and validated based on an argument -spec. The following options can be set at the root level of the argument spec: - -- ``mutually_exclusive``: A list of lists, where the inner list contains module options that cannot be set together -- ``no_log``: Stops the module from emitting any logs to the Windows Event log -- ``options``: A dictionary where the key is the module option and the value is the spec for that option -- ``required_by``: A dictionary where the option(s) specified by the value must be set if the option specified by the key is also set -- ``required_if``: A list of lists where the inner list contains 3 or 4 elements; - * The first element is the module option to check the value against - * The second element is the value of the option specified by the first element, if matched then the required if check is run - * The third element is a list of required module options when the above is matched - * An optional fourth element is a boolean that states whether all module options in the third elements are required (default: ``$false``) or only one (``$true``) -- ``required_one_of``: A list of lists, where the inner list contains module options where at least one must be set -- ``required_together``: A list of lists, where the inner list contains module options that must be set together -- ``supports_check_mode``: Whether the module supports check mode, by default this is ``$false`` - -The actual input options for a module are set within the ``options`` value as a dictionary. The keys of this dictionary -are the module option names while the values are the spec of that module option. Each spec can have the following -options set: - -- ``aliases``: A list of aliases for the module option -- ``choices``: A list of valid values for the module option, if ``type=list`` then each list value is validated against the choices and not the list itself -- ``default``: The default value for the module option if not set -- ``deprecated_aliases``: A list of hashtables that define aliases that are deprecated and the versions they will be removed in. Each entry must contain the keys ``name`` and ``collection_name`` with either ``version`` or ``date`` -- ``elements``: When ``type=list``, this sets the type of each list value, the values are the same as ``type`` -- ``no_log``: Will sanitise the input value before being returned in the ``module_invocation`` return value -- ``removed_in_version``: States when a deprecated module option is to be removed, a warning is displayed to the end user if set -- ``removed_at_date``: States the date (YYYY-MM-DD) when a deprecated module option will be removed, a warning is displayed to the end user if set -- ``removed_from_collection``: States from which collection the deprecated module option will be removed; must be specified if one of ``removed_in_version`` and ``removed_at_date`` is specified -- ``required``: Will fail when the module option is not set -- ``type``: The type of the module option, if not set then it defaults to ``str``. The valid types are; - * ``bool``: A boolean value - * ``dict``: A dictionary value, if the input is a JSON or key=value string then it is converted to dictionary - * ``float``: A float or `Single `_ value - * ``int``: An Int32 value - * ``json``: A string where the value is converted to a JSON string if the input is a dictionary - * ``list``: A list of values, ``elements=`` can convert the individual list value types if set. If ``elements=dict`` then ``options`` is defined, the values will be validated against the argument spec. When the input is a string then the string is split by ``,`` and any whitespace is trimmed - * ``path``: A string where values likes ``%TEMP%`` are expanded based on environment values. If the input value starts with ``\\?\`` then no expansion is run - * ``raw``: No conversions occur on the value passed in by Ansible - * ``sid``: Will convert Windows security identifier values or Windows account names to a `SecurityIdentifier `_ value - * ``str``: The value is converted to a string - -When ``type=dict``, or ``type=list`` and ``elements=dict``, the following keys can also be set for that module option: - -- ``apply_defaults``: The value is based on the ``options`` spec defaults for that key if ``True`` and null if ``False``. Only valid when the module option is not defined by the user and ``type=dict``. -- ``mutually_exclusive``: Same as the root level ``mutually_exclusive`` but validated against the values in the sub dict -- ``options``: Same as the root level ``options`` but contains the valid options for the sub option -- ``required_if``: Same as the root level ``required_if`` but validated against the values in the sub dict -- ``required_by``: Same as the root level ``required_by`` but validated against the values in the sub dict -- ``required_together``: Same as the root level ``required_together`` but validated against the values in the sub dict -- ``required_one_of``: Same as the root level ``required_one_of`` but validated against the values in the sub dict - -A module type can also be a delegate function that converts the value to whatever is required by the module option. For -example the following snippet shows how to create a custom type that creates a ``UInt64`` value: - -.. code-block:: powershell - - $spec = @{ - uint64_type = @{ type = [Func[[Object], [UInt64]]]{ [System.UInt64]::Parse($args[0]) } } - } - $uint64_type = $module.Params.uint64_type - -When in doubt, look at some of the other core modules and see how things have been -implemented there. - -Sometimes there are multiple ways that Windows offers to complete a task; this -is the order to favor when writing modules: - -- Native Powershell cmdlets like ``Remove-Item -Path C:\temp -Recurse`` -- .NET classes like ``[System.IO.Path]::GetRandomFileName()`` -- WMI objects through the ``New-CimInstance`` cmdlet -- COM objects through ``New-Object -ComObject`` cmdlet -- Calls to native executables like ``Secedit.exe`` - -PowerShell modules support a small subset of the ``#Requires`` options built -into PowerShell as well as some Ansible-specific requirements specified by -``#AnsibleRequires``. These statements can be placed at any point in the script, -but are most commonly near the top. They are used to make it easier to state the -requirements of the module without writing any of the checks. Each ``requires`` -statement must be on its own line, but there can be multiple requires statements -in one script. - -These are the checks that can be used within Ansible modules: - -- ``#Requires -Module Ansible.ModuleUtils.``: Added in Ansible 2.4, specifies a module_util to load in for the module execution. -- ``#Requires -Version x.y``: Added in Ansible 2.5, specifies the version of PowerShell that is required by the module. The module will fail if this requirement is not met. -- ``#AnsibleRequires -PowerShell ``: Added in Ansible 2.8, like ``#Requires -Module``, this specifies a module_util to load in for module execution. -- ``#AnsibleRequires -CSharpUtil ``: Added in Ansible 2.8, specifies a C# module_util to load in for the module execution. -- ``#AnsibleRequires -OSVersion x.y``: Added in Ansible 2.5, specifies the OS build version that is required by the module and will fail if this requirement is not met. The actual OS version is derived from ``[Environment]::OSVersion.Version``. -- ``#AnsibleRequires -Become``: Added in Ansible 2.5, forces the exec runner to run the module with ``become``, which is primarily used to bypass WinRM restrictions. If ``ansible_become_user`` is not specified then the ``SYSTEM`` account is used instead. - -The ``#AnsibleRequires -PowerShell`` and ``#AnsibleRequires -CSharpUtil`` -support further features such as: - -- Importing a util contained in a collection (added in Ansible 2.9) -- Importing a util by relative names (added in Ansible 2.10) -- Specifying the util is optional by adding `-Optional` to the import - declaration (added in Ansible 2.12). - -See the below examples for more details: - -.. code-block:: powershell - - # Imports the PowerShell Ansible.ModuleUtils.Legacy provided by Ansible itself - #AnsibleRequires -PowerShell Ansible.ModuleUtils.Legacy - - # Imports the PowerShell my_util in the my_namesapce.my_name collection - #AnsibleRequires -PowerShell ansible_collections.my_namespace.my_name.plugins.module_utils.my_util - - # Imports the PowerShell my_util that exists in the same collection as the current module - #AnsibleRequires -PowerShell ..module_utils.my_util - - # Imports the PowerShell Ansible.ModuleUtils.Optional provided by Ansible if it exists. - # If it does not exist then it will do nothing. - #AnsibleRequires -PowerShell Ansible.ModuleUtils.Optional -Optional - - # Imports the C# Ansible.Process provided by Ansible itself - #AnsibleRequires -CSharpUtil Ansible.Process - - # Imports the C# my_util in the my_namespace.my_name collection - #AnsibleRequires -CSharpUtil ansible_collections.my_namespace.my_name.plugins.module_utils.my_util - - # Imports the C# my_util that exists in the same collection as the current module - #AnsibleRequires -CSharpUtil ..module_utils.my_util - - # Imports the C# Ansible.Optional provided by Ansible if it exists. - # If it does not exist then it will do nothing. - #AnsibleRequires -CSharpUtil Ansible.Optional -Optional - -For optional require statements, it is up to the module code to then verify -whether the util has been imported before trying to use it. This can be done by -checking if a function or type provided by the util exists or not. - -While both ``#Requires -Module`` and ``#AnsibleRequires -PowerShell`` can be -used to load a PowerShell module it is recommended to use ``#AnsibleRequires``. -This is because ``#AnsibleRequires`` supports collection module utils, imports -by relative util names, and optional util imports. - -C# module utils can reference other C# utils by adding the line -``using Ansible.;`` to the top of the script with all the other -using statements. - - -Windows module utilities -======================== - -Like Python modules, PowerShell modules also provide a number of module -utilities that provide helper functions within PowerShell. These module_utils -can be imported by adding the following line to a PowerShell module: - -.. code-block:: powershell - - #Requires -Module Ansible.ModuleUtils.Legacy - -This will import the module_util at ``./lib/ansible/module_utils/powershell/Ansible.ModuleUtils.Legacy.psm1`` -and enable calling all of its functions. As of Ansible 2.8, Windows module -utils can also be written in C# and stored at ``lib/ansible/module_utils/csharp``. -These module_utils can be imported by adding the following line to a PowerShell -module: - -.. code-block:: powershell - - #AnsibleRequires -CSharpUtil Ansible.Basic - -This will import the module_util at ``./lib/ansible/module_utils/csharp/Ansible.Basic.cs`` -and automatically load the types in the executing process. C# module utils can -reference each other and be loaded together by adding the following line to the -using statements at the top of the util: - -.. code-block:: csharp - - using Ansible.Become; - -There are special comments that can be set in a C# file for controlling the -compilation parameters. The following comments can be added to the script; - -- ``//AssemblyReference -Name [-CLR [Core|Framework]]``: The assembly DLL to reference during compilation, the optional ``-CLR`` flag can also be used to state whether to reference when running under .NET Core, Framework, or both (if omitted) -- ``//NoWarn -Name [-CLR [Core|Framework]]``: A compiler warning ID to ignore when compiling the code, the optional ``-CLR`` works the same as above. A list of warnings can be found at `Compiler errors `_ - -As well as this, the following pre-processor symbols are defined; - -- ``CORECLR``: This symbol is present when PowerShell is running through .NET Core -- ``WINDOWS``: This symbol is present when PowerShell is running on Windows -- ``UNIX``: This symbol is present when PowerShell is running on Unix - -A combination of these flags help to make a module util interoperable on both -.NET Framework and .NET Core, here is an example of them in action: - -.. code-block:: csharp - - #if CORECLR - using Newtonsoft.Json; - #else - using System.Web.Script.Serialization; - #endif - - //AssemblyReference -Name Newtonsoft.Json.dll -CLR Core - //AssemblyReference -Name System.Web.Extensions.dll -CLR Framework - - // Ignore error CS1702 for all .NET types - //NoWarn -Name CS1702 - - // Ignore error CS1956 only for .NET Framework - //NoWarn -Name CS1956 -CLR Framework - - -The following is a list of module_utils that are packaged with Ansible and a general description of what -they do: - -- ArgvParser: Utility used to convert a list of arguments to an escaped string compliant with the Windows argument parsing rules. -- CamelConversion: Utility used to convert camelCase strings/lists/dicts to snake_case. -- CommandUtil: Utility used to execute a Windows process and return the stdout/stderr and rc as separate objects. -- FileUtil: Utility that expands on the ``Get-ChildItem`` and ``Test-Path`` to work with special files like ``C:\pagefile.sys``. -- Legacy: General definitions and helper utilities for Ansible module. -- LinkUtil: Utility to create, remove, and get information about symbolic links, junction points and hard inks. -- SID: Utilities used to convert a user or group to a Windows SID and vice versa. - -For more details on any specific module utility and their requirements, please see the `Ansible -module utilities source code `_. - -PowerShell module utilities can be stored outside of the standard Ansible -distribution for use with custom modules. Custom module_utils are placed in a -folder called ``module_utils`` located in the root folder of the playbook or role -directory. - -C# module utilities can also be stored outside of the standard Ansible distribution for use with custom modules. Like -PowerShell utils, these are stored in a folder called ``module_utils`` and the filename must end in the extension -``.cs``, start with ``Ansible.`` and be named after the namespace defined in the util. - -The below example is a role structure that contains two PowerShell custom module_utils called -``Ansible.ModuleUtils.ModuleUtil1``, ``Ansible.ModuleUtils.ModuleUtil2``, and a C# util containing the namespace -``Ansible.CustomUtil``: - -.. code-block:: console - - meta/ - main.yml - defaults/ - main.yml - module_utils/ - Ansible.ModuleUtils.ModuleUtil1.psm1 - Ansible.ModuleUtils.ModuleUtil2.psm1 - Ansible.CustomUtil.cs - tasks/ - main.yml - -Each PowerShell module_util must contain at least one function that has been exported with ``Export-ModuleMember`` -at the end of the file. For example - -.. code-block:: powershell - - Export-ModuleMember -Function Invoke-CustomUtil, Get-CustomInfo - - -Exposing shared module options -++++++++++++++++++++++++++++++ - -PowerShell module utils can easily expose common module options that a module can use when building its argument spec. -This allows common features to be stored and maintained in one location and have those features used by multiple -modules with minimal effort. Any new features or bugfixes added to one of these utils are then automatically used by -the various modules that call that util. - -An example of this would be to have a module util that handles authentication and communication against an API This -util can be used by multiple modules to expose a common set of module options like the API endpoint, username, -password, timeout, cert validation, and so on without having to add those options to each module spec. - -The standard convention for a module util that has a shared argument spec would have - -- A ``Get-Spec`` function that outputs the common spec for a module - * It is highly recommended to make this function name be unique to the module to avoid any conflicts with other utils that can be loaded - * The format of the output spec is a Hashtable in the same format as the ``$spec`` used for normal modules -- A function that takes in an ``AnsibleModule`` object called under the ``-Module`` parameter which it can use to get the shared options - -Because these options can be shared across various module it is highly recommended to keep the module option names and -aliases in the shared spec as specific as they can be. For example do not have a util option called ``password``, -rather you should prefix it with a unique name like ``acme_password``. - -.. warning:: - Failure to have a unique option name or alias can prevent the util being used by module that also use those names or - aliases for its own options. - -The following is an example module util called ``ServiceAuth.psm1`` in a collection that implements a common way for -modules to authentication with a service. - -.. code-block:: powershell - - Invoke-MyServiceResource { - [CmdletBinding()] - param ( - [Parameter(Mandatory=$true)] - [ValidateScript({ $_.GetType().FullName -eq 'Ansible.Basic.AnsibleModule' })] - $Module, - - [Parameter(Mandatory=$true)] - [String] - $ResourceId, - - [String] - $State = 'present' - ) - - # Process the common module options known to the util - $params = @{ - ServerUri = $Module.Params.my_service_url - } - if ($Module.Params.my_service_username) { - $params.Credential = Get-MyServiceCredential - } - - if ($State -eq 'absent') { - Remove-MyService @params -ResourceId $ResourceId - } else { - New-MyService @params -ResourceId $ResourceId - } - } - - Get-MyNamespaceMyCollectionServiceAuthSpec { - # Output the util spec - @{ - options = @{ - my_service_url = @{ type = 'str'; required = $true } - my_service_username = @{ type = 'str' } - my_service_password = @{ type = 'str'; no_log = $true } - } - - required_together = @( - ,@('my_service_username', 'my_service_password') - ) - } - } - - $exportMembers = @{ - Function = 'Get-MyNamespaceMyCollectionServiceAuthSpec', 'Invoke-MyServiceResource' - } - Export-ModuleMember @exportMembers - - -For a module to take advantage of this common argument spec it can be set out like - -.. code-block:: powershell - - #!powershell - - # Include the module util ServiceAuth.psm1 from the my_namespace.my_collection collection - #AnsibleRequires -PowerShell ansible_collections.my_namespace.my_collection.plugins.module_utils.ServiceAuth - - # Create the module spec like normal - $spec = @{ - options = @{ - resource_id = @{ type = 'str'; required = $true } - state = @{ type = 'str'; choices = 'absent', 'present' } - } - } - - # Create the module from the module spec but also include the util spec to merge into our own. - $module = [Ansible.Basic.AnsibleModule]::Create($args, $spec, @(Get-MyNamespaceMyCollectionServiceAuthSpec)) - - # Call the ServiceAuth module util and pass in the module object so it can access the module options. - Invoke-MyServiceResource -Module $module -ResourceId $module.Params.resource_id -State $module.params.state - - $module.ExitJson() - - -.. note:: - Options defined in the module spec will always have precedence over a util spec. Any list values under the same key - in a util spec will be appended to the module spec for that same key. Dictionary values will add any keys that are - missing from the module spec and merge any values that are lists or dictionaries. This is similar to how the doc - fragment plugins work when extending module documentation. - -To document these shared util options for a module, create a doc fragment plugin that documents the options implemented -by the module util and extend the module docs for every module that implements the util to include that fragment in -its docs. - - -Windows playbook module testing -=============================== - -You can test a module with an Ansible playbook. For example: - -- Create a playbook in any directory ``touch testmodule.yml``. -- Create an inventory file in the same directory ``touch hosts``. -- Populate the inventory file with the variables required to connect to a Windows host(s). -- Add the following to the new playbook file: - -.. code-block:: yaml - - --- - - name: test out windows module - hosts: windows - tasks: - - name: test out module - win_module: - name: test name - -- Run the playbook ``ansible-playbook -i hosts testmodule.yml`` - -This can be useful for seeing how Ansible runs with -the new module end to end. Other possible ways to test the module are -shown below. - - -Windows debugging -================= - -Debugging a module currently can only be done on a Windows host. This can be -useful when developing a new module or implementing bug fixes. These -are some steps that need to be followed to set this up: - -- Copy the module script to the Windows server -- Copy the folders ``./lib/ansible/module_utils/powershell`` and ``./lib/ansible/module_utils/csharp`` to the same directory as the script above -- Add an extra ``#`` to the start of any ``#Requires -Module`` lines in the module code, this is only required for any lines starting with ``#Requires -Module`` -- Add the following to the start of the module script that was copied to the server: - -.. code-block:: powershell - - # Set $ErrorActionPreference to what's set during Ansible execution - $ErrorActionPreference = "Stop" - - # Set the first argument as the path to a JSON file that contains the module args - $args = @("$($pwd.Path)\args.json") - - # Or instead of an args file, set $complex_args to the pre-processed module args - $complex_args = @{ - _ansible_check_mode = $false - _ansible_diff = $false - path = "C:\temp" - state = "present" - } - - # Import any C# utils referenced with '#AnsibleRequires -CSharpUtil' or 'using Ansible.; - # The $_csharp_utils entries should be the context of the C# util files and not the path - Import-Module -Name "$($pwd.Path)\powershell\Ansible.ModuleUtils.AddType.psm1" - $_csharp_utils = @( - [System.IO.File]::ReadAllText("$($pwd.Path)\csharp\Ansible.Basic.cs") - ) - Add-CSharpType -References $_csharp_utils -IncludeDebugInfo - - # Import any PowerShell modules referenced with '#Requires -Module` - Import-Module -Name "$($pwd.Path)\powershell\Ansible.ModuleUtils.Legacy.psm1" - - # End of the setup code and start of the module code - #!powershell - -You can add more args to ``$complex_args`` as required by the module or define the module options through a JSON file -with the structure: - -.. code-block:: json - - { - "ANSIBLE_MODULE_ARGS": { - "_ansible_check_mode": false, - "_ansible_diff": false, - "path": "C:\\temp", - "state": "present" - } - } - -There are multiple IDEs that can be used to debug a Powershell script, two of -the most popular ones are - -- `Powershell ISE`_ -- `Visual Studio Code`_ - -.. _Powershell ISE: https://docs.microsoft.com/en-us/powershell/scripting/core-powershell/ise/how-to-debug-scripts-in-windows-powershell-ise -.. _Visual Studio Code: https://blogs.technet.microsoft.com/heyscriptingguy/2017/02/06/debugging-powershell-script-in-visual-studio-code-part-1/ - -To be able to view the arguments as passed by Ansible to the module follow -these steps. - -- Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1` to specify that Ansible should keep the exec files on the server. -- Log onto the Windows server using the same user account that Ansible used to execute the module. -- Navigate to ``%TEMP%\..``. It should contain a folder starting with ``ansible-tmp-``. -- Inside this folder, open the PowerShell script for the module. -- In this script is a raw JSON script under ``$json_raw`` which contains the module arguments under ``module_args``. These args can be assigned manually to the ``$complex_args`` variable that is defined on your debug script or put in the ``args.json`` file. - - -Windows unit testing -==================== - -Currently there is no mechanism to run unit tests for Powershell modules under Ansible CI. - - -Windows integration testing -=========================== - -Integration tests for Ansible modules are typically written as Ansible roles. These test -roles are located in ``./test/integration/targets``. You must first set up your testing -environment, and configure a test inventory for Ansible to connect to. - -In this example we will set up a test inventory to connect to two hosts and run the integration -tests for win_stat: - -- Run the command ``source ./hacking/env-setup`` to prepare environment. -- Create a copy of ``./test/integration/inventory.winrm.template`` and name it ``inventory.winrm``. -- Fill in entries under ``[windows]`` and set the required variables that are needed to connect to the host. -- :ref:`Install the required Python modules ` to support WinRM and a configured authentication method. -- To execute the integration tests, run ``ansible-test windows-integration win_stat``; you can replace ``win_stat`` with the role you want to test. - -This will execute all the tests currently defined for that role. You can set -the verbosity level using the ``-v`` argument just as you would with -ansible-playbook. - -When developing tests for a new module, it is recommended to test a scenario once in -check mode and twice not in check mode. This ensures that check mode -does not make any changes but reports a change, as well as that the second run is -idempotent and does not report changes. For example: - -.. code-block:: yaml - - - name: remove a file (check mode) - win_file: - path: C:\temp - state: absent - register: remove_file_check - check_mode: true - - - name: get result of remove a file (check mode) - win_command: powershell.exe "if (Test-Path -Path 'C:\temp') { 'true' } else { 'false' }" - register: remove_file_actual_check - - - name: assert remove a file (check mode) - assert: - that: - - remove_file_check is changed - - remove_file_actual_check.stdout == 'true\r\n' - - - name: remove a file - win_file: - path: C:\temp - state: absent - register: remove_file - - - name: get result of remove a file - win_command: powershell.exe "if (Test-Path -Path 'C:\temp') { 'true' } else { 'false' }" - register: remove_file_actual - - - name: assert remove a file - assert: - that: - - remove_file is changed - - remove_file_actual.stdout == 'false\r\n' - - - name: remove a file (idempotent) - win_file: - path: C:\temp - state: absent - register: remove_file_again - - - name: assert remove a file (idempotent) - assert: - that: - - not remove_file_again is changed - - -Windows communication and development support -============================================= - -Join the ``#ansible-devel`` or ``#ansible-windows`` chat channels (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) for discussions about Ansible development for Windows. - -For questions and discussions pertaining to using the Ansible product, -use the ``#ansible`` channel. diff --git a/docs/docsite/rst/dev_guide/developing_modules_in_groups.rst b/docs/docsite/rst/dev_guide/developing_modules_in_groups.rst deleted file mode 100644 index cd44a3ffdc6..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules_in_groups.rst +++ /dev/null @@ -1,82 +0,0 @@ -.. _developing_modules_in_groups: - -************************* -Creating a new collection -************************* - -Starting with Ansible 2.10, related modules should be developed in a collection. The Ansible core team and community compiled these module development tips and tricks to help companies developing Ansible modules for their products and users developing Ansible modules for third-party products. See :ref:`developing_collections` for a more detailed description of the collections format and additional development guidelines. - -.. contents:: - :local: - -.. include:: shared_snippets/licensing.txt - -Before you start coding -======================= - -This list of prerequisites is designed to help ensure that you develop high-quality modules that work well with ansible-core and provide a seamless user experience. - -* Read though all the pages linked off :ref:`developing_modules_general`; paying particular focus to the :ref:`developing_modules_checklist`. -* We encourage PEP 8 compliance. See :ref:`testing_pep8` for more information. -* We encourage supporting :ref:`Python 2.6+ and Python 3.5+ `. -* Look at Ansible Galaxy and review the naming conventions in your functional area (such as cloud, networking, databases). -* With great power comes great responsibility: Ansible collection maintainers have a duty to help keep content up to date and release collections they are responsible for regularly. As with all successful community projects, collection maintainers should keep a watchful eye for reported issues and contributions. -* We strongly recommend unit and/or integration tests. Unit tests are especially valuable when external resources (such as cloud or network devices) are required. For more information see :ref:`developing_testing` and the `Testing Working Group `_. - - -Naming conventions -================== - -Fully Qualified Collection Names (FQCNs) for plugins and modules include three elements: - - * the Galaxy namespace, which generally represents the company or group - * the collection name, which generally represents the product or OS - * the plugin or module name - * always in lower case - * words separated with an underscore (``_``) character - * singular, rather than plural, for example, ``command`` not ``commands`` - -For example, ``community.mongodb.mongodb_linux`` or ``cisco.meraki.meraki_device``. - -It is convenient if the organization and repository names on GitHub (or elsewhere) match your namespace and collection names on Ansible Galaxy, but it is not required. The plugin names you select, however, are always the same in your code repository and in your collection artifact on Galaxy. - -Speak to us -=========== - -Circulating your ideas before coding helps you adopt good practices and avoid common mistakes. After reading the "Before you start coding" section you should have a reasonable idea of the structure of your modules. Write a list of your proposed plugin and/or module names, with a short description of what each one does. Circulate that list on IRC or a mailing list so the Ansible community can review your ideas for consistency and familiarity. Names and functionality that are consistent, predictable, and familiar make your collection easier to use. - -.. _developing_in_groups_support: - -Where to get support -==================== - -Ansible has a thriving and knowledgeable community of module developers that is a great resource for getting your questions answered. - -In the :ref:`ansible_community_guide` you can find how to: - -* Subscribe to the Mailing Lists - We suggest "Ansible Development List" and "Ansible Announce list" -* ``#ansible-devel`` - We have found that communicating on the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) works best for developers so we can have an interactive dialogue. -* Working group and other chat channel meetings - Join the various weekly meetings `meeting schedule and agenda page `_ - -Required files -============== - -Your collection should include the following files to be usable: - -* an ``__init__.py`` file - An empty file to initialize namespace and allow Python to import the files. *Required* -* at least one plugin, for example, ``/plugins/modules/$your_first_module.py``. *Required* -* if needed, one or more ``/plugins/doc_fragments/$topic.py`` files - Code documentation, such as details regarding common arguments. *Optional* -* if needed, one or more ``/plugins/module_utils/$topic.py`` files - Code shared between more than one module, such as common arguments. *Optional* - -When you have these files ready, review the :ref:`developing_modules_checklist` again. If you are creating a new collection, you are responsible for all procedures related to your repository, including setting rules for contributions, finding reviewers, and testing and maintaining the code in your collection. - -If you need help or advice, consider joining the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). For more information, see :ref:`developing_in_groups_support` and :ref:`communication`. - -New to git or GitHub -==================== - -We realize this may be your first use of Git or GitHub. The following guides may be of use: - -* `How to create a fork of ansible/ansible `_ -* `How to sync (update) your fork `_ -* `How to create a Pull Request (PR) `_ diff --git a/docs/docsite/rst/dev_guide/developing_plugins.rst b/docs/docsite/rst/dev_guide/developing_plugins.rst deleted file mode 100644 index e1143cf4925..00000000000 --- a/docs/docsite/rst/dev_guide/developing_plugins.rst +++ /dev/null @@ -1,578 +0,0 @@ -.. _developing_plugins: -.. _plugin_guidelines: - -****************** -Developing plugins -****************** - -.. contents:: - :local: - -Plugins augment Ansible's core functionality with logic and features that are accessible to all modules. Ansible collections include a number of handy plugins, and you can easily write your own. All plugins must: - -* be written in Python -* raise errors -* return strings in unicode -* conform to Ansible's configuration and documentation standards - -Once you've reviewed these general guidelines, you can skip to the particular type of plugin you want to develop. - -Writing plugins in Python -========================= - -You must write your plugin in Python so it can be loaded by the ``PluginLoader`` and returned as a Python object that any module can use. Since your plugin will execute on the controller, you must write it in a :ref:`compatible version of Python `. - -Raising errors -============== - -You should return errors encountered during plugin execution by raising ``AnsibleError()`` or a similar class with a message describing the error. When wrapping other exceptions into error messages, you should always use the ``to_native`` Ansible function to ensure proper string compatibility across Python versions: - -.. code-block:: python - - from ansible.module_utils.common.text.converters import to_native - - try: - cause_an_exception() - except Exception as e: - raise AnsibleError('Something happened, this was original exception: %s' % to_native(e)) - -Since Ansible evaluates variables only when they are needed, filter and test plugins should propagate the exceptions ``jinja2.exceptions.UndefinedError`` and ``AnsibleUndefinedVariable`` to ensure undefined variables are only fatal when necessary. - -Check the different `AnsibleError objects `_ and see which one applies best to your situation. -Check the section on the specific plugin type you're developing for type-specific error handling details. - -String encoding -=============== - -You must convert any strings returned by your plugin into Python's unicode type. Converting to unicode ensures that these strings can run through Jinja2. To convert strings: - -.. code-block:: python - - from ansible.module_utils.common.text.converters import to_text - result_string = to_text(result_string) - -Plugin configuration & documentation standards -============================================== - -To define configurable options for your plugin, describe them in the ``DOCUMENTATION`` section of the python file. Callback and connection plugins have declared configuration requirements this way since Ansible version 2.4; most plugin types now do the same. This approach ensures that the documentation of your plugin's options will always be correct and up-to-date. To add a configurable option to your plugin, define it in this format: - -.. code-block:: yaml - - options: - option_name: - description: describe this config option - default: default value for this config option - env: - - name: NAME_OF_ENV_VAR - ini: - - section: section_of_ansible.cfg_where_this_config_option_is_defined - key: key_used_in_ansible.cfg - vars: - - name: name_of_ansible_var - - name: name_of_second_var - version_added: X.x - required: True/False - type: boolean/float/integer/list/none/path/pathlist/pathspec/string/tmppath - version_added: X.x - -To access the configuration settings in your plugin, use ``self.get_option()``. -Some plugin types hande this differently: - -* Become, callback, connection and shell plugins are guaranteed to have the engine call ``set_options()``. -* Lookup plugins always require you to handle it in the ``run()`` method. -* Inventory plugins are done automatically if you use the ``base _read_config_file()`` method. If not, you must use ``self.get_option()``. -* Cache plugins do it on load. -* Cliconf, httpapi and netconf plugins indirectly piggy back on connection plugins. -* Vars plugin settings are populated when first accessed (using the ``self.get_option()`` or ``self.get_options()`` method. - -If you need to populate settings explicitly, use a ``self.set_options()`` call. - -Configuration sources follow the precedence rules for values in Ansible. When there are multiple values from the same category, the value defined last takes precedence. For example, in the above configuration block, if both ``name_of_ansible_var`` and ``name_of_second_var`` are defined, the value of the ``option_name`` option will be the value of ``name_of_second_var``. Refer to :ref:`general_precedence_rules` for further information. - -Plugins that support embedded documentation (see :ref:`ansible-doc` for the list) should include well-formed doc strings. If you inherit from a plugin, you must document the options it takes, either through a documentation fragment or as a copy. See :ref:`module_documenting` for more information on correct documentation. Thorough documentation is a good idea even if you're developing a plugin for local use. - -In ansible-core 2.14 we added support for documenting filter and test plugins. You have two options for providing documentation: - - Define a Python file that includes inline documentation for each plugin. - - Define a Python file for multiple plugins and create adjacent documentation files in YAML format. - -Developing particular plugin types -================================== - -.. _developing_actions: - -Action plugins --------------- - -Action plugins let you integrate local processing and local data with module functionality. - -To create an action plugin, create a new class with the Base(ActionBase) class as the parent: - -.. code-block:: python - - from ansible.plugins.action import ActionBase - - class ActionModule(ActionBase): - pass - -From there, execute the module using the ``_execute_module`` method to call the original module. -After successful execution of the module, you can modify the module return data. - -.. code-block:: python - - module_return = self._execute_module(module_name='', - module_args=module_args, - task_vars=task_vars, tmp=tmp) - - -For example, if you wanted to check the time difference between your Ansible controller and your target machine(s), you could write an action plugin to check the local time and compare it to the return data from Ansible's ``setup`` module: - -.. code-block:: python - - #!/usr/bin/python - # Make coding more python3-ish, this is required for contributions to Ansible - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type - - from ansible.plugins.action import ActionBase - from datetime import datetime - - - class ActionModule(ActionBase): - def run(self, tmp=None, task_vars=None): - super(ActionModule, self).run(tmp, task_vars) - module_args = self._task.args.copy() - module_return = self._execute_module(module_name='setup', - module_args=module_args, - task_vars=task_vars, tmp=tmp) - ret = dict() - remote_date = None - if not module_return.get('failed'): - for key, value in module_return['ansible_facts'].items(): - if key == 'ansible_date_time': - remote_date = value['iso8601'] - - if remote_date: - remote_date_obj = datetime.strptime(remote_date, '%Y-%m-%dT%H:%M:%SZ') - time_delta = datetime.utcnow() - remote_date_obj - ret['delta_seconds'] = time_delta.seconds - ret['delta_days'] = time_delta.days - ret['delta_microseconds'] = time_delta.microseconds - - return dict(ansible_facts=dict(ret)) - - -This code checks the time on the controller, captures the date and time for the remote machine using the ``setup`` module, and calculates the difference between the captured time and -the local time, returning the time delta in days, seconds and microseconds. - -For practical examples of action plugins, -see the source code for the `action plugins included with Ansible Core `_ - -.. _developing_cache_plugins: - -Cache plugins -------------- - -Cache plugins store gathered facts and data retrieved by inventory plugins. - -Import cache plugins using the cache_loader so you can use ``self.set_options()`` and ``self.get_option()``. If you import a cache plugin directly in the code base, you can only access options by the ``ansible.constants``, and you break the cache plugin's ability to be used by an inventory plugin. - -.. code-block:: python - - from ansible.plugins.loader import cache_loader - [...] - plugin = cache_loader.get('custom_cache', **cache_kwargs) - -There are two base classes for cache plugins, ``BaseCacheModule`` for database-backed caches, and ``BaseCacheFileModule`` for file-backed caches. - -To create a cache plugin, start by creating a new ``CacheModule`` class with the appropriate base class. If you're creating a plugin using an ``__init__`` method you should initialize the base class with any provided args and kwargs to be compatible with inventory plugin cache options. The base class calls ``self.set_options(direct=kwargs)``. After the base class ``__init__`` method is called ``self.get_option()`` should be used to access cache options. - -New cache plugins should take the options ``_uri``, ``_prefix``, and ``_timeout`` to be consistent with existing cache plugins. - -.. code-block:: python - - from ansible.plugins.cache import BaseCacheModule - - class CacheModule(BaseCacheModule): - def __init__(self, *args, **kwargs): - super(CacheModule, self).__init__(*args, **kwargs) - self._connection = self.get_option('_uri') - self._prefix = self.get_option('_prefix') - self._timeout = self.get_option('_timeout') - -If you use the ``BaseCacheModule``, you must implement the methods ``get``, ``contains``, ``keys``, ``set``, ``delete``, ``flush``, and ``copy``. The ``contains`` method should return a boolean that indicates if the key exists and has not expired. Unlike file-based caches, the ``get`` method does not raise a KeyError if the cache has expired. - -If you use the ``BaseFileCacheModule``, you must implement ``_load`` and ``_dump`` methods that will be called from the base class methods ``get`` and ``set``. - -If your cache plugin stores JSON, use ``AnsibleJSONEncoder`` in the ``_dump`` or ``set`` method and ``AnsibleJSONDecoder`` in the ``_load`` or ``get`` method. - -For example cache plugins, see the source code for the `cache plugins included with Ansible Core `_. - -.. _developing_callbacks: - -Callback plugins ----------------- - -Callback plugins add new behaviors to Ansible when responding to events. By default, callback plugins control most of the output you see when running the command line programs. - -To create a callback plugin, create a new class with the Base(Callbacks) class as the parent: - -.. code-block:: python - - from ansible.plugins.callback import CallbackBase - - class CallbackModule(CallbackBase): - pass - -From there, override the specific methods from the CallbackBase that you want to provide a callback for. -For plugins intended for use with Ansible version 2.0 and later, you should only override methods that start with ``v2``. -For a complete list of methods that you can override, please see ``__init__.py`` in the -`lib/ansible/plugins/callback `_ directory. - -The following is a modified example of how Ansible's timer plugin is implemented, -but with an extra option so you can see how configuration works in Ansible version 2.4 and later: - -.. code-block:: python - - # Make coding more python3-ish, this is required for contributions to Ansible - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type - - # not only visible to ansible-doc, it also 'declares' the options the plugin requires and how to configure them. - DOCUMENTATION = ''' - name: timer - callback_type: aggregate - requirements: - - enable in configuration - short_description: Adds time to play stats - version_added: "2.0" # for collections, use the collection version, not the Ansible version - description: - - This callback just adds total play duration to the play stats. - options: - format_string: - description: format of the string shown to user at play end - ini: - - section: callback_timer - key: format_string - env: - - name: ANSIBLE_CALLBACK_TIMER_FORMAT - default: "Playbook run took %s days, %s hours, %s minutes, %s seconds" - ''' - from datetime import datetime - - from ansible.plugins.callback import CallbackBase - - - class CallbackModule(CallbackBase): - """ - This callback module tells you how long your plays ran for. - """ - CALLBACK_VERSION = 2.0 - CALLBACK_TYPE = 'aggregate' - CALLBACK_NAME = 'namespace.collection_name.timer' - - # only needed if you ship it and don't want to enable by default - CALLBACK_NEEDS_ENABLED = True - - def __init__(self): - - # make sure the expected objects are present, calling the base's __init__ - super(CallbackModule, self).__init__() - - # start the timer when the plugin is loaded, the first play should start a few milliseconds after. - self.start_time = datetime.now() - - def _days_hours_minutes_seconds(self, runtime): - ''' internal helper method for this callback ''' - minutes = (runtime.seconds // 60) % 60 - r_seconds = runtime.seconds - (minutes * 60) - return runtime.days, runtime.seconds // 3600, minutes, r_seconds - - # this is only event we care about for display, when the play shows its summary stats; the rest are ignored by the base class - def v2_playbook_on_stats(self, stats): - end_time = datetime.now() - runtime = end_time - self.start_time - - # Shows the usage of a config option declared in the DOCUMENTATION variable. Ansible will have set it when it loads the plugin. - # Also note the use of the display object to print to screen. This is available to all callbacks, and you should use this over printing yourself - self._display.display(self._plugin_options['format_string'] % (self._days_hours_minutes_seconds(runtime))) - - -Note that the ``CALLBACK_VERSION`` and ``CALLBACK_NAME`` definitions are required for properly functioning plugins for Ansible version 2.0 and later. ``CALLBACK_TYPE`` is mostly needed to distinguish 'stdout' plugins from the rest, since you can only load one plugin that writes to stdout. - -For example callback plugins, see the source code for the `callback plugins included with Ansible Core `_ - -New in ansible-core 2.11, callback plugins are notified (by the ``v2_playbook_on_task_start``) of :ref:`meta` tasks. By default, only explicit ``meta`` tasks that users list in their plays are sent to callbacks. - -There are also some tasks which are generated internally and implicitly at various points in execution. Callback plugins can opt-in to receiving these implicit tasks as well, by setting ``self.wants_implicit_tasks = True``. Any ``Task`` object received by a callback hook will have an ``.implicit`` attribute, which can be consulted to determine whether the ``Task`` originated from within Ansible, or explicitly by the user. - -.. _developing_connection_plugins: - -Connection plugins ------------------- - -Connection plugins allow Ansible to connect to the target hosts so it can execute tasks on them. Ansible ships with many connection plugins, but only one can be used per host at a time. The most commonly used connection plugins are the ``paramiko`` SSH, native ssh (just called ``ssh``), and ``local`` connection types. All of these can be used in playbooks and with ``/usr/bin/ansible`` to connect to remote machines. - -Ansible version 2.1 introduced the ``smart`` connection plugin. The ``smart`` connection type allows Ansible to automatically select either the ``paramiko`` or ``openssh`` connection plugin based on system capabilities, or the ``ssh`` connection plugin if OpenSSH supports ControlPersist. - -To create a new connection plugin (for example, to support SNMP, Message bus, or other transports), copy the format of one of the existing connection plugins and drop it into ``connection`` directory on your :ref:`local plugin path `. - -Connection plugins can support common options (such as the ``--timeout`` flag) by defining an entry in the documentation for the attribute name (in this case ``timeout``). If the common option has a non-null default, the plugin should define the same default since a different default would be ignored. - -For example connection plugins, see the source code for the `connection plugins included with Ansible Core `_. - -.. _developing_filter_plugins: - -Filter plugins --------------- - -Filter plugins manipulate data. They are a feature of Jinja2 and are also available in Jinja2 templates used by the ``template`` module. As with all plugins, they can be easily extended, but instead of having a file for each one you can have several per file. Most of the filter plugins shipped with Ansible reside in a ``core.py``. - -Filter plugins do not use the standard configuration system described above, but since ansible-core 2.14 can use it as plain documentation. - -Since Ansible evaluates variables only when they are needed, filter plugins should propagate the exceptions ``jinja2.exceptions.UndefinedError`` and ``AnsibleUndefinedVariable`` to ensure undefined variables are only fatal when necessary. - -.. code-block:: python - - try: - cause_an_exception(with_undefined_variable) - except jinja2.exceptions.UndefinedError as e: - raise AnsibleUndefinedVariable("Something happened, this was the original exception: %s" % to_native(e)) - except Exception as e: - raise AnsibleFilterError("Something happened, this was the original exception: %s" % to_native(e)) - -For example filter plugins, see the source code for the `filter plugins included with Ansible Core `_. - -.. _developing_inventory_plugins: - -Inventory plugins ------------------ - -Inventory plugins parse inventory sources and form an in-memory representation of the inventory. Inventory plugins were added in Ansible version 2.4. - -You can see the details for inventory plugins in the :ref:`developing_inventory` page. - -.. _developing_lookup_plugins: - -Lookup plugins --------------- - -Lookup plugins pull in data from external data stores. Lookup plugins can be used within playbooks both for looping --- playbook language constructs like ``with_fileglob`` and ``with_items`` are implemented through lookup plugins --- and to return values into a variable or parameter. - -Lookup plugins are expected to return lists, even if just a single element. - -Ansible includes many :ref:`filters ` which can be used to manipulate the data returned by a lookup plugin. Sometimes it makes sense to do the filtering inside the lookup plugin, other times it is better to return results that can be filtered in the playbook. Keep in mind how the data will be referenced when determining the appropriate level of filtering to be done inside the lookup plugin. - -Here's a simple lookup plugin implementation --- this lookup returns the contents of a text file as a variable: - -.. code-block:: python - - # python 3 headers, required if submitting to Ansible - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type - - DOCUMENTATION = r""" - name: file - author: Daniel Hokka Zakrisson (@dhozac) - version_added: "0.9" # for collections, use the collection version, not the Ansible version - short_description: read file contents - description: - - This lookup returns the contents from a file on the Ansible controller's file system. - options: - _terms: - description: path(s) of files to read - required: True - option1: - description: - - Sample option that could modify plugin behaviour. - - This one can be set directly ``option1='x'`` or in ansible.cfg, but can also use vars or environment. - type: string - ini: - - section: file_lookup - key: option1 - notes: - - if read in variable context, the file can be interpreted as YAML if the content is valid to the parser. - - this lookup does not understand globbing --- use the fileglob lookup instead. - """ - from ansible.errors import AnsibleError, AnsibleParserError - from ansible.plugins.lookup import LookupBase - from ansible.utils.display import Display - - display = Display() - - class LookupModule(LookupBase): - - def run(self, terms, variables=None, **kwargs): - - # First of all populate options, - # this will already take into account env vars and ini config - self.set_options(var_options=variables, direct=kwargs) - - # lookups in general are expected to both take a list as input and output a list - # this is done so they work with the looping construct 'with_'. - ret = [] - for term in terms: - display.debug("File lookup term: %s" % term) - - # Find the file in the expected search path, using a class method - # that implements the 'expected' search path for Ansible plugins. - lookupfile = self.find_file_in_search_path(variables, 'files', term) - - # Don't use print or your own logging, the display class - # takes care of it in a unified way. - display.vvvv(u"File lookup using %s as file" % lookupfile) - try: - if lookupfile: - contents, show_data = self._loader._get_file_contents(lookupfile) - ret.append(contents.rstrip()) - else: - # Always use ansible error classes to throw 'final' exceptions, - # so the Ansible engine will know how to deal with them. - # The Parser error indicates invalid options passed - raise AnsibleParserError() - except AnsibleParserError: - raise AnsibleError("could not locate file in lookup: %s" % term) - - # consume an option: if this did something useful, you can retrieve the option value here - if self.get_option('option1') == 'do something': - pass - - return ret - - -The following is an example of how this lookup is called: - -.. code-block:: YAML - - --- - - hosts: all - vars: - contents: "{{ lookup('namespace.collection_name.file', '/etc/foo.txt') }}" - contents_with_option: "{{ lookup('namespace.collection_name.file', '/etc/foo.txt', option1='donothing') }}" - tasks: - - - debug: - msg: the value of foo.txt is {{ contents }} as seen today {{ lookup('pipe', 'date +"%Y-%m-%d"') }} - - -For example lookup plugins, see the source code for the `lookup plugins included with Ansible Core `_. - -For more usage examples of lookup plugins, see :ref:`Using Lookups`. - -.. _developing_test_plugins: - -Test plugins ------------- - -Test plugins verify data. They are a feature of Jinja2 and are also available in Jinja2 templates used by the ``template`` module. As with all plugins, they can be easily extended, but instead of having a file for each one you can have several per file. Most of the test plugins shipped with Ansible reside in a ``core.py``. These are specially useful in conjunction with some filter plugins like ``map`` and ``select``; they are also available for conditional directives like ``when:``. - -Test plugins do not use the standard configuration system described above. Since ansible-core 2.14 test plugins can use plain documentation. - -Since Ansible evaluates variables only when they are needed, test plugins should propagate the exceptions ``jinja2.exceptions.UndefinedError`` and ``AnsibleUndefinedVariable`` to ensure undefined variables are only fatal when necessary. - -.. code-block:: python - - try: - cause_an_exception(with_undefined_variable) - except jinja2.exceptions.UndefinedError as e: - raise AnsibleUndefinedVariable("Something happened, this was the original exception: %s" % to_native(e)) - except Exception as e: - raise AnsibleFilterError("Something happened, this was the original exception: %s" % to_native(e)) - -For example test plugins, see the source code for the `test plugins included with Ansible Core `_. - -.. _developing_vars_plugins: - -Vars plugins ------------- - -Vars plugins inject additional variable data into Ansible runs that did not come from an inventory source, playbook, or command line. Playbook constructs like 'host_vars' and 'group_vars' work using vars plugins. - -Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4. Vars plugins are supported by collections starting with Ansible 2.10. - -Older plugins used a ``run`` method as their main body/work: - -.. code-block:: python - - def run(self, name, vault_password=None): - pass # your code goes here - - -Ansible 2.0 did not pass passwords to older plugins, so vaults were unavailable. -Most of the work now happens in the ``get_vars`` method which is called from the VariableManager when needed. - -.. code-block:: python - - def get_vars(self, loader, path, entities): - pass # your code goes here - -The parameters are: - - * loader: Ansible's DataLoader. The DataLoader can read files, auto-load JSON/YAML and decrypt vaulted data, and cache read files. - * path: this is 'directory data' for every inventory source and the current play's playbook directory, so they can search for data in reference to them. ``get_vars`` will be called at least once per available path. - * entities: these are host or group names that are pertinent to the variables needed. The plugin will get called once for hosts and again for groups. - -This ``get_vars`` method just needs to return a dictionary structure with the variables. - -Since Ansible version 2.4, vars plugins only execute as needed when preparing to execute a task. This avoids the costly 'always execute' behavior that occurred during inventory construction in older versions of Ansible. Since Ansible version 2.10, vars plugin execution can be toggled by the user to run when preparing to execute a task or after importing an inventory source. - -The user must explicitly enable vars plugins that reside in a collection. See :ref:`enable_vars` for details. - -Legacy vars plugins are always loaded and run by default. You can prevent them from automatically running by setting ``REQUIRES_ENABLED`` to True. - -.. code-block:: python - - class VarsModule(BaseVarsPlugin): - REQUIRES_ENABLED = True - -Include the ``vars_plugin_staging`` documentation fragment to allow users to determine when vars plugins run. - -.. code-block:: python - - DOCUMENTATION = ''' - name: custom_hostvars - version_added: "2.10" # for collections, use the collection version, not the Ansible version - short_description: Load custom host vars - description: Load custom host vars - options: - stage: - ini: - - key: stage - section: vars_custom_hostvars - env: - - name: ANSIBLE_VARS_PLUGIN_STAGE - extends_documentation_fragment: - - vars_plugin_staging - ''' - -At times a value provided by a vars plugin will contain unsafe values. The utility function `wrap_var` provided by `ansible.utils.unsafe_proxy` should be used to ensure that Ansible handles the variable and value correctly. The use cases for unsafe data is covered in :ref:`unsafe_strings`. - -.. code-block:: python - - from ansible.plugins.vars import BaseVarsPlugin - from ansible.utils.unsafe_proxy import wrap_var - - class VarsPlugin(BaseVarsPlugin): - def get_vars(self, loader, path, entities): - return dict( - something_unsafe=wrap_var("{{ SOMETHING_UNSAFE }}") - ) - -For example vars plugins, see the source code for the `vars plugins included with Ansible Core -`_. - -.. seealso:: - - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_api` - Learn about the Python API for task execution - :ref:`developing_inventory` - Learn about how to develop dynamic inventory sources - :ref:`developing_modules_general` - Learn about how to write Ansible modules - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels - :ref:`adjacent_yaml_doc` - Alternate YAML files as documentation diff --git a/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst b/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst deleted file mode 100644 index e858103d6bd..00000000000 --- a/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst +++ /dev/null @@ -1,923 +0,0 @@ -.. _flow_modules: -.. _developing_program_flow_modules: - -*************************** -Ansible module architecture -*************************** - -If you are working on the ``ansible-core`` code, writing an Ansible module, or developing an action plugin, you may need to understand how Ansible's program flow executes. If you are just using Ansible Modules in playbooks, you can skip this section. - -.. contents:: - :local: - -.. _flow_types_of_modules: - -Types of modules -================ - -Ansible supports several different types of modules in its code base. Some of -these are for backwards compatibility and others are to enable flexibility. - -.. _flow_action_plugins: - -Action plugins --------------- - -Action plugins look like modules to anyone writing a playbook. Usage documentation for most action plugins lives inside a module of the same name. Some action plugins do all the work, with the module providing only documentation. Some action plugins execute modules. The ``normal`` action plugin executes modules that don't have special action plugins. Action plugins always execute on the controller. - -Some action plugins do all their work on the controller. For -example, the :ref:`debug ` action plugin (which prints text for -the user to see) and the :ref:`assert ` action plugin (which -tests whether values in a playbook satisfy certain criteria) execute entirely on the controller. - -Most action plugins set up some values on the controller, then invoke an -actual module on the managed node that does something with these values. For example, the :ref:`template ` action plugin takes values from -the user to construct a file in a temporary location on the controller using -variables from the playbook environment. It then transfers the temporary file -to a temporary file on the remote system. After that, it invokes the -:ref:`copy module ` which operates on the remote system to move the file -into its final location, sets file permissions, and so on. - -.. _flow_new_style_modules: - -New-style modules ------------------ - -All of the modules that ship with Ansible fall into this category. While you can write modules in any language, all official modules (shipped with Ansible) use either Python or PowerShell. - -New-style modules have the arguments to the module embedded inside of them in -some manner. Old-style modules must copy a separate file over to the -managed node, which is less efficient as it requires two over-the-wire -connections instead of only one. - -.. _flow_python_modules: - -Python -^^^^^^ - -New-style Python modules use the :ref:`Ansiballz` framework for constructing -modules. These modules use imports from :code:`ansible.module_utils` to pull in -boilerplate module code, such as argument parsing, formatting of return -values as :term:`JSON`, and various file operations. - -.. note:: In Ansible, up to version 2.0.x, the official Python modules used the - :ref:`module_replacer` framework. For module authors, :ref:`Ansiballz` is - largely a superset of :ref:`module_replacer` functionality, so you usually - do not need to understand the differences between them. - -.. _flow_powershell_modules: - -PowerShell -^^^^^^^^^^ - -New-style PowerShell modules use the :ref:`module_replacer` framework for -constructing modules. These modules get a library of PowerShell code embedded -in them before being sent to the managed node. - -.. _flow_jsonargs_modules: - -JSONARGS modules ----------------- - -These modules are scripts that include the string -``<>`` in their body. -This string is replaced with the JSON-formatted argument string. These modules typically set a variable to that value like this: - -.. code-block:: python - - json_arguments = """<>""" - -Which is expanded as: - -.. code-block:: python - - json_arguments = """{"param1": "test's quotes", "param2": "\"To be or not to be\" - Hamlet"}""" - -.. note:: Ansible outputs a :term:`JSON` string with bare quotes. Double quotes are - used to quote string values, double quotes inside of string values are - backslash escaped, and single quotes may appear unescaped inside of - a string value. To use JSONARGS, your scripting language must have a way - to handle this type of string. The example uses Python's triple quoted - strings to do this. Other scripting languages may have a similar quote - character that won't be confused by any quotes in the JSON or it may - allow you to define your own start-of-quote and end-of-quote characters. - If the language doesn't give you any of these then you'll need to write - a :ref:`non-native JSON module ` or - :ref:`Old-style module ` instead. - -These modules typically parse the contents of ``json_arguments`` using a JSON -library and then use them as native variables throughout the code. - -.. _flow_want_json_modules: - -Non-native want JSON modules ----------------------------- - -If a module has the string ``WANT_JSON`` in it anywhere, Ansible treats -it as a non-native module that accepts a filename as its only command-line -parameter. The filename is for a temporary file containing a :term:`JSON` -string containing the module's parameters. The module needs to open the file, -read and parse the parameters, operate on the data, and print its return data -as a JSON encoded dictionary to stdout before exiting. - -These types of modules are self-contained entities. As of Ansible 2.1, Ansible -only modifies them to change a shebang line if present. - -.. seealso:: Examples of Non-native modules written in ruby are in the `Ansible - for Rubyists `_ repository. - -.. _flow_binary_modules: - -Binary modules --------------- - -From Ansible 2.2 onwards, modules may also be small binary programs. Ansible -doesn't perform any magic to make these portable to different systems so they -may be specific to the system on which they were compiled or require other -binary runtime dependencies. Despite these drawbacks, you may have -to compile a custom module against a specific binary -library if that's the only way to get access to certain resources. - -Binary modules take their arguments and return data to Ansible in the same -way as :ref:`want JSON modules `. - -.. seealso:: One example of a `binary module - `_ - written in go. - -.. _flow_old_style_modules: - -Old-style modules ------------------ - -Old-style modules are similar to -:ref:`want JSON modules `, except that the file that -they take contains ``key=value`` pairs for their parameters instead of -:term:`JSON`. Ansible decides that a module is old-style when it doesn't have -any of the markers that would show that it is one of the other types. - -.. _flow_how_modules_are_executed: - -How modules are executed -======================== - -When a user uses :program:`ansible` or :program:`ansible-playbook`, they -specify a task to execute. The task is usually the name of a module along -with several parameters to be passed to the module. Ansible takes these -values and processes them in various ways before they are finally executed on -the remote machine. - -.. _flow_executor_task_executor: - -Executor/task_executor ----------------------- - -The TaskExecutor receives the module name and parameters that were parsed from -the :term:`playbook ` (or from the command-line in the case of -:command:`/usr/bin/ansible`). It uses the name to decide whether it's looking -at a module or an :ref:`Action Plugin `. If it's -a module, it loads the :ref:`Normal Action Plugin ` -and passes the name, variables, and other information about the task and play -to that Action Plugin for further processing. - -.. _flow_normal_action_plugin: - -The ``normal`` action plugin ----------------------------- - -The ``normal`` action plugin executes the module on the remote host. It is -the primary coordinator of much of the work to actually execute the module on -the managed machine. - -* It loads the appropriate connection plugin for the task, which then transfers - or executes as needed to create a connection to that host. -* It adds any internal Ansible properties to the module's parameters (for - instance, the ones that pass along ``no_log`` to the module). -* It works with other plugins (connection, shell, become, other action plugins) - to create any temporary files on the remote machine and - cleans up afterwards. -* It pushes the module and module parameters to the - remote host, although the :ref:`module_common ` - code described in the next section decides which format - those will take. -* It handles any special cases regarding modules (for instance, async - execution, or complications around Windows modules that must have the same names as Python modules, so that internal calling of modules from other Action Plugins work.) - -Much of this functionality comes from the `BaseAction` class, -which lives in :file:`plugins/action/__init__.py`. It uses the -``Connection`` and ``Shell`` objects to do its work. - -.. note:: - When :term:`tasks ` are run with the ``async:`` parameter, Ansible - uses the ``async`` Action Plugin instead of the ``normal`` Action Plugin - to invoke it. That program flow is currently not documented. Read the - source for information on how that works. - -.. _flow_executor_module_common: - -Executor/module_common.py -------------------------- - -Code in :file:`executor/module_common.py` assembles the module -to be shipped to the managed node. The module is first read in, then examined -to determine its type: - -* :ref:`PowerShell ` and :ref:`JSON-args modules ` are passed through :ref:`Module Replacer `. -* New-style :ref:`Python modules ` are assembled by :ref:`Ansiballz`. -* :ref:`Non-native-want-JSON `, :ref:`Binary modules `, and :ref:`Old-Style modules ` aren't touched by either of these and pass through unchanged. - -After the assembling step, one final -modification is made to all modules that have a shebang line. Ansible checks -whether the interpreter in the shebang line has a specific path configured via -an ``ansible_$X_interpreter`` inventory variable. If it does, Ansible -substitutes that path for the interpreter path given in the module. After -this, Ansible returns the complete module data and the module type to the -:ref:`Normal Action ` which continues execution of -the module. - -Assembler frameworks --------------------- - -Ansible supports two assembler frameworks: Ansiballz and the older Module Replacer. - -.. _module_replacer: - -Module Replacer framework -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The Module Replacer framework is the original framework implementing new-style -modules, and is still used for PowerShell modules. It is essentially a preprocessor (like the C Preprocessor for those -familiar with that programming language). It does straight substitutions of -specific substring patterns in the module file. There are two types of -substitutions: - -* Replacements that only happen in the module file. These are public - replacement strings that modules can utilize to get helpful boilerplate or - access to arguments. - - - :code:`from ansible.module_utils.MOD_LIB_NAME import *` is replaced with the - contents of the :file:`ansible/module_utils/MOD_LIB_NAME.py` These should - only be used with :ref:`new-style Python modules `. - - :code:`#<>` is equivalent to - :code:`from ansible.module_utils.basic import *` and should also only apply - to new-style Python modules. - - :code:`# POWERSHELL_COMMON` substitutes the contents of - :file:`ansible/module_utils/powershell.ps1`. It should only be used with - :ref:`new-style Powershell modules `. - -* Replacements that are used by ``ansible.module_utils`` code. These are internal replacement patterns. They may be used internally, in the above public replacements, but shouldn't be used directly by modules. - - - :code:`"<>"` is substituted with the Ansible version. In - :ref:`new-style Python modules ` under the - :ref:`Ansiballz` framework the proper way is to instead instantiate an - `AnsibleModule` and then access the version from - :attr:``AnsibleModule.ansible_version``. - - :code:`"<>"` is substituted with - a string which is the Python ``repr`` of the :term:`JSON` encoded module - parameters. Using ``repr`` on the JSON string makes it safe to embed in - a Python file. In new-style Python modules under the Ansiballz framework - this is better accessed by instantiating an `AnsibleModule` and - then using :attr:`AnsibleModule.params`. - - :code:`<>` substitutes a string which is - a comma-separated list of file systems which have a file system dependent - security context in SELinux. In new-style Python modules, if you really - need this you should instantiate an `AnsibleModule` and then use - :attr:`AnsibleModule._selinux_special_fs`. The variable has also changed - from a comma-separated string of file system names to an actual python - list of file system names. - - :code:`<>` substitutes the module - parameters as a JSON string. Care must be taken to properly quote the - string as JSON data may contain quotes. This pattern is not substituted - in new-style Python modules as they can get the module parameters another - way. - - The string :code:`syslog.LOG_USER` is replaced wherever it occurs with the - ``syslog_facility`` which was named in :file:`ansible.cfg` or any - ``ansible_syslog_facility`` inventory variable that applies to this host. In - new-style Python modules this has changed slightly. If you really need to - access it, you should instantiate an `AnsibleModule` and then use - :attr:`AnsibleModule._syslog_facility` to access it. It is no longer the - actual syslog facility and is now the name of the syslog facility. See - the :ref:`documentation on internal arguments ` - for details. - -.. _Ansiballz: - -Ansiballz framework -^^^^^^^^^^^^^^^^^^^ - -The Ansiballz framework was adopted in Ansible 2.1 and is used for all new-style Python modules. Unlike the Module Replacer, Ansiballz uses real Python imports of things in -:file:`ansible/module_utils` instead of merely preprocessing the module. It -does this by constructing a zipfile -- which includes the module file, files -in :file:`ansible/module_utils` that are imported by the module, and some -boilerplate to pass in the module's parameters. The zipfile is then Base64 -encoded and wrapped in a small Python script which decodes the Base64 encoding -and places the zipfile into a temp directory on the managed node. It then -extracts just the Ansible module script from the zip file and places that in -the temporary directory as well. Then it sets the PYTHONPATH to find Python -modules inside of the zip file and imports the Ansible module as the special name, ``__main__``. -Importing it as ``__main__`` causes Python to think that it is executing a script rather than simply -importing a module. This lets Ansible run both the wrapper script and the module code in a single copy of Python on the remote machine. - -.. note:: - * Ansible wraps the zipfile in the Python script for two reasons: - - * for compatibility with Python 2.6 which has a less - functional version of Python's ``-m`` command-line switch. - - * so that pipelining will function properly. Pipelining needs to pipe the - Python module into the Python interpreter on the remote node. Python - understands scripts on stdin but does not understand zip files. - - * Prior to Ansible 2.7, the module was executed by a second Python interpreter instead of being - executed inside of the same process. This change was made once Python-2.4 support was dropped - to speed up module execution. - -In Ansiballz, any imports of Python modules from the -:py:mod:`ansible.module_utils` package trigger inclusion of that Python file -into the zipfile. Instances of :code:`#<>` in -the module are turned into :code:`from ansible.module_utils.basic import *` -and :file:`ansible/module-utils/basic.py` is then included in the zipfile. -Files that are included from :file:`module_utils` are themselves scanned for -imports of other Python modules from :file:`module_utils` to be included in -the zipfile as well. - - -.. _flow_passing_module_args: - -Passing args ------------- - -Arguments are passed differently by the two frameworks: - -* In :ref:`module_replacer`, module arguments are turned into a JSON-ified string and substituted into the combined module file. -* In :ref:`Ansiballz`, the JSON-ified string is part of the script which wraps the zipfile. Just before the wrapper script imports the Ansible module as ``__main__``, it monkey-patches the private, ``_ANSIBLE_ARGS`` variable in ``basic.py`` with the variable values. When a :class:`ansible.module_utils.basic.AnsibleModule` is instantiated, it parses this string and places the args into :attr:`AnsibleModule.params` where it can be accessed by the module's other code. - -.. warning:: - If you are writing modules, remember that the way we pass arguments is an internal implementation detail: it has changed in the past and will change again as soon as changes to the common module_utils - code allow Ansible modules to forgo using :class:`ansible.module_utils.basic.AnsibleModule`. Do not rely on the internal global ``_ANSIBLE_ARGS`` variable. - - Very dynamic custom modules which need to parse arguments before they - instantiate an ``AnsibleModule`` may use ``_load_params`` to retrieve those parameters. - Although ``_load_params`` may change in breaking ways if necessary to support - changes in the code, it is likely to be more stable than either the way we pass parameters or the internal global variable. - -.. note:: - Prior to Ansible 2.7, the Ansible module was invoked in a second Python interpreter and the - arguments were then passed to the script over the script's stdin. - - -.. _flow_internal_arguments: - -Internal arguments ------------------- - -Both :ref:`module_replacer` and :ref:`Ansiballz` send additional arguments to -the Ansible module beyond those which the user specified in the playbook. These -additional arguments are internal parameters that help implement global -Ansible features. Modules often do not need to know about these explicitly because -the features are implemented in :py:mod:`ansible.module_utils.basic`. However, certain -features need support from modules and some knowledge of the internal arguments is useful. - -The internal arguments in this section are global. If you need to add a local internal argument to a custom module, create an action plugin for that specific module. See ``_original_basename`` in the `copy action plugin `_ for an example. - - -_ansible_no_log -^^^^^^^^^^^^^^^ - -Type: ``bool`` - -Set to ``True`` whenever an argument in a task or play specifies ``no_log``. Any module that calls the :py:meth:`AnsibleModule.log` function handles this action automatically. If you have a module that implements its own logging then you need to check the value of ``_ansible_no_log``. To access ``_ansible_no_log`` in a module, instantiate the ``AnsibleModule`` utility and then check the value of :attr:`AnsibleModule.no_log`. - -.. note:: - ``no_log`` specified in a module's ``argument_spec`` is handled by a different mechanism. - - -_ansible_debug -^^^^^^^^^^^^^^ - -Type: ``bool`` - -Operates verbose logging and logging of external commands that a module executes. If the module uses the :py:meth:`AnsibleModule.debug` function rather than the :py:meth:`AnsibleModule.log` function then the messages are only logged if you set the ``_ansible_debug`` argument to ``True``. To access ``_ansible_debug`` in a module, instantiate the ``AnsibleModule`` utility and access :attr:`AnsibleModule._debug`. For more details, see :ref:`DEFAULT_DEBUG`. - - -_ansible_diff -^^^^^^^^^^^^^ - -Type: ``bool`` - -With this parameter you can configure your module to show a unified diff of changes that will be applied to the templated files. To access ``_ansible_diff`` in a module, instantiate the ``AnsibleModule`` utility and access :attr:`AnsibleModule._diff`. You can also access this parameter using the ``diff`` keyword in your playbook, or the relevant environment variable. For more details, see :ref:`playbook_keywords` and the :ref:`DIFF_ALWAYS` configuration option. - - -_ansible_verbosity -^^^^^^^^^^^^^^^^^^ - -Type: ``int`` - -You can use this argument to control the level (0 for none) of verbosity in logging. - - -_ansible_selinux_special_fs -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Type: ``list`` -Elements: ``strings`` - -This argument provides modules with the names of file systems which should have a special SELinux context. They are used by the ``AnsibleModule`` methods which operate on files (changing attributes, moving, and copying). - -Most modules can use the built-in ``AnsibleModule`` methods to manipulate files. To access in a module that needs to know about these special context file systems, instantiate ``AnsibleModule`` and examine the list in :attr:`AnsibleModule._selinux_special_fs`. - -This argument replaces :attr:`ansible.module_utils.basic.SELINUX_SPECIAL_FS` from :ref:`module_replacer`. In the module replacer framework the argument was formatted as a comma-separated string of file system names. Under the Ansiballz framework it is a list. You can access ``_ansible_selinux_special_fs`` using the corresponding environment variable. For more details, see the :ref:`DEFAULT_SELINUX_SPECIAL_FS` configuration option. - -.. versionadded:: 2.1 - - -_ansible_syslog_facility -^^^^^^^^^^^^^^^^^^^^^^^^ - -This argument controls which syslog facility the module logs to. Most modules should just use the :meth:`AnsibleModule.log` function which will then make use of this. If a module has to use this on its own, it should instantiate the ``AnsibleModule`` method and then retrieve the name of the syslog facility from :attr:`AnsibleModule._syslog_facility`. The Ansiballz code is less elegant than the :ref:`module_replacer` code: - -.. code-block:: python - - # Old module_replacer way - import syslog - syslog.openlog(NAME, 0, syslog.LOG_USER) - - # New Ansiballz way - import syslog - facility_name = module._syslog_facility - facility = getattr(syslog, facility_name, syslog.LOG_USER) - syslog.openlog(NAME, 0, facility) - -For more details, see the :ref:`DEFAULT_SYSLOG_FACILITY` configuration option. - -.. versionadded:: 2.1 - - -_ansible_version -^^^^^^^^^^^^^^^^ - -This argument passes the version of Ansible to the module. To access it, a module should instantiate the ``AnsibleModule`` method and then retrieve the version from :attr:`AnsibleModule.ansible_version`. This replaces :attr:`ansible.module_utils.basic.ANSIBLE_VERSION` from :ref:`module_replacer`. - -.. versionadded:: 2.1 - - -_ansible_module_name -^^^^^^^^^^^^^^^^^^^^ - -Type: ``str`` - -This argument passes the information to modules about their name. For more details see, the configuration option :ref:`DEFAULT_MODULE_NAME`. - - -_ansible_string_conversion_action -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -This argument provides instructions about what modules should do after the values of the user-specified module parameters are converted to strings. For more details, see the :ref:`STRING_CONVERSION_ACTION` configuration option. - - -_ansible_keep_remote_files -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Type: ``bool`` - -This argument provides instructions that modules must be ready if they need to keep the remote files. For more details, see the :ref:`DEFAULT_KEEP_REMOTE_FILES` configuration option. - - -_ansible_socket -^^^^^^^^^^^^^^^ -This argument provides modules with a socket for persistent connections. The argument is created using the :ref:`PERSISTENT_CONTROL_PATH_DIR` configuration option. - - -_ansible_shell_executable -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Type: ``bool`` - -This argument ensures that modules use the designated shell executable. For more details, see the :ref:`ansible_shell_executable` remote host environment parameter. - - -_ansible_tmpdir -^^^^^^^^^^^^^^^ - -Type: ``str`` - -This argument provides instructions to modules that all commands must use the designated temporary directory, if created. The action plugin designs this temporary directory. - -Modules can access this parameter by using the public ``tmpdir`` property. The ``tmpdir`` property will create a temporary directory if the action plugin did not set the parameter. - -The directory name is generated randomly, and the the root of the directory is determined by one of these: - -* :ref:`DEFAULT_LOCAL_TMP` -* `remote_tmp `_ -* `system_tmpdirs `_ - -As a result, using the ``ansible.cfg`` configuration file to activate or customize this setting will not guarantee that you control the full value. - - -_ansible_remote_tmp -^^^^^^^^^^^^^^^^^^^ - -The module's ``tmpdir`` property creates a randomized directory name in this directory if the action plugin did not set ``_ansible_tmpdir``. For more details, see the `remote_tmp `_ parameter of the shell plugin. - - -.. _flow_module_return_values: - -Module return values & Unsafe strings -------------------------------------- - -At the end of a module's execution, it formats the data that it wants to return as a JSON string and prints the string to its stdout. The normal action plugin receives the JSON string, parses it into a Python dictionary, and returns it to the executor. - -If Ansible templated every string return value, it would be vulnerable to an attack from users with access to managed nodes. If an unscrupulous user disguised malicious code as Ansible return value strings, and if those strings were then templated on the controller, Ansible could execute arbitrary code. To prevent this scenario, Ansible marks all strings inside returned data as ``Unsafe``, emitting any Jinja2 templates in the strings verbatim, not expanded by Jinja2. - -Strings returned by invoking a module through ``ActionPlugin._execute_module()`` are automatically marked as ``Unsafe`` by the normal action plugin. If another action plugin retrieves information from a module through some other means, it must mark its return data as ``Unsafe`` on its own. - -In case a poorly-coded action plugin fails to mark its results as "Unsafe," Ansible audits the results again when they are returned to the executor, -marking all strings as ``Unsafe``. The normal action plugin protects itself and any other code that it calls with the result data as a parameter. The check inside the executor protects the output of all other action plugins, ensuring that subsequent tasks run by Ansible will not template anything from those results either. - -.. _flow_special_considerations: - -Special considerations ----------------------- - -.. _flow_pipelining: - -Pipelining -^^^^^^^^^^ - -Ansible can transfer a module to a remote machine in one of two ways: - -* it can write out the module to a temporary file on the remote host and then - use a second connection to the remote host to execute it with the - interpreter that the module needs -* or it can use what's known as pipelining to execute the module by piping it - into the remote interpreter's stdin. - -Pipelining only works with modules written in Python at this time because -Ansible only knows that Python supports this mode of operation. Supporting -pipelining means that whatever format the module payload takes before being -sent over the wire must be executable by Python through stdin. - -.. _flow_args_over_stdin: - -Why pass args over stdin? -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Passing arguments through stdin was chosen for the following reasons: - -* When combined with :ref:`ANSIBLE_PIPELINING`, this keeps the module's arguments from - temporarily being saved onto disk on the remote machine. This makes it - harder (but not impossible) for a malicious user on the remote machine to - steal any sensitive information that may be present in the arguments. -* Command line arguments would be insecure as most systems allow unprivileged - users to read the full commandline of a process. -* Environment variables are usually more secure than the commandline but some - systems limit the total size of the environment. This could lead to - truncation of the parameters if we hit that limit. - - -.. _flow_ansiblemodule: - -AnsibleModule -------------- - -.. _argument_spec: - -Argument spec -^^^^^^^^^^^^^ - -The ``argument_spec`` provided to ``AnsibleModule`` defines the supported arguments for a module, as well as their type, defaults and more. - -Example ``argument_spec``: - -.. code-block:: python - - module = AnsibleModule(argument_spec=dict( - top_level=dict( - type='dict', - options=dict( - second_level=dict( - default=True, - type='bool', - ) - ) - ) - )) - -This section will discuss the behavioral attributes for arguments: - -:type: - - ``type`` allows you to define the type of the value accepted for the argument. The default value for ``type`` is ``str``. Possible values are: - - * str - * list - * dict - * bool - * int - * float - * path - * raw - * jsonarg - * json - * bytes - * bits - - The ``raw`` type, performs no type validation or type casting, and maintains the type of the passed value. - -:elements: - - ``elements`` works in combination with ``type`` when ``type='list'``. ``elements`` can then be defined as ``elements='int'`` or any other type, indicating that each element of the specified list should be of that type. - -:default: - - The ``default`` option allows sets a default value for the argument for the scenario when the argument is not provided to the module. When not specified, the default value is ``None``. - -:fallback: - - ``fallback`` accepts a ``tuple`` where the first argument is a callable (function) that will be used to perform the lookup, based on the second argument. The second argument is a list of values to be accepted by the callable. - - The most common callable used is ``env_fallback`` which will allow an argument to optionally use an environment variable when the argument is not supplied. - - Example: - - .. code-block:: python - - username=dict(fallback=(env_fallback, ['ANSIBLE_NET_USERNAME'])) - -:choices: - - ``choices`` accepts a list of choices that the argument will accept. The types of ``choices`` should match the ``type``. - -:required: - - ``required`` accepts a boolean, either ``True`` or ``False`` that indicates that the argument is required. When not specified, ``required`` defaults to ``False``. This should not be used in combination with ``default``. - -:no_log: - - ``no_log`` accepts a boolean, either ``True`` or ``False``, that indicates explicitly whether or not the argument value should be masked in logs and output. - - .. note:: - In the absence of ``no_log``, if the parameter name appears to indicate that the argument value is a password or passphrase (such as "admin_password"), a warning will be shown and the value will be masked in logs but **not** output. To disable the warning and masking for parameters that do not contain sensitive information, set ``no_log`` to ``False``. - -:aliases: - - ``aliases`` accepts a list of alternative argument names for the argument, such as the case where the argument is ``name`` but the module accepts ``aliases=['pkg']`` to allow ``pkg`` to be interchangeably with ``name`` - -:options: - - ``options`` implements the ability to create a sub-argument_spec, where the sub options of the top level argument are also validated using the attributes discussed in this section. The example at the top of this section demonstrates use of ``options``. ``type`` or ``elements`` should be ``dict`` is this case. - -:apply_defaults: - - ``apply_defaults`` works alongside ``options`` and allows the ``default`` of the sub-options to be applied even when the top-level argument is not supplied. - - In the example of the ``argument_spec`` at the top of this section, it would allow ``module.params['top_level']['second_level']`` to be defined, even if the user does not provide ``top_level`` when calling the module. - -:removed_in_version: - - ``removed_in_version`` indicates which version of ansible-core or a collection a deprecated argument will be removed in. Mutually exclusive with ``removed_at_date``, and must be used with ``removed_from_collection``. - - Example: - - .. code-block:: python - - option = { - 'type': 'str', - 'removed_in_version': '2.0.0', - 'removed_from_collection': 'testns.testcol', - }, - -:removed_at_date: - - ``removed_at_date`` indicates that a deprecated argument will be removed in a minor ansible-core release or major collection release after this date. Mutually exclusive with ``removed_in_version``, and must be used with ``removed_from_collection``. - - Example: - - .. code-block:: python - - option = { - 'type': 'str', - 'removed_at_date': '2020-12-31', - 'removed_from_collection': 'testns.testcol', - }, - -:removed_from_collection: - - Specifies which collection (or ansible-core) deprecates this deprecated argument. Specify ``ansible.builtin`` for ansible-core, or the collection's name (format ``foo.bar``). Must be used with ``removed_in_version`` or ``removed_at_date``. - -:deprecated_aliases: - - Deprecates aliases of this argument. Must contain a list or tuple of dictionaries having some the following keys: - - :name: - - The name of the alias to deprecate. (Required.) - - :version: - - The version of ansible-core or the collection this alias will be removed in. Either ``version`` or ``date`` must be specified. - - :date: - - The a date after which a minor release of ansible-core or a major collection release will no longer contain this alias.. Either ``version`` or ``date`` must be specified. - - :collection_name: - - Specifies which collection (or ansible-core) deprecates this deprecated alias. Specify ``ansible.builtin`` for ansible-core, or the collection's name (format ``foo.bar``). Must be used with ``version`` or ``date``. - - Examples: - - .. code-block:: python - - option = { - 'type': 'str', - 'aliases': ['foo', 'bar'], - 'depecated_aliases': [ - { - 'name': 'foo', - 'version': '2.0.0', - 'collection_name': 'testns.testcol', - }, - { - 'name': 'foo', - 'date': '2020-12-31', - 'collection_name': 'testns.testcol', - }, - ], - }, - - -:mutually_exclusive: - - If ``options`` is specified, ``mutually_exclusive`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`. - -:required_together: - - If ``options`` is specified, ``required_together`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`. - -:required_one_of: - - If ``options`` is specified, ``required_one_of`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`. - -:required_if: - - If ``options`` is specified, ``required_if`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`. - -:required_by: - - If ``options`` is specified, ``required_by`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`. - - -.. _argument_spec_dependencies: - -Dependencies between module options -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following are optional arguments for ``AnsibleModule()``: - -.. code-block:: python - - module = AnsibleModule( - argument_spec, - mutually_exclusive=[ - ('path', 'content'), - ], - required_one_of=[ - ('path', 'content'), - ], - ) - -:mutually_exclusive: - - Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names which are mutually exclusive. If more than one options of a list are specified together, Ansible will fail the module with an error. - - Example: - - .. code-block:: python - - mutually_exclusive=[ - ('path', 'content'), - ('repository_url', 'repository_filename'), - ], - - In this example, the options ``path`` and ``content`` must not specified at the same time. Also the options ``repository_url`` and ``repository_filename`` must not be specified at the same time. But specifying ``path`` and ``repository_url`` is accepted. - - To ensure that precisely one of two (or more) options is specified, combine ``mutually_exclusive`` with ``required_one_of``. - -:required_together: - - Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names which are must be specified together. If at least one of these options are specified, the other ones from the same sequence must all be present. - - Example: - - .. code-block:: python - - required_together=[ - ('file_path', 'file_hash'), - ], - - In this example, if one of the options ``file_path`` or ``file_hash`` is specified, Ansible will fail the module with an error if the other one is not specified. - -:required_one_of: - - Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names from which at least one must be specified. If none one of these options are specified, Ansible will fail module execution. - - Example: - - .. code-block:: python - - required_one_of=[ - ('path', 'content'), - ], - - In this example, at least one of ``path`` and ``content`` must be specified. If none are specified, execution will fail. Specifying both is explicitly allowed; to prevent this, combine ``required_one_of`` with ``mutually_exclusive``. - -:required_if: - - Must be a sequence of sequences. Every inner sequence describes one conditional dependency. Every sequence must have three or four values. The first two values are the option's name and the option's value which describes the condition. The further elements of the sequence are only needed if the option of that name has precisely this value. - - If you want that all options in a list of option names are specified if the condition is met, use one of the following forms: - - .. code-block:: python - - ('option_name', option_value, ('option_a', 'option_b', ...)), - ('option_name', option_value, ('option_a', 'option_b', ...), False), - - If you want that at least one option of a list of option names is specified if the condition is met, use the following form: - - .. code-block:: python - - ('option_name', option_value, ('option_a', 'option_b', ...), True), - - Example: - - .. code-block:: python - - required_if=[ - ('state', 'present', ('path', 'content'), True), - ('force', True, ('force_reason', 'force_code')), - ], - - In this example, if the user specifies ``state=present``, at least one of the options ``path`` and ``content`` must be supplied (or both). To make sure that precisely one can be specified, combine ``required_if`` with ``mutually_exclusive``. - - On the other hand, if ``force`` (a boolean parameter) is set to ``true``, ``yes`` and so on, both ``force_reason`` and ``force_code`` must be specified. - -:required_by: - - Must be a dictionary mapping option names to sequences of option names. If the option name in a dictionary key is specified, the option names it maps to must all also be specified. Note that instead of a sequence of option names, you can also specify one single option name. - - Example: - - .. code-block:: python - - required_by={ - 'force': 'force_reason', - 'path': ('mode', 'owner', 'group'), - }, - - In the example, if ``force`` is specified, ``force_reason`` must also be specified. Also, if ``path`` is specified, then three three options ``mode``, ``owner`` and ``group`` also must be specified. - -Declaring check mode support -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To declare that a module supports check mode, supply ``supports_check_mode=True`` to the ``AnsibleModule()`` call: - -.. code-block:: python - - module = AnsibleModule(argument_spec, supports_check_mode=True) - -The module can determine whether it is called in check mode by checking the boolean value ``module.check_mode``. If it evaluates to ``True``, the module must take care not to do any modification. - -If ``supports_check_mode=False`` is specified, which is the default value, the module will exit in check mode with ``skipped=True`` and message ``remote module () does not support check mode``. - -Adding file options -^^^^^^^^^^^^^^^^^^^ - -To declare that a module should add support for all common file options, supply ``add_file_common_args=True`` to the ``AnsibleModule()`` call: - -.. code-block:: python - - module = AnsibleModule(argument_spec, add_file_common_args=True) - -You can find `a list of all file options here `_. It is recommended that you make your ``DOCUMENTATION`` extend the doc fragment ``ansible.builtin.files`` (see :ref:`module_docs_fragments`) in this case, to make sure that all these fields are correctly documented. - -The helper functions ``module.load_file_common_arguments()`` and ``module.set_fs_attributes_if_different()`` can be used to handle these arguments for you: - -.. code-block:: python - - argument_spec = { - 'path': { - 'type': 'str', - 'required': True, - }, - } - - module = AnsibleModule(argument_spec, add_file_common_args=True) - changed = False - - # TODO do something with module.params['path'], like update it's contents - - # Ensure that module.params['path'] satisfies the file options supplied by the user - file_args = module.load_file_common_arguments(module.params) - changed = module.set_fs_attributes_if_different(file_args, changed) - - module.exit_json(changed=changed) diff --git a/docs/docsite/rst/dev_guide/developing_python_3.rst b/docs/docsite/rst/dev_guide/developing_python_3.rst deleted file mode 100644 index 74385c43f9d..00000000000 --- a/docs/docsite/rst/dev_guide/developing_python_3.rst +++ /dev/null @@ -1,393 +0,0 @@ -.. _developing_python_3: - -******************** -Ansible and Python 3 -******************** - -The ``ansible-core`` code runs Python 3 (for specific versions check :ref:`Control Node Requirements ` -Contributors to ``ansible-core`` and to Ansible Collections should be aware of the tips in this document so that they can write code -that will run on the same versions of Python as the rest of Ansible. - -.. contents:: - :local: - -We do have some considerations depending on the types of Ansible code: - -1. controller-side code - code that runs on the machine where you invoke :command:`/usr/bin/ansible`, only needs to support the controller's Python versions. -2. modules - the code which Ansible transmits to and invokes on the managed machine. Modules need to support the 'managed node' Python versions, with some exceptions. -3. shared ``module_utils`` code - the common code that is used by modules to perform tasks and sometimes used by controller-side code as well. Shared ``module_utils`` code needs to support the same range of Python as the modules. - -However, the three types of code do not use the same string strategy. If you're developing a module or some ``module_utils`` code, be sure to read the section on string strategy carefully. - -.. note: - - While modules can be written in any language, the above applies to code contributed to the core project, which only supports specific Python versions and Powershell for Windows. - -Minimum version of Python 3.x and Python 2.x -============================================ - -See :ref:`Control Node Requirements ` and :ref:`Managed Node Requirements ` for the -specific versions supported. - -Your custom modules can support any version of Python (or other languages) you want, but the above are the requirements for the code contributed to the Ansible project. - -Developing Ansible code that supports Python 2 and Python 3 -=========================================================== - -The best place to start learning about writing code that supports both Python 2 and Python 3 -is `Lennart Regebro's book: Porting to Python 3 `_. -The book describes several strategies for porting to Python 3. The one we're -using is `to support Python 2 and Python 3 from a single code base -`_ - -Understanding strings in Python 2 and Python 3 ----------------------------------------------- - -Python 2 and Python 3 handle strings differently, so when you write code that supports Python 3 -you must decide what string model to use. Strings can be an array of bytes (like in C) or -they can be an array of text. Text is what we think of as letters, digits, -numbers, other printable symbols, and a small number of unprintable "symbols" -(control codes). - -In Python 2, the two types for these (:class:`str ` for bytes and -:func:`unicode ` for text) are often used interchangeably. When dealing only -with ASCII characters, the strings can be combined, compared, and converted -from one type to another automatically. When non-ASCII characters are -introduced, Python 2 starts throwing exceptions due to not knowing what encoding -the non-ASCII characters should be in. - -Python 3 changes this behavior by making the separation between bytes (:class:`bytes `) -and text (:class:`str `) more strict. Python 3 will throw an exception when -trying to combine and compare the two types. The programmer has to explicitly -convert from one type to the other to mix values from each. - -In Python 3 it's immediately apparent to the programmer when code is -mixing the byte and text types inappropriately, whereas in Python 2, code that mixes those types -may work until a user causes an exception by entering non-ASCII input. -Python 3 forces programmers to proactively define a strategy for -working with strings in their program so that they don't mix text and byte strings unintentionally. - -Ansible uses different strategies for working with strings in controller-side code, in -:ref: `modules `, and in :ref:`module_utils ` code. - -.. _controller_string_strategy: - -Controller string strategy: the Unicode Sandwich -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Until recently ``ansible-core`` supported Python 2.x and followed this strategy, known as the Unicode Sandwich (named -after Python 2's :func:`unicode ` text type). For Unicode Sandwich we know that -at the border of our code and the outside world (for example, file and network IO, -environment variables, and some library calls) we are going to receive bytes. -We need to transform these bytes into text and use that throughout the -internal portions of our code. When we have to send those strings back out to -the outside world we first convert the text back into bytes. -To visualize this, imagine a 'sandwich' consisting of a top and bottom layer -of bytes, a layer of conversion between, and all text type in the center. - -For compatibility reasons you will see a bunch of custom functions we developed (``to_text``/``to_bytes``/``to_native``) -and while Python 2 is not a concern anymore we will continue to use them as they apply for other cases that make -dealing with unicode problematic. - -While we will not be using it most of it anymore, the documentation below is still useful for those developing modules -that still need to support both Python 2 and 3 simultaneously. - -Unicode Sandwich common borders: places to convert bytes to text in controller code ------------------------------------------------------------------------------------ - -This is a partial list of places where we have to convert to and from bytes -when using the Unicode Sandwich string strategy. It's not exhaustive but -it gives you an idea of where to watch for problems. - -Reading and writing to files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In Python 2, reading from files yields bytes. In Python 3, it can yield text. -To make code that's portable to both we don't make use of Python 3's ability -to yield text but instead do the conversion explicitly ourselves. For example: - -.. code-block:: python - - from ansible.module_utils.common.text.converters import to_text - - with open('filename-with-utf8-data.txt', 'rb') as my_file: - b_data = my_file.read() - try: - data = to_text(b_data, errors='surrogate_or_strict') - except UnicodeError: - # Handle the exception gracefully -- usually by displaying a good - # user-centric error message that can be traced back to this piece - # of code. - pass - -.. note:: Much of Ansible assumes that all encoded text is UTF-8. At some - point, if there is demand for other encodings we may change that, but for - now it is safe to assume that bytes are UTF-8. - -Writing to files is the opposite process: - -.. code-block:: python - - from ansible.module_utils.common.text.converters import to_bytes - - with open('filename.txt', 'wb') as my_file: - my_file.write(to_bytes(some_text_string)) - -Note that we don't have to catch :exc:`UnicodeError` here because we're -transforming to UTF-8 and all text strings in Python can be transformed back -to UTF-8. - -Filesystem interaction -^^^^^^^^^^^^^^^^^^^^^^ - -Dealing with filenames often involves dropping back to bytes because on UNIX-like -systems filenames are bytes. On Python 2, if we pass a text string to these -functions, the text string will be converted to a byte string inside of the -function and a traceback will occur if non-ASCII characters are present. In -Python 3, a traceback will only occur if the text string can't be decoded in -the current locale, but it's still good to be explicit and have code which -works on both versions: - -.. code-block:: python - - import os.path - - from ansible.module_utils.common.text.converters import to_bytes - - filename = u'/var/tmp/くらとみ.txt' - f = open(to_bytes(filename), 'wb') - mtime = os.path.getmtime(to_bytes(filename)) - b_filename = os.path.expandvars(to_bytes(filename)) - if os.path.exists(to_bytes(filename)): - pass - -When you are only manipulating a filename as a string without talking to the -filesystem (or a C library which talks to the filesystem) you can often get -away without converting to bytes: - -.. code-block:: python - - import os.path - - os.path.join(u'/var/tmp/café', u'くらとみ') - os.path.split(u'/var/tmp/café/くらとみ') - -On the other hand, if the code needs to manipulate the filename and also talk -to the filesystem, it can be more convenient to transform to bytes right away -and manipulate in bytes. - -.. warning:: Make sure all variables passed to a function are the same type. - If you're working with something like :func:`python3:os.path.join` which takes - multiple strings and uses them in combination, you need to make sure that - all the types are the same (either all bytes or all text). Mixing - bytes and text will cause tracebacks. - -Interacting with other programs -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Interacting with other programs goes through the operating system and -C libraries and operates on things that the UNIX kernel defines. These -interfaces are all byte-oriented so the Python interface is byte oriented as -well. On both Python 2 and Python 3, byte strings should be given to Python's -subprocess library and byte strings should be expected back from it. - -One of the main places in Ansible's controller code that we interact with -other programs is the connection plugins' ``exec_command`` methods. These -methods transform any text strings they receive in the command (and arguments -to the command) to execute into bytes and return stdout and stderr as byte strings -Higher level functions (like action plugins' ``_low_level_execute_command``) -transform the output into text strings. - -.. _module_string_strategy: - -Module string strategy: Native String -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In modules we use a strategy known as Native Strings. This makes things -easier on the community members who maintain so many of Ansible's -modules, by not breaking backwards compatibility by -mandating that all strings inside of modules are text and converting between -text and bytes at the borders. - -Native strings refer to the type that Python uses when you specify a bare -string literal: - -.. code-block:: python - - "This is a native string" - -In Python 2, these are byte strings. In Python 3 these are text strings. Modules should be -coded to expect bytes on Python 2 and text on Python 3. - -.. _module_utils_string_strategy: - -Module_utils string strategy: hybrid -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In ``module_utils`` code we use a hybrid string strategy. Although Ansible's -``module_utils`` code is largely like module code, some pieces of it are -used by the controller as well. So it needs to be compatible with modules -and with the controller's assumptions, particularly the string strategy. -The module_utils code attempts to accept native strings as input -to its functions and emit native strings as their output. - -In ``module_utils`` code: - -* Functions **must** accept string parameters as either text strings or byte strings. -* Functions may return either the same type of string as they were given or the native string type for the Python version they are run on. -* Functions that return strings **must** document whether they return strings of the same type as they were given or native strings. - -Module-utils functions are therefore often very defensive in nature. -They convert their string parameters into text (using ``ansible.module_utils.common.text.converters.to_text``) -at the beginning of the function, do their work, and then convert -the return values into the native string type (using ``ansible.module_utils.common.text.converters.to_native``) -or back to the string type that their parameters received. - -Tips, tricks, and idioms for Python 2/Python 3 compatibility ------------------------------------------------------------- - -Use forward-compatibility boilerplate -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use the following boilerplate code at the top of all python files -to make certain constructs act the same way on Python 2 and Python 3: - -.. code-block:: python - - # Make coding more python3-ish - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type - -``__metaclass__ = type`` makes all classes defined in the file into new-style -classes without explicitly inheriting from :class:`object `. - -The ``__future__`` imports do the following: - -:absolute_import: Makes imports look in :data:`sys.path ` for the modules being - imported, skipping the directory in which the module doing the importing - lives. If the code wants to use the directory in which the module doing - the importing, there's a new dot notation to do so. -:division: Makes division of integers always return a float. If you need to - find the quotient use ``x // y`` instead of ``x / y``. -:print_function: Changes :func:`print ` from a keyword into a function. - -.. seealso:: - * `PEP 0328: Absolute Imports `_ - * `PEP 0238: Division `_ - * `PEP 3105: Print function `_ - -Prefix byte strings with ``b_`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Since mixing text and bytes types leads to tracebacks we want to be clear -about what variables hold text and what variables hold bytes. We do this by -prefixing any variable holding bytes with ``b_``. For instance: - -.. code-block:: python - - filename = u'/var/tmp/café.txt' - b_filename = to_bytes(filename) - with open(b_filename) as f: - data = f.read() - -We do not prefix the text strings instead because we only operate -on byte strings at the borders, so there are fewer variables that need bytes -than text. - -Import Ansible's bundled Python ``six`` library -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The third-party Python `six `_ library exists -to help projects create code that runs on both Python 2 and Python 3. Ansible -includes a version of the library in module_utils so that other modules can use it -without requiring that it is installed on the remote system. To make use of -it, import it like this: - -.. code-block:: python - - from ansible.module_utils import six - -.. note:: Ansible can also use a system copy of six - - Ansible will use a system copy of six if the system copy is a later - version than the one Ansible bundles. - -Handle exceptions with ``as`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In order for code to function on Python 2.6+ and Python 3, use the -new exception-catching syntax which uses the ``as`` keyword: - -.. code-block:: python - - try: - a = 2/0 - except ValueError as e: - module.fail_json(msg="Tried to divide by zero: %s" % e) - -Do **not** use the following syntax as it will fail on every version of Python 3: - -.. This code block won't highlight because python2 isn't recognized. This is necessary to pass tests under python 3. -.. code-block:: none - - try: - a = 2/0 - except ValueError, e: - module.fail_json(msg="Tried to divide by zero: %s" % e) - -Update octal numbers -^^^^^^^^^^^^^^^^^^^^ - -In Python 2.x, octal literals could be specified as ``0755``. In Python 3, -octals must be specified as ``0o755``. - -String formatting for controller code -------------------------------------- - -Use ``str.format()`` for Python 2.6 compatibility -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Starting in Python 2.6, strings gained a method called ``format()`` to put -strings together. However, one commonly used feature of ``format()`` wasn't -added until Python 2.7, so you need to remember not to use it in Ansible code: - -.. code-block:: python - - # Does not work in Python 2.6! - new_string = "Dear {}, Welcome to {}".format(username, location) - - # Use this instead - new_string = "Dear {0}, Welcome to {1}".format(username, location) - -Both of the format strings above map positional arguments of the ``format()`` -method into the string. However, the first version doesn't work in -Python 2.6. Always remember to put numbers into the placeholders so the code -is compatible with Python 2.6. - -.. seealso:: - Python documentation on format strings: - - - `format strings in 2.6 `_ - - `format strings in 3.x `_ - -Use percent format with byte strings -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In Python 3.x, byte strings do not have a ``format()`` method. However, it -does have support for the older, percent-formatting. - -.. code-block:: python - - b_command_line = b'ansible-playbook --become-user %s -K %s' % (user, playbook_file) - -.. note:: Percent formatting added in Python 3.5 - - Percent formatting of byte strings was added back into Python 3 in 3.5. - This isn't a problem for us because Python 3.5 is our minimum version. - However, if you happen to be testing Ansible code with Python 3.4 or - earlier, you will find that the byte string formatting here won't work. - Upgrade to Python 3.5 to test. - -.. seealso:: - Python documentation on `percent formatting `_ - -.. _testing_modules_python_3: diff --git a/docs/docsite/rst/dev_guide/developing_rebasing.rst b/docs/docsite/rst/dev_guide/developing_rebasing.rst deleted file mode 100644 index dcd1fb07c43..00000000000 --- a/docs/docsite/rst/dev_guide/developing_rebasing.rst +++ /dev/null @@ -1,97 +0,0 @@ -.. _rebase_guide: - -*********************** -Rebasing a pull request -*********************** - -You may find that your pull request (PR) is out-of-date and needs to be rebased. This can happen for several reasons: - -- Files modified in your PR are in conflict with changes which have already been merged. -- Your PR is old enough that significant changes to automated test infrastructure have occurred. - -Rebasing the branch used to create your PR will resolve both of these issues. - -Configuring your remotes -======================== - -Before you can rebase your PR, you need to make sure you have the proper remotes configured. These instructions apply to any repository on GitHub, including collections repositories. On other platforms (bitbucket, gitlab), the same principles and commands apply but the syntax may be different. We use the ansible/ansible repository here as an example. In other repositories, the branch names may be different. Assuming you cloned your fork in the usual fashion, the ``origin`` remote will point to your fork: - -.. code-block:: shell-session - - $ git remote -v - origin git@github.com:YOUR_GITHUB_USERNAME/ansible.git (fetch) - origin git@github.com:YOUR_GITHUB_USERNAME/ansible.git (push) - -However, you also need to add a remote which points to the upstream repository: - -.. code-block:: shell-session - - $ git remote add upstream https://github.com/ansible/ansible.git - -Which should leave you with the following remotes: - -.. code-block:: shell-session - - $ git remote -v - origin git@github.com:YOUR_GITHUB_USERNAME/ansible.git (fetch) - origin git@github.com:YOUR_GITHUB_USERNAME/ansible.git (push) - upstream https://github.com/ansible/ansible.git (fetch) - upstream https://github.com/ansible/ansible.git (push) - -Checking the status of your branch should show your fork is up-to-date with the ``origin`` remote: - -.. code-block:: shell-session - - $ git status - On branch YOUR_BRANCH - Your branch is up-to-date with 'origin/YOUR_BRANCH'. - nothing to commit, working tree clean - -Rebasing your branch -==================== - -Once you have an ``upstream`` remote configured, you can rebase the branch for your PR: - -.. code-block:: shell-session - - $ git pull --rebase upstream devel - -This will replay the changes in your branch on top of the changes made in the upstream ``devel`` branch. -If there are merge conflicts, you will be prompted to resolve those before you can continue. - -After you rebase, the status of your branch changes: - -.. code-block:: shell-session - - $ git status - On branch YOUR_BRANCH - Your branch and 'origin/YOUR_BRANCH' have diverged, - and have 4 and 1 different commits each, respectively. - (use "git pull" to merge the remote branch into yours) - nothing to commit, working tree clean - -Don't worry, this is normal after a rebase. You should ignore the ``git status`` instructions to use ``git pull``. We'll cover what to do next in the following section. - -Updating your pull request -========================== - -Now that you've rebased your branch, you need to push your changes to GitHub to update your PR. - -Since rebasing re-writes git history, you will need to use a force push: - -.. code-block:: shell-session - - $ git push --force-with-lease - -Your PR on GitHub has now been updated. This will automatically trigger testing of your changes. -You should check in on the status of your PR after tests have completed to see if further changes are required. - -Getting help rebasing -===================== - -For help with rebasing your PR, or other development related questions, join us on the #ansible-devel chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). - -.. seealso:: - - :ref:`community_development_process` - Information on roadmaps, opening PRs, Ansibullbot, and more diff --git a/docs/docsite/rst/dev_guide/migrating_roles.rst b/docs/docsite/rst/dev_guide/migrating_roles.rst deleted file mode 100644 index ddf79c954ba..00000000000 --- a/docs/docsite/rst/dev_guide/migrating_roles.rst +++ /dev/null @@ -1,416 +0,0 @@ - -.. _migrating_roles: - -************************************************* -Migrating Roles to Roles in Collections on Galaxy -************************************************* - -You can migrate any existing standalone role into a collection and host the collection on Galaxy. With Ansible collections, you can distribute many roles in a single cohesive unit of re-usable automation. Inside a collection, you can share custom plugins across all roles in the collection instead of duplicating them in each role's :file:`library/`` directory. - -You must migrate roles to collections if you want to distribute them as certified Ansible content. - -.. note:: - - If you want to import your collection to Galaxy, you need a `Galaxy namespace `_. - -See :ref:`developing_collections` for details on collections. - - -.. contents:: - :local: - :depth: 1 - -Comparing standalone roles to collection roles -=============================================== - -:ref:`Standalone roles ` have the following directory structure: - -.. code-block:: bash - :emphasize-lines: 5,7,8 - - role/ - ├── defaults - ├── files - ├── handlers - ├── library - ├── meta - ├── module_utils - ├── [*_plugins] - ├── tasks - ├── templates - ├── tests - └── vars - - -The highlighted directories above will change when you migrate to a collection-based role. The collection directory structure includes a :file:`roles/` directory: - -.. code-block:: bash - - mynamespace/ - └── mycollection/ - ├── docs/ - ├── galaxy.yml - ├── plugins/ - │ ├── modules/ - │ │ └── module1.py - │ ├── inventory/ - │ └── .../ - ├── README.md - ├── roles/ - │ ├── role1/ - │ ├── role2/ - │ └── .../ - ├── playbooks/ - │ ├── files/ - │ ├── vars/ - │ ├── templates/ - │ └── tasks/ - └── tests/ - -You will need to use the Fully Qualified Collection Name (FQCN) to use the roles and plugins when you migrate your role into a collection. The FQCN is the combination of the collection ``namespace``, collection ``name``, and the content item you are referring to. - -So for example, in the above collection, the FQCN to access ``role1`` would be: - -.. code-block:: Python - - mynamespace.mycollection.role1 - - -A collection can contain one or more roles in the :file:`roles/` directory and these are almost identical to standalone roles, except you need to move plugins out of the individual roles, and use the :abbr:`FQCN (Fully Qualified Collection Name)` in some places, as detailed in the next section. - -.. note:: - - In standalone roles, some of the plugin directories referenced their plugin types in the plural sense; this is not the case in collections. - -.. _simple_roles_in_collections: - -Migrating a role to a collection -================================= - -To migrate from a standalone role that contains no plugins to a collection role: - -1. Create a local :file:`ansible_collections` directory and ``cd`` to this new directory. - -2. Create a collection. If you want to import this collection to Ansible Galaxy, you need a `Galaxy namespace `_. - -.. code-block:: bash - - $ ansible-galaxy collection init mynamespace.mycollection - -This creates the collection directory structure. - -3. Copy the standalone role directory into the :file:`roles/` subdirectory of the collection. Roles in collections cannot have hyphens in the role name. Rename any such roles to use underscores instead. - -.. code-block:: bash - - $ mkdir mynamespace/mycollection/roles/my_role/ - $ cp -r /path/to/standalone/role/mynamespace/my_role/\* mynamespace/mycollection/roles/my_role/ - -4. Update ``galaxy.yml`` to include any role dependencies. - -5. Update the collection README.md file to add links to any role README.md files. - -.. _complex_roles_in_collections: - -Migrating a role that contains plugins to a collection -====================================================== - -To migrate from a standalone role that has plugins to a collection role: - -1. Create a local :file:`ansible_collections directory` and ``cd`` to this new directory. - -2. Create a collection. If you want to import this collection to Ansible Galaxy, you need a `Galaxy namespace `_. - -.. code-block:: bash - - $ ansible-galaxy collection init mynamespace.mycollection - -This creates the collection directory structure. - -3. Copy the standalone role directory into the :file:`roles/` subdirectory of the collection. Roles in collections cannot have hyphens in the role name. Rename any such roles to use underscores instead. - -.. code-block:: bash - - $ mkdir mynamespace/mycollection/roles/my_role/ - $ cp -r /path/to/standalone/role/mynamespace/my_role/\* mynamespace/mycollection/roles/my_role/ - - -4. Move any modules to the :file:`plugins/modules/` directory. - -.. code-block:: bash - - $ mv -r mynamespace/mycollection/roles/my_role/library/\* mynamespace/mycollection/plugins/modules/ - -5. Move any other plugins to the appropriate :file:`plugins/PLUGINTYPE/` directory. See :ref:`migrating_plugins_collection` for additional steps that may be required. - -6. Update ``galaxy.yml`` to include any role dependencies. - -7. Update the collection README.md file to add links to any role README.md files. - -8. Change any references to the role to use the :abbr:`FQCN (Fully Qualified Collection Name)`. - -.. code-block:: yaml - - --- - - name: example role by FQCN - hosts: some_host_pattern - tasks: - - name: import FQCN role from a collection - import_role: - name: mynamespace.mycollection.my_role - - -You can alternately use the ``collections`` keyword to simplify this: - -.. code-block:: yaml - - --- - - name: example role by FQCN - hosts: some_host_pattern - collections: - - mynamespace.mycollection - tasks: - - name: import role from a collection - import_role: - name: my_role - - -.. _migrating_plugins_collection: - -Migrating other role plugins to a collection ---------------------------------------------- - -To migrate other role plugins to a collection: - - -1. Move each nonmodule plugins to the appropriate :file:`plugins/PLUGINTYPE/` directory. The :file:`mynamespace/mycollection/plugins/README.md` file explains the types of plugins that the collection can contain within optionally created subdirectories. - -.. code-block:: bash - - $ mv -r mynamespace/mycollection/roles/my_role/filter_plugins/\* mynamespace/mycollection/plugins/filter/ - -2. Update documentation to use the FQCN. Plugins that use ``doc_fragments`` need to use FQCN (for example, ``mydocfrag`` becomes ``mynamespace.mycollection.mydocfrag``). - -3. Update relative imports work in collections to start with a period. For example, :file:`./filename` and :file:`../asdfu/filestuff` works but :file:`filename` in same directory must be updated to :file:`./filename`. - - -If you have a custom ``module_utils`` or import from ``__init__.py``, you must also: - -#. Change the Python namespace for custom ``module_utils`` to use the :abbr:`FQCN (Fully Qualified Collection Name)` along with the ``ansible_collections`` convention. See :ref:`update_module_utils_role`. - -#. Change how you import from ``__init__.py``. See :ref:`update_init_role`. - - -.. _update_module_utils_role: - -Updating ``module_utils`` -^^^^^^^^^^^^^^^^^^^^^^^^^ - -If any of your custom modules use a custom module utility, once you migrate to a collection you cannot address the module utility in the top level ``ansible.module_utils`` Python namespace. Ansible does not merge content from collections into the Ansible internal Python namespace. Update any Python import statements that refer to custom module utilities when you migrate your custom content to collections. See :ref:`module_utils in collections ` for more details. - -When coding with ``module_utils`` in a collection, the Python import statement needs to take into account the :abbr:`FQCN (Fully Qualified Collection Name)` along with the ``ansible_collections`` convention. The resulting Python import looks similar to the following example: - -.. code-block:: text - - from ansible_collections.{namespace}.{collectionname}.plugins.module_utils.{util} import {something} - -.. note:: - - You need to follow the same rules in changing paths and using namespaced names for subclassed plugins. - -The following example code snippets show a Python and a PowerShell module using both default Ansible ``module_utils`` and those provided by a collection. In this example the namespace is ``ansible_example`` and the collection is ``community``. - -In the Python example the ``module_utils`` is ``helper`` and the :abbr:`FQCN (Fully Qualified Collection Name)` is ``ansible_example.community.plugins.module_utils.helper``: - -.. code-block:: text - - from ansible.module_utils.basic import AnsibleModule - from ansible.module_utils.common.text.converters import to_text - from ansible.module_utils.six.moves.urllib.parse import urlencode - from ansible.module_utils.six.moves.urllib.error import HTTPError - from ansible_collections.ansible_example.community.plugins.module_utils.helper import HelperRequest - - argspec = dict( - name=dict(required=True, type='str'), - state=dict(choices=['present', 'absent'], required=True), - ) - - module = AnsibleModule( - argument_spec=argspec, - supports_check_mode=True - ) - - _request = HelperRequest( - module, - headers={"Content-Type": "application/json"}, - data=data - ) - -In the PowerShell example the ``module_utils`` is ``hyperv`` and the :abbr:`FQCN (Fully Qualified Collection Name)` is ``ansible_example.community.plugins.module_utils.hyperv``: - -.. code-block:: powershell - - #!powershell - #AnsibleRequires -CSharpUtil Ansible.Basic - #AnsibleRequires -PowerShell ansible_collections.ansible_example.community.plugins.module_utils.hyperv - - $spec = @{ - name = @{ required = $true; type = "str" } - state = @{ required = $true; choices = @("present", "absent") } - } - $module = [Ansible.Basic.AnsibleModule]::Create($args, $spec) - - Invoke-HyperVFunction -Name $module.Params.name - - $module.ExitJson() - - -.. _update_init_role: - -Importing from __init__.py -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Because of the way that the CPython interpreter does imports, combined with the way the Ansible plugin loader works, if your custom embedded module or plugin requires importing something from an :file:`__init__.py` file, that also becomes part of your collection. You can either originate the content inside a standalone role or use the file name in the Python import statement. The following example is an :file:`__init__.py` file that is part of a callback plugin found inside a collection named ``ansible_example.community``. - -.. code-block:: python - - from ansible_collections.ansible_example.community.plugins.callback.__init__ import CustomBaseClass - - -Example: Migrating a standalone role with plugins to a collection ------------------------------------------------------------------ - -In this example we have a standalone role called ``my-standalone-role.webapp`` to emulate a standalone role that contains dashes in the name (which is not valid in collections). This standalone role contains a custom module in the ``library/`` directory called ``manage_webserver``. - -.. code-block:: bash - - my-standalone-role.webapp - ├── defaults - ├── files - ├── handlers - ├── library - ├── meta - ├── tasks - ├── templates - ├── tests - └── vars - -1. Create a new collection, for example, ``acme.webserver``: - -.. code-block:: bash - - $ ansible-galaxy collection init acme.webserver - - Collection acme.webserver was created successfully - $ tree acme -d 1 - acme - └── webserver - ├── docs - ├── plugins - └── roles - -2. Create the ``webapp`` role inside the collection and copy all contents from the standalone role: - -.. code-block:: bash - - $ mkdir acme/webserver/roles/webapp - $ cp my-standalone-role.webapp/* acme/webserver/roles/webapp/ - -3. Move the ``manage_webserver`` module to its new home in ``acme/webserver/plugins/modules/``: - -.. code-block:: bash - - $ cp my-standalone-role.webapp/library/manage_webserver.py acme/webserver/plugins/modules/manage.py - -.. note:: - - This example changed the original source file ``manage_webserver.py`` to the destination file ``manage.py``. This is optional but the :abbr:`FQCN (Fully Qualified Collection Name)` provides the ``webserver`` context as ``acme.webserver.manage``. - -4. Change ``manage_webserver`` to ``acme.webserver.manage`` in :file:`tasks/` files in the role ( for example, ``my-standalone-role.webapp/tasks/main.yml``) and any use of the original module name. - -.. note:: - - This name change is only required if you changed the original module name, but illustrates content referenced by :abbr:`FQCN (Fully Qualified Collection Name)` can offer context and in turn can make module and plugin names shorter. If you anticipate using these modules independent of the role, keep the original naming conventions. Users can add the :ref:`collections keyword ` in their playbooks. Typically roles are an abstraction layer and users won't use components of the role independently. - - -Example: Supporting standalone roles and migrated collection roles in a downstream RPM ---------------------------------------------------------------------------------------- - -A standalone role can co-exist with its collection role counterpart (for example, as part of a support lifecycle of a product). This should only be done for a transition period, but these two can exist in downstream in packages such as RPMs. For example, the RHEL system roles could coexist with an `example of a RHEL system roles collection `_ and provide existing backwards compatibility with the downstream RPM. - -This section walks through an example creating this coexistence in a downstream RPM and requires Ansible 2.9.0 or later. - -To deliver a role as both a standalone role and a collection role: - -#. Place the collection in :file:`/usr/share/ansible/collections/ansible_collections/`. -#. Copy the contents of the role inside the collection into a directory named after the standalone role and place the standalone role in :file:`/usr/share/ansible/roles/`. - -All previously bundled modules and plugins used in the standalone role are now referenced by :abbr:`FQCN (Fully Qualified Collection Name)` so even though they are no longer embedded, they can be found from the collection contents.This is an example of how the content inside the collection is a unique entity and does not have to be bound to a role or otherwise. You could alternately create two separate collections: one for the modules and plugins and another for the standalone role to migrate to. The role must use the modules and plugins as :abbr:`FQCN (Fully Qualified Collection Name)`. - -The following is an example RPM spec file that accomplishes this using this example content: - -.. code-block:: text - - Name: acme-ansible-content - Summary: Ansible Collection for deploying and configuring ACME webapp - Version: 1.0.0 - Release: 1%{?dist} - License: GPLv3+ - Source0: acme-webserver-1.0.0.tar.gz - - Url: https://github.com/acme/webserver-ansible-collection - BuildArch: noarch - - %global roleprefix my-standalone-role. - %global collection_namespace acme - %global collection_name webserver - - %global collection_dir %{_datadir}/ansible/collections/ansible_collections/%{collection_namespace}/%{collection_name} - - %description - Ansible Collection and standalone role (for backward compatibility and migration) to deploy, configure, and manage the ACME webapp software. - - %prep - %setup -qc - - %build - - %install - - mkdir -p %{buildroot}/%{collection_dir} - cp -r ./* %{buildroot}/%{collection_dir}/ - - mkdir -p %{buildroot}/%{_datadir}/ansible/roles - for role in %{buildroot}/%{collection_dir}/roles/* - do - cp -pR ${role} %{buildroot}/%{_datadir}/ansible/roles/%{roleprefix}$(basename ${role}) - - mkdir -p %{buildroot}/%{_pkgdocdir}/$(basename ${role}) - for docfile in README.md COPYING LICENSE - do - if [ -f ${role}/${docfile} ] - then - cp -p ${role}/${docfile} %{buildroot}/%{_pkgdocdir}/$(basename ${role})/${docfile} - fi - done - done - - - %files - %dir %{_datadir}/ansible - %dir %{_datadir}/ansible/roles - %dir %{_datadir}/ansible/collections - %dir %{_datadir}/ansible/collections/ansible_collections - %{_datadir}/ansible/roles/ - %doc %{_pkgdocdir}/*/README.md - %doc %{_datadir}/ansible/roles/%{roleprefix}*/README.md - %{collection_dir} - %doc %{collection_dir}/roles/*/README.md - %license %{_pkgdocdir}/*/COPYING - %license %{_pkgdocdir}/*/LICENSE - -.. _using_ansible_legacy: - -Using ``ansible.legacy`` to access local custom modules from collections-based roles -===================================================================================== - -Some roles within a collection use :ref:`local custom modules ` that are not part of the collection itself. If there is a conflict between the custom module short name and the collection module name, you need to specify which module your tasks call. You can update the tasks to change ``local_module_name`` to ``ansible.legacy.local_module_name`` to ensure you are using the custom module. diff --git a/docs/docsite/rst/dev_guide/module_lifecycle.rst b/docs/docsite/rst/dev_guide/module_lifecycle.rst deleted file mode 100644 index 823e2b37388..00000000000 --- a/docs/docsite/rst/dev_guide/module_lifecycle.rst +++ /dev/null @@ -1,126 +0,0 @@ -.. _module_lifecycle: - -******************************************** -The lifecycle of an Ansible module or plugin -******************************************** - -Modules and plugins in the main Ansible repository have a defined life cycle, from the first introduction to final removal. The module and plugin lifecycle is tied to the `Ansible release cycle `. -A module or plugin may move through these four stages: - -1. When a module or plugin is first accepted into Ansible, we consider it in tech preview and will mark it as such in the documentation. - -2. If a module or plugin matures, the 'preview' mark in the documentation is removed. Backward compatibility for these modules and plugins is maintained but not guaranteed, which means their parameters should be maintained with stable meanings. - -3. If a module's or plugin's target API changes radically, or if someone creates a better implementation of its functionality, we may mark it deprecated. Modules and plugins that are deprecated are still available but they are reaching the end of their life cycle. We retain deprecated modules and plugins for 4 release cycles with deprecation warnings to help users update playbooks and roles that use them. - -4. When a module or plugin has been deprecated for four release cycles, it is removed and replaced with a tombstone entry in the routing configuration. Modules and plugins that are removed are no longer shipped with Ansible. The tombstone entry helps users find alternative modules and plugins. - -For modules and plugins in collections, the lifecycle is similar. Since ansible-base 2.10, it is no longer possible to mark modules as 'preview' or 'stable'. - -.. _deprecating_modules: - -Deprecating modules and plugins in the Ansible main repository -============================================================== - -To deprecate a module in ansible-core, you must: - -1. Rename the file so it starts with an ``_``, for example, rename ``old_cloud.py`` to ``_old_cloud.py``. This keeps the module available and marks it as deprecated on the module index pages. -2. Mention the deprecation in the relevant changelog (by creating a changelog fragment with a section ``deprecated_features``). -3. Reference the deprecation in the relevant ``porting_guide_core_x.y.rst``. -4. Add ``deprecated:`` to the documentation with the following sub-values: - - :removed_in: A ``string``, such as ``"2.10"``; the version of Ansible where the module will be replaced with a docs-only module stub. Usually current release +4. Mutually exclusive with :removed_by_date:. - :remove_by_date: (Added in ansible-base 2.10). An ISO 8601 formatted date when the module will be removed. Usually 2 years from the date the module is deprecated. Mutually exclusive with :removed_in:. - :why: Optional string that used to detail why this has been removed. - :alternative: Inform users they should do instead, for example, ``Use M(whatmoduletouseinstead) instead.``. - -* For an example of documenting deprecation, see this `PR that deprecates multiple modules `_. - Some of the elements in the PR might now be out of date. - -Deprecating modules and plugins in a collection -=============================================== - -To deprecate a module in a collection, you must: - -1. Add a ``deprecation`` entry to ``plugin_routing`` in ``meta/runtime.yml``. For example, to deprecate the module ``old_cloud``, add: - - .. code-block:: yaml - - plugin_routing: - modules: - old_cloud: - deprecation: - removal_version: 2.0.0 - warning_text: Use foo.bar.new_cloud instead. - - For other plugin types, you have to replace ``modules:`` with ``:``, for example ``lookup:`` for lookup plugins. - - Instead of ``removal_version``, you can also use ``removal_date`` with an ISO 8601 formatted date after which the module will be removed in a new major version of the collection. - -2. Mention the deprecation in the relevant changelog. If the collection uses ``antsibull-changelog``, create a changelog fragment with a section ``deprecated_features``. -3. Add ``deprecated:`` to the documentation of the module or plugin with the following sub-values: - - :removed_in: A ``string``, such as ``"2.10"``; the version of Ansible where the module will be replaced with a docs-only module stub. Usually current release +4. Mutually exclusive with :removed_by_date:. - :remove_by_date: (Added in ansible-base 2.10). An ISO 8601 formatted date when the module will be removed. Usually 2 years from the date the module is deprecated. Mutually exclusive with :removed_in:. - :why: Optional string that used to detail why this has been removed. - :alternative: Inform users they should do instead, for example, ``Use M(whatmoduletouseinstead) instead.``. - -Changing a module or plugin name in the Ansible main repository -=============================================================== - -You can also rename a module and keep a deprecated alias to the old name by using a symlink that starts with _. -This example allows the ``stat`` module to be called with ``fileinfo``, making the following examples equivalent: - -.. code-block:: yaml - - ln -s stat.py _fileinfo.py - ansible -m stat -a "path=/tmp" localhost - ansible -m fileinfo -a "path=/tmp" localhost - -Renaming a module or plugin in a collection, or redirecting a module or plugin to another collection -==================================================================================================== - -To rename a module or plugin in a collection, or to redirect a module or plugin to another collection, you need to add a ``redirect`` entry to ``plugin_routing`` in ``meta/runtime.yml``. For example, to redirect the module ``old_cloud`` to ``foo.bar.new_cloud``, add: - -.. code-block:: yaml - - plugin_routing: - modules: - old_cloud: - redirect: foo.bar.new_cloud - -If you want to deprecate the old name, add a ``deprecation:`` entry (see above): - -.. code-block:: yaml - - plugin_routing: - modules: - old_cloud: - redirect: foo.bar.new_cloud - deprecation: - removal_version: 2.0.0 - warning_text: Use foo.bar.new_cloud instead. - -You need to use the Fully Qualified Collection Name (FQCN) of the new module/plugin name, even if it is located in the same collection as the redirect. By using a FQCN from another collection, you redirect the module/plugin to that collection. - -If you need to support Ansible 2.9, please note that Ansible 2.9 does not know about ``meta/runtime.yml``. With Ansible 2.9 you can still rename plugins and modules inside one collection by using symbolic links. Note that ansible-base 2.10, ansible-core 2.11, and newer will prefer ``meta/runtime.yml`` entries over symbolic links. - - -Tombstoning a module or plugin in a collection -============================================== - -To remove a deprecated module or plugin from a collection, you need to tombstone it: - -1. Remove the module or plugin file with related files like tests, documentation references, and documentation. -2. Add a tombstone entry in ``meta/runtime.yml``. For example, to tombstone the module ``old_cloud``, add: - - .. code-block:: yaml - - plugin_routing: - modules: - old_cloud: - tombstone: - removal_version: 2.0.0 - warning_text: Use foo.bar.new_cloud instead. - - Instead of ``removal_version``, you can also use ``removal_date`` with an ISO 8601 formatted date. The date should be the date of the next major release. diff --git a/docs/docsite/rst/dev_guide/overview_architecture.rst b/docs/docsite/rst/dev_guide/overview_architecture.rst deleted file mode 100644 index 89677e96d9a..00000000000 --- a/docs/docsite/rst/dev_guide/overview_architecture.rst +++ /dev/null @@ -1,153 +0,0 @@ -******************** -Ansible architecture -******************** - -Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs. - -Being designed for multi-tier deployments since day one, Ansible models your IT infrastructure by describing how all of your systems inter-relate, rather than just managing one system at a time. - -It uses no agents and no additional custom security infrastructure, so it's easy to deploy - and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow you to describe your automation jobs in a way that approaches plain English. - -In this section, we'll give you a really quick overview of how Ansible works so you can see how the pieces fit together. - -.. contents:: - :local: - -Modules -======= - -Ansible works by connecting to your nodes and pushing out scripts called "Ansible modules" to them. Most modules accept parameters that describe the desired state of the system. -Ansible then executes these modules (over SSH by default), and removes them when finished. Your library of modules can reside on any machine, and there are no servers, daemons, or databases required. - -You can :ref:`write your own modules `, though you should first consider :ref:`whether you should `. Typically you'll work with your favorite terminal program, a text editor, and probably a version control system to keep track of changes to your content. You may write specialized modules in any language that can return JSON (Ruby, Python, bash, and so on). - -Module utilities -================ - -When multiple modules use the same code, Ansible stores those functions as module utilities to minimize duplication and maintenance. For example, the code that parses URLs is ``lib/ansible/module_utils/url.py``. You can :ref:`write your own module utilities ` as well. Module utilities may only be written in Python or in PowerShell. - -Plugins -======= - -:ref:`Plugins ` augment Ansible's core functionality. While modules execute on the target system in separate processes (usually that means on a remote system), plugins execute on the control node within the ``/usr/bin/ansible`` process. Plugins offer options and extensions for the core features of Ansible - transforming data, logging output, connecting to inventory, and more. Ansible ships with a number of handy plugins, and you can easily :ref:`write your own `. For example, you can write an :ref:`inventory plugin ` to connect to any datasource that returns JSON. Plugins must be written in Python. - -Inventory -========= - -By default, Ansible represents the machines it manages in a file (INI, YAML, and so on) that puts all of your managed machines in groups of your own choosing. - -To add new machines, there is no additional SSL signing server involved, so there's never any hassle deciding why a particular machine didn't get linked up due to obscure NTP or DNS issues. - -If there's another source of truth in your infrastructure, Ansible can also connect to that. Ansible can draw inventory, group, and variable information from sources like EC2, Rackspace, OpenStack, and more. - -Here's what a plain text inventory file looks like: - -.. code-block:: text - - --- - [webservers] - www1.example.com - www2.example.com - - [dbservers] - db0.example.com - db1.example.com - -Once inventory hosts are listed, variables can be assigned to them in simple text files (in a subdirectory called 'group_vars/' or 'host_vars/') or directly in the inventory file. - -Or, as already mentioned, use a dynamic inventory to pull your inventory from data sources like EC2, Rackspace, or OpenStack. - -Playbooks -========= - -Playbooks can finely orchestrate multiple slices of your infrastructure topology, with very detailed control over how many machines to tackle at a time. This is where Ansible starts to get most interesting. - -Ansible's approach to orchestration is one of finely-tuned simplicity, as we believe your automation code should make perfect sense to you years down the road and there should be very little to remember about special syntax or features. - -Here's what a simple playbook looks like: - -.. code-block:: yaml - - --- - - hosts: webservers - serial: 5 # update 5 machines at a time - roles: - - common - - webapp - - - hosts: content_servers - roles: - - common - - content - -.. _ansible_search_path: - -The Ansible search path -======================= - -Modules, module utilities, plugins, playbooks, and roles can live in multiple locations. If you -write your own code to extend Ansible's core features, you may have multiple files with similar or the same names in different locations on your Ansible control node. The search path determines which of these files Ansible will discover and use on any given playbook run. - -Ansible's search path grows incrementally over a run. As -Ansible finds each playbook and role included in a given run, it appends -any directories related to that playbook or role to the search path. Those -directories remain in scope for the duration of the run, even after the playbook or role -has finished executing. Ansible loads modules, module utilities, and plugins in this order: - -1. Directories adjacent to a playbook specified on the command line. If you run Ansible with ``ansible-playbook /path/to/play.yml``, Ansible appends these directories if they exist: - - .. code-block:: bash - - /path/to/modules - /path/to/module_utils - /path/to/plugins - -2. Directories adjacent to a playbook that is statically imported by a - playbook specified on the command line. If ``play.yml`` includes - ``- import_playbook: /path/to/subdir/play1.yml``, Ansible appends these directories if they exist: - - .. code-block:: bash - - /path/to/subdir/modules - /path/to/subdir/module_utils - /path/to/subdir/plugins - -3. Subdirectories of a role directory referenced by a playbook. If - ``play.yml`` runs ``myrole``, Ansible appends these directories if they exist: - - .. code-block:: bash - - /path/to/roles/myrole/modules - /path/to/roles/myrole/module_utils - /path/to/roles/myrole/plugins - -4. Directories specified as default paths in ``ansible.cfg`` or by the related - environment variables, including the paths for the various plugin types. See :ref:`ansible_configuration_settings` for more information. - Sample ``ansible.cfg`` fields: - - .. code-block:: bash - - DEFAULT_MODULE_PATH - DEFAULT_MODULE_UTILS_PATH - DEFAULT_CACHE_PLUGIN_PATH - DEFAULT_FILTER_PLUGIN_PATH - - Sample environment variables: - - .. code-block:: bash - - ANSIBLE_LIBRARY - ANSIBLE_MODULE_UTILS - ANSIBLE_CACHE_PLUGINS - ANSIBLE_FILTER_PLUGINS - -5. The standard directories that ship as part of the Ansible distribution. - -.. caution:: - - Modules, module utilities, and plugins in user-specified directories will - override the standard versions. This includes some files with generic names. - For example, if you have a file named ``basic.py`` in a user-specified - directory, it will override the standard ``ansible.module_utils.basic``. - - If you have more than one module, module utility, or plugin with the same name in different user-specified directories, the order of commands at the command line and the order of includes and roles in each play will affect which one is found and used on that particular play. diff --git a/docs/docsite/rst/dev_guide/shared_snippets/licensing.txt b/docs/docsite/rst/dev_guide/shared_snippets/licensing.txt deleted file mode 100644 index d4b3051f984..00000000000 --- a/docs/docsite/rst/dev_guide/shared_snippets/licensing.txt +++ /dev/null @@ -1,12 +0,0 @@ -.. note:: - **LICENSING REQUIREMENTS** Ansible enforces the following licensing requirements: - - * Utilities (files in ``lib/ansible/module_utils/``) may have one of two licenses: - * A file in ``module_utils`` used **only** for a specific vendor's hardware, provider, or service may be licensed under GPLv3+. - Adding a new file under ``module_utils`` with GPLv3+ needs to be approved by the core team. - * All other ``module_utils`` must be licensed under BSD, so GPL-licensed third-party and Galaxy modules can use them. - * If there's doubt about the appropriate license for a file in ``module_utils``, the Ansible Core Team will decide during an Ansible Core Community Meeting. - * All other files shipped with Ansible, including all modules, must be licensed under the GPL license (GPLv3 or later). - * Existing license requirements still apply to content in ansible/ansible (ansible-core). - * Content that was previously in ansible/ansible or a collection and has moved to a new collection must retain the license it had in its prior repository. - * Copyright entries by previous committers must also be kept in any moved files. diff --git a/docs/docsite/rst/dev_guide/sidecar.rst b/docs/docsite/rst/dev_guide/sidecar.rst deleted file mode 100644 index ccf3aa75efa..00000000000 --- a/docs/docsite/rst/dev_guide/sidecar.rst +++ /dev/null @@ -1,100 +0,0 @@ -.. _adjacent_yaml_doc: - -********************************* -Adjacent YAML documentation files -********************************* - -.. contents:: - :local: - -YAML documentation for plugins ------------------------------- -For most Ansible plugins, the documentation is in the same file as the code. This approach does not work for cases when: - - * Multiple plugins are defined in the same file, such as tests and filters. - * Plugins are written in a language other than Python (modules). - -These cases require plugins to provide documentation in an adjacent ``.py`` file. As of ansible-core 2.14, you can provide documentation as adjacent YAML files instead. -The format of a YAML documentation file is nearly identical to its Python equivalent, except it is pure YAML. - - -YAML format ------------ -In Python each section is a variable ``DOCUMENTATION = r""" ... """`` while in YAML it is a mapping key ``DOCUMENTATION: ...``. - -Here is a longer example that shows documentation as embedded in a Python file: - -.. code-block:: python - - DOCUMENTATION = r''' - description: something - options: - option_name: - description: describe this config option - default: default value for this config option - env: - - name: NAME_OF_ENV_VAR - ini: - - section: section_of_ansible.cfg_where_this_config_option_is_defined - key: key_used_in_ansible.cfg - vars: - - name: name_of_ansible_var - - name: name_of_second_var - version_added: X.x - required: True/False - type: boolean/float/integer/list/none/path/pathlist/pathspec/string/tmppath - version_added: X.x - ''' - - EXAMPLES = r''' - # TODO: write examples - ''' - -This example shows the same documentation in YAML format: - -.. code-block:: YAML - - DOCUMENTATION: - description: something - options: - option_name: - description: describe this config option - default: default value for this config option - env: - - name: NAME_OF_ENV_VAR - ini: - - section: section_of_ansible.cfg_where_this_config_option_is_defined - key: key_used_in_ansible.cfg - vars: - - name: name_of_ansible_var - - name: name_of_second_var - version_added: X.x - required: True/False - type: boolean/float/integer/list/none/path/pathlist/pathspec/string/tmppath - version_added: X.x - - EXAMPLES: # TODO: write examples - -As the examples above show, Python variables already contain YAML. The main change to use YAML documentation is to simply move the YAML out of such variables. - - Any adjacent YAML documentation files must be in the same directory as the plugin or module that they document. This means the documentation is available in any directory that contains the plugins or modules. - - -Supported plugin types ----------------------- -YAML documentation is mainly intended for filters, tests and modules. While it is possible to use with other plugin types, Ansible always recommends having documentation in the same file as the code for most cases. - -.. seealso:: - - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_api` - Learn about the Python API for task execution - :ref:`developing_inventory` - Learn about how to develop dynamic inventory sources - :ref:`developing_modules_general` - Learn about how to write Ansible modules - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/style_guide/basic_rules.rst b/docs/docsite/rst/dev_guide/style_guide/basic_rules.rst deleted file mode 100644 index fcb4abad687..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/basic_rules.rst +++ /dev/null @@ -1,71 +0,0 @@ -.. _styleguide_basic: - -Basic rules -=========== -.. contents:: - :local: - -Use standard American English ------------------------------ -Ansible uses Standard American English. Watch for common words that are spelled differently in American English (color vs colour, organize vs organise, and so on). - -Write for a global audience ---------------------------- -Everything you say should be understandable by people of different backgrounds and cultures. Avoid idioms and regionalism and maintain a neutral tone that cannot be misinterpreted. Avoid attempts at humor. - -Follow naming conventions -------------------------- -Always follow naming conventions and trademarks. - -.. good place to link to an Ansible terminology page - -Use clear sentence structure ----------------------------- -Clear sentence structure means: - -- Start with the important information first. -- Avoid padding/adding extra words that make the sentence harder to understand. -- Keep it short - Longer sentences are harder to understand. - -Some examples of improving sentences: - -Bad: - The unwise walking about upon the area near the cliff edge may result in a dangerous fall and therefore it is recommended that one remains a safe distance to maintain personal safety. - -Better: - Danger! Stay away from the cliff. - -Bad: - Furthermore, large volumes of water are also required for the process of extraction. - -Better: - Extraction also requires large volumes of water. - -Avoid verbosity ---------------- -Write short, succinct sentences. Avoid terms like: - -- "...as has been said before," -- "..each and every," -- "...point in time," -- "...in order to," - -Highlight menu items and commands ---------------------------------- -When documenting menus or commands, it helps to **bold** what is important. - -For menu procedures, bold the menu names, button names, and so on to help the user find them on the GUI: - -1. On the **File** menu, click **Open**. -2. Type a name in the **User Name** field. -3. In the **Open** dialog box, click **Save**. -4. On the toolbar, click the **Open File** icon. - -For code or command snippets, use the RST `code-block directive `_: - -.. code-block:: rst - - .. code-block:: bash - - ssh my_vyos_user@vyos.example.net - show config diff --git a/docs/docsite/rst/dev_guide/style_guide/grammar_punctuation.rst b/docs/docsite/rst/dev_guide/style_guide/grammar_punctuation.rst deleted file mode 100644 index da06070918d..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/grammar_punctuation.rst +++ /dev/null @@ -1,201 +0,0 @@ - -Grammar and Punctuation -======================= - -Common Styles and Usage, and Common Mistakes ----------------------------------------------------- - -Ansible -^^^^^^^ -* Write "Ansible." Not "Ansible, Inc." or "AnsibleWorks The only exceptions to this rule are when we're writing legal or financial statements. - -* Never use the logotype by itself in body text. Always keep the same font you are using the rest of the sentence. - -* A company is singular in the US. In other words, Ansible is an "it," not a "they." - - -Capitalization -^^^^^^^^^^^^^^ -If it's not a real product, service, or department at Ansible, don't capitalize it. Not even if it seems important. Capitalize only the first letter of the first word in headlines. - -Colon -^^^^^ -A colon is generally used before a list or series: -- The Triangle Area consists of three cities: Raleigh, Durham, and Chapel Hill. - -But not if the list is a complement or object of an element in the sentence: -- Before going on vacation, be sure to (1) set the alarm, (2) cancel the newspaper, and (3) ask a neighbor to collect your mail. - -Use a colon after "as follows" and "the following" if the related list comes immediately after: -wedge The steps for changing directories are as follows: - - 1. Open a terminal. - 2. Type cd... - -Use a colon to introduce a bullet list (or dash, or icon/symbol of your choice): - - In the Properties dialog box, you'll find the following entries: - - - Connection name - - Count - - Cost per item - - -Commas -^^^^^^ -Use serial commas, the comma before the "and" in a series of three or more items: - -- "Item 1, item 2, and item 3." - - -It's easier to read that way and helps avoid confusion. The primary exception to this you will see is in PR, where it is traditional not to use serial commas because it is often the style of journalists. - -Commas are always important, considering the vast difference in meanings of the following two statements. - -- Let's eat, Grandma -- Let's eat Grandma. - -Correct punctuation could save Grandma's life. - -If that does not convince you, maybe this will: - -.. image:: images/commas-matter.jpg - - -Contractions -^^^^^^^^^^^^ -Do not use contractions in Ansible documents. - -Em dashes -^^^^^^^^^ -When possible, use em-dashes with no space on either side. When full em-dashes aren't available, use double-dashes with no spaces on either side--like this. - -A pair of em dashes can be used in place of commas to enhance readability. Note, however, that dashes are always more emphatic than commas. - -A pair of em dashes can replace a pair of parentheses. Dashes are considered less formal than parentheses; they are also more intrusive. If you want to draw attention to the parenthetical content, use dashes. If you want to include the parenthetical content more subtly, use parentheses. - -.. note:: - When dashes are used in place of parentheses, surrounding punctuation should be omitted. Compare the following examples. - -:: - - Upon discovering the errors (all 124 of them), the publisher immediately recalled the books. - - Upon discovering the errors—all 124 of them—the publisher immediately recalled the books. - - -When used in place of parentheses at the end of a sentence, only a single dash is used. - -:: - - After three weeks on set, the cast was fed up with his direction (or, rather, lack of direction). - - After three weeks on set, the cast was fed up with his direction—or, rather, lack of direction. - - -Exclamation points (!) -^^^^^^^^^^^^^^^^^^^^^^ -Do not use them at the end of sentences. An exclamation point can be used when referring to a command, such as the bang (!) command. - -Gender References -^^^^^^^^^^^^^^^^^ -Do not use gender-specific pronouns in documentation. It is far less awkward to read a sentence that uses "they" and "their" rather than "he/she" and "his/hers." - -It is fine to use "you" when giving instructions and "the user," "new users," and so on. in more general explanations. - -Never use "one" in place of "you" when writing technical documentation. Using "one" is far too formal. - -Never use "we" when writing. "We" aren't doing anything on the user side. Ansible's products are doing the work as requested by the user. - - -Hyphen -^^^^^^ -The hyphen's primary function is the formation of certain compound terms. Do not use a hyphen unless it serves a purpose. If a compound adjective cannot be misread or, as with many psychological terms, its meaning is established, a hyphen is not necessary. - -Use hyphens to avoid ambiguity or confusion: - -:: - - a little-used car - a little used-car - - cross complaint - cross-complaint - - high-school girl - high schoolgirl - - fine-tooth comb (most people do not comb their teeth) - - third-world war - third world war - -.. image:: images/hyphen-funny.jpg - -In professionally printed material (particularly books, magazines, and newspapers), the hyphen is used to divide words between the end of one line and the beginning of the next. This allows for an evenly aligned right margin without highly variable (and distracting) word spacing. - - -Lists -^^^^^ -Keep the structure of bulleted lists equivalent and consistent. If one bullet is a verb phrase, they should all be verb phrases. If one is a complete sentence, they should all be complete sentences, and so on. - -Capitalize the first word of each bullet. Unless it is obvious that it is just a list of items, such as a list of items like: -* computer -* monitor -* keyboard -* mouse - -When the bulleted list appears within the context of other copy, (unless it's a straight list like the previous example) add periods, even if the bullets are sentence fragments. Part of the reason behind this is that each bullet is said to complete the original sentence. - -In some cases where the bullets are appearing independently, such as in a poster or a homepage promotion, they do not need periods. - -When giving instructional steps, use numbered lists instead of bulleted lists. - - -Months and States -^^^^^^^^^^^^^^^^^ -Abbreviate months and states according to AP. Months are only abbreviated if they are used in conjunction with a day. Example: "The President visited in January 1999." or "The President visited Jan. 12." - -Months: Jan., Feb., March, April, May, June, July, Aug., Sept., Nov., Dec. - -States: Ala., Ariz., Ark., Calif., Colo., Conn., Del., Fla., Ga., Ill., Ind., Kan., Ky., La., Md., Mass., Mich., Minn., Miss., Mo., Mont., Neb., Nev., NH, NJ, NM, NY, NC, ND, Okla., Ore., Pa., RI, SC, SD, Tenn., Vt., Va., Wash., W.Va., Wis., Wyo. - -Numbers -^^^^^^^ -Numbers between one and nine are written out. 10 and above are numerals. The exception to this is writing "4 million" or "4 GB." It's also acceptable to use numerals in tables and charts. - -Phone Numbers -^^^^^^^^^^^^^ - -Phone number style: 1 (919) 555-0123 x002 and 1 888-GOTTEXT - - -Quotations (Using Quotation Marks and Writing Quotes) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - "Place the punctuation inside the quotes," the editor said. - -Except in rare instances, use only "said" or "says" because anything else just gets in the way of the quote itself, and also tends to editorialize. - -Place the name first right after the quote: - "I like to write first-person because I like to become the character I'm writing," Wally Lamb said. - -Not: - "I like to write first-person because I like to become the character I'm writing," said Wally Lamb. - - -Semicolon -^^^^^^^^^ -Use a semicolon to separate items in a series if the items contain commas: - -- Everyday I have coffee, toast, and fruit for breakfast; a salad for lunch; and a peanut butter sandwich, cookies, ice cream, and chocolate cake for dinner. - -Use a semicolon before a conjunctive adverb (however, therefore, otherwise, namely, for example, and so on): -- I think; therefore, I am. - -Spacing after sentences -^^^^^^^^^^^^^^^^^^^^^^^ -Use only a single space after a sentence. - -Time -^^^^ -* Time of day is written as "4 p.m." diff --git a/docs/docsite/rst/dev_guide/style_guide/images/commas-matter-2.jpg b/docs/docsite/rst/dev_guide/style_guide/images/commas-matter-2.jpg deleted file mode 100644 index 2dec81c4380..00000000000 Binary files a/docs/docsite/rst/dev_guide/style_guide/images/commas-matter-2.jpg and /dev/null differ diff --git a/docs/docsite/rst/dev_guide/style_guide/images/commas-matter.jpg b/docs/docsite/rst/dev_guide/style_guide/images/commas-matter.jpg deleted file mode 100644 index 1699a31af31..00000000000 Binary files a/docs/docsite/rst/dev_guide/style_guide/images/commas-matter.jpg and /dev/null differ diff --git a/docs/docsite/rst/dev_guide/style_guide/images/hyphen-funny.jpg b/docs/docsite/rst/dev_guide/style_guide/images/hyphen-funny.jpg deleted file mode 100644 index d642703fe44..00000000000 Binary files a/docs/docsite/rst/dev_guide/style_guide/images/hyphen-funny.jpg and /dev/null differ diff --git a/docs/docsite/rst/dev_guide/style_guide/images/thenvsthan.jpg b/docs/docsite/rst/dev_guide/style_guide/images/thenvsthan.jpg deleted file mode 100644 index f4851b07813..00000000000 Binary files a/docs/docsite/rst/dev_guide/style_guide/images/thenvsthan.jpg and /dev/null differ diff --git a/docs/docsite/rst/dev_guide/style_guide/index.rst b/docs/docsite/rst/dev_guide/style_guide/index.rst deleted file mode 100644 index b43b9164d31..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/index.rst +++ /dev/null @@ -1,340 +0,0 @@ -.. _style_guide: - -********************************** -Ansible documentation style guide -********************************** - -Welcome to the Ansible style guide! -To create clear, concise, consistent, useful materials on docs.ansible.com, follow these guidelines: - -.. contents:: - :local: - -Linguistic guidelines -===================== - -We want the Ansible documentation to be: - -* clear -* direct -* conversational -* easy to translate - -We want reading the docs to feel like having an experienced, friendly colleague -explain how Ansible works. - -Stylistic cheat-sheet ---------------------- - -This cheat-sheet illustrates a few rules that help achieve the "Ansible tone": - -+-------------------------------+------------------------------+----------------------------------------+ -| Rule | Good example | Bad example | -+===============================+==============================+========================================+ -| Use active voice | You can run a task by | A task can be run by | -+-------------------------------+------------------------------+----------------------------------------+ -| Use the present tense | This command creates a | This command will create a | -+-------------------------------+------------------------------+----------------------------------------+ -| Address the reader | As you expand your inventory | When the number of managed nodes grows | -+-------------------------------+------------------------------+----------------------------------------+ -| Use standard English | Return to this page | Hop back to this page | -+-------------------------------+------------------------------+----------------------------------------+ -| Use American English | The color of the output | The colour of the output | -+-------------------------------+------------------------------+----------------------------------------+ - -Header case ------------ - -Headers should be written in sentence case. For example, this section's title is -``Header case``, not ``Header Case`` or ``HEADER CASE``. - - -Avoid using Latin phrases -------------------------- - -Latin words and phrases like ``e.g.`` or ``etc.`` -are easily understood by English speakers. -They may be harder to understand for others and are also tricky for automated translation. - -Use the following English terms in place of Latin terms or abbreviations: - -+-------------------------------+------------------------------+ -| Latin | English | -+===============================+==============================+ -| i.e | in other words | -+-------------------------------+------------------------------+ -| e.g. | for example | -+-------------------------------+------------------------------+ -| etc | and so on | -+-------------------------------+------------------------------+ -| via | by/ through | -+-------------------------------+------------------------------+ -| vs./versus | rather than/against | -+-------------------------------+------------------------------+ - - -reStructuredText guidelines -=========================== - -The Ansible documentation is written in reStructuredText and processed by Sphinx. -We follow these technical or mechanical guidelines on all rST pages: - -.. _headers_style: - -Header notation ---------------- - -`Section headers in reStructuredText `_ -can use a variety of notations. -Sphinx will 'learn on the fly' when creating a hierarchy of headers. -To make our documents easy to read and to edit, we follow a standard set of header notations. -We use: - -* ``###`` with overline, for parts: - -.. code-block:: rst - - ############### - Developer guide - ############### - -* ``***`` with overline, for chapters: - -.. code-block:: rst - - ******************* - Ansible style guide - ******************* - -* ``===`` for sections: - -.. code-block:: rst - - Mechanical guidelines - ===================== - -* ``---`` for subsections: - -.. code-block:: rst - - Internal navigation - ------------------- - -* ``^^^`` for sub-subsections: - -.. code-block:: rst - - Adding anchors - ^^^^^^^^^^^^^^ - -* ``"""`` for paragraphs: - -.. code-block:: rst - - Paragraph that needs a title - """""""""""""""""""""""""""" - - -Syntax highlighting - Pygments ------------------------------- - -The Ansible documentation supports a range of `Pygments lexers `_ -for `syntax highlighting `_ to make our code examples look good. Each code-block must be correctly indented and surrounded by blank lines. - -The Ansible documentation allows the following values: - -* none (no highlighting) -* ansible-output (a custom lexer for Ansible output) -* bash -* console -* csharp -* ini -* json -* powershell -* python -* rst -* sh -* shell -* shell-session -* text -* yaml -* yaml+jinja - -For example, you can highlight Python code using following syntax: - -.. code-block:: rst - - .. code-block:: python - - def my_beautiful_python_code(): - pass - -.. _style_links: - -Internal navigation -------------------- - -`Anchors (also called labels) and links `_ -work together to help users find related content. -Local tables of contents also help users navigate quickly to the information they need. -All internal links should use the ``:ref:`` syntax. -Every page should have at least one anchor to support internal ``:ref:`` links. -Long pages, or pages with multiple levels of headers, can also include a local TOC. - -.. note:: - - Avoid raw URLs. RST and sphinx allow ::code:`https://my.example.com`, but this is unhelpful for those using screen readers. ``:ref:`` links automatically pick up the header from the anchor, but for external links, always use the ::code:`link title `_` format. - -.. _adding_anchors_rst: - -Adding anchors -^^^^^^^^^^^^^^ - -* Include at least one anchor on every page -* Place the main anchor above the main header -* If the file has a unique title, use that for the main page anchor: - -.. code-block:: text - - .. _unique_page:: - -* You may also add anchors elsewhere on the page - -Adding internal links -^^^^^^^^^^^^^^^^^^^^^ - -* All internal links must use ``:ref:`` syntax. These links both point to the anchor defined above: - -.. code-block:: rst - - :ref:`unique_page` - :ref:`this page ` - -The second example adds custom text for the link. - -Adding links to modules and plugins -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Ansible 2.10 and later require the extended Fully Qualified Collection Name (FQCN) as part of the links: - -.. code-block:: text - - ansible_collections. + FQCN + _module - -For example: - - .. code-block:: rst - - :ref:`ansible.builtin.first_found lookup plugin ` - -displays as :ref:`ansible.builtin.first_found lookup plugin `. - -Modules require different suffixes from other plugins: - -* Module links use this extended FQCN module name with ``_module`` for the anchor. -* Plugin links use this extended FQCN plugin name with the plugin type (``_connection`` for example). - -.. code-block:: rst - - :ref:`arista.eos.eos_config ` - :ref:`kubernetes.core.kubectl connection plugin ` - -.. note:: - - ``ansible.builtin`` is the FQCN for modules included in ``ansible.base``. Documentation links are the only place you prepend ``ansible_collections`` to the FQCN. This is used by the documentation build scripts to correctly fetch documentation from collections on Ansible Galaxy. - -.. _local_toc: - -Adding local TOCs -^^^^^^^^^^^^^^^^^ - -The page you're reading includes a `local TOC `_. -If you include a local TOC: - -* place it below, not above, the main heading and (optionally) introductory text -* use the ``:local:`` directive so the page's main header is not included -* do not include a title - -The syntax is: - -.. code-block:: rst - - .. contents:: - :local: - -Accessibility guidelines -========================= - -Ansible documentation has a goal to be more accessible. Use the following guidelines to help us reach this goal. - -Images and alternative text - Ensure all icons, images, diagrams, and non text elements have a meaningful alternative-text description. Do not include screen captures of CLI output. Use ``code-block`` instead. - - .. code-block:: text - - .. image:: path/networkdiag.png - :width: 400 - :alt: SpiffyCorp network diagram - - -Links and hypertext - URLs and cross-reference links have descriptive text that conveys information about the content of the linked target. See :ref:`style_links` for how to format links. - -Tables - Tables have a simple, logical reading order from left to right, and top to bottom. - Tables include a header row and avoid empty or blank table cells. - Label tables with a descriptive title. - - .. code-block:: reStructuredText - - .. table:: File descriptions - - +----------+----------------------------+ - |File |Purpose | - +==========+============================+ - |foo.txt |foo configuration settings | - +----------+----------------------------+ - |bar.txt |bar configuration settings | - +----------+----------------------------+ - - -Colors and other visual information - * Avoid instructions that rely solely on sensory characteristics. For example, do not use ``Click the square, blue button to continue.`` - * Convey information by methods and not by color alone. - * Ensure there is sufficient contrast between foreground and background text or graphical elements in images and diagrams. - * Instructions for navigating through an interface make sense without directional indicators such as left, right, above, and below. - -Accessibility resources ------------------------- - -Use the following resources to help test your documentation changes: - -* `axe DevTools browser extension `_ - Highlights accessibility issues on a website page. -* `WAVE browser extension `_ from WebAIM - another accessibility tester. -* `Orca screen reader `_ - Common tool used by people with vision impairments. -* `color filter `_ - For color-blind testing. - -More resources -============== - -These pages offer more help with grammatical, stylistic, and technical rules for documentation. - -.. toctree:: - :maxdepth: 1 - - basic_rules - voice_style - trademarks - grammar_punctuation - spelling_word_choice - search_hints - resources - -.. seealso:: - - :ref:`community_documentation_contributions` - How to contribute to the Ansible documentation - :ref:`testing_documentation_locally` - How to build the Ansible documentation - `irc.libera.chat `_ - #ansible-docs IRC chat channel diff --git a/docs/docsite/rst/dev_guide/style_guide/resources.rst b/docs/docsite/rst/dev_guide/style_guide/resources.rst deleted file mode 100644 index 64dc0c1dd57..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/resources.rst +++ /dev/null @@ -1,11 +0,0 @@ -Resources -^^^^^^^^^ -* Follow the style of the :ref:`Ansible Documentation` -* Ask for advice on the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) -* Review these online style guides: - - * `AP Stylebook `_ - * `Chicago Manual of Style `_ - * `Strunk and White's Elements of Style `_ - * `Google developer documentation style guide `_ - diff --git a/docs/docsite/rst/dev_guide/style_guide/search_hints.rst b/docs/docsite/rst/dev_guide/style_guide/search_hints.rst deleted file mode 100644 index d9bf3f665a7..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/search_hints.rst +++ /dev/null @@ -1,48 +0,0 @@ - -.. _search_hints: - -Writing documentation so search can find it -------------------------------------------- - -One of the keys to writing good documentation is to make it findable. Readers use a combination of internal site search and external search engines such as Google or duckduckgo. - -To ensure Ansible documentation is findable, you should: - -#. Use headings that clearly reflect what you are documenting. -#. Use numbered lists for procedures or high-level steps where possible. -#. Avoid linking to github blobs where possible. - - -Using clear headings in documentation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -We all use simple English when we want to find something. For example, the title of this page could have been any one of the following: - -* Search optimization -* Findable documentation -* Writing for findability - -What we are really trying to describe is - how do I write documentation so search engines can find my content? That simple phrase is what drove the title of this section. When you are creating your headings for documentation, spend some time to think about what you would type in a search box to find it, or more importantly, how someone less familiar with Ansible would try to find that information. Your heading should be the answer to that question. - -One word of caution - you do want to limit the size of your headings. A full heading such as `How do I write documentation so search engines can find my content?` is too long. Search engines would truncate anything over 50 - 60 characters. Long headings would also wrap on smaller devices such as a smart phone. - -Using numbered lists for `zero position` snippets -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Google can optimize the search results by adding a `feature snippet `_ at the top of the search results. This snippet provides a small window into the documentation on that first search result that adds more detail than the rest of the search results, and can occasionally answer the reader's questions right there, or at least verify that the linked page is what the reader is looking for. - -Google returns the feature snippet in the form of numbered steps. Where possible, you should add a numbered list near the top of your documentation page, where appropriate. The steps can be the exact procedure a reader would follow, or could be a high level introduction to the documentation topic, such as the numbered list at the top of this page. - -Problems with github blobs on search results -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Search engines do not typically return github blobs in search results, at least not in higher ranked positions. While it is possible and sometimes necessary to link to github blobs from documentation, the better approach would be to copy that information into an .rst page in Ansible documentation. - -Other search hints -^^^^^^^^^^^^^^^^^^ - -While it may not be possible to adapt your documentation to all search optimizations, keep the following in mind as you write your documentation: - -* **Search engines don't parse beyond the `#` in an html page.** So for example, all the subheadings on this page are appended to the main page URL. As such, when I search for 'Using number lists for zero position snippets', the search result would be a link to the top of this page, not a link directly to the subheading I searched for. Using :ref:`local TOCs ` helps alleviate this problem as the reader can scan for the header at top of the page and click to the section they are looking for. For critical documentation, consider creating a new page that can be a direct search result page. - -* **Make your first few sentences clearly describe your page topic.** Search engines return not just the URL, but a short description of the information at the URL. For Ansible documentation, we do not have description metadata embedded on each page. Instead, the search engines return the first couple of sentences (140 characters) on the page. That makes your first sentence or two very important to the reader who is searching for something in Ansible. diff --git a/docs/docsite/rst/dev_guide/style_guide/spelling_word_choice.rst b/docs/docsite/rst/dev_guide/style_guide/spelling_word_choice.rst deleted file mode 100644 index ce16eba70f3..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/spelling_word_choice.rst +++ /dev/null @@ -1,327 +0,0 @@ -Spelling - Word Usage - Common Words and Phrases to Use and Avoid ------------------------------------------------------------------ - -Acronyms -^^^^^^^^ - -Always uppercase. An acronym is a word formed from the initial letters of a name, such as ROM for Read-only memory, -SaaS for Software as a Service, or by combining initial letters or part of a series of words, such as LILO for LInux -LOader. - -Spell out the acronym before using it in alone text, such as "The Embedded DevKit (EDK)..." - -Applications -^^^^^^^^^^^^ -When used as a proper name, use the capitalization of the product, such as GNUPro or Source-Navigator. When used as a command, use lowercase as appropriate, such as "To start GCC, type ``gcc``." - -.. note:: - - "vi" is always lowercase. - -As -^^ -This is often used to mean "because", but has other connotations, for example, parallel or simultaneous actions. If you mean "because", say "because". - -Asks for -^^^^^^^^ -Use "requests" instead. - -Assure/Ensure/Insure -^^^^^^^^^^^^^^^^^^^^ -Assure implies a sort of mental comfort. As in "I assured my husband that I would eventually bring home beer." - -Ensure means "to make sure." - -Insure relates to monetary insurance. - - -Back up -^^^^^^^ -This is a verb. You "back up" files; you do not "backup" files. - -Backup -^^^^^^ -This is a noun. You create "backup" files; you do not create "back up" files. - -Backward -^^^^^^^^ -Correct. Avoid using backwards unless you are stating that something has "backwards compatibility." - -Backwards compatibility -^^^^^^^^^^^^^^^^^^^^^^^ -Correct as is. - -By way of -^^^^^^^^^ -Use "using" instead. - -Can/May -^^^^^^^ -Use "can" to describe actions or conditions that are possible. Use "may" only to describe situations where permission is being given. If either "can," "could," or "may" apply, use "can" because it's less tentative. - -CD or cd -^^^^^^^^ -When referring to a compact disk, use CD, such as "Insert the CD into the CD-ROM drive." When referring to the change directory command, use cd. - -CD-ROM -^^^^^^ -Correct. Do not use "cdrom," "CD-Rom," "CDROM," "cd-rom" or any other variation. When referring to the drive, use CD-ROM drive, such as "Insert the CD into the CD-ROM drive." The plural is "CD-ROMs." - - -Command line -^^^^^^^^^^^^ -Correct. Do not use "command-line" or "commandline" as a noun. If used as an adjective, "command-line" is appropriate, for example "command-line arguments". - -Use "command line" to describes where to place options for a command, but not where to type the command. Use "shell prompt" instead to describe where to type commands. The line on the display screen where a command is expected. Generally, the command line is the line that contains the most recently displayed command prompt. - - -Daylight saving time (DST) -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Correct. Do not use daylight savings time. Daylight Saving Time (DST) is often misspelled "Daylight Savings", with an "s" at the end. Other common variations are "Summer Time"and "Daylight-Saving Time". (https://www.timeanddate.com/time/dst/daylight-savings-time.html) - - -Download -^^^^^^^^ -Correct. Do not use "down load" or "down-load." - -e.g. -^^^^ -Spell it out: "For example." - -Failover -^^^^^^^^ -When used as a noun, a failover is a backup operation that automatically switches to a standby database, server or network if the primary system fails or is temporarily shut down for servicing. Failover is an important fault tolerance function of mission-critical systems that rely on constant accessibility. Failover automatically and transparently to the user redirects requests from the failed or down system to the backup system that mimics the operations of the primary system. - -Fail over -^^^^^^^^^ -When used as a verb, fail over is two words since there can be different tenses such as failed over. - -Fewer -^^^^^ -Fewer is used with plural nouns. Think things you could count. Time, money, distance, and weight are often listed as exceptions to the traditional "can you count it" rule, often thought of a singular amounts (the work will take less than 5 hours, for example). - -File name -^^^^^^^^^ -Correct. Do not use "filename." - -File system -^^^^^^^^^^^ -Correct. Do not use "filesystem." The system that an operating system or program uses to organize and keep track of files. For example, a hierarchical file system is one that uses directories to organize files into a tree structure. Although the operating system provides its own file management system, you can buy separate file management systems. These systems interact smoothly with the operating system but provide more features, such as improved backup procedures and stricter file protection. - -For instance -^^^^^^^^^^^^ -For example," instead. - -For further/additional/whatever information -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use "For more information" - -For this reason -^^^^^^^^^^^^^^^ -Use "therefore". - -Forward -^^^^^^^ -Correct. Avoid using "forwards." - -Gigabyte (GB) -^^^^^^^^^^^^^ -2 to the 30th power (1,073,741,824) bytes. One gigabyte is equal to 1,024 megabytes. Gigabyte is often abbreviated as G or GB. - -Got -^^^ -Avoid. Use "must" instead. - -High-availability -^^^^^^^^^^^^^^^^^ -Correct. Do not use "high availability." - -Highly available -^^^^^^^^^^^^^^^^ -Correct. Do not use highly-available." - -Hostname -^^^^^^^^ -Correct. Do not use host name. - -i.e. -^^^^ -Spell it out: "That is." - -Installer -^^^^^^^^^ -Avoid. Use "installation program" instead. - -It's and its -^^^^^^^^^^^^ -"It's" is a contraction for "it is;" use "it is" instead of "it's." Use "its" as a possessive pronoun (for example, "the store is known for its low prices"). - -Less -^^^^ -Less is used with singular nouns. For example "View less details" wouldn't be correct but "View less detail" works. Use fewer when you have plural nouns (things you can count). - -Linux -^^^^^ -Correct. Do not use "LINUX" or "linux" unless referring to a command, such as "To start Linux, type linux." Linux is a registered trademark of Linus Torvalds. - -Login -^^^^^ -A noun used to refer to the login prompt, such as "At the login prompt, enter your username." - -Log in -^^^^^^ -A verb used to refer to the act of logging in. Do not use "login," "loggin," "logon," and other variants. For example, "When starting your computer, you are requested to log in..." - -Log on -^^^^^^ -To make a computer system or network recognize you so that you can begin a computer session. Most personal computers have no log-on procedure -- you just turn the machine on and begin working. For larger systems and networks, however, you usually need to enter a username and password before the computer system will allow you to execute programs. - -Lots of -^^^^^^^ -Use "Several" or something equivalent instead. - -Make sure -^^^^^^^^^ -This means "be careful to remember, attend to, or find out something." For example, "...make sure that the rhedk group is listed in the output." -Try to use verify or ensure instead. - -Manual/man page -^^^^^^^^^^^^^^^ -Correct. Two words. Do not use "manpage" - -MB -^^ -(1) When spelled MB, short for megabyte (1,000,000 or 1,048,576 bytes, depending on the context). -(2) When spelled Mb, short for megabit. - -MBps -^^^^ -Short for megabytes per second, a measure of data transfer speed. Mass storage devices are generally measured in MBps. - -MySQL -^^^^^ -Common open source database server and client package. Do not use "MYSQL" or "mySQL." - -Need to -^^^^^^^ -Avoid. Use "must" instead. - -Read-only -^^^^^^^^^ -Correct. Use when referring to the access permissions of files or directories. - -Real time/real-time -^^^^^^^^^^^^^^^^^^^ -Depends. If used as a noun, it is the actual time during which something takes place. For example, "The computer may partly analyze the data in real time (as it comes in) -- R. H. March." If used as an adjective, "real-time" is appropriate. For example, "XEmacs is a self-documenting, customizable, extensible, real-time display editor." - -Refer to -^^^^^^^^ -Use to indicate a reference (within a manual or website) or a cross-reference (to another manual or documentation source). - -See -^^^ -Don't use. Use "Refer to" instead. - -Since -^^^^^ -This is often used to mean "because", but "since" has connotations of time, so be careful. If you mean "because", say "because". - -Tells -^^^^^ -Use "Instructs" instead. - -That/which -^^^^^^^^^^ -"That" introduces a restrictive clause-a clause that must be there for the sentence to make sense. A restrictive clause often defines the noun or phrase preceding it. "Which" introduces a non-restrictive, parenthetical clause-a clause that could be omitted without affecting the meaning of the sentence. For example: The car was travelling at a speed that would endanger lives. The car, which was traveling at a speed that would endanger lives, swerved onto the sidewalk. Use "who" or "whom," rather than "that" or "which," when referring to a person. - -Then/than -^^^^^^^^^ - "Then" refers to a time in the past or the next step in a sequence. "Than" is used for comparisons. - -.. image:: images/thenvsthan.jpg - -Third-party -^^^^^^^^^^^ -Correct. Do not use "third party". - -Troubleshoot -^^^^^^^^^^^^ -Correct. Do not use "trouble shoot" or "trouble-shoot." To isolate the source of a problem and fix it. In the case of computer systems, the term troubleshoot is usually used when the problem is suspected to be hardware -related. If the problem is known to be in software, the term debug is more commonly used. - -UK -^^ -Correct as is, no periods. - -UNIX® -^^^^^ -Correct. Do not use "Unix" or "unix." UNIX® is a registered trademark of The Open Group. - -Unset -^^^^^ -Don't use. Use Clear. - -US -^^ -Correct as is, no periods. - -User -^^^^ -When referring to the reader, use "you" instead of "user." For example, "The user must..." is incorrect. Use "You must..." instead. If referring to more than one user, calling the collection "users" is acceptable, such as "Other users may wish to access your database." - -Username -^^^^^^^^ -Correct. Do not use "user name." - -View -^^^^ -When using as a reference ("View the documentation available online."), do not use View. Use "Refer to" instead. - -Within -^^^^^^ -Don't use to refer to a file that exists in a directory. Use "In". - -World Wide Web -^^^^^^^^^^^^^^ -Correct. Capitalize each word. Abbreviate as "WWW" or "Web." - -Webpage -^^^^^^^ -Correct. Do not use "web page" or "Web page." - -Web server -^^^^^^^^^^ -Correct. Do not use "webserver". For example, "The Apache HTTP Server is the default Web server..." - -Website -^^^^^^^ -Correct. Do not use "web site" or "Web site." For example, "The Ansible website contains ..." - -Who/whom -^^^^^^^^ -Use the pronoun "who" as a subject. Use the pronoun "whom" as a direct object, an indirect object, or the object of a preposition. For example: Who owns this? To whom does this belong? - -Will -^^^^ -Do not use future tense unless it is absolutely necessary. For instance, do not use the sentence, "The next section will describe the process in more detail." Instead, use the sentence, "The next section describes the process in more detail." - -Wish -^^^^ -Use "need" instead of "desire" and "wish." Use "want" when the reader's actions are optional (that is, they may not "need" something but may still "want" something). - -x86 -^^^ -Correct. Do not capitalize the "x." - -x86_64 -^^^^^^ -Do not use. Do not use "Hammer". Always use "AMD64 and Intel® EM64T" when referring to this architecture. - -You -^^^ -Correct. Do not use "I," "he," or "she." - -You may -^^^^^^^ -Try to avoid using this. For example, "you may" can be eliminated from this sentence "You may double-click on the desktop..." - diff --git a/docs/docsite/rst/dev_guide/style_guide/trademarks.rst b/docs/docsite/rst/dev_guide/style_guide/trademarks.rst deleted file mode 100644 index 6e1fb276d3a..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/trademarks.rst +++ /dev/null @@ -1,95 +0,0 @@ - -Trademark Usage ---------------- -Why is it important to use the TM, SM, and ® for our registered marks? - -Before a trademark is registered with the United States Patent and Trademark Office it is appropriate to use the TM or SM symbol depending whether the product is for goods or services. It is important to use the TM or SM as it is notification to the public that Ansible claims rights to the mark even though it has not yet been registered. - -Once the trademark is registered, it is appropriate to use the symbol in place of the TM or SM. The symbol designation must be used in conjunction with the trademark if Ansible is to fully protect its rights. If we don't protect these marks, we run the risk of losing them in the way of Aspirin or Trampoline or Escalator. - -General Rules: -^^^^^^^^^^^^^^ - -Trademarks should be used on 1st references on a page or within a section. - -Use Red Hat® Ansible® Automation Platform or Ansible®, on first reference when referring to products. - -Use "Ansible" alone as the company name, as in "Ansible announced quarterly results," which is not marked. - -Also add the trademark disclaimer. -* When using Ansible trademarks in the body of written text, you should use the following credit line in a prominent place, usually a footnote. - - For Registered Trademarks: - - [Name of Trademark] is a registered trademark of Red Hat, Inc. in the United States and other countries. - - For Unregistered Trademarks (TMs/SMs): - - [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries. - - For registered and unregistered trademarks: - - [Name of Trademark] is a registered trademark and [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries. - -Guidelines for the proper use of trademarks: -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Always distinguish trademarks from surround text with at least initial capital letters or in all capital letters. - -Always use proper trademark form and spelling. - -Never use a trademark as a noun. Always use a trademark as an adjective modifying the noun. - - Correct: - Red Hat® Ansible® Automation Platform system performance is incredible. - - Incorrect: - Ansible's performance is incredible. - -Never use a trademark as a verb. Trademarks are products or services, never actions. - - Correct: - "Orchestrate your entire network using Red Hat® Ansible® Automation Platform." - - Incorrect: - "Ansible your entire network." - -Never modify a trademark to a plural form. Instead, change the generic word from the singular to the plural. - - Correct: - "Corporate demand for Red Hat® Ansible® Automation Platform software is surging." - - Incorrect: - "Corporate demand for Ansible is surging." - -Never modify a trademark from its possessive form, or make a trademark possessive. Always use it in the form it has been registered. - -Never translate a trademark into another language. - -Never use trademarks to coin new words or names. - -Never use trademarks to create a play on words. - -Never alter a trademark in any way including through unapproved fonts or visual identifiers. - -Never abbreviate or use any Ansible trademarks as an acronym. - -The importance of Ansible trademarks -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The Ansible trademark and the "A" logo in a shaded circle are our most valuable assets. The value of these trademarks encompass the Ansible Brand. Effective trademark use is more than just a name, it defines the level of quality the customer will receive and it ties a product or service to a corporate image. A trademark may serve as the basis for many of our everyday decisions and choices. The Ansible Brand is about how we treat customers and each other. In order to continue to build a stronger more valuable Brand we must use it in a clear and consistent manner. - -The mark consists of the letter "A" in a shaded circle. As of 5/11/15, this was a pending trademark (registration in process). - -Common Ansible Trademarks -^^^^^^^^^^^^^^^^^^^^^^^^^ -* Ansible® - -Other Common Trademarks and Resource Sites: -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Linux is a registered trademark of Linus Torvalds. -- UNIX® is a registered trademark of The Open Group. -- Microsoft, Windows, Vista, XP, and NT are registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/en-us.aspx -- Apple, Mac, Mac OS, Macintosh, Pages and TrueType are either registered trademarks or trademarks of Apple Computer, Inc. in the United States and/or other countries. https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html -- Adobe, Acrobat, GoLive, InDesign, Illustrator, PostScript , PhotoShop and the OpenType logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. https://www.adobe.com/legal/permissions/trademarks.html -- Macromedia and Macromedia Flash are trademarks of Macromedia, Inc. https://www.adobe.com/legal/permissions/trademarks.html -- IBM is a registered trademark of International Business Machines Corporation. https://www.ibm.com/legal/us/en/copytrade.shtml -- Celeron, Celeron Inside, Centrino, Centrino logo, Core Inside, Intel Core, Intel Inside, Intel Inside logo, Itanium, Itanium Inside, Pentium, Pentium Inside,VTune, Xeon, and Xeon Inside are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. https://www.intel.com/content/www/us/en/legal/trademarks.html - diff --git a/docs/docsite/rst/dev_guide/style_guide/voice_style.rst b/docs/docsite/rst/dev_guide/style_guide/voice_style.rst deleted file mode 100644 index b15029df2fa..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/voice_style.rst +++ /dev/null @@ -1,20 +0,0 @@ - -Voice Style -=========== -The essence of the Ansible writing style is short sentences that flow naturally together. Mix up sentence structures. Vary sentence subjects. Address the reader directly. Ask a question. And when the reader adjusts to the pace of shorter sentences, write a longer one. - -- Write how real people speak... -- ...but try to avoid slang and colloquialisms that might not translate well into other languages. -- Say big things with small words. -- Be direct. Tell the reader exactly what you want them to do. -- Be honest. -- Short sentences show confidence. -- Grammar rules are meant to be bent, but only if the reader knows you are doing this. -- Choose words with fewer syllables for faster reading and better understanding. -- Think of copy as one-on-one conversations rather than as a speech. It's more difficult to ignore someone who is speaking to you directly. -- When possible, start task-oriented sentences (those that direct a user to do something) with action words. For example: Find software... Contact support... Install the media.... and so forth. - -Active Voice ------------- -Use the active voice ("Start Linuxconf by typing...") rather than passive ("Linuxconf can be started by typing...") whenever possible. Active voice makes for more lively, interesting reading. -Also avoid future tense (or using the term "will") whenever possible For example, future tense ("The screen will display...") does not read as well as an active voice ("The screen displays"). Remember, the users you are writing for most often refer to the documentation while they are using the system, not after or in advance of using the system. diff --git a/docs/docsite/rst/dev_guide/style_guide/why_use.rst b/docs/docsite/rst/dev_guide/style_guide/why_use.rst deleted file mode 100644 index 8ed840ac36a..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/why_use.rst +++ /dev/null @@ -1,23 +0,0 @@ -:orphan: - -Why Use a Style Guide? -"""""""""""""""""""""" - -Style guides are important because they ensure consistency in the content, look, and feel of a book or a website. - -Remember, a style guide is only useful if it is used, updated, and enforced. Style Guides are useful for engineering-related documentation, sales and marketing materials, support docs, community contributions, and more. - -As changes are made to the overall Ansible site design, be sure to update this style guide with those changes. Or, should other resources listed below have major revisions, consider including company information here for ease of reference. - -This style guide incorporates current Ansible resources and information so that overall site and documentation consistency can be met. - -.. raw:: html - -
    - - "If you don't find it in the index, look very carefully through the entire catalogue." - ― Sears, Roebuck and Co., 1897 Sears Roebuck & Co. Catalogue - -.. raw:: html - -
    diff --git a/docs/docsite/rst/dev_guide/testing.rst b/docs/docsite/rst/dev_guide/testing.rst deleted file mode 100644 index 6b4716ddfec..00000000000 --- a/docs/docsite/rst/dev_guide/testing.rst +++ /dev/null @@ -1,245 +0,0 @@ -.. _developing_testing: - -*************** -Testing Ansible -*************** - -.. contents:: - :local: - - -Why test your Ansible contributions? -==================================== - -If you're a developer, one of the most valuable things you can do is to look at GitHub issues and help fix bugs, since bug-fixing is almost always prioritized over feature development. Even for non-developers, helping to test pull requests for bug fixes and features is still immensely valuable. - -Ansible users who understand how to write playbooks and roles should be able to test their work. GitHub pull requests will automatically run a variety of tests (for example, Azure Pipelines) that show bugs in action. However, contributors must also test their work outside of the automated GitHub checks and show evidence of these tests in the PR to ensure that their work will be more likely to be reviewed and merged. - -Read on to learn how Ansible is tested, how to test your contributions locally, and how to extend testing capabilities. - -If you want to learn about testing collections, read :ref:`testing_collections` - - - -Types of tests -============== - -At a high level we have the following classifications of tests: - -:sanity: - * :ref:`testing_sanity` - * Sanity tests are made up of scripts and tools used to perform static code analysis. - * The primary purpose of these tests is to enforce Ansible coding standards and requirements. -:integration: - * :ref:`testing_integration` - * Functional tests of modules and Ansible core functionality. -:units: - * :ref:`testing_units` - * Tests directly against individual parts of the code base. - - -Testing within GitHub & Azure Pipelines -======================================= - - -Organization ------------- - -When Pull Requests (PRs) are created they are tested using Azure Pipelines, a Continuous Integration (CI) tool. Results are shown at the end of every PR. - -When Azure Pipelines detects an error and it can be linked back to a file that has been modified in the PR then the relevant lines will be added as a GitHub comment. For example: - -.. code-block:: text - - The test `ansible-test sanity --test pep8` failed with the following errors: - - lib/ansible/modules/network/foo/bar.py:509:17: E265 block comment should start with '# ' - - The test `ansible-test sanity --test validate-modules` failed with the following error: - lib/ansible/modules/network/foo/bar.py:0:0: E307 version_added should be 2.4. Currently 2.3 - -From the above example we can see that ``--test pep8`` and ``--test validate-modules`` have identified an issue. The commands given allow you to run the same tests locally to ensure you've fixed all issues without having to push your changes to GitHub and wait for Azure Pipelines, for example: - -If you haven't already got Ansible available, use the local checkout by running: - -.. code-block:: shell-session - - source hacking/env-setup - -Then run the tests detailed in the GitHub comment: - -.. code-block:: shell-session - - ansible-test sanity --test pep8 - ansible-test sanity --test validate-modules - -If there isn't a GitHub comment stating what's failed you can inspect the results by clicking on the "Details" button under the "checks have failed" message at the end of the PR. - -Rerunning a failing CI job --------------------------- - -Occasionally you may find your PR fails due to a reason unrelated to your change. This could happen for several reasons, including: - -* a temporary issue accessing an external resource, such as a yum or git repo -* a timeout creating a virtual machine to run the tests on - -If either of these issues appear to be the case, you can rerun the Azure Pipelines test by: - -* adding a comment with ``/rebuild`` (full rebuild) or ``/rebuild_failed`` (rebuild only failed CI nodes) to the PR -* closing and re-opening the PR (full rebuild) -* making another change to the PR and pushing to GitHub - -If the issue persists, please contact us in the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). - - -How to test a PR -================ - -Ideally, code should add tests that prove that the code works. That's not always possible and tests are not always comprehensive, especially when a user doesn't have access to a wide variety of platforms, or is using an API or web service. In these cases, live testing against real equipment can be more valuable than automation that runs against simulated interfaces. In any case, things should always be tested manually the first time as well. - -Thankfully, helping to test Ansible is pretty straightforward, assuming you are familiar with how Ansible works. - -Setup: Checking out a Pull Request ----------------------------------- - -You can do this by: - -* checking out Ansible -* fetching the proposed changes into a test branch -* testing -* commenting on that particular issue on GitHub - -Here's how: - -.. warning:: - Testing source code from GitHub pull requests sent to us does have some inherent risk, as the source code - sent may have mistakes or malicious code that could have a negative impact on your system. We recommend - doing all testing on a virtual machine, whether a cloud instance, or locally. Some users like Vagrant - or Docker for this, but they are optional. It is also useful to have virtual machines of different Linux or - other flavors, since some features (for example, package managers such as apt or yum) are specific to those OS versions. - - -Create a fresh area to work: - -.. code-block:: shell-session - - git clone https://github.com/ansible/ansible.git ansible-pr-testing - cd ansible-pr-testing - -Next, find the pull request you'd like to test and make note of its number. It will look something like this: - -.. code-block:: text - - Use os.path.sep instead of hardcoding / #65381 - -.. note:: Only test ``ansible:devel`` - - It is important that the PR request target be ``ansible:devel``, as we do not accept pull requests into any other branch. Dot releases are cherry-picked manually by Ansible staff. - -Use the pull request number when you fetch the proposed changes and create your branch for testing: - -.. code-block:: shell-session - - git fetch origin refs/pull/XXXX/head:testing_PRXXXX - git checkout testing_PRXXXX - -The first command fetches the proposed changes from the pull request and creates a new branch named ``testing_PRXXXX``, where the XXXX is the actual number associated with the pull request (for example, 65381). The second command checks out the newly created branch. - -.. note:: - If the GitHub user interface shows that the pull request will not merge cleanly, we do not recommend proceeding if you are not somewhat familiar with git and coding, as you will have to resolve a merge conflict. This is the responsibility of the original pull request contributor. - -.. note:: - Some users do not create feature branches, which can cause problems when they have multiple, unrelated commits in their version of ``devel``. If the source looks like ``someuser:devel``, make sure there is only one commit listed on the pull request. - -The Ansible source includes a script that allows you to use Ansible directly from source without requiring a -full installation that is frequently used by developers on Ansible. - -Simply source it (to use the Linux/Unix terminology) to begin using it immediately: - -.. code-block:: shell-session - - source ./hacking/env-setup - -This script modifies the ``PYTHONPATH`` environment variables (along with a few other things), which will be temporarily -set as long as your shell session is open. - -Testing the Pull Request ------------------------- - -At this point, you should be ready to begin testing! - -Some ideas of what to test are: - -* Create a test Playbook with the examples in and check if they function correctly -* Test to see if any Python backtraces returned (that's a bug) -* Test on different operating systems, or against different library versions - -Run sanity tests -^^^^^^^^^^^^^^^^ - -.. code:: shell - - ansible-test sanity - -More information: :ref:`testing_sanity` - -Run unit tests -^^^^^^^^^^^^^^ - -.. code:: shell - - ansible-test units - -More information: :ref:`testing_units` - -Run integration tests -^^^^^^^^^^^^^^^^^^^^^ - -.. code:: shell - - ansible-test integration -v ping - -More information: :ref:`testing_integration` - -Any potential issues should be added as comments on the pull request (and it's acceptable to comment if the feature works as well), remembering to include the output of ``ansible --version`` - -Example: - -.. code-block:: text - - Works for me! Tested on `Ansible 2.3.0`. I verified this on CentOS 6.5 and also Ubuntu 14.04. - -If the PR does not resolve the issue, or if you see any failures from the unit/integration tests, just include that output instead: - - | This change causes errors for me. - | - | When I ran this Ubuntu 16.04 it failed with the following: - | - | \``` - | some output - | StackTrace - | some other output - | \``` - -Code Coverage Online -^^^^^^^^^^^^^^^^^^^^ - -`The online code coverage reports `_ are a good way -to identify areas for testing improvement in Ansible. By following red colors you can -drill down through the reports to find files which have no tests at all. Adding both -integration and unit tests which show clearly how code should work, verify important -Ansible functions and increase testing coverage in areas where there is none is a valuable -way to help improve Ansible. - -The code coverage reports only cover the ``devel`` branch of Ansible where new feature -development takes place. Pull requests and new code will be missing from the codecov.io -coverage reports so local reporting is needed. Most ``ansible-test`` commands allow you -to collect code coverage, this is particularly useful to indicate where to extend -testing. See :ref:`testing_running_locally` for more information. - - -Want to know more about testing? -================================ - -If you'd like to know more about the plans for improving testing Ansible then why not join the -`Testing Working Group `_. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/action-plugin-docs.rst b/docs/docsite/rst/dev_guide/testing/sanity/action-plugin-docs.rst deleted file mode 100644 index e3a5d8b838d..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/action-plugin-docs.rst +++ /dev/null @@ -1,4 +0,0 @@ -action-plugin-docs -================== - -Each action plugin should have a matching module of the same name to provide documentation. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/ansible-doc.rst b/docs/docsite/rst/dev_guide/testing/sanity/ansible-doc.rst deleted file mode 100644 index 9f2c4f5f458..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/ansible-doc.rst +++ /dev/null @@ -1,4 +0,0 @@ -ansible-doc -=========== - -Verifies that ``ansible-doc`` can parse module documentation on all supported Python versions. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/ansible-requirements.rst b/docs/docsite/rst/dev_guide/testing/sanity/ansible-requirements.rst deleted file mode 100644 index f348b07f00b..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/ansible-requirements.rst +++ /dev/null @@ -1,4 +0,0 @@ -ansible-requirements -==================== - -``test/lib/ansible_test/_data/requirements/sanity.import-plugins.txt`` must be an identical copy of ``requirements.txt`` found in the project's root. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/ansible-test-future-boilerplate.rst b/docs/docsite/rst/dev_guide/testing/sanity/ansible-test-future-boilerplate.rst deleted file mode 100644 index 43dfe324650..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/ansible-test-future-boilerplate.rst +++ /dev/null @@ -1,8 +0,0 @@ -ansible-test-future-boilerplate -=============================== - -The ``_internal`` code for ``ansible-test`` requires the following ``__future__`` import: - -.. code-block:: python - - from __future__ import annotations diff --git a/docs/docsite/rst/dev_guide/testing/sanity/ansible-var-precedence-check.rst b/docs/docsite/rst/dev_guide/testing/sanity/ansible-var-precedence-check.rst deleted file mode 100644 index 1906886f4ff..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/ansible-var-precedence-check.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -ansible-var-precedence-check -============================ - -Check the order of precedence for Ansible variables against :ref:`ansible_variable_precedence`. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/azure-requirements.rst b/docs/docsite/rst/dev_guide/testing/sanity/azure-requirements.rst deleted file mode 100644 index 5e0cc04444c..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/azure-requirements.rst +++ /dev/null @@ -1,10 +0,0 @@ -:orphan: - -azure-requirements -================== - -Update the Azure integration test requirements file when changes are made to the Azure packaging requirements file: - -.. code-block:: bash - - cp packaging/requirements/requirements-azure.txt test/lib/ansible_test/_data/requirements/integration.cloud.azure.txt diff --git a/docs/docsite/rst/dev_guide/testing/sanity/bin-symlinks.rst b/docs/docsite/rst/dev_guide/testing/sanity/bin-symlinks.rst deleted file mode 100644 index a8e33a7f445..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/bin-symlinks.rst +++ /dev/null @@ -1,11 +0,0 @@ -bin-symlinks -============ - -The ``bin/`` directory in Ansible must contain only symbolic links to executable files. -These files must reside in the ``lib/ansible/`` or ``test/lib/ansible_test/`` directories. - -This is required to allow ``ansible-test`` to work with containers and remote hosts when running from an installed version of Ansible. - -Symlinks for each entry point in ``bin/`` must also be present in ``test/lib/ansible_test/_util/target/injector/``. -Each symlink should point to the ``python.py`` script in the same directory. -This facilitates running with the correct Python interpreter and enabling code coverage. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/boilerplate.rst b/docs/docsite/rst/dev_guide/testing/sanity/boilerplate.rst deleted file mode 100644 index 51c0c089428..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/boilerplate.rst +++ /dev/null @@ -1,11 +0,0 @@ -:orphan: - -boilerplate -=========== - -Most Python files should include the following boilerplate: - -.. code-block:: python - - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type diff --git a/docs/docsite/rst/dev_guide/testing/sanity/botmeta.rst b/docs/docsite/rst/dev_guide/testing/sanity/botmeta.rst deleted file mode 100644 index 639bb0bf017..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/botmeta.rst +++ /dev/null @@ -1,4 +0,0 @@ -botmeta -======= - -Verifies that ``./github/BOTMETA.yml`` is valid. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/changelog.rst b/docs/docsite/rst/dev_guide/testing/sanity/changelog.rst deleted file mode 100644 index 2d557c72d5f..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/changelog.rst +++ /dev/null @@ -1,19 +0,0 @@ -changelog -========= - -Basic linting of changelog fragments with `antsibull-changelog lint `_. - -One or more of the following sections are required: - -- major_changes -- minor_changes -- breaking_changes -- deprecated_features -- removed_features -- security_fixes -- bugfixes -- known_issues - -New modules and plugins must not be included in changelog fragments. - -See :ref:`collection_changelogs` for details. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/compile.rst b/docs/docsite/rst/dev_guide/testing/sanity/compile.rst deleted file mode 100644 index 40367218cdf..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/compile.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _testing_compile: - -compile -======= - -All Python source files must successfully compile using all supported Python versions. - -.. note:: - - The list of supported Python versions is dependent on the version of ``ansible-core`` that you are using. - Make sure you consult the version of the documentation which matches your ``ansible-core`` version. - -Controller code, including plugins in Ansible Collections, must support the following Python versions: - -- 3.11 -- 3.10 -- 3.9 - -Code which runs on targets (``modules`` and ``module_utils``) must support all controller supported Python versions, -as well as the additional Python versions supported only on targets: - -- 3.8 -- 3.7 -- 3.6 -- 3.5 -- 2.7 - -.. note:: - - Ansible Collections can be - `configured `_ - to support a subset of the target-only Python versions. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/configure-remoting-ps1.rst b/docs/docsite/rst/dev_guide/testing/sanity/configure-remoting-ps1.rst deleted file mode 100644 index e83bc78d897..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/configure-remoting-ps1.rst +++ /dev/null @@ -1,5 +0,0 @@ -configure-remoting-ps1 -====================== - -The file ``examples/scripts/ConfigureRemotingForAnsible.ps1`` is required and must be a regular file. -It is used by external automated processes and cannot be moved, renamed or replaced with a symbolic link. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/deprecated-config.rst b/docs/docsite/rst/dev_guide/testing/sanity/deprecated-config.rst deleted file mode 100644 index 950805a282d..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/deprecated-config.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -deprecated-config -================= - -``DOCUMENTATION`` config is scheduled for removal diff --git a/docs/docsite/rst/dev_guide/testing/sanity/docs-build.rst b/docs/docsite/rst/dev_guide/testing/sanity/docs-build.rst deleted file mode 100644 index 23f3c5524ba..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/docs-build.rst +++ /dev/null @@ -1,4 +0,0 @@ -docs-build -========== - -Verifies that ``make singlehtmldocs`` in ``docs/docsite/`` completes without errors. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/empty-init.rst b/docs/docsite/rst/dev_guide/testing/sanity/empty-init.rst deleted file mode 100644 index e87bb71ed60..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/empty-init.rst +++ /dev/null @@ -1,10 +0,0 @@ -empty-init -========== - -The ``__init__.py`` files under the following directories must be empty. For some of these (modules -and tests), ``__init__.py`` files with code won't be used. For others (module_utils), we want the -possibility of using Python namespaces which an empty ``__init__.py`` will allow for. - -- ``lib/ansible/modules/`` -- ``lib/ansible/module_utils/`` -- ``test/units/`` diff --git a/docs/docsite/rst/dev_guide/testing/sanity/future-import-boilerplate.rst b/docs/docsite/rst/dev_guide/testing/sanity/future-import-boilerplate.rst deleted file mode 100644 index 658ef064442..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/future-import-boilerplate.rst +++ /dev/null @@ -1,51 +0,0 @@ -future-import-boilerplate -========================= - -Most Python files should include the following boilerplate at the top of the file, right after the -comment header: - -.. code-block:: python - - from __future__ import (absolute_import, division, print_function) - -This uses Python 3 semantics for absolute versus relative imports, division, and print. By doing this, -we can write code which is portable between Python 2 and Python 3 by following the Python 3 semantics. - - -absolute_import ---------------- - -When Python 2 encounters an import of a name in a file like ``import copy`` it attempts to load -``copy.py`` from the same directory as the file is in. This can cause problems if there is a python -file of that name in the directory and also a python module in ``sys.path`` with that same name. In -that case, Python 2 would load the one in the same directory and there would be no way to load the -one on ``sys.path``. Python 3 fixes this by making imports absolute by default. ``import copy`` -will find ``copy.py`` from ``sys.path``. If you want to import ``copy.py`` from the same directory, -the code needs to be changed to perform a relative import: ``from . import copy``. - -.. seealso:: - - * `Absolute and relative imports `_ - -division --------- - -In Python 2, the division operator (``/``) returns integer values when used with integers. If there -was a remainder, this part would be left off (aka, `floor division`). In Python 3, the division -operator (``/``) always returns a floating point number. Code that needs to calculate the integer -portion of the quotient needs to switch to using the floor division operator (`//`) instead. - -.. seealso:: - - * `Changing the division operator `_ - -print_function --------------- - -In Python 2, :func:`python:print` is a keyword. In Python 3, :func:`python3:print` is a function with different -parameters. Using this ``__future__`` allows using the Python 3 print semantics everywhere. - -.. seealso:: - - * `Make print a function `_ - diff --git a/docs/docsite/rst/dev_guide/testing/sanity/ignores.rst b/docs/docsite/rst/dev_guide/testing/sanity/ignores.rst deleted file mode 100644 index 69190c8d739..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/ignores.rst +++ /dev/null @@ -1,105 +0,0 @@ -ignores -======= - -Sanity tests for individual files can be skipped, and specific errors can be ignored. - -When to Ignore Errors ---------------------- - -Sanity tests are designed to improve code quality and identify common issues with content. -When issues are identified during development, those issues should be corrected. - -As development of Ansible continues, sanity tests are expanded to detect issues that previous releases could not. -To allow time for existing content to be updated to pass newer tests, ignore entries can be added. -New content should not use ignores for existing sanity tests. - -When code is fixed to resolve sanity test errors, any relevant ignores must also be removed. -If the ignores are not removed, this will be reported as an unnecessary ignore error. -This is intended to prevent future regressions due to the same error recurring after being fixed. - -When to Skip Tests ------------------- - -Although rare, there are reasons for skipping a sanity test instead of ignoring the errors it reports. - -If a sanity test results in a traceback when processing content, that error cannot be ignored. -If this occurs, open a new `bug report `_ for the issue so it can be fixed. -If the traceback occurs due to an issue with the content, that issue should be fixed. -If the content is correct, the test will need to be skipped until the bug in the sanity test is fixed. - - Caution should be used when skipping sanity tests instead of ignoring them. - Since the test is skipped entirely, resolution of the issue will not be automatically detected. - This will prevent prevent regression detection from working once the issue has been resolved. - For this reason it is a good idea to periodically review skipped entries manually to verify they are required. - -Ignore File Location --------------------- - -The location of the ignore file depends on the type of content being tested. - -Ansible Collections -^^^^^^^^^^^^^^^^^^^ - -Since sanity tests change between Ansible releases, a separate ignore file is needed for each Ansible major release. - -The filename is ``tests/sanity/ignore-X.Y.txt`` where ``X.Y`` is the Ansible release being used to test the collection. - -Maintaining a separate file for each Ansible release allows a collection to pass tests for multiple versions of Ansible. - -Ansible -^^^^^^^ - -When testing Ansible, all ignores are placed in the ``test/sanity/ignore.txt`` file. - -Only a single file is needed because ``ansible-test`` is developed and released as a part of Ansible itself. - -Ignore File Format ------------------- - -The ignore file contains one entry per line. -Each line consists of two columns, separated by a single space. -Comments may be added at the end of an entry, started with a hash (``#``) character, which can be proceeded by zero or more spaces. -Blank and comment only lines are not allowed. - -The first column specifies the file path that the entry applies to. -File paths must be relative to the root of the content being tested. -This is either the Ansible source or an Ansible collection. -File paths cannot contain a space or the hash (``#``) character. - -The second column specifies the sanity test that the entry applies to. -This will be the name of the sanity test. -If the sanity test is specific to a version of Python, the name will include a dash (``-``) and the relevant Python version. -If the named test uses error codes then the error code to ignore must be appended to the name of the test, separated by a colon (``:``). - -Below are some example ignore entries for an Ansible collection: - -.. code-block:: text - - roles/my_role/files/my_script.sh shellcheck:SC2154 # ignore undefined variable - plugins/modules/my_module.py validate-modules:missing-gplv3-license # ignore license check - plugins/modules/my_module.py import-3.8 # needs update to support collections.abc on Python 3.8+ - -It is also possible to skip a sanity test for a specific file. -This is done by adding ``!skip`` after the sanity test name in the second column. -When this is done, no error code is included, even if the sanity test uses error codes. - -Below are some example skip entries for an Ansible collection: - -.. code-block:: text - - plugins/module_utils/my_util.py validate-modules!skip # waiting for bug fix in module validator - plugins/lookup/my_plugin.py compile-2.6!skip # Python 2.6 is not supported on the controller - -See the full list of :ref:`sanity tests `, which details the various tests and details how to fix identified issues. - -Ignore File Errors ------------------- - -There are various errors that can be reported for the ignore file itself: - -- syntax errors parsing the ignore file -- references a file path that does not exist -- references to a sanity test that does not exist -- ignoring an error that does not occur -- ignoring a file which is skipped -- duplicate entries diff --git a/docs/docsite/rst/dev_guide/testing/sanity/import.rst b/docs/docsite/rst/dev_guide/testing/sanity/import.rst deleted file mode 100644 index ddfe1217f02..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/import.rst +++ /dev/null @@ -1,137 +0,0 @@ -import -====== - -Ansible :ref:`allows unchecked imports` of some libraries from specific directories. -Importing any other Python library requires :ref:`handling import errors`. -This enables support for sanity tests such as :ref:`testing_validate-modules` and provides better error messages to the user. - -.. _handling_import_errors: - -Handling import errors ----------------------- - -Ansible executes across many hosts and can use multiple Python interpreters at the same time, which may even have different versions. -To ensure users get an actionable and easy to understand error we try to ensure any non-core imports in modules/plugins are guarded to avoid a traceback, -which most users won't be able to understand, much less use to solve the issue. - -Another reason Ansible does this is to import the code for inspection. This allows Ansible to easily test, document, configure, etc based on the code without having to install -any and all requirements everywhere, especially when that is not the context in which you execute the code. - -The code below shows examples of how to avoid errors on import and then use the provided ``missing_required_lib`` to ensure the user knows which LIBRARY is missing, -on which HOST it is missing and the specific INTERPRETER that requires it. - - -In modules -^^^^^^^^^^ - -Instead of using ``import another_library``: - -.. code-block:: python - - import traceback - - from ansible.module_utils.basic import missing_required_lib - - try: - import another_library - except ImportError: - HAS_ANOTHER_LIBRARY = False - ANOTHER_LIBRARY_IMPORT_ERROR = traceback.format_exc() - else: - HAS_ANOTHER_LIBRARY = True - ANOTHER_LIBRARY_IMPORT_ERROR = None - -.. note:: - - The ``missing_required_lib`` import above will be used below. - -Then in the module code, normally inside the ``main`` method: - -.. code-block:: python - - module = AnsibleModule(...) - - if not HAS_ANOTHER_LIBRARY: - module.fail_json( - msg=missing_required_lib('another_library'), - exception=ANOTHER_LIBRARY_IMPORT_ERROR) - -In plugins -^^^^^^^^^^ - -Instead of using ``import another_library``: - -.. code-block:: python - - try: - import another_library - except ImportError as imp_exc: - ANOTHER_LIBRARY_IMPORT_ERROR = imp_exc - else: - ANOTHER_LIBRARY_IMPORT_ERROR = None - -Then in the plugin code, for example in the ``run`` method of the plugin (some plugins don't have a ``run`` method and will require it in the ``__init__`` method instead): - -.. code-block:: python - - if ANOTHER_LIBRARY_IMPORT_ERROR: - raise AnsibleError('another_library must be installed to use this plugin') from ANOTHER_LIBRARY_IMPORT_ERROR - -When used as base classes -^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. important:: - - This solution builds on the previous two examples. - Make sure to pick the appropriate one before continuing with this solution. - -Sometimes an import is used in a base class, for example: - -.. code-block:: python - - from another_library import UsefulThing - - class CustomThing(UsefulThing): - pass - -One option is make the entire class definition conditional: - -.. code-block:: python - - if not ANOTHER_LIBRARY_IMPORT_ERROR: - class CustomThing(UsefulThing): - pass - -Another option is to define a substitute base class by modifying the exception handler: - -.. code-block:: python - - try: - from another_library import UsefulThing - except ImportError: - class UsefulThing: - pass - ... - -.. _allowed_unchecked_imports: - -Allowed unchecked imports -------------------------- - -Ansible allows the following unchecked imports from these specific directories: - -* ansible-core: - - * For ``lib/ansible/modules/`` and ``lib/ansible/module_utils/``, unchecked imports are only allowed from the Python standard library; - * For ``lib/ansible/plugins/``, unchecked imports are only allowed from the Python standard library, from public dependencies of ansible-core, and from ansible-core itself; - -* collections: - - * For ``plugins/modules/`` and ``plugins/module_utils/``, unchecked imports are only allowed from the Python standard library; - * For other directories in ``plugins/`` (see `the community collection requirements `_ for a list), unchecked imports are only allowed from the Python standard library, from public dependencies of ansible-core, and from ansible-core itself. - -Public dependencies of ansible-core are: - - * Jinja2 - * PyYAML - * MarkupSafe (as a dependency of Jinja2) diff --git a/docs/docsite/rst/dev_guide/testing/sanity/integration-aliases.rst b/docs/docsite/rst/dev_guide/testing/sanity/integration-aliases.rst deleted file mode 100644 index 1d70dbc78e8..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/integration-aliases.rst +++ /dev/null @@ -1,183 +0,0 @@ -integration-aliases -=================== - -Integration tests are executed by ``ansible-test`` and reside in directories under ``test/integration/targets/``. -Each test MUST have an ``aliases`` file to control test execution. - -Aliases are explained in the following sections. Each alias must be on a separate line in an ``aliases`` file. - -Groups ------- - -Tests must be configured to run in exactly one group. This is done by adding the appropriate group to the ``aliases`` file. - -The following are examples of some of the available groups: - -- ``shippable/posix/group1`` -- ``shippable/windows/group2`` -- ``shippable/azure/group3`` -- ``shippable/aws/group1`` -- ``shippable/cloud/group1`` - -Groups are used to balance tests across multiple CI jobs to minimize test run time. -They also improve efficiency by keeping tests with similar requirements running together. - -When selecting a group for a new test, use the same group as existing tests similar to the one being added. -If more than one group is available, select one randomly. - -Setup ------ - -Aliases can be used to execute setup targets before running tests: - -- ``setup/once/TARGET`` - Run the target ``TARGET`` before the first target that requires it. -- ``setup/always/TARGET`` - Run the target ``TARGET`` before each target that requires it. - -Requirements ------------- - -Aliases can be used to express some test requirements: - -- ``needs/privileged`` - Requires ``--docker-privileged`` when running tests with ``--docker``. -- ``needs/root`` - Requires running tests as ``root`` or with ``--docker``. -- ``needs/ssh`` - Requires SSH connections to localhost (or the test container with ``--docker``) without a password. -- ``needs/httptester`` - Requires use of the http-test-container to run tests. - -Dependencies ------------- - -Some test dependencies are automatically discovered: - -- Ansible role dependencies defined in ``meta/main.yml`` files. -- Setup targets defined with ``setup/*`` aliases. -- Symbolic links from one target to a file in another target. - -Aliases can be used to declare dependencies that are not handled automatically: - -- ``needs/target/TARGET`` - Requires use of the test target ``TARGET``. -- ``needs/file/PATH`` - Requires use of the file ``PATH`` relative to the git root. - -Skipping --------- - -Aliases can be used to skip platforms using one of the following: - -- ``skip/freebsd`` - Skip tests on FreeBSD. -- ``skip/macos`` - Skip tests on macOS. -- ``skip/rhel`` - Skip tests on RHEL. -- ``skip/docker`` - Skip tests when running in a Docker container. - -Platform versions, as specified using the ``--remote`` option with ``/`` removed, can also be skipped: - -- ``skip/freebsd11.1`` - Skip tests on FreeBSD 11.1. -- ``skip/rhel7.6`` - Skip tests on RHEL 7.6. - -Windows versions, as specified using the ``--windows`` option can also be skipped: - -- ``skip/windows/2016`` - Skip tests on Windows Server 2016. -- ``skip/windows/2019`` - Skip tests on Windows Server 2019. -- ``skip/windows/2022`` - Skip tests on Windows Server 2022. - -Aliases can be used to skip Python major versions using one of the following: - -- ``skip/python2`` - Skip tests on Python 2.x. -- ``skip/python3`` - Skip tests on Python 3.x. - -For more fine grained skipping, use conditionals in integration test playbooks, such as: - -.. code-block:: yaml - - when: ansible_distribution in ('Ubuntu') - - -Miscellaneous -------------- - -There are several other aliases available as well: - -- ``destructive`` - Requires ``--allow-destructive`` to run without ``--docker`` or ``--remote``. -- ``hidden`` - Target is ignored. Usable as a dependency. Automatic for ``setup_`` and ``prepare_`` prefixed targets. -- ``retry/never`` - Target is excluded from retries enabled by the ``--retry-on-error`` option. - -Unstable --------- - -Tests which fail sometimes should be marked with the ``unstable`` alias until the instability has been fixed. -These tests will continue to run for pull requests which modify the test or the module under test. - -This avoids unnecessary test failures for other pull requests, as well as tests on merge runs and nightly CI jobs. - -There are two ways to run unstable tests manually: - -- Use the ``--allow-unstable`` option for ``ansible-test`` -- Prefix the test name with ``unstable/`` when passing it to ``ansible-test``. - -Tests will be marked as unstable by a member of the Ansible Core Team. -GitHub issues_ will be created to track each unstable test. - -Disabled --------- - -Tests which always fail should be marked with the ``disabled`` alias until they can be fixed. - -Disabled tests are automatically skipped. - -There are two ways to run disabled tests manually: - -- Use the ``--allow-disabled`` option for ``ansible-test`` -- Prefix the test name with ``disabled/`` when passing it to ``ansible-test``. - -Tests will be marked as disabled by a member of the Ansible Core Team. -GitHub issues_ will be created to track each disabled test. - -Unsupported ------------ - -Tests which cannot be run in CI should be marked with the ``unsupported`` alias. -Most tests can be supported through the use of simulators and/or cloud plugins. - -However, if that is not possible then marking a test as unsupported will prevent it from running in CI. - -There are two ways to run unsupported tests manually: - -* Use the ``--allow-unsupported`` option for ``ansible-test`` -* Prefix the test name with ``unsupported/`` when passing it to ``ansible-test``. - -Tests will be marked as unsupported by the contributor of the test. - -Cloud ------ - -Tests for cloud services and other modules that require access to external APIs usually require special support for testing in CI. - -These require an additional alias to indicate the required test plugin. - -Some of the available aliases are: - -- ``cloud/aws`` -- ``cloud/azure`` -- ``cloud/cs`` -- ``cloud/digitalocean`` -- ``cloud/openshift`` -- ``cloud/vcenter`` - -Untested --------- - -Every module and plugin should have integration tests, even if the tests cannot be run in CI. - -Issues ------- - -Tests that are marked as unstable_ or disabled_ will have an issue created to track the status of the test. -Each issue will be assigned to one of the following projects: - -- `AWS `_ -- `Azure `_ -- `Windows `_ -- `General `_ - -Questions ---------- - -For questions about integration tests reach out to @mattclay or @gundalow on GitHub or the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). diff --git a/docs/docsite/rst/dev_guide/testing/sanity/line-endings.rst b/docs/docsite/rst/dev_guide/testing/sanity/line-endings.rst deleted file mode 100644 index d56cfc12e53..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/line-endings.rst +++ /dev/null @@ -1,4 +0,0 @@ -line-endings -============ - -All files must use ``\n`` for line endings instead of ``\r\n``. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/metaclass-boilerplate.rst b/docs/docsite/rst/dev_guide/testing/sanity/metaclass-boilerplate.rst deleted file mode 100644 index c7327b39fa1..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/metaclass-boilerplate.rst +++ /dev/null @@ -1,23 +0,0 @@ -metaclass-boilerplate -===================== - -Most Python files should include the following boilerplate at the top of the file, right after the -comment header and ``from __future__ import``: - -.. code-block:: python - - __metaclass__ = type - - -Python 2 has "new-style classes" and "old-style classes" whereas Python 3 only has new-style classes. -Adding the ``__metaclass__ = type`` boilerplate makes every class defined in that file into -a new-style class as well. - -.. code-block:: python - - from __future__ import absolute_import, division, print_function - __metaclass__ = type - - class Foo: - # This is a new-style class even on Python 2 because of the __metaclass__ - pass diff --git a/docs/docsite/rst/dev_guide/testing/sanity/mypy.rst b/docs/docsite/rst/dev_guide/testing/sanity/mypy.rst deleted file mode 100644 index 9eb46bafca8..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/mypy.rst +++ /dev/null @@ -1,14 +0,0 @@ -mypy -==== - -The ``mypy`` static type checker is used to check the following code against each Python version supported by the controller: - - * ``lib/ansible/`` - * ``test/lib/ansible_test/_internal/`` - -Additionally, the following code is checked against Python versions supported only on managed nodes: - - * ``lib/ansible/modules/`` - * ``lib/ansible/module_utils/`` - -See `the mypy documentation `_ diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-assert.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-assert.rst deleted file mode 100644 index 489f917f624..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-assert.rst +++ /dev/null @@ -1,16 +0,0 @@ -no-assert -========= - -Do not use ``assert`` in production Ansible python code. When running Python -with optimizations, Python will remove ``assert`` statements, potentially -allowing for unexpected behavior throughout the Ansible code base. - -Instead of using ``assert`` you should utilize simple ``if`` statements, -that result in raising an exception. There is a new exception called -``AnsibleAssertionError`` that inherits from ``AnsibleError`` and -``AssertionError``. When possible, utilize a more specific exception -than ``AnsibleAssertionError``. - -Modules will not have access to ``AnsibleAssertionError`` and should instead -raise ``AssertionError``, a more specific exception, or just use -``module.fail_json`` at the failure point. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-basestring.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-basestring.rst deleted file mode 100644 index f2fea137ebd..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-basestring.rst +++ /dev/null @@ -1,11 +0,0 @@ -no-basestring -============= - -Do not use ``isinstance(s, basestring)`` as basestring has been removed in -Python3. You can import ``string_types``, ``binary_type``, or ``text_type`` -from ``ansible.module_utils.six`` and then use ``isinstance(s, string_types)`` -or ``isinstance(s, (binary_type, text_type))`` instead. - -If this is part of code to convert a string to a particular type, -``ansible.module_utils.common.text.converters`` contains several functions -that may be even better for you: ``to_text``, ``to_bytes``, and ``to_native``. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-dict-iteritems.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-dict-iteritems.rst deleted file mode 100644 index e231c796c47..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-dict-iteritems.rst +++ /dev/null @@ -1,16 +0,0 @@ -no-dict-iteritems -================= - -The ``dict.iteritems`` method has been removed in Python 3. There are two recommended alternatives: - -.. code-block:: python - - for KEY, VALUE in DICT.items(): - pass - -.. code-block:: python - - from ansible.module_utils.six import iteritems - - for KEY, VALUE in iteritems(DICT): - pass diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-dict-iterkeys.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-dict-iterkeys.rst deleted file mode 100644 index 9dc4a978550..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-dict-iterkeys.rst +++ /dev/null @@ -1,9 +0,0 @@ -no-dict-iterkeys -================ - -The ``dict.iterkeys`` method has been removed in Python 3. Use the following instead: - -.. code-block:: python - - for KEY in DICT: - pass diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-dict-itervalues.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-dict-itervalues.rst deleted file mode 100644 index 979450e418d..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-dict-itervalues.rst +++ /dev/null @@ -1,16 +0,0 @@ -no-dict-itervalues -================== - -The ``dict.itervalues`` method has been removed in Python 3. There are two recommended alternatives: - -.. code-block:: python - - for VALUE in DICT.values(): - pass - -.. code-block:: python - - from ansible.module_utils.six import itervalues - - for VALUE in itervalues(DICT): - pass diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-get-exception.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-get-exception.rst deleted file mode 100644 index 67f1646f21a..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-get-exception.rst +++ /dev/null @@ -1,28 +0,0 @@ -no-get-exception -================ - -We created a function, ``ansible.module_utils.pycompat24.get_exception`` to -help retrieve exceptions in a manner compatible with Python 2.4 through -Python 3.6. We no longer support Python 2.4 and Python 2.5 so this is -extraneous and we want to deprecate the function. Porting code should look -something like this: - -.. code-block:: python - - # Unfixed code: - try: - raise IOError('test') - except IOError: - e = get_exception() - do_something(e) - except: - e = get_exception() - do_something_else(e) - - # After fixing: - try: - raise IOError('test') - except IOErrors as e: - do_something(e) - except Exception as e: - do_something_else(e) diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-illegal-filenames.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-illegal-filenames.rst deleted file mode 100644 index 6e6f565eed8..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-illegal-filenames.rst +++ /dev/null @@ -1,61 +0,0 @@ -no-illegal-filenames -==================== - -Files and directories should not contain illegal characters or names so that -Ansible can be checked out on any Operating System. - -Illegal Characters ------------------- - -The following characters are not allowed to be used in any part of the file or -directory name; - -* ``<`` -* ``>`` -* ``:`` -* ``"`` -* ``/`` -* ``\`` -* ``|`` -* ``?`` -* ``*`` -* Any characters whose integer representations are in the range from 0 through to 31 like ``\n`` - -The following characters are not allowed to be used as the last character of a -file or directory; - -* ``.`` -* ``" "`` (just the space character) - -Illegal Names -------------- - -The following names are not allowed to be used as the name of a file or -directory excluding the extension; - -* ``CON`` -* ``PRN`` -* ``AUX`` -* ``NUL`` -* ``COM1`` -* ``COM2`` -* ``COM3`` -* ``COM4`` -* ``COM5`` -* ``COM6`` -* ``COM7`` -* ``COM8`` -* ``COM9`` -* ``LPT1`` -* ``LPT2`` -* ``LPT3`` -* ``LPT4`` -* ``LPT5`` -* ``LPT6`` -* ``LPT7`` -* ``LPT8`` -* ``LPT9`` - -For example, the file ``folder/COM1``, ``folder/COM1.txt`` are illegal but -``folder/COM1-file`` or ``folder/COM1-file.txt`` is allowed. - diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-main-display.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-main-display.rst deleted file mode 100644 index 271f88f1889..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-main-display.rst +++ /dev/null @@ -1,14 +0,0 @@ -no-main-display -=============== - -As of Ansible 2.8, ``Display`` should no longer be imported from ``__main__``. - -``Display`` is now a singleton and should be utilized like the following: - -.. code-block:: python - - from ansible.utils.display import Display - display = Display() - -There is no longer a need to attempt ``from __main__ import display`` inside -a ``try/except`` block. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst deleted file mode 100644 index 50dc7bafc92..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst +++ /dev/null @@ -1,4 +0,0 @@ -no-smart-quotes -=============== - -Smart quotes (``”“‘’``) should not be used. Use plain ascii quotes (``"'``) instead. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-tests-as-filters.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-tests-as-filters.rst deleted file mode 100644 index 0c1f99ac786..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-tests-as-filters.rst +++ /dev/null @@ -1,12 +0,0 @@ -:orphan: - -no-tests-as-filters -=================== - -Using Ansible provided Jinja2 tests as filters will be removed in Ansible 2.9. - -Prior to Ansible 2.5, Jinja2 tests included within Ansible were most often used as filters. The large difference in use is that filters are referenced as ``variable | filter_name`` while Jinja2 tests are referenced as ``variable is test_name``. - -Jinja2 tests are used for comparisons, whereas filters are used for data manipulation, and have different applications in Jinja2. This change is to help differentiate the concepts for a better understanding of Jinja2, and where each can be appropriately used. - -As of Ansible 2.5 using an Ansible provided Jinja2 test with filter syntax will display a deprecation error. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-underscore-variable.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-underscore-variable.rst deleted file mode 100644 index 5174a43adf7..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-underscore-variable.rst +++ /dev/null @@ -1,30 +0,0 @@ -:orphan: - -no-underscore-variable -====================== - -In the future, Ansible may use the identifier ``_`` to internationalize its -message strings. To be ready for that, we need to make sure that there are -no conflicting identifiers defined in the code base. - -In common practice, ``_`` is frequently used as a dummy variable (a variable -to receive a value from a function where the value is useless and never used). -In Ansible, we're using the identifier ``dummy`` for this purpose instead. - -Example of unfixed code: - -.. code-block:: python - - for _ in range(0, retries): - success = retry_thing() - if success: - break - -Example of fixed code: - -.. code-block:: python - - for dummy in range(0, retries): - success = retry_thing() - if success: - break diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst deleted file mode 100644 index f8ca1d2c542..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst +++ /dev/null @@ -1,16 +0,0 @@ -no-unicode_literals -=================== - -The use of :code:`from __future__ import unicode_literals` has been deemed an anti-pattern. The -problems with it are: - -* It makes it so one can't jump into the middle of a file and know whether a bare literal string is - a byte string or text string. The programmer has to first check the top of the file to see if the - import is there. -* It removes the ability to define native strings (a string which should be a byte string on python2 - and a text string on python3) by a string literal. -* It makes for more context switching. A programmer could be reading one file which has - `unicode_literals` and know that bare string literals are text strings but then switch to another - file (perhaps tracing program execution into a third party library) and have to switch their - understanding of what bare string literals are. - diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-unwanted-files.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-unwanted-files.rst deleted file mode 100644 index 3d76324eeaa..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-unwanted-files.rst +++ /dev/null @@ -1,13 +0,0 @@ -no-unwanted-files -================= - -Specific file types are allowed in certain directories: - -- ``lib`` - All content must reside in the ``lib/ansible`` directory. - -- ``lib/ansible`` - Only source code with one of the following extensions is allowed: - - - ``*.cs`` - C# - - ``*.ps1`` - PowerShell - - ``*.psm1`` - PowerShell - - ``*.py`` - Python diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-wildcard-import.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-wildcard-import.rst deleted file mode 100644 index fdaf07b097a..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-wildcard-import.rst +++ /dev/null @@ -1,31 +0,0 @@ -:orphan: - -no-wildcard-import -================== - -Using :code:`import *` is a bad habit which pollutes your namespace, hinders -debugging, and interferes with static analysis of code. For those reasons, we -do want to limit the use of :code:`import *` in the ansible code. Change our -code to import the specific names that you need instead. - -Examples of unfixed code: - -.. code-block:: python - - from ansible.module_utils.six import * - if isinstance(variable, string_types): - do_something(variable) - - from ansible.module_utils.basic import * - module = AnsibleModule() - -Examples of fixed code: - -.. code-block:: python - - from ansible.module_utils import six - if isinstance(variable, six.string_types): - do_something(variable) - - from ansible.module_utils.basic import AnsibleModule - module = AnsibleModule() diff --git a/docs/docsite/rst/dev_guide/testing/sanity/obsolete-files.rst b/docs/docsite/rst/dev_guide/testing/sanity/obsolete-files.rst deleted file mode 100644 index cb237468943..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/obsolete-files.rst +++ /dev/null @@ -1,14 +0,0 @@ -obsolete-files -============== - -Directories in the Ansible source tree are sometimes made obsolete. -Files should not exist in these directories. -The new location (if any) is dependent on which directory has been made obsolete. - -Below are some of the obsolete directories and their new locations: - -- All of ``test/runner/`` is now under ``test/lib/ansible_test/`` instead. The organization of files in the new directory has changed. -- Most subdirectories of ``test/sanity/`` (with some exceptions) are now under ``test/lib/ansible_test/_util/controller/sanity/`` instead. - -This error occurs most frequently for open pull requests which add or modify files in directories which are now obsolete. -Make sure the branch you are working from is current so that changes can be made in the correct location. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/package-data.rst b/docs/docsite/rst/dev_guide/testing/sanity/package-data.rst deleted file mode 100644 index 220872dd28a..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/package-data.rst +++ /dev/null @@ -1,5 +0,0 @@ -package-data -============ - -Verifies that the combination of ``MANIFEST.in`` and ``package_data`` from ``setup.py`` -properly installs data files from within ``lib/ansible`` diff --git a/docs/docsite/rst/dev_guide/testing/sanity/pep8.rst b/docs/docsite/rst/dev_guide/testing/sanity/pep8.rst deleted file mode 100644 index 9424bda8ab4..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/pep8.rst +++ /dev/null @@ -1,24 +0,0 @@ -.. _testing_pep8: - -pep8 -==== - -Python static analysis for PEP 8 style guideline compliance. - -`PEP 8`_ style guidelines are enforced by `pycodestyle`_ on all python files in the repository by default. - -Running locally ------------------ - -The `PEP 8`_ check can be run locally as follows: - -.. code-block:: shell - - ansible-test sanity --test pep8 [file-or-directory-path-to-check] ... - - - -.. _PEP 8: https://www.python.org/dev/peps/pep-0008/ -.. _pycodestyle: https://pypi.org/project/pycodestyle/ - - diff --git a/docs/docsite/rst/dev_guide/testing/sanity/pslint.rst b/docs/docsite/rst/dev_guide/testing/sanity/pslint.rst deleted file mode 100644 index baa4fa034fc..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/pslint.rst +++ /dev/null @@ -1,4 +0,0 @@ -pslint -====== - -PowerShell static analysis for common programming errors using `PSScriptAnalyzer `_. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/pylint-ansible-test.rst b/docs/docsite/rst/dev_guide/testing/sanity/pylint-ansible-test.rst deleted file mode 100644 index a80ddc1eb05..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/pylint-ansible-test.rst +++ /dev/null @@ -1,8 +0,0 @@ -:orphan: - -pylint-ansible-test -=================== - -Python static analysis for common programming errors. - -A more strict set of rules applied to ``ansible-test``. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/pylint.rst b/docs/docsite/rst/dev_guide/testing/sanity/pylint.rst deleted file mode 100644 index 2b2ef9e53bd..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/pylint.rst +++ /dev/null @@ -1,4 +0,0 @@ -pylint -====== - -Python static analysis for common programming errors. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/release-names.rst b/docs/docsite/rst/dev_guide/testing/sanity/release-names.rst deleted file mode 100644 index 359f7ecb54d..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/release-names.rst +++ /dev/null @@ -1,4 +0,0 @@ -Release names -============= - -Verifies that the most recent release name has been added to ``./github/RELEASE_NAMES.yml`` diff --git a/docs/docsite/rst/dev_guide/testing/sanity/replace-urlopen.rst b/docs/docsite/rst/dev_guide/testing/sanity/replace-urlopen.rst deleted file mode 100644 index 705195c942f..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/replace-urlopen.rst +++ /dev/null @@ -1,4 +0,0 @@ -replace-urlopen -=============== - -Use ``open_url`` from ``module_utils`` instead of ``urlopen``. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/required-and-default-attributes.rst b/docs/docsite/rst/dev_guide/testing/sanity/required-and-default-attributes.rst deleted file mode 100644 index 573c361500a..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/required-and-default-attributes.rst +++ /dev/null @@ -1,5 +0,0 @@ -required-and-default-attributes -=============================== - -Use only one of ``default`` or ``required`` with ``FieldAttribute``. - diff --git a/docs/docsite/rst/dev_guide/testing/sanity/rstcheck.rst b/docs/docsite/rst/dev_guide/testing/sanity/rstcheck.rst deleted file mode 100644 index 8fcbbce3431..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/rstcheck.rst +++ /dev/null @@ -1,4 +0,0 @@ -rstcheck -======== - -Check reStructuredText files for syntax and formatting issues. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/runtime-metadata.rst b/docs/docsite/rst/dev_guide/testing/sanity/runtime-metadata.rst deleted file mode 100644 index 1f3c32ad778..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/runtime-metadata.rst +++ /dev/null @@ -1,7 +0,0 @@ -runtime-metadata.yml -==================== - -Validates the schema for: - -* ansible-core's ``lib/ansible/config/ansible_builtin_runtime.yml`` -* collection's ``meta/runtime.yml`` diff --git a/docs/docsite/rst/dev_guide/testing/sanity/sanity-docs.rst b/docs/docsite/rst/dev_guide/testing/sanity/sanity-docs.rst deleted file mode 100644 index 34265c34be5..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/sanity-docs.rst +++ /dev/null @@ -1,4 +0,0 @@ -sanity-docs -=========== - -Documentation for each ``ansible-test sanity`` test is required. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/shebang.rst b/docs/docsite/rst/dev_guide/testing/sanity/shebang.rst deleted file mode 100644 index cff2aa0914b..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/shebang.rst +++ /dev/null @@ -1,16 +0,0 @@ -shebang -======= - -Most executable files should only use one of the following shebangs: - -- ``#!/bin/sh`` -- ``#!/bin/bash`` -- ``#!/usr/bin/make`` -- ``#!/usr/bin/env python`` -- ``#!/usr/bin/env bash`` - -NOTE: For ``#!/bin/bash``, any of the options ``eux`` may also be used, such as ``#!/bin/bash -eux``. - -This does not apply to Ansible modules, which should not be executable and must always use ``#!/usr/bin/python``. - -Some exceptions are permitted. Ask if you have questions. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/shellcheck.rst b/docs/docsite/rst/dev_guide/testing/sanity/shellcheck.rst deleted file mode 100644 index 446ee1ee782..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/shellcheck.rst +++ /dev/null @@ -1,4 +0,0 @@ -shellcheck -========== - -Static code analysis for shell scripts using the excellent `shellcheck `_ tool. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/symlinks.rst b/docs/docsite/rst/dev_guide/testing/sanity/symlinks.rst deleted file mode 100644 index 017209bdd3b..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/symlinks.rst +++ /dev/null @@ -1,6 +0,0 @@ -symlinks -======== - -Symbolic links are only permitted for files that exist to ensure proper tarball generation during a release. - -If other types of symlinks are needed for tests they must be created as part of the test. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/test-constraints.rst b/docs/docsite/rst/dev_guide/testing/sanity/test-constraints.rst deleted file mode 100644 index 36ceb361309..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/test-constraints.rst +++ /dev/null @@ -1,4 +0,0 @@ -test-constraints -================ - -Constraints for test requirements should be in ``test/lib/ansible_test/_data/requirements/constraints.txt``. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/update-bundled.rst b/docs/docsite/rst/dev_guide/testing/sanity/update-bundled.rst deleted file mode 100644 index d8f19385b35..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/update-bundled.rst +++ /dev/null @@ -1,31 +0,0 @@ -:orphan: - -update-bundled -============== - -Check whether any of our known bundled code needs to be updated for a new upstream release. - -This test can error in the following ways: - -* The bundled code is out of date with regard to the latest release on pypi. Update the code - to the new version and update the version in _BUNDLED_METADATA to solve this. - -* The code is lacking a _BUNDLED_METADATA variable. This typically happens when a bundled version - is updated and we forget to add a _BUNDLED_METADATA variable to the updated file. Once that is - added, this error should go away. - -* A file has a _BUNDLED_METADATA variable but the file isn't specified in - :file:`test/sanity/code-smell/update-bundled.py`. This typically happens when a new bundled - library is added. Add the file to the `get_bundled_libs()` function in the `update-bundled.py` - test script to solve this error. - -_BUNDLED_METADATA has the following fields: - -:pypi_name: Name of the bundled package on pypi - -:version: Version of the package that we are including here - -:version_constraints: Optional PEP440 specifier for the version range that we are bundling. - Currently, the only valid use of this is to follow a version that is - compatible with the Python stdlib when newer versions of the pypi package - implement a new API. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/use-argspec-type-path.rst b/docs/docsite/rst/dev_guide/testing/sanity/use-argspec-type-path.rst deleted file mode 100644 index e06d83dd1a5..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/use-argspec-type-path.rst +++ /dev/null @@ -1,10 +0,0 @@ -use-argspec-type-path -===================== - -The AnsibleModule argument_spec knows of several types beyond the standard python types. One of -these is ``path``. When used, type ``path`` ensures that an argument is a string and expands any -shell variables and tilde characters. - -This test looks for use of :func:`os.path.expanduser ` in modules. When found, it tells the user to -replace it with ``type='path'`` in the module's argument_spec or list it as a false positive in the -test. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/use-compat-six.rst b/docs/docsite/rst/dev_guide/testing/sanity/use-compat-six.rst deleted file mode 100644 index 1f4150056da..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/use-compat-six.rst +++ /dev/null @@ -1,4 +0,0 @@ -use-compat-six -============== - -Use ``six`` from ``module_utils`` instead of ``six``. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/validate-modules.rst b/docs/docsite/rst/dev_guide/testing/sanity/validate-modules.rst deleted file mode 100644 index e2c20f4dddb..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/validate-modules.rst +++ /dev/null @@ -1,141 +0,0 @@ -.. _testing_validate-modules: - -validate-modules -================ - -Analyze modules for common issues in code and documentation. - -.. contents:: - :local: - -Usage ------- - -.. code:: shell - - cd /path/to/ansible/source - source hacking/env-setup - ansible-test sanity --test validate-modules - -Help ------ - -Type ``ansible-test sanity validate-modules -h`` to display help for using this sanity test. - - - -Extending validate-modules ---------------------------- - -The ``validate-modules`` tool has a `schema.py `_ that is used to validate the YAML blocks, such as ``DOCUMENTATION`` and ``RETURNS``. - - -Codes ------- - -============================================================ ================== ==================== ========================================================================================= - **Error Code** **Type** **Level** **Sample Message** ------------------------------------------------------------- ------------------ -------------------- ----------------------------------------------------------------------------------------- - ansible-deprecated-module Documentation Error A module is deprecated and supposed to be removed in the current or an earlier Ansible version - collection-deprecated-module Documentation Error A module is deprecated and supposed to be removed in the current or an earlier collection version - ansible-deprecated-version Documentation Error A feature is deprecated and supposed to be removed in the current or an earlier Ansible version - ansible-module-not-initialized Syntax Error Execution of the module did not result in initialization of AnsibleModule - collection-deprecated-version Documentation Error A feature is deprecated and supposed to be removed in the current or an earlier collection version - deprecated-date Documentation Error A date before today appears as ``removed_at_date`` or in ``deprecated_aliases`` - deprecation-mismatch Documentation Error Module marked as deprecated or removed in at least one of the filename, its metadata, or in DOCUMENTATION (setting DOCUMENTATION.deprecated for deprecation or removing all Documentation for removed) but not in all three places. - doc-choices-do-not-match-spec Documentation Error Value for "choices" from the argument_spec does not match the documentation - doc-choices-incompatible-type Documentation Error Choices value from the documentation is not compatible with type defined in the argument_spec - doc-default-does-not-match-spec Documentation Error Value for "default" from the argument_spec does not match the documentation - doc-default-incompatible-type Documentation Error Default value from the documentation is not compatible with type defined in the argument_spec - doc-elements-invalid Documentation Error Documentation specifies elements for argument, when "type" is not ``list``. - doc-elements-mismatch Documentation Error Argument_spec defines elements different than documentation does - doc-missing-type Documentation Error Documentation doesn't specify a type but argument in ``argument_spec`` use default type (``str``) - doc-required-mismatch Documentation Error argument in argument_spec is required but documentation says it is not, or vice versa - doc-type-does-not-match-spec Documentation Error Argument_spec defines type different than documentation does - documentation-error Documentation Error Unknown ``DOCUMENTATION`` error - documentation-syntax-error Documentation Error Invalid ``DOCUMENTATION`` schema - import-before-documentation Imports Error Import found before documentation variables. All imports must appear below ``DOCUMENTATION``/``EXAMPLES``/``RETURN`` - import-error Documentation Error ``Exception`` attempting to import module for ``argument_spec`` introspection - attributes-check-mode Documentation Error If a module documents the ``check_mode`` attribute, its ``support`` value must be compatible with the ``supports_check_mode`` parameter of ``AnsibleModule`` - attributes-check-mode-details Documentation Error If a module documents the ``check_mode`` attribute with support values ``partial`` or ``N/A``, it must provide ``details`` - import-placement Locations Warning Imports should be directly below ``DOCUMENTATION``/``EXAMPLES``/``RETURN`` - imports-improper-location Imports Error Imports should be directly below ``DOCUMENTATION``/``EXAMPLES``/``RETURN`` - incompatible-choices Documentation Error Choices value from the argument_spec is not compatible with type defined in the argument_spec - incompatible-default-type Documentation Error Default value from the argument_spec is not compatible with type defined in the argument_spec - invalid-argument-name Documentation Error Argument in argument_spec must not be one of 'message', 'syslog_facility' as it is used internally by Ansible Core Engine - invalid-argument-spec Documentation Error Argument in argument_spec must be a dictionary/hash when used - invalid-argument-spec-options Documentation Error Suboptions in argument_spec are invalid - invalid-documentation Documentation Error ``DOCUMENTATION`` is not valid YAML - invalid-documentation-markup Documentation Error ``DOCUMENTATION`` or ``RETURN`` contains invalid markup - invalid-documentation-options Documentation Error ``DOCUMENTATION.options`` must be a dictionary/hash when used - invalid-examples Documentation Error ``EXAMPLES`` is not valid YAML - invalid-extension Naming Error Official Ansible modules must have a ``.py`` extension for python modules or a ``.ps1`` for powershell modules - invalid-module-schema Documentation Error ``AnsibleModule`` schema validation error - invalid-removal-version Documentation Error The version at which a feature is supposed to be removed cannot be parsed (for collections, it must be a `semantic version `_) - invalid-requires-extension Naming Error Module ``#AnsibleRequires -CSharpUtil`` should not end in .cs, Module ``#Requires`` should not end in .psm1 - missing-doc-fragment Documentation Error ``DOCUMENTATION`` fragment missing - missing-existing-doc-fragment Documentation Warning Pre-existing ``DOCUMENTATION`` fragment missing - missing-documentation Documentation Error No ``DOCUMENTATION`` provided - missing-examples Documentation Error No ``EXAMPLES`` provided - missing-gplv3-license Documentation Error GPLv3 license header not found - missing-module-utils-basic-import Imports Warning Did not find ``ansible.module_utils.basic`` import - missing-module-utils-import-csharp-requirements Imports Error No ``Ansible.ModuleUtils`` or C# Ansible util requirements/imports found - missing-powershell-interpreter Syntax Error Interpreter line is not ``#!powershell`` - missing-python-interpreter Syntax Error Interpreter line is not ``#!/usr/bin/python`` - missing-return Documentation Error No ``RETURN`` documentation provided - missing-return-legacy Documentation Warning No ``RETURN`` documentation provided for legacy module - missing-suboption-docs Documentation Error Argument in argument_spec has sub-options but documentation does not define sub-options - module-incorrect-version-added Documentation Error Module level ``version_added`` is incorrect - module-invalid-version-added Documentation Error Module level ``version_added`` is not a valid version number - module-utils-specific-import Imports Error ``module_utils`` imports should import specific components, not ``*`` - multiple-utils-per-requires Imports Error ``Ansible.ModuleUtils`` requirements do not support multiple modules per statement - multiple-csharp-utils-per-requires Imports Error Ansible C# util requirements do not support multiple utils per statement - no-default-for-required-parameter Documentation Error Option is marked as required but specifies a default. Arguments with a default should not be marked as required - no-log-needed Parameters Error Option name suggests that the option contains a secret value, while ``no_log`` is not specified for this option in the argument spec. If this is a false positive, explicitly set ``no_log=False`` - nonexistent-parameter-documented Documentation Error Argument is listed in DOCUMENTATION.options, but not accepted by the module - option-incorrect-version-added Documentation Error ``version_added`` for new option is incorrect - option-invalid-version-added Documentation Error ``version_added`` for option is not a valid version number - parameter-invalid Documentation Error Argument in argument_spec is not a valid python identifier - parameter-invalid-elements Documentation Error Value for "elements" is valid only when value of "type" is ``list`` - implied-parameter-type-mismatch Documentation Error Argument_spec implies ``type="str"`` but documentation defines it as different data type - parameter-type-not-in-doc Documentation Error Type value is defined in ``argument_spec`` but documentation doesn't specify a type - parameter-alias-repeated Parameters Error argument in argument_spec has at least one alias specified multiple times in aliases - parameter-alias-self Parameters Error argument in argument_spec is specified as its own alias - parameter-documented-multiple-times Documentation Error argument in argument_spec with aliases is documented multiple times - parameter-list-no-elements Parameters Error argument in argument_spec "type" is specified as ``list`` without defining "elements" - parameter-state-invalid-choice Parameters Error Argument ``state`` includes ``get``, ``list`` or ``info`` as a choice. Functionality should be in an ``_info`` or (if further conditions apply) ``_facts`` module. - python-syntax-error Syntax Error Python ``SyntaxError`` while parsing module - removal-version-must-be-major Documentation Error According to the semantic versioning specification (https://semver.org/), the only versions in which features are allowed to be removed are major versions (x.0.0) - return-syntax-error Documentation Error ``RETURN`` is not valid YAML, ``RETURN`` fragments missing or invalid - return-invalid-version-added Documentation Error ``version_added`` for return value is not a valid version number - subdirectory-missing-init Naming Error Ansible module subdirectories must contain an ``__init__.py`` - try-except-missing-has Imports Warning Try/Except ``HAS_`` expression missing - undocumented-parameter Documentation Error Argument is listed in the argument_spec, but not documented in the module - unidiomatic-typecheck Syntax Error Type comparison using ``type()`` found. Use ``isinstance()`` instead - unknown-doc-fragment Documentation Warning Unknown pre-existing ``DOCUMENTATION`` error - use-boto3 Imports Error ``boto`` import found, new modules should use ``boto3`` - use-fail-json-not-sys-exit Imports Error ``sys.exit()`` call found. Should be ``exit_json``/``fail_json`` - use-module-utils-urls Imports Error ``requests`` import found, should use ``ansible.module_utils.urls`` instead - use-run-command-not-os-call Imports Error ``os.call`` used instead of ``module.run_command`` - use-run-command-not-popen Imports Error ``subprocess.Popen`` used instead of ``module.run_command`` - use-short-gplv3-license Documentation Error GPLv3 license header should be the :ref:`short form ` for new modules - mutually_exclusive-type Documentation Error mutually_exclusive entry contains non-string value - mutually_exclusive-collision Documentation Error mutually_exclusive entry has repeated terms - mutually_exclusive-unknown Documentation Error mutually_exclusive entry contains option which does not appear in argument_spec (potentially an alias of an option?) - required_one_of-type Documentation Error required_one_of entry contains non-string value - required_one_of-collision Documentation Error required_one_of entry has repeated terms - required_one_of-unknown Documentation Error required_one_of entry contains option which does not appear in argument_spec (potentially an alias of an option?) - required_together-type Documentation Error required_together entry contains non-string value - required_together-collision Documentation Error required_together entry has repeated terms - required_together-unknown Documentation Error required_together entry contains option which does not appear in argument_spec (potentially an alias of an option?) - required_if-is_one_of-type Documentation Error required_if entry has a fourth value which is not a bool - required_if-requirements-type Documentation Error required_if entry has a third value (requirements) which is not a list or tuple - required_if-requirements-collision Documentation Error required_if entry has repeated terms in requirements - required_if-requirements-unknown Documentation Error required_if entry's requirements contains option which does not appear in argument_spec (potentially an alias of an option?) - required_if-unknown-key Documentation Error required_if entry's key does not appear in argument_spec (potentially an alias of an option?) - required_if-key-in-requirements Documentation Error required_if entry contains its key in requirements list/tuple - required_if-value-type Documentation Error required_if entry's value is not of the type specified for its key - required_by-collision Documentation Error required_by entry has repeated terms - required_by-unknown Documentation Error required_by entry contains option which does not appear in argument_spec (potentially an alias of an option?) - version-added-must-be-major-or-minor Documentation Error According to the semantic versioning specification (https://semver.org/), the only versions in which features are allowed to be added are major and minor versions (x.y.0) -============================================================ ================== ==================== ========================================================================================= diff --git a/docs/docsite/rst/dev_guide/testing/sanity/yamllint.rst b/docs/docsite/rst/dev_guide/testing/sanity/yamllint.rst deleted file mode 100644 index 5822bb7c1e0..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/yamllint.rst +++ /dev/null @@ -1,4 +0,0 @@ -yamllint -======== - -Check YAML files for syntax and formatting issues. diff --git a/docs/docsite/rst/dev_guide/testing_compile.rst b/docs/docsite/rst/dev_guide/testing_compile.rst deleted file mode 100644 index 2f258c8b076..00000000000 --- a/docs/docsite/rst/dev_guide/testing_compile.rst +++ /dev/null @@ -1,8 +0,0 @@ -:orphan: - - -************* -Compile Tests -************* - -This page has moved to :ref:`testing_compile`. diff --git a/docs/docsite/rst/dev_guide/testing_documentation.rst b/docs/docsite/rst/dev_guide/testing_documentation.rst deleted file mode 100644 index 280e2c03270..00000000000 --- a/docs/docsite/rst/dev_guide/testing_documentation.rst +++ /dev/null @@ -1,44 +0,0 @@ -:orphan: - -.. _testing_module_documentation: -.. _testing_plugin_documentation: - -**************************** -Testing plugin documentation -**************************** - -A quick test while developing is to use ``ansible-doc -t `` to see if it renders, you might need to add ``-M /path/to/module`` if the module is not somewhere Ansible expects to find it. - -Before you submit a plugin for inclusion in Ansible, you must test your documentation for correct HTML rendering and for modules to ensure that the argspec matches the documentation in your Python file. -The community pages offer more information on :ref:`testing reStructuredText documentation `. - -For example, to check the HTML output of your module documentation: - -#. Ensure working :ref:`development environment `. -#. Install required Python packages (drop '--user' in venv/virtualenv): - - .. code-block:: bash - - pip install --user -r requirements.txt - pip install --user -r docs/docsite/requirements.txt - -#. Ensure your module is in the correct directory: ``lib/ansible/modules/mymodule.py`` or in a configured path. -#. Build HTML from your module documentation: ``MODULES=mymodule make webdocs``. -#. To build the HTML documentation for multiple modules, use a comma-separated list of module names: ``MODULES=mymodule,mymodule2 make webdocs``. -#. View the HTML page at ``file:///path/to/docs/docsite/_build/html/modules/mymodule_module.html``. - -To ensure that your module documentation matches your ``argument_spec``: - -#. Install required Python packages (drop '--user' in venv/virtualenv): - - .. code-block:: bash - - pip install --user -r test/lib/ansible_test/_data/requirements/sanity.txt - -#. run the ``validate-modules`` test: - - .. code-block:: bash - - ansible-test sanity --test validate-modules mymodule - -For other plugin types the steps are similar, just adjusting names and paths to the specific type. diff --git a/docs/docsite/rst/dev_guide/testing_httptester.rst b/docs/docsite/rst/dev_guide/testing_httptester.rst deleted file mode 100644 index 7c1a9fbbaf7..00000000000 --- a/docs/docsite/rst/dev_guide/testing_httptester.rst +++ /dev/null @@ -1,28 +0,0 @@ -:orphan: - -********** -httptester -********** - -.. contents:: Topics - -Overview -======== - -``httptester`` is a docker container used to host certain resources required by :ref:`testing_integration`. This is to avoid CI tests requiring external resources (such as git or package repos) which, if temporarily unavailable, would cause tests to fail. - -HTTP Testing endpoint which provides the following capabilities: - -* httpbin -* nginx -* SSL -* SNI -* Negotiate Authentication - - -Source files can be found in the `http-test-container `_ repository. - -Extending httptester -==================== - -If you have sometime to improve ``httptester`` please add a comment on the `Testing Working Group Agenda `_ to avoid duplicated effort. diff --git a/docs/docsite/rst/dev_guide/testing_integration.rst b/docs/docsite/rst/dev_guide/testing_integration.rst deleted file mode 100644 index 915281d02cb..00000000000 --- a/docs/docsite/rst/dev_guide/testing_integration.rst +++ /dev/null @@ -1,241 +0,0 @@ -:orphan: - -.. _testing_integration: - -***************** -Integration tests -***************** - -.. contents:: Topics - -The Ansible integration Test system. - -Tests for playbooks, by playbooks. - -Some tests may require credentials. Credentials may be specified with `credentials.yml`. - -Some tests may require root. - -.. note:: - Every new module and plugin should have integration tests, even if the tests cannot be run on Ansible CI infrastructure. - In this case, the tests should be marked with the ``unsupported`` alias in `aliases file `_. - -Quick Start -=========== - -It is highly recommended that you install and activate the ``argcomplete`` python package. -It provides tab completion in ``bash`` for the ``ansible-test`` test runner. - -Configuration -============= - -ansible-test command --------------------- - -The example below assumes ``bin/`` is in your ``$PATH``. An easy way to achieve that -is to initialize your environment with the ``env-setup`` command: - -.. code-block:: shell-session - - source hacking/env-setup - ansible-test --help - -You can also call ``ansible-test`` with the full path: - -.. code-block:: shell-session - - bin/ansible-test --help - -integration_config.yml ----------------------- - -Making your own version of ``integration_config.yml`` can allow for setting some -tunable parameters to help run the tests better in your environment. Some -tests (for example, cloud tests) will only run when access credentials are provided. For more -information about supported credentials, refer to the various ``cloud-config-*.template`` -files in the ``test/integration/`` directory. - -Prerequisites -============= - -Some tests assume things like hg, svn, and git are installed, and in path. Some tests -(such as those for Amazon Web Services) need separate definitions, which will be covered -later in this document. - -(Complete list pending) - -Non-destructive Tests -===================== - -These tests will modify files in subdirectories, but will not do things that install or remove packages or things -outside of those test subdirectories. They will also not reconfigure or bounce system services. - -.. note:: Running integration tests within containers - - To protect your system from any potential changes caused by integration tests, and to ensure a sensible set of dependencies are available we recommend that you always run integration tests with the ``--docker`` option, for example ``--docker ubuntu2004``. See the `list of supported container images `_ for options (the ``default`` image is used for sanity and unit tests, as well as for platform independent integration tests such as those for cloud modules). - -Run as follows for all POSIX platform tests executed by our CI system in a Fedora 34 container: - -.. code-block:: shell-session - - ansible-test integration shippable/ --docker fedora34 - -You can target a specific tests as well, such as for individual modules: - -.. code-block:: shell-session - - ansible-test integration ping - -You can use the ``-v`` option to make the output more verbose: - -.. code-block:: shell-session - - ansible-test integration lineinfile -vvv - -Use the following command to list all the available targets: - -.. code-block:: shell-session - - ansible-test integration --list-targets - -.. note:: Bash users - - If you use ``bash`` with ``argcomplete``, obtain a full list by doing: ``ansible-test integration `` - -Destructive Tests -================= - -These tests are allowed to install and remove some trivial packages. You will likely want to devote these -to a virtual environment, such as Docker. They won't reformat your filesystem: - -.. code-block:: shell-session - - ansible-test integration destructive/ --docker fedora34 - -Windows Tests -============= - -These tests exercise the ``winrm`` connection plugin and Windows modules. You'll -need to define an inventory with a remote Windows Server to use for testing, -and enable PowerShell Remoting to continue. - -Running these tests may result in changes to your Windows host, so don't run -them against a production/critical Windows environment. - -Enable PowerShell Remoting (run on the Windows host by a Remote Desktop): - -.. code-block:: shell-session - - Enable-PSRemoting -Force - -Define Windows inventory: - -.. code-block:: shell-session - - cp inventory.winrm.template inventory.winrm - ${EDITOR:-vi} inventory.winrm - -Run the Windows tests executed by our CI system: - -.. code-block:: shell-session - - ansible-test windows-integration -v shippable/ - -Tests in containers -========================== - -If you have a Linux system with Docker or Podman installed, running integration tests using the same containers used by -the Ansible continuous integration (CI) system is recommended. - -.. note:: Podman - - By default, Podman will only be used if the Docker CLI is not installed. If you have Docker installed but want to use - Podman, you can change this behavior by setting the environment variable ``ANSIBLE_TEST_PREFER_PODMAN``. - -.. note:: Docker on non-Linux - - Using Docker Engine to run Docker on a non-Linux host (such as macOS) is not recommended. - Some tests may fail, depending on the image used for testing. - Using the ``--docker-privileged`` option when running ``integration`` (not ``network-integration`` or ``windows-integration``) may resolve the issue. - -Running Integration Tests -------------------------- - -To run all CI integration test targets for POSIX platforms in a Ubuntu 18.04 container: - -.. code-block:: shell-session - - ansible-test integration shippable/ --docker ubuntu1804 - -You can also run specific tests or select a different Linux distribution. -For example, to run tests for the ``ping`` module on a Ubuntu 18.04 container: - -.. code-block:: shell-session - - ansible-test integration ping --docker ubuntu1804 - -.. _test_container_images: - -Container Images ----------------- - -Container images are updated regularly. To see the current list of container images: - -.. code-block:: bash - - ansible-test integration --help - -The list is under the **target docker images and supported python version** heading. - -Other configuration for Cloud Tests -=================================== - -In order to run some tests, you must provide access credentials in a file named -``cloud-config-aws.yml`` or ``cloud-config-cs.ini`` in the test/integration -directory. Corresponding .template files are available for for syntax help. The newer AWS -tests now use the file test/integration/cloud-config-aws.yml - -IAM policies for AWS -==================== - -Ansible needs fairly wide ranging powers to run the tests in an AWS account. This rights can be provided to a dedicated user. These need to be configured before running the test. - -testing-policies ----------------- - -The GitHub repository `mattclay/aws-terminator `_ -contains two sets of policies used for all existing AWS module integratoin tests. -The `hacking/aws_config/setup_iam.yml` playbook can be used to setup two groups: - - - `ansible-integration-ci` will have the policies applied necessary to run any - integration tests not marked as `unsupported` and are designed to mirror those - used by Ansible's CI. - - `ansible-integration-unsupported` will have the additional policies applied - necessary to run the integration tests marked as `unsupported` including tests - for managing IAM roles, users and groups. - -Once the groups have been created, you'll need to create a user and make the user a member of these -groups. The policies are designed to minimize the rights of that user. Please note that while this policy does limit -the user to one region, this does not fully restrict the user (primarily due to the limitations of the Amazon ARN -notation). The user will still have wide privileges for viewing account definitions, and will also able to manage -some resources that are not related to testing (for example, AWS lambdas with different names). Tests should not -be run in a primary production account in any case. - -Other Definitions required --------------------------- - -Apart from installing the policy and giving it to the user identity running the tests, a -lambda role `ansible_integration_tests` has to be created which has lambda basic execution -privileges. - - -Network Tests -============= - -For guidance on writing network test see :ref:`testing_resource_modules`. - - -Where to find out more -====================== - -If you'd like to know more about the plans for improving testing Ansible, join the `Testing Working Group `_. diff --git a/docs/docsite/rst/dev_guide/testing_pep8.rst b/docs/docsite/rst/dev_guide/testing_pep8.rst deleted file mode 100644 index c634914dff2..00000000000 --- a/docs/docsite/rst/dev_guide/testing_pep8.rst +++ /dev/null @@ -1,8 +0,0 @@ -:orphan: - - -***** -PEP 8 -***** - -This page has moved to :ref:`testing_pep8`. \ No newline at end of file diff --git a/docs/docsite/rst/dev_guide/testing_running_locally.rst b/docs/docsite/rst/dev_guide/testing_running_locally.rst deleted file mode 100644 index 0d03189bf41..00000000000 --- a/docs/docsite/rst/dev_guide/testing_running_locally.rst +++ /dev/null @@ -1,382 +0,0 @@ -:orphan: - -.. _testing_running_locally: - -******************************* -Testing Ansible and Collections -******************************* - -This document describes how to run tests using ``ansible-test``. - -.. contents:: - :local: - -Setup -===== - -Before running ``ansible-test``, set up your environment for :ref:`testing_an_ansible_collection` or -:ref:`testing_ansible_core`, depending on which scenario applies to you. - -.. warning:: - - If you use ``git`` for version control, make sure the files you are working with are not ignored by ``git``. - If they are, ``ansible-test`` will ignore them as well. - -.. _testing_an_ansible_collection: - -Testing an Ansible Collection ------------------------------ - -If you are testing an Ansible Collection, you need a copy of the collection, preferably a git clone. -For example, to work with the ``community.windows`` collection, follow these steps: - -1. Clone the collection you want to test into a valid collection root: - - .. code-block:: shell - - git clone https://github.com/ansible-collections/community.windows ~/dev/ansible_collections/community/windows - - .. important:: - - The path must end with ``/ansible_collections/{collection_namespace}/{collection_name}`` where - ``{collection_namespace}`` is the namespace of the collection and ``{collection_name}`` is the collection name. - -2. Clone any collections on which the collection depends: - - .. code-block:: shell - - git clone https://github.com/ansible-collections/ansible.windows ~/dev/ansible_collections/ansible/windows - - .. important:: - - If your collection has any dependencies on other collections, they must be in the same collection root, since - ``ansible-test`` will not use your configured collection roots (or other Ansible configuration). - - .. note:: - - See the collection's ``galaxy.yml`` for a list of possible dependencies. - -3. Switch to the directory where the collection to test resides: - - .. code-block:: shell - - cd ~/dev/ansible_collections/community/windows - -.. _testing_ansible_core: - -Testing ``ansible-core`` ------------------------- - -If you are testing ``ansible-core`` itself, you need a copy of the ``ansible-core`` source code, preferably a git clone. -Having an installed copy of ``ansible-core`` is not sufficient or required. -For example, to work with the ``ansible-core`` source cloned from GitHub, follow these steps: - -1. Clone the ``ansible-core`` repository: - - .. code-block:: shell - - git clone https://github.com/ansible/ansible ~/dev/ansible - -2. Switch to the directory where the ``ansible-core`` source resides: - - .. code-block:: shell - - cd ~/dev/ansible - -3. Add ``ansible-core`` programs to your ``PATH``: - - .. code-block:: shell - - source hacking/env-setup - - .. note:: - - You can skip this step if you only need to run ``ansible-test``, and not other ``ansible-core`` programs. - In that case, simply run ``bin/ansible-test`` from the root of the ``ansible-core`` source. - - .. caution:: - - If you have an installed version of ``ansible-core`` and are trying to run ``ansible-test`` from your ``PATH``, - make sure the program found by your shell is the one from the ``ansible-core`` source: - - .. code-block:: shell - - which ansible-test - -Commands -======== - -The most commonly used test commands are: - -* ``ansible-test sanity`` - Run sanity tests (mostly linters and static analysis). -* ``ansible-test integration`` - Run integration tests. -* ``ansible-test units`` - Run unit tests. - -Run ``ansible-test --help`` to see a complete list of available commands. - -.. note:: - - For detailed help on a specific command, add the ``--help`` option after the command. - -Environments -============ - -Most ``ansible-test`` commands support running in one or more isolated test environments to simplify testing. - -Containers ----------- - -Containers are recommended for running sanity, unit and integration tests, since they provide consistent environments. -Unit tests will be run with network isolation, which avoids unintentional dependencies on network resources. - -The ``--docker`` option runs tests in a container using either Docker or Podman. - -.. note:: - - If both Docker and Podman are installed, Docker will be used. - To override this, set the environment variable ``ANSIBLE_TEST_PREFER_PODMAN`` to any non-empty value. - -Choosing a container -^^^^^^^^^^^^^^^^^^^^ - -Without an additional argument, the ``--docker`` option uses the ``default`` container. -To use another container, specify it immediately after the ``--docker`` option. - -.. note:: - - The ``default`` container is recommended for all sanity and unit tests. - -To see the list of supported containers, use the ``--help`` option with the ``ansible-test`` command you want to use. - -.. note:: - - The list of available containers is dependent on the ``ansible-test`` command you are using. - -You can also specify your own container. -When doing so, you will need to indicate the Python version in the container with the ``--python`` option. - -Custom containers -""""""""""""""""" - -When building custom containers, keep in mind the following requirements: - -* The ``USER`` should be ``root``. -* Use an ``init`` process, such as ``systemd``. -* Include ``sshd`` and accept connections on the default port of ``22``. -* Include a POSIX compatible ``sh`` shell which can be found on ``PATH``. -* Include a ``sleep`` utility which runs as a subprocess. -* Include a supported version of Python. -* Avoid using the ``VOLUME`` statement. - -Docker and SELinux -^^^^^^^^^^^^^^^^^^ - -Using Docker on a host with SELinux may require setting the system in permissive mode. -Consider using Podman instead. - -Docker Desktop with WSL2 -^^^^^^^^^^^^^^^^^^^^^^^^ - -These instructions explain how to use ``ansible-test`` with WSL2 and Docker Desktop *without* ``systemd`` support. - -.. note:: - - If your WSL2 environment includes ``systemd`` support, these steps are not required. - -.. _configuration_requirements: - -Configuration requirements -"""""""""""""""""""""""""" - -1. Open Docker Desktop and go to the **Settings** screen. -2. On the the **General** tab: - - a. Uncheck the **Start Docker Desktop when you log in** checkbox. - b. Check the **Use the WSL 2 based engine** checkbox. - -3. On the **Resources** tab under the **WSL Integration** section: - - a. Enable distros you want to use under the **Enable integration with additional distros** section. - -4. Click **Apply and restart** if changes were made. - -.. _setup_instructions: - -Setup instructions -"""""""""""""""""" - -.. note:: - - If all WSL instances have been stopped, these changes will need to be re-applied. - -1. Verify Docker Desktop is properly configured (see :ref:`configuration_requirements`). -2. Quit Docker Desktop if it is running: - - a. Right click the **Docker Desktop** taskbar icon. - b. Click the **Quit Docker Desktop** option. - -3. Stop any running WSL instances with the command: - - .. code-block:: shell - - wsl --shutdown - -4. Verify all WSL instances have stopped with the command: - - .. code-block:: shell - - wsl -l -v - -5. Start a WSL instance and perform the following steps as ``root``: - - a. Verify the ``systemd`` subsystem is not registered: - - a. Check for the ``systemd`` cgroup hierarchy with the following command: - - .. code-block:: shell - - grep systemd /proc/self/cgroup - - b. If any matches are found, re-check the :ref:`configuration_requirements` and follow the - :ref:`setup_instructions` again. - - b. Mount the ``systemd`` cgroup hierarchy with the following commands: - - .. code-block:: shell - - mkdir /sys/fs/cgroup/systemd - mount cgroup -t cgroup /sys/fs/cgroup/systemd -o none,name=systemd,xattr - -6. Start Docker Desktop. - -You should now be able to use ``ansible-test`` with the ``--docker`` option. - -.. _linux_cgroup_configuration: - -Linux cgroup configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. note:: - - These changes will need to be re-applied each time the container host is booted. - -For certain container hosts and container combinations, additional setup on the container host may be required. -In these situations ``ansible-test`` will report an error and provide additional instructions to run as ``root``: - -.. code-block:: shell - - mkdir /sys/fs/cgroup/systemd - mount cgroup -t cgroup /sys/fs/cgroup/systemd -o none,name=systemd,xattr - -If you are using rootless Podman, an additional command must be run, also as ``root``. -Make sure to substitute your user and group for ``{user}`` and ``{group}`` respectively: - -.. code-block:: shell - - chown -R {user}:{group} /sys/fs/cgroup/systemd - -Podman -"""""" - -When using Podman, you may need to stop existing Podman processes after following the :ref:`linux_cgroup_configuration` -instructions. Otherwise Podman may be unable to see the new mount point. - -You can check to see if Podman is running by looking for ``podman`` and ``catatonit`` processes. - -Remote virtual machines ------------------------ - -Remote virtual machines are recommended for running integration tests not suitable for execution in containers. - -The ``--remote`` option runs tests in a cloud hosted ephemeral virtual machine. - -.. note:: - - An API key is required to use this feature, unless running under an approved Azure Pipelines organization. - -To see the list of supported systems, use the ``--help`` option with the ``ansible-test`` command you want to use. - -.. note:: - - The list of available systems is dependent on the ``ansible-test`` command you are using. - -Python virtual environments ---------------------------- - -Python virtual environments provide a simple way to achieve isolation from the system and user Python environments. -They are recommended for unit and integration tests when the ``--docker`` and ``--remote`` options cannot be used. - -The ``--venv`` option runs tests in a virtual environment managed by ``ansible-test``. -Requirements are automatically installed before tests are run. - -Composite environment arguments -------------------------------- - -The environment arguments covered in this document are sufficient for most use cases. -However, some scenarios may require the additional flexibility offered by composite environment arguments. - -The ``--controller`` and ``--target`` options are alternatives to the ``--docker``, ``--remote`` and ``--venv`` options. - -.. note:: - - When using the ``shell`` command, the ``--target`` option is replaced by three platform specific options. - -Add the ``--help`` option to your ``ansible-test`` command to learn more about the composite environment arguments. - -Additional Requirements -======================= - -Some ``ansible-test`` commands have additional requirements. -You can use the ``--requirements`` option to automatically install them. - -.. note:: - - When using a test environment managed by ``ansible-test`` the ``--requirements`` option is usually unnecessary. - -Environment variables -===================== - -When using environment variables to manipulate tests there some limitations to keep in mind. Environment variables are: - -* Not propagated from the host to the test environment when using the ``--docker`` or ``--remote`` options. -* Not exposed to the test environment unless enabled in ``test/lib/ansible_test/_internal/util.py`` in the ``common_environment`` function. - - Example: ``ANSIBLE_KEEP_REMOTE_FILES=1`` can be set when running ``ansible-test integration --venv``. However, using the ``--docker`` option would - require running ``ansible-test shell`` to gain access to the Docker environment. Once at the shell prompt, the environment variable could be set - and the tests executed. This is useful for debugging tests inside a container by following the - :ref:`debugging_modules` instructions. - -Interactive shell -================= - -Use the ``ansible-test shell`` command to get an interactive shell in the same environment used to run tests. Examples: - -* ``ansible-test shell --docker`` - Open a shell in the default docker container. -* ``ansible-test shell --venv --python 3.10`` - Open a shell in a Python 3.10 virtual environment. - -Code coverage -============= - -Code coverage reports make it easy to identify untested code for which more tests should -be written. Online reports are available but only cover the ``devel`` branch (see -:ref:`developing_testing`). For new code local reports are needed. - -Add the ``--coverage`` option to any test command to collect code coverage data. If you -aren't using the ``--venv`` or ``--docker`` options which create an isolated python -environment then you may have to use the ``--requirements`` option to ensure that the -correct version of the coverage module is installed: - -.. code-block:: shell - - ansible-test coverage erase - ansible-test units --coverage apt - ansible-test integration --coverage aws_lambda - ansible-test coverage html - -Reports can be generated in several different formats: - -* ``ansible-test coverage report`` - Console report. -* ``ansible-test coverage html`` - HTML report. -* ``ansible-test coverage xml`` - XML report. - -To clear data between test runs, use the ``ansible-test coverage erase`` command. diff --git a/docs/docsite/rst/dev_guide/testing_sanity.rst b/docs/docsite/rst/dev_guide/testing_sanity.rst deleted file mode 100644 index 93769c1d2a6..00000000000 --- a/docs/docsite/rst/dev_guide/testing_sanity.rst +++ /dev/null @@ -1,52 +0,0 @@ -:orphan: - -.. _testing_sanity: - -************ -Sanity Tests -************ - -.. contents:: Topics - -Sanity tests are made up of scripts and tools used to perform static code analysis. -The primary purpose of these tests is to enforce Ansible coding standards and requirements. - -Tests are run with ``ansible-test sanity``. -All available tests are run unless the ``--test`` option is used. - - -How to run -========== - -.. note:: - To run sanity tests using docker, always use the default docker image - by passing the ``--docker`` or ``--docker default`` argument. - -.. code:: shell - - source hacking/env-setup - - # Run all sanity tests - ansible-test sanity - - # Run all sanity tests including disabled ones - ansible-test sanity --allow-disabled - - # Run all sanity tests against certain file(s) - ansible-test sanity lib/ansible/modules/files/template.py - - # Run all sanity tests against certain folder(s) - ansible-test sanity lib/ansible/modules/files/ - - # Run all tests inside docker (good if you don't have dependencies installed) - ansible-test sanity --docker default - - # Run validate-modules against a specific file - ansible-test sanity --test validate-modules lib/ansible/modules/files/template.py - -Available Tests -=============== - -Tests can be listed with ``ansible-test sanity --list-tests``. - -See the full list of :ref:`sanity tests `, which details the various tests and details how to fix identified issues. diff --git a/docs/docsite/rst/dev_guide/testing_units.rst b/docs/docsite/rst/dev_guide/testing_units.rst deleted file mode 100644 index 3b876455a77..00000000000 --- a/docs/docsite/rst/dev_guide/testing_units.rst +++ /dev/null @@ -1,219 +0,0 @@ -:orphan: - -.. _testing_units: - -********** -Unit Tests -********** - -Unit tests are small isolated tests that target a specific library or module. Unit tests -in Ansible are currently the only way of driving tests from python within Ansible's -continuous integration process. This means that in some circumstances the tests may be a -bit wider than just units. - -.. contents:: Topics - -Available Tests -=============== - -Unit tests can be found in `test/units -`_. Notice that the directory -structure of the tests matches that of ``lib/ansible/``. - -Running Tests -============= - -.. note:: - To run unit tests using docker, always use the default docker image - by passing the ``--docker`` or ``--docker default`` argument. - -The Ansible unit tests can be run across the whole code base by doing: - -.. code:: shell - - cd /path/to/ansible/source - source hacking/env-setup - ansible-test units --docker -v - -Against a single file by doing: - -.. code:: shell - - ansible-test units --docker -v apt - -Or against a specific Python version by doing: - -.. code:: shell - - ansible-test units --docker -v --python 2.7 apt - -If you are running unit tests against things other than modules, such as module utilities, specify the whole file path: - -.. code:: shell - - ansible-test units --docker -v test/units/module_utils/basic/test_imports.py - -For advanced usage see the online help: - -.. code:: shell - - ansible-test units --help - -You can also run tests in Ansible's continuous integration system by opening a pull -request. This will automatically determine which tests to run based on the changes made -in your pull request. - - -Installing dependencies -======================= - -If you are running ``ansible-test`` with the ``--docker`` or ``--venv`` option you do not need to install dependencies manually. - -Otherwise you can install dependencies using the ``--requirements`` option, which will -install all the required dependencies needed for unit tests. For example: - -.. code:: shell - - ansible-test units --python 2.7 --requirements apache2_module - - -The list of unit test requirements can be found at `test/units/requirements.txt -`_. - -This does not include the list of unit test requirements for ``ansible-test`` itself, -which can be found at `test/lib/ansible_test/_data/requirements/units.txt -`_. - -See also the `constraints -`_ -applicable to all test commands. - - -Extending unit tests -==================== - - -.. warning:: What a unit test isn't - - If you start writing a test that requires external services then - you may be writing an integration test, rather than a unit test. - - -Structuring Unit Tests ----------------------- - -Ansible drives unit tests through `pytest `_. This -means that tests can either be written a simple functions which are included in any file -name like ``test_.py`` or as classes. - -Here is an example of a function: - -.. code:: python - - #this function will be called simply because it is called test_*() - - def test_add(): - a = 10 - b = 23 - c = 33 - assert a + b == c - -Here is an example of a class: - -.. code:: python - - import unittest - - class AddTester(unittest.TestCase): - - def SetUp(): - self.a = 10 - self.b = 23 - - # this function will - def test_add(): - c = 33 - assert self.a + self.b == c - - # this function will - def test_subtract(): - c = -13 - assert self.a - self.b == c - -Both methods work fine in most circumstances; the function-based interface is simpler and -quicker and so that's probably where you should start when you are just trying to add a -few basic tests for a module. The class-based test allows more tidy set up and tear down -of pre-requisites, so if you have many test cases for your module you may want to refactor -to use that. - -Assertions using the simple ``assert`` function inside the tests will give full -information on the cause of the failure with a trace-back of functions called during the -assertion. This means that plain asserts are recommended over other external assertion -libraries. - -A number of the unit test suites include functions that are shared between several -modules, especially in the networking arena. In these cases a file is created in the same -directory, which is then included directly. - - -Module test case common code ----------------------------- - -Keep common code as specific as possible within the `test/units/` directory structure. -Don't import common unit test code from directories outside the current or parent directories. - -Don't import other unit tests from a unit test. Any common code should be in dedicated -files that aren't themselves tests. - - -Fixtures files --------------- - -To mock out fetching results from devices, or provide other complex data structures that -come from external libraries, you can use ``fixtures`` to read in pre-generated data. - -You can check how `fixtures `_ -are used in `cpuinfo fact tests `_ - -If you are simulating APIs you may find that Python placebo is useful. See -:ref:`testing_units_modules` for more information. - - -Code Coverage For New or Updated Unit Tests -------------------------------------------- -New code will be missing from the codecov.io coverage reports (see :ref:`developing_testing`), so -local reporting is needed. Most ``ansible-test`` commands allow you to collect code -coverage; this is particularly useful when to indicate where to extend testing. - -To collect coverage data add the ``--coverage`` argument to your ``ansible-test`` command line: - -.. code:: shell - - ansible-test units --coverage apt - ansible-test coverage html - -Results will be written to ``test/results/reports/coverage/index.html`` - -Reports can be generated in several different formats: - -* ``ansible-test coverage report`` - Console report. -* ``ansible-test coverage html`` - HTML report. -* ``ansible-test coverage xml`` - XML report. - -To clear data between test runs, use the ``ansible-test coverage erase`` command. See -:ref:`testing_running_locally` for more information about generating coverage -reports. - - -.. seealso:: - - :ref:`testing_units_modules` - Special considerations for unit testing modules - :ref:`testing_running_locally` - Running tests locally including gathering and reporting coverage data - `Python 3 documentation - 26.4. unittest — Unit testing framework `_ - The documentation of the unittest framework in python 3 - `Python 2 documentation - 25.3. unittest — Unit testing framework `_ - The documentation of the earliest supported unittest framework - from Python 2.6 - `pytest: helps you write better programs `_ - The documentation of pytest - the framework actually used to run Ansible unit tests diff --git a/docs/docsite/rst/dev_guide/testing_units_modules.rst b/docs/docsite/rst/dev_guide/testing_units_modules.rst deleted file mode 100644 index d07dcff9448..00000000000 --- a/docs/docsite/rst/dev_guide/testing_units_modules.rst +++ /dev/null @@ -1,589 +0,0 @@ -:orphan: - -.. _testing_units_modules: - -**************************** -Unit Testing Ansible Modules -**************************** - -.. highlight:: python - -.. contents:: Topics - -Introduction -============ - -This document explains why, how and when you should use unit tests for Ansible modules. -The document doesn't apply to other parts of Ansible for which the recommendations are -normally closer to the Python standard. There is basic documentation for Ansible unit -tests in the developer guide :ref:`testing_units`. This document should -be readable for a new Ansible module author. If you find it incomplete or confusing, -please open a bug or ask for help on the #ansible-devel chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). - -What Are Unit Tests? -==================== - -Ansible includes a set of unit tests in the :file:`test/units` directory. These tests primarily cover the -internals but can also cover Ansible modules. The structure of the unit tests matches -the structure of the code base, so the tests that reside in the :file:`test/units/modules/` directory -are organized by module groups. - -Integration tests can be used for most modules, but there are situations where -cases cannot be verified using integration tests. This means that Ansible unit test cases -may extend beyond testing only minimal units and in some cases will include some -level of functional testing. - - -Why Use Unit Tests? -=================== - -Ansible unit tests have advantages and disadvantages. It is important to understand these. -Advantages include: - -* Most unit tests are much faster than most Ansible integration tests. The complete suite - of unit tests can be run regularly by a developer on their local system. -* Unit tests can be run by developers who don't have access to the system which the module is - designed to work on, allowing a level of verification that changes to core functions - haven't broken module expectations. -* Unit tests can easily substitute system functions allowing testing of software that - would be impractical. For example, the ``sleep()`` function can be replaced and we check - that a ten minute sleep was called without actually waiting ten minutes. -* Unit tests are run on different Python versions. This allows us to - ensure that the code behaves in the same way on different Python versions. - -There are also some potential disadvantages of unit tests. Unit tests don't normally -directly test actual useful valuable features of software, instead just internal -implementation - -* Unit tests that test the internal, non-visible features of software may make - refactoring difficult if those internal features have to change (see also naming in How - below) -* Even if the internal feature is working correctly it is possible that there will be a - problem between the internal code tested and the actual result delivered to the user - -Normally the Ansible integration tests (which are written in Ansible YAML) provide better -testing for most module functionality. If those tests already test a feature and perform -well there may be little point in providing a unit test covering the same area as well. - -When To Use Unit Tests -====================== - -There are a number of situations where unit tests are a better choice than integration -tests. For example, testing things which are impossible, slow or very difficult to test -with integration tests, such as: - -* Forcing rare / strange / random situations that can't be forced, such as specific network - failures and exceptions -* Extensive testing of slow configuration APIs -* Situations where the integration tests cannot be run as part of the main Ansible - continuous integration running in Azure Pipelines. - - - -Providing quick feedback ------------------------- - -Example: - A single step of the rds_instance test cases can take up to 20 - minutes (the time to create an RDS instance in Amazon). The entire - test run can last for well over an hour. All 16 of the unit tests - complete execution in less than 2 seconds. - -The time saving provided by being able to run the code in a unit test makes it worth -creating a unit test when bug fixing a module, even if those tests do not often identify -problems later. As a basic goal, every module should have at least one unit test which -will give quick feedback in easy cases without having to wait for the integration tests to -complete. - -Ensuring correct use of external interfaces -------------------------------------------- - -Unit tests can check the way in which external services are run to ensure that they match -specifications or are as efficient as possible *even when the final output will not be changed*. - -Example: - Package managers are often far more efficient when installing multiple packages at once - rather than each package separately. The final result is the - same: the packages are all installed, so the efficiency is difficult to verify through - integration tests. By providing a mock package manager and verifying that it is called - once, we can build a valuable test for module efficiency. - -Another related use is in the situation where an API has versions which behave -differently. A programmer working on a new version may change the module to work with the -new API version and unintentionally break the old version. A test case -which checks that the call happens properly for the old version can help avoid the -problem. In this situation it is very important to include version numbering in the test case -name (see `Naming unit tests`_ below). - -Providing specific design tests --------------------------------- - -By building a requirement for a particular part of the -code and then coding to that requirement, unit tests _can_ sometimes improve the code and -help future developers understand that code. - -Unit tests that test internal implementation details of code, on the other hand, almost -always do more harm than good. Testing that your packages to install are stored in a list -would slow down and confuse a future developer who might need to change that list into a -dictionary for efficiency. This problem can be reduced somewhat with clear test naming so -that the future developer immediately knows to delete the test case, but it is often -better to simply leave out the test case altogether and test for a real valuable feature -of the code, such as installing all of the packages supplied as arguments to the module. - - -How to unit test Ansible modules -================================ - -There are a number of techniques for unit testing modules. Beware that most -modules without unit tests are structured in a way that makes testing quite difficult and -can lead to very complicated tests which need more work than the code. Effectively using unit -tests may lead you to restructure your code. This is often a good thing and leads -to better code overall. Good restructuring can make your code clearer and easier to understand. - - -Naming unit tests ------------------ - -Unit tests should have logical names. If a developer working on the module being tested -breaks the test case, it should be easy to figure what the unit test covers from the name. -If a unit test is designed to verify compatibility with a specific software or API version -then include the version in the name of the unit test. - -As an example, ``test_v2_state_present_should_call_create_server_with_name()`` would be a -good name, ``test_create_server()`` would not be. - - -Use of Mocks ------------- - -Mock objects (from https://docs.python.org/3/library/unittest.mock.html) can be very -useful in building unit tests for special / difficult cases, but they can also -lead to complex and confusing coding situations. One good use for mocks would be in -simulating an API. As for 'six', the 'mock' python package is bundled with Ansible (use -``import units.compat.mock``). - -Ensuring failure cases are visible with mock objects ----------------------------------------------------- - -Functions like :meth:`module.fail_json` are normally expected to terminate execution. When you -run with a mock module object this doesn't happen since the mock always returns another mock -from a function call. You can set up the mock to raise an exception as shown above, or you can -assert that these functions have not been called in each test. For example: - -.. code-block:: python - - module = MagicMock() - function_to_test(module, argument) - module.fail_json.assert_not_called() - -This applies not only to calling the main module but almost any other -function in a module which gets the module object. - - -Mocking of the actual module ----------------------------- - -The setup of an actual module is quite complex (see `Passing Arguments`_ below) and often -isn't needed for most functions which use a module. Instead you can use a mock object as -the module and create any module attributes needed by the function you are testing. If -you do this, beware that the module exit functions need special handling as mentioned -above, either by throwing an exception or ensuring that they haven't been called. For example: - -.. code-block:: python - - class AnsibleExitJson(Exception): - """Exception class to be raised by module.exit_json and caught by the test case""" - pass - - # you may also do the same to fail json - module = MagicMock() - module.exit_json.side_effect = AnsibleExitJson(Exception) - with self.assertRaises(AnsibleExitJson) as result: - results = my_module.test_this_function(module, argument) - module.fail_json.assert_not_called() - assert results["changed"] == True - -API definition with unit test cases ------------------------------------ - -API interaction is usually best tested with the function tests defined in Ansible's -integration testing section, which run against the actual API. There are several cases -where the unit tests are likely to work better. - -Defining a module against an API specification -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This case is especially important for modules interacting with web services, which provide -an API that Ansible uses but which are beyond the control of the user. - -By writing a custom emulation of the calls that return data from the API, we can ensure -that only the features which are clearly defined in the specification of the API are -present in the message. This means that we can check that we use the correct -parameters and nothing else. - - -*Example: in rds_instance unit tests a simple instance state is defined*: - -.. code-block:: python - - def simple_instance_list(status, pending): - return {u'DBInstances': [{u'DBInstanceArn': 'arn:aws:rds:us-east-1:1234567890:db:fakedb', - u'DBInstanceStatus': status, - u'PendingModifiedValues': pending, - u'DBInstanceIdentifier': 'fakedb'}]} - -This is then used to create a list of states: - -.. code-block:: python - - rds_client_double = MagicMock() - rds_client_double.describe_db_instances.side_effect = [ - simple_instance_list('rebooting', {"a": "b", "c": "d"}), - simple_instance_list('available', {"c": "d", "e": "f"}), - simple_instance_list('rebooting', {"a": "b"}), - simple_instance_list('rebooting', {"e": "f", "g": "h"}), - simple_instance_list('rebooting', {}), - simple_instance_list('available', {"g": "h", "i": "j"}), - simple_instance_list('rebooting', {"i": "j", "k": "l"}), - simple_instance_list('available', {}), - simple_instance_list('available', {}), - ] - -These states are then used as returns from a mock object to ensure that the ``await`` function -waits through all of the states that would mean the RDS instance has not yet completed -configuration: - -.. code-block:: python - - rds_i.await_resource(rds_client_double, "some-instance", "available", mod_mock, - await_pending=1) - assert(len(sleeper_double.mock_calls) > 5), "await_pending didn't wait enough" - -By doing this we check that the ``await`` function will keep waiting through -potentially unusual that it would be impossible to reliably trigger through the -integration tests but which happen unpredictably in reality. - -Defining a module to work against multiple API versions -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This case is especially important for modules interacting with many different versions of -software; for example, package installation modules that might be expected to work with -many different operating system versions. - -By using previously stored data from various versions of an API we can ensure that the -code is tested against the actual data which will be sent from that version of the system -even when the version is very obscure and unlikely to be available during testing. - -Ansible special cases for unit testing -====================================== - -There are a number of special cases for unit testing the environment of an Ansible module. -The most common are documented below, and suggestions for others can be found by looking -at the source code of the existing unit tests or asking on the Ansible chat channel or mailing -lists. For more information on joining chat channels and subscribing to mailing lists, see :ref:`communication`. - -Module argument processing --------------------------- - -There are two problems with running the main function of a module: - -* Since the module is supposed to accept arguments on ``STDIN`` it is a bit difficult to - set up the arguments correctly so that the module will get them as parameters. -* All modules should finish by calling either the :meth:`module.fail_json` or - :meth:`module.exit_json`, but these won't work correctly in a testing environment. - -Passing Arguments ------------------ - -.. This section should be updated once https://github.com/ansible/ansible/pull/31456 is - closed since the function below will be provided in a library file. - -To pass arguments to a module correctly, use the ``set_module_args`` method which accepts a dictionary -as its parameter. Module creation and argument processing is -handled through the :class:`AnsibleModule` object in the basic section of the utilities. Normally -this accepts input on ``STDIN``, which is not convenient for unit testing. When the special -variable is set it will be treated as if the input came on ``STDIN`` to the module. Simply call that function before setting up your module: - -.. code-block:: python - - import json - from units.modules.utils import set_module_args - from ansible.module_utils.common.text.converters import to_bytes - - def test_already_registered(self): - set_module_args({ - 'activationkey': 'key', - 'username': 'user', - 'password': 'pass', - }) - -Handling exit correctly ------------------------ - -.. This section should be updated once https://github.com/ansible/ansible/pull/31456 is - closed since the exit and failure functions below will be provided in a library file. - -The :meth:`module.exit_json` function won't work properly in a testing environment since it -writes error information to ``STDOUT`` upon exit, where it -is difficult to examine. This can be mitigated by replacing it (and :meth:`module.fail_json`) with -a function that raises an exception: - -.. code-block:: python - - def exit_json(*args, **kwargs): - if 'changed' not in kwargs: - kwargs['changed'] = False - raise AnsibleExitJson(kwargs) - -Now you can ensure that the first function called is the one you expected simply by -testing for the correct exception: - -.. code-block:: python - - def test_returned_value(self): - set_module_args({ - 'activationkey': 'key', - 'username': 'user', - 'password': 'pass', - }) - - with self.assertRaises(AnsibleExitJson) as result: - my_module.main() - -The same technique can be used to replace :meth:`module.fail_json` (which is used for failure -returns from modules) and for the ``aws_module.fail_json_aws()`` (used in modules for Amazon -Web Services). - -Running the main function -------------------------- - -If you do want to run the actual main function of a module you must import the module, set -the arguments as above, set up the appropriate exit exception and then run the module: - -.. code-block:: python - - # This test is based around pytest's features for individual test functions - import pytest - import ansible.modules.module.group.my_module as my_module - - def test_main_function(monkeypatch): - monkeypatch.setattr(my_module.AnsibleModule, "exit_json", fake_exit_json) - set_module_args({ - 'activationkey': 'key', - 'username': 'user', - 'password': 'pass', - }) - my_module.main() - - -Handling calls to external executables --------------------------------------- - -Module must use :meth:`AnsibleModule.run_command` in order to execute an external command. This -method needs to be mocked: - -Here is a simple mock of :meth:`AnsibleModule.run_command` (taken from :file:`test/units/modules/packaging/os/test_rhn_register.py`): - -.. code-block:: python - - with patch.object(basic.AnsibleModule, 'run_command') as run_command: - run_command.return_value = 0, '', '' # successful execution, no output - with self.assertRaises(AnsibleExitJson) as result: - my_module.main() - self.assertFalse(result.exception.args[0]['changed']) - # Check that run_command has been called - run_command.assert_called_once_with('/usr/bin/command args') - self.assertEqual(run_command.call_count, 1) - self.assertFalse(run_command.called) - - -A Complete Example ------------------- - -The following example is a complete skeleton that reuses the mocks explained above and adds a new -mock for :meth:`Ansible.get_bin_path`: - -.. code-block:: python - - import json - - from units.compat import unittest - from units.compat.mock import patch - from ansible.module_utils import basic - from ansible.module_utils.common.text.converters import to_bytes - from ansible.modules.namespace import my_module - - - def set_module_args(args): - """prepare arguments so that they will be picked up during module creation""" - args = json.dumps({'ANSIBLE_MODULE_ARGS': args}) - basic._ANSIBLE_ARGS = to_bytes(args) - - - class AnsibleExitJson(Exception): - """Exception class to be raised by module.exit_json and caught by the test case""" - pass - - - class AnsibleFailJson(Exception): - """Exception class to be raised by module.fail_json and caught by the test case""" - pass - - - def exit_json(*args, **kwargs): - """function to patch over exit_json; package return data into an exception""" - if 'changed' not in kwargs: - kwargs['changed'] = False - raise AnsibleExitJson(kwargs) - - - def fail_json(*args, **kwargs): - """function to patch over fail_json; package return data into an exception""" - kwargs['failed'] = True - raise AnsibleFailJson(kwargs) - - - def get_bin_path(self, arg, required=False): - """Mock AnsibleModule.get_bin_path""" - if arg.endswith('my_command'): - return '/usr/bin/my_command' - else: - if required: - fail_json(msg='%r not found !' % arg) - - - class TestMyModule(unittest.TestCase): - - def setUp(self): - self.mock_module_helper = patch.multiple(basic.AnsibleModule, - exit_json=exit_json, - fail_json=fail_json, - get_bin_path=get_bin_path) - self.mock_module_helper.start() - self.addCleanup(self.mock_module_helper.stop) - - def test_module_fail_when_required_args_missing(self): - with self.assertRaises(AnsibleFailJson): - set_module_args({}) - my_module.main() - - - def test_ensure_command_called(self): - set_module_args({ - 'param1': 10, - 'param2': 'test', - }) - - with patch.object(basic.AnsibleModule, 'run_command') as mock_run_command: - stdout = 'configuration updated' - stderr = '' - rc = 0 - mock_run_command.return_value = rc, stdout, stderr # successful execution - - with self.assertRaises(AnsibleExitJson) as result: - my_module.main() - self.assertFalse(result.exception.args[0]['changed']) # ensure result is changed - - mock_run_command.assert_called_once_with('/usr/bin/my_command --value 10 --name test') - - -Restructuring modules to enable testing module set up and other processes -------------------------------------------------------------------------- - -Often modules have a ``main()`` function which sets up the module and then performs other -actions. This can make it difficult to check argument processing. This can be made easier by -moving module configuration and initialization into a separate function. For example: - -.. code-block:: python - - argument_spec = dict( - # module function variables - state=dict(choices=['absent', 'present', 'rebooted', 'restarted'], default='present'), - apply_immediately=dict(type='bool', default=False), - wait=dict(type='bool', default=False), - wait_timeout=dict(type='int', default=600), - allocated_storage=dict(type='int', aliases=['size']), - db_instance_identifier=dict(aliases=["id"], required=True), - ) - - def setup_module_object(): - module = AnsibleAWSModule( - argument_spec=argument_spec, - required_if=required_if, - mutually_exclusive=[['old_instance_id', 'source_db_instance_identifier', - 'db_snapshot_identifier']], - ) - return module - - def main(): - module = setup_module_object() - validate_parameters(module) - conn = setup_client(module) - return_dict = run_task(module, conn) - module.exit_json(**return_dict) - -This now makes it possible to run tests against the module initiation function: - -.. code-block:: python - - def test_rds_module_setup_fails_if_db_instance_identifier_parameter_missing(): - # db_instance_identifier parameter is missing - set_module_args({ - 'state': 'absent', - 'apply_immediately': 'True', - }) - - with self.assertRaises(AnsibleFailJson) as result: - my_module.setup_json - -See also ``test/units/module_utils/aws/test_rds.py`` - -Note that the ``argument_spec`` dictionary is visible in a module variable. This has -advantages, both in allowing explicit testing of the arguments and in allowing the easy -creation of module objects for testing. - -The same restructuring technique can be valuable for testing other functionality, such as the part of the module which queries the object that the module configures. - -Traps for maintaining Python 2 compatibility -============================================ - -If you use the ``mock`` library from the Python 2.6 standard library, a number of the -assert functions are missing but will return as if successful. This means that test cases should take great care *not* use -functions marked as _new_ in the Python 3 documentation, since the tests will likely always -succeed even if the code is broken when run on older versions of Python. - -A helpful development approach to this should be to ensure that all of the tests have been -run under Python 2.6 and that each assertion in the test cases has been checked to work by breaking -the code in Ansible to trigger that failure. - -.. warning:: Maintain Python 2.6 compatibility - - Please remember that modules need to maintain compatibility with Python 2.6 so the unittests for - modules should also be compatible with Python 2.6. - - -.. seealso:: - - :ref:`testing_units` - Ansible unit tests documentation - :ref:`testing_running_locally` - Running tests locally including gathering and reporting coverage data - :ref:`developing_modules_general` - Get started developing a module - `Python 3 documentation - 26.4. unittest — Unit testing framework `_ - The documentation of the unittest framework in python 3 - `Python 2 documentation - 25.3. unittest — Unit testing framework `_ - The documentation of the earliest supported unittest framework - from Python 2.6 - `pytest: helps you write better programs `_ - The documentation of pytest - the framework actually used to run Ansible unit tests - `Development Mailing List `_ - Mailing list for development topics - `Testing Your Code (from The Hitchhiker's Guide to Python!) `_ - General advice on testing Python code - `Uncle Bob's many videos on YouTube `_ - Unit testing is a part of the of various philosophies of software development, including - Extreme Programming (XP), Clean Coding. Uncle Bob talks through how to benefit from this - `"Why Most Unit Testing is Waste" `_ - An article warning against the costs of unit testing - `'A Response to "Why Most Unit Testing is Waste"' `_ - An response pointing to how to maintain the value of unit tests diff --git a/docs/docsite/rst/dev_guide/testing_validate-modules.rst b/docs/docsite/rst/dev_guide/testing_validate-modules.rst deleted file mode 100644 index 1c74fe39b1a..00000000000 --- a/docs/docsite/rst/dev_guide/testing_validate-modules.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -**************** -validate-modules -**************** - -This page has moved to :ref:`testing_validate-modules`. diff --git a/docs/docsite/rst/galaxy/dev_guide.rst b/docs/docsite/rst/galaxy/dev_guide.rst deleted file mode 100644 index 01a92d02900..00000000000 --- a/docs/docsite/rst/galaxy/dev_guide.rst +++ /dev/null @@ -1,226 +0,0 @@ -.. _developing_galaxy: - -********************** -Galaxy Developer Guide -********************** - -You can host collections and roles on Galaxy to share with the Ansible community. Galaxy content is formatted in pre-packaged units of work such as :ref:`roles `, and new in Galaxy 3.2, :ref:`collections `. -You can create roles for provisioning infrastructure, deploying applications, and all of the tasks you do everyday. Taking this a step further, you can create collections which provide a comprehensive package of automation that may include multiple playbooks, roles, modules, and plugins. - -.. contents:: - :local: - :depth: 2 - -.. _creating_collections_galaxy: - -Creating collections for Galaxy -=============================== - -Collections are a distribution format for Ansible content. You can use collections to package and distribute playbooks, roles, modules, and plugins. -You can publish and use collections through `Ansible Galaxy `_. - -See :ref:`developing_collections` for details on how to create collections. - -.. _creating_roles_galaxy: - - -Creating roles for Galaxy -========================= - -Use the ``init`` command to initialize the base structure of a new role, saving time on creating the various directories and main.yml files a role requires - -.. code-block:: bash - - $ ansible-galaxy init role_name - -The above will create the following directory structure in the current working directory: - -.. code-block:: text - - role_name/ - README.md - .travis.yml - defaults/ - main.yml - files/ - handlers/ - main.yml - meta/ - main.yml - templates/ - tests/ - inventory - test.yml - vars/ - main.yml - -If you want to create a repository for the role, the repository root should be `role_name`. - -Force ------ - -If a directory matching the name of the role already exists in the current working directory, the init command will result in an error. To ignore the error -use the ``--force`` option. Force will create the above subdirectories and files, replacing anything that matches. - -Container enabled ------------------ - -If you are creating a Container Enabled role, pass ``--type container`` to ``ansible-galaxy init``. This will create the same directory structure as above, but populate it -with default files appropriate for a Container Enabled role. For instance, the README.md has a slightly different structure, the *.travis.yml* file tests -the role using `Ansible Container `_, and the meta directory includes a *container.yml* file. - -Using a custom role skeleton ----------------------------- - -A custom role skeleton directory can be supplied as follows: - -.. code-block:: bash - - $ ansible-galaxy init --role-skeleton=/path/to/skeleton role_name - -When a skeleton is provided, init will: - -- copy all files and directories from the skeleton to the new role -- any .j2 files found outside of a templates folder will be rendered as templates. The only useful variable at the moment is role_name -- The .git folder and any .git_keep files will not be copied - -Alternatively, the role_skeleton and ignoring of files can be configured via ansible.cfg - -.. code-block:: text - - [galaxy] - role_skeleton = /path/to/skeleton - role_skeleton_ignore = ^.git$,^.*/.git_keep$ - -Authenticate with Galaxy ------------------------- - -Using the ``import``, ``delete`` and ``setup`` commands to manage your roles on the Galaxy website requires authentication in the form of an API key, you must create an account on the Galaxy website. - -#. Log in to the Galaxy website and open the `Preferences `_ view. -#. Select **Show API key** and then copy it. - -#. Save your token in the path set in the :ref:`GALAXY_TOKEN_PATH`. - - -Import a role -------------- - -The ``import`` command requires that you first authenticate using the ``login`` command. Once authenticated you can import any GitHub repository that you own or have been granted access. - -Use the following to import to role: - -.. code-block:: bash - - $ ansible-galaxy import github_user github_repo - -By default the command will wait for Galaxy to complete the import process, displaying the results as the import progresses: - -.. code-block:: text - - Successfully submitted import request 41 - Starting import 41: role_name=myrole repo=githubuser/ansible-role-repo ref= - Retrieving GitHub repo githubuser/ansible-role-repo - Accessing branch: devel - Parsing and validating meta/main.yml - Parsing galaxy_tags - Parsing platforms - Adding dependencies - Parsing and validating README.md - Adding repo tags as role versions - Import completed - Status SUCCESS : warnings=0 errors=0 - -Branch -^^^^^^ - -Use the ``--branch`` option to import a specific branch. If not specified, the default branch for the repo will be used. - -Role name -^^^^^^^^^ - -By default the name given to the role will be derived from the GitHub repository name. However, you can use the ``--role-name`` option to override this and set the name. - -No wait -^^^^^^^ - -If the ``--no-wait`` option is present, the command will not wait for results. Results of the most recent import for any of your roles is available on the Galaxy web site by visiting *My Imports*. - -Delete a role -------------- - -The ``delete`` command requires that you first authenticate using the ``login`` command. Once authenticated you can remove a role from the Galaxy web site. You are only allowed to remove roles where you have access to the repository in GitHub. - -Use the following to delete a role: - -.. code-block:: bash - - $ ansible-galaxy delete github_user github_repo - -This only removes the role from Galaxy. It does not remove or alter the actual GitHub repository. - - -Travis integrations -------------------- - -You can create an integration or connection between a role in Galaxy and `Travis `_. Once the connection is established, a build in Travis will -automatically trigger an import in Galaxy, updating the search index with the latest information about the role. - -You create the integration using the ``setup`` command, but before an integration can be created, you must first authenticate using the ``login`` command; you will -also need an account in Travis, and your Travis token. Once you're ready, use the following command to create the integration: - -.. code-block:: bash - - $ ansible-galaxy setup travis github_user github_repo xxx-travis-token-xxx - -The setup command requires your Travis token, however the token is not stored in Galaxy. It is used along with the GitHub username and repo to create a hash as described -in `the Travis documentation `_. The hash is stored in Galaxy and used to verify notifications received from Travis. - -The setup command enables Galaxy to respond to notifications. To configure Travis to run a build on your repository and send a notification, follow the -`Travis getting started guide `_. - -To instruct Travis to notify Galaxy when a build completes, add the following to your .travis.yml file: - -.. code-block:: text - - notifications: - webhooks: https://galaxy.ansible.com/api/v1/notifications/ - - -List Travis integrations -^^^^^^^^^^^^^^^^^^^^^^^^ - -Use the ``--list`` option to display your Travis integrations: - -.. code-block:: bash - - $ ansible-galaxy setup --list - - - ID Source Repo - ---------- ---------- ---------- - 2 travis github_user/github_repo - 1 travis github_user/github_repo - - -Remove Travis integrations -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use the ``--remove`` option to disable and remove a Travis integration: - - .. code-block:: bash - - $ ansible-galaxy setup --remove ID - -Provide the ID of the integration to be disabled. You can find the ID by using the ``--list`` option. - - -.. seealso:: - :ref:`collections` - Shareable collections of modules, playbooks and roles - :ref:`playbooks_reuse_roles` - All about ansible roles - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/galaxy/user_guide.rst b/docs/docsite/rst/galaxy/user_guide.rst deleted file mode 100644 index c5a1e19e8fb..00000000000 --- a/docs/docsite/rst/galaxy/user_guide.rst +++ /dev/null @@ -1,497 +0,0 @@ -.. _using_galaxy: -.. _ansible_galaxy: - -***************** -Galaxy User Guide -***************** - -:dfn:`Ansible Galaxy` refers to the `Galaxy `_ website, a free site for finding, downloading, and sharing community developed roles. - -Use Galaxy to jump-start your automation project with great content from the Ansible community. Galaxy provides pre-packaged units of work such as :ref:`roles `, and new in Galaxy 3.2, :ref:`collections ` -You can find roles for provisioning infrastructure, deploying applications, and all of the tasks you do everyday. The collection format provides a comprehensive package of automation that may include multiple playbooks, roles, modules, and plugins. - -.. contents:: - :local: - :depth: 2 -.. _finding_galaxy_collections: - -Finding collections on Galaxy -============================= - -To find collections on Galaxy: - -#. Click the :guilabel:`Search` icon in the left-hand navigation. -#. Set the filter to *collection*. -#. Set other filters and press :guilabel:`enter`. - -Galaxy presents a list of collections that match your search criteria. - -.. _installing_galaxy_collections: - - -Installing collections -====================== - - -Installing a collection from Galaxy ------------------------------------ - -.. include:: ../shared_snippets/installing_collections.txt - -.. _installing_ah_collection: - -Downloading a collection from Automation Hub ----------------------------------------------------- - -You can download collections from Automation Hub at the command line. Automation Hub content is available to subscribers only, so you must download an API token and configure your local environment to provide it before you can you download collections. To download a collection from Automation Hub with the ``ansible-galaxy`` command: - -1. Get your Automation Hub API token. Go to https://cloud.redhat.com/ansible/automation-hub/token/ and click :guilabel:`Load token` from the version dropdown to copy your API token. -2. Configure Red Hat Automation Hub server in the ``server_list`` option under the ``[galaxy]`` section in your :file:`ansible.cfg` file. - - .. code-block:: ini - - [galaxy] - server_list = automation_hub - - [galaxy_server.automation_hub] - url=https://console.redhat.com/api/automation-hub/ - auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token - token=my_ah_token - -3. Download the collection hosted in Automation Hub. - - .. code-block:: bash - - ansible-galaxy collection install my_namespace.my_collection - -.. seealso:: - `Getting started with Automation Hub `_ - An introduction to Automation Hub - -Installing an older version of a collection -------------------------------------------- - -.. include:: ../shared_snippets/installing_older_collection.txt - -Install multiple collections with a requirements file ------------------------------------------------------ - -.. include:: ../shared_snippets/installing_multiple_collections.txt - -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 - -Listing installed collections ------------------------------ - -To list installed collections, run ``ansible-galaxy collection list``. See :ref:`collections_listing` for more details. - - -Configuring the ``ansible-galaxy`` client ------------------------------------------- - -.. include:: ../shared_snippets/galaxy_server_list.txt - -.. _finding_galaxy_roles: - -Finding roles on Galaxy -======================= - -Search the Galaxy database by tags, platforms, author and multiple keywords. For example: - -.. code-block:: bash - - $ ansible-galaxy search elasticsearch --author geerlingguy - -The search command will return a list of the first 1000 results matching your search: - -.. code-block:: text - - Found 2 roles matching your search: - - Name Description - ---- ----------- - geerlingguy.elasticsearch Elasticsearch for Linux. - geerlingguy.elasticsearch-curator Elasticsearch curator for Linux. - - -Get more information about a role ---------------------------------- - -Use the ``info`` command to view more detail about a specific role: - -.. code-block:: bash - - $ ansible-galaxy info username.role_name - -This returns everything found in Galaxy for the role: - -.. code-block:: text - - Role: username.role_name - description: Installs and configures a thing, a distributed, highly available NoSQL thing. - active: True - commit: c01947b7bc89ebc0b8a2e298b87ab416aed9dd57 - commit_message: Adding travis - commit_url: https://github.com/username/repo_name/commit/c01947b7bc89ebc0b8a2e298b87ab - company: My Company, Inc. - created: 2015-12-08T14:17:52.773Z - download_count: 1 - forks_count: 0 - github_branch: - github_repo: repo_name - github_user: username - id: 6381 - is_valid: True - issue_tracker_url: - license: Apache - min_ansible_version: 1.4 - modified: 2015-12-08T18:43:49.085Z - namespace: username - open_issues_count: 0 - path: /Users/username/projects/roles - scm: None - src: username.repo_name - stargazers_count: 0 - travis_status_url: https://travis-ci.org/username/repo_name.svg?branch=main - version: - watchers_count: 1 - - -.. _installing_galaxy_roles: - -Installing roles from Galaxy -============================ - -The ``ansible-galaxy`` command comes bundled with Ansible, and you can use it to install roles from Galaxy or directly from a git based SCM. You can -also use it to create a new role, remove roles, or perform tasks on the Galaxy website. - -The command line tool by default communicates with the Galaxy website API using the server address *https://galaxy.ansible.com*. If you run your own internal Galaxy server -and want to use it instead of the default one, pass the ``--server`` option following the address of this galaxy server. You can set permanently this option by setting -the Galaxy server value in your ``ansible.cfg`` file to use it . For information on setting the value in *ansible.cfg* see :ref:`galaxy_server`. - - -Installing roles ----------------- - -Use the ``ansible-galaxy`` command to download roles from the `Galaxy website `_ - -.. code-block:: bash - - $ ansible-galaxy install namespace.role_name - -Setting where to install roles -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default, Ansible downloads roles to the first writable directory in the default list of paths ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles``. This installs roles in the home directory of the user running ``ansible-galaxy``. - -You can override this with one of the following options: - -* Set the environment variable :envvar:`ANSIBLE_ROLES_PATH` in your session. -* Use the ``--roles-path`` option for the ``ansible-galaxy`` command. -* Define ``roles_path`` in an ``ansible.cfg`` file. - -The following provides an example of using ``--roles-path`` to install the role into the current working directory: - -.. code-block:: bash - - $ ansible-galaxy install --roles-path . geerlingguy.apache - -.. seealso:: - - :ref:`intro_configuration` - All about configuration files - -Installing a specific version of a role ---------------------------------------- - -When the Galaxy server imports a role, it imports any git tags matching the `Semantic Version `_ format as versions. -In turn, you can download a specific version of a role by specifying one of the imported tags. - -To see the available versions for a role: - -#. Locate the role on the Galaxy search page. -#. Click on the name to view more details, including the available versions. - -You can also navigate directly to the role using the //. For example, to view the role geerlingguy.apache, go to ``_. - -To install a specific version of a role from Galaxy, append a comma and the value of a GitHub release tag. For example: - -.. code-block:: bash - - $ ansible-galaxy install geerlingguy.apache,1.0.0 - -It is also possible to point directly to the git repository and specify a branch name or commit hash as the version. For example, the following will -install a specific commit: - -.. code-block:: bash - - $ ansible-galaxy install git+https://github.com/geerlingguy/ansible-role-apache.git,0b7cd353c0250e87a26e0499e59e7fd265cc2f25 - -Installing multiple roles from a file -------------------------------------- - -You can install multiple roles by including the roles in a :file:`requirements.yml` file. The format of the file is YAML, and the -file extension must be either *.yml* or *.yaml*. - -Use the following command to install roles included in :file:`requirements.yml:` - -.. code-block:: bash - - $ ansible-galaxy install -r requirements.yml - -Again, the extension is important. If the *.yml* extension is left off, the ``ansible-galaxy`` CLI assumes the file is in an older, now deprecated, -"basic" format. - -Each role in the file will have one or more of the following attributes: - - src - The source of the role. Use the format *namespace.role_name*, if downloading from Galaxy; otherwise, provide a URL pointing - to a repository within a git based SCM. See the examples below. This is a required attribute. - scm - Specify the SCM. As of this writing only *git* or *hg* are allowed. See the examples below. Defaults to *git*. - version: - The version of the role to download. Provide a release tag value, commit hash, or branch name. Defaults to the branch set as a default in the repository, otherwise defaults to the *master*. - name: - Download the role to a specific name. Defaults to the Galaxy name when downloading from Galaxy, otherwise it defaults - to the name of the repository. - -Use the following example as a guide for specifying roles in *requirements.yml*: - -.. code-block:: yaml - - # from galaxy - - name: yatesr.timezone - - # from locally cloned git repository (git+file:// requires full paths) - - src: git+file:///home/bennojoy/nginx - - # from GitHub - - src: https://github.com/bennojoy/nginx - - # from GitHub, overriding the name and specifying a specific tag - - name: nginx_role - src: https://github.com/bennojoy/nginx - version: main - - # from GitHub, specifying a specific commit hash - - src: https://github.com/bennojoy/nginx - version: "ee8aa41" - - # from a webserver, where the role is packaged in a tar.gz - - name: http-role-gz - src: https://some.webserver.example.com/files/main.tar.gz - - # from a webserver, where the role is packaged in a tar.bz2 - - name: http-role-bz2 - src: https://some.webserver.example.com/files/main.tar.bz2 - - # from a webserver, where the role is packaged in a tar.xz (Python 3.x only) - - name: http-role-xz - src: https://some.webserver.example.com/files/main.tar.xz - - # from Bitbucket - - src: git+https://bitbucket.org/willthames/git-ansible-galaxy - version: v1.4 - - # from Bitbucket, alternative syntax and caveats - - src: https://bitbucket.org/willthames/hg-ansible-galaxy - scm: hg - - # from GitLab or other git-based scm, using git+ssh - - src: git@gitlab.company.com:mygroup/ansible-core.git - scm: git - version: "0.1" # quoted, so YAML doesn't parse this as a floating-point value - -.. warning:: - - Embedding credentials into a SCM URL is not secure. Make sure to use safe auth options for security reasons. For example, use `SSH `_, `netrc `_ or `http.extraHeader `_/`url..pushInsteadOf `_ in Git config to prevent your creds from being exposed in logs. - -Installing roles and collections from the same requirements.yml file ---------------------------------------------------------------------- - -You can install roles and collections from the same requirements files - -.. code-block:: yaml - - --- - roles: - # Install a role from Ansible Galaxy. - - name: geerlingguy.java - version: "1.9.6" # note that ranges are not supported for roles - - collections: - # Install a collection from Ansible Galaxy. - - name: geerlingguy.php_roles - version: ">=0.9.3" - source: https://galaxy.ansible.com - -Installing multiple roles from multiple files ---------------------------------------------- - -For large projects, the ``include`` directive in a :file:`requirements.yml` file provides the ability to split a large file into multiple smaller files. - -For example, a project may have a :file:`requirements.yml` file, and a :file:`webserver.yml` file. - -Below are the contents of the :file:`webserver.yml` file: - -.. code-block:: bash - - # from github - - src: https://github.com/bennojoy/nginx - - # from Bitbucket - - src: git+https://bitbucket.org/willthames/git-ansible-galaxy - version: v1.4 - -The following shows the contents of the :file:`requirements.yml` file that now includes the :file:`webserver.yml` file: - -.. code-block:: bash - - # from galaxy - - name: yatesr.timezone - - include: /webserver.yml - -To install all the roles from both files, pass the root file, in this case :file:`requirements.yml` on the -command line, as follows: - -.. code-block:: bash - - $ ansible-galaxy install -r requirements.yml - -.. _galaxy_dependencies: - -Dependencies ------------- - -Roles can also be dependent on other roles, and when you install a role that has dependencies, those dependencies will automatically be installed to the ``roles_path``. - -There are two ways to define the dependencies of a role: - -* using ``meta/requirements.yml`` -* using ``meta/main.yml`` - -Using ``meta/requirements.yml`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. versionadded:: 2.10 - -You can create the file ``meta/requirements.yml`` and define dependencies in the same format used for :file:`requirements.yml` described in the `Installing multiple roles from a file`_ section. - -From there, you can import or include the specified roles in your tasks. - -Using ``meta/main.yml`` -^^^^^^^^^^^^^^^^^^^^^^^ - -Alternatively, you can specify role dependencies in the ``meta/main.yml`` file by providing a list of roles under the ``dependencies`` section. If the source of a role is Galaxy, you can simply specify the role in -the format ``namespace.role_name``. You can also use the more complex format in :file:`requirements.yml`, allowing you to provide ``src``, ``scm``, ``version``, and ``name``. - -Dependencies installed that way, depending on other factors described below, will also be executed **before** this role is executed during play execution. -To better understand how dependencies are handled during play execution, see :ref:`playbooks_reuse_roles`. - -The following shows an example ``meta/main.yml`` file with dependent roles: - -.. code-block:: yaml - - --- - dependencies: - - geerlingguy.java - - galaxy_info: - author: geerlingguy - description: Elasticsearch for Linux. - company: "Midwestern Mac, LLC" - license: "license (BSD, MIT)" - min_ansible_version: 2.4 - platforms: - - name: EL - versions: - - all - - name: Debian - versions: - - all - - name: Ubuntu - versions: - - all - galaxy_tags: - - web - - system - - monitoring - - logging - - lucene - - elk - - elasticsearch - -Tags are inherited *down* the dependency chain. In order for tags to be applied to a role and all its dependencies, the tag should be applied to the role, not to all the tasks within a role. - -Roles listed as dependencies are subject to conditionals and tag filtering, and may not execute fully depending on -what tags and conditionals are applied. - -If the source of a role is Galaxy, specify the role in the format *namespace.role_name*: - -.. code-block:: yaml - - dependencies: - - geerlingguy.apache - - geerlingguy.ansible - - -Alternately, you can specify the role dependencies in the complex form used in :file:`requirements.yml` as follows: - -.. code-block:: yaml - - dependencies: - - name: geerlingguy.ansible - - name: composer - src: git+https://github.com/geerlingguy/ansible-role-composer.git - version: 775396299f2da1f519f0d8885022ca2d6ee80ee8 - -.. note:: - - Galaxy expects all role dependencies to exist in Galaxy, and therefore dependencies to be specified in the - ``namespace.role_name`` format. If you import a role with a dependency where the ``src`` value is a URL, the import process will fail. - -List installed roles --------------------- - -Use ``list`` to show the name and version of each role installed in the *roles_path*. - -.. code-block:: bash - - $ ansible-galaxy list - - ansible-network.network-engine, v2.7.2 - - ansible-network.config_manager, v2.6.2 - - ansible-network.cisco_nxos, v2.7.1 - - ansible-network.vyos, v2.7.3 - - ansible-network.cisco_ios, v2.7.0 - -Remove an installed role ------------------------- - -Use ``remove`` to delete a role from *roles_path*: - -.. code-block:: bash - - $ ansible-galaxy remove namespace.role_name - - -.. seealso:: - :ref:`collections` - Shareable collections of modules, playbooks and roles - :ref:`playbooks_reuse_roles` - Reusable tasks, handlers, and other files in a known directory structure - :ref:`command_line_tools` - Perform other related operations - diff --git a/docs/docsite/rst/getting_started/ansible_output/first_playbook_output.txt b/docs/docsite/rst/getting_started/ansible_output/first_playbook_output.txt deleted file mode 100644 index e5e1dcb8fd4..00000000000 --- a/docs/docsite/rst/getting_started/ansible_output/first_playbook_output.txt +++ /dev/null @@ -1,27 +0,0 @@ -PLAY [My first play] ********************************************************************** - -TASK [Gathering Facts] ******************************************************************** -ok: [vm01] -ok: [vm02] -ok: [vm03] - -TASK [Ping my hosts] ********************************************************************** -ok: [vm01] -ok: [vm02] -ok: [vm03] - -TASK [Print message] ********************************************************************** -ok: [vm01] => { - "msg": "Hello world" -} -ok: [vm02] => { - "msg": "Hello world" -} -ok: [vm03] => { - "msg": "Hello world" -} - -PLAY RECAP ******************************************************************************** -vm01: ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 -vm02: ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 -vm03: ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 diff --git a/docs/docsite/rst/getting_started/ansible_output/ping_inventory_output.txt b/docs/docsite/rst/getting_started/ansible_output/ping_inventory_output.txt deleted file mode 100644 index cd7c4dd7c19..00000000000 --- a/docs/docsite/rst/getting_started/ansible_output/ping_inventory_output.txt +++ /dev/null @@ -1,21 +0,0 @@ -vm03 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python3" - }, - "changed": false, - "ping": "pong" -} -vm02 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python3" - }, - "changed": false, - "ping": "pong" -} -vm01 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python3" - }, - "changed": false, - "ping": "pong" -} \ No newline at end of file diff --git a/docs/docsite/rst/getting_started/ansible_output/ping_output.txt b/docs/docsite/rst/getting_started/ansible_output/ping_output.txt deleted file mode 100644 index 9fe88862ef3..00000000000 --- a/docs/docsite/rst/getting_started/ansible_output/ping_output.txt +++ /dev/null @@ -1,21 +0,0 @@ -192.0.2.50 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python3" - }, - "changed": false, - "ping": "pong" - } -192.0.2.51 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python3" - }, - "changed": false, - "ping": "pong" - } -192.0.2.52 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python3" - }, - "changed": false, - "ping": "pong" - } \ No newline at end of file diff --git a/docs/docsite/rst/getting_started/basic_concepts.rst b/docs/docsite/rst/getting_started/basic_concepts.rst deleted file mode 100644 index cc433c81f2f..00000000000 --- a/docs/docsite/rst/getting_started/basic_concepts.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. _basic_concepts: - -**************** -Ansible concepts -**************** - -These concepts are common to all uses of Ansible. -You should understand them before using Ansible or reading the documentation. - -.. contents:: - :local: - -.. include:: /shared_snippets/basic_concepts.txt diff --git a/docs/docsite/rst/getting_started/get_started_inventory.rst b/docs/docsite/rst/getting_started/get_started_inventory.rst deleted file mode 100644 index 8df73302073..00000000000 --- a/docs/docsite/rst/getting_started/get_started_inventory.rst +++ /dev/null @@ -1,102 +0,0 @@ -.. _get_started_inventory: - -********************* -Building an inventory -********************* - -Inventories organize managed nodes in centralized files that provide Ansible with system information and network locations. -Using an inventory file, Ansible can manage a large number of hosts with a single command. -Inventories also help you use Ansible more efficiently by reducing the number of command-line options you need to specify. -For example, inventories usually contain the SSH user so you do not need to include the ``-u`` flag when running Ansible commands. - -In the previous section, you added managed nodes directly to the ``/etc/ansible/hosts`` file. -Now let's create an inventory file that you can add to source control for flexibility, reuse, and for sharing with other users. - -.. note:: - Inventory files can be in ``INI`` or ``YAML`` format. - For demonstration purposes, this section uses ``YAML`` format only. - -Complete the following steps: - -#. Open a terminal window on your control node. -#. Create a new inventory file named ``inventory.yaml`` in any directory and open it for editing. -#. Add a new group for your hosts then specify the IP address or fully qualified domain name (FQDN) of each managed node with the ``ansible_host`` field. - The following example adds the IP addresses of three virtual machines in KVM: - - .. literalinclude:: yaml/inventory_example_vms.yaml - :language: yaml - -#. Verify your inventory. - If you created your inventory in a directory other than your home directory, specify the full path with the ``-i`` option. - - .. code-block:: bash - - ansible-inventory -i inventory.yaml --list - -#. Ping the managed nodes in your inventory. - In this example, the group name is ``virtualmachines`` which you can specify with the ``ansible`` command instead of ``all``. - - .. code-block:: bash - - ansible virtualmachines -m ping -i inventory.yaml - - .. literalinclude:: ansible_output/ping_inventory_output.txt - :language: text - -Congratulations! You have successfully built an inventory. - -Tips for building inventories -============================= - -* Ensure that group names are meaningful and unique. Group names are also case sensitive. -* Avoid spaces, hyphens, and preceding numbers (use ``floor_19``, not ``19th_floor``) in group names. -* Group hosts in your inventory logically according to their **What**, **Where**, and **When**. - - What - Group hosts according to the topology, for example: db, web, leaf, spine. - Where - Group hosts by geographic location, for example: datacenter, region, floor, building. - When - Group hosts by stage, for example: development, test, staging, production. - -Use metagroups --------------- - -Create a metagroup that organizes multiple groups in your inventory with the following syntax: - -.. code-block:: yaml - - metagroupname: - children: - -The following inventory illustrates a basic structure for a data center. -This example inventory contains a ``network`` metagroup that includes all network devices and a ``datacenter`` metagroup that includes the ``network`` group and all webservers. - -.. literalinclude:: yaml/inventory_group_structure.yaml - :language: yaml - -Create variables ----------------- - -Variables set values for managed nodes, such as the IP address, FQDN, operating system, and SSH user, so you do not need to pass them when running Ansible commands. - -Variables can apply to specific hosts. - -.. literalinclude:: yaml/inventory_variables_host.yaml - :language: yaml - -Variables can also apply to all hosts in a group. - -.. literalinclude:: yaml/inventory_variables_group.yaml - :language: yaml - -Now that you know how to build an inventory, continue by :ref:`learning how to create a playbook`. - -.. seealso:: - - :ref:`intro_inventory` - Learn more about inventories in ``YAML`` or ``INI`` format. - :ref:`variables_in_inventory` - Find out more about inventory variables and their syntax. - :ref:`vault` - Find out how to encrypt sensitive content in your inventory such as passwords and keys. diff --git a/docs/docsite/rst/getting_started/get_started_playbook.rst b/docs/docsite/rst/getting_started/get_started_playbook.rst deleted file mode 100644 index 7ee1be6d3bc..00000000000 --- a/docs/docsite/rst/getting_started/get_started_playbook.rst +++ /dev/null @@ -1,70 +0,0 @@ -.. _get_started_playbook: - -******************* -Creating a playbook -******************* - -Playbooks are automation blueprints, in ``YAML`` format, that Ansible uses to deploy and configure managed nodes. - -Playbook - A list of plays that define the order in which Ansible performs operations, from top to bottom, to achieve an overall goal. - -Play - An ordered list of tasks that maps to managed nodes in an inventory. - -Task - A list of one or more modules that defines the operations that Ansible performs. - -Module - A unit of code or binary that Ansible runs on managed nodes. - Ansible modules are grouped in collections with a :term:`Fully Qualified Collection Name (FQCN)` for each module. - -In the previous section, you used the ``ansible`` command to ping hosts in your inventory. -Now let's create a playbook that pings your hosts and also prints a "Hello world" message. - -Complete the following steps: - -#. Open a terminal window on your control node. -#. Create a new playbook file named ``playbook.yaml`` in any directory and open it for editing. -#. Add the following content to ``playbook.yaml``: - - .. literalinclude:: yaml/first_playbook.yaml - :language: yaml - -#. Run your playbook. - - .. code-block:: bash - - ansible-playbook -i inventory.yaml playbook.yaml - -Ansible returns the following output: - -.. literalinclude:: ansible_output/first_playbook_output.txt - :language: text - -In this output you can see: - -* The names that you give the play and each task. - You should always use descriptive names that make it easy to verify and troubleshoot playbooks. - -* The ``Gather Facts`` task runs implicitly. - By default Ansible gathers information about your inventory that it can use in the playbook. - -* The status of each task. - Each task has a status of ``ok`` which means it ran successfully. - -* The play recap that summarizes results of all tasks in the playbook per host. - In this example, there are three tasks so ``ok=3`` indicates that each task ran successfully. - -Congratulations! You have just created your first Ansible playbook. - -.. seealso:: - - :ref:`playbooks_intro` - Start building playbooks for real world scenarios. - :ref:`working_with_playbooks` - Go into more detail with Ansible playbooks. - :ref:`playbooks_best_practices` - Get tips and tricks for using playbooks. - :ref:`vars_and_facts` - Learn more about the ``gather_facts`` keyword in playbooks. \ No newline at end of file diff --git a/docs/docsite/rst/getting_started/index.rst b/docs/docsite/rst/getting_started/index.rst deleted file mode 100644 index 818c7fbe379..00000000000 --- a/docs/docsite/rst/getting_started/index.rst +++ /dev/null @@ -1,99 +0,0 @@ -.. _getting_started_index: - -############################ -Getting started with Ansible -############################ - -Ansible automates the management of remote systems and controls their desired state. -A basic Ansible environment has three main components: - - -Control node - A system on which Ansible is installed. - You run Ansible commands such as ``ansible`` or ``ansible-inventory`` on a control node. - -Managed node - A remote system, or host, that Ansible controls. - -Inventory - A list of managed nodes that are logically organized. - You create an inventory on the control node to describe host deployments to Ansible. - -.. image:: ../images/ansible_basic.svg - :width: 400px - :align: center - :height: 200px - :alt: Basic components of an Ansible environment include a control node, an inventory of managed nodes, and a module copied to each managed node. - -Ready to start using Ansible? -Complete the following steps to get up and running: - -#. Install Ansible. Visit the :ref:`installation guide` for complete details. - - .. code-block:: bash - - python3 -m pip install --user ansible - -#. Create an inventory by adding the IP address or fully qualified domain name (FQDN) of one or more remote systems to ``/etc/ansible/hosts``. - The following example adds the IP addresses of three virtual machines in KVM: - - .. code-block:: ini - - [myvirtualmachines] - 192.0.2.50 - 192.0.2.51 - 192.0.2.52 - -#. Verify the hosts in your inventory. - - .. code-block:: bash - - ansible all --list-hosts - - .. code-block:: ansible-output - - hosts (1): - 192.0.2.50 - 192.0.2.51 - 192.0.2.52 - -#. Set up SSH connections so Ansible can connect to the managed nodes. - - a. Add your public SSH key to the ``authorized_keys`` file on each remote system. - b. Test the SSH connections, for example: - - .. code-block:: bash - - ssh username@192.0.2.50 - - If the username on the control node is different on the host, you need to pass the ``-u`` option with the ``ansible`` command. - -#. Ping the managed nodes. - - .. code-block:: bash - - ansible all -m ping - - .. literalinclude:: ansible_output/ping_output.txt - :language: text - -Congratulations! You are now using Ansible. -Continue by :ref:`learning how to build an inventory`. - -.. seealso:: - - `Ansible Demos `_ - Demonstrations of different Ansible usecases - `Ansible Labs `_ - Labs to provide further knowledge on different topics - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels - -.. toctree:: - :maxdepth: 1 - - get_started_inventory - get_started_playbook - basic_concepts \ No newline at end of file diff --git a/docs/docsite/rst/getting_started/yaml/first_playbook.yaml b/docs/docsite/rst/getting_started/yaml/first_playbook.yaml deleted file mode 100644 index dd0ef63f0b3..00000000000 --- a/docs/docsite/rst/getting_started/yaml/first_playbook.yaml +++ /dev/null @@ -1,8 +0,0 @@ -- name: My first play - hosts: virtualmachines - tasks: - - name: Ping my hosts - ansible.builtin.ping: - - name: Print message - ansible.builtin.debug: - msg: Hello world diff --git a/docs/docsite/rst/getting_started/yaml/inventory_example_vms.yaml b/docs/docsite/rst/getting_started/yaml/inventory_example_vms.yaml deleted file mode 100644 index 636fa7f2376..00000000000 --- a/docs/docsite/rst/getting_started/yaml/inventory_example_vms.yaml +++ /dev/null @@ -1,8 +0,0 @@ -virtualmachines: - hosts: - vm01: - ansible_host: 192.0.2.50 - vm02: - ansible_host: 192.0.2.51 - vm03: - ansible_host: 192.0.2.52 diff --git a/docs/docsite/rst/getting_started/yaml/inventory_group_structure.yaml b/docs/docsite/rst/getting_started/yaml/inventory_group_structure.yaml deleted file mode 100644 index 940791111c7..00000000000 --- a/docs/docsite/rst/getting_started/yaml/inventory_group_structure.yaml +++ /dev/null @@ -1,30 +0,0 @@ -leafs: - hosts: - leaf01: - ansible_host: 192.0.2.100 - leaf02: - ansible_host: 192.0.2.110 - -spines: - hosts: - spine01: - ansible_host: 192.0.2.120 - spine02: - ansible_host: 192.0.2.130 - -network: - children: - leafs: - spines: - -webservers: - hosts: - webserver01: - ansible_host: 192.0.2.140 - webserver02: - ansible_host: 192.0.2.150 - -datacenter: - children: - network: - webservers: diff --git a/docs/docsite/rst/getting_started/yaml/inventory_variables_group.yaml b/docs/docsite/rst/getting_started/yaml/inventory_variables_group.yaml deleted file mode 100644 index 4e92cbe34bf..00000000000 --- a/docs/docsite/rst/getting_started/yaml/inventory_variables_group.yaml +++ /dev/null @@ -1,10 +0,0 @@ -webservers: - hosts: - webserver01: - ansible_host: 192.0.2.140 - http_port: 80 - webserver02: - ansible_host: 192.0.2.150 - http_port: 443 - vars: - ansible_user: my_server_user diff --git a/docs/docsite/rst/getting_started/yaml/inventory_variables_host.yaml b/docs/docsite/rst/getting_started/yaml/inventory_variables_host.yaml deleted file mode 100644 index 7e376b903c9..00000000000 --- a/docs/docsite/rst/getting_started/yaml/inventory_variables_host.yaml +++ /dev/null @@ -1,8 +0,0 @@ -webservers: - hosts: - webserver01: - ansible_host: 192.0.2.140 - http_port: 80 - webserver02: - ansible_host: 192.0.2.150 - http_port: 443 diff --git a/docs/docsite/rst/images/ansible_basic.svg b/docs/docsite/rst/images/ansible_basic.svg deleted file mode 100644 index 6217c89ff39..00000000000 --- a/docs/docsite/rst/images/ansible_basic.svg +++ /dev/null @@ -1,333 +0,0 @@ - - - - diff --git a/docs/docsite/rst/images/cow.png b/docs/docsite/rst/images/cow.png deleted file mode 100644 index 9ace4401908..00000000000 Binary files a/docs/docsite/rst/images/cow.png and /dev/null differ diff --git a/docs/docsite/rst/installation_guide/index.rst b/docs/docsite/rst/installation_guide/index.rst deleted file mode 100644 index 332560e885a..00000000000 --- a/docs/docsite/rst/installation_guide/index.rst +++ /dev/null @@ -1,14 +0,0 @@ -****************** -Installation Guide -****************** - -Welcome to the Ansible Installation Guide! - - -.. toctree:: - :maxdepth: 2 - - intro_installation - installation_distros - intro_configuration - diff --git a/docs/docsite/rst/installation_guide/installation_distros.rst b/docs/docsite/rst/installation_guide/installation_distros.rst deleted file mode 100644 index 69f1ff490a1..00000000000 --- a/docs/docsite/rst/installation_guide/installation_distros.rst +++ /dev/null @@ -1,149 +0,0 @@ -.. _installing_distros: - -Installing Ansible on specific operating systems -================================================ - -.. note:: These instructions are provided by their respective communities. Any bugs/issues should be filed with that community to update these instructions. Ansible maintains only the ``pip install`` instructions. - -The ``ansible`` package can always be :ref:`installed from PyPI using pip ` on most systems but it is also packaged and maintained by the community for a variety of Linux distributions. - -The following instructions will guide you through installing the ``ansible`` package with your preferred distribution's package manager. - -.. note:: For maintainers who wish to add distributions to this guide, installation instructions are included here only for distributions with a reasonably up-to-date version of ``ansible``. The distribution MUST ensure that ``ansible-core`` and ``ansible`` versions are kept in sync to the extent that the distribution build system allows. Maintainers MUST include a way to contact them with their instructions here and are encouraged to join the `Ansible Packaging `_ Matrix room. - -.. contents:: - :local: - -Installing Ansible on Fedora Linux -------------------------------------------------- - -To install the batteries included ``ansible`` package on Fedora run - -.. code-block:: bash - - $ sudo dnf install ansible - -If you prefer to install the minimal ``ansible-core`` package run - -.. code-block:: bash - - $ sudo dnf install ansible-core - -Several Ansible collections are also available from the Fedora repositories as -standalone packages that users can install alongside ``ansible-core``. -For example, to install the ``community.general`` collection run - -.. code-block:: bash - - $ sudo dnf install ansible-collection-community-general - -See the `Fedora Packages index `_ -for a full list of Ansible collections packaged in Fedora. - - -Please `file a bug `_ against the -``Fedora`` product in Red Hat Bugzilla to reach the package maintainers. - -Installing Ansible from EPEL ----------------------------------- - -Users of CentOS Stream, Almalinux, Rocky Linux, and related distributions -can install ``ansible`` or Ansible collections from the community maintained -`EPEL `_ -(Extra Packages for Enterprise Linux) repository. - -After `enabling the EPEL repository `_, -users can use the same ``dnf`` commands as for Fedora Linux. - -Please `file a bug `_ against the -``Fedora EPEL`` product in Red Hat Bugzilla to reach the package maintainers. - - -Installing Ansible on OpenSUSE Tumbleweed/Leap ----------------------------------------------- - -.. code-block:: bash - - $ sudo zypper install ansible - -See `OpenSUSE Support Portal ` for additional help with Ansible on OpenSUSE. - -.. _from_apt: - -Installing Ansible on Ubuntu ----------------------------- - -Ubuntu builds are available `in a PPA here `_. - -To configure the PPA on your system and install Ansible run these commands: - -.. code-block:: bash - - $ sudo apt update - $ sudo apt install software-properties-common - $ sudo add-apt-repository --yes --update ppa:ansible/ansible - $ sudo apt install ansible - -.. note:: On older Ubuntu distributions, "software-properties-common" is called "python-software-properties". You may want to use ``apt-get`` rather than ``apt`` in older versions. Also, be aware that only newer distributions (that is, 18.04, 18.10, and later) have a ``-u`` or ``--update`` flag. Adjust your script as needed. - - - - -Installing Ansible on Debian ----------------------------- - -Debian users can use the same source as the Ubuntu PPA (using the following table). - -.. list-table:: - :header-rows: 1 - - * - Debian - - - - Ubuntu - * - Debian 11 (Bullseye) - - -> - - Ubuntu 20.04 (Focal) - * - Debian 10 (Buster) - - -> - - Ubuntu 18.04 (Bionic) - - -.. note:: - - Ansible releases are only built for Ubuntu 18.04 (Bionic) or later releases. - -Add the following line to ``/etc/apt/sources.list`` or ``/etc/apt/sources.list.d/ansible.list``: - -.. code-block:: bash - - deb http://ppa.launchpad.net/ansible/ansible/ubuntu MATCHING_UBUNTU_CODENAME_HERE main - -Example for Debian 11 (Bullseye) - -.. code-block:: bash - - deb http://ppa.launchpad.net/ansible/ansible/ubuntu focal main - -Then run these commands: - -.. code-block:: bash - - $ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367 - $ sudo apt update - $ sudo apt install ansible - - - -.. _from_windows: - -Installing Ansible on Windows ------------------------------- - -You cannot use a Windows system for the Ansible control node. See :ref:`windows_faq_ansible` - -.. seealso:: - - `Installing Ansible on Arch Linux `_ - Distro-specific installation on Arch Linux - `Installing Ansible on Clear Linux `_ - Distro-specific installation on Clear Linux diff --git a/docs/docsite/rst/installation_guide/intro_configuration.rst b/docs/docsite/rst/installation_guide/intro_configuration.rst deleted file mode 100644 index 863d315154f..00000000000 --- a/docs/docsite/rst/installation_guide/intro_configuration.rst +++ /dev/null @@ -1,59 +0,0 @@ -.. _intro_configuration: - -******************* -Configuring Ansible -******************* - -.. contents:: Topics - - -This topic describes how to control Ansible settings. - - -.. _the_configuration_file: - -Configuration file -================== - -Certain settings in Ansible are adjustable via a configuration file (ansible.cfg). -The stock configuration should be sufficient for most users, but there may be reasons you would want to change them. -Paths where configuration file is searched are listed in :ref:`reference documentation`. - -.. _getting_the_latest_configuration: - -Getting the latest configuration --------------------------------- - -If installing Ansible from a package manager, the latest ``ansible.cfg`` file should be present in ``/etc/ansible``, possibly -as a ``.rpmnew`` file (or other) as appropriate in the case of updates. - -If you installed Ansible from pip or from source, you may want to create this file in order to override -default settings in Ansible. - -An `example file is available on GitHub `_. - -For more details and a full listing of available configurations go to :ref:`configuration_settings`. Starting with Ansible version 2.4, you can use the :ref:`ansible-config` command line utility to list your available options and inspect the current values. - -For in-depth details, see :ref:`ansible_configuration_settings`. - -.. _environmental_configuration: - -Environmental configuration -=========================== - -Ansible also allows configuration of settings using environment variables. -If these environment variables are set, they will override any setting loaded from the configuration file. - -You can get a full listing of available environment variables for configuring core functionality from :ref:`ansible_configuration_settings`, and for configuring plugins in collections from :ref:`list_of_collection_env_vars`. - - -.. _command_line_configuration: - -Command line options -==================== - -Not all configuration options are present in the command line, just the ones deemed most useful or common. -Settings in the command line will override those passed through the configuration file and the environment. - -The full list of options available is in :ref:`ansible-playbook` and :ref:`ansible`. - diff --git a/docs/docsite/rst/installation_guide/intro_installation.rst b/docs/docsite/rst/installation_guide/intro_installation.rst deleted file mode 100644 index bb5c68719c1..00000000000 --- a/docs/docsite/rst/installation_guide/intro_installation.rst +++ /dev/null @@ -1,330 +0,0 @@ -.. _installation_guide: -.. _intro_installation_guide: - -****************** -Installing Ansible -****************** - -Ansible is an agentless automation tool that you install on a single host (referred to as the control node). From the control node, Ansible can manage an entire fleet of machines and other devices (referred to as managed nodes) remotely with SSH, Powershell remoting, and numerous other transports, all from a simple command-line interface with no databases or daemons required. - -.. contents:: - :local: - -.. _control_node_requirements: - -Control node requirements -========================= - -For your *control* node (the machine that runs Ansible), you can use nearly any UNIX-like machine with Python 3.9 or newer installed. This includes Red Hat, Debian, Ubuntu, macOS, BSDs, and Windows under a `Windows Subsystem for Linux (WSL) distribution `_. Windows without WSL is not natively supported as a control node; see `Matt Davis' blog post `_ for more information. - -.. _managed_node_requirements: - -Managed node requirements -========================= - -The *managed* node (the machine that Ansible is managing) does not require Ansible to be installed, but requires Python 2.7, or Python 3.5 - 3.11 to run Ansible library code. -The managed node also needs a user account that can SSH to the node with an interactive POSIX shell. - -.. note:: - - Network modules are an exception and do not require Python on the managed device. See :ref:`network_modules`. - -.. _node_requirements_summary: - -Node requirement summary -======================== - -You can find details about control and managed node requirements for each Ansible version in the :ref:`support_life`. - -.. _getting_ansible: - -.. _what_version: - -Selecting an Ansible package and version to install -==================================================== - -Ansible's community packages are distributed in two ways: a minimalist language and runtime package called ``ansible-core``, and a much larger "batteries included" package called ``ansible``, which adds a community-curated selection of :ref:`Ansible Collections ` for automating a wide variety of devices. Choose the package that fits your needs; The following instructions use ``ansible``, but you can substitute ``ansible-core`` if you prefer to start with a more minimal package and separately install only the Ansible Collections you require. The ``ansible`` or ``ansible-core`` packages may be available in your operating systems package manager, and you are free to install these packages with your preferred method. These installation instructions only cover the officially supported means of installing the python package with ``pip``. - -See the :ref:`Ansible package release status table` for the ``ansible-core`` version included in the package. - -Installing and upgrading Ansible with pipx -========================================== - -On some systems, it may not be possible to install Ansible with ``pip``, due to decisions made by the operating system. In such cases, ``pipx`` is a widely available alternative. - -These instructions will not go over the steps to install ``pipx``; If those instructions are needed please continue to the `pipx installation instructions`_ for more information. - -.. _pipx installation instructions: https://pypa.github.io/pipx/installation/ - -.. _pipx_install: - -Installing Ansible ------------------- - -Use ``pipx`` in your environment to install the Ansible package of your choice for the current user: - -.. code-block:: console - - $ pipx install ansible - -Alternately, you can install a specific version of ``ansible-core``: - -.. code-block:: console - - $ pipx install ansible-core==2.12.3 - -.. _pipx_upgrade: - -Upgrading Ansible ------------------ - -To upgrade an existing Ansible installation to the latest released version: - -.. code-block:: console - - $ pipx upgrade ansible - -.. _pipx_inject: - -Installing Extra Python Dependencies ------------------------------------- - -To install additional python dependencies that may be needed, with the example of installing the ``argcomplete`` python package as described below: - -.. code-block:: console - - $ pipx inject ansible argcomplete - -Installing and upgrading Ansible with pip -========================================= - -Locating Python ---------------- - -Locate and remember the path to the Python interpreter you wish to use to run Ansible. The following instructions refer to this Python as ``python3``. For example, if you've determined that you want the Python at ``/usr/bin/python3.9`` to be the one that you'll install Ansible under, specify that instead of ``python3``. - -Ensuring ``pip`` is available ------------------------------ - -To verify whether ``pip`` is already installed for your preferred Python: - -.. code-block:: console - - $ python3 -m pip -V - -If all is well, you should see something like the following: - -.. code-block:: console - - $ python3 -m pip -V - pip 21.0.1 from /usr/lib/python3.9/site-packages/pip (python 3.9) - -If so, ``pip`` is available, and you can move on to the :ref:`next step `. - -If you see an error like ``No module named pip``, you'll need to install ``pip`` under your chosen Python interpreter before proceeding. This may mean installing an additional OS package (for example, ``python3-pip``), or installing the latest ``pip`` directly from the Python Packaging Authority by running the following: - -.. code-block:: console - - $ curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py - $ python3 get-pip.py --user - -You may need to perform some additional configuration before you are able to run Ansible. See the Python documentation on `installing to the user site`_ for more information. - -.. _installing to the user site: https://packaging.python.org/tutorials/installing-packages/#installing-to-the-user-site - -.. _pip_install: - -Installing Ansible ------------------- - -Use ``pip`` in your selected Python environment to install the Ansible package of your choice for the current user: - -.. code-block:: console - - $ python3 -m pip install --user ansible - -Alternately, you can install a specific version of ``ansible-core`` in this Python environment: - -.. code-block:: console - - $ python3 -m pip install --user ansible-core==2.12.3 - -.. _pip_upgrade: - -Upgrading Ansible ------------------ - -To upgrade an existing Ansible installation in this Python environment to the latest released version, simply add ``--upgrade`` to the command above: - -.. code-block:: console - - $ python3 -m pip install --upgrade --user ansible - -.. _development_install: - -Installing for development -========================== - -If you are testing new features, fixing bugs, or otherwise working with the development team on changes to the core code, you can install and run the source from GitHub. - -.. note:: - - You should only install and run the ``devel`` branch if you are modifying ``ansible-core`` or trying out features under development. This is a rapidly changing source of code and can become unstable at any point. - -For more information on getting involved in the Ansible project, see the :ref:`ansible_community_guide`. For more information on creating Ansible modules and Collections, see the :ref:`developer_guide`. - -.. _from_pip_devel: - -Installing ``devel`` from GitHub with ``pip`` ---------------------------------------------- - -You can install the ``devel`` branch of ``ansible-core`` directly from GitHub with ``pip``: - -.. code-block:: console - - $ python3 -m pip install --user https://github.com/ansible/ansible/archive/devel.tar.gz - -You can replace ``devel`` in the URL mentioned above, with any other branch or tag on GitHub to install older versions of Ansible, tagged alpha or beta versions, and release candidates. - -.. _from_source: - -Running the ``devel`` branch from a clone ------------------------------------------ - -``ansible-core`` is easy to run from source. You do not need ``root`` permissions to use it and there is no software to actually install. No daemons or database setup are required. - -#. Clone the ``ansible-core`` repository - - .. code-block:: console - - $ git clone https://github.com/ansible/ansible.git - $ cd ./ansible - -#. Setup the Ansible environment - - * Using Bash - - .. code-block:: console - - $ source ./hacking/env-setup - - * Using Fish - - .. code-block:: console - - $ source ./hacking/env-setup.fish - - * To suppress spurious warnings/errors, use ``-q`` - - .. code-block:: console - - $ source ./hacking/env-setup -q - -#. Install Python dependencies - - .. code-block:: console - - $ python3 -m pip install --user -r ./requirements.txt - -#. Update the ``devel`` branch of ``ansible-core`` on your local machine - - Use pull-with-rebase so any local changes are replayed. - - .. code-block:: console - - $ git pull --rebase - -.. _shell_completion: - -Confirming your installation -============================ - -You can test that Ansible is installed correctly by checking the version: - -.. code-block:: console - - $ ansible --version - -The version displayed by this command is for the associated ``ansible-core`` package that has been installed. - -To check the version of the ``ansible`` package that has been installed: - -.. code-block:: console - - $ ansible-community --version - -Adding Ansible command shell completion -======================================= - -You can add shell completion of the Ansible command line utilities by installing an optional dependency called ``argcomplete``. ``argcomplete`` supports bash, and has limited support for zsh and tcsh. - -For more information about installation and configuration, see the `argcomplete documentation `_. - -Installing ``argcomplete`` --------------------------- - -If you chose the ``pipx`` install instructions: - -.. code-block:: console - - $ pipx inject ansible argcomplete - -Or, if you chose the ``pip`` install instructions: - -.. code-block:: console - - $ python3 -m pip install --user argcomplete - -Configuring ``argcomplete`` ---------------------------- - -There are 2 ways to configure ``argcomplete`` to allow shell completion of the Ansible command line utilities: globally or per command. - -Global configuration -^^^^^^^^^^^^^^^^^^^^ - -Global completion requires bash 4.2. - -.. code-block:: console - - $ activate-global-python-argcomplete --user - -This will write a bash completion file to a user location. Use ``--dest`` to change the location or ``sudo`` to set up the completion globally. - -Per command configuration -^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you do not have bash 4.2, you must register each script independently. - -.. code-block:: console - - $ eval $(register-python-argcomplete ansible) - $ eval $(register-python-argcomplete ansible-config) - $ eval $(register-python-argcomplete ansible-console) - $ eval $(register-python-argcomplete ansible-doc) - $ eval $(register-python-argcomplete ansible-galaxy) - $ eval $(register-python-argcomplete ansible-inventory) - $ eval $(register-python-argcomplete ansible-playbook) - $ eval $(register-python-argcomplete ansible-pull) - $ eval $(register-python-argcomplete ansible-vault) - -You should place the above commands into your shells profile file such as ``~/.profile`` or ``~/.bash_profile``. - -Using ``argcomplete`` with zsh or tcsh -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -See the `argcomplete documentation `_. - - -.. seealso:: - - :ref:`intro_adhoc` - Examples of basic commands - :ref:`working_with_playbooks` - Learning ansible's configuration management language - :ref:`installation_faqs` - Ansible Installation related to FAQs - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/inventory/implicit_localhost.rst b/docs/docsite/rst/inventory/implicit_localhost.rst deleted file mode 100644 index ced98df8e1d..00000000000 --- a/docs/docsite/rst/inventory/implicit_localhost.rst +++ /dev/null @@ -1,40 +0,0 @@ -:orphan: - -.. _implicit_localhost: - -Implicit 'localhost' -==================== - -When you try to reference a ``localhost`` and you don't have it defined in inventory, Ansible will create an implicit one for you.: - -.. code-block:: yaml - - - hosts: all - tasks: - - name: check that i have log file for all hosts on my local machine - stat: path=/var/log/hosts/{{inventory_hostname}}.log - delegate_to: localhost - -In a case like this (or ``local_action``) when Ansible needs to contact a 'localhost' but you did not supply one, we create one for you. This host is defined with specific connection variables equivalent to this in an inventory: - -.. code-block:: yaml - - ... - - hosts: - localhost: - vars: - ansible_connection: local - ansible_python_interpreter: "{{ansible_playbook_python}}" - -This ensures that the proper connection and Python are used to execute your tasks locally. -You can override the built-in implicit version by creating a ``localhost`` host entry in your inventory. At that point, all implicit behaviors are ignored; the ``localhost`` in inventory is treated just like any other host. Group and host vars will apply, including connection vars, which includes the ``ansible_python_interpreter`` setting. This will also affect ``delegate_to: localhost`` and ``local_action``, the latter being an alias to the former. - -.. note:: - - - This host is not targetable via any group, however it will use vars from ``host_vars`` and from the 'all' group. - - Implicit localhost does not appear in the ``hostvars`` magic variable unless demanded, such as by ``"{{ hostvars['localhost'] }}"``. - - The ``inventory_file`` and ``inventory_dir`` magic variables are not available for the implicit localhost as they are dependent on **each inventory host**. - - This implicit host also gets triggered by using ``127.0.0.1`` or ``::1`` as they are the IPv4 and IPv6 representations of 'localhost'. - - Even though there are many ways to create it, there will only ever be ONE implicit localhost, using the name first used to create it. - - Having ``connection: local`` does NOT trigger an implicit localhost, you are just changing the connection for the ``inventory_hostname``. diff --git a/docs/docsite/rst/inventory_guide/connection_details.rst b/docs/docsite/rst/inventory_guide/connection_details.rst deleted file mode 100644 index 5e332160617..00000000000 --- a/docs/docsite/rst/inventory_guide/connection_details.rst +++ /dev/null @@ -1,123 +0,0 @@ -.. _connections: - -****************************** -Connection methods and details -****************************** - -This section shows you how to expand and refine the connection methods Ansible uses for your inventory. - -ControlPersist and paramiko ---------------------------- - -By default, Ansible uses native OpenSSH, because it supports ControlPersist (a performance feature), Kerberos, and options in ``~/.ssh/config`` such as Jump Host setup. If your control machine uses an older version of OpenSSH that does not support ControlPersist, Ansible will fallback to a Python implementation of OpenSSH called 'paramiko'. - -.. _connection_set_user: - -Setting a remote user ---------------------- - -By default, Ansible connects to all remote devices with the user name you are using on the control node. If that user name does not exist on a remote device, you can set a different user name for the connection. If you just need to do some tasks as a different user, look at :ref:`become`. You can set the connection user in a playbook: - -.. code-block:: yaml - - --- - - name: update webservers - hosts: webservers - remote_user: admin - - tasks: - - name: thing to do first in this playbook - . . . - -as a host variable in inventory: - -.. code-block:: text - - other1.example.com ansible_connection=ssh ansible_user=myuser - other2.example.com ansible_connection=ssh ansible_user=myotheruser - -or as a group variable in inventory: - -.. code-block:: yaml - - cloud: - hosts: - cloud1: my_backup.cloud.com - cloud2: my_backup2.cloud.com - vars: - ansible_user: admin - -.. seealso:: - - :ref:`ssh_connection` - Details on the ``remote_user`` keyword and ``ansible_user`` variable. - :ref:`general_precedence_rules` - Details on Ansible precedence rules. - -Setting up SSH keys -------------------- - -By default, Ansible assumes you are using SSH keys to connect to remote machines. SSH keys are encouraged, but you can use password authentication if needed with the ``--ask-pass`` option. If you need to provide a password for :ref:`privilege escalation ` (sudo, pbrun, and so on), use ``--ask-become-pass``. - -.. include:: shared_snippets/SSH_password_prompt.txt - -To set up SSH agent to avoid retyping passwords, you can do: - -.. code-block:: bash - - $ ssh-agent bash - $ ssh-add ~/.ssh/id_rsa - -Depending on your setup, you may wish to use Ansible's ``--private-key`` command line option to specify a pem file instead. You can also add the private key file: - -.. code-block:: bash - - $ ssh-agent bash - $ ssh-add ~/.ssh/keypair.pem - -Another way to add private key files without using ssh-agent is using ``ansible_ssh_private_key_file`` in an inventory file as explained here: :ref:`intro_inventory`. - -Running against localhost -------------------------- - -You can run commands against the control node by using "localhost" or "127.0.0.1" for the server name: - -.. code-block:: bash - - $ ansible localhost -m ping -e 'ansible_python_interpreter="/usr/bin/env python"' - -You can specify localhost explicitly by adding this to your inventory file: - -.. code-block:: bash - - localhost ansible_connection=local ansible_python_interpreter="/usr/bin/env python" - -.. _host_key_checking_on: - -Managing host key checking --------------------------- - -Ansible enables host key checking by default. Checking host keys guards against server spoofing and man-in-the-middle attacks, but it does require some maintenance. - -If a host is reinstalled and has a different key in 'known_hosts', this will result in an error message until corrected. If a new host is not in 'known_hosts' your control node may prompt for confirmation of the key, which results in an interactive experience if using Ansible, from say, cron. You might not want this. - -If you understand the implications and wish to disable this behavior, you can do so by editing ``/etc/ansible/ansible.cfg`` or ``~/.ansible.cfg``: - -.. code-block:: text - - [defaults] - host_key_checking = False - -Alternatively this can be set by the :envvar:`ANSIBLE_HOST_KEY_CHECKING` environment variable: - -.. code-block:: bash - - $ export ANSIBLE_HOST_KEY_CHECKING=False - -Also note that host key checking in paramiko mode is reasonably slow, therefore switching to 'ssh' is also recommended when using this feature. - -Other connection methods ------------------------- - -Ansible can use a variety of connection methods beyond SSH. You can select any connection plugin, including managing things locally and managing chroot, lxc, and jail containers. -A mode called 'ansible-pull' can also invert the system and have systems 'phone home' via scheduled git checkouts to pull configuration directives from a central repository. diff --git a/docs/docsite/rst/inventory_guide/index.rst b/docs/docsite/rst/inventory_guide/index.rst deleted file mode 100644 index 7b984eb1d74..00000000000 --- a/docs/docsite/rst/inventory_guide/index.rst +++ /dev/null @@ -1,28 +0,0 @@ -.. _inventory_guide_index: - -############################ -Building Ansible inventories -############################ - -.. 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 `_. - -Welcome to the guide to building Ansible inventories. -An inventory is a list of managed nodes, or hosts, that Ansible deploys and configures. -This guide introduces you to inventories and covers the following topics: - -* Creating inventories to track list of servers and devices that you want to automate. -* Using dynamic inventories to track cloud services with servers and devices that are constantly starting and stopping. -* Using patterns to automate specific sub-sets of an inventory. -* Expanding and refining the connection methods Ansible uses for your inventory. - -.. toctree:: - :maxdepth: 2 - - intro_inventory - intro_dynamic_inventory - intro_patterns - connection_details \ No newline at end of file diff --git a/docs/docsite/rst/inventory_guide/intro_dynamic_inventory.rst b/docs/docsite/rst/inventory_guide/intro_dynamic_inventory.rst deleted file mode 100644 index e0d9c204f75..00000000000 --- a/docs/docsite/rst/inventory_guide/intro_dynamic_inventory.rst +++ /dev/null @@ -1,260 +0,0 @@ -.. _intro_dynamic_inventory: -.. _dynamic_inventory: - -****************************** -Working with dynamic inventory -****************************** - -.. contents:: - :local: - -If your Ansible inventory fluctuates over time, with hosts spinning up and shutting down in response to business demands, the static inventory solutions described in :ref:`inventory` will not serve your needs. -You may need to track hosts from multiple sources: cloud providers, LDAP, `Cobbler `_, and/or enterprise CMDB systems. - -Ansible integrates all of these options through a dynamic external inventory system. -Ansible supports two ways to connect with external inventory: :ref:`inventory_plugins` and `inventory scripts`. - -Inventory plugins take advantage of the most recent updates to the Ansible core code. -We recommend plugins over scripts for dynamic inventory. -You can :ref:`write your own plugin ` to connect to additional dynamic inventory sources. - -You can still use inventory scripts if you choose. -When we implemented inventory plugins, we ensured backwards compatibility through the script inventory plugin. -The examples below illustrate how to use inventory scripts. - -If you prefer a GUI for handling dynamic inventory, the inventory database on AWX or :ref:`ansible_platform` syncs with all your dynamic inventory sources, provides web and REST access to the results, and offers a graphical inventory editor. -With a database record of all of your hosts, you can correlate past event history and see which hosts have had failures on their last playbook runs. - -.. _cobbler_example: - -Inventory script example: Cobbler -================================= - -Ansible integrates seamlessly with `Cobbler `_, a Linux installation server originally written by Michael DeHaan and now led by James Cammarata, who works for Ansible. - -While primarily used to kickoff OS installations and manage DHCP and DNS, Cobbler has a generic -layer that can represent data for multiple configuration management systems (even at the same time) and serve as a 'lightweight CMDB'. - -To tie your Ansible inventory to Cobbler, copy `this script `_ to ``/etc/ansible`` and ``chmod +x`` the file. Run ``cobblerd`` any time you use Ansible and use the ``-i`` command line option (for example, ``-i /etc/ansible/cobbler.py``) to communicate with Cobbler using Cobbler's XMLRPC API. - -Add a ``cobbler.ini`` file in ``/etc/ansible`` so Ansible knows where the Cobbler server is and some cache improvements can be used. For example: - -.. code-block:: text - - [cobbler] - - # Set Cobbler's hostname or IP address - host = http://127.0.0.1/cobbler_api - - # API calls to Cobbler can be slow. For this reason, we cache the results of an API - # call. Set this to the path you want cache files to be written to. Two files - # will be written to this directory: - # - ansible-cobbler.cache - # - ansible-cobbler.index - - cache_path = /tmp - - # The number of seconds a cache file is considered valid. After this many - # seconds, a new API call will be made, and the cache file will be updated. - - cache_max_age = 900 - - -First test the script by running ``/etc/ansible/cobbler.py`` directly. You should see some JSON data output, but it may not have anything in it just yet. - -Let's explore what this does. In Cobbler, assume a scenario somewhat like the following: - -.. code-block:: bash - - cobbler profile add --name=webserver --distro=CentOS6-x86_64 - cobbler profile edit --name=webserver --mgmt-classes="webserver" --ksmeta="a=2 b=3" - cobbler system edit --name=foo --dns-name="foo.example.com" --mgmt-classes="atlanta" --ksmeta="c=4" - cobbler system edit --name=bar --dns-name="bar.example.com" --mgmt-classes="atlanta" --ksmeta="c=5" - -In the example above, the system 'foo.example.com' is addressable by ansible directly, but is also addressable when using the group names 'webserver' or 'atlanta'. Since Ansible uses SSH, it contacts system foo over 'foo.example.com', only, never just 'foo'. Similarly, if you tried "ansible foo", it would not find the system... but "ansible 'foo*'" would do, because the system DNS name starts with 'foo'. - -The script provides more than host and group info. In addition, as a bonus, when the 'setup' module is run (which happens automatically when using playbooks), the variables 'a', 'b', and 'c' will all be auto-populated in the templates: - -.. code-block:: text - - # file: /srv/motd.j2 - Welcome, I am templated with a value of a={{ a }}, b={{ b }}, and c={{ c }} - -Which could be executed just like this: - -.. code-block:: bash - - ansible webserver -m setup - ansible webserver -m template -a "src=/tmp/motd.j2 dest=/etc/motd" - -.. note:: - The name 'webserver' came from Cobbler, as did the variables for - the config file. You can still pass in your own variables like - normal in Ansible, but variables from the external inventory script - will override any that have the same name. - -So, with the template above (``motd.j2``), this results in the following data being written to ``/etc/motd`` for system 'foo': - -.. code-block:: text - - Welcome, I am templated with a value of a=2, b=3, and c=4 - -And on system 'bar' (bar.example.com): - -.. code-block:: text - - Welcome, I am templated with a value of a=2, b=3, and c=5 - -And technically, though there is no major good reason to do it, this also works: - -.. code-block:: bash - - ansible webserver -m ansible.builtin.shell -a "echo {{ a }}" - -So, in other words, you can use those variables in arguments/actions as well. - -.. _openstack_example: - -Inventory script example: OpenStack -=================================== - -If you use an OpenStack-based cloud, instead of manually maintaining your own inventory file, you can use the ``openstack_inventory.py`` dynamic inventory to pull information about your compute instances directly from OpenStack. - -You can download the latest version of the OpenStack inventory script `here `_. - -You can use the inventory script explicitly (by passing the `-i openstack_inventory.py` argument to Ansible) or implicitly (by placing the script at `/etc/ansible/hosts`). - -Explicit use of OpenStack inventory script ------------------------------------------- - -Download the latest version of the OpenStack dynamic inventory script and make it executable. - -.. code-block:: bash - - wget https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack_inventory.py - chmod +x openstack_inventory.py - -.. note:: - Do not name it `openstack.py`. This name will conflict with imports from openstacksdk. - -Source an OpenStack RC file: - -.. code-block:: bash - - source openstack.rc - -.. note:: - - An OpenStack RC file contains the environment variables required by the client tools to establish a connection with the cloud provider, such as the authentication URL, user name, password and region name. For more information on how to download, create or source an OpenStack RC file, please refer to `Set environment variables using the OpenStack RC file `_. - -You can confirm the file has been successfully sourced by running a simple command, such as `nova list` and ensuring it returns no errors. - -.. note:: - - The OpenStack command line clients are required to run the `nova list` command. For more information on how to install them, please refer to `Install the OpenStack command-line clients `_. - -You can test the OpenStack dynamic inventory script manually to confirm it is working as expected: - -.. code-block:: bash - - ./openstack_inventory.py --list - -After a few moments you should see some JSON output with information about your compute instances. - -Once you confirm the dynamic inventory script is working as expected, you can tell Ansible to use the `openstack_inventory.py` script as an inventory file, as illustrated below: - -.. code-block:: bash - - ansible -i openstack_inventory.py all -m ansible.builtin.ping - -Implicit use of OpenStack inventory script ------------------------------------------- - -Download the latest version of the OpenStack dynamic inventory script, make it executable and copy it to `/etc/ansible/hosts`: - -.. code-block:: bash - - wget https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack_inventory.py - chmod +x openstack_inventory.py - sudo cp openstack_inventory.py /etc/ansible/hosts - -Download the sample configuration file, modify it to suit your needs and copy it to `/etc/ansible/openstack.yml`: - -.. code-block:: bash - - wget https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack.yml - vi openstack.yml - sudo cp openstack.yml /etc/ansible/ - -You can test the OpenStack dynamic inventory script manually to confirm it is working as expected: - -.. code-block:: bash - - /etc/ansible/hosts --list - -After a few moments you should see some JSON output with information about your compute instances. - -Refreshing the cache --------------------- - -Note that the OpenStack dynamic inventory script will cache results to avoid repeated API calls. To explicitly clear the cache, you can run the openstack_inventory.py (or hosts) script with the ``--refresh`` parameter: - -.. code-block:: bash - - ./openstack_inventory.py --refresh --list - -.. _other_inventory_scripts: - -Other inventory scripts -======================= - -In Ansible 2.10 and later, inventory scripts moved to their associated collections. Many are now in the `ansible-community/contrib-scripts repository `_. We recommend you use :ref:`inventory_plugins` instead. - -.. _using_multiple_sources: - -Using inventory directories and multiple inventory sources -========================================================== - -If the location given to ``-i`` in Ansible is a directory (or as so configured in ``ansible.cfg``), Ansible can use multiple inventory sources -at the same time. When doing so, it is possible to mix both dynamic and statically managed inventory sources in the same ansible run. Instant -hybrid cloud! - -In an inventory directory, executable files are treated as dynamic inventory sources and most other files as static sources. Files which end with any of the following are ignored: - -.. code-block:: text - - ~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo - -You can replace this list with your own selection by configuring an ``inventory_ignore_extensions`` list in ``ansible.cfg``, or setting the :envvar:`ANSIBLE_INVENTORY_IGNORE` environment variable. The value in either case must be a comma-separated list of patterns, as shown above. - -Any ``group_vars`` and ``host_vars`` subdirectories in an inventory directory are interpreted as expected, making inventory directories a powerful way to organize different sets of configurations. See :ref:`using_multiple_inventory_sources` for more information. - -.. _static_groups_of_dynamic: - -Static groups of dynamic groups -=============================== - -When defining groups of groups in the static inventory file, the child groups -must also be defined in the static inventory file, otherwise ansible returns an -error. If you want to define a static group of dynamic child groups, define -the dynamic groups as empty in the static inventory file. For example: - -.. code-block:: text - - [tag_Name_staging_foo] - - [tag_Name_staging_bar] - - [staging:children] - tag_Name_staging_foo - tag_Name_staging_bar - - -.. seealso:: - - :ref:`intro_inventory` - All about static inventory files - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/inventory_guide/intro_inventory.rst b/docs/docsite/rst/inventory_guide/intro_inventory.rst deleted file mode 100644 index 3fd6782dbde..00000000000 --- a/docs/docsite/rst/inventory_guide/intro_inventory.rst +++ /dev/null @@ -1,841 +0,0 @@ -.. _intro_inventory: -.. _inventory: - -*************************** -How to build your inventory -*************************** - -Ansible automates tasks on managed nodes or "hosts" in your infrastructure, using a list or group of lists known as inventory. You can pass host names at the command line, but most Ansible users create inventory files. Your inventory defines the managed nodes you automate, with groups so you can run automation tasks on multiple hosts at the same time. -Once your inventory is defined, you use :ref:`patterns ` to select the hosts or groups you want Ansible to run against. - -The simplest inventory is a single file with a list of hosts and groups. The default location for this file is ``/etc/ansible/hosts``. -You can specify a different inventory file at the command line using the ``-i `` option or in configuration using ``inventory``. - -Ansible :ref:`inventory_plugins` support a range of formats and sources to make your inventory flexible and customizable. As your inventory expands, you may need more than a single file to organize your hosts and groups. Here are three options beyond the ``/etc/ansible/hosts`` file: -- You can create a directory with multiple inventory files. See :ref:`inventory_directory`. These can use different formats (YAML, ini, and so on). -- You can pull inventory dynamically. For example, you can use a dynamic inventory plugin to list resources in one or more cloud providers. See :ref:`intro_dynamic_inventory`. -- You can use multiple sources for inventory, including both dynamic inventory and static files. See :ref:`using_multiple_inventory_sources`. - -.. contents:: - :local: - -.. _inventoryformat: - -Inventory basics: formats, hosts, and groups -============================================ - -You can create your inventory file in one of many formats, depending on the inventory plugins you have. -The most common formats are INI and YAML. A basic INI ``/etc/ansible/hosts`` might look like this: - -.. code-block:: text - - mail.example.com - - [webservers] - foo.example.com - bar.example.com - - [dbservers] - one.example.com - two.example.com - three.example.com - -The headings in brackets are group names, which are used in classifying hosts -and deciding what hosts you are controlling at what times and for what purpose. -Group names should follow the same guidelines as :ref:`valid_variable_names`. - -Here's that same basic inventory file in YAML format: - -.. code-block:: yaml - - all: - hosts: - mail.example.com: - children: - webservers: - hosts: - foo.example.com: - bar.example.com: - dbservers: - hosts: - one.example.com: - two.example.com: - three.example.com: - -.. _default_groups: - -Default groups --------------- - -Even if you do not define any groups in your inventory file, Ansible creates two default groups: ``all`` and ``ungrouped``. The ``all`` group contains every host. -The ``ungrouped`` group contains all hosts that don't have another group aside from ``all``. -Every host will always belong to at least 2 groups (``all`` and ``ungrouped`` or ``all`` and some other group). For example, in the basic inventory above, the host ``mail.example.com`` belongs to the ``all`` group and the ``ungrouped`` group; the host ``two.example.com`` belongs to the ``all`` group and the ``dbservers`` group. Though ``all`` and ``ungrouped`` are always present, they can be implicit and not appear in group listings like ``group_names``. - -.. _host_multiple_groups: - -Hosts in multiple groups ------------------------- - -You can (and probably will) put each host in more than one group. For example a production webserver in a datacenter in Atlanta might be included in groups called ``[prod]`` and ``[atlanta]`` and ``[webservers]``. You can create groups that track: - -* What - An application, stack or microservice (for example, database servers, web servers, and so on). -* Where - A datacenter or region, to talk to local DNS, storage, and so on (for example, east, west). -* When - The development stage, to avoid testing on production resources (for example, prod, test). - -Extending the previous YAML inventory to include what, when, and where would look like this: - -.. code-block:: yaml - - all: - hosts: - mail.example.com: - children: - webservers: - hosts: - foo.example.com: - bar.example.com: - dbservers: - hosts: - one.example.com: - two.example.com: - three.example.com: - east: - hosts: - foo.example.com: - one.example.com: - two.example.com: - west: - hosts: - bar.example.com: - three.example.com: - prod: - hosts: - foo.example.com: - one.example.com: - two.example.com: - test: - hosts: - bar.example.com: - three.example.com: - -You can see that ``one.example.com`` exists in the ``dbservers``, ``east``, and ``prod`` groups. - -.. _child_groups: - -Grouping groups: parent/child group relationships -------------------------------------------------- - -You can create parent/child relationships among groups. Parent groups are also known as nested groups or groups of groups. For example, if all your production hosts are already in groups such as ``atlanta_prod`` and ``denver_prod``, you can create a ``production`` group that includes those smaller groups. This approach reduces maintenance because you can add or remove hosts from the parent group by editing the child groups. - -To create parent/child relationships for groups: - -* in INI format, use the ``:children`` suffix -* in YAML format, use the ``children:`` entry - -Here is the same inventory as shown above, simplified with parent groups for the ``prod`` and ``test`` groups. The two inventory files give you the same results: - -.. code-block:: yaml - - all: - hosts: - mail.example.com: - children: - webservers: - hosts: - foo.example.com: - bar.example.com: - dbservers: - hosts: - one.example.com: - two.example.com: - three.example.com: - east: - hosts: - foo.example.com: - one.example.com: - two.example.com: - west: - hosts: - bar.example.com: - three.example.com: - prod: - children: - east: - test: - children: - west: - -Child groups have a couple of properties to note: - -* Any host that is member of a child group is automatically a member of the parent group. -* Groups can have multiple parents and children, but not circular relationships. -* Hosts can also be in multiple groups, but there will only be **one** instance of a host at runtime. Ansible merges the data from the multiple groups. - -Adding ranges of hosts ----------------------- - -If you have a lot of hosts with a similar pattern, you can add them as a range rather than listing each hostname separately: - -In INI: - -.. code-block:: text - - [webservers] - www[01:50].example.com - -In YAML: - -.. code-block:: yaml - - ... - webservers: - hosts: - www[01:50].example.com: - -You can specify a stride (increments between sequence numbers) when defining a numeric range of hosts: - -In INI: - -.. code-block:: text - - [webservers] - www[01:50:2].example.com - -In YAML: - -.. code-block:: yaml - - ... - webservers: - hosts: - www[01:50:2].example.com: - -The example above would make the subdomains www01, www03, www05, ..., www49 match, but not www00, www02, www50 and so on, because the stride (increment) is 2 units each step. - -For numeric patterns, leading zeros can be included or removed, as desired. Ranges are inclusive. You can also define alphabetic ranges: - -.. code-block:: text - - [databases] - db-[a:f].example.com - -.. _using_multiple_inventory_sources: - -Passing multiple inventory sources -================================== - -You can target multiple inventory sources (directories, dynamic inventory scripts -or files supported by inventory plugins) at the same time by giving multiple inventory parameters from the command -line or by configuring :envvar:`ANSIBLE_INVENTORY`. This can be useful when you want to target normally -separate environments, like staging and production, at the same time for a specific action. - -To target two inventory sources from the command line: - -.. code-block:: bash - - ansible-playbook get_logs.yml -i staging -i production - -.. _inventory_directory: - -Organizing inventory in a directory -=================================== - -You can consolidate multiple inventory sources in a single directory. The simplest version of this is a directory with multiple files instead of a single inventory file. A single file gets difficult to maintain when it gets too long. If you have multiple teams and multiple automation projects, having one inventory file per team or project lets everyone easily find the hosts and groups that matter to them. - -You can also combine multiple inventory source types in an inventory directory. This can be useful for combining static and dynamic hosts and managing them as one inventory. -The following inventory directory combines an inventory plugin source, a dynamic inventory script, -and a file with static hosts: - -.. code-block:: text - - inventory/ - openstack.yml # configure inventory plugin to get hosts from OpenStack cloud - dynamic-inventory.py # add additional hosts with dynamic inventory script - on-prem # add static hosts and groups - parent-groups # add static hosts and groups - -You can target this inventory directory as follows: - -.. code-block:: bash - - ansible-playbook example.yml -i inventory - -You can also configure the inventory directory in your ``ansible.cfg`` file. See :ref:`intro_configuration` for more details. - -Managing inventory load order ------------------------------ - -Ansible loads inventory sources in ASCII order according to the filenames. If you define parent groups in one file or directory and child groups in other files or directories, the files that define the child groups must be loaded first. If the parent groups are loaded first, you will see the error ``Unable to parse /path/to/source_of_parent_groups as an inventory source``. - -For example, if you have a file called ``groups-of-groups`` that defines a ``production`` group with child groups defined in a file called ``on-prem``, Ansible cannot parse the ``production`` group. To avoid this problem, you can control the load order by adding prefixes to the files: - -.. code-block:: text - - inventory/ - 01-openstack.yml # configure inventory plugin to get hosts from OpenStack cloud - 02-dynamic-inventory.py # add additional hosts with dynamic inventory script - 03-on-prem # add static hosts and groups - 04-groups-of-groups # add parent groups - -You can find examples of how to organize your inventories and group your hosts in :ref:`inventory_setup_examples`. - -.. _variables_in_inventory: - -Adding variables to inventory -============================= - -You can store variable values that relate to a specific host or group in inventory. To start with, you may add variables directly to the hosts and groups in your main inventory file. - -We document adding variables in the main inventory file for simplicity. However, storing variables in separate host and group variable files is a more robust approach to describing your system policy. Setting variables in the main inventory file is only a shorthand. See :ref:`splitting_out_vars` for guidelines on storing variable values in individual files in the 'host_vars' directory. See :ref:`splitting_out_vars` for details. - -.. _host_variables: - -Assigning a variable to one machine: host variables -=================================================== - -You can easily assign a variable to a single host, then use it later in playbooks. You can do this directly in your inventory file. - -In INI: - -.. code-block:: text - - [atlanta] - host1 http_port=80 maxRequestsPerChild=808 - host2 http_port=303 maxRequestsPerChild=909 - -In YAML: - -.. code-block:: yaml - - atlanta: - hosts: - host1: - http_port: 80 - maxRequestsPerChild: 808 - host2: - http_port: 303 - maxRequestsPerChild: 909 - -Unique values like non-standard SSH ports work well as host variables. You can add them to your Ansible inventory by adding the port number after the hostname with a colon: - -.. code-block:: text - - badwolf.example.com:5309 - -Connection variables also work well as host variables: - -.. code-block:: text - - [targets] - - localhost ansible_connection=local - other1.example.com ansible_connection=ssh ansible_user=myuser - other2.example.com ansible_connection=ssh ansible_user=myotheruser - -.. note:: If you list non-standard SSH ports in your SSH config file, the ``openssh`` connection will find and use them, but the ``paramiko`` connection will not. - -.. _inventory_aliases: - -Inventory aliases ------------------ - -You can also define aliases in your inventory using host variables: - -In INI: - -.. code-block:: text - - jumper ansible_port=5555 ansible_host=192.0.2.50 - -In YAML: - -.. code-block:: yaml - - ... - hosts: - jumper: - ansible_port: 5555 - ansible_host: 192.0.2.50 - -In this example, running Ansible against the host alias "jumper" will connect to 192.0.2.50 on port 5555. See :ref:`behavioral inventory parameters ` to further customize the connection to hosts. - -Defining variables in INI format -================================ - -Values passed in the INI format using the ``key=value`` syntax are interpreted differently depending on where they are declared: - -* When declared inline with the host, INI values are interpreted as Python literal structures (strings, numbers, tuples, lists, dicts, booleans, None). Host lines accept multiple ``key=value`` parameters per line. Therefore they need a way to indicate that a space is part of a value rather than a separator. Values that contain whitespace can be quoted (single or double). See the `Python shlex parsing rules`_ for details. - -* When declared in a ``:vars`` section, INI values are interpreted as strings. For example ``var=FALSE`` would create a string equal to 'FALSE'. Unlike host lines, ``:vars`` sections accept only a single entry per line, so everything after the ``=`` must be the value for the entry. - -If a variable value set in an INI inventory must be a certain type (for example, a string or a boolean value), always specify the type with a filter in your task. Do not rely on types set in INI inventories when consuming variables. - -Consider using YAML format for inventory sources to avoid confusion on the actual type of a variable. The YAML inventory plugin processes variable values consistently and correctly. - -.. _Python shlex parsing rules: https://docs.python.org/3/library/shlex.html#parsing-rules - -.. _group_variables: - -Assigning a variable to many machines: group variables -====================================================== - -If all hosts in a group share a variable value, you can apply that variable to an entire group at once. - -In INI: - -.. code-block:: text - - [atlanta] - host1 - host2 - - [atlanta:vars] - ntp_server=ntp.atlanta.example.com - proxy=proxy.atlanta.example.com - -In YAML: - -.. code-block:: yaml - - atlanta: - hosts: - host1: - host2: - vars: - ntp_server: ntp.atlanta.example.com - proxy: proxy.atlanta.example.com - -Group variables are a convenient way to apply variables to multiple hosts at once. Before executing, however, Ansible always flattens variables, including inventory variables, to the host level. If a host is a member of multiple groups, Ansible reads variable values from all of those groups. If you assign different values to the same variable in different groups, Ansible chooses which value to use based on internal :ref:`rules for merging `. - -.. _subgroups: - -Inheriting variable values: group variables for groups of groups ----------------------------------------------------------------- - -You can apply variables to parent groups (nested groups or groups of groups) as well as to child groups. The syntax is the same: ``:vars`` for INI format and ``vars:`` for YAML format: - -In INI: - -.. code-block:: text - - [atlanta] - host1 - host2 - - [raleigh] - host2 - host3 - - [southeast:children] - atlanta - raleigh - - [southeast:vars] - some_server=foo.southeast.example.com - halon_system_timeout=30 - self_destruct_countdown=60 - escape_pods=2 - - [usa:children] - southeast - northeast - southwest - northwest - -In YAML: - -.. code-block:: yaml - - all: - children: - usa: - children: - southeast: - children: - atlanta: - hosts: - host1: - host2: - raleigh: - hosts: - host2: - host3: - vars: - some_server: foo.southeast.example.com - halon_system_timeout: 30 - self_destruct_countdown: 60 - escape_pods: 2 - northeast: - northwest: - southwest: - -A child group's variables will have higher precedence (override) a parent group's variables. - -.. _splitting_out_vars: - -Organizing host and group variables -=================================== - -Although you can store variables in the main inventory file, storing separate host and group variables files may help you organize your variable values more easily. You can also use lists and hash data in host and group variables files, which you cannot do in your main inventory file. - -Host and group variable files must use YAML syntax. Valid file extensions include '.yml', '.yaml', '.json', or no file extension. See :ref:`yaml_syntax` if you are new to YAML. - -Ansible loads host and group variable files by searching paths relative to the inventory file or the playbook file. If your inventory file at ``/etc/ansible/hosts`` contains a host named 'foosball' that belongs to two groups, 'raleigh' and 'webservers', that host will use variables in YAML files at the following locations: - -.. code-block:: bash - - /etc/ansible/group_vars/raleigh # can optionally end in '.yml', '.yaml', or '.json' - /etc/ansible/group_vars/webservers - /etc/ansible/host_vars/foosball - -For example, if you group hosts in your inventory by datacenter, and each datacenter uses its own NTP server and database server, you can create a file called ``/etc/ansible/group_vars/raleigh`` to store the variables for the ``raleigh`` group: - -.. code-block:: yaml - - --- - ntp_server: acme.example.org - database_server: storage.example.org - -You can also create *directories* named after your groups or hosts. Ansible will read all the files in these directories in lexicographical order. An example with the 'raleigh' group: - -.. code-block:: bash - - /etc/ansible/group_vars/raleigh/db_settings - /etc/ansible/group_vars/raleigh/cluster_settings - -All hosts in the 'raleigh' group will have the variables defined in these files -available to them. This can be very useful to keep your variables organized when a single -file gets too big, or when you want to use :ref:`Ansible Vault` on some group variables. - -For ``ansible-playbook`` you can also add ``group_vars/`` and ``host_vars/`` directories to your playbook directory. Other Ansible commands (for example, ``ansible``, ``ansible-console``, and so on) will only look for ``group_vars/`` and ``host_vars/`` in the inventory directory. If you want other commands to load group and host variables from a playbook directory, you must provide the ``--playbook-dir`` option on the command line. -If you load inventory files from both the playbook directory and the inventory directory, variables in the playbook directory will override variables set in the inventory directory. - -Keeping your inventory file and variables in a git repo (or other version control) -is an excellent way to track changes to your inventory and host variables. - -.. _how_we_merge: - -How variables are merged -======================== - -By default variables are merged/flattened to the specific host before a play is run. This keeps Ansible focused on the Host and Task, so groups don't really survive outside of inventory and host matching. By default, Ansible overwrites variables including the ones defined for a group and/or host (see :ref:`DEFAULT_HASH_BEHAVIOUR`). The order/precedence is (from lowest to highest): - -- all group (because it is the 'parent' of all other groups) -- parent group -- child group -- host - -By default Ansible merges groups at the same parent/child level in ASCII order, and variables from the last group loaded overwrite variables from the previous groups. For example, an a_group will be merged with b_group and b_group vars that match will overwrite the ones in a_group. - -You can change this behavior by setting the group variable ``ansible_group_priority`` to change the merge order for groups of the same level (after the parent/child order is resolved). The larger the number, the later it will be merged, giving it higher priority. This variable defaults to ``1`` if not set. For example: - -.. code-block:: yaml - - a_group: - vars: - testvar: a - ansible_group_priority: 10 - b_group: - vars: - testvar: b - -In this example, if both groups have the same priority, the result would normally have been ``testvar == b``, but since we are giving the ``a_group`` a higher priority the result will be ``testvar == a``. - -.. note:: ``ansible_group_priority`` can only be set in the inventory source and not in group_vars/, as the variable is used in the loading of group_vars. - -Managing inventory variable load order --------------------------------------- - -When using multiple inventory sources, keep in mind that any variable conflicts are resolved according -to the rules described in :ref:`how_we_merge` and :ref:`ansible_variable_precedence`. You can control the merging order of variables in inventory sources to get the variable value you need. - -When you pass multiple inventory sources at the command line, Ansible merges variables in the order you pass those parameters. If ``[all:vars]`` in staging inventory defines ``myvar = 1`` and production inventory defines ``myvar = 2``, then: - -* Pass ``-i staging -i production`` to run the playbook with ``myvar = 2``. -* Pass ``-i production -i staging`` to run the playbook with ``myvar = 1``. - -When you put multiple inventory sources in a directory, Ansible merges them in ASCII order according to the filenames. You can control the load order by adding prefixes to the files: - -.. code-block:: text - - inventory/ - 01-openstack.yml # configure inventory plugin to get hosts from Openstack cloud - 02-dynamic-inventory.py # add additional hosts with dynamic inventory script - 03-static-inventory # add static hosts - group_vars/ - all.yml # assign variables to all hosts - -If ``01-openstack.yml`` defines ``myvar = 1`` for the group ``all``, ``02-dynamic-inventory.py`` defines ``myvar = 2``, -and ``03-static-inventory`` defines ``myvar = 3``, the playbook will be run with ``myvar = 3``. - -For more details on inventory plugins and dynamic inventory scripts see :ref:`inventory_plugins` and :ref:`intro_dynamic_inventory`. - -.. _behavioral_parameters: - -Connecting to hosts: behavioral inventory parameters -==================================================== - -As described above, setting the following variables control how Ansible interacts with remote hosts. - -Host connection: - -.. include:: shared_snippets/SSH_password_prompt.txt - -ansible_connection - Connection type to the host. This can be the name of any of ansible's connection plugins. SSH protocol types are ``smart``, ``ssh`` or ``paramiko``. The default is smart. Non-SSH based types are described in the next section. - -General for all connections: - -ansible_host - The name of the host to connect to, if different from the alias you wish to give to it. -ansible_port - The connection port number, if not the default (22 for ssh) -ansible_user - The user name to use when connecting to the host -ansible_password - The password to use to authenticate to the host (never store this variable in plain text; always use a vault. See :ref:`tip_for_variables_and_vaults`) - - -Specific to the SSH connection: - -ansible_ssh_private_key_file - Private key file used by ssh. Useful if using multiple keys and you don't want to use SSH agent. -ansible_ssh_common_args - This setting is always appended to the default command line for :command:`sftp`, :command:`scp`, - and :command:`ssh`. Useful to configure a ``ProxyCommand`` for a certain host (or - group). -ansible_sftp_extra_args - This setting is always appended to the default :command:`sftp` command line. -ansible_scp_extra_args - This setting is always appended to the default :command:`scp` command line. -ansible_ssh_extra_args - This setting is always appended to the default :command:`ssh` command line. -ansible_ssh_pipelining - Determines whether or not to use SSH pipelining. This can override the ``pipelining`` setting in :file:`ansible.cfg`. -ansible_ssh_executable (added in version 2.2) - This setting overrides the default behavior to use the system :command:`ssh`. This can override the ``ssh_executable`` setting in :file:`ansible.cfg`. - - -Privilege escalation (see :ref:`Ansible Privilege Escalation` for further details): - -ansible_become - Equivalent to ``ansible_sudo`` or ``ansible_su``, allows to force privilege escalation -ansible_become_method - Allows to set privilege escalation method -ansible_become_user - Equivalent to ``ansible_sudo_user`` or ``ansible_su_user``, allows to set the user you become through privilege escalation -ansible_become_password - Equivalent to ``ansible_sudo_password`` or ``ansible_su_password``, allows you to set the privilege escalation password (never store this variable in plain text; always use a vault. See :ref:`tip_for_variables_and_vaults`) -ansible_become_exe - Equivalent to ``ansible_sudo_exe`` or ``ansible_su_exe``, allows you to set the executable for the escalation method selected -ansible_become_flags - Equivalent to ``ansible_sudo_flags`` or ``ansible_su_flags``, allows you to set the flags passed to the selected escalation method. This can be also set globally in :file:`ansible.cfg` in the ``sudo_flags`` option - -Remote host environment parameters: - -.. _ansible_shell_type: - -ansible_shell_type - The shell type of the target system. You should not use this setting unless you have set the - :ref:`ansible_shell_executable` to a non-Bourne (sh) compatible shell. By default commands are - formatted using ``sh``-style syntax. Setting this to ``csh`` or ``fish`` will cause commands - executed on target systems to follow those shell's syntax instead. - -.. _ansible_python_interpreter: - -ansible_python_interpreter - The target host python path. This is useful for systems with more - than one Python or not located at :command:`/usr/bin/python` such as \*BSD, or where :command:`/usr/bin/python` - is not a 2.X series Python. We do not use the :command:`/usr/bin/env` mechanism as that requires the remote user's - path to be set right and also assumes the :program:`python` executable is named python, where the executable might - be named something like :program:`python2.6`. - -ansible_*_interpreter - Works for anything such as ruby or perl and works just like :ref:`ansible_python_interpreter`. - This replaces shebang of modules which will run on that host. - -.. versionadded:: 2.1 - -.. _ansible_shell_executable: - -ansible_shell_executable - This sets the shell the ansible controller will use on the target machine, - overrides ``executable`` in :file:`ansible.cfg` which defaults to - :command:`/bin/sh`. You should really only change it if is not possible - to use :command:`/bin/sh` (in other words, if :command:`/bin/sh` is not installed on the target - machine or cannot be run from sudo.). - -Examples from an Ansible-INI host file: - -.. code-block:: text - - some_host ansible_port=2222 ansible_user=manager - aws_host ansible_ssh_private_key_file=/home/example/.ssh/aws.pem - freebsd_host ansible_python_interpreter=/usr/local/bin/python - ruby_module_host ansible_ruby_interpreter=/usr/bin/ruby.1.9.3 - -Non-SSH connection types ------------------------- - -As stated in the previous section, Ansible executes playbooks over SSH but it is not limited to this connection type. -With the host specific parameter ``ansible_connection=``, the connection type can be changed. -The following non-SSH based connectors are available: - -**local** - -This connector can be used to deploy the playbook to the control machine itself. - -**docker** - -This connector deploys the playbook directly into Docker containers using the local Docker client. The following parameters are processed by this connector: - -ansible_host - The name of the Docker container to connect to. -ansible_user - The user name to operate within the container. The user must exist inside the container. -ansible_become - If set to ``true`` the ``become_user`` will be used to operate within the container. -ansible_docker_extra_args - Could be a string with any additional arguments understood by Docker, which are not command specific. This parameter is mainly used to configure a remote Docker daemon to use. - -Here is an example of how to instantly deploy to created containers: - -.. code-block:: yaml - - - name: Create a jenkins container - community.general.docker_container: - docker_host: myserver.net:4243 - name: my_jenkins - image: jenkins - - - name: Add the container to inventory - ansible.builtin.add_host: - name: my_jenkins - ansible_connection: docker - ansible_docker_extra_args: "--tlsverify --tlscacert=/path/to/ca.pem --tlscert=/path/to/client-cert.pem --tlskey=/path/to/client-key.pem -H=tcp://myserver.net:4243" - ansible_user: jenkins - changed_when: false - - - name: Create a directory for ssh keys - delegate_to: my_jenkins - ansible.builtin.file: - path: "/var/jenkins_home/.ssh/jupiter" - state: directory - -For a full list with available plugins and examples, see :ref:`connection_plugin_list`. - -.. note:: If you're reading the docs from the beginning, this may be the first example you've seen of an Ansible playbook. This is not an inventory file. - Playbooks will be covered in great detail later in the docs. - -.. _inventory_setup_examples: - -Inventory setup examples -======================== - -See also :ref:`sample_setup`, which shows inventory along with playbooks and other Ansible artifacts. - -.. _inventory_setup-per_environment: - -Example: One inventory per environment --------------------------------------- - -If you need to manage multiple environments it's sometimes prudent to -have only hosts of a single environment defined per inventory. This -way, it is harder to, for instance, accidentally change the state of -nodes inside the "test" environment when you actually wanted to update -some "staging" servers. - -For the example mentioned above you could have an -:file:`inventory_test` file: - -.. code-block:: ini - - [dbservers] - db01.test.example.com - db02.test.example.com - - [appservers] - app01.test.example.com - app02.test.example.com - app03.test.example.com - -That file only includes hosts that are part of the "test" -environment. Define the "staging" machines in another file -called :file:`inventory_staging`: - -.. code-block:: ini - - [dbservers] - db01.staging.example.com - db02.staging.example.com - - [appservers] - app01.staging.example.com - app02.staging.example.com - app03.staging.example.com - -To apply a playbook called :file:`site.yml` -to all the app servers in the test environment, use the -following command: - -.. code-block:: bash - - ansible-playbook -i inventory_test -l appservers site.yml - -.. _inventory_setup-per_function: - -Example: Group by function --------------------------- - -In the previous section you already saw an example for using groups in -order to cluster hosts that have the same function. This allows you, -for instance, to define firewall rules inside a playbook or role -affecting only database servers: - -.. code-block:: yaml - - - hosts: dbservers - tasks: - - name: Allow access from 10.0.0.1 - ansible.builtin.iptables: - chain: INPUT - jump: ACCEPT - source: 10.0.0.1 - -.. _inventory_setup-per_location: - -Example: Group by location --------------------------- - -Other tasks might be focused on where a certain host is located. Let's -say that ``db01.test.example.com`` and ``app01.test.example.com`` are -located in DC1 while ``db02.test.example.com`` is in DC2: - -.. code-block:: ini - - [dc1] - db01.test.example.com - app01.test.example.com - - [dc2] - db02.test.example.com - -In practice, you might even end up mixing all these setups as you -might need to, on one day, update all nodes in a specific data center -while, on another day, update all the application servers no matter -their location. - -.. seealso:: - - :ref:`inventory_plugins` - Pulling inventory from dynamic or static sources - :ref:`intro_dynamic_inventory` - Pulling inventory from dynamic sources, such as cloud providers - :ref:`intro_adhoc` - Examples of basic commands - :ref:`working_with_playbooks` - Learning Ansible's configuration, deployment, and orchestration language. - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/inventory_guide/intro_patterns.rst b/docs/docsite/rst/inventory_guide/intro_patterns.rst deleted file mode 100644 index 446b7d4ca2f..00000000000 --- a/docs/docsite/rst/inventory_guide/intro_patterns.rst +++ /dev/null @@ -1,253 +0,0 @@ -.. _intro_patterns: - -Patterns: targeting hosts and groups -==================================== - -When you execute Ansible through an ad hoc command or by running a playbook, you must choose which managed nodes or groups you want to execute against. -Patterns let you run commands and playbooks against specific hosts and/or groups in your inventory. -An Ansible pattern can refer to a single host, an IP address, an inventory group, a set of groups, or all hosts in your inventory. -Patterns are highly flexible - you can exclude or require subsets of hosts, use wildcards or regular expressions, and more. -Ansible executes on all inventory hosts included in the pattern. - -.. contents:: - :local: - -Using patterns --------------- - -You use a pattern almost any time you execute an ad hoc command or a playbook. The pattern is the only element of an :ref:`ad hoc command` that has no flag. It is usually the second element: - -.. code-block:: bash - - ansible -m -a "" - -For example: - -.. code-block:: bash - - ansible webservers -m service -a "name=httpd state=restarted" - -In a playbook the pattern is the content of the ``hosts:`` line for each play: - -.. code-block:: yaml - - - name: - hosts: - -For example: - -.. code-block:: yaml - - - name: restart webservers - hosts: webservers - -Since you often want to run a command or playbook against multiple hosts at once, patterns often refer to inventory groups. Both the ad hoc command and the playbook above will execute against all machines in the ``webservers`` group. - -.. _common_patterns: - -Common patterns ---------------- - -This table lists common patterns for targeting inventory hosts and groups. - -.. table:: - :class: documentation-table - - ====================== ================================ =================================================== - Description Pattern(s) Targets - ====================== ================================ =================================================== - All hosts all (or \*) - - One host host1 - - Multiple hosts host1:host2 (or host1,host2) - - One group webservers - - Multiple groups webservers:dbservers all hosts in webservers plus all hosts in dbservers - - Excluding groups webservers:!atlanta all hosts in webservers except those in atlanta - - Intersection of groups webservers:&staging any hosts in webservers that are also in staging - ====================== ================================ =================================================== - -.. note:: You can use either a comma (``,``) or a colon (``:``) to separate a list of hosts. The comma is preferred when dealing with ranges and IPv6 addresses. - -Once you know the basic patterns, you can combine them. This example: - -.. code-block:: yaml - - webservers:dbservers:&staging:!phoenix - -targets all machines in the groups 'webservers' and 'dbservers' that are also in -the group 'staging', except any machines in the group 'phoenix'. - -You can use wildcard patterns with FQDNs or IP addresses, as long as the hosts are named in your inventory by FQDN or IP address: - -.. code-block:: yaml - - 192.0.* - *.example.com - *.com - -You can mix wildcard patterns and groups at the same time: - -.. code-block:: yaml - - one*.com:dbservers - -Limitations of patterns ------------------------ - -Patterns depend on inventory. If a host or group is not listed in your inventory, you cannot use a pattern to target it. If your pattern includes an IP address or hostname that does not appear in your inventory, you will see an error like this: - -.. code-block:: text - - [WARNING]: No inventory was parsed, only implicit localhost is available - [WARNING]: Could not match supplied host pattern, ignoring: *.not_in_inventory.com - -Your pattern must match your inventory syntax. If you define a host as an :ref:`alias`: - -.. code-block:: yaml - - atlanta: - host1: - http_port: 80 - maxRequestsPerChild: 808 - host: 127.0.0.2 - -you must use the alias in your pattern. In the example above, you must use ``host1`` in your pattern. If you use the IP address, you will once again get the error: - -.. code-block:: console - - [WARNING]: Could not match supplied host pattern, ignoring: 127.0.0.2 - -Pattern processing order ------------------------- - -The processing is a bit special and happens in the following order: - -1. ``:`` and ``,`` -2. ``&`` -3. ``!`` - -This positioning only accounts for processing order inside each operation: -``a:b:&c:!d:!e == &c:a:!d:b:!e == !d:a:!e:&c:b`` - -All of these result in the following: - -Host in/is (a or b) AND host in/is all(c) AND host NOT in/is all(d, e). - -Now ``a:b:!e:!d:&c`` is a slight change as the ``!e`` gets processed before the ``!d``, though this doesn't make much of a difference: - -Host in/is (a or b) AND host in/is all(c) AND host NOT in/is all(e, d). - -Advanced pattern options ------------------------- - -The common patterns described above will meet most of your needs, but Ansible offers several other ways to define the hosts and groups you want to target. - -Using variables in patterns -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can use variables to enable passing group specifiers via the ``-e`` argument to ansible-playbook: - -.. code-block:: bash - - webservers:!{{ excluded }}:&{{ required }} - -Using group position in patterns -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can define a host or subset of hosts by its position in a group. For example, given the following group: - -.. code-block:: ini - - [webservers] - cobweb - webbing - weber - -you can use subscripts to select individual hosts or ranges within the webservers group: - -.. code-block:: yaml - - webservers[0] # == cobweb - webservers[-1] # == weber - webservers[0:2] # == webservers[0],webservers[1] - # == cobweb,webbing - webservers[1:] # == webbing,weber - webservers[:3] # == cobweb,webbing,weber - -Using regexes in patterns -^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can specify a pattern as a regular expression by starting the pattern with ``~``: - -.. code-block:: yaml - - ~(web|db).*\.example\.com - -Patterns and ad-hoc commands ----------------------------- - -You can change the behavior of the patterns defined in ad-hoc commands using command-line options. -You can also limit the hosts you target on a particular run with the ``--limit`` flag. - -* Limit to one host - -.. code-block:: bash - - $ ansible all -m [module] -a "[module options]" --limit "host1" - -* Limit to multiple hosts - -.. code-block:: bash - - $ ansible all -m [module] -a "[module options]" --limit "host1,host2" - -* Negated limit. Note that single quotes MUST be used to prevent bash interpolation. - -.. code-block:: bash - - $ ansible all -m [module] -a "[module options]" --limit 'all:!host1' - -* Limit to host group - -.. code-block:: bash - - $ ansible all -m [module] -a "[module options]" --limit 'group1' - -Patterns and ansible-playbook flags ------------------------------------ - -You can change the behavior of the patterns defined in playbooks using command-line options. For example, you can run a playbook that defines ``hosts: all`` on a single host by specifying ``-i 127.0.0.2,`` (note the trailing comma). This works even if the host you target is not defined in your inventory, but this method will NOT read your inventory for variables tied to this host and any variables required by the playbook will need to be specified manually at the command line. You can also limit the hosts you target on a particular run with the ``--limit`` flag, which will reference your inventory: - -.. code-block:: bash - - ansible-playbook site.yml --limit datacenter2 - -Finally, you can use ``--limit`` to read the list of hosts from a file by prefixing the file name with ``@``: - -.. code-block:: bash - - ansible-playbook site.yml --limit @retry_hosts.txt - -If :ref:`RETRY_FILES_ENABLED` is set to ``True``, a ``.retry`` file will be created after the ``ansible-playbook`` run containing a list of failed hosts from all plays. This file is overwritten each time ``ansible-playbook`` finishes running. - -.. code-block:: bash - - ansible-playbook site.yml --limit @site.retry - -To apply your knowledge of patterns with Ansible commands and playbooks, read :ref:`intro_adhoc` and :ref:`playbooks_intro`. - -.. seealso:: - - :ref:`intro_adhoc` - Examples of basic commands - :ref:`working_with_playbooks` - Learning the Ansible configuration management language - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/inventory_guide/shared_snippets/SSH_password_prompt.txt b/docs/docsite/rst/inventory_guide/shared_snippets/SSH_password_prompt.txt deleted file mode 100644 index dc61ab38b70..00000000000 --- a/docs/docsite/rst/inventory_guide/shared_snippets/SSH_password_prompt.txt +++ /dev/null @@ -1,2 +0,0 @@ -.. note:: - Ansible does not expose a channel to allow communication between the user and the ssh process to accept a password manually to decrypt an ssh key when using the ssh connection plugin (which is the default). The use of ``ssh-agent`` is highly recommended. diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/404.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/404.po deleted file mode 100644 index 84ad11147d0..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/404.po +++ /dev/null @@ -1,30 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-02-23 10:50+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/404.rst:5 -msgid "Oops!" -msgstr "Oops!" - -#: ../../rst/404.rst:7 -msgid "The version of the Ansible documentation you were looking at doesn't contain that page." -msgstr "参照している Ansible ドキュメントのバージョンには、そのページが含まれていません。" - -#: ../../rst/404.rst:12 -msgid "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." -msgstr "戻るボタンを使用して閲覧していたバージョンに戻るか、左側のナビゲーションを使用して最新リリースを参照してください。404 以外のページでは、バージョン番号変更メニューを使用してバージョンを選択できます。" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/api.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/api.po deleted file mode 100644 index 52c296ab6f8..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/api.po +++ /dev/null @@ -1,94 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-02-23 10:50+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/api/index.rst:5 -msgid "Ansible API Documentation" -msgstr "Ansible API のドキュメント" - -#: ../../rst/api/index.rst:7 -msgid "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 ` included in ``ansible.module_utils.basic`` and ``AnsibleModule`` are documented under Reference & Appendices." -msgstr "Ansible API を構築中です。属性、クラス、関数、メソッド、およびモジュールのスタブ参照の説明は、今後追加されます。``ansible.module_utils.basic`` および ``AnsibleModule`` に含まれる「:ref:`モジュールユーティリティー `」、「参照および付録」に記載されています。" - -#: ../../rst/api/index.rst:14 -msgid "Attributes" -msgstr "属性" - -#: ../../rst/api/index.rst:18 -msgid "The parameters accepted by the module." -msgstr "モジュールで受け入れられるパラメーターです。" - -#: ../../rst/api/index.rst:24 -msgid "Deprecated in favor of ansibleModule._selinux_special_fs." -msgstr "ansibleModule._selinux_special_fs が導入されたため、非推奨となりました。" - -#: ../../rst/api/index.rst:36 -msgid "(formerly ansible.module_utils.basic.SELINUX_SPECIAL_FS)" -msgstr "(以前は ansible.module_utils.basic.SELINUX_SPECIAL_FS)" - -#: ../../rst/api/index.rst:50 -msgid "Classes" -msgstr "クラス" - -#: ../../rst/api/index.rst:55 -msgid "The basic utilities for AnsibleModule." -msgstr "AnsibleModule の基本的なユーティリティーです。" - -#: ../../rst/api/index.rst:59 -msgid "The main class for an Ansible module." -msgstr "Ansible モジュールのメインクラスです。" - -#: ../../rst/api/index.rst:63 -msgid "Functions" -msgstr "関数" - -#: ../../rst/api/index.rst:67 -msgid "Load parameters." -msgstr "パラメーターを読み込みます。" - -#: ../../rst/api/index.rst:71 -msgid "Methods" -msgstr "メソッド" - -#: ../../rst/api/index.rst:75 -msgid "Logs the output of Ansible." -msgstr "Ansible の出力をログに記録します。" - -#: ../../rst/api/index.rst:79 -msgid "Debugs Ansible." -msgstr "Ansible をデバッグします。" - -#: ../../rst/api/index.rst:83 -msgid "Retrieves the path for executables." -msgstr "実行可能ファイルのパスを取得します。" - -#: ../../rst/api/index.rst:87 -msgid "Runs a command within an Ansible module." -msgstr "Ansible モジュール内でコマンドを実行します。" - -#: ../../rst/api/index.rst:91 -msgid "Exits and returns a failure." -msgstr "終了して、失敗を返します。" - -#: ../../rst/api/index.rst:95 -msgid "Exits and returns output." -msgstr "終了して、出力を返します。" - -#: ../../rst/api/index.rst:99 -msgid "Modules" -msgstr "モジュール" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/cli.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/cli.po deleted file mode 100644 index 14ffade0f0c..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/cli.po +++ /dev/null @@ -1,1137 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-03-08 20:25+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/cli/ansible.rst:7 -msgid "ansible" -msgstr "ansible" - -#: ../../rst/cli/ansible.rst:10 -msgid ":strong:`Define and run a single task 'playbook' against a set of hosts`" -msgstr ":strong:`一連のホストに対して単一のタスク「Playbook」を定義して実行`" - -#: ../../rst/cli/ansible-config.rst:21 ../../rst/cli/ansible-console.rst:21 -#: ../../rst/cli/ansible-doc.rst:21 ../../rst/cli/ansible-galaxy.rst:21 -#: ../../rst/cli/ansible-inventory.rst:21 ../../rst/cli/ansible-playbook.rst:21 -#: ../../rst/cli/ansible-pull.rst:21 ../../rst/cli/ansible-vault.rst:21 -#: ../../rst/cli/ansible.rst:21 -msgid "Synopsis" -msgstr "概要" - -#: ../../rst/cli/ansible-config.rst:30 ../../rst/cli/ansible-console.rst:44 -#: ../../rst/cli/ansible-doc.rst:35 ../../rst/cli/ansible-galaxy.rst:30 -#: ../../rst/cli/ansible-inventory.rst:36 ../../rst/cli/ansible-playbook.rst:45 -#: ../../rst/cli/ansible-pull.rst:44 ../../rst/cli/ansible-vault.rst:32 -#: ../../rst/cli/ansible.rst:43 -msgid "Description" -msgstr "説明" - -#: ../../rst/cli/ansible.rst:46 -msgid "is an extra-simple tool/framework/API for doing 'remote things'. this command allows you to define and run a single task 'playbook' against a set of hosts" -msgstr "「リモートのこと」を行う非常に単純なツール/フレームワーク/API です。このコマンドでは、ホスト 1 台に対して単一タスク「Playbook」を定義および実行できます" - -#: ../../rst/cli/ansible-config.rst:37 ../../rst/cli/ansible-console.rst:72 -#: ../../rst/cli/ansible-doc.rst:45 ../../rst/cli/ansible-galaxy.rst:37 -#: ../../rst/cli/ansible-inventory.rst:43 ../../rst/cli/ansible-playbook.rst:53 -#: ../../rst/cli/ansible-pull.rst:59 ../../rst/cli/ansible-vault.rst:46 -#: ../../rst/cli/ansible.rst:51 -msgid "Common Options" -msgstr "共通オプション" - -#: ../../rst/cli/ansible-console.rst:79 ../../rst/cli/ansible-inventory.rst:50 -#: ../../rst/cli/ansible-playbook.rst:60 ../../rst/cli/ansible-pull.rst:71 -#: ../../rst/cli/ansible-vault.rst:89 ../../rst/cli/ansible-vault.rst:123 -#: ../../rst/cli/ansible-vault.rst:157 ../../rst/cli/ansible-vault.rst:191 -#: ../../rst/cli/ansible-vault.rst:221 ../../rst/cli/ansible-vault.rst:259 -#: ../../rst/cli/ansible-vault.rst:313 ../../rst/cli/ansible.rst:58 -msgid "ask for vault password" -msgstr "Vault のパスワード入力を尋ねます。" - -#: ../../rst/cli/ansible-console.rst:84 ../../rst/cli/ansible-playbook.rst:65 -#: ../../rst/cli/ansible.rst:63 -msgid "privilege escalation method to use (default=sudo), use `ansible-doc -t become -l` to list valid choices." -msgstr "使用する特権昇格方法 (デフォルトは sudo)。有効な選択を一覧表示するには `ansible-doc -t become -l` を使用します。" - -#: ../../rst/cli/ansible-console.rst:89 ../../rst/cli/ansible-playbook.rst:70 -#: ../../rst/cli/ansible.rst:68 -msgid "run operations as this user (default=root)" -msgstr "このユーザーとして操作を実行します (デフォルトは root)。" - -#: ../../rst/cli/ansible-console.rst:94 ../../rst/cli/ansible-playbook.rst:85 -#: ../../rst/cli/ansible-pull.rst:96 ../../rst/cli/ansible.rst:73 -msgid "outputs a list of matching hosts; does not execute anything else" -msgstr "一致するホストの一覧を出力します。他には何も実行しません。" - -#: ../../rst/cli/ansible-console.rst:99 ../../rst/cli/ansible-doc.rst:57 -#: ../../rst/cli/ansible-inventory.rst:85 ../../rst/cli/ansible.rst:78 -msgid "Since this tool does not use playbooks, use this as a substitute playbook directory.This sets the relative path for many features including roles/ group_vars/ etc." -msgstr "このツールは Playbook を使用しないため、代替の Playbook ディレクトリーとして使用します。これにより、roles/ group_vars/ などの多くの機能の相対パスが設定されます。" - -#: ../../rst/cli/ansible-console.rst:104 ../../rst/cli/ansible-playbook.rst:100 -#: ../../rst/cli/ansible-pull.rst:101 ../../rst/cli/ansible.rst:83 -msgid "use this file to authenticate the connection" -msgstr "このファイルを使用して接続を認証します。" - -#: ../../rst/cli/ansible-console.rst:109 ../../rst/cli/ansible-playbook.rst:105 -#: ../../rst/cli/ansible-pull.rst:111 ../../rst/cli/ansible.rst:88 -msgid "specify extra arguments to pass to scp only (e.g. -l)" -msgstr "scp のみに渡す追加の引数を指定します (例: -l)。" - -#: ../../rst/cli/ansible-console.rst:114 ../../rst/cli/ansible-playbook.rst:110 -#: ../../rst/cli/ansible-pull.rst:116 ../../rst/cli/ansible.rst:93 -msgid "specify extra arguments to pass to sftp only (e.g. -f, -l)" -msgstr "sftp のみに渡す追加の引数を指定します (例: -f、-l)。" - -#: ../../rst/cli/ansible-console.rst:119 ../../rst/cli/ansible-playbook.rst:120 -#: ../../rst/cli/ansible-pull.rst:126 ../../rst/cli/ansible.rst:98 -msgid "specify common arguments to pass to sftp/scp/ssh (e.g. ProxyCommand)" -msgstr "sftp/scp/ssh に渡す一般的な引数を指定します (例: ProxyCommand)。" - -#: ../../rst/cli/ansible-console.rst:124 ../../rst/cli/ansible-playbook.rst:125 -#: ../../rst/cli/ansible-pull.rst:131 ../../rst/cli/ansible.rst:103 -msgid "specify extra arguments to pass to ssh only (e.g. -R)" -msgstr "ssh のみに渡す追加の引数を指定します (例: -R)。" - -#: ../../rst/cli/ansible-console.rst:134 ../../rst/cli/ansible-playbook.rst:140 -#: ../../rst/cli/ansible.rst:108 -msgid "perform a syntax check on the playbook, but do not execute it" -msgstr "Playbook で構文チェックを実行しますが、Playbook は実行しません。" - -#: ../../rst/cli/ansible-console.rst:139 ../../rst/cli/ansible.rst:113 -msgid "set task timeout limit in seconds, must be positive integer." -msgstr "タスクのタイムアウト制限を秒単位で設定します。正の整数である必要があります。" - -#: ../../rst/cli/ansible-console.rst:144 -#: ../../rst/cli/ansible-inventory.rst:100 -#: ../../rst/cli/ansible-playbook.rst:145 ../../rst/cli/ansible-pull.rst:141 -#: ../../rst/cli/ansible-vault.rst:97 ../../rst/cli/ansible-vault.rst:131 -#: ../../rst/cli/ansible-vault.rst:165 ../../rst/cli/ansible-vault.rst:195 -#: ../../rst/cli/ansible-vault.rst:233 ../../rst/cli/ansible-vault.rst:279 -#: ../../rst/cli/ansible-vault.rst:329 ../../rst/cli/ansible.rst:118 -msgid "the vault identity to use" -msgstr "使用する Vault アイデンティティー" - -#: ../../rst/cli/ansible-console.rst:149 -#: ../../rst/cli/ansible-inventory.rst:105 -#: ../../rst/cli/ansible-playbook.rst:150 ../../rst/cli/ansible-pull.rst:146 -#: ../../rst/cli/ansible-vault.rst:101 ../../rst/cli/ansible-vault.rst:135 -#: ../../rst/cli/ansible-vault.rst:169 ../../rst/cli/ansible-vault.rst:199 -#: ../../rst/cli/ansible-vault.rst:237 ../../rst/cli/ansible-vault.rst:283 -#: ../../rst/cli/ansible-vault.rst:333 ../../rst/cli/ansible.rst:123 -msgid "vault password file" -msgstr "Vault パスワードファイル" - -#: ../../rst/cli/ansible-config.rst:44 ../../rst/cli/ansible-console.rst:154 -#: ../../rst/cli/ansible-doc.rst:62 ../../rst/cli/ansible-galaxy.rst:44 -#: ../../rst/cli/ansible-inventory.rst:110 -#: ../../rst/cli/ansible-playbook.rst:155 ../../rst/cli/ansible-pull.rst:156 -#: ../../rst/cli/ansible-vault.rst:53 ../../rst/cli/ansible.rst:128 -msgid "show program's version number, config file location, configured module search path, module location, executable location and exit" -msgstr "プログラムバージョン番号、設定ファイルの場所、設定したモジュール検索パス、モジュールの場所、実行可能な場所、および終了を表示します。" - -#: ../../rst/cli/ansible.rst:133 -msgid "run asynchronously, failing after X seconds (default=N/A)" -msgstr "非同期的に実行し、X 秒後に失敗します (デフォルトは N/A)。" - -#: ../../rst/cli/ansible-console.rst:159 ../../rst/cli/ansible-playbook.rst:160 -#: ../../rst/cli/ansible-pull.rst:76 ../../rst/cli/ansible.rst:138 -msgid "don't make any changes; instead, try to predict some of the changes that may occur" -msgstr "変更を加えないでください。代わりに、発生する可能性のある変更のいくつかを予測してみてください。" - -#: ../../rst/cli/ansible-console.rst:164 ../../rst/cli/ansible-playbook.rst:165 -#: ../../rst/cli/ansible-pull.rst:86 ../../rst/cli/ansible.rst:143 -msgid "when changing (small) files and templates, show the differences in those files; works great with --check" -msgstr "(小規模な) ファイルおよびテンプレートの変更時に、これらのファイルの相違点を表示します。--check と適切に連携します。" - -#: ../../rst/cli/ansible-console.rst:169 ../../rst/cli/ansible-playbook.rst:170 -#: ../../rst/cli/ansible-pull.rst:166 ../../rst/cli/ansible.rst:148 -msgid "ask for privilege escalation password" -msgstr "権限昇格のパスワードを要求します。" - -#: ../../rst/cli/ansible-console.rst:174 ../../rst/cli/ansible-doc.rst:72 -#: ../../rst/cli/ansible-playbook.rst:175 ../../rst/cli/ansible-pull.rst:171 -#: ../../rst/cli/ansible.rst:153 -msgid "prepend colon-separated path(s) to module library (default=~/.ansible/plugins/modules:/usr/share/ansible/plugins/modules)" -msgstr "モジュールライブラリーへのコロン区切りパス (デフォルトは ~/.ansible/plugins/modules:/usr/share/ansible/plugins/modules) を先頭に追加します。" - -#: ../../rst/cli/ansible.rst:158 -msgid "set the poll interval if using -B (default=15)" -msgstr "-B (デフォルトは 15) を使用する場合はポーリング間隔を設定します。" - -#: ../../rst/cli/ansible-console.rst:179 ../../rst/cli/ansible-playbook.rst:180 -#: ../../rst/cli/ansible-pull.rst:176 ../../rst/cli/ansible.rst:163 -msgid "override the connection timeout in seconds (default=10)" -msgstr "接続タイムアウトを秒単位で上書きします (デフォルトは 10)。" - -#: ../../rst/cli/ansible.rst:168 -msgid "module arguments" -msgstr "モジュール引数" - -#: ../../rst/cli/ansible-console.rst:184 ../../rst/cli/ansible-playbook.rst:185 -#: ../../rst/cli/ansible.rst:173 -msgid "run operations with become (does not imply password prompting)" -msgstr "become で操作の実行 (パスワード入力を意味するものではありません)" - -#: ../../rst/cli/ansible-console.rst:189 ../../rst/cli/ansible-playbook.rst:190 -#: ../../rst/cli/ansible-pull.rst:186 ../../rst/cli/ansible.rst:178 -msgid "connection type to use (default=smart)" -msgstr "使用する接続タイプ (デフォルトは smart)" - -#: ../../rst/cli/ansible-console.rst:194 -#: ../../rst/cli/ansible-inventory.rst:115 -#: ../../rst/cli/ansible-playbook.rst:195 ../../rst/cli/ansible-pull.rst:196 -#: ../../rst/cli/ansible.rst:183 -msgid "set additional variables as key=value or YAML/JSON, if filename prepend with @" -msgstr "ファイル名の前に @ を付ける場合は、追加の変数を key=value または YAML/JSON に設定します。" - -#: ../../rst/cli/ansible-console.rst:199 ../../rst/cli/ansible-playbook.rst:200 -#: ../../rst/cli/ansible.rst:188 -msgid "specify number of parallel processes to use (default=5)" -msgstr "使用する並列プロセス数を指定します (デフォルトは 5)。" - -#: ../../rst/cli/ansible-config.rst:49 ../../rst/cli/ansible-console.rst:204 -#: ../../rst/cli/ansible-doc.rst:82 ../../rst/cli/ansible-galaxy.rst:49 -#: ../../rst/cli/ansible-inventory.rst:120 -#: ../../rst/cli/ansible-playbook.rst:205 ../../rst/cli/ansible-pull.rst:206 -#: ../../rst/cli/ansible-vault.rst:58 ../../rst/cli/ansible.rst:193 -msgid "show this help message and exit" -msgstr "ヘルプメッセージを表示して終了します。" - -#: ../../rst/cli/ansible-console.rst:209 -#: ../../rst/cli/ansible-inventory.rst:125 -#: ../../rst/cli/ansible-playbook.rst:210 ../../rst/cli/ansible-pull.rst:211 -#: ../../rst/cli/ansible.rst:198 -msgid "specify inventory host path or comma separated host list. --inventory-file is deprecated" -msgstr "インベントリーホストパスまたはコンマ区切りホスト一覧を指定します。--inventory-file は非推奨になりました。" - -#: ../../rst/cli/ansible-console.rst:214 ../../rst/cli/ansible-playbook.rst:215 -#: ../../rst/cli/ansible-pull.rst:216 ../../rst/cli/ansible.rst:203 -msgid "ask for connection password" -msgstr "接続のパスワードを要求します。" - -#: ../../rst/cli/ansible-console.rst:219 ../../rst/cli/ansible-playbook.rst:220 -#: ../../rst/cli/ansible-pull.rst:221 ../../rst/cli/ansible.rst:208 -msgid "further limit selected hosts to an additional pattern" -msgstr "選択したホストを追加パターンにさらに制限します。" - -#: ../../rst/cli/ansible.rst:213 -msgid "module name to execute (default=command)" -msgstr "実行するモジュール名 (デフォルトは command)" - -#: ../../rst/cli/ansible.rst:218 -msgid "condense output" -msgstr "出力を要約します。" - -#: ../../rst/cli/ansible.rst:223 -msgid "log output to this directory" -msgstr "このディレクトリーにログを記録します。" - -#: ../../rst/cli/ansible-console.rst:224 ../../rst/cli/ansible-playbook.rst:230 -#: ../../rst/cli/ansible-pull.rst:246 ../../rst/cli/ansible.rst:228 -msgid "connect as this user (default=None)" -msgstr "このユーザーとして接続 します (デフォルトは None)。" - -#: ../../rst/cli/ansible-config.rst:54 ../../rst/cli/ansible-console.rst:229 -#: ../../rst/cli/ansible-doc.rst:112 ../../rst/cli/ansible-galaxy.rst:54 -#: ../../rst/cli/ansible-inventory.rst:135 -#: ../../rst/cli/ansible-playbook.rst:235 ../../rst/cli/ansible-pull.rst:251 -#: ../../rst/cli/ansible-vault.rst:63 ../../rst/cli/ansible.rst:233 -msgid "verbose mode (-vvv for more, -vvvv to enable connection debugging)" -msgstr "詳細モード (-vvv の場合はより詳細になる。-vvvv の場合は接続のデバッグを有効にする)" - -#: ../../rst/cli/ansible-config.rst:139 ../../rst/cli/ansible-console.rst:238 -#: ../../rst/cli/ansible-doc.rst:121 ../../rst/cli/ansible-galaxy.rst:783 -#: ../../rst/cli/ansible-inventory.rst:149 -#: ../../rst/cli/ansible-playbook.rst:244 ../../rst/cli/ansible-pull.rst:260 -#: ../../rst/cli/ansible-vault.rst:344 ../../rst/cli/ansible.rst:242 -msgid "Environment" -msgstr "環境" - -#: ../../rst/cli/ansible-config.rst:141 ../../rst/cli/ansible-console.rst:240 -#: ../../rst/cli/ansible-doc.rst:123 ../../rst/cli/ansible-galaxy.rst:785 -#: ../../rst/cli/ansible-inventory.rst:151 -#: ../../rst/cli/ansible-playbook.rst:246 ../../rst/cli/ansible-pull.rst:262 -#: ../../rst/cli/ansible-vault.rst:346 ../../rst/cli/ansible.rst:244 -msgid "The following environment variables may be specified." -msgstr "以下の環境変数を指定できます。" - -#: ../../rst/cli/ansible-config.rst:145 ../../rst/cli/ansible-console.rst:244 -#: ../../rst/cli/ansible-doc.rst:127 ../../rst/cli/ansible-galaxy.rst:789 -#: ../../rst/cli/ansible-inventory.rst:155 -#: ../../rst/cli/ansible-playbook.rst:250 ../../rst/cli/ansible-pull.rst:266 -#: ../../rst/cli/ansible-vault.rst:350 ../../rst/cli/ansible.rst:248 -msgid ":envvar:`ANSIBLE_CONFIG` -- Override the default ansible config file" -msgstr ":envvar:`ANSIBLE_CONFIG` -- デフォルトの Ansible 設定ファイルを上書きします" - -#: ../../rst/cli/ansible-config.rst:147 ../../rst/cli/ansible-console.rst:246 -#: ../../rst/cli/ansible-doc.rst:129 ../../rst/cli/ansible-galaxy.rst:791 -#: ../../rst/cli/ansible-inventory.rst:157 -#: ../../rst/cli/ansible-playbook.rst:252 ../../rst/cli/ansible-pull.rst:268 -#: ../../rst/cli/ansible-vault.rst:352 ../../rst/cli/ansible.rst:250 -msgid "Many more are available for most options in ansible.cfg" -msgstr "ansible.cfg のほとんどのオプションで、さらに多くのものが利用できます。" - -#: ../../rst/cli/ansible-config.rst:151 ../../rst/cli/ansible-console.rst:250 -#: ../../rst/cli/ansible-doc.rst:133 ../../rst/cli/ansible-galaxy.rst:795 -#: ../../rst/cli/ansible-inventory.rst:161 -#: ../../rst/cli/ansible-playbook.rst:256 ../../rst/cli/ansible-pull.rst:272 -#: ../../rst/cli/ansible-vault.rst:356 ../../rst/cli/ansible.rst:254 -msgid "Files" -msgstr "ファイル" - -#: ../../rst/cli/ansible-config.rst:154 ../../rst/cli/ansible-console.rst:253 -#: ../../rst/cli/ansible-doc.rst:136 ../../rst/cli/ansible-galaxy.rst:798 -#: ../../rst/cli/ansible-inventory.rst:164 -#: ../../rst/cli/ansible-playbook.rst:259 ../../rst/cli/ansible-pull.rst:275 -#: ../../rst/cli/ansible-vault.rst:359 ../../rst/cli/ansible.rst:257 -msgid ":file:`/etc/ansible/ansible.cfg` -- Config file, used if present" -msgstr ":file:`/etc/ansible/ansible.cfg` -- 存在する場合は使用される設定ファイル。" - -#: ../../rst/cli/ansible-config.rst:156 ../../rst/cli/ansible-console.rst:255 -#: ../../rst/cli/ansible-doc.rst:138 ../../rst/cli/ansible-galaxy.rst:800 -#: ../../rst/cli/ansible-inventory.rst:166 -#: ../../rst/cli/ansible-playbook.rst:261 ../../rst/cli/ansible-pull.rst:277 -#: ../../rst/cli/ansible-vault.rst:361 ../../rst/cli/ansible.rst:259 -msgid ":file:`~/.ansible.cfg` -- User config file, overrides the default config if present" -msgstr ":file:`~/.ansible.cfg` -- 存在する場合はデフォルト設定を上書きするユーザー設定ファイル。" - -#: ../../rst/cli/ansible-config.rst:159 ../../rst/cli/ansible-console.rst:258 -#: ../../rst/cli/ansible-doc.rst:141 ../../rst/cli/ansible-galaxy.rst:803 -#: ../../rst/cli/ansible-inventory.rst:169 -#: ../../rst/cli/ansible-playbook.rst:264 ../../rst/cli/ansible-pull.rst:280 -#: ../../rst/cli/ansible-vault.rst:364 ../../rst/cli/ansible.rst:262 -msgid "Author" -msgstr "作成者" - -#: ../../rst/cli/ansible-config.rst:161 ../../rst/cli/ansible-console.rst:260 -#: ../../rst/cli/ansible-doc.rst:143 ../../rst/cli/ansible-galaxy.rst:805 -#: ../../rst/cli/ansible-inventory.rst:171 -#: ../../rst/cli/ansible-playbook.rst:266 ../../rst/cli/ansible-pull.rst:282 -#: ../../rst/cli/ansible-vault.rst:366 ../../rst/cli/ansible.rst:264 -msgid "Ansible was originally written by Michael DeHaan." -msgstr "Ansible は当初、Michael DeHaan によって記述されました。" - -#: ../../rst/cli/ansible-config.rst:163 ../../rst/cli/ansible-console.rst:262 -#: ../../rst/cli/ansible-doc.rst:145 ../../rst/cli/ansible-galaxy.rst:807 -#: ../../rst/cli/ansible-inventory.rst:173 -#: ../../rst/cli/ansible-playbook.rst:268 ../../rst/cli/ansible-pull.rst:284 -#: ../../rst/cli/ansible-vault.rst:368 ../../rst/cli/ansible.rst:266 -msgid "See the `AUTHORS` file for a complete list of contributors." -msgstr "貢献者の完全な一覧は、`AUTHORS` ファイルを参照してください。" - -#: ../../rst/cli/ansible-config.rst:167 ../../rst/cli/ansible-console.rst:266 -#: ../../rst/cli/ansible-doc.rst:149 ../../rst/cli/ansible-galaxy.rst:811 -#: ../../rst/cli/ansible-inventory.rst:177 -#: ../../rst/cli/ansible-playbook.rst:272 ../../rst/cli/ansible-pull.rst:288 -#: ../../rst/cli/ansible-vault.rst:372 ../../rst/cli/ansible.rst:270 -msgid "License" -msgstr "ライセンス" - -#: ../../rst/cli/ansible-config.rst:169 ../../rst/cli/ansible-console.rst:268 -#: ../../rst/cli/ansible-doc.rst:151 ../../rst/cli/ansible-galaxy.rst:813 -#: ../../rst/cli/ansible-inventory.rst:179 -#: ../../rst/cli/ansible-playbook.rst:274 ../../rst/cli/ansible-pull.rst:290 -#: ../../rst/cli/ansible-vault.rst:374 ../../rst/cli/ansible.rst:272 -msgid "Ansible is released under the terms of the GPLv3+ License." -msgstr "Ansible は、GPLv3 以降のライセンスの対象範囲でリリースされています。" - -#: ../../rst/cli/ansible-config.rst:172 ../../rst/cli/ansible-console.rst:271 -#: ../../rst/cli/ansible-doc.rst:154 ../../rst/cli/ansible-galaxy.rst:816 -#: ../../rst/cli/ansible-inventory.rst:182 -#: ../../rst/cli/ansible-playbook.rst:277 ../../rst/cli/ansible-pull.rst:293 -#: ../../rst/cli/ansible-vault.rst:377 ../../rst/cli/ansible.rst:275 -msgid "See also" -msgstr "参照情報" - -#: ../../rst/cli/ansible-config.rst:174 ../../rst/cli/ansible-console.rst:273 -#: ../../rst/cli/ansible-doc.rst:156 ../../rst/cli/ansible-galaxy.rst:818 -#: ../../rst/cli/ansible-inventory.rst:184 -#: ../../rst/cli/ansible-playbook.rst:279 ../../rst/cli/ansible-pull.rst:295 -#: ../../rst/cli/ansible-vault.rst:379 ../../rst/cli/ansible.rst:277 -msgid ":manpage:`ansible(1)`, :manpage:`ansible-config(1)`, :manpage:`ansible-console(1)`, :manpage:`ansible-doc(1)`, :manpage:`ansible-galaxy(1)`, :manpage:`ansible-inventory(1)`, :manpage:`ansible-playbook(1)`, :manpage:`ansible-pull(1)`, :manpage:`ansible-vault(1)`," -msgstr ":manpage:`ansible(1)`、 :manpage:`ansible-config(1)`、 :manpage:`ansible-console(1)`、 :manpage:`ansible-doc(1)`、 :manpage:`ansible-galaxy(1)`、 :manpage:`ansible-inventory(1)`、 :manpage:`ansible-playbook(1)`、 :manpage:`ansible-pull(1)`、 :manpage:`ansible-vault(1)`" - -#: ../../rst/cli/ansible-config.rst:7 -msgid "ansible-config" -msgstr "ansible-config" - -#: ../../rst/cli/ansible-config.rst:10 -msgid ":strong:`View ansible configuration.`" -msgstr ":strong:`ansible 設定を表示します。`" - -#: ../../rst/cli/ansible-config.rst:33 -msgid "Config command line class" -msgstr "設定コマンドラインクラス" - -#: ../../rst/cli/ansible-config.rst:62 ../../rst/cli/ansible-galaxy.rst:62 -#: ../../rst/cli/ansible-vault.rst:71 -msgid "Actions" -msgstr "アクション" - -#: ../../rst/cli/ansible-config.rst:70 -msgid "list" -msgstr "list" - -#: ../../rst/cli/ansible-config.rst:72 -msgid "list all current configs reading lib/constants.py and shows env and config file setting names" -msgstr "lib/constants.py を読み取る現在の設定の一覧を表示し、env および config ファイルの設定名を表示します。" - -#: ../../rst/cli/ansible-config.rst:80 ../../rst/cli/ansible-config.rst:106 -#: ../../rst/cli/ansible-config.rst:128 -msgid "path to configuration file, defaults to first file found in precedence." -msgstr "設定ファイルへのパス (デフォルトは優先される最初のファイルです)。" - -#: ../../rst/cli/ansible-config.rst:92 -msgid "dump" -msgstr "dump" - -#: ../../rst/cli/ansible-config.rst:94 -msgid "Shows the current settings, merges ansible.cfg if specified" -msgstr "現在の設定を表示し、指定した場合は ansible.cfg をマージします。" - -#: ../../rst/cli/ansible-config.rst:102 -msgid "Only show configurations that have changed from the default" -msgstr "デフォルトから変更した設定のみを表示します。" - -#: ../../rst/cli/ansible-config.rst:118 ../../rst/cli/ansible-vault.rst:181 -msgid "view" -msgstr "view" - -#: ../../rst/cli/ansible-config.rst:120 -msgid "Displays the current config file" -msgstr "現在の設定ファイルを表示します。" - -#: ../../rst/cli/ansible-console.rst:7 -msgid "ansible-console" -msgstr "ansible-console" - -#: ../../rst/cli/ansible-console.rst:10 -msgid ":strong:`REPL console for executing Ansible tasks.`" -msgstr ":strong:`Ansible タスクを実行する REPL コンソール`" - -#: ../../rst/cli/ansible-console.rst:47 -msgid "A REPL that allows for running ad-hoc tasks against a chosen inventory from a nice shell with built-in tab completion (based on dominis' ansible-shell)." -msgstr "(dominis の ansible-shell に基づく) 組み込みのタブ補完機能を備えた優れたシェルから選択したインベントリーに対してアドホックタスクを実行できるようにする REPL。" - -#: ../../rst/cli/ansible-console.rst:51 -msgid "It supports several commands, and you can modify its configuration at runtime:" -msgstr "これは複数のコマンドをサポートし、起動時にその設定を変更できます。" - -#: ../../rst/cli/ansible-console.rst:54 -msgid "`cd [pattern]`: change host/group (you can use host patterns eg.: app*.dc*:!app01*)" -msgstr "`cd [pattern]`: ホスト/グループを変更する (app*.dc*:!app01* などのホストパターンを使用できます)。" - -#: ../../rst/cli/ansible-console.rst:55 -msgid "`list`: list available hosts in the current path" -msgstr "`list`: 現在のパスで利用可能なホストを一覧表示する" - -#: ../../rst/cli/ansible-console.rst:56 -msgid "`list groups`: list groups included in the current path" -msgstr "`list groups`: 現在のパスに含まれるグループを一覧表示する" - -#: ../../rst/cli/ansible-console.rst:57 -msgid "`become`: toggle the become flag" -msgstr "`become`: become フラグを切り替える" - -#: ../../rst/cli/ansible-console.rst:58 -msgid "`!`: forces shell module instead of the ansible module (!yum update -y)" -msgstr "`!`: Ansible モジュールの代わりにシェルモジュールを強制的に実行する (!yum update -y)" - -#: ../../rst/cli/ansible-console.rst:59 -msgid "`verbosity [num]`: set the verbosity level" -msgstr "`verbosity [num]`: 詳細レベルを設定する" - -#: ../../rst/cli/ansible-console.rst:60 -msgid "`forks [num]`: set the number of forks" -msgstr "`forks [num]`: フォークの数を設定する" - -#: ../../rst/cli/ansible-console.rst:61 -msgid "`become_user [user]`: set the become_user" -msgstr "`become_user [user]`: become_user を設定する" - -#: ../../rst/cli/ansible-console.rst:62 -msgid "`remote_user [user]`: set the remote_user" -msgstr "`remote_user [user]`: remote_user を設定する" - -#: ../../rst/cli/ansible-console.rst:63 -msgid "`become_method [method]`: set the privilege escalation method" -msgstr "`become_method [method]`: 権限昇格方法を設定する" - -#: ../../rst/cli/ansible-console.rst:64 -msgid "`check [bool]`: toggle check mode" -msgstr "`check [bool]`: チェックモードを切り替える" - -#: ../../rst/cli/ansible-console.rst:65 -msgid "`diff [bool]`: toggle diff mode" -msgstr "`diff [bool]`: diff モードを切り替える" - -#: ../../rst/cli/ansible-console.rst:66 -msgid "`timeout [integer]`: set the timeout of tasks in seconds (0 to disable)" -msgstr "`timeout [integer]`: タスクのタイムアウトを秒単位で設定する (無効にするには 0)。" - -#: ../../rst/cli/ansible-console.rst:67 -msgid "`help [command/module]`: display documentation for the command or module" -msgstr "`help [command/module]`: コマンドまたはモジュールのドキュメントを表示する" - -#: ../../rst/cli/ansible-console.rst:68 -msgid "`exit`: exit ansible-console" -msgstr "`exit`: ansible-console を終了する" - -#: ../../rst/cli/ansible-console.rst:129 ../../rst/cli/ansible-playbook.rst:135 -msgid "one-step-at-a-time: confirm each task before running" -msgstr "one-step-at-a-time: 実行前に各タスクを確認する" - -#: ../../rst/cli/ansible-doc.rst:7 -msgid "ansible-doc" -msgstr "ansible-doc" - -#: ../../rst/cli/ansible-doc.rst:10 -msgid ":strong:`plugin documentation tool`" -msgstr ":strong:`プラグインドキュメントツール`" - -#: ../../rst/cli/ansible-doc.rst:38 -msgid "displays information on modules installed in Ansible libraries. It displays a terse listing of plugins and their short descriptions, provides a printout of their DOCUMENTATION strings, and it can create a short \"snippet\" which can be pasted into a playbook." -msgstr "Ansible ライブラリーにインストールされているモジュールに関する情報を表示します。プラグインとその簡単な説明を表示し、DOCUMENTATION 文字列を出力します。これにより、Playbook に簡単に張り付けることができる短い「スニペット」を作成できます。" - -#: ../../rst/cli/ansible-doc.rst:52 -msgid "**For internal testing only** Dump json metadata for all plugins." -msgstr "**内部テストのみ** すべてのプラグインの json メタデータをダンプする。" - -#: ../../rst/cli/ansible-doc.rst:67 -msgid "Show plugin names and their source files without summaries (implies --list). A supplied argument will be used for filtering, can be a namespace or full collection name." -msgstr "要約なしでプラグイン名およびソースファイルを表示します (implmaries --list)。指定した引数は、名前空間または完全なコレクション名になります。" - -#: ../../rst/cli/ansible-doc.rst:77 -msgid "Select the entry point for role(s)." -msgstr "ロールのエントリーポイントを選択します。" - -#: ../../rst/cli/ansible-doc.rst:87 -msgid "Change output into json format." -msgstr "出力を json 形式に変更します。" - -#: ../../rst/cli/ansible-doc.rst:92 -msgid "List available plugins. A supplied argument will be used for filtering, can be a namespace or full collection name." -msgstr "利用可能なプラグインを一覧表示します。指定された引数はフィルタリングに使用され、名前空間または完全コレクション名になります。" - -#: ../../rst/cli/ansible-doc.rst:97 -msgid "The path to the directory containing your roles." -msgstr "ロールを含むディレクトリーへのパス。" - -#: ../../rst/cli/ansible-doc.rst:102 -msgid "Show playbook snippet for specified plugin(s)" -msgstr "指定されたプラグインの Playbook スニペットを表示します" - -#: ../../rst/cli/ansible-doc.rst:107 -msgid "Choose which plugin type (defaults to \"module\"). Available plugin types are : ('become', 'cache', 'callback', 'cliconf', 'connection', 'httpapi', 'inventory', 'lookup', 'netconf', 'shell', 'vars', 'module', 'strategy', 'role', 'keyword')" -msgstr "プラグインの種類 (デフォルトは「module」) を選択します。利用可能なプラグインの種類は :(「become」、「cache」、「callback」、「cliconf」、「connection」、「httpapi」、「inventory」、「lookup」、「netconf」、「shell」、「vars」、「module」、「strategy」、「role」、「keyword」) です。" - -#: ../../rst/cli/ansible-galaxy.rst:7 -msgid "ansible-galaxy" -msgstr "ansible-galaxy" - -#: ../../rst/cli/ansible-galaxy.rst:10 -msgid ":strong:`Perform various Role and Collection related operations.`" -msgstr ":strong:`ロールおよびコレクションに関する様々な操作を実行します。`" - -#: ../../rst/cli/ansible-galaxy.rst:33 -msgid "command to manage Ansible roles in shared repositories, the default of which is Ansible Galaxy *https://galaxy.ansible.com*." -msgstr "共有リポジトリーの Ansible ロールを管理するコマンド (デフォルトは Ansible Galaxy *https://galaxy.ansible.com* です)。" - -#: ../../rst/cli/ansible-galaxy.rst:70 -msgid "collection" -msgstr "コレクション" - -#: ../../rst/cli/ansible-galaxy.rst:72 -msgid "Perform the action on an Ansible Galaxy collection. Must be combined with a further action like init/install as listed below." -msgstr "Ansible Galaxy コレクションでアクションを実行します。以下で示すように、init/install などの追加アクションと組み合わせる必要があります。" - -#: ../../rst/cli/ansible-galaxy.rst:84 -msgid "collection download" -msgstr "collection download" - -#: ../../rst/cli/ansible-galaxy.rst:94 ../../rst/cli/ansible-galaxy.rst:265 -msgid "Clear the existing server response cache." -msgstr "既存のサーバーの応答キャッシュを消去します。" - -#: ../../rst/cli/ansible-galaxy.rst:98 ../../rst/cli/ansible-galaxy.rst:273 -msgid "Do not use the server response cache." -msgstr "サーバーの応答キャッシュを使用しないでください。" - -#: ../../rst/cli/ansible-galaxy.rst:102 ../../rst/cli/ansible-galaxy.rst:277 -msgid "Include pre-release versions. Semantic versioning pre-releases are ignored by default" -msgstr "リリース前のバージョンを含めます。セマンティックバージョニングのプレリリースはデフォルトで無視されます" - -#: ../../rst/cli/ansible-galaxy.rst:106 ../../rst/cli/ansible-galaxy.rst:156 -#: ../../rst/cli/ansible-galaxy.rst:195 ../../rst/cli/ansible-galaxy.rst:236 -#: ../../rst/cli/ansible-galaxy.rst:281 ../../rst/cli/ansible-galaxy.rst:338 -#: ../../rst/cli/ansible-galaxy.rst:371 ../../rst/cli/ansible-galaxy.rst:440 -#: ../../rst/cli/ansible-galaxy.rst:477 ../../rst/cli/ansible-galaxy.rst:510 -#: ../../rst/cli/ansible-galaxy.rst:539 ../../rst/cli/ansible-galaxy.rst:584 -#: ../../rst/cli/ansible-galaxy.rst:629 ../../rst/cli/ansible-galaxy.rst:666 -#: ../../rst/cli/ansible-galaxy.rst:703 ../../rst/cli/ansible-galaxy.rst:740 -msgid "The Ansible Galaxy API key which can be found at https://galaxy.ansible.com/me/preferences." -msgstr "https://galaxy.ansible.com/me/preferences で見つかる Ansible Galaxy API キー。" - -#: ../../rst/cli/ansible-galaxy.rst:110 ../../rst/cli/ansible-galaxy.rst:160 -#: ../../rst/cli/ansible-galaxy.rst:199 ../../rst/cli/ansible-galaxy.rst:240 -#: ../../rst/cli/ansible-galaxy.rst:289 ../../rst/cli/ansible-galaxy.rst:342 -#: ../../rst/cli/ansible-galaxy.rst:375 ../../rst/cli/ansible-galaxy.rst:448 -#: ../../rst/cli/ansible-galaxy.rst:481 ../../rst/cli/ansible-galaxy.rst:514 -#: ../../rst/cli/ansible-galaxy.rst:543 ../../rst/cli/ansible-galaxy.rst:588 -#: ../../rst/cli/ansible-galaxy.rst:633 ../../rst/cli/ansible-galaxy.rst:670 -#: ../../rst/cli/ansible-galaxy.rst:707 ../../rst/cli/ansible-galaxy.rst:744 -msgid "Ignore SSL certificate validation errors." -msgstr "SSL 証明書の検証エラーを無視します。" - -#: ../../rst/cli/ansible-galaxy.rst:114 -msgid "Don't download collection(s) listed as dependencies." -msgstr "依存関係としてリストされているコレクションはダウンロードしないでください。" - -#: ../../rst/cli/ansible-galaxy.rst:118 -msgid "The directory to download the collections to." -msgstr "コレクションをダウンロードするディレクトリー。" - -#: ../../rst/cli/ansible-galaxy.rst:122 -msgid "A file containing a list of collections to be downloaded." -msgstr "ダウンロードするコレクションの一覧を含むファイル。" - -#: ../../rst/cli/ansible-galaxy.rst:126 ../../rst/cli/ansible-galaxy.rst:168 -#: ../../rst/cli/ansible-galaxy.rst:207 ../../rst/cli/ansible-galaxy.rst:244 -#: ../../rst/cli/ansible-galaxy.rst:313 ../../rst/cli/ansible-galaxy.rst:350 -#: ../../rst/cli/ansible-galaxy.rst:391 ../../rst/cli/ansible-galaxy.rst:456 -#: ../../rst/cli/ansible-galaxy.rst:489 ../../rst/cli/ansible-galaxy.rst:518 -#: ../../rst/cli/ansible-galaxy.rst:551 ../../rst/cli/ansible-galaxy.rst:592 -#: ../../rst/cli/ansible-galaxy.rst:637 ../../rst/cli/ansible-galaxy.rst:678 -#: ../../rst/cli/ansible-galaxy.rst:715 ../../rst/cli/ansible-galaxy.rst:772 -msgid "The Galaxy API server URL" -msgstr "Galaxy API サーバー URL" - -#: ../../rst/cli/ansible-galaxy.rst:137 -msgid "collection init" -msgstr "collection init" - -#: ../../rst/cli/ansible-galaxy.rst:139 ../../rst/cli/ansible-galaxy.rst:419 -msgid "Creates the skeleton framework of a role or collection that complies with the Galaxy metadata format. Requires a role or collection name. The collection name must be in the format ``.``." -msgstr "Galaxy メタデータ形式に準拠するロールまたはコレクションのスケルトンフレームワークを作成します。ロールまたはコレクション名が必要です。コレクション名は ``.`` の形式にする必要があります。" - -#: ../../rst/cli/ansible-galaxy.rst:148 -msgid "The path to a collection skeleton that the new collection should be based upon." -msgstr "新しいコレクションの基となるコレクションスケルトンへのパス。" - -#: ../../rst/cli/ansible-galaxy.rst:152 -msgid "The path in which the skeleton collection will be created. The default is the current working directory." -msgstr "スケルトンコレクションが作成されるパス。デフォルトは現在の作業ディレクトリーです。" - -#: ../../rst/cli/ansible-galaxy.rst:164 ../../rst/cli/ansible-galaxy.rst:203 -#: ../../rst/cli/ansible-galaxy.rst:293 ../../rst/cli/ansible-galaxy.rst:452 -#: ../../rst/cli/ansible-galaxy.rst:748 -msgid "Force overwriting an existing role or collection" -msgstr "既存のロールまたはコレクションの上書きを強制します。" - -#: ../../rst/cli/ansible-galaxy.rst:179 -msgid "collection build" -msgstr "collection build" - -#: ../../rst/cli/ansible-galaxy.rst:181 -msgid "Build an Ansible Galaxy collection artifact that can be stored in a central repository like Ansible Galaxy. By default, this command builds from the current working directory. You can optionally pass in the collection input path (where the ``galaxy.yml`` file is)." -msgstr "Ansible Galaxy などの中央リポジトリーに格納できる Ansible Galaxy コレクションアーティファクトを構築します。デフォルトでは、このコマンドは現在の作業ディレクトリーから構築されます。必要に応じて、コレクション入力パスを渡すことができます (``galaxy.yml`` ファイルの場所です)。" - -#: ../../rst/cli/ansible-galaxy.rst:191 -msgid "The path in which the collection is built to. The default is the current working directory." -msgstr "コレクションが構築されるパス。デフォルトは現在の作業ディレクトリーです。" - -#: ../../rst/cli/ansible-galaxy.rst:218 -msgid "collection publish" -msgstr "collection publish" - -#: ../../rst/cli/ansible-galaxy.rst:220 -msgid "Publish a collection into Ansible Galaxy. Requires the path to the collection tarball to publish." -msgstr "コレクションを Ansible Galaxy に公開します。公開するには、コレクション tarball へのパスが必要になります。" - -#: ../../rst/cli/ansible-galaxy.rst:228 -msgid "The time to wait for the collection import process to finish." -msgstr "コレクションのインポートプロセスが完了するのを待つ時間。" - -#: ../../rst/cli/ansible-galaxy.rst:232 -msgid "Don't wait for import validation results." -msgstr "インポートの検証結果を待ちません。" - -#: ../../rst/cli/ansible-galaxy.rst:255 -msgid "collection install" -msgstr "collection install" - -#: ../../rst/cli/ansible-galaxy.rst:269 -msgid "Force overwriting an existing collection and its dependencies." -msgstr "既存のコレクションおよびその依存関係を強制的に上書きします。" - -#: ../../rst/cli/ansible-galaxy.rst:285 -msgid "Upgrade installed collection artifacts. This will also update dependencies unless --no-deps is provided" -msgstr "インストールされたコレクションアーティファクトをアップグレードします。--no-deps が提供されている場合を除き依存関係も更新されます。" - -#: ../../rst/cli/ansible-galaxy.rst:297 -msgid "Ignore errors during installation and continue with the next specified collection. This will not ignore dependency conflict errors." -msgstr "インストール時にエラーを無視し、次の指定されたコレクションで続行します。依存関係の競合エラーは無視しません。" - -#: ../../rst/cli/ansible-galaxy.rst:301 -msgid "Don't download collections listed as dependencies." -msgstr "依存関係として一覧表示されているコレクションはダウンロードしないでください。" - -#: ../../rst/cli/ansible-galaxy.rst:305 -msgid "The path to the directory containing your collections." -msgstr "コレクションを含むディレクトリーへのパス。" - -#: ../../rst/cli/ansible-galaxy.rst:309 -msgid "A file containing a list of collections to be installed." -msgstr "インストールするコレクションの一覧を含むファイル。" - -#: ../../rst/cli/ansible-galaxy.rst:324 -msgid "collection list" -msgstr "collection list" - -#: ../../rst/cli/ansible-galaxy.rst:326 ../../rst/cli/ansible-galaxy.rst:531 -msgid "List installed collections or roles" -msgstr "インストール済みのコレクションまたはロールを一覧表示します。" - -#: ../../rst/cli/ansible-galaxy.rst:334 -msgid "Format to display the list of collections in." -msgstr "コレクションの一覧を表示する形式。" - -#: ../../rst/cli/ansible-galaxy.rst:346 ../../rst/cli/ansible-galaxy.rst:383 -msgid "One or more directories to search for collections in addition to the default COLLECTIONS_PATHS. Separate multiple paths with ':'." -msgstr "デフォルトの COLLECTIONS_PATHS に加えて、コレクションを検索する 1 つ以上のディレクトリー。複数のパスは、「:」で区切ります。" - -#: ../../rst/cli/ansible-galaxy.rst:361 -msgid "collection verify" -msgstr "collection verify" - -#: ../../rst/cli/ansible-galaxy.rst:379 -msgid "Ignore errors during verification and continue with the next specified collection." -msgstr "検証時のエラーを無視し、次の指定されたコレクションで続行します。" - -#: ../../rst/cli/ansible-galaxy.rst:387 -msgid "A file containing a list of collections to be verified." -msgstr "検証するコレクションの一覧を含むファイル。" - -#: ../../rst/cli/ansible-galaxy.rst:403 -msgid "role" -msgstr "ロール" - -#: ../../rst/cli/ansible-galaxy.rst:405 -msgid "Perform the action on an Ansible Galaxy role. Must be combined with a further action like delete/install/init as listed below." -msgstr "Ansible Galaxy ロールで操作を実行します。以下のように delete/install/init などのアクションと組み合わせる必要があります。" - -#: ../../rst/cli/ansible-galaxy.rst:417 -msgid "role init" -msgstr "role init" - -#: ../../rst/cli/ansible-galaxy.rst:428 -msgid "The path in which the skeleton role will be created. The default is the current working directory." -msgstr "スケルトンロールが作成されるパス。デフォルトは現在の作業ディレクトリーです。" - -#: ../../rst/cli/ansible-galaxy.rst:432 ../../rst/cli/ansible-galaxy.rst:699 -msgid "Don't query the galaxy API when creating roles" -msgstr "ロールの作成時に galaxy API にクエリーを実行しないでください。" - -#: ../../rst/cli/ansible-galaxy.rst:436 -msgid "The path to a role skeleton that the new role should be based upon." -msgstr "新しいロールの基となるロールスケルトンへのパス。" - -#: ../../rst/cli/ansible-galaxy.rst:444 -msgid "Initialize using an alternate role type. Valid types include: 'container', 'apb' and 'network'." -msgstr "別のロールタイプを使用して初期化します。有効なタイプには、「container」、「apb」、および「network」が含まれます。" - -#: ../../rst/cli/ansible-galaxy.rst:467 -msgid "role remove" -msgstr "role remove" - -#: ../../rst/cli/ansible-galaxy.rst:469 -msgid "removes the list of roles passed as arguments from the local system." -msgstr "ローカルシステムから引数として渡されたロールの一覧を削除します。" - -#: ../../rst/cli/ansible-galaxy.rst:485 ../../rst/cli/ansible-galaxy.rst:547 -#: ../../rst/cli/ansible-galaxy.rst:674 ../../rst/cli/ansible-galaxy.rst:711 -#: ../../rst/cli/ansible-galaxy.rst:764 -msgid "The path to the directory containing your roles. The default is the first writable one configured via DEFAULT_ROLES_PATH: ~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles" -msgstr "ロールを含むディレクトリーへのパスです。デフォルトは DEFAULT_ROLES_PATH: ~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles で設定される最初の書き込み可能なファイルです。" - -#: ../../rst/cli/ansible-galaxy.rst:500 -msgid "role delete" -msgstr "role delete" - -#: ../../rst/cli/ansible-galaxy.rst:502 -msgid "Delete a role from Ansible Galaxy." -msgstr "Ansible Galaxy からロールを削除します。" - -#: ../../rst/cli/ansible-galaxy.rst:529 -msgid "role list" -msgstr "role list" - -#: ../../rst/cli/ansible-galaxy.rst:562 -msgid "role search" -msgstr "role search" - -#: ../../rst/cli/ansible-galaxy.rst:564 -msgid "searches for roles on the Ansible Galaxy server" -msgstr "Ansible Galaxy サーバーでロールを検索します。" - -#: ../../rst/cli/ansible-galaxy.rst:572 -msgid "GitHub username" -msgstr "GitHub ユーザー名" - -#: ../../rst/cli/ansible-galaxy.rst:576 -msgid "list of galaxy tags to filter by" -msgstr "フィルタリングする galaxy タグの一覧を表示します。" - -#: ../../rst/cli/ansible-galaxy.rst:580 -msgid "list of OS platforms to filter by" -msgstr "フィルタリングする OS プラットフォームの一覧を表示します。" - -#: ../../rst/cli/ansible-galaxy.rst:603 -msgid "role import" -msgstr "role import" - -#: ../../rst/cli/ansible-galaxy.rst:605 -msgid "used to import a role into Ansible Galaxy" -msgstr "Ansible Galaxy にロールをインポートするのに使用します。" - -#: ../../rst/cli/ansible-galaxy.rst:613 -msgid "The name of a branch to import. Defaults to the repository's default branch (usually master)" -msgstr "インポートするブランチの名前。デフォルトではリポジトリーのデフォルトブランチ (通常は master) に設定されます。" - -#: ../../rst/cli/ansible-galaxy.rst:617 -msgid "Don't wait for import results." -msgstr "インポートの結果を待ちません。" - -#: ../../rst/cli/ansible-galaxy.rst:621 -msgid "The name the role should have, if different than the repo name" -msgstr "ロールに付与すべき名前 (リポジトリー名とは異なる場合)" - -#: ../../rst/cli/ansible-galaxy.rst:625 -msgid "Check the status of the most recent import request for given github_user/github_repo." -msgstr "指定した github_user/github_repo の、最新のインポート要求ステータスを確認します。" - -#: ../../rst/cli/ansible-galaxy.rst:648 -msgid "role setup" -msgstr "role setup" - -#: ../../rst/cli/ansible-galaxy.rst:650 -msgid "Setup an integration from Github or Travis for Ansible Galaxy roles" -msgstr "Ansible Galaxy ロールの Github または Travis からの統合を設定します。" - -#: ../../rst/cli/ansible-galaxy.rst:658 -msgid "List all of your integrations." -msgstr "すべての統合の一覧を表示します。" - -#: ../../rst/cli/ansible-galaxy.rst:662 -msgid "Remove the integration matching the provided ID value. Use --list to see ID values." -msgstr "指定の ID 値に一致するインテグレーションを削除します。ID の値を表示するには --list を使用します。" - -#: ../../rst/cli/ansible-galaxy.rst:689 -msgid "role info" -msgstr "role info" - -#: ../../rst/cli/ansible-galaxy.rst:691 -msgid "prints out detailed information about an installed role as well as info available from the galaxy API." -msgstr "インストールされているロールに関する詳細情報と、galaxy API で利用可能な情報を出力します。" - -#: ../../rst/cli/ansible-galaxy.rst:726 -msgid "role install" -msgstr "role install" - -#: ../../rst/cli/ansible-galaxy.rst:736 -msgid "Force overwriting an existing role and its dependencies." -msgstr "既存のロールとその依存関係を強制的に上書きします。" - -#: ../../rst/cli/ansible-galaxy.rst:752 -msgid "Use tar instead of the scm archive option when packaging the role." -msgstr "ロールをパッケージ化する際に、scm アーカイブオプションの代わりに tar を使用します。" - -#: ../../rst/cli/ansible-galaxy.rst:756 -msgid "Ignore errors and continue with the next specified role." -msgstr "エラーを無視して、次に指定したロールで続行します。" - -#: ../../rst/cli/ansible-galaxy.rst:760 -msgid "Don't download roles listed as dependencies." -msgstr "依存関係としてリストされているロールはダウンロードしないでください。" - -#: ../../rst/cli/ansible-galaxy.rst:768 -msgid "A file containing a list of roles to be installed." -msgstr "インストールするロールの一覧を含むファイル。" - -#: ../../rst/cli/ansible-inventory.rst:7 -msgid "ansible-inventory" -msgstr "ansible-inventory" - -#: ../../rst/cli/ansible-inventory.rst:10 -msgid ":strong:`None`" -msgstr ":strong:`None`" - -#: ../../rst/cli/ansible-inventory.rst:39 -msgid "used to display or dump the configured inventory as Ansible sees it" -msgstr "Ansible が認識しているように、設定したインベントリーを表示またはダンプするために使用します。" - -#: ../../rst/cli/ansible-inventory.rst:55 -msgid "When doing an --list, represent in a way that is optimized for export,not as an accurate representation of how Ansible has processed it" -msgstr "--list を実行する場合は、Ansible が処理する方法を正確に示すのではなく、エクスポート用に最適化される方法を示します。" - -#: ../../rst/cli/ansible-inventory.rst:60 -msgid "create inventory graph, if supplying pattern it must be a valid group name" -msgstr "インベントリーグラフを作成します (パターンを指定している場合は、有効なグループ名である必要があります)。" - -#: ../../rst/cli/ansible-inventory.rst:65 -msgid "Output specific host info, works as inventory script" -msgstr "特定のホスト情報を出力します (インベントリースクリプトとして機能します)。" - -#: ../../rst/cli/ansible-inventory.rst:70 -msgid "Output all hosts info, works as inventory script" -msgstr "全ホスト情報出力します (インベントリースクリプトとして機能します)。" - -#: ../../rst/cli/ansible-inventory.rst:75 -#: ../../rst/cli/ansible-inventory.rst:130 -msgid "==SUPPRESS==" -msgstr "==SUPPRESS==" - -#: ../../rst/cli/ansible-inventory.rst:80 -msgid "When doing --list, send the inventory to a file instead of to the screen" -msgstr "--list を実行する場合は、画面の代わりにインベントリーをファイルに送信します。" - -#: ../../rst/cli/ansible-inventory.rst:90 -msgid "Use TOML format instead of default JSON, ignored for --graph" -msgstr "デフォルトの JSON の代わりに TOML 形式を使用します (--graph では無視されます)。" - -#: ../../rst/cli/ansible-inventory.rst:95 -msgid "Add vars to graph display, ignored unless used with --graph" -msgstr "グラフ表示に変数を追加します。--graph と併用しない限り無視されます。" - -#: ../../rst/cli/ansible-inventory.rst:140 -msgid "Use YAML format instead of default JSON, ignored for --graph" -msgstr "デフォルトの JSON の代わりに YAML 形式を使用します。--graph は無視されます。" - -#: ../../rst/cli/ansible-playbook.rst:7 -msgid "ansible-playbook" -msgstr "ansible-playbook" - -#: ../../rst/cli/ansible-playbook.rst:10 -msgid ":strong:`Runs Ansible playbooks, executing the defined tasks on the targeted hosts.`" -msgstr ":strong:`ターゲットのホストで定義したタスクを実行して Ansible Playbook を実行します。`" - -#: ../../rst/cli/ansible-playbook.rst:48 -msgid "the tool to run *Ansible playbooks*, which are a configuration and multinode deployment system. See the project home page (https://docs.ansible.com) for more information." -msgstr "設定およびマルチノードのデプロイメントシステムである *Ansible Playbook* を実行するツール。詳細はプロジェクトのホームページ (https://docs.ansible.com)) を参照してください。" - -#: ../../rst/cli/ansible-playbook.rst:75 -msgid "clear the fact cache for every host in inventory" -msgstr "インベントリー内のすべてのホストのファクトキャッシュを消去します。" - -#: ../../rst/cli/ansible-playbook.rst:80 -msgid "run handlers even if a task fails" -msgstr "タスクが失敗してもハンドラーを実行する" - -#: ../../rst/cli/ansible-playbook.rst:90 -msgid "list all available tags" -msgstr "利用可能なタグをすべて表示する" - -#: ../../rst/cli/ansible-playbook.rst:95 -msgid "list all tasks that would be executed" -msgstr "実行するタスクをすべて表示する" - -#: ../../rst/cli/ansible-playbook.rst:115 ../../rst/cli/ansible-pull.rst:121 -msgid "only run plays and tasks whose tags do not match these values" -msgstr "タグがこれらの値と一致しないプレイとタスクのみを実行する" - -#: ../../rst/cli/ansible-playbook.rst:130 -msgid "start the playbook at the task matching this name" -msgstr "この名前に一致するタスクで Playbook を開始する" - -#: ../../rst/cli/ansible-playbook.rst:225 ../../rst/cli/ansible-pull.rst:241 -msgid "only run plays and tasks tagged with these values" -msgstr "それらの値でタグ付けされたプレイとタスクのみを実行する" - -#: ../../rst/cli/ansible-pull.rst:7 -msgid "ansible-pull" -msgstr "ansible-pull" - -#: ../../rst/cli/ansible-pull.rst:10 -msgid ":strong:`pulls playbooks from a VCS repo and executes them for the local host`" -msgstr ":strong:`VCS リポジトリーから Playbooks を取得し、ローカルホストで実行します。`" - -#: ../../rst/cli/ansible-pull.rst:47 -msgid "Used to pull a remote copy of ansible on each managed node, each set to run via cron and update playbook source via a source repository. This inverts the default *push* architecture of ansible into a *pull* architecture, which has near-limitless scaling potential." -msgstr "各管理対象ノードで ansible のリモートコピーを取得するのに使用されます。各セットは cron を介して実行され、ソースリポジトリーを介して Playbook ソースを更新します。これにより、ansible のデフォルトの *push* アーキテクチャーが *pull* アーキテクチャーに反転します。これには、スケーリングの可能性がほぼ無限あります。" - -#: ../../rst/cli/ansible-pull.rst:52 -msgid "The setup playbook can be tuned to change the cron frequency, logging locations, and parameters to ansible-pull. This is useful both for extreme scale-out as well as periodic remediation. Usage of the 'fetch' module to retrieve logs from ansible-pull runs would be an excellent way to gather and analyze remote logs from ansible-pull." -msgstr "セットアップ Playbook は、cron 頻度、ロギングの場所、およびパラメーターを ansible-pull に変更します。これは、急なスケールアウトと定期的な修復にも便利です。ansible-pull からログを取得するために「fetch」モジュールを使用することは、ansible-pull からログを収集し、分析するための優れた方法です。" - -#: ../../rst/cli/ansible-pull.rst:66 -msgid "adds the hostkey for the repo url if not already added" -msgstr "リポジトリー URL のホストキーが追加されていない場合はホストキーを追加する" - -#: ../../rst/cli/ansible-pull.rst:81 -msgid "modified files in the working repository will be discarded" -msgstr "作業リポジトリー内の変更されたファイルは破棄される" - -#: ../../rst/cli/ansible-pull.rst:91 -msgid "Do a full clone, instead of a shallow one." -msgstr "簡易クローンではなく、完全なクローンを実行します。" - -#: ../../rst/cli/ansible-pull.rst:106 -msgid "purge checkout after playbook run" -msgstr "Playbook の実行後にチェックアウトをパージする" - -#: ../../rst/cli/ansible-pull.rst:136 -msgid "submodules will track the latest changes. This is equivalent to specifying the --remote flag to git submodule update" -msgstr "サブモジュールでは最新の変更を追跡します。これは、--remote フラグを git サブモジュール更新に指定するのと同じです。" - -#: ../../rst/cli/ansible-pull.rst:151 -msgid "verify GPG signature of checked out commit, if it fails abort running the playbook. This needs the corresponding VCS module to support such an operation" -msgstr "チェックアウトしたコミットの GPG 署名を確認します。Playbook の実行を中断できない場合に、このような操作をサポートするには、対応する VCS モジュールが必要になります。" - -#: ../../rst/cli/ansible-pull.rst:161 -msgid "branch/tag/commit to checkout. Defaults to behavior of repository module." -msgstr "チェックアウトするブランチ、タグ、またはコミット。デフォルトは、リポジトリーモジュールの動作です。" - -#: ../../rst/cli/ansible-pull.rst:181 -msgid "URL of the playbook repository" -msgstr "Playbook リポジトリーの URL" - -#: ../../rst/cli/ansible-pull.rst:191 -msgid "directory to checkout repository to" -msgstr "リポジトリーをチェックアウトするディレクトリー" - -#: ../../rst/cli/ansible-pull.rst:201 -msgid "run the playbook even if the repository could not be updated" -msgstr "リポジトリーを更新できなかった場合でも、Playbook を実行します。" - -#: ../../rst/cli/ansible-pull.rst:226 -msgid "Repository module name, which ansible will use to check out the repo. Choices are ('git', 'subversion', 'hg', 'bzr'). Default is git." -msgstr "Ansible がリポジトリーをチェックアウトするのに使用するリポジトリーモジュール名 (「git」、「subversion」、「hg」、「bzr」)。デフォルトは git です。" - -#: ../../rst/cli/ansible-pull.rst:231 -msgid "only run the playbook if the repository has been updated" -msgstr "リポジトリーが更新されている場合にのみ Playbook を実行します。" - -#: ../../rst/cli/ansible-pull.rst:236 -msgid "sleep for random interval (between 0 and n number of seconds) before starting. This is a useful way to disperse git requests" -msgstr "開始前のランダムな間隔 (0 ～ n 秒間) をスリープ状態にします。これは、git 要求を分散させるための便利な方法です。" - -#: ../../rst/cli/ansible-vault.rst:7 -msgid "ansible-vault" -msgstr "ansible-vault" - -#: ../../rst/cli/ansible-vault.rst:10 -msgid ":strong:`encryption/decryption utility for Ansible data files`" -msgstr ":strong:`Ansible データファイルの暗号化/複合ユーティリティー`" - -#: ../../rst/cli/ansible-vault.rst:35 -msgid "can encrypt any structured data file used by Ansible. This can include *group_vars/* or *host_vars/* inventory variables, variables loaded by *include_vars* or *vars_files*, or variable files passed on the ansible-playbook command line with *-e @file.yml* or *-e @file.json*. Role variables and defaults are also included!" -msgstr "Ansible が使用する構造化データファイルをすべて暗号化できます。これには、インベントリー変数 *group_vars/* または *host_vars/*、*include_vars* または *vars_files* で読み込まれる変数、*-e @file.yml* または *-e @file.json* を使用して ansible-playbook コマンドラインで渡される変数ファイルが含まれます。ロールの変数およびデフォルトも含まれます。" - -#: ../../rst/cli/ansible-vault.rst:41 -msgid "Because Ansible tasks, handlers, and other objects are data, these can also be encrypted with vault. If you'd like to not expose what variables you are using, you can keep an individual task file entirely encrypted." -msgstr "Ansible タスク、ハンドラー、およびその他のオブジェクトはデータであるため、Vault で暗号化することもできます。使用している変数を公開しない場合は、個別のタスクファイルを完全に暗号化できます。" - -#: ../../rst/cli/ansible-vault.rst:79 -msgid "create" -msgstr "create" - -#: ../../rst/cli/ansible-vault.rst:81 -msgid "create and open a file in an editor that will be encrypted with the provided vault secret when closed" -msgstr "閉じたときに提供される Vault シークレットで暗号化されるファイルを作成してエディターで開きます" - -#: ../../rst/cli/ansible-vault.rst:93 ../../rst/cli/ansible-vault.rst:161 -#: ../../rst/cli/ansible-vault.rst:225 ../../rst/cli/ansible-vault.rst:263 -#: ../../rst/cli/ansible-vault.rst:317 -msgid "the vault id used to encrypt (required if more than one vault-id is provided)" -msgstr "暗号化に使用する Vault ID (複数の vault-id が指定されている場合に必要)" - -#: ../../rst/cli/ansible-vault.rst:113 -msgid "decrypt" -msgstr "decrypt" - -#: ../../rst/cli/ansible-vault.rst:115 -msgid "decrypt the supplied file using the provided vault secret" -msgstr "提供された Vault シークレットを使用して提供されたファイルを復号します。" - -#: ../../rst/cli/ansible-vault.rst:127 ../../rst/cli/ansible-vault.rst:229 -#: ../../rst/cli/ansible-vault.rst:267 -msgid "output file name for encrypt or decrypt; use - for stdout" -msgstr "暗号化用または復号用の出力ファイル名。標準出力 (stdout) に - を使用します。" - -#: ../../rst/cli/ansible-vault.rst:147 -msgid "edit" -msgstr "edit" - -#: ../../rst/cli/ansible-vault.rst:149 -msgid "open and decrypt an existing vaulted file in an editor, that will be encrypted again when closed" -msgstr "エディターで既存の Vault ファイルを開き、復号します。これは、閉じると再度暗号化されます。" - -#: ../../rst/cli/ansible-vault.rst:183 -msgid "open, decrypt and view an existing vaulted file using a pager using the supplied vault secret" -msgstr "提供された Vault シークレットを使用するページャーを使用して、既存の Vault ファイルを開き、復号し、表示します。" - -#: ../../rst/cli/ansible-vault.rst:211 -msgid "encrypt" -msgstr "encrypt" - -#: ../../rst/cli/ansible-vault.rst:213 -msgid "encrypt the supplied file using the provided vault secret" -msgstr "提供される Vault シークレットを使用して提供されたファイルを暗号化します。" - -#: ../../rst/cli/ansible-vault.rst:249 -msgid "encrypt_string" -msgstr "encrypt_string" - -#: ../../rst/cli/ansible-vault.rst:251 -msgid "encrypt the supplied string using the provided vault secret" -msgstr "提供された Vault シークレットを使用して提供された文字列を暗号化します。" - -#: ../../rst/cli/ansible-vault.rst:271 -msgid "Do not hide input when prompted for the string to encrypt" -msgstr "文字列の暗号化を要求したときに入力を非表示にしない" - -#: ../../rst/cli/ansible-vault.rst:275 -msgid "Specify the variable name for stdin" -msgstr "stdin の変数名を指定する" - -#: ../../rst/cli/ansible-vault.rst:287 -msgid "Specify the variable name" -msgstr "変数名を指定する" - -#: ../../rst/cli/ansible-vault.rst:291 -msgid "Prompt for the string to encrypt" -msgstr "暗号化する文字列を入力する" - -#: ../../rst/cli/ansible-vault.rst:303 -msgid "rekey" -msgstr "rekey" - -#: ../../rst/cli/ansible-vault.rst:305 -msgid "re-encrypt a vaulted file with a new secret, the previous secret is required" -msgstr "新規シークレットと共に Vault ファイルを再暗号化します。以前のシークレットが必要です。" - -#: ../../rst/cli/ansible-vault.rst:321 -msgid "the new vault identity to use for rekey" -msgstr "rekey に使用する新しい vault アイデンティティー" - -#: ../../rst/cli/ansible-vault.rst:325 -msgid "new vault password file for rekey" -msgstr "rekey の新しい Vault パスワードファイル" - -#~ msgid "a REPL that allows for running ad-hoc tasks against a chosen inventory (based on dominis' ansible-shell)." -#~ msgstr "" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/collections.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/collections.po deleted file mode 100644 index 1165075de6e..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/collections.po +++ /dev/null @@ -1,26 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-03-01 12:38+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/collections/all_plugins.rst:6 -msgid "Plugin indexes" -msgstr "プラグインインデックス" - -#: ../../rst/collections/all_plugins.rst:4 -msgid "Indexes of all modules and plugins" -msgstr "すべてのモジュールおよびプラグインのインデックス" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/community.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/community.po deleted file mode 100644 index 49f9724de24..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/community.po +++ /dev/null @@ -1,2750 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-02-23 10:50+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/community/code_of_conduct.rst:5 -msgid "Community Code of Conduct" -msgstr "コミュニティーの行動規範" - -#: ../../rst/community/code_of_conduct.rst:7 -#: ../../rst/community/github_admins.rst:7 -#: ../../rst/community/release_managers.rst:7 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/community/code_of_conduct.rst:9 -msgid "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." -msgstr "すべてのコミュニティーは、多様な視点、洞察力、意見、スキルセット、スキルレベルの多様性によって強化されます。しかし、多様性には、意見の相違や誤解が生じる可能性があります。この行動規範の目的は、意見の不一致や相違が、個人的な攻撃やその他の不安定な環境や歓迎されない環境を作り出すような行動をせずに、敬意を持って、各自の利点に基づいて行われるようにすることです。" - -#: ../../rst/community/code_of_conduct.rst:16 -msgid "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." -msgstr "これらの方針は、「やってはいけないこと」を網羅したものではありません。コミュニティーメンバーに敬意と礼儀をもって接し、不快な行動はしないことをお願いしています。この行動規範は、心構えをできる限り示すことを目的としており、すべてを網羅しているわけではありません。" - -#: ../../rst/community/code_of_conduct.rst:21 -msgid "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 IRC channels, private correspondence, and public meetings." -msgstr "Ansible イベントとその参加者はすべて、この行動規範とハラスメント防止ポリシーに従う必要があります。主催者は、常にこのガイドラインに沿ってイベントを開催することが期待されます。また、参加者、講演者、スポンサー、およびボランティアの皆様には、コミュニティー全体の安全な環境を確保するためにご協力いただくことが期待されます。具体的には、この行動規範は、Ansible 関連のフォーラムやメーリングリストへの参加、コードやドキュメントへの貢献、公開 IRC チャンネルへの参加、プライベートなやり取り、公開会議への参加が対象となります。" - -#: ../../rst/community/code_of_conduct.rst:28 -msgid "Ansible community members are..." -msgstr "Ansible コミュニティーのメンバーには、以下が期待されます。" - -#: ../../rst/community/code_of_conduct.rst:30 -msgid "**Considerate**" -msgstr "**思いやりをもつ**" - -#: ../../rst/community/code_of_conduct.rst:32 -msgid "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." -msgstr "あらゆる種類の貢献が、広範囲に影響します。自分の仕事が他の人の仕事に依存しているのと同じように、Ansible コミュニティーへの貢献についてあなたが下した決定は、コミュニティーメンバーに影響します。意思決定を行う際には、このような結果を考慮に入れることが強く推奨されます。" - -#: ../../rst/community/code_of_conduct.rst:37 -msgid "**Patient**" -msgstr "**寛大になる**" - -#: ../../rst/community/code_of_conduct.rst:39 -msgid "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." -msgstr "非同期のコミュニケーションは、どんなに反応の良いコミュニティーであっても、ある程度はフラストレーションが溜まってしまうことがあります。コミュニティーは主にボランティアの時間で成り立っていることを覚えておいてください。質問、貢献、サポートのリクエストには返事が返ってくるまでに時間がかかることがあります。何度も「スレッド作成 (bump)」や「リマインダー」を繰り返すのは、忍耐力を示す優れた方法ではありません。さらに、一般的な質問を特定の人にするのはマナー違反です。コミュニティー全体に向けて質問し、辛抱強く返事を待ちましょう。" - -#: ../../rst/community/code_of_conduct.rst:47 -msgid "**Respectful**" -msgstr "**相手を尊重する**" - -#: ../../rst/community/code_of_conduct.rst:49 -msgid "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." -msgstr "どのようなコミュニティーでも意見の相違は避けられませんが、異議を唱えるときは敬意を持って礼儀正しく行う必要があることを覚えておいてください。意見の相違は、失礼、敵意、脅迫、(言葉によるまたは身体的な) 虐待、または個人的な攻撃の言い訳にはなりません。" - -#: ../../rst/community/code_of_conduct.rst:53 -msgid "**Kind**" -msgstr "**親切にする**" - -#: ../../rst/community/code_of_conduct.rst:55 -msgid "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." -msgstr "Ansible コミュニティーでは、各自の経歴に関係なく誰もが歓迎されていると感じるようにならなければなりません。コミュニティーメンバーに対しては、礼儀正しく、敬意を払って接してください。スキルレベル、性別、性自認、性表現、性的指向、障害、容姿、体格、人種、宗教に関する攻撃的なコメントをしたり、投稿したりしないでください。性的画像、明示的または暗示的な暴力、脅迫、抑圧、ストーカー行為、継続的な活動妨害、明示的な許可なく個人情報の公開、望まれない身体的接触、歓迎されない性的注目は、すべて固く禁じられています。さらに、コミュニティーメンバーの経歴や身元を推測しないようにしてください。" - -#: ../../rst/community/code_of_conduct.rst:65 -msgid "**Inquisitive**" -msgstr "**探求心を持つ**" - -#: ../../rst/community/code_of_conduct.rst:67 -msgid "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 IRC channels - instead use gist.github.com or another paste site to provide code snippets." -msgstr "取るに足らない質問とは、質問されない質問だけです。コミュニティーメンバーは、早めに、そして頻繁に質問することが推奨されます。質問ができるかどうかを尋ねるのではなく (その答えは常にイエスとなるため)、質問したい内容を尋ねてください。できるだけ具体的な情報を提供することが推奨されます。最も有益な回答を得るには、Gist などのサイトへ抜粋したコードを貼り付け、そのリンクを示してください。つまり、IRC チャンネルに、複数行のコードを直接貼り付けず、代わりに gist.github.com などのサイトに該当のコードを貼り付けて、そのサイトへのリンクを示してください。" - -#: ../../rst/community/code_of_conduct.rst:75 -msgid "**Helpful**" -msgstr "**助けになること**" - -#: ../../rst/community/code_of_conduct.rst:77 -msgid "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." -msgstr "Ansible コミュニティーは、スキルレベルに関係なく、誰にとっても歓迎されていると感じる環境であることをお約束します。すべての人は皆、最初は初心者でした。新しいユーザーが安心して質問できる環境でなければコミュニティーは成長しません。同じ質問に何度も答えることにもどかしさを感じることもありますが、スキルや知識のレベルに関係なく、すべてのユーザーに対して平等に礼儀正しく、親切に対応することが求められます。有益な情報よりも、中傷や悪口を優先するような回答は避けてください。同時に、全てのメンバーが、提供された文書を十分に読むことが期待されています。コミュニティーメンバーは、質問に答えたり、戦略的なガイダンスを提供したり、効果的なワークフローを提案したりすることは喜んで行いますが、質問者の代わりに作業をするために存在しているわけではありません。" - -#: ../../rst/community/code_of_conduct.rst:88 -msgid "Anti-harassment policy" -msgstr "ハラスメント防止ポリシー" - -#: ../../rst/community/code_of_conduct.rst:90 -msgid "Harassment includes (but is not limited to) all of the following behaviors:" -msgstr "ハラスメントには、以下のすべての行為が含まれます (ただし、これに限定されません)。" - -#: ../../rst/community/code_of_conduct.rst:92 -msgid "Offensive comments related to gender (including gender expression and identity), age, sexual orientation, disability, physical appearance, body size, race, and religion" -msgstr "性別 (性表現や性自認を含む)、年齢、性的指向、障害、容姿、体格、人種、宗教に関する攻撃的なコメント" - -#: ../../rst/community/code_of_conduct.rst:93 -msgid "Derogatory terminology including words commonly known to be slurs" -msgstr "一般的に中傷であると知られている言葉を含む中傷的な用語" - -#: ../../rst/community/code_of_conduct.rst:94 -msgid "Posting sexualized images or imagery in public spaces" -msgstr "公共の場に性的な画像を投稿すること" - -#: ../../rst/community/code_of_conduct.rst:95 -msgid "Deliberate intimidation" -msgstr "意図的な脅迫" - -#: ../../rst/community/code_of_conduct.rst:96 -msgid "Stalking" -msgstr "ストーカー行為" - -#: ../../rst/community/code_of_conduct.rst:97 -msgid "Posting others' personal information without explicit permission" -msgstr "明示的な許可なく他のユーザーの個人情報を投稿すること" - -#: ../../rst/community/code_of_conduct.rst:98 -msgid "Sustained disruption of talks or other events" -msgstr "会話やその他のイベントの継続的な中断" - -#: ../../rst/community/code_of_conduct.rst:99 -msgid "Inappropriate physical contact" -msgstr "不適切な身体的接触" - -#: ../../rst/community/code_of_conduct.rst:100 -msgid "Unwelcome sexual attention" -msgstr "歓迎されない性的注目" - -#: ../../rst/community/code_of_conduct.rst:102 -msgid "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." -msgstr "ハラスメント行為を止めるように求められた参加者は、直ちにこれに応じることが求められます。スポンサーも、ハラスメント防止ポリシーの対象となります。特に、スポンサーは性的な画像、活動、その他の素材を使用してはなりません。また、Meetup の主催者やボランティアスタッフは、コミュニティーイベントで性的な恰好をしたり、性的な環境を作らないようにする必要があります。" - -#: ../../rst/community/code_of_conduct.rst:108 -msgid "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." -msgstr "上記の行動に加えて、ここで明記されていなくても、やめるように言われた後にそのような行動を続けることも、ハラスメントに該当します。やめるように言われた後に何かをやめることは、思いやりと敬意を表す行動であり、コミュニティーの全メンバーは、そのような要求に直ちに従うことが求められます。" - -#: ../../rst/community/code_of_conduct.rst:115 -msgid "Policy violations" -msgstr "ポリシー違反" - -#: ../../rst/community/code_of_conduct.rst:117 -msgid "Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting `codeofconduct@ansible.com `_, to any channel operator in the community IRC channels, 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." -msgstr "虐待、嫌がらせ、その他の容認できない行為があった場合は、`codeofconduct@ansible.com `_ や、コミュニティーの IRC チャンネルのチャンネル運営者、各地のイベント主催者に連絡してください。Meetup の主催者は、各地のイベントで容認されない行動を報告する連絡先を目立つところに表示することが推奨されます。" - -#: ../../rst/community/code_of_conduct.rst:123 -msgid "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." -msgstr "Meetup 主催者は、参加者が嫌がらせ行為を行った場合、適切と思われる措置を取ることができます。このような措置には、加害者への警告、イベントからの退出を求めること、今後のコミュニティーイベントへの参加禁止などが含まれますが、これらに限定されません。" - -#: ../../rst/community/code_of_conduct.rst:128 -msgid "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." -msgstr "主催者は、ハラスメントを経験した人が Meetup の間安心して過ごせるように、参加者が警備員や地元の警察に連絡したり、別の場所に案内したりなど支援します。コミュニティーは、コミュニティーメンバーの安全と幸福を大切にし、オンラインとオフラインの両方で開催されるイベントですべての人が歓迎されていると感じてほしいと願っています。" - -#: ../../rst/community/code_of_conduct.rst:134 -msgid "We expect all participants, organizers, speakers, and attendees to follow these policies at all of our event venues and event-related social events." -msgstr "すべての参加者、主催者、講演者、参加者は、コミュニティーのイベント会場およびイベント関連のソーシャルイベントにおいて、これらのポリシーに従うことを期待しています。" - -#: ../../rst/community/code_of_conduct.rst:137 -msgid "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:" -msgstr "Ansible コミュニティー行動規範は、Creative Commons Attribution-Share Alike 3.0 ライセンスの認可を受けています。私たちの行動規範は、以下のような他のオープンソースプロジェクトの行動規範を参考にしています。" - -#: ../../rst/community/code_of_conduct.rst:141 -msgid "Contributor Covenant" -msgstr "Contributor Covenant" - -#: ../../rst/community/code_of_conduct.rst:142 -msgid "Elastic" -msgstr "Elastic" - -#: ../../rst/community/code_of_conduct.rst:143 -msgid "The Fedora Project" -msgstr "The Fedora Project" - -#: ../../rst/community/code_of_conduct.rst:144 -msgid "OpenStack" -msgstr "OpenStack" - -#: ../../rst/community/code_of_conduct.rst:145 -msgid "Puppet Labs" -msgstr "Puppet Labs" - -#: ../../rst/community/code_of_conduct.rst:146 -msgid "Ubuntu" -msgstr "Ubuntu" - -#: ../../rst/community/committer_guidelines.rst:5 -msgid "Committers Guidelines" -msgstr "コミット担当者のガイドライン" - -#: ../../rst/community/committer_guidelines.rst:7 -msgid "These are the guidelines for people with commit privileges on the Ansible GitHub repository. Committers are essentially acting as members of the Ansible Core team, although not necessarily as employees of Ansible and Red Hat. Please read the guidelines before you commit." -msgstr "このページは、Ansible GitHub リポジトリー上でコミット権限を持つユーザーのためのガイドラインです。コミット担当者は、基本的に Ansible Core チームのメンバーとして活動していますが、Ansible および Red Hat の従業員であるとは限りません。コミットする前にこのガイドラインをお読みください。" - -#: ../../rst/community/committer_guidelines.rst:9 -msgid "These guidelines apply to everyone. At the same time, this ISN'T a process document. So just use good judgment. You've been given commit access because we trust your judgment." -msgstr "これらのガイドラインはすべてのユーザーに適用されます。同時に、これはプロセスのドキュメントではありません。したがって、適切な判断が求められます。コミットアクセス権が与えられているのは、そのユーザーの判断を信頼しているからです。" - -#: ../../rst/community/committer_guidelines.rst:11 -msgid "That said, use the trust wisely." -msgstr "そのため、その信頼については慎重に行動してください。" - -#: ../../rst/community/committer_guidelines.rst:13 -msgid "If you abuse the trust and break components and builds, and so on, the trust level falls and you may be asked not to commit or you may lose your commit privileges." -msgstr "信頼を乱用してコンポーネントやビルドなどを壊してしまうと、信頼のレベルが下がり、コミットしないように求められたり、コミット権限を失うことになるかもしれません。" - -#: ../../rst/community/committer_guidelines.rst:16 -msgid "Features, high-level design, and roadmap" -msgstr "機能、高レベル設計、およびロードマップ" - -#: ../../rst/community/committer_guidelines.rst:18 -msgid "As a core team member, you are an integral part of the team that develops the :ref:`roadmap `. Please be engaged, and push for the features and fixes that you want to see. Also keep in mind that Red Hat, as a company, will commit to certain features, fixes, APIs, and so on, for various releases. Red Hat, the company, and the Ansible team must get these changes completed and released as scheduled. Obligations to users, the community, and customers must come first. Because of these commitments, a feature you want to develop yourself may not get into a release if it affects a lot of other parts within Ansible." -msgstr "コミット担当者は、コアチームメンバーとして、:ref:`ロードマップ ` を作成するチームに不可欠です。積極的に関与し、希望する機能や修正をプッシュしてください。また、Red Hat は企業として、様々なリリースに対して、特定の機能、修正、API などにコミットすることを念頭に置いてください。企業である Red Hat、および Ansible チームは、このようなコミットされた機能 (など) を完成させ、スケジュール通りにリリースしなければなりません。ユーザー、コミュニティー、顧客への義務が最優先されなければなりません。これらの義務があるため、自分で開発したい機能が Ansible 内の他の多くの部分に影響を与える場合は、その機能がリリースに含まれない可能性があります。" - -#: ../../rst/community/committer_guidelines.rst:20 -msgid "Any other new features and changes to high level design should go through the proposal process (TBD), to ensure the community and core team have had a chance to review the idea and approve it. The core team has sole responsibility for merging new features based on proposals." -msgstr "その他の新機能や高レベル設計の変更は、コミュニティーおよび Core チームがアイデアを確認して承認する機会を確実にもてるように、提案プロセス (TBD) を経る必要があります。提案に基づいて新しい機能をマージする責任は Core チームにあります。" - -#: ../../rst/community/committer_guidelines.rst:23 -msgid "Our workflow on GitHub" -msgstr "GitHub でのワークフロー" - -#: ../../rst/community/committer_guidelines.rst:25 -msgid "As a committer, you may already know this, but our workflow forms a lot of our team policies. Please ensure you're aware of the following workflow steps:" -msgstr "コミット担当者として、以下をすでに理解しているかもしれませんが、私たちのワークフローは多くのチームポリシーを形成しています。以下のワークフローの手順を理解しておいてください。" - -#: ../../rst/community/committer_guidelines.rst:27 -msgid "Fork the repository upon which you want to do some work to your own personal repository" -msgstr "作業したいリポジトリーを自身のリポジトリーにフォークします。" - -#: ../../rst/community/committer_guidelines.rst:28 -msgid "Work on the specific branch upon which you need to commit" -msgstr "コミットする必要がある特定のブランチで作業します。" - -#: ../../rst/community/committer_guidelines.rst:29 -msgid "Create a Pull Request back to the Ansible repository and tag the people you would like to review; assign someone as the primary \"owner\" of your request" -msgstr "プル要求を Ansible リポジトリーに作成し、レビューしてほしいユーザーにタグを付けます。そのユーザーを、その要求の主な「所有者」として割り当てます。" - -#: ../../rst/community/committer_guidelines.rst:30 -msgid "Adjust code as necessary based on the Comments provided" -msgstr "提供されたコメントに基づいて、必要に応じてコードを調整します。" - -#: ../../rst/community/committer_guidelines.rst:31 -msgid "Ask someone on the Core Team to do a final review and merge" -msgstr "Core チームに最終確認とマージを依頼します。" - -#: ../../rst/community/committer_guidelines.rst:34 -msgid "Addendum to workflow for committers:" -msgstr "コミット担当者のワークフローへの補足" - -#: ../../rst/community/committer_guidelines.rst:36 -msgid "The Core Team is aware that this can be a difficult process at times. Sometimes, the team breaks the rules by making direct commits or merging their own PRs. This section is a set of guidelines. If you're changing a comma in a doc, or making a very minor change, you can use your best judgement. This is another trust thing. The process is critical for any major change, but for little things or getting something done quickly, use your best judgement and make sure people on the team are aware of your work." -msgstr "Core チームは、これが時に困難なプロセスであることを認識しています。時には、チームが直接コミットしたり、自身のプル要求をマージしたりしてルールを破ってしまうこともあります。ここではガイドラインを示します。ドキュメントでコンマを変更する場合や、ごく些細な変更であれば、各自の裁量で行ってください。これも信頼関係の問題です。大きな変更にはプロセスが重要ですが、ちょっとしたことや迅速に何かを行う場合は、最善の判断を下し、チームの人々に自分の仕事を認識してもらうようにしましょう。" - -#: ../../rst/community/committer_guidelines.rst:39 -msgid "Roles on Core" -msgstr "Core におけるロール" - -#: ../../rst/community/committer_guidelines.rst:40 -msgid "Core committers: Fine to do PRs for most things, but we should have a timebox. Hanging PRs may merge on the judgement of these devs." -msgstr "Core のコミット担当者: ほとんどの場合は、プル要求を実行しても問題ありませんが、タイムボックスが必要です。解決されていないプル要求が存在すると、開発者の判断でマージされます。" - -#: ../../rst/community/committer_guidelines.rst:41 -msgid ":ref:`Module maintainers `: Module maintainers own specific modules and have indirect commit access through the current module PR mechanisms." -msgstr ":ref:`モジュールメンテナー `: モジュールメンテナーは特定のモジュールを所有しており、現在のモジュールのプル要求メカニズムを通じて間接的にコミットにアクセスできます。" - -#: ../../rst/community/committer_guidelines.rst:44 -msgid "General rules" -msgstr "一般的なルール" - -#: ../../rst/community/committer_guidelines.rst:45 -msgid "Individuals with direct commit access to ansible/ansible are entrusted with powers that allow them to do a broad variety of things--probably more than we can write down. Rather than rules, treat these as general *guidelines*, individuals with this power are expected to use their best judgement." -msgstr "ansible/ansible への直接コミットアクセスを持つユーザーには、さまざまなことを実行できる権限が与えられています。おそらく、ここに記載している以上のことが可能になります。ここに示すことは、ルールというよりは、一般的な *ガイドライン* として扱い、この権限を持つユーザーは最善の判断を下すことが期待されています。" - -#: ../../rst/community/committer_guidelines.rst:47 -msgid "Don't" -msgstr "してはいけないこと" - -#: ../../rst/community/committer_guidelines.rst:49 -msgid "Commit directly." -msgstr "直接コミットする。" - -#: ../../rst/community/committer_guidelines.rst:50 -msgid "Merge your own PRs. Someone else should have a chance to review and approve the PR merge. If you are a Core Committer, you have a small amount of leeway here for very minor changes." -msgstr "自身のプル要求をマージする。他の誰かがプル要求のマージを確認して承認する機会を持つべきです。Core のコミット担当者であれば、ごくわずかな変更であれば、各自の裁量で行うことができます。" - -#: ../../rst/community/committer_guidelines.rst:51 -msgid "Forget about alternate environments. Consider the alternatives--yes, people have bad environments, but they are the ones who need us the most." -msgstr "代替環境のことを考えない。代替案を検討してください。ユーザーの中には環境が良くない人もいますが、私たちを最も必要としているのはそのようなユーザーです。" - -#: ../../rst/community/committer_guidelines.rst:52 -msgid "Drag your community team members down. Always discuss the technical merits, but you should never address the person's limitations (you can later go for beers and call them idiots, but not in IRC/GitHub/and so on)." -msgstr "コミュニティーチームのメンバーの足を引っ張る。技術的なメリットについては常に議論するべきですが、一個人の限界については決して言及すべきではありません (IRC、GitHub などでは特に注意してください)。" - -#: ../../rst/community/committer_guidelines.rst:53 -msgid "Forget about the maintenance burden. Some things are really cool to have, but they might not be worth shoehorning in if the maintenance burden is too great." -msgstr "メンテナンスの負担を考えない。その機能が本当に優れていても、メンテナンスの負担が大きすぎる場合は、組み込む価値がないかもしれません。" - -#: ../../rst/community/committer_guidelines.rst:54 -msgid "Break playbooks. Always keep backwards compatibility in mind." -msgstr "Playbook を壊す。常に下位互換性を念頭に置いてください。" - -#: ../../rst/community/committer_guidelines.rst:55 -msgid "Forget to keep it simple. Complexity breeds all kinds of problems." -msgstr "シンプルにすることを考えない。複雑なものは、あらゆる種類の問題を生み出します。" - -#: ../../rst/community/committer_guidelines.rst:57 -msgid "Do" -msgstr "すべきこと" - -#: ../../rst/community/committer_guidelines.rst:59 -msgid "Squash, avoid merges whenever possible, use GitHub's squash commits or cherry pick if needed (bisect thanks you)." -msgstr "squash を使用し、マージはできる限り使用せず、必要に応じて GitHub の Squash コミットを使用するか、入念に選ぶ (cherry-pick)。" - -#: ../../rst/community/committer_guidelines.rst:60 -msgid "Be active. Committers who have no activity on the project (through merges, triage, commits, and so on) will have their permissions suspended." -msgstr "活発に行動する。(マージ、トリアージ、コミットなどを通じて) プロジェクトで活動をしていないコミット担当者は、そのパーミッションが停止します。" - -#: ../../rst/community/committer_guidelines.rst:61 -msgid "Consider backwards compatibility (goes back to \"don't break existing playbooks\")." -msgstr "下位互換性を検討する (既存の Playbook を壊さない)。" - -#: ../../rst/community/committer_guidelines.rst:62 -msgid "Write tests. PRs with tests are looked at with more priority than PRs without tests that should have them included. While not all changes require tests, be sure to add them for bug fixes or functionality changes." -msgstr "テストを作成する。テストが含まれているプル要求は、テストが必要なのに含まれていないプル要求よりも優先して検討されます。すべての変更がテストを必要とするわけではありませんが、バグ修正や機能変更の際には必ずテストを追加しましょう。" - -#: ../../rst/community/committer_guidelines.rst:63 -msgid "Discuss with other committers, specially when you are unsure of something." -msgstr "特に不明な点がある場合は、他のコミット担当者と話し合う。" - -#: ../../rst/community/committer_guidelines.rst:64 -msgid "Document! If your PR is a new feature or a change to behavior, make sure you've updated all associated documentation or have notified the right people to do so. It also helps to add the version of ``ansible-base`` against which this documentation is compatible (to avoid confusion between stable and devel docs, for backwards compatibility, and so on)." -msgstr "文書化する。プル要求が新機能や動作の変更であれば、関連するすべてのドキュメントを更新したか、適切なユーザーに通知したかを確認してください。また、本ドキュメントと互換性がある Core の ``ansible-base`` バージョンを追加するのに便利です (たとえば、安定版と開発版のドキュメントとの混同を避けるため、後方互換性のため)。" - -#: ../../rst/community/committer_guidelines.rst:65 -msgid "Consider scope, sometimes a fix can be generalized" -msgstr "スコープを検討する。時には修正を一般化できる場合があります。" - -#: ../../rst/community/committer_guidelines.rst:66 -msgid "Keep it simple, then things are maintainable, debuggable and intelligible." -msgstr "保守やデバッグが可能で、分かりやすいものになるように、簡潔さを試みる。" - -#: ../../rst/community/committer_guidelines.rst:68 -msgid "Committers are expected to continue to follow the same community and contribution guidelines followed by the rest of the Ansible community." -msgstr "コミット担当者は、その他の Ansible コミュニティーメンバーが従っているコミュニティーおよび貢献に関するガイドラインに従い続けることが期待されています。" - -#: ../../rst/community/committer_guidelines.rst:72 -msgid "People" -msgstr "ユーザー" - -#: ../../rst/community/committer_guidelines.rst:74 -msgid "Individuals who've been asked to become a part of this group have generally been contributing in significant ways to the Ansible community for some time. Should they agree, they are requested to add their names and GitHub IDs to this file, in the section below, through a pull request. Doing so indicates that these individuals agree to act in the ways that their fellow committers trust that they will act." -msgstr "このグループの一員になることを尋ねられるユーザーは、通常、しばらくの間 Ansible コミュニティーに重要な貢献をしてきたユーザーです。同意したユーザーは、以下のセクションにあるこのファイルに名前と GitHub ID をプル要求で追加してください。この操作は、その他のコミット担当者に信頼してもらえる行動をとることに同意していることを示します。" - -#: ../../rst/community/committer_guidelines.rst:77 -msgid "Name" -msgstr "名前" - -#: ../../rst/community/committer_guidelines.rst:77 -msgid "GitHub ID" -msgstr "GitHub ID" - -#: ../../rst/community/committer_guidelines.rst:77 -msgid "IRC Nick" -msgstr "IRC ニック" - -#: ../../rst/community/committer_guidelines.rst:77 -msgid "Other" -msgstr "その他" - -#: ../../rst/community/committer_guidelines.rst:79 -msgid "James Cammarata" -msgstr "James Cammarata" - -#: ../../rst/community/committer_guidelines.rst:79 -msgid "jimi-c" -msgstr "jimi-c" - -#: ../../rst/community/committer_guidelines.rst:79 -msgid "jimi" -msgstr "jimi" - -#: ../../rst/community/committer_guidelines.rst:81 -msgid "Brian Coca" -msgstr "Brian Coca" - -#: ../../rst/community/committer_guidelines.rst:81 -msgid "bcoca" -msgstr "bcoca" - -#: ../../rst/community/committer_guidelines.rst:83 -msgid "Matt Davis" -msgstr "Matt Davis" - -#: ../../rst/community/committer_guidelines.rst:83 -msgid "nitzmahone" -msgstr "nitzmahone" - -#: ../../rst/community/committer_guidelines.rst:85 -msgid "Toshio Kuratomi" -msgstr "Toshio Kuratomi" - -#: ../../rst/community/committer_guidelines.rst:85 -msgid "abadger" -msgstr "abadger" - -#: ../../rst/community/committer_guidelines.rst:85 -msgid "abadger1999" -msgstr "abadger1999" - -#: ../../rst/community/committer_guidelines.rst:87 -msgid "Jason McKerr" -msgstr "Jason McKerr" - -#: ../../rst/community/committer_guidelines.rst:87 -msgid "mckerrj" -msgstr "mckerrj" - -#: ../../rst/community/committer_guidelines.rst:87 -msgid "newtMcKerr" -msgstr "newtMcKerr" - -#: ../../rst/community/committer_guidelines.rst:89 -msgid "Robyn Bergeron" -msgstr "Robyn Bergeron" - -#: ../../rst/community/committer_guidelines.rst:89 -msgid "robynbergeron" -msgstr "robynbergeron" - -#: ../../rst/community/committer_guidelines.rst:89 -msgid "rbergeron" -msgstr "rbergeron" - -#: ../../rst/community/committer_guidelines.rst:91 -msgid "Greg DeKoenigsberg" -msgstr "Greg DeKoenigsberg" - -#: ../../rst/community/committer_guidelines.rst:91 -msgid "gregdek" -msgstr "gregdek" - -#: ../../rst/community/committer_guidelines.rst:93 -msgid "Monty Taylor" -msgstr "Monty Taylor" - -#: ../../rst/community/committer_guidelines.rst:93 -msgid "emonty" -msgstr "emonty" - -#: ../../rst/community/committer_guidelines.rst:93 -msgid "mordred" -msgstr "mordred" - -#: ../../rst/community/committer_guidelines.rst:95 -msgid "Matt Martz" -msgstr "Matt Martz" - -#: ../../rst/community/committer_guidelines.rst:95 -msgid "sivel" -msgstr "sivel" - -#: ../../rst/community/committer_guidelines.rst:97 -msgid "Nate Case" -msgstr "Nate Case" - -#: ../../rst/community/committer_guidelines.rst:97 -msgid "qalthos" -msgstr "qalthos" - -#: ../../rst/community/committer_guidelines.rst:97 -msgid "Qalthos" -msgstr "Qalthos" - -#: ../../rst/community/committer_guidelines.rst:99 -msgid "James Tanner" -msgstr "James Tanner" - -#: ../../rst/community/committer_guidelines.rst:99 -msgid "jctanner" -msgstr "jctanner" - -#: ../../rst/community/committer_guidelines.rst:99 -msgid "jtanner" -msgstr "jtanner" - -#: ../../rst/community/committer_guidelines.rst:101 -msgid "Peter Sprygada" -msgstr "Peter Sprygada" - -#: ../../rst/community/committer_guidelines.rst:101 -msgid "privateip" -msgstr "privateip" - -#: ../../rst/community/committer_guidelines.rst:103 -msgid "Abhijit Menon-Sen" -msgstr "Abhijit Menon-Sen" - -#: ../../rst/community/committer_guidelines.rst:103 -msgid "amenonsen" -msgstr "amenonsen" - -#: ../../rst/community/committer_guidelines.rst:103 -msgid "crab" -msgstr "crab" - -#: ../../rst/community/committer_guidelines.rst:105 -msgid "Michael Scherer" -msgstr "Michael Scherer" - -#: ../../rst/community/committer_guidelines.rst:105 -msgid "mscherer" -msgstr "mscherer" - -#: ../../rst/community/committer_guidelines.rst:105 -msgid "misc" -msgstr "misc" - -#: ../../rst/community/committer_guidelines.rst:107 -msgid "René Moser" -msgstr "René Moser" - -#: ../../rst/community/committer_guidelines.rst:107 -msgid "resmo" -msgstr "resmo" - -#: ../../rst/community/committer_guidelines.rst:109 -msgid "David Shrewsbury" -msgstr "David Shrewsbury" - -#: ../../rst/community/committer_guidelines.rst:109 -msgid "Shrews" -msgstr "Shrews" - -#: ../../rst/community/committer_guidelines.rst:111 -msgid "Sandra Wills" -msgstr "Sandra Wills" - -#: ../../rst/community/committer_guidelines.rst:111 -msgid "docschick" -msgstr "docschick" - -#: ../../rst/community/committer_guidelines.rst:113 -msgid "Graham Mainwaring" -msgstr "Graham Mainwaring" - -#: ../../rst/community/committer_guidelines.rst:113 -msgid "ghjm" -msgstr "ghjm" - -#: ../../rst/community/committer_guidelines.rst:115 -msgid "Chris Houseknecht" -msgstr "Chris Houseknecht" - -#: ../../rst/community/committer_guidelines.rst:115 -msgid "chouseknecht" -msgstr "chouseknecht" - -#: ../../rst/community/committer_guidelines.rst:117 -msgid "Trond Hindenes" -msgstr "Trond Hindenes" - -#: ../../rst/community/committer_guidelines.rst:117 -msgid "trondhindenes" -msgstr "trondhindenes" - -#: ../../rst/community/committer_guidelines.rst:119 -msgid "Jon Hawkesworth" -msgstr "Jon Hawkesworth" - -#: ../../rst/community/committer_guidelines.rst:119 -msgid "jhawkesworth" -msgstr "jhawkesworth" - -#: ../../rst/community/committer_guidelines.rst:121 -msgid "Will Thames" -msgstr "Will Thames" - -#: ../../rst/community/committer_guidelines.rst:121 -msgid "willthames" -msgstr "willthames" - -#: ../../rst/community/committer_guidelines.rst:123 -msgid "Adrian Likins" -msgstr "Adrian Likins" - -#: ../../rst/community/committer_guidelines.rst:123 -msgid "alikins" -msgstr "alikins" - -#: ../../rst/community/committer_guidelines.rst:125 -msgid "Dag Wieers" -msgstr "Dag Wieers" - -#: ../../rst/community/committer_guidelines.rst:125 -msgid "dagwieers" -msgstr "dagwieers" - -#: ../../rst/community/committer_guidelines.rst:125 -msgid "dag@wieers.com" -msgstr "dag@wieers.com" - -#: ../../rst/community/committer_guidelines.rst:127 -msgid "Tim Rupp" -msgstr "Tim Rupp" - -#: ../../rst/community/committer_guidelines.rst:127 -msgid "caphrim007" -msgstr "caphrim007" - -#: ../../rst/community/committer_guidelines.rst:129 -msgid "Sloane Hertel" -msgstr "Sloane Hertel" - -#: ../../rst/community/committer_guidelines.rst:129 -msgid "s-hertel" -msgstr "s-hertel" - -#: ../../rst/community/committer_guidelines.rst:129 -msgid "shertel" -msgstr "shertel" - -#: ../../rst/community/committer_guidelines.rst:131 -msgid "Sam Doran" -msgstr "Sam Doran" - -#: ../../rst/community/committer_guidelines.rst:131 -msgid "samdoran" -msgstr "samdoran" - -#: ../../rst/community/committer_guidelines.rst:133 -msgid "Matt Clay" -msgstr "Matt Clay" - -#: ../../rst/community/committer_guidelines.rst:133 -msgid "mattclay" -msgstr "mattclay" - -#: ../../rst/community/committer_guidelines.rst:135 -msgid "Martin Krizek" -msgstr "Martin Krizek" - -#: ../../rst/community/committer_guidelines.rst:135 -msgid "mkrizek" -msgstr "mkrizek" - -#: ../../rst/community/committer_guidelines.rst:137 -msgid "Ganesh Nalawade" -msgstr "Ganesh Nalawade" - -#: ../../rst/community/committer_guidelines.rst:137 -msgid "ganeshrn" -msgstr "ganeshrn" - -#: ../../rst/community/committer_guidelines.rst:139 -msgid "Trishna Guha" -msgstr "Trishna Guha" - -#: ../../rst/community/committer_guidelines.rst:139 -msgid "trishnaguha" -msgstr "trishnaguha" - -#: ../../rst/community/committer_guidelines.rst:139 -msgid "trishnag" -msgstr "trishnag" - -#: ../../rst/community/committer_guidelines.rst:141 -msgid "Andrew Gaffney" -msgstr "Andrew Gaffney" - -#: ../../rst/community/committer_guidelines.rst:141 -msgid "agaffney" -msgstr "agaffney" - -#: ../../rst/community/committer_guidelines.rst:143 -msgid "Jordan Borean" -msgstr "Jordan Borean" - -#: ../../rst/community/committer_guidelines.rst:143 -msgid "jborean93" -msgstr "jborean93" - -#: ../../rst/community/committer_guidelines.rst:145 -msgid "Abhijeet Kasurde" -msgstr "Abhijeet Kasurde" - -#: ../../rst/community/committer_guidelines.rst:145 -msgid "Akasurde" -msgstr "Akasurde" - -#: ../../rst/community/committer_guidelines.rst:145 -msgid "akasurde" -msgstr "akasurde" - -#: ../../rst/community/committer_guidelines.rst:147 -msgid "Adam Miller" -msgstr "Adam Miller" - -#: ../../rst/community/committer_guidelines.rst:147 -msgid "maxamillion" -msgstr "maxamillion" - -#: ../../rst/community/committer_guidelines.rst:149 -msgid "Sviatoslav Sydorenko" -msgstr "Sviatoslav Sydorenko" - -#: ../../rst/community/committer_guidelines.rst:149 -msgid "webknjaz" -msgstr "webknjaz" - -#: ../../rst/community/committer_guidelines.rst:151 -msgid "Alicia Cozine" -msgstr "Alicia Cozine" - -#: ../../rst/community/committer_guidelines.rst:151 -msgid "acozine" -msgstr "acozine" - -#: ../../rst/community/committer_guidelines.rst:153 -msgid "Sandra McCann" -msgstr "Sandra McCann" - -#: ../../rst/community/committer_guidelines.rst:153 -msgid "samccann" -msgstr "samccann" - -#: ../../rst/community/committer_guidelines.rst:155 -msgid "Felix Fontein" -msgstr "Felix Fontein" - -#: ../../rst/community/committer_guidelines.rst:155 -msgid "felixfontein" -msgstr "felixfontein" - -#: ../../rst/community/committer_guidelines.rst:155 -msgid "felix@fontein.de" -msgstr "felix@fontein.de" - -#: ../../rst/community/communication.rst:5 -msgid "Communicating" -msgstr "コミュニケーション" - -#: ../../rst/community/communication.rst:11 -msgid "Code of Conduct" -msgstr "行動規範" - -#: ../../rst/community/communication.rst:13 -msgid "Please read and understand the :ref:`code_of_conduct`." -msgstr "「:ref:`code_of_conduct`」を読んで理解してください。" - -#: ../../rst/community/communication.rst:16 -msgid "Mailing list information" -msgstr "メーリングリストの情報" - -#: ../../rst/community/communication.rst:18 -msgid "Ansible has several mailing lists. Your first post to the mailing list will be moderated (to reduce spam), so please allow up to a day or so for your first post to appear." -msgstr "Ansible にはいくつかのメーリングリストがあります。メーリングリストへの最初の投稿は (スパムを減らすため) 調整されます。そのため、最初の投稿が表示されるまで最大 1 日ほどかかります。" - -#: ../../rst/community/communication.rst:20 -msgid "`Ansible Announce list `_ is a read-only list that shares information about new releases of Ansible, and also rare infrequent event information, such as announcements about an upcoming AnsibleFest, which is our official conference series. Worth subscribing to!" -msgstr "`Ansible Announce list `_ は、Ansible の新規リリースに関する情報を共有する読み取り専用リストです。Ansible の公式カンファレンスシリーズである AnsibleFest に関するアナウンスなど、不定期に開催されるイベント情報を共有しているため、ぜひサブスクライブしてください。" - -#: ../../rst/community/communication.rst:21 -msgid "`Ansible AWX List `_ is for `Ansible AWX `_ the upstream version of `Red Hat Ansible Tower `_" -msgstr "`Ansible AWX List `_ は、`Red Hat Ansible Tower `_ のアップストリームバージョンである `Ansible AWX `_ です。" - -#: ../../rst/community/communication.rst:22 -msgid "`Ansible Container List `_ is for users and developers of the Ansible Container project." -msgstr "`Ansible Container List `_ は、Ansible Container プロジェクトのユーザーおよび開発者向けです。" - -#: ../../rst/community/communication.rst:23 -msgid "`Ansible Development List `_ is for learning how to develop on Ansible, asking about prospective feature design, or discussions about extending ansible or features in progress." -msgstr "`Ansible Development List `_ は、Ansible での開発方法を学ぶため、将来の機能設計について質問するため、あるいは進行中の Ansible または機能の拡張について議論するためのものです。" - -#: ../../rst/community/communication.rst:24 -msgid "`Ansible Lockdown List `_ is for all things related to Ansible Lockdown projects, including DISA STIG automation and CIS Benchmarks." -msgstr "`Ansible Lockdown List `_ は、DISA STIG オートメーションや CIS ベンチマークなど、Ansible Lockdown プロジェクトに関連するものを対象としています。" - -#: ../../rst/community/communication.rst:25 -msgid "`Ansible Outreach List `_ help with promoting Ansible and `Ansible Meetups `_" -msgstr "`Ansible Outreach List `_ は、Ansible および `Ansible Meetups `_ のプロモーションを支援します。" - -#: ../../rst/community/communication.rst:26 -msgid "`Ansible Project List `_ is for sharing Ansible tips, answering questions, and general user discussion." -msgstr "`Ansible Project List `_ は、Ansible のヒントを共有したり、質問に答えたり、一般的なユーザーディスカッションを行うためのものです。" - -#: ../../rst/community/communication.rst:27 -msgid "`Molecule Discussions `_ is designed to aid with the development and testing of Ansible roles with Molecule." -msgstr "`Molecule Discussions `_ は、Molecule を使用した Ansible ロールの開発とテストを支援するためのものです。" - -#: ../../rst/community/communication.rst:29 -msgid "To subscribe to a group from a non-Google account, you can send an email to the subscription address requesting the subscription. For example: ``ansible-devel+subscribe@googlegroups.com``" -msgstr "Google 以外のアカウントからグループをサブスクライブするには、サブスクリプションを依頼するメールをサブスクリプションのアドレス (例: ``ansible-devel+subscribe@googlegroups.com``) に送信します。" - -#: ../../rst/community/communication.rst:34 -msgid "IRC channels" -msgstr "IRC チャネル" - -#: ../../rst/community/communication.rst:36 -msgid "Ansible has several IRC channels on `Freenode `_." -msgstr "Ansible には、`Freenode `_ に複数の IRC チャンネルがあります。" - -#: ../../rst/community/communication.rst:38 -msgid "Our IRC channels may require you to register your nickname. If you receive an error when you connect, see `Freenode's Nickname Registration guide `_ for instructions." -msgstr "この IRC チャネルでは、ニックネームの登録が必要になる場合があります。接続時にエラーが発生する場合は、「`Freenode's Nickname Registration guide `_」を参照してください。" - -#: ../../rst/community/communication.rst:40 -msgid "To find all ``ansible`` specific channels on a freenode network, use the following command in your IRC client::" -msgstr "freenode ネットワークですべての ``ansible`` 固有のチャンネルを見つけるには、IRC クライアントで以下のコマンドを使用します。" - -#: ../../rst/community/communication.rst:44 -msgid "as described in `freenode docs `_." -msgstr "`freenode ドキュメント `_ に記載のとおり。" - -#: ../../rst/community/communication.rst:47 -msgid "General channels" -msgstr "一般的なチャンネル" - -#: ../../rst/community/communication.rst:49 -msgid "``#ansible`` - For general use questions and support." -msgstr "``#ansible`` - 一般的な使い方の質問やサポートに使用。" - -#: ../../rst/community/communication.rst:50 -msgid "``#ansible-devel`` - For discussions on developer topics and code related to features or bugs." -msgstr "``#ansible-devel`` - 開発者のトピックや機能やバグに関連するコードについて議論する場。" - -#: ../../rst/community/communication.rst:51 -msgid "``#ansible-meeting`` - For public community meetings. We will generally announce these on one or more of the above mailing lists. See the `meeting schedule and agenda page `_" -msgstr "``#ansible-meeting`` - コミュニティーの公開ミーティング用。通常は、上記のメーリングリストで告知されます。「`ミーティングのスケジュールおよび議題のページ `_」を参照してください。" - -#: ../../rst/community/communication.rst:56 -msgid "Working groups" -msgstr "ワーキンググループ" - -#: ../../rst/community/communication.rst:58 -msgid "Many of our community `Working Groups `_ meet on Freenode IRC channels. If you want to get involved in a working group, join the channel where it meets or comment on the agenda." -msgstr "Ansible コミュニティーの `ワーキンググループ `_ の多くが、Freenode IRC チャンネルで活動しています。ワーキンググループに参加したい場合は、そのワーキンググループが活動しているチャンネルに参加したり、議題にコメントしたりしてください。" - -#: ../../rst/community/communication.rst:60 -msgid "`Amazon (AWS) Working Group `_ - ``#ansible-aws``" -msgstr "`Amazon (AWS) Working Group `_ - ``#ansible-aws``" - -#: ../../rst/community/communication.rst:61 -msgid "`Ansible Lockdown Working Group `_ | `gh/ansible/ansible-lockdown `_ - ``#ansible-lockdown``- Security playbooks/roles" -msgstr "`Ansible Lockdown Working Group `_ | `gh/ansible/ansible-lockdown `_ - ``#ansible-lockdown``- セキュリティー Playbook およびロール" - -#: ../../rst/community/communication.rst:62 -msgid "`AWX Working Group `_ - ``#ansible-awx`` - Upstream for Ansible Tower" -msgstr "`AWX Working Group `_ - ``#ansible-awx`` - Ansible Tower のアップストリーム" - -#: ../../rst/community/communication.rst:63 -msgid "`Azure Working Group `_ - ``#ansible-azure``" -msgstr "`Azure Working Group `_ - ``#ansible-azure``" - -#: ../../rst/community/communication.rst:64 -msgid "`Community Working Group `_ - ``#ansible-community`` - Including Meetups" -msgstr "`Community Working Group `_ - ``#ansible-community`` - Meetup を含みます。" - -#: ../../rst/community/communication.rst:65 -msgid "`Container Working Group `_ - ``#ansible-container``" -msgstr "`Container Working Group `_ - ``#ansible-container``" - -#: ../../rst/community/communication.rst:66 -msgid "`Contributor Experience Working Group `_ - ``#ansible-community``" -msgstr "`Contributor Experience Working Group `_ - ``#ansible-community``" - -#: ../../rst/community/communication.rst:67 -msgid "`Docker Working Group `_ - ``#ansible-devel``" -msgstr "`Docker Working Group `_ - ``#ansible-devel``" - -#: ../../rst/community/communication.rst:68 -msgid "`Documentation Working Group `_- ``#ansible-docs``" -msgstr "`Documentation Working Group `_- ``#ansible-docs``" - -#: ../../rst/community/communication.rst:69 -msgid "`Galaxy Working Group `_ - ``#ansible-galaxy``" -msgstr "`Galaxy Working Group `_ - ``#ansible-galaxy``" - -#: ../../rst/community/communication.rst:70 -msgid "`JBoss Working Group `_ - ``#ansible-jboss``" -msgstr "`JBoss Working Group `_ - ``#ansible-jboss``" - -#: ../../rst/community/communication.rst:71 -msgid "`Kubernetes Working Group `_ - ``#ansible-kubernetes``" -msgstr "`Kubernetes Working Group `_ - ``#ansible-kubernetes``" - -#: ../../rst/community/communication.rst:72 -msgid "`Lightbulb Training `_ - ``#ansible-lightbulb`` - Ansible training" -msgstr "`Lightbulb Training `_ - ``#ansible-lightbulb`` - Ansible トレーニング" - -#: ../../rst/community/communication.rst:73 -msgid "`Linode Working Group `_ - ``#ansible-linode``" -msgstr "`Linode Working Group `_ - ``#ansible-linode``" - -#: ../../rst/community/communication.rst:74 -msgid "`Molecule Working Group `_ | `molecule.io `_ - ``#ansible-molecule`` - testing platform for Ansible playbooks and roles" -msgstr "`Molecule Working Group `_ | `molecule.io `_ - ``#ansible-molecule`` - Ansible Playbook およびロール用テストプラットフォーム" - -#: ../../rst/community/communication.rst:75 -msgid "`Network Working Group `_ - ``#ansible-network``" -msgstr "`Network Working Group `_ - ``#ansible-network``" - -#: ../../rst/community/communication.rst:76 -msgid "`Remote Management Working Group `_ - ``#ansible-devel``" -msgstr "`Remote Management Working Group `_ - ``#ansible-devel``" - -#: ../../rst/community/communication.rst:77 -msgid "`Testing Working Group `_ - ``#ansible-devel``" -msgstr "`Testing Working Group `_ - ``#ansible-devel``" - -#: ../../rst/community/communication.rst:78 -msgid "`VMware Working Group `_ - ``#ansible-vmware``" -msgstr "`VMware Working Group `_ - ``#ansible-vmware``" - -#: ../../rst/community/communication.rst:79 -msgid "`Windows Working Group `_ - ``#ansible-windows``" -msgstr "`Windows Working Group `_ - ``#ansible-windows``" - -#: ../../rst/community/communication.rst:81 -msgid "Want to `form a new Working Group `_?" -msgstr "`新しいワーキンググループを作りたい `_ ですか?" - -#: ../../rst/community/communication.rst:84 -msgid "Regional and Language-specific channels" -msgstr "地域および言語固有のチャンネル" - -#: ../../rst/community/communication.rst:86 -msgid "``#ansible-es`` - Channel for Spanish speaking Ansible community." -msgstr "``#ansible-es`` - スペイン語の Ansible コミュニティー向けチャンネル。" - -#: ../../rst/community/communication.rst:87 -msgid "``#ansible-eu`` - Channel for the European Ansible Community." -msgstr "``#ansible-eu`` - ヨーロッパの Ansible コミュニティー向けのチャンネル。" - -#: ../../rst/community/communication.rst:88 -msgid "``#ansible-fr`` - Channel for French speaking Ansible community." -msgstr "``#ansible-fr`` - フランス語の Ansible コミュニティー向けのチャンネル。" - -#: ../../rst/community/communication.rst:89 -msgid "``#ansiblezh`` - Channel for Zurich/Swiss Ansible community." -msgstr "``#ansiblezh`` - チューリッヒ/スイスの Ansible コミュニティー向けのチャンネル。" - -#: ../../rst/community/communication.rst:92 -msgid "IRC meetings" -msgstr "IRC ミーティング" - -#: ../../rst/community/communication.rst:94 -msgid "The Ansible community holds regular IRC meetings on various topics, and anyone who is interested is invited to participate. For more information about Ansible meetings, consult the `meeting schedule and agenda page `_." -msgstr "Ansible コミュニティーは、さまざまなトピックに関する定期的な IRC ミーティングを開いており、興味のある人は誰でも参加することができます。Ansible ミーティングの詳細は、「`meeting schedule and agenda page `_」を参照してください。" - -#: ../../rst/community/communication.rst:98 -msgid "Ansible Tower support questions" -msgstr "Ansible Tower のサポートに関する質問" - -#: ../../rst/community/communication.rst:100 -msgid "Red Hat Ansible `Tower `_ is a UI, Server, and REST endpoint for Ansible. The Red Hat Ansible Automation subscription contains support for Ansible, Ansible Tower, Ansible Automation for Networking, and more." -msgstr "Red Hat Ansible `Tower `_ は、Ansible の UI、サーバー、および REST エンドポイントです。Red Hat Ansible Automation サブスクリプションには、Ansible、Ansible Tower、Ansible Automation for Networking などのサポートが含まれます。" - -#: ../../rst/community/communication.rst:103 -msgid "If you have a question about Ansible Tower, visit `Red Hat support `_ rather than using the IRC channel or the general project mailing list." -msgstr "Ansible Tower に関するご質問は、IRC チャンネルまたは一般的なプロジェクトメーリングリストではなく、`Red Hat サポート `_ にお問い合わせください。" - -#: ../../rst/community/communication.rst:106 -msgid "The Bullhorn" -msgstr "The Bullhorn" - -#: ../../rst/community/communication.rst:108 -msgid "**The Bullhorn** is our newsletter for the Ansible developer community. If you have any questions or content you would like to share, please reach out to us at the-bullhorn@redhat.com, or directly `contribute/suggest content `_ for upcoming issues." -msgstr "**The Bullhorn** は、Ansible 開発者コミュニティーのニュースレターです。共有したい質問やコンテンツがある場合は、Red Hat にアクセスしてください (the-bullhorn@redhat.com,)。また、今後発行する版については、`contribute/suggest content `_ に直接お問い合わせください。" - -#: ../../rst/community/communication.rst:111 -msgid "Read past issues `here `_." -msgstr "これまで発行した版については、`こちら `_ をお読みください。" - -#: ../../rst/community/communication.rst:113 -msgid "`Subscribe `_ to receive it." -msgstr "これを受け取るには、`サブスクライブ `_ します。" - -#: ../../rst/community/community.rst:4 -msgid "Community Information & Contributing" -msgstr "コミュニティーの情報および貢献" - -#: ../../rst/community/community.rst:6 -msgid "This page is deprecated. Please see the updated :ref:`Ansible Community Guide `." -msgstr "このページは非推奨になりました。更新された「:ref:`Ansible コミュニティーガイド `」を確認してください。" - -#: ../../rst/community/contributing_maintained_collections.rst:6 -msgid "Contributing to Ansible-maintained Collections" -msgstr "Ansible 管理コレクションへの参加" - -#: ../../rst/community/contributing_maintained_collections.rst:8 -msgid "The Ansible team welcomes community contributions to the collections maintained by Red Hat Ansible Engineering. This section describes how you can open issues and create PRs with the required testing before your PR can be merged." -msgstr "Ansible チームは、Red Hat Ansible Engineering が管理するコレクションへのコミュニティーの貢献を歓迎します。このセクションでは、PR をマージする前に、問題を作成し、必要なテストで PR を作成する方法を説明します。" - -#: ../../rst/community/contributing_maintained_collections.rst:14 -msgid "Ansible-maintained collections" -msgstr "Ansible で管理されているコレクション" - -#: ../../rst/community/contributing_maintained_collections.rst:16 -msgid "The following table shows:" -msgstr "次の表に示します。" - -#: ../../rst/community/contributing_maintained_collections.rst:18 -msgid "**Ansible-maintained collection** - Click the link to the collection on Galaxy, then click the ``repo`` button in Galaxy to find the GitHub repository for this collection." -msgstr "**Ansible で管理されているコレクション** - Galaxy のコレクションへのリンクをクリックしてから、Galaxy の ``repo`` ボタンをクリックして、このコレクションの GitHub リポジトリーを検索します。" - -#: ../../rst/community/contributing_maintained_collections.rst:19 -msgid "**Related community collection** - Collection that holds community-created content (modules, roles, and so on) that may also be of interest to a user of the Ansible-maintained collection. You can, for example, add new modules to the community collection as a technical preview before the content is moved to the Ansible-maintained collection." -msgstr "**関連するコミュニティーコレクション** - コミュニティーで作成されたコンテンツ (モジュール、ロールなど) を保持するコレクションで、Ansible で管理されているコレクションのユーザーも関心を持つ可能性があります。たとえば、コンテンツが Ansible で管理されているコレクションに移動する前に、テクニカルプレビューとしてコミュニティーコレクションに新しいモジュールを追加できます。" - -#: ../../rst/community/contributing_maintained_collections.rst:20 -msgid "**Sponsor** - Working group that manages the collections. You can join the meetings to discuss important proposed changes and enhancements to the collections." -msgstr "**スポンサー**: コレクションを管理する作業グループ。ミーティングに参加して、コレクションに対する重要な変更および機能強化を検討することができます。" - -#: ../../rst/community/contributing_maintained_collections.rst:21 -msgid "**Test requirements** - Testing required for any new or changed content for the Ansible-maintained collection." -msgstr "**テスト要件**: Ansible が管理するコレクションの新しいコンテンツまたは変更されたコンテンツについてテスト。" - -#: ../../rst/community/contributing_maintained_collections.rst:22 -msgid "**Developer details** - Describes whether the Ansible-maintained collection accepts direct community issues and PRs for existing collection content, as well as more specific developer guidelines based on the collection type." -msgstr "**開発者の詳細**: Ansible が直接コミュニティーの問題と、既存のコレクションコンテンツの PR と、コレクションタイプに基づいてより具体的な開発者ガイドラインを受け入れるかどうかを説明します。" - -#: ../../rst/community/contributing_maintained_collections.rst:248 -msgid "\\* A ✓ under **Open to PRs** means the collection welcomes GitHub issues and PRs for any changes to existing collection content (plugins, roles, and so on)." -msgstr "\\* **Open to PRs** の下にある ✓ は、コレクションが GitHub の問題と既存のコレクションコンテンツ (プラグイン、ロールなど) への変更に対する PR を歓迎することを意味します。" - -#: ../../rst/community/contributing_maintained_collections.rst:250 -msgid "\\*\\* Integration tests are required and unit tests are welcomed but not required for the AWS collections. An exception to this is made in cases where integration tests are logistically not feasible due to external requirements. An example of this is AWS Direct Connect, as this service can not be functionally tested without the establishment of network peering connections. Unit tests are therefore required for modules that interact with AWS Direct Connect. Exceptions to ``amazon.aws`` must be approved by Red Hat, and exceptions to ``community.aws`` must be approved by the AWS community." -msgstr "\\*\\* 統合テストは必須であり、単体テストは歓迎されますが、AWS コレクションには必須ではありません。これに対する例外は、外部要件により統合テストが永続的に実行できない場合に生じます。この例として、AWS Direct Connect があります。これは、ネットワークピアリング接続を確立しないと、このサービスを機能的にテストできないためです。したがって、AWS Direct Connect と相互作用するモジュールには単体テストが必要です。``amazon.aws`` への例外は Red Hat によって承認され、``community.aws`` への例外は AWS コミュニティーによって承認される必要があります。" - -#: ../../rst/community/contributing_maintained_collections.rst:252 -msgid "\\*\\*\\* ``ansible.netcommon`` contains all foundational components for enabling many network and security :ref:`platform ` collections. It contains all connection and filter plugins required, and installs as a dependency when you install the platform collection." -msgstr "\\*\\*\\* ``ansible.netcommon`` には、多くのネットワークおよびセキュリティーの :ref:`プラットフォーム ` コレクションを有効にするための基本コンポーネントが含まれています。これには必要なすべての接続およびフィルタープラグインが含まれ、プラットフォームコレクションのインストール時に依存関係としてインストールされます。" - -#: ../../rst/community/contributing_maintained_collections.rst:254 -msgid "\\*\\*\\*\\* Unit tests for Windows PowerShell modules are an exception to testing, but unit tests are valid and required for the remainder of the collection, including Ansible-side plugins." -msgstr "\\*\\*\\*\\* Windows PowerShell モジュールの単体テストは、テストの例外ですが、単体テストは、Ansible 側のプラグインを含め、コレクションの残りの部分に有効かつ必要になります。" - -#: ../../rst/community/contributing_maintained_collections.rst:260 -msgid "Deciding where your contribution belongs" -msgstr "貢献が所属する場所の決定" - -#: ../../rst/community/contributing_maintained_collections.rst:262 -msgid "We welcome contributions to Ansible-maintained collections. Because these collections are part of a downstream supported Red Hat product, the criteria for contribution, testing, and release may be higher than other community collections. The related community collections (such as ``community.general`` and ``community.network``) have less-stringent requirements and are a great place for new functionality that may become part of the Ansible-maintained collection in a future release." -msgstr "Ansible で管理されているコレクションへの貢献を歓迎します。これらのコレクションは、ダウンストリームでサポートされている Red Hat 製品の一部であるため、貢献、テスト、およびリリースの基準は、他のコミュニティーコレクションよりも高い場合があります。関連するコミュニティーコレクション (``community.general`` および ``community.network`` など) の要件はそれほど厳しくなく、将来のリリースで Ansible が管理するコレクションの一部になる可能性がある新しい機能に最適な場所です。" - -#: ../../rst/community/contributing_maintained_collections.rst:264 -msgid "The following scenarios use the ``arista.eos`` to help explain when to contribute to the Ansible-maintained collection, and when to propose your change or idea to the related community collection:" -msgstr "以下のシナリオでは、``arista.eos`` を使用して Ansible が管理しているコレクションに貢献するタイミングや、関連するコミュニティーコレクションに変更や考えを提案するタイミングを説明しています。" - -#: ../../rst/community/contributing_maintained_collections.rst:267 -msgid "You want to fix a problem in the ``arista.eos`` Ansible-maintained collection. Create the PR directly in the `arista.eos collection GitHub repository `_. Apply all the :ref:`merge requirements `." -msgstr "Ansible が管理する ``arista.eos`` コレクションの問題を修正します。PR を `arista.eos コレクションの GitHub リポジトリー `_ に直接作成します。:ref:`マージ要件 ` をすべて適用します。" - -#: ../../rst/community/contributing_maintained_collections.rst:269 -msgid "You want to add a new Ansible module for Arista. Your options are one of the following:" -msgstr "Arista の新しい Ansible モジュールを追加します。オプションは以下のいずれかになります。" - -#: ../../rst/community/contributing_maintained_collections.rst:271 -msgid "Propose a new module in the ``arista.eos`` collection (requires approval from Arista and Red Hat)." -msgstr "``arista.eos`` コレクションで新しいモジュールを実装します (Arista と Red Hat の承認が必要です)。" - -#: ../../rst/community/contributing_maintained_collections.rst:272 -msgid "Propose a new collection in the ``arista`` namespace (requires approval from Arista and Red Hat)." -msgstr "``arista`` 名前空間で新しいコレクションを提案します (Arista および Red Hat の承認が必要です)。" - -#: ../../rst/community/contributing_maintained_collections.rst:273 -msgid "Propose a new module in the ``community.network`` collection (requires network community approval)." -msgstr "``community.network`` コレクションで新しいモジュールを実装します (ネットワークコミュニティーの承認が必要です)。" - -#: ../../rst/community/contributing_maintained_collections.rst:274 -msgid "Place your new module in a collection in your own namespace (no approvals required)." -msgstr "新しいモジュールを独自の名前空間のコレクションに置きます (承認は必要ありません)。" - -#: ../../rst/community/contributing_maintained_collections.rst:277 -msgid "Most new content should go into either a related community collection or your own collection first so that is well established in the community before you can propose adding it to the ``arista`` namespace, where inclusion and maintenance criteria are much higher." -msgstr "ほとんどの新しいコンテンツは、関連するコミュニティーコレクションに入れるか、独自のコレクションのいずれかに入れる必要があります。これにより、含まれる基準とメンテナンス基準がはるかに高い ``arista`` 名前空間に追加することを提案できます。" - -#: ../../rst/community/contributing_maintained_collections.rst:283 -msgid "Requirements to merge your PR" -msgstr "PR のマージ要件" - -#: ../../rst/community/contributing_maintained_collections.rst:285 -msgid "Your PR must meet the following requirements before it can merge into an Ansible-maintained collection:" -msgstr "Ansible が管理するコレクションにマージする前に、PR が以下の要件を満たす必要があります。" - -#: ../../rst/community/contributing_maintained_collections.rst:288 -msgid "The PR is in the intended scope of the collection. Communicate with the appropriate Ansible sponsor listed in the :ref:`Ansible-maintained collection table ` for help." -msgstr "PR はコレクションの範囲にあり、支援を得るために :ref:`Ansible 管理コレクションの表 ` に一覧表示されている適切な Ansible スポンサーに連絡します。" - -#: ../../rst/community/contributing_maintained_collections.rst:289 -msgid "For network and security domains, the PR follows the :ref:`resource module development principles `." -msgstr "ネットワークおよびセキュリティードメインの場合、プル要求は :ref:`リソースモジュール開発の原則 ` に従います。" - -#: ../../rst/community/contributing_maintained_collections.rst:290 -msgid "Passes :ref:`sanity tests and tox `." -msgstr ":ref:`sanity tests and tox ` を渡します。" - -#: ../../rst/community/contributing_maintained_collections.rst:291 -msgid "Passes unit, and integration tests, as listed in the :ref:`Ansible-maintained collection table ` and described in :ref:`testing_resource_modules`." -msgstr ":ref:`Ansible 管理コレクションの表 ` に一覧表示されているとおりに、単体テストおよび統合テストを渡します (:ref:`testing_resource_modules` を参照)。" - -#: ../../rst/community/contributing_maintained_collections.rst:292 -msgid "Follows Ansible guidelines. See :ref:`developing_modules` and :ref:`developing_collections`." -msgstr "Ansible ガイドラインに準拠します。「:ref:`developing_modules`」および「:ref:`developing_collections`」を参照してください。" - -#: ../../rst/community/contributing_maintained_collections.rst:293 -msgid "Addresses all review comments." -msgstr "すべてのレビューコメントに対応します。" - -#: ../../rst/community/contributing_maintained_collections.rst:294 -msgid "Includes an appropriate :ref:`changelog `." -msgstr "これには、適切な :ref:`changelog ` が含まれます。" - -#: ../../rst/community/contributor_license_agreement.rst:5 -msgid "Contributors License Agreement" -msgstr "貢献者のライセンス契約" - -#: ../../rst/community/contributor_license_agreement.rst:7 -msgid "By contributing you agree that these contributions are your own (or approved by your employer) and you grant a full, complete, irrevocable copyright license to all users and developers of the project, present and future, pursuant to the license of the project." -msgstr "By contributing you agree that these contributions are your own (or approved by your employer) and you grant a full, complete, irrevocable copyright license to all users and developers of the project, present and future, pursuant to the license of the project." - -#: ../../rst/community/development_process.rst:5 -msgid "The Ansible Development Cycle" -msgstr "Ansible 開発ライフサイクル" - -#: ../../rst/community/development_process.rst:7 -msgid "Ansible developers (including community contributors) add new features, fix bugs, and update code in many different repositories. The `ansible/ansible repository `_ contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-base``. Other repositories contain plugins and modules that enable Ansible to execute specific tasks, like adding a user to a particular database or configuring a particular network device. These repositories contain the source code for collections." -msgstr "Ansible 開発者 (コミュニティーの貢献者を含む) は、多くの異なるリポジトリーで新機能を追加し、バグを修正し、コードを更新します。`ansible/ansible リポジトリー `_には、モジュールコードを管理対象ノードにコピーするなど、基本的な機能およびコードが含まれています。このコードは、``ansible-base`` と呼ばれています。他のリポジトリーには、Ansible が特定のタスク (特定のデータベースへのユーザーの追加や特定のネットワークデバイスの設定など) を実行できるようにするプラグインとモジュールが含まれています。これらのリポジトリーには、コレクションのソースコードが含まれています。" - -#: ../../rst/community/development_process.rst:9 -msgid "Development on ``ansible-base`` occurs on two levels. At the macro level, the ``ansible-base`` developers and maintainers plan releases and track progress with roadmaps and projects. At the micro level, each PR has its own lifecycle." -msgstr "``ansible-base`` 開発サイクルは 2 つのレベルで行われます。マクロレベルでは、``ansible-base`` 開発者とメンテナーがリリースを計画を立て、ロードマップおよびプロジェクトを使用して進捗を追跡します。ミクロレベルでは、各プル要求には独自のライフサイクルがあります。" - -#: ../../rst/community/development_process.rst:11 -msgid "Development on collections also occurs at the macro and micro levels. Each collection has its own macro development cycle. For more information on the collections development cycle, see :ref:`contributing_maintained_collections`. The micro-level lifecycle of a PR is similar in collections and in ``ansible-base``." -msgstr "コレクションに関する開発は、マクロレベルおよびミクロレベルでも発生します。各コレクションには独自のマクロ開発サイクルがあります。コレクション開発サイクルの詳細は、:ref:`contributing_maintained_collections` を参照してください。プル要求のマイクロレベルのライフサイクルは、コレクションと ``ansible-base`` で似ています。" - -#: ../../rst/community/development_process.rst:17 -msgid "Macro development: ``ansible-base`` roadmaps, releases, and projects" -msgstr "マクロ開発: ``ansible-base`` のロードマップ、リリース、およびプロジェクト" - -#: ../../rst/community/development_process.rst:19 -msgid "If you want to follow the conversation about what features will be added to ``ansible-base`` for upcoming releases and what bugs are being fixed, you can watch these resources:" -msgstr "今後のリリースに向けて ``ansible-base`` にどのような機能が追加されるのか、どのようなバグが修正されるのかについてのやりとりを見逃さないようにする場合は、これらのリソースをフォローしてください。" - -#: ../../rst/community/development_process.rst:21 -msgid "the :ref:`roadmaps`" -msgstr ":ref:`roadmaps`" - -#: ../../rst/community/development_process.rst:22 -msgid "the :ref:`Ansible Release Schedule `" -msgstr ":ref:`Ansible リリーススケジュール `" - -#: ../../rst/community/development_process.rst:23 -msgid "various GitHub `projects `_ - for example:" -msgstr "さまざまな GitHub `プロジェクト `_ - 以下に例を示します。" - -#: ../../rst/community/development_process.rst:25 -msgid "the `2.10 release project `_" -msgstr "`2.10 release project `_" - -#: ../../rst/community/development_process.rst:26 -msgid "the `network bugs project `_" -msgstr "`network bugs project `_" - -#: ../../rst/community/development_process.rst:27 -msgid "the `core documentation project `_" -msgstr "`core documentation project `_" - -#: ../../rst/community/development_process.rst:32 -msgid "Micro development: the lifecycle of a PR" -msgstr "マイクロ開発: プル要求のライフサイクル" - -#: ../../rst/community/development_process.rst:34 -msgid "If you want to contribute a feature or fix a bug in ``ansible-base`` or in a collection, you must open a **pull request** (\"PR\" for short). GitHub provides a great overview of `how the pull request process works `_ in general. The ultimate goal of any pull request is to get merged and become part of a collection or ``ansible-base``. Here's an overview of the PR lifecycle:" -msgstr "``ansible-base`` またはコレクションの機能追加またはバグ修正を行う場合は、**プル要求** (略して「PR」) を作成する必要があります。一般的に `プル要求プロセスの一般的な仕組みについて `_ の概要は、GitHub で確認できます。プル要求の最終目標は、マージされ、コレクションまたは ``ansible-base`` の一部になることです。プル要求ライフサイクルの概要は、以下のようになります。" - -#: ../../rst/community/development_process.rst:37 -msgid "Contributor opens a PR" -msgstr "プル要求を開きます。" - -#: ../../rst/community/development_process.rst:38 -msgid "Ansibot reviews the PR" -msgstr "Ansibot がプル要求をレビューします。" - -#: ../../rst/community/development_process.rst:39 -msgid "Ansibot assigns labels" -msgstr "Ansibot がラベルを割り当てます。" - -#: ../../rst/community/development_process.rst:40 -msgid "Ansibot pings maintainers" -msgstr "Ansibot がメンテナーに通知します。" - -#: ../../rst/community/development_process.rst:41 -msgid "Shippable runs the test suite" -msgstr "Shippable テストスイートを実行します。" - -#: ../../rst/community/development_process.rst:42 -msgid "Developers, maintainers, community review the PR" -msgstr "開発者、メンテナー、コミュニティーがプル要求をレビューします。" - -#: ../../rst/community/development_process.rst:43 -msgid "Contributor addresses any feedback from reviewers" -msgstr "貢献者が、レビューアーからのフィードバックに対処します。" - -#: ../../rst/community/development_process.rst:44 -msgid "Developers, maintainers, community re-review" -msgstr "開発者、メンテナー、コミュニティーが再度レビューします。" - -#: ../../rst/community/development_process.rst:45 -msgid "PR merged or closed" -msgstr "プル要求をマージまたは終了します。" - -#: ../../rst/community/development_process.rst:48 -msgid "Automated PR review: ansibullbot" -msgstr "自動プル要求確認: ansibullbot" - -#: ../../rst/community/development_process.rst:50 -msgid "Because Ansible receives many pull requests, and because we love automating things, we have automated several steps of the process of reviewing and merging pull requests with a tool called Ansibullbot, or Ansibot for short." -msgstr "Ansible は多くのプル要求を受け取るため、またこのコミュニティーは自動化に興味があるため、Ansibullbot (略して Ansibot) と呼ばれるツールを使ってプル要求を確認してマージするプロセスのいくつかのステップを自動化しました。" - -#: ../../rst/community/development_process.rst:52 -msgid "`Ansibullbot `_ serves many functions:" -msgstr "`Ansibullbot `_ は多くの機能を提供します。" - -#: ../../rst/community/development_process.rst:54 -msgid "Responds quickly to PR submitters to thank them for submitting their PR" -msgstr "プル要求の提出者に迅速に対応し、プル要求提出のお礼を伝えます。" - -#: ../../rst/community/development_process.rst:55 -msgid "Identifies the community maintainer responsible for reviewing PRs for any files affected" -msgstr "影響を受けるファイルのプル要求をレビューするコミュニティーメンテナーを指定します。" - -#: ../../rst/community/development_process.rst:56 -msgid "Tracks the current status of PRs" -msgstr "プル要求の現在の状態を追跡します。" - -#: ../../rst/community/development_process.rst:57 -msgid "Pings responsible parties to remind them of any PR actions for which they may be responsible" -msgstr "責任を負う可能性のあるプル要求の作業を思い出させるために、責任者に通知します。" - -#: ../../rst/community/development_process.rst:58 -msgid "Provides maintainers with the ability to move PRs through the workflow" -msgstr "メンテナーは、ワークフローを通じてプル要求に対応する機能を提供します。" - -#: ../../rst/community/development_process.rst:59 -msgid "Identifies PRs abandoned by their submitters so that we can close them" -msgstr "プル要求は、それを提出したユーザーが中断したり、修了することができるようにします。" - -#: ../../rst/community/development_process.rst:60 -msgid "Identifies modules abandoned by their maintainers so that we can find new maintainers" -msgstr "メンテナーが中断したモジュールを特定し、新しいメンテナーを見つけられるようにします。" - -#: ../../rst/community/development_process.rst:63 -msgid "Ansibot workflow" -msgstr "Ansibot ワークフロー" - -#: ../../rst/community/development_process.rst:65 -msgid "Ansibullbot runs continuously. You can generally expect to see changes to your issue or pull request within thirty minutes. Ansibullbot examines every open pull request in the repositories, and enforces state roughly according to the following workflow:" -msgstr "Ansibullbot は継続的に実行されます。通常、提出した問題やプル要求の内容は、30 分もあれば確認できるようになります。Ansibullbot は、リポジトリー内のすべての未解決のプル要求を調べて、以下のワークフローに従って状態を強制します。" - -#: ../../rst/community/development_process.rst:67 -msgid "If a pull request has no workflow labels, it's considered **new**. Files in the pull request are identified, and the maintainers of those files are pinged by the bot, along with instructions on how to review the pull request. (Note: sometimes we strip labels from a pull request to \"reboot\" this process.)" -msgstr "プル要求にワークフローラベルがない場合は、**new** と見なされます。プル要求に含まれるファイルが特定され、ボットがそのファイルのメンテナーに通知を送り、プル要求を確認する方法が指示されます (注記: 時々、プル要求からラベルを削除して、このプロセスを「再起動」することがあります)。" - -#: ../../rst/community/development_process.rst:68 -msgid "If the module maintainer is not ``$team_ansible``, the pull request then goes into the **community_review** state." -msgstr "モジュールのメンテナーが ``$team_ansible`` でない場合は、プル要求が **community_review** 状態になります。" - -#: ../../rst/community/development_process.rst:69 -msgid "If the module maintainer is ``$team_ansible``, the pull request then goes into the **core_review** state (and probably sits for a while)." -msgstr "モジュールのメンテナーが ``$team_ansible`` の場合、プル要求は **core_review** 状態になります (そして、おそらくしばらくそのままになります)。" - -#: ../../rst/community/development_process.rst:70 -msgid "If the pull request is in **community_review** and has received comments from the maintainer:" -msgstr "プル要求が **community_review** にあり、メンテナーからコメントを受け取った場合は、以下のようになります。" - -#: ../../rst/community/development_process.rst:72 -msgid "If the maintainer says ``shipit``, the pull request is labeled **shipit**, whereupon the Core team assesses it for final merge." -msgstr "メンテナーが ``shipit`` と判断すると、プル要求に **shipit** というラベルが付けられ、Core チームが最終的なマージのためにそれを評価します。" - -#: ../../rst/community/development_process.rst:73 -msgid "If the maintainer says ``needs_info``, the pull request is labeled **needs_info** and the submitter is asked for more info." -msgstr "メンテナーが ``needs_info`` と判断すると、プル要求に **needs_info** というラベルが付けられ、提出したユーザーには詳細情報の提供が求められます。" - -#: ../../rst/community/development_process.rst:74 -msgid "If the maintainer says **needs_revision**, the pull request is labeled **needs_revision** and the submitter is asked to fix some things." -msgstr "メンテナーが **needs_revision** と判断すると、プル要求に **needs_revision** というラベルが付けられ、提出したユーザーは一部修正を求められます。" - -#: ../../rst/community/development_process.rst:76 -msgid "If the submitter says ``ready_for_review``, the pull request is put back into **community_review** or **core_review** and the maintainer is notified that the pull request is ready to be reviewed again." -msgstr "提出したユーザーが ``ready_for_review`` と判断すると、そのプル要求は **community_review** または **core_review** に戻され、プル要求の再レビューの準備ができたことがメンテナーに通知されます。" - -#: ../../rst/community/development_process.rst:77 -msgid "If the pull request is labeled **needs_revision** or **needs_info** and the submitter has not responded lately:" -msgstr "プル要求に **needs_revision** または **needs_info** というラベルが付けられ、提出したユーザーが応答しない場合は、以下のようになります。" - -#: ../../rst/community/development_process.rst:79 -msgid "The submitter is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending action**, and the issue or pull request will be closed two weeks after that." -msgstr "提出したユーザーは 2 週間後に丁寧な通知を受け取り、さらに 2 週間後に再度連絡が入り、**pending action** (保留中) というラベルが付けられ、その 2 週間後に問題またはプル要求がクローズになります。" - -#: ../../rst/community/development_process.rst:80 -msgid "If the submitter responds at all, the clock is reset." -msgstr "提出したユーザーが応答すると、タイマーがリセットされます。" - -#: ../../rst/community/development_process.rst:81 -msgid "If the pull request is labeled **community_review** and the reviewer has not responded lately:" -msgstr "プル要求に **community_review** というラベルが付けられ、レビュー担当者が応答しない場合は、以下のようになります。" - -#: ../../rst/community/development_process.rst:83 -msgid "The reviewer is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending_action**, and then may be reassigned to ``$team_ansible`` or labeled **core_review**, or often the submitter of the pull request is asked to step up as a maintainer." -msgstr "レビューアーは 2 週間後に丁寧な通知を受け取り、さらに 2 週間後に再度通知があり、**pending_action** と表示されます。その後、``$team_ansible`` に再アサインされたり、**core_review** というラベルが付きます。もしくは、プル要求の提出者がメンテナーとしてステップアップするように求められることがよくあります。" - -#: ../../rst/community/development_process.rst:84 -msgid "If Shippable tests fail, or if the code is not able to be merged, the pull request is automatically put into **needs_revision** along with a message to the submitter explaining why." -msgstr "Shippable テストが失敗したり、コードをマージできないと、プル要求は自動的に **needs_revision** に置かれ、その理由を説明するメッセージが提出したユーザーに送られます。" - -#: ../../rst/community/development_process.rst:86 -msgid "There are corner cases and frequent refinements, but this is the workflow in general." -msgstr "めったに発生しない場合や、頻繁に改良される場合がありますが、これは一般的なワークフローです。" - -#: ../../rst/community/development_process.rst:89 -msgid "PR labels" -msgstr "プル要求のラベル" - -#: ../../rst/community/development_process.rst:91 -msgid "There are two types of PR Labels generally: **workflow** labels and **information** labels." -msgstr "一般的に、プル要求には、**ワークフロー** ラベルおよび **情報** ラベルの 2 つのタイプがあります。" - -#: ../../rst/community/development_process.rst:94 -msgid "Workflow labels" -msgstr "ワークフローラベル" - -#: ../../rst/community/development_process.rst:96 -msgid "**community_review**: Pull requests for modules that are currently awaiting review by their maintainers in the Ansible community." -msgstr "**community_review**: Ansible コミュニティーのメンテナーが確認するのを現在待っているモジュールのプル要求。" - -#: ../../rst/community/development_process.rst:97 -msgid "**core_review**: Pull requests for modules that are currently awaiting review by their maintainers on the Ansible Core team." -msgstr "**core_review**: 現在 Ansible Core チームのメンテナーによる確認を待っているモジュールのプル要求。" - -#: ../../rst/community/development_process.rst:98 -msgid "**needs_info**: Waiting on info from the submitter." -msgstr "**needs_info**: 提出したユーザーからの情報を待っています。" - -#: ../../rst/community/development_process.rst:99 -msgid "**needs_rebase**: Waiting on the submitter to rebase." -msgstr "**needs_rebase**: 提出したユーザーがリベースを行うのを待っています。" - -#: ../../rst/community/development_process.rst:100 -msgid "**needs_revision**: Waiting on the submitter to make changes." -msgstr "**needs_revision**: 提出したユーザーが変更を行うのを待っています。" - -#: ../../rst/community/development_process.rst:101 -msgid "**shipit**: Waiting for final review by the core team for potential merge." -msgstr "**shipit**: マージの可能性があるかどうか、Core チームによる最終レビューを待っています。" - -#: ../../rst/community/development_process.rst:104 -msgid "Information labels" -msgstr "情報ラベル" - -#: ../../rst/community/development_process.rst:106 -msgid "**backport**: this is applied automatically if the PR is requested against any branch that is not devel. The bot immediately assigns the labels backport and ``core_review``." -msgstr "**backport**: PR が devel 以外のブランチに対して要求されると自動的に適用されます。ボットは、すぐにラベルバックポートと ``core_review`` を割り当てます。" - -#: ../../rst/community/development_process.rst:107 -msgid "**bugfix_pull_request**: applied by the bot based on the templatized description of the PR." -msgstr "**bugfix_pull_request**: プル要求のテンプレート化された説明に基づいてボットが適用します。" - -#: ../../rst/community/development_process.rst:108 -msgid "**cloud**: applied by the bot based on the paths of the modified files." -msgstr "**cloud**: 変更されたファイルのパスに基づいてボットが適用します。" - -#: ../../rst/community/development_process.rst:109 -msgid "**docs_pull_request**: applied by the bot based on the templatized description of the PR." -msgstr "**docs_pull_request**: プル要求のテンプレート化された説明に基づいてボットが適用します。" - -#: ../../rst/community/development_process.rst:110 -msgid "**easyfix**: applied manually, inconsistently used but sometimes useful." -msgstr "**easyfix**: 手動で適用され、その使用は一貫性はありまあせんが、場合によっては役に立ちます。" - -#: ../../rst/community/development_process.rst:111 -msgid "**feature_pull_request**: applied by the bot based on the templatized description of the PR." -msgstr "**feature_pull_request**: プル要求のテンプレート化された説明に基づいてボットが適用します。" - -#: ../../rst/community/development_process.rst:112 -msgid "**networking**: applied by the bot based on the paths of the modified files." -msgstr "**networking**: 変更されたファイルのパスに基づいてボットが適用します。" - -#: ../../rst/community/development_process.rst:113 -msgid "**owner_pr**: largely deprecated. Formerly workflow, now informational. Originally, PRs submitted by the maintainer would automatically go to **shipit** based on this label. If the submitter is also a maintainer, we notify the other maintainers and still require one of the maintainers (including the submitter) to give a **shipit**." -msgstr "**owner_pr**: 大半が非推奨になりました。以前はワークフローでしたが、現在は情報提供です。元々、メンテナーから提出されたプル要求は、このラベルに基づいて自動的に **shipit** に送られていました。提出したユーザーがメンテナーでもある場合、他のメンテナーに通知しても、(提出したユーザーを含む) メンテナーの一人に **shipit** を提供するように要求するようになりました。" - -#: ../../rst/community/development_process.rst:114 -msgid "**pending_action**: applied by the bot to PRs that are not moving. Reviewed every couple of weeks by the community team, who tries to figure out the appropriate action (closure, asking for new maintainers, and so on)." -msgstr "**pending_action**: ボットにより、変化のないプル要求に適用されます。コミュニティーチームが 2、３ 週間ごとにレビューし、適切なアクション (終了、新しいメンテナーの募集など) を考えます。" - -#: ../../rst/community/development_process.rst:118 -msgid "Special Labels" -msgstr "特殊なラベル" - -#: ../../rst/community/development_process.rst:120 -msgid "**new_plugin**: this is for new modules or plugins that are not yet in Ansible." -msgstr "**new_plugin**: これは Ansible にない新しいモジュールやプラグインのためのものです。" - -#: ../../rst/community/development_process.rst:122 -msgid "**Note:** `new_plugin` kicks off a completely separate process, and frankly it doesn't work very well at present. We're working our best to improve this process." -msgstr "**注記：** `new_plugin` は完全に別のプロセスを起動しますが、率直に言って現在はあまりうまく機能していません。このプロセスを改善するために最善を尽くしています。" - -#: ../../rst/community/development_process.rst:125 -msgid "Human PR review" -msgstr "ユーザーによるプル要求のレビュー" - -#: ../../rst/community/development_process.rst:127 -msgid "After Ansibot reviews the PR and applies labels, the PR is ready for human review. The most likely reviewers for any PR are the maintainers for the module that PR modifies." -msgstr "Ansibot がプル要求をレビューしてラベルを適用したら、ユーザーがプル要求をレビューする準備が整います。いずれのプル要求でも、それをレビューする可能性が高いのは、プル要求が変更するモジュールのメンテナーです。" - -#: ../../rst/community/development_process.rst:129 -msgid "Each module has at least one assigned :ref:`maintainer `, listed in the `BOTMETA.yml `_ file." -msgstr "各モジュールには、:ref:`メンテナー ` が少なくとも 1 人が割り当てられており、`BOTMETA.yml ` ファイルにその一覧があります。" - -#: ../../rst/community/development_process.rst:131 -msgid "The maintainer's job is to review PRs that affect that module and decide whether they should be merged (``shipit``) or revised (``needs_revision``). We'd like to have at least one community maintainer for every module. If a module has no community maintainers assigned, the maintainer is listed as ``$team_ansible``." -msgstr "メンテナーの仕事は、そのモジュールに影響を与えるプル要求をレビューして、マージ (``shipit``) すべきか修正 (``needs_revision``) すべきかを判断することです。すべてのモジュールには少なくともコミュニティーのメンテナーが 1 人必要です。モジュールにコミュニティーメンテナーが割り当てられていないと、そのメンテナーは ``$team_ansible`` として表示されます。" - -#: ../../rst/community/development_process.rst:133 -msgid "Once a human applies the ``shipit`` label, the :ref:`committers ` decide whether the PR is ready to be merged. Not every PR that gets the ``shipit`` label is actually ready to be merged, but the better our reviewers are, and the better our guidelines are, the more likely it will be that a PR that reaches **shipit** will be mergeable." -msgstr "ユーザーが ``shipit`` ラベルを適用すると、:ref:`コミット担当者 ` は、プル要求がマージする準備ができているかどうかを判断します。``shipit`` ラベルを取得したすべてのプル要求が実際にマージ可能な状態になるわけではありませんが、レビュー担当者が優秀で、コミュニティーのガイドラインが優れていればいるほど、**shipit** に到達したプル要求がマージされる可能性が高くなります。" - -#: ../../rst/community/development_process.rst:137 -msgid "Making your PR merge-worthy" -msgstr "プル要求を価値あるものにする" - -#: ../../rst/community/development_process.rst:139 -msgid "We do not merge every PR. Here are some tips for making your PR useful, attractive, and merge-worthy." -msgstr "すべてのプル要求をマージするわけではありません。ここでは、プル要求を有益で魅力的で、マージする価値のあるものにするためのヒントをいくつかご紹介します。" - -#: ../../rst/community/development_process.rst:144 -msgid "Changelogs" -msgstr "Changelog" - -#: ../../rst/community/development_process.rst:146 -msgid "Changelogs help users and developers keep up with changes to Ansible. Ansible builds a changelog for each release from fragments. You **must** add a changelog fragment to any PR that changes functionality or fixes a bug in ansible-base. You do not have to add a changelog fragment for PRs that add new modules and plugins, because our tooling does that for you automatically." -msgstr "changelog は、ユーザーや開発者が Ansible の変更情報を確認するのに役に立ちます。Ansible では、リリースごとにフラグメントから changelog を作成します。ansible-base の機能を変更したりバグを修正するプル要求には、changelog のフラグメントを追加する **必要があります**。プル要求が、新しいモジュールやプラグインを追加する場合は、ツールで自動的に行われるため、changelog のフラグメントを追加する必要はありません。" - -#: ../../rst/community/development_process.rst:148 -msgid "We build short summary changelogs for minor releases as well as for major releases. If you backport a bugfix, include a changelog fragment with the backport PR." -msgstr "マイナーリリースとメジャーリリースの両方に、短い概要を示した changelog を作成します。バグ修正をバックポートする場合には、バックポートのプル要求に changelog フラグメントを追加してください。" - -#: ../../rst/community/development_process.rst:153 -msgid "Creating a changelog fragment" -msgstr "changelog フラグメントの作成" - -#: ../../rst/community/development_process.rst:155 -msgid "A basic changelog fragment is a ``.yaml`` file placed in the ``changelogs/fragments/`` directory. Each file contains a yaml dict with keys like ``bugfixes`` or ``major_changes`` followed by a list of changelog entries of bugfixes or features. Each changelog entry is rst embedded inside of the yaml file which means that certain constructs would need to be escaped so they can be interpreted by rst and not by yaml (or escaped for both yaml and rst if you prefer). Each PR **must** use a new fragment file rather than adding to an existing one, so we can trace the change back to the PR that introduced it." -msgstr "基本的な changelog フラグメントは ``changelogs/fragments/`` ディレクトリーにある ``.yaml`` ファイルです。それぞれのファイルには、``bugfixes``、``major_changes`` などのキーを持つ yaml ディクショナリーが含まれており、その後にバグ修正または機能の changelog エントリーの一覧が続きます。それぞれの changelog エントリーは yaml ファイルが組み込まれている rst です。つまり、特定の構成は、yaml ではなく rst で解釈できるようにエスケープする必要があります (yaml と rst の両方にエスケープされていることが望ましい場合は、両方エスケープします)。各プル要求は、既存のものに追加するのではなく、新しいフラグメントファイルを使用する **必要があります**。したがって、変更を加えたプル要求までさかのぼることができます。" - -#: ../../rst/community/development_process.rst:157 -msgid "To create a changelog entry, create a new file with a unique name in the ``changelogs/fragments/`` directory of the corresponding repository. The file name should include the PR number and a description of the change. It must end with the file extension ``.yaml``. For example: ``40696-user-backup-shadow-file.yaml``" -msgstr "changelog エントリーを作成するには、対応するリポジトリーの ``changelogs/fragments/`` ディレクトリーに一意の名前を持つ新しいファイルを作成します。ファイル名には、PR 番号と変更の説明を含める必要があります。拡張子 ``.yaml`` で終了する必要があります。たとえば、``40696-user-backup-shadow-file.yaml`` です。" - -#: ../../rst/community/development_process.rst:159 -msgid "A single changelog fragment may contain multiple sections but most will only contain one section. The toplevel keys (bugfixes, major_changes, and so on) are defined in the `config file `_ for our `release note tool `_. Here are the valid sections and a description of each:" -msgstr "1 つの changelog フラグメントには複数のセクションが含まれる場合がありますが、ほとんどの場合はセクションが 1 つしか含まれていません。最上位キー (bugfixes、major_changes など) は、`リリースノートツール `_ の `設定ファイル `_ で定義されています。有効なセクションとその説明を以下に示します。" - -#: ../../rst/community/development_process.rst:162 -msgid "**breaking_changes**" -msgstr "**breaking_changes**" - -#: ../../rst/community/development_process.rst:162 -msgid "Changes that break existing playbooks or roles. This includes any change to existing behavior that forces users to update tasks. Displayed in both the changelogs and the :ref:`Porting Guides `." -msgstr "既存の Playbook またはロールを破損する変更。これには、ユーザーにタスクの更新を強制する既存の動作の変更が含まれます。changelog と :ref:`移植ガイド ` の両方に記載されます。" - -#: ../../rst/community/development_process.rst:165 -msgid "**major_changes**" -msgstr "**major_changes**" - -#: ../../rst/community/development_process.rst:165 -msgid "Major changes to Ansible itself. Generally does not include module or plugin changes. Displayed in both the changelogs and the :ref:`Porting Guides `." -msgstr "Ansible 自体への大規模な変更。通常、モジュールやプラグインの変更は含まれません。changelog と :ref:`移植ガイド ` の両方に記載されます。" - -#: ../../rst/community/development_process.rst:168 -msgid "**minor_changes**" -msgstr "**minor_changes**" - -#: ../../rst/community/development_process.rst:168 -msgid "Minor changes to Ansible, modules, or plugins. This includes new features, new parameters added to modules, or behavior changes to existing parameters." -msgstr "Ansible、モジュール、またはプラグインへの小規模な変更。これには、新機能、モジュールに追加された新しいパラメーター、または既存のパラメーターに対する動作の変更が含まれます。" - -#: ../../rst/community/development_process.rst:171 -msgid "**deprecated_features**" -msgstr "**deprecated_features**" - -#: ../../rst/community/development_process.rst:171 -msgid "Features that have been deprecated and are scheduled for removal in a future release. Displayed in both the changelogs and the :ref:`Porting Guides `." -msgstr "非推奨となり、今後のリリースで削除される予定です。changelog と :ref:`移植ガイド ` の両方に記載されます。" - -#: ../../rst/community/development_process.rst:174 -msgid "**removed_features**" -msgstr "**removed_features**" - -#: ../../rst/community/development_process.rst:174 -msgid "Features that were previously deprecated and are now removed. Displayed in both the changelogs and the :ref:`Porting Guides `." -msgstr "以前非推奨となり、削除された機能。changelogs と :ref:`移植ガイド ` の両方に表示されます。" - -#: ../../rst/community/development_process.rst:177 -msgid "**security_fixes**" -msgstr "**security_fixes**" - -#: ../../rst/community/development_process.rst:177 -msgid "Fixes that address CVEs or resolve security concerns. Include links to CVE information." -msgstr "CVE に対応するか、セキュリティー上の懸念を解決してください。CVE 情報へのリンクが含まれます。" - -#: ../../rst/community/development_process.rst:180 -msgid "**bugfixes**" -msgstr "**bugfixes**" - -#: ../../rst/community/development_process.rst:180 -msgid "Fixes that resolve issues." -msgstr "問題を解決するための修正。" - -#: ../../rst/community/development_process.rst:183 -msgid "**known_issues**" -msgstr "**known_issues**" - -#: ../../rst/community/development_process.rst:183 -msgid "Known issues that are currently not fixed or will not be fixed." -msgstr "現在修正されていない、または修正される予定のない既知の問題。" - -#: ../../rst/community/development_process.rst:185 -msgid "Each changelog entry must contain a link to its issue between parentheses at the end. If there is no corresponding issue, the entry must contain a link to the PR itself." -msgstr "各 changelog エントリーには、最後に括弧内に、その問題へのリンクが含まれていなければなりません。対応する問題がない場合は、エントリーにプル要求自体へのリンクが含まれている必要があります。" - -#: ../../rst/community/development_process.rst:187 -msgid "Most changelog entries will be ``bugfixes`` or ``minor_changes``. When writing a changelog entry that pertains to a particular module, start the entry with ``- [module name] -`` and the following sentence with a lowercase letter." -msgstr "ほとんどの changelog エントリーは ``bugfixes`` または ``minor_changes`` になります。特定のモジュールに関連する changelog エントリーを作成する場合は、そのエントリーを ``- [module name] -`` で始め、続く文章は小文字で表します。" - -#: ../../rst/community/development_process.rst:189 -msgid "Here are some examples:" -msgstr "以下に例を示します。" - -#: ../../rst/community/development_process.rst:209 -msgid "You can find more example changelog fragments in the `changelog directory `_ for the 2.10 release." -msgstr "changelog フラグメントの例は、2.10 リリースの `changelog ディレクトリー `_ もあります。" - -#: ../../rst/community/development_process.rst:211 -msgid "After you have written the changelog fragment for your PR, commit the file and include it with the pull request." -msgstr "プル要求用に changelog フラグメントを作成したら、ファイルをコミットし、プル要求に追加します。" - -#: ../../rst/community/development_process.rst:216 -msgid "Backporting merged PRs in ``ansible-base``" -msgstr "``ansible-base`` にマージされたプル要求のバックポート" - -#: ../../rst/community/development_process.rst:218 -msgid "All ``ansible-base`` PRs must be merged to the ``devel`` branch first. After a pull request has been accepted and merged to the ``devel`` branch, the following instructions will help you create a pull request to backport the change to a previous stable branch." -msgstr "``ansible-base`` のプル要求はすべて、最初に ``devel`` ブランチにマージする必要があります。プル要求を受け入れて、``devel`` ブランチにマージした後、以下の手順でプル要求を作成して、変更を以前の安定したブランチにバックポートします。" - -#: ../../rst/community/development_process.rst:220 -msgid "We do **not** backport features." -msgstr "機能のバックポートは **行いません**。" - -#: ../../rst/community/development_process.rst:224 -msgid "These instructions assume that:" -msgstr "これらの手順は、以下を前提としています。" - -#: ../../rst/community/development_process.rst:226 -msgid "``stable-2.10`` is the targeted release branch for the backport" -msgstr "``stable-2.10`` は、バックポートのターゲットリリースブランチです。" - -#: ../../rst/community/development_process.rst:227 -msgid "``https://github.com/ansible/ansible.git`` is configured as a ``git remote`` named ``upstream``. If you do not use a ``git remote`` named ``upstream``, adjust the instructions accordingly." -msgstr "``https://github.com/ansible/ansible.git`` は、``upstream`` という名前の ``git remote`` として設定されます。``upstream`` という名前の ``git remote`` を使用しない場合は、適切に手順を調整します。" - -#: ../../rst/community/development_process.rst:230 -msgid "``https://github.com//ansible.git`` is configured as a ``git remote`` named ``origin``. If you do not use a ``git remote`` named ``origin``, adjust the instructions accordingly." -msgstr "``https://github.com//ansible.git`` は、``origin`` という名前の ``git remote`` として設定されます。``origin`` という名前の ``git remote`` を使用しない場合は、適切に手順を調整します。" - -#: ../../rst/community/development_process.rst:234 -msgid "Prepare your devel, stable, and feature branches:" -msgstr "devel、stable、および feature のブランチを準備します。" - -#: ../../rst/community/development_process.rst:241 -msgid "Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary:" -msgstr "devel ブランチから関連するコミットの SHA を自身の feature ブランチに選別して、必要に応じてマージの競合を処理します。" - -#: ../../rst/community/development_process.rst:248 -msgid "Add a :ref:`changelog fragment ` for the change, and commit it." -msgstr "変更には :ref:`changelog フラグメント ` を追加し、コミットします。" - -#: ../../rst/community/development_process.rst:250 -msgid "Push your feature branch to your fork on GitHub:" -msgstr "feature ブランチを GitHub のフォークにプッシュします。" - -#: ../../rst/community/development_process.rst:256 -msgid "Submit the pull request for ``backport/2.10/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.10`` branch" -msgstr "``stable-2.10`` ブランチに、``backport/2.10/[PR_NUMBER_FROM_DEVEL]`` のプル要求を送信します。" - -#: ../../rst/community/development_process.rst:259 -msgid "The Release Manager will decide whether to merge the backport PR before the next minor release. There isn't any need to follow up. Just ensure that the automated tests (CI) are green." -msgstr "次のマイナーリリースまでにバックポートのプル要求をマージするかどうかはリリースマネージャーが判断します。フォローアップの必要はありません。自動テスト (CI) に問題が発生していないことを確認するだけです。" - -#: ../../rst/community/development_process.rst:265 -msgid "The choice to use ``backport/2.10/[PR_NUMBER_FROM_DEVEL]`` as the name for the feature branch is somewhat arbitrary, but conveys meaning about the purpose of that branch. It is not required to use this format, but it can be helpful, especially when making multiple backport PRs for multiple stable branches." -msgstr "feature ブランチの名前に ``backport/2.10/[PR_NUMBER_FROM_DEVEL]`` を使用する選択は任意ですが、そのブランチの目的を伝えています。この形式を使うことは必須ではありませんが、特に複数の安定したブランチに対して、複数のバックポートのプル要求を作成する場合に役立ちます。" - -#: ../../rst/community/development_process.rst:273 -msgid "If you prefer, you can use CPython's cherry-picker tool (``pip install --user 'cherry-picker >= 1.3.2'``) to backport commits from devel to stable branches in Ansible. Take a look at the `cherry-picker documentation `_ for details on installing, configuring, and using it." -msgstr "必要に応じて、CPython の cherry-picker ツール (``pip install --user 'cherry-picker >= 1.3.2'``) を使用して、Ansible の devel から安定したブランチへのコミットをバックポートすることができます。インストール、設定、および使用方法の詳細は、「`cherry-picker のドキュメント `_」を参照してください。" - -#: ../../rst/community/documentation_contributions.rst:5 -msgid "Contributing to the Ansible Documentation" -msgstr "Ansible ドキュメントへの貢献" - -#: ../../rst/community/documentation_contributions.rst:7 -msgid "Ansible has a lot of documentation and a small team of writers. Community support helps us keep up with new features, fixes, and changes." -msgstr "Ansible ではドキュメントが多数提供されていますが、ドキュメントを作成するチームは小規模です。新機能、修正、および変更の情報を常に最新に保つには、コミュニティーによるサポートが重要です。" - -#: ../../rst/community/documentation_contributions.rst:9 -msgid "Improving the documentation is an easy way to make your first contribution to the Ansible project. You do not have to be a programmer, since most of our documentation is written in YAML (module documentation) or `reStructuredText `_ (rST). Some collection-level documentation is written in a subset of `Markdown `_. If you are using Ansible, you already use YAML in your playbooks. rST and Markdown are mostly just text. You do not even need git experience, if you use the ``Edit on GitHub`` option." -msgstr "ドキュメントへの改善は、Ansible プロジェクトへの最初の貢献として適しています。本ガイドの大部分は YAML (モジュールドキュメント) または `reStructuredText `_ (rST) で記述されているため、貢献者がプログラマーである必要はありません。コレクションレベルのドキュメントの一部は、`マークダウン `_ のサブセットに記述されています。Ansible を使用している場合は、Playbook ですでに YAML を使用しています。そして、rST および Markdown はほとんどがテキストです。``Edit on GitHub`` オプションを使用すれば、git の経験も必要ではありません。" - -#: ../../rst/community/documentation_contributions.rst:11 -msgid "If you find a typo, a broken example, a missing topic, or any other error or omission on this documentation website, let us know. Here are some ways to support Ansible documentation:" -msgstr "このドキュメントの Web サイトで、タ誤字や不備のある例、欠落しているトピック、またはその他のエラーや省略を見つけたらご連絡ください。Ansible ドキュメントをサポートする方法は次のとおりです。" - -#: ../../rst/community/documentation_contributions.rst:17 -msgid "Editing docs directly on GitHub" -msgstr "GitHub でドキュメントを直接編集" - -#: ../../rst/community/documentation_contributions.rst:19 -msgid "For typos and other quick fixes, you can edit most of the documentation right from the site. Look at the top right corner of this page. That ``Edit on GitHub`` link is available on all the guide pages in the documentation. If you have a GitHub account, you can submit a quick and easy pull request this way." -msgstr "入力ミスやその他の簡単な修正は、サイトから直接ドキュメントを編集できます。このページの右上を見てください。``Edit on GitHub`` リンクは、ドキュメント内のすべてのページで利用できます。GitHub アカウントがある場合は、この方法で迅速かつ簡単なプル要求を送信できます。" - -#: ../../rst/community/documentation_contributions.rst:23 -msgid "The source files for individual collection plugins exist in their respective repositories. Follow the link to the collection on Galaxy to find where the repository is located and any guidelines on how to contribute to that collection." -msgstr "個別のコレクションプラグインのソースファイルがそれぞれのリポジトリーに存在します。Galaxy 上のコレクションへのリンクに従い、リポジトリーの場所と、そのコレクションへの貢献方法を確認してください。" - -#: ../../rst/community/documentation_contributions.rst:25 -msgid "To submit a documentation PR from docs.ansible.com with ``Edit on GitHub``:" -msgstr "``Edit on GitHub`` で docs.ansible.com からドキュメント PR を送信するには、以下を行います。" - -#: ../../rst/community/documentation_contributions.rst:27 -msgid "Click on ``Edit on GitHub``." -msgstr "``Edit on GitHub`` をクリックします。" - -#: ../../rst/community/documentation_contributions.rst:28 -msgid "If you don't already have a fork of the ansible repo on your GitHub account, you'll be prompted to create one." -msgstr "GitHub アカウントで ansible リポジトリーのフォークを所有していない場合は、作成するように促されます。" - -#: ../../rst/community/documentation_contributions.rst:29 -msgid "Fix the typo, update the example, or make whatever other change you have in mind." -msgstr "タイプミスを修正したり、例文を更新したり、その他の変更を加えたりします。" - -#: ../../rst/community/documentation_contributions.rst:30 -msgid "Enter a commit message in the first rectangle under the heading ``Propose file change`` at the bottom of the GitHub page. The more specific, the better. For example, \"fixes typo in my_module description\". You can put more detail in the second rectangle if you like. Leave the ``+label: docsite_pr`` there." -msgstr "GitHub ページの一番下にある ``Propose file change`` という見出しの下にある最初の四角い部分にコミットメッセージを入力します。より具体的な方が望ましいです。たとえば「fixes typo in my_module description (my_module の説明にあるタイポを修正)」といった具合です。2 つの目の四角い部分に詳細を記入することもできます。ここで、``+label: docsite_pr`` はそのままにしておきます。" - -#: ../../rst/community/documentation_contributions.rst:31 -msgid "Submit the suggested change by clicking on the green \"Propose file change\" button. GitHub will handle branching and committing for you, and open a page with the heading \"Comparing Changes\"." -msgstr "緑色の「Propose file change」ボタンをクリックして、提案する変更を送信します。GitHub がブランチを作成してコミットを行い、「Comparing Changes」という見出しのページが開きます。" - -#: ../../rst/community/documentation_contributions.rst:32 -msgid "Click on ``Create pull request`` to open the PR template." -msgstr "``Create pull request`` をクリックして PR テンプレートを開きます。" - -#: ../../rst/community/documentation_contributions.rst:33 -msgid "Fill out the PR template, including as much detail as appropriate for your change. You can change the title of your PR if you like (by default it's the same as your commit message). In the ``Issue Type`` section, delete all lines except the ``Docs Pull Request`` line." -msgstr "PR テンプレートには、変更に適した詳細などを記入します。PR のタイトルは、必要に応じて変更できます (デフォルトでは、コミットメッセージと同じタイトルになっています)。``Issue Type`` セクションで、``Docs Pull Request`` 行を除くすべての行を削除します。" - -#: ../../rst/community/documentation_contributions.rst:34 -msgid "Submit your change by clicking on ``Create pull request`` button." -msgstr "``Create pull request`` ボタンをクリックして、変更内容を送信します。" - -#: ../../rst/community/documentation_contributions.rst:35 -msgid "Be patient while Ansibot, our automated script, adds labels, pings the docs maintainers, and kicks off a CI testing run." -msgstr "Ansibot という名前の自動スクリプトがラベルを追加し、ドキュメントのメンテナーに通知を送り、CI テストが開始されるのをお待ちください。" - -#: ../../rst/community/documentation_contributions.rst:36 -msgid "Keep an eye on your PR - the docs team may ask you for changes." -msgstr "送信した PR に注意を払い続けてください。ドキュメントチームから変更を依頼される場合があります。" - -#: ../../rst/community/documentation_contributions.rst:39 -msgid "Reviewing open PRs and issues" -msgstr "PR および問題の確認" - -#: ../../rst/community/documentation_contributions.rst:41 -#, python-format -msgid "You can also contribute by reviewing open documentation `issues `_ and `PRs `_. To add a helpful review, please:" -msgstr "開いているドキュメントの `問題 (issue) `_ および `プル要求 `_ を確認することで貢献することもできます。役に立つレビューを追加するには、以下を参照してください。" - -#: ../../rst/community/documentation_contributions.rst:43 -msgid "Include a comment - \"looks good to me\" only helps if we know why." -msgstr "「looks good to me (私には良さそうに見える)」というコメントは、他の人にもその理由が明らかな場合にのみ使用してください。" - -#: ../../rst/community/documentation_contributions.rst:44 -msgid "For issues, reproduce the problem." -msgstr "問題がある場合は、問題を再現してください。" - -#: ../../rst/community/documentation_contributions.rst:45 -msgid "For PRs, test the change." -msgstr "PR については、変更をテストしてください。" - -#: ../../rst/community/documentation_contributions.rst:48 -msgid "Opening a new issue and/or PR" -msgstr "新しい問題または PR を開く" - -#: ../../rst/community/documentation_contributions.rst:50 -msgid "If the problem you have noticed is too complex to fix with the ``Edit on GitHub`` option, and no open issue or PR already documents the problem, please open an issue and/or a PR on the correct underlying repo - ``ansible/ansible`` for most pages that are not plugin or module documentation. If the documentation page has no ``Edit on GitHub`` option, check if the page is for a module within a collection. If so, follow the link to the collection on Galaxy and select the ``repo`` button in the upper right corner to find the source repository for that collection and module. The Collection README file should contain information on how to contribute to that collection, or report issues." -msgstr "気づいた問題が複雑すぎて ``Edit on GitHub`` オプションでは修正できず、その問題が報告されていなかったり、プル要求が作成されていない場合は、正しい基盤のリポジトリーで問題またはプル要求を作成してください (プラグインやモジュールのドキュメント以外のほとんどのページについては、``ansible/ansible`` で問題またはプル要求を作成してください)。ドキュメントページに ``Edit on GitHub`` オプションがない場合は、そのページがコレクション内のモジュール用であるかどうかを確認します。その場合は、Galaxy のコレクションへのリンクに従い、右上隅の ``repo`` ボタンを選択して、そのコレクションとモジュールのソースリポジトリーを見つけてください。コレクション README ファイルには、そのコレクションへの貢献方法、または問題を報告する方法に関する情報が含まれているはずです。" - -#: ../../rst/community/documentation_contributions.rst:52 -msgid "A great documentation GitHub issue or PR includes:" -msgstr "GitHub の問題や PR には、以下のような内容を追加してください。" - -#: ../../rst/community/documentation_contributions.rst:54 -msgid "a specific title" -msgstr "特定のタイトル" - -#: ../../rst/community/documentation_contributions.rst:55 -msgid "a detailed description of the problem (even for a PR - it's hard to evaluate a suggested change unless we know what problem it's meant to solve)" -msgstr "問題の詳細な説明 (何が問題なのか分からないと変更案の評価が困難になるため、プル要求の場合でも同様)" - -#: ../../rst/community/documentation_contributions.rst:56 -msgid "links to other information (related issues/PRs, external documentation, pages on docs.ansible.com, and so on)" -msgstr "その他の情報 (関連する問題やプル要求、外部ドキュメント、docs.ansible.com のページなど) へのリンク" - -#: ../../rst/community/documentation_contributions.rst:60 -msgid "Verifying your documentation PR" -msgstr "ドキュメントプル要求の確認" - -#: ../../rst/community/documentation_contributions.rst:62 -msgid "If you make multiple changes to the documentation on ``ansible/ansible``, or add more than a line to it, before you open a pull request, please:" -msgstr "``ansible/ansible`` のドキュメントに複数の変更を加えたり、複数の行を追加したりする場合は、プル要求を開始する前に、以下を行います。" - -#: ../../rst/community/documentation_contributions.rst:64 -msgid "Check that your text follows our :ref:`style_guide`." -msgstr "記述した内容が、:ref:`style_guide` に従っていることを確認してください。" - -#: ../../rst/community/documentation_contributions.rst:65 -msgid "Test your changes for rST errors." -msgstr "変更した内容が rST のエラーになっていないかテストしてください。" - -#: ../../rst/community/documentation_contributions.rst:66 -msgid "Build the page, and preferably the entire documentation site, locally." -msgstr "ページ、できればドキュメントサイト全体をローカルでビルドします。" - -#: ../../rst/community/documentation_contributions.rst:70 -msgid "The following sections apply to documentation sourced from the ``ansible/ansible`` repo and does not apply to documentation from an individual collection. See the collection README file for details on how to contribute to that collection." -msgstr "以下のセクションは、``ansible/ansible`` リポジトリーから取得したドキュメントに適用され、個別のコレクションからのドキュメントには適用されません。そのコレクションへの貢献方法は、コレクションの README ファイルを参照してください。" - -#: ../../rst/community/documentation_contributions.rst:73 -msgid "Setting up your environment to build documentation locally" -msgstr "ローカルにドキュメントをビルドするための環境設定" - -#: ../../rst/community/documentation_contributions.rst:75 -msgid "To build documentation locally, ensure you have a working :ref:`development environment `." -msgstr "ローカルにドキュメントをビルドするには、:ref:`開発環境 ` が有効であることを確認します。" - -#: ../../rst/community/documentation_contributions.rst:77 -msgid "To work with documentation on your local machine, you need to have python-3.5 or greater and the following packages installed:" -msgstr "ローカルマシンでドキュメントを扱うには、python-3.5 以降と、以下のパッケージがインストールされている必要があります。" - -#: ../../rst/community/documentation_contributions.rst:80 -msgid "gcc" -msgstr "gcc" - -#: ../../rst/community/documentation_contributions.rst:81 -msgid "jinja2" -msgstr "jinja2" - -#: ../../rst/community/documentation_contributions.rst:82 -msgid "libyaml" -msgstr "libyaml" - -#: ../../rst/community/documentation_contributions.rst:83 -msgid "Pygments >= 2.4.0" -msgstr "Pygments 2.4.0 以降" - -#: ../../rst/community/documentation_contributions.rst:84 -msgid "pyparsing" -msgstr "pyparsing" - -#: ../../rst/community/documentation_contributions.rst:85 -msgid "PyYAML" -msgstr "PyYAML" - -#: ../../rst/community/documentation_contributions.rst:86 -msgid "rstcheck" -msgstr "rstcheck" - -#: ../../rst/community/documentation_contributions.rst:87 -msgid "six" -msgstr "six" - -#: ../../rst/community/documentation_contributions.rst:88 -msgid "sphinx" -msgstr "sphinx" - -#: ../../rst/community/documentation_contributions.rst:89 -msgid "sphinx-notfound-page" -msgstr "sphinx-notfound-page" - -#: ../../rst/community/documentation_contributions.rst:90 -msgid "straight.plugin" -msgstr "straight.plugin" - -#: ../../rst/community/documentation_contributions.rst:92 -msgid "These required packages are listed in two :file:`requirements.txt` files to make installation easier:" -msgstr "これらの必要なパッケージは、インストールを容易にするために、2 つの :file:`requirements.txt` ファイルに一覧表示されています。" - -#: ../../rst/community/documentation_contributions.rst:99 -msgid "You can drop ``--user`` if you have set up a virtual environment (venv/virtenv)." -msgstr "仮想環境 (venv/virtenv) を設定している場合は、``--user`` を削除することができます。" - -#: ../../rst/community/documentation_contributions.rst:103 -msgid "On macOS with Xcode, you may need to install ``six`` and ``pyparsing`` with ``--ignore-installed`` to get versions that work with ``sphinx``." -msgstr "Xcode を使用する macOS では、``--ignore-installed`` を使用して ``six`` および ``pyparsing`` をインストールして、``sphinx``. に対応するバージョンを取得しないといけない場合があります。" - -#: ../../rst/community/documentation_contributions.rst:107 -msgid "After checking out ``ansible/ansible``, make sure the ``docs/docsite/rst`` directory has strict enough permissions. It should only be writable by the owner's account. If your default ``umask`` is not 022, you can use ``chmod go-w docs/docsite/rst`` to set the permissions correctly in your new branch. Optionally, you can set your ``umask`` to 022 to make all newly created files on your system (including those created by ``git clone``) have the correct permissions." -msgstr "``ansible/ansible`` をチェックアウトしたら、``docs/docsite/rst`` ディレクトリーに十分なパーミッションが付与されていることを確認します。所有者のアカウントのみが書き込み可能でなければなりません。デフォルトの ``umask`` が 022 ではない場合は、``chmod go-w docs/docsite/rst`` を使用して新規ブランチにパーミッションを正しく設定することができます。必要に応じて、``umask`` を 022 に設定して、システムで新に作成されるすべてのファイル (``git clone`` が作成したファイルを含む) に正しいパーミッションを設定することができます。" - -#: ../../rst/community/documentation_contributions.rst:112 -msgid "Testing the documentation locally" -msgstr "ドキュメントのローカルでのテスト" - -#: ../../rst/community/documentation_contributions.rst:114 -msgid "To test an individual file for rST errors:" -msgstr "rST エラーに対して個別のファイルをテストするには、以下を行います。" - -#: ../../rst/community/documentation_contributions.rst:121 -msgid "Building the documentation locally" -msgstr "ローカルでのドキュメントのビルド" - -#: ../../rst/community/documentation_contributions.rst:123 -msgid "Building the documentation is the best way to check for errors and review your changes. Once `rstcheck` runs with no errors, navigate to ``ansible/docs/docsite`` and then build the page(s) you want to review." -msgstr "ドキュメントのビルドは、エラーと変更を確認するのに最適な方法です。エラーなしで `rstcheck` を実行したら、``ansible/docs/docsite`` に移動し、確認するページをビルドします。" - -#: ../../rst/community/documentation_contributions.rst:126 -msgid "Building a single rST page" -msgstr "単一の rST ページのビルド" - -#: ../../rst/community/documentation_contributions.rst:128 -msgid "To build a single rST file with the make utility:" -msgstr "make ユーティリティーで単一の RST ファイルをビルドするには、以下を実行します。" - -#: ../../rst/community/documentation_contributions.rst:134 -#: ../../rst/community/documentation_contributions.rst:187 -msgid "For example:" -msgstr "例:" - -#: ../../rst/community/documentation_contributions.rst:140 -msgid "This process compiles all the links but provides minimal log output. If you're writing a new page or want more detailed log output, refer to the instructions on :ref:`build_with_sphinx-build`" -msgstr "このプロセスはすべてのリンクをコンパイルしますが、ログ出力は最小限になります。新しいページを作成する場合や、より詳細なログ出力が必要な場合は、「:ref:`build_with_sphinx-build`」の手順を参照してください。" - -#: ../../rst/community/documentation_contributions.rst:144 -msgid "``make htmlsingle`` adds ``rst/`` to the beginning of the path you provide in ``rst=``, so you can't type the filename with autocomplete. Here are the error messages you will see if you get this wrong:" -msgstr "``make htmlsingle`` は、``rst=`` で提供されるパスの先頭に ``rst/`` を追加するため、自動補完でファイル名を入力することができません。これが間違っている場合は、以下のようなエラーメッセージが表示されます。" - -#: ../../rst/community/documentation_contributions.rst:146 -msgid "If you run ``make htmlsingle`` from the ``docs/docsite/rst/`` directory: ``make: *** No rule to make target `htmlsingle'. Stop.``" -msgstr "``docs/docsite/rst/`` ディレクトリーから ``make htmlsingle`` を実行した場合は、``make: *** No rule to make target `htmlsingle'. Stop.`` メッセージが表示されます。" - -#: ../../rst/community/documentation_contributions.rst:147 -msgid "If you run ``make htmlsingle`` from the ``docs/docsite/`` directory with the full path to your rST document: ``sphinx-build: error: cannot find files ['rst/rst/community/documentation_contributions.rst']``." -msgstr "rST ドキュメントへの完全パスを使用して ``docs/docsite/`` ディレクトリーから ``make htmlsingle`` を実行した場合は、``sphinx-build: error: cannot find files ['rst/rst/community/documentation_contributions.rst']`` メッセージが表示されます。" - -#: ../../rst/community/documentation_contributions.rst:151 -msgid "Building all the rST pages" -msgstr "すべての rST ページのビルド" - -#: ../../rst/community/documentation_contributions.rst:153 -msgid "To build all the rST files without any module documentation:" -msgstr "モジュールのドキュメント以外のすべての rST ファイルをビルドするには、以下を実行します。" - -#: ../../rst/community/documentation_contributions.rst:160 -msgid "Building module docs and rST pages" -msgstr "モジュールドキュメントと rST ページのビルド" - -#: ../../rst/community/documentation_contributions.rst:162 -msgid "To build documentation for a few modules included in ``ansible/ansible`` plus all the rST files, use a comma-separated list:" -msgstr "``ansible/ansible`` に含まれるいくつかのモジュールとすべての rST ファイルを使用してドキュメントをビルドするには、コンマ区切りリストを使用します。" - -#: ../../rst/community/documentation_contributions.rst:168 -msgid "To build all the module documentation plus all the rST files:" -msgstr "すべてのモジュールドキュメントとすべての rST ファイルをビルドするには、以下を実行します。" - -#: ../../rst/community/documentation_contributions.rst:177 -msgid "Building rST files with ``sphinx-build``" -msgstr "``sphinx-build`` で rST ファイルのビルド" - -#: ../../rst/community/documentation_contributions.rst:179 -msgid "Advanced users can build one or more rST files with the sphinx utility directly. ``sphinx-build`` returns misleading ``undefined label`` warnings if you only build a single page, because it does not create internal links. However, ``sphinx-build`` returns more extensive syntax feedback, including warnings about indentation errors and ``x-string without end-string`` warnings. This can be useful, especially if you're creating a new page from scratch. To build a page or pages with ``sphinx-build``:" -msgstr "上級ユーザーは、sphinx ユーティリティーを直接使用して 1 つ以上の rST ファイルをビルドすることができます。``sphinx-build`` は、内部リンクが作成されないため、1 ページのみをビルドする場合は、誤解を招く ``undefined label`` 警告を返します。ただし、``sphinx-build`` は、インデントエラーや ``x-string without end-string`` 警告など、より広範な構文のフィードバックを返します。これは特に、ゼロから新しいページを作成している場合に役に立ちます。``sphinx-build`` でページをビルドするには、以下のようにします。" - -#: ../../rst/community/documentation_contributions.rst:185 -msgid "You can specify filenames, or ``–a`` for all files, or omit both to compile only new/changed files." -msgstr "ファイル名を指定することもできますし、すべてのファイルに ``–a`` を指定することもできます。もしくは、両方を省略して新しいまたは変更されたファイルだけをコンパイルすることもできます。" - -#: ../../rst/community/documentation_contributions.rst:194 -msgid "Running the final tests" -msgstr "最終テストの実行" - -#: ../../rst/community/documentation_contributions.rst:196 -msgid "When you submit a documentation pull request, automated tests are run. Those same tests can be run locally. To do so, navigate to the repository's top directory and run:" -msgstr "ドキュメントのプル要求を送信すると、自動テストが実行します。同じテストをローカルで実行できます。これを行うには、リポジトリーの最上位ディレクトリーに移動し、以下を実行します。" - -#: ../../rst/community/documentation_contributions.rst:204 -msgid "Unfortunately, leftover rST-files from previous document-generating can occasionally confuse these tests. It is therefore safest to run them on a clean copy of the repository, which is the purpose of ``make clean``. If you type these three lines one at a time and manually check the success of each, you do not need the ``&&``." -msgstr "ただし、以前ドキュメントを生成した時の rST ファイルが残っていると、このテストを混乱させることがあります。そのため、リポジトリーのクリーンコピー上で実行するのが最も安全です。これが、``make clean`` の目的でもあります。この 3 つの行を一度に 1 行ずつ入力して、各行が成功したことを手動で確認する場合、``&&`` は必要ありません。" - -#: ../../rst/community/documentation_contributions.rst:207 -msgid "Joining the documentation working group" -msgstr "ドキュメントワーキンググループへの参加" - -#: ../../rst/community/documentation_contributions.rst:209 -msgid "The Documentation Working Group (DaWGs) meets weekly on Tuesdays on the #ansible-docs channel on freenode IRC. For more information, including links to our agenda and a calendar invite, please visit the `working group page in the community repo `_." -msgstr "ドキュメントワーキンググループ (DaWGs)は、freenode IRC 上の #ansible-docs チャンネルで、毎週木曜日に集まっています。議題へのリンクや、カレンダーの招待状などの詳細は、「`コミュニティーレポジトリーのワーキンググループページ `_」をご覧ください。" - -#: ../../rst/community/documentation_contributions.rst:212 -msgid ":ref:`More about testing module documentation `" -msgstr ":ref:`More about testing module documentation `" - -#: ../../rst/community/documentation_contributions.rst:214 -msgid ":ref:`More about documenting modules `" -msgstr ":ref:`More about documenting modules `" - -#: ../../rst/community/github_admins.rst:5 -msgid "GitHub Admins" -msgstr "GitHub 管理者" - -#: ../../rst/community/github_admins.rst:9 -msgid "GitHub Admins have more permissions on GitHub than normal contributors or even committers. There are a few responsibilities that come with that increased power." -msgstr "GitHub 管理者には、通常の貢献者や、コミットするユーザーよりも多くの権限が付与されています。このように権限の増加に伴い、いくつかの責任が発生します" - -#: ../../rst/community/github_admins.rst:14 -msgid "Adding and removing committers" -msgstr "コミットを行うユーザーの追加および削除" - -#: ../../rst/community/github_admins.rst:16 -msgid "The Ansible Team will periodically review who is actively contributing to Ansible to grant or revoke contributors' ability to commit on their own. GitHub Admins are the people who have the power to actually manage the GitHub permissions." -msgstr "Ansible チームは、誰が Ansible に積極的に貢献しているかを定期的に確認して、貢献者のコミット権限を許可したり取り消したりします。GitHub 管理者は、GitHub パーミッションを実際に管理する権限を持つユーザーです。" - -#: ../../rst/community/github_admins.rst:22 -msgid "Changing branch permissions for releases" -msgstr "リリースのブランチパーミッションの変更" - -#: ../../rst/community/github_admins.rst:24 -msgid "When we make releases we make people go through a :ref:`release_managers` to push commits to that branch. The GitHub admins are responsible for setting the branch so only the Release Manager can commit to the branch when the release process reaches that stage and later opening the branch once the release has been made. The Release manager will let the GitHub Admin know when this needs to be done." -msgstr "リリースを行う場合は、:ref:`release_managers` に沿って、そのブランチへのコミットをプッシュします。GitHub 管理者には、リリースプロセスがその段階に達したときにリリースマネージャーだけがブランチにコミットできるようにブランチを設定し、リリースが完了した後にブランチを開く責任があります。この設定が必要になると、リリースマネージャーが GitHub 管理者に知らせます。" - -#: ../../rst/community/github_admins.rst:30 -msgid "The `GitHub Admin Process Docs `_ for instructions on how to change branch permissions." -msgstr "ブランチパーミッションを変更する方法は、「`GitHub Admin Process Docs `_」を参照してください。" - -#: ../../rst/community/how_can_I_help.rst:5 -msgid "How can I help?" -msgstr "貢献方法" - -#: ../../rst/community/how_can_I_help.rst:10 -msgid "Thanks for being interested in helping the Ansible project!" -msgstr "Ansible プロジェクトを支援することに関心をお寄せいただきありがとうございます。" - -#: ../../rst/community/how_can_I_help.rst:12 -msgid "There are many ways to help the Ansible project...but first, please read and understand the :ref:`code_of_conduct`." -msgstr "Ansible プロジェクトを支援する方法は多数ありますが、まずは「:ref:`code_of_conduct`」を読んで理解してください。" - -#: ../../rst/community/how_can_I_help.rst:15 -msgid "Become a power user" -msgstr "パワーユーザーになる" - -#: ../../rst/community/how_can_I_help.rst:17 -msgid "A great way to help the Ansible project is to become a power user:" -msgstr "Ansible プロジェクトを支援する素晴らしい方法は、パワーユーザーになることです。" - -#: ../../rst/community/how_can_I_help.rst:19 -msgid "Use Ansible everywhere you can" -msgstr "Ansible をできる限り使用する。" - -#: ../../rst/community/how_can_I_help.rst:20 -msgid "Take tutorials and classes" -msgstr "チュートリアルやクラスを受講する。" - -#: ../../rst/community/how_can_I_help.rst:21 -msgid "Read the :ref:`official documentation `" -msgstr ":ref:`公式ドキュメント ` を読む。" - -#: ../../rst/community/how_can_I_help.rst:22 -msgid "Study some of the `many excellent books `_ about Ansible" -msgstr "Ansible に関する `多くの優れた書籍 `_ の中からいくつか選んで勉強する。" - -#: ../../rst/community/how_can_I_help.rst:23 ../../rst/community/index.rst:31 -msgid "`Get certified `_." -msgstr "`認定を受ける `。" - -#: ../../rst/community/how_can_I_help.rst:25 -msgid "When you become a power user, your ability and opportunities to help the Ansible project in other ways will multiply quickly." -msgstr "パワーユーザーになると、Ansible プロジェクトを他の方法で支援する能力と機会が急速に増えます。" - -#: ../../rst/community/how_can_I_help.rst:28 -msgid "Ask and answer questions online" -msgstr "オンラインで質問し、質問に回答" - -#: ../../rst/community/how_can_I_help.rst:30 -msgid "There are many forums online where Ansible users ask and answer questions. Reach out and communicate with your fellow Ansible users." -msgstr "オンラインには、Ansible ユーザーが質問をしたり、質問に答えたりするフォーラムが多数あります。他の Ansible ユーザーに連絡してコミュニケーションを行いましょう。" - -#: ../../rst/community/how_can_I_help.rst:32 -msgid "You can find the official :ref:`Ansible communication channels `." -msgstr "公式の :ref:`Ansible コミュニケーションチャンネル ` があります。" - -#: ../../rst/community/how_can_I_help.rst:35 -msgid "Review, fix, and maintain the documentation" -msgstr "ドキュメントの確認、修正、および維持" - -#: ../../rst/community/how_can_I_help.rst:37 -msgid "Typos are everywhere, even in the Ansible documentation. We work hard to keep the documentation up-to-date, but you may also find outdated examples. We offer easy ways to :ref:`report and/or fix documentation errors `." -msgstr "Ansible ドキュメントに誤字が含まれる場合があります。ドキュメントを最新の状態に保つように努めていますが、古い例が見つかる場合もあります。:ref:`ドキュメントエラーを報告または修正する ` 簡単な方法を提供しています。" - -#: ../../rst/community/how_can_I_help.rst:42 -msgid "Participate in your local meetup" -msgstr "各地の Meetup に参加" - -#: ../../rst/community/how_can_I_help.rst:44 -msgid "There are Ansible meetups `all over the world `_. Join your local meetup. Attend regularly. Ask good questions. Volunteer to give a presentation about how you use Ansible." -msgstr "Ansible の Meetup は `世界中 `_ で開催されています。お住いの地域で開催される Meetup に参加してください。定期的に参加してください。質問をしてください。Ansible の使用方法に関するプレゼンテーションを自発的に行ってください。" - -#: ../../rst/community/how_can_I_help.rst:46 -msgid "If there is no meetup near you, we are happy to help you `start one `_." -msgstr "お近くで Meetup が開催されない場合は、`新たに開催する `_ ことをお手伝いします。" - -#: ../../rst/community/how_can_I_help.rst:49 -msgid "File and verify issues" -msgstr "問題の報告および確認" - -#: ../../rst/community/how_can_I_help.rst:51 -msgid "All software has bugs, and Ansible is no exception. When you find a bug, you can help tremendously by :ref:`telling us about it `." -msgstr "すべてのソフトウェアにはバグがあり、Ansible も例外ではありません。バグを見つけた場合は、:ref:`報告 ` していただくと非常に助かります。" - -#: ../../rst/community/how_can_I_help.rst:54 -msgid "If the bug you found already exists in an issue, you can help by verifying the behavior of the reported bug with a comment in that issue, or by reporting any additional information." -msgstr "報告しようとしているバグがすでに報告されている場合は、報告されているバグの動作をその問題のコメントで検証したり、追加情報を報告したりすることが助けになります。" - -#: ../../rst/community/how_can_I_help.rst:57 -msgid "Review and submit pull requests" -msgstr "プル要求の確認および提出" - -#: ../../rst/community/how_can_I_help.rst:59 -msgid "As you become more familiar with how Ansible works, you may be able to fix issues or develop new features yourself. If you think you have a fix for a bug in Ansible, or if you have a new feature that you would like to share with millions of Ansible users, read all about the :ref:`Ansible development process ` and and :ref:`how to contribute to collections ` to learn how to get your code accepted into Ansible." -msgstr "Ansible の機能について理解が深まると、問題を修正したり、新しい機能を自分で開発したりできるようになります。Ansible で見つかったバグの解決策を見つけた場合や、自身が作成した新機能を何百万人もの Ansible ユーザーと共有したい場合は、「:ref:`Ansible の開発プロセス `」および「:ref:`コレクションへの貢献方法 `」をよく読んで、作成したコードを Ansible に受け入れてもらう方法を学んでください。" - -#: ../../rst/community/how_can_I_help.rst:61 -msgid "Another good way to help is to review pull requests that other Ansible users have submitted. The Ansible community keeps a full list of `open pull requests by file `_, so if a particular module or plugin interests you, you can easily keep track of all the relevant new pull requests and provide testing or feedback." -msgstr "もう 1 つの貢献方法は、別の Ansible ユーザーが作成したプル要求を確認することです。Ansible コミュニティーは、`ファイルごとにオープンなプル要求 `_ の完全なリストを保持しています。したがって、特に興味のある特定のモジュールやプラグインがあれば、関連する新しいプル要求をすべて簡単に追跡して、テストやフィードバックを提供できます。" - -#: ../../rst/community/how_can_I_help.rst:64 -msgid "Become a collection maintainer" -msgstr "コレクションメンテナーになる" - -#: ../../rst/community/how_can_I_help.rst:66 -msgid "Once you have learned about the development process and have contributed code to a collection, we encourage you to become a maintainer of that collection. There are hundreds of modules in dozens of Ansible collections, and the vast majority of them are written and maintained entirely by members of the Ansible community." -msgstr "開発プロセスについて学習し、コードをコレクションに提供したら、そのコレクションのメンテナーになるよう推奨されます。Ansible には数百ものモジュールがあり、その大部分は Ansible コミュニティーのメンバーによって完全に記述され、維持されています。" - -#: ../../rst/community/how_can_I_help.rst:68 -msgid "To learn more about the responsibilities of being an Ansible module maintainer, please read our :ref:`collection maintainer guidelines `." -msgstr "Ansible モジュールメンテナーにおける責任の詳細は、「:ref:`モジュールのメンテナーガイドライン `」を参照してください。" - -#: ../../rst/community/how_can_I_help.rst:73 -msgid "Join a working group" -msgstr "ワーキンググループへの参加" - -#: ../../rst/community/how_can_I_help.rst:75 -msgid "Working groups are a way for Ansible community members to self-organize around particular topics of interest. We have working groups around various topics. To join or create a working group, please read the :ref:`Ansible Working Groups`." -msgstr "ワーキンググループは、Ansible コミュニティーのメンバーが関心のある特定のトピックについて自己編成する方法です。さまざまなトピックに関するワーキンググループがあります。ワーキンググループに参加するか、「:ref:`Ansible ワーキンググループ`」を参照してください。" - -#: ../../rst/community/how_can_I_help.rst:79 -msgid "Teach Ansible to others" -msgstr "Ansible を紹介する" - -#: ../../rst/community/how_can_I_help.rst:81 -msgid "We are working on a standardized `Ansible workshop `_ that can provide a good hands-on introduction to Ansible usage and concepts." -msgstr "現在、Ansible の使用方法や概念をしっかりとハンズオンで紹介できる標準化された `Ansible ワークショップ `_ に取り組んでいます。" - -#: ../../rst/community/how_can_I_help.rst:84 -msgid "Social media" -msgstr "ソーシャルメディア" - -#: ../../rst/community/how_can_I_help.rst:86 -msgid "If you like Ansible and just want to spread the good word, feel free to share on your social media platform of choice, and let us know by using ``@ansible`` or ``#ansible``. We'll be looking for you." -msgstr "Ansible が好きで、Ansible の良さを広めたい方は、お好きなソーシャルメディアプラットフォームで気軽にシェアしてください。コミュニティーメンバーが気が付くように、``@ansible`` または ``#ansible`` を使用することが推奨されます。" - -#: ../../rst/community/index.rst:88 -msgid "Guidelines for specific types of contributors" -msgstr "貢献者向け各ガイドライン" - -#: ../../rst/community/index.rst:5 -msgid "Ansible Community Guide" -msgstr "Ansible コミュニティーガイド" - -#: ../../rst/community/index.rst:9 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/community/index.rst:11 -msgid "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 `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ ` を参照してください。" - -#: ../../rst/community/index.rst:13 -msgid "Welcome to the Ansible Community Guide!" -msgstr "Ansible コミュニティーガイドにようこそ!" - -#: ../../rst/community/index.rst:15 -msgid "The purpose of this guide is to teach you everything you need to know about being a contributing member of the Ansible community. All types of contributions are welcome and necessary to Ansible's continued success." -msgstr "本ガイドの目的は、Ansible コミュニティーに貢献する際に必要な知識をすべて説明することです。あらゆる種類の貢献が、Ansible の継続的な成功に必要なものであり、歓迎されます。" - -#: ../../rst/community/index.rst:17 -msgid "This page outlines the most common situations and questions that bring readers to this section. If you prefer a :ref:`traditional table of contents `, you can find one at the bottom of the page." -msgstr "このページでは、本セクションにたどり着いたユーザーにとって最も一般的な状況や質問の概要を説明します。:ref:`従来の目次形式 ` をご希望のユーザー向けに、ページの一番下に目次が用意されています。" - -#: ../../rst/community/index.rst:21 -msgid "Getting started" -msgstr "はじめに" - -#: ../../rst/community/index.rst:23 -msgid "I am new to the community. Where can I find the Ansible :ref:`code_of_conduct`?" -msgstr "このコミュニティーに参加して間もないです。Ansible の :ref:`code_of_conduct` はどこで確認できますか。" - -#: ../../rst/community/index.rst:24 -msgid "I would like to know what I am agreeing to when I contribute to Ansible. Does Ansible have a :ref:`contributor_license_agreement`?" -msgstr "Ansible に貢献する際に何に同意しているのか知りたいのです。Ansible には :ref:`contributor_license_agreement` がありますか。" - -#: ../../rst/community/index.rst:25 -msgid "I would like to contribute but I am not sure how. Are there :ref:`easy ways to contribute `?" -msgstr "貢献したいのですが、方法がわかりません。:ref:`簡単に貢献する方法 ` はありますか。" - -#: ../../rst/community/index.rst:26 -msgid "I want to talk to other Ansible users. How do I find an `Ansible Meetup near me `_?" -msgstr "他の Ansible ユーザーと話をしてみたいです。`私が参加できる Ansible Meetup `_ はどのように探せばいいですか。" - -#: ../../rst/community/index.rst:27 -msgid "I have a question. Which :ref:`Ansible email lists and IRC channels ` will help me find answers?" -msgstr "質問があります。:ref:`Ansible のメーリングリストや IRC チャンネル ` で答えを見つけるにはどうすればいいですか。" - -#: ../../rst/community/index.rst:28 -msgid "I want to learn more about Ansible. What can I do?" -msgstr "Ansible についてもっと知りたいです。どうすればよいでしょうか。" - -#: ../../rst/community/index.rst:30 -msgid "`Read books `_." -msgstr "`本を読む `_。" - -#: ../../rst/community/index.rst:32 -msgid "`Attend events `_." -msgstr "`イベントに参加する `_。" - -#: ../../rst/community/index.rst:33 -msgid "`Review getting started guides `_." -msgstr "`スタートガイドを確認する `_。" - -#: ../../rst/community/index.rst:34 -msgid "`Watch videos `_ - includes Ansible Automates, AnsibleFest & webinar recordings." -msgstr "`ビデオを観る `_ (Ansible Automates、AnsibleFest、ウェビナーの録画など)。" - -#: ../../rst/community/index.rst:36 -msgid "I would like updates about new Ansible versions. How are `new releases announced `_?" -msgstr "Ansible の新しいバージョンに関する最新情報を知りたいです。`新しいリリースの発表 `_ はどのように行われますか。" - -#: ../../rst/community/index.rst:37 -msgid "I want to use the current release. How do I know which :ref:`releases are current `?" -msgstr "最新のリリースを使用したいです。:ref:`どのリリースが最新のリリース ` かを知るにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:40 -msgid "Going deeper" -msgstr "使い慣れてきた頃" - -#: ../../rst/community/index.rst:42 -msgid "I think Ansible is broken. How do I :ref:`report a bug `?" -msgstr "Ansible が破損しているように見えます。:ref:`バグを報告 ` するにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:43 -msgid "I need functionality that Ansible does not offer. How do I :ref:`request a feature `?" -msgstr "Ansible が提供していない機能が必要です。:ref:`機能を要求 ` するにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:44 -msgid "How do I :ref:`contribute to an Ansible-maintained collection `?" -msgstr ":ref:`Ansible が管理するコレクションに貢献 ` するにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:45 -msgid "I am waiting for a particular feature. How do I see what is :ref:`planned for future Ansible Releases `?" -msgstr "特定の機能が必要です。:ref:`Ansible の将来のリリースで予定されている ` ものを確認するにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:46 -msgid "I have a specific Ansible interest or expertise (for example, VMware, Linode, and so on). How do I get involved in a :ref:`working group `?" -msgstr "特定の Ansible 機能に関心がある、または専門知識があります (VMware、Linode など)。:ref:`ワーキンググループ ` に参加するにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:47 -msgid "I would like to participate in conversations about features and fixes. How do I review GitHub issues and pull requests?" -msgstr "機能や修正に関する議論に参加したいです。GitHub の問題やプル要求を確認するにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:48 -msgid "I found a typo or another problem on docs.ansible.com. How can I :ref:`improve the documentation `?" -msgstr "docs.ansible.com でタイポなどの誤りを見つけました。:ref:`ドキュメントを改善 ` するにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:49 -msgid "Is there a :ref:`mailing list ` I can sign up for to stay informed about Ansible?" -msgstr "サインアップして Ansible に関する通知を受けることができる :ref:`メーリングリスト ` はありますか。" - -#: ../../rst/community/index.rst:53 -msgid "Working with the Ansible repo" -msgstr "Ansible リポジトリーの使用" - -#: ../../rst/community/index.rst:55 -msgid "I want to make my first code changes to a collection or to ``ansible-base``. How do I :ref:`set up my Python development environment `?" -msgstr "コレクションまたは ``ansible-base`` に初めてコード変更をします。:ref:`Python 開発環境を設定 ` するにはどうしたら良いですか。" - -#: ../../rst/community/index.rst:56 -msgid "I would like to get more efficient as a developer. How can I find :ref:`editors, linters, and other tools ` that will support my Ansible development efforts?" -msgstr "開発者としてもっと効率的に作業したいです。Ansible 開発をサポートする :ref:`エディター、Linter などのツール ` はどうやって見つければ良いですか。" - -#: ../../rst/community/index.rst:57 -msgid "I want my code to meet Ansible's guidelines. Where can I find guidance on :ref:`coding in Ansible `?" -msgstr "自分のコードを Ansible のガイドラインに沿ったものにしたいです。:ref:`Ansible でのコーディング ` に関するガイダンスはどこにありますか。" - -#: ../../rst/community/index.rst:58 -msgid "I want to learn more about Ansible roadmaps, releases, and projects. How do I find information on :ref:`the development cycle `?" -msgstr "Ansible のロードマップ、リリース、およびプロジェクトについて詳しく知りたいです。:ref:`開発サイクル ` に関する情報はどこにありますか。" - -#: ../../rst/community/index.rst:59 -msgid "I would like to connect Ansible to a new API or other resource. How do I :ref:`create a collection `?" -msgstr "Ansible を新しい API やその他のリソースに接続したいです。:ref:`関連モジュールのグループに貢献 ` するにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:60 -msgid "My pull request is marked ``needs_rebase``. How do I :ref:`rebase my PR `?" -msgstr "プル要求に ``needs_rebase`` というマークが付いています。:ref:`自分のプル要求をリベース ` するにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:61 -msgid "I am using an older version of Ansible and want a bug fixed in my version that has already been fixed on the ``devel`` branch. How do I :ref:`backport a bugfix PR `?" -msgstr "Ansible の古いバージョンを使用していますが、``devel`` ブランチですでに修正されているバグを、私の使用しているバージョンで修正してほしいです。:ref:`バグ修正のプル要求 ` をバックポートするにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:62 -msgid "I have an open pull request with a failing test. How do I learn about Ansible's :ref:`testing (CI) process `?" -msgstr "オープンになっているプル要求でテストに失敗しているものがあります。Ansible の :ref:`テスト (CI) プロセス ` について学ぶにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:63 -msgid "I am ready to step up as a collection maintainer. What are the :ref:`guidelines for maintainers `?" -msgstr "コレクションメンテナーになりたいです。:ref:`メンテナー向けガイドライン ` を教えてください。" - -#: ../../rst/community/index.rst:64 -msgid "A module in a collection I maintain is obsolete. How do I :ref:`deprecate a module `?" -msgstr "私が保守しているモジュールが古くなりました。:ref:`モジュールを非推奨 ` にするにはどうすれば良いですか。" - -#: ../../rst/community/index.rst:69 -msgid "Traditional Table of Contents" -msgstr "従来の目次" - -#: ../../rst/community/index.rst:71 -msgid "If you prefer to read the entire Community Guide, here is a list of the pages in order:" -msgstr "コミュニティーガイド全体をお読みになりたい方は、こちらのページを順番にご覧ください。" - -#: ../../rst/community/maintainers.rst:5 -msgid "Collection maintainer guidelines" -msgstr "コレクションメンテナーのガイドライン" - -#: ../../rst/community/maintainers.rst:7 -msgid "Thank you for being a community collection maintainer. This guide offers an overview of your responsibilities as a maintainer along with resources for additional information. The Ansible community hopes that you will find that maintaining a collection is as rewarding for you as having the collection content is for the wider community." -msgstr "Ansible のコミュニティーコレクションのメンテナーになっていただきありがとうございます。本ガイドでは、メンテナーの責任の概要、追加情報のリソースを紹介します。Ansible コミュニティーは、コレクションのコンテンツを持つことがより広いコミュニティーにとって有益であるのと同様に、コレクションを維持することが皆様にとっても有益であると感じていただけることを願っています。" - -#: ../../rst/community/maintainers.rst:12 -msgid "In addition to the information below, module maintainers should be familiar with:" -msgstr "以下の情報に加えて、モジュールメンテナーは以下について理解しておく必要があります。" - -#: ../../rst/community/maintainers.rst:14 -msgid ":ref:`General Ansible community development practices `" -msgstr ":ref:`Ansible コミュニティー開発に関する一般的なプラクティス `" - -#: ../../rst/community/maintainers.rst:15 -msgid "Documentation on :ref:`module development `" -msgstr ":ref:`モジュール開発 ` に関するドキュメント" - -#: ../../rst/community/maintainers.rst:19 -msgid "Maintainer responsibilities" -msgstr "メンテナーの役割" - -#: ../../rst/community/maintainers.rst:21 -msgid "When you contribute a module to a collection included in the ``ansible`` package, you become a maintainer for that module once it has been merged. Maintainership empowers you with the authority to accept, reject, or request revisions to pull requests on your module -- but as they say, \"with great power comes great responsibility.\"" -msgstr "``ansible`` パッケージに含まれるコレクションにモジュールを提供し、それがマージされると、そのモジュールのメンテナーになります。メンテナーになると、主に、モジュールへのプル要求を許可、拒否、またはリクエストする権限を持つことになりますが、「権限が大きくなると責任も大きくなる」とも言えます。" - -#: ../../rst/community/maintainers.rst:23 -msgid "Maintainers of Ansible collections are expected to provide feedback, responses, or actions on pull requests or issues to the collection(s) they maintain in a reasonably timely manner. You can also update the contributor guidelines for that collection, in collaboration with the Ansible community team and the other maintainers of that collection." -msgstr "Ansible コレクションのメンテナーは、プル要求または問題に対するフィードバック、応答、またはアクションを、合理的な時間内に、維持するコレクションに提供することが期待されています。また、Ansible コミュニティーチームやそのコレクションの他のメンテナーと協力して、そのコレクションの貢献者ガイドラインを更新することもできます。" - -#: ../../rst/community/maintainers.rst:26 -msgid "Resources" -msgstr "リソース" - -#: ../../rst/community/maintainers.rst:28 -msgid "Please see :ref:`communication` for ways to contact the broader Ansible community. For maintainers, following the `ansible-devel `_ mailing list is a great way to participate in conversations about coding, get assistance when you need it, and influence the overall direction, quality, and goals of Ansible and the collections. If you are not on this relatively low-volume list, please join us here: https://groups.google.com/forum/#!forum/ansible-devel" -msgstr "幅広い Ansible コミュニティーに連絡する方法は、:ref:`communication` を参照してください。`ansible-devel `_ メーリングリストに参加することは、メンテナーにとって、コーディングに関する対話に参加し、必要に応じて支援を受け、Ansible およびコレクションの全体的な方向、品質、および目的に影響を与えるための優れた方法です。このリストに載っていない場合はhttps://groups.google.com/forum/#!forum/ansible-devel に参加してください。" - -#: ../../rst/community/maintainers.rst:32 -msgid "Pull requests, issues, and workflow" -msgstr "プル要求、問題、およびワークフロー" - -#: ../../rst/community/maintainers.rst:34 -msgid "Each collection community can set its own rules and workflow for managing pull requests, bug reports, documentation issues, and feature requests, as well as adding and replacing maintainers." -msgstr "各コレクションコミュニティーは、プル要求、バグレポート、ドキュメント問題、および機能リクエストを管理する独自のルールおよびワークフローを設定できます。また、メンテナーの追加および置き換えも可能です。" - -#: ../../rst/community/other_tools_and_programs.rst:5 -msgid "Other Tools and Programs" -msgstr "その他のツールおよびプログラム" - -#: ../../rst/community/other_tools_and_programs.rst:10 -msgid "The Ansible community uses a range of tools for working with the Ansible project. This is a list of some of the most popular of these tools." -msgstr "Ansible コミュニティーは、Ansible プロジェクトで作業するためにさまざまなツールを使用します。ここでは、これらのツールの中でも特に人気のあるものをいくつか紹介します。" - -#: ../../rst/community/other_tools_and_programs.rst:12 -msgid "If you know of any other tools that should be added, this list can be updated by clicking \"Edit on GitHub\" on the top right of this page." -msgstr "他にも追加すべきツールがあれば、このページの右上にある「Edit on GitHub」をクリックすると、この一覧を更新できます。" - -#: ../../rst/community/other_tools_and_programs.rst:16 -msgid "Popular editors" -msgstr "人気のあるエディター" - -#: ../../rst/community/other_tools_and_programs.rst:19 -msgid "Atom" -msgstr "Atom" - -#: ../../rst/community/other_tools_and_programs.rst:21 -msgid "An open-source, free GUI text editor created and maintained by GitHub. You can keep track of git project changes, commit from the GUI, and see what branch you are on. You can customize the themes for different colors and install syntax highlighting packages for different languages. You can install Atom on Linux, macOS and Windows. Useful Atom plugins include:" -msgstr "GitHub で作成および保守されるオープンソースの無料 GUI テキストエディター。git プロジェクトの変更を追跡したり、GUI からコミットしたり、自分がどのブランチにいるかを確認できます。テーマをカスタマイズして色を変えたり、言語ごとに構文強調表示パッケージをインストールしたりできます。Atom は、Linux、macOS、および Windows にインストールできます。便利な Atom プラグインには以下が含まれます。" - -#: ../../rst/community/other_tools_and_programs.rst:24 -msgid "`language-yaml `_ - YAML highlighting for Atom (built-in)." -msgstr "`language-yaml `_ - Atom での YAML の強調表示 (組み込み)。" - -#: ../../rst/community/other_tools_and_programs.rst:25 -msgid "`linter-js-yaml `_ - parses your YAML files in Atom through js-yaml." -msgstr "`linter-js-yaml `_ - js-yaml を介して Atom で YAML ファイルを解析。" - -#: ../../rst/community/other_tools_and_programs.rst:29 -msgid "Emacs" -msgstr "Emacs" - -#: ../../rst/community/other_tools_and_programs.rst:31 -msgid "A free, open-source text editor and IDE that supports auto-indentation, syntax highlighting and built in terminal shell(among other things)." -msgstr "無料でオープンソースのテキストエディターと IDE。オートインデント、構文強調表示、端末シェルでのビルドなどをサポートします。" - -#: ../../rst/community/other_tools_and_programs.rst:33 -msgid "`yaml-mode `_ - YAML highlighting and syntax checking." -msgstr "`yaml-mode `_ - YAML の強調表示と構文のチェック。" - -#: ../../rst/community/other_tools_and_programs.rst:34 -msgid "`jinja2-mode `_ - Jinja2 highlighting and syntax checking." -msgstr "`jinja2-mode `_ - Jinja2 の強調表示と構文の確認。" - -#: ../../rst/community/other_tools_and_programs.rst:35 -msgid "`magit-mode `_ - Git porcelain within Emacs." -msgstr "`magit-mode `_ - Emacs 内での git porcelain (磁器)。" - -#: ../../rst/community/other_tools_and_programs.rst:39 -msgid "PyCharm" -msgstr "PyCharm" - -#: ../../rst/community/other_tools_and_programs.rst:41 -msgid "A full IDE (integrated development environment) for Python software development. It ships with everything you need to write python scripts and complete software, including support for YAML syntax highlighting. It's a little overkill for writing roles/playbooks, but it can be a very useful tool if you write modules and submit code for Ansible. Can be used to debug the Ansible engine." -msgstr "Python ソフトウェア開発向けの完全な IDE (統合開発環境)。これには、YAML 構文強調表示のサポートを含む、Python スクリプトを記述するのに必要なすべてのものと完全なソフトウェアが同梱されています。ロール/Playbook の作成には少し時間がかかりますが、モジュールを作成し、Ansible 用のコードを送信する場合は、非常に便利なツールになります。Ansible エンジンのデバッグに使用できます。" - -#: ../../rst/community/other_tools_and_programs.rst:45 -msgid "Sublime" -msgstr "Sublime" - -#: ../../rst/community/other_tools_and_programs.rst:47 -msgid "A closed-source, subscription GUI text editor. You can customize the GUI with themes and install packages for language highlighting and other refinements. You can install Sublime on Linux, macOS and Windows. Useful Sublime plugins include:" -msgstr "クローズドソースのサブスクリプション GUI テキストエディター。テーマを使用して GUI をカスタマイズしたり、言語の強調表示やその他の改良のためのパッケージをインストールしたりすることができます。Sublime は Linux、macOS、Windows にインストールできます。便利な Sublime プラグインには以下のものがあります。" - -#: ../../rst/community/other_tools_and_programs.rst:49 -msgid "`GitGutter `_ - shows information about files in a git repository." -msgstr "`GitGutter `_ - git リポジトリー内のファイルに関する情報を表示します。" - -#: ../../rst/community/other_tools_and_programs.rst:50 -msgid "`SideBarEnhancements `_ - provides enhancements to the operations on Sidebar of Files and Folders." -msgstr "`SideBarEnhancements `_ - ファイルおよびディレクトリーのサイドバーに対する操作の強化を提供します。" - -#: ../../rst/community/other_tools_and_programs.rst:51 -msgid "`Sublime Linter `_ - a code-linting framework for Sublime Text 3." -msgstr "`Sublime Linter `_ - Sublime Text 3 のコードの文法チェックフレームワークです。" - -#: ../../rst/community/other_tools_and_programs.rst:52 -msgid "`Pretty YAML `_ - prettifies YAML for Sublime Text 2 and 3." -msgstr "`Pretty YAML `_ - Sublime Text 2 および 3 の YAML を事前設定します。" - -#: ../../rst/community/other_tools_and_programs.rst:53 -msgid "`Yamllint `_ - a Sublime wrapper around yamllint." -msgstr "`Yamllint `_ - yamllint に関する Sublime ラッパーです。" - -#: ../../rst/community/other_tools_and_programs.rst:57 -msgid "Visual studio code" -msgstr "Visual Studio コード" - -#: ../../rst/community/other_tools_and_programs.rst:59 -msgid "An open-source, free GUI text editor created and maintained by Microsoft. Useful Visual Studio Code plugins include:" -msgstr "Microsoft が作成および管理するオープンソースの無料 GUI テキストエディター。便利な Visual Studio Code プラグインには以下が含まれます。" - -#: ../../rst/community/other_tools_and_programs.rst:62 -msgid "`YAML Support by Red Hat `_ - provides YAML support through yaml-language-server with built-in Kubernetes and Kedge syntax support." -msgstr "`YAML Support by Red Hat `_ - Kubernetes と Kedge の構文サポートを組み込んだ yaml-language-server を通じて YAML サポートを提供します。" - -#: ../../rst/community/other_tools_and_programs.rst:63 -msgid "`Ansible Syntax Highlighting Extension `_ - YAML & Jinja2 support." -msgstr "`Ansible Syntax Highlighting Extension `_ - YAML および Jinja2 サポート。" - -#: ../../rst/community/other_tools_and_programs.rst:64 -msgid "`Visual Studio Code extension for Ansible `_ - provides autocompletion, syntax highlighting." -msgstr "`Visual Studio Code extension for Ansible `_ - オートコンプリート、構文強調表示を提供します。" - -#: ../../rst/community/other_tools_and_programs.rst:67 -msgid "vim" -msgstr "vim" - -#: ../../rst/community/other_tools_and_programs.rst:69 -msgid "An open-source, free command-line text editor. Useful vim plugins include:" -msgstr "オープンソースの無料コマンドラインテキストエディター。便利な vim プラグインには以下が含まれます。" - -#: ../../rst/community/other_tools_and_programs.rst:71 -msgid "`Ansible vim `_ - vim syntax plugin for Ansible 2.x, it supports YAML playbooks, Jinja2 templates, and Ansible's hosts files." -msgstr "`Ansible vim `_ - Ansible 2.x の vim 構文プラグイン。YAML Playbook、Jinja2 テンプレート、および Ansible ホストファイルをサポートします。" - -#: ../../rst/community/other_tools_and_programs.rst:74 -msgid "JetBrains" -msgstr "JetBrains" - -#: ../../rst/community/other_tools_and_programs.rst:76 -msgid "An open-source Community edition and closed-source Enterprise edition, integrated development environments based on IntelliJ's framework including IDEA, AppCode, CLion, GoLand, PhpStorm, PyCharm and others. Useful JetBrains platform plugins include:" -msgstr "オープンソースのコミュニティーエディションとクローズドソースのエンタープライズエディション、IntelliJ のフレームワークに基づく統合開発環境 (IDEA、AppCode、CLion、GoLand、PhpStorm、PyCharm などを含む)。便利な JetBrains プラットフォームプラグインは次のとおりです。" - -#: ../../rst/community/other_tools_and_programs.rst:78 -msgid "`Ansible `_ - general Ansible plugin provides auto-completion, role name suggestion and other handy features for working with playbooks and roles." -msgstr "`Ansible `_ - 一般的な Ansible プラグインは、オートコンプリート、ロール名の提案、および Playbook およびロールを操作するためのその他の便利な機能を提供します。" - -#: ../../rst/community/other_tools_and_programs.rst:80 -msgid "`Ansible Vault Editor `_ - Ansible Vault Editor with auto encryption/decryption." -msgstr "`Ansible Vault Editor `_ - 自動暗号化/復号機能を使用した Ansible Vault エディター" - -#: ../../rst/community/other_tools_and_programs.rst:84 -msgid "Development tools" -msgstr "開発ツール" - -#: ../../rst/community/other_tools_and_programs.rst:87 -msgid "Finding related issues and PRs" -msgstr "関連する問題およびプル要求の検索" - -#: ../../rst/community/other_tools_and_programs.rst:89 -msgid "There are various ways to find existing issues and pull requests (PRs)" -msgstr "既存の問題およびプル要求を特定する方法は複数あります。" - -#: ../../rst/community/other_tools_and_programs.rst:91 -msgid "`PR by File `_ - shows a current list of all open pull requests by individual file. An essential tool for Ansible module maintainers." -msgstr "`ファイル別のプル要求 `_ - 個別ファイルによるオープンのプル要求の現在の一覧を表示します。Ansible モジュールのメンテナーにとって不可欠なツールです。" - -#: ../../rst/community/other_tools_and_programs.rst:92 -msgid "`jctanner's Ansible Tools `_ - miscellaneous collection of useful helper scripts for Ansible development." -msgstr "`jctanner の Ansible ツール `_ - Ansible 開発に役立つヘルパースクリプトのさまざまなコレクション。" - -#: ../../rst/community/other_tools_and_programs.rst:98 -msgid "Tools for validating playbooks" -msgstr "Playbook を検証するためのツール" - -#: ../../rst/community/other_tools_and_programs.rst:100 -msgid "`Ansible Lint `_ - a highly configurable linter for Ansible playbooks." -msgstr "`Ansible Lint `_ - Ansible Playbook の高度な設定可能な文法チェックプログラムです。" - -#: ../../rst/community/other_tools_and_programs.rst:101 -msgid "`Ansible Review `_ - an extension of Ansible Lint designed for code review." -msgstr "`Ansible Review `_ - コードレビュー用に設計された Ansible Lint の拡張機能です。" - -#: ../../rst/community/other_tools_and_programs.rst:102 -msgid "`Molecule `_ - a testing framework for Ansible plays and roles." -msgstr "`Molecule `_ - は、Anbile による Ansible のプレイおよびロールのテストフレームワークです。" - -#: ../../rst/community/other_tools_and_programs.rst:103 -msgid "`yamllint `__ - a command-line utility to check syntax validity including key repetition and indentation issues." -msgstr "`yamllint `__ - キーの繰り返しやインデントの問題など、構文の有効性を確認するコマンドラインユーティリティーです。" - -#: ../../rst/community/other_tools_and_programs.rst:108 -msgid "Other tools" -msgstr "その他のツール" - -#: ../../rst/community/other_tools_and_programs.rst:110 -msgid "`Ansible cmdb `_ - takes the output of Ansible's fact gathering and converts it into a static HTML overview page containing system configuration information." -msgstr "`Ansible cmdb `_ - Ansible のファクト収集の出力を受け取り、システム設定情報が含まれる静的 HTML 概要ページに変換します。" - -#: ../../rst/community/other_tools_and_programs.rst:111 -msgid "`Ansible Inventory Grapher `_ - visually displays inventory inheritance hierarchies and at what level a variable is defined in inventory." -msgstr "`Ansible Inventory Grapher `_ - インベントリーの継承階層と、変数がインベントリーで定義されているレベルを視覚的に表示します。" - -#: ../../rst/community/other_tools_and_programs.rst:112 -msgid "`Ansible Playbook Grapher `_ - a command line tool to create a graph representing your Ansible playbook tasks and roles." -msgstr "`Ansible Playbook Grapher `_ - Ansible Playbook のタスクおよびロールを表すグラフを作成するコマンドラインツールです。" - -#: ../../rst/community/other_tools_and_programs.rst:113 -msgid "`Ansible Shell `_ - an interactive shell for Ansible with built-in tab completion for all the modules." -msgstr "`Ansible Shell `_ - すべてのモジュールのタブ補完が組み込まれている Ansible 用のインタラクティブシェルです。" - -#: ../../rst/community/other_tools_and_programs.rst:114 -msgid "`Ansible Silo `_ - a self-contained Ansible environment by Docker." -msgstr "`Ansible Silo `_ - Docker による自己完結型の Ansible 環境です。" - -#: ../../rst/community/other_tools_and_programs.rst:115 -msgid "`Ansigenome `_ - a command line tool designed to help you manage your Ansible roles." -msgstr "`Ansigenome `_ - Ansible ロールの管理に役立つように設計されたコマンドラインツールです。" - -#: ../../rst/community/other_tools_and_programs.rst:116 -msgid "`ARA `_ - records Ansible playbook runs and makes the recorded data available and intuitive for users and systems by integrating with Ansible as a callback plugin." -msgstr "`ARA `_ - Ansible Playbook の実行を記録し、コールバックプラグインとして Ansible と統合することにより、記録されたデータをユーザーおよびシステムが利用できる直感的なものにします。" - -#: ../../rst/community/other_tools_and_programs.rst:117 -msgid "`Awesome Ansible `_ - a collaboratively curated list of awesome Ansible resources." -msgstr "`Awesome Ansible `_ - Awesome Ansible リソースの共同キュレーションの一覧です。" - -#: ../../rst/community/other_tools_and_programs.rst:118 -msgid "`AWX `_ - provides a web-based user interface, REST API, and task engine built on top of Ansible. AWX is the upstream project for Red Hat Ansible Tower, part of the Red Hat Ansible Automation subscription." -msgstr "`AWX `_ - Ansible 上に構築された Web ベースのユーザーインターフェース、REST API、およびタスクエンジンを提供します。AWX は、Red Hat Ansible Automation サブスクリプションに含まれる Red Hat Ansible Tower のアップストリームプロジェクトです。" - -#: ../../rst/community/other_tools_and_programs.rst:119 -msgid "`Mitogen for Ansible `_ - uses the `Mitogen `_ library to execute Ansible playbooks in a more efficient way (decreases the execution time)." -msgstr "`Mitogen for Ansible `_ - `Mitogen `_ ライブラリーを使用して、より効率的な方法で Ansible Playbook を実行します (実行時間を短縮します)。" - -#: ../../rst/community/other_tools_and_programs.rst:120 -msgid "`nanvault `_ - a standalone tool to encrypt and decrypt files in the Ansible Vault format, featuring UNIX-style composability." -msgstr "`nanvault `_ - UNIX 形式の構成機能を備えた Ansible Vault 形式ファイルの暗号化および復号を行うスタンドアロンツールです。" - -#: ../../rst/community/other_tools_and_programs.rst:121 -msgid "`OpsTools-ansible `_ - uses Ansible to configure an environment that provides the support of `OpsTools `_, namely centralized logging and analysis, availability monitoring, and performance monitoring." -msgstr "`OpsTools-ansible `_ - Ansible を使用して `OpsTools `_ のサポートを提供する環境 (中央型ロギングと分析、可用性監視、パフォーマンスの監視など) を設定します。" - -#: ../../rst/community/other_tools_and_programs.rst:122 -msgid "`TD4A `_ - a template designer for automation. TD4A is a visual design aid for building and testing jinja2 templates. It will combine data in yaml format with a jinja2 template and render the output." -msgstr "`TD4A `_ - 自動化のテンプレートデザイナー。TD4A は、jinja2 テンプレートの構築とテストを行うための視覚的な設計支援ツールです。これは、yaml 形式のデータを jinja2 テンプレートと組み合わせ、出力をレンダリングします。" - -#: ../../rst/community/other_tools_and_programs.rst:123 -msgid "`PHP-Ansible `_ - an object oriented Ansible wrapper for PHP." -msgstr "`PHP-Ansible `_: PHP のオブジェクト指向の Ansible ラッパー。" - -#: ../../rst/community/release_managers.rst:5 -msgid "Release Manager Guidelines" -msgstr "リリースマネージャーのガイドライン" - -#: ../../rst/community/release_managers.rst:9 -msgid "The release manager's purpose is to ensure a smooth release. To achieve that goal, they need to coordinate between:" -msgstr "リリースマネージャーの目的は、スムーズなリリースを確保することです。この目的を達成するには、以下について調整する必要があります。" - -#: ../../rst/community/release_managers.rst:12 -msgid "Developers with commit privileges on the `Ansible GitHub repository `_" -msgstr "`Ansible GitHub リポジトリー `_ でコミット権限を持つ開発者" - -#: ../../rst/community/release_managers.rst:13 -msgid "Contributors without commit privileges" -msgstr "コミット権限のない貢献者" - -#: ../../rst/community/release_managers.rst:14 -msgid "The community" -msgstr "コミュニティー" - -#: ../../rst/community/release_managers.rst:15 -msgid "Ansible documentation team" -msgstr "Ansible ドキュメントチーム" - -#: ../../rst/community/release_managers.rst:16 -msgid "Ansible Tower team" -msgstr "Ansible Tower チーム" - -#: ../../rst/community/release_managers.rst:19 -msgid "Pre-releases: what and why" -msgstr "プレリリース: 何を/なぜ" - -#: ../../rst/community/release_managers.rst:21 -msgid "Pre-releases exist to draw testers. They give people who don't feel comfortable running from source control a means to get an early version of the code to test and give us feedback. To ensure we get good feedback about a release, we need to make sure all major changes in a release are put into a pre-release. Testers must be given time to test those changes before the final release. Ideally we want there to be sufficient time between pre-releases for people to install and test one version for a span of time. Then they can spend more time using the new code than installing the latest version." -msgstr "プレリリース版はテスターを集めるために存在します。プレリリースは、ソース管理からの実行に不安を感じているユーザーに、初期バージョンのコードを手に入れてテストをしたり、フィードバックを行う手段を提供します。リリースに関する適切なフィードバックを確実に得るには、リリースに対する主要な変更がすべてプレリリースに組み込まれているようにする必要があります。テスターには、最終リリースの前にこれらの変更をテストする時間が与えられる必要があります。プレリリースとプレリリースの間に、1 つのバージョンをインストールしてテストするのに十分な時間を確保するのが理想的です。そうすれば、最新バージョンをインストールするよりも、新しいコードを使用することに多くの時間を費やすことができます。" - -#: ../../rst/community/release_managers.rst:29 -msgid "The right length of time for a tester is probably around two weeks. However, for our three-to-four month development cycle to work, we compress this down to one week; any less runs the risk of people spending more time installing the code instead of running it. However, if there's a time crunch (with a release date that cannot slip), it is better to release with new changes than to hold back those changes to give people time to test between. People cannot test what is not released, so we have to get those tarballs out there even if people feel they have to install more frequently." -msgstr "テスターにとって適切な期間は、おそら 2 週間程度です。ただし、3 ~ 4か月の開発サイクルを機能させるために、この期間を 1 週間に短縮しています。これより短くなると、コードを実行する代わりにコードのインストールに多くの時間を費やしてしまう可能性があります。ただし、時間的な制約がある場合は (リリース日がずれないようにするには)、ユーザーにテストする時間を与えるために変更を保留するよりも、新しい変更を加えてリリースする方が良いでしょう。リリースされていないものはテストできないため、たとえより頻繁にインストールしなければならないと思われる場合でも、その tarball は公開すべきです。" - -#: ../../rst/community/release_managers.rst:38 -msgid "Beta releases" -msgstr "ベータリリース" - -#: ../../rst/community/release_managers.rst:40 -msgid "In a beta release, we know there are still bugs. We will continue to accept fixes for these. Although we review these fixes, sometimes they can be invasive or potentially destabilize other areas of the code." -msgstr "ベータリリースでは、バグが存在していることが認識されています。これらの修正は今後も受け入れていきます。これらの修正は確認されますが、場合によっては侵襲的であったり、コードの他の領域を不安定にする可能性があります。" - -#: ../../rst/community/release_managers.rst:44 -msgid "During the beta, we will no longer accept feature submissions." -msgstr "ベータ版では、機能の提出は受け付けなくなります。" - -#: ../../rst/community/release_managers.rst:48 -msgid "Release candidates" -msgstr "Release Candidate (リリースの候補)" - -#: ../../rst/community/release_managers.rst:50 -msgid "In a release candidate, we've fixed all known blockers. Any remaining bugfixes are ones that we are willing to leave out of the release. At this point we need user testing to determine if there are any other blocker bugs lurking." -msgstr "リリース候補では、既知のすべてのブロッカーを修正しました。残っているバグ修正は、リリースから除外しても構わないと考えています。この時点で、他にもブロッカーバグが潜んでいないかどうかを判断するために、ユーザーテストを行う必要があります。" - -#: ../../rst/community/release_managers.rst:54 -msgid "Blocker bugs generally are those that cause significant problems for users. Regressions are more likely to be considered blockers because they will break present users' usage of Ansible." -msgstr "ブロッカーバグとは、一般的にユーザーに重大な問題を引き起こすバグのことです。リグレッションは、現在のユーザーの Ansible の使用方法に支障をきたすため、ブロッカーと見なされる可能性が高くなります。" - -#: ../../rst/community/release_managers.rst:57 -msgid "The Release Manager will cherry-pick fixes for new release blockers. The release manager will also choose whether to accept bugfixes for isolated areas of the code or defer those to the next minor release. By themselves, non-blocker bugs will not trigger a new release; they will only make it into the next major release if blocker bugs require that a new release be made." -msgstr "リリースマネージャーは、新しいリリースのブロッカーの修正を選択します。また、リリースマネージャーは、コードの孤立した部分のバグ修正を受け入れるか、次のマイナーリリースまで受け入れを延ばすを選択します。単独では、ブロッカー以外のバグは新しいリリースのトリガーにはなりません。ブロッカーのバグにより新しいリリースを作成する必要がある場合にのみ、次のメジャーリリースになります。" - -#: ../../rst/community/release_managers.rst:62 -msgid "The last RC should be as close to the final as possible. The following things may be changed:" -msgstr "最後のプル要求は可能な限り最終版に近いものとなるはずです。以下の点が変更される可能性があります。" - -#: ../../rst/community/release_managers.rst:64 -msgid "Version numbers are changed automatically and will differ as the pre-release tags are removed from the versions." -msgstr "バージョン番号が自動的に変更され、プレリリースのタグが削除されるとバージョンが異なります。" - -#: ../../rst/community/release_managers.rst:66 -msgid "Tests and :file:`docs/docsite/` can differ if really needed as they do not break runtime. However, the release manager may still reject them as they have the potential to cause breakage that will be visible during the release process." -msgstr "テストおよび :file:`docs/docsite/` はランタイムを破損しないため、本当に必要であれば変更しても構いません。ただし、リリースプロセス時に目に見える破損を引き起こす可能性がある場合は、リリースマネージャーが拒否する可能性があります。" - -#: ../../rst/community/release_managers.rst:70 -msgid "We want to specifically emphasize that code (in :file:`bin/`, :file:`lib/ansible/`, and :file:`setup.py`) must be the same unless there are extraordinary extenuating circumstances. If there are extenuating circumstances, the Release Manager is responsible for notifying groups (like the Tower Team) which would want to test the code." -msgstr "特別な事情がない限り、(:file:`bin/`、:file:`lib/ansible/`、および :file:`setup.py` の) コードは同じでなければなりません。特別な事情がある場合は、リリースマネージャーに、コードをテストしたいグループ (Tower チームなど) に通知する責任があります。" - -#: ../../rst/community/release_managers.rst:77 -msgid "Ansible release process" -msgstr "Ansible リリースプロセス" - -#: ../../rst/community/release_managers.rst:79 -msgid "The release process is kept in a `separate document `_ so that it can be easily updated during a release. If you need access to edit this, please ask one of the current release managers to add you." -msgstr "リリースプロセスは、リリース中に簡単に更新できるように、`別のドキュメント `_ に保存されています。これを編集するためのアクセス権が必要な場合は、現在のリリースマネージャーに追加を依頼してください。" - -#: ../../rst/community/reporting_bugs_and_features.rst:5 -msgid "Reporting bugs and requesting features" -msgstr "バグの報告および機能の要求" - -#: ../../rst/community/reporting_bugs_and_features.rst:13 -msgid "Reporting a bug" -msgstr "バグの報告" - -#: ../../rst/community/reporting_bugs_and_features.rst:16 -msgid "Security bugs" -msgstr "セキュリティーバグ" - -#: ../../rst/community/reporting_bugs_and_features.rst:18 -msgid "Ansible practices responsible disclosure - if this is a security-related bug, email `security@ansible.com `_ instead of filing a ticket or posting to any public groups, and you will receive a prompt response." -msgstr "Ansible は責任のある開示を実践しています。これがセキュリティー関連のバグである場合は、任意のパブリックグループにチケットを作成または投稿するのではなく、`security@ansible.com `_ にメールで報告してください。迅速に対応されます。" - -#: ../../rst/community/reporting_bugs_and_features.rst:21 -msgid "Bugs in ansible-base" -msgstr "ansible-base のバグ" - -#: ../../rst/community/reporting_bugs_and_features.rst:23 -msgid "If you find a bug that affects multiple plugins, a plugin that remained in the ansible/ansible repo, or the overall functioning of Ansible, report it to `github.com/ansible/ansible/issues `_. You need a free GitHub account. Before reporting a bug, use the bug/issue search to see if the issue has already been reported. If you are not sure if something is a bug yet, you can report the behavior on the :ref:`mailing list or IRC first `." -msgstr "複数のプラグイン、ansible/ansible リポジトリーに残っているプラグイン、または Ansible の全体的な機能に影響を与えるバグは、`github.com/ansible/ansible/issues `_ に報告します。無料の GitHub アカウントが必要になります。バグを報告する前に、バグ/問題検索を使用して、その問題がすでに報告されているかどうかを確認します。バグかどうか分からない場合は、:ref:`最初にメーリングリストまたは IRC ` に動作を報告できます。" - -#: ../../rst/community/reporting_bugs_and_features.rst:25 -msgid "Do not open issues for \"how do I do this\" type questions. These are great topics for IRC or the mailing list, where things are likely to be more of a discussion." -msgstr "「How do I do this (どうすればいいのか)」というタイプの質問で、問題を作成しないでください。このタイプの問題は、物事がより多くの議論になる可能性が高い IRC またはメーリングリストにとって素晴らしいトピックです。" - -#: ../../rst/community/reporting_bugs_and_features.rst:27 -msgid "If you find a bug, open the issue yourself to ensure we have a record of it. Do not rely on someone else in the community to file the bug report for you. We have created an issue template, which saves time and helps us help everyone with their issues more quickly. Please fill it out as completely and as accurately as possible:" -msgstr "バグを見つけた場合は、自分で問題を作成して、記録されたことを確認してください。コミュニティーの他の誰かがバグレポートを提出するのを待たないでください。問題テンプレートを作成しました。これにより、時間を節約し、すべての人がその問題をより迅速に解決できるようになります。できるだけ完全かつ正確に記入してください。" - -#: ../../rst/community/reporting_bugs_and_features.rst:29 -msgid "Include the Ansible version" -msgstr "Ansible バージョンの記載" - -#: ../../rst/community/reporting_bugs_and_features.rst:30 -msgid "Include any relevant configuration" -msgstr "関連する設定の記載" - -#: ../../rst/community/reporting_bugs_and_features.rst:31 -msgid "Include the exact commands or tasks you are running" -msgstr "実行する正確なコマンドまたはタスクの記載" - -#: ../../rst/community/reporting_bugs_and_features.rst:32 -msgid "Describe the behavior you expected" -msgstr "期待される動作の説明" - -#: ../../rst/community/reporting_bugs_and_features.rst:33 -msgid "Provide steps to reproduce the bug * Use minimal well-reduced and well-commented examples, not your entire production playbook * When sharing YAML in playbooks, preserve the formatting by using `code blocks `_." -msgstr "バグを再現するための手順の記載 * 実稼働で使用する Playbook 全体ではなく、必要な最小限の部分だけを取り出し、詳細な説明を記載 * Playbook で YAML を共有する場合は、`コードブロック `_ を使用してフォーマットを整理します。" - -#: ../../rst/community/reporting_bugs_and_features.rst:36 -msgid "Document the behavior you got" -msgstr "発生した動作の記述" - -#: ../../rst/community/reporting_bugs_and_features.rst:37 -msgid "Include output where possible" -msgstr "可能な場合は出力結果の記載" - -#: ../../rst/community/reporting_bugs_and_features.rst:38 -msgid "For multiple-file content, use gist.github.com, which is more durable than pastebin content" -msgstr "コンテンツが複数ファイルの場合は、gist.github.com を使用します。これは pastebin コンテンツよりも永続的です。" - -#: ../../rst/community/reporting_bugs_and_features.rst:41 -msgid "Bugs in collections" -msgstr "コレクションのバグ" - -#: ../../rst/community/reporting_bugs_and_features.rst:43 -msgid "Many bugs only affect a single module or plugin. If you find a bug that affects a module or plugin hosted in a collection, file the bug in the repository of the :ref:`collection `:" -msgstr "多くのバグは、単一のモジュールまたはプラグインにのみ影響します。コレクションでホストされるモジュールまたはプラグインに影響するバグを見つけた場合は、:ref:`コレクション ` のリポジトリーにバグを報告してください。" - -#: ../../rst/community/reporting_bugs_and_features.rst:45 -msgid "Find the collection on Galaxy." -msgstr "Galaxy のコレクションを見つけます。" - -#: ../../rst/community/reporting_bugs_and_features.rst:46 -msgid "Click on the Issue Tracker link for that collection." -msgstr "そのコレクションの Issue Tracker リンクをクリックします。" - -#: ../../rst/community/reporting_bugs_and_features.rst:47 -msgid "Follow the contributor guidelines or instructions in the collection repo." -msgstr "貢献者向けガイドラインまたはコレクションリポジトリーの指示に従ってください。" - -#: ../../rst/community/reporting_bugs_and_features.rst:49 -msgid "If you are not sure whether a bug is in ansible-base or in a collection, you can report the behavior on the :ref:`mailing list or IRC first `." -msgstr "バグが ansible-base またはコレクションのどちらにあるかわからない場合は、:ref:`最初にメーリングリストまたは IRC ` に動作を報告できます。" - -#: ../../rst/community/reporting_bugs_and_features.rst:54 -msgid "Requesting a feature" -msgstr "機能要求" - -#: ../../rst/community/reporting_bugs_and_features.rst:56 -msgid "The best way to get a feature into Ansible is to :ref:`submit a pull request `, either against ansible-base or against a collection. See also :ref:`ansible_collection_merge_requirements`." -msgstr "Ansible に機能を取り組むための最良の方法は、ansible-base またはコレクションに対して :ref:`プル要求を提出 ` することです。「:ref:`ansible_collection_merge_requirements`」も参照してください。" - -#: ../../rst/community/triage_process.rst:3 -msgid "Triage Process" -msgstr "トリアージプロセス" - -#: ../../rst/community/triage_process.rst:5 -msgid "The issue and PR triage processes are driven by the `Ansibot `_. Whenever an issue or PR is filed, the Ansibot examines the issue to ensure that all relevant data is present, and handles the routing of the issue as it works its way to eventual completion." -msgstr "問題およびプル要求のトリアージープロセスは `Ansibot `_ によって実行されます。問題やプル要求が報告されるたびに、Ansibot は問題を調べ、すべての関連データが存在することを確認し、最終的な完成に向けて問題のルーティングを処理します。" - -#: ../../rst/community/triage_process.rst:7 -msgid "For details on how Ansibot manages the triage process, please consult the `Ansibot Issue Guide `_." -msgstr "Ansibot によるトリアージプロセスの管理方法に関する詳細は、「`Ansibot 問題ガイド `_」を参照してください。" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/dev_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/dev_guide.po deleted file mode 100644 index 67b8c3fbadc..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/dev_guide.po +++ /dev/null @@ -1,14631 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-03-08 20:25+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:5 -msgid "Collection Galaxy metadata structure" -msgstr "コレクション Galaxy メタデータ構造" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:7 -msgid "A key component of an Ansible collection is the ``galaxy.yml`` file placed in the root directory of a collection. This file contains the metadata of the collection that is used to generate a collection artifact." -msgstr "Ansible コレクションの主なコンポーネントは、コレクションのルートディレクトリーに配置されている ``galaxy.yml`` ファイルです。このファイルには、コレクションアーティファクトの生成に使用されるコレクションのメタデータが含まれます。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:11 -msgid "Structure" -msgstr "構造" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:13 -msgid "The ``galaxy.yml`` file must contain the following keys in valid YAML:" -msgstr "``galaxy.yml`` ファイルの有効な YAML に以下のキーが含まれている必要があります。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:22 -msgid "Key" -msgstr "キー" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:23 -msgid "Comment" -msgstr "コメント" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:27 -msgid "namespace |br|" -msgstr "namespace |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:31 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:55 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:77 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:99 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:143 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:175 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:229 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:243 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:257 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:271 -msgid "string |_|" -msgstr "文字列 |_|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:35 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:59 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:81 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:103 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:125 -msgid "/ |_|" -msgstr "/ |_|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:39 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:63 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:85 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:107 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:129 -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "required" -msgstr "required" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:41 -msgid "The namespace of the collection." -msgstr "コレクションの名前空間。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:43 -msgid "This can be a company/brand/organization or product namespace under which all content lives." -msgstr "これには、企業/ブランド/組織、またはすべてのコンテンツが置かれる製品の名前空間を指定できます。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:45 -msgid "May only contain alphanumeric lowercase characters and underscores. Namespaces cannot start with underscores or numbers and cannot contain consecutive underscores." -msgstr "英数字とアンダースコアのみを使用できます。名前空間はアンダースコアや数字で開始できず、連続したアンダースコアを含めることはできません。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:51 -msgid "name |br|" -msgstr "name |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:65 -msgid "The name of the collection." -msgstr "コレクションの名前。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:67 -msgid "Has the same character restrictions as ``namespace``." -msgstr "``namespace`` と同じ文字制限があります。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:73 -msgid "version |br|" -msgstr "version:" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:87 -msgid "The version of the collection." -msgstr "コレクションのバージョン。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:89 -msgid "Must be compatible with semantic versioning." -msgstr "セマンティックバージョニングと互換性がある必要があります。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:95 -msgid "readme |br|" -msgstr "readme |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:109 -msgid "The path to the Markdown (.md) readme file." -msgstr "Markdown (.md) ファイルへのパス。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:111 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:181 -msgid "This path is relative to the root of the collection." -msgstr "このパスは、コレクションのルートに相対します。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:117 -msgid "authors |br|" -msgstr "authors |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:121 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:157 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:193 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:285 -msgid "list |_|" -msgstr "list |_|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:131 -msgid "A list of the collection's content authors." -msgstr "コレクションのコンテンツ作成者の一覧。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:133 -msgid "Can be just the name or in the format 'Full Name (url) @nicks:irc/im.site#channel'." -msgstr "名前または形式には、「Full Name (url) @nicks:irc/im.site#channel」の形式しか指定できません。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:139 -msgid "description |br|" -msgstr "description |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:147 -msgid "A short summary description of the collection." -msgstr "コレクションの簡単な説明。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:153 -msgid "license |br|" -msgstr "license |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:161 -msgid "Either a single license or a list of licenses for content inside of a collection." -msgstr "1 つのライセンスまたはコレクション内のコンテンツのライセンスの一覧。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:163 -msgid "Ansible Galaxy currently only accepts `SPDX `_ licenses" -msgstr "現在 Ansible Galaxy は `SPDX `_ ライセンスのみ受け付けます。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:165 -msgid "This key is mutually exclusive with ``license_file``." -msgstr "このキーは、``license_file`` と相互に排他的です。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:171 -msgid "license_file |br|" -msgstr "license_file |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:179 -msgid "The path to the license file for the collection." -msgstr "コレクションのライセンスファイルへのパス。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:183 -msgid "This key is mutually exclusive with ``license``." -msgstr "このキーは、``license`` と相互に排他的です。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:189 -msgid "tags |br|" -msgstr "tags |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:197 -msgid "A list of tags you want to associate with the collection for indexing/searching." -msgstr "インデックス化/検索のコレクションに関連付けるタグの一覧。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:199 -msgid "A tag name has the same character requirements as ``namespace`` and ``name``." -msgstr "タグ名には、``namespace`` および ``name`` と同じ文字要件があります。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:205 -msgid "dependencies |br|" -msgstr "依存関係 |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:209 -msgid "dictionary |_|" -msgstr "辞書 |_|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:213 -msgid "Collections that this collection requires to be installed for it to be usable." -msgstr "利用できるように、このコレクションをインストールする必要があります。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:215 -msgid "The key of the dict is the collection label ``namespace.name``." -msgstr "dict のキーはコレクションラベル ``namespace.name`` です。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:217 -msgid "The value is a version range `specifiers `_." -msgstr "この値は、`指定子 `_ のバージョン範囲です。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:219 -msgid "Multiple version range specifiers can be set and are separated by ``,``." -msgstr "複数のバージョン範囲指定子を設定でき、``,`` で区切ることができます。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:225 -msgid "repository |br|" -msgstr "リポジトリー |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:233 -msgid "The URL of the originating SCM repository." -msgstr "元の SCM リポジトリーの URL。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:239 -msgid "documentation |br|" -msgstr "ドキュメント |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:247 -msgid "The URL to any online docs." -msgstr "オンラインドキュメントへの URL。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:253 -msgid "homepage |br|" -msgstr "ホームページ |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:261 -msgid "The URL to the homepage of the collection/project." -msgstr "コレクション/プロジェクトのホームページへの URL。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:267 -msgid "issues |br|" -msgstr "問題 |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:275 -msgid "The URL to the collection issue tracker." -msgstr "コレクションの問題トラッカーへの URL。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:281 -msgid "build_ignore |br|" -msgstr "build_ignore |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:290 -msgid "|br| version_added: 2.10" -msgstr "|br| version_added: 2.10" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:292 -msgid "|_|" -msgstr "|_|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:293 -msgid "A list of file glob-like patterns used to filter any files or directories that should not be included in the build artifact." -msgstr "ビルドアーティファクトに含まれないファイルやディレクトリーをフィルタリングするために使用されるグロブのようなパターンの一覧。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:295 -msgid "A pattern is matched from the relative path of the file or directory of the collection directory." -msgstr "パターンは、コレクションディレクトリーのファイルまたはディレクトリーの相対パスと照合されます。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:297 -msgid "This uses ``fnmatch`` to match the files or directories." -msgstr "ここでは、``fnmatch`` を使用してファイルまたはディレクトリーを照合します。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:299 -msgid "Some directories and files like ``galaxy.yml``, ``*.pyc``, ``*.retry``, and ``.git`` are always filtered." -msgstr "``galaxy.yml``、``*.pyc``、``*.retry``、``.git`` などの一部のディレクトリーおよびファイルは常にフィルタリングされます。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:304 -msgid "Examples" -msgstr "例" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:329 -msgid ":ref:`developing_collections`" -msgstr ":ref:`developing_collections`" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:330 -msgid "Develop or modify a collection." -msgstr "コレクションを開発するか、または変更します。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:331 -#: ../../rst/dev_guide/developing_api.rst:40 -#: ../../rst/dev_guide/developing_collections.rst:809 -#: ../../rst/dev_guide/developing_inventory.rst:413 -#: ../../rst/dev_guide/developing_plugins.rst:496 -#: ../../rst/dev_guide/testing_units_modules.rst:545 -msgid ":ref:`developing_modules_general`" -msgstr ":ref:`developing_modules_general`" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:332 -#: ../../rst/dev_guide/developing_collections.rst:810 -#: ../../rst/dev_guide/developing_plugins.rst:497 -msgid "Learn about how to write Ansible modules" -msgstr "Ansible モジュールの作成方法について" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:333 -#: ../../rst/dev_guide/developing_collections.rst:805 -msgid ":ref:`collections`" -msgstr ":ref:`collections`" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:334 -#: ../../rst/dev_guide/developing_collections.rst:806 -msgid "Learn how to install and use collections." -msgstr "コレクションのインストール方法および使用方法はこちらを参照してください。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:335 -#: ../../rst/dev_guide/developing_collections.rst:811 -#: ../../rst/dev_guide/developing_core.rst:18 -#: ../../rst/dev_guide/developing_modules.rst:48 -#: ../../rst/dev_guide/developing_plugins.rst:498 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:336 -#: ../../rst/dev_guide/developing_collections.rst:812 -#: ../../rst/dev_guide/developing_core.rst:19 -#: ../../rst/dev_guide/developing_plugins.rst:499 -msgid "The development mailing list" -msgstr "開発メーリングリスト" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:337 -#: ../../rst/dev_guide/developing_api.rst:46 -#: ../../rst/dev_guide/developing_collections.rst:813 -#: ../../rst/dev_guide/developing_core.rst:20 -#: ../../rst/dev_guide/developing_inventory.rst:421 -#: ../../rst/dev_guide/developing_modules.rst:50 -#: ../../rst/dev_guide/developing_plugins.rst:500 -#: ../../rst/dev_guide/style_guide/index.rst:277 -msgid "`irc.freenode.net `_" -msgstr "`irc.freenode.net `_" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:338 -#: ../../rst/dev_guide/developing_api.rst:47 -#: ../../rst/dev_guide/developing_collections.rst:814 -#: ../../rst/dev_guide/developing_inventory.rst:422 -#: ../../rst/dev_guide/developing_modules.rst:51 -#: ../../rst/dev_guide/developing_plugins.rst:501 -msgid "#ansible IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible)" - -#: ../../rst/dev_guide/debugging.rst:5 -msgid "Debugging modules" -msgstr "モジュールのデバッグ" - -#: ../../rst/dev_guide/debugging.rst:13 -msgid "Detailed debugging steps" -msgstr "詳細なデバッグ手順" - -#: ../../rst/dev_guide/debugging.rst:15 -msgid "Ansible modules are put together as a zip file consisting of the module file and the various Python module boilerplate inside of a wrapper script. To see what is actually happening in the module, you need to extract the file from the wrapper. The wrapper script provides helper methods that let you do that." -msgstr "Ansible モジュールは、モジュールファイルとラッパースクリプト内のさまざまな Python モジュールボイラープレートで構成される zip ファイルとしてまとめて置かれます。モジュールで実際に何が発生しているかを確認するには、ラッパーからファイルを抽出する必要があります。ラッパースクリプトは、これを可能にするヘルパーメソッドを提供します。" - -#: ../../rst/dev_guide/debugging.rst:17 -msgid "The following steps use ``localhost`` as the target host, but you can use the same steps to debug against remote hosts as well. For a simpler approach to debugging without using the temporary files, see :ref:`simple debugging `." -msgstr "以下の手順では、ターゲットホストに ``localhost`` を使用していますが、同じ手順を使用してリモートホストに対してデバッグすることもできます。一時ファイルを使用せずにデバッグを行う簡単な方法は、「:ref:`簡単なデバッグ `」を参照してください。" - -#: ../../rst/dev_guide/debugging.rst:20 -msgid "Set :envvar:`ANSIBLE_KEEP_REMOTE_FILES` to ``1`` on the control host so Ansible will keep the remote module files instead of deleting them after the module finishes executing. Use the ``-vvv`` option to make Ansible more verbose. This will display the file name of the temporary module file." -msgstr "コントロールホストで :envvar:`ANSIBLE_KEEP_REMOTE_FILES` を ``1`` に設定します。これにより、Ansible はモジュール実行後も削除せずにリモートモジュールファイルを維持します。``-vvv`` オプションを使用すると、Ansible の詳細が表示されます。一時モジュールのファイル名が表示されます。" - -#: ../../rst/dev_guide/debugging.rst:40 -msgid "Navigate to the temporary directory from the previous step. If the previous command was run against a remote host, connect to that host first before trying to navigate to the temporary directory." -msgstr "前の手順から一時ディレクトリーに移動します。前のコマンドがリモートホストに対して実行した場合は、最初にそのホストに接続します。一時ディレクトリーに移動する前に、そのホストに接続します。" - -#: ../../rst/dev_guide/debugging.rst:47 -msgid "Run the wrapper's ``explode`` command to turn the string into some Python files that you can work with." -msgstr "ラッパーの ``explode`` コマンドを実行して、文字列を使用可能な Python ファイルに変換します。" - -#: ../../rst/dev_guide/debugging.rst:55 -msgid "If you want to examine the wrapper file you can. It will show a small Python script with a large base64 encoded string. The string contains the module to execute." -msgstr "ラッパーファイルを調べたい場合は、小さい Python スクリプトに、大きな base64 でエンコードされた文字列が記載されます。文字列には、実行するモジュールが含まれます。" - -#: ../../rst/dev_guide/debugging.rst:57 -msgid "When you look into the temporary directory you'll see a structure like this:" -msgstr "一時ディレクトリーを確認すると、以下のような構造が表示されます。" - -#: ../../rst/dev_guide/debugging.rst:80 -msgid "``AnsiballZ_ping.py`` is the Python script with the module code stored in a base64 encoded string. It contains various helper functions for executing the module." -msgstr "``AnsiballZ_ping.py`` base64 でエンコードされた文字列に保存されたモジュールコードを含む Python スクリプトで、モジュールを実行するためのさまざまなヘルパー関数が含まれます。" - -#: ../../rst/dev_guide/debugging.rst:82 -msgid "``ping.py`` is the code for the module itself. You can modify this code to see what effect it would have on your module, or for debugging purposes." -msgstr "``ping.py`` モジュール自体のコードです。このコードを変更して、モジュールまたはデバッグの目的を確認することができます。" - -#: ../../rst/dev_guide/debugging.rst:84 -msgid "The ``args`` file contains a JSON string. The string is a dictionary containing the module arguments and other variables that Ansible passes into the module to change its behavior. Modify this file to change the parameters passed to the module." -msgstr "``args`` ファイルには JSON 文字列が含まれています。この文字列は、Ansible がモジュールに渡したモジュール引数とその他の変数を含むディクショナリーで、動作を変更します。このファイルを変更して、モジュールに渡されるパラメーターを変更します。" - -#: ../../rst/dev_guide/debugging.rst:86 -msgid "The ``ansible`` directory contains the module code in ``modules`` as well as code from :mod:`ansible.module_utils` that is used by the module. Ansible includes files for any :mod:`ansible.module_utils` imports in the module but not any files from any other module. If your module uses :mod:`ansible.module_utils.url` Ansible will include it for you. But if your module includes `requests `_, then you'll have to make sure that the Python `requests library `_ is installed on the system before running the module." -msgstr "``ansible`` ディレクトリーには、``modules`` のモジュールコードと、モジュールによって使用される :mod:`ansible.module_utils` のコードが含まれています。 Ansible には、モジュール内の :mod:`ansible.module_utils` インポートのファイルが含まれますが、他のモジュールからのファイルは含まれません。モジュールで :mod:`ansible.module_utils.url` が使用される場合は、Ansible にそれが含まれます。ただし、モジュールに `requests `_ が含まれる場合は、モジュールを実行する前に Python `requests library `_ がシステムにインストールされていることを確認する必要があります。" - -#: ../../rst/dev_guide/debugging.rst:88 -msgid "You can modify files in this directory if you suspect that the module is having a problem in some of this boilerplate code rather than in the module code you have written." -msgstr "作成したモジュールコードではなく、モジュールのこのボイラープレートコードの一部に問題があると思われる場合は、このディレクトリーのファイルを変更できます。" - -#: ../../rst/dev_guide/debugging.rst:90 -msgid "Once you edit the code or arguments in the exploded tree, use the ``execute`` subcommand to run it:" -msgstr "展開されたツリーのコードまたは引数を編集したら、``execute`` サブコマンドを使用してこれを実行します。" - -#: ../../rst/dev_guide/debugging.rst:97 -msgid "This subcommand inserts the absolute path to ``debug_dir`` as the first item in ``sys.path`` and invokes the script using the arguments in the ``args`` file. You can continue to run the module like this until you understand the problem. Then you can copy the changes back into your real module file and test that the real module works via ``ansible`` or ``ansible-playbook``." -msgstr "このサブコマンドは、``sys.path`` の最初の項目として ``debug_dir`` に絶対パスを挿入し、``args`` ファイルの引数を使用してスクリプトを呼び出します。問題を理解するまで、このモジュールの実行を継続できます。変更を実際のモジュールファイルにコピーし、実際のモジュールが ``ansible`` または ``ansible-playbook`` で動作することをテストすることができます。" - -#: ../../rst/dev_guide/debugging.rst:103 -msgid "Simple debugging" -msgstr "簡単なデバッグ" - -#: ../../rst/dev_guide/debugging.rst:105 -msgid "The easiest way to run a debugger in a module, either local or remote, is to use `epdb `_. Add ``import epdb; epdb.serve()`` in the module code on the control node at the desired break point. To connect to the debugger, run ``epdb.connect()``. See the `epdb documentation `_ for how to specify the ``host`` and ``port``. If connecting to a remote node, make sure to use a port that is allowed by any firewall between the control node and the remote node." -msgstr "モジュール (ローカルまたはリモートのいずれか) でデバッガーを実行する最も簡単な方法は、`epdb `_ を使用します。任意の破損ポイントで、コントロールノードのモジュールコードに ``import epdb; epdb.serve()`` を追加します。デバッガーに接続するには、``epdb.connect()`` を実行します。``host`` および ``port`` を指定する方法は、`epdb ドキュメント `_ を参照してください。リモートノードに接続する場合は、コントロールノードとリモートノードとの間のファイアウォールが許可されているポートを使用するようにしてください。" - -#: ../../rst/dev_guide/debugging.rst:107 -msgid "This technique should work with any remote debugger, but we do not guarantee any particular remote debugging tool will work." -msgstr "この手法はリモートデバッガーと動作しますが、特定のリモートデバッグツールが機能する保証はありません。" - -#: ../../rst/dev_guide/debugging.rst:109 -msgid "The `q `_ library is another very useful debugging tool." -msgstr "`q `_ ライブラリーは、もう 1 つの便利なデバッグツールです。" - -#: ../../rst/dev_guide/debugging.rst:111 -msgid "Since ``print()`` statements do not work inside modules, raising an exception is a good approach if you just want to see some specific data. Put ``raise Exception(some_value)`` somewhere in the module and run it normally. Ansible will handle this exception, pass the message back to the control node, and display it." -msgstr "``print()`` ステートメントはモジュール内では機能しないため、特定のデータを確認する場合は例外を発生させます。モジュール内のどこかに ``raise Exception(some_value)`` を置き、通常どおり実行します。Ansible はこの例外を処理し、メッセージをコントロールノードに渡し、表示します。" - -#: ../../rst/dev_guide/developing_api.rst:5 -msgid "Python API" -msgstr "Python API" - -#: ../../rst/dev_guide/developing_api.rst:7 -#: ../../rst/dev_guide/developing_inventory.rst:17 -#: ../../rst/dev_guide/developing_modules_best_practices.rst:9 -#: ../../rst/dev_guide/testing_compile.rst:9 -#: ../../rst/dev_guide/testing_httptester.rst:7 -#: ../../rst/dev_guide/testing_integration.rst:9 -#: ../../rst/dev_guide/testing_integration_legacy.rst:9 -#: ../../rst/dev_guide/testing_pep8.rst:9 -#: ../../rst/dev_guide/testing_sanity.rst:9 -#: ../../rst/dev_guide/testing_units.rst:14 -#: ../../rst/dev_guide/testing_units_modules.rst:11 -#: ../../rst/dev_guide/testing_validate-modules.rst:9 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/dev_guide/developing_api.rst:9 -msgid "This API is intended for internal Ansible use. Ansible may make changes to this API at any time that could break backward compatibility with older versions of the API. Because of this, external use is not supported by Ansible. If you want to use Python API only for executing playbooks or modules, consider `ansible-runner `_ first." -msgstr "この API は、内部 Ansible の使用を目的としています。Ansible は、古いバージョンの API との後方互換性を妨げる可能性がある時点でこの API に変更を加える可能性があるため、Ansible では外部の使用はサポートされません。Playbook またはモジュールの実行のみに Python API を使用する場合は、まず `ansible-runner `_ を考慮してください。" - -#: ../../rst/dev_guide/developing_api.rst:11 -msgid "There are several ways to use Ansible from an API perspective. You can use the Ansible Python API to control nodes, you can extend Ansible to respond to various Python events, you can write plugins, and you can plug in inventory data from external data sources. This document gives a basic overview and examples of the Ansible execution and playbook API." -msgstr "API パースペクティブから Ansible を使用する方法は複数あります。Ansible Python API を使用してノードを制御し、Ansible を拡張してさまざまな Python イベントに応答でき、プラグインを作成したり、外部データソースからのインベントリーデータへのプラグインを行うことができます。本書では、Ansible の実行および Playbook API の基本的な概要と例を紹介します。" - -#: ../../rst/dev_guide/developing_api.rst:16 -msgid "If you would like to use Ansible programmatically from a language other than Python, trigger events asynchronously, or have access control and logging demands, please see the `Ansible Tower documentation `_." -msgstr "Python 以外の言語からプログラムを使用して Ansible を使用する場合は、イベントを非同期的にトリガーするか、またはアクセス制御およびログの需要がある場合は、`Ansible Tower ドキュメント `_ を参照してください。" - -#: ../../rst/dev_guide/developing_api.rst:19 -msgid "Because Ansible relies on forking processes, this API is not thread safe." -msgstr "Ansible はプロセスのフォークに依存しているため、この API はスレッドセーフではありません。" - -#: ../../rst/dev_guide/developing_api.rst:24 -msgid "Python API example" -msgstr "Python API の例" - -#: ../../rst/dev_guide/developing_api.rst:26 -msgid "This example is a simple demonstration that shows how to minimally run a couple of tasks:" -msgstr "この例は、いくつかのタスクを最小限に実行する方法を示す簡単なデモです。" - -#: ../../rst/dev_guide/developing_api.rst:31 -msgid "Ansible emits warnings and errors via the display object, which prints directly to stdout, stderr and the Ansible log." -msgstr "Ansibleは、標準出力 (stdout)、標準エラー (stderr)、Ansible ログに直接出力する表示オブジェクトを介して警告とエラーを発行します。" - -#: ../../rst/dev_guide/developing_api.rst:33 -msgid "The source code for the ``ansible`` command line tools (``lib/ansible/cli/``) is `available on GitHub `_." -msgstr "``ansible`` コマンドラインツールのソースコード (``lib/ansible/cli/``) は `GitHub `_ で利用できます。" - -#: ../../rst/dev_guide/developing_api.rst:38 -#: ../../rst/dev_guide/developing_plugins.rst:494 -msgid ":ref:`developing_inventory`" -msgstr ":ref:`developing_inventory`" - -#: ../../rst/dev_guide/developing_api.rst:39 -msgid "Developing dynamic inventory integrations" -msgstr "動的インベントリー統合の開発" - -#: ../../rst/dev_guide/developing_api.rst:41 -msgid "Getting started on developing a module" -msgstr "モジュール開発を始める" - -#: ../../rst/dev_guide/developing_api.rst:42 -#: ../../rst/dev_guide/developing_core.rst:16 -#: ../../rst/dev_guide/developing_inventory.rst:415 -msgid ":ref:`developing_plugins`" -msgstr ":ref:`developing_plugins`" - -#: ../../rst/dev_guide/developing_api.rst:43 -#: ../../rst/dev_guide/developing_inventory.rst:416 -msgid "How to develop plugins" -msgstr "プラグインの開発方法" - -#: ../../rst/dev_guide/developing_api.rst:44 -#: ../../rst/dev_guide/developing_inventory.rst:419 -#: ../../rst/dev_guide/testing_units_modules.rst:553 -msgid "`Development Mailing List `_" -msgstr "`Development Mailing List `_" - -#: ../../rst/dev_guide/developing_api.rst:45 -#: ../../rst/dev_guide/developing_inventory.rst:420 -#: ../../rst/dev_guide/testing_units_modules.rst:554 -msgid "Mailing list for development topics" -msgstr "開発トピックのメーリングリスト" - -#: ../../rst/dev_guide/developing_collections.rst:6 -msgid "Developing collections" -msgstr "コレクションの開発" - -#: ../../rst/dev_guide/developing_collections.rst:8 -msgid "Collections are a distribution format for Ansible content. You can use collections to package and distribute playbooks, roles, modules, and plugins. You can publish and use collections through `Ansible Galaxy `_." -msgstr "コレクションは、Ansible コンテンツのディストリビューション形式です。コレクションを使用して、Playbook、ロール、モジュール、プラグインをパッケージ化および配布できます。`Ansible Galaxy `_ を介してコレクションを公開および使用できます。" - -#: ../../rst/dev_guide/developing_collections.rst:11 -msgid "For details on how to *use* collections see :ref:`collections`." -msgstr "*use* コレクションの使用方法は、「:ref:`collections`」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:12 -msgid "For the current development status of Collections and FAQ see `Ansible Collections Overview and FAQ `_." -msgstr "コレクションおよび FAQ の現在の開発ステータスは、「`Ansible Collections Overview and FAQ `_」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:21 -msgid "Collection structure" -msgstr "コレクション構造" - -#: ../../rst/dev_guide/developing_collections.rst:23 -msgid "Collections follow a simple data structure. None of the directories are required unless you have specific content that belongs in one of them. A collection does require a ``galaxy.yml`` file at the root level of the collection. This file contains all of the metadata that Galaxy and other tools need in order to package, build and publish the collection::" -msgstr "コレクションは簡単なデータ構造に従います。それらの中の 1 つに所属する特定のコンテンツがない限り、ディレクトリーは必要ありません。コレクションのルートレベルで ``galaxy.yml`` ファイルが必要になります。このファイルには、Galaxy やその他のツールがコレクションをパッケージ化、ビルド、公開するのに必要なメタデータがすべて含まれます。" - -#: ../../rst/dev_guide/developing_collections.rst:49 -msgid "Ansible only accepts ``.md`` extensions for the :file:`README` file and any files in the :file:`/docs` folder." -msgstr "Ansible は、:file:`README` ファイルおよび :file:`/docs` フォルダー内の ``.md`` 拡張子ファイルのみを受け入れます。" - -#: ../../rst/dev_guide/developing_collections.rst:50 -msgid "See the `ansible-collections `_ GitHub Org for examples of collection structure." -msgstr "コレクション構造の例は、`ansible-collections `_ GitHub Org を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:51 -msgid "Not all directories are currently in use. Those are placeholders for future features." -msgstr "現在、すべてのディレクトリが使用されているわけではありません。これらは、将来の機能のプレースホルダーです。" - -#: ../../rst/dev_guide/developing_collections.rst:56 -msgid "galaxy.yml" -msgstr "galaxy.yml" - -#: ../../rst/dev_guide/developing_collections.rst:58 -msgid "A collection must have a ``galaxy.yml`` file that contains the necessary information to build a collection artifact. See :ref:`collections_galaxy_meta` for details." -msgstr "コレクションには、コレクションアーティファクトを構築するために必要な情報が含まれる ``galaxy.yml`` ファイルが必要です。詳細は、:ref:`collections_galaxy_meta` を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:64 -msgid "docs directory" -msgstr "ドキュメンテーションディレクトリー" - -#: ../../rst/dev_guide/developing_collections.rst:66 -msgid "Put general documentation for the collection here. Keep the specific documentation for plugins and modules embedded as Python docstrings. Use the ``docs`` folder to describe how to use the roles and plugins the collection provides, role requirements, and so on. Use markdown and do not add subfolders." -msgstr "ここでコレクションに関する一般的なドキュメントを追加します。Python ドキュメント文字列として埋め込まれたプラグインおよびモジュールに関する特定のドキュメントを保持します。``docs`` フォルダーを使用して、ロール、コレクションが提供するロール、ロール要件などを説明します。マークダウンを使用し、サブフォルダーを追加しないでください。" - -#: ../../rst/dev_guide/developing_collections.rst:68 -msgid "Use ``ansible-doc`` to view documentation for plugins inside a collection:" -msgstr "``ansible-doc`` を使用して、コレクション内のプラグインのドキュメントを表示します。" - -#: ../../rst/dev_guide/developing_collections.rst:74 -msgid "The ``ansible-doc`` command requires the fully qualified collection name (FQCN) to display specific plugin documentation. In this example, ``my_namespace`` is the Galaxy namespace and ``my_collection`` is the collection name within that namespace." -msgstr "``ansible-doc`` コマンドには、特定のプラグインのドキュメントを表示するには、完全修飾コレクション名 (FQCN) が必要です。この例では、``my_namespace`` は Galaxy 名前空間で、``my_collection`` はその名前空間内のコレクション名です。" - -#: ../../rst/dev_guide/developing_collections.rst:76 -msgid "The Galaxy namespace of an Ansible collection is defined in the ``galaxy.yml`` file. It can be different from the GitHub organization or repository name." -msgstr "Ansible コレクションの Galaxy 名前空間は ``galaxy.yml`` ファイルで定義されます。GitHub の組織またはリポジトリー名とは異なる場合があります。" - -#: ../../rst/dev_guide/developing_collections.rst:81 -msgid "plugins directory" -msgstr "プラグインディレクトリー" - -#: ../../rst/dev_guide/developing_collections.rst:83 -msgid "Add a 'per plugin type' specific subdirectory here, including ``module_utils`` which is usable not only by modules, but by most plugins by using their FQCN. This is a way to distribute modules, lookups, filters, and so on without having to import a role in every play." -msgstr "「プラグインタイプ」固有のサブディレクトリーをここに追加します。これには、モジュールによってだけでなく、その FQCN を使用して、ほとんどのプラグインで使用できる ``module_utils`` が含まれます。これは、すべてのプレイでロールをインポートすることなくモジュール、検索、フィルターなどを分散する方法です。" - -#: ../../rst/dev_guide/developing_collections.rst:85 -msgid "Vars plugins are unsupported in collections. Cache plugins may be used in collections for fact caching, but are not supported for inventory plugins." -msgstr "コレクションでは、vars プラグインはサポートされていません。キャッシュプラグインはファクトキャッシュのためにコレクションで使用できますが、インベントリープラグインではサポートされていません。" - -#: ../../rst/dev_guide/developing_collections.rst:90 -#: ../../rst/dev_guide/developing_collections.rst:639 -msgid "module_utils" -msgstr "module_utils" - -#: ../../rst/dev_guide/developing_collections.rst:92 -msgid "When coding with ``module_utils`` in a collection, the Python ``import`` statement needs to take into account the FQCN along with the ``ansible_collections`` convention. The resulting Python import will look like ``from ansible_collections.{namespace}.{collection}.plugins.module_utils.{util} import {something}``" -msgstr "コレクションで ``module_utils`` を使用してコーディングする場合、Python の ``import`` ステートメントは ``ansible_collections`` 規則とともに FQCN を考慮する必要があります。作成される Python インポートは ``from ansible_collections.{namespace}.{collection}.plugins.module_utils.{util} import {something}`` のようになります。" - -#: ../../rst/dev_guide/developing_collections.rst:94 -msgid "The following example snippets show a Python and PowerShell module using both default Ansible ``module_utils`` and those provided by a collection. In this example the namespace is ``community``, the collection is ``test_collection``. In the Python example the ``module_util`` in question is called ``qradar`` such that the FQCN is ``community.test_collection.plugins.module_utils.qradar``:" -msgstr "以下のスニペットの例は、デフォルトの Ansible ``module_utils`` と、コレクションの両方を使用する Python および PowerShell モジュールを示しています。この例では、名前空間は ``community`` で、コレクションは ``test_collection`` です。 Python の例では、問題の ``module_util`` は ``qradar`` と呼ばれ、FQCN が ``community.test_collection.plugins.module_utils.qradar`` となっています。" - -#: ../../rst/dev_guide/developing_collections.rst:124 -msgid "Note that importing something from an ``__init__.py`` file requires using the file name:" -msgstr "``__init__.py`` ファイルから何かをインポートする場合は、ファイル名を使用する必要があることに注意してください。" - -#: ../../rst/dev_guide/developing_collections.rst:130 -msgid "In the PowerShell example the ``module_util`` in question is called ``hyperv`` such that the FQCN is ``community.test_collection.plugins.module_utils.hyperv``:" -msgstr "PowerShell の例では、``module_util`` の質問は ``hyperv`` と呼ばれ、FQCN が ``community.test_collection.plugins.module_utils.hyperv`` となっています。" - -#: ../../rst/dev_guide/developing_collections.rst:152 -msgid "roles directory" -msgstr "roles ディレクトリー" - -#: ../../rst/dev_guide/developing_collections.rst:154 -msgid "Collection roles are mostly the same as existing roles, but with a couple of limitations:" -msgstr "コレクションロールは既存ロールとほぼ同じですが、いくつか制限があります。" - -#: ../../rst/dev_guide/developing_collections.rst:156 -msgid "Role names are now limited to contain only lowercase alphanumeric characters, plus ``_`` and start with an alpha character." -msgstr "ロール名は、小文字の英数字を使用し、``_`` を追加してから、アルファベットで指定します。" - -#: ../../rst/dev_guide/developing_collections.rst:157 -msgid "Roles in a collection cannot contain plugins any more. Plugins must live in the collection ``plugins`` directory tree. Each plugin is accessible to all roles in the collection." -msgstr "コレクション内のロールにはプラグインを含めることができません。プラグインはコレクションの ``plugins`` ディレクトリーツリーで持続する必要があります。各プラグインはコレクション内のすべてのロールからアクセスできます。" - -#: ../../rst/dev_guide/developing_collections.rst:159 -msgid "The directory name of the role is used as the role name. Therefore, the directory name must comply with the above role name rules. The collection import into Galaxy will fail if a role name does not comply with these rules." -msgstr "ロールのディレクトリー名はロール名として使用されます。そのため、ディレクトリー名は上記のロール名ルールに従う必要があります。Galaxy へのコレクションのインポートは、ロール名がこれらのルールに準拠していないと失敗します。" - -#: ../../rst/dev_guide/developing_collections.rst:163 -msgid "You can migrate 'traditional roles' into a collection but they must follow the rules above. You may need to rename roles if they don't conform. You will have to move or link any role-based plugins to the collection specific directories." -msgstr "「従来のロール」をコレクションに移行できますが、上記のルールに従う必要があります。ロールの名前を変更しなければならない場合もあります。ロールベースのプラグインをコレクション固有のディレクトリーに移動するか、リンクする必要があります。" - -#: ../../rst/dev_guide/developing_collections.rst:167 -msgid "For roles imported into Galaxy directly from a GitHub repository, setting the ``role_name`` value in the role's metadata overrides the role name used by Galaxy. For collections, that value is ignored. When importing a collection, Galaxy uses the role directory as the name of the role and ignores the ``role_name`` metadata value." -msgstr "GitHub リポジトリーから Galaxy に直接インポートされたロールの場合、ロールのメタデータに ``role_name`` 値を設定すると、Galaxy が使用するロール名が上書きされます。コレクションの場合、この値は無視されます。コレクションをインポートすると、Galaxy はロールディレクトリーをロール名として使用し、``role_name`` メタデータの値を無視します。" - -#: ../../rst/dev_guide/developing_collections.rst:170 -msgid "playbooks directory" -msgstr "playbooks ディレクトリー" - -#: ../../rst/dev_guide/developing_collections.rst:172 -msgid "TBD." -msgstr "現在準備中です。" - -#: ../../rst/dev_guide/developing_collections.rst:177 -msgid "tests directory" -msgstr "tests ディレクトリー" - -#: ../../rst/dev_guide/developing_collections.rst:179 -msgid "Ansible Collections are tested much like Ansible itself, by using the `ansible-test` utility which is released as part of Ansible, version 2.9.0 and newer. Because Ansible Collections are tested using the same tooling as Ansible itself, via `ansible-test`, all Ansible developer documentation for testing is applicable for authoring Collections Tests with one key concept to keep in mind." -msgstr "Ansible Collection は、Ansible 自体と同じように、`ansible-test` Ansible バージョン 2.9.0 以降の一部としてリリースされたユーティリティーを使用してテストされます。Ansible コレクションは Ansible 自体と同じツールを使用してテストされるため、`ansible-test` を介して、テスト用のすべての Ansible 開発者向けドキュメントは、覚えておくべき 1 つの重要な概念を使用してコレクションテストを作成するために適用できます。" - -#: ../../rst/dev_guide/developing_collections.rst:185 -msgid "See :ref:`testing_collections` for specific information on how to test collections with ``ansible-test``." -msgstr "``ansible-test`` でコレクションをテストする方法は、「:ref:`testing_collections`」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:188 -msgid "When reading the :ref:`developing_testing` documentation, there will be content that applies to running Ansible from source code via a git clone, which is typical of an Ansible developer. However, it's not always typical for an Ansible Collection author to be running Ansible from source but instead from a stable release, and to create Collections it is not necessary to run Ansible from source. Therefore, when references of dealing with `ansible-test` binary paths, command completion, or environment variables are presented throughout the :ref:`developing_testing` documentation; keep in mind that it is not needed for Ansible Collection Testing because the act of installing the stable release of Ansible containing `ansible-test` is expected to setup those things for you." -msgstr ":ref:`developing_testing` のドキュメントを読む際、Ansible 開発者の典型的な git clone を使用して、ソースコードから Ansible を実行するコンテンツがあります。ただし、Ansible Collection の作成者がソースから Ansible を実行することは常に一般的ではなく、安定したリリースからではなく、コレクションを作成するには、ソースから Ansible を実行する必要はありません。そのため、`ansible-test` バイナリーパス、コマンド補完、または環境変数については、:ref:`developing_testing` ドキュメントで提示されます。`ansible-test` を含む Ansible の安定したリリースをインストールするにはは、これらをセットアップすることが予想されるためです。" - -#: ../../rst/dev_guide/developing_collections.rst:202 -msgid "meta directory" -msgstr "meta ディレクトリー" - -#: ../../rst/dev_guide/developing_collections.rst:204 -msgid "A collection can store some additional metadata in a ``runtime.yml`` file in the collection's ``meta`` directory. The ``runtime.yml`` file supports the top level keys:" -msgstr "コレクションは、コレクションの ``meta`` ディレクトリーの ``runtime.yml`` ファイルに追加のメタデータを保存できます。``runtime.yml`` ファイルは、最上位のキーをサポートします。" - -#: ../../rst/dev_guide/developing_collections.rst:206 -msgid "*requires_ansible*:" -msgstr "*requires_ansible*:" - -#: ../../rst/dev_guide/developing_collections.rst:208 -msgid "The version of Ansible required to use the collection. Multiple versions can be separated with a comma." -msgstr "コレクションを使用するために必要な Ansible のバージョン。複数のバージョンはコンマで区切ることができます。" - -#: ../../rst/dev_guide/developing_collections.rst:214 -msgid "although the version is a `PEP440 Version Specifier `_ under the hood, Ansible deviates from PEP440 behavior by truncating prerelease segments from the Ansible version. This means that Ansible 2.11.0b1 is compatible with something that ``requires_ansible: \">=2.11\"``." -msgstr "バージョンは `PEP440 バージョン指定子 `_ ですが、内部では、Ansible はプレリリースセグメントを Ansible バージョンから切り捨てることにより、PEP440 の動作から逸脱しています。これは、Ansible2.11.0b1 が ``requires_ansible: \">=2.11\"`` であるものと互換性があることを意味します。" - -#: ../../rst/dev_guide/developing_collections.rst:216 -msgid "*plugin_routing*:" -msgstr "*plugin_routing*:" - -#: ../../rst/dev_guide/developing_collections.rst:218 -msgid "Content in a collection that Ansible needs to load from another location or that has been deprecated/removed. The top level keys of ``plugin_routing`` are types of plugins, with individual plugin names as subkeys. To define a new location for a plugin, set the ``redirect`` field to another name. To deprecate a plugin, use the ``deprecation`` field to provide a custom warning message and the removal version or date. If the plugin has been renamed or moved to a new location, the ``redirect`` field should also be provided. If a plugin is being removed entirely, ``tombstone`` can be used for the fatal error message and removal version or date." -msgstr "Ansible が別の場所から読み込む必要があるコレクション内のコンテンツ、もしくは非推奨となったか削除されるコレクションのコンテンツ。``plugin_routing`` の最上位のキーはプラグインのタイプで、個々のプラグイン名をサブキーとして使用します。プラグインの新しい場所を定義するには、``redirect`` フィールドを別の名前に設定します。プラグインを非推奨にするには、``deprecation`` フィールドを使用してカスタム警告メッセージと削除バージョンまたは日付を指定します。プラグインの名前が変更するか新しい場所に移動する場合は、``redirect`` フィールドも入力する必要があります。プラグインが完全に削除される場合、``tombstone`` は致命的なエラーメッセージ、および削除バージョンまたは日付に使用できます。" - -#: ../../rst/dev_guide/developing_collections.rst:247 -msgid "*import_redirection*" -msgstr "*import_redirection*" - -#: ../../rst/dev_guide/developing_collections.rst:249 -msgid "A mapping of names for Python import statements and their redirected locations." -msgstr "Python インポートステートメントの名前とそのリダイレクトされた場所のマッピング。" - -#: ../../rst/dev_guide/developing_collections.rst:261 -msgid "Creating a collection skeleton" -msgstr "コレクションスケルトンの作成" - -#: ../../rst/dev_guide/developing_collections.rst:263 -msgid "To start a new collection:" -msgstr "新規コレクションを開始するには、以下を使用します。" - -#: ../../rst/dev_guide/developing_collections.rst:271 -msgid "Both the namespace and collection names use the same strict set of requirements. See `Galaxy namespaces `_ on the Galaxy docsite for those requirements." -msgstr "名前空間とコレクション名はいずれも、同じ厳密な要件セットを使用します。これらの要件については、Galaxy ドキュメントスイートの「`Galaxy namespaces `_」で確認してください。" - -#: ../../rst/dev_guide/developing_collections.rst:273 -msgid "Once the skeleton exists, you can populate the directories with the content you want inside the collection. See `ansible-collections `_ GitHub Org to get a better idea of what you can place inside a collection." -msgstr "スケルトンが存在すると、コレクション内の内容でディレクトリーを設定できます。`ansible-collections `_ の GitHub Org で、コレクションに配置できる内容を十分に理解することができます。" - -#: ../../rst/dev_guide/developing_collections.rst:278 -msgid "Creating collections" -msgstr "コレクションの作成" - -#: ../../rst/dev_guide/developing_collections.rst:280 -msgid "To create a collection:" -msgstr "コレクションを作成するには、以下を行います。" - -#: ../../rst/dev_guide/developing_collections.rst:282 -msgid "Create a collection skeleton with the ``collection init`` command. See :ref:`creating_collections_skeleton` above." -msgstr "``collection init`` コマンドでコレクションスケルトンを作成します。上記の「:ref:`creating_collections_skeleton`」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:283 -msgid "Add your content to the collection." -msgstr "コンテンツをコレクションに追加します。" - -#: ../../rst/dev_guide/developing_collections.rst:284 -msgid "Build the collection into a collection artifact with :ref:`ansible-galaxy collection build`." -msgstr ":ref:`ansible-galaxy collection build` を使用してコレクションをコレクションアーティファクトにビルドします。" - -#: ../../rst/dev_guide/developing_collections.rst:285 -msgid "Publish the collection artifact to Galaxy with :ref:`ansible-galaxy collection publish`." -msgstr ":ref:`ansible-galaxy collection publish` で構築したコレクションアーティファクトを Galaxy に公開します。" - -#: ../../rst/dev_guide/developing_collections.rst:287 -msgid "A user can then install your collection on their systems." -msgstr "これにより、ユーザーが、そのコレクションをシステムにインストールできるようになります。" - -#: ../../rst/dev_guide/developing_collections.rst:289 -msgid "Currently the ``ansible-galaxy collection`` command implements the following sub commands:" -msgstr "現在、``ansible-galaxy collection`` コマンドは以下のサブコマンドを実装します。" - -#: ../../rst/dev_guide/developing_collections.rst:291 -msgid "``init``: Create a basic collection skeleton based on the default template included with Ansible or your own template." -msgstr "``init``: Ansible に含まれるデフォルトテンプレートまたは独自のテンプレートに基づいて、基本的なコレクションのスケルトンを作成します。" - -#: ../../rst/dev_guide/developing_collections.rst:292 -msgid "``build``: Create a collection artifact that can be uploaded to Galaxy or your own repository." -msgstr "``build``: Galaxy または独自のリポジトリーにアップロードできるコレクションアーティファクトを作成します。" - -#: ../../rst/dev_guide/developing_collections.rst:293 -msgid "``publish``: Publish a built collection artifact to Galaxy." -msgstr "``publish``: 構築したコレクションアーティファクトを Galaxy に公開します。" - -#: ../../rst/dev_guide/developing_collections.rst:294 -msgid "``install``: Install one or more collections." -msgstr "``install``: 1 つ以上のコレクションをインストールします。" - -#: ../../rst/dev_guide/developing_collections.rst:296 -msgid "To learn more about the ``ansible-galaxy`` command-line tool, see the :ref:`ansible-galaxy` man page." -msgstr "``ansible-galaxy`` コマンドラインツールの詳細は、:ref:`ansible-galaxy` の man ページを参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:302 -msgid "Using documentation fragments in collections" -msgstr "コレクションでのドキュメントフラグメントの使用" - -#: ../../rst/dev_guide/developing_collections.rst:304 -msgid "To include documentation fragments in your collection:" -msgstr "コレクションにドキュメントフラグメントを含めるには、以下を行います。" - -#: ../../rst/dev_guide/developing_collections.rst:306 -msgid "Create the documentation fragment: ``plugins/doc_fragments/fragment_name``." -msgstr "ドキュメントフラグメントを作成します (``plugins/doc_fragments/fragment_name``)。" - -#: ../../rst/dev_guide/developing_collections.rst:308 -msgid "Refer to the documentation fragment with its FQCN." -msgstr "FQCN を含むドキュメントフラグメントを参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:318 -msgid ":ref:`module_docs_fragments` covers the basics for documentation fragments. The `kubernetes `_ collection includes a complete example." -msgstr ":ref:`module_docs_fragments` は、ドキュメントフラグメントの基本を説明します。`kubernetes `_コレクションには完全な例が含まれています。" - -#: ../../rst/dev_guide/developing_collections.rst:320 -msgid "You can also share documentation fragments across collections with the FQCN." -msgstr "また、FQCN を使用してコレクション間でドキュメントフラグメントを共有することもできます。" - -#: ../../rst/dev_guide/developing_collections.rst:325 -msgid "Building collections" -msgstr "コレクションの構築" - -#: ../../rst/dev_guide/developing_collections.rst:327 -msgid "To build a collection, run ``ansible-galaxy collection build`` from inside the root directory of the collection:" -msgstr "コレクションを構築するには、コレクションのルートディレクトリーから ``ansible-galaxy collection build`` を実行します。" - -#: ../../rst/dev_guide/developing_collections.rst:333 -msgid "This creates a tarball of the built collection in the current directory which can be uploaded to Galaxy.::" -msgstr "これにより、現在のディレクトリーに構築されたコレクションの tarball が作成されます。これは Galaxy にアップロードできます。" - -#: ../../rst/dev_guide/developing_collections.rst:342 -msgid "Certain files and folders are excluded when building the collection artifact. See :ref:`ignoring_files_and_folders_collections` to exclude other files you would not want to distribute." -msgstr "コレクションアーティファクトのビルド時に、特定のファイルおよびフォルダーは除外されます。配布したくない他のファイルを除外するには、「:ref:`ignoring_files_and_folders_collections`」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:343 -msgid "If you used the now-deprecated ``Mazer`` tool for any of your collections, delete any and all files it added to your :file:`releases/` directory before you build your collection with ``ansible-galaxy``." -msgstr "今回の非推奨となった ``Mazer`` ツールをコレクションに使用した場合は、``ansible-galaxy`` でコレクションをビルドする前に、:file:`releases/` ディレクトリーに追加したすべてのファイルを削除します。" - -#: ../../rst/dev_guide/developing_collections.rst:344 -msgid "The current Galaxy maximum tarball size is 2 MB." -msgstr "現在の Galaxy の tarball 最大サイズは 2 MB です。" - -#: ../../rst/dev_guide/developing_collections.rst:347 -msgid "This tarball is mainly intended to upload to Galaxy as a distribution method, but you can use it directly to install the collection on target systems." -msgstr "この tarball は、配布方法として主に Galaxy にアップロードすることを目的としていますが、ターゲットシステムにコレクションをインストールするために直接使用することもできます。" - -#: ../../rst/dev_guide/developing_collections.rst:353 -msgid "Ignoring files and folders" -msgstr "ファイルやフォルダーを無視する" - -#: ../../rst/dev_guide/developing_collections.rst:355 -msgid "By default the build step will include all the files in the collection directory in the final build artifact except for the following:" -msgstr "デフォルトでは、ビルドステップには、以下を除き、最終的なビルドアーティファクト内のコレクションディレクトリーにあるすべてのファイルが含まれます。" - -#: ../../rst/dev_guide/developing_collections.rst:357 -msgid "``galaxy.yml``" -msgstr "``galaxy.yml``" - -#: ../../rst/dev_guide/developing_collections.rst:358 -msgid "``*.pyc``" -msgstr "``*.pyc``" - -#: ../../rst/dev_guide/developing_collections.rst:359 -msgid "``*.retry``" -msgstr "``*.retry``" - -#: ../../rst/dev_guide/developing_collections.rst:360 -msgid "``tests/output``" -msgstr "``tests/output``" - -#: ../../rst/dev_guide/developing_collections.rst:361 -msgid "previously built artifacts in the root directory" -msgstr "ルートディレクトリーに以前にビルドされたアーティファクト" - -#: ../../rst/dev_guide/developing_collections.rst:362 -msgid "various version control directories like ``.git/``" -msgstr "``.git/`` などのさまざまなバージョン管理ディレクトリー" - -#: ../../rst/dev_guide/developing_collections.rst:364 -msgid "To exclude other files and folders when building the collection, you can set a list of file glob-like patterns in the ``build_ignore`` key in the collection's ``galaxy.yml`` file. These patterns use the following special characters for wildcard matching:" -msgstr "コレクション構築時に他のファイルおよびディレクトリーを除外するには、コレクションの ``galaxy.yml`` ファイルの ``build_ignore`` キーに、ファイルグロブのようなパターンの一覧を設定します。これらのパターンはワイルドカードの一致に以下の特殊文字を使用します。" - -#: ../../rst/dev_guide/developing_collections.rst:368 -msgid "``*``: Matches everything" -msgstr "``*``: すべてに一致" - -#: ../../rst/dev_guide/developing_collections.rst:369 -msgid "``?``: Matches any single character" -msgstr "``?``: 任意の単一文字に一致します。" - -#: ../../rst/dev_guide/developing_collections.rst:370 -msgid "``[seq]``: Matches and character in seq" -msgstr "``[seq]``: シーケンス内の一致と文字" - -#: ../../rst/dev_guide/developing_collections.rst:371 -msgid "``[!seq]``:Matches any character not in seq" -msgstr "``[!seq]``: シーケンスにない文字と一致" - -#: ../../rst/dev_guide/developing_collections.rst:373 -msgid "For example, if you wanted to exclude the :file:`sensitive` folder within the ``playbooks`` folder as well any ``.tar.gz`` archives you can set the following in your ``galaxy.yml`` file:" -msgstr "たとえば、``playbooks`` ディレクトリー内の :file:`sensitive` ディレクトリーや ``.tar.gz`` アーカイブを除外する場合は、``galaxy.yml`` ファイルに以下を設定することができます。" - -#: ../../rst/dev_guide/developing_collections.rst:383 -msgid "This feature is only supported when running ``ansible-galaxy collection build`` with Ansible 2.10 or newer." -msgstr "この機能は、Ansible 2.10 以降と ``ansible-galaxy collection build`` を実行する場合に限りサポートされます。" - -#: ../../rst/dev_guide/developing_collections.rst:389 -msgid "Trying collections locally" -msgstr "ローカルでコレクションを試行" - -#: ../../rst/dev_guide/developing_collections.rst:391 -msgid "You can try your collection locally by installing it from the tarball. The following will enable an adjacent playbook to access the collection:" -msgstr "コレクションを tarball からインストールすることで、コレクションをローカルで試すことができます。以下では、隣接用の Playbook がコレクションにアクセスできるようになります。" - -#: ../../rst/dev_guide/developing_collections.rst:399 -msgid "You should use one of the values configured in :ref:`COLLECTIONS_PATHS` for your path. This is also where Ansible itself will expect to find collections when attempting to use them. If you don't specify a path value, ``ansible-galaxy collection install`` installs the collection in the first path defined in :ref:`COLLECTIONS_PATHS`, which by default is ``~/.ansible/collections``." -msgstr "パスのために、:ref:`COLLECTIONS_PATHS` で構成された値の 1 つを使用する必要があります。これは、Ansible 自体がコレクションを使用しようとしたときにコレクションを見つけることを期待する場所でもあります。パス値を指定しない場合は、:ref:`COLLECTIONS_PATHS` で定義された最初のパスにコレクションをインストールします。これは、デフォルトは、``~/.ansible/collections`` となります。" - -#: ../../rst/dev_guide/developing_collections.rst:403 -msgid "If you want to use a collection directly out of a checked out git repository, see :ref:`hacking_collections`." -msgstr "確認された git リポジトリーから直接コレクションを使用する場合は、「:ref:`hacking_collections`」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:405 -msgid "Next, try using the local collection inside a playbook. For examples and more details see :ref:`Using collections `" -msgstr "次に、Playbook 内でローカルコレクションの使用を試行します。例および詳細は、「:ref:`コレクションの使用 `」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:410 -msgid "Installing collections from a git repository" -msgstr "Git リポジトリーからのコレクションのインストール" - -#: ../../rst/dev_guide/developing_collections.rst:412 -msgid "You can also test a version of your collection in development by installing it from a git repository." -msgstr "また、Git リポジトリーからインストールすることで、開発でコレクションのバージョンをテストすることもできます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:1 -msgid "You can install a collection in a git repository by providing the URI to the repository instead of a collection name or path to a ``tar.gz`` file. The collection must contain a ``galaxy.yml`` or ``MANIFEST.json`` file, which will be used to generate the would-be collection artifact data from the directory. The URI should be prefixed with ``git+`` (or with ``git@`` to use a private repository with ssh authentication) and optionally supports a comma-separated `git commit-ish `_ version (for example, a commit or tag)." -msgstr "コレクション名または ``tar.gz`` ファイルへのパスではなく、リポジトリーに URI を提供することにより、git リポジトリーにコレクションをインストールできます。コレクションには、``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルが必要です。このコレクションは、ディレクトリーからの will-be コレクションアーティファクトデータを生成するのに使用されます。URI の接頭辞には ``git+`` (または ssh 認証でプライベートリポジトリーを使用する ``git@``）を付け、必要に応じてコンマ区切りの `git commit-ish `_ バージョン (コミットまたはタグなど) をサポートする必要があります。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:5 -msgid "Embedding credentials into a git URI is not secure. Make sure to use safe auth options for security reasons. For example, use `SSH `_, `netrc `_ or `http.extraHeader `_/`url..pushInsteadOf `_ in Git config to prevent your creds from being exposed in logs." -msgstr "認証情報を git URI に埋め込むことは安全ではありません。セキュリティー上の理由から、安全な認証オプションを使用してください。たとえば、Git 設定の `SSH `_、`netrc `_、または `http.extraHeader `_/`url..pushInsteadOf `_ で、クレジットがログに公開されないようにします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:18 -msgid "In a ``requirements.yml`` file, you can also use the ``type`` and ``version`` keys in addition to using the ``git+repo,version`` syntax for the collection name." -msgstr "``requirements.yml`` ファイルでは、コレクション名の ``git+repo,version`` 構文を使用する他に、``type`` キーおよび ``version`` キーを使用することもできます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:27 -msgid "Git repositories can be used for collection dependencies as well. This can be helpful for local development and testing but built/published artifacts should only have dependencies on other artifacts." -msgstr "git リポジトリーはコレクションの依存関係にも使用できます。これは、ローカル開発およびテストに役立ちますが、ビルド/公開されたアーティファクトには他のアーティファクトへの依存関係のみが必要です。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:34 -msgid "Default repository search locations" -msgstr "デフォルトのリポジトリー検索の場所" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:36 -msgid "There are two paths searched in a repository for collections by default." -msgstr "デフォルトでは、コレクション用のリポジトリーで 2 つのパスが検索されます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:38 -msgid "The first is the ``galaxy.yml`` or ``MANIFEST.json`` file in the top level of the repository path. If the file exists it's used as the collection metadata and the individual collection will be installed." -msgstr "1 つ目は、リポジトリーパスの最上位にある ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ファイルが存在する場合は、コレクションのメタデータとして使用され、個々のコレクションがインストールされます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:49 -msgid "The second is a ``galaxy.yml`` or ``MANIFEST.json`` file in each directory in the repository path (one level deep). In this scenario, each directory with a metadata file is installed as a collection." -msgstr "2 つ目は、リポジトリーパス (1 レベルの深さ) の各ディレクトリーの ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ここでは、メタデータファイルが含まれる各ディレクトリーがコレクションとしてインストールされます)。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:62 -msgid "Specifying the location to search for collections" -msgstr "コレクションを検索する場所の指定" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:64 -msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate which path ansible-galaxy should inspect for metadata file(s). The path should be a directory to a collection or multiple collections (rather than the path to a ``galaxy.yml`` file or ``MANIFEST.json`` file)." -msgstr "異なるリポジトリー構造がある場合や、コレクションのサブセットのみをインストールする場合は、URI の最後にフラグメントを追加して (任意のコンマ区切りバージョンの前）、ansible-galaxy がメタデータファイルを調べるパスを示すことができます。パスは、(``MANIFEST.json`` ファイルまたは ``galaxy.yml`` ファイルへのパスではなく) コレクションまたは複数のコレクションへのディレクトリーである必要があります。" - -#: ../../rst/dev_guide/developing_collections.rst:423 -msgid "Publishing collections" -msgstr "コレクションの公開" - -#: ../../rst/dev_guide/developing_collections.rst:425 -msgid "You can publish collections to Galaxy using the ``ansible-galaxy collection publish`` command or the Galaxy UI itself. You need a namespace on Galaxy to upload your collection. See `Galaxy namespaces `_ on the Galaxy docsite for details." -msgstr "``ansible-galaxy collection publish`` コマンドまたは Galaxy UI 自体を使用して、コレクションを Galaxy に公開することができます。コレクションをアップロードするには、Galaxy に名前空間が必要です。詳細は、Galaxy のドキュメントスイートの「`Galaxy 名前空間 `_」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:427 -msgid "Once you upload a version of a collection, you cannot delete or modify that version. Ensure that everything looks okay before you upload it." -msgstr "コレクションのバージョンをアップロードしたら、そのバージョンを削除または変更することはできません。アップロードする前に、すべての情報が適切であることを確認します。" - -#: ../../rst/dev_guide/developing_collections.rst:432 -msgid "Getting your API token" -msgstr "API トークンの取得" - -#: ../../rst/dev_guide/developing_collections.rst:434 -msgid "To upload your collection to Galaxy, you must first obtain an API token (``--token`` in the ``ansible-galaxy`` CLI command or ``token`` in the :file:`ansible.cfg` file under the ``galaxy_server`` section). The API token is a secret token used to protect your content." -msgstr "コレクションを Galaxy にアップロードするには、まず API トークンを取得する必要があります (``ansible-galaxy`` CLI コマンドの ``--token``、または ``galaxy_server`` セクションの下の :file:`ansible.cfg` ファイルの ``token``) は、コンテンツを保護するために使用されるシークレットトークン。" - -#: ../../rst/dev_guide/developing_collections.rst:436 -msgid "To get your API token:" -msgstr "API トークンを取得するには、以下を行います。" - -#: ../../rst/dev_guide/developing_collections.rst:438 -msgid "For Galaxy, go to the `Galaxy profile preferences `_ page and click :guilabel:`API Key`." -msgstr "Galaxy の場合は、`Galaxy プロファイルの設定 `_ ページに移動し、:guilabel:`API Key` をクリックします。" - -#: ../../rst/dev_guide/developing_collections.rst:439 -msgid "For Automation Hub, go to https://cloud.redhat.com/ansible/automation-hub/token/ and click :guilabel:`Load token` from the version dropdown." -msgstr "Automation Hub の場合は、https://cloud.redhat.com/ansible/automation-hub/token/ に移動し、バージョンドロップダウンの :guilabel:`Load token` をクリックします。" - -#: ../../rst/dev_guide/developing_collections.rst:442 -msgid "Storing or using your API token" -msgstr "API トークンの保存または使用" - -#: ../../rst/dev_guide/developing_collections.rst:444 -msgid "Once you have retrieved your API token, you can store or use the token for collections in two ways:" -msgstr "API トークンを取得したら、2 つの方法でコレクションにトークンを保存または使用することができます。" - -#: ../../rst/dev_guide/developing_collections.rst:446 -msgid "Pass the token to the ``ansible-galaxy`` command using the ``--token``." -msgstr "``--token`` を使用して、トークンを ``ansible-galaxy`` コマンドに渡します。" - -#: ../../rst/dev_guide/developing_collections.rst:447 -msgid "Specify the token within a Galaxy server list in your :file:`ansible.cfg` file." -msgstr ":file:`ansible.cfg` ファイルの Galaxy サーバーリスト内のトークンを指定します。" - -#: ../../rst/dev_guide/developing_collections.rst:450 -msgid "Using the ``token`` argument" -msgstr "``token`` 引数の使用" - -#: ../../rst/dev_guide/developing_collections.rst:452 -msgid "You can use the ``--token`` argument with the ``ansible-galaxy`` command (in conjunction with the ``--server`` argument or :ref:`GALAXY_SERVER` setting in your :file:`ansible.cfg` file). You cannot use ``apt-key`` with any servers defined in your :ref:`Galaxy server list `." -msgstr "``--token`` 引数は、``ansible-galaxy`` コマンド (:file:`ansible.cfg` ファイルの ``--server`` 引数または :ref:`GALAXY_SERVER` 設定とともに) で使用できます。:ref:`Galaxy サーバー一覧 ` で定義されているサーバーでは、``apt-key`` を使用することはできません。" - -#: ../../rst/dev_guide/developing_collections.rst:460 -msgid "Specify the token within a Galaxy server list" -msgstr "Galaxy サーバー一覧内でトークンの指定" - -#: ../../rst/dev_guide/developing_collections.rst:462 -msgid "With this option, you configure one or more servers for Galaxy in your :file:`ansible.cfg` file under the ``galaxy_server_list`` section. For each server, you also configure the token." -msgstr "このオプションを使用して、``galaxy_server_list`` セクションの下にある :file:`ansible.cfg` で Galaxy 用に 1 つ以上のサーバーを構成します。サーバーごとに、トークンも構成します。" - -#: ../../rst/dev_guide/developing_collections.rst:474 -msgid "See :ref:`galaxy_server_config` for complete details." -msgstr "詳細は、「:ref:`galaxy_server_config`」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:479 -msgid "Upload using ansible-galaxy" -msgstr "ansible-galaxy を使用したアップロード" - -#: ../../rst/dev_guide/developing_collections.rst:482 -msgid "By default, ``ansible-galaxy`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`). If you are only publishing your collection to Ansible Galaxy, you do not need any further configuration. If you are using Red Hat Automation Hub or any other Galaxy server, see :ref:`Configuring the ansible-galaxy client `." -msgstr "デフォルトでは、``ansible-galaxy`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の下の :file:`ansible.cfg` ファイルに記載されるように)。`galaxy_server` コレクションのみを Ansible Galaxy に公開している場合は、追加設定は必要ありません。Red Hat Automation Hub またはその他の Galaxy サーバーを使用している場合は、「:ref:`ansible-galaxy クライアントの設定 `」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:484 -msgid "To upload the collection artifact with the ``ansible-galaxy`` command:" -msgstr "``ansible-galaxy`` コマンドでコレクションアーティファクトをアップロードするには、以下を使用します。" - -#: ../../rst/dev_guide/developing_collections.rst:492 -msgid "The above command assumes you have retrieved and stored your API token as part of a Galaxy server list. See :ref:`galaxy_get_token` for details." -msgstr "上記のコマンドは、API トークンを取得して Galaxy サーバーリストの一部として取得し、保存していることを前提としています。詳細は「:ref:`galaxy_get_token`」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:494 -msgid "The ``ansible-galaxy collection publish`` command triggers an import process, just as if you uploaded the collection through the Galaxy website. The command waits until the import process completes before reporting the status back. If you want to continue without waiting for the import result, use the ``--no-wait`` argument and manually look at the import progress in your `My Imports `_ page." -msgstr "``ansible-galaxy collection publish`` コマンドは、Galaxy の Web サイトでコレクションをアップロードしているのと同様に、インポートプロセスを発生させます。コマンドは、ステータスを報告する前にインポートプロセスが完了するまで待ちます。インポート結果を待たずに続行する場合は、``--no-wait`` 引数を使用して、`My Imports `_ ページで手動でインポートの進行状況を確認します。" - -#: ../../rst/dev_guide/developing_collections.rst:503 -msgid "Upload a collection from the Galaxy website" -msgstr "Galaxy の Web サイトからコレクションをアップロードします。" - -#: ../../rst/dev_guide/developing_collections.rst:505 -msgid "To upload your collection artifact directly on Galaxy:" -msgstr "Galaxy でコレクションアーティファクトを直接アップロードするには、以下を行います。" - -#: ../../rst/dev_guide/developing_collections.rst:507 -msgid "Go to the `My Content `_ page, and click the **Add Content** button on one of your namespaces." -msgstr "`My Content `_ ページに移動し、名前空間のいずれかの **コンテンツを追加** ボタンをクリックします。" - -#: ../../rst/dev_guide/developing_collections.rst:508 -msgid "From the **Add Content** dialogue, click **Upload New Collection**, and select the collection archive file from your local filesystem." -msgstr "**コンテンツの追加** ダイアログから、**新規コレクションのアップロード** をクリックして、ローカルファイルシステムからコレクションのアーカイブファイルを選択します。" - -#: ../../rst/dev_guide/developing_collections.rst:510 -msgid "When uploading collections it doesn't matter which namespace you select. The collection will be uploaded to the namespace specified in the collection metadata in the ``galaxy.yml`` file. If you're not an owner of the namespace, the upload request will fail." -msgstr "コレクションをアップロードする際に、選択した名前空間は重要ではありません。コレクションは ``galaxy.yml`` ファイルのコレクションメタデータに指定された名前空間にアップロードされます。名前空間の所有者がない場合、アップロード要求は失敗します。" - -#: ../../rst/dev_guide/developing_collections.rst:514 -msgid "Once Galaxy uploads and accepts a collection, you will be redirected to the **My Imports** page, which displays output from the import process, including any errors or warnings about the metadata and content contained in the collection." -msgstr "Galaxy がコレクションをアップロードして受け入れると、**My Imports** ページにリダイレクトされます。このページには、コレクションに含まれるメタデータやコンテンツに関するエラーや警告など、インポート処理の出力が表示されます。" - -#: ../../rst/dev_guide/developing_collections.rst:520 -msgid "Collection versions" -msgstr "コレクションのバージョン" - -#: ../../rst/dev_guide/developing_collections.rst:522 -msgid "Once you upload a version of a collection, you cannot delete or modify that version. Ensure that everything looks okay before uploading. The only way to change a collection is to release a new version. The latest version of a collection (by highest version number) will be the version displayed everywhere in Galaxy; however, users will still be able to download older versions." -msgstr "コレクションのバージョンをアップロードしたら、そのバージョンを削除または変更することはできません。アップロードする前に、すべてが正常に見えることを確認してください。コレクションを変更する唯一の方法は、新しいバージョンをリリースすることです。(最大バージョン番号による) コレクションの最新バージョンは、Galaxy のあらゆる場所に表示されるバージョンになります。ただし、ユーザーは引き続き古いバージョンをダウンロードできます。" - -#: ../../rst/dev_guide/developing_collections.rst:526 -msgid "Collection versions use `Semantic Versioning `_ for version numbers. Please read the official documentation for details and examples. In summary:" -msgstr "コレクションのバージョンは、バージョン番号に `セマンティックバージョン `_ を使用します。詳細と例は、公式ドキュメントをお読みください。要約すると、以下のようになります。" - -#: ../../rst/dev_guide/developing_collections.rst:528 -msgid "Increment major (for example: x in `x.y.z`) version number for an incompatible API change." -msgstr "互換性のない API 変更のメジャーバージョンのバージョン番号 (例: `x.y.z` の x)。" - -#: ../../rst/dev_guide/developing_collections.rst:529 -msgid "Increment minor (for example: y in `x.y.z`) version number for new functionality in a backwards compatible manner (for example new modules/plugins, parameters, return values)." -msgstr "後方互換の方法で新機能のマイナーバージョンのバージョン番号 (例: `x.y.z` の y)(新しいモジュール/プラグイン、パラメーター、戻り値など)。" - -#: ../../rst/dev_guide/developing_collections.rst:530 -msgid "Increment patch (for example: z in `x.y.z`) version number for backwards compatible bug fixes." -msgstr "後方互換のバグ修正向けのインクリメントパッチのバージョン番号 (例: `x.y.z` の z)。" - -#: ../../rst/dev_guide/developing_collections.rst:535 -msgid "Migrating Ansible content to a different collection" -msgstr "Ansible コンテンツのコレクションへの移行" - -#: ../../rst/dev_guide/developing_collections.rst:537 -msgid "First, look at `Ansible Collection Checklist `_." -msgstr "まず `Ansible Collection チェックリスト `_ を確認します。" - -#: ../../rst/dev_guide/developing_collections.rst:539 -msgid "To migrate content from one collection to another, if the collections are parts of `Ansible distribution `_:" -msgstr "コレクションが `Ansible ディストリビューション `_ の一部である場合は、コレクションを別のコレクションに移行するには、以下を実行します。" - -#: ../../rst/dev_guide/developing_collections.rst:541 -msgid "Copy content from the source (old) collection to the target (new) collection." -msgstr "ソース (以前の) コレクションからターゲット (新しい) コレクションにコンテンツをコピーします。" - -#: ../../rst/dev_guide/developing_collections.rst:542 -msgid "Deprecate the module/plugin with ``removal_version`` scheduled for the next major version in ``meta/runtime.yml`` of the old collection. The deprecation must be released after the copied content has been included in a release of the new collection." -msgstr "古いコレクションの ``meta/runtime.yml`` の次のメジャーバージョンに予定されている ``removal_version`` でモジュール/プラグインが非推奨になりました。コピーされたコンテンツが新しいコレクションのリリースにあった後に、非推奨がリリースする必要があります。" - -#: ../../rst/dev_guide/developing_collections.rst:543 -msgid "When the next major release of the old collection is prepared:" -msgstr "古いコレクションの次のメジャーリリースが準備されている場合は、以下のようになります。" - -#: ../../rst/dev_guide/developing_collections.rst:545 -msgid "remove the module/plugin from the old collection" -msgstr "古いコレクションからモジュール/プラグインを削除する" - -#: ../../rst/dev_guide/developing_collections.rst:546 -msgid "remove the symlink stored in ``plugin/modules`` directory if appropriate (mainly when removing from ``community.general`` and ``community.network``)" -msgstr "必要に応じて、``plugin/modules`` ディレクトリーに保存されたシンボリックリンクを削除します (主に ``community.general`` および ``community.network``から削除する場合)。" - -#: ../../rst/dev_guide/developing_collections.rst:547 -msgid "remove related unit and integration tests" -msgstr "関連するユニットおよびインテグレーションテストの削除" - -#: ../../rst/dev_guide/developing_collections.rst:548 -msgid "remove specific module utils" -msgstr "特定のモジュールユーティリティーの削除" - -#: ../../rst/dev_guide/developing_collections.rst:549 -msgid "remove specific documentation fragments if there are any in the old collection" -msgstr "古いコレクションにある場合は、特定のドキュメントフラグメントを削除する" - -#: ../../rst/dev_guide/developing_collections.rst:550 -msgid "add a changelog fragment containing entries for ``removed_features`` and ``breaking_changes``; you can see an example of a changelog fragment in this `pull request `_" -msgstr "``removed_features`` および ``breaking_changes`` のエントリーを含む changelog フラグメントを追加します。この `プル要求 `_ で changelog フラグメントの例を確認できます。" - -#: ../../rst/dev_guide/developing_collections.rst:551 -msgid "change ``meta/runtime.yml`` in the old collection:" -msgstr "古いコレクションの ``meta/runtime.yml`` を変更します。" - -#: ../../rst/dev_guide/developing_collections.rst:553 -msgid "add ``redirect`` to the corresponding module/plugin's entry" -msgstr "対応するモジュール/プラグインのエントリーに ``redirect`` を追加" - -#: ../../rst/dev_guide/developing_collections.rst:554 -msgid "in particular, add ``redirect`` for the removed module utils and documentation fragments if applicable" -msgstr "特に、削除されたモジュールユーティリティーおよびドキュメントフラグメント (該当する場合) に ``redirect`` を追加します。" - -#: ../../rst/dev_guide/developing_collections.rst:555 -msgid "remove ``removal_version`` from there" -msgstr "そこから ``removal_version`` を削除します" - -#: ../../rst/dev_guide/developing_collections.rst:556 -msgid "remove related entries from ``tests/sanity/ignore.txt`` files if exist" -msgstr "``tests/sanity/ignore.txt`` ファイルから関連エントリーが存在する場合は削除" - -#: ../../rst/dev_guide/developing_collections.rst:557 -msgid "remove changelog fragments for removed content that are not yet part of the changelog (in other words, do not modify `changelogs/changelog.yaml` and do not delete files mentioned in it)" -msgstr "changelog の一部ではない削除されたコンテンツの changelog フラグメントを削除します (つまり、`changelogs/changelog.yaml` を変更せず、そのファイルに記述されているファイルを削除しないでください)。" - -#: ../../rst/dev_guide/developing_collections.rst:558 -msgid "remove requirements that are no longer required in ``tests/unit/requirements.txt``, ``tests/requirements.yml`` and ``galaxy.yml``" -msgstr "``tests/unit/requirements.txt``、``tests/requirements.yml``、および ``galaxy.yml`` ではなくなった要件を削除します。" - -#: ../../rst/dev_guide/developing_collections.rst:560 -msgid "According to the above, you need to create at least three PRs as follows:" -msgstr "上記に応じて、以下のように 3 つ以上の PR を作成する必要があります。" - -#: ../../rst/dev_guide/developing_collections.rst:562 -msgid "Create a PR against the new collection to copy the content." -msgstr "新しいコレクションに対して PR を作成し、コンテンツをコピーします。" - -#: ../../rst/dev_guide/developing_collections.rst:563 -msgid "Deprecate the module/plugin in the old collection." -msgstr "古いコレクションのモジュール/プラグインが非推奨になる。" - -#: ../../rst/dev_guide/developing_collections.rst:564 -msgid "Later create a PR against the old collection to remove the content according to the schedule." -msgstr "後に、古いコレクションに対して PR を作成し、スケジュールに応じてコンテンツを削除します。" - -#: ../../rst/dev_guide/developing_collections.rst:568 -msgid "Adding the content to the new collection" -msgstr "新しいコレクションへのコンテンツの追加" - -#: ../../rst/dev_guide/developing_collections.rst:570 -msgid "Create a PR in the new collection to:" -msgstr "新しいコレクションで PR を作成し、以下を行います。" - -#: ../../rst/dev_guide/developing_collections.rst:572 -msgid "Copy ALL the related files from the old collection." -msgstr "古いコレクションから関連ファイルをすべてコピーします。" - -#: ../../rst/dev_guide/developing_collections.rst:573 -msgid "If it is an action plugin, include the corresponding module with documentation." -msgstr "アクションプラグインの場合は、ドキュメントが含まれる対応するモジュールを含めます。" - -#: ../../rst/dev_guide/developing_collections.rst:574 -msgid "If it is a module, check if it has a corresponding action plugin that should move with it." -msgstr "モジュールを削除する場合は、それに対応するアクションプラグインを削除します。" - -#: ../../rst/dev_guide/developing_collections.rst:575 -msgid "Check ``meta/`` for relevant updates to ``runtime.yml`` if it exists." -msgstr "``meta/`` で、``runtime.yml`` に対する関連更新が存在する場合は、それを確認します。" - -#: ../../rst/dev_guide/developing_collections.rst:576 -msgid "Carefully check the moved ``tests/integration`` and ``tests/units`` and update for FQCN." -msgstr "移動した ``tests/integration`` および ``tests/units`` を注意して確認し、FQCN を更新してください。" - -#: ../../rst/dev_guide/developing_collections.rst:577 -msgid "Review ``tests/sanity/ignore-*.txt`` entries in the old collection." -msgstr "古いコレクションの ``tests/sanity/ignore-*.txt`` エントリーを確認します。" - -#: ../../rst/dev_guide/developing_collections.rst:578 -msgid "Update ``meta/runtime.yml`` in the old collection." -msgstr "古いコレクションの ``meta/runtime.yml`` を更新します。" - -#: ../../rst/dev_guide/developing_collections.rst:582 -msgid "Removing the content from the old collection" -msgstr "古いコレクションからのコンテンツの削除" - -#: ../../rst/dev_guide/developing_collections.rst:584 -msgid "Create a PR against the source collection repository to remove the modules, module_utils, plugins, and docs_fragments related to this migration:" -msgstr "ソースコレクションリポジトリーに対して PR を作成し、この移行に関連するモジュール、module_utils、plugins、および docs_fragments を削除します。" - -#: ../../rst/dev_guide/developing_collections.rst:586 -msgid "If you are removing an action plugin, remove the corresponding module that contains the documentation." -msgstr "アクションプラグインを削除する場合は、ドキュメントが含まれる対応するモジュールを削除します。" - -#: ../../rst/dev_guide/developing_collections.rst:587 -msgid "If you are removing a module, remove any corresponding action plugin that should stay with it." -msgstr "モジュールを削除する場合は、それに対応するアクションプラグインを削除します。" - -#: ../../rst/dev_guide/developing_collections.rst:588 -msgid "Remove any entries about removed plugins from ``meta/runtime.yml``. Ensure they are added into the new repo." -msgstr "削除されたプラグインに関するエントリーを ``meta/runtime.yml`` から削除します。それらが新しいリポジトリーに追加されるようにしてください。" - -#: ../../rst/dev_guide/developing_collections.rst:589 -msgid "Remove sanity ignore lines from ``tests/sanity/ignore\\*.txt``" -msgstr "``tests/sanity/ignore\\*.txt`` から、サニティー無視の行を削除します。" - -#: ../../rst/dev_guide/developing_collections.rst:590 -msgid "Remove associated integration tests from ``tests/integrations/targets/`` and unit tests from ``tests/units/plugins/``." -msgstr "関連する統合テストを ``tests/units/plugins/`` から削除し、``tests/integrations/targets/`` およびユニットテストから削除します。" - -#: ../../rst/dev_guide/developing_collections.rst:591 -msgid "if you are removing from content from ``community.general`` or ``community.network``, remove entries from ``.github/BOTMETA.yml``." -msgstr "``community.general`` または ``community.network`` からコンテンツを削除すると、``.github/BOTMETA.yml`` からエントリーを削除します。" - -#: ../../rst/dev_guide/developing_collections.rst:592 -msgid "Carefully review ``meta/runtime.yml`` for any entries you may need to remove or update, in particular deprecated entries." -msgstr "特定の非推奨のエントリーで削除または更新が必要になる可能性のあるエントリーについては、``meta/runtime.yml`` を慎重に確認してください。" - -#: ../../rst/dev_guide/developing_collections.rst:593 -msgid "Update ``meta/runtime.yml`` to contain redirects for EVERY PLUGIN, pointing to the new collection name." -msgstr "``meta/runtime.yml`` を更新して、新しいコレクション名を示す EVERY PLUGIN のリダイレクトを追加します。" - -#: ../../rst/dev_guide/developing_collections.rst:597 -msgid "Maintainers for the old collection have to make sure that the PR is merged in a way that it does not break user experience and semantic versioning:" -msgstr "古いコレクションのメンテナーは、PR がユーザーエクスペリエンスとセマンティックバージョニングを壊さない方法でマージされるようにする必要があります。" - -#: ../../rst/dev_guide/developing_collections.rst:599 -msgid "A new version containing the merged PR must not be released before the collection the content has been moved to has been released again, with that content contained in it. Otherwise the redirects cannot work and users relying on that content will experience breakage." -msgstr "マージされた PR を含む新しいバージョンは、コンテンツが移動されたコレクションが再びリリースされる前にリリースされてはならず、そのコンテンツが含まれています。そうしないと、リダイレクトが機能せず、そのコンテンツに依存しているユーザーが破損する可能性があります。" - -#: ../../rst/dev_guide/developing_collections.rst:600 -msgid "Once 1.0.0 of the collection from which the content has been removed has been released, such PRs can only be merged for a new **major** version (in other words, 2.0.0, 3.0.0, and so on)." -msgstr "コンテンツが削除されたコレクションで 1.0.0 がリリースされると、この PR は新しい **メジャー** バージョン (つまり 2.0.0、3.0.0 など) のみをマージできます。" - -#: ../../rst/dev_guide/developing_collections.rst:604 -msgid "BOTMETA.yml" -msgstr "BOTMETA.yml" - -#: ../../rst/dev_guide/developing_collections.rst:606 -msgid "The ``BOTMETA.yml``, for example in `community.general collection repository `_, is the source of truth for:" -msgstr "たとえば `community.general collection repository `_ の ``BOTMETA.yml`` は、以下の信頼できるソースです。" - -#: ../../rst/dev_guide/developing_collections.rst:608 -msgid "ansibullbot" -msgstr "ansibullbot" - -#: ../../rst/dev_guide/developing_collections.rst:610 -msgid "If the old and/or new collection has ``ansibullbot``, its ``BOTMETA.yml`` must be updated correspondingly." -msgstr "古いコレクションまたは新しいコレクションで ``ansibullbot`` がある場合は、それに応じて ``BOTMETA.yml`` を更新する必要があります。" - -#: ../../rst/dev_guide/developing_collections.rst:612 -msgid "Ansibulbot will know how to redirect existing issues and PRs to the new repo. The build process for docs.ansible.com will know where to find the module docs." -msgstr "Ansibulbot は、既存の問題と PR を新しいリポジトリーにリダイレクトする方法を認識します。docs.ansible.com のビルドプロセスは、モジュール文書の検索場所を認識します。" - -#: ../../rst/dev_guide/developing_collections.rst:632 -msgid "`Example PR `_" -msgstr "`Example PR `_" - -#: ../../rst/dev_guide/developing_collections.rst:634 -msgid "The ``migrated_to:`` key must be added explicitly for every *file*. You cannot add ``migrated_to`` at the directory level. This is to allow module and plugin webdocs to be redirected to the new collection docs." -msgstr "``migrated_to:`` キーは、*ファイル* ごとに明示的に追加する必要があります。ディレクトリーレベルで ``migrated_to`` を追加することはできません。モジュールとプラグインの Web ドキュメントを新しいコレクションにリダイレクトすることです。" - -#: ../../rst/dev_guide/developing_collections.rst:635 -msgid "``migrated_to:`` MUST be added for every:" -msgstr "以下のすべてに ``migrated_to:`` を追加する必要があります。" - -#: ../../rst/dev_guide/developing_collections.rst:637 -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "module" -msgstr "モジュール" - -#: ../../rst/dev_guide/developing_collections.rst:638 -msgid "plugin" -msgstr "プラグイン" - -#: ../../rst/dev_guide/developing_collections.rst:640 -msgid "contrib/inventory script" -msgstr "contrib/inventory スクリプト" - -#: ../../rst/dev_guide/developing_collections.rst:642 -msgid "You do NOT need to add ``migrated_to`` for:" -msgstr "以下について ``migrated_to`` を追加する必要はありません。" - -#: ../../rst/dev_guide/developing_collections.rst:644 -#: ../../rst/dev_guide/developing_collections.rst:668 -msgid "Unit tests" -msgstr "ユニットテスト" - -#: ../../rst/dev_guide/developing_collections.rst:645 -#: ../../rst/dev_guide/developing_collections.rst:687 -#: ../../rst/dev_guide/testing_integration.rst:7 -msgid "Integration tests" -msgstr "統合テスト" - -#: ../../rst/dev_guide/developing_collections.rst:646 -msgid "ReStructured Text docs (anything under ``docs/docsite/rst/``)" -msgstr "再構築されたテキストドキュメント (``docs/docsite/rst/`` の下すべて)" - -#: ../../rst/dev_guide/developing_collections.rst:647 -msgid "Files that never existed in ``ansible/ansible:devel``" -msgstr "``ansible/ansible:devel`` に存在しないファイル" - -#: ../../rst/dev_guide/developing_collections.rst:652 -msgid "Testing collections" -msgstr "コレクションの表示" - -#: ../../rst/dev_guide/developing_collections.rst:654 -msgid "The main tool for testing collections is ``ansible-test``, Ansible's testing tool described in :ref:`developing_testing`. You can run several compile and sanity checks, as well as run unit and integration tests for plugins using ``ansible-test``. When you test collections, test against the ansible-base version(s) you are targeting." -msgstr "コレクションをテストする主なツールは、:ref:`developing_testing` に記載されている Ansible のテストツールである ``ansible-test`` です。また、複数のコンパイルチェックと健全性チェックを実行したり、``ansible-test`` を使用してプラグイン用にユニットテストや統合テストを実行できます。コレクションをテストする場合に、使用する ansible-base バージョンをテストする際にテストすることができます。" - -#: ../../rst/dev_guide/developing_collections.rst:656 -msgid "You must always execute ``ansible-test`` from the root directory of a collection. You can run ``ansible-test`` in Docker containers without installing any special requirements. The Ansible team uses this approach in Shippable both in the ansible/ansible GitHub repository and in the large community collections such as `community.general `_ and `community.network `_. The examples below demonstrate running tests in Docker containers." -msgstr "常に、コレクションのルートディレクトリーから、``ansible-test`` を実行する必要があります。特別な要件をインストールせずに Docker コンテナーの ``ansible-test`` を実行できます。Ansible チームは、ansible/ansible GitHub リポジトリーと、`community.general `_ や `community.network `_ ような大規模なコミュニティーコレクションの両方の Shippable で、このアプローチを使用します。以下ので例は、Docker コンテナーでテストを実行しています。" - -#: ../../rst/dev_guide/developing_collections.rst:659 -msgid "Compile and sanity tests" -msgstr "コンパイルとサニティーテスト" - -#: ../../rst/dev_guide/developing_collections.rst:661 -msgid "To run all compile and sanity tests::" -msgstr "すべてのコンパイルおよびサニティーテストを実行するには、以下を実行します。" - -#: ../../rst/dev_guide/developing_collections.rst:665 -msgid "See :ref:`testing_compile` and :ref:`testing_sanity` for more information. See the :ref:`full list of sanity tests ` for details on the sanity tests and how to fix identified issues." -msgstr "詳細は、:ref:`testing_compile` および :ref:`testing_sanity` を参照してください。健全性テストと、特定された問題を修正する方法は、「:ref:`健全性テストの完全リスト `」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:670 -msgid "You must place unit tests in the appropriate``tests/unit/plugins/`` directory. For example, you would place tests for ``plugins/module_utils/foo/bar.py`` in ``tests/unit/plugins/module_utils/foo/test_bar.py`` or ``tests/unit/plugins/module_utils/foo/bar/test_bar.py``. For examples, see the `unit tests in community.general `_." -msgstr "ユニットテストを適切な ``tests/unit/plugins/`` ディレクトリーに置く必要があります。たとえば、``tests/unit/plugins/module_utils/foo/test_bar.py`` または ``tests/unit/plugins/module_utils/foo/bar/test_bar.py`` の ``plugins/module_utils/foo/bar.py`` にテストを置きます。たとえば、`community.general のユニットテスト `_ を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:672 -msgid "To run all unit tests for all supported Python versions::" -msgstr "サポートされるすべての Python バージョンに対して、すべてのユニットテストを実行するには、以下のコマンドを実行します。" - -#: ../../rst/dev_guide/developing_collections.rst:676 -msgid "To run all unit tests only for a specific Python version::" -msgstr "特定の Python バージョンに対してのみ、ユニットテストをすべて実行するには、以下を実行します。" - -#: ../../rst/dev_guide/developing_collections.rst:680 -msgid "To run only a specific unit test::" -msgstr "特定のユニットテストのみを実行するには、以下を実行します。" - -#: ../../rst/dev_guide/developing_collections.rst:684 -msgid "You can specify Python requirements in the ``tests/unit/requirements.txt`` file. See :ref:`testing_units` for more information, especially on fixture files." -msgstr "``tests/unit/requirements.txt`` ファイルで Python 要件を指定できます。詳細 (特にフィクスチャーファイルの詳細) は、「:ref:`testing_units`」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:689 -msgid "You must place integration tests in the appropriate ``tests/integration/targets/`` directory. For module integration tests, you can use the module name alone. For example, you would place integration tests for ``plugins/modules/foo.py`` in a directory called ``tests/integration/targets/foo/``. For non-module plugin integration tests, you must add the plugin type to the directory name. For example, you would place integration tests for ``plugins/connections/bar.py`` in a directory called ``tests/integration/targets/connection_bar/``. For lookup plugins, the directory must be called ``lookup_foo``, for inventory plugins, ``inventory_foo``, and so on." -msgstr "統合テストは、適切な ``tests/integration/targets/`` ディレクトリーに置く必要があります。モジュールの統合テストでは、モジュール名だけを使用することができます。たとえば、``plugins/modules/foo.py`` の統合テストを``tests/integration/targets/foo/`` というディレクトリーに置くことになります。モジュール以外のプラグインの統合テストでは、ディレクトリー名にプラグインタイプを追加する必要があります。たとえば、``plugins/connections/bar.py`` の統合テストは、``tests/integration/targets/connection_bar/`` というディレクトリーに置くことになります。たとえば、ルックアッププラグインの場合、ディレクトリー名は ``lookup_foo`` となり、インベントリプラグインの場合、``inventory_foo`` となりなります。" - -#: ../../rst/dev_guide/developing_collections.rst:691 -msgid "You can write two different kinds of integration tests:" -msgstr "2 種類の統合テストを作成できます。" - -#: ../../rst/dev_guide/developing_collections.rst:693 -msgid "Ansible role tests run with ``ansible-playbook`` and validate various aspects of the module. They can depend on other integration tests (usually named ``prepare_bar`` or ``setup_bar``, which prepare a service or install a requirement named ``bar`` in order to test module ``foo``) to set-up required resources, such as installing required libraries or setting up server services." -msgstr "これらのテストは、他の統合テスト (通常 ``prepare_bar`` または ``setup_bar`` と呼ばれ、モジュール ``foo`` をテストするためにサービスを準備したり、``bar`` という要件をインストールしたりする) に依存して、必要なライブラリーのインストールやサーバーサービスの設定など、必要なリソースを設定することができます。" - -#: ../../rst/dev_guide/developing_collections.rst:694 -msgid "``runme.sh`` tests run directly as scripts. They can set up inventory files, and execute ``ansible-playbook`` or ``ansible-inventory`` with various settings." -msgstr "``runme.sh`` テストは、直接スクリプトとして実行されます。インベントリーファイルを設定し、さまざまな設定で ``ansible-playbook`` または ``ansible-inventory`` を実行できます。" - -#: ../../rst/dev_guide/developing_collections.rst:696 -msgid "For examples, see the `integration tests in community.general `_. See also :ref:`testing_integration` for more details." -msgstr "例については、「`community.general の統合テスト `_」を参照してください。詳細は、「:ref:`testing_integration`」も参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:698 -msgid "Since integration tests can install requirements, and set-up, start and stop services, we recommended running them in docker containers or otherwise restricted environments whenever possible. By default, ``ansible-test`` supports Docker images for several operating systems. See the `list of supported docker images `_ for all options. Use the ``default`` image mainly for platform-independent integration tests, such as those for cloud modules. The following examples use the ``centos8`` image." -msgstr "統合テストは、要件のインストールや、サービスの設定、開始、および停止を行うことができるため、可能な限り、Docker コンテナーや、制限された環境で実行することが推奨されます。デフォルトでは、``ansible-test`` は複数のオペレーティングシステムの Docker イメージをサポートします。すべてのオプションは `サポート対象の docker イメージ `_ を参照してください。クラウドモジュール用などのプラットフォームに依存しない統合テストには、主に ``default`` イメージを使用します。以下の例では、``centos8`` イメージが使用されています。" - -#: ../../rst/dev_guide/developing_collections.rst:700 -msgid "To execute all integration tests for a collection::" -msgstr "特定のモジュールに対して統合テストを実行するには、次を実行します。" - -#: ../../rst/dev_guide/developing_collections.rst:704 -msgid "If you want more detailed output, run the command with ``-vvv`` instead of ``-v``. Alternatively, specify ``--retry-on-error`` to automatically re-run failed tests with higher verbosity levels." -msgstr "より詳細な出力が必要な場合は、``-v`` ではなく、``-vvv`` でコマンドを実行します。もしくは、``--retry-on-error`` を指定して、失敗したテストを、詳細レベルをあげて自動的に再実行します。" - -#: ../../rst/dev_guide/developing_collections.rst:706 -msgid "To execute only the integration tests in a specific directory::" -msgstr "特定のディレクトリーで統合テストのみを実行するには、以下を行います。" - -#: ../../rst/dev_guide/developing_collections.rst:710 -msgid "You can specify multiple target names. Each target name is the name of a directory in ``tests/integration/targets/``." -msgstr "複数のターゲット名を指定できます。ターゲット名は ``tests/integration/targets/`` のディレクトリーの名前になります。" - -#: ../../rst/dev_guide/developing_collections.rst:715 -msgid "Contributing to collections" -msgstr "コレクションへの貢献" - -#: ../../rst/dev_guide/developing_collections.rst:717 -msgid "If you want to add functionality to an existing collection, modify a collection you are using to fix a bug, or change the behavior of a module in a collection, clone the git repository for that collection and make changes on a branch. You can combine changes to a collection with a local checkout of Ansible (``source hacking/env-setup``)." -msgstr "既存のコレクションに機能を追加する場合は、バグを修正するために使用するコレクションを変更するか、コレクションでモジュールの動作を変更して、ブランチで git リポジトリーのクローンを作成し、ブランチに変更することができます。コレクションへの変更を、Ansible のローカルチェックアウトと組み合わせることができます (``source hacking/env-setup``)。" - -#: ../../rst/dev_guide/developing_collections.rst:719 -msgid "This section describes the process for `community.general `_. To contribute to other collections, replace the folder names ``community`` and ``general`` with the namespace and collection name of a different collection." -msgstr "このセクションでは、`community.general `_ のプロセスを説明します。他のコレクションに貢献する場合は、フォルダー名 ``community`` および ``general`` を、異なるコレクションの名前空間およびコレクション名に置き換えます。" - -#: ../../rst/dev_guide/developing_collections.rst:721 -msgid "We assume that you have included ``~/dev/ansible/collections/`` in :ref:`COLLECTIONS_PATHS`, and if that path mentions multiple directories, that you made sure that no other directory earlier in the search path contains a copy of ``community.general``. Create the directory ``~/dev/ansible/collections/ansible_collections/community``, and in it clone `the community.general Git repository `_ or a fork of it into the folder ``general``::" -msgstr ":ref:`COLLECTIONS_PATHS` に ``~/dev/ansible/collections/`` が含まれており、そのパスで複数のディレクトリーに言及されている場合は、検索パスの他のディレクトリーに ``community.general`` のコピーが含まれないようにします。``~/dev/ansible/collections/ansible_collections/community`` ディレクトリーを作成して、その中に `the community.general Git repository `_ のクローンを作成するか、フォルダー ``general`` にそのディレクトリーのフォークを作成します。" - -#: ../../rst/dev_guide/developing_collections.rst:727 -msgid "If you clone a fork, add the original repository as a remote ``upstream``::" -msgstr "フォークのクローンを作成したら、元のリポジトリーをリモートの ``upstream`` として追加します。" - -#: ../../rst/dev_guide/developing_collections.rst:732 -msgid "Now you can use this checkout of ``community.general`` in playbooks and roles with whichever version of Ansible you have installed locally, including a local checkout of ``ansible/ansible``'s ``devel`` branch." -msgstr "これで、``ansible/ansible`` の ``devel`` ブランチのローカルチェックアウトを含め、ローカルにインストールしたどのバージョンの Ansible でも、Playbook やロールで ``community.general`` のチェックアウトを使用できるようになりました。" - -#: ../../rst/dev_guide/developing_collections.rst:734 -msgid "For collections hosted in the ``ansible_collections`` GitHub org, create a branch and commit your changes on the branch. When you are done (remember to add tests, see :ref:`testing_collections`), push your changes to your fork of the collection and create a Pull Request. For other collections, especially for collections not hosted on GitHub, check the ``README.md`` of the collection for information on contributing to it." -msgstr "``ansible_collections`` GitHub の団体でホストされるコレクションの場合は、ブランチを作成し、ブランチで変更をコミットします。これが完了したら、(テストを追加する方法は、:ref:`testing_collections` を参照してください)。コレクションのフォークに変更をプッシュし、プル要求を作成します。他のコレクション (特に GitHub がホストされていないコレクション) については、コレクションの ``README.md`` でこれに貢献する情報を確認してください。" - -#: ../../rst/dev_guide/developing_collections.rst:739 -msgid "Generating changelogs for a collection" -msgstr "コレクションのチェンジログの生成" - -#: ../../rst/dev_guide/developing_collections.rst:741 -msgid "We recommend that you use the `antsibull-changelog `_ tool to generate Ansible-compatible changelogs for your collection. The Ansible changelog uses the output of this tool to collate all the collections included in an Ansible release into one combined changelog for the release." -msgstr "`antsibull-changelog `_ ツールを使用してコレクションに Ansible 互換の changelog を生成することが推奨されます。Ansibleの changelog は、このツールの出力を利用して、Ansible のリリースに含まれるすべてのコレクションを、そのリリースの 1 つの統合されたチェンジログに照合します。" - -#: ../../rst/dev_guide/developing_collections.rst:745 -msgid "Ansible here refers to the Ansible 2.10 or later release that includes a curated set of collections." -msgstr "Ansible は、指定したコレクションセットを含む Ansible 2.10 以降のリリースを参照します。" - -#: ../../rst/dev_guide/developing_collections.rst:748 -msgid "Understanding antsibull-changelog" -msgstr "antsibull-changelog について" - -#: ../../rst/dev_guide/developing_collections.rst:750 -msgid "The ``antsibull-changelog`` tool allows you to create and update changelogs for Ansible collections that are compatible with the combined Ansible changelogs. This is an update to the changelog generator used in prior Ansible releases. The tool adds three new changelog fragment categories: ``breaking_changes``, ``security_fixes`` and ``trivial``. The tool also generates the ``changelog.yaml`` file that Ansible uses to create the combined ``CHANGELOG.rst`` file and Porting Guide for the release." -msgstr "``antsibull-changelog`` ツールを使用すると、組み合わせた Ansible の changelog と互換性のある Ansible コレクションに対して changelog を作成し、更新できます。これは、Ansible リリース以前で使用される changelog ジェネレーターに対する更新です。このツールは、``breaking_changes``、``security_fixes``、および ``trivial`` の 3 つの新しい changelog フラグメントカテゴリーを追加します。このツールは、Ansible がリリースを組み合わせた ``CHANGELOG.rst`` ファイルと移植ガイドを作成するために使用する ``changelog.yaml`` ファイルも生成します。" - -#: ../../rst/dev_guide/developing_collections.rst:752 -msgid "See :ref:`changelogs_how_to` and the `antsibull-changelog documentation `_ for complete details." -msgstr "詳細は、「:ref:`changelogs_how_to`」および`antsibull-changelog ドキュメント `_ を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:756 -msgid "The collection maintainers set the changelog policy for their collections. See the individual collection contributing guidelines for complete details." -msgstr "コレクションのメンテナーは、コレクションに changelog ポリシーを設定します。詳細は、詳細については、個々のコレクションの貢献ガイドラインを参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:759 -msgid "Generating changelogs" -msgstr "changelog の生成" - -#: ../../rst/dev_guide/developing_collections.rst:761 -msgid "To initialize changelog generation:" -msgstr "チェンジログの生成を初期化するには、以下を実行します。" - -#: ../../rst/dev_guide/developing_collections.rst:763 -msgid "Install ``antsibull-changelog``: :code:`pip install antsibull-changelog`." -msgstr "``antsibull-changelog``: :code:`pip install antsibull-changelog` をインストールします。" - -#: ../../rst/dev_guide/developing_collections.rst:764 -msgid "Initialize changelogs for your repository: :code:`antsibull-changelog init `." -msgstr "リポジトリーの changelog を初期化します (:code:`antsibull-changelog init `)。" - -#: ../../rst/dev_guide/developing_collections.rst:765 -msgid "Optionally, edit the ``changelogs/config.yaml`` file to customize the location of the generated changelog ``.rst`` file or other options. See `Bootstrapping changelogs for collections `_ for details." -msgstr "必要に応じて、``changelogs/config.yaml`` ファイルを編集して、生成された changelog の ``.rst`` ファイルまたはその他のオプションをカスタマイズします。詳細は、「`コレクションの changelog のブートストラップ `ブートストラップ_」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:767 -msgid "To generate changelogs from the changelog fragments you created:" -msgstr "作成した changelog フラグメントからチェンジログを生成するには、以下を実行します。" - -#: ../../rst/dev_guide/developing_collections.rst:769 -msgid "Optionally, validate your changelog fragments: :code:`antsibull-changelog lint`." -msgstr "必要に応じて、チェンジログフラグメント (:code:`antsibull-changelog lint`) を検証します。" - -#: ../../rst/dev_guide/developing_collections.rst:770 -msgid "Generate the changelog for your release: :code:`antsibull-changelog release [--version version_number]`." -msgstr "リリースのチェンジログ (:code:`antsibull-changelog release [--version version_number]`) を生成します。" - -#: ../../rst/dev_guide/developing_collections.rst:774 -msgid "Add the ``--reload-plugins`` option if you ran the ``antsibull-changelog release`` command previously and the version of the collection has not changed. ``antsibull-changelog`` caches the information on all plugins and does not update its cache until the collection version changes." -msgstr "以前に ``antsibull-changelog release`` コマンドを実行し、コレクションのバージョンが変更されていない場合は、``--reload-plugins`` オプションを追加します。``antsibull-changelog`` はすべてのプラグインに関する情報をキャッシュし、コレクションバージョンが変更されるまでキャッシュを更新しません。" - -#: ../../rst/dev_guide/developing_collections.rst:778 -msgid "Porting Guide entries" -msgstr "移植ガイドエントリー" - -#: ../../rst/dev_guide/developing_collections.rst:780 -msgid "The following changelog fragment categories are consumed by the Ansible changelog generator into the Ansible Porting Guide:" -msgstr "以下の changelog フラグメントカテゴリーは、Ansible changelog ジェネレーターが Ansible 移植ガイドに使用されます。" - -#: ../../rst/dev_guide/developing_collections.rst:782 -msgid "``major_changes``" -msgstr "``major_changes``" - -#: ../../rst/dev_guide/developing_collections.rst:783 -msgid "``breaking_changes``" -msgstr "``breaking_changes``" - -#: ../../rst/dev_guide/developing_collections.rst:784 -msgid "``deprecated_features``" -msgstr "``deprecated_features``" - -#: ../../rst/dev_guide/developing_collections.rst:785 -msgid "``removed_features``" -msgstr "``removed_features``" - -#: ../../rst/dev_guide/developing_collections.rst:788 -msgid "Including collection changelogs into Ansible" -msgstr "Ansible へのコレクション変更ログの追加" - -#: ../../rst/dev_guide/developing_collections.rst:791 -msgid "If your collection is part of Ansible, use one of the following three options to include your changelog into the Ansible release changelog:" -msgstr "コレクションが Ansible の一部である場合は、以下の 3 つのオプションのいずれかを使用して、Ansible リリースの changelog に changelog を追加します。" - -#: ../../rst/dev_guide/developing_collections.rst:793 -msgid "Use the ``antsibull-changelog`` tool." -msgstr "``antsibull-changelog`` ツールの使用" - -#: ../../rst/dev_guide/developing_collections.rst:795 -msgid "If are not using this tool, include the properly formatted ``changelog.yaml`` file into your collection. See the `changelog.yaml format `_ for details." -msgstr "このツールを使用していない場合は、適切にフォーマットされた ``changelog.yaml`` ファイルをコレクションに追加します。詳細は、「`changelog.yaml 形式 `_」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:797 -msgid "Add a link to own changelogs or release notes in any format by opening an issue at https://github.com/ansible-community/ansible-build-data/ with the HTML link to that information." -msgstr "HTML リンクで問題を https://github.com/ansible-community/ansible-build-data/ で開いて、任意の形式で独自の changelog またはリリースノートへのリンクを追加します。" - -#: ../../rst/dev_guide/developing_collections.rst:801 -msgid "For the first two options, Ansible pulls the changelog details from Galaxy so your changelogs must be included in the collection version on Galaxy that is included in the upcoming Ansible release." -msgstr "最初の 2 つのオプションの場合、Ansible は changelog の詳細を Galaxy からプルし、changelog を今後の Ansible リリースに含まれる Galaxy のコレクションバージョンに追加する必要があります。" - -#: ../../rst/dev_guide/developing_collections.rst:807 -msgid ":ref:`collections_galaxy_meta`" -msgstr ":ref:`collections_galaxy_meta`" - -#: ../../rst/dev_guide/developing_collections.rst:808 -msgid "Understand the collections metadata structure." -msgstr "コレクションのメタデータ構造を理解します。" - -#: ../../rst/dev_guide/developing_core.rst:3 -msgid "Developing ``ansible-base``" -msgstr "``ansible-base`` の開発" - -#: ../../rst/dev_guide/developing_core.rst:5 -msgid "Although ``ansible-base`` (the code hosted in the `ansible/ansible repository `_ on GitHub) includes a few plugins that can be swapped out via playbook directives or configuration, much of the code there is not modular. The documents here give insight into how the parts of ``ansible-base`` work together." -msgstr "``ansible-base`` (GitHub の `ansible/ansible repository `_ でホストされるコード) には、Playbook ディレクティブまたは設定を介してスワップできるプラグインが含まれていますが、モジュール化されないコードが多くあります。また、``ansible-base`` の一部が連携する方法に関するドキュメントです。" - -#: ../../rst/dev_guide/developing_core.rst:14 -#: ../../rst/dev_guide/developing_inventory.rst:411 -#: ../../rst/dev_guide/developing_plugins.rst:492 -msgid ":ref:`developing_api`" -msgstr ":ref:`developing_api`" - -#: ../../rst/dev_guide/developing_core.rst:15 -#: ../../rst/dev_guide/developing_plugins.rst:493 -msgid "Learn about the Python API for task execution" -msgstr "タスク実行用の Python API について" - -#: ../../rst/dev_guide/developing_core.rst:17 -msgid "Learn about developing plugins" -msgstr "プラグインの開発について" - -#: ../../rst/dev_guide/developing_core.rst:21 -msgid "#ansible-devel IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible-devel)" - -#: ../../rst/dev_guide/developing_inventory.rst:5 -msgid "Developing dynamic inventory" -msgstr "動的インベントリーの開発" - -#: ../../rst/dev_guide/developing_inventory.rst:7 -msgid "Ansible can pull inventory information from dynamic sources, including cloud sources, by using the supplied :ref:`inventory plugins `. For details about how to pull inventory information, see :ref:`dynamic_inventory`. If the source you want is not currently covered by existing plugins, you can create your own inventory plugin as with any other plugin type." -msgstr "Ansible は、指定された :ref:`インベントリープラグイン ` を使用して、クラウドソースを含む動的ソースからインベントリー情報をプルすることができます。インベントリー情報のプル方法の詳細は、「:ref:`dynamic_inventory`」を参照してください。現在、既存のプラグインで対象とするソースについては、他のプラグインタイプで独自のインベントリープラグインを作成できます。" - -#: ../../rst/dev_guide/developing_inventory.rst:9 -msgid "In previous versions, you had to create a script or program that could output JSON in the correct format when invoked with the proper arguments. You can still use and write inventory scripts, as we ensured backwards compatibility via the :ref:`script inventory plugin ` and there is no restriction on the programming language used. If you choose to write a script, however, you will need to implement some features yourself such as caching, configuration management, dynamic variable and group composition, and so on. If you use :ref:`inventory plugins ` instead, you can leverage the Ansible codebase and add these common features automatically." -msgstr "以前のバージョンでは、適切な引数で呼び出されたときに正しい形式で JSON を出力できるスクリプトやプログラムを作成する必要がありました。:ref:`スクリプトインベントリープラグイン ` を通じて後方互換性を確保しており、使用するプログラミング言語にも制限がないため、インベントリースクリプトを使用したり書いたりすることができます。ただし、スクリプトを書く場合は、キャッシュ、設定管理、動的な変数やグループの構成など、いくつかの機能を自分で実装する必要があります。代わりに:ref:`インベントリープラグイン ` を使用すれば、Ansible のコードベースを活用し、これらの共通機能を自動的に追加することができます。" - -#: ../../rst/dev_guide/developing_inventory.rst:22 -msgid "Inventory sources" -msgstr "インベントリーソース" - -#: ../../rst/dev_guide/developing_inventory.rst:24 -msgid "Inventory sources are the input strings that inventory plugins work with. An inventory source can be a path to a file or to a script, or it can be raw data that the plugin can interpret." -msgstr "インベントリーソースは、インベントリープラグインが機能する入力文字列です。インベントリーソースはファイルまたはスクリプトへのパスにするか、プラグインが解釈できる生のデータになります。" - -#: ../../rst/dev_guide/developing_inventory.rst:27 -msgid "The table below shows some examples of inventory plugins and the source types that you can pass to them with ``-i`` on the command line." -msgstr "以下の表は、コマンドラインで ``-i`` を使用して、インベントリープラグインの例と、プラグインに渡すことができるソースタイプを示しています。" - -#: ../../rst/dev_guide/developing_inventory.rst:30 -msgid "Plugin" -msgstr "プラグイン" - -#: ../../rst/dev_guide/developing_inventory.rst:30 -msgid "Source" -msgstr "ソース" - -#: ../../rst/dev_guide/developing_inventory.rst:32 -msgid ":ref:`host list `" -msgstr ":ref:`host list `" - -#: ../../rst/dev_guide/developing_inventory.rst:32 -msgid "A comma-separated list of hosts" -msgstr "ホストのコンマ区切りリスト" - -#: ../../rst/dev_guide/developing_inventory.rst:34 -msgid ":ref:`yaml `" -msgstr ":ref:`yaml `" - -#: ../../rst/dev_guide/developing_inventory.rst:34 -msgid "Path to a YAML format data file" -msgstr "YAML 形式のデータファイルへのパス" - -#: ../../rst/dev_guide/developing_inventory.rst:36 -msgid ":ref:`constructed `" -msgstr ":ref:`constructed `" - -#: ../../rst/dev_guide/developing_inventory.rst:36 -#: ../../rst/dev_guide/developing_inventory.rst:40 -msgid "Path to a YAML configuration file" -msgstr "YAML 設定ファイルへのパス" - -#: ../../rst/dev_guide/developing_inventory.rst:38 -msgid ":ref:`ini `" -msgstr ":ref:`ini `" - -#: ../../rst/dev_guide/developing_inventory.rst:38 -msgid "Path to an INI formatted data file" -msgstr "INI 形式のデータファイルへのパス" - -#: ../../rst/dev_guide/developing_inventory.rst:40 -msgid ":ref:`virtualbox `" -msgstr ":ref:`virtualbox `" - -#: ../../rst/dev_guide/developing_inventory.rst:42 -msgid ":ref:`script plugin `" -msgstr ":ref:`script plugin `" - -#: ../../rst/dev_guide/developing_inventory.rst:42 -msgid "Path to an executable that outputs JSON" -msgstr "JSON を出力する実行可能ファイルへのパス" - -#: ../../rst/dev_guide/developing_inventory.rst:49 -#: ../../rst/dev_guide/developing_plugins.rst:314 -msgid "Inventory plugins" -msgstr "Inventory プラグイン" - -#: ../../rst/dev_guide/developing_inventory.rst:51 -msgid "Like most plugin types (except modules), inventory plugins must be developed in Python. They execute on the controller and should therefore adhere to the :ref:`control_node_requirements`." -msgstr "ほとんどのプラグインタイプ (モジュールを除く) と同様に、それらは Python で開発されなければなりません。コントローラー上で実行するため、「:ref:`control_node_requirements`」と同じ要件に一致させなければなりません。" - -#: ../../rst/dev_guide/developing_inventory.rst:53 -msgid "Most of the documentation in :ref:`developing_plugins` also applies here. You should read that document first for a general understanding and then come back to this document for specifics on inventory plugins." -msgstr ":ref:`developing_plugins` に関するドキュメントの多くはここでも適用されています。一般的な理解のために最初にこのドキュメントを読んでから、本ガイドで Inventory プラグインの詳細を参照してください。" - -#: ../../rst/dev_guide/developing_inventory.rst:55 -msgid "Normally, inventory plugins are executed at the start of a run, and before the playbooks, plays, or roles are loaded. However, you can use the ``meta: refresh_inventory`` task to clear the current inventory and execute the inventory plugins again, and this task will generate a new inventory." -msgstr "通常、インベントリープラグインは実行の開始時、および Playbook、プレイ、またはロールが読み込まれる前に実行します。``meta: refresh_inventory`` タスクを使用しますが、現在のインベントリーを消去してインベントリープラグインを再度実行することもできます。また、このタスクは新しいインベントリーを生成します。" - -#: ../../rst/dev_guide/developing_inventory.rst:58 -msgid "If you use the persistent cache, inventory plugins can also use the configured cache plugin to store and retrieve data. Caching inventory avoids making repeated and costly external calls." -msgstr "永続キャッシュを使用する場合、inventory プラグインは設定済みのキャッシュプラグインを使用してデータを保存および取得し、コストのかかる外部呼び出しを回避することもできます。" - -#: ../../rst/dev_guide/developing_inventory.rst:63 -msgid "Developing an inventory plugin" -msgstr "Inventory プラグインの開発" - -#: ../../rst/dev_guide/developing_inventory.rst:65 -msgid "The first thing you want to do is use the base class:" -msgstr "最初に行うのは、ベースクラスを使用することです。" - -#: ../../rst/dev_guide/developing_inventory.rst:75 -msgid "If the inventory plugin is in a collection, the NAME should be in the 'namespace.collection_name.myplugin' format. The base class has a couple of methods that each plugin should implement and a few helpers for parsing the inventory source and updating the inventory." -msgstr "Inventory プラグインがコレクションにある場合、NAME は「namespace.collection_name.myplugin」形式である必要があります。このクラスは、各プラグインが実装する必要のあるいくつかのメソッドと、インベントリーソースを解析してインベントリーを更新するためのヘルパーがいくつかあります。" - -#: ../../rst/dev_guide/developing_inventory.rst:77 -msgid "After you have the basic plugin working, you can incorporate other features by adding more base classes:" -msgstr "基本的なプラグインが動作するようになったら、より多くの基本クラスを追加することで他の機能を組み込むことができます。" - -#: ../../rst/dev_guide/developing_inventory.rst:87 -msgid "For the bulk of the work in a plugin, we mostly want to deal with 2 methods ``verify_file`` and ``parse``." -msgstr "プラグインでの作業の大部分では、主に 2 つのメソッド (``verify_file`` と ``parse``) を扱います。" - -#: ../../rst/dev_guide/developing_inventory.rst:92 -msgid "verify_file method" -msgstr "verify_file メソッド" - -#: ../../rst/dev_guide/developing_inventory.rst:94 -msgid "Ansible uses this method to quickly determine if the inventory source is usable by the plugin. The determination does not need to be 100% accurate, as there might be an overlap in what plugins can handle and by default Ansible will try the enabled plugins as per their sequence." -msgstr "Ansible はこのメソッドを使用して、インベントリソースがプラグインで使用可能かどうかを迅速に判断します。この判定は 100％ 正確である必要はありません。なぜなら、プラグインが処理できる内容には重複があり、デフォルトでは Ansible は有効なプラグインを順番に試していくからです。" - -#: ../../rst/dev_guide/developing_inventory.rst:107 -msgid "In the above example, from the :ref:`virtualbox inventory plugin `, we screen for specific file name patterns to avoid attempting to consume any valid YAML file. You can add any type of condition here, but the most common one is 'extension matching'. If you implement extension matching for YAML configuration files, the path suffix . should be accepted. All valid extensions should be documented in the plugin description." -msgstr "上記の例では、:ref:`virtualbox インベントリープラグイン ` からは、有効な YAML ファイルの使用を試みないように、特定のファイル名パターンの画面があります。ここに任意のタイプの条件を追加できますが、最も一般的なものは「拡張子の一致」です。YAML 設定ファイルに一致する拡張子を実装する場合、パスサフィックス . が許可される必要があります。有効なすべての拡張機能は、プラグインの説明に記載されています。" - -#: ../../rst/dev_guide/developing_inventory.rst:109 -msgid "The following is another example that does not use a 'file' but the inventory source string itself, from the :ref:`host list ` plugin:" -msgstr "以下は、「ファイル」を使用せず、:ref:`host list ` プラグインからインベントリソース文字列自体を使用する別の例です。" - -#: ../../rst/dev_guide/developing_inventory.rst:124 -msgid "This method is just to expedite the inventory process and avoid unnecessary parsing of sources that are easy to filter out before causing a parse error." -msgstr "この方法は、Inventory プロセスを迅速化し、解析エラーの原因になる前に簡単に除外できるソースの不要な解析を回避するためのものです。" - -#: ../../rst/dev_guide/developing_inventory.rst:129 -msgid "parse method" -msgstr "解析メソッド" - -#: ../../rst/dev_guide/developing_inventory.rst:131 -msgid "This method does the bulk of the work in the plugin. It takes the following parameters:" -msgstr "この方法は、プラグインの作業の大部分を行います。このメソッドは、以下のパラメーターを取ります。" - -#: ../../rst/dev_guide/developing_inventory.rst:134 -msgid "inventory: inventory object with existing data and the methods to add hosts/groups/variables to inventory" -msgstr "inventory: 既存のデータと、ホスト/グループ/変数をインベントリーに追加するメソッドがある Inventory オブジェクト。" - -#: ../../rst/dev_guide/developing_inventory.rst:135 -msgid "loader: Ansible's DataLoader. The DataLoader can read files, auto load JSON/YAML and decrypt vaulted data, and cache read files." -msgstr "loader: Ansible の DataLoader です。DataLoader は、ファイルの読み取り、JSON/YAML の自動読み込み、vault を使用したデータの復号化、および読み取りファイルのキャッシュを行うことができます。" - -#: ../../rst/dev_guide/developing_inventory.rst:136 -msgid "path: string with inventory source (this is usually a path, but is not required)" -msgstr "path: インベントリーソースを持つ文字列 (通常、これはパスですが、必須ではありません)。" - -#: ../../rst/dev_guide/developing_inventory.rst:137 -msgid "cache: indicates whether the plugin should use or avoid caches (cache plugin and/or loader)" -msgstr "cache: プラグインがキャッシュを使用するかどうかを示します (キャッシュプラグインまたはローダー、もしくはその両方)。" - -#: ../../rst/dev_guide/developing_inventory.rst:140 -msgid "The base class does some minimal assignment for reuse in other methods." -msgstr "ベースクラスは他のメソッドで再利用するための割り当てを最小限に抑えます。" - -#: ../../rst/dev_guide/developing_inventory.rst:150 -msgid "It is up to the plugin now to parse the provided inventory source and translate it into Ansible inventory. To facilitate this, the example below uses a few helper functions:" -msgstr "提供されたインベントリーソースを解析し、それを Ansible インベントリーに変換するのは、プラグイン次第です。これを容易にするために、以下の例ではいくつかのヘルパー関数を使用しています。" - -#: ../../rst/dev_guide/developing_inventory.rst:187 -msgid "The specifics will vary depending on API and structure returned. Remember that if you get an inventory source error or any other issue, you should ``raise AnsibleParserError`` to let Ansible know that the source was invalid or the process failed." -msgstr "この状況は、API および構造の戻り値によって異なります。インベントリーソースエラーや他の問題を取得する場合は、``AnsibleParserError を発生`` させ、ソースが無効であるか、プロセスが失敗したことを Ansible に通知する必要があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:189 -msgid "For examples on how to implement an inventory plugin, see the source code here: `lib/ansible/plugins/inventory `_." -msgstr "インベントリープラグインの実装方法の例は、ソースコード (`lib/ansible/plugins/inventory `_) を参照してください。" - -#: ../../rst/dev_guide/developing_inventory.rst:195 -msgid "inventory cache" -msgstr "インベントリーキャッシュ" - -#: ../../rst/dev_guide/developing_inventory.rst:197 -msgid "To cache the inventory, extend the inventory plugin documentation with the inventory_cache documentation fragment and use the Cacheable base class." -msgstr "インベントリーをキャッシュするには、インベントリープラグインのドキュメントを inventory_cache ドキュメントフラグメントで拡張し、Cacheable 基本クラスを使用します。" - -#: ../../rst/dev_guide/developing_inventory.rst:210 -msgid "Next, load the cache plugin specified by the user to read from and update the cache. If your inventory plugin uses YAML-based configuration files and the ``_read_config_data`` method, the cache plugin is loaded within that method. If your inventory plugin does not use ``_read_config_data``, you must load the cache explicitly with ``load_cache_plugin``." -msgstr "次に、ユーザーが指定したキャッシュプラグインを読み込み、キャッシュの読み取りと更新を行います。インベントリープラグインが YAML ベースの構成ファイルを使用していて、``_read_config_data`` メソッドの場合、キャッシュプラグインはそのメソッド内に読み込まれます。インベントリープラグインが ``_read_config_data`` を使用しない場合は、``load_cache_plugin`` を使用してキャッシュを明示的に読み込む必要があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:221 -msgid "Before using the cache plugin, you must retrieve a unique cache key by using the ``get_cache_key`` method. This task needs to be done by all inventory modules using the cache, so that you don't use/overwrite other parts of the cache." -msgstr "キャッシュプラグインを使用する前に、``get_cache_key`` メソッドを使用して一意のキャッシュキーを取得する必要があります。このタスクは、キャッシュを使用するすべてのインベントリーモジュールで実行する必要があります。これにより、キャッシュの他の部分を使用/上書きしないようになります。" - -#: ../../rst/dev_guide/developing_inventory.rst:231 -msgid "Now that you've enabled caching, loaded the correct plugin, and retrieved a unique cache key, you can set up the flow of data between the cache and your inventory using the ``cache`` parameter of the ``parse`` method. This value comes from the inventory manager and indicates whether the inventory is being refreshed (such as via ``--flush-cache`` or the meta task ``refresh_inventory``). Although the cache shouldn't be used to populate the inventory when being refreshed, the cache should be updated with the new inventory if the user has enabled caching. You can use ``self._cache`` like a dictionary. The following pattern allows refreshing the inventory to work in conjunction with caching." -msgstr "これでキャッシュを有効にし、正しいプラグインを読み込み、一意のキャッシュキーを取得し、``parse`` メソッドの ``cache`` パラメーターを使用して、キャッシュとインベントリーの間でデータのフローを設定できるようになりました。この値は、インベントリーマネージャーから取得され、インベントリーを更新するか (例： ``--flush-cache``、メタタスク ``refresh_inventory`` など) を示します。キャッシュは、更新時にインベントリーを入力するために使用しますが、キャッシュを有効にした場合は、キャッシュを新しいインベントリーで更新する必要があります。ディクショナリーのような ``self._cache`` を使用できます。以下のパターンを使用すると、インベントリーをキャッシュとともに動作させることができます。" - -#: ../../rst/dev_guide/developing_inventory.rst:266 -msgid "After the ``parse`` method is complete, the contents of ``self._cache`` is used to set the cache plugin if the contents of the cache have changed." -msgstr "``parse`` メソッドが完了すると、``self._cache`` の内容は、キャッシュの内容が変更された場合にキャッシュプラグインを設定するために使用されます。" - -#: ../../rst/dev_guide/developing_inventory.rst:271 -msgid "You have three other cache methods available:" -msgstr "3 つのキャッシュメソッドが利用できます。" - -#: ../../rst/dev_guide/developing_inventory.rst:269 -msgid "``set_cache_plugin`` forces the cache plugin to be set with the contents of ``self._cache``, before the ``parse`` method completes" -msgstr "``set_cache_plugin`` は、``parse`` メソッドの完了前にキャッシュプラグインを ``self._cache`` の内容で強制的に設定します。" - -#: ../../rst/dev_guide/developing_inventory.rst:270 -msgid "``update_cache_if_changed`` sets the cache plugin only if ``self._cache`` has been modified, before the ``parse`` method completes" -msgstr "``update_cache_if_changed`` は、``parse`` メソッドが完了する前に ``self._cache`` が変更された場合のみキャッシュプラグインを設定します。" - -#: ../../rst/dev_guide/developing_inventory.rst:271 -msgid "``clear_cache`` flushes the cache, ultimately by calling the cache plugin's ``flush()`` method, whose implementation is dependent upon the particular cache plugin in use. Note that if the user is using the same cache backend for facts and inventory, both will get flushed. To avoid this, the user can specify a distinct cache backend in their inventory plugin configuration." -msgstr "``clear_cache`` キャッシュをフラッシュし、キャッシュプラグインの ``flush()`` メソッドを呼び出すことで、これらの実装は使用中の特定のキャッシュプラグインに依存します。ファクトとインベントリーで同じキャッシュバックエンドを使用している場合は、両方のキャッシュバックエンドをフラッシュします。これを回避するために、インベントリープラグイン設定で個別のキャッシュバックエンドを指定できます。" - -#: ../../rst/dev_guide/developing_inventory.rst:276 -msgid "Common format for inventory sources" -msgstr "インベントリーソースの共通形式" - -#: ../../rst/dev_guide/developing_inventory.rst:278 -msgid "To simplify development, most plugins use a standard YAML-based configuration file as the inventory source. The file has only one required field ``plugin``, which should contain the name of the plugin that is expected to consume the file. Depending on other common features used, you might need other fields, and you can add custom options in each plugin as required. For example, if you use the integrated caching, ``cache_plugin``, ``cache_timeout`` and other cache-related fields could be present." -msgstr "開発を簡単にするために、ほとんどのプラグインはインベントリーソースとして標準的な YAML ベースの設定ファイルを使用しています。このファイルには、必須フィールドが 1 つしかありません (``plugin``)。このフィールドには、このファイルを使用することが期待されるプラグインの名前を入れる必要があります。使用する他の共通機能によっては、他のフィールドが必要になる場合があり、必要に応じて各プラグインにカスタムオプションを追加することができます。たとえば、統合キャッシングを使用する場合は、``cache_plugin``、``cache_timeout`` などのキャッシュ関連のフィールドが存在する可能性があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:285 -msgid "The 'auto' plugin" -msgstr "「auto」プラグイン" - -#: ../../rst/dev_guide/developing_inventory.rst:287 -msgid "From Ansible 2.5 onwards, we include the :ref:`auto inventory plugin ` and enable it by default. If the ``plugin`` field in your standard configuration file matches the name of your inventory plugin, the ``auto`` inventory plugin will load your plugin. The 'auto' plugin makes it easier to use your plugin without having to update configurations." -msgstr "Ansible 2.5 以降では、デフォルトで :ref:`auto inventory plugin ` を追加し、これをデフォルトで有効化します。標準設定ファイルの ``plugin`` フィールドがインベントリープラグインの名前と一致する場合、``auto`` インベントリープラグインはプラグインを読み込みます。「auto」プラグインは、設定を更新せずにプラグインを簡単に使用できます。" - -#: ../../rst/dev_guide/developing_inventory.rst:294 -msgid "Inventory scripts" -msgstr "インベントリースクリプト" - -#: ../../rst/dev_guide/developing_inventory.rst:296 -msgid "Even though we now have inventory plugins, we still support inventory scripts, not only for backwards compatibility but also to allow users to leverage other programming languages." -msgstr "インベントリープラグインはそのままですが、後方互換性だけでなく、ユーザーが他のプログラミング言語を使用できるように、引き続きインベントリースクリプトをサポートします。" - -#: ../../rst/dev_guide/developing_inventory.rst:302 -msgid "Inventory script conventions" -msgstr "インベントリースクリプトの規則" - -#: ../../rst/dev_guide/developing_inventory.rst:304 -msgid "Inventory scripts must accept the ``--list`` and ``--host `` arguments. Although other arguments are allowed, Ansible will not use them. Such arguments might still be useful for executing the scripts directly." -msgstr "インベントリースクリプトは引数 ``--list`` および ``--host `` を受け入れる必要があります。他の引数は設定できますが、Ansible はそれらを使用しません。このような引数は、スクリプトを直接実行するのに役立つ場合があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:307 -msgid "When the script is called with the single argument ``--list``, the script must output to stdout a JSON-encoded hash or dictionary that contains all the groups to be managed. Each group's value should be either a hash or dictionary containing a list of each host, any child groups, and potential group variables, or simply a list of hosts::" -msgstr "スクリプトが単一の引数 ``--list`` で呼び出されると、スクリプトは、標準出力に、管理するすべてのグループが含まれる JSON でエンコードされたハッシュまたはディクショナリーを出力する必要があります。各グループの値は、各ホスト、子グループ、および潜在的なグループ変数の一覧を含むハッシュまたはディクショナリーにする必要があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:329 -msgid "If any of the elements of a group are empty, they may be omitted from the output." -msgstr "グループのいずれかの要素が空の場合は、出力から省略される可能性があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:331 -msgid "When called with the argument ``--host `` (where is a host from above), the script must print either an empty JSON hash/dictionary, or a hash/dictionary of variables to make them available to templates and playbooks. For example::" -msgstr "引数 ``--host `` ( は上述のホスト) で呼び出されると、スクリプトは空の JSON ハッシュ/ディクショナリーか、テンプレートや Playbook で利用できるようにするための変数のハッシュ/ディクショナリーを出力しなければなりません。たとえば、以下のようになります。" - -#: ../../rst/dev_guide/developing_inventory.rst:339 -msgid "Printing variables is optional. If the script does not print variables, it should print an empty hash or dictionary." -msgstr "変数の出力は任意です。スクリプトが変数を出力しない場合は、空のハッシュまたはディクショナリーを出力する必要があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:344 -msgid "Tuning the external inventory script" -msgstr "外部インベントリースクリプトのチューニング" - -#: ../../rst/dev_guide/developing_inventory.rst:348 -msgid "The stock inventory script system mentioned above works for all versions of Ansible, but calling ``--host`` for every host can be rather inefficient, especially if it involves API calls to a remote subsystem." -msgstr "上記のストックのインベントリースクリプトシステムは、すべてのバージョンの Ansible に対して動作しますが、特にリモートサブシステムへの API 呼び出しが必要になる場合は、すべてのホストに対して ``--host`` を呼び出すこともできます。" - -#: ../../rst/dev_guide/developing_inventory.rst:350 -msgid "To avoid this inefficiency, if the inventory script returns a top-level element called \"_meta\", it is possible to return all the host variables in a single script execution. When this meta element contains a value for \"hostvars\", the inventory script will not be invoked with ``--host`` for each host. This behavior results in a significant performance increase for large numbers of hosts." -msgstr "これを回避するには、インベントリースクリプトが「_meta」という最上位の要素を返す場合には、単一スクリプトの実行ですべてのホスト変数を返すことができます。このメタ要素に「hostvars」の値が含まれている場合、インベントリースクリプトは各ホストに対して ``--host`` で呼び出されません。この動作は、多数のホストのパフォーマンスを大幅に向上します。" - -#: ../../rst/dev_guide/developing_inventory.rst:352 -msgid "The data to be added to the top-level JSON dictionary looks like this::" -msgstr "トップレベルの JSON ディクショナリーに追加するデータは次のようになります。" - -#: ../../rst/dev_guide/developing_inventory.rst:371 -msgid "To satisfy the requirements of using ``_meta``, to prevent ansible from calling your inventory with ``--host`` you must at least populate ``_meta`` with an empty ``hostvars`` dictionary. For example::" -msgstr "Ansible が ``--host`` でインベントリーを呼び出すのを防ぐために ``_meta`` を使用する要件を満たすには、少なくとも空の ``hostvars`` ディクショナリーで ``_meta`` を埋めなければなりません。以下に例を示します。" - -#: ../../rst/dev_guide/developing_inventory.rst:387 -msgid "If you intend to replace an existing static inventory file with an inventory script, it must return a JSON object which contains an 'all' group that includes every host in the inventory as a member and every group in the inventory as a child. It should also include an 'ungrouped' group which contains all hosts which are not members of any other group. A skeleton example of this JSON object is:" -msgstr "既存の静的インベントリーファイルをインベントリースクリプトに置き換える場合は、インベントリー内のすべてのホストをメンバーとして、インベントリー内のすべてのグループを子として含む「すべて」のグループを含む JSON オブジェクトを返す必要があります。また、他のグループのメンバーではないすべてのホストを含む「グループ化されていない」グループも含める必要があります。この JSON オブジェクトのスケルトンの例は次のとおりです。。" - -#: ../../rst/dev_guide/developing_inventory.rst:407 -msgid "An easy way to see how this should look is using :ref:`ansible-inventory`, which also supports ``--list`` and ``--host`` parameters like an inventory script would." -msgstr "これがどのように見えるかを確認する簡単な方法は、:ref:`ansible-inventory` を使用することです。これにより、インベントリースクリプトのように ``--list`` パラメーターおよび ``--host`` パラメーターがサポートされます。" - -#: ../../rst/dev_guide/developing_inventory.rst:412 -msgid "Python API to Playbooks and Ad Hoc Task Execution" -msgstr "Playbook およびアドホックタスク実行のための Python API" - -#: ../../rst/dev_guide/developing_inventory.rst:414 -msgid "Get started with developing a module" -msgstr "モジュールの開発を始める" - -#: ../../rst/dev_guide/developing_inventory.rst:417 -msgid "`Ansible Tower `_" -msgstr "`Ansible Tower `_" - -#: ../../rst/dev_guide/developing_inventory.rst:418 -msgid "REST API endpoint and GUI for Ansible, syncs with dynamic inventory" -msgstr "Ansible の REST API エンドポイントおよび GUI (動的インベントリーと同期)" - -#: ../../rst/dev_guide/developing_locally.rst:6 -msgid "Adding modules and plugins locally" -msgstr "モジュールおよびプラグインをローカルで追加" - -#: ../../rst/dev_guide/developing_locally.rst:8 -msgid "The easiest, quickest, and the most popular way to extend Ansible is to use a local module or a plugin. You can create them or copy existing ones for local use. You can store a local module or plugin on your Ansible control node and share it with your team or organization. You can also share a local plugin or module by including it in a collection or embedding it in a role, then publishing the collection or role on Ansible Galaxy. If you are using roles on Ansible Galaxy, then you are already using local modules and plugins without realizing it." -msgstr "Ansible を拡張する最も簡単な方法は、ローカルモジュールまたはプラグインを使用することです。ローカルで使用するためにこれらを作成するか、既存のものをコピーすることができます。Ansible コントロールノードにローカルモジュールまたはプラグインを保存し、チームまたは組織と共有することができます。また、ローカルプラグインまたはモジュールをコレクションに含めるか、ロールに埋め込むことで、Ansible Galaxy にコレクションまたはロールを公開することもできます。Ansible Galaxy でロールを使用している場合は、認識せずにローカルモジュールとプラグインをすでに使用していることになります。" - -#: ../../rst/dev_guide/developing_locally.rst:10 -msgid "If you are using an existing module or plugin but Ansible can't find it, this page is all you need. However, if you want to create a plugin or a module, go to :ref:`developing_plugins` and :ref:`developing_modules_general` topics and then return to this page to know how to add it locally." -msgstr "既存のモジュールまたはプラグインを使用しているにもかかわらず、Ansible で見つからない場合、このページのみが必要となります。プラグインまたはモジュールを作成する場合は、:ref:`developing_plugins` および :ref:`developing_modules_general` トピックに移動してから、このページに戻り、ローカルで追加する方法を説明します。" - -#: ../../rst/dev_guide/developing_locally.rst:12 -msgid "Extending Ansible with local modules and plugins offers lots of shortcuts such as:" -msgstr "ローカルのモジュールおよびプラグインで Ansible を拡張すると、以下のようなショートカットが多数利用できるようになります。" - -#: ../../rst/dev_guide/developing_locally.rst:14 -msgid "You can copy other people's modules and plugins." -msgstr "他のユーザーのモジュールおよびプラグインをコピーできます。" - -#: ../../rst/dev_guide/developing_locally.rst:15 -msgid "When writing a new module, you can choose any programming language you like." -msgstr "新しいモジュールを作成する場合は、任意のプログラミング言語を選択できます。" - -#: ../../rst/dev_guide/developing_locally.rst:16 -msgid "You do not have to clone any repositories." -msgstr "リポジトリーのクローンを作成する必要はありません。" - -#: ../../rst/dev_guide/developing_locally.rst:17 -msgid "You do not have to open a pull request." -msgstr "プルリクエストを開く必要はありません。" - -#: ../../rst/dev_guide/developing_locally.rst:18 -msgid "You do not have to add tests (though we recommend that you do!)." -msgstr "テストを追加する必要はありません (ただし、この操作を推奨しています)。" - -#: ../../rst/dev_guide/developing_locally.rst:20 -msgid "To save a local module or plugin such that Ansible can find and use it, add the module or plugin in the appropriate directory (the directories are specified in later parts of this topic)." -msgstr "Ansible が検出して使用するようにローカルモジュールまたはプラグインを保存するには、適切なディレクトリーにモジュールまたはプラグインを追加します (ディレクトリーは、本トピックの後半で指定されています)。" - -#: ../../rst/dev_guide/developing_locally.rst:28 -msgid "Modules and plugins: what is the difference?" -msgstr "モジュールおよびプラグイン: 相違点" - -#: ../../rst/dev_guide/developing_locally.rst:29 -msgid "If you are looking to add local functionality to Ansible, you might wonder whether you need a module or a plugin. Here is a quick overview to help you decide between the two:" -msgstr "Ansible にローカル機能を追加する場合は、モジュールまたはプラグインのいずれかが必要かを熟知している必要があります。以下は、モジュールまたはプラグインのどちらに問題があるかを判断するための簡単な概要です。" - -#: ../../rst/dev_guide/developing_locally.rst:31 -msgid "Modules are reusable, standalone scripts that can be used by the Ansible API, the :command:`ansible` command, or the :command:`ansible-playbook` command. Modules provide a defined interface. Each module accepts arguments and returns information to Ansible by printing a JSON string to stdout before exiting. Modules execute on the target system (usually that means on a remote system) in separate processes." -msgstr "モジュールは、Ansible API、:command:`ansible` コマンド、または :command:`ansible-playbook` コマンドで使用できる再利用可能なスタンドアロンスクリプトです。モジュールは、定義されたインターフェースを提供します。各モジュールは引数を受け入れ、終了する前に JSON 文字列を stdout に出力して Ansible に情報を返します。モジュールは、別のプロセスでターゲットシステム (通常はリモートシステム上) で実行されます。" - -#: ../../rst/dev_guide/developing_locally.rst:32 -msgid ":ref:`Plugins ` augment Ansible's core functionality and execute on the control node within the ``/usr/bin/ansible`` process. Plugins offer options and extensions for the core features of Ansible - transforming data, logging output, connecting to inventory, and more." -msgstr ":ref:`プラグイン ` は、Ansible のコア機能を拡張し、``/usr/bin/ansible`` プロセス内のコントロールノードで実行します。する。プラグインは、Ansible のコア機能のオプションおよび拡張機能 (データの変換、ログ出力、インベントリーへの接続など) を提供します。" - -#: ../../rst/dev_guide/developing_locally.rst:37 -msgid "Adding a module locally" -msgstr "モジュールをローカルで追加" - -#: ../../rst/dev_guide/developing_locally.rst:38 -msgid "Ansible automatically loads all executable files found in certain directories as modules." -msgstr "Ansible は、特定のディレクトリーにある実行可能ファイルをすべてモジュールとして自動的に読み込みます。" - -#: ../../rst/dev_guide/developing_locally.rst:40 -msgid "For local modules, use the name of the file as the module name: for example, if the module file is ``~/.ansible/plugins/modules/local_users.py``, use ``local_users`` as the module name." -msgstr "ローカルモジュールの場合は、ファイル名をモジュール名として使用します。たとえば、モジュールファイルが ``~/.ansible/plugins/modules/local_users.py`` の場合は、モジュール名として ``local_users`` を使用します。" - -#: ../../rst/dev_guide/developing_locally.rst:42 -msgid "To load your local modules automatically and make them available to all playbooks and roles, add them in any of these locations:" -msgstr "ローカルモジュールを自動的に読み込み、すべての Playbook およびロールで使用できるようにするには、それらを以下のいずれかの場所に追加します。" - -#: ../../rst/dev_guide/developing_locally.rst:44 -msgid "any directory added to the ``ANSIBLE_LIBRARY`` environment variable (``$ANSIBLE_LIBRARY`` takes a colon-separated list like ``$PATH``)" -msgstr "``ANSIBLE_LIBRARY`` 環境変数に追加されたディレクトリー (``$ANSIBLE_LIBRARY`` は ``$PATH``のようにコロンで区切った一覧)" - -#: ../../rst/dev_guide/developing_locally.rst:45 -msgid "``~/.ansible/plugins/modules/``" -msgstr "``~/.ansible/plugins/modules/``" - -#: ../../rst/dev_guide/developing_locally.rst:46 -msgid "``/usr/share/ansible/plugins/modules/``" -msgstr "``/usr/share/ansible/plugins/modules/``" - -#: ../../rst/dev_guide/developing_locally.rst:48 -msgid "After you save your module file in one of these locations, Ansible loads it and you can use it in any local task, playbook, or role." -msgstr "モジュールファイルをこのいずれかの場所に保存すると、Ansible はそのファイルを読み込み、ローカルのタスク、Playbook、またはロールで使用できます。" - -#: ../../rst/dev_guide/developing_locally.rst:50 -msgid "To confirm that ``my_custom_module`` is available:" -msgstr "``my_custom_module`` が利用できることを確認するには、以下を行います。" - -#: ../../rst/dev_guide/developing_locally.rst:52 -msgid "type ``ansible localhost -m my_custom_module``. You should see the output for that module." -msgstr "``ansible localhost -m my_custom_module`` を入力します。このモジュールの出力が表示されるはずです。" - -#: ../../rst/dev_guide/developing_locally.rst:54 -msgid "or" -msgstr "または" - -#: ../../rst/dev_guide/developing_locally.rst:56 -msgid "type ``ansible-doc -t module my_custom_module``. You should see the documentation for that module." -msgstr "``ansible-doc -t module my_custom_module`` を入力します。そのモジュールのドキュメントが表示されるはずです。" - -#: ../../rst/dev_guide/developing_locally.rst:60 -msgid "Currently, the ``ansible-doc`` command can parse module documentation only from modules written in Python. If you have a module written in a programming language other than Python, please write the documentation in a Python file adjacent to the module file." -msgstr "現在、``ansible-doc`` コマンドは、Python で記述されたモジュールからのみモジュールドキュメントを解析できます。Python 以外のプログラミング言語で記述されたモジュールがある場合は、モジュールファイルの横の Python ファイルにドキュメントを作成してください。" - -#: ../../rst/dev_guide/developing_locally.rst:62 -msgid "You can limit the availability of your local module. If you want to use a local module only with selected playbooks or only with a single role, load it in one of the following locations:" -msgstr "ローカルモジュールの可用性を制限することができます。選択した Playbook でのみローカルモジュールを使用する場合、または単一のロールでのみローカルモジュールを使用する場合は、以下のいずれかの場所にロードします。" - -#: ../../rst/dev_guide/developing_locally.rst:64 -msgid "In a selected playbook or playbooks: Store the module in a subdirectory called ``library`` in the directory that contains those playbooks." -msgstr "選択した Playbook で、それらの Playbook が含まれるディレクトリーの ``library`` という名前のサブディレクトリーにモジュールを保存します。" - -#: ../../rst/dev_guide/developing_locally.rst:65 -msgid "In a single role: Store the module in a subdirectory called ``library`` within that role." -msgstr "単一のロール: そのロール内の ``library`` という名前のサブディレクトリーにモジュールを保存します。" - -#: ../../rst/dev_guide/developing_locally.rst:71 -msgid "Adding a plugin locally" -msgstr "プラグインをローカルで追加" - -#: ../../rst/dev_guide/developing_locally.rst:72 -msgid "Ansible loads plugins automatically too, and loads each type of plugin separately from a directory named for the type of plugin. Here's the full list of plugin directory names:" -msgstr "Ansible はプラグインも自動的にロードし、プラグインのタイプに対して名前が付けられたディレクトリーとは別に、各タイプのプラグインを読み込みます。プラグインディレクトリー名の全一覧を以下に示します。" - -#: ../../rst/dev_guide/developing_locally.rst:74 -msgid "action_plugins*" -msgstr "action_plugins*" - -#: ../../rst/dev_guide/developing_locally.rst:75 -msgid "cache_plugins" -msgstr "cache_plugins" - -#: ../../rst/dev_guide/developing_locally.rst:76 -msgid "callback_plugins" -msgstr "callback_plugins" - -#: ../../rst/dev_guide/developing_locally.rst:77 -msgid "connection_plugins" -msgstr "connection_plugins" - -#: ../../rst/dev_guide/developing_locally.rst:78 -msgid "filter_plugins*" -msgstr "filter_plugins*" - -#: ../../rst/dev_guide/developing_locally.rst:79 -msgid "inventory_plugins" -msgstr "inventory_plugins" - -#: ../../rst/dev_guide/developing_locally.rst:80 -msgid "lookup_plugins" -msgstr "lookup_plugins" - -#: ../../rst/dev_guide/developing_locally.rst:81 -msgid "shell_plugins" -msgstr "shell_plugins" - -#: ../../rst/dev_guide/developing_locally.rst:82 -msgid "strategy_plugins" -msgstr "strategy_plugins" - -#: ../../rst/dev_guide/developing_locally.rst:83 -msgid "test_plugins*" -msgstr "test_plugins*" - -#: ../../rst/dev_guide/developing_locally.rst:84 -msgid "vars_plugins" -msgstr "vars_plugins" - -#: ../../rst/dev_guide/developing_locally.rst:88 -msgid "After you add the plugins and verify that they are available for use, you can see the documentation for all the plugins except for the ones marked with an asterisk (*) above." -msgstr "プラグインを追加して、それらが使用できることを確認すると、上記のアスタリスク (*) のマークが付いたものを除き、すべてのプラグインのドキュメントを表示できます。" - -#: ../../rst/dev_guide/developing_locally.rst:90 -msgid "To load your local plugins automatically, add them in any of these locations:" -msgstr "ローカルプラグインを自動的に読み込むには、以下のいずれかの場所に追加します。" - -#: ../../rst/dev_guide/developing_locally.rst:92 -msgid "any directory added to the relevant ``ANSIBLE_plugin_type_PLUGINS`` environment variable (these variables, such as ``$ANSIBLE_INVENTORY_PLUGINS`` and ``$ANSIBLE_VARS_PLUGINS`` take colon-separated lists like ``$PATH``)" -msgstr "関連する ``ANSIBLE_plugin_type_PLUGINS`` 環境変数に追加されたディレクトリー (``$ANSIBLE_INVENTORY_PLUGINS``、``$ANSIBLE_VARS_PLUGINS`` など) は、``$PATH`` のようにコロンで区切った一覧を取ります。" - -#: ../../rst/dev_guide/developing_locally.rst:93 -msgid "the directory named for the correct ``plugin_type`` within ``~/.ansible/plugins/`` - for example, ``~/.ansible/plugins/callback``" -msgstr "``~/.ansible/plugins/`` 内の正しい ``plugin_type`` という名前のディレクトリー (例: ``~/.ansible/plugins/callback``)" - -#: ../../rst/dev_guide/developing_locally.rst:94 -msgid "the directory named for the correct ``plugin_type`` within ``/usr/share/ansible/plugins/`` - for example, ``/usr/share/ansible/plugins/action``" -msgstr "``/usr/share/ansible/plugins/`` 内の正しい ``plugin_type`` という名前のディレクトリー (例: ``/usr/share/ansible/plugins/action``)" - -#: ../../rst/dev_guide/developing_locally.rst:96 -msgid "After your plugin file is in one of these locations, Ansible loads it and you can use it in any local module, task, playbook, or role. Alternatively, you can edit your ``ansible.cfg`` file to add directories that contain local plugins. For details about adding directories of local plugins, see :ref:`ansible_configuration_settings`." -msgstr "プラグインファイルがこれらの場所のいずれかに置かれたら、Ansible が読み込み、ローカルモジュール、タスク、Playbook、またはロールで使用することができます。``ansible.cfg`` ファイルを編集してローカルプラグインを含むディレクトリーを追加できます。ローカルプラグインのディレクトリーを追加する方法については、:ref:`ansible_configuration_settings` を参照してください。" - -#: ../../rst/dev_guide/developing_locally.rst:98 -msgid "To confirm that ``plugins/plugin_type/my_custom_plugin`` is available:" -msgstr "``plugins/plugin_type/my_custom_plugin`` が利用できることを確認するには、以下を行います。" - -#: ../../rst/dev_guide/developing_locally.rst:100 -msgid "type ``ansible-doc -t my_custom_lookup_plugin``. For example, ``ansible-doc -t lookup my_custom_lookup_plugin``. You should see the documentation for that plugin. This works for all plugin types except the ones marked with ``*`` in the list above - see :ref:`ansible-doc` for more details." -msgstr "``ansible-doc -t my_custom_lookup_plugin`` を入力します (例: ``ansible-doc -t lookup my_custom_lookup_plugin``)。そのプラグインに関するドキュメントを確認してください。これは上記のリストで ``*`` のマークが付いたもの以外のすべてのプラグインタイプで機能します。詳細は「:ref:`ansible-doc`」を参照してください。" - -#: ../../rst/dev_guide/developing_locally.rst:102 -msgid "You can limit the availability of your local plugin. If you want to use a local plugin only with selected playbooks or only with a single role, load it in one of the following locations:" -msgstr "ローカルプラグインの可用性を制限することができます。選択した Playbook でのみローカルプラグインを使用する場合、または単一のロールでのみローカルプラグインを使用する場合は、以下のいずれかの場所に読み込みます。" - -#: ../../rst/dev_guide/developing_locally.rst:104 -msgid "In a selected playbook or playbooks: Store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``callback_plugins`` or ``inventory_plugins``) in the directory that contains the playbooks." -msgstr "選択した Playbook: そのPlaybook を含むディレクトリーに、正しい ``plugin_type`` (例: ``callback_plugins`` または ``inventory_plugins``) のサブディレクトリーにプラグインを保存します。" - -#: ../../rst/dev_guide/developing_locally.rst:105 -msgid "In a single role: Store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``cache_plugins`` or ``strategy_plugins``) within that role. When shipped as part of a role, the plugin is available as soon as the role is executed." -msgstr "単一のロール: そのロール内で、正しい ``plugin_type`` （例： ``cache_plugins`` または ``strategy_plugins``) のサブディレクトリーにプラグインを保存します。ロールの一部として提供されると、ロールが実行されるとすぐにプラグインが利用可能になります。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:5 -msgid "Using and developing module utilities" -msgstr "モジュールユーティリティーの使用および開発" - -#: ../../rst/dev_guide/developing_module_utilities.rst:7 -msgid "Ansible provides a number of module utilities, or snippets of shared code, that provide helper functions you can use when developing your own modules. The ``basic.py`` module utility provides the main entry point for accessing the Ansible library, and all Python Ansible modules must import something from ``ansible.module_utils``. A common option is to import ``AnsibleModule``::" -msgstr "Ansible は、独自のモジュール開発時に使用できるヘルパー関数を提供する多くのモジュールユーティリティー、またはスニペットを提供します。``basic.py`` モジュールユーティリティーは、Ansible ライブラリーにアクセスするためのメインのエントリーポイントを提供します。また、すべての Python Ansible モジュールは ``ansible.module_utils`` からインポートする必要があります。一般的なオプションでは、``AnsibleModule`` をインポートするのが一般的です。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:15 -msgid "The ``ansible.module_utils`` namespace is not a plain Python package: it is constructed dynamically for each task invocation, by extracting imports and resolving those matching the namespace against a :ref:`search path ` derived from the active configuration." -msgstr "``ansible.module_utils`` 名前空間は単純な Python パッケージではありません。これは、インポートを抽出し、アクティブな設定から派生する :ref:`検索パス ` に対して一致する名前空間を解決することで、各タスク呼び出し用に動的に構築されます。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:20 -msgid "To reduce the maintenance burden in a collection or in local modules, you can extract duplicated code into one or more module utilities and import them into your modules. For example, if you have your own custom modules that import a ``my_shared_code`` library, you can place that into a ``./module_utils/my_shared_code.py`` file like this::" -msgstr "コレクションまたはローカルモジュールのメンテナンス負荷を軽減するには、重複コードを 1 つ以上のモジュールユーティリティーに抽出してモジュールにインポートすることができます。たとえば、``my_shared_code`` ライブラリーをインポートする独自のカスタムモジュールがある場合は、これを、以下のように ``./module_utils/my_shared_code.py`` ファイルに配置できます。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:25 -msgid "When you run ``ansible-playbook``, Ansible will merge any files in your local ``module_utils`` directories into the ``ansible.module_utils`` namespace in the order defined by the :ref:`Ansible search path `." -msgstr "``ansible-playbook`` を実行すると、Ansible は :ref:`Ansible search path ` で定義されている順序でローカルの ``module_utils`` ディレクトリーのファイルを ``ansible.module_utils`` 名前空間にマージします。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:28 -msgid "Naming and finding module utilities" -msgstr "モジュールユーティリティーの命名および検索" - -#: ../../rst/dev_guide/developing_module_utilities.rst:30 -msgid "You can generally tell what a module utility does from its name and/or its location. Generic utilities (shared code used by many different kinds of modules) live in the main ansible/ansible codebase, in the ``common`` subdirectory or in the root directory of ``lib/ansible/module_utils``. Utilities used by a particular set of modules generally live in the same collection as those modules. For example:" -msgstr "通常、モジュールユーティリティーが名前やその場所から動作するようにできます。汎用ユーティリティー (さまざまな種類のモジュールで使用される共有コード) は、メインの ansible/ansible コードベースにあります。``common`` サブディレクトリー、または ``lib/ansible/module_utils`` のルートディレクトリーにあります。特定のモジュールセットで使用されるユーティリティーは、通常、それらのモジュールと同じコレクションに存在します。以下に例を示します。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:32 -msgid "``lib/ansible/module_utils/urls.py`` contains shared code for parsing URLs" -msgstr "``lib/ansible/module_utils/urls.py`` は、URL を解析するための共有コードが含まれています" - -#: ../../rst/dev_guide/developing_module_utilities.rst:33 -msgid "``openstack.cloud.plugins.module_utils.openstack.py`` contains utilities for modules that work with OpenStack instances" -msgstr "たとえば、``openstack.cloud.plugins.module_utils.openstack.py`` には、OpenStack インスタンスと連携するモジュールのユーティリティーが含まれます。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:34 -msgid "``ansible.netcommon.plugins.module_utils.network.common.config.py`` contains utility functions for use by networking modules" -msgstr "``ansible.netcommon.plugins.module_utils.network.common.config.py`` は、ネットワークモジュールによって使用される設定ユーティリティーの機能が含まれます。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:36 -msgid "Following this pattern with your own module utilities makes everything easy to find and use." -msgstr "このパターンを独自のモジュールユーティリティーで行うと、あらゆるものを見つけ、使用することが容易になります。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:41 -msgid "Standard module utilities" -msgstr "標準のモジュールユーティリティー" - -#: ../../rst/dev_guide/developing_module_utilities.rst:43 -msgid "Ansible ships with an extensive library of ``module_utils`` files. You can find the module utility source code in the ``lib/ansible/module_utils`` directory under your main Ansible path. We describe the most widely used utilities below. For more details on any specific module utility, please see the `source code for module_utils `_." -msgstr "Ansible には、``module_utils`` ファイルの広範なライブラリーが含まれています。モジュールユーティリティーのソースコードは、メインの Ansible パス下の ``lib/ansible/module_utils`` ディレクトリーにあります。また、以下で最も広く使用されているユーティリティーが含まれています。特定のモジュールユーティリティーの詳細は、「`モジュールユーティリティーのソースコード `_」を参照してください。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:2 -msgid "**LICENSING REQUIREMENTS** Ansible enforces the following licensing requirements:" -msgstr "**ライセンス要件** Ansible は、以下のライセンス要件を強制します。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:7 -msgid "Utilities (files in ``lib/ansible/module_utils/``) may have one of two licenses:" -msgstr "ユーティリティー (``lib/ansible/module_utils/``内のファイル) には、2 つあるライセンスのいずれかが存在する可能性があります。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:5 -msgid "A file in ``module_utils`` used **only** for a specific vendor's hardware, provider, or service may be licensed under GPLv3+. Adding a new file under ``module_utils`` with GPLv3+ needs to be approved by the core team." -msgstr "特定のベンダーのハードウェア、プロバイダー、またはサービスに**のみ** ``module_utils`` を使用するファイルは、GPLv3 以降を持つ ``module_utils``に新しいファイルを追加するには、コアチームによる承認が必要になります。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:7 -msgid "All other ``module_utils`` must be licensed under BSD, so GPL-licensed third-party and Galaxy modules can use them." -msgstr "他のすべての ``module_utils`` は、GPL のライセンスが付与されたサードパーティーと Galaxy モジュールが使用できるように、BSD でライセンスが付与されている必要があります。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:8 -msgid "If there's doubt about the appropriate license for a file in ``module_utils``, the Ansible Core Team will decide during an Ansible Core Community Meeting." -msgstr "``module_utils`` のファイルに適切なライセンスについて疑問がある場合は、Ansible Core Team が Ansible Core Community Meeting 中に決定します。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:9 -msgid "All other files shipped with Ansible, including all modules, must be licensed under the GPL license (GPLv3 or later)." -msgstr "すべてのモジュールを含む Ansible に同梱される他のすべてのファイルは、GPL ライセンス (GPLv3 以降) でライセンスする必要があります。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:47 -msgid "``api.py`` - Supports generic API modules" -msgstr "``api.py`` - 汎用 API モジュールのサポート" - -#: ../../rst/dev_guide/developing_module_utilities.rst:48 -msgid "``basic.py`` - General definitions and helper utilities for Ansible modules" -msgstr "``basic.py`` - Ansible モジュールの一般的な定義およびヘルパーユーティリティー。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:49 -msgid "``common/dict_transformations.py`` - Helper functions for dictionary transformations" -msgstr "``common/dict_transformations.py`` - ディクショナリー変換のヘルパー関数。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:50 -msgid "``common/file.py`` - Helper functions for working with files" -msgstr "``common/file.py`` - ファイルを操作するヘルパー関数" - -#: ../../rst/dev_guide/developing_module_utilities.rst:51 -msgid "``common/text/`` - Helper functions for converting and formatting text" -msgstr "``common/text/`` - テキスト変換およびフォーマットを行うためのヘルパー関数" - -#: ../../rst/dev_guide/developing_module_utilities.rst:52 -msgid "``common/parameters.py`` - Helper functions for dealing with module parameters" -msgstr "``common/parameters.py`` - モジュールパラメーターを処理するヘルパー関数" - -#: ../../rst/dev_guide/developing_module_utilities.rst:53 -msgid "``common/sys_info.py`` - Functions for getting distribution and platform information" -msgstr "``common/sys_info.py`` - ディストリビューションおよびプラットフォーム情報を取得する機能。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:54 -msgid "``common/validation.py`` - Helper functions for validating module parameters against a module argument spec" -msgstr "``common/validation.py`` - モジュール引数仕様に対してモジュールパラメーターを検証するためのヘルパー関数。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:55 -msgid "``facts/`` - Directory of utilities for modules that return facts. See `PR 23012 `_ for more information" -msgstr "``facts/`` - 詳細は、`PR 23012 `_ を参照してください。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:56 -msgid "``json_utils.py`` - Utilities for filtering unrelated output around module JSON output, like leading and trailing lines" -msgstr "``json_utils.py`` - 先頭行や末尾行など、モジュール JSON 出力に関する関連のない出力をフィルタリングするユーティリティー。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:57 -msgid "``powershell/`` - Directory of definitions and helper functions for Windows PowerShell modules" -msgstr "``powershell/`` - Windows PowerShell モジュールの定義およびヘルパー関数のディレクトリー。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:58 -msgid "``pycompat24.py`` - Exception workaround for Python 2.4" -msgstr "``pycompat24.py`` - Python 2.4 の例外回避策" - -#: ../../rst/dev_guide/developing_module_utilities.rst:59 -msgid "``service.py`` - Utilities to enable modules to work with Linux services (placeholder, not in use)" -msgstr "``service.py`` - モジュールが Linux サービスと連携できるようにするユーティリティー (未使用のプレースホルダー)。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:60 -msgid "``six/__init__.py`` - Bundled copy of the `Six Python library `_ to aid in writing code compatible with both Python 2 and Python 3" -msgstr "``six/__init__.py`` - Python 2 と Python 3 の両方と互換性のあるコードを書き込む際に助けとなる `Six Python ライブラリー `_ のバンドルコピー。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:61 -msgid "``splitter.py`` - String splitting and manipulation utilities for working with Jinja2 templates" -msgstr "``splitter.py`` - Jinja2 テンプレートを使用する文字列分割および操作ユーティリティー。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:62 -msgid "``urls.py`` - Utilities for working with http and https requests" -msgstr "``urls.py`` - http および https リクエストを操作するユーティリティー。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:64 -msgid "Several commonly-used utilities migrated to collections in Ansible 2.10, including:" -msgstr "一般的に使用されるいくつかのユーティリティーは、Ansible 2.10 では以下のようなコレクションに移行されています。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:66 -msgid "``ismount.py`` migrated to ``ansible.posix.plugins.module_utils.mount.py`` - Single helper function that fixes os.path.ismount" -msgstr "``ansible.posix.plugins.module_utils.mount.py`` に移行した ``ismount.py`` - os.path.ismount を修正する単一のヘルパー関数。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:67 -msgid "``known_hosts.py`` migrated to ``community.general.plugins.module_utils.known_hosts.py`` - utilities for working with known_hosts file" -msgstr "``community.general.plugins.module_utils.known_hosts.py`` に移行した ``known_hosts.py`` - known_hosts ファイルで作業するためのユーティリティー。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:69 -msgid "For a list of migrated content with destination collections, see https://github.com/ansible/ansible/blob/devel/lib/ansible/config/ansible_builtin_runtime.yml." -msgstr "宛先コレクションで移行されたコンテンツの一覧は、https://github.com/ansible/ansible/blob/devel/lib/ansible/config/ansible_builtin_runtime.yml を参照してください。" - -#: ../../rst/dev_guide/developing_modules.rst:6 -msgid "Should you develop a module?" -msgstr "モジュール開発の必要性" - -#: ../../rst/dev_guide/developing_modules.rst:8 -msgid "Developing Ansible modules is easy, but often it is not necessary. Before you start writing a new module, ask:" -msgstr "Ansible モジュールの開発は容易ですが、通常は不要です。新しいモジュールを書き始める前に、以下を確認してください。" - -#: ../../rst/dev_guide/developing_modules.rst:10 -msgid "Does a similar module already exist?" -msgstr "同様のモジュールが存在しているか。" - -#: ../../rst/dev_guide/developing_modules.rst:12 -msgid "An existing module may cover the functionality you want. Ansible collections include thousands of modules. Search our :ref:`list of included collections ` or `Ansible Galaxy `_ to see if an existing module does what you need." -msgstr "既存のモジュールは必要な機能に対応できます。Ansible コレクションには、数千のモジュールが含まれています。:ref:`同梱されるコレクションの一覧 ` または `Ansible Galaxy `_ を検索すると、既存のモジュールが必要なモジュールかどうかが分かります。" - -#: ../../rst/dev_guide/developing_modules.rst:14 -msgid "Should you use or develop an action plugin instead of a module?" -msgstr "モジュールの代わりにアクションプラグインを使用するか、または開発する必要があるか。" - -#: ../../rst/dev_guide/developing_modules.rst:16 -msgid "An action plugin may be the best way to get the functionality you want. Action plugins run on the control node instead of on the managed node, and their functionality is available to all modules. For more information about developing plugins, read the :ref:`developing plugins page `." -msgstr "アクションプラグインは、必要な機能を取得する最善の方法となるでしょう。アクションプラグインは、管理ノードではなくコントロールノードで実行され、その機能はすべてのモジュールで利用できます。プラグインの開発に関する詳細は、「:ref:`プラグインの開発ページ`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules.rst:18 -msgid "Should you use a role instead of a module?" -msgstr "モジュールの代わりにロールを使用する必要があるか。" - -#: ../../rst/dev_guide/developing_modules.rst:20 -msgid "A combination of existing modules may cover the functionality you want. You can write a role for this type of use case. Check out the :ref:`roles documentation`." -msgstr "既存のモジュールの組み合わせによって、希望の機能に対応できる可能性があります。このタイプのユースケースにロールを作成することができます。:ref:`ロールのドキュメント` を確認してください。" - -#: ../../rst/dev_guide/developing_modules.rst:22 -msgid "Should you create a collection instead of a single module?" -msgstr "1 つのモジュールの代わりにコレクションを作成する必要があるか。" - -#: ../../rst/dev_guide/developing_modules.rst:24 -msgid "The functionality you want may be too large for a single module. If you want to connect Ansible to a new cloud provider, database, or network platform, you may need to :ref:`develop a new collection`." -msgstr "1 つのモジュールでは、この機能が大きすぎる可能性があります。Ansible を新しいクラウドプロバイダー、データベース、またはネットワークプラットフォームに接続する場合は、:ref:`新しいコレクションの開発` が必要になる場合があります。" - -#: ../../rst/dev_guide/developing_modules.rst:26 -msgid "Each module should have a concise and well defined functionality. Basically, follow the UNIX philosophy of doing one thing well." -msgstr "各モジュールには、簡潔で十分に機能が定義されている必要があります。基本的には、1 つのことを十分に行うという UNIX の哲学に従ってください。" - -#: ../../rst/dev_guide/developing_modules.rst:28 -msgid "A module should not require that a user know all the underlying options of an API/tool to be used. For instance, if the legal values for a required module parameter cannot be documented, that's a sign that the module would be rejected." -msgstr "モジュールは、使用する API またはツールの基礎となるすべてのオプションを把握する必要がありません。たとえば、必要なモジュールパラメーターの有効な値を文書化できない場合、それはモジュールが拒否されることを示しています。" - -#: ../../rst/dev_guide/developing_modules.rst:30 -msgid "Modules should typically encompass much of the logic for interacting with a resource. A lightweight wrapper around an API that does not contain much logic would likely cause users to offload too much logic into a playbook, and for this reason the module would be rejected. Instead try creating multiple modules for interacting with smaller individual pieces of the API." -msgstr "モジュールは通常、リソースと対話するロジックの多くを網羅する必要があります。ロジックをあまり含まない API の軽量ラッパーを使用すると、ユーザーがあまりにも多くのロジックを Playbook にオフロードする原因となる可能性があるため、モジュールが拒否されます。代わりに、API の小さな個々の部分と対話するための複数のモジュールを作成してみてください。" - -#: ../../rst/dev_guide/developing_modules.rst:32 -msgid "If your use case isn't covered by an existing module, an action plugin, or a role, and you don't need to create multiple modules, then you're ready to start developing a new module. Choose from the topics below for next steps:" -msgstr "ユースケースが、既存のモジュール、アクションプラグイン、またはロールでは対応されておらず、複数のモジュールを作成する必要がない場合は、新しいモジュールの開発を開始する準備ができています。次のステップは、以下のトピックから選択します。" - -#: ../../rst/dev_guide/developing_modules.rst:34 -msgid "I want to :ref:`get started on a new module `." -msgstr ":ref:`新しいモジュールを使用開始` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:35 -msgid "I want to review :ref:`tips and conventions for developing good modules `." -msgstr ":ref:`良質なモジュールを開発するためのヒントおよび規約 ` を確認します。" - -#: ../../rst/dev_guide/developing_modules.rst:36 -msgid "I want to :ref:`write a Windows module `." -msgstr ":ref:`Windows モジュールを作成 ` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:37 -msgid "I want :ref:`an overview of Ansible's architecture `." -msgstr ":ref:`Ansible のアーキテクチャーの概要 ` が必要です。" - -#: ../../rst/dev_guide/developing_modules.rst:38 -msgid "I want to :ref:`document my module `." -msgstr ":ref:`作成したモジュールをドキュメント化 ` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:39 -msgid "I want to :ref:`contribute my module back to Ansible Core `." -msgstr ":ref:`作成したモジュールを Ansible Core に貢献 ` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:40 -msgid "I want to :ref:`add unit and integration tests to my module `." -msgstr ":ref:`作成したモジュールに単体テストおよび統合テストを追加 ` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:41 -msgid "I want to :ref:`add Python 3 support to my module `." -msgstr ":ref:`作成したモジュールに Python 3 サポートを追加 ` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:42 -msgid "I want to :ref:`write multiple modules `." -msgstr ":ref:`複数モジュールを作成 ` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:46 -#: ../../rst/dev_guide/developing_plugins.rst:490 -msgid ":ref:`list_of_collections`" -msgstr ":ref:`list_of_collections`" - -#: ../../rst/dev_guide/developing_modules.rst:47 -#: ../../rst/dev_guide/developing_plugins.rst:491 -msgid "Browse existing collections, modules, and plugins" -msgstr "既存のコレクション、モジュール、およびプラグインの閲覧" - -#: ../../rst/dev_guide/developing_modules.rst:49 -msgid "Development mailing list" -msgstr "開発メーリングリスト" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:6 -msgid "Conventions, tips, and pitfalls" -msgstr "規則、ヒント、および落とし穴" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:11 -msgid "As you design and develop modules, follow these basic conventions and tips for clean, usable code:" -msgstr "モジュールの設計および開発を行う際に、以下の基本的な規則およびヒントに従って、読みやすく使用可能なコードを作成します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:14 -msgid "Scoping your module(s)" -msgstr "モジュールのスコープ設定" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:16 -msgid "Especially if you want to contribute your module(s) to an existing Ansible Collection, make sure each module includes enough logic and functionality, but not too much. If these guidelines seem confusing, consider :ref:`whether you really need to write a module ` at all." -msgstr "特に、既存の Ansible Collection にモジュールを提供する場合は、各モジュールに十分なロジックと機能が含まれていることを確認してください。ただし、多すぎないようにしてください。これらのガイドラインが紛らわしいと思われる場合は、:ref:`モジュールの記述が本当に必要かどうか ` を検討してください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:18 -msgid "Each module should have a concise and well-defined functionality. Basically, follow the UNIX philosophy of doing one thing well." -msgstr "各モジュールには、簡潔で十分に機能が定義されている必要があります。基本的には、1 つのことを十分に行うという UNIX の哲学に従ってください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:19 -msgid "Do not add ``get``, ``list`` or ``info`` state options to an existing module - create a new ``_info`` or ``_facts`` module." -msgstr "既存のモジュールに、``get``、``list``、または ``info`` の状態のオプションを追加しないでください。新しい ``_info`` モジュールまたは ``_facts`` モジュールを作成します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:20 -msgid "Modules should not require that a user know all the underlying options of an API/tool to be used. For instance, if the legal values for a required module option cannot be documented, the module does not belong in Ansible Core." -msgstr "モジュールでは、使用する API またはツールの基礎となるオプションをすべてユーザーが把握する必要がありません。たとえば、必要なモジュールパラメーターの有効な値を文書化できない場合、そのモジュールは Ansible Core に属しません。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:21 -msgid "Modules should encompass much of the logic for interacting with a resource. A lightweight wrapper around a complex API forces users to offload too much logic into their playbooks. If you want to connect Ansible to a complex API, :ref:`create multiple modules ` that interact with smaller individual pieces of the API." -msgstr "モジュールは、リソースと対話するためのロジックを多数組み込む必要があります。複雑な API に関連した軽量ラッパーにより、ユーザーは Playbook に非常に多くのロジックをオフロードします。Ansible を複雑な API に接続する場合は、より複雑な API と対話する :ref:`複数のモジュールを作成 ` する必要があります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:22 -msgid "Avoid creating a module that does the work of other modules; this leads to code duplication and divergence, and makes things less uniform, unpredictable and harder to maintain. Modules should be the building blocks. If you are asking 'how can I have a module execute other modules' ... you want to write a role." -msgstr "他のモジュールの作業を行うモジュールを作成しないようにしてください。これにより、コードの重複と差異が発生し、一貫性が保たれず、予測ができなくなり、維持が難しくなります。モジュールはビルディングブロックでなければなりません。「どのようにしてモジュールに他のモジュールを実行させることができるのか」という質問が浮かんでくる場合は、それがロールを作成する理由になります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:25 -msgid "Designing module interfaces" -msgstr "モジュールインターフェースの設計" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:27 -msgid "If your module is addressing an object, the option for that object should be called ``name`` whenever possible, or accept ``name`` as an alias." -msgstr "モジュールがオブジェクトに対処している場合は、可能な限りそのオブジェクトのパラメーターを ``name`` とするか、またはエイリアスとして ``name`` を受け入れます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:28 -msgid "Modules accepting boolean status should accept ``yes``, ``no``, ``true``, ``false``, or anything else a user may likely throw at them. The AnsibleModule common code supports this with ``type='bool'``." -msgstr "ブール値ステータスを許可するモジュールは、``yes``、``no``、``true``、``false``、もしくはユーザーに出力される可能性があるものはなんでも受け入れる必要がります。Ansible Module の一般的なコードは、``type='bool'`` でこれをサポートします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:29 -msgid "Avoid ``action``/``command``, they are imperative and not declarative, there are other ways to express the same thing." -msgstr "``action``/``command`` は使用しないでください。これは命令型であり、宣言的ではありませんが、同じ方法を表示する方法は他にもあります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:32 -msgid "General guidelines & tips" -msgstr "一般的なガイドラインおよびヒント" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:34 -msgid "Each module should be self-contained in one file, so it can be auto-transferred by ``ansible-base``." -msgstr "各モジュールは 1 つのファイルにまとめて自己完結させる必要があり、``ansible-base`` で自動転送できるようにします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:35 -msgid "Module name MUST use underscores instead of hyphens or spaces as a word separator. Using hyphens and spaces will prevent ``ansible-base`` from importing your module." -msgstr "モジュール名は、単語の区切り文字として、ハイフンやスペースの代わりにアンダースコアを使用する必要があります。ハイフンやスペースを使用すると、``ansible-base`` がモジュールをインポートできなくなります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:36 -msgid "Always use the ``hacking/test-module.py`` script when developing modules - it will warn you about common pitfalls." -msgstr "モジュールを開発する際には必ず ``hacking/test-module.py`` スクリプトを使用してください。よくある落とし穴について警告してくれます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:37 -msgid "If you have a local module that returns information specific to your installations, a good name for this module is ``site_info``." -msgstr "インストールに固有の情報を返すローカルモジュールがある場合、このモジュールの適切な名前は ``site_info`` となります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:38 -msgid "Eliminate or minimize dependencies. If your module has dependencies, document them at the top of the module file and raise JSON error messages when dependency import fails." -msgstr "依存関係をなくするか、または最小限に抑えます。モジュールに依存関係がある場合は、モジュールファイルの冒頭で文書化し、依存関係のインポートに失敗した場合は JSON エラーメッセージを発生させます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:39 -msgid "Don't write to files directly; use a temporary file and then use the ``atomic_move`` function from ``ansible.module_utils.basic`` to move the updated temporary file into place. This prevents data corruption and ensures that the correct context for the file is kept." -msgstr "ファイルに直接書き込まないようにします。一時ファイルを使用してから、``ansible.module_utils.basic`` の ``atomic_move`` 関数を使用して、更新された一時ファイルを所定の場所に移動させます。これにより、データの破損を防ぎ、ファイルの正しいコンテキストが保持されるようになります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:40 -msgid "Avoid creating caches. Ansible is designed without a central server or authority, so you cannot guarantee it will not run with different permissions, options or locations. If you need a central authority, have it on top of Ansible (for example, using bastion/cm/ci server or tower); do not try to build it into modules." -msgstr "キャッシュを作成しないでください。Ansible は中央のサーバーや権限を持たないように設計されているため、さまざまなパーミッション、オプション、場所を指定して実行しないことを保証することはできません。中央の権限が必要な場合は、それを Ansible の上に置いてください (例: bastion/cm/ci サーバーまたは Tower を使用)。それをモジュールには組み込まないでください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:41 -msgid "If you package your module(s) in an RPM, install the modules on the control machine in ``/usr/share/ansible``. Packaging modules in RPMs is optional." -msgstr "RPM でモジュールをパッケージ化する場合は、コントロールマシンに ``/usr/share/ansible`` のモジュールをインストールします。RPM でのモジュールのパッケージ化は任意です。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:44 -msgid "Functions and Methods" -msgstr "関数およびメソッド" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:46 -msgid "Each function should be concise and should describe a meaningful amount of work." -msgstr "各関数は簡潔にし、意味のある作業量を記述する必要があります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:47 -msgid "\"Don't repeat yourself\" is generally a good philosophy." -msgstr "「Don't repeat yourself (繰り返さないこと)」は、通常、適している哲学です。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:48 -msgid "Function names should use underscores: ``my_function_name``." -msgstr "関数名はアンダースコアを使用する必要があります (``my_function_name``)。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:49 -msgid "The name of each function should describe what the function does." -msgstr "各関数の名前には、関数の機能を記述する必要があります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:50 -msgid "Each function should have a docstring." -msgstr "各関数にはドキュメント文字列 (docstring) が必要です。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:51 -msgid "If your code is too nested, that's usually a sign the loop body could benefit from being a function. Parts of our existing code are not the best examples of this at times." -msgstr "コードの入れ子を多用しすぎている場合、それは通常、ループ本体が関数であることから利益が得られる可能性のある兆候です。既存のコードの一部は、時としてこのような例としては最適ではありません。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:54 -msgid "Python tips" -msgstr "Python のヒント" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:56 -msgid "Include a ``main`` function that wraps the normal execution." -msgstr "通常の実行をラップする ``main`` 関数を含めます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:57 -msgid "Call your ``main`` function from a conditional so you can import it into unit tests - for example:" -msgstr "条件から ``main`` 機能を呼び出して、ユニットテストにインポートします。以下に例を示します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:67 -msgid "Importing and using shared code" -msgstr "共有コードのインポートおよび使用" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:69 -msgid "Use shared code whenever possible - don't reinvent the wheel. Ansible offers the ``AnsibleModule`` common Python code, plus :ref:`utilities ` for many common use cases and patterns. You can also create documentation fragments for docs that apply to multiple modules." -msgstr "可能な限り共有コードを使用する - wheel を再実装しないでください。Ansible は ``AnsibleModule`` の一般的な Python コードと、多くの一般的なユースケースおよびパターンに使用する :ref:`ユーティリティー ` を提供します。また、複数のモジュールに適用されるドキュメントフラグメントを作成することもできます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:70 -msgid "Import ``ansible.module_utils`` code in the same place as you import other libraries." -msgstr "他のライブラリーをインポートする場所と同じ場所に ``ansible.module_utils`` コードをインポートします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:71 -msgid "Do NOT use wildcards (*) for importing other python modules; instead, list the function(s) you are importing (for example, ``from some.other_python_module.basic import otherFunction``)." -msgstr "他の python モジュールのインポートにはワイルドカード (*) を使用しないでください。代わりに、インポートする関数を一覧表示してください (例: ``some.other_python_module.basic からの otherFunction のインポート``。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:72 -msgid "Import custom packages in ``try``/``except``, capture any import errors, and handle them with ``fail_json()`` in ``main()``. For example:" -msgstr "カスタムパッケージを ``try``/``except`` でインポートし、インポートエラーを捕捉し、``main()`` の ``fail_json()`` で処理します。以下は例となります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:89 -msgid "Then in ``main()``, just after the argspec, do" -msgstr "次に ``main()`` で、argspec の直後に以下を実行します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:98 -msgid "And document the dependency in the ``requirements`` section of your module's :ref:`documentation_block`." -msgstr "また、依存関係をモジュールの :ref:`documentation_block` の ``requirements`` セクションで記述します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:103 -msgid "Handling module failures" -msgstr "モジュール障害の処理" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:105 -msgid "When your module fails, help users understand what went wrong. If you are using the ``AnsibleModule`` common Python code, the ``failed`` element will be included for you automatically when you call ``fail_json``. For polite module failure behavior:" -msgstr "モジュールが失敗すると、ユーザーは問題を理解するのに役立ちます。一般的な Python コード ``AnsibleModule`` を使用している場合、``fail_json`` の呼び出し時に自動的に ``failed`` 要素が含まれます。Polite モジュールの失敗動作には、以下を行います。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:107 -msgid "Include a key of ``failed`` along with a string explanation in ``msg``. If you don't do this, Ansible will use standard return codes: 0=success and non-zero=failure." -msgstr "``msg`` の文字列の説明と共に ``failed`` のキーが含まれるようにします。これを行わないと、Ansible は標準の戻りコード 0=success および non-zero=failure を使用します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:108 -msgid "Don't raise a traceback (stacktrace). Ansible can deal with stacktraces and automatically converts anything unparsable into a failed result, but raising a stacktrace on module failure is not user-friendly." -msgstr "トレースバック (スタックトレース) は発生させません。Ansible はスタックトレースを扱うことができ、解析できないものは自動的に失敗した結果に変換しますが、モジュールの失敗時にスタックトレースを発生させるのはユーザーフレンドリーではありません。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:109 -msgid "Do not use ``sys.exit()``. Use ``fail_json()`` from the module object." -msgstr "``sys.exit()`` は使用しないでください。モジュールオブジェクトの ``fail_json()`` を使用してください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:112 -msgid "Handling exceptions (bugs) gracefully" -msgstr "例外 (バグ) を正常に処理" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:114 -msgid "Validate upfront--fail fast and return useful and clear error messages." -msgstr "前もって検証します。早めに失敗し、有用で明確なエラーメッセージを返します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:115 -msgid "Use defensive programming--use a simple design for your module, handle errors gracefully, and avoid direct stacktraces." -msgstr "防御的なプログラミングを使用します。モジュールにはシンプルなデザインを使用し、エラーを適切に処理し、直接のスタックトレースを回避します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:116 -msgid "Fail predictably--if we must fail, do it in a way that is the most expected. Either mimic the underlying tool or the general way the system works." -msgstr "予測可能な方法で失敗させます。失敗がどうしても避けられない場合は、最も期待される方法で失敗します。基礎となるツール、またはシステムの一般的な動作方法を模倣します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:117 -msgid "Give out a useful message on what you were doing and add exception messages to that." -msgstr "実行内容に関する有用なメッセージを表示して、それに例外メッセージを追加します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:118 -msgid "Avoid catchall exceptions, they are not very useful unless the underlying API gives very good error messages pertaining the attempted action." -msgstr "キャッチオール例外は使用しないでください。基になる API で試行されたアクションに関する非常に優れたエラーメッセージがない限り、これらの例外はほとんど役に立ちません。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:123 -msgid "Creating correct and informative module output" -msgstr "正確で有益なモジュール出力を作成" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:125 -msgid "Modules must output valid JSON only. Follow these guidelines for creating correct, useful module output:" -msgstr "モジュールは有効な JSON のみを出力しなければなりません。正確で有用なモジュール出力を作成するには、以下のガイドラインに従ってください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:127 -msgid "Make your top-level return type a hash (dictionary)." -msgstr "トップレベルの戻り値の型をハッシュ (ディレクトリー) にします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:128 -msgid "Nest complex return values within the top-level hash." -msgstr "複雑な戻り値をトップレベルのハッシュ内に入れ子にします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:129 -msgid "Incorporate any lists or simple scalar values within the top-level return hash." -msgstr "トップレベルの戻り値ハッシュ内にリストや単純なスカラー値を組み込みます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:130 -msgid "Do not send module output to standard error, because the system will merge standard out with standard error and prevent the JSON from parsing." -msgstr "モジュールの出力を標準エラーに送らないでください。システムが標準エラーと標準出力をマージし、JSON の解析を妨げるためです。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:131 -msgid "Capture standard error and return it as a variable in the JSON on standard out. This is how the command module is implemented." -msgstr "標準エラーを取得し、標準出力の JSON で変数として返します。これは、コマンドモジュールの実装方法です。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:132 -msgid "Never do ``print(\"some status message\")`` in a module, because it will not produce valid JSON output." -msgstr "有効な JSON 出力が生成されないため、モジュールで ``print(\"some status message\")`` を実行しないでください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:133 -msgid "Always return useful data, even when there is no change." -msgstr "変更がない場合でも、有用なデータを常に返します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:134 -msgid "Be consistent about returns (some modules are too random), unless it is detrimental to the state/action." -msgstr "状態/アクションに影響を及ばさないために、戻り値は一貫したものにしてください (モジュールによっては非常に乱雑なものもあります)。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:135 -msgid "Make returns reusable--most of the time you don't want to read it, but you do want to process it and re-purpose it." -msgstr "戻り値は再利用可能なものにします。ほとんどの場合は読むことはありませんが、処理して再利用できるものにします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:136 -msgid "Return diff if in diff mode. This is not required for all modules, as it won't make sense for certain ones, but please include it when applicable." -msgstr "diff モードの場合は diff を返します。これは、特定のモジュールでは意味をなさないため、すべてのモジュールに必要なわけではありませんが、該当する場合には使用してください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:137 -msgid "Enable your return values to be serialized as JSON with Python's standard `JSON encoder and decoder `_ library. Basic python types (strings, int, dicts, lists, and so on) are serializable." -msgstr "Python の標準の `JSON エンコーダーおよびデコーダー ` ライブラリーで、戻り値を JSON としてシリアライズできるようにします。基本的な python タイプ (文字列、int、ディクショナリー、リストなど) はシリアライズ可能です。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:138 -msgid "Do not return an object using exit_json(). Instead, convert the fields you need from the object into the fields of a dictionary and return the dictionary." -msgstr "exit_json() を使用してオブジェクトを返さないでください。代わりに、オブジェクトから必要なフィールドをディクショナリーのフィールドに変換して返します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:139 -msgid "Results from many hosts will be aggregated at once, so your module should return only relevant output. Returning the entire contents of a log file is generally bad form." -msgstr "多数のホストからの結果が一度に集約されるため、モジュールは関連する出力だけを返すべきです。ログファイルの内容全体を返すのは、一般的には悪い形式です。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:141 -msgid "If a module returns stderr or otherwise fails to produce valid JSON, the actual output will still be shown in Ansible, but the command will not succeed." -msgstr "モジュールが標準エラー (stderr) を返したり、その他の方法で有効な JSON の生成に失敗した場合でも、実際の出力は Ansible に表示されますが、コマンドは成功しません。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:146 -msgid "Following Ansible conventions" -msgstr "Ansible の規則に準拠" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:148 -msgid "Ansible conventions offer a predictable user interface across all modules, playbooks, and roles. To follow Ansible conventions in your module development:" -msgstr "Ansible の規則は、すべてのモジュール、Playbook、ロールに渡って予測可能なユーザーインターフェースを提供します。モジュール開発において Ansible の規則に従うには、以下を行います。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:150 -msgid "Use consistent names across modules (yes, we have many legacy deviations - don't make the problem worse!)." -msgstr "モジュール間で一貫性のある名前を使用します (レガシーとの相違が多数あるため、問題を悪化させないようにしましょう)。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:151 -msgid "Use consistent options (arguments) within your module(s)." -msgstr "モジュール内で一貫したオプション (引数) を使用します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:152 -msgid "Do not use 'message' or 'syslog_facility' as an option name, because this is used internally by Ansible." -msgstr "これは Ansible によって内部で使用されるため、オプション名には「message」または「syslog_facility」を使用しないでください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:153 -msgid "Normalize options with other modules - if Ansible and the API your module connects to use different names for the same option, add aliases to your options so the user can choose which names to use in tasks and playbooks." -msgstr "他のモジュールでオプションを正規化します。Ansible と、モジュールが接続する API が同じオプションに異なる名前を使用している場合は、オプションにエイリアスを追加して、ユーザーがタスクおよび Playbook で使用する名前を選択できるようにします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:154 -msgid "Return facts from ``*_facts`` modules in the ``ansible_facts`` field of the :ref:`result dictionary` so other modules can access them." -msgstr "他のモジュールがそれらにアクセスできるように、:ref:`結果ディクショナリー` の ``ansible_facts`` フィールドの ``*_facts`` モジュールからファクトを返します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:155 -msgid "Implement ``check_mode`` in all ``*_info`` and ``*_facts`` modules. Playbooks which conditionalize based on fact information will only conditionalize correctly in ``check_mode`` if the facts are returned in ``check_mode``. Usually you can add ``supports_check_mode=True`` when instantiating ``AnsibleModule``." -msgstr "すべての ``*_info`` および ``*_facts`` モジュールに ``check_mode`` を実装します。ファクト情報をもとに条件付けされる Playbook は、ファクトが ``check_mode`` で返される場合にのみ ``check_mode`` で条件化されます。 通常は、``AnsibleModule`` をインスタンス化する時に ``supports_check_mode=True`` を追加することができます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:156 -msgid "Use module-specific environment variables. For example, if you use the helpers in ``module_utils.api`` for basic authentication with ``module_utils.urls.fetch_url()`` and you fall back on environment variables for default values, use a module-specific environment variable like :code:`API__USERNAME` to avoid conflicts between modules." -msgstr "モジュール固有の環境変数を使用します。たとえば、``module_utils.urls.fetch_url()`` での基本的な認証に ``module_utils.api`` のヘルパーを使用し、デフォルト値を環境変数に依存している場合は、モジュール間の競合を回避するために :code:`API__USERNAME` のようなモジュール固有の環境変数を使用します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:157 -msgid "Keep module options simple and focused - if you're loading a lot of choices/states on an existing option, consider adding a new, simple option instead." -msgstr "モジュールのオプションはシンプルで焦点を絞ったものにします。既存のオプションに多くの選択肢や状態を読み込んでいる場合は、代わりに新しいシンプルなオプションを追加することを検討してください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:158 -msgid "Keep options small when possible. Passing a large data structure to an option might save us a few tasks, but it adds a complex requirement that we cannot easily validate before passing on to the module." -msgstr "可能な場合はオプションのサイズを小さくします。大きなデータ構造をオプションに渡すと、いくつかの作業が省けるかもしれませんが、モジュールに渡す前に簡単に検証できない複雑な要件が追加されてしまいます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:159 -msgid "If you want to pass complex data to an option, write an expert module that allows this, along with several smaller modules that provide a more 'atomic' operation against the underlying APIs and services. Complex operations require complex data. Let the user choose whether to reflect that complexity in tasks and plays or in vars files." -msgstr "複雑なデータをオプションに渡したいのであれば、それを可能にするエキスパートモジュールと、基礎となる API やサービスに対してより「アトミックな」操作を提供するいくつかの小さなモジュールを作成します。複雑な操作には複雑なデータが必要です。その複雑さをタスクやプレイに反映させるか、vars ファイルに反映させるかをユーザが選択できるようにします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:160 -msgid "Implement declarative operations (not CRUD) so the user can ignore existing state and focus on final state. For example, use ``started/stopped``, ``present/absent``." -msgstr "ユーザーが既存の状態を無視して最終的な状態に集中できるように、(CRUDではなく) 宣言的な操作を実装します。たとえば、``started/stopped``、``present/absent`` を使用します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:161 -msgid "Strive for a consistent final state (aka idempotency). If running your module twice in a row against the same system would result in two different states, see if you can redesign or rewrite to achieve consistent final state. If you can't, document the behavior and the reasons for it." -msgstr "最終状態が一貫したもの (別名、冪等性) になるようにします。同じシステムに対してモジュールを連続して 2 回実行すると 2 つの異なる状態になってしまう場合は、最終的な状態が一貫しているかどうかを再設計または書き換えてみてください。できない場合は、動作とその理由を記載してください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:162 -msgid "Provide consistent return values within the standard Ansible return structure, even if NA/None are used for keys normally returned under other options." -msgstr "通常は他のオプションで返されるキーに NA/None が使用されている場合でも、標準の Ansible の戻り値構造内で一貫性のある戻り値を提供します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:163 -msgid "Follow additional guidelines that apply to families of modules if applicable. For example, AWS modules should follow the :ref:`Amazon development checklist `." -msgstr "該当する場合は、モジュールのファミリーに適用される追加のガイドラインに従います。たとえば、AWS モジュールは :ref:`Amazon development checklist ` に従う必要があります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:167 -msgid "Module Security" -msgstr "モジュールのセキュリティー" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:169 -msgid "Avoid passing user input from the shell." -msgstr "シェルからユーザー入力を渡さないようにします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:170 -msgid "Always check return codes." -msgstr "常に戻りコードを確認してください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:171 -msgid "You must always use ``module.run_command``, not ``subprocess`` or ``Popen`` or ``os.system``." -msgstr "``subprocess``、``Popen``、または ``os.system`` ではなく、常に ``module.run_command`` を使用する必要があります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:172 -msgid "Avoid using the shell unless absolutely necessary." -msgstr "絶対に必要な場合を除き、シェルは使用しないでください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:173 -msgid "If you must use the shell, you must pass ``use_unsafe_shell=True`` to ``module.run_command``." -msgstr "シェルを使用する必要がある場合は、``use_unsafe_shell=True`` を ``module.run_command`` に渡す必要があります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:174 -msgid "If any variables in your module can come from user input with ``use_unsafe_shell=True``, you must wrap them with ``pipes.quote(x)``." -msgstr "モジュールの変数が ``use_unsafe_shell=True`` を使用してユーザー入力から送られる場合は、``pipes.quote(x)`` でラップする必要があります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:175 -msgid "When fetching URLs, use ``fetch_url`` or ``open_url`` from ``ansible.module_utils.urls``. Do not use ``urllib2``, which does not natively verify TLS certificates and so is insecure for https." -msgstr "URL を取得する際には、``ansible.module_utils.urls`` から ``fetch_url`` または ``open_url`` を使用してください。``urllib2`` を使用しないでください。TLS 証明書をネイティブで検証しないため、https では安全ではありません。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:176 -msgid "Sensitive values marked with ``no_log=True`` will automatically have that value stripped from module return values. If your module could return these sensitive values as part of a dictionary key name, you should call the ``ansible.module_utils.basic.sanitize_keys()`` function to strip the values from the keys. See the ``uri`` module for an example." -msgstr "``no_log=True`` のマークが付いた機密値は自動的に、モジュールの戻り値から取り除かれます。モジュールがこれらの機密値をディクショナリーキー名の一部として返すことができる場合は、``ansible.module_utils.basic.sanitize_keys()`` 関数を呼び出してキーから値を取り除く必要があります。たとえば、``uri`` モジュールを参照してください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:6 -msgid "Contributing your module to an existing Ansible collection" -msgstr "既存の Ansible コレクションへのモジュールの貢献" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:8 -msgid "If you want to contribute a module to an existing collection, you must meet the community's objective and subjective requirements. Please read the details below, and also review our :ref:`tips for module development `." -msgstr "既存のコレクションにモジュールを提供する場合は、コミュニティーの目的の要件と主体的な要件を満たす必要があります。以下の詳細を読み、「:ref:`モジュール開発のヒント `」も確認してください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:10 -msgid "Modules accepted into certain collections are included in every Ansible release on PyPI. However, contributing to one of these collections is not the only way to distribute a module - you can :ref:`create your own collection `, embed modules in roles on Galaxy or simply share copies of your module code for :ref:`local use `." -msgstr "特定のコレクションで許可されるモジュールは、PyPI のすべての Ansible リリースに含まれます。ただし、これらのコレクションのいずれかに貢献することが、モジュールを配布する唯一の方法ではありません。:ref:`独自のコレクションの作成 ` は、Galaxy のロールにモジュールコードのコピーを埋め込んだり、:ref:`ローカルでの使用 ` 用にモジュールコードのコピーを共有することもできます。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:13 -msgid "Contributing modules: objective requirements" -msgstr "モジュールの貢献: 目的要件" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:15 -msgid "To contribute a module to most Ansible collections, you must:" -msgstr "モジュールをほとんどの Ansible コレクションに提供するには、以下を行う必要があります。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:17 -msgid "write your module in either Python or Powershell for Windows" -msgstr "Windows 用の Python または Powershell のいずれかでモジュールを書き込みます。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:18 -msgid "use the ``AnsibleModule`` common code" -msgstr "``AnsibleModule`` 共通コードを使用します。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:19 -msgid "support Python 2.6 and Python 3.5 - if your module cannot support Python 2.6, explain the required minimum Python version and rationale in the requirements section in ``DOCUMENTATION``" -msgstr "Python 2.6 および Python 3.5 をサポートします。モジュールが Python 2.6 をサポートできない場合は、``DOCUMENTATION`` の要件セクションで、最低限必要な Python バージョンと根拠を説明します。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:20 -msgid "use proper :ref:`Python 3 syntax `" -msgstr "適切な :ref:`Python 3 構文 ` を使用します。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:21 -msgid "follow `PEP 8 `_ Python style conventions - see :ref:`testing_pep8` for more information" -msgstr "`PEP 8 `_ Python スタイルの規則に従います。詳細は「:ref:`testing_pep8`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:22 -msgid "license your module under the GPL license (GPLv3 or later)" -msgstr "GPL ライセンス (GPLv3 以降) でモジュールにライセンスを付与します。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:23 -msgid "understand the :ref:`license agreement `, which applies to all contributions" -msgstr "すべての貢献に適用される :ref:`ライセンス合意 ` を理解します。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:24 -msgid "conform to Ansible's :ref:`formatting and documentation ` standards" -msgstr "Ansible の :ref:`formatting and documentation ` 標準規格に準拠しています。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:25 -msgid "include comprehensive :ref:`tests ` for your module" -msgstr "モジュールに包括的な :ref:`tests ` を含めます。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:26 -msgid "minimize module dependencies" -msgstr "モジュール依存関係を最小限に抑えます。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:27 -msgid "support :ref:`check_mode ` if possible" -msgstr "可能な場合は :ref:`check_mode ` をサポートします。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:28 -msgid "ensure your code is readable" -msgstr "コードが読み取り可能であることを確認します。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:29 -msgid "if a module is named ``_facts``, it should be because its main purpose is returning ``ansible_facts``. Do not name modules that do not do this with ``_facts``. Only use ``ansible_facts`` for information that is specific to the host machine, for example network interfaces and their configuration, which operating system and which programs are installed." -msgstr "モジュールの名前が ``_facts`` なのは、``ansible_facts`` を返すことが主な目的だからです。これは、``_facts`` でこれを行わないモジュールに名前を付けないでください。ネットワークインターフェースやその設定や、オペレーティングシステムやインストールされているプログラムなど、ホストマシンに固有の情報には ``ansible_facts`` のみを使用してください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:30 -msgid "Modules that query/return general information (and not ``ansible_facts``) should be named ``_info``. General information is non-host specific information, for example information on online/cloud services (you can access different accounts for the same online service from the same host), or information on VMs and containers accessible from the machine." -msgstr "一般情報をクエリー/返送するモジュールは (``ansible_facts`` ではなく) ``_info`` という名前にする必要があります。一般情報とは、ホスト固有ではない情報、たとえば、オンライン/クラウドサービスに関する情報 (同じホストから同じオンラインサービスの異なるアカウントにアクセスできます)、または、マシンからアクセス可能な仮想マシンおよびコンテナーに関する情報になります。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:32 -msgid "Additional requirements may apply for certain collections. Review the individual collection repositories for more information." -msgstr "追加の要件は、特定のコレクションに適用される可能性があります。詳細は、個別のコレクションリポジトリーを参照してください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:34 -msgid "Please make sure your module meets these requirements before you submit your PR/proposal. If you have questions, reach out via `Ansible's IRC chat channel `_ or the `Ansible development mailing list `_." -msgstr "PR/提案を送信する前に、お使いのモジュールがこれらの要件を満たしていることを確認してください。ご質問がある場合は、`Ansible の IRC チャットチャンネル `_ または `Ansible 開発メーリングリスト `_ までお問い合わせください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:37 -msgid "Contributing to Ansible: subjective requirements" -msgstr "Ansibleへの貢献: 主観的な要件" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:39 -msgid "If your module meets these objective requirements, collection maintainers will review your code to see if they think it's clear, concise, secure, and maintainable. They will consider whether your module provides a good user experience, helpful error messages, reasonable defaults, and more. This process is subjective, with no exact standards for acceptance. For the best chance of getting your module accepted, follow our :ref:`tips for module development `." -msgstr "モジュールがこれらの目的の要件を満たす場合は、コレクションのメンテナーが、明確、簡潔、安全であり、維持が可能であると考えるコードを確認します。モジュールが優れたユーザーエクスペリエンスを提供し、有用なエラーメッセージ、有益なデフォルトなどを提供するかどうかを考慮します。このプロセスは主観的で、正確な標準はありません。モジュールが受け入れられる可能性を最大限に高めるには、「:ref:`モジュール開発のヒント `」に従ってください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:42 -msgid "Other checklists" -msgstr "その他のチェックリスト" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:44 -msgid ":ref:`Tips for module development `." -msgstr ":ref:`モジュール開発のヒント `" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:45 -msgid ":ref:`Amazon development checklist `." -msgstr ":ref:`Amazon 開発チェックリスト `" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:46 -msgid ":ref:`Windows development checklist `." -msgstr ":ref:`Windows 開発チェックリスト `" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:6 -msgid "Module format and documentation" -msgstr "モジュールの形式およびドキュメント" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:8 -msgid "If you want to contribute your module to most Ansible collections, you must write your module in Python and follow the standard format described below. (Unless you're writing a Windows module, in which case the :ref:`Windows guidelines ` apply.) In addition to following this format, you should review our :ref:`submission checklist `, :ref:`programming tips `, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility `, as well as information about :ref:`testing ` before you open a pull request." -msgstr "モジュールをほとんどの Ansible コレクションに貢献する場合は、Python でモジュールを作成して、その標準形式に従う必要があります。(Windows モジュールを作成したことがない場合。この場合は、:ref:`Windows ガイドライン ` が適用されます)。この形式に従うことに加え、プル要求を作成する前に、:ref:`提出のチェックリスト `、:ref:`プログラムのヒント `、:ref:`Python 2 および Python 3 互換性の維持のストラテジー ` と、:ref:`testing ` に関する情報をお読みください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:10 -msgid "Every Ansible module written in Python must begin with seven standard sections in a particular order, followed by the code. The sections in order are:" -msgstr "Python で書かれたすべての Ansible モジュールは、特定の順序で 7 つの標準セクションから始まり、その後にコードが続きます。セクションの順番は以下のとおりです。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:16 -msgid "Why don't the imports go first?" -msgstr "最初にインポートが行われないのはなぜですか。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:18 -msgid "Keen Python programmers may notice that contrary to PEP 8's advice we don't put ``imports`` at the top of the file. This is because the ``DOCUMENTATION`` through ``RETURN`` sections are not used by the module code itself; they are essentially extra docstrings for the file. The imports are placed after these special variables for the same reason as PEP 8 puts the imports after the introductory comments and docstrings. This keeps the active parts of the code together and the pieces which are purely informational apart. The decision to exclude E402 is based on readability (which is what PEP 8 is about). Documentation strings in a module are much more similar to module level docstrings, than code, and are never utilized by the module itself. Placing the imports below this documentation and closer to the code, consolidates and groups all related code in a congruent manner to improve readability, debugging and understanding." -msgstr "熱心な Python プログラマーは、PEP 8 のアドバイスに反して、ファイルの上部に ``imports`` を置いていないことに気づくかもしれません。これは、``RETURN`` までの ``DOCUMENTATION`` セクションはモジュールコード自体で使用されておらず、基本的にファイルに追加のドキュメント文字列を使用するためです。インポートは、PEP 8 と同じ理由でこれらの特別な変数の後に置かれ、入門のコメントとドキュメント文字列の後にインポートを追加します。これにより、コードの活動的な部分が一緒になり、純粋に情報を提供する部分が分離されます。E402 を除外する意思決定は (PEP 8 の目的である) 可読性に基づいています。モジュール内のドキュメント文字列は、コードよりも、モジュールレベルのドキュメント文字列によく似ており、モジュール自体が利用することはありません。インポートを、このドキュメントの下の、よりコードに近いところに置くことで、関連するすべてのコードを統合してグループ化し、可読性、デバッグ、理解を向上させます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:20 -msgid "**Copy old modules with care!**" -msgstr "**古いモジュールは注意してコピーしてください。**" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:22 -msgid "Some older Ansible modules have ``imports`` at the bottom of the file, ``Copyright`` notices with the full GPL prefix, and/or ``DOCUMENTATION`` fields in the wrong order. These are legacy files that need updating - do not copy them into new modules. Over time we are updating and correcting older modules. Please follow the guidelines on this page!" -msgstr "一部の古い Ansible モジュールでは、ファイルの下部に ``imports`` があるため、``Copyright`` は完全な GPL プレフィックス、または ``DOCUMENTATION`` フィールドを間違った順序で持つことに注意してください。これらは更新が必要なレガシーファイルです。新しいモジュールにコピーしないでくださし。時間の経過とともに、古いモジュールを更新および修正しています。このページにはガイドラインに従うようにしてください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:27 -msgid "Python shebang & UTF-8 coding" -msgstr "Python シバンと UTF-8 コーディング" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:29 -msgid "Begin your Ansible module with ``#!/usr/bin/python`` - this \"shebang\" allows ``ansible_python_interpreter`` to work. Follow the shebang immediately with ``# -*- coding: utf-8 -*-`` to clarify that the file is UTF-8 encoded." -msgstr "``#!/usr/bin/python`` で Ansible モジュールを開始します (この「シバン」では ``ansible_python_interpreter`` が機能します)。``# -*- coding: utf-8 -*-`` ファイルがUTF-8でエンコードされていることを明確にするために、シバンの直後に ``# -*- coding: utf-8 -*-``を使用します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:34 -msgid "Copyright and license" -msgstr "著作権およびライセンス" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:36 -msgid "After the shebang and UTF-8 coding, add a `copyright line `_ with the original copyright holder and a license declaration. The license declaration should be ONLY one line, not the full GPL prefix.:" -msgstr "シバンおよび UTF-8 コーディングの後には、元の著作権所有者およびライセンス宣言を含む `copyright line `_ があるはずです。ライセンス宣言は、完全な GPL プレフィックスではなく、1 行のみにする必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:46 -msgid "Major additions to the module (for instance, rewrites) may add additional copyright lines. Any legal review will include the source control history, so an exhaustive copyright header is not necessary. Please do not edit the existing copyright year. This simplifies project administration and is unlikely to cause any interesting legal issues. When adding a second copyright line for a significant feature or rewrite, add the newer line above the older one:" -msgstr "モジュールへの主要な追加 (たとえば、書き換え) は、により、著作権行が追加される場合があります。法的な審査にはソース管理履歴が含まれるため、網羅的な著作権ヘッダーは必要ありません。既存の著作権年は編集しないでください。これは、プロジェクトの管理を単純化するものであり、興味深い法的問題を引き起こす可能性はほとんどありません。重要な機能や書き換えのために 2 行目の著作権行を追加する場合は、古い行の上に新しい行を追加します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:62 -msgid "ANSIBLE_METADATA block" -msgstr "ansible_METADATA ブロック" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:64 -msgid "Since we moved to collections we have deprecated the METADATA functionality, it is no longer required for modules, but it will not break anything if present." -msgstr "コレクションに移行しても METADATA 機能は非推奨になり、モジュールには必要なくなりましたが、存在しても何も破損しません。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:70 -msgid "DOCUMENTATION block" -msgstr "DOCUMENTATION ブロック" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:72 -msgid "After the shebang, the UTF-8 coding, the copyright line, and the license section comes the ``DOCUMENTATION`` block. Ansible's online module documentation is generated from the ``DOCUMENTATION`` blocks in each module's source code. The ``DOCUMENTATION`` block must be valid YAML. You may find it easier to start writing your ``DOCUMENTATION`` string in an :ref:`editor with YAML syntax highlighting ` before you include it in your Python file. You can start by copying our `example documentation string `_ into your module file and modifying it. If you run into syntax issues in your YAML, you can validate it on the `YAML Lint `_ website." -msgstr "shebang、UTF-8 コーディング、著作権行、ライセンスセクションの後には、``DOCUMENTATION`` ブロックがあります。Ansible のオンラインモジュールドキュメントは、各モジュールのソースコード内の ``DOCUMENTATION`` ブロックから生成されます。``DOCUMENTATION`` ブロックは有効な YAML でなければなりません。Python ファイルに含める前に、``DOCUMENTATION`` の文字列を :ref:`YAML 構文の強調表示を使用したエディター ` に書き始めた方が簡単だと思うかもしれません。私たちの `例のドキュメントの文字列 `_ をあなたのモジュールファイルにコピーして、それを修正することから始めることができます。もし YAML の構文に問題がある場合は、`YAML Lint `_ の Web サイトで検証することができます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:80 -msgid "Module documentation should briefly and accurately define what each module and option does, and how it works with others in the underlying system. Documentation should be written for broad audience--readable both by experts and non-experts." -msgstr "モジュールのドキュメントでは、各モジュールとオプションの動作について簡単かつ正確に定義し、基礎となるシステムで他のモジュールとどのように連携するかを説明します。ドキュメントは、専門家と非専門家の両方が読むことができるように、幅広い読者に向けて作成する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:75 -msgid "Descriptions should always start with a capital letter and end with a full stop. Consistency always helps." -msgstr "説明は常に大文字で始め、完全に終了する必要があります。一貫性は常に役立ちます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:76 -msgid "Verify that arguments in doc and module spec dict are identical." -msgstr "ドキュメントの引数と、モジュール仕様のディクショナリーが同じであることを確認します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:77 -msgid "For password / secret arguments ``no_log=True`` should be set." -msgstr "パスワード/シークレット引数 ``no_log=True`` を設定する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:78 -msgid "For arguments that seem to contain sensitive information but **do not** contain secrets, such as \"password_length\", set ``no_log=False`` to disable the warning message." -msgstr "機密情報が含まれているように見えても「password_length」などのシークレットが **含まれていない** ように表示される引数には、``no_log=False`` を設定して警告メッセージを無効にします。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:79 -#: ../../rst/dev_guide/developing_modules_documenting.rst:147 -msgid "If an option is only sometimes required, describe the conditions. For example, \"Required when I(state=present).\"" -msgstr "オプションのみが必要な場合は、条件を記述してください。たとえば、「Required when I(state=present)」です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:80 -msgid "If your module allows ``check_mode``, reflect this fact in the documentation." -msgstr "モジュールで ``check_mode`` が許可されている場合は、これをドキュメントに反映させます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:82 -msgid "To create clear, concise, consistent, and useful documentation, follow the :ref:`style guide `." -msgstr "明確かつ簡潔で一貫性があり、便利なドキュメントは :ref:`スタイルガイド ` に従います。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:84 -msgid "Each documentation field is described below. Before committing your module documentation, please test it at the command line and as HTML:" -msgstr "各ドキュメントフィールドの説明は次のとおりです。モジュールのドキュメントをコミットする前に、コマンドラインおよび HTML でテストしてください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:86 -msgid "As long as your module file is :ref:`available locally `, you can use ``ansible-doc -t module my_module_name`` to view your module documentation at the command line. Any parsing errors will be obvious - you can view details by adding ``-vvv`` to the command." -msgstr "モジュールファイルが :ref:`ローカルで利用可能 ` な場合に限り、``ansible-doc -t module my_module_name`` を使用して、コマンドラインでモジュールのドキュメントを表示します。構文解析エラーは明確になります。コマンドに ``-vvv`` を追加すると、詳細を表示できます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:87 -msgid "You should also :ref:`test the HTML output ` of your module documentation." -msgstr "モジュールのドキュメントにおける :ref:`HTML 出力のテスト ` も必要です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:90 -msgid "Documentation fields" -msgstr "ドキュメントフィールド" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:92 -msgid "All fields in the ``DOCUMENTATION`` block are lower-case. All fields are required unless specified otherwise:" -msgstr "``DOCUMENTATION`` ブロックのフィールドはすべて小文字になります。特に指定がない場合は、すべてのフィールドが必要になります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:96 -msgid "The name of the module." -msgstr "モジュールの名前。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:97 -msgid "Must be the same as the filename, without the ``.py`` extension." -msgstr "ファイル名と同じ (``.py`` 拡張子なし) である必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "short_description" -msgstr "short_description" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:101 -msgid "A short description which is displayed on the :ref:`list_of_collections` page and ``ansible-doc -l``." -msgstr ":ref:`list_of_collections` ページと ``ansible-doc -l`` に表示される簡単な説明です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:102 -msgid "The ``short_description`` is displayed by ``ansible-doc -l`` without any category grouping, so it needs enough detail to explain the module's purpose without the context of the directory structure in which it lives." -msgstr "``short_description`` は、カテゴリーをグループ化せずに、``ansible-doc -l`` によって表示されます。そのため、モジュールが存在するディレクトリー構造のコンテキストなしでモジュールの目的を説明するのに十分な詳細が必要です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:104 -msgid "Unlike ``description:``, ``short_description`` should not have a trailing period/full stop." -msgstr "``description:`` とは異なり、``short_description`` のピリオド/完全な停止は設定しないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "description" -msgstr "説明" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:108 -msgid "A detailed description (generally two or more sentences)." -msgstr "詳細な説明 (通常は 2 文以上)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:109 -msgid "Must be written in full sentences, in other words, with capital letters and periods/full stops." -msgstr "文章の形、つまり冒頭の大文字やピリオドなどを使用して記述する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:110 -msgid "Shouldn't mention the module name." -msgstr "モジュール名について言及すべきではありません。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:111 -msgid "Make use of multiple entries rather than using one long paragraph." -msgstr "1 つの長い段落にせず、複数の文章に分けます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:112 -msgid "Don't quote complete values unless it is required by YAML." -msgstr "YAML で必要な場合を除き、完全な値を引用符で囲まないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "version_added" -msgstr "version_added" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:116 -msgid "The version of Ansible when the module was added." -msgstr "モジュールが追加された Ansible のバージョン。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:117 -msgid "This is a string, and not a float, for example, ``version_added: '2.1'``." -msgstr "これはフローティングではなく文字列です (例: ``version_added: '2.1'``)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:118 -msgid "In collections, this must be the collection version the module was added to, not the Ansible version. For example, ``version_added: 1.0.0``." -msgstr "コレクションでは、これは Ansible バージョンではなく、モジュールが追加されたコレクションバージョンでなければなりません (例: ``version_added: 1.0.0``)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "author" -msgstr "作成者" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:122 -msgid "Name of the module author in the form ``First Last (@GitHubID)``." -msgstr "``First Last (@GitHubID)`` 形式のモジュール作成者の名前。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:123 -msgid "Use a multi-line list if there is more than one author." -msgstr "作成者が複数になる場合は、複数行のリストを使用します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:124 -msgid "Don't use quotes as it should not be required by YAML." -msgstr "YAML では必要ないため、引用符は使用しないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "deprecated" -msgstr "非推奨" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:128 -msgid "Marks modules that will be removed in future releases. See also :ref:`module_lifecycle`." -msgstr "将来のリリースで削除されるモジュールにマークを付けします。「:ref:`module_lifecycle`」も併せて参照してください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "options" -msgstr "options" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:132 -msgid "Options are often called `parameters` or `arguments`. Because the documentation field is called `options`, we will use that term." -msgstr "オプションは、多くの場合、`パラメーター` または `引数` と呼ばれます。ドキュメントフィールドは `オプション` を呼ばれるため、ここではその用語を使用します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:133 -msgid "If the module has no options (for example, it's a ``_facts`` module), all you need is one line: ``options: {}``." -msgstr "モジュールにオプションがない (例: ``_facts`` モジュール) 場合、必要なのは 1 行 (``options: {}``) だけです。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:134 -msgid "If your module has options (in other words, accepts arguments), each option should be documented thoroughly. For each module option, include:" -msgstr "モジュールにオプションがある (つまり引数を受け入れる) 場合、各オプションは詳細に文書化される必要があります。各モジュールオプションについて、以下を記載します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "option-name" -msgstr "option-name" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:138 -msgid "Declarative operation (not CRUD), to focus on the final state, for example `online:`, rather than `is_online:`." -msgstr "(CRUD ではなく) 宣言操作は、「`is_online:`」ではなく、「`online:`」などの最終状態に焦点をあてます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:139 -msgid "The name of the option should be consistent with the rest of the module, as well as other modules in the same category." -msgstr "オプションの名前は、そのモジュールの残りの部分、および同じカテゴリーの他のモジュールと一貫性を持たせる必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:140 -msgid "When in doubt, look for other modules to find option names that are used for the same purpose, we like to offer consistency to our users." -msgstr "不明な場合は、他のモジュールを探して、同じ目的で使用されているオプション名を見つけてください。ユーザーに一貫性を提供できるようにしています。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:144 -msgid "Detailed explanation of what this option does. It should be written in full sentences." -msgstr "* このオプションの機能の詳細な説明。これは、完全な文章で記述する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:145 -msgid "The first entry is a description of the option itself; subsequent entries detail its use, dependencies, or format of possible values." -msgstr "最初のエントリーは、オプションそのものの説明です。後続のエントリーは、その使用、依存関係、または使用できる値の形式の詳細を説明します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:146 -msgid "Should not list the possible values (that's what ``choices:`` is for, though it should explain what the values do if they aren't obvious)." -msgstr "可能な値を列挙しないでください (``choices:`` はそのためにあります。値が明らかでない場合は、その値が何を示すのかを説明してください)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:148 -msgid "Mutually exclusive options must be documented as the final sentence on each of the options." -msgstr "相互に排他的なオプションは、各オプションの最後の文で文書化する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:152 -msgid "Only needed if ``true``." -msgstr "``true`` の場合にのみ必要です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:153 -msgid "If missing, we assume the option is not required." -msgstr "見つからない場合は、オプションが不要であると仮定します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "default" -msgstr "default" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:157 -msgid "If ``required`` is false/missing, ``default`` may be specified (assumed 'null' if missing)." -msgstr "``required`` が false もしくは指定されていない場合は、``default`` を指定できます (見つからない場合は「null」と見なされます)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:158 -msgid "Ensure that the default value in the docs matches the default value in the code." -msgstr "ドキュメントのデフォルト値が、コードのデフォルト値と一致していることを確認してください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:159 -msgid "The default field must not be listed as part of the description, unless it requires additional information or conditions." -msgstr "追加の情報や条件が必要な場合を除き、デフォルトのフィールドは、説明の一部として記載しないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:160 -msgid "If the option is a boolean value, you can use any of the boolean values recognized by Ansible: (such as true/false or yes/no). Choose the one that reads better in the context of the option." -msgstr "オプションがブール値の場合は、Ansible が認識する任意のブール値 (true/false、yes/no など) を使用できます。オプションのコンテキストで読み取りが適切であればこれを選択します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "choices" -msgstr "choices" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:165 -msgid "List of option values." -msgstr "* オプション値のリスト。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:166 -msgid "Should be absent if empty." -msgstr "空欄の場合は指定なしになります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "type" -msgstr "タイプ" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:170 -msgid "Specifies the data type that option accepts, must match the ``argspec``." -msgstr "オプションで使用できるデータ型を指定します。``argspec`` と一致させる必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:171 -msgid "If an argument is ``type='bool'``, this field should be set to ``type: bool`` and no ``choices`` should be specified." -msgstr "引数が ``type='bool'`` の場合、このフィールドは ``type: bool`` に設定されます。``choices`` は指定しないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:172 -msgid "If an argument is ``type='list'``, ``elements`` should be specified." -msgstr "引数が ``type='list'`` の場合は、``elements`` を指定する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "elements" -msgstr "elements" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:176 -msgid "Specifies the data type for list elements in case ``type='list'``." -msgstr "``type='list'`` の場合に、リスト要素のデータ型を指定します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "aliases" -msgstr "aliases" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:179 -msgid "List of optional name aliases." -msgstr "オプションの名前エイリアスのリスト。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:180 -msgid "Generally not needed." -msgstr "* 一般的には必要ありません。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:184 -msgid "Only needed if this option was extended after initial Ansible release, in other words, this is greater than the top level `version_added` field." -msgstr "このオプションが Ansible の初回リリース後に拡張されている場合にのみ必要です。つまり、これはトップレベルの `version_added` フィールドよりも大きくなります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:185 -msgid "This is a string, and not a float, for example, ``version_added: '2.3'``." -msgstr "これは浮動小数点ではなく文字列です (例: ``version_added: '2.3'``)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:186 -msgid "In collections, this must be the collection version the option was added to, not the Ansible version. For example, ``version_added: 1.0.0``." -msgstr "コレクションでは、これは Ansible バージョンではなく、オプションが追加されたコレクションバージョンでなければなりません (例: ``version_added: 1.0.0``)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "suboptions" -msgstr "suboptions" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:190 -msgid "If this option takes a dict or list of dicts, you can define the structure here." -msgstr "このオプションがディクショナリーまたはディクショナリーの一覧を取る場合は、ここで構造を定義できます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:191 -msgid "See :ref:`ansible_collections.azure.azcollection.azure_rm_securitygroup_module`, :ref:`ansible_collections.azure.azcollection.azure_rm_azurefirewall_module`, and :ref:`ansible_collections.openstack.cloud.baremetal_node_action_module` for examples." -msgstr "例は、「:ref:`ansible_collections.azure.azcollection.azure_rm_securitygroup_module`」、「:ref:`ansible_collections.azure.azcollection.azure_rm_azurefirewall_module`」、および「:ref:`ansible_collections.openstack.cloud.baremetal_node_action_module`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "requirements" -msgstr "requirements" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:195 -msgid "List of requirements (if applicable)." -msgstr "要件のリスト (該当する場合)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:196 -msgid "Include minimum versions." -msgstr "最小バージョンを指定します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "seealso" -msgstr "seealso" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:200 -msgid "A list of references to other modules, documentation or Internet resources" -msgstr "その他のモジュール、ドキュメント、またはインターネットリソースへの参照の一覧。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:201 -msgid "In Ansible 2.10 and later, references to modules must use the FQCN or ``ansible.builtin`` for modules in ``ansible-base``." -msgstr "Ansible 2.10 以降では、モジュールへの参照が ``ansible-base`` のモジュールに FQCN または ``ansible.builtin`` を使用する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:202 -msgid "A reference can be one of the following formats:" -msgstr "参照には、以下の形式のいずれかを使用できます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "notes" -msgstr "備考" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:227 -msgid "Details of any important information that doesn't fit in one of the above sections." -msgstr "上記のセクションのいずれかに該当しない重要な情報の詳細。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:228 -msgid "For example, whether ``check_mode`` is or is not supported." -msgstr "たとえば、``check_mode`` がサポートされるかどうかなどです。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:232 -msgid "Linking and other format macros within module documentation" -msgstr "モジュールドキュメント内のリンクおよびその他の形式マクロ" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:234 -msgid "You can link from your module documentation to other module docs, other resources on docs.ansible.com, and resources elsewhere on the internet with the help of some pre-defined macros. The correct formats for these macros are:" -msgstr "モジュールドキュメントから他のモジュールドキュメント、docs.ansible.com の他のリソース、一部の事前設定マクロでインターネット上の他のリソースにリンクできます。これらのマクロの正しい形式は次のとおりです。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:236 -msgid "``L()`` for links with a heading. For example: ``See L(Ansible Tower,https://www.ansible.com/products/tower).`` As of Ansible 2.10, do not use ``L()`` for relative links between Ansible documentation and collection documentation." -msgstr "``L()`` 見出しへのリンク。たとえば、``See L(Ansible Tower,https://www.ansible.com/products/tower).`` となります。Ansible 2.10 以降、Ansible ドキュメントとコレクションのドキュメントの相対リンクには ``L()`` を使用しないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:237 -msgid "``U()`` for URLs. For example: ``See U(https://www.ansible.com/products/tower) for an overview.``" -msgstr "URL の場合は ``U()``。たとえば、``See U(https://www.ansible.com/products/tower) for an overview.`` となります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:238 -msgid "``R()`` for cross-references with a heading (added in Ansible 2.10). For example: ``See R(Cisco IOS Platform Guide,ios_platform_options)``. Use the RST anchor for the cross-reference. See :ref:`adding_anchors_rst` for details." -msgstr "(Ansible 2.10 に含まれる) 見出しと相互参照用 ``R()`` (例: ``See R(Cisco IOS Platform Guide,ios_platform_options)``)。クロス参照に RST アンカーを使用します。詳細は、:ref:`adding_anchors_rst` を参照してください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:239 -msgid "``M()`` for module names. For example: ``See also M(ansible.builtin.yum) or M(community.general.apt_rpm)``." -msgstr "``M()`` モジュール名。たとえば ``See also M(ansible.builtin.yum) or M(community.general.apt_rpm)`` になります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:241 -msgid "There are also some macros which do not create links but we use them to display certain types of content in a uniform way:" -msgstr "リンクを作成しないものの、そのマクロを使用して、特定のタイプのコンテンツを統一して表示します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:244 -msgid "``I()`` for option names. For example: ``Required if I(state=present).`` This is italicized in the documentation." -msgstr "オプション名の場合は ``I()``。たとえば ``Required if I(state=present).`` です。これは、ドキュメントではイタリック体で示されています。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:246 -msgid "``C()`` for files, option values, and inline code. For example: ``If not set the environment variable C(ACME_PASSWORD) will be used.`` or ``Use C(var | foo.bar.my_filter) to transform C(var) into the required format.`` This displays with a mono-space font in the documentation." -msgstr "ファイル、オプション値、およびインラインコードの場合は ``C()`` (例 ``If not set the environment variable C(ACME_PASSWORD) will be used.`` または ``Use C(var | foo.bar.my_filter) to transform C(var) into the required format.``)。これは、ドキュメントでは Monospace フォントと表示されます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:247 -msgid "``B()`` currently has no standardized usage. It is displayed in boldface in the documentation." -msgstr "``B()`` は、現在、標準化された使用はありません。このドキュメントには太字が表示されます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:248 -msgid "``HORIZONTALLINE`` is used sparingly as a separator in long descriptions. It becomes a horizontal rule (the ``
    `` html tag) in the documentation." -msgstr "``HORIZONTALLINE`` は、長い説明では、区切り文字として慎重に使用されており、ドキュメント内の水平ルール (``
    `` html タグ) になります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:252 -msgid "For links between modules and documentation within a collection, you can use any of the options above. For links outside of your collection, use ``R()`` if available. Otherwise, use ``U()`` or ``L()`` with full URLs (not relative links). For modules, use ``M()`` with the FQCN or ``ansible.builtin`` as shown in the example. If you are creating your own documentation site, you will need to use the `intersphinx extension `_ to convert ``R()`` and ``M()`` to the correct links." -msgstr "コレクション内のモジュールとドキュメント間のリンクについては、上記のオプションのいずれかを使用することができます。コレクション外のリンクについては、利用可能な場合は ``R()`` を使用します。利用できない場合は、(相対リンクではなく) 完全な URL で ``U()`` または ``L()`` を使用します。モジュールの場合は、例のように、FQCN または ``ansible.builtin`` で ``M()`` を使用します。独自のドキュメントサイトを作成する場合は、`intersphinx extension `_ を使用して ``R()`` および ``M()`` を正しいリンクに変換する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:256 -msgid "To refer to a group of modules in a collection, use ``R()``. When a collection is not the right granularity, use ``C(..)``:" -msgstr "コレクション内のモジュールのグループを参照するには、``R()`` を使用します。コレクションが適切な粒度ではない場合は、``C(..)`` を使用します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:258 -msgid "``Refer to the R(community.kubernetes collection, plugins_in_community.kubernetes) for information on managing kubernetes clusters.``" -msgstr "``Refer to the R(community.kubernetes collection, plugins_in_community.kubernetes) for information on managing kubernetes clusters.``" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:259 -msgid "``The C(win_*) modules (spread across several collections) allow you to manage various aspects of windows hosts.``" -msgstr "``The C(win_*) modules (spread across several collections) allow you to manage various aspects of windows hosts.``" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:264 -msgid "Because it stands out better, use ``seealso`` for general references over the use of notes or adding links to the description." -msgstr "- ``seealso`` の方が目立つため、一般的な参照にはノートの使用や説明へのリンクよりも、``seealso`` を使用することが推奨されます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:269 -msgid "Documentation fragments" -msgstr "ドキュメントフラグメント" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:271 -msgid "If you are writing multiple related modules, they may share common documentation, such as authentication details, file mode settings, ``notes:`` or ``seealso:`` entries. Rather than duplicate that information in each module's ``DOCUMENTATION`` block, you can save it once as a doc_fragment plugin and use it in each module's documentation. In Ansible, shared documentation fragments are contained in a ``ModuleDocFragment`` class in `lib/ansible/plugins/doc_fragments/ `_ or the equivalent directory in a collection. To include a documentation fragment, add ``extends_documentation_fragment: FRAGMENT_NAME`` in your module documentation. Use the fully qualified collection name for the FRAGMENT_NAME (for example, ``community.kubernetes.k8s_auth_options``)." -msgstr "複数の関連モジュールを記述している場合は、認証の詳細やファイルモードの設定、``notes:`` や``seealso:`` のエントリーなど、共通のドキュメントを共有していることがあります。そのような情報を各モジュールの ``DOCUMENTATION`` ブロックに複製するのではなく、doc_fragment プラグインとして一度保存し、各モジュールのドキュメントで使用することができます。Ansibl eでは、共有ドキュメントフラグメントは、`lib/ansible/plugins/doc_fragments/ `_ の ``ModuleDocFragment`` クラス、またはコレクションの同等のディレクトリーに含まれています。ドキュメントフラグメントを含めるには、モジュールのドキュメントに ``extends_documentation_fragment: FRAGMENT_NAME`` を追加します。FRAGMENT_NAME には、完全修飾されたコレクション名を使用します (例： ``community.kubernetes.k8s_auth_options``)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:273 -msgid "Modules should only use items from a doc fragment if the module will implement all of the interface documented there in a manner that behaves the same as the existing modules which import that fragment. The goal is that items imported from the doc fragment will behave identically when used in another module that imports the doc fragment." -msgstr "モジュールがドキュメントフラグメントのアイテムを使用するのは、そのフラグメントをインポートする既存のモジュールと動作する方法で、ドキュメント化されたすべてのインターフェースをモジュールが実装する場合のみです。目標は、ドキュメントフラグメントからインポートされたアイテムが、ドキュメントフラグメントをインポートする別のモジュールで使用された場合と同じように動作することです。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:275 -msgid "By default, only the ``DOCUMENTATION`` property from a doc fragment is inserted into the module documentation. It is possible to define additional properties in the doc fragment in order to import only certain parts of a doc fragment or mix and match as appropriate. If a property is defined in both the doc fragment and the module, the module value overrides the doc fragment." -msgstr "デフォルトでは、doc フラグメントの ``DOCUMENTATION`` プロパティーがモジュールのドキュメントに挿入されます。doc フラグメントの特定の部分のみをインポートするため、または必要に応じて組み合わせて一致させるために、doc フラグメントに追加のプロパティーを定義することができます。プロパティーが doc フラグメントとモジュールの両方で定義されている場合、モジュール値は doc フラグメントを上書きします。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:277 -msgid "Here is an example doc fragment named ``example_fragment.py``:" -msgstr "以下は、``example_fragment.py`` という名前の doc フラグメントの例です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:295 -msgid "To insert the contents of ``OTHER`` in a module:" -msgstr "``OTHER`` の内容をモジュールに挿入するには、以下を行います。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:301 -msgid "Or use both :" -msgstr "または、以下の両方を使用してください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:314 -msgid "Since Ansible 2.8, you can have user-supplied doc_fragments by using a ``doc_fragments`` directory adjacent to play or role, just like any other plugin." -msgstr "Ansible 2.8 以降、その他のプラグインと同様に、プレイやロールに隣接する ``doc_fragments`` ディレクトリーを使用することで、ユーザーが提供する doc_fragments を設定できます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:316 -msgid "For example, all AWS modules should include:" -msgstr "たとえば、すべての AWS モジュールには以下を含める必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:324 -msgid ":ref:`docfragments_collections` describes how to incorporate documentation fragments in a collection." -msgstr "「:ref:`docfragments_collections`」では、コレクションにドキュメントのフラグメントを組み込む方法を説明します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:329 -msgid "EXAMPLES block" -msgstr "EXAMPLES ブロック" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:331 -msgid "After the shebang, the UTF-8 coding, the copyright line, the license section, and the ``DOCUMENTATION`` block comes the ``EXAMPLES`` block. Here you show users how your module works with real-world examples in multi-line plain-text YAML format. The best examples are ready for the user to copy and paste into a playbook. Review and update your examples with every change to your module." -msgstr "シバンの後、UTF-8 コーディング、著作権表示、ライセンスセクション、および ``DOCUMENTATION``ブロックの後に ``EXAMPLES`` ブロックが続きます。ここでは、モジュールが実際の例で複数行のプレーンテキスト YAML 形式でどのように機能するかをユーザーに示します。最良の例は、ユーザーがコピーして Playbook に貼り付ける準備ができています。モジュールに変更を加えるたびに、例を確認して更新してください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:333 -msgid "Per playbook best practices, each example should include a ``name:`` line::" -msgstr "Playbook のベストプラクティスに基づき、各例には ``name:`` 行が必要です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:342 -msgid "The ``name:`` line should be capitalized and not include a trailing dot." -msgstr "``name:`` 行は大文字にし、末尾のドットは含めないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:344 -msgid "Use a fully qualified collection name (FQCN) as a part of the module's name like in the example above. For modules in ``ansible-base``, use the ``ansible.builtin.`` identifier, for example ``ansible.builtin.debug``." -msgstr "上記の例のように、モジュール名の一部として完全修飾コレクション名 (FQCN) を使用します。``ansible-base`` のモジュールの場合は、``ansible.builtin.`` 識別子 (たとえば ``ansible.builtin.debug``) を使用します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:346 -msgid "If your examples use boolean options, use yes/no values. Since the documentation generates boolean values as yes/no, having the examples use these values as well makes the module documentation more consistent." -msgstr "サンプルでブール値オプションを使用する場合は、yes/no の値を使用します。ドキュメントによりブール値が yes/no として生成されるため、このサンプルではこれらの値が使用されており、モジュールドキュメントの一貫性が保たれます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:348 -msgid "If your module returns facts that are often needed, an example of how to use them can be helpful." -msgstr "モジュールが必要なファクトを返すと、その使用方法の例が便利です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:353 -msgid "RETURN block" -msgstr "RETURN ブロック" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:355 -msgid "After the shebang, the UTF-8 coding, the copyright line, the license section, ``DOCUMENTATION`` and ``EXAMPLES`` blocks comes the ``RETURN`` block. This section documents the information the module returns for use by other modules." -msgstr "シバン、UTF-8コーディング、著作権表示、ライセンスセクション、``DOCUMENTATION`` および ``EXAMPLES`` ブロックの後に、``RETURN`` ブロックが続きます。このセクションでは、モジュールが他のモジュールで使用するために返す情報を説明します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:357 -msgid "If your module doesn't return anything (apart from the standard returns), this section of your module should read: ``RETURN = r''' # '''`` Otherwise, for each value returned, provide the following fields. All fields are required unless specified otherwise." -msgstr "モジュールが何も返さない場合は (標準の戻り値とは異なり)、モジュールのこのセクションは「``RETURN = r''' # '''``」を読み取る必要があります。それ以外の場合は、返された各値に以下のフィールドを指定します。特に指定がない場合はすべてのフィールドが必要になります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "return name" -msgstr "return name" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:361 -msgid "Name of the returned field." -msgstr "返されるフィールドの名前。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:364 -msgid "Detailed description of what this value represents. Capitalized and with trailing dot." -msgstr "この値が表す内容の詳細な説明。大文字で、末尾のドットを使用します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "returned" -msgstr "returned" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:366 -msgid "When this value is returned, such as ``always``, ``changed`` or ``success``. This is a string and can contain any human-readable content." -msgstr "``always``、``changed``、``success`` などのこの値が返されると、これは文字列となり、人間が判読できるコンテンツを含めることができます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:368 -msgid "Data type." -msgstr "データ型。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:370 -msgid "If ``type='list'``, specifies the data type of the list's elements." -msgstr "``type='list'`` の場合は、リストの要素のデータタイプを指定します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "sample" -msgstr "サンプル" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:372 -msgid "One or more examples." -msgstr "1 つ以上の例。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:374 -msgid "Only needed if this return was extended after initial Ansible release, in other words, this is greater than the top level `version_added` field. This is a string, and not a float, for example, ``version_added: '2.3'``." -msgstr "これは、最初の Ansible リリースの後にこの返された場合にのみ必要です。つまり、これは最上位レベルの `version_added` フィールドよりも大きくなります。これは浮動小数点 (例: ``version_added: '2.3'``) ではなく、文字列です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "contains" -msgstr "contains" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:377 -msgid "Optional. To describe nested return values, set ``type: dict``, or ``type: list``/``elements: dict``, or if you really have to, ``type: complex``, and repeat the elements above for each sub-field." -msgstr "任意です。ネストされた戻り値を記述するには、``type: dict`` または ``type: list``/``elements: dict`` を設定するか、本当に必要であれば ``type: complex`` を設定し、各サブフィールドに対して上記の要素を繰り返します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:379 -msgid "Here are two example ``RETURN`` sections, one with three simple fields and one with a complex nested field::" -msgstr "以下の例は、``RETURN`` セクションを 3 つの単純なフィールドと、複雑なネストされたフィールドを持つ 2 つのセクションです。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:427 -msgid "Python imports" -msgstr "Python のインポート" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:429 -msgid "After the shebang, the UTF-8 coding, the copyright line, the license, and the sections for ``DOCUMENTATION``, ``EXAMPLES``, and ``RETURN``, you can finally add the python imports. All modules must use Python imports in the form:" -msgstr "シバンの後には、UTF-8 コード行、著作権行、ライセンス、および ``DOCUMENTATION``、``EXAMPLES``、および ``RETURN`` のセクションが最後に python インポートを追加できます。すべてのモジュールは、Python インポートを形式で使用する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:435 -msgid "The use of \"wildcard\" imports such as ``from module_utils.basic import *`` is no longer allowed." -msgstr "``from module_utils.basic import *`` などの「ワイルドカード」インポートの使用は許可されなくなりました。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:440 -#: ../../rst/dev_guide/testing_documentation.rst:7 -msgid "Testing module documentation" -msgstr "モジュールドキュメンテーションのテスト" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:442 -msgid "To test Ansible documentation locally please :ref:`follow instruction`." -msgstr "Ansible ドキュメントをローカルでテストするには、「:ref:`指示に従う`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:6 -msgid "Developing Ansible modules" -msgstr "Ansible モジュールの開発" - -#: ../../rst/dev_guide/developing_modules_general.rst:8 -msgid "A module is a reusable, standalone script that Ansible runs on your behalf, either locally or remotely. Modules interact with your local machine, an API, or a remote system to perform specific tasks like changing a database password or spinning up a cloud instance. Each module can be used by the Ansible API, or by the :command:`ansible` or :command:`ansible-playbook` programs. A module provides a defined interface, accepts arguments, and returns information to Ansible by printing a JSON string to stdout before exiting." -msgstr "モジュールは、Ansible がローカルまたはリモートのいずれかで実行する再利用可能なスタンドアロンスクリプトです。モジュールは、ローカルマシン、API、またはリモートシステムと対話し、データベースパスワードの変更やクラウドインスタンスの起動などの特定のタスクを実行します。各モジュールは、Ansible API または :command:`ansible` または :command:`ansible-playbook` プログラムで使用できます。モジュールは定義されたインターフェースを提供し、引数を受け入れ、終了前に JSON 文字列を stdout に出力して Ansible に情報を返します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:10 -msgid "If you need functionality that is not available in any of the thousands of Ansible modules found in collections, you can easily write your own custom module. When you write a module for local use, you can choose any programming language and follow your own rules. Use this topic to learn how to create an Ansible module in Python. After you create a module, you must add it locally to the appropriate directory so that Ansible can find and execute it. For details about adding a module locally, see :ref:`developing_locally`." -msgstr "コレクションにある数千の Ansible モジュールで利用できない機能が必要な場合は、独自のカスタムモジュールを簡単に作成できます。ローカルで使用するためのモジュールを作成する場合は、任意のプログラミング言語を選択して、独自のルールに従うことができます。本トピックを使用して、Python で Ansible モジュールを作成する方法を説明します。モジュールを作成したら、Ansible が検出および実行できるように、これを適切なディレクトリーにローカルに追加する必要があります。ローカルでモジュールを追加する方法は、「:ref:`developing_locally`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:18 -msgid "Preparing an environment for developing Ansible modules" -msgstr "Ansible モジュール開発用の環境の準備" - -#: ../../rst/dev_guide/developing_modules_general.rst:21 -msgid "Installing prerequisites via apt (Ubuntu)" -msgstr "apt (Ubuntu) を使用した前提条件のインストール" - -#: ../../rst/dev_guide/developing_modules_general.rst:23 -msgid "Due to dependencies (for example ansible -> paramiko -> pynacl -> libffi):" -msgstr "依存関係のため (例: ansible -> paramiko -> pynacl -> libffi)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:31 -msgid "Creating a development environment (platform-agnostic steps)" -msgstr "開発環境の作成 (プラットフォームに依存しない手順)" - -#: ../../rst/dev_guide/developing_modules_general.rst:33 -msgid "Clone the Ansible repository: ``$ git clone https://github.com/ansible/ansible.git``" -msgstr "Ansible リポジトリーのクローンを作成します (``$ git clone https://github.com/ansible/ansible.git``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:35 -msgid "Change directory into the repository root dir: ``$ cd ansible``" -msgstr "ディレクトリーをリポジトリーの root ディレクトリーに変更します (``$ cd ansible``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:36 -msgid "Create a virtual environment: ``$ python3 -m venv venv`` (or for Python 2 ``$ virtualenv venv``. Note, this requires you to install the virtualenv package: ``$ pip install virtualenv``)" -msgstr "仮想環境を作成します (``$ python3 -m venv venv``) (Python 2 の場合は ``$ virtualenv venv`` です。これには、virtualenv パッケージ ``$ pip install virtualenv`` をインストールする必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:39 -msgid "Activate the virtual environment: ``$ . venv/bin/activate``" -msgstr "仮想環境をアクティベートします (``$ . venv/bin/activate``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:40 -msgid "Install development requirements: ``$ pip install -r requirements.txt``" -msgstr "開発要件をインストールします (``$ pip install -r requirements.txt``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:42 -msgid "Run the environment setup script for each new dev shell process: ``$ . hacking/env-setup``" -msgstr "新規 dev シェルプロセスごとに環境設定スクリプトを実行します (``$ . hacking/env-setup``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:45 -msgid "After the initial setup above, every time you are ready to start developing Ansible you should be able to just run the following from the root of the Ansible repo: ``$ . venv/bin/activate && . hacking/env-setup``" -msgstr "上記の初期設定後、Ansible の開発準備ができるたびに、Ansible リポジトリーのルートから ``$ . venv/bin/activate && . hacking/env-setup`` を実行できるはずです。" - -#: ../../rst/dev_guide/developing_modules_general.rst:52 -msgid "Creating an info or a facts module" -msgstr "情報またはファクトモジュールの作成" - -#: ../../rst/dev_guide/developing_modules_general.rst:54 -msgid "Ansible gathers information about the target machines using facts modules, and gathers information on other objects or files using info modules. If you find yourself trying to add ``state: info`` or ``state: list`` to an existing module, that is often a sign that a new dedicated ``_facts`` or ``_info`` module is needed." -msgstr "Ansible は、ファクトモジュールを使用してターゲットマシンに関する情報を収集し、info モジュールを使用して他のオブジェクトやファイルに関する情報を収集します。既存のモジュールに ``state: info`` または ``state: list`` を追加しようとする際、多くの場合、これが新規の専用 ``_facts`` モジュールまたは ``_info`` モジュールが必要になるという署名になります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:57 -msgid "In Ansible 2.8 and onwards, we have two type of information modules, they are ``*_info`` and ``*_facts``." -msgstr "Ansible 2.8 以降では、2 種類の情報モジュール (``*_info`` および ``*_facts``) があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:59 -msgid "If a module is named ``_facts``, it should be because its main purpose is returning ``ansible_facts``. Do not name modules that do not do this with ``_facts``. Only use ``ansible_facts`` for information that is specific to the host machine, for example network interfaces and their configuration, which operating system and which programs are installed." -msgstr "モジュールの名前が ``_facts`` の場合、主な目的は ``ansible_facts`` を返しているからです。これは、``_facts`` で行わないモジュールに名前を付けないでください。ネットワークインターフェース、その設定など、オペレーティングシステムと、インストールされているプログラムなど、ホストマシンに固有の情報には ``ansible_facts`` のみを使用してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:62 -msgid "Modules that query/return general information (and not ``ansible_facts``) should be named ``_info``. General information is non-host specific information, for example information on online/cloud services (you can access different accounts for the same online service from the same host), or information on VMs and containers accessible from the machine, or information on individual files or programs." -msgstr "(``ansible_facts`` ではなく) 一般情報をクエリーまたは返すモジュールの名前は、``_info`` にする必要があります。オンライン/クラウドサービスに関する情報などの一般的な情報は、ホスト以外の固有の情報 (同じホストから同じオンラインサービスの異なるアカウントにアクセスできる)、マシンからアクセス可能な仮想マシンおよびコンテナーに関する情報、または個々のファイルまたはプログラムに関する情報です。" - -#: ../../rst/dev_guide/developing_modules_general.rst:65 -msgid "Info and facts modules, are just like any other Ansible Module, with a few minor requirements:" -msgstr "info および facts モジュールには、他の Ansible モジュールと同様に、さほど重要ではない要件があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:67 -msgid "They MUST be named ``_info`` or ``_facts``, where is singular." -msgstr "名前は ``_info`` または ``_facts`` です。 は単数になります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:68 -msgid "Info ``*_info`` modules MUST return in the form of the :ref:`result dictionary` so other modules can access them." -msgstr "info の ``*_info`` モジュールは、他のモジュールがアクセスできるように :ref:`結果ディレクトリー` の形式で返す必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:69 -msgid "Fact ``*_facts`` modules MUST return in the ``ansible_facts`` field of the :ref:`result dictionary` so other modules can access them." -msgstr "fact の ``*_facts`` モジュールは、他のモジュールがそれらにアクセスできるように :ref:`結果ディレクトリー` の ``ansible_facts`` フィールドに返す必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:70 -msgid "They MUST support :ref:`check_mode `." -msgstr ":ref:`check_mode ` をサポートする必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:71 -msgid "They MUST NOT make any changes to the system." -msgstr "システムに変更を加えないでください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:72 -msgid "They MUST document the :ref:`return fields` and :ref:`examples`." -msgstr ":ref:`return fields` および :ref:`examples` を文書化する必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:74 -msgid "To create an info module:" -msgstr "info モジュールを作成するには、次を実行します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:76 -msgid "Navigate to the correct directory for your new module: ``$ cd lib/ansible/modules/``. If you are developing module using collection, ``$ cd plugins/modules/`` inside your collection development tree." -msgstr "新しいモジュールの正しいディレクトリーに移動します (``$ cd lib/ansible/modules/``)。コレクションを使用してモジュールを開発する場合は、コレクション開発ツリー内で ``$ cd plugins/modules/`` を実行します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:77 -msgid "Create your new module file: ``$ touch my_test_info.py``." -msgstr "新しいモジュールファイルを作成します (``$ touch my_test_info.py``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:78 -msgid "Paste the content below into your new info module file. It includes the :ref:`required Ansible format and documentation `, a simple :ref:`argument spec for declaring the module options `, and some example code." -msgstr "以下の内容を新しい情報モジュールファイルに貼り付けます。これには、:ref:`必須の Ansible 形式およびドキュメント `、:ref:`モジュールオプションを宣言する単純な引数仕様 `、およびサンプルコードが含まれます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:79 -msgid "Modify and extend the code to do what you want your new info module to do. See the :ref:`programming tips ` and :ref:`Python 3 compatibility ` pages for pointers on writing clean and concise module code." -msgstr "新しい情報モジュールが実行することを行えるようにコードを変更し、拡張します。余計なものが入っていないモジュールコードや、簡潔なモジュールコードの作成に関するヒントは、「:ref:`プログラミングのヒント `」ページおよび「:ref:`Python 3 互換性 `」ページを参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:84 -msgid "Use the same process to create a facts module." -msgstr "同じプロセスを使用してファクトモジュールを作成します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:90 -msgid "Creating a module" -msgstr "モジュールの作成" - -#: ../../rst/dev_guide/developing_modules_general.rst:92 -msgid "To create a module:" -msgstr "モジュールを作成するには、以下を行います。" - -#: ../../rst/dev_guide/developing_modules_general.rst:94 -msgid "Navigate to the correct directory for your new module: ``$ cd lib/ansible/modules/``. If you are developing a module in a :ref:`collection `, ``$ cd plugins/modules/`` inside your collection development tree." -msgstr "新しいモジュールの正しいディレクトリーに移動します (``$ cd lib/ansible/modules/``)。:ref:`コレクション ` でモジュールを開発する場合は、コレクション開発ツリー内で ``$ cd plugins/modules/`` を実行します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:95 -msgid "Create your new module file: ``$ touch my_test.py``." -msgstr "新しいモジュールファイルを作成します (``$ touch my_test.py``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:96 -msgid "Paste the content below into your new module file. It includes the :ref:`required Ansible format and documentation `, a simple :ref:`argument spec for declaring the module options `, and some example code." -msgstr "以下の内容を新しいモジュールファイルに貼り付けます。これには、:ref:`必須の Ansible 形式およびドキュメント `、:ref:`モジュールオプションを宣言する単純な引数仕様 `、およびサンプルコードが含まれます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:97 -msgid "Modify and extend the code to do what you want your new module to do. See the :ref:`programming tips ` and :ref:`Python 3 compatibility ` pages for pointers on writing clean and concise module code." -msgstr "新しいモジュールが実行することを行えるようにコードを変更し、拡張します。余計なものが入っていないモジュールコードや、簡潔なモジュールコードの作成に関するヒントは、「:ref:`プログラミングのヒント `」ページおよび」:ref:`Python 3 互換性 `」ページを参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:103 -msgid "Verifying your module code" -msgstr "モジュールコードの確認" - -#: ../../rst/dev_guide/developing_modules_general.rst:105 -msgid "After you modify the sample code above to do what you want, you can try out your module. Our :ref:`debugging tips ` will help if you run into bugs as you verify your module code." -msgstr "上記のサンプルコードを修正した後に、モジュールを試すことができます。:ref:`debugging tips ` は、モジュールコードを検証する際にバグが発生した場合に役立ちます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:110 -msgid "Verifying your module code locally" -msgstr "モジュールコードのローカルでの確認" - -#: ../../rst/dev_guide/developing_modules_general.rst:112 -msgid "If your module does not need to target a remote host, you can quickly and easily exercise your code locally like this:" -msgstr "モジュールがリモートホストを対象にする必要がない場合は、以下のようにコードをローカルで簡単に使用できます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:114 -msgid "Create an arguments file, a basic JSON config file that passes parameters to your module so that you can run it. Name the arguments file ``/tmp/args.json`` and add the following content:" -msgstr "引数ファイルを作成します。これは、モジュールを実行できるようにパラメーターをモジュールに渡す基本的な JSON 構成ファイルです。引数ファイル ``/tmp/args.json`` に名前を付け、以下の内容を追加します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:125 -msgid "If you are using a virtual environment (which is highly recommended for development) activate it: ``$ . venv/bin/activate``" -msgstr "(開発に非常に推奨されている) 仮想環境を使用している場合は、アクティベートします (``$ . venv/bin/activate``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:127 -msgid "Set up the environment for development: ``$ . hacking/env-setup``" -msgstr "開発用の環境を設定します (``$ . hacking/env-setup``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:128 -msgid "Run your test module locally and directly: ``$ python -m ansible.modules.my_test /tmp/args.json``" -msgstr "テストモジュールをローカルで直接実行します (``$ python -m ansible.modules.my_test /tmp/args.json``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:131 -msgid "This should return output like this:" -msgstr "これにより、以下のような出力が返されます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:139 -msgid "Verifying your module code in a playbook" -msgstr "Playbook でのモジュールコードの確認" - -#: ../../rst/dev_guide/developing_modules_general.rst:141 -msgid "The next step in verifying your new module is to consume it with an Ansible playbook." -msgstr "新規モジュールを検証する次のステップは、Ansible Playbook で使用します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:143 -msgid "Create a playbook in any directory: ``$ touch testmod.yml``" -msgstr "任意のディレクトリーに Playbook を作成します (``$ touch testmod.yml``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:144 -#: ../../rst/dev_guide/developing_modules_general_windows.rst:521 -msgid "Add the following to the new playbook file::" -msgstr "以下を新しい Playbook ファイルに追加します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:158 -msgid "Run the playbook and analyze the output: ``$ ansible-playbook ./testmod.yml``" -msgstr "Playbook を実行し、出力を分析します (``$ ansible-playbook ./testmod.yml``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:161 -msgid "Testing your newly-created module" -msgstr "新たに作成したモジュールのテスト" - -#: ../../rst/dev_guide/developing_modules_general.rst:163 -msgid "The following two examples will get you started with testing your module code. Please review our :ref:`testing ` section for more detailed information, including instructions for :ref:`testing module documentation `, adding :ref:`integration tests `, and more." -msgstr "以下の 2 つの例は、モジュールコードのテストを開始します。:ref:`モジュールのテストのドキュメント ` の手順、:ref:`統合テスト ` の追加などの詳細な情報は、:ref:`testing ` のセクションを参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:167 -#: ../../rst/dev_guide/testing_integration.rst:20 -msgid "Every new module and plugin should have integration tests, even if the tests cannot be run on Ansible CI infrastructure. In this case, the tests should be marked with the ``unsupported`` alias in `aliases file `_." -msgstr "テストを Ansible CI インフラストラクチャーで実行できない場合でも、新しいモジュールとプラグインには統合テストが必要です。この場合、テストは `aliases file `_ の ``unsupported`` エイリアスでマーク付けする必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:171 -msgid "Performing sanity tests" -msgstr "サニティーテストの実行" - -#: ../../rst/dev_guide/developing_modules_general.rst:173 -msgid "You can run through Ansible's sanity checks in a container:" -msgstr "Ansible の健全性チェックをコンテナーで実行できます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:175 -msgid "``$ ansible-test sanity -v --docker --python 2.7 MODULE_NAME``" -msgstr "``$ ansible-test sanity -v --docker --python 2.7 MODULE_NAME``" - -#: ../../rst/dev_guide/developing_modules_general.rst:178 -msgid "Note that this example requires Docker to be installed and running. If you'd rather not use a container for this, you can choose to use ``--venv`` instead of ``--docker``." -msgstr "この例では、Docker をインストールして実行する必要があります。コンテナーを使用しない場合は、``--docker`` の代わりに ``--venv`` を使用できます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:181 -msgid "Adding unit tests" -msgstr "ユニットテストの追加" - -#: ../../rst/dev_guide/developing_modules_general.rst:183 -msgid "You can add unit tests for your module in ``./test/units/modules``. You must first set up your testing environment. In this example, we're using Python 3.5." -msgstr "モジュールのユニットテストは ``./test/units/modules`` で追加できます。まずテスト環境を設定する必要があります。この例では、Python 3.5 を使用しています。" - -#: ../../rst/dev_guide/developing_modules_general.rst:185 -msgid "Install the requirements (outside of your virtual environment): ``$ pip3 install -r ./test/lib/ansible_test/_data/requirements/units.txt``" -msgstr "(仮想環境外に) 要件をインストールします (``$ pip3 install -r ./test/lib/ansible_test/_data/requirements/units.txt``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:186 -msgid "Run ``. hacking/env-setup``" -msgstr "``. hacking/env-setup`` を実行します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:187 -msgid "To run all tests do the following: ``$ ansible-test units --python 3.5``. If you are using a CI environment, these tests will run automatically." -msgstr "すべてのテストを実行するには、``$ ansible-test units --python 3.5`` で CI 環境を使用している場合は、これらのテストが自動的に実行されます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:189 -msgid "Ansible uses pytest for unit testing." -msgstr "Ansible はユニットテストに pytest を使用します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:191 -msgid "To run pytest against a single test module, you can run the following command. Ensure that you are providing the correct path of the test module:" -msgstr "単一のテストモジュールに対して pytest を実行するには、以下のコマンドを実行します。テストモジュールの正しいパスを提供していることを確認してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:193 -msgid "``$ pytest -r a --cov=. --cov-report=html --fulltrace --color yes test/units/modules/.../test/my_test.py``" -msgstr "``$ pytest -r a --cov=. --cov-report=html --fulltrace --color yes test/units/modules/.../test/my_test.py``" - -#: ../../rst/dev_guide/developing_modules_general.rst:197 -msgid "Contributing back to Ansible" -msgstr "Ansible への貢献" - -#: ../../rst/dev_guide/developing_modules_general.rst:199 -msgid "If you would like to contribute to ``ansible-base`` by adding a new feature or fixing a bug, `create a fork `_ of the ansible/ansible repository and develop against a new feature branch using the ``devel`` branch as a starting point. When you you have a good working code change, you can submit a pull request to the Ansible repository by selecting your feature branch as a source and the Ansible devel branch as a target." -msgstr "新しい機能を追加したりバグを修正したりして、``ansible-base`` に貢献する場合は、ansible/ansible リポジトリーの ansible/ansible リポジトリーの `フォークを作成 `_ し、開始点として ``devel`` ブランチを使用して新機能ブランチに対して開発します。適切な作業コードも変更がある場合は、機能ブランチをソースとして、およびAnsible devel ブランチをターゲットとして選択し、Ansible リポジトリーにプルリクエストを送信します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:201 -msgid "If you want to contribute a module to an :ref:`Ansible collection `, review our :ref:`submission checklist `, :ref:`programming tips `, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility `, as well as information about :ref:`testing ` before you open a pull request." -msgstr "モジュールを :ref:`Ansible コレクション ` に提供したい場合は、:ref:`提出のチェックアウト `、:ref:`プログラムのヒント `、および :ref:`Python 2 および Python 3 の互換性を維持するストラテジー ` を確認してください。プルリクエストを作成する前に、:ref:`テスト ` に関する情報も併せて参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:203 -msgid "The :ref:`Community Guide ` covers how to open a pull request and what happens next." -msgstr ":ref:`コミュニティーガイド ` では、プルリクエストを開く方法と、次に実行することを説明します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:207 -msgid "Communication and development support" -msgstr "通信および開発のサポート" - -#: ../../rst/dev_guide/developing_modules_general.rst:209 -msgid "Join the IRC channel ``#ansible-devel`` on freenode for discussions surrounding Ansible development." -msgstr "Ansible 開発に取り組むため、freenode の IRC チャンネル ``#ansible-devel`` に参加します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:212 -#: ../../rst/dev_guide/developing_modules_general_windows.rst:695 -msgid "For questions and discussions pertaining to using the Ansible product, use the ``#ansible`` channel." -msgstr "Ansible 製品の使用に関する質問および貢献については、``#ansible`` チャンネルを使用します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:215 -msgid "For more specific IRC channels look at :ref:`Community Guide, Communicating `." -msgstr "より具体的な IRC チャンネルは、「:ref:`Community Guide, Communicating `」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:218 -msgid "Credit" -msgstr "謝辞" - -#: ../../rst/dev_guide/developing_modules_general.rst:220 -msgid "Thank you to Thomas Stringer (`@trstringer `_) for contributing source material for this topic." -msgstr "このトピックの元となる資料を提供していただいた Thomas Stringer (`@trstringer `_) 氏に感謝の意を示します。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:5 -msgid "Developing Cisco ACI modules" -msgstr "Cisco ACI モジュールの開発 " - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:6 -msgid "This is a brief walk-through of how to create new Cisco ACI modules for Ansible." -msgstr "Ansible 向けに新しい Cisco ACI モジュールを作成する方法に関する簡単なウォークスルーです。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:8 -msgid "For more information about Cisco ACI, look at the :ref:`Cisco ACI user guide `." -msgstr "Cisco ACI の詳細は、「:ref:`Cisco ACI ユーザーガイド `」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:10 -#: ../../rst/dev_guide/developing_modules_general_windows.rst:13 -msgid "What's covered in this section:" -msgstr "本項で取り上げられている内容:" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:20 -#: ../../rst/dev_guide/testing_units_modules.rst:14 -msgid "Introduction" -msgstr "はじめに" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:21 -msgid "The `cisco.aci collection `_ already includes a large number of Cisco ACI modules, however the ACI object model is huge and covering all possible functionality would easily cover more than 1500 individual modules." -msgstr "`cisco.aci collection `_ にはすでに多数の Cisco ACI モジュールが含まれていますが、ACI オブジェクトモデルは大きく、すべての機能に対応するため、1500 以上のモジュールを簡単に対応できます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:23 -msgid "If you need specific functionality, you have 2 options:" -msgstr "特定の機能が必要な場合は、2 つのオプションがあります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:25 -msgid "Learn the ACI object model and use the low-level APIC REST API using the :ref:`aci_rest ` module" -msgstr "ACI オブジェクトモデルを学習し、「:ref:`aci_rest `」モジュールを使用して低レベルの APIC REST API を使用します。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:26 -msgid "Write your own dedicated modules, which is actually quite easy" -msgstr "独自の専用モジュールを作成することは、実際には非常に簡単です。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:30 -msgid "`ACI Fundamentals: ACI Policy Model `_" -msgstr "`ACI Fundamentals: ACI Policy Model `_" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:31 -msgid "A good introduction to the ACI object model." -msgstr "ACI オブジェクトモデルの優れた概要。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:32 -msgid "`APIC Management Information Model reference `_" -msgstr "`APIC Management Information Model reference `_" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:33 -msgid "Complete reference of the APIC object model." -msgstr "APIC オブジェクトモデルの完全なリファレンス。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:34 -msgid "`APIC REST API Configuration Guide `_" -msgstr "`APIC REST API Configuration Guide `_" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:35 -msgid "Detailed guide on how the APIC REST API is designed and used, incl. many examples." -msgstr "APIC REST API を設計および使用する方法についての詳細ガイド。多数の例があります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:38 -msgid "So let's look at how a typical ACI module is built up." -msgstr "それでは、典型的な ACI モジュールがどのように構築されるかを見てみましょう。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:44 -msgid "ACI module structure" -msgstr "ACI モジュール構造" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:47 -msgid "Importing objects from Python libraries" -msgstr "Python ライブラリーからのオブジェクトのインポート" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:48 -msgid "The following imports are standard across ACI modules:" -msgstr "以下のインポートは、ACI モジュール全体で標準のものです。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:57 -msgid "Defining the argument spec" -msgstr "引数仕様の定義" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:58 -msgid "The first line adds the standard connection parameters to the module. After that, the next section will update the ``argument_spec`` dictionary with module-specific parameters. The module-specific parameters should include:" -msgstr "最初の行は、標準の接続パラメーターをモジュールに追加します。その後、以下のセクションはモジュール固有のパラメーターで ``argument_spec`` ディクショナリーを更新します。モジュール固有のパラメーターには以下が含まれます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:60 -msgid "the object_id (usually the name)" -msgstr "object_id (通常は名前)" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:61 -msgid "the configurable properties of the object" -msgstr "オブジェクトの設定可能なプロパティー" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:62 -msgid "the parent object IDs (all parents up to the root)" -msgstr "親オブジェクト ID (ルートまでのすべての親)" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:63 -msgid "only child classes that are a 1-to-1 relationship (1-to-many/many-to-many require their own module to properly manage)" -msgstr "1 対 1 の関係である子クラスのみ (1 対多/多対多 では、独自のモジュールが適切に管理する必要があります)" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:64 -msgid "the state" -msgstr "状態" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:66 -msgid "``state: absent`` to ensure object does not exist" -msgstr "``state: absent``: オブジェクトが存在しないことを確認する" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:67 -msgid "``state: present`` to ensure the object and configs exist; this is also the default" -msgstr "``state: present``: オブジェクトと設定が存在することを確認する (デフォルト)" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:68 -msgid "``state: query`` to retrieve information about objects in the class" -msgstr "``state: query``: クラスのオブジェクトに関する情報を取得する" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:86 -msgid "Do not provide default values for configuration arguments. Default values could cause unintended changes to the object." -msgstr "設定引数のデフォルト値を指定しないでください。デフォルト値により、オブジェクトへの意図しない変更が生じる可能性があります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:89 -msgid "Using the AnsibleModule object" -msgstr "AnsibleModule オブジェクトの使用" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:90 -msgid "The following section creates an AnsibleModule instance. The module should support check-mode, so we pass the ``argument_spec`` and ``supports_check_mode`` arguments. Since these modules support querying the APIC for all objects of the module's class, the object/parent IDs should only be required if ``state: absent`` or ``state: present``." -msgstr "次のセクションでは、AnsibleModule インスタンスを作成します。モジュールはチェックモードをサポートする必要があるため、``argument_spec`` 引数および ``supports_check_mode`` 引数を渡します。これらのモジュールは、モジュールのクラスのすべてのオブジェクトに対する APIC のクエリーをサポートするため、オブジェクト/親 ID は、``state: absent`` または ``state: present`` の場合に限り必要になります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:105 -msgid "Mapping variable definition" -msgstr "マッピング変数定義" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:106 -msgid "Once the AnsibleModule object has been initiated, the necessary parameter values should be extracted from ``params`` and any data validation should be done. Usually the only params that need to be extracted are those related to the ACI object configuration and its child configuration. If you have integer objects that you would like to validate, then the validation should be done here, and the ``ACIModule.payload()`` method will handle the string conversion." -msgstr "AnsibleModule オブジェクトが開始されたら、必要なパラメーターの値を ``params`` から抽出し、データの検証を行う必要があります。通常、抽出する必要がある唯一のパラメーターが ACI オブジェクトの設定およびその子設定に関連するパラメーターのみとなります。検証する整数オブジェクトがある場合は、検証を行う必要があります。データ検証はここで行う必要があり、``ACIModule.payload()`` メソッドは変換文字列を処理する必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:122 -msgid "Using the ACIModule object" -msgstr "ACIModule オブジェクトの使用" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:123 -msgid "The ACIModule class handles most of the logic for the ACI modules. The ACIModule extends functionality to the AnsibleModule object, so the module instance must be passed into the class instantiation." -msgstr "ACIModule クラスは、ACI モジュールのロジックの大部分を処理します。ACIModule は機能を AnsibleModule オブジェクトに拡張するため、モジュールインスタンスをクラスのインスタンス化に渡す必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:129 -msgid "The ACIModule has six main methods that are used by the modules:" -msgstr "ACIModule には、モジュールによって使用される 6 つの主なメソッドがあります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:131 -msgid "construct_url" -msgstr "construct_url" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:132 -msgid "get_existing" -msgstr "get_existing" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:133 -msgid "payload" -msgstr "payload" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:134 -msgid "get_diff" -msgstr "get_diff" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:135 -msgid "post_config" -msgstr "post_config" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:136 -msgid "delete_config" -msgstr "delete_config" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:138 -msgid "The first two methods are used regardless of what value is passed to the ``state`` parameter." -msgstr "最初の 2 つのメソッドは、``state`` パラメーターに渡される値に関係なく使用されます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:141 -msgid "Constructing URLs" -msgstr "URL の構築" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:142 -msgid "The ``construct_url()`` method is used to dynamically build the appropriate URL to interact with the object, and the appropriate filter string that should be appended to the URL to filter the results." -msgstr "``construct_url()`` メソッドは、オブジェクトと対話するために適切な URL と、URL に追加して結果にフィルターを設定する適切なフィルター文字列を動的にビルドするために使用されます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:144 -msgid "When the ``state`` is not ``query``, the URL is the base URL to access the APIC plus the distinguished name to access the object. The filter string will restrict the returned data to just the configuration data." -msgstr "``state`` が ``query`` でない場合、URL は APIC にアクセスするベース URL と、オブジェクトにアクセスするための識別名です。フィルター文字列は返されたデータを設定データにのみ制限します。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:145 -msgid "When ``state`` is ``query``, the URL and filter string used depends on what parameters are passed to the object. This method handles the complexity so that it is easier to add new modules and so that all modules are consistent in what type of data is returned." -msgstr "``state`` が ``query`` される場合、使用される URL およびフィルター文字列は、オブジェクトに渡されるパラメーターによって異なります。この方法は複雑性を処理するため、新しいモジュールの追加が容易になります。また、すべてのモジュールがどのタイプのデータを返すかに一貫性を持たせるようにします。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:147 -msgid "Our design goal is to take all ID parameters that have values, and return the most specific data possible. If you do not supply any ID parameters to the task, then all objects of the class will be returned. If your task does consist of ID parameters sed, then the data for the specific object is returned. If a partial set of ID parameters are passed, then the module will use the IDs that are passed to build the URL and filter strings appropriately." -msgstr "この設計の目的は、値があるすべての ID パラメーターを取り、最も具体的なデータを返すことです。ID パラメーターをタスクに指定しないと、クラスのすべてのオブジェクトが返されます。タスクが ID パラメーターで構成されている場合は、特定のオブジェクトのデータが返されます。ID パラメーターの一部が渡されると、モジュールは URL およびフィルター文字列を適切にビルドするために渡された ID を使用します。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:149 -msgid "The ``construct_url()`` method takes 2 required arguments:" -msgstr "``construct_url()`` メソッドは、必要な引数を 2 つ取ります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:151 -msgid "**self** - passed automatically with the class instance" -msgstr "**self** - クラスインスタンスで自動的に渡されます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:152 -msgid "**root_class** - A dictionary consisting of ``aci_class``, ``aci_rn``, ``target_filter``, and ``module_object`` keys" -msgstr "**root_class**: ``aci_class`` キー、``aci_rn`` キー、``target_filter`` キー、および ``module_object`` キーで構成されるディクショナリー" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:154 -msgid "**aci_class**: The name of the class used by the APIC, for example ``fvTenant``" -msgstr "**aci_class**: APIC が使用するクラス名 (例: ``fvTenant``)" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:156 -msgid "**aci_rn**: The relative name of the object, for example ``tn-ACME``" -msgstr "**aci_rn**: オブジェクトの相対名 (例: ``tn-ACME``)" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:158 -msgid "**target_filter**: A dictionary with key-value pairs that make up the query string for selecting a subset of entries, for example ``{'name': 'ACME'}``" -msgstr "**target_filter**: エントリーのサブセットを選択するクエリー文字列を構成するキーと値のペアを持つディクショナリー (例: ``{'name': 'ACME'}``)" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:160 -msgid "**module_object**: The particular object for this class, for example ``ACME``" -msgstr "**module_object**: このクラスの特定のオブジェクト (例: ``ACME``)" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:162 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:597 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:636 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:650 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:750 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:767 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:781 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:808 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:825 -#: ../../rst/dev_guide/testing_units_modules.rst:90 -#: ../../rst/dev_guide/testing_units_modules.rst:109 -msgid "Example:" -msgstr "例: " - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:175 -msgid "Some modules, like ``aci_tenant``, are the root class and so they would not need to pass any additional arguments to the method." -msgstr "``aci_tenant`` などの一部のモジュールは root クラスであるため、メソッドに追加の引数を渡す必要はありません。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:177 -msgid "The ``construct_url()`` method takes 4 optional arguments, the first three imitate the root class as described above, but are for child objects:" -msgstr "``construct_url()`` メソッドは、4 つの任意の引数を取ります。最初の 3 つの引数が上記のように root クラスを模倣しますが、これは子オブジェクト用です。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:179 -msgid "subclass_1 - A dictionary consisting of ``aci_class``, ``aci_rn``, ``target_filter``, and ``module_object`` keys" -msgstr "subclass_1 - ``aci_class`` キー、``aci_rn`` キー、``target_filter`` キー、および ``module_object`` キーで構成されるディクショナリー" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:181 -msgid "Example: Application Profile Class (AP)" -msgstr "例: Application Profile Class (AP)" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:183 -msgid "subclass_2 - A dictionary consisting of ``aci_class``, ``aci_rn``, ``target_filter``, and ``module_object`` keys" -msgstr "subclass_2 - ``aci_class`` キー、``aci_rn`` キー、``target_filter`` キー、および ``module_object`` キーで構成されるディクショナリー" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:185 -msgid "Example: End Point Group (EPG)" -msgstr "例: エンドポイントグループ (EPG)" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:187 -msgid "subclass_3 - A dictionary consisting of ``aci_class``, ``aci_rn``, ``target_filter``, and ``module_object`` keys" -msgstr "subclass_3 - ``aci_class`` キー、``aci_rn`` キー、``target_filter`` キー、および ``module_object`` キーで構成されるディクショナリー" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:189 -msgid "Example: Binding a Contract to an EPG" -msgstr "例: EPG への契約のバインド" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:191 -msgid "child_classes - The list of APIC names for the child classes supported by the modules." -msgstr "child_classes - モジュールがサポートする子クラスの APIC 名のリスト。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:193 -msgid "This is a list, even if it is a list of one" -msgstr "1 つのリストであっても、これはリストです" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:194 -msgid "These are the unfriendly names used by the APIC" -msgstr "これらは、APIC が使用する分かりにくい名前です。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:195 -msgid "These are used to limit the returned child_classes when possible" -msgstr "可能な場合は、返された child_classes を制限するために使用されます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:196 -msgid "Example: ``child_classes=['fvRsBDSubnetToProfile', 'fvRsNdPfxPol']``" -msgstr "例: ``child_classes=['fvRsBDSubnetToProfile', 'fvRsNdPfxPol']``" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:198 -msgid "Sometimes the APIC will require special characters ([, ], and -) or will use object metadata in the name (\"vlanns\" for VLAN pools); the module should handle adding special characters or joining of multiple parameters in order to keep expected inputs simple." -msgstr "APIC は、特殊文字 ([, ]、および -) を要求したり、名前にオブジェクトのメタデータ (「VLAN」プールの場合は「vlanns」) を使用したりすることがあります。モジュールは、予想される入力の単純さに保つために、特殊文字の追加または複数のパラメーターの結合を処理する必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:201 -msgid "Getting the existing configuration" -msgstr "既存設定の取得" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:202 -msgid "Once the URL and filter string have been built, the module is ready to retrieve the existing configuration for the object:" -msgstr "URL およびフィルター文字列が構築されると、モジュールはオブジェクトの既存の設定を取得できるようになります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:204 -msgid "``state: present`` retrieves the configuration to use as a comparison against what was entered in the task. All values that are different than the existing values will be updated." -msgstr "``state: present`` は、タスクに入力した値と比較として使用する設定を取得します。既存の値とは異なる値はすべて更新されます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:205 -msgid "``state: absent`` uses the existing configuration to see if the item exists and needs to be deleted." -msgstr "``state: absent`` は、既存の設定を使用して項目が存在し、削除する必要があるかどうかを確認します。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:206 -msgid "``state: query`` uses this to perform the query for the task and report back the existing data." -msgstr "``state: query`` は、これを使用してタスクのクエリーを実行し、既存のデータを報告します。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:214 -msgid "When state is present" -msgstr "state が present の場合" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:215 -msgid "When ``state: present``, the module needs to perform a diff against the existing configuration and the task entries. If any value needs to be updated, then the module will make a POST request with only the items that need to be updated. Some modules have children that are in a 1-to-1 relationship with another object; for these cases, the module can be used to manage the child objects." -msgstr "``state: present`` の場合、モジュールは既存の設定とタスクエントリーに対して diff を実行する必要があります。値を更新する必要がある場合は、モジュールは更新が必要なアイテムのみが含まれる POST リクエストを行います。モジュールによっては、別のオブジェクトと 1-to-1 の関係にある子があります。これらの場合、モジュールは子オブジェクトを管理するために使用できます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:218 -msgid "Building the ACI payload" -msgstr "ACI ペイロードの構築" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:219 -msgid "The ``aci.payload()`` method is used to build a dictionary of the proposed object configuration. All parameters that were not provided a value in the task will be removed from the dictionary (both for the object and its children). Any parameter that does have a value will be converted to a string and added to the final dictionary object that will be used for comparison against the existing configuration." -msgstr "``aci.payload()`` メソッドは、提案されたオブジェクト設定のディクショナリー構築に使用されます。タスクで値が提供されていないパラメーターはすべてディクショナリー (オブジェクトとその子の両方) から削除されます。値のあるパラメーターは文字列に変換され、既存の設定との比較に使用される最終ディクショナリーオブジェクトに追加されます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:221 -msgid "The ``aci.payload()`` method takes two required arguments and 1 optional argument, depending on if the module manages child objects." -msgstr "``aci.payload()`` メソッドは、モジュールが子オブジェクトを管理するかどうかに応じて、2 つの必須引数と、1 つの任意の引数を取ります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:223 -msgid "``aci_class`` is the APIC name for the object's class, for example ``aci_class='fvBD'``" -msgstr "``aci_class`` は、オブジェクトのクラスの APIC 名です。たとえば、``aci_class='fvBD'`` になります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:224 -msgid "``class_config`` is the appropriate dictionary to be used as the payload for the POST request" -msgstr "``class_config`` は POST 要求のペイロードとして使用する適切なディクショナリーです。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:226 -msgid "The keys should match the names used by the APIC." -msgstr "キーは APIC で使用される名前と一致する必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:227 -msgid "The values should be the corresponding value in ``module.params``; these are the variables defined above" -msgstr "``module.params`` の対応する値でなければなりません。これらは上で定義される変数です" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:229 -msgid "``child_configs`` is optional, and is a list of child config dictionaries." -msgstr "``child_configs`` は任意であり、子設定のディクショナリーの一覧です。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:231 -msgid "The child configs include the full child object dictionary, not just the attributes configuration portion." -msgstr "子設定には、属性設定部分だけでなく、完全な子オブジェクトディクショナリーが含まれます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:232 -msgid "The configuration portion is built the same way as the object." -msgstr "設定部分は、オブジェクトと同じ方法で構築されます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:256 -msgid "Performing the request" -msgstr "要求の実行" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:257 -msgid "The ``get_diff()`` method is used to perform the diff, and takes only one required argument, ``aci_class``. Example: ``aci.get_diff(aci_class='fvBD')``" -msgstr "``get_diff()`` メソッドは diff を実行し、必要な引数 ``aci_class`` を 1 つだけ取ります。たとえば ``aci.get_diff(aci_class='fvBD')`` です。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:260 -msgid "The ``post_config()`` method is used to make the POST request to the APIC if needed. This method doesn't take any arguments and handles check mode. Example: ``aci.post_config()``" -msgstr "``post_config()`` メソッドは、必要に応じて APIC への POST リクエストを行うために使用されます。このメソッドは引数を受け付けず、チェックモードを処理します。以下に例を示します。たとえば、``aci.post_config()`` になります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:265 -msgid "Example code" -msgstr "サンプルコード" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:295 -msgid "When state is absent" -msgstr "state が absent の場合" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:296 -msgid "If the task sets the state to absent, then the ``delete_config()`` method is all that is needed. This method does not take any arguments, and handles check mode." -msgstr "タスクが state を absent に設定すると、``delete_config()`` メソッドのみが必要になります。このメソッドは引数を取らず、チェックモードを処理します。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:305 -msgid "Exiting the module" -msgstr "モジュールの終了" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:306 -msgid "To have the module exit, call the ACIModule method ``exit_json()``. This method automatically takes care of returning the common return values for you." -msgstr "モジュールを終了するには、ACIModule メソッド ``exit_json()`` を呼び出します。このメソッドは、一般的な戻り値を返すことを自動的に行います。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:319 -msgid "Testing ACI library functions" -msgstr "ACI ライブラリー関数のテスト" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:320 -msgid "You can test your ``construct_url()`` and ``payload()`` arguments without accessing APIC hardware by using the following python script:" -msgstr "以下の python スクリプトを使用して、APIC ハードウェアにアクセスせずに ``construct_url()`` 引数および ``payload()`` 引数をテストすることができます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:379 -msgid "This will result in:" -msgstr "これにより、以下が生成されます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:393 -msgid "Testing for sanity checks" -msgstr "健全性チェックのテスト" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:394 -msgid "You can run from your fork something like:" -msgstr "次のようなフォークから実行できます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:402 -#: ../../rst/dev_guide/testing.rst:33 -msgid ":ref:`testing_sanity`" -msgstr ":ref:`testing_sanity`" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:403 -msgid "Information on how to build sanity tests." -msgstr "健全性テストを構築する方法に関する情報" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:407 -msgid "Testing ACI integration tests" -msgstr "ACI 統合テストのテスト" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:408 -#: ../../rst/dev_guide/developing_modules_general_aci.rst:438 -msgid "You can run this:" -msgstr "以下を実行できます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:414 -msgid "You may need to add ``--python 2.7`` or ``--python 3.6`` in order to use the correct python version for performing tests." -msgstr "テストの実行に適切な python バージョンを使用するには、``--python 2.7`` または ``--python 3.6`` を追加しないといけない場合があります。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:416 -msgid "You may want to edit the used inventory at *test/integration/inventory.networking* and add something like:" -msgstr "*test/integration/inventory.networking* で使用されたインベントリーを編集し、以下のように追加することもできます。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:432 -#: ../../rst/dev_guide/testing.rst:37 -msgid ":ref:`testing_integration`" -msgstr ":ref:`testing_integration`" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:433 -msgid "Information on how to build integration tests." -msgstr "インテグレーションテストの構築方法に関する情報。" - -#: ../../rst/dev_guide/developing_modules_general_aci.rst:437 -msgid "Testing for test coverage" -msgstr "テストカバレージのテスト" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:5 -msgid "Windows module development walkthrough" -msgstr "Windows モジュールウォークスルー" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:7 -msgid "In this section, we will walk through developing, testing, and debugging an Ansible Windows module." -msgstr "本セクションでは、Ansible Windows モジュールの開発、テスト、デバッグの開発手順 (ウォークスルー) を説明します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:10 -msgid "Because Windows modules are written in Powershell and need to be run on a Windows host, this guide differs from the usual development walkthrough guide." -msgstr "Windows モジュールは Powershell で書かれており、Windows ホスト上で実行する必要があるため、このガイドは通常の開発ウォークスルーガイドとは異なります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:20 -msgid "Windows environment setup" -msgstr "Windows 環境の設定" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:22 -msgid "Unlike Python module development which can be run on the host that runs Ansible, Windows modules need to be written and tested for Windows hosts. While evaluation editions of Windows can be downloaded from Microsoft, these images are usually not ready to be used by Ansible without further modification. The easiest way to set up a Windows host so that it is ready to by used by Ansible is to set up a virtual machine using Vagrant. Vagrant can be used to download existing OS images called *boxes* that are then deployed to a hypervisor like VirtualBox. These boxes can either be created and stored offline or they can be downloaded from a central repository called Vagrant Cloud." -msgstr "Ansible を実行するホストで実行できる Python モジュール開発とは異なり、Windows ホスト用に Windows モジュールを作成およびテストする必要があります。Windows の評価エディションを Microsoft からダウンロードできますが、通常はこれらのイメージを追加の変更なしで Ansible で使用することはできません。Ansible で使用する準備が整うように Windows ホストを設定する最も簡単な方法は、Vagrant を使用して仮想マシンを設定することにあります。Vagrant を使用すると、*ボックス* と呼ばれる既存の OS イメージをダウンロードし、VirtualBox のようなハイパーバイザーにデプロイされます。これらのボックスは、オフラインで作成および保存するか、Vagrant Cloud と呼ばれる中央リポジトリーからダウンロードできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:33 -#, python-format -msgid "This guide will use the Vagrant boxes created by the `packer-windoze `_ repository which have also been uploaded to `Vagrant Cloud `_. To find out more info on how these images are created, please go to the GitHub repo and look at the ``README`` file." -msgstr "本ガイドでは、`packer-windoze `_ リポジトリーによって作成された Vagrant ボックスを使用します。これは、`Vagrant Cloud `_ にアップロードされました。これらの画像がどのように作成されるかについての詳細は、GitHub リポジトリーで ``README`` ファイルを確認してください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:38 -msgid "Before you can get started, the following programs must be installed (please consult the Vagrant and VirtualBox documentation for installation instructions):" -msgstr "作業を開始する前に、以下のプログラムをインストールする必要があります (インストール方法は Vagrant および VirtualBox のドキュメントを参照してください)。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:41 -msgid "Vagrant" -msgstr "Vagrant" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:42 -msgid "VirtualBox" -msgstr "VirtualBox" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:45 -msgid "Create a Windows server in a VM" -msgstr "仮想マシンで Windows サーバーを作成" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:47 -msgid "To create a single Windows Server 2016 instance, run the following:" -msgstr "1 つの Windows Server 2016 インスタンスを作成するには、次のコマンドを実行します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:54 -msgid "This will download the Vagrant box from Vagrant Cloud and add it to the local boxes on your host and then start up that instance in VirtualBox. When starting for the first time, the Windows VM will run through the sysprep process and then create a HTTP and HTTPS WinRM listener automatically. Vagrant will finish its process once the listeners are online, after which the VM can be used by Ansible." -msgstr "これにより、Vagrant Cloud から Vagrant ボックスをダウンロードし、ホストのローカルボックスに追加して、VirtualBox でそのインスタンスを起動します。初めて起動すると、Windows 仮想マシンが sysprep プロセスを介して実行し、HTTP および HTTPS WinRM リスナーを自動的に作成します。Vagrant は、リスナーがオンラインになるとプロセスを終了します。その後、仮想マシンを Ansible で使用できるようになります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:61 -msgid "Create an Ansible inventory" -msgstr "Ansible インベントリーの作成" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:63 -msgid "The following Ansible inventory file can be used to connect to the newly created Windows VM:" -msgstr "以下の Ansible インベントリーファイルを使用して、新しく作成した Windows 仮想マシンに接続できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:79 -msgid "The port ``55986`` is automatically forwarded by Vagrant to the Windows host that was created, if this conflicts with an existing local port then Vagrant will automatically use another one at random and display show that in the output." -msgstr "ポート ``55986`` は、Vagrant によって作成された Windows ホストに自動的に転送されます。これが既存のローカルポートと競合する場合、Vagrant は自動的に別のポートをランダムに使用し、出力にそれを表示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:84 -msgid "The OS that is created is based on the image set. The following images can be used:" -msgstr "作成される OS はイメージセットに基づいています。次のイメージを使用できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:87 -msgid "`jborean93/WindowsServer2008-x86 `_" -msgstr "`jborean93/WindowsServer2008-x86 `_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:88 -msgid "`jborean93/WindowsServer2008-x64 `_" -msgstr "`jborean93/WindowsServer2008-x64 `_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:89 -msgid "`jborean93/WindowsServer2008R2 `_" -msgstr "`jborean93/WindowsServer2008R2 `_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:90 -msgid "`jborean93/WindowsServer2012 `_" -msgstr "`jborean93/WindowsServer2012 `_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:91 -msgid "`jborean93/WindowsServer2012R2 `_" -msgstr "`jborean93/WindowsServer2012R2 `_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:92 -msgid "`jborean93/WindowsServer2016 `_" -msgstr "`jborean93/WindowsServer2016 `_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:94 -msgid "When the host is online, it can accessible by RDP on ``127.0.0.1:3389`` but the port may differ depending if there was a conflict. To get rid of the host, run ``vagrant destroy --force`` and Vagrant will automatically remove the VM and any other files associated with that VM." -msgstr "ホストがオンラインになったら、``127.0.0.1:3389`` で RDP からアクセスできますが、競合があったかどうかによってポートが異なる場合があります。ホストを取り除くには、``vagrant destroy --force`` を実行すると、Vagrant が、仮想マシンとその仮想マシンに関連付けられたその他のファイルを自動的に削除します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:99 -msgid "While this is useful when testing modules on a single Windows instance, these host won't work without modification with domain based modules. The Vagrantfile at `ansible-windows `_ can be used to create a test domain environment to be used in Ansible. This repo contains three files which are used by both Ansible and Vagrant to create multiple Windows hosts in a domain environment. These files are:" -msgstr "これは、単一の Windows インスタンスでモジュールをテストする際に役立ちますが、これらのホストはドメインベースのモジュールで変更せずに動作しません。`ansible-windows `_ の Vagrant を使用して、Ansible で使用するテストドメイン環境を作成できます。このリポジトリーには、Ansible と Vagrant で使用されている 3 つのファイルが含まれ、ドメイン環境で複数の Windows ホストを作成するのに使用できます。このファイルは、以下のようになります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:106 -msgid "``Vagrantfile``: The Vagrant file that reads the inventory setup of ``inventory.yml`` and provisions the hosts that are required" -msgstr "``Vagrantfile``: ``inventory.yml`` のインベントリー設定を読み込んで、必要なホストをプロビジョニングする Vagrant ファイルです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:107 -msgid "``inventory.yml``: Contains the hosts that are required and other connection information such as IP addresses and forwarded ports" -msgstr "``inventory.yml``: 必要なホストと、IP アドレスや転送ポートなどの他の接続情報が含まれています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:108 -msgid "``main.yml``: Ansible playbook called by Vagrant to provision the domain controller and join the child hosts to the domain" -msgstr "``main.yml``: Vagrant に呼び出された Ansible Playbook は、ドメインコントローラーをプロビジョニングし、子ホストをドメインに参加させます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:110 -msgid "By default, these files will create the following environment:" -msgstr "デフォルトでは、これらのファイルは以下の環境を作成します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:112 -msgid "A single domain controller running on Windows Server 2016" -msgstr "Windows Server 2016 で実行しているドメインコントローラー 1 つ" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:113 -msgid "Five child hosts for each major Windows Server version joined to that domain" -msgstr "ドメインに参加している各 Windows Server のメジャーバージョンの子ホスト 5 台" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:114 -msgid "A domain with the DNS name ``domain.local``" -msgstr "DNS 名 ``domain.local`` を持つドメイン" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:115 -msgid "A local administrator account on each host with the username ``vagrant`` and password ``vagrant``" -msgstr "各ホストのローカル管理者アカウント (ユーザー名 ``vagrant`` およびパスワード ``vagrant``)" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:116 -msgid "A domain admin account ``vagrant-domain@domain.local`` with the password ``VagrantPass1``" -msgstr "``VagrantPass1`` パスワードを含むドメイン管理者アカウント ``vagrant-domain@domain.local``" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:118 -msgid "The domain name and accounts can be modified by changing the variables ``domain_*`` in the ``inventory.yml`` file if it is required. The inventory file can also be modified to provision more or less servers by changing the hosts that are defined under the ``domain_children`` key. The host variable ``ansible_host`` is the private IP that will be assigned to the VirtualBox host only network adapter while ``vagrant_box`` is the box that will be used to create the VM." -msgstr "ドメイン名およびアカウントを変更するには、必要な場合に ``inventory.yml`` ファイルの変数 ``domain_*`` を変更することで変更できます。インベントリーファイルは、``domain_children`` キーで定義されるホストを変更して、より少ないサーバーをプロビジョニングするように変更することもできます。ホスト変数 ``ansible_host`` は、VirtualBox ホストに割り当てられるプライベート IP で、ネットワークアダプターのみに割り当てられますが、``vagrant_box`` は仮想マシンの作成に使用するボックスです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:127 -msgid "Provisioning the environment" -msgstr "環境のプロビジョニング" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:129 -msgid "To provision the environment as is, run the following:" -msgstr "そのまま環境をプロビジョニングするには、次を実行します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:137 -msgid "Vagrant provisions each host sequentially so this can take some time to complete. If any errors occur during the Ansible phase of setting up the domain, run ``vagrant provision`` to rerun just that step." -msgstr "Vagrant は各ホストを順番にプロビジョニングするため、完了するまでに時間がかかる場合があります。ドメイン設定の Ansible フェーズ中にエラーが発生した場合は、``vagrant provision`` を実行してそのステップだけを再実行します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:141 -msgid "Unlike setting up a single Windows instance with Vagrant, these hosts can also be accessed using the IP address directly as well as through the forwarded ports. It is easier to access it over the host only network adapter as the normal protocol ports are used, for example RDP is still over ``3389``. In cases where the host cannot be resolved using the host only network IP, the following protocols can be access over ``127.0.0.1`` using these forwarded ports:" -msgstr "Vagrant で単一の Windows インスタンスをセットアップするのとは異なり、これらのホストは、転送されたポートを介してだけでなく、IP アドレスを使用して直接アクセスすることもできます。ホストのみのネットワークアダプターを使用してアクセスする方が、通常のプロトコルのポートが使用されるため簡単です。たとえば、RDP はまだ ``3389`` でした。ホストのみのネットワーク IP を使用してホストを解決できない場合、以下のプロトコルは、これらの転送されたポートを使用して ``127.0.0.1`` を介してアクセスできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:148 -msgid "``RDP``: 295xx" -msgstr "``RDP``: 295xx" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:149 -msgid "``SSH``: 296xx" -msgstr "``SSH``: 296xx" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:150 -msgid "``WinRM HTTP``: 297xx" -msgstr "``WinRM HTTP``: 297xx" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:151 -msgid "``WinRM HTTPS``: 298xx" -msgstr "``WinRM HTTPS``: 298xx" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:152 -msgid "``SMB``: 299xx" -msgstr "``SMB``: 299xx" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:154 -msgid "Replace ``xx`` with the entry number in the inventory file where the domain controller started with ``00`` and is incremented from there. For example, in the default ``inventory.yml`` file, WinRM over HTTPS for ``SERVER2012R2`` is forwarded over port ``29804`` as it's the fourth entry in ``domain_children``." -msgstr "``xx`` を、ドメインコントローラーが ``00`` から開始したインベントリーファイルのエントリー番号で、インクリメントされていきます。たとえば、デフォルトでは、``domain_children`` の 4番目のエントリーであるため、``inventory.yml``ファイル (WinRM over HTTPS for ``SERVER2012R2``) がポート ``29804`` 経由で転送されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:159 -msgid "While an SSH server is available on all Windows hosts but Server 2008 (non R2), it is not a support connection for Ansible managing Windows hosts and should not be used with Ansible." -msgstr "SSH サーバーはすべての Windows ホストで利用できますが、Server 2008 (R2 以外) は、Ansible による Windows ホストの管理接続ではなく、Ansible では使用できません。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:164 -msgid "Windows new module development" -msgstr "Windows 新しいモジュール開発" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:166 -msgid "When creating a new module there are a few things to keep in mind:" -msgstr "新しいモジュールを作成する際には、以下の点に留意してください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:168 -msgid "Module code is in Powershell (.ps1) files while the documentation is contained in Python (.py) files of the same name" -msgstr "モジュールのコードは Powershell (.ps1) ファイルにあり、ドキュメントは同じ名前の Python (.py) ファイルに含まれています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:169 -msgid "Avoid using ``Write-Host/Debug/Verbose/Error`` in the module and add what needs to be returned to the ``$module.Result`` variable" -msgstr "モジュールでは ``Write-Host/Debug/Verbose/Error`` を使用せず、``$module.Result`` 変数に返す必要のあるものを追加します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:170 -msgid "To fail a module, call ``$module.FailJson(\"failure message here\")``, an Exception or ErrorRecord can be set to the second argument for a more descriptive error message" -msgstr "モジュールを失敗させるには、``$module.FailJson(\"failure message here\")`` を呼び出して、Exception または ErrorRecord を 2 番目の引数に設定して、より詳細なエラーメッセージを表示できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:171 -msgid "You can pass in the exception or ErrorRecord as a second argument to ``FailJson(\"failure\", $_)`` to get a more detailed output" -msgstr "例外または ErrorRecord を 2 つ目の引数として ``FailJson(\"failure\", $_)`` に渡すと、より詳細な出力を取得できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:172 -msgid "Most new modules require check mode and integration tests before they are merged into the main Ansible codebase" -msgstr "ほとんどの新規モジュールには、主要な Ansible コードベースにマージする前にチェックモードと統合テストが必要です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:173 -msgid "Avoid using try/catch statements over a large code block, rather use them for individual calls so the error message can be more descriptive" -msgstr "大規模なコードブロックで try/catch 文を使用するのは避け、個別の呼び出しに使用することで、エラーメッセージがより分かりやすくなるようにします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:174 -msgid "Try and catch specific exceptions when using try/catch statements" -msgstr "Try/catch 文の使用時に特定の例外を試して捕え (キャッチし) ます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:175 -msgid "Avoid using PSCustomObjects unless necessary" -msgstr "必要な場合を除き PSCustomObject は使用しないでください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:176 -msgid "Look for common functions in ``./lib/ansible/module_utils/powershell/`` and use the code there instead of duplicating work. These can be imported by adding the line ``#Requires -Module *`` where * is the filename to import, and will be automatically included with the module code sent to the Windows target when run via Ansible" -msgstr "重複する作業を行わないように、``./lib/ansible/module_utils/powershell/`` にある共通の関数を探して、そこにあるコードを使用してください。これらの関数は ``#Requires -Module *`` という行を追加することでインポートすることができます。* はインポートするファイル名で、Ansible を介して実行する場合に、自動的に Windows ターゲットに送信されたモジュールコードが含まれています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:177 -msgid "As well as PowerShell module utils, C# module utils are stored in ``./lib/ansible/module_utils/csharp/`` and are automatically imported in a module execution if the line ``#AnsibleRequires -CSharpUtil *`` is present" -msgstr "PowerShell モジュールユーティリティーの他に、C# モジュールユーティリティーが ``./lib/ansible/module_utils/csharp/`` にあります。これは、``#AnsibleRequires -CSharpUtil *`` 行が存在する場合に、モジュール実行に自動的にインポートされます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:178 -msgid "C# and PowerShell module utils achieve the same goal but C# allows a developer to implement low level tasks, such as calling the Win32 API, and can be faster in some cases" -msgstr "C# と PowerShell モジュールのユーティリティーは同じ目標を達成しますが、C# を使用すると、開発者は Win32 API の呼び出しなどの低レベルのタスクを実装でき、場合によってはより高速になります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:179 -msgid "Ensure the code runs under Powershell v3 and higher on Windows Server 2008 and higher; if higher minimum Powershell or OS versions are required, ensure the documentation reflects this clearly" -msgstr "このコードが Windows Server 2008 以降の Powershell v3 以降で動作することを確認してください。最小バージョンより新しい Powershell または OS が必要な場合は、ドキュメントにこの内容が明確に反映されていることを確認してください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:180 -msgid "Ansible runs modules under strictmode version 2.0. Be sure to test with that enabled by putting ``Set-StrictMode -Version 2.0`` at the top of your dev script" -msgstr "Ansible は、strictmode バージョン 2.0 でモジュールを実行します。必ず、開発スクリプトの先頭に ``Set-StrictMode -Version 2.0`` と記述して、この機能を有効にしてテストしてください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:181 -msgid "Favor native Powershell cmdlets over executable calls if possible" -msgstr "可能であれば、実行可能な呼び出しよりも、ネイティブの Powershell コマンドレットを優先してください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:182 -msgid "Use the full cmdlet name instead of aliases, for example ``Remove-Item`` over ``rm``" -msgstr "エイリアスの代わりに完全なコマンドレット名を使用してください (例: ``rm`` ではなく ``Remove-Item``)。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:183 -msgid "Use named parameters with cmdlets, for example ``Remove-Item -Path C:\\temp`` over ``Remove-Item C:\\temp``" -msgstr "コマンドレットで名前付きパラメーターを使用します (例： ``Remove-Item C:\\temp`` より ``Remove-Item -Path C:\\temp`` を使用)。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:185 -msgid "A very basic Powershell module `win_environment `_ incorporates best practices for Powershell modules. It demonstrates how to implement check-mode and diff-support, and also shows a warning to the user when a specific condition is met." -msgstr "非常に基本的な Powershell モジュール `win_environment `_ が、Powershell モジュールのベストプラクティスが組み込まれています。これは、check-mode および diff-support を実装する方法を示し、特定の条件が満たされるとユーザーに警告を表示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:187 -msgid "A slightly more advanced module is `win_uri `_ which additionally shows how to use different parameter types (bool, str, int, list, dict, path) and a selection of choices for parameters, how to fail a module and how to handle exceptions." -msgstr "もう少し高度なモジュールとしては `win_uri `_ がありますが、ここで、さまざまなパラメーター型 (bool、str、int、list、dict、path) の使用方法やパラメーターの選択方法、モジュールを失敗させる方法、例外の処理方法などを紹介しています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:189 -msgid "As part of the new ``AnsibleModule`` wrapper, the input parameters are defined and validated based on an argument spec. The following options can be set at the root level of the argument spec:" -msgstr "新しい ``AnsibleModule`` ラッパーの一部として、入力パラメーターは引数の仕様に基づいて定義および検証されます。以下のオプションは、引数仕様のルートレベルで設定できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:192 -msgid "``mutually_exclusive``: A list of lists, where the inner list contains module options that cannot be set together" -msgstr "``mutually_exclusive``: リストのリストで、内側のリストには一緒に設定できないモジュールオプションが含まれています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:193 -msgid "``no_log``: Stops the module from emitting any logs to the Windows Event log" -msgstr "``no_log``: モジュールが Windows イベントログにログを出力しないようにします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:194 -msgid "``options``: A dictionary where the key is the module option and the value is the spec for that option" -msgstr "``options``: キーがモジュールオプションで、値がそのオプションの仕様となるディクショナリーです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:195 -msgid "``required_by``: A dictionary where the option(s) specified by the value must be set if the option specified by the key is also set" -msgstr "``required_by``: キーで指定されたオプションが設定されている場合に、値で指定されたオプションも設定しなければならないディクショナリーです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:199 -msgid "``required_if``: A list of lists where the inner list contains 3 or 4 elements;" -msgstr "``required_if``: 内部リストに 3 つまたは 4 つの要素が含まれるリストの一覧" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:197 -msgid "The first element is the module option to check the value against" -msgstr "最初の要素は、値を確認するモジュールオプションです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:198 -msgid "The second element is the value of the option specified by the first element, if matched then the required if check is run" -msgstr "2 つ目の要素は、1 つ目の要素によって指定されるオプションの値です。一致すると必須の if チェックが実行します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:199 -msgid "The third element is a list of required module options when the above is matched" -msgstr "3 つ目の要素は、上記が一致した場合に必要なモジュールオプションのリストです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:200 -msgid "An optional fourth element is a boolean that states whether all module options in the third elements are required (default: ``$false``) or only one (``$true``)" -msgstr "4 番目の要素 (任意) は、3 番目の要素のすべてのモジュールオプションが必要なのか (デフォルト: ``$false``)、1 つだけが必要なのか (``$true``) を示すブール値です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:201 -msgid "``required_one_of``: A list of lists, where the inner list contains module options where at least one must be set" -msgstr "``required_one_of``: 少なくとも 1 つは設定しなければならないモジュールオプションが含まれているリストが記載されるリストです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:202 -msgid "``required_together``: A list of lists, where the inner list contains module options that must be set together" -msgstr "``required_together``: 一緒に設定しなければならないモジュールオプションが含まれているリストが記載されるリストです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:203 -msgid "``supports_check_mode``: Whether the module supports check mode, by default this is ``$false``" -msgstr "``supports_check_mode``: モジュールがチェックモードに対応しているかどうか (デフォルトは ``$false`` です) を指定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:205 -msgid "The actual input options for a module are set within the ``options`` value as a dictionary. The keys of this dictionary are the module option names while the values are the spec of that module option. Each spec can have the following options set:" -msgstr "モジュールの実際の入力オプションは、ディクショナリーとなる ``options`` 値に設定されています。このディクショナリーのキーはモジュールオプション名であり、値はそのモジュールオプションの仕様です。各仕様には、次のオプションを設定できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:209 -msgid "``aliases``: A list of aliases for the module option" -msgstr "``aliases``: モジュールオプションのエイリアス一覧" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:210 -msgid "``choices``: A list of valid values for the module option, if ``type=list`` then each list value is validated against the choices and not the list itself" -msgstr "``choices``: モジュールオプションの有効な値のリストです。``type=list`` の場合は、各リストの値が choices に対して検証され、リスト自体は検証されません。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:211 -msgid "``default``: The default value for the module option if not set" -msgstr "``default``: モジュールオプションのデフォルト値 (設定されていない場合) です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:212 -msgid "``deprecated_aliases``: A list of hashtables that define aliases that are deprecated and the versions they will be removed in. Each entry must contain the keys ``name`` and ``collection_name`` with either ``version`` or ``date``" -msgstr "``deprecated_aliases``: 非推奨となるエイリアスとそれらが削除されるバージョンを定義するハッシュテーブルの一覧。各エントリーには、``version`` または ``date`` がある ``name`` キーと ``collection_name`` が含まれている必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:213 -msgid "``elements``: When ``type=list``, this sets the type of each list value, the values are the same as ``type``" -msgstr "``elements``: ``type=list`` の場合は、各リスト値のタイプが設定され、値は ``type`` と同じになります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:214 -msgid "``no_log``: Will sanitise the input value before being returned in the ``module_invocation`` return value" -msgstr "``no_log``: ``module_invocation`` 戻り値で返される前に入力値をサニタイズします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:215 -msgid "``removed_in_version``: States when a deprecated module option is to be removed, a warning is displayed to the end user if set" -msgstr "``removed_in_version``: 非推奨のモジュールオプションを削除すると、警告が設定されている場合はエンドユーザーに警告が表示されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:216 -msgid "``removed_at_date``: States the date (YYYY-MM-DD) when a deprecated module option will be removed, a warning is displayed to the end user if set" -msgstr "``removed_at_date``: 非推奨のモジュールオプションが削除される日付 (YYYY-MM-DD) を示します。これが設定されている場合は、警告がエンドユーザーに表示されます" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:217 -msgid "``removed_from_collection``: States from which collection the deprecated module option will be removed; must be specified if one of ``removed_in_version`` and ``removed_at_date`` is specified" -msgstr "``removed_from_collection``: 非推奨のモジュールオプションを削除するコレクションの状態。``removed_in_version`` および ``removed_at_date`` のいずれかが指定されている場合は指定する必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:218 -msgid "``required``: Will fail when the module option is not set" -msgstr "``required``: モジュールオプションが設定されていない場合は失敗します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:229 -msgid "``type``: The type of the module option, if not set then it defaults to ``str``. The valid types are;" -msgstr "``type``: モジュールオプションのタイプです。設定されていない場合は、デフォルトで ``str`` に設定されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:220 -msgid "``bool``: A boolean value" -msgstr "``bool``: ブール値です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:221 -msgid "``dict``: A dictionary value, if the input is a JSON or key=value string then it is converted to dictionary" -msgstr "``dict``: ディクショナリーの値です。入力が JSON または key=value 文字列の場合は、ディクショナリーに変換されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:222 -msgid "``float``: A float or `Single `_ value" -msgstr "``float``: 浮動 または `Single `_ の値" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:223 -msgid "``int``: An Int32 value" -msgstr "``int``: Int32 値です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:224 -msgid "``json``: A string where the value is converted to a JSON string if the input is a dictionary" -msgstr "``json``: 入力がディクショナリーである場合に値が JSON 文字列に変換される文字列です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:225 -msgid "``list``: A list of values, ``elements=`` can convert the individual list value types if set. If ``elements=dict`` then ``options`` is defined, the values will be validated against the argument spec. When the input is a string then the string is split by ``,`` and any whitespace is trimmed" -msgstr "``list``: 値の一覧 (``elements=``) が設定されている場合は、個々のリスト値タイプを変換できます。``elements=dict`` で、``options``が定義されている場合、値は引数の仕様に対して検証されます。入力が文字列である場合、文字列は ``,`` で分割され、空白文字はすべてトリミングされます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:226 -msgid "``path``: A string where values likes ``%TEMP%`` are expanded based on environment values. If the input value starts with ``\\\\?\\`` then no expansion is run" -msgstr "``path``: ``%TEMP%`` などの値が環境値に基づいて展開される文字列です。入力値が ``\\\\?\\`` で始まると、展開は実行されません。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:227 -msgid "``raw``: No conversions occur on the value passed in by Ansible" -msgstr "``raw``: Ansible によって渡される値で変換が行われません。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:228 -msgid "``sid``: Will convert Windows security identifier values or Windows account names to a `SecurityIdentifier `_ value" -msgstr "``sid``: Windows セキュリティー識別子の値または Windows アカウント名を `SecurityIdentifier `_ 値に変換します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:229 -msgid "``str``: The value is converted to a string" -msgstr "``str``: この値は文字列に変換されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:231 -msgid "When ``type=dict``, or ``type=list`` and ``elements=dict``, the following keys can also be set for that module option:" -msgstr "``type=dict`` または ``type=list`` および ``elements=dict`` の場合は、そのモジュールオプションに以下のキーを設定することもできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:233 -msgid "``apply_defaults``: The value is based on the ``options`` spec defaults for that key if ``True`` and null if ``False``. Only valid when the module option is not defined by the user and ``type=dict``." -msgstr "``apply_defaults``: この値は、``True`` の場合はそのキーの ``options`` 仕様のデフォルトになり、``False`` の場合は null です。モジュールオプションがユーザーによって定義されておらず、``type=dict`` の場合に限り有効です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:234 -msgid "``mutually_exclusive``: Same as the root level ``mutually_exclusive`` but validated against the values in the sub dict" -msgstr "``mutually_exclusive``: ルートレベルの ``mutually_exclusive`` と同じですが、サブディクショナリーの値に対して検証されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:235 -msgid "``options``: Same as the root level ``options`` but contains the valid options for the sub option" -msgstr "``options``: ルートレベルの ``options`` と同じですが、サブオプションの有効なオプションが含まれています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:236 -msgid "``required_if``: Same as the root level ``required_if`` but validated against the values in the sub dict" -msgstr "``required_if``: ルートレベルの ``required_if`` と同じですが、サブディクショナリーの値に対して検証されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:237 -msgid "``required_by``: Same as the root level ``required_by`` but validated against the values in the sub dict" -msgstr "``required_by``: ルートレベルの ``required_by`` と同じですが、サブディクショナリーの値に対して検証されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:238 -msgid "``required_together``: Same as the root level ``required_together`` but validated against the values in the sub dict" -msgstr "``required_together``: ルートレベルの ``required_together`` と同じですが、サブディクショナリーの値に対して検証されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:239 -msgid "``required_one_of``: Same as the root level ``required_one_of`` but validated against the values in the sub dict" -msgstr "``required_one_of``: ルートレベルの ``required_one_of`` と同じですが、サブディクショナリーの値に対して検証されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:241 -msgid "A module type can also be a delegate function that converts the value to whatever is required by the module option. For example the following snippet shows how to create a custom type that creates a ``UInt64`` value:" -msgstr "モジュール型は、値をモジュールオプションで必要とされるものに変換するデリゲート関数にすることもできます。次のスニペットの例は、``UInt64`` 値を作成するカスタム型を作成する方法を示しています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:251 -msgid "When in doubt, look at some of the other core modules and see how things have been implemented there." -msgstr "不明な場合は、他のコアモジュールを見て、そこにどのように実装されているかを見てみましょう。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:254 -msgid "Sometimes there are multiple ways that Windows offers to complete a task; this is the order to favor when writing modules:" -msgstr "Windows がタスクを完了させるために、複数の方法が提示されることがあります。モジュールを書くときに好ましい順序は以下のようになります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:257 -msgid "Native Powershell cmdlets like ``Remove-Item -Path C:\\temp -Recurse``" -msgstr "``Remove-Item -Path C:\\temp -Recurse`` などのネイティブの Powershell コマンドレッド" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:258 -msgid ".NET classes like ``[System.IO.Path]::GetRandomFileName()``" -msgstr "``[System.IO.Path]::GetRandomFileName()`` などの .NET クラス" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:259 -msgid "WMI objects through the ``New-CimInstance`` cmdlet" -msgstr "``New-CimInstance`` コマンドレッド経由の WMI オブジェクト" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:260 -msgid "COM objects through ``New-Object -ComObject`` cmdlet" -msgstr "``New-Object -ComObject`` cmdlet 経由の COM オブジェクト" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:261 -msgid "Calls to native executables like ``Secedit.exe``" -msgstr "``Secedit.exe``など、ネイティブ実行可能ファイルへの呼び出し" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:263 -msgid "PowerShell modules support a small subset of the ``#Requires`` options built into PowerShell as well as some Ansible-specific requirements specified by ``#AnsibleRequires``. These statements can be placed at any point in the script, but are most commonly near the top. They are used to make it easier to state the requirements of the module without writing any of the checks. Each ``requires`` statement must be on its own line, but there can be multiple requires statements in one script." -msgstr "PowerShell モジュールは、PowerShell に組み込まれている ``#Requires`` オプションの小さなサブセットと、``#AnsibleRequires`` で指定されている Ansible 固有の要件をサポートしています。これらのステートメントは、スクリプトの任意の位置に配置できますが、最も一般的なのは先頭付近です。これらのステートメントは、チェック項目を記述することなく、モジュールの要件を簡単に記述するために使用されます。``requires`` ステートメントはそれぞれ1行に書かなければなりませんが、1 つのスクリプトに複数の requires ステートメントを記述することができます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:271 -msgid "These are the checks that can be used within Ansible modules:" -msgstr "以下のチェックは、Ansible モジュール内で使用できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:273 -msgid "``#Requires -Module Ansible.ModuleUtils.``: Added in Ansible 2.4, specifies a module_util to load in for the module execution." -msgstr "``#Requires -Module Ansible.ModuleUtils.``: Ansible 2.4 で追加され、モジュール実行のために読み込む module_util を指定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:274 -msgid "``#Requires -Version x.y``: Added in Ansible 2.5, specifies the version of PowerShell that is required by the module. The module will fail if this requirement is not met." -msgstr "``#Requires -Version x.y``: Ansible 2.5 で追加され、モジュールが必要とする PowerShell バージョンを指定します。この要件を満たしていない場合は失敗します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:275 -msgid "``#AnsibleRequires -OSVersion x.y``: Added in Ansible 2.5, specifies the OS build version that is required by the module and will fail if this requirement is not met. The actual OS version is derived from ``[Environment]::OSVersion.Version``." -msgstr "``#AnsibleRequires -OSVersion x.y``: Ansible 2.5 で追加され、モジュールが必要とする OS ビルドバージョンを指定します。この要件を満たしていない場合は失敗します。実際の OS バージョンは ``[Environment]::OSVersion.Version`` から由来します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:276 -msgid "``#AnsibleRequires -Become``: Added in Ansible 2.5, forces the exec runner to run the module with ``become``, which is primarily used to bypass WinRM restrictions. If ``ansible_become_user`` is not specified then the ``SYSTEM`` account is used instead." -msgstr "``#AnsibleRequires -Become``: Ansible 2.5 で追加され、exec ランナーが ``become`` でモジュールを強制的に実行します。これは主に WinRM の制限を回避するために使用されます。``ansible_become_user`` が指定されていない場合は、代わりに ``SYSTEM`` アカウントが使用されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:277 -msgid "``#AnsibleRequires -CSharpUtil Ansible.``: Added in Ansible 2.8, specifies a C# module_util to load in for the module execution." -msgstr "``#AnsibleRequires -CSharpUtil Ansible.``: Ansible 2.8 で追加され、モジュール実行のために読み込む C# module_util を指定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:279 -msgid "C# module utils can reference other C# utils by adding the line ``using Ansible.;`` to the top of the script with all the other using statements." -msgstr "C# モジュールユーティリティーは、すべてのステートメントを使用し、スクリプトの上部に ``using Ansible.;`` 行を追加することで、他の C# ユーティリティーを参照できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:285 -msgid "Windows module utilities" -msgstr "Windows モジュールユーティリティー" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:287 -msgid "Like Python modules, PowerShell modules also provide a number of module utilities that provide helper functions within PowerShell. These module_utils can be imported by adding the following line to a PowerShell module:" -msgstr "Python モジュールと同様に、PowerShell モジュールは、PowerShell でヘルパー関数を提供する多くのモジュールユーティリティーを提供します。これらのモジュールユーティリティーは、以下の行を PowerShell モジュールに追加してインポートできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:295 -msgid "This will import the module_util at ``./lib/ansible/module_utils/powershell/Ansible.ModuleUtils.Legacy.psm1`` and enable calling all of its functions. As of Ansible 2.8, Windows module utils can also be written in C# and stored at ``lib/ansible/module_utils/csharp``. These module_utils can be imported by adding the following line to a PowerShell module:" -msgstr "これにより、モジュールユーティリティーが ``./lib/ansible/module_utils/powershell/Ansible.ModuleUtils.Legacy.psm1`` でインポートされ、すべての関数の呼び出しが可能になります。Ansible 2.8 と同様に、Windows モジュールユーティリティーは C# でも記述でき、``lib/ansible/module_utils/csharp`` に保存されます。これらのモジュールユーティリティーは、PowerShell モジュールに以下の行を追加することでインポートできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:305 -msgid "This will import the module_util at ``./lib/ansible/module_utils/csharp/Ansible.Basic.cs`` and automatically load the types in the executing process. C# module utils can reference each other and be loaded together by adding the following line to the using statements at the top of the util:" -msgstr "これにより、``./lib/ansible/module_utils/csharp/Ansible.Basic.cs`` でモジュールユーティリティーがインポートされ、実行中のプロセスでタイプが自動的に読み込まれます。C# モジュールユーティリティーは相互に参照でき、次の行を、ユーティリティーの上部にある using ステートメントに追加して読み込むことができます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:314 -msgid "There are special comments that can be set in a C# file for controlling the compilation parameters. The following comments can be added to the script;" -msgstr "コンパイルパラメーターを制御するために C# ファイルに設定できる特別なコメントがあります。以下のコメントをスクリプトに追加できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:317 -msgid "``//AssemblyReference -Name [-CLR [Core|Framework]]``: The assembly DLL to reference during compilation, the optional ``-CLR`` flag can also be used to state whether to reference when running under .NET Core, Framework, or both (if omitted)" -msgstr "``//AssemblyReference -Name [-CLR [Core|Framework]]``: コンパイル中に参照するアセンブリー DLL です。任意の ``-CLR`` フラグを使用して、.NET Core、Framework、またはその両方 (省略されている場合) で実行するときに参照するかどうかを表示することもできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:318 -msgid "``//NoWarn -Name [-CLR [Core|Framework]]``: A compiler warning ID to ignore when compiling the code, the optional ``-CLR`` works the same as above. A list of warnings can be found at `Compiler errors `_" -msgstr "``//NoWarn -Name [-CLR [Core|Framework]]``: コードをコンパイルするときに無視するコンパイラ警告 ID で、任意の ``-CLR`` が上記と同じように機能します。警告のリストは、`コンパイラーエラー `_ で見つけることができます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:320 -msgid "As well as this, the following pre-processor symbols are defined;" -msgstr "この他に、以下のプリプロセッサーシンボルも定義されています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:322 -msgid "``CORECLR``: This symbol is present when PowerShell is running through .NET Core" -msgstr "``CORECLR``: このシンボルは、PowerShell が .NET Core を介して実行されている場合に表示されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:323 -msgid "``WINDOWS``: This symbol is present when PowerShell is running on Windows" -msgstr "``WINDOWS``: このシンボルは、PowerShell が Windows で実行している場合に表示されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:324 -msgid "``UNIX``: This symbol is present when PowerShell is running on Unix" -msgstr "``UNIX``: このシンボルは、PowerShell が Unix で実行している場合に表示されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:326 -msgid "A combination of these flags help to make a module util interoperable on both .NET Framework and .NET Core, here is an example of them in action:" -msgstr "これフラグの組み合わせは、.NET Framework と .NET Core の両方でモジュールユーティリティーを相互運用可能にするのに役立ちます。以下に、実際の動作例を示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:347 -msgid "The following is a list of module_utils that are packaged with Ansible and a general description of what they do:" -msgstr "以下に Ansible と一緒にパッケージ化されている module_utils リストと、それらの機能の一般的な説明です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:350 -msgid "ArgvParser: Utility used to convert a list of arguments to an escaped string compliant with the Windows argument parsing rules." -msgstr "ArgvParser: 引数のリストを Windows の引数解析ルールに準拠しているエスケープされた文字列に変換するのに使用されるユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:351 -msgid "CamelConversion: Utility used to convert camelCase strings/lists/dicts to snake_case." -msgstr "CamelConversion: camelCase strings/lists/dicts を snake_case に変換するのに使用されるユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:352 -msgid "CommandUtil: Utility used to execute a Windows process and return the stdout/stderr and rc as separate objects." -msgstr "CommandUtil: Windows プロセスを実行し、stdout/stderr と rc を異なるオブジェクトとして返すために使用されるユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:353 -msgid "FileUtil: Utility that expands on the ``Get-ChildItem`` and ``Test-Path`` to work with special files like ``C:\\pagefile.sys``." -msgstr "FileUtil: ``C:\\pagefile.sys`` のような特殊なファイルを扱うために ``Get-ChildItem`` および ``Test-Path`` を拡張するユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:354 -msgid "Legacy: General definitions and helper utilities for Ansible module." -msgstr "Legacy: Ansible モジュールの一般的な定義およびヘルパーユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:355 -msgid "LinkUtil: Utility to create, remove, and get information about symbolic links, junction points and hard inks." -msgstr "LinkUtil: シンボリックリンク、分岐点、ハードインクに関する情報を作成、削除、取得するユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:356 -msgid "SID: Utilities used to convert a user or group to a Windows SID and vice versa." -msgstr "SID: ユーザーやグループを Windows SID に変換したり、Windows SID をユーザーやグループに変換するのに使用するユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:358 -msgid "For more details on any specific module utility and their requirements, please see the `Ansible module utilities source code `_." -msgstr "特定のモジュールユーティリティーとその要件に関する詳細は、`Ansible モジュールユーティリティーのソースコード `_ を参照してください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:361 -msgid "PowerShell module utilities can be stored outside of the standard Ansible distribution for use with custom modules. Custom module_utils are placed in a folder called ``module_utils`` located in the root folder of the playbook or role directory." -msgstr "PowerShell モジュールユーティリティーは、カスタムモジュールで使用する標準の Ansible ディストリビューション外に保存できます。カスタムのモジュールユーティリティーは、Playbook またはロールディレクトリーのルートディレクトリーにある ``module_utils`` と呼ばれるディレクトリーに配置されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:366 -msgid "C# module utilities can also be stored outside of the standard Ansible distribution for use with custom modules. Like PowerShell utils, these are stored in a folder called ``module_utils`` and the filename must end in the extension ``.cs``, start with ``Ansible.`` and be named after the namespace defined in the util." -msgstr "C# モジュールユーティリティーは、カスタムモジュールで使用するための標準の Ansible ディストリビューション外にも保存できます。PowerShellutils と同様、``module_utils`` ディレクトリーに格納され、ファイル名は ``.cs`` で終わり、``Ansible.`` で始まる、ユーティリティーで定義された名前空間の後に名前を指定する必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:370 -msgid "The below example is a role structure that contains two PowerShell custom module_utils called ``Ansible.ModuleUtils.ModuleUtil1``, ``Ansible.ModuleUtils.ModuleUtil2``, and a C# util containing the namespace ``Ansible.CustomUtil``::" -msgstr "次の例は、呼び出された 2 つの PowerShell のカスタム module_utils (``Ansible.ModuleUtils.ModuleUtil1``、``Ansible.ModuleUtils.ModuleUtil2``、および名前空間を含むC# ユーティリティー ``Ansible.CustomUtil``) を含むロール構造です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:385 -msgid "Each PowerShell module_util must contain at least one function that has been exported with ``Export-ModuleMember`` at the end of the file. For example" -msgstr "PowerShell の各 module_util には、ファイルの終わりに ``Export-ModuleMember`` でエクスポートされた関数が少なくとも 1 つ含まれている必要があります。以下に例を示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:394 -msgid "Exposing shared module options" -msgstr "共有モジュールオプションの公開" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:396 -msgid "PowerShell module utils can easily expose common module options that a module can use when building its argument spec. This allows common features to be stored and maintained in one location and have those features used by multiple modules with minimal effort. Any new features or bugfixes added to one of these utils are then automatically used by the various modules that call that util." -msgstr "PowerShell モジュールユーティリティーは、引数仕様を構築する際にモジュールが使用できる共通のモジュールオプションを簡単に公開できます。これにより、共通の機能は 1 つの場所に保存および維持でき、最小限の作業で複数のモジュールによって使用される機能を利用できます。これらのユーティリティーのいずれかに追加された新機能またはバグ修正は、そのユーティリティーのいずれかを呼び出すさまざまなモジュールによって自動的に使用されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:401 -msgid "An example of this would be to have a module util that handles authentication and communication against an API This util can be used by multiple modules to expose a common set of module options like the API endpoint, username, password, timeout, cert validation, and so on without having to add those options to each module spec." -msgstr "この例としては、認証と API に対する通信を処理するモジュールユーティリティーがあります。このユーティリティーは、API エンドポイント、ユーザー名、パスワード、タイムアウト、認定検証などの共通のモジュールオプションセットを公開するため、各モジュール仕様にそれらのオプションを追加しなくても、複数のモジュールによって使用できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:405 -msgid "The standard convention for a module util that has a shared argument spec would have" -msgstr "共有の引数仕様を持つモジュールユーティリティーの標準規則" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:408 -msgid "A ``Get-Spec`` function that outputs the common spec for a module" -msgstr "モジュールの共通の仕様を出力する ``Get-Spec`` 関数" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:408 -msgid "It is highly recommended to make this function name be unique to the module to avoid any conflicts with other utils that can be loaded" -msgstr "読み込みできる他のユーティリティーとの競合を避けるために、この関数名をモジュールに固有のものに強く推奨します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:409 -msgid "The format of the output spec is a Hashtable in the same format as the ``$spec`` used for normal modules" -msgstr "出力仕様の形式は、通常のモジュールに使用される ``$spec`` と同じ形式のハッシュテーブルです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:410 -msgid "A function that takes in an ``AnsibleModule`` object called under the ``-Module`` parameter which it can use to get the shared options" -msgstr "``-Module`` パラメーター下で呼び出された ``AnsibleModule`` オブジェクトを取り入れた関数。これを使用して共有オプションを取得できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:412 -msgid "Because these options can be shared across various module it is highly recommended to keep the module option names and aliases in the shared spec as specific as they can be. For example do not have a util option called ``password``, rather you should prefix it with a unique name like ``acme_password``." -msgstr "これらのオプションは各種モジュール間で共有できるため、モジュールオプション名とエイリアスを、可能な限り具体的な仕様に維持することを推奨します。たとえば、``password`` ユーティリティーオプションがありません。たとえば、``acme_password`` などの一意の名前でプレフィックスを付けるべきではありません。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:417 -msgid "Failure to have a unique option name or alias can prevent the util being used by module that also use those names or aliases for its own options." -msgstr "一意のオプション名またはエイリアスがないと、モジュールがユーティリティーを使用できなくなり、モジュールがそれらの名前またはエイリアスを独自のオプションに使用する可能性があります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:420 -msgid "The following is an example module util called ``ServiceAuth.psm1`` in a collection that implements a common way for modules to authentication with a service." -msgstr "以下は、コレクションで ``ServiceAuth.psm1`` モジュールユーティリティーの例になります。このモジュールは、サービスを使用した認証に共通の方法を実装します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:476 -msgid "For a module to take advantage of this common argument spec it can be set out like" -msgstr "モジュールがこの共通の引数仕様を利用できるようにするには、以下のように設定できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:503 -msgid "Options defined in the module spec will always have precedence over a util spec. Any list values under the same key in a util spec will be appended to the module spec for that same key. Dictionary values will add any keys that are missing from the module spec and merge any values that are lists or dictionaries. This is similar to how the doc fragment plugins work when extending module documentation." -msgstr "モジュール仕様に定義されているオプションは常にユーティリティー仕様よりも優先されます。ユーティリティー仕様の同じキー下のリスト値は、同じキーのモジュール仕様に追加されます。ディクショナリーの値は、モジュール仕様に不足している鍵を追加し、リストまたはディクショナリーである値をマージします。これは、モジュールドキュメントを拡張するときにドキュメントフラグメントプラグインがどのように機能するかと似ています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:508 -msgid "To document these shared util options for a module, create a doc fragment plugin that documents the options implemented by the module util and extend the module docs for every module that implements the util to include that fragment in its docs." -msgstr "モジュールのこれらの共有ユーティリティーオプションを文書化するには、モジュールユーティリティーによって実装されたオプションを文書化するドキュメントフラグメントプラグインを作成し、ユーティリティーを実装するすべてのモジュールのモジュールドキュメントを拡張して、そのフラグメントをドキュメントに含めます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:514 -msgid "Windows playbook module testing" -msgstr "Windows Playbook モジュールのテスト" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:516 -msgid "You can test a module with an Ansible playbook. For example:" -msgstr "以下のように、Ansible Playbook でモジュールをテストできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:518 -msgid "Create a playbook in any directory ``touch testmodule.yml``." -msgstr "任意のディレクトリーに Playbook を作成します (``touch testmodule.yml``)。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:519 -msgid "Create an inventory file in the same directory ``touch hosts``." -msgstr "同じディレクトリー ``touch hosts`` にインベントリーファイルを作成します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:520 -msgid "Populate the inventory file with the variables required to connect to a Windows host(s)." -msgstr "Windows ホストへの接続に必要な変数を指定してインベントリーファイルを設定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:531 -msgid "Run the playbook ``ansible-playbook -i hosts testmodule.yml``" -msgstr "Playbook ``ansible-playbook -i hosts testmodule.yml`` を実行します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:533 -msgid "This can be useful for seeing how Ansible runs with the new module end to end. Other possible ways to test the module are shown below." -msgstr "これは、Ansible が新しいモジュールでエンドツーエンドでどのように実行されるかを確認するのに役立ちます。モジュールをテストする他の可能な方法を以下に示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:539 -msgid "Windows debugging" -msgstr "Windows のデバッグ" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:541 -msgid "Debugging a module currently can only be done on a Windows host. This can be useful when developing a new module or implementing bug fixes. These are some steps that need to be followed to set this up:" -msgstr "現在、モジュールのデバッグは Windows ホストでのみ実行できます。これは、新しいモジュールまたはバグ修正の開発時に便利です。これらの手順は、以下を設定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:545 -msgid "Copy the module script to the Windows server" -msgstr "モジュールスクリプトを Windows サーバーにコピーします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:546 -msgid "Copy the folders ``./lib/ansible/module_utils/powershell`` and ``./lib/ansible/module_utils/csharp`` to the same directory as the script above" -msgstr "フォルダー ``./lib/ansible/module_utils/powershell`` と ``./lib/ansible/module_utils/csharp`` を上記のスクリプトと同じディレクトリーにコピーします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:547 -msgid "Add an extra ``#`` to the start of any ``#Requires -Module`` lines in the module code, this is only required for any lines starting with ``#Requires -Module``" -msgstr "モジュールコードにあるすべての ``#Requires -Module`` 行の先頭に ``#`` を追加してください。これは、``#Requires -Module`` で始まる行にのみ必要です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:548 -msgid "Add the following to the start of the module script that was copied to the server:" -msgstr "以下を、サーバーにコピーされたモジュールスクリプトの先頭に追加します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:580 -msgid "You can add more args to ``$complex_args`` as required by the module or define the module options through a JSON file with the structure::" -msgstr "モジュールに必要な場合は ``$complex_args`` にさらに引数を追加したり、その構造を持つ JSON ファイルでモジュールオプションを定義することもできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:592 -msgid "There are multiple IDEs that can be used to debug a Powershell script, two of the most popular ones are" -msgstr "Powershell スクリプトのデバッグに使用できる IDE が複数あり、以下の 2 つが最も一般的なものになります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:595 -msgid "`Powershell ISE`_" -msgstr "`Powershell ISE`_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:596 -msgid "`Visual Studio Code`_" -msgstr "`Visual Studio Code`_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:601 -msgid "To be able to view the arguments as passed by Ansible to the module follow these steps." -msgstr "Ansible がモジュールに渡した引数を表示するには、次の手順に従います。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:604 -msgid "Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1` to specify that Ansible should keep the exec files on the server." -msgstr "Ansible コマンドの前に :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1` を付けて、Ansible が exec ファイルをサーバ上に保持するように指定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:605 -msgid "Log onto the Windows server using the same user account that Ansible used to execute the module." -msgstr "Ansible がモジュールの実行に使用したのと同じユーザーアカウントを使用して Windows サーバーにログインします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:606 -msgid "Navigate to ``%TEMP%\\..``. It should contain a folder starting with ``ansible-tmp-``." -msgstr "``%TEMP%\\..`` に移動します。これには、``ansible-tmp-`` で始まるフォルダーが含まれるはずです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:607 -msgid "Inside this folder, open the PowerShell script for the module." -msgstr "このフォルダー内で、モジュールの PowerShell スクリプトを開きます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:608 -msgid "In this script is a raw JSON script under ``$json_raw`` which contains the module arguments under ``module_args``. These args can be assigned manually to the ``$complex_args`` variable that is defined on your debug script or put in the ``args.json`` file." -msgstr "このスクリプトは、``$json_raw`` にある生の JSON スクリプトで、``module_args`` の下にモジュール引数が含まれています。これらの引数は、デバッグスクリプトで定義される ``$complex_args`` 変数に手動で割り当てたり、``args.json`` ファイルに置いたりできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:612 -msgid "Windows unit testing" -msgstr "Windows のユニットテスト" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:614 -msgid "Currently there is no mechanism to run unit tests for Powershell modules under Ansible CI." -msgstr "現在、Ansible CI で Powershell モジュールのユニットテストを実行するメカニズムはありません。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:618 -msgid "Windows integration testing" -msgstr "Windows 統合テスト" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:620 -msgid "Integration tests for Ansible modules are typically written as Ansible roles. These test roles are located in ``./test/integration/targets``. You must first set up your testing environment, and configure a test inventory for Ansible to connect to." -msgstr "Ansible モジュールの統合テストは通常 Ansible ロールとして記述されます。これらのテストロールは ``./test/integration/targets`` にあります。まず、テスト環境を設定して、Ansible が接続できるようにテストインベントリーを設定する必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:624 -msgid "In this example we will set up a test inventory to connect to two hosts and run the integration tests for win_stat:" -msgstr "この例では、2 つのホストに接続し、win_stat の統合テストを実行するためのテストインベントリーを設定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:627 -msgid "Run the command ``source ./hacking/env-setup`` to prepare environment." -msgstr "環境を準備するには、``source ./hacking/env-setup`` コマンドを実行します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:628 -msgid "Create a copy of ``./test/integration/inventory.winrm.template`` and name it ``inventory.winrm``." -msgstr "``./test/integration/inventory.winrm.template`` のコピーを作成し、``inventory.winrm`` という名前を指定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:629 -msgid "Fill in entries under ``[windows]`` and set the required variables that are needed to connect to the host." -msgstr "``[windows]`` の下にエントリーを入力し、ホストへの接続に必要な変数を設定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:630 -msgid ":ref:`Install the required Python modules ` to support WinRM and a configured authentication method." -msgstr "WinRM と、設定された認証方法をサポートするのに :ref:`必要な Python モジュールをインストール ` します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:631 -msgid "To execute the integration tests, run ``ansible-test windows-integration win_stat``; you can replace ``win_stat`` with the role you want to test." -msgstr "統合テストを実行するには、``ansible-test windows-integration win_stat`` を実行します。``win_stat`` は、テストするロールに置き換えることができます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:633 -msgid "This will execute all the tests currently defined for that role. You can set the verbosity level using the ``-v`` argument just as you would with ansible-playbook." -msgstr "これにより、そのロールに対して現在定義されているすべてのテストが実行されます。ansible-playbook の場合と同じように、``-v`` 引数を使用して詳細レベルを設定できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:637 -msgid "When developing tests for a new module, it is recommended to test a scenario once in check mode and twice not in check mode. This ensures that check mode does not make any changes but reports a change, as well as that the second run is idempotent and does not report changes. For example:" -msgstr "新しいモジュールのテストを開発するときは、シナリオをチェックモードで 1 回、チェックモード以外で 2 回テストすることが推奨されます。これにより、チェックモードでは変更は行われず、変更が報告されます。また、2 回目の実行はべき等であり、変更は報告されません。以下に例を示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:690 -msgid "Windows communication and development support" -msgstr "Windows の通信および開発サポート" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:692 -msgid "Join the IRC channel ``#ansible-devel`` or ``#ansible-windows`` on freenode for discussions about Ansible development for Windows." -msgstr "freenode の IRC チャネル ``#ansible-devel`` または ``#ansible-windows`` に参加し、Windows 用 の Ansible 開発に関する議論を行うこと。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:5 -msgid "Creating a new collection" -msgstr "新規コレクションの作成" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:7 -msgid "Starting with Ansible 2.10, related modules should be developed in a collection. The Ansible core team and community compiled these module development tips and tricks to help companies developing Ansible modules for their products and users developing Ansible modules for third-party products. See :ref:`developing_collections` for a more detailed description of the collections format and additional development guidelines." -msgstr "Ansible 2.10 以降、関連するモジュールをコレクションで開発する必要があります。Ansible コアチームおよびコミュニティーは、これらのモジュール開発のヒントとコツをまとめて、自社製品用の Ansible モジュールを開発している企業や、サードパーティー製品用の Ansible モジュールを開発しているユーザーを支援します。コレクションの形式と追加の開発ガイドラインの詳細は、「:ref:`developing_collections`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:15 -msgid "Before you start coding" -msgstr "コーディングを開始する前に" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:17 -msgid "This list of prerequisites is designed to help ensure that you develop high-quality modules that work well with ansible-base and provide a seamless user experience." -msgstr "この前提条件のリストは、ansible-base で適切に機能し、シームレスなユーザーエクスペリエンスを提供する高品質のモジュールを確実に開発できるように設計されています。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:19 -msgid "Read though all the pages linked off :ref:`developing_modules_general`; paying particular focus to the :ref:`developing_modules_checklist`." -msgstr "「:ref:`developing_modules_general`」からリンクされているすべてのページを読みます。特に、「:ref:`developing_modules_checklist`」に注意してください。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:20 -msgid "We encourage PEP 8 compliance. See :ref:`testing_pep8` for more information." -msgstr "PEP 8 コンプライアンスが推奨されます。詳細は「:ref:`testing_pep8`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:21 -msgid "We encourage supporting :ref:`Python 2.6+ and Python 3.5+ `." -msgstr ":ref:`Python 2.6+ and Python 3.5+ ` をサポートすることが推奨されます。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:22 -msgid "Look at Ansible Galaxy and review the naming conventions in your functional area (such as cloud, networking, databases)." -msgstr "Ansible Galaxy を確認し、機能エリア (クラウド、ネットワーク、データベースなど) で命名規則を確認します。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:23 -msgid "With great power comes great responsibility: Ansible collection maintainers have a duty to help keep content up to date and release collections they are responsible for regularly. As with all successful community projects, collection maintainers should keep a watchful eye for reported issues and contributions." -msgstr "大きな力には大きな責任が伴います。Ansible コレクションのメンテナーには、コンテンツを最新の状態に保ち、定期的に責任のあるコレクションをリリースするのを支援する義務があります。成功しているすべてのコミュニティープロジェクトと同様に、コレクションのメンテナーは、報告された問題や貢献に注意を払う必要があります。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:24 -msgid "We strongly recommend unit and/or integration tests. Unit tests are especially valuable when external resources (such as cloud or network devices) are required. For more information see :ref:`developing_testing` and the `Testing Working Group `_." -msgstr "ユニットテストや統合テストが強く推奨されます。ユニットテストは、外部リソース (クラウドやネットワークデバイスなど) が必要な場合に特に役に立ちます。詳細については、「:ref:`developing_testing`」および「`ワーキンググループのテスト `_」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:28 -msgid "Naming conventions" -msgstr "命名規則" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:30 -msgid "Fully Qualified Collection Names (FQCNs) for plugins and modules include three elements:" -msgstr "プラグインおよびモジュール用の完全修飾コレクション名 (FQCN) には 3 つの要素があります。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:32 -msgid "the Galaxy namespace, which generally represents the company or group" -msgstr "Galaxy 名前空間。通常、会社またはグループを表します。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:33 -msgid "the collection name, which generally represents the product or OS" -msgstr "コレクション名。通常は製品または OS を表します。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:37 -msgid "the plugin or module name" -msgstr "プラグインまたはモジュール名" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:35 -msgid "always in lower case" -msgstr "常に小文字" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:36 -msgid "words separated with an underscore (``_``) character" -msgstr "単語はアンダースコア (``_``) 文字で区切られます。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:37 -msgid "singular, rather than plural, for example, ``command`` not ``commands``" -msgstr "複数形ではなく、単数形 (例: ``commands`` ではなく ``command``)" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:39 -msgid "For example, ``community.mongodb.mongodb_linux`` or ``cisco.meraki.meraki_device``." -msgstr "たとえば、``community.mongodb.mongodb_linux`` または ``cisco.meraki.meraki_device`` です。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:41 -msgid "It is convenient if the organization and repository names on GitHub (or elsewhere) match your namespace and collection names on Ansible Galaxy, but it is not required. The plugin names you select, however, are always the same in your code repository and in your collection artifact on Galaxy." -msgstr "GitHub (または別の場所) の組織とリポジトリー名が Ansible Galaxy の名前空間とコレクション名と一致する場合に便利ですが、必須ではありません。ただし、選択したプラグイン名は、コードリポジトリーと Galaxy のコレクションアーティファクトで常に同じです。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:44 -msgid "Speak to us" -msgstr "お問い合わせ" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:46 -msgid "Circulating your ideas before coding helps you adopt good practices and avoid common mistakes. After reading the \"Before you start coding\" section you should have a reasonable idea of the structure of your modules. Write a list of your proposed plugin and/or module names, with a short description of what each one does. Circulate that list on IRC or a mailing list so the Ansible community can review your ideas for consistency and familiarity. Names and functionality that are consistent, predictable, and familiar make your collection easier to use." -msgstr "コーディングの前にアイデアを出し合うことで、良い習慣を取り入れ、よくある間違いを避けることができます。「コーディングを始める前に」のセクションを読んだ後、モジュールの構造について妥当なアイデアがあるはずです。提案するプラグインやモジュールの名前のリストを書き、それぞれが何をするのかを簡単に説明してください。そのリストを、IRC やメーリングリストで出し合って、Ansible コミュニティーが一貫性や親しみやすさの観点からアイデアを検討できるようにします。一貫性があり、予測可能で、親しみやすい名前や機能は、コレクションをより使いやすくします。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:49 -msgid "Where to get support" -msgstr "サポートを受ける場所" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:51 -msgid "Ansible has a thriving and knowledgeable community of module developers that is a great resource for getting your questions answered." -msgstr "Ansible には、活発で知識が豊富なモジュール開発者のコミュニティーがあり、質問に答えるための素晴らしいリソースとなっています。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:53 -msgid "In the :ref:`ansible_community_guide` you can find how to:" -msgstr ":ref:`ansible_community_guide` で、以下の方法を見つけることができます。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:55 -msgid "Subscribe to the Mailing Lists - We suggest \"Ansible Development List\" and \"Ansible Announce list\"" -msgstr "メーリングリストをサブスクライブすること。「Ansible Development List」および「Ansible Announce list」をお勧めします。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:56 -msgid "``#ansible-devel`` - We have found that IRC ``#ansible-devel`` on FreeNode's IRC network works best for developers so we can have an interactive dialogue." -msgstr "``#ansible-devel`` - FreeNode の IRC ネットワーク ``#ansible-devel`` では、インタラクティブな対話を行うことができるため、モジュール開発者に最適なものであることが分かっています。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:57 -msgid "IRC meetings - Join the various weekly IRC meetings `meeting schedule and agenda page `_" -msgstr "IRC ミーティング。様々な IRC ミーティング (毎週) に参加する。「_」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:60 -msgid "Required files" -msgstr "必須ファイル" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:62 -msgid "Your collection should include the following files to be usable:" -msgstr "コレクションには、使用可能な以下のファイルが含まれているはずです。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:64 -msgid "an ``__init__.py`` file - An empty file to initialize namespace and allow Python to import the files. *Required*" -msgstr "``__init__.py`` - 名前空間を初期化し、Python がファイルをインポートできるようにする空のファイル。*必須*" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:65 -msgid "at least one plugin, for example, ``/plugins/modules/$your_first_module.py``. *Required*" -msgstr "少なくとも 1 つのプラグイン (例: ``/plugins/modules/$your_first_module.py``)。*必須*" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:66 -msgid "if needed, one or more ``/plugins/doc_fragments/$topic.py`` files - Code documentation, such as details regarding common arguments. *Optional*" -msgstr "必要な場合は、1 つ以上の ``/plugins/doc_fragments/$topic.py`` ファイル - 一般的な引数の詳細などのコードのドキュメント。*任意*" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:67 -msgid "if needed, one or more ``/plugins/module_utils/$topic.py`` files - Code shared between more than one module, such as common arguments. *Optional*" -msgstr "必要な場合は、1 つ以上の ``/plugins/module_utils/$topic.py`` ファイル - 一般的な引数などの、複数のモジュール間で共有されるコード。*任意*" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:69 -msgid "When you have these files ready, review the :ref:`developing_modules_checklist` again. If you are creating a new collection, you are responsible for all procedures related to your repository, including setting rules for contributions, finding reviewers, and testing and maintaining the code in your collection." -msgstr "これらのファイルの準備が整ったら、:ref:`developing_modules_checklist` を再度確認します。新しいコレクションを作成する場合は、貢献、レビュー担当者のルールの設定など、リポジトリーに関連するすべての手順を行い、コレクションでコードをテストおよび維持します。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:71 -msgid "If you need help or advice, consider join the ``#ansible-devel`` IRC channel (see how in the \"Where to get support\")." -msgstr "さらにヘルプまたはアドバイスが必要な場合は、IRC チャンネル ``#ansible-devel`` に参加することを検討してください (「サポートを得る方法」を参照してください)。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:74 -msgid "New to git or GitHub" -msgstr "git または GitHub をはじめて使用する場合" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:76 -msgid "We realize this may be your first use of Git or GitHub. The following guides may be of use:" -msgstr "ここでは、Git または GitHub を初めて使用するユーザーを対象としています。次のガイドが参考になる場合があります。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:78 -msgid "`How to create a fork of ansible/ansible `_" -msgstr "`How to create a fork of ansible/ansible `_" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:79 -msgid "`How to sync (update) your fork `_" -msgstr "`How to sync (update) your fork `_" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:80 -msgid "`How to create a Pull Request (PR) `_" -msgstr "`How to create a Pull Request (PR) `_" - -#: ../../rst/dev_guide/developing_plugins.rst:6 -msgid "Developing plugins" -msgstr "プラグインの開発" - -#: ../../rst/dev_guide/developing_plugins.rst:11 -msgid "Plugins augment Ansible's core functionality with logic and features that are accessible to all modules. Ansible collections include a number of handy plugins, and you can easily write your own. All plugins must:" -msgstr "プラグインは、すべてのモジュールがアクセスできるロジックおよび機能を使用して Ansible のコア機能を拡張します。Ansibleコレクションには多くの便利なプラグインが含まれており、独自のプラグインを簡単に作成できます。すべてのプラグインでは、以下を行う必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:13 -msgid "be written in Python" -msgstr "Python で書かれている。" - -#: ../../rst/dev_guide/developing_plugins.rst:14 -msgid "raise errors" -msgstr "エラーを発生させる。" - -#: ../../rst/dev_guide/developing_plugins.rst:15 -msgid "return strings in unicode" -msgstr "Unicode で文字列を返す。" - -#: ../../rst/dev_guide/developing_plugins.rst:16 -msgid "conform to Ansible's configuration and documentation standards" -msgstr "Ansible の設定およびドキュメントの標準仕様に準拠する。" - -#: ../../rst/dev_guide/developing_plugins.rst:18 -msgid "Once you've reviewed these general guidelines, you can skip to the particular type of plugin you want to develop." -msgstr "これらの一般的なガイドラインを確認したら、開発する特定のタイプのプラグインを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:21 -msgid "Writing plugins in Python" -msgstr "Python でのプラグインの作成" - -#: ../../rst/dev_guide/developing_plugins.rst:23 -msgid "You must write your plugin in Python so it can be loaded by the ``PluginLoader`` and returned as a Python object that any module can use. Since your plugin will execute on the controller, you must write it in a :ref:`compatible version of Python `." -msgstr "``PluginLoader`` により読み込まれ、モジュールが使用できる Python オブジェクトとして返すには、Python でプラグインを作成する必要があります。プラグインはコントローラーで実行するため、:ref:`互換性のある Python バージョン ` で作成する必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:26 -msgid "Raising errors" -msgstr "エラーの発生" - -#: ../../rst/dev_guide/developing_plugins.rst:28 -msgid "You should return errors encountered during plugin execution by raising ``AnsibleError()`` or a similar class with a message describing the error. When wrapping other exceptions into error messages, you should always use the ``to_native`` Ansible function to ensure proper string compatibility across Python versions:" -msgstr "プラグインの実行中に発生したエラーは、``AnsibleError()`` またはエラーを記述したメッセージのある同様のクラスを発生させて返す必要があります。他の例外をエラーメッセージにラップする場合は、Python のバージョン間で適切な文字列の互換性を確保するために、常に Ansible 関数の ``to_native`` を使用する必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:39 -msgid "Check the different `AnsibleError objects `_ and see which one applies best to your situation." -msgstr "様々な `AnsibleError オブジェクト `_ を確認して、お使いの状況に最適なものを確認します。" - -#: ../../rst/dev_guide/developing_plugins.rst:42 -msgid "String encoding" -msgstr "文字列エンコーディング" - -#: ../../rst/dev_guide/developing_plugins.rst:44 -msgid "You must convert any strings returned by your plugin into Python's unicode type. Converting to unicode ensures that these strings can run through Jinja2. To convert strings:" -msgstr "プラグインによって返される文字列は、Python の Unicode タイプに変換する必要があります。Unicode に変換すると、これらの文字列が Jinja2 を介して実行できるようになります。文字列を変換するには、次を実行します。" - -#: ../../rst/dev_guide/developing_plugins.rst:52 -msgid "Plugin configuration & documentation standards" -msgstr "プラグインの設定およびドキュメントの標準仕様" - -#: ../../rst/dev_guide/developing_plugins.rst:54 -msgid "To define configurable options for your plugin, describe them in the ``DOCUMENTATION`` section of the python file. Callback and connection plugins have declared configuration requirements this way since Ansible version 2.4; most plugin types now do the same. This approach ensures that the documentation of your plugin's options will always be correct and up-to-date. To add a configurable option to your plugin, define it in this format:" -msgstr "プラグインの設定可能なオプションを定義するには、python ファイルの ``DOCUMENTATION`` セクションで記述します。Ansible バージョン 2.4 以降、コールバックおよび接続プラグインはこの方法で設定要件を宣言しました。ほとんどのプラグインが同じように動作するようになりました。この方法により、プラグインのオプションのドキュメントを常に正しく最新の状態に保つことができます。設定可能なオプションをプラグインに追加するには、以下の形式で定義します。" - -#: ../../rst/dev_guide/developing_plugins.rst:71 -msgid "To access the configuration settings in your plugin, use ``self.get_option()``. For most plugin types, the controller pre-populates the settings. If you need to populate settings explicitly, use a ``self.set_options()`` call." -msgstr "プラグインの設定にアクセスするには、``self.get_option()`` を使用します。ほとんどのプラグインタイプでは、コントローラーは設定を事前に設定します。設定を明示的に設定する必要がある場合は、``self.set_options()`` 呼び出しを使用します。" - -#: ../../rst/dev_guide/developing_plugins.rst:73 -msgid "Plugins that support embedded documentation (see :ref:`ansible-doc` for the list) should include well-formed doc strings. If you inherit from a plugin, you must document the options it takes, either via a documentation fragment or as a copy. See :ref:`module_documenting` for more information on correct documentation. Thorough documentation is a good idea even if you're developing a plugin for local use." -msgstr "埋め込みドキュメントをサポートするプラグイン (:ref:`ansible-doc` リストの場合を参照) は、適切に構築されたドキュメント文字列を含める必要があります。プラグインから継承する場合は、ドキュメントフラグメントを介して、またはコピーとして、必要なオプションを記述する必要があります。正しいドキュメントに関する詳細は、「:ref:`module_documenting`」を参照してください。ローカルで使用するプラグインを開発している場合でも、完全なドキュメントを作成することが推奨されます。" - -#: ../../rst/dev_guide/developing_plugins.rst:76 -msgid "Developing particular plugin types" -msgstr "特定のプラグインタイプの開発" - -#: ../../rst/dev_guide/developing_plugins.rst:81 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:24 -msgid "Action plugins" -msgstr "Action プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:83 -msgid "Action plugins let you integrate local processing and local data with module functionality." -msgstr "Action プラグインを使用すると、ローカル処理とローカルデータをモジュール機能に統合できます。" - -#: ../../rst/dev_guide/developing_plugins.rst:85 -msgid "To create an action plugin, create a new class with the Base(ActionBase) class as the parent:" -msgstr "Action プラグインを作成するには、Base(ActionBase) クラスを親として新しいクラスを作成します。" - -#: ../../rst/dev_guide/developing_plugins.rst:94 -msgid "From there, execute the module using the ``_execute_module`` method to call the original module. After successful execution of the module, you can modify the module return data." -msgstr "そこから、``_execute_module`` メソッドを使用して元のモジュールを呼び出します。モジュールの実行に成功すると、モジュールの戻り値データを変更できます。" - -#: ../../rst/dev_guide/developing_plugins.rst:104 -msgid "For example, if you wanted to check the time difference between your Ansible controller and your target machine(s), you could write an action plugin to check the local time and compare it to the return data from Ansible's ``setup`` module:" -msgstr "たとえば、Ansible コントローラーとターゲットマシン間の時間差を確認する場合は、Action プラグインを作成してローカルタイムを確認し、それを Ansible の ``setup`` モジュールから返されるデータと比較できます。" - -#: ../../rst/dev_guide/developing_plugins.rst:141 -msgid "This code checks the time on the controller, captures the date and time for the remote machine using the ``setup`` module, and calculates the difference between the captured time and the local time, returning the time delta in days, seconds and microseconds." -msgstr "このコードはコントローラーの時間を確認し、``setup`` モジュールを使用してリモートマシンの日時を取得し、取得した時間とローカル時間の差異を算出し、その時間差を日数、秒、マイクロ秒で返します。" - -#: ../../rst/dev_guide/developing_plugins.rst:144 -msgid "For practical examples of action plugins, see the source code for the `action plugins included with Ansible Core `_" -msgstr "action プラグインの実際の例は、`Ansible Core に同梱される action プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:150 -msgid "Cache plugins" -msgstr "Cache プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:152 -msgid "Cache plugins store gathered facts and data retrieved by inventory plugins." -msgstr "Cache プラグインは、Inventory \\プラグインによって取得されるファクトおよびデータを収集したデータを格納します。" - -#: ../../rst/dev_guide/developing_plugins.rst:154 -msgid "Import cache plugins using the cache_loader so you can use ``self.set_options()`` and ``self.get_option()``. If you import a cache plugin directly in the code base, you can only access options via ``ansible.constants``, and you break the cache plugin's ability to be used by an inventory plugin." -msgstr "``self.set_options()`` および ``self.get_option()`` を使用できる cache_loader を使用する cache プラグインをインポートします。コードベースで Cache プラグインを直接インポートする場合は、``ansible.constants`` からのみオプションにアクセスでき、Inventory プラグインによって使用される cache プラグインの機能が壊れます。" - -#: ../../rst/dev_guide/developing_plugins.rst:162 -msgid "There are two base classes for cache plugins, ``BaseCacheModule`` for database-backed caches, and ``BaseCacheFileModule`` for file-backed caches." -msgstr "cache プラグインには、2 つのベースクラス (データベースベースのバックアップ用のキャッシュの場合は ``BaseCacheModule``、ファイルのバックアップ用のキャッシュの場合は ``BaseCacheFileModule``) があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:164 -msgid "To create a cache plugin, start by creating a new ``CacheModule`` class with the appropriate base class. If you're creating a plugin using an ``__init__`` method you should initialize the base class with any provided args and kwargs to be compatible with inventory plugin cache options. The base class calls ``self.set_options(direct=kwargs)``. After the base class ``__init__`` method is called ``self.get_option()`` should be used to access cache options." -msgstr "キャッシュプラグインを作成するには、適切なベースクラスで新しい ``CacheModule`` クラスを作成して開始します。``__init__`` メソッドを使用してプラグインを作成する場合は、指定された arg および kwarg でベースクラスを初期化し、インベントリープラグインキャッシュオプションと互換性がある必要があります。ベースクラスは ``self.set_options(direct=kwargs)`` を呼び出します。ベースクラス ``__init__`` メソッドが ``self.get_option()`` を呼び出したあと、キャッシュオプションにアクセスする必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:166 -msgid "New cache plugins should take the options ``_uri``, ``_prefix``, and ``_timeout`` to be consistent with existing cache plugins." -msgstr "新しい cache プラグインは、既存の cache プラグインとの整合性を保つために、``_uri`` オプション、``_prefix`` オプション、および ``_timeout`` オプションを使用する必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:179 -msgid "If you use the ``BaseCacheModule``, you must implement the methods ``get``, ``contains``, ``keys``, ``set``, ``delete``, ``flush``, and ``copy``. The ``contains`` method should return a boolean that indicates if the key exists and has not expired. Unlike file-based caches, the ``get`` method does not raise a KeyError if the cache has expired." -msgstr "``BaseCacheModule`` を使用する場合は、メソッド ``get``、``contains``、``keys``、``set``、``delete``、``flush``、および ``copy`` を実装する必要があります。``contains`` メソッドは、キーが存在し、有効期限が切れていないことを示すブール値を返すはずです。ファイルベースのキャッシュとは異なり、キャッシュの有効期限が切れると、``get`` メソッドによって KeyError は発生しません。" - -#: ../../rst/dev_guide/developing_plugins.rst:181 -msgid "If you use the ``BaseFileCacheModule``, you must implement ``_load`` and ``_dump`` methods that will be called from the base class methods ``get`` and ``set``." -msgstr "``BaseFileCacheModule`` を使用する場合は、ベースクラスメソッド ``_load`` および ``_dump`` から呼び出される ``_load`` メソッドおよび ``_dump`` メソッドを実装する必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:183 -msgid "If your cache plugin stores JSON, use ``AnsibleJSONEncoder`` in the ``_dump`` or ``set`` method and ``AnsibleJSONDecoder`` in the ``_load`` or ``get`` method." -msgstr "キャッシュプラグインに JSON が保存されている場合は、``_dump`` メソッドまたは ``set`` メソッドの ``AnsibleJSONEncoder`` と、``_load`` メソッドまたは``get`` メソッドを使用します。" - -#: ../../rst/dev_guide/developing_plugins.rst:185 -msgid "For example cache plugins, see the source code for the `cache plugins included with Ansible Core `_." -msgstr "cache プラグインの例は、`Ansible Core に同梱される cache プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:190 -msgid "Callback plugins" -msgstr "Callback プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:192 -msgid "Callback plugins add new behaviors to Ansible when responding to events. By default, callback plugins control most of the output you see when running the command line programs." -msgstr "callback プラグインは、イベントに応答する際に新しい動作を Ansible に追加します。デフォルトでは、callback プラグインは、コマンドラインプログラムの実行時に表示されるほとんどの出力を制御します。" - -#: ../../rst/dev_guide/developing_plugins.rst:194 -msgid "To create a callback plugin, create a new class with the Base(Callbacks) class as the parent:" -msgstr "Callback プラグインを作成するには、Base(Callbacks) クラスを親として使用して新規クラスを作成します。" - -#: ../../rst/dev_guide/developing_plugins.rst:203 -msgid "From there, override the specific methods from the CallbackBase that you want to provide a callback for. For plugins intended for use with Ansible version 2.0 and later, you should only override methods that start with ``v2``. For a complete list of methods that you can override, please see ``__init__.py`` in the `lib/ansible/plugins/callback `_ directory." -msgstr "そこから、コールバックを提供する CallbackBase から特定のメソッドを上書きします。Ansible バージョン 2.0 以降で使用するプラグインでは、``v2`` で始まる方法のみを上書きしてください。上書きできるメソッドの完全なリストは、`lib/ansible/plugins/callback `_ ディレクトリーの ``__init__.py`` を参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:208 -msgid "The following is a modified example of how Ansible's timer plugin is implemented, but with an extra option so you can see how configuration works in Ansible version 2.4 and later:" -msgstr "以下は、Ansible の timer プラグインの実装方法の変更例です。ただし、追加のオプションを使用すると、Ansible バージョン 2.4 以降で構成がどのように機能するかを確認できます。" - -#: ../../rst/dev_guide/developing_plugins.rst:277 -msgid "Note that the ``CALLBACK_VERSION`` and ``CALLBACK_NAME`` definitions are required for properly functioning plugins for Ansible version 2.0 and later. ``CALLBACK_TYPE`` is mostly needed to distinguish 'stdout' plugins from the rest, since you can only load one plugin that writes to stdout." -msgstr "``CALLBACK_VERSION`` および ``CALLBACK_NAME`` の定義は、Ansible バージョン 2.0 以降のプラグインが正しく機能するために必要であることに注意してください。``CALLBACK_TYPE`` は、標準出力 (stdout) に書き込むプラグインを 1 つだけ読み込むことができるため、ほとんどの「stdout」プラグインをその他のものと区別するために必要です。" - -#: ../../rst/dev_guide/developing_plugins.rst:279 -msgid "For example callback plugins, see the source code for the `callback plugins included with Ansible Core `_" -msgstr "callback プラグインの例は、`Ansible Core に同梱される callback プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:281 -msgid "New in ansible-base 2.11, callback plugins are notified (via ``v2_playbook_on_task_start``) of :ref:`meta` tasks. By default, only explicit ``meta`` tasks that users list in their plays are sent to callbacks." -msgstr "ansible-base 2.11 の新機能として、:ref:`meta` タスクのコールバックプラグインが (``v2_playbook_on_task_start`` を介して) 通知されます。デフォルトでは、プレイに上あげる明示的な ``meta`` タスクのみが、コールバックに送信されます。" - -#: ../../rst/dev_guide/developing_plugins.rst:283 -msgid "There are also some tasks which are generated internally and implicitly at various points in execution. Callback plugins can opt-in to receiving these implicit tasks as well, by setting ``self.wants_implicit_tasks = True``. Any ``Task`` object received by a callback hook will have an ``.implicit`` attribute, which can be consulted to determine whether the ``Task`` originated from within Ansible, or explicitly by the user." -msgstr "実行のさまざまな時点で、内部的および暗黙的に生成されるタスクもいくつかあります。callback プラグインは、``self.wants_implicit_tasks = True`` を設定することにより、これらの暗黙的なタスクを受け取ることをオプトインできます。``Task`` コールバックフックによって受信されたオブジェクトには、``.implicit`` 属性があります。これを参照して、``Task`` が Ansible 内から、またはユーザーによって明示的に発信されましたかどうかを決めるために参照します。" - -#: ../../rst/dev_guide/developing_plugins.rst:288 -msgid "Connection plugins" -msgstr "Connection プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:290 -msgid "Connection plugins allow Ansible to connect to the target hosts so it can execute tasks on them. Ansible ships with many connection plugins, but only one can be used per host at a time. The most commonly used connection plugins are the ``paramiko`` SSH, native ssh (just called ``ssh``), and ``local`` connection types. All of these can be used in playbooks and with ``/usr/bin/ansible`` to connect to remote machines." -msgstr "接続プラグインにより、Ansible はターゲットホストに接続してそのホストにあるタスクを実行できるようにします。Ansible には多くの接続プラグインが同梱されていますが、一度に使用できるのは 1 つのみとなります。最も一般的に使用される接続プラグインは、``paramiko`` SSH、ネイティブ ssh (単に ``ssh`` と呼ばれる)、および ``local`` 接続タイプです。これらはすべて Playbook で使用され、``/usr/bin/ansible`` を使用してリモートマシンに接続します。" - -#: ../../rst/dev_guide/developing_plugins.rst:292 -msgid "Ansible version 2.1 introduced the ``smart`` connection plugin. The ``smart`` connection type allows Ansible to automatically select either the ``paramiko`` or ``openssh`` connection plugin based on system capabilities, or the ``ssh`` connection plugin if OpenSSH supports ControlPersist." -msgstr "Ansible バージョン 2.1 では、``smart`` 接続プラグインが導入されます。``smart`` 接続タイプにより、Ansible は、システム機能に基づいて、``paramiko`` 接続プラグインまたは ``openssh`` 接続プラグインのいずれかを自動的に選択できますが、OpenSSH が ControlPersist に対応している場合は ``ssh`` の Connection プラグインを選択します。" - -#: ../../rst/dev_guide/developing_plugins.rst:294 -msgid "To create a new connection plugin (for example, to support SNMP, Message bus, or other transports), copy the format of one of the existing connection plugins and drop it into ``connection`` directory on your :ref:`local plugin path `." -msgstr "新しい connection プラグイン (SNMP、メッセージバス、またはその他のトランスポートをサポートする場合など) を作成するには、既存の connection プラグインのいずれかの形式をコピーして、:ref:`ローカルプラグインパス ` にある ``connection`` ディレクトリーに置きます。" - -#: ../../rst/dev_guide/developing_plugins.rst:296 -msgid "Connection plugins can support common options (such as the ``--timeout`` flag) by defining an entry in the documentation for the attribute name (in this case ``timeout``). If the common option has a non-null default, the plugin should define the same default since a different default would be ignored." -msgstr "接続プラグインは、属性名 (ここでは ``timeout``) のドキュメントでエントリーを定義することで、一般的なオプション (``--timeout`` フラグなど) をサポートします。一般的なオプションには null 以外のデフォルトがある場合、別のデフォルトは無視されるため、プラグインは同じデフォルトを定義する必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:298 -msgid "For example connection plugins, see the source code for the `connection plugins included with Ansible Core `_." -msgstr "選択プラグインの例は、`Ansible Core に同梱される接続プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:303 -msgid "Filter plugins" -msgstr "Filter プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:305 -msgid "Filter plugins manipulate data. They are a feature of Jinja2 and are also available in Jinja2 templates used by the ``template`` module. As with all plugins, they can be easily extended, but instead of having a file for each one you can have several per file. Most of the filter plugins shipped with Ansible reside in a ``core.py``." -msgstr "Filter プラグインはデータを操作します。これらは Jinja2 の機能であり、``template`` モジュールが使用する Jinja2 テンプレートで利用できます。すべてのプラグインと同様に、プラグインは簡単に拡張できますが、プラグインごとにファイルを作成する代わりに、ファイルごとに複数のプラグインを作成できます。Ansible に同梱されているフィルタープラグインのほとんどは、``core.py`` にあります。" - -#: ../../rst/dev_guide/developing_plugins.rst:307 -msgid "Filter plugins do not use the standard configuration and documentation system described above." -msgstr "Filter プラグインは、上記の標準設定およびドキュメントシステムを使用しません。" - -#: ../../rst/dev_guide/developing_plugins.rst:309 -msgid "For example filter plugins, see the source code for the `filter plugins included with Ansible Core `_." -msgstr "vars プラグインの例は、`Ansible Core に同梱される filter プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:316 -msgid "Inventory plugins parse inventory sources and form an in-memory representation of the inventory. Inventory plugins were added in Ansible version 2.4." -msgstr "inventory プラグインはインベントリーソースを解析し、インベントリーのインメモリー表示を形成します。inventory プラグインは Ansible バージョン 2.4 で追加されました。" - -#: ../../rst/dev_guide/developing_plugins.rst:318 -msgid "You can see the details for inventory plugins in the :ref:`developing_inventory` page." -msgstr "インベントリープラグインの詳細は、:ref:`developing_inventory` ページを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:323 -msgid "Lookup plugins" -msgstr "Lookup プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:325 -msgid "Lookup plugins pull in data from external data stores. Lookup plugins can be used within playbooks both for looping --- playbook language constructs like ``with_fileglob`` and ``with_items`` are implemented via lookup plugins --- and to return values into a variable or parameter." -msgstr "lookup プラグインは、外部データストアからデータをプルします。lookup プラグインは Playbook 内でループするため (``with_fileglob`` や ``with_items`` などの Playbook 言語の構造は lookup プラグインを介して実装されています)、また変数やパラメーターに値を返すために使用することができます。" - -#: ../../rst/dev_guide/developing_plugins.rst:327 -msgid "Lookup plugins are very flexible, allowing you to retrieve and return any type of data. When writing lookup plugins, always return data of a consistent type that can be easily consumed in a playbook. Avoid parameters that change the returned data type. If there is a need to return a single value sometimes and a complex dictionary other times, write two different lookup plugins." -msgstr "Lookup プラグインは非常に柔軟性があるため、あらゆるタイプのデータを取得し、返すことができます。Lookup プラグインを記述する際には、Playbook で簡単に使用できる一貫性のあるタイプのデータを常に返します。返されたデータ型を変更するパラメーターは使用しないでください。単一の値を返さなければならないときもあれば、複雑なディクショナリーを返さなければない場合もあります。この場合は、Lookup プラグインを 2 つ記述してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:329 -msgid "Ansible includes many :ref:`filters ` which can be used to manipulate the data returned by a lookup plugin. Sometimes it makes sense to do the filtering inside the lookup plugin, other times it is better to return results that can be filtered in the playbook. Keep in mind how the data will be referenced when determining the appropriate level of filtering to be done inside the lookup plugin." -msgstr "Ansible には、Lookup プラグインによって返されるデータを操作するために使用できる :ref:`filters ` が多数含まれています。Lookup プラグイン内でフィルタリングを行うことが理にかなっている場合もあれば、Playbook でフィルタリングできる結果を返す方がよい場合もあります。Lookup プラグイン内で実行する適切なフィルタリングレベルを決定するときは、データがどのように参照されるかに留意してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:331 -msgid "Here's a simple lookup plugin implementation --- this lookup returns the contents of a text file as a variable:" -msgstr "以下は簡単な Lookup プラグインの実装です。この Lookup は、テキストファイルの内容を変数として返します。" - -#: ../../rst/dev_guide/developing_plugins.rst:393 -msgid "The following is an example of how this lookup is called:" -msgstr "以下は、このルックアップがどのように呼び出されるかの例になります。" - -#: ../../rst/dev_guide/developing_plugins.rst:408 -msgid "For example lookup plugins, see the source code for the `lookup plugins included with Ansible Core `_." -msgstr "vars プラグインの例は、`Ansible Core に同梱される lookup プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:410 -msgid "For more usage examples of lookup plugins, see :ref:`Using Lookups`." -msgstr "検索プラグインのその他の使用例については、「:ref:`検索の使用`」を参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:415 -msgid "Test plugins" -msgstr "Test プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:417 -msgid "Test plugins verify data. They are a feature of Jinja2 and are also available in Jinja2 templates used by the ``template`` module. As with all plugins, they can be easily extended, but instead of having a file for each one you can have several per file. Most of the test plugins shipped with Ansible reside in a ``core.py``. These are specially useful in conjunction with some filter plugins like ``map`` and ``select``; they are also available for conditional directives like ``when:``." -msgstr "テストプラグインはデータを検証します。これは Jinja2 の機能で、``template`` モジュールが使用する Jinja2 テンプレートでも利用できます。他のすべてのプラグインと同様、このプラグインは簡単に拡張できますが、プラグインごとにファイルを作成する代わりに、ファイルごとに複数のプラグインを作成できます。Ansible に同梱されているテストプラグインのほとんどは、``core.py`` に格納されています。これらのプラグインは、``map`` や ``select`` などのフィルタープラグインと組み合わせて使うと特に便利です。また、``when:`` などの条件付きディレクティブにも利用できます。" - -#: ../../rst/dev_guide/developing_plugins.rst:419 -msgid "Test plugins do not use the standard configuration and documentation system described above." -msgstr "Test プラグインは、上記の標準設定およびドキュメントシステムを使用しません。" - -#: ../../rst/dev_guide/developing_plugins.rst:421 -msgid "For example test plugins, see the source code for the `test plugins included with Ansible Core `_." -msgstr "test プラグインの例は、`Ansible Core に同梱されるテストプラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:426 -msgid "Vars plugins" -msgstr "Vars プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:428 -msgid "Vars plugins inject additional variable data into Ansible runs that did not come from an inventory source, playbook, or command line. Playbook constructs like 'host_vars' and 'group_vars' work using vars plugins." -msgstr "Vars プラグインは、インベントリーソース、Playbook、またはコマンドラインに組み込まれていない Ansible の実行に、変数データを追加します。「host_vars」や「group_vars」のような Playbook の構成要素は、vars プラグインを使用します。" - -#: ../../rst/dev_guide/developing_plugins.rst:430 -msgid "Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4. Vars plugins are unsupported by collections." -msgstr "vars プラグインは Ansible 2.0 に部分的に実装され、Ansible 2.4 以降では、完全実装になるように書き直されました。vars プラグインはコレクションによりサポートされません。" - -#: ../../rst/dev_guide/developing_plugins.rst:432 -msgid "Older plugins used a ``run`` method as their main body/work:" -msgstr "古いプラグインでは、``run`` メソッドを主要な本文/作業として使用していました。" - -#: ../../rst/dev_guide/developing_plugins.rst:440 -msgid "Ansible 2.0 did not pass passwords to older plugins, so vaults were unavailable. Most of the work now happens in the ``get_vars`` method which is called from the VariableManager when needed." -msgstr "Ansible 2.0 は古いプラグインにパスワードを渡さなかったため、vault は利用できませんでした。ほとんどの作業は、必要に応じて VariableManager から呼び出される ``get_vars`` メソッドで実行されるようになりました。" - -#: ../../rst/dev_guide/developing_plugins.rst:448 -msgid "The parameters are:" -msgstr "パラメーターは以下のとおりです。" - -#: ../../rst/dev_guide/developing_plugins.rst:450 -msgid "loader: Ansible's DataLoader. The DataLoader can read files, auto-load JSON/YAML and decrypt vaulted data, and cache read files." -msgstr "DataLoader は、ファイルの読み取り、JSON/YAML の自動読み込み、vault を使用したデータの復号化、および読み取りファイルのキャッシュを行うことができます。" - -#: ../../rst/dev_guide/developing_plugins.rst:451 -msgid "path: this is 'directory data' for every inventory source and the current play's playbook directory, so they can search for data in reference to them. ``get_vars`` will be called at least once per available path." -msgstr "path: これはすべてのインベントリーソースと現在のプレイの Playbook ディレクトリーの「ディレクトリーデータ」であるため、それを参照するデータを検索することができます。``get_vars`` は、利用可能なパスごとに最低 1 回呼び出されます。" - -#: ../../rst/dev_guide/developing_plugins.rst:452 -msgid "entities: these are host or group names that are pertinent to the variables needed. The plugin will get called once for hosts and again for groups." -msgstr "entities: 必要な変数に関連付けられるホスト名またはグループ名です。プラグインはホストについて 1 回呼び出され、グループについて再度呼び出されます。" - -#: ../../rst/dev_guide/developing_plugins.rst:454 -msgid "This ``get_vars`` method just needs to return a dictionary structure with the variables." -msgstr "この ``get_vars`` メソッドは変数を含むディクショナリー構造を返す必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:456 -msgid "Since Ansible version 2.4, vars plugins only execute as needed when preparing to execute a task. This avoids the costly 'always execute' behavior that occurred during inventory construction in older versions of Ansible. Since Ansible version 2.10, vars plugin execution can be toggled by the user to run when preparing to execute a task or after importing an inventory source." -msgstr "Ansible バージョン 2.4 以降、タスク実行の準備時に必要に応じて vars プラグインを実行します。これにより、古いバージョンの Ansible のインベントリー構築中に発生した、費用のかかる「常に実行」動作が回避されます。Ansible バージョン 2.10 以降、vars プラグインの実行は、タスクの実行準備時またはインベントリーソースのインポート後に実行するようにユーザーが切り替えることができます。" - -#: ../../rst/dev_guide/developing_plugins.rst:458 -msgid "You can create vars plugins that are not enabled by default using the class variable ``REQUIRES_ENABLED``. If your vars plugin resides in a collection, it cannot be enabled by default. You must use ``REQUIRES_ENABLED`` in all collections-based vars plugins. To require users to enable your plugin, set the class variable ``REQUIRES_ENABLED``:" -msgstr "クラス変数 ``REQUIRES_ENABLED`` を使用して、デフォルトで有効になっていない vars プラグインを作成できます。vars プラグインがコレクションに存在する場合は、デフォルトで有効にはできません。すべてのコレクションベースの vars プラグインで ``REQUIRES_ENABLED`` を使用する必要があります。ユーザーがプラグインを有効にするには、クラス変数 ``REQUIRES_ENABLED`` を設定します。" - -#: ../../rst/dev_guide/developing_plugins.rst:465 -msgid "Include the ``vars_plugin_staging`` documentation fragment to allow users to determine when vars plugins run." -msgstr "``vars_plugin_staging`` ドキュメントフラグメントを追加して、ユーザーが when vars プラグインの実行を判別できるようにします。" - -#: ../../rst/dev_guide/developing_plugins.rst:485 -msgid "For example vars plugins, see the source code for the `vars plugins included with Ansible Core `_." -msgstr "vars プラグインの例は、`Ansible Core に含まれる vars プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:495 -msgid "Learn about how to develop dynamic inventory sources" -msgstr "動的インベントリーソースの開発方法について" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:6 -msgid "Ansible module architecture" -msgstr "Ansible モジュールのアーキテクチャー" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:8 -msgid "If you are working on the ``ansible-base`` code, writing an Ansible module, or developing an action plugin, you may need to understand how Ansible's program flow executes. If you are just using Ansible Modules in playbooks, you can skip this section." -msgstr "``ansible-base`` コードを使用している場合、Ansible モジュールの作成、またはアクションプラグインの開発では、Ansible のプログラムフローがどのように実行されるかを理解しないといけない場合があります。Playbook で Ansible モジュールを使用しているだけの場合は、このセクションをスキップできます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:16 -msgid "Types of modules" -msgstr "モジュールの種類" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:18 -msgid "Ansible supports several different types of modules in its code base. Some of these are for backwards compatibility and others are to enable flexibility." -msgstr "Ansible は、コードベースでいくつかの異なるタイプのモジュールをサポートしています。下位互換性のためのものもあり、柔軟性を可能にするものもあります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:26 -msgid "Action plugins look like modules to anyone writing a playbook. Usage documentation for most action plugins lives inside a module of the same name. Some action plugins do all the work, with the module providing only documentation. Some action plugins execute modules. The ``normal`` action plugin executes modules that don't have special action plugins. Action plugins always execute on the controller." -msgstr "アクションプラグインは、Playbook を作成する人にとってはモジュールのように見えます。ほとんどのアクションプラグインの使用方法に関するドキュメントは、同じ名前のモジュール内にあります。アクションプラグインの中には、すべての作業を行なうものもありますが、このモジュールはドキュメントのみを提供します。一部のアクションプラグインはモジュールを実行します。``normal`` アクションプラグインは、特別なアクションプラグインを持たないモジュールを実行します。アクションプラグインは常にコントローラーで実行します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:28 -msgid "Some action plugins do all their work on the controller. For example, the :ref:`debug ` action plugin (which prints text for the user to see) and the :ref:`assert ` action plugin (which tests whether values in a playbook satisfy certain criteria) execute entirely on the controller." -msgstr "アクションプラグインによってコントローラーですべての作業が機能します。たとえば、:ref:`debug ` アクションプラグイン (ユーザーのテキストを出力する) および :ref:`assert ` アクションプラグイン (Playbook が特定の基準を満たすかどうかをテスト) など、コントローラー上で完全に実行します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:33 -msgid "Most action plugins set up some values on the controller, then invoke an actual module on the managed node that does something with these values. For example, the :ref:`template ` action plugin takes values from the user to construct a file in a temporary location on the controller using variables from the playbook environment. It then transfers the temporary file to a temporary file on the remote system. After that, it invokes the :ref:`copy module ` which operates on the remote system to move the file into its final location, sets file permissions, and so on." -msgstr "ほとんどのアクションプラグインは、コントローラーにいくつかの値を設定した後、管理ノードで実際のモジュールを呼び出して、これらの値を使用して何かを行います。たとえば、:ref:`template ` アクションプラグインは、ユーザーから値を受け取り、Playbook 環境からの変数を使用して、コントローラーの一時的な場所にファイルを作成します。その後、その一時ファイルをリモートシステム上の一時ファイルに転送します。その後、リモートシステム上で動作する :ref:`copy モジュール ` を起動して、ファイルを最終的な場所に移動させ、ファイルのパーミッションを設定するなどの作業を行います。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:44 -msgid "New-style modules" -msgstr "新スタイルのモジュール" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:46 -msgid "All of the modules that ship with Ansible fall into this category. While you can write modules in any language, all official modules (shipped with Ansible) use either Python or PowerShell." -msgstr "Ansible に同梱されるモジュールはすべてこのカテゴリーに分類されます。モジュールは任意の言語で記述できますが、(Ansible に同梱されている) 正式なモジュールはすべて Python または PowerShell を使用します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:48 -msgid "New-style modules have the arguments to the module embedded inside of them in some manner. Old-style modules must copy a separate file over to the managed node, which is less efficient as it requires two over-the-wire connections instead of only one." -msgstr "新しいスタイルのモジュールには、何らかの方法で実装されているモジュールに引数があります。古いスタイルのモジュールは、管理ノードに個別のファイルを管理ノードにコピーする必要があります。これは、1 つの接続ではなく、ネットワーク上の接続が 2 つ必要であるため、効率が低くなります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:56 -msgid "Python" -msgstr "Python" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:58 -msgid "New-style Python modules use the :ref:`Ansiballz` framework for constructing modules. These modules use imports from :code:`ansible.module_utils` to pull in boilerplate module code, such as argument parsing, formatting of return values as :term:`JSON`, and various file operations." -msgstr "新しいスタイルの Python モジュールは、モジュールの構築に :ref:`Ansiballz` フレームワークを使用します。これらのモジュールは、:code:`ansible.module_utils` からインポートを使用し、引数の解析、戻り値のフォーマットなど、定型モジュールコードを、:term:`JSON`、およびさまざまなファイル操作として取得します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:63 -msgid "In Ansible, up to version 2.0.x, the official Python modules used the :ref:`module_replacer` framework. For module authors, :ref:`Ansiballz` is largely a superset of :ref:`module_replacer` functionality, so you usually do not need to understand the differences between them." -msgstr "バージョン 2.0.x までの Ansible では、公式の Python モジュールが :ref:`module_replacer` フレームワークを使用していました。:ref:`Ansiballz` は、:ref:`module_replacer` 機能の上位セットであるため、通常はモジュール作成者がこれらの違いを理解する必要はありません。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:71 -msgid "PowerShell" -msgstr "PowerShell" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:73 -msgid "New-style PowerShell modules use the :ref:`module_replacer` framework for constructing modules. These modules get a library of PowerShell code embedded in them before being sent to the managed node." -msgstr "新しいスタイルの PowerShell モジュールは、モジュールの構築に :ref:`module_replacer` フレームワークを使用します。これらのモジュールは、管理ノードに送信される前にそれらに組み込まれている PowerShell コードのライブラリーを取得します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:80 -msgid "JSONARGS modules" -msgstr "JSONARGS モジュール" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:82 -msgid "These modules are scripts that include the string ``<>`` in their body. This string is replaced with the JSON-formatted argument string. These modules typically set a variable to that value like this:" -msgstr "これらのモジュールは、本文に文字列 ``<>`` が含まれるスクリプトです。この文字列は JSON 形式の引数文字列に置き換えられます。これらのモジュールは、通常、変数を以下のような値に設定します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:90 -msgid "Which is expanded as:" -msgstr "これは以下のように展開されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:96 -msgid "Ansible outputs a :term:`JSON` string with bare quotes. Double quotes are used to quote string values, double quotes inside of string values are backslash escaped, and single quotes may appear unescaped inside of a string value. To use JSONARGS, your scripting language must have a way to handle this type of string. The example uses Python's triple quoted strings to do this. Other scripting languages may have a similar quote character that won't be confused by any quotes in the JSON or it may allow you to define your own start-of-quote and end-of-quote characters. If the language doesn't give you any of these then you'll need to write a :ref:`non-native JSON module ` or :ref:`Old-style module ` instead." -msgstr "Ansible は、:term:`JSON` の文字列を引用符なしで出力します。文字列値の引用には二重引用符が使用され、文字列値の中の二重引用符はバックスラッシュでエスケープされ、文字列値の中の一重引用符はエスケープされずに表示されることがあります。JSONARGS を使用するには、スクリプト言語がこの種の文字列を処理する方法を備えている必要があります。この例では、Python の三重引用符文字列を使用しています。他のスクリプト言語では、JSON 内の引用符と混同されないような同様の引用符文字が用意されていたり、独自の引用開始文字や引用終了文字を定義できたりする場合があります。お使いの言語がこれを提供していない場合は、代わりに :ref:`非ネイティブ JSON モジュール ` または :ref:`古いスタイルのモジュール ` を記述する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:108 -msgid "These modules typically parse the contents of ``json_arguments`` using a JSON library and then use them as native variables throughout the code." -msgstr "これらのモジュールは通常、JSON ライブラリーを使用して ``json_arguments`` のコンテンツを解析し、次にコード全体でネイティブ変数として使用します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:114 -msgid "Non-native want JSON modules" -msgstr "ネイティブ以外の JSON モジュール" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:116 -msgid "If a module has the string ``WANT_JSON`` in it anywhere, Ansible treats it as a non-native module that accepts a filename as its only command line parameter. The filename is for a temporary file containing a :term:`JSON` string containing the module's parameters. The module needs to open the file, read and parse the parameters, operate on the data, and print its return data as a JSON encoded dictionary to stdout before exiting." -msgstr "モジュールに文字列 ``WANT_JSON`` があると、Ansible は、ファイル名をコマンドラインパラメーターとしてのみ許可する非ネイティブモジュールとして扱います。ファイル名は、モジュールのパラメーターを含む :term:`JSON` 文字列を含む一時的なファイル向けです。モジュールはファイルを開き、パラメーターを読み取りおよび解析し、データで操作し、終了する前にその戻り値を JSON エンコードディレクトリーとして stdout に出力する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:123 -msgid "These types of modules are self-contained entities. As of Ansible 2.1, Ansible only modifies them to change a shebang line if present." -msgstr "これらのモジュールタイプは自己完結型エンティティーです。Ansible 2.1 以降、Ansible では、存在する場合にのみ、シバン行を変更するようにそれらを変更します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:126 -msgid "Examples of Non-native modules written in ruby are in the `Ansible for Rubyists `_ repository." -msgstr "Ruby で書かれた非ネイティブモジュールの例は、`Ansible for Rubyists `_ リポジトリーにあります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:132 -msgid "Binary modules" -msgstr "バイナリーモジュール" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:134 -msgid "From Ansible 2.2 onwards, modules may also be small binary programs. Ansible doesn't perform any magic to make these portable to different systems so they may be specific to the system on which they were compiled or require other binary runtime dependencies. Despite these drawbacks, you may have to compile a custom module against a specific binary library if that's the only way to get access to certain resources." -msgstr "Ansible 2.2 以降、モジュールは小規模のバイナリープログラムでもあります。Ansible は、これらを異なるシステムに移植できるようにする機能がないため、コンパイルされたシステムに固有のものであったり、他のバイナリーランタイムに依存したものが必要であったりします。このような欠点はありますが、特定のリソースにアクセスするための唯一の方法であれば、特定のバイナリーライブラリーに対するカスタムモジュールのコンパイルが必要になる場合があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:141 -msgid "Binary modules take their arguments and return data to Ansible in the same way as :ref:`want JSON modules `." -msgstr "バイナリモジュールは、引数を取り、:ref:`want JSON モジュール ` と同じ方法でデータを Ansible に返します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:144 -msgid "One example of a `binary module `_ written in go." -msgstr "Go で書かれた `binary module `_ バイナリーモジュールの一例" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:151 -msgid "Old-style modules" -msgstr "古いスタイルのモジュール" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:153 -msgid "Old-style modules are similar to :ref:`want JSON modules `, except that the file that they take contains ``key=value`` pairs for their parameters instead of :term:`JSON`. Ansible decides that a module is old-style when it doesn't have any of the markers that would show that it is one of the other types." -msgstr "古いスタイルのモジュールは、:ref:`want JSON modules ` と似ていますが、使用するファイルが :term:`JSON` ではなく ``key=value``の ペアをパラメータに含んでいる点が異なります。Ansible は、モジュールに他のタイプの 1 つであることを示すマーカーがないと、そのモジュールが古いスタイルであると判断します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:162 -msgid "How modules are executed" -msgstr "モジュールの実行方法" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:164 -msgid "When a user uses :program:`ansible` or :program:`ansible-playbook`, they specify a task to execute. The task is usually the name of a module along with several parameters to be passed to the module. Ansible takes these values and processes them in various ways before they are finally executed on the remote machine." -msgstr ":program:`ansible` または :program:`ansible-playbook` を使用する場合は、実行するタスクを指定します。タスクは通常、モジュールに渡す複数のパラメーターを持つモジュールの名前です。Ansible はこれらの値を取得し、さまざまな方法で処理してから、最終的にリモートマシンで実行されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:173 -msgid "Executor/task_executor" -msgstr "Executor/task_executor" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:175 -msgid "The TaskExecutor receives the module name and parameters that were parsed from the :term:`playbook ` (or from the command line in the case of :command:`/usr/bin/ansible`). It uses the name to decide whether it's looking at a module or an :ref:`Action Plugin `. If it's a module, it loads the :ref:`Normal Action Plugin ` and passes the name, variables, and other information about the task and play to that Action Plugin for further processing." -msgstr "TaskExecutor は、:term:`playbook ` (:command:`/usr/bin/ansible` の場合はコマンドライン) から解析されたモジュール名とパラメーターを受け取ります。これは、モジュールを見て、または :ref:`Action Plugin ` を見ているかを判断するために名前を使用します。モジュールの場合は、:ref:`Normal Action Plugin ` を読み込み、タスクとプレイに関する名前、変数、およびその他の情報をそのアクションプラグインに渡して、さらに処理します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:186 -msgid "The ``normal`` action plugin" -msgstr "``normal`` アクションプラグイン" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:188 -msgid "The ``normal`` action plugin executes the module on the remote host. It is the primary coordinator of much of the work to actually execute the module on the managed machine." -msgstr "``normal`` アクションプラグインは、リモートホストでモジュールを実行します。管理マシンでモジュールを実際に実行する多くの作業に対する主要な調整役です。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:192 -msgid "It loads the appropriate connection plugin for the task, which then transfers or executes as needed to create a connection to that host." -msgstr "タスクに適切な接続プラグインを読み込み、そのホストへの接続を作成するために必要に応じて転送や実行を行います。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:194 -msgid "It adds any internal Ansible properties to the module's parameters (for instance, the ones that pass along ``no_log`` to the module)." -msgstr "モジュールのパラメーターに、Ansible の内部プロパティーを追加します (たとえば ``no_log`` をモジュールに渡すものなど)。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:196 -msgid "It works with other plugins (connection, shell, become, other action plugins) to create any temporary files on the remote machine and cleans up afterwards." -msgstr "これは、他のプラグイン (connection、shell、become、その他の action プラグイン) と連携して、リモートマシンに一時ファイルを作成し、後で削除します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:199 -msgid "It pushes the module and module parameters to the remote host, although the :ref:`module_common ` code described in the next section decides which format those will take." -msgstr "これに、モジュールおよびモジュールパラメーターがリモートホストにプッシュされますが、次のセクションで説明する :ref:`module_common ` コードが、どの形式を取るのか決定します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:203 -msgid "It handles any special cases regarding modules (for instance, async execution, or complications around Windows modules that must have the same names as Python modules, so that internal calling of modules from other Action Plugins work.)" -msgstr "モジュールに関する特殊なケースを処理します (たとえば、非同期実行や、Python モジュールと同じ名前を持たなければならない Windows モジュールの複雑さなど。これにより、他のアクションプラグインからのモジュールの内部呼び出しが機能します)。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:206 -msgid "Much of this functionality comes from the `BaseAction` class, which lives in :file:`plugins/action/__init__.py`. It uses the ``Connection`` and ``Shell`` objects to do its work." -msgstr "この機能の多くは、`BaseAction` クラス (:file:`plugins/action/__init__.py` にある) から取得されます。これは、``Connection`` オブジェクトおよび ``Shell`` オブジェクトを使用して作業を行います。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:211 -msgid "When :term:`tasks ` are run with the ``async:`` parameter, Ansible uses the ``async`` Action Plugin instead of the ``normal`` Action Plugin to invoke it. That program flow is currently not documented. Read the source for information on how that works." -msgstr ":term:`tasks ` を ``async:`` パラメーターで実行している場合、Ansible は、Auction プラグイン ``normal`` の代わりに ``async`` を使用してそれを呼び出します。そのプログラムフローは現在文書化されていません。それがどのように機能するかについては、ソースをお読みください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:219 -msgid "Executor/module_common.py" -msgstr "Executor/module_common.py" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:221 -msgid "Code in :file:`executor/module_common.py` assembles the module to be shipped to the managed node. The module is first read in, then examined to determine its type:" -msgstr ":file:`executor/module_common.py` は、管理ノードに同梱するモジュールをアセンブルします。まず、モジュールは最初に読み取られ、その後はそのタイプを判断します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:225 -msgid ":ref:`PowerShell ` and :ref:`JSON-args modules ` are passed through :ref:`Module Replacer `." -msgstr ":ref:`PowerShell ` および :ref:`JSON-args modules ` は、:ref:`Module Replacer ` 経由で渡されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:226 -msgid "New-style :ref:`Python modules ` are assembled by :ref:`Ansiballz`." -msgstr "新しいスタイルの :ref:`Python modules ` は :ref:`Ansiballz` によってアセンブルされます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:227 -msgid ":ref:`Non-native-want-JSON `, :ref:`Binary modules `, and :ref:`Old-Style modules ` aren't touched by either of these and pass through unchanged." -msgstr ":ref:`Non-native-want-JSON `、:ref:`バイナリーモジュール `、および:ref:`古いスタイルのモジュール ` は、これらのどちらにも触れられず、変更されずにそのまま通過します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:229 -msgid "After the assembling step, one final modification is made to all modules that have a shebang line. Ansible checks whether the interpreter in the shebang line has a specific path configured via an ``ansible_$X_interpreter`` inventory variable. If it does, Ansible substitutes that path for the interpreter path given in the module. After this, Ansible returns the complete module data and the module type to the :ref:`Normal Action ` which continues execution of the module." -msgstr "アセンブル手順後、シバン行を持つすべてのモジュールに最終変更が行われます。Ansible は、シバン行内のインタープリターに ``ansible_$X_interpreter`` インベントリー変数を介して特定のパスが設定されているかどうかを確認します。存在する場合には、Ansible は、そのパスを、そのモジュールに指定されているインタープリターパスに置き換えます。その後、Ansible は完全なモジュールデータを返し、モジュールタイプを :ref:`Normal Action ` に返し、モジュールの実行を続行します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:239 -msgid "Assembler frameworks" -msgstr "アセンブラーフレームワーク" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:241 -msgid "Ansible supports two assembler frameworks: Ansiballz and the older Module Replacer." -msgstr "Ansible は、2 つのアセンブラフレームワーク (Ansiballz と古い Module Replacer) をサポートしています。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:246 -msgid "Module Replacer framework" -msgstr "Module Replacer フレームワーク" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:248 -msgid "The Module Replacer framework is the original framework implementing new-style modules, and is still used for PowerShell modules. It is essentially a preprocessor (like the C Preprocessor for those familiar with that programming language). It does straight substitutions of specific substring patterns in the module file. There are two types of substitutions:" -msgstr "モジュール置換フレームワークは、新しいスタイルモジュールを実装し、引き続き PowerShell モジュール向けに使用されています。基本的には、(そのプログラミング言語に精通している C プロセッサーなど) です。モジュールファイル内の特定のサブストリングパターンを直接置換します。置換には 2 つのタイプがあります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:254 -msgid "Replacements that only happen in the module file. These are public replacement strings that modules can utilize to get helpful boilerplate or access to arguments." -msgstr "モジュールファイルでのみ実行する置換。モジュールは、便利なボイラープレートや引数へのアクセスに使用できるパブリックの置換文字列です。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:258 -msgid ":code:`from ansible.module_utils.MOD_LIB_NAME import *` is replaced with the contents of the :file:`ansible/module_utils/MOD_LIB_NAME.py` These should only be used with :ref:`new-style Python modules `." -msgstr ":code:`from ansible.module_utils.MOD_LIB_NAME import *` は、:file:`ansible/module_utils/MOD_LIB_NAME.py` の内容に置き換えます。これらは、:ref:`new-style Python modules ` と併用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:261 -msgid ":code:`#<>` is equivalent to :code:`from ansible.module_utils.basic import *` and should also only apply to new-style Python modules." -msgstr ":code:`#<>` は、:code:`from ansible.module_utils.basic import *` と同等で、新しいスタイルの Python モジュールのみに適用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:264 -msgid ":code:`# POWERSHELL_COMMON` substitutes the contents of :file:`ansible/module_utils/powershell.ps1`. It should only be used with :ref:`new-style Powershell modules `." -msgstr ":code:`# POWERSHELL_COMMON` は、:file:`ansible/module_utils/powershell.ps1` の内容を置き換えます。これは、:ref:`新しいスタイルの Powershell モジュール ` と併用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:268 -msgid "Replacements that are used by ``ansible.module_utils`` code. These are internal replacement patterns. They may be used internally, in the above public replacements, but shouldn't be used directly by modules." -msgstr "``ansible.module_utils`` コードにより使用される代替品。これらは内部交換パターンです。これらは、上記のパブリック置換で内部的に使用できますが、モジュールによって直接使用しないでください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:270 -msgid ":code:`\"<>\"` is substituted with the Ansible version. In :ref:`new-style Python modules ` under the :ref:`Ansiballz` framework the proper way is to instead instantiate an `AnsibleModule` and then access the version from :attr:``AnsibleModule.ansible_version``." -msgstr ":code:`\"<>\"` は、Ansible バージョンに置き換えられます。:ref:`Ansiballz` フレームワークの下の :ref:`new-style Python modules ` で適切な方法は、代わりに `AnsibleModule` をインスタンス化したと、:attr:``AnsibleModule.ansible_version`` からバージョンにアクセスすることです。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:275 -msgid ":code:`\"<>\"` is substituted with a string which is the Python ``repr`` of the :term:`JSON` encoded module parameters. Using ``repr`` on the JSON string makes it safe to embed in a Python file. In new-style Python modules under the Ansiballz framework this is better accessed by instantiating an `AnsibleModule` and then using :attr:`AnsibleModule.params`." -msgstr ":code:`\"<>\"` は、:term:`JSON` でエンコードされたモジュールパラメーターの Python ``repr`` の文字列に置き換えます。JSON 文字列で ``repr`` を使用すると、Python ファイルに安全に埋め込むことができます。Ansiballz フレームワークの新しいスタイル Python モジュールでは、`AnsibleModule` をインスタンス化してから :attr:`AnsibleModule.params` を使用することで、これはより適切にアクセスされます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:281 -msgid ":code:`<>` substitutes a string which is a comma separated list of file systems which have a file system dependent security context in SELinux. In new-style Python modules, if you really need this you should instantiate an `AnsibleModule` and then use :attr:`AnsibleModule._selinux_special_fs`. The variable has also changed from a comma separated string of file system names to an actual python list of filesystem names." -msgstr ":code:`<>` は、SELinux にファイルシステムに依存するファイルシステムのカンマ区切りの一覧である文字列を置き換えます。新しいスタイルの Python モジュールで `AnsibleModule` をインスタンス化してから、:attr:`AnsibleModule._selinux_special_fs` を使用してください。また、この変数は、ファイルシステム名のカンマ区切りの文字列から、実際の python のリストに変更されています。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:288 -msgid ":code:`<>` substitutes the module parameters as a JSON string. Care must be taken to properly quote the string as JSON data may contain quotes. This pattern is not substituted in new-style Python modules as they can get the module parameters another way." -msgstr ":code:`<>` はモジュールパラメーターを JSON 文字列として置き換えます。JSON データには引用符が含まれている可能性があるため、文字列を適切に引用符で囲むように注意する必要があります。このパターンは、モジュールパラメータを別の方法で取得できるため、新しいスタイルの Python モジュールでは置き換えられません。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:293 -msgid "The string :code:`syslog.LOG_USER` is replaced wherever it occurs with the ``syslog_facility`` which was named in :file:`ansible.cfg` or any ``ansible_syslog_facility`` inventory variable that applies to this host. In new-style Python modules this has changed slightly. If you really need to access it, you should instantiate an `AnsibleModule` and then use :attr:`AnsibleModule._syslog_facility` to access it. It is no longer the actual syslog facility and is now the name of the syslog facility. See the :ref:`documentation on internal arguments ` for details." -msgstr "文字列 :code:`syslog.LOG_USER` は、:file:`ansible.cfg` またはこのホストに適用される ``ansible_syslog_facility`` インベントリー変数で囲まれている ``syslog_facility`` に置き換えられます。新しいスタイルの Python モジュールでは、これは若干変更になりました。本当にアクセスする必要がある場合は、`AnsibleModule` をインスタンス化し、その後 :attr:`AnsibleModule._syslog_facility` を使用してアクセスする必要があります。これは実際の syslog 機能ではなく、syslog 機能の名前になります。詳細は、:ref:`documentation on internal arguments ` を参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:306 -msgid "Ansiballz framework" -msgstr "Ansiballz フレームワーク" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:308 -msgid "The Ansiballz framework was adopted in Ansible 2.1 and is used for all new-style Python modules. Unlike the Module Replacer, Ansiballz uses real Python imports of things in :file:`ansible/module_utils` instead of merely preprocessing the module. It does this by constructing a zipfile -- which includes the module file, files in :file:`ansible/module_utils` that are imported by the module, and some boilerplate to pass in the module's parameters. The zipfile is then Base64 encoded and wrapped in a small Python script which decodes the Base64 encoding and places the zipfile into a temp directory on the managed node. It then extracts just the Ansible module script from the zip file and places that in the temporary directory as well. Then it sets the PYTHONPATH to find Python modules inside of the zip file and imports the Ansible module as the special name, ``__main__``. Importing it as ``__main__`` causes Python to think that it is executing a script rather than simply importing a module. This lets Ansible run both the wrapper script and the module code in a single copy of Python on the remote machine." -msgstr "Ansiblez フレームワークは Ansible 2.1 で採用され、すべての新しいスタイルの Python モジュールに使用されます。Module Replacer とは異なり、Ansiballz は、単にモジュールを前処理するだけではなく、:file:`ansible/module_utils` に含まれるものを実際に Python でインポートします。これを行うには、zipfile を構築します。これには、モジュールファイル、モジュールがインポートする :file:`ansible/module_utils` のファイル、およびモジュールのパラメーターを渡すボイラープレートが含まれます。その後、zipfile は Base64 でエンコードされ、小さな Python スクリプトでラップされます。このスクリプトは Base64 エンコードをデコードし、zipfile を管理対象ノードの一時ディレクトリーに配置します。その後、zip ファイルから Ansible モジュールスクリプトのみを抽出し、一時ディレクトリーに配置します。その後、PYTHONPATH を設定して、zip ファイルから Python モジュールを検索し、Ansible モジュールを特殊な名前 ``__main__`` としてインポートします。``__main__`` としてインポートすると、Python は単にモジュールをインポートするのではなく、スクリプトを実行していると見なすようになります。これにより、Ansible は、ラッパースクリプトとモジュールコードの両方を、リモートマシン上の Python の単一コピーで実行できます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:322 -msgid "Ansible wraps the zipfile in the Python script for two reasons:" -msgstr "Ansible が Python スクリプトで zip ファイルをラップするには、以下の 2 つの理由があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:324 -msgid "for compatibility with Python 2.6 which has a less functional version of Python's ``-m`` command line switch." -msgstr "Python の ``-m`` コマンドラインスイッチの機能が少ない Python 2.6 との互換性のため。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:327 -msgid "so that pipelining will function properly. Pipelining needs to pipe the Python module into the Python interpreter on the remote node. Python understands scripts on stdin but does not understand zip files." -msgstr "パイプ処理が適切に機能します。Pipelining は Python モジュールをリモートノード上の Python インタープリターにパイプする必要があります。Python は stdin のスクリプトを理解しますが、zip ファイルを理解しません。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:331 -msgid "Prior to Ansible 2.7, the module was executed via a second Python interpreter instead of being executed inside of the same process. This change was made once Python-2.4 support was dropped to speed up module execution." -msgstr "Ansible 2.7 より前のバージョンでは、同じプロセス内で実行されるのではなく 2 つ目の Python インタープリター経由で実行されます。この変更は、Python-2.4 サポートが破棄され、モジュール実行のスピードを高めました。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:335 -msgid "In Ansiballz, any imports of Python modules from the :py:mod:`ansible.module_utils` package trigger inclusion of that Python file into the zipfile. Instances of :code:`#<>` in the module are turned into :code:`from ansible.module_utils.basic import *` and :file:`ansible/module-utils/basic.py` is then included in the zipfile. Files that are included from :file:`module_utils` are themselves scanned for imports of other Python modules from :file:`module_utils` to be included in the zipfile as well." -msgstr "Ansiballzでは、：:py:mod:`ansible.module_utils` パッケージからの Python モジュールのインポートにより、その Python ファイルを zip ファイルに含めることを誘発します。モジュール内の :code:`#<>` のインスタンスは :code:`from ansible.module_utils.basic import *` に変換され、その後 :file:`ansible/module-utils/basic.py` が zip ファイルに含まれます。:file:`module_utils` から同梱されるファイルは、それ自体が :file:`module_utils` からの他の Python モジュールのインポートをスキャンし、同じように zip ファイルに同梱されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:345 -msgid "At present, the Ansiballz Framework cannot determine whether an import should be included if it is a relative import. Always use an absolute import that has :py:mod:`ansible.module_utils` in it to allow Ansiballz to determine that the file should be included." -msgstr "現状、Aweraiballz Framework は、相対インポートの場合にインポートを含める必要があるかどうかを判別できません。常に、:py:mod:`ansible.module_utils` を持つ絶対インポートを使用して、このファイルを同梱する必要があると判断することができます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:354 -msgid "Passing args" -msgstr "引数を渡す" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:356 -msgid "Arguments are passed differently by the two frameworks:" -msgstr "以下の 2 つのフレームワークでは、引数の渡し方が異なります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:358 -msgid "In :ref:`module_replacer`, module arguments are turned into a JSON-ified string and substituted into the combined module file." -msgstr ":ref:`module_replacer` では、モジュールの引数は JSON 化された文字列に変換され、結合されたモジュールファイルに置き換えられます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:359 -msgid "In :ref:`Ansiballz`, the JSON-ified string is part of the script which wraps the zipfile. Just before the wrapper script imports the Ansible module as ``__main__``, it monkey-patches the private, ``_ANSIBLE_ARGS`` variable in ``basic.py`` with the variable values. When a :class:`ansible.module_utils.basic.AnsibleModule` is instantiated, it parses this string and places the args into :attr:`AnsibleModule.params` where it can be accessed by the module's other code." -msgstr ":ref:`Ansiballz` では、JSON 化された文字列は、zip ファイルをラップするスクリプトの一部です。ラッパースクリプトが Ansible モジュールを ``__main__`` としてインポートする直前に、``basic.py`` のプライベート変数 ``_ANSIBLE_ARGS`` を変数値でモンキーパッチしています。:class:`ansible.module_utils.basic.AnsibleModule` がインスタンス化されると、この文字列を解析し、引数を :attr:`AnsibleModule.params` に配置し、モジュールの他のコードがアクセスできる場所に置きます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:362 -msgid "If you are writing modules, remember that the way we pass arguments is an internal implementation detail: it has changed in the past and will change again as soon as changes to the common module_utils code allow Ansible modules to forgo using :class:`ansible.module_utils.basic.AnsibleModule`. Do not rely on the internal global ``_ANSIBLE_ARGS`` variable." -msgstr "モジュールを作成している場合は、引数を渡す方法は内部実装の詳細であることに注意してください。これは過去に変更されており、共通の module_utils コードを変更すると、Ansible モジュールが :class:`ansible.module_utils.basic.AnsibleModule` の使用をやめるとすぐに再び変更されます。内部グローバル変数 ``_ANSIBLE_ARGS`` に依存しないでください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:365 -msgid "Very dynamic custom modules which need to parse arguments before they instantiate an ``AnsibleModule`` may use ``_load_params`` to retrieve those parameters. Although ``_load_params`` may change in breaking ways if necessary to support changes in the code, it is likely to be more stable than either the way we pass parameters or the internal global variable." -msgstr "``AnsibleModule`` をインスタンス化する前に引数を解析する必要のある非常に動的なカスタムモジュールは、``_load_params`` を使用してこれらのパラメーターを取得する場合があります。しかし、コードの変更をサポートする必要がある場合、``_load_params`` はパラメーターを渡す方法よりも安定性があるか、内部グローバル変数を渡す方法よりも安定性があると考えられます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:371 -msgid "Prior to Ansible 2.7, the Ansible module was invoked in a second Python interpreter and the arguments were then passed to the script over the script's stdin." -msgstr "Ansible 2.7 より前のバージョンでは、Ansible モジュールは 2 番目の Python インタープリターで呼び出され、引数はスクリプトの標準入力 (stdin) を介してスクリプトに渡されていました。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:378 -msgid "Internal arguments" -msgstr "内部引数" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:380 -msgid "Both :ref:`module_replacer` and :ref:`Ansiballz` send additional arguments to the module beyond those which the user specified in the playbook. These additional arguments are internal parameters that help implement global Ansible features. Modules often do not need to know about these explicitly as the features are implemented in :py:mod:`ansible.module_utils.basic` but certain features need support from the module so it's good to know about them." -msgstr ":ref:`module_replacer` および :ref:`Ansiballz` の両方は、Playbook で指定したユーザー以外に追加の引数をモジュールに送信します。これらの追加の引数は、Ansible のグローバル機能の実装に役立つ内部パラメーターです。これらの機能は、:py:mod:`ansible.module_utils.basic` に実装されているため、モジュールが明示的に理解する必要がないことがしばしばありますが、機能についてある程度理解できるように、モジュールから特定の機能のサポートが必要になります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:387 -msgid "The internal arguments listed here are global. If you need to add a local internal argument to a custom module, create an action plugin for that specific module - see ``_original_basename`` in the `copy action plugin `_ for an example." -msgstr "ここに記載されている内部引数はグローバルです。カスタムモジュールにローカルの内部引数を追加する必要がある場合は、その特定のモジュール用のアクションプラグインを作成してください。例は、「`copy action plugin `_」の「``_original_basename``」を参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:390 -msgid "_ansible_no_log" -msgstr "_ansible_no_log" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:392 -msgid "Boolean. Set to True whenever a parameter in a task or play specifies ``no_log``. Any module that calls :py:meth:`AnsibleModule.log` handles this automatically. If a module implements its own logging then it needs to check this value. To access in a module, instantiate an ``AnsibleModule`` and then check the value of :attr:`AnsibleModule.no_log`." -msgstr "ブール値。タスクまたはプレイのパラメーターを ``no_log`` に指定した場合は True に設定します。:py:meth:`AnsibleModule.log` を呼び出すモジュールが自動的にこれを処理します。モジュールがその独自のロギングを実装した場合は、この値を確認する必要があります。モジュールにアクセスするには、``AnsibleModule`` をインスタンス化して、:attr:`AnsibleModule.no_log` の値を確認します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:397 -msgid "``no_log`` specified in a module's argument_spec is handled by a different mechanism." -msgstr "モジュールの argument_spec で指定された ``no_log`` は別のメカニズムで処理されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:400 -msgid "_ansible_debug" -msgstr "_ansible_debug" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:402 -msgid "Boolean. Turns more verbose logging on or off and turns on logging of external commands that the module executes. If a module uses :py:meth:`AnsibleModule.debug` rather than :py:meth:`AnsibleModule.log` then the messages are only logged if ``_ansible_debug`` is set to ``True``. To set, add ``debug: True`` to :file:`ansible.cfg` or set the environment variable :envvar:`ANSIBLE_DEBUG`. To access in a module, instantiate an ``AnsibleModule`` and access :attr:`AnsibleModule._debug`." -msgstr "ブール値。詳細なロギングをオンまたはオフにし、モジュールが実行する外部コマンドのロギングを有効にします。モジュールが :py:meth:`AnsibleModule.log` ではなく :py:meth:`AnsibleModule.debug` を使用する場合は、``_ansible_debug`` が ``True`` に設定されている場合にのみメッセージがログに記録されます。設定するには、``debug: True`` を :file:`ansible.cfg` に追加するか、環境変数 :envvar:`ANSIBLE_DEBUG` を設定します。モジュールにアクセスするには、``AnsibleModule`` をインスタンス化し、:attr:`AnsibleModule._debug` にアクセスします。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:411 -msgid "_ansible_diff" -msgstr "_ansible_diff" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:413 -msgid "Boolean. If a module supports it, tells the module to show a unified diff of changes to be made to templated files. To set, pass the ``--diff`` command line option. To access in a module, instantiate an `AnsibleModule` and access :attr:`AnsibleModule._diff`." -msgstr "ブール値。モジュールがサポートする場合は、モジュールに対し、テンプレート化されたファイルに加えられた変更の差異を統合するためにモジュールに指示します。設定するには、``--diff`` コマンドラインオプションを渡します。モジュールにアクセスするには、`AnsibleModule` をインスタンス化して、:attr:`AnsibleModule._diff` にアクセスしてください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:419 -msgid "_ansible_verbosity" -msgstr "_ansible_verbosity" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:421 -msgid "Unused. This value could be used for finer grained control over logging." -msgstr "未使用。この値は、ログをより細かく制御するために使用できます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:424 -msgid "_ansible_selinux_special_fs" -msgstr "_ansible_selinux_special_fs" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:426 -msgid "List. Names of filesystems which should have a special SELinux context. They are used by the `AnsibleModule` methods which operate on files (changing attributes, moving, and copying). To set, add a comma separated string of filesystem names in :file:`ansible.cfg`::" -msgstr "一覧。特別な SELinux コンテキストを持つ必要があるファイルシステムの名前。名前はファイル (属性の変更、移動、コピー) で操作する `AnsibleModule` メソッドによって使用されます。設定するには、:file:`ansible.cfg` に、ファイル名のコンマ区切りの文字列を追加します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:434 -msgid "Most modules can use the built-in ``AnsibleModule`` methods to manipulate files. To access in a module that needs to know about these special context filesystems, instantiate an ``AnsibleModule`` and examine the list in :attr:`AnsibleModule._selinux_special_fs`." -msgstr "ほとんどのモジュールは、ファイルを操作する組み込み ``AnsibleModule`` メソッドを使用できます。これらの特別なコンテキストファイルシステムについて知る必要があるモジュールにアクセスするには、``AnsibleModule`` をインスタンス化し、:attr:`AnsibleModule._selinux_special_fs` でリストを調べます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:438 -msgid "This replaces :attr:`ansible.module_utils.basic.SELINUX_SPECIAL_FS` from :ref:`module_replacer`. In module replacer it was a comma separated string of filesystem names. Under Ansiballz it's an actual list." -msgstr "これにより、:ref:`module_replacer` の :attr:`ansible.module_utils.basic.SELINUX_SPECIAL_FS` を置き換えます。モジュール置換は、ファイル名のコンマ区切りの文字列でした。Ansiballz は、実際のリストになります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:445 -msgid "_ansible_syslog_facility" -msgstr "_ansible_syslog_facility" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:447 -msgid "This parameter controls which syslog facility Ansible module logs to. To set, change the ``syslog_facility`` value in :file:`ansible.cfg`. Most modules should just use :meth:`AnsibleModule.log` which will then make use of this. If a module has to use this on its own, it should instantiate an `AnsibleModule` and then retrieve the name of the syslog facility from :attr:`AnsibleModule._syslog_facility`. The Ansiballz code is less hacky than the old :ref:`module_replacer` code:" -msgstr "このパラメーターは、Ansible モジュールがどの syslog 機能にログに記録するかを制御します。設定するには、:file:`ansible.cfg` の ``syslog_facility`` の値を変更します。多くのモジュールは、これを使用する :meth:`AnsibleModule.log` のみを使用する必要があります。モジュールが独自にこれを使用する必要がある場合は、`AnsibleModule` をインスタンス化して、:attr:`AnsibleModule._syslog_facility` から syslog 機能の名前を取得する必要があります。Ansiballz コードは古い :ref:`module_replacer` コードよりもハッキングされません。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:468 -msgid "_ansible_version" -msgstr "_ansible_version" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:470 -msgid "This parameter passes the version of Ansible that runs the module. To access it, a module should instantiate an `AnsibleModule` and then retrieve it from :attr:`AnsibleModule.ansible_version`. This replaces :attr:`ansible.module_utils.basic.ANSIBLE_VERSION` from :ref:`module_replacer`." -msgstr "このパラメーターは、モジュールを実行する Ansible のバージョンを渡します。これにアクセスするために、モジュールは `AnsibleModule` をインスタンス化し、:attr:`AnsibleModule.ansible_version` から取得する必要があります。これは、:ref:`module_replacer` の :attr:`ansible.module_utils.basic.ANSIBLE_VERSION` を置き換えます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:482 -msgid "Module return values & Unsafe strings" -msgstr "モジュール戻り値と安全でない文字列" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:484 -msgid "At the end of a module's execution, it formats the data that it wants to return as a JSON string and prints the string to its stdout. The normal action plugin receives the JSON string, parses it into a Python dictionary, and returns it to the executor." -msgstr "モジュールの実行の最後に、返したいデータを JSON 文字列としてフォーマットし、その文字列を標準出力 (stdout) に出力します。normal アクションプラグインは JSON 文字列を受け取り、Python ディクショナリーに解析してエクゼキューターに返します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:486 -msgid "If Ansible templated every string return value, it would be vulnerable to an attack from users with access to managed nodes. If an unscrupulous user disguised malicious code as Ansible return value strings, and if those strings were then templated on the controller, Ansible could execute arbitrary code. To prevent this scenario, Ansible marks all strings inside returned data as ``Unsafe``, emitting any Jinja2 templates in the strings verbatim, not expanded by Jinja2." -msgstr "Ansible がすべての文字列の戻り値をテンプレート化すると、管理ノードにアクセスできるユーザーからの攻撃に対して脆弱になります。悪意のあるユーザーが悪意のあるコードを Ansible の戻り値の文字列として偽装し、そのような文字列がコントローラー上でテンプレート化されると、Ansible が任意のコードを実行する可能性があります。このシナリオを防ぐために、Ansible は戻り値のデータ内のすべての文字列を ``Unsafe`` としてマークし、文字列内の Jinja2 テンプレートを Jinja2 で展開せずにそのままエミットします。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:488 -msgid "Strings returned by invoking a module through ``ActionPlugin._execute_module()`` are automatically marked as ``Unsafe`` by the normal action plugin. If another action plugin retrieves information from a module through some other means, it must mark its return data as ``Unsafe`` on its own." -msgstr "``ActionPlugin._execute_module()`` を介してモジュールを呼び出して返された文字列には、normal アクションプラグインによって自動的に ``Unsafe`` というマークが付きます。別のアクションプラグインが他の方法でモジュールから情報を取得した場合は、そのアクションプラグイン自身がその戻り値に ``Unsafe`` マークを付ける必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:490 -msgid "In case a poorly-coded action plugin fails to mark its results as \"Unsafe,\" Ansible audits the results again when they are returned to the executor, marking all strings as ``Unsafe``. The normal action plugin protects itself and any other code that it calls with the result data as a parameter. The check inside the executor protects the output of all other action plugins, ensuring that subsequent tasks run by Ansible will not template anything from those results either." -msgstr "不適切にコーディングされたアクションプラグインが結果を「Unsafe」と表示しなかった場合、Ansible は実行者に返される際に結果を再度監査し、すべての文字列を ``Unsafe`` と表示します。通常のアクションプラグインは、自分自身と、結果データをパラメーターとして呼び出した他のコードを保護します。エクゼキュータ内のチェックは、他のすべてのアクションプラグインの出力を保護し、Ansible が実行する後続のタスクがこれらの結果から何かをテンプレート化することがないようにします。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:496 -msgid "Special considerations" -msgstr "特別な考慮事項" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:501 -msgid "Pipelining" -msgstr "パイプライン" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:503 -msgid "Ansible can transfer a module to a remote machine in one of two ways:" -msgstr "Ansible は、以下のいずれかの方法で、モジュールをリモートマシンに転送できます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:505 -msgid "it can write out the module to a temporary file on the remote host and then use a second connection to the remote host to execute it with the interpreter that the module needs" -msgstr "これは、リモートホストの一時ファイルにモジュールを書き込むことができ、次にリモートホストへの 2 番目の接続を使用して、モジュールが必要とするインタープリターでこれを実行します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:508 -msgid "or it can use what's known as pipelining to execute the module by piping it into the remote interpreter's stdin." -msgstr "または、パイプラインと呼ばれるものを使用して、モジュールをリモートインタープリターの stdin にパイプすることでモジュールを実行できます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:511 -msgid "Pipelining only works with modules written in Python at this time because Ansible only knows that Python supports this mode of operation. Supporting pipelining means that whatever format the module payload takes before being sent over the wire must be executable by Python via stdin." -msgstr "パイプライン処理は、現時点では Python で記述されたモジュールでのみ機能します。これは、Python がこの操作モードをサポートしていることのみを Ansible が認識しているためです。パイプライン化をサポートするということは、モジュールペイロードがネットワーク経由で送信される前に取る形式が何であれ、Python が stdin を介して実行可能でなければならないことを意味します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:519 -msgid "Why pass args over stdin?" -msgstr "標準入力 (stdin) で引数を渡す理由" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:521 -msgid "Passing arguments via stdin was chosen for the following reasons:" -msgstr "以下の理由により、stdin で引数を渡すことが選択されました。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:523 -msgid "When combined with :ref:`ANSIBLE_PIPELINING`, this keeps the module's arguments from temporarily being saved onto disk on the remote machine. This makes it harder (but not impossible) for a malicious user on the remote machine to steal any sensitive information that may be present in the arguments." -msgstr ":ref:`ANSIBLE_PIPELINING` と組み合わせると、モジュールの引数をリモートマシン上のディスクに一時的に保存したままにします。これにより、リモートマシン上の悪意のあるユーザーが引数に存在する可能性のある機密情報を盗むのが困難になります (不可能ではありません)。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:527 -msgid "Command line arguments would be insecure as most systems allow unprivileged users to read the full commandline of a process." -msgstr "ほとんどのシステムでは、権限のないユーザーがプロセスのコマンドライン全体を読むことを許可されているため、コマンドライン引数は安全ではありません。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:529 -msgid "Environment variables are usually more secure than the commandline but some systems limit the total size of the environment. This could lead to truncation of the parameters if we hit that limit." -msgstr "環境変数は通常コマンドラインより安全ですが、環境の合計サイズを制限するシステムもあります。これにより、パラメーターが上限に達すると、パラメーターが切り捨てられる可能性があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:537 -msgid "AnsibleModule" -msgstr "AnsibleModule" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:542 -msgid "Argument spec" -msgstr "引数の仕様" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:544 -msgid "The ``argument_spec`` provided to ``AnsibleModule`` defines the supported arguments for a module, as well as their type, defaults and more." -msgstr "``AnsibleModule`` に提供される ``argument_spec`` は、モジュールでサポートされる引数、その型、デフォルトなどを定義します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:546 -msgid "Example ``argument_spec``:" -msgstr "``argument_spec`` の例:" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:562 -msgid "This section will discuss the behavioral attributes for arguments:" -msgstr "本セクションでは、引数の動作属性を説明します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:566 -msgid "``type`` allows you to define the type of the value accepted for the argument. The default value for ``type`` is ``str``. Possible values are:" -msgstr "``type`` では、引数に受け入れられる値の型を定義できます。``type`` のデフォルト値は ``str`` です。可能な値は次のとおりです。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:568 -msgid "str" -msgstr "str" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:569 -msgid "list" -msgstr "list" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:570 -msgid "dict" -msgstr "dict" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:571 -msgid "bool" -msgstr "bool" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:572 -msgid "int" -msgstr "int" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:573 -msgid "float" -msgstr "float" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:574 -msgid "path" -msgstr "path" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:575 -msgid "raw" -msgstr "raw" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:576 -msgid "jsonarg" -msgstr "jsonarg" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:577 -#: ../../rst/dev_guide/style_guide/index.rst:150 -msgid "json" -msgstr "json" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:578 -msgid "bytes" -msgstr "bytes" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:579 -msgid "bits" -msgstr "bits" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:581 -msgid "The ``raw`` type, performs no type validation or type casting, and maintains the type of the passed value." -msgstr "``raw`` 型で、型の検証や型のケーシングを行わず、渡された値の型を保持します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:585 -msgid "``elements`` works in combination with ``type`` when ``type='list'``. ``elements`` can then be defined as ``elements='int'`` or any other type, indicating that each element of the specified list should be of that type." -msgstr "``elements`` は、``type='list'`` の時に ``type`` と組み合わせて動作します。``elements`` は ``elements='int'`` などの型で定義することができ、指定されたリストの各要素がその型であることを示します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:589 -msgid "The ``default`` option allows sets a default value for the argument for the scenario when the argument is not provided to the module. When not specified, the default value is ``None``." -msgstr "``default`` オプションは、引数がモジュールに提供されていない場合のシナリオの引数のデフォルト値を設定します。指定しない場合、デフォルト値は ``None`` です。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "fallback" -msgstr "fallback" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:593 -msgid "``fallback`` accepts a ``tuple`` where the first argument is a callable (function) that will be used to perform the lookup, based on the second argument. The second argument is a list of values to be accepted by the callable." -msgstr "``fallback`` は、第 1 引数に、第 2 引数に基づいて検索を実行するために使用される callable (関数) の ``tuple`` を受け入れます。2 つ目の引数は、呼び出し可能な値のリストを指定します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:595 -msgid "The most common callable used is ``env_fallback`` which will allow an argument to optionally use an environment variable when the argument is not supplied." -msgstr "最も一般的に使用されている callable は ``env_fallback`` で、これは引数に環境変数が与えられていない場合に任意で環境変数を使用できるようにします。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:605 -msgid "``choices`` accepts a list of choices that the argument will accept. The types of ``choices`` should match the ``type``." -msgstr "``choices`` は、引数が受け入れる選択肢のリストを受け入れます。``choices`` の型は、``type`` と一致している必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:609 -msgid "``required`` accepts a boolean, either ``True`` or ``False`` that indicates that the argument is required. When not specified, ``required`` defaults to ``False``. This should not be used in combination with ``default``." -msgstr "``required`` ブール値 (``True`` または ``False`` のいずれか) も受け入れます。これは、引数が必要であることを示しています。指定しない場合、``required`` のデフォルトは ``False`` になります。これは、``default`` と組み合わせて使用しないでください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "no_log" -msgstr "no_log" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:613 -msgid "``no_log`` accepts a boolean, either ``True`` or ``False``, that indicates explicitly whether or not the argument value should be masked in logs and output." -msgstr "``no_log`` には、引数の値がログや出力でマスクされるべきかどうかを明示的に示すブール値 (``True`` または ``False``) を使用できます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:616 -msgid "In the absence of ``no_log``, if the parameter name appears to indicate that the argument value is a password or passphrase (such as \"admin_password\"), a warning will be shown and the value will be masked in logs but **not** output. To disable the warning and masking for parameters that do not contain sensitive information, set ``no_log`` to ``False``." -msgstr "``no_log`` がない場合は、パラメーター名が、引数の値がパスワードやパスフレーズであることを示しているように見える場合 (「admin_password」など)、警告が表示され、値はログでマスクされますが、**出力されません**。機密情報を含まないパラメータの警告とマスキングを無効にするには、``no_log`` を ``False`` に設定します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:620 -msgid "``aliases`` accepts a list of alternative argument names for the argument, such as the case where the argument is ``name`` but the module accepts ``aliases=['pkg']`` to allow ``pkg`` to be interchangeably with ``name``" -msgstr "``aliases`` では、引数の代替引数名のリストが使用できます。たとえば、引数が ``name`` ですが、モジュールが ``aliases=['pkg']`` を受け付けて、``pkg`` を ``name`` と互換性を持たせるようにしています。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:624 -msgid "``options`` implements the ability to create a sub-argument_spec, where the sub options of the top level argument are also validated using the attributes discussed in this section. The example at the top of this section demonstrates use of ``options``. ``type`` or ``elements`` should be ``dict`` is this case." -msgstr "``options`` では、トップレベル引数のサブオプションもこのセクションで説明した属性を使用して検証される sub-argument_spec を作成する機能を実装しています。このセクションの先頭にある例は、``options`` の使用を示しています。ここでは、``type`` または ``elements`` は ``dict`` である必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "apply_defaults" -msgstr "apply_defaults" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:628 -msgid "``apply_defaults`` works alongside ``options`` and allows the ``default`` of the sub-options to be applied even when the top-level argument is not supplied." -msgstr "``apply_defaults`` は、``options`` と並んで動作し、トップレベルの引数が指定されていない場合でもサブオプションの``デフォルト`` を適用できるようにします。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:630 -msgid "In the example of the ``argument_spec`` at the top of this section, it would allow ``module.params['top_level']['second_level']`` to be defined, even if the user does not provide ``top_level`` when calling the module." -msgstr "このセクションの先頭にある ``argument_spec`` の例では、ユーザーがモジュールを呼び出すときに ``top_level`` を指定しなかった場合でも、``module.params['top_level']['second_level']`` を定義できるようにします。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "removed_in_version" -msgstr "removed_in_version" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:634 -msgid "``removed_in_version`` indicates which version of ansible-base or a collection a deprecated argument will be removed in. Mutually exclusive with ``removed_at_date``, and must be used with ``removed_from_collection``." -msgstr "``removed_in_version`` は、非推奨の引数が削除される ansible-base またはコレクションのバージョンを示します。``removed_at_date`` で相互排他され、``removed_from_collection`` で使用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "removed_at_date" -msgstr "removed_at_date" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:648 -msgid "``removed_at_date`` indicates that a deprecated argument will be removed in a minor ansible-base release or major collection release after this date. Mutually exclusive with ``removed_in_version``, and must be used with ``removed_from_collection``." -msgstr "``removed_at_date`` は、非推奨の引数が、この日付以降のマイナーな ansible-base リリースまたはメジャーコレクションリリースで削除されることを示します。``removed_in_version`` と相互に排他的であり、``removed_from_collection`` と一緒に使用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "removed_from_collection" -msgstr "removed_from_collection" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:662 -msgid "Specifies which collection (or ansible-base) deprecates this deprecated argument. Specify ``ansible.builtin`` for ansible-base, or the collection's name (format ``foo.bar``). Must be used with ``removed_in_version`` or ``removed_at_date``." -msgstr "この非推奨の引数を非推奨にするコレクション (または ansible-base) を指定します。ansible-base には ``ansible.builtin``、またはコレクションの名前 (``foo.bar`` の形式) を指定します。``removed_in_version`` または ``removed_at_date`` と共に使用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "deprecated_aliases" -msgstr "deprecated_aliases" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:666 -msgid "Deprecates aliases of this argument. Must contain a list or tuple of dictionaries having some the following keys:" -msgstr "この引数のエイリアスを非推奨にします。以下のキーを持つディクショナリーのリストまたはタプルが含まれます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "name" -msgstr "name" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:670 -msgid "The name of the alias to deprecate. (Required.)" -msgstr "非推奨にするエイリアスの名前 (必須)" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst -msgid "version" -msgstr "version" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:674 -msgid "The version of ansible-base or the collection this alias will be removed in. Either ``version`` or ``date`` must be specified." -msgstr "ansible-base、またはこのエイリアスは削除されるコレクションのバージョン。``version`` または ``date`` のいずれかを指定する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "date" -msgstr "date" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:678 -msgid "The a date after which a minor release of ansible-base or a major collection release will no longer contain this alias.. Either ``version`` or ``date`` must be specified." -msgstr "ansible-base のマイナーリリースまたはメジャーコレクションリリースにこのエイリアスが含まれなくなった日付。``version`` または ``date`` のいずれかを指定する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "collection_name" -msgstr "collection_name" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:682 -msgid "Specifies which collection (or ansible-base) deprecates this deprecated alias. Specify ``ansible.builtin`` for ansible-base, or the collection's name (format ``foo.bar``). Must be used with ``version`` or ``date``." -msgstr "この非推奨のエイリアスを非推奨にするコレクション (または ansible-base) を指定します。ansible-base には ``ansible.builtin``、またはコレクションの名前 (``foo.bar`` の形式) を指定します。``version`` または ``date`` と共に使用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:684 -msgid "Examples:" -msgstr "例:" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "mutually_exclusive" -msgstr "mutually_exclusive" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:708 -msgid "If ``options`` is specified, ``mutually_exclusive`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`." -msgstr "``options`` を指定すると、``mutually_exclusive`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "required_together" -msgstr "required_together" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:712 -msgid "If ``options`` is specified, ``required_together`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`." -msgstr "``options`` を指定すると、``required_together`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "required_one_of" -msgstr "required_one_of" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:716 -msgid "If ``options`` is specified, ``required_one_of`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`." -msgstr "``options`` を指定すると、``required_one_of`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "required_if" -msgstr "required_if" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:720 -msgid "If ``options`` is specified, ``required_if`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`." -msgstr "``options`` を指定すると、``required_if`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "required_by" -msgstr "required_by" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:724 -msgid "If ``options`` is specified, ``required_by`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`." -msgstr "``options`` を指定すると、``required_by`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:730 -msgid "Dependencies between module options" -msgstr "モジュールオプションの依存関係" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:732 -msgid "The following are optional arguments for ``AnsibleModule()``:" -msgstr "以下は、``AnsibleModule()`` のオプションの引数です。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:748 -msgid "Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names which are mutually exclusive. If more than one options of a list are specified together, Ansible will fail the module with an error." -msgstr "文字列シーケンスのシーケンス (リストまたはタプル) です。文字列のシーケンスは相互排他的なオプション名のリストです。リストの複数のオプションを指定すると、Ansible はエラーを出してモジュールに失敗します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:759 -msgid "In this example, the options ``path`` and ``content`` must not specified at the same time. Also the options ``repository_url`` and ``repository_filename`` must not be specified at the same time. But specifying ``path`` and ``repository_url`` is accepted." -msgstr "この例では、``path`` オプションと ``content`` オプションは同時に指定しないでください。``repository_url`` オプションと ``repository_filename`` オプションを同時に指定することはできません。``path`` および ``repository_url`` を指定することはできません。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:761 -msgid "To ensure that precisely one of two (or more) options is specified, combine ``mutually_exclusive`` with ``required_one_of``." -msgstr "正確に 2 つのオプション (または複数の) オプションのいずれかを指定するようにするには、``mutually_exclusive`` と ``required_one_of`` を組み合わせます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:765 -msgid "Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names which are must be specified together. If at least one of these options are specified, the other ones from the same sequence must all be present." -msgstr "文字列のシーケンスのシーケンス (リストまたはタプル) である必要があります。文字列のすべてのシーケンスは、一緒に指定する必要があるオプション名のリストです。これらのオプションの少なくとも 1 つが指定されている場合は、同じシーケンスの他のオプションがすべて存在している必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:775 -msgid "In this example, if one of the options ``file_path`` or ``file_hash`` is specified, Ansible will fail the module with an error if the other one is not specified." -msgstr "この例では、``file_path`` または ``file_hash`` のいずれかのオプションを指定し、他のオプションが指定していないと、Ansible はエラーを出してモジュールに失敗します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:779 -msgid "Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names from which at least one must be specified. If none one of these options are specified, Ansible will fail module execution." -msgstr "文字列のシーケンスのシーケンス (リストまたはタプル) である必要があります。文字列のすべてのシーケンスは、少なくとも 1 つを指定する必要があるオプション名のリストです。これらのオプションのいずれも指定されていない場合、Ansible はモジュールの実行に失敗します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:789 -msgid "In this example, at least one of ``path`` and ``content`` must be specified. If none are specified, execution will fail. Specifying both is explicitly allowed; to prevent this, combine ``required_one_of`` with ``mutually_exclusive``." -msgstr "この例では、``path`` および ``content`` のいずれかを指定する必要があります。指定されていない場合、実行は失敗します。両方の値を指定すると、明示的に許可されます。これを回避するには、``required_one_of`` と ``mutually_exclusive`` を組み合わせます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:793 -msgid "Must be a sequence of sequences. Every inner sequence describes one conditional dependency. Every sequence must have three or four values. The first two values are the option's name and the option's value which describes the condition. The further elements of the sequence are only needed if the option of that name has precisely this value." -msgstr "一連のシーケンスのシーケンスである必要があります。すべての内部シーケンスでは、条件の依存関係を 1 つ説明します。すべてのシーケンスには、値が 3 つまたは 4 つ必要です。最初の 2 つの値の値は、3 つまたは 4 つの値でなければなりません。最初の 2 つの値はオプション名と、その条件を説明するオプションの値です。シーケンスの追加要素は、その名前のオプションが正確にこの値を持っている場合にのみ必要です。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:795 -msgid "If you want that all options in a list of option names are specified if the condition is met, use one of the following forms:" -msgstr "条件が満たされた場合にオプション名のリスト内のオプションをすべて指定する場合は、次のいずれかの形式を使用します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:802 -msgid "If you want that at least one option of a list of option names is specified if the condition is met, use the following form:" -msgstr "条件が満たされた場合にオプション名の一覧のオプションを 1 つ以上指定する場合は、以下の形式を使用します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:817 -msgid "In this example, if the user specifies ``state=present``, at least one of the options ``path`` and ``content`` must be supplied (or both). To make sure that precisely one can be specified, combine ``required_if`` with ``mutually_exclusive``." -msgstr "この例では、ユーザーが ``state=present`` を指定している場合は、``path`` と ``content`` のいずれか (または両方) のオプションを指定する必要があります。正確に指定できるようにするには、``required_if`` と ``mutually_exclusive`` を組み合わせます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:819 -msgid "On the other hand, if ``force`` (a boolean parameter) is set to ``true``, ``yes`` etc., both ``force_reason`` and ``force_code`` must be specified." -msgstr "一方、``force`` (ブール値パラメーター) が ``true``、``yes`` などに設定されている場合は、``force_reason`` と ``force_code`` の両方を指定する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:823 -msgid "Must be a dictionary mapping option names to sequences of option names. If the option name in a dictionary key is specified, the option names it maps to must all also be specified. Note that instead of a sequence of option names, you can also specify one single option name." -msgstr "オプション名のシーケンスへのディクショナリーマッピングオプション名である必要があります。辞書キーでオプション名を指定すると、そのオプション名をすべて指定する必要があります。オプション名のシーケンスの代わりに、オプションの名前を 1 つ指定することもできます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:834 -msgid "In the example, if ``force`` is specified, ``force_reason`` must also be specified. Also, if ``path`` is specified, then three three options ``mode``, ``owner`` and ``group`` also must be specified." -msgstr "この例では、``force`` が指定されている場合は、``force_reason`` も指定する必要があります。また、``path`` が指定されている場合は、3 つのオプション ``mode``、``owner``、および ``group`` も指定する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:837 -msgid "Declaring check mode support" -msgstr "チェックモードのサポートの宣言" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:839 -msgid "To declare that a module supports check mode, supply ``supports_check_mode=True`` to the ``AnsibleModule()`` call:" -msgstr "モジュールが確認モードをサポートすることを宣言するには、``AnsibleModule()`` 呼び出しに ``supports_check_mode=True`` を指定します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:845 -msgid "The module can determine whether it is called in check mode by checking the boolean value ``module.check_mode``. If it evaluates to ``True``, the module must take care not to do any modification." -msgstr "モジュールは、ブール値 ``module.check_mode`` を確認して、チェックモードで呼び出されるかどうかを判断できます。``True`` に評価する場合、モジュールは変更を行わないようにする必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:847 -msgid "If ``supports_check_mode=False`` is specified, which is the default value, the module will exit in check mode with ``skipped=True`` and message ``remote module () does not support check mode``." -msgstr "``supports_check_mode=False`` が指定されている場合 (デフォルト値)、モジュールはチェックモードで ``skipped=True`` および ``remote module () does not support check mode`` メッセージで終了します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:850 -msgid "Adding file options" -msgstr "ファイルオプションの追加" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:852 -msgid "To declare that a module should add support for all common file options, supply ``add_file_common_args=True`` to the ``AnsibleModule()`` call:" -msgstr "モジュールがすべての共通ファイルオプションのサポートを追加することを宣言するには、``add_file_common_args=True`` を ``AnsibleModule()`` 呼び出しに指定します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:858 -msgid "You can find `a list of all file options here `_. It is recommended that you make your ``DOCUMENTATION`` extend the doc fragment ``ansible.builtin.files`` (see :ref:`module_docs_fragments`) in this case, to make sure that all these fields are correctly documented." -msgstr "`a list of all file options here `_ を確認できます。今回は、``DOCUMENTATION`` がドキュメントフラグメント ``ansible.builtin.files`` (:ref:`module_docs_fragments`を参照) を拡張し、これらのフィールドがすべて正しく文書化されていることを確認することが推奨されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:860 -msgid "The helper functions ``module.load_file_common_arguments()`` and ``module.set_fs_attributes_if_different()`` can be used to handle these arguments for you:" -msgstr "ヘルパー関数 ``module.load_file_common_arguments()`` および ``module.set_fs_attributes_if_different()`` を使用して、以下の引数を扱うことができます。" - -#: ../../rst/dev_guide/developing_python_3.rst:5 -msgid "Ansible and Python 3" -msgstr "Ansible および Python 3" - -#: ../../rst/dev_guide/developing_python_3.rst:7 -msgid "The ``ansible-base`` code runs on both Python 2 and Python 3 because we want Ansible to be able to manage a wide variety of machines. Contributors to ansible-base and to Ansible Collections should be aware of the tips in this document so that they can write code that will run on the same versions of Python as the rest of Ansible." -msgstr "Ansible が各種マシンを管理できるようにするため、``ansible-base`` コードは Python 2 と Python 3 の両方で実行されます。Ansible ベースと Ansible Collections では、Ansible の残りの部分と同じバージョンの Python で実行されるコードを記述できる必要があります。" - -#: ../../rst/dev_guide/developing_python_3.rst:13 -msgid "To ensure that your code runs on Python 3 as well as on Python 2, learn the tips and tricks and idioms described here. Most of these considerations apply to all three types of Ansible code:" -msgstr "Python 2 および Python 2 でコードが実行されるようにするには、ここで説明するヒントとコツ、およびイディオムを確認してください。これらの考慮事項は、これら 3 種類の Ansible コードのすべてに適用されます。" - -#: ../../rst/dev_guide/developing_python_3.rst:16 -msgid "controller-side code - code that runs on the machine where you invoke :command:`/usr/bin/ansible`" -msgstr "コントローラー側のコード: :command:`/usr/bin/ansible` を呼び出すマシンで実行されるコード" - -#: ../../rst/dev_guide/developing_python_3.rst:17 -msgid "modules - the code which Ansible transmits to and invokes on the managed machine." -msgstr "モジュール - 管理マシンに Ansible が送信したり起動したりするコード。" - -#: ../../rst/dev_guide/developing_python_3.rst:18 -msgid "shared ``module_utils`` code - the common code that's used by modules to perform tasks and sometimes used by controller-side code as well" -msgstr "共有されている ``module_utils`` コード - タスクを実行するためにモジュールが使用する一般的なコードで、コントローラーのコードでも使用されることがあります。" - -#: ../../rst/dev_guide/developing_python_3.rst:20 -msgid "However, the three types of code do not use the same string strategy. If you're developing a module or some ``module_utils`` code, be sure to read the section on string strategy carefully." -msgstr "ただし、この 3 種類のコードで同じ文字列戦略が使用されているわけではありません。モジュールまたはいくつかの ``module_utils`` コードを開発している場合は、文字列戦略のセクションを注意してお読みください。" - -#: ../../rst/dev_guide/developing_python_3.rst:23 -msgid "Minimum version of Python 3.x and Python 2.x" -msgstr "Python 3.x および Python 2.x の最小バージョン" - -#: ../../rst/dev_guide/developing_python_3.rst:25 -msgid "On the controller we support Python 3.5 or greater and Python 2.7 or greater. Module-side, we support Python 3.5 or greater and Python 2.6 or greater." -msgstr "コントローラーでは、Python 3.5 以降、および Python 2.7 以降をサポートしています。モジュール側では、Python 3.5 以降、Python 2.6 以降をサポートします。" - -#: ../../rst/dev_guide/developing_python_3.rst:28 -msgid "Python 3.5 was chosen as a minimum because it is the earliest Python 3 version adopted as the default Python by a Long Term Support (LTS) Linux distribution (in this case, Ubuntu-16.04). Previous LTS Linux distributions shipped with a Python 2 version which users can rely upon instead of the Python 3 version." -msgstr "Python 3.5 は、長期サポート (LTS: Long Term Support) の Linux ディストリビューション (この場合は Ubuntu-16.04) でデフォルトの Python として採用されている最も古い Python 3 のバージョンであるため、最小バージョンとして採用されました。以前の LTS Linux ディストリビューションでは、Python 3 バージョンの代わりに、ユーザーが代わりに使用できる Python 2 バージョンが同梱されていました。" - -#: ../../rst/dev_guide/developing_python_3.rst:33 -msgid "For Python 2, the default is for modules to run on at least Python 2.6. This allows users with older distributions that are stuck on Python 2.6 to manage their machines. Modules are allowed to drop support for Python 2.6 when one of their dependent libraries requires a higher version of Python. This is not an invitation to add unnecessary dependent libraries in order to force your module to be usable only with a newer version of Python; instead it is an acknowledgment that some libraries (for instance, boto3 and docker-py) will only function with a newer version of Python." -msgstr "Python 2 では、モジュールは少なくとも Python 2.6 で動作することがデフォルトとなっています。これにより、Python 2.6 に固執する古いディストリビューションのユーザーが自分のマシンを管理できるようになります。モジュールは、依存するライブラリーの 1 つがより高いバージョンの Python を必要とする場合は、Python 2.6 のサポートを終了することができます。これは、自作したモジュールをより新しいバージョンの Python でしか使えないようにするために、不要な依存ライブラリーを追加することを勧めるものではありません。代わりに、いくつかのライブラリー (例えば、boto3 や docker-py) はより新しいバージョンの Python でしか機能しないことを認めています。" - -#: ../../rst/dev_guide/developing_python_3.rst:42 -msgid "Python 2.4 Module-side Support:" -msgstr "Python 2.4 モジュールでのサポート:" - -#: ../../rst/dev_guide/developing_python_3.rst:44 -msgid "Support for Python 2.4 and Python 2.5 was dropped in Ansible-2.4. RHEL-5 (and its rebuilds like CentOS-5) were supported until April of 2017. Ansible-2.3 was released in April of 2017 and was the last Ansible release to support Python 2.4 on the module-side." -msgstr "Python 2.4 および Python 2.5 のサポートは Ansible-2.4 から削除されました。RHEL-5 (および CentOS-5) は 2017 年 4 月までサポートされます。Ansible-2.3 は 2017 年 4 月にリリースされ、モジュールサイドの Python 2.4 をサポートする最後の Ansible リリースでした。" - -#: ../../rst/dev_guide/developing_python_3.rst:50 -msgid "Developing Ansible code that supports Python 2 and Python 3" -msgstr "Python 2 および Python 3 をサポートする Ansible コードの開発" - -#: ../../rst/dev_guide/developing_python_3.rst:52 -msgid "The best place to start learning about writing code that supports both Python 2 and Python 3 is `Lennart Regebro's book: Porting to Python 3 `_. The book describes several strategies for porting to Python 3. The one we're using is `to support Python 2 and Python 3 from a single code base `_" -msgstr "Python 2 と Python 3 の両方をサポートするコードの記述について学び始めるのに最適なのは、`Lennart Regebro の著書: Porting to Python 3 `_ です。本書では、Python 3 に移植するためのいくつかの戦略が説明されています。Ansible で使用しているのは、`単一のコードベースから Python 2 および Python 3 をサポートするため `_ です。" - -#: ../../rst/dev_guide/developing_python_3.rst:59 -msgid "Understanding strings in Python 2 and Python 3" -msgstr "Python 2 および Python 3 の文字列を理解" - -#: ../../rst/dev_guide/developing_python_3.rst:61 -msgid "Python 2 and Python 3 handle strings differently, so when you write code that supports Python 3 you must decide what string model to use. Strings can be an array of bytes (like in C) or they can be an array of text. Text is what we think of as letters, digits, numbers, other printable symbols, and a small number of unprintable \"symbols\" (control codes)." -msgstr "Python 2 と Python 3 では文字列の扱いが異なるため、Python 3 をサポートするコードを作成するときは、どのような文字列モデルを使用するかを決める必要があります。文字列は (C 言語のように) バイトの配列にすることもできますし、テキストの配列にすることもできます。ここでの「テキスト」とは、文字、数字 (digit または number)、その他の印刷可能な記号、および少数の印刷不可能な「記号」(制御コード) になります。" - -#: ../../rst/dev_guide/developing_python_3.rst:67 -msgid "In Python 2, the two types for these (:class:`str ` for bytes and :func:`unicode ` for text) are often used interchangeably. When dealing only with ASCII characters, the strings can be combined, compared, and converted from one type to another automatically. When non-ASCII characters are introduced, Python 2 starts throwing exceptions due to not knowing what encoding the non-ASCII characters should be in." -msgstr "Python 2 では、これらの 2 つのタイプ (バイト単位の場合は :class:`str `、テキストの場合は :func:`unicode `) が、しばしば同じ意味で使用されます。ASCII 文字のみを処理する場合は、文字列を組み合わせて比較し、あるタイプから別のタイプに自動的に変換できます。非 ASCII 文字が導入されると、Python 2 は、非 ASCII 文字がどのエンコーディングに含まれるべきかわからないために例外をスローし始めます。" - -#: ../../rst/dev_guide/developing_python_3.rst:74 -msgid "Python 3 changes this behavior by making the separation between bytes (:class:`bytes `) and text (:class:`str `) more strict. Python 3 will throw an exception when trying to combine and compare the two types. The programmer has to explicitly convert from one type to the other to mix values from each." -msgstr "Python 3 は、バイト (:class:`bytes `) とテキスト (:class:`str `) の分離をより厳格にします。Python 3 は 2 つのタイプの結合と比較を試みる際に例外を発生させます。プログラマーは、ある型から別の型に変換し、混在させる必要があります。" - -#: ../../rst/dev_guide/developing_python_3.rst:79 -msgid "In Python 3 it's immediately apparent to the programmer when code is mixing the byte and text types inappropriately, whereas in Python 2, code that mixes those types may work until a user causes an exception by entering non-ASCII input. Python 3 forces programmers to proactively define a strategy for working with strings in their program so that they don't mix text and byte strings unintentionally." -msgstr "Python 3 では、プログラマーは、コードがバイト型とテキスト型を不適切に混合していることがすぐに分かりますが、Python 2 では、ユーザーが非 ASCII 入力を入力して例外が発生するまでは、これらの型を混合しているコードが動作するかもしれません。Python 3 では、プログラマーが意図せずにテキスト文字列とバイト文字列を混在させないように、プログラムの中で文字列を扱うための戦略を積極的に定義することを強制しています。" - -#: ../../rst/dev_guide/developing_python_3.rst:85 -msgid "Ansible uses different strategies for working with strings in controller-side code, in :ref: `modules `, and in :ref:`module_utils ` code." -msgstr "Ansible は、:ref:`modules ` コードおよび :ref:`module_utils ` コードのコントローラー側のコードで文字列を操作するためにさまざまな戦略を使用します。" - -#: ../../rst/dev_guide/developing_python_3.rst:91 -msgid "Controller string strategy: the Unicode Sandwich" -msgstr "コントローラー文字列戦略: Unicode Sandwich" - -#: ../../rst/dev_guide/developing_python_3.rst:93 -msgid "In controller-side code we use a strategy known as the Unicode Sandwich (named after Python 2's :func:`unicode ` text type). For Unicode Sandwich we know that at the border of our code and the outside world (for example, file and network IO, environment variables, and some library calls) we are going to receive bytes. We need to transform these bytes into text and use that throughout the internal portions of our code. When we have to send those strings back out to the outside world we first convert the text back into bytes. To visualize this, imagine a 'sandwich' consisting of a top and bottom layer of bytes, a layer of conversion between, and all text type in the center." -msgstr "コントローラー側のコードでは、Unicode Sandwich と呼ばれるストラテジーを使用します (名前は Python 2 の :func:`unicode ` テキストタイプに由来します)。Unicode Sandwich の場合、コードと外部の境界 (ファイルやネットワークの IO、環境変数、ライブラリーの呼び出しなど) でバイトを受信することがわかります。これらのバイトをテキストに変換し、コードの内部全体でこれを使用する必要があります。これらの文字列を外部に返す必要がある場合は、最初にテキストをバイトに変換します。これは、上下にバイトの層、その間に変換の層、中央にすべてのテキストタイプからなる「サンドイッチ」を想像してください。" - -#: ../../rst/dev_guide/developing_python_3.rst:104 -msgid "Unicode Sandwich common borders: places to convert bytes to text in controller code" -msgstr "Unicode Sandwich の共通の境界: コントローラーコードのテキストにバイトを変換する場所" - -#: ../../rst/dev_guide/developing_python_3.rst:106 -msgid "This is a partial list of places where we have to convert to and from bytes when using the Unicode Sandwich string strategy. It's not exhaustive but it gives you an idea of where to watch for problems." -msgstr "これは、Unicode Sandwich 文字列ストラテジーの使用時にバイトに変換する場所の一部リストです。網羅的ではありませんが、問題を監視する場所がわかります。" - -#: ../../rst/dev_guide/developing_python_3.rst:111 -msgid "Reading and writing to files" -msgstr "ファイルの読み取りおよび書き込み" - -#: ../../rst/dev_guide/developing_python_3.rst:113 -msgid "In Python 2, reading from files yields bytes. In Python 3, it can yield text. To make code that's portable to both we don't make use of Python 3's ability to yield text but instead do the conversion explicitly ourselves. For example:" -msgstr "Python 2 では、ファイルから読み取るとバイトが生成されます。Python 3 では、テキストを生成できます。両方に移植可能なコードを作成するために、Python 3 のテキスト生成機能を利用せず、代わりに自身で明示的に変換を行います。以下に例を示します。" - -#: ../../rst/dev_guide/developing_python_3.rst:131 -msgid "Much of Ansible assumes that all encoded text is UTF-8. At some point, if there is demand for other encodings we may change that, but for now it is safe to assume that bytes are UTF-8." -msgstr "Ansible の多くは、エンコードされたテキストがすべて UTF-8 であることを前提としています。将来変更することがあるかもしれませんが、現時点では、バイトが UTF-8 であると考えて問題ありません。" - -#: ../../rst/dev_guide/developing_python_3.rst:135 -msgid "Writing to files is the opposite process:" -msgstr "ファイルへの書き込みは、その逆の処理です。" - -#: ../../rst/dev_guide/developing_python_3.rst:144 -msgid "Note that we don't have to catch :exc:`UnicodeError` here because we're transforming to UTF-8 and all text strings in Python can be transformed back to UTF-8." -msgstr "UTF-8 に変換していて、Python のテスト文字列がすべて UTF-8 に戻されるため、ここで :exc:`UnicodeError` を取得するキャッチする必要がないことに注意してください。" - -#: ../../rst/dev_guide/developing_python_3.rst:149 -msgid "Filesystem interaction" -msgstr "ファイルシステムの相互作用" - -#: ../../rst/dev_guide/developing_python_3.rst:151 -msgid "Dealing with filenames often involves dropping back to bytes because on UNIX-like systems filenames are bytes. On Python 2, if we pass a text string to these functions, the text string will be converted to a byte string inside of the function and a traceback will occur if non-ASCII characters are present. In Python 3, a traceback will only occur if the text string can't be decoded in the current locale, but it's still good to be explicit and have code which works on both versions:" -msgstr "UNIX 系システムではファイル名はバイトであるため、ファイル名を扱う際にはしばしばバイトに戻すことになります。Python 2 では、これらの関数にテキスト文字列を渡すと、テキスト文字列は関数内でバイト文字列に変換され、非 ASCII 文字が存在する場合にはトレースバックが発生します。Python 3 では、トレースバックはテキスト文字列が現在のロケールでデコードできない場合にのみ発生しますが、明示的に両方のバージョンで動作するコードを用意しておくことは良いことだと思います。" - -#: ../../rst/dev_guide/developing_python_3.rst:172 -msgid "When you are only manipulating a filename as a string without talking to the filesystem (or a C library which talks to the filesystem) you can often get away without converting to bytes:" -msgstr "ファイルシステム (またはファイルシステムと通信する C ライブラリー) と通信せずにファイル名を文字列として操作するだけの場合は、バイトに変換せずに逃げることができることがよくあります。" - -#: ../../rst/dev_guide/developing_python_3.rst:183 -msgid "On the other hand, if the code needs to manipulate the filename and also talk to the filesystem, it can be more convenient to transform to bytes right away and manipulate in bytes." -msgstr "一方、コードがファイル名を操作し、ファイルシステムとやりとりする場合は、バイトの右側にあるバイトに変換して操作する方が便利です。" - -#: ../../rst/dev_guide/developing_python_3.rst:187 -msgid "Make sure all variables passed to a function are the same type. If you're working with something like :func:`python3:os.path.join` which takes multiple strings and uses them in combination, you need to make sure that all the types are the same (either all bytes or all text). Mixing bytes and text will cause tracebacks." -msgstr "関数に渡されるすべての変数が同じタイプであることを確認します。:func:`python3:os.path.join` のように、複数の文字列を取得し、これらの変数を組み合わせて使用する場合は、すべてのタイプが同じ (すべてのバイトまたはすべてのテキストのいずれか) にする必要があります。バイトとテキストを混在させると、トレースバックが発生します。" - -#: ../../rst/dev_guide/developing_python_3.rst:194 -msgid "Interacting with other programs" -msgstr "他のプログラムとの対話" - -#: ../../rst/dev_guide/developing_python_3.rst:196 -msgid "Interacting with other programs goes through the operating system and C libraries and operates on things that the UNIX kernel defines. These interfaces are all byte-oriented so the Python interface is byte oriented as well. On both Python 2 and Python 3, byte strings should be given to Python's subprocess library and byte strings should be expected back from it." -msgstr "他のプログラムとの対話は、オペレーティングシステムと C ライブラリーを経由して、UNIX カーネルが定義するものを操作します。これらのインターフェースはすべてバイト指向であるため、Python インターフェースもバイト指向です。Python 2 と Python3 の両方で、バイト文字列は Python のサブプロセスライブラリーに渡され、バイト文字列はそこから返されることが期待されます。" - -#: ../../rst/dev_guide/developing_python_3.rst:202 -msgid "One of the main places in Ansible's controller code that we interact with other programs is the connection plugins' ``exec_command`` methods. These methods transform any text strings they receive in the command (and arguments to the command) to execute into bytes and return stdout and stderr as byte strings Higher level functions (like action plugins' ``_low_level_execute_command``) transform the output into text strings." -msgstr "Ansible のコントローラーコードで他のプログラムとやり取りする主な場所の 1 つは、接続プラグインの ``exec_command`` メソッドです。これらのメソッドは、コマンドで受け取ったテキスト文字列 (およびコマンドへの引数) をバイトに変換し、stdout と stderr をバイト文字列として返します。高レベルの関数 (アクションプラグインの ``_low_level_execute_command``) 出力をテキスト文字列に変換します。" - -#: ../../rst/dev_guide/developing_python_3.rst:212 -msgid "Module string strategy: Native String" -msgstr "モジュール文字列戦略: ネイティブ文字列" - -#: ../../rst/dev_guide/developing_python_3.rst:214 -msgid "In modules we use a strategy known as Native Strings. This makes things easier on the community members who maintain so many of Ansible's modules, by not breaking backwards compatibility by mandating that all strings inside of modules are text and converting between text and bytes at the borders." -msgstr "モジュールでは、ネイティブ文字列と呼ばれるストラテジーを採用しています。これにより、Ansible の多くのモジュールを保守しているコミュニティーメンバーは、モジュール内のすべての文字列がテキストであることを義務付けたり、境界でテキストとバイトの間を変換したりすることで、後方互換性を壊さないようにしています。" - -#: ../../rst/dev_guide/developing_python_3.rst:220 -msgid "Native strings refer to the type that Python uses when you specify a bare string literal:" -msgstr "ネイティブ文字列は、裸の文字列リテラルを指定するときに Python が使用するタイプを参照します。" - -#: ../../rst/dev_guide/developing_python_3.rst:227 -msgid "In Python 2, these are byte strings. In Python 3 these are text strings. Modules should be coded to expect bytes on Python 2 and text on Python 3." -msgstr "Python 2 では、これらはバイト文字列です。Python 3 では、これらはテキスト文字列です。Python 2 ではバイト、Python 3 ではテキストを期待するようにコード化されている必要があります。" - -#: ../../rst/dev_guide/developing_python_3.rst:233 -msgid "Module_utils string strategy: hybrid" -msgstr "Module_utils 文字列戦略: ハイブリッド" - -#: ../../rst/dev_guide/developing_python_3.rst:235 -msgid "In ``module_utils`` code we use a hybrid string strategy. Although Ansible's ``module_utils`` code is largely like module code, some pieces of it are used by the controller as well. So it needs to be compatible with modules and with the controller's assumptions, particularly the string strategy. The module_utils code attempts to accept native strings as input to its functions and emit native strings as their output." -msgstr "``module_utils`` コードでは、ハイブリッドな文字列戦略を採用しています。Ansible の ``module_utils`` コードは、大部分がモジュールコードのようなものですが、その一部はコントローラーでも使用されます。そのため、モジュールやコントローラの前提条件との互換性、特に文字列ストラテジーとの互換性が必要になります。module_utils コードは、その関数への入力としてネイティブ文字列を受け入れ、その出力としてネイティブ文字列を放出しようとします。" - -#: ../../rst/dev_guide/developing_python_3.rst:242 -msgid "In ``module_utils`` code:" -msgstr "``module_utils`` コードの場合:" - -#: ../../rst/dev_guide/developing_python_3.rst:244 -msgid "Functions **must** accept string parameters as either text strings or byte strings." -msgstr "関数は、文字列パラメーターをテキスト文字列かバイト文字列のいずれかで使用できるようにする **必要があります**。" - -#: ../../rst/dev_guide/developing_python_3.rst:245 -msgid "Functions may return either the same type of string as they were given or the native string type for the Python version they are run on." -msgstr "関数は、提供された文字列と同じタイプの文字列を返すか、実行している Python のバージョンに合わせたネイティブの文字列タイプを返すことができます。" - -#: ../../rst/dev_guide/developing_python_3.rst:246 -msgid "Functions that return strings **must** document whether they return strings of the same type as they were given or native strings." -msgstr "文字列を返す関数は、指定の文字列と同じ型の文字列を返すのか、ネイティブの文字列を返すのかを文書化する **必要があります**。" - -#: ../../rst/dev_guide/developing_python_3.rst:248 -msgid "Module-utils functions are therefore often very defensive in nature. They convert their string parameters into text (using ``ansible.module_utils._text.to_text``) at the beginning of the function, do their work, and then convert the return values into the native string type (using ``ansible.module_utils._text.to_native``) or back to the string type that their parameters received." -msgstr "したがって、module_utils 関数は、本質的に非常に防御的であることがよくあります。この関数は、関数の先頭で (``ansible.module_utils._text.to_text`` を使用して) 文字列パラメーターをテキストに変換します。作業を行い、(``ansible.module_utils._text.to_native`` を使用して) 戻り値をネイティブの文字列型に変換します。または、パラメーターが受け取った文字列型に戻ります。" - -#: ../../rst/dev_guide/developing_python_3.rst:255 -msgid "Tips, tricks, and idioms for Python 2/Python 3 compatibility" -msgstr "Python 2/Python 3 互換のためのヒント、トリック、イディオム" - -#: ../../rst/dev_guide/developing_python_3.rst:258 -msgid "Use forward-compatibility boilerplate" -msgstr "前方互換性のあるボイラープレートの使用" - -#: ../../rst/dev_guide/developing_python_3.rst:260 -msgid "Use the following boilerplate code at the top of all python files to make certain constructs act the same way on Python 2 and Python 3:" -msgstr "Python 2 と Python 3 で特定の構成要素が同じように動作するようにするために、すべての python ファイルの先頭に以下のボイラプレートコードを使用してください。" - -#: ../../rst/dev_guide/developing_python_3.rst:269 -msgid "``__metaclass__ = type`` makes all classes defined in the file into new-style classes without explicitly inheriting from :class:`object `." -msgstr "``__metaclass__ = type`` は、ファイルで定義されているすべてのクラスを :class:`object ` から明示的に継承することなく、新しいスタイルのクラスにします。" - -#: ../../rst/dev_guide/developing_python_3.rst:272 -msgid "The ``__future__`` imports do the following:" -msgstr "``__future__`` のインポートは以下を行います。" - -#: ../../rst/dev_guide/developing_python_3.rst -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:16 -msgid "absolute_import" -msgstr "absolute_import" - -#: ../../rst/dev_guide/developing_python_3.rst:274 -msgid "Makes imports look in :data:`sys.path ` for the modules being imported, skipping the directory in which the module doing the importing lives. If the code wants to use the directory in which the module doing the importing, there's a new dot notation to do so." -msgstr "インポートは、インポートされるモジュールの :data:`sys.path ` を検索し、インポートを行うモジュールが存在するディレクトリーをスキップします。インポートを行うモジュールが存在するディレクトリーをコードが使用したい場合は、新しいドット表記があります。" - -#: ../../rst/dev_guide/developing_python_3.rst -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:31 -msgid "division" -msgstr "division" - -#: ../../rst/dev_guide/developing_python_3.rst:278 -msgid "Makes division of integers always return a float. If you need to find the quotient use ``x // y`` instead of ``x / y``." -msgstr "整数の除算が常に浮動小数点を返すようになります。商を見つける必要がある場合は、``x / y`` の代わりに ``x // y`` を使用してください。" - -#: ../../rst/dev_guide/developing_python_3.rst -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:43 -msgid "print_function" -msgstr "print_function" - -#: ../../rst/dev_guide/developing_python_3.rst:280 -msgid "Changes :func:`print ` from a keyword into a function." -msgstr "キーワードから関数への :func:`print ` の変更" - -#: ../../rst/dev_guide/developing_python_3.rst:283 -msgid "`PEP 0328: Absolute Imports `_" -msgstr "`PEP 0328: Absolute Imports `_" - -#: ../../rst/dev_guide/developing_python_3.rst:284 -msgid "`PEP 0238: Division `_" -msgstr "`PEP 0238: Division `_" - -#: ../../rst/dev_guide/developing_python_3.rst:285 -msgid "`PEP 3105: Print function `_" -msgstr "`PEP 3105: Print function `_" - -#: ../../rst/dev_guide/developing_python_3.rst:288 -msgid "Prefix byte strings with ``b_``" -msgstr "バイト文字列のプレフィックス ``b_``" - -#: ../../rst/dev_guide/developing_python_3.rst:290 -msgid "Since mixing text and bytes types leads to tracebacks we want to be clear about what variables hold text and what variables hold bytes. We do this by prefixing any variable holding bytes with ``b_``. For instance:" -msgstr "テキスト型とバイト型が混在するとトレースバックが発生するため、どの変数がテキストを保持していて、どの変数がバイトを保持しているかを明確にします。これは、バイトと ``b_`` を保持する変数のプレフィックスを指定して実行します。以下に例を示します。" - -#: ../../rst/dev_guide/developing_python_3.rst:301 -msgid "We do not prefix the text strings instead because we only operate on byte strings at the borders, so there are fewer variables that need bytes than text." -msgstr "代わりに、ボーダーのバイト文字列でのみ動作するためテキスト文字列はプレフィックスとして付けられません。したがって、テキストの文字列の前にバイト値が必要な変数が少なくなります。" - -#: ../../rst/dev_guide/developing_python_3.rst:306 -msgid "Import Ansible's bundled Python ``six`` library" -msgstr "Ansible のバンドルされた Python ``six`` ライブラリーをインポート" - -#: ../../rst/dev_guide/developing_python_3.rst:308 -msgid "The third-party Python `six `_ library exists to help projects create code that runs on both Python 2 and Python 3. Ansible includes a version of the library in module_utils so that other modules can use it without requiring that it is installed on the remote system. To make use of it, import it like this:" -msgstr "サードパーティーの Python `six `_ ライブラリーは、プロジェクトが Python 2 および Python 3 の両方で実行するコードを作成するのに役立ちます。Ansible には、module_utils にライブラリーのバージョンが含まれ、他のモジュールがリモートシステムにインストールされなくても使用可能となるようになっています。これを使用して、以下のようにインポートしてください。" - -#: ../../rst/dev_guide/developing_python_3.rst:318 -msgid "Ansible can also use a system copy of six" -msgstr "Ansible は、six のシステムコピーを使用することもできます。" - -#: ../../rst/dev_guide/developing_python_3.rst:320 -msgid "Ansible will use a system copy of six if the system copy is a later version than the one Ansible bundles." -msgstr "Ansible は、システムコピーが、Ansible がバンドルしているものよりも後のバージョンのものであれば、6 のシステムコピーを使用します。" - -#: ../../rst/dev_guide/developing_python_3.rst:324 -msgid "Handle exceptions with ``as``" -msgstr "``as`` で例外を処理します。" - -#: ../../rst/dev_guide/developing_python_3.rst:326 -msgid "In order for code to function on Python 2.6+ and Python 3, use the new exception-catching syntax which uses the ``as`` keyword:" -msgstr "Python 2.6 以降および Python 3 でコードが機能するには、``as`` キーワードを使用する新しい例外キャッチ構文を使用してください。" - -#: ../../rst/dev_guide/developing_python_3.rst:336 -msgid "Do **not** use the following syntax as it will fail on every version of Python 3:" -msgstr "以下の構文は、Python 3 のすべてのバージョンで失敗するため、**使用しないでください**。" - -#: ../../rst/dev_guide/developing_python_3.rst:347 -msgid "Update octal numbers" -msgstr "8 進数の更新" - -#: ../../rst/dev_guide/developing_python_3.rst:349 -msgid "In Python 2.x, octal literals could be specified as ``0755``. In Python 3, octals must be specified as ``0o755``." -msgstr "Python 2.xでは、8 進数リテラルは ``0755`` と指定できました。Python 3 では、8 進数は ``0o755`` と指定しなければなりません。" - -#: ../../rst/dev_guide/developing_python_3.rst:353 -msgid "String formatting for controller code" -msgstr "コントローラーコードの文字列形式" - -#: ../../rst/dev_guide/developing_python_3.rst:356 -msgid "Use ``str.format()`` for Python 2.6 compatibility" -msgstr "Python 2.6 の互換性のために ``str.format()`` を使用します。" - -#: ../../rst/dev_guide/developing_python_3.rst:358 -msgid "Starting in Python 2.6, strings gained a method called ``format()`` to put strings together. However, one commonly used feature of ``format()`` wasn't added until Python 2.7, so you need to remember not to use it in Ansible code:" -msgstr "Python 2.6 以降、文字列には、``format()`` という名前のメソッドが追加されました。ただし、``format()`` に一般的に使用される機能の 1 つは Python 2.7 まで追加されなかったため、Ansible コードで使用しないように注意する必要があります。" - -#: ../../rst/dev_guide/developing_python_3.rst:370 -msgid "Both of the format strings above map positional arguments of the ``format()`` method into the string. However, the first version doesn't work in Python 2.6. Always remember to put numbers into the placeholders so the code is compatible with Python 2.6." -msgstr "上記の両方の形式文字列では、``format()`` メソッドの位置引数を文字列にマッピングしますが、最初のバージョンは Python 2.6 では動作しません。常に数字をプレースホルダーに配置し、コードが Python 2.6 と互換性を持つようにします。" - -#: ../../rst/dev_guide/developing_python_3.rst:376 -msgid "Python documentation on `format strings `_" -msgstr "`フォーマットの文字列 `_ に関する Python ドキュメント" - -#: ../../rst/dev_guide/developing_python_3.rst:379 -msgid "Use percent format with byte strings" -msgstr "バイト文字列でのパーセント書式の使用" - -#: ../../rst/dev_guide/developing_python_3.rst:381 -msgid "In Python 3.x, byte strings do not have a ``format()`` method. However, it does have support for the older, percent-formatting." -msgstr "Python 3.x では、バイト文字列に ``format()`` メソッドがありませんが、以前のパーセント形式をサポートします。" - -#: ../../rst/dev_guide/developing_python_3.rst:388 -msgid "Percent formatting added in Python 3.5" -msgstr "Python 3.5 に追加されたパーセント書式" - -#: ../../rst/dev_guide/developing_python_3.rst:390 -msgid "Percent formatting of byte strings was added back into Python 3 in 3.5. This isn't a problem for us because Python 3.5 is our minimum version. However, if you happen to be testing Ansible code with Python 3.4 or earlier, you will find that the byte string formatting here won't work. Upgrade to Python 3.5 to test." -msgstr "Python 3.5 に、バイト文字列のパーセント書式が追加されました。Python 3.5 は最小バージョンであるため、これは問題ではありません。ただし、Python 3.4 以前のバージョンで Ansible のコードをテストしている場合は、ここでのバイト文字列の書式設定が適切に処理されないことがあります。その場合は、Python 3.5 にアップグレードしてテストしてください。" - -#: ../../rst/dev_guide/developing_python_3.rst:397 -msgid "Python documentation on `percent formatting `_" -msgstr "`パーセンテージフォーマット `_ に関するドキュメント" - -#: ../../rst/dev_guide/developing_python_3.rst:402 -msgid "Testing modules on Python 3" -msgstr "Python 3 でのモジュールのテスト" - -#: ../../rst/dev_guide/developing_python_3.rst:404 -msgid "Ansible modules are slightly harder to code to support Python 3 than normal code from other projects. A lot of mocking has to go into unit testing an Ansible module, so it's harder to test that your changes have fixed everything or to to make sure that later commits haven't regressed the Python 3 support. Review our :ref:`testing ` pages for more information." -msgstr "Ansible モジュールは、その他のプロジェクトの通常のコードよりも Python 3 をサポートするようにコーディングするのが若干難しくなります。多くのモックは、Ansible モジュールのユニットテストに入る必要があるため、変更によってすべてが修正されたことをテストするか、後のコミットが Python 3 をサポートしないようにする方が困難になります。詳細は、:ref:`テスト ` ページを参照してください。" - -#: ../../rst/dev_guide/developing_rebasing.rst:5 -msgid "Rebasing a pull request" -msgstr "プル要求のリベース" - -#: ../../rst/dev_guide/developing_rebasing.rst:7 -msgid "You may find that your pull request (PR) is out-of-date and needs to be rebased. This can happen for several reasons:" -msgstr "プル要求 (PR) が古いため、リベースが必要になる場合があります。これにはいくつかの理由が考えられます。" - -#: ../../rst/dev_guide/developing_rebasing.rst:9 -msgid "Files modified in your PR are in conflict with changes which have already been merged." -msgstr "PR で変更されたファイルは、すでにマージされている変更と競合しています。" - -#: ../../rst/dev_guide/developing_rebasing.rst:10 -msgid "Your PR is old enough that significant changes to automated test infrastructure have occurred." -msgstr "PR は、自動化されたテストインフラストラクチャーに大きな変更が行われたのに十分なサイズです。" - -#: ../../rst/dev_guide/developing_rebasing.rst:12 -msgid "Rebasing the branch used to create your PR will resolve both of these issues." -msgstr "PR を作成するのに使用するブランチを再設定すると、この両方の問題が解決されます。" - -#: ../../rst/dev_guide/developing_rebasing.rst:15 -msgid "Configuring your remotes" -msgstr "リモートの設定" - -#: ../../rst/dev_guide/developing_rebasing.rst:17 -msgid "Before you can rebase your PR, you need to make sure you have the proper remotes configured. These instructions apply to any repository on GitHub, including collections repositories. On other platforms (bitbucket, gitlab), the same principles and commands apply but the syntax may be different. We use the ansible/ansible repository here as an example. In other repositories, the branch names may be different. Assuming you cloned your fork in the usual fashion, the ``origin`` remote will point to your fork::" -msgstr "PR をリベースする前に、適切なリモートが設定されていることを確認する必要があります。この手順は、コレクションリポジトリーを含む GitHub のすべてのリポジトリーに適用されます。他のプラットフォーム (bitbucket や gitlab) でも同様の原則とコマンドが適用されますが、構文が異なる場合があります。ここでは、ansible/ansible のリポジトリーを例に挙げています。他のリポジトリーでは、ブランチ名が異なる場合があります。通常の方法でフォークをクローンしたと仮定すると、``origin`` のリモートは操作したユーザーのフォークを指すことになります::" - -#: ../../rst/dev_guide/developing_rebasing.rst:23 -msgid "However, you also need to add a remote which points to the upstream repository::" -msgstr "ただし、アップストリームのリポジトリーを参照するリモートを追加する必要もあります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:27 -msgid "Which should leave you with the following remotes::" -msgstr "次のリモートを残す必要があります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:35 -msgid "Checking the status of your branch should show your fork is up-to-date with the ``origin`` remote::" -msgstr "ブランチのステータスを確認すると、``作成元`` のリモートのフォークが最新の状態であることを理解できます。" - -#: ../../rst/dev_guide/developing_rebasing.rst:43 -msgid "Rebasing your branch" -msgstr "ブランチのリベース" - -#: ../../rst/dev_guide/developing_rebasing.rst:45 -msgid "Once you have an ``upstream`` remote configured, you can rebase the branch for your PR::" -msgstr "``upstream`` のリモートを設定したら、PR のブランチをリベースできます。" - -#: ../../rst/dev_guide/developing_rebasing.rst:49 -msgid "This will replay the changes in your branch on top of the changes made in the upstream ``devel`` branch. If there are merge conflicts, you will be prompted to resolve those before you can continue." -msgstr "これにより、アップストリームの ``devel`` ブランチで変更したブランチに変更が再生されます。マージの競合が発生した場合は、続行する前に解決するように求められます。" - -#: ../../rst/dev_guide/developing_rebasing.rst:52 -msgid "After you rebase, the status of your branch changes::" -msgstr "リベース後に、ブランチのステータスが変更になります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:61 -msgid "Don't worry, this is normal after a rebase. You should ignore the ``git status`` instructions to use ``git pull``. We'll cover what to do next in the following section." -msgstr "リベースの後、これは通常通りとなります。``git pull`` を使用する ``git status`` 命令は無視する必要があります。次のセクションでは、次に何をするかについて説明します。" - -#: ../../rst/dev_guide/developing_rebasing.rst:64 -msgid "Updating your pull request" -msgstr "プル要求の更新" - -#: ../../rst/dev_guide/developing_rebasing.rst:66 -msgid "Now that you've rebased your branch, you need to push your changes to GitHub to update your PR." -msgstr "ブランチをリベースしたら、変更を GitHub にプッシュして、PR を更新する必要があります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:68 -msgid "Since rebasing re-writes git history, you will need to use a force push::" -msgstr "git 履歴を再書き込みするため、強制的にプッシュする必要があります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:72 -msgid "Your PR on GitHub has now been updated. This will automatically trigger testing of your changes. You should check in on the status of your PR after tests have completed to see if further changes are required." -msgstr "GitHub の PR が更新されました。これにより、変更のテストが自動的に発生します。テスト完了後に PR のステータスを確認し、さらなる変更が必要であるかどうかを確認する必要があります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:76 -msgid "Getting help rebasing" -msgstr "ヘルプの再ベース" - -#: ../../rst/dev_guide/developing_rebasing.rst:78 -msgid "For help with rebasing your PR, or other development related questions, join us on our #ansible-devel IRC chat channel on `freenode.net `_." -msgstr "PR またはその他の開発関連の質問を再設定する際には、`freenode.net `_ で IRC チャットチャンネル #ansible-devel に参加します。" - -#: ../../rst/dev_guide/developing_rebasing.rst:82 -msgid ":ref:`community_development_process`" -msgstr ":ref:`community_development_process`" - -#: ../../rst/dev_guide/developing_rebasing.rst:83 -msgid "Information on roadmaps, opening PRs, Ansibullbot, and more" -msgstr "ロードマップ、オープン PRS、Ansibullbot などに関する情報" - -#: ../../rst/dev_guide/index.rst:5 -msgid "Developer Guide" -msgstr "開発者ガイド" - -#: ../../rst/dev_guide/index.rst:9 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/dev_guide/index.rst:11 -msgid "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 `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" - -#: ../../rst/dev_guide/index.rst:13 -msgid "Welcome to the Ansible Developer Guide!" -msgstr "Ansible 開発者ガイドにようこそ!" - -#: ../../rst/dev_guide/index.rst:15 -msgid "**Who should use this guide?**" -msgstr "**本ガイドの対象者**" - -#: ../../rst/dev_guide/index.rst:17 -msgid "If you want to extend Ansible by using a custom module or plugin locally, creating a module or plugin, adding functionality to an existing module, or expanding test coverage, this guide is for you. We've included detailed information for developers on how to test and document modules, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository." -msgstr "カスタムモジュールまたはプラグインのローカルでの使用、モジュールまたはプラグインの作成、既存のモジュールへの機能の追加、テスト範囲の拡張を行って Ansible を拡張する場合が、このガイドがご利用になれます。モジュールのテストおよびドキュメント化に関する方法についての開発者向けの詳細情報、および主な Ansible リポジトリーに受け入れられるモジュールまたはプラグインを取得するための前提条件が記載されています。" - -#: ../../rst/dev_guide/index.rst:19 -msgid "Find the task that best describes what you want to do:" -msgstr "以下の中から、お客様のニーズに最も適したタスクを選んでください。" - -#: ../../rst/dev_guide/index.rst:21 -msgid "I'm looking for a way to address a use case:" -msgstr "ユースケースに対応する方法を探している。" - -#: ../../rst/dev_guide/index.rst:23 -msgid "I want to :ref:`add a custom plugin or module locally `." -msgstr ":ref:`カスタムプラグインまたはモジュールをローカルに追加 ` したいです。" - -#: ../../rst/dev_guide/index.rst:24 -msgid "I want to figure out if :ref:`developing a module is the right approach ` for my use case." -msgstr "選択したユースケースでは、:ref:`モジュールの開発が適切なアプローチである ` かどうかを確認したいです。" - -#: ../../rst/dev_guide/index.rst:25 -msgid "I want to :ref:`develop a collection `." -msgstr ":ref:`コレクションを開発 ` したいです。" - -#: ../../rst/dev_guide/index.rst:26 -msgid "I want to :ref:`contribute to an Ansible-maintained collection `." -msgstr ":ref:`Ansible が管理するコレクションに貢献 ` したいです。" - -#: ../../rst/dev_guide/index.rst:27 -msgid "I want to :ref:`contribute to a community-maintained collection `." -msgstr ":ref:`コミュニティーが管理するコレクションに貢献 ` したいです。" - -#: ../../rst/dev_guide/index.rst:28 -msgid "I want to :ref:`migrate a role to a collection `." -msgstr ":ref:`ロールをコレクションに移行 ` したいです。" - -#: ../../rst/dev_guide/index.rst:30 -msgid "I've read the info above, and I'm sure I want to develop a module:" -msgstr "上記の情報を読んで、モジュールを開発したい。" - -#: ../../rst/dev_guide/index.rst:32 -msgid "What do I need to know before I start coding?" -msgstr "コーディングを始める前に何を知っておくべきか。" - -#: ../../rst/dev_guide/index.rst:33 -msgid "I want to :ref:`set up my Python development environment `." -msgstr ":ref:`Python 開発環境をセットアップ ` したいです。" - -#: ../../rst/dev_guide/index.rst:34 -msgid "I want to :ref:`get started writing a module `." -msgstr ":ref:`モジュールの記述を開始 ` したいです。" - -#: ../../rst/dev_guide/index.rst:40 -msgid "I want to write a specific kind of module:" -msgstr "特定のモジュールを作成したい。" - -#: ../../rst/dev_guide/index.rst:36 -msgid "a :ref:`network module `" -msgstr ":ref:`ネットワークモジュール `" - -#: ../../rst/dev_guide/index.rst:37 -msgid "a :ref:`Windows module `." -msgstr ":ref:`Windows モジュール `" - -#: ../../rst/dev_guide/index.rst:38 -msgid "an :ref:`Amazon module `." -msgstr ":ref:`Amazon モジュール `" - -#: ../../rst/dev_guide/index.rst:39 -msgid "an :ref:`OpenStack module `." -msgstr ":ref:`OpenStack モジュール `" - -#: ../../rst/dev_guide/index.rst:40 -msgid "an :ref:`oVirt/RHV module `." -msgstr ":ref:`oVirt/RHV モジュール `" - -#: ../../rst/dev_guide/index.rst:41 -msgid "a :ref:`VMware module `." -msgstr ":ref:`VMware モジュール `" - -#: ../../rst/dev_guide/index.rst:42 -msgid "I want to :ref:`write a series of related modules ` that integrate Ansible with a new product (for example, a database, cloud provider, network platform, and so on)." -msgstr "Ansible を新規製品 (例: データベース、クラウドプロバイダー、ネットワークプラットフォーム) と統合する :ref:`一連の関連モジュールを記述 ` したいです。" - -#: ../../rst/dev_guide/index.rst:44 -msgid "I want to refine my code:" -msgstr "コードを改良したい。" - -#: ../../rst/dev_guide/index.rst:46 -msgid "I want to :ref:`debug my module code `." -msgstr ":ref:`モジュールコードをデバッグ ` したいです。" - -#: ../../rst/dev_guide/index.rst:47 -msgid "I want to :ref:`add tests `." -msgstr ":ref:`テストを追加 ` したいです。" - -#: ../../rst/dev_guide/index.rst:48 -msgid "I want to :ref:`document my module `." -msgstr ":ref:`モジュールをドキュメント化 ` したいです。" - -#: ../../rst/dev_guide/index.rst:49 -msgid "I want to :ref:`document my set of modules for a network platform `." -msgstr ":ref:`ネットワークプラットフォームのモジュールセットを文書化 ` したいです。" - -#: ../../rst/dev_guide/index.rst:50 -msgid "I want to follow :ref:`conventions and tips for clean, usable module code `." -msgstr ":ref:`クリーンで使いやすいモジュールコードのための規則とヒント ` を適用したいです。" - -#: ../../rst/dev_guide/index.rst:51 -msgid "I want to :ref:`make sure my code runs on Python 2 and Python 3 `." -msgstr ":ref:`作成したコードが Python 2 および Python 3 で実行する ` ようにしたいです。" - -#: ../../rst/dev_guide/index.rst:53 -msgid "I want to work on other development projects:" -msgstr "他の開発プロジェクトで作業したい。" - -#: ../../rst/dev_guide/index.rst:55 -msgid "I want to :ref:`write a plugin `." -msgstr ":ref:`プラグインを記述 ` したいです。" - -#: ../../rst/dev_guide/index.rst:56 -msgid "I want to :ref:`connect Ansible to a new source of inventory `." -msgstr ":ref:`Ansible を新しいインベントリーソースに接続 ` したいです。" - -#: ../../rst/dev_guide/index.rst:57 -msgid "I want to :ref:`deprecate an outdated module `." -msgstr ":ref:`古いモジュールを非推奨 ` にしたいです。" - -#: ../../rst/dev_guide/index.rst:59 -msgid "I want to contribute back to the Ansible project:" -msgstr "Ansible プロジェクトに貢献したい。" - -#: ../../rst/dev_guide/index.rst:61 -msgid "I want to :ref:`understand how to contribute to Ansible `." -msgstr ":ref:`Ansible への貢献方法を理解 ` したいです。" - -#: ../../rst/dev_guide/index.rst:62 -msgid "I want to :ref:`contribute my module or plugin `." -msgstr ":ref:`モジュールまたはプラグインに貢献 ` したいです。" - -#: ../../rst/dev_guide/index.rst:63 -msgid "I want to :ref:`understand the license agreement ` for contributions to Ansible." -msgstr "Ansible に参加するための :ref:`使用許諾契約を理解 ` したいです。" - -#: ../../rst/dev_guide/index.rst:65 -msgid "If you prefer to read the entire guide, here's a list of the pages in order." -msgstr "本ガイドをすべて読む場合は、以下に示す順番でページを表示してください。" - -#: ../../rst/dev_guide/migrating_roles.rst:6 -msgid "Migrating Roles to Roles in Collections on Galaxy" -msgstr "Galaxy のコレクション内のロールへの移行" - -#: ../../rst/dev_guide/migrating_roles.rst:8 -msgid "You can migrate any existing standalone role into a collection and host the collection on Galaxy. With Ansible collections, you can distribute many roles in a single cohesive unit of re-usable automation. Inside a collection, you can share custom plugins across all roles in the collection instead of duplicating them in each role's :file:`library/`` directory." -msgstr "既存のスタンドアロンロールをコレクションに移行し、コレクションを Galaxy 上でホストすることができます。Ansible コレクションを使用すると、再利用可能なオートメーションの 1 つのまとまったユニットで多くのロールを配布できます。コレクションの中では、カスタムプラグインを各ロールの :file:`library/`` ディレクトリーに複製するのではなく、コレクション内のすべてのロールで共有することができます。" - -#: ../../rst/dev_guide/migrating_roles.rst:10 -msgid "You must migrate roles to collections if you want to distribute them as certified Ansible content." -msgstr "ロールを認定済みの Ansible コンテンツとして配布する場合は、ロールをコレクションに移行する必要があります。" - -#: ../../rst/dev_guide/migrating_roles.rst:14 -msgid "If you want to import your collection to Galaxy, you need a `Galaxy namespace `_." -msgstr "コレクションを Galaxy にインポートする場合は、`Galaxy 名前空間 `_ が必要です。" - -#: ../../rst/dev_guide/migrating_roles.rst:16 -msgid "See :ref:`developing_collections` for details on collections." -msgstr "コレクションの詳細は、「:ref:`developing_collections`」を参照してください。" - -#: ../../rst/dev_guide/migrating_roles.rst:24 -msgid "Comparing standalone roles to collection roles" -msgstr "スタンドアロンロールとコレクションロールの比較" - -#: ../../rst/dev_guide/migrating_roles.rst:26 -msgid ":ref:`Standalone roles ` have the following directory structure:" -msgstr ":ref:`Standalone roles ` に、以下のディレクトリー構造があります。" - -#: ../../rst/dev_guide/migrating_roles.rst:45 -msgid "The highlighted directories above will change when you migrate to a collection-based role. The collection directory structure includes a :file:`roles/` directory:" -msgstr "上記の強調表示されたディレクトリーは、コレクションベースのロールへの移行時に変化します。コレクションディレクトリー構造には、:file:`roles/` ディレクトリーが含まれます。" - -#: ../../rst/dev_guide/migrating_roles.rst:70 -msgid "You will need to use the Fully Qualified Collection Name (FQCN) to use the roles and plugins when you migrate your role into a collection. The FQCN is the combination of the collection ``namespace``, collection ``name``, and the content item you are referring to." -msgstr "FQCN は、ロールをコレクションに移行するときに完全修飾コレクション名 (FQCN) を使用してロールおよびプラグインを使用する必要があります。FQCN は、コレクション ``namespace``、コレクション ``name``、および参照するコンテンツアイテムの組み合わせになります。" - -#: ../../rst/dev_guide/migrating_roles.rst:72 -msgid "So for example, in the above collection, the FQCN to access ``role1`` would be:" -msgstr "たとえば、上記のコレクションでは、``role1`` にアクセスする FQCN は以下のようになります。" - -#: ../../rst/dev_guide/migrating_roles.rst:79 -msgid "A collection can contain one or more roles in the :file:`roles/` directory and these are almost identical to standalone roles, except you need to move plugins out of the individual roles, and use the :abbr:`FQCN (Fully Qualified Collection Name)` in some places, as detailed in the next section." -msgstr "コレクションには、:file:`roles/` ディレクトリーに 1 つまたは複数のロールを含めることができ、これらのロールはスタンドアロンロールとほぼ同じです。ただし、個別のロールからプラグインを外に移動し、一部では :abbr:`FQCN (Fully Qualified Collection Name)` を使用します。これは、次のセクションで詳細に説明します。" - -#: ../../rst/dev_guide/migrating_roles.rst:83 -msgid "In standalone roles, some of the plugin directories referenced their plugin types in the plural sense; this is not the case in collections." -msgstr "スタンドアロンロールでは、プラグインディレクトリの一部が複数の意味でプラグインタイプを参照していました。これはコレクションには当てはまりません。" - -#: ../../rst/dev_guide/migrating_roles.rst:88 -msgid "Migrating a role to a collection" -msgstr "ロールのコレクションへの移行" - -#: ../../rst/dev_guide/migrating_roles.rst:90 -msgid "To migrate from a standalone role that contains no plugins to a collection role:" -msgstr "プラグインが含まれないスタンドアロンロールから collection ロールに移行するには、以下を行います。" - -#: ../../rst/dev_guide/migrating_roles.rst:92 -msgid "Create a local :file:`ansible_collections` directory and ``cd`` to this new directory." -msgstr "ローカルの :file:`ansible_collections` ディレクトリーを作成し、この新しいディレクトリーに ``cd`` を作成します。" - -#: ../../rst/dev_guide/migrating_roles.rst:94 -#: ../../rst/dev_guide/migrating_roles.rst:123 -msgid "Create a collection. If you want to import this collection to Ansible Galaxy, you need a `Galaxy namespace `_." -msgstr "コレクションを作成します。このコレクションを Ansible Galaxy にインポートする場合は、`Galaxy 名前空間 `_ が必要です。" - -#: ../../rst/dev_guide/migrating_roles.rst:100 -#: ../../rst/dev_guide/migrating_roles.rst:129 -msgid "This creates the collection directory structure." -msgstr "これにより、コレクションディレクトリー構造が作成されます。" - -#: ../../rst/dev_guide/migrating_roles.rst:102 -#: ../../rst/dev_guide/migrating_roles.rst:131 -msgid "Copy the standalone role directory into the :file:`roles/` subdirectory of the collection. Roles in collections cannot have hyphens in the role name. Rename any such roles to use underscores instead." -msgstr "スタンドアロンのロールディレクトリーをコレクションの :file:`roles/` サブディレクトリーにコピーします。コレクション内のロールにはロール名にハイフンを設定できません。このようなロールは、代わりにアンダースコアを使用するようにします。" - -#: ../../rst/dev_guide/migrating_roles.rst:109 -#: ../../rst/dev_guide/migrating_roles.rst:147 -msgid "Update ``galaxy.yml`` to include any role dependencies." -msgstr "``galaxy.yml`` を更新して、ロールの依存関係を追加します。" - -#: ../../rst/dev_guide/migrating_roles.rst:111 -#: ../../rst/dev_guide/migrating_roles.rst:149 -msgid "Update the collection README.md file to add links to any role README.md files." -msgstr "コレクション README.md ファイルを更新して、ロールの README.md ファイルへのリンクを追加します。" - -#: ../../rst/dev_guide/migrating_roles.rst:117 -msgid "Migrating a role with plugins to a collection" -msgstr "プラグインを持つロールをコレクションに移行する" - -#: ../../rst/dev_guide/migrating_roles.rst:119 -msgid "To migrate from a standalone role that has plugins to a collection role:" -msgstr "プラグインが含まれないスタンドアロンロールから collection ロールに移行するには、以下を行います。" - -#: ../../rst/dev_guide/migrating_roles.rst:121 -msgid "Create a local :file:`ansible_collections directory` and ``cd`` to this new directory." -msgstr "ローカルの :file:`ansible_collections directory` および ``cd`` をこの新しいディレクトリーに作成します。" - -#: ../../rst/dev_guide/migrating_roles.rst:139 -msgid "Move any modules to the :file:`plugins/modules/` directory." -msgstr "モジュールを :file:`plugins/modules/` ディレクトリーに移動します。" - -#: ../../rst/dev_guide/migrating_roles.rst:145 -msgid "Move any other plugins to the appropriate :file:`plugins/PLUGINTYPE/` directory. See :ref:`migrating_plugins_collection` for additional steps that may be required." -msgstr "その他のプラグインを適切な :file:`plugins/PLUGINTYPE/` ディレクトリーに移動します。必要とされる追加手順については、「:ref:`migrating_plugins_collection`」を参照してください。" - -#: ../../rst/dev_guide/migrating_roles.rst:151 -msgid "Change any references to the role to use the :abbr:`FQCN (Fully Qualified Collection Name)`." -msgstr ":abbr:`FQCN (Fully Qualified Collection Name)` を使用するように、ロールへの参照を変更します。" - -#: ../../rst/dev_guide/migrating_roles.rst:164 -msgid "You can alternately use the ``collections`` keyword to simplify this:" -msgstr "別の方法では、``collections`` キーワードを使用してこれを単純化することもできます。" - -#: ../../rst/dev_guide/migrating_roles.rst:182 -msgid "Migrating other role plugins to a collection" -msgstr "他のロールプラグインからコレクションへの移行" - -#: ../../rst/dev_guide/migrating_roles.rst:184 -msgid "To migrate other role plugins to a collection:" -msgstr "その他のロールプラグインをコレクションに移行するには、以下を実行します。" - -#: ../../rst/dev_guide/migrating_roles.rst:187 -msgid "Move each nonmodule plugins to the appropriate :file:`plugins/PLUGINTYPE/` directory. The :file:`mynamespace/mycollection/plugins/README.md` file explains the types of plugins that the collection can contain within optionally created subdirectories." -msgstr "モジュール以外の各プラグインを適切な :file:`plugins/PLUGINTYPE/` ディレクトリーに移動します。:file:`mynamespace/mycollection/plugins/README.md` ファイルは、任意で作成されたサブディレクトリー内にコレクションが含めることができるプラグインのタイプを説明します。" - -#: ../../rst/dev_guide/migrating_roles.rst:193 -msgid "Update documentation to use the FQCN. Plugins that use ``doc_fragments`` need to use FQCN (for example, ``mydocfrag`` becomes ``mynamespace.mycollection.mydocfrag``)." -msgstr "FQCN を使用するようにドキュメントを更新します。``doc_fragments`` を使用するプラグインは、FQCN を使用する必要があります (たとえば、``mydocfrag`` は ``mynamespace.mycollection.mydocfrag`` になります)。" - -#: ../../rst/dev_guide/migrating_roles.rst:195 -msgid "Update relative imports work in collections to start with a period. For example, :file:`./filename` and :file:`../asdfu/filestuff` works but :file:`filename` in same directory must be updated to :file:`./filename`." -msgstr "コレクション内の相対インポート作業を更新し、ピリオドで開始します。たとえば、:file:`./filename` および :file:`../asdfu/filestuff` は有効ですが、同じディレクトリー内の :file:`./filename` を :file:`./filename` に更新する必要があります。" - -#: ../../rst/dev_guide/migrating_roles.rst:198 -msgid "If you have a custom ``module_utils`` or import from ``__init__.py``, you must also:" -msgstr "カスタムの ``module_utils`` がある、または ``__init__.py`` からインポートする場合には、以下も必要になります。" - -#: ../../rst/dev_guide/migrating_roles.rst:200 -msgid "Change the Python namespace for custom ``module_utils`` to use the :abbr:`FQCN (Fully Qualified Collection Name)` along with the ``ansible_collections`` convention. See :ref:`update_module_utils_role`." -msgstr "カスタム ``module_utils`` の Python 名前空間が、``ansible_collections`` 規則と共に :abbr:`FQCN (Fully Qualified Collection Name)` を使用するように変更します。:ref:`update_module_utils_role` を参照してください。" - -#: ../../rst/dev_guide/migrating_roles.rst:202 -msgid "Change how you import from ``__init__.py``. See :ref:`update_init_role`." -msgstr "``__init__.py`` からインポートする方法を変更します。「:ref:`update_init_role`」を参照してください。" - -#: ../../rst/dev_guide/migrating_roles.rst:208 -msgid "Updating ``module_utils``" -msgstr " ``module_utils`` の更新" - -#: ../../rst/dev_guide/migrating_roles.rst:210 -msgid "If any of your custom modules use a custom module utility, once you migrate to a collection you cannot address the module utility in the top level ``ansible.module_utils`` Python namespace. Ansible does not merge content from collections into the Ansible internal Python namespace. Update any Python import statements that refer to custom module utilities when you migrate your custom content to collections. See :ref:`module_utils in collections ` for more details." -msgstr "カスタムモジュールのいずれかがカスタムモジュールユーティリティーを使用している場合は、コレクションに移行すると、トップレベルの ``ansible.module_utils`` Python 名前空間でモジュールユーティリティーを扱うことができません。Ansible は、コレクションのコンテンツを Ansible 内部の Python 名前空間にマージしません。カスタムコンテンツをコレクションに移行する際は、カスタムモジュールユーティリティーを参照している Python の import 文を更新してください。詳細は、「:ref:`コレクションの module_utils `」を参照してください。" - -#: ../../rst/dev_guide/migrating_roles.rst:212 -msgid "When coding with ``module_utils`` in a collection, the Python import statement needs to take into account the :abbr:`FQCN (Fully Qualified Collection Name)` along with the ``ansible_collections`` convention. The resulting Python import looks similar to the following example:" -msgstr "コレクションで ``module_utils`` を使用してコーディングする場合、Python の import ステートメントは ``ansible_collections`` 規則とともに :abbr:`FQCN (Fully Qualified Collection Name)` を考慮する必要があります。作成される Python インポートは以下のようになります。" - -#: ../../rst/dev_guide/migrating_roles.rst:220 -msgid "You need to follow the same rules in changing paths and using namespaced names for subclassed plugins." -msgstr "パスの変更と同じルールに従い、サブクラスのプラグインに名前空間を使用した名前を使用する必要があります。" - -#: ../../rst/dev_guide/migrating_roles.rst:222 -msgid "The following example code snippets show a Python and a PowerShell module using both default Ansible ``module_utils`` and those provided by a collection. In this example the namespace is ``ansible_example`` and the collection is ``community``." -msgstr "以下のスニペットの例は、デフォルトの Ansible ``module_utils`` と、コレクションの両方を使用する Python および PowerShell モジュールを示しています。この例では、名前空間は ``ansible_example`` で、コレクションは ``community`` です。" - -#: ../../rst/dev_guide/migrating_roles.rst:224 -msgid "In the Python example the ``module_utils`` is ``helper`` and the :abbr:`FQCN (Fully Qualified Collection Name)` is ``ansible_example.community.plugins.module_utils.helper``:" -msgstr "Python の例では、``module_utils`` が ``helper`` で、:abbr:`FQCN (Fully Qualified Collection Name)` は ``ansible_example.community.plugins.module_utils.helper`` です。" - -#: ../../rst/dev_guide/migrating_roles.rst:250 -msgid "In the PowerShell example the ``module_utils`` is ``hyperv`` and the :abbr:`FQCN (Fully Qualified Collection Name)` is ``ansible_example.community.plugins.module_utils.hyperv``:" -msgstr "PowerShell の例では、``module_utils`` が ``hyperv`` で、:abbr:`FQCN (Fully Qualified Collection Name)` は ``ansible_example.community.plugins.module_utils.hyperv`` です。" - -#: ../../rst/dev_guide/migrating_roles.rst:272 -msgid "Importing from __init__.py" -msgstr "__init__.py からのインポート" - -#: ../../rst/dev_guide/migrating_roles.rst:274 -msgid "Because of the way that the CPython interpreter does imports, combined with the way the Ansible plugin loader works, if your custom embedded module or plugin requires importing something from an :file:`__init__.py` file, that also becomes part of your collection. You can either originate the content inside a standalone role or use the file name in the Python import statement. The following example is an :file:`__init__.py` file that is part of a callback plugin found inside a collection named ``ansible_example.community``." -msgstr "CPython インタープリターがインポートを行う方法と、Ansible プラグインローダーが動作する方法を組み合わせることで、カスタムの組み込みモジュールやプラグインが :file:`__init__.py` ファイルから何かをインポートする必要がある場合、それもコレクションの一部になります。コンテンツをスタンドアロンのロールの内部で生成するか、Python の import 文でファイル名を使用することができます。次の例は、``ansible_example.community`` という名前のコレクションの中にあるコールバックプラグインの一部である :file:`__init__.py` というファイルです。" - -#: ../../rst/dev_guide/migrating_roles.rst:282 -msgid "Example: Migrating a standalone role with plugins to a collection" -msgstr "例: プラグインを持つスタンドアロンロールをコレクションに移行" - -#: ../../rst/dev_guide/migrating_roles.rst:284 -msgid "In this example we have a standalone role called ``my-standalone-role.webapp`` to emulate a standalone role that contains dashes in the name (which is not valid in collections). This standalone role contains a custom module in the ``library/`` directory called ``manage_webserver``." -msgstr "この例では、``my-standalone-role.webapp`` という名前のスタンドアロンのロールがあり、名前にダッシュが含まれるスタンドアロンのロールをエミュレートします (コレクションで有効なものではありません)。このスタンドアロンロールには、``manage_webserver`` と呼ばれる ``library/`` ディレクトリーのカスタムモジュールが含まれます。" - -#: ../../rst/dev_guide/migrating_roles.rst:299 -msgid "Create a new collection, for example, ``acme.webserver``:" -msgstr "新規コレクションを作成します (``acme.webserver`` など)。" - -#: ../../rst/dev_guide/migrating_roles.rst:312 -msgid "Create the ``webapp`` role inside the collection and copy all contents from the standalone role:" -msgstr "コレクション内に ``webapp`` ロールを作成し、standalone ロールからすべてのコンテンツをコピーします。" - -#: ../../rst/dev_guide/migrating_roles.rst:319 -msgid "Move the ``manage_webserver`` module to its new home in ``acme/webserver/plugins/modules/``:" -msgstr "``manage_webserver`` モジュールを ``acme/webserver/plugins/modules/`` 内の新しいホームに移動します。" - -#: ../../rst/dev_guide/migrating_roles.rst:327 -msgid "This example changed the original source file ``manage_webserver.py`` to the destination file ``manage.py``. This is optional but the :abbr:`FQCN (Fully Qualified Collection Name)` provides the ``webserver`` context as ``acme.webserver.manage``." -msgstr "この例では、元のソースファイル ``manage_webserver.py`` を宛先ファイル ``manage.py`` に変更しました。これは任意ですが、:abbr:`FQCN (Fully Qualified Collection Name)` は、``acme.webserver.manage`` として ``webserver`` のコンテキストを提供します。" - -#: ../../rst/dev_guide/migrating_roles.rst:329 -msgid "Change ``manage_webserver`` to ``acme.webserver.manage`` in :file:`tasks/` files in the role ( for example, ``my-standalone-role.webapp/tasks/main.yml``) and any use of the original module name." -msgstr "ロール内の :file:`tasks/` ファイルで ``manage_webserver`` を ``acme.webserver.manage`` に変更 (``my-standalone-role.webapp/tasks/main.yml`` など) し、元のモジュール名のいずれかを使用します。" - -#: ../../rst/dev_guide/migrating_roles.rst:333 -msgid "This name change is only required if you changed the original module name, but illustrates content referenced by :abbr:`FQCN (Fully Qualified Collection Name)` can offer context and in turn can make module and plugin names shorter. If you anticipate using these modules independent of the role, keep the original naming conventions. Users can add the :ref:`collections keyword ` in their playbooks. Typically roles are an abstraction layer and users won't use components of the role independently." -msgstr "この名前の変更は、元のモジュール名を変更した場合にのみ必要ですが、:abbr:`FQCN (Fully Qualified Collection Name)` で参照されるコンテンツを例示することで、コンテキストを提供し、ひいてはモジュールやプラグインの名前を短くすることができます。これらのモジュールをロールとは関係なく使用することを想定している場合は、元の命名規則を維持してください。ユーザーは、Playbook に :ref:`コレクションのキーワード ` を追加することができます。通常、ロールは抽象化されたレイヤーであり、ユーザーはロールのコンポーネントを独立して使用することはありません。" - -#: ../../rst/dev_guide/migrating_roles.rst:337 -msgid "Example: Supporting standalone roles and migrated collection roles in a downstream RPM" -msgstr "例: ダウンストリーム RPM でのスタンドアロンロールと移行されたコレクションロールのサポート" - -#: ../../rst/dev_guide/migrating_roles.rst:339 -msgid "A standalone role can co-exist with its collection role counterpart (for example, as part of a support lifecycle of a product). This should only be done for a transition period, but these two can exist in downstream in packages such as RPMs. For example, the RHEL system roles could coexist with an `example of a RHEL system roles collection `_ and provide existing backwards compatibility with the downstream RPM." -msgstr "スタンドアロンのロールは、対応するコレクションロールと共存することができます (例: 製品のサポートライフサイクルの一部として)。これは移行期間のみ行うべきですが、これら 2 つは RPM などのパッケージでダウンストリームに存在することができます。たとえば、RHEL のシステムロールは `example of a RHEL system roles collection `_ と共存し、ダウンストリーム RPM との既存の後方互換性を提供することができます。" - -#: ../../rst/dev_guide/migrating_roles.rst:341 -msgid "This section walks through an example creating this coexistence in a downstream RPM and requires Ansible 2.9.0 or later." -msgstr "本セクションでは、ダウンストリーム RPM でこの共存を作成し、Ansible 2.9.0 以降が必要になります。" - -#: ../../rst/dev_guide/migrating_roles.rst:343 -msgid "To deliver a role as both a standalone role and a collection role:" -msgstr "スタンドアロンロールとコレクションロールの両方としてロールを提供するには、以下を実行します。" - -#: ../../rst/dev_guide/migrating_roles.rst:345 -msgid "Place the collection in :file:`/usr/share/ansible/collections/ansible_collections/`." -msgstr "コレクションを :file:`/usr/share/ansible/collections/ansible_collections/` に置きます。" - -#: ../../rst/dev_guide/migrating_roles.rst:346 -msgid "Copy the contents of the role inside the collection into a directory named after the standalone role and place the standalone role in :file:`/usr/share/ansible/roles/`." -msgstr "コレクション内のロールの内容をスタンドアロンロールにちなんで名付けられたディレクトリーにコピーし、スタンドアロンロールを :file:`/usr/share/ansible/roles/` に置きます。" - -#: ../../rst/dev_guide/migrating_roles.rst:348 -msgid "All previously bundled modules and plugins used in the standalone role are now referenced by :abbr:`FQCN (Fully Qualified Collection Name)` so even though they are no longer embedded, they can be found from the collection contents.This is an example of how the content inside the collection is a unique entity and does not have to be bound to a role or otherwise. You could alternately create two separate collections: one for the modules and plugins and another for the standalone role to migrate to. The role must use the modules and plugins as :abbr:`FQCN (Fully Qualified Collection Name)`." -msgstr "スタンドアロンロールで使用されていた、以前にバンドルされていたモジュールやプラグインは、すべて :abbr:`FQCN (Fully Qualified Collection Name)` で参照されるようになりました。そのため、それらはもはや埋め込まれていないにもかかわらず、コレクションのコンテンツから見つけることができます。これは、コレクション内のコンテンツが固有のエンティティーであり、ロールなどに縛られる必要がないことを示す例です。別の方法として、2 つの独立したコレクションを作成することもできます。1 つはモジュールとプラグイン用、もう 1 つは移行先のスタンドアロンロール用です。ロールは、モジュールとプラグインを :abbr:`FQCN (Fully Qualified Collection Name)` として使用する必要があります。" - -#: ../../rst/dev_guide/migrating_roles.rst:350 -msgid "The following is an example RPM spec file that accomplishes this using this example content:" -msgstr "以下は、このサンプルの内容を使用してこれを実現する RPM 仕様ファイルの例です。" - -#: ../../rst/dev_guide/module_lifecycle.rst:5 -msgid "The lifecycle of an Ansible module" -msgstr "Ansible モジュールのライフサイクル" - -#: ../../rst/dev_guide/module_lifecycle.rst:7 -msgid "Modules in the main Ansible repo have a defined life cycle, from first introduction to final removal. The module life cycle is tied to the `Ansible release cycle `. A module may move through these four states:" -msgstr "メインの Ansible リポジトリーのモジュールには、最初の導入から最後の削除までライフサイクルが定義されます。モジュールのライフサイクルは、`Ansible リリースサイクル ` に紐づけられ、モジュールは、次の 4 つの状態を通過する可能性があります。" - -#: ../../rst/dev_guide/module_lifecycle.rst:10 -msgid "When a module is first accepted into Ansible, we consider it in tech preview and will mark it as such in the documentation." -msgstr "モジュールが最初に Ansible に受け入れられると、テクノロジープレビューでそれが考慮され、そのようにマークされます。" - -#: ../../rst/dev_guide/module_lifecycle.rst:12 -msgid "If a module matures, we will remove the 'preview' mark in the documentation. We support (though we cannot guarantee) backwards compatibility for these modules, which means their parameters should be maintained with stable meanings." -msgstr "モジュールが成熟すると、ドキュメントの「プレビュー」マークが削除されます。これらのモジュールに対する後方互換性はサポートします (が保証はしません)。つまり、パラメーターは安定した方法で維持する必要があります。" - -#: ../../rst/dev_guide/module_lifecycle.rst:14 -msgid "If a module's target API changes radically, or if someone creates a better implementation of its functionality, we may mark it deprecated. Modules that are deprecated are still available but they are reaching the end of their life cycle. We retain deprecated modules for 4 release cycles with deprecation warnings to help users update playbooks and roles that use them." -msgstr "モジュールのターゲット API が大幅に変更された場合、または誰かがその機能に対してより良い実装を作成した場合は、非推奨と表示することがあります。非推奨のモジュールは引き続き利用できますが、ライフサイクルの終わりに近づいています。非推奨のモジュールは 4 つのリリースサイクルの間保持され、ユーザーはそれを使用する Playbook とロールを更新できるように非推奨の警告が表示されます。" - -#: ../../rst/dev_guide/module_lifecycle.rst:16 -msgid "When a module has been deprecated for four release cycles, we remove the code and mark the stub file removed. Modules that are removed are no longer shipped with Ansible. The stub file helps users find alternative modules." -msgstr "4 つのリリースサイクルでモジュールが非推奨になったら、コードを削除し、stab ファイルに removed と表示します。削除されたモジュールは、Ansible に同梱されなくなります。stab ファイルは、ユーザーが代替モジュールを見つけるのに役立ちます。" - -#: ../../rst/dev_guide/module_lifecycle.rst:21 -msgid "Deprecating modules" -msgstr "モジュールの非推奨化" - -#: ../../rst/dev_guide/module_lifecycle.rst:23 -msgid "To deprecate a module, you must:" -msgstr "モジュールの使用を終了するには、以下を行う必要があります。" - -#: ../../rst/dev_guide/module_lifecycle.rst:25 -msgid "Rename the file so it starts with an ``_``, for example, rename ``old_cloud.py`` to ``_old_cloud.py``. This keeps the module available and marks it as deprecated on the module index pages." -msgstr "ファイルの名前を ``_`` で始まるように変更します。たとえば、``old_cloud.py`` の名前を ``_old_cloud.py`` に変更します。これにより、モジュールが利用可能のままとなり、モジュールインデックスページで非推奨としてマークされます。" - -#: ../../rst/dev_guide/module_lifecycle.rst:26 -msgid "Mention the deprecation in the relevant ``CHANGELOG``." -msgstr "関連する ``CHANGELOG`` の非推奨に言及してください。" - -#: ../../rst/dev_guide/module_lifecycle.rst:27 -msgid "Reference the deprecation in the relevant ``porting_guide_x.y.rst``." -msgstr "関連する ``porting_guide_x.y.rst`` で非推奨化を参照します。" - -#: ../../rst/dev_guide/module_lifecycle.rst:28 -msgid "Add ``deprecated:`` to the documentation with the following sub-values:" -msgstr "次のサブ値を使用して、``deprecated:`` をドキュメントに追加します。" - -#: ../../rst/dev_guide/module_lifecycle.rst -msgid "removed_in" -msgstr "removed_in" - -#: ../../rst/dev_guide/module_lifecycle.rst:30 -msgid "A ``string``, such as ``\"2.10\"``; the version of Ansible where the module will be replaced with a docs-only module stub. Usually current release +4. Mutually exclusive with :removed_by_date:." -msgstr "``\"2.10\"`` などの ``string`` (モジュールがドキュメントのみのモジュールスタブに置き換えられる Ansible のバージョン)。通常、現在のリリース +4 になります。:removed_by_date: と相互に排他的です。" - -#: ../../rst/dev_guide/module_lifecycle.rst -msgid "remove_by_date" -msgstr "remove_by_date" - -#: ../../rst/dev_guide/module_lifecycle.rst:31 -msgid "(Added in Ansible 2.10). An ISO 8601 formatted date when the module will be removed. Usually 2 years from the date the module is deprecated. Mutually exclusive with :removed_in:." -msgstr "(Ansible 2.10 に追加されます)。モジュールの削除時に ISO 8601 形式の日付。通常は、モジュールが非推奨になってから 2 年間となります。このモジュールでは、:removed_in: と相互排他的になります。" - -#: ../../rst/dev_guide/module_lifecycle.rst -msgid "why" -msgstr "理由" - -#: ../../rst/dev_guide/module_lifecycle.rst:32 -msgid "Optional string that used to detail why this has been removed." -msgstr "これが削除された理由の詳細に使用される任意の文字列です。" - -#: ../../rst/dev_guide/module_lifecycle.rst -msgid "alternative" -msgstr "代替方法" - -#: ../../rst/dev_guide/module_lifecycle.rst:33 -msgid "Inform users they should do instead, for example, ``Use M(whatmoduletouseinstead) instead.``." -msgstr "ユーザーが代わりにすべきことを通知します (例: ``Use M(whatmoduletouseinstead) instead.``)。" - -#: ../../rst/dev_guide/module_lifecycle.rst:35 -msgid "note: with the advent of collections and ``routing.yml`` we might soon require another entry in this file to mark the deprecation." -msgstr "注記: コレクションおよび ``routing.yml`` では、非推奨となったマークにこのファイル内の別のエントリーがすぐに必要になることがあります。" - -#: ../../rst/dev_guide/module_lifecycle.rst:37 -msgid "For an example of documenting deprecation, see this `PR that deprecates multiple modules `_. Some of the elements in the PR might now be out of date." -msgstr "ドキュメントの非推奨の例は、「`複数のモジュールを非推奨にする PR `_」を参照してください。PR の一部の要素が最新でない可能性があります。" - -#: ../../rst/dev_guide/module_lifecycle.rst:41 -msgid "Changing a module name" -msgstr "モジュール名の変更" - -#: ../../rst/dev_guide/module_lifecycle.rst:43 -msgid "You can also rename a module and keep an alias to the old name by using a symlink that starts with _. This example allows the ``stat`` module to be called with ``fileinfo``, making the following examples equivalent::" -msgstr "_ で始まるシンボリックリンクを使用して、モジュールの名前を変更し、エイリアスを古い名前に保つこともできます。この例では、``stat`` モジュールを ``fileinfo`` で呼び出すことができるため、次の例は同等になります。" - -#: ../../rst/dev_guide/overview_architecture.rst:3 -msgid "Ansible architecture" -msgstr "Ansible アーキテクチャー" - -#: ../../rst/dev_guide/overview_architecture.rst:5 -msgid "Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs." -msgstr "Ansible は、クラウドプロビジョニング、設定管理、アプリケーションのデプロイメント、サービス内オーケストレーション、およびその他の IT のニーズを自動化する非常にシンプルな IT 自動化エンジンです。" - -#: ../../rst/dev_guide/overview_architecture.rst:7 -msgid "Being designed for multi-tier deployments since day one, Ansible models your IT infrastructure by describing how all of your systems inter-relate, rather than just managing one system at a time." -msgstr "Ansible は、リリースされたその日から多層デプロイメント用に設計されており、システムを 1 つずつ管理する代わりに、すべてのシステムがどのように相互に関連しているかを記述することで、IT インフラストラクチャーをモデル化します。" - -#: ../../rst/dev_guide/overview_architecture.rst:9 -msgid "It uses no agents and no additional custom security infrastructure, so it's easy to deploy - and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow you to describe your automation jobs in a way that approaches plain English." -msgstr "エージェントを使用せず、カスタムセキュリティーインフラストラクチャーを追加しないため、簡単にデプロイメントできます。最も重要なことは、非常に単純な言語 (YAML を Ansible Playbook の形式で使用) を使用しているため、分かりやすい英語に近づける方法で自動化ジョブを記述できます。" - -#: ../../rst/dev_guide/overview_architecture.rst:11 -msgid "In this section, we'll give you a really quick overview of how Ansible works so you can see how the pieces fit together." -msgstr "本セクションでは、Ansible の動作の概要を簡単に説明します。これにより各ピースがどのように組み合わされているかを確認できます。" - -#: ../../rst/dev_guide/overview_architecture.rst:17 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/dev_guide/overview_architecture.rst:19 -msgid "Ansible works by connecting to your nodes and pushing out scripts called \"Ansible modules\" to them. Most modules accept parameters that describe the desired state of the system. Ansible then executes these modules (over SSH by default), and removes them when finished. Your library of modules can reside on any machine, and there are no servers, daemons, or databases required." -msgstr "Ansible は、ノードに接続し、「Ansible モジュール」と呼ばれるスクリプトをノードにプッシュすることで機能します。ほとんどのモジュールは、システムの希望の状態を記述するパラメーターを受け入れます。その後、Ansible はこれらのモジュールを実行して (デフォルトでは SSH 上)、終了すると削除されます。モジュールのライブラリーはどのマシンにも配置でき、サーバー、デーモン、またはデータベースは必要ありません。" - -#: ../../rst/dev_guide/overview_architecture.rst:22 -msgid "You can :ref:`write your own modules `, though you should first consider :ref:`whether you should `. Typically you'll work with your favorite terminal program, a text editor, and probably a version control system to keep track of changes to your content. You may write specialized modules in any language that can return JSON (Ruby, Python, bash, and so on)." -msgstr ":ref:`独自のモジュールを記述 ` ができますが、最初に :ref:`記述すべきかどうか ` を検討する必要があります。通常、任意のターミナルプログラム、テキストエディター、およびおそらくバージョン管理システムを使用して、コンテンツへの変更を追跡します。JSON を返すことができる任意の言語 (Ruby、Python、bash など) で特殊なモジュールを作成できます。" - -#: ../../rst/dev_guide/overview_architecture.rst:25 -msgid "Module utilities" -msgstr "モジュールユーティリティー" - -#: ../../rst/dev_guide/overview_architecture.rst:27 -msgid "When multiple modules use the same code, Ansible stores those functions as module utilities to minimize duplication and maintenance. For example, the code that parses URLs is ``lib/ansible/module_utils/url.py``. You can :ref:`write your own module utilities ` as well. Module utilities may only be written in Python or in PowerShell." -msgstr "複数のモジュールが同じコードを使用する場合は、Ansible がこの機能をモジュールユーティリティーとして保存し、重複とメンテナンスを最小限に抑えます。たとえば、URL を解析するコードは次のとおりです (``lib/ansible/module_utils/url.py``)。:ref:`独自のモジュールユーティリティーを記述 ` をすることもできます。モジュールユーティリティーは、Python または PowerShell でのみ記述できます。" - -#: ../../rst/dev_guide/overview_architecture.rst:30 -msgid "Plugins" -msgstr "プラグイン" - -#: ../../rst/dev_guide/overview_architecture.rst:32 -msgid ":ref:`Plugins ` augment Ansible's core functionality. While modules execute on the target system in separate processes (usually that means on a remote system), plugins execute on the control node within the ``/usr/bin/ansible`` process. Plugins offer options and extensions for the core features of Ansible - transforming data, logging output, connecting to inventory, and more. Ansible ships with a number of handy plugins, and you can easily :ref:`write your own `. For example, you can write an :ref:`inventory plugin ` to connect to any datasource that returns JSON. Plugins must be written in Python." -msgstr ":ref:`Plugins ` は、Ansible のコア機能を拡張するものです。モジュールがターゲットシステム上で別のプロセス (通常はリモートシステム上) で実行されるのに対し、プラグインは、``/usr/bin/ansible`` プロセス内のコントロールノードで実行されます。プラグインは、データの変換、出力のロギング、インベントリーへの接続など、Ansible のコア機能のオプションや拡張機能を提供します。Ansible には便利なプラグインが多数同梱されており、簡単に :ref:`自作 ` できます。たとえば、JSON を返すあらゆるデータソースに接続するための :ref:`inventory プラグイン ` を記述することができます。プラグインは Python で記述されている必要があります。" - -#: ../../rst/dev_guide/overview_architecture.rst:35 -msgid "Inventory" -msgstr "インベントリー" - -#: ../../rst/dev_guide/overview_architecture.rst:37 -msgid "By default, Ansible represents the machines it manages in a file (INI, YAML, and so on) that puts all of your managed machines in groups of your own choosing." -msgstr "デフォルトでは、Ansible は、自身が作成したグループにすべての管理マシンを配置するファイル (INI、YAML など) で管理するマシンを表します。" - -#: ../../rst/dev_guide/overview_architecture.rst:39 -msgid "To add new machines, there is no additional SSL signing server involved, so there's never any hassle deciding why a particular machine didn't get linked up due to obscure NTP or DNS issues." -msgstr "新規マシンを追加するための、追加の SSL 署名サーバーはありません。したがって、NTP または DNS の問題が原因で特定のマシンがリンクされない理由を判断する手間がかかります。" - -#: ../../rst/dev_guide/overview_architecture.rst:41 -msgid "If there's another source of truth in your infrastructure, Ansible can also connect to that. Ansible can draw inventory, group, and variable information from sources like EC2, Rackspace, OpenStack, and more." -msgstr "インフラストラクチャーに信頼できる別のソースがある場合は、Ansible もこれに接続できます。Ansible は、EC2、Rackspace、OpenStack などのソースからインベントリー、グループ、および変数情報を取り出すことができます。" - -#: ../../rst/dev_guide/overview_architecture.rst:43 -msgid "Here's what a plain text inventory file looks like::" -msgstr "プレーンテキストのインベントリーファイルは次のようになります。" - -#: ../../rst/dev_guide/overview_architecture.rst:54 -msgid "Once inventory hosts are listed, variables can be assigned to them in simple text files (in a subdirectory called 'group_vars/' or 'host_vars/' or directly in the inventory file." -msgstr "インベントリーホストの一覧が作成されると、単純なテキストファイル形式で (「group_vars/」または「host_vars/」という名前のサブディレクトリー内、またはインベントリーファイルに直接) 割り当てることができます。" - -#: ../../rst/dev_guide/overview_architecture.rst:56 -msgid "Or, as already mentioned, use a dynamic inventory to pull your inventory from data sources like EC2, Rackspace, or OpenStack." -msgstr "または、上述のように、動的インベントリーを使用して、EC2、Rackspace、OpenStack のようなデータソースからインベントリーをプルすることもできます。" - -#: ../../rst/dev_guide/overview_architecture.rst:59 -msgid "Playbooks" -msgstr "Playbook" - -#: ../../rst/dev_guide/overview_architecture.rst:61 -msgid "Playbooks can finely orchestrate multiple slices of your infrastructure topology, with very detailed control over how many machines to tackle at a time. This is where Ansible starts to get most interesting." -msgstr "Playbook は、インフラストラクチャートポロジーの複数のスライスを細かく調整 (オーケストレーション) することができ、同時に取り組むマシンの数を非常に細かく制御することができます。ここからが、Ansible で最も魅力的な点になります。" - -#: ../../rst/dev_guide/overview_architecture.rst:63 -msgid "Ansible's approach to orchestration is one of finely-tuned simplicity, as we believe your automation code should make perfect sense to you years down the road and there should be very little to remember about special syntax or features." -msgstr "Ansible のオーケストレーションへのアプローチは、細かく調整された簡素化の 1 つです。通常、自動化コードは今後何年にもわたって完全に理解できるものであり、特別な構文や機能について覚えておくべきことはほとんどないためです。" - -#: ../../rst/dev_guide/overview_architecture.rst:65 -msgid "Here's what a simple playbook looks like::" -msgstr "以下は単純な Playbook の例です。" - -#: ../../rst/dev_guide/overview_architecture.rst:82 -msgid "The Ansible search path" -msgstr "Ansible 検索パス" - -#: ../../rst/dev_guide/overview_architecture.rst:84 -msgid "Modules, module utilities, plugins, playbooks, and roles can live in multiple locations. If you write your own code to extend Ansible's core features, you may have multiple files with similar or the same names in different locations on your Ansible control node. The search path determines which of these files Ansible will discover and use on any given playbook run." -msgstr "モジュール、モジュールユーティリティー、プラグイン、Playbook、およびロールは複数の場所に置くことができます。Ansible コントロールノードの異なる場所に同じ名前または類似する名前を持つファイルが複数存在する場合があります。検索パスにより、Ansible が特定の Playbook の実行で検出して使用するこれらのファイルが決まります。" - -#: ../../rst/dev_guide/overview_architecture.rst:87 -msgid "Ansible's search path grows incrementally over a run. As Ansible finds each playbook and role included in a given run, it appends any directories related to that playbook or role to the search path. Those directories remain in scope for the duration of the run, even after the playbook or role has finished executing. Ansible loads modules, module utilities, and plugins in this order:" -msgstr "Ansible の検索パスは、実行中に徐々に大きくなります。Ansible は、特定の実行に含まれる各 Playbook とロールを見つけると、その Playbook またはロールに関連するディレクトリーを検索パスに追加します。これらのディレクトリーは、Playbook またはロールの実行が終了した後でも、実行中はスコープ内に留まります。Ansible は、モジュール、モジュールユーティリティー、プラグインを次の順序で読み込みます。" - -#: ../../rst/dev_guide/overview_architecture.rst:93 -msgid "Directories adjacent to a playbook specified on the command line. If you run Ansible with ``ansible-playbook /path/to/play.yml``, Ansible appends these directories if they exist:" -msgstr "コマンドラインで指定した Playbook に隣接するディレクトリー。``ansible-playbook /path/to/play.yml`` で Ansible を実行し、そのディレクトリーが存在する場合は、Ansible がそのディレクトリーを追加します。" - -#: ../../rst/dev_guide/overview_architecture.rst:101 -msgid "Directories adjacent to a playbook that is statically imported by a playbook specified on the command line. If ``play.yml`` includes ``- import_playbook: /path/to/subdir/play1.yml``, Ansible appends these directories if they exist:" -msgstr "コマンドラインで指定された Playbook によって静的にインポートされる Playbook に隣接するディレクトリー。``play.yml`` に ``- import_playbook: /path/to/subdir/play1.yml`` が含まれている場合、Ansible は、これらのディレクトリーが存在する場合、それらを追加します。" - -#: ../../rst/dev_guide/overview_architecture.rst:111 -msgid "Subdirectories of a role directory referenced by a playbook. If ``play.yml`` runs ``myrole``, Ansible appends these directories if they exist:" -msgstr "Playbook によって参照されるロールディレクトリーのサブディレクトリー。``play.yml`` が ``myrole`` を実行し、次のディレクトリーが存在する場合は、そのディレクトリーを Ansible が追加します。" - -#: ../../rst/dev_guide/overview_architecture.rst:120 -msgid "Directories specified as default paths in ``ansible.cfg`` or by the related environment variables, including the paths for the various plugin types. See :ref:`ansible_configuration_settings` for more information. Sample ``ansible.cfg`` fields:" -msgstr "``ansible.cfg`` のデフォルトパスとして、またはさまざまなプラグインタイプのパスなど、関連する環境変数により指定されたディレクトリーて。詳細は、:ref:`ansible_configuration_settings` を参照してください。サンプルの ``ansible.cfg`` フィールドは以下のようになります。" - -#: ../../rst/dev_guide/overview_architecture.rst:131 -msgid "Sample environment variables:" -msgstr "以下は、環境変数の例となります。" - -#: ../../rst/dev_guide/overview_architecture.rst:140 -msgid "The standard directories that ship as part of the Ansible distribution." -msgstr "Ansible ディストリビューションに同梱される標準ディレクトリー。" - -#: ../../rst/dev_guide/overview_architecture.rst:144 -msgid "Modules, module utilities, and plugins in user-specified directories will override the standard versions. This includes some files with generic names. For example, if you have a file named ``basic.py`` in a user-specified directory, it will override the standard ``ansible.module_utils.basic``." -msgstr "ユーザーが指定したディレクトリーにあるモジュール、モジュールユーティリティー、およびプラグインは標準バージョンを上書きします。これには、一般的な名前のファイルも含まれます。たとえば、ユーザー指定のディレクトリーに ``basic.py`` という名前がある場合は、標準の ``ansible.module_utils.basic`` を上書きします。" - -#: ../../rst/dev_guide/overview_architecture.rst:149 -msgid "If you have more than one module, module utility, or plugin with the same name in different user-specified directories, the order of commands at the command line and the order of includes and roles in each play will affect which one is found and used on that particular play." -msgstr "同じ名前のモジュール、モジュールユーティリティー、またはプラグインが複数のユーザー指定ディレクトリーにある場合は、コマンドラインでのコマンドの順序や、各プレイでのインクルードとロールの順序は、その特定のプレイでどのモジュールが見つかり、使用されるかによって異なります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:5 -msgid "Guidelines for Ansible Amazon AWS module development" -msgstr "Ansible Amazon AWS モジュール開発のガイドライン" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:7 -msgid "The Ansible AWS collection (on `Galaxy `_, source code `repository `_) is maintained by the Ansible AWS Working Group. For further information see the `AWS working group community page `_. If you are planning to contribute AWS modules to Ansible then getting in touch with the working group is a good way to start, especially because a similar module may already be under development." -msgstr "Ansible AWS コレクション (`Galaxy `_ では、ソースコード `レポジトリー `_) は、Ansible AWS のワーキンググループ維持されます。詳細は `AWS ワーキンググループのコミュニティーページ `_ を参照してください。AWS モジュールを Ansible に提供することを計画している場合は、特に同様のモジュールがすでに開発中である可能性があるため、ワーキンググループに連絡することから始めることを推奨します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:13 -msgid "Maintaining existing modules" -msgstr "既存のモジュールのメンテナンス" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:16 -msgid "Fixing bugs" -msgstr "バグの修正" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:18 -msgid "Bug fixes to code that relies on boto will still be accepted. When possible, the code should be ported to use boto3." -msgstr "boto に依存するコードに対するバグ修正は引き続き承認されます。可能であれば、このコードは、boto3 を使用するように移植する必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:22 -msgid "Adding new features" -msgstr "新しい機能の追加" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:24 -msgid "Try to keep backward compatibility with relatively recent versions of boto3. That means that if you want to implement some functionality that uses a new feature of boto3, it should only fail if that feature actually needs to be run, with a message stating the missing feature and minimum required version of boto3." -msgstr "比較的最近のバージョンの boto3 との下位互換性を保つようにしてください。つまり、boto3 の新機能を使用する一部の機能を実装する場合は、その機能を実際に実行する必要がある場合にのみ失敗し、欠落している機能と最低限必要な boto3 のバージョンを示すメッセージが表示されます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:29 -msgid "Use feature testing (for example, ``hasattr('boto3.module', 'shiny_new_method')``) to check whether boto3 supports a feature rather than version checking. For example, from the ``ec2`` module:" -msgstr "機能テスト (例: ``hasattr('boto3.module', 'shiny_new_method')``) を使用して、boto3 がバージョンチェックではなく機能をサポートしているかどうかを確認します。たとえば、``ec2`` モジュールからです。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:41 -msgid "Migrating to boto3" -msgstr "boto3 への移行" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:43 -msgid "Prior to Ansible 2.0, modules were written in either boto3 or boto. We are still porting some modules to boto3. Modules that still require boto should be ported to use boto3 rather than using both libraries (boto and boto3). We would like to remove the boto dependency from all modules." -msgstr "Ansible 2.0 より前、モジュールは boto3 または boto のいずれかで記述されていました。まだ、いくつかのモジュールを boto3 に移植しています。それでもbotoが必要なモジュールは、両方のライブラリー (boto と boto3) を使用するのではなく、boto3 を使用するように移植する必要があります。すべてのモジュールから boto 依存関係を削除したいと考えています。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:47 -msgid "Porting code to AnsibleAWSModule" -msgstr "AnsibleAWSModule へのコードの移植" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:49 -msgid "Some old AWS modules use the generic ``AnsibleModule`` as a base rather than the more efficient ``AnsibleAWSModule``. To port an old module to ``AnsibleAWSModule``, change:" -msgstr "一部の古い AWS モジュールは、より効率的な ``AnsibleAWSModule`` ではなく、汎用の ``AnsibleModule`` をベースとして使用します。古いモジュールを ``AnsibleAWSModule`` に移植するには、以下を変更します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:57 -msgid "to:" -msgstr "以下のように変更します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:65 -msgid "Few other changes are required. AnsibleAWSModule does not inherit methods from AnsibleModule by default, but most useful methods are included. If you do find an issue, please raise a bug report." -msgstr "その他の変更が必要になります。AnsibleAWSModule はデフォルトで AnsibleModule のメソッドを継承しませんが、最も便利なメソッドが含まれています。問題を発見した場合は、バグレポートを提出してください。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:69 -msgid "When porting, keep in mind that AnsibleAWSModule also will add the default ec2 argument spec by default. In pre-port modules, you should see common arguments specified with:" -msgstr "ポート時には、AnsibleAWSModule はデフォルトでデフォルトの ec2 引数仕様も追加します。事前ポートモジュールでは、以下で指定された一般的な引数が表示されるはずです。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:84 -msgid "These can be replaced with:" -msgstr "これは、次のものと置き換えることができます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:97 -msgid "Creating new AWS modules" -msgstr "新規 AWS モジュールの作成" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:100 -msgid "Use boto3 and AnsibleAWSModule" -msgstr "boto3 および AnsibleAWSModule の使用" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:102 -msgid "All new AWS modules must use boto3 and ``AnsibleAWSModule``." -msgstr "すべての新規 AWS モジュールは boto3 および ``AnsibleAWSModule`` を使用する必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:104 -msgid "``AnsibleAWSModule`` greatly simplifies exception handling and library management, reducing the amount of boilerplate code. If you cannot use ``AnsibleAWSModule`` as a base, you must document the reason and request an exception to this rule." -msgstr "``AnsibleAWSModule`` は、例外処理とライブラリー管理を大幅に簡素化し、ボイラープレートコードの量を削減します。``AnsibleAWSModule`` をベースとして使えない場合は、理由を文書化し、このルールの例外を要求する必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:109 -msgid "Naming your module" -msgstr "モジュールの名前付け" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:111 -msgid "Base the name of the module on the part of AWS that you actually use. (A good rule of thumb is to take whatever module you use with boto as a starting point). Don't further abbreviate names - if something is a well known abbreviation of a major component of AWS (for example, VPC or ELB), that's fine, but don't create new ones independently." -msgstr "実際に使用する AWS の一部であるモジュール名をベースにします (経験則として、boto で使用するモジュールを開始点として使用することが推奨されます)。名前をさらに省略しないでください。AWS の主要コンポーネント (VPC や ELB など) のよく知られた省略形である場合は問題ありませんが、新しい名前を個別に作成しないでください。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:116 -msgid "Unless the name of your service is quite unique, please consider using ``aws_`` as a prefix. For example ``aws_lambda``." -msgstr "サービスの名前が非常に一意でない限り、``aws_`` を接頭辞として使用することを検討してください。たとえば、``aws_lambda`` となります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:119 -msgid "Importing botocore and boto3" -msgstr "botocore および boto3 のインポート" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:121 -msgid "The ``ansible.module_utils.ec2`` module and ``ansible.module_utils.core.aws`` modules both automatically import boto3 and botocore. If boto3 is missing from the system then the variable ``HAS_BOTO3`` will be set to false. Normally, this means that modules don't need to import boto3 directly. There is no need to check ``HAS_BOTO3`` when using AnsibleAWSModule as the module does that check:" -msgstr "``ansible.module_utils.ec2`` モジュールと ``ansible.module_utils.core.aws`` モジュールは、boto3 と botocore を自動的にインポートします。 システムに boto3 がない場合は、変数 ``HAS_BOTO3`` が false に設定されます。通常、これは、boto3 を直接インポートする必要はありません。モジュールの確認が行われる際に AnsibleAWSModule を使用する場合は、``HAS_BOTO3`` を確認する必要はありません。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:135 -msgid "or:" -msgstr "または" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:152 -msgid "Supporting Module Defaults" -msgstr "モジュールのデフォルトのサポート" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:154 -msgid "The existing AWS modules support using :ref:`module_defaults ` for common authentication parameters. To do the same for your new module, add an entry for it in ``lib/ansible/config/module_defaults.yml``. These entries take the form of:" -msgstr "既存の AWS モジュールは、共通の認証パラメーターに :ref:`module_defaults ` を使用したサポートです。新しいモジュールに同じモジュールを行うには、``lib/ansible/config/module_defaults.yml`` でエントリーを追加します。これらのエントリーは以下の形式になります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:164 -msgid "Connecting to AWS" -msgstr "AWS への接続" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:166 -msgid "AnsibleAWSModule provides the ``resource`` and ``client`` helper methods for obtaining boto3 connections. These handle some of the more esoteric connection options, such as security tokens and boto profiles." -msgstr "AnsibleAWSModule は、boto3 接続を取得するためのヘルパーメソッド ``resource`` および ``client`` を提供します。これらは、セキュリティートークンや boto プロファイルなど、より難解な接続オプションのいくつかを処理します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:169 -msgid "If using the basic AnsibleModule then you should use ``get_aws_connection_info`` and then ``boto3_conn`` to connect to AWS as these handle the same range of connection options." -msgstr "接続オプションと同じ範囲を処理するため、基本的な AnsibleModule を使用する場合は、``get_aws_connection_info`` を使用してから ``boto3_conn`` を使用して AWS に接続する必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:172 -msgid "These helpers also for missing profiles or a region not set when it needs to be, so you don't have to." -msgstr "これらのヘルパーは、欠落しているプロファイルや、必要なときに設定されていない領域にも使用できるため、必須ではありません。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:174 -msgid "An example of connecting to ec2 is shown below. Note that unlike boto there is no ``NoAuthHandlerFound`` exception handling like in boto. Instead, an ``AuthFailure`` exception will be thrown when you use the connection. To ensure that authorization, parameter validation and permissions errors are all caught, you should catch ``ClientError`` and ``BotoCoreError`` exceptions with every boto3 connection call. See exception handling:" -msgstr "ec2 への接続例は以下のようになります。boto とは異なり、boto には、``NoAuthHandlerFound`` の例外処理がないことに注意してください。代わりに、接続の使用時に ``AuthFailure`` 例外がスローされます。承認、パラメーター検証およびパーミッションエラーがすべてキャッチされるようにするには、すべての boto3 接続呼び出しで ``ClientError`` および ``BotoCoreError`` の例外をキャッチする必要があります。「例外処理」を参照してください。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:184 -msgid "or for the higher level ec2 resource:" -msgstr "また、より高いレベルの ec2 リソースの場合は、次のようになります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:191 -msgid "An example of the older style connection used for modules based on AnsibleModule rather than AnsibleAWSModule:" -msgstr "AnsibleAWSModule ではなく AnsibleModule に基づくモジュールに使用される旧式の接続例は次のとおりです。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:205 -msgid "Common Documentation Fragments for Connection Parameters" -msgstr "接続パラメーターに関する断片化された汎用ドキュメント" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:207 -msgid "There are two :ref:`common documentation fragments ` that should be included into almost all AWS modules:" -msgstr "ほとんどすべての AWS モジュールに含まれる :ref:`断片化された汎用ドキュメント ` は 2 つあります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:210 -msgid "``aws`` - contains the common boto connection parameters" -msgstr "``aws`` - 共通の boto 接続パラメーターが含まれます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:211 -msgid "``ec2`` - contains the common region parameter required for many AWS modules" -msgstr "``ec2`` - 数多くの AWS モジュールに必要な共通の region パラメーターが含まれます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:213 -msgid "These fragments should be used rather than re-documenting these properties to ensure consistency and that the more esoteric connection options are documented. For example:" -msgstr "一貫性を確保し、より難解な接続オプションを文書化するには、このようなプロパティーを再文書化するのではなく、このような断片化されたドキュメントを使用する必要があります。たとえば、以下のようになります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:228 -msgid "Handling exceptions" -msgstr "例外の処理" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:230 -msgid "You should wrap any boto3 or botocore call in a try block. If an exception is thrown, then there are a number of possibilities for handling it." -msgstr "try ブロックで boto3 または botocore 呼び出しをラップする必要があります。例外がスローされると、処理の可能性が多数あります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:233 -msgid "Catch the general ``ClientError`` or look for a specific error code with" -msgstr "汎用的な ``ClientError`` を取得するか、次のような特定のエラーコードを探します" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:234 -msgid "``is_boto3_error_code``." -msgstr "``is_boto3_error_code``." - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:235 -msgid "Use ``aws_module.fail_json_aws()`` to report the module failure in a standard way" -msgstr "``aws_module.fail_json_aws()`` を使用して、標準的な方法でモジュール障害を報告します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:236 -msgid "Retry using AWSRetry" -msgstr "AWSRetry を使用して再試行します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:237 -msgid "Use ``fail_json()`` to report the failure without using ``ansible.module_utils.aws.core``" -msgstr "``fail_json()`` を使用して、``ansible.module_utils.aws.core`` を使用せずに障害を報告します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:238 -msgid "Do something custom in the case where you know how to handle the exception" -msgstr "例外の処理方法が分かっている場合は、何らかのカスタマイズ作業を行います。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:240 -msgid "For more information on botocore exception handling see the `botocore error documentation `_." -msgstr "botocore 例外処理の詳細は、`botocore エラードキュメント `_ を参照してください。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:243 -msgid "Using is_boto3_error_code" -msgstr "is_boto3_error_code の使用" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:245 -msgid "To use ``ansible.module_utils.aws.core.is_boto3_error_code`` to catch a single AWS error code, call it in place of ``ClientError`` in your except clauses. In this case, *only* the ``InvalidGroup.NotFound`` error code will be caught here, and any other error will be raised for handling elsewhere in the program." -msgstr "``ansible.module_utils.aws.core.is_boto3_error_code`` を使用して単一の AWS エラーコードを取得するには、except 句で ``ClientError`` の代わりに呼び出しを行います。この場合、``InvalidGroup.NotFound`` エラーコードをここに検出し、その他のエラーでプログラム内の別の場所を処理する際に発生します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:259 -msgid "Using fail_json_aws()" -msgstr "fail_json_aws() の使用" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:261 -msgid "In the AnsibleAWSModule there is a special method, ``module.fail_json_aws()`` for nice reporting of exceptions. Call this on your exception and it will report the error together with a traceback for use in Ansible verbose mode." -msgstr "AnsibleAWSModule には、例外レポートに優れた方法 ``module.fail_json_aws()`` があります。例外上でこの呼び出しを行い、Ansible の冗長モードで使用するためにトレースバックと共にエラーを報告します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:265 -msgid "You should use the AnsibleAWSModule for all new modules, unless not possible. If adding significant amounts of exception handling to existing modules, we recommend migrating the module to use AnsibleAWSModule (there are very few changes required to do this)" -msgstr "不可能でない限り、すべての新しいモジュールに AnsibleAWSModule を使用する必要があります。既存のモジュールに大量の例外処理を追加する場合は、AnsibleAWSModule を使用するようにモジュールを移行することが推奨されます (これを行うために必要な変更はほとんどありません)。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:286 -msgid "Note that it should normally be acceptable to catch all normal exceptions here, however if you expect anything other than botocore exceptions you should test everything works as expected." -msgstr "通常、ここですべての通常の例外を捕えても問題がないことに注意してください。ただし、botocore 以外の例外が予想される場合は、すべてが期待どおりに機能するかどうかをテストする必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:289 -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:334 -msgid "If you need to perform an action based on the error boto3 returned, use the error code." -msgstr "返された boto3 エラーに基づいてアクションを実行する必要がある場合は、このエラーコードを使用します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:306 -msgid "using fail_json() and avoiding ansible.module_utils.aws.core" -msgstr "fail_json() and avoiding ansible.module_utils.aws.core の使用" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:308 -msgid "Boto3 provides lots of useful information when an exception is thrown so pass this to the user along with the message." -msgstr "Boto3 は、例外が発生したときに多くの有用な情報を提供するため、メッセージと共にこれをユーザーに渡します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:331 -msgid "Note: we use `str(e)` rather than `e.message` as the latter doesn't work with python3" -msgstr "注記: 後者は python3 では機能しないため、`e.message` の代わりに `str(e)` を使用します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:354 -msgid "API throttling (rate limiting) and pagination" -msgstr "API スロットリング (レート制限) とページネーション" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:356 -msgid "For methods that return a lot of results, boto3 often provides `paginators `_. If the method you're calling has ``NextToken`` or ``Marker`` parameters, you should probably check whether a paginator exists (the top of each boto3 service reference page has a link to Paginators, if the service has any). To use paginators, obtain a paginator object, call ``paginator.paginate`` with the appropriate arguments and then call ``build_full_result``." -msgstr "大量の結果を返すメソッドの場合、boto3 はしばしば `paginators `_ を提供します。呼び出しているメソッドに ``NextToken`` パラメーターまたは ``Marker`` パラメーターがある場合は、Paginator が存在するかどうかを確認する必要があります (各 boto3 サービスに paginator がある場合は、参照ページ上部に Paginator へのリンクがあります)。paginator を使用するには、paginator オブジェクトを取得し、適切な引数を指定して ``paginator.paginate`` を呼び出してから、``build_full_result`` を呼び出します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:363 -msgid "Any time that you are calling the AWS API a lot, you may experience API throttling, and there is an ``AWSRetry`` decorator that can be used to ensure backoff. Because exception handling could interfere with the retry working properly (as AWSRetry needs to catch throttling exceptions to work correctly), you'd need to provide a backoff function and then put exception handling around the backoff function." -msgstr "AWS API を大量に呼び出しているのはいつでも、API スロットリングが発生する可能性があり、バックオフ機能を提供するために使用できる ``AWSRetry`` デコレーターがあります。例外処理は再試行が正しく機能するのを妨げる可能性があるため (AWSRetry が正しく機能するためにスロットリング例外を取得する必要があるため)、バックオフ関数を提供してから、バックオフ関数の周りに例外処理を配置する必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:369 -msgid "You can use ``exponential_backoff`` or ``jittered_backoff`` strategies - see the cloud ``module_utils`` ()/lib/ansible/module_utils/cloud.py) and `AWS Architecture blog `_ for more details." -msgstr "``exponential_backoff`` または ``jittered_backoff`` ストラテジーを使用できます。詳細は、クラウド ``module_utils`` ()/lib/ansible/module_utils/cloud.py) および `AWS アーキテクチャーのブログ `_ を参照してください。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:373 -msgid "The combination of these two approaches is then:" -msgstr "これら 2 つのアプローチの組み合わせは次のとおりです。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:390 -msgid "If the underlying ``describe_some_resources`` API call throws a ``ResourceNotFound`` exception, ``AWSRetry`` takes this as a cue to retry until it's not thrown (this is so that when creating a resource, we can just retry until it exists)." -msgstr "基礎となる ``describe_some_resources`` API 呼び出しで ``ResourceNotFound`` 例外を出力すると、``AWSRetry`` はこれが出力されなくなるまで再試行する合図としてこれを受け取ります (これは、リソースを作成するときに、リソースが存在するまで再試行できるようにするためです)。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:394 -msgid "To handle authorization failures or parameter validation errors in ``describe_some_resource_with_backoff``, where we just want to return ``None`` if the resource doesn't exist and not retry, we need:" -msgstr "リソースが存在しない場合、およびリソースが再試行されていない場合のみ ``None`` を返す ``describe_some_resource_with_backoff`` で承認の失敗またはパラメーター検証エラーを処理するには、以下が必要になります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:420 -msgid "To make use of AWSRetry easier, it can now be wrapped around a client returned by ``AnsibleAWSModule``. any call from a client. To add retries to a client, create a client:" -msgstr "AWSRetry を使いやすくするために、``AnsibleAWSModule`` (クライアントからの呼び出し) によって返されたクライアントをラップできるようになりました。クライアントに再試行を追加するには、クライアントを作成します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:428 -msgid "Any calls from that client can be made to use the decorator passed at call-time using the `aws_retry` argument. By default, no retries are used." -msgstr "そのクライアントからの呼び出しはすべて、`aws_retry` 引数を使用して呼び出し時に渡されたデコレーターを使用して行うことができます。デフォルトでは、再試行は使用されません。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:443 -msgid "The call will be retried the specified number of times, so the calling functions don't need to be wrapped in the backoff decorator." -msgstr "呼び出しは指定された回数だけ再試行されるため、呼び出し元の関数をバックオフデコレーターでラップする必要はありません。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:446 -msgid "You can also use customization for ``retries``, ``delay`` and ``max_delay`` parameters used by ``AWSRetry.jittered_backoff`` API using module params. You can take a look at the `cloudformation ` module for example." -msgstr "また、モジュールパラメーターを使用して、``AWSRetry.jittered_backoff`` API が使用する ``retries`` パラメーター、``delay`` パラメーター、および ``max_delay`` パラメーターのカスタマイズを使用することもできます。たとえば、`cloudformation ` モジュールを参照してください。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:451 -msgid "To make all Amazon modules uniform, prefix the module param with ``backoff_``, so ``retries`` becomes ``backoff_retries``" -msgstr "すべての Amazon モジュールを均一にするには、モジュールパラメーターの前に ``backoff_`` を付けます。これにより、``retries`` は ``backoff_retries`` になります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:451 -msgid "and likewise with ``backoff_delay`` and ``backoff_max_delay``." -msgstr "``backoff_delay`` と ``backoff_max_delay`` も同様です。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:454 -msgid "Returning Values" -msgstr "戻り値" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:456 -msgid "When you make a call using boto3, you will probably get back some useful information that you should return in the module. As well as information related to the call itself, you will also have some response metadata. It is OK to return this to the user as well as they may find it useful." -msgstr "boto3 を使用して呼び出しを行うと、モジュールで返す必要がある便利な情報を入手できます。また、呼び出し自体に関連する情報や応答メタデータもあります。これをユーザーに返すことは問題ありませんが、ユーザーはそれが役立つと思うかもしれません。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:460 -msgid "Boto3 returns all values CamelCased. Ansible follows Python standards for variable names and uses snake_case. There is a helper function in module_utils/ec2.py called `camel_dict_to_snake_dict` that allows you to easily convert the boto3 response to snake_case." -msgstr "boto3 は、キャメルケース化したすべての値を返します。Ansible は変数名の Python 標準に従い、snake_case を使用します。`camel_dict_to_snake_dict` という名前の module_utils/ec2.py にヘルパー関数があり、boto3 を簡単に snake_case に変換できます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:464 -msgid "You should use this helper function and avoid changing the names of values returned by Boto3. E.g. if boto3 returns a value called 'SecretAccessKey' do not change it to 'AccessKey'." -msgstr "このヘルパー関数を使用し、Boto3 が返す値の名前を変更しないでください。たとえば、boto3 が「SecretAccessKey」値を返す場合は、これを「AccessKey」に変更しないでください。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:476 -msgid "Dealing with IAM JSON policy" -msgstr "IAM JSON ポリシーの処理" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:478 -msgid "If your module accepts IAM JSON policies then set the type to 'json' in the module spec. For example:" -msgstr "モジュールが IAM JSON ポリシーを受け入れる場合は、モジュール仕様でタイプを「json」に設定します。たとえば、以下のようになります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:489 -msgid "Note that AWS is unlikely to return the policy in the same order that is was submitted. Therefore, use the `compare_policies` helper function which handles this variance." -msgstr "AWS が、送信された順序でポリシーを返すことはほとんどありません。したがって、この差異を処理する `compare_policies` ヘルパー関数を使用します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:492 -msgid "`compare_policies` takes two dictionaries, recursively sorts and makes them hashable for comparison and returns True if they are different." -msgstr "`compare_policies` は、2 つのディクショナリーを取得し、再帰的にソートし、比較のためにハッシュを可能にし、異なる場合は True を返します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:516 -msgid "Dealing with tags" -msgstr "タグの処理" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:518 -msgid "AWS has a concept of resource tags. Usually the boto3 API has separate calls for tagging and untagging a resource. For example, the ec2 API has a create_tags and delete_tags call." -msgstr "AWS にはリソースタグの概念があります。通常、boto3 API には、リソースのタグ付けとタグ付け解除のための呼び出しがあります。たとえば、ec2 API には create_tags および delete_tags の呼び出しがあります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:521 -msgid "It is common practice in Ansible AWS modules to have a `purge_tags` parameter that defaults to true." -msgstr "これは、デフォルトが true の `purge_tags` パラメーターがある Ansible AWS モジュールでは一般的な方法です。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:524 -msgid "The `purge_tags` parameter means that existing tags will be deleted if they are not specified by the Ansible task." -msgstr "`purge_tags` パラメーターは、既存のタグが Ansible タスクで指定されていない場合に削除されることを示しています。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:527 -msgid "There is a helper function `compare_aws_tags` to ease dealing with tags. It can compare two dicts and return the tags to set and the tags to delete. See the Helper function section below for more detail." -msgstr "タグの扱いを容易にするためヘルパー機能 `compare_aws_tags` があります。2 つのディクショナリーを比較し、設定するタグと削除するタグを返すことができます。詳細については、以下のヘルパー関数のセクションを参照してください。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:532 -msgid "Helper functions" -msgstr "helper 関数" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:534 -msgid "Along with the connection functions in Ansible ec2.py module_utils, there are some other useful functions detailed below." -msgstr "Ansible ec2.py module_utils の接続関数に加えて、以下に説明するいくつかの便利な関数があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:538 -msgid "camel_dict_to_snake_dict" -msgstr "camel_dict_to_snake_dict" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:540 -msgid "boto3 returns results in a dict. The keys of the dict are in CamelCase format. In keeping with Ansible format, this function will convert the keys to snake_case." -msgstr "boto3 はディクショナリーの結果を返します。ディクショナリーのキーは CamelCase 形式になります。Ansible 形式を維持すると、この機能はキーを snake_case に変換します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:543 -msgid "``camel_dict_to_snake_dict`` takes an optional parameter called ``ignore_list`` which is a list of keys not to convert (this is usually useful for the ``tags`` dict, whose child keys should remain with case preserved)" -msgstr "``camel_dict_to_snake_dict`` は、``ignore_list`` 呼ばれる任意のパラメーターを取ります。これは、変換しないキーの一覧です。これは通常、``tags`` ディクショナリーに役に立ちます。この子キーは大文字と小文字を区別して保持する必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:547 -msgid "Another optional parameter is ``reversible``. By default, ``HTTPEndpoint`` is converted to ``http_endpoint``, which would then be converted by ``snake_dict_to_camel_dict`` to ``HttpEndpoint``. Passing ``reversible=True`` converts HTTPEndpoint to ``h_t_t_p_endpoint`` which converts back to ``HTTPEndpoint``." -msgstr "その他の任意のパラメーターは ``reversible`` です。デフォルトでは、``HTTPEndpoint`` は ``http_endpoint`` に変換されます。これは、``snake_dict_to_camel_dict`` によって ``HttpEndpoint`` に変換されます。``reversible=True`` を渡すと、HTTPEndpoint が ``h_t_t_p_endpoint`` に変換され、``HTTPEndpoint`` に変換され直されます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:552 -msgid "snake_dict_to_camel_dict" -msgstr "snake_dict_to_camel_dict" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:554 -msgid "`snake_dict_to_camel_dict` converts snake cased keys to camel case. By default, because it was first introduced for ECS purposes, this converts to dromedaryCase. An optional parameter called `capitalize_first`, which defaults to `False`, can be used to convert to CamelCase." -msgstr "`snake_dict_to_camel_dict` は、スネークケースのキーをキャメルケースに変換します。デフォルトでは、ECS の目的で最初に導入されたため、これは dromedaryCase に変換されます。`capitalize_first` と呼ばれる任意のパラメーターは、`False` にデフォルトされ、CamelCase への変換に使用できます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:559 -msgid "ansible_dict_to_boto3_filter_list" -msgstr "ansible_dict_to_boto3_filter_list" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:561 -msgid "Converts a an Ansible list of filters to a boto3 friendly list of dicts. This is useful for any boto3 `_facts` modules." -msgstr "フィルターの Ansible リストを、ディクショナリーの boto3 フレンドリーリストに変換します。これは、boto3 の `_facts` モジュールに役立ちます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:565 -msgid "boto_exception" -msgstr "boto_exception" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:567 -msgid "Pass an exception returned from boto or boto3, and this function will consistently get the message from the exception." -msgstr "boto または boto3 から返された例外を渡します。この関数は、例外からメッセージを一貫して取得します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:569 -msgid "Deprecated: use `AnsibleAWSModule`'s `fail_json_aws` instead." -msgstr "非推奨: 代わりに `AnsibleAWSModule` の `fail_json_aws` を使用してください。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:573 -msgid "boto3_tag_list_to_ansible_dict" -msgstr "boto3_tag_list_to_ansible_dict" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:575 -msgid "Converts a boto3 tag list to an Ansible dict. Boto3 returns tags as a list of dicts containing keys called 'Key' and 'Value' by default. This key names can be overridden when calling the function. For example, if you have already camel_cased your list of tags you may want to pass lowercase key names instead, in other words, 'key' and 'value'." -msgstr "boto3 タグリストを Ansible ディクショナリーに変換します。Boto3 は、「Key」および「Value」という名前のキーがデフォルトで含まれる ディクショナリーのリストとしてタグを返します。このキーは、関数を呼び出す際に上書きできます。たとえば、タグのリストをすでにキャメルケース化している場合は、代わりに小文字のキー名、つまり「key」と「value」を渡すことができます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:580 -msgid "This function converts the list in to a single dict where the dict key is the tag key and the dict value is the tag value." -msgstr "この関数は、リストを単一のディクショナリーに変換します。dict キーはタグキーで、dict 値はタグの値です。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:584 -msgid "ansible_dict_to_boto3_tag_list" -msgstr "ansible_dict_to_boto3_tag_list" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:586 -msgid "Opposite of above. Converts an Ansible dict to a boto3 tag list of dicts. You can again override the key names used if 'Key' and 'Value' is not suitable." -msgstr "上記の逆で、Ansible ディクショナリーをディクショナリーの boto3 タグ一覧に変換します。「Key」と「Value」が適していないときに使用されるキー名を再度上書きすることもできます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:590 -msgid "get_ec2_security_group_ids_from_names" -msgstr "get_ec2_security_group_ids_from_names" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:592 -msgid "Pass this function a list of security group names or combination of security group names and IDs and this function will return a list of IDs. You should also pass the VPC ID if known because security group names are not necessarily unique across VPCs." -msgstr "この関数にセキュリティーグループ名のリスト、またはセキュリティーグループ名とIDの組み合わせを渡すと、この関数は ID のリストを返します。セキュリティーグループ名は VPC 間で必ずしも一意であるとは限らないため、既知の場合は VPCID も渡す必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:597 -msgid "compare_policies" -msgstr "compare_policies" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:599 -msgid "Pass two dicts of policies to check if there are any meaningful differences and returns true if there are. This recursively sorts the dicts and makes them hashable before comparison." -msgstr "ポリシーの 2 つのディクショナリーを渡して、意味のある差異があるかどうかを確認し、ある場合は true を返します。これにより、ディクショナリーが再帰的にソートされ、比較前にハッシュ可能になります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:602 -msgid "This method should be used any time policies are being compared so that a change in order doesn't result in unnecessary changes." -msgstr "この方法は、順序を変更しても不要な変更が発生しないように、ポリシーを比較するときに必ず使用する必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:606 -msgid "compare_aws_tags" -msgstr "compare_aws_tags" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:608 -msgid "Pass two dicts of tags and an optional purge parameter and this function will return a dict containing key pairs you need to modify and a list of tag key names that you need to remove. Purge is True by default. If purge is False then any existing tags will not be modified." -msgstr "タグの 2 つのディクショナリーと任意の purge パラメーターを渡します。この関数はディクショナリーを返します。これには、変更するキーペアと、削除する必要のあるタグキー名の一覧が含まれています。パージは、デフォルトで True です。パージが False の場合は、既存のタグが変更されません。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:612 -msgid "This function is useful when using boto3 'add_tags' and 'remove_tags' functions. Be sure to use the other helper function `boto3_tag_list_to_ansible_dict` to get an appropriate tag dict before calling this function. Since the AWS APIs are not uniform (for example, EC2 is different from Lambda) this will work without modification for some (Lambda) and others may need modification before using these values (such as EC2, with requires the tags to unset to be in the form `[{'Key': key1}, {'Key': key2}]`)." -msgstr "この関数は、boto3 の「add_tags」関数および「remove_tags」関数を使用する場合に役に立ちます。この関数を呼び出す前に、必ず他のヘルパー関数 `boto3_tag_list_to_ansible_dict` を使用して、適切なタグのディクショナリーを取得してください。AWS の API は統一されていないため (たとえば、EC2 と Lambda は異なる)、一部 (Lambda) では修正なしで動作しますが、他ではこれらの値を使用する前に修正が必要な場合があります(EC2 では、設定解除するタグを `[{'Key': key1}, {'Key': key2}]` の形式にする必要があるなど)。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:619 -msgid "Integration Tests for AWS Modules" -msgstr "AWS モジュールの統合テスト" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:621 -msgid "All new AWS modules should include integration tests to ensure that any changes in AWS APIs that affect the module are detected. At a minimum this should cover the key API calls and check the documented return values are present in the module result." -msgstr "すべての新規 AWS モジュールには、モジュールに影響する AWS API の変更が検出されるように、統合テストを含める必要があります。最小値はキー API 呼び出しに対応し、文書化された戻り値がモジュールの結果に存在するようにする必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:625 -msgid "For general information on running the integration tests see the :ref:`Integration Tests page of the Module Development Guide `, especially the section on configuration for cloud tests." -msgstr "統合テストの実行に関する一般的な情報は、:ref:`モジュール開発ガイドの統合テストページ ` ページ (特に、クラウドテスト設定のセクション) を参照してください。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:628 -msgid "The integration tests for your module should be added in `test/integration/targets/MODULE_NAME`." -msgstr "モジュールの統合テストは、`test/integration/targets/MODULE_NAME` に追加する必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:630 -msgid "You must also have a aliases file in `test/integration/targets/MODULE_NAME/aliases`. This file serves two purposes. First indicates it's in an AWS test causing the test framework to make AWS credentials available during the test run. Second putting the test in a test group causing it to be run in the continuous integration build." -msgstr "また、`test/integration/targets/MODULE_NAME/aliases` にはエイリアスファイルが必要です。このファイルには 2 つの目的があります。最初に、それが AWS テストにあり、テストフレームワークがテスト実行中に AWS 認証情報を利用できるようにしていることを示します。次に、テストをテストグループに入れて、継続的インテグレーションビルドで実行します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:635 -msgid "Tests for new modules should be added to the same group as existing AWS tests. In general just copy an existing aliases file such as the `aws_s3 tests aliases file `_." -msgstr "新規モジュールのテストは、既存の AWS テストと同じグループに追加する必要があります。一般に、`aws_s3 テストエイリアスファイル `_ のような既存のエイリアスファイルをコピーするだけです。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:639 -msgid "AWS Credentials for Integration Tests" -msgstr "統合テストの AWS 認証情報" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:641 -msgid "The testing framework handles running the test with appropriate AWS credentials, these are made available to your test in the following variables:" -msgstr "テストフレームワークは、適切な AWS 認証情報を使用したテストの実行を処理します。この認証情報は、次の変数で、テストに利用できます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:644 -msgid "`aws_region`" -msgstr "`aws_region`" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:645 -msgid "`aws_access_key`" -msgstr "`aws_access_key`" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:646 -msgid "`aws_secret_key`" -msgstr "`aws_secret_key`" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:647 -msgid "`security_token`" -msgstr "`security_token`" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:649 -msgid "So all invocations of AWS modules in the test should set these parameters. To avoid duplicating these for every call, it's preferable to use :ref:`module_defaults `. For example:" -msgstr "したがって、テストで AWS モジュールを呼び出す場合はすべて、これらのパラメーターを設定する必要があります。呼び出しごとにこれらが重複しないようにするには、:ref:`module_defaults ` を使用することが推奨されます。以下に例を示します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:673 -msgid "AWS Permissions for Integration Tests" -msgstr "統合テスト用の AWS パーミッション" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:675 -msgid "As explained in the :ref:`Integration Test guide ` there are defined IAM policies in `mattclay/aws-terminator `_ that contain the necessary permissions to run the AWS integration test." -msgstr ":ref:`Integration Test guide ` で説明されているように、AWS 統合テストを実行するために必要な権限が含まれる `mattclay/aws-terminator `_ で定義された IAM ポリシーがあります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:679 -msgid "If your module interacts with a new service or otherwise requires new permissions, tests will fail when you submit a pull request and the `Ansibullbot `_ will tag your PR as needing revision. We do not automatically grant additional permissions to the roles used by the continuous integration builds. You will need to raise a Pull Request against `mattclay/aws-terminator `_ to add them." -msgstr "モジュールが新しいサービスとやり取りする場合、または別の方法で新しいパーミッションが必要な場合は、プル要求を送信すると、テストは失敗します。`Ansibullbot `_ は、PR に修正が必要なタグを付けます。継続的インテグレーションビルドで使用されるロールに追加のパーミッションを自動的に付与することはありません。それを追加するには、`mattclay/aws-terminator `_ に対してプル要求を発行する必要があります、それらを追加します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:684 -msgid "If your PR has test failures, check carefully to be certain the failure is only due to the missing permissions. If you've ruled out other sources of failure, add a comment with the `ready_for_review` tag and explain that it's due to missing permissions." -msgstr "PR にテストの失敗がある場合は、失敗の原因がパーミッションの欠落のみであることをしっかりと確認してください。他の失敗の原因を除外した場合は、`ready_for_review` タグを使用してコメントを追加して、権限がないことが原因であることを説明します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:687 -msgid "Your pull request cannot be merged until the tests are passing. If your pull request is failing due to missing permissions, you must collect the minimum IAM permissions required to run the tests." -msgstr "テストに合格するまでプル要求がマージできません。パーミッションがないためにプル要求が失敗すると、テストの実行に必要な最低限の IAM パーミッションを収集する必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:691 -msgid "There are two ways to figure out which IAM permissions you need for your PR to pass:" -msgstr "PR に合格するために必要な IAM パーミッションを確認する場合は、以下の 2 つの方法があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:693 -msgid "Start with the most permissive IAM policy, run the tests to collect information about which resources your tests actually use, then construct a policy based on that output. This approach only works on modules that use `AnsibleAWSModule`." -msgstr "最も許容度の高い IAM ポリシーから始めて、テストを実行し、テストが実際に使用するリソースに関する情報を収集し、その出力に基づいてポリシーを構築します。このアプローチは、`AnsibleAWSModule` を使用するモジュールでのみ機能します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:694 -msgid "Start with the least permissive IAM policy, run the tests to discover a failure, add permissions for the resource that addresses that failure, then repeat. If your module uses `AnsibleModule` instead of `AnsibleAWSModule`, you must use this approach." -msgstr "最も許容度の低い IAM ポリシーから開始し、テストを実行して障害を検出し、その障害に対処するリソースのパーミッションを追加してから、繰り返します。モジュールが使用する場合は、`AnsibleAWSModule` の代わりに `AnsibleModule` を使用する場合は、このアプローチを使用する必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:696 -msgid "To start with the most permissive IAM policy:" -msgstr "最も許容度の高い IAM ポリシーを使用するには、以下を実行します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:698 -msgid "`Create an IAM policy `_ that allows all actions (set ``Action`` and ``Resource`` to ``*```)." -msgstr "すべてのアクションを許可する `IAM ポリシーを作成 `_ します (``Action`` および ``Resource`` を ``*``' に設定)。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:699 -msgid "Run your tests locally with this policy. On AnsibleAWSModule-based modules, the ``debug_botocore_endpoint_logs`` option is automatically set to ``yes``, so you should see a list of AWS ACTIONS after the PLAY RECAP showing all the permissions used. If your tests use a boto/AnsibleModule module, you must start with the least permissive policy (see below)." -msgstr "このポリシーを使用して、ローカルでテストを実行します。AnsibleAWSModule ベースのモジュールでは、``debug_botocore_endpoint_logs`` オプションが自動的に ``yes`` に設定されます。したがって、PLAY RECAP の後に、使用されているすべてのパーミッションを示す AWSACTIONS のリストが表示されます。テストで boto/AnsibleModule モジュールを使用する場合は、最も許容度の低いポリシーから開始する必要があります (以下を参照)。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:700 -msgid "Modify your policy to allow only the actions your tests use. Restrict account, region, and prefix where possible. Wait a few minutes for your policy to update." -msgstr "テストで使用するアクションのみを許可するようにポリシーを変更します。可能な場合は、アカウント、地域、プレフィックスを制限してください。ポリシーが更新されるまで数分待ちます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:701 -msgid "Run the tests again with a user or role that allows only the new policy." -msgstr "新規ポリシーのみを許可するユーザーまたはロールでテストを再実行します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:702 -msgid "If the tests fail, troubleshoot (see tips below), modify the policy, run the tests again, and repeat the process until the tests pass with a restrictive policy." -msgstr "テストに失敗し、トラブルシューティング (以下のヒントを参照) を行い、ポリシーを変更し、テストを再実行し、制限的なポリシーでテストに合格するまでプロセスを繰り返します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:703 -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:720 -msgid "Open a pull request proposing the minimum required policy to the `CI policies `_." -msgstr "`CI policies `_ に対して最低限必要なポリシーを提案するプル要求を開きます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:705 -msgid "To start from the least permissive IAM policy:" -msgstr "最も許容度の低い IAM ポリシーから開始するには、以下を実行します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:707 -msgid "Run the integration tests locally with no IAM permissions." -msgstr "IAM パーミッションを持たないローカルの統合テストを実行します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:715 -msgid "Examine the error when the tests reach a failure." -msgstr "テストが失敗した場合はエラーを確認します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:709 -msgid "If the error message indicates the action used in the request, add the action to your policy." -msgstr "エラーメッセージがリクエストで使用されるアクションを示す場合は、アクションをポリシーに追加します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:711 -msgid "If the error message does not indicate the action used in the request:" -msgstr "エラーメッセージがリクエストで使用されるアクションを示していない場合は、以下を行います。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:711 -msgid "Usually the action is a CamelCase version of the method name - for example, for an ec2 client the method `describe_security_groups` correlates to the action `ec2:DescribeSecurityGroups`." -msgstr "通常、アクションはメソッド名の CamelCase バージョンです。たとえば、ec2 クライアントの場合、`describe_security_groups` メソッドはアクション `ec2:DescribeSecurityGroups` に相関します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:712 -msgid "Refer to the documentation to identify the action." -msgstr "アクションを特定するには、ドキュメントを参照してください。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:713 -msgid "If the error message indicates the resource ARN used in the request, limit the action to that resource." -msgstr "エラーメッセージが要求で使用されるリソース ARN を示す場合は、アクションをそのリソースに制限します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:715 -msgid "If the error message does not indicate the resource ARN used:" -msgstr "エラーメッセージに、使用されたリソース ARN が示されない場合は、以下を行います。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:715 -msgid "Determine if the action can be restricted to a resource by examining the documentation." -msgstr "ドキュメントを参照して、アクションをリソースに制限できるかどうかを判断します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:716 -msgid "If the action can be restricted, use the documentation to construct the ARN and add it to the policy." -msgstr "アクションが制限されている場合は、ドキュメントを使用して ARN を構築し、ポリシーに追加します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:717 -msgid "Add the action or resource that caused the failure to `an IAM policy `_. Wait a few minutes for your policy to update." -msgstr "`IAM ポリシー `_ の失敗の原因となったアクションまたはリソースを追加します。ポリシーが更新まで数分待ちます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:718 -msgid "Run the tests again with this policy attached to your user or role." -msgstr "ユーザーまたはロールにこのポリシーを割り当てテストを再実行します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:719 -msgid "If the tests still fail at the same place with the same error you will need to troubleshoot (see tips below). If the first test passes, repeat steps 2 and 3 for the next error. Repeat the process until the tests pass with a restrictive policy." -msgstr "それでも同じ場所で同じエラーでテストが失敗する場合はは、トラブルシューティングを行う必要があります (以下のヒントを参照)。最初のテストに合格した場合は、次のエラーに対して手順 2 と 3 を繰り返します。制限付きポリシーでテストに合格するまで、このプロセスを繰り返します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:723 -msgid "Troubleshooting IAM policies" -msgstr "IAM ポリシーのトラブルシューティング" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:725 -msgid "When you make changes to a policy, wait a few minutes for the policy to update before re-running the tests." -msgstr "ポリシーに変更を加えたら、ポリシーが更新されるまで数分待ってからテストを再実行します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:726 -msgid "Use the `policy simulator `_ to verify that each action (limited by resource when applicable) in your policy is allowed." -msgstr "`ポリシーシミュレーター `_ を使用して、ポリシー内の (該当する場合はリソースによって制限されている) が許可されていることを確認します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:727 -msgid "If you're restricting actions to certain resources, replace resources temporarily with `*`. If the tests pass with wildcard resources, there is a problem with the resource definition in your policy." -msgstr "特定のリソースにアクションを制限する場合は、リソースを一時的に `*` に置き換えます。ワイルドカードリソースでテストに合格した場合は、ポリシーのリソース定義に問題があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:728 -msgid "If the initial troubleshooting above doesn't provide any more insight, AWS may be using additional undisclosed resources and actions." -msgstr "上記の最初のトラブルシューティングでより多くの洞察が得られない場合、AWS は追加の未公開のリソースおよびアクションを使用している可能性があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:729 -msgid "Examine the AWS FullAccess policy for the service for clues." -msgstr "手がかりについては、サービスの AWS FullAccess ポリシーを調べます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:730 -msgid "Re-read the AWS documentation, especially the list of `Actions, Resources and Condition Keys `_ for the various AWS services." -msgstr "各種の AWS サービスの `Actions, Resources and Condition Keys `_ の一覧など、AWS ドキュメントを再度読みます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:731 -msgid "Look at the `cloudonaut `_ documentation as a troubleshooting cross-reference." -msgstr "トラブルシューティングの相互参照として `cloudonaut `_ ドキュメントをご覧ください。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:732 -msgid "Use a search engine." -msgstr "検索エンジンを使用します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:733 -msgid "Ask in the Ansible IRC channel #ansible-aws (on freenode IRC)." -msgstr "Freenode IRC の Ansible IRC チャンネル #ansible-aws に問い合わせます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:736 -msgid "Unsupported Integration tests" -msgstr "サポートされないインテグレーションのテスト" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:738 -msgid "There are a limited number of reasons why it may not be practical to run integration tests for a module within CI. Where these apply you should add the keyword `unsupported` to the aliases file in `test/integration/targets/MODULE_NAME/aliases`." -msgstr "CI 内のモジュールの統合テストを実行する場合には、いくつかの理由が限定されている理由があります。これらの理由については、キーワード `unsupported` を `test/integration/targets/MODULE_NAME/aliases` のエイリアスファイルに追加する必要があります。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:742 -msgid "Some cases where tests should be marked as unsupported: 1) The tests take longer than 10 or 15 minutes to complete 2) The tests create expensive resources 3) The tests create inline policies 4) The tests require the existence of external resources 5) The tests manage Account level security policies such as the password policy or AWS Organizations." -msgstr "テストがサポート対象外としてマークされる必要がある場合があります。1) テストが完了するまで 10 分または 15 分以上かかります。2) テストにより、高価なリソースが作成されます。3) テストにより、インラインポリシーが作成されます。4) テストに外部リソースの存在が必要になります。5) テストは、パスワードポリシーや AWS 組織などのアカウントレベルのセキュリティポリシーを管理します。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:749 -msgid "Where one of these reasons apply you should open a pull request proposing the minimum required policy to the `unsupported test policies `_." -msgstr "上記の理由の 1 つは、`サポートされないテストポリシー `_ に対して最低限必要なポリシーを提案するプル要求を開きます。" - -#: ../../rst/dev_guide/platforms/aws_guidelines.rst:752 -msgid "Unsupported integration tests will not be automatically run by CI. However, the necessary policies should be available so that the tests can be manually run by someone performing a PR review or writing a patch." -msgstr "サポート対象外の統合テストは CI によって自動的に実行されませんが、必要なポリシーを利用すると、PR レビューまたはパッチの作成を実行してテストを手動で実行できるようにする必要があります。" - -#: ../../rst/dev_guide/platforms/openstack_guidelines.rst:4 -msgid "OpenStack Ansible Modules" -msgstr "OpenStack Ansible モジュール" - -#: ../../rst/dev_guide/platforms/openstack_guidelines.rst:6 -msgid "Please see the `OpenStack guidelines `_, for further information." -msgstr "詳細は、`OpenStack ガイドライン `_ を参照してください。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:4 -msgid "oVirt Ansible Modules" -msgstr "oVirt Ansible モジュール" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:6 -msgid "The set of modules for interacting with oVirt/RHV are currently part of the community.general collection (on `Galaxy `_, source code `repository `_). This document serves as developer coding guidelines for creating oVirt/RHV modules." -msgstr "oVirt/RHV との対話に使用するモジュールセットは、現在 community.general コレクション (`Galaxy `_ ではソースコード `repository `_) に含まれます。このドキュメントは、oVirt/RHV モジュールを作成するための開発者コーディングのガイドラインとして機能します。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:12 -#: ../../rst/dev_guide/testing_validate-modules.rst:93 -#: ../../rst/dev_guide/testing_validate-modules.rst:96 -#: ../../rst/dev_guide/testing_validate-modules.rst:108 -#: ../../rst/dev_guide/testing_validate-modules.rst:135 -msgid "Naming" -msgstr "命名規則" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:14 -msgid "All modules should start with an ``ovirt_`` prefix." -msgstr "すべてのモジュールは、``ovirt_`` 接頭辞で開始する必要があります。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:15 -msgid "All modules should be named after the resource it manages in singular form." -msgstr "すべてのモジュールは、管理するリソースにちなんで単数形で名前を付ける必要があります。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:17 -msgid "All modules that gather information should have a ``_info`` suffix." -msgstr "情報を収集するすべてのモジュールには、``_info`` 構文があります。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:21 -msgid "Interface" -msgstr "インターフェース" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:23 -msgid "Every module should return the ID of the resource it manages." -msgstr "すべてのモジュールは、管理するリソースの ID を返す必要があります。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:24 -msgid "Every module should return the dictionary of the resource it manages." -msgstr "すべてのモジュールは、管理するリソースのディレクトリーを返す必要があります。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:25 -msgid "Never change the name of the parameter, as we guarantee backward compatibility. Use aliases instead." -msgstr "後方互換性を保証するため、パラメーターの名前は変更しないでください。代わりにエイリアスを使用してください。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:27 -msgid "If a parameter can't achieve idempotency for any reason, please document it." -msgstr "パラメーターが何らかの理由で冪等性を実現できない場合は、それを文書化してください。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:31 -msgid "Interoperability" -msgstr "相互運用性" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:33 -msgid "All modules should work against all minor versions of version 4 of the API. Version 3 of the API is not supported." -msgstr "すべてのモジュールは API のバージョン 4 のすべてのマイナーバージョンに対して動作します。API のバージョン 3 はサポート対象外です。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:37 -msgid "Libraries" -msgstr "ライブラリー" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:39 -msgid "All modules should use ``ovirt_full_argument_spec`` or ``ovirt_info_full_argument_spec`` to pick up the standard input (such as auth and ``fetch_nested``)." -msgstr "すべてのモジュールは ``ovirt_full_argument_spec`` または ``ovirt_info_full_argument_spec`` を使用して、標準入力 (認証、``fetch_nested`` など) にする必要があります。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:42 -msgid "All modules should use ``extends_documentation_fragment``: ovirt to go along with ``ovirt_full_argument_spec``." -msgstr "すべてのモジュールは、``ovirt_full_argument_spec`` に従うために ``extends_documentation_fragment``: ovirt を使用する必要があります。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:44 -msgid "All info modules should use ``extends_documentation_fragment``: ``ovirt_info`` to go along with ``ovirt_info_full_argument_spec``." -msgstr "すべての info モジュールは、``ovirt_info_full_argument_spec`` に従うために ``extends_documentation_fragment``: ``ovirt_info`` を使用する必要があります。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:46 -msgid "Functions that are common to all modules should be implemented in the ``module_utils/ovirt.py`` file, so they can be reused." -msgstr "すべてのモジュールに共通する関数は、``module_utils/ovirt.py`` ファイルに実装されているため、再利用できます。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:48 -msgid "Python SDK version 4 must be used." -msgstr "Python SDK バージョン 4 を使用する必要があります。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:51 -msgid "New module development" -msgstr "新しいモジュール開発" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:53 -msgid "Please read :ref:`developing_modules`, first to know what common properties, functions and features every module must have." -msgstr "「:ref:`developing_modules`」をお読みください。最初に、すべてのモジュールに必要な共通のプロパティー、関数、および機能を確認します。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:57 -msgid "In order to achieve idempotency of oVirt entity attributes, a helper class was created. The first thing you need to do is to extend this class and override a few methods:" -msgstr "oVirt エンティティー属性のべき等性を実現するには、ヘルパークラスが作成されました。まず、このクラスを拡張し、いくつかのメソッドを上書きする必要があります。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:99 -msgid "The code above handle the check if the entity should be updated, so we don't update the entity if not needed and also it construct the needed entity of the SDK." -msgstr "上記のコードは、エンティティーを更新すべきかどうかのチェックを処理するため、必要でない場合はエンティティーを更新せず、SDK に必要なエンティティーを構築します。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:176 -msgid "If your module must support action handling (for example, virtual machine start) you must ensure that you handle the states of the virtual machine correctly, and document the behavior of the module:" -msgstr "モジュールがアクション処理 (例: 仮想マシンの開始) をサポートする必要がある場合は、仮想マシンの状態を正しく処理し、モジュールの動作を文書化する必要があります。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:204 -msgid "As you can see from the preceding example, the ``action`` method accepts the ``action_condition`` and ``wait_condition``, which are methods which accept the virtual machine object as a parameter, so you can check whether the virtual machine is in a proper state before the action. The rest of the parameters are for the ``start`` action. You may also handle pre- or post- action tasks by defining ``pre_action`` and ``post_action`` parameters." -msgstr "前述の例で分かるように、``action`` メソッドは ``action_condition`` および ``wait_condition`` (仮想マシンオブジェクトをパラメーターとして許可するメソッド) を受け入れます。そのため、仮想マシンがアクションの前に適切な状態にあるかどうかを確認できます。残りのパラメーターは ``start`` アクション用です。``pre_action`` パラメーターおよび ``post_action`` パラメーターを定義して、事前または後続のアクションのタスクを処理することもできます。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:213 -msgid "Testing" -msgstr "テスト" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:215 -msgid "Integration testing is currently done in oVirt's CI system `on Jenkins `__ and `on GitHub `__." -msgstr "統合テストは、現在、__ と `GitHub `__ の oVirt's CI システム で行われています。" - -#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:219 -msgid "Please consider using these integration tests if you create a new module or add a new feature to an existing module." -msgstr "新しいモジュールを作成する場合、または既存のモジュールに新しい機能を追加する場合は、これらの統合テストの使用を検討してください。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:5 -msgid "Guidelines for VMware module development" -msgstr "VMware モジュール開発のガイドライン" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:7 -msgid "The Ansible VMware collection (on `Galaxy `_, source code `repository `_) is maintained by the VMware Working Group. For more information see the `team community page `_." -msgstr "詳細は、Ansible VMware コレクション (`Galaxy `_ で、ソースコード `repository `_) は VMware ワーキンググループにより維持されます。詳細は `team community page `_ を参照してください。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:13 -msgid "Testing with govcsim" -msgstr "govcsim を使用したテスト" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:15 -msgid "Most of the existing modules are covered by functional tests. The tests are located `here `_." -msgstr "既存のモジュールのほとんどは、機能テストで対応しています。テストは、`ここ `_ に置かれます。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:17 -msgid "By default, the tests run against a vCenter API simulator called `govcsim `_. ``ansible-test`` will automatically pull a `govcsim container `_ and use it to set-up the test environment." -msgstr "デフォルトでは、テストは、`govcsim `_ という名前の vCenter API シミュレーターに対して実行されます。``ansible-test`` は、`govcsim コンテナー `_ を自動的にプルし、これを使用してテスト環境を設定します。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:19 -msgid "You can trigger the test of a module manually with the ``ansible-test`` command. For example, to trigger ``vcenter_folder`` tests:" -msgstr "``ansible-test`` コマンドを使用して、モジュールのテストを手動でトリガーできます。たとえば、``vcenter_folder`` テストを開始するには、以下を行います。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:26 -msgid "``govcsim`` is handy because it is much faster than a regular test environment. However, ``govcsim`` does not support all the ESXi or vCenter features." -msgstr "``govcsim`` は、通常のテスト環境よりもはるかに高速ですが、``govcsim`` は ESXi 機能または vCenter 機能をすべてサポートしません。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:31 -msgid "Do not confuse ``govcsim`` with ``vcsim``. ``vcsim`` is an older and outdated version of vCenter simulator, whereas ``govcsim`` is new and written in Go language." -msgstr "``govcsim`` と ``vcsim`` を混同しないでください。``vcsim`` は、古いバージョンの vCenterシミュレーターですが、``govcsim`` は新しく、Go 言語で書かれています" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:34 -msgid "Testing with your own infrastructure" -msgstr "独自のインフラストラクチャーでのテスト" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:36 -msgid "You can also target a regular VMware environment. This paragraph explains step by step how you can run the test-suite yourself." -msgstr "通常の VMware 環境を対象とすることもできます。この段落では、テストスイートを自分で実行する方法について順を追って説明します。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:39 -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:23 -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:37 -#: ../../rst/dev_guide/testing_running_locally.rst:18 -msgid "Requirements" -msgstr "要件" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:41 -msgid "2 ESXi hosts (6.5 or 6.7)" -msgstr "2 台の ESXi ホスト (6.5 または 6.7)" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:42 -msgid "with 2 NIC, the second ones should be available for the test" -msgstr "2 つの NIC (テスト用に 2 番目の NIC が利用可能)" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:43 -msgid "a VCSA host" -msgstr "VCSA ホスト" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:44 -msgid "a NFS server" -msgstr "NFS サーバー" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:47 -msgid "Python dependencies:" -msgstr "Python の依存関係:" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:46 -msgid "`pyvmomi `_" -msgstr "`pyvmomi `_" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:47 -msgid "`requests `_" -msgstr "`requests `_" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:49 -msgid "If you want to deploy your test environment in a hypervisor, both `VMware or Libvirt `_ works well." -msgstr "ハイパーバイザーにテスト環境をデプロイする場合は、`VMware または Libvirt ` の両方が正常に機能します。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:52 -msgid "NFS server configuration" -msgstr "NFS サーバーの設定" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:54 -msgid "Your NFS server must expose the following directory structure:" -msgstr "NFS サーバーでは、以下のディレクトリー構造を公開する必要があります。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:67 -msgid "On a Linux system, you can expose the directory over NFS with the following export file:" -msgstr "Linux システムでは、次のエクスポートファイルを使用して、NFS 経由でディレクトリーを公開できます。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:76 -msgid "With this configuration all the new files will be owned by the user with the UID and GID 1000/1000. Adjust the configuration to match your user's UID/GID." -msgstr "この設定では、UID 1000 および GID 1000 のユーザーが、新しいファイルをすべて所有します。ユーザーの UID および GID に合わせて設定を調整してください。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:79 -msgid "The service can be enabled with:" -msgstr "このサービスは以下で有効にできます。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:87 -msgid "Configure your installation" -msgstr "インストールの設定" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:89 -msgid "Prepare a configuration file that describes your set-up. The file should be called :file:`test/integration/cloud-config-vcenter.ini` and based on :file:`test/lib/ansible_test/config/cloud-config-vcenter.ini.template`. For instance, if you have deployed your lab with `vmware-on-libvirt `_:" -msgstr "セットアップを説明する構成ファイルを準備します。このファイルは :file:`test/integration/cloud-config-vcenter.ini` という名前し、:file:`test/lib/ansible_test/config/cloud-config-vcenter.ini.template` をベースにする必要があります。たとえば、`vmware-on-libvirt `_ でラボをデプロイした場合は以下のようになります。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:109 -msgid "Using an HTTP proxy" -msgstr "HTTP プロキシーの使用" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:110 -msgid "Hosting test infrastructure behind an HTTP proxy is supported. You can specify the location of the proxy server with the two extra keys:" -msgstr "HTTP プロキシーの背後にあるホスティングテストインフラストラクチャーがサポートされています。次の 2 つの追加キーを使用して、プロキシーサーバーの場所を指定できます。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:117 -msgid "In addition, you may need to adjust the variables of the following `var files `_ to match the configuration of your lab. If you use vmware-on-libvirt to prepare your lab, you do not have anything to change." -msgstr "さらに、ラボの構成に一致させるために、次の `var ファイル `_ の変数を調整しないといけない場合があります。vmware-on-libvirt を使用してラボを準備する場合は、変更することができません。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:120 -msgid "Run the test-suite" -msgstr "テストスイートの実行" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:122 -msgid "Once your configuration is ready, you can trigger a run with the following command:" -msgstr "設定の準備ができたら、以下のコマンドで実行をトリガーできます。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:129 -msgid "``vmware_host_firewall_manager`` is the name of the module to test." -msgstr "``vmware_host_firewall_manager`` は、テストするモジュールの名前です。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:131 -msgid "``vmware_guest`` is much larger than any other test role and is rather slow. You can enable or disable some of its test playbooks in `main.yml `_." -msgstr "``vmware_guest`` は、他のテストロールよりもはるかに大きく、速度もかなり遅くなります。`main.yml `_ でテスト Playbook の一部を有効または無効にできます。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:135 -msgid "Unit-test" -msgstr "ユニットテスト" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:137 -msgid "The VMware modules have limited unit-test coverage. You can run the test suite with the following commands:" -msgstr "VMware モジュールには、unit-test の範囲が限定されています。以下のコマンドを実行してテストスイートを実行できます。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:146 -msgid "Code style and best practice" -msgstr "コードスタイルおよびベストプラクティス" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:149 -msgid "datacenter argument with ESXi" -msgstr "ESXi での datacenter 引数" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:151 -msgid "The ``datacenter`` parameter should not use ``ha-datacenter`` by default. This is because the user may not realize that Ansible silently targets the wrong data center." -msgstr "``datacenter`` パラメーターはデフォルトで ``ha-datacenter`` を使用しないでください。これは、Ansible が間違ったデータセンターをサイレントにターゲットにしていることにユーザーが気付かない可能性があるためです。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:155 -msgid "esxi_hostname should not be mandatory" -msgstr "esxi_hostname は必須ではない" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:157 -msgid "Depending upon the functionality provided by ESXi or vCenter, some modules can seamlessly work with both. In this case, ``esxi_hostname`` parameter should be optional." -msgstr "ESXi または vCenter が提供する機能に応じて、一部のモジュールは両方でシームレスに動作します。この場合、``esxi_hostname`` パラメーターは任意である必要があります。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:173 -msgid "Example should use the fully qualified collection name (FQCN)" -msgstr "例では、完全修飾コレクション名 (FQCN) を使用する必要があります" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:175 -msgid "Use FQCN for examples within module documentation. For instance, you should use ``community.vmware.vmware_guest`` instead of just ``vmware_guest``." -msgstr "モジュールドキュメントの例としては、FQCN を使用してください。たとえば、``vmware_guest`` ではなく ``community.vmware.vmware_guest`` を使用する必要があります。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:178 -msgid "This way, the examples do not depend on the ``collections`` directive of the playbook." -msgstr "この方法では、Playbook の ``collections`` ディレクティブに依存しません。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:182 -msgid "Functional tests" -msgstr "機能テスト" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:185 -msgid "Writing new tests" -msgstr "新規テストの作成" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:187 -msgid "If you are writing a new collection of integration tests, there are a few VMware-specific things to note beyond the standard Ansible :ref:`integration testing` process." -msgstr "統合テストの新しいコレクションを作成している場合は、標準の Ansible の :ref:`統合テスト` プロセス以外に注意すべき VMware 固有の事項がいくつかあります。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:190 -msgid "The test-suite uses a set of common, pre-defined vars located `in prepare_vmware_tests `_ role. The resources defined there are automatically created by importing that role at the start of your test:" -msgstr "テストスイートは、`prepare_vmware_tests `_ ロールにある一般的な事前定義済みの変数のセットを使用します。ここに定義されたリソースは、テストの開始時にそのロールをインポートして自動的に作成されます。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:200 -msgid "This will give you a ready to use cluster, datacenter, datastores, folder, switch, dvswitch, ESXi hosts, and VMs." -msgstr "これにより、クラスター、データセンター、データストア、ディレクトリー、スイッチ、dvSwitch、ESXi ホスト、および仮想マシンを使用する準備が整います。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:203 -msgid "No need to create too much resources" -msgstr "リソースを過剰に作成する必要なし" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:205 -msgid "Most of the time, it's not necessary to use ``with_items`` to create multiple resources. By avoiding it, you speed up the test execution and you simplify the clean up afterwards." -msgstr "多くの場合、``with_items`` を使用して複数のリソースの作成を行う必要はありません。回避することで、テストの実行を迅速化して、後でクリーンアップを単純化できます。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:209 -msgid "VM names should be predictable" -msgstr "仮想マシン名は、名前で内容が予測できるものにする" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:211 -msgid "If you need to create a new VM during your test, you can use ``test_vm1``, ``test_vm2`` or ``test_vm3``. This way it will be automatically clean up for you." -msgstr "テスト中に新しい仮想マシンを作成する必要がある場合は、``test_vm1``、``test_vm2``、または ``test_vm3`` を使用できます。このように、自動的にクリーンアップされます。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:215 -msgid "Avoid the common boiler plate code in your test playbook" -msgstr "テスト Playbook で一般的なボイラールのコードを回避" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:217 -msgid "From Ansible 2.10, the test suite uses `modules_defaults`. This module allow us to preinitialize the following default keys of the VMware modules:" -msgstr "Ansible 2.10 以降では、テストスイートは `modules_defaults` を使用します。このモジュールにより、以下の VMware モジュールのデフォルトキーを事前に初期化できます。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:220 -msgid "hostname" -msgstr "hostname" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:221 -msgid "username" -msgstr "username" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:222 -msgid "password" -msgstr "password" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:223 -msgid "validate_certs" -msgstr "validate_certs" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:225 -msgid "For example, the following block:" -msgstr "たとえば、以下のブロックの場合:" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:239 -msgid "should be simplified to just:" -msgstr "以下を単純化する必要があります。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:251 -msgid "Typographic convention" -msgstr "表記規則" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:254 -msgid "Nomenclature" -msgstr "命名法" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:256 -msgid "We try to enforce the following rules in our documentation:" -msgstr "Ansible のドキュメントでは、次のルールを適用しています。" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:258 -msgid "VMware, not VMWare or vmware" -msgstr "VMware (VMWare または vmware ではありません)" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:259 -msgid "ESXi, not esxi or ESXI" -msgstr "ESXi (esxi または ESXI ではありません)" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:260 -msgid "vCenter, not vcenter or VCenter" -msgstr "vCenter (vcenter または VCenter ではありません)" - -#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:262 -msgid "We also refer to vcsim's Go implementation with ``govcsim``. This to avoid any confusion with the outdated implementation." -msgstr "また、``govcsim`` を使用した vcsim の Go 実装も参照します。これは、古い実装との混乱を回避するためのものです。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:5 -msgid "Guidelines for VMware REST module development" -msgstr "VMware REST モジュール開発のガイドライン" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:7 -msgid "The Ansible VMware REST collection (on `Galaxy `_, source code `repository `_) is maintained by Red Hat and the community." -msgstr "Ansible VMware REST コレクション (`Galaxy `_ ではソースコード `repository `_) は、Red Hat とコミュニティーにより維持されます。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:13 -msgid "Contribution process" -msgstr "貢献プロセス" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:15 -msgid "The modules of the vmware_rest collection are autogenerated by another tool called `vmware_rest_code_generator `." -msgstr "vmware_rest コレクションのモジュールは、`vmware_rest_code_generator ` と呼ばれる別のツールにより自動生成されます。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:17 -msgid "If you would like to contribute a change, we would appreciate if you:" -msgstr "変更に貢献したい場合は、以下をご用意ください。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:19 -msgid "submit a Github Pull Request (PR) against the vmware_rest_code_generator project" -msgstr "vmware_rest_code_generator プロジェクトに対して Github Pull Request (PR) を送信します。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:20 -msgid "but also ensure the generated modules are compliant with our quality criteria." -msgstr "ただし、生成されたモジュールが品質基準に準拠していることを確認します。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:25 -msgid "You will need:" -msgstr "以下が必要になります。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:27 -msgid "Python 3.6 or greater" -msgstr "Python 3.6 以降" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:28 -msgid "the `tox ` command" -msgstr "`tox ` コマンド" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:32 -msgid "vmware_rest_code_generator" -msgstr "vmware_rest_code_generator" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:34 -msgid "Your contribution should follow the coding style of `Black `. To run the code formatter, just run:" -msgstr "貢献は、`Black ` のコーディングスタイルに従う必要があります。コードフォーマッターを実行するには、以下を実行します。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:41 -msgid "To regenerate the vmware_rest collection, you can use the following commands:" -msgstr "vmware_rest コレクションを再生成するには、以下のコマンドを使用できます。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:47 -msgid "If you also want to update the EXAMPLE section of the modules, run:" -msgstr "モジュールの EXAMPLE セクションも更新する場合は、以下を実行します。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:54 -msgid "Testing with ansible-test" -msgstr "ansible-test を使用したテスト" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:56 -msgid "All the modules are covered by a functional test. The tests are located in the :file:`tests/integration/targets/`." -msgstr "すべてのモジュールは、機能テストで対応しています。テストは、:file:`tests/integration/targets/` に置かれます。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:58 -msgid "To run the tests, you will need a vcenter instance and an ESXi." -msgstr "テストを実行するには、vcenter インスタンスと ESXi が必要です。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:61 -msgid "black code formatter" -msgstr "ブラックコードフォーマッター" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:63 -msgid "We follow the coding style of `Black `. You can run the code formatter with the following command." -msgstr "`Black ` のコーディングスタイルに準拠しています。以下のコマンドでコードフォーマッターを実行できます。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:72 -msgid "sanity tests" -msgstr "健全性テスト" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:74 -msgid "Here we use Python 3.8, the minimal version is 3.6." -msgstr "ここでは Python 3.8 を使用します。最小バージョンは 3.6 です。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:83 -msgid "integration tests" -msgstr "統合テスト" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:85 -msgid "These tests should be run against your test environment." -msgstr "これらのテストは、テスト環境に対して実行する必要があります。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:87 -msgid "..warning:: The test suite will delete all the existing DC from your test environment." -msgstr "..警告:: テストスイートは、テスト環境から既存の DC をすべて削除します。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:89 -msgid "First, prepare a configuration file, we call it :file:`/tmp/inventory-vmware_rest` in this example:" -msgstr "まず設定ファイルを準備し、この例では :file:`/tmp/inventory-vmware_rest` とします。" - -#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:106 -msgid "To run the tests, use the following command. You may want to adjust the Python version." -msgstr "テストを実行するには、以下のコマンドを使用して Python バージョンを調整できます。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:4 -msgid "Basic rules" -msgstr "基本ルール" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:9 -msgid "Use standard American English" -msgstr "標準的なアメリカ英語を使用する" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:10 -msgid "Ansible uses Standard American English. Watch for common words that are spelled differently in American English (color vs colour, organize vs organise, and so on)." -msgstr "Ansible は標準的なアメリカ英語を使用します。アメリカ英語では綴りが異なる一般的な単語に注意してください (color と colour、organize と organise など)。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:13 -msgid "Write for a global audience" -msgstr "世界中の読者に向けて書く" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:14 -msgid "Everything you say should be understandable by people of different backgrounds and cultures. Avoid idioms and regionalism and maintain a neutral tone that cannot be misinterpreted. Avoid attempts at humor." -msgstr "記載する内容は、生い立ちや文化が違っても理解できるものでなければなりません。イディオムや地域主義は使用せず、誤って解釈されない中立的な表現を使用します。ユーモアな表現は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:17 -msgid "Follow naming conventions" -msgstr "命名規則に従う" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:18 -msgid "Always follow naming conventions and trademarks." -msgstr "命名規則と商標には常に従ってください。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:23 -msgid "Use clear sentence structure" -msgstr "明確な文構造を使用する" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:24 -msgid "Clear sentence structure means:" -msgstr "明確な文法構造とは、以下のようになります。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:26 -msgid "Start with the important information first." -msgstr "重要な情報を最初に示します。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:27 -msgid "Avoid padding/adding extra words that make the sentence harder to understand." -msgstr "文章の理解が難しくなるような単語は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:28 -msgid "Keep it short - Longer sentences are harder to understand." -msgstr "文章は短くします。文章が長くなればなるほど、理解が難しくなります。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:30 -msgid "Some examples of improving sentences:" -msgstr "たとえば、以下のように改善できます。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:33 -#: ../../rst/dev_guide/style_guide/basic_rules.rst:39 -msgid "Bad:" -msgstr "問題がある文章: " - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:33 -msgid "The unwise walking about upon the area near the cliff edge may result in a dangerous fall and therefore it is recommended that one remains a safe distance to maintain personal safety." -msgstr "The unwise walking about upon the area near the cliff edge may result in a dangerous fall and therefore it is recommended that one remains a safe distance to maintain personal safety. (崖の端近くを歩き回ると、下に落ちる危険があります。安全を維持するために安全な距離を保つことをお勧めします。)" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:36 -#: ../../rst/dev_guide/style_guide/basic_rules.rst:42 -msgid "Better:" -msgstr "改善例: " - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:36 -msgid "Danger! Stay away from the cliff." -msgstr "Danger! Stay away from the cliff. (危険です。崖から離れてください。)" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:39 -msgid "Furthermore, large volumes of water are also required for the process of extraction." -msgstr "Furthermore, large volumes of water are also required for the process of extraction. (また、抜歯のプロセスには、水が大量に必要になります。)" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:42 -msgid "Extraction also requires large volumes of water." -msgstr "Extraction also requires large volumes of water. (抜歯には、大量の水が必要です。)" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:45 -msgid "Avoid verbosity" -msgstr "冗長を避ける" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:46 -msgid "Write short, succinct sentences. Avoid terms like:" -msgstr "短く簡潔な文章を書きます。以下のような用語は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:48 -msgid "\"...as has been said before,\"" -msgstr "「...as has been said before」" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:49 -msgid "\"..each and every,\"" -msgstr "「...each and every」" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:50 -msgid "\"...point in time,\"" -msgstr "「...point in time」" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:51 -msgid "\"...in order to,\"" -msgstr "「...in order to」" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:54 -msgid "Highlight menu items and commands" -msgstr "メニュー項目およびコマンドを強調表示する" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:55 -msgid "When documenting menus or commands, it helps to **bold** what is important." -msgstr "メニューまたはコマンドを文書化する場合は、重要な内容を **太字** にすると役立ちます。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:57 -msgid "For menu procedures, bold the menu names, button names, and so on to help the user find them on the GUI:" -msgstr "メニュー手順では、メニュー名、ボタン名などを太字にして、GUI でその文字を見つけられるようにします。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:59 -msgid "On the **File** menu, click **Open**." -msgstr "**ファイル** メニューで、**開く** をクリックします。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:60 -msgid "Type a name in the **User Name** field." -msgstr "**ユーザー名** フィールドに名前を入力します。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:61 -msgid "In the **Open** dialog box, click **Save**." -msgstr "**開く** ダイアログボックスで、**保存** をクリックします。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:62 -msgid "On the toolbar, click the **Open File** icon." -msgstr "ツールバーで、**ファイルを開く** アイコンをクリックします。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:64 -msgid "For code or command snippets, use the RST `code-block directive `_::" -msgstr "code または command スニペットの場合は、RST の `code-block ディレクティブ `_ を使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:3 -msgid "Grammar and Punctuation" -msgstr "文法および句読点" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:6 -msgid "Common Styles and Usage, and Common Mistakes" -msgstr "一般的なスタイルおよび使用方法、ならびに一般的な間違い" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:9 -#: ../../rst/dev_guide/testing/sanity/ignores.rst:50 -msgid "Ansible" -msgstr "Ansible" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:10 -msgid "Write \"Ansible.\" Not \"Ansible, Inc.\" or \"AnsibleWorks The only exceptions to this rule are when we're writing legal or financial statements." -msgstr "「Ansible, Inc.」または「AnsibleWorks」とせず、「Ansible」としてください。このルールの唯一の例外は、法的文書または財務諸表を作成する場合です。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:12 -msgid "Never use the logotype by itself in body text. Always keep the same font you are using the rest of the sentence." -msgstr "ロゴマークは、本文で使用しないでください。その他の文章で使用しているフォントを常に使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:14 -msgid "A company is singular in the US. In other words, Ansible is an \"it,\" not a \"they.\"" -msgstr "米国では、会社は単数形で使用します。つまり、Ansible は、「they」ではなく「it」になります。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:18 -msgid "Capitalization" -msgstr "大文字" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:19 -msgid "If it's not a real product, service, or department at Ansible, don't capitalize it. Not even if it seems important. Capitalize only the first letter of the first word in headlines." -msgstr "Ansible の実際の製品、サービス、または部門ではない場合には、大文字にしないでください。見出しの最初の単語の最初の文字だけを大文字にします。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:22 -msgid "Colon" -msgstr "コロン" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:23 -msgid "A colon is generally used before a list or series: - The Triangle Area consists of three cities: Raleigh, Durham, and Chapel Hill." -msgstr "通常、コロンは、リストまたは一連の要素の前に使用されます。- The Triangle Area consists of three cities: Raleigh, Durham, and Chapel Hill." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:26 -msgid "But not if the list is a complement or object of an element in the sentence: - Before going on vacation, be sure to (1) set the alarm, (2) cancel the newspaper, and (3) ask a neighbor to collect your mail." -msgstr "ただし、リストが、文内の要素の補語または目的語の場合は、以下のようにします。Before going on vacation, be sure to (1) set the alarm, (2) cancel the newspaper, and (3) ask a neighbor to collect your mail." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:29 -msgid "Use a colon after \"as follows\" and \"the following\" if the related list comes immediately after: wedge The steps for changing directories are as follows:" -msgstr "直後に関連するリストを追加する場合は、「as follows」および「the following」(次のとおり) の後にコロンを使用します。The steps for changing directories are as follows:" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:32 -msgid "Open a terminal." -msgstr "Open a terminal." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:33 -msgid "Type cd..." -msgstr "Type cd..." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:35 -msgid "Use a colon to introduce a bullet list (or dash, or icon/symbol of your choice):" -msgstr "コロンを使用して、箇条書きリスト (ダッシュ、アイコンまたは記号を使用) 追加します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:37 -msgid "In the Properties dialog box, you'll find the following entries:" -msgstr "In the Properties dialog box, you'll find the following entries:" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:39 -msgid "Connection name" -msgstr "Connection name" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:40 -msgid "Count" -msgstr "Count" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:41 -msgid "Cost per item" -msgstr "Cost per item" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:45 -msgid "Commas" -msgstr "コンマ" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:46 -msgid "Use serial commas, the comma before the \"and\" in a series of three or more items:" -msgstr "3 つ以上の項目が続く場合は、「and」の前にコンマを使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:48 -msgid "\"Item 1, item 2, and item 3.\"" -msgstr "Item 1, item 2, and item 3." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:51 -msgid "It's easier to read that way and helps avoid confusion. The primary exception to this you will see is in PR, where it is traditional not to use serial commas because it is often the style of journalists." -msgstr "これにより読みやすくなり、混乱を避けることができます。これに対する主な例外は PR です。PR では、多くの場合ジャーナリスト向けのスタイルにより、このようなコンマは使用しません。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:53 -msgid "Commas are always important, considering the vast difference in meanings of the following two statements." -msgstr "次の 2 つの文章の意味が大きく異なることを考えると、コンマは常に重要です。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:55 -msgid "Let's eat, Grandma" -msgstr "Let's eat, Grandma" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:56 -msgid "Let's eat Grandma." -msgstr "Let's eat Grandma." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:58 -msgid "Correct punctuation could save Grandma's life." -msgstr "正しい句読点により、おばあさんの命を救うことができます。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:60 -msgid "If that does not convince you, maybe this will:" -msgstr "もしくは、以下の例をご覧ください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:66 -msgid "Contractions" -msgstr "縮約" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:67 -msgid "Do not use contractions in Ansible documents." -msgstr "Ansible ドキュメントでは、縮約は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:70 -msgid "Em dashes" -msgstr "エムダッシュ (－)" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:71 -msgid "When possible, use em-dashes with no space on either side. When full em-dashes aren't available, use double-dashes with no spaces on either side--like this." -msgstr "可能な場合は、両側にスペースを入れずにエムダッシュ (－) を使用します。エムダッシュ (－) が利用できない場合は、両側に空白を入れずに二重ダッシュを使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:73 -msgid "A pair of em dashes can be used in place of commas to enhance readability. Note, however, that dashes are always more emphatic than commas." -msgstr "読みやすくするために、コンマの代わりにエムダッシュをペアにして使用できます。ただし、ダッシュはコンマよりも常に強調されることに注意してください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:75 -msgid "A pair of em dashes can replace a pair of parentheses. Dashes are considered less formal than parentheses; they are also more intrusive. If you want to draw attention to the parenthetical content, use dashes. If you want to include the parenthetical content more subtly, use parentheses." -msgstr "エムダッシュのペアは、括弧のペアの代わりに使用することもできます。ダッシュは括弧よりも形式的ではないと見なされ、押しつけがましく感じることもあります。括弧内のコンテンツに注意を引きたい場合は、ダッシュを使用します。括弧内のコンテンツにあまり注意を引きたくない場合は、括弧を使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:78 -msgid "When dashes are used in place of parentheses, surrounding punctuation should be omitted. Compare the following examples." -msgstr "括弧の代わりにダッシュを使用する場合は、前後の句読点を省略してください。次の例を比較してください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:87 -msgid "When used in place of parentheses at the end of a sentence, only a single dash is used." -msgstr "文末に括弧の代わりに使用する場合は、ダッシュを 1 つだけに使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:97 -msgid "Exclamation points (!)" -msgstr "感嘆符 (!)" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:98 -msgid "Do not use them at the end of sentences. An exclamation point can be used when referring to a command, such as the bang (!) command." -msgstr "文末には使用しないでください。感嘆符は、bang (!) などのコマンドを参照する場合に使用できます。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:101 -msgid "Gender References" -msgstr "性別の参照" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:102 -msgid "Do not use gender-specific pronouns in documentation. It is far less awkward to read a sentence that uses \"they\" and \"their\" rather than \"he/she\" and \"his/hers.\"" -msgstr "ドキュメンテーションでは、性別固有の代名詞は使用しないでください。「he/she」や「his/hers」ではなく「they」および「their」を使用する方が適切です。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:104 -msgid "It is fine to use \"you\" when giving instructions and \"the user,\" \"new users,\" and so on. in more general explanations." -msgstr "指示を示す場合は「you」と使用し、より一般的な説明では「the user」、「new users」などを使用すると良いでしょう。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:106 -msgid "Never use \"one\" in place of \"you\" when writing technical documentation. Using \"one\" is far too formal." -msgstr "テクニカルドキュメントを作成する際は、「You」 の意味で「one」を使用しないでください。「one」を使用すると堅苦しくなります。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:108 -msgid "Never use \"we\" when writing. \"We\" aren't doing anything on the user side. Ansible's products are doing the work as requested by the user." -msgstr "書き込み時に「we」は使用しないでください。「We」は、ユーザー側では何も実行しません。Ansible の製品は、ユーザーの要求に応じて作業を行います。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:112 -msgid "Hyphen" -msgstr "ハイフン" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:113 -msgid "The hyphen's primary function is the formation of certain compound terms. Do not use a hyphen unless it serves a purpose. If a compound adjective cannot be misread or, as with many psychological terms, its meaning is established, a hyphen is not necessary." -msgstr "このハイフンの主な機能は、特定の複合用語の特徴です。目的が満たされない限り、ハイフンは使用しないでください。複合形容詞が間違って解釈されない場合、または多くの心理学用語と同じ様に、その意味が確立されている場合は、ハイフンが必要ありません。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:115 -msgid "Use hyphens to avoid ambiguity or confusion:" -msgstr "ハイフンは、あいまいさや混乱を避けるためにを使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:135 -msgid "In professionally printed material (particularly books, magazines, and newspapers), the hyphen is used to divide words between the end of one line and the beginning of the next. This allows for an evenly aligned right margin without highly variable (and distracting) word spacing." -msgstr "適切な編集が必要な出版物 (特に本、雑誌、新聞) では、単語が行をまたがる場合にハイフンを使用します。これにより、単語の間隔が大きく変わる (そして気が散る) ことなく、右マージンを均等に揃えることができます。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:139 -msgid "Lists" -msgstr "リスト" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:140 -msgid "Keep the structure of bulleted lists equivalent and consistent. If one bullet is a verb phrase, they should all be verb phrases. If one is a complete sentence, they should all be complete sentences, and so on." -msgstr "箇条書きの構造を同等かつ一貫性のあるものに保ちます。たとえば、1 つの箇条書きが動詞句である場合、それらはすべて動詞句である必要があります。1 つが完全な文である場合、それらはすべて完全な文である必要があります。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:142 -msgid "Capitalize the first word of each bullet. Unless it is obvious that it is just a list of items, such as a list of items like: * computer * monitor * keyboard * mouse" -msgstr "箇条書きでは、それぞれ最初の単語を大文字にします。次のような項目のリストなど、単に項目のリストであることが明らかである場合は除きます (* computer * monitor * keyboard * mouse)。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:148 -msgid "When the bulleted list appears within the context of other copy, (unless it's a straight list like the previous example) add periods, even if the bullets are sentence fragments. Part of the reason behind this is that each bullet is said to complete the original sentence." -msgstr "箇条書きに他の文章が含まれる場合は、(上の例のような単純なリストでない限り) 箇条書きが完全な文になっていなくてもピリオドを追加します。この理由の 1 つは、各箇条書きが元の文を完了すると言われているためです。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:150 -msgid "In some cases where the bullets are appearing independently, such as in a poster or a homepage promotion, they do not need periods." -msgstr "箇条書きがポスターやホームページのプロモーションなどのように独立して示される場合は、ピリオドは必要ありません。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:152 -msgid "When giving instructional steps, use numbered lists instead of bulleted lists." -msgstr "手順を説明するときは、箇条書きの代わりに番号付きリストを使用してください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:156 -msgid "Months and States" -msgstr "月および州" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:157 -msgid "Abbreviate months and states according to AP. Months are only abbreviated if they are used in conjunction with a day. Example: \"The President visited in January 1999.\" or \"The President visited Jan. 12.\"" -msgstr "AP に従って、月と州の名前を省略します。月は、日付と組み合わせて使用される場合に限り省略されます。たとえば、「The President visited in January 1999.」または「The President visited Jan. 12.」です。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:159 -msgid "Months: Jan., Feb., March, April, May, June, July, Aug., Sept., Nov., Dec." -msgstr "月: Jan.、Feb.、March、April、May、June、July、Aug.、Sept.、Nov.、Dec." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:161 -msgid "States: Ala., Ariz., Ark., Calif., Colo., Conn., Del., Fla., Ga., Ill., Ind., Kan., Ky., La., Md., Mass., Mich., Minn., Miss., Mo., Mont., Neb., Nev., NH, NJ, NM, NY, NC, ND, Okla., Ore., Pa., RI, SC, SD, Tenn., Vt., Va., Wash., W.Va., Wis., Wyo." -msgstr "州: Ala.、Ariz.、Ark.、Calif.、Colo.、Conn.、Del.、Fla.、Ga.、Ill.、Ind.、Kan.、Ky.、La.、Md.、Mass.、Mich.、Minn.、Miss.、Mo.、Mont.、Neb.、Nev.、NH、NJ、NM、NY、NC、ND、Okla.、Ore.、Pa.、RI、SC、SD、Tenn.、Vt.、Va.、Wash.、W.Va.、Wis.、Wyo." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:164 -msgid "Numbers" -msgstr "数字" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:165 -msgid "Numbers between one and nine are written out. 10 and above are numerals. The exception to this is writing \"4 million\" or \"4 GB.\" It's also acceptable to use numerals in tables and charts." -msgstr "1 から 9 までの数字が使用されます。10 以上の値は数字を使用します。「4 million」または「4 GB」などは例外となります。また、表やチャートでは数値を使用することもできます。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:168 -msgid "Phone Numbers" -msgstr "電話番号" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:170 -msgid "Phone number style: 1 (919) 555-0123 x002 and 1 888-GOTTEXT" -msgstr "電話番号の形式: 1 (919) 555-0123 x002 および 1 888-GOTTEXT" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:174 -msgid "Quotations (Using Quotation Marks and Writing Quotes)" -msgstr "引用 (引用符の使用と引用の記述)" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:175 -msgid "\"Place the punctuation inside the quotes,\" the editor said." -msgstr "\"Place the punctuation inside the quotes,\" the editor said." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:177 -msgid "Except in rare instances, use only \"said\" or \"says\" because anything else just gets in the way of the quote itself, and also tends to editorialize." -msgstr "ほとんどの場合は、「said」または「say」だけを使用してください。それ以外は、引用の邪魔になり、編集される傾向があるためです。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:180 -msgid "Place the name first right after the quote:" -msgstr "引用の直後に名前を追加します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:180 -msgid "\"I like to write first-person because I like to become the character I'm writing,\" Wally Lamb said." -msgstr "\"I like to write first-person because I like to become the character I'm writing,\" Wally Lamb said." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:184 -msgid "Not:" -msgstr "以下のようにはしないでください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:183 -msgid "\"I like to write first-person because I like to become the character I'm writing,\" said Wally Lamb." -msgstr "\"I like to write first-person because I like to become the character I'm writing,\" said Wally Lamb." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:187 -msgid "Semicolon" -msgstr "セミコロン" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:188 -msgid "Use a semicolon to separate items in a series if the items contain commas:" -msgstr "項目にコンマが含まれている場合は、セミコロンを使用して項目を区切ります。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:190 -msgid "Everyday I have coffee, toast, and fruit for breakfast; a salad for lunch; and a peanut butter sandwich, cookies, ice cream, and chocolate cake for dinner." -msgstr "Everyday I have coffee, toast, and fruit for breakfast; a salad for lunch; and a peanut butter sandwich, cookies, ice cream, and chocolate cake for dinner." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:192 -msgid "Use a semicolon before a conjunctive adverb (however, therefore, otherwise, namely, for example, and so on): - I think; therefore, I am." -msgstr "接続詞副詞 (however、therefore、otherwise、namely、for example) の前にセミコロンを使用します。「I think; therefore, I am.」のようにします。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:196 -msgid "Spacing after sentences" -msgstr "文の後のスペース" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:197 -msgid "Use only a single space after a sentence." -msgstr "文の後には、シングルスペースのみを使用してください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:200 -msgid "Time" -msgstr "時間" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:201 -msgid "Time of day is written as \"4 p.m.\"" -msgstr "時刻は「4 p.m」とします。" - -#: ../../rst/dev_guide/style_guide/index.rst:5 -msgid "Ansible style guide" -msgstr "Ansible スタイルガイド" - -#: ../../rst/dev_guide/style_guide/index.rst:7 -msgid "Welcome to the Ansible style guide! To create clear, concise, consistent, useful materials on docs.ansible.com, follow these guidelines:" -msgstr "Ansible スタイルガイドにようこそ! docs.ansible.com に、明確および簡潔で、一貫性のある有用なドキュメントを作成するために、以下のガイドラインが指定されています。" - -#: ../../rst/dev_guide/style_guide/index.rst:14 -msgid "Linguistic guidelines" -msgstr "言語のガイドライン" - -#: ../../rst/dev_guide/style_guide/index.rst:16 -msgid "We want the Ansible documentation to be:" -msgstr "Ansible ドキュメントでは、以下を目標にしています。" - -#: ../../rst/dev_guide/style_guide/index.rst:18 -msgid "clear" -msgstr "明確な" - -#: ../../rst/dev_guide/style_guide/index.rst:19 -msgid "direct" -msgstr "直接的な" - -#: ../../rst/dev_guide/style_guide/index.rst:20 -msgid "conversational" -msgstr "会話的な" - -#: ../../rst/dev_guide/style_guide/index.rst:21 -msgid "easy to translate" -msgstr "翻訳が容易な" - -#: ../../rst/dev_guide/style_guide/index.rst:23 -msgid "We want reading the docs to feel like having an experienced, friendly colleague explain how Ansible works." -msgstr "Ansible が提供するドキュメントは、経験豊富で友好的な同僚に Ansible の仕組みを説明してもらっていると感じられるようなものにすることを目標にしています。" - -#: ../../rst/dev_guide/style_guide/index.rst:27 -msgid "Stylistic cheat-sheet" -msgstr "文体の早見表" - -#: ../../rst/dev_guide/style_guide/index.rst:29 -msgid "This cheat-sheet illustrates a few rules that help achieve the \"Ansible tone\":" -msgstr "以下の早見表は、「Ansibleのトーン」を実現するのに役立つルールを示しています。" - -#: ../../rst/dev_guide/style_guide/index.rst:32 -msgid "Rule" -msgstr "**ルール**" - -#: ../../rst/dev_guide/style_guide/index.rst:32 -msgid "Good example" -msgstr "適切な例" - -#: ../../rst/dev_guide/style_guide/index.rst:32 -msgid "Bad example" -msgstr "不適切な例" - -#: ../../rst/dev_guide/style_guide/index.rst:34 -msgid "Use active voice" -msgstr "能動態を使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:34 -msgid "You can run a task by" -msgstr "You can run a task by (以下を使用してタスクを実行できます)" - -#: ../../rst/dev_guide/style_guide/index.rst:34 -msgid "A task can be run by" -msgstr "A task can be run by (タスクは、以下のように実行できます)" - -#: ../../rst/dev_guide/style_guide/index.rst:36 -msgid "Use the present tense" -msgstr "現在形の使用" - -#: ../../rst/dev_guide/style_guide/index.rst:36 -msgid "This command creates a" -msgstr "This command creates a (このコマンドにより...が作成されます。)" - -#: ../../rst/dev_guide/style_guide/index.rst:36 -msgid "This command will create a" -msgstr "This command will create a (このコマンドにより...が作成されます)" - -#: ../../rst/dev_guide/style_guide/index.rst:38 -msgid "Address the reader" -msgstr "読者に話すように書きます。" - -#: ../../rst/dev_guide/style_guide/index.rst:38 -msgid "As you expand your inventory" -msgstr "As you expand your inventory (インベントリーを展開します)" - -#: ../../rst/dev_guide/style_guide/index.rst:38 -msgid "When the number of managed nodes grows" -msgstr "When the number of managed nodes grows (管理ノードの数が増える場合)" - -#: ../../rst/dev_guide/style_guide/index.rst:40 -msgid "Use standard English" -msgstr "標準英語の使用" - -#: ../../rst/dev_guide/style_guide/index.rst:40 -msgid "Return to this page" -msgstr "Return to this page (このページに戻る)" - -#: ../../rst/dev_guide/style_guide/index.rst:40 -msgid "Hop back to this page" -msgstr "Hop back to this page (このページに戻る)" - -#: ../../rst/dev_guide/style_guide/index.rst:42 -msgid "Use American English" -msgstr "アメリカ英語の使用" - -#: ../../rst/dev_guide/style_guide/index.rst:42 -msgid "The color of the output" -msgstr "The color of the output (出力の色)" - -#: ../../rst/dev_guide/style_guide/index.rst:42 -msgid "The colour of the output" -msgstr "The colour of the output (出力の色)" - -#: ../../rst/dev_guide/style_guide/index.rst:46 -msgid "Header case" -msgstr "ヘッダーの書式" - -#: ../../rst/dev_guide/style_guide/index.rst:48 -msgid "Headers should be written in sentence case. For example, this section's title is ``Header case``, not ``Header Case`` or ``HEADER CASE``." -msgstr "ヘッダーは文で使用される書式で記述する必要があります。たとえば、``Header Case`` または ``HEADER CASE`` ではなく、``Header case`` です。" - -#: ../../rst/dev_guide/style_guide/index.rst:53 -msgid "Avoid using Latin phrases" -msgstr "ラテン語のフレーズを使用しない" - -#: ../../rst/dev_guide/style_guide/index.rst:55 -msgid "Latin words and phrases like ``e.g.`` or ``etc.`` are easily understood by English speakers. They may be harder to understand for others and are also tricky for automated translation." -msgstr "``e.g.``、``etc.`` のようなラテン語やフレーズは、英語話者であれば簡単に理解できます。ただし、その他の人にとっては理解が難しい場合もあり、自動翻訳の際にも注意が必要になります。" - -#: ../../rst/dev_guide/style_guide/index.rst:59 -msgid "Use the following English terms in place of Latin terms or abbreviations:" -msgstr "したがって、ラテン語の用語または略語の代わりに、英語の用語を使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:62 -msgid "Latin" -msgstr "ラテン語" - -#: ../../rst/dev_guide/style_guide/index.rst:62 -msgid "English" -msgstr "英語" - -#: ../../rst/dev_guide/style_guide/index.rst:64 -msgid "i.e" -msgstr "i.e (言い換えると)" - -#: ../../rst/dev_guide/style_guide/index.rst:64 -msgid "in other words" -msgstr "in other words (言い換えると)" - -#: ../../rst/dev_guide/style_guide/index.rst:66 -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:89 -msgid "e.g." -msgstr "e.g. (たとえば)" - -#: ../../rst/dev_guide/style_guide/index.rst:66 -msgid "for example" -msgstr "for example (たとえば)" - -#: ../../rst/dev_guide/style_guide/index.rst:68 -msgid "etc" -msgstr "etc (など)" - -#: ../../rst/dev_guide/style_guide/index.rst:68 -msgid "and so on" -msgstr "and so on (など)" - -#: ../../rst/dev_guide/style_guide/index.rst:70 -msgid "via" -msgstr "via (により)" - -#: ../../rst/dev_guide/style_guide/index.rst:70 -msgid "by/ through" -msgstr "by/ through ( (により))" - -#: ../../rst/dev_guide/style_guide/index.rst:72 -msgid "vs./versus" -msgstr "vs./versus (対)" - -#: ../../rst/dev_guide/style_guide/index.rst:72 -msgid "rather than/against" -msgstr "rather than/against (対)" - -#: ../../rst/dev_guide/style_guide/index.rst:77 -msgid "reStructuredText guidelines" -msgstr "reStructuredText のガイドライン" - -#: ../../rst/dev_guide/style_guide/index.rst:79 -msgid "The Ansible documentation is written in reStructuredText and processed by Sphinx. We follow these technical or mechanical guidelines on all rST pages:" -msgstr "Ansible ドキュメントは reStructuredText で記述され、Sphinx によって処理されます。すべての rST ページに対して、以下の技術的または機械的なガイドラインが指定されています。" - -#: ../../rst/dev_guide/style_guide/index.rst:83 -msgid "Header notation" -msgstr "ヘッダーの表記法" - -#: ../../rst/dev_guide/style_guide/index.rst:85 -msgid "`Section headers in reStructuredText `_ can use a variety of notations. Sphinx will 'learn on the fly' when creating a hierarchy of headers. To make our documents easy to read and to edit, we follow a standard set of header notations. We use:" -msgstr "`Section headers in reStructuredText `_ は、さまざまな表記を使用できます。Sphinx は、ヘッダーの階層を作成するときに「オンザフライで学習」します。ドキュメントを読みやすく、編集できるようにするために、標準のヘッダー表記法に従います。以下を使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:91 -msgid "``###`` with overline, for parts:" -msgstr "``###`` 上線付き (各部分の場合):" - -#: ../../rst/dev_guide/style_guide/index.rst:99 -msgid "``***`` with overline, for chapters:" -msgstr "``***`` 上線付き (章の場合):" - -#: ../../rst/dev_guide/style_guide/index.rst:107 -msgid "``===`` for sections:" -msgstr "``===`` セクションの場合:" - -#: ../../rst/dev_guide/style_guide/index.rst:114 -msgid "``---`` for subsections:" -msgstr "``---`` サブセクションの場合:" - -#: ../../rst/dev_guide/style_guide/index.rst:121 -msgid "``^^^`` for sub-subsections:" -msgstr "``^^^`` サブサブセクションの場合:" - -#: ../../rst/dev_guide/style_guide/index.rst:128 -msgid "``\"\"\"`` for paragraphs:" -msgstr "``\"\"\"`` パラグラフの場合:" - -#: ../../rst/dev_guide/style_guide/index.rst:137 -msgid "Syntax highlighting - Pygments" -msgstr "構文の強調表示 - Pygment" - -#: ../../rst/dev_guide/style_guide/index.rst:139 -msgid "The Ansible documentation supports a range of `Pygments lexers `_ for `syntax highlighting `_ to make our code examples look good. Each code-block must be correctly indented and surrounded by blank lines." -msgstr "Ansible ドキュメントは、コード例の見栄えを良くするため、`構文の強調表示 `_ の `Pygments lexers `_ の範囲をサポートします。コードブロックは適切にインデントされ、空の行で囲む必要があります。" - -#: ../../rst/dev_guide/style_guide/index.rst:142 -msgid "The Ansible documentation allows the following values:" -msgstr "Ansible ドキュメントでは、以下の値を使用できます。" - -#: ../../rst/dev_guide/style_guide/index.rst:144 -msgid "none (no highlighting)" -msgstr "なし (強調表示なし)" - -#: ../../rst/dev_guide/style_guide/index.rst:145 -msgid "ansible-output (a custom lexer for Ansible output)" -msgstr "ansible-output (Ansible 出力用のカスタム lexer)" - -#: ../../rst/dev_guide/style_guide/index.rst:146 -msgid "bash" -msgstr "bash" - -#: ../../rst/dev_guide/style_guide/index.rst:147 -msgid "console" -msgstr "console" - -#: ../../rst/dev_guide/style_guide/index.rst:148 -msgid "csharp" -msgstr "csharp" - -#: ../../rst/dev_guide/style_guide/index.rst:149 -msgid "ini" -msgstr "ini" - -#: ../../rst/dev_guide/style_guide/index.rst:151 -msgid "powershell" -msgstr "powershell" - -#: ../../rst/dev_guide/style_guide/index.rst:152 -msgid "python" -msgstr "python" - -#: ../../rst/dev_guide/style_guide/index.rst:153 -msgid "rst" -msgstr "rst" - -#: ../../rst/dev_guide/style_guide/index.rst:154 -msgid "sh" -msgstr "sh" - -#: ../../rst/dev_guide/style_guide/index.rst:155 -msgid "shell" -msgstr "shell" - -#: ../../rst/dev_guide/style_guide/index.rst:156 -msgid "shell-session" -msgstr "shell-session" - -#: ../../rst/dev_guide/style_guide/index.rst:157 -msgid "text" -msgstr "text" - -#: ../../rst/dev_guide/style_guide/index.rst:158 -msgid "yaml" -msgstr "yaml" - -#: ../../rst/dev_guide/style_guide/index.rst:159 -msgid "yaml+jinja" -msgstr "yaml+jinja" - -#: ../../rst/dev_guide/style_guide/index.rst:161 -msgid "For example, you can highlight Python code using following syntax:" -msgstr "たとえば、以下の構文を使用して Python コードを強調表示できます。" - -#: ../../rst/dev_guide/style_guide/index.rst:171 -msgid "Internal navigation" -msgstr "内部ナビゲーション" - -#: ../../rst/dev_guide/style_guide/index.rst:173 -msgid "`Anchors (also called labels) and links `_ work together to help users find related content. Local tables of contents also help users navigate quickly to the information they need. All internal links should use the ``:ref:`` syntax. Every page should have at least one anchor to support internal ``:ref:`` links. Long pages, or pages with multiple levels of headers, can also include a local TOC." -msgstr "`Anchors (also called labels) and links `関連コンテンツを見つけやすくするために、あるローカルテーブルも必要な情報に移動するのに役立ちます。すべての内部リンクで ``:ref:`` 構文を使用する必要があります。また、内部ページには内部 ``:ref:`` リンクに対応するアンカーは 1 つ以上ある必要があります。長いページまたは複数のヘッダーレベルを持つページでも、ローカルの TOC を含めることもできます。" - -#: ../../rst/dev_guide/style_guide/index.rst:183 -msgid "Adding anchors" -msgstr "アンカーの追加" - -#: ../../rst/dev_guide/style_guide/index.rst:185 -msgid "Include at least one anchor on every page" -msgstr "すべてのページに少なくとも 1 つのアンカーを含める。" - -#: ../../rst/dev_guide/style_guide/index.rst:186 -msgid "Place the main anchor above the main header" -msgstr "メインヘッダーの上にメインアンカーを配置する。" - -#: ../../rst/dev_guide/style_guide/index.rst:187 -msgid "If the file has a unique title, use that for the main page anchor::" -msgstr "このファイルに一意のタイトルがある場合は、メインページのアンカーに使用する。" - -#: ../../rst/dev_guide/style_guide/index.rst:191 -msgid "You may also add anchors elsewhere on the page" -msgstr "ページにアンカーを追加することもできます。" - -#: ../../rst/dev_guide/style_guide/index.rst:194 -msgid "Adding internal links" -msgstr "内部リンクの追加" - -#: ../../rst/dev_guide/style_guide/index.rst:196 -msgid "All internal links must use ``:ref:`` syntax. These links both point to the anchor defined above:" -msgstr "すべての内部リンクには ``:ref:`` 構文を使用する必要があります。これらのリンクは共に、上で定義したアンカーを指定します。" - -#: ../../rst/dev_guide/style_guide/index.rst:203 -msgid "The second example adds custom text for the link." -msgstr "2 つ目の例は、リンクのカスタムテキストを追加します。" - -#: ../../rst/dev_guide/style_guide/index.rst:206 -msgid "Adding links to modules and plugins" -msgstr "モジュールおよびプラグインへのリンクの追加" - -#: ../../rst/dev_guide/style_guide/index.rst:208 -msgid "Ansible 2.10 and later require the extended Fully Qualified Collection Name (FQCN) as part of the links:" -msgstr "Ansible 2.10 以降は、リンクの一部として、拡張された完全修飾コレクション名 (FQCN) が必要です。" - -#: ../../rst/dev_guide/style_guide/index.rst:214 -msgid "For example:" -msgstr "たとえば、以下のようになります。" - -#: ../../rst/dev_guide/style_guide/index.rst:220 -msgid "displays as :ref:`ansible.builtin.first_found lookup plugin `." -msgstr ":ref:`ansible.builtin.first_found lookup plugin ` として表示します。" - -#: ../../rst/dev_guide/style_guide/index.rst:222 -msgid "Modules require different suffixes from other plugins:" -msgstr "モジュールには、他のプラグインとは異なるサフィックスが必要です。" - -#: ../../rst/dev_guide/style_guide/index.rst:224 -msgid "Module links use this extended FQCN module name with ``_module`` for the anchor." -msgstr "モジュールリンクはこの広範な FQCN モジュール名に続けて、アンカーに ``_module`` を使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:225 -msgid "Plugin links use this extended FQCN plugin name with the plugin type (``_connection`` for example)." -msgstr "プラグインのリンクは、この拡張された FQCN プラグイン名をプラグイン種別 (``_connection`` など) で使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:234 -msgid "``ansible.builtin`` is the FQCN for modules included in ``ansible.base``. Documentation links are the only place you prepend ``ansible_collections`` to the FQCN. This is used by the documentation build scripts to correctly fetch documentation from collections on Ansible Galaxy." -msgstr "``ansible.builtin`` は、``ansible.base`` に含まれているモジュールの FQCN (ドキュメントリンク) です。ドキュメントのリンクは、``ansible_collections`` を FQCN の前に付ける唯一の場所です。これは、Ansible Galaxy のコレクションからドキュメントを適切に取得するために、ドキュメントビルドスクリプトによって使用されます。" - -#: ../../rst/dev_guide/style_guide/index.rst:239 -msgid "Adding local TOCs" -msgstr "ページ内目次の追加" - -#: ../../rst/dev_guide/style_guide/index.rst:241 -msgid "The page you're reading includes a `local TOC `_. If you include a local TOC:" -msgstr "読み取りするページには `ローカル TOC `_ が含まれます。ローカルの TOC を含める場合は、以下のようになります。" - -#: ../../rst/dev_guide/style_guide/index.rst:244 -msgid "place it below, not above, the main heading and (optionally) introductory text" -msgstr "目次の下に、主要な見出しと (任意で) 紹介文を追加する。" - -#: ../../rst/dev_guide/style_guide/index.rst:245 -msgid "use the ``:local:`` directive so the page's main header is not included" -msgstr "そのページの主要なヘッダーが含まれないように ``:local:`` ディレクティブを使用する。" - -#: ../../rst/dev_guide/style_guide/index.rst:246 -msgid "do not include a title" -msgstr "タイトルは除外する。" - -#: ../../rst/dev_guide/style_guide/index.rst:248 -msgid "The syntax is:" -msgstr "構文は以下のようになります。" - -#: ../../rst/dev_guide/style_guide/index.rst:256 -msgid "More resources" -msgstr "参考資料" - -#: ../../rst/dev_guide/style_guide/index.rst:258 -msgid "These pages offer more help with grammatical, stylistic, and technical rules for documentation." -msgstr "以下のページでは、ドキュメントに関する文法、スタイル、および技術的なルールを紹介しています。" - -#: ../../rst/dev_guide/style_guide/index.rst:273 -msgid ":ref:`community_documentation_contributions`" -msgstr ":ref:`community_documentation_contributions`" - -#: ../../rst/dev_guide/style_guide/index.rst:274 -msgid "How to contribute to the Ansible documentation" -msgstr "Ansible ドキュメントへの貢献方法" - -#: ../../rst/dev_guide/style_guide/index.rst:275 -msgid ":ref:`testing_documentation_locally`" -msgstr ":ref:`testing_documentation_locally`" - -#: ../../rst/dev_guide/style_guide/index.rst:276 -msgid "How to build the Ansible documentation" -msgstr "Ansible ドキュメントのビルド方法" - -#: ../../rst/dev_guide/style_guide/index.rst:278 -msgid "#ansible-docs IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible-docs)" - -#: ../../rst/dev_guide/style_guide/resources.rst:2 -msgid "Resources" -msgstr "リソース" - -#: ../../rst/dev_guide/style_guide/resources.rst:3 -msgid "Follow the style of the :ref:`Ansible Documentation`" -msgstr "* 「:ref:`Ansible ドキュメント`」のスタイルに従ってください。" - -#: ../../rst/dev_guide/style_guide/resources.rst:4 -msgid "Ask for advice on IRC, on the ``#ansible-devel`` Freenode channel" -msgstr "Freenode チャンネル ``#ansible-devel`` の IRC で質問してください。" - -#: ../../rst/dev_guide/style_guide/resources.rst:5 -msgid "Review these online style guides:" -msgstr "オンラインのスタイルガイドを確認してください。" - -#: ../../rst/dev_guide/style_guide/resources.rst:7 -msgid "`AP Stylebook `_" -msgstr "`AP Stylebook `_" - -#: ../../rst/dev_guide/style_guide/resources.rst:8 -msgid "`Chicago Manual of Style `_" -msgstr "`Chicago Manual of Style `_" - -#: ../../rst/dev_guide/style_guide/resources.rst:9 -msgid "`Strunk and White's Elements of Style `_" -msgstr "`Strunk and White's Elements of Style `_" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:5 -msgid "Writing documentation so search can find it" -msgstr "検索用のドキュメントの作成" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:7 -msgid "One of the keys to writing good documentation is to make it findable. Readers use a combination of internal site search and external search engines such as Google or duckduckgo." -msgstr "優れたドキュメントを作成するための鍵の 1 つは、ドキュメントを見つけやすくすることです。読者は、内部サイト検索と、Google や duckduckgo などの外部検索エンジンを組み合わせて使用します。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:9 -msgid "To ensure Ansible documentation is findable, you should:" -msgstr "Ansible ドキュメントが見つかるようにするには、以下を行う必要があります。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:11 -msgid "Use headings that clearly reflect what you are documenting." -msgstr "ドキュメントの内容を明確に反映させる見出しを使用します。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:12 -msgid "Use numbered lists for procedures or high-level steps where possible." -msgstr "可能な場合は、番号付きの一覧または手順の概要手順に使用します。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:13 -msgid "Avoid linking to github blobs where possible." -msgstr "可能な限り、github Blob にリンクしないでください。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:17 -msgid "Using clear headings in documentation" -msgstr "ドキュメントで明確な見出しの使用" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:19 -msgid "We all use simple English when we want to find something. For example, the title of this page could have been any one of the following:" -msgstr "何かを探すときは、簡単な英語を使います。たとえば、このページのタイトルは次のいずれかになります。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:21 -msgid "Search optimization" -msgstr "検索の最適化" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:22 -msgid "Findable documentation" -msgstr "検索可能なドキュメント" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:23 -msgid "Writing for findability" -msgstr "見やすくするために記述" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:25 -msgid "What we are really trying to describe is - how do I write documentation so search engines can find my content? That simple phrase is what drove the title of this section. When you are creating your headings for documentation, spend some time to think about what you would type in a search box to find it, or more importantly, how someone less familiar with Ansible would try to find that information. Your heading should be the answer to that question." -msgstr "私たちが本当に説明しようとしているのは、「検索エンジンがコンテンツを見つけられるように、どのようにドキュメントを書けばいいのか」ということです。その単純なフレーズが、このセクションのタイトルになりました。ドキュメントの見出しを作成するときは、検索ボックスに何を入力して検索するのか、さらに重要なことに、Ansible にあまり詳しくない人がその情報をどのように見つけようとするかを考える時間を設けてください。見出しは、その質問に対する答えであるべきです。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:27 -msgid "One word of caution - you do want to limit the size of your headings. A full heading such as `How do I write documentation so search engines can find my content?` is too long. Search engines would truncate anything over 50 - 60 characters. Long headings would also wrap on smaller devices such as a smart phone." -msgstr "注意の 1 つの単語 - 見出しのサイズを制限する場合は、`How do I write documentation so search engines can find my content?` などの見出しにすると長すぎます。検索エンジンは 50 ~ 60 文字を超えるものを省略します。長い見出しも、スマートフォンなどの小規模なデバイスで折り返されます。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:30 -msgid "Using numbered lists for `zero position` snippets" -msgstr "`zero position` スニペットの番号付きのリストの使用" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:32 -msgid "Google can optimize the search results by adding a `feature snippet `_ at the top of the search results. This snippet provides a small window into the documentation on that first search result that adds more detail than the rest of the search results, and can occasionally answer the reader's questions right there, or at least verify that the linked page is what the reader is looking for." -msgstr "Google は、検索結果の上部に `feature snippet `_ を追加して検索結果を最適化できます。このスニペットは、最初の検索結果に関するドキュメントに小さなウィンドウを提供し、残りの検索結果よりも詳細を追加し、時には読者の質問にその場で答えたり、少なくともリンク先のページが読者の探しているものであることを確認することができます。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:34 -msgid "Google returns the feature snippet in the form of numbered steps. Where possible, you should add a numbered list near the top of your documentation page, where appropriate. The steps can be the exact procedure a reader would follow, or could be a high level introduction to the documentation topic, such as the numbered list at the top of this page." -msgstr "Google は番号付きの手順の機能スニペットを返します。可能であれば、必要に応じて、ドキュメントページの上部付近に番号付きリストを追加する必要があります。手順は、読者が従う正確な手順にすることも、このページの上部にある番号付きリストなど、ドキュメントトピックの概要を説明することもできます。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:37 -msgid "Problems with github blobs on search results" -msgstr "検索結果に関する github ブロブの問題" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:39 -msgid "Search engines do not typically return github blobs in search results, at least not in higher ranked positions. While it is possible and sometimes necessary to link to github blobs from documentation, the better approach would be to copy that information into an .rst page in Ansible documentation." -msgstr "検索エンジンは通常、少なくとも上位の位置では、検索結果に github ブロブを返しません。ドキュメントから github ブロブにリンクすることは可能であり、場合によっては必要ですが、より良いアプローチは、その情報を Ansible ドキュメントの .rst ページにコピーすることです。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:42 -msgid "Other search hints" -msgstr "他の検索ヒント" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:44 -msgid "While it may not be possible to adapt your documentation to all search optimizations, keep the following in mind as you write your documentation:" -msgstr "すべての検索最適化にドキュメントを調整することができない場合もありますが、ドキュメントを作成する場合は、以下の点に留意してください。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:46 -msgid "**Search engines don't parse beyond the `#` in an html page.** So for example, all the subheadings on this page are appended to the main page URL. As such, when I search for 'Using number lists for zero position snippets', the search result would be a link to the top of this page, not a link directly to the subheading I searched for. Using :ref:`local TOCs ` helps alleviate this problem as the reader can scan for the header at top of the page and click to the section they are looking for. For critical documentation, consider creating a new page that can be a direct search result page." -msgstr "**検索エンジンは、html ページ内の `#` 以降は解析しません。** そのため、たとえば、このページのすべての小見出しは、メインページの URL に付加されています。そのため、「Using number lists for zero position snippets」と検索すると、検索結果はこのページの冒頭へのリンクになり、検索した小見出しへの直接のリンクにはなりません。:ref:`ローカル TOC ` を使用すると、読者がページ上部のヘッダーをスキャンして、探しているセクションにクリックできるため、この問題を軽減することができます。重要な文書については、検索結果のページに直接アクセスできる新しいページを作成することを検討してください。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:48 -msgid "**Make your first few sentences clearly describe your page topic.** Search engines return not just the URL, but a short description of the information at the URL. For Ansible documentation, we do not have description metadata embedded on each page. Instead, the search engines return the first couple of sentences (140 characters) on the page. That makes your first sentence or two very important to the reader who is searching for something in Ansible." -msgstr "**最初の 2、3 文でページのトピックを明確に説明してください。** 検索エンジンは URL だけでなく、その URL にある情報の簡単な説明も返します。Ansible ドキュメントの場合、各ページに説明メタデータが埋め込まれていません。その代わり、検索エンジンはページの最初の 2、3 文 (140 文字) を返します。そのため、Ansibleで何かを検索している読者にとって、最初の 1〜2 文が非常に重要になります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:2 -msgid "Spelling - Word Usage - Common Words and Phrases to Use and Avoid" -msgstr "スペル、単語の使用、およびに使用または回避する一般的な単語とフレーズ" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:5 -msgid "Acronyms" -msgstr "略語" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:7 -msgid "Always uppercase. An acronym is a word formed from the initial letters of a name, such as ROM for Read-only memory, SaaS for Software as a Service, or by combining initial letters or part of a series of words, such as LILO for LInux LOader." -msgstr "常に大文字です。頭字語とは、ROM (Read-Only Memory) や SaaS (Software as a Service) のように名前の頭文字から形成された単語や、LILO (LInux LOader) のように一連の単語の頭文字や一部を組み合わせて形成された単語のことです。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:11 -msgid "Spell out the acronym before using it in alone text, such as \"The Embedded DevKit (EDK)...\"" -msgstr "略語は、単独で使用する前に、「The Embedded devkit(EDK)...」のように文字を略さずに書いて使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:14 -msgid "Applications" -msgstr "アプリケーション" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:15 -msgid "When used as a proper name, use the capitalization of the product, such as GNUPro, Source-Navigator, and Ansible Tower. When used as a command, use lowercase as appropriate, such as \"To start GCC, type ``gcc``.\"" -msgstr "固有名詞として使用する場合は、GNUPro、Source-Navigator、Ansible Tower のように製品の大文字を使用します。コマンドとして使用する場合は、「To start GCC, type ``gcc``.」(GCC を起動する場合は、``gcc`` を入力します。) のように、適切な小文字を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:19 -msgid "\"vi\" is always lowercase." -msgstr "「vi」は常に小文字です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:22 -msgid "As" -msgstr "Ansibleは、" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:23 -msgid "This is often used to mean \"because\", but has other connotations, for example, parallel or simultaneous actions. If you mean \"because\", say \"because\"." -msgstr "原因を示す場合によく使用されますが、並列または同時の操作など、他の意味もあります。「原因」を意味する場合は、「because」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:26 -msgid "Asks for" -msgstr "Asks for" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:27 -msgid "Use \"requests\" instead." -msgstr "代わりに「requests」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:30 -msgid "Assure/Ensure/Insure" -msgstr "Assure/Ensure/Insure" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:31 -msgid "Assure implies a sort of mental comfort. As in \"I assured my husband that I would eventually bring home beer.\"" -msgstr "「assure」は、一種の精神的な安心さを意味します。たとえば、「I assured my husband that I would eventually bring home beer. (私は夫に最終的に家のビールを持ってくることを保証しました。)」のように使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:33 -msgid "Ensure means \"to make sure.\"" -msgstr "「ensure」は、「確実に」を意味します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:35 -msgid "Insure relates to monetary insurance." -msgstr "「insure」は、金銭的な保険に関係があります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:39 -msgid "Back up" -msgstr "Back up" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:40 -msgid "This is a verb. You \"back up\" files; you do not \"backup\" files." -msgstr "これは動詞です。ファイルを「バックアップ」するときは、「backup」ではなく、「back up」と記載します (You back up files)。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:43 -msgid "Backup" -msgstr "Backup" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:44 -msgid "This is a noun. You create \"backup\" files; you do not create \"back up\" files." -msgstr "これは名詞です。「バックアップ」ファイルを作成するときは、「back up」ではなく、「backup」と記載します (You create backup files)。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:47 -msgid "Backward" -msgstr "Backward" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:48 -msgid "Correct. Avoid using backwards unless you are stating that something has \"backwards compatibility.\"" -msgstr "適切です。「backwards compatibility」(後方互換性) 以外の説明に、「backward」という単語を使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:51 -msgid "Backwards compatibility" -msgstr "Backwards compatibility" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:52 -msgid "Correct as is." -msgstr "そのまま使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:55 -msgid "By way of" -msgstr "By way of" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:56 -msgid "Use \"using\" instead." -msgstr "代わりに「using」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:59 -msgid "Can/May" -msgstr "Can/May" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:60 -msgid "Use \"can\" to describe actions or conditions that are possible. Use \"may\" only to describe situations where permission is being given. If either \"can,\" \"could,\" or \"may\" apply, use \"can\" because it's less tentative." -msgstr "「can」は、可能な操作や条件を説明するのに使用します。許可が必要な状況を説明するには、「may」を使用します。「can」、「could」、または「may」のいずれかが当てはまる場合は、「can」を使用します (暫定的な意味合いが少ないため)。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:63 -msgid "CD or cd" -msgstr "CD または cd" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:64 -msgid "When referring to a compact disk, use CD, such as \"Insert the CD into the CD-ROM drive.\" When referring to the change directory command, use cd." -msgstr "コンパクトディスクを参照する場合は、CD を使用します。たとえば、「Insert the CD into the CD-ROM drive.」(CD を CD-ROM ドライブに挿入します。) とします。ディレクトリーを変更する change directory コマンドを示す場合は、cd を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:67 -msgid "CD-ROM" -msgstr "CD-ROM" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:68 -msgid "Correct. Do not use \"cdrom,\" \"CD-Rom,\" \"CDROM,\" \"cd-rom\" or any other variation. When referring to the drive, use CD-ROM drive, such as \"Insert the CD into the CD-ROM drive.\" The plural is \"CD-ROMs.\"" -msgstr "「cdrom」、「CD-Rom」、「CDROM」、「cd-rom」、またはその他のバリテーションは使用しないでください。ドライブを参照する場合は、「Insert the CD into the CD-ROM drive (CD-ROM ドライブなど)」のように「CD-ROM drive」を使用します。複数形は「CD-ROMs」となります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:72 -msgid "Command line" -msgstr "Command line" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:73 -msgid "Correct. Do not use \"command-line\" or \"commandline\" as a noun. If used as an adjective, \"command-line\" is appropriate, for example \"command-line arguments\"." -msgstr "適切です。「command-line」または「commandline」を名詞として使用しないでください。形容詞として使用する場合は、「command-line arguments」のように、「command-line」が適切です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:75 -msgid "Use \"command line\" to describes where to place options for a command, but not where to type the command. Use \"shell prompt\" instead to describe where to type commands. The line on the display screen where a command is expected. Generally, the command line is the line that contains the most recently displayed command prompt." -msgstr "「コマンドライン」を使用して、コマンドのオプションを配置する場所を記述しますが、コマンドを入力する場所は記述しません。コマンドを入力する場所を説明する場合は、代わりに「shell prompt」を使用します。コマンドが期待される画面上の行です。通常、コマンドラインは、最後に表示されるコマンドプロンプトを含む行です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:79 -msgid "Daylight saving time (DST)" -msgstr "Daylight saving time (DST)" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:81 -msgid "Correct. Do not use daylight savings time. Daylight Saving Time (DST) is often misspelled \"Daylight Savings\", with an \"s\" at the end. Other common variations are \"Summer Time\"and \"Daylight-Saving Time\". (https://www.timeanddate.com/time/dst/daylight-savings-time.html)" -msgstr "適切です。「daylight savings time」は使用しないでください。「Daylight Saving Time (DST)」は、「Daylight Savings」のように、最後に s が付いている場合がありますが、これは間違いです。その他の一般的な表記法には、「Summer Time」および「Daylight-Saving Time」があります (https://www.timeanddate.com/time/dst/daylight-savings-time.html))。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:85 -msgid "Download" -msgstr "Download" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:86 -msgid "Correct. Do not use \"down load\" or \"down-load.\"" -msgstr "適切です。「down load」または「down-load」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:90 -msgid "Spell it out: \"For example.\"" -msgstr "省略せずに「For example」とします。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:93 -msgid "Failover" -msgstr "Failover" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:94 -msgid "When used as a noun, a failover is a backup operation that automatically switches to a standby database, server or network if the primary system fails or is temporarily shut down for servicing. Failover is an important fault tolerance function of mission-critical systems that rely on constant accessibility. Failover automatically and transparently to the user redirects requests from the failed or down system to the backup system that mimics the operations of the primary system." -msgstr "名詞として使用される場合、フェイルオーバーとは、プライマリーシステムに障害が発生したり、サービスのために一時的に停止した場合に、自動的にスタンバイデータベース、サーバー、またはネットワークに切り替えるバックアップ操作のことです。フェイルオーバーは、常にアクセス可能であることが求められるミッションクリティカルなシステムの重要なフォールト・トレランス機能となります。フェイルオーバーは、自動的かつユーザーに透過的に、障害や停止したシステムからのリクエストを、プライマリーシステムの操作を模倣したバックアップシステムにリダイレクトします。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:97 -msgid "Fail over" -msgstr "Fail over" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:98 -msgid "When used as a verb, fail over is two words since there can be different tenses such as failed over." -msgstr "動詞として使用する場合は、時制を変えられるように (failed over など)、2 つの単語にします。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:101 -msgid "Fewer" -msgstr "Fewer" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:102 -msgid "Fewer is used with plural nouns. Think things you could count. Time, money, distance, and weight are often listed as exceptions to the traditional \"can you count it\" rule, often thought of a singular amounts (the work will take less than 5 hours, for example)." -msgstr "fewer は、複数形の名詞で使用します。数を数えることができるものに使用します。時間、お金、距離、および重量は、従来の「数えることができるか」ルールの例外として挙げられることが多く、通常は 1 つの量と見なされます。たとえば、「the work will take less than 5 hours」(作業にかかる時間は 5 時間未満です)。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:105 -msgid "File name" -msgstr "File name" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:106 -msgid "Correct. Do not use \"filename.\"" -msgstr "適切です。「filename」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:109 -msgid "File system" -msgstr "File system" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:110 -msgid "Correct. Do not use \"filesystem.\" The system that an operating system or program uses to organize and keep track of files. For example, a hierarchical file system is one that uses directories to organize files into a tree structure. Although the operating system provides its own file management system, you can buy separate file management systems. These systems interact smoothly with the operating system but provide more features, such as improved backup procedures and stricter file protection." -msgstr "適切です。「filesystem」は使用しないでください。オペレーティングシステムまたはプログラムがファイルを整理し、追跡するために使用するシステムです。たとえば、階層ファイルシステムは、ディレクトリーを使用してファイルをツリー構造に編成するものです。オペレーティングシステムは独自のファイル管理システムを提供していますが、別のファイル管理システムを購入することもできます。このようなシステムはオペレーティングシステムとスムーズに対話しますが、バックアップ手順の改善やファイル保護の強化など、より多くの機能を提供します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:113 -msgid "For instance" -msgstr "For instance" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:114 -msgid "For example,\" instead." -msgstr "代わりに「For example」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:117 -msgid "For further/additional/whatever information" -msgstr "For further/additional/whatever information" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:118 -msgid "Use \"For more information\"" -msgstr "「For more information」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:121 -msgid "For this reason" -msgstr "For this reason" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:122 -msgid "Use \"therefore\"." -msgstr "「therefore」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:125 -msgid "Forward" -msgstr "Forward" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:126 -msgid "Correct. Avoid using \"forwards.\"" -msgstr "適切です。「forwards」を使用して拒否します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:129 -msgid "Gigabyte (GB)" -msgstr "Gigabyte (GB)" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:130 -msgid "2 to the 30th power (1,073,741,824) bytes. One gigabyte is equal to 1,024 megabytes. Gigabyte is often abbreviated as G or GB." -msgstr "2 の 30乗 (1,073,741,824) バイト。1 ギガバイトは 1,024 メガバイトに相当します。ギガバイトは、G または GB と略されることがよくあります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:133 -msgid "Got" -msgstr "Got" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:134 -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:208 -msgid "Avoid. Use \"must\" instead." -msgstr "使用しないようにしてください。代わりに \"must\" を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:137 -msgid "High-availability" -msgstr "High-availability" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:138 -msgid "Correct. Do not use \"high availability.\"" -msgstr "適切です。「hight availability」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:141 -msgid "Highly available" -msgstr "Highly available" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:142 -msgid "Correct. Do not use highly-available.\"" -msgstr "適切です。高可用性は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:145 -msgid "Hostname" -msgstr "Hostname" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:146 -msgid "Correct. Do not use host name." -msgstr "適切です。ホスト名は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:149 -msgid "i.e." -msgstr "i.e." - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:150 -msgid "Spell it out: \"That is.\"" -msgstr "「That is」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:153 -msgid "Installer" -msgstr "Installer" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:154 -msgid "Avoid. Use \"installation program\" instead." -msgstr "使用しないでください。代わりに「installation program」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:157 -msgid "It's and its" -msgstr "It's および its" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:158 -msgid "\"It's\" is a contraction for \"it is;\" use \"it is\" instead of \"it's.\" Use \"its\" as a possessive pronoun (for example, \"the store is known for its low prices\")." -msgstr "「It's」は「it is」の短縮形です。「it's」ではなく「it is」を使用します。所有代名詞は「its」と使用します。たとえば「the store is known for its low prices」(この店は低価格で知られています) となります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:161 -msgid "Less" -msgstr "Less" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:162 -msgid "Less is used with singular nouns. For example \"View less details\" wouldn't be correct but \"View less detail\" works. Use fewer when you have plural nouns (things you can count)." -msgstr "Less は単数名詞で使用されます。たとえば、「View less details」は間違っていますが、「View less detail」は適切です。複数名詞 (数えられる物) には、「fewer」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:165 -msgid "Linux" -msgstr "Linux" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:166 -msgid "Correct. Do not use \"LINUX\" or \"linux\" unless referring to a command, such as \"To start Linux, type linux.\" Linux is a registered trademark of Linus Torvalds." -msgstr "適切です。コマンドを参照している場合 (たとえば「To start Linux, type linux」(Linux を起動する場合は、linux と入力します)) を除き、「LINUX」または「linux」を使用しないでください。Linux is a registered trademark of Linus Torvalds." - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:169 -msgid "Login" -msgstr "Login" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:170 -msgid "A noun used to refer to the login prompt, such as \"At the login prompt, enter your username.\"" -msgstr "ログインプロンプトを示すために使用している名詞です。たとえば、「At the login prompt, enter your username.」(ログインプロンプトでユーザー名を入力してください。) とします。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:173 -msgid "Log in" -msgstr "Log in" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:174 -msgid "A verb used to refer to the act of logging in. Do not use \"login,\" \"loggin,\" \"logon,\" and other variants. For example, \"When starting your computer, you are requested to log in...\"" -msgstr "ログインの動作を参照するために使用される動詞です。「login」、「loggin」、「loggin」などの形は使用しないでください。たとえば、「When starting your computer, you are requested to log in...」(コンピューターを起動すると、ログインを要求されます...) と表示されます。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:177 -msgid "Log on" -msgstr "Log on" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:178 -msgid "To make a computer system or network recognize you so that you can begin a computer session. Most personal computers have no log-on procedure -- you just turn the machine on and begin working. For larger systems and networks, however, you usually need to enter a username and password before the computer system will allow you to execute programs." -msgstr "コンピューターセッションを開始できるように、コンピューターシステムまたはネットワークにユーザーを認識させることです。ほとんどのコンピューターにはログオン手順がありません。マシンの電源を入れれば動くためです。ただし、大規模システムやネットワークの場合には、通常、コンピュータシステムでプログラムを実行する前に、ユーザー名とパスワードを入力する必要があります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:181 -msgid "Lots of" -msgstr "Lots of" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:182 -msgid "Use \"Several\" or something equivalent instead." -msgstr "代わりに「several」などの単語を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:185 -msgid "Make sure" -msgstr "Make sure" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:186 -msgid "This means \"be careful to remember, attend to, or find out something.\" For example, \"...make sure that the rhedk group is listed in the output.\" Try to use verify or ensure instead." -msgstr "これは、「何かを覚えたり、注意したり、見つけたりするように注意する」という意味です。たとえば、「...make sure that the rhedk group is listed in the output.」(rhedk グループが出力の一覧に含まれていることを確認してください。) となります。代わりに verify や ensure を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:190 -msgid "Manual/man page" -msgstr "Manual/man page" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:191 -msgid "Correct. Two words. Do not use \"manpage\"" -msgstr "適切です。2 つの単語になります。「manpage」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:194 -msgid "MB" -msgstr "MB" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:195 -msgid "When spelled MB, short for megabyte (1,000,000 or 1,048,576 bytes, depending on the context)." -msgstr "MB は、メガバイト (状況に応じて 1,000,000 バイトまたは 1,048,576 バイト) の略語です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:196 -msgid "When spelled Mb, short for megabit." -msgstr "Mb は、メガビットの略語です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:199 -msgid "MBps" -msgstr "MBps" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:200 -msgid "Short for megabytes per second, a measure of data transfer speed. Mass storage devices are generally measured in MBps." -msgstr "1 秒あたりのメガバイトの略語で、データ転送速度の測定単位です。通常、大容量ストレージデバイスは、MBps で表されます。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:203 -msgid "MySQL" -msgstr "MySQL" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:204 -msgid "Common open source database server and client package. Do not use \"MYSQL\" or \"mySQL.\"" -msgstr "一般的なオープンソースデータベースサーバーおよびクライアントパッケージです。「MYSQL」または「mySQL」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:207 -msgid "Need to" -msgstr "Need to" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:211 -msgid "Read-only" -msgstr "Read-only" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:212 -msgid "Correct. Use when referring to the access permissions of files or directories." -msgstr "正しいです。ファイルまたはディレクトリーのアクセスパーミッションを参照する場合に使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:215 -msgid "Real time/real-time" -msgstr "Real time/real-time" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:216 -msgid "Depends. If used as a noun, it is the actual time during which something takes place. For example, \"The computer may partly analyze the data in real time (as it comes in) -- R. H. March.\" If used as an adjective, \"real-time\" is appropriate. For example, \"XEmacs is a self-documenting, customizable, extensible, real-time display editor.\"" -msgstr "状況によって異なります。名詞として使用する場合は、それは何かが行われる実際の時間になります。たとえば、「The computer may partly analyze the data in real time (as it comes in) -- R. H. March」(コンピュータはデータをリアルタイムで部分的に分析する場合があります。(R. H.マーチ)) となります。形容詞として使用する場合は、「real-time」が適切です。たとえば、「XEmacs is a self-documenting, customizable, extensible, real-time display editor.」(XEmacs は、自己文書化を行う、カスタマイズ可能で、拡張可能な、リアルタイムディスプレイエディターです。) となります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:219 -msgid "Refer to" -msgstr "Refer to" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:220 -msgid "Use to indicate a reference (within a manual or website) or a cross-reference (to another manual or documentation source)." -msgstr "参照 (マニュアルまたは Web サイト内) または相互参照 (別のマニュアルまたはドキュメントソース) を示すために使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:223 -msgid "See" -msgstr "詳細は、" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:224 -msgid "Don't use. Use \"Refer to\" instead." -msgstr "使用しないでください。代わりに「Refer to」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:227 -msgid "Since" -msgstr "Since" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:228 -msgid "This is often used to mean \"because\", but \"since\" has connotations of time, so be careful. If you mean \"because\", say \"because\"." -msgstr "この単語は「原因」を意味するためによく使用されますが、「since」には時間の意味合いがあるため、注意してください。「原因」を意味する場合は、「because」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:231 -msgid "Tells" -msgstr "Tells" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:232 -msgid "Use \"Instructs\" instead." -msgstr "代わりに「instructs」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:235 -msgid "That/which" -msgstr "That/which" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:236 -msgid "\"That\" introduces a restrictive clause-a clause that must be there for the sentence to make sense. A restrictive clause often defines the noun or phrase preceding it. \"Which\" introduces a non-restrictive, parenthetical clause-a clause that could be omitted without affecting the meaning of the sentence. For example: The car was travelling at a speed that would endanger lives. The car, which was traveling at a speed that would endanger lives, swerved onto the sidewalk. Use \"who\" or \"whom,\" rather than \"that\" or \"which,\" when referring to a person." -msgstr "「That」は、制限的関係詞節を導入します。これは、文が意味をなすために必要な節です。制限的関係詞節は、多くの場合、その前にある名詞または句を定義します。「Which」は、非制限の、括弧で囲まれた節を導入します。つまり、文の意味に影響を与えずに省略することができる節です。たとえば、「The car was travelling at a speed that would endanger lives.」(人命を危険にさらす速度で車が走行していました。) と、「The car, which was traveling at a speed that would endanger lives, swerved onto the sidewalk.」(人命を危険にさらす速度で走行していた車が歩道にのり上げました。) です。人を指す場合は、「that」または「which」ではなく「who」または「whom」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:239 -msgid "Then/than" -msgstr "Then/than" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:240 -msgid "\"Then\" refers to a time in the past or the next step in a sequence. \"Than\" is used for comparisons." -msgstr "「then」は、ひと続きのものの中から、シーケンスの過去のステップまたは次のステップの時間を指します。比較には「than」が使用されます。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:245 -msgid "Third-party" -msgstr "Third-party" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:246 -msgid "Correct. Do not use \"third party\"." -msgstr "適切です。「third party」を使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:249 -msgid "Troubleshoot" -msgstr "Troubleshoot" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:250 -msgid "Correct. Do not use \"trouble shoot\" or \"trouble-shoot.\" To isolate the source of a problem and fix it. In the case of computer systems, the term troubleshoot is usually used when the problem is suspected to be hardware -related. If the problem is known to be in software, the term debug is more commonly used." -msgstr "適切です。「trouble shoot」または「trouble-shoot」は使用しないでください。問題の原因を特定して修正するためのものです。コンピューターシステムの場合は、通常は、問題がハードウェアに関連するものと考えられる場合に使用されます。問題がソフトウェアにあることが分かっている場合に、より一般的に使用されるのは「debug」です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:253 -msgid "UK" -msgstr "UK" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:254 -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:266 -msgid "Correct as is, no periods." -msgstr "このとおりに使用します。ピリオドは付けません。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:257 -msgid "UNIX®" -msgstr "UNIX®" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:258 -msgid "Correct. Do not use \"Unix\" or \"unix.\" UNIX® is a registered trademark of The Open Group." -msgstr "適切です。「Unix」または「unix」は使用しないでください。UNIX® は、The Open Group の登録商標です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:261 -msgid "Unset" -msgstr "Unset" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:262 -msgid "Don't use. Use Clear." -msgstr "使用しないでください。「Clear」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:265 -msgid "US" -msgstr "US" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:269 -msgid "User" -msgstr "ユーザー" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:270 -msgid "When referring to the reader, use \"you\" instead of \"user.\" For example, \"The user must...\" is incorrect. Use \"You must...\" instead. If referring to more than one user, calling the collection \"users\" is acceptable, such as \"Other users may wish to access your database.\"" -msgstr "読み手を示す場合は、「user」ではなく「you」を使用します。たとえば、「The user must...」は正しくありません。代わりに「You must...」を使用してください。複数のユーザーを示す場合は、「users」を使用できます。たとえば、「Other users may to access your database.」(その他のユーザーがデータベースにアクセスすることを望む可能性があります。) です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:273 -msgid "Username" -msgstr "ユーザー名" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:274 -msgid "Correct. Do not use \"user name.\"" -msgstr "適切です。「ユーザー名」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:277 -msgid "View" -msgstr "表示" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:278 -msgid "When using as a reference (\"View the documentation available online.\"), do not use View. Use \"Refer to\" instead." -msgstr "参照として使用する場合、たとえば「View the documentation available online.」(オンラインで使用可能なドキュメントを参照してください。) とする場合は、「view」を使用しないでください。代わりに「refer to」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:281 -msgid "Within" -msgstr "Within" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:282 -msgid "Don't use to refer to a file that exists in a directory. Use \"In\"." -msgstr "ディレクトリーにあるファイルを参照する場合は使用しないでください。「In」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:285 -msgid "World Wide Web" -msgstr "World Wide Web" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:286 -msgid "Correct. Capitalize each word. Abbreviate as \"WWW\" or \"Web.\"" -msgstr "適切です。各単語を大文字にします。省略形は「WWW」または「Web」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:289 -msgid "Webpage" -msgstr "Webpage" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:290 -msgid "Correct. Do not use \"web page\" or \"Web page.\"" -msgstr "適切です。「web page」または「Web page」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:293 -msgid "Web server" -msgstr "Web server" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:294 -msgid "Correct. Do not use \"webserver\". For example, \"The Apache HTTP Server is the default Web server...\"" -msgstr "適切です。「webserver」は使用しないでください。たとえば、「The Apache HTTP Server is the default Web server...」(Apache HTTP サーバーはデフォルトの Web サーバー...) です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:297 -msgid "Website" -msgstr "Website" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:298 -msgid "Correct. Do not use \"web site\" or \"Web site.\" For example, \"The Ansible website contains ...\"" -msgstr "適切です。「web site」または「Web site」は使用しないでください。たとえば、「The Ansible website contains ...」(Ansible web サイトに...含まれます。) となります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:301 -msgid "Who/whom" -msgstr "Who/whom" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:302 -msgid "Use the pronoun \"who\" as a subject. Use the pronoun \"whom\" as a direct object, an indirect object, or the object of a preposition. For example: Who owns this? To whom does this belong?" -msgstr "主語には、代名詞「who」を使用します。直接目的語、間接目的語、または前置詞の目的語には、代名詞の目的格「whom」を使用します。たとえば、「Who owns this?」(これは誰が所有していますか?) や、「To whom does this belong?」(これは誰のものですか?) となります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:305 -msgid "Will" -msgstr "Will" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:306 -msgid "Do not use future tense unless it is absolutely necessary. For instance, do not use the sentence, \"The next section will describe the process in more detail.\" Instead, use the sentence, \"The next section describes the process in more detail.\"" -msgstr "絶対に必要な場合を除いて、未来時制は使用しないでください。たとえば、「The next section will describe the process in more detail.」(次のセクションでプロセスを詳しく説明します。) ではなく、「The next section describes the process in more detail.」とします。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:309 -msgid "Wish" -msgstr "Wish" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:310 -msgid "Use \"need\" instead of \"desire\" and \"wish.\" Use \"want\" when the reader's actions are optional (that is, they may not \"need\" something but may still \"want\" something)." -msgstr "「desire」および「wish」の代わりに「need」を使用します。読者の操作が任意の場合 (つまり、何かを「必要」とはしないかもしれないけど、それでも何かを「望んでいる」可能性がある場合) は「want」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:313 -msgid "x86" -msgstr "x86" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:314 -msgid "Correct. Do not capitalize the \"x.\"" -msgstr "正しい。「x」は大文字にしないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:317 -msgid "x86_64" -msgstr "x86_64" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:318 -msgid "Do not use. Do not use \"Hammer\". Always use \"AMD64 and Intel® EM64T\" when referring to this architecture." -msgstr "「Hammer」を使用しないでください。このアーキテクチャーを参照する場合は必ず「AMD64 and Intel® EM64T」としてください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:321 -msgid "You" -msgstr "You" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:322 -msgid "Correct. Do not use \"I,\" \"he,\" or \"she.\"" -msgstr "適切です。「I」、「he」、「she」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:325 -msgid "You may" -msgstr "You may" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:326 -msgid "Try to avoid using this. For example, \"you may\" can be eliminated from this sentence \"You may double-click on the desktop...\"" -msgstr "この表現は使用しないようにしてください。たとえば、「You may double-click on the desktop...」(あなたはデスクトップ上でダブルクリックすることができます...) という意味の文からは「you may」を省くことができます。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:3 -msgid "Trademark Usage" -msgstr "商標の使用方法" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:4 -msgid "Why is it important to use the TM, SM, and ® for our registered marks?" -msgstr "登録商標に TM、SM、および ® を使用することが重要な理由" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:6 -msgid "Before a trademark is registered with the United States Patent and Trademark Office it is appropriate to use the TM or SM symbol depending whether the product is for goods or services. It is important to use the TM or SM as it is notification to the public that Ansible claims rights to the mark even though it has not yet been registered." -msgstr "商標が米国特許商標局に登録される前に、TM または SM のどちらの記号を使用するのが適切かは、製品が商品用かサービス用かによって異なります。TM または SM は、登録される前から、Ansible がそのマークに対する権利を主張していることを公に通知するため、TM または SM を使用することが重要です。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:8 -msgid "Once the trademark is registered, it is appropriate to use the symbol in place of the TM or SM. The symbol designation must be used in conjunction with the trademark if Ansible is to fully protect its rights. If we don't protect these marks, we run the risk of losing them in the way of Aspirin or Trampoline or Escalator." -msgstr "商標が登録されたら、TM または SM の代わりにシンボルを使用することが適切です。Ansible がその権利を完全に保護する場合は、シンボルと商標を組み合わせて使用する必要があります。これらのマークを保護しないと、アスピリン、トランポリン、エスカレーターなどのように、権利を失う場合があります。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:11 -msgid "General Rules:" -msgstr "一般的なルール:" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:13 -msgid "Trademarks should be used on 1st references on a page or within a section." -msgstr "商標は、ページ内またはセクション内で最初に参照する際に使用する必要があります。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:15 -msgid "Use Red Hat® Ansible Tower® or Ansible®, on first reference when referring to products." -msgstr "製品を最初に参照する際に、Red Hat® Ansible Tower® または Ansible® のように使用してください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:17 -msgid "Use \"Ansible\" alone as the company name, as in \"Ansible announced quarterly results,\" which is not marked." -msgstr "「Ansible」を会社名として使用する場合は、「Ansible announced quarterly results」(Ansible 四半期決算発表) のように、マークを付けずに使用します。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:19 -msgid "Also add the trademark disclaimer. * When using Ansible trademarks in the body of written text, you should use the following credit line in a prominent place, usually a footnote." -msgstr "商標の免責事項も追加します。* 文章の本文に Ansible 商標を使用する場合は、目立つ場所、通常は脚注に次のような行を追加する必要があります。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:22 -msgid "For Registered Trademarks: - [Name of Trademark] is a registered trademark of Red Hat, Inc. in the United States and other countries." -msgstr "登録商標の場合 - [Name of Trademark] is a registered trademark of Red Hat, Inc. in the United States and other countries." - -#: ../../rst/dev_guide/style_guide/trademarks.rst:25 -msgid "For Unregistered Trademarks (TMs/SMs): - [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries." -msgstr "非登録商標の場合 (TM/SM): - [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries." - -#: ../../rst/dev_guide/style_guide/trademarks.rst:28 -msgid "For registered and unregistered trademarks: - [Name of Trademark] is a registered trademark and [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries." -msgstr "登録商標および未登録商標の場合: [Name of Trademark] is a registered trademark and [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries." - -#: ../../rst/dev_guide/style_guide/trademarks.rst:32 -msgid "Guidelines for the proper use of trademarks:" -msgstr "商標を適切な使用するためのガイドライン:" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:34 -msgid "Always distinguish trademarks from surround text with at least initial capital letters or in all capital letters." -msgstr "商標を、周囲のテキストと区別するために、少なくとも頭文字を大文字にするか、すべての文字を大文字にします。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:36 -msgid "Always use proper trademark form and spelling." -msgstr "常に適切な商標の形式とスペルを使用してください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:38 -msgid "Never use a trademark as a noun. Always use a trademark as an adjective modifying the noun." -msgstr "商標は、動詞として使用しないでください。商標は、常に名詞を修飾する形容詞として使用してください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:40 -msgid "Correct: Red Hat® Ansible Tower® system performance is incredible." -msgstr "正: Red Hat® Ansible Tower® system performance is incredible." - -#: ../../rst/dev_guide/style_guide/trademarks.rst:43 -msgid "Incorrect: Ansible's performance is incredible." -msgstr "適切ではありません。Ansible のパフォーマンスは素晴らしいです。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:46 -msgid "Never use a trademark as a verb. Trademarks are products or services, never actions." -msgstr "商標は、名詞として使用しないでください。商標は製品またはサービスであり、動作ではありません。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:48 -msgid "Correct: \"Orchestrate your entire network using Red Hat® Ansible Tower®.\"" -msgstr "正: \"Orchestrate your entire network using Red Hat® Ansible Tower®.\"" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:51 -msgid "Incorrect: \"Ansible your entire network.\"" -msgstr "誤った使用方法: Ansible your entire network." - -#: ../../rst/dev_guide/style_guide/trademarks.rst:54 -msgid "Never modify a trademark to a plural form. Instead, change the generic word from the singular to the plural." -msgstr "商標を複数形に変更しないでください。代わりに、一般的な単語を単数形から複数形に変更します。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:56 -msgid "Correct: \"Corporate demand for Red Hat® Ansible Tower® configuration software is surging.\"" -msgstr "正: \"Corporate demand for Red Hat® Ansible Tower® configuration software is surging.\"" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:59 -msgid "Incorrect: \"Corporate demand for Ansible is surging.\"" -msgstr "誤った使用方法: Corporate demand for Ansible is surging." - -#: ../../rst/dev_guide/style_guide/trademarks.rst:62 -msgid "Never modify a trademark from its possessive form, or make a trademark possessive. Always use it in the form it has been registered." -msgstr "商標を所有格から変更したり、商標を所有格にしたりしないでください。必ず登録した形を使用してください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:64 -msgid "Never translate a trademark into another language." -msgstr "商標を別の言語に翻訳しないでください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:66 -msgid "Never use trademarks to coin new words or names." -msgstr "商標を使用して新しい単語や名前を作成しないでください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:68 -msgid "Never use trademarks to create a play on words." -msgstr "商標を使用して言葉遊びを作成しないでください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:70 -msgid "Never alter a trademark in any way including through unapproved fonts or visual identifiers." -msgstr "未承認のフォントや視覚的な識別子など、いかなる方法でも商標を変更しないでください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:72 -msgid "Never abbreviate or use any Ansible trademarks as an acronym." -msgstr "Ansible の商標を省略したり、頭文字だけ使用しないでください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:75 -msgid "The importance of Ansible trademarks" -msgstr "Ansible 商標の重要性" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:77 -msgid "The Ansible trademark and the \"A\" logo in a shaded circle are our most valuable assets. The value of these trademarks encompass the Ansible Brand. Effective trademark use is more than just a name, it defines the level of quality the customer will receive and it ties a product or service to a corporate image. A trademark may serve as the basis for many of our everyday decisions and choices. The Ansible Brand is about how we treat customers and each other. In order to continue to build a stronger more valuable Brand we must use it in a clear and consistent manner." -msgstr "Ansible の商標と、斜線で囲まれた「A」のロゴは、当社の最も価値のある資産です。これらの商標の価値は、Ansible ブランドを包括するものです。効果的な商標の使用は、単なる名前ではなく、お客様が受け取る品質レベルを定義し、製品やサービスを企業イメージに結びつけるものです。商標は、私たちの日常的な意思決定や選択の多くの基礎となるものです。Ansible ブランドは、私たちがお客様と互いにどのように接するかということです。より強力で価値のあるブランドを構築し続けるためには、明確で一貫した方法で使用しなければなりません。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:79 -msgid "The mark consists of the letter \"A\" in a shaded circle. As of 5/11/15, this was a pending trademark (registration in process)." -msgstr "このマークは、影付きの円で囲まれた文字「A」で構成されています。2015 年 5 月 11 日の時点で、この商標は係属中 (登録手続き中) でした。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:82 -msgid "Common Ansible Trademarks" -msgstr "一般的な Ansible の商標" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:83 -msgid "Ansible®" -msgstr "Ansible®" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:84 -msgid "Ansible Tower®" -msgstr "Ansible Tower®" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:87 -msgid "Other Common Trademarks and Resource Sites:" -msgstr "その他の一般的な商標およびリソースのサイト:" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:88 -msgid "Linux is a registered trademark of Linus Torvalds." -msgstr "Linux は、Linus Torvalds の登録商標です。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:89 -msgid "UNIX® is a registered trademark of The Open Group." -msgstr "UNIX® は、The Open Group の登録商標です。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:90 -msgid "Microsoft, Windows, Vista, XP, and NT are registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/en-us.aspx" -msgstr "- Microsoft, Windows, Vista, XP, and NT are registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/en-us.aspx" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:91 -msgid "Apple, Mac, Mac OS, Macintosh, Pages and TrueType are either registered trademarks or trademarks of Apple Computer, Inc. in the United States and/or other countries. https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html" -msgstr "Apple, Mac, Mac OS, Macintosh, Pages and TrueType are either registered trademarks or trademarks of Apple Computer, Inc. in the United States and/or other countries. https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:92 -msgid "Adobe, Acrobat, GoLive, InDesign, Illustrator, PostScript , PhotoShop and the OpenType logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. https://www.adobe.com/legal/permissions/trademarks.html" -msgstr "Adobe, Acrobat, GoLive, InDesign, Illustrator, PostScript , PhotoShop and the OpenType logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. https://www.adobe.com/legal/permissions/trademarks.html" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:93 -msgid "Macromedia and Macromedia Flash are trademarks of Macromedia, Inc. https://www.adobe.com/legal/permissions/trademarks.html" -msgstr "Macromedia and Macromedia Flash are trademarks of Macromedia, Inc. https://www.adobe.com/legal/permissions/trademarks.html" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:94 -msgid "IBM is a registered trademark of International Business Machines Corporation. https://www.ibm.com/legal/us/en/copytrade.shtml" -msgstr "IBM is a registered trademark of International Business Machines Corporation. https://www.ibm.com/legal/us/en/copytrade.shtml" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:95 -msgid "Celeron, Celeron Inside, Centrino, Centrino logo, Core Inside, Intel Core, Intel Inside, Intel Inside logo, Itanium, Itanium Inside, Pentium, Pentium Inside,VTune, Xeon, and Xeon Inside are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. https://www.intel.com/content/www/us/en/legal/trademarks.html" -msgstr "Celeron, Celeron Inside, Centrino, Centrino logo, Core Inside, Intel Core, Intel Inside, Intel Inside logo, Itanium, Itanium Inside, Pentium, Pentium Inside,VTune, Xeon, and Xeon Inside are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. https://www.intel.com/content/www/us/en/legal/trademarks.html" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:3 -msgid "Voice Style" -msgstr "態のスタイル" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:4 -msgid "The essence of the Ansible writing style is short sentences that flow naturally together. Mix up sentence structures. Vary sentence subjects. Address the reader directly. Ask a question. And when the reader adjusts to the pace of shorter sentences, write a longer one." -msgstr "Ansible ライティングスタイルの特長は、自然に一緒に流れる短い文です。文法構造は混在させます。文の主題を変化させます。読者に直接話しかけます。質問します。読者が短い文章のペースに順応したら、長い文章を書いてください。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:6 -msgid "Write how real people speak..." -msgstr "実際のユーザーが話すように記述します。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:7 -msgid "...but try to avoid slang and colloquialisms that might not translate well into other languages." -msgstr "...ただし、他言語に適切に翻訳できない可能性のある俗語や口語表現は避けるようにしてください。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:8 -msgid "Say big things with small words." -msgstr "小さなことばで大きなことを説明します。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:9 -msgid "Be direct. Tell the reader exactly what you want them to do." -msgstr "直接的な表現を使用してください。読み手が実行する必要がある内容を正確に指示します。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:10 -msgid "Be honest." -msgstr "誠実に表現します。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:11 -msgid "Short sentences show confidence." -msgstr "短い文章は自信を示しています。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:12 -msgid "Grammar rules are meant to be bent, but only if the reader knows you are doing this." -msgstr "文法規則は、何を説明しているかを読者が理解している場合に限り組み込まれることが意図されています。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:13 -msgid "Choose words with fewer syllables for faster reading and better understanding." -msgstr "読みやすく、理解を深めるために、音節が少ない単語を選んでください。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:14 -msgid "Think of copy as one-on-one conversations rather than as a speech. It's more difficult to ignore someone who is speaking to you directly." -msgstr "コピーは、聴衆に対するスピーチではなく、1 対 1 の対話と考えてください。直接話しかけている人を無視するのはより困難です。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:15 -msgid "When possible, start task-oriented sentences (those that direct a user to do something) with action words. For example: Find software... Contact support... Install the media.... and so forth." -msgstr "可能な場合は、タスク指向の文章 (ユーザーによる作業を指示する項目) は、動作を示す用語で開始します。たとえば、「Find software...」、「Contact support...」、「Install the media...」などです。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:18 -msgid "Active Voice" -msgstr "能動態" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:19 -msgid "Use the active voice (\"Start Linuxconf by typing...\") rather than passive (\"Linuxconf can be started by typing...\") whenever possible. Active voice makes for more lively, interesting reading. Also avoid future tense (or using the term \"will\") whenever possible For example, future tense (\"The screen will display...\") does not read as well as an active voice (\"The screen displays\"). Remember, the users you are writing for most often refer to the documentation while they are using the system, not after or in advance of using the system." -msgstr "可能な限り、受動態 (「Linuxconf can be started by typing...」) ではなく、能動態 (「Start Linuxconf by typing...」) を使用してください。能動態の方がより生き生きとした、注意を引き付ける文章になります。また、未来形 (または「will」の使用) は可能な限り使用しないでください。たとえば、未来形 (「The screen will display...」) と能動態 (「The screen displays」) では、ニュアンスが異なります。読者は、システムの使用前または使用後ではなく、システムの使用中にドキュメントを参照することがほとんどであることに注意してください。" - -#: ../../rst/dev_guide/style_guide/why_use.rst:4 -msgid "Why Use a Style Guide?" -msgstr "スタイルガイドを使用する理由" - -#: ../../rst/dev_guide/style_guide/why_use.rst:6 -msgid "Style guides are important because they ensure consistency in the content, look, and feel of a book or a website." -msgstr "スタイルガイドは、ドキュメントまたは Web サイトのコンテンツおよびルックアンドフィールの一貫性を確保するために重要です。" - -#: ../../rst/dev_guide/style_guide/why_use.rst:8 -msgid "Remember, a style guide is only useful if it is used, updated, and enforced. Style Guides are useful for engineering-related documentation, sales and marketing materials, support docs, community contributions, and more." -msgstr "スタイルガイドは、使用、更新、および実施される場合にのみ役立つことに注意してください。スタイルガイドは、エンジニアリング関連のドキュメント、営業およびマーケティング用資料、サポートドキュメント、コミュニティーへの貢献などに役立ちます。" - -#: ../../rst/dev_guide/style_guide/why_use.rst:10 -msgid "As changes are made to the overall Ansible site design, be sure to update this style guide with those changes. Or, should other resources listed below have major revisions, consider including company information here for ease of reference." -msgstr "Ansible サイトのデザイン全体に変更が加えられた場合は、その変更に合わせて本スタイルガイドも更新してください。または、以下に記載されているその他の資料に大幅な改訂がある場合は、参照しやすいようにここに会社情報を含めることを検討してください。" - -#: ../../rst/dev_guide/style_guide/why_use.rst:12 -msgid "This style guide incorporates current Ansible resources and information so that overall site and documentation consistency can be met." -msgstr "このスタイルガイドには、現在の Ansible リソースと情報が組み込まれているため、サイトとドキュメント全体の一貫性を保つことができます。" - -#: ../../rst/dev_guide/testing.rst:5 -#: ../../rst/dev_guide/testing_running_locally.rst:7 -msgid "Testing Ansible" -msgstr "Ansible のテスト" - -#: ../../rst/dev_guide/testing.rst:12 -msgid "Why test your Ansible contributions?" -msgstr "Ansible への貢献をテストする理由" - -#: ../../rst/dev_guide/testing.rst:14 -msgid "If you're a developer, one of the most valuable things you can do is to look at GitHub issues and help fix bugs, since bug-fixing is almost always prioritized over feature development. Even for non-developers, helping to test pull requests for bug fixes and features is still immensely valuable." -msgstr "開発者にとって、最も価値のあることの 1 つが、GitHub の問題を確認バグ修正を手伝うことです。バグ修正は、ほとんど常に、機能開発よりも優先されるためです。開発者ではなくても、バグの修正や機能のプル要求のテストを手伝うことは非常に価値のあることです。" - -#: ../../rst/dev_guide/testing.rst:16 -msgid "Ansible users who understand how to write playbooks and roles should be able to test their work. GitHub pull requests will automatically run a variety of tests (for example, Shippable) that show bugs in action. However, contributors must also test their work outside of the automated GitHub checks and show evidence of these tests in the PR to ensure that their work will be more likely to be reviewed and merged." -msgstr "Ansible ユーザーは、Playbook とロールの作成方法を理解していれば、自身が作成した作業をテストできるはずです。GitHub プル要求は、バグの動作を示すさまざまなテスト (Shippableなど) を自動的に実行します。ただし、貢献者は、自動化された GitHub チェック以外でも自身の作業をテストし、その証拠を PR で示すと、その作業がレビューされてマージされる可能性が高くなります。" - -#: ../../rst/dev_guide/testing.rst:18 -msgid "Read on to learn how Ansible is tested, how to test your contributions locally, and how to extend testing capabilities." -msgstr "Ansible のテスト方法、貢献をローカルでテストする方法、およびテスト機能を拡張する方法を説明します。" - -#: ../../rst/dev_guide/testing.rst:20 -msgid "If you want to learn about testing collections, read :ref:`testing_collections`" -msgstr "コレクションのテストを確認する場合は、「:ref:`testing_collections`」を参照してください。" - -#: ../../rst/dev_guide/testing.rst:25 -msgid "Types of tests" -msgstr "テストの種類" - -#: ../../rst/dev_guide/testing.rst:27 -msgid "At a high level we have the following classifications of tests:" -msgstr "テストは、大きく分けて以下のように分類されます。" - -#: ../../rst/dev_guide/testing.rst -#: ../../rst/dev_guide/testing/sanity/compile.rst:2 -msgid "compile" -msgstr "コンパイル" - -#: ../../rst/dev_guide/testing.rst:30 -msgid ":ref:`testing_compile`" -msgstr ":ref:`testing_compile`" - -#: ../../rst/dev_guide/testing.rst:31 -msgid "Test python code against a variety of Python versions." -msgstr "さまざまな Python バージョンに対して python コードのテスト" - -#: ../../rst/dev_guide/testing.rst -msgid "sanity" -msgstr "健全性" - -#: ../../rst/dev_guide/testing.rst:34 -msgid "Sanity tests are made up of scripts and tools used to perform static code analysis." -msgstr "健全性テストは、静的コード分析の実行に使用されるスクリプトおよびツールで構成されています。" - -#: ../../rst/dev_guide/testing.rst:35 -msgid "The primary purpose of these tests is to enforce Ansible coding standards and requirements." -msgstr "これらのテストの主な目的は、Ansible コーディングの仕様および要件を適用することです。" - -#: ../../rst/dev_guide/testing.rst -msgid "integration" -msgstr "統合" - -#: ../../rst/dev_guide/testing.rst:38 -msgid "Functional tests of modules and Ansible core functionality." -msgstr "モジュールおよび Ansible コア機能の機能テスト" - -#: ../../rst/dev_guide/testing.rst -msgid "units" -msgstr "ユニット" - -#: ../../rst/dev_guide/testing.rst:40 -#: ../../rst/dev_guide/testing_units_modules.rst:541 -msgid ":ref:`testing_units`" -msgstr ":ref:`testing_units`" - -#: ../../rst/dev_guide/testing.rst:41 -msgid "Tests directly against individual parts of the code base." -msgstr "コードベースの個々の部分に対して直接テストを行います。" - -#: ../../rst/dev_guide/testing.rst:44 -msgid "If you're a developer, one of the most valuable things you can do is look at the GitHub issues list and help fix bugs. We almost always prioritize bug fixing over feature development." -msgstr "開発者にとって、最も価値のあることの 1 つが、GitHub の問題を確認し、バグ修正を手伝うことです。バグ修正は、ほとんど常に、機能開発よりも優先されるためです。" - -#: ../../rst/dev_guide/testing.rst:48 -msgid "Even for non developers, helping to test pull requests for bug fixes and features is still immensely valuable. Ansible users who understand writing playbooks and roles should be able to add integration tests and so GitHub pull requests with integration tests that show bugs in action will also be a great way to help." -msgstr "開発者ではなくても、バグの修正や機能のプル要求のテストを手伝うことは非常に価値のあることです。Ansible ユーザーが Playbook やロールの書き方を熟知していれば統合テストを追加できるため、バグが実際に動かしている様子を示す統合テストが付いた GitHub プル要求も、大きな助けになるでしょう。" - -#: ../../rst/dev_guide/testing.rst:55 -msgid "Testing within GitHub & Shippable" -msgstr "GitHub および Shippable でのテスト" - -#: ../../rst/dev_guide/testing.rst:59 -msgid "Organization" -msgstr "組織" - -#: ../../rst/dev_guide/testing.rst:61 -msgid "When Pull Requests (PRs) are created they are tested using Shippable, a Continuous Integration (CI) tool. Results are shown at the end of every PR." -msgstr "プル要求 (PR: Pull Requests) が作成されると、継続的インテグレーション (CI) ツールである Shippable を使用してテストが行われます。結果はすべての PR の最後に表示されます。" - -#: ../../rst/dev_guide/testing.rst:63 -msgid "When Shippable detects an error and it can be linked back to a file that has been modified in the PR then the relevant lines will be added as a GitHub comment. For example::" -msgstr "Saltppable がエラーを検出し、それが PR で変更されたファイルにリンクされると、関連する行が GitHub のコメントとして追加されます。たとえば、以下のようになります。" - -#: ../../rst/dev_guide/testing.rst:72 -msgid "From the above example we can see that ``--test pep8`` and ``--test validate-modules`` have identified an issue. The commands given allow you to run the same tests locally to ensure you've fixed all issues without having to push your changes to GitHub and wait for Shippable, for example:" -msgstr "上記の例から、``--test pep8`` および ``--test validate-modules`` が問題を特定したことが分かります。与えられたコマンドを使用すると、同じテストをローカルで実行して、変更を GitHub にプッシュして Shippable を待つことなく、すべての問題を修正したことを確認できます。次に例を示します。" - -#: ../../rst/dev_guide/testing.rst:74 -msgid "If you haven't already got Ansible available, use the local checkout by running::" -msgstr "Ansible がまだ利用できるようになっていない場合は、ローカルでチェックアウトを実行してください。" - -#: ../../rst/dev_guide/testing.rst:78 -msgid "Then run the tests detailed in the GitHub comment::" -msgstr "次に、GitHub コメントで説明するテストを実行します。" - -#: ../../rst/dev_guide/testing.rst:83 -msgid "If there isn't a GitHub comment stating what's failed you can inspect the results by clicking on the \"Details\" button under the \"checks have failed\" message at the end of the PR." -msgstr "GitHub のコメントに何が失敗したかが書かれていない場合は、PR の末尾にある「checks have failed」というメッセージの下にある「Details」ボタンをクリックして結果を確認することができます。" - -#: ../../rst/dev_guide/testing.rst:86 -msgid "Rerunning a failing CI job" -msgstr "失敗した CI ジョブの再実行" - -#: ../../rst/dev_guide/testing.rst:88 -msgid "Occasionally you may find your PR fails due to a reason unrelated to your change. This could happen for several reasons, including:" -msgstr "時折、変更とは関係のない理由で PR が失敗することがあります。これには、以下のような理由が考えられます。" - -#: ../../rst/dev_guide/testing.rst:90 -msgid "a temporary issue accessing an external resource, such as a yum or git repo" -msgstr "yum や git リポジトリーなどの外部リソースにアクセスする際に一時的に問題が発生した場合。" - -#: ../../rst/dev_guide/testing.rst:91 -msgid "a timeout creating a virtual machine to run the tests on" -msgstr "テストを実行するための仮想マシンを作成するタイムアウト。" - -#: ../../rst/dev_guide/testing.rst:93 -msgid "If either of these issues appear to be the case, you can rerun the Shippable test by:" -msgstr "いずれかの問題が発生しているようであれば、以下の方法で Shippable テストを再実行できます。" - -#: ../../rst/dev_guide/testing.rst:95 -msgid "adding a comment with ``/rebuild`` (full rebuild) or ``/rebuild_failed`` (rebuild only failed CI nodes) to the PR" -msgstr "``/rebuild`` (完全な再構築) または ``/rebuild_failed`` (ビルドに失敗した CI ノードのみ) でのコメントの追加" - -#: ../../rst/dev_guide/testing.rst:96 -msgid "closing and re-opening the PR (full rebuild)" -msgstr "PR を閉じて再度開く (完全な再構築)" - -#: ../../rst/dev_guide/testing.rst:97 -msgid "making another change to the PR and pushing to GitHub" -msgstr "PR に何らかの変更を加えて GitHub にプッシュする。" - -#: ../../rst/dev_guide/testing.rst:99 -msgid "If the issue persists, please contact us in ``#ansible-devel`` on Freenode IRC." -msgstr "問題が解決しない場合は、Freenode IRC の ``#ansible-devel`` にお問い合わせください。" - -#: ../../rst/dev_guide/testing.rst:103 -msgid "How to test a PR" -msgstr "PR をテストする方法" - -#: ../../rst/dev_guide/testing.rst:105 -msgid "Ideally, code should add tests that prove that the code works. That's not always possible and tests are not always comprehensive, especially when a user doesn't have access to a wide variety of platforms, or is using an API or web service. In these cases, live testing against real equipment can be more valuable than automation that runs against simulated interfaces. In any case, things should always be tested manually the first time as well." -msgstr "理想的には、コードが機能することを証明するテストを追加することが推奨されます。特に、ユーザーが様々なプラットフォームにアクセスできない場合、または API や Web サービスを使用している場合は、これが必ずしも可能ではなく、テストも必ずしも包括的ではありません。このような場合は、シミュレーションされたインターフェースに対して実行される自動化よりも、実際の機器を使用したライブテストの方が有益でしょう。いずれにせよ、最初の段階でも常に手動でテストする必要があります。" - -#: ../../rst/dev_guide/testing.rst:107 -msgid "Thankfully, helping to test Ansible is pretty straightforward, assuming you are familiar with how Ansible works." -msgstr "Ansible の動作を熟知していれば、Ansible のテストを手伝うことは非常に簡単です。" - -#: ../../rst/dev_guide/testing.rst:110 -msgid "Setup: Checking out a Pull Request" -msgstr "設定: プル要求のチェック" - -#: ../../rst/dev_guide/testing.rst:112 -msgid "You can do this by:" -msgstr "これは、以下の方法で実行できます。" - -#: ../../rst/dev_guide/testing.rst:114 -msgid "checking out Ansible" -msgstr "Ansible のチェックアウト" - -#: ../../rst/dev_guide/testing.rst:115 -msgid "fetching the proposed changes into a test branch" -msgstr "テストブランチへの提案された変更の取得" - -#: ../../rst/dev_guide/testing.rst:116 -msgid "testing" -msgstr "テスト" - -#: ../../rst/dev_guide/testing.rst:117 -msgid "commenting on that particular issue on GitHub" -msgstr "GitHub に特定の問題についてのコメント" - -#: ../../rst/dev_guide/testing.rst:119 -msgid "Here's how:" -msgstr "以下に、実行する方法を説明します。" - -#: ../../rst/dev_guide/testing.rst:122 -msgid "Testing source code from GitHub pull requests sent to us does have some inherent risk, as the source code sent may have mistakes or malicious code that could have a negative impact on your system. We recommend doing all testing on a virtual machine, whether a cloud instance, or locally. Some users like Vagrant or Docker for this, but they are optional. It is also useful to have virtual machines of different Linux or other flavors, since some features (for example, package managers such as apt or yum) are specific to those OS versions." -msgstr "GitHub のプル要求から送られてきたソースコードをテストすることにはリスクが伴います。送られてきたソースコードには、間違いや悪意のあるコードが含まれていて、システムに影響を及ぼす可能性があるからです。すべてのテストは、仮想マシン上で行うことが推奨されます。クラウドインスタンスでもローカルでもかまいません。このために Vagrant や Docker を好むユーザーもいますが、これらは任意です。また、いくつかの機能 (たとえば、apt や yum などのパッケージマネージャー) は、それらの OS バージョンに固有のものであるため、異なる Linux やその他のフレーバーの仮想マシンを用意しておくと便利です。" - -#: ../../rst/dev_guide/testing.rst:129 -msgid "Create a fresh area to work::" -msgstr "作業用に新しい領域を作成します::" - -#: ../../rst/dev_guide/testing.rst:135 -msgid "Next, find the pull request you'd like to test and make note of its number. It will look something like this::" -msgstr "次に、テストするプル要求を見つけて、その番号を書き留めます。次のようになります。" - -#: ../../rst/dev_guide/testing.rst:139 -msgid "Only test ``ansible:devel``" -msgstr "``ansible:devel`` のみをテストします。" - -#: ../../rst/dev_guide/testing.rst:141 -msgid "It is important that the PR request target be ``ansible:devel``, as we do not accept pull requests into any other branch. Dot releases are cherry-picked manually by Ansible staff." -msgstr "他のブランチへのプル要求は使用できないため、PR 要求のターゲットは ``ansible:devel`` にすることが重要です。ドットリリースは、Ansible のスタッフが入念に選択しています。" - -#: ../../rst/dev_guide/testing.rst:143 -msgid "Use the pull request number when you fetch the proposed changes and create your branch for testing::" -msgstr "提案された変更を取得し、テスト用にブランチを作成するときにプル要求番号を使用します。" - -#: ../../rst/dev_guide/testing.rst:148 -msgid "The first command fetches the proposed changes from the pull request and creates a new branch named ``testing_PRXXXX``, where the XXXX is the actual number associated with the pull request (for example, 65381). The second command checks out the newly created branch." -msgstr "1 つ目のコマンドはプル要求から提案された変更を取得し、``testing_PRXXXX`` という名前の新規ブランチを作成します。ここで、XXXX はプル要求に関連する実際の番号 (例: 65381) です。2 つ目のコマンドは、新たに作成されたブランチをチェックアウトします。" - -#: ../../rst/dev_guide/testing.rst:151 -msgid "If the GitHub user interface shows that the pull request will not merge cleanly, we do not recommend proceeding if you are not somewhat familiar with git and coding, as you will have to resolve a merge conflict. This is the responsibility of the original pull request contributor." -msgstr "GitHub ユーザーインターフェースで、プル要求が正常にマージされないと示された場合は、マージの競合を解決しなければならないため、git およびコーディングにあまり精通していない場合は、続行しないことが推奨されます。これは、元のプル要求の投稿者の責任です。" - -#: ../../rst/dev_guide/testing.rst:154 -msgid "Some users do not create feature branches, which can cause problems when they have multiple, unrelated commits in their version of ``devel``. If the source looks like ``someuser:devel``, make sure there is only one commit listed on the pull request." -msgstr "一部のユーザーは機能ブランチを作成しないため、``devel`` のバージョンに関連性のないコミットが複数ある場合に、問題が発生する可能性があります。ソースが ``someuser:devel`` のように表示される場合は、プル要求に記載されているコミットが 1 つだけであることを確認してください。" - -#: ../../rst/dev_guide/testing.rst:156 -msgid "The Ansible source includes a script that allows you to use Ansible directly from source without requiring a full installation that is frequently used by developers on Ansible." -msgstr "Ansible のソースには、Ansible の開発者が頻繁に使用するフルインストールを必要とせず、ソースから直接 Ansible を使えるようにするスクリプトが含まれています。" - -#: ../../rst/dev_guide/testing.rst:159 -msgid "Simply source it (to use the Linux/Unix terminology) to begin using it immediately::" -msgstr "ソースを作成するだけ (Linux/Unix の用語を使用するために) で、すぐに使い始めることができます。" - -#: ../../rst/dev_guide/testing.rst:163 -msgid "This script modifies the ``PYTHONPATH`` environment variables (along with a few other things), which will be temporarily set as long as your shell session is open." -msgstr "このスクリプトは、``PYTHONPATH`` 環境変数を変更します (他にもいくつかあります)。これは、シェルセッションが開いている間は一時的に設定されます。" - -#: ../../rst/dev_guide/testing.rst:167 -msgid "Testing the Pull Request" -msgstr "プル要求のテスト" - -#: ../../rst/dev_guide/testing.rst:169 -msgid "At this point, you should be ready to begin testing!" -msgstr "この時点でテストを開始する準備が整いました。" - -#: ../../rst/dev_guide/testing.rst:171 -msgid "Some ideas of what to test are:" -msgstr "何をテストするかのアイデアをいくつか挙げてみましょう。" - -#: ../../rst/dev_guide/testing.rst:173 -msgid "Create a test Playbook with the examples in and check if they function correctly" -msgstr "例題を含むテスト Playbook を作成し、それらが正しく機能するかどうかを確認します。" - -#: ../../rst/dev_guide/testing.rst:174 -msgid "Test to see if any Python backtraces returned (that's a bug)" -msgstr "Python のバックトレースが返されているかどうかをテストします (これはバグです)。" - -#: ../../rst/dev_guide/testing.rst:175 -msgid "Test on different operating systems, or against different library versions" -msgstr "異なるオペレーティングシステムで、または異なるバージョンのライブラリーに対してテストします。" - -#: ../../rst/dev_guide/testing.rst:178 -msgid "Run sanity tests" -msgstr "健全性テストの実行" - -#: ../../rst/dev_guide/testing.rst:184 -msgid "More information: :ref:`testing_sanity`" -msgstr "詳細情報: :ref:`testing_sanity`" - -#: ../../rst/dev_guide/testing.rst:187 -msgid "Run unit tests" -msgstr "ユニットテストの実行" - -#: ../../rst/dev_guide/testing.rst:193 -msgid "More information: :ref:`testing_units`" -msgstr "詳細情報: :ref:`testing_units`" - -#: ../../rst/dev_guide/testing.rst:196 -msgid "Run integration tests" -msgstr "インテグレーションテストの実行" - -#: ../../rst/dev_guide/testing.rst:202 -msgid "More information: :ref:`testing_integration`" -msgstr "詳細情報: :ref:`testing_integration`" - -#: ../../rst/dev_guide/testing.rst:204 -msgid "Any potential issues should be added as comments on the pull request (and it's acceptable to comment if the feature works as well), remembering to include the output of ``ansible --version``" -msgstr "潜在的な問題があれば、プル要求にコメントを追加する必要があります (機能が正常に動作する場合もコメントしてもかまいません)。忘れずに ``ansible --version`` の出力を転載してください。" - -#: ../../rst/dev_guide/testing.rst:206 -msgid "Example::" -msgstr "例:" - -#: ../../rst/dev_guide/testing.rst:210 -msgid "If the PR does not resolve the issue, or if you see any failures from the unit/integration tests, just include that output instead:" -msgstr "PR が問題を解決しない場合や、ユニット/統合テストでエラーが発生した場合には、代わりにその出力を転載してください。" - -#: ../../rst/dev_guide/testing.rst -msgid "This change causes errors for me." -msgstr "この変更により、エラーが発生します。" - -#: ../../rst/dev_guide/testing.rst -msgid "When I ran this Ubuntu 16.04 it failed with the following:" -msgstr "When I ran this Ubuntu 16.04 it failed with the following:" - -#: ../../rst/dev_guide/testing.rst -msgid "\\```" -msgstr "\\```" - -#: ../../rst/dev_guide/testing.rst -msgid "some output" -msgstr "some output" - -#: ../../rst/dev_guide/testing.rst -msgid "StackTrace" -msgstr "StackTrace" - -#: ../../rst/dev_guide/testing.rst -msgid "some other output" -msgstr "some other output" - -#: ../../rst/dev_guide/testing.rst:223 -msgid "Code Coverage Online" -msgstr "オンラインのコードカバレージ" - -#: ../../rst/dev_guide/testing.rst:225 -msgid "`The online code coverage reports `_ are a good way to identify areas for testing improvement in Ansible. By following red colors you can drill down through the reports to find files which have no tests at all. Adding both integration and unit tests which show clearly how code should work, verify important Ansible functions and increase testing coverage in areas where there is none is a valuable way to help improve Ansible." -msgstr "`The online code coverage reports `_ は、Ansible でテストが向上する領域を特定するのが適切な方法です。赤い色に従うことで、レポートをドリルダウンして、テストがまったくないファイルを見つけることができます。コードがどのように機能するかを明確に示す統合テストとユニットテストの両方を追加し、重要な Ansible 関数を検証し、存在しない領域でのテスト範囲を拡大することは、Ansible の改善に役立つ貴重な方法です。" - -#: ../../rst/dev_guide/testing.rst:232 -msgid "The code coverage reports only cover the ``devel`` branch of Ansible where new feature development takes place. Pull requests and new code will be missing from the codecov.io coverage reports so local reporting is needed. Most ``ansible-test`` commands allow you to collect code coverage, this is particularly useful to indicate where to extend testing. See :ref:`testing_running_locally` for more information." -msgstr "コードカバレッジレポートは、新しい機能開発が行われる Ansible の ``devel`` ブランチのみを対象とします。プル要求および新規コードは codecov.io のカバレッジレポートから欠落し、ローカルレポートが必要になるようです。ほとんどの ``ansible-test`` コマンドでは、コードカバレッジを収集できます。詳細は、「:ref:`testing_running_locally`」を参照してください。" - -#: ../../rst/dev_guide/testing.rst:240 -msgid "Want to know more about testing?" -msgstr "テストに関する詳細情報" - -#: ../../rst/dev_guide/testing.rst:242 -msgid "If you'd like to know more about the plans for improving testing Ansible then why not join the `Testing Working Group `_." -msgstr "Ansible テストを改善する詳細な計画を確認したい場合は、`テストワーキンググループ `_ にご参加ください。" - -#: ../../rst/dev_guide/testing/sanity/action-plugin-docs.rst:2 -msgid "action-plugin-docs" -msgstr "action-plugin-docs" - -#: ../../rst/dev_guide/testing/sanity/action-plugin-docs.rst:4 -msgid "Each action plugin should have a matching module of the same name to provide documentation." -msgstr "各アクションプラグインには、ドキュメントを提供するモジュールと同じ名前のモジュールが必要です。" - -#: ../../rst/dev_guide/testing/sanity/ansible-doc.rst:2 -msgid "ansible-doc" -msgstr "ansible-doc" - -#: ../../rst/dev_guide/testing/sanity/ansible-doc.rst:4 -msgid "Verifies that ``ansible-doc`` can parse module documentation on all supported Python versions." -msgstr "``ansible-doc`` が、サポートされているすべての Python バージョンでモジュールドキュメントを解析できることを確認します。" - -#: ../../rst/dev_guide/testing/sanity/ansible-requirements.rst:2 -msgid "ansible-requirements" -msgstr "ansible-requirements" - -#: ../../rst/dev_guide/testing/sanity/ansible-requirements.rst:4 -msgid "``test/lib/ansible_test/_data/requirements/sanity.import-plugins.txt`` must be an identical copy of ``requirements.txt`` found in the project's root." -msgstr "``test/lib/ansible_test/_data/requirements/sanity.import-plugins.txt`` は、プロジェクトのルートにある ``requirements.txt`` と同じコピーである必要があります。" - -#: ../../rst/dev_guide/testing/sanity/ansible-var-precedence-check.rst:4 -msgid "ansible-var-precedence-check" -msgstr "ansible-var-precedence-check" - -#: ../../rst/dev_guide/testing/sanity/ansible-var-precedence-check.rst:6 -msgid "Check the order of precedence for Ansible variables against :ref:`ansible_variable_precedence`." -msgstr "「:ref:`ansible_variable_precedence`」で、Ansible 変数の優先順位の順序を確認します。" - -#: ../../rst/dev_guide/testing/sanity/azure-requirements.rst:4 -msgid "azure-requirements" -msgstr "azure-requirements" - -#: ../../rst/dev_guide/testing/sanity/azure-requirements.rst:6 -msgid "Update the Azure integration test requirements file when changes are made to the Azure packaging requirements file:" -msgstr "Azure パッケージ化の要件ファイルに変更が加えたら、Azure 統合テスト要件ファイルを更新します。" - -#: ../../rst/dev_guide/testing/sanity/bin-symlinks.rst:2 -msgid "bin-symlinks" -msgstr "bin-symlinks" - -#: ../../rst/dev_guide/testing/sanity/bin-symlinks.rst:4 -msgid "The ``bin/`` directory in Ansible must contain only symbolic links to executable files. These files must reside in the ``lib/ansible/`` or ``test/lib/ansible_test/`` directories." -msgstr "Ansible の ``bin/`` ディレクトリーには、実行ファイルへのシンボリックリンクのみが含まれている必要があります。これらのファイルは、``lib/ansible/`` ディレクトリーまたは ``test/lib/ansible_test/`` ディレクトリーに置かれている必要があります。" - -#: ../../rst/dev_guide/testing/sanity/bin-symlinks.rst:7 -msgid "This is required to allow ``ansible-test`` to work with containers and remote hosts when running from an installed version of Ansible." -msgstr "これは、インストール済みバージョンの Ansible から実行する際に、``ansible-test`` がコンテナーおよびリモートホストで動作できるようにするために必要です。" - -#: ../../rst/dev_guide/testing/sanity/bin-symlinks.rst:9 -msgid "Symlinks for each entry point in ``bin/`` must also be present in ``test/lib/ansible_test/_data/injector/``. Each symlink should point to the ``python.py`` script in the same directory. This facilitates running with the correct Python interpreter and enabling code coverage." -msgstr "``bin/`` の各エントリーポイントのシンボリックリンクも ``test/lib/ansible_test/_data/injector/`` に存在する必要があります。それぞれのシンボリックリンクは同じディレクトリー内の ``python.py`` スクリプトをポイントする必要があります。これにより、正しい Python インタープリターでの実行とコードのカバレッジの有効化が容易になります。" - -#: ../../rst/dev_guide/testing/sanity/boilerplate.rst:4 -msgid "boilerplate" -msgstr "boilerplate" - -#: ../../rst/dev_guide/testing/sanity/boilerplate.rst:6 -msgid "Most Python files should include the following boilerplate:" -msgstr "ほとんどの Python ファイルには以下の boilerplate が必要です。" - -#: ../../rst/dev_guide/testing/sanity/botmeta.rst:2 -msgid "botmeta" -msgstr "botmeta" - -#: ../../rst/dev_guide/testing/sanity/botmeta.rst:4 -msgid "Verifies that ``./github/BOTMETA.yml`` is valid." -msgstr "``./github/BOTMETA.yml`` が有効であることを確認します。" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:2 -msgid "changelog" -msgstr "changelog" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:4 -msgid "Basic linting of changelog fragments with `antsibull-changelog lint `_." -msgstr "`antsibull-changelog lint `_ を使用した changelog フラグメントの基本的な文法チェックです。" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:6 -msgid "One or more of the following sections are required:" -msgstr "以下のセクションが 1 つ以上必要です。" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:8 -msgid "major_changes" -msgstr "major_changes" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:9 -msgid "minor_changes" -msgstr "minor_changes" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:10 -msgid "breaking_changes" -msgstr "breaking_changes" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:11 -msgid "deprecated_features" -msgstr "deprecated_features" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:12 -msgid "removed_features" -msgstr "removed_features" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:13 -msgid "security_fixes" -msgstr "security_fixes" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:14 -msgid "bugfixes" -msgstr "bugfixes" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:15 -msgid "known_issues" -msgstr "known_issues" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:17 -msgid "New modules and plugins must not be included in changelog fragments." -msgstr "新しいモジュールおよびプラグインは、changelog フラグメントに含めることはできません。" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:4 -msgid "See :ref:`testing_compile` for more information." -msgstr "詳細は、「:ref:`testing_compile`」を参照してください。" - -#: ../../rst/dev_guide/testing/sanity/configure-remoting-ps1.rst:2 -msgid "configure-remoting-ps1" -msgstr "configure-remoting-ps1" - -#: ../../rst/dev_guide/testing/sanity/configure-remoting-ps1.rst:4 -msgid "The file ``examples/scripts/ConfigureRemotingForAnsible.ps1`` is required and must be a regular file. It is used by external automated processes and cannot be moved, renamed or replaced with a symbolic link." -msgstr "``examples/scripts/ConfigureRemotingForAnsible.ps1`` ファイルは必須であり、通常のファイルである必要があります。これは外部の自動化プロセスによって使用され、移動したり、名前を変更したり、シンボリックリンクに置き換えたりすることはできません。" - -#: ../../rst/dev_guide/testing/sanity/deprecated-config.rst:4 -msgid "deprecated-config" -msgstr "非推奨の設定" - -#: ../../rst/dev_guide/testing/sanity/deprecated-config.rst:6 -msgid "``DOCUMENTATION`` config is scheduled for removal" -msgstr "``DOCUMENTATION`` 設定は削除される予定です。" - -#: ../../rst/dev_guide/testing/sanity/docs-build.rst:2 -msgid "docs-build" -msgstr "docs-build" - -#: ../../rst/dev_guide/testing/sanity/docs-build.rst:4 -msgid "Verifies that ``make singlehtmldocs`` in ``docs/docsite/`` completes without errors." -msgstr "エラーなしで ``docs/docsite/`` で ``make singlehtmldocs`` が完了していることを確認します。" - -#: ../../rst/dev_guide/testing/sanity/empty-init.rst:2 -msgid "empty-init" -msgstr "empty-init" - -#: ../../rst/dev_guide/testing/sanity/empty-init.rst:4 -msgid "The ``__init__.py`` files under the following directories must be empty. For some of these (modules and tests), ``__init__.py`` files with code won't be used. For others (module_utils), we want the possibility of using Python namespaces which an empty ``__init__.py`` will allow for." -msgstr "以下のディレクトリーにある ``__init__.py`` ファイルは空である必要があります。これらのディレクトリーの一部 (モジュールおよびテスト) では、コードを持つ ``__init__.py`` ファイルは使用されません。他の (module_utils) 場合は、空の ``__init__.py`` を許可する Python 名前空間を使用することも可能です。" - -#: ../../rst/dev_guide/testing/sanity/empty-init.rst:8 -msgid "``lib/ansible/modules/``" -msgstr "``lib/ansible/modules/``" - -#: ../../rst/dev_guide/testing/sanity/empty-init.rst:9 -msgid "``lib/ansible/module_utils/``" -msgstr "``lib/ansible/module_utils/``" - -#: ../../rst/dev_guide/testing/sanity/empty-init.rst:10 -msgid "``test/units/``" -msgstr "``test/units/``" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:2 -msgid "future-import-boilerplate" -msgstr "future-import-boilerplate" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:4 -msgid "Most Python files should include the following boilerplate at the top of the file, right after the comment header:" -msgstr "ほとんどの Python ファイルには、ファイルの上部、コメントヘッダーの直後に次の boilerplate を含める必要があります。" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:11 -msgid "This uses Python 3 semantics for absolute vs relative imports, division, and print. By doing this, we can write code which is portable between Python 2 and Python 3 by following the Python 3 semantics." -msgstr "ここでは、絶対的インポートと相対的インポート、除算、および出力に Python 3 セマンティクスを使用します。Python 3 セマンティクスに従って、Python 2 と Python 3 の間で移植可能なコードを作成できます。" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:18 -msgid "When Python 2 encounters an import of a name in a file like ``import copy`` it attempts to load ``copy.py`` from the same directory as the file is in. This can cause problems if there is a python file of that name in the directory and also a python module in ``sys.path`` with that same name. In that case, Python 2 would load the one in the same directory and there would be no way to load the one on ``sys.path``. Python 3 fixes this by making imports absolute by default. ``import copy`` will find ``copy.py`` from ``sys.path``. If you want to import ``copy.py`` from the same directory, the code needs to be changed to perform a relative import: ``from . import copy``." -msgstr "Python 2 は、``import copy`` のようなファイルで名前の import に遭遇すると、そのファイルがあるのと同じディレクトリーから ``copy.py`` を読み込もうとします。これは、そのディレクトリーにその名前の python ファイルがあり、``sys.path`` にも同じ名前の python モジュールがある場合に問題が発生します。その場合、Python 2 は同じディレクトリーにあるものをロ読み込み、``sys.path`` にあるものを読み込む方法がありません。Python 3 は、デフォルトでインポートを行うようにすることでこの問題を解決しました。``import copy`` は、``sys.path`` から ``copy.py`` を見つけます。同じディレクトリーから ``copy.py`` をインポートしたい場合は、相対インポートを行うようにコードを変更する必要があります (``from . import copy``.)。" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:28 -msgid "`Absolute and relative imports `_" -msgstr "`Absolute and relative imports `_" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:33 -msgid "In Python 2, the division operator (``/``) returns integer values when used with integers. If there was a remainder, this part would be left off (aka, `floor division`). In Python 3, the division operator (``/``) always returns a floating point number. Code that needs to calculate the integer portion of the quotient needs to switch to using the floor division operator (`//`) instead." -msgstr "Python 2 では、整数と共に使用する場合に、除算演算子 (``/``) は整数値を返します。残りの部分がある場合、この部分はオフ (別名 `切り捨て除算`) のままにします。Python 3 では、除算演算子 (``/``) は常に浮動小数点数を返します。引用符で整数を計算する必要のあるコードは、代わりに切り捨て除算演算子 (`//`) の使用に切り替える必要があります。" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:40 -msgid "`Changing the division operator `_" -msgstr "`Changing the division operator `_" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:45 -msgid "In Python 2, :func:`python:print` is a keyword. In Python 3, :func:`python3:print` is a function with different parameters. Using this ``__future__`` allows using the Python 3 print semantics everywhere." -msgstr "Python 2 では、:func:`python:print` はキーワードです。Python 3 では、 :func:`python3:print` は異なるパラメーターを持つ機能です。この ``__future__`` を使用すると、あらゆる場所に Python 3 出力セマンティクスを使用できます。" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:50 -msgid "`Make print a function `_" -msgstr "`Make print a function `_" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:2 -msgid "ignores" -msgstr "ignore" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:4 -msgid "Sanity tests for individual files can be skipped, and specific errors can be ignored." -msgstr "個々のファイルで健全性テストをスキップしたり、特定のエラーを無視したりできます。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:7 -msgid "When to Ignore Errors" -msgstr "エラーを無視するタイミング" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:9 -msgid "Sanity tests are designed to improve code quality and identify common issues with content. When issues are identified during development, those issues should be corrected." -msgstr "健全性テストは、コードの品質を改善し、コンテンツに関する典型的な問題を特定するように設計されています。開発中に問題を特定する際に、問題を修正する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:12 -msgid "As development of Ansible continues, sanity tests are expanded to detect issues that previous releases could not. To allow time for existing content to be updated to pass newer tests, ignore entries can be added. New content should not use ignores for existing sanity tests." -msgstr "Ansible の開発が続くにつれて、健全性テストが拡張され、以前のリリースでは検出できなかった問題が検出されます。既存のコンテンツを更新して新しいテストに合格するための時間を確保するために、ignore エントリーを追加できます。新しいコンテンツでは、既存の健全性テストで ignore を使用しないでください。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:16 -msgid "When code is fixed to resolve sanity test errors, any relevant ignores must also be removed. If the ignores are not removed, this will be reported as an unnecessary ignore error. This is intended to prevent future regressions due to the same error recurring after being fixed." -msgstr "コードが修正されて健全性テストエラーを解決する場合には、関連する ignore も削除する必要があります。ignore が削除されないと、不要な ignore エラーが報告されます。これは、修正後に同じエラーが繰り返し発生するため、今後のリグレッションを防ぐことを目的としています。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:21 -msgid "When to Skip Tests" -msgstr "テストをスキップするタイミング" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:23 -msgid "Although rare, there are reasons for skipping a sanity test instead of ignoring the errors it reports." -msgstr "頻繁には起こりませんが、報告されたエラーを無視する代わりに、健全性テストをスキップする場合があります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:25 -msgid "If a sanity test results in a traceback when processing content, that error cannot be ignored. If this occurs, open a new `bug report `_ for the issue so it can be fixed. If the traceback occurs due to an issue with the content, that issue should be fixed. If the content is correct, the test will need to be skipped until the bug in the sanity test is fixed." -msgstr "健全性テストにより、コンテンツの処理時にトレースバックが発生すると、そのエラーは無視できません。このような場合には、新しい `バグレポート `_ を作成し、問題を修正してください。コンテンツに問題があるためにトレースバックが発生した場合は、その問題を修正する必要があります。コンテンツが正しい場合は、健全性テストのバグが修正されるまで、テストをスキップする必要があります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:30 -msgid "Caution should be used when skipping sanity tests instead of ignoring them. Since the test is skipped entirely, resolution of the issue will not be automatically detected. This will prevent prevent regression detection from working once the issue has been resolved. For this reason it is a good idea to periodically review skipped entries manually to verify they are required." -msgstr "健全性テストを無視するのではなくスキップする場合は注意が必要です。テストは完全にスキップされるため、問題の解決が自動的に検出されません。これにより、問題が解決すると回帰検出が機能しなくなります。このため、スキップしたエントリーを定期的に手動で確認して、そのエントリーが必要かどうかを確認することが推奨されます。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:36 -msgid "Ignore File Location" -msgstr "ignore ファイルの場所" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:38 -msgid "The location of the ignore file depends on the type of content being tested." -msgstr "ignore ファイルの場所は、テストするコンテンツの種類によって異なります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:41 -msgid "Ansible Collections" -msgstr "Ansible コレクション" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:43 -msgid "Since sanity tests change between Ansible releases, a separate ignore file is needed for each Ansible major release." -msgstr "健全性テストは Ansible リリース間で異なるため、Ansible メジャーリリースごとに個別の ignore ファイルが必要です。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:45 -msgid "The filename is ``tests/sanity/ignore-X.Y.txt`` where ``X.Y`` is the Ansible release being used to test the collection." -msgstr "ファイル名は ``tests/sanity/ignore-X.Y.txt`` です。``X.Y`` は、コレクションをテストするために使用される Ansible リリースです。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:47 -msgid "Maintaining a separate file for each Ansible release allows a collection to pass tests for multiple versions of Ansible." -msgstr "Ansible リリースごとに個別のファイルを維持すると、コレクションが Ansible の複数のバージョンのテストに合格できるようになります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:52 -msgid "When testing Ansible, all ignores are placed in the ``test/sanity/ignore.txt`` file." -msgstr "Ansible をテストする際、すべての ignore は ``test/sanity/ignore.txt`` ファイルに配置されます。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:54 -msgid "Only a single file is needed because ``ansible-test`` is developed and released as a part of Ansible itself." -msgstr "``ansible-test`` が作成され、Ansible 自体の一部としてリリースされるため、単一のファイルのみが必要になります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:57 -msgid "Ignore File Format" -msgstr "ignore ファイル形式" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:59 -msgid "The ignore file contains one entry per line. Each line consists of two columns, separated by a single space. Comments may be added at the end of an entry, started with a hash (``#``) character, which can be proceeded by zero or more spaces. Blank and comment only lines are not allowed." -msgstr "ignore ファイルでは、1 行に 1 つのエントリーが含まれます。各行は、1 つのスペースで区切られた 2 つの列で構成されます。コメントはエントリーの末尾に追加できます。先頭にハッシュ (``#``) 文字を付けて、ゼロ以上の空白を追加できます。空白とコメントのみの行は使用できません。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:64 -msgid "The first column specifies the file path that the entry applies to. File paths must be relative to the root of the content being tested. This is either the Ansible source or an Ansible collection. File paths cannot contain a space or the hash (``#``) character." -msgstr "最初の列は、エントリーが適用されるファイルパスを指定します。ファイルパスは、テストするコンテンツのルートに対して相対的である必要があります。これは Ansible ソースまたは Ansible コレクションのいずれかです。ファイルパスにスペースまたはハッシュ (``#``) 文字を含めることはできません。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:69 -msgid "The second column specifies the sanity test that the entry applies to. This will be the name of the sanity test. If the sanity test is specific to a version of Python, the name will include a dash (``-``) and the relevant Python version. If the named test uses error codes then the error code to ignore must be appended to the name of the test, separated by a colon (``:``)." -msgstr "2 列目は、エントリーが適用される健全性テストを指定します。これが健全性テストの名前になります。Python のバージョンに固有の健全性テストを使用する場合は、名前にダッシュ (``-``) と関連する Python バージョンが含まれます。名前付きテストがエラーコードを使用する場合は、無視するエラーコードをコロン (``:``) で区切ってテストの名前に追加する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:74 -msgid "Below are some example ignore entries for an Ansible collection::" -msgstr "以下の例は、Ansible コレクションのエントリーを無視します。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:80 -msgid "It is also possible to skip a sanity test for a specific file. This is done by adding ``!skip`` after the sanity test name in the second column. When this is done, no error code is included, even if the sanity test uses error codes." -msgstr "特定ファイルの健全性テストをスキップすることもできます。これは、2 番目のコラムの健全性テスト名の後に ``!skip`` を追加することで行います。これを行うと、健全性テストでエラーコードを使用しても、エラーコードは含まれません。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:84 -msgid "Below are some example skip entries for an Ansible collection::" -msgstr "以下は、Ansible コレクションのエントリーをスキップする例です。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:90 -msgid "Ignore File Errors" -msgstr "ignore ファイルエラー" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:92 -msgid "There are various errors that can be reported for the ignore file itself:" -msgstr "ignore ファイル自体について報告できるさまざまなエラーがあります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:94 -msgid "syntax errors parsing the ignore file" -msgstr "ignore ファイルを解析する構文エラー" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:95 -msgid "references a file path that does not exist" -msgstr "存在しないファイルパスを参照" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:96 -msgid "references to a sanity test that does not exist" -msgstr "存在しない健全性テストへの参照" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:97 -msgid "ignoring an error that does not occur" -msgstr "発生しないエラーを無視" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:98 -msgid "ignoring a file which is skipped" -msgstr "省略されるファイルを無視" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:99 -msgid "duplicate entries" -msgstr "重複エントリー" - -#: ../../rst/dev_guide/testing/sanity/import.rst:2 -msgid "import" -msgstr "import" - -#: ../../rst/dev_guide/testing/sanity/import.rst:4 -msgid "Ansible allows unchecked imports of some libraries from specific directories, listed at the bottom of this section. Import all other Python libraries in a try/except ImportError block to support sanity tests such as ``validate-modules`` and to allow Ansible to give better error messages to the user. To import a library in a try/except ImportError block:" -msgstr "Ansible では、このセクションの下部に記載されている特定のディレクトリーから、いくつかのライブラリーを確認せずにインポートすることができます。``validate-modules`` などの健全性テストをサポートし、Ansible がユーザーに適切なエラーメッセージを表示できるようにするため、try/except ImportError ブロックで他のすべての Python ライブラリーをインポートします。try/except ImportError ブロックでライブラリをインポートするには、次を行います。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:6 -msgid "In modules:" -msgstr "モジュールの場合:" - -#: ../../rst/dev_guide/testing/sanity/import.rst:33 -msgid "In plugins:" -msgstr "プラグインの場合:" - -#: ../../rst/dev_guide/testing/sanity/import.rst:58 -msgid "Ansible allows the following unchecked imports from these specific directories:" -msgstr "Ansible では、これらの特定のディレクトリーから次の確認されていないインポートを許可します。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:60 -msgid "ansible-core:" -msgstr "ansible-core:" - -#: ../../rst/dev_guide/testing/sanity/import.rst:62 -msgid "For ``lib/ansible/modules/`` and ``lib/ansible/module_utils/``, unchecked imports are only allowed from the Python standard library;" -msgstr "``lib/ansible/modules/`` および ``lib/ansible/module_utils/`` の場合、チェックされていないインポートは Python 標準ライブラリーでのみ利用可能です。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:63 -msgid "For ``lib/ansible/plugins/``, unchecked imports are only allowed from the Python standard library, from dependencies of ansible-core, and from ansible-core itself;" -msgstr "``lib/ansible/plugins/`` では、確認されていないインポートは、Python 標準ライブラリー、ansible-core の依存関係、および ansible-core 自体からのみ許可されます。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:65 -msgid "collections:" -msgstr "collections:" - -#: ../../rst/dev_guide/testing/sanity/import.rst:67 -msgid "For ``plugins/modules/`` and ``plugins/module_utils/``, unchecked imports are only allowed from the Python standard library;" -msgstr "``plugins/modules/`` および ``plugins/module_utils/`` の場合、チェックされていないインポートは Python 標準ライブラリーでのみ利用可能です。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:68 -msgid "For other directories in ``plugins/`` (see `the community collection requirements `_ for a list), unchecked imports are only allowed from the Python standard library, from dependencies of ansible-core, and from ansible-core itself." -msgstr "``plugins/`` のその他のディレクトリー (一覧は「`コミュニティーコレクション要件 `_」を参照) では、チェックされていないインポートは Python 標準ライブラリー、ansible-core の依存関係、および ansible-core 自体からのみ許可されます。" - -#: ../../rst/dev_guide/testing/sanity/index.rst:4 -#: ../../rst/dev_guide/testing_sanity.rst:7 -msgid "Sanity Tests" -msgstr "サニティーテスト" - -#: ../../rst/dev_guide/testing/sanity/index.rst:6 -msgid "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``." -msgstr "以下の健全性テストは、``ansible-test sanity`` の ``--test`` オプションとして利用できます。この一覧は、``ansible-test sanity --list-tests --allow-disabled`` を使用しても利用できます。" - -#: ../../rst/dev_guide/testing/sanity/index.rst:9 -msgid "For information on how to run these tests, see :ref:`sanity testing guide `." -msgstr "これらのテストの実行方法は、:ref:`サニティーテストガイド ` を参照してください。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:2 -msgid "integration-aliases" -msgstr "integration-aliases" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:4 -msgid "Integration tests are executed by ``ansible-test`` and reside in directories under ``test/integration/targets/``. Each test MUST have an ``aliases`` file to control test execution." -msgstr "統合テストは ``ansible-test`` によって実行し、``test/integration/targets/`` 配下のディレクトリーに置かれます。各テストには、テストの実行を制御する ``aliases`` ファイルが必要です。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:7 -msgid "Aliases are explained in the following sections. Each alias must be on a separate line in an ``aliases`` file." -msgstr "エイリアスは、以下のセクションで説明します。各エイリアスは、``aliases`` ファイルの別の行に指定する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:10 -msgid "Groups" -msgstr "グループ" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:12 -msgid "Tests must be configured to run in exactly one group. This is done by adding the appropriate group to the ``aliases`` file." -msgstr "テストは 1 つのグループで実行するように設定する必要があります。これは、適切なグループを ``aliases`` ファイルに追加することで行われます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:14 -msgid "The following are examples of some of the available groups:" -msgstr "利用可能な一部のグループの例を以下に示します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:16 -msgid "``shippable/posix/group1``" -msgstr "``shippable/posix/group1``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:17 -msgid "``shippable/windows/group2``" -msgstr "``shippable/windows/group2``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:18 -msgid "``shippable/azure/group3``" -msgstr "``shippable/azure/group3``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:19 -msgid "``shippable/aws/group1``" -msgstr "``shippable/aws/group1``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:20 -msgid "``shippable/cloud/group1``" -msgstr "``shippable/cloud/group1``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:22 -msgid "Groups are used to balance tests across multiple CI jobs to minimize test run time. They also improve efficiency by keeping tests with similar requirements running together." -msgstr "グループは、複数の CI ジョブ間でテストのバランスを取り、テストのランタイムを最小限にするために使用します。同様の要件が一緒に実行されるテストを維持することで、効率性も向上します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:25 -msgid "When selecting a group for a new test, use the same group as existing tests similar to the one being added. If more than one group is available, select one randomly." -msgstr "新規テスト用にグループを選択する場合は、追加するテストと同様のグループを使用します。複数のグループが利用可能な場合は、ランダムに 1 つのグループを選択します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:29 -msgid "Setup" -msgstr "設定" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:31 -msgid "Aliases can be used to execute setup targets before running tests:" -msgstr "エイリアスは、テストを実行する前に設定ターゲットを実行するのに使用できます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:33 -msgid "``setup/once/TARGET`` - Run the target ``TARGET`` before the first target that requires it." -msgstr "``setup/once/TARGET`` - それが必要な最初のターゲットの前に、ターゲット ``TARGET`` を実行します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:34 -msgid "``setup/always/TARGET`` - Run the target ``TARGET`` before each target that requires it." -msgstr "``setup/always/TARGET`` - 必要な各ターゲットの前にターゲット ``TARGET`` を実行します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:39 -msgid "Aliases can be used to express some test requirements:" -msgstr "エイリアスを使用すると、一部のテスト要件を表現することができます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:41 -msgid "``needs/privileged`` - Requires ``--docker-privileged`` when running tests with ``--docker``." -msgstr "``needs/privileged`` - ``--docker`` でテストを実行する場合は、``--docker-privileged`` が必要です。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:42 -msgid "``needs/root`` - Requires running tests as ``root`` or with ``--docker``." -msgstr "``needs/root`` - ``root`` または ``--docker`` でテストを実行する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:43 -msgid "``needs/ssh`` - Requires SSH connections to localhost (or the test container with ``--docker``) without a password." -msgstr "``needs/ssh`` - パスワードなしで localhost (または ``--docker`` を使用したテストコンテナー) への SSH 接続を必要とします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:44 -msgid "``needs/httptester`` - Requires use of the http-test-container to run tests." -msgstr "``needs/httptester`` - テストを実行するには、http-test-container を使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:47 -msgid "Dependencies" -msgstr "依存関係" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:49 -msgid "Some test dependencies are automatically discovered:" -msgstr "一部のテスト依存関係は自動的に検出されます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:51 -msgid "Ansible role dependencies defined in ``meta/main.yml`` files." -msgstr "``meta/main.yml`` ファイルで定義される Ansible ロールの依存関係。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:52 -msgid "Setup targets defined with ``setup/*`` aliases." -msgstr "``setup/*`` エイリアスで定義されたターゲットのセットアップ。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:53 -msgid "Symbolic links from one target to a file in another target." -msgstr "あるターゲットから別のターゲットのファイルへのシンボリックリンク。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:55 -msgid "Aliases can be used to declare dependencies that are not handled automatically:" -msgstr "エイリアスを使用すると、自動的に処理されない依存関係を宣言できます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:57 -msgid "``needs/target/TARGET`` - Requires use of the test target ``TARGET``." -msgstr "``needs/target/TARGET`` - テストターゲット ``TARGET`` を使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:58 -msgid "``needs/file/PATH`` - Requires use of the file ``PATH`` relative to the git root." -msgstr "``needs/file/PATH`` - git ルートとの関連ファイル ``PATH`` を使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:61 -msgid "Skipping" -msgstr "スキップ" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:63 -msgid "Aliases can be used to skip platforms using one of the following:" -msgstr "エイリアスを使用すると、以下のいずれかを使用してプラットフォームをスキップできます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:65 -msgid "``skip/freebsd`` - Skip tests on FreeBSD." -msgstr "``skip/freebsd`` - FreeBSD のテストを省略します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:66 -msgid "``skip/osx`` - Skip tests on macOS." -msgstr "``skip/osx`` - macOS でのテストを省略します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:67 -msgid "``skip/rhel`` - Skip tests on RHEL." -msgstr "``skip/rhel`` - RHEL でのテストを省略します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:68 -msgid "``skip/docker`` - Skip tests when running in a Docker container." -msgstr "``skip/docker`` - Docker コンテナーで実行する場合はテストをスキップします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:70 -msgid "Platform versions, as specified using the ``--remote`` option with ``/`` removed, can also be skipped:" -msgstr "``--remote`` オプションで ``/`` を削除して指定したプラットフォームバージョンもスキップできます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:72 -msgid "``skip/freebsd11.1`` - Skip tests on FreeBSD 11.1." -msgstr "``skip/freebsd11.1`` - FreeBSD 11.1 のテストをスキップします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:73 -msgid "``skip/rhel7.6`` - Skip tests on RHEL 7.6." -msgstr "``skip/rhel7.6`` - RHEL 7.6 でのテストを省略します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:75 -msgid "Windows versions, as specified using the ``--windows`` option can also be skipped:" -msgstr "``--windows`` オプションを使用して指定する Windows バージョンもスキップできます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:77 -msgid "``skip/windows/2008`` - Skip tests on Windows Server 2008." -msgstr "``skip/windows/2008`` - Windows Server 2008 のテストを省略します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:78 -msgid "``skip/windows/2012-R2`` - Skip tests on Windows Server 2012 R2." -msgstr "``skip/windows/2012-R2`` - Windows Server 2012 R2 のテストを省略します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:80 -msgid "Aliases can be used to skip Python major versions using one of the following:" -msgstr "エイリアスを使用すると、以下のいずれかを使用して Python のメジャーバージョンをスキップできます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:82 -msgid "``skip/python2`` - Skip tests on Python 2.x." -msgstr "``skip/python2`` - Python 2.x のテストを省略します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:83 -msgid "``skip/python3`` - Skip tests on Python 3.x." -msgstr "``skip/python3`` - Python 3.x のテストを省略します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:85 -msgid "For more fine grained skipping, use conditionals in integration test playbooks, such as:" -msgstr "より詳細なスキップを行うには、インテグレーションテストの Playbook で条件を使用します。以下に例を示します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:93 -msgid "Miscellaneous" -msgstr "その他" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:95 -msgid "There are several other aliases available as well:" -msgstr "その他にも利用できるエイリアスがあります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:97 -msgid "``destructive`` - Requires ``--allow-destructive`` to run without ``--docker`` or ``--remote``." -msgstr "``destructive`` - ``--docker`` または ``--remote`` なしで ``--allow-destructive`` を実行する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:98 -msgid "``hidden`` - Target is ignored. Usable as a dependency. Automatic for ``setup_`` and ``prepare_`` prefixed targets." -msgstr "``hidden`` - ターゲットは無視されます。プレフィックス ``setup_`` および ``prepare_`` のが付けられたターゲットに対する自動化。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:101 -msgid "Unstable" -msgstr "不安定" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:103 -msgid "Tests which fail sometimes should be marked with the ``unstable`` alias until the instability has been fixed. These tests will continue to run for pull requests which modify the test or the module under test." -msgstr "時々失敗するテストは、不安定性が修正されるまで、``unstable`` エイリアスでマークする必要があります。これらのテストは、テストまたはテスト対象のモジュールを変更するプル要求に対して引き続き実行します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:106 -msgid "This avoids unnecessary test failures for other pull requests, as well as tests on merge runs and nightly CI jobs." -msgstr "これにより、他のプル要求に対する不要なテストの失敗や、マージの実行および毎夜の CI ジョブのテストも回避されます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:108 -msgid "There are two ways to run unstable tests manually:" -msgstr "不安定なテストを手動で実行する方法は 2 つあります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:110 -msgid "Use the ``--allow-unstable`` option for ``ansible-test``" -msgstr "``ansible-test`` には ``--allow-unstable`` オプションを使用します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:111 -msgid "Prefix the test name with ``unstable/`` when passing it to ``ansible-test``." -msgstr "``ansible-test`` に渡す場合は、テスト名の前に ``unstable/`` を付けます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:113 -msgid "Tests will be marked as unstable by a member of the Ansible Core Team. GitHub issues_ will be created to track each unstable test." -msgstr "テストは、Ansible Core Team のメンバーによって不安定としてマークされます。GitHub 問題_ が作成され、不安定な各テストを追跡します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:117 -msgid "Disabled" -msgstr "無効" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:119 -msgid "Tests which always fail should be marked with the ``disabled`` alias until they can be fixed." -msgstr "常に失敗するテストでは、修正されるまで、``disabled`` なエイリアスでマークされる必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:121 -msgid "Disabled tests are automatically skipped." -msgstr "無効にされたテストは自動的に省略されます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:123 -msgid "There are two ways to run disabled tests manually:" -msgstr "無効にされたテストを手動で実行する方法は 2 つあります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:125 -msgid "Use the ``--allow-disabled`` option for ``ansible-test``" -msgstr "``ansible-test`` には ``--allow-disabled`` オプションを使用します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:126 -msgid "Prefix the test name with ``disabled/`` when passing it to ``ansible-test``." -msgstr "``ansible-test`` に渡す場合は、テスト名の前に ``disabled/`` を付けます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:128 -msgid "Tests will be marked as disabled by a member of the Ansible Core Team. GitHub issues_ will be created to track each disabled test." -msgstr "テストは、Ansible Core Team のメンバーによって無効とマークされます。GitHub 問題_ が作成され、無効にされた各テストを追跡します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:132 -msgid "Unsupported" -msgstr "サポート対象外" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:134 -msgid "Tests which cannot be run in CI should be marked with the ``unsupported`` alias. Most tests can be supported through the use of simulators and/or cloud plugins." -msgstr "CI で実行できないテストには、``unsupported`` エイリアスのマークを付ける必要があります。ほとんどのテストはシミュレーターやクラウドプラグインを使用することでサポートされます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:137 -msgid "However, if that is not possible then marking a test as unsupported will prevent it from running in CI." -msgstr "ただし、テストが使用できない場合は、サポート対象外としてテストをマークすると、CI でテストを実行できなくなります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:139 -msgid "There are two ways to run unsupported tests manually:" -msgstr "サポートされないテストを手動で実行する方法は 2 つあります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:141 -msgid "Use the ``--allow-unsupported`` option for ``ansible-test``" -msgstr "``ansible-test`` には ``--allow-unsupported`` オプションを使用します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:142 -msgid "Prefix the test name with ``unsupported/`` when passing it to ``ansible-test``." -msgstr "``ansible-test`` に渡す場合は、テスト名の前に ``unsupported/`` を付けます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:144 -msgid "Tests will be marked as unsupported by the contributor of the test." -msgstr "テストは、テストの貢献者によって unsupported とマークされます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:147 -msgid "Cloud" -msgstr "クラウド" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:149 -msgid "Tests for cloud services and other modules that require access to external APIs usually require special support for testing in CI." -msgstr "通常、外部 API へのアクセスを必要とするクラウドサービスおよびその他のモジュールのテストには、CI でのテストに特別なサポートが必要です。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:151 -msgid "These require an additional alias to indicate the required test plugin." -msgstr "これらには、必要なテストプラグインを指定するために追加のエイリアスが必要です。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:153 -msgid "Some of the available aliases are:" -msgstr "利用可能なエイリアスには、以下のものがあります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:155 -msgid "``cloud/aws``" -msgstr "``cloud/aws``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:156 -msgid "``cloud/azure``" -msgstr "``cloud/azure``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:157 -msgid "``cloud/cs``" -msgstr "``cloud/cs``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:158 -msgid "``cloud/foreman``" -msgstr "``cloud/foreman``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:159 -msgid "``cloud/openshift``" -msgstr "``cloud/openshift``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:160 -msgid "``cloud/tower``" -msgstr "``cloud/tower``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:161 -msgid "``cloud/vcenter``" -msgstr "``cloud/vcenter``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:164 -msgid "Untested" -msgstr "未テスト" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:166 -msgid "Every module and plugin should have integration tests, even if the tests cannot be run in CI." -msgstr "テストを CI で実行できない場合でも、すべてのモジュールおよびプラグインにインテグレーションテストが含まれる必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:169 -msgid "Issues" -msgstr "問題" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:171 -msgid "Tests that are marked as unstable_ or disabled_ will have an issue created to track the status of the test. Each issue will be assigned to one of the following projects:" -msgstr "unstable_ または disabled_ としてマークされているテストには、テストのステータスを追跡する問題が作成されます。それぞれの問題は以下のプロジェクトのいずれかに割り当てられます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:174 -msgid "`AWS `_" -msgstr "`AWS `_" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:175 -msgid "`Azure `_" -msgstr "`Azure `_" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:176 -msgid "`Windows `_" -msgstr "`Windows `_" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:177 -msgid "`General `_" -msgstr "`General `_" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:180 -msgid "Questions" -msgstr "ご質問はございますか。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:182 -msgid "For questions about integration tests reach out to @mattclay or @gundalow on GitHub or ``#ansible-devel`` on IRC." -msgstr "インテグレーションテストに関する質問は、GitHub で @mattclay または @gundalow、または IRC で ``#ansible-devel`` にお問い合わせください。" - -#: ../../rst/dev_guide/testing/sanity/line-endings.rst:2 -msgid "line-endings" -msgstr "行末" - -#: ../../rst/dev_guide/testing/sanity/line-endings.rst:4 -msgid "All files must use ``\\n`` for line endings instead of ``\\r\\n``." -msgstr "すべてのファイルは、``\\r\\n" -"`` ではなく、行末に ``\\n" -"`` を使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/metaclass-boilerplate.rst:2 -msgid "metaclass-boilerplate" -msgstr "metaclass-boilerplate" - -#: ../../rst/dev_guide/testing/sanity/metaclass-boilerplate.rst:4 -msgid "Most Python files should include the following boilerplate at the top of the file, right after the comment header and ``from __future__ import``:" -msgstr "ほとんどの Python ファイルには、ファイルの上部、コメントヘッダーのおよび ``from __future__ import`` の直後に次の boilerplate を含める必要があります。" - -#: ../../rst/dev_guide/testing/sanity/metaclass-boilerplate.rst:12 -msgid "Python 2 has \"new-style classes\" and \"old-style classes\" whereas Python 3 only has new-style classes. Adding the ``__metaclass__ = type`` boilerplate makes every class defined in that file into a new-style class as well." -msgstr "Python 2 には「新スタイルのクラス」および「旧スタイルのクラス」が使用されますが、Python 3 には新スタイルのクラスのみが使用されます。また、``__metaclass__ = type`` boilerplate を追加すると、そのファイルで定義されているすべてのクラスが新しいスタイルのクラスになります。" - -#: ../../rst/dev_guide/testing/sanity/no-assert.rst:2 -msgid "no-assert" -msgstr "assert は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-assert.rst:4 -msgid "Do not use ``assert`` in production Ansible python code. When running Python with optimizations, Python will remove ``assert`` statements, potentially allowing for unexpected behavior throughout the Ansible code base." -msgstr "実稼働環境の Ansible Python コードで ``assert`` を使用しないでください。最適化で Python を実行すると、Python は ``assert`` ステートメントを削除すると、Ansible のコードベース全体で予期しない動作が可能になります。" - -#: ../../rst/dev_guide/testing/sanity/no-assert.rst:8 -msgid "Instead of using ``assert`` you should utilize simple ``if`` statements, that result in raising an exception. There is a new exception called ``AnsibleAssertionError`` that inherits from ``AnsibleError`` and ``AssertionError``. When possible, utilize a more specific exception than ``AnsibleAssertionError``." -msgstr "``assert`` を使用する代わりに、簡単な ``if`` ステートメントを利用する必要があります。その結果、例外が発生します。``AnsibleError`` および ``AssertionError`` から継承する ``AnsibleAssertionError`` と呼ばれる新しい例外があります。可能であれば、``AnsibleAssertionError`` より具体的な例外を利用してください。" - -#: ../../rst/dev_guide/testing/sanity/no-assert.rst:14 -msgid "Modules will not have access to ``AnsibleAssertionError`` and should instead raise ``AssertionError``, a more specific exception, or just use ``module.fail_json`` at the failure point." -msgstr "モジュールは ``AnsibleAssertionError`` にアクセスできないため、代わりに ``AssertionError`` を高くすることはできません。あるいは、障害段階で ``module.fail_json`` を使用します。" - -#: ../../rst/dev_guide/testing/sanity/no-basestring.rst:2 -msgid "no-basestring" -msgstr "basestring は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-basestring.rst:4 -msgid "Do not use ``isinstance(s, basestring)`` as basestring has been removed in Python3. You can import ``string_types``, ``binary_type``, or ``text_type`` from ``ansible.module_utils.six`` and then use ``isinstance(s, string_types)`` or ``isinstance(s, (binary_type, text_type))`` instead." -msgstr "Python3 では ``isinstance(s, basestring)`` をベース文字列から削除しないでください。``string_types``、``binary_type``、または ``text_type`` を ``ansible.module_utils.six`` からインポートしてから、代わりに ``isinstance(s, string_types)`` または ``isinstance(s, (binary_type, text_type))`` を使用できます。" - -#: ../../rst/dev_guide/testing/sanity/no-basestring.rst:9 -msgid "If this is part of code to convert a string to a particular type, ``ansible.module_utils._text`` contains several functions that may be even better for you: ``to_text``, ``to_bytes``, and ``to_native``." -msgstr "これが文字列を特定の型に変換するコードの一部である場合、``ansible.module_utils._text`` には、より良い関数がいくつか含まれています (``to_text``、``to_bytes``、および ``to_native``)。" - -#: ../../rst/dev_guide/testing/sanity/no-dict-iteritems.rst:2 -msgid "no-dict-iteritems" -msgstr "dict-iteritems は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-dict-iteritems.rst:4 -msgid "The ``dict.iteritems`` method has been removed in Python 3. There are two recommended alternatives:" -msgstr "この ``dict.iteritems`` メソッドは、Python 3 で削除されました。推奨される方法には、以下の 2 つがあります。" - -#: ../../rst/dev_guide/testing/sanity/no-dict-iterkeys.rst:2 -msgid "no-dict-iterkeys" -msgstr "dict-iterkeys は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-dict-iterkeys.rst:4 -msgid "The ``dict.iterkeys`` method has been removed in Python 3. Use the following instead:" -msgstr "この ``dict.iterkeys`` メソッドは、Python 3 で削除されました。代わりに、以下を使用します。" - -#: ../../rst/dev_guide/testing/sanity/no-dict-itervalues.rst:2 -msgid "no-dict-itervalues" -msgstr "dict-itervalues は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-dict-itervalues.rst:4 -msgid "The ``dict.itervalues`` method has been removed in Python 3. There are two recommended alternatives:" -msgstr "この ``dict.itervalues`` メソッドは、Python 3 で削除されました。推奨される代替手段が 2 つあります。" - -#: ../../rst/dev_guide/testing/sanity/no-get-exception.rst:2 -msgid "no-get-exception" -msgstr "get-exception は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-get-exception.rst:4 -msgid "We created a function, ``ansible.module_utils.pycompat24.get_exception`` to help retrieve exceptions in a manner compatible with Python 2.4 through Python 3.6. We no longer support Python 2.4 and Python 2.5 so this is extraneous and we want to deprecate the function. Porting code should look something like this:" -msgstr "Python 2.4 ～ Python 3.6 と互換性がある例外の取得に役立つ関数 ``ansible.module_utils.pycompat24.get_exception`` を作成しました。Python 2.4 および Python 2.5 はサポートされなくなったため、これは外部のものであり、この関数を廃止する必要があります。移植コードは、以下のようになります。" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:2 -msgid "no-illegal-filenames" -msgstr "不正なファイル名は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:4 -msgid "Files and directories should not contain illegal characters or names so that Ansible can be checked out on any Operating System." -msgstr "ファイルとディレクトリーには、Ansible をどのオペレーティングシステムでもチェックアウトできるように、不正な文字や名前は使用しないでください。" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:8 -msgid "Illegal Characters" -msgstr "不正な文字" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:10 -msgid "The following characters are not allowed to be used in any part of the file or directory name;" -msgstr "以下の文字は、ファイルまたはディレクトリーの名前には使用できません。" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:13 -msgid "``<``" -msgstr "``<``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:14 -msgid "``>``" -msgstr "``>``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:15 -msgid "``:``" -msgstr "``:``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:16 -msgid "``\"``" -msgstr "``\"``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:17 -msgid "``/``" -msgstr "``/``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:18 -msgid "``\\``" -msgstr "``\\``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:19 -msgid "``|``" -msgstr "``|``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:20 -msgid "``?``" -msgstr "``?``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:21 -msgid "``*``" -msgstr "``*``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:22 -msgid "Any characters whose integer representations are in the range from 0 through to 31 like ``\\n``" -msgstr "整数表示が 0 から 31 までの文字 (例: ``\\n" -"``)" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:24 -msgid "The following characters are not allowed to be used as the last character of a file or directory;" -msgstr "次の文字は、ファイルまたはディレクトリーの最後の文字には使用できません。" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:27 -msgid "``.``" -msgstr "``.``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:28 -msgid "``\" \"`` (just the space character)" -msgstr "``\" \"`` (空白文字のみ)" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:31 -msgid "Illegal Names" -msgstr "不正な名前" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:33 -msgid "The following names are not allowed to be used as the name of a file or directory excluding the extension;" -msgstr "以下の名前は、拡張子を除いてファイルまたはディレクトリーの名前として使用することはできません。" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:36 -msgid "``CON``" -msgstr "``CON``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:37 -msgid "``PRN``" -msgstr "``PRN``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:38 -msgid "``AUX``" -msgstr "``AUX``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:39 -msgid "``NUL``" -msgstr "``NUL``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:40 -msgid "``COM1``" -msgstr "``COM1``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:41 -msgid "``COM2``" -msgstr "``COM2``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:42 -msgid "``COM3``" -msgstr "``COM3``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:43 -msgid "``COM4``" -msgstr "``COM4``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:44 -msgid "``COM5``" -msgstr "``COM5``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:45 -msgid "``COM6``" -msgstr "``COM6``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:46 -msgid "``COM7``" -msgstr "``COM7``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:47 -msgid "``COM8``" -msgstr "``COM8``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:48 -msgid "``COM9``" -msgstr "``COM9``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:49 -msgid "``LPT1``" -msgstr "``LPT1``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:50 -msgid "``LPT2``" -msgstr "``LPT2``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:51 -msgid "``LPT3``" -msgstr "``LPT3``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:52 -msgid "``LPT4``" -msgstr "``LPT4``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:53 -msgid "``LPT5``" -msgstr "``LPT5``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:54 -msgid "``LPT6``" -msgstr "``LPT6``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:55 -msgid "``LPT7``" -msgstr "``LPT7``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:56 -msgid "``LPT8``" -msgstr "``LPT8``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:57 -msgid "``LPT9``" -msgstr "``LPT9``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:59 -msgid "For example, the file ``folder/COM1``, ``folder/COM1.txt`` are illegal but ``folder/COM1-file`` or ``folder/COM1-file.txt`` is allowed." -msgstr "たとえば、``folder/COM1`` または ``folder/COM1.txt`` は許可されませんが、``folder/COM1-file`` または ``folder/COM1-file.txt`` は許可されます。" - -#: ../../rst/dev_guide/testing/sanity/no-main-display.rst:2 -msgid "no-main-display" -msgstr "main-display は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-main-display.rst:4 -msgid "As of Ansible 2.8, ``Display`` should no longer be imported from ``__main__``." -msgstr "Ansible 2.8 の時点で、``Display`` は ``__main__`` からインポートしないようにしてください。" - -#: ../../rst/dev_guide/testing/sanity/no-main-display.rst:6 -msgid "``Display`` is now a singleton and should be utilized like the following::" -msgstr "``Display`` はシングルトンで、以下のように使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/no-main-display.rst:11 -msgid "There is no longer a need to attempt ``from __main__ import display`` inside a ``try/except`` block." -msgstr "``try/except`` ブロック内で ``from __main__ import display`` を試行する必要がなくなりました。" - -#: ../../rst/dev_guide/testing/sanity/no-smart-quotes.rst:2 -msgid "no-smart-quotes" -msgstr "スマート引用符は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-smart-quotes.rst:4 -msgid "Smart quotes (``”“‘’``) should not be used. Use plain ascii quotes (``\"'``) instead." -msgstr "スマート引用符 (``”“‘’``) は使用しないでください。代わりに、標準の ascii 引用符 (``\"'``) を使用します。" - -#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:4 -msgid "no-tests-as-filters" -msgstr "テストをフィルターとして使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:6 -msgid "Using Ansible provided Jinja2 tests as filters will be removed in Ansible 2.9." -msgstr "Ansible が提供する Jinja2 テストをフィルターとして使用することは、Ansible 2.9 で削除されます。" - -#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:8 -msgid "Prior to Ansible 2.5, Jinja2 tests included within Ansible were most often used as filters. The large difference in use is that filters are referenced as ``variable | filter_name`` while Jinja2 tests are referenced as ``variable is test_name``." -msgstr "Ansible 2.5 以前は、Ansible に含まれる Jinja2 テストは、ほとんどがフィルターとして使用されていました。使用方法の大きな違いは、フィルターは ``variable | filter_name`` として参照されるのに対し、Jinja2 テストは ``variable is test_name`` として参照されることです。" - -#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:10 -msgid "Jinja2 tests are used for comparisons, whereas filters are used for data manipulation, and have different applications in Jinja2. This change is to help differentiate the concepts for a better understanding of Jinja2, and where each can be appropriately used." -msgstr "Jinja2 テストは比較のために使用され、フィルターはデータ操作のために使用され、それぞれ用途が異なります。この変更は、Jinja2 の理解を深めるために概念を区別し、それぞれが適切に使用される場所を示すためのものです。" - -#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:12 -msgid "As of Ansible 2.5 using an Ansible provided Jinja2 test with filter syntax will display a deprecation error." -msgstr "Ansible 2.5 以降では、Ansible が提供する Jinja2 テストをフィルター構文で使用すると、非推奨エラーが表示されます。" - -#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:4 -msgid "no-underscore-variable" -msgstr "no-underscore-variable" - -#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:6 -msgid "In the future, Ansible may use the identifier ``_`` to internationalize its message strings. To be ready for that, we need to make sure that there are no conflicting identifiers defined in the code base." -msgstr "今後、Ansible は、識別子 ``_`` を使用して、メッセージ文字列を国際化することができます。そのためには、コードベースで定義されている識別子が競合しないようにする必要があります。" - -#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:10 -msgid "In common practice, ``_`` is frequently used as a dummy variable (a variable to receive a value from a function where the value is useless and never used). In Ansible, we're using the identifier ``dummy`` for this purpose instead." -msgstr "一般的な慣行では、``_`` は、ダミー変数 (値が役に立たず、使用されない関数から値を受け取る変数) として頻繁に使用されます。Ansibleでは、代わりにこの目的のために識別子 ``dummy`` を使用しています。" - -#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:14 -msgid "Example of unfixed code:" -msgstr "未修正コードの例:" - -#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:23 -msgid "Example of fixed code:" -msgstr "修正したコードの例:" - -#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:2 -msgid "no-unicode_literals" -msgstr "no-unicode_literals" - -#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:4 -msgid "The use of :code:`from __future__ import unicode_literals` has been deemed an anti-pattern. The problems with it are:" -msgstr ":code:`from __future__ import unicode_literals` のはアンチパターンと見なされます。その問題は次のとおりです。" - -#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:7 -msgid "It makes it so one can't jump into the middle of a file and know whether a bare literal string is a byte string or text string. The programmer has to first check the top of the file to see if the import is there." -msgstr "これにより、ファイルの途中にジャンプして、裸のリテラル文字列がバイト文字列なのかテキスト文字列なのかを知ることができなくなります。プログラマーは、最初にファイルの先頭をチェックして、インポートが存在するかどうかを確認する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:10 -msgid "It removes the ability to define native strings (a string which should be a byte string on python2 and a text string on python3) via a string literal." -msgstr "これにより、文字列リテラルを介してネイティブ文字列 (python2 ではバイト文字列、python3 ではテキスト文字列である必要がある文字列) を定義する機能が削除されます。" - -#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:12 -msgid "It makes for more context switching. A programmer could be reading one file which has `unicode_literals` and know that bare string literals are text strings but then switch to another file (perhaps tracing program execution into a third party library) and have to switch their understanding of what bare string literals are." -msgstr "そのため、コンテキストの切り替えが多くなります。プログラマーは、`unicode_literals` を含むあるファイルを読み込んでいて、裸の文字列リテラルがテキスト文字列であることを知っていますが、その後、別のファイル (おそらくサードパーティーのライブラリーへのプログラム実行のトレース) に切り替えて、裸の文字列リテラルが何であるかの理解を切り替えなければなりません。" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:2 -msgid "no-unwanted-files" -msgstr "不要なファイルは使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:4 -msgid "Specific file types are allowed in certain directories:" -msgstr "特定のファイルタイプは、特定のディレクトリーで許可されます。" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:6 -msgid "``lib`` - All content must reside in the ``lib/ansible`` directory." -msgstr "``lib`` - すべてのコンテンツは ``lib/ansible`` ディレクトリーに置く必要があります。" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:8 -msgid "``lib/ansible`` - Only source code with one of the following extensions is allowed:" -msgstr "``lib/ansible`` - 以下の拡張機能のいずれかを持つソースコードのみが許可されます。" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:10 -msgid "``*.cs`` - C#" -msgstr "``*.cs`` - C#" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:11 -msgid "``*.ps1`` - PowerShell" -msgstr "``*.ps1`` - PowerShell" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:12 -msgid "``*.psm1`` - PowerShell" -msgstr "``*.psm1`` - PowerShell" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:13 -msgid "``*.py`` - Python" -msgstr "``*.py`` - Python" - -#: ../../rst/dev_guide/testing/sanity/no-wildcard-import.rst:4 -msgid "no-wildcard-import" -msgstr "ワイルドカードの import は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-wildcard-import.rst:6 -msgid "Using :code:`import *` is a bad habit which pollutes your namespace, hinders debugging, and interferes with static analysis of code. For those reasons, we do want to limit the use of :code:`import *` in the ansible code. Change our code to import the specific names that you need instead." -msgstr ":code:`import *` を使用すること、名前空間を汚染し、デバッグを妨げ、コードの静的分析を妨げる悪い習慣です。これらの理由から、Ansible コードで :code:`import *` の使用を制限します。代わりに、必要な特定の名前をインポートするようにコードを変更してください。" - -#: ../../rst/dev_guide/testing/sanity/no-wildcard-import.rst:11 -msgid "Examples of unfixed code:" -msgstr "未修正コードの例:" - -#: ../../rst/dev_guide/testing/sanity/no-wildcard-import.rst:22 -msgid "Examples of fixed code:" -msgstr "修正されたコードの例:" - -#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:2 -msgid "obsolete-files" -msgstr "陳腐化したファイル" - -#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:4 -msgid "Directories in the Ansible source tree are sometimes made obsolete. Files should not exist in these directories. The new location (if any) is dependent on which directory has been made obsolete." -msgstr "Ansible ソースツリー内のディレクトリーは廃止されることがあります。ファイルは、このディレクトリーに存在すべきではありません。新しい場所 (存在する場合) は、どのディレクトリーが廃止されたかに依存しています。" - -#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:8 -msgid "Below are some of the obsolete directories and their new locations:" -msgstr "古いディレクトリーとその新しい場所を以下に示します。" - -#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:10 -msgid "All of ``test/runner/`` is now under ``test/lib/ansible_test/`` instead. The organization of files in the new directory has changed." -msgstr "すべての ``test/runner/`` は、現在は、代わりに ``test/lib/ansible_test/`` にあります。新しいディレクトリーのファイルの編成が変更になりました。" - -#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:11 -msgid "Most subdirectories of ``test/sanity/`` (with some exceptions) are now under ``test/lib/ansible_test/_data/sanity/`` instead." -msgstr "``test/sanity/`` (例外あり) のサブディレクトリーのほとんどは、代わりに ``test/lib/ansible_test/_data/sanity/`` の下にあります。" - -#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:13 -msgid "This error occurs most frequently for open pull requests which add or modify files in directories which are now obsolete. Make sure the branch you are working from is current so that changes can be made in the correct location." -msgstr "このエラーは、現在古くなったディレクトリーのファイルを追加または変更するオープンなプル要求に対して最も頻繁に発生します。正しい場所で変更できるように、作業しているブランチが現在の状態であることを確認します。" - -#: ../../rst/dev_guide/testing/sanity/package-data.rst:2 -msgid "package-data" -msgstr "package-data" - -#: ../../rst/dev_guide/testing/sanity/package-data.rst:4 -msgid "Verifies that the combination of ``MANIFEST.in`` and ``package_data`` from ``setup.py`` properly installs data files from within ``lib/ansible``" -msgstr "``setup.py`` から ``MANIFEST.in`` と ``package_data`` の組み合わせによって、``lib/ansible`` 内からデータファイルが適切にインストールされていることを確認します。" - -#: ../../rst/dev_guide/testing/sanity/pep8.rst:2 -msgid "pep8" -msgstr "pep8" - -#: ../../rst/dev_guide/testing/sanity/pep8.rst:4 -msgid "Python static analysis for PEP 8 style guideline compliance." -msgstr "PEP 8 スタイルのガイドラインコンプライアンスに対する Python 静的分析です。" - -#: ../../rst/dev_guide/testing/sanity/pep8.rst:6 -msgid "See :ref:`testing_pep8` for more information." -msgstr "詳細は、「:ref:`testing_pep8`」を参照してください。" - -#: ../../rst/dev_guide/testing/sanity/pslint.rst:2 -msgid "pslint" -msgstr "pslint" - -#: ../../rst/dev_guide/testing/sanity/pslint.rst:4 -msgid "PowerShell static analysis for common programming errors using `PSScriptAnalyzer `_." -msgstr "`PSScriptAnalyzer `_ を使用した一般的なプログラミングエラーに関する PowerShell の静的な分析です。" - -#: ../../rst/dev_guide/testing/sanity/pylint.rst:2 -msgid "pylint" -msgstr "pylint" - -#: ../../rst/dev_guide/testing/sanity/pylint-ansible-test.rst:6 -#: ../../rst/dev_guide/testing/sanity/pylint.rst:4 -msgid "Python static analysis for common programming errors." -msgstr "一般的なプログラミングエラーに対する Python の静的分析です。" - -#: ../../rst/dev_guide/testing/sanity/pylint-ansible-test.rst:4 -msgid "pylint-ansible-test" -msgstr "pylint-ansible-test" - -#: ../../rst/dev_guide/testing/sanity/pylint-ansible-test.rst:8 -msgid "A more strict set of rules applied to ``ansible-test``." -msgstr "``ansible-test`` に適用されるより厳密なルールセット" - -#: ../../rst/dev_guide/testing/sanity/release-names.rst:2 -msgid "Release names" -msgstr "リリース名" - -#: ../../rst/dev_guide/testing/sanity/release-names.rst:4 -msgid "Verifies that the most recent release name has been added to ``./github/RELEASE_NAMES.yml``" -msgstr "最新のリリース名が ``./github/RELEASE_NAMES.yml`` に追加されたことを確認します。" - -#: ../../rst/dev_guide/testing/sanity/replace-urlopen.rst:2 -msgid "replace-urlopen" -msgstr "replace-urlopen" - -#: ../../rst/dev_guide/testing/sanity/replace-urlopen.rst:4 -msgid "Use ``open_url`` from ``module_utils`` instead of ``urlopen``." -msgstr "``urlopen`` の代わりに ``module_utils`` から ``open_url`` を使用します。" - -#: ../../rst/dev_guide/testing/sanity/required-and-default-attributes.rst:2 -msgid "required-and-default-attributes" -msgstr "required-and-default-attributes" - -#: ../../rst/dev_guide/testing/sanity/required-and-default-attributes.rst:4 -msgid "Use only one of ``default`` or ``required`` with ``FieldAttribute``." -msgstr "``default`` または ``required`` の 1 つのみを ``FieldAttribute`` で使用します。" - -#: ../../rst/dev_guide/testing/sanity/rstcheck.rst:2 -msgid "rstcheck" -msgstr "rstcheck" - -#: ../../rst/dev_guide/testing/sanity/rstcheck.rst:4 -msgid "Check reStructuredText files for syntax and formatting issues." -msgstr "構文およびフォーマットに関する問題は、eStructuredTex ファイルを確認してください。" - -#: ../../rst/dev_guide/testing/sanity/runtime-metadata.rst:2 -msgid "runtime-metadata.yml" -msgstr "runtime-metadata.yml" - -#: ../../rst/dev_guide/testing/sanity/runtime-metadata.rst:4 -msgid "Validates the schema for:" -msgstr "スキーマを検証します。" - -#: ../../rst/dev_guide/testing/sanity/runtime-metadata.rst:6 -msgid "ansible-base's ``lib/ansible/config/ansible_builtin_runtime.yml``" -msgstr "ansible-base の ``lib/ansible/config/ansible_builtin_runtime.yml``" - -#: ../../rst/dev_guide/testing/sanity/runtime-metadata.rst:7 -msgid "collection's ``meta/runtime.yml``" -msgstr "コレクションの ``meta/runtime.yml``" - -#: ../../rst/dev_guide/testing/sanity/sanity-docs.rst:2 -msgid "sanity-docs" -msgstr "sanity-docs" - -#: ../../rst/dev_guide/testing/sanity/sanity-docs.rst:4 -msgid "Documentation for each ``ansible-test sanity`` test is required." -msgstr "各 ``ansible-test sanity`` テスト用のドキュメントが必要です。" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:2 -msgid "shebang" -msgstr "shebang" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:4 -msgid "Most executable files should only use one of the following shebangs:" -msgstr "実行ファイルのほとんどは、以下のいずれかの shebang のみを使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:6 -msgid "``#!/bin/sh``" -msgstr "``#!/bin/sh``" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:7 -msgid "``#!/bin/bash``" -msgstr "``#!/bin/bash``" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:8 -msgid "``#!/usr/bin/make``" -msgstr "``#!/usr/bin/make``" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:9 -msgid "``#!/usr/bin/env python``" -msgstr "``#!/usr/bin/env python``" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:10 -msgid "``#!/usr/bin/env bash``" -msgstr "``#!/usr/bin/env bash``" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:12 -msgid "NOTE: For ``#!/bin/bash``, any of the options ``eux`` may also be used, such as ``#!/bin/bash -eux``." -msgstr "注記: ``#!/bin/bash`` の場合は、いずれのオプションの ``eux`` も使用できます (``#!/bin/bash -eux`` など)。" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:14 -msgid "This does not apply to Ansible modules, which should not be executable and must always use ``#!/usr/bin/python``." -msgstr "これは Ansible モジュールには適用されません。これは実行可能ではなく、``#!/usr/bin/python`` を常に使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:16 -msgid "Some exceptions are permitted. Ask if you have questions." -msgstr "一部の例外が許可されます。ご質問がある場合はお問い合わせください。" - -#: ../../rst/dev_guide/testing/sanity/shellcheck.rst:2 -msgid "shellcheck" -msgstr "shellcheck" - -#: ../../rst/dev_guide/testing/sanity/shellcheck.rst:4 -msgid "Static code analysis for shell scripts using the excellent `shellcheck `_ tool." -msgstr "優れた `shellcheck `_ ツールを使用してシェルスクリプトの静的コード分析。" - -#: ../../rst/dev_guide/testing/sanity/symlinks.rst:2 -msgid "symlinks" -msgstr "symlinks" - -#: ../../rst/dev_guide/testing/sanity/symlinks.rst:4 -msgid "Symbolic links are only permitted for files that exist to ensure proper tarball generation during a release." -msgstr "シンボリックリンクは、リリース中に適切な tarball 生成を保証するファイルにのみ許可されます。" - -#: ../../rst/dev_guide/testing/sanity/symlinks.rst:6 -msgid "If other types of symlinks are needed for tests they must be created as part of the test." -msgstr "テストに他のシンボリックリンクが必要な場合は、テストの一部として作成する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/test-constraints.rst:2 -msgid "test-constraints" -msgstr "test-constraints" - -#: ../../rst/dev_guide/testing/sanity/test-constraints.rst:4 -msgid "Constraints for test requirements should be in ``test/lib/ansible_test/_data/requirements/constraints.txt``." -msgstr "テスト要件の制約は ``test/lib/ansible_test/_data/requirements/constraints.txt`` に保存されている必要があります。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:4 -msgid "update-bundled" -msgstr "update-bundled" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:6 -msgid "Check whether any of our known bundled code needs to be updated for a new upstream release." -msgstr "既知のバンドルされたコードが新しいアップストリームリリース用に更新する必要があるかどうかを確認します。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:8 -msgid "This test can error in the following ways:" -msgstr "このテストは以下の方法でエラーが発生する可能性があります。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:10 -msgid "The bundled code is out of date with regard to the latest release on pypi. Update the code to the new version and update the version in _BUNDLED_METADATA to solve this." -msgstr "バンドルされたコードは pypi の最新リリースに関して古くなっています。コードを新しいバージョンに更新し、_BUNDLED_METADATA でバージョンを更新してこれを解決します。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:13 -msgid "The code is lacking a _BUNDLED_METADATA variable. This typically happens when a bundled version is updated and we forget to add a _BUNDLED_METADATA variable to the updated file. Once that is added, this error should go away." -msgstr "このコードには _BUNDLED_METADATA 変数がありません。これは通常、バンドルバージョンが更新され、更新されたファイルに _BUNDLED_METADATA 変数を追加し忘れた場合に発生します。それが追加されると、このエラーはなくなるはずです。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:17 -msgid "A file has a _BUNDLED_METADATA variable but the file isn't specified in :file:`test/sanity/code-smell/update-bundled.py`. This typically happens when a new bundled library is added. Add the file to the `get_bundled_libs()` function in the `update-bundled.py` test script to solve this error." -msgstr "ファイルには、_BUNDLED_METADATA 変数がありますが、そのファイルは :file:`test/sanity/code-smell/update-bundled.py` で指定されていません。これは通常、新しいバンドルライブラリーが追加されたときに発生します。このエラーを解決するために、`update-bundled.py` テストスクリプトの `get_bundled_libs()` 関数にファイルを追加します。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:22 -msgid "_BUNDLED_METADATA has the following fields:" -msgstr "_BUNDLED_METADATA には以下のフィールドがあります。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst -msgid "pypi_name" -msgstr "pypi_name" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:24 -msgid "Name of the bundled package on pypi" -msgstr "pypi でバンドルされたパッケージの名前" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:26 -msgid "Version of the package that we are including here" -msgstr "ここに含めるパッケージのバージョン" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst -msgid "version_constraints" -msgstr "version_constraints" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:28 -msgid "Optional PEP440 specifier for the version range that we are bundling. Currently, the only valid use of this is to follow a version that is compatible with the Python stdlib when newer versions of the pypi package implement a new API." -msgstr "バンドルするバージョン範囲の任意の PEP440 指定子。現在、これの唯一の有効な使用法は、新しいバージョンの pypi パッケージが新しい API を実装するときに、Python stdlib と互換性のあるバージョンに従うことです。" - -#: ../../rst/dev_guide/testing/sanity/use-argspec-type-path.rst:2 -msgid "use-argspec-type-path" -msgstr "use-argspec-type-path" - -#: ../../rst/dev_guide/testing/sanity/use-argspec-type-path.rst:4 -msgid "The AnsibleModule argument_spec knows of several types beyond the standard python types. One of these is ``path``. When used, type ``path`` ensures that an argument is a string and expands any shell variables and tilde characters." -msgstr "AnsibleModule の argument_spec は、標準の python タイプ以外の複数のタイプを認識します。これらのいずれかが ``path`` になります。使用すると、``path`` と入力して、引数が文字列で、シェル変数とチルダ文字を拡張するようにします。" - -#: ../../rst/dev_guide/testing/sanity/use-argspec-type-path.rst:8 -msgid "This test looks for use of :func:`os.path.expanduser ` in modules. When found, it tells the user to replace it with ``type='path'`` in the module's argument_spec or list it as a false positive in the test." -msgstr "このテストでは、モジュールで :func:`os.path.expanduser ` の使用を探します。見つかった場合は、モジュールの argument_spec で ``type='path'`` に置き換えるか、テストで誤検出として一覧に挙げられます。" - -#: ../../rst/dev_guide/testing/sanity/use-compat-six.rst:2 -msgid "use-compat-six" -msgstr "use-compat-six" - -#: ../../rst/dev_guide/testing/sanity/use-compat-six.rst:4 -msgid "Use ``six`` from ``module_utils`` instead of ``six``." -msgstr "``six`` の代わりに ``module_utils`` から ``six`` を使用します。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:2 -#: ../../rst/dev_guide/testing_validate-modules.rst:7 -msgid "validate-modules" -msgstr "validate-modules" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:4 -msgid "Analyze modules for common issues in code and documentation." -msgstr "コードおよびドキュメントの一般的な問題についてモジュールを分析します。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:6 -msgid "See :ref:`testing_validate-modules` for more information." -msgstr "詳細は、「:ref:`testing_validate-modules`」を参照してください。" - -#: ../../rst/dev_guide/testing/sanity/yamllint.rst:2 -msgid "yamllint" -msgstr "yamllint" - -#: ../../rst/dev_guide/testing/sanity/yamllint.rst:4 -msgid "Check YAML files for syntax and formatting issues." -msgstr "YAML ファイルにおける構文およびフォーマットの問題を確認します。" - -#: ../../rst/dev_guide/testing_compile.rst:7 -msgid "Compile Tests" -msgstr "コンパイルテスト" - -#: ../../rst/dev_guide/testing_compile.rst:12 -#: ../../rst/dev_guide/testing_httptester.rst:10 -msgid "Overview" -msgstr "概要" - -#: ../../rst/dev_guide/testing_compile.rst:14 -msgid "Compile tests check source files for valid syntax on all supported python versions:" -msgstr "コンパイルテストでは、サポートされているすべての python バージョンで、ソースファイルの構文が有効かどうかを確認します。" - -#: ../../rst/dev_guide/testing_compile.rst:16 -msgid "2.4 (Ansible 2.3 only)" -msgstr "2.4 (Ansible 2.3 のみ)" - -#: ../../rst/dev_guide/testing_compile.rst:17 -msgid "2.6" -msgstr "2.6" - -#: ../../rst/dev_guide/testing_compile.rst:18 -msgid "2.7" -msgstr "2.7" - -#: ../../rst/dev_guide/testing_compile.rst:19 -msgid "3.5" -msgstr "3.5" - -#: ../../rst/dev_guide/testing_compile.rst:20 -msgid "3.6" -msgstr "3.6" - -#: ../../rst/dev_guide/testing_compile.rst:21 -msgid "3.7" -msgstr "3.7" - -#: ../../rst/dev_guide/testing_compile.rst:22 -msgid "3.8" -msgstr "3.8" - -#: ../../rst/dev_guide/testing_compile.rst:23 -msgid "3.9" -msgstr "3.9" - -#: ../../rst/dev_guide/testing_compile.rst:25 -msgid "NOTE: In Ansible 2.4 and earlier the compile test was provided by a dedicated sub-command ``ansible-test compile`` instead of a sanity test using ``ansible-test sanity --test compile``." -msgstr "注記: Ansible 2.4 以前では、``ansible-test sanity --test compile`` を使用するサニティーテストの代わりに、コンパイルテストが専用のサブコマンド ``ansible-test compile`` によって提供されていました。" - -#: ../../rst/dev_guide/testing_compile.rst:28 -msgid "Running compile tests locally" -msgstr "ローカルでのコンパイルテストの実行" - -#: ../../rst/dev_guide/testing_compile.rst:30 -msgid "Compile tests can be run across the whole code base by doing:" -msgstr "コンパイルテストを実行するには、次のように、コードベース全体でテストを実行できます。" - -#: ../../rst/dev_guide/testing_compile.rst:38 -#: ../../rst/dev_guide/testing_units.rst:38 -msgid "Against a single file by doing:" -msgstr "1 つのファイルに対して以下を行います。" - -#: ../../rst/dev_guide/testing_compile.rst:44 -#: ../../rst/dev_guide/testing_units.rst:44 -msgid "Or against a specific Python version by doing:" -msgstr "または、以下を実行して特定の Python バージョンに対して実行します。" - -#: ../../rst/dev_guide/testing_compile.rst:50 -msgid "For advanced usage see the help:" -msgstr "高度な使用方法は、ヘルプを参照してください。" - -#: ../../rst/dev_guide/testing_compile.rst:58 -#: ../../rst/dev_guide/testing_units.rst:66 -msgid "Installing dependencies" -msgstr "依存関係のインストール" - -#: ../../rst/dev_guide/testing_compile.rst:60 -msgid "``ansible-test`` has a number of dependencies , for ``compile`` tests we suggest running the tests with ``--local``, which is the default" -msgstr "``ansible-test`` にはいくつかの依存関係があります。``compile`` テストでは、デフォルトである ``--local`` を使用してテストを実行することが推奨されます。" - -#: ../../rst/dev_guide/testing_compile.rst:62 -msgid "The dependencies can be installed using the ``--requirements`` argument. For example:" -msgstr "依存関係は、``--requirements`` 引数を使用してインストールできます。以下に例を示します。" - -#: ../../rst/dev_guide/testing_compile.rst:70 -msgid "The full list of requirements can be found at `test/lib/ansible_test/_data/requirements `_. Requirements files are named after their respective commands. See also the `constraints `_ applicable to all commands." -msgstr "要件の一覧は `test/lib/ansible_test/_data/requirements `_ に記載されています。要件ファイルには、各コマンドにちなんで名前が付けられています。全コマンドに適用される `制約 `_ も参照してください。" - -#: ../../rst/dev_guide/testing_compile.rst:74 -msgid "Extending compile tests" -msgstr "コンパイルテストの拡張" - -#: ../../rst/dev_guide/testing_compile.rst:76 -msgid "If you believe changes are needed to the compile tests please add a comment on the `Testing Working Group Agenda `_ so it can be discussed." -msgstr "コンパイルテストに変更が必要な場合は、`ワーキンググループのテストの議題 `_ にコメントを追加してください。その内容について話し合うことができます。" - -#: ../../rst/dev_guide/testing_documentation.rst:9 -msgid "Before you submit a module for inclusion in the main Ansible repo, you must test your module documentation for correct HTML rendering and to ensure that the argspec matches the documentation in your Python file. The community pages offer more information on :ref:`testing reStructuredText documentation `." -msgstr "メインの Ansible リポジトリーに組み込むモジュールを送信する前に、正しい HTML レンダリングついてモジュールドキュメントをテストする必要があります。また、argspec が Python ファイルのドキュメントと一致することを確認する必要があります。コミュニティーページでは、「:ref:`reStructuredText ドキュメントのテスト `」の詳細が提供されています。" - -#: ../../rst/dev_guide/testing_documentation.rst:11 -msgid "To check the HTML output of your module documentation:" -msgstr "モジュールドキュメントの HTML 出力を確認するには、次のコマンドを実行します。" - -#: ../../rst/dev_guide/testing_documentation.rst:13 -msgid "Ensure working :ref:`development environment `." -msgstr ":ref:`開発環境 ` が稼働していることを確認します。" - -#: ../../rst/dev_guide/testing_documentation.rst:14 -#: ../../rst/dev_guide/testing_documentation.rst:28 -msgid "Install required Python packages (drop '--user' in venv/virtualenv):" -msgstr "必要な Python パッケージをインストールします（venv/virtualenv に「--user」をドロップします）。" - -#: ../../rst/dev_guide/testing_documentation.rst:21 -msgid "Ensure your module is in the correct directory: ``lib/ansible/modules/$CATEGORY/mymodule.py``." -msgstr "モジュールが正しいディレクトリー (``lib/ansible/modules/$CATEGORY/mymodule.py``) にあることを確認します。" - -#: ../../rst/dev_guide/testing_documentation.rst:22 -msgid "Build HTML from your module documentation: ``MODULES=mymodule make webdocs``." -msgstr "モジュールドキュメント ``MODULES=mymodule make webdocs`` から HTML を構築します。" - -#: ../../rst/dev_guide/testing_documentation.rst:23 -msgid "To build the HTML documentation for multiple modules, use a comma-separated list of module names: ``MODULES=mymodule,mymodule2 make webdocs``." -msgstr "複数のモジュールの HTML ドキュメントを作成するには、モジュール名のコンマ区切りリストを使用します (``MODULES=mymodule,mymodule2 make webdocs``)。" - -#: ../../rst/dev_guide/testing_documentation.rst:24 -msgid "View the HTML page at ``file:///path/to/docs/docsite/_build/html/modules/mymodule_module.html``." -msgstr "``file:///path/to/docs/docsite/_build/html/modules/mymodule_module.html`` で HTML ページを表示します。" - -#: ../../rst/dev_guide/testing_documentation.rst:26 -msgid "To ensure that your module documentation matches your ``argument_spec``:" -msgstr "モジュールのドキュメントが ``argument_spec`` と適合するようにするには、以下を行います。" - -#: ../../rst/dev_guide/testing_documentation.rst:34 -msgid "run the ``validate-modules`` test::" -msgstr "``validate-modules`` テストを実行します。" - -#: ../../rst/dev_guide/testing_httptester.rst:5 -msgid "httptester" -msgstr "httptester" - -#: ../../rst/dev_guide/testing_httptester.rst:12 -msgid "``httptester`` is a docker container used to host certain resources required by :ref:`testing_integration`. This is to avoid CI tests requiring external resources (such as git or package repos) which, if temporarily unavailable, would cause tests to fail." -msgstr "``httptester`` は、:ref:`testing_integration` で必要な特定のリソースをホストするために使用される docker コンテナーです。これにより、(git やパッケージリポジトリーなどの) 外部リソースを必要とする CI テストが回避され、一時的に利用できなくなるとテストが失敗します。" - -#: ../../rst/dev_guide/testing_httptester.rst:14 -msgid "HTTP Testing endpoint which provides the following capabilities:" -msgstr "以下の機能を提供する HTTP テストエンドポイントです。" - -#: ../../rst/dev_guide/testing_httptester.rst:16 -msgid "httpbin" -msgstr "httpbin" - -#: ../../rst/dev_guide/testing_httptester.rst:17 -msgid "nginx" -msgstr "nginx" - -#: ../../rst/dev_guide/testing_httptester.rst:18 -msgid "SSL" -msgstr "SSL" - -#: ../../rst/dev_guide/testing_httptester.rst:19 -msgid "SNI" -msgstr "SNI" - -#: ../../rst/dev_guide/testing_httptester.rst:20 -msgid "Negotiate Authentication" -msgstr "認証のネゴシエート" - -#: ../../rst/dev_guide/testing_httptester.rst:23 -msgid "Source files can be found in the `http-test-container `_ repository." -msgstr "ソースファイルは `http-test-container `_ リポジトリーにあります。" - -#: ../../rst/dev_guide/testing_httptester.rst:26 -msgid "Extending httptester" -msgstr "httptester の拡張" - -#: ../../rst/dev_guide/testing_httptester.rst:28 -msgid "If you have sometime to improve ``httptester`` please add a comment on the `Testing Working Group Agenda `_ to avoid duplicated effort." -msgstr "``httptester`` を改善するタイミングがある場合は、重複作業を回避するために、「`ワーキンググループのテストの議題 `_」にコメントを追加します。" - -#: ../../rst/dev_guide/testing_integration.rst:11 -msgid "The Ansible integration Test system." -msgstr "Ansible 統合テストシステム。" - -#: ../../rst/dev_guide/testing_integration.rst:13 -msgid "Tests for playbooks, by playbooks." -msgstr "Playbook による Playbook のテスト" - -#: ../../rst/dev_guide/testing_integration.rst:15 -msgid "Some tests may require credentials. Credentials may be specified with `credentials.yml`." -msgstr "テストによっては認証情報が必要になる場合があります。認証情報は `credentials.yml` で指定できます。" - -#: ../../rst/dev_guide/testing_integration.rst:17 -msgid "Some tests may require root." -msgstr "テストによっては root が必要になる場合があります。" - -#: ../../rst/dev_guide/testing_integration.rst:24 -msgid "Quick Start" -msgstr "クイックスタート" - -#: ../../rst/dev_guide/testing_integration.rst:26 -msgid "It is highly recommended that you install and activate the ``argcomplete`` python package. It provides tab completion in ``bash`` for the ``ansible-test`` test runner." -msgstr "python パッケージ ``argcomplete`` をインストールし、アクティベートすることが強く推奨されます。これにより、テストランナー ``ansible-test`` に ``bash`` のタブ補完が提供されます。" - -#: ../../rst/dev_guide/testing_integration.rst:30 -msgid "Configuration" -msgstr "設定" - -#: ../../rst/dev_guide/testing_integration.rst:33 -msgid "ansible-test command" -msgstr "ansible-test コマンド" - -#: ../../rst/dev_guide/testing_integration.rst:35 -msgid "The example below assumes ``bin/`` is in your ``$PATH``. An easy way to achieve that is to initialize your environment with the ``env-setup`` command::" -msgstr "以下の例では、``bin/`` が ``$PATH`` であることを前提としています。これは、``env-setup`` コマンドで環境を初期化する簡単な方法になります。" - -#: ../../rst/dev_guide/testing_integration.rst:41 -msgid "You can also call ``ansible-test`` with the full path::" -msgstr "完全パスで ``ansible-test`` を呼び出すこともできます。" - -#: ../../rst/dev_guide/testing_integration.rst:46 -msgid "integration_config.yml" -msgstr "integration_config.yml" - -#: ../../rst/dev_guide/testing_integration.rst:48 -msgid "Making your own version of ``integration_config.yml`` can allow for setting some tunable parameters to help run the tests better in your environment. Some tests (for example, cloud tests) will only run when access credentials are provided. For more information about supported credentials, refer to the various ``cloud-config-*.template`` files in the ``test/integration/`` directory." -msgstr "自身で作成した ``integration_config.yml`` があると、一部の調整可能なパラメーターを設定して、環境により適切にテストを実行できます。一部のテストは、アクセス認証情報が提供されている場合にのみ実行されます。サポート対象の認証情報の詳細は、``test/integration/`` ディレクトリーでさまざまな ``cloud-config-*.template`` ファイルを参照してください。" - -#: ../../rst/dev_guide/testing_integration.rst:55 -msgid "Prerequisites" -msgstr "要件" - -#: ../../rst/dev_guide/testing_integration.rst:57 -msgid "Some tests assume things like hg, svn, and git are installed, and in path. Some tests (such as those for Amazon Web Services) need separate definitions, which will be covered later in this document." -msgstr "一部のテストでは、hg、svn、git などがインストールされ、パスにあることを前提としています。一部のテスト (Amazon Web Services のテストなど) には個別の定義が必要です。これについては、このドキュメントの後半で説明します。" - -#: ../../rst/dev_guide/testing_integration.rst:61 -msgid "(Complete list pending)" -msgstr "(完全はリストは後に追加されます)" - -#: ../../rst/dev_guide/testing_integration.rst:64 -msgid "Non-destructive Tests" -msgstr "非破壊テスト" - -#: ../../rst/dev_guide/testing_integration.rst:66 -msgid "These tests will modify files in subdirectories, but will not do things that install or remove packages or things outside of those test subdirectories. They will also not reconfigure or bounce system services." -msgstr "これらのテストはサブディレクトリー内のファイルを修正しますが、パッケージやテストのサブディレクトリー以外にあるものをインストールしたり削除したりするようなことはしません。また、システムサービスの再設定やバウンスも行いません。" - -#: ../../rst/dev_guide/testing_integration.rst:69 -msgid "Running integration tests within Docker" -msgstr "*Docker 内での統合テストの実行" - -#: ../../rst/dev_guide/testing_integration.rst:71 -msgid "To protect your system from any potential changes caused by integration tests, and to ensure a sensible set of dependencies are available we recommend that you always run integration tests with the ``--docker`` option, for example ``--docker centos8``. See the `list of supported docker images `_ for options (the ``default`` image is used for sanity and unit tests, as well as for platform independent integration tests such as those for cloud modules)." -msgstr "統合テストによる潜在的な変更からシステムを守り、適切な依存関係セットが利用可能になるようにするには、常に ``--docker`` オプションをつけて統合テストを実行することが推奨されます (``--docker centos8``)。オプションについては、「`サポート対象外の docker イメージ `_」を参照してください (``default``イメージは、健全性とユニットテスト、およびクラウドモジュールなどのプラットフォームに依存しない統合テストに使用されます)。" - -#: ../../rst/dev_guide/testing_integration.rst:73 -msgid "Avoiding pulling new Docker images" -msgstr "新規 Docker イメージのプルの回避" - -#: ../../rst/dev_guide/testing_integration.rst:75 -msgid "Use the ``--docker-no-pull`` option to avoid pulling the latest container image. This is required when using custom local images that are not available for download." -msgstr "最新のコンテナーイメージをプルしないようにするには、``--docker-no-pull`` オプションを使用します。これは、ダウンロードに利用できないカスタムのローカルイメージを使用する場合に必要です。" - -#: ../../rst/dev_guide/testing_integration.rst:77 -msgid "Run as follows for all POSIX platform tests executed by our CI system in a fedora32 docker container::" -msgstr "fedora32 docker コンテナーで CI システムによって実行されるすべての POSIX プラットフォームテストに対して次のように実行します。" - -#: ../../rst/dev_guide/testing_integration.rst:81 -msgid "You can target a specific tests as well, such as for individual modules::" -msgstr "個々のモジュールなど、特定のテストを対象とすることもできます。" - -#: ../../rst/dev_guide/testing_integration.rst:85 -msgid "You can use the ``-v`` option to make the output more verbose::" -msgstr "``-v`` オプションを使用すると、出力をさらに詳細にすることができます。" - -#: ../../rst/dev_guide/testing_integration.rst:89 -msgid "Use the following command to list all the available targets::" -msgstr "利用可能なターゲットの一覧を表示するには、以下のコマンドを実行します。" - -#: ../../rst/dev_guide/testing_integration.rst:93 -msgid "Bash users" -msgstr "Bash ユーザー" - -#: ../../rst/dev_guide/testing_integration.rst:95 -msgid "If you use ``bash`` with ``argcomplete``, obtain a full list by doing: ``ansible-test integration ``" -msgstr "``bash`` を ``argcomplete`` とともに使用する場合は、``ansible-test integration `` を実行して完全な一覧を取得します。" - -#: ../../rst/dev_guide/testing_integration.rst:98 -msgid "Destructive Tests" -msgstr "破壊テスト" - -#: ../../rst/dev_guide/testing_integration.rst:100 -msgid "These tests are allowed to install and remove some trivial packages. You will likely want to devote these to a virtual environment, such as Docker. They won't reformat your filesystem::" -msgstr "これらのテストでは、いくつかの簡単なパッケージをインストールおよび削除できます。これらを Docker などの仮想環境専用にすることが推奨されます。これらは、ファイルシステムを再フォーマットしません。" - -#: ../../rst/dev_guide/testing_integration.rst:106 -msgid "Windows Tests" -msgstr "Windows テスト" - -#: ../../rst/dev_guide/testing_integration.rst:108 -msgid "These tests exercise the ``winrm`` connection plugin and Windows modules. You'll need to define an inventory with a remote Windows 2008 or 2012 Server to use for testing, and enable PowerShell Remoting to continue." -msgstr "これらのテストは、``winrm`` 接続プラグインと Windows モジュールに従います。テストに使用するリモート Windows 2008 Server または 2012 Server を持つインベントリーを定義し、PowerShell Remoting を継続できるようにする必要があります。" - -#: ../../rst/dev_guide/testing_integration.rst:112 -msgid "Running these tests may result in changes to your Windows host, so don't run them against a production/critical Windows environment." -msgstr "これらのテストを実行すると、Windows ホストが変更になる可能性があるため、実稼働環境や重要な Windows 環境では実行しないでください。" - -#: ../../rst/dev_guide/testing_integration.rst:115 -msgid "Enable PowerShell Remoting (run on the Windows host via Remote Desktop)::" -msgstr "PowerShell Remoting を有効にします (リモートデスクトップを介して Windows ホストで実行します)::" - -#: ../../rst/dev_guide/testing_integration.rst:119 -msgid "Define Windows inventory::" -msgstr "Windows インベントリーを定義します。" - -#: ../../rst/dev_guide/testing_integration.rst:124 -msgid "Run the Windows tests executed by our CI system::" -msgstr "CI システムで実行する Windows テストを実行します::" - -#: ../../rst/dev_guide/testing_integration.rst:129 -msgid "Tests in Docker containers" -msgstr "Docker コンテナーでのテスト" - -#: ../../rst/dev_guide/testing_integration.rst:131 -msgid "If you have a Linux system with Docker installed, running integration tests using the same Docker containers used by the Ansible continuous integration (CI) system is recommended." -msgstr "Docker がインストールされた Linux システムをお持ちの場合は、Ansible の継続的インテグレーション (CI) システムで使用されているものと同じ Docker コンテナーを使用して統合テストを実行することが推奨されます。" - -#: ../../rst/dev_guide/testing_integration.rst:134 -msgid "Docker on non-Linux" -msgstr "Linux 以外の Docker" - -#: ../../rst/dev_guide/testing_integration.rst:136 -msgid "Using Docker Engine to run Docker on a non-Linux host (such as macOS) is not recommended. Some tests may fail, depending on the image used for testing. Using the ``--docker-privileged`` option when running ``integration`` (not ``network-integration`` or ``windows-integration``) may resolve the issue." -msgstr "Docker Engine を使用して (macOS などの) Linux 以外のホストで Docker を実行することは推奨されません。テストに使用されるイメージによっては、一部のテストが失敗する可能性があります。(``network-integration`` または ``windows-integration``ではなく) ``integration`` の実行時に ``--docker-privileged`` オプションを使用すると問題が解決する可能性があります。" - -#: ../../rst/dev_guide/testing_integration.rst:141 -msgid "Running Integration Tests" -msgstr "統合テストの実行" - -#: ../../rst/dev_guide/testing_integration.rst:143 -msgid "To run all CI integration test targets for POSIX platforms in a Ubuntu 18.04 container::" -msgstr "Ubuntu 18.04 コンテナー内の POSIX プラットフォームに CI 統合テストターゲットすべてを実行するには、次のコマンドを実行します。" - -#: ../../rst/dev_guide/testing_integration.rst:147 -msgid "You can also run specific tests or select a different Linux distribution. For example, to run tests for the ``ping`` module on a Ubuntu 18.04 container::" -msgstr "特定のテストを実行することも、別の Linux ディストリビューションを選択することもできます。たとえば、Ubuntu 18.04 コンテナーで ``ping`` モジュールのテストを実行するには、次を実行します。" - -#: ../../rst/dev_guide/testing_integration.rst:153 -msgid "Container Images" -msgstr "コンテナーイメージ" - -#: ../../rst/dev_guide/testing_integration.rst:156 -msgid "Python 2" -msgstr "Python 2" - -#: ../../rst/dev_guide/testing_integration.rst:158 -msgid "Most container images are for testing with Python 2:" -msgstr "ほとんどのコンテナーイメージは、Python 2 でテストするためのものです。" - -#: ../../rst/dev_guide/testing_integration.rst:160 -msgid "centos6" -msgstr "centos6" - -#: ../../rst/dev_guide/testing_integration.rst:161 -msgid "centos7" -msgstr "centos7" - -#: ../../rst/dev_guide/testing_integration.rst:162 -msgid "fedora28" -msgstr "fedora28" - -#: ../../rst/dev_guide/testing_integration.rst:163 -msgid "opensuse15py2" -msgstr "opensuse15py2" - -#: ../../rst/dev_guide/testing_integration.rst:164 -msgid "ubuntu1404" -msgstr "ubuntu1404" - -#: ../../rst/dev_guide/testing_integration.rst:165 -msgid "ubuntu1604" -msgstr "ubuntu1604" - -#: ../../rst/dev_guide/testing_integration.rst:168 -msgid "Python 3" -msgstr "Python 3" - -#: ../../rst/dev_guide/testing_integration.rst:170 -msgid "To test with Python 3 use the following images:" -msgstr "Python 3 でテストするには、以下のイメージを使用します。" - -#: ../../rst/dev_guide/testing_integration.rst:172 -msgid "centos8" -msgstr "centos8" - -#: ../../rst/dev_guide/testing_integration.rst:173 -msgid "fedora32" -msgstr "fedora32" - -#: ../../rst/dev_guide/testing_integration.rst:174 -msgid "opensuse15" -msgstr "opensuse15" - -#: ../../rst/dev_guide/testing_integration.rst:175 -msgid "ubuntu1804" -msgstr "ubuntu1804" - -#: ../../rst/dev_guide/testing_integration.rst:179 -msgid "Legacy Cloud Tests" -msgstr "レガシーのクラウドテスト" - -#: ../../rst/dev_guide/testing_integration.rst:181 -msgid "Some of the cloud tests run as normal integration tests, and others run as legacy tests; see the :ref:`testing_integration_legacy` page for more information." -msgstr "一部のクラウドテストは通常の統合テストとして実行し、その他はレガシーテストとして実行します。詳細は、「:ref:`testing_integration_legacy`」のドキュメントを参照してください。" - -#: ../../rst/dev_guide/testing_integration.rst:186 -msgid "Other configuration for Cloud Tests" -msgstr "クラウドテストのその他の設定" - -#: ../../rst/dev_guide/testing_integration.rst:188 -msgid "In order to run some tests, you must provide access credentials in a file named ``cloud-config-aws.yml`` or ``cloud-config-cs.ini`` in the test/integration directory. Corresponding .template files are available for for syntax help. The newer AWS tests now use the file test/integration/cloud-config-aws.yml" -msgstr "test/integration ディレクトリーにある ``cloud-config-aws.yml`` または ``cloud-config-cs.ini`` という名前のファイルにあるアクセス認証情報を指定する必要があります。構文ヘルプでは、対応する .template ファイルを利用できます。新しい AWS テストでは、test/integration/cloud-config-aws.yml ファイルが使用されるようになりました。" - -#: ../../rst/dev_guide/testing_integration.rst:194 -#: ../../rst/dev_guide/testing_integration_legacy.rst:58 -msgid "IAM policies for AWS" -msgstr "AWS の IAM ポリシー" - -#: ../../rst/dev_guide/testing_integration.rst:196 -msgid "Ansible needs fairly wide ranging powers to run the tests in an AWS account. This rights can be provided to a dedicated user. These need to be configured before running the test." -msgstr "Ansible は、AWS アカウントでテストを実行するために非常に幅広い権限が必要になります。この権限は専用のユーザーに提供できます。これらの権限は、テストを実行する前に設定する必要があります。" - -#: ../../rst/dev_guide/testing_integration.rst:199 -msgid "testing-policies" -msgstr "testing-policies" - -#: ../../rst/dev_guide/testing_integration.rst:201 -msgid "The GitHub repository `mattclay/aws-terminator `_ contains two sets of policies used for all existing AWS module integratoin tests. The `hacking/aws_config/setup_iam.yml` playbook can be used to setup two groups:" -msgstr "GitHub リポジトリー `mattclay/aws-terminator `_ には、既存の AWS モジュールの統合テストに使用するポリシーのセットが 2 つ含まれます。Playbook `hacking/aws_config/setup_iam.yml` を使用すると、2 つのグループを設定できます。" - -#: ../../rst/dev_guide/testing_integration.rst:205 -msgid "`ansible-integration-ci` will have the policies applied necessary to run any integration tests not marked as `unsupported` and are designed to mirror those used by Ansible's CI." -msgstr "`ansible-integration-ci` は、インテグレーションテストの実行に必要となるポリシーを適用すると共に、`unsupported` と識別されず、Ansible の CI で使用されるミラーリング用に設計されています。" - -#: ../../rst/dev_guide/testing_integration.rst:208 -msgid "`ansible-integration-unsupported` will have the additional policies applied necessary to run the integration tests marked as `unsupported` including tests for managing IAM roles, users and groups." -msgstr "`ansible-integration-unsupported` は、IAM ロール、ユーザー、およびグループの管理のテストを含む `unsupported` とマークされた統合テストの実行に必要な追加のポリシーが適用されます。" - -#: ../../rst/dev_guide/testing_integration.rst:212 -msgid "Once the groups have been created, you'll need to create a user and make the user a member of these groups. The policies are designed to minimize the rights of that user. Please note that while this policy does limit the user to one region, this does not fully restrict the user (primarily due to the limitations of the Amazon ARN notation). The user will still have wide privileges for viewing account definitions, and will also able to manage some resources that are not related to testing (for example, AWS lambdas with different names). Tests should not be run in a primary production account in any case." -msgstr "グループが作成されたら、ユーザーを作成して、そのユーザーをこれらのグループのメンバーにする必要があります。ポリシーは、そのユーザーの権利を最小限にするためのものです。このポリシーでは、ユーザーを 1 つの地域に限定していますが、これはユーザーを完全には制限していないことに注意してください (主にAmazon ARN 表記の制限によるものです)。このユーザーは、アカウント定義を閲覧するための広い権限を持っており、テストに関係のないいくつかのリソース (たとえば、異なる名前の AWS ラムダ) を管理することもできます。どのような場合でも、テストを実稼働環境用のプライマリーアカウントで実行すべきではありません。" - -#: ../../rst/dev_guide/testing_integration.rst:220 -#: ../../rst/dev_guide/testing_integration_legacy.rst:76 -msgid "Other Definitions required" -msgstr "その他の必要な定義" - -#: ../../rst/dev_guide/testing_integration.rst:222 -#: ../../rst/dev_guide/testing_integration_legacy.rst:78 -msgid "Apart from installing the policy and giving it to the user identity running the tests, a lambda role `ansible_integration_tests` has to be created which has lambda basic execution privileges." -msgstr "ポリシーをインストールしてテストを実行しているユーザ ID に付与することとは別に、ラムダロール `ansible_integration_tests` を作成する必要があります。これは、ラムダの基本的な実行権限を持ちます。" - -#: ../../rst/dev_guide/testing_integration.rst:228 -msgid "Network Tests" -msgstr "ネットワークテスト" - -#: ../../rst/dev_guide/testing_integration.rst:230 -msgid "For guidance on writing network test see :ref:`testing_resource_modules`." -msgstr "ネットワークテストの書き込みに関する情報は、「:ref:`testing_resource_modules`」を参照してください。" - -#: ../../rst/dev_guide/testing_integration.rst:234 -msgid "Where to find out more" -msgstr "その他の詳細情報" - -#: ../../rst/dev_guide/testing_integration.rst:236 -msgid "If you'd like to know more about the plans for improving testing Ansible, join the `Testing Working Group `_." -msgstr "Ansible テストを改善する詳細な計画を確認したい場合は、`テストのワーキンググループ `_ にご参加ください。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:7 -msgid "Testing using the Legacy Integration system" -msgstr "レガシー統合システムを使用したテスト" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:11 -msgid "This page details how to run the integration tests that haven't been ported to the new ``ansible-test`` framework." -msgstr "このページでは、新しい ``ansible-test`` フレームワークに移植されていない統合テストの実行方法を説明します。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:13 -msgid "The following areas are still tested using the legacy ``make tests`` command:" -msgstr "以下のエリアは、レガシーの ``make tests`` コマンドを使用してテストされています。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:15 -msgid "amazon (some)" -msgstr "Amazon (一部)" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:16 -msgid "azure" -msgstr "azure" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:17 -msgid "cloudflare" -msgstr "cloudflare" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:18 -msgid "cloudscale" -msgstr "cloudscale" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:19 -msgid "cloudstack" -msgstr "cloudstack" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:20 -msgid "consul" -msgstr "consul" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:21 -msgid "exoscale" -msgstr "exoscale" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:22 -msgid "gce" -msgstr "gce" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:23 -msgid "jenkins" -msgstr "jenkins" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:24 -msgid "rackspace" -msgstr "rackspace" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:26 -msgid "Over time the above list will be reduced as tests are ported to the ``ansible-test`` framework." -msgstr "テストが ``ansible-test`` フレームワークに移植されると、上記のリストは徐々に少なくなっていきます。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:30 -msgid "Running Cloud Tests" -msgstr "クラウドテストの実行" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:32 -msgid "Cloud tests exercise capabilities of cloud modules (for example, ec2_key). These are not 'tests run in the cloud' so much as tests that leverage the cloud modules and are organized by cloud provider." -msgstr "クラウドテストは、クラウドモジュール (ec2_key など) の機能を実行します。これらは、クラウドモジュールを活用し、クラウドプロバイダーによって編成されたテストほど、「クラウドで実行されるテスト」ではありません。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:36 -msgid "Some AWS tests may use environment variables. It is recommended to either unset any AWS environment variables( such as ``AWS_DEFAULT_PROFILE``, ``AWS_SECRET_ACCESS_KEY``, and so on) or be sure that the environment variables match the credentials provided in ``credentials.yml`` to ensure the tests run with consistency to their full capability on the expected account. See `AWS CLI docs `_ for information on creating a profile." -msgstr "AWS テストによっては、環境変数を使用するものもあります。AWS 環境変数 (``AWS_DEFAULT_PROFILE``、``AWS_SECRET_ACCESS_KEY`` など) の設定を解除するか、環境変数が ``credentials.yml`` で提供される認証情報と一致することを確認して、予想されるアカウントの完全な機能に一貫性のあるテストが実行されるようにすることが推奨されます。プロファイルの作成に関する情報は、`AWS CLI ドキュメント `_ を参照してください。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:38 -msgid "Subsets of tests may be run by ``#commenting`` out unnecessary roles in the appropriate playbook, such as ``test/integration/amazon.yml``." -msgstr "テストのサブセットは、適切な Playbook の ``test/integration/amazon.yml`` 不要なロール (例: test/integration/amazon.yml) をコメントアウトして実行できます。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:40 -msgid "In order to run cloud tests, you must provide access credentials in a file named ``credentials.yml``. A sample credentials file named ``credentials.template`` is available for syntax help." -msgstr "クラウドテストを実行するには、``credentials.yml`` の名前のファイルでアクセス認証情報を指定する必要があります。``credentials.template`` と名前の付いたサンプル認証情報ファイルの構文ヘルプに利用できます。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:44 -msgid "Provide cloud credentials::" -msgstr "クラウド認証を提供します::" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:51 -msgid "Other configuration" -msgstr "その他の設定" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:53 -msgid "In order to run some tests, you must provide access credentials in a file named ``credentials.yml``. A sample credentials file named ``credentials.template`` is available for syntax help." -msgstr "いくつかのテストを実行するには、``credentials.yml`` の名前のファイルでアクセス認証情報を指定する必要があります。``credentials.template`` と名前の付いたサンプル認証情報ファイルの構文ヘルプに利用できます。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:60 -msgid "In order to run the tests in an AWS account ansible needs fairly wide ranging powers which can be provided to a dedicated user or temporary credentials using a specific policy configured in the AWS account." -msgstr "AWS アカウントでテストを実行するためには、Ansible に、AWS アカウントで設定された特定のポリシーを使用して、専用のユーザや一時的な認証情報に提供できる、かなり広範囲の権限が必要となります。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:65 -msgid "testing-iam-policy.json.j2" -msgstr "testing-iam-policy.json.j2" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:67 -msgid "The testing-iam-policy.json.j2 file contains a policy which can be given to the user running the tests to give close to minimum rights required to run the tests. Please note that this does not fully restrict the user; The user has wide privileges for viewing account definitions and is also able to manage some resources that are not related to testing (for example, AWS lambdas with different names) primarily due to the limitations of the Amazon ARN notation. At the very least the policy limits the user to one region, however tests should not be run in a primary production account in any case." -msgstr "testing-iam-policy.json.j2 ファイルには、テストを実行するユーザーに付与するポリシーが含まれており、テストの実行に必要な最低限の権限に近いものを付与することができます。なお、これは完全な制限ではないため注意が必要です。このユーザーは、アカウント定義を閲覧する幅広い権限を持ち、主に Amazon ARN 表記の制限により、テストに関係のない一部のリソース (たとえば、異なる名前の AWS ラムダ) を管理することもできます。少なくとも、このポリシーではユーザーを 1 つのリージョンに限定していますが、いかなる場合でも、テストは実稼働環境のプライマリーアカウントで実行すべきではありません。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:84 -#: ../../rst/dev_guide/testing_units.rst:24 -msgid "Running Tests" -msgstr "テストの実行" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:86 -msgid "The tests are invoked via a ``Makefile``." -msgstr "テストは ``Makefile`` 経由で呼び出されます。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:88 -msgid "If you haven't already got Ansible available use the local checkout by doing::" -msgstr "Ansible がまだ利用可能でない場合は、以下の方法でローカルチェックアウトを使用します。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:92 -msgid "Run the tests by doing::" -msgstr "以下を実行してテストを実行します。" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:102 -msgid "Possible cost of running cloud tests" -msgstr "クラウドテストにかかる可能性のあるコスト" - -#: ../../rst/dev_guide/testing_integration_legacy.rst:104 -msgid "Running cloud integration tests will create and destroy cloud resources. Running these tests may result in additional fees associated with your cloud account. Care is taken to ensure that created resources are removed. However, it is advisable to inspect your AWS console to ensure no unexpected resources are running." -msgstr "クラウド統合テストを実行すると、クラウドリソースが作成および破棄されます。このようなテストを実行すると、クラウドアカウントに関連する追加料金が発生する可能性があります。作成されたリソースが確実に削除されるように注意が払われます。ただし、AWS コンソールを調べて、予期しないリソースが実行されていないことを確認することが推奨されます。" - -#: ../../rst/dev_guide/testing_pep8.rst:7 -msgid "PEP 8" -msgstr "PEP 8" - -#: ../../rst/dev_guide/testing_pep8.rst:11 -msgid "`PEP 8`_ style guidelines are enforced by `pycodestyle`_ on all python files in the repository by default." -msgstr "`PEP 8`_ スタイルのガイドラインは、デフォルトでリポジトリーにあるすべての python ファイルで `pycodestyle`_ によって強制されます。" - -#: ../../rst/dev_guide/testing_pep8.rst:14 -msgid "Running Locally" -msgstr "ローカルでの実行" - -#: ../../rst/dev_guide/testing_pep8.rst:16 -msgid "The `PEP 8`_ check can be run locally with::" -msgstr "`PEP 8`_ チェックは、以下を使用してローカルで実行できます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:9 -msgid "This document describes how to:" -msgstr "本書では、以下を行う方法を説明します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:11 -msgid "Run tests locally using ``ansible-test``" -msgstr "``ansible-test`` を使用してテストをローカルで実行します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:12 -msgid "Extend" -msgstr "拡張します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:20 -msgid "There are no special requirements for running ``ansible-test`` on Python 2.7 or later. The ``argparse`` package is required for Python 2.6. The requirements for each ``ansible-test`` command are covered later." -msgstr "Python 2.7 以降では、``ansible-test`` を実行するための特別な要件がありません。Python 2.6 には ``argparse`` パッケージが必要です。各 ``ansible-test`` コマンドの要件は、後で説明します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:26 -msgid "Test Environments" -msgstr "テスト環境" - -#: ../../rst/dev_guide/testing_running_locally.rst:28 -msgid "Most ``ansible-test`` commands support running in one or more isolated test environments to simplify testing." -msgstr "ほとんどの ``ansible-test`` コマンドは、テストを簡単にするために、1 つ以上の分離テスト環境での実行をサポートします。" - -#: ../../rst/dev_guide/testing_running_locally.rst:32 -msgid "Remote" -msgstr "リモート" - -#: ../../rst/dev_guide/testing_running_locally.rst:34 -msgid "The ``--remote`` option runs tests in a cloud hosted environment. An API key is required to use this feature." -msgstr "``--remote`` オプションは、クラウドホスト環境でテストを実行します。この機能を使用するには API キーが必要です。" - -#: ../../rst/dev_guide/testing_running_locally.rst:37 -msgid "Recommended for integration tests." -msgstr "統合テストに推奨されます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:39 -msgid "See the `list of supported platforms and versions `_ for additional details." -msgstr "詳細は、「`サポート対象のプラットフォームおよびバージョンの一覧 `_」を参照してください。" - -#: ../../rst/dev_guide/testing_running_locally.rst:42 -msgid "Environment Variables" -msgstr "環境変数" - -#: ../../rst/dev_guide/testing_running_locally.rst:44 -msgid "When using environment variables to manipulate tests there some limitations to keep in mind. Environment variables are:" -msgstr "環境変数を使用してテストを操作する際には、以下の制限事項に留意してください。環境変数は以下のようになります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:46 -msgid "Not propagated from the host to the test environment when using the ``--docker`` or ``--remote`` options." -msgstr "``--docker`` オプションまたは ``--remote`` オプションを使用する場合は、ホストからテスト環境に伝播されません。" - -#: ../../rst/dev_guide/testing_running_locally.rst:47 -msgid "Not exposed to the test environment unless enabled in ``test/lib/ansible_test/_internal/util.py`` in the ``common_environment`` function." -msgstr "``common_environment`` 関数の ``test/lib/ansible_test/_internal/util.py`` で有効にされていない限り、テスト環境には公開されません。" - -#: ../../rst/dev_guide/testing_running_locally.rst:49 -msgid "Example: ``ANSIBLE_KEEP_REMOTE_FILES=1`` can be set when running ``ansible-test integration --venv``. However, using the ``--docker`` option would require running ``ansible-test shell`` to gain access to the Docker environment. Once at the shell prompt, the environment variable could be set and the tests executed. This is useful for debugging tests inside a container by following the :ref:`Debugging AnsibleModule-based modules ` instructions." -msgstr "例: ``ansible-test integration --venv`` の実行時に ``ANSIBLE_KEEP_REMOTE_FILES=1`` を設定できますが、``--docker`` オプションを使用すると、``ansible-test shell`` を実行し、Docker 環境へのアクセスが必要になります。シェルプロンプトでは、環境変数を設定してテストを行う可能性があります。これは、:ref:`Debugging AnsibleModule-based modules ` の指示に従って、コンテナー内でテストを実行する上で役立ちます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:55 -msgid "Interactive Shell" -msgstr "インタラクティブシェル" - -#: ../../rst/dev_guide/testing_running_locally.rst:57 -msgid "Use the ``ansible-test shell`` command to get an interactive shell in the same environment used to run tests. Examples:" -msgstr "``ansible-test shell`` コマンドを使用して、テストを実行するのに使用する同じ環境でインタラクティブシェルを取得します。以下は例になります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:59 -msgid "``ansible-test shell --docker`` - Open a shell in the default docker container." -msgstr "``ansible-test shell --docker`` - デフォルトの docker コンテナーでシェルを開きます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:60 -msgid "``ansible-test shell --venv --python 3.6`` - Open a shell in a Python 3.6 virtual environment." -msgstr "``ansible-test shell --venv --python 3.6`` - Python 3.6 仮想環境でシェルを開きます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:64 -msgid "Code Coverage" -msgstr "コードの対象範囲" - -#: ../../rst/dev_guide/testing_running_locally.rst:66 -msgid "Code coverage reports make it easy to identify untested code for which more tests should be written. Online reports are available but only cover the ``devel`` branch (see :ref:`developing_testing`). For new code local reports are needed." -msgstr "コードの対象範囲レポートは、より多くのテストが記述されるべき未テストのコードを簡単に識別することができます。オンラインレポートが利用可能ですが、``devel`` ブランチのみを扱います (:ref:`developing_testing` を参照)。新規コードのローカルレポートが必要な場合は、以下を行います。" - -#: ../../rst/dev_guide/testing_running_locally.rst:70 -msgid "Add the ``--coverage`` option to any test command to collect code coverage data. If you aren't using the ``--venv`` or ``--docker`` options which create an isolated python environment then you may have to use the ``--requirements`` option to ensure that the correct version of the coverage module is installed::" -msgstr "コードカバレッジデータを収集するテストコマンドに ``--coverage`` オプションを追加します。分離した python 環境を作成する ``--venv`` オプションまたは ``--docker`` オプションを使用していない場合は、``--requirements`` オプションを使用してカバレッジモジュールの正しいバージョンがインストールされていることを確認する必要があります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:81 -#: ../../rst/dev_guide/testing_units.rst:191 -msgid "Reports can be generated in several different formats:" -msgstr "Report は、複数の形式で生成できます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:83 -#: ../../rst/dev_guide/testing_units.rst:193 -msgid "``ansible-test coverage report`` - Console report." -msgstr "``ansible-test coverage report`` - コンソールレポート。" - -#: ../../rst/dev_guide/testing_running_locally.rst:84 -#: ../../rst/dev_guide/testing_units.rst:194 -msgid "``ansible-test coverage html`` - HTML report." -msgstr "``ansible-test coverage html`` - HTML レポート。" - -#: ../../rst/dev_guide/testing_running_locally.rst:85 -#: ../../rst/dev_guide/testing_units.rst:195 -msgid "``ansible-test coverage xml`` - XML report." -msgstr "``ansible-test coverage xml`` - XML レポート。" - -#: ../../rst/dev_guide/testing_running_locally.rst:87 -msgid "To clear data between test runs, use the ``ansible-test coverage erase`` command. For a full list of features see the online help::" -msgstr "テスト実行間のデータを消去するには、``ansible-test coverage erase`` コマンドを使用します。機能の全一覧については、オンラインのヘルプを参照してください。" - -#: ../../rst/dev_guide/testing_sanity.rst:11 -msgid "Sanity tests are made up of scripts and tools used to perform static code analysis. The primary purpose of these tests is to enforce Ansible coding standards and requirements." -msgstr "サニティーテストは、静的コード分析の実行に使用されるスクリプトおよびツールで構成されています。これらのテストの主な目的は、Ansible コーディングの仕様および要件を適用することです。" - -#: ../../rst/dev_guide/testing_sanity.rst:14 -msgid "Tests are run with ``ansible-test sanity``. All available tests are run unless the ``--test`` option is used." -msgstr "テストは、``ansible-test sanity`` で実行します。``--test`` オプションを使用しない限り、利用可能なテストはすべて実行します。" - -#: ../../rst/dev_guide/testing_sanity.rst:19 -msgid "How to run" -msgstr "実行方法" - -#: ../../rst/dev_guide/testing_sanity.rst:22 -msgid "To run sanity tests using docker, always use the default docker image by passing the ``--docker`` or ``--docker default`` argument." -msgstr "docker を使用して健常性テストを実行するには、常に ``--docker`` 引数または ``--docker default`` 引数を渡すことでデフォルトの docker イメージを常に使用します。" - -#: ../../rst/dev_guide/testing_sanity.rst:26 -msgid "When using docker and the ``--base-branch`` argument, also use the ``--docker-keep-git`` argument to avoid git related errors." -msgstr "docker および ``--base-branch`` 引数を使用する場合は、git 関連のエラーを回避するために ``--docker-keep-git`` 引数も使用します。" - -#: ../../rst/dev_guide/testing_sanity.rst:49 -#: ../../rst/dev_guide/testing_units.rst:17 -msgid "Available Tests" -msgstr "利用可能なテスト" - -#: ../../rst/dev_guide/testing_sanity.rst:51 -msgid "Tests can be listed with ``ansible-test sanity --list-tests``." -msgstr "テストは ``ansible-test sanity --list-tests`` で一覧表示できます。" - -#: ../../rst/dev_guide/testing_sanity.rst:53 -msgid "See the full list of :ref:`sanity tests `, which details the various tests and details how to fix identified issues." -msgstr "各種テストや特定された問題を解決する方法の詳細は、「:ref:`サニティーテスト `」の一覧を参照してください。" - -#: ../../rst/dev_guide/testing_units.rst:7 -msgid "Unit Tests" -msgstr "ユニットテスト" - -#: ../../rst/dev_guide/testing_units.rst:9 -msgid "Unit tests are small isolated tests that target a specific library or module. Unit tests in Ansible are currently the only way of driving tests from python within Ansible's continuous integration process. This means that in some circumstances the tests may be a bit wider than just units." -msgstr "ユニットテストは、特定のライブラリーまたはモジュールを対象とする小規模の分離テストです。現在、Ansible のユニットテストは、Ansible の継続的インテグレーションプロセスの中で、python からテストを実行する唯一の方法です。つまり、状況によっては、テストにはユニット以外のものも含まれます。" - -#: ../../rst/dev_guide/testing_units.rst:19 -msgid "Unit tests can be found in `test/units `_. Notice that the directory structure of the tests matches that of ``lib/ansible/``." -msgstr "ユニットテストは `test/units `_ にあります。テストのディレクトリー構造が ``lib/ansible/`` と一致することに注意してください。" - -#: ../../rst/dev_guide/testing_units.rst:27 -msgid "To run unit tests using docker, always use the default docker image by passing the ``--docker`` or ``--docker default`` argument." -msgstr "docker を使用してユニットテストを実行するには、``--docker`` 引数または ``--docker default`` 引数を渡すことで常にデフォルトの docker イメージを使用します。" - -#: ../../rst/dev_guide/testing_units.rst:30 -msgid "The Ansible unit tests can be run across the whole code base by doing:" -msgstr "Ansible のユニットテストは、以下の操作を実行してコードベース全体で実行できます。" - -#: ../../rst/dev_guide/testing_units.rst:50 -msgid "If you are running unit tests against things other than modules, such as module utilities, specify the whole file path:" -msgstr "モジュールユーティリティーなどのモジュール以外のものに対してユニットテストを実行している場合は、ファイルパス全体を指定します。" - -#: ../../rst/dev_guide/testing_units.rst:56 -msgid "For advanced usage see the online help::" -msgstr "高度な使用方法は、オンラインヘルプを参照してください。" - -#: ../../rst/dev_guide/testing_units.rst:60 -msgid "You can also run tests in Ansible's continuous integration system by opening a pull request. This will automatically determine which tests to run based on the changes made in your pull request." -msgstr "プル要求を開いて、Ansible の継続的統合システムでテストを実行することもできます。これにより、プル要求で実行された変更に基づいて、実行されるテストが自動的に決定されます。" - -#: ../../rst/dev_guide/testing_units.rst:68 -msgid "If you are running ``ansible-test`` with the ``--docker`` or ``--venv`` option you do not need to install dependencies manually." -msgstr "``--docker`` オプションまたは ``--venv`` オプションを指定して ``ansible-test`` を実行している場合は、依存関係を手動でインストールする必要はありません。" - -#: ../../rst/dev_guide/testing_units.rst:70 -msgid "Otherwise you can install dependencies using the ``--requirements`` option, which will install all the required dependencies needed for unit tests. For example:" -msgstr "それ以外の場合は、``--requirements`` オプションを使用して依存関係をインストールし、ユニットテストに必要な依存関係をすべてインストールします。以下に例を示します。" - -#: ../../rst/dev_guide/testing_units.rst:78 -msgid "The list of unit test requirements can be found at `test/units/requirements.txt `_." -msgstr "ユニットテストの要件一覧は、`test/units/requirements.txt `_ を参照してください。" - -#: ../../rst/dev_guide/testing_units.rst:81 -msgid "This does not include the list of unit test requirements for ``ansible-test`` itself, which can be found at `test/lib/ansible_test/_data/requirements/units.txt `_." -msgstr "これには、``ansible-test`` のユニットテスト要件のリストは含まれていません。それは、`test/lib/ansible_test/_data/requirements/units.txt `_ で見つけることができます。" - -#: ../../rst/dev_guide/testing_units.rst:85 -msgid "See also the `constraints `_ applicable to all test commands." -msgstr "すべてのコマンドに適用可能な「`制約 `_」も参照してください。" - -#: ../../rst/dev_guide/testing_units.rst:91 -msgid "Extending unit tests" -msgstr "ユニットテストの拡張" - -#: ../../rst/dev_guide/testing_units.rst:94 -msgid "What a unit test isn't" -msgstr "ユニットテスト以外のもの" - -#: ../../rst/dev_guide/testing_units.rst:96 -msgid "If you start writing a test that requires external services then you may be writing an integration test, rather than a unit test." -msgstr "外部サービスを必要とするテストを書き始めると、ユニットテストではなく統合テストを書くことができます。" - -#: ../../rst/dev_guide/testing_units.rst:101 -msgid "Structuring Unit Tests" -msgstr "ユニットテストの構造" - -#: ../../rst/dev_guide/testing_units.rst:103 -msgid "Ansible drives unit tests through `pytest `_. This means that tests can either be written a simple functions which are included in any file name like ``test_.py`` or as classes." -msgstr "Ansible は、`pytest `_ でユニットテストを行います。これは、テストは、``test_.py`` のファイル名またはクラスとして含まれる単純な関数を記述できることを意味します。" - -#: ../../rst/dev_guide/testing_units.rst:107 -msgid "Here is an example of a function::" -msgstr "以下は、関数の例です。" - -#: ../../rst/dev_guide/testing_units.rst:117 -msgid "Here is an example of a class::" -msgstr "以下はクラスの例です::" - -#: ../../rst/dev_guide/testing_units.rst:137 -msgid "Both methods work fine in most circumstances; the function-based interface is simpler and quicker and so that's probably where you should start when you are just trying to add a few basic tests for a module. The class-based test allows more tidy set up and tear down of pre-requisites, so if you have many test cases for your module you may want to refactor to use that." -msgstr "どちらの方法も、ほとんどの状況で正常に機能します。関数ベースのインターフェースの方がシンプルで速いため、モジュールにいくつかの基本的なテストを追加しようとしている場合は、ここから始めることが推奨されます。クラスベースのテストでは、前提条件の設定や分解をより整然と行うことができるため、モジュールに多くのテストケースがある場合は、それを使用するようにリファクタリングすることが推奨されます。" - -#: ../../rst/dev_guide/testing_units.rst:143 -msgid "Assertions using the simple ``assert`` function inside the tests will give full information on the cause of the failure with a trace-back of functions called during the assertion. This means that plain asserts are recommended over other external assertion libraries." -msgstr "テスト内の簡単な ``assert`` 関数を使用するアサーションにより、アサーション中に呼び出される関数のトレースバックで障害に関する完全な情報が表示されます。これは、他の外部アサーションライブラリーよりも、プレーンアサートが推奨されることを意味します。" - -#: ../../rst/dev_guide/testing_units.rst:148 -msgid "A number of the unit test suites include functions that are shared between several modules, especially in the networking arena. In these cases a file is created in the same directory, which is then included directly." -msgstr "多くのユニットテストスイートには、特にネットワークの分野では、複数のモジュール間で共有される関数が含まれています。この場合は、同じディレクトリーにファイルが作成ます。このファイルは、直接含まれます。" - -#: ../../rst/dev_guide/testing_units.rst:154 -msgid "Module test case common code" -msgstr "それが直接インクルードされます。" - -#: ../../rst/dev_guide/testing_units.rst:156 -msgid "Keep common code as specific as possible within the `test/units/` directory structure. Don't import common unit test code from directories outside the current or parent directories." -msgstr "`test/units/` ディレクトリー構造内で可能な限り具体的に共通コードを維持します。現在のディレクトリーまたは親ディレクトリー以外のディレクトリーから共通のユニットテストコードをインポートしないでください。" - -#: ../../rst/dev_guide/testing_units.rst:159 -msgid "Don't import other unit tests from a unit test. Any common code should be in dedicated files that aren't themselves tests." -msgstr "ユニットテストから他のユニットテストをインポートしないでください。共通のコードは、テスト自体ではない専用のファイルに含める必要があります。" - -#: ../../rst/dev_guide/testing_units.rst:164 -msgid "Fixtures files" -msgstr "Fixtures ファイル" - -#: ../../rst/dev_guide/testing_units.rst:166 -msgid "To mock out fetching results from devices, or provide other complex data structures that come from external libraries, you can use ``fixtures`` to read in pre-generated data." -msgstr "デバイスからの結果の取得を模倣したり、外部ライブラリーから取得した他の複雑なデータ構造を提供するために、``fixtures`` を使用して事前に生成されたデータを読み込むことができます。" - -#: ../../rst/dev_guide/testing_units.rst:169 -msgid "You can check how `fixtures `_ are used in `cpuinfo fact tests `_" -msgstr "`cpuinfo ファクトテスト `_ で、`修正 `_ が使用される方法を確認することができます。" - -#: ../../rst/dev_guide/testing_units.rst:172 -msgid "If you are simulating APIs you may find that Python placebo is useful. See :ref:`testing_units_modules` for more information." -msgstr "API のシミュレーションをしているのであれば、Python のプラシーボが役に立つかもしれません。詳細は、「:ref:`testing_units_modules`」を参照してください。" - -#: ../../rst/dev_guide/testing_units.rst:177 -msgid "Code Coverage For New or Updated Unit Tests" -msgstr "新規ユニットテストまたは更新されたユニットテスト用のコード対応" - -#: ../../rst/dev_guide/testing_units.rst:178 -msgid "New code will be missing from the codecov.io coverage reports (see :ref:`developing_testing`), so local reporting is needed. Most ``ansible-test`` commands allow you to collect code coverage; this is particularly useful when to indicate where to extend testing." -msgstr "codecov.io カバレッジレポートから新しいコードが欠落し (:ref:`developing_testing`を参照)、ローカルレポートが必要です。ほとんどの ``ansible-test`` コマンドを使用すると、コードカバレッジを収集できます。これは、テストを拡張する場所を示すときに特に役立ちます。" - -#: ../../rst/dev_guide/testing_units.rst:182 -msgid "To collect coverage data add the ``--coverage`` argument to your ``ansible-test`` command line:" -msgstr "カバレージデータを収集するには、``--coverage`` 引数を ``ansible-test`` コマンドラインに追加します。" - -#: ../../rst/dev_guide/testing_units.rst:189 -msgid "Results will be written to ``test/results/reports/coverage/index.html``" -msgstr "結果は ``test/results/reports/coverage/index.html`` に書き込まれます。" - -#: ../../rst/dev_guide/testing_units.rst:197 -msgid "To clear data between test runs, use the ``ansible-test coverage erase`` command. See :ref:`testing_running_locally` for more information about generating coverage reports." -msgstr "テスト実行間のデータを消去するには、``ansible-test coverage erase`` コマンドを使用します。カバレッジレポートの生成の詳細は、「:ref:`testing_running_locally`」を参照してください。" - -#: ../../rst/dev_guide/testing_units.rst:204 -msgid ":ref:`testing_units_modules`" -msgstr ":ref:`testing_units_modules`" - -#: ../../rst/dev_guide/testing_units.rst:205 -msgid "Special considerations for unit testing modules" -msgstr "ユニットテストモジュールに関する特別な考慮事項" - -#: ../../rst/dev_guide/testing_units.rst:206 -#: ../../rst/dev_guide/testing_units_modules.rst:543 -msgid ":ref:`testing_running_locally`" -msgstr ":ref:`testing_running_locally`" - -#: ../../rst/dev_guide/testing_units.rst:207 -#: ../../rst/dev_guide/testing_units_modules.rst:544 -msgid "Running tests locally including gathering and reporting coverage data" -msgstr "カバレージデータの収集とレポートを含む、ローカルでのテストの実行" - -#: ../../rst/dev_guide/testing_units.rst:208 -#: ../../rst/dev_guide/testing_units_modules.rst:547 -msgid "`Python 3 documentation - 26.4. unittest — Unit testing framework `_" -msgstr "`Python 3 documentation - 26.4. unittest — Unit testing framework `_" - -#: ../../rst/dev_guide/testing_units.rst:209 -#: ../../rst/dev_guide/testing_units_modules.rst:548 -msgid "The documentation of the unittest framework in python 3" -msgstr "Python 3 におけるユニットテストフレームワークのドキュメント" - -#: ../../rst/dev_guide/testing_units.rst:210 -#: ../../rst/dev_guide/testing_units_modules.rst:549 -msgid "`Python 2 documentation - 25.3. unittest — Unit testing framework `_" -msgstr "`Python 2 documentation - 25.3. unittest — Unit testing framework `_" - -#: ../../rst/dev_guide/testing_units.rst:211 -#: ../../rst/dev_guide/testing_units_modules.rst:550 -msgid "The documentation of the earliest supported unittest framework - from Python 2.6" -msgstr "サポートされている初期のユニットテストフレームワークのドキュメント (Python 2.6)" - -#: ../../rst/dev_guide/testing_units.rst:212 -#: ../../rst/dev_guide/testing_units_modules.rst:551 -msgid "`pytest: helps you write better programs `_" -msgstr "`pytest: helps you write better programs `_" - -#: ../../rst/dev_guide/testing_units.rst:213 -#: ../../rst/dev_guide/testing_units_modules.rst:552 -msgid "The documentation of pytest - the framework actually used to run Ansible unit tests" -msgstr "pytest のドキュメント - Ansible ユニットテストの実行に実際に使用されているフレームワーク" - -#: ../../rst/dev_guide/testing_units_modules.rst:7 -msgid "Unit Testing Ansible Modules" -msgstr "Ansible モジュールのユニットテスト" - -#: ../../rst/dev_guide/testing_units_modules.rst:16 -msgid "This document explains why, how and when you should use unit tests for Ansible modules. The document doesn't apply to other parts of Ansible for which the recommendations are normally closer to the Python standard. There is basic documentation for Ansible unit tests in the developer guide :ref:`testing_units`. This document should be readable for a new Ansible module author. If you find it incomplete or confusing, please open a bug or ask for help on Ansible IRC." -msgstr "このドキュメントでは、Ansible モジュールにユニットテストを使用する理由、方法、タイミングについて説明します。このドキュメントは、通常 Python の標準に近い推奨事項を持つA nsible の他の部分には適用されません。AnAnsible のユニットテストに関する基本的なドキュメントは、開発者ガイドの「:ref:`testing_units`」にあります。このドキュメントは、新しい Ansible モジュールの作成者にとって読みやすいものでなければなりません。不完全だったり、分かりにくかったりした場合は、バグを報告したり、Ansible IRC で助けを求めたりしてください。" - -#: ../../rst/dev_guide/testing_units_modules.rst:24 -msgid "What Are Unit Tests?" -msgstr "ユニットテストとは" - -#: ../../rst/dev_guide/testing_units_modules.rst:26 -msgid "Ansible includes a set of unit tests in the :file:`test/units` directory. These tests primarily cover the internals but can also cover Ansible modules. The structure of the unit tests matches the structure of the code base, so the tests that reside in the :file:`test/units/modules/` directory are organized by module groups." -msgstr "Ansible には、:file:`test/units` ディレクトリーにユニットテストのセットが含まれています。これらのテストは、主に内部に対応していますが、Ansible モジュールにも対応します。ユニットテストの構造はコードベースのベースの構造に一致し、:file:`test/units/modules/` ディレクトリーはモジュールグループごとに編成されます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:31 -msgid "Integration tests can be used for most modules, but there are situations where cases cannot be verified using integration tests. This means that Ansible unit test cases may extend beyond testing only minimal units and in some cases will include some level of functional testing." -msgstr "統合テストはほとんどのモジュールで使用できますが、統合テストではケースを検証できない場合もあります。つまり、Ansible ユニットテストケースは、最小限のユニットのみのテストにとどまらず、場合によっては、ある程度の機能テストが含まれることもあります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:38 -msgid "Why Use Unit Tests?" -msgstr "ユニットテストを使用する理由" - -#: ../../rst/dev_guide/testing_units_modules.rst:40 -msgid "Ansible unit tests have advantages and disadvantages. It is important to understand these. Advantages include:" -msgstr "Ansible ユニットテストには長所と短所があり、その点を理解することは重要です。以下が挙げられます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:43 -msgid "Most unit tests are much faster than most Ansible integration tests. The complete suite of unit tests can be run regularly by a developer on their local system." -msgstr "ほとんどのユニットテストは、ほとんどの Ansible 統合テストよりもはるかに高速です。ユニットテストの完全なスイートは、ローカルシステムで開発者が定期的に実行できます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:45 -msgid "Unit tests can be run by developers who don't have access to the system which the module is designed to work on, allowing a level of verification that changes to core functions haven't broken module expectations." -msgstr "ユニットテストは、モジュールが動作するように設計されているシステムにアクセスできない開発者が実行することができ、コア機能への変更がモジュールの期待どおりであることをある程度検証できます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:48 -msgid "Unit tests can easily substitute system functions allowing testing of software that would be impractical. For example, the ``sleep()`` function can be replaced and we check that a ten minute sleep was called without actually waiting ten minutes." -msgstr "ユニットテストは、システム関数を簡単に置換でき、実現するソフトウェアのテストを簡単に指定することができます。たとえば、``sleep()`` 関数を置き換えることができ、実際に 10 分待たずに 10 分のスリープが呼び出されたことを確認します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:51 -msgid "Unit tests are run on different Python versions. This allows us to ensure that the code behaves in the same way on different Python versions." -msgstr "ユニットテストは、Python の各バージョンで実行されます。これにより、コードが異なる Python のバージョンでも同じように動作することを確認できます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:54 -msgid "There are also some potential disadvantages of unit tests. Unit tests don't normally directly test actual useful valuable features of software, instead just internal implementation" -msgstr "ユニットテストには、いくつかの潜在的な欠点もあります。通常、実際に便利で価値のある機能を直接テストせず、代わりに内部実装をテストします。" - -#: ../../rst/dev_guide/testing_units_modules.rst:58 -msgid "Unit tests that test the internal, non-visible features of software may make refactoring difficult if those internal features have to change (see also naming in How below)" -msgstr "ソフトウェア内部にある、目に見えない機能をテストするユニットテストは、それらの内部機能を変更する必要がある場合、リファクタリングを困難にする可能性があります (以下の「方法」の命名も参照)。" - -#: ../../rst/dev_guide/testing_units_modules.rst:61 -msgid "Even if the internal feature is working correctly it is possible that there will be a problem between the internal code tested and the actual result delivered to the user" -msgstr "内部機能が正しく機能している場合でも、テストされた内部コードとユーザーに配信される実際の結果との間に問題が発生する可能性があります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:64 -msgid "Normally the Ansible integration tests (which are written in Ansible YAML) provide better testing for most module functionality. If those tests already test a feature and perform well there may be little point in providing a unit test covering the same area as well." -msgstr "通常、(Ansible YAML で記述される) Ansible 統合テストは、ほとんどのモジュール機能に対してより良いテストを提供します。これらのテストがすでに機能をテストしていて、うまく機能している場合は、同じ領域をカバーするユニットテストを提供する意味はほとんどないかもしれません。" - -#: ../../rst/dev_guide/testing_units_modules.rst:69 -msgid "When To Use Unit Tests" -msgstr "ユニットテストを使うタイミング" - -#: ../../rst/dev_guide/testing_units_modules.rst:71 -msgid "There are a number of situations where unit tests are a better choice than integration tests. For example, testing things which are impossible, slow or very difficult to test with integration tests, such as:" -msgstr "統合テストよりもユニットテストの方が適している状況は数多くあります。たとえば、次のような統合テストでテストすることが不可能、遅い、または非常に難しいものをテストします。" - -#: ../../rst/dev_guide/testing_units_modules.rst:75 -msgid "Forcing rare / strange / random situations that can't be forced, such as specific network failures and exceptions" -msgstr "特定のネットワーク障害や例外のような、強制することができない稀な、奇妙な、およびランダムな状況を強制。" - -#: ../../rst/dev_guide/testing_units_modules.rst:77 -msgid "Extensive testing of slow configuration APIs" -msgstr "遅い設定 API の広範なテスト。" - -#: ../../rst/dev_guide/testing_units_modules.rst:78 -msgid "Situations where the integration tests cannot be run as part of the main Ansible continuous integration running in Shippable." -msgstr "Shippable で実行されているメインの Ansible 継続的インテグレーションの一部として、統合テストを実行できない状況。" - -#: ../../rst/dev_guide/testing_units_modules.rst:84 -msgid "Providing quick feedback" -msgstr "迅速なフィードバックの提供" - -#: ../../rst/dev_guide/testing_units_modules.rst:87 -msgid "A single step of the rds_instance test cases can take up to 20 minutes (the time to create an RDS instance in Amazon). The entire test run can last for well over an hour. All 16 of the unit tests complete execution in less than 2 seconds." -msgstr "rds_instance のテストケースの 1 つのステップには、最大 20 分 (Amazonで RDS インスタンスを作成する時間) かかる場合があります。テストの実行は、全体で 1 時間以上かかることもあります。16 個のユニットテストは、すべて 2 秒以内に実行を完了します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:92 -msgid "The time saving provided by being able to run the code in a unit test makes it worth creating a unit test when bug fixing a module, even if those tests do not often identify problems later. As a basic goal, every module should have at least one unit test which will give quick feedback in easy cases without having to wait for the integration tests to complete." -msgstr "ユニットテストでコードを実行できることによって提供される時間の節約により、モジュールのバグ修正時にユニットテストを作成する価値があります。これらのテストで後で問題が特定されることはあまりありません。基本的な目標として、すべてのモジュールには少なくとも 1 つのユニットテストが必要です。これにより、統合テストが完了するのを待たずに、簡単なケースで迅速なフィードバックが得られます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:99 -msgid "Ensuring correct use of external interfaces" -msgstr "外部インターフェースを正しく使用すること" - -#: ../../rst/dev_guide/testing_units_modules.rst:101 -msgid "Unit tests can check the way in which external services are run to ensure that they match specifications or are as efficient as possible *even when the final output will not be changed*." -msgstr "ユニットテストは、*最終的な出力が変更されない場合でも*、外部サービスの実行方法が仕様に合致しているか、あるいは可能な限り効率的であるかを確認できます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:105 -msgid "Package managers are often far more efficient when installing multiple packages at once rather than each package separately. The final result is the same: the packages are all installed, so the efficiency is difficult to verify through integration tests. By providing a mock package manager and verifying that it is called once, we can build a valuable test for module efficiency." -msgstr "パッケージマネージャーは、各パッケージを個別にインストールするよりも、複数のパッケージを一度にインストールする方がはるかに効率的であることがよくあります。最終結果は同じです。すべてのパッケージがインストールされるため、統合テストで効率を検証することは困難です。模擬パッケージマネージャを提供し、それが一度に呼ばれることを検証するため、モジュール効率について貴重なテストを構築できます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:111 -msgid "Another related use is in the situation where an API has versions which behave differently. A programmer working on a new version may change the module to work with the new API version and unintentionally break the old version. A test case which checks that the call happens properly for the old version can help avoid the problem. In this situation it is very important to include version numbering in the test case name (see `Naming unit tests`_ below)." -msgstr "別の関連する使用法は、API の動作が異なるバージョンがある状況です。新しいバージョンで作業しているプログラマーは、新しい API バージョンで動作するようにモジュールを変更し、意図せずに古いバージョンを壊してしまう可能性があります。古いバージョンで呼び出しが適切に行われることを確認するテストケースは、問題を回避するのに役立ちます。この状況では、テストケース名にバージョン番号を含めることが非常に重要です (以下 `Naming unit tests`_ を参照)。" - -#: ../../rst/dev_guide/testing_units_modules.rst:119 -msgid "Providing specific design tests" -msgstr "特定の設計テストの提供" - -#: ../../rst/dev_guide/testing_units_modules.rst:121 -msgid "By building a requirement for a particular part of the code and then coding to that requirement, unit tests _can_ sometimes improve the code and help future developers understand that code." -msgstr "コードの特定の部分に対する要件を構築し、その要件に合わせてコーディングすることで、ユニットテストは、時にはコードを改善し、将来の開発者がそのコードを理解する助けとなります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:125 -msgid "Unit tests that test internal implementation details of code, on the other hand, almost always do more harm than good. Testing that your packages to install are stored in a list would slow down and confuse a future developer who might need to change that list into a dictionary for efficiency. This problem can be reduced somewhat with clear test naming so that the future developer immediately knows to delete the test case, but it is often better to simply leave out the test case altogether and test for a real valuable feature of the code, such as installing all of the packages supplied as arguments to the module." -msgstr "一方、コードの内部実装の詳細をテストするユニットテストは、ほとんどの場合、益よりも害をもたらします。インストールするパッケージがリストに格納されているかどうかをテストすると、遅くなり、効率化のためにリストをディクショナリーに変更しないといけない将来の開発者を混乱させます。この問題は、将来の開発者がすぐにテストケースを削除することがわかるように、明確なテスト名をつけることで多少軽減できますが、単にテストケースを完全に除外して、モジュールの引数として与えられたすべてのパッケージをインストールするなど、コードの本当の価値ある機能をテストする方が良い場合が多いです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:135 -msgid "How to unit test Ansible modules" -msgstr "Ansible モジュールをユニットテストする方法" - -#: ../../rst/dev_guide/testing_units_modules.rst:137 -msgid "There are a number of techniques for unit testing modules. Beware that most modules without unit tests are structured in a way that makes testing quite difficult and can lead to very complicated tests which need more work than the code. Effectively using unit tests may lead you to restructure your code. This is often a good thing and leads to better code overall. Good restructuring can make your code clearer and easier to understand." -msgstr "ユニットテストモジュールにはいくつかの手法があります。ユニットテストののないほとんどのモジュールでは、テストが非常に困難になり、コードがより複雑なテストが必要になります。ユニットテストを効果的に使用するには、コードを再構築する可能性があります。これは多くの場合良いことであり、全体的に優れたコードにつながります。適切な再構築により、コードがより明確で理解しやすくなります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:145 -msgid "Naming unit tests" -msgstr "ユニットテストの命名" - -#: ../../rst/dev_guide/testing_units_modules.rst:147 -msgid "Unit tests should have logical names. If a developer working on the module being tested breaks the test case, it should be easy to figure what the unit test covers from the name. If a unit test is designed to verify compatibility with a specific software or API version then include the version in the name of the unit test." -msgstr "ユニットテストは論理名を付ける必要があります。テスト対象のモジュールで作業している開発者がテストケースを壊してしまった場合に、ユニットテストが何を対象としているのかが名前から簡単に分かるようにする必要があります。ユニットテストが特定のソフトウェアや API のバージョンとの互換性を検証するように設計されている場合は、ユニットテストの名前にそのバージョンを追加してください。" - -#: ../../rst/dev_guide/testing_units_modules.rst:152 -msgid "As an example, ``test_v2_state_present_should_call_create_server_with_name()`` would be a good name, ``test_create_server()`` would not be." -msgstr "たとえば、``test_v2_state_present_should_call_create_server_with_name()`` が適切な名前で、``test_create_server()`` は適切ではありません。" - -#: ../../rst/dev_guide/testing_units_modules.rst:157 -msgid "Use of Mocks" -msgstr "モックの使用" - -#: ../../rst/dev_guide/testing_units_modules.rst:159 -msgid "Mock objects (from https://docs.python.org/3/library/unittest.mock.html) can be very useful in building unit tests for special / difficult cases, but they can also lead to complex and confusing coding situations. One good use for mocks would be in simulating an API. As for 'six', the 'mock' python package is bundled with Ansible (use ``import units.compat.mock``)." -msgstr "(https://docs.python.org/3/library/unittest.mock.html_ からの) モックオブジェクトは、特殊なケースや難しいケースのユニットテストを構築するのに非常に便利ですが、複雑で理解しづらいコーディングになってしまうこともあります。モックの使用方法として適切なものの 1 つに、API のシミュレートがあります。Python パッケージの six、mock は、Ansible にバンドルされています (``import units.compat.mock`` を使用)。" - -#: ../../rst/dev_guide/testing_units_modules.rst:166 -msgid "Ensuring failure cases are visible with mock objects" -msgstr "モックオブジェクトで障害ケースを確実に可視化" - -#: ../../rst/dev_guide/testing_units_modules.rst:168 -msgid "Functions like :meth:`module.fail_json` are normally expected to terminate execution. When you run with a mock module object this doesn't happen since the mock always returns another mock from a function call. You can set up the mock to raise an exception as shown above, or you can assert that these functions have not been called in each test. For example::" -msgstr ":meth:`module.fail_json` などの関数は、通常、実行を終了することが期待されます。モックモジュールオブジェクトを使用して実行すると、モックは常に関数呼び出しから別のモックを返すため、このようなことは起こりません。上記のように例外を発生させるようにモックを設定することもできますし、各テストでこれらの関数が呼び出されていないことをアサートすることもできます。以下に例を示します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:177 -msgid "This applies not only to calling the main module but almost any other function in a module which gets the module object." -msgstr "これは、メインモジュールを呼び出す場合だけでなく、モジュールオブジェクトを取得するモジュール内の他のほとんどの関数を呼び出す場合にも適用されます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:182 -msgid "Mocking of the actual module" -msgstr "実際のモジュールのモック化" - -#: ../../rst/dev_guide/testing_units_modules.rst:184 -msgid "The setup of an actual module is quite complex (see `Passing Arguments`_ below) and often isn't needed for most functions which use a module. Instead you can use a mock object as the module and create any module attributes needed by the function you are testing. If you do this, beware that the module exit functions need special handling as mentioned above, either by throwing an exception or ensuring that they haven't been called. For example::" -msgstr "実際のモジュールの設定は非常に複雑で (以下の `Passing Arguments`_ を参照)、モジュールを使用するほとんどの機能には必要ありません。モックオブジェクトをモジュールとして使用する代わりに、テストする関数で必要なモジュール属性を作成できます。この場合、モジュールの終了関数は、上述のように、例外を発生させるか、呼び出されていないことを確認するなど、特別な処理が必要になることに注意してください。以下に例を示します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:203 -msgid "API definition with unit test cases" -msgstr "ユニットテストケースでの API 定義" - -#: ../../rst/dev_guide/testing_units_modules.rst:205 -msgid "API interaction is usually best tested with the function tests defined in Ansible's integration testing section, which run against the actual API. There are several cases where the unit tests are likely to work better." -msgstr "API の対話は通常、実際の API に対して実行される Ansible の統合テストで定義された関数テストで最適です。ユニットテストが適切に機能する可能性があります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:210 -msgid "Defining a module against an API specification" -msgstr "API の仕様に対してモジュールを定義" - -#: ../../rst/dev_guide/testing_units_modules.rst:212 -msgid "This case is especially important for modules interacting with web services, which provide an API that Ansible uses but which are beyond the control of the user." -msgstr "このケースは、Ansible が使用する API を提供しているが、ユーザーの制御が及ばない Web サービスと対話するモジュールにとって特に重要です。" - -#: ../../rst/dev_guide/testing_units_modules.rst:215 -msgid "By writing a custom emulation of the calls that return data from the API, we can ensure that only the features which are clearly defined in the specification of the API are present in the message. This means that we can check that we use the correct parameters and nothing else." -msgstr "API からデータを返す呼び出しのカスタムエミュレーションを書くことで、API の仕様で明確に定義されている機能のみがメッセージに含まれていることを確認できます。つまり、正しいパラメーターを使用しているかどうかを確認し、それ以外は何も使用していないことを確認することができます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:221 -msgid "*Example: in rds_instance unit tests a simple instance state is defined*::" -msgstr "*例: rds_instance ユニットテストでは、単純なインスタンスの状態が定義されています*::" - -#: ../../rst/dev_guide/testing_units_modules.rst:229 -msgid "This is then used to create a list of states::" -msgstr "次に、これを使用して状態のリストを作成します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:244 -msgid "These states are then used as returns from a mock object to ensure that the ``await`` function waits through all of the states that would mean the RDS instance has not yet completed configuration::" -msgstr "これらの状態は、モックオブジェクトからの戻り値として使用され、``await`` 関数は、RDS インスタンスがまだ設定を完了しないことを意味するすべての状態を待機します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:252 -msgid "By doing this we check that the ``await`` function will keep waiting through potentially unusual that it would be impossible to reliably trigger through the integration tests but which happen unpredictably in reality." -msgstr "これを実行することで、統合テストでは確実に誘発させることができないにもかかわらず、現実には予測できないような、潜在的に異常なことが起こる可能性がある場合に ``await`` 関数が待機し続けるかどうかをチェックしています。" - -#: ../../rst/dev_guide/testing_units_modules.rst:257 -msgid "Defining a module to work against multiple API versions" -msgstr "複数の API バージョンに対して動作するモジュールの定義" - -#: ../../rst/dev_guide/testing_units_modules.rst:259 -msgid "This case is especially important for modules interacting with many different versions of software; for example, package installation modules that might be expected to work with many different operating system versions." -msgstr "このケースは、多くの異なるバージョンのソフトウェアと対話するモジュールにとって特に重要です。たとえば、さまざまなオペレーティングシステムのバージョンと動作することが想定されるパッケージインストールモジュールなどです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:263 -msgid "By using previously stored data from various versions of an API we can ensure that the code is tested against the actual data which will be sent from that version of the system even when the version is very obscure and unlikely to be available during testing." -msgstr "様々なバージョンの API から、以前に保存されたデータを使用することで、バージョンが非常に曖昧でテスト中に利用できそうにない場合でも、そのバージョンのシステムから送信される実際のデータに対してコードがテストできるようになります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:268 -msgid "Ansible special cases for unit testing" -msgstr "Ansible ユニットテストの特殊なケース" - -#: ../../rst/dev_guide/testing_units_modules.rst:270 -msgid "There are a number of special cases for unit testing the environment of an Ansible module. The most common are documented below, and suggestions for others can be found by looking at the source code of the existing unit tests or asking on the Ansible IRC channel or mailing lists." -msgstr "Ansible モジュールの環境に対してユニットテストを行うための特別なケースがいくつかあります。最も一般的なものを以下に示します。他の人への提案は、既存のユニットテストのソースコードを確認するか、Ansible IRC チャンネルまたはメーリングリストで質問することで見つけることができます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:276 -msgid "Module argument processing" -msgstr "モジュール引数処理" - -#: ../../rst/dev_guide/testing_units_modules.rst:278 -msgid "There are two problems with running the main function of a module:" -msgstr "モジュールの主な関数の実行には、以下の 2 つの問題があります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:280 -msgid "Since the module is supposed to accept arguments on ``STDIN`` it is a bit difficult to set up the arguments correctly so that the module will get them as parameters." -msgstr "モジュールは ``STDIN`` で引数を受け入れる必要があるため、引数を正しく設定してモジュールがパラメーターとして受け取るようにするのは少し難しくなります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:282 -msgid "All modules should finish by calling either the :meth:`module.fail_json` or :meth:`module.exit_json`, but these won't work correctly in a testing environment." -msgstr "すべてのモジュールは、:meth:`module.fail_json` または :meth:`module.exit_json` を呼び出して終了する必要がありますが、テスト環境で正常に動作しません。" - -#: ../../rst/dev_guide/testing_units_modules.rst:286 -msgid "Passing Arguments" -msgstr "引数の渡し方" - -#: ../../rst/dev_guide/testing_units_modules.rst:291 -msgid "To pass arguments to a module correctly, use the ``set_module_args`` method which accepts a dictionary as its parameter. Module creation and argument processing is handled through the :class:`AnsibleModule` object in the basic section of the utilities. Normally this accepts input on ``STDIN``, which is not convenient for unit testing. When the special variable is set it will be treated as if the input came on ``STDIN`` to the module. Simply call that function before setting up your module::" -msgstr "モジュールに正しく引数を渡すには、ディクショナリーをパラメーターとして受け付ける ``set_module_args`` メソッドを使用します。モジュールの作成と引数の処理は、ユーティリティーの基本セクションにある :class:`AnsibleModule` オブジェクトによって処理されます。通常は ``STDIN`` で入力を受け付けますが、これはユニットテストには不便です。特殊変数が設定されると、あたかも入力が ``STDIN`` でモジュールに来たかのように扱われます。モジュールをセットアップする前にこの関数を呼び出すだけです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:309 -msgid "Handling exit correctly" -msgstr "終了を適切に処理" - -#: ../../rst/dev_guide/testing_units_modules.rst:314 -msgid "The :meth:`module.exit_json` function won't work properly in a testing environment since it writes error information to ``STDOUT`` upon exit, where it is difficult to examine. This can be mitigated by replacing it (and :meth:`module.fail_json`) with a function that raises an exception::" -msgstr ":meth:`module.exit_json` 関数は、終了時にエラー情報を ``STDOUT`` に書き込むため、テスト環境で適切に動作しません。これは検証が困難です。これは、この関数 (および :meth:`module.fail_json`) を、例外を発生させる関数に置き換えることで軽減できます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:324 -msgid "Now you can ensure that the first function called is the one you expected simply by testing for the correct exception::" -msgstr "これで、最初に呼び出された関数が正しい例外であるかどうかをテストするだけで、期待したものであることを確認することができるようになりました。" - -#: ../../rst/dev_guide/testing_units_modules.rst:337 -msgid "The same technique can be used to replace :meth:`module.fail_json` (which is used for failure returns from modules) and for the ``aws_module.fail_json_aws()`` (used in modules for Amazon Web Services)." -msgstr "同じテクニックを使用して、:meth:`module.fail_json` (モジュールから返る障害に使用) および ``aws_module.fail_json_aws()`` (Amazon Web Services のモジュールに使用) に置き換えることができます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:342 -msgid "Running the main function" -msgstr "主な関数の実行" - -#: ../../rst/dev_guide/testing_units_modules.rst:344 -msgid "If you do want to run the actual main function of a module you must import the module, set the arguments as above, set up the appropriate exit exception and then run the module::" -msgstr "モジュールにおける主な実関数を実行する場合は、モジュールをインポートし、上記のように引数を設定し、適切な終了例外を設定してからモジュールを実行する必要があります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:362 -msgid "Handling calls to external executables" -msgstr "外部実行ファイルへの呼び出しの処理" - -#: ../../rst/dev_guide/testing_units_modules.rst:364 -msgid "Module must use :meth:`AnsibleModule.run_command` in order to execute an external command. This method needs to be mocked:" -msgstr "モジュールは、外部コマンドを実行するのに :meth:`AnsibleModule.run_command` を使用する必要があります。このメソッドモックする必要があります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:367 -msgid "Here is a simple mock of :meth:`AnsibleModule.run_command` (taken from :file:`test/units/modules/packaging/os/test_rhn_register.py`)::" -msgstr "以下は、:meth:`AnsibleModule.run_command` (:file:`test/units/modules/packaging/os/test_rhn_register.py` から取得) の簡単なモックです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:381 -msgid "A Complete Example" -msgstr "完全な例" - -#: ../../rst/dev_guide/testing_units_modules.rst:383 -msgid "The following example is a complete skeleton that reuses the mocks explained above and adds a new mock for :meth:`Ansible.get_bin_path`::" -msgstr "次の例は、上記で説明したモックを再利用し、:meth:`Ansible.get_bin_path` の新しいモックを追加する完全なスケルトンです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:469 -msgid "Restructuring modules to enable testing module set up and other processes" -msgstr "テストモジュールの設定などを可能にするためのモジュールの再構築" - -#: ../../rst/dev_guide/testing_units_modules.rst:471 -msgid "Often modules have a ``main()`` function which sets up the module and then performs other actions. This can make it difficult to check argument processing. This can be made easier by moving module configuration and initialization into a separate function. For example::" -msgstr "多くの場合、モジュールをセットアップし、他のアクションを実行する ``main()`` 関数があります。これにより、引数処理を確認するのが困難になる可能性があります。モジュールの設定と初期化を別の関数に移すことで簡単にできます。以下に例を示します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:501 -msgid "This now makes it possible to run tests against the module initiation function::" -msgstr "これにより、モジュールの開始関数に対してテストを実行できるようになりました。" - -#: ../../rst/dev_guide/testing_units_modules.rst:513 -msgid "See also ``test/units/module_utils/aws/test_rds.py``" -msgstr "「``test/units/module_utils/aws/test_rds.py``」も参照してください。" - -#: ../../rst/dev_guide/testing_units_modules.rst:515 -msgid "Note that the ``argument_spec`` dictionary is visible in a module variable. This has advantages, both in allowing explicit testing of the arguments and in allowing the easy creation of module objects for testing." -msgstr "``argument_spec`` ディクショナリーはモジュール変数に表示されます。これには、引数の明示的なテストを許可し、テスト用にモジュールオブジェクトの作成を簡単に行えるようにする利点があります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:519 -msgid "The same restructuring technique can be valuable for testing other functionality, such as the part of the module which queries the object that the module configures." -msgstr "この再構築の手法は、モジュールが設定したオブジェクトを問い合わせるモジュールの部分など、その他の機能をテストする場合にも役に立ちます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:522 -msgid "Traps for maintaining Python 2 compatibility" -msgstr "Python 2 の互換性を維持するためのトラップ" - -#: ../../rst/dev_guide/testing_units_modules.rst:524 -msgid "If you use the ``mock`` library from the Python 2.6 standard library, a number of the assert functions are missing but will return as if successful. This means that test cases should take great care *not* use functions marked as _new_ in the Python 3 documentation, since the tests will likely always succeed even if the code is broken when run on older versions of Python." -msgstr "Python 2.6 標準ライブラリーの ``mock`` ライブラリーを使用している場合は、多くの assert 関数が欠落していますが、成功したかのように返されます。これは、テストケースが、Python 3 のドキュメントで _new_ となっている関数を使用しないよう、細心の注意を払うべきであることを意味します。なぜなら、古いバージョンの Python で実行されたコードが壊れていても、テストは常に成功するからです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:529 -msgid "A helpful development approach to this should be to ensure that all of the tests have been run under Python 2.6 and that each assertion in the test cases has been checked to work by breaking the code in Ansible to trigger that failure." -msgstr "これに役立つ開発アプローチは、すべてのテストが Python 2.6 で実行されていることと、テストケース内の各アサーションが Ansible でコードを壊してその失敗を誘発することで動作することが確認されているという点を確認することです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:533 -msgid "Maintain Python 2.6 compatibility" -msgstr "Python 2.6 互換性の維持" - -#: ../../rst/dev_guide/testing_units_modules.rst:535 -msgid "Please remember that modules need to maintain compatibility with Python 2.6 so the unittests for modules should also be compatible with Python 2.6." -msgstr "モジュールは Python 2.6 との互換性を維持する必要があるため、モジュールのユニットテストも、Python 2.6 との互換性を維持する必要があることに注意してください。" - -#: ../../rst/dev_guide/testing_units_modules.rst:542 -msgid "Ansible unit tests documentation" -msgstr "Ansible unit テストドキュメント" - -#: ../../rst/dev_guide/testing_units_modules.rst:546 -msgid "Get started developing a module" -msgstr "モジュール開発を始める" - -#: ../../rst/dev_guide/testing_units_modules.rst:555 -msgid "`Testing Your Code (from The Hitchhiker's Guide to Python!) `_" -msgstr "`Testing Your Code (from The Hitchhiker's Guide to Python!) `_" - -#: ../../rst/dev_guide/testing_units_modules.rst:556 -msgid "General advice on testing Python code" -msgstr "Python コードのテストに関する一般的なアドバイス" - -#: ../../rst/dev_guide/testing_units_modules.rst:558 -msgid "`Uncle Bob's many videos on YouTube `_" -msgstr "`Uncle Bob's many videos on YouTube `_" - -#: ../../rst/dev_guide/testing_units_modules.rst:558 -msgid "Unit testing is a part of the of various philosophies of software development, including Extreme Programming (XP), Clean Coding. Uncle Bob talks through how to benefit from this" -msgstr "ユニットテストは、Extreme Programming (XP)、クリーンコーディングを含むソフトウェア開発の様々な哲学の一部です。Uncle Bob は、どのようにしてこの恩恵を受けることができるのかを説明します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:560 -msgid "`\"Why Most Unit Testing is Waste\" `_" -msgstr "`\"Why Most Unit Testing is Waste\" `_" - -#: ../../rst/dev_guide/testing_units_modules.rst:561 -msgid "An article warning against the costs of unit testing" -msgstr "ユニットテストの大半が無駄である理由" - -#: ../../rst/dev_guide/testing_units_modules.rst:562 -msgid "`'A Response to \"Why Most Unit Testing is Waste\"' `_" -msgstr "`'A Response to \"Why Most Unit Testing is Waste\"' `_" - -#: ../../rst/dev_guide/testing_units_modules.rst:563 -msgid "An response pointing to how to maintain the value of unit tests" -msgstr "ユニットテストの価値を維持する方法を指摘した回答" - -#: ../../rst/dev_guide/testing_validate-modules.rst:11 -msgid "Python program to help test or validate Ansible modules." -msgstr "Ansible モジュールのテストまたは検証に役立つ Python プログラム。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:13 -msgid "``validate-modules`` is one of the ``ansible-test`` Sanity Tests, see :ref:`testing_sanity` for more information." -msgstr "``validate-modules`` は、健全性テスト ``ansible-test`` のいずれかです。詳細は、「:ref:`testing_sanity`」を参照してください。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:15 -msgid "Originally developed by Matt Martz (@sivel)" -msgstr "本プログラムは、元々 Michay Martz(@sivel) 氏により開発されました。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:19 -msgid "Usage" -msgstr "使用法" - -#: ../../rst/dev_guide/testing_validate-modules.rst:28 -msgid "Help" -msgstr "ヘルプ" - -#: ../../rst/dev_guide/testing_validate-modules.rst:53 -msgid "Extending validate-modules" -msgstr "validate-modules の拡張" - -#: ../../rst/dev_guide/testing_validate-modules.rst:55 -msgid "The ``validate-modules`` tool has a `schema.py `_ that is used to validate the YAML blocks, such as ``DOCUMENTATION`` and ``RETURNS``." -msgstr "``validate-modules`` ツールには、``DOCUMENTATION``、``RETURNS`` などの YAML ブロックの検証に使用される `schema.py `_ があります。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:59 -msgid "Codes" -msgstr "コード" - -#: ../../rst/dev_guide/testing_validate-modules.rst:62 -msgid "**Error Code**" -msgstr "**エラーコード**" - -#: ../../rst/dev_guide/testing_validate-modules.rst:62 -msgid "**Type**" -msgstr "**タイプ**" - -#: ../../rst/dev_guide/testing_validate-modules.rst:62 -msgid "**Level**" -msgstr "**レベル**" - -#: ../../rst/dev_guide/testing_validate-modules.rst:62 -msgid "**Sample Message**" -msgstr "**開始メッセージ**" - -#: ../../rst/dev_guide/testing_validate-modules.rst:64 -msgid "ansible-deprecated-version" -msgstr "ansible-deprecated-version" - -#: ../../rst/dev_guide/testing_validate-modules.rst:64 -#: ../../rst/dev_guide/testing_validate-modules.rst:66 -#: ../../rst/dev_guide/testing_validate-modules.rst:67 -#: ../../rst/dev_guide/testing_validate-modules.rst:68 -#: ../../rst/dev_guide/testing_validate-modules.rst:69 -#: ../../rst/dev_guide/testing_validate-modules.rst:70 -#: ../../rst/dev_guide/testing_validate-modules.rst:71 -#: ../../rst/dev_guide/testing_validate-modules.rst:72 -#: ../../rst/dev_guide/testing_validate-modules.rst:73 -#: ../../rst/dev_guide/testing_validate-modules.rst:74 -#: ../../rst/dev_guide/testing_validate-modules.rst:75 -#: ../../rst/dev_guide/testing_validate-modules.rst:76 -#: ../../rst/dev_guide/testing_validate-modules.rst:77 -#: ../../rst/dev_guide/testing_validate-modules.rst:78 -#: ../../rst/dev_guide/testing_validate-modules.rst:79 -#: ../../rst/dev_guide/testing_validate-modules.rst:82 -#: ../../rst/dev_guide/testing_validate-modules.rst:85 -#: ../../rst/dev_guide/testing_validate-modules.rst:86 -#: ../../rst/dev_guide/testing_validate-modules.rst:87 -#: ../../rst/dev_guide/testing_validate-modules.rst:88 -#: ../../rst/dev_guide/testing_validate-modules.rst:89 -#: ../../rst/dev_guide/testing_validate-modules.rst:90 -#: ../../rst/dev_guide/testing_validate-modules.rst:91 -#: ../../rst/dev_guide/testing_validate-modules.rst:92 -#: ../../rst/dev_guide/testing_validate-modules.rst:94 -#: ../../rst/dev_guide/testing_validate-modules.rst:95 -#: ../../rst/dev_guide/testing_validate-modules.rst:98 -#: ../../rst/dev_guide/testing_validate-modules.rst:99 -#: ../../rst/dev_guide/testing_validate-modules.rst:100 -#: ../../rst/dev_guide/testing_validate-modules.rst:101 -#: ../../rst/dev_guide/testing_validate-modules.rst:102 -#: ../../rst/dev_guide/testing_validate-modules.rst:110 -#: ../../rst/dev_guide/testing_validate-modules.rst:111 -#: ../../rst/dev_guide/testing_validate-modules.rst:112 -#: ../../rst/dev_guide/testing_validate-modules.rst:113 -#: ../../rst/dev_guide/testing_validate-modules.rst:114 -#: ../../rst/dev_guide/testing_validate-modules.rst:118 -#: ../../rst/dev_guide/testing_validate-modules.rst:119 -#: ../../rst/dev_guide/testing_validate-modules.rst:120 -#: ../../rst/dev_guide/testing_validate-modules.rst:121 -#: ../../rst/dev_guide/testing_validate-modules.rst:122 -#: ../../rst/dev_guide/testing_validate-modules.rst:123 -#: ../../rst/dev_guide/testing_validate-modules.rst:124 -#: ../../rst/dev_guide/testing_validate-modules.rst:125 -#: ../../rst/dev_guide/testing_validate-modules.rst:128 -#: ../../rst/dev_guide/testing_validate-modules.rst:132 -#: ../../rst/dev_guide/testing_validate-modules.rst:133 -#: ../../rst/dev_guide/testing_validate-modules.rst:134 -#: ../../rst/dev_guide/testing_validate-modules.rst:137 -#: ../../rst/dev_guide/testing_validate-modules.rst:139 -#: ../../rst/dev_guide/testing_validate-modules.rst:145 -#: ../../rst/dev_guide/testing_validate-modules.rst:146 -#: ../../rst/dev_guide/testing_validate-modules.rst:147 -#: ../../rst/dev_guide/testing_validate-modules.rst:148 -#: ../../rst/dev_guide/testing_validate-modules.rst:149 -#: ../../rst/dev_guide/testing_validate-modules.rst:150 -#: ../../rst/dev_guide/testing_validate-modules.rst:151 -#: ../../rst/dev_guide/testing_validate-modules.rst:152 -#: ../../rst/dev_guide/testing_validate-modules.rst:153 -#: ../../rst/dev_guide/testing_validate-modules.rst:154 -#: ../../rst/dev_guide/testing_validate-modules.rst:155 -#: ../../rst/dev_guide/testing_validate-modules.rst:156 -#: ../../rst/dev_guide/testing_validate-modules.rst:157 -#: ../../rst/dev_guide/testing_validate-modules.rst:158 -#: ../../rst/dev_guide/testing_validate-modules.rst:159 -#: ../../rst/dev_guide/testing_validate-modules.rst:160 -#: ../../rst/dev_guide/testing_validate-modules.rst:161 -#: ../../rst/dev_guide/testing_validate-modules.rst:162 -#: ../../rst/dev_guide/testing_validate-modules.rst:163 -#: ../../rst/dev_guide/testing_validate-modules.rst:164 -msgid "Documentation" -msgstr "ドキュメント" - -#: ../../rst/dev_guide/testing_validate-modules.rst:64 -#: ../../rst/dev_guide/testing_validate-modules.rst:65 -#: ../../rst/dev_guide/testing_validate-modules.rst:66 -#: ../../rst/dev_guide/testing_validate-modules.rst:67 -#: ../../rst/dev_guide/testing_validate-modules.rst:68 -#: ../../rst/dev_guide/testing_validate-modules.rst:69 -#: ../../rst/dev_guide/testing_validate-modules.rst:70 -#: ../../rst/dev_guide/testing_validate-modules.rst:71 -#: ../../rst/dev_guide/testing_validate-modules.rst:72 -#: ../../rst/dev_guide/testing_validate-modules.rst:73 -#: ../../rst/dev_guide/testing_validate-modules.rst:74 -#: ../../rst/dev_guide/testing_validate-modules.rst:75 -#: ../../rst/dev_guide/testing_validate-modules.rst:76 -#: ../../rst/dev_guide/testing_validate-modules.rst:77 -#: ../../rst/dev_guide/testing_validate-modules.rst:78 -#: ../../rst/dev_guide/testing_validate-modules.rst:79 -#: ../../rst/dev_guide/testing_validate-modules.rst:80 -#: ../../rst/dev_guide/testing_validate-modules.rst:81 -#: ../../rst/dev_guide/testing_validate-modules.rst:82 -#: ../../rst/dev_guide/testing_validate-modules.rst:84 -#: ../../rst/dev_guide/testing_validate-modules.rst:85 -#: ../../rst/dev_guide/testing_validate-modules.rst:86 -#: ../../rst/dev_guide/testing_validate-modules.rst:87 -#: ../../rst/dev_guide/testing_validate-modules.rst:88 -#: ../../rst/dev_guide/testing_validate-modules.rst:89 -#: ../../rst/dev_guide/testing_validate-modules.rst:90 -#: ../../rst/dev_guide/testing_validate-modules.rst:91 -#: ../../rst/dev_guide/testing_validate-modules.rst:92 -#: ../../rst/dev_guide/testing_validate-modules.rst:93 -#: ../../rst/dev_guide/testing_validate-modules.rst:94 -#: ../../rst/dev_guide/testing_validate-modules.rst:95 -#: ../../rst/dev_guide/testing_validate-modules.rst:96 -#: ../../rst/dev_guide/testing_validate-modules.rst:97 -#: ../../rst/dev_guide/testing_validate-modules.rst:98 -#: ../../rst/dev_guide/testing_validate-modules.rst:100 -#: ../../rst/dev_guide/testing_validate-modules.rst:101 -#: ../../rst/dev_guide/testing_validate-modules.rst:102 -#: ../../rst/dev_guide/testing_validate-modules.rst:103 -#: ../../rst/dev_guide/testing_validate-modules.rst:104 -#: ../../rst/dev_guide/testing_validate-modules.rst:106 -#: ../../rst/dev_guide/testing_validate-modules.rst:107 -#: ../../rst/dev_guide/testing_validate-modules.rst:108 -#: ../../rst/dev_guide/testing_validate-modules.rst:109 -#: ../../rst/dev_guide/testing_validate-modules.rst:110 -#: ../../rst/dev_guide/testing_validate-modules.rst:112 -#: ../../rst/dev_guide/testing_validate-modules.rst:113 -#: ../../rst/dev_guide/testing_validate-modules.rst:114 -#: ../../rst/dev_guide/testing_validate-modules.rst:115 -#: ../../rst/dev_guide/testing_validate-modules.rst:116 -#: ../../rst/dev_guide/testing_validate-modules.rst:117 -#: ../../rst/dev_guide/testing_validate-modules.rst:118 -#: ../../rst/dev_guide/testing_validate-modules.rst:119 -#: ../../rst/dev_guide/testing_validate-modules.rst:120 -#: ../../rst/dev_guide/testing_validate-modules.rst:121 -#: ../../rst/dev_guide/testing_validate-modules.rst:122 -#: ../../rst/dev_guide/testing_validate-modules.rst:123 -#: ../../rst/dev_guide/testing_validate-modules.rst:124 -#: ../../rst/dev_guide/testing_validate-modules.rst:125 -#: ../../rst/dev_guide/testing_validate-modules.rst:126 -#: ../../rst/dev_guide/testing_validate-modules.rst:127 -#: ../../rst/dev_guide/testing_validate-modules.rst:128 -#: ../../rst/dev_guide/testing_validate-modules.rst:129 -#: ../../rst/dev_guide/testing_validate-modules.rst:130 -#: ../../rst/dev_guide/testing_validate-modules.rst:131 -#: ../../rst/dev_guide/testing_validate-modules.rst:132 -#: ../../rst/dev_guide/testing_validate-modules.rst:133 -#: ../../rst/dev_guide/testing_validate-modules.rst:134 -#: ../../rst/dev_guide/testing_validate-modules.rst:135 -#: ../../rst/dev_guide/testing_validate-modules.rst:137 -#: ../../rst/dev_guide/testing_validate-modules.rst:138 -#: ../../rst/dev_guide/testing_validate-modules.rst:140 -#: ../../rst/dev_guide/testing_validate-modules.rst:141 -#: ../../rst/dev_guide/testing_validate-modules.rst:142 -#: ../../rst/dev_guide/testing_validate-modules.rst:143 -#: ../../rst/dev_guide/testing_validate-modules.rst:144 -#: ../../rst/dev_guide/testing_validate-modules.rst:145 -#: ../../rst/dev_guide/testing_validate-modules.rst:146 -#: ../../rst/dev_guide/testing_validate-modules.rst:147 -#: ../../rst/dev_guide/testing_validate-modules.rst:148 -#: ../../rst/dev_guide/testing_validate-modules.rst:149 -#: ../../rst/dev_guide/testing_validate-modules.rst:150 -#: ../../rst/dev_guide/testing_validate-modules.rst:151 -#: ../../rst/dev_guide/testing_validate-modules.rst:152 -#: ../../rst/dev_guide/testing_validate-modules.rst:153 -#: ../../rst/dev_guide/testing_validate-modules.rst:154 -#: ../../rst/dev_guide/testing_validate-modules.rst:155 -#: ../../rst/dev_guide/testing_validate-modules.rst:156 -#: ../../rst/dev_guide/testing_validate-modules.rst:157 -#: ../../rst/dev_guide/testing_validate-modules.rst:158 -#: ../../rst/dev_guide/testing_validate-modules.rst:159 -#: ../../rst/dev_guide/testing_validate-modules.rst:160 -#: ../../rst/dev_guide/testing_validate-modules.rst:161 -#: ../../rst/dev_guide/testing_validate-modules.rst:162 -#: ../../rst/dev_guide/testing_validate-modules.rst:163 -#: ../../rst/dev_guide/testing_validate-modules.rst:164 -msgid "Error" -msgstr "エラー" - -#: ../../rst/dev_guide/testing_validate-modules.rst:64 -msgid "A feature is deprecated and supposed to be removed in the current or an earlier Ansible version" -msgstr "機能は非推奨となり、現行またはそれ以前の Ansible バージョンで削除される予定です。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:65 -msgid "ansible-module-not-initialized" -msgstr "ansible-module-not-initialized" - -#: ../../rst/dev_guide/testing_validate-modules.rst:65 -#: ../../rst/dev_guide/testing_validate-modules.rst:97 -#: ../../rst/dev_guide/testing_validate-modules.rst:103 -#: ../../rst/dev_guide/testing_validate-modules.rst:104 -#: ../../rst/dev_guide/testing_validate-modules.rst:107 -#: ../../rst/dev_guide/testing_validate-modules.rst:109 -#: ../../rst/dev_guide/testing_validate-modules.rst:131 -#: ../../rst/dev_guide/testing_validate-modules.rst:138 -msgid "Syntax" -msgstr "構文" - -#: ../../rst/dev_guide/testing_validate-modules.rst:65 -msgid "Execution of the module did not result in initialization of AnsibleModule" -msgstr "モジュールを実行しても、AnsibleModule は初期化されなかった。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:66 -msgid "collection-deprecated-version" -msgstr "collection-deprecated-version" - -#: ../../rst/dev_guide/testing_validate-modules.rst:66 -msgid "A feature is deprecated and supposed to be removed in the current or an earlier collection version" -msgstr "機能は非推奨となり、現行またはそれ以前のバージョンのコレクションで削除される予定です。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:67 -msgid "deprecated-date" -msgstr "deprecated-date" - -#: ../../rst/dev_guide/testing_validate-modules.rst:67 -msgid "A date before today appears as ``removed_at_date`` or in ``deprecated_aliases``" -msgstr "今日より前の日付は、``removed_at_date`` ように表示されるか、``deprecated_aliases`` に表示されます。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:68 -msgid "deprecation-mismatch" -msgstr "deprecation-mismatch" - -#: ../../rst/dev_guide/testing_validate-modules.rst:68 -msgid "Module marked as deprecated or removed in at least one of the filename, its metadata, or in DOCUMENTATION (setting DOCUMENTATION.deprecated for deprecation or removing all Documentation for removed) but not in all three places." -msgstr "ファイル名、そのメタデータの少なくとも 1 つ、または DOCUMENTATION (非推奨の場合は DOCUMENTATION.deprecated を設定するか、削除の場合はすべてのドキュメントを削除する) で非推奨または削除済みとしてマークされたモジュールですが、3 カ所すべてではありません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:69 -msgid "doc-choices-do-not-match-spec" -msgstr "doc-choices-do-not-match-spec" - -#: ../../rst/dev_guide/testing_validate-modules.rst:69 -msgid "Value for \"choices\" from the argument_spec does not match the documentation" -msgstr "argument_spec の「choices」の値がドキュメントと一致しない。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:70 -msgid "doc-choices-incompatible-type" -msgstr "doc-choices-incompatible-type" - -#: ../../rst/dev_guide/testing_validate-modules.rst:70 -msgid "Choices value from the documentation is not compatible with type defined in the argument_spec" -msgstr "ドキュメンテーションの選択値は、argument_spec で定義されたタイプと互換性がありません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:71 -msgid "doc-default-does-not-match-spec" -msgstr "doc-default-does-not-match-spec" - -#: ../../rst/dev_guide/testing_validate-modules.rst:71 -msgid "Value for \"default\" from the argument_spec does not match the documentation" -msgstr "argument_spec の「default」の値がドキュメントと一致しない。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:72 -msgid "doc-default-incompatible-type" -msgstr "doc-default-incompatible-type" - -#: ../../rst/dev_guide/testing_validate-modules.rst:72 -msgid "Default value from the documentation is not compatible with type defined in the argument_spec" -msgstr "ドキュメンテーションのデフォルト値は、argument_spec で定義されたタイプと互換性がありません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:73 -msgid "doc-elements-invalid" -msgstr "doc-elements-invalid" - -#: ../../rst/dev_guide/testing_validate-modules.rst:73 -msgid "Documentation specifies elements for argument, when \"type\" is not ``list``." -msgstr "ドキュメントでは、「type」が ``list`` ではない場合に、引数の要素を指定します。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:74 -msgid "doc-elements-mismatch" -msgstr "doc-elements-mismatch" - -#: ../../rst/dev_guide/testing_validate-modules.rst:74 -msgid "Argument_spec defines elements different than documentation does" -msgstr "Argument_spec はドキュメントとは異なるタイプを定義する。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:75 -msgid "doc-missing-type" -msgstr "doc-missing-type" - -#: ../../rst/dev_guide/testing_validate-modules.rst:75 -msgid "Documentation doesn't specify a type but argument in ``argument_spec`` use default type (``str``)" -msgstr "ドキュメントでは種類を示していないが、``argument_spec`` の引数がデフォルト型 (``str``) を使用している。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:76 -msgid "doc-required-mismatch" -msgstr "doc-required-mismatch" - -#: ../../rst/dev_guide/testing_validate-modules.rst:76 -msgid "argument in argument_spec is required but documentation says it is not, or vice versa" -msgstr "arguments_spec の引数は必須ですが、ドキュメントには必須ではない (または arguments_spec の引数は必須ではないが、ドキュメントには必須) と記載されています。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:77 -msgid "doc-type-does-not-match-spec" -msgstr "doc-type-does-not-match-spec" - -#: ../../rst/dev_guide/testing_validate-modules.rst:77 -msgid "Argument_spec defines type different than documentation does" -msgstr "Argument_spec はドキュメントとは異なるタイプを定義" - -#: ../../rst/dev_guide/testing_validate-modules.rst:78 -msgid "documentation-error" -msgstr "documentation-error" - -#: ../../rst/dev_guide/testing_validate-modules.rst:78 -msgid "Unknown ``DOCUMENTATION`` error" -msgstr "不明な ``DOCUMENTATION`` エラー" - -#: ../../rst/dev_guide/testing_validate-modules.rst:79 -msgid "documentation-syntax-error" -msgstr "documentation-syntax-error" - -#: ../../rst/dev_guide/testing_validate-modules.rst:79 -msgid "Invalid ``DOCUMENTATION`` schema" -msgstr "無効な ``DOCUMENTATION`` スキーマ" - -#: ../../rst/dev_guide/testing_validate-modules.rst:80 -msgid "illegal-future-imports" -msgstr "illegal-future-imports" - -#: ../../rst/dev_guide/testing_validate-modules.rst:80 -#: ../../rst/dev_guide/testing_validate-modules.rst:81 -#: ../../rst/dev_guide/testing_validate-modules.rst:84 -#: ../../rst/dev_guide/testing_validate-modules.rst:105 -#: ../../rst/dev_guide/testing_validate-modules.rst:106 -#: ../../rst/dev_guide/testing_validate-modules.rst:115 -#: ../../rst/dev_guide/testing_validate-modules.rst:116 -#: ../../rst/dev_guide/testing_validate-modules.rst:117 -#: ../../rst/dev_guide/testing_validate-modules.rst:136 -#: ../../rst/dev_guide/testing_validate-modules.rst:140 -#: ../../rst/dev_guide/testing_validate-modules.rst:141 -#: ../../rst/dev_guide/testing_validate-modules.rst:142 -#: ../../rst/dev_guide/testing_validate-modules.rst:143 -#: ../../rst/dev_guide/testing_validate-modules.rst:144 -msgid "Imports" -msgstr "Import" - -#: ../../rst/dev_guide/testing_validate-modules.rst:80 -msgid "Only the following ``from __future__`` imports are allowed: ``absolute_import``, ``division``, and ``print_function``." -msgstr "``absolute_import``、``division``、および ``print_function`` の ``from __future__`` インポートのみが許可されます。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:81 -msgid "import-before-documentation" -msgstr "import-before-documentation" - -#: ../../rst/dev_guide/testing_validate-modules.rst:81 -msgid "Import found before documentation variables. All imports must appear below ``DOCUMENTATION``/``EXAMPLES``/``RETURN``" -msgstr "ドキュメント変数の前にインポートが見つかりました。すべてのインポートは、``DOCUMENTATION``/``EXAMPLES``/``RETURN`` の下に表示される必要があります。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:82 -msgid "import-error" -msgstr "import-error" - -#: ../../rst/dev_guide/testing_validate-modules.rst:82 -msgid "``Exception`` attempting to import module for ``argument_spec`` introspection" -msgstr "``Exception`` が、``argument_spec`` イントロスペクションのモジュールのインポートを試行中" - -#: ../../rst/dev_guide/testing_validate-modules.rst:83 -msgid "import-placement" -msgstr "import-placement" - -#: ../../rst/dev_guide/testing_validate-modules.rst:83 -msgid "Locations" -msgstr "場所" - -#: ../../rst/dev_guide/testing_validate-modules.rst:83 -#: ../../rst/dev_guide/testing_validate-modules.rst:99 -#: ../../rst/dev_guide/testing_validate-modules.rst:105 -#: ../../rst/dev_guide/testing_validate-modules.rst:111 -#: ../../rst/dev_guide/testing_validate-modules.rst:136 -#: ../../rst/dev_guide/testing_validate-modules.rst:139 -msgid "Warning" -msgstr "警告" - -#: ../../rst/dev_guide/testing_validate-modules.rst:83 -#: ../../rst/dev_guide/testing_validate-modules.rst:84 -msgid "Imports should be directly below ``DOCUMENTATION``/``EXAMPLES``/``RETURN``" -msgstr "インポートは、``DOCUMENTATION``/``EXAMPLES``/``RETURN`` のすぐ後に配置しなければなりません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:84 -msgid "imports-improper-location" -msgstr "imports-improper-location" - -#: ../../rst/dev_guide/testing_validate-modules.rst:85 -msgid "incompatible-choices" -msgstr "incompatible-choices" - -#: ../../rst/dev_guide/testing_validate-modules.rst:85 -msgid "Choices value from the argument_spec is not compatible with type defined in the argument_spec" -msgstr "argument_spec の選択肢は、argument_spec で定義されたタイプと互換性がありません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:86 -msgid "incompatible-default-type" -msgstr "incompatible-default-type" - -#: ../../rst/dev_guide/testing_validate-modules.rst:86 -msgid "Default value from the argument_spec is not compatible with type defined in the argument_spec" -msgstr "argument_spec のデフォルト値は、argument_spec で定義されたタイプと互換性がありません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:87 -msgid "invalid-argument-name" -msgstr "invalid-argument-name" - -#: ../../rst/dev_guide/testing_validate-modules.rst:87 -msgid "Argument in argument_spec must not be one of 'message', 'syslog_facility' as it is used internally by Ansible Core Engine" -msgstr "argument_spec の引数は、Ansible Core Engine によって内部で使用されるため、「message」、「syslog_facility」のいずれかにすることはできません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:88 -msgid "invalid-argument-spec" -msgstr "invalid-argument-spec" - -#: ../../rst/dev_guide/testing_validate-modules.rst:88 -msgid "Argument in argument_spec must be a dictionary/hash when used" -msgstr "argument_spec の引数を使用する場合は、ディクショナリーまたはハッシュである必要がある。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:89 -msgid "invalid-argument-spec-options" -msgstr "invalid-argument-spec-options" - -#: ../../rst/dev_guide/testing_validate-modules.rst:89 -msgid "Suboptions in argument_spec are invalid" -msgstr "argument_spec のサブオプションは無効" - -#: ../../rst/dev_guide/testing_validate-modules.rst:90 -msgid "invalid-documentation" -msgstr "invalid-documentation" - -#: ../../rst/dev_guide/testing_validate-modules.rst:90 -msgid "``DOCUMENTATION`` is not valid YAML" -msgstr "``DOCUMENTATION`` は、有効な YAML ではありません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:91 -msgid "invalid-documentation-options" -msgstr "invalid-documentation-options" - -#: ../../rst/dev_guide/testing_validate-modules.rst:91 -msgid "``DOCUMENTATION.options`` must be a dictionary/hash when used" -msgstr "``DOCUMENTATION.options`` 使用する場合は、ディクショナリー/ハッシュでなければなりません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:92 -msgid "invalid-examples" -msgstr "invalid-examples" - -#: ../../rst/dev_guide/testing_validate-modules.rst:92 -msgid "``EXAMPLES`` is not valid YAML" -msgstr "``EXAMPLES`` は、有効な YAML ではありません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:93 -msgid "invalid-extension" -msgstr "invalid-extension" - -#: ../../rst/dev_guide/testing_validate-modules.rst:93 -msgid "Official Ansible modules must have a ``.py`` extension for python modules or a ``.ps1`` for powershell modules" -msgstr "公式の Ansible モジュールでは、python モジュールの拡張子は ``.py`` で、powershell モジュールの拡張子は ``.ps1`` である必要がある。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:94 -msgid "invalid-module-schema" -msgstr "invalid-module-schema" - -#: ../../rst/dev_guide/testing_validate-modules.rst:94 -msgid "``AnsibleModule`` schema validation error" -msgstr "``AnsibleModule`` スキーマ検証エラー" - -#: ../../rst/dev_guide/testing_validate-modules.rst:95 -msgid "invalid-removal-version" -msgstr "invalid-removal-version" - -#: ../../rst/dev_guide/testing_validate-modules.rst:95 -msgid "The version at which a feature is supposed to be removed cannot be parsed (for collections, it must be a semantic version, see https://semver.org/)" -msgstr "機能が削除されることになっているバージョンは解析できません (コレクションの場合、セマンティックバージョンである必要があります。https://semver.org/ を参照してください)。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:96 -msgid "invalid-requires-extension" -msgstr "invalid-requires-extension" - -#: ../../rst/dev_guide/testing_validate-modules.rst:96 -msgid "Module ``#AnsibleRequires -CSharpUtil`` should not end in .cs, Module ``#Requires`` should not end in .psm1" -msgstr "モジュール ``#AnsibleRequires -CSharpUtil`` の末尾を .cs にしてはならない。モジュール ``#Requires`` は .psm1 では終わらない。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:97 -msgid "last-line-main-call" -msgstr "last-line-main-call" - -#: ../../rst/dev_guide/testing_validate-modules.rst:97 -msgid "Call to ``main()`` not the last line (or ``removed_module()`` in the case of deprecated & docs only modules)" -msgstr "最終行以外の ``main()`` の呼出し (または、非推奨およびドキュメントのみのモジュールでは ``removed_module()``)。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:98 -msgid "missing-doc-fragment" -msgstr "missing-doc-fragment" - -#: ../../rst/dev_guide/testing_validate-modules.rst:98 -msgid "``DOCUMENTATION`` fragment missing" -msgstr "``DOCUMENTATION`` フラグメントがない" - -#: ../../rst/dev_guide/testing_validate-modules.rst:99 -msgid "missing-existing-doc-fragment" -msgstr "missing-existing-doc-fragment" - -#: ../../rst/dev_guide/testing_validate-modules.rst:99 -msgid "Pre-existing ``DOCUMENTATION`` fragment missing" -msgstr "既存の ``DOCUMENTATION`` フラグメントがない" - -#: ../../rst/dev_guide/testing_validate-modules.rst:100 -msgid "missing-documentation" -msgstr "missing-documentation" - -#: ../../rst/dev_guide/testing_validate-modules.rst:100 -msgid "No ``DOCUMENTATION`` provided" -msgstr "``DOCUMENTATION`` が提供されていない" - -#: ../../rst/dev_guide/testing_validate-modules.rst:101 -msgid "missing-examples" -msgstr "missing-examples" - -#: ../../rst/dev_guide/testing_validate-modules.rst:101 -msgid "No ``EXAMPLES`` provided" -msgstr "``EXAMPLES`` が提供されていない" - -#: ../../rst/dev_guide/testing_validate-modules.rst:102 -msgid "missing-gplv3-license" -msgstr "missing-gplv3-license" - -#: ../../rst/dev_guide/testing_validate-modules.rst:102 -msgid "GPLv3 license header not found" -msgstr "GPLv3 ライセンスヘッダーが見つからない" - -#: ../../rst/dev_guide/testing_validate-modules.rst:103 -msgid "missing-if-name-main" -msgstr "missing-if-name-main" - -#: ../../rst/dev_guide/testing_validate-modules.rst:103 -msgid "Next to last line is not ``if __name__ == \"__main__\":``" -msgstr "最後の行の隣になるものは、``if __name__ == \"__main__\":`` ではない" - -#: ../../rst/dev_guide/testing_validate-modules.rst:104 -msgid "missing-main-call" -msgstr "missing-main-call" - -#: ../../rst/dev_guide/testing_validate-modules.rst:104 -msgid "Did not find a call to ``main()`` (or ``removed_module()`` in the case of deprecated & docs only modules)" -msgstr "``main()`` への呼出しが見つからなかった (非推奨またはドキュメントのみのモジュールの場合は ``removed_module()``)。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:105 -msgid "missing-module-utils-basic-import" -msgstr "missing-module-utils-basic-import" - -#: ../../rst/dev_guide/testing_validate-modules.rst:105 -msgid "Did not find ``ansible.module_utils.basic`` import" -msgstr "``ansible.module_utils.basic`` インポートが見つかりませんでした" - -#: ../../rst/dev_guide/testing_validate-modules.rst:106 -msgid "missing-module-utils-import-csharp-requirements" -msgstr "missing-module-utils-import-csharp-requirements" - -#: ../../rst/dev_guide/testing_validate-modules.rst:106 -msgid "No ``Ansible.ModuleUtils`` or C# Ansible util requirements/imports found" -msgstr "``Ansible.ModuleUtils`` または C# Ansible util 要件/インポートがある" - -#: ../../rst/dev_guide/testing_validate-modules.rst:107 -msgid "missing-powershell-interpreter" -msgstr "missing-powershell-interpreter" - -#: ../../rst/dev_guide/testing_validate-modules.rst:107 -msgid "Interpreter line is not ``#!powershell``" -msgstr "インタープリター行、``#!powershell`` ではありません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:108 -msgid "missing-python-doc" -msgstr "missing-python-doc" - -#: ../../rst/dev_guide/testing_validate-modules.rst:108 -msgid "Missing python documentation file" -msgstr "python ドキュメントファイルがありません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:109 -msgid "missing-python-interpreter" -msgstr "missing-python-interpreter" - -#: ../../rst/dev_guide/testing_validate-modules.rst:109 -msgid "Interpreter line is not ``#!/usr/bin/python``" -msgstr "インタープリター行、``#!/usr/bin/python`` ではありません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:110 -msgid "missing-return" -msgstr "missing-return" - -#: ../../rst/dev_guide/testing_validate-modules.rst:110 -msgid "No ``RETURN`` documentation provided" -msgstr "``RETURN`` のドキュメントは提供されていません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:111 -msgid "missing-return-legacy" -msgstr "missing-return-legacy" - -#: ../../rst/dev_guide/testing_validate-modules.rst:111 -msgid "No ``RETURN`` documentation provided for legacy module" -msgstr "レガシーモジュールには ``RETURN`` のドキュメントがありません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:112 -msgid "missing-suboption-docs" -msgstr "missing-suboption-docs" - -#: ../../rst/dev_guide/testing_validate-modules.rst:112 -msgid "Argument in argument_spec has sub-options but documentation does not define sub-options" -msgstr "argument_spec の引数にはサブオプションョンがあるが、ドキュメントではサブオプションが定義されていない。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:113 -msgid "module-incorrect-version-added" -msgstr "module-incorrect-version-added" - -#: ../../rst/dev_guide/testing_validate-modules.rst:113 -msgid "Module level ``version_added`` is incorrect" -msgstr "モジュールレベル ``version_added`` は正しくありません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:114 -msgid "module-invalid-version-added" -msgstr "module-invalid-version-added" - -#: ../../rst/dev_guide/testing_validate-modules.rst:114 -msgid "Module level ``version_added`` is not a valid version number" -msgstr "モジュールレベルの ``version_added`` は、有効なバージョン番号ではありません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:115 -msgid "module-utils-specific-import" -msgstr "module-utils-specific-import" - -#: ../../rst/dev_guide/testing_validate-modules.rst:115 -msgid "``module_utils`` imports should import specific components, not ``*``" -msgstr "``module_utils`` は、``*`` ではなく、特定のコンポーネントをインポートする必要があります。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:116 -msgid "multiple-utils-per-requires" -msgstr "multiple-utils-per-requires" - -#: ../../rst/dev_guide/testing_validate-modules.rst:116 -msgid "``Ansible.ModuleUtils`` requirements do not support multiple modules per statement" -msgstr "``Ansible.ModuleUtils`` 要件は、ステートメントごとに複数のモジュールをサポートしません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:117 -msgid "multiple-csharp-utils-per-requires" -msgstr "multiple-csharp-utils-per-requires" - -#: ../../rst/dev_guide/testing_validate-modules.rst:117 -msgid "Ansible C# util requirements do not support multiple utils per statement" -msgstr "C# ユーティリティー要件は、ステートメントごとに複数のモジュールをサポートしません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:118 -msgid "no-default-for-required-parameter" -msgstr "no-default-for-required-parameter" - -#: ../../rst/dev_guide/testing_validate-modules.rst:118 -msgid "Option is marked as required but specifies a default. Arguments with a default should not be marked as required" -msgstr "オプションは必須と識別されますが、デフォルトの引数を指定します。デフォルトの引数は必須と識別しないでください。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:119 -msgid "nonexistent-parameter-documented" -msgstr "nonexistent-parameter-documented" - -#: ../../rst/dev_guide/testing_validate-modules.rst:119 -msgid "Argument is listed in DOCUMENTATION.options, but not accepted by the module" -msgstr "引数は DOCUMENTATION.options に一覧表示されますが、モジュールでは受け入れられません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:120 -msgid "option-incorrect-version-added" -msgstr "option-incorrect-version-added" - -#: ../../rst/dev_guide/testing_validate-modules.rst:120 -msgid "``version_added`` for new option is incorrect" -msgstr "新しいオプションの ``version_added`` は正しくありません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:121 -msgid "option-invalid-version-added" -msgstr "option-invalid-version-added" - -#: ../../rst/dev_guide/testing_validate-modules.rst:121 -msgid "``version_added`` for option is not a valid version number" -msgstr "``version_added`` オプションが有効なバージョン番号ではありません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:122 -msgid "parameter-invalid" -msgstr "parameter-invalid" - -#: ../../rst/dev_guide/testing_validate-modules.rst:122 -msgid "Argument in argument_spec is not a valid python identifier" -msgstr "argument_spec の引数は有効な python 識別子ではありません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:123 -msgid "parameter-invalid-elements" -msgstr "parameter-invalid-elements" - -#: ../../rst/dev_guide/testing_validate-modules.rst:123 -msgid "Value for \"elements\" is valid only when value of \"type\" is ``list``" -msgstr "「elements」の値は、「type」の値が ``list`` である場合に限り有効である。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:124 -msgid "implied-parameter-type-mismatch" -msgstr "implied-parameter-type-mismatch" - -#: ../../rst/dev_guide/testing_validate-modules.rst:124 -msgid "Argument_spec implies ``type=\"str\"`` but documentation defines it as different data type" -msgstr "Argument_spec には ``type=\"str\"`` の意が含まれるが、ドキュメントでは、別のデータ型として指定されている。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:125 -msgid "parameter-type-not-in-doc" -msgstr "parameter-type-not-in-doc" - -#: ../../rst/dev_guide/testing_validate-modules.rst:125 -msgid "Type value is defined in ``argument_spec`` but documentation doesn't specify a type" -msgstr "タイプ値は ``argument_spec`` で定義されています。しかし、ドキュメントはタイプを指定していません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:126 -msgid "parameter-alias-repeated" -msgstr "parameter-alias-repeated" - -#: ../../rst/dev_guide/testing_validate-modules.rst:126 -#: ../../rst/dev_guide/testing_validate-modules.rst:127 -#: ../../rst/dev_guide/testing_validate-modules.rst:129 -#: ../../rst/dev_guide/testing_validate-modules.rst:130 -msgid "Parameters" -msgstr "パラメーター" - -#: ../../rst/dev_guide/testing_validate-modules.rst:126 -msgid "argument in argument_spec has at least one alias specified multiple times in aliases" -msgstr "argument_spec の引数には、エイリアスに複数回指定されたエイリアスが 1 つ以上含まれます" - -#: ../../rst/dev_guide/testing_validate-modules.rst:127 -msgid "parameter-alias-self" -msgstr "parameter-alias-self" - -#: ../../rst/dev_guide/testing_validate-modules.rst:127 -msgid "argument in argument_spec is specified as its own alias" -msgstr "argument_spec の引数は、独自のエイリアスとして指定されます。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:128 -msgid "parameter-documented-multiple-times" -msgstr "parameter-documented-multiple-times" - -#: ../../rst/dev_guide/testing_validate-modules.rst:128 -msgid "argument in argument_spec with aliases is documented multiple times" -msgstr "エイリアスを持つ argument_spec の引数が複数回文書化されています。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:129 -msgid "parameter-list-no-elements" -msgstr "parameter-list-no-elements" - -#: ../../rst/dev_guide/testing_validate-modules.rst:129 -msgid "argument in argument_spec \"type\" is specified as ``list`` without defining \"elements\"" -msgstr "argument_spec「type」の引数は、「要素」を定義せずに ``list`` のように指定されます。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:130 -msgid "parameter-state-invalid-choice" -msgstr "parameter-state-invalid-choice" - -#: ../../rst/dev_guide/testing_validate-modules.rst:130 -msgid "Argument ``state`` includes ``get``, ``list`` or ``info`` as a choice. Functionality should be in an ``_info`` or (if further conditions apply) ``_facts`` module." -msgstr "引数 ``state`` には、``get``、``list``、または ``info`` が含まれています。機能性は ``_info`` または (追加の条件が適用される場合) ``_facts`` モジュールである必要があります。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:131 -msgid "python-syntax-error" -msgstr "python-syntax-error" - -#: ../../rst/dev_guide/testing_validate-modules.rst:131 -msgid "Python ``SyntaxError`` while parsing module" -msgstr "モジュールの解析中に Python ``SyntaxError``" - -#: ../../rst/dev_guide/testing_validate-modules.rst:132 -msgid "removal-version-must-be-major" -msgstr "removal-version-must-be-major" - -#: ../../rst/dev_guide/testing_validate-modules.rst:132 -msgid "According to the semantic versioning specification (https://semver.org/), the only versions in which features are allowed to be removed are major versions (x.0.0)" -msgstr "セマンティックバージョニング仕様 (https://semver.org/)) によると、機能の削除が許可されているバージョンはメジャーバージョン (x.0.0) のみです。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:133 -msgid "return-syntax-error" -msgstr "return-syntax-error" - -#: ../../rst/dev_guide/testing_validate-modules.rst:133 -msgid "``RETURN`` is not valid YAML, ``RETURN`` fragments missing or invalid" -msgstr "``RETURN`` は、有効な YAML ではありません。``RETURN`` フラグメントが見つからないか、無効です。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:134 -msgid "return-invalid-version-added" -msgstr "return-invalid-version-added" - -#: ../../rst/dev_guide/testing_validate-modules.rst:134 -msgid "``version_added`` for return value is not a valid version number" -msgstr "戻り値の ``version_added`` は、有効なバージョン番号ではありません" - -#: ../../rst/dev_guide/testing_validate-modules.rst:135 -msgid "subdirectory-missing-init" -msgstr "subdirectory-missing-init" - -#: ../../rst/dev_guide/testing_validate-modules.rst:135 -msgid "Ansible module subdirectories must contain an ``__init__.py``" -msgstr "Ansible モジュールのサブディレクトリーには ``__init__.py`` が含まれている必要があります。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:136 -msgid "try-except-missing-has" -msgstr "try-except-missing-has" - -#: ../../rst/dev_guide/testing_validate-modules.rst:136 -msgid "Try/Except ``HAS_`` expression missing" -msgstr "try/Except ``HAS_`` 式がない" - -#: ../../rst/dev_guide/testing_validate-modules.rst:137 -msgid "undocumented-parameter" -msgstr "undocumented-parameter" - -#: ../../rst/dev_guide/testing_validate-modules.rst:137 -msgid "Argument is listed in the argument_spec, but not documented in the module" -msgstr "引数が argument_spec に記載されているが、このモジュールでは文書化されていない。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:138 -msgid "unidiomatic-typecheck" -msgstr "unidiomatic-typecheck" - -#: ../../rst/dev_guide/testing_validate-modules.rst:138 -msgid "Type comparison using ``type()`` found. Use ``isinstance()`` instead" -msgstr "``type()`` を使用したタイプ比較。代わりに ``isinstance()`` を使用してください。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:139 -msgid "unknown-doc-fragment" -msgstr "unknown-doc-fragment" - -#: ../../rst/dev_guide/testing_validate-modules.rst:139 -msgid "Unknown pre-existing ``DOCUMENTATION`` error" -msgstr "不明な既存の ``DOCUMENTATION`` エラー" - -#: ../../rst/dev_guide/testing_validate-modules.rst:140 -msgid "use-boto3" -msgstr "use-boto3" - -#: ../../rst/dev_guide/testing_validate-modules.rst:140 -msgid "``boto`` import found, new modules should use ``boto3``" -msgstr "``boto`` インポートが見つかりました。代わりに ``boto3`` を使用してください" - -#: ../../rst/dev_guide/testing_validate-modules.rst:141 -msgid "use-fail-json-not-sys-exit" -msgstr "use-fail-json-not-sys-exit" - -#: ../../rst/dev_guide/testing_validate-modules.rst:141 -msgid "``sys.exit()`` call found. Should be ``exit_json``/``fail_json``" -msgstr "``sys.exit()`` 呼び出しが見つかりました。``exit_json``/``fail_json`` でなければなりません。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:142 -msgid "use-module-utils-urls" -msgstr "use-module-utils-urls" - -#: ../../rst/dev_guide/testing_validate-modules.rst:142 -msgid "``requests`` import found, should use ``ansible.module_utils.urls`` instead" -msgstr "``requests`` インポートしています。代わりに ``ansible.module_utils.urls`` を使用してください" - -#: ../../rst/dev_guide/testing_validate-modules.rst:143 -msgid "use-run-command-not-os-call" -msgstr "use-run-command-not-os-call" - -#: ../../rst/dev_guide/testing_validate-modules.rst:143 -msgid "``os.call`` used instead of ``module.run_command``" -msgstr "``module.run_command`` の代わりに、``os.call`` を使用します。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:144 -msgid "use-run-command-not-popen" -msgstr "use-run-command-not-popen" - -#: ../../rst/dev_guide/testing_validate-modules.rst:144 -msgid "``subprocess.Popen`` used instead of ``module.run_command``" -msgstr "``module.run_command`` の代わりに、``subprocess.Popen`` を使用します。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:145 -msgid "use-short-gplv3-license" -msgstr "use-short-gplv3-license" - -#: ../../rst/dev_guide/testing_validate-modules.rst:145 -msgid "GPLv3 license header should be the :ref:`short form ` for new modules" -msgstr "GPLv3 ライセンスヘッダーは、新しいモジュールの :ref:`短縮形 ` である必要があります" - -#: ../../rst/dev_guide/testing_validate-modules.rst:146 -msgid "mutually_exclusive-type" -msgstr "mutually_exclusive-type" - -#: ../../rst/dev_guide/testing_validate-modules.rst:146 -msgid "mutually_exclusive entry contains non-string value" -msgstr "mutually_exclusive エントリーには文字列以外の値が含まれる" - -#: ../../rst/dev_guide/testing_validate-modules.rst:147 -msgid "mutually_exclusive-collision" -msgstr "mutually_exclusive-collision" - -#: ../../rst/dev_guide/testing_validate-modules.rst:147 -msgid "mutually_exclusive entry has repeated terms" -msgstr "mutually_exclusive エントリーが繰り返し使用される" - -#: ../../rst/dev_guide/testing_validate-modules.rst:148 -msgid "mutually_exclusive-unknown" -msgstr "mutually_exclusive-unknown" - -#: ../../rst/dev_guide/testing_validate-modules.rst:148 -msgid "mutually_exclusive entry contains option which does not appear in argument_spec (potentially an alias of an option?)" -msgstr "mutually_exclusive エントリーには、argument_spec に表示されないオプションが含まれている (オプションのエイリアスである可能性がありますか?)" - -#: ../../rst/dev_guide/testing_validate-modules.rst:149 -msgid "required_one_of-type" -msgstr "required_one_of-type" - -#: ../../rst/dev_guide/testing_validate-modules.rst:149 -msgid "required_one_of entry contains non-string value" -msgstr "required_one_of エントリーには文字列以外の値が含まれる" - -#: ../../rst/dev_guide/testing_validate-modules.rst:150 -msgid "required_one_of-collision" -msgstr "required_one_of-collision" - -#: ../../rst/dev_guide/testing_validate-modules.rst:150 -msgid "required_one_of entry has repeated terms" -msgstr "required_one_of エントリーが繰り返し使用される" - -#: ../../rst/dev_guide/testing_validate-modules.rst:151 -msgid "required_one_of-unknown" -msgstr "required_one_of-unknown" - -#: ../../rst/dev_guide/testing_validate-modules.rst:151 -msgid "required_one_of entry contains option which does not appear in argument_spec (potentially an alias of an option?)" -msgstr "required_one_of エントリーには、argument_spec に表示されないオプションが含まれています (オプションのエイリアスである可能性がありますか?)" - -#: ../../rst/dev_guide/testing_validate-modules.rst:152 -msgid "required_together-type" -msgstr "required_together-type" - -#: ../../rst/dev_guide/testing_validate-modules.rst:152 -msgid "required_together entry contains non-string value" -msgstr "required_together エントリーには文字列以外の値が含まれる" - -#: ../../rst/dev_guide/testing_validate-modules.rst:153 -msgid "required_together-collision" -msgstr "required_together-collision" - -#: ../../rst/dev_guide/testing_validate-modules.rst:153 -msgid "required_together entry has repeated terms" -msgstr "required_together エントリーが繰り返し使用される" - -#: ../../rst/dev_guide/testing_validate-modules.rst:154 -msgid "required_together-unknown" -msgstr "required_together-unknown" - -#: ../../rst/dev_guide/testing_validate-modules.rst:154 -msgid "required_together entry contains option which does not appear in argument_spec (potentially an alias of an option?)" -msgstr "required_together エントリーには、argument_spec に表示されないオプションが含まれている (オプションのエイリアスである可能性がありますか?)" - -#: ../../rst/dev_guide/testing_validate-modules.rst:155 -msgid "required_if-is_one_of-type" -msgstr "required_if-is_one_of-type" - -#: ../../rst/dev_guide/testing_validate-modules.rst:155 -msgid "required_if entry has a fourth value which is not a bool" -msgstr "required_if エントリーには bool ではない 4 つ目の値がある" - -#: ../../rst/dev_guide/testing_validate-modules.rst:156 -msgid "required_if-requirements-type" -msgstr "required_if-requirements-type" - -#: ../../rst/dev_guide/testing_validate-modules.rst:156 -msgid "required_if entry has a third value (requirements) which is not a list or tuple" -msgstr "required_if エントリーには、リストまたはタプルではない 3 つの値 (必須) があります。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:157 -msgid "required_if-requirements-collision" -msgstr "required_if-requirements-collision" - -#: ../../rst/dev_guide/testing_validate-modules.rst:157 -msgid "required_if entry has repeated terms in requirements" -msgstr "required_if エントリーが繰り返し使用されます。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:158 -msgid "required_if-requirements-unknown" -msgstr "required_if-requirements-unknown" - -#: ../../rst/dev_guide/testing_validate-modules.rst:158 -msgid "required_if entry's requirements contains option which does not appear in argument_spec (potentially an alias of an option?)" -msgstr "required_if エントリーの要件には、argument_spec に表示されないオプションが含まれている (オプションのエイリアスである可能性がありますか?)" - -#: ../../rst/dev_guide/testing_validate-modules.rst:159 -msgid "required_if-unknown-key" -msgstr "required_if-unknown-key" - -#: ../../rst/dev_guide/testing_validate-modules.rst:159 -msgid "required_if entry's key does not appear in argument_spec (potentially an alias of an option?)" -msgstr "required_if エントリーのキーは argument_spec に表示されない (オプションのエイリアスである可能性がありますか?)" - -#: ../../rst/dev_guide/testing_validate-modules.rst:160 -msgid "required_if-key-in-requirements" -msgstr "required_if-key-in-requirements" - -#: ../../rst/dev_guide/testing_validate-modules.rst:160 -msgid "required_if entry contains its key in requirements list/tuple" -msgstr "required_if エントリーには要件リスト/タプルのキーが含まれる。" - -#: ../../rst/dev_guide/testing_validate-modules.rst:161 -msgid "required_if-value-type" -msgstr "required_if-value-type" - -#: ../../rst/dev_guide/testing_validate-modules.rst:161 -msgid "required_if entry's value is not of the type specified for its key" -msgstr "required_if エントリーの値は、キーに指定されたタイプではない" - -#: ../../rst/dev_guide/testing_validate-modules.rst:162 -msgid "required_by-collision" -msgstr "required_by-collision" - -#: ../../rst/dev_guide/testing_validate-modules.rst:162 -msgid "required_by entry has repeated terms" -msgstr "required_by エントリーが繰り返し使用される" - -#: ../../rst/dev_guide/testing_validate-modules.rst:163 -msgid "required_by-unknown" -msgstr "required_by-unknown" - -#: ../../rst/dev_guide/testing_validate-modules.rst:163 -msgid "required_by entry contains option which does not appear in argument_spec (potentially an alias of an option?)" -msgstr "required_by エントリーには、argument_spec に表示されないオプションが含まれる (オプションのエイリアスである可能性がありますか?)" - -#: ../../rst/dev_guide/testing_validate-modules.rst:164 -msgid "version-added-must-be-major-or-minor" -msgstr "version-added-must-be-major-or-minor" - -#: ../../rst/dev_guide/testing_validate-modules.rst:164 -msgid "According to the semantic versioning specification (https://semver.org/), the only versions in which features are allowed to be added are major and minor versions (x.y.0)" -msgstr "セマンティックバージョニング仕様 (https://semver.org/)) によると、機能の追加が許可されているバージョンはメジャーバージョンおよびマイナーバージョン (x.y.0) のみです。" - -#~ msgid "All Python imports in ``lib/ansible/modules/`` and ``lib/ansible/module_utils/`` which are not from the Python standard library must be imported in a try/except ImportError block." -#~ msgstr "" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/galaxy.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/galaxy.po deleted file mode 100644 index 5e5fd586cc1..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/galaxy.po +++ /dev/null @@ -1,943 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2019 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-03-08 20:25+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/galaxy/dev_guide.rst:5 -msgid "Galaxy Developer Guide" -msgstr "Galaxy 開発者ガイド" - -#: ../../rst/galaxy/dev_guide.rst:7 -msgid "You can host collections and roles on Galaxy to share with the Ansible community. Galaxy content is formatted in pre-packaged units of work such as :ref:`roles `, and new in Galaxy 3.2, :ref:`collections `. You can create roles for provisioning infrastructure, deploying applications, and all of the tasks you do everyday. Taking this a step further, you can create collections which provide a comprehensive package of automation that may include multiple playbooks, roles, modules, and plugins." -msgstr "Galaxy でコレクションとロールをホストして、Ansible コミュニティーと共有できます。Galaxy コンテンツは、事前にパッケージ化された作業単位 (:ref:`ロール`、Galaxy 3.2 の新機能、:ref:`コレクション ` など) でフォーマットされます。インフラストラクチャーのプロビジョニング、アプリケーションのデプロイメント、および日常的に行うすべてのタスクのロールを作成できます。これをさらに一歩進めて、複数の Playbook、ロール、モジュール、およびプラグインを含む可能性のある自動化の包括的なパッケージを提供するコレクションを作成できます。" - -#: ../../rst/galaxy/dev_guide.rst:17 -msgid "Creating collections for Galaxy" -msgstr "Galaxy のコレクションの作成" - -#: ../../rst/galaxy/dev_guide.rst:19 -msgid "Collections are a distribution format for Ansible content. You can use collections to package and distribute playbooks, roles, modules, and plugins. You can publish and use collections through `Ansible Galaxy `_." -msgstr "コレクションは、Ansible コンテンツのディストリビューション形式です。コレクションを使用して、Playbook、ロール、モジュール、プラグインをパッケージ化および配布できます。`Ansible Galaxy `_ を介してコレクションを公開および使用できます。" - -#: ../../rst/galaxy/dev_guide.rst:22 -msgid "See :ref:`developing_collections` for details on how to create collections." -msgstr "コレクションの作成方法は「:ref:`developing_collections`」を参照してください。" - -#: ../../rst/galaxy/dev_guide.rst:28 -msgid "Creating roles for Galaxy" -msgstr "Galaxy のロールの作成" - -#: ../../rst/galaxy/dev_guide.rst:30 -msgid "Use the ``init`` command to initialize the base structure of a new role, saving time on creating the various directories and main.yml files a role requires" -msgstr "``init`` コマンドを使用して新規ロールの基本構造を初期化し、ロールに必要なさまざまなディレクトリーおよび main.yml ファイルを作成する際の時間を短縮します。" - -#: ../../rst/galaxy/dev_guide.rst:36 -msgid "The above will create the following directory structure in the current working directory:" -msgstr "上記により、現在の作業ディレクトリーに以下のディレクトリー構造が作成されます。" - -#: ../../rst/galaxy/dev_guide.rst:57 -msgid "If you want to create a repository for the role the repository root should be `role_name`." -msgstr "ロールのリポジトリーを作成する場合、リポジトリーのルートは `role_name` である必要があります。" - -#: ../../rst/galaxy/dev_guide.rst:60 -msgid "Force" -msgstr "Force" - -#: ../../rst/galaxy/dev_guide.rst:62 -msgid "If a directory matching the name of the role already exists in the current working directory, the init command will result in an error. To ignore the error use the ``--force`` option. Force will create the above subdirectories and files, replacing anything that matches." -msgstr "現在の作業ディレクトリーにすでにロール名に一致するディレクトリーが存在する場合は、init コマンドによりエラーが発生します。エラーを無視するには、``--force`` オプションを使用します。強制的に、上記のサブディレクトリーとファイルを作成し、一致するものをすべて置き換えます。" - -#: ../../rst/galaxy/dev_guide.rst:66 -msgid "Container enabled" -msgstr "有効なコンテナー" - -#: ../../rst/galaxy/dev_guide.rst:68 -msgid "If you are creating a Container Enabled role, pass ``--type container`` to ``ansible-galaxy init``. This will create the same directory structure as above, but populate it with default files appropriate for a Container Enabled role. For instance, the README.md has a slightly different structure, the *.travis.yml* file tests the role using `Ansible Container `_, and the meta directory includes a *container.yml* file." -msgstr "Container Enabled ロールを作成する場合は、``--type container`` を ``ansible-galaxy init`` に渡します。これにより、上記のものと同じディレクトリー構造が作成されますが、これを Container Enabled ロールに適したデフォルトファイルで追加します。たとえば、README.md には若干異なる構造があり、*.travis.yml* ファイルでは、`Ansible Container `_ を使用してロールをテストします。また、メタディレクトリーには *container.yml* ファイルが含まれます。" - -#: ../../rst/galaxy/dev_guide.rst:73 -msgid "Using a custom role skeleton" -msgstr "カスタムロールのスケルトンの使用" - -#: ../../rst/galaxy/dev_guide.rst:75 -msgid "A custom role skeleton directory can be supplied as follows:" -msgstr "カスタムロールのスケルトンディレクトリーは、以下のように指定できます。" - -#: ../../rst/galaxy/dev_guide.rst:81 -msgid "When a skeleton is provided, init will:" -msgstr "スケルトンを指定すると init は以下のことを行います。" - -#: ../../rst/galaxy/dev_guide.rst:83 -msgid "copy all files and directories from the skeleton to the new role" -msgstr "すべてのファイルおよびディレクトリーをスケルトンから新しいロールにコピーします。" - -#: ../../rst/galaxy/dev_guide.rst:84 -msgid "any .j2 files found outside of a templates folder will be rendered as templates. The only useful variable at the moment is role_name" -msgstr "テンプレートディレクトリーの外部で見つかったすべての .j2 ファイルはテンプレートとしてレンダリングされます。現在便利な変数は role_name です" - -#: ../../rst/galaxy/dev_guide.rst:85 -msgid "The .git folder and any .git_keep files will not be copied" -msgstr ".git ディレクトリーおよび .git_keep ファイルはコピーされません。" - -#: ../../rst/galaxy/dev_guide.rst:87 -msgid "Alternatively, the role_skeleton and ignoring of files can be configured via ansible.cfg" -msgstr "または、role_skeleton とファイルの無視は、ansible.cfgで設定できます" - -#: ../../rst/galaxy/dev_guide.rst:96 -msgid "Authenticate with Galaxy" -msgstr "Galaxy での認証" - -#: ../../rst/galaxy/dev_guide.rst:98 -msgid "Using the ``import``, ``delete`` and ``setup`` commands to manage your roles on the Galaxy website requires authentication, and the ``login`` command can be used to do just that. Before you can use the ``login`` command, you must create an account on the Galaxy website." -msgstr "Galaxy Web サイトでロールを管理する ``import`` コマンド、``delete`` コマンド、および ``setup`` コマンドを使用するには認証が必要で、``login`` コマンドを使用してこれを行うことができます。``login`` コマンドを使用する前に、Galaxy の Web サイトでアカウントを作成する必要があります。" - -#: ../../rst/galaxy/dev_guide.rst:101 -msgid "The ``login`` command requires using your GitHub credentials. You can use your username and password, or you can create a `personal access token `_. If you choose to create a token, grant minimal access to the token, as it is used just to verify identify." -msgstr "``login`` コマンドには、GitHub 認証情報を使用する必要があります。ユーザー名とパスワードを使用するか、`personal access token `_ を作成することができます。トークンの作成を選択した場合は、識別を確認するためにのみ使用されます。" - -#: ../../rst/galaxy/dev_guide.rst:103 -msgid "The following shows authenticating with the Galaxy website using a GitHub username and password:" -msgstr "以下は、GitHub のユーザー名とパスワードを使用した Galaxy Web サイトでの認証を示しています。" - -#: ../../rst/galaxy/dev_guide.rst:119 -msgid "When you choose to use your username and password, your password is not sent to Galaxy. It is used to authenticates with GitHub and create a personal access token. It then sends the token to Galaxy, which in turn verifies that your identity and returns a Galaxy access token. After authentication completes the GitHub token is destroyed." -msgstr "ユーザー名とパスワードの使用を選択すると、パスワードは Galaxy に送信されません。これは GitHub で認証され、個人アクセストークンを作成するために使用されます。次にトークンを Galaxy に送信し、その ID を検証し、Galaxy アクセストークンを返します。認証が完了すると、GitHub トークンが破棄されます。" - -#: ../../rst/galaxy/dev_guide.rst:123 -msgid "If you do not want to use your GitHub password, or if you have two-factor authentication enabled with GitHub, use the ``--github-token`` option to pass a personal access token that you create." -msgstr "GitHub パスワードを使用しない場合や、GitHub で 2 段階認証を有効にしている場合は、``--github-token`` オプションを使用して、作成する個人用アクセストークンを渡します。" - -#: ../../rst/galaxy/dev_guide.rst:127 -msgid "Import a role" -msgstr "ロールのインポート" - -#: ../../rst/galaxy/dev_guide.rst:129 -msgid "The ``import`` command requires that you first authenticate using the ``login`` command. Once authenticated you can import any GitHub repository that you own or have been granted access." -msgstr "``import`` コマンドでは、最初に ``login`` コマンドを使用して認証する必要があります。認証されると、所有またはアクセスが付与された GitHub リポジトリーをすべてインポートできます。" - -#: ../../rst/galaxy/dev_guide.rst:131 -msgid "Use the following to import to role:" -msgstr "以下を使用してロールにインポートします。" - -#: ../../rst/galaxy/dev_guide.rst:137 -msgid "By default the command will wait for Galaxy to complete the import process, displaying the results as the import progresses:" -msgstr "デフォルトでは、コマンドは Galaxy がインポートプロセスを完了するまで待機し、インポートが進行するにつれて結果を表示します。" - -#: ../../rst/galaxy/dev_guide.rst:155 -msgid "Branch" -msgstr "ブランチ" - -#: ../../rst/galaxy/dev_guide.rst:157 -msgid "Use the ``--branch`` option to import a specific branch. If not specified, the default branch for the repo will be used." -msgstr "特定のブランチをインポートするには、``--branch`` オプションを使用します。指定しない場合は、リポジトリーのデフォルトブランチが使用されます。" - -#: ../../rst/galaxy/dev_guide.rst:160 -msgid "Role name" -msgstr "ロール名" - -#: ../../rst/galaxy/dev_guide.rst:162 -msgid "By default the name given to the role will be derived from the GitHub repository name. However, you can use the ``--role-name`` option to override this and set the name." -msgstr "デフォルトでは、ロールに指定された名前は GitHub リポジトリー名から派生しますが、``--role-name`` オプションを使用してこれを上書きして名前を設定できます。" - -#: ../../rst/galaxy/dev_guide.rst:165 -msgid "No wait" -msgstr "待機なし" - -#: ../../rst/galaxy/dev_guide.rst:167 -msgid "If the ``--no-wait`` option is present, the command will not wait for results. Results of the most recent import for any of your roles is available on the Galaxy web site by visiting *My Imports*." -msgstr "``--no-wait`` オプションが存在する場合は、結果を待ちません。すべてのロールに対する最新のインポートの結果は、*My Imports* に移動して Galaxy Web サイトで利用できるようになります。" - -#: ../../rst/galaxy/dev_guide.rst:170 -msgid "Delete a role" -msgstr "ロールの削除" - -#: ../../rst/galaxy/dev_guide.rst:172 -msgid "The ``delete`` command requires that you first authenticate using the ``login`` command. Once authenticated you can remove a role from the Galaxy web site. You are only allowed to remove roles where you have access to the repository in GitHub." -msgstr "``delete`` コマンドでは、最初に ``login`` コマンドを使用して認証する必要があります。認証されると、Galaxy Web サイトからロールを削除できます。GitHub のリポジトリーにアクセスできるロールのみを削除することができます。" - -#: ../../rst/galaxy/dev_guide.rst:174 -msgid "Use the following to delete a role:" -msgstr "ロールを削除するには、以下を使用します。" - -#: ../../rst/galaxy/dev_guide.rst:180 -msgid "This only removes the role from Galaxy. It does not remove or alter the actual GitHub repository." -msgstr "これにより、Galaxy からロールのみが削除されます。実際の GitHub リポジトリーを削除したり、変更したりしません。" - -#: ../../rst/galaxy/dev_guide.rst:184 -msgid "Travis integrations" -msgstr "Travis 統合" - -#: ../../rst/galaxy/dev_guide.rst:186 -msgid "You can create an integration or connection between a role in Galaxy and `Travis `_. Once the connection is established, a build in Travis will automatically trigger an import in Galaxy, updating the search index with the latest information about the role." -msgstr "Galaxy と `Travis `_ のロール間の統合またはコネクションを作成できます。コネクションが確立されると、Travis のビルドが自動的に Galaxy でインポートを発生させ、ロールに関する最新情報で検索インデックスを更新します。" - -#: ../../rst/galaxy/dev_guide.rst:189 -msgid "You create the integration using the ``setup`` command, but before an integration can be created, you must first authenticate using the ``login`` command; you will also need an account in Travis, and your Travis token. Once you're ready, use the following command to create the integration:" -msgstr "``setup`` コマンドを使用して統合を作成しますが、統合を作成する前に、最初に ``login`` コマンドを使用して認証する必要があります。Travis および Travis トークンにもアカウントが必要になります。準備が整ったら、以下のコマンドを使用して統合を作成します。" - -#: ../../rst/galaxy/dev_guide.rst:196 -msgid "The setup command requires your Travis token, however the token is not stored in Galaxy. It is used along with the GitHub username and repo to create a hash as described in `the Travis documentation `_. The hash is stored in Galaxy and used to verify notifications received from Travis." -msgstr "setup コマンドには Travis トークンが必要ですが、トークンは Galaxy に保存されていません。これは、`the Travis documentation `_ で説明されているように、GitHub ユーザー名およびリポジトリーとともに使用されます。ハッシュは Galaxy に格納され、Travis から受信した通知の検証に使用されます。" - -#: ../../rst/galaxy/dev_guide.rst:199 -msgid "The setup command enables Galaxy to respond to notifications. To configure Travis to run a build on your repository and send a notification, follow the `Travis getting started guide `_." -msgstr "setup コマンドを使用すると、Galaxy が通知に応答します。Travis がリポジトリーでビルドを実行し、通知を送信するように設定するには、`Travis getting started guide `_ に従います。" - -#: ../../rst/galaxy/dev_guide.rst:202 -msgid "To instruct Travis to notify Galaxy when a build completes, add the following to your .travis.yml file:" -msgstr "ビルドの完了時に Galaxy に通知するように Travis に指示するには、.travis.yml ファイルに以下を追加します。" - -#: ../../rst/galaxy/dev_guide.rst:211 -msgid "List Travis integrations" -msgstr "Travis 統合の一覧表示" - -#: ../../rst/galaxy/dev_guide.rst:213 -msgid "Use the ``--list`` option to display your Travis integrations:" -msgstr "``--list`` オプションを使用して、Travis 統合を表示します。" - -#: ../../rst/galaxy/dev_guide.rst:227 -msgid "Remove Travis integrations" -msgstr "Travis 統合の削除" - -#: ../../rst/galaxy/dev_guide.rst:229 -msgid "Use the ``--remove`` option to disable and remove a Travis integration:" -msgstr "``--remove`` オプションを使用して、Travis 統合を無効化および削除します。" - -#: ../../rst/galaxy/dev_guide.rst:235 -msgid "Provide the ID of the integration to be disabled. You can find the ID by using the ``--list`` option." -msgstr "無効にする統合の ID を指定します。``--list`` オプションを使用して ID を検索できます。" - -#: ../../rst/galaxy/dev_guide.rst:239 ../../rst/galaxy/user_guide.rst:486 -msgid ":ref:`collections`" -msgstr ":ref:`collections`" - -#: ../../rst/galaxy/dev_guide.rst:240 ../../rst/galaxy/user_guide.rst:487 -msgid "Shareable collections of modules, playbooks and roles" -msgstr "モジュール、Playbook、およびロールの共有可能なコレクション" - -#: ../../rst/galaxy/dev_guide.rst:241 ../../rst/galaxy/user_guide.rst:488 -msgid ":ref:`playbooks_reuse_roles`" -msgstr ":ref:`playbooks_reuse_roles`" - -#: ../../rst/galaxy/dev_guide.rst:242 -msgid "All about ansible roles" -msgstr "Ansible ロールに関するすべて" - -#: ../../rst/galaxy/dev_guide.rst:243 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/galaxy/dev_guide.rst:244 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/galaxy/dev_guide.rst:245 -msgid "`irc.freenode.net `_" -msgstr "`irc.freenode.net `_" - -#: ../../rst/galaxy/dev_guide.rst:246 -msgid "#ansible IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible)" - -#: ../../rst/galaxy/user_guide.rst:6 -msgid "Galaxy User Guide" -msgstr "Galaxy ユーザーガイド" - -#: ../../rst/galaxy/user_guide.rst:8 -msgid ":dfn:`Ansible Galaxy` refers to the `Galaxy `_ website, a free site for finding, downloading, and sharing community developed roles." -msgstr ":dfn:`Ansible Galaxy` は `Galaxy `_ の Web サイトを参照します。これは、コミュニティーが開発したロールを検索し、ダウンロードし、共有するための無料サイトです。" - -#: ../../rst/galaxy/user_guide.rst:10 -msgid "Use Galaxy to jump-start your automation project with great content from the Ansible community. Galaxy provides pre-packaged units of work such as :ref:`roles `, and new in Galaxy 3.2, :ref:`collections ` You can find roles for provisioning infrastructure, deploying applications, and all of the tasks you do everyday. The collection format provides a comprehensive package of automation that may include multiple playbooks, roles, modules, and plugins." -msgstr "Galaxy を使用して、Ansible コミュニティーの優れたコンテンツで自動化プロジェクトを活性化させます。Galaxy は、事前にパッケージ化された作業単位 (:ref:`ロール `、Galaxy 3.2 の新機能、:ref:`コレクション ` など) でフォーマットされます。インフラストラクチャーのプロビジョニング、アプリケーションのデプロイメント、および日常的に行うすべてのタスクのロールを検索できます。コレクション形式は、複数の Playbook、ロール、モジュール、プラグインを含む可能性のある自動化の包括的なパッケージを提供します。" - -#: ../../rst/galaxy/user_guide.rst:19 -msgid "Finding collections on Galaxy" -msgstr "Galaxy でコレクションの検索" - -#: ../../rst/galaxy/user_guide.rst:21 -msgid "To find collections on Galaxy:" -msgstr "Galaxy でコレクションを検索するには、以下を行います。" - -#: ../../rst/galaxy/user_guide.rst:23 -msgid "Click the :guilabel:`Search` icon in the left-hand navigation." -msgstr "左側のナビゲーションにある :guilabel:`Search` アイコンをクリックします。" - -#: ../../rst/galaxy/user_guide.rst:24 -msgid "Set the filter to *collection*." -msgstr "フィルターを *collection* に設定します。" - -#: ../../rst/galaxy/user_guide.rst:25 -msgid "Set other filters and press :guilabel:`enter`." -msgstr "他のフィルターを設定し、:guilabel:`enter` を押します。" - -#: ../../rst/galaxy/user_guide.rst:27 -msgid "Galaxy presents a list of collections that match your search criteria." -msgstr "Galaxy は、検索条件に一致するコレクションのリストを表示します。" - -#: ../../rst/galaxy/user_guide.rst:33 -msgid "Installing collections" -msgstr "コレクションのインストール" - -#: ../../rst/galaxy/user_guide.rst:37 -msgid "Installing a collection from Galaxy" -msgstr "Galaxy からコレクションのインストール" - -#: ../../rst/shared_snippets/installing_collections.txt:3 -msgid "By default, ``ansible-galaxy collection install`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`). You do not need any further configuration." -msgstr "デフォルトでは、``ansible-galaxy collection install`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の :file:`ansible.cfg` ファイルに記載)。追加設定は必要ありません。" - -#: ../../rst/shared_snippets/installing_collections.txt:7 -msgid "See :ref:`Configuring the ansible-galaxy client ` if you are using any other Galaxy server, such as Red Hat Automation Hub." -msgstr "Red Hat Automation Hub などの他の Galaxy サーバーを使用している場合は、「:ref:`Configuring the ansible-galaxy client `」を参照してください。" - -#: ../../rst/shared_snippets/installing_collections.txt:9 -msgid "To install a collection hosted in Galaxy:" -msgstr "Galaxy でホストされるコレクションをインストールするには、以下を実行します。" - -#: ../../rst/shared_snippets/installing_collections.txt:15 -msgid "To upgrade a collection to the latest available version from the Galaxy server you can use the ``--upgrade`` option:" -msgstr "コレクションを Galaxy サーバーから利用可能な最新バージョンにアップグレードするには、``--upgrade`` オプションを使用します。" - -#: ../../rst/shared_snippets/installing_collections.txt:21 -msgid "You can also directly use the tarball from your build:" -msgstr "ビルドから tarball を直接使用することもできます。" - -#: ../../rst/shared_snippets/installing_collections.txt:27 -msgid "You can build and install a collection from a local source directory. The ``ansible-galaxy`` utility builds the collection using the ``MANIFEST.json`` or ``galaxy.yml`` metadata in the directory." -msgstr "ローカルソースディレクトリーからコレクションを構築してインストールできます。``ansible-galaxy`` ユーティリティーは、ディレクトリー内の ``MANIFEST.json`` または ``galaxy.yml`` メタデータを使用してコレクションを構築します。" - -#: ../../rst/shared_snippets/installing_collections.txt:34 -msgid "You can also install multiple collections in a namespace directory." -msgstr "名前空間ディレクトリーに複数のコレクションをインストールすることもできます。" - -#: ../../rst/shared_snippets/installing_collections.txt:51 -msgid "The install command automatically appends the path ``ansible_collections`` to the one specified with the ``-p`` option unless the parent directory is already in a folder called ``ansible_collections``." -msgstr "install コマンドは、親ディレクトリーが ``ansible_collections`` ディレクトリーに含まれている場合を除き、``-p`` オプションで指定したパスに、パス ``ansible_collections`` を自動的に追加します。" - -#: ../../rst/shared_snippets/installing_collections.txt:55 -msgid "When using the ``-p`` option to specify the install path, use one of the values configured in :ref:`COLLECTIONS_PATHS`, as this is where Ansible itself will expect to find collections. If you don't specify a path, ``ansible-galaxy collection install`` installs the collection to the first path defined in :ref:`COLLECTIONS_PATHS`, which by default is ``~/.ansible/collections``" -msgstr "``-p`` オプションを使用してインストールパスを指定する場合は、Ansible 自体がコレクションを見つけることが予想される場所であるため、:ref:`COLLECTIONS_PATHS` に設定された値のいずれかを使用します。パスを指定しないと、``ansible-galaxy collection install`` は :ref:`COLLECTIONS_PATHS` で定義されている最初のパスにコレクションをインストールします。これは、デフォルトでは ``~/.ansible/collections`` です。" - -#: ../../rst/shared_snippets/installing_collections.txt:59 -msgid "You can also keep a collection adjacent to the current playbook, under a ``collections/ansible_collections/`` directory structure." -msgstr "また、``collections/ansible_collections/`` ディレクトリー構造の下で、コレクションを現在の Playbook の横に維持することもできます。" - -#: ../../rst/shared_snippets/installing_collections.txt:71 -msgid "See :ref:`collection_structure` for details on the collection directory structure." -msgstr "コレクションディレクトリー構造の詳細は、「:ref:`collection_structure`」を参照してください。" - -#: ../../rst/galaxy/user_guide.rst:44 -msgid "Downloading a collection from Automation Hub" -msgstr "Automation Hub からのコレクションのダウンロード" - -#: ../../rst/galaxy/user_guide.rst:46 -msgid "You can download collections from Automation Hub at the command line. Automation Hub content is available to subscribers only, so you must download an API token and configure your local environment to provide it before you can you download collections. To download a collection from Automation Hub with the ``ansible-galaxy`` command:" -msgstr "コマンドラインで Automation Hub からコレクションをダウンロードできます。Automation Hub コンテンツは、サブスクライバーのみで利用できるため、コレクションをダウンロードする前に API トークンをダウンロードし、ローカル環境を設定して提供する必要があります。``ansible-galaxy`` コマンドを使用して Automation Hub からコレクションをダウンロードするには、以下を実行します。" - -#: ../../rst/galaxy/user_guide.rst:48 -msgid "Get your Automation Hub API token. Go to https://cloud.redhat.com/ansible/automation-hub/token/ and click :guilabel:`Get API token` from the version dropdown to copy your API token." -msgstr "Automation Hub API トークンを取得します。https://cloud.redhat.com/ansible/automation-hub/token/ に移動し、バージョンドロップダウンの :guilabel:`Get API token` をクリックして API トークンをコピーします。" - -#: ../../rst/galaxy/user_guide.rst:49 -msgid "Configure Red Hat Automation Hub server in the ``server_list`` option under the ``[galaxy]`` section in your :file:`ansible.cfg` file." -msgstr ":file:`ansible.cfg` ファイルの ``[galaxy]`` セクションで、``server_list`` オプションで Red Hat Automation Hub サーバーを設定します。" - -#: ../../rst/galaxy/user_guide.rst:61 -msgid "Download the collection hosted in Automation Hub." -msgstr "Automation Hub でホストされるコレクションをダウンロードします。" - -#: ../../rst/galaxy/user_guide.rst:68 -msgid "`Getting started with Automation Hub `_" -msgstr "`Getting started with Automation Hub `_" - -#: ../../rst/galaxy/user_guide.rst:69 -msgid "An introduction to Automation Hub" -msgstr "Automation Hub の概要" - -#: ../../rst/galaxy/user_guide.rst:72 -msgid "Installing an older version of a collection" -msgstr "古いバージョンのコレクションのインストール" - -#: ../../rst/shared_snippets/installing_older_collection.txt:2 -msgid "You can only have one version of a collection installed at a time. By default ``ansible-galaxy`` installs the latest available version. If you want to install a specific version, you can add a version range identifier. For example, to install the 1.0.0-beta.1 version of the collection:" -msgstr "一度にインストールするコレクションのバージョンは 1 つだけです。デフォルトでは、``ansible-galaxy`` により利用可能な最新バージョンがインストールされます。特定のバージョンをインストールする場合は、バージョン範囲識別子を追加できます。たとえば、コレクションの 1.0.0-beta.1 バージョンをインストールするには、以下を実行します。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:8 -msgid "You can specify multiple range identifiers separated by ``,``. Use single quotes so the shell passes the entire command, including ``>``, ``!``, and other operators, along. For example, to install the most recent version that is greater than or equal to 1.0.0 and less than 2.0.0:" -msgstr "``,`` で区切って複数の範囲識別子を指定できます。シェルが、``>``、``!``、およびその他の演算子を含むコマンド全体を渡すように、一重引用符を使用します。たとえば、1.0.0 以上 2.0.0 未満の最新バージョンをインストールするには、次を実行します。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:14 -msgid "Ansible will always install the most recent version that meets the range identifiers you specify. You can use the following range identifiers:" -msgstr "Ansible は、指定する範囲識別子を満たす最新バージョンを常にインストールします。以下の範囲識別子を使用できます。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:16 -msgid "``*``: The most recent version. This is the default." -msgstr "``*``: 最新バージョンです。これがデフォルトです。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:17 -msgid "``!=``: Not equal to the version specified." -msgstr "``!=``: 指定されたバージョンと同等ではありません。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:18 -msgid "``==``: Exactly the version specified." -msgstr "``==``: 指定されたバージョンそのものになります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:19 -msgid "``>=``: Greater than or equal to the version specified." -msgstr "``>=``: 指定されたバージョン以上になります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:20 -msgid "``>``: Greater than the version specified." -msgstr "``>``: 指定されたバージョンよりも大きくなります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:21 -msgid "``<=``: Less than or equal to the version specified." -msgstr "``<=``: 指定されたバージョン以下になります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:22 -msgid "``<``: Less than the version specified." -msgstr "``<``: 指定されたバージョンよりも小さくなります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:25 -msgid "By default ``ansible-galaxy`` ignores pre-release versions. To install a pre-release version, you must use the ``==`` range identifier to require it explicitly." -msgstr "デフォルトでは、``ansible-galaxy`` はリリース前のバージョンを無視します。リリース前のバージョンをインストールするには、``==`` 範囲識別子を使用して明示的に要求する必要があります。" - -#: ../../rst/galaxy/user_guide.rst:77 -msgid "Install multiple collections with a requirements file" -msgstr "要件ファイルを使用した複数のコレクションのインストール" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:2 -msgid "You can also setup a ``requirements.yml`` file to install multiple collections in one command. This file is a YAML file in the format:" -msgstr "``requirements.yml`` ファイルを設定して、1 つのコマンドで複数のコレクションをインストールすることもできます。このファイルは、以下の形式の YAML ファイルです。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:16 -msgid "The supported keys for collection requirement entries are ``name``, ``version``, ``source``, and ``type``." -msgstr "コレクション要件エントリーでサポートされるキーは ``name``、``version``、``source``、および ``type`` です。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:18 -msgid "The ``version`` key can take in the same range identifier format documented above. If you're installing a collection from a git repository instead of a built collection artifact, the ``version`` key refers to a `git commit-ish `_." -msgstr "``version`` キーは、上記の範囲識別子の形式を取ることができます。ビルドコレクションアーティファクトではなく git リポジトリーからコレクションをインストールする場合は、``version`` キーは `git commit-ish `_ を参照します。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:20 -msgid "The ``type`` key can be set to ``galaxy``, ``url``, ``file``, and ``git``. If ``type`` is omitted, the ``name`` key is used to implicitly determine the source of the collection." -msgstr "``type`` キーは ``galaxy``、``url``、``file``、および ``git`` に設定できます。``type`` を省略すると、``name`` キーを使用してコレクションのソースを暗黙的に決定します。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:22 -msgid "Roles can also be specified and placed under the ``roles`` key. The values follow the same format as a requirements file used in older Ansible releases." -msgstr "ロールは、``roles`` キーの下に指定して配置することもできます。この値は、古い Ansible リリースで使用される要件ファイルと同じ形式に従います。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:39 -msgid "To install both roles and collections at the same time with one command, run the following:" -msgstr "1 つのコマンドで、ロールとコレクションを同時にインストールするには、以下のコマンドを実行します。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:45 -msgid "Running ``ansible-galaxy collection install -r`` or ``ansible-galaxy role install -r`` will only install collections, or roles respectively." -msgstr "``ansible-galaxy collection install -r`` または ``ansible-galaxy role install -r`` を実行すると、それぞれコレクションまたはロールがインストールされます。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:49 -msgid "Installing both roles and collections from the same requirements file will not work when specifying a custom collection or role install path. In this scenario the collections will be skipped and the command will process each like ``ansible-galaxy role install`` would." -msgstr "カスタムコレクションまたはロールインストールパスを指定する場合は、同じ要件ファイルからロールとコレクションの両方をインストールすることはできません。今回の例では、コレクションは省略され、コマンドは ``ansible-galaxy role install`` のように処理されます。" - -#: ../../rst/galaxy/user_guide.rst:82 -msgid "Downloading a collection for offline use" -msgstr "オフラインで使用するコレクションのダウンロード" - -#: ../../rst/shared_snippets/download_tarball_collections.txt:3 -msgid "To download the collection tarball from Galaxy for offline use:" -msgstr "オフラインで使用するために、コレクション tarball を Galaxy からダウンロードするには、以下を行います。" - -#: ../../rst/shared_snippets/download_tarball_collections.txt:5 -msgid "Navigate to the collection page." -msgstr "コレクションページに移動します。" - -#: ../../rst/shared_snippets/download_tarball_collections.txt:6 -msgid "Click on :guilabel:`Download tarball`." -msgstr ":guilabel:`Download tarball` をクリックします。" - -#: ../../rst/shared_snippets/download_tarball_collections.txt:8 -msgid "You may also need to manually download any dependent collections." -msgstr "また、依存するコレクションを手動でダウンロードする必要がある場合があります。" - -#: ../../rst/galaxy/user_guide.rst:87 -msgid "Installing a collection from a git repository" -msgstr "git リポジトリーからのコレクションのインストール" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:1 -msgid "You can install a collection in a git repository by providing the URI to the repository instead of a collection name or path to a ``tar.gz`` file. The collection must contain a ``galaxy.yml`` or ``MANIFEST.json`` file, which will be used to generate the would-be collection artifact data from the directory. The URI should be prefixed with ``git+`` (or with ``git@`` to use a private repository with ssh authentication) and optionally supports a comma-separated `git commit-ish `_ version (for example, a commit or tag)." -msgstr "コレクション名または ``tar.gz`` ファイルへのパスではなく、リポジトリーに URI を提供することにより、git リポジトリーにコレクションをインストールできます。コレクションには、``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルが必要です。このコレクションは、ディレクトリーからの will-be コレクションアーティファクトデータを生成するのに使用されます。URI の接頭辞には ``git+`` (または ssh 認証でプライベートリポジトリーを使用する ``git@``）を付け、必要に応じてコンマ区切りの `git commit-ish `_ バージョン (コミットまたはタグなど) をサポートする必要があります。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:5 -msgid "Embedding credentials into a git URI is not secure. Make sure to use safe auth options for security reasons. For example, use `SSH `_, `netrc `_ or `http.extraHeader `_/`url..pushInsteadOf `_ in Git config to prevent your creds from being exposed in logs." -msgstr "認証情報を git URI に埋め込むことは安全ではありません。セキュリティー上の理由から、安全な認証オプションを使用してください。たとえば、Git 設定の `SSH `_、`netrc `_、または `http.extraHeader `_/`url..pushInsteadOf `_ で、クレジットがログに公開されないようにします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:18 -msgid "In a ``requirements.yml`` file, you can also use the ``type`` and ``version`` keys in addition to using the ``git+repo,version`` syntax for the collection name." -msgstr "``requirements.yml`` ファイルでは、コレクション名の ``git+repo,version`` 構文を使用する他に、``type`` キーおよび ``version`` キーを使用することもできます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:27 -msgid "Git repositories can be used for collection dependencies as well. This can be helpful for local development and testing but built/published artifacts should only have dependencies on other artifacts." -msgstr "git リポジトリーはコレクションの依存関係にも使用できます。これは、ローカル開発およびテストに役立ちますが、ビルド/公開されたアーティファクトには他のアーティファクトへの依存関係のみが必要です。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:34 -msgid "Default repository search locations" -msgstr "デフォルトのリポジトリー検索の場所" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:36 -msgid "There are two paths searched in a repository for collections by default." -msgstr "デフォルトでは、コレクション用のリポジトリーで 2 つのパスが検索されます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:38 -msgid "The first is the ``galaxy.yml`` or ``MANIFEST.json`` file in the top level of the repository path. If the file exists it's used as the collection metadata and the individual collection will be installed." -msgstr "1 つ目は、リポジトリーパスの最上位にある ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ファイルが存在する場合は、コレクションのメタデータとして使用され、個々のコレクションがインストールされます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:49 -msgid "The second is a ``galaxy.yml`` or ``MANIFEST.json`` file in each directory in the repository path (one level deep). In this scenario, each directory with a metadata file is installed as a collection." -msgstr "2 つ目は、リポジトリーパス (1 レベルの深さ) の各ディレクトリーの ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ここでは、メタデータファイルが含まれる各ディレクトリーがコレクションとしてインストールされます)。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:62 -msgid "Specifying the location to search for collections" -msgstr "コレクションを検索する場所の指定" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:64 -msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate which path ansible-galaxy should inspect for metadata file(s). The path should be a directory to a collection or multiple collections (rather than the path to a ``galaxy.yml`` file or ``MANIFEST.json`` file)." -msgstr "異なるリポジトリー構造がある場合や、コレクションのサブセットのみをインストールする場合は、URI の最後にフラグメントを追加して (任意のコンマ区切りバージョンの前）、ansible-galaxy がメタデータファイルを調べるパスを示すことができます。パスは、(``MANIFEST.json`` ファイルまたは ``galaxy.yml`` ファイルへのパスではなく) コレクションまたは複数のコレクションへのディレクトリーである必要があります。" - -#: ../../rst/galaxy/user_guide.rst:92 -msgid "Listing installed collections" -msgstr "インストール済みコレクションの一覧表示" - -#: ../../rst/galaxy/user_guide.rst:94 -msgid "To list installed collections, run ``ansible-galaxy collection list``. See :ref:`collections_listing` for more details." -msgstr "インストール済みのコレクションを一覧表示するには、``ansible-galaxy collection list`` を実行します。詳細は、「:ref:`collections_listing`」を参照してください。" - -#: ../../rst/galaxy/user_guide.rst:98 -msgid "Configuring the ``ansible-galaxy`` client" -msgstr "``ansible-galaxy`` クライアントの設定" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:3 -msgid "By default, ``ansible-galaxy`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`)." -msgstr "デフォルトでは、``ansible-galaxy`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の :file:`ansible.cfg` ファイルに記載）。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:5 -msgid "You can use either option below to configure ``ansible-galaxy collection`` to use other servers (such as Red Hat Automation Hub or a custom Galaxy server):" -msgstr "以下のオプションを使用して、他のサーバー (Red Hat Automation Hub、カスタムの Galaxy サーバーなど) を使用するように ``ansible-galaxy collection`` を設定できます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:7 -msgid "Set the server list in the :ref:`galaxy_server_list` configuration option in :ref:`ansible_configuration_settings_locations`." -msgstr "「:ref:`ansible_configuration_settings_locations`」の「:ref:`galaxy_server_list`」設定オプションにサーバーリストを設定します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:8 -msgid "Use the ``--server`` command line argument to limit to an individual server." -msgstr "``--server`` コマンドライン引数を使用して、個々のサーバーに制限します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:10 -msgid "To configure a Galaxy server list in ``ansible.cfg``:" -msgstr "``ansible.cfg`` で Galaxy サーバー一覧を設定するには、以下を行います。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:13 -msgid "Add the ``server_list`` option under the ``[galaxy]`` section to one or more server names." -msgstr "``server_list`` セクションの ``[galaxy]`` オプションを 1 つ以上のサーバー名に追加します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:14 -msgid "Create a new section for each server name." -msgstr "各サーバー名に新しいセクションを作成します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:15 -msgid "Set the ``url`` option for each server name." -msgstr "各サーバー名に ``url`` オプションを設定します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:16 -msgid "Optionally, set the API token for each server name. Go to https://galaxy.ansible.com/me/preferences and click :guilabel:`Show API key`." -msgstr "必要に応じて、各サーバー名の API トークンを設定します。https://galaxy.ansible.com/me/preferences に移動し、guilabel:`Show API key` をクリックします。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:19 -msgid "The ``url`` option for each server name must end with a forward slash ``/``. If you do not set the API token in your Galaxy server list, use the ``--api-key`` argument to pass in the token to the ``ansible-galaxy collection publish`` command." -msgstr "各サーバー名の ``url`` オプションは、スラッシュ ``/`` で終了する必要があります。Galaxy サーバー一覧の API トークンを設定しない場合は、``--api-key`` 引数を使用してトークンを ``ansible-galaxy collection publish`` コマンドに渡します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:21 -msgid "For Automation Hub, you additionally need to:" -msgstr "Automation Hub の場合には、さらに以下の操作が必要です。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:23 -msgid "Set the ``auth_url`` option for each server name." -msgstr "各サーバー名に ``auth_url`` オプションを設定します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:24 -msgid "Set the API token for each server name. Go to https://cloud.redhat.com/ansible/automation-hub/token/ and click ::guilabel:`Get API token` from the version dropdown to copy your API token." -msgstr "各サーバー名の API トークンを設定します。https://cloud.redhat.com/ansible/automation-hub/token/ に、バージョンドロップダウンリストから ::guilabel:`Get API token` をクリックして API トークンをコピーします。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:26 -msgid "The following example shows how to configure multiple servers:" -msgstr "以下の例は、複数のサーバーを設定する方法を示しています。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:52 -msgid "You can use the ``--server`` command line argument to select an explicit Galaxy server in the ``server_list`` and the value of this argument should match the name of the server. To use a server not in the server list, set the value to the URL to access that server (all servers in the server list will be ignored). Also you cannot use the ``--api-key`` argument for any of the predefined servers. You can only use the ``api_key`` argument if you did not define a server list or if you specify a URL in the ``--server`` argument." -msgstr "``--server`` コマンドライン引数を使用して ``server_list`` で明示的な Galaxy サーバーを選択し、この引数の値はサーバー名と一致する必要があります。サーバー一覧にないサーバーを使用する場合は、そのサーバーにアクセスする URL に値を設定します (サーバーリスト内のすべてのサーバーは無視されます)。また、事前定義されたサーバーのいずれかに ``--api-key`` 引数を使用することはできません。サーバーの一覧を定義していない場合、または ``--server`` に URL を指定した場合限り、``api_key`` 引数を使用できます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:56 -msgid "**Galaxy server list configuration options**" -msgstr "**Galaxy サーバー一覧設定オプション**" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:58 -msgid "The :ref:`galaxy_server_list` option is a list of server identifiers in a prioritized order. When searching for a collection, the install process will search in that order, for example, ``automation_hub`` first, then ``my_org_hub``, ``release_galaxy``, and finally ``test_galaxy`` until the collection is found. The actual Galaxy instance is then defined under the section ``[galaxy_server.{{ id }}]`` where ``{{ id }}`` is the server identifier defined in the list. This section can then define the following keys:" -msgstr ":ref:`galaxy_server_list` オプションは、優先順位が付けられたサーバー識別子の一覧です。コレクションを検索する場合、インストールプロセスは次の順序で検索します。たとえば、``automation_hub`` を検索してから、``my_org_hub``、``release_galaxy``、最後に ``test_galaxy`` で、コレクションが見つかるまで行います。次に、実際の Galaxy インスタンスが ``[galaxy_server.{{ id }}]`` セクションで定義され。ここでは、``{{ id }}`` は、一覧で定義されているサーバー識別子です。このセクションでは、次のキーを定義できます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:64 -msgid "``url``: The URL of the Galaxy instance to connect to. Required." -msgstr "``url``: 接続する Galaxy インスタンスの URL。必須。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:65 -msgid "``token``: An API token key to use for authentication against the Galaxy instance. Mutually exclusive with ``username``." -msgstr "``token``: Galaxy インスタンスに対する認証に使用する API トークンキー。``username`` と相互に排他的です。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:66 -msgid "``username``: The username to use for basic authentication against the Galaxy instance. Mutually exclusive with ``token``." -msgstr "``username``: Galaxy インスタンスに対する Basic 認証に使用するユーザー名。``token`` と相互に排他的です。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:67 -msgid "``password``: The password to use, in conjunction with ``username``, for basic authentication." -msgstr "``password``: Basic 認証に使用するパスワード。``username`` と併用します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:68 -msgid "``auth_url``: The URL of a Keycloak server 'token_endpoint' if using SSO authentication (for example, Automation Hub). Mutually exclusive with ``username``. Requires ``token``." -msgstr "``auth_url``: SSO 認証 (例: Automation Hub) を使用する場合は Keycloak サーバー「token_endpoint」の URL です。``username`` と相互に排他的です。``token`` が必要です。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:70 -msgid "As well as defining these server options in the ``ansible.cfg`` file, you can also define them as environment variables. The environment variable is in the form ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` where ``{{ id }}`` is the upper case form of the server identifier and ``{{ key }}`` is the key to define. For example I can define ``token`` for ``release_galaxy`` by setting ``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token``." -msgstr "これらのサーバーオプションを ``ansible.cfg`` ファイルで定義するだけでなく、それらを環境変数として定義することもできます。環境変数は ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` の形式です。``{{ id }}`` はサーバー識別子の大文字形式であり、``{{ key }}`` は定義するキーです。たとえば、``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token`` を設定することで、``release_galaxy`` に ``token`` を定義することができます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:75 -msgid "For operations that use only one Galaxy server (for example, the ``publish``, ``info``, or ``install`` commands). the ``ansible-galaxy collection`` command uses the first entry in the ``server_list``, unless you pass in an explicit server with the ``--server`` argument." -msgstr "Galaxy サーバー 1 つだけを使用する操作 (例: ``publish`` コマンド、``info`` コマンド、または ``install`` コマンド) の場合、``ansible-galaxy collection`` コマンドは、``--server`` 引数を使用して明示的なサーバーに渡しない限り、``server_list`` の最初のエントリーを使用します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:79 -msgid "Once a collection is found, any of its requirements are only searched within the same Galaxy instance as the parent collection. The install process will not search for a collection requirement in a different Galaxy instance." -msgstr "コレクションが見つかると、その要件は親コレクションと同じ Galaxy インスタンス内でのみ検索されます。インストールプロセスでは、別の Galaxy インスタンスでコレクション要件を検索しません。" - -#: ../../rst/galaxy/user_guide.rst:105 -msgid "Finding roles on Galaxy" -msgstr "Galaxy でのロールの検索" - -#: ../../rst/galaxy/user_guide.rst:107 -msgid "Search the Galaxy database by tags, platforms, author and multiple keywords. For example:" -msgstr "Galaxy データベースは、タグ、プラットフォーム、作成者、および複数のキーワードで検索します。以下は例になります。" - -#: ../../rst/galaxy/user_guide.rst:113 -msgid "The search command will return a list of the first 1000 results matching your search:" -msgstr "search コマンドは、検索に一致する最初の 1000 個の結果を一覧で返します。" - -#: ../../rst/galaxy/user_guide.rst:126 -msgid "Get more information about a role" -msgstr "ロールに関する詳細情報の取得" - -#: ../../rst/galaxy/user_guide.rst:128 -msgid "Use the ``info`` command to view more detail about a specific role:" -msgstr "``info`` コマンドを使用して、特定のロールに関する詳細を表示します。" - -#: ../../rst/galaxy/user_guide.rst:134 -msgid "This returns everything found in Galaxy for the role:" -msgstr "これは、ロールの Galaxy にあるすべてのものを返します。" - -#: ../../rst/galaxy/user_guide.rst:171 -msgid "Installing roles from Galaxy" -msgstr "Galaxy からのロールのインストール" - -#: ../../rst/galaxy/user_guide.rst:173 -msgid "The ``ansible-galaxy`` command comes bundled with Ansible, and you can use it to install roles from Galaxy or directly from a git based SCM. You can also use it to create a new role, remove roles, or perform tasks on the Galaxy website." -msgstr "``ansible-galaxy`` コマンドは Ansible とバンドルされ、Galaxy から、または git ベースの SCM から直接ロールをインストールするために使用できます。また、新しいロールの作成、ロールの削除、または Galaxy の Web サイトでタスクを実行することもできます。" - -#: ../../rst/galaxy/user_guide.rst:176 -msgid "The command line tool by default communicates with the Galaxy website API using the server address *https://galaxy.ansible.com*. If you run your own internal Galaxy server and want to use it instead of the default one, pass the ``--server`` option following the address of this galaxy server. You can set permanently this option by setting the Galaxy server value in your ``ansible.cfg`` file to use it . For information on setting the value in *ansible.cfg* see :ref:`galaxy_server`." -msgstr "コマンドラインツールは、デフォルトでサーバーアドレス *https://galaxy.ansible.com* を使用して Galaxy Web サイト API と通信します。独自の内部 Galaxy サーバーを実行していて、デフォルトのサーバーの代わりにそれを使用したい場合は、この galaxy サーバーのアドレスの後に ``--server`` オプションを渡します。``ansible.cfg`` ファイルに Galaxy サーバーの値を設定することにより、このオプションを永続的に設定できます。*ansible.cfg* での値の設定については、「:ref:`galaxy_server`」を参照してください。" - -#: ../../rst/galaxy/user_guide.rst:182 -msgid "Installing roles" -msgstr "ロールのインストール" - -#: ../../rst/galaxy/user_guide.rst:184 -msgid "Use the ``ansible-galaxy`` command to download roles from the `Galaxy website `_" -msgstr "``ansible-galaxy`` コマンドを使用して、`Galaxy website `_ からロールをダウンロードします。" - -#: ../../rst/galaxy/user_guide.rst:191 -msgid "Setting where to install roles" -msgstr "ロールをインストールする場所の設定" - -#: ../../rst/galaxy/user_guide.rst:193 -msgid "By default, Ansible downloads roles to the first writable directory in the default list of paths ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles``. This installs roles in the home directory of the user running ``ansible-galaxy``." -msgstr "デフォルトでは、Ansible はパスのデフォルトリスト ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles`` にある最初に書き込み可能なディレクトリーにロールをダウンロードします。これは、``ansible-galaxy`` を実行するユーザーのホームディレクトリーにロールをインストールします。" - -#: ../../rst/galaxy/user_guide.rst:195 -msgid "You can override this with one of the following options:" -msgstr "これは、以下のオプションのいずれかで上書きできます。" - -#: ../../rst/galaxy/user_guide.rst:197 -msgid "Set the environment variable :envvar:`ANSIBLE_ROLES_PATH` in your session." -msgstr "セッションで環境変数 :envvar:`ANSIBLE_ROLES_PATH` を設定します。" - -#: ../../rst/galaxy/user_guide.rst:198 -msgid "Use the ``--roles-path`` option for the ``ansible-galaxy`` command." -msgstr "``--roles-path`` コマンドに ``ansible-galaxy`` オプションを使用します。" - -#: ../../rst/galaxy/user_guide.rst:199 -msgid "Define ``roles_path`` in an ``ansible.cfg`` file." -msgstr "``ansible.cfg`` ファイルで ``roles_path`` を定義します。" - -#: ../../rst/galaxy/user_guide.rst:201 -msgid "The following provides an example of using ``--roles-path`` to install the role into the current working directory:" -msgstr "以下は、``--roles-path`` を使用して現在の作業ディレクトリーにロールをインストールする例を示しています。" - -#: ../../rst/galaxy/user_guide.rst:209 -msgid ":ref:`intro_configuration`" -msgstr ":ref:`intro_configuration`" - -#: ../../rst/galaxy/user_guide.rst:210 -msgid "All about configuration files" -msgstr "設定ファイルに関するすべて" - -#: ../../rst/galaxy/user_guide.rst:213 -msgid "Installing a specific version of a role" -msgstr "ロールの特定バージョンのインストール" - -#: ../../rst/galaxy/user_guide.rst:215 -msgid "When the Galaxy server imports a role, it imports any git tags matching the `Semantic Version `_ format as versions. In turn, you can download a specific version of a role by specifying one of the imported tags." -msgstr "Galaxy サーバーがロールをインポートすると、`Semantic Version `_ 形式に一致する git タグがバージョンとしてインポートされます。次に、インポートされたタグのいずれかを指定して、ロールの特定バージョンをダウンロードできます。" - -#: ../../rst/galaxy/user_guide.rst:218 -msgid "To see the available versions for a role:" -msgstr "ロールで利用可能なバージョンを表示するには、以下を行います。" - -#: ../../rst/galaxy/user_guide.rst:220 -msgid "Locate the role on the Galaxy search page." -msgstr "Galaxy 検索ページでロールを見つけます。" - -#: ../../rst/galaxy/user_guide.rst:221 -msgid "Click on the name to view more details, including the available versions." -msgstr "利用可能なバージョンなど、名前をクリックして詳細情報を表示します。" - -#: ../../rst/galaxy/user_guide.rst:223 -msgid "You can also navigate directly to the role using the //. For example, to view the role geerlingguy.apache, go to ``_." -msgstr "// を使用してロールに直接移動することもできます。たとえば、geerlingguy.apache ロールを表示するには、``_ に移動します。" - -#: ../../rst/galaxy/user_guide.rst:225 -msgid "To install a specific version of a role from Galaxy, append a comma and the value of a GitHub release tag. For example:" -msgstr "Galaxy から特定のバージョンのロールをインストールするには、コンマと GitHub リリースタグの値を追加します。以下に例を示します。" - -#: ../../rst/galaxy/user_guide.rst:231 -msgid "It is also possible to point directly to the git repository and specify a branch name or commit hash as the version. For example, the following will install a specific commit:" -msgstr "git リポジトリーを直接参照して、バージョンとしてブランチ名またはコミットハッシュを指定することもできます。たとえば、以下は特定のコミットをインストールします。" - -#: ../../rst/galaxy/user_guide.rst:239 -msgid "Installing multiple roles from a file" -msgstr "ファイルからの複数ロールのインストール" - -#: ../../rst/galaxy/user_guide.rst:241 -msgid "You can install multiple roles by including the roles in a :file:`requirements.yml` file. The format of the file is YAML, and the file extension must be either *.yml* or *.yaml*." -msgstr ":file:`requirements.yml` ファイルにロールを追加して、複数のロールをインストールできます。ファイルのフォーマットは YAML で、ファイル拡張子は *.yml* または *.yaml* のいずれかでなければなりません。" - -#: ../../rst/galaxy/user_guide.rst:244 -msgid "Use the following command to install roles included in :file:`requirements.yml:`" -msgstr "以下のコマンドを使用して、:file:`requirements.yml:` に含まれるロールをインストールします。" - -#: ../../rst/galaxy/user_guide.rst:250 -msgid "Again, the extension is important. If the *.yml* extension is left off, the ``ansible-galaxy`` CLI assumes the file is in an older, now deprecated, \"basic\" format." -msgstr "拡張子は重要です。*.yml* 拡張子がオフのままの場合、``ansible-galaxy`` CLI は、ファイルが古いものと見なし、「basic」フォーマットが非推奨であると想定します。" - -#: ../../rst/galaxy/user_guide.rst:253 -msgid "Each role in the file will have one or more of the following attributes:" -msgstr "このファイルの各ロールには、以下の属性が 1 つ以上あります。" - -#: ../../rst/galaxy/user_guide.rst:256 -msgid "src" -msgstr "src" - -#: ../../rst/galaxy/user_guide.rst:256 -msgid "The source of the role. Use the format *namespace.role_name*, if downloading from Galaxy; otherwise, provide a URL pointing to a repository within a git based SCM. See the examples below. This is a required attribute." -msgstr "ロールのソース。Galaxy からダウンロードする場合は、*namespace.role_name* の形式を使用します。それ以外の場合は、git ベースの SCM 内のリポジトリーを参照する URL を提供します。以下を参照してください。これは必須属性です。" - -#: ../../rst/galaxy/user_guide.rst:258 -msgid "scm" -msgstr "scm" - -#: ../../rst/galaxy/user_guide.rst:259 -msgid "Specify the SCM. As of this writing only *git* or *hg* are allowed. See the examples below. Defaults to *git*." -msgstr "SCM を指定します。本書の作成時点では、*git* または *hg* への書き込みのみが許可されます。以下の例を参照してください。デフォルトは *git* です。" - -#: ../../rst/galaxy/user_guide.rst:260 -msgid "version:" -msgstr "version:" - -#: ../../rst/galaxy/user_guide.rst:261 -msgid "The version of the role to download. Provide a release tag value, commit hash, or branch name. Defaults to the branch set as a default in the repository, otherwise defaults to the *master*." -msgstr "ダウンロードするロールのバージョン。リリースタグの値、コミットハッシュ、またはブランチ名を指定します。デフォルトではリポジトリーのデフォルトとして設定されたブランチに設定されます。それ以外の場合は、デフォルトで *master* に設定されます。" - -#: ../../rst/galaxy/user_guide.rst:264 -msgid "name:" -msgstr "name:" - -#: ../../rst/galaxy/user_guide.rst:263 -msgid "Download the role to a specific name. Defaults to the Galaxy name when downloading from Galaxy, otherwise it defaults to the name of the repository." -msgstr "ロールを特定の名前にダウンロードします。デフォルトでは Galaxy からダウンロードするときに Galaxy 名に設定されます。指定しない場合は、リポジトリーの名前に設定されます。" - -#: ../../rst/galaxy/user_guide.rst:266 -msgid "Use the following example as a guide for specifying roles in *requirements.yml*:" -msgstr "以下の例を、*requirements.yml* でロールを指定するためのガイドとして使用してください。" - -#: ../../rst/galaxy/user_guide.rst:315 -msgid "Embedding credentials into a SCM URL is not secure. Make sure to use safe auth options for security reasons. For example, use `SSH `_, `netrc `_ or `http.extraHeader `_/`url..pushInsteadOf `_ in Git config to prevent your creds from being exposed in logs." -msgstr "認証情報を SCM URL に埋め込むことは安全ではありません。セキュリティー上の理由から、安全な認証オプションを使用してください。たとえば、Git 設定の `SSH `_、`netrc `_、または `http.extraHeader `_/`url..pushInsteadOf `_ で、クレジットがログに公開されないようにします。" - -#: ../../rst/galaxy/user_guide.rst:318 -msgid "Installing roles and collections from the same requirements.yml file" -msgstr "同じ requirements.yml ファイルからのロールおよびコレクションのインストール" - -#: ../../rst/galaxy/user_guide.rst:320 -msgid "You can install roles and collections from the same requirements files" -msgstr "同じ要件ファイルからロールおよびコレクションをインストールできます。" - -#: ../../rst/galaxy/user_guide.rst:337 -msgid "Installing multiple roles from multiple files" -msgstr "複数のファイルからの複数ロールのインストール" - -#: ../../rst/galaxy/user_guide.rst:339 -msgid "For large projects, the ``include`` directive in a :file:`requirements.yml` file provides the ability to split a large file into multiple smaller files." -msgstr "大規模なプロジェクトの場合、:file:`requirements.yml` ファイルの ``include`` ディレクティブにより、大きなファイルを複数の小さなファイルに分割することができます。" - -#: ../../rst/galaxy/user_guide.rst:341 -msgid "For example, a project may have a :file:`requirements.yml` file, and a :file:`webserver.yml` file." -msgstr "たとえば、プロジェクトには :file:`requirements.yml` ファイルと :file:`webserver.yml` ファイルが含まれる場合があります。" - -#: ../../rst/galaxy/user_guide.rst:343 -msgid "Below are the contents of the :file:`webserver.yml` file:" -msgstr ":file:`webserver.yml` ファイルの内容を以下に示します。" - -#: ../../rst/galaxy/user_guide.rst:354 -msgid "The following shows the contents of the :file:`requirements.yml` file that now includes the :file:`webserver.yml` file:" -msgstr ":file:`requirements.yml` ファイルが含まれる :file:`webserver.yml` ファイルの内容を以下に示します。" - -#: ../../rst/galaxy/user_guide.rst:362 -msgid "To install all the roles from both files, pass the root file, in this case :file:`requirements.yml` on the command line, as follows:" -msgstr "両方のファイルからすべてのロールをインストールするには、以下のように root ファイルを渡します。この例では、以下のように、コマンドラインで :file:`requirements.yml` を指定します。" - -#: ../../rst/galaxy/user_guide.rst:372 -msgid "Dependencies" -msgstr "依存関係" - -#: ../../rst/galaxy/user_guide.rst:374 -msgid "Roles can also be dependent on other roles, and when you install a role that has dependencies, those dependencies will automatically be installed to the ``roles_path``." -msgstr "また、ロールは他のロールに依存し、依存関係のあるロールをインストールすると、それらの依存関係が自動的に ``roles_path`` にインストールされます。" - -#: ../../rst/galaxy/user_guide.rst:376 -msgid "There are two ways to define the dependencies of a role:" -msgstr "ロールの依存関係を定義する方法は 2 つあります。" - -#: ../../rst/galaxy/user_guide.rst:378 -msgid "using ``meta/requirements.yml``" -msgstr "``meta/requirements.yml`` の使用" - -#: ../../rst/galaxy/user_guide.rst:379 -msgid "using ``meta/main.yml``" -msgstr "``meta/main.yml`` の使用" - -#: ../../rst/galaxy/user_guide.rst:382 -msgid "Using ``meta/requirements.yml``" -msgstr "``meta/requirements.yml`` の使用" - -#: ../../rst/galaxy/user_guide.rst:386 -msgid "You can create the file ``meta/requirements.yml`` and define dependencies in the same format used for :file:`requirements.yml` described in the `Installing multiple roles from a file`_ section." -msgstr "``meta/requirements.yml`` ファイルを作成し、「`ファイルから複数のロールのインストール`_」セクションで説明されている :file:`requirements.yml` に使用されるのと同じ形式で依存関係を定義できます。" - -#: ../../rst/galaxy/user_guide.rst:388 -msgid "From there, you can import or include the specified roles in your tasks." -msgstr "そこから、指定のロールをタスクにインポートしたり、追加できます。" - -#: ../../rst/galaxy/user_guide.rst:391 -msgid "Using ``meta/main.yml``" -msgstr "``meta/main.yml`` の使用" - -#: ../../rst/galaxy/user_guide.rst:393 -msgid "Alternatively, you can specify role dependencies in the ``meta/main.yml`` file by providing a list of roles under the ``dependencies`` section. If the source of a role is Galaxy, you can simply specify the role in the format ``namespace.role_name``. You can also use the more complex format in :file:`requirements.yml`, allowing you to provide ``src``, ``scm``, ``version``, and ``name``." -msgstr "または、``dependencies`` セクションの下にロールの一覧を指定して、``meta/main.yml`` ファイルにロールの依存関係を指定できます。ロールのソースが Galaxy の場合には、``namespace.role_name`` 形式でロールを指定するだけです。さらに複雑な形式を :file:`requirements.yml` で使用することもできます。``src``、``scm``、``version``、および ``name`` を指定することもできます。" - -#: ../../rst/galaxy/user_guide.rst:396 -msgid "Dependencies installed that way, depending on other factors described below, will also be executed **before** this role is executed during play execution. To better understand how dependencies are handled during play execution, see :ref:`playbooks_reuse_roles`." -msgstr "そのようにインストールされた依存関係は、以下で説明する他の要因に応じて、プレイの実行中にこのロールが実行される **前** にも実行されます。再生の実行中に依存関係がどのように処理されるかをよりよく理解するには、「:ref:`playbooks_reuse_roles`」を参照してください。" - -#: ../../rst/galaxy/user_guide.rst:399 -msgid "The following shows an example ``meta/main.yml`` file with dependent roles:" -msgstr "依存するロールが指定された ``meta/main.yml`` ファイルの例を以下に示します。" - -#: ../../rst/galaxy/user_guide.rst:432 -msgid "Tags are inherited *down* the dependency chain. In order for tags to be applied to a role and all its dependencies, the tag should be applied to the role, not to all the tasks within a role." -msgstr "タグは、依存関係チェーン *下* に継承されます。タグをロールに適用してすべての依存関係に適用するには、タグをロール内の全タスクに適用するのではなく、ロールに適用する必要があります。" - -#: ../../rst/galaxy/user_guide.rst:434 -msgid "Roles listed as dependencies are subject to conditionals and tag filtering, and may not execute fully depending on what tags and conditionals are applied." -msgstr "依存関係として一覧表示されているロールは、条件とタグフィルタリングの対象であり、適用されるタグと条件によっては完全に実行されない場合があります。" - -#: ../../rst/galaxy/user_guide.rst:437 -msgid "If the source of a role is Galaxy, specify the role in the format *namespace.role_name*:" -msgstr "ロールのソースが Galaxy の場合は、ロールを *namespace.role_name* 形式で指定します。" - -#: ../../rst/galaxy/user_guide.rst:446 -msgid "Alternately, you can specify the role dependencies in the complex form used in :file:`requirements.yml` as follows:" -msgstr "または、以下のように :file:`requirements.yml` で使用される複雑な形式でロールの依存関係を指定することもできます。" - -#: ../../rst/galaxy/user_guide.rst:458 -msgid "Galaxy expects all role dependencies to exist in Galaxy, and therefore dependencies to be specified in the ``namespace.role_name`` format. If you import a role with a dependency where the ``src`` value is a URL, the import process will fail." -msgstr "Galaxy では、すべてのロールの依存関係が Galaxy に存在することが想定されるため、``namespace.role_name`` 形式で依存関係を指定します。``src`` の値が URL である依存関係でロールをインポートすると、インポートプロセスは失敗します。" - -#: ../../rst/galaxy/user_guide.rst:462 -msgid "List installed roles" -msgstr "インストール済みロールの一覧表示" - -#: ../../rst/galaxy/user_guide.rst:464 -msgid "Use ``list`` to show the name and version of each role installed in the *roles_path*." -msgstr "``list`` を使用して、*roles_path* にインストールされている各ロールの名前およびバージョンを表示します。" - -#: ../../rst/galaxy/user_guide.rst:476 -msgid "Remove an installed role" -msgstr "インストールされたロールの削除" - -#: ../../rst/galaxy/user_guide.rst:478 -msgid "Use ``remove`` to delete a role from *roles_path*:" -msgstr "``remove`` を使用して、*roles_path* からロールを削除します。" - -#: ../../rst/galaxy/user_guide.rst:489 -msgid "Reusable tasks, handlers, and other files in a known directory structure" -msgstr "既知のディレクトリー構造の再利用可能なタスク、ハンドラー、およびその他のファイル" - -#~ msgid "You can install a collection in a git repository by providing the URI to the repository instead of a collection name or path to a ``tar.gz`` file. The collection must contain a ``galaxy.yml`` file, which will be used to generate the would-be collection artifact data from the directory. The URI should be prefixed with ``git+`` (or with ``git@`` to use a private repository with ssh authentication) and optionally supports a comma-separated `git commit-ish `_ version (for example, a commit or tag)." -#~ msgstr "" - -#~ msgid "The first is the ``galaxy.yml`` file in the top level of the repository path. If the ``galaxy.yml`` file exists it's used as the collection metadata and the individual collection will be installed." -#~ msgstr "" - -#~ msgid "The second is a ``galaxy.yml`` file in each directory in the repository path (one level deep). In this scenario, each directory with a ``galaxy.yml`` is installed as a collection." -#~ msgstr "" - -#~ msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate which path ansible-galaxy should inspect for ``galaxy.yml`` file(s). The path should be a directory to a collection or multiple collections (rather than the path to a ``galaxy.yml`` file)." -#~ msgstr "" - -#~ msgid "You can install roles and collections from the same requirements files, with some caveats." -#~ msgstr "" - -#~ msgid "While both roles and collections can be specified in one requirements file, they need to be installed separately. The ``ansible-galaxy role install -r requirements.yml`` will only install roles and ``ansible-galaxy collection install -r requirements.yml -p ./`` will only install collections." -#~ msgstr "" - -#~ msgid "`.. versionadded:: 2.10`" -#~ msgstr "" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/index.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/index.po deleted file mode 100644 index a7805d82aa8..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/index.po +++ /dev/null @@ -1,124 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-03-08 20:25+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/2.10_index.rst:23 ../../rst/ansible_index.rst:25 -#: ../../rst/core_index.rst:30 -msgid "Installation, Upgrade & Configuration" -msgstr "インストール、アップグレード、および設定" - -#: ../../rst/core_index.rst:37 -msgid "Using Ansible Core" -msgstr "Ansible Core の使用" - -#: ../../rst/core_index.rst:43 -msgid "Contributing to Ansible Core" -msgstr "Ansible Core への貢献" - -#: ../../rst/2.10_index.rst:42 ../../rst/ansible_index.rst:44 -#: ../../rst/core_index.rst:49 -msgid "Extending Ansible" -msgstr "Ansible の拡張" - -#: ../../rst/2.10_index.rst:73 ../../rst/ansible_index.rst:75 -#: ../../rst/core_index.rst:56 -msgid "Reference & Appendices" -msgstr "参照および付録" - -#: ../../rst/2.10_index.rst:102 ../../rst/ansible_index.rst:100 -#: ../../rst/core_index.rst:80 -msgid "Roadmaps" -msgstr "ロードマップ" - -#: ../../rst/core_index.rst:8 -msgid "Ansible Core Documentation" -msgstr "Ansible Core ドキュメント" - -#: ../../rst/core_index.rst:11 -msgid "About ansible-core" -msgstr "ansible-core の概要" - -#: ../../rst/2.10_index.rst:9 ../../rst/ansible_index.rst:11 -#: ../../rst/core_index.rst:13 -msgid "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." -msgstr "Ansible は IT 自動化ツールです。このツールを使用すると、システムの構成、ソフトウェアの展開、より高度な IT タスク (継続的なデプロイメント、ダウンタイムなしのローリング更新など) のオーケストレーションが可能になります。" - -#: ../../rst/2.10_index.rst:11 ../../rst/ansible_index.rst:13 -#: ../../rst/core_index.rst:15 -msgid "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." -msgstr "Ansible の主な目標は、簡単で使いやすいことです。また、セキュリティーおよび信頼性に重点を置いており、最小限の可動部品、トランスポート用の OpenSSH の使用 (代替として他のトランスポートとプルモードを使用)、およびプログラムに精通していない人でも監査を可能にする言語も備えています。" - -#: ../../rst/2.10_index.rst:13 ../../rst/ansible_index.rst:15 -#: ../../rst/core_index.rst:17 -msgid "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." -msgstr "簡素化はあらゆる規模の環境に関連しており、開発者、システム管理者、リリースエンジニア、IT マネージャーなど、あらゆるタイプのビジーユーザー向けに設計されています。Ansible は、わずかなインスタンスしかない小規模のセットアップから、インスタンスが数千にもなるエンタープライズ環境まで、すべての環境を管理するのに適しています。" - -#: ../../rst/2.10_index.rst:15 ../../rst/ansible_index.rst:17 -#: ../../rst/core_index.rst:19 -msgid "You can learn more at `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." -msgstr "詳細は、`AnsibleFest `_ (Red Hat が開催する、Ansible のすべての貢献者、ユーザー、および顧客のための毎年恒例のイベント) で学ぶことができます。AnsibleFest は、他の人とつながり、新しいスキルを学び、自動化に興味のある人達と知り合うためのイベントです。" - -#: ../../rst/2.10_index.rst:17 ../../rst/ansible_index.rst:19 -#: ../../rst/core_index.rst:21 -msgid "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." -msgstr "Ansible は、エージェントを使用せずにマシンを管理します。リモートデーモンをアップグレードする方法や、デーモンがアンインストールされているためにシステムを管理できないという問題はありません。OpenSSH は、相互評価が最も行われるオープンソースコンポーネントの 1 つであるため、セキュリティーの危険性は大幅に軽減されます。Ansible は分散化されており、既存の OS 認証情報を使用して、リモートマシンへのアクセスを制御します。必要に応じて、Ansible は、Kerberos、LDAP、およびその他の集中認証管理システムに簡単に接続できます。" - -#: ../../rst/2.10_index.rst:19 ../../rst/ansible_index.rst:21 -#: ../../rst/core_index.rst:23 -msgid "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." -msgstr "本ドキュメントは、本ページの左上にある Ansible のバージョンを説明します。Red Hat は、複数のバージョンの Ansible とドキュメントを提供しているため、参照しているドキュメントが、お使いの Ansible のバージョンのものであることを確認してください。最新の機能については、この機能が追加された Ansible のバージョンを記載しています。" - -#: ../../rst/core_index.rst:26 -msgid "``ansible-core`` 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." -msgstr "``ansible-core`` は、年に約 2 回、新しいメジャーリリースをリリースします。コアアプリケーションは、言語の設計および設定の単純性が重視され、その進化は若干保守的となります。貢献者はバージョン 2.10 以降のコレクションでホストされるモジュールとプラグインを、はるかに迅速に開発および変更します。" - -#: ../../rst/2.10_index.rst:30 ../../rst/ansible_index.rst:32 -msgid "Using Ansible" -msgstr "Ansible の使用" - -#: ../../rst/2.10_index.rst:36 ../../rst/ansible_index.rst:38 -msgid "Contributing to Ansible" -msgstr "Ansible への貢献" - -#: ../../rst/2.10_index.rst:48 ../../rst/ansible_index.rst:50 -msgid "Common Ansible Scenarios" -msgstr "Ansible の一般的なシナリオ" - -#: ../../rst/2.10_index.rst:57 ../../rst/ansible_index.rst:59 -msgid "Network Automation" -msgstr "ネットワークの自動化" - -#: ../../rst/2.10_index.rst:65 ../../rst/ansible_index.rst:67 -msgid "Ansible Galaxy" -msgstr "Ansible Galaxy" - -#: ../../rst/2.10_index.rst:4 ../../rst/ansible_index.rst:6 -msgid "Ansible Documentation" -msgstr "Ansible ドキュメント" - -#: ../../rst/2.10_index.rst:7 ../../rst/ansible_index.rst:9 -msgid "About Ansible" -msgstr "Ansible の概要" - -#: ../../rst/2.10_index.rst:21 ../../rst/ansible_index.rst:23 -msgid "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." -msgstr "Ansible は、年に約 2 回、新しいメジャーリリースをリリースします。コアアプリケーションは、言語の設計および設定の単純性が重視され、その進化は若干保守的となります。貢献者はバージョン 2.10 以降のコレクションでホストされるモジュールとプラグインを、はるかに迅速に開発および変更します。" - -#: ../../rst/2.10_index.rst:98 -msgid "Release Notes" -msgstr "リリースノート" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/installation_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/installation_guide.po deleted file mode 100644 index 7ce1e66c459..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/installation_guide.po +++ /dev/null @@ -1,656 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-02-23 10:50+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/installation_guide/index.rst:3 -msgid "Installation Guide" -msgstr "インストールガイド" - -#: ../../rst/installation_guide/index.rst:5 -msgid "Welcome to the Ansible Installation Guide!" -msgstr "本ガイドは Ansible インストールガイドです。" - -#: ../../rst/installation_guide/intro_configuration.rst:5 -msgid "Configuring Ansible" -msgstr "Ansible の設定" - -#: ../../rst/installation_guide/intro_configuration.rst:8 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/installation_guide/intro_configuration.rst:10 -msgid "This topic describes how to control Ansible settings." -msgstr "ここでは、Ansible の設定を制御する方法を説明します。" - -#: ../../rst/installation_guide/intro_configuration.rst:16 -msgid "Configuration file" -msgstr "設定ファイル" - -#: ../../rst/installation_guide/intro_configuration.rst:18 -msgid "Certain settings in Ansible are adjustable via a configuration file (ansible.cfg). The stock configuration should be sufficient for most users, but there may be reasons you would want to change them. Paths where configuration file is searched are listed in :ref:`reference documentation`." -msgstr "Ansible の一部の設定は、設定ファイル (ansible.cfg) で調整できます。ほとんどの場合には stock 設定で十分ですが、変更した方が適している場合もあります。設定ファイルの検索先のパスは「:ref:`参照ドキュメント`」に一覧表示されます。" - -#: ../../rst/installation_guide/intro_configuration.rst:25 -msgid "Getting the latest configuration" -msgstr "最新設定の取得" - -#: ../../rst/installation_guide/intro_configuration.rst:27 -msgid "If installing Ansible from a package manager, the latest ``ansible.cfg`` file should be present in ``/etc/ansible``, possibly as a ``.rpmnew`` file (or other) as appropriate in the case of updates." -msgstr "パッケージマネージャーから Ansible をインストールした場合は、最新の ``ansible.cfg`` ファイルが ``/etc/ansible`` に存在しているはずです。更新では、``.rpmnew`` ファイル (またはその他のファイル) が適切な場合もあります。" - -#: ../../rst/installation_guide/intro_configuration.rst:30 -msgid "If you installed Ansible from pip or from source, you may want to create this file in order to override default settings in Ansible." -msgstr "Ansible を pip またはソースからインストールした場合は、このファイルを作成して Ansible のデフォルト設定をオーバーライドすることもできます。" - -#: ../../rst/installation_guide/intro_configuration.rst:33 -msgid "An `example file is available on GitHub `_." -msgstr "サンプルファイルは `GitHub `_ から入手できます。" - -#: ../../rst/installation_guide/intro_configuration.rst:35 -msgid "For more details and a full listing of available configurations go to :ref:`configuration_settings`. Starting with Ansible version 2.4, you can use the :ref:`ansible-config` command line utility to list your available options and inspect the current values." -msgstr "詳細と利用可能な設定の完全一覧は「:ref:`configuration_settings`」にあります。Ansible バージョン 2.4 以降では、:ref:`ansible-config` コマンドラインユーティリティーを使用して利用可能なオプションの一覧を表示し、現在の値を確認できます。" - -#: ../../rst/installation_guide/intro_configuration.rst:37 -msgid "For in-depth details, see :ref:`ansible_configuration_settings`." -msgstr "詳細は、「:ref:`ansible_configuration_settings`」参照してください。" - -#: ../../rst/installation_guide/intro_configuration.rst:42 -msgid "Environmental configuration" -msgstr "環境設定" - -#: ../../rst/installation_guide/intro_configuration.rst:44 -msgid "Ansible also allows configuration of settings using environment variables. If these environment variables are set, they will override any setting loaded from the configuration file." -msgstr "Ansible では、環境変数を使用した設定も可能です。これらの環境変数が設定されている場合は、設定ファイルから読み込まれた設定はすべて上書きされます。" - -#: ../../rst/installation_guide/intro_configuration.rst:47 -msgid "You can get a full listing of available environment variables from :ref:`ansible_configuration_settings`." -msgstr "「:ref:`ansible_configuration_settings`」は、利用可能な環境変数の詳細な一覧を確認できます。" - -#: ../../rst/installation_guide/intro_configuration.rst:53 -msgid "Command line options" -msgstr "コマンドラインオプション" - -#: ../../rst/installation_guide/intro_configuration.rst:55 -msgid "Not all configuration options are present in the command line, just the ones deemed most useful or common. Settings in the command line will override those passed through the configuration file and the environment." -msgstr "すべての設定オプションがコマンドラインに表示されるわけではなく、最も有用オプションと一般的なオプションのみが表示されます。コマンドラインの設定は、設定ファイルと環境を介して渡された設定を上書きされます。" - -#: ../../rst/installation_guide/intro_configuration.rst:58 -msgid "The full list of options available is in :ref:`ansible-playbook` and :ref:`ansible`." -msgstr "利用可能なオプションの詳細な一覧は「:ref:`ansible-playbook`」および「:ref:`ansible`」にあります。" - -#: ../../rst/installation_guide/intro_installation.rst:5 -msgid "Installing Ansible" -msgstr "Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:7 -msgid "This page describes how to install Ansible on different platforms. Ansible is an agentless automation tool that by default manages machines over the SSH protocol. Once installed, Ansible does not add a database, and there will be no daemons to start or keep running. You only need to install it on one machine (which could easily be a laptop) and it can manage an entire fleet of remote machines from that central point. When Ansible manages remote machines, it does not leave software installed or running on them, so there's no real question about how to upgrade Ansible when moving to a new version." -msgstr "ここでは、さまざまなプラットフォームに Ansible をインストールする方法を説明します。Ansible は、デフォルトで SSH プロトコルを介してマシンを管理するエージェントレス自動化ツールです。インストールしても、Ansible はデータベースを追加せず、起動または稼働し続けるデーモンもありません。Ansible を 1 台のマシン (ラップトップでも可) にインストールするだけで、そのマシンからリモートマシン全体を一元管理できます。Ansible がリモートマシンを管理する場合は、ソフトウェアをマシンにインストールしたまま、あるいは実行したままにすることがないため、新しいバージョンに移行する際に Ansible のアップグレードが問題になることはありません。" - -#: ../../rst/installation_guide/intro_installation.rst:16 -msgid "Prerequisites" -msgstr "要件" - -#: ../../rst/installation_guide/intro_installation.rst:18 -msgid "You install Ansible on a control node, which then uses SSH (by default) to communicate with your managed nodes (those end devices you want to automate)." -msgstr "Ansible をコントロールノードにインストールし、SSH (デフォルト) を使用して管理ノード (自動化するエンドデバイス) と通信します。" - -#: ../../rst/installation_guide/intro_installation.rst:23 -msgid "Control node requirements" -msgstr "コントロールノードの要件" - -#: ../../rst/installation_guide/intro_installation.rst:25 -msgid "Currently Ansible can be run from any machine with Python 2 (version 2.7) or Python 3 (versions 3.5 and higher) installed. Ansible 2.11 will make Python 3.8 a soft dependency for the control node, but will function with the aforementioned requirements. Ansible 2.12 will require Python 3.8 or newer to function on the control node. Starting with Ansible 2.11, the project will only be packaged for Python 3.8 and newer. This includes Red Hat, Debian, CentOS, macOS, any of the BSDs, and so on. Windows is not supported for the control node, read more about this in `Matt Davis's blog post `_." -msgstr "現在、Ansible は、Python 2 (バージョン 2.7) または Python 3 (バージョン 3.5 以降) がインストールされていればどのマシンからでも実行できます。Ansible 2.11 は、Python 3.8 をコントロールノードのソフト依存関係にしますが、前述の要件で機能します。Ansible 2.12 のコントロールノードで機能するには、Python 3.8 以降が必要です。Ansible 2.11 以降では、このプロジェクトは Python 3.8 以降に対してのみパッケージ化されます。これには、Red Hat、Debian、CentOS、MacOS をはじめ、各種 BSD などが含まれます。コントロールノードでは、Windows のサポートはありません。詳細は、`Matt Davis's blog post `_ を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:29 -msgid "When choosing a control node, bear in mind that any management system benefits from being run near the machines being managed. If you are running Ansible in a cloud, consider running it from a machine inside that cloud. In most cases this will work better than on the open Internet." -msgstr "コントロールノードを選択するときは、管理対象のマシンの近くで実行することに利点があることを念頭に置いてください。Ansible をクラウドで実行している場合は、そのクラウド内のマシンから実行することを検討してください。ほとんどの場合は、オープンなインターネット上で実行するよりも、同じクラウド内から実行するほうが適切です。" - -#: ../../rst/installation_guide/intro_installation.rst:33 -msgid "macOS by default is configured for a small number of file handles, so if you want to use 15 or more forks you'll need to raise the ulimit with ``sudo launchctl limit maxfiles unlimited``. This command can also fix any \"Too many open files\" error." -msgstr "MacOS はデフォルトで、少数のファイルハンドル向けに設定されているため、15 個以上のフォークを使用する場合は、``sudo launchctl limit maxfiles unlimited`` を使用して ulimit を増やす必要があります。このコマンドは、「Too many open files」エラーを修正することもできます。" - -#: ../../rst/installation_guide/intro_installation.rst:38 -msgid "Ansible 2.11 will make Python 3.8 a soft dependency for the control node, but will function with the aforementioned requirements. Ansible 2.12 will require Python 3.8 or newer to function on the control node. Starting with Ansible 2.11, the project will only be packaged for Python 3.8 and newer." -msgstr "Ansible 2.11 は、Python 3.8 をコントロールノードのソフト依存関係にしますが、前述の要件で機能します。Ansible 2.12 では、コントロールノードで機能するために Python3.8 以降が必要です。Ansible 2.11 以降、プロジェクトは Python 3.8 以降でのみパッケージ化されます。" - -#: ../../rst/installation_guide/intro_installation.rst:42 -msgid "Please note that some modules and plugins have additional requirements. For modules these need to be satisfied on the 'target' machine (the managed node) and should be listed in the module specific docs." -msgstr "モジュールやプラグインには追加の要件があることに注意してください。モジュールについては、「ターゲット」マシン (管理対象ノード) でこの追加要件を満たす必要があります。これについては各モジュールのドキュメントに記載されています。" - -#: ../../rst/installation_guide/intro_installation.rst:47 -msgid "Managed node requirements" -msgstr "管理ノードの要件" - -#: ../../rst/installation_guide/intro_installation.rst:49 -msgid "On the managed nodes, you need a way to communicate, which is normally SSH. By default this uses SFTP. If that's not available, you can switch to SCP in :ref:`ansible.cfg `. You also need Python 2 (version 2.6 or later) or Python 3 (version 3.5 or later)." -msgstr "管理ノードでは通信手段が必要です。通常は SSH が使用されます。デフォルトでは SFTP が使用されます。SFTP を使用できない場合は、:ref:`ansible.cfg ` で SCP に切り替えることができます。Python 2 (バージョン 2.6 以降) または Python 3 (バージョン 3.5 以降) も 必要になります。" - -#: ../../rst/installation_guide/intro_installation.rst:56 -msgid "If you have SELinux enabled on remote nodes, you will also want to install libselinux-python on them before using any copy/file/template related functions in Ansible. You can use the :ref:`yum module` or :ref:`dnf module` in Ansible to install this package on remote systems that do not have it." -msgstr "リモートノードで SELinux を有効にしている場合は、Ansible でコピー/ファイル/テンプレート関連の機能を使用する前に、libselinux-python をインストールすることもできます。リモートシステムにこのパッケージがインストールされていない場合は、Ansible で :ref:`yum モジュール` または :ref:`dnf モジュール` を使用してインストールできます。" - -#: ../../rst/installation_guide/intro_installation.rst:61 -msgid "By default, before the first Python module in a playbook runs on a host, Ansible attempts to discover a suitable Python interpreter on that host. You can override the discovery behavior by setting the :ref:`ansible_python_interpreter` inventory variable to a specific interpreter, and in other ways. See :ref:`interpreter_discovery` for details." -msgstr "デフォルトでは、Playbook の最初の Python モジュールがホストで実行される前に、Ansible はそのホストで適切な Python インタープリターを検出しようとします。検出動作は、:ref:`ansible_python_interpreter` インベントリー変数を特定のインタープリターに設定でき、その他の方法で無効にできます。詳細は、「:ref:`interpreter_discovery`」を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:63 -msgid "Ansible's :ref:`raw module`, and the :ref:`script module`, do not depend on a client side install of Python to run. Technically, you can use Ansible to install a compatible version of Python using the :ref:`raw module`, which then allows you to use everything else. For example, if you need to bootstrap Python 2 onto a RHEL-based system, you can install it as follows:" -msgstr "Ansible の :ref:`raw モジュール` および :ref:`script モジュール` は、実行する Python のクライアント側インストールに依存しません。技術的には、Ansible を使用して :ref:`raw モジュール` を使用して互換性のあるバージョンの Python をインストールできます。これ以外のものをすべて使用できます。たとえば、Python 2 を RHEL ベースのシステムにブートストラップする必要がある場合は、以下のようにインストールできます。" - -#: ../../rst/installation_guide/intro_installation.rst:76 -msgid "Selecting an Ansible version to install" -msgstr "インストールする Ansible バージョンの選択" - -#: ../../rst/installation_guide/intro_installation.rst:78 -msgid "Which Ansible version to install is based on your particular needs. You can choose any of the following ways to install Ansible:" -msgstr "インストールする Ansible バージョンは、特定のニーズに基づいて決定します。Ansible をインストールするには、以下のいずれかの方法を選択できます。" - -#: ../../rst/installation_guide/intro_installation.rst:80 -msgid "Install the latest release with your OS package manager (for Red Hat Enterprise Linux (TM), CentOS, Fedora, Debian, or Ubuntu)." -msgstr "OS パッケージマネージャー (Red Hat Enterprise Linux (TM)、CentOS、Fedora、Debian、または Ubuntu の場合) を使用して最新リリースをインストールします。" - -#: ../../rst/installation_guide/intro_installation.rst:81 -msgid "Install with ``pip`` (the Python package manager)." -msgstr "``pip`` (Python パッケージマネージャー) でインストールします。" - -#: ../../rst/installation_guide/intro_installation.rst:82 -msgid "Install ``ansible-base`` from source to access the development (``devel``) version to develop or test the latest features." -msgstr "ソースから ``ansible-base`` インストールして開発 (``devel``) バージョンにアクセスし、最新の機能を開発またはテストします。" - -#: ../../rst/installation_guide/intro_installation.rst:86 -msgid "You should only run ``ansible-base`` from ``devel`` if you are modifying ``ansible-base``, or trying out features under development. This is a rapidly changing source of code and can become unstable at any point." -msgstr "``devel`` から ``ansible-base`` を実行するのは、``ansible-base`` を変更する場合や、開発時に機能を試す場合にしてください。これはコードのソースが素早く変更し、いつでも不安定になる可能性があります。" - -#: ../../rst/installation_guide/intro_installation.rst:89 -msgid "Ansible creates new releases two to three times a year. Due to this short release cycle, minor bugs will generally be fixed in the next release rather than maintaining backports on the stable branch. Major bugs will still have maintenance releases when needed, though these are infrequent." -msgstr "Ansible のリリースは、年に 2 ~ 3 回作成されます。リリースサイクルがこのように短いため、マイナーなバグは通常、安定したブランチでバックポートを維持するのではなく、次のリリースで修正されます。メジャーバグについては、必要なときにメンテナンスリリースが行われますが、このようなことはあまり頻繁には起こりません。" - -#: ../../rst/installation_guide/intro_installation.rst:98 -msgid "Installing Ansible on RHEL, CentOS, or Fedora" -msgstr "RHEL、CentOS、または Fedora への Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:100 -#: ../../rst/installation_guide/intro_installation.rst:534 -msgid "On Fedora:" -msgstr "Fedora の場合:" - -#: ../../rst/installation_guide/intro_installation.rst:106 -msgid "On RHEL:" -msgstr "RHEL の場合:" - -#: ../../rst/installation_guide/intro_installation.rst:112 -msgid "On CentOS:" -msgstr "CentOS の場合:" - -#: ../../rst/installation_guide/intro_installation.rst:119 -msgid "RPMs for RHEL 7 and RHEL 8 are available from the `Ansible Engine repository `_." -msgstr "RHEL 7 および RHEL 8 の RPM は、`Ansible Engine リポジトリー `_ から入手できます。" - -#: ../../rst/installation_guide/intro_installation.rst:121 -msgid "To enable the Ansible Engine repository for RHEL 8, run the following command:" -msgstr "RHEL 8 用の Ansible Engine リポジトリーを有効にするには、以下のコマンドを実行します。" - -#: ../../rst/installation_guide/intro_installation.rst:127 -msgid "To enable the Ansible Engine repository for RHEL 7, run the following command:" -msgstr "RHEL 7 用の Ansible Engine リポジトリーを有効にするには、以下のコマンドを実行します。" - -#: ../../rst/installation_guide/intro_installation.rst:133 -msgid "RPMs for currently supported versions of RHEL and CentOS are also available from `EPEL `_." -msgstr "現在サポートされているバージョンの RHEL および CentOS の場合は、`EPEL `_ からも利用できます。" - -#: ../../rst/installation_guide/intro_installation.rst:137 -msgid "Since Ansible 2.10 for RHEL is not available at this time, continue to use Ansible 2.9." -msgstr "現在、RHEL では Ansible 2.10 が利用できないため、引き続き Ansible 2.9 を使用してください。" - -#: ../../rst/installation_guide/intro_installation.rst:139 -msgid "Ansible can manage older operating systems that contain Python 2.6 or higher." -msgstr "Ansible は、Python 2.6 以降が含まれる古いオペレーティングシステムを管理できます。" - -#: ../../rst/installation_guide/intro_installation.rst:144 -msgid "Installing Ansible on Ubuntu" -msgstr "Ubuntu への Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:146 -msgid "Ubuntu builds are available `in a PPA here `_." -msgstr "Ubuntu ビルドは `PPA `_ で利用できます。" - -#: ../../rst/installation_guide/intro_installation.rst:148 -msgid "To configure the PPA on your machine and install Ansible run these commands:" -msgstr "自分のマシンに PPA を設定して Ansible をインストールするには、次のコマンドを実行します。" - -#: ../../rst/installation_guide/intro_installation.rst:157 -msgid "On older Ubuntu distributions, \"software-properties-common\" is called \"python-software-properties\". You may want to use ``apt-get`` instead of ``apt`` in older versions. Also, be aware that only newer distributions (in other words, 18.04, 18.10, and so on) have a ``-u`` or ``--update`` flag, so adjust your script accordingly." -msgstr "以前の Ubuntu ディストリビューションでは、「software-properties-common」は「python-software-properties」と呼ばれるため、過去のバージョンでは ``apt`` ではなく ``apt-get`` を使用するほうが適している場合があります。また、``-u`` フラグまたは ``--update`` フラグが指定できるのは、新しいディストリビューション (18.04、18.10 など) に限定されることに注意し、スクリプトを調整してください。" - -#: ../../rst/installation_guide/intro_installation.rst:159 -msgid "Debian/Ubuntu packages can also be built from the source checkout, run:" -msgstr "Debian/Ubuntu パッケージは、ソースチェックアウトから構築することもできます。以下を実行します。" - -#: ../../rst/installation_guide/intro_installation.rst:165 -msgid "You may also wish to run from source to get the development branch, which is covered below." -msgstr "ソースから実行して開発ブランチを取得することも可能です。この点については以下で説明します。" - -#: ../../rst/installation_guide/intro_installation.rst:168 -msgid "Installing Ansible on Debian" -msgstr "Debian への Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:170 -msgid "Debian users may leverage the same source as the Ubuntu PPA." -msgstr "Debian を使用している場合は Ubuntu PPA と同じソースを使用できます。" - -#: ../../rst/installation_guide/intro_installation.rst:172 -msgid "Add the following line to ``/etc/apt/sources.list``:" -msgstr "以下の行を ``/etc/apt/sources.list`` に追加します。" - -#: ../../rst/installation_guide/intro_installation.rst:178 -msgid "Then run these commands:" -msgstr "次に、以下のコマンドを実行します。" - -#: ../../rst/installation_guide/intro_installation.rst:186 -msgid "This method has been verified with the Trusty sources in Debian Jessie and Stretch but may not be supported in earlier versions. You may want to use ``apt-get`` instead of ``apt`` in older versions." -msgstr "このメソッドは、Debian Jessie および Stretch の Trusty ソースで検証されていますが、以前のバージョンではサポートされない場合があります。以前のバージョンでは、``apt`` の代わりに ``apt-get`` を使用できます。" - -#: ../../rst/installation_guide/intro_installation.rst:189 -msgid "Installing Ansible on Gentoo with portage" -msgstr "portage を使用した Gentoo への Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:195 -msgid "To install the newest version, you may need to unmask the Ansible package prior to emerging:" -msgstr "最新バージョンをインストールするには、インストールする前に Ansible パッケージのマスク解除が必要になる場合があります。" - -#: ../../rst/installation_guide/intro_installation.rst:202 -msgid "Installing Ansible on FreeBSD" -msgstr "FreeBSD への Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:204 -msgid "Though Ansible works with both Python 2 and 3 versions, FreeBSD has different packages for each Python version. So to install you can use:" -msgstr "Ansible は Python 2 および 3 の両バージョンで動作しますが、FreeBSD パッケージは各 Python バージョンで異なります。したがって、インストールには、以下を使用できます。" - -#: ../../rst/installation_guide/intro_installation.rst:211 -msgid "or:" -msgstr "または" - -#: ../../rst/installation_guide/intro_installation.rst:218 -msgid "You may also wish to install from ports, run:" -msgstr "ポートからインストールすることもできます。以下を実行します。" - -#: ../../rst/installation_guide/intro_installation.rst:224 -msgid "You can also choose a specific version, for example ``ansible25``." -msgstr "特定のバージョン (例: ``ansible25``) を選択することもできます。" - -#: ../../rst/installation_guide/intro_installation.rst:226 -msgid "Older versions of FreeBSD worked with something like this (substitute for your choice of package manager):" -msgstr "以前のバージョンの FreeBSD は、以下のようなもので動作します (パッケージマネージャーの代わりです)。" - -#: ../../rst/installation_guide/intro_installation.rst:235 -msgid "Installing Ansible on macOS" -msgstr "MacOS への Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:237 -msgid "The preferred way to install Ansible on a Mac is with ``pip``." -msgstr "Mac に Ansible をインストールするには ``pip`` を使用することが推奨されます。" - -#: ../../rst/installation_guide/intro_installation.rst:239 -msgid "The instructions can be found in :ref:`from_pip`. If you are running macOS version 10.12 or older, then you should upgrade to the latest ``pip`` to connect to the Python Package Index securely. It should be noted that pip must be run as a module on macOS, and the linked ``pip`` instructions will show you how to do that." -msgstr "手順は「:ref:`from_pip`」を参照してください。MacOS バージョン 10.12 以前を実行している場合に、Python Package Index に安全に接続するには最新の ``pip`` にアップグレードする必要があります。pip は、MacOS でモジュールとして実行する必要があり、リンクされている ``pip`` の手順にその実行方法が示されることに注意してください。" - -#: ../../rst/installation_guide/intro_installation.rst:243 -#: ../../rst/installation_guide/intro_installation.rst:316 -#: ../../rst/installation_guide/intro_installation.rst:389 -#: ../../rst/installation_guide/intro_installation.rst:413 -msgid "If you have Ansible 2.9 or older installed, you need to use ``pip uninstall ansible`` first to remove older versions of Ansible before re-installing it." -msgstr "Ansible 2.9 以前のバージョンをインストールしている場合は、先に ``pip uninstall ansible`` を使用して古いバージョンの Ansible を削除してから再インストールする必要があります。" - -#: ../../rst/installation_guide/intro_installation.rst:245 -msgid "If you are installing on macOS Mavericks (10.9), you may encounter some noise from your compiler. A workaround is to do the following::" -msgstr "MacOS Mavericks (10.9) にインストールする場合は、コンパイラーから何らかの問題が発生する可能性があります。回避策として、以下を行います。" - -#: ../../rst/installation_guide/intro_installation.rst:253 -msgid "Installing Ansible on Solaris" -msgstr "Solaris への Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:255 -msgid "Ansible is available for Solaris as `SysV package from OpenCSW `_." -msgstr "Solaris では、`SysV package from OpenCSW `_ として Ansible を利用できます。" - -#: ../../rst/installation_guide/intro_installation.rst:265 -msgid "Installing Ansible on Arch Linux" -msgstr "Arch Linux への Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:267 -msgid "Ansible is available in the Community repository::" -msgstr "Ansible は、コミュニティーリポジトリーから入手できます::" - -#: ../../rst/installation_guide/intro_installation.rst:271 -msgid "The AUR has a PKGBUILD for pulling directly from GitHub called `ansible-git `_." -msgstr "AUR には、(`ansible-git `_ と呼ばれている) GitHub から直接プルするための PKGBUILD があります。" - -#: ../../rst/installation_guide/intro_installation.rst:273 -msgid "Also see the `Ansible `_ page on the ArchWiki." -msgstr "ArchWiki の「`Ansible `_」ページを参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:278 -msgid "Installing Ansible on Slackware Linux" -msgstr "Slackware Linux への Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:280 -msgid "Ansible build script is available in the `SlackBuilds.org `_ repository. Can be built and installed using `sbopkg `_." -msgstr "Ansible ビルドスクリプトは `SlackBuilds.org `_ リポジトリーから利用できます。`sbopkg `_ を使用してビルドおよびインストールできます。" - -#: ../../rst/installation_guide/intro_installation.rst:283 -msgid "Create queue with Ansible and all dependencies::" -msgstr "Ansible およびすべての依存関係を含むキューを作成します::" - -#: ../../rst/installation_guide/intro_installation.rst:287 -msgid "Build and install packages from a created queuefile (answer Q for question if sbopkg should use queue or package)::" -msgstr "作成した queuefile からパッケージを構築してインストールします (sbopkg がキューまたはパッケージを使用する必要がある場合の問題への回答 Q)::" - -#: ../../rst/installation_guide/intro_installation.rst:294 -msgid "Installing Ansible on Clear Linux" -msgstr "Clear Linux への Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:296 -msgid "Ansible and its dependencies are available as part of the sysadmin host management bundle::" -msgstr "Ansible およびその依存関係は、sysadmin ホスト管理バンドルの一部として利用できます::" - -#: ../../rst/installation_guide/intro_installation.rst:300 -msgid "Update of the software will be managed by the swupd tool::" -msgstr "ソフトウェアの更新は、swupd ツールにより管理されます::" - -#: ../../rst/installation_guide/intro_installation.rst:307 -msgid "Installing Ansible with ``pip``" -msgstr "``pip`` を使用した Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:309 -msgid "Ansible can be installed with ``pip``, the Python package manager. If ``pip`` isn't already available on your system of Python, run the following commands to install it::" -msgstr "Python パッケージマネージャーである ``pip`` で Ansible をインストールできます。``pip`` が Python のシステムで利用できない場合は、以下のコマンドを実行してインストールします。" - -#: ../../rst/installation_guide/intro_installation.rst:318 -msgid "Then install Ansible [1]_::" -msgstr "次に Ansible [1]_ をインストールします::" - -#: ../../rst/installation_guide/intro_installation.rst:325 -msgid "If this is your first time installing packages with pip, you may need to perform some additional configuration before you are able to run Ansible. See the Python documentation on `installing to the user site`_ for more information." -msgstr "pip でパッケージを初めてインストールする場合は、Ansible を実行する前に追加の設定が必要になる場合があります。詳細は、Python ドキュメント「`ユーザーサイトへのインストール`_ を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:330 -msgid "In order to use the ``paramiko`` connection plugin or modules that require ``paramiko``, install the required module [2]_::" -msgstr "``paramiko`` を必要とする ``paramiko`` 接続プラグインまたはモジュールを使用するには、必要なモジュール [2]_ をインストールします。" - -#: ../../rst/installation_guide/intro_installation.rst:334 -msgid "If you wish to install Ansible globally, run the following commands::" -msgstr "Ansible をグローバルにインストールする場合は、以下のコマンドを実行します::" - -#: ../../rst/installation_guide/intro_installation.rst:341 -msgid "Running ``pip`` with ``sudo`` will make global changes to the system. Since ``pip`` does not coordinate with system package managers, it could make changes to your system that leaves it in an inconsistent or non-functioning state. This is particularly true for macOS. Installing with ``--user`` is recommended unless you understand fully the implications of modifying global files on the system." -msgstr "``sudo`` で ``pip`` を実行すると、システムにグローバルの変更が行われます。``pip`` はシステムパッケージマネージャーと連携しないため、システムに変更が加えられ、システムが一貫性のない状態または機能しない状態になる可能性があります。これは特に MacOS に当てはまります。システム上のグローバルファイルを変更した場合の影響を完全に理解していない限り、``--user`` でインストールすることが推奨されます。" - -#: ../../rst/installation_guide/intro_installation.rst:345 -msgid "Older versions of ``pip`` default to http://pypi.python.org/simple, which no longer works. Please make sure you have the latest version of ``pip`` before installing Ansible. If you have an older version of ``pip`` installed, you can upgrade by following `pip's upgrade instructions `_ ." -msgstr "古いバージョンの ``pip`` は、http://pypi.python.org/simple がデフォルトとなります。これは有効ではなくなりました。Ansible をインストールする前に、``pip`` の最新バージョンをお持ちであることを確認してください。古いバージョンの ``pip`` がインストールされている場合は、`pip のアップグレード手順 `_ でアップグレードできます。" - -#: ../../rst/installation_guide/intro_installation.rst:350 -msgid "Upgrading Ansible from version 2.9 and older to version 2.10 or later" -msgstr "Ansible のバージョン 2.9 以前から 2.10 以降へのアップグレード" - -#: ../../rst/installation_guide/intro_installation.rst:352 -msgid "Starting in version 2.10, Ansible is made of two packages. You need to first uninstall the old Ansible version (2.9 or earlier) before upgrading. If you do not uninstall the older version of Ansible, you will see the following message, and no change will be performed:" -msgstr "バージョン 2.10 以降では、Ansible は 2 つのパッケージで構成されています。最初にアップグレードの前に、古い Ansible バージョン (2.9 以前) をアンインストールする必要があります。古いバージョンの Ansible をアンインストールしない場合は、以下のメッセージが表示され、変更が実行されません。" - -#: ../../rst/installation_guide/intro_installation.rst:368 -msgid "As explained by the message, to upgrade you must first remove the version of Ansible installed and then install it to the latest version." -msgstr "メッセージで説明されているように、アップグレードするには、最初にインストールした Ansible のバージョンを削除してから、最新バージョンにインストールする必要があります。" - -#: ../../rst/installation_guide/intro_installation.rst:379 -msgid "Installing the development version of ``ansible-base``" -msgstr "開発バージョンの ``ansible-base`` のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:381 -#: ../../rst/installation_guide/intro_installation.rst:426 -msgid "In Ansible 2.10 and later, The `ansible/ansible repository `_ contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-base``." -msgstr "Ansible 2.10 以降では、`ansible/ansible リポジトリー `_ には、モジュールコードを管理対象ノードにコピーするなど、基本的な機能や関数のコードが含まれています。このコードは ``ansible-base`` としても知られています。" - -#: ../../rst/installation_guide/intro_installation.rst:385 -#: ../../rst/installation_guide/intro_installation.rst:430 -msgid "You should only run ``ansible-base`` from ``devel`` if you are modifying ``ansible-base`` or trying out features under development. This is a rapidly changing source of code and can become unstable at any point." -msgstr "``ansible-base`` を変更する場合や、開発時に機能を試す場合にのみ、``devel`` から ``ansible-base`` を実行する必要があります。これはコードのソースが素早く変更し、いつでも不安定になる可能性があります。" - -#: ../../rst/installation_guide/intro_installation.rst:392 -msgid "You can install the development version of ``ansible-base`` directly from GitHub with pip." -msgstr "開発バージョンの ``ansible-base`` は、pip を使用して GitHub から直接インストールできます。" - -#: ../../rst/installation_guide/intro_installation.rst:398 -msgid "Replace ``devel`` in the URL mentioned above, with any other branch or tag on GitHub to install older versions of Ansible (prior to ``ansible-base`` 2.10.) This installs all of Ansible." -msgstr "上記の URL の ``devel`` を GitHub の他のブランチまたはタグに置き換え、古いバージョンの Ansible（``ansible-base`` 2.10 以前) をインストールします。これにより、すべての Ansible がインストールされます。" - -#: ../../rst/installation_guide/intro_installation.rst:404 -msgid "See :ref:`from_source` for instructions on how to run ``ansible-base`` directly from source, without the requirement of installation." -msgstr "インストールの必要がなく、ソースから ``ansible-base`` を直接実行する方法については、「:ref:`from_source`」を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:409 -msgid "Virtual Environments" -msgstr "仮想環境" - -#: ../../rst/installation_guide/intro_installation.rst:415 -msgid "Ansible can also be installed inside a new or existing ``virtualenv``::" -msgstr "Ansible は、新規または既存の ``virtualenv`` 内にもインストールできます::" - -#: ../../rst/installation_guide/intro_installation.rst:424 -msgid "Running ``ansible-base`` from source (devel)" -msgstr "ソース (devel) から ``ansible-base`` の実行" - -#: ../../rst/installation_guide/intro_installation.rst:432 -msgid "``ansible-base`` is easy to run from source. You do not need ``root`` permissions to use it and there is no software to actually install. No daemons or database setup are required." -msgstr "``ansible-base`` ソースからの実行は簡単です。``root`` パーミッションは必要ありません。実際にインストールするソフトウェアはありません。デーモンやデータベース設定は必要ありません。" - -#: ../../rst/installation_guide/intro_installation.rst:438 -msgid "If you want to use Ansible Tower as the control node, do not use a source installation of Ansible. Please use an OS package manager (like ``apt`` or ``yum``) or ``pip`` to install a stable version." -msgstr "Ansible Tower をコントロールノードとして使用する場合は、Ansible のソースインストールは使用せず、OS パッケージマネージャー (``apt`` や ``yum`` など) を使用するか、``pip`` を使用して安定したバージョンをインストールしてください。" - -#: ../../rst/installation_guide/intro_installation.rst:441 -msgid "To install from source, clone the ``ansible-base`` git repository:" -msgstr "ソースからインストールするには、git リポジトリー ``ansible-base`` のクローンを作成します。" - -#: ../../rst/installation_guide/intro_installation.rst:448 -msgid "Once ``git`` has cloned the ``ansible-base`` repository, setup the Ansible environment:" -msgstr "``git`` が ``ansible-base`` リポジトリーのクローンを作成したら、Ansible 環境を設定します。" - -#: ../../rst/installation_guide/intro_installation.rst:450 -msgid "Using Bash:" -msgstr "Bash の使用:" - -#: ../../rst/installation_guide/intro_installation.rst:456 -msgid "Using Fish::" -msgstr "Fish の使用::" - -#: ../../rst/installation_guide/intro_installation.rst:460 -msgid "If you want to suppress spurious warnings/errors, use::" -msgstr "誤った警告やエラーが表示されないようにするには、以下を使用します::" - -#: ../../rst/installation_guide/intro_installation.rst:464 -msgid "If you don't have ``pip`` installed in your version of Python, install it::" -msgstr "お使いのバージョンの Python に ``pip`` がインストールされていない場合は、インストールします::" - -#: ../../rst/installation_guide/intro_installation.rst:469 -msgid "Ansible also uses the following Python modules that need to be installed [1]_:" -msgstr "Ansible は、以下の Python モジュールも使用し、このモジュールもインストールする必要があります [1]_。" - -#: ../../rst/installation_guide/intro_installation.rst:475 -msgid "To update ``ansible-base`` checkouts, use pull-with-rebase so any local changes are replayed." -msgstr "``ansible-base`` チェックアウトを更新するには、pull-with-rebase を使用してローカルの変更がリプレイされるようにします。" - -#: ../../rst/installation_guide/intro_installation.rst:486 -msgid "Once running the env-setup script you'll be running from checkout and the default inventory file will be ``/etc/ansible/hosts``. You can optionally specify an inventory file (see :ref:`inventory`) other than ``/etc/ansible/hosts``:" -msgstr "env-setup スクリプトを実行すると、チェックアウトから実行が行われ、デフォルトのインベントリーファイルが ``/etc/ansible/hosts`` になります。必要に応じて、``/etc/ansible/hosts`` 以外のインベントリーファイル (「:ref:`inventory`」を参照) を指定できます。" - -#: ../../rst/installation_guide/intro_installation.rst:495 -msgid "You can read more about the inventory file at :ref:`inventory`." -msgstr "インベントリーファイルの詳細は、:ref:`inventory`を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:497 -msgid "Now let's test things with a ping command:" -msgstr "では、ping コマンドを使ってテストしていきましょう。" - -#: ../../rst/installation_guide/intro_installation.rst:503 -msgid "You can also use \"sudo make install\"." -msgstr "「sudo make install」も使用できます。" - -#: ../../rst/installation_guide/intro_installation.rst:508 -msgid "Finding tarballs of tagged releases" -msgstr "タグ付けされたリリースの tarball の場所" - -#: ../../rst/installation_guide/intro_installation.rst:510 -msgid "Packaging Ansible or wanting to build a local package yourself, but don't want to do a git checkout? Tarballs of releases are available from ``pypi`` as https://pypi.python.org/packages/source/a/ansible/ansible-{{VERSION}}.tar.gz. You can make VERSION a variable in your package managing system that you update in one place whenever you package a new version. Alternately, you can download https://pypi.python.org/project/ansible to get the latest stable release." -msgstr "git チェックアウトせずに、Ansible をパッケージ化したり、ローカルパッケージをご自身で構築する場合があります。リリースの tarball は、``pypi`` で https://pypi.python.org/packages/source/a/ansible/ansible-{{VERSION}}.tar.gz から入手できます。VERSION は、新しいバージョンをパッケージ化するたびに 1 カ所で更新するパッケージ管理システムの変数にすることができます。また、最新の安定版リリースを入手するには、https://pypi.python.org/project/ansible をダウンロードします。" - -#: ../../rst/installation_guide/intro_installation.rst:514 -msgid "If you are creating your own Ansible package, you must also download or package ``ansible-base`` as part of your Ansible package. You can download it as https://pypi.python.org/packages/source/a/ansible-base/ansible-base-{{VERSION}}.tar.gz." -msgstr "独自の Ansible パッケージを作成する場合は、Ansible パッケージの一部として ``ansible-base`` をダウンロードまたはパッケージ化する必要があります。これは、https://pypi.python.org/packages/source/a/ansible-base/ansible-base-{{VERSION}}.tar.gz としてダウンロードすることができます。" - -#: ../../rst/installation_guide/intro_installation.rst:516 -msgid "These releases are also tagged in the `git repository `_ with the release version." -msgstr "これらのリリースは、`git リポジトリー `_ でもリリースバージョンでタグ付けされます。" - -#: ../../rst/installation_guide/intro_installation.rst:522 -msgid "Ansible command shell completion" -msgstr "Ansible コマンドシェルの完了" - -#: ../../rst/installation_guide/intro_installation.rst:524 -msgid "As of Ansible 2.9, shell completion of the Ansible command line utilities is available and provided through an optional dependency called ``argcomplete``. ``argcomplete`` supports bash, and has limited support for zsh and tcsh." -msgstr "Ansible 2.9 の時点では、Ansible コマンドラインユーティリティーのシェル補完を利用できます。これは、``argcomplete`` というオプションの依存関係を使用して提供されます。``argcomplete`` は bash をサポートし、また制限付きで zsh および tcsh もサポートします。" - -#: ../../rst/installation_guide/intro_installation.rst:527 -msgid "You can install ``python-argcomplete`` from EPEL on Red Hat Enterprise based distributions, and or from the standard OS repositories for many other distributions." -msgstr "``python-argcomplete`` は、Red Hat Enterprise ベースのディストリビューションでは EPEL からインストールでき、その他の多くのディストリビューションでは標準 OS リポジトリーで入手できます。" - -#: ../../rst/installation_guide/intro_installation.rst:529 -msgid "For more information about installing and configuration see the `argcomplete documentation `_." -msgstr "インストールおよび設定の詳細は、`argcomplete ドキュメント `_ を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:532 -msgid "Installing ``argcomplete`` on RHEL, CentOS, or Fedora" -msgstr "RHEL、CentOS、または Fedora への ``argcomplete`` のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:540 -msgid "On RHEL and CentOS:" -msgstr "RHEL および CentOS の場合:" - -#: ../../rst/installation_guide/intro_installation.rst:549 -msgid "Installing ``argcomplete`` with ``apt``" -msgstr "``apt`` を使用した ``argcomplete`` のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:557 -msgid "Installing ``argcomplete`` with ``pip``" -msgstr "``pip`` を使用した ``argcomplete`` のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:564 -msgid "Configuring ``argcomplete``" -msgstr "``argcomplete`` の設定" - -#: ../../rst/installation_guide/intro_installation.rst:566 -msgid "There are 2 ways to configure ``argcomplete`` to allow shell completion of the Ansible command line utilities: globally or per command." -msgstr "Ansible コマンドラインユーティリティーのシェル補完を可能にする ``argcomplete`` の設定方法は、2 通りあります。" - -#: ../../rst/installation_guide/intro_installation.rst:569 -msgid "Globally" -msgstr "グローバル" - -#: ../../rst/installation_guide/intro_installation.rst:571 -msgid "Global completion requires bash 4.2." -msgstr "グローバル補完には bash 4.2 が必要です。" - -#: ../../rst/installation_guide/intro_installation.rst:577 -msgid "This will write a bash completion file to a global location. Use ``--dest`` to change the location." -msgstr "これにより、bash 補完ファイルがグローバルロケーションに書き込まれます。ロケーションを変更するには ``--dest`` を使用します。" - -#: ../../rst/installation_guide/intro_installation.rst:580 -msgid "Per command" -msgstr "コマンド単位" - -#: ../../rst/installation_guide/intro_installation.rst:582 -msgid "If you do not have bash 4.2, you must register each script independently." -msgstr "bash 4.2 がない場合は、各スクリプトを個別に登録する必要があります。" - -#: ../../rst/installation_guide/intro_installation.rst:596 -msgid "You should place the above commands into your shells profile file such as ``~/.profile`` or ``~/.bash_profile``." -msgstr "上記のコマンドを、``~/.profile``、``~/.bash_profile`` などのシェルプロファイルファイルに置く必要があります。" - -#: ../../rst/installation_guide/intro_installation.rst:599 -msgid "``argcomplete`` with zsh or tcsh" -msgstr "zsh または tcsh での ``argcomplete``" - -#: ../../rst/installation_guide/intro_installation.rst:601 -msgid "See the `argcomplete documentation `_." -msgstr "`argcomplete documentation `_ を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:606 -msgid "``ansible-base`` on GitHub" -msgstr "GitHub の ``ansible-base``" - -#: ../../rst/installation_guide/intro_installation.rst:608 -msgid "You may also wish to follow the `GitHub project `_ if you have a GitHub account. This is also where we keep the issue tracker for sharing bugs and feature ideas." -msgstr "GitHub アカウントがある場合は、`GitHub project `_ をフォローすることが推奨されます。これは、バグや機能に関するアイディアを共有するための問題追跡システムを維持する場所でもあります。" - -#: ../../rst/installation_guide/intro_installation.rst:615 -msgid ":ref:`intro_adhoc`" -msgstr ":ref:`intro_adhoc`" - -#: ../../rst/installation_guide/intro_installation.rst:616 -msgid "Examples of basic commands" -msgstr "基本コマンドの例" - -#: ../../rst/installation_guide/intro_installation.rst:617 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/installation_guide/intro_installation.rst:618 -msgid "Learning ansible's configuration management language" -msgstr "Ansible の設定管理言語の概要" - -#: ../../rst/installation_guide/intro_installation.rst:619 -msgid ":ref:`installation_faqs`" -msgstr ":ref:`installation_faqs`" - -#: ../../rst/installation_guide/intro_installation.rst:620 -msgid "Ansible Installation related to FAQs" -msgstr "FAQ に関連する Ansible インストール" - -#: ../../rst/installation_guide/intro_installation.rst:621 -msgid "`Mailing List `_" -msgstr "`メーリングリスト `_" - -#: ../../rst/installation_guide/intro_installation.rst:622 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/installation_guide/intro_installation.rst:623 -msgid "`irc.freenode.net `_" -msgstr "`irc.freenode.net `_" - -#: ../../rst/installation_guide/intro_installation.rst:624 -msgid "#ansible IRC chat channel" -msgstr "IRC チャットチャネル (#ansible)" - -#: ../../rst/installation_guide/intro_installation.rst:626 -msgid "If you have issues with the \"pycrypto\" package install on macOS, then you may need to try ``CC=clang sudo -E pip install pycrypto``." -msgstr "MacOS への「pycrypto」パッケージのインストールに問題がある場合は、``CC=clang sudo -E pip install pycrypto`` の試行が必要になる場合があります。" - -#: ../../rst/installation_guide/intro_installation.rst:627 -msgid "``paramiko`` was included in Ansible's ``requirements.txt`` prior to 2.8." -msgstr "``paramiko`` は、2.8 以前の Ansible の ``requirements.txt`` に同梱されています。" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/inventory.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/inventory.po deleted file mode 100644 index 43adbb8c190..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/inventory.po +++ /dev/null @@ -1,58 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-02-23 10:50+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/inventory/implicit_localhost.rst:6 -msgid "Implicit 'localhost'" -msgstr "暗黙的な「localhost」" - -#: ../../rst/inventory/implicit_localhost.rst:8 -msgid "When you try to reference a ``localhost`` and you don't have it defined in inventory, Ansible will create an implicit one for you.::" -msgstr "``localhost`` を参照しようとしたにもかかわらず、インベントリーにその localhost が定義されていない場合は、Ansible により暗黙的 localhost が作成されます::" - -#: ../../rst/inventory/implicit_localhost.rst:16 -msgid "In a case like this (or ``local_action``) when Ansible needs to contact a 'localhost' but you did not supply one, we create one for you. This host is defined with specific connection variables equivalent to this in an inventory::" -msgstr "上記のような場合 (または ``local_action``) で、Ansible が「localhost」に問い合わせをする必要があるにもかかわらず、localhost を作成していない場合には、Ansible で localhost が作成されます。このホストは、インベントリーにあるものと同等の特定の接続変数で定義されます::" - -#: ../../rst/inventory/implicit_localhost.rst:26 -msgid "This ensures that the proper connection and Python are used to execute your tasks locally. You can override the built-in implicit version by creating a ``localhost`` host entry in your inventory. At that point, all implicit behaviors are ignored; the ``localhost`` in inventory is treated just like any other host. Group and host vars will apply, including connection vars, which includes the ``ansible_python_interpreter`` setting. This will also affect ``delegate_to: localhost`` and ``local_action``, the latter being an alias to the former." -msgstr "この設定により、適切な接続と Python がローカルでタスクを実行するのに使用されるようにます。インベントリーに ``localhost`` ホストエントリーを作成すると、組み込みの暗黙的ホストのバージョンを上書きできます。この時点で、暗黙的な動作はすべて無視され、インベントリー内の ``localhost`` は他のホストと同じように処理されます。グループおよびホストの変数 (接続変数を含む) が適用されます。これには、``ansible_python_interpreter`` 設定が含まれます。グループおよびホスト変数の設定は、``delegate_to: localhost`` および ``local_action`` にも適用され、``local_action`` は ``delegate_to: localhost`` のエイリアスとなります。" - -#: ../../rst/inventory/implicit_localhost.rst:30 -msgid "This host is not targetable via any group, however it will use vars from ``host_vars`` and from the 'all' group." -msgstr "このホストをターゲットにできるグループはありませんが、``host_vars`` と「all」グループの変数を使用します。" - -#: ../../rst/inventory/implicit_localhost.rst:31 -msgid "Implicit localhost does not appear in the ``hostvars`` magic variable unless demanded, such as by ``\"{{ hostvars['localhost'] }}\"``." -msgstr "``\"{{ hostvars['localhost'] }}\"`` などの要求がない限り、暗黙的な localhost は ``hostvars`` マジック変数には表示されません。" - -#: ../../rst/inventory/implicit_localhost.rst:32 -msgid "The ``inventory_file`` and ``inventory_dir`` magic variables are not available for the implicit localhost as they are dependent on **each inventory host**." -msgstr "マジック変数 ``inventory_file`` および ``inventory_dir`` は、**各インベントリーホスト** に依存しているため、暗黙的な localhost では利用できません。" - -#: ../../rst/inventory/implicit_localhost.rst:33 -msgid "This implicit host also gets triggered by using ``127.0.0.1`` or ``::1`` as they are the IPv4 and IPv6 representations of 'localhost'." -msgstr "この暗黙的ホストは、「localhost」の IPv4 および IPv6 の表現であるため、``127.0.0.1`` または ``::1`` を使用しても発生しません。" - -#: ../../rst/inventory/implicit_localhost.rst:34 -msgid "Even though there are many ways to create it, there will only ever be ONE implicit localhost, using the name first used to create it." -msgstr "それを作成する方法は多数ありますが、暗黙的な localhost は 1 つだけ存在することになります。最初に作成したときに使用した名前が使用されます。" - -#: ../../rst/inventory/implicit_localhost.rst:35 -msgid "Having ``connection: local`` does NOT trigger an implicit localhost, you are just changing the connection for the ``inventory_hostname``." -msgstr "``connection: local`` があっても暗黙的な localhost が作成されない場合は、``inventory_hostname`` の接続を変更します。" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/network.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/network.po deleted file mode 100644 index 8705061bec4..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/network.po +++ /dev/null @@ -1,5522 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2019 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-03-08 20:25+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:7 -msgid "Developing network plugins" -msgstr "ネットワークプラグインの開発" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:9 -msgid "You can extend the existing network modules with custom plugins in your collection." -msgstr "コレクションのカスタムプラグインを使用して、既存のネットワークモジュールを拡張できます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:15 -msgid "Network connection plugins" -msgstr "ネットワーク接続プラグイン" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:16 -msgid "Each network connection plugin has a set of its own plugins which provide a specification of the connection for a particular set of devices. The specific plugin used is selected at runtime based on the value of the ``ansible_network_os`` variable assigned to the host. This variable should be set to the same value as the name of the plugin to be loaded. Thus, ``ansible_network_os=nxos`` will try to load a plugin in a file named ``nxos.py``, so it is important to name the plugin in a way that will be sensible to users." -msgstr "各ネットワーク接続プラグインには、独自のプラグインセットがあります。これは、特定のデバイスセットの接続の仕様を提供します。使用される特定のプラグインは、ホストに割り当てられた ``ansible_network_os`` 変数の値に基づいてランタイム時に選択されます。この変数は、読み込むプラグインの名前と同じ値に設定する必要があります。そのため、``ansible_network_os=nxos`` は、``nxos.py`` という名前のファイルにプラグインを読み込もうとするため、ユーザーが適切な方法でプラグインに名前を付けることが重要です。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:23 -msgid "Public methods of these plugins may be called from a module or module_utils with the connection proxy object just as other connection methods can. The following is a very simple example of using such a call in a module_utils file so it may be shared with other modules." -msgstr "これらのプラグインのパブリックメソッドは、他の接続方法と同様に、接続のプロキシーオブジェクトを使用して、モジュールまたは module_utils から接続で呼び出すことができます。以下は、その他のモジュールと共有できるように、module_utils ファイルでこのような呼び出しを使用する非常に簡単な例です。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:45 -msgid "Developing httpapi plugins" -msgstr "httpapi プラグインの開発" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:47 -msgid ":ref:`httpapi plugins ` serve as adapters for various HTTP(S) APIs for use with the ``httpapi`` connection plugin. They should implement a minimal set of convenience methods tailored to the API you are attempting to use." -msgstr ":ref:`httpapi プラグイン ` は、``httpapi`` 接続プラグインで使用するさまざまな HTTP(S) API のアダプターとして機能します。このプラグインは、使用しようとしている API に適した最小限の便利なメソッドを実装する必要があります。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:49 -msgid "Specifically, there are a few methods that the ``httpapi`` connection plugin expects to exist." -msgstr "具体的には、``httpapi`` 接続プラグインが存在することが必要なメソッドがいくつかあります。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:52 -msgid "Making requests" -msgstr "要求の作成" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:54 -msgid "The ``httpapi`` connection plugin has a ``send()`` method, but an httpapi plugin needs a ``send_request(self, data, **message_kwargs)`` method as a higher-level wrapper to ``send()``. This method should prepare requests by adding fixed values like common headers or URL root paths. This method may do more complex work such as turning data into formatted payloads, or determining which path or method to request. It may then also unpack responses to be more easily consumed by the caller." -msgstr "``httpapi`` 接続プラグインには ``send()`` メソッドがありますが、httpapi プラグインには、``send()`` への高レベルラッパーとして ``send_request(self, data, **message_kwargs)`` メソッドが必要です。このメソッドは、共通ヘッダーや URL ルートパスなどの固定値を追加することで要求を準備する必要があります。このメソッドは、フォーマットされたペイロードへのデータの切り替えや、リクエスト用のパスやメソッドの特定など、より複雑な作業を行うことがあります。その後、呼び出し元によって簡単に消費される応答が展開される可能性があります" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:74 -msgid "Authenticating" -msgstr "認証" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:76 -msgid "By default, all requests will authenticate with HTTP Basic authentication. If a request can return some kind of token to stand in place of HTTP Basic, the ``update_auth(self, response, response_text)`` method should be implemented to inspect responses for such tokens. If the token is meant to be included with the headers of each request, it is sufficient to return a dictionary which will be merged with the computed headers for each request. The default implementation of this method does exactly this for cookies. If the token is used in another way, say in a query string, you should instead save that token to an instance variable, where the ``send_request()`` method (above) can add it to each request" -msgstr "デフォルトでは、すべての要求は HTTP Basic 認証で認証されます。要求が HTTP Basic の代わりにある種のトークンを返す場合は、``update_auth(self, response, response_text)`` メソッドを実装して、このようなトークンの応答を検査する必要があります。トークンが各要求のヘッダーに含まれるように設計されている場合は、各要求に対して計算されたヘッダーとマージするディクショナリーを返すだけで十分です。このメソッドのデフォルト実装は Cookie に対して行われる方法で行われます。トークンが別の方法 (クエリー文字列など) で使用される場合は、そのトークンをインスタンス変数に保存して、``send_request()`` メソッド (上記) により各要求に追加できるようにします。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:87 -msgid "If instead an explicit login endpoint needs to be requested to receive an authentication token, the ``login(self, username, password)`` method can be implemented to call that endpoint. If implemented, this method will be called once before requesting any other resources of the server. By default, it will also be attempted once when a HTTP 401 is returned from a request." -msgstr "代わりに明示的なログインエンドポイントを要求して認証トークンを受け取る必要がある場合は、``login(self, username, password)`` メソッドを実装して、そのエンドポイントを呼び出すことができます。このメソッドを実装すると、サーバーの他のリソースを要求する前にこのメソッドが一度呼び出されます。デフォルトでは、要求から HTTP 401 が返されるとこれが一度試行されます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:105 -msgid "Similarly, ``logout(self)`` can be implemented to call an endpoint to invalidate and/or release the current token, if such an endpoint exists. This will be automatically called when the connection is closed (and, by extension, when reset)." -msgstr "同様に、``logout(self)`` を実装してエンドポイントを呼び出し、そのエンドポイントが存在する場合は現在のトークンを無効化または解放できます。これは、接続を閉じると自動的に呼び出されます (また、リセット時には拡張により呼び出されます)。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:117 -msgid "Error handling" -msgstr "エラー処理" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:119 -msgid "The ``handle_httperror(self, exception)`` method can deal with status codes returned by the server. The return value indicates how the plugin will continue with the request:" -msgstr "``handle_httperror(self, exception)`` メソッドは、サーバーによって返されるステータスコードを処理できます。戻り値は、プラグインがどのようにリクエストを続けるかを示します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:121 -msgid "A value of ``true`` means that the request can be retried. This my be used to indicate a transient error, or one that has been resolved. For example, the default implementation will try to call ``login()`` when presented with a 401, and return ``true`` if successful." -msgstr "``true`` の値は、要求を再試行できることを意味します。これは、一時的なエラーや解決されたエラーを示すために使用できます。たとえば、デフォルトの実装では、401 が示されると ``login()`` の呼び出しが試行され、成功した場合は ``true`` が返されます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:123 -msgid "A value of ``false`` means that the plugin is unable to recover from this response. The status code will be raised as an exception to the calling module." -msgstr "``false`` の値は、プラグインがこの応答から復元できないことを意味します。ステータスコードは、呼び出したモジュールに例外としてあげられます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:125 -msgid "Any other value will be taken as a nonfatal response from the request. This may be useful if the server returns error messages in the body of the response. Returning the original exception is usually sufficient in this case, as HTTPError objects have the same interface as a successful response." -msgstr "その他の値は、要求からの致命的でない応答として取られます。これは、サーバーが応答のボディーでエラーメッセージを返す場合に便利です。HTTPError オブジェクトは正常な応答と同じインターフェースを持つため、通常は元の例外を返します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:127 -msgid "For example httpapi plugins, see the `source code for the httpapi plugins `_ included with Ansible Core." -msgstr "httpapi プラグインの例は、Ansible Core に含まれる `httpapi プラグインのソースコード `_ を参照してください。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:132 -msgid "Developing NETCONF plugins" -msgstr "NETCONF プラグインの開発" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:134 -msgid "The :ref:`netconf ` connection plugin provides a connection to remote devices over the ``SSH NETCONF`` subsystem. Network devices typically use this connection plugin to send and receive ``RPC`` calls over ``NETCONF``." -msgstr ":ref:`netconf ` 接続プラグインは、``SSH NETCONF`` サブシステム経由でリモートデバイスへの接続を提供します。ネットワークデバイスは通常、この接続プラグインを使用して、``NETCONF`` で ``RPC`` 呼び出しを送受信します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:136 -msgid "The ``netconf`` connection plugin uses the ``ncclient`` Python library under the hood to initiate a NETCONF session with a NETCONF-enabled remote network device. ``ncclient`` also executes NETCONF RPC requests and receives responses. You must install the ``ncclient`` on the local Ansible controller." -msgstr "``netconf`` 接続プラグインは、Python ライブラリー ``ncclient`` を使用して、NETCONF が有効なリモートネットワークデバイスで NETCONF セッションを開始します。また、``ncclient`` は NETCONF RPC 要求を実行し、応答を受け取ります。ローカルの Ansible コントローラーに ``ncclient`` をインストールする必要があります。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:138 -msgid "To use the ``netconf`` connection plugin for network devices that support standard NETCONF (:RFC:`6241`) operations such as ``get``, ``get-config``, ``edit-config``, set ``ansible_network_os=default``. You can use :ref:`netconf_get `, :ref:`netconf_config ` and :ref:`netconf_rpc ` modules to talk to a NETCONF enabled remote host." -msgstr "``get``、``get-config``、``edit-config`` などの標準 NETCONF (:RFC:`6241`) 操作に対応するネットワークデバイスの ``netconf`` 接続プラグインを使用するには、``ansible_network_os=default`` を設定します。:ref:`netconf_get ` モジュール、:ref:`netconf_config ` モジュール、および :ref:`netconf_rpc ` モジュールを使用して、NETCONF が有効なリモートホストと通信できます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:141 -msgid "As a contributor and user, you should be able to use all the methods under the ``NetconfBase`` class if your device supports standard NETCONF. You can contribute a new plugin if the device you are working with has a vendor specific NETCONF RPC. To support a vendor specific NETCONF RPC, add the implementation in the network OS specific NETCONF plugin." -msgstr "デバイスが標準の NETCONF に対応している場合は、貢献者およびユーザーとして、``NetconfBase`` クラスのすべてのメソッドを使用できるようにする必要があります。作業しているデバイスにベンダー固有の NETCONF RPC がある場合は、新しいプラグインを提供できます。ベンダー固有の NETCONF RPC に対応するには、ネットワーク OS 固有の NETCONF プラグインに実装を追加します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:144 -msgid "For Junos for example:" -msgstr "たとえば、Junios の場合は以下のようになります。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:146 -msgid "See the vendor-specific Junos RPC methods implemented in ``plugins/netconf/junos.py``." -msgstr "``plugins/netconf/junos.py`` に実装されるベンダー固有の Junos RPC メソッドを参照してください。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:147 -msgid "Set the value of ``ansible_network_os`` to the name of the netconf plugin file, that is ``junos`` in this case." -msgstr "``ansible_network_os`` の値を netconf プラグインファイルの名前 (ここでは ``junos``) に設定します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:152 -msgid "Developing network_cli plugins" -msgstr "network_cli プラグインの開発" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:154 -msgid "The :ref:`network_cli ` connection type uses ``paramiko_ssh`` under the hood which creates a pseudo terminal to send commands and receive responses. ``network_cli`` loads two platform specific plugins based on the value of ``ansible_network_os``:" -msgstr "接続タイプ :ref:`network_cli ` は、コマンドを送信して応答を受け取るための疑似端末を作成するフード (hood) の下で、``paramiko_ssh`` を使用します。``network_cli`` は、``ansible_network_os`` の値に基づいて 2 つのプラットフォーム固有のプラグインを読み込みます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:157 -msgid "Terminal plugin (for example ``plugins/terminal/ios.py``) - Controls the parameters related to terminal, such as setting terminal length and width, page disabling and privilege escalation. Also defines regex to identify the command prompt and error prompts." -msgstr "端末のプラグイン (例: ``plugins/terminal/ios.py``) - 端末の長さや幅の設定、ページの無効化、権限の昇格など、端末に関連するパラメーターを制御します。また、正規表現を定義して、コマンドプロンプトおよびエラープロンプトを特定します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:159 -msgid ":ref:`cliconf_plugins` (for example, :ref:`ios cliconf `) - Provides an abstraction layer for low level send and receive operations. For example, the ``edit_config()`` method ensures that the prompt is in ``config`` mode before executing configuration commands." -msgstr ":ref:`cliconf_plugins` (例: :ref:`ios cliconf `) - 低レベルの送受信操作の抽象化レイヤーを提供します。たとえば、``edit_config()`` メソッドは、設定コマンドを実行する前にプロンプトが ``config`` モードになるようにします。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:161 -msgid "To contribute a new network operating system to work with the ``network_cli`` connection, implement the ``cliconf`` and ``terminal`` plugins for that network OS." -msgstr "新しいネットワークオペレーティングシステムが ``network_cli`` 接続と連携するようにするには、そのネットワーク OS の ``cliconf`` プラグインおよび ``terminal`` プラグインを実装します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:163 -msgid "The plugins can reside in:" -msgstr "このプラグインは以下の場所に置くことができます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:165 -msgid "Adjacent to playbook in folders" -msgstr "ディレクトリー内で Playbook に隣接" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:172 -msgid "Roles" -msgstr "ロール" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:179 -#: ../../rst/shared_snippets/basic_concepts.txt:17 -msgid "Collections" -msgstr "コレクション" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:186 -msgid "The user can also set the :ref:`DEFAULT_CLICONF_PLUGIN_PATH` to configure the ``cliconf`` plugin path." -msgstr "``cliconf`` プラグインパスを設定するために、ユーザーは :ref:`DEFAULT_CLICONF_PLUGIN_PATH` を設定することもできます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:188 -msgid "After adding the ``cliconf`` and ``terminal`` plugins in the expected locations, users can:" -msgstr "予想される場所に ``cliconf`` プラグインおよび ``terminal`` プラグインを追加したら、ユーザーは以下を行うことができます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:190 -msgid "Use the :ref:`cli_command ` to run an arbitrary command on the network device." -msgstr ":ref:`cli_command ` を使用して、ネットワークデバイス上で任意のコマンドを実行します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:191 -msgid "Use the :ref:`cli_config ` to implement configuration changes on the remote hosts without platform-specific modules." -msgstr ":ref:`cli_config ` を使用して、プラットフォーム固有のモジュールを使用しないリモートホストに設定変更を実装する。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:197 -msgid "Developing cli_parser plugins in a collection" -msgstr "コレクションでの cli_parser プラグインの開発" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:199 -msgid "You can use ``cli_parse`` as an entry point for a cli_parser plugin in your own collection." -msgstr "``cli_parse`` は、独自のコレクションで cli_parser プラグインのエントリーポイントとして使用できます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:202 -msgid "The following sample shows the start of a custom cli_parser plugin:" -msgstr "以下の例は、カスタム cli_parser プラグインの開始を示しています。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:245 -msgid "The following task uses this custom cli_parser plugin:" -msgstr "以下のタスクでは、このカスタム cli_parser プラグインを使用します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:255 -msgid "To develop a custom plugin: - Each cli_parser plugin requires a ``CliParser`` class. - Each cli_parser plugin requires a ``parse`` function. - Always return a dictionary with ``errors`` or ``parsed``. - Place the custom cli_parser in plugins/cli_parsers directory of the collection. - See the `current cli_parsers `_ for examples to follow." -msgstr "カスタムプラグインを開発するには: - 各 cli_parser プラグインには ``CliParser`` クラスが必要です。- 各 cli_parser プラグインには ``parse`` 関数が必要です。- 常に ``errors`` または ``parsed`` でディクショナリーを返します。コレクションの plugins/cli_parsers ディレクトリーにカスタムの cli_parser を置きます。例は `現在の cli_parsers ` を参照してください。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:265 -msgid ":ref:`cli_parsing`" -msgstr ":ref:`cli_parsing`" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:6 -msgid "Developing network resource modules" -msgstr "ネットワークリソースモジュールの開発" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:13 -msgid "Understanding network and security resource modules" -msgstr "ネットワークおよびセキュリティーのリソースモジュールの概要" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:15 -msgid "Network and security devices separate configuration into sections (such as interfaces, VLANs, and so on) that apply to a network or security service. Ansible resource modules take advantage of this to allow users to configure subsections or resources within the device configuration. Resource modules provide a consistent experience across different network and security devices. For example, a network resource module may only update the configuration for a specific portion of the network interfaces, VLANs, ACLs, and so on for a network device. The resource module:" -msgstr "ネットワークデバイスおよびセキュリティーデバイスは、その設定を、ネットワークサービスまたはセキュリティーサービスに適用されるセクション (インターフェース、VLAN など) に分割します。Ansible リソースモジュールはこれを利用して、ユーザーがデバイス設定でサブセクションやリソースを設定できるようにします。リソースモジュールは、異なるネットワークおよびセキュリティーデバイス全体で一貫したエクスペリエンスを提供します。たとえば、ネットワークリソースモジュールは、ネットワークインターフェース、VLAN、ACL などの特定の部分に対して設定を更新することができます。リソースモジュールは、以下を行います。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:17 -msgid "Fetches a piece of the configuration (fact gathering), for example, the interfaces configuration." -msgstr "インターフェース設定など、設定の一部 (ファクト収集) を取得します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:18 -msgid "Converts the returned configuration into key-value pairs." -msgstr "返された設定をキーと値のペアに変換します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:19 -msgid "Places those key-value pairs into an internal agnostic structured data format." -msgstr "これらのキーと値のペアを内部に依存しない構造化データ形式に置きます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:21 -msgid "Now that the configuration data is normalized, the user can update and modify the data and then use the resource module to send the configuration data back to the device. This results in a full round-trip configuration update without the need for manual parsing, data manipulation, and data model management." -msgstr "設定データが正規化され、ユーザーはデータを更新して変更し、リソースモジュールを使用して設定データをデバイスに戻すことができます。これにより、手動の解析、データ操作、およびデータモデル管理を必要とせずに、完全なラウンドトリップ設定の更新が可能になります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:23 -msgid "The resource module has two top-level keys - ``config`` and ``state``:" -msgstr "リソースモジュールには、``config`` と ``state`` の 2 つのトップレベルキーがあります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:25 -msgid "``config`` defines the resource configuration data model as key-value pairs. The type of the ``config`` option can be ``dict`` or ``list of dict`` based on the resource managed. That is, if the device has a single global configuration, it should be a ``dict`` (for example, a global LLDP configuration). If the device has multiple instances of configuration, it should be of type ``list`` with each element in the list of type ``dict`` (for example, interfaces configuration)." -msgstr "``config`` は、リソース設定のデータモデルをキーと値のペアとして定義します。``config`` オプションのタイプは、管理されるリソースに基づいて ``dict`` または ``list of dict`` になります。つまり、デバイスにグローバル設定が 1 つある場合には、``dict`` でなければなりません (例: グローバル LLDP 設定)。デバイスに複数の設定インスタンスがある場合は、タイプが ``list`` となり、リストの各要素はタイプが ``dict`` である必要があります (例: インターフェース設定)。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:28 -msgid "``state`` defines the action the resource module takes on the end device." -msgstr "``state`` リソースモジュールがエンドデバイスで使用するアクションを定義します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:30 -msgid "The ``state`` for a new resource module should support the following values (as applicable for the devices that support them):" -msgstr "新しいリソースモジュールの ``state`` は、以下の値をサポートする必要があります (サポートするデバイスに該当する場合)。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:33 -#: ../../rst/network/user_guide/network_resource_modules.rst:19 -msgid "merged" -msgstr "merged" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:33 -#: ../../rst/network/user_guide/network_resource_modules.rst:19 -msgid "Ansible merges the on-device configuration with the provided configuration in the task." -msgstr "Ansible は、デバイス上の設定をタスクに指定した設定と統合します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:36 -#: ../../rst/network/user_guide/network_resource_modules.rst:22 -msgid "replaced" -msgstr "replaced" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:36 -#: ../../rst/network/user_guide/network_resource_modules.rst:22 -msgid "Ansible replaces the on-device configuration subsection with the provided configuration subsection in the task." -msgstr "Ansible が、デバイス上の設定のサブセクションを、タスクに指定した設定のサブセクションに置き換えます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:39 -#: ../../rst/network/user_guide/network_resource_modules.rst:25 -msgid "overridden" -msgstr "overridden" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:39 -#: ../../rst/network/user_guide/network_resource_modules.rst:25 -msgid "Ansible overrides the on-device configuration for the resource with the provided configuration in the task. Use caution with this state as you could remove your access to the device (for example, by overriding the management interface configuration)." -msgstr "Ansible は、リソースのデバイスの設定を、タスクで提供された設定を使用して上書きします。この状態では、デバイスへのアクセスが削除される可能性があるため、注意が必要です (たとえば、管理インターフェイスの設定を上書きするなど)。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:42 -#: ../../rst/network/user_guide/network_resource_modules.rst:28 -msgid "deleted" -msgstr "deleted" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:42 -#: ../../rst/network/user_guide/network_resource_modules.rst:28 -msgid "Ansible deletes the on-device configuration subsection and restores any default settings." -msgstr "Ansible は、デバイス上の設定サブセクションを削除して、デフォルト設定を復元します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:45 -#: ../../rst/network/user_guide/network_resource_modules.rst:31 -msgid "gathered" -msgstr "gathered" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:45 -#: ../../rst/network/user_guide/network_resource_modules.rst:31 -msgid "Ansible displays the resource details gathered from the network device and accessed with the ``gathered`` key in the result." -msgstr "Ansible は、ネットワークデバイスから収集したリソースの詳細を表示し、結果の ``gathered`` キーを使用してアクセスします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:48 -#: ../../rst/network/user_guide/network_resource_modules.rst:34 -msgid "rendered" -msgstr "rendered" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:48 -#: ../../rst/network/user_guide/network_resource_modules.rst:34 -msgid "Ansible renders the provided configuration in the task in the device-native format (for example, Cisco IOS CLI). Ansible returns this rendered configuration in the ``rendered`` key in the result. Note this state does not communicate with the network device and can be used offline." -msgstr "Ansible は、デバイスネイティブの形式でタスク内の提供された設定をレンダリングします (例: Cisco IOS CLI)。Ansible は、結果内の ``rendered`` キーでレンダリングされた設定を返します。この状態はネットワークデバイスと通信せず、オフラインで使用できる点に注意してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:52 -#: ../../rst/network/user_guide/network_resource_modules.rst:37 -msgid "parsed" -msgstr "parsed" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:51 -#: ../../rst/network/user_guide/network_resource_modules.rst:37 -msgid "Ansible parses the configuration from the ``running_configuration`` option into Ansible structured data in the ``parsed`` key in the result. Note this does not gather the configuration from the network device so this state can be used offline." -msgstr "Ansible は、``running_configuration`` オプションから、その結果内の ``parsed`` キーの Ansible 構造化データに設定を解析します。この設定は、ネットワークデバイスから設定が収集されないため、この状態をオフラインで使用できる点に注意してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:54 -msgid "Modules in Ansible-maintained collections must support these state values. If you develop a module with only \"present\" and \"absent\" for state, you may submit it to a community collection." -msgstr "Ansible が管理しているコレクションのモジュールは、これらの状態値をサポートする必要があります。状態が「present」および「absent」のモジュールを開発した場合は、コミュニティーコレクションに提出することができます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:58 -msgid "The states ``rendered``, ``gathered``, and ``parsed`` do not perform any change on the device." -msgstr "状態 ``rendered``、``gathered``、および ``parsed`` はデバイス上で変更を行いません。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:62 -msgid "`Deep Dive on VLANs Resource Modules for Network Automation `_" -msgstr "`Deep Dive on VLANs Resource Modules for Network Automation `_" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:63 -msgid "Walkthrough of how state values are implemented for VLANs." -msgstr "VLAN への状態値の実装方法のウォールスルー" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:67 -msgid "Developing network and security resource modules" -msgstr "ネットワークおよびセキュリティーのリソースモジュールの開発" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:69 -msgid "The Ansible Engineering team ensures the module design and code pattern within Ansible-maintained collections is uniform across resources and across platforms to give a vendor-agnostic feel and deliver good quality code. We recommend you use the `resource module builder `_ to develop a resource module." -msgstr "Ansible Engineering チームは、Ansible が管理しているコレクション内のモジュール設計およびコードパターンがリソースやプラットフォーム全体で統一され、ベンダーに依存せず、適切な品質コードを提供します。`リソースモジュールビルダー `_ を使用してリソースモジュールを開発することが推奨されます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:72 -msgid "The highlevel process for developing a resource module is:" -msgstr "リソースモジュール開発の主なプロセスは次のとおりです。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:74 -msgid "Create and share a resource model design in the `resource module models repository `_ as a PR for review." -msgstr "レビュー用にプル要求として、`リソースモジュールモデルリポジトリー `_ でリソースモデルの設計を作成し、共有します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:75 -msgid "Download the latest version of the `resource module builder `_." -msgstr "最新バージョンの `リソースモジュールビルダー `_ をダウンロードします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:76 -msgid "Run the ``resource module builder`` to create a collection scaffold from your approved resource model." -msgstr "``リソースモジュールビルダー`` を実行して、承認されたリソースモデルからコレクションのスキャフォールディングを作成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:77 -msgid "Write the code to implement your resource module." -msgstr "コードを作成し、リソースモジュールを実装します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:78 -msgid "Develop integration and unit tests to verify your resource module." -msgstr "統合テストおよびユニットテストを開発して、リソースモジュールを確認します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:79 -msgid "Create a PR to the appropriate collection that you want to add your new resource module to. See :ref:`contributing_maintained_collections` for details on determining the correct collection for your module." -msgstr "新しいリソースモジュールを追加する適切なコレクションにプル要求を作成します。モジュールの正しいコレクションを判断する方法は「:ref:`contributing_maintained_collections`」を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:83 -msgid "Understanding the model and resource module builder" -msgstr "モデルおよびリソースモジュールビルダーの理解" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:85 -msgid "The resource module builder is an Ansible Playbook that helps developers scaffold and maintain an Ansible resource module. It uses a model as the single source of truth for the module. This model is a ``yaml`` file that is used for the module DOCUMENTATION section and the argument spec." -msgstr "リソースモジュールビルダーは、開発者が Ansible リソースモジュールをスキャフォールディングし、維持できるようにする Ansible Playbook です。このモデルは、モジュールの信頼できる唯一のソースとして使用します。このモデルは、モジュールの DOCUMENTATION セクションおよび引数仕様に使用される ``yaml`` ファイルです。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:87 -msgid "The resource module builder has the following capabilities:" -msgstr "リソースモジュールビルダーには以下の機能があります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:89 -msgid "Uses a defined model to scaffold a resource module directory layout and initial class files." -msgstr "定義されたモデルを使用して、リソースモジュールディレクトリーのレイアウトと初期クラスファイルをスキャフォールディングします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:90 -msgid "Scaffolds either an Ansible role or a collection." -msgstr "Ansible ロールまたはコレクションのいずれかをスキャフォールディングします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:91 -msgid "Subsequent uses of the resource module builder will only replace the module arspec and file containing the module docstring." -msgstr "その後、リソースモジュールビルダーを使用すると、モジュールの arspec と、モジュールの docstring を含むファイルのみが置き換えられます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:92 -msgid "Allows you to store complex examples along side the model in the same directory." -msgstr "複雑なサンプルモデルと同じディレクトリーに保存できます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:93 -msgid "Maintains the model as the source of truth for the module and use resource module builder to update the source files as needed." -msgstr "モジュールの信頼できるソースとしてこのモデルを維持し、必要に応じてリソースモジュールビルダーを使用してソースファイルを更新します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:94 -msgid "Generates working sample modules for both ``_`` and ``_facts``." -msgstr "``_`` および ``_facts`` の両方に作業サンプルモジュールを生成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:97 -msgid "Accessing the resource module builder" -msgstr "リソースモジュールビルダーへのアクセス" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:99 -msgid "To access the resource module builder:" -msgstr "リソースモジュールビルダーにアクセスするには、以下を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:101 -msgid "clone the github repository:" -msgstr "github リポジトリーのクローンを作成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:107 -msgid "Install the requirements:" -msgstr "要件をインストールします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:114 -msgid "Creating a model" -msgstr "モデルの作成" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:116 -msgid "You must create a model for your new resource. The model is the single source of truth for both the argspec and docstring, keeping them in sync. Once your model is approved, you can use the resource module builder to generate three items based on the model:" -msgstr "新しいリソースのモデルを作成する必要があります。モデルは、argspec と docstring の両方に対する信頼できる唯一のソースとなります。モデルが承認されると、リソースモジュールビルダーを使用して、このモデルに基づいて 3 つのアイテムを生成できます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:118 -msgid "The scaffold for a new module" -msgstr "新しいモジュールのスキャフォールディング" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:119 -msgid "The argspec for the new module" -msgstr "新しいモジュールの argspec" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:120 -msgid "The docstring for the new module" -msgstr "新しいモジュールの docstring" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:122 -msgid "For any subsequent changes to the functionality, update the model first and use the resource module builder to update the module argspec and docstring." -msgstr "その後、機能に対する変更を行う場合は、最初にモデルを更新し、リソースモジュールビルダーを使用してモジュールの argspec および docstring を更新します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:124 -msgid "For example, the resource model builder includes the ``myos_interfaces.yml`` sample in the :file:`models` directory, as seen below:" -msgstr "たとえば、リソースモデルビルダーには、以下のように :file:`models` ディレクトリーに ``myos_interfaces.yml`` サンプルが含まれます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:196 -msgid "Notice that you should include examples for each of the states that the resource supports. The resource module builder also includes these in the sample model." -msgstr "リソースがサポートする各状態の例を含める必要があることに注意してください。リソースモジュールビルダーには、サンプルモデルにもこれらが含まれます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:198 -msgid "Share this model as a PR for review at `resource module models repository `_. You can also see more model examples at that location." -msgstr "このモデルは、`リソースモジュールモデルのリポジトリー `_ で確認するための PR として共有します。この場所でさらにモデルのサンプルを表示することもできます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:202 -msgid "Creating a collection scaffold from a resource model" -msgstr "リソースモデルからのコレクションのスキャフォールディングの作成" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:204 -msgid "To use the resource module builder to create a collection scaffold from your approved resource model:" -msgstr "リソースモジュールビルダーを使用して、認証されたリソースモデルからコレクションのスキャフォールディングを作成するには、以下を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:215 -msgid "Where the parameters are as follows:" -msgstr "パラメーターは以下のようになります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:217 -msgid "``rm_dest``: The directory where the resource module builder places the files and directories for the resource module and facts modules." -msgstr "``rm_dest``: リソースモジュールビルダーが、リソースモジュールおよびファクトモジュールのファイルおよびディレクトリーを置くディレクトリー。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:218 -msgid "``structure``: The directory layout type (role or collection)" -msgstr "``structure``: ディレクトリーレイアウトの種類 (ロールまたはコレクション)。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:220 -msgid "``role``: Generate a role directory layout." -msgstr "``role``: ロールディレクトリーレイアウトを生成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:221 -msgid "``collection``: Generate a collection directory layout." -msgstr "``collection``: コレクションディレクトリーのレイアウトを生成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:223 -msgid "``collection_org``: The organization of the collection, required when `structure=collection`." -msgstr "``collection_org``: `structure=collection` の場合にコレクションの組織が必要です。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:224 -msgid "``collection_name``: The name of the collection, required when `structure=collection`." -msgstr "``collection_name``: `structure=collection` の場合に必要となるコレクションの名前です。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:225 -msgid "``model``: The path to the model file." -msgstr "``model``: モデルファイルへのパス。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:227 -msgid "To use the resource module builder to create a role scaffold:" -msgstr "リソースモジュールビルダーを使用してロールのスキャフォールディングを作成するには、以下を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:237 -msgid "Examples" -msgstr "例" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:240 -msgid "Collection directory layout" -msgstr "コレクションディレクトリーのレイアウト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:242 -msgid "This example shows the directory layout for the following:" -msgstr "この例では、以下のようなディレクトリーレイアウトを示しています。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:244 -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:306 -msgid "``network_os``: myos" -msgstr "``network_os``: myos" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:245 -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:307 -msgid "``resource``: interfaces" -msgstr "``resource``: interfaces" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:302 -msgid "Role directory layout" -msgstr "ロールディレクトリーのレイアウト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:304 -msgid "This example displays the role directory layout for the following:" -msgstr "この例では、以下のロールのディレクトリーレイアウトを表示しています。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:358 -msgid "Using the collection" -msgstr "コレクションの使用" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:360 -msgid "This example shows how to use the generated collection in a playbook:" -msgstr "以下の例は、生成されたコレクションを Playbook で使用する方法を示しています。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:378 -msgid "Using the role" -msgstr "ロールの使用" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:380 -msgid "This example shows how to use the generated role in a playbook:" -msgstr "以下の例は、生成されたロールを Playbook で使用する方法を示しています。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:402 -msgid "Resource module structure and workflow" -msgstr "リソースモジュール構造およびワークフロー" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:404 -msgid "The resource module structure includes the following components:" -msgstr "リソースモジュール構造には、以下のコンポーネントが含まれます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:413 -msgid "Module" -msgstr "モジュール" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:407 -msgid "``library/_.py``." -msgstr "``library/_.py``。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:408 -msgid "Imports the ``module_utils`` resource package and calls ``execute_module`` API:" -msgstr "``module_utils`` リソースパッケージをインポートし、``execute_module`` API を呼び出します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:417 -msgid "Module argspec" -msgstr "モジュールの argspec" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:416 -msgid "``module_utils//argspec//``." -msgstr "``module_utils//argspec//``。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:417 -msgid "Argspec for the resource." -msgstr "リソースの argspec" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:423 -msgid "Facts" -msgstr "ファクト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:420 -msgid "``module_utils//facts//``." -msgstr "``module_utils//facts//``。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:421 -msgid "Populate facts for the resource." -msgstr "リソースのファクトを入力します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:422 -msgid "Entry in ``module_utils//facts/facts.py`` for ``get_facts`` API to keep ``_facts`` module and facts gathered for the resource module in sync for every subset." -msgstr "すべてのサブセットに対して同期するリソースモジュール用に収集された ``_facts`` モジュールおよびファクトを保持する ``get_facts`` API の ``module_utils//facts/facts.py`` エントリー。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:423 -msgid "Entry of Resource subset in FACTS_RESOURCE_SUBSETS list in ``module_utils//facts/facts.py`` to make facts collection work." -msgstr "``module_utils//facts/facts.py`` の FACTS_RESOURCE_SUBSETS 一覧でリソースサブセットのエントリー。ファクトコレクションを機能させます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:430 -msgid "Module package in module_utils" -msgstr "module_utils のモジュールパッケージ" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:426 -msgid "``module_utils////``." -msgstr "``module_utils////``。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:427 -msgid "Implement ``execute_module`` API that loads the configuration to device and generates the result with ``changed``, ``commands``, ``before`` and ``after`` keys." -msgstr "設定を読み込む ``execute_module`` API を実装し、``changed`` キー、``commands`` キー、``before`` キー、および ``after`` キーで結果を生成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:428 -msgid "Call ``get_facts`` API that returns the ```` configuration facts or return the difference if the device has onbox diff support." -msgstr "```` 設定のファクトを返す ``get_facts`` API を呼び出すか、デバイスに onbox diff サポートがある場合はその相違点を返します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:429 -msgid "Compare facts gathered and given key-values if diff is not supported." -msgstr "diff がサポートされていない場合は、収集されるファクトと、指定されるキー/値を比較します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:430 -msgid "Generate final configuration." -msgstr "最後の設定を生成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:434 -msgid "Utils" -msgstr "ユーティリティー" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:433 -msgid "``module_utils//utils``." -msgstr "``module_utils//utils``。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:434 -msgid "Utilities for the ```` platform." -msgstr "```` プラットフォームのユーティリティー。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:439 -msgid "Running ``ansible-test sanity`` and ``tox`` on resource modules" -msgstr "リソースモジュールでの ``ansible-test sanity`` および ``tox`` の実行" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:441 -msgid "You should run ``ansible-test sanity`` and ``tox -elinters`` from the collection root directory before pushing your PR to an Ansible-maintained collection. The CI runs both and will fail if these tests fail. See :ref:`developing_testing` for details on ``ansible-test sanity``." -msgstr "プル要求を Ansible で管理されたコレクションにプッシュする前に、コレクションルートディレクトリーから ``ansible-test sanity`` および ``tox -elinters`` を実行する必要があります。CI はその両方を実行し、このテストに失敗すると失敗します。``ansible-test sanity`` の詳細は、「:ref:`developing_testing`」を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:443 -msgid "To install the necessary packages:" -msgstr "必要なパッケージをインストールするには、以下を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:445 -msgid "Ensure you have a valid Ansible development environment configured. See :ref:`environment_setup` for details." -msgstr "有効な Ansible 開発環境が設定されていることを確認してください。詳細は :ref:`environment_setup` を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:446 -msgid "Run ``pip install -r requirements.txt`` from the collection root directory." -msgstr "コレクションの root ディレクトリーから ``pip install -r requirements.txt`` を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:449 -msgid "Running ``tox -elinters``:" -msgstr "``tox -elinters`` の実行:" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:451 -msgid "Reads :file:`tox.ini` from the collection root directory and installs required dependencies (such as ``black`` and ``flake8``)." -msgstr "コレクションルートディレクトリーから :file:`tox.ini` を読み込み、必要な依存関係 (例: ``black``、``flake8``) をインストールします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:452 -msgid "Runs these with preconfigured options (such as line-length and ignores.)" -msgstr "事前設定されたオプション (line-length や ignore など) を指定して、これらのコマンドを実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:453 -msgid "Runs ``black`` in check mode to show which files will be formatted without actually formatting them." -msgstr "``black`` をチェックモードで実行し、実際にフォーマットされることなくどのファイルをフォーマットするかを表示します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:456 -msgid "Testing resource modules" -msgstr "リソースモジュールのテスト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:458 -msgid "The tests rely on a role generated by the resource module builder. After changes to the resource module builder, the role should be regenerated and the tests modified and run as needed. To generate the role after changes:" -msgstr "テストは、リソースモジュールビルダーが生成したロールに依存します。リソースモジュールビルダーへの変更後に、ロールを再生成し、必要に応じてテストが変更され、実行される必要があります。変更後にロールを生成するには、以下を行います。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:472 -msgid "Resource module integration tests" -msgstr "リソースモジュール統合テスト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:474 -msgid "High-level integration test requirements for new resource modules are as follows:" -msgstr "新しいリソースモジュールのハイレベル統合テスト要件は次のとおりです。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:476 -msgid "Write a test case for every state." -msgstr "すべての状態についてテストケースを作成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:477 -msgid "Write additional test cases to test the behavior of the module when an empty ``config.yaml`` is given." -msgstr "空の ``config.yaml`` が指定されている場合にモジュールの動作をテストするために、追加のテストケースを作成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:478 -msgid "Add a round trip test case. This involves a ``merge`` operation, followed by ``gather_facts``, a ``merge`` update with additional configuration, and then reverting back to the base configuration using the previously gathered facts with the ``state`` set to ``overridden``." -msgstr "ラウンドトリップテストケースを追加します。これには ``merge`` の操作が含まれ、続いて ``gather_facts`` 、``merge`` が追加の構成で更新され、その後、``state`` が ``overridden`` に設定された状態で、以前に収集したファクトを使用して基本構成に戻ります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:479 -msgid "Wherever applicable, assertions should check after and before ``dicts`` against a hard coded Source of Truth." -msgstr "該当する場合、アサーションは、ハードコードされた信頼できる唯一のソースに対して ``dicts`` の前後で確認する必要があります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:483 -msgid "We use Zuul as the CI to run the integration test." -msgstr "Zuul を CI として使用し、統合テストを実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:485 -msgid "To view the report, click :guilabel:`Details` on the CI comment in the PR" -msgstr "レポートを表示するには、プル要求の CI コメントにある :guilabel:`Details` をクリックします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:486 -msgid "To view a failure report, click :guilabel:`ansible/check` and select the failed test." -msgstr "障害レポートを表示するには、:guilabel:`ansible/check` をクリックし、失敗したテストを選択します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:487 -msgid "To view logs while the test is running, check for your PR number in the `Zull status board `_." -msgstr "テストの実行中にログを表示するには、`Zull 状態ボード `_ で プル要求番号を確認します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:488 -msgid "To fix static test failure locally, run the :command:`tox -e black` **inside the root folder of collection**." -msgstr "静的テストの失敗をローカルで修正するには、:command:`tox -e black` を、**コレクションのルートディレクトリー内** で実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:490 -msgid "To view The Ansible run logs and debug test failures:" -msgstr "Ansible の実行ログおよびデバッグテストの失敗を表示するには、以下を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:492 -msgid "Click the failed job to get the summary, and click :guilabel:`Logs` for the log." -msgstr "失敗したジョブをクリックしてサマリーを取得し、ログの :guilabel:`Logs` をクリックします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:493 -msgid "Click :guilabel:`console` and scroll down to find the failed test." -msgstr ":guilabel:`console` をクリックし、スクロールダウンして失敗したテストを見つけます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:494 -msgid "Click :guilabel:`>` next to the failed test for complete details." -msgstr "詳細は、失敗したテストの横にある :guilabel:`>` をクリックします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:498 -msgid "Integration test structure" -msgstr "統合テスト構造" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:500 -msgid "Each test case should generally follow this pattern:" -msgstr "通常、各テストケースは、以下のパターンに従います。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:502 -msgid "setup —> test —> assert —> test again (for idempotency) —> assert —> tear down (if needed) -> done. This keeps test playbooks from becoming monolithic and difficult to troubleshoot." -msgstr "設定 —> テスト —> アサート —> 再テスト (冪等性) —> アサート —> 分解 (必要な場合) -> 完了。これにより、テスト Playbook がモノリシックになり、トラブルシューティングが困難になります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:503 -msgid "Include a name for each task that is not an assertion. You can add names to assertions as well, but it is easier to identify the broken task within a failed test if you add a name for each task." -msgstr "アサーションではない各タスクの名前を含めます。名前をアサーションに追加できますが、各タスクの名前を追加すると、失敗したテスト内では、破損したタスクを特定するのが容易になります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:504 -msgid "Files containing test cases must end in ``.yaml``" -msgstr "テストケースを含むファイルは ``.yaml`` で終了する必要があります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:507 -msgid "Implementation" -msgstr "実装" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:509 -msgid "For platforms that support ``connection: local`` *and* ``connection: network_cli`` use the following guidance:" -msgstr "``connection: local`` *および* ``connection: network_cli`` をサポートするプラットフォームについては、以下のガイダンスを使用します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:511 -msgid "Name the :file:`targets/` directories after the module name." -msgstr "モジュール名の後に :file:`targets/` ディレクトリーに名前を付けます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:512 -msgid "The :file:`main.yaml` file should just reference the transport." -msgstr ":file:`main.yaml` ファイルは、トランスポートを参照するだけです。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:514 -msgid "The following example walks through the integration tests for the ``vyos.vyos.vyos_l3_interfaces`` module in the `vyos.vyos `_ collection:" -msgstr "以下の例では、`vyos.vyos `_ コレクションの ``vyos.vyos.vyos_l3_interfaces`` モジュールの統合テストを行います。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:516 -msgid "``test/integration/targets/vyos_l3_interfaces/tasks/main.yaml``" -msgstr "``test/integration/targets/vyos_l3_interfaces/tasks/main.yaml``" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:525 -msgid "``test/integration/targets/vyos_l3_interfaces/tasks/cli.yaml``" -msgstr "``test/integration/targets/vyos_l3_interfaces/tasks/cli.yaml``" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:552 -msgid "``test/integration/targets/vyos_l3_interfaces/tests/cli/overridden.yaml``" -msgstr "``test/integration/targets/vyos_l3_interfaces/tests/cli/overridden.yaml``" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:620 -msgid "Detecting test resources at runtime" -msgstr "ランタイム時のテストリソースの検出" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:622 -msgid "Your tests should detect resources (such as interfaces) at runtime rather than hard-coding them into the test. This allows the test to run on a variety of systems." -msgstr "テストは、(インターフェースなどの) リソースをテストにハードコーディングするのではなく、ランタイム時にリソースを検出する必要があります。これにより、テストはさまざまなシステムで実行できます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:624 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:203 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:262 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:298 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:327 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:358 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:405 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:611 -msgid "For example:" -msgstr "たとえば、以下のようになります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:648 -msgid "See the complete test example of this at https://github.com/ansible-collections/cisco.nxos/blob/main/tests/integration/targets/prepare_nxos_tests/tasks/main.yml." -msgstr "https://github.com/ansible-collections/cisco.nxos/blob/main/tests/integration/targets/prepare_nxos_tests/tasks/main.yml. で、このテストの完全例を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:652 -msgid "Running network integration tests" -msgstr "ネットワーク統合テストの実行" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:654 -msgid "Ansible uses Zuul to run an integration test suite on every PR, including new tests introduced by that PR. To find and fix problems in network modules, run the network integration test locally before you submit a PR." -msgstr "Ansible は Zuul を使用して、すべてのプル要求で、プル要求によって導入された新規テストを含む統合テストスイートを実行します。ネットワークモジュールで問題を特定して修正するには、プル要求を送信する前にネットワーク統合テストをローカルで実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:657 -msgid "First, create an inventory file that points to your test machines. The inventory group should match the platform name (for example, ``eos``, ``ios``):" -msgstr "まず、テストマシンを参照するインベントリーファイルを作成します。インベントリーグループは、プラットフォーム名と一致する必要があります (例: ``eos``、``ios``)。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:666 -msgid "To run these network integration tests, use ``ansible-test network-integration --inventory     ``:" -msgstr "これらのネットワーク統合テストを実行するには、``ansible-test network-integration --inventory     `` を使用します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:675 -msgid "To run all network tests for a particular platform:" -msgstr "特定のプラットフォームでネットワークテストをすべて実行するには、次を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:681 -msgid "This example will run against all ``vyos`` modules. Note that ``vyos_.*`` is a regex match, not a bash wildcard - include the `.` if you modify this example." -msgstr "この例は、すべての ``vyos`` モジュールに対して実行します。``vyos_.*`` は、bash ワイルドカードではなく、正規表現一致であることに注意してください。この例を修正する場合は `.` を含むようにしてください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:683 -msgid "To run integration tests for a specific module:" -msgstr "特定のモジュールに対して統合テストを実行するには、次を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:689 -msgid "To run a single test case on a specific module:" -msgstr "特定のモジュールでテストケースを 1 つ実行するには、次を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:696 -msgid "To run integration tests for a specific transport:" -msgstr "特定のトランスポートで統合テストを実行するには、次を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:706 -msgid "See `test/integration/targets/nxos_bgp/tasks/main.yaml `_ for how this is implemented in the tests." -msgstr "テストに実装される方法は、「`test/integration/targets/nxos_bgp/tasks/main.yaml `_」を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:708 -msgid "For more options:" -msgstr "その他のオプション:" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:714 -msgid "If you need additional help or feedback, reach out in ``#ansible-network`` on Freenode." -msgstr "本書で示したもの以外にヘルプやフィードバックが必要な場合は、Freenode の ``#ansible-network`` にアクセスしてください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:717 -msgid "Unit test requirements" -msgstr "ユニットテストの要件" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:719 -msgid "High-level unit test requirements that new resource modules should follow:" -msgstr "新しいリソースモジュールが従う高レベルのユニットテスト要件は以下のようになります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:721 -msgid "Write test cases for all the states with all possible combinations of config values." -msgstr "設定値の組み合わせ可能なすべての状態についてテストケースを作成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:722 -msgid "Write test cases to test the error conditions ( negative scenarios)." -msgstr "テストケースを作成し、エラー条件 (負のシナリオ) をテストします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:723 -msgid "Check the value of ``changed`` and ``commands`` keys in every test case." -msgstr "すべてのテストケースで ``changed`` キーおよび ``commands`` キーの値を確認します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:725 -msgid "We run all unit test cases on our Zuul test suite, on the latest python version supported by our CI setup." -msgstr "CI 設定でサポートされる最新の python バージョンで、Zuul テストスイートですべてのユニットテストケースを実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:727 -msgid "Use the :ref:`same procedure ` as the integration tests to view Zuul unit tests reports and logs." -msgstr ":ref:`同じ手順 ` を統合テストとして使用し、Zuul ユニットテストのレポートおよびログを表示します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:729 -msgid "See :ref:`unit module testing ` for general unit test details." -msgstr "一般的なユニットテストの詳細は、「:ref:`ユニットモジュールのテスト `」を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:735 -msgid "Example: Unit testing Ansible network resource modules" -msgstr "例: Ansible ネットワークリソースモジュールのユニットテスト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:738 -msgid "This section walks through an example of how to develop unit tests for Ansible resource modules." -msgstr "本セクションでは、Ansible リソースモジュールのユニットテストを開発する方法の例を説明します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:741 -msgid "See :ref:`testing_units` and :ref:`testing_units_modules` for general documentation on Ansible unit tests for modules. Please read those pages first to understand unit tests and why and when you should use them." -msgstr "モジュール向けの Ansible ユニットテストの一般的なドキュメントは、「:ref:`testing_units`」および「:ref:`testing_units_modules`」を参照してください。ユニットテスト、および使用する理由およびその方法を理解するには、まずこれらのページをお読みください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:746 -msgid "Using mock objects to unit test Ansible network resource modules" -msgstr "モック (模擬) オブジェクトを使用した Ansible ネットワークリソースモジュールのユニットテスト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:749 -msgid "`Mock objects `_ can be very useful in building unit tests for special or difficult cases, but they can also lead to complex and confusing coding situations. One good use for mocks would be to simulate an API. The ``mock`` Python package is bundled with Ansible (use ``import units.compat.mock``)." -msgstr "`モックオブジェクト `_ は、特殊なケースや難しいケースのユニットテストを構築するのに非常に便利ですが、複雑で理解しづらいコーディングになってしまうこともあります。モックの使用方法として適切なものの 1 つに、API のシミュレートがあります。``mock`` Python パッケージは、Ansible にバンドルされています (``import units.compat.mock`` を使用)。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:755 -msgid "You can mock the device connection and output from the device as follows:" -msgstr "以下のように、デバイスの接続とデバイスからの出力を模倣できます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:789 -msgid "The facts file of the module now includes a new method, ``get_device_data``. Call ``get_device_data`` here to emulate the device output." -msgstr "モジュールのファクトファイルに新しいメソッド ``get_device_data`` が追加されました。ここで ``get_device_data`` を呼び出して、デバイスの出力をエミュレートします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:793 -msgid "Mocking device data" -msgstr "デバイスデータの模倣" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:795 -msgid "To mock fetching results from devices or provide other complex data structures that come from external libraries, you can use ``fixtures`` to read in pre-generated data. The text files for this pre-generated data live in ``test/units/modules/network/PLATFORM/fixtures/``. See for example the `eos_l2_interfaces.cfg file `_." -msgstr "デバイスからの結果の取得や、外部ライブラリーからの複雑なデータ構造の提供を模倣するために、``fixtures`` を使用して事前に生成されたデータを読み込むことができます。この事前に生成されたデータのテキストファイルは、``test/units/modules/network/PLATFORM/fixtures/`` にあります。たとえば、`eos_l2_interfaces.cfg file `_ の例を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:798 -msgid "Load data using the ``load_fixture`` method and set this data as the return value of the ``get_device_data`` method in the facts file:" -msgstr "``load_fixture`` メソッドを使用してデータを読み込み、このデータをファクトファイルの ``get_device_data`` メソッドの戻り値として設定します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:808 -msgid "See the unit test file `test_eos_l2_interfaces `_ for a practical example." -msgstr "実用的な例は、ユニットテストファイル `test_eos_l2_interfaces `_ を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:814 -msgid ":ref:`testing_units`" -msgstr ":ref:`testing_units`" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:815 -msgid "Deep dive into developing unit tests for Ansible modules" -msgstr "Ansible モジュールのユニットテスト開発を深く掘り下げて調査" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:816 -msgid ":ref:`testing_running_locally`" -msgstr ":ref:`testing_running_locally`" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:817 -msgid "Running tests locally including gathering and reporting coverage data" -msgstr "カバレージデータの収集とレポートを含む、ローカルでのテストの実行" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:818 -msgid ":ref:`developing_modules_general`" -msgstr ":ref:`developing_modules_general`" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:819 -msgid "Get started developing a module" -msgstr "モジュール開発を始める" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:6 -msgid "Documenting new network platforms" -msgstr "新しいネットワークプラットフォームのドキュメント化" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:11 -msgid "When you create network modules for a new platform, or modify the connections provided by an existing network platform(such as ``network_cli`` and ``httpapi``), you also need to update the :ref:`settings_by_platform` table and add or modify the Platform Options file for your platform." -msgstr "新しいプラットフォーム用のネットワークモジュールを作成する場合や、既存のネットワークプラットフォーム (``network_cli``、``httpapi`` など) が提供する接続を変更する場合は、:ref:`settings_by_platform` テーブルを更新して、プラットフォームの Platform Options ファイルを追加または変更することも必要です。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:13 -msgid "You should already have documented each module as described in :ref:`developing_modules_documenting`." -msgstr "各モジュールは、「:ref:`developing_modules_documenting`」で説明されているように、すでに文書化されている必要があります。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:16 -msgid "Modifying the platform options table" -msgstr "プラットフォームオプションテーブルの変更" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:18 -msgid "The :ref:`settings_by_platform` table is a convenient summary of the connections options provided by each network platform that has modules in Ansible. Add a row for your platform to this table, in alphabetical order. For example:" -msgstr ":ref:`settings_by_platform` テーブルは、Ansible にモジュールがある各ネットワークプラットフォームが提供する接続オプションの便利な概要です。お使いのプラットフォームの行をアルファベット順に追加します。以下に例を示します。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:25 -msgid "Ensure that the table stays formatted correctly. That is:" -msgstr "テーブルの形式が正しく表示されていることを確認します。つまり、以下のようになります。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:27 -msgid "Each row is inserted in alphabetical order." -msgstr "各行はアルファベット順に挿入されます。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:28 -msgid "The cell division ``|`` markers line up with the ``+`` markers." -msgstr "セル分割マーカー ``|`` と ``+`` マーカーの位置は同じになります。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:29 -msgid "The check marks appear only for the connection types provided by the network modules." -msgstr "このチェックマークは、ネットワークモジュールが提供する接続タイプに限り表示されます。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:34 -msgid "Adding a platform-specific options section" -msgstr "プラットフォーム固有のオプションセクションの追加" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:36 -msgid "The platform- specific sections are individual ``.rst`` files that provide more detailed information for the users of your network platform modules. Name your new file ``platform_.rst`` (for example, ``platform_myos.rst``). The platform name should match the module prefix. See `platform_eos.rst `_ and :ref:`eos_platform_options` for an example of the details you should provide in your platform-specific options section." -msgstr "プラットフォーム固有のセクションは、ネットワークプラットフォームモジュールのユーザーに関する詳細情報を提供する個別の ``.rst`` ファイルです。新しいファイル ``platform_.rst`` に名前を付けます (例: ``platform_myos.rst``)。プラットフォーム名はモジュール接頭辞と一致させる必要があります。プラットフォーム固有のオプションセクションに指定する必要のある詳細例は、「`platform_eos.rst `_」および「:ref:`eos_platform_options`」を参照してください。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:38 -msgid "Your platform-specific section should include the following:" -msgstr "プラットフォーム固有のセクションには、以下のセクションが含まれている必要があります。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:40 -msgid "**Connections available table** - a deeper dive into each connection type, including details on credentials, indirect access, connections settings, and enable mode." -msgstr "**接続可能なテーブル** - 認証情報、間接アクセス、接続設定、有効化モードの詳細など、各接続タイプの詳細。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:41 -msgid "**How to use each connection type** - with working examples of each connection type." -msgstr "**各接続タイプの使用方法** - 各接続タイプの作業例を含む。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:43 -msgid "If your network platform supports SSH connections, also include the following at the bottom of your ``.rst`` file:" -msgstr "ネットワークプラットフォームが SSH 接続に対応している場合は、``.rst`` ファイルの下部に以下も追加します。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:50 -msgid "Adding your new file to the table of contents" -msgstr "新規ファイルのコンテンツを表へ追加" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:52 -msgid "As a final step, add your new file in alphabetical order in the ``platform_index.rst`` file. You should then build the documentation to verify your additions. See :ref:`community_documentation_contributions` for more details." -msgstr "最終ステップとして、``platform_index.rst`` ファイルの新しいファイルをアルファベット順に追加します。次に、ドキュメントをビルドして、追加した内容を確認する必要があります。詳細は「:ref:`community_documentation_contributions`」を参照してください。" - -#: ../../rst/network/dev_guide/index.rst:5 -msgid "Network Developer Guide" -msgstr "ネットワーク開発者ガイド" - -#: ../../rst/network/dev_guide/index.rst:7 -msgid "Welcome to the Developer Guide for Ansible Network Automation!" -msgstr "ネットワークを自動化する開発者向けガイドへようこそ" - -#: ../../rst/network/dev_guide/index.rst:9 -#: ../../rst/network/getting_started/index.rst:15 -#: ../../rst/network/user_guide/index.rst:9 -msgid "**Who should use this guide?**" -msgstr "**本ガイドの対象者**" - -#: ../../rst/network/dev_guide/index.rst:11 -msgid "If you want to extend Ansible for Network Automation by creating a module or plugin, this guide is for you. This guide is specific to networking. You should already be familiar with how to create, test, and document modules and plugins, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository. See the :ref:`developer_guide` for details. Before you proceed, please read:" -msgstr "ネットワーク自動化のために、モジュールやプラグインを作成して Ansible を拡張する場合は、本ガイドをお勧めします。このガイドは、ネットワークに特化しています。モジュールやプラグインの作成、テスト、文書化の方法や、作成したモジュールやプラグインを Ansible のメインリポジトリーに受け入れてもらうための前提条件については、すでにご存知のことと思います。詳細は、「:ref:`developer_guide`」を参照してください。先に進む前に、以下をお読みください。" - -#: ../../rst/network/dev_guide/index.rst:13 -msgid "How to :ref:`add a custom plugin or module locally `." -msgstr ":ref:`カスタムプラグインまたはモジュールをローカルに追加する ` 方法" - -#: ../../rst/network/dev_guide/index.rst:14 -msgid "How to figure out if :ref:`developing a module is the right approach ` for my use case." -msgstr "個別のユースケースで :ref:`モジュールを開発することが正しいアプローチ ` かどうかを判断する方法。" - -#: ../../rst/network/dev_guide/index.rst:15 -msgid "How to :ref:`set up my Python development environment `." -msgstr ":ref:`Python 開発環境を設定する ` 方法" - -#: ../../rst/network/dev_guide/index.rst:16 -msgid "How to :ref:`get started writing a module `." -msgstr ":ref:`モジュール作成を開始する ` 方法" - -#: ../../rst/network/dev_guide/index.rst:19 -msgid "Find the network developer task that best describes what you want to do:" -msgstr "お客様が必要なことを最も適切に説明しているネットワーク開発者タスクを選択してください。" - -#: ../../rst/network/dev_guide/index.rst:21 -msgid "I want to :ref:`develop a network resource module `." -msgstr ":ref:`ネットワークリソースモジュールを開発 ` したいです。" - -#: ../../rst/network/dev_guide/index.rst:22 -msgid "I want to :ref:`develop a network connection plugin `." -msgstr ":ref:`ネットワーク接続プラグインを開発 ` したいです。" - -#: ../../rst/network/dev_guide/index.rst:23 -msgid "I want to :ref:`document my set of modules for a network platform `." -msgstr ":ref:`ネットワークプラットフォームのモジュールセットを文書化 ` したいです。" - -#: ../../rst/network/dev_guide/index.rst:25 -msgid "If you prefer to read the entire guide, here's a list of the pages in order." -msgstr "本ガイドをすべて読む場合は、以下に示す順番でページを表示してください。" - -#: ../../rst/network/getting_started/basic_concepts.rst:3 -msgid "Basic Concepts" -msgstr "基本的な概念" - -#: ../../rst/network/getting_started/basic_concepts.rst:5 -msgid "These concepts are common to all uses of Ansible, including network automation. You need to understand them to use Ansible for network automation. This basic introduction provides the background you need to follow the examples in this guide." -msgstr "この概念は、ネットワーク自動化を含む Ansible のすべての用途に共通しています。ネットワーク自動化のためにAnsibleを使用するには、これらを理解する必要があります。この基本的な紹介は、本ガイドの例を理解するのに必要な背景を説明します。" - -#: ../../rst/shared_snippets/basic_concepts.txt:2 -msgid "Control node" -msgstr "コントロールノード" - -#: ../../rst/shared_snippets/basic_concepts.txt:4 -msgid "Any machine with Ansible installed. You can run Ansible commands and playbooks by invoking the ``ansible`` or ``ansible-playbook`` command from any control node. You can use any computer that has a Python installation as a control node - laptops, shared desktops, and servers can all run Ansible. However, you cannot use a Windows machine as a control node. You can have multiple control nodes." -msgstr "Ansible がインストールされているマシン。任意のコントロールノードから ``ansible`` コマンドまたは ``ansible-playbook`` コマンドを呼び出すことで、Ansible コマンドおよび Playbook を実行できます。Python がインストールされているコンピューターであれば、ラップトップ、共有ディスクトップ、サーバーなど、どのコンピューターでも Ansible を実行することができます。ただし、Windows マシンをコントロールノードとして使用することはできません。複数のコントロールノードを持つことができます。" - -#: ../../rst/shared_snippets/basic_concepts.txt:7 -msgid "Managed nodes" -msgstr "管理ノード" - -#: ../../rst/shared_snippets/basic_concepts.txt:9 -msgid "The network devices (and/or servers) you manage with Ansible. Managed nodes are also sometimes called \"hosts\". Ansible is not installed on managed nodes." -msgstr "Ansible で管理するネットワークデバイス (またはサーバー)。管理ノードは「ホスト」と呼ばれることもあります。Ansible は管理ノードにインストールされません。" - -#: ../../rst/shared_snippets/basic_concepts.txt:12 -msgid "Inventory" -msgstr "インベントリー" - -#: ../../rst/shared_snippets/basic_concepts.txt:14 -msgid "A list of managed nodes. An inventory file is also sometimes called a \"hostfile\". Your inventory can specify information like IP address for each managed node. An inventory can also organize managed nodes, creating and nesting groups for easier scaling. To learn more about inventory, see :ref:`the Working with Inventory` section." -msgstr "管理ノードの一覧。インベントリーファイルは「ホストファイル」と呼ばれることもあります。インベントリーは、各管理ノードに対して IP アドレスなどの情報を指定できます。インベントリーは管理ノードを整理でき、スケーリングが容易になるグループの作成やネスト化が可能です。インベントリーの詳細は「:ref:`インベントリーでの作業 `」セクションを参照してください。" - -#: ../../rst/shared_snippets/basic_concepts.txt:19 -msgid "Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. You can install and use collections through `Ansible Galaxy `_. To learn more about collections, see :ref:`collections`." -msgstr "コレクションは、Playbook、ロール、モジュール、プラグインを含む Ansible コンテンツのディストリビューション形式です。`Ansible Galaxy `_ でコレクションをインストールして使用することができます。コレクションの詳細は、「:ref:`collections`」を参照してください。" - -#: ../../rst/shared_snippets/basic_concepts.txt:22 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/shared_snippets/basic_concepts.txt:24 -msgid "The units of code Ansible executes. Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device. You can invoke a single module with a task, or invoke several different modules in a playbook. Starting in Ansible 2.10, modules are grouped in collections. For an idea of how many collections Ansible includes, take a look at the :ref:`list_of_collections`." -msgstr "Ansible が実行するコードの単位。各モジュールは、特定タイプのデータベースのユーザーを管理したり、特定タイプのネットワークデバイスの VLAN インターフェースを管理するなど、特定の用途に使用されます。タスクで 1 つのモジュールを起動したり、Playbook で複数のモジュールを起動したりすることができます。Ansible 2.10 以降、モジュールはコレクションとしてまとめられています。Ansible に含まれるコレクションの数は、「:ref:`list_of_collections`」を参照してください。" - -#: ../../rst/shared_snippets/basic_concepts.txt:27 -msgid "Tasks" -msgstr "タスク" - -#: ../../rst/shared_snippets/basic_concepts.txt:29 -msgid "The units of action in Ansible. You can execute a single task once with an ad hoc command." -msgstr "Ansible でのアクションの単位。アドホックコマンドを使用すると、単一のタスクを実行できます。" - -#: ../../rst/shared_snippets/basic_concepts.txt:32 -msgid "Playbooks" -msgstr "Playbook" - -#: ../../rst/shared_snippets/basic_concepts.txt:34 -msgid "Ordered lists of tasks, saved so you can run those tasks in that order repeatedly. Playbooks can include variables as well as tasks. Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`." -msgstr "順番に並べられたタスクの一覧は保存されているため、その順番でタスクを繰り返し実行することができます。Playbook には、タスクだけでなく、変数も含めることができます。Playbook は YAML で記述されているため、読みやすく、書きやすく、共有しやすく、理解しやすい特徴があります。Playbook の詳細は、「:ref:`about_playbooks`」を参照してください。" - -#: ../../rst/network/getting_started/first_inventory.rst:3 -msgid "Build Your Inventory" -msgstr "インベントリーの構築" - -#: ../../rst/network/getting_started/first_inventory.rst:5 -msgid "Running a playbook without an inventory requires several command-line flags. Also, running a playbook against a single device is not a huge efficiency gain over making the same change manually. The next step to harnessing the full power of Ansible is to use an inventory file to organize your managed nodes into groups with information like the ``ansible_network_os`` and the SSH user. A fully-featured inventory file can serve as the source of truth for your network. Using an inventory file, a single playbook can maintain hundreds of network devices with a single command. This page shows you how to build an inventory file, step by step." -msgstr "インベントリーを使用せずに Playbook を実行するには、いくつかのコマンドラインフラグが必要です。また、単一のデバイスに対して Playbook を実行しても、同じ変更を手動で行うのに比べて効率が大きく向上するわけではありません。Ansible を最大限に活用するための次のステップは、インベントリーファイルを使用して、管理対象のノードを ``ansible_network_os`` や SSH ユーザーなどの情報を持つグループに整理することです。完全な機能を備えたインベントリーファイルは、ネットワークの唯一の信頼できるソースとなります。インベントリーファイルを使用すると、1 つの Playbook で数百のネットワークデバイスを 1 つのコマンドで管理できます。このページでは、インベントリーファイルを作成する方法を順を追って説明します。" - -#: ../../rst/network/getting_started/first_inventory.rst:11 -msgid "Basic inventory" -msgstr "基本的なインベントリー" - -#: ../../rst/network/getting_started/first_inventory.rst:13 -msgid "First, group your inventory logically. Best practice is to group servers and network devices by their What (application, stack or microservice), Where (datacenter or region), and When (development stage):" -msgstr "まず、インベントリーを論理的にグループ化します。ベストプラクティスは、サーバーおよびネットワークデバイスを、種類 (アプリケーション、スタック、またはマイクロサービス)、場所 (データセンタまたは地域)、および時期 (開発段階) でグループ化することです。" - -#: ../../rst/network/getting_started/first_inventory.rst:15 -msgid "**What**: db, web, leaf, spine" -msgstr "**種類**: db、web、leaf、spine" - -#: ../../rst/network/getting_started/first_inventory.rst:16 -msgid "**Where**: east, west, floor_19, building_A" -msgstr "**場所**: east、west、floor_19、building_A" - -#: ../../rst/network/getting_started/first_inventory.rst:17 -msgid "**When**: dev, test, staging, prod" -msgstr "**時期**: dev、test、staging、prod" - -#: ../../rst/network/getting_started/first_inventory.rst:19 -msgid "Avoid spaces, hyphens, and preceding numbers (use ``floor_19``, not ``19th_floor``) in your group names. Group names are case sensitive." -msgstr "グループ名にスペースまたはハイフンを使用しないでください。またグループ名は数値で始めないでください (``19th_floor``ではなく ``floor_19`` を使用)。グループ名は大文字と小文字を区別します。" - -#: ../../rst/network/getting_started/first_inventory.rst:21 -msgid "This tiny example data center illustrates a basic group structure. You can group groups using the syntax ``[metagroupname:children]`` and listing groups as members of the metagroup. Here, the group ``network`` includes all leafs and all spines; the group ``datacenter`` includes all network devices plus all webservers." -msgstr "この小さなデータセンターの例では、基本的なグループ構造を説明します。グループをグループ化するには、``[metagroupname:children]`` という構文を使い、グループをメタグループのメンバーとしてリストアップします。ここでは、``network`` というグループには、すべての leaf (リーフ) とすべての spine (スパイン) が含まれ、``datacenter`` というグループには、すべてのネットワークデバイスとすべての Web サーバーが含まれています。" - -#: ../../rst/network/getting_started/first_inventory.rst:60 -msgid "You can also create this same inventory in INI format." -msgstr "同じインベントリーを INI 形式で作成することもできます。" - -#: ../../rst/network/getting_started/first_inventory.rst:86 -msgid "Add variables to the inventory" -msgstr "インベントリーへの変数の追加" - -#: ../../rst/network/getting_started/first_inventory.rst:88 -msgid "Next, you can set values for many of the variables you needed in your first Ansible command in the inventory, so you can skip them in the ``ansible-playbook`` command. In this example, the inventory includes each network device's IP, OS, and SSH user. If your network devices are only accessible by IP, you must add the IP to the inventory file. If you access your network devices using hostnames, the IP is not necessary." -msgstr "次に、最初の Ansible コマンドで必要であった多くの変数の値をインベントリーに設定することで、``ansible-playbook`` コマンドでスキップできるようになります。この例では、インベントリーに各ネットワークデバイスの IP、OS、SSH ユーザーが含まれています。ネットワークデバイスに IP でしかアクセスできない場合は、インベントリーファイルに IP を追加する必要があります。ホスト名を使用してネットワークデバイスにアクセスする場合は、IP が必要ありません。" - -#: ../../rst/network/getting_started/first_inventory.rst:137 -msgid "Group variables within inventory" -msgstr "インベントリー内のグループ変数" - -#: ../../rst/network/getting_started/first_inventory.rst:139 -msgid "When devices in a group share the same variable values, such as OS or SSH user, you can reduce duplication and simplify maintenance by consolidating these into group variables:" -msgstr "グループ内のデバイスが、OS や SSH ユーザーなど、同じ変数値を共有している場合は、この値をグループ変数に統合することで、重複を減らし、メンテナンスを簡素化できます。" - -#: ../../rst/network/getting_started/first_inventory.rst:185 -msgid "Variable syntax" -msgstr "変数の構文" - -#: ../../rst/network/getting_started/first_inventory.rst:187 -msgid "The syntax for variable values is different in inventory, in playbooks, and in the ``group_vars`` files, which are covered below. Even though playbook and ``group_vars`` files are both written in YAML, you use variables differently in each." -msgstr "変数の値の構文は、インベントリー、Playbook、および ``group_vars`` ファイルで異なりますが、以下で説明します。Playbook と ``group_vars`` ファイルはどちらも YAML で記述されていますが、変数は YAML でそれぞれ異なります。" - -#: ../../rst/network/getting_started/first_inventory.rst:189 -msgid "In an ini-style inventory file you **must** use the syntax ``key=value`` for variable values: ``ansible_network_os=vyos.vyos.vyos``." -msgstr "ini 形式のインベントリーファイルで、変数値 ``ansible_network_os=vyos.vyos.vyos`` に構文 ``key=value`` を使用する **必要があります**。" - -#: ../../rst/network/getting_started/first_inventory.rst:190 -msgid "In any file with the ``.yml`` or ``.yaml`` extension, including playbooks and ``group_vars`` files, you **must** use YAML syntax: ``key: value``." -msgstr "Playbook および ``group_vars`` ファイルを含む ``.yml`` 拡張子または ``.yaml`` 拡張子を持つファイルでは、YAML 構文 ``key: value`` を使用する**必要があります**。" - -#: ../../rst/network/getting_started/first_inventory.rst:192 -msgid "In ``group_vars`` files, use the full ``key`` name: ``ansible_network_os: vyos.vyos.vyos``." -msgstr "``group_vars`` ファイルで、完全な ``key`` 名 (``ansible_network_os: vyos.vyos.vyos``) を使用します。" - -#: ../../rst/network/getting_started/first_inventory.rst:193 -msgid "In playbooks, use the short-form ``key`` name, which drops the ``ansible`` prefix: ``network_os: vyos.vyos.vyos``." -msgstr "Playbook では、``ansible`` の接頭辞を取り除いた短い形式の``key`` の名前を使用します (``network_os: vyos.vyos.vyos``)。" - -#: ../../rst/network/getting_started/first_inventory.rst:197 -msgid "Group inventory by platform" -msgstr "プラットフォームによるインベントリーのグループ化" - -#: ../../rst/network/getting_started/first_inventory.rst:199 -msgid "As your inventory grows, you may want to group devices by platform. This allows you to specify platform-specific variables easily for all devices on that platform:" -msgstr "インベントリーが大きくなるにつれ、プラットフォームでデバイスをグループ化できます。これにより、そのプラットフォームのすべてのデバイスに対してプラットフォーム固有の変数を簡単に指定できます。" - -#: ../../rst/network/getting_started/first_inventory.rst:242 -msgid "With this setup, you can run ``first_playbook.yml`` with only two flags:" -msgstr "この設定では、以下の 2 つのフラグを指定して ``first_playbook.yml`` を実行できます。" - -#: ../../rst/network/getting_started/first_inventory.rst:248 -msgid "With the ``-k`` flag, you provide the SSH password(s) at the prompt. Alternatively, you can store SSH and other secrets and passwords securely in your group_vars files with ``ansible-vault``. See :ref:`network_vault` for details." -msgstr "``-k`` フラグを使用して、プロンプトで SSH パスワードを指定します。これで、``ansible-vault`` で SSH と、その他のシークレットおよびパスワードを group_vars ファイルに安全に保存できます。詳細は「:ref:`network_vault`」を参照してください。" - -#: ../../rst/network/getting_started/first_inventory.rst:251 -msgid "Verifying the inventory" -msgstr "インベントリーの確認" - -#: ../../rst/network/getting_started/first_inventory.rst:253 -msgid "You can use the :ref:`ansible-inventory` CLI command to display the inventory as Ansible sees it." -msgstr "CLI コマンド :ref:`ansible-inventory` を使用すると、Ansible が確認できるようにインベントリーを表示できます。" - -#: ../../rst/network/getting_started/first_inventory.rst:336 -msgid "Protecting sensitive variables with ``ansible-vault``" -msgstr "``ansible-vault`` による機密変数の保護" - -#: ../../rst/network/getting_started/first_inventory.rst:338 -msgid "The ``ansible-vault`` command provides encryption for files and/or individual variables like passwords. This tutorial will show you how to encrypt a single SSH password. You can use the commands below to encrypt other sensitive information, such as database passwords, privilege-escalation passwords and more." -msgstr "``ansible-vault`` コマンドは、ファイルや、パスワードなどの個々の変数の暗号化を行います。このチュートリアルでは、1 つの SSH パスワードを暗号化する方法を紹介します。以下のコマンドを使用すると、データベースのパスワードや権限昇格のためのパスワードなど、その他の機密情報を暗号化することができます。" - -#: ../../rst/network/getting_started/first_inventory.rst:340 -msgid "First you must create a password for ansible-vault itself. It is used as the encryption key, and with this you can encrypt dozens of different passwords across your Ansible project. You can access all those secrets (encrypted values) with a single password (the ansible-vault password) when you run your playbooks. Here's a simple example." -msgstr "まず、ansible-vault 自体のパスワードを作成する必要があります。これは暗号化キーとして使用され、Ansible プロジェクト全体で何十もの異なるパスワードを暗号化することができます。Playbook を実行するときに、1 つのパスワード (ansible-vault パスワード) でこの全シークレット (暗号化された値) にアクセスできます。以下に簡単な例を示します。" - -#: ../../rst/network/getting_started/first_inventory.rst:342 -msgid "Create a file and write your password for ansible-vault to it:" -msgstr "ファイルを作成して、ansible-vault のパスワードを書き込みます。" - -#: ../../rst/network/getting_started/first_inventory.rst:348 -msgid "Create the encrypted ssh password for your VyOS network devices, pulling your ansible-vault password from the file you just created:" -msgstr "VyOS ネットワークデバイス用に暗号化された ssh パスワードを作成し、作成したファイルから ansible-vault パスワードをプルします。" - -#: ../../rst/network/getting_started/first_inventory.rst:354 -msgid "If you prefer to type your ansible-vault password rather than store it in a file, you can request a prompt:" -msgstr "ファイルに保存せずに ansible-vault パスワードを入力する必要がある場合は、プロンプトを要求できます。" - -#: ../../rst/network/getting_started/first_inventory.rst:360 -msgid "and type in the vault password for ``my_user``." -msgstr "また、``my_user`` に vault パスワードに入力します。" - -#: ../../rst/network/getting_started/first_inventory.rst:362 -msgid "The :option:`--vault-id ` flag allows different vault passwords for different users or different levels of access. The output includes the user name ``my_user`` from your ``ansible-vault`` command and uses the YAML syntax ``key: value``:" -msgstr "option:`--vault-id ` フラグを使用すると、ユーザーまたはアクセスレベルごとに異なる Vault パスワードを使用できます。出力には、``ansible-vault`` コマンドのユーザー名 ``my_user`` が含まれ、YAML 構文 ``key: value`` が使用されます。" - -#: ../../rst/network/getting_started/first_inventory.rst:375 -msgid "This is an example using an extract from a YAML inventory, as the INI format does not support inline vaults:" -msgstr "INI 形式はインラインの vault に対応していないため、以下は YAML インベントリーから抽出を使用する例です。" - -#: ../../rst/network/getting_started/first_inventory.rst:396 -msgid "To use an inline vaulted variables with an INI inventory you need to store it in a 'vars' file in YAML format, it can reside in host_vars/ or group_vars/ to be automatically picked up or referenced from a play via ``vars_files`` or ``include_vars``." -msgstr "インラインの Vault 変数を INI インベントリーで使用するには、これを YAML 形式で「vars」ファイルに保存する必要があります。これは host_vars/ または group_vars/ に置かれ、``vars_files`` または ``include_vars`` で Play から自動的に取得または参照されます。" - -#: ../../rst/network/getting_started/first_inventory.rst:399 -msgid "To run a playbook with this setup, drop the ``-k`` flag and add a flag for your ``vault-id``:" -msgstr "この設定で Playbook を実行するには、``-k`` フラグを削除し、``vault-id`` のフラグを追加します。" - -#: ../../rst/network/getting_started/first_inventory.rst:405 -msgid "Or with a prompt instead of the vault password file:" -msgstr "または、vault パスワードファイルの代わりにプロンプトを使用します。" - -#: ../../rst/network/getting_started/first_inventory.rst:411 -msgid "To see the original value, you can use the debug module. Please note if your YAML file defines the `ansible_connection` variable (as we used in our example), it will take effect when you execute the command below. To prevent this, please make a copy of the file without the ansible_connection variable." -msgstr "元の値を確認するには、デバッグモジュールを使用できます。(この例で使用したように) YAML ファイルで `ansible_connection` 変数が定義されているかどうかに注意してください。以下のコマンドを実行すると有効になります。これを防ぐには、ansible_connection 変数を使用せずにファイルのコピーを作成してください。" - -#: ../../rst/network/getting_started/first_inventory.rst:427 -msgid "Vault content can only be decrypted with the password that was used to encrypt it. If you want to stop using one password and move to a new one, you can update and re-encrypt existing vault content with ``ansible-vault rekey myfile``, then provide the old password and the new password. Copies of vault content still encrypted with the old password can still be decrypted with old password." -msgstr "Vault のコンテンツは、暗号化に使用されたパスワードでのみ復号できます。1 つのパスワードの使用を停止して新しいパスワードに移動する場合は、``ansible-vault rekey myfile`` を使用して、既存の Valut コンテンツを更新して再暗号化でき、次に古いパスワードと新しいパスワードを入力します。古いパスワードで暗号化されたままの Vault コンテンツのコピーは、古いパスワードで復号できます。" - -#: ../../rst/network/getting_started/first_inventory.rst:429 -msgid "For more details on building inventory files, see :ref:`the introduction to inventory`; for more details on ansible-vault, see :ref:`the full Ansible Vault documentation`." -msgstr "インベントリーファイルの構築の詳細は、「:ref:`インベントリーの概要`」を参照してください。ansible-vault の詳細は、:ref:`Ansible Vault の完全ドキュメント` を参照してください。" - -#: ../../rst/network/getting_started/first_inventory.rst:431 -msgid "Now that you understand the basics of commands, playbooks, and inventory, it's time to explore some more complex Ansible Network examples." -msgstr "コマンド、Playbook、およびインベントリーの基本を理解したら、より複雑な Ansible Network の例をいくつか説明します。" - -#: ../../rst/network/getting_started/first_playbook.rst:6 -msgid "Run Your First Command and Playbook" -msgstr "最初のコマンドおよび Playbook の実行" - -#: ../../rst/network/getting_started/first_playbook.rst:8 -msgid "Put the concepts you learned to work with this quick tutorial. Install Ansible, execute a network configuration command manually, execute the same command with Ansible, then create a playbook so you can execute the command any time on multiple network devices." -msgstr "このクイックチュートリアルでは、これまで学んだ概念を実際に使ってみましょう。Ansible をインストールし、ネットワーク設定コマンドを手動で実行し、Ansible で同じコマンドを実行してから Playbook を作成するため、複数のネットワークデバイスでいつでもコマンドを実行できます。" - -#: ../../rst/network/getting_started/first_playbook.rst:14 -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:13 -msgid "Prerequisites" -msgstr "要件" - -#: ../../rst/network/getting_started/first_playbook.rst:16 -msgid "Before you work through this tutorial you need:" -msgstr "このチュートリアルを実行する前に、以下が必要になります。" - -#: ../../rst/network/getting_started/first_playbook.rst:18 -msgid "Ansible 2.10 (or higher) installed" -msgstr "Ansible 2.10 (以降) がインストールされている" - -#: ../../rst/network/getting_started/first_playbook.rst:19 -msgid "One or more network devices that are compatible with Ansible" -msgstr "Ansible と互換性のある 1 つ以上ネットワークデバイス" - -#: ../../rst/network/getting_started/first_playbook.rst:20 -msgid "Basic Linux command line knowledge" -msgstr "基本的な Linux コマンドラインの知識" - -#: ../../rst/network/getting_started/first_playbook.rst:21 -msgid "Basic knowledge of network switch & router configuration" -msgstr "ネットワークスイッチおよびルーター設定に関する基本知識" - -#: ../../rst/network/getting_started/first_playbook.rst:24 -msgid "Install Ansible" -msgstr "Ansible のインストール" - -#: ../../rst/network/getting_started/first_playbook.rst:26 -msgid "Install Ansible using your preferred method. See :ref:`installation_guide`. Then return to this tutorial." -msgstr "好みの方法で Ansible をインストールします。「:ref:`installation_guide`」を参照してください。その後、このチュートリアルに戻ります。" - -#: ../../rst/network/getting_started/first_playbook.rst:28 -msgid "Confirm the version of Ansible (must be >= 2.10):" -msgstr "Ansible のバージョンを確認します (2.10 以下である必要があります)。" - -#: ../../rst/network/getting_started/first_playbook.rst:36 -msgid "Establish a manual connection to a managed node" -msgstr "管理ノードへの手動接続の確立" - -#: ../../rst/network/getting_started/first_playbook.rst:38 -msgid "To confirm your credentials, connect to a network device manually and retrieve its configuration. Replace the sample user and device name with your real credentials. For example, for a VyOS router:" -msgstr "認証情報を確認するには、手動でネットワークデバイスに接続し、その設定を取得します。サンプルユーザー名とデバイス名を実際の認証情報に置き換えます。たとえば、VyOS ルーターの場合は以下のようになります。" - -#: ../../rst/network/getting_started/first_playbook.rst:46 -msgid "This manual connection also establishes the authenticity of the network device, adding its RSA key fingerprint to your list of known hosts. (If you have connected to the device before, you have already established its authenticity.)" -msgstr "この手動接続により、ネットワークデバイスの信頼性も確立され、既知のホストの一覧に RSA 鍵フィンガープリントが追加されます (以前にデバイスを接続したことがある場合は、その信頼性がすでに確立されています)。" - -#: ../../rst/network/getting_started/first_playbook.rst:50 -msgid "Run your first network Ansible command" -msgstr "最初のネットワーク Ansible コマンドの実行" - -#: ../../rst/network/getting_started/first_playbook.rst:52 -msgid "Instead of manually connecting and running a command on the network device, you can retrieve its configuration with a single, stripped-down Ansible command:" -msgstr "ネットワークデバイスでコマンドを手動で接続して実行する代わりに、1 つの削除済み Ansible コマンドで設定を取得できます。" - -#: ../../rst/network/getting_started/first_playbook.rst:65 -msgid "The flags in this command set seven values:" -msgstr "このコマンドのフラグは、7 つの値を設定します。" - -#: ../../rst/network/getting_started/first_playbook.rst:59 -msgid "the host group(s) to which the command should apply (in this case, all)" -msgstr "コマンドを適用するホストグループ (この場合は all)" - -#: ../../rst/network/getting_started/first_playbook.rst:60 -msgid "the inventory (-i, the device or devices to target - without the trailing comma -i points to an inventory file)" -msgstr "インベントリー (-i、ターゲットに設定するデバイス (最後のコンマがない -i はインベントリーファイルの指定がありません))" - -#: ../../rst/network/getting_started/first_playbook.rst:61 -msgid "the connection method (-c, the method for connecting and executing ansible)" -msgstr "接続方法 (-c、ansible の接続方法および実行方法)" - -#: ../../rst/network/getting_started/first_playbook.rst:62 -msgid "the user (-u, the username for the SSH connection)" -msgstr "ユーザー (-u、SSH 接続のユーザー名)" - -#: ../../rst/network/getting_started/first_playbook.rst:63 -msgid "the SSH connection method (-k, please prompt for the password)" -msgstr "SSH 接続の方法 (-k、パスワードのプロンプト有り)" - -#: ../../rst/network/getting_started/first_playbook.rst:64 -msgid "the module (-m, the Ansible module to run, using the fully qualified collection name (FQCN))" -msgstr "モジュール (-m、完全修飾コレクション名 (FQCN) を使用した、実行する Ansible モジュール)" - -#: ../../rst/network/getting_started/first_playbook.rst:65 -msgid "an extra variable ( -e, in this case, setting the network OS value)" -msgstr "追加変数 (-e、この場合はネットワーク OS 値の設定)" - -#: ../../rst/network/getting_started/first_playbook.rst:67 -msgid "NOTE: If you use ``ssh-agent`` with ssh keys, Ansible loads them automatically. You can omit ``-k`` flag." -msgstr "注記: ssh 鍵で ``ssh-agent`` を使用すると、Ansible により自動的に読み込まれます。``-k`` フラグは省略できます。" - -#: ../../rst/network/getting_started/first_playbook.rst:71 -msgid "If you are running Ansible in a virtual environment, you will also need to add the variable ``ansible_python_interpreter=/path/to/venv/bin/python``" -msgstr "仮想環境で Ansible を実行している場合は、変数 ``ansible_python_interpreter=/path/to/venv/bin/python`` を追加する必要もあります。" - -#: ../../rst/network/getting_started/first_playbook.rst:75 -msgid "Create and run your first network Ansible Playbook" -msgstr "最初のネットワークの Ansible Playbook の作成および実行" - -#: ../../rst/network/getting_started/first_playbook.rst:77 -msgid "If you want to run this command every day, you can save it in a playbook and run it with ``ansible-playbook`` instead of ``ansible``. The playbook can store a lot of the parameters you provided with flags at the command line, leaving less to type at the command line. You need two files for this - a playbook and an inventory file." -msgstr "このコマンドを毎日実行する場合は、Playbook に保存し、``ansible`` の代わりに ``ansible-playbook`` を使用して実行できます。Playbook には、コマンドラインでフラグを使用して指定した多くのパラメーターを保存できるため、コマンドラインで入力するパラメータが少なくなります。これを行うためには、Playbook およびインベントリーファイルの 2 つのファイルが必要です。" - -#: ../../rst/network/getting_started/first_playbook.rst:79 -msgid "Download :download:`first_playbook.yml `, which looks like this:" -msgstr ":download:`first_playbook.yml ` をダウンロードします。これは、以下のようになります。" - -#: ../../rst/network/getting_started/first_playbook.rst:84 -msgid "The playbook sets three of the seven values from the command line above: the group (``hosts: all``), the connection method (``connection: ansible.netcommon.network_cli``) and the module (in each task). With those values set in the playbook, you can omit them on the command line. The playbook also adds a second task to show the config output. When a module runs in a playbook, the output is held in memory for use by future tasks instead of written to the console. The debug task here lets you see the results in your shell." -msgstr "Playbook では、上記のコマンドラインの 7 つの値のうちの 3 つ、つまりグループ (``hosts: all``)、接続方法 (``connection: ansible.netcommon.network_cli``)、モジュール (各タスク内) が設定されます。これらの値を Playbook で設定すると、コマンドラインで省略できます。この Playbook には、設定出力を表示する 2 番目のタスクも追加されています。モジュールが Playbook で実行すると、出力はコンソールに書き込まれるのではなく、将来のタスクで使用するためにメモリーに保持されます。ここでデバッグタスクを実行すると、シェルで結果を確認できます。" - -#: ../../rst/network/getting_started/first_playbook.rst:86 -msgid "Run the playbook with the command:" -msgstr "以下のコマンドを使用して Playbook を実行します。" - -#: ../../rst/network/getting_started/first_playbook.rst:92 -msgid "The playbook contains one play with two tasks, and should generate output like this:" -msgstr "Playbook には、2 つのタスクを持つプレイが 1 つ含まれており、次のような出力が生成されます。" - -#: ../../rst/network/getting_started/first_playbook.rst:111 -msgid "Now that you can retrieve the device config, try updating it with Ansible. Download :download:`first_playbook_ext.yml `, which is an extended version of the first playbook:" -msgstr "デバイス設定を取得できたので、Ansible で更新してみましょう。最初の Playbook の拡張バージョンである :download:`first_playbook_ext.yml ` をダウンロードします。" - -#: ../../rst/network/getting_started/first_playbook.rst:116 -msgid "The extended first playbook has four tasks in a single play. Run it with the same command you used above. The output shows you the change Ansible made to the config:" -msgstr "拡張された最初の Playbook には、1 つのプレイに 4 つのタスクがあります。上記のコマンドと同じコマンドを使用して実行すると、出力には、Ansible が設定に加えた変更が表示されます。" - -#: ../../rst/network/getting_started/first_playbook.rst:158 -msgid "Gathering facts from network devices" -msgstr "ネットワークデバイスからのファクトの収集" - -#: ../../rst/network/getting_started/first_playbook.rst:160 -msgid "The ``gather_facts`` keyword now supports gathering network device facts in standardized key/value pairs. You can feed these network facts into further tasks to manage the network device." -msgstr "``gather_facts`` キーワードは、標準化された鍵と値のペアでネットワークデバイスのファクトの収集に対応します。これらのネットワークファクトを、ネットワークデバイスを管理する追加のタスクに指定できます。" - -#: ../../rst/network/getting_started/first_playbook.rst:162 -msgid "You can also use the new ``gather_network_resources`` parameter with the network ``*_facts`` modules (such as :ref:`arista.eos.eos_facts `) to return just a subset of the device configuration, as shown below." -msgstr "また、新しい ``gather_network_resources`` パラメーターを、ネットワークの ``*_facts`` モジュール (:ref:`arista.eos.eos_facts ` など) とともに使用すると、以下のようにデバイス設定のサブセットのみを返すことができます。" - -#: ../../rst/network/getting_started/first_playbook.rst:173 -msgid "The playbook returns the following interface facts:" -msgstr "Playbook は以下のインターフェースのファクトを返します。" - -#: ../../rst/network/getting_started/first_playbook.rst:210 -msgid "Note that this returns a subset of what is returned by just setting ``gather_subset: interfaces``." -msgstr "これは、``gather_subset: interfaces`` の設定で返される内容のサブセットを返すことに注意してください。" - -#: ../../rst/network/getting_started/first_playbook.rst:212 -msgid "You can store these facts and use them directly in another task, such as with the :ref:`eos_interfaces ` resource module." -msgstr "これらのファクトを保存し、:ref:`eos_interfaces ` リソースモジュールなどの別のタスクで直接使用できます。" - -#: ../../rst/network/getting_started/index.rst:23 -msgid "Getting Started Guide" -msgstr "入門ガイド" - -#: ../../rst/network/getting_started/index.rst:5 -msgid "Network Getting Started" -msgstr "ネットワークスタートガイド" - -#: ../../rst/network/getting_started/index.rst:7 -msgid "Ansible collections support a wide range of vendors, device types, and actions, so you can manage your entire network with a single automation tool. With Ansible, you can:" -msgstr "Ansible コレクションは広範なベンダー、デバイスタイプ、アクションに対応しているため、1 つの自動化ツールでネットワーク全体を管理できます。Ansible では、以下を行うことができます。" - -#: ../../rst/network/getting_started/index.rst:9 -msgid "Automate repetitive tasks to speed routine network changes and free up your time for more strategic work" -msgstr "反復タスクを自動化して、ルーチンネットワークの変更を迅速化し、その時間をより戦略的な作業に割り当てます。" - -#: ../../rst/network/getting_started/index.rst:10 -msgid "Leverage the same simple, powerful, and agentless automation tool for network tasks that operations and development use" -msgstr "操作と開発で使用するネットワークタスクの両方に、同一の簡単で強力なエージェントレスの自動化ツールを使用します。" - -#: ../../rst/network/getting_started/index.rst:11 -msgid "Separate the data model (in a playbook or role) from the execution layer (via Ansible modules) to manage heterogeneous network devices" -msgstr "異機種環境にあるネットワークデバイスを管理するため、(Ansible モジュールにより) 実行レイヤーからデータモデル (Playbook またはロール) を分離します。" - -#: ../../rst/network/getting_started/index.rst:12 -msgid "Benefit from community and vendor-generated sample playbooks and roles to help accelerate network automation projects" -msgstr "ネットワーク自動化プロジェクトを加速化するコミュニティーおよびベンダーが生成したサンプルの Playbook およびロールを活用します。" - -#: ../../rst/network/getting_started/index.rst:13 -msgid "Communicate securely with network hardware over SSH or HTTPS" -msgstr "SSH または HTTPS を介してネットワークハードウェアとセキュアに通信します。" - -#: ../../rst/network/getting_started/index.rst:17 -msgid "This guide is intended for network engineers using Ansible for the first time. If you understand networks but have never used Ansible, work through the guide from start to finish." -msgstr "このガイドは、Ansible を初めて使用するネットワークエンジニアを対象としています。ネットワークを理解していて、Ansible を使用したことがない場合は、ガイドを最初から最後まで実践してください。" - -#: ../../rst/network/getting_started/index.rst:19 -msgid "This guide is also useful for experienced Ansible users automating network tasks for the first time. You can use Ansible commands, playbooks and modules to configure hubs, switches, routers, bridges and other network devices. But network modules are different from Linux/Unix and Windows modules, and you must understand some network-specific concepts to succeed. If you understand Ansible but have never automated a network task, start with the second section." -msgstr "このガイドは、ネットワークタスクを初めて自動化する経験豊富な Ansible ユーザーにも役立ちます。Ansible コマンド、Playbook、モジュールを使用して、ハブ、スイッチ、ルーター、ブリッジ、その他のネットワークデバイスを構成できます。ただし、ネットワークモジュールは Linux/Unix および Windows のモジュールとは異なり、成功するにはネットワーク固有の概念を理解する必要があります。Ansible を理解していても、ネットワークタスクを自動化したことがない場合は、2 番目のセクションから始めてください。" - -#: ../../rst/network/getting_started/index.rst:21 -msgid "This guide introduces basic Ansible concepts and guides you through your first Ansible commands, playbooks and inventory entries." -msgstr "本ガイドでは、基本的な Ansible の概念を紹介し、Ansible コマンド、Playbook、およびインベントリーエントリーを説明します。" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:3 -msgid "Beyond the basics" -msgstr "中級編" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:5 -msgid "This page introduces some concepts that help you manage your Ansible workflow with directory structure and source control. Like the Basic Concepts at the beginning of this guide, these intermediate concepts are common to all uses of Ansible." -msgstr "このページでは、ディレクトリー構造とソース管理を使用した Ansible ワークフローの管理に役立つ概念を紹介します。このガイドの最初の基本概念と同様に、これらの中間概念は Ansible のすべての使用に共通です。" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:12 -msgid "A typical Ansible filetree" -msgstr "一般的な Ansible ファイルツリー" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:14 -msgid "Ansible expects to find certain files in certain places. As you expand your inventory and create and run more network playbooks, keep your files organized in your working Ansible project directory like this:" -msgstr "Ansible では、特定の場所にある特定のファイルを見つけることを想定しています。インベントリーを拡張し、ネットワークの Playbook を作成して実行する場合は、ファイルを以下のように作業用の Ansible プロジェクトディレクトリーに整理した状態にします。" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:33 -msgid "The ``backup`` directory and the files in it get created when you run modules like ``vyos_config`` with the ``backup: yes`` parameter." -msgstr "``backup`` ディレクトリーと、そのディレクトリーのファイルは、``backup: yes`` パラメーターを使用した ``vyos_config`` のモジュールを実行する際に作成されます。" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:37 -msgid "Tracking changes to inventory and playbooks: source control with git" -msgstr "インベントリーおよび Playbook への変更の追跡: git でのソース制御" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:39 -msgid "As you expand your inventory, roles and playbooks, you should place your Ansible projects under source control. We recommend ``git`` for source control. ``git`` provides an audit trail, letting you track changes, roll back mistakes, view history and share the workload of managing, maintaining and expanding your Ansible ecosystem. There are plenty of tutorials and guides to using ``git`` available." -msgstr "インベントリー、ロール、および Playbook を拡張するときは、Ansible プロジェクトをソース管理下に置く必要があります。ソース管理には ``git`` をお勧めします。``git`` には監査証跡が用意されており、変更の追跡、失敗のロールバック、履歴の表示、Ansible エコシステムの管理、維持、拡張のワークロードの共有が可能になります。``git`` を使用するためのチュートリアルとガイドが多数用意されています。" - -#: ../../rst/network/getting_started/network_connection_options.rst:5 -msgid "Working with network connection options" -msgstr "ネットワーク接続オプションの使用" - -#: ../../rst/network/getting_started/network_connection_options.rst:7 -msgid "Network modules can support multiple connection protocols, such as ``ansible.netcommon.network_cli``, ``ansible.netcommon.netconf``, and ``ansible.netcommon.httpapi``. These connections include some common options you can set to control how the connection to your network device behaves." -msgstr "ネットワークモジュールは、``ansible.netcommon.network_cli``、``ansible.netcommon.netconf``、``ansible.netcommon.httpapi`` などの複数の接続プロトコルをサポートできます。これらの接続には、ネットワークデバイスへの接続の動作を制御するために設定できる一般的なオプションがあります。" - -#: ../../rst/network/getting_started/network_connection_options.rst:9 -msgid "Common options are:" -msgstr "一般的なオプションは以下のとおりです。" - -#: ../../rst/network/getting_started/network_connection_options.rst:11 -msgid "``become`` and ``become_method`` as described in :ref:`privilege_escalation`." -msgstr "「:ref:`privilege_escalation`」に記載される通りに ``become`` および ``become_method``" - -#: ../../rst/network/getting_started/network_connection_options.rst:12 -msgid "``network_os`` - set to match your network platform you are communicating with. See the :ref:`platform-specific ` pages." -msgstr "``network_os`` - 通信しているネットワークプラットフォームと一致するように設定されます。「:ref:`platform-specific `」ページを参照してください。" - -#: ../../rst/network/getting_started/network_connection_options.rst:13 -msgid "``remote_user`` as described in :ref:`connection_set_user`." -msgstr "「:ref:`connection_set_user`」に記載される通りに ``remote_user``" - -#: ../../rst/network/getting_started/network_connection_options.rst:14 -msgid "Timeout options - ``persistent_command_timeout``, ``persistent_connect_timeout``, and ``timeout``." -msgstr "タイムアウトオプション: ``persistent_command_timeout``、``persistent_connect_timeout``、および ``timeout``" - -#: ../../rst/network/getting_started/network_connection_options.rst:19 -msgid "Setting timeout options" -msgstr "タイムアウトオプションの設定" - -#: ../../rst/network/getting_started/network_connection_options.rst:21 -msgid "When communicating with a remote device, you have control over how long Ansible maintains the connection to that device, as well as how long Ansible waits for a command to complete on that device. Each of these options can be set as variables in your playbook files, environment variables, or settings in your :ref:`ansible.cfg file `." -msgstr "リモートデバイスと通信する場合は、Ansible がそのデバイスへの接続を維持する時間、およびそのデバイスでコマンドが完了するまで Ansible が待機する時間を制御できます。各オプションは、Playbook ファイルの変数、環境変数、または :ref:`ansible.cfg ファイル ` の設定として設定できます。" - -#: ../../rst/network/getting_started/network_connection_options.rst:23 -msgid "For example, the three options for controlling the connection timeout are as follows." -msgstr "たとえば、接続タイムアウトを制御する 3 つのオプションは次のとおりです。" - -#: ../../rst/network/getting_started/network_connection_options.rst:25 -msgid "Using vars (per task):" -msgstr "vars (タスクごと) の使用:" - -#: ../../rst/network/getting_started/network_connection_options.rst:35 -msgid "Using the environment variable:" -msgstr "環境変数の使用:" - -#: ../../rst/network/getting_started/network_connection_options.rst:41 -msgid "Using the global configuration (in :file:`ansible.cfg`)" -msgstr "グローバル設定の使用 (:file:`ansible.cfg`) の使用" - -#: ../../rst/network/getting_started/network_connection_options.rst:48 -msgid "See :ref:`ansible_variable_precedence` for details on the relative precedence of each of these variables. See the individual connection type to understand each option." -msgstr "これらの各変数の相対優先度は、「:ref:`ansible_variable_precedence`」を参照してください。各オプションについては、個別の接続タイプを参照してください。" - -#: ../../rst/network/getting_started/network_differences.rst:3 -msgid "How Network Automation is Different" -msgstr "ネットワーク自動化の相違点" - -#: ../../rst/network/getting_started/network_differences.rst:5 -msgid "Network automation leverages the basic Ansible concepts, but there are important differences in how the network modules work. This introduction prepares you to understand the exercises in this guide." -msgstr "ネットワーク自動化は、基本的な Ansible の概念を利用しますが、ネットワークモジュールの動作には重要な相違点があります。本ガイドの演習を始める前に、このイントロダクションをお読みください。" - -#: ../../rst/network/getting_started/network_differences.rst:11 -msgid "Execution on the control node" -msgstr "コントロールノードでの実行" - -#: ../../rst/network/getting_started/network_differences.rst:13 -msgid "Unlike most Ansible modules, network modules do not run on the managed nodes. From a user's point of view, network modules work like any other modules. They work with ad hoc commands, playbooks, and roles. Behind the scenes, however, network modules use a different methodology than the other (Linux/Unix and Windows) modules use. Ansible is written and executed in Python. Because the majority of network devices can not run Python, the Ansible network modules are executed on the Ansible control node, where ``ansible`` or ``ansible-playbook`` runs." -msgstr "ほとんどの Ansible モジュールとは異なり、ネットワークモジュールは管理ノードで実行されません。ユーザーから見ると、ネットワークモジュールは他のモジュールと同様に機能します。アドホックコマンド、Playbook およびロールを使用します。しかし、その裏では、ネットワークモジュールは他 (Linux/Unix および Windows) のモジュールとは異なる方法を使用します。Ansible は Python で記述され、実行されます。大部分のネットワークデバイスは Python を実行できないため、Ansible ネットワークモジュールは Ansible コントロールノードで実行されます (``ansible`` または ``ansible-playbook`` が実行される場所です)。" - -#: ../../rst/network/getting_started/network_differences.rst:15 -msgid "Network modules also use the control node as a destination for backup files, for those modules that offer a ``backup`` option. With Linux/Unix modules, where a configuration file already exists on the managed node(s), the backup file gets written by default in the same directory as the new, changed file. Network modules do not update configuration files on the managed nodes, because network configuration is not written in files. Network modules write backup files on the control node, usually in the `backup` directory under the playbook root directory." -msgstr "ネットワークモジュールも、``backup`` オプションを提供するモジュールのバックアップファイルの宛先としてコントロールノードを使用します。Linux/Unix モジュールでは、管理ノードに設定ファイルがすでに存在する場合に、デフォルトでは、新しい変更したファイルと同じディレクトリーにバックアップファイルが書き込まれます。ネットワーク設定はファイルに書き込まれないため、ネットワークモジュールは管理ノード上の構成ファイルを更新しません。ネットワークモジュールは、通常は Playbook のルートディレクトリーの下の `backup` ディレクトリーにあるコントロールノードにバックアップファイルを書き込みます。" - -#: ../../rst/network/getting_started/network_differences.rst:18 -msgid "Multiple communication protocols" -msgstr "複数の通信プロトコル" - -#: ../../rst/network/getting_started/network_differences.rst:20 -msgid "Because network modules execute on the control node instead of on the managed nodes, they can support multiple communication protocols. The communication protocol (XML over SSH, CLI over SSH, API over HTTPS) selected for each network module depends on the platform and the purpose of the module. Some network modules support only one protocol; some offer a choice. The most common protocol is CLI over SSH. You set the communication protocol with the ``ansible_connection`` variable:" -msgstr "ネットワークモジュールは管理ノードではなくコントロールノードで実行されるため、複数の通信プロトコルをサポートできます。各ネットワークモジュールに選択される通信プロトコル (SSH での XML、SSH での CLI、HTTPS での API) は、プラットフォームと、モジュールの目的によって異なります。プロトコルを 1 つしかサポートしていないネットワークモジュールもあります。複数のプロトコルをサポートするプロトコルもあります。最も一般的なプロトコルは CLI over SSH です。``ansible_connection`` 変数を使用して通信プロトコルを設定します。" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "Value of ansible_connection" -msgstr "ansible_connection の値" - -#: ../../rst/network/getting_started/network_differences.rst:1 -#: ../../rst/network/user_guide/platform_ce.rst:23 -#: ../../rst/network/user_guide/platform_cnos.rst:21 -#: ../../rst/network/user_guide/platform_dellos10.rst:21 -#: ../../rst/network/user_guide/platform_dellos6.rst:21 -#: ../../rst/network/user_guide/platform_dellos9.rst:21 -#: ../../rst/network/user_guide/platform_enos.rst:21 -#: ../../rst/network/user_guide/platform_eos.rst:21 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:21 -#: ../../rst/network/user_guide/platform_exos.rst:22 -#: ../../rst/network/user_guide/platform_frr.rst:21 -#: ../../rst/network/user_guide/platform_icx.rst:21 -#: ../../rst/network/user_guide/platform_ios.rst:21 -#: ../../rst/network/user_guide/platform_iosxr.rst:25 -#: ../../rst/network/user_guide/platform_ironware.rst:21 -#: ../../rst/network/user_guide/platform_junos.rst:24 -#: ../../rst/network/user_guide/platform_meraki.rst:21 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:23 -#: ../../rst/network/user_guide/platform_netvisor.rst:22 -#: ../../rst/network/user_guide/platform_nos.rst:22 -#: ../../rst/network/user_guide/platform_nxos.rst:21 -#: ../../rst/network/user_guide/platform_routeros.rst:22 -#: ../../rst/network/user_guide/platform_slxos.rst:22 -#: ../../rst/network/user_guide/platform_voss.rst:22 -#: ../../rst/network/user_guide/platform_vyos.rst:21 -msgid "Protocol" -msgstr "プロトコル" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "Requires" -msgstr "必須" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "Persistent?" -msgstr "永続的?" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "ansible.netcommon.network_cli" -msgstr "ansible.netcommon.network_cli" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "CLI over SSH" -msgstr "SSH での CLI" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "network_os setting" -msgstr "network_os の設定" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "yes" -msgstr "はい" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "ansible.netcommon.netconf" -msgstr "ansible.netcommon.netconf" - -#: ../../rst/network/getting_started/network_differences.rst:1 -#: ../../rst/network/user_guide/platform_ce.rst:23 -#: ../../rst/network/user_guide/platform_iosxr.rst:25 -#: ../../rst/network/user_guide/platform_junos.rst:24 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:23 -msgid "XML over SSH" -msgstr "SSH での XML" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "ansible.netcommon.httpapi" -msgstr "ansible.netcommon.httpapi" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "API over HTTP/HTTPS" -msgstr "HTTP/HTTPS での API" - -#: ../../rst/network/getting_started/network_differences.rst:1 -#: ../../rst/network/user_guide/platform_index.rst:60 -msgid "local" -msgstr "ローカル" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "depends on provider" -msgstr "プロバイダーによって異なる" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "provider setting" -msgstr "プロバイダー設定" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "no" -msgstr "いいえ" - -#: ../../rst/network/getting_started/network_differences.rst:32 -msgid "``ansible.netcommon.httpapi`` deprecates ``eos_eapi`` and ``nxos_nxapi``. See :ref:`httpapi_plugins` for details and an example." -msgstr "``ansible.netcommon.httpapi`` は、``eos_eapi`` および ``nxos_nxapi`` を非推奨とします。詳細と例は「:ref:`httpapi_plugins`」参照してください。" - -#: ../../rst/network/getting_started/network_differences.rst:34 -msgid "The ``ansible_connection: local`` has been deprecated. Please use one of the persistent connection types listed above instead. With persistent connections, you can define the hosts and credentials only once, rather than in every task. You also need to set the ``network_os`` variable for the specific network platform you are communicating with. For more details on using each connection type on various platforms, see the :ref:`platform-specific ` pages." -msgstr "``ansible_connection: local`` は非推奨になりました。代わりに、上記の永続的接続タイプのいずれかを使用してください。永続的接続では、すべてのタスクに対してではなく、ホストと認証情報を 1 回だけ定義できます。また、通信する特定のネットワークプラットフォームの ``network_os`` 変数も設定する必要があります。さまざまなプラットフォームでの各接続タイプの使用の詳細は、「:ref:`platform-specific `」を参照してください。" - -#: ../../rst/network/getting_started/network_differences.rst:38 -msgid "Collections organized by network platform" -msgstr "ネットワークプラットフォーム別に整理されたコレクション" - -#: ../../rst/network/getting_started/network_differences.rst:40 -msgid "A network platform is a set of network devices with a common operating system that can be managed by an Ansible collection, for example:" -msgstr "ネットワークプラットフォームは、Ansible コレクションで管理できる共通のオペレーティングシステムを備えたネットワークデバイスセットです。以下に例を示します。" - -#: ../../rst/network/getting_started/network_differences.rst:42 -msgid "Arista: `arista.eos `_" -msgstr "Arista: `arista.eos `_" - -#: ../../rst/network/getting_started/network_differences.rst:43 -msgid "Cisco: `cisco.ios `_, `cisco.iosxr `_, `cisco.nxos `_" -msgstr "Cisco: `cisco.ios `_、`cisco.iosxr `_、`cisco.nxos `_" - -#: ../../rst/network/getting_started/network_differences.rst:44 -msgid "Juniper: `junipernetworks.junos `_" -msgstr "Juniper: `junipernetworks.junos `_" - -#: ../../rst/network/getting_started/network_differences.rst:45 -msgid "VyOS `vyos.vyos `_" -msgstr "VyOS `vyos.vyos `_" - -#: ../../rst/network/getting_started/network_differences.rst:47 -msgid "All modules within a network platform share certain requirements. Some network platforms have specific differences - see the :ref:`platform-specific ` documentation for details." -msgstr "ネットワークプラットフォーム内のすべてのモジュールは特定の要件を共有します。ネットワークプラットフォームによっては、特定の相違点があります。詳細は、:ref:`platform-specific ` ドキュメントを参照してください。" - -#: ../../rst/network/getting_started/network_differences.rst:52 -msgid "Privilege Escalation: ``enable`` mode, ``become``, and ``authorize``" -msgstr "特権エスカレーション: ``enable`` モード、``become``、および ``authorize``" - -#: ../../rst/network/getting_started/network_differences.rst:54 -msgid "Several network platforms support privilege escalation, where certain tasks must be done by a privileged user. On network devices this is called the ``enable`` mode (the equivalent of ``sudo`` in \\*nix administration). Ansible network modules offer privilege escalation for those network devices that support it. For details of which platforms support ``enable`` mode, with examples of how to use it, see the :ref:`platform-specific ` documentation." -msgstr "一部のネットワークプラットフォームでは特権エスカレーションがサポートされており、特権を持つユーザーが特定のタスクを実行する必要があります。ネットワークデバイスでは、これを ``enable`` モードと呼びます (\\*nix 管理における ``sudo`` と同等)。Ansible ネットワークモジュールは、それをサポートするネットワークデバイスに特権エスカレーションを提供します。``enable`` モードをサポートプラットフォームとその使用例については、:ref:`platform-specific ` ドキュメントを参照してください。" - -#: ../../rst/network/getting_started/network_differences.rst:57 -msgid "Using ``become`` for privilege escalation" -msgstr "権限昇格に ``become`` を使用" - -#: ../../rst/network/getting_started/network_differences.rst:59 -msgid "Use the top-level Ansible parameter ``become: yes`` with ``become_method: enable`` to run a task, play, or playbook with escalated privileges on any network platform that supports privilege escalation. You must use either ``connection: network_cli`` or ``connection: httpapi`` with ``become: yes`` with ``become_method: enable``. If you are using ``network_cli`` to connect Ansible to your network devices, a ``group_vars`` file would look like:" -msgstr "特権昇格をサポートする任意のネットワークプラットフォームで、昇格された特権を使用してタスク、プレイ、または Playbook を実行するには、``become_method: enable`` の Ansible 最上位パラメーター ``become: yes`` を使用します。``connection: network_cli`` または ``connection: httpapi`` を、``become: yes`` と ``become_method: enable`` とともに使用する必要があります。``network_cli`` を使用して Ansible をネットワークデバイスに接続している場合、``group_vars`` ファイルは次のようになります。" - -#: ../../rst/network/getting_started/network_differences.rst:68 -msgid "For more information, see :ref:`Become and Networks`" -msgstr "詳細情報は、「:ref:`Become およびネットワーク`」を参照してください。" - -#: ../../rst/network/getting_started/network_resources.rst:6 -msgid "Resources and next steps" -msgstr "リソースと次のステップ" - -#: ../../rst/network/getting_started/network_resources.rst:12 -msgid "Documents" -msgstr "ドキュメント" - -#: ../../rst/network/getting_started/network_resources.rst:14 -msgid "Read more about Ansible for Network Automation:" -msgstr "ネットワーク自動化での Ansible の詳細は、次を参照してください。" - -#: ../../rst/network/getting_started/network_resources.rst:16 -msgid "Network Automation on the `Ansible website `_" -msgstr "`Ansible Web サイト `_ 上のネットワーク自動化" - -#: ../../rst/network/getting_started/network_resources.rst:17 -msgid "Ansible Network `Blog posts `_" -msgstr "Ansible ネットワークの `ブログ投稿 `_" - -#: ../../rst/network/getting_started/network_resources.rst:20 -msgid "Events (on video and in person)" -msgstr "イベント (ビデオおよび個人)" - -#: ../../rst/network/getting_started/network_resources.rst:22 -msgid "All sessions at Ansible events are recorded and include many Network-related topics (use Filter by Category to view only Network topics). You can also join us for future events in your area. See:" -msgstr "Ansible イベントにおけるセッションはすべて録画されており、ネットワーク関連のトピックが多数含まれています (「Filter by Category」を使用して、ネットワークトピックのみを表示します)。また、お住まいの地域で今後開催されるイベントにもご参加いただけます。以下を参照してください。" - -#: ../../rst/network/getting_started/network_resources.rst:24 -msgid "`Recorded AnsibleFests `_" -msgstr "`AnsibleFests (録画) `_" - -#: ../../rst/network/getting_started/network_resources.rst:25 -msgid "`Recorded AnsibleAutomates `_" -msgstr "`AnsibleAutomates (録画) `_" - -#: ../../rst/network/getting_started/network_resources.rst:26 -msgid "`Upcoming Ansible Events `_ page." -msgstr "`今後の Ansible イベント `_ ページ。" - -#: ../../rst/network/getting_started/network_resources.rst:29 -msgid "GitHub repos" -msgstr "GitHub リポジトリー" - -#: ../../rst/network/getting_started/network_resources.rst:31 -msgid "Ansible hosts module code, examples, demonstrations, and other content on GitHub. Anyone with a GitHub account is able to create Pull Requests (PRs) or issues on these repos:" -msgstr "Ansible では、モジュールのコード、サンプル、デモンストレーション、その他のコンテンツを GitHub で公開しています。GitHub のアカウントをお持ちの方は、これらのリポジトリーにプル要求 (PR) や問題を作成することができます。" - -#: ../../rst/network/getting_started/network_resources.rst:33 -msgid "`Network-Automation `_ is an open community for all things network automation. Have an idea, some playbooks, or roles to share? Email ansible-network@redhat.com and we will add you as a contributor to the repository." -msgstr "`Network-Automation `_ は、ネットワーク自動化に関するあらゆることを扱うオープンコミュニティーです。アイディア、Playbook、またはロールを共有しませんか。ansible-network@redhat.com にメールでお問い合わせいただければ、リポジトリーに貢献者として追加されます。" - -#: ../../rst/network/getting_started/network_resources.rst:35 -msgid "`Ansible collections `_ is the main repository for Ansible-maintained and community collections, including collections for network devices." -msgstr "`Ansible コレクション `_ は、Ansible が管理しているコレクションおよびコミュニティーコレクションの主なリポジトリーです。これにはネットワークデバイスのコレクションが含まれます。" - -#: ../../rst/network/getting_started/network_resources.rst:40 -msgid "IRC and Slack" -msgstr "IRC および Slack" - -#: ../../rst/network/getting_started/network_resources.rst:42 -msgid "Join us on:" -msgstr "以下に参加してください。" - -#: ../../rst/network/getting_started/network_resources.rst:44 -msgid "Freenode IRC - ``#ansible-network`` Freenode channel" -msgstr "Freenode IRC - ``#ansible-network`` Freenode チャンネル" - -#: ../../rst/network/getting_started/network_resources.rst:46 -msgid "Slack - ``_" -msgstr "Slack - ``_" - -#: ../../rst/network/getting_started/network_roles.rst:6 -msgid "Use Ansible network roles" -msgstr "Ansible ネットワークロールの使用" - -#: ../../rst/network/getting_started/network_roles.rst:8 -msgid "Roles are sets of Ansible defaults, files, tasks, templates, variables, and other Ansible components that work together. As you saw on :ref:`first_network_playbook`, moving from a command to a playbook makes it easy to run multiple tasks and repeat the same tasks in the same order. Moving from a playbook to a role makes it even easier to reuse and share your ordered tasks. You can look at :ref:`Ansible Galaxy `, which lets you share your roles and use others' roles, either directly or as inspiration." -msgstr "ロールは、Ansible のデフォルト、ファイル、タスク、テンプレート、変数、およびその他の Ansible コンポーネントのセットで、連携して動作します。:ref:`first_network_playbook` でこれまで見てきたように、コマンドから Playbook に移動すると、複数のタスクを簡単に実行し、同じタスクを同じ順序で繰り返すことができます。Playbook からロールに移動すると、注文したタスクの再利用と共有がさらに簡単になります。:ref:`Ansible Galaxy ` では、自分のロールを共有したり、他の人のロールを直接またはインスピレーションとして使用したりできます。" - -#: ../../rst/network/getting_started/network_roles.rst:14 -msgid "Understanding roles" -msgstr "ロールについて" - -#: ../../rst/network/getting_started/network_roles.rst:16 -msgid "So what exactly is a role, and why should you care? Ansible roles are basically playbooks broken up into a known file structure. Moving to roles from a playbook makes sharing, reading, and updating your Ansible workflow easier. Users can write their own roles. So for example, you don't have to write your own DNS playbook. Instead, you specify a DNS server and a role to configure it for you." -msgstr "では、ロールとは正確には何なのか、そしてなぜそれが必要なのでしょうか。Ansible ロールは基本的に、既知のファイル構造に分割された Playbook です。Playbook からロールに移動することで、Ansible ワークフローの共有、読み取り、および更新が簡単になります。ユーザーは独自のロールを作成できます。たとえば、独自の DNS Playbook を作成する必要はありません。代わりに、DNS サーバーと、DNS サーバーを構成するロールを指定します。" - -#: ../../rst/network/getting_started/network_roles.rst:18 -msgid "To simplify your workflow even further, the Ansible Network team has written a series of roles for common network use cases. Using these roles means you don't have to reinvent the wheel. Instead of writing and maintaining your own ``create_vlan`` playbooks or roles, you can concentrate on designing, codifying and maintaining the parser templates that describe your network topologies and inventory, and let Ansible's network roles do the work. See the `network-related roles `_ on Ansible Galaxy." -msgstr "ワークフローをさらに単純化するために、Ansible Network チームは一般的なネットワークのユースケースのための一連のロールを作成しました。これらのロールを使用すると、車輪を再発明する必要がなくなります。独自の ``create_vlan`` Playbook やロールを作成して管理する代わりに、Ansible のネットワークロールにその作業を任せることで、ネットワークトポロジーやインベントリーを記述するパーサーテンプレートの設計、コード化、および管理に集中することができます。Ansible Galaxyの「`ネットワーク関連のロール `_」を見てください。" - -#: ../../rst/network/getting_started/network_roles.rst:21 -msgid "A sample DNS playbook" -msgstr "DNS Playbook のサンプル" - -#: ../../rst/network/getting_started/network_roles.rst:23 -msgid "To demonstrate the concept of what a role is, the example ``playbook.yml`` below is a single YAML file containing a two-task playbook. This Ansible Playbook configures the hostname on a Cisco IOS XE device, then it configures the DNS (domain name system) servers." -msgstr "ロールの概念を説明するために、下記の例 ``playbook.yml`` は 2 つのタスクの Playbook を含む 1 つの YAML ファイルです。この Ansible Playbook は、Cisco IOS XE デバイスでホスト名を設定してから、DNS (ドメインネームシステム) サーバーを設定します。" - -#: ../../rst/network/getting_started/network_roles.rst:44 -msgid "If you run this playbook using the ``ansible-playbook`` command, you'll see the output below. This example used ``-l`` option to limit the playbook to only executing on the **rtr1** node." -msgstr "``ansible-playbook`` コマンドを使用してこの Playbook を実行する場合は、以下の出力が表示されます。この例では、``-l`` オプションを使用して Playbook を **rtr1** ノード上でのみ実行するように制限しています。" - -#: ../../rst/network/getting_started/network_roles.rst:62 -msgid "This playbook configured the hostname and DNS servers. You can verify that configuration on the Cisco IOS XE **rtr1** router:" -msgstr "この Playbook はホスト名および DNS サーバーを設定し、Cisco IOS XE **rtr1** ルーターの設定を確認できます。" - -#: ../../rst/network/getting_started/network_roles.rst:71 -msgid "Convert the playbook into a role" -msgstr "Playbook のロールへの変換" - -#: ../../rst/network/getting_started/network_roles.rst:73 -msgid "The next step is to convert this playbook into a reusable role. You can create the directory structure manually, or you can use ``ansible-galaxy init`` to create the standard framework for a role." -msgstr "次の手順では、この Playbook を再利用可能なロールに変換します。ディレクトリー構造を手動で作成するか、``ansible-galaxy init`` を使用してロールの標準フレームワークを作成できます。" - -#: ../../rst/network/getting_started/network_roles.rst:98 -msgid "This first demonstration uses only the **tasks** and **vars** directories. The directory structure would look as follows:" -msgstr "この最初のデモンストレーションは **tasks** ディレクトリーおよび **vars** ディレクトリーのみを使用します。ディレクトリー構造は以下のようになります。" - -#: ../../rst/network/getting_started/network_roles.rst:109 -msgid "Next, move the content of the ``vars`` and ``tasks`` sections from the original Ansible Playbook into the role. First, move the two tasks into the ``tasks/main.yml`` file:" -msgstr "次に、元の Ansible Playbook から ``vars`` セクションおよび ``tasks`` セクションの内容をロールに移動します。まず、2 つのタスクを ``tasks/main.yml`` ファイルに移動します。" - -#: ../../rst/network/getting_started/network_roles.rst:123 -msgid "Next, move the variables into the ``vars/main.yml`` file:" -msgstr "次に、変数を ``vars/main.yml`` ファイルに移動します。" - -#: ../../rst/network/getting_started/network_roles.rst:131 -msgid "Finally, modify the original Ansible Playbook to remove the ``tasks`` and ``vars`` sections and add the keyword ``roles`` with the name of the role, in this case ``system-demo``. You'll have this playbook:" -msgstr "最後に、元の Ansible Playbook を変更して ``tasks`` セクションおよび ``vars`` セクションを削除し、ロールの名前 (ここでは ``system-demo``) でキーワード ``roles`` を追加します。これで、Playbook が完成します。" - -#: ../../rst/network/getting_started/network_roles.rst:144 -msgid "To summarize, this demonstration now has a total of three directories and three YAML files. There is the ``system-demo`` folder, which represents the role. This ``system-demo`` contains two folders, ``tasks`` and ``vars``. There is a ``main.yml`` is each respective folder. The ``vars/main.yml`` contains the variables from ``playbook.yml``. The ``tasks/main.yml`` contains the tasks from ``playbook.yml``. The ``playbook.yml`` file has been modified to call the role rather than specifying vars and tasks directly. Here is a tree of the current working directory:" -msgstr "要約すると、このデモには合計 3 つのディレクトリーと 3 つの YAML ファイルがあります。ロールを表す ``system-demo`` ディレクトリーがあります。この ``system-demo`` には、``tasks`` および ``vars`` の 2 つのディレクトリーが含まれています。各ディレクトリーに ``main.yml`` があります。``vars/main.yml`` には、``playbook.yml`` の変数が含まれます。``tasks/main.yml`` には、``playbook.yml`` のタスクが含まれます。``playbook.yml`` ファイルは、変数とタスクを直接指定するのではなく、ロールを呼び出すように変更されています。現在の作業ディレクトリーのツリーを次に示します。" - -#: ../../rst/network/getting_started/network_roles.rst:157 -msgid "Running the playbook results in identical behavior with slightly different output:" -msgstr "Playbook を実行すると、同じ動作で、出力が若干異なります。" - -#: ../../rst/network/getting_started/network_roles.rst:174 -msgid "As seen above each task is now prepended with the role name, in this case ``system-demo``. When running a playbook that contains several roles, this will help pinpoint where a task is being called from. This playbook returned ``ok`` instead of ``changed`` because it has identical behavior for the single file playbook we started from." -msgstr "上記のように、各タスクの先頭にロール名が付加されます (``system-demo`` の場合)。複数のロールを含む Playbook を実行する場合、タスクの呼び出し元を特定するのに役立ちます。このPlaybook は、``changed`` ではなく ``ok`` を返しますが、これは、開始した単一ファイルの Playbook と同じ動作をするためです。" - -#: ../../rst/network/getting_started/network_roles.rst:176 -msgid "As before, the playbook will generate the following configuration on a Cisco IOS-XE router:" -msgstr "前述のように、Playbook は Cisco IOS-XE ルーターで以下の設定を生成します。" - -#: ../../rst/network/getting_started/network_roles.rst:185 -msgid "This is why Ansible roles can be simply thought of as deconstructed playbooks. They are simple, effective and reusable. Now another user can simply include the ``system-demo`` role instead of having to create a custom \"hard coded\" playbook." -msgstr "このため、Ansible ロールは、簡単に言えば、分解された Playbook と考えることができます。ロールは、シンプルで、効果的で、再利用可能です。これで、別のユーザーがカスタムの「ハードコーディングされた」Playbook を作成する代わりに、``system-demo`` ロールを含めるだけで十分となります。" - -#: ../../rst/network/getting_started/network_roles.rst:188 -msgid "Variable precedence" -msgstr "変数の優先順位" - -#: ../../rst/network/getting_started/network_roles.rst:190 -msgid "What if you want to change the DNS servers? You aren't expected to change the ``vars/main.yml`` within the role structure. Ansible has many places where you can specify variables for a given play. See :ref:`playbooks_variables` for details on variables and precedence. There are actually 21 places to put variables. While this list can seem overwhelming at first glance, the vast majority of use cases only involve knowing the spot for variables of least precedence and how to pass variables with most precedence. See :ref:`ansible_variable_precedence` for more guidance on where you should put variables." -msgstr "DNS サーバーを変更する場合はどうすればよいですか。ロール構造内の ``vars/main.yml`` を変更する必要はありません。Ansible には、特定のプレイの変数を指定できる場所が多数あります。変数と優先順位の詳細は、「:ref:`playbooks_variables`」を参照してください。変数を置く場所は実際には 21 箇所あります。これは一見圧倒されるような数ですが、大半のユースケースでは、優先順位が最も低い変数の場所と、最も優先順位の高い変数を渡す方法を知るだけですみます。変数をどこに置くべきかは、「:ref:`ansible_variable_precedence`」を参照してください。" - -#: ../../rst/network/getting_started/network_roles.rst:193 -msgid "Lowest precedence" -msgstr "最も低い優先順位" - -#: ../../rst/network/getting_started/network_roles.rst:195 -msgid "The lowest precedence is the ``defaults`` directory within a role. This means all the other 20 locations you could potentially specify the variable will all take higher precedence than ``defaults``, no matter what. To immediately give the vars from the ``system-demo`` role the least precedence, rename the ``vars`` directory to ``defaults``." -msgstr "最も低い優先順位は、ロール内の ``defaults`` ディレクトリーです。つまり、変数を指定できる可能性のある他の 20 箇所はすべて、``defaults`` より優先されます。``system-demo`` ロールの変数の優先順位を直ちに最も低くするには、``vars`` ディレクトリーの名前を ``defaults`` に変更します。" - -#: ../../rst/network/getting_started/network_roles.rst:207 -msgid "Add a new ``vars`` section to the playbook to override the default behavior (where the variable ``dns`` is set to 8.8.8.8 and 8.8.4.4). For this demonstration, set ``dns`` to 1.1.1.1, so ``playbook.yml`` becomes:" -msgstr "デフォルトの動作を上書きするために、Playbook に新しい ``vars`` セクションを追加します (ここでは、``dns`` 変数が 8.8.8.8 および 8.8.4.4 に設定されています)。このデモでは、``dns`` を 1.1.1.1 に設定するため、``playbook.yml`` は次のようになります。" - -#: ../../rst/network/getting_started/network_roles.rst:221 -msgid "Run this updated playbook on **rtr2**:" -msgstr "更新した Playbook を **rtr2** で実行します。" - -#: ../../rst/network/getting_started/network_roles.rst:227 -msgid "The configuration on the **rtr2** Cisco router will look as follows:" -msgstr "**rtr2** Cisco ルーターの設定は以下のようになります。" - -#: ../../rst/network/getting_started/network_roles.rst:234 -msgid "The variable configured in the playbook now has precedence over the ``defaults`` directory. In fact, any other spot you configure variables would win over the values in the ``defaults`` directory." -msgstr "Playbook に設定した変数は、``defaults`` ディレクトリーよりも優先されます。実際には、変数に設定したその他のスポットは、``defaults`` ディレクトリーの値よりも優先されます。" - -#: ../../rst/network/getting_started/network_roles.rst:237 -msgid "Highest precedence" -msgstr "最も高い優先順位" - -#: ../../rst/network/getting_started/network_roles.rst:239 -msgid "Specifying variables in the ``defaults`` directory within a role will always take the lowest precedence, while specifying ``vars`` as extra vars with the ``-e`` or ``--extra-vars=`` will always take the highest precedence, no matter what. Re-running the playbook with the ``-e`` option overrides both the ``defaults`` directory (8.8.4.4 and 8.8.8.8) as well as the newly created ``vars`` within the playbook that contains the 1.1.1.1 dns server." -msgstr "ロール内の ``defaults`` ディレクトリーに変数を指定すると、常に優先順位が最も低くなりますが、``-e`` または ``--extra-vars=`` を使用して追加変数として ``vars`` を指定すると、優先順位が最も高くなります。``-e`` オプションを指定して Playbook を再実行すると、``defaults`` ディレクトリー (8.8.4.4 および 8.8.8.8) だけでなく、1.1.1.1 dns サーバーを含む Playbook 内に新しく作成された ``vars`` も上書きされます。" - -#: ../../rst/network/getting_started/network_roles.rst:245 -msgid "The result on the Cisco IOS XE router will only contain the highest precedence setting of 192.168.1.1:" -msgstr "Cisco IOS XE ルーターの結果には、優先順位の最も高い 192.168.1.1 設定のみが含まれます。" - -#: ../../rst/network/getting_started/network_roles.rst:252 -msgid "How is this useful? Why should you care? Extra vars are commonly used by network operators to override defaults. A powerful example of this is with Red Hat Ansible Tower and the Survey feature. It is possible through the web UI to prompt a network operator to fill out parameters with a Web form. This can be really simple for non-technical playbook writers to execute a playbook using their Web browser. See `Ansible Tower Job Template Surveys `_ for more details." -msgstr "これはどのように役立つのでしょうか。なぜ気にする必要があるのでしょうか。ネットワークオペレーターは通常、追加の変数を使用してデフォルトを上書きします。その良い例は、Red Hat Ansible Tower と Survey 機能です。Web UI を使用して、ネットワークオペレーターに Web フォームでパラメーターの入力を求めることができます。これは、技術に詳しくない Playbook 作成者が Web ブラウザーを使用して Playbook を実行する場合に非常に簡単です。詳細は、「`Ansible Tower ジョブテンプレートサーベイ `_」を参照してください。" - -#: ../../rst/network/getting_started/network_roles.rst:256 -msgid "Update an installed role" -msgstr "インストールされたロールの更新" - -#: ../../rst/network/getting_started/network_roles.rst:258 -msgid "The Ansible Galaxy page for a role lists all available versions. To update a locally installed role to a new or different version, use the ``ansible-galaxy install`` command with the version and ``--force`` option. You may also need to manually update any dependent roles to support this version. See the role **Read Me** tab in Galaxy for dependent role minimum version requirements." -msgstr "ロールの Ansible Galaxy ページには、使用可能なすべてのバージョンが一覧表示されます。ローカルにインストールされたロールを新しいバージョンまたは別のバージョンに更新するには、``ansible-galaxy install`` コマンドにバージョンおよび ``--force`` オプションを指定して使用します。また、このバージョンをサポートするために、依存ロールを手動で更新しないといけない場合もあります。依存ロールの最小バージョン要件については、Galaxy のロールの「Read Me」タブを参照してください。" - -#: ../../rst/network/getting_started/network_roles.rst:266 -msgid "`Ansible Galaxy documentation `_" -msgstr "`Ansible Galaxy ドキュメント `_" - -#: ../../rst/network/getting_started/network_roles.rst:267 -msgid "Ansible Galaxy user guide" -msgstr "Ansible Galaxy ユーザーガイド" - -#: ../../rst/network/index.rst:7 -msgid "Ansible for Network Automation" -msgstr "ネットワークの自動化における Ansible" - -#: ../../rst/network/index.rst:9 -msgid "Ansible Network modules extend the benefits of simple, powerful, agentless automation to network administrators and teams. Ansible Network modules can configure your network stack, test and validate existing network state, and discover and correct network configuration drift." -msgstr "Ansible Network モジュールは、シンプルで強力なエージェントレス自動化の利点をネットワーク管理者とチームに拡張します。Ansible Network モジュールは、ネットワークスタックを構成し、既存のネットワーク状態をテストおよび検証し、ネットワーク構成のドリフトを検出して修正できます。" - -#: ../../rst/network/index.rst:11 -msgid "If you're new to Ansible, or new to using Ansible for network management, start with :ref:`network_getting_started`. If you are already familiar with network automation with Ansible, see :ref:`network_advanced`." -msgstr "Ansible を初めて使用する場合や、ネットワーク管理に Ansible を初めて使用する場合は、:ref:`network_getting_started` から開始します。Ansible とのネットワーク自動化に精通している場合は、「:ref:`network_advanced`」を参照してください。" - -#: ../../rst/network/index.rst:13 -msgid "For documentation on using a particular network module, consult the :ref:`list of all network modules`. Network modules for various hardware are supported by different teams including the hardware vendors themselves, volunteers from the Ansible community, and the Ansible Network Team." -msgstr "特定のネットワークモジュールの使用に関するドキュメントについては、「:ref:`ネットワークモジュールの一覧`」を参照してください。さまざまなハードウェアのネットワークモジュールが、ハードウェアベンダー自体、Ansible コミュニティーのボランティア、Ansible ネットワークチームなど、さまざまなチームにサポートされています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:5 -msgid "Parsing semi-structured text with Ansible" -msgstr "Ansible を使用した半構造化テキストの解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:7 -msgid "The :ref:`cli_parse ` module parses semi-structured data such as network configurations into structured data to allow programmatic use of the data from that device. You can pull information from a network device and update a CMDB in one playbook. Use cases include automated troubleshooting, creating dynamic documentation, updating IPAM (IP address management) tools and so on." -msgstr ":ref:`cli_parse ` モジュールは、ネットワーク構成などの半構造化データを構造化データに解析して、そのデバイスからのデータをプログラムで使用できるようにします。ネットワークデバイスから情報を取得し、1 つの Playbook で CMDB を更新できます。ユースケースには、自動トラブルシューティング、動的ドキュメントの作成、IPAM (IPアドレス管理) ツールの更新などがあります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:15 -msgid "Understanding the CLI parser" -msgstr "CLI パーサーについて" - -#: ../../rst/network/user_guide/cli_parsing.rst:17 -msgid "The `ansible.netcommon `_ collection version 1.2.0 or later includes the :ref:`cli_parse ` module that can run CLI commands and parse the semi-structured text output. You can use the ``cli_parse`` module on a device, host, or platform that only supports a command-line interface and the commands issued return semi-structured text. The ``cli_parse`` module can either run a CLI command on a device and return a parsed result or can simply parse any text document. The ``cli_parse`` module includes cli_parser plugins to interface with a variety of parsing engines." -msgstr "`ansible.netcommon `_ コレクションバージョン 1.2.0 以降には、CLI コマンドを実行し、半構造化テキスト出力を解析できる :ref:`cli_parse ` モジュールが含まれています。コマンドラインインタフェースのみをサポートするデバイス、ホスト、またはプラットフォームで ``cli_parse`` モジュールを使用でき、実行したコマンドは半構造化テキストを返します。``cli_parse`` モジュールは、デバイス上で CLI コマンドを実行して解析結果を返すことも、単純にテキストドキュメントを解析することもできます。``cli_parse`` モジュールには、さまざまな解析エンジンとのインタフェースとなる cli_parser プラグインが含まれています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:20 -msgid "Why parse the text?" -msgstr "テキストを解析する理由" - -#: ../../rst/network/user_guide/cli_parsing.rst:22 -msgid "Parsing semi-structured data such as network configurations into structured data allows programmatic use of the data from that device. Use cases include automated troubleshooting, creating dynamic documentation, updating IPAM (IP address management) tools and so on. You may prefer to do this with Ansible natively to take advantage of native Ansible constructs such as:" -msgstr "ネットワーク構成などの半構造化データを構造化データに解析すると、そのデバイスのデータをプログラムで使用できます。ユースケースには、自動トラブルシューティング、動的ドキュメントの作成、IPAM (IPアドレス管理) ツールの更新などがあります。このような作業は、Ansible でネイティブに行う方が、以下のような Ansible のネイティブな構成を活用できるかもしれません。" - -#: ../../rst/network/user_guide/cli_parsing.rst:24 -msgid "The ``when`` clause to conditionally run other tasks or roles" -msgstr "他のタスクまたはロールを条件的に実行する ``when`` 句" - -#: ../../rst/network/user_guide/cli_parsing.rst:25 -msgid "The ``assert`` module to check configuration and operational state compliance" -msgstr "設定と運用状態コンプライアンスを確認するための ``assert`` モジュール" - -#: ../../rst/network/user_guide/cli_parsing.rst:26 -msgid "The ``template`` module to generate reports about configuration and operational state information" -msgstr "設定および運用の状態情報に関するレポートを生成する ``template`` モジュール" - -#: ../../rst/network/user_guide/cli_parsing.rst:27 -msgid "Templates and ``command`` or ``config`` modules to generate host, device, or platform commands or configuration" -msgstr "ホスト、デバイス、またはプラットフォームコマンドまたは設定を生成するテンプレートおよび ``command`` モジュールまたは ``config`` モジュール" - -#: ../../rst/network/user_guide/cli_parsing.rst:28 -msgid "The current platform ``facts`` modules to supplement native facts information" -msgstr "ネイティブファクト情報を補足する現在のプラットフォームの ``facts`` モジュール" - -#: ../../rst/network/user_guide/cli_parsing.rst:30 -msgid "By parsing semi-structured text into Ansible native data structures, you can take full advantage of Ansible's network modules and plugins." -msgstr "半構造化テキストを Ansible のネイティブデータ構造に解析することで、Ansible のネットワークモジュールおよびプラグインを完全に活用できます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:34 -msgid "When not to parse the text" -msgstr "テキストを解析しない場合" - -#: ../../rst/network/user_guide/cli_parsing.rst:36 -msgid "You should not parse semi-structured text when:" -msgstr "以下の場合は、半構造化されたテキストを解析しないでください。" - -#: ../../rst/network/user_guide/cli_parsing.rst:38 -msgid "The device, host, or platform has a RESTAPI and returns JSON." -msgstr "デバイス、ホスト、またはプラットフォームには RESTAPI があり、JSON を返します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:39 -msgid "Existing Ansible facts modules already return the desired data." -msgstr "既存の Ansible ファクトモジュールは、すでに必要なデータを返しています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:40 -msgid "Ansible network resource modules exist for configuration management of the device and resource." -msgstr "デバイスおよびリソースの設定管理には、Ansible ネットワークリソースモジュールがあります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:43 -msgid "Parsing the CLI" -msgstr "CLI の解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:45 -msgid "The ``cli_parse`` module includes the following cli_parsing plugins:" -msgstr "``cli_parse`` モジュールには、以下の cli_parsing プラグインが含まれます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:47 -msgid "``native``" -msgstr "``native``" - -#: ../../rst/network/user_guide/cli_parsing.rst:48 -msgid "The native parsing engine built into Ansible and requires no addition python libraries" -msgstr "Ansible に組み込まれたネイティブの解析エンジンで、Python ライブラリーを追加する必要はありません。" - -#: ../../rst/network/user_guide/cli_parsing.rst:49 -msgid "``xml``" -msgstr "``xml``" - -#: ../../rst/network/user_guide/cli_parsing.rst:50 -msgid "Convert XML to an Ansible native data structure" -msgstr "XML の Ansible ネイティブデータ構造への変換" - -#: ../../rst/network/user_guide/cli_parsing.rst:51 -msgid "``textfsm``" -msgstr "``textfsm``" - -#: ../../rst/network/user_guide/cli_parsing.rst:52 -msgid "A python module which implements a template based state machine for parsing semi-formatted text" -msgstr "半フォーマット化テキストを解析するためにテンプレートベースの状態マシンを実装する Python モジュール" - -#: ../../rst/network/user_guide/cli_parsing.rst:53 -msgid "``ntc_templates``" -msgstr "``ntc_templates``" - -#: ../../rst/network/user_guide/cli_parsing.rst:54 -msgid "Predefined ``textfsm`` templates packages supporting a variety of platforms and commands" -msgstr "さまざまなプラットフォームおよびコマンドをサポートする事前定義された ``textfsm`` テンプレートパッケージ" - -#: ../../rst/network/user_guide/cli_parsing.rst:55 -msgid "``ttp``" -msgstr "``ttp``" - -#: ../../rst/network/user_guide/cli_parsing.rst:56 -msgid "A library for semi-structured text parsing using templates, with added capabilities to simplify the process" -msgstr "処理を簡略化する機能が追加されている、テンプレートを利用した半構造化テキストの解析用ライブラリー" - -#: ../../rst/network/user_guide/cli_parsing.rst:57 -msgid "``pyats``" -msgstr "``pyats``" - -#: ../../rst/network/user_guide/cli_parsing.rst:58 -msgid "Uses the parsers included with the Cisco Test Automation & Validation Solution" -msgstr "Cisco Test Automation & Validation Solution に含まれるパーサーを使用します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:60 -msgid "``json``" -msgstr "``json``" - -#: ../../rst/network/user_guide/cli_parsing.rst:60 -msgid "Converts JSON output at the CLI to an Ansible native data structure" -msgstr "CLI での JSON 出力を Ansible ネイティブデータ構造に変換" - -#: ../../rst/network/user_guide/cli_parsing.rst:62 -#: ../../rst/network/user_guide/cli_parsing.rst:589 -msgid "Although Ansible contains a number of plugins that can convert XML to Ansible native data structures, the ``cli_parse`` module runs the command on devices that return XML and returns the converted data in a single task." -msgstr "Ansible には、XML を Ansible のネイティブデータ構造に変換できる多数のプラグインが含まれていますが、``cli_parse`` モジュールは XML を返すデバイスでコマンドを実行し、変換されたデータを 1 つのタスクで返します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:64 -msgid "Because ``cli_parse`` uses a plugin based architecture, it can use additional parsing engines from any Ansible collection." -msgstr "``cli_parse`` はプラグインベースのアーキテクチャーを使用するため、任意の Ansible コレクションから追加の解析エンジンを使用できます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:68 -msgid "The ``ansible.netcommon.native`` and ``ansible.netcommon.json`` parsing engines are fully supported with a Red Hat Ansible Automation Platform subscription. Red Hat Ansible Automation Platform subscription support is limited to the use of the ``ntc_templates``, pyATS, ``textfsm``, ``xmltodict``, public APIs as documented." -msgstr "解析エンジン ``ansible.netcommon.native`` および ``ansible.netcommon.json`` は、Red Hat Ansible Automation Platform サブスクリプションで完全にサポートされています。Red Hat Ansible Automation Platform サブスクリプションのサポートは、ドキュメントに記載されているように、``ntc_templates``、pyATS、``textfsm``、``xmltodict``、パブリック APIの使用に限定されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:71 -msgid "Parsing with the native parsing engine" -msgstr "ネイティブ解析エンジンを使用した解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:73 -msgid "The native parsing engine is included with the ``cli_parse`` module. It uses data captured using regular expressions to populate the parsed data structure. The native parsing engine requires a YAML template file to parse the command output." -msgstr "ネイティブ解析エンジンは ``cli_parse`` モジュールに含まれています。正規表現を使用して取得されたデータを使用して、解析されたデータ構造を生成します。ネイティブ解析エンジンでは、コマンド出力を解析するために YAML テンプレートファイルが必要です。" - -#: ../../rst/network/user_guide/cli_parsing.rst:76 -msgid "Networking example" -msgstr "ネットワークの例" - -#: ../../rst/network/user_guide/cli_parsing.rst:78 -msgid "This example uses the output of a network device command and applies a native template to produce an output in Ansible structured data format." -msgstr "この例では、ネットワークデバイスコマンドの出力を使用し、ネイティブテンプレートを適用して Ansible 構造のデータ形式で出力を生成します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:80 -msgid "The ``show interface`` command output from the network device looks as follows:" -msgstr "ネットワークデバイスからの ``show interface`` コマンドの出力は以下のようになります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:104 -msgid "Create the native template to match this output and store it as ``templates/nxos_show_interface.yaml``:" -msgstr "この出力に一致するネイティブテンプレートを作成し、これを ``templates/nxos_show_interface.yaml`` として保存します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:134 -msgid "This native parser template is structured as a list of parsers, each containing the following key-value pairs:" -msgstr "このネイティブパーサーテンプレートはパーサーのリストとして構成され、それぞれに以下のキーと値のペアが含まれます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:136 -msgid "``example`` - An example line of the text line to be parsed" -msgstr "``example`` - 解析対象となるテキスト行の一例" - -#: ../../rst/network/user_guide/cli_parsing.rst:137 -msgid "``getval`` - A regular expression using named capture groups to store the extracted data" -msgstr "``getval`` - 展開したデータを保存するために名前付きキャプチャーグループを使用した正規表現" - -#: ../../rst/network/user_guide/cli_parsing.rst:138 -msgid "``result`` - A data tree, populated as a template, from the parsed data" -msgstr "``result`` - 解析されたデータからテンプレートとして生成されたデータツリー" - -#: ../../rst/network/user_guide/cli_parsing.rst:139 -msgid "``shared`` - (optional) The shared key makes the parsed values available to the rest of the parser entries until matched again." -msgstr "``shared`` - (任意) 共有キーは、再一致するまで、残りのパーサーエントリーに解析された値を利用できるようにします。" - -#: ../../rst/network/user_guide/cli_parsing.rst:141 -msgid "The following example task uses ``cli_parse`` with the native parser and the example template above to parse the ``show interface`` command from a Cisco NXOS device:" -msgstr "以下のタスク例では、ネイティブパーサーで ``cli_parse`` と上記のテンプレートのサンプルを使用して、Cisco NXOS デバイスからの ``show interface`` コマンドを解析します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:152 -#: ../../rst/network/user_guide/cli_parsing.rst:300 -#: ../../rst/network/user_guide/cli_parsing.rst:326 -#: ../../rst/network/user_guide/cli_parsing.rst:386 -#: ../../rst/network/user_guide/cli_parsing.rst:495 -msgid "Taking a deeper dive into this task:" -msgstr "このタスクをより深く掘り下げます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:154 -msgid "The ``command`` option provides the command you want to run on the device or host. Alternately, you can provide text from a previous command with the ``text`` option instead." -msgstr "``command`` オプションは、デバイスまたはホストで実行するコマンドを提供します。代わりに、``text`` オプションを指定して、前のコマンドのテキストを指定することもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:155 -msgid "The ``parser`` option provides information specific to the parser engine." -msgstr "``parser`` オプションは、パーサーエンジンに固有の情報を提供します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:156 -msgid "The ``name`` suboption provides the fully qualified collection name (FQCN) of the parsing engine (``ansible.netcommon.native``)." -msgstr "``name`` サブオプションは、解析エンジン (``ansible.netcommon.native``) の完全修飾コレクション名 (FQCN) を提供します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:157 -msgid "The ``cli_parse`` module, by default, looks for the template in the templates directory as ``{{ short_os }}_{{ command }}.yaml``." -msgstr "デフォルトでは、``cli_parse`` モジュールは、templates ディレクトリーで ``{{ short_os }}_{{ command }}.yaml`` と指定してテンプレートを検索します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:159 -msgid "The ``short_os`` in the template filename is derived from either the host ``ansible_network_os`` or ``ansible_distribution``." -msgstr "テンプレートファイル名の ``short_os`` は、ホストの ``ansible_network_os`` または ``ansible_distribution`` から派生します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:160 -msgid "Spaces in the network or host command are replace with ``_`` in the ``command`` portion of the template filename. In this example, the ``show interfaces`` network CLI command becomes ``show_interfaces`` in the filename." -msgstr "network または host コマンドのスペースは、テンプレートファイル名の ``command`` 部分にある ``_`` に置き換えます。この例では、``show interfaces`` network CLI コマンドはファイル名の ``show_interfaces`` になります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:164 -msgid "``ansible.netcommon.native`` parsing engine is fully supported with a Red Hat Ansible Automation Platform subscription." -msgstr "``ansible.netcommon.native`` エンジンの解析は、Red Hat Ansible Automation Platform サブスクリプションで完全にサポートされています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:166 -msgid "Lastly in this task, the ``set_fact`` option sets the following ``interfaces`` fact for the device based on the now-structured data returned from ``cli_parse``:" -msgstr "このタスクの最後で、``set_fact`` オプションは、``interfaces`` から返された現在構造化されているデータに基づいて、デバイスに以下の ``cli_parse`` ファクトを設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:184 -msgid "Linux example" -msgstr "Linux の例" - -#: ../../rst/network/user_guide/cli_parsing.rst:186 -msgid "You can also use the native parser to run commands and parse output from Linux hosts." -msgstr "ネイティブパーサーを使用してコマンドを実行し、Linux ホストからの出力を解析することもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:188 -msgid "The output of a sample Linux command (``ip addr show``) looks as follows:" -msgstr "Linux コマンドの出力例 (``ip addr show``) は以下のようになります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:203 -msgid "Create the native template to match this output and store it as ``templates/fedora_ip_addr_show.yaml``:" -msgstr "この出力に一致するネイティブテンプレートを作成し、これを ``templates/fedora_ip_addr_show.yaml`` として保存します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:241 -msgid "The ``shared`` key in the parser template allows the interface name to be used in subsequent parser entries. The use of examples and free-spacing mode with the regular expressions makes the template easier to read." -msgstr "パーサーテンプレートの ``shared`` キーを使用すると、インターフェース名を後続のパーサーエントリーで使用できます。正規表現で例とフリースペースモードを使用すると、テンプレートが読みやすくなります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:243 -msgid "The following example task uses ``cli_parse`` with the native parser and the example template above to parse the Linux output:" -msgstr "以下のタスク例では、ネイティブパーサーのある ``cli_parse`` と、上記のサンプルテンプレートを使用して Linux の出力を解析します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:254 -msgid "This task assumes you previously gathered facts to determine the ``ansible_distribution`` needed to locate the template. Alternately, you could provide the path in the ``parser/template_path`` option." -msgstr "このタスクでは、以前にファクトを収集してテンプレートを見つけるのに必要な ``ansible_distribution`` を決定することを仮定しています。あるいは、``parser/template_path`` オプションでパスを指定することもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:257 -msgid "Lastly in this task, the ``set_fact`` option sets the following ``interfaces`` fact for the host, based on the now-structured data returned from ``cli_parse``:" -msgstr "このタスクの最後で、``set_fact`` オプションは、``interfaces`` から返された現在構造化されているデータに基づいて、ホストに以下の ``cli_parse`` ファクトを設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:285 -msgid "Parsing JSON" -msgstr "JSON の解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:287 -msgid "Although Ansible will natively convert serialized JSON to Ansible native data when recognized, you can also use the ``cli_parse`` module for this conversion." -msgstr "Ansible は、認識時にシリアライズされた JSON を Ansible ネイティブデータに変換しますが、この変換に ``cli_parse`` モジュールを使用することもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:289 -#: ../../rst/network/user_guide/cli_parsing.rst:315 -#: ../../rst/network/user_guide/cli_parsing.rst:374 -msgid "Example task:" -msgstr "タスクの例:" - -#: ../../rst/network/user_guide/cli_parsing.rst:302 -msgid "The ``show interface | json`` command is issued on the device." -msgstr "``show interface | json`` コマンドはデバイスで発行されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:303 -msgid "The output is set as the ``interfaces`` fact for the device." -msgstr "この出力は、デバイスの ``interfaces`` ファクトとして設定されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:304 -msgid "JSON support is provided primarily for playbook consistency." -msgstr "JSON のサポートは、主に Playbook の一貫性のために提供されています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:308 -msgid "The use of ``ansible.netcommon.json`` is fully supported with a Red Hat Ansible Automation Platform subscription" -msgstr "``ansible.netcommon.json`` の使用は、Red Hat Ansible Automation Platform サブスクリプションで完全にサポートされています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:311 -msgid "Parsing with ntc_templates" -msgstr "ntc_templates での解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:313 -msgid "The ``ntc_templates`` python library includes pre-defined ``textfsm`` templates for parsing a variety of network device commands output." -msgstr "``ntc_templates`` python ライブラリーには、さまざまなネットワークデバイスコマンドの出力を解析する事前定義済みの ``textfsm`` テンプレートが含まれています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:328 -msgid "The ``ansible_network_os`` of the device is converted to the ntc_template format ``cisco_nxos``. Alternately, you can provide the ``os`` with the ``parser/os`` option instead." -msgstr "デバイスの ``ansible_network_os`` は ntc_template 形式 ``cisco_nxos`` に変換されますが、代わりに ``parser/os`` オプションで ``os`` を指定することもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:329 -msgid "The ``cisco_nxos_show_interface.textfsm`` template, included with the ``ntc_templates`` package, parses the output." -msgstr "``cisco_nxos_show_interface.textfsm`` パッケージに含まれる ``ntc_templates`` テンプレートは、出力を解析します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:330 -msgid "See `the ntc_templates README `_ for additional information about the ``ntc_templates`` python library." -msgstr "``ntc_templates`` python ライブラリーに関する追加情報は、`ntc_templates の「README」 `_ を参照してください。" - -#: ../../rst/network/user_guide/cli_parsing.rst:334 -msgid "Red Hat Ansible Automation Platform subscription support is limited to the use of the ``ntc_templates`` public APIs as documented." -msgstr "Red Hat Ansible Automation Platform のサブスクリプションのサポートは、文書化されている ``ntc_templates`` パブリック API の使用に限定されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:337 -msgid "This task and and the predefined template sets the following fact as the ``interfaces`` fact for the host:" -msgstr "このタスクおよび事前定義されたテンプレートは、以下のファクトをホストの ``interfaces`` ファクトとして設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:370 -msgid "Parsing with pyATS" -msgstr "pyATS での解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:372 -msgid "``pyATS`` is part of the Cisco Test Automation & Validation Solution. It includes many predefined parsers for a number of network platforms and commands. You can use the predefined parsers that are part of the ``pyATS`` package with the ``cli_parse`` module." -msgstr "``pyATS`` は、Cisco Test Automation & Validation Solution の一部です。これには、多数のネットワークプラットフォームおよびコマンド用の定義済みパーサーが多数含まれています。``cli_parse`` モジュールでは、``pyATS`` パッケージに同梱される定義済みパーサーを使用できます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:388 -msgid "The ``cli_parse`` modules converts the ``ansible_network_os`` automatically (in this example, ``ansible_network_os`` set to ``cisco.nxos.nxos``, converts to ``nxos`` for pyATS. Alternately, you can set the OS with the ``parser/os`` option instead." -msgstr "``cli_parse`` モジュールは、自動的に ``ansible_network_os`` を変換します (この例では、``ansible_network_os`` は ``cisco.nxos.nxos`` に設定されていますが、pyATS の場合は ``nxos`` に変換されます。代わりに、``parser/os`` オプションを使用して OS を設定することもできます)。" - -#: ../../rst/network/user_guide/cli_parsing.rst:389 -#, python-format -msgid "Using a combination of the command and OS, the pyATS selects the following parser: https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/parsers/show%2520interface." -msgstr "コマンドと OS の組み合わせを使用して、pyATS がパーサー (https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/parsers/show%2520interface) を選択します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:390 -msgid "The ``cli_parse`` module sets ``cisco.ios.ios`` to ``iosxe`` for pyATS. You can override this with the ``parser/os`` option." -msgstr "``cli_parse`` モジュールは、pyATS に対して ``cisco.ios.ios`` を ``iosxe`` に設定します。``parser/os`` オプションでこれを上書きできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:391 -msgid "``cli_parse`` only uses the predefined parsers in pyATS. See the `pyATS documentation `_ and the full list of `pyATS included parsers `_." -msgstr "``cli_parse`` は pyATS の定義済みパーサーのみを使用します。`pyATS ドキュメント `_ と、`pyATS が含まれるパーサー `_ の完全なリストを参照してください。" - -#: ../../rst/network/user_guide/cli_parsing.rst:395 -msgid "Red Hat Ansible Automation Platform subscription support is limited to the use of the pyATS public APIs as documented." -msgstr "Red Hat Ansible Automation Platform のサブスクリプションサポートは、文書化されている pyATS パブリック API の使用に限定されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:398 -#: ../../rst/network/user_guide/cli_parsing.rst:506 -msgid "This task sets the following fact as the ``interfaces`` fact for the host:" -msgstr "このタスクは、ホストの ``interfaces`` ファクトとして以下のファクトを設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:436 -msgid "Parsing with textfsm" -msgstr "textfsm で解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:438 -msgid "``textfsm`` is a Python module which implements a template-based state machine for parsing semi-formatted text." -msgstr "``textfsm`` は、半フォーマットのテキストを解析するためにテンプレートベースの状態マシンを実装する Python モジュールです。" - -#: ../../rst/network/user_guide/cli_parsing.rst:440 -msgid "The following sample``textfsm`` template is stored as ``templates/nxos_show_interface.textfsm``" -msgstr "以下のサンプル ``textfsm`` テンプレートは、``templates/nxos_show_interface.textfsm`` の形式で保存されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:484 -msgid "The following task uses the example template for ``textfsm`` with the ``cli_parse`` module." -msgstr "以下のタスクでは、``textfsm`` モジュールで ``cli_parse`` のサンプルテンプレートを使用します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:497 -msgid "The ``ansible_network_os`` for the device (``cisco.nxos.nxos``) is converted to ``nxos``. Alternately you can provide the OS in the ``parser/os`` option instead." -msgstr "デバイスの ``ansible_network_os`` (``cisco.nxos.nxos``) は ``nxos`` に変換されます。代わりに ``parser/os`` オプションに OS を指定することもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:498 -msgid "The textfsm template name defaulted to ``templates/nxos_show_interface.textfsm`` using a combination of the OS and command run. Alternately you can override the generated template path with the ``parser/template_path`` option." -msgstr "textfsm のテンプレート名は、OS とコマンドランの組み合わせにより、デフォルトで``templates/nxos_show_interface.textfsm`` となっています。また、``parser/template_path`` オプションで、生成されたテンプレートのパスを上書きすることもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:499 -msgid "See the `textfsm README `_ for details." -msgstr "詳細は、`textfsm README `_ を参照してください。" - -#: ../../rst/network/user_guide/cli_parsing.rst:500 -msgid "``textfsm`` was previously made available as a filter plugin. Ansible users should transition to the ``cli_parse`` module." -msgstr "``textfsm`` は、以前はフィルタープラグインとして利用できました。Ansible ユーザーは、``cli_parse`` モジュールに移行する必要があります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:504 -msgid "Red Hat Ansible Automation Platform subscription support is limited to the use of the ``textfsm`` public APIs as documented." -msgstr "Red Hat Ansible Automation Platform のサブスクリプションのサポートは、文書化されている ``textfsm`` パブリック API の使用に限定されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:537 -msgid "Parsing with TTP" -msgstr "TTP での解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:539 -msgid "TTP is a Python library for semi-structured text parsing using templates. TTP uses a jinja-like syntax to limit the need for regular expressions. Users familiar with jinja templating may find the TTP template syntax familiar." -msgstr "TTP は、テンプレートを使用した半構造化テキスト解析用の Python ライブラリーです。TTP は、正規表現の必要性を制限するために、jinja に似た構文を使用します。jinja のテンプレート化に精通しているユーザーは、TTP テンプレートの構文に親しみを感じるかもしれません。" - -#: ../../rst/network/user_guide/cli_parsing.rst:541 -msgid "The following is an example TTP template stored as ``templates/nxos_show_interface.ttp``:" -msgstr "以下は、``templates/nxos_show_interface.ttp`` として保存された TTP テンプレートの例です。" - -#: ../../rst/network/user_guide/cli_parsing.rst:548 -msgid "The following task uses this template to parse the ``show interface`` command output:" -msgstr "以下のタスクでは、このテンプレートを使用して ``show interface`` コマンドの出力を解析します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:559 -msgid "Taking a deeper dive in this task:" -msgstr "このタスクをより深く掘り下げます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:561 -msgid "The default template path ``templates/nxos_show_interface.ttp`` was generated using the ``ansible_network_os`` for the host and ``command`` provided." -msgstr "デフォルトのテンプレートパス ``templates/nxos_show_interface.ttp`` は、ホストの ``ansible_network_os`` と、指定した ``command`` を使用して生成されました。" - -#: ../../rst/network/user_guide/cli_parsing.rst:562 -msgid "TTP supports several additional variables that will be passed to the parser. These include:" -msgstr "TTP は、パーサーに渡される追加変数をサポートします。これには以下が含まれます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:564 -msgid "``parser/vars/ttp_init`` - Additional parameter passed when the parser is initialized." -msgstr "``parser/vars/ttp_init`` - パーサーの初期化時に渡される追加のパラメーター。" - -#: ../../rst/network/user_guide/cli_parsing.rst:565 -msgid "``parser/vars/ttp_results`` - Additional parameters used to influence the parser output." -msgstr "``parser/vars/ttp_results`` - パーサーの出力に影響を与えるために使用される追加のパラメーター。" - -#: ../../rst/network/user_guide/cli_parsing.rst:566 -msgid "``parser/vars/ttp_vars`` - Additional variables made available in the template." -msgstr "``parser/vars/ttp_vars`` - テンプレートで利用可能な追加の変数" - -#: ../../rst/network/user_guide/cli_parsing.rst:568 -msgid "See the `TTP documentation `_ for details." -msgstr "詳細は、`TTP documentation `_ を参照してください。" - -#: ../../rst/network/user_guide/cli_parsing.rst:571 -msgid "The task sets the follow fact as the ``interfaces`` fact for the host:" -msgstr "このタスクは、ホストの ``interfaces`` ファクトとして follow ファクトを設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:587 -msgid "Converting XML" -msgstr "XML の変換" - -#: ../../rst/network/user_guide/cli_parsing.rst:591 -msgid "This example task runs the ``show interface`` command and parses the output as XML:" -msgstr "このサンプルタスクでは、``show interface`` コマンドを実行し、出力を XML として解析します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:604 -msgid "Red Hat Ansible Automation Platform subscription support is limited to the use of the ``xmltodict`` public APIs as documented." -msgstr "Red Hat Ansible Automation Platform のサブスクリプションのサポートは、文書化されている ``xmltodict`` パブリック API の使用に限定されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:606 -msgid "This task sets the ``interfaces`` fact for the host based on this returned output:" -msgstr "このタスクは、返された出力に基づいてホストの ``interfaces`` ファクトを設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:629 -msgid "Advanced use cases" -msgstr "高度なユースケース" - -#: ../../rst/network/user_guide/cli_parsing.rst:631 -msgid "The ``cli_parse`` module supports several features to support more complex uses cases." -msgstr "``cli_parse`` モジュールは、より複雑なユースケースをサポートする複数の機能をサポートします。" - -#: ../../rst/network/user_guide/cli_parsing.rst:634 -msgid "Provide a full template path" -msgstr "完全なテンプレートパスを提供" - -#: ../../rst/network/user_guide/cli_parsing.rst:636 -msgid "Use the ``template_path`` option to override the default template path in the task:" -msgstr "``template_path`` オプションを使用して、タスクのデフォルトのテンプレートパスを上書きします。" - -#: ../../rst/network/user_guide/cli_parsing.rst:649 -msgid "Provide command to parser different than the command run" -msgstr "コマンド実行以外のパーサーを行うコマンドを指定" - -#: ../../rst/network/user_guide/cli_parsing.rst:651 -msgid "Use the ``command`` suboption for the ``parser`` to configure the command the parser expects if it is different from the command ``cli_parse`` runs:" -msgstr "``parser`` の ``command`` サブオプションを使用して、``cli_parse`` コマンドの実行とは異なる場合にパーサーが想定するコマンドを設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:663 -msgid "Provide a custom OS value" -msgstr "カスタム OS 値を指定" - -#: ../../rst/network/user_guide/cli_parsing.rst:665 -msgid "Use the ``os`` suboption to the parser to directly set the OS instead of using ``ansible_network_os`` or ``ansible_distribution`` to generate the template path or with the specified parser engine:" -msgstr "テンプレートパスを生成する ``ansible_network_os`` や ``ansible_distribution``、または指定したパーサーエンジンを使用する代わりに、OS を直接設定するパーサーに ``os`` サブオプションを使用します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:685 -msgid "Parse existing text" -msgstr "既存テキストの解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:687 -msgid "Use the ``text`` option instead of ``command`` to parse text collected earlier in the playbook." -msgstr "``command`` の代わりに ``text`` オプションを使用して、Playbook で以前に収集したテキストを解析します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:719 -msgid ":ref:`develop_cli_parse_plugins`" -msgstr ":ref:`develop_cli_parse_plugins`" - -#: ../../rst/network/user_guide/faq.rst:5 -msgid "Ansible Network FAQ" -msgstr "Ansible Network FAQ" - -#: ../../rst/network/user_guide/faq.rst:7 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/network/user_guide/faq.rst:12 -msgid "How can I improve performance for network playbooks?" -msgstr "ネットワークの Playbook のパフォーマンスを改善するにはどうすればよいですか" - -#: ../../rst/network/user_guide/faq.rst:17 -msgid "Consider ``strategy: free`` if you are running on multiple hosts" -msgstr "複数のホストで実行している場合は ``strategy: free`` について検討してください。" - -#: ../../rst/network/user_guide/faq.rst:19 -msgid "The ``strategy`` plugin tells Ansible how to order multiple tasks on multiple hosts. :ref:`Strategy` is set at the playbook level." -msgstr "``strategy`` プラグインは、Ansible に対して複数のホストで複数のタスクを順序付ける方法を示します。:ref:`Strategy` は Playbook レベルで設定されます。" - -#: ../../rst/network/user_guide/faq.rst:21 -msgid "The default strategy is ``linear``. With strategy set to ``linear``, Ansible waits until the current task has run on all hosts before starting the next task on any host. Ansible may have forks free, but will not use them until all hosts have completed the current task. If each task in your playbook must succeed on all hosts before you run the next task, use the ``linear`` strategy." -msgstr "デフォルトのストラテジーは ``linear`` です。ストラテジーを ``linear`` に設定すると、Ansible は、現在のタスクがすべてのホストで実行されるまで待機してから、任意のホストで次のタスクを開始します。Ansible はフォークを解放しているかもしれませんが、全てのホストが現在のタスクを完了するまでフォークを使用しません。次のタスクを実行する前に、Playbook の各タスクがすべてのホストで成功する必要がある場合は、``linear`` ストラテジーを使用します。" - -#: ../../rst/network/user_guide/faq.rst:23 -msgid "Using the ``free`` strategy, Ansible uses available forks to execute tasks on each host as quickly as possible. Even if an earlier task is still running on one host, Ansible executes later tasks on other hosts. The ``free`` strategy uses available forks more efficiently. If your playbook stalls on each task, waiting for one slow host, consider using ``strategy: free`` to boost overall performance." -msgstr "この ``free`` ストラテジーを使用すると、Ansible は、利用可能なフォークを使用して各ホストのタスクをできるだけ速く実行します。あるホストで前のタスクの実行が完了していない場合でも、Ansible は他のホストで後のタスクを実行します。この ``free`` ストラテジーでは、使用可能なフォークをより効率的に使用します。各タスクで Playbook が停滞し、1 つのホストの処理速度が遅い場合は、``strategy: free`` を使用して全体的なパフォーマンスを向上させることを検討してください。" - -#: ../../rst/network/user_guide/faq.rst:28 -msgid "Execute ``show running`` only if you absolutely must" -msgstr "絶対的に必要とされる場合にのみ ``show running`` を実行" - -#: ../../rst/network/user_guide/faq.rst:30 -msgid "The ``show running`` command is the most resource-intensive command to execute on a network device, because of the way queries are handled by the network OS. Using the command in your Ansible playbook will slow performance significantly, especially on large devices; repeating it will multiply the performance hit. If you have a playbook that checks the running config, then executes changes, then checks the running config again, you should expect that playbook to be very slow." -msgstr "この ``show running`` コマンドは、ネットワーク OS によるクエリーの処理方法のため、ネットワークデバイスで実行する最もリソースを消費するコマンドです。Ansible Playbook でこのコマンドを使用すると、特に大規模なデバイスではパフォーマンスが大幅に低下します。繰り返し実行すると、パフォーマンスへの影響が大きくなります。実行設定を確認してから変更を実行し、再び実行設定を確認する Playbook がある場合は、Playbook が非常に遅くなることが予想されます。" - -#: ../../rst/network/user_guide/faq.rst:35 -msgid "Use ``ProxyCommand`` only if you absolutely must" -msgstr "絶対的に必要とされる場合のみ ``ProxyCommand`` を使用" - -#: ../../rst/network/user_guide/faq.rst:37 -msgid "Network modules support the use of a :ref:`proxy or jump host` with the ``ProxyCommand`` parameter. However, when you use a jump host, Ansible must open a new SSH connection for every task, even if you are using a persistent connection type (``network_cli`` or ``netconf``). To maximize the performance benefits of the persistent connection types introduced in version 2.5, avoid using jump hosts whenever possible." -msgstr "ネットワークモジュールは、``ProxyCommand`` パラメーターで :ref:`プロキシーまたはジャンプホスト` の使用がサポートされています。ただし、ジャンプホストを使用する場合は、永続的な接続タイプ (``network_cli`` または ``netconf``) を使用している場合でも、タスクごとに新しい SSH 接続を開く必要があります。バージョン 2.5 で導入された永続接続タイプのパフォーマンス上の利点を最大限に活用するには、可能な限りジャンプホストを使用しないでください。" - -#: ../../rst/network/user_guide/faq.rst:42 -msgid "Set ``--forks`` to match your needs" -msgstr "必要に応じて ``--forks`` を設定" - -#: ../../rst/network/user_guide/faq.rst:44 -msgid "Every time Ansible runs a task, it forks its own process. The ``--forks`` parameter defines the number of concurrent tasks - if you retain the default setting, which is ``--forks=5``, and you are running a playbook on 10 hosts, five of those hosts will have to wait until a fork is available. Of course, the more forks you allow, the more memory and processing power Ansible will use. Since most network tasks are run on the control host, this means your laptop can quickly become cpu- or memory-bound." -msgstr "Ansible はタスクを実行するたびに、独自のプロセスをフォークします。``--forks`` パラメーターは、同時実行タスクの数を定義します。デフォルト設定 (``--forks=5``) のままで、10 台のホストで Playbook を実行していると、そのうち 5 台のホストは、フォークが使用可能になるまで待機する必要があります。もちろん、フォークの数が増えれば増えるほど、Ansible はより多くのメモリーと処理能力を使うことになります。ネットワークタスクの大半はコントロールホストで実行されるため、ラップトップでは、CPU またはメモリーがすぐに枯渇することになります。" - -#: ../../rst/network/user_guide/faq.rst:49 -msgid "Why is my output sometimes replaced with ``********``?" -msgstr "出力が ``********`` に置き換えられることがあるのはなぜですか" - -#: ../../rst/network/user_guide/faq.rst:51 -msgid "Ansible replaces any string marked ``no_log``, including passwords, with ``********`` in Ansible output. This is done by design, to protect your sensitive data. Most users are happy to have their passwords redacted. However, Ansible replaces every string that matches your password with ``********``. If you use a common word for your password, this can be a problem. For example, if you choose ``Admin`` as your password, Ansible will replace every instance of the word ``Admin`` with ``********`` in your output. This may make your output harder to read. To avoid this problem, select a secure password that will not occur elsewhere in your Ansible output." -msgstr "Ansible は、Ansible 出力で、パスワードを含む ``no_log`` と印された文字列を ``********`` に置き換えます。これは、機密データを保護するために設計されています。ほとんどのユーザーは、自身のパスワードが伏字になることを希望します。ただし、Ansible はパスワードに一致するすべての文字列を ``********`` に置き換えます。パスワードに一般的な単語を使用すると、問題が発生する可能性があります。たとえば、``Admin`` をパスワードとした場合、``Admin`` は出力内にあるその単語のすべてのインスタンスを ``********`` に置き換えます。これにより、出力が読みにくくなる場合があります。この問題を回避するには、他の Ansible 出力場所では使用されない安全なパスワードを選択してください。" - -#: ../../rst/network/user_guide/faq.rst:56 -msgid "Why do the ``*_config`` modules always return ``changed=true`` with abbreviated commands?" -msgstr "省略されたコマンドで ``*_config`` モジュールが常に ``changed=true`` を返すのはなぜですか" - -#: ../../rst/network/user_guide/faq.rst:58 -msgid "When you issue commands directly on a network device, you can use abbreviated commands. For example, ``int g1/0/11`` and ``interface GigabitEthernet1/0/11`` do the same thing; ``shut`` and ``shutdown`` do the same thing. Ansible Network ``*_command`` modules work with abbreviations, because they run commands through the network OS." -msgstr "ネットワークデバイスで直接コマンドを実行する場合は、省略されたコマンドを使用できます。たとえば、``int g1/0/11`` と ``interface GigabitEthernet1/0/11`` は、同じ動作になります。``shut`` と ``shutdown`` も同じ動作になります。Ansible Network の ``*_command`` モジュールは、ネットワーク OS を介してコマンドを実行するため、省略形で動作します。" - -#: ../../rst/network/user_guide/faq.rst:60 -msgid "When committing configuration, however, the network OS converts abbreviations into long-form commands. Whether you use ``shut`` or ``shutdown`` on ``GigabitEthernet1/0/11``, the result in the configuration is the same: ``shutdown``." -msgstr "ただし、設定をコミットすると、ネットワーク OS は省略形を長い形式のコマンドに変換します。``GigabitEthernet1/0/11`` で ``shut`` または ``shutdown`` を使用した場合の設定は同じで、``shutdown`` となります。" - -#: ../../rst/network/user_guide/faq.rst:62 -msgid "Ansible Network ``*_config`` modules compare the text of the commands you specify in ``lines`` to the text in the configuration. If you use ``shut`` in the ``lines`` section of your task, and the configuration reads ``shutdown``, the module returns ``changed=true`` even though the configuration is already correct. Your task will update the configuration every time it runs." -msgstr "Ansible Network の ``*_config`` モジュールは、``lines`` で指定したコマンドのテキストを設定のテキストと比較します。タスクの ``lines`` セクションで ``shut`` を使用し、設定が ``shutdown`` を読み込む場合は、設定が正しいにもかかわらず、モジュールが ``changed=true`` を返します。タスクを実行するたびに設定が更新されます。" - -#: ../../rst/network/user_guide/faq.rst:64 -msgid "To avoid this problem, use long-form commands with the ``*_config`` modules:" -msgstr "この問題を回避するには、``*_config`` モジュールで長い形式のコマンドを使用します。" - -#: ../../rst/network/user_guide/index.rst:15 -msgid "Advanced Topics" -msgstr "高度なトピック" - -#: ../../rst/network/user_guide/index.rst:5 -msgid "Network Advanced Topics" -msgstr "ネットワークの高度なトピック" - -#: ../../rst/network/user_guide/index.rst:7 -msgid "Once you have mastered the basics of network automation with Ansible, as presented in :ref:`network_getting_started`, use this guide understand platform-specific details, optimization, and troubleshooting tips for Ansible for network automation." -msgstr ":ref:`network_getting_started` に記載されているように、Ansible を使用したネットワーク自動化の基本を習得したら、本ガイドを参照して、ネットワーク自動化に関する Ansible のプラットフォーム固有の詳細、最適化、およびトラブルシューティングのヒントを理解します。" - -#: ../../rst/network/user_guide/index.rst:11 -msgid "This guide is intended for network engineers using Ansible for automation. It covers advanced topics. If you understand networks and Ansible, this guide is for you. You may read through the entire guide if you choose, or use the links below to find the specific information you need." -msgstr "このガイドは、自動化に Ansible を使用するネットワークエンジニアを対象とした高度なトピックを説明します。ネットワークと Ansible を理解しているユーザーを対象としています。必要に応じてガイド全体を読むか、次のリンクを使用して必要な特定情報を選択してください。" - -#: ../../rst/network/user_guide/index.rst:13 -msgid "If you're new to Ansible, or new to using Ansible for network automation, start with the :ref:`network_getting_started`." -msgstr "Ansible を初めて使用する場合や、ネットワーク管理に Ansible を初めて使用する場合は、最初に「:ref:`network_getting_started`」をお読みください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:5 -msgid "Ansible Network Examples" -msgstr "Ansible ネットワークの例" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:7 -msgid "This document describes some examples of using Ansible to manage your network infrastructure." -msgstr "本ガイドでは、Ansible を使用してネットワークインフラストラクチャーを管理する例を説明します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:15 -msgid "This example requires the following:" -msgstr "この例では、以下が必要です。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:17 -msgid "**Ansible 2.10** (or higher) installed. See :ref:`intro_installation_guide` for more information." -msgstr "**Ansible 2.10** (またはそれ以上) がインストールされている。詳細は「:ref:`intro_installation_guide`」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:18 -msgid "One or more network devices that are compatible with Ansible." -msgstr "Ansible と互換性がある 1 つ以上ネットワークデバイス。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:19 -msgid "Basic understanding of YAML :ref:`yaml_syntax`." -msgstr "YAML :ref:`yaml_syntax` の基本知識" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:20 -msgid "Basic understanding of Jinja2 templates. See :ref:`playbooks_templating` for more information." -msgstr "Jinja2 テンプレートの基本的な理解。詳細は「:ref:`playbooks_templating`」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:21 -msgid "Basic Linux command line use." -msgstr "基本的な Linux コマンドラインの使用。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:22 -msgid "Basic knowledge of network switch & router configurations." -msgstr "ネットワークスイッチおよびルーター設定に関する基本知識。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:26 -msgid "Groups and variables in an inventory file" -msgstr "インベントリーファイルのグループおよび変数" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:28 -msgid "An ``inventory`` file is a YAML or INI-like configuration file that defines the mapping of hosts into groups." -msgstr "``inventory`` ファイルは、ホストからグループへのマッピングを定義する YAML または INI のような設定ファイルです。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:30 -msgid "In our example, the inventory file defines the groups ``eos``, ``ios``, ``vyos`` and a \"group of groups\" called ``switches``. Further details about subgroups and inventory files can be found in the :ref:`Ansible inventory Group documentation `." -msgstr "この例では、インベントリーファイルは ``eos``、``ios``、および ``vyos`` と、``switches`` と呼ばれる「グループのグループ」を定義します。サブグループとインベントリーファイルの詳細は「:ref:`Ansible inventory Group documentation `」にあります。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:32 -msgid "Because Ansible is a flexible tool, there are a number of ways to specify connection information and credentials. We recommend using the ``[my_group:vars]`` capability in your inventory file." -msgstr "Ansible は柔軟なツールであるため、接続情報および認証情報を指定する方法は複数あります。インベントリーファイルで ``[my_group:vars]`` 機能を使用することが推奨されます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:81 -msgid "If you use ssh-agent, you do not need the ``ansible_password`` lines. If you use ssh keys, but not ssh-agent, and you have multiple keys, specify the key to use for each connection in the ``[group:vars]`` section with ``ansible_ssh_private_key_file=/path/to/correct/key``. For more information on ``ansible_ssh_`` options see :ref:`behavioral_parameters`." -msgstr "ssh-agent を使用する場合、``ansible_password`` 行は必要ありません。ssh-agent でなく ssh キーを使用し、鍵が複数ある場合は、``ansible_ssh_private_key_file=/path/to/correct/key`` の ``[group:vars]`` セクションで、各接続に使用するキーを指定します。``ansible_ssh_`` オプションの詳細は、「:ref:`behavioral_parameters`」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:85 -msgid "Never store passwords in plain text." -msgstr "プレーンテキストにパスワードを保存しないでください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:88 -msgid "Ansible vault for password encryption" -msgstr "パスワード暗号化用の Ansible Vault" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:90 -msgid "The \"Vault\" feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See :ref:`playbooks_vault` for more information." -msgstr "Ansible の「Vault」機能を使用すると、パスワードやキーなどの機密データを、Playbook やロールのプレーンテキストとしてではなく、暗号化されたファイルに保存することができます。この Vault ファイルは、ソース制御に配布または配置することができます。詳細は、「:ref:`playbooks_vault`」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:92 -msgid "Here's what it would look like if you specified your SSH passwords (encrypted with Ansible Vault) among your variables:" -msgstr "変数内に SSH パスワード (Ansible Vault で暗号化) を指定すると、以下のようになります。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:108 -msgid "Common inventory variables" -msgstr "共通のインベントリー変数" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:110 -msgid "The following variables are common for all platforms in the inventory, though they can be overwritten for a particular inventory group or host." -msgstr "以下の変数はインベントリー内のすべてのプラットフォームに共通ですが、特定のインベントリーグループまたはホストについて上書きできます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst -msgid "ansible_connection" -msgstr "ansible_connection" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:114 -msgid "Ansible uses the ansible-connection setting to determine how to connect to a remote device. When working with Ansible Networking, set this to an appropriate network connection option, such as``ansible.netcommon.network_cli``, so Ansible treats the remote node as a network device with a limited execution environment. Without this setting, Ansible would attempt to use ssh to connect to the remote and execute the Python script on the network device, which would fail because Python generally isn't available on network devices." -msgstr "Ansible は ansible-connection 設定を使用してリモートデバイスへの接続方法を決定します。Ansible ネットワークを使用する場合は、適切なネットワーク接続オプション (``ansible.netcommon.network_cli`` など) に設定して、Ansible が実行環境が制限されたネットワークデバイスとしてリモートノードを扱うようにします。この設定がないと、Ansible は ssh を使用してリモートに接続し、Python スクリプトをネットワークデバイスで実行しようとしますが、Python は一般的にネットワークデバイスで使用できないため失敗します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst -msgid "ansible_network_os" -msgstr "ansible_network_os" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:116 -msgid "Informs Ansible which Network platform this hosts corresponds to. This is required when using the ``ansible.netcommon.*`` connection options." -msgstr "このホストに対応するネットワークプラットフォームを Ansible に通知します。これは、``ansible.netcommon.*`` 接続オプションを使用する場合に必要です。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst -msgid "ansible_user" -msgstr "ansible_user" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:117 -msgid "The user to connect to the remote device (switch) as. Without this the user that is running ``ansible-playbook`` would be used. Specifies which user on the network device the connection" -msgstr "リモートデバイス (スイッチ) に接続するユーザーです。これがないと、このユーザーが ``ansible-playbook`` を実行しているユーザーに使用されます。ネットワークデバイス上のどのユーザーに接続するかを指定します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst -msgid "ansible_password" -msgstr "ansible_password" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:120 -msgid "The corresponding password for ``ansible_user`` to log in as. If not specified SSH key will be used." -msgstr "``ansible_user`` でログインするためのパスワードです。指定しない場合は、SSH キーが使用されます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst -msgid "ansible_become" -msgstr "ansible_become" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:122 -msgid "If enable mode (privilege mode) should be used, see the next section." -msgstr "Enable モード (特権モード) を使用する場合は、次のセクションを参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst -msgid "ansible_become_method" -msgstr "ansible_become_method" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:124 -msgid "Which type of `become` should be used, for ``network_cli`` the only valid choice is ``enable``." -msgstr "どのタイプ `become` を使用すべきか。``network_cli`` では、有効な選択は ``enable`` のみです。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:127 -msgid "Privilege escalation" -msgstr "権限昇格" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:129 -msgid "Certain network platforms, such as Arista EOS and Cisco IOS, have the concept of different privilege modes. Certain network modules, such as those that modify system state including users, will only work in high privilege states. Ansible supports ``become`` when using ``connection: ansible.netcommon.network_cli``. This allows privileges to be raised for the specific tasks that need them. Adding ``become: yes`` and ``become_method: enable`` informs Ansible to go into privilege mode before executing the task, as shown here:" -msgstr "Arista EOS や Cisco IOS などの特定のネットワークプラットフォームには、異なる特権モードの概念があります。ユーザーを含むシステム状態を変更するような特定のネットワークモジュールは、高特権状態でのみ動作します。Ansible は、``connection: ansible.netcommon.network_cli`` の使用時に、``become`` をサポートします。これにより、権限を必要とする特定のタスクに対して権限を設定できます。次に示すように、``become: yes`` および ``become_method: enable`` を追加すると、タスクを実行する前に特権モードに入るように Ansible に通知します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:139 -msgid "For more information, see the :ref:`using become with network modules` guide." -msgstr "詳細は「:ref:`ネットワークモジュールで become の使用`」ガイドを参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:143 -msgid "Jump hosts" -msgstr "ジャンプホスト" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:145 -msgid "If the Ansible Controller does not have a direct route to the remote device and you need to use a Jump Host, please see the :ref:`Ansible Network Proxy Command ` guide for details on how to achieve this." -msgstr "Ansible Controller がリモートデバイスへの直接ルートがなく、ジャンプホストを使用する必要がある場合は、これを実現する方法について、「:ref:`Ansible ネットワークプロキシーコマンド `」ガイドを参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:148 -msgid "Example 1: collecting facts and creating backup files with a playbook" -msgstr "例 1: Playbook でファクトを収集し、バックアップファイルの作成" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:150 -msgid "Ansible facts modules gather system information 'facts' that are available to the rest of your playbook." -msgstr "Ansible ファクトモジュールは、他の Playbook で利用可能なシステム情報の「ファクト」を収集します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:152 -msgid "Ansible Networking ships with a number of network-specific facts modules. In this example, we use the ``_facts`` modules :ref:`arista.eos.eos_facts `, :ref:`cisco.ios.ios_facts ` and :ref:`vyos.vyos.vyos_facts ` to connect to the remote networking device. As the credentials are not explicitly passed with module arguments, Ansible uses the username and password from the inventory file." -msgstr "Ansible ネットワークには、ネットワーク固有のファクトモジュールがいくつか付属しています。この例では、``_facts`` モジュール (:ref:`arista.eos.eos_facts `、:ref:`cisco.ios.ios_facts `、および :ref:`vyos.vyos.vyos_facts `) を使用し、リモートネットワーキングデバイスに接続します。認証情報はモジュール引数とともに明示的に渡されないため、Ansible はインベントリーファイルからのユーザー名とパスワードを使用します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:154 -msgid "Ansible's \"Network Fact modules\" gather information from the system and store the results in facts prefixed with ``ansible_net_``. The data collected by these modules is documented in the `Return Values` section of the module docs, in this case :ref:`arista.eos.eos_facts ` and :ref:`vyos.vyos.vyos_facts `. We can use the facts, such as ``ansible_net_version`` late on in the \"Display some facts\" task." -msgstr "Ansibleの「ネットワークファクトモジュール」はシステムから情報を収集し、``ansible_net_`` の接頭辞が付いたファクトに結果を格納します。これらのモジュールによって収集されるデータは、モジュールドキュメントの `Return Values` セクション (この場合は :ref:`arista.eos.eos_facts ` および :ref:`vyos.vyos.vyos_facts `) に記載されています。``ansible_net_version`` などのファクトは、「Display some facts (一部のファクトを表示する)」タスクの後半で使用できます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:156 -msgid "To ensure we call the correct mode (``*_facts``) the task is conditionally run based on the group defined in the inventory file, for more information on the use of conditionals in Ansible Playbooks see :ref:`the_when_statement`." -msgstr "正しいモード (``*_facts``) を呼び出すようにするには、インベントリーファイルに定義されたグループに基づいてタスクが条件付きで実行されます。Ansible Playbook での条件付き使用の詳細は、「:ref:`the_when_statement`」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:158 -msgid "In this example, we will create an inventory file containing some network switches, then run a playbook to connect to the network devices and return some information about them." -msgstr "この例では、一部のネットワークスイッチを含むインベントリーファイルを作成してから、Playbook を実行してネットワークデバイスに接続し、その情報を返します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:161 -msgid "Step 1: Creating the inventory" -msgstr "ステップ 1: インベントリーの作成" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:163 -msgid "First, create a file called ``inventory``, containing:" -msgstr "まず、以下を含む ``inventory`` という名前のファイルを作成します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:183 -msgid "Step 2: Creating the playbook" -msgstr "ステップ 2: Playbook の作成" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:185 -msgid "Next, create a playbook file called ``facts-demo.yml`` containing the following:" -msgstr "次に、以下を含む ``facts-demo.yml`` という名前の Playbook ファイルを作成します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:285 -msgid "Step 3: Running the playbook" -msgstr "ステップ 3: Playbook の実行" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:287 -msgid "To run the playbook, run the following from a console prompt:" -msgstr "Playbook を実行するには、コンソールプロンプトから以下を実行します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:293 -msgid "This should return output similar to the following:" -msgstr "このコマンドを実行すると、以下のような出力が返されます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:303 -msgid "Step 4: Examining the playbook results" -msgstr "手順 4: Playbook の結果の検証" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:305 -msgid "Next, look at the contents of the file we created containing the switch facts:" -msgstr "次に、スイッチファクトを含む作成したファイルの内容を確認します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:311 -msgid "You can also look at the backup files:" -msgstr "バックアップファイルを確認することもできます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:318 -msgid "If `ansible-playbook` fails, please follow the debug steps in :ref:`network_debug_troubleshooting`." -msgstr "`ansible-playbook` が失敗する場合は、:ref:`network_debug_troubleshooting` のデバッグ手順に従ってください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:324 -msgid "Example 2: simplifying playbooks with network agnostic modules" -msgstr "例 2: ネットワークに依存しないモジュールを使用した Playbook の単純化" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:326 -msgid "(This example originally appeared in the `Deep Dive on cli_command for Network Automation `_ blog post by Sean Cavanaugh -`@IPvSean `_)." -msgstr "(この例は、元々、Sean Cavanaugh (`@IPvSean `_) 氏が投稿したブログ「`Deep Dive on cli_command for Network Automation `_」で紹介されました。)" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:328 -msgid "If you have two or more network platforms in your environment, you can use the network agnostic modules to simplify your playbooks. You can use network agnostic modules such as ``ansible.netcommon.cli_command`` or ``ansible.netcommon.cli_config`` in place of the platform-specific modules such as ``arista.eos.eos_config``, ``cisco.ios.ios_config``, and ``junipernetworks.junos.junos_config``. This reduces the number of tasks and conditionals you need in your playbooks." -msgstr "環境内に複数のネットワークプラットフォームがある場合は、ネットワークに依存しないモジュールを使用して、Playbook を簡素化できます。``arista.eos.eos_config``、``cisco.ios.ios_config``、``junipernetworks.junos.junos_config`` などのプラットフォーム固有のモジュールの代わりに、``ansible.netcommon.cli_command``、``ansible.netcommon.cli_config`` などのネットワークに依存しないモジュールを使用できます。これにより、Playbook に必要なタスクおよび条件の数が減ります。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:331 -msgid "Network agnostic modules require the :ref:`ansible.netcommon.network_cli ` connection plugin." -msgstr "ネットワークに依存しないモジュールには、:ref:`ansible.netcommon.network_cli ` 接続プラグインが必要です。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:335 -msgid "Sample playbook with platform-specific modules" -msgstr "プラットフォーム固有のモジュールを含む Playbook のサンプル" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:337 -msgid "This example assumes three platforms, Arista EOS, Cisco NXOS, and Juniper JunOS. Without the network agnostic modules, a sample playbook might contain the following three tasks with platform-specific commands:" -msgstr "この例では、Arista EOS、Cisco NXOS、Juniper JunOS の 3 つのプラットフォームを想定しています。ネットワークに依存しないモジュールを使用しないと、サンプル Playbook にはプラットフォーム固有のコマンドと共に、以下の 3 つのタスクが含まれる場合があります。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:358 -msgid "Simplified playbook with ``cli_command`` network agnostic module" -msgstr "``cli_command`` ネットワークに依存しないモジュールを使用した Playbook の簡素化" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:360 -msgid "You can replace these platform-specific modules with the network agnostic ``ansible.netcommon.cli_command`` module as follows:" -msgstr "これらのプラットフォーム固有のモジュールは、以下のようにネットワークに依存しない ``ansible.netcommon.cli_command`` モジュールに置き換えることができます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:407 -msgid "If you use groups and group_vars by platform type, this playbook can be further simplified to :" -msgstr "プラットフォームタイプ別にグループおよび group_vars を使用する場合は、この Playbook をさらに簡単にできます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:423 -msgid "You can see a full example of this using group_vars and also a configuration backup example at `Network agnostic examples `_." -msgstr "group_vars の完全例と設定バックアップの例は、`ネットワークに依存しない例 `_ で確認できます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:426 -msgid "Using multiple prompts with the ``ansible.netcommon.cli_command``" -msgstr "``ansible.netcommon.cli_command`` を含む複数のプロンプトの使用" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:428 -msgid "The ``ansible.netcommon.cli_command`` also supports multiple prompts." -msgstr "``ansible.netcommon.cli_command`` は、複数のプロンプトもサポートします。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:449 -msgid "See the :ref:`ansible.netcommon.cli_command ` for full documentation on this command." -msgstr "このコマンドに関するドキュメントは、「:ref:`ansible.netcommon.cli_command `」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:453 -msgid "Implementation Notes" -msgstr "実装に関する注意点" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:457 -msgid "Demo variables" -msgstr "デモ変数" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:459 -msgid "Although these tasks are not needed to write data to disk, they are used in this example to demonstrate some methods of accessing facts about the given devices or a named host." -msgstr "これらのタスクは、ディスクにデータを書き込む必要はありませんが、この例では、特定のデバイスまたは名前付きホストのファクトにアクセスする方法を実証するために使用されます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:461 -msgid "Ansible ``hostvars`` allows you to access variables from a named host. Without this we would return the details for the current host, rather than the named host." -msgstr "Ansible ``hostvars`` を使用すると、名前付きホストから変数にアクセスすることができます。これを使用しないと、名前付きホストではなく、現在のホストの詳細が返されます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:463 -msgid "For more information, see :ref:`magic_variables_and_hostvars`." -msgstr "詳細情報は、「:ref:`magic_variables_and_hostvars`」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:466 -msgid "Get running configuration" -msgstr "実行中の設定の取得" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:468 -msgid "The :ref:`arista.eos.eos_config ` and :ref:`vyos.vyos.vyos_config ` modules have a ``backup:`` option that when set will cause the module to create a full backup of the current ``running-config`` from the remote device before any changes are made. The backup file is written to the ``backup`` folder in the playbook root directory. If the directory does not exist, it is created." -msgstr ":ref:`arista.eos.eos_config ` モジュールおよび :ref:`vyos.vyos.vyos_config ` モジュールには、設定されている場合は、変更が行われる前にリモートデバイスから現在の ``running-config`` のフルバックアップを作成する ``backup:`` オプションがあります。バックアップファイルは、Playbook のルートディレクトリー内の ``backup`` ディレクトリーに書き込まれます。このディレクトリーが存在しない場合は作成されます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:470 -msgid "To demonstrate how we can move the backup file to a different location, we register the result and move the file to the path stored in ``backup_path``." -msgstr "バックアップファイルを別の場所に移動する方法を実証するために、結果を登録し、ファイルを ``backup_path`` に保存されているパスに移動します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:472 -msgid "Note that when using variables from tasks in this way we use double quotes (``\"``) and double curly-brackets (``{{...}}`` to tell Ansible that this is a variable." -msgstr "この方法でタスクの変数を使用する場合は、Ansible にこれが変数であることを伝えるために、二重引用符 (``\"``) と二重中括弧 (``{{...}}``) を使用します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:475 -msgid "Troubleshooting" -msgstr "トラブルシューティング" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:477 -msgid "If you receive an connection error please double check the inventory and playbook for typos or missing lines. If the issue still occurs follow the debug steps in :ref:`network_debug_troubleshooting`." -msgstr "接続エラーを受け取った場合は、インベントリーと Playbook で誤字または欠落している行がないか再確認してください。問題が解決しない場合は、:ref:`network_debug_troubleshooting` のデバッグ手順に従います。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:481 -msgid ":ref:`network_guide`" -msgstr ":ref:`network_guide`" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:482 -msgid ":ref:`intro_inventory`" -msgstr ":ref:`intro_inventory`" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:483 -msgid ":ref:`Keeping vaulted variables visible `" -msgstr ":ref:`Keeping vaulted variables visible `" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:5 -msgid "Network Debug and Troubleshooting Guide" -msgstr "ネットワークデバッグおよびトラブルシューティングガイド" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:7 -msgid "This section discusses how to debug and troubleshoot network modules in Ansible." -msgstr "本セクションでは、Ansible でネットワークモジュールをデバッグし、トラブルシューティングを行う方法を説明します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:14 -msgid "How to troubleshoot" -msgstr "トラブルシューティングの方法" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:16 -msgid "Ansible network automation errors generally fall into one of the following categories:" -msgstr "Ansible ネットワーク自動化エラーは通常、以下のカテゴリーのいずれかに分類されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst -msgid "Authentication issues" -msgstr "認証の問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:19 -msgid "Not correctly specifying credentials" -msgstr "認証情報を正しく指定できない" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:20 -msgid "Remote device (network switch/router) not falling back to other other authentication methods" -msgstr "リモートデバイス (ネットワークスイッチ/ルーター) が他の認証方法にフォールバックしない" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:21 -msgid "SSH key issues" -msgstr "SSH キーの問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:439 -msgid "Timeout issues" -msgstr "タイムアウトの問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:23 -msgid "Can occur when trying to pull a large amount of data" -msgstr "大量のデータを取得しようとすると発生することがある" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:24 -msgid "May actually be masking a authentication issue" -msgstr "認証の問題を実際にマスクする可能性がある" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:600 -msgid "Playbook issues" -msgstr "Playbook の問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:26 -msgid "Use of ``delegate_to``, instead of ``ProxyCommand``. See :ref:`network proxy guide ` for more information." -msgstr "``ProxyCommand`` の代わりに ``delegate_to`` を使用します。詳細は、「:ref:`ネットワークプロキシーガイド `」を参照してください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:28 -msgid "``unable to open shell``" -msgstr "``unable to open shell``" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:30 -msgid "The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. See the \"Authentication and connection issues\" section in this document for more information." -msgstr "``unable to open shell`` メッセージは、``ansible-connection`` デーモンがリモートネットワークデバイスと正常に通信できなかったことを示します。これは通常、認証の問題があることを意味します。詳細については、このドキュメントの「認証と接続の問題」を参照してください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:37 -msgid "Enabling Networking logging and how to read the logfile" -msgstr "ネットワークロギングの有効化とログファイルの読み取り方法" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:39 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:96 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:156 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:199 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:256 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:294 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:321 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:426 -msgid "**Platforms:** Any" -msgstr "**プラットフォーム:** 任意" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:41 -msgid "Ansible includes logging to help diagnose and troubleshoot issues regarding Ansible Networking modules." -msgstr "Ansible には、Ansible ネットワークモジュールに関する問題の診断とトラブルシューティングに役立つロギングが含まれます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:43 -msgid "Because logging is very verbose, it is disabled by default. It can be enabled with the :envvar:`ANSIBLE_LOG_PATH` and :envvar:`ANSIBLE_DEBUG` options on the ansible-controller, that is the machine running ``ansible-playbook``." -msgstr "ロギングは非常に詳細なため、デフォルトでは無効になっています。これは、ansible-controller の :envvar:`ANSIBLE_LOG_PATH` オプションおよび :envvar:`ANSIBLE_DEBUG` オプションで有効にできます。これは、``ansible-playbook`` を実行しているマシンです。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:45 -msgid "Before running ``ansible-playbook``, run the following commands to enable logging::" -msgstr "``ansible-playbook`` を実行する前に、以下のコマンドを実行してロギングを有効にします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:55 -msgid "After Ansible has finished running you can inspect the log file which has been created on the ansible-controller:" -msgstr "Ansible の実行が完了したら、ansible-controller で作成されたログファイルを確認できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:73 -msgid "From the log notice:" -msgstr "このログ通知は、以下のようになります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:75 -msgid "``p=28990`` Is the PID (Process ID) of the ``ansible-connection`` process" -msgstr "``p=28990`` ``ansible-connection`` プロセスの PID (プロセス ID) です。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:76 -msgid "``u=fred`` Is the user `running` ansible, not the remote-user you are attempting to connect as" -msgstr "``u=fred`` ansible を `実行` しているユーザーです (接続しようとしているリモートユーザーではありません)。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:77 -msgid "``creating new control socket for host veos01:22 as user admin`` host:port as user" -msgstr "``ホスト veos01:22 の新しいコントロールソケットをユーザー管理者`` ユーザーとして host:port" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:78 -msgid "``control socket path is`` location on disk where the persistent connection socket is created" -msgstr "``control socket path is`` 永続接続ソケットが作成されるディスクの場所" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:79 -msgid "``using connection plugin network_cli`` Informs you that persistent connection is being used" -msgstr "``using connection plugin network_cli`` 永続接続が使用されていることが通知されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:80 -msgid "``connection established to veos01 in 0:00:22.580626`` Time taken to obtain a shell on the remote device" -msgstr "``connection established to veos01 in 0:00:22.580626`` リモートデバイスでシェルの取得にかかった時間" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:88 -msgid "Because the log files are verbose, you can use grep to look for specific information. For example, once you have identified the ``pid`` from the ``creating new control socket for host`` line you can search for other connection log entries::" -msgstr "ログファイルは冗長であるため、grepを使用して特定の情報を検索できます。たとえば、``creating new control socket for host`` 行から ``pid`` を特定したら、他の接続ログエントリーを検索できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:94 -msgid "Enabling Networking device interaction logging" -msgstr "ネットワークデバイスの対話ロギングの有効化" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:98 -msgid "Ansible includes logging of device interaction in the log file to help diagnose and troubleshoot issues regarding Ansible Networking modules. The messages are logged in the file pointed to by the ``log_path`` configuration option in the Ansible configuration file or by setting the :envvar:`ANSIBLE_LOG_PATH`." -msgstr "Ansible には、Ansible ネットワークモジュールに関する問題の診断およびトラブルシューティングに役立つ、ログファイル内のデバイスの対話のログが含まれています。このメッセージは、Ansible 設定ファイルの ``log_path`` 設定オプションで指定されているファイルに記録されるか、:envvar:`ANSIBLE_LOG_PATH` を設定すると記録されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:103 -msgid "The device interaction messages consist of command executed on the target device and the returned response. Since this log data can contain sensitive information including passwords in plain text it is disabled by default. Additionally, in order to prevent accidental leakage of data, a warning will be shown on every task with this setting enabled, specifying which host has it enabled and where the data is being logged." -msgstr "デバイスインタラクションメッセージは、ターゲットデバイス上で実行されたコマンドと返された応答で構成されます。このログデータには、パスワードなどの機密情報がプレーンテキストの形式で含まれる可能性があるため、デフォルトでは無効になっています。また、誤ってデータが漏洩しないように、この設定が有効になっているすべてのタスクに警告が表示され、有効になっているホストとデータが記録される場所が指定されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:108 -msgid "Be sure to fully understand the security implications of enabling this option. The device interaction logging can be enabled either globally by setting in configuration file or by setting environment or enabled on per task basis by passing a special variable to the task." -msgstr "このオプションを有効にした場合のセキュリティーへの影響を完全に理解してください。デバイス対話ロギングは、設定ファイルでグローバルに設定するか、環境を設定して有効にするか、または特殊な変数をタスクに渡すことでタスクごとに有効にすることができます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:110 -msgid "Before running ``ansible-playbook`` run the following commands to enable logging:" -msgstr "``ansible-playbook`` を実行する前に、以下のコマンドを実行してロギングを有効にします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:118 -msgid "Enable device interaction logging for a given task" -msgstr "特定のタスクのデバイス対話ログを有効にします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:130 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:756 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:823 -msgid "To make this a global setting, add the following to your ``ansible.cfg`` file:" -msgstr "この設定をグローバルにするには、以下の設定を ``ansible.cfg`` ファイルに追加します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:137 -msgid "or enable the environment variable `ANSIBLE_PERSISTENT_LOG_MESSAGES`:" -msgstr "または、環境変数 `ANSIBLE_PERSISTENT_LOG_MESSAGES` を有効にします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:144 -msgid "If the task is failing on connection initialization itself, you should enable this option globally. If an individual task is failing intermittently this option can be enabled for that task itself to find the root cause." -msgstr "タスク自体が接続の初期化に失敗している場合は、このオプションをグローバルに有効にする必要があります。個々のタスクが断続的に失敗する場合は、そのタスク自体に対してこのオプションを有効にして、根本原因を見つけることができます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:147 -msgid "After Ansible has finished running you can inspect the log file which has been created on the ansible-controller" -msgstr "Ansible の実行が完了したら、ansible-controller で作成されたログファイルを確認できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:149 -msgid "Be sure to fully understand the security implications of enabling this option as it can log sensitive information in log file thus creating security vulnerability." -msgstr "このオプションを有効にすると、ログファイルに機密情報が記録され、セキュリティ上の脆弱性が生じる可能性があるため、セキュリティー上の影響を十分に理解してください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:154 -msgid "Isolating an error" -msgstr "エラーの分離" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:158 -msgid "As with any effort to troubleshoot it's important to simplify the test case as much as possible." -msgstr "トラブルシューティングにおけるあらゆる作業と同様に、テストケースをできるだけ簡略化することが重要です。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:160 -msgid "For Ansible this can be done by ensuring you are only running against one remote device:" -msgstr "Ansible の場合は、1 つのリモートデバイスに対してのみ実行するようにすることでこれを行うことができます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:162 -msgid "Using ``ansible-playbook --limit switch1.example.net...``" -msgstr "``ansible-playbook --limit switch1.example.net...`` の使用" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:163 -msgid "Using an ad hoc ``ansible`` command" -msgstr "``ansible`` アドホックコマンドの使用" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:165 -msgid "`ad hoc` refers to running Ansible to perform some quick command using ``/usr/bin/ansible``, rather than the orchestration language, which is ``/usr/bin/ansible-playbook``. In this case we can ensure connectivity by attempting to execute a single command on the remote device::" -msgstr "`ad hoc` は、オーケストレーション言語 ``/usr/bin/ansible-playbook`` ではなく、``/usr/bin/ansible`` を使用して簡単なコマンドを実行するために Ansible を実行することを指します。この場合は、リモートデバイスで 1 つのコマンドを実行することで、接続を確認できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:169 -msgid "In the above example, we:" -msgstr "上記の例では、以下を行います。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:171 -msgid "connect to ``switch1.example.net`` specified in the inventory file ``inventory``" -msgstr "インベントリーファイル ``inventory`` に指定された ``switch1.example.net`` に接続します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:172 -msgid "use the module ``arista.eos.eos_command``" -msgstr "``arista.eos.eos_command`` モジュールの使用" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:173 -msgid "run the command ``?``" -msgstr "``?`` コマンドの実行" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:174 -msgid "connect using the username ``admin``" -msgstr "ユーザー名 ``admin`` を使用して接続" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:175 -msgid "inform the ``ansible`` command to prompt for the SSH password by specifying ``-k``" -msgstr "``-k`` を指定して SSH パスワードを要求するように、``ansible`` コマンドに通知" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:177 -msgid "If you have SSH keys configured correctly, you don't need to specify the ``-k`` parameter." -msgstr "SSH キーが正しく設定されている場合は、``-k`` パラメーターを指定する必要はありません。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:179 -msgid "If the connection still fails you can combine it with the enable_network_logging parameter. For example:" -msgstr "それでも接続が失敗した場合は、これを enable_network_logging パラメーターと組み合わせることができます。以下に例を示します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:190 -msgid "Then review the log file and find the relevant error message in the rest of this document." -msgstr "次に、ログファイルを確認し、このドキュメントの残りの部分で、関連するエラーメッセージを見つけます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:197 -msgid "Troubleshooting socket path issues" -msgstr "ソケットパスの問題のトラブルシューティング" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:201 -msgid "The ``Socket path does not exist or cannot be found`` and ``Unable to connect to socket`` messages indicate that the socket used to communicate with the remote network device is unavailable or does not exist." -msgstr "``Socket path does not exist or cannot be found`` メッセージおよび ``Unable to connect to socket``メッセージは、リモートネットワークデバイスとの通信に使用されるソケットが利用できないか、存在しないことを示しています。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:216 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:241 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:378 -msgid "or" -msgstr "または" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:229 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:283 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:309 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:335 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:369 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:419 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:450 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:476 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:502 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:513 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:539 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:623 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:795 -msgid "Suggestions to resolve:" -msgstr "解決するためのヒント:" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:231 -msgid "Verify that you have write access to the socket path described in the error message." -msgstr "エラーメッセージに記載されているソケットパスへの書き込み権限があることを確認します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:233 -msgid "Follow the steps detailed in :ref:`enable network logging `." -msgstr "「:ref:`ネットワークロギングの有効化 `」記載される手順に従ってください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:235 -msgid "If the identified error message from the log file is:" -msgstr "ログファイルから特定されたエラーメッセージが以下の場合は、" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:247 -msgid "Follow the steps detailed in :ref:`timeout issues `" -msgstr "「:ref:`タイムアウトの問題 `」に記載の手順に従ってください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:253 -msgid "Category \"Unable to open shell\"" -msgstr "Category \"Unable to open shell\"" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:258 -msgid "The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. It is a \"catch all\" message, meaning you need to enable :ref:`logging ` to find the underlying issues." -msgstr "``unable to open shell`` メッセージは、``ansible-connection`` デーモンがリモートネットワークデバイスと正常に通信できなかったことを示します。これは通常、認証の問題があることを意味します。これは「catch all (全て取得する)」メッセージです。つまり、:ref:`logging ` を有効にして、根本的な問題を検出する必要があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:270 -msgid "or:" -msgstr "または" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:285 -msgid "Follow the steps detailed in enable_network_logging_." -msgstr "enable_network_logging_ に記載の手順に従います。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:287 -msgid "Once you've identified the error message from the log file, the specific solution can be found in the rest of this document." -msgstr "ログファイルからエラーメッセージが特定できたら、特定の解決方法は、本ガイドのその他のセクションを参照してください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:292 -msgid "Error: \"[Errno -2] Name or service not known\"" -msgstr "Error: \"[Errno -2] Name or service not known\"" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:296 -msgid "Indicates that the remote host you are trying to connect to can not be reached" -msgstr "接続しようとしているリモートホストに到達できないことを示します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:311 -msgid "If you are using the ``provider:`` options ensure that its suboption ``host:`` is set correctly." -msgstr "``provider:`` オプションを使用している場合は、サブオプション ``host:`` が正しく設定されていることを確認します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:312 -msgid "If you are not using ``provider:`` nor top-level arguments ensure your inventory file is correct." -msgstr "``provider:`` またはトップレベルの引数を使用しない場合には、インベントリーファイルが正しいことを確認してください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:319 -msgid "Error: \"Authentication failed\"" -msgstr "Error: \"Authentication failed\"" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:323 -msgid "Occurs if the credentials (username, passwords, or ssh keys) passed to ``ansible-connection`` (via ``ansible`` or ``ansible-playbook``) can not be used to connect to the remote device." -msgstr "(``ansible`` または ``ansible-playbook`` を使用して) ``ansible-connection`` に渡される認証情報 (ユーザー名、パスワード、または ssh キー) を使用してリモートデバイスに接続できない場合に発生します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:337 -msgid "If you are specifying credentials via ``password:`` (either directly or via ``provider:``) or the environment variable `ANSIBLE_NET_PASSWORD` it is possible that ``paramiko`` (the Python SSH library that Ansible uses) is using ssh keys, and therefore the credentials you are specifying are being ignored. To find out if this is the case, disable \"look for keys\". This can be done like this:" -msgstr "(直接または ``provider:`` を使用して) ``password:`` で認証情報を指定する場合や、環境変数 `ANSIBLE_NET_PASSWORD` を指定する場合は、``paramiko`` (Ansible が使用する Python SSH ライブラリー) が ssh キーを使用している可能性があるため、指定する認証情報が無効になります。これを確認するには、「look for keys」を無効にします。これは次のように行います。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:343 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:458 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:485 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:550 -msgid "To make this a permanent change, add the following to your ``ansible.cfg`` file:" -msgstr "これを永続的に行うには、以下を ``ansible.cfg`` ファイルに追加します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:352 -msgid "Error: \"connecting to host returned an error\" or \"Bad address\"" -msgstr "Error: \"connecting to host returned an error\" or \"Bad address\"" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:354 -msgid "This may occur if the SSH fingerprint hasn't been added to Paramiko's (the Python SSH library) know hosts file." -msgstr "これは、SSH フィンガープリントが Paramiko の既知のホストファイル (Python SSH ライブラリー) に追加されていない場合に発生する可能性があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:356 -msgid "When using persistent connections with Paramiko, the connection runs in a background process. If the host doesn't already have a valid SSH key, by default Ansible will prompt to add the host key. This will cause connections running in background processes to fail." -msgstr "Paramiko で永続的な接続を使用する場合、接続はバックグラウンドプロセスで実行します。ホストが有効な SSH キーを持っていない場合、Ansible はデフォルトでホストキーを追加するようプロンプトを出します。これにより、バックグラウンドプロセスで実行中の接続が失敗します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:371 -msgid "Use ``ssh-keyscan`` to pre-populate the known_hosts. You need to ensure the keys are correct." -msgstr "``ssh-keyscan`` を使用して known_hosts を事前に設定します。キーが正しいことを確認してください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:380 -msgid "You can tell Ansible to automatically accept the keys" -msgstr "鍵を自動的に受け入れるように Ansible に設定できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:382 -msgid "Environment variable method::" -msgstr "環境変数メソッド::" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:387 -msgid "``ansible.cfg`` method:" -msgstr "``ansible.cfg`` メソッド:" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:389 -msgid "ansible.cfg" -msgstr "ansible.cfg" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:403 -msgid "Error: \"No authentication methods available\"" -msgstr "Error: \"No authentication methods available\"" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:421 -msgid "No password or SSH key supplied" -msgstr "パスワードまたは SSH キーが指定されていない" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:424 -msgid "Clearing Out Persistent Connections" -msgstr "永続的な接続を解除" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:428 -msgid "In Ansible 2.3, persistent connection sockets are stored in ``~/.ansible/pc`` for all network devices. When an Ansible playbook runs, the persistent socket connection is displayed when verbose output is specified." -msgstr "Ansible 2.3 では、すべてのネットワークデバイスの永続的な接続ソケットが ``~/.ansible/pc`` に保存されます。Ansible Playbook が実行すると、詳細な出力が指定されている場合に永続的なソケット接続が表示されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:430 -msgid "`` socket_path: /home/fred/.ansible/pc/f64ddfa760``" -msgstr "`` socket_path: /home/fred/.ansible/pc/f64ddfa760``" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:432 -msgid "To clear out a persistent connection before it times out (the default timeout is 30 seconds of inactivity), simple delete the socket file." -msgstr "タイムアウトする前に永続的な接続 (デフォルトのタイムアウトが 30 秒の非アクティブタイムアウト) を削除するには、ソケットファイルを簡単な削除します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:442 -msgid "Persistent connection idle timeout" -msgstr "永続的な接続アイドルタイムアウト" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:444 -msgid "By default, ``ANSIBLE_PERSISTENT_CONNECT_TIMEOUT`` is set to 30 (seconds). You may see the following error if this value is too low:" -msgstr "デフォルトでは、``ANSIBLE_PERSISTENT_CONNECT_TIMEOUT`` は 30 (秒) に設定されます。この値が低すぎると、以下のエラーが表示される可能性があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:452 -msgid "Increase value of persistent connection idle timeout:" -msgstr "永続的な接続アイドルタイムアウトの値を大きくします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:466 -msgid "Command timeout" -msgstr "コマンドタイムアウト" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:468 -msgid "By default, ``ANSIBLE_PERSISTENT_COMMAND_TIMEOUT`` is set to 30 (seconds). Prior versions of Ansible had this value set to 10 seconds by default. You may see the following error if this value is too low:" -msgstr "デフォルトでは、``ANSIBLE_PERSISTENT_COMMAND_TIMEOUT`` は 30 (秒) に設定されます。Ansible の以前のバージョンでは、デフォルトでこの値を 10 秒に設定されています。この値が低すぎると、以下のエラーが発生する可能性があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:478 -msgid "Option 1 (Global command timeout setting): Increase value of command timeout in configuration file or by setting environment variable." -msgstr "オプション 1 (グローバルコマンドのタイムアウト設定): 設定ファイル、または環境変数を設定してコマンドタイムアウトの値を増やします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:492 -msgid "Option 2 (Per task command timeout setting): Increase command timeout per task basis. All network modules support a timeout value that can be set on a per task basis. The timeout value controls the amount of time in seconds before the task will fail if the command has not returned." -msgstr "オプション 2 (タスクごとのコマンドのタイムアウト設定): タスクごとにコマンドタイムアウトを増やします。すべてのネットワークモジュールは、タスクごとに設定できるタイムアウト値をサポートしています。タイムアウト値は、コマンドが返されなかった場合にタスクが失敗するまでの時間を秒単位で制御します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:498 -msgid "For local connection type:" -msgstr "ローカル接続タイプの場合:" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:523 -msgid "Some operations take longer than the default 30 seconds to complete. One good example is saving the current running config on IOS devices to startup config. In this case, changing the timeout value from the default 30 seconds to 60 seconds will prevent the task from failing before the command completes successfully." -msgstr "一部の操作は、完了までにデフォルトの 30 秒より長くかかります。たとえば、IOS デバイス上の現在の実行設定をスタートアップ設定に保存します。この場合は、タイムアウト値をデフォルトの 30 秒から 60 秒に変更すると、コマンドが正常に完了する前にタスクが失敗するのを防ぐことができます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:530 -msgid "Persistent connection retry timeout" -msgstr "永続的な接続の再試行タイムアウト" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:532 -msgid "By default, ``ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT`` is set to 15 (seconds). You may see the following error if this value is too low:" -msgstr "デフォルトでは、``ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT`` は 15 (秒) に設定されます。この値が低すぎると、以下のエラーが表示される可能性があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:541 -msgid "Increase the value of the persistent connection idle timeout. Note: This value should be greater than the SSH timeout value (the timeout value under the defaults section in the configuration file) and less than the value of the persistent connection idle timeout (connect_timeout)." -msgstr "持続的接続アイドルタイムアウトの値を増やします。注意: この値は、SSH タイムアウト値 (設定ファイルのデフォルトセクションの下のタイムアウト値) より大きく、永続的接続アイドルタイムアウト値 (connect_timeout) より小さくする必要があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:559 -msgid "Timeout issue due to platform specific login menu with ``network_cli`` connection type" -msgstr "``network_cli`` 接続タイプを持つプラットフォーム固有のログインメニューによるタイムアウトの問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:561 -msgid "In Ansible 2.9 and later, the network_cli connection plugin configuration options are added to handle the platform specific login menu. These options can be set as group/host or tasks variables." -msgstr "Ansible 2.9 以降では、プラットフォーム固有のログインメニューを処理するために network_cli 接続プラグイン設定オプションが追加されました。これらのオプションは、グループ/ホストまたはタスク変数として設定できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:565 -msgid "Example: Handle single login menu prompts with host variables" -msgstr "例: ホスト変数を使用した 1 つのログインメニュープロンプトを処理します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:576 -msgid "Example: Handle remote host multiple login menu prompts with host variables" -msgstr "例: ホスト変数を使用したリモートホストの複数のログインメニュープロンプトを処理します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:590 -msgid "To handle multiple login menu prompts:" -msgstr "複数のログインメニュープロンプトを処理するには、以下を行います。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:592 -msgid "The values of ``ansible_terminal_initial_prompt`` and ``ansible_terminal_initial_answer`` should be a list." -msgstr "``ansible_terminal_initial_prompt`` および ``ansible_terminal_initial_answer`` の値は一覧形式である必要があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:593 -msgid "The prompt sequence should match the answer sequence." -msgstr "プロンプトシーケンスは、応答シーケンスに一致する必要があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:594 -msgid "The value of ``ansible_terminal_initial_prompt_checkall`` should be set to ``True``." -msgstr "``ansible_terminal_initial_prompt_checkall`` の値は ``True`` に設定する必要があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:596 -msgid "If all the prompts in sequence are not received from remote host at the time connection initialization it will result in a timeout." -msgstr "接続の初期化時に、リモートホストからシーケンス内のすべてのプロンプトを受け取らないと、タイムアウトが生じます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:602 -msgid "This section details issues are caused by issues with the Playbook itself." -msgstr "本セクションでは、Playbook 自体の問題が原因で発生する問題を詳しく説明します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:605 -msgid "Error: \"Unable to enter configuration mode\"" -msgstr "Error: \"Unable to enter configuration mode\"" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:607 -msgid "**Platforms:** Arista EOS and Cisco IOS" -msgstr "**プラットフォーム:** Arista EOS および Cisco IOS" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:609 -msgid "This occurs when you attempt to run a task that requires privileged mode in a user mode shell." -msgstr "これは、ユーザーモードシェルで特権モードを必要とするタスクを実行しようとすると発生します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:625 -msgid "Use ``connection: ansible.netcommon.network_cli`` and ``become: yes``" -msgstr "``connection: ansible.netcommon.network_cli`` および ``become: yes`` の使用" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:629 -msgid "Proxy Issues" -msgstr "プロキシーの問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:634 -msgid "delegate_to vs ProxyCommand" -msgstr "delegate_to 対 ProxyCommand" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:636 -msgid "In order to use a bastion or intermediate jump host to connect to network devices over ``cli`` transport, network modules support the use of ``ProxyCommand``." -msgstr "bastion または中間ジャンプホストを使用して ``cli`` トランスポートでネットワークデバイスに接続するために、ネットワークモジュールは ``ProxyCommand`` の使用に対応します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:639 -msgid "To use ``ProxyCommand``, configure the proxy settings in the Ansible inventory file to specify the proxy host." -msgstr "``ProxyCommand`` を使用するには、Ansible インベントリーファイルでプロキシー設定を設定して、プロキシーホストを指定します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:652 -msgid "With the configuration above, simply build and run the playbook as normal with no additional changes necessary. The network module will now connect to the network device by first connecting to the host specified in ``ansible_ssh_common_args``, which is ``bastion01`` in the above example." -msgstr "上記の設定では、追加の変更を必要とせずに、通常どおり Playbook をビルドして実行します。ネットワークモジュールは、最初に ``ansible_ssh_common_args`` で指定したホスト (上記の例は ``bastion01``) に接続して、ネットワークデバイスに接続します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:657 -msgid "You can also set the proxy target for all hosts by using environment variables." -msgstr "環境変数を使用して、すべてのホストのプロキシーターゲットを設定することもできます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:664 -msgid "Using bastion/jump host with netconf connection" -msgstr "netconf 接続での bastion/ジャンプホストの使用" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:667 -msgid "Enabling jump host setting" -msgstr "ジャンプホスト設定の有効化" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:673 -msgid "Bastion/jump host with netconf connection can be enabled by:" -msgstr "netconf 接続を持つ bastion/ジャンプホストは、以下で有効にできます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:671 -msgid "Setting Ansible variable ``ansible_netconf_ssh_config`` either to ``True`` or custom ssh config file path" -msgstr "Ansible 変数 ``ansible_netconf_ssh_config`` を ``True`` またはカスタムの ssh 設定ファイルパスに設定" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:672 -msgid "Setting environment variable ``ANSIBLE_NETCONF_SSH_CONFIG`` to ``True`` or custom ssh config file path" -msgstr "環境変数 ``ANSIBLE_NETCONF_SSH_CONFIG`` を ``True`` またはカスタムの ssh 設定ファイルパスに設定" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:673 -msgid "Setting ``ssh_config = 1`` or ``ssh_config = `` under ``netconf_connection`` section" -msgstr "``ssh_config = 1`` セクションの下に ``ssh_config = `` または ``netconf_connection`` の設定" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:675 -msgid "If the configuration variable is set to 1 the proxycommand and other ssh variables are read from default ssh config file (~/.ssh/config)." -msgstr "設定変数が 1 に設定されている場合、proxycommand およびその他の ssh 変数はデフォルトの ssh 設定ファイル (~/.ssh/config) から読み込まれます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:678 -msgid "If the configuration variable is set to file path the proxycommand and other ssh variables are read from the given custom ssh file path" -msgstr "設定変数がファイルパスに設定されていると、proxycommand およびその他の ssh 変数は指定のカスタム ssh ファイルパスから読み込まれます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:682 -msgid "Example ssh config file (~/.ssh/config)" -msgstr "ssh 設定ファイルの例 (~/.ssh/config)" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:709 -msgid "Example Ansible inventory file" -msgstr "Ansible インベントリーファイルの例" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:723 -msgid "Using ``ProxyCommand`` with passwords via variables" -msgstr "変数を介したパスワードでの ``ProxyCommand`` の使用" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:725 -msgid "By design, SSH doesn't support providing passwords via environment variables. This is done to prevent secrets from leaking out, for example in ``ps`` output." -msgstr "設計上、SSH は環境変数経由でパスワードの提供をサポートしません。これは、``ps`` の出力など、シークレットがリークしないようにします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:728 -msgid "We recommend using SSH Keys, and if needed an ssh-agent, rather than passwords, where ever possible." -msgstr "SSH 鍵を使用することを推奨します。必要に応じて、可能な場合は、パスワードではなく ssh-agent を使用することが推奨されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:731 -msgid "Miscellaneous Issues" -msgstr "その他の問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:735 -msgid "Intermittent failure while using ``ansible.netcommon.network_cli`` connection type" -msgstr "``ansible.netcommon.network_cli`` 接続タイプの使用中に断続的な失敗" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:737 -msgid "If the command prompt received in response is not matched correctly within the ``ansible.netcommon.network_cli`` connection plugin the task might fail intermittently with truncated response or with the error message ``operation requires privilege escalation``. Starting in 2.7.1 a new buffer read timer is added to ensure prompts are matched properly and a complete response is send in output. The timer default value is 0.2 seconds and can be adjusted on a per task basis or can be set globally in seconds." -msgstr "応答で受け取ったコマンドプロンプトが ``ansible.netcommon.network_cli`` 接続プラグイン内で正しく一致しないと、タスクが断続的に失敗し、応答が切り捨てられるか、エラーメッセージ ``operation requires privilege escalation`` が表示されることがあります。2.7.1 以降、プロンプトが正しく一致し、完全な応答が出力に送信されるように、新しいバッファ読み取りタイマーが追加されました。タイマーのデフォルト値は 0.2 秒で、タスクごとに調整することも、秒単位でグローバルに設定することもできます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:744 -msgid "Example Per task timer setting" -msgstr "タスクタイマーごとの設定例" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:763 -msgid "This timer delay per command executed on remote host can be disabled by setting the value to zero." -msgstr "リモートホストで実行されるコマンド別のこのタイマー遅延は、値をゼロに設定すると無効にできます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:767 -msgid "Task failure due to mismatched error regex within command response using ``ansible.netcommon.network_cli`` connection type" -msgstr "``ansible.netcommon.network_cli`` 接続タイプを使用したコマンド応答内のエラー正規表現の不一致によるタスクの失敗" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:769 -msgid "In Ansible 2.9 and later, the ``ansible.netcommon.network_cli`` connection plugin configuration options are added to handle the stdout and stderr regex to identify if the command execution response consist of a normal response or an error response. These options can be set group/host variables or as tasks variables." -msgstr "Ansible 2.9 以降では、``ansible.netcommon.network_cli`` 接続プラグイン設定オプションが追加され、標準出力と標準エラーの正規表現を処理して、コマンド実行応答が通常の応答かエラー応答かを識別します。これらのオプションは、グループ/ホスト変数またはタスク変数として設定できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:774 -msgid "Example: For mismatched error response" -msgstr "例: 不一致のエラー応答の場合" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:784 -msgid "Playbook run output:" -msgstr "Playbook 実行の出力:" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:797 -msgid "Modify the error regex for individual task." -msgstr "個々のタスクのエラー正規表現を変更します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:810 -msgid "The terminal plugin regex options ``ansible_terminal_stderr_re`` and ``ansible_terminal_stdout_re`` have ``pattern`` and ``flags`` as keys. The value of the ``flags`` key should be a value that is accepted by the ``re.compile`` python method." -msgstr "端末プラグインの正規表現オプション ``ansible_terminal_stderr_re`` および ``ansible_terminal_stdout_re`` は、``pattern`` と ``flags`` をキーとします。``flags`` キーの値は、``re.compile`` python メソッドで許可される値である必要があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:816 -msgid "Intermittent failure while using ``ansible.netcommon.network_cli`` connection type due to slower network or remote target host" -msgstr "低速ネットワークまたはリモートターゲットホストによる ``ansible.netcommon.network_cli`` 接続タイプの使用時の断続的な失敗" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:818 -msgid "In Ansible 2.9 and later, the ``ansible.netcommon.network_cli`` connection plugin configuration option is added to control the number of attempts to connect to a remote host. The default number of attempts is three. After every retry attempt the delay between retries is increased by power of 2 in seconds until either the maximum attempts are exhausted or either the ``persistent_command_timeout`` or ``persistent_connect_timeout`` timers are triggered." -msgstr "Ansible 2.9 以降では、リモートホストへの接続の試行回数を制御するために、``ansible.netcommon.network_cli`` 接続プラグイン設定オプションが追加されました。デフォルトの試行回数は 3 回です。再試行のたびに、最大試行回数がなくなるか、``persistent_command_timeout`` または ``persistent_connect_timeout`` タイマーのいずれかが発生するまで、再試行間の遅延は 2 の累乗 (秒) ずつ増加します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:5 -msgid "Network Resource Modules" -msgstr "ネットワークリソースモジュール" - -#: ../../rst/network/user_guide/network_resource_modules.rst:7 -msgid "Ansible network resource modules simplify and standardize how you manage different network devices. Network devices separate configuration into sections (such as interfaces and VLANs) that apply to a network service. Ansible network resource modules take advantage of this to allow you to configure subsections or *resources* within the network device configuration. Network resource modules provide a consistent experience across different network devices." -msgstr "Ansible ネットワークリソースモジュールは、さまざまなネットワークデバイスの管理方法を簡素化し、標準化します。ネットワークデバイスは、ネットワークサービスに適用されるセクション (インターフェースや VLAN など) に設定を分割します。Ansible ネットワークリソースモジュールはこれを利用して、ネットワークデバイス設定内でサブセクションや *リソース* を設定することができます。ネットワークリソースモジュールは、異なるネットワークデバイス間で一貫したエクスペリエンスを提供します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:14 -msgid "Network resource module states" -msgstr "ネットワークリソースモジュールの状態" - -#: ../../rst/network/user_guide/network_resource_modules.rst:16 -msgid "You use the network resource modules by assigning a state to what you want the module to do. The resource modules support the following states:" -msgstr "モジュールの動作に状態を割り当てて、ネットワークリソースモジュールを使用します。リソースモジュールは以下の状態をサポートします。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:40 -msgid "Using network resource modules" -msgstr "ネットワークリソースモジュールの使用" - -#: ../../rst/network/user_guide/network_resource_modules.rst:42 -msgid "This example configures the L3 interface resource on a Cisco IOS device, based on different state settings." -msgstr "この例では、異なる状態設定に基づいて、Cisco IOS デバイスで L3 インターフェースリソースを設定します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:51 -msgid "The following table shows an example of how an initial resource configuration changes with this task for different states." -msgstr "以下の表は、このタスクで初期リソースの設定が異なる状態で変化する例を示しています。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:54 -msgid "Resource starting configuration" -msgstr "リソース起動の設定" - -#: ../../rst/network/user_guide/network_resource_modules.rst:54 -msgid "task-provided configuration (YAML)" -msgstr "タスク提供設定 (YAML)" - -#: ../../rst/network/user_guide/network_resource_modules.rst:54 -msgid "Final resource configuration on device" -msgstr "デバイスの最終的なリソース設定" - -#: ../../rst/network/user_guide/network_resource_modules.rst:61 -msgid "*merged*" -msgstr "*マージ*" - -#: ../../rst/network/user_guide/network_resource_modules.rst:69 -msgid "*replaced*" -msgstr "*置き換え済*" - -#: ../../rst/network/user_guide/network_resource_modules.rst:73 -msgid "*overridden*" -msgstr "*上書き済*" - -#: ../../rst/network/user_guide/network_resource_modules.rst:73 -msgid "Incorrect use case. This would remove all interfaces from the device" -msgstr "誤ったユースケース。これにより、デバイスからすべてのインターフェースが削除されます。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:75 -msgid "(including the mgmt interface) except" -msgstr "(mgmt インターフェースを含む) 以下を除く" - -#: ../../rst/network/user_guide/network_resource_modules.rst:76 -msgid "the configured loopback100" -msgstr "設定されている loopback100" - -#: ../../rst/network/user_guide/network_resource_modules.rst:81 -msgid "*deleted*" -msgstr "*削除済*" - -#: ../../rst/network/user_guide/network_resource_modules.rst:85 -msgid "Network resource modules return the following details:" -msgstr "ネットワークリソースモジュールは、以下の詳細を返します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:87 -msgid "The *before* state - the existing resource configuration before the task was executed." -msgstr "*before* 状態 - タスクの実行前の既存リソース設定。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:88 -msgid "The *after* state - the new resource configuration that exists on the network device after the task was executed." -msgstr "*after* 状態 - タスク実行後にネットワークデバイスに存在する新しいリソース設定。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:89 -msgid "Commands - any commands configured on the device." -msgstr "コマンド - このデバイスに設定されるすべてのコマンド。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:122 -msgid "Example: Verifying the network device configuration has not changed" -msgstr "例: ネットワークデバイス設定が変更されていないことを確認" - -#: ../../rst/network/user_guide/network_resource_modules.rst:124 -msgid "The following playbook uses the :ref:`arista.eos.eos_l3_interfaces ` module to gather a subset of the network device configuration (Layer 3 interfaces only) and verifies the information is accurate and has not changed. This playbook passes the results of :ref:`arista.eos.eos_facts ` directly to the ``arista.eos.eos_l3_interfaces`` module." -msgstr "以下の Playbook は、:ref:`arista.eos.eos_l3_interfaces ` モジュールを使用してネットワークデバイス設定のサブセット (レイヤー 3 インターフェースのみ) を収集し、情報が正確であり、変更されていないことを確認します。この Playbook は、:ref:`arista.eos.eos_facts ` の結果を直接 ``arista.eos.eos_l3_interfaces`` モジュールに渡します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:148 -msgid "Example: Acquiring and updating VLANs on a network device" -msgstr "例: ネットワークデバイスの VLAN の調整および更新" - -#: ../../rst/network/user_guide/network_resource_modules.rst:150 -msgid "This example shows how you can use resource modules to:" -msgstr "以下の例は、リソースモジュールを使用して以下を行う方法を示しています。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:152 -msgid "Retrieve the current configuration on a network device." -msgstr "ネットワークデバイスの現在の設定を取得します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:153 -msgid "Save that configuration locally." -msgstr "その設定をローカルに保存します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:154 -msgid "Update that configuration and apply it to the network device." -msgstr "その設定を更新して、ネットワークデバイスに適用します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:156 -msgid "This example uses the ``cisco.ios.ios_vlans`` resource module to retrieve and update the VLANs on an IOS device." -msgstr "この例では、``cisco.ios.ios_vlans`` リソースモジュールを使用して、IOS デバイスの VLAN を取得および更新します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:158 -msgid "Retrieve the current IOS VLAN configuration:" -msgstr "現在の IOS VLAN 設定を取得します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:170 -msgid "Store the VLAN configuration locally:" -msgstr "VLAN 設定をローカルに保存します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:179 -msgid "Modify the stored file to update the VLAN configuration locally." -msgstr "保存したファイルを変更して、VLAN 設定をローカルに更新します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:181 -msgid "Merge the updated VLAN configuration with the existing configuration on the device:" -msgstr "更新された VLAN 設定を、デバイス上の既存の設定とマージします。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:193 -msgid "`Network Features in Ansible 2.9 `_" -msgstr "`Network Features in Ansible 2.9 `_" - -#: ../../rst/network/user_guide/network_resource_modules.rst:194 -msgid "A introductory blog post on network resource modules." -msgstr "ネットワークリソースモジュールに関する入門ブログの投稿" - -#: ../../rst/network/user_guide/network_resource_modules.rst:195 -msgid "`Deep Dive into Network Resource Modules `_" -msgstr "`Deep Dive into Network Resource Modules `_" - -#: ../../rst/network/user_guide/network_resource_modules.rst:196 -msgid "A deeper dive presentation into network resource modules." -msgstr "ネットワークリソースモジュールの詳細な説明" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:5 -msgid "Working with command output and prompts in network modules" -msgstr "ネットワークモジュールのコマンド出力およびプロンプトの使用" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:11 -msgid "Conditionals in networking modules" -msgstr "ネットワークモジュールの条件" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:13 -msgid "Ansible allows you to use conditionals to control the flow of your playbooks. Ansible networking command modules use the following unique conditional statements." -msgstr "Ansible では、条件を使用して Playbook のフローを制御できます。Ansible ネットワークコマンドモジュールは、以下の固有の条件付きステートメントを使用します。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:15 -msgid "``eq`` - Equal" -msgstr "``eq`` - 等しい" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:16 -msgid "``neq`` - Not equal" -msgstr "``neq`` - 等しくない" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:17 -msgid "``gt`` - Greater than" -msgstr "``gt`` - より大きい" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:18 -msgid "``ge`` - Greater than or equal" -msgstr "``ge`` - より大きいか等しい" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:19 -msgid "``lt`` - Less than" -msgstr "``lt`` - より小さい" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:20 -msgid "``le`` - Less than or equal" -msgstr "``le`` - より小さいか等しい" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:21 -msgid "``contains`` - Object contains specified item" -msgstr "``contains`` - オブジェクトに指定された項目が含まれる" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:24 -msgid "Conditional statements evaluate the results from the commands that are executed remotely on the device. Once the task executes the command set, the ``wait_for`` argument can be used to evaluate the results before returning control to the Ansible playbook." -msgstr "条件文は、デバイス上でリモートに実行されるコマンドの結果を評価します。タスクがコマンドセットを実行すると、Ansible Playbook に制御を戻す前に、``wait_for`` 引数を使用して結果を評価できます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:29 -msgid "For example::" -msgstr "例::" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:39 -msgid "In the above example task, the command :code:`show interface Ethernet4 | json` is executed on the remote device and the results are evaluated. If the path :code:`(result[0].interfaces.Ethernet4.interfaceStatus)` is not equal to \"connected\", then the command is retried. This process continues until either the condition is satisfied or the number of retries has expired (by default, this is 10 retries at 1 second intervals)." -msgstr "上記のタスク例では、リモートデバイスで command :code:`show interface Ethernet4 | json` が実行され、結果が評価されます。path :code:`(result[0].interfaces.Ethernet4.interfaceStatus)`が「connected」になっていなければ、コマンドは再試行されます。この処理は、条件が満たされるか、再試行回数が期限切れになる (デフォルトでは、1 秒間隔で 10 回の再試行) まで継続されます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:47 -msgid "The commands module can also evaluate more than one set of command results in an interface. For instance::" -msgstr "また、commands モジュールは、1 つのインターフェースで複数のコマンド結果を評価することもできます。たとえば、以下のようになります。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:60 -msgid "In the above example, two commands are executed on the remote device, and the results are evaluated. By specifying the result index value (0 or 1), the correct result output is checked against the conditional." -msgstr "上記の例では、2 つのコマンドがリモートデバイスで実行され、結果が評価されます。結果のインデックス値 (0 または 1) を指定することで、条件に対して正しい結果出力が確認されます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:65 -msgid "The ``wait_for`` argument must always start with result and then the command index in ``[]``, where ``0`` is the first command in the commands list, ``1`` is the second command, ``2`` is the third and so on." -msgstr "``wait_for`` 引数は、必ず結果で、次に ``[]`` のコマンドインデックスが必要です。``0`` はコマンドリストの最初のコマンド、``1`` は 2 番目のコマンド、``2`` は 3 番目のコマンドなどになります。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:71 -msgid "Handling prompts in network modules" -msgstr "ネットワークモジュールのプロンプトの処理" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:73 -msgid "Network devices may require that you answer a prompt before performing a change on the device. Individual network modules such as :ref:`cisco.ios.ios_command ` and :ref:`cisco.nxos.nxos_command ` can handle this with a ``prompt`` parameter." -msgstr "ネットワークデバイスは、デバイスの変更を実行する前にプロンプトの回答が必要になる場合があります。:ref:`cisco.ios.ios_command ` および :ref:`cisco.nxos.nxos_command ` などの個別ネットワークモジュールは ``prompt`` パラメーターでこれを処理できます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:77 -msgid "``prompt`` is a Python regex. If you add special characters such as ``?`` in the ``prompt`` value, the prompt won't match and you will get a timeout. To avoid this, ensure that the ``prompt`` value is a Python regex that matches the actual device prompt. Any special characters must be handled correctly in the ``prompt`` regex." -msgstr "``prompt`` は Python の正規表現です。``prompt`` 値に ``?`` などの特殊文字を追加すると、プロンプトが一致せず、タイムアウトが発生します。これを回避するには、``prompt`` 値が実際のデバイスプロンプトと一致する Python 正規表現であることを確認します。特殊文字は、``prompt`` 正規表現で正しく処理する必要があります。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:79 -msgid "You can also use the :ref:`ansible.netcommon.cli_command ` to handle multiple prompts." -msgstr ":ref:`ansible.netcommon.cli_command ` を使用して、複数のプロンプトを処理することもできます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:97 -msgid "You must list the prompt and the answers in the same order (that is, prompt[0] is answered by answer[0])." -msgstr "プロンプトと回答を同じ順序で一覧表示する必要があります (つまり、prompt[0] には answer[0] で応答します)。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:99 -msgid "In the above example, ``check_all: True`` ensures that the task gives the matching answer to each prompt. Without that setting, a task with multiple prompts would give the first answer to every prompt." -msgstr "上記の例では、``check_all: True`` により、タスクが各プロンプトに一致する応答を返すようにします。この設定がないと、複数のプロンプトがあるタスクでは、すべてのプロンプトに対して最初の応答が表示されます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:101 -msgid "In the following example, the second answer would be ignored and ``y`` would be the answer given to both prompts. That is, this task only works because both answers are identical. Also notice again that ``prompt`` must be a Python regex, which is why the ``?`` is escaped in the first prompt." -msgstr "次の例では、2 番目の回答は無視され、両方のプロンプトに ``y`` が入力されます。つまり、このタスクが機能するのは、両方の答えが同じだからです。また、``prompt`` は Python の正規表現でなければならないことにも注意してください。このため、``?`` は最初のプロンプトでエスケープされます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:119 -msgid "`Rebooting network devices with Ansible `_" -msgstr "`Rebooting network devices with Ansible `_" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:119 -msgid "Examples using ``wait_for``, ``wait_for_connection``, and ``prompt`` for network devices." -msgstr "ネットワークデバイス用に ``wait_for``、``wait_for_connection``、および ``prompt`` を使用する例。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:121 -msgid "`Deep dive on cli_command `_" -msgstr "`Deep dive on cli_command `_" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:122 -msgid "Detailed overview of how to use the ``cli_command``." -msgstr "``cli_command`` の使用方法に関する詳細な概要" - -#: ../../rst/network/user_guide/platform_ce.rst:5 -msgid "CloudEngine OS Platform Options" -msgstr "CloudEngine OS プラットフォームオプション" - -#: ../../rst/network/user_guide/platform_ce.rst:7 -msgid "CloudEngine CE OS is part of the `community.network `_ collection and supports multiple connections. This page offers details on how each connection works in Ansible and how to use it." -msgstr "CloudEngine CE OS は `community.network `_ コレクションの一部で、複数の接続をサポートします。このページでは、Ansible での各接続がどのように機能し、どのように使用されるかを詳細に説明します。" - -#: ../../rst/network/user_guide/platform_ce.rst:13 -#: ../../rst/network/user_guide/platform_cnos.rst:13 -#: ../../rst/network/user_guide/platform_dellos10.rst:13 -#: ../../rst/network/user_guide/platform_dellos6.rst:13 -#: ../../rst/network/user_guide/platform_dellos9.rst:13 -#: ../../rst/network/user_guide/platform_enos.rst:13 -#: ../../rst/network/user_guide/platform_eos.rst:13 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:13 -#: ../../rst/network/user_guide/platform_exos.rst:13 -#: ../../rst/network/user_guide/platform_frr.rst:13 -#: ../../rst/network/user_guide/platform_icx.rst:13 -#: ../../rst/network/user_guide/platform_ios.rst:13 -#: ../../rst/network/user_guide/platform_iosxr.rst:13 -#: ../../rst/network/user_guide/platform_ironware.rst:13 -#: ../../rst/network/user_guide/platform_junos.rst:13 -#: ../../rst/network/user_guide/platform_meraki.rst:13 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:13 -#: ../../rst/network/user_guide/platform_netvisor.rst:14 -#: ../../rst/network/user_guide/platform_nos.rst:14 -#: ../../rst/network/user_guide/platform_nxos.rst:13 -#: ../../rst/network/user_guide/platform_routeros.rst:14 -#: ../../rst/network/user_guide/platform_slxos.rst:14 -#: ../../rst/network/user_guide/platform_voss.rst:14 -#: ../../rst/network/user_guide/platform_vyos.rst:13 -msgid "Connections available" -msgstr "利用可能な接続" - -#: ../../rst/network/user_guide/platform_ce.rst:19 -#: ../../rst/network/user_guide/platform_cnos.rst:19 -#: ../../rst/network/user_guide/platform_dellos10.rst:19 -#: ../../rst/network/user_guide/platform_dellos6.rst:19 -#: ../../rst/network/user_guide/platform_dellos9.rst:19 -#: ../../rst/network/user_guide/platform_enos.rst:19 -#: ../../rst/network/user_guide/platform_eos.rst:19 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:19 -#: ../../rst/network/user_guide/platform_exos.rst:20 -#: ../../rst/network/user_guide/platform_frr.rst:19 -#: ../../rst/network/user_guide/platform_icx.rst:19 -#: ../../rst/network/user_guide/platform_ios.rst:19 -#: ../../rst/network/user_guide/platform_iosxr.rst:19 -#: ../../rst/network/user_guide/platform_ironware.rst:19 -#: ../../rst/network/user_guide/platform_junos.rst:19 -#: ../../rst/network/user_guide/platform_netvisor.rst:20 -#: ../../rst/network/user_guide/platform_nos.rst:20 -#: ../../rst/network/user_guide/platform_nxos.rst:19 -#: ../../rst/network/user_guide/platform_routeros.rst:20 -#: ../../rst/network/user_guide/platform_slxos.rst:20 -#: ../../rst/network/user_guide/platform_voss.rst:20 -#: ../../rst/network/user_guide/platform_vyos.rst:19 -msgid "CLI" -msgstr "CLI" - -#: ../../rst/network/user_guide/platform_ce.rst:19 -#: ../../rst/network/user_guide/platform_iosxr.rst:19 -#: ../../rst/network/user_guide/platform_junos.rst:19 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:18 -msgid "NETCONF" -msgstr "NETCONF" - -#: ../../rst/network/user_guide/platform_ce.rst:23 -#: ../../rst/network/user_guide/platform_cnos.rst:21 -#: ../../rst/network/user_guide/platform_dellos10.rst:21 -#: ../../rst/network/user_guide/platform_dellos6.rst:21 -#: ../../rst/network/user_guide/platform_dellos9.rst:21 -#: ../../rst/network/user_guide/platform_enos.rst:21 -#: ../../rst/network/user_guide/platform_eos.rst:21 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:21 -#: ../../rst/network/user_guide/platform_exos.rst:22 -#: ../../rst/network/user_guide/platform_frr.rst:21 -#: ../../rst/network/user_guide/platform_icx.rst:21 -#: ../../rst/network/user_guide/platform_ios.rst:21 -#: ../../rst/network/user_guide/platform_iosxr.rst:25 -#: ../../rst/network/user_guide/platform_ironware.rst:21 -#: ../../rst/network/user_guide/platform_junos.rst:24 -#: ../../rst/network/user_guide/platform_netvisor.rst:22 -#: ../../rst/network/user_guide/platform_nos.rst:22 -#: ../../rst/network/user_guide/platform_nxos.rst:21 -#: ../../rst/network/user_guide/platform_routeros.rst:22 -#: ../../rst/network/user_guide/platform_slxos.rst:22 -#: ../../rst/network/user_guide/platform_voss.rst:22 -#: ../../rst/network/user_guide/platform_vyos.rst:21 -msgid "SSH" -msgstr "SSH" - -#: ../../rst/network/user_guide/platform_ce.rst:25 -#: ../../rst/network/user_guide/platform_cnos.rst:23 -#: ../../rst/network/user_guide/platform_dellos10.rst:23 -#: ../../rst/network/user_guide/platform_dellos6.rst:23 -#: ../../rst/network/user_guide/platform_dellos9.rst:23 -#: ../../rst/network/user_guide/platform_enos.rst:23 -#: ../../rst/network/user_guide/platform_eos.rst:23 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:23 -#: ../../rst/network/user_guide/platform_exos.rst:24 -#: ../../rst/network/user_guide/platform_frr.rst:23 -#: ../../rst/network/user_guide/platform_icx.rst:23 -#: ../../rst/network/user_guide/platform_ios.rst:23 -#: ../../rst/network/user_guide/platform_iosxr.rst:27 -#: ../../rst/network/user_guide/platform_ironware.rst:23 -#: ../../rst/network/user_guide/platform_junos.rst:26 -#: ../../rst/network/user_guide/platform_meraki.rst:23 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:25 -#: ../../rst/network/user_guide/platform_netvisor.rst:24 -#: ../../rst/network/user_guide/platform_nos.rst:24 -#: ../../rst/network/user_guide/platform_nxos.rst:23 -#: ../../rst/network/user_guide/platform_routeros.rst:24 -#: ../../rst/network/user_guide/platform_slxos.rst:24 -#: ../../rst/network/user_guide/platform_voss.rst:24 -#: ../../rst/network/user_guide/platform_vyos.rst:23 -msgid "Credentials" -msgstr "認証情報" - -#: ../../rst/network/user_guide/platform_ce.rst:25 -#: ../../rst/network/user_guide/platform_cnos.rst:23 -#: ../../rst/network/user_guide/platform_dellos10.rst:23 -#: ../../rst/network/user_guide/platform_dellos6.rst:23 -#: ../../rst/network/user_guide/platform_dellos9.rst:23 -#: ../../rst/network/user_guide/platform_enos.rst:23 -#: ../../rst/network/user_guide/platform_eos.rst:23 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:23 -#: ../../rst/network/user_guide/platform_exos.rst:24 -#: ../../rst/network/user_guide/platform_frr.rst:23 -#: ../../rst/network/user_guide/platform_icx.rst:23 -#: ../../rst/network/user_guide/platform_ios.rst:23 -#: ../../rst/network/user_guide/platform_iosxr.rst:27 -#: ../../rst/network/user_guide/platform_ironware.rst:23 -#: ../../rst/network/user_guide/platform_junos.rst:26 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:25 -#: ../../rst/network/user_guide/platform_netvisor.rst:24 -#: ../../rst/network/user_guide/platform_nos.rst:24 -#: ../../rst/network/user_guide/platform_nxos.rst:23 -#: ../../rst/network/user_guide/platform_routeros.rst:24 -#: ../../rst/network/user_guide/platform_slxos.rst:24 -#: ../../rst/network/user_guide/platform_voss.rst:24 -#: ../../rst/network/user_guide/platform_vyos.rst:23 -msgid "uses SSH keys / SSH-agent if present" -msgstr "SSH キー/SSH-agent が存在する場合は使用します" - -#: ../../rst/network/user_guide/platform_ce.rst:27 -#: ../../rst/network/user_guide/platform_cnos.rst:25 -#: ../../rst/network/user_guide/platform_dellos10.rst:25 -#: ../../rst/network/user_guide/platform_dellos6.rst:25 -#: ../../rst/network/user_guide/platform_dellos9.rst:25 -#: ../../rst/network/user_guide/platform_enos.rst:25 -#: ../../rst/network/user_guide/platform_eos.rst:25 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:25 -#: ../../rst/network/user_guide/platform_exos.rst:26 -#: ../../rst/network/user_guide/platform_frr.rst:25 -#: ../../rst/network/user_guide/platform_icx.rst:25 -#: ../../rst/network/user_guide/platform_ios.rst:25 -#: ../../rst/network/user_guide/platform_iosxr.rst:29 -#: ../../rst/network/user_guide/platform_ironware.rst:25 -#: ../../rst/network/user_guide/platform_junos.rst:28 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:27 -#: ../../rst/network/user_guide/platform_netvisor.rst:26 -#: ../../rst/network/user_guide/platform_nos.rst:26 -#: ../../rst/network/user_guide/platform_nxos.rst:25 -#: ../../rst/network/user_guide/platform_routeros.rst:26 -#: ../../rst/network/user_guide/platform_slxos.rst:26 -#: ../../rst/network/user_guide/platform_voss.rst:26 -#: ../../rst/network/user_guide/platform_vyos.rst:25 -msgid "accepts ``-u myuser -k`` if using password" -msgstr "パスワードを使用する場合に ``-u myuser -k`` を受け入れます。" - -#: ../../rst/network/user_guide/platform_ce.rst:29 -#: ../../rst/network/user_guide/platform_cnos.rst:27 -#: ../../rst/network/user_guide/platform_dellos10.rst:27 -#: ../../rst/network/user_guide/platform_dellos6.rst:27 -#: ../../rst/network/user_guide/platform_dellos9.rst:27 -#: ../../rst/network/user_guide/platform_enos.rst:27 -#: ../../rst/network/user_guide/platform_eos.rst:27 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:27 -#: ../../rst/network/user_guide/platform_exos.rst:28 -#: ../../rst/network/user_guide/platform_frr.rst:27 -#: ../../rst/network/user_guide/platform_icx.rst:27 -#: ../../rst/network/user_guide/platform_ios.rst:27 -#: ../../rst/network/user_guide/platform_iosxr.rst:31 -#: ../../rst/network/user_guide/platform_ironware.rst:27 -#: ../../rst/network/user_guide/platform_junos.rst:30 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:29 -#: ../../rst/network/user_guide/platform_netvisor.rst:28 -#: ../../rst/network/user_guide/platform_nos.rst:28 -#: ../../rst/network/user_guide/platform_nxos.rst:27 -#: ../../rst/network/user_guide/platform_routeros.rst:28 -#: ../../rst/network/user_guide/platform_slxos.rst:28 -#: ../../rst/network/user_guide/platform_voss.rst:28 -#: ../../rst/network/user_guide/platform_vyos.rst:27 -msgid "Indirect Access" -msgstr "間接アクセス" - -#: ../../rst/network/user_guide/platform_ce.rst:29 -#: ../../rst/network/user_guide/platform_cnos.rst:27 -#: ../../rst/network/user_guide/platform_dellos10.rst:27 -#: ../../rst/network/user_guide/platform_dellos6.rst:27 -#: ../../rst/network/user_guide/platform_dellos9.rst:27 -#: ../../rst/network/user_guide/platform_enos.rst:27 -#: ../../rst/network/user_guide/platform_eos.rst:27 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:27 -#: ../../rst/network/user_guide/platform_exos.rst:28 -#: ../../rst/network/user_guide/platform_frr.rst:27 -#: ../../rst/network/user_guide/platform_icx.rst:27 -#: ../../rst/network/user_guide/platform_ios.rst:27 -#: ../../rst/network/user_guide/platform_iosxr.rst:31 -#: ../../rst/network/user_guide/platform_ironware.rst:27 -#: ../../rst/network/user_guide/platform_junos.rst:30 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:29 -#: ../../rst/network/user_guide/platform_netvisor.rst:28 -#: ../../rst/network/user_guide/platform_nos.rst:28 -#: ../../rst/network/user_guide/platform_nxos.rst:27 -#: ../../rst/network/user_guide/platform_routeros.rst:28 -#: ../../rst/network/user_guide/platform_slxos.rst:28 -#: ../../rst/network/user_guide/platform_voss.rst:28 -#: ../../rst/network/user_guide/platform_vyos.rst:27 -msgid "via a bastion (jump host)" -msgstr "bastion (jump ホスト) を使用" - -#: ../../rst/network/user_guide/platform_ce.rst:31 -#: ../../rst/network/user_guide/platform_cnos.rst:29 -#: ../../rst/network/user_guide/platform_dellos10.rst:29 -#: ../../rst/network/user_guide/platform_dellos6.rst:29 -#: ../../rst/network/user_guide/platform_dellos9.rst:29 -#: ../../rst/network/user_guide/platform_enos.rst:29 -#: ../../rst/network/user_guide/platform_eos.rst:29 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:29 -#: ../../rst/network/user_guide/platform_exos.rst:30 -#: ../../rst/network/user_guide/platform_frr.rst:29 -#: ../../rst/network/user_guide/platform_icx.rst:29 -#: ../../rst/network/user_guide/platform_ios.rst:29 -#: ../../rst/network/user_guide/platform_iosxr.rst:33 -#: ../../rst/network/user_guide/platform_ironware.rst:29 -#: ../../rst/network/user_guide/platform_junos.rst:32 -#: ../../rst/network/user_guide/platform_meraki.rst:25 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:31 -#: ../../rst/network/user_guide/platform_netvisor.rst:30 -#: ../../rst/network/user_guide/platform_nos.rst:30 -#: ../../rst/network/user_guide/platform_nxos.rst:29 -#: ../../rst/network/user_guide/platform_routeros.rst:30 -#: ../../rst/network/user_guide/platform_slxos.rst:30 -#: ../../rst/network/user_guide/platform_voss.rst:30 -#: ../../rst/network/user_guide/platform_vyos.rst:29 -msgid "Connection Settings" -msgstr "接続設定" - -#: ../../rst/network/user_guide/platform_ce.rst:32 -#: ../../rst/network/user_guide/platform_exos.rst:31 -#: ../../rst/network/user_guide/platform_iosxr.rst:34 -#: ../../rst/network/user_guide/platform_nxos.rst:30 -msgid "``ansible_connection:``" -msgstr "``ansible_connection:``" - -#: ../../rst/network/user_guide/platform_ce.rst:32 -#: ../../rst/network/user_guide/platform_exos.rst:31 -#: ../../rst/network/user_guide/platform_iosxr.rst:34 -#: ../../rst/network/user_guide/platform_nxos.rst:30 -msgid "``ansible.netcommon.network_cli``" -msgstr "``ansible.netcommon.network_cli``" - -#: ../../rst/network/user_guide/platform_ce.rst:32 -#: ../../rst/network/user_guide/platform_iosxr.rst:34 -msgid "``ansible.netcommon.netconf``" -msgstr "``ansible.netcommon.netconf``" - -#: ../../rst/network/user_guide/platform_ce.rst:34 -#: ../../rst/network/user_guide/platform_cnos.rst:31 -#: ../../rst/network/user_guide/platform_dellos10.rst:31 -#: ../../rst/network/user_guide/platform_dellos6.rst:31 -#: ../../rst/network/user_guide/platform_dellos9.rst:31 -#: ../../rst/network/user_guide/platform_enos.rst:31 -#: ../../rst/network/user_guide/platform_eos.rst:33 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:31 -#: ../../rst/network/user_guide/platform_exos.rst:33 -#: ../../rst/network/user_guide/platform_frr.rst:31 -#: ../../rst/network/user_guide/platform_icx.rst:31 -#: ../../rst/network/user_guide/platform_ios.rst:31 -#: ../../rst/network/user_guide/platform_iosxr.rst:36 -#: ../../rst/network/user_guide/platform_ironware.rst:31 -#: ../../rst/network/user_guide/platform_junos.rst:35 -#: ../../rst/network/user_guide/platform_netvisor.rst:32 -#: ../../rst/network/user_guide/platform_nos.rst:32 -#: ../../rst/network/user_guide/platform_nxos.rst:32 -#: ../../rst/network/user_guide/platform_routeros.rst:32 -#: ../../rst/network/user_guide/platform_slxos.rst:32 -#: ../../rst/network/user_guide/platform_voss.rst:32 -#: ../../rst/network/user_guide/platform_vyos.rst:31 -msgid "|enable_mode|" -msgstr "|enable_mode|" - -#: ../../rst/network/user_guide/platform_ce.rst:34 -msgid "not supported by ce OS" -msgstr "ce OS ではサポートなし" - -#: ../../rst/network/user_guide/platform_ce.rst:36 -#: ../../rst/network/user_guide/platform_cnos.rst:35 -#: ../../rst/network/user_guide/platform_dellos10.rst:35 -#: ../../rst/network/user_guide/platform_dellos6.rst:35 -#: ../../rst/network/user_guide/platform_dellos9.rst:35 -#: ../../rst/network/user_guide/platform_enos.rst:35 -#: ../../rst/network/user_guide/platform_eos.rst:39 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:33 -#: ../../rst/network/user_guide/platform_exos.rst:35 -#: ../../rst/network/user_guide/platform_frr.rst:33 -#: ../../rst/network/user_guide/platform_icx.rst:34 -#: ../../rst/network/user_guide/platform_ios.rst:34 -#: ../../rst/network/user_guide/platform_iosxr.rst:38 -#: ../../rst/network/user_guide/platform_ironware.rst:35 -#: ../../rst/network/user_guide/platform_junos.rst:37 -#: ../../rst/network/user_guide/platform_meraki.rst:27 -#: ../../rst/network/user_guide/platform_netvisor.rst:34 -#: ../../rst/network/user_guide/platform_nos.rst:34 -#: ../../rst/network/user_guide/platform_nxos.rst:36 -#: ../../rst/network/user_guide/platform_routeros.rst:34 -#: ../../rst/network/user_guide/platform_slxos.rst:34 -#: ../../rst/network/user_guide/platform_voss.rst:35 -#: ../../rst/network/user_guide/platform_vyos.rst:33 -msgid "Returned Data Format" -msgstr "返されるデータ形式" - -#: ../../rst/network/user_guide/platform_ce.rst:36 -#: ../../rst/network/user_guide/platform_iosxr.rst:38 -#: ../../rst/network/user_guide/platform_vyos.rst:33 -msgid "Refer to individual module documentation" -msgstr "各モジュールのドキュメンテーションを参照してください。" - -#: ../../rst/network/user_guide/platform_ce.rst:41 -msgid "The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.netconf`` or ``ansible_connection=ansible.netcommon.network_cli`` instead." -msgstr "``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.netconf`` または ``ansible_connection=ansible.netcommon.network_cli`` を使用してください。" - -#: ../../rst/network/user_guide/platform_ce.rst:44 -#: ../../rst/network/user_guide/platform_cnos.rst:43 -#: ../../rst/network/user_guide/platform_dellos10.rst:44 -#: ../../rst/network/user_guide/platform_dellos6.rst:43 -#: ../../rst/network/user_guide/platform_dellos9.rst:43 -#: ../../rst/network/user_guide/platform_enos.rst:45 -#: ../../rst/network/user_guide/platform_eos.rst:48 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:41 -#: ../../rst/network/user_guide/platform_exos.rst:43 -#: ../../rst/network/user_guide/platform_frr.rst:40 -#: ../../rst/network/user_guide/platform_icx.rst:41 -#: ../../rst/network/user_guide/platform_ios.rst:43 -#: ../../rst/network/user_guide/platform_iosxr.rst:47 -#: ../../rst/network/user_guide/platform_ironware.rst:44 -#: ../../rst/network/user_guide/platform_junos.rst:48 -#: ../../rst/network/user_guide/platform_netvisor.rst:42 -#: ../../rst/network/user_guide/platform_nos.rst:42 -#: ../../rst/network/user_guide/platform_nxos.rst:45 -#: ../../rst/network/user_guide/platform_routeros.rst:43 -#: ../../rst/network/user_guide/platform_slxos.rst:43 -#: ../../rst/network/user_guide/platform_voss.rst:44 -#: ../../rst/network/user_guide/platform_vyos.rst:42 -msgid "Using CLI in Ansible" -msgstr "Ansible での CLI の使用" - -#: ../../rst/network/user_guide/platform_ce.rst:47 -msgid "Example CLI inventory ``[ce:vars]``" -msgstr "CLI インベントリーの例 ``[ce:vars]``" - -#: ../../rst/network/user_guide/platform_ce.rst:59 -#: ../../rst/network/user_guide/platform_cnos.rst:60 -#: ../../rst/network/user_guide/platform_dellos10.rst:61 -#: ../../rst/network/user_guide/platform_dellos6.rst:60 -#: ../../rst/network/user_guide/platform_dellos9.rst:60 -#: ../../rst/network/user_guide/platform_enos.rst:62 -#: ../../rst/network/user_guide/platform_eos.rst:65 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:55 -#: ../../rst/network/user_guide/platform_exos.rst:57 -#: ../../rst/network/user_guide/platform_frr.rst:54 -#: ../../rst/network/user_guide/platform_icx.rst:58 -#: ../../rst/network/user_guide/platform_ios.rst:60 -#: ../../rst/network/user_guide/platform_iosxr.rst:62 -#: ../../rst/network/user_guide/platform_ironware.rst:61 -#: ../../rst/network/user_guide/platform_junos.rst:63 -#: ../../rst/network/user_guide/platform_netvisor.rst:56 -#: ../../rst/network/user_guide/platform_nos.rst:56 -#: ../../rst/network/user_guide/platform_nxos.rst:62 -#: ../../rst/network/user_guide/platform_routeros.rst:60 -#: ../../rst/network/user_guide/platform_slxos.rst:57 -#: ../../rst/network/user_guide/platform_voss.rst:60 -#: ../../rst/network/user_guide/platform_vyos.rst:56 -msgid "If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration." -msgstr "SSH キー (ssh-agent を含む) を使用している場合は、``ansible_password`` 設定を削除できます。" - -#: ../../rst/network/user_guide/platform_ce.rst:60 -#: ../../rst/network/user_guide/platform_cnos.rst:61 -#: ../../rst/network/user_guide/platform_dellos10.rst:62 -#: ../../rst/network/user_guide/platform_dellos6.rst:61 -#: ../../rst/network/user_guide/platform_dellos9.rst:61 -#: ../../rst/network/user_guide/platform_enos.rst:63 -#: ../../rst/network/user_guide/platform_eos.rst:66 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:56 -#: ../../rst/network/user_guide/platform_exos.rst:58 -#: ../../rst/network/user_guide/platform_frr.rst:55 -#: ../../rst/network/user_guide/platform_icx.rst:59 -#: ../../rst/network/user_guide/platform_ios.rst:61 -#: ../../rst/network/user_guide/platform_iosxr.rst:63 -#: ../../rst/network/user_guide/platform_ironware.rst:62 -#: ../../rst/network/user_guide/platform_junos.rst:64 -#: ../../rst/network/user_guide/platform_netvisor.rst:57 -#: ../../rst/network/user_guide/platform_nos.rst:57 -#: ../../rst/network/user_guide/platform_nxos.rst:63 -#: ../../rst/network/user_guide/platform_routeros.rst:61 -#: ../../rst/network/user_guide/platform_slxos.rst:58 -#: ../../rst/network/user_guide/platform_voss.rst:61 -#: ../../rst/network/user_guide/platform_vyos.rst:57 -msgid "If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration." -msgstr "(bastion/ジャンプホストを経由せず) ホストに直接アクセスしている場合は、``ansible_ssh_common_args`` 設定を削除できます。" - -#: ../../rst/network/user_guide/platform_ce.rst:61 -#: ../../rst/network/user_guide/platform_cnos.rst:62 -#: ../../rst/network/user_guide/platform_dellos10.rst:63 -#: ../../rst/network/user_guide/platform_dellos6.rst:62 -#: ../../rst/network/user_guide/platform_dellos9.rst:62 -#: ../../rst/network/user_guide/platform_enos.rst:64 -#: ../../rst/network/user_guide/platform_eos.rst:67 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:57 -#: ../../rst/network/user_guide/platform_exos.rst:59 -#: ../../rst/network/user_guide/platform_frr.rst:56 -#: ../../rst/network/user_guide/platform_icx.rst:60 -#: ../../rst/network/user_guide/platform_ios.rst:62 -#: ../../rst/network/user_guide/platform_iosxr.rst:64 -#: ../../rst/network/user_guide/platform_ironware.rst:63 -#: ../../rst/network/user_guide/platform_junos.rst:65 -#: ../../rst/network/user_guide/platform_netvisor.rst:58 -#: ../../rst/network/user_guide/platform_nos.rst:58 -#: ../../rst/network/user_guide/platform_nxos.rst:64 -#: ../../rst/network/user_guide/platform_routeros.rst:62 -#: ../../rst/network/user_guide/platform_slxos.rst:59 -#: ../../rst/network/user_guide/platform_voss.rst:62 -#: ../../rst/network/user_guide/platform_vyos.rst:58 -msgid "If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords via environment variables." -msgstr "bastion/ジャンプホストを介してホストにアクセスする場合は、``ProxyCommand`` ディレクティブに SSH パスワードを含めることができません。シークレットが漏洩するのを防ぐために (例: ``ps`` 出力)、SSH は環境変数によるパスワードの提供をサポートしません。" - -#: ../../rst/network/user_guide/platform_ce.rst:64 -#: ../../rst/network/user_guide/platform_cnos.rst:65 -#: ../../rst/network/user_guide/platform_dellos10.rst:66 -#: ../../rst/network/user_guide/platform_dellos6.rst:65 -#: ../../rst/network/user_guide/platform_dellos9.rst:65 -#: ../../rst/network/user_guide/platform_enos.rst:67 -#: ../../rst/network/user_guide/platform_eos.rst:70 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:60 -#: ../../rst/network/user_guide/platform_exos.rst:62 -#: ../../rst/network/user_guide/platform_frr.rst:59 -#: ../../rst/network/user_guide/platform_icx.rst:63 -#: ../../rst/network/user_guide/platform_ios.rst:65 -#: ../../rst/network/user_guide/platform_iosxr.rst:67 -#: ../../rst/network/user_guide/platform_ironware.rst:66 -#: ../../rst/network/user_guide/platform_junos.rst:68 -#: ../../rst/network/user_guide/platform_netvisor.rst:61 -#: ../../rst/network/user_guide/platform_nos.rst:61 -#: ../../rst/network/user_guide/platform_nxos.rst:67 -#: ../../rst/network/user_guide/platform_routeros.rst:66 -#: ../../rst/network/user_guide/platform_slxos.rst:62 -#: ../../rst/network/user_guide/platform_voss.rst:65 -#: ../../rst/network/user_guide/platform_vyos.rst:61 -msgid "Example CLI task" -msgstr "CLI タスクの例" - -#: ../../rst/network/user_guide/platform_ce.rst:75 -#: ../../rst/network/user_guide/platform_iosxr.rst:78 -#: ../../rst/network/user_guide/platform_junos.rst:79 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:38 -msgid "Using NETCONF in Ansible" -msgstr "Ansible での NETCONF の使用" - -#: ../../rst/network/user_guide/platform_ce.rst:78 -#: ../../rst/network/user_guide/platform_iosxr.rst:81 -#: ../../rst/network/user_guide/platform_junos.rst:82 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:41 -msgid "Enabling NETCONF" -msgstr "NETCONF の有効化" - -#: ../../rst/network/user_guide/platform_ce.rst:80 -#: ../../rst/network/user_guide/platform_iosxr.rst:83 -#: ../../rst/network/user_guide/platform_junos.rst:84 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:43 -msgid "Before you can use NETCONF to connect to a switch, you must:" -msgstr "NETCONF を使用してスイッチに接続する前に、以下を行う必要があります。" - -#: ../../rst/network/user_guide/platform_ce.rst:82 -#: ../../rst/network/user_guide/platform_iosxr.rst:85 -#: ../../rst/network/user_guide/platform_junos.rst:86 -msgid "install the ``ncclient`` python package on your control node(s) with ``pip install ncclient``" -msgstr "``pip install ncclient`` を使用して、``ncclient`` python パッケージをコントロールノードにインストールします。" - -#: ../../rst/network/user_guide/platform_ce.rst:83 -msgid "enable NETCONF on the CloudEngine OS device(s)" -msgstr "CloudEngine OS デバイスでの NETCONF の有効化" - -#: ../../rst/network/user_guide/platform_ce.rst:85 -msgid "To enable NETCONF on a new switch using Ansible, use the ``community.network.ce_config`` module with the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this:" -msgstr "Ansibleを使用する新しいスイッチで NETCONF を有効にするには、CLI 接続でモジュールを ``community.network.ce_config`` 使用します。上記の CLI の例のようにプラットフォームレベルの変数を設定し、次のような Playbook タスクを実行します。" - -#: ../../rst/network/user_guide/platform_ce.rst:96 -#: ../../rst/network/user_guide/platform_iosxr.rst:97 -#: ../../rst/network/user_guide/platform_junos.rst:98 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:58 -msgid "Once NETCONF is enabled, change your variables to use the NETCONF connection." -msgstr "NETCONF を有効にしたら、変数を変更して NETCONF 接続を使用します。" - -#: ../../rst/network/user_guide/platform_ce.rst:99 -msgid "Example NETCONF inventory ``[ce:vars]``" -msgstr "NETCONF インベントリーの例 ``[ce:vars]``" - -#: ../../rst/network/user_guide/platform_ce.rst:112 -#: ../../rst/network/user_guide/platform_iosxr.rst:113 -#: ../../rst/network/user_guide/platform_junos.rst:114 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:73 -msgid "Example NETCONF task" -msgstr "NETCONF タスクの例" - -#: ../../rst/network/user_guide/platform_ce.rst:124 -msgid "Notes" -msgstr "備考" - -#: ../../rst/network/user_guide/platform_ce.rst:127 -msgid "Modules that work with ``ansible.netcommon.network_cli``" -msgstr "``ansible.netcommon.network_cli`` と連携するモジュール" - -#: ../../rst/network/user_guide/platform_ce.rst:157 -msgid "Modules that work with ``ansible.netcommon.netconf``" -msgstr "``ansible.netcommon.netconf`` と連携するモジュール" - -#: ../../rst/network/user_guide/shared_snippets/SSH_warning.txt:2 -msgid "Never store passwords in plain text. We recommend using SSH keys to authenticate SSH connections. Ansible supports ssh-agent to manage your SSH keys. If you must use passwords to authenticate SSH connections, we recommend encrypting them with :ref:`Ansible Vault `." -msgstr "パスワードをプレーンテキストで保存しないでください。SSH キーを使用して SSH 接続を認証することが推奨されます。Ansible は SSH キーを管理するための ssh-agent をサポートしています。SSH 接続の認証にパスワードを使用する必要がある場合は、:ref:`Ansible Vault ` で暗号化することが推奨されます。" - -#: ../../rst/network/user_guide/platform_ce.rst:213 -#: ../../rst/network/user_guide/platform_cnos.rst:78 -#: ../../rst/network/user_guide/platform_dellos10.rst:80 -#: ../../rst/network/user_guide/platform_dellos6.rst:79 -#: ../../rst/network/user_guide/platform_dellos9.rst:79 -#: ../../rst/network/user_guide/platform_enos.rst:80 -#: ../../rst/network/user_guide/platform_eos.rst:140 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:73 -#: ../../rst/network/user_guide/platform_exos.rst:108 -#: ../../rst/network/user_guide/platform_frr.rst:73 -#: ../../rst/network/user_guide/platform_icx.rst:77 -#: ../../rst/network/user_guide/platform_ios.rst:79 -#: ../../rst/network/user_guide/platform_iosxr.rst:130 -#: ../../rst/network/user_guide/platform_ironware.rst:80 -#: ../../rst/network/user_guide/platform_junos.rst:129 -#: ../../rst/network/user_guide/platform_meraki.rst:44 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:133 -#: ../../rst/network/user_guide/platform_netvisor.rst:78 -#: ../../rst/network/user_guide/platform_nos.rst:76 -#: ../../rst/network/user_guide/platform_nxos.rst:166 -#: ../../rst/network/user_guide/platform_routeros.rst:80 -#: ../../rst/network/user_guide/platform_slxos.rst:77 -#: ../../rst/network/user_guide/platform_voss.rst:78 -#: ../../rst/network/user_guide/platform_vyos.rst:74 -msgid ":ref:`timeout_options`" -msgstr ":ref:`timeout_options`" - -#: ../../rst/network/user_guide/platform_cnos.rst:5 -msgid "CNOS Platform Options" -msgstr "CNOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_cnos.rst:7 -msgid "CNOS is part of the `community.network `_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on CNOS in Ansible." -msgstr "CNOS は、`community.network `_ コレクションの一部で、Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の CNOS で Enable Mode を有効にする方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_cnos.rst:29 -#: ../../rst/network/user_guide/platform_dellos10.rst:29 -#: ../../rst/network/user_guide/platform_dellos6.rst:29 -#: ../../rst/network/user_guide/platform_dellos9.rst:29 -#: ../../rst/network/user_guide/platform_enos.rst:29 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:29 -#: ../../rst/network/user_guide/platform_frr.rst:29 -#: ../../rst/network/user_guide/platform_icx.rst:29 -#: ../../rst/network/user_guide/platform_ios.rst:29 -#: ../../rst/network/user_guide/platform_ironware.rst:29 -#: ../../rst/network/user_guide/platform_netvisor.rst:30 -#: ../../rst/network/user_guide/platform_slxos.rst:30 -#: ../../rst/network/user_guide/platform_voss.rst:30 -#: ../../rst/network/user_guide/platform_vyos.rst:29 -msgid "``ansible_connection: ansible.netcommon.network_cli``" -msgstr "``ansible_connection: ansible.netcommon.network_cli``" - -#: ../../rst/network/user_guide/platform_cnos.rst:31 -#: ../../rst/network/user_guide/platform_dellos10.rst:31 -#: ../../rst/network/user_guide/platform_dellos6.rst:31 -#: ../../rst/network/user_guide/platform_dellos9.rst:31 -#: ../../rst/network/user_guide/platform_enos.rst:31 -#: ../../rst/network/user_guide/platform_icx.rst:31 -#: ../../rst/network/user_guide/platform_ios.rst:31 -#: ../../rst/network/user_guide/platform_ironware.rst:31 -#: ../../rst/network/user_guide/platform_nxos.rst:32 -msgid "supported: use ``ansible_become: yes`` with ``ansible_become_method: enable`` and ``ansible_become_password:``" -msgstr "サポート対象: ``ansible_become: yes`` を、``ansible_become_method: enable`` および ``ansible_become_password:`` と併用します。" - -#: ../../rst/network/user_guide/platform_cnos.rst:35 -#: ../../rst/network/user_guide/platform_dellos10.rst:35 -#: ../../rst/network/user_guide/platform_dellos6.rst:35 -#: ../../rst/network/user_guide/platform_dellos9.rst:35 -#: ../../rst/network/user_guide/platform_enos.rst:35 -#: ../../rst/network/user_guide/platform_eos.rst:39 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:33 -#: ../../rst/network/user_guide/platform_exos.rst:35 -#: ../../rst/network/user_guide/platform_frr.rst:33 -#: ../../rst/network/user_guide/platform_icx.rst:34 -#: ../../rst/network/user_guide/platform_ios.rst:34 -#: ../../rst/network/user_guide/platform_ironware.rst:35 -#: ../../rst/network/user_guide/platform_junos.rst:37 -#: ../../rst/network/user_guide/platform_netvisor.rst:34 -#: ../../rst/network/user_guide/platform_nos.rst:34 -#: ../../rst/network/user_guide/platform_nxos.rst:36 -#: ../../rst/network/user_guide/platform_routeros.rst:34 -#: ../../rst/network/user_guide/platform_slxos.rst:34 -#: ../../rst/network/user_guide/platform_voss.rst:35 -msgid "``stdout[0].``" -msgstr "``stdout[0].``" - -#: ../../rst/network/user_guide/platform_cnos.rst:40 -#: ../../rst/network/user_guide/platform_dellos10.rst:40 -#: ../../rst/network/user_guide/platform_dellos6.rst:40 -#: ../../rst/network/user_guide/platform_dellos9.rst:40 -#: ../../rst/network/user_guide/platform_enos.rst:42 -#: ../../rst/network/user_guide/platform_ios.rst:40 -#: ../../rst/network/user_guide/platform_ironware.rst:41 -#: ../../rst/network/user_guide/platform_vyos.rst:39 -msgid "The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead." -msgstr "``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.network_cli`` を使用してください。" - -#: ../../rst/network/user_guide/platform_cnos.rst:46 -msgid "Example CLI ``group_vars/cnos.yml``" -msgstr "CLI の例 ``group_vars/cnos.yml``" - -#: ../../rst/network/user_guide/platform_dellos10.rst:5 -msgid "Dell OS10 Platform Options" -msgstr "Dell OS10 プラットフォームオプション" - -#: ../../rst/network/user_guide/platform_dellos10.rst:7 -msgid "The `dellemc.os10 `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS10 in Ansible." -msgstr "`dellemc.os10 `_ コレクションは Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の OS10 で Enable Mode を使用する方法に関する詳細が記載されています。" - -#: ../../rst/network/user_guide/platform_dellos10.rst:47 -msgid "Example CLI ``group_vars/dellos10.yml``" -msgstr "CLI の例 ``group_vars/dellos10.yml``" - -#: ../../rst/network/user_guide/platform_dellos6.rst:5 -msgid "Dell OS6 Platform Options" -msgstr "Dell OS6 プラットフォームオプション" - -#: ../../rst/network/user_guide/platform_dellos6.rst:7 -msgid "The `dellemc.os6 `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS6 in Ansible." -msgstr "`dellemc.os6 `_ コレクションは Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の OS6 で Enable Mode の使用方法に関する詳細が記載されています。" - -#: ../../rst/network/user_guide/platform_dellos6.rst:46 -msgid "Example CLI ``group_vars/dellos6.yml``" -msgstr "CLI の例 ``group_vars/dellos6.yml``" - -#: ../../rst/network/user_guide/platform_dellos9.rst:5 -msgid "Dell OS9 Platform Options" -msgstr "Dell OS9 プラットフォームオプション" - -#: ../../rst/network/user_guide/platform_dellos9.rst:7 -msgid "The `dellemc.os9 `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS9 in Ansible." -msgstr "`dellemc.os9 `_ コレクションは Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の OS9 で Enable Mode の使用方法に関する詳細が記載されています。" - -#: ../../rst/network/user_guide/platform_dellos9.rst:46 -msgid "Example CLI ``group_vars/dellos9.yml``" -msgstr "CLI の例 ``group_vars/dellos9.yml``" - -#: ../../rst/network/user_guide/platform_enos.rst:5 -msgid "ENOS Platform Options" -msgstr "ENOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_enos.rst:7 -msgid "ENOS is part of the `community.network `_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on ENOS in Ansible." -msgstr "ENOS は、`community.network `_ コレクションの一部で、Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の ENOS で Enable Mode を有効にする方法を説明します。" - -#: ../../rst/network/user_guide/platform_enos.rst:48 -msgid "Example CLI ``group_vars/enos.yml``" -msgstr "CLI の例 ``group_vars/enos.yml``" - -#: ../../rst/network/user_guide/platform_eos.rst:5 -msgid "EOS Platform Options" -msgstr "EOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_eos.rst:7 -msgid "The `Arista EOS `_ collection supports multiple connections. This page offers details on how each connection works in Ansible and how to use it." -msgstr "`Arista EOS `_ コレクションは複数の接続をサポートします。このページでは、各接続がどのように Ansible でどのように機能するかと、その使用方法を説明します。" - -#: ../../rst/network/user_guide/platform_eos.rst:19 -msgid "eAPI" -msgstr "eAPI" - -#: ../../rst/network/user_guide/platform_eos.rst:21 -#: ../../rst/network/user_guide/platform_exos.rst:22 -#: ../../rst/network/user_guide/platform_meraki.rst:21 -#: ../../rst/network/user_guide/platform_nxos.rst:21 -msgid "HTTP(S)" -msgstr "HTTP(S)" - -#: ../../rst/network/user_guide/platform_eos.rst:23 -#: ../../rst/network/user_guide/platform_exos.rst:24 -#: ../../rst/network/user_guide/platform_nxos.rst:23 -msgid "uses HTTPS certificates if present" -msgstr "HTTPS 証明書が存在する場合は使用します。" - -#: ../../rst/network/user_guide/platform_eos.rst:27 -#: ../../rst/network/user_guide/platform_exos.rst:28 -#: ../../rst/network/user_guide/platform_nxos.rst:27 -msgid "via a web proxy" -msgstr "Web プロキシー経由" - -#: ../../rst/network/user_guide/platform_eos.rst:29 -msgid "``ansible_connection:`` ``ansible.netcommon.network_cli``" -msgstr "``ansible_connection:`` ``ansible.netcommon.network_cli``" - -#: ../../rst/network/user_guide/platform_eos.rst:29 -msgid "``ansible_connection:`` ``ansible.netcommon.httpapi``" -msgstr "``ansible_connection:`` ``ansible.netcommon.httpapi``" - -#: ../../rst/network/user_guide/platform_eos.rst:33 -msgid "supported: |br|" -msgstr "サポート対象: |br|" - -#: ../../rst/network/user_guide/platform_eos.rst:35 -msgid "use ``ansible_become: yes`` with ``ansible_become_method: enable``" -msgstr "``ansible_become: yes`` を ``ansible_become_method: enable`` と併用します。" - -#: ../../rst/network/user_guide/platform_eos.rst:35 -msgid "``httpapi`` uses ``ansible_become: yes`` with ``ansible_become_method: enable``" -msgstr "``httpapi`` は、``ansible_become: yes`` を ``ansible_become_method: enable`` と併用します。" - -#: ../../rst/network/user_guide/platform_eos.rst:39 -#: ../../rst/network/user_guide/platform_exos.rst:35 -#: ../../rst/network/user_guide/platform_nxos.rst:36 -msgid "``stdout[0].messages[0].``" -msgstr "``stdout[0].messages[0].``" - -#: ../../rst/network/user_guide/platform_eos.rst:45 -#: ../../rst/network/user_guide/platform_nxos.rst:42 -msgid "The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.httpapi`` instead." -msgstr "``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.network_cli`` または ``ansible_connection: ansible.netcommon.httpapi`` を使用してください。" - -#: ../../rst/network/user_guide/platform_eos.rst:51 -msgid "Example CLI ``group_vars/eos.yml``" -msgstr "CLI の例 ``group_vars/eos.yml``" - -#: ../../rst/network/user_guide/platform_eos.rst:83 -msgid "Using eAPI in Ansible" -msgstr "Ansible での eAPI の使用" - -#: ../../rst/network/user_guide/platform_eos.rst:86 -msgid "Enabling eAPI" -msgstr "EAPI の有効化" - -#: ../../rst/network/user_guide/platform_eos.rst:88 -msgid "Before you can use eAPI to connect to a switch, you must enable eAPI. To enable eAPI on a new switch with Ansible, use the ``arista.eos.eos_eapi`` module through the CLI connection. Set up ``group_vars/eos.yml`` just like in the CLI example above, then run a playbook task like this:" -msgstr "eAPI を使用してスイッチに接続する前に、eAPI を有効にする必要があります。Ansible を使用する新しいスイッチで eAPI を有効にするには、CLI 接続を介して ``arista.eos.eos_eapi`` モジュールを使用します。上記の CLI の例のように ``group_vars/eos.yml`` を設定し、次のように Playbook タスクを実行します。" - -#: ../../rst/network/user_guide/platform_eos.rst:100 -msgid "You can find more options for enabling HTTP/HTTPS connections in the :ref:`arista.eos.eos_eapi ` module documentation." -msgstr "HTTP/HTTPS 接続を有効にするオプションの詳細は、:ref:`arista.eos.eos_eapi ` モジュールのドキュメントを参照してください。" - -#: ../../rst/network/user_guide/platform_eos.rst:102 -msgid "Once eAPI is enabled, change your ``group_vars/eos.yml`` to use the eAPI connection." -msgstr "eAPI を有効にしたら、``group_vars/eos.yml`` を変更して eAPI 接続を使用します。" - -#: ../../rst/network/user_guide/platform_eos.rst:105 -msgid "Example eAPI ``group_vars/eos.yml``" -msgstr "eAPI の例 ``group_vars/eos.yml``" - -#: ../../rst/network/user_guide/platform_eos.rst:118 -#: ../../rst/network/user_guide/platform_exos.rst:88 -#: ../../rst/network/user_guide/platform_nxos.rst:111 -msgid "If you are accessing your host directly (not through a web proxy) you can remove the ``proxy_env`` configuration." -msgstr "(Web プロキシーを経由せず) ホストに直接アクセスしている場合は、``proxy_env`` 設定を削除できます。" - -#: ../../rst/network/user_guide/platform_eos.rst:119 -#: ../../rst/network/user_guide/platform_exos.rst:89 -#: ../../rst/network/user_guide/platform_nxos.rst:112 -msgid "If you are accessing your host through a web proxy using ``https``, change ``http_proxy`` to ``https_proxy``." -msgstr "``https`` を使用して Web プロキシー経由でホストにアクセスする場合は、``http_proxy`` を ``https_proxy`` に変更します。" - -#: ../../rst/network/user_guide/platform_eos.rst:123 -msgid "Example eAPI task" -msgstr "eAPI タスクの例" - -#: ../../rst/network/user_guide/platform_eos.rst:134 -msgid "In this example the ``proxy_env`` variable defined in ``group_vars`` gets passed to the ``environment`` option of the module in the task." -msgstr "この例では、``group_vars`` で定義された ``proxy_env`` 変数が、タスクで使用されるモジュールの ``environment`` オプションに渡されます。" - -#: ../../rst/network/user_guide/platform_eric_eccli.rst:5 -msgid "ERIC_ECCLI Platform Options" -msgstr "ERIC_ECCLI プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_eric_eccli.rst:7 -msgid "Extreme ERIC_ECCLI is part of the `community.network `_ collection and only supports CLI connections today. This page offers details on how to use ``ansible.netcommon.network_cli`` on ERIC_ECCLI in Ansible." -msgstr "Extreme ERIC_ECCLI は `community.network `_ コレクションの一部で、現在は CLI 接続のみに対応しています。このページでは、Ansible の ERIC_ECCLI で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_eric_eccli.rst:31 -msgid "not supported by ERIC_ECCLI" -msgstr "ERIC_ECCLI ではサポートされません。" - -#: ../../rst/network/user_guide/platform_eric_eccli.rst:38 -msgid "ERIC_ECCLI does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "ERIC_ECCLI は、``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_eric_eccli.rst:44 -msgid "Example CLI ``group_vars/eric_eccli.yml``" -msgstr "CLI の例 ``group_vars/eric_eccli.yml``" - -#: ../../rst/network/user_guide/platform_exos.rst:5 -msgid "EXOS Platform Options" -msgstr "EXOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_exos.rst:7 -msgid "Extreme EXOS is part of the `community.network `_ collection and supports multiple connections. This page offers details on how each connection works in Ansible and how to use it." -msgstr "Extreme EXOS は `community.network `_ コレクションの一部で、複数の接続をサポートします。このページでは、Ansible での各接続がどのように機能し、どのように使用されるかを詳細に説明します。" - -#: ../../rst/network/user_guide/platform_exos.rst:20 -msgid "EXOS-API" -msgstr "EXOS-API" - -#: ../../rst/network/user_guide/platform_exos.rst:31 -#: ../../rst/network/user_guide/platform_nxos.rst:30 -msgid "``ansible.netcommon.httpapi``" -msgstr "``ansible.netcommon.httpapi``" - -#: ../../rst/network/user_guide/platform_exos.rst:33 -msgid "not supported by EXOS" -msgstr "EXOS ではサポートされません" - -#: ../../rst/network/user_guide/platform_exos.rst:40 -msgid "EXOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.httpapi``." -msgstr "EXOS は、``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` または ``ansible_connection: ansible.netcommon.httpapi`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_exos.rst:46 -msgid "Example CLI ``group_vars/exos.yml``" -msgstr "CLI の例 ``group_vars/exos.yml``" - -#: ../../rst/network/user_guide/platform_exos.rst:74 -msgid "Using EXOS-API in Ansible" -msgstr "Ansible での EXOS-API の使用" - -#: ../../rst/network/user_guide/platform_exos.rst:77 -msgid "Example EXOS-API ``group_vars/exos.yml``" -msgstr "EXOS-API の例 ``group_vars/exos.yml``" - -#: ../../rst/network/user_guide/platform_exos.rst:93 -msgid "Example EXOS-API task" -msgstr "EXOS-API タスクの例" - -#: ../../rst/network/user_guide/platform_exos.rst:102 -#: ../../rst/network/user_guide/platform_nxos.rst:127 -msgid "In this example the ``proxy_env`` variable defined in ``group_vars`` gets passed to the ``environment`` option of the module used in the task." -msgstr "この例では、``proxy_env`` で定義された ``group_vars`` 変数は、タスクで使用されるモジュールの ``environment`` オプションに渡されます。" - -#: ../../rst/network/user_guide/platform_frr.rst:5 -msgid "FRR Platform Options" -msgstr "FRR プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_frr.rst:7 -msgid "The `FRR `_ collection supports the ``ansible.netcommon.network_cli`` connection. This section provides details on how to use this connection for Free Range Routing (FRR)." -msgstr "`FRR `_ コレクションは、``ansible.netcommon.network_cli`` 接続をサポートします。本セクションでは、この接続を Free Range Routing (FRR) に使用する方法を説明します。" - -#: ../../rst/network/user_guide/platform_frr.rst:31 -#: ../../rst/network/user_guide/platform_iosxr.rst:36 -#: ../../rst/network/user_guide/platform_vyos.rst:31 -msgid "not supported" -msgstr "サポート対象外" - -#: ../../rst/network/user_guide/platform_frr.rst:43 -msgid "Example CLI ``group_vars/frr.yml``" -msgstr "CLI の例 ``group_vars/frr.yml``" - -#: ../../rst/network/user_guide/platform_frr.rst:53 -msgid "The ``ansible_user`` should be a part of the ``frrvty`` group and should have the default shell set to ``/bin/vtysh``." -msgstr "``ansible_user`` は ``frrvty`` グループに含まれるはずです。デフォルトのシェルは ``/bin/vtysh`` に設定する必要があります。" - -#: ../../rst/network/user_guide/platform_icx.rst:5 -msgid "ICX Platform Options" -msgstr "ICX プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_icx.rst:7 -msgid "ICX is part of the `community.network `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on ICX in Ansible." -msgstr "ICX は、`community.network `_ コレクションの一部で、Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の ICX で Enable Mode を有効にする方法を説明します。" - -#: ../../rst/network/user_guide/platform_icx.rst:44 -msgid "Example CLI ``group_vars/icx.yml``" -msgstr "CLI の例 ``group_vars/icx.yml``" - -#: ../../rst/network/user_guide/platform_index.rst:5 -#: ../../rst/network/user_guide/platform_index.rst:9 -msgid "Platform Options" -msgstr "プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_index.rst:7 -msgid "Some Ansible Network platforms support multiple connection types, privilege escalation (``enable`` mode), or other options. The pages in this section offer standardized guides to understanding available options on each network platform. We welcome contributions from community-maintained platforms to this section." -msgstr "一部の Ansible Network プラットフォームは、複数の接続タイプ、権限エスカレーション (``enable`` モード) 、またはその他のオプションをサポートしています。本セクションのページでは、各ネットワークプラットフォームで利用可能なオプションを理解する標準ガイドが紹介されています。コミュニティーが管理するプラットフォームから、このセクションへの貢献を歓迎いたします。" - -#: ../../rst/network/user_guide/platform_index.rst:41 -msgid "Settings by Platform" -msgstr "プラットフォーム別の設定" - -#: ../../rst/network/user_guide/platform_index.rst:58 -msgid "``ansible_connection:`` settings available" -msgstr "``ansible_connection:`` 設定が利用可能" - -#: ../../rst/network/user_guide/platform_index.rst:60 -msgid "Network OS" -msgstr "ネットワーク OS" - -#: ../../rst/network/user_guide/platform_index.rst:60 -msgid "``ansible_network_os:``" -msgstr "``ansible_network_os:``" - -#: ../../rst/network/user_guide/platform_index.rst:60 -msgid "network_cli" -msgstr "network_cli" - -#: ../../rst/network/user_guide/platform_index.rst:60 -msgid "netconf" -msgstr "netconf" - -#: ../../rst/network/user_guide/platform_index.rst:60 -msgid "httpapi" -msgstr "httpapi" - -#: ../../rst/network/user_guide/platform_index.rst:62 -msgid "`Arista EOS`_ `[†]`_" -msgstr "`Arista EOS`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:62 -msgid "``arista.eos.eos``" -msgstr "``arista.eos.eos``" - -#: ../../rst/network/user_guide/platform_index.rst:62 -#: ../../rst/network/user_guide/platform_index.rst:63 -#: ../../rst/network/user_guide/platform_index.rst:64 -#: ../../rst/network/user_guide/platform_index.rst:65 -#: ../../rst/network/user_guide/platform_index.rst:66 -#: ../../rst/network/user_guide/platform_index.rst:67 -#: ../../rst/network/user_guide/platform_index.rst:68 -#: ../../rst/network/user_guide/platform_index.rst:69 -#: ../../rst/network/user_guide/platform_index.rst:70 -#: ../../rst/network/user_guide/platform_index.rst:71 -#: ../../rst/network/user_guide/platform_index.rst:72 -#: ../../rst/network/user_guide/platform_index.rst:73 -#: ../../rst/network/user_guide/platform_index.rst:74 -#: ../../rst/network/user_guide/platform_index.rst:75 -#: ../../rst/network/user_guide/platform_index.rst:76 -#: ../../rst/network/user_guide/platform_index.rst:77 -#: ../../rst/network/user_guide/platform_index.rst:78 -#: ../../rst/network/user_guide/platform_index.rst:79 -#: ../../rst/network/user_guide/platform_index.rst:80 -#: ../../rst/network/user_guide/platform_index.rst:81 -#: ../../rst/network/user_guide/platform_index.rst:82 -#: ../../rst/network/user_guide/platform_index.rst:83 -#: ../../rst/network/user_guide/platform_index.rst:84 -#: ../../rst/network/user_guide/platform_index.rst:85 -#: ../../rst/network/user_guide/platform_index.rst:86 -#: ../../rst/network/user_guide/platform_index.rst:87 -#: ../../rst/network/user_guide/platform_index.rst:88 -#: ../../rst/network/user_guide/platform_index.rst:89 -msgid "✓" -msgstr "✓" - -#: ../../rst/network/user_guide/platform_index.rst:63 -msgid "`Ciena SAOS6`_" -msgstr "`Ciena SAOS6`_" - -#: ../../rst/network/user_guide/platform_index.rst:63 -msgid "``ciena.saos6.saos6``" -msgstr "``ciena.saos6.saos6``" - -#: ../../rst/network/user_guide/platform_index.rst:64 -msgid "`Cisco ASA`_ `[†]`_" -msgstr "`Cisco ASA`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:64 -msgid "``cisco.asa.asa``" -msgstr "``cisco.asa.asa``" - -#: ../../rst/network/user_guide/platform_index.rst:65 -msgid "`Cisco IOS`_ `[†]`_" -msgstr "`Cisco IOS`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:65 -msgid "``cisco.ios.ios``" -msgstr "``cisco.ios.ios``" - -#: ../../rst/network/user_guide/platform_index.rst:66 -msgid "`Cisco IOS XR`_ `[†]`_" -msgstr "`Cisco IOS XR`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:66 -msgid "``cisco.iosxr.iosxr``" -msgstr "``cisco.iosxr.iosxr``" - -#: ../../rst/network/user_guide/platform_index.rst:67 -msgid "`Cisco NX-OS`_ `[†]`_" -msgstr "`Cisco NX-OS`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:67 -msgid "``cisco.nxos.nxos``" -msgstr "``cisco.nxos.nxos``" - -#: ../../rst/network/user_guide/platform_index.rst:68 -msgid "`Cloudengine OS`_" -msgstr "`Cloudengine OS`_" - -#: ../../rst/network/user_guide/platform_index.rst:68 -msgid "``community.network.ce``" -msgstr "``community.network.ce``" - -#: ../../rst/network/user_guide/platform_index.rst:69 -msgid "`Dell OS6`_" -msgstr "`Dell OS6`_" - -#: ../../rst/network/user_guide/platform_index.rst:69 -msgid "``dellemc.os6.os6``" -msgstr "``dellemc.os6.os6``" - -#: ../../rst/network/user_guide/platform_index.rst:70 -msgid "`Dell OS9`_" -msgstr "`Dell OS9`_" - -#: ../../rst/network/user_guide/platform_index.rst:70 -msgid "``dellemc.os9.os9``" -msgstr "``dellemc.os9.os9``" - -#: ../../rst/network/user_guide/platform_index.rst:71 -msgid "`Dell OS10`_" -msgstr "`Dell OS10`_" - -#: ../../rst/network/user_guide/platform_index.rst:71 -msgid "``dellemc.os10.os10``" -msgstr "``dellemc.os10.os10``" - -#: ../../rst/network/user_guide/platform_index.rst:72 -msgid "`Ericsson ECCLI`_" -msgstr "`Ericsson ECCLI`_" - -#: ../../rst/network/user_guide/platform_index.rst:72 -msgid "``community.network.eric_eccli``" -msgstr "``community.network.eric_eccli``" - -#: ../../rst/network/user_guide/platform_index.rst:73 -msgid "`Extreme EXOS`_" -msgstr "`Extreme EXOS`_" - -#: ../../rst/network/user_guide/platform_index.rst:73 -msgid "``community.network.exos``" -msgstr "``community.network.exos``" - -#: ../../rst/network/user_guide/platform_index.rst:74 -msgid "`Extreme IronWare`_" -msgstr "`Extreme IronWare`_" - -#: ../../rst/network/user_guide/platform_index.rst:74 -msgid "``community.network.ironware``" -msgstr "``community.network.ironware``" - -#: ../../rst/network/user_guide/platform_index.rst:75 -msgid "`Extreme NOS`_" -msgstr "`Extreme NOS`_" - -#: ../../rst/network/user_guide/platform_index.rst:75 -msgid "``community.network.nos``" -msgstr "``community.network.nos``" - -#: ../../rst/network/user_guide/platform_index.rst:76 -msgid "`Extreme SLX-OS`_" -msgstr "`Extreme SLX-OS`_" - -#: ../../rst/network/user_guide/platform_index.rst:76 -msgid "``community.network.slxos``" -msgstr "``community.network.slxos``" - -#: ../../rst/network/user_guide/platform_index.rst:77 -msgid "`Extreme VOSS`_" -msgstr "`Extreme VOSS`_" - -#: ../../rst/network/user_guide/platform_index.rst:77 -msgid "``community.network.voss``" -msgstr "``community.network.voss``" - -#: ../../rst/network/user_guide/platform_index.rst:78 -msgid "`F5 BIG-IP`_" -msgstr "`F5 BIG-IP`_" - -#: ../../rst/network/user_guide/platform_index.rst:79 -msgid "`F5 BIG-IQ`_" -msgstr "`F5 BIG-IQ`_" - -#: ../../rst/network/user_guide/platform_index.rst:80 -msgid "`Junos OS`_ `[†]`_" -msgstr "`Junos OS`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:80 -msgid "``junipernetworks.junos.junos``" -msgstr "``junipernetworks.junos.junos``" - -#: ../../rst/network/user_guide/platform_index.rst:81 -msgid "`Lenovo CNOS`_" -msgstr "`Lenovo CNOS`_" - -#: ../../rst/network/user_guide/platform_index.rst:81 -msgid "``community.network.cnos``" -msgstr "``community.network.cnos``" - -#: ../../rst/network/user_guide/platform_index.rst:82 -msgid "`Lenovo ENOS`_" -msgstr "`Lenovo ENOS`_" - -#: ../../rst/network/user_guide/platform_index.rst:82 -msgid "``community.network.enos``" -msgstr "``community.network.enos``" - -#: ../../rst/network/user_guide/platform_index.rst:83 -msgid "`Meraki`_" -msgstr "`Meraki`_" - -#: ../../rst/network/user_guide/platform_index.rst:84 -msgid "`MikroTik RouterOS`_" -msgstr "`MikroTik RouterOS`_" - -#: ../../rst/network/user_guide/platform_index.rst:84 -msgid "``community.network.routeros``" -msgstr "``community.network.routeros``" - -#: ../../rst/network/user_guide/platform_index.rst:85 -msgid "`Nokia SR OS`_" -msgstr "`Nokia SR OS`_" - -#: ../../rst/network/user_guide/platform_index.rst:86 -msgid "`Pluribus Netvisor`_" -msgstr "`Pluribus Netvisor`_" - -#: ../../rst/network/user_guide/platform_index.rst:86 -msgid "``community.network.netvisor``" -msgstr "``community.network.netvisor``" - -#: ../../rst/network/user_guide/platform_index.rst:87 -msgid "`Ruckus ICX`_" -msgstr "`Ruckus ICX`_" - -#: ../../rst/network/user_guide/platform_index.rst:87 -msgid "``community.network.icx``" -msgstr "``community.network.icx``" - -#: ../../rst/network/user_guide/platform_index.rst:88 -msgid "`VyOS`_ `[†]`_" -msgstr "`VyOS`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:88 -msgid "``vyos.vyos.vyos``" -msgstr "``vyos.vyos.vyos``" - -#: ../../rst/network/user_guide/platform_index.rst:89 -msgid "OS that supports Netconf `[†]`_" -msgstr "Netconf に対応する OS `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:89 -msgid "````" -msgstr "````" - -#: ../../rst/network/user_guide/platform_index.rst:121 -msgid "**[†]** Maintained by Ansible Network Team" -msgstr "**[†]** Ansible Network Team が管理" - -#: ../../rst/network/user_guide/platform_ios.rst:5 -msgid "IOS Platform Options" -msgstr "IOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_ios.rst:7 -msgid "The `Cisco IOS `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on IOS in Ansible." -msgstr "`Cisco IOS `_ コレクションは Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の IOS で Enable Mode を有効にする方法を説明します。" - -#: ../../rst/network/user_guide/platform_ios.rst:46 -msgid "Example CLI ``group_vars/ios.yml``" -msgstr "CLI の例 ``group_vars/ios.yml``" - -#: ../../rst/network/user_guide/platform_iosxr.rst:5 -msgid "IOS-XR Platform Options" -msgstr "IOS-XR プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_iosxr.rst:7 -msgid "The `Cisco IOS-XR collection `_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it." -msgstr "`Cisco IOS-XR collection `_ は複数の接続をサポートします。このページでは、Ansible での各接続がどのように機能するか、およびその使用方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_iosxr.rst:21 -msgid "only for modules ``iosxr_banner``, ``iosxr_interface``, ``iosxr_logging``, ``iosxr_system``, ``iosxr_user``" -msgstr "モジュールの ``iosxr_banner``、``iosxr_interface``、``iosxr_logging``、``iosxr_system``、``iosxr_user`` のみ" - -#: ../../rst/network/user_guide/platform_iosxr.rst:44 -#: ../../rst/network/user_guide/platform_junos.rst:45 -msgid "The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.netconf`` instead." -msgstr "``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.network_cli`` または ``ansible_connection: ansible.netcommon.netconf`` を使用してください。" - -#: ../../rst/network/user_guide/platform_iosxr.rst:50 -msgid "Example CLI inventory ``[iosxr:vars]``" -msgstr "CLI インベントリーの例 ``[iosxr:vars]``" - -#: ../../rst/network/user_guide/platform_iosxr.rst:86 -msgid "enable NETCONF on the Cisco IOS-XR device(s)" -msgstr "Cisco IOS-XR デバイスで NETCONF を有効にします。" - -#: ../../rst/network/user_guide/platform_iosxr.rst:88 -msgid "To enable NETCONF on a new switch via Ansible, use the ``cisco.iosxr.iosxr_netconf`` module through the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this:" -msgstr "Ansible を介して新しいスイッチで NETCONF を有効にするには、CLI 接続を介して ``cisco.iosxr.iosxr_netconf`` モジュールを使用します。上記の CLI の例のようにプラットフォームレベルの変数を設定し、次のような Playbook タスクを実行します。" - -#: ../../rst/network/user_guide/platform_iosxr.rst:100 -msgid "Example NETCONF inventory ``[iosxr:vars]``" -msgstr "NETCONF インベントリーの例 ``[iosxr:vars]``" - -#: ../../rst/network/user_guide/platform_ironware.rst:5 -msgid "IronWare Platform Options" -msgstr "IronWare プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_ironware.rst:7 -msgid "IronWare is part of the `community.network `_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on IronWare in Ansible." -msgstr "IronWare は、`community.network `_ コレクションの一部で、Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の IronWare で Enable Mode を有効にする方法を説明します。" - -#: ../../rst/network/user_guide/platform_ironware.rst:47 -msgid "Example CLI ``group_vars/mlx.yml``" -msgstr "CLI の例 ``group_vars/mlx.yml``" - -#: ../../rst/network/user_guide/platform_junos.rst:5 -msgid "Junos OS Platform Options" -msgstr "Junos OS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_junos.rst:7 -msgid "The `Juniper Junos OS `_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it." -msgstr "`Juniper Junos OS `_ は複数の接続をサポートします。このページでは、Ansible での各接続がどのように機能するか、およびその使用方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_junos.rst:21 -msgid "``junos_netconf`` & ``junos_command`` modules only" -msgstr "``junos_netconf`` モジュールおよび ``junos_command`` モジュールのみ" - -#: ../../rst/network/user_guide/platform_junos.rst:21 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:20 -msgid "all modules except ``junos_netconf``, which enables NETCONF" -msgstr "NETCONF を有効にする ``junos_netconf`` 以外のすべてのモジュール" - -#: ../../rst/network/user_guide/platform_junos.rst:32 -msgid "``ansible_connection: ``ansible.netcommon.network_cli``" -msgstr "``ansible_connection: ``ansible.netcommon.network_cli``" - -#: ../../rst/network/user_guide/platform_junos.rst:32 -msgid "``ansible_connection: ``ansible.netcommon.netconf``" -msgstr "``ansible_connection: ``ansible.netcommon.netconf``" - -#: ../../rst/network/user_guide/platform_junos.rst:35 -msgid "not supported by Junos OS" -msgstr "Junos OS ではサポートされません" - -#: ../../rst/network/user_guide/platform_junos.rst:37 -msgid "json: ``result[0]['software-information'][0]['host-name'][0]['data'] foo lo0``" -msgstr "json: ``result[0]['software-information'][0]['host-name'][0]['data'] foo lo0``" - -#: ../../rst/network/user_guide/platform_junos.rst:38 -msgid "text: ``result[1].interface-information[0].physical-interface[0].name[0].data foo lo0``" -msgstr "テキスト: ``result[1].interface-information[0].physical-interface[0].name[0].data foo lo0``" - -#: ../../rst/network/user_guide/platform_junos.rst:39 -msgid "xml: ``result[1].rpc-reply.interface-information[0].physical-interface[0].name[0].data foo lo0``" -msgstr "xml: ``result[1].rpc-reply.interface-information[0].physical-interface[0].name[0].data foo lo0``" - -#: ../../rst/network/user_guide/platform_junos.rst:51 -msgid "Example CLI inventory ``[junos:vars]``" -msgstr "CLI インベントリーの例 ``[junos:vars]``" - -#: ../../rst/network/user_guide/platform_junos.rst:87 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:46 -msgid "enable NETCONF on the Junos OS device(s)" -msgstr "Junos OS デバイスの netconf を有効にします。" - -#: ../../rst/network/user_guide/platform_junos.rst:89 -msgid "To enable NETCONF on a new switch via Ansible, use the ``junipernetworks.junos.junos_netconf`` module through the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this:" -msgstr "Ansible を介して新しいスイッチで NETCONF を有効にするには、CLI 接続を介して ``junipernetworks.junos.junos_netconf`` モジュールを使用します。上記の CLI の例のようにプラットフォームレベルの変数を設定し、次のように Playbook タスクを実行します。" - -#: ../../rst/network/user_guide/platform_junos.rst:101 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:61 -msgid "Example NETCONF inventory ``[junos:vars]``" -msgstr "NETCONF インベントリーの例 ``[junos:vars]``" - -#: ../../rst/network/user_guide/platform_meraki.rst:5 -msgid "Meraki Platform Options" -msgstr "Meraki プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_meraki.rst:7 -msgid "The `cisco.meraki `_ collection only supports the ``local`` connection type at this time." -msgstr "`cisco.meraki `_ コレクションは、現時点では ``local`` 接続タイプのみをサポートします。" - -#: ../../rst/network/user_guide/platform_meraki.rst:19 -msgid "Dashboard API" -msgstr "ダッシュボード API" - -#: ../../rst/network/user_guide/platform_meraki.rst:23 -msgid "uses API key from Dashboard" -msgstr "Dashboard からの API キーの使用" - -#: ../../rst/network/user_guide/platform_meraki.rst:25 -msgid "``ansible_connection: localhost``" -msgstr "``ansible_connection: localhost``" - -#: ../../rst/network/user_guide/platform_meraki.rst:27 -msgid "``data.``" -msgstr "``data.``" - -#: ../../rst/network/user_guide/platform_meraki.rst:32 -msgid "Example Meraki task" -msgstr "Meraki タスクの例" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:5 -msgid "Netconf enabled Platform Options" -msgstr "Netconf が有効なプラットフォームオプション" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:7 -msgid "This page offers details on how the netconf connection works in Ansible and how to use it." -msgstr "このページには、netconf 接続が Ansible でどのように機能するか、およびその詳細な使用方法が記載されています。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:31 -msgid "``ansible_connection: ansible.netcommon.netconf``" -msgstr "``ansible_connection: ansible.netcommon.netconf``" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:35 -msgid "The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.netconf`` instead." -msgstr "``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.netconf`` を使用してください。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:45 -msgid "install the ``ncclient`` Python package on your control node(s) with ``pip install ncclient``" -msgstr "``pip install ncclient`` を使用して、``ncclient`` Python パッケージをコントロールノードにインストールします。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:48 -msgid "To enable NETCONF on a new switch via Ansible, use the platform specific module via the CLI connection or set it manually. For example set up your platform-level variables just like in the CLI example above, then run a playbook task like this:" -msgstr "Ansible 経由で新しいスイッチの NETCONF を有効にするには、CLI 接続経由でプラットフォーム固有のモジュールを使用するか、手動で設定します。たとえば、上記の CLI の例のようにプラットフォームレベルの変数を設定し、次のような Playbook タスクを実行します。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:83 -msgid "Example NETCONF task with configurable variables" -msgstr "設定可能な変数を含む NETCONF タスクの例" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:94 -msgid "Note: For netconf connection plugin configurable variables see :ref:`ansible.netcommon.netconf `." -msgstr "注意: netconf 接続プラグインの設定可能な変数は、「:ref:`ansible.netcommon.netconf `」を参照してください。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:97 -msgid "Bastion/Jumphost configuration" -msgstr "Bastion/Jumphost の設定" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:98 -msgid "To use a jump host to connect to a NETCONF enabled device you must set the ``ANSIBLE_NETCONF_SSH_CONFIG`` environment variable." -msgstr "ジャンプホストを使用して NETCONF 対応のデバイスに接続するには、``ANSIBLE_NETCONF_SSH_CONFIG`` 環境変数を設定する必要があります。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:102 -msgid "``ANSIBLE_NETCONF_SSH_CONFIG`` can be set to either:" -msgstr "``ANSIBLE_NETCONF_SSH_CONFIG`` を、次のいずれかに設定できます。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:101 -msgid "1 or TRUE (to trigger the use of the default SSH config file ~/.ssh/config)" -msgstr "1 または TRUE (デフォルトの SSH 設定ファイル ~/.ssh/config の使用を開始するため)。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:102 -msgid "The absolute path to a custom SSH config file." -msgstr "カスタムの SSH 設定ファイルへの絶対パス。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:104 -msgid "The SSH config file should look something like:" -msgstr "SSH 設定ファイルは以下のようになります。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:112 -msgid "Authentication for the jump host must use key based authentication." -msgstr "ジャンプホストの認証は、鍵ベースの認証を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:114 -msgid "You can either specify the private key used in the SSH config file:" -msgstr "SSH 設定ファイルで使用する秘密鍵のいずれかを指定できます。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:120 -msgid "Or you can use an ssh-agent." -msgstr "または、ssh-agent を使用できます。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:123 -msgid "ansible_network_os auto-detection" -msgstr "ansible_network_os 自動検出" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:125 -msgid "If ``ansible_network_os`` is not specified for a host, then Ansible will attempt to automatically detect what ``network_os`` plugin to use." -msgstr "ホストに ``ansible_network_os`` が指定されていない場合、Ansible は、使用する ``network_os`` プラグインを自動的に検出しようとします。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:127 -msgid "``ansible_network_os`` auto-detection can also be triggered by using ``auto`` as the ``ansible_network_os``. (Note: Previously ``default`` was used instead of ``auto``)." -msgstr "``ansible_network_os`` 自動検出は、``auto`` を ``ansible_network_os`` として使用することで発生させることもできます (注意: 以前は ``default`` の代わりに ``auto``が使用されていました)。" - -#: ../../rst/network/user_guide/platform_netvisor.rst:5 -msgid "Pluribus NETVISOR Platform Options" -msgstr "Pluribus NETVISOR プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_netvisor.rst:7 -msgid "Pluribus NETVISOR Ansible is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. This page offers details on how to use ``ansible.netcommon.network_cli`` on NETVISOR in Ansible." -msgstr "Pluribus NETVISOR Ansible は `community.network `_ コレクションの一部で、現在は CLI 接続のみをサポートしています。将来的に ``httpapi`` モジュールが追加される可能性があります。このページでは、Ansible の NETVISOR で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_netvisor.rst:32 -msgid "not supported by NETVISOR" -msgstr "NETVISOR ではサポートされません" - -#: ../../rst/network/user_guide/platform_netvisor.rst:39 -msgid "Pluribus NETVISOR does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "Pluribus NETVISOR は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_netvisor.rst:45 -msgid "Example CLI ``group_vars/netvisor.yml``" -msgstr "CLI の例 ``group_vars/netvisor.yml``" - -#: ../../rst/network/user_guide/platform_nos.rst:5 -msgid "NOS Platform Options" -msgstr "NOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_nos.rst:7 -msgid "Extreme NOS is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. This page offers details on how to use ``ansible.netcommon.network_cli`` on NOS in Ansible." -msgstr "Extreme NOS は `community.network `_ コレクションの一部で、現在は CLI 接続のみをサポートしています。将来的に ``httpapi`` モジュールが追加される可能性があります。このページでは、Ansible の NOS で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_nos.rst:30 -msgid "``ansible_connection: community.netcommon.network_cli``" -msgstr "``ansible_connection: community.netcommon.network_cli``" - -#: ../../rst/network/user_guide/platform_nos.rst:32 -msgid "not supported by NOS" -msgstr "NOS ではサポートされません" - -#: ../../rst/network/user_guide/platform_nos.rst:39 -msgid "NOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "NOS は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_nos.rst:45 -msgid "Example CLI ``group_vars/nos.yml``" -msgstr "CLI の例 ``group_vars/nos.yml``" - -#: ../../rst/network/user_guide/platform_nxos.rst:5 -msgid "NXOS Platform Options" -msgstr "NXOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_nxos.rst:7 -msgid "The `Cisco NXOS `_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it." -msgstr "`Cisco NXOS `_ は複数の接続をサポートします。このページでは、Ansible で各接続がどのように機能するか、およびその使用方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_nxos.rst:19 -msgid "NX-API" -msgstr "NX-API" - -#: ../../rst/network/user_guide/platform_nxos.rst:32 -msgid "not supported by NX-API" -msgstr "NX-API ではサポートされません" - -#: ../../rst/network/user_guide/platform_nxos.rst:48 -msgid "Example CLI ``group_vars/nxos.yml``" -msgstr "CLI の例 ``group_vars/nxos.yml``" - -#: ../../rst/network/user_guide/platform_nxos.rst:80 -msgid "Using NX-API in Ansible" -msgstr "Ansible での NX-API の使用" - -#: ../../rst/network/user_guide/platform_nxos.rst:83 -msgid "Enabling NX-API" -msgstr "NX-API の有効化" - -#: ../../rst/network/user_guide/platform_nxos.rst:85 -msgid "Before you can use NX-API to connect to a switch, you must enable NX-API. To enable NX-API on a new switch via Ansible, use the ``nxos_nxapi`` module via the CLI connection. Set up group_vars/nxos.yml just like in the CLI example above, then run a playbook task like this:" -msgstr "NX-API を使用してスイッチに接続する前に、NX-API を有効にする必要があります。Ansible を介して新しいスイッチで NX-API を有効にするには、CLI 接続を介して ``nxos_nxapi`` モジュールを使用します。前述の CLI の例と同様に group_vars/nxos.yml を設定し、次のように Playbook タスクを実行します。" - -#: ../../rst/network/user_guide/platform_nxos.rst:95 -msgid "To find out more about the options for enabling HTTP/HTTPS and local http see the :ref:`nxos_nxapi ` module documentation." -msgstr "HTTP/HTTPS およびローカル http を有効にするオプションの詳細は、:ref:`nxos_nxapi ` モジュールのドキュメントを参照してください。" - -#: ../../rst/network/user_guide/platform_nxos.rst:97 -msgid "Once NX-API is enabled, change your ``group_vars/nxos.yml`` to use the NX-API connection." -msgstr "NX-API を有効にしたら、NX-API 接続を使用するように ``group_vars/nxos.yml`` を変更します。" - -#: ../../rst/network/user_guide/platform_nxos.rst:100 -msgid "Example NX-API ``group_vars/nxos.yml``" -msgstr "NX-API の例 ``group_vars/nxos.yml``" - -#: ../../rst/network/user_guide/platform_nxos.rst:116 -msgid "Example NX-API task" -msgstr "NX-API タスクの例" - -#: ../../rst/network/user_guide/platform_nxos.rst:132 -msgid "Cisco Nexus platform support matrix" -msgstr "Cisco Nexus プラットフォームのサポートマトリックス" - -#: ../../rst/network/user_guide/platform_nxos.rst:134 -msgid "The following platforms and software versions have been certified by Cisco to work with this version of Ansible." -msgstr "以下のプラットフォームおよびソフトウェアのバージョンは、Cisco が本バージョンの Ansible で機能することが認定されています。" - -#: ../../rst/network/user_guide/platform_nxos.rst:136 -msgid "Platform / Software Minimum Requirements" -msgstr "プラットフォーム/ソフトウェア最小要件" - -#: ../../rst/network/user_guide/platform_nxos.rst:140 -msgid "Supported Platforms" -msgstr "サポート対象のプラットフォーム" - -#: ../../rst/network/user_guide/platform_nxos.rst:140 -msgid "Minimum NX-OS Version" -msgstr "最小 NX-OS バージョン" - -#: ../../rst/network/user_guide/platform_nxos.rst:142 -msgid "Cisco Nexus N3k" -msgstr "Cisco Nexus N3k" - -#: ../../rst/network/user_guide/platform_nxos.rst:142 -#: ../../rst/network/user_guide/platform_nxos.rst:143 -msgid "7.0(3)I2(5) and later" -msgstr "7.0(3)I2(5) 以降" - -#: ../../rst/network/user_guide/platform_nxos.rst:143 -msgid "Cisco Nexus N9k" -msgstr "Cisco Nexus N9k" - -#: ../../rst/network/user_guide/platform_nxos.rst:144 -msgid "Cisco Nexus N5k" -msgstr "Cisco Nexus N5k" - -#: ../../rst/network/user_guide/platform_nxos.rst:144 -#: ../../rst/network/user_guide/platform_nxos.rst:145 -msgid "7.3(0)N1(1) and later" -msgstr "7.3(0)N1(1) 以降" - -#: ../../rst/network/user_guide/platform_nxos.rst:145 -msgid "Cisco Nexus N6k" -msgstr "Cisco Nexus N6k" - -#: ../../rst/network/user_guide/platform_nxos.rst:146 -msgid "Cisco Nexus N7k" -msgstr "Cisco Nexus N7k" - -#: ../../rst/network/user_guide/platform_nxos.rst:146 -msgid "7.3(0)D1(1) and later" -msgstr "7.3(0)D1(1) 以降" - -#: ../../rst/network/user_guide/platform_nxos.rst:147 -msgid "Cisco Nexus MDS" -msgstr "Cisco Nexus MDS" - -#: ../../rst/network/user_guide/platform_nxos.rst:147 -msgid "8.4(1) and later" -msgstr "8.4(1) 以降" - -#: ../../rst/network/user_guide/platform_nxos.rst:150 -msgid "Platform Models" -msgstr "プラットフォームモデル" - -#: ../../rst/network/user_guide/platform_nxos.rst:154 -msgid "Platform" -msgstr "プラットフォーム" - -#: ../../rst/network/user_guide/platform_nxos.rst:154 -msgid "Description" -msgstr "説明" - -#: ../../rst/network/user_guide/platform_nxos.rst:156 -msgid "N3k" -msgstr "N3k" - -#: ../../rst/network/user_guide/platform_nxos.rst:156 -msgid "Support includes N30xx, N31xx and N35xx models" -msgstr "サポートには、N30xx モデル、N31xx モデル、および N35xx モデルが含まれます。" - -#: ../../rst/network/user_guide/platform_nxos.rst:157 -msgid "N5k" -msgstr "N5k" - -#: ../../rst/network/user_guide/platform_nxos.rst:157 -msgid "Support includes all N5xxx models" -msgstr "サポートには、N5xxx の全モデルが含まれます。" - -#: ../../rst/network/user_guide/platform_nxos.rst:158 -msgid "N6k" -msgstr "N6k" - -#: ../../rst/network/user_guide/platform_nxos.rst:158 -msgid "Support includes all N6xxx models" -msgstr "サポートには、N6xxx の全モデルが含まれます。" - -#: ../../rst/network/user_guide/platform_nxos.rst:159 -msgid "N7k" -msgstr "N7k" - -#: ../../rst/network/user_guide/platform_nxos.rst:159 -msgid "Support includes all N7xxx models" -msgstr "サポートには、N7xxx の全モデルが含まれます。" - -#: ../../rst/network/user_guide/platform_nxos.rst:160 -msgid "N9k" -msgstr "N9k" - -#: ../../rst/network/user_guide/platform_nxos.rst:160 -msgid "Support includes all N9xxx models" -msgstr "サポートには、N9xxx の全モデルが含まれます。" - -#: ../../rst/network/user_guide/platform_nxos.rst:161 -msgid "MDS" -msgstr "MDS" - -#: ../../rst/network/user_guide/platform_nxos.rst:161 -msgid "Support includes all MDS 9xxx models" -msgstr "サポートには、MDS 9xxx モデルがすべて含まれます。" - -#: ../../rst/network/user_guide/platform_routeros.rst:5 -msgid "RouterOS Platform Options" -msgstr "RouterOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_routeros.rst:7 -msgid "RouterOS is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. This page offers details on how to use ``ansible.netcommon.network_cli`` on RouterOS in Ansible." -msgstr "RouterOS は `community.network `_ コレクションの一部で、現在は CLI 接続のみをサポートしています。将来的に ``httpapi`` モジュールが追加される可能性があります。このページでは、Ansible の RouterOS で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_routeros.rst:30 -msgid "``ansible_connection: ansible.network.network_cli``" -msgstr "``ansible_connection: ansible.network.network_cli``" - -#: ../../rst/network/user_guide/platform_routeros.rst:32 -msgid "not supported by RouterOS" -msgstr "RouterOS ではサポートされません" - -#: ../../rst/network/user_guide/platform_routeros.rst:40 -msgid "RouterOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "RouterOS は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_routeros.rst:46 -msgid "Example CLI ``group_vars/routeros.yml``" -msgstr "CLI の例 ``group_vars/routeros.yml``" - -#: ../../rst/network/user_guide/platform_routeros.rst:63 -msgid "If you are getting timeout errors you may want to add ``+cet1024w`` suffix to your username which will disable console colors, enable \"dumb\" mode, tell RouterOS not to try detecting terminal capabilities and set terminal width to 1024 columns. See article `Console login process `_ in MikroTik wiki for more information." -msgstr "タイムアウトエラーが発生した場合は、ユーザー名に ``+cet1024w`` 接頭辞を追加することでコンソールの色を無効にし、「dumb」モードを有効にし、端末機能を検出しないように RouterOS に指示し、端末の幅を 1024 カラムに設定することができます。詳細は、MikroTik Wikiの記事「`Console login process `_」を参照してください。" - -#: ../../rst/network/user_guide/platform_slxos.rst:5 -msgid "SLX-OS Platform Options" -msgstr "SLX-OS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_slxos.rst:7 -msgid "Extreme SLX-OS is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. This page offers details on how to use ``ansible.netcommon.network_cli`` on SLX-OS in Ansible." -msgstr "Extreme SLX-OS は `community.network `_ コレクションの一部で、現在は CLI 接続のみをサポートしています。将来的に ``httpapi`` モジュールが追加される可能性があります。このページでは、Ansible の SLX-OS で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_slxos.rst:32 -msgid "not supported by SLX-OS" -msgstr "SLX-OS ではサポートされません" - -#: ../../rst/network/user_guide/platform_slxos.rst:40 -msgid "SLX-OS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "SLX-OS は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_slxos.rst:46 -msgid "Example CLI ``group_vars/slxos.yml``" -msgstr "CLI の例 ``group_vars/slxos.yml``" - -#: ../../rst/network/user_guide/platform_voss.rst:5 -msgid "VOSS Platform Options" -msgstr "VOSS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_voss.rst:7 -msgid "Extreme VOSS is part of the `community.network `_ collection and only supports CLI connections today. This page offers details on how to use ``ansible.netcommon.network_cli`` on VOSS in Ansible." -msgstr "Extreme VOSS は `community.network `_ コレクションの一部で、現在は CLI 接続のみをサポートしています。このページでは、Ansible の VOSS で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_voss.rst:32 -msgid "supported: use ``ansible_become: yes`` with ``ansible_become_method: enable``" -msgstr "サポート対象: ``ansible_become: yes`` を ``ansible_become_method: enable`` と併用してください。" - -#: ../../rst/network/user_guide/platform_voss.rst:41 -msgid "VOSS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "VOSS は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_voss.rst:47 -msgid "Example CLI ``group_vars/voss.yml``" -msgstr "CLI の例 ``group_vars/voss.yml``" - -#: ../../rst/network/user_guide/platform_vyos.rst:5 -msgid "VyOS Platform Options" -msgstr "VyOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_vyos.rst:7 -msgid "The `VyOS `_ collection supports the ``ansible.netcommon.network_cli`` connection type. This page offers details on connection options to manage VyOS using Ansible." -msgstr "`VyOS `_ コレクションは、``ansible.netcommon.network_cli`` 接続タイプをサポートします。このページでは、Ansible を使用して VyOS を管理する接続オプションの詳細を提供します。" - -#: ../../rst/network/user_guide/platform_vyos.rst:45 -msgid "Example CLI ``group_vars/vyos.yml``" -msgstr "CLI の例 ``group_vars/vyos.yml``" - -#~ msgid "The units of action in Ansible. You can execute a single task once with an ad-hoc command." -#~ msgstr "" - -#~ msgid "Unlike most Ansible modules, network modules do not run on the managed nodes. From a user's point of view, network modules work like any other modules. They work with ad-hoc commands, playbooks, and roles. Behind the scenes, however, network modules use a different methodology than the other (Linux/Unix and Windows) modules use. Ansible is written and executed in Python. Because the majority of network devices can not run Python, the Ansible network modules are executed on the Ansible control node, where ``ansible`` or ``ansible-playbook`` runs." -#~ msgstr "" - -#~ msgid "Although Ansible contains a number of plugins that can convert XML to Ansible native data structures, the``cli_parse`` module runs the command on devices that return XML and returns the converted data in a single task." -#~ msgstr "" - -#~ msgid "The following is an example TTP template stored as ``templates/nxos_show_interfaces.ttp``:" -#~ msgstr "" - -#~ msgid "Using an ad-hoc ``ansible`` command" -#~ msgstr "" - -#~ msgid "`ad-hoc` refers to running Ansible to perform some quick command using ``/usr/bin/ansible``, rather than the orchestration language, which is ``/usr/bin/ansible-playbook``. In this case we can ensure connectivity by attempting to execute a single command on the remote device::" -#~ msgstr "" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/plugins.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/plugins.po deleted file mode 100644 index db9dd05a4a0..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/plugins.po +++ /dev/null @@ -1,1018 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-02-23 10:50+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/plugins/action.rst:4 -msgid "Action Plugins" -msgstr "action プラグイン" - -#: ../../rst/plugins/action.rst:10 -msgid "Action plugins act in conjunction with :ref:`modules ` to execute the actions required by playbook tasks. They usually execute automatically in the background doing prerequisite work before modules execute." -msgstr "action プラグインは、:ref:`modules ` と連携して、Playbook タスクに必要なアクションを実行します。これらは通常、モジュールが実行される前に、前提条件の作業を行うバックグラウンドで自動的に実行します。" - -#: ../../rst/plugins/action.rst:13 -msgid "The 'normal' action plugin is used for modules that do not already have an action plugin." -msgstr "action プラグインが指定されていないモジュールには、「一般的な」action プラグインが使用されます。" - -#: ../../rst/plugins/action.rst:18 -msgid "Enabling action plugins" -msgstr "action プラグインの有効化" - -#: ../../rst/plugins/action.rst:20 -msgid "You can enable a custom action plugin by either dropping it into the ``action_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the action plugin directory sources configured in :ref:`ansible.cfg `." -msgstr "カスタムの action プラグインを有効にするには、カスタムのプラグインを、ロール内のプレイの隣りにある ``action_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg ` に設定した action プラグインのディレクトリーソースの 1 つに配置します。" - -#: ../../rst/plugins/action.rst:25 -msgid "Using action plugins" -msgstr "action プラグインの使用" - -#: ../../rst/plugins/action.rst:27 -msgid "Action plugin are executed by default when an associated module is used; no action is required." -msgstr "action プラグインは、関連のモジュールを使用する場合にはデフォルトで実行するため、特に作業は必要ありません。" - -#: ../../rst/plugins/action.rst:30 ../../rst/plugins/callback.rst:77 -#: ../../rst/plugins/lookup.rst:136 ../../rst/plugins/strategy.rst:56 -msgid "Plugin list" -msgstr "プラグイン一覧" - -#: ../../rst/plugins/action.rst:32 -msgid "You cannot list action plugins directly, they show up as their counterpart modules:" -msgstr "直接 action プラグインの一覧を表示することはできませんが、対応のモジュールとして表示されます。" - -#: ../../rst/plugins/action.rst:34 -msgid "Use ``ansible-doc -l`` to see the list of available modules. Use ``ansible-doc `` to see specific documentation and examples, this should note if the module has a corresponding action plugin." -msgstr "``ansible-doc -l`` を使用して、利用可能なモジュールの一覧を表示します。特定のドキュメントおよび例を参照するには ``ansible-doc `` を使用してください。モジュールに対応の action プラグインがある場合には、この点に注意してください。" - -#: ../../rst/plugins/action.rst:39 ../../rst/plugins/callback.rst:86 -#: ../../rst/plugins/vars.rst:64 -msgid ":ref:`cache_plugins`" -msgstr ":ref:`cache_plugins`" - -#: ../../rst/plugins/action.rst:40 ../../rst/plugins/vars.rst:65 -msgid "Ansible Cache plugins" -msgstr "Ansible cache プラグイン" - -#: ../../rst/plugins/action.rst:41 ../../rst/plugins/become.rst:56 -#: ../../rst/plugins/cache.rst:125 ../../rst/plugins/connection.rst:65 -#: ../../rst/plugins/inventory.rst:147 ../../rst/plugins/lookup.rst:147 -#: ../../rst/plugins/shell.rst:42 ../../rst/plugins/strategy.rst:68 -#: ../../rst/plugins/vars.rst:66 -msgid ":ref:`callback_plugins`" -msgstr ":ref:`callback_plugins`" - -#: ../../rst/plugins/action.rst:42 ../../rst/plugins/become.rst:57 -#: ../../rst/plugins/cache.rst:126 ../../rst/plugins/connection.rst:66 -#: ../../rst/plugins/inventory.rst:148 ../../rst/plugins/lookup.rst:148 -#: ../../rst/plugins/shell.rst:43 ../../rst/plugins/strategy.rst:69 -#: ../../rst/plugins/vars.rst:67 -msgid "Ansible callback plugins" -msgstr "Ansible callback プラグイン" - -#: ../../rst/plugins/action.rst:43 ../../rst/plugins/cache.rst:127 -#: ../../rst/plugins/callback.rst:88 ../../rst/plugins/inventory.rst:149 -#: ../../rst/plugins/vars.rst:68 -msgid ":ref:`connection_plugins`" -msgstr ":ref:`connection_plugins`" - -#: ../../rst/plugins/action.rst:44 ../../rst/plugins/cache.rst:128 -#: ../../rst/plugins/callback.rst:89 ../../rst/plugins/inventory.rst:150 -#: ../../rst/plugins/vars.rst:69 -msgid "Ansible connection plugins" -msgstr "Ansible connection プラグイン" - -#: ../../rst/plugins/action.rst:45 ../../rst/plugins/become.rst:54 -#: ../../rst/plugins/cache.rst:129 ../../rst/plugins/callback.rst:90 -#: ../../rst/plugins/lookup.rst:145 ../../rst/plugins/shell.rst:40 -#: ../../rst/plugins/strategy.rst:66 ../../rst/plugins/vars.rst:70 -msgid ":ref:`inventory_plugins`" -msgstr ":ref:`inventory_plugins`" - -#: ../../rst/plugins/action.rst:46 ../../rst/plugins/become.rst:55 -#: ../../rst/plugins/cache.rst:130 ../../rst/plugins/callback.rst:91 -#: ../../rst/plugins/lookup.rst:146 ../../rst/plugins/shell.rst:41 -#: ../../rst/plugins/strategy.rst:67 ../../rst/plugins/vars.rst:71 -msgid "Ansible inventory plugins" -msgstr "Ansible inventory プラグインの使用" - -#: ../../rst/plugins/action.rst:47 ../../rst/plugins/cache.rst:131 -#: ../../rst/plugins/callback.rst:92 ../../rst/plugins/vars.rst:72 -msgid ":ref:`shell_plugins`" -msgstr ":ref:`shell_plugins`" - -#: ../../rst/plugins/action.rst:48 ../../rst/plugins/cache.rst:132 -#: ../../rst/plugins/callback.rst:93 ../../rst/plugins/vars.rst:73 -msgid "Ansible Shell plugins" -msgstr "Ansible shell プラグイン" - -#: ../../rst/plugins/action.rst:49 ../../rst/plugins/cache.rst:133 -#: ../../rst/plugins/callback.rst:94 ../../rst/plugins/vars.rst:74 -msgid ":ref:`strategy_plugins`" -msgstr ":ref:`strategy_plugins`" - -#: ../../rst/plugins/action.rst:50 ../../rst/plugins/cache.rst:134 -#: ../../rst/plugins/callback.rst:95 ../../rst/plugins/vars.rst:75 -msgid "Ansible Strategy plugins" -msgstr "Ansible strategy プラグイン" - -#: ../../rst/plugins/action.rst:51 ../../rst/plugins/cache.rst:135 -#: ../../rst/plugins/callback.rst:96 ../../rst/plugins/connection.rst:73 -#: ../../rst/plugins/inventory.rst:157 -msgid ":ref:`vars_plugins`" -msgstr ":ref:`vars_plugins`" - -#: ../../rst/plugins/action.rst:52 ../../rst/plugins/cache.rst:136 -#: ../../rst/plugins/callback.rst:97 -msgid "Ansible Vars plugins" -msgstr "Ansible vars プラグイン" - -#: ../../rst/plugins/action.rst:53 ../../rst/plugins/become.rst:64 -#: ../../rst/plugins/cliconf.rst:44 ../../rst/plugins/connection.rst:75 -#: ../../rst/plugins/httpapi.rst:69 ../../rst/plugins/inventory.rst:159 -#: ../../rst/plugins/lookup.rst:155 ../../rst/plugins/netconf.rst:44 -#: ../../rst/plugins/plugins.rst:41 ../../rst/plugins/shell.rst:50 -#: ../../rst/plugins/strategy.rst:76 ../../rst/plugins/vars.rst:76 -msgid "`User Mailing List `_" -msgstr "`User Mailing List `_" - -#: ../../rst/plugins/action.rst:54 ../../rst/plugins/become.rst:65 -#: ../../rst/plugins/cache.rst:138 ../../rst/plugins/callback.rst:99 -#: ../../rst/plugins/cliconf.rst:45 ../../rst/plugins/connection.rst:76 -#: ../../rst/plugins/httpapi.rst:70 ../../rst/plugins/inventory.rst:160 -#: ../../rst/plugins/lookup.rst:156 ../../rst/plugins/netconf.rst:45 -#: ../../rst/plugins/plugins.rst:42 ../../rst/plugins/shell.rst:51 -#: ../../rst/plugins/strategy.rst:77 ../../rst/plugins/vars.rst:77 -msgid "Have a question? Stop by the google group!" -msgstr "ご質問はございますか。Google Group をご覧ください。" - -#: ../../rst/plugins/action.rst:55 ../../rst/plugins/become.rst:66 -#: ../../rst/plugins/cliconf.rst:46 ../../rst/plugins/connection.rst:77 -#: ../../rst/plugins/httpapi.rst:71 ../../rst/plugins/inventory.rst:161 -#: ../../rst/plugins/lookup.rst:157 ../../rst/plugins/netconf.rst:46 -#: ../../rst/plugins/plugins.rst:43 ../../rst/plugins/shell.rst:52 -#: ../../rst/plugins/strategy.rst:78 ../../rst/plugins/vars.rst:78 -msgid "`irc.freenode.net `_" -msgstr "`irc.freenode.net `_" - -#: ../../rst/plugins/action.rst:56 ../../rst/plugins/become.rst:67 -#: ../../rst/plugins/cache.rst:140 ../../rst/plugins/callback.rst:101 -#: ../../rst/plugins/connection.rst:78 ../../rst/plugins/inventory.rst:162 -#: ../../rst/plugins/lookup.rst:158 ../../rst/plugins/plugins.rst:44 -#: ../../rst/plugins/shell.rst:53 ../../rst/plugins/strategy.rst:79 -#: ../../rst/plugins/vars.rst:79 -msgid "#ansible IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible)" - -#: ../../rst/plugins/become.rst:4 -msgid "Become Plugins" -msgstr "become プラグイン" - -#: ../../rst/plugins/become.rst:12 -msgid "Become plugins work to ensure that Ansible can use certain privilege escalation systems when running the basic commands to work with the target machine as well as the modules required to execute the tasks specified in the play." -msgstr "become プラグインは、基本的なコマンドの実行時に、Ansible が特定の特権昇格システムを使用して、プレイで指定されたタスクを実行するのに必要なモジュールやターゲットマシンと連携できるようにします。" - -#: ../../rst/plugins/become.rst:16 -msgid "These utilities (``sudo``, ``su``, ``doas``, and so on) generally let you 'become' another user to execute a command with the permissions of that user." -msgstr "通常、``sudo``、``su``、``doas`` などのユーティリティーを使用すると、別のユーザーになって (become)、そのユーザーのパーミッションでコマンドを実行できるようになります。" - -#: ../../rst/plugins/become.rst:23 -msgid "Enabling Become Plugins" -msgstr "become プラグインの有効化" - -#: ../../rst/plugins/become.rst:25 -msgid "The become plugins shipped with Ansible are already enabled. Custom plugins can be added by placing them into a ``become_plugins`` directory adjacent to your play, inside a role, or by placing them in one of the become plugin directory sources configured in :ref:`ansible.cfg `." -msgstr "Ansible に同梱されている become プラグインはすでに有効になっています。カスタムのプラグインを追加するには、ロール内のプレイの隣りにある ``become_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg ` で設定した become プラグインのディレクトリーソースの 1 つに配置します。" - -#: ../../rst/plugins/become.rst:33 -msgid "Using Become Plugins" -msgstr "become プラグインの使用" - -#: ../../rst/plugins/become.rst:35 -msgid "In addition to the default configuration settings in :ref:`ansible_configuration_settings` or the ``--become-method`` command line option, you can use the ``become_method`` keyword in a play or, if you need to be 'host specific', the connection variable ``ansible_become_method`` to select the plugin to use." -msgstr ":ref:`ansible_configuration_settings` や ``--become-method`` コマンドラインオプションでのデフォルト設定に加え、プレイで ``become_method`` キーワードを使用できます。「ホスト固有」にする必要がある場合は、接続変数 ``ansible_become_method`` で、使用するプラグインを選択します。" - -#: ../../rst/plugins/become.rst:39 ../../rst/plugins/shell.rst:33 -msgid "You can further control the settings for each plugin via other configuration options detailed in the plugin themselves (linked below)." -msgstr "プラグイン自体 (以下にリンク) に詳述されているその他の設定オプションを使用して、各プラグインの設定をさらに制御できます。" - -#: ../../rst/plugins/become.rst:45 ../../rst/plugins/cache.rst:116 -#: ../../rst/plugins/connection.rst:55 ../../rst/plugins/inventory.rst:138 -msgid "Plugin List" -msgstr "プラグイン一覧" - -#: ../../rst/plugins/become.rst:47 -msgid "You can use ``ansible-doc -t become -l`` to see the list of available plugins. Use ``ansible-doc -t become `` to see specific documentation and examples." -msgstr "``ansible-doc -t become -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t become `` を使用して、特定のドキュメントと例を参照してください。" - -#: ../../rst/plugins/become.rst:52 ../../rst/plugins/inventory.rst:145 -#: ../../rst/plugins/lookup.rst:143 ../../rst/plugins/plugins.rst:35 -#: ../../rst/plugins/shell.rst:38 ../../rst/plugins/strategy.rst:64 -msgid ":ref:`about_playbooks`" -msgstr ":ref:`about_playbooks`" - -#: ../../rst/plugins/become.rst:53 ../../rst/plugins/connection.rst:64 -#: ../../rst/plugins/inventory.rst:146 ../../rst/plugins/lookup.rst:144 -#: ../../rst/plugins/plugins.rst:36 ../../rst/plugins/shell.rst:39 -#: ../../rst/plugins/strategy.rst:65 -msgid "An introduction to playbooks" -msgstr "Playbook の概要" - -#: ../../rst/plugins/become.rst:58 ../../rst/plugins/inventory.rst:151 -#: ../../rst/plugins/lookup.rst:149 ../../rst/plugins/shell.rst:44 -#: ../../rst/plugins/strategy.rst:70 -msgid ":ref:`playbooks_filters`" -msgstr ":ref:`playbooks_filters`" - -#: ../../rst/plugins/become.rst:59 ../../rst/plugins/connection.rst:68 -#: ../../rst/plugins/inventory.rst:152 ../../rst/plugins/lookup.rst:150 -#: ../../rst/plugins/shell.rst:45 ../../rst/plugins/strategy.rst:71 -msgid "Jinja2 filter plugins" -msgstr "Jinja2 filter プラグイン" - -#: ../../rst/plugins/become.rst:60 ../../rst/plugins/inventory.rst:153 -#: ../../rst/plugins/lookup.rst:151 ../../rst/plugins/shell.rst:46 -#: ../../rst/plugins/strategy.rst:72 -msgid ":ref:`playbooks_tests`" -msgstr ":ref:`playbooks_tests`" - -#: ../../rst/plugins/become.rst:61 ../../rst/plugins/connection.rst:70 -#: ../../rst/plugins/inventory.rst:154 ../../rst/plugins/lookup.rst:152 -#: ../../rst/plugins/shell.rst:47 ../../rst/plugins/strategy.rst:73 -msgid "Jinja2 test plugins" -msgstr "Jinja2 test プラグイン" - -#: ../../rst/plugins/become.rst:62 ../../rst/plugins/inventory.rst:155 -#: ../../rst/plugins/lookup.rst:153 ../../rst/plugins/shell.rst:48 -#: ../../rst/plugins/strategy.rst:74 -msgid ":ref:`playbooks_lookups`" -msgstr ":ref:`playbooks_lookups`" - -#: ../../rst/plugins/become.rst:63 ../../rst/plugins/connection.rst:72 -#: ../../rst/plugins/inventory.rst:156 ../../rst/plugins/lookup.rst:154 -#: ../../rst/plugins/shell.rst:49 ../../rst/plugins/strategy.rst:75 -msgid "Jinja2 lookup plugins" -msgstr "Jinja2 lookup プラグイン" - -#: ../../rst/plugins/cache.rst:4 -msgid "Cache Plugins" -msgstr "cache プラグイン" - -#: ../../rst/plugins/cache.rst:10 -msgid "Cache plugins allow Ansible to store gathered facts or inventory source data without the performance hit of retrieving them from source." -msgstr "cache プラグインを使用すると、Ansible は、ソースから取得するパフォーマンスに影響を与えずに、収集したファクトまたはインベントリーソースデータを保存できるようになります。" - -#: ../../rst/plugins/cache.rst:12 -msgid "The default cache plugin is the :ref:`memory ` plugin, which only caches the data for the current execution of Ansible. Other plugins with persistent storage are available to allow caching the data across runs. Some of these cache plugins write to files, others write to databases." -msgstr "デフォルトのキャッシュプラグインは :ref:`memory ` プラグインです。Ansible の現在の実行のデータのみをキャッシュします。永続ストレージを備えた他のプラグインを使用して、実行間でデータをキャッシュできます。これらのキャッシュプラグインの中にはファイルに書き込むものもあれば、データベースに書き込むものもあります。" - -#: ../../rst/plugins/cache.rst:14 -msgid "You can use different cache plugins for inventory and facts. If you enable inventory caching without setting an inventory-specific cache plugin, Ansible uses the fact cache plugin for both facts and inventory." -msgstr "インベントリーとファクトにさまざまな cache プラグインを使用できます。インベントリー固有の cache プラグインを設定せずにインベントリー固有のキャッシュを有効にした場合、Ansible は、ファクトとインベントリー両方に cache プラグインを使用します。" - -#: ../../rst/plugins/cache.rst:19 -msgid "Enabling Fact Cache Plugins" -msgstr "ファクトの cache プラグインの有効化" - -#: ../../rst/plugins/cache.rst:21 -msgid "Fact caching is always enabled. However, only one fact cache plugin can be active at a time. You can select the cache plugin to use for fact caching in the Ansible configuration, either with an environment variable:" -msgstr "ファクトキャッシングは常に有効になっています。ただし、一度にアクティブにできるファクトの cache プラグインは 1 つだけです。環境変数を使用して、Ansible 設定でファクトキャッシュに使用するキャッシュプラグインを選択できます。" - -#: ../../rst/plugins/cache.rst:27 ../../rst/plugins/cache.rst:55 -msgid "or in the ``ansible.cfg`` file:" -msgstr "または ``ansible.cfg`` ファイルで、以下を行います。" - -#: ../../rst/plugins/cache.rst:34 -msgid "If the cache plugin is in a collection use the fully qualified name:" -msgstr "cache プラグインをコレクションで使用する場合は、完全修飾名を使用してください。" - -#: ../../rst/plugins/cache.rst:41 -msgid "To enable a custom cache plugin, save it in a ``cache_plugins`` directory adjacent to your play, inside a role, or in one of the directory sources configured in :ref:`ansible.cfg `." -msgstr "カスタムの cache プラグインを有効にするには、ロール内のプレイの隣りにある ``cache_plugins`` ディレクトリーに保存するか、:ref:`ansible.cfg ` で設定したディレクトリーソースの 1 つに保存します。" - -#: ../../rst/plugins/cache.rst:43 -msgid "You also need to configure other settings specific to each plugin. Consult the individual plugin documentation or the Ansible :ref:`configuration ` for more details." -msgstr "また、各プラグインに固有の他の設定を構成する必要があります。個々のプラグインのドキュメントまたは Ansible の「:ref:`設定 `」を参照してください。" - -#: ../../rst/plugins/cache.rst:47 -msgid "Enabling Inventory Cache Plugins" -msgstr "インベントリーの cache プラグインの有効化" - -#: ../../rst/plugins/cache.rst:49 -msgid "Inventory caching is disabled by default. To cache inventory data, you must enable inventory caching and then select the specific cache plugin you want to use. Not all inventory plugins support caching, so check the documentation for the inventory plugin(s) you want to use. You can enable inventory caching with an environment variable:" -msgstr "インベントリーキャッシュはデフォルトで無効になっています。インベントリーデータをキャッシュするには、インベントリーキャッシュを有効にしてから、使用する特定の cache プラグインを選択する必要があります。すべての intentory プラグインがキャッシュをサポートしているわけではないため、使用する inventory プラグインのドキュメントを確認してください。環境変数を使用してインベントリーキャッシュを有効にできます。" - -#: ../../rst/plugins/cache.rst:62 ../../rst/plugins/cache.rst:83 -msgid "or if the inventory plugin accepts a YAML configuration source, in the configuration file:" -msgstr "または、inventory プラグインが YAML 設定ソースに対応している場合は、設定ファイルで以下を指定します。" - -#: ../../rst/plugins/cache.rst:70 -msgid "Only one inventory cache plugin can be active at a time. You can set it with an environment variable:" -msgstr "一度にアクティブにできるインベントリーの cache プラグインは 1 つだけです。環境変数を使用して設定できます。" - -#: ../../rst/plugins/cache.rst:76 -msgid "or in the ansible.cfg file:" -msgstr "または、ansible.cfg ファイルで以下を設定します。" - -#: ../../rst/plugins/cache.rst:91 -msgid "To cache inventory with a custom plugin in your plugin path, follow the :ref:`developer guide on cache plugins`." -msgstr "プラグインパスにカスタムプラグインを使用してインベントリーをキャッシュするには、「:ref:`cache プラグインの開発者ガイド`」の手順に従ってください。" - -#: ../../rst/plugins/cache.rst:93 -msgid "To cache inventory with a cache plugin in a collection, use the FQCN:" -msgstr "コレクション内の cache プラグインを使用してインベントリーをキャッシュするには、FQCN を使用します。" - -#: ../../rst/plugins/cache.rst:100 -msgid "If you enable caching for inventory plugins without selecting an inventory-specific cache plugin, Ansible falls back to caching inventory with the fact cache plugin you configured. Consult the individual inventory plugin documentation or the Ansible :ref:`configuration ` for more details." -msgstr "インベントリー固有の cache プラグインを選択せずに inventory プラグインのキャッシュを有効にした場合、Ansible は、設定済みのファクトの cache プラグインでインベントリーのキャッシュが行われるようにフォールバックします。詳細は、inventory プラグインのドキュメント、または Ansible の「:ref:`設定 `」を参照してください。" - -#: ../../rst/plugins/cache.rst:108 -msgid "Using Cache Plugins" -msgstr "cache プラグインの使用" - -#: ../../rst/plugins/cache.rst:110 -msgid "Cache plugins are used automatically once they are enabled." -msgstr "cache プラグインは、有効になると自動的に使用されます。" - -#: ../../rst/plugins/cache.rst:118 -msgid "You can use ``ansible-doc -t cache -l`` to see the list of available plugins. Use ``ansible-doc -t cache `` to see specific documentation and examples." -msgstr "``ansible-doc -t cache -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t cache `` を使用して、特定のドキュメントと例を参照してください。" - -#: ../../rst/plugins/cache.rst:123 ../../rst/plugins/callback.rst:84 -#: ../../rst/plugins/vars.rst:62 -msgid ":ref:`action_plugins`" -msgstr ":ref:`action_plugins`" - -#: ../../rst/plugins/cache.rst:124 ../../rst/plugins/callback.rst:85 -#: ../../rst/plugins/vars.rst:63 -msgid "Ansible Action plugins" -msgstr "Ansible action プラグイン" - -#: ../../rst/plugins/cache.rst:137 ../../rst/plugins/callback.rst:98 -msgid "`User Mailing List `_" -msgstr "`User Mailing List `_" - -#: ../../rst/plugins/cache.rst:139 ../../rst/plugins/callback.rst:100 -msgid "`webchat.freenode.net `_" -msgstr "`webchat.freenode.net `_" - -#: ../../rst/plugins/callback.rst:4 -msgid "Callback Plugins" -msgstr "callback プラグイン" - -#: ../../rst/plugins/callback.rst:10 -msgid "Callback plugins enable adding new behaviors to Ansible when responding to events. By default, callback plugins control most of the output you see when running the command line programs, but can also be used to add additional output, integrate with other tools and marshall the events to a storage backend." -msgstr "callback プラグインを使用すると、イベントに応答するときに Ansible に新しい動作を追加できます。デフォルトでは、callback プラグインは、コマンドラインプログラムを実行時に表示される出力の大半を制御しますが、他の出力を追加し、他のツールと統合し、ストレージバックエンドにイベントをマーシャリングすることにも使用できます。" - -#: ../../rst/plugins/callback.rst:17 -msgid "Example callback plugins" -msgstr "callback プラグインの例" - -#: ../../rst/plugins/callback.rst:19 -msgid "The :ref:`log_plays ` callback is an example of how to record playbook events to a log file, and the :ref:`mail ` callback sends email on playbook failures." -msgstr ":ref:`log_plays ` のコールバックは、Playbook のイベントをログファイルに記録する一例で、:ref:`mail ` コールバックは Playbook の失敗時にメールを送信します。" - -#: ../../rst/plugins/callback.rst:22 -msgid "The :ref:`say ` callback responds with computer synthesized speech in relation to playbook events." -msgstr "また、:ref:`say ` コールバックは、Playbook のイベントに関連して、コンピューターで合成された音声で応答します。" - -#: ../../rst/plugins/callback.rst:27 -msgid "Enabling callback plugins" -msgstr "callback プラグインの有効化" - -#: ../../rst/plugins/callback.rst:29 -msgid "You can activate a custom callback by either dropping it into a ``callback_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the callback directory sources configured in :ref:`ansible.cfg `." -msgstr "カスタムの callback を有効にするには、その callback を、ロール内のプレイの隣りにある ``callback_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg ` で設定した callback ディレクトリーソースの 1 つに置きます。" - -#: ../../rst/plugins/callback.rst:31 -msgid "Plugins are loaded in alphanumeric order. For example, a plugin implemented in a file named `1_first.py` would run before a plugin file named `2_second.py`." -msgstr "プラグインは英数字順に読み込まれます。たとえば、`1_first.py` という名前で実装されているプラグインは、`2_second.py` という名前のプラグインファイルより先に実行されます。" - -#: ../../rst/plugins/callback.rst:33 -msgid "Most callbacks shipped with Ansible are disabled by default and need to be enabled in your :ref:`ansible.cfg ` file in order to function. For example:" -msgstr "Ansible に同梱されるほとんどの callback プラグインはデフォルトで無効になっており、このプラグインを機能させるには、:ref:`ansible.cfg ` ファイルで有効にする必要があります。以下に例を示します。" - -#: ../../rst/plugins/callback.rst:40 -msgid "Setting a callback plugin for ``ansible-playbook``" -msgstr "``ansible-playbook``の callback プラグインの設定" - -#: ../../rst/plugins/callback.rst:42 -msgid "You can only have one plugin be the main manager of your console output. If you want to replace the default, you should define CALLBACK_TYPE = stdout in the subclass and then configure the stdout plugin in :ref:`ansible.cfg `. For example:" -msgstr "コンソール出力のメインマネージャーは、1 つのプラグインのみにすることができます。デフォルトを置き換える場合は、サブクラスに CALLBACK_TYPE = stdout を定義して、:ref:`ansible.cfg ` に stdout プラグインを設定する必要があります。以下に例を示します。" - -#: ../../rst/plugins/callback.rst:48 -msgid "or for my custom callback:" -msgstr "または、カスタムのコールバックの場合は以下を実行します。" - -#: ../../rst/plugins/callback.rst:54 -msgid "This only affects :ref:`ansible-playbook` by default." -msgstr "これは、デフォルトでは、:ref:`ansible-playbook` にのみ影響を及ぼします。" - -#: ../../rst/plugins/callback.rst:57 -msgid "Setting a callback plugin for ad hoc commands" -msgstr "アドホックコマンドへの callback プラグインの設定" - -#: ../../rst/plugins/callback.rst:59 -msgid "The :ref:`ansible` ad hoc command specifically uses a different callback plugin for stdout, so there is an extra setting in :ref:`ansible_configuration_settings` you need to add to use the stdout callback defined above:" -msgstr ":ref:`ansible` アドホックコマンドは、特に stdout には別の callback プラグインを使用するため、上記に定義した stdout callback を使用するには、追加する必要がある :ref:`ansible_configuration_settings` にさらに設定を追加する必要があります。" - -#: ../../rst/plugins/callback.rst:67 -msgid "You can also set this as an environment variable:" -msgstr "これを環境変数として設定することもできます。" - -#: ../../rst/plugins/callback.rst:79 -msgid "You can use ``ansible-doc -t callback -l`` to see the list of available plugins. Use ``ansible-doc -t callback `` to see specific documents and examples." -msgstr "``ansible-doc -t callback -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t callback `` を使用して、特定のドキュメントと例を参照してください。" - -#: ../../rst/plugins/callback.rst:87 -msgid "Ansible cache plugins" -msgstr "Ansible cache プラグイン" - -#: ../../rst/plugins/cliconf.rst:4 -msgid "Cliconf Plugins" -msgstr "cliconf プラグイン" - -#: ../../rst/plugins/cliconf.rst:10 -msgid "Cliconf plugins are abstractions over the CLI interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices." -msgstr "cliconf プラグインは、ネットワークデバイスへの CLI インターフェースを介した抽象化です。これらは、Ansible がこれらのネットワークデバイスでタスクを実行するための標準インターフェースを提供します。" - -#: ../../rst/plugins/cliconf.rst:12 -msgid "These plugins generally correspond one-to-one to network device platforms. Ansible loads the appropriate cliconf plugin automatically based on the ``ansible_network_os`` variable." -msgstr "通常、これらのプラグインはネットワークデバイスのプラットフォームに 1 対 1 で対応します。Ansible は ``ansible_network_os`` 変数に基づいて適切な cliconf プラグインを自動的に読み込みます。" - -#: ../../rst/plugins/cliconf.rst:17 -msgid "Adding cliconf plugins" -msgstr "cliconf プラグインの追加" - -#: ../../rst/plugins/cliconf.rst:19 -msgid "You can extend Ansible to support other network devices by dropping a custom plugin into the ``cliconf_plugins`` directory." -msgstr "``cliconf_plugins`` ディレクトリーにカスタムのプラグインを置いて、Ansible が他のネットワークデバイスをサポートするように拡張できます。" - -#: ../../rst/plugins/cliconf.rst:24 -msgid "Using cliconf plugins" -msgstr "cliconf プラグインの使用" - -#: ../../rst/plugins/cliconf.rst:26 -msgid "The cliconf plugin to use is determined automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality." -msgstr "使用する cliconf プラグインは ``ansible_network_os`` 変数から自動的に決定されます。この機能を上書きする理由はありません。" - -#: ../../rst/plugins/cliconf.rst:28 -msgid "Most cliconf plugins can operate without configuration. A few have additional options that can be set to affect how tasks are translated into CLI commands." -msgstr "ほとんどの cliconf プラグインは設定なしで動作します。タスクが CLI コマンドにどのように変換されるかに影響する追加オプションがいくつかあります。" - -#: ../../rst/plugins/cliconf.rst:30 ../../rst/plugins/httpapi.rst:32 -#: ../../rst/plugins/netconf.rst:30 -msgid "Plugins are self-documenting. Each plugin should document its configuration options." -msgstr "プラグインは自己文書化されています。プラグインごとに、設定オプションについて文書化する必要があります。" - -#: ../../rst/plugins/cliconf.rst:35 -msgid "Viewing cliconf plugins" -msgstr "cliconf プラグインの表示" - -#: ../../rst/plugins/cliconf.rst:37 -msgid "These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several cliconf plugins. To list all available cliconf plugins on your control node, type ``ansible-doc -t cliconf -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t cliconf``." -msgstr "これらのプラグインは `Ansible Galaxy `_ のコレクションに移行しました。``pip`` を使用して Ansible バージョン 2.10 以降をインストールしている場合は、複数の cliconf プラグインにアクセスできます。コントロールノードで利用可能な cliconf プラグインの一覧を表示するには、``ansible-doc -t cliconf -l`` と入力します。プラグイン固有のドキュメントと例を確認するには、``ansible-doc -t cliconf`` を使用します。" - -#: ../../rst/plugins/cliconf.rst:42 ../../rst/plugins/httpapi.rst:65 -#: ../../rst/plugins/netconf.rst:42 -msgid ":ref:`Ansible for Network Automation`" -msgstr ":ref:`Ansible for Network Automation`" - -#: ../../rst/plugins/cliconf.rst:43 ../../rst/plugins/httpapi.rst:66 -#: ../../rst/plugins/netconf.rst:43 -msgid "An overview of using Ansible to automate networking devices." -msgstr "Ansible を使用したネットワークデバイスの自動化の概要" - -#: ../../rst/plugins/cliconf.rst:47 ../../rst/plugins/httpapi.rst:72 -#: ../../rst/plugins/netconf.rst:47 -msgid "#ansible-network IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible-network)" - -#: ../../rst/plugins/connection.rst:4 -msgid "Connection Plugins" -msgstr "connection プラグイン" - -#: ../../rst/plugins/connection.rst:10 -msgid "Connection plugins allow Ansible to connect to the target hosts so it can execute tasks on them. Ansible ships with many connection plugins, but only one can be used per host at a time." -msgstr "接続プラグインにより、Ansible はターゲットホストに接続してそのホストにあるタスクを実行できるようにします。Ansible には多くの接続プラグインが同梱されていますが、一度に使用できるのは 1 つのみとなります。" - -#: ../../rst/plugins/connection.rst:12 -msgid "By default, Ansible ships with several plugins. The most commonly used are the :ref:`paramiko SSH`, native ssh (just called :ref:`ssh`), and :ref:`local` connection types. All of these can be used in playbooks and with :command:`/usr/bin/ansible` to decide how you want to talk to remote machines." -msgstr "デフォルトでは、Ansible には複数のプラグインが同梱されています。最も一般的に使用されるものは、:ref:`paramiko SSH` ネイティブ ssh (ただ :ref:`ssh` と呼ばれます)、および :ref:`local` 接続タイプです。これらはすべて、リモートマシンとの通信方法を決定するために Playbook と :command:`/usr/bin/ansible` で使用できます。" - -#: ../../rst/plugins/connection.rst:14 -msgid "The basics of these connection types are covered in the :ref:`getting started` section." -msgstr "このような接続タイプの基本情報は、:ref:`getting started` のセクションで説明しています。" - -#: ../../rst/plugins/connection.rst:19 -msgid "``ssh`` plugins" -msgstr "``ssh`` プラグイン" - -#: ../../rst/plugins/connection.rst:21 -msgid "Because ssh is the default protocol used in system administration and the protocol most used in Ansible, ssh options are included in the command line tools. See :ref:`ansible-playbook` for more details." -msgstr "ssh は、システム管理で使用されるデフォルトのプロトコルであり、Ansible で最も使用されるプロトコルでもあるため、コマンドラインツールに ssh オプションが含まれています。詳細は、「:ref:`ansible-playbook`」を参照してください。" - -#: ../../rst/plugins/connection.rst:26 -msgid "Adding connection plugins" -msgstr "connection プラグインの追加" - -#: ../../rst/plugins/connection.rst:28 -msgid "You can extend Ansible to support other transports (such as SNMP or message bus) by dropping a custom plugin into the ``connection_plugins`` directory." -msgstr "カスタムのプラグインを ``connection_plugins`` ディレクトリーに置いて、他のトランスポート (SNMP やメッセージバスなど) をサポートするように Ansible を拡張できます。" - -#: ../../rst/plugins/connection.rst:34 -msgid "Using connection plugins" -msgstr "connection プラグインの使用" - -#: ../../rst/plugins/connection.rst:36 -msgid "You can set the connection plugin globally via :ref:`configuration`, at the command line (``-c``, ``--connection``), as a :ref:`keyword ` in your play, or by setting a :ref:`variable`, most often in your inventory. For example, for Windows machines you might want to set the :ref:`winrm ` plugin as an inventory variable." -msgstr "接続プラグインは、:ref:`configuration`、コマンドライン (``-c``、``--connection``)を経由するか、プレイの :ref:`keyword ` として使用するか、インベントリーにある :ref:`variable` を設定すること (もっとも多い例) で設定できます。たとえば、Windows マシンでは :ref:`winrm ` プラグインをインベントリー変数として設定できます。" - -#: ../../rst/plugins/connection.rst:39 -msgid "Most connection plugins can operate with minimal configuration. By default they use the :ref:`inventory hostname` and defaults to find the target host." -msgstr "ほとんどの接続プラグインは最小設定で動作します。デフォルトでは :ref:`inventory hostname` を使用し、デフォルトではターゲットホストを検索します。" - -#: ../../rst/plugins/connection.rst:41 -msgid "Plugins are self-documenting. Each plugin should document its configuration options. The following are connection variables common to most connection plugins:" -msgstr "プラグインは自己文書化されています。各プラグインは、その設定オプションを文書化する必要があります。以下は、ほとんどの接続プラグインに共通する接続変数です。" - -#: ../../rst/plugins/connection.rst:43 -msgid ":ref:`ansible_host`" -msgstr ":ref:`ansible_host`" - -#: ../../rst/plugins/connection.rst:44 -msgid "The name of the host to connect to, if different from the :ref:`inventory ` hostname." -msgstr "接続するホストの名前 (:ref:`inventory ` のホスト名と異なる場合)。" - -#: ../../rst/plugins/connection.rst:45 -msgid ":ref:`ansible_port`" -msgstr ":ref:`ansible_port`" - -#: ../../rst/plugins/connection.rst:46 -msgid "The ssh port number, for :ref:`ssh ` and :ref:`paramiko_ssh ` it defaults to 22." -msgstr ":ref:`ssh ` および :ref:`paramiko_ssh ` の場合は ssh ポート番号。デフォルトは 22 です。" - -#: ../../rst/plugins/connection.rst:48 -msgid ":ref:`ansible_user`" -msgstr ":ref:`ansible_user`" - -#: ../../rst/plugins/connection.rst:48 -msgid "The default user name to use for log in. Most plugins default to the 'current user running Ansible'." -msgstr "ログインに使用するデフォルトのユーザー名。ほとんどのプラグインはデフォルトで Ansible を実行している現在のユーザーです。" - -#: ../../rst/plugins/connection.rst:50 -msgid "Each plugin might also have a specific version of a variable that overrides the general version. For example, ``ansible_ssh_host`` for the :ref:`ssh ` plugin." -msgstr "プラグインごとに、一般的なバージョンを上書きする特定の変数バージョンが存在する場合もあります。たとえば、:ref:`ssh ` プラグインの場合は ``ansible_ssh_host`` です。" - -#: ../../rst/plugins/connection.rst:57 -msgid "You can use ``ansible-doc -t connection -l`` to see the list of available plugins. Use ``ansible-doc -t connection `` to see detailed documentation and examples." -msgstr "``ansible-doc -t connection -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t connection `` を使用して、詳細なドキュメントと例を参照してください。" - -#: ../../rst/plugins/connection.rst:63 -msgid ":ref:`Working with Playbooks`" -msgstr ":ref:`Working with Playbooks`" - -#: ../../rst/plugins/connection.rst:67 -msgid ":ref:`Filters`" -msgstr ":ref:`Filters`" - -#: ../../rst/plugins/connection.rst:69 -msgid ":ref:`Tests`" -msgstr ":ref:`Tests`" - -#: ../../rst/plugins/connection.rst:71 -msgid ":ref:`Lookups`" -msgstr ":ref:`Lookups`" - -#: ../../rst/plugins/connection.rst:74 ../../rst/plugins/inventory.rst:158 -msgid "Ansible vars plugins" -msgstr "Ansible vars プラグイン" - -#: ../../rst/plugins/httpapi.rst:4 -msgid "Httpapi Plugins" -msgstr "httpapi プラグイン" - -#: ../../rst/plugins/httpapi.rst:10 -msgid "Httpapi plugins tell Ansible how to interact with a remote device's HTTP-based API and execute tasks on the device." -msgstr "httpapi プラグインは、Ansible に対して、リモートデバイスの HTTP ベースの API と対話して、そのデバイスでタスクを実行する方法を指示します。" - -#: ../../rst/plugins/httpapi.rst:13 -msgid "Each plugin represents a particular dialect of API. Some are platform-specific (Arista eAPI, Cisco NXAPI), while others might be usable on a variety of platforms (RESTCONF). Ansible loads the appropriate httpapi plugin automatically based on the ``ansible_network_os`` variable." -msgstr "各プラグインは、特定の API 方言を表します。プラットフォーム固有のもの (Arista eAPI、Cisco NXAPI) があり、さまざまなプラットフォーム (RESTCONF) を使用できる場合があります。Ansible は ``ansible_network_os`` 変数に基づいて適切な httpapi プラグインを自動的に読み込みます。" - -#: ../../rst/plugins/httpapi.rst:19 -msgid "Adding httpapi plugins" -msgstr "httpapi プラグインの追加" - -#: ../../rst/plugins/httpapi.rst:21 -msgid "You can extend Ansible to support other APIs by dropping a custom plugin into the ``httpapi_plugins`` directory. See :ref:`developing_plugins_httpapi` for details." -msgstr "``httpapi_plugins`` ディレクトリーにカスタムのプラグインを置いて、Ansible が他の API をサポートするように拡張できます。詳細は、「:ref:`developing_plugins_httpapi`」を参照してください。" - -#: ../../rst/plugins/httpapi.rst:26 -msgid "Using httpapi plugins" -msgstr "httpapi プラグインの使用" - -#: ../../rst/plugins/httpapi.rst:28 -msgid "The httpapi plugin to use is determined automatically from the ``ansible_network_os`` variable." -msgstr "使用する httpapi プラグインは、``ansible_network_os`` 変数から自動的に判断されます。" - -#: ../../rst/plugins/httpapi.rst:30 -msgid "Most httpapi plugins can operate without configuration. Additional options may be defined by each plugin." -msgstr "ほとんどの httpapi プラグインは設定なしで動作します。追加オプションは各プラグインで定義できます。" - -#: ../../rst/plugins/httpapi.rst:35 -msgid "The following sample playbook shows the httpapi plugin for an Arista network device, assuming an inventory variable set as ``ansible_network_os=eos`` for the httpapi plugin to trigger off:" -msgstr "以下の Playbook サンプルでは、Arista ネットワークデバイスの httpapi プラグインについて示します。この例では、インベントリー変数を ``ansible_network_os=eos`` に設定して httpapi プラグインがオフになるようにトリガーすることを想定しています。" - -#: ../../rst/plugins/httpapi.rst:54 -msgid "See the full working example `on GitHub `_." -msgstr "`GitHub `_ にある完全な作業例を参照してください。" - -#: ../../rst/plugins/httpapi.rst:59 -msgid "Viewing httpapi plugins" -msgstr "httpapi プラグインの表示" - -#: ../../rst/plugins/httpapi.rst:61 -msgid "These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several httpapi plugins. To list all available httpapi plugins on your control node, type ``ansible-doc -t httpapi -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t httpapi``." -msgstr "これらのプラグインは `Ansible Galaxy `_ のコレクションに移行しました。``pip`` を使用して Ansible バージョン 2.10 以降をインストールしている場合は、複数の httpapi プラグインにアクセスできます。コントロールノードで利用可能な httpapi プラグインの一覧を表示するには、``ansible-doc -t httpapi -l`` と入力します。プラグイン固有のドキュメントと例を確認するには、``ansible-doc -t httpapi`` を使用します。" - -#: ../../rst/plugins/httpapi.rst:67 -msgid ":ref:`Developing network modules`" -msgstr ":ref:`Developing network modules`" - -#: ../../rst/plugins/httpapi.rst:68 -msgid "How to develop network modules." -msgstr "ネットワークモジュールの開発方法" - -#: ../../rst/plugins/inventory.rst:4 -msgid "Inventory Plugins" -msgstr "inventory プラグイン" - -#: ../../rst/plugins/inventory.rst:10 -msgid "Inventory plugins allow users to point at data sources to compile the inventory of hosts that Ansible uses to target tasks, either using the ``-i /path/to/file`` and/or ``-i 'host1, host2'`` command line parameters or from other configuration sources." -msgstr "inventory プラグインでは、``-i /path/to/file`` や ``-i 'host1, host2'`` コマンドラインパラメーターを使用したり、他の設定ソースを使用したりして、Ansible がタスクの対象として使用するホストのインベントリーをコンパイルするためのデータソースを指定できます。" - -#: ../../rst/plugins/inventory.rst:16 -msgid "Enabling inventory plugins" -msgstr "inventory プラグインの有効化" - -#: ../../rst/plugins/inventory.rst:18 -msgid "Most inventory plugins shipped with Ansible are enabled by default or can be used by with the ``auto`` plugin." -msgstr "Ansible に同梱されるほとんどの inventory プラグインはデフォルトで有効になっているか、``auto`` プラグインで使用することができます。" - -#: ../../rst/plugins/inventory.rst:20 -msgid "In some circumstances, for example, if the inventory plugin does not use a YAML configuration file, you may need to enable the specific plugin. You can do this by setting ``enable_plugins`` in your :ref:`ansible.cfg ` file in the ``[inventory]`` section. Modifying this will override the default list of enabled plugins. Here is the default list of enabled plugins that ships with Ansible:" -msgstr "たとえば、インベントリープラグインが YAML 設定ファイルを使用しない場合は、特定のプラグインを有効にする必要があります。これを行うには、``[inventory]`` セクションの :ref:`ansible.cfg `ファイルで ``enable_plugins``を設定します。これを変更すると、有効化されたプラグインのデフォルト一覧が上書きされます。以下は、Ansible に同梱される有効なプラグインのデフォルト一覧です。" - -#: ../../rst/plugins/inventory.rst:27 -msgid "If the plugin is in a collection, use the fully qualified name:" -msgstr "プラグインをコレクションで使用する場合は、完全修飾名を使用してください。" - -#: ../../rst/plugins/inventory.rst:38 -msgid "Using inventory plugins" -msgstr "inventory プラグインの使用" - -#: ../../rst/plugins/inventory.rst:40 -msgid "To use an inventory plugin, you must provide an inventory source. Most of the time this is a file containing host information or a YAML configuration file with options for the plugin. You can use the ``-i`` flag to provide inventory sources or configure a default inventory path." -msgstr "inventory プラグインを使用するには、インベントリーソースを指定する必要があります。そのほとんどは、プラグインのオプションを持つホスト情報または YAML 設定ファイルを含むファイルです。``-i`` フラグを使用してインベントリーソースを提供するか、デフォルトのインベントリーパスを設定することができます。" - -#: ../../rst/plugins/inventory.rst:46 -msgid "To start using an inventory plugin with a YAML configuration source, create a file with the accepted filename schema documented for the plugin in question, then add ``plugin: plugin_name``. Use the fully qualified name if the plugin is in a collection." -msgstr "YAML 設定ソースで inventory プラグインの使用を開始するには、該当するプラグインで文書化されている受け入れ可能なファイル名のスキーマでファイルを作成し、そのファイルに ``plugin: plugin_name`` を追加します。プラグインがコレクションにある場合は、完全修飾名を使用します。" - -#: ../../rst/plugins/inventory.rst:53 -msgid "Each plugin should document any naming restrictions. In addition, the YAML config file must end with the extension ``yml`` or ``yaml`` to be enabled by default with the ``auto`` plugin (otherwise, see the section above on enabling plugins)." -msgstr "各プラグインは命名制限について記載する必要があります。また、YAML 設定ファイルは、``auto`` プラグインでデフォルトで有効にする拡張子 ``yml`` または ``yaml`` で終了する必要があります (同様に、プラグインを有効にする際の上記のセクションを参照してください)。" - -#: ../../rst/plugins/inventory.rst:55 -msgid "After providing any required options, you can view the populated inventory with ``ansible-inventory -i demo.aws_ec2.yml --graph``:" -msgstr "必要なオプションを指定したら、``ansible-inventory -i demo.aws_ec2.yml --graph`` で設定され追加されたインベントリーを表示できます。" - -#: ../../rst/plugins/inventory.rst:65 -msgid "If you are using an inventory plugin in a playbook-adjacent collection and want to test your setup with ``ansible-inventory``, use the ``--playbook-dir`` flag." -msgstr "Playbook に隣接するコレクションで inventory プラグインを使用して、``ansible-inventory`` で設定をテストするには、``--playbook-dir`` フラグを使用する必要があります。" - -#: ../../rst/plugins/inventory.rst:67 -msgid "Your inventory source might be a directory of inventory configuration files. The constructed inventory plugin only operates on those hosts already in inventory, so you may want the constructed inventory configuration parsed at a particular point (such as last). Ansible parses the directory recursively, alphabetically. You cannot configure the parsing approach, so name your files to make it work predictably. Inventory plugins that extend constructed features directly can work around that restriction by adding constructed options in addition to the inventory plugin options. Otherwise, you can use ``-i`` with multiple sources to impose a specific order, for example ``-i demo.aws_ec2.yml -i clouds.yml -i constructed.yml``." -msgstr "インベントリーソースは、インベントリー設定ファイルのディレクトリーである場合があります。構築した inventory プラグインは、インベントリーにすでに存在するホストでのみ動作するため、特定のタイミング (「最後」など) で構築したインベントリー設定を解析してください。Ansible は、ディレクトリーを再帰的にアルファベットで解析します。解析アプローチは設定できないため、想定通りに機能するように、ファイルの名前を指定します。構築した機能を直接拡張したinventory プラグインは、inventory プラグインのオプションに構築したオプションを追加し、制約を回避して機能させることができます。それ以外の場合は、複数ソースに ``-i`` を使用して特定の順番を指定します (例: ``-i demo.aws_ec2.yml -i clouds.yml -i constructed.yml``)。" - -#: ../../rst/plugins/inventory.rst:69 -msgid "You can create dynamic groups using host variables with the constructed ``keyed_groups`` option. The option ``groups`` can also be used to create groups and ``compose`` creates and modifies host variables. Here is an aws_ec2 example utilizing constructed features:" -msgstr "構築した``keyed_groups`` オプションとホスト変数を使用して、動的なグループを作成できます。``groups`` オプションを使用してグループを作成し、``compose`` でホスト変数を作成して変更できます。以下は、構築した機能を使用する aws_ec2 のサンプルです。" - -#: ../../rst/plugins/inventory.rst:90 -msgid "Now the output of ``ansible-inventory -i demo.aws_ec2.yml --graph``:" -msgstr "これで、``ansible-inventory -i demo.aws_ec2.yml --graph`` の出力が表示されます。" - -#: ../../rst/plugins/inventory.rst:108 -msgid "If a host does not have the variables in the configuration above (in other words, ``tags.Name``, ``tags``, ``private_ip_address``), the host will not be added to groups other than those that the inventory plugin creates and the ``ansible_host`` host variable will not be modified." -msgstr "上記の設定でホストに変数がない場合には (つまり ``tags.Name``、``tags``、``private_ip_address``)、ホストは inventory プラグインが作成したグループ以外には追加されず、また ``ansible_host`` のホスト変数も変更されません。" - -#: ../../rst/plugins/inventory.rst:110 -msgid "Inventory plugins that support caching can use the general settings for the fact cache defined in the ``ansible.cfg`` file's ``[defaults]`` section or define inventory-specific settings in the ``[inventory]`` section. Individual plugins can define plugin-specific cache settings in their config file:" -msgstr "キャッシュをサポートする inventory プラグインは、``ansible.cfg`` ファイルの ``[defaults]`` セクションに定義されたファクトキャッシュの一般設定を使用するか、``[inventory]`` セクションにインベントリー固有の設定を定義することができます。個々のプラグインは、設定ファイルでプラグイン固有のキャッシュ設定を定義できます。" - -#: ../../rst/plugins/inventory.rst:122 -msgid "Here is an example of setting inventory caching with some fact caching defaults for the cache plugin used and the timeout in an ``ansible.cfg`` file:" -msgstr "以下は、``ansible.cfg`` ファイルに、使用する cache プラグインにデフォルト設定されているファクトキャッシュの一部を使用したインベントリーキャッシュと、タイムアウトを設定する例です。" - -#: ../../rst/plugins/inventory.rst:140 -msgid "You can use ``ansible-doc -t inventory -l`` to see the list of available plugins. Use ``ansible-doc -t inventory `` to see plugin-specific documentation and examples." -msgstr "``ansible-doc -t inventory -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t inventory `` を使用して、プラグイン固有のドキュメントと例を参照してください。" - -#: ../../rst/plugins/lookup.rst:4 -msgid "Lookup Plugins" -msgstr "lookup プラグイン" - -#: ../../rst/plugins/lookup.rst:10 -msgid "Lookup plugins are an Ansible-specific extension to the Jinja2 templating language. You can use lookup plugins to access data from outside sources (files, databases, key/value stores, APIs, and other services) within your playbooks. Like all :ref:`templating `, lookups execute and are evaluated on the Ansible control machine. Ansible makes the data returned by a lookup plugin available using the standard templating system. You can use lookup plugins to load variables or templates with information from external sources." -msgstr "lookup プラグインは、Jinja2 テンプレート言語への Ansible 固有の拡張です。lookup プラグインを使用して、Playbook 内の外部ソース (ファイル、データベース、キー/値のストア、API、その他のサービス) からデータにアクセスできます。:ref:`templating ` はすべて、Ansible 制御マシンで lookup を実行し、評価されます。Ansible は、標準の一時システムで利用可能な lookup プラグインにより返されたデータを提供します。lookup プラグインを使用すると、変数やテンプレートに外部ソースからの情報を読み込むことができます。" - -#: ../../rst/plugins/lookup.rst:13 -msgid "Lookups are executed with a working directory relative to the role or play, as opposed to local tasks, which are executed relative the executed script." -msgstr "ルックアップは、ロールやプレイに相対する作業ディレクトリーで実行されます。一方、ローカルタスクは、実行されたスクリプトに相対して実行されます。" - -#: ../../rst/plugins/lookup.rst:15 -msgid "Pass ``wantlist=True`` to lookups to use in Jinja2 template \"for\" loops." -msgstr "``wantlist=True`` を lookup に渡して、Jinja2 テンプレート「for」ループで使用できます。" - -#: ../../rst/plugins/lookup.rst:18 -msgid "Some lookups pass arguments to a shell. When using variables from a remote/untrusted source, use the `|quote` filter to ensure safe usage." -msgstr "ルックアップの中には、シェルに引数を渡すものがあります。リモート/信頼されていないソースから変数を使用する場合には、`|quote` フィルターを使用して、安全に使用できるようにします。" - -#: ../../rst/plugins/lookup.rst:24 -msgid "Enabling lookup plugins" -msgstr "lookup プラグインの有効化" - -#: ../../rst/plugins/lookup.rst:26 -msgid "Ansible enables all lookup plugins it can find. You can activate a custom lookup by either dropping it into a ``lookup_plugins`` directory adjacent to your play, inside the ``plugins/lookup/`` directory of a collection you have installed, inside a standalone role, or in one of the lookup directory sources configured in :ref:`ansible.cfg `." -msgstr "Ansibleは、検出したすべての lookup プラグインを有効にします。カスタム lookup を有効にするには、プレイに隣接する ``lookup_plugins`` ディレクトリー、インストールしたコレクションの ``plugins/lookup/`` ディレクトリー、スタンドアロンロール、または :ref:`ansible.cfg ` で設定したルックアップディレクトリソースのいずれかに置きます。" - -#: ../../rst/plugins/lookup.rst:32 -msgid "Using lookup plugins" -msgstr "lookup プラグインの使用" - -#: ../../rst/plugins/lookup.rst:34 -msgid "You can use lookup plugins anywhere you can use templating in Ansible: in a play, in variables file, or in a Jinja2 template for the :ref:`template ` module." -msgstr "lookup プラグインは、Ansible でテンプレートを使用できる場所で使用できます。これはプレイ、変数ファイル、または :ref:`template ` モジュールの Jinja2 テンプレートで使用できます。" - -#: ../../rst/plugins/lookup.rst:41 -msgid "Lookups are an integral part of loops. Wherever you see ``with_``, the part after the underscore is the name of a lookup. For this reason, most lookups output lists and take lists as input; for example, ``with_items`` uses the :ref:`items ` lookup::" -msgstr "lookups はループには欠かせない要素です。``with_`` と表示される場合は、アンダースコアの後の部分がルックアップの名前になります。ほとんどのルックアップはリストを出力し、入力としてリストを受け取ります。たとえば、``with_items`` は :ref:`items ` lookup を使用します::" - -#: ../../rst/plugins/lookup.rst:48 -msgid "You can combine lookups with :ref:`filters `, :ref:`tests ` and even each other to do some complex data generation and manipulation. For example::" -msgstr "lookup と :ref:`filters `、:ref:`tests `、またはそれぞれを組み合わせて複雑なデータ生成やデータ操作が可能です。以下に例を示します。" - -#: ../../rst/plugins/lookup.rst:60 -msgid "You can control how errors behave in all lookup plugins by setting ``errors`` to ``ignore``, ``warn``, or ``strict``. The default setting is ``strict``, which causes the task to fail if the lookup returns an error. For example:" -msgstr "``errors`` を ``ignore``、``warn``、または ``strict`` に設定して、すべての lookup プラグインでエラーの動作を制御できます。デフォルト設定は ``strict`` で、lookup がエラーを返すとタスクは失敗します。以下に例を示します。" - -#: ../../rst/plugins/lookup.rst:62 -msgid "To ignore lookup errors::" -msgstr "ルックアップエラーを無視するには、以下を行います。" - -#: ../../rst/plugins/lookup.rst:76 -msgid "To get a warning instead of a failure::" -msgstr "失敗させるのではなく警告を出すには、以下を使用します。" - -#: ../../rst/plugins/lookup.rst:92 -msgid "To get a fatal error (the default)::" -msgstr "致命的なエラーを取得する (デフォルト) には、以下を行います::" - -#: ../../rst/plugins/lookup.rst:107 -msgid "Forcing lookups to return lists: ``query`` and ``wantlist=True``" -msgstr "ルックアップが強制的にリストを返すようにする： ``query`` および ``wantlist=True``" - -#: ../../rst/plugins/lookup.rst:111 -msgid "In Ansible 2.5, a new Jinja2 function called ``query`` was added for invoking lookup plugins. The difference between ``lookup`` and ``query`` is largely that ``query`` will always return a list. The default behavior of ``lookup`` is to return a string of comma separated values. ``lookup`` can be explicitly configured to return a list using ``wantlist=True``." -msgstr "Ansible 2.5 では、lookup プラグインを呼び出すために ``query`` と呼ばれる新しい Jinja2 関数が追加されました。``lookup`` と ``query`` の相違点は、``query`` が常にリストを返すことです。``lookup`` のデフォルト動作は、コンマ区切りの値の文字列を返すことです。``lookup`` は、``wantlist=True`` を使用してリストを返すように明示的に設定できます。" - -#: ../../rst/plugins/lookup.rst:114 -msgid "This feature provides an easier and more consistent interface for interacting with the new ``loop`` keyword, while maintaining backwards compatibility with other uses of ``lookup``." -msgstr "この機能により、新しい ``loop`` キーワードを操作するための、より簡単で一貫性のあるインターフェースが提供され、同時に``lookup`` の他の使い方との後方互換性も維持されます。" - -#: ../../rst/plugins/lookup.rst:116 -msgid "The following examples are equivalent:" -msgstr "以下の例はどちらも同等の操作ができます。" - -#: ../../rst/plugins/lookup.rst:124 -msgid "As demonstrated above, the behavior of ``wantlist=True`` is implicit when using ``query``." -msgstr "上記の例のように、``query`` を使用する場合、``wantlist=True`` の動作は暗黙的になります。" - -#: ../../rst/plugins/lookup.rst:126 -msgid "Additionally, ``q`` was introduced as a shortform of ``query``:" -msgstr "また、``query`` の短縮形となる ``q`` が導入されました。" - -#: ../../rst/plugins/lookup.rst:138 -msgid "You can use ``ansible-doc -t lookup -l`` to see the list of available plugins. Use ``ansible-doc -t lookup `` to see specific documents and examples." -msgstr "``ansible-doc -t lookup -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t lookup `` を使用して、特定のドキュメントと例を参照してください。" - -#: ../../rst/plugins/netconf.rst:4 -msgid "Netconf Plugins" -msgstr "netconf プラグイン" - -#: ../../rst/plugins/netconf.rst:10 -msgid "Netconf plugins are abstractions over the Netconf interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices." -msgstr "netconf プラグインは、ネットワークデバイスへの Netconf インターフェイスを介した抽象化です。これらは、Ansible がこれらのネットワークデバイスでタスクを実行するための標準インターフェースを提供します。" - -#: ../../rst/plugins/netconf.rst:12 -msgid "These plugins generally correspond one-to-one to network device platforms. Ansible loads the appropriate netconf plugin automatically based on the ``ansible_network_os`` variable. If the platform supports standard Netconf implementation as defined in the Netconf RFC specification, Ansible loads the ``default`` netconf plugin. If the platform supports propriety Netconf RPCs, Ansible loads the platform-specific netconf plugin." -msgstr "これらのプラグインは通常、ネットワークデバイスプラットフォームに 1 対 1 に対応します。Ansible は ``ansible_network_os`` 変数に基づいて適切な netconf プラグインを自動的に読み込みます。プラットフォームが Netconf の RFC 仕様で定義されている標準の Netconf 実装をサポートする場合、Ansible は ``default`` netconf プラグインを読み込みます。プラットフォームがプロプライエタリーな Netconf RPC をサポートする場合、Ansible はプラットフォーム固有の netconf プラグインを読み込みます。" - -#: ../../rst/plugins/netconf.rst:17 -msgid "Adding netconf plugins" -msgstr "netconf プラグインの追加" - -#: ../../rst/plugins/netconf.rst:19 -msgid "You can extend Ansible to support other network devices by dropping a custom plugin into the ``netconf_plugins`` directory." -msgstr "``netconf_plugins`` ディレクトリーにカスタムのプラグインを置いて、Ansible が他のネットワークデバイスをサポートするように拡張できます。" - -#: ../../rst/plugins/netconf.rst:24 -msgid "Using netconf plugins" -msgstr "netconf プラグインの使用" - -#: ../../rst/plugins/netconf.rst:26 -msgid "The netconf plugin to use is determined automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality." -msgstr "使用する netconf プラグインは ``ansible_network_os`` 変数から自動的に決定されます。この機能を上書きする理由はありません。" - -#: ../../rst/plugins/netconf.rst:28 -msgid "Most netconf plugins can operate without configuration. A few have additional options that can be set to affect how tasks are translated into netconf commands. A ncclient device specific handler name can be set in the netconf plugin or else the value of ``default`` is used as per ncclient device handler." -msgstr "ほとんどの netconf プラグインは設定せずに動作します。タスクがどのように netconf コマンドに変換されるかに影響を与えるように設定できる追加オプションがいくつかあります。ncclient デバイス固有のハンドラー名は netconf プラグインで設定するか、ncclient デバイスハンドラーごとに ``default`` の値を使用することができます。" - -#: ../../rst/plugins/netconf.rst:35 -msgid "Listing netconf plugins" -msgstr "netconf プラグインの一覧表示" - -#: ../../rst/plugins/netconf.rst:37 -msgid "These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several netconf plugins. To list all available netconf plugins on your control node, type ``ansible-doc -t netconf -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t netconf``." -msgstr "これらのプラグインは `Ansible Galaxy `_ のコレクションに移行しました。``pip`` を使用して Ansible バージョン 2.10 以降をインストールしている場合は、複数の netconf プラグインにアクセスできます。コントロールノードで利用可能な netconf プラグインの一覧を表示するには、``ansible-doc -t netconf -l`` と入力します。プラグイン固有のドキュメントと例を確認するには、``ansible-doc -t netconf`` を使用します。" - -#: ../../rst/plugins/plugins.rst:5 -msgid "Working With Plugins" -msgstr "プラグインの使用" - -#: ../../rst/plugins/plugins.rst:7 -msgid "Plugins are pieces of code that augment Ansible's core functionality. Ansible uses a plugin architecture to enable a rich, flexible and expandable feature set." -msgstr "プラグインは、Ansible のコア機能を拡張するコードの一部です。Ansible はプラグインアーキテクチャーを使用して、豊富で柔軟な拡張性のある機能セットを実現しています。" - -#: ../../rst/plugins/plugins.rst:9 -msgid "Ansible ships with a number of handy plugins, and you can easily write your own." -msgstr "Ansible には、便利なプラグインが多数同梱されています。また、簡単に独自のプラグインを作成することもできます。" - -#: ../../rst/plugins/plugins.rst:11 -msgid "This section covers the various types of plugins that are included with Ansible:" -msgstr "本セクションでは、Ansible に含まれるさまざまなプラグインを説明します。" - -#: ../../rst/plugins/plugins.rst:37 -msgid ":ref:`ansible_configuration_settings`" -msgstr ":ref:`ansible_configuration_settings`" - -#: ../../rst/plugins/plugins.rst:38 -msgid "Ansible configuration documentation and settings" -msgstr "Ansible 設定ドキュメントおよび設定" - -#: ../../rst/plugins/plugins.rst:39 -msgid ":ref:`command_line_tools`" -msgstr ":ref:`command_line_tools`" - -#: ../../rst/plugins/plugins.rst:40 -msgid "Ansible tools, description and options" -msgstr "Ansible ツール、説明、およびオプション" - -#: ../../rst/plugins/shell.rst:4 -msgid "Shell Plugins" -msgstr "shell プラグイン" - -#: ../../rst/plugins/shell.rst:10 -msgid "Shell plugins work to ensure that the basic commands Ansible runs are properly formatted to work with the target machine and allow the user to configure certain behaviors related to how Ansible executes tasks." -msgstr "shell プラグインは、Ansible が実行する基本的なコマンドが正しくフォーマットされ、ターゲットマシンと連携し、Ansible のタスク実行方法に関連する特定の動作を設定できるように機能します。" - -#: ../../rst/plugins/shell.rst:16 -msgid "Enabling shell plugins" -msgstr "shell プラグインの有効化" - -#: ../../rst/plugins/shell.rst:18 -msgid "You can add a custom shell plugin by dropping it into a ``shell_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the shell plugin directory sources configured in :ref:`ansible.cfg `." -msgstr "カスタムの shell プラグインを追加するには、そのプラグインを、ロール内のプレイの隣りにある ``shell_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg ` で設定したディレクトリーソースの 1 つに置きます。" - -#: ../../rst/plugins/shell.rst:21 -msgid "You should not alter which plugin is used unless you have a setup in which the default ``/bin/sh`` is not a POSIX compatible shell or is not available for execution." -msgstr "デフォルトの ``/bin/sh`` が POSIX に準拠していないシェルで、実行に利用できない場合以外は、使用するプラグインを変更するべきではありません。" - -#: ../../rst/plugins/shell.rst:27 -msgid "Using shell plugins" -msgstr "shell プラグインの使用" - -#: ../../rst/plugins/shell.rst:29 -msgid "In addition to the default configuration settings in :ref:`ansible_configuration_settings`, you can use the connection variable :ref:`ansible_shell_type ` to select the plugin to use. In this case, you will also want to update the :ref:`ansible_shell_executable ` to match." -msgstr ":ref:`ansible_configuration_settings` のデフォルト設定に加えて、接続プロファイル :ref:`ansible_shell_type ` を使用して、使用するプラグインを選択できます。この場合は、一致するように :ref:`ansible_shell_executable ` も更新します。" - -#: ../../rst/plugins/strategy.rst:4 -msgid "Strategy Plugins" -msgstr "strategy プラグイン" - -#: ../../rst/plugins/strategy.rst:10 -msgid "Strategy plugins control the flow of play execution by handling task and host scheduling." -msgstr "strategy プラグインは、タスクおよびホストスケジューリングを処理し、プレイ実行のフローを制御します。" - -#: ../../rst/plugins/strategy.rst:15 -msgid "Enabling strategy plugins" -msgstr "strategy プラグインの有効化" - -#: ../../rst/plugins/strategy.rst:17 -msgid "All strategy plugins shipped with Ansible are enabled by default. You can enable a custom strategy plugin by putting it in one of the lookup directory sources configured in :ref:`ansible.cfg `." -msgstr "Ansible に同梱されているすべての strategy プラグインは、デフォルトで有効になっています。カスタムの strategy プラグインを有効にするには、:ref:`ansible.cfg ` で設定したルックアップディレクトリーソースの 1 つにそれを置きます。" - -#: ../../rst/plugins/strategy.rst:23 -msgid "Using strategy plugins" -msgstr "strategy プラグインの使用" - -#: ../../rst/plugins/strategy.rst:25 -msgid "Only one strategy plugin can be used in a play, but you can use different ones for each play in a playbook or ansible run. The default is the :ref:`linear ` plugin. You can change this default in Ansible :ref:`configuration ` using an environment variable:" -msgstr "プレイで使用できる strategy プラグインは 1 つだけですが、Playbook または ansible の実行でプレイごとに異なるプラグインを使用できます。デフォルトは :ref:`linear ` プラグインです。環境変数を使用して、Ansible :ref:`configuration ` でこのデフォルトを変更できます。" - -#: ../../rst/plugins/strategy.rst:32 -msgid "or in the `ansible.cfg` file:" -msgstr "または `ansible.cfg` ファイルで、以下を行います。" - -#: ../../rst/plugins/strategy.rst:39 -msgid "You can also specify the strategy plugin in the play via the :ref:`strategy keyword ` in a play::" -msgstr "プレイの :ref:`strategy キーワード ` を使用して、プレイの strategy プラグインを指定できます。" - -#: ../../rst/plugins/strategy.rst:58 -msgid "You can use ``ansible-doc -t strategy -l`` to see the list of available plugins. Use ``ansible-doc -t strategy `` to see plugin-specific specific documentation and examples." -msgstr "``ansible-doc -t strategy -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t strategy `` を使用して、プラグイン固有のドキュメントと例を参照してください。" - -#: ../../rst/plugins/vars.rst:4 -msgid "Vars Plugins" -msgstr "vars プラグイン" - -#: ../../rst/plugins/vars.rst:10 -msgid "Vars plugins inject additional variable data into Ansible runs that did not come from an inventory source, playbook, or command line. Playbook constructs like 'host_vars' and 'group_vars' work using vars plugins." -msgstr "Vars プラグインは、インベントリーソース、Playbook、またはコマンドラインに組み込まれていない Ansible の実行に、変数データを追加します。「host_vars」や「group_vars」のような Playbook の構成要素は、vars プラグインを使用します。" - -#: ../../rst/plugins/vars.rst:12 -msgid "Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4." -msgstr "vars プラグインは Ansible 2.0 に部分的に実装され、Ansible 2.4 以降では、完全実装になるように書き直されました。" - -#: ../../rst/plugins/vars.rst:14 -msgid "The :ref:`host_group_vars ` plugin shipped with Ansible enables reading variables from :ref:`host_variables` and :ref:`group_variables`." -msgstr "Ansible に同梱される :ref:`host_group_vars ` プラグインは、:ref:`host_variables` および :ref:`group_variables` から変数の読み取りを可能にします。" - -#: ../../rst/plugins/vars.rst:20 -msgid "Enabling vars plugins" -msgstr "vars プラグインの有効化" - -#: ../../rst/plugins/vars.rst:22 -msgid "You can activate a custom vars plugin by either dropping it into a ``vars_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the directory sources configured in :ref:`ansible.cfg `." -msgstr "カスタムの vars プラグインを有効にするには、カスタムのプラグインを、ロール内のプレイの隣りにある ``vars_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg ` で設定したディレクトリーソースの 1 つに置きます。" - -#: ../../rst/plugins/vars.rst:24 -msgid "Most vars plugins are disabled by default. To enable a vars plugin, set ``vars_plugins_enabled`` in the ``defaults`` section of :ref:`ansible.cfg ` or set the ``ANSIBLE_VARS_ENABLED`` environment variable to the list of vars plugins you want to execute. By default, the :ref:`host_group_vars ` plugin shipped with Ansible is enabled." -msgstr "ほとんどの vars プラグインはデフォルトで無効になっています。vars プラグインを有効にするには、:ref:`ansible.cfg ` の ``defaults`` セクションで ``vars_plugins_enabled`` を設定するか、実行する vars プラグインの一覧に ``ANSIBLE_VARS_ENABLED`` 環境変数を設定します。デフォルトでは、Ansible に同梱される :ref:`host_group_vars ` プラグインが有効になっています。" - -#: ../../rst/plugins/vars.rst:26 -msgid "Starting in Ansible 2.10, you can use vars plugins in collections. All vars plugins in collections must be explicitly enabled and must use the fully qualified collection name in the format ``namespace.collection_name.vars_plugin_name``." -msgstr "Ansible 2.10 以降では、コレクションで vars プラグインを使用できます。コレクションのすべての vars プラグインは明示的に有効で、``namespace.collection_name.vars_plugin_name`` 形式で完全修飾コレクション名を使用する必要があります。" - -#: ../../rst/plugins/vars.rst:36 -msgid "Using vars plugins" -msgstr "vars プラグインの使用" - -#: ../../rst/plugins/vars.rst:38 -msgid "By default, vars plugins are used on demand automatically after they are enabled." -msgstr "デフォルトでは、vars プラグインは、有効になった後に自動的にオンデマンドで使用されます。" - -#: ../../rst/plugins/vars.rst:40 -msgid "Starting in Ansible 2.10, vars plugins can be made to run at specific times. `ansible-inventory` does not use these settings, and always loads vars plugins." -msgstr "Ansible 2.10 以降、vars プラグインは特定のタイミングで実行できます。`ansible-inventory` はこれらの設定を使用せず、常に vars プラグインを読み込みます。" - -#: ../../rst/plugins/vars.rst:42 -msgid "The global setting ``RUN_VARS_PLUGINS`` can be set in ``ansible.cfg`` using ``run_vars_plugins`` in the ``defaults`` section or by the ``ANSIBLE_RUN_VARS_PLUGINS`` environment variable. The default option, ``demand``, runs any enabled vars plugins relative to inventory sources whenever variables are demanded by tasks. You can use the option ``start`` to run any enabled vars plugins relative to inventory sources after importing that inventory source instead." -msgstr "グローバル設定 ``RUN_VARS_PLUGINS`` は、``defaults`` セクションの ``run_vars_plugins`` を使用して、または ``ANSIBLE_RUN_VARS_PLUGINS`` 環境変数により、``ansible.cfg``に設定できます。デフォルトのオプションである ``demand`` は、タスクで変数が必要となった場合には必ず、インベントリーソースに対して有効なVars プラグインを実行します。代わりに、インベントリーソースをインポートした後に、``start`` オプションを使用して、インベントリーソースと相対的な位置にある、有効化された Vars プラグインを実行できます。" - -#: ../../rst/plugins/vars.rst:44 -msgid "You can also control vars plugin execution on a per-plugin basis for vars plugins that support the ``stage`` option. To run the :ref:`host_group_vars ` plugin after importing inventory you can add the following to :ref:`ansible.cfg `:" -msgstr "また、``stage`` オプションをサポートする vars プラグインの場合は、プラグインごとに vars プラグインの実行を制御することもできます。インベントリーのインポート後に :ref:`host_group_vars ` プラグインを実行するには、以下を :ref:`ansible.cfg ` に追加します:" - -#: ../../rst/plugins/vars.rst:54 -msgid "Plugin Lists" -msgstr "プラグイン一覧" - -#: ../../rst/plugins/vars.rst:56 -msgid "You can use ``ansible-doc -t vars -l`` to see the list of available plugins. Use ``ansible-doc -t vars `` to see specific plugin-specific documentation and examples." -msgstr "``ansible-doc -t vars -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t vars `` を使用して、プラグイン固有のドキュメントと例を参照してください。" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/porting_guides.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/porting_guides.po deleted file mode 100644 index d9e9c037675..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/porting_guides.po +++ /dev/null @@ -1,6677 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-03-08 20:25+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/porting_guides/core_porting_guides.rst:5 -msgid "Ansible Core Porting Guides" -msgstr "Ansible Core 移植ガイド" - -#: ../../rst/porting_guides/core_porting_guides.rst:7 -msgid "This section lists porting guides that can help you in updating playbooks, plugins and other parts of your Ansible infrastructure from one version of ``ansible-core`` to the next." -msgstr "本セクションでは、``ansible-core`` のあるバージョンから次のバージョンに、Ansible インフラストラクチャーの Playbook、プラグインなどを更新するのに役に立つ移植ガイドを紹介します。" - -#: ../../rst/porting_guides/core_porting_guides.rst:9 -msgid "Please note that this is not a complete list. If you believe any extra information would be useful in these pages, you can edit by clicking `Edit on GitHub` on the top right, or raising an issue." -msgstr "これは完全な一覧ではないことに注意してください。以下のページに役に立つ追加情報をお持ちの場合は、右上の「`Edit on GitHub`」をクリックするか、問題を報告することで編集が可能になります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:6 -msgid "Ansible 2.0 Porting Guide" -msgstr "Ansible 2.0 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:8 -msgid "This section discusses the behavioral changes between Ansible 1.x and Ansible 2.0." -msgstr "このセクションでは、Ansible 1.x から Ansible 2.0 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:10 -#: ../../rst/porting_guides/porting_guide_2.10.rst:16 -#: ../../rst/porting_guides/porting_guide_2.3.rst:10 -#: ../../rst/porting_guides/porting_guide_2.4.rst:10 -#: ../../rst/porting_guides/porting_guide_2.5.rst:9 -#: ../../rst/porting_guides/porting_guide_2.6.rst:9 -#: ../../rst/porting_guides/porting_guide_2.7.rst:9 -#: ../../rst/porting_guides/porting_guide_2.8.rst:9 -#: ../../rst/porting_guides/porting_guide_2.9.rst:10 -msgid "It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible." -msgstr "本ガイドは、このバージョンの Ansible で動作するように、Playbook、プラグイン、その他の Ansible インフラストラクチャーを更新する際にご利用になります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:13 -msgid "We suggest you read this page along with `Ansible Changelog for 2.0 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.0 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:15 -#: ../../rst/porting_guides/porting_guide_2.3.rst:15 -#: ../../rst/porting_guides/porting_guide_2.4.rst:15 -#: ../../rst/porting_guides/porting_guide_2.5.rst:13 -#: ../../rst/porting_guides/porting_guide_2.6.rst:13 -#: ../../rst/porting_guides/porting_guide_2.7.rst:13 -#: ../../rst/porting_guides/porting_guide_2.8.rst:13 -#: ../../rst/porting_guides/porting_guide_2.9.rst:14 -msgid "This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `." -msgstr "このドキュメントは、移植に関する内容の一部です。移植の完全なリストは「:ref:`移植ガイド `」にあります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:17 -#: ../../rst/porting_guides/porting_guide_2.3.rst:17 -#: ../../rst/porting_guides/porting_guide_2.4.rst:17 -#: ../../rst/porting_guides/porting_guide_2.5.rst:15 -#: ../../rst/porting_guides/porting_guide_2.6.rst:15 -#: ../../rst/porting_guides/porting_guide_2.7.rst:15 -#: ../../rst/porting_guides/porting_guide_2.9.rst:17 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:20 -#: ../../rst/porting_guides/porting_guide_2.10.rst:33 -#: ../../rst/porting_guides/porting_guide_2.3.rst:20 -#: ../../rst/porting_guides/porting_guide_2.5.rst:18 -#: ../../rst/porting_guides/porting_guide_2.6.rst:18 -#: ../../rst/porting_guides/porting_guide_2.7.rst:54 -#: ../../rst/porting_guides/porting_guide_2.8.rst:19 -#: ../../rst/porting_guides/porting_guide_2.9.rst:20 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:26 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:21 -msgid "Playbook" -msgstr "Playbook" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:22 -msgid "This section discusses any changes you may need to make to your playbooks." -msgstr "本セクションでは、Playbook に加える必要のある変更を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:36 -msgid "To make an escaped string that will work on all versions you have two options::" -msgstr "すべてのバージョンで機能するエスケープされた文字列を作成するには、2 つのオプションがあります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:40 -msgid "uses key=value escaping which has not changed. The other option is to check for the ansible version::" -msgstr "key=value エスケープを使用しますが、これは、変更されていません。もう 1 つの方法は、ansible のバージョンを確認することです。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:44 -msgid "trailing newline When a string with a trailing newline was specified in the playbook via yaml dict format, the trailing newline was stripped. When specified in key=value format, the trailing newlines were kept. In v2, both methods of specifying the string will keep the trailing newlines. If you relied on the trailing newline being stripped, you can change your playbook using the following as an example::" -msgstr "末尾に改行: 末尾に改行がある文字列が yaml dict 形式で Playbook に指定されている場合、末尾の改行は削除されます。key=value 形式で指定すると、末尾に改行が保持されます。v2 では、この文字列を指定するメソッドはともに改行を保持します。末尾の改行が自動的に削除されるのに依存していた場合は、以下のように Playbook を変更できます。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:71 -msgid "Behavior of templating DOS-type text files changes with Ansible v2." -msgstr "DOS タイプのテキストファイルをテンプレート化する動作は Ansible v2 で変わります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:73 -msgid "A bug in Ansible v1 causes DOS-type text files (using a carriage return and newline) to be templated to Unix-type text files (using only a newline). In Ansible v2 this long-standing bug was finally fixed and DOS-type text files are preserved correctly. This may be confusing when you expect your playbook to not show any differences when migrating to Ansible v2, while in fact you will see every DOS-type file being completely replaced (with what appears to be the exact same content)." -msgstr "Ansible v1 のバグにより、DOS タイプのテキストファイル (キャリッジリターンと改行を使用) が、Unix タイプのテキストファイル (改行のみを使用) にテンプレート化していました。Ansible v2 では、この長年のバグがようやく修正され、DOS 形式のテキストファイルが正しく保存されるようになりました。これは、Ansible v2 への移行時に Playbook に変更がないことを期待している場合には混乱するかもしれませんが、実際には、すべての DOS 型ファイルが完全に置き換えられています (ただし、完全に同一の内容であるように表示される場合があります)。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:75 -msgid "When specifying complex args as a variable, the variable must use the full jinja2 variable syntax (```{{var_name}}```) - bare variable names there are no longer accepted. In fact, even specifying args with variables has been deprecated, and will not be allowed in future versions::" -msgstr "複雑な引数を変数として指定する場合、変数は完全な jinja2 変数構文 (```{{var_name}}```) を使用する必要があります。ベア変数名は使用できなくなりました。実際、変数で引数を指定することが非推奨となっており、将来のバージョンでは使用できなくなります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:93 -msgid "porting task includes" -msgstr "移植タスクに含まれるもの" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:94 -msgid "More dynamic. Corner-case formats that were not supposed to work now do not, as expected." -msgstr "より動的に。動作すると想定していなかったコーナーケース (めったに発生しない厄介なケース) の形式が、期待通りに動作しなくなります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:95 -msgid "variables defined in the yaml dict format https://github.com/ansible/ansible/issues/13324" -msgstr "yaml の dict 形式で定義される変数 (https://github.com/ansible/ansible/issues/13324)" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:96 -msgid "templating (variables in playbooks and template lookups) has improved with regard to keeping the original instead of turning everything into a string. If you need the old behavior, quote the value to pass it around as a string." -msgstr "テンプレート化 (Playbook およびテンプレート検索の変数) は、すべてを文字列にするのではなく、オリジナルを維持するという点で改善されました。以前の動作が必要な場合は、値を引用符で囲み、文字列として渡してください。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:98 -msgid "Empty variables and variables set to null in yaml are no longer converted to empty strings. They will retain the value of `None`. You can override the `null_representation` setting to an empty string in your config file by setting the :envvar:`ANSIBLE_NULL_REPRESENTATION` environment variable." -msgstr "空の変数と、yaml で null に設定された変数は、空の文字列に変換されなくなり、`None` の値を維持します。環境変数 :envvar:`ANSIBLE_NULL_REPRESENTATION` を設定することで、設定ファイルで `null_representation` が空文字列に設定されるのを上書きすることができます。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:100 -msgid "Extras callbacks must be enabled in ansible.cfg. Copying is no longer necessary but you must enable them in ansible.cfg." -msgstr "ansible.cfg で追加のコールバックを有効にする必要があります。コピーは不要になりますが、ansible.cfg で有効にする必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:101 -msgid "dnf module has been rewritten. Some minor changes in behavior may be observed." -msgstr "dnf モジュールが書き直されました。いくつかの細かい動作の変更があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:102 -msgid "win_updates has been rewritten and works as expected now." -msgstr "win_updates は書き直され、期待通りに動作するようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:103 -msgid "from 2.0.1 onwards, the implicit setup task from gather_facts now correctly inherits everything from play, but this might cause issues for those setting `environment` at the play level and depending on `ansible_env` existing. Previously this was ignored but now might issue an 'Undefined' error." -msgstr "2.0.1 以降、gather_facts の暗黙的な設定タスクは、プレイからすべて正しく継承されるようになりましたが、これにより、プレイレベルで `environment` を設定し、`ansible_env` の存在に依存している場合に問題が発生する可能性がありましたが、以前はこの問題は無視されていました。これからは「Undefined」エラーが発生する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:107 -#: ../../rst/porting_guides/porting_guide_2.10.rst:51 -#: ../../rst/porting_guides/porting_guide_2.4.rst:52 -#: ../../rst/porting_guides/porting_guide_2.5.rst:101 -#: ../../rst/porting_guides/porting_guide_2.6.rst:23 -#: ../../rst/porting_guides/porting_guide_2.7.rst:104 -#: ../../rst/porting_guides/porting_guide_2.8.rst:325 -#: ../../rst/porting_guides/porting_guide_2.9.rst:43 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:44 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:44 -msgid "Deprecated" -msgstr "非推奨" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:109 -msgid "While all items listed here will show a deprecation warning message, they still work as they did in 1.9.x. Please note that they will be removed in 2.2 (Ansible always waits two major releases to remove a deprecated feature)." -msgstr "ここに掲載されているすべての項目には、非推奨の警告メッセージが表示されますが、1.9.x での動作と同じ動作になります。ただし、2.2 で削除されることに注意してください (Ansible は常に 2 つのメジャーリリースを待ってから非推奨の機能を削除します)。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:111 -msgid "Bare variables in ``with_`` loops should instead use the ``\"{{ var }}\"`` syntax, which helps eliminate ambiguity." -msgstr "``with_`` ループ内のベア変数は、代わりに ``\"{{ var }}\"`` 構文を使用する必要があります。これにより、曖昧さがなくなります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:112 -msgid "The ansible-galaxy text format requirements file. Users should use the YAML format for requirements instead." -msgstr "ansible-galaxy テキスト形式の要件ファイル。ユーザーは、代わりに要件に YAML 形式を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:113 -msgid "Undefined variables within a ``with_`` loop's list currently do not interrupt the loop, but they do issue a warning; in the future, they will issue an error." -msgstr "``with_`` ループのリストに含まれる未定義の変数は、現在のところループを中断することはありませんが、警告を出力します。今後はエラーを出力します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:114 -msgid "Using dictionary variables to set all task parameters is unsafe and will be removed in a future version. For example::" -msgstr "ディクショナリー変数を使用してすべてのタスクパラメーターを設定することは安全ではないため、将来のバージョンでは削除される予定です。以下に例を示します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:131 -msgid "Host patterns should use a comma (,) or colon (:) instead of a semicolon (;) to separate hosts/groups in the pattern." -msgstr "ホストパターンで、パターン内のホスト/グループを分離する場合は、セミコロン (;) の代わりにコンマ (,) またはコロン (:) を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:132 -msgid "Ranges specified in host patterns should use the [x:y] syntax, instead of [x-y]." -msgstr "ホストパターンで指定した範囲は、[x-y] 構文ではなく [x:y] 構文を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:133 -msgid "Playbooks using privilege escalation should always use \"become*\" options rather than the old su*/sudo* options." -msgstr "権限昇格を使用した Playbook は、古い su*/sudo* オプションではなく「become*」オプションを常に使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:134 -msgid "The \"short form\" for vars_prompt is no longer supported. For example::" -msgstr "vars_prompt の「短縮形」はサポートされなくなりました。以下に例を示します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:140 -msgid "Specifying variables at the top level of a task include statement is no longer supported. For example::" -msgstr "タスクのinclude 文の最上位で変数を指定することはサポートされなくなりました。たとえば次のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:145 -msgid "Should now be::" -msgstr "以下のようになるはずです。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:151 -msgid "Setting any_errors_fatal on a task is no longer supported. This should be set at the play level only." -msgstr "タスクで any_errors_fatal の設定がサポートされなくなりました。これはプレイレベルでのみ設定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:152 -msgid "Bare variables in the `environment` dictionary (for plays/tasks/etc.) are no longer supported. Variables specified there should use the full variable syntax: '{{foo}}'." -msgstr "`environment` ディクショナリー (プレイ、タスクなど) のベアメタル変数がサポートされなくなりました。指定される変数は、完全な変数構文 (「{{foo}}」) を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:153 -msgid "Tags (or any directive) should no longer be specified with other parameters in a task include. Instead, they should be specified as an option on the task. For example::" -msgstr "タグ (または他のディレクティブ) は、タスクのインクルードの中で他のパラメーターと一緒に指定しないでください。代わりに、タスクのオプションとして指定する必要があります。以下に例を示します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:158 -msgid "Should be::" -msgstr "以下のようになるはずです。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:163 -msgid "The first_available_file option on tasks has been deprecated. Users should use the with_first_found option or lookup ('first_found', …) plugin." -msgstr "タスクの first_available_file オプションが非推奨になりました。ユーザーは、with_first_found オプションまたは lookup ('first_found', …) プラグインを使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:167 -#: ../../rst/porting_guides/porting_guide_2.3.rst:100 -#: ../../rst/porting_guides/porting_guide_2.4.rst:72 -msgid "Other caveats" -msgstr "その他の注意事項" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:169 -msgid "Here are some corner cases encountered when updating. These are mostly caused by the more stringent parser validation and the capture of errors that were previously ignored." -msgstr "ここでは、更新時に遭遇するいくつかのコーナーケース (めったに発生しない厄介なケース) を紹介します。これらは主に、パーサーの検証がより厳しくなったことと、以前は無視されていたエラーが捕捉されたことが原因です。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:171 -msgid "Bad variable composition::" -msgstr "誤った変数の構成:" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:175 -msgid "This worked 'by accident' as the errors were retemplated and ended up resolving the variable, it was never intended as valid syntax and now properly returns an error, use the following instead.::" -msgstr "これは、エラーが再テンプレート化され、変数を解決することになったため、「偶然」機能しましたが、有効な構文として意図されたものではありませんでしたが、現在は適切にエラーを返しています。代わりに以下を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:179 -msgid "Misspelled directives::" -msgstr "スペルが間違っているディレクティブ:" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:184 -msgid "The task always ran without using privilege escalation (for that you need `become`) but was also silently ignored so the play 'ran' even though it should not, now this is a parsing error." -msgstr "タスクは常に、権限エスカレーションを使用せずに (`become` が必要なため) 実行されますが、通知なく無視されるために、プレイが実行させるべきでないにも関わらず「実行」されていましたが、これは解析エラーとなるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:187 -msgid "Duplicate directives::" -msgstr "重複ディレクティブ:" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:193 -msgid "The first `when` was ignored and only the 2nd one was used as the play ran w/o warning it was ignoring one of the directives, now this produces a parsing error." -msgstr "最初の `when` は無視され、2 つ目のものだけが使用されました。プレーは警告なしに実行され、ディレクティブの 1 つを無視していましたが、解析エラーが生成されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:195 -msgid "Conflating variables and directives::" -msgstr "変数およびディレクティブの制限::" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:202 -msgid "The `port` variable is reserved as a play/task directive for overriding the connection port, in previous versions this got conflated with a variable named `port` and was usable later in the play, this created issues if a host tried to reconnect or was using a non caching connection. Now it will be correctly identified as a directive and the `port` variable will appear as undefined, this now forces the use of non conflicting names and removes ambiguity when adding settings and variables to a role invocation." -msgstr "`port` 変数は、接続ポートを上書きするための play/task ディレクティブとして予約されています。以前のバージョンでは、`port` という名前の変数と融合し、後でプレイで使用できますが、そのホストが再接続をしようとしたり、非キャッシュ接続を使用していた場合にこの問題が発生します。今回のリリースより、ディレクティブとして正しく識別され、`port` 変数は未定義として表示されます。これにより、競合する名前を使用しないようにし、ロールの呼び出しに設定および変数を追加する際に曖昧さがなくなりました。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:206 -msgid "Bare operations on `with_`::" -msgstr "`with_` でのベア操作:" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:210 -msgid "An issue with the 'bare variable' features, which was supposed only template a single variable without the need of braces ({{ )}}, would in some versions of Ansible template full expressions. Now you need to use proper templating and braces for all expressions everywhere except conditionals (`when`)::" -msgstr "「ベア変数」関数の問題は、中括弧 ({{ )}} を必要としない単一の変数のみをテンプレート化することになっていましたが、Ansible の一部のバージョンでは完全な式をテンプレート化していました。現在では、条件式 (`when`) を除くすべての場所のすべての式に対して、適切なテンプレート化と中括弧を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:215 -msgid "The bare feature itself is deprecated as an undefined variable is indistinguishable from a string which makes it difficult to display a proper error." -msgstr "未定義の変数は文字列と区別がつかず、適切なエラーを表示することが難しいため、ベア関数自体が非推奨となっています。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:218 -msgid "Porting plugins" -msgstr "Porting プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:220 -msgid "In ansible-1.9.x, you would generally copy an existing plugin to create a new one. Simply implementing the methods and attributes that the caller of the plugin expected made it a plugin of that type. In ansible-2.0, most plugins are implemented by subclassing a base class for each plugin type. This way the custom plugin does not need to contain methods which are not customized." -msgstr "ansible-1.9.xでは、通常、既存のプラグインをコピーして新しいプラグインを作成します。プラグインの呼び出し元が期待するメソッドおよび属性を実装するだけで、そのタイプのプラグインになりました。ansible-2.0では、ほとんどのプラグインが、各プラグインタイプのベースクラスをサブクラス化することで実装されています。こうすることで、カスタムプラグインはカスタマイズされていないメソッドを含む必要がなくなります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:224 -#: ../../rst/porting_guides/porting_guide_2.0.rst:305 -msgid "Lookup plugins" -msgstr "Lookup プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:226 -msgid "lookup plugins ; import version" -msgstr "lookup プラグイン; バージョンのインポート" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:230 -#: ../../rst/porting_guides/porting_guide_2.0.rst:277 -#: ../../rst/porting_guides/porting_guide_2.0.rst:373 -#: ../../rst/porting_guides/porting_guide_2.0.rst:388 -msgid "Connection plugins" -msgstr "Connection プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:232 -#: ../../rst/porting_guides/porting_guide_2.0.rst:279 -#: ../../rst/porting_guides/porting_guide_2.0.rst:375 -#: ../../rst/porting_guides/porting_guide_2.0.rst:390 -msgid "connection plugins" -msgstr "connection プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:235 -#: ../../rst/porting_guides/porting_guide_2.0.rst:378 -msgid "Action plugins" -msgstr "Action プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:238 -#: ../../rst/porting_guides/porting_guide_2.0.rst:380 -msgid "action plugins" -msgstr "action プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:241 -#: ../../rst/porting_guides/porting_guide_2.0.rst:383 -#: ../../rst/porting_guides/porting_guide_2.4.rst:132 -msgid "Callback plugins" -msgstr "Callback プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:243 -msgid "Although Ansible 2.0 provides a new callback API the old one continues to work for most callback plugins. However, if your callback plugin makes use of :attr:`self.playbook`, :attr:`self.play`, or :attr:`self.task` then you will have to store the values for these yourself as ansible no longer automatically populates the callback with them. Here's a short snippet that shows you how:" -msgstr "Ansible 2.0 では新しいコールバック API が提供されていますが、ほとんどのコールバックプラグインでは古い API も引き続き使用できます。ただし、コールバックプラグインが :attr:`self.playbook`、:attr:`self.play`、または :attr:`self.task` を使用している場合は、ansible がコールバックに自動的に値を入力しなくなったため、これらの値を自分で保存する必要があります。ここでは、その方法を示す短いスニペットをご紹介します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:283 -msgid "Hybrid plugins" -msgstr "ハイブリッドプラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:285 -msgid "In specific cases you may want a plugin that supports both ansible-1.9.x *and* ansible-2.0. Much like porting plugins from v1 to v2, you need to understand how plugins work in each version and support both requirements." -msgstr "特定のケースでは、ansible-1.9.x *および* ansible-2.0 の両方をサポートするプラグインが必要になる場合があります。v1 から v2 へのプラグインの移植と同様に、各バージョンでプラグインがどのように機能し、両方の要件をサポートするかを理解する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:287 -msgid "Since the ansible-2.0 plugin system is more advanced, it is easier to adapt your plugin to provide similar pieces (subclasses, methods) for ansible-1.9.x as ansible-2.0 expects. This way your code will look a lot cleaner." -msgstr "ansible-2.0 プラグインシステムはより高度なため、ansible-2.0 が想定するとおりに、ansible-1.9.x の同様の部分 (サブクラス、メソッド) を提供するためにプラグインを調整することがより容易になります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:289 -msgid "You may find the following tips useful:" -msgstr "以下のヒントを参考にしてみてください。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:291 -msgid "Check whether the ansible-2.0 class(es) are available and if they are missing (ansible-1.9.x) mimic them with the needed methods (for example, ``__init__``)" -msgstr "ansible-2.0 のクラスが利用可能かどうかを確認し、クラスが不足している場合 (ansible-1.9.x) は、必要なメソッド (``__init__`` など) でそれらを模倣します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:293 -msgid "When ansible-2.0 python modules are imported, and they fail (ansible-1.9.x), catch the ``ImportError`` exception and perform the equivalent imports for ansible-1.9.x. With possible translations (for example, importing specific methods)." -msgstr "ansible-2.0 python モジュールをインポートして失敗すると (ansible-1.9.x)、``ImportError`` 例外を捕捉して、ansible-1.9.x の同等のインポートを実行します。翻訳 (たとえば、特定のメソッドをインポートすること) が行われることもあります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:295 -msgid "Use the existence of these methods as a qualifier to what version of Ansible you are running. So rather than using version checks, you can do capability checks instead. (See examples below)" -msgstr "これらのメソッドの存在を、実行中の Ansible バージョンへの修飾子として使用します。そのため、バージョンチェックを使用するのではなく、代わりに機能チェックを行うことができます (以下の例を参照)。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:297 -msgid "Document for each if-then-else case for which specific version each block is needed. This will help others to understand how they have to adapt their plugins, but it will also help you to remove the older ansible-1.9.x support when it is deprecated." -msgstr "各ブロックがどのバージョンで必要とされているか、if-then-else のケースごとに文書化します。これは、他の人が自分のプラグインをどのように適応させなければならないかを理解するのに役立つだけでなく、以前の ansible-1.9.x のサポートが非推奨になったときに削除するのに役立ちます。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:299 -msgid "When doing plugin development, it is very useful to have the ``warning()`` method during development, but it is also important to emit warnings for deadends (cases that you expect should never be triggered) or corner cases (for example, cases where you expect misconfigurations)." -msgstr "プラグインの開発を行う場合は、開発中に ``warning()`` メソッドがあると非常に便利ですが、デッドエンド (絶対に発生してはいけないと予想されるケース）やコーナーケース (めったに発生しない厄介なケース、たとえば設定が間違っている可能性があるケース) に対して警告を発することも重要です。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:301 -msgid "It helps to look at other plugins in ansible-1.9.x and ansible-2.0 to understand how the API works and what modules, classes and methods are available." -msgstr "API がどのように機能するか、どのようなモジュール、クラス、メソッドが利用できるかを理解するには、ansible-1.9.x や ansible-2.0 の他のプラグインを確認するのが有効です。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:307 -msgid "As a simple example we are going to make a hybrid ``fileglob`` lookup plugin." -msgstr "簡単な例として、ハイブリッドの ``fileglob`` lookup プラグインを作成します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:368 -msgid "In the above example we did not use the ``warning()`` method as we had no direct use for it in the final version. However we left this code in so people can use this part during development/porting/use." -msgstr "上記の例では、最終バージョンで直接使用することがなかったため、``warning()`` メソッドを使用していません。しかし、開発、移植、および使用の際にこの部分を利用できるように、このコードを残しました。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:385 -msgid "callback plugins" -msgstr "callback プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:394 -#: ../../rst/porting_guides/porting_guide_2.10.rst:97 -#: ../../rst/porting_guides/porting_guide_2.3.rst:160 -#: ../../rst/porting_guides/porting_guide_2.5.rst:281 -#: ../../rst/porting_guides/porting_guide_2.6.rst:102 -#: ../../rst/porting_guides/porting_guide_2.7.rst:241 -#: ../../rst/porting_guides/porting_guide_2.8.rst:549 -#: ../../rst/porting_guides/porting_guide_2.9.rst:722 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:90 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:86 -msgid "Porting custom scripts" -msgstr "カスタムスクリプトの移植" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:396 -msgid "Custom scripts that used the ``ansible.runner.Runner`` API in 1.x have to be ported in 2.x. Please refer to: :ref:`developing_api`" -msgstr "1.x で ``ansible.runner.Runner`` API を使用したカスタムスクリプトは、2.x に移植する必要があります。「:ref:`developing_api`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:8 -msgid "Ansible 2.10 Porting Guide" -msgstr "Ansible 2.10 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:12 -msgid "In Ansible 2.10, many plugins and modules have migrated to Collections on `Ansible Galaxy `_. Your playbooks should continue to work without any changes. We recommend you start using the fully-qualified collection name (FQCN) in your playbooks as the explicit and authoritative indicator of which collection to use as some collections may contain duplicate module names. You can search the `index of all modules `_ to find the collection a module has been relocated to." -msgstr "Ansible 2.10 では、多くのプラグインやモジュールが、`Ansible Galaxy `_ のコレクションに移行しました。お使いの Playbook は何の変更もなく継続してお使いいただけます。一部のコレクションではモジュール名が重複している可能性があるため、どのコレクションを使用するかの明示的かつ権威的な指標として、Playbook で、完全修飾コレクション名（FQCN）を使用することが推奨されます。`すべてのモジュールのインデックス `_ を検索すると、モジュールが再配置されたコレクションを見つけることができます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:14 -msgid "This section discusses the behavioral changes between Ansible 2.9 and Ansible 2.10." -msgstr "このセクションでは、Ansible 2.9 から Ansible 2.10 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:18 -msgid "We suggest you read this page along with the `Ansible Changelog for 2.10 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible 2.10 のチェンジログ `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:20 -msgid "Since 2.10, Ansible consists of two parts:" -msgstr "2.10 以降、Ansible は以下の 2 つの部分から構成されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:22 -msgid "ansible-base, which includes the command line tools with a small selection of plugins and modules, and" -msgstr "ansible-base: プラグインやモジュールが少ないコマンドラインツールが含まれます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:23 -msgid "a `set of collections `_." -msgstr "`コレクションのセット `" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:25 -msgid "The :ref:`porting_2.10_guide_base` is included in this porting guide. The complete list of porting guides can be found at :ref:`porting guides `." -msgstr ":ref:`porting_2.10_guide_base` は、この移植ガイドに含まれます。移植ガイドの一覧は「:ref:`移植ガイド `」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:35 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:28 -msgid "Fixed a bug on boolean keywords that made random strings return 'False', now they should return an error if they are not a proper boolean Example: ``diff: yes-`` was returning ``False``." -msgstr "ランダムな文字列が「False」を返すブール値のキーワードのバグを修正しました。適切なブール値ではない場合はエラーを返すはずです (例: ``diff: yes-`` が ``False`` を返している場合)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:37 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:30 -msgid "A new fact, ``ansible_processor_nproc`` reflects the number of vcpus available to processes (falls back to the number of vcpus available to the scheduler)." -msgstr "新しいファクト ``ansible_processor_nproc`` は、プロセスで利用可能な vcpu の数を反映しています (スケジューラーで利用可能な vcpu の数に戻されます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:43 -#: ../../rst/porting_guides/porting_guide_2.7.rst:18 -#: ../../rst/porting_guides/porting_guide_2.8.rst:305 -#: ../../rst/porting_guides/porting_guide_2.9.rst:37 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:36 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:27 -msgid "Command Line" -msgstr "コマンドライン" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:45 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:38 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:29 -msgid "The ``ansible-galaxy login`` command has been removed, as the underlying API it used for GitHub auth is being shut down. Publishing roles or collections to Galaxy via ``ansible-galaxy`` now requires that a Galaxy API token be passed to the CLI via a token file (default location ``~/.ansible/galaxy_token``) or (insecurely) via the ``--token`` argument to ``ansible-galaxy``." -msgstr "GitHub 認証に使用される基礎となる API がシャットダウンされるため、``ansible-galaxy login`` コマンドが削除されました。``ansible-galaxy`` 経由で Galaxy にロールまたはコレクションを公開する場合は、Galaxy API トークンをトークンファイル (デフォルトの場所 ``~/.ansible/galaxy_token``) または ``--token`` 引数から ``ansible-galaxy`` に (セキュリティーを確保せずにセキュアに) 渡すことが必要になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:53 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:46 -msgid "Windows Server 2008 and 2008 R2 will no longer be supported or tested in the next Ansible release, see :ref:`windows_faq_server2008`." -msgstr "Windows Server 2008 および 2008 R2 は、次回の Ansible リリースではサポートされず、テストされなくなります。「:ref:`windows_faq_server2008`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:57 -#: ../../rst/porting_guides/porting_guide_2.3.rst:108 -#: ../../rst/porting_guides/porting_guide_2.4.rst:77 -#: ../../rst/porting_guides/porting_guide_2.5.rst:156 -#: ../../rst/porting_guides/porting_guide_2.6.rst:28 -#: ../../rst/porting_guides/porting_guide_2.7.rst:154 -#: ../../rst/porting_guides/porting_guide_2.8.rst:364 -#: ../../rst/porting_guides/porting_guide_2.9.rst:72 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:50 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:50 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:61 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:54 -msgid "Links on this page may not point to the most recent versions of modules. We will update them when we can." -msgstr "このページのリンクは、最新のバージョンのモジュールを参照していない可能性があります。可能な限り更新していきます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:63 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:56 -msgid "Version 2.10.0 of ansible-base changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the mode change has been reverted in 2.10.1, and mode will now default to ``0o666 & ~umask`` as in previous versions of Ansible." -msgstr "ansible-base のバージョン 2.10.0 は、ユーザーがファイルベースのタスクで ``mode`` パラメーターを指定しなかった場合に、ファイルベースのタスクのデフォルトモードを ``0o600 & ~umask`` に変更しました。これは、再編成した CVE レポートに対する対応でした。その結果、2.10.1 ではモードの変更が元に戻され、以前のバージョンの Ansible と同様に、モードのデフォルトが ``0o666 & ~umask`` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:64 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:57 -msgid "If you changed any tasks to specify less restrictive permissions while using 2.10.0, those changes will be unnecessary (but will do no harm) in 2.10.1." -msgstr "2.10.0 を使用する際に、より制限の少ないパーミッションを指定するようにタスクを変更した場合、2.10.1 ではその変更は不要になります (ただし、害はありません)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:65 -#: ../../rst/porting_guides/porting_guide_2.8.rst:376 -#: ../../rst/porting_guides/porting_guide_2.9.rst:79 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:58 -msgid "To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it." -msgstr "CVE-2020-1736 で発生する問題を回避するには、それを受け入れるファイルベースのタスクで ``mode`` パラメーターを指定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:67 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:60 -msgid "``dnf`` and ``yum`` - As of version 2.10.1, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task." -msgstr "``dnf`` および ``yum`` - バージョン 2.10.1 より、``dnf`` モジュール (および ``dnf`` を使用する場合は ``yum`` アクション) がパッケージの GPG 署名を正しく検証するようになりました (CVE-2020-14365)。``Failed to validate GPG signature for [package name]`` のようなエラーが表示された場合は、使用している DNF リポジトリーやパッケージの GPG キーが正しくインポートされていることを確認してください。これを行う 1 つの方法として、``rpm_key`` モジュールの使用があります。推奨はしませんが、場合によっては GPG チェックを無効にする必要があるかもしれません。これは、``dnf`` タスクまたは ``yum`` タスクに ``disable_gpg_check: yes`` を明示的に追加することで実現できます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:71 -#: ../../rst/porting_guides/porting_guide_2.3.rst:141 -#: ../../rst/porting_guides/porting_guide_2.4.rst:99 -#: ../../rst/porting_guides/porting_guide_2.5.rst:207 -#: ../../rst/porting_guides/porting_guide_2.6.rst:49 -#: ../../rst/porting_guides/porting_guide_2.7.rst:193 -#: ../../rst/porting_guides/porting_guide_2.8.rst:414 -#: ../../rst/porting_guides/porting_guide_2.9.rst:699 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:64 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:71 -msgid "Noteworthy module changes" -msgstr "モジュール変更に関する注目点" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:73 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:66 -msgid "Ansible modules created with ``add_file_common_args=True`` added a number of undocumented arguments which were mostly there to ease implementing certain action plugins. The undocumented arguments ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode`` are now no longer added. Modules relying on these options to be added need to specify them by themselves." -msgstr "``add_file_common_args=True`` で作成された Ansible モジュールにより、特定アクションプラグインの実装を容易にするために、文書化されていない引数が複数追加されています。ドキュメント化されていない引数 ``src``、``follow``、``force``、``content``、``backup``、``remote_src``、``regexp``、``delimiter``、および ``directory_mode`` が追加されなくなりました。オプションを追加するため、これらのオプションが追加されることに依存しているモジュールは、自分でそれらを指定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:74 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:67 -msgid "Ansible no longer looks for Python modules in the current working directory (typically the ``remote_user``'s home directory) when an Ansible module is run. This is to fix becoming an unprivileged user on OpenBSD and to mitigate any attack vector if the current working directory is writable by a malicious user. Install any Python modules needed to run the Ansible modules on the managed node in a system-wide location or in another directory which is in the ``remote_user``'s ``$PYTHONPATH`` and readable by the ``become_user``." -msgstr "Ansible は、Ansible モジュールの実行時に、現在の作業ディレクトリー (通常は ``remote_user`` のホームディレクトリー) にある Python モジュールを検索しなくなりました。これにより、OpenBSD で権限のないユーザーになり (become)、悪意のあるユーザーが現在の作業ディレクトリーを書き込み可能な場合に攻撃ベクトルを軽減することができます。Ansible モジュールを、システム全体の管理ノードまたは ``remote_user`` の ``$PYTHONPATH`` にあり、``become_user`` が読み取り可能な別のディレクトリーに、Ansible モジュールを実行するのに必要な Python モジュールをインストールします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:78 -#: ../../rst/porting_guides/porting_guide_2.3.rst:155 -#: ../../rst/porting_guides/porting_guide_2.4.rst:107 -#: ../../rst/porting_guides/porting_guide_2.5.rst:237 -#: ../../rst/porting_guides/porting_guide_2.6.rst:83 -#: ../../rst/porting_guides/porting_guide_2.7.rst:231 -#: ../../rst/porting_guides/porting_guide_2.8.rst:511 -#: ../../rst/porting_guides/porting_guide_2.9.rst:713 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:71 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:79 -msgid "Plugins" -msgstr "プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:81 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:74 -msgid "Lookup plugin names case-sensitivity" -msgstr "大文字小文字を区別してプラグイン名の検索" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:83 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:76 -msgid "Prior to Ansible ``2.10`` lookup plugin names passed in as an argument to the ``lookup()`` function were treated as case-insensitive as opposed to lookups invoked via ``with_``. ``2.10`` brings consistency to ``lookup()`` and ``with_`` to be both case-sensitive." -msgstr "Ansible ``2.10`` の lookup プラグイン名が ``lookup()`` 関数に引数として渡される前に、``with_`` を介して呼び出されるルックアップとは異なり、大文字と小文字を区別しないものとして処理されます。``2.10`` では、``lookup()`` と ``with_`` の両方で大文字小文字を区別するように整合性が取られています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:86 -#: ../../rst/porting_guides/porting_guide_2.6.rst:94 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:79 -msgid "Noteworthy plugin changes" -msgstr "注目すべきプラグインの変更点" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:88 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:81 -msgid "Cache plugins in collections can be used to cache data from inventory plugins. Previously, cache plugins in collections could only be used for fact caching." -msgstr "コレクションの cache プラグインを使用すると、インベントリープラグインからデータをキャッシュできます。以前は、コレクションの cache プラグインはファクトキャッシュにしか使用できませんでした。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:89 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:82 -msgid "Some undocumented arguments from ``FILE_COMMON_ARGUMENTS`` have been removed; plugins using these, in particular action plugins, need to be adjusted. The undocumented arguments which were removed are ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode``." -msgstr "``FILE_COMMON_ARGUMENTS`` から、文書化されていない引数がいくつか削除されました。これらの特定のアクションプラグインを使用するプラグインは、調整する必要があります。削除されたドキュメントなしの引数は、``src``、``follow``、``force``、``content``、``backup``、``remote_src``、``regexp``、``delimiter``、および ``directory_mode`` です。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:92 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:85 -msgid "Action plugins which execute modules should use fully-qualified module names" -msgstr "モジュールを実行するアクションプラグインは完全修飾モジュール名の使用が必要" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:94 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:87 -msgid "Action plugins that call modules should pass explicit, fully-qualified module names to ``_execute_module()`` whenever possible (eg, ``ansible.builtin.file`` rather than ``file``). This ensures that the task's collection search order is not consulted to resolve the module. Otherwise, a module from a collection earlier in the search path could be used when not intended." -msgstr "モジュールを呼び出すアクションプラグインは、可能な限り明示的な完全修飾モジュール名を ``_execute_module()`` に渡す必要があります (例: ``file``ではなく ``ansible.builtin.file``)。これにより、タスクのコレクション検索順序がモジュールを解決するように参照されなくなります。そうしないと、意図していないときに検索パスの前の方のコレクションのモジュールが使用されてしまう可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:99 -#: ../../rst/porting_guides/porting_guide_2.9.rst:45 -#: ../../rst/porting_guides/porting_guide_2.9.rst:724 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:92 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:46 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:61 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:67 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:88 -msgid "No notable changes" -msgstr "主な変更はありません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:102 -msgid "Porting Guide for v2.10.7" -msgstr "v2.10.7 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:105 -#: ../../rst/porting_guides/porting_guide_2.10.rst:191 -#: ../../rst/porting_guides/porting_guide_2.10.rst:264 -#: ../../rst/porting_guides/porting_guide_2.10.rst:376 -#: ../../rst/porting_guides/porting_guide_2.10.rst:469 -#: ../../rst/porting_guides/porting_guide_3.rst:27 -msgid "Breaking Changes" -msgstr "互換性を失わせる変更点" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:108 -#: ../../rst/porting_guides/porting_guide_2.10.rst:150 -#: ../../rst/porting_guides/porting_guide_2.10.rst:202 -#: ../../rst/porting_guides/porting_guide_2.10.rst:275 -#: ../../rst/porting_guides/porting_guide_2.10.rst:360 -#: ../../rst/porting_guides/porting_guide_2.10.rst:518 -#: ../../rst/porting_guides/porting_guide_2.10.rst:651 -#: ../../rst/porting_guides/porting_guide_2.10.rst:809 -#: ../../rst/porting_guides/porting_guide_2.10.rst:924 -#: ../../rst/porting_guides/porting_guide_3.rst:47 -#: ../../rst/porting_guides/porting_guide_3.rst:151 -#: ../../rst/porting_guides/porting_guide_3.rst:282 -#: ../../rst/porting_guides/porting_guide_3.rst:423 -msgid "community.general" -msgstr "community.general" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:110 -#: ../../rst/porting_guides/porting_guide_3.rst:91 -msgid "utm_proxy_auth_profile - the ``frontend_cookie_secret`` return value now contains a placeholder string instead of the module's ``frontend_cookie_secret`` parameter (https://github.com/ansible-collections/community.general/pull/1736)." -msgstr "utm_proxy_auth_profile - ``frontend_cookie_secret`` の戻り値に、モジュールの ``frontend_cookie_secret`` パラメーターではなくプレースホルダーの文字列が含まれるようになりました (https://github.com/ansible-collections/community.general/pull/1736)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:113 -#: ../../rst/porting_guides/porting_guide_2.10.rst:147 -#: ../../rst/porting_guides/porting_guide_2.10.rst:199 -#: ../../rst/porting_guides/porting_guide_2.10.rst:272 -#: ../../rst/porting_guides/porting_guide_2.10.rst:384 -#: ../../rst/porting_guides/porting_guide_2.10.rst:425 -#: ../../rst/porting_guides/porting_guide_2.10.rst:613 -#: ../../rst/porting_guides/porting_guide_3.rst:143 -msgid "Major Changes" -msgstr "主な変更点" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:115 -msgid "Restricting the version of the community.okd collection to 1.0.0. The previously included version, 1.0.1, had a dependency on kubernetes.core and thus required the installation of an additional collection that was not included in Ansible 2.10. Version 1.0.0 is essentially identical to 1.0.1, except that it uses community.kubernetes, which is included in Ansible 2.10." -msgstr "community.okd コレクションのバージョンを 1.0.0 に制限しました。これまで含まれていたバージョン 1.0.1 は、kubernetes.core に依存していたため、Ansible 2.10 に含まれていない追加のコレクションをインストールする必要がありました。バージョン 1.0.0 は、Ansible 2.10 に含まれている community.kubernetes を使用している以外は、1.0.1 と基本的に同じです。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:118 -#: ../../rst/porting_guides/porting_guide_2.10.rst:392 -#: ../../rst/porting_guides/porting_guide_2.10.rst:739 -#: ../../rst/porting_guides/porting_guide_3.rst:230 -msgid "ovirt.ovirt" -msgstr "ovirt.ovirt" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:120 -#: ../../rst/porting_guides/porting_guide_3.rst:239 -msgid "ovirt_system_option_info - Add new module (https://github.com/oVirt/ovirt-ansible-collection/pull/206)." -msgstr "ovirt_system_option_info - 新しいモジュールを追加します (https://github.com/oVirt/ovirt-ansible-collection/pull/206)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:123 -#: ../../rst/porting_guides/porting_guide_3.rst:245 -msgid "servicenow.servicenow" -msgstr "servicenow.servicenow" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:125 -#: ../../rst/porting_guides/porting_guide_3.rst:247 -msgid "add new tests (find with no result, search many)" -msgstr "新規テストの追加 (結果がない検索、多数の検索)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:126 -#: ../../rst/porting_guides/porting_guide_3.rst:248 -msgid "add related tests" -msgstr "関連テストの追加" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:127 -#: ../../rst/porting_guides/porting_guide_3.rst:249 -msgid "add support for ServiceNOW table api display_value exclude_reference_link and suppress_pagination_header" -msgstr "ServiceNOW テーブル api display_value exclude_reference_link および suppress_pagination_header のサポートを追加" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:128 -#: ../../rst/porting_guides/porting_guide_3.rst:250 -msgid "use new API for pysnow >=0.6.0" -msgstr "0.6.0 以降の pysnow で新しい API の使用" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:131 -#: ../../rst/porting_guides/porting_guide_2.10.rst:238 -#: ../../rst/porting_guides/porting_guide_2.10.rst:357 -#: ../../rst/porting_guides/porting_guide_2.10.rst:414 -#: ../../rst/porting_guides/porting_guide_2.10.rst:434 -#: ../../rst/porting_guides/porting_guide_2.10.rst:851 -#: ../../rst/porting_guides/porting_guide_3.rst:402 -msgid "Deprecated Features" -msgstr "非推奨の機能" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:134 -#: ../../rst/porting_guides/porting_guide_2.10.rst:417 -#: ../../rst/porting_guides/porting_guide_2.10.rst:437 -#: ../../rst/porting_guides/porting_guide_3.rst:405 -msgid "cisco.nxos" -msgstr "cisco.nxos" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:136 -#: ../../rst/porting_guides/porting_guide_3.rst:407 -msgid "Deprecated `nxos_bgp` and `nxos_bgp_neighbor` modules in favor of `nxos_bgp_global` resource module." -msgstr "`nxos_bgp` モジュールおよび `nxos_bgp_neighbor` モジュールが非推奨となり、`nxos_bgp_global` リソースモジュールが使用されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:139 -#: ../../rst/porting_guides/porting_guide_2.10.rst:537 -#: ../../rst/porting_guides/porting_guide_2.10.rst:827 -#: ../../rst/porting_guides/porting_guide_2.10.rst:944 -#: ../../rst/porting_guides/porting_guide_3.rst:449 -msgid "community.vmware" -msgstr "community.vmware" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:141 -#: ../../rst/porting_guides/porting_guide_3.rst:451 -msgid "vmware_host_firewall_manager - the creation of new rule with no ``allowed_ip`` entry in the ``allowed_hosts`` dictionary won't be allowed after 2.0.0 release." -msgstr "vmware_host_firewall_manager - ``allowed_hosts`` ディクショナリーに ``allowed_ip`` エントリーがない新規ルールの作成は、2.0.0 リリース後は許可されなくなります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:144 -msgid "Porting Guide for v2.10.6" -msgstr "v2.10.6 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:152 -msgid "For community.general 2.0.0, the kubevirt modules will be moved to the `community.kubevirt `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、kubevirt モジュールは `community.kubevirt `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:155 -msgid "If you use Ansible 2.9 and explicitly use kubevirt modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.kubevirt.`` instead of ``community.general.``, for example replace ``community.general.kubevirt_vm`` in a task by ``community.kubevirt.kubevirt_vm``." -msgstr "Ansible 2.9 を使用し、このコレクションからの kubevirt モジュールを明示的に使用する場合は、``community.general.`` ではなく ``community.kubevirt.`` で始まる FQCN を使用するように Playbook およびロールを調整する必要があります (例: ``community.kubevirt.kubevirt_vm`` によるタスクで ``community.general.kubevirt_vm`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:158 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the kubevirt modules, you have to make sure to install the ``community.kubevirt`` collection as well. If you are using FQCNs, for example ``community.general.kubevirt_vm`` instead of ``kubevirt_vm``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.general`` を手動でインストールし、kubevirt モジュールに依存している場合は、``community.kubevirt`` コレクションもインストールする必要があります。FQCN を使用している場合は、たとえば ``kubevirt_vm`` の代わりに ``community.general.kubevirt_vm`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:162 -#: ../../rst/porting_guides/porting_guide_2.10.rst:304 -#: ../../rst/porting_guides/porting_guide_2.10.rst:368 -#: ../../rst/porting_guides/porting_guide_2.10.rst:532 -#: ../../rst/porting_guides/porting_guide_2.10.rst:822 -#: ../../rst/porting_guides/porting_guide_3.rst:104 -#: ../../rst/porting_guides/porting_guide_3.rst:366 -#: ../../rst/porting_guides/porting_guide_3.rst:444 -msgid "community.network" -msgstr "community.network" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:164 -msgid "For community.network 2.0.0, the Cisco NSO modules will be moved to the `cisco.nso `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.network 2.0.0 では、Cisco NSO モジュールは `cisco.nso `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更しなくてもよいように、リダイレクトが挿入されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:167 -msgid "If you use Ansible 2.9 and explicitly use Cisco NSO modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``cisco.nso.`` instead of ``community.network.``, for example replace ``community.network.nso_config`` in a task by ``cisco.nso.nso_config``." -msgstr "Ansible 2.9 を使用し、このコレクションから Cisco NSO モジュールを明示的に使用する場合は、Playbook およびロールを ``community.network.`` ではなく ``cisco.nso.`` で始まる FQCN を使用するように調整する必要があります (例: ``cisco.nso.nso_config`` によるタスクで ``community.network.nso_config`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:170 -msgid "If you use ansible-base and installed ``community.network`` manually and rely on the Cisco NSO modules, you have to make sure to install the ``cisco.nso`` collection as well. If you are using FQCNs, for example ``community.network.nso_config`` instead of ``nso_config``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.network`` を手動でインストールし、Cisco NSO モジュールに依存している場合は、``cisco.nso`` コレクションもインストールする必要があります。FQCN を使用している場合、たとえば ``nso_config`` の代わりに ``community.network.nso_config`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:172 -msgid "For community.network 2.0.0, the FortiOS modules will be moved to the `community.fortios `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.network 2.0.0 では、FortiOS モジュールは `community.fortios `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更しなくてもよいように、リダイレクトが挿入されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:175 -msgid "If you use Ansible 2.9 and explicitly use FortiOS modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.fortios.`` instead of ``community.network.``, for example replace ``community.network.fmgr_device`` in a task by ``community.fortios.fmgr_device``." -msgstr "Ansible 2.9 を使用し、このコレクションから FortiOS モジュールを明示的に使用する場合は、Playbook およびロールを ``community.network.`` ではなく ``community.fortios.`` で始まる FQCN を使用するように調整する必要があります (例: ``community.fortios.fmgr_device`` によるタスクで ``community.network.fmgr_device`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:178 -msgid "If you use ansible-base and installed ``community.network`` manually and rely on the FortiOS modules, you have to make sure to install the ``community.fortios`` collection as well. If you are using FQCNs, for example ``community.network.fmgr_device`` instead of ``fmgr_device``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.network`` を手動でインストールし、FortiOS モジュールに依存している場合は、``community.fortios`` コレクションもインストールする必要があります。FQCN を使用している場合、たとえば ``fmgr_device`` の代わりに ``community.network.fmgr_device`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:182 -#: ../../rst/porting_guides/porting_guide_2.10.rst:387 -#: ../../rst/porting_guides/porting_guide_2.10.rst:409 -#: ../../rst/porting_guides/porting_guide_2.10.rst:728 -#: ../../rst/porting_guides/porting_guide_2.10.rst:841 -#: ../../rst/porting_guides/porting_guide_2.10.rst:958 -#: ../../rst/porting_guides/porting_guide_3.rst:188 -#: ../../rst/porting_guides/porting_guide_3.rst:397 -msgid "f5networks.f5_modules" -msgstr "f5networks.f5_modules" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:184 -#: ../../rst/porting_guides/porting_guide_3.rst:191 -msgid "Added async_timeout parameter to bigip_ucs_fetch module to allow customization of module wait for async interface" -msgstr "bigip_ucs_fetch モジュールに async_timeout パラメーターを追加して、モジュールが async インターフェースを待機できるようにします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:185 -#: ../../rst/porting_guides/porting_guide_3.rst:192 -msgid "Changed bigip_ucs_fetch module to use asynchronous interface when generating UCS files" -msgstr "UCS ファイルの生成時に非同期インターフェースを使用するように bigip_ucs_fetch モジュールの変更" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:188 -msgid "Porting Guide for v2.10.5" -msgstr "v2.10.5 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:194 -#: ../../rst/porting_guides/porting_guide_2.10.rst:251 -#: ../../rst/porting_guides/porting_guide_3.rst:94 -#: ../../rst/porting_guides/porting_guide_3.rst:434 -msgid "community.hashi_vault" -msgstr "community.hashi_vault" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:196 -#: ../../rst/porting_guides/porting_guide_3.rst:96 -msgid "hashi_vault - the ``VAULT_ADDR`` environment variable is now checked last for the ``url`` parameter. For details on which use cases are impacted, see (https://github.com/ansible-collections/community.hashi_vault/issues/8)." -msgstr "hashi_vault - ``VAULT_ADDR`` 環境変数が、最後に ``url`` パラメーターについてチェックされるようになりました。影響を受けるユースケースの詳細は、https://github.com/ansible-collections/community.hashi_vault/issues/8 を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:204 -msgid "For community.general 2.0.0, the Google modules will be moved to the `community.google `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、Google モジュールは `community.google `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:207 -msgid "If you use Ansible 2.9 and explicitly use Google modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.google.`` instead of ``community.general.``, for example replace ``community.general.gcpubsub`` in a task by ``community.google.gcpubsub``." -msgstr "Ansible 2.9 を使用し、このコレクションから Google モジュールを明示的に使用する場合は、Playbook およびロールを ``community.general.`` ではなく ``community.google.`` で始まる FQCN を使用するように調整する必要があります (例: ``community.google.gcpubsub`` によるタスクで ``community.general.gcpubsub`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:210 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the Google modules, you have to make sure to install the ``community.google`` collection as well. If you are using FQCNs, for example ``community.general.gcpubsub`` instead of ``gcpubsub``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.general`` を手動でインストールし、Google モジュールに依存している場合は、``community.google`` コレクションもインストールする必要があります。FQCN を使用している場合、たとえば ``gcpubsub`` の代わりに ``community.general.gcpubsub`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:212 -msgid "For community.general 2.0.0, the OC connection plugin will be moved to the `community.okd `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、OC 接続プラグインは `community.okd `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:215 -msgid "If you use Ansible 2.9 and explicitly use OC connection plugin from this collection, you will need to adjust your playbooks and roles to use FQCNs ``community.okd.oc`` instead of ``community.general.oc``." -msgstr "Ansible 2.9 を使用し、このコレクションから OC 接続プラグインを明示的に使用する場合は、Playbook およびロールを ``community.general.oc`` ではなく FQCN の ``community.okd.oc`` を使用するように調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:217 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the OC connection plugin, you have to make sure to install the ``community.okd`` collection as well. If you are using FQCNs, in other words ``community.general.oc`` instead of ``oc``, it will continue working, but we still recommend to adjust this FQCN as well." -msgstr "ansible-base を使用し、手動でインストールした ``community.general`` を使用し、OC 接続プラグインに依存する場合は、``community.okd`` コレクションもインストールしてください。FQCN を使用している場合、つまり、``oc`` の代わりに ``community.general.oc`` を使用している場合、動作は継続されますが、この FQCN も調整することを推奨します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:219 -msgid "For community.general 2.0.0, the hashi_vault lookup plugin will be moved to the `community.hashi_vault `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、hashi_vault lookup プラグインは `community.hashi_vault `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:222 -msgid "If you use Ansible 2.9 and explicitly use hashi_vault lookup plugin from this collection, you will need to adjust your playbooks and roles to use FQCNs ``community.hashi_vault.hashi_vault`` instead of ``community.general.hashi_vault``." -msgstr "Ansible 2.9 を使用し、このコレクションの hashi_vault lookup プラグインを明示的に使用する場合は、``community.general.hashi_vault`` ではなく FQCN ``community.hashi_vault.hashi_vault`` を使用するように Playbook およびロールを調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:224 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the hashi_vault lookup plugin, you have to make sure to install the ``community.hashi_vault`` collection as well. If you are using FQCNs, in other words ``community.general.hashi_vault`` instead of ``hashi_vault``, it will continue working, but we still recommend to adjust this FQCN as well." -msgstr "ansible-base を使用し、手動でインストールした ``community.general`` を手動でし、hashi_vault lookup プラグインに依存する場合は、``community.hashi_vault`` コレクションもインストールする必要があります。FQCN を使用している場合、つまり、``hashi_vault`` ではなく ``community.general.hashi_vault`` を使用している場合、動作は継続されますが、この FQCN も調整することを推奨します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:228 -#: ../../rst/porting_guides/porting_guide_2.10.rst:559 -#: ../../rst/porting_guides/porting_guide_3.rst:220 -msgid "netbox.netbox" -msgstr "netbox.netbox" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:230 -#: ../../rst/porting_guides/porting_guide_3.rst:222 -msgid "nb_inventory - Add ``dns_name`` option that adds ``dns_name`` to the host when ``True`` and device has a primary IP address. (#394)" -msgstr "nb_inventory - ``True`` およびデバイスにプライマリー IP アドレスがある場合に ``dns_name`` をホストに追加する ``dns_name`` オプションを追加します。(#394)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:231 -#: ../../rst/porting_guides/porting_guide_3.rst:223 -msgid "nb_inventory - Add ``status`` as a ``group_by`` option. (398)" -msgstr "nb_inventory - ``group_by`` オプションとして ``status`` を追加します。(398)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:232 -#: ../../rst/porting_guides/porting_guide_3.rst:224 -msgid "nb_inventory - Move around ``extracted_primary_ip`` to allow for ``config_context`` or ``custom_field`` to overwrite. (#377)" -msgstr "nb_inventory - ``config_context`` または ``custom_field`` の上書きを許可する ``extracted_primary_ip`` を移動します。(#377)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:233 -#: ../../rst/porting_guides/porting_guide_3.rst:225 -msgid "nb_inventory - Services are now a list of integers due to NetBox 2.10 changes. (#396)" -msgstr "nb_inventory - サービスは、NetBox 2.10 の変更により整数の一覧になりました。(#396)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:234 -#: ../../rst/porting_guides/porting_guide_3.rst:226 -msgid "nb_lookup - Allow ID to be passed in and use ``.get`` instead of ``.filter``. (#376)" -msgstr "nb_lookup - ID を渡すことができ、``.filter`` の代わりに ``.get`` を使用できます。(#376)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:235 -#: ../../rst/porting_guides/porting_guide_3.rst:227 -msgid "nb_lookup - Allow ``api_endpoint`` and ``token`` to be found via env. (#391)" -msgstr "nb_lookup - ``api_endpoint`` および ``token`` を env 経由で検索することを許可します。(#391)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:241 -#: ../../rst/porting_guides/porting_guide_2.10.rst:892 -#: ../../rst/porting_guides/porting_guide_3.rst:413 -msgid "community.aws" -msgstr "community.aws" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:243 -#: ../../rst/porting_guides/porting_guide_3.rst:415 -msgid "ec2_vpc_igw_info - After 2022-06-22 the ``convert_tags`` parameter default value will change from ``False`` to ``True`` to match the collection standard behavior (https://github.com/ansible-collections/community.aws/pull/318)." -msgstr "ec2_vpc_igw_info - 2022-06-22 以降、``convert_tags`` パラメーターのデフォルト値が ``False`` から ``True`` に変更し、コレクションの標準動作と一致するようになります (https://github.com/ansible-collections/community.aws/pull/318)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:246 -#: ../../rst/porting_guides/porting_guide_2.10.rst:331 -#: ../../rst/porting_guides/porting_guide_3.rst:256 -#: ../../rst/porting_guides/porting_guide_3.rst:418 -msgid "community.docker" -msgstr "community.docker" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:248 -#: ../../rst/porting_guides/porting_guide_3.rst:420 -msgid "docker_container - currently ``published_ports`` can contain port mappings next to the special value ``all``, in which case the port mappings are ignored. This behavior is deprecated for community.docker 2.0.0, at which point it will either be forbidden, or this behavior will be properly implemented similar to how the Docker CLI tool handles this (https://github.com/ansible-collections/community.docker/issues/8, https://github.com/ansible-collections/community.docker/pull/60)." -msgstr "docker_container - 現在、``published_ports`` には、特別な値 ``all`` の横にポートマッピングを含めることができます。この動作は、community.docker 2.0.0 では非推奨です。その時点で、禁止されるか、Docker CLI ツールがどのようにこれを処理するかと同じように、この動作が適切に実装されます (https://github.com/ansible-collections/community.docker/issues/8、https://github.com/ansible-collections/community.docker/pull/60)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:253 -#: ../../rst/porting_guides/porting_guide_3.rst:436 -msgid "hashi_vault - ``VAULT_ADDR`` environment variable for option ``url`` will have its precedence lowered in 1.0.0; use ``ANSIBLE_HASHI_VAULT_ADDR`` to intentionally override a config value (https://github.com/ansible-collections/community.hashi_vault/issues/8)." -msgstr "hashi_vault - オプション ``url`` の ``VAULT_ADDR`` 環境変数の優先度は 1.0.0 で低くなります。設定値を意図的に上書きするには ``ANSIBLE_HASHI_VAULT_ADDR`` を使用します (https://github.com/ansible-collections/community.hashi_vault/issues/8)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:254 -#: ../../rst/porting_guides/porting_guide_3.rst:437 -msgid "hashi_vault - ``VAULT_AUTH_METHOD`` environment variable for option ``auth_method`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_AUTH_METHOD`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/17)." -msgstr "hashi_vault - オプション ``auth_method`` の ``VAULT_AUTH_METHOD`` 環境変数は 2.0.0 で削除されます。代わりに ``ANSIBLE_HASHI_VAULT_AUTH_METHOD`` を使用します (https://github.com/ansible-collections/community.hashi_vault/issues/17)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:255 -#: ../../rst/porting_guides/porting_guide_3.rst:438 -msgid "hashi_vault - ``VAULT_ROLE_ID`` environment variable for option ``role_id`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_ROLE_ID`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/20)." -msgstr "hashi_vault - オプション ``role_id`` の ``VAULT_ROLE_ID`` 環境変数は 2.0.0 で削除されます。代わりに ``ANSIBLE_HASHI_VAULT_ROLE_ID`` を使用します (https://github.com/ansible-collections/community.hashi_vault/issues/20)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:256 -#: ../../rst/porting_guides/porting_guide_3.rst:439 -msgid "hashi_vault - ``VAULT_SECRET_ID`` environment variable for option ``secret_id`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_SECRET_ID`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/20)." -msgstr "hashi_vault - オプション ``secret_id`` の ``VAULT_SECRET_ID`` 環境変数は 2.0.0 で削除されます。代わりに ``ANSIBLE_HASHI_VAULT_SECRET_ID`` を使用します (https://github.com/ansible-collections/community.hashi_vault/issues/20)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:257 -#: ../../rst/porting_guides/porting_guide_3.rst:440 -msgid "hashi_vault - ``VAULT_TOKEN_FILE`` environment variable for option ``token_file`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_TOKEN_FILE`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/15)." -msgstr "hashi_vault - オプション ``token_file`` の ``VAULT_TOKEN_FILE`` 環境変数は 2.0.0 で削除されます。代わりに ``ANSIBLE_HASHI_VAULT_TOKEN_FILE`` を使用します (https://github.com/ansible-collections/community.hashi_vault/issues/15)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:258 -#: ../../rst/porting_guides/porting_guide_3.rst:441 -msgid "hashi_vault - ``VAULT_TOKEN_PATH`` environment variable for option ``token_path`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_TOKEN_PATH`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/15)." -msgstr "hashi_vault - オプション ``token_path`` の ``VAULT_TOKEN_PATH`` 環境変数は 2.0.0 で削除されます。代わりに ``ANSIBLE_HASHI_VAULT_TOKEN_PATH`` を使用します (https://github.com/ansible-collections/community.hashi_vault/issues/15)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:261 -msgid "Porting Guide for v2.10.4" -msgstr "v2.10.4 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:267 -#: ../../rst/porting_guides/porting_guide_3.rst:99 -msgid "community.hrobot" -msgstr "community.hrobot" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:269 -#: ../../rst/porting_guides/porting_guide_3.rst:101 -msgid "firewall - now requires the `ipaddress `_ library (https://github.com/ansible-collections/community.hrobot/pull/2)." -msgstr "firewall - `ipaddress `_ ライブラリーが必要になりました (https://github.com/ansible-collections/community.hrobot/pull/2)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:277 -msgid "For community.general 2.0.0, the Hetzner Robot modules will be moved to the `community.hrobot `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、Heatzner Robot モジュールが `community.hrobot `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更しないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:280 -msgid "If you use Ansible 2.9 and explicitly use Hetzner Robot modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.hrobot.`` instead of ``community.general.hetzner_``, for example replace ``community.general.hetzner_firewall_info`` in a task by ``community.hrobot.firewall_info``." -msgstr "Ansible 2.9 を使用して、このコレクションから Hetzner Robot モジュールを明示的に使用する場合は、``community.general.hetzner_`` ではなく ``community.hrobot.`` で始まる FQCN を使用するように Playbook およびロールを調整する必要があります (例: ``community.hrobot.firewall_info`` で、タスク内の ``community.general.hetzner_firewall_info`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:283 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the Hetzner Robot modules, you have to make sure to install the ``community.hrobot`` collection as well. If you are using FQCNs, i.e. ``community.general.hetzner_failover_ip`` instead of ``hetzner_failover_ip``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.general`` を手動でインストールし、Hetzner Robot モジュールに依存している場合は、``community.hrobot`` コレクションもインストールする必要があります。FQCN を使用している場合、たとえば ``hetzner_failover_ip`` の代わりに ``community.general.hetzner_failover_ip`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:285 -msgid "For community.general 2.0.0, the ``docker`` modules and plugins will be moved to the `community.docker `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、``docker`` モジュールおよびプラグインは `community.docker `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:288 -msgid "If you use Ansible 2.9 and explicitly use ``docker`` content from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.docker.`` instead of ``community.general.``, for example replace ``community.general.docker_container`` in a task by ``community.docker.docker_container``." -msgstr "Ansible 2.9 を使用し、このコレクションから ``docker`` コンテンツを明示的に使用する場合は、Playbook およびロールを ``community.general.`` ではなく ``community.docker.`` で始まる FQCN を使用するように調整する必要があります (例: ``community.docker.docker_container`` によるタスクで ``community.general.docker_container`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:291 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the ``docker`` content, you have to make sure to install the ``community.docker`` collection as well. If you are using FQCNs, i.e. ``community.general.docker_container`` instead of ``docker_container``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.general`` を手動でインストールし、``docker`` コンテンツに依存している場合は、``community.docker`` コレクションもインストールする必要があります。FQCN を使用している場合、つまり ``docker_container`` の代わりに ``community.general.docker_container`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:293 -msgid "For community.general 2.0.0, the ``postgresql`` modules and plugins will be moved to the `community.postgresql `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、``postgresql`` モジュールおよびプラグインは `community.postgresql `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:296 -msgid "If you use Ansible 2.9 and explicitly use ``postgresql`` content from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.postgresql.`` instead of ``community.general.``, for example replace ``community.general.postgresql_info`` in a task by ``community.postgresql.postgresql_info``." -msgstr "Ansible 2.9 を使用し、このコレクションから ``postgresql`` コンテンツを明示的に使用する場合は、Playbook およびロールを ``community.general.`` ではなく ``community.postgresql.`` で始まる FQCN を使用するように調整する必要があります (例: ``community.postgresql.postgresql_info`` によるタスクで ``community.general.postgresql_info`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:299 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the ``postgresql`` content, you have to make sure to install the ``community.postgresql`` collection as well. If you are using FQCNs, i.e. ``community.general.postgresql_info`` instead of ``postgresql_info``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.general`` を手動でインストールし、``postgresql`` コンテンツに依存している場合は、``community.postgresql`` コレクションもインストールする必要があります。FQCN を使用している場合、つまり ``postgresql_info`` の代わりに ``community.general.postgresql_info`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:301 -#: ../../rst/porting_guides/porting_guide_3.rst:162 -msgid "The community.general collection no longer depends on the ansible.posix collection (https://github.com/ansible-collections/community.general/pull/1157)." -msgstr "community.general コレクションは ansible.posix コレクションに依存しなくなりました (https://github.com/ansible-collections/community.general/pull/1157)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:306 -msgid "For community.network 2.0.0, the ``routeros`` modules and plugins will be moved to the `community.routeros `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.network 2.0.0 の場合、``routeros`` モジュールおよびプラグインは `community.routeros `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:309 -msgid "If you use Ansible 2.9 and explicitly use ``routeros`` content from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.routeros.`` instead of ``community.network.routeros_``, for example replace ``community.network.routeros_api`` in a task by ``community.routeros.api``." -msgstr "Ansible 2.9 を使用し、このコレクションから ``routeros`` コンテンツを明示的に使用する場合は、Playbook およびロールを ``community.network.routeros_`` ではなく ``community.routeros.`` で始まる FQCN を使用するように調整する必要があります (例: ``community.routeros.api`` によるタスクで ``community.network.routeros_api`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:312 -msgid "If you use ansible-base and installed ``community.network`` manually and rely on the ``routeros`` content, you have to make sure to install the ``community.routeros`` collection as well. If you are using FQCNs, i.e. ``community.network.routeros_command`` instead of ``routeros_command``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.network`` を手動でインストールし、``routeros`` コンテンツに依存している場合は、``community.routeros`` コレクションもインストールする必要があります。FQCN を使用している場合、つまり ``routeros_command`` の代わりに ``community.network.routeros_command`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:314 -msgid "In community.network 2.0.0, the ``fortimanager`` httpapi plugin will be removed and replaced by a redirect to the corresponding plugin in the fortios.fortimanager collection. For Ansible 2.10 and ansible-base 2.10 users, this means that it will continue to work assuming that collection is installed. For Ansible 2.9 users, this means that they have to adjust the FQCN from ``community.network.fortimanager`` to ``fortios.fortimanager.fortimanager`` (https://github.com/ansible-collections/community.network/pull/151)." -msgstr "community.network 2.0.0 では、``fortimanager`` httpapi プラグインが削除され、fortios.fortimanager コレクションにある対応するプラグインへのリダイレクトに置き換えられます。Ansible 2.10 および ansible-base 2.10 ユーザーの場合は、コレクションがインストールされていると仮定して動作は継続します。Ansible 2.9 ユーザーは、FQCN を ``community.network.fortimanager`` から ``fortios.fortimanager.fortimanager`` へ調整する必要があることを意味します。(https://github.com/ansible-collections/community.network/pull/151)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:317 -#: ../../rst/porting_guides/porting_guide_3.rst:171 -msgid "community.okd" -msgstr "community.okd" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:319 -#: ../../rst/porting_guides/porting_guide_3.rst:173 -msgid "Add custom k8s module, integrate better Molecule tests (https://github.com/ansible-collections/community.okd/pull/7)." -msgstr "カスタム k8s モジュールを追加し、優れた Molecule テストを統合します (https://github.com/ansible-collections/community.okd/pull/7)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:320 -#: ../../rst/porting_guides/porting_guide_3.rst:174 -msgid "Add downstream build scripts to build redhat.openshift (https://github.com/ansible-collections/community.okd/pull/20)." -msgstr "redhat.openshift を構築するためのダウンストリームビルドスクリプトを追加します (https://github.com/ansible-collections/community.okd/pull/20)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:321 -#: ../../rst/porting_guides/porting_guide_3.rst:175 -msgid "Add openshift connection plugin, update inventory plugin to use it (https://github.com/ansible-collections/community.okd/pull/18)." -msgstr "openshift 接続プラグインを追加し、使用するインベントリープラグインを更新します (https://github.com/ansible-collections/community.okd/pull/18)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:322 -#: ../../rst/porting_guides/porting_guide_3.rst:176 -msgid "Add openshift_process module for template rendering and optional application of rendered resources (https://github.com/ansible-collections/community.okd/pull/44)." -msgstr "テンプレートをレンダリングし、レンダリングされたリソースの任意のアプリケーション用に openshift_process モジュールを追加します (https://github.com/ansible-collections/community.okd/pull/44)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:323 -#: ../../rst/porting_guides/porting_guide_3.rst:177 -msgid "Add openshift_route module for creating routes from services (https://github.com/ansible-collections/community.okd/pull/40)." -msgstr "サービスからルートを作成する openshift_route モジュールを追加します (https://github.com/ansible-collections/community.okd/pull/40)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:324 -#: ../../rst/porting_guides/porting_guide_3.rst:178 -msgid "Initial content migration from community.kubernetes (https://github.com/ansible-collections/community.okd/pull/3)." -msgstr "community.kubernetes からの最初のコンテンツの移行 (https://github.com/ansible-collections/community.okd/pull/3)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:325 -#: ../../rst/porting_guides/porting_guide_3.rst:179 -msgid "openshift_auth - new module (migrated from k8s_auth in community.kubernetes) (https://github.com/ansible-collections/community.okd/pull/33)." -msgstr "openshift_auth - 新しいモジュール (community.kubernetes の k8s_auth からの移行) (https://github.com/ansible-collections/community.okd/pull/33)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:328 -#: ../../rst/porting_guides/porting_guide_2.10.rst:406 -#: ../../rst/porting_guides/porting_guide_2.10.rst:786 -#: ../../rst/porting_guides/porting_guide_3.rst:253 -msgid "Removed Features" -msgstr "削除された機能" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:333 -#: ../../rst/porting_guides/porting_guide_3.rst:258 -msgid "docker_container - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_container - ``ansible_facts`` が返されなくなりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:334 -#: ../../rst/porting_guides/porting_guide_3.rst:259 -msgid "docker_container - the default of ``networks_cli_compatible`` changed to ``true`` (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_container - ``networks_cli_compatible`` のデフォルトが ``true`` に変更になりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:335 -#: ../../rst/porting_guides/porting_guide_3.rst:260 -msgid "docker_container - the unused option ``trust_image_content`` has been removed (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_container - 未使用のオプション ``trust_image_content`` が削除されました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:336 -#: ../../rst/porting_guides/porting_guide_3.rst:261 -msgid "docker_image - ``state=build`` has been removed. Use ``present`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - ``state=build`` は削除されました。代わりに ``present`` を使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:337 -#: ../../rst/porting_guides/porting_guide_3.rst:262 -msgid "docker_image - the ``container_limits``, ``dockerfile``, ``http_timeout``, ``nocache``, ``rm``, ``path``, ``buildargs``, ``pull`` have been removed. Use the corresponding suboptions of ``build`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - ``container_limits``、``dockerfile``、``http_timeout``、``nocache``、``rm``、``path``、``buildargs``、``pull`` が削除されました。 代わりに ``build`` の該当するサブオプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:338 -#: ../../rst/porting_guides/porting_guide_3.rst:263 -msgid "docker_image - the ``force`` option has been removed. Use the more specific ``force_*`` options instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - ``force`` オプションは削除されました。代わりに、より具体的な ``force_*`` オプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:339 -#: ../../rst/porting_guides/porting_guide_3.rst:264 -msgid "docker_image - the ``source`` option is now mandatory (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - ``source`` オプションが必須になりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:340 -#: ../../rst/porting_guides/porting_guide_3.rst:265 -msgid "docker_image - the ``use_tls`` option has been removed. Use ``tls`` and ``validate_certs`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - ``use_tls`` オプションが削除されました。代わりに ``tls`` および ``validate_certs`` を使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:341 -#: ../../rst/porting_guides/porting_guide_3.rst:266 -msgid "docker_image - the default of the ``build.pull`` option changed to ``false`` (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - ``build.pull`` オプションのデフォルトが ``false`` に変更になりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:342 -#: ../../rst/porting_guides/porting_guide_3.rst:267 -msgid "docker_image_facts - this alias is on longer available, use ``docker_image_info`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - このエイリアスは利用できなくなります。代わりに ``docker_image_info`` を使用します (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:343 -#: ../../rst/porting_guides/porting_guide_3.rst:268 -msgid "docker_network - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_network - ``ansible_facts`` が返されなくなりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:344 -#: ../../rst/porting_guides/porting_guide_3.rst:269 -msgid "docker_network - the ``ipam_options`` option has been removed. Use ``ipam_config`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_network - ``ipam_options`` オプションは削除されました。代わりに ``ipam_config`` を使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:345 -#: ../../rst/porting_guides/porting_guide_3.rst:270 -msgid "docker_service - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_service - ``ansible_facts`` が返されなくなりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:346 -#: ../../rst/porting_guides/porting_guide_3.rst:271 -msgid "docker_swarm - ``state=inspect`` has been removed. Use ``docker_swarm_info`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm - ``state=inspect`` が削除されました。代わりに ``docker_swarm_info`` を使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:347 -#: ../../rst/porting_guides/porting_guide_3.rst:272 -msgid "docker_swarm_service - the ``constraints`` option has been removed. Use ``placement.constraints`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm_service - ``constraints`` オプションは削除されました。代わりに ``placement.constraints`` を使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:348 -#: ../../rst/porting_guides/porting_guide_3.rst:273 -msgid "docker_swarm_service - the ``limit_cpu`` and ``limit_memory`` options has been removed. Use the corresponding suboptions in ``limits`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm_service - ``limit_cpu`` オプションおよび ``limit_memory`` オプションが削除されました。代わりに ``limits`` で対応するサブオプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:349 -#: ../../rst/porting_guides/porting_guide_3.rst:274 -msgid "docker_swarm_service - the ``log_driver`` and ``log_driver_options`` options has been removed. Use the corresponding suboptions in ``logging`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm_service - ``log_driver`` オプションおよび ``log_driver_options`` オプションが削除されました。代わりに ``logging`` で対応するサブオプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:350 -#: ../../rst/porting_guides/porting_guide_3.rst:275 -msgid "docker_swarm_service - the ``reserve_cpu`` and ``reserve_memory`` options has been removed. Use the corresponding suboptions in ``reservations`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm_service - ``reserve_cpu`` オプションおよび ``reserve_memory`` オプションが削除されました。代わりに ``reservations`` で対応するサブオプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:351 -#: ../../rst/porting_guides/porting_guide_3.rst:276 -msgid "docker_swarm_service - the ``restart_policy``, ``restart_policy_attempts``, ``restart_policy_delay`` and ``restart_policy_window`` options has been removed. Use the corresponding suboptions in ``restart_config`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm_service - ``restart_policy`` オプション、``restart_policy_attempts`` オプション、``restart_policy_delay`` オプション、および ``restart_policy_window`` オプションが削除されました。代わりに ``restart_config`` で対応するサブオプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:352 -#: ../../rst/porting_guides/porting_guide_3.rst:277 -msgid "docker_swarm_service - the ``update_delay``, ``update_parallelism``, ``update_failure_action``, ``update_monitor``, ``update_max_failure_ratio`` and ``update_order`` options has been removed. Use the corresponding suboptions in ``update_config`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm_service - ``update_delay`` オプション、``update_parallelism`` オプション、``update_failure_action`` オプション、``update_monitor``、``update_max_failure_ratio`` オプション、および ``update_order`` オプションが削除されました。代わりに ``update_config`` で対応するサブオプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:353 -#: ../../rst/porting_guides/porting_guide_3.rst:278 -msgid "docker_volume - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_volume - ``ansible_facts`` が返されなくなりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:354 -#: ../../rst/porting_guides/porting_guide_3.rst:279 -msgid "docker_volume - the ``force`` option has been removed. Use ``recreate`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_volume - ``force`` オプションは削除されました。代わりに ``recreate`` を使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:362 -#: ../../rst/porting_guides/porting_guide_3.rst:427 -msgid "django_manage - the parameter ``liveserver`` relates to a no longer maintained third-party module for django. It is now deprecated, and will be remove in community.general 3.0.0 (https://github.com/ansible-collections/community.general/pull/1154)." -msgstr "django_manage - パラメーター ``liveserver`` は、django の維持されているサードパーティーモジュールに関連しなくなりました。現在は非推奨になり、community.general 3.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/1154)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:363 -#: ../../rst/porting_guides/porting_guide_3.rst:428 -msgid "proxmox - the default of the new ``proxmox_default_behavior`` option will change from ``compatibility`` to ``no_defaults`` in community.general 4.0.0. Set the option to an explicit value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/850)." -msgstr "proxmox - 新しい ``proxmox_default_behavior`` オプションのデフォルトが community.general 4.0.0 で ``compatibility`` から ``no_defaults`` に変更します。非推奨の警告を防ぐために、オプションを明示的な値に設定します (https://github.com/ansible-collections/community.general/pull/850))。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:364 -#: ../../rst/porting_guides/porting_guide_3.rst:429 -msgid "proxmox_kvm - the default of the new ``proxmox_default_behavior`` option will change from ``compatibility`` to ``no_defaults`` in community.general 4.0.0. Set the option to an explicit value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/850)." -msgstr "proxmox_kvm - 新しい ``proxmox_default_behavior`` オプションのデフォルトが community.general 4.0.0 で ``compatibility`` から ``no_defaults`` に変更されます。非推奨の警告を防ぐために、オプションを明示的な値に設定します (https://github.com/ansible-collections/community.general/pull/850)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:365 -#: ../../rst/porting_guides/porting_guide_3.rst:430 -msgid "syspatch - deprecate the redundant ``apply`` argument (https://github.com/ansible-collections/community.general/pull/360)." -msgstr "syspatch - 冗長な ``apply`` 引数を非推奨にします (https://github.com/ansible-collections/community.general/pull/360)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:370 -#: ../../rst/porting_guides/porting_guide_3.rst:446 -msgid "Deprecate connection=local support for network platforms using persistent framework (https://github.com/ansible-collections/community.network/pull/120)." -msgstr "永続的なフレームワークを使用したネットワークプラットフォームの connection=local サポートを非推奨にします（https://github.com/ansible-collections/community.network/pull/120)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:373 -msgid "Porting Guide for v2.10.2" -msgstr "v2.10.2 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:379 -#: ../../rst/porting_guides/porting_guide_2.10.rst:616 -#: ../../rst/porting_guides/porting_guide_2.10.rst:789 -#: ../../rst/porting_guides/porting_guide_2.10.rst:856 -#: ../../rst/porting_guides/porting_guide_3.rst:30 -msgid "Ansible-base" -msgstr "Ansible-base" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:381 -#: ../../rst/porting_guides/porting_guide_3.rst:32 -msgid "ansible-galaxy login command has been removed (see https://github.com/ansible/ansible/issues/71560)" -msgstr "ansible-galaxy login コマンドが削除されました (https://github.com/ansible/ansible/issues/71560) を参照)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:389 -#: ../../rst/porting_guides/porting_guide_3.rst:190 -msgid "Add phone home Teem integration into all modules, functionality can be disabled by setting up F5_TEEM environment variable or no_f5_teem provider parameter" -msgstr "すべてのモジュールに phone home Teem 統合を追加します。F5_TEEM 環境変数または no_f5_teem プロバイダーパラメーターを設定して機能を無効にできます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:394 -#: ../../rst/porting_guides/porting_guide_3.rst:232 -msgid "cluster_upgrade - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/94)." -msgstr "cluster_upgrade - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/94)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:395 -#: ../../rst/porting_guides/porting_guide_3.rst:233 -msgid "disaster_recovery - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/134)." -msgstr "disaster_recovery - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/134)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:396 -#: ../../rst/porting_guides/porting_guide_3.rst:234 -msgid "engine_setup - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/69)." -msgstr "engine_setup - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/69)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:397 -#: ../../rst/porting_guides/porting_guide_3.rst:235 -msgid "hosted_engine_setup - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/106)." -msgstr "hosted_engine_setup - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/106)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:398 -#: ../../rst/porting_guides/porting_guide_3.rst:236 -msgid "image_template - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/95)." -msgstr "image_template - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/95)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:399 -#: ../../rst/porting_guides/porting_guide_3.rst:237 -msgid "infra - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/92)." -msgstr "infra - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/92)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:400 -#: ../../rst/porting_guides/porting_guide_3.rst:238 -msgid "manageiq - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/97)." -msgstr "manageiq - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/97)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:401 -#: ../../rst/porting_guides/porting_guide_3.rst:240 -msgid "repositories - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/96)." -msgstr "repositories - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/96)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:402 -#: ../../rst/porting_guides/porting_guide_3.rst:241 -msgid "shutdown_env - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/112)." -msgstr "shutdown_env - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/112)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:403 -#: ../../rst/porting_guides/porting_guide_3.rst:242 -msgid "vm_infra - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/93)." -msgstr "vm_infra - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/93)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:411 -#: ../../rst/porting_guides/porting_guide_3.rst:399 -msgid "Removed arp_state parameter from the bigip_virtual_address module" -msgstr "bigip_virtual_address モジュールから arp_state パラメーターを削除しました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:419 -#: ../../rst/porting_guides/porting_guide_3.rst:408 -msgid "Deprecated `nxos_interface_ospf` in favor of `nxos_ospf_interfaces` Resource Module." -msgstr "`nxos_interface_ospf` を非推奨にし、`nxos_ospf_interfaces` Resource Module が採用されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:422 -msgid "Porting Guide for v2.10.1" -msgstr "v2.10.1 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:428 -#: ../../rst/porting_guides/porting_guide_2.10.rst:664 -#: ../../rst/porting_guides/porting_guide_3.rst:165 -msgid "community.kubernetes" -msgstr "community.kubernetes" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:430 -#: ../../rst/porting_guides/porting_guide_3.rst:167 -msgid "k8s - Add support for template parameter (https://github.com/ansible-collections/community.kubernetes/pull/230)." -msgstr "k8s - テンプレートパラメーターのサポートを追加します (https://github.com/ansible-collections/community.kubernetes/pull/230)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:431 -#: ../../rst/porting_guides/porting_guide_3.rst:168 -msgid "k8s_* - Add support for vaulted kubeconfig and src (https://github.com/ansible-collections/community.kubernetes/pull/193)." -msgstr "k8s_* - Vault 済み kubeconfig および src のサポートを追加します (https://github.com/ansible-collections/community.kubernetes/pull/193)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:439 -#: ../../rst/porting_guides/porting_guide_3.rst:409 -msgid "Deprecated `nxos_smu` in favour of `nxos_rpm` module." -msgstr "`nxos_smu` を非推奨にし、`nxos_rpm` モジュールが採用されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:440 -#: ../../rst/porting_guides/porting_guide_3.rst:410 -msgid "The `nxos_ospf_vrf` module is deprecated by `nxos_ospfv2` and `nxos_ospfv3` Resource Modules." -msgstr "`nxos_ospf_vrf` モジュールは、`nxos_ospfv2` および `nxos_ospfv3` Resource Module によって非推奨となりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:443 -msgid "Porting Guide for v2.10.0" -msgstr "v2.10.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:446 -msgid "Known Issues" -msgstr "既知の問題" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:448 -msgid "Due to a limitation in pip, you cannot ``pip install --upgrade`` from ansible-2.9 or earlier to ansible-2.10 or higher. Instead, you must explicitly use ``pip uninstall ansible`` before pip installing the new version. If you attempt to upgrade Ansible with pip without first uninstalling, the installer warns you to uninstall first." -msgstr "pip の制限により、ansible-2.9 以前から ansible-2.10 以降には ``pip install --upgrade`` を行うことができません。代わりに、pip で新しいバージョンをインストールする前に ``pip uninstall ansible`` を明示的に使用する必要があります。最初にアンインストールせずに pip で Ansible をアップグレードする場合は、インストーラーが最初にアンインストールを警告します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:449 -#, python-format -msgid "The individual collections that make up the ansible-2.10.0 package can be viewed independently. However, they are not currently listed by ansible-galaxy. To view these collections with ansible-galaxy, explicitly specify where ansible has installed the collections -- ``COLLECTION_INSTALL=$(python -c 'import ansible, os.path ; print(\"%s/../ansible_collections\" % os.path.dirname(ansible.__file__))') ansible-galaxy collection list -p \"$COLLECTION_INSTALL\"``." -msgstr "ansible-2.10.0 パッケージを構成する個々のコレクションは個別に表示できますが、現在 ansible-galaxy により一覧表示されていません。ansible-galaxy でこれらのコレクションを表示するには、ansible がコレクションをインストールした場所を明示的に指定します。``COLLECTION_INSTALL=$(python -c 'import ansible, os.path ; print(\"%s/../ansible_collections\" % os.path.dirname(ansible.__file__))') ansible-galaxy collection list -p \"$COLLECTION_INSTALL\"``" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:450 -msgid "These fortios modules are not automatically redirected from their 2.9.x names to the new 2.10.x names within collections. You must modify your playbooks to use fully qualified collection names for them. You can use the documentation (https://docs.ansible.com/ansible/2.10/collections/fortinet/fortios/) for the ``fortinet.fortios`` collection to determine what the fully qualified collection names are." -msgstr "これらの fortios モジュールは、コレクション内で 2.9.x の名前から新しい 2.10.x の名前に自動的にリダイレクトされません。これらのモジュールに完全修飾コレクション名を使用するように Playbook を変更する必要があります。完全修飾コレクション名については、``fortinet.fortios`` コレクションのドキュメント (https://docs.ansible.com/ansible/2.10/collections/fortinet/fortios/)) を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:452 -msgid "fortios_address" -msgstr "fortios_address" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:453 -msgid "fortios_config" -msgstr "fortios_config" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:454 -msgid "fortios_firewall_DoS_policy" -msgstr "fortios_firewall_DoS_policy" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:455 -msgid "fortios_firewall_DoS_policy6" -msgstr "fortios_firewall_DoS_policy6" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:456 -msgid "fortios_ipv4_policy" -msgstr "fortios_ipv4_policy" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:457 -msgid "fortios_switch_controller_802_1X_settings" -msgstr "fortios_switch_controller_802_1X_settings" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:458 -msgid "fortios_switch_controller_security_policy_802_1X" -msgstr "fortios_switch_controller_security_policy_802_1X" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:459 -msgid "fortios_system_firmware_upgrade" -msgstr "fortios_system_firmware_upgrade" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:460 -msgid "fortios_system_nd_proxy" -msgstr "fortios_system_nd_proxy" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:461 -msgid "fortios_webfilter" -msgstr "fortios_webfilter" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:464 -#: ../../rst/porting_guides/porting_guide_2.10.rst:658 -msgid "community.grafana" -msgstr "community.grafana" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:466 -msgid "grafana_datasource doesn't set password correctly (#113)" -msgstr "grafana_datasource でパスワードが正しく設定されない (#113)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:471 -msgid "cisco.nxos.nxos_igmp_interface - no longer supports the deprecated ``oif_prefix`` and ``oif_source`` options. These have been superseded by ``oif_ps``." -msgstr "cisco.nxos.nxos_igmp_interface - 非推奨の ``oif_prefix`` オプションおよび ``oif_source`` オプションをサポートしなくなりました。これらは ``oif_ps`` に置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:472 -msgid "community.grafana.grafana_dashboard - the parameter ``message`` is renamed to ``commit_message`` since ``message`` is used by Ansible Core engine internally." -msgstr "community.grafana.grafana_dashboard - ``message`` は内部的に Ansible Core Engine で使用されるため、パラメーター ``message`` の名前が ``commit_message`` に変更されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:473 -msgid "purestorage.flashblade.purefb_fs - no longer supports the deprecated ``nfs`` option. This has been superseded by ``nfsv3``." -msgstr "purestorage.flashblade.purefb_fs - 非推奨の ``nfs`` オプションに対応しなくなりました。これは ``nfsv3`` に置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:476 -#: ../../rst/porting_guides/porting_guide_2.10.rst:627 -#: ../../rst/porting_guides/porting_guide_2.10.rst:863 -msgid "amazon.aws" -msgstr "amazon.aws" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:478 -msgid "aws_s3 - can now delete versioned buckets even when they are not empty - set mode to delete to delete a versioned bucket and everything in it." -msgstr "aws_s3 - バージョンアップされたバケットが空でなくても削除できるようになりました。モードを delete に設定すると、バージョンアップされたバケットとその中のものがすべて削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:481 -#: ../../rst/porting_guides/porting_guide_2.10.rst:799 -#: ../../rst/porting_guides/porting_guide_2.10.rst:882 -msgid "ansible.windows" -msgstr "ansible.windows" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:483 -msgid "setup - Make sure ``ansible_date_time.epoch`` is seconds since EPOCH in UTC to mirror the POSIX facts. The ``ansible_date_time.epoch_local`` contains seconds since EPOCH in the local timezone for backwards compatibility" -msgstr "setup - POSIX ファクトを反映させるために、``ansible_date_time.epoch`` が UTC の EPOCH 以降の秒数であることを確認します。後方互換のために、``ansible_date_time.epoch_local`` には、ローカルタイムゾーンの EPOCH 以降の秒数が含まれています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:484 -msgid "setup - Will now add the IPv6 scope on link local addresses for ``ansible_ip_addresses``" -msgstr "setup - ``ansible_ip_addresses`` のリンクローカルアドレスに IPv6 スコープを追加します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:485 -msgid "setup - ``ansible_processor`` will now return the index before the other values to match the POSIX fact behaviour" -msgstr "setup - ``ansible_processor`` が、POSIX ファクトの動作に一致するために他の値の前にインデックスを返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:486 -msgid "win_find - No longer filters by size on directories, this feature had a lot of bugs, slowed down the module, and not a supported scenario with the ``find`` module." -msgstr "win_find - ディレクトリーにおいてサイズでフィルターが設定されるようになり、この機能はバグが多くなり、モジュールの速度が低下し、``find`` モジュールでの対応シナリオはありません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:489 -msgid "win_find - module has been refactored to better match the behaviour of the ``find`` module. Here is what has changed:" -msgstr "win_find - モジュールは、``find`` モジュールの動作に合わせてリファクタリングされました。これが変更になりました:" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:488 -msgid "When the directory specified by ``paths`` does not exist or is a file, it will no longer fail and will just warn the user" -msgstr "``paths`` で指定されたディレクトリーが存在しないか、ファイルであると、失敗しなくなり、ユーザーに警告が表示されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:489 -msgid "Junction points are no longer reported as ``islnk``, use ``isjunction`` to properly report these files. This behaviour matches the win_stat module" -msgstr "ジャンクションポイントは ``islnk`` として報告されなくなりました。これらのファイルを正しく報告するには ``isjunction`` を使用してください。この動作は win_stat モジュールと一致します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:490 -msgid "Directories no longer return a ``size``, this matches the ``stat`` and ``find`` behaviour and has been removed due to the difficulties in correctly reporting the size of a directory" -msgstr "ディレクトリーが ``size`` を返さなくなりました。これは ``stat`` および ``find`` の動作と一致し、ディレクトリーのサイズを正しく報告することが困難であるため、削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:491 -msgid "win_user - Change idempotency checks for ``description`` to be case sensitive" -msgstr "win_user - 大文字と小文字を区別するために ``description`` の冪等性チェックを変更します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:492 -msgid "win_user - Change idempotency checks for ``fullname`` to be case sensitive" -msgstr "win_user - 大文字と小文字を区別するために ``fullname`` の冪等性チェックを変更します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:495 -#: ../../rst/porting_guides/porting_guide_2.10.rst:642 -msgid "cisco.meraki" -msgstr "cisco.meraki" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:497 -msgid "meraki_device - Changed tags from string to list" -msgstr "meraki_device - 文字列からリストにタグを変更しました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:498 -msgid "meraki_device - Removed serial_lldp_cdp parameter" -msgstr "meraki_device - serial_lldp_cdp パラメーターを削除しました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:499 -msgid "meraki_device - Removed serial_uplink parameter" -msgstr "meraki_device - serial_uplink パラメーターを削除しました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:500 -msgid "meraki_intrusion_prevention - Rename whitedlisted_rules to allowed_rules" -msgstr "meraki_intrusion_prevention - whitedlisted_rules の名前を allowed_rules に変更します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:501 -msgid "meraki_mx_l3_firewall - Rule responses are now in a `rules` list" -msgstr "meraki_mx_l3_firewall - ルール応答が `rules` リストに表示されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:502 -msgid "meraki_mx_l7_firewall - Rename blacklisted_countries to blocked_countries" -msgstr "meraki_mx_l7_firewall - blocked_countries の名前を blacklisted_countries に変更します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:503 -msgid "meraki_mx_l7_firewall - Rename whitelisted_countries to allowed_countries" -msgstr "meraki_mx_l7_firewall - whitelisted_countries の名前を allowed_countries に変更します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:504 -msgid "meraki_network - Local and remote status page settings cannot be set during network creation" -msgstr "meraki_network - ネットワークの作成時にローカルおよびリモートステータスページ設定を設定できません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:505 -msgid "meraki_network - `disableRemoteStatusPage` response is now `remote_status_page_enabled`" -msgstr "meraki_network - `disableRemoteStatusPage` の応答が `remote_status_page_enabled` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:506 -msgid "meraki_network - `disable_my_meraki_com` response is now `local_status_page_enabled`" -msgstr "meraki_network - `disable_my_meraki_com` の応答が `local_status_page_enabled` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:507 -msgid "meraki_network - `disable_my_meraki` has been deprecated" -msgstr "meraki_network - `disable_my_meraki` が非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:508 -msgid "meraki_network - `enable_my_meraki` is now called `local_status_page_enabled`" -msgstr "meraki_network - `enable_my_meraki` が `local_status_page_enabled` と呼ばれるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:509 -msgid "meraki_network - `enable_remote_status_page` is now called `remote_status_page_enabled`" -msgstr "meraki_network - `enable_remote_status_page` が `remote_status_page_enabled` と呼ばれるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:510 -msgid "meraki_network - `enabled` response for VLAN status is now `vlans_enabled`" -msgstr "meraki_network - VLAN ステータスに対する `enabled` 応答が `vlans_enabled` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:511 -msgid "meraki_network - `tags` and `type` now return a list" -msgstr "meraki_network - `tags` および `type` が一覧を返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:512 -msgid "meraki_snmp - peer_ips is now a list" -msgstr "meraki_snmp - peer_ips がリストになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:513 -msgid "meraki_switchport - `access_policy_number` is now an int and not a string" -msgstr "meraki_switchport - `access_policy_number` は文字列型ではなく int 型になりました" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:514 -msgid "meraki_switchport - `tags` is now a list and not a string" -msgstr "meraki_switchport - `tags` が文字列型ではなくリスト型になりました" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:515 -msgid "meraki_webhook - Querying test status now uses state of query." -msgstr "meraki_webhook - テストステータスのクエリーはクエリー状態を使用するようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:520 -msgid "The environment variable for the auth context for the oc.py connection plugin has been corrected (K8S_CONTEXT). It was using an initial lowercase k by mistake. (https://github.com/ansible-collections/community.general/pull/377)." -msgstr "oc.py 接続プラグインの認証コンテキストの環境変数 (K8S_CONTEXT) が修正されました。これは、最初の小文字の k を間違って使用していました (https://github.com/ansible-collections/community.general/pull/377)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:521 -msgid "bigpanda - the parameter ``message`` was renamed to ``deployment_message`` since ``message`` is used by Ansible Core engine internally." -msgstr "bigpanda - ``message`` は Ansible Core Engine で内部的に使用されているため、パラメーター ``message`` は ``deployment_message`` に変更されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:522 -msgid "cisco_spark - the module option ``message`` was renamed to ``msg``, as ``message`` is used internally in Ansible Core engine (https://github.com/ansible/ansible/issues/39295)" -msgstr "cisco_spark - Ansible Core エンジンで ``message`` が内部で使用されるため、モジュールオプション ``message`` の名前が ``msg`` に変更されました (https://github.com/ansible/ansible/issues/39295)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:523 -msgid "datadog - the parameter ``message`` was renamed to ``notification_message`` since ``message`` is used by Ansible Core engine internally." -msgstr "datadog - ``message`` は Ansible Core Engine で内部的に使用されているため、パラメーターの名前 ``message`` は ``notification_message`` に変更されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:524 -msgid "docker_container - no longer passes information on non-anonymous volumes or binds as ``Volumes`` to the Docker daemon. This increases compatibility with the ``docker`` CLI program. Note that if you specify ``volumes: strict`` in ``comparisons``, this could cause existing containers created with docker_container from Ansible 2.9 or earlier to restart." -msgstr "docker_container - 匿名でないボリュームの情報や ``Volumes`` としてのバインドを Docker デーモンに渡さなくなりました。これにより、``docker`` CLI プログラムとの互換性が高まりました。なお、``comparisons`` に``volumes: strict`` を指定すると、Ansible 2.9 以前の docker_container で作成された既存のコンテナーが再起動する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:525 -msgid "docker_container - support for port ranges was adjusted to be more compatible to the ``docker`` command line utility: a one-port container range combined with a multiple-port host range will no longer result in only the first host port be used, but the whole range being passed to Docker so that a free port in that range will be used." -msgstr "docker_container - ポート範囲のサポートは、``docker`` コマンドラインユーティリティーとの互換性を高めるために調整されました。1 ポートのコンテナー範囲と複数ポートのホスト範囲を組み合わせた場合は、最初のホストポートのみが使用されることはなくなり、範囲全体が Docker に渡され、その範囲内の空きポートが使用されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:526 -msgid "hashi_vault lookup - now returns the latest version when using the KV v2 secrets engine. Previously, it returned all versions of the secret which required additional steps to extract and filter the desired version." -msgstr "hashi_vault lookup - KV v2 シークレットエンジンを使用する際に、最新バージョンを返すようになりました。これまでは、すべてのバージョンのシークレットが返されていたため、目的のバージョンを抽出してフィルタリングするための追加手順が必要でした。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:527 -#: ../../rst/porting_guides/porting_guide_3.rst:86 -msgid "log_plays callback - add missing information to the logs generated by the callback plugin. This changes the log message format (https://github.com/ansible-collections/community.general/pull/442)." -msgstr "log_plays callback - callback プラグインで生成されたログに不足している情報を追加します。これにより、ログメッセージの形式が変更されます (https://github.com/ansible-collections/community.general/pull/442)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:528 -#: ../../rst/porting_guides/porting_guide_3.rst:88 -msgid "pkgng - passing ``name: *`` with ``state: absent`` will no longer remove every installed package from the system. It is now a noop. (https://github.com/ansible-collections/community.general/pull/569)." -msgstr "pkgng - ``name: *`` に ``state: absent`` を渡すと、インストール済みパッケージがすべてシステムから削除されなくなり、noop になりました (https://github.com/ansible-collections/community.general/pull/569)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:529 -#: ../../rst/porting_guides/porting_guide_3.rst:89 -msgid "pkgng - passing ``name: *`` with ``state: latest`` or ``state: present`` will no longer install every package from the configured package repositories. Instead, ``name: *, state: latest`` will upgrade all already-installed packages, and ``name: *, state: present`` is a noop. (https://github.com/ansible-collections/community.general/pull/569)." -msgstr "pkgng - ``name: *`` に ``state: latest`` または``state: present`` を渡すと、設定されたパッケージリポジトリーからすべてのパッケージをインストールしなくなります。代わりに、``name: *, state: latest`` は既にインストールされているパッケージをすべてアップグレードし、``name: *, state: present`` は noop です (https://github.com/ansible-collections/community.general/pull/569)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:534 -msgid "routeros_facts - allow multiple addresses and neighbors per interface. This makes ``ansible_net_neighbors`` a list instead of a dict (https://github.com/ansible-collections/community.network/pull/6)." -msgstr "routeros_facts - インターフェースごとに複数のアドレスと近接アドレスを許可します。これにより、``ansible_net_neighbors`` が dict ではなく list になります (https://github.com/ansible-collections/community.network/pull/6)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:539 -msgid "vmware_datastore_maintenancemode - now returns ``datastore_status`` instead of Ansible internal key ``results``." -msgstr "vmware_datastore_maintenancemode - Ansible 内部キー ``results`` の代わりに ``datastore_status`` を返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:540 -msgid "vmware_guest_custom_attributes - does not require VM name which was a required parameter for releases prior to Ansible 2.10." -msgstr "vmware_guest_custom_attributes - Ansible 2.10 より前のリリースで必須だったパラメーターである仮想マシン名は必要ありません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:541 -msgid "vmware_guest_find - the ``datacenter`` option has been removed." -msgstr "vmware_guest_find - ``datacenter`` オプションは削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:542 -msgid "vmware_host_kernel_manager - now returns ``host_kernel_status`` instead of Ansible internal key ``results``." -msgstr "vmware_host_kernel_manager - Ansible 内部キー ``results`` の代わりに ``host_kernel_status`` を返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:543 -msgid "vmware_host_ntp - now returns ``host_ntp_status`` instead of Ansible internal key ``results``." -msgstr "vmware_host_ntp - Ansible 内部キー ``results`` の代わりに ``host_ntp_status`` を返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:544 -msgid "vmware_host_service_manager - now returns ``host_service_status`` instead of Ansible internal key ``results``." -msgstr "vmware_host_service_manager - Ansible 内部キー ``results`` の代わりに ``host_service_status`` を返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:545 -msgid "vmware_tag - now returns ``tag_status`` instead of Ansible internal key ``results``." -msgstr "vmware_tag - Ansible 内部キー ``results`` の代わりに ``tag_status`` を返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:546 -msgid "vmware_vmkernel - the options ``ip_address`` and ``subnet_mask`` have been removed; use the suboptions ``ip_address`` and ``subnet_mask`` of the ``network`` option instead." -msgstr "vmware_vmkernel - ``ip_address`` オプションおよび ``subnet_mask`` オプションが削除されました。代わりに ``network`` オプションのサブオプション ``ip_address`` および ``subnet_mask`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:549 -#: ../../rst/porting_guides/porting_guide_2.10.rst:835 -msgid "community.windows" -msgstr "community.windows" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:551 -msgid "win_pester - no longer runs all ``*.ps1`` file in the directory specified due to it executing potentially unknown scripts. It will follow the default behaviour of only running tests for files that are like ``*.tests.ps1`` which is built into Pester itself." -msgstr "win_pester - 未知のスクリプトを実行する可能性があるため、指定したディレクトリー内のすべての ``*.ps1`` ファイルを実行しなくなりました。Pester 自体に組み込まれている ``*.tests.ps1`` のようなファイルに対してのみテストを実行するというデフォルトの動作に従います。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:554 -#: ../../rst/porting_guides/porting_guide_2.10.rst:953 -msgid "community.zabbix" -msgstr "community.zabbix" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:556 -msgid "zabbix_javagateway - options ``javagateway_pidfile``, ``javagateway_listenip``, ``javagateway_listenport`` and ``javagateway_startpollers`` renamed to ``zabbix_javagateway_xyz`` (see `UPGRADE.md `_)." -msgstr "zabbix_javagateway - ``javagateway_pidfile`` オプション、``javagateway_listenip`` オプション、``javagateway_listenport``、および ``javagateway_startpollers`` オプションの名前が ``zabbix_javagateway_xyz`` に変更されています (`UPGRADE.md `_ を参照してください)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:561 -msgid "Change ``ip-addresses`` key in netbox inventory plugin to ``ip_addresses`` (https://github.com/netbox-community/ansible_modules/issues/139)" -msgstr "netbox インベントリープラグインの ``ip-addresses`` キーを ``ip_addresses`` に変更します (https://github.com/netbox-community/ansible_modules/issues/139)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:562 -msgid "Changed ``group`` to ``tenant_group`` in ``netbox_tenant.py`` (https://github.com/netbox-community/ansible_modules/issues/9)" -msgstr "``netbox_tenant.py`` の ``group`` を ``tenant_group`` へ変更しました (https://github.com/netbox-community/ansible_modules/issues/9)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:563 -msgid "Changed ``role`` to ``prefix_role`` in ``netbox_prefix.py`` (https://github.com/netbox-community/ansible_modules/issues/9)" -msgstr "``netbox_prefix.py`` の ``role`` を ``prefix_role`` へ変更しました (https://github.com/netbox-community/ansible_modules/issues/9)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:564 -msgid "Module failures when required fields aren't provided (https://github.com/netbox-community/ansible_modules/issues/24)" -msgstr "必須フィールドが提供されていない場合のモジュールの失敗 (https://github.com/netbox-community/ansible_modules/issues/24)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:565 -msgid "Renamed ``netbox_interface`` to ``netbox_device_interface`` (https://github.com/netbox-community/ansible_modules/issues/9)" -msgstr "``netbox_interface`` の名前が ``netbox_device_interface`` に変更 (https://github.com/netbox-community/ansible_modules/issues/9)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:566 -msgid "This version has a few breaking changes due to new namespace and collection name. I felt it necessary to change the name of the lookup plugin and inventory plugin just not to have a non descriptive namespace call to use them. Below is an example: ``netbox.netbox.netbox`` would be used for both inventory plugin and lookup plugin, but in different contexts so no collision will arise, but confusion will. I renamed the lookup plugin to ``nb_lookup`` so it will be used with the FQCN ``netbox.netbox.nb_lookup``. The inventory plugin will now be called within an inventory file by ``netbox.netbox.nb_inventory``" -msgstr "このバージョンには、新しい名前空間とコレクション名のためにいくつかの重大な変更があります。lookup プラグインと inventory プラグインの名前を変更して、それを使用するための非記述的な名前空間呼び出しを行わないようにする必要があると感じました。以下に例を示します。inventory プラグインと lookup プラグインの両方に ``netbox.netbox.netbox`` が使用されますが、コンテキストが異なるため、衝突は発生しませんが、混乱が発生します。lookup プラグインの名前を ``nb_lookup`` に変更しました。そのため、FQCN ``netbox.netbox.nb_lookup`` で使用されます。インベントリープラグインは、インベントリーファイル内で ``netbox.netbox.nb_inventory`` により呼び出されるようになります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:570 -msgid "To pass in integers via Ansible Jinja filters for a key in ``data`` that requires querying an endpoint is now done by making it a dictionary with an ``id`` key. The previous behavior was to just pass in an integer and it was converted when normalizing the data, but some people may have names that are all integers and those were being converted erroneously so we made the decision to change the method to convert to an integer for the NetBox API." -msgstr "エンドポイントへの問い合わせが必要な ``data`` のキーに対して、Ansible Jinja のフィルターで整数を渡すためには、``id`` キーを持つディクショナリーにすることで行うようになりました。これまでの動作では、整数を渡すだけでデータの正規化時に変換されていましたが、人によっては名前がすべて整数である場合があり、それらが誤って変換されていたため、NetBox API では整数に変換する方法に変更することにしました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:593 -msgid "``pynetbox`` changed to using ``requests.Session()`` to manage the HTTP session which broke passing in ``ssl_verify`` when building the NetBox API client. This PR makes ``pynetbox 5.0.4+`` the new required version of `pynetbox` for the Ansible modules and lookup plugin. (https://github.com/netbox-community/ansible_modules/pull/269)" -msgstr "``pynetbox`` は、NetBox API クライアントを構築する際に ``ssl_verify`` を渡すことができなくなったため、HTTP セッションの管理に ``requests.Session()`` を使用するように変更しました。この PR により、``pynetbox 5.0.4+`` は、Ansible モジュールと lookup プラグインに必要な `pynetbox` の新しいバージョンとなりました (https://github.com/netbox-community/ansible_modules/pull/269)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:599 -msgid "theforeman.foreman" -msgstr "theforeman.foreman" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:601 -msgid "All modules were renamed to drop the ``foreman_`` and ``katello_`` prefixes. Additionally to the prefix removal, the following modules were further ranamed:" -msgstr "すべてのモジュールの名前が ``foreman_`` 接頭辞および ``katello_`` 接頭辞を削除するように変更されました。接頭辞の削除以外に、以下のモジュールの名前がさらに無視されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:604 -msgid "katello_upload to content_upload" -msgstr "katello_upload から content_upload へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:605 -msgid "katello_sync to repository_sync" -msgstr "katello_sync から repository_sync へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:606 -msgid "katello_manifest to subscription_manifest" -msgstr "katello_manifest から subscription_manifest へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:607 -msgid "foreman_search_facts to resource_info" -msgstr "foreman_search_facts から resource_info へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:608 -msgid "foreman_ptable to partition_table" -msgstr "foreman_ptable から partition_table へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:609 -msgid "foreman_model to hardware_model" -msgstr "foreman_model から hardware_model へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:610 -msgid "foreman_environment to puppet_environment" -msgstr "foreman_environment から puppet_environment へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:618 -msgid "Both ansible-doc and ansible-console's help command will error for modules and plugins whose return documentation cannot be parsed as YAML. All modules and plugins passing ``ansible-test sanity --test yamllint`` will not be affected by this." -msgstr "ansible-doc と ansible-console の help コマンドの両方が、リターンドキュメントが YAML として解析できないモジュールとプラグインに対してエラーを出します。``ansible-test sanity --test yamllint`` を通過するすべてのモジュールとプラグインは、この影響を受けません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:619 -msgid "Collections may declare a list of supported/tested Ansible versions for the collection. A warning is issued if a collection does not support the Ansible version that loads it (can also be configured as silent or a fatal error). Collections that do not declare supported Ansible versions do not issue a warning/error." -msgstr "コレクションは、そのコレクションでサポート/テストされている Ansible のバージョンのリストを宣言することができます。コレクションが、それを読み込む Ansible バージョンをサポートしていない場合は、警告が発行されます (サイレントまたは致命的なエラーとして設定することもできます)。サポートされている Ansible のバージョンを宣言していないコレクションは、警告/エラーを発行しません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:620 -msgid "Plugin routing allows collections to declare deprecation, redirection targets, and removals for all plugin types." -msgstr "プラグインルーティングにより、コレクションはすべてのプラグインタイプの非推奨、リダイレクトターゲット、および削除を宣言できます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:621 -msgid "Plugins that import module_utils and other ansible namespaces that have moved to collections should continue to work unmodified." -msgstr "コレクションに移動した module_utils およびその他の Ansible 名前空間をインポートするプラグインは、変更せずに動作し続けます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:622 -msgid "Routing data built into Ansible 2.10 ensures that 2.9 content should work unmodified on 2.10. Formerly included modules and plugins that were moved to collections are still accessible by their original unqualified names, so long as their destination collections are installed." -msgstr "Ansible 2.10 に組み込まれたルーティングデータにより、2.9 のコンテンツが 2.10 で変更なく動作することが保証されます。コレクションに移動した以前に同梱されているモジュールやプラグインは、移動先のコレクションがインストールされている限り、元の未修飾名でアクセスできます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:623 -msgid "When deprecations are done in code, they to specify a ``collection_name`` so that deprecation warnings can mention which collection - or ansible-base - is deprecating a feature. This affects all ``Display.deprecated()`` or ``AnsibleModule.deprecate()`` or ``Ansible.Basic.Deprecate()`` calls, and ``removed_in_version``/``removed_at_date`` or ``deprecated_aliases`` in module argument specs." -msgstr "コードで非推奨となった場合は、非推奨の警告でどのコレクション (または ansible-base) が機能を非推奨としているかを言及できるように、``collection_name`` を指定する必要があります。これは、すべての ``Display.deprecated()``、``AnsibleModule.deprecate()``、または``Ansible.Basic.Deprecate()`` の呼び出し、およびモジュール引数仕様の ``removed_in_version``/``removed_at_date`` または ``deprecated_aliases`` に影響します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:624 -msgid "ansible-test now uses a different ``default`` test container for Ansible Collections" -msgstr "ansible-test が、Ansible Collections に異なる ``default`` テストコンテナーを使用するようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:629 -msgid "ec2 module_utils - The ``AWSRetry`` decorator no longer catches ``NotFound`` exceptions by default. ``NotFound`` exceptions need to be explicitly added using ``catch_extra_error_codes``. Some AWS modules may see an increase in transient failures due to AWS''s eventual consistency model." -msgstr "ec2 module_utils - ``AWSRetry`` デコレーターは、デフォルトで ``NotFound`` の例外をキャッチしなくなりました。``NotFound`` の例外は、``catch_extra_error_codes`` を使用して明示的に追加する必要があります。一部の AWS モジュールでは、AWS の最終的な一貫性モデルにより、一時的な障害が増加する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:632 -#: ../../rst/porting_guides/porting_guide_2.10.rst:794 -msgid "ansible.netcommon" -msgstr "ansible.netcommon" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:634 -msgid "Add libssh connection plugin and refactor network_cli (https://github.com/ansible-collections/ansible.netcommon/pull/30)" -msgstr "libssh 接続プラグインを追加し、refactor network_cli をリファクタリングします (https://github.com/ansible-collections/ansible.netcommon/pull/30)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:637 -msgid "ansible.posix" -msgstr "ansible.posix" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:639 -msgid "Bootstrap Collection (https://github.com/ansible-collections/ansible.posix/pull/1)." -msgstr "ブートストラップコレクション (https://github.com/ansible-collections/ansible.posix/pull/1)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:644 -msgid "Rewrite requests method for version 1.0 API and improved readability" -msgstr "バージョン 1.0 の API に合わせて requests メソッドを書き換え、読みやすさを向上させました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:645 -msgid "meraki_mr_rf_profile - Configure wireless RF profiles." -msgstr "meraki_mr_rf_profile - ワイヤレス RF プロファイルを設定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:646 -msgid "meraki_mr_settings - Configure network settings for wireless." -msgstr "meraki_mr_settings - ワイヤレスのネットワーク設定を構成します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:647 -msgid "meraki_ms_l3_interface - New module" -msgstr "meraki_ms_l3_interface - 新しいモジュール" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:648 -msgid "meraki_ms_ospf - Configure OSPF." -msgstr "meraki_ms_ospf - OSPF を設定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:653 -msgid "docker_container - the ``network_mode`` option will be set by default to the name of the first network in ``networks`` if at least one network is given and ``networks_cli_compatible`` is ``true`` (will be default from community.general 2.0.0 on). Set to an explicit value to avoid deprecation warnings if you specify networks and set ``networks_cli_compatible`` to ``true``. The current default (not specifying it) is equivalent to the value ``default``." -msgstr "docker_container -``network_mode`` オプションは、少なくとも 1 つのネットワークが指定され、``networks_cli_compatible`` が``true`` である場合は、``networks`` の最初のネットワークの名前がデフォルトで設定されます (community.general 2.0.0 以降はデフォルトになります)。ネットワークを指定して ``networks_cli_compatible`` を ``true`` に設定した場合の非推奨警告を回避するために、明示的な値に設定します。現在のデフォルト (指定なし) は、``default`` の値と同等です。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:654 -msgid "docker_container - the module has a new option, ``container_default_behavior``, whose default value will change from ``compatibility`` to ``no_defaults``. Set to an explicit value to avoid deprecation warnings." -msgstr "docker_container - モジュールには新しいオプション ``container_default_behavior`` があり、そのデフォルト値は ``compatibility`` から ``no_defaults`` に変更になります。非推奨の警告を回避するために明示的な値を設定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:655 -msgid "gitlab_user - no longer requires ``name``, ``email`` and ``password`` arguments when ``state=absent``." -msgstr "gitlab_user - ``state=absent`` の場合に ``name`` 引数、``email`` 引数、および ``password`` 引数が必要なくなりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:660 -msgid "Add changelog management for ansible 2.10 (#112)" -msgstr "Ansible 2.10 の changelog 管理を追加 (#112)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:661 -msgid "grafana_datasource ; adding additional_json_data param" -msgstr "grafana_datasource - additional_json_data パラメーターの追加" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:666 -msgid "Add changelog and fragments and document changelog process (https://github.com/ansible-collections/community.kubernetes/pull/131)." -msgstr "変更ログおよびフラグメントを追加し、変更ログプロセスを文書化します (https://github.com/ansible-collections/community.kubernetes/pull/131)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:667 -msgid "helm - New module for managing Helm charts (https://github.com/ansible-collections/community.kubernetes/pull/61)." -msgstr "helm - Helm チャート管理用の新規モジュール (https://github.com/ansible-collections/community.kubernetes/pull/61)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:668 -msgid "helm_info - New module for retrieving Helm chart information (https://github.com/ansible-collections/community.kubernetes/pull/61)." -msgstr "helm_info - Helm チャート情報を取得する新規モジュール (https://github.com/ansible-collections/community.kubernetes/pull/61)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:669 -msgid "helm_plugin - new module to manage Helm plugins (https://github.com/ansible-collections/community.kubernetes/pull/154)." -msgstr "helm_plugin - Helm プラグインを管理する新しいモジュール (https://github.com/ansible-collections/community.kubernetes/pull/154)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:670 -msgid "helm_plugin_info - new modules to gather information about Helm plugins (https://github.com/ansible-collections/community.kubernetes/pull/154)." -msgstr "helm_plugin_info - Helm プラグインに関する情報を収集する新しいモジュール (https://github.com/ansible-collections/community.kubernetes/pull/154)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:671 -msgid "helm_repository - New module for managing Helm repositories (https://github.com/ansible-collections/community.kubernetes/pull/61)." -msgstr "helm_repository - Helm リポジトリーを管理するための新規モジュール (https://github.com/ansible-collections/community.kubernetes/pull/61)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:672 -#: ../../rst/porting_guides/porting_guide_3.rst:204 -msgid "k8s - Inventory source migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s - Ansible 2.9 から Kubernetes コレクションに移行したインベントリーソース。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:673 -#: ../../rst/porting_guides/porting_guide_3.rst:205 -msgid "k8s - Lookup plugin migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s - Ansible 2.9 から Kubernetes コレクションに移行したプラグイン。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:674 -#: ../../rst/porting_guides/porting_guide_3.rst:206 -msgid "k8s - Module migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s - Ansible 2.9 から Kubernetes コレクションに移行したモジュール。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:675 -#: ../../rst/porting_guides/porting_guide_3.rst:208 -msgid "k8s_auth - Module migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s_auth - Ansible 2.9 から Kubernetes コレクションに移行したモジュール。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:676 -#: ../../rst/porting_guides/porting_guide_3.rst:209 -msgid "k8s_config_resource_name - Filter plugin migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s_config_resource_name - Ansible 2.9 から Kubernetes コレクションに移行したプラグインにフィルターを設定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:677 -msgid "k8s_exec - New module for executing commands on pods via Kubernetes API (https://github.com/ansible-collections/community.kubernetes/pull/14)." -msgstr "k8s_exec - Kubernetes API を使用して Pod でコマンドを実行する新規モジュール (https://github.com/ansible-collections/community.kubernetes/pull/14)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:678 -msgid "k8s_exec - Return rc for the command executed (https://github.com/ansible-collections/community.kubernetes/pull/158)." -msgstr "k8s_exec - 実行したコマンドの rc を返します (https://github.com/ansible-collections/community.kubernetes/pull/158)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:679 -#: ../../rst/porting_guides/porting_guide_3.rst:212 -msgid "k8s_info - Module migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s_info - Ansible 2.9 から Kubernetes コレクションに移行したモジュール。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:680 -msgid "k8s_log - New module for retrieving pod logs (https://github.com/ansible-collections/community.kubernetes/pull/16)." -msgstr "k8s_log - Pod ログを取得する新規モジュール (https://github.com/ansible-collections/community.kubernetes/pull/16)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:681 -#: ../../rst/porting_guides/porting_guide_3.rst:214 -msgid "k8s_scale - Module migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s_scale - Ansible 2.9 から Kubernetes コレクションに移行したモジュール。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:682 -#: ../../rst/porting_guides/porting_guide_3.rst:215 -msgid "k8s_service - Module migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s_service - Ansible 2.9 から Kubernetes コレクションに移行したモジュール。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:683 -#: ../../rst/porting_guides/porting_guide_3.rst:216 -msgid "kubectl - Connection plugin migrated from Ansible 2.9 to Kubernetes collection." -msgstr "kubectl - Ansible 2.9 から Kubernetes コレクションに移行した接続プラグイン。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:684 -#: ../../rst/porting_guides/porting_guide_3.rst:217 -msgid "openshift - Inventory source migrated from Ansible 2.9 to Kubernetes collection." -msgstr "openshift - Ansible 2.9 から Kubernetes コレクションに移行したインベントリーソース。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:687 -msgid "community.libvirt" -msgstr "community.libvirt" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:689 -msgid "added generic libvirt inventory plugin" -msgstr "汎用 libvirt インベントリープラグインの追加" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:690 -msgid "removed libvirt_lxc inventory script" -msgstr "libvirt_lxc インベントリースクリプトを削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:693 -#: ../../rst/porting_guides/porting_guide_3.rst:131 -#: ../../rst/porting_guides/porting_guide_3.rst:182 -msgid "dellemc.os10" -msgstr "dellemc.os10" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:695 -msgid "New role os10_aaa - Facilitates the configuration of Authentication Authorization and Accounting (AAA), TACACS and RADIUS server." -msgstr "新しいロール os10_aaa - 認証承認およびアカウント (AAA)、TACACS サーバーおよび RADIUS サーバーの設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:696 -msgid "New role os10_acl - Facilitates the configuration of Access Control lists." -msgstr "新しいロール os10_acl - アクセス制御リストの設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:697 -msgid "New role os10_bfd - Facilitates the configuration of BFD global attributes." -msgstr "新しいロール os10_bfd - BFD グローバル属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:698 -msgid "New role os10_bgp - Facilitates the configuration of border gateway protocol (BGP) attributes." -msgstr "新しいロール os10_bgp - 境界線ゲートウェイプロトコル (BGP) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:699 -msgid "New role os10_copy_config - This role pushes the backup running configuration into a OS10 device." -msgstr "新しいロール os10_copy_config - このロールは、バックアップの実行設定を OS10 デバイスにプッシュします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:700 -msgid "New role os10_dns - Facilitates the configuration of domain name service (DNS)." -msgstr "新しいロール os10_dns - ドメインネームサービス (DNS) の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:701 -msgid "New role os10_ecmp - Facilitates the configuration of equal cost multi-path (ECMP) for IPv4." -msgstr "新しいロール os10_ecmp - IPv4 用の同等のコストマルチパス (ECMP) の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:702 -msgid "New role os10_fabric_summary Facilitates to get show system information of all the OS10 switches in the fabric." -msgstr "新しいロール os10_fabric_summary - ファブリック内のすべての OS10 スイッチのシステム情報を表示するのを容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:703 -msgid "New role os10_flow_monitor Facilitates the configuration of ACL flow-based monitoring attributes." -msgstr "新しいロール os10_flow_monitor - ACL フローベースの監視属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:704 -msgid "New role os10_image_upgrade Facilitates installation of OS10 software images." -msgstr "新しいロール os10_image_upgrade - OS10 ソフトウェアイメージのインストールを容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:705 -msgid "New role os10_interface Facilitates the configuration of interface attributes." -msgstr "新しいロール os10_interface - インターフェース属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:706 -msgid "New role os10_lag Facilitates the configuration of link aggregation group (LAG) attributes." -msgstr "新しいロール os10_lag - リンクアグリゲーショングループ (LAG) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:707 -msgid "New role os10_lldp Facilitates the configuration of link layer discovery protocol (LLDP) attributes at global and interface level." -msgstr "新しいロール os10_lldp - グローバルおよびインターフェースレベルでのリンクレイヤー検出プロトコル (LLDP) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:708 -msgid "New role os10_logging Facilitates the configuration of global logging attributes and logging servers." -msgstr "新しいロール os10_logging - グローバルロギング属性およびロギングサーバーの設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:709 -msgid "New role os10_network_validation Facilitates validation of wiring connection, BGP neighbors, MTU between neighbors and VLT pair." -msgstr "新しいロール os10_network_validation - 配線接続、BGP 近接、近接間 MTU、VLT ペアの検証を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:710 -msgid "New role os10_ntp Facilitates the configuration of network time protocol (NTP) attributes." -msgstr "新しいロール os10_ntp - ネットワークタイムプロトコル (NTP) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:711 -msgid "New role os10_prefix_list Facilitates the configuration of IP prefix-list." -msgstr "新しいロール os10_prefix_list - IP プレフィックスリストの設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:712 -msgid "New role os10_qos Facilitates the configuration of quality of service attributes including policy-map and class-map." -msgstr "新しいロール os10_qos - policy-map および class-map を含む QoS (Quality of Service) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:713 -msgid "New role os10_raguard Facilitates the configuration of IPv6 RA Guard attributes." -msgstr "新しいロール os10_raguard - IPv6 RA Guard 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:714 -msgid "New role os10_route_map Facilitates the configuration of route-map attributes." -msgstr "新しいロール os10_route_map - route-map 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:715 -msgid "New role os10_snmp Facilitates the configuration of global SNMP attributes." -msgstr "新しいロール os10_snmp - グローバル SNMP 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:716 -msgid "New role os10_system Facilitates the configuration of hostname and hashing algorithm." -msgstr "新しいロール os10_system - ホスト名とハッシュアルゴリズムの設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:717 -msgid "New role os10_template The role takes the raw string input from the CLI of OS10 device, and returns a structured text in the form of a Python dictionary." -msgstr "新しいロール os10_template - このロールは、OS10 デバイスの CLI から raw 文字列入力を取得し、Python ディクショナリーの形式で構造化されたテキストを返します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:718 -msgid "New role os10_uplink Facilitates the configuration of uplink attributes like uplink-state group." -msgstr "新しいロール os10_uplink - uplink-state グループのようなアップリンク属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:719 -msgid "New role os10_users Facilitates the configuration of global system user attributes." -msgstr "新しいロール os10_users - グローバルシステムユーザー属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:720 -msgid "New role os10_vlan Facilitates the configuration of virtual LAN (VLAN) attributes." -msgstr "新しいロール os10_vlan - 仮想 LAN (VLAN) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:721 -msgid "New role os10_vlt Facilitates the configuration of virtual link trunking (VLT)." -msgstr "新しいロール os10_vlt - 仮想リンクトランク (VLT) の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:722 -msgid "New role os10_vrf Facilitates the configuration of virtual routing and forwarding (VRF)." -msgstr "新しいロール os10_vrf - VRF (Virtual Routing and Forwarding) の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:723 -msgid "New role os10_vrrp Facilitates the configuration of virtual router redundancy protocol (VRRP) attributes." -msgstr "新しいロール os10_vrrp - 仮想ルーター冗長性プロトコル (VRRP) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:724 -msgid "New role os10_vxlan Facilitates the configuration of virtual extensible LAN (VXLAN) attributes." -msgstr "新しいロール os10_vxlan - 仮想拡張可能 LAN (VXLAN) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:725 -msgid "New role os10_xstp Facilitates the configuration of xSTP attributes." -msgstr "新しいロール os10_xstp - xSTP 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:730 -msgid "Broke apart bigip_device_auth_radius to implement radius server configuration in bigip_device_auth_server module. Refer to module documentation for usage details" -msgstr "bigip_device_auth_radius を分割し、radius サーバの設定を bigip_device_auth_server モジュールに実装しました。使用方法の詳細はモジュールのドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:731 -msgid "Remove redundant parameters in f5_provider to fix disparity between documentation and module parameters" -msgstr "f5_provider で冗長なパラメーターを削除して、ドキュメントとモジュールパラメーターの不一致を修正します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:734 -msgid "gluster.gluster" -msgstr "gluster.gluster" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:736 -msgid "geo_rep - Added the independent module of geo rep with other gluster modules (https://github.com/gluster/gluster-ansible-collection/pull/2)." -msgstr "geo_rep - 他の gluster モジュールと、geo rep の独立したモジュールが追加されました (https://github.com/gluster/gluster-ansible-collection/pull/2)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:741 -msgid "ovirt_disk - Add backup (https://github.com/oVirt/ovirt-ansible-collection/pull/57)." -msgstr "ovirt_disk - バックアップ追加します (https://github.com/oVirt/ovirt-ansible-collection/pull/57)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:742 -msgid "ovirt_disk - Support direct upload/download (https://github.com/oVirt/ovirt-ansible-collection/pull/35)." -msgstr "ovirt_disk - 直接アップロード/ダウンロードをサポートします (https://github.com/oVirt/ovirt-ansible-collection/pull/35)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:743 -msgid "ovirt_host - Add ssh_port (https://github.com/oVirt/ovirt-ansible-collection/pull/60)." -msgstr "ovirt_host - ssh_port を追加します (https://github.com/oVirt/ovirt-ansible-collection/pull/60)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:744 -msgid "ovirt_vm_os_info - Creation of module (https://github.com/oVirt/ovirt-ansible-collection/pull/26)." -msgstr "ovirt_vm_os_info - モジュールを作成します (https://github.com/oVirt/ovirt-ansible-collection/pull/26)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:747 -msgid "purestorage.flasharray" -msgstr "purestorage.flasharray" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:749 -msgid "purefa_console - manage Console Lock setting for the FlashArray" -msgstr "purefa_console - FlashArray のコンソールロック設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:750 -msgid "purefa_endpoint - manage VMware protocol-endpoints on the FlashArray" -msgstr "purefa_endpoint - FlashArray で VMware プロトコルエンドポイントを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:751 -msgid "purefa_eula - sign, or resign, FlashArray EULA" -msgstr "purefa_eula - sign または resign、FlashArray EULA" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:752 -msgid "purefa_inventory - get hardware inventory information from a FlashArray" -msgstr "purefa_inventory - FlashArray からハードウェアインベントリー情報を取得します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:753 -msgid "purefa_network - manage the physical and virtual network settings on the FlashArray" -msgstr "purefa_network - FlashArray で物理および仮想ネットワークの設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:754 -msgid "purefa_pgsched - manage protection group snapshot and replication schedules on the FlashArray" -msgstr "purefa_pgsched - FlashArray で保護グループのスナップショットおよびレプリケーションスケジュールを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:755 -msgid "purefa_pod - manage ActiveCluster pods in FlashArrays" -msgstr "purefa_pod - FlashArray で ActiveCluster Pod を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:756 -msgid "purefa_pod_replica - manage ActiveDR pod replica links in FlashArrays" -msgstr "purefa_pod_replica - FlashArray で ActiveDR Pod レプリカリンクを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:757 -msgid "purefa_proxy - manage the phonehome HTTPS proxy setting for the FlashArray" -msgstr "purefa_proxy - FlashArray の phonehome HTTPS プロキシー設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:758 -msgid "purefa_smis - manage SMI-S settings on the FlashArray" -msgstr "purefa_smis - FlashArray で SMI-S 設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:759 -msgid "purefa_subnet - manage network subnets on the FlashArray" -msgstr "purefa_subnet - FlashArray でネットワークサブネットを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:760 -msgid "purefa_timeout - manage the GUI idle timeout on the FlashArray" -msgstr "purefa_timeout - FlashArray で GUI のアイドルタイムアウトを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:761 -msgid "purefa_vlan - manage VLAN interfaces on the FlashArray" -msgstr "purefa_vlan - FlashArray で VLAN インターフェースを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:762 -msgid "purefa_vnc - manage VNC for installed applications on the FlashArray" -msgstr "purefa_vnc - FlashArray にインストールされたアプリケーションの VNC を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:763 -msgid "purefa_volume_tags - manage volume tags on the FlashArray" -msgstr "purefa_volume_tags - FlashArray でボリュームタグを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:766 -msgid "purestorage.flashblade" -msgstr "purestorage.flashblade" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:768 -msgid "purefb_alert - manage alert email settings on a FlashBlade" -msgstr "purefb_alert - FlashBlade でアラートのメール設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:769 -msgid "purefb_bladename - manage FlashBlade name" -msgstr "purefb_bladename - FlashBlade 名を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:770 -msgid "purefb_bucket_replica - manage bucket replica links on a FlashBlade" -msgstr "purefb_bucket_replica - FlashBlade でバケットレプリカリンクを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:771 -msgid "purefb_connect - manage connections between FlashBlades" -msgstr "purefb_connect - FlashBlades 間の接続を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:772 -msgid "purefb_dns - manage DNS settings on a FlashBlade" -msgstr "purefb_dns - FlashBlade で DNS 設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:773 -msgid "purefb_fs_replica - manage filesystem replica links on a FlashBlade" -msgstr "purefb_fs_replica - FlashBlade でファイルシステムレプリカリンクを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:774 -msgid "purefb_inventory - get information about the hardware inventory of a FlashBlade" -msgstr "purefb_inventory - FlashBlade のハードウェアインベントリーに関する情報を取得します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:775 -msgid "purefb_ntp - manage the NTP settings for a FlashBlade" -msgstr "purefb_ntp - FlashBlade の NTP 設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:776 -msgid "purefb_phonehome - manage the phone home settings for a FlashBlade" -msgstr "purefb_phonehome - FlashBlade の電話ホームディレクトリー設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:777 -msgid "purefb_policy - manage the filesystem snapshot policies for a FlashBlade" -msgstr "purefb_policy - FlashBlade のファイルシステムスナップショットポリシーを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:778 -msgid "purefb_proxy - manage the phone home HTTP proxy settings for a FlashBlade" -msgstr "purefb_proxy - FlashBlade の電話ホーム HTTP プロキシー設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:779 -msgid "purefb_remote_cred - manage the Object Store Remote Credentials on a FlashBlade" -msgstr "purefb_remote_cred - FlashBlade でオブジェクトストアのリモート認証情報を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:780 -msgid "purefb_snmp_agent - modify the FlashBlade SNMP Agent" -msgstr "purefb_snmp_agent - FlashBlade SNMP エージェントを変更します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:781 -msgid "purefb_snmp_mgr - manage SNMP Managers on a FlashBlade" -msgstr "purefb_snmp_mgr - FlashBlade で SNMP Manager を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:782 -msgid "purefb_target - manage remote S3-capable targets for a FlashBlade" -msgstr "purefb_target - FlashBlade のリモート S3 対応ターゲットを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:783 -msgid "purefb_user - manage local ``pureuser`` account password on a FlashBlade" -msgstr "purefb_user - FlashBlade でローカルの ``pureuser`` アカウントのパスワードを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:791 -msgid "core - remove support for ``check_invalid_arguments`` in ``AnsibleModule``, ``AzureModule`` and ``UTMModule``." -msgstr "core - ``AnsibleModule``、``AzureModule``、および ``UTMModule`` の ``check_invalid_arguments`` のサポートを削除します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:796 -msgid "module_utils.network.common.utils.ComplexDict has been removed" -msgstr "module_utils.network.common.utils.ComplexDict が削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:801 -msgid "win_stat - removed the deprecated ``get_md55`` option and ``md5`` return value." -msgstr "win_stat - 非推奨の ``get_md55`` オプションと ``md5`` の戻り値を削除します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:804 -#: ../../rst/porting_guides/porting_guide_2.10.rst:919 -msgid "community.crypto" -msgstr "community.crypto" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:806 -msgid "The ``letsencrypt`` module has been removed. Use ``acme_certificate`` instead." -msgstr "``letsencrypt`` モジュールが削除されました。代わりに ``acme_certificate`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:811 -#: ../../rst/porting_guides/porting_guide_3.rst:353 -msgid "conjur_variable lookup - has been moved to the ``cyberark.conjur`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/570)." -msgstr "conjur_variable ルックアップ - ``cyberark.conjur`` コレクションに移動しました。リダイレクトはアクティブで、バージョン 2.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/570)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:812 -msgid "core - remove support for ``check_invalid_arguments`` in ``UTMModule``." -msgstr "core - ``UTMModule`` の ``check_invalid_arguments`` のサポートを削除します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:813 -#: ../../rst/porting_guides/porting_guide_3.rst:354 -msgid "digital_ocean_* - all DigitalOcean modules have been moved to the ``community.digitalocean`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/622)." -msgstr "digital_ocean_* - すべての DigitalOcean モジュールが ``community.digitalocean`` コレクションに移動しました。リダイレクトはアクティブで、バージョン 2.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/622)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:814 -#: ../../rst/porting_guides/porting_guide_3.rst:355 -msgid "infini_* - all infinidat modules have been moved to the ``infinidat.infinibox`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/607)." -msgstr "infini_* - すべての infinidat モジュールが ``infinidat.infinibox`` コレクションに移動されました。リダイレクトはアクティブで、バージョン 2.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/607)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:815 -#: ../../rst/porting_guides/porting_guide_3.rst:357 -msgid "logicmonitor - the module has been removed in 1.0.0 since it is unmaintained and the API used by the module has been turned off in 2017 (https://github.com/ansible-collections/community.general/issues/539, https://github.com/ansible-collections/community.general/pull/541)." -msgstr "logicmonitor - このモジュールは、メンテナンス対象外で、モジュールが使用する API が 2017 年に削除されたため、1.0.0 で削除されました (https://github.com/ansible-collections/community.general/issues/539、https://github.com/ansible-collections/community.general/pull/541)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:816 -#: ../../rst/porting_guides/porting_guide_3.rst:358 -msgid "logicmonitor_facts - the module has been removed in 1.0.0 since it is unmaintained and the API used by the module has been turned off in 2017 (https://github.com/ansible-collections/community.general/issues/539, https://github.com/ansible-collections/community.general/pull/541)." -msgstr "logicmonitor_facts - このモジュールは、メンテナンス対象外で、モジュールが使用する API が 2017 年に削除されたため、1.0.0 で削除されました (https://github.com/ansible-collections/community.general/issues/539、https://github.com/ansible-collections/community.general/pull/541)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:817 -#: ../../rst/porting_guides/porting_guide_3.rst:360 -msgid "mysql_* - all MySQL modules have been moved to the ``community.mysql`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/633)." -msgstr "mysql_* - すべての MySQL モジュールが ``community.mysql`` コレクションに移動しました。リダイレクトはアクティブで、バージョン 2.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/633)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:818 -msgid "pacman - Removed deprecated ``recurse`` option, use ``extra_args=--recursive`` instead" -msgstr "pacman - 非推奨の ``recurse`` オプションを削除しました。代わりに ``extra_args=--recursive`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:819 -#: ../../rst/porting_guides/porting_guide_3.rst:361 -msgid "proxysql_* - all ProxySQL modules have been moved to the ``community.proxysql`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/624)." -msgstr "proxysql_* - すべての ProxySQL モジュールが ``community.proxysql`` コレクションに移動されました。リダイレクトはアクティブで、バージョン 2.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/624)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:824 -#: ../../rst/porting_guides/porting_guide_3.rst:394 -msgid "onyx - all onyx modules and plugins have been moved to the mellanox.onyx collection. Redirects have been added that will be removed in community.network 2.0.0 (https://github.com/ansible-collections/community.network/pull/83)." -msgstr "onyx - すべての onyx モジュールとプラグインは、mellanox.onyx コレクションに移動しました。community.network 2.0.0 で削除される予定のリダイレクトが追加されました (https://github.com/ansible-collections/community.network/pull/83)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:829 -msgid "vmware_guest_find - Removed deprecated ``datacenter`` option" -msgstr "vmware_guest_find - 非推奨の ``datacenter`` オプションを削除しました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:830 -msgid "vmware_portgroup - removed 'inbound_policy', and 'rolling_order' deprecated options." -msgstr "vmware_portgroup - 「inbound_policy」および「rolling_order」の非推奨オプションを削除しました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:831 -msgid "vmware_vmkernel - Removed deprecated ``ip_address`` option; use sub-option ip_address in the network option instead" -msgstr "vms_vmkernel - 非推奨の ``ip_address`` オプション。代わりに network オプションにサブオプション ip_address を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:832 -msgid "vmware_vmkernel - Removed deprecated ``subnet_mask`` option; use sub-option subnet_mask in the network option instead" -msgstr "vmware_vmkernel - 非推奨の ``subnet_mask`` オプションを削除しました。代わりに network オプションにサブオプション subnet_mask を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:837 -msgid "win_disk_image - removed the deprecated return value ``mount_path`` in favour of ``mount_paths``." -msgstr "win_disk_image - 非推奨の戻り値 ``mount_path`` が削除され、``mount_paths`` が変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:838 -msgid "win_psexec - removed the deprecated ``extra_opts`` option." -msgstr "win_psexec - 非推奨の ``extra_opts`` オプションが削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:843 -msgid "Remove _bigip_iapplx_package alias" -msgstr "_bigip_iapplx_package エイリアスの削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:844 -msgid "Remove _bigip_security_address_list alias" -msgstr "_bigip_security_address_list エイリアスの削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:845 -msgid "Remove _bigip_security_port_list alias" -msgstr "_bigip_security_port_list エイリアスの削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:846 -msgid "Remove _bigip_traffic_group alias" -msgstr "_bigip_traffic_group エイリアスの削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:847 -msgid "Remove bigip_appsvcs_extension module" -msgstr "bigip_appsvcs_extension モジュールの削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:848 -msgid "Remove bigip_asm_policy module" -msgstr "bigip_asm_policy モジュールの削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:853 -msgid "The vyos.vyos.vyos_static_route module has been deprecated and will be removed in a later release; use vyos.vyos.vyos_static_routes instead." -msgstr "vyos.vyos.vyos_static_route モジュールは非推奨となり、今後のリリースで削除される予定です。代わりに、vyos.vyos.vyos_static_routes を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:858 -msgid "Using the DefaultCallback without the correspodning doc_fragment or copying the documentation." -msgstr "対応する doc_fragment を使用せずに DefaultCallback を使用、またはドキュメントのコピー" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:859 -msgid "hash_behaviour - Deprecate ``hash_behaviour`` for future removal." -msgstr "hash_behaviour - 今後削除される ``hash_behaviour`` を非推奨にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:860 -msgid "script inventory plugin - The 'cache' option is deprecated and will be removed in 2.12. Its use has been removed from the plugin since it has never had any effect." -msgstr "スクリプトインベントリープラグイン - 「cache」オプションは非推奨になり、2.12 で削除されます。何も効果がないため、その使用はプラグインから削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:865 -msgid "All AWS Modules - ``aws_access_key``, ``aws_secret_key`` and ``security_token`` will be made mutually exclusive with ``profile`` after 2022-06-01." -msgstr "すべての AWS モジュール - ``aws_access_key``、``aws_secret_key``、および ``security_token`` は 2022-06-01 以降に ``profile`` と相互に排他的になります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:866 -#: ../../rst/porting_guides/porting_guide_2.10.rst:894 -msgid "cloudformation - The ``template_format`` option had no effect since Ansible 2.3 and will be removed after 2022-06-01" -msgstr "cloudformation - ``template_format`` オプションは Ansible 2.3 以降には影響しませんが、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:867 -msgid "cloudformation - the ``template_format`` option has been deprecated and will be removed in a later release. It has been ignored by the module since Ansible 2.3." -msgstr "cloudformation - ``template_format`` オプションは非推奨となり、今後のリリースで削除されます。これは Ansible 2.3 以降モジュールによって無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:868 -msgid "data_pipeline - The ``version`` option had no effect and will be removed in after 2022-06-01" -msgstr "data_pipeline - ``version`` オプションは影響を受けず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:869 -msgid "ec2 - in a later release, the ``group`` and ``group_id`` options will become mutually exclusive. Currently ``group_id`` is ignored if you pass both." -msgstr "ec2 - 今後のリリースでは、``group`` オプションと ``group_id`` オプションが相互に排他的になります。現時点では、両方を渡すと ``group_id`` は無視されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:870 -msgid "ec2_ami - The ``no_device`` alias ``NoDevice`` has been deprecated and will be removed after 2022-06-01" -msgstr "ec2_ami - ``no_device`` エイリアス ``NoDevice`` は非推奨となり、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:871 -msgid "ec2_ami - The ``virtual_name`` alias ``VirtualName`` has been deprecated and will be removed after 2022-06-01" -msgstr "ec2_ami - ``virtual_name`` エイリアス ``VirtualName`` は非推奨となり、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:872 -#: ../../rst/porting_guides/porting_guide_2.10.rst:897 -msgid "ec2_eip - The ``wait_timeout`` option had no effect and will be removed after 2022-06-01" -msgstr "ec2_eip - ``wait_timeout`` オプションは影響を受けておらず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:873 -#: ../../rst/porting_guides/porting_guide_2.10.rst:899 -msgid "ec2_key - The ``wait_timeout`` option had no effect and will be removed after 2022-06-01" -msgstr "ec2_key - ``wait_timeout`` オプションは影響を受けておらず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:874 -#: ../../rst/porting_guides/porting_guide_2.10.rst:900 -msgid "ec2_key - The ``wait`` option had no effect and will be removed after 2022-06-01" -msgstr "ec2_key - ``wait`` オプションは影響を受けておらず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:875 -msgid "ec2_key - the ``wait_timeout`` option has been deprecated and will be removed in a later release. It has had no effect since Ansible 2.5." -msgstr "ec2_key - ``wait_timeout`` オプションは非推奨となり、今後のリリースで削除される予定です。Ansible 2.5 以降には変更はありません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:876 -msgid "ec2_key - the ``wait`` option has been deprecated and will be removed in a later release. It has had no effect since Ansible 2.5." -msgstr "ec2_key - ``wait`` オプションは非推奨となり、今後のリリースで削除される予定です。Ansible 2.5 以降には変更はありません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:877 -#: ../../rst/porting_guides/porting_guide_2.10.rst:901 -msgid "ec2_lc - The ``associate_public_ip_address`` option had no effect and will be removed after 2022-06-01" -msgstr "ec2_lc - ``associate_public_ip_address`` オプションは影響を受けておらず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:878 -msgid "ec2_tag - deprecate the ``list`` option in favor of ec2_tag_info" -msgstr "ec2_tag - ``list`` オプションが非推奨になり、ec2_tag_info が採用されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:879 -msgid "ec2_tag - support for ``list`` as a state has been deprecated and will be removed in a later release. The ``ec2_tag_info`` can be used to fetch the tags on an EC2 resource." -msgstr "ec2_tag - 状態としての ``list`` のサポートは非推奨となり、今後のリリースで削除されます。``ec2_tag_info`` を使用すると、EC2 リソースでタグを取得できます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:884 -msgid "win_domain_computer - Deprecated the undocumented ``log_path`` option. This option will be removed in a major release after ``2022-07-01``." -msgstr "win_domain_ computers - ドキュメント化されていない ``log_path`` オプションが非推奨になりました。このオプションは ``2022-07-01`` 後のメジャーリリースで削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:885 -msgid "win_domain_controller - the ``log_path`` option has been deprecated and will be removed in a later release. This was undocumented and only related to debugging information for module development." -msgstr "win_domain_controller - ``log_path`` オプションは非推奨となり、今後のリリースで削除されます。これは文書化されておらず、モジュール開発のデバッグ情報にのみ関連しています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:886 -msgid "win_package - the ``ensure`` alias for the ``state`` option has been deprecated and will be removed in a later release. Please use ``state`` instead of ``ensure``." -msgstr "win_package - ``state`` オプションの ``ensure`` エイリアスは非推奨となり、今後のリリースで削除されます。``ensure`` の代わりに ``state`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:887 -msgid "win_package - the ``productid`` alias for the ``product_id`` option has been deprecated and will be removed in a later release. Please use ``product_id`` instead of ``productid``." -msgstr "win_package - ``product_id`` オプションの ``productid`` エイリアスは非推奨となり、今後のリリースで削除されます。``productid`` の代わりに ``product_id`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:888 -msgid "win_package - the ``username`` and ``password`` options has been deprecated and will be removed in a later release. The same functionality can be done by using ``become: yes`` and ``become_flags: logon_type=new_credentials logon_flags=netcredentials_only`` on the task." -msgstr "win_package - ``username`` オプションおよび ``password`` オプションは非推奨となり、今後のリリースで削除されます。同様に、タスクの ``become: yes`` および ``become_flags: logon_type=new_credentials logon_flags=netcredentials_only`` を使用して実行できます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:889 -msgid "win_regedit - Deprecated using forward slashes as a path separator, use backslashes to avoid ambiguity between a forward slash in the key name or a forward slash as a path separator. This feature will be removed in a major release after ``2021-07-01``." -msgstr "win_regedit - スラッシュをパス区切り文字として使用し、バックスラッシュを使用して、キー名のスラッシュとパス区切りのスラッシュの曖昧さを回避します。この機能は、``2021-07-01`` の後のメジャーリリースで削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:895 -msgid "data_pipeline - The ``version`` option had no effect and will be removed after 2022-06-01" -msgstr "data_pipeline - ``version`` オプションは影響を受けておらず、2022-06-01 以降削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:896 -msgid "data_pipeline - the ``version`` option has been deprecated and will be removed in a later release. It has always been ignored by the module." -msgstr "data_pipeline - ``version`` オプションは非推奨となり、今後のリリースで削除されます。常にモジュールによって無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:898 -msgid "ec2_eip - the ``wait_timeout`` option has been deprecated and will be removed in a later release. It has had no effect since Ansible 2.3." -msgstr "ec2_eip - ``wait_timeout`` オプションは非推奨となり、今後のリリースで削除される予定です。Ansible 2.3 以降は変更されません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:902 -msgid "ec2_lc - the ``associate_public_ip_address`` option has been deprecated and will be removed after a later release. It has always been ignored by the module." -msgstr "ec2_lc - ``associate_public_ip_address`` オプションは非推奨となり、今後のリリースで削除されます。常にモジュールによって無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:903 -msgid "elb_network_lb - The current default value of the ``state`` option has been deprecated and will change from absent to present after 2022-06-01" -msgstr "elb_network_lb - ``state`` オプションの現在のデフォルト値は非推奨となり、2022-06-01 以降に absent から present に変更する予定です。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:904 -msgid "elb_network_lb - in a later release, the default behaviour for the ``state`` option will change from ``absent`` to ``present``. To maintain the existing behavior explicitly set state to ``absent``." -msgstr "elb_network_lb - 今後のリリースでは、``state`` オプションのデフォルト動作が ``absent`` から ``present`` に変更なります。既存の動作を維持するには、状態を明示的に ``absent`` に設定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:905 -msgid "iam_managed_policy - The ``fail_on_delete`` option had no effect and will be removed after 2022-06-01" -msgstr "iam_managed_policy - ``fail_on_delete`` オプションは影響を受けず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:906 -msgid "iam_managed_policy - the ``fail_on_delete`` option has been deprecated and will be removed after a later release. It has always been ignored by the module." -msgstr "iam_managed_policy - ``fail_on_delete`` オプションは非推奨となり、今後のリリースで削除されます。常にモジュールによって無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:907 -msgid "iam_policy - The ``policy_document`` will be removed after 2022-06-01. To maintain the existing behavior use the ``policy_json`` option and read the file with the ``lookup`` plugin." -msgstr "iam_policy - ``policy_document`` は 2022-06-01 以降削除されます。既存の動作を維持するには、``policy_json`` オプションを使用して ``lookup`` プラグインでファイルを読み取ります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:908 -msgid "iam_policy - The default value of ``skip_duplicates`` will change after 2022-06-01 from ``true`` to ``false``." -msgstr "iam_policy -``skip_duplicates`` のデフォルト値は、2022-06-01 以降、``true`` から``false`` に変更になります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:909 -msgid "iam_policy - in a later release, the default value for the ``skip_duplicates`` option will change from ``true`` to ``false``. To maintain the existing behavior explicitly set it to ``true``." -msgstr "iam_policy - 今後のリリースでは、``skip_duplicates`` オプションのデフォルト値が ``true`` から``false`` に変更になります。既存の動作を維持するには、明示的に ``true`` に設定してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:910 -msgid "iam_policy - the ``policy_document`` option has been deprecated and will be removed after a later release. To maintain the existing behavior use the ``policy_json`` option and read the file with the ``lookup`` plugin." -msgstr "iam_policy - ``policy_document`` オプションは非推奨となり、後のリリースで削除される予定です。既存の動作を維持するには、``policy_json`` オプションを使用し、``lookup`` プラグインでファイルを読み込んでください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:911 -msgid "iam_role - The default value of the purge_policies has been deprecated and will change from true to false after 2022-06-01" -msgstr "iam_role - purge_policies のデフォルト値は非推奨となり、2022-06-01 以降は true から false に変更になります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:912 -msgid "iam_role - in a later release, the ``purge_policies`` option (also know as ``purge_policy``) default value will change from ``true`` to ``false``" -msgstr "iam_role - 今後のリリースでは、``purge_policies`` オプション (``purge_policy`` とも呼ばれる) のデフォルト値が ``true`` から ``false`` に変更になります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:913 -msgid "s3_lifecycle - The ``requester_pays`` option had no effect and will be removed after 2022-06-01" -msgstr "s3_lifecycle - ``requester_pays`` オプションは影響を受けておらず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:914 -msgid "s3_lifecycle - the ``requester_pays`` option has been deprecated and will be removed after a later release. It has always been ignored by the module." -msgstr "s3_lifecycle - ``requester_pays`` オプションは非推奨となり、今後のリリースで削除される予定です。モジュールでは常に無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:915 -msgid "s3_sync - The ``retries`` option had no effect and will be removed after 2022-06-01" -msgstr "s3_sync - ``retries`` オプションは影響を受けておらず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:916 -msgid "s3_sync - the ``retries`` option has been deprecated and will be removed after 2022-06-01. It has always been ignored by the module." -msgstr "s3_sync - ``retries`` オプションは非推奨となり、2022-06-01 以降は削除されます。モジュールでは常に無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:921 -msgid "openssl_csr - all values for the ``version`` option except ``1`` are deprecated. The value 1 denotes the current only standardized CSR version." -msgstr "openssl_csr - ``version`` オプションの ``1`` 以外の値は非推奨です。値 1 は、現在唯一標準化されている CSR バージョンを示します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:926 -#: ../../rst/porting_guides/porting_guide_3.rst:426 -msgid "The ldap_attr module has been deprecated and will be removed in a later release; use ldap_attrs instead." -msgstr "ldap_attr モジュールは非推奨となり、今後のリリースで削除されます。代わりに ldap_attrs を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:927 -msgid "airbrake_deployment - Add deprecation notice for ``token`` parameter and v2 api deploys. This feature will be removed in community.general 3.0.0." -msgstr "airbrake_deployment - ``token`` パラメーターと v2 api のデプロイに関する非推奨の告知を追加します。この機能は community.general 3.0.0 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:928 -msgid "clc_aa_policy - The ``wait`` option had no effect and will be removed in community.general 3.0.0." -msgstr "clc_aa_policy - ``wait`` オプションは影響を受けず、community.general 3.0.0 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:929 -msgid "clc_aa_policy - the ``wait`` parameter will be removed. It has always been ignored by the module." -msgstr "clc_aa_policy - ``wait`` パラメーターは削除されます。常にモジュールにより無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:930 -msgid "docker_container - the ``trust_image_content`` option is now deprecated and will be removed in community.general 3.0.0. It has never been used by the module." -msgstr "docker_container - ``trust_image_content`` オプションは非推奨となり、community.general 3.0.0 で削除されます。モジュールで使用されることはありません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:931 -msgid "docker_container - the ``trust_image_content`` option will be removed. It has always been ignored by the module." -msgstr "docker_container - ``trust_image_content`` オプションは削除されます。これまでもモジュールはこのオプションを無視していました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:932 -msgid "docker_container - the default of ``container_default_behavior`` will change from ``compatibility`` to ``no_defaults`` in community.general 3.0.0. Set the option to an explicit value to avoid a deprecation warning." -msgstr "docker_container - ``container_default_behavior`` のデフォルト値が community.general 3.0.0 で ``compatibility`` から ``no_defaults`` に変更になります。非推奨の警告を防ぐために、オプションを明示的に設定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:933 -msgid "docker_container - the default value for ``network_mode`` will change in community.general 3.0.0, provided at least one network is specified and ``networks_cli_compatible`` is ``true``. See porting guide, module documentation or deprecation warning for more details." -msgstr "docker_container - community.general 3.0.0 では、少なくとも 1 つのネットワークが指定され、``networks_cli_compatible`` が ``true`` である場合は、``network_mode`` のデフォルト値が変更します。詳細は移植ガイド、モジュールのドキュメント、または非推奨の警告を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:934 -msgid "docker_stack - Return values ``out`` and ``err`` have been deprecated and will be removed in community.general 3.0.0. Use ``stdout`` and ``stderr`` instead." -msgstr "docker_stack - 戻り値の ``out`` と``err`` は非推奨であり、community.general 3.0.0 で削除されます。代わりに ``stdout`` と``stderr`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:935 -msgid "docker_stack - the return values ``err`` and ``out`` have been deprecated. Use ``stdout`` and ``stderr`` from now on instead." -msgstr "docker_stack - ``err`` と``out`` の戻り値は非推奨となりました。今後は ``stdout`` と ``stderr`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:936 -msgid "helm - Put ``helm`` module to deprecated. New implementation is available in community.kubernetes collection." -msgstr "helm - ``helm`` モジュールを非推奨にしました。新しい実装は community.kubernetes コレクションで公開されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:937 -msgid "redfish_config - Deprecate ``bios_attribute_name`` and ``bios_attribute_value`` in favor of new `bios_attributes`` option." -msgstr "redfish_config - ``bios_attribute_name`` と ``bios_attribute_value`` を非推奨とし、新しい `bios_attributes`` オプションを採用します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:938 -msgid "redfish_config - the ``bios_attribute_name`` and ``bios_attribute_value`` options will be removed. To maintain the existing behavior use the ``bios_attributes`` option instead." -msgstr "redfish_config - ``bios_attribute_name`` オプションおよび ``bios_attribute_value`` オプションを削除します。既存の動作を維持するには、代わりに ``bios_attributes`` オプションを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:939 -msgid "redfish_config and redfish_command - the behavior to select the first System, Manager, or Chassis resource to modify when multiple are present will be removed. Use the new ``resource_id`` option to specify target resource to modify." -msgstr "redfish_config および redfish_command - 複数のリソースが存在する場合に修正する最初の System リソース、Manager リソース、または Chassis リソースを選択する動作が削除されます。新しい ``resource_id`` オプションを使用して、変更する対象のリソースを指定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:940 -msgid "redfish_config, redfish_command - Behavior to modify the first System, Manager, or Chassis resource when multiple are present is deprecated. Use the new ``resource_id`` option to specify target resource to modify." -msgstr "redfish_config、redfish_command - 複数のリソースが存在する場合、最初の System、Manager、または Chassis リソースを修正する動作は非推奨です。新しい ``resource_id`` オプションを使用して、変更する対象のリソースを指定してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:941 -#: ../../rst/porting_guides/porting_guide_3.rst:431 -msgid "xbps - the ``force`` option never had any effect. It is now deprecated, and will be removed in 3.0.0 (https://github.com/ansible-collections/community.general/pull/568)." -msgstr "xbps - ``force`` オプションには何も効果がありません。現在非推奨になり、3.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/568)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:946 -msgid "The vmware_dns_config module has been deprecated and will be removed in a later release; use vmware_host_dns instead." -msgstr "vmware_dns_config モジュールは非推奨となり、今後のリリースで削除される予定です。代わりに vmware_host_dns を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:947 -msgid "vca - vca_fw, vca_nat, vca_app are deprecated since these modules rely on deprecated part of Pyvcloud library." -msgstr "vca - vca_fw モジュール、vca_nat モジュール、vca_app モジュールは、Pyvcloud ライブラリーの非推奨の部分に依存しているため非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:948 -msgid "vmware_dns_config - Deprecate in favour of new module vmware_host_dns." -msgstr "vmc_dns_config - 非推奨になり、新しいモジュール vmware_host_dns が採用されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:949 -msgid "vmware_guest - deprecate specifying CDROM configuration as a dict, instead use a list." -msgstr "vmware_guest - CDROM 設定を dict として指定することを非推奨とし、代わりにリストを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:950 -msgid "vmware_tag_info - in a later release, the module will not return ``tag_facts`` since it does not return multiple tags with the same name and different category id. To maintain the existing behavior use ``tag_info`` which is a list of tag metadata." -msgstr "vmware_tag_info - 今後のリリースでは、同じ名前で異なるカテゴリー ID を持つ複数のタグを返さないため、モジュールは ``tag_facts`` を返しません。既存の動作を維持するには、タグのメタデータのリストである ``tag_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:955 -msgid "zabbix_proxy (module) - deprecates ``interface`` sub-options ``type`` and ``main`` when proxy type is set to passive via ``status=passive``. Make sure these suboptions are removed from your playbook as they were never supported by Zabbix in the first place." -msgstr "zabbix_proxy (モジュール) - ``status=passive`` でプロキシーが passive に設定されている場合は、``interface`` のサブオプション ``type`` と ``main`` を非推奨とします。これらのサブオプションはそもそも Zabbix ではサポートされていないため、必ず Playbook から削除してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:960 -msgid "Deprecated bigip_appsvcs_extension module" -msgstr "非推奨の bigip_appsvcs_extension モジュール" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:961 -msgid "Deprecated bigip_device_facts module name" -msgstr "非推奨の bigip_device_facts モジュール名" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:962 -msgid "Deprecated bigiq_device_facts module name" -msgstr "非推奨の bigiq_device_facts モジュール名" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:6 -msgid "Ansible 2.3 Porting Guide" -msgstr "Ansible 2.3 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:8 -msgid "This section discusses the behavioral changes between Ansible 2.2 and Ansible 2.3." -msgstr "このセクションでは、Ansible 2.2 から Ansible 2.3 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:13 -msgid "We suggest you read this page along with `Ansible Changelog for 2.3 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.3 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:23 -msgid "Restructured async to work with action plugins" -msgstr "アクションプラグインと連携するように async を再構築しました。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:25 -msgid "In Ansible 2.2 (and possibly earlier) the `async:` keyword could not be used in conjunction with the action plugins such as `service`. This limitation has been removed in Ansible 2.3" -msgstr "Ansible 2.2 (およびそれ以前) では、`async:` キーワードを `service` などのアクションプラグインと併用できませんでした。この制限は Ansible 2.3 で削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:27 -#: ../../rst/porting_guides/porting_guide_2.3.rst:53 -#: ../../rst/porting_guides/porting_guide_2.3.rst:69 -#: ../../rst/porting_guides/porting_guide_2.3.rst:208 -msgid "**NEW** In Ansible 2.3:" -msgstr "Ansible 2.3 における **新機能**:" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:40 -msgid "OpenBSD version facts" -msgstr "OpenBSD バージョンファクト" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:42 -msgid "The `ansible_distribution_release` and `ansible_distribution_version` facts on OpenBSD hosts were reversed in Ansible 2.2 and earlier. This has been changed so that version has the numeric portion and release has the name of the release." -msgstr "OpenBSD ホストの `ansible_distribution_release` と`ansible_distribution_version` のファクトは、Ansible 2.2 以前では逆になっていました。これは、バージョンに数字の部分があり、リリースにはリリースの名前があるように変更されています。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:44 -msgid "**OLD** In Ansible 2.2 (and earlier)" -msgstr "Ansible 2.2 以前における **以前の機能**:" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:64 -msgid "Names Blocks" -msgstr "Names ブロック" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:66 -msgid "Blocks can now have names, this allows you to avoid the ugly `# this block is for...` comments." -msgstr "ブロックに名前を付けられるようになりました。これにより、冗長な `# this block is for...` のコメントを回避できます。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:91 -#: ../../rst/porting_guides/porting_guide_2.4.rst:62 -msgid "Use of multiple tags" -msgstr "複数のタグの使用" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:93 -msgid "Specifying ``--tags`` (or ``--skip-tags``) multiple times on the command line currently leads to the last specified tag overriding all the other specified tags. This behaviour is deprecated. In the future, if you specify --tags multiple times the tags will be merged together. From now on, using ``--tags`` multiple times on one command line will emit a deprecation warning. Setting the ``merge_multiple_cli_tags`` option to True in the ``ansible.cfg`` file will enable the new behaviour." -msgstr "現在、コマンドラインで ``--tags`` (または ``--skip-tags``) を複数回指定すると、最後に指定したタグが他のすべての指定したタグよりも優先されます。この動作は推奨されません。将来的には、--tags を複数回指定した場合、タグは統合されます。今後は、1 つのコマンドラインで ``--tags`` を複数回使用すると、非推奨の警告が表示されます。``ansible.cfg`` ファイルで ``merge_multiple_cli_tags`` オプションを True に設定すると、新しい動作が有効になります。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:95 -msgid "In 2.4, the default will be to merge the tags. You can enable the old overwriting behavior via the config option. In 2.5, multiple ``--tags`` options will be merged with no way to go back to the old behaviour." -msgstr "2.4 では、デフォルトでタグのマージが行われます。古い上書きの動作は、設定オプションで有効にすることができます。2.5 では、複数の ``--tags`` オプションがマージされますが、以前の動作に戻すことはできません。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:102 -msgid "Here are some rare cases that might be encountered when updating. These are mostly caused by the more stringent parser validation and the capture of errors that were previously ignored." -msgstr "ここでは、更新時に遭遇するめったに発生しないケースを紹介します。これらは主に、パーサーの検証がより厳しくなったことと、以前は無視されていたエラーが捕捉されたことが原因です。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:105 -msgid "Made ``any_errors_fatal`` inheritable from play to task and all other objects in between." -msgstr "``any_errors_fatal`` をプレイからタスクおよび他のオブジェクトへ継承できるようにしました。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:110 -#: ../../rst/porting_guides/porting_guide_2.3.rst:115 -#: ../../rst/porting_guides/porting_guide_2.3.rst:157 -#: ../../rst/porting_guides/porting_guide_2.3.rst:162 -#: ../../rst/porting_guides/porting_guide_2.4.rst:74 -msgid "No major changes in this version." -msgstr "このバージョンには大きな変更がありません。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:113 -#: ../../rst/porting_guides/porting_guide_2.4.rst:84 -#: ../../rst/porting_guides/porting_guide_2.5.rst:168 -#: ../../rst/porting_guides/porting_guide_2.6.rst:34 -#: ../../rst/porting_guides/porting_guide_2.7.rst:168 -#: ../../rst/porting_guides/porting_guide_2.8.rst:382 -#: ../../rst/porting_guides/porting_guide_2.9.rst:122 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:57 -msgid "Modules removed" -msgstr "削除されたモジュール" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:118 -#: ../../rst/porting_guides/porting_guide_2.4.rst:91 -#: ../../rst/porting_guides/porting_guide_2.5.rst:194 -#: ../../rst/porting_guides/porting_guide_2.6.rst:40 -#: ../../rst/porting_guides/porting_guide_2.6.rst:86 -#: ../../rst/porting_guides/porting_guide_2.7.rst:174 -#: ../../rst/porting_guides/porting_guide_2.8.rst:393 -#: ../../rst/porting_guides/porting_guide_2.9.rst:139 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:65 -msgid "Deprecation notices" -msgstr "非推奨のお知らせ" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:120 -msgid "The following modules will be removed in Ansible 2.5. Please update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.5 で削除されます。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:122 -msgid "ec2_vpc" -msgstr "ec2_vpc" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:123 -msgid "cl_bond" -msgstr "cl_bond" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:124 -msgid "cl_bridge" -msgstr "cl_bridge" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:125 -msgid "cl_img_install" -msgstr "cl_img_install" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:126 -msgid "cl_interface" -msgstr "cl_interface" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:127 -msgid "cl_interface_policy" -msgstr "cl_interface_policy" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:128 -msgid "cl_license" -msgstr "cl_license" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:129 -msgid "cl_ports" -msgstr "cl_ports" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:130 -msgid "nxos_mtu use :ref:`nxos_system ` instead" -msgstr "nxos_mtu は、代わりに :ref:`nxos_system ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:134 -msgid "These modules may no longer have documentation in the current release. Please see the `Ansible 2.3 module documentation `_ if you need to know how they worked for porting your playbooks." -msgstr "これらのモジュールには現在のリリースのドキュメントが含まれていない可能性があります。Playbook の移植方法を把握する必要がある場合は、`Ansible 2.3 モジュールドキュメント `_ を確認してください。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:144 -msgid "AWS lambda" -msgstr "AWS ラムダ" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:145 -msgid "Previously ignored changes that only affected one parameter. Existing deployments may have outstanding changes that this bug fix will apply." -msgstr "以前は、1 つのパラメーターにのみ影響する変更を無視していました。既存のデプロイメントでは、このバグ修正が適用される未処理の変更がある可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:149 -msgid "Mount" -msgstr "マウント" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:151 -msgid "Mount: Some fixes so bind mounts are not mounted each time the playbook runs." -msgstr "マウント: Playbook の実行時にバインドマウントがマウントされないようにする修正もあります。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:165 -#: ../../rst/porting_guides/porting_guide_2.4.rst:199 -#: ../../rst/porting_guides/porting_guide_2.6.rst:107 -#: ../../rst/porting_guides/porting_guide_2.7.rst:246 -#: ../../rst/porting_guides/porting_guide_2.8.rst:575 -#: ../../rst/porting_guides/porting_guide_2.9.rst:728 -msgid "Networking" -msgstr "ネットワーキング" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:167 -msgid "There have been a number of changes to number of changes to how Networking Modules operate." -msgstr "ネットワーキングモジュールの運用方法に、いくつかの変更がありました。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:169 -#: ../../rst/porting_guides/porting_guide_2.4.rst:203 -msgid "Playbooks should still use ``connection: local``." -msgstr "Playbook は引き続き ``connection: local`` を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:171 -msgid "The following changes apply to:" -msgstr "以下の変更が適用されます。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:173 -msgid "dellos6" -msgstr "dellos6" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:174 -msgid "dellos9" -msgstr "dellos9" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:175 -msgid "dellos10" -msgstr "dellos10" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:176 -msgid "eos" -msgstr "eos" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:177 -msgid "ios" -msgstr "ios" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:178 -msgid "iosxr" -msgstr "iosxr" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:179 -msgid "junos" -msgstr "junos" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:180 -msgid "sros" -msgstr "sros" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:181 -msgid "vyos" -msgstr "vyos" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:184 -msgid "Deprecation of top-level connection arguments" -msgstr "トップレベルの接続引数を非推奨にする" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:186 -msgid "**OLD** In Ansible 2.2:" -msgstr "Ansible 2.2 における **以前の機能**:" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:199 -msgid "Will result in:" -msgstr "結果は以下のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:223 -msgid "delegate_to vs ProxyCommand" -msgstr "delegate_to 対 ProxyCommand" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:225 -msgid "The new connection framework for Network Modules in Ansible 2.3 that uses ``cli`` transport no longer supports the use of the ``delegate_to`` directive. In order to use a bastion or intermediate jump host to connect to network devices over ``cli`` transport, network modules now support the use of ``ProxyCommand``." -msgstr "``cli`` トランスポートを使用する Ansible 2.3 のネットワークモジュールの新しい接続フレームワークは、``delegate_to`` ディレクティブの使用をサポートしなくなりました。bastion または中間ジャンプホストを使用して ``cli`` トランスポートでネットワークデバイスに接続するために、ネットワークモジュールは ``ProxyCommand`` の使用に対応します。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:230 -msgid "To use ``ProxyCommand`` configure the proxy settings in the Ansible inventory file to specify the proxy host via ``ansible_ssh_common_args``." -msgstr "``ProxyCommand`` を使用するには、Ansible インベントリーファイルでプロキシー設定を構成して、``ansible_ssh_common_args`` を使用してプロキシーホストを指定します。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:233 -msgid "For details on how to do this see the :ref:`network proxy guide `." -msgstr "これを行う方法は、「:ref:`ネットワークプロキシーガイド `」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:6 -msgid "Ansible 2.4 Porting Guide" -msgstr "Ansible 2.4 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:8 -msgid "This section discusses the behavioral changes between Ansible 2.3 and Ansible 2.4." -msgstr "このセクションでは、Ansible 2.3 から Ansible 2.4 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:13 -msgid "We suggest you read this page along with `Ansible Changelog for 2.4 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.4 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:20 -msgid "Python version" -msgstr "Python バージョン" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:22 -msgid "Ansible will not support Python 2.4 or 2.5 on the target hosts anymore. Going forward, Python 2.6+ will be required on targets, as already is the case on the controller." -msgstr "Ansible は、ターゲットホストで Python 2.4 または 2.5 に対応しなくなりました。今後は、コントローラーと同様、ターゲットでも Python 2.6 以降が必要となります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:26 -#: ../../rst/porting_guides/porting_guide_2.5.rst:242 -#: ../../rst/porting_guides/porting_guide_2.9.rst:23 -msgid "Inventory" -msgstr "インベントリー" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:28 -msgid "Inventory has been refactored to be implemented via plugins and now allows for multiple sources. This change is mostly transparent to users." -msgstr "インベントリーはプラグインで実装できるようにリファクタリングされ、複数のソースを使用できるようになりました。この変更はユーザーにはほとんどわかりません。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:30 -msgid "One exception is the ``inventory_dir``, which is now a host variable; previously it could only have one value so it was set globally. This means you can no longer use it early in plays to determine ``hosts:`` or similar keywords. This also changes the behaviour of ``add_hosts`` and the implicit localhost; because they no longer automatically inherit the global value, they default to ``None``. See the module documentation for more information." -msgstr "1 つの例外は ``inventory_dir`` で、これはホスト変数になりました。以前は 1 つの値しか持てなかったため、グローバルに設定されていました。これは、``hosts:`` や同様のキーワードを決定するためにプレイの早い段階でそれを使用できなくなったことを意味します。これにより、``add_hosts`` および暗黙のローカルホストの動作も変更されます。グローバル値を自動的に継承しなくなったため、デフォルトで ``None`` となります。詳細は、モジュールのドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:35 -msgid "The ``inventory_file`` remains mostly unchanged, as it was always host specific." -msgstr "``inventory_file`` は常に特定のホスト固有の状態であったため、ほとんど変更されません。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:37 -msgid "Since there is no longer a single inventory, the 'implicit localhost' doesn't get either of these variables defined." -msgstr "インベントリーが 1 つなくなるため、「暗黙的な localhost」は、これらの変数のいずれかが定義されていません。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:39 -msgid "A bug was fixed with the inventory path/directory, which was defaulting to the current working directory. This caused ``group_vars`` and ``host_vars`` to be picked up from the current working directory instead of just adjacent to the playbook or inventory directory when a host list (comma separated host names) was provided as inventory." -msgstr "インベントリーのパス/ディレクトリーのデフォルトが現在のワーキングディレクトリーになっていたバグが修正されました。これにより、インベントリーとしてホストリスト (カンマで区切られたホスト名) が提供された場合に、``group_vars`` と``host_vars`` が Playbook やインベントリーのディレクトリーに隣接するのではなく、現在の作業ディレクトリーから選択されていました。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:42 -msgid "Initial playbook relative group_vars and host_vars" -msgstr "初期 Playbook の相対的な group_vars および host_vars" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:44 -msgid "In Ansible versions prior to 2.4, the inventory system would maintain the context of the initial playbook that was executed. This allowed successively included playbooks from other directories to inherit group_vars and host_vars placed relative to the top level playbook file." -msgstr "Ansible 2.4 以前のバージョンでは、インベントリーシステムが、最初に実行した Playbook のコンテキストを維持していました。これにより、他のディレクトリーから連続してインクルードされた Playbook は、最上位レベルの Playbook ファイルに相対的に配置された group_vars や host_vars を継承することができました。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:46 -msgid "Due to some behavioral inconsistencies, this functionality will not be included in the new inventory system starting with Ansible version 2.4." -msgstr "一部の動作上の不整合により、この機能は Ansible バージョン 2.4 以降の新規インベントリーシステムに含まれません。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:49 -msgid "Similar functionality can still be achieved by using vars_files, include_vars, or group_vars and host_vars placed relative to the inventory file." -msgstr "同様の機能は、インベントリーファイルに相対的に配置された vars_files、include_vars、または group_vars と host_vars を使用しても実現できます。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:55 -msgid "Specifying Inventory sources" -msgstr "インベントリーソースの指定" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:57 -msgid "Use of ``--inventory-file`` on the command line is now deprecated. Use ``--inventory`` or ``-i``. The associated ini configuration key, ``hostfile``, and environment variable, ``ANSIBLE_HOSTS``, are also deprecated. Replace them with the configuration key ``inventory`` and environment variable :envvar:`ANSIBLE_INVENTORY`." -msgstr "コマンドラインでの ``--inventory-file`` の使用は推奨されていません。``--inventory`` または``-i`` を使用してください。また、関連する ini 設定キー ``hostfile`` や環境変数 ``ANSIBLE_HOSTS`` も非推奨となっています。これらは、設定キー ``inventory`` と環境変数 :envvar:`ANSIBLE_INVENTORY` で置き換えてください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:64 -msgid "Specifying ``--tags`` (or ``--skip-tags``) multiple times on the command line currently leads to the last one overriding all the previous ones. This behavior is deprecated. In the future, if you specify --tags multiple times the tags will be merged together. From now on, using ``--tags`` multiple times on one command line will emit a deprecation warning. Setting the ``merge_multiple_cli_tags`` option to True in the ``ansible.cfg`` file will enable the new behavior." -msgstr "現在、コマンドラインで ``--tags`` (または ``--skip-tags``) を複数回指定すると、最後に指定したタグがその前に指定したすべてのタグよりも優先されます。この動作は推奨されません。将来的には、--tags を複数回指定した場合、タグは統合されます。今後は、1 つのコマンドラインで ``--tags`` を複数回使用すると、非推奨の警告が表示されます。``ansible.cfg`` ファイルで ``merge_multiple_cli_tags`` オプションを True に設定すると、新しい動作が有効になります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:66 -msgid "In 2.4, the default has change to merge the tags. You can enable the old overwriting behavior via the config option." -msgstr "2.4 では、デフォルトでタグのマージが行われるようになりました。以前の上書きの動作は、設定オプションで有効にすることができます。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:68 -msgid "In 2.5, multiple ``--tags`` options will be merged with no way to go back to the old behavior." -msgstr "2.5 では、複数の ``--tags`` オプションがマージされ、古い動作に戻る方法はありません。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:79 -#: ../../rst/porting_guides/porting_guide_2.7.rst:156 -#: ../../rst/porting_guides/porting_guide_2.8.rst:366 -msgid "Major changes in popular modules are detailed here" -msgstr "一般的なモジュールの主な変更点は、以下を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:81 -msgid "The :ref:`win_shell ` and :ref:`win_command ` modules now properly preserve quoted arguments in the command-line. Tasks that attempted to work around the issue by adding extra quotes/escaping may need to be reworked to remove the superfluous escaping. See `Issue 23019 `_ for additional detail." -msgstr ":ref:`win_shell ` モジュールおよび :ref:`win_command ` モジュールは、コマンドラインに適切に引用符で囲まれた引数を保持するようになりました。余分な引用符やエスケープを追加してこの問題を回避しようとしたタスクは、不必要なエスケープを取り除くために再作業が必要になるかもしれません。詳細は `Issue 23019 `_ を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:86 -#: ../../rst/porting_guides/porting_guide_2.5.rst:170 -#: ../../rst/porting_guides/porting_guide_2.6.rst:36 -#: ../../rst/porting_guides/porting_guide_2.7.rst:170 -#: ../../rst/porting_guides/porting_guide_2.8.rst:384 -#: ../../rst/porting_guides/porting_guide_2.9.rst:124 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:59 -msgid "The following modules no longer exist:" -msgstr "次のモジュールはもう存在していません。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:88 -msgid "None" -msgstr "なし" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:93 -msgid "The following modules will be removed in Ansible 2.8. Please update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.8 で削除されます。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:95 -msgid "azure, use :ref:`azure_rm_virtualmachine `, which uses the new Resource Manager SDK." -msgstr "azure - 新しい Resource Manager SDK を使用する :ref:`azure_rm_virtualmachine ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:96 -msgid "win_msi, use :ref:`win_package ` instead" -msgstr "win_msi - 代わりに :ref:`win_package ` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:101 -msgid "The :ref:`win_get_url ` module has the dictionary ``win_get_url`` in its results deprecated, its content is now also available directly in the resulting output, like other modules. This dictionary will be removed in Ansible 2.8." -msgstr ":ref:`win_get_url ` モジュールでは、ディクショナリー ``win_get_url`` が非推奨となり、他のモジュールと同様に、生成された出力でコンテンツが直接利用可能になりました。このディクショナリーは Ansible 2.8 で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:102 -msgid "The :ref:`win_unzip ` module no longer includes the dictionary ``win_unzip`` in its results; the contents are now included directly in the resulting output, like other modules." -msgstr ":ref:`win_unzip ` モジュールの結果には、ディクショナリー ``win_unzip`` が含まれなくなりました。コンテンツは、他のモジュールのように、出力に直接追加されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:103 -msgid "The :ref:`win_package ` module return values ``exit_code`` and ``restart_required`` have been deprecated in favour of ``rc`` and ``reboot_required`` respectively. The deprecated return values will be removed in Ansible 2.6." -msgstr ":ref:`win_package ` モジュールの戻り値 ``exit_code`` と ``restart_required`` が非推奨になり、``rc`` および ``reboot_required`` がそれぞれ採用されました。非推奨の戻り値は Ansible 2.6 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:109 -msgid "A new way to configure and document plugins has been introduced. This does not require changes to existing setups but developers should start adapting to the new infrastructure now. More details will be available in the developer documentation for each plugin type." -msgstr "プラグインを設定して文書化する方法が新たに導入されました。これには、既存の設定への変更は必要ありませんが、開発者は新しいインフラストラクチャーへの適合を開始する必要があります。詳細は、各プラグインタイプの開発者ドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:112 -msgid "Vars plugin changes" -msgstr "vars プラグインの変更点" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:114 -msgid "There have been many changes to the implementation of vars plugins, but both users and developers should not need to change anything to keep current setups working. Developers should consider changing their plugins take advantage of new features." -msgstr "vars プラグインの実装には多くの変更が加えられていますが、ユーザーも開発者も、現在の設定を維持するために何も変更する必要はありません。開発者は、新機能を利用したプラグインの変更を検討してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:116 -msgid "The most notable difference to users is that vars plugins now get invoked on demand instead of at inventory build time. This should make them more efficient for large inventories, especially when using a subset of the hosts." -msgstr "ユーザーにとって最も重要な相違点は、vars プラグインがインベントリー構築時ではなく、必要に応じて起動されるようになったことです。これにより、大規模なインベントリー、特にホストのサブセットを使用する場合に、より効率的になります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:120 -msgid "This also creates a difference with group/host_vars when using them adjacent to playbooks. Before, the 'first' playbook loaded determined the variables; now the 'current' playbook does. We are looking to fix this soon, since 'all playbooks' in the path should be considered for variable loading." -msgstr "また、group/host_vars を Playbook に隣接して使用する場合にも違いが生じます。以前は、「最初に」読み込まれた Playbook が変数を決定していましたが、現在は「現在の」Playbook が決定しています。変数の読み込みには、パスに含まれる「すべての Playbook」を考慮する必要があるため、近々この問題を修正したいと考えています。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:121 -msgid "In 2.4.1 we added a toggle to allow you to control this behaviour, 'top' will be the pre 2.4, 'bottom' will use the current playbook hosting the task and 'all' will use them all from top to bottom." -msgstr "2.4.1 では、この動作を制御するためのトグルが追加されました。「top」は 2.4 以前になり、「bottom」はタスクをホストする現在の Playbook を使用し、「all」は上から順にこれらを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:125 -msgid "Inventory plugins" -msgstr "Inventory プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:127 -msgid "Developers should start migrating from hardcoded inventory with dynamic inventory scripts to the new Inventory Plugins. The scripts will still work via the ``script`` inventory plugin but Ansible development efforts will now concentrate on writing plugins rather than enhancing existing scripts." -msgstr "開発者は、動的インベントリーリスクリプトによるハードコードされたインベントリーから、新しいインベントリースクリプトへの移行を開始する必要があります。スクリプトは、``script`` インベントリープラグインを介して引き続き動作しますが、Ansible の開発努力は、既存のスクリプトの改良ではなく、プラグインの作成に集中することになります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:129 -msgid "Both users and developers should look into the new plugins because they are intended to alleviate the need for many of the hacks and workarounds found in the dynamic inventory scripts." -msgstr "ユーザーおよび開発者は、動的インベントリースクリプトにある多くのハッキングや回避策を低減することを目的としているため、ユーザーと開発者は新しいプラグインを調べる必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:134 -msgid "Users:" -msgstr "ユーザー:" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:136 -msgid "Callbacks are now using the new configuration system. Users should not need to change anything as the old system still works, but you might see a deprecation notice if any callbacks used are not inheriting from the built in classes. Developers need to update them as stated below." -msgstr "コールバックは新しい設定システムを使用しています。古いシステムはまだ機能しているため、ユーザーは何も変更する必要はありませんが、使用されているコールバックが組み込みクラスを継承していない場合は、非推奨の通知が表示されるかもしれません。開発者は以下のように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:139 -msgid "Developers:" -msgstr "開発者:" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:141 -msgid "If your callback does not inherit from ``CallbackBase`` (directly or indirectly via another callback), it will still work, but issue a deprecation notice. To avoid this and ensure it works in the future change it to inherit from ``CallbackBase`` so it has the new options handling methods and properties. You can also implement the new options handling methods and properties but that won't automatically inherit changes added in the future. You can look at ``CallbackBase`` itself and/or ``AnsiblePlugin`` for details." -msgstr "コールバックが ``CallbackBase`` を継承していない場合 (直接または他のコールバックを経由して間接的に)、コールバックは動作しますが、非推奨の警告が表示されます。これを回避し、将来も確実に動作させるには、``CallbackBase`` を継承するように変更し、新しいオプション処理のメソッドとプロパティーを持つようにします。新しいオプション処理のメソッドやプロパティーを実装することもできますが、将来追加される変更を自動的に継承することはできません。詳細は、``CallbackBase`` 自体や``AnsiblePlugin`` を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:144 -msgid "Any callbacks inheriting from other callbacks might need to also be updated to contain the same documented options as the parent or the options won't be available. This is noted in the developer guide." -msgstr "他のコールバックから継承されるコールバックも更新して、親と同じ記述されたオプションを含むか、またはオプションを利用できないようにする必要があります。これは、開発者ガイドに記載されています。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:148 -msgid "Template lookup plugin: Escaping Strings" -msgstr "テンプレートルックアッププラグイン: 文字列のエスケープ" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:150 -msgid "Prior to Ansible 2.4, backslashes in strings passed to the template lookup plugin would be escaped automatically. In 2.4, users are responsible for escaping backslashes themselves. This change brings the template lookup plugin inline with the template module so that the same backslash escaping rules apply to both." -msgstr "Ansible 2.4 より前は、テンプレートの lookup プラグインに渡される文字列のバックスラッシュは自動的にエスケープされていました。2.4 では、ユーザーは自分でバックスラッシュをエスケープする責任があります。この変更により、テンプレートの lookup プラグインがテンプレートモジュールとインラインになり、同じバックスラッシュエスケープルールが両方に適用されるようになります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:155 -msgid "If you have a template lookup like this::" -msgstr "以下のようなテンプレート検索がある場合:" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:160 -msgid "**OLD** In Ansible 2.3 (and earlier) :file:`template.j2` would look like this:" -msgstr "Ansible 2.3 以前における **以前の機能** :file:`template.j2` は以下のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:166 -msgid "**NEW** In Ansible 2.4 it should be changed to look like this:" -msgstr "**新機能** Ansible 2.4 では、以下のように変更する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:173 -msgid "Tests" -msgstr "テスト" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:176 -msgid "Tests succeeded/failed" -msgstr "テストの成功/失敗" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:178 -msgid "Prior to Ansible version 2.4, a task return code of ``rc`` would override a return code of ``failed``. In version 2.4, both ``rc`` and ``failed`` are used to calculate the state of the task. Because of this, test plugins ``succeeded``/``failed``` have also been changed. This means that overriding a task failure with ``failed_when: no`` will result in ``succeeded``/``failed`` returning ``True``/``False``. For example::" -msgstr "Ansible バージョン 2.4 以前では、タスクのリターンコードが ``rc`` の場合は、リターンコードが ``failed`` の場合よりも優先されていました。バージョン 2.4 では、タスクの状態を計算するのに ``rc`` と``failed`` の両方が使用されます。このため、テスト用プラグイン ``succeeded``/``failed``` も変更しました。これは、``failed_when: no`` でタスクの失敗を上書きすると ``succeeded``/``failed`` が ``True``/``False`` となります。たとえば次のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:196 -msgid "As we can see from the example above, in Ansible 2.3 ``succeeded``/``failed`` only checked the value of ``rc``." -msgstr "上記の例で分かるように、Ansible 2.3 ``succeeded``/``failed`` では ``rc`` の値のみを確認しています。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:201 -msgid "There have been a number of changes to how Networking Modules operate." -msgstr "Networking モジュールの動作に複数の変更が加えられました。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:206 -msgid "Persistent Connection" -msgstr "永続的な接続" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:208 -msgid "The configuration variables ``connection_retries`` and ``connect_interval`` which were added in Ansible 2.3 are now deprecated. For Ansible 2.4 and later use ``connection_retry_timeout``." -msgstr "Ansible 2.3 で追加された設定変数 ``connection_retries`` および ``connect_interval`` が非推奨になりました。Ansible 2.4 以降では、``connection_retry_timeout`` が使用されます。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:210 -msgid "To control timeouts use ``command_timeout`` rather than the previous top level ``timeout`` variable under ``[default]``" -msgstr "タイムアウトを制御するには、``[default]`` の下の以前の最上位である ``timeout`` ではなく、``command_timeout`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:212 -msgid "See :ref:`Ansible Network debug guide ` for more information." -msgstr "詳細は、「:ref:`Ansible Network debug guide `」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:216 -msgid "Configuration" -msgstr "設定" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:219 -msgid "The configuration system has had some major changes. Users should be unaffected except for the following:" -msgstr "設定システムに大きな変更が加えられました。以下の点を除き、ユーザーは影響を受けないはずです。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:221 -msgid "All relative paths defined are relative to the `ansible.cfg` file itself. Previously they varied by setting. The new behavior should be more predictable." -msgstr "定義されている相対パスはすべて、`ansible.cfg` ファイル自体に相対的です。以前は設定により変化していました。新しい動作はより予測する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:222 -msgid "A new macro ``{{CWD}}`` is available for paths, which will make paths relative to the 'current working directory', this is unsafe but some users really want to rely on this behaviour." -msgstr "新しいマクロ ``{{CWD}}`` がパスで利用できます。このパスでは、「現在の作業ディレクトリー」に相対的なパスが作成されます。この方法は安全ではありませんが、これを使用したい場合があります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:225 -msgid "Developers that were working directly with the previous API should revisit their usage as some methods (for example, ``get_config``) were kept for backwards compatibility but will warn users that the function has been deprecated." -msgstr "以前の API を直接使用していた開発者は、使用方法を見直す必要があります。いくつかのメソッド (たとえば ``get_config``) は後方互換性のために残されていますが、その関数が非推奨であることが警告されます。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:227 -msgid "The new configuration has been designed to minimize the need for code changes in core for new plugins. The plugins just need to document their settings and the configuration system will use the documentation to provide what they need. This is still a work in progress; currently only 'callback' and 'connection' plugins support this. More details will be added to the specific plugin developer guides." -msgstr "新しい設定は、新しいプラグインのためにコアのコードを変更する必要性を最小限に抑えるように設計されています。プラグインは設定を文書化するだけでよく、設定システムはその文書を使用して必要なものを提供します。これはまだ作業中で、現在は「callback」プラグインと「connection」プラグインのみがサポートしています。詳細は、各プラグインの開発者ガイドに追加される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:5 -msgid "Ansible 2.5 Porting Guide" -msgstr "Ansible 2.5 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:7 -msgid "This section discusses the behavioral changes between Ansible 2.4 and Ansible 2.5." -msgstr "このセクションでは、Ansible 2.4 から Ansible 2.5 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:11 -msgid "We suggest you read this page along with `Ansible Changelog for 2.5 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.5 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:21 -msgid "Dynamic includes and attribute inheritance" -msgstr "ダイナミックインクルードと属性の継承" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:23 -msgid "In Ansible version 2.4, the concept of dynamic includes (``include_tasks``), as opposed to static imports (``import_tasks``), was introduced to clearly define the differences in how ``include`` works between dynamic and static includes." -msgstr "Ansible バージョン 2.4 では、静的インポート (``import_tasks``) とは対照的に、動的インクルード (``include_tasks``) という概念が導入され、動的インクルードと静的インクルードの ``include`` の動作の違いが明確に定義されました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:25 -msgid "All attributes applied to a dynamic ``include_*`` would only apply to the include itself, while attributes applied to a static ``import_*`` would be inherited by the tasks within." -msgstr "動的な ``include_*`` に適用されるすべての属性はインクルード自体にのみ適用されます。静的な ``import_*`` に適用される属性は、タスクによって継承されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:28 -msgid "This separation was only partially implemented in Ansible version 2.4. As of Ansible version 2.5, this work is complete and the separation now behaves as designed; attributes applied to an ``include_*`` task will not be inherited by the tasks within." -msgstr "この分離は、Ansible バージョン 2.4 では部分的にしか実装されていませんでした。Ansible バージョン 2.5 では、この作業が完了し、設計通りに動作するようになりました。``include_*`` タスクに適用された属性は、その中のタスクには継承されません。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:30 -msgid "To achieve an outcome similar to how Ansible worked prior to version 2.5, playbooks should use an explicit application of the attribute on the needed tasks, or use blocks to apply the attribute to many tasks. Another option is to use a static ``import_*`` when possible instead of a dynamic task." -msgstr "バージョン 2.5 以前の Ansible と同様の結果を得るためには、Playbook では、必要なタスクに属性を明示的に適用するか、ブロックを使用して多くのタスクに属性を適用する必要があります。また、動的なタスクではなく、可能な限り静的な ``import_*`` を使用するという方法もあります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:32 -msgid "**OLD** In Ansible 2.4:" -msgstr "Ansible 2.4 における **以前の機能**:" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:40 -#: ../../rst/porting_guides/porting_guide_2.5.rst:62 -msgid "Included file:" -msgstr "同梱されるファイル:" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:52 -msgid "**NEW** In Ansible 2.5:" -msgstr "Ansible 2.5 における **新機能**:" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:54 -msgid "Including task:" -msgstr "以下のタスクを含みます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:76 -msgid "The relevant change in those examples is, that in Ansible 2.5, the included file defines the tag ``distro_include`` again. The tag is not inherited automatically." -msgstr "これらの例に関連する変更点は、Ansible 2.5 では、同梱されるファイルで ``distro_include`` というタグが再び定義されていることです。このタグは自動的には継承されません。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:79 -msgid "Fixed handling of keywords and inline variables" -msgstr "キーワードおよびインライン変数の処理を修正しました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:81 -msgid "We made several fixes to how we handle keywords and 'inline variables', to avoid conflating the two. Unfortunately these changes mean you must specify whether `name` is a keyword or a variable when calling roles. If you have playbooks that look like this::" -msgstr "キーワードと「インライン変数」の扱い方をいくつか修正し、両者の混同を避けるようにしました。残念ながら、この変更により、ロールを呼び出す際に `name` がキーワードなのか変数なのかを指定しなければならなくなりました。以下のような Playbook をお持ちの方は、ご注意ください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:86 -msgid "You will run into errors because Ansible reads name in this context as a keyword. Beginning in 2.5, if you want to use a variable name that is also a keyword, you must explicitly declare it as a variable for the role::" -msgstr "この文脈では、Ansible は名前をキーワードとして読み取るため、エラーが発生します。2.5 以降では、キーワードでもある変数名を使用したい場合は、ロールの変数として明示的に宣言する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:92 -msgid "For a full list of keywords see :ref:`playbook_keywords`." -msgstr "キーワードの完全なリストは、「:ref:`playbook_keywords`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:95 -msgid "Migrating from with_X to loop" -msgstr "with_X から loop への移行" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:1 -msgid "In most cases, loops work best with the ``loop`` keyword instead of ``with_X`` style loops. The ``loop`` syntax is usually best expressed using filters instead of more complex use of ``query`` or ``lookup``." -msgstr "ほとんどの場合、ループは、``with_X`` スタイルのループではなく、``loop`` キーワードで最適に機能します。``loop`` 構文は通常、``query`` や ``lookup`` の複雑な使用ではなく、フィルターを使用して表現できます。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:3 -msgid "These examples show how to convert many common ``with_`` style loops to ``loop`` and filters." -msgstr "以下の例では、一般的な ``with_`` スタイルのループを ``loop`` およびフィルターに変換する方法を示しています。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:6 -msgid "with_list" -msgstr "with_list" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:8 -msgid "``with_list`` is directly replaced by ``loop``." -msgstr "``with_list`` は、直接 ``loop`` に置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:27 -msgid "with_items" -msgstr "with_items" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:29 -msgid "``with_items`` is replaced by ``loop`` and the ``flatten`` filter." -msgstr "``with_items`` は、``loop`` および ``flatten`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:44 -msgid "with_indexed_items" -msgstr "with_indexed_items" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:46 -msgid "``with_indexed_items`` is replaced by ``loop``, the ``flatten`` filter and ``loop_control.index_var``." -msgstr "``with_indexed_items`` は、``loop``、``flatten`` フィルター、および ``loop_control.index_var`` に置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:63 -msgid "with_flattened" -msgstr "with_flattened" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:65 -msgid "``with_flattened`` is replaced by ``loop`` and the ``flatten`` filter." -msgstr "``with_flattened`` は、``loop`` および ``flatten`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:80 -msgid "with_together" -msgstr "with_together" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:82 -msgid "``with_together`` is replaced by ``loop`` and the ``zip`` filter." -msgstr "``with_together`` は、``loop`` および ``zip`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:98 -msgid "Another example with complex data" -msgstr "複雑なデータがある別の例" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:113 -msgid "with_dict" -msgstr "with_dict" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:115 -msgid "``with_dict`` can be substituted by ``loop`` and either the ``dictsort`` or ``dict2items`` filters." -msgstr "``with_dict`` は、``loop`` と、``dictsort`` または``dict2items`` のいずれかのフィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:135 -msgid "with_sequence" -msgstr "with_sequence" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:137 -msgid "``with_sequence`` is replaced by ``loop`` and the ``range`` function, and potentially the ``format`` filter." -msgstr "``with_sequence`` は、``loop`` と``range`` の関数、そして潜在的には``format`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:153 -msgid "with_subelements" -msgstr "with_subelements" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:155 -msgid "``with_subelements`` is replaced by ``loop`` and the ``subelements`` filter." -msgstr "``with_subelements`` は、``loop`` および ``subelements`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:172 -msgid "with_nested/with_cartesian" -msgstr "with_nested/with_cartesian" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:174 -msgid "``with_nested`` and ``with_cartesian`` are replaced by loop and the ``product`` filter." -msgstr "``with_nested`` と``with_cartesian`` は、ループと ``product`` のフィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:191 -msgid "with_random_choice" -msgstr "with_random_choice" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:193 -msgid "``with_random_choice`` is replaced by just use of the ``random`` filter, without need of ``loop``." -msgstr "``with_random_choice`` は、``random`` フィルターを使用するだけで、``loop`` を必要とせずに置き換えることができます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:104 -msgid "Jinja tests used as filters" -msgstr "フィルターとして使用される Jinja テスト" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:106 -msgid "Using Ansible-provided jinja tests as filters will be removed in Ansible 2.9." -msgstr "Ansible が提供する jinja テストをフィルターとして使用することは、Ansible 2.9 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:108 -msgid "Prior to Ansible 2.5, jinja tests included within Ansible were most often used as filters. The large difference in use is that filters are referenced as ``variable | filter_name`` while jinja tests are referenced as ``variable is test_name``." -msgstr "Ansible 2.5 以前は、Ansible に含まれる jinja テストは、ほとんどがフィルターとして使用されていました。使用方法の大きな違いは、フィルターは ``variable | filter_name`` として参照されるのに対し、jinja テストは ``variable is test_name`` として参照されることです。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:110 -msgid "Jinja tests are used for comparisons, while filters are used for data manipulation and have different applications in jinja. This change is to help differentiate the concepts for a better understanding of jinja, and where each can be appropriately used." -msgstr "jinja テストは比較のために使用され、フィルターはデータ操作のために使用され、それぞれ用途が異なります。この変更は、jinja の理解を深めるために概念を区別し、それぞれが適切に使用される場所を示すためのものです。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:112 -msgid "As of Ansible 2.5, using an Ansible provided jinja test with filter syntax, will display a deprecation error." -msgstr "Ansible 2.5 以降では、Ansible が提供する jinja テストをフィルター構文で使用すると、非推奨エラーが表示されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:114 -msgid "**OLD** In Ansible 2.4 (and earlier) the use of an Ansible included jinja test would likely look like this:" -msgstr "Ansible 2.4 (以前) における **以前の機能** Ansible に含まれる jinja テストを使用すると、次のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:122 -msgid "**NEW** In Ansible 2.5 it should be changed to look like this:" -msgstr "**新機能** Ansible 2.5 では、以下のように変更する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:130 -msgid "In addition to the deprecation warnings, many new tests have been introduced that are aliases of the old tests. These new tests make more sense grammatically with the jinja test syntax, such as the new ``successful`` test which aliases ``success``." -msgstr "非推奨の警告に加えて、古いテストのエイリアスである多くの新しいテストが導入されました。これらの新しいテストは、``success`` のエイリアスを設定した新しい ``successful`` テストのように、jinja のテスト構文では文法的に意味をなします。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:136 -msgid "See :ref:`playbooks_tests` for more information." -msgstr "詳細は、「:ref:`playbooks_tests`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:138 -msgid "Additionally, a script was created to assist in the conversion for tests using filter syntax to proper jinja test syntax. This script has been used to convert all of the Ansible integration tests to the correct format. There are a few limitations documented, and all changes made by this script should be evaluated for correctness before executing the modified playbooks. The script can be found at `https://github.com/ansible/ansible/blob/devel/hacking/fix_test_syntax.py `_." -msgstr "さらに、フィルター構文を使ったテストを適切な jinja テスト構文に変換するためのスクリプトも作成しました。このスクリプトを使用して、Ansible のすべての統合テストを正しい形式に変換しました。いくつかの制限事項が記載されているため、このスクリプトによる変更は、修正した Playbook を実行する前に正しいかどうか評価する必要があります。このスクリプトは `https://github.com/ansible/ansible/blob/devel/hacking/fix_test_syntax.py `_ にあります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:141 -msgid "Ansible fact namespacing" -msgstr "Ansible のファクト名前空間設定" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:143 -msgid "Ansible facts, which have historically been written to names like ``ansible_*`` in the main facts namespace, have been placed in their own new namespace, ``ansible_facts.*`` For example, the fact ``ansible_distribution`` is now best queried through the variable structure ``ansible_facts.distribution``." -msgstr "Ansible のファクトは、これまで主なファクトの名前空間で ``ansible_*`` のような名前で書かれていましたが、独自の新しい名前空間 ``ansible_facts.*`` に配置されました。たとえば、ファクト ``ansible_distribution`` は、変数構造 ``ansible_facts.distribution`` を通じて最もよく照会されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:148 -msgid "A new configuration variable, ``inject_facts_as_vars``, has been added to ansible.cfg. Its default setting, 'True', keeps the 2.4 behavior of facts variables being set in the old ``ansible_*`` locations (while also writing them to the new namespace). This variable is expected to be set to 'False' in a future release. When ``inject_facts_as_vars`` is set to False, you must refer to ansible_facts through the new ``ansible_facts.*`` namespace." -msgstr "ansible.cfg に、新しい設定変数 ``inject_facts_as_vars`` が追加されました。デフォルトの設定は「True」で、2.4 の動作であるファクト変数が古い ``ansible_*`` の場所に設定されたままになります (新しい名前空間にも書き込まれます)。この変数は、将来のリリースでは「False」に設定される予定です。``inject_facts_as_vars`` が False に設定されると、新しい ``ansible_facts.*`` 名前空間を通して ansible_facts を参照する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:158 -msgid "Major changes in popular modules are detailed here." -msgstr "一般的なモジュールの主な変更点は、こちらを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:161 -msgid "github_release" -msgstr "github_release" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:163 -msgid "In Ansible versions 2.4 and older, after creating a GitHub release using the ``create_release`` state, the ``github_release`` module reported state as ``skipped``. In Ansible version 2.5 and later, after creating a GitHub release using the ``create_release`` state, the ``github_release`` module now reports state as ``changed``." -msgstr "Ansible バージョン 2.4 以前では、``create_release`` 状態を使用して GitHub リリースを作成すると、``github_release`` モジュールの状態が ``skipped`` と報告します。Ansible バージョン 2.5 以降では、``create_release`` 状態を使用して GitHub リリースを作成した後に、``github_release`` モジュールの状態が ``changed`` として報告されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:172 -msgid "nxos_mtu use :ref:`nxos_system `'s ``system_mtu`` option or :ref:`nxos_interface ` instead" -msgstr "nxos_mtu は、代わりに :ref:`nxos_system `の ``system_mtu`` オプションまたは :ref:`nxos_interface ` を使用します" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:173 -msgid "cl_interface_policy use :ref:`nclu ` instead" -msgstr "cl_interface_policy は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:174 -msgid "cl_bridge use :ref:`nclu ` instead" -msgstr "cl_bridge は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:175 -msgid "cl_img_install use :ref:`nclu ` instead" -msgstr "cl_img_install は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:176 -msgid "cl_ports use :ref:`nclu ` instead" -msgstr "cl_ports は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:177 -msgid "cl_license use :ref:`nclu ` instead" -msgstr "cl_license は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:178 -msgid "cl_interface use :ref:`nclu ` instead" -msgstr "cl_interface は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:179 -msgid "cl_bond use :ref:`nclu ` instead" -msgstr "cl_bond は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:180 -msgid "ec2_vpc use :ref:`ec2_vpc_net ` along with supporting modules :ref:`ec2_vpc_igw `, :ref:`ec2_vpc_route_table `, :ref:`ec2_vpc_subnet `, :ref:`ec2_vpc_dhcp_option `, :ref:`ec2_vpc_nat_gateway `, :ref:`ec2_vpc_nacl ` instead." -msgstr "ec2_vpc は、:ref:`ec2_vpc_net ` とサポートモジュール :ref:`ec2_vpc_igw `、:ref:`ec2_vpc_route_table `、:ref:`ec2_vpc_subnet `、:ref:`ec2_vpc_dhcp_option `、:ref:`ec2_vpc_nat_gateway `、:ref:`ec2_vpc_nacl ` を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:181 -msgid "ec2_ami_search use :ref:`ec2_ami_facts ` instead" -msgstr "ec2_ami_search は、代わりに :ref:`ec2_ami_facts ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:182 -msgid "docker use :ref:`docker_container ` and :ref:`docker_image ` instead" -msgstr "docker は、代わりに :ref:`docker_container ` および :ref:`docker_image ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:186 -msgid "These modules may no longer have documentation in the current release. Please see the `Ansible 2.4 module documentation `_ if you need to know how they worked for porting your playbooks." -msgstr "これらのモジュールには現在のリリースのドキュメントが含まれていない可能性があります。Playbook の移植方法を把握する必要がある場合は、`Ansible 2.4 モジュールのドキュメント `_ を確認してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:196 -msgid "The following modules will be removed in Ansible 2.9. Please update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.9 で削除されます。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:198 -msgid "Apstra's ``aos_*`` modules are deprecated as they do not work with AOS 2.1 or higher. See new modules at `https://github.com/apstra `_." -msgstr "AOS 2.1 以降では動作しないため、Apstra の ``aos_*`` モジュールは非推奨になりました。`https://github.com/apstra `_ で新しいモジュールを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:199 -msgid "nxos_ip_interface use :ref:`nxos_l3_interface ` instead." -msgstr "nxos_ip_interface は、代わりに :ref:`nxos_l3_interface ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:200 -msgid "nxos_portchannel use :ref:`nxos_linkagg ` instead." -msgstr "nxos_portchannel は、代わりに :ref:`nxos_linkagg ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:201 -msgid "nxos_switchport use :ref:`nxos_l2_interface ` instead." -msgstr "nxos_switchport は、代わりに :ref:`nxos_l2_interface ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:202 -msgid "panos_security_policy use :ref:`panos_security_rule ` instead." -msgstr "panos_security_policy は、代わりに :ref:`panos_security_rule ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:203 -msgid "panos_nat_policy use :ref:`panos_nat_rule ` instead." -msgstr "panos_nat_policy は、代わりに :ref:`panos_nat_rule ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:204 -msgid "vsphere_guest use :ref:`vmware_guest ` instead." -msgstr "vsphere_guest は、代わりに :ref:`vmware_guest ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:209 -msgid "The :ref:`stat ` and :ref:`win_stat ` modules have changed the default of the option ``get_md5`` from ``true`` to ``false``." -msgstr ":ref:`stat ` モジュールおよび :ref:`win_stat ` モジュールは、オプション``get_md5`` のデフォルトを ``true`` から``false`` に変更しました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:211 -msgid "This option will be removed starting with Ansible version 2.9. The options ``get_checksum: True`` and ``checksum_algorithm: md5`` can still be used if an MD5 checksum is desired." -msgstr "このオプションは、Ansible バージョン 2.9 以降で削除されます。MD5 チェックサムが必要な場合は、``get_checksum: True`` と ``checksum_algorithm: md5`` のオプションを引き続き使用できます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:215 -msgid "``osx_say`` module was renamed into :ref:`say `." -msgstr "``osx_say`` モジュールの名前が :ref:`say ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:216 -msgid "Several modules which could deal with symlinks had the default value of their ``follow`` option changed as part of a feature to `standardize the behavior of follow `_:" -msgstr "シンボリックリンクを処理することができる複数のモジュールでは、``follow`` オプションのデフォルト値が機能の一部として `standardize the behavior of follow `_ に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:220 -msgid "The :ref:`file module ` changed from ``follow=False`` to ``follow=True`` because its purpose is to modify the attributes of a file and most systems do not allow attributes to be applied to symlinks, only to real files." -msgstr ":ref:`file モジュール ` が ``follow=False`` から ``follow=True`` に変更になったのは、その目的がファイルの属性を変更することであり、ほとんどのシステムでは属性をシンボリックリンクに適用することはできず、実際のファイルにのみ適用することができるからです。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:223 -msgid "The :ref:`replace module ` had its ``follow`` parameter removed because it inherently modifies the content of an existing file so it makes no sense to operate on the link itself." -msgstr ":ref:`replace module ` は、既存ファイルの内容を本質的に変更するため、``follow`` パラメーターが削除されました。したがって、リンク自体で操作することは適切ではありません。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:226 -msgid "The :ref:`blockinfile module ` had its ``follow`` parameter removed because it inherently modifies the content of an existing file so it makes no sense to operate on the link itself." -msgstr ":ref:`blockinfile module ` は、既存ファイルの内容を本質的に変更するため、``follow`` パラメーターが削除されました。したがって、リンク自体で操作することは適切ではありません。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:229 -msgid "In Ansible-2.5.3, the :ref:`template module ` became more strict about its ``src`` file being proper utf-8. Previously, non-utf8 contents in a template module src file would result in a mangled output file (the non-utf8 characters would be replaced with a unicode replacement character). Now, on Python2, the module will error out with the message, \"Template source files must be utf-8 encoded\". On Python3, the module will first attempt to pass the non-utf8 characters through verbatim and fail if that does not succeed." -msgstr "Ansible-2.5.3 では、:ref:`template module ` が、その ``src`` ファイルが適切な utf-8 であることについて、より厳密になりました。これまでは、テンプレートモジュールの src ファイルに utf8 でないコンテンツがあると、出力ファイルが文字化けしていました (utf8 でない文字は unicode の置換文字で置き換えられます)。現在、Python2 では、モジュールは「Template source files must be utf-8 encoded」というメッセージでエラーになります。Python3 では、モジュールはまず非 utf8 文字をそのまま通過させようとし、それが成功しない場合は失敗します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:239 -msgid "As a developer, you can now use 'doc fragments' for common configuration options on plugin types that support the new plugin configuration system." -msgstr "開発者は、新しいプラグイン設定システムをサポートするプラグインタイプの共通設定オプションに「doc フラグメント」を使用できるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:244 -msgid "Inventory plugins have been fine tuned, and we have started to add some common features:" -msgstr "インベントリープラグインは微調整され、共通の機能を追加しました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:246 -msgid "The ability to use a cache plugin to avoid costly API/DB queries is disabled by default. If using inventory scripts, some may already support a cache, but it is outside of Ansible's knowledge and control. Moving to the internal cache will allow you to use Ansible's existing cache refresh/invalidation mechanisms." -msgstr "cache プラグインを使用して、コストのかかる API/DB クエリーを回避するためにする機能は、デフォルトでは無効になっています。インベントリースクリプトを使用している場合、一部のスクリプトはすでにキャッシュをサポートしているかもしれませんが、それは Ansible の知識とコントロールの範囲外となります。内部キャッシュに移行することで、Ansible の既存のキャッシュリフレッシュ/無効化メカニズムを使用できるようになります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:250 -msgid "A new 'auto' plugin, enabled by default, that can automatically detect the correct plugin to use IF that plugin is using our 'common YAML configuration format'. The previous host_list, script, yaml and ini plugins still work as they did, the auto plugin is now the last one we attempt to use. If you had customized the enabled plugins you should revise the setting to include the new auto plugin." -msgstr "デフォルトで有効になっている新しい「auto」プラグイン。プラグインが「共通の YAML 設定形式」を使用している場合に使用する正しいプラグインを自動的に検出できます。以前の host_list、script、yaml、および ini プラグインは引き続き機能しますが、自動プラグインが最後に使用を試みます。有効なプラグインをカスタマイズした場合は、新しい自動プラグインを含めるように設定を変更する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:255 -msgid "Shell" -msgstr "シェル" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:257 -msgid "Shell plugins have been migrated to the new plugin configuration framework. It is now possible to customize more settings, and settings which were previously 'global' can now also be overridden using host specific variables." -msgstr "シェルプラグインが、新しいプラグイン設定フレームワークに移行しました。より多くの設定をカスタマイズできるようになり、これまで「グローバル」だった設定を、ホスト固有の変数を使用してオーバーライドできるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:259 -msgid "For example, ``system_temps`` is a new setting that allows you to control what Ansible will consider a 'system temporary dir'. This is used when escalating privileges for a non-administrative user. Previously this was hardcoded to '/tmp', which some systems cannot use for privilege escalation. This setting now defaults to ``[ '/var/tmp', '/tmp']``." -msgstr "たとえば、``system_temps`` は、Ansible が「システム一時ディレクトリー」とみなすものを制御することができる新しい設定です。これは、管理者ではないユーザーの権限を昇格させる際に使用されます。これまでは「/tmp」にハードコードされていましたが、システムによっては特権の昇格に使用できない場合があります。この設定のデフォルトは ``[ '/var/tmp', '/tmp']`` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:261 -msgid "Another new setting is ``admin_users`` which allows you to specify a list of users to be considered 'administrators'. Previously this was hardcoded to ``root``. It now it defaults to ``[root, toor, admin]``. This information is used when choosing between your ``remote_temp`` and ``system_temps`` directory." -msgstr "もう一つの新しい設定は ``admin_users`` で、「管理者」とみなされるユーザーのリストを指定することができます。これまでは、``root`` にハードコードされていました。現在はデフォルトで ``[root, toor, admin]`` になっています。この情報は、``remote_temp`` と ``system_temps`` のディレクトリーを選択する際に使用されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:263 -msgid "For a full list, check the shell plugin you are using, the default shell plugin is ``sh``." -msgstr "全一覧については、使用しているシェルプラグインを確認してください。デフォルトのシェルプラグインは ``sh`` です。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:265 -msgid "Those that had to work around the global configuration limitations can now migrate to a per host/group settings, but also note that the new defaults might conflict with existing usage if the assumptions don't correlate to your environment." -msgstr "グローバル設定の制限を回避する必要があった場合は、ホスト/グループごとの設定に移行することができますが、新しいデフォルト設定がお客様の環境と関連していない場合は、既存の使用方法と競合する可能性があることに注意してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:269 -msgid "Filter" -msgstr "フィルター" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:271 -msgid "The lookup plugin API now throws an error if a non-iterable value is returned from a plugin. Previously, numbers or other non-iterable types returned by a plugin were accepted without error or warning. This change was made because plugins should always return a list. Please note that plugins that return strings and other non-list iterable values will not throw an error, but may cause unpredictable behavior. If you have a custom lookup plugin that does not return a list, you should modify it to wrap the return values in a list." -msgstr "プラグインから反復不可能値が返された場合は、lookup プラグイン API がエラーを発生させるようになりました。以前は、プラグインによって返される数値またはその他の反復不可能な型は、エラーや警告なしに受け入れられていました。プラグインは常にリストを返す必要があるため、この変更が行われました。文字列やその他のリストされていない反復可能な値を返すプラグインはエラーを発生させませんが、予期しない動作を引き起こす可能性があることに注意してください。リストを返さないカスタム lookup プラグインがある場合は、戻り値をリストでラップするようにプラグインを変更する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:275 -msgid "Lookup" -msgstr "Lookup" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:277 -msgid "A new option was added to lookup plugins globally named ``error`` which allows you to control how errors produced by the lookup are handled, before this option they were always fatal. Valid values for this option are ``warn``, ``ignore`` and ``strict``. See the :ref:`lookup ` page for more details." -msgstr "新しいオプションは、``error`` という名前のプラグインをグローバルで検索するために追加されました。このプラグインでは、このオプションが常に致命的になる前に、検索によって生成されるエラーの処理方法を制御できます。このオプションの有効な値は ``warn``、``ignore``、および ``strict`` です。詳細は「:ref:`lookup `」ページを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:283 -#: ../../rst/porting_guides/porting_guide_2.6.rst:104 -#: ../../rst/porting_guides/porting_guide_2.6.rst:109 -#: ../../rst/porting_guides/porting_guide_2.7.rst:243 -#: ../../rst/porting_guides/porting_guide_2.7.rst:248 -msgid "No notable changes." -msgstr "主な変更はありません。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:286 -msgid "Network" -msgstr "ネットワーク" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:289 -msgid "Expanding documentation" -msgstr "ドキュメントの拡張" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:291 -msgid "We're expanding the network documentation. There's new content and a :ref:`new Ansible Network landing page`. We will continue to build the network-related documentation moving forward." -msgstr "ネットワークドキュメントを拡充しています。新しいコンテンツと :ref:`new Ansible Network landing page` があります。今後もネットワーク関連のドキュメントを充実させていく予定です。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:294 -msgid "Top-level connection arguments will be removed in 2.9" -msgstr "最上位レベルの接続引数が 2.9 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:296 -msgid "Top-level connection arguments like ``username``, ``host``, and ``password`` are deprecated and will be removed in version 2.9." -msgstr "``username``、``host``、``password`` などの最上位レベルの接続引数は非推奨となり、バージョン 2.9 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:298 -#: ../../rst/porting_guides/porting_guide_2.9.rst:745 -msgid "**OLD** In Ansible < 2.4" -msgstr "Ansible 2.4 より前のバージョンにおける **以前の機能**" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:311 -msgid "The deprecation warnings reflect this schedule. The task above, run in Ansible 2.5, will result in:" -msgstr "非推奨の警告にはこのスケジュールが反映されます。上記のタスクを Ansible 2.5 で実行すると、以下のような結果になります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:322 -msgid "We recommend using the new connection types ``network_cli`` and ``netconf`` (see below), using standard Ansible connection properties, and setting those properties in inventory by group. As you update your playbooks and inventory files, you can easily make the change to ``become`` for privilege escalation (on platforms that support it). For more information, see the :ref:`using become with network modules` guide and the :ref:`platform documentation`." -msgstr "新しい接続タイプ ``network_cli`` および ``netconf`` (下記参照) を使用し、Ansible の標準的な接続プロパティーを使用し、インベントリーでそれらのプロパティをグループごとに設定することが推奨されます。Playbook やインベントリーファイルを更新する際に、特権昇格のために ``become`` への変更を簡単に行うことができます (サポートしているプラットフォームの場合)。詳細は、「:ref:`ネットワークモジュールを使用した become の使用`」ガイドおよび「:ref:`プラットフォームドキュメント`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:325 -msgid "Adding persistent connection types ``network_cli`` and ``netconf``" -msgstr "永続的な接続タイプ ``network_cli`` および ``netconf`` の追加" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:327 -msgid "Ansible 2.5 introduces two top-level persistent connection types, ``network_cli`` and ``netconf``. With ``connection: local``, each task passed the connection parameters, which had to be stored in your playbooks. With ``network_cli`` and ``netconf`` the playbook passes the connection parameters once, so you can pass them at the command line if you prefer. We recommend you use ``network_cli`` and ``netconf`` whenever possible. Note that eAPI and NX-API still require ``local`` connections with ``provider`` dictionaries. See the :ref:`platform documentation` for more information. Unless you need a ``local`` connection, update your playbooks to use ``network_cli`` or ``netconf`` and to specify your connection variables with standard Ansible connection variables:" -msgstr "Ansible 2.5 では、``network_cli`` と``netconf`` という 2 つの最上位レベルの永続的な接続タイプが導入されました。``connection: local`` では、各タスクが接続パラメーターを渡していたため、Playbook に保存しておく必要がありました。``network_cli`` および ``netconf`` では、Playbook が接続パラメータを一度だけ渡すため、必要に応じてコマンドラインでパラメーターを渡すことができます。可能な限り ``network_cli`` と ``netconf`` を使用することが推奨されます。なお、eAPI と NX-API では、``provider`` ディレクトリーを使用した ``local`` の接続がまだ必要です。詳細は「:ref:`プラットフォームドキュメント`」を参照してください。``local`` の接続が必要な場合を除き、``network_cli`` または ``netconf`` を使用し、Ansible の標準的な接続変数を指定するように Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:330 -#: ../../rst/porting_guides/porting_guide_2.5.rst:379 -msgid "**OLD** In Ansible 2.4" -msgstr "Ansible 2.4 における **以前の機能**" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:349 -#: ../../rst/porting_guides/porting_guide_2.5.rst:385 -msgid "**NEW** In Ansible 2.5" -msgstr "Ansible 2.5 における **新機能**" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:365 -msgid "Using a provider dictionary with either ``network_cli`` or ``netconf`` will result in a warning." -msgstr "``network_cli`` または ``netconf`` のいずれかでプロバイダーディクショナリーを使用すると、警告が表示されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:369 -msgid "Developers: Shared Module Utilities Moved" -msgstr "Developers: 共有モジュールのユーティリティーが移動しました" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:371 -msgid "Beginning with Ansible 2.5, shared module utilities for network modules moved to ``ansible.module_utils.network``." -msgstr "Ansible 2.5 以降、ネットワークモジュールの共有モジュールユーティリティーが ``ansible.module_utils.network`` に移動しました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:373 -msgid "Platform-independent utilities are found in ``ansible.module_utils.network.common``" -msgstr "プラットフォームに依存しないユーティリティーは、``ansible.module_utils.network.common`` にあります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:375 -msgid "Platform-specific utilities are found in ``ansible.module_utils.network.{{ platform }}``" -msgstr "プラットフォーム固有のユーティリティーは、``ansible.module_utils.network.{{ platform }}`` にあります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:377 -msgid "If your module uses shared module utilities, you must update all references. For example, change:" -msgstr "モジュールで共有モジュールユーティリティーを使用している場合は、すべての参照を更新する必要があります。たとえば、以下のように変更します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:392 -msgid "See the module utilities developer guide see :ref:`developing_module_utilities` for more information." -msgstr "詳細は、モジュールユーティリティーの開発者ガイドの「:ref:`developing_module_utilities`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:5 -msgid "Ansible 2.6 Porting Guide" -msgstr "Ansible 2.6 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:7 -msgid "This section discusses the behavioral changes between Ansible 2.5 and Ansible 2.6." -msgstr "このセクションでは、Ansible 2.5 から Ansible 2.6 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:11 -msgid "We suggest you read this page along with `Ansible Changelog for 2.6 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.6 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:20 -msgid "The deprecated task option ``always_run`` has been removed, please use ``check_mode: no`` instead." -msgstr "非推奨のタスクオプション ``always_run`` が削除されました。代わりに ``check_mode: no`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:25 -msgid "In the :ref:`nxos_igmp_interface module`, ``oif_prefix`` and ``oif_source`` properties are deprecated. Use ``ois_ps`` parameter with a dictionary of prefix and source to values instead." -msgstr ":ref:`nxos_igmp_interface モジュール ` で、``oif_prefix`` プロパティーおよび ``oif_source`` プロパティーでは非推奨になりました。代わりに、接頭辞のディクショナリーとソースから値へのディクショナリーを付けて ``ois_ps`` パラメーターを使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:30 -msgid "Major changes in popular modules are detailed here:" -msgstr "一般的なモジュールの主な変更点は、以下を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:42 -#: ../../rst/porting_guides/porting_guide_2.6.rst:88 -msgid "The following modules will be removed in Ansible 2.10. Please update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.10 で削除されます。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:44 -msgid "``k8s_raw`` use :ref:`k8s ` instead." -msgstr "``k8s_raw`` は、代わりに :ref:`k8s ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:45 -msgid "``openshift_raw`` use :ref:`k8s ` instead." -msgstr "``openshift_raw`` は、代わりに :ref:`k8s ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:46 -msgid "``openshift_scale`` use :ref:`k8s_scale ` instead." -msgstr "``openshift_scale`` は、代わりに :ref:`k8s_scale ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:51 -msgid "The ``upgrade`` module option for ``win_chocolatey`` has been removed; use ``state: latest`` instead." -msgstr "``win_chocolatey`` の ``upgrade`` モジュールオプションが削除されました。代わりに ``state: latest`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:52 -msgid "The ``reboot`` module option for ``win_feature`` has been removed; use the ``win_reboot`` action plugin instead." -msgstr "``win_feature`` の ``reboot`` モジュールオプションが削除されました。代わりに ``win_reboot`` アクションプラグインを使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:53 -msgid "The ``win_iis_webapppool`` module no longer accepts a string for the ``attributes`` module option; use the free form dictionary value instead." -msgstr "``win_iis_webapppool`` モジュールは ``attributes`` モジュールオプションの文字列を受け入れなくなりました。代わりに自由形式のディクショナリー値を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:54 -msgid "The ``name`` module option for ``win_package`` has been removed; this is not used anywhere and should just be removed from your playbooks." -msgstr "``win_package`` の ``name`` モジュールオプションが削除されました。これはいずれも使用されず、Playbook から削除されるだけです。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:55 -msgid "The ``win_regedit`` module no longer automatically corrects the hive path ``HCCC`` to ``HKCC``; use ``HKCC`` because this is the correct hive path." -msgstr "``win_regedit`` モジュールは、ハイブパス ``HCCC`` から``HKCC`` を自動的に修正しなくなりました。正しいハイブパスは``HKCC`` です。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:56 -msgid "The :ref:`file_module` now emits a deprecation warning when ``src`` is specified with a state other than ``hard`` or ``link`` as it is only supposed to be useful with those. This could have an effect on people who were depending on a buggy interaction between src and other state's to place files into a subdirectory. For instance::" -msgstr ":ref:`file_module` は、``src`` が ``hard`` または ``link`` 以外の状態で指定された場合、非推奨の警告を表示するようになりました。これは、これらの状態でのみ有用であると考えられているからです。これにより、src と他の状態との間のバグのある相互作用を利用してファイルをサブディレクトリーに置いていた場合は影響が出る可能性があります。たとえば、以下のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:63 -msgid "Would create a directory named ``/tmp/lib``. Instead of the above, simply spell out the entire destination path like this::" -msgstr "``/tmp/lib`` という名前のディレクトリーが作成されます。上記の代わりに、単純に目的地のパス全体を次のように綴ります。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:68 -msgid "The ``k8s_raw`` and ``openshift_raw`` modules have been aliased to the new ``k8s`` module." -msgstr "``k8s_raw`` モジュールおよび ``openshift_raw`` モジュールは新しい ``k8s`` モジュールにエイリアスが設定されました。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:69 -msgid "The ``k8s`` module supports all Kubernetes resources including those from Custom Resource Definitions and aggregated API servers. This includes all OpenShift resources." -msgstr "``k8s`` モジュールは、Custom Resource Definitions や集約された API サーバーからのものを含むすべての Kubernetes リソースをサポートします。これには、すべての OpenShift リソースも含まれます。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:70 -msgid "The ``k8s`` module will not accept resources where subkeys have been snake_cased. This was a workaround that was suggested with the ``k8s_raw`` and ``openshift_raw`` modules." -msgstr "``k8s`` モジュールは、サブキーを使用して snake_cased となったリソースを受け入れません。これは、``k8s_raw`` モジュールおよび ``openshift_raw`` モジュールに提案された回避策です。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:71 -msgid "The ``k8s`` module may not accept resources where the ``api_version`` has been changed to match the shortened version in the Kubernetes Python client. You should now specify the proper full Kubernetes ``api_version`` for a resource." -msgstr "``k8s`` モジュールは、``api_version`` が Kubernetes Python クライアントの短縮バージョンに合わせて変更されたリソースを受け入れない場合があります。これからは、リソースに対して適切な完全な Kubernetes ``api_version`` を指定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:72 -msgid "The ``k8s`` module can now process multi-document YAML files if they are passed with the ``src`` parameter. It will process each document as a separate resource. Resources provided inline with the ``resource_definition`` parameter must still be a single document." -msgstr "``k8s`` モジュールは、複数ドキュメントの YAML ファイルが ``src`` パラメーターで渡された場合に、それを処理できるようになりました。各ドキュメントは個別のリソースとして処理されます。``resource_definition`` パラメーターを使用してインラインで提供されるリソースは、1 つのドキュメントでなければなりません。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:73 -msgid "The ``k8s`` module will not automatically change ``Project`` creation requests into ``ProjectRequest`` creation requests as the ``openshift_raw`` module did. You must now specify the ``ProjectRequest`` kind explicitly." -msgstr "``openshift_raw`` モジュールが行ったため、``k8s`` モジュールは ``Project`` 作成要求を自動的に ``ProjectRequest`` 作成要求に変更しません。``ProjectRequest`` の種類を明示的に指定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:74 -msgid "The ``k8s`` module will not automatically remove secrets from the Ansible return values (and by extension the log). In order to prevent secret values in a task from being logged, specify the ``no_log`` parameter on the task block." -msgstr "``k8s`` モジュールは、Ansible の戻り値 (ひいてはログ) からシークレットを自動的に削除しません。タスク内のシークレット値がログに残らないようにするには、タスクブロックに ``no_log`` パラメーターを指定します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:75 -msgid "The ``k8s_scale`` module now supports scalable OpenShift objects, such as ``DeploymentConfig``." -msgstr "``k8s_scale`` モジュールは、``DeploymentConfig`` などのスケーラブルな OpenShift オブジェクトをサポートするようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:76 -msgid "The ``lineinfile`` module was changed to show a warning when using an empty string as a regexp. Since an empty regexp matches every line in a file, it will replace the last line in a file rather than inserting. If this is the desired behavior, use ``'^'`` which will match every line and will not trigger the warning." -msgstr "``lineinfile`` モジュールは、空の文字列を正規表現として使用する際に警告を表示するように変更になりました。空の正規表現はファイルのすべての行に一致するため、ファイルの最後の行を挿入するのではなく、置き換えてしまいます。このような動作をさせたい場合は、``'^'`` を使用すると、すべての行に一致し、警告は発生しません。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:80 -msgid "Openstack modules are no longer using ``shade`` library. Instead ``openstacksdk`` is used. Since ``openstacksdk`` should be already present as a dependency to ``shade`` no additional actions are required." -msgstr "Openstack モジュールで ``shade`` ライブラリーが使用されなくなりました。代わりに ``openstacksdk`` が使用されます。``openstacksdk`` は ``shade`` の依存関係として既に存在しているため、追加のアクションは必要ありません。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:90 -msgid "``openshift`` use ``k8s`` instead." -msgstr "``openshift`` は、代わりに ``k8s`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:96 -msgid "The ``k8s`` lookup plugin now supports all Kubernetes resources including those from Custom Resource Definitions and aggregated API servers. This includes all OpenShift resources." -msgstr "``k8s`` lookup モジュールは、Custom Resource Definitions や集約された API サーバーからのものを含むすべての Kubernetes リソースをサポートします。これには、すべての OpenShift リソースも含まれます。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:97 -msgid "The ``k8s`` lookup plugin may not accept resources where the ``api_version`` has been changed to match the shortened version in the Kubernetes Python client. You should now specify the proper full Kubernetes ``api_version`` for a resource." -msgstr "``k8s`` lookup モジュールは、``api_version`` が Kubernetes Python クライアントの短縮バージョンに合わせて変更されたリソースを受け入れない場合があります。これからは、リソースに対して適切な完全な Kubernetes ``api_version`` を指定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:98 -msgid "The ``k8s`` lookup plugin will no longer remove secrets from the Ansible return values (and by extension the log). In order to prevent secret values in a task from being logged, specify the ``no_log`` parameter on the task block." -msgstr "``k8s`` lookup プラグインは、Ansible の戻り値 (ひいてはログ) からシークレットを自動的に削除しません。タスク内のシークレット値がログに残らないようにするには、タスクブロックに ``no_log`` パラメーターを指定します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:112 -msgid "Dynamic inventory scripts" -msgstr "動的インベントリースクリプト" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:114 -msgid "``contrib/inventory/openstack.py`` has been renamed to ``contrib/inventory/openstack_inventory.py``. If you have used ``openstack.py`` as a name for your OpenStack dynamic inventory file, change it to ``openstack_inventory.py``. Otherwise the file name will conflict with imports from ``openstacksdk``." -msgstr "``contrib/inventory/openstack.py`` の名前が ``contrib/inventory/openstack_inventory.py`` に変更になりました。OpenStack の動的インベントリーファイルの名前として ``openstack.py`` を使用している場合は、``openstack_inventory.py`` に変更してください。そうしないと、ファイル名が ``openstacksdk`` からのインポートと競合します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:5 -msgid "Ansible 2.7 Porting Guide" -msgstr "Ansible 2.7 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:7 -msgid "This section discusses the behavioral changes between Ansible 2.6 and Ansible 2.7." -msgstr "このセクションでは、Ansible 2.6 から Ansible 2.7 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:11 -msgid "We suggest you read this page along with `Ansible Changelog for 2.7 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.7 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:20 -msgid "If you specify ``--tags`` or ``--skip-tags`` multiple times on the command line, Ansible will merge the specified tags together. In previous versions of Ansible, you could set ``merge_multiple_cli_tags`` to ``False`` if you wanted to keep only the last-specified ``--tags``. This config option existed for backwards compatibility. The overwriting behavior was deprecated in 2.3 and the default behavior was changed in 2.4. Ansible-2.7 removes the config option; multiple ``--tags`` are now always merged." -msgstr "コマンドラインで ``--tags`` や ``--skip-tags`` を複数回指定した場合、Ansible は指定されたタグをまとめてマージします。Ansible の以前のバージョンでは、最後に指定した ``--tags`` だけを残したい場合は、``merge_multiple_cli_tags`` を ``False`` に設定することができました。この設定オプションは後方互換性のために存在していました。上書きの動作は 2.3 で非推奨となり、2.4 ではデフォルトの動作が変更されました。Ansible-2.7 では、この設定オプションが削除され、複数の ``--tags`` が常にマージされるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:27 -msgid "If you have a shell script that depends on setting ``merge_multiple_cli_tags`` to ``False``, please upgrade your script so it only adds the ``--tags`` you actually want before upgrading to Ansible-2.7." -msgstr "``merge_multiple_cli_tags`` から ``False`` への設定に依存するシェルスクリプトがある場合は、スクリプトをアップグレードして Ansible-2.7 にアップグレードする前に実際に必要な ``--tags`` のみを追加してください。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:32 -msgid "Python Compatibility" -msgstr "Python の互換性" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:34 -msgid "Ansible has dropped compatibility with Python-2.6 on the controller (The host where :command:`/usr/bin/ansible` or :command:`/usr/bin/ansible-playbook` is run). Modules shipped with Ansible can still be used to manage hosts which only have Python-2.6. You just need to have a host with Python-2.7 or Python-3.5 or greater to manage those hosts from." -msgstr "Ansible は、コントローラー (:command:`/usr/bin/ansible` または :command:`/usr/bin/ansible-playbook` が実行されるホスト) での Python-2.6 との互換性を失いました。Ansible に同梱されているモジュールは、Python-2.6 しか搭載していないホストの管理に使用できます。ただし、Python-2.7 以上または Python-3.5 以上のホストから管理する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:39 -msgid "One thing that this does affect is the ability to use :command:`/usr/bin/ansible-pull` to manage a host which has Python-2.6. ``ansible-pull`` runs on the host being managed but it is a controller script, not a module so it will need an updated Python. Actively developed Linux distros which ship with Python-2.6 have some means to install newer Python versions (For instance, you can install Python-2.7 via an SCL on RHEL-6) but you may need to also install Python bindings for many common modules to work (For RHEL-6, for instance, selinux bindings and yum would have to be installed for the updated Python install)." -msgstr "これが影響することの 1 つは、:command:`/usr/bin/ansible-pull` を使用して、Python-2.6 を搭載したホストを管理する機能です。``ansible-pull`` は管理対象のホストで実行しますが、これはコントローラースクリプトであり、モジュールではないため、更新された Python が必要になります。Python-2.6 に同梱されているアクティブに開発された Linux ディストリビューションには、新しい Python バージョンをインストールする手段があります (たとえば、RHEL-6 の SCL を介して Python-2.7 をインストールすることが可能) が、多くの一般的なモジュールの Python バインディングもインストールしないといけない場合があります (たとえば、RHEL-6 の場合、更新された Python インストールには selinux バインディングと yum をインストールする必要があります)。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:47 -msgid "The decision to drop Python-2.6 support on the controller was made because many dependent libraries are becoming unavailable there. In particular, python-cryptography is no longer available for Python-2.6 and the last release of pycrypto (the alternative to python-cryptography) has known security bugs which will never be fixed." -msgstr "コントローラの Python-2.6 サポートを終了する決定を下したのは、多くの依存ライブラリーが利用できなくなってきたためです。特に、python-cryptography は Python-2.6 では利用できなくなり、pycrypto (python-cryptography の代替品) の最後のリリースには、今後も修正されない既知のセキュリティーバグがあります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:57 -msgid "Role Precedence Fix during Role Loading" -msgstr "ロール読み込み時のロールの優先順位の修正" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:59 -msgid "Ansible 2.7 makes a small change to variable precedence when loading roles, resolving a bug, ensuring that role loading matches :ref:`variable precedence expectations `." -msgstr "Ansible 2.7 では、ロールの読み込み時に変数の優先順位が若干変更され、バグを解決し、ロールの読み込みが :ref:`variable precedence expectations ` と一致するようにします。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:61 -msgid "Before Ansible 2.7, when loading a role, the variables defined in the role's ``vars/main.yml`` and ``defaults/main.yml`` were not available when parsing the role's ``tasks/main.yml`` file. This prevented the role from utilizing these variables when being parsed. The problem manifested when ``import_tasks`` or ``import_role`` was used with a variable defined in the role's vars or defaults." -msgstr "Ansible 2.7 より前のバージョンでは、ロールを読み込む際に、ロールの ``vars/main.yml`` および``defaults/main.yml`` で定義された変数が、ロールの ``tasks/main.yml`` ファイルを解析するときに利用できませんでした。このため、ロールの解析時にこれらの変数を利用することができませんでした。この問題は、``import_tasks`` または ``import_role`` が、ロールの vars または defaults で定義された変数と一緒に使用されたときに明らかになりました。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:63 -msgid "In Ansible 2.7, role ``vars`` and ``defaults`` are now parsed before ``tasks/main.yml``. This can cause a change in behavior if the same variable is defined at the play level and the role level with different values, and leveraged in ``import_tasks`` or ``import_role`` to define the role or file to import." -msgstr "Ansible 2.7 では、ロール ``vars`` および ``defaults`` が ``tasks/main.yml`` の前に解析されるようになりました。これにより、プレイレベルとロールレベルで同じ変数が異なる値で定義されており、``import_tasks`` や``import_role`` でインポートするロールやファイルを定義するのに利用されている場合は、動作が変化する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:66 -msgid "include_role and import_role variable exposure" -msgstr "include_role および import_role の変数の公開" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:68 -msgid "In Ansible 2.7 a new module argument named ``public`` was added to the ``include_role`` module that dictates whether or not the role's ``defaults`` and ``vars`` will be exposed outside of the role, allowing those variables to be used by later tasks. This value defaults to ``public: False``, matching current behavior." -msgstr "Ansible 2.7 では、``public`` という名前の新しいモジュール引数が ``include_role`` モジュールに追加され、ロールの ``defaults`` および ``vars`` がロール外部に公開され、後のタスクでこれらの変数を使用できるようにします。この値は ``public: False`` にデフォルト設定されており、現在の動作と一致させます。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:70 -msgid "``import_role`` does not support the ``public`` argument, and will unconditionally expose the role's ``defaults`` and ``vars`` to the rest of the playbook. This functionality brings ``import_role`` into closer alignment with roles listed within the ``roles`` header in a play." -msgstr "``import_role`` では ``public`` 引数はサポートされず、ロールの ``defaults`` と ``vars`` は無条件で Playbook の残りの値に公開されます。この機能では、``import_role`` がプレイの ``roles`` ヘッダー内に一覧表示されるロールに綿密な調整されます。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:72 -msgid "There is an important difference in the way that ``include_role`` (dynamic) will expose the role's variables, as opposed to ``import_role`` (static). ``import_role`` is a pre-processor, and the ``defaults`` and ``vars`` are evaluated at playbook parsing, making the variables available to tasks and roles listed at any point in the play. ``include_role`` is a conditional task, and the ``defaults`` and ``vars`` are evaluated at execution time, making the variables available to tasks and roles listed *after* the ``include_role`` task." -msgstr "``include_role`` (動的) がロールの変数を公開する方法は、``import_role`` (静的) とは重要な違いがあります。``import_role`` はプリプロセッサーであり、``defaults`` と``vars`` は Playbook の解析時に評価され、プレイのどの時点でもリストされているタスクとロールが変数を利用できるようになります。``include_role`` は条件付きタスクであり、``defaults`` と ``vars`` は実行時に評価され、``include_role`` タスクの *後* にリストされているタスクとロールが変数を利用できるようになります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:75 -msgid "include_tasks/import_tasks inline variables" -msgstr "include_tasks/import_tasks インライン変数" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:77 -msgid "As of Ansible 2.7, `include_tasks` and `import_tasks` can no longer accept inline variables. Instead of using inline variables, tasks should supply variables under the ``vars`` keyword." -msgstr "Ansible 2.7 では、`include_tasks` および `import_tasks` はインライン変数を受け付けなくなりました。インライン変数を使用する代わりに、タスクは ``vars`` キーワードで変数を提供する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:79 -msgid "**OLD** In Ansible 2.6 (and earlier) the following was valid syntax for specifying variables:" -msgstr "Ansible 2.6 以前における **以前の機能** 以下は、変数を指定するのに有効な構文でした。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:85 -msgid "**NEW** In Ansible 2.7 the task should be changed to use the ``vars`` keyword:" -msgstr "**新機能** Ansible 2.7 では、``vars`` キーワードを使用するようにタスクを変更する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:94 -msgid "vars_prompt with unknown algorithms" -msgstr "アルゴリズムが不明な vars_prompt" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:96 -msgid "vars_prompt now throws an error if the hash algorithm specified in encrypt is not supported by the controller. This increases the safety of vars_prompt as it previously returned None if the algorithm was unknown. Some modules, notably the user module, treated a password of None as a request not to set a password. If your playbook starts erroring because of this, change the hashing algorithm being used with this filter." -msgstr "暗号化で指定されたハッシュアルゴリズムがコントローラーでサポートされていない場合は、vars_prompt がエラーを出力するようになりました。これにより、以前はアルゴリズムが不明な場合に None が返されたため、vars_prompt の安全性が向上します。一部のモジュール、特にユーザーモジュールは、None のパスワードをパスワードを設定しない要求として扱いました。これが原因で Playbook でエラーが発生し始めた場合は、このフィルターで使用されているハッシュアルゴリズムを変更してください。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:107 -msgid "Expedited Deprecation: Use of ``__file__`` in ``AnsibleModule``" -msgstr "Expedited Deprecation: ``AnsibleModule`` での ``__file__`` の使用" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:109 -msgid "The use of the ``__file__`` variable is deprecated in Ansible 2.7 and **will be eliminated in Ansible 2.8**. This is much quicker than our usual 4-release deprecation cycle." -msgstr "``__file__`` 変数の使用は、Ansible 2.7 で非推奨となり、**Ansible 2.8 で廃止される予定です**。これは、通常の 4 リリースの非推奨サイクルよりもはるかに早いものです。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:111 -msgid "We are deprecating the use of the ``__file__`` variable to refer to the file containing the currently-running code. This common Python technique for finding a filesystem path does not always work (even in vanilla Python). Sometimes a Python module can be imported from a virtual location (like inside of a zip file). When this happens, the ``__file__`` variable will reference a virtual location pointing to inside of the zip file. This can cause problems if, for instance, the code was trying to use ``__file__`` to find the directory containing the python module to write some temporary information." -msgstr "現在実行中のコードを含むファイルを参照する ``__file__`` 変数の使用は非推奨になります。ファイルシステムパスを見つけるためのこの一般的な Python の手法は、(vanilla Python でも) 常に機能するとは限りません。Python モジュールを仮想の場所 (zip ファイル内など) からインポートできる場合があります。これが発生すると、``__file__`` 変数は、zip ファイルの内部を指す仮想の場所を参照します。これは、たとえば、コードが ``__file__`` を使用して、一時的な情報を書き込むための Python モジュールを含むディレクトリーを検索する場合に、問題が発生する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:113 -msgid "Before the introduction of AnsiBallZ in Ansible 2.1, using ``__file__`` worked in ``AnsibleModule`` sometimes, but any module that used it would fail when pipelining was turned on (because the module would be piped into the python interpreter's standard input, so ``__file__`` wouldn't contain a file path). AnsiBallZ unintentionally made using ``__file__`` work, by always creating a temporary file for ``AnsibleModule`` to reside in." -msgstr "Ansible 2.1 で AnsiBallZ が導入される前は、``__file__`` を使用すると ``AnsibleModule`` で動作することがありましたが、パイプラインが有効になっていると、これを使用したモジュールは失敗していました (モジュールは python インタープリターの標準入力にパイプされるため、``__file__`` にはファイルパスが含まれないためです)。AnsiBallZ は、``AnsibleModule`` が常駐するための一時ファイルを常に作成することで、``__file__`` を意図せずに利用できるようにしました。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:115 -msgid "Ansible 2.8 will no longer create a temporary file for ``AnsibleModule``; instead it will read the file out of a zip file. This change should speed up module execution, but it does mean that starting with Ansible 2.8, referencing ``__file__`` will always fail in ``AnsibleModule``." -msgstr "Ansible 2.8 は、``AnsibleModule`` 用の一時ファイルを作成しません。この変更により、zip ファイルからファイルを読み取ることになります。この変更により、モジュールの実行が迅速化されますが、Ansible 2.8 以降で ``__file__`` 参照が常に ``AnsibleModule`` で失敗します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:117 -msgid "If you are the author of a third-party module which uses ``__file__`` with ``AnsibleModule``, please update your module(s) now, while the use of ``__file__`` is deprecated but still available. The most common use of ``__file__`` is to find a directory to write a temporary file. In Ansible 2.5 and above, you can use the ``tmpdir`` attribute on an ``AnsibleModule`` instance instead, as shown in this code from the :ref:`apt module `:" -msgstr "``__file__`` と ``AnsibleModule`` を併用しているサードパーティーモジュールを作成した場合は、``__file__`` が利用可能な状態ではあってもその使用が非推奨となっている間に、ご自身のモジュールを更新してください。``__file__`` の最も一般的な使い方は、一時ファイルを書き込むディレクトリーを探すことです。Ansible 2.5 以降では、:ref:`apt モジュール ` のコードにあるように、``AnsibleModule`` インスタンスに ``tmpdir`` 属性を使用することができます。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:127 -msgid "Using a loop on a package module via squash_actions" -msgstr "squash_actions によるパッケージモジュールでのループの使用" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:129 -msgid "The use of ``squash_actions`` to invoke a package module, such as \"yum\", to only invoke the module once is deprecated, and will be removed in Ansible 2.11." -msgstr "``squash_actions`` を使用して「yum」などのパッケージモジュールを呼び出して、モジュールが非推奨にしてからのみ起動し、Ansible 2.11 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:131 -msgid "Instead of relying on implicit squashing, tasks should instead supply the list directly to the ``name``, ``pkg`` or ``package`` parameter of the module. This functionality has been supported in most modules since Ansible 2.3." -msgstr "暗黙的な権限付けに依存せずに、タスクは代わりにモジュールの ``name`` パラメーター、``pkg`` パラメーター、または ``package`` パラメーターに直接リストを提供する必要があります。この機能は Ansible 2.3 以降のほとんどのモジュールでサポートされています。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:133 -msgid "**OLD** In Ansible 2.6 (and earlier) the following task would invoke the \"yum\" module only 1 time to install multiple packages" -msgstr "Ansible 2.6 以前における **以前の機能** 以下のタスクが「yum」モジュールを一度だけ呼び出して複数のパッケージをインストールします。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:143 -msgid "**NEW** In Ansible 2.7 it should be changed to look like this:" -msgstr "**新機能** Ansible 2.7 では、以下のように変更する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:158 -msgid "The :ref:`DEFAULT_SYSLOG_FACILITY` configuration option tells Ansible modules to use a specific `syslog facility `_ when logging information on all managed machines. Due to a bug with older Ansible versions, this setting did not affect machines using journald with the systemd Python bindings installed. On those machines, Ansible log messages were sent to ``/var/log/messages``, even if you set :ref:`DEFAULT_SYSLOG_FACILITY`. Ansible 2.7 fixes this bug, routing all Ansible log messages according to the value set for :ref:`DEFAULT_SYSLOG_FACILITY`. If you have :ref:`DEFAULT_SYSLOG_FACILITY` configured, the location of remote logs on systems which use journald may change." -msgstr ":ref:`DEFAULT_SYSLOG_FACILITY` 設定オプションは、すべての管理マシンの情報をログに記録する際に、特定の `syslog ファシリティー `_ を使用するように Ansible モジュールに指示します。古い Ansible バージョンのバグにより、この設定は systemd Python バインディングがインストールされた journald を使用するマシンには影響しませんでした。これらのマシンでは、:ref:`DEFAULT_SYSLOG_FACILITY` を設定しても、Ansible のログメッセージは ``/var/log/messages`` に送信されていました。Ansible 2.7 ではこのバグが修正され、すべての Ansible ログメッセージが :ref:`DEFAULT_SYSLOG_FACILITY` に設定された値に従ってルーティングされるようになりました。:ref:`DEFAULT_SYSLOG_FACILITY` を設定している場合は、journald を使用しているシステムのリモートログの場所が変わる可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:176 -msgid "The following modules will be removed in Ansible 2.11. Please update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.11 で削除されます。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:178 -msgid "``na_cdot_aggregate`` use :ref:`na_ontap_aggregate ` instead." -msgstr "``na_cdot_aggregate`` は、代わりに :ref:`na_ontap_aggregate ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:179 -msgid "``na_cdot_license`` use :ref:`na_ontap_license ` instead." -msgstr "``na_cdot_license`` は、代わりに :ref:`na_ontap_license ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:180 -msgid "``na_cdot_lun`` use :ref:`na_ontap_lun ` instead." -msgstr "``na_cdot_lun`` は、代わりに :ref:`na_ontap_lun ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:181 -msgid "``na_cdot_qtree`` use :ref:`na_ontap_qtree ` instead." -msgstr "``na_cdot_qtree`` は、代わりに :ref:`na_ontap_qtree ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:182 -msgid "``na_cdot_svm`` use :ref:`na_ontap_svm ` instead." -msgstr "``na_cdot_svm`` は、代わりに :ref:`na_ontap_svm ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:183 -msgid "``na_cdot_user`` use :ref:`na_ontap_user ` instead." -msgstr "``na_cdot_user`` は、代わりに :ref:`na_ontap_user ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:184 -msgid "``na_cdot_user_role`` use :ref:`na_ontap_user_role ` instead." -msgstr "``na_cdot_user_role`` は、代わりに :ref:`na_ontap_user_role ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:185 -msgid "``na_cdot_volume`` use :ref:`na_ontap_volume ` instead." -msgstr "``na_cdot_volume`` は、代わりに :ref:`na_ontap_volume ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:186 -msgid "``sf_account_manager`` use :ref:`na_elementsw_account` instead." -msgstr "``sf_account_manager`` は、代わりに :ref:`na_elementsw_account` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:187 -msgid "``sf_check_connections`` use :ref:`na_elementsw_check_connections` instead." -msgstr "``sf_check_connections`` は、代わりに :ref:`na_elementsw_check_connections` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:188 -msgid "``sf_snapshot_schedule_manager`` use :ref:`na_elementsw_snapshot_schedule` instead." -msgstr "``sf_snapshot_schedule_manager`` は、代わりに :ref:`na_elementsw_snapshot_schedule` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:189 -msgid "``sf_volume_access_group_manager`` use :ref:`na_elementsw_access_group` instead." -msgstr "``sf_volume_access_group_manager`` は、代わりに :ref:`na_elementsw_access_group` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:190 -msgid "``sf_volume_manager`` use :ref:`na_elementsw_volume` instead." -msgstr "``sf_volume_manager`` は、代わりに :ref:`na_elementsw_volume` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:195 -msgid "Check mode is now supported in the ``command`` and ``shell`` modules. However, only when ``creates`` or ``removes`` is specified. If either of these are specified, the module will check for existence of the file and report the correct changed status, if they are not included the module will skip like it had done previously." -msgstr "``command`` モジュールおよび ``shell`` モジュールでチェックモードがサポートされるようになりました。ただし、``creates`` または ``removes`` が指定されている場合に限ります。これらのいずれかが指定された場合、モジュールはファイルの存在をチェックし、正しく変更された状態を報告しますが、これらが含まれていない場合、モジュールは以前のようにスキップします。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:199 -msgid "The ``win_chocolatey`` module originally required the ``proxy_username`` and ``proxy_password`` to escape any double quotes in the value. This is no longer required and the escaping may cause further issues." -msgstr "``win_chocolatey`` モジュールでは、もともと ``proxy_username`` と ``proxy_password`` で値の中の二重引用符をエスケープする必要がありました。これは必須ではなくなり、エスケープすることでさらに問題が発生する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:203 -msgid "The ``win_uri`` module has removed the deprecated option ``use_basic_parsing``, since Ansible 2.5 this option did nothing" -msgstr "``win_uri`` モジュールは、非推奨のオプション ``use_basic_parsing`` が Ansible 2.5 以降機能していなかっため、削除しました。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:206 -msgid "The ``win_scheduled_task`` module has removed the following deprecated options:" -msgstr "``win_scheduled_task`` モジュールでは、以下の非推奨オプションが削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:208 -msgid "``executable``, use ``path`` in an actions entry instead" -msgstr "``executable``。代わりに、アクションエントリーで ``path`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:209 -msgid "``argument``, use ``arguments`` in an actions entry instead" -msgstr "``argument``。代わりに、アクションエントリーで ``arguments`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:210 -msgid "``store_password``, set ``logon_type: password`` instead" -msgstr "``store_password``。代わりに ``logon_type: password`` を設定します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:211 -msgid "``days_of_week``, use ``monthlydow`` in a triggers entry instead" -msgstr "``days_of_week``。代わりに、トリガーエントリーで ``monthlydow`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:212 -msgid "``frequency``, use ``type``, in a triggers entry instead" -msgstr "``frequency``。代わりに、トリガーエントリーで ``type`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:213 -msgid "``time``, use ``start_boundary`` in a triggers entry instead" -msgstr "``time``。代わりに、トリガーエントリーで ``start_boundary`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:215 -msgid "The ``interface_name`` module option for ``na_ontap_net_vlan`` has been removed and should be removed from your playbooks" -msgstr "``na_ontap_net_vlan`` の ``interface_name`` モジュールオプションが削除され、Playbook から削除される必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:217 -msgid "The ``win_disk_image`` module has deprecated the return value ``mount_path``, use ``mount_paths[0]`` instead. This will be removed in Ansible 2.11." -msgstr "``win_disk_image`` モジュールは、戻り値 ``mount_path`` を非推奨とし、代わりに ``mount_paths[0]`` を使用します。この戻り値は Ansible 2.11で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:220 -msgid "``include_role`` and ``include_tasks`` can now be used directly from ``ansible`` (adhoc) and ``ansible-console``::" -msgstr "``include_role`` および ``include_tasks`` は、``ansible`` (adhoc) と``ansible-console`` から直接使用できるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:224 -msgid "The ``pip`` module has added a dependency on ``setuptools`` to support version requirements, this requirement is for the Python interpreter that executes the module and not the Python interpreter that the module is managing." -msgstr "``pip`` モジュールは、バージョン要件をサポートするために ``setuptools`` への依存を追加しました。この要件は、モジュールを実行する Python インタープリターに対するもので、モジュールが管理する Python インタープリターに対するものではありません。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:227 -msgid "Prior to Ansible 2.7.10, the ``replace`` module did the opposite of what was intended when using the ``before`` and ``after`` options together. This now works properly but may require changes to tasks." -msgstr "Ansible 2.7.10 より前のバージョンでは、``replace`` モジュールは、``before`` オプションと ``after`` オプションを同時に使用する際に意図された内容と反対に実行していました。これにより、タスクへの変更が必要になる可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:233 -msgid "The hash_password filter now throws an error if the hash algorithm specified is not supported by the controller. This increases the safety of the filter as it previously returned None if the algorithm was unknown. Some modules, notably the user module, treated a password of None as a request not to set a password. If your playbook starts erroring because of this, change the hashing algorithm being used with this filter." -msgstr "指定されたハッシュアルゴリズムがコントローラーでサポートされていない場合は、hash_password フィルターがエラーを出力するようになりました。これにより、アルゴリズムが不明な場合、以前は None が返されたため、フィルターの安全性が向上します。一部のモジュール、特にユーザーモジュールは、None のパスワードをパスワードを設定しない要求として扱いました。これが原因で Playbook でエラーが発生し始めた場合は、このフィルターで使用されているハッシュアルゴリズムを変更してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:5 -msgid "Ansible 2.8 Porting Guide" -msgstr "Ansible 2.8 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:7 -msgid "This section discusses the behavioral changes between Ansible 2.7 and Ansible 2.8." -msgstr "このセクションでは、Ansible 2.7 から Ansible 2.8 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:11 -msgid "We suggest you read this page along with `Ansible Changelog for 2.8 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.8 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:22 -msgid "Distribution Facts" -msgstr "分散ファクト" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:24 -msgid "The information returned for the ``ansible_distribution_*`` group of facts may have changed slightly. Ansible 2.8 uses a new backend library for information about distributions: `nir0s/distro `_. This library runs on Python-3.8 and fixes many bugs, including correcting release and version names." -msgstr "ファクトの ``ansible_distribution_*`` グループで返される情報は、若干変更されている可能性があります。Ansible 2.8 では、ディストリビューションに関する情報を得るために、新しいバックエンドライブラリー (`nir0s/distro `_) を使用しています。このライブラリーは Python-3.8 上で動作し、リリース名やバージョン名の修正など、多くのバグが修正されています。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:27 -msgid "The two facts used in playbooks most often, ``ansible_distribution`` and ``ansible_distribution_major_version``, should not change. If you discover a change in these facts, please file a bug so we can address the difference. However, other facts like ``ansible_distribution_release`` and ``ansible_distribution_version`` may change as erroneous information gets corrected." -msgstr "Playbook で最もよく使われる 2 つのファクト (``ansible_distribution`` と``ansible_distribution_major_version``) は変更しないでください。これらのファクトが変更されているのを発見した場合は、バグを提出してください。ただし、``ansible_distribution_release`` や``ansible_distribution_version`` のような他のファクトは、誤った情報が修正された場合に変更される可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:32 -msgid "Imports as handlers" -msgstr "ハンドラーとしてインポート" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:34 -msgid "Beginning in version 2.8, a task cannot notify ``import_tasks`` or a static ``include`` that is specified in ``handlers``." -msgstr "バージョン 2.8 以降、タスクは ``handlers`` で指定される ``import_tasks`` または静的 ``include`` に通知することができません。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:36 -msgid "The goal of a static import is to act as a pre-processor, where the import is replaced by the tasks defined within the imported file. When using an import, a task can notify any of the named tasks within the imported file, but not the name of the import itself." -msgstr "静的インポートの目的は、インポートがインポートファイル内で定義されたタスクに置き換えられる、事前プロセッサーとして機能することです。インポートを使用する場合、タスクはインポートされたファイル内で名前付きのタスクのいずれかに通知されますが、これはインポート自体の名前ではありません。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:39 -msgid "To achieve the results of notifying a single name but running multiple handlers, utilize ``include_tasks``, or ``listen`` :ref:`handlers`." -msgstr "単一の名前に通知するが、複数のハンドラーを実行している場合には、``include_tasks``、または ``listen`` :ref:`handlers` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:42 -msgid "Jinja Undefined values" -msgstr "Jinja の未定義の値" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:44 -msgid "Beginning in version 2.8, attempting to access an attribute of an Undefined value in Jinja will return another Undefined value, rather than throwing an error immediately. This means that you can now simply use a default with a value in a nested data structure when you don't know if the intermediate values are defined." -msgstr "バージョン 2.8 から、Jinja で Undefined の値の属性にアクセスしようとすると、すぐにエラーが発生するのではなく、別の Undefined の値が返されます。これにより、中間値が定義されているかどうかわからない場合に、ネストされたデータ構造の中の値でデフォルト簡単に使用することができるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:47 -msgid "In Ansible 2.8::" -msgstr "Ansible 2.8 の場合::" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:51 -msgid "In Ansible 2.7 and older::" -msgstr "Ansible 2.7 以前::" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:55 -msgid "or::" -msgstr "または::" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:60 -msgid "Module option conversion to string" -msgstr "モジュールオプションの文字列への変換" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:62 -msgid "Beginning in version 2.8, Ansible will warn if a module expects a string, but a non-string value is passed and automatically converted to a string. This highlights potential problems where, for example, a ``yes`` or ``true`` (parsed as truish boolean value) would be converted to the string ``'True'``, or where a version number ``1.10`` (parsed as float value) would be converted to ``'1.1'``. Such conversions can result in unexpected behavior depending on context." -msgstr "バージョン 2.8 以降、Ansible は、モジュールが文字列を期待しているにもかかわらず、文字列ではない値が渡され、自動的に文字列に変換された場合に警告を発します。これにより、たとえば、``yes`` や ``true`` (truish のブール値として解析) が文字列 ``'True'`` に変換されたり、バージョン番号 ``1.10`` (float 値として解析) が ``'1.1'`` に変換されたりする潜在的な問題が浮き彫りになります。このような変換は、コンテキストによっては予期せぬ動作が発生する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:64 -msgid "This behavior can be changed to be an error or to be ignored by setting the ``ANSIBLE_STRING_CONVERSION_ACTION`` environment variable, or by setting the ``string_conversion_action`` configuration in the ``defaults`` section of ``ansible.cfg``." -msgstr "この動作は、``ANSIBLE_STRING_CONVERSION_ACTION`` 環境変数を設定したり、``ansible.cfg`` の``defaults`` セクションで``string_conversion_action`` の設定を行うことで、エラーにしたり、無視するように変更することができます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:67 -msgid "Command line facts" -msgstr "コマンドラインファクト" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:69 -msgid "``cmdline`` facts returned in system will be deprecated in favor of ``proc_cmdline``. This change handles special case where Kernel command line parameter contains multiple values with the same key." -msgstr "システムで返される ``cmdline`` ファクトは非推奨となり、``proc_cmdline`` が採用されます。この変更により、カーネルのコマンドラインパラメーターに同じキーを持つ複数の値が含まれている特殊なケースに対応します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:72 -msgid "Bare variables in conditionals" -msgstr "条件のベアメタル変数" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:74 -msgid "In Ansible 2.7 and earlier, top-level variables sometimes treated boolean strings as if they were boolean values. This led to inconsistent behavior in conditional tests built on top-level variables defined as strings. Ansible 2.8 began changing this behavior. For example, if you set two conditions like this:" -msgstr "Ansible 2.7 およびそれ以前のバージョンでは、最上位レベルの変数が、ブール値の文字列をブール値のように扱うことがありました。このため、文字列として定義された最上位レベルの変数に基づいて構築された条件付きテストで、一貫性のない動作が発生していました。Ansible 2.8 では、この動作が変更になりました。たとえば、以下のように 2 つの条件を設定した場合は、次のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:85 -msgid "based on a variable you define **as a string** (with quotation marks around it):" -msgstr "**文字列** として定義する変数に基づきます (引用符で囲みます)。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:87 -msgid "In Ansible 2.7 and earlier, the two conditions above evaluated as ``True`` and ``False`` respectively if ``teardown: 'true'``" -msgstr "Ansible 2.7 以前では、``teardown: 'true'`` と設定すると、上記の 2 つの条件はそれぞれ ``True`` と ``False`` と評価されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:88 -msgid "In Ansible 2.7 and earlier, both conditions evaluated as ``False`` if ``teardown: 'false'``" -msgstr "Ansible 2.7 以前では、``teardown: 'false'`` の場合に、両方の条件が ``False`` と評価されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:89 -msgid "In Ansible 2.8 and later, you have the option of disabling conditional bare variables, so ``when: teardown`` always evaluates as ``True`` and ``when: not teardown`` always evaluates as ``False`` when ``teardown`` is a non-empty string (including ``'true'`` or ``'false'``)" -msgstr "Ansible 2.8 以降では、条件付きベア変数を無効にするオプションがあるため、``when: teardown`` は常に ``True`` として評価され、``when: not teardown`` は ``teardown`` が空ではない文字列 (``'true'`` または ``'false'`` を含む) の場合は常に ``False`` として評価されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:91 -msgid "Ultimately, ``when: 'string'`` will always evaluate as ``True`` and ``when: not 'string'`` will always evaluate as ``False``, as long as ``'string'`` is not empty, even if the value of ``'string'`` itself looks like a boolean. For users with playbooks that depend on the old behavior, we added a config setting that preserves it. You can use the ``ANSIBLE_CONDITIONAL_BARE_VARS`` environment variable or ``conditional_bare_variables`` in the ``defaults`` section of ``ansible.cfg`` to select the behavior you want on your control node. The default setting is ``true``, which preserves the old behavior. Set the config value or environment variable to ``false`` to start using the new option." -msgstr "最終的に、``when: 'string'`` は常に ``True`` として評価され、``when: not 'string'`` は ``'string'`` が空でない限り、``'string'`` 自身の値がブール値のように見えたとしても、``False`` として常に評価されます。以前の動作に依存している Playbook を使用している場合に向けて、以前の動作を維持するための設定を追加しました。環境変数 ``ANSIBLE_CONDITIONAL_BARE_VARS`` または ``ansible.cfg`` の ``defaults`` セクションにある ``conditional_bare_variables`` を使用して、制御ノードに必要な動作を選択することができます。デフォルトの設定は ``true`` で、以前の動作を保持します。新しいオプションの使用を開始するには、設定値または環境変数を ``false`` に設定します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:95 -msgid "In 2.10 the default setting for ``conditional_bare_variables`` will change to ``false``. In 2.12 the old behavior will be deprecated." -msgstr "2.10 では、``conditional_bare_variables`` のデフォルト設定が ``false`` に変更されます。2.12 では、以前の動作は非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:98 -msgid "Updating your playbooks" -msgstr "Playbook の更新" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:100 -msgid "To prepare your playbooks for the new behavior, you must update your conditional statements so they accept only boolean values. For variables, you can use the ``bool`` filter to evaluate the string ``'false'`` as ``False``:" -msgstr "Playbook を新しい動作に対応させるには、条件文を更新して、ブール値のみを受け付けるようにする必要があります。変数については ``bool`` フィルターを使用して、文字列 ``'false'`` を ``False`` として評価することができます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:114 -msgid "Alternatively, you can re-define your variables as boolean values (without quotation marks) instead of strings:" -msgstr "変数を、文字列ではなくブール値として再定義することができます (引用符は使用しません)。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:128 -msgid "For dictionaries and lists, use the ``length`` filter to evaluate the presence of a dictionary or list as ``True``:" -msgstr "ディクショナリーおよびリストについては、``length`` フィルターを使用してディクショナリーまたはリストの存在を ``True`` として評価します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:138 -msgid "Do not use the ``bool`` filter with lists or dictionaries. If you use ``bool`` with a list or dict, Ansible will always evaluate it as ``False``." -msgstr "``bool`` フィルターをリストまたはディクショナリーと共に使用しないでください。``bool`` をリストまたはディクショナリーと共に使用する場合、Ansible は常に ``False`` として評価します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:141 -msgid "Double-interpolation" -msgstr "二重の解釈" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:143 -msgid "The ``conditional_bare_variables`` setting also affects variables set based on other variables. The old behavior unexpectedly double-interpolated those variables. For example:" -msgstr "``conditional_bare_variables`` の設定は、他の変数に基づいて設定された変数にも影響します。以前の動作では、それらの変数が予期せず二重に補間されていました。以下に例を示します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:155 -msgid "In Ansible 2.7 and earlier, ``when: double_interpolated`` evaluated to the value of ``bare_variable``, in this case, ``False``. If the variable ``bare_variable`` is undefined, the conditional fails." -msgstr "Ansible 2.7 以前のバージョンでは、``when: double_interpolated`` は``bare_variable`` の値に評価され、この場合は ``False`` となります。変数 ``bare_variable`` が未定義の場合、この条件式は失敗します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:156 -msgid "In Ansible 2.8 and later, with bare variables disabled, Ansible evaluates ``double_interpolated`` as the string ``'bare_variable'``, which is ``True``." -msgstr "Ansible 2.8 以降では、ベア変数が無効な状態で、Ansible は ``double_interpolated`` を文字列 ``'bare_variable'`` として評価します。これは ``True`` となります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:158 -msgid "To double-interpolate variable values, use curly braces:" -msgstr "変数の値を二重引用符で囲むには、中括弧を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:167 -msgid "Nested variables" -msgstr "ネストされた変数" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:169 -msgid "The ``conditional_bare_variables`` setting does not affect nested variables. Any string value assigned to a subkey is already respected and not treated as a boolean. If ``complex_variable['subkey']`` is a non-empty string, then ``when: complex_variable['subkey']`` is always ``True`` and ``when: not complex_variable['subkey']`` is always ``False``. If you want a string subkey like ``complex_variable['subkey']`` to be evaluated as a boolean, you must use the ``bool`` filter." -msgstr "``conditional_bare_variables`` 設定はネストされた変数には影響を与えません。サブキーに割り当てられる文字列値はすでに考慮され、ブール値として処理されません。``complex_variable['subkey']`` が空ではない文字列である場合、``when: complex_variable['subkey']`` は常に ``True`` となり、``when: not complex_variable['subkey']`` は常に ``False`` になります。``complex_variable['subkey']`` などの文字列サブキーをブール値として評価するには、``bool`` フィルターを使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:172 -msgid "Gathering Facts" -msgstr "ファクトの収集" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:174 -msgid "In Ansible 2.8 the implicit \"Gathering Facts\" task in a play was changed to obey play tags. Previous to 2.8, the \"Gathering Facts\" task would ignore play tags and tags supplied from the command line and always run in a task." -msgstr "Ansible 2.8 では、プレイの中で暗黙的に実行される「Gathering Facts」タスクが、プレイタグに従うように変更されました。2.8 より前のバージョンでは、「Gathering Facts」タスクは play タグやコマンドラインから提供されたタグを無視し、常にタスクの中で実行されていました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:178 -msgid "The behavior change affects the following example play." -msgstr "動作の変更は、次のプレイ例に影響します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:193 -msgid "In Ansible 2.8, if you supply ``--tags nginx``, the implicit \"Gathering Facts\" task will be skipped, as the task now inherits the tag of ``webserver`` instead of ``always``." -msgstr "Ansible 2.8 では、``--tags nginx`` を指定すると、タスクが ``always`` ではなく ``webserver`` のタグを継承するため、暗黙的な「Gathering Facts」タスクが省略されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:197 -msgid "If no play level tags are set, the \"Gathering Facts\" task will be given a tag of ``always`` and will effectively match prior behavior." -msgstr "プレイレベルのタグが設定されていない場合、「Gathering Facts」タスクには ``always`` というタグが与えられ、それまでの行動と効果的に一致します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:201 -msgid "You can achieve similar results to the pre-2.8 behavior, by using an explicit ``gather_facts`` task in your ``tasks`` list." -msgstr "``tasks`` で一覧で明示的な ``gather_facts`` タスクを使用すると、バージョン 2.8 より前の動作と同様の結果が得られます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:224 -msgid "Python Interpreter Discovery" -msgstr "Python インタープリターの検出" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:226 -msgid "In Ansible 2.7 and earlier, Ansible defaulted to :command:`/usr/bin/python` as the setting for ``ansible_python_interpreter``. If you ran Ansible against a system that installed Python with a different name or a different path, your playbooks would fail with ``/usr/bin/python: bad interpreter: No such file or directory`` unless you either set ``ansible_python_interpreter`` to the correct value for that system or added a Python interpreter and any necessary dependencies at :command:`usr/bin/python`." -msgstr "Ansible 2.7 以前のバージョンでは、``ansible_python_interpreter`` の設定として :command:`/usr/bin/python` が Ansible のデフォルトでした。異なる名前やパスで Python をインストールしたシステムに対して Ansible を実行した場合は、``ansible_python_interpreter`` をそのシステムの正しい値に設定するか、Python インタープリターと必要な依存関係を :command:`usr/bin/python` に追加しない限り、Playbook は ``/usr/bin/python: bad interpreter: No such file or directory`` で失敗します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:234 -msgid "Starting in Ansible 2.8, Ansible searches for the correct path and executable name for Python on each target system, first in a lookup table of default Python interpreters for common distros, then in an ordered fallback list of possible Python interpreter names/paths." -msgstr "Ansible 2.8 以降、Ansible は各ターゲットシステム上の Python の正しいパスと実行ファイル名を、最初は一般的なディストリビューションのデフォルト Python インタープリターの lookup テーブルから、次に可能な Python インタープリター名/パスの順序付きフォールバックリストから検索します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:239 -msgid "It's risky to rely on a Python interpreter set from the fallback list, because the interpreter may change on future runs. If an interpreter from higher in the fallback list gets installed (for example, as a side-effect of installing other packages), your original interpreter and its dependencies will no longer be used. For this reason, Ansible warns you when it uses a Python interpreter discovered from the fallback list. If you see this warning, the best solution is to explicitly set ``ansible_python_interpreter`` to the path of the correct interpreter for those target systems." -msgstr "フォールバックリストから設定された Python インタープリターに依存するのはリスクがあります。なぜなら、将来の実行時にインタープリターが変更される可能性があるためです。フォールバックリストの上位にあるインタープリタがインストールされると (たとえば、他のパッケージをインストールする際の副作用として)、元のインタープリターとその依存関係は使用できなくなります。このような理由から、Ansible はフォールバックリストから検出された Python インタープリターを使用する際に警告を表示します。この警告が表示された場合、最良の解決策は、明示的に ``ansible_python_interpreter`` にそれらのターゲットシステムの正しいインタープリターのパスを設定することです。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:248 -msgid "You can still set ``ansible_python_interpreter`` to a specific path at any variable level (as a host variable, in vars files, in playbooks, and so on). If you prefer to use the Python interpreter discovery behavior, use one of the four new values for ``ansible_python_interpreter`` introduced in Ansible 2.8:" -msgstr "これまで通り、どの変数レベル (ホスト変数、vars ファイル、Playbook など) でも、``ansible_python_interpreter`` を特定のパスに設定することができます。Python インタープリターの検出動作を使用する場合は、Ansible 2.8 で導入された ``ansible_python_interpreter`` の新しい 4 つの値のうちの 1 つを使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:255 -msgid "New value" -msgstr "新しい値" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:255 -msgid "Behavior" -msgstr "動作" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:257 -msgid "auto |br| (future default)" -msgstr "自動 |br| (将来のデフォルト)" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:257 -msgid "If a Python interpreter is discovered, Ansible uses the discovered Python, even if :command:`/usr/bin/python` is also present. Warns when using the fallback list." -msgstr "Python インタープリターが検出され、:command:`/usr/bin/python` がない場合に、Ansible は検出された Python を使用します。フォールバックリストを使用する際に警告します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:262 -msgid "**auto_legacy** |br| (Ansible 2.8 default)" -msgstr "**auto_legacy** |br| (Ansible 2.8 デフォルト)" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:262 -msgid "If a Python interpreter is discovered, and :command:`/usr/bin/python` is absent, Ansible uses the discovered Python. Warns when using the fallback list." -msgstr "Python インタープリターが検出され、:command:`/usr/bin/python` がない場合に、Ansible は検出された Python を使用します。フォールバックリストを使用する際に警告します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:267 -msgid "If a Python interpreter is discovered, and :command:`/usr/bin/python` is present, Ansible uses :command:`/usr/bin/python` and prints a deprecation warning about future default behavior. Warns when using the fallback list." -msgstr "Python インタープリターが発見され、:command:`/usr/bin/python` が存在する場合、Ansible は :command:`/usr/bin/python` を使用し、将来のデフォルトの動作について非推奨の警告を表示します。フォールバックリストを使用する際に警告します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:274 -msgid "auto_legacy_silent" -msgstr "auto_legacy_silent" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:274 -msgid "Behaves like ``auto_legacy`` but suppresses the deprecation and fallback-list warnings." -msgstr "``auto_legacy`` のような動作はしますが、非推奨とフォールバックリストに関する警告は抑制されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:277 -msgid "auto_silent" -msgstr "auto_silent" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:277 -msgid "Behaves like ``auto`` but suppresses the fallback-list warning." -msgstr "``auto`` のように動作しますが、fallback-list の警告は表示されません。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:282 -msgid "In Ansible 2.12, Ansible will switch the default from :literal:`auto_legacy` to :literal:`auto`. The difference in behaviour is that :literal:`auto_legacy` uses :command:`/usr/bin/python` if present and falls back to the discovered Python when it is not present. :literal:`auto` will always use the discovered Python, regardless of whether :command:`/usr/bin/python` exists. The :literal:`auto_legacy` setting provides compatibility with previous versions of Ansible that always defaulted to :command:`/usr/bin/python`." -msgstr "Ansible 2.12 では、Ansible はデフォルトを :literal:`auto_legacy` から :literal:`auto` に変更します。挙動の違いは、:literal:`auto_legacy` は :command:`/usr/bin/python` が存在すればそれを使用し、存在しなければ検出された Python にフォールバックします。:literal:`auto` は :command:`/usr/bin/python` が存在するかどうかに関わらず、常に検出された Python を使用します。:literal:`auto_legacy` の設定は、常に :command:`/usr/bin/python` をデフォルトとしていた以前のバージョンの Ansible との互換性を提供します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:289 -msgid "If you installed Python and dependencies (``boto``, and so on) to :command:`/usr/bin/python` as a workaround on distros with a different default Python interpreter (for example, Ubuntu 16.04+, RHEL8, Fedora 23+), you have two options:" -msgstr "異なるデフォルトの Python インタープリターを持つディストリビューション (例: Ubuntu 16.04 以降、RHEL 8、Fedora 23 以降) での回避策として、Python と依存ファイル (``boto`` など) を :command:`/usr/bin/python` にインストールした場合のオプションが 2 つあります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:294 -msgid "Move existing dependencies over to the default Python for each platform/distribution/version." -msgstr "各プラットフォーム/ディストリビューション/バージョンで、既存の依存関係をデフォルトの Python に移動します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:295 -msgid "Use ``auto_legacy``. This setting lets Ansible find and use the workaround Python on hosts that have it, while also finding the correct default Python on newer hosts. But remember, the default will change in 4 releases." -msgstr "``auto_legacy`` を使用します。この設定により、Ansible は Python があるホストでは回避策の Python を見つけて使用し、新しいホストでは正しいデフォルトの Python を見つけることができます。ただし、デフォルトは 4 つのリリースで変更されることを忘れないでください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:299 -msgid "Retry File Creation default" -msgstr "ファイル作成の再試行デフォルト" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:301 -msgid "In Ansible 2.8, ``retry_files_enabled`` now defaults to ``False`` instead of ``True``. The behavior can be modified to previous version by editing the default ``ansible.cfg`` file and setting the value to ``True``." -msgstr "Ansible 2.8 では、``retry_files_enabled`` は ``True`` ではなく ``False`` にデフォルト設定されています。動作は、デフォルトの ``ansible.cfg`` ファイルを編集し、値を ``True`` に設定すると変更できます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:308 -msgid "Become Prompting" -msgstr "Become プロンプト" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:310 -msgid "Beginning in version 2.8, by default Ansible will use the word ``BECOME`` to prompt you for a password for elevated privileges (``sudo`` privileges on Unix systems or ``enable`` mode on network devices):" -msgstr "バージョン 2.8 以降、Ansible のデフォルトでは、昇格権限 (Unix システムでは ``sudo`` 権限、またはネットワークデバイスでは ``enable`` モード) のパスワードの入力を促す際に、``BECOME`` という単語を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:312 -msgid "By default in Ansible 2.8::" -msgstr "Ansible 2.8 のデフォルト::" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:317 -msgid "If you want the prompt to display the specific ``become_method`` you're using, instead of the agnostic value ``BECOME``, set :ref:`AGNOSTIC_BECOME_PROMPT` to ``False`` in your Ansible configuration." -msgstr "使用している特定の ``become_method`` をプロンプトで表示する場合は、Ansible 設定で非依存値の ``BECOME`` ではなく、:ref:`AGNOSTIC_BECOME_PROMPT` を ``False`` に設定します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:319 -msgid "By default in Ansible 2.7, or with ``AGNOSTIC_BECOME_PROMPT=False`` in Ansible 2.8::" -msgstr "デフォルトでは Ansible 2.7、または Ansible 2.8 の ``AGNOSTIC_BECOME_PROMPT=False`` で使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:327 -msgid "Setting the async directory using ``ANSIBLE_ASYNC_DIR`` as an task/play environment key is deprecated and will be removed in Ansible 2.12. You can achieve the same result by setting ``ansible_async_dir`` as a variable like::" -msgstr "``ANSIBLE_ASYNC_DIR`` を task/play 環境キーとして使用して非同期ディレクトリーを設定することは非推奨であり、Ansible 2.12 で削除される予定です。``ansible_async_dir`` を次のように変数として設定することで、同じ結果を得ることができます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:336 -msgid "Plugin writers who need a ``FactCache`` object should be aware of two deprecations:" -msgstr "``FactCache`` オブジェクトを必要とするプラグイン作成者は、以下の 2 つの非推奨を認識する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:338 -msgid "The ``FactCache`` class has moved from ``ansible.plugins.cache.FactCache`` to ``ansible.vars.fact_cache.FactCache``. This is because the ``FactCache`` is not part of the cache plugin API and cache plugin authors should not be subclassing it. ``FactCache`` is still available from its old location but will issue a deprecation warning when used from there. The old location will be removed in Ansible 2.12." -msgstr "``FactCache`` クラスは ``ansible.plugins.cache.FactCache`` から``ansible.vars.fact_cache.FactCache`` へ移動しました。これは、``FactCache`` が cache プラグイン API の一部ではないため、cache プラグインの作成者はこれをサブクラス化すべきではないという理由によるものです。``FactCache`` は以前の場所でも利用できますが、そこから使用すると非推奨の警告が表示されます。この古い場所は Ansible 2.12 で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:344 -msgid "The ``FactCache.update()`` method has been converted to follow the dict API. It now takes a dictionary as its sole argument and updates itself with the dictionary's items. The previous API where ``update()`` took a key and a value will now issue a deprecation warning and will be removed in 2.12. If you need the old behavior switch to ``FactCache.first_order_merge()`` instead." -msgstr "``FactCache.update()`` メソッドは、dict API に従うように変更されました。ディレクトリーを唯一の引数として受け取り、そのディレクトリーの項目で自身を更新するようになりました。``update()`` がキーと値を受け取っていた以前の API は、現在は非推奨の警告が表示されされ、2.12 で削除されます。以前の動作が必要な場合は、代わりに ``FactCache.first_order_merge()`` に切り替えてください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:350 -msgid "Supporting file-backed caching via self.cache is deprecated and will be removed in Ansible 2.12. If you maintain an inventory plugin, update it to use ``self._cache`` as a dictionary. For implementation details, see the :ref:`developer guide on inventory plugins`." -msgstr "self.cache によるファイルバックキャッシングのサポートは非推奨で、Ansible 2.12 で削除されます。インベントリープラグインを管理している場合は、ディクショナリーとして ``self._cache`` を使用するように更新してください。実装の詳細は、「:ref:`inventory プラグインの開発者ガイド`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:354 -msgid "Importing cache plugins directly is deprecated and will be removed in Ansible 2.12. Use the plugin_loader so direct options, environment variables, and other means of configuration can be reconciled using the config system rather than constants." -msgstr "cache プラグインを直接インポートすることは非推奨であり、Ansible 2.12 で削除される予定です。plugin_loader を使用することで、ダイレクトオプション、環境変数、その他の設定手段を、定数ではなく設定システムを使って調整することができます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:368 -msgid "The exec wrapper that runs PowerShell modules has been changed to set ``$ErrorActionPreference = \"Stop\"`` globally. This may mean that custom modules can fail if they implicitly relied on this behavior. To get the old behavior back, add ``$ErrorActionPreference = \"Continue\"`` to the top of the module. This change was made to restore the old behavior of the EAP that was accidentally removed in a previous release and ensure that modules are more resilient to errors that may occur in execution." -msgstr "PowerShell モジュールを実行する exec ラッパーは、``$ErrorActionPreference = \"Stop\"`` をグローバルに設定するように変更になりました。これにより、カスタムモジュールがこの動作に暗黙的に依存していた場合は、失敗する可能性があります。以前の動作を取り戻すには、モジュールの先頭に ``$ErrorActionPreference = \"Continue\"`` を追加してください。この変更は、以前のリリースで誤って削除された EAP の古い動作を復元し、実行時に発生するエラーに対してモジュールがより耐性を持つようにするために行われました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:374 -msgid "Version 2.8.14 of Ansible changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the ``mode`` change has been reverted in 2.8.15, and ``mode`` will now default to ``0o666 & ~umask`` as in previous versions of Ansible." -msgstr "Ansible のバージョン 2.8.14 は、ユーザーがファイルベースのタスクで ``mode`` パラメーターを指定しなかった場合に、ファイルベースのタスクのデフォルトモードを ``0o600 & ~umask`` に変更しました。これは、再編成した CVE レポートに対する対応でした。その結果、2.8.15 では ``mode`` の変更が元に戻され、以前のバージョンの Ansible と同様に、``mode`` のデフォルトが ``0o666 & ~umask`` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:375 -msgid "If you changed any tasks to specify less restrictive permissions while using 2.8.14, those changes will be unnecessary (but will do no harm) in 2.8.15." -msgstr "2.8.14 を使用する際に、より制限の少ないパーミッションを指定するようにタスクを変更した場合、2.8.15 ではその変更は不要になります (ただし、害はありません)。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:378 -msgid "``dnf`` and ``yum`` - As of version 2.8.15, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task." -msgstr "``dnf`` および ``yum`` - バージョン 2.8.15 より、``dnf`` モジュール (および ``dnf`` を使用する場合は ``yum`` アクション) がパッケージの GPG 署名を正しく検証するようになりました (CVE-2020-14365)。``Failed to validate GPG signature for [package name]`` のようなエラーが表示された場合は、使用している DNF リポジトリーやパッケージの GPG キーが正しくインポートされていることを確認してください。これを行う 1 つの方法として、``rpm_key`` モジュールの使用があります。推奨はしませんが、場合によっては GPG チェックを無効にする必要があるかもしれません。これは、``dnf`` タスクまたは ``yum`` タスクに ``disable_gpg_check: yes`` を明示的に追加することで実現できます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:386 -msgid "ec2_remote_facts" -msgstr "ec2_remote_facts" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:387 -msgid "azure" -msgstr "azure" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:388 -msgid "cs_nic" -msgstr "cs_nic" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:389 -msgid "netscaler" -msgstr "netscaler" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:390 -msgid "win_msi" -msgstr "win_msi" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:395 -msgid "The following modules will be removed in Ansible 2.12. Please update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.12 で削除されます。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:397 -msgid "``foreman`` use `foreman-ansible-modules `_ instead." -msgstr "``foreman`` は、代わりに `foreman-ansible-modules `_ を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:398 -msgid "``katello`` use `foreman-ansible-modules `_ instead." -msgstr "``katello`` は、代わりに `foreman-ansible-modules `_ を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:399 -msgid "``github_hooks`` use :ref:`github_webhook ` and :ref:`github_webhook_facts ` instead." -msgstr "``github_hooks`` は、代わりに :ref:`github_webhook ` および :ref:`github_webhook_facts ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:400 -msgid "``digital_ocean`` use :ref:`digital_ocean_droplet ` instead." -msgstr "``digital_ocean`` は、代わりに :ref:`digital_ocean_droplet ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:401 -msgid "``gce`` use :ref:`gcp_compute_instance ` instead." -msgstr "``gce`` は、代わりに :ref:`gcp_compute_instance ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:402 -msgid "``gcspanner`` use :ref:`gcp_spanner_instance ` and :ref:`gcp_spanner_database ` instead." -msgstr "``gcspanner`` は、代わりに :ref:`gcp_spanner_instance ` および :ref:`gcp_spanner_database ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:403 -msgid "``gcdns_record`` use :ref:`gcp_dns_resource_record_set ` instead." -msgstr "``gcdns_record`` は、代わりに :ref:`gcp_dns_resource_record_set ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:404 -msgid "``gcdns_zone`` use :ref:`gcp_dns_managed_zone ` instead." -msgstr "``gcdns_zone`` は、代わりに :ref:`gcp_dns_managed_zone ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:405 -msgid "``gcp_forwarding_rule`` use :ref:`gcp_compute_global_forwarding_rule ` or :ref:`gcp_compute_forwarding_rule ` instead." -msgstr "``gcp_forwarding_rule`` は、代わりに :ref:`gcp_compute_global_forwarding_rule ` または:ref:`gcp_compute_forwarding_rule ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:406 -msgid "``gcp_healthcheck`` use :ref:`gcp_compute_health_check `, :ref:`gcp_compute_http_health_check `, or :ref:`gcp_compute_https_health_check ` instead." -msgstr "``gcp_healthcheck`` は、代わりに :ref:`gcp_compute_health_check `、:ref:`gcp_compute_http_health_check `、または :ref:`gcp_compute_https_health_check ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:407 -msgid "``gcp_backend_service`` use :ref:`gcp_compute_backend_service ` instead." -msgstr "``gcp_backend_service`` は、代わりに :ref:`gcp_compute_backend_service ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:408 -msgid "``gcp_target_proxy`` use :ref:`gcp_compute_target_http_proxy ` instead." -msgstr "``gcp_target_proxy`` は、代わりに :ref:`gcp_compute_target_http_proxy ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:409 -msgid "``gcp_url_map`` use :ref:`gcp_compute_url_map ` instead." -msgstr "``gcp_url_map`` は、代わりに :ref:`gcp_compute_url_map ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:410 -msgid "``panos`` use the `Palo Alto Networks Ansible Galaxy role `_ instead." -msgstr "``panos`` は、代わりに `Palo Alto Networks Ansible Galaxy role `_ を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:416 -msgid "The ``foreman`` and ``katello`` modules have been deprecated in favor of a set of modules that are broken out per entity with better idempotency in mind." -msgstr "``foreman`` と ``katello`` のモジュールは非推奨になり、より良い冪等性を考慮してエンティティーごとに分割されたモジュールのセットが採用されました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:417 -msgid "The ``foreman`` and ``katello`` modules replacement is officially part of the Foreman Community and supported there." -msgstr "``foreman`` モジュールおよび ``katello`` モジュールの置き換えは、Foreman Community の一部であり、そこでサポートされます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:418 -msgid "The ``tower_credential`` module originally required the ``ssh_key_data`` to be the path to a ssh_key_file. In order to work like Tower/AWX, ``ssh_key_data`` now contains the content of the file. The previous behavior can be achieved with ``lookup('file', '/path/to/file')``." -msgstr "``tower_credential`` モジュールでは、もともと ``ssh_key_data`` に ssh_key_file のパスを指定する必要がありました。Tower/AWX のように動作させるために、``ssh_key_data`` にファイルの内容を含めるようになりました。以前の動作は ``lookup('file', '/path/to/file')`` で実現できます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:421 -msgid "The ``win_scheduled_task`` module deprecated support for specifying a trigger repetition as a list and this format will be removed in Ansible 2.12. Instead specify the repetition as a dictionary value." -msgstr "``win_scheduled_task`` モジュールは、トリガーの繰り返しをリストとして指定するサポートを非推奨としており、このフォーマットは Ansible 2.12で 削除される予定です。代わりに、繰り返しをディクショナリーの値として指定します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:424 -msgid "The ``win_feature`` module has removed the deprecated ``restart_needed`` return value, use the standardized ``reboot_required`` value instead." -msgstr "``win_feature`` モジュールによって非推奨の ``restart_needed`` の戻り値が削除され、代わりに標準化された ``reboot_required`` 値を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:427 -msgid "The ``win_package`` module has removed the deprecated ``restart_required`` and ``exit_code`` return value, use the standardized ``reboot_required`` and ``rc`` value instead." -msgstr "``win_package`` モジュールによって非推奨の ``restart_required`` および ``exit_code`` の戻り値が削除され、代わりに標準化された ``reboot_required`` および ``rc`` の値が使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:430 -msgid "The ``win_get_url`` module has removed the deprecated ``win_get_url`` return dictionary, contained values are returned directly." -msgstr "``win_get_url`` モジュールは、非推奨の ``win_get_url`` 戻りディクショナリーを削除し、含まれる値が直接返されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:433 -msgid "The ``win_get_url`` module has removed the deprecated ``skip_certificate_validation`` option, use the standardized ``validate_certs`` option instead." -msgstr "``win_get_url`` モジュールによって非推奨の ``skip_certificate_validation`` オプションが削除され、代わりに標準化された ``validate_certs`` オプションを使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:436 -msgid "The ``vmware_local_role_facts`` module now returns a list of dicts instead of a dict of dicts for role information." -msgstr "``vmware_local_role_facts`` モジュールは、ロール情報に対して、dict の中の dict ではなく、dict のリストを返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:438 -msgid "If ``docker_network`` or ``docker_volume`` were called with ``diff: yes``, ``check_mode: yes`` or ``debug: yes``, a return value called ``diff`` was returned of type ``list``. To enable proper diff output, this was changed to type ``dict``; the original ``list`` is returned as ``diff.differences``." -msgstr "``docker_network`` または ``docker_volume`` が ``diff: yes``、``check_mode: yes``、または``debug: yes`` で呼び出された場合は、``diff`` と呼ばれる ``list`` タイプの戻り値が返されていました。適切な diff 出力を可能にするために、これを ``dict`` タイプに変更し、元の ``list`` は``diff.differences`` として返されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:442 -msgid "The ``na_ontap_cluster_peer`` module has replaced ``source_intercluster_lif`` and ``dest_intercluster_lif`` string options with ``source_intercluster_lifs`` and ``dest_intercluster_lifs`` list options" -msgstr "``na_ontap_cluster_peer`` モジュールでは、文字列オプションの ``source_intercluster_lif`` および ``dest_intercluster_lif`` が、リストオプションの ``source_intercluster_lifs`` および ``dest_intercluster_lifs`` に置き換わりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:445 -msgid "The ``modprobe`` module now detects kernel builtins. Previously, attempting to remove (with ``state: absent``) a builtin kernel module succeeded without any error message because ``modprobe`` did not detect the module as ``present``. Now, ``modprobe`` will fail if a kernel module is builtin and ``state: absent`` (with an error message from the modprobe binary like ``modprobe: ERROR: Module nfs is builtin.``), and it will succeed without reporting changed if ``state: present``. Any playbooks that are using ``changed_when: no`` to mask this quirk can safely remove that workaround. To get the previous behavior when applying ``state: absent`` to a builtin kernel module, use ``failed_when: false`` or ``ignore_errors: true`` in your playbook." -msgstr "``modprobe`` モジュールがカーネルビルドインを検出するようになりました。これまでは、``modprobe`` がそのモジュールを ``present`` として検出していなかったため、組み込みカーネルモジュールを (``state: absent`` で) 削除しようとすると、成功してエラーメッセージも表示されませんでした。現在では、``modprobe`` はカーネルモジュールが組み込まれて ``state: absent`` の場合は失敗し (modprobe バイナリーから ``modprobe: ERROR: Module nfs is builtin.`` のようなエラーメッセージが表示されます)、``state: present`` の場合は変更を報告せずに成功します。この特異な動作を隠すために ``changed_when: no`` を使用している Playbook は、その回避策を削除しても問題はありません。組み込みカーネルモジュールに ``state: absent`` を適用して以前の動作を得るには、Playbook で ``failed_when: false`` または ``ignore_errors: true`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:453 -msgid "The ``digital_ocean`` module has been deprecated in favor of modules that do not require external dependencies. This allows for more flexibility and better module support." -msgstr "``digital_ocean`` モジュールは非推奨となり、外部依存を必要としないモジュールが採用されました。これにより、より柔軟で優れたモジュールサポートが可能になります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:456 -msgid "The ``docker_container`` module has deprecated the returned fact ``docker_container``. The same value is available as the returned variable ``container``. The returned fact will be removed in Ansible 2.12." -msgstr "``docker_container`` モジュールは、返されるファクト ``docker_container`` を非推奨としています。返される変数 ``container`` と同じ値が利用できます。返されるファクトは Ansible 2.12 で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:458 -msgid "The ``docker_network`` module has deprecated the returned fact ``docker_container``. The same value is available as the returned variable ``network``. The returned fact will be removed in Ansible 2.12." -msgstr "``docker_network`` モジュールは、返されるファクト ``docker_container`` を非推奨としています。返される変数 ``network`` と同じ値が利用できます。返されるファクトは Ansible 2.12 で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:460 -msgid "The ``docker_volume`` module has deprecated the returned fact ``docker_container``. The same value is available as the returned variable ``volume``. The returned fact will be removed in Ansible 2.12." -msgstr "``docker_volume`` モジュールは、返されるファクト ``docker_container`` を非推奨としています。返される変数 ``volume`` と同じ値が利用できます。返されるファクトは Ansible 2.12 で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:463 -msgid "The ``docker_service`` module was renamed to :ref:`docker_compose `." -msgstr "``docker_service`` モジュールの名前が :ref:`docker_compose ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:464 -msgid "The renamed ``docker_compose`` module used to return one fact per service, named same as the service. A dictionary of these facts is returned as the regular return value ``services``. The returned facts will be removed in Ansible 2.12." -msgstr "サービスと同じ名前に変更した ``docker_compose`` モジュールは、サービスごとに 1 つのファクトを返すために使用されます。これらのファクトのディクショナリーは、通常の戻り値 ``services`` として返されます。返されるファクトは Ansible 2.12 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:471 -msgid "The ``docker_swarm_service`` module no longer sets a defaults for the following options:" -msgstr "``docker_swarm_service`` モジュールでは、以下のオプションにデフォルトを設定しなくなりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:469 -msgid "``user``. Before, the default was ``root``." -msgstr "``user``。以前のデフォルトは ``root`` です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:470 -msgid "``update_delay``. Before, the default was ``10``." -msgstr "``update_delay``。以前のデフォルトは ``10`` です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:471 -msgid "``update_parallelism``. Before, the default was ``1``." -msgstr "``update_parallelism``。以前のデフォルトは ``1`` です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:473 -msgid "``vmware_vm_facts`` used to return dict of dict with virtual machine's facts. Ansible 2.8 and onwards will return list of dict with virtual machine's facts. Please see module ``vmware_vm_facts`` documentation for example." -msgstr "``vmware_vm_facts`` は、仮想マシンのファクトを含む dict の dict を返すために使用されます。Ansible 2.8 以降では、仮想マシンのファクトを含む dict のリストを返します。例として、モジュール ``vmware_vm_facts`` のドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:476 -msgid "``vmware_guest_snapshot`` module used to return ``results``. Since Ansible 2.8 and onwards ``results`` is a reserved keyword, it is replaced by ``snapshot_results``. Please see module ``vmware_guest_snapshots`` documentation for example." -msgstr "``results`` を返すのに使用される ``vmware_guest_snapshot`` モジュール。Ansible 2.8 以降、``results`` は予約キーワードであるため、``snapshot_results`` に置き換えられています。たとえば、モジュール ``vmware_guest_snapshots`` ドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:479 -msgid "The ``panos`` modules have been deprecated in favor of using the Palo Alto Networks `Ansible Galaxy role `_. Contributions to the role can be made `here `_." -msgstr "``panos`` モジュールが非推奨となり、Palo Alto Networks の `Ansible Galaxy ロール `_ が使用されるようになりました。ロールへの貢献は `こちら `_ から行うことができます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:483 -msgid "The ``ipa_user`` module originally always sent ``password`` to FreeIPA regardless of whether the password changed. Now the module only sends ``password`` if ``update_password`` is set to ``always``, which is the default." -msgstr "``ipa_user`` モジュールは、パスワードが変更されたかどうかに関わらず、常に ``password`` を FreeIPA に送信します。現在は、``update_password`` がデフォルトである ``always`` に設定されている場合のみ ``password`` を送信します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:485 -msgid "The ``win_psexec`` has deprecated the undocumented ``extra_opts`` module option. This will be removed in Ansible 2.10." -msgstr "``win_psexec`` では、文書化されていない ``extra_opts`` モジュールオプションが非推奨になりました。これは Ansible 2.10 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:487 -msgid "The ``win_nssm`` module has deprecated the following options in favor of using the ``win_service`` module to configure the service after installing it with ``win_nssm``: * ``dependencies``, use ``dependencies`` of ``win_service`` instead * ``start_mode``, use ``start_mode`` of ``win_service`` instead * ``user``, use ``username`` of ``win_service`` instead * ``password``, use ``password`` of ``win_service`` instead These options will be removed in Ansible 2.12." -msgstr "``win_nssm`` モジュールでは、以下のオプションが非推奨になり、``win_nssm`` を使用したインストール後のサービス設定に ``win_service`` を使用することが推奨されます。* ``dependencies`` の代わりに ``win_service`` の ``dependencies`` を使用します。 * ``start_mode`` の代わりに ``win_service`` の ``start_mode`` を使用します。 * ``user`` の代わりに ``win_service`` の ``username`` を使用します。 * ``password`` の代わりに ``win_service`` の ``password`` を使用します。このオプションは、Ansible 2.12 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:494 -msgid "The ``win_nssm`` module has also deprecated the ``start``, ``stop``, and ``restart`` values of the ``status`` option. You should use the ``win_service`` module to control the running state of the service. This will be removed in Ansible 2.12." -msgstr "``win_nssm`` モジュールでは、``status`` オプションの ``start``、``stop``、および ``restart`` の値も非推奨になりました。``win_service`` モジュールを使用して、サービスの実行状態を制御する必要があります。これは、Ansible 2.12 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:497 -msgid "The ``status`` module option for ``win_nssm`` has changed its default value to ``present``. Before, the default was ``start``. Consequently, the service is no longer started by default after creation with ``win_nssm``, and you should use the ``win_service`` module to start it if needed." -msgstr "``win_nssm`` の ``status`` モジュールオプションのデフォルト値が ``present`` に変更されました。以前のデフォルトは ``start`` でした。その結果、``win_nssm`` で作成したサービスはデフォルトでは開始されなくなり、必要に応じて ``win_service`` モジュールを使用してサービスを開始する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:501 -msgid "The ``app_parameters`` module option for ``win_nssm`` has been deprecated; use ``argument`` instead. This will be removed in Ansible 2.12." -msgstr "``win_nssm`` の ``app_parameters`` モジュールオプションは非推奨となります。代わりに ``argument`` を使用してください。このオプションは、Ansible 2.12 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:503 -msgid "The ``app_parameters_free_form`` module option for ``win_nssm`` has been aliased to the new ``arguments`` option." -msgstr "``win_nssm`` 用の ``app_parameters_free_form`` モジュールオプションは、新しい ``arguments`` オプションに対してエイリアスが設定されました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:505 -msgid "The ``win_dsc`` module will now validate the input options for a DSC resource. In previous versions invalid options would be ignored but are now not." -msgstr "``win_dsc`` モジュールは、DSC リソースの入力オプションを検証しました。以前のバージョンでは無効なオプションは無視されますが、今回は無視されません。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:508 -msgid "The ``openssl_pkcs12`` module will now regenerate the pkcs12 file if there are differences between the file on disk and the parameters passed to the module." -msgstr "ディスク上のファイルと、モジュールに渡すパラメーターに違いがある場合は、``openssl_pkcs12`` モジュールが pkcs12 ファイルを再生成するようになります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:513 -msgid "Ansible no longer defaults to the ``paramiko`` connection plugin when using macOS as the control node. Ansible will now use the ``ssh`` connection plugin by default on a macOS control node. Since ``ssh`` supports connection persistence between tasks and playbook runs, it performs better than ``paramiko``. If you are using password authentication, you will need to install ``sshpass`` when using the ``ssh`` connection plugin. Or you can explicitly set the connection type to ``paramiko`` to maintain the pre-2.8 behavior on macOS." -msgstr "Ansible は、macOS を制御ノードとして使用する場合は、``paramiko`` 接続プラグインをデフォルトで使用しなくなりました。Ansible は、macOS のコントロールノードではデフォルトで ``ssh`` の接続プラグインを使用するようになりました。``ssh`` は、タスクと Playbook の実行間の接続持続性をサポートしているため、``paramiko`` よりもパフォーマンスが高くなります。パスワード認証を使用している場合は、``ssh`` 接続プラグインを使用する際に ``sshpass`` をインストールする必要があります。または、接続タイプを明示的に ``paramiko`` に設定することで、macOS での 2.8 以前の動作を維持することができます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:515 -msgid "Connection plugins have been standardized to allow use of ``ansible__user`` and ``ansible__password`` variables. Variables such as ``ansible__pass`` and ``ansible__username`` are treated with lower priority than the standardized names and may be deprecated in the future. In general, the ``ansible_user`` and ``ansible_password`` vars should be used unless there is a reason to use the connection-specific variables." -msgstr "接続プラグインは、``ansible__user`` 変数および ``ansible__password`` 変数を使用できるように標準化されました。``ansible__pass`` や ``ansible__username`` のような変数は、標準化された名前よりも優先度が低く扱われ、将来的には非推奨になる可能性があります。一般的には、接続専用の変数を使用する理由がない限り、``ansible_user`` と ``ansible_password`` の変数を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:522 -msgid "The ``powershell`` shell plugin now uses ``async_dir`` to define the async path for the results file and the default has changed to ``%USERPROFILE%\\.ansible_async``. To control this path now, either set the ``ansible_async_dir`` variable or the ``async_dir`` value in the ``powershell`` section of the config ini." -msgstr "``powershell`` シェルプラグインでは、結果ファイルの非同期パスの定義に ``async_dir`` を使用するようになり、デフォルトは ``%USERPROFILE%\\.ansible_async`` に変更になりました。このパスを制御するには、``ansible_async_dir`` 変数を設定するか、config ini の ``powershell`` セクションで ``async_dir`` の値を設定します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:526 -msgid "Order of enabled inventory plugins (:ref:`INVENTORY_ENABLED`) has been updated, :ref:`auto ` is now before :ref:`yaml ` and :ref:`ini `." -msgstr "有効なインベントリープラグイン (:ref:`INVENTORY_ENABLED`) の順序が更新されました。:ref:`auto ` は :ref:`yaml ` および :ref:`ini ` の前に追加されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:528 -msgid "The private ``_options`` attribute has been removed from the ``CallbackBase`` class of callback plugins. If you have a third-party callback plugin which needs to access the command line arguments, use code like the following instead of trying to use ``self._options``:" -msgstr "``_options`` のプライベート属性は、コールバックプラグインの ``CallbackBase`` クラスから削除されました。コマンドライン引数にアクセスする必要のあるサードパーティー製 callback プラグインをお持ちの場合は、``self._options`` を使用する代わりに、以下のようなコードを使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:538 -msgid "``context.CLIARGS`` is a read-only dictionary so normal dictionary retrieval methods like ``CLIARGS.get('tags')`` and ``CLIARGS['tags']`` work as expected but you won't be able to modify the cli arguments at all." -msgstr "``context.CLIARGS`` は読み取り専用のディクショナリーであるため、``CLIARGS.get('tags')`` や``CLIARGS['tags']`` のような通常のディクショナリーの検索方法は期待通りに動作しますが、cli 引数を変更することは一切できません。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:542 -msgid "Play recap now counts ``ignored`` and ``rescued`` tasks as well as ``ok``, ``changed``, ``unreachable``, ``failed`` and ``skipped`` tasks, thanks to two additional stat counters in the ``default`` callback plugin. Tasks that fail and have ``ignore_errors: yes`` set are listed as ``ignored``. Tasks that fail and then execute a rescue section are listed as ``rescued``. Note that ``rescued`` tasks are no longer counted as ``failed`` as in Ansible 2.7 (and earlier)." -msgstr "プレイの要約では、``default`` callback プラグインの 2 つの追加スタットカウンターのおかげで、タスクは ``ignored`` と``rescued`` だけでなく、``ok``、``changed``、``unreachable``、``failed``、``skipped`` もカウントされるようになりました。失敗して``ignore_errors: yes`` が設定されたタスクは ``ignored`` としてリストアップされます。失敗してレスキューセクションを実行したタスクは、``rescued`` としてリストアップされます。なお、Ansible 2.7 (およびそれ以前) では、``rescued`` タスクは ``failed`` としてカウントされなくなりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:544 -msgid "``osx_say`` callback plugin was renamed into :ref:`say `." -msgstr "``osx_say`` callback プラグインの名前が :ref:`say ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:546 -msgid "Inventory plugins now support caching via cache plugins. To start using a cache plugin with your inventory see the section on caching in the :ref:`inventory guide`. To port a custom cache plugin to be compatible with inventory see :ref:`developer guide on cache plugins`." -msgstr "inventory プラグインが cache プラグインによるキャッシュ設定に対応しました。インベントリーで cache プラグインの使用を開始するには、「:ref:`インベントリーガイド`」のキャッシュ設定に関するセクションを参照してください。カスタム cache プラグインをインベントリーと互換性があるように移植するには、「:ref:`cache プラグインの開発者ガイド`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:552 -msgid "Display class" -msgstr "クラスの表示" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:554 -msgid "As of Ansible 2.8, the ``Display`` class is now a \"singleton\". Instead of using ``__main__.display`` each file should import and instantiate ``ansible.utils.display.Display`` on its own." -msgstr "Ansible 2.8では、``Display`` クラスが「シングルトン」になりました。各ファイルは、``__main__.display`` を使用する代わりに ``ansible.utils.display.Display`` をインポートして独自にインスタンス化する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:557 -msgid "**OLD** In Ansible 2.7 (and earlier) the following was used to access the ``display`` object:" -msgstr "Ansible 2.7 以前における **以前の機能** ``display`` オブジェクトへのアクセスには以下が使用されていました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:567 -msgid "**NEW** In Ansible 2.8 the following should be used:" -msgstr "**新機能** Ansible 2.8 では、以下を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:577 -msgid "The ``eos_config``, ``ios_config``, and ``nxos_config`` modules have removed the deprecated ``save`` and ``force`` parameters, use the ``save_when`` parameter to replicate their functionality." -msgstr "``eos_config`` モジュール、``ios_config`` モジュール、および ``nxos_config`` モジュールは非推奨の ``save`` パラメーターおよび ``force`` パラメーターを削除し、``save_when`` パラメーターを使用して機能を複製します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:581 -msgid "The ``nxos_vrf_af`` module has removed the ``safi`` parameter. This parameter was deprecated in Ansible 2.4 and has had no impact on the module since then." -msgstr "``nxos_vrf_af`` モジュールは ``safi`` パラメーターを削除しました。このパラメーターは Ansible 2.4 で非推奨となり、それ以降モジュールに影響を及ぼしませんでした。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:6 -msgid "Ansible 2.9 Porting Guide" -msgstr "Ansible 2.9 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:8 -msgid "This section discusses the behavioral changes between Ansible 2.8 and Ansible 2.9." -msgstr "このセクションでは、Ansible 2.8 と Ansible 2.9 での動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:12 -msgid "We suggest you read this page along with `Ansible Changelog for 2.9 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.9 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:25 -msgid "``hash_behaviour`` now affects inventory sources. If you have it set to ``merge``, the data you get from inventory might change and you will have to update playbooks accordingly. If you're using the default setting (``overwrite``), you will see no changes. Inventory was ignoring this setting." -msgstr "``hash_behaviour`` インベントリーソースに影響します。これを ``merge`` に設定した場合は、インベントリーから取得したデータが変更され、Playbook が適切に更新される必要があります。デフォルト設定 (``overwrite``) を使用している場合は、変更されません。インベントリーは、この設定を無視していました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:28 -msgid "Loops" -msgstr "ループ" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:30 -msgid "Ansible 2.9 handles \"unsafe\" data more robustly, ensuring that data marked \"unsafe\" is not templated. In previous versions, Ansible recursively marked all data returned by the direct use of ``lookup()`` as \"unsafe\", but only marked structured data returned by indirect lookups using ``with_X`` style loops as \"unsafe\" if the returned elements were strings. Ansible 2.9 treats these two approaches consistently." -msgstr "Ansible 2.9 では、「unsafe」とマークされたデータがテンプレート化されないように、「unsafe」データをより強固に処理します。以前のバージョンでは、Ansible は``lookup()`` を直接使用して返されたすべてのデータを再帰的に「unsafe」と表示していましたが、``with_X`` スタイルのループを使用して間接的にルックアップして返された構造化データは、返される要素が文字列の場合にのみ「unsafe」と表示していました。Ansible 2.9 では、この 2 つのアプローチを一貫して扱います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:32 -msgid "As a result, if you use ``with_dict`` to return keys with templatable values, your templates may no longer work as expected in Ansible 2.9." -msgstr "その結果、``with_dict`` を使用して、テンプレート化できる値とキーが返されると、テンプレートは Ansible 2.9 では想定どおりに動作しなくなる可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:34 -msgid "To allow the old behavior, switch from using ``with_X`` to using ``loop`` with a filter as described at :ref:`migrating_to_loop`." -msgstr "以前の動作を許可するには、「:ref:`migrating_to_loop`」で説明されているフィルターで使用する ``with_X`` を ``loop`` に切り替えてください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:39 -msgid "The location of the Galaxy token file has changed from ``~/.ansible_galaxy`` to ``~/.ansible/galaxy_token``. You can configure both path and file name with the :ref:`galaxy_token_path` config." -msgstr "Galaxy トークンファイルの場所が ``~/.ansible_galaxy`` から ``~/.ansible/galaxy_token`` に変更になりました。:ref:`galaxy_token_path` 設定で、パスとファイル名の両方を設定できます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:49 -msgid "Collection loader changes" -msgstr "コレクションローダーの変更" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:51 -msgid "The way to import a PowerShell or C# module util from a collection has changed in the Ansible 2.9 release. In Ansible 2.8 a util was imported with the following syntax:" -msgstr "Ansible 2.9 リリースでは、コレクションから PowerShell または C# モジュールユーティリティーをインポートする方法が変更されました。Ansible 2.8 では、以下の構文で ユーティリティーがインポートされました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:59 -msgid "In Ansible 2.9 this was changed to:" -msgstr "Ansible 2.9 では、上記は次のように変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:66 -msgid "The change in the collection import name also requires any C# util namespaces to be updated with the newer name format. This is more verbose but is designed to make sure we avoid plugin name conflicts across separate plugin types and to standardise how imports work in PowerShell with how Python modules work." -msgstr "また、コレクションのインポート名の変更に伴い、C# ユーティリティーの名前空間も新しい名前形式に更新する必要があります。新しい形式はより冗長になっていますが、他のプラグインタイプとの間でプラグイン名が競合しないようにするため、また PowerShell でのインポートの動作と Python モジュールの動作を標準化するためのものです。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:74 -msgid "The ``win_get_url`` and ``win_uri`` module now sends requests with a default ``User-Agent`` of ``ansible-httpget``. This can be changed by using the ``http_agent`` key." -msgstr "``win_get_url`` モジュールおよび ``win_uri`` モジュールは、``ansible-httpget`` のデフォルトの ``User-Agent`` で要求を送信するようになりました。これは ``http_agent`` キーを使用して変更できます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:75 -msgid "The ``apt`` module now honors ``update_cache=false`` while installing its own dependency and skips the cache update. Explicitly setting ``update_cache=true`` or omitting the param ``update_cache`` will result in a cache update while installing its own dependency." -msgstr "``apt`` モジュールは、自身の依存関係をインストールする際に ``update_cache=false`` を尊重し、キャッシュの更新をスキップするようになりました。``update_cache=true`` を明示的に設定するか、パラメーターの ``update_cache`` を省略すると、自身の依存関係をインストールしている間にキャッシュの更新が行われます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:77 -msgid "Version 2.9.12 of Ansible changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the mode change has been reverted in 2.9.13, and mode will now default to ``0o666 & ~umask`` as in previous versions of Ansible." -msgstr "Ansible のバージョン 2.9.12 は、ユーザーがファイルベースのタスクで ``mode`` パラメーターを指定しなかった場合に、ファイルベースのタスクのデフォルトモードを ``0o600 & ~umask`` に変更しました。これは、再編成した CVE レポートに対する対応でした。その結果、2.9.13 ではモードの変更が元に戻され、以前のバージョンの Ansible と同様に、モードのデフォルトが ``0o666 & ~umask`` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:78 -msgid "If you changed any tasks to specify less restrictive permissions while using 2.9.12, those changes will be unnecessary (but will do no harm) in 2.9.13." -msgstr "2.9.12 を使用する際に、より制限の少ないパーミッションを指定するようにタスクを変更した場合、2.9.13 ではその変更は不要になります (ただし、害はありません)。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:81 -msgid "``dnf`` and ``yum`` - As of version 2.9.13, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task." -msgstr "``dnf`` および ``yum`` - バージョン 2.9.13 より、``dnf`` モジュール (および ``dnf`` を使用する場合は ``yum`` アクション) がパッケージの GPG 署名を正しく検証するようになりました (CVE-2020-14365)。``Failed to validate GPG signature for [package name]`` のようなエラーが表示された場合は、使用している DNF リポジトリーやパッケージの GPG キーが正しくインポートされていることを確認してください。これを行う 1 つの方法として、``rpm_key`` モジュールの使用があります。推奨はしませんが、場合によっては GPG チェックを無効にする必要があるかもしれません。これは、``dnf`` タスクまたは ``yum`` タスクに ``disable_gpg_check: yes`` を明示的に追加することで実現できます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:85 -msgid "Renaming from ``_facts`` to ``_info``" -msgstr "``_facts`` から ``_info`` へ名前を変更します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:87 -msgid "Ansible 2.9 renamed a lot of modules from ``_facts`` to ``_info``, because the modules do not return :ref:`Ansible facts `. Ansible facts relate to a specific host. For example, the configuration of a network interface, the operating system on a unix server, and the list of packages installed on a Windows box are all Ansible facts. The renamed modules return values that are not unique to the host. For example, account information or region data for a cloud provider. Renaming these modules should provide more clarity about the types of return values each set of modules offers." -msgstr "Ansible 2.9 では、モジュールが :ref:`Ansible facts ` を返さないため、多くのモジュールの名前が ``_facts`` から``_info`` に変更なりました。Ansible のファクトは、特定のホストに関連するものです。たとえば、ネットワークインターフェースの設定、Unix サーバーのオペレーティングシステム、Windows ボックスにインストールされたパッケージのリストは、すべて Ansible のファクトです。名前が変更したモジュールは、ホストに固有ではない値を返します。クラウドプロバイダーのアカウント情報やリージョンデータなどです。これらのモジュールの名前を変更することで、モジュールの各セットが提供する戻り値の種類がより明確になるはずです。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:90 -msgid "Writing modules" -msgstr "モジュールの記述" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:92 -msgid "Module and module_utils files can now use relative imports to include other module_utils files. This is useful for shortening long import lines, especially in collections." -msgstr "モジュールおよび module_utils ファイルは、他の module_utils ファイルを含めるために相対インポートを使用できるようになりました。これは、特にコレクションにおいて、長いインポート行を短くするのに便利です。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:95 -msgid "Example of using a relative import in collections:" -msgstr "コレクションで相対インポートを使用する例:" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:105 -msgid "Modules and module_utils shipped with Ansible can use relative imports as well but the savings are smaller:" -msgstr "Ansible に同梱されているモジュールと module_utils では、相対インポートも使用できますが、短縮される量は少なくなります。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:116 -msgid "Each single dot (``.``) represents one level of the tree (equivalent to ``../`` in filesystem relative links)." -msgstr "単一ドット (``.``) はそれぞれツリーの 1 レベル (ファイルシステムの相対リンクの ``../`` に相当) を表します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:118 -msgid "`The Python Relative Import Docs `_ go into more detail of how to write relative imports." -msgstr "`Python Relative Import ドキュメント `_ では、相対的なインポートをどのように書くか、より詳細に説明します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:126 -msgid "Apstra's ``aos_*`` modules. See the new modules at `https://github.com/apstra `_." -msgstr "Apstra の ``aos_*`` モジュール。新しいモジュールは `https://github.com/apstra `_ にあります。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:127 -msgid "ec2_ami_find use :ref:`ec2_ami_facts ` instead." -msgstr "ec2_ami_find は、代わりに :ref:`ec2_ami_facts ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:128 -msgid "kubernetes use :ref:`k8s ` instead." -msgstr "kubernetes は、代わりに :ref:`k8s ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:129 -msgid "nxos_ip_interface use :ref:`nxos_l3_interface ` instead." -msgstr "nxos_ip_interface は、代わりに :ref:`nxos_l3_interface ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:130 -msgid "nxos_portchannel use :ref:`nxos_linkagg ` instead." -msgstr "nxos_portchannel は、代わりに :ref:`nxos_linkagg ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:131 -msgid "nxos_switchport use :ref:`nxos_l2_interface ` instead." -msgstr "nxos_switchport は、代わりに :ref:`nxos_l2_interface ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:132 -msgid "oc use :ref:`k8s ` instead." -msgstr "oc は、代わりに :ref:`k8s ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:133 -msgid "panos_nat_policy use :ref:`panos_nat_rule ` instead." -msgstr "panos_nat_policy は、代わりに :ref:`panos_nat_rule ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:134 -msgid "panos_security_policy use :ref:`panos_security_rule ` instead." -msgstr "panos_security_policy は、代わりに :ref:`panos_security_rule ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:135 -msgid "vsphere_guest use :ref:`vmware_guest ` instead." -msgstr "vsphere_guest は、代わりに :ref:`vmware_guest ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:141 -msgid "The following modules will be removed in Ansible 2.13. Please update update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.13 で削除されます。Playbook を適宜更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:143 -msgid "cs_instance_facts use :ref:`cs_instance_info ` instead." -msgstr "cs_instance_facts は、代わりに :ref:`cs_instance_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:145 -msgid "cs_zone_facts use :ref:`cs_zone_info ` instead." -msgstr "cs_zone_facts は、代わりに :ref:`cs_zone_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:147 -msgid "digital_ocean_sshkey_facts use :ref:`digital_ocean_sshkey_info ` instead." -msgstr "digital_ocean_sshkey_facts は、代わりに :ref:`digital_ocean_sshkey_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:149 -msgid "eos_interface use :ref:`eos_interfaces ` instead." -msgstr "edos_interface は、代わりに :ref:`eos_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:151 -msgid "eos_l2_interface use :ref:`eos_l2_interfaces ` instead." -msgstr "eos_l2_interface は、代わりに :ref:`eos_l2_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:153 -msgid "eos_l3_interface use :ref:`eos_l3_interfaces ` instead." -msgstr "eos_l3_interface は、代わりに :ref:`eos_l3_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:155 -msgid "eos_linkagg use :ref:`eos_lag_interfaces ` instead." -msgstr "ems_linkagg は、代わりに :ref:`eos_lag_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:157 -msgid "eos_lldp_interface use :ref:`eos_lldp_interfaces ` instead." -msgstr "eds_lldp_interface は、代わりに :ref:`eos_lldp_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:159 -msgid "eos_vlan use :ref:`eos_vlans ` instead." -msgstr "eos_vlan は、代わりに :ref:`eos_vlans ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:161 -msgid "ios_interface use :ref:`ios_interfaces ` instead." -msgstr "ios_interface は、代わりに :ref:`ios_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:163 -msgid "ios_l2_interface use :ref:`ios_l2_interfaces ` instead." -msgstr "ios_l2_interface は、代わりに :ref:`ios_l2_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:165 -msgid "ios_l3_interface use :ref:`ios_l3_interfaces ` instead." -msgstr "ios_l3_interface は、代わりに :ref:`ios_l3_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:167 -msgid "ios_vlan use :ref:`ios_vlans ` instead." -msgstr "ios_vlan は、代わりに :ref:`ios_vlans ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:169 -msgid "iosxr_interface use :ref:`iosxr_interfaces ` instead." -msgstr "iosxr_interface は、代わりに :ref:`iosxr_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:171 -msgid "junos_interface use :ref:`junos_interfaces ` instead." -msgstr "junos_interface は、代わりに :ref:`junos_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:173 -msgid "junos_l2_interface use :ref:`junos_l2_interfaces ` instead." -msgstr "junos_l2_interface は、代わりに :ref:`junos_l2_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:175 -msgid "junos_l3_interface use :ref:`junos_l3_interfaces ` instead." -msgstr "junos_l3_interface は、代わりに :ref:`junos_l3_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:177 -msgid "junos_linkagg use :ref:`junos_lag_interfaces ` instead." -msgstr "junos_linkagg は、代わりに :ref:`junos_lag_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:179 -msgid "junos_lldp use :ref:`junos_lldp_global ` instead." -msgstr "junos_lldp は、代わりに :ref:`junos_lldp_global ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:181 -msgid "junos_lldp_interface use :ref:`junos_lldp_interfaces ` instead." -msgstr "junos_lldp_interface は、代わりに :ref:`junos_lldp_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:183 -msgid "junos_vlan use :ref:`junos_vlans ` instead." -msgstr "junos_vlan は、代わりに :ref:`junos_vlans ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:185 -msgid "lambda_facts use :ref:`lambda_info ` instead." -msgstr "lambda_facts は、代わりに :ref:`lambda_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:187 -msgid "na_ontap_gather_facts use :ref:`na_ontap_info ` instead." -msgstr "na_ontap_gather_facts は、代わりに :ref:`na_ontap_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:189 -msgid "net_banner use the platform-specific [netos]_banner modules instead." -msgstr "net_banner は、代わりにプラットフォーム固有の [netos]_banner モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:191 -msgid "net_interface use the new platform-specific [netos]_interfaces modules instead." -msgstr "net_interface は、代わりにプラットフォーム固有の新しい [netos]_interfaces モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:193 -msgid "net_l2_interface use the new platform-specific [netos]_l2_interfaces modules instead." -msgstr "net_l2_interface は、代わりにプラットフォーム固有の新しい [netos]_l2_interfaces モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:195 -msgid "net_l3_interface use the new platform-specific [netos]_l3_interfaces modules instead." -msgstr "net_l3_interface は、代わりにプラットフォーム固有の新しい [netos]_l3_interfaces モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:197 -msgid "net_linkagg use the new platform-specific [netos]_lag modules instead." -msgstr "net_linkagg は、代わりにプラットフォーム固有の新しい [netos]_lag モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:199 -msgid "net_lldp use the new platform-specific [netos]_lldp_global modules instead." -msgstr "net_lldp は、代わりにプラットフォーム固有の新しい [netos]_lldp_global モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:201 -msgid "net_lldp_interface use the new platform-specific [netos]_lldp_interfaces modules instead." -msgstr "net_lldp_interface は、代わりにプラットフォーム固有の新しい [netos]_lldp_interfaces モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:203 -msgid "net_logging use the platform-specific [netos]_logging modules instead." -msgstr "net_logging は、代わりにプラットフォーム固有の [netos]_logging モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:205 -msgid "net_static_route use the platform-specific [netos]_static_route modules instead." -msgstr "net_static_route は、代わりにプラットフォーム固有の [netos]_static_route モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:207 -msgid "net_system use the platform-specific [netos]_system modules instead." -msgstr "net_system は、代わりにプラットフォーム固有の [netos]_system モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:209 -msgid "net_user use the platform-specific [netos]_user modules instead." -msgstr "net_user は、代わりにプラットフォーム固有の [netos]_user モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:211 -msgid "net_vlan use the new platform-specific [netos]_vlans modules instead." -msgstr "net_vlan は、代わりにプラットフォーム固有の新しい [netos]_vlans モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:213 -msgid "net_vrf use the platform-specific [netos]_vrf modules instead." -msgstr "net_vrf は、代わりにプラットフォーム固有の [netos]_vrf モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:215 -msgid "nginx_status_facts use :ref:`nginx_status_info ` instead." -msgstr "nginx_status_facts は、代わりに :ref:`nginx_status_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:217 -msgid "nxos_interface use :ref:`nxos_interfaces ` instead." -msgstr "nxos_interface は、代わりに :ref:`nxos_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:219 -msgid "nxos_l2_interface use :ref:`nxos_l2_interfaces ` instead." -msgstr "nxos_l2_interface は、代わりに :ref:`nxos_l2_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:221 -msgid "nxos_l3_interface use :ref:`nxos_l3_interfaces ` instead." -msgstr "nxos_l3_interface は、代わりに :ref:`nxos_l3_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:223 -msgid "nxos_linkagg use :ref:`nxos_lag_interfaces ` instead." -msgstr "nxos_linkagg は、代わりに :ref:`nxos_lag_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:225 -msgid "nxos_vlan use :ref:`nxos_vlans ` instead." -msgstr "nxos_vlan は、代わりに :ref:`nxos_vlans ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:227 -msgid "online_server_facts use :ref:`online_server_info ` instead." -msgstr "online_server_facts は、代わりに :ref:`online_server_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:229 -msgid "online_user_facts use :ref:`online_user_info ` instead." -msgstr "online_user_facts は、代わりに :ref:`online_user_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:231 -msgid "purefa_facts use :ref:`purefa_info ` instead." -msgstr "purefa_facts は、代わりに :ref:`purefa_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:233 -msgid "purefb_facts use :ref:`purefb_info ` instead." -msgstr "purefb_facts は、代わりに :ref:`purefb_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:235 -msgid "scaleway_image_facts use :ref:`scaleway_image_info ` instead." -msgstr "scaleway_image_facts は、代わりに :ref:`scaleway_image_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:237 -msgid "scaleway_ip_facts use :ref:`scaleway_ip_info ` instead." -msgstr "scaleway_ip_facts は、代わりに :ref:`scaleway_ip_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:239 -msgid "scaleway_organization_facts use :ref:`scaleway_organization_info ` instead." -msgstr "scaleway_organization_facts は、代わりに :ref:`scaleway_organization_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:241 -msgid "scaleway_security_group_facts use :ref:`scaleway_security_group_info ` instead." -msgstr "scaleway_security_group_facts は、代わりに :ref:`scaleway_security_group_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:243 -msgid "scaleway_server_facts use :ref:`scaleway_server_info ` instead." -msgstr "scaleway_server_facts は、代わりに :ref:`scaleway_server_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:245 -msgid "scaleway_snapshot_facts use :ref:`scaleway_snapshot_info ` instead." -msgstr "scaleway_snapshot_facts は、代わりに :ref:`scaleway_snapshot_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:247 -msgid "scaleway_volume_facts use :ref:`scaleway_volume_info ` instead." -msgstr "scaleway_volume_facts は、代わりに :ref:`scaleway_volume_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:249 -msgid "vcenter_extension_facts use :ref:`vcenter_extension_info ` instead." -msgstr "vcenter_extension_facts は、代わりに :ref:`vcenter_extension_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:251 -msgid "vmware_about_facts use :ref:`vmware_about_info ` instead." -msgstr "vmware_about_facts は、代わりに :ref:`vmware_about_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:253 -msgid "vmware_category_facts use :ref:`vmware_category_info ` instead." -msgstr "vmware_category_facts は、代わりに :ref:`vmware_category_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:255 -msgid "vmware_drs_group_facts use :ref:`vmware_drs_group_info ` instead." -msgstr "vmware_drs_group_facts は、代わりに :ref:`vmware_drs_group_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:257 -msgid "vmware_drs_rule_facts use :ref:`vmware_drs_rule_info ` instead." -msgstr "vmware_drs_rule_facts は、代わりに :ref:`vmware_drs_rule_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:259 -msgid "vmware_dvs_portgroup_facts use :ref:`vmware_dvs_portgroup_info ` instead." -msgstr "vmware_dvs_portgroup_facts は、代わりに :ref:`vmware_dvs_portgroup_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:261 -msgid "vmware_guest_boot_facts use :ref:`vmware_guest_boot_info ` instead." -msgstr "vmware_guest_boot_facts は、代わりに :ref:`vmware_guest_boot_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:263 -msgid "vmware_guest_customization_facts use :ref:`vmware_guest_customization_info ` instead." -msgstr "vmware_guest_customization_facts は、代わりに :ref:`vmware_guest_customization_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:265 -msgid "vmware_guest_disk_facts use :ref:`vmware_guest_disk_info ` instead." -msgstr "vmware_guest_disk_facts は、代わりに :ref:`vmware_guest_disk_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:267 -msgid "vmware_host_capability_facts use :ref:`vmware_host_capability_info ` instead." -msgstr "vmware_host_capability_facts は、代わりに :ref:`vmware_host_capability_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:269 -msgid "vmware_host_config_facts use :ref:`vmware_host_config_info ` instead." -msgstr "vmware_host_config_facts は、代わりに :ref:`vmware_host_config_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:271 -msgid "vmware_host_dns_facts use :ref:`vmware_host_dns_info ` instead." -msgstr "vmware_host_dns_facts は、代わりに :ref:`vmware_host_dns_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:273 -msgid "vmware_host_feature_facts use :ref:`vmware_host_feature_info ` instead." -msgstr "vmware_host_feature_facts は、代わりに :ref:`vmware_host_feature_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:275 -msgid "vmware_host_firewall_facts use :ref:`vmware_host_firewall_info ` instead." -msgstr "vmware_host_firewall_facts は、代わりに :ref:`vmware_host_firewall_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:277 -msgid "vmware_host_ntp_facts use :ref:`vmware_host_ntp_info ` instead." -msgstr "vmware_host_ntp_facts は、代わりに :ref:`vmware_host_ntp_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:279 -msgid "vmware_host_package_facts use :ref:`vmware_host_package_info ` instead." -msgstr "vmware_host_package_facts は、代わりに :ref:`vmware_host_package_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:281 -msgid "vmware_host_service_facts use :ref:`vmware_host_service_info ` instead." -msgstr "vmware_host_service_facts は、代わりに :ref:`vmware_host_service_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:283 -msgid "vmware_host_ssl_facts use :ref:`vmware_host_ssl_info ` instead." -msgstr "vmware_host_ssl_facts は、代わりに :ref:`vmware_host_ssl_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:285 -msgid "vmware_host_vmhba_facts use :ref:`vmware_host_vmhba_info ` instead." -msgstr "vmware_host_vmhba_facts は、代わりに :ref:`vmware_host_vmhba_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:287 -msgid "vmware_host_vmnic_facts use :ref:`vmware_host_vmnic_info ` instead." -msgstr "vmware_host_vmnic_facts は、代わりに :ref:`vmware_host_vmnic_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:289 -msgid "vmware_local_role_facts use :ref:`vmware_local_role_info ` instead." -msgstr "vmware_local_role_facts は、代わりに :ref:`vmware_local_role_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:291 -msgid "vmware_local_user_facts use :ref:`vmware_local_user_info ` instead." -msgstr "vmware_local_user_facts は、代わりに :ref:`vmware_local_user_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:293 -msgid "vmware_portgroup_facts use :ref:`vmware_portgroup_info ` instead." -msgstr "vmware_portgroup_facts は、代わりに :ref:`vmware_portgroup_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:295 -msgid "vmware_resource_pool_facts use :ref:`vmware_resource_pool_info ` instead." -msgstr "vmware_resource_pool_facts は、代わりに :ref:`vmware_resource_pool_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:297 -msgid "vmware_target_canonical_facts use :ref:`vmware_target_canonical_info ` instead." -msgstr "vmware_target_canonical_facts は、代わりに :ref:`vmware_target_canonical_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:299 -msgid "vmware_vmkernel_facts use :ref:`vmware_vmkernel_info ` instead." -msgstr "vmware_vmkernel_facts は、代わりに :ref:`vmware_vmkernel_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:301 -msgid "vmware_vswitch_facts use :ref:`vmware_vswitch_info ` instead." -msgstr "vmware_vswitch_facts は、代わりに :ref:`vmware_vswitch_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:303 -msgid "vultr_account_facts use :ref:`vultr_account_info ` instead." -msgstr "vultr_account_facts は、代わりに :ref:`vultr_account_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:305 -msgid "vultr_block_storage_facts use :ref:`vultr_block_storage_info ` instead." -msgstr "vultr_block_storage_facts は、代わりに :ref:`vultr_block_storage_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:307 -msgid "vultr_dns_domain_facts use :ref:`vultr_dns_domain_info ` instead." -msgstr "vultr_dns_domain_facts は、代わりに :ref:`vultr_dns_domain_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:309 -msgid "vultr_firewall_group_facts use :ref:`vultr_firewall_group_info ` instead." -msgstr "vultr_firewall_group_facts は、代わりに :ref:`vultr_firewall_group_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:311 -msgid "vultr_network_facts use :ref:`vultr_network_info ` instead." -msgstr "vultr_network_facts は、代わりに :ref:`vultr_network_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:313 -msgid "vultr_os_facts use :ref:`vultr_os_info ` instead." -msgstr "vultr_os_facts は、代わりに :ref:`vultr_os_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:315 -msgid "vultr_plan_facts use :ref:`vultr_plan_info ` instead." -msgstr "vultr_plan_facts は、代わりに :ref:`vultr_plan_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:317 -msgid "vultr_region_facts use :ref:`vultr_region_info ` instead." -msgstr "vultr_region_facts は、代わりに :ref:`vultr_region_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:319 -msgid "vultr_server_facts use :ref:`vultr_server_info ` instead." -msgstr "vultr_server_facts は、代わりに :ref:`vultr_server_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:321 -msgid "vultr_ssh_key_facts use :ref:`vultr_ssh_key_info ` instead." -msgstr "vultr_ssh_key_facts は、代わりに :ref:`vultr_ssh_key_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:323 -msgid "vultr_startup_script_facts use :ref:`vultr_startup_script_info ` instead." -msgstr "vultr_startup_script_facts は、代わりに :ref:`vultr_startup_script_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:325 -msgid "vultr_user_facts use :ref:`vultr_user_info ` instead." -msgstr "vultr_user_facts は、代わりに :ref:`vultr_user_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:327 -msgid "vyos_interface use :ref:`vyos_interfaces ` instead." -msgstr "vyos_interface は、代わりに :ref:`vyos_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:329 -msgid "vyos_l3_interface use :ref:`vyos_l3_interfaces ` instead." -msgstr "vyos_l3_interface は、代わりに :ref:`vyos_l3_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:331 -msgid "vyos_linkagg use :ref:`vyos_lag_interfaces ` instead." -msgstr "vyos_linkagg は、代わりに :ref:`vyos_lag_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:333 -msgid "vyos_lldp use :ref:`vyos_lldp_global ` instead." -msgstr "vyos_lldp は、代わりに :ref:`vyos_lldp_global ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:335 -msgid "vyos_lldp_interface use :ref:`vyos_lldp_interfaces ` instead." -msgstr "vyos_lldp_interface は、代わりに :ref:`vyos_lldp_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:338 -msgid "The following functionality will be removed in Ansible 2.12. Please update update your playbooks accordingly." -msgstr "以下の機能は Ansible 2.12 で削除されます。それに伴い、Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:340 -msgid "``vmware_cluster`` DRS, HA and VSAN configuration; use :ref:`vmware_cluster_drs `, :ref:`vmware_cluster_ha ` and :ref:`vmware_cluster_vsan ` instead." -msgstr "``vmware_cluster`` の DRS、HA、および VSAN の設定。代わりに :ref:`vmware_cluster_drs `、:ref:`vmware_cluster_ha `、および :ref:`vmware_cluster_vsan ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:343 -msgid "The following functionality will be removed in Ansible 2.13. Please update update your playbooks accordingly." -msgstr "以下の機能は Ansible 2.13 では削除されます。それに伴い、Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:345 -msgid "``openssl_certificate`` deprecates the ``assertonly`` provider. Please see the :ref:`openssl_certificate ` documentation examples on how to replace the provider with the :ref:`openssl_certificate_info `, :ref:`openssl_csr_info `, :ref:`openssl_privatekey_info ` and :ref:`assert ` modules." -msgstr "``openssl_certificate`` は、``assertonly`` プロバイダーを非推奨にします。プロバイダーを :ref:`openssl_certificate_info ` モジュール、:ref:`openssl_csr_info ` モジュール、:ref:`openssl_privatekey_info ` モジュール、および :ref:`assert ` モジュールに置き換える方法は、:ref:`openssl_certificate ` のドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:352 -msgid "For the following modules, the PyOpenSSL-based backend ``pyopenssl`` has been deprecated and will be removed in Ansible 2.13:" -msgstr "以下のモジュールについては、PyOpenSSL ベースのバックエンド ``pyopenssl`` がすでに非推奨になっており、Ansible 2.13 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:355 -msgid ":ref:`get_certificate `" -msgstr ":ref:`get_certificate `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:356 -msgid ":ref:`openssl_certificate `" -msgstr ":ref:`openssl_certificate `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:357 -msgid ":ref:`openssl_certificate_info `" -msgstr ":ref:`openssl_certificate_info `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:358 -msgid ":ref:`openssl_csr `" -msgstr ":ref:`openssl_csr `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:359 -msgid ":ref:`openssl_csr_info `" -msgstr ":ref:`openssl_csr_info `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:360 -msgid ":ref:`openssl_privatekey `" -msgstr ":ref:`openssl_privatekey `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:361 -msgid ":ref:`openssl_privatekey_info `" -msgstr ":ref:`openssl_privatekey_info `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:362 -msgid ":ref:`openssl_publickey `" -msgstr ":ref:`openssl_publickey `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:366 -msgid "Renamed modules" -msgstr "名前が変更になったモジュール" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:368 -msgid "The following modules have been renamed. The old name is deprecated and will be removed in Ansible 2.13. Please update update your playbooks accordingly." -msgstr "以下のモジュールの名称が変更になりました。古い名前は非推奨で、Ansible 2.13 で削除される予定です。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:371 -msgid "The ``ali_instance_facts`` module was renamed to :ref:`ali_instance_info `." -msgstr "``ali_instance_facts`` モジュールの名前が :ref:`ali_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:372 -msgid "The ``aws_acm_facts`` module was renamed to :ref:`aws_acm_info `." -msgstr "``aws_acm_facts`` モジュールの名前が :ref:`aws_acm_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:373 -msgid "The ``aws_az_facts`` module was renamed to :ref:`aws_az_info `." -msgstr "``aws_az_facts`` モジュールの名前が :ref:`aws_az_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:374 -msgid "The ``aws_caller_facts`` module was renamed to :ref:`aws_caller_info `." -msgstr "``aws_caller_facts`` モジュールの名前が :ref:`aws_caller_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:375 -msgid "The ``aws_kms_facts`` module was renamed to :ref:`aws_kms_info `." -msgstr "``aws_kms_facts`` モジュールの名前が :ref:`aws_kms_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:376 -msgid "The ``aws_region_facts`` module was renamed to :ref:`aws_region_info `." -msgstr "``aws_region_facts`` モジュールの名前が :ref:`aws_region_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:377 -msgid "The ``aws_s3_bucket_facts`` module was renamed to :ref:`aws_s3_bucket_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``aws_s3_bucket_facts`` モジュールの名前が :ref:`aws_s3_bucket_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:380 -msgid "The ``aws_sgw_facts`` module was renamed to :ref:`aws_sgw_info `." -msgstr "``aws_sgw_facts`` モジュールの名前が :ref:`aws_sgw_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:381 -msgid "The ``aws_waf_facts`` module was renamed to :ref:`aws_waf_info `." -msgstr "``aws_waf_facts`` モジュールの名前が :ref:`aws_waf_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:382 -msgid "The ``azure_rm_aks_facts`` module was renamed to :ref:`azure_rm_aks_info `." -msgstr "``azure_rm_aks_facts`` モジュールの名前が :ref:`azure_rm_aks_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:383 -msgid "The ``azure_rm_aksversion_facts`` module was renamed to :ref:`azure_rm_aksversion_info `." -msgstr "``azure_rm_aksversion_facts`` モジュールの名前が :ref:`azure_rm_aksversion_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:384 -msgid "The ``azure_rm_applicationsecuritygroup_facts`` module was renamed to :ref:`azure_rm_applicationsecuritygroup_info `." -msgstr "``azure_rm_applicationsecuritygroup_facts`` モジュールの名前が :ref:`azure_rm_applicationsecuritygroup_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:385 -msgid "The ``azure_rm_appserviceplan_facts`` module was renamed to :ref:`azure_rm_appserviceplan_info `." -msgstr "``azure_rm_appserviceplan_facts`` モジュールの名前が :ref:`azure_rm_appserviceplan_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:386 -msgid "The ``azure_rm_automationaccount_facts`` module was renamed to :ref:`azure_rm_automationaccount_info `." -msgstr "``azure_rm_automationaccount_facts`` モジュールの名前が :ref:`azure_rm_automationaccount_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:387 -msgid "The ``azure_rm_autoscale_facts`` module was renamed to :ref:`azure_rm_autoscale_info `." -msgstr "``azure_rm_autoscale_facts`` モジュールの名前が :ref:`azure_rm_autoscale_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:388 -msgid "The ``azure_rm_availabilityset_facts`` module was renamed to :ref:`azure_rm_availabilityset_info `." -msgstr "``azure_rm_availabilityset_facts`` モジュールの名前が :ref:`azure_rm_availabilityset_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:389 -msgid "The ``azure_rm_cdnendpoint_facts`` module was renamed to :ref:`azure_rm_cdnendpoint_info `." -msgstr "``azure_rm_cdnendpoint_facts`` モジュールの名前が :ref:`azure_rm_cdnendpoint_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:390 -msgid "The ``azure_rm_cdnprofile_facts`` module was renamed to :ref:`azure_rm_cdnprofile_info `." -msgstr "``azure_rm_cdnprofile_facts`` モジュールの名前が :ref:`azure_rm_cdnprofile_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:391 -msgid "The ``azure_rm_containerinstance_facts`` module was renamed to :ref:`azure_rm_containerinstance_info `." -msgstr "``azure_rm_containerinstance_facts`` モジュールの名前が :ref:`azure_rm_containerinstance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:392 -msgid "The ``azure_rm_containerregistry_facts`` module was renamed to :ref:`azure_rm_containerregistry_info `." -msgstr "``azure_rm_containerregistry_facts`` モジュールの名前が :ref:`azure_rm_containerregistry_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:393 -msgid "The ``azure_rm_cosmosdbaccount_facts`` module was renamed to :ref:`azure_rm_cosmosdbaccount_info `." -msgstr "``azure_rm_cosmosdbaccount_facts`` モジュールの名前が :ref:`azure_rm_cosmosdbaccount_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:394 -msgid "The ``azure_rm_deployment_facts`` module was renamed to :ref:`azure_rm_deployment_info `." -msgstr "``azure_rm_deployment_facts`` モジュールの名前が :ref:`azure_rm_deployment_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:395 -msgid "The ``azure_rm_resourcegroup_facts`` module was renamed to :ref:`azure_rm_resourcegroup_info `." -msgstr "``azure_rm_resourcegroup_facts`` モジュールの名前が :ref:`azure_rm_resourcegroup_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:396 -msgid "The ``bigip_device_facts`` module was renamed to :ref:`bigip_device_info `." -msgstr "``bigip_device_facts`` モジュールの名前が :ref:`bigip_device_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:397 -msgid "The ``bigiq_device_facts`` module was renamed to :ref:`bigiq_device_info `." -msgstr "``bigiq_device_facts`` モジュールの名前が :ref:`bigiq_device_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:398 -msgid "The ``cloudformation_facts`` module was renamed to :ref:`cloudformation_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``cloudformation_facts`` モジュールの名前が :ref:`cloudformation_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:401 -msgid "The ``cloudfront_facts`` module was renamed to :ref:`cloudfront_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``cloudfront_facts`` モジュールの名前が :ref:`cloudfront_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:404 -msgid "The ``cloudwatchlogs_log_group_facts`` module was renamed to :ref:`cloudwatchlogs_log_group_info `." -msgstr "``cloudwatchlogs_log_group_facts`` モジュールの名前が :ref:`cloudwatchlogs_log_group_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:405 -msgid "The ``digital_ocean_account_facts`` module was renamed to :ref:`digital_ocean_account_info `." -msgstr "``digital_ocean_account_facts`` モジュールの名前が :ref:`digital_ocean_account_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:406 -msgid "The ``digital_ocean_certificate_facts`` module was renamed to :ref:`digital_ocean_certificate_info `." -msgstr "``digital_ocean_certificate_facts`` モジュールの名前が :ref:`digital_ocean_certificate_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:407 -msgid "The ``digital_ocean_domain_facts`` module was renamed to :ref:`digital_ocean_domain_info `." -msgstr "``digital_ocean_domain_facts`` モジュールの名前が :ref:`digital_ocean_domain_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:408 -msgid "The ``digital_ocean_firewall_facts`` module was renamed to :ref:`digital_ocean_firewall_info `." -msgstr "``digital_ocean_firewall_facts`` モジュールの名前が :ref:`digital_ocean_firewall_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:409 -msgid "The ``digital_ocean_floating_ip_facts`` module was renamed to :ref:`digital_ocean_floating_ip_info `." -msgstr "``digital_ocean_floating_ip_facts`` モジュールの名前が :ref:`digital_ocean_floating_ip_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:410 -msgid "The ``digital_ocean_image_facts`` module was renamed to :ref:`digital_ocean_image_info `." -msgstr "``digital_ocean_image_facts`` モジュールの名前が :ref:`digital_ocean_image_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:411 -msgid "The ``digital_ocean_load_balancer_facts`` module was renamed to :ref:`digital_ocean_load_balancer_info `." -msgstr "``digital_ocean_load_balancer_facts`` モジュールの名前が :ref:`digital_ocean_load_balancer_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:412 -msgid "The ``digital_ocean_region_facts`` module was renamed to :ref:`digital_ocean_region_info `." -msgstr "``digital_ocean_region_facts`` モジュールの名前が :ref:`digital_ocean_region_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:413 -msgid "The ``digital_ocean_size_facts`` module was renamed to :ref:`digital_ocean_size_info `." -msgstr "``digital_ocean_size_facts`` モジュールの名前が :ref:`digital_ocean_size_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:414 -msgid "The ``digital_ocean_snapshot_facts`` module was renamed to :ref:`digital_ocean_snapshot_info `." -msgstr "``digital_ocean_snapshot_facts`` モジュールの名前が :ref:`digital_ocean_snapshot_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:415 -msgid "The ``digital_ocean_tag_facts`` module was renamed to :ref:`digital_ocean_tag_info `." -msgstr "``digital_ocean_tag_facts`` モジュールの名前が :ref:`digital_ocean_tag_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:416 -msgid "The ``digital_ocean_volume_facts`` module was renamed to :ref:`digital_ocean_volume_info `." -msgstr "``digital_ocean_volume_facts`` モジュールの名前が :ref:`digital_ocean_volume_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:417 -msgid "The ``ec2_ami_facts`` module was renamed to :ref:`ec2_ami_info `." -msgstr "``ec2_ami_facts`` モジュールの名前が :ref:`ec2_ami_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:418 -msgid "The ``ec2_asg_facts`` module was renamed to :ref:`ec2_asg_info `." -msgstr "``ec2_asg_facts`` モジュールの名前が :ref:`ec2_asg_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:419 -msgid "The ``ec2_customer_gateway_facts`` module was renamed to :ref:`ec2_customer_gateway_info `." -msgstr "``ec2_customer_gateway_facts`` モジュールの名前が :ref:`ec2_customer_gateway_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:420 -msgid "The ``ec2_eip_facts`` module was renamed to :ref:`ec2_eip_info `." -msgstr "``ec2_eip_facts`` モジュールの名前が :ref:`ec2_eip_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:421 -msgid "The ``ec2_elb_facts`` module was renamed to :ref:`ec2_elb_info `." -msgstr "``ec2_elb_facts`` モジュールの名前が :ref:`ec2_elb_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:422 -msgid "The ``ec2_eni_facts`` module was renamed to :ref:`ec2_eni_info `." -msgstr "``ec2_eni_facts`` モジュールの名前が :ref:`ec2_eni_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:423 -msgid "The ``ec2_group_facts`` module was renamed to :ref:`ec2_group_info `." -msgstr "``ec2_group_facts`` モジュールの名前が :ref:`ec2_group_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:424 -msgid "The ``ec2_instance_facts`` module was renamed to :ref:`ec2_instance_info `." -msgstr "``ec2_instance_facts`` モジュールの名前が :ref:`ec2_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:425 -msgid "The ``ec2_lc_facts`` module was renamed to :ref:`ec2_lc_info `." -msgstr "``ec2_lc_facts`` モジュールの名前が :ref:`ec2_lc_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:426 -msgid "The ``ec2_placement_group_facts`` module was renamed to :ref:`ec2_placement_group_info `." -msgstr "``ec2_placement_group_facts`` モジュールの名前が :ref:`ec2_placement_group_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:427 -msgid "The ``ec2_snapshot_facts`` module was renamed to :ref:`ec2_snapshot_info `." -msgstr "``ec2_snapshot_facts`` モジュールの名前が :ref:`ec2_snapshot_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:428 -msgid "The ``ec2_vol_facts`` module was renamed to :ref:`ec2_vol_info `." -msgstr "``ec2_vol_facts`` モジュールの名前が :ref:`ec2_vol_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:429 -msgid "The ``ec2_vpc_dhcp_option_facts`` module was renamed to :ref:`ec2_vpc_dhcp_option_info `." -msgstr "``ec2_vpc_dhcp_option_facts`` モジュールの名前が :ref:`ec2_vpc_dhcp_option_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:430 -msgid "The ``ec2_vpc_endpoint_facts`` module was renamed to :ref:`ec2_vpc_endpoint_info `." -msgstr "``ec2_vpc_endpoint_facts`` モジュールの名前が :ref:`ec2_vpc_endpoint_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:431 -msgid "The ``ec2_vpc_igw_facts`` module was renamed to :ref:`ec2_vpc_igw_info `." -msgstr "``ec2_vpc_igw_facts`` モジュールの名前が :ref:`ec2_vpc_igw_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:432 -msgid "The ``ec2_vpc_nacl_facts`` module was renamed to :ref:`ec2_vpc_nacl_info `." -msgstr "``ec2_vpc_nacl_facts`` モジュールの名前が :ref:`ec2_vpc_nacl_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:433 -msgid "The ``ec2_vpc_nat_gateway_facts`` module was renamed to :ref:`ec2_vpc_nat_gateway_info `." -msgstr "``ec2_vpc_nat_gateway_facts`` モジュールの名前が :ref:`ec2_vpc_nat_gateway_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:434 -msgid "The ``ec2_vpc_net_facts`` module was renamed to :ref:`ec2_vpc_net_info `." -msgstr "``ec2_vpc_net_facts`` モジュールの名前が :ref:`ec2_vpc_net_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:435 -msgid "The ``ec2_vpc_peering_facts`` module was renamed to :ref:`ec2_vpc_peering_info `." -msgstr "``ec2_vpc_peering_facts`` モジュールの名前が :ref:`ec2_vpc_peering_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:436 -msgid "The ``ec2_vpc_route_table_facts`` module was renamed to :ref:`ec2_vpc_route_table_info `." -msgstr "``ec2_vpc_route_table_facts`` モジュールの名前が :ref:`ec2_vpc_route_table_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:437 -msgid "The ``ec2_vpc_subnet_facts`` module was renamed to :ref:`ec2_vpc_subnet_info `." -msgstr "``ec2_vpc_subnet_facts`` モジュールの名前が :ref:`ec2_vpc_subnet_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:438 -msgid "The ``ec2_vpc_vgw_facts`` module was renamed to :ref:`ec2_vpc_vgw_info `." -msgstr "``ec2_vpc_vgw_facts`` モジュールの名前が :ref:`ec2_vpc_vgw_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:439 -msgid "The ``ec2_vpc_vpn_facts`` module was renamed to :ref:`ec2_vpc_vpn_info `." -msgstr "``ec2_vpc_vpn_facts`` モジュールの名前が :ref:`ec2_vpc_vpn_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:440 -msgid "The ``ecs_service_facts`` module was renamed to :ref:`ecs_service_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ecs_service_facts`` モジュールの名前が :ref:`ecs_service_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:443 -msgid "The ``ecs_taskdefinition_facts`` module was renamed to :ref:`ecs_taskdefinition_info `." -msgstr "``ecs_taskdefinition_facts`` モジュールの名前が :ref:`ecs_taskdefinition_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:444 -msgid "The ``efs_facts`` module was renamed to :ref:`efs_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``efs_facts`` モジュールの名前が :ref:`efs_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:447 -msgid "The ``elasticache_facts`` module was renamed to :ref:`elasticache_info `." -msgstr "``elasticache_facts`` モジュールの名前が :ref:`elasticache_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:448 -msgid "The ``elb_application_lb_facts`` module was renamed to :ref:`elb_application_lb_info `." -msgstr "``elb_application_lb_facts`` モジュールの名前が :ref:`elb_application_lb_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:449 -msgid "The ``elb_classic_lb_facts`` module was renamed to :ref:`elb_classic_lb_info `." -msgstr "``elb_classic_lb_facts`` モジュールの名前が :ref:`elb_classic_lb_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:450 -msgid "The ``elb_target_facts`` module was renamed to :ref:`elb_target_info `." -msgstr "``elb_target_facts`` モジュールの名前が :ref:`elb_target_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:451 -msgid "The ``elb_target_group_facts`` module was renamed to :ref:`elb_target_group_info `." -msgstr "``elb_target_group_facts`` モジュールの名前が :ref:`elb_target_group_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:452 -msgid "The ``gcp_bigquery_dataset_facts`` module was renamed to :ref:`gcp_bigquery_dataset_info `." -msgstr "``gcp_bigquery_dataset_facts`` モジュールの名前が :ref:`gcp_bigquery_dataset_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:453 -msgid "The ``gcp_bigquery_table_facts`` module was renamed to :ref:`gcp_bigquery_table_info `." -msgstr "``gcp_bigquery_table_facts`` モジュールの名前が :ref:`gcp_bigquery_table_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:454 -msgid "The ``gcp_cloudbuild_trigger_facts`` module was renamed to :ref:`gcp_cloudbuild_trigger_info `." -msgstr "``gcp_cloudbuild_trigger_facts`` モジュールの名前が :ref:`gcp_cloudbuild_trigger_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:455 -msgid "The ``gcp_compute_address_facts`` module was renamed to :ref:`gcp_compute_address_info `." -msgstr "``gcp_compute_address_facts`` モジュールの名前が :ref:`gcp_compute_address_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:456 -msgid "The ``gcp_compute_backend_bucket_facts`` module was renamed to :ref:`gcp_compute_backend_bucket_info `." -msgstr "``gcp_compute_backend_bucket_facts`` モジュールの名前が :ref:`gcp_compute_backend_bucket_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:457 -msgid "The ``gcp_compute_backend_service_facts`` module was renamed to :ref:`gcp_compute_backend_service_info `." -msgstr "``gcp_compute_backend_service_facts`` モジュールの名前が :ref:`gcp_compute_backend_service_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:458 -msgid "The ``gcp_compute_disk_facts`` module was renamed to :ref:`gcp_compute_disk_info `." -msgstr "``gcp_compute_disk_facts`` モジュールの名前が :ref:`gcp_compute_disk_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:459 -msgid "The ``gcp_compute_firewall_facts`` module was renamed to :ref:`gcp_compute_firewall_info `." -msgstr "``gcp_compute_firewall_facts`` モジュールの名前が :ref:`gcp_compute_firewall_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:460 -msgid "The ``gcp_compute_forwarding_rule_facts`` module was renamed to :ref:`gcp_compute_forwarding_rule_info `." -msgstr "``gcp_compute_forwarding_rule_facts`` モジュールの名前が :ref:`gcp_compute_forwarding_rule_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:461 -msgid "The ``gcp_compute_global_address_facts`` module was renamed to :ref:`gcp_compute_global_address_info `." -msgstr "``gcp_compute_global_address_facts`` モジュールの名前が :ref:`gcp_compute_global_address_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:462 -msgid "The ``gcp_compute_global_forwarding_rule_facts`` module was renamed to :ref:`gcp_compute_global_forwarding_rule_info `." -msgstr "``gcp_compute_global_forwarding_rule_facts`` モジュールの名前が :ref:`gcp_compute_global_forwarding_rule_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:463 -msgid "The ``gcp_compute_health_check_facts`` module was renamed to :ref:`gcp_compute_health_check_info `." -msgstr "``gcp_compute_health_check_facts`` モジュールの名前が :ref:`gcp_compute_health_check_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:464 -msgid "The ``gcp_compute_http_health_check_facts`` module was renamed to :ref:`gcp_compute_http_health_check_info `." -msgstr "``gcp_compute_http_health_check_facts`` モジュールの名前が :ref:`gcp_compute_http_health_check_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:465 -msgid "The ``gcp_compute_https_health_check_facts`` module was renamed to :ref:`gcp_compute_https_health_check_info `." -msgstr "``gcp_compute_https_health_check_facts`` モジュールの名前が :ref:`gcp_compute_https_health_check_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:466 -msgid "The ``gcp_compute_image_facts`` module was renamed to :ref:`gcp_compute_image_info `." -msgstr "``gcp_compute_image_facts`` モジュールの名前が :ref:`gcp_compute_image_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:467 -msgid "The ``gcp_compute_instance_facts`` module was renamed to :ref:`gcp_compute_instance_info `." -msgstr "``gcp_compute_instance_facts`` モジュールの名前が :ref:`gcp_compute_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:468 -msgid "The ``gcp_compute_instance_group_facts`` module was renamed to :ref:`gcp_compute_instance_group_info `." -msgstr "``gcp_compute_instance_group_facts`` モジュールの名前が :ref:`gcp_compute_instance_group_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:469 -msgid "The ``gcp_compute_instance_group_manager_facts`` module was renamed to :ref:`gcp_compute_instance_group_manager_info `." -msgstr "``gcp_compute_instance_group_manager_facts`` モジュールの名前が :ref:`gcp_compute_instance_group_manager_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:470 -msgid "The ``gcp_compute_instance_template_facts`` module was renamed to :ref:`gcp_compute_instance_template_info `." -msgstr "``gcp_compute_instance_template_facts`` モジュールの名前が :ref:`gcp_compute_instance_template_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:471 -msgid "The ``gcp_compute_interconnect_attachment_facts`` module was renamed to :ref:`gcp_compute_interconnect_attachment_info `." -msgstr "``gcp_compute_interconnect_attachment_facts`` モジュールの名前が :ref:`gcp_compute_interconnect_attachment_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:472 -msgid "The ``gcp_compute_network_facts`` module was renamed to :ref:`gcp_compute_network_info `." -msgstr "``gcp_compute_network_facts`` モジュールの名前が :ref:`gcp_compute_network_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:473 -msgid "The ``gcp_compute_region_disk_facts`` module was renamed to :ref:`gcp_compute_region_disk_info `." -msgstr "``gcp_compute_region_disk_facts`` モジュールの名前が :ref:`gcp_compute_region_disk_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:474 -msgid "The ``gcp_compute_route_facts`` module was renamed to :ref:`gcp_compute_route_info `." -msgstr "``gcp_compute_route_facts`` モジュールの名前が :ref:`gcp_compute_route_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:475 -msgid "The ``gcp_compute_router_facts`` module was renamed to :ref:`gcp_compute_router_info `." -msgstr "``gcp_compute_router_facts`` モジュールの名前が :ref:`gcp_compute_router_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:476 -msgid "The ``gcp_compute_ssl_certificate_facts`` module was renamed to :ref:`gcp_compute_ssl_certificate_info `." -msgstr "``gcp_compute_ssl_certificate_facts`` モジュールの名前が :ref:`gcp_compute_ssl_certificate_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:477 -msgid "The ``gcp_compute_ssl_policy_facts`` module was renamed to :ref:`gcp_compute_ssl_policy_info `." -msgstr "``gcp_compute_ssl_policy_facts`` モジュールの名前が :ref:`gcp_compute_ssl_policy_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:478 -msgid "The ``gcp_compute_subnetwork_facts`` module was renamed to :ref:`gcp_compute_subnetwork_info `." -msgstr "``gcp_compute_subnetwork_facts`` モジュールの名前が :ref:`gcp_compute_subnetwork_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:479 -msgid "The ``gcp_compute_target_http_proxy_facts`` module was renamed to :ref:`gcp_compute_target_http_proxy_info `." -msgstr "``gcp_compute_target_http_proxy_facts`` モジュールの名前が :ref:`gcp_compute_target_http_proxy_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:480 -msgid "The ``gcp_compute_target_https_proxy_facts`` module was renamed to :ref:`gcp_compute_target_https_proxy_info `." -msgstr "``gcp_compute_target_https_proxy_facts`` モジュールの名前が :ref:`gcp_compute_target_https_proxy_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:481 -msgid "The ``gcp_compute_target_pool_facts`` module was renamed to :ref:`gcp_compute_target_pool_info `." -msgstr "``gcp_compute_target_pool_facts`` モジュールの名前が :ref:`gcp_compute_target_pool_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:482 -msgid "The ``gcp_compute_target_ssl_proxy_facts`` module was renamed to :ref:`gcp_compute_target_ssl_proxy_info `." -msgstr "``gcp_compute_target_ssl_proxy_facts`` モジュールの名前が :ref:`gcp_compute_target_ssl_proxy_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:483 -msgid "The ``gcp_compute_target_tcp_proxy_facts`` module was renamed to :ref:`gcp_compute_target_tcp_proxy_info `." -msgstr "``gcp_compute_target_tcp_proxy_facts`` モジュールの名前が :ref:`gcp_compute_target_tcp_proxy_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:484 -msgid "The ``gcp_compute_target_vpn_gateway_facts`` module was renamed to :ref:`gcp_compute_target_vpn_gateway_info `." -msgstr "``gcp_compute_target_vpn_gateway_facts`` モジュールの名前が :ref:`gcp_compute_target_vpn_gateway_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:485 -msgid "The ``gcp_compute_url_map_facts`` module was renamed to :ref:`gcp_compute_url_map_info `." -msgstr "``gcp_compute_url_map_facts`` モジュールの名前が :ref:`gcp_compute_url_map_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:486 -msgid "The ``gcp_compute_vpn_tunnel_facts`` module was renamed to :ref:`gcp_compute_vpn_tunnel_info `." -msgstr "``gcp_compute_vpn_tunnel_facts`` モジュールの名前が :ref:`gcp_compute_vpn_tunnel_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:487 -msgid "The ``gcp_container_cluster_facts`` module was renamed to :ref:`gcp_container_cluster_info `." -msgstr "``gcp_container_cluster_facts`` モジュールの名前が :ref:`gcp_container_cluster_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:488 -msgid "The ``gcp_container_node_pool_facts`` module was renamed to :ref:`gcp_container_node_pool_info `." -msgstr "``gcp_container_node_pool_facts`` モジュールの名前が :ref:`gcp_container_node_pool_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:489 -msgid "The ``gcp_dns_managed_zone_facts`` module was renamed to :ref:`gcp_dns_managed_zone_info `." -msgstr "``gcp_dns_managed_zone_facts`` モジュールの名前が :ref:`gcp_dns_managed_zone_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:490 -msgid "The ``gcp_dns_resource_record_set_facts`` module was renamed to :ref:`gcp_dns_resource_record_set_info `." -msgstr "``gcp_dns_resource_record_set_facts`` モジュールの名前が :ref:`gcp_dns_resource_record_set_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:491 -msgid "The ``gcp_iam_role_facts`` module was renamed to :ref:`gcp_iam_role_info `." -msgstr "``gcp_iam_role_facts`` モジュールの名前が :ref:`gcp_iam_role_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:492 -msgid "The ``gcp_iam_service_account_facts`` module was renamed to :ref:`gcp_iam_service_account_info `." -msgstr "``gcp_iam_service_account_facts`` モジュールの名前が :ref:`gcp_iam_service_account_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:493 -msgid "The ``gcp_pubsub_subscription_facts`` module was renamed to :ref:`gcp_pubsub_subscription_info `." -msgstr "``gcp_pubsub_subscription_facts`` モジュールの名前が :ref:`gcp_pubsub_subscription_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:494 -msgid "The ``gcp_pubsub_topic_facts`` module was renamed to :ref:`gcp_pubsub_topic_info `." -msgstr "``gcp_pubsub_topic_facts`` モジュールの名前が :ref:`gcp_pubsub_topic_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:495 -msgid "The ``gcp_redis_instance_facts`` module was renamed to :ref:`gcp_redis_instance_info `." -msgstr "``gcp_redis_instance_facts`` モジュールの名前が :ref:`gcp_redis_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:496 -msgid "The ``gcp_resourcemanager_project_facts`` module was renamed to :ref:`gcp_resourcemanager_project_info `." -msgstr "``gcp_resourcemanager_project_facts`` モジュールの名前が :ref:`gcp_resourcemanager_project_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:497 -msgid "The ``gcp_sourcerepo_repository_facts`` module was renamed to :ref:`gcp_sourcerepo_repository_info `." -msgstr "``gcp_sourcerepo_repository_facts`` モジュールの名前が :ref:`gcp_sourcerepo_repository_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:498 -msgid "The ``gcp_spanner_database_facts`` module was renamed to :ref:`gcp_spanner_database_info `." -msgstr "``gcp_spanner_database_facts`` モジュールの名前が :ref:`gcp_spanner_database_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:499 -msgid "The ``gcp_spanner_instance_facts`` module was renamed to :ref:`gcp_spanner_instance_info `." -msgstr "``gcp_spanner_instance_facts`` モジュールの名前が :ref:`gcp_spanner_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:500 -msgid "The ``gcp_sql_database_facts`` module was renamed to :ref:`gcp_sql_database_info `." -msgstr "``gcp_sql_database_facts`` モジュールの名前が :ref:`gcp_sql_database_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:501 -msgid "The ``gcp_sql_instance_facts`` module was renamed to :ref:`gcp_sql_instance_info `." -msgstr "``gcp_sql_instance_facts`` モジュールの名前が :ref:`gcp_sql_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:502 -msgid "The ``gcp_sql_user_facts`` module was renamed to :ref:`gcp_sql_user_info `." -msgstr "``gcp_sql_user_facts`` モジュールの名前が :ref:`gcp_sql_user_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:503 -msgid "The ``gcp_tpu_node_facts`` module was renamed to :ref:`gcp_tpu_node_info `." -msgstr "``gcp_tpu_node_facts`` モジュールの名前が :ref:`gcp_tpu_node_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:504 -msgid "The ``gcpubsub_facts`` module was renamed to :ref:`gcpubsub_info `." -msgstr "``gcpubsub_facts`` モジュールの名前が :ref:`gcpubsub_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:505 -msgid "The ``github_webhook_facts`` module was renamed to :ref:`github_webhook_info `." -msgstr "``github_webhook_facts`` モジュールの名前が :ref:`github_webhook_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:506 -msgid "The ``gluster_heal_facts`` module was renamed to :ref:`gluster_heal_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``gluster_heal_facts`` モジュールの名前が :ref:`gluster_heal_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:509 -msgid "The ``hcloud_datacenter_facts`` module was renamed to :ref:`hcloud_datacenter_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_datacenter_facts`` モジュールの名前が :ref:`hcloud_datacenter_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:512 -msgid "The ``hcloud_floating_ip_facts`` module was renamed to :ref:`hcloud_floating_ip_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_floating_ip_facts`` モジュールの名前が :ref:`hcloud_floating_ip_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:515 -msgid "The ``hcloud_image_facts`` module was renamed to :ref:`hcloud_image_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_image_facts`` モジュールの名前が :ref:`hcloud_image_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:518 -msgid "The ``hcloud_location_facts`` module was renamed to :ref:`hcloud_location_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_location_facts`` モジュールの名前が :ref:`hcloud_location_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:521 -msgid "The ``hcloud_server_facts`` module was renamed to :ref:`hcloud_server_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_server_facts`` モジュールの名前が :ref:`hcloud_server_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:524 -msgid "The ``hcloud_server_type_facts`` module was renamed to :ref:`hcloud_server_type_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_server_type_facts`` モジュールの名前が :ref:`hcloud_server_type_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:527 -msgid "The ``hcloud_ssh_key_facts`` module was renamed to :ref:`hcloud_ssh_key_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_ssh_key_facts`` モジュールの名前が :ref:`hcloud_ssh_key_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:530 -msgid "The ``hcloud_volume_facts`` module was renamed to :ref:`hcloud_volume_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_volume_facts`` モジュールの名前が :ref:`hcloud_volume_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:533 -msgid "The ``hpilo_facts`` module was renamed to :ref:`hpilo_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hpilo_facts`` モジュールの名前が :ref:`hpilo_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:536 -msgid "The ``iam_mfa_device_facts`` module was renamed to :ref:`iam_mfa_device_info `." -msgstr "``iam_mfa_device_facts`` モジュールの名前が :ref:`iam_mfa_device_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:537 -msgid "The ``iam_role_facts`` module was renamed to :ref:`iam_role_info `." -msgstr "``iam_role_facts`` モジュールの名前が :ref:`iam_role_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:538 -msgid "The ``iam_server_certificate_facts`` module was renamed to :ref:`iam_server_certificate_info `." -msgstr "``iam_server_certificate_facts`` モジュールの名前が :ref:`iam_server_certificate_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:539 -msgid "The ``idrac_redfish_facts`` module was renamed to :ref:`idrac_redfish_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``idrac_redfish_facts`` モジュールの名前が :ref:`idrac_redfish_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:542 -msgid "The ``intersight_facts`` module was renamed to :ref:`intersight_info `." -msgstr "``intersight_facts`` モジュールの名前が :ref:`intersight_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:543 -msgid "The ``jenkins_job_facts`` module was renamed to :ref:`jenkins_job_info `." -msgstr "``jenkins_job_facts`` モジュールの名前が :ref:`jenkins_job_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:544 -msgid "The ``k8s_facts`` module was renamed to :ref:`k8s_info `." -msgstr "``k8s_facts`` モジュールの名前が :ref:`k8s_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:545 -msgid "The ``memset_memstore_facts`` module was renamed to :ref:`memset_memstore_info `." -msgstr "``memset_memstore_facts`` モジュールの名前が :ref:`memset_memstore_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:546 -msgid "The ``memset_server_facts`` module was renamed to :ref:`memset_server_info `." -msgstr "``memset_server_facts`` モジュールの名前が :ref:`memset_server_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:547 -msgid "The ``one_image_facts`` module was renamed to :ref:`one_image_info `." -msgstr "``one_image_facts`` モジュールの名前が :ref:`one_image_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:548 -msgid "The ``onepassword_facts`` module was renamed to :ref:`onepassword_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``onepassword_facts`` モジュールの名前が :ref:`onepassword_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:551 -msgid "The ``oneview_datacenter_facts`` module was renamed to :ref:`oneview_datacenter_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_datacenter_facts`` モジュールの名前が :ref:`oneview_datacenter_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:554 -msgid "The ``oneview_enclosure_facts`` module was renamed to :ref:`oneview_enclosure_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_enclosure_facts`` モジュールの名前が :ref:`oneview_enclosure_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:557 -msgid "The ``oneview_ethernet_network_facts`` module was renamed to :ref:`oneview_ethernet_network_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_ethernet_network_facts`` モジュールの名前が :ref:`oneview_ethernet_network_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:560 -msgid "The ``oneview_fc_network_facts`` module was renamed to :ref:`oneview_fc_network_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_fc_network_facts`` モジュールの名前が :ref:`oneview_fc_network_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:563 -msgid "The ``oneview_fcoe_network_facts`` module was renamed to :ref:`oneview_fcoe_network_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_fcoe_network_facts`` モジュールの名前が :ref:`oneview_fcoe_network_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:566 -msgid "The ``oneview_logical_interconnect_group_facts`` module was renamed to :ref:`oneview_logical_interconnect_group_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_logical_interconnect_group_facts`` モジュールの名前が :ref:`oneview_logical_interconnect_group_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:569 -msgid "The ``oneview_network_set_facts`` module was renamed to :ref:`oneview_network_set_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_network_set_facts`` モジュールの名前が :ref:`oneview_network_set_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:572 -msgid "The ``oneview_san_manager_facts`` module was renamed to :ref:`oneview_san_manager_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_san_manager_facts`` モジュールの名前が :ref:`oneview_san_manager_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:575 -msgid "The ``os_flavor_facts`` module was renamed to :ref:`os_flavor_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_flavor_facts`` モジュールの名前が :ref:`os_flavor_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:578 -msgid "The ``os_image_facts`` module was renamed to :ref:`os_image_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_image_facts`` モジュールの名前が :ref:`os_image_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:581 -msgid "The ``os_keystone_domain_facts`` module was renamed to :ref:`os_keystone_domain_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_keystone_domain_facts`` モジュールの名前が :ref:`os_keystone_domain_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:584 -msgid "The ``os_networks_facts`` module was renamed to :ref:`os_networks_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_networks_facts`` モジュールの名前が :ref:`os_networks_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:587 -msgid "The ``os_port_facts`` module was renamed to :ref:`os_port_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_port_facts`` モジュールの名前が :ref:`os_port_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:590 -msgid "The ``os_project_facts`` module was renamed to :ref:`os_project_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_project_facts`` モジュールの名前が :ref:`os_project_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:593 -msgid "The ``os_server_facts`` module was renamed to :ref:`os_server_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_server_facts`` モジュールの名前が :ref:`os_server_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:596 -msgid "The ``os_subnets_facts`` module was renamed to :ref:`os_subnets_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_subnets_facts`` モジュールの名前が :ref:`os_subnets_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:599 -msgid "The ``os_user_facts`` module was renamed to :ref:`os_user_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_user_facts`` モジュールの名前が :ref:`os_user_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:602 -msgid "The ``ovirt_affinity_label_facts`` module was renamed to :ref:`ovirt_affinity_label_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_affinity_label_facts`` モジュールの名前が :ref:`ovirt_affinity_label_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:605 -msgid "The ``ovirt_api_facts`` module was renamed to :ref:`ovirt_api_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_api_facts`` モジュールの名前が :ref:`ovirt_api_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:608 -msgid "The ``ovirt_cluster_facts`` module was renamed to :ref:`ovirt_cluster_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_cluster_facts`` モジュールの名前が :ref:`ovirt_cluster_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:611 -msgid "The ``ovirt_datacenter_facts`` module was renamed to :ref:`ovirt_datacenter_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_datacenter_facts`` モジュールの名前が :ref:`ovirt_datacenter_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:614 -msgid "The ``ovirt_disk_facts`` module was renamed to :ref:`ovirt_disk_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_disk_facts`` モジュールの名前が :ref:`ovirt_disk_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:617 -msgid "The ``ovirt_event_facts`` module was renamed to :ref:`ovirt_event_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_event_facts`` モジュールの名前が :ref:`ovirt_event_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:620 -msgid "The ``ovirt_external_provider_facts`` module was renamed to :ref:`ovirt_external_provider_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_external_provider_facts`` モジュールの名前が :ref:`ovirt_external_provider_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:623 -msgid "The ``ovirt_group_facts`` module was renamed to :ref:`ovirt_group_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_group_facts`` モジュールの名前が :ref:`ovirt_group_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:626 -msgid "The ``ovirt_host_facts`` module was renamed to :ref:`ovirt_host_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_host_facts`` モジュールの名前が :ref:`ovirt_host_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:629 -msgid "The ``ovirt_host_storage_facts`` module was renamed to :ref:`ovirt_host_storage_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_host_storage_facts`` モジュールの名前が :ref:`ovirt_host_storage_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:632 -msgid "The ``ovirt_network_facts`` module was renamed to :ref:`ovirt_network_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_network_facts`` モジュールの名前が :ref:`ovirt_network_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:635 -msgid "The ``ovirt_nic_facts`` module was renamed to :ref:`ovirt_nic_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_nic_facts`` モジュールの名前が :ref:`ovirt_nic_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:638 -msgid "The ``ovirt_permission_facts`` module was renamed to :ref:`ovirt_permission_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_permission_facts`` モジュールの名前が :ref:`ovirt_permission_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:641 -msgid "The ``ovirt_quota_facts`` module was renamed to :ref:`ovirt_quota_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_quota_facts`` モジュールの名前が :ref:`ovirt_quota_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:644 -msgid "The ``ovirt_scheduling_policy_facts`` module was renamed to :ref:`ovirt_scheduling_policy_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_scheduling_policy_facts`` モジュールの名前が :ref:`ovirt_scheduling_policy_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:647 -msgid "The ``ovirt_snapshot_facts`` module was renamed to :ref:`ovirt_snapshot_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_snapshot_facts`` モジュールの名前が :ref:`ovirt_snapshot_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:650 -msgid "The ``ovirt_storage_domain_facts`` module was renamed to :ref:`ovirt_storage_domain_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_storage_domain_facts`` モジュールの名前が :ref:`ovirt_storage_domain_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:653 -msgid "The ``ovirt_storage_template_facts`` module was renamed to :ref:`ovirt_storage_template_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_storage_template_facts`` モジュールの名前が :ref:`ovirt_storage_template_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:656 -msgid "The ``ovirt_storage_vm_facts`` module was renamed to :ref:`ovirt_storage_vm_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_storage_vm_facts`` モジュールの名前が :ref:`ovirt_storage_vm_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:659 -msgid "The ``ovirt_tag_facts`` module was renamed to :ref:`ovirt_tag_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_tag_facts`` モジュールの名前が :ref:`ovirt_tag_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:662 -msgid "The ``ovirt_template_facts`` module was renamed to :ref:`ovirt_template_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_template_facts`` モジュールの名前が :ref:`ovirt_template_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:665 -msgid "The ``ovirt_user_facts`` module was renamed to :ref:`ovirt_user_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_user_facts`` モジュールの名前が :ref:`ovirt_user_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:668 -msgid "The ``ovirt_vm_facts`` module was renamed to :ref:`ovirt_vm_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_vm_facts`` モジュールの名前が :ref:`ovirt_vm_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:671 -msgid "The ``ovirt_vmpool_facts`` module was renamed to :ref:`ovirt_vmpool_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_vmpool_facts`` モジュールの名前が :ref:`ovirt_vmpool_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:674 -msgid "The ``python_requirements_facts`` module was renamed to :ref:`python_requirements_info `." -msgstr "``python_requirements_facts`` モジュールの名前が :ref:`python_requirements_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:675 -msgid "The ``rds_instance_facts`` module was renamed to :ref:`rds_instance_info `." -msgstr "``rds_instance_facts`` モジュールの名前が :ref:`rds_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:676 -msgid "The ``rds_snapshot_facts`` module was renamed to :ref:`rds_snapshot_info `." -msgstr "``rds_snapshot_facts`` モジュールの名前が :ref:`rds_snapshot_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:677 -msgid "The ``redfish_facts`` module was renamed to :ref:`redfish_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``redfish_facts`` モジュールの名前が :ref:`redfish_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:680 -msgid "The ``redshift_facts`` module was renamed to :ref:`redshift_info `." -msgstr "``redshift_facts`` モジュールの名前が :ref:`redshift_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:681 -msgid "The ``route53_facts`` module was renamed to :ref:`route53_info `." -msgstr "``route53_facts`` モジュールの名前が :ref:`route53_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:682 -msgid "The ``smartos_image_facts`` module was renamed to :ref:`smartos_image_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``smartos_image_facts`` モジュールの名前が :ref:`smartos_image_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:685 -msgid "The ``vertica_facts`` module was renamed to :ref:`vertica_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``vertica_facts`` モジュールの名前が :ref:`vertica_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:688 -msgid "The ``vmware_cluster_facts`` module was renamed to :ref:`vmware_cluster_info `." -msgstr "``vmware_cluster_facts`` モジュールの名前が :ref:`vmware_cluster_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:689 -msgid "The ``vmware_datastore_facts`` module was renamed to :ref:`vmware_datastore_info `." -msgstr "``vmware_datastore_facts`` モジュールの名前が :ref:`vmware_datastore_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:690 -msgid "The ``vmware_guest_facts`` module was renamed to :ref:`vmware_guest_info `." -msgstr "``vmware_guest_facts`` モジュールの名前が :ref:`vmware_guest_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:691 -msgid "The ``vmware_guest_snapshot_facts`` module was renamed to :ref:`vmware_guest_snapshot_info `." -msgstr "``vmware_guest_snapshot_facts`` モジュールの名前が :ref:`vmware_guest_snapshot_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:692 -msgid "The ``vmware_tag_facts`` module was renamed to :ref:`vmware_tag_info `." -msgstr "``vmware_tag_facts`` モジュールの名前が :ref:`vmware_tag_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:693 -msgid "The ``vmware_vm_facts`` module was renamed to :ref:`vmware_vm_info `." -msgstr "``vmware_vm_facts`` モジュールの名前が :ref:`vmware_vm_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:694 -msgid "The ``xenserver_guest_facts`` module was renamed to :ref:`xenserver_guest_info `." -msgstr "``xenserver_guest_facts`` モジュールの名前が :ref:`xenserver_guest_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:695 -msgid "The ``zabbix_group_facts`` module was renamed to :ref:`zabbix_group_info `." -msgstr "``zabbix_group_facts`` モジュールの名前が :ref:`zabbix_group_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:696 -msgid "The ``zabbix_host_facts`` module was renamed to :ref:`zabbix_host_info `." -msgstr "``zabbix_host_facts`` モジュールの名前が :ref:`zabbix_host_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:701 -msgid ":ref:`vmware_cluster ` was refactored for easier maintenance/bugfixes. Use the three new, specialized modules to configure clusters. Configure DRS with :ref:`vmware_cluster_drs `, HA with :ref:`vmware_cluster_ha ` and vSAN with :ref:`vmware_cluster_vsan `." -msgstr ":ref:`vmware_cluster ` がリファクタリングされ、維持やバグ修正が容易になりました。クラスターの構成には、3 つの新しい専用モジュールを使用します。:ref:`vmware_cluster_drs ` で DRS を設定し、:ref:`vmware_cluster_ha ` で HA を設定し、:ref:`vmware_cluster_vsan ` で vSAN を設定します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:702 -msgid ":ref:`vmware_dvswitch ` accepts ``folder`` parameter to place dvswitch in user defined folder. This option makes ``datacenter`` as an optional parameter." -msgstr ":ref:`vmware_dvswitch ` は、ユーザー定義のディレクトリーに dvswitch を配置する ``folder`` パラメーターを受け入れます。このオプションは ``datacenter`` を任意のパラメーターとして指定します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:703 -msgid ":ref:`vmware_datastore_cluster ` accepts ``folder`` parameter to place datastore cluster in user defined folder. This option makes ``datacenter`` as an optional parameter." -msgstr ":ref:`vmware_datastore_cluster ` は、ユーザー定義のディレクトリーにデータストアクラスターを配置する ``folder`` パラメーターを受け入れます。このオプションは ``datacenter`` を任意のパラメーターとして指定します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:704 -msgid ":ref:`mysql_db ` returns new ``db_list`` parameter in addition to ``db`` parameter. This ``db_list`` parameter refers to list of database names. ``db`` parameter will be deprecated in version 2.13." -msgstr ":ref:`mysql_db ` は、``db`` パラメーターに加えて、新しい``db_list`` パラメーターを返します。この ``db_list`` パラメーターは、データベース名のリストを参照します。``db`` パラメーターは、バージョン 2.13 で非推奨となります。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:705 -msgid ":ref:`snow_record ` and :ref:`snow_record_find ` now takes environment variables for ``instance``, ``username`` and ``password`` parameters. This change marks these parameters as optional." -msgstr ":ref:`snow_record ` と:ref:`snow_record_find ` は、``instance``、``username``、``password`` のパラメータに環境変数を使用するようになりました。この変更により、これらのパラメータは任意となります。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:706 -msgid "The deprecated ``force`` option in ``win_firewall_rule`` has been removed." -msgstr "``win_firewall_rule`` の非推奨の ``force`` オプションは削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:707 -msgid ":ref:`openssl_certificate `'s ``ownca`` provider creates authority key identifiers if not explicitly disabled with ``ownca_create_authority_key_identifier: no``. This is only the case for the ``cryptography`` backend, which is selected by default if the ``cryptography`` library is available." -msgstr ":ref:`openssl_certificate ` の ``ownca`` プロバイダーは、``ownca_create_authority_key_identifier: no`` で明示的に無効にしていなければ、権限キーの識別子を作成します。これは、``cryptography`` バックエンドの場合のみで、``cryptography`` ライブラリーが利用可能な場合はデフォルトで選択されます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:708 -msgid ":ref:`openssl_certificate `'s ``ownca`` and ``selfsigned`` providers create subject key identifiers if not explicitly disabled with ``ownca_create_subject_key_identifier: never_create`` resp. ``selfsigned_create_subject_key_identifier: never_create``. If a subject key identifier is provided by the CSR, it is taken; if not, it is created from the public key. This is only the case for the ``cryptography`` backend, which is selected by default if the ``cryptography`` library is available." -msgstr ":ref:`openssl_certificate ` の``ownca`` プロバイダーおよび ``selfsigned`` プロバイダーは、``ownca_create_subject_key_identifier: never_create`` および ``selfsigned_create_subject_key_identifier: never_create`` でそれぞれ明示的に無効化されていなければ、サブジェクト鍵の識別子を作成します。CSR によってサブジェクト鍵識別子が提供されている場合はそれが使用され、提供されていない場合は公開鍵から作成されます。これは ``cryptography`` バックエンドの場合のみで、``cryptography`` ライブラリーが利用可能な場合はデフォルトで選択されます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:709 -msgid ":ref:`openssh_keypair ` now applies the same file permissions and ownership to both public and private keys (both get the same ``mode``, ``owner``, ``group``, and so on). If you need to change permissions / ownership on one key, use the :ref:`file ` to modify it after it is created." -msgstr ":ref:`openssh_keypair ` は、公開鍵と秘密鍵の両方に同じファイルのパーミッションと所有権を適用するようになりました (両方に同じ ``mode``、``owner``、``group`` などが適用されます)。ある鍵のパーミッション/所有権を変更する必要がある場合は、作成後に :ref:`file ` を使用して変更します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:716 -msgid "Removed Lookup Plugins" -msgstr "削除されたルックアッププラグイン" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:718 -msgid "``redis_kv`` use :ref:`redis ` instead." -msgstr "``redis_kv`` は、代わりに :ref:`redis ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:731 -msgid "Network resource modules" -msgstr "ネットワークリソースモジュール" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:733 -msgid "Ansible 2.9 introduced the first batch of network resource modules. Sections of a network device's configuration can be thought of as a resource provided by that device. Network resource modules are intentionally scoped to configure a single resource and you can combine them as building blocks to configure complex network services. The older modules are deprecated in Ansible 2.9 and will be removed in Ansible 2.13. You should scan the list of deprecated modules above and replace them with the new network resource modules in your playbooks. See `Ansible Network Features in 2.9 `_ for details." -msgstr "Ansible 2.9 では、ネットワークリソースモジュールの最初のバッチが導入されました。ネットワークデバイスの設定のセクションは、そのデバイスが提供するリソースと考えることができます。ネットワークリソースモジュールは、意図的に 1 つのリソースを設定するようにスコープされており、複雑なネットワークサービスを設定するためのビルディングブロックとして組み合わせることができます。古いモジュールは、Ansible 2.9 で非推奨となり、Ansible 2.13 で削除される予定です。上記の非推奨モジュールのリストをスキャンし、Playbook の中で新しいネットワークリソースモジュールに置き換える必要があります。詳細は「`2.9 の Ansible ネットワーク機能 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:736 -msgid "Improved ``gather_facts`` support for network devices" -msgstr "ネットワークデバイスの ``gather_facts`` サポートが改善されました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:738 -msgid "In Ansible 2.9, the ``gather_facts`` keyword now supports gathering network device facts in standardized key/value pairs. You can feed these network facts into further tasks to manage the network device. You can also use the new ``gather_network_resources`` parameter with the network ``*_facts`` modules (such as :ref:`eos_facts `) to return just a subset of the device configuration. See :ref:`network_gather_facts` for an example." -msgstr "Ansible 2.9 では、``gather_facts`` キーワードが、標準化されたキー/値のペアでのネットワークデバイスのファクトの収集に対応しました。これらのネットワークファクトを、ネットワークデバイスを管理するためのさらなるタスクに投入することができます。また、新しい ``gather_network_resources`` パラメーターをネットワーク ``*_facts`` モジュール (:ref:`eos_facts ` など) と一緒に使用することで、デバイス構成のサブセットのみを返すことができます。その例として、「:ref:`network_gather_facts`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:741 -msgid "Top-level connection arguments removed in 2.9" -msgstr "2.9 で削除された最上位の接続引数" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:743 -msgid "Top-level connection arguments like ``username``, ``host``, and ``password`` are removed in version 2.9." -msgstr "``username``、``host``、``password`` などの最上位レベルの接続引数は、バージョン 2.9 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:759 -msgid "Change your playbooks to the connection types ``network_cli`` and ``netconf`` using standard Ansible connection properties, and setting those properties in inventory by group. As you update your playbooks and inventory files, you can easily make the change to ``become`` for privilege escalation (on platforms that support it). For more information, see the :ref:`using become with network modules` guide and the :ref:`platform documentation`." -msgstr "Playbook を、Ansible の標準的な接続プロパティーを使用して接続タイプ ``network_cli`` および``netconf`` に変更し、インベントリーでこれらのプロパティーをグループごとに設定します。Playbook とインベントリーファイルを更新する際に、特権昇格のために ``become`` への変更を簡単に行うことができます (サポートしているプラットフォームの場合)。詳細については、「:ref:`ネットワークモジュールで become の使用`」ガイドおよび :ref:`プラットフォームのドキュメント` を参照してください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:8 -msgid "Ansible 3 Porting Guide" -msgstr "Ansible 3 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_3.rst:15 -msgid "Ansible 3 is based on Ansible-Base 2.10, which is the same major release as Ansible 2.10. Therefore, there is no section on ansible-base in this porting guide. If you are upgrading from Ansible 2.9, please first consult the Ansible 2.10 porting guide before continuing with the Ansible 3 porting guide." -msgstr "Ansible 3 は、Ansible 2.10 と同じメジャーリリースである Ansible-Base 2.10 をベースにしています。そのため、この移植ガイドには、ansible-base に関するセクションはありません。Ansible 2.9 からアップグレードする場合は、まず Ansible 2.10 の移植ガイドを参照してから、Ansible 3 の移植ガイドに進んでください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:17 -msgid "We suggest you read this page along with the `Ansible Changelog for 3.0 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 3.0 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:20 -msgid "Due to a scheduling conflict, the latest version of Ansible 2.10 (2.10.7) has a few collections which are newer than Ansible 3.0.0. Ansible 3.1.0 will contain updated versions of those collections." -msgstr "スケジュールの都合上、Ansible 2.10 の最新版 (2.10.7) には、Ansible 3.0.0 よりも新しいコレクションがいくつかあります。Ansible 3.1.0 には、これらのコレクションのアップデート版が含まれます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:24 -msgid "Porting Guide for v3.0.0" -msgstr "v3.0.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_3.rst:35 -msgid "ansible.utils" -msgstr "ansible.utils" - -#: ../../rst/porting_guides/porting_guide_3.rst:37 -msgid "If added custom sub plugins in your collection move from old location `plugins/` to the new location `plugins/sub_plugins/` and update the imports as required" -msgstr "コレクションにカスタムサブプラグインを追加した場合、以前の場所 `plugins/` から新しい場所 `plugins/sub_plugins/` に移動し、必要に応じてインポートを更新します。" - -#: ../../rst/porting_guides/porting_guide_3.rst:38 -msgid "Move sub plugins cli_parsers, fact_diff and validate to `plugins/sub_plugins` folder" -msgstr "サブプラグイン cli_parsers、fact_diff、および validate を `plugins/sub_plugins` ディレクトリーに移動します。" - -#: ../../rst/porting_guides/porting_guide_3.rst:39 -msgid "The `cli_parsers` sub plugins folder name is changed to `cli_parse` to have consistent naming convention, that is all the cli_parse subplugins will now be in `plugins/sub_plugins/cli_parse` folder" -msgstr "`cli_parsers` サブプラグインのディレクトリー名が、一貫性のある命名規則を持つように `cli_parse` に変更になり、cli_parse サブプラグインはすべて `plugins/sub_plugins/cli_parse` ディレクトリーに置かれます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:42 -msgid "cloudscale_ch.cloud" -msgstr "cloudscale_ch.cloud" - -#: ../../rst/porting_guides/porting_guide_3.rst:44 -msgid "floating_ip - ``name`` is required for assigning a new floating IP." -msgstr "floating_ip - 新しい Floating IP アドレスの割り当てには ``name`` が必要です。" - -#: ../../rst/porting_guides/porting_guide_3.rst:49 -msgid "If you use Ansible 2.9 and the Google cloud plugins or modules from this collection, community.general 2.0.0 results in errors when trying to use the Google cloud content by FQCN, like ``community.general.gce_img``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.google.gce_img`` for the previous example) and to make sure that you have ``community.google`` installed." -msgstr "Ansible 2.9 とこのコレクションの Google Cloud プラグインまたはモジュールを使用している場合、community.general 2.0.0 では、``community.general.gce_img`` のように FQCN で Google Cloud コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では ``community.google.gce_img``) を使用するために Playbook とロールを手動で調整し、``community.google`` がインストールされているかどうかを確認する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:52 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install the ``community.google`` or ``google.cloud`` collections if you are using any of the Google cloud plugins or modules. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (such as community.google) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) した場合、Google cloud プラグインまたはモジュールを使用している場合は、``community.google`` コレクションまたは ``google.cloud`` コレクションもインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.google など) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:54 -msgid "If you use Ansible 2.9 and the Kubevirt plugins or modules from this collection, community.general 2.0.0 results in errors when trying to use the Kubevirt content by FQCN, like ``community.general.kubevirt_vm``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.kubevirt.kubevirt_vm`` for the previous example) and to make sure that you have ``community.kubevirt`` installed." -msgstr "Ansible 2.9 とこのコレクションの Kubevirt プラグインまたはモジュールを使用している場合、community.general 2.0.0 では、``community.general.kubevirt_vm`` のような FQCN による Kubevirt コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN を使用するために Playbook とロールを手動で調整する必要があります (前述の例では ``community.kubevirt.kubevirt_vm``)。また、``community.kubevirt`` がインストールされていることを確認してください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:57 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install the ``community.kubevirt`` collection if you are using any of the Kubevirt plugins or modules. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (such as community.google) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) し、Kubevirt プラグインまたはモジュールを使用している場合は、``community.kubevirt`` コレクションもインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.google など) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:59 -msgid "If you use Ansible 2.9 and the ``docker`` plugins or modules from this collections, community.general 2.0.0 results in errors when trying to use the docker content by FQCN, like ``community.general.docker_container``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.docker.docker_container`` for the previous example) and to make sure that you have ``community.docker`` installed." -msgstr "Ansible 2.9 と、このコレクションの ``docker`` プラグインやモジュールを使用している場合、community.general 2.0.0 では、``community.general.docker_container`` のように FQCN による docker コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では ``community.docker.docker_container``) を使用し、``community.docker`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:62 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.docker`` if you are using any of the ``docker`` plugins or modules. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.docker) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) した場合、``docker`` プラグインまたはモジュールを使用している場合は、``community.docker`` もインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.docker) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:64 -msgid "If you use Ansible 2.9 and the ``hashi_vault`` lookup plugin from this collections, community.general 2.0.0 results in errors when trying to use the Hashi Vault content by FQCN, like ``community.general.hashi_vault``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your inventories, variable files, playbooks and roles manually to use the new FQCN (``community.hashi_vault.hashi_vault``) and to make sure that you have ``community.hashi_vault`` installed." -msgstr "Ansible 2.9 と、このコレクションの ``hashi_vault`` lookup プラグインやモジュールを使用している場合、community.general 2.0.0 では、``community.general.hashi_vault`` のように FQCN による Hashi Vault コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (``community.hashi_vault.hashi_vault``) を使用し、``community.hashi_vault`` がインストールされていることを確認するために、インベントリー、変数ファイル、Playbook、およびロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:67 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.hashi_vault`` if you are using the ``hashi_vault`` plugin. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.hashi_vault) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) し、``hashi_vault`` プラグインを使用している場合は、``community.hashi_vault`` もインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.hashi_vault) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:69 -msgid "If you use Ansible 2.9 and the ``hetzner`` modules from this collections, community.general 2.0.0 results in errors when trying to use the hetzner content by FQCN, like ``community.general.hetzner_firewall``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.hrobot.firewall`` for the previous example) and to make sure that you have ``community.hrobot`` installed." -msgstr "Ansible 2.9 と、このコレクションの ``hetzner`` プラグインやモジュールを使用している場合、community.general 2.0.0 では、``community.general.hetzner_firewall`` のように FQCN による hetzner コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では ``community.hrobot.firewall``) を使用し、``community.hrobot`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:72 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.hrobot`` if you are using any of the ``hetzner`` modules. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.hrobot) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) した場合、``hetzner`` モジュールを使用している場合は、``community.hrobot`` もインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.hrobot) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:74 -msgid "If you use Ansible 2.9 and the ``oc`` connection plugin from this collections, community.general 2.0.0 results in errors when trying to use the oc content by FQCN, like ``community.general.oc``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your inventories, variable files, playbooks and roles manually to use the new FQCN (``community.okd.oc``) and to make sure that you have ``community.okd`` installed." -msgstr "Ansible 2.9 と、このコレクションの ``oc`` connection プラグインやモジュールを使用している場合、community.general 2.0.0 では、``community.general.oc`` のように FQCN による oc コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (``community.okd.oc``) を使用し、``community.okd`` がインストールされていることを確認するために、インベントリー、変数ファイル、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:77 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.okd`` if you are using the ``oc`` plugin. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.okd) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) し、``oc`` プラグインを使用している場合は、``community.okd`` もインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.okd) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:79 -msgid "If you use Ansible 2.9 and the ``postgresql`` modules from this collections, community.general 2.0.0 results in errors when trying to use the postgresql content by FQCN, like ``community.general.postgresql_info``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.postgresql.postgresql_info`` for the previous example) and to make sure that you have ``community.postgresql`` installed." -msgstr "Ansible 2.9 と、このコレクションの ``postgresql`` プラグインやモジュールを使用している場合、community.general 2.0.0 では、``community.general.postgresql_info`` のように FQCN による postgresql コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では ``community.postgresql.postgresql_info``) を使用し、``community.postgresql`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:82 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.postgresql`` if you are using any of the ``postgresql`` modules. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.postgresql) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) し、``postgresql`` モジュールを使用している場合は、``community.postgresql`` もインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.postgresql) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:84 -#: ../../rst/porting_guides/porting_guide_3.rst:308 -msgid "The Google cloud inventory script ``gce.py`` has been migrated to the ``community.google`` collection. Install the ``community.google`` collection in order to continue using it." -msgstr "Google クラウドインベントリースクリプト ``gce.py`` を ``community.google`` コレクションに移行しました。使用を継続するには、``community.google`` コレクションをインストールしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:85 -msgid "archive - remove path folder itself when ``remove`` parameter is true (https://github.com/ansible-collections/community.general/issues/1041)." -msgstr "archive - ``remove`` パラメーターが true の場合にパスフォルダー自体を削除します (https://github.com/ansible-collections/community.general/issues/1041)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:87 -msgid "passwordstore lookup plugin - now parsing a password store entry as YAML if possible, skipping the first line (which by convention only contains the password and nothing else). If it cannot be parsed as YAML, the old ``key: value`` parser will be used to process the entry. Can break backwards compatibility if YAML formatted code was parsed in a non-YAML interpreted way, e.g. ``foo: [bar, baz]`` will become a list with two elements in the new version, but a string ``'[bar, baz]'`` in the old (https://github.com/ansible-collections/community.general/issues/1673)." -msgstr "passwordstore lookup プラグイン - パスワードストアのエントリーを可能な限り YAML として解析するようになり、最初の行 (慣例ではパスワードのみを含み、他には何もない) をスキップするようになりました。YAML として解析できない場合は、古い ``key: value`` パーサーがエントリーの処理に使用されます。YAML 形式のコードが YAML ではない解釈方法で解析された場合は、下位互換性を失う可能性があります。たとえば、``foo: [bar, baz]`` は新バージョンでは 2 つの要素を持つリストになりますが、旧バージョンでは文字列 ``'[bar, baz]'`` になります (https://github.com/ansible-collections/community.general/issues/1673)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:90 -msgid "proxmox_kvm - recognize ``force=yes`` in conjunction with ``state=absent`` to forcibly remove a running VM (https://github.com/ansible-collections/community.general/pull/849)." -msgstr "proxmox_kvm - ``force=yes`` を ``state=absent`` と併用して、実行中の仮想マシンを強制的に削除します (https://github.com/ansible-collections/community.general/pull/849)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:106 -msgid "If you use Ansible 2.9 and the FortiOS modules from this collection, community.network 2.0.0 results in errors when trying to use the FortiOS content by FQCN, like ``community.network.fmgr_device``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.fortios.fmgr_device`` for the previous example) and to make sure that you have ``community.fortios`` installed." -msgstr "このコレクションの Ansible 2.9 と FortiOS モジュールを使用する場合は、community.network 2.0.0 を使用すると、FQCN で ``community.network.fmgr_device`` のような FortiOS コンテンツを使用しようとすると、エラーが発生します。Ansible 2.9 はリダイレクトを使用できないため、新しい FQCN を使用し、``community.fortios`` がインストールされているのを確認するには、Playbook とロールを手動で調整する必要があります (前の例の ``community.fortios.fmgr_device``)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:109 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``community.fortios`` if you are using any of the FortiOS modules. While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (community.fortios) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.network をインストール (またはアップグレード) した場合、FortiOS モジュールを使用している場合は、``community.fortios`` もインストールする必要があります。ansible-base 2.10 以降では、community.network 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.fortios) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:111 -msgid "If you use Ansible 2.9 and the ``cp_publish`` module from this collection, community.network 2.0.0 results in errors when trying to use the module by FQCN, i.e. ``community.network.cp_publish``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``check_point.mgmt.cp_mgmt_publish``) and to make sure that you have ``check_point.mgmt`` installed. If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``check_point.mgmt`` if you are using the ``cp_publish`` module. While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (check_point.mgmt) must be installed for them to work." -msgstr "Ansible 2.9 とこのコレクションの ``cp_publish`` モジュールを使用している場合、community.network 2.0.0 では、FQCN でモジュールを使用しようとするとエラーが発生します (``community.network.cp_publish``)。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (``check_point.mgmt.cp_mgmt_publish``) を使用し、``check_point.mgmt`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、community.network を手動でインストール (またはアップグレード) し、``cp_publish`` モジュールを使用している場合は、``check_point.mgmt`` もインストールする必要があります。ansible-base 2.10 以降では community.network 2.0.0 が追加するリダイレクトを使用することができますが、リダイレクト先のコレクション (check_point.mgmt) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:113 -msgid "If you use Ansible 2.9 and the ``fortimanager`` httpapi plugin from this collection, community.network 2.0.0 results in errors when trying to use it by FQCN (``community.network.fortimanager``). Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCN ``fortinet.fortimanager.fortimanager`` and to make sure that you have ``fortinet.fortimanager`` installed." -msgstr "Ansible 2.9 とこのコレクションの ``fortimanager`` httpapi プラグインを使用している場合、community.network 2.0.0 では、FQCN (``community.network.fortimanager``) で使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN ``fortinet.fortimanager.fortimanager`` を使用し、``fortinet.fortimanager`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:116 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``fortinet.fortimanager`` if you are using the ``fortimanager`` httpapi plugin. While ansible-base 2.10 or newer can use the redirect that community.network 2.0.0 adds, the collection they point to (fortinet.fortimanager) must be installed for it to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.network をインストール (またはアップグレード) し、``fortimanager`` httpapi プラグインを使用している場合は、``fortinet.fortimanager`` もインストールする必要があります。ansible-base 2.10 以降では、community.network 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (fortinet.fortimanager) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:118 -msgid "If you use Ansible 2.9 and the ``nso`` modules from this collection, community.network 2.0.0 results in errors when trying to use the nso content by FQCN, like ``community.network.nso_config``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``cisco.nso.nso_config`` for the previous example) and to make sure that you have ``cisco.nso`` installed." -msgstr "Ansible 2.9 とこのコレクションの ``nso`` モジュールを使用している場合、community.network 2.0.0 では、``community.network.nso_config`` のように FQCN による nso コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では``cisco.nso.nso_config``) を使用し、``cisco.nso`` がインストールされていることを確認するには、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:121 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``cisco.nso`` if you are using any of the ``nso`` modules. While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (cisco.nso) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.network をインストール (またはアップグレード) し、``nso`` モジュールを使用している場合は、``cisco.nso`` もインストールする必要があります。ansible-base 2.10 以降では、community.network 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (cisco.nso) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:123 -msgid "If you use Ansible 2.9 and the ``routeros`` plugins or modules from this collections, community.network 2.0.0 results in errors when trying to use the routeros content by FQCN, like ``community.network.routeros_command``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.routeros.command`` for the previous example) and to make sure that you have ``community.routeros`` installed." -msgstr "Ansible 2.9 と、このコレクションの ``routeros`` プラグインやモジュールを使用している場合、community.network 2.0.0 では、``community.network.routeros_command`` のように FQCN による routeros コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では ``community.routeros.command``) を使用し、``community.routeros`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:126 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``community.routeros`` if you are using any of the ``routeros`` plugins or modules. While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (community.routeros) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.network をインストール (またはアップグレード) し、``routeros`` プラグインまたはモジュールを使用している場合は、``community.routeros`` もインストールする必要があります。ansible-base 2.10 以降では、community.network 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.routeros) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:128 -msgid "cnos_static_route - move ipaddress import from ansible.netcommon to builtin or package before ipaddress is removed from ansible.netcommon. You need to make sure to have the ipaddress package installed if you are using this module on Python 2.7 (https://github.com/ansible-collections/community.network/pull/129)." -msgstr "cnos_static_route - ansible.netcommon から ipaddress が削除される前に、ansible.netcommon から ipaddress のインポートをビルドインまたはパッケージに移動します。このモジュールを Python 2.7 で使う場合は、ipaddress パッケージがインストールされていることを確認する必要があります (https://github.com/ansible-collections/community.network/pull/129)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:133 -msgid "os10_bgp - Changed \"subnet\" key as list format instead of dictionary format under \"listen\" key to support multiple neighbor prefix for listen command" -msgstr "os10_bgp - listen コマンドの複数の neighbor 接頭辞をサポートするために、「listen」キーの「subnet」キーを、ディクショナリー形式からリスト形式に変更しました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:134 -msgid "os10_bgp - Changed \"vrf\" key as list format instead of dictionary format to support multiple VRF in router BGP and changed the \"vrf\" key name to \"vrfs\"" -msgstr "os10_bgp - ルーター BGP で複数の VRF をサポートするために、「vrf」キーをディクショナリー形式ではなくリスト形式に変更し、「vrf」キーの名前を「vrfs」に変更しました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:137 -msgid "ngine_io.cloudstack" -msgstr "ngine_io.cloudstack" - -#: ../../rst/porting_guides/porting_guide_3.rst:139 -msgid "Authentication option using INI files e.g. ``cloudstack.ini`` has been removed. The only supported option to authenticate is by using the module params with fallback to the ENV variables." -msgstr "INI ファイル (例: ``cloudstack.ini``) を使用した認証オプションは削除されました。現在サポートされている認証方法は、ENV 変数にフォールバックしてモジュールパラメーターを使用する方法のみです。" - -#: ../../rst/porting_guides/porting_guide_3.rst:140 -msgid "default zone deprecation - The `zone` param default value, across multiple modules, has been deprecated due to unreliable API (https://github.com/ngine-io/ansible-collection-cloudstack/pull/62)." -msgstr "デフォルトゾーンが非推奨になる - API の信頼性が低いため、複数のモジュール間で `zone` パラメーターのデフォルト値が非推奨になりました (https://github.com/ngine-io/ansible-collection-cloudstack/pull/62)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:146 -msgid "cisco.aci" -msgstr "cisco.aci" - -#: ../../rst/porting_guides/porting_guide_3.rst:148 -msgid "Change certificate_name to name in aci_aaa_user_certificate module for query operation" -msgstr "クエリー操作の certificate_name の名前を aci_aaa_user_certificate モジュールの名前に変更します。" - -#: ../../rst/porting_guides/porting_guide_3.rst:153 -msgid "For community.general 3.0.0, the ``ome_device_info``, ``idrac_firmware`` and ``idrac_server_config_profile`` modules will be moved to the `dellemc.openmanage `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 3.0.0 の場合、``ome_device_info`` モジュール、``idrac_firmware`` モジュール、および ``idrac_server_config_profile`` モジュールは `dellemc.openmanage `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_3.rst:156 -msgid "If you use Ansible 2.9 and explicitly use the DellEMC modules mentioned above from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``dellemc.openmanage.`` instead of ``community.general.``, for example replace ``community.general.ome_device_info`` in a task by ``dellemc.openmanage.ome_device_info``." -msgstr "Ansible 2.9 を使用し、このコレクションから上記の DellEMC モジュールを明示的に使用する場合は、Playbook およびロールを ``community.general.`` ではなく ``dellemc.openmanage.`` で始まる FQCN を使用するように調整する必要があります (例: ``dellemc.openmanage.ome_device_info`` によるタスクで ``community.general.ome_device_info`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:159 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the DellEMC modules mentioned above, you have to make sure to install the ``dellemc.openmanage`` collection as well. If you are using FQCNs, for example ``community.general.ome_device_info`` instead of ``ome_device_info``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.general`` を手動でインストールし、上記の DellEMC モジュールに依存している場合は、``dellemc.openmanage`` コレクションもインストールする必要があります。FQCN を使用している場合、たとえば ``ome_device_info`` の代わりに ``community.general.ome_device_info`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:161 -msgid "The community.general collection no longer depends on the ansible.netcommon collection (https://github.com/ansible-collections/community.general/pull/1561)." -msgstr "community.general コレクションは、ansible.netcommon コレクションに依存しなくなりました (https://github.com/ansible-collections/community.general/pull/1561)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:184 -msgid "os10_bgp - Enhanced router bgp keyword support for non-default vrf which are supported for default vrf and additional keyword to support both default and non-default vrf" -msgstr "os10_bgp - デフォルト vrf に対応している非デフォルト vrf 用のルーター bgp キーワードのサポートを強化し、デフォルトおよび非デフォルトの vrf の両方に対応するための追加キーワードを追加しました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:185 -msgid "os10_snmp role - Added support for snmp V3 features in community, group, host, engineID" -msgstr "os10_snmp role - コミュニティー、グループ、ホスト、engineID における snmp V3 機能のサポートを追加しました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:195 -msgid "kubernetes.core" -msgstr "kubernetes.core" - -#: ../../rst/porting_guides/porting_guide_3.rst:197 -msgid "Add changelog and fragments and document changelog process (https://github.com/ansible-collections/kubernetes.core/pull/131)." -msgstr "変更ログおよびフラグメントを追加し、変更ログプロセスを文書化します (https://github.com/ansible-collections/kubernetes.core/pull/131)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:198 -msgid "helm - New module for managing Helm charts (https://github.com/ansible-collections/kubernetes.core/pull/61)." -msgstr "helm - Helm チャート管理用の新規モジュール (https://github.com/ansible-collections/kubernetes.core/pull/61)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:199 -msgid "helm_info - New module for retrieving Helm chart information (https://github.com/ansible-collections/kubernetes.core/pull/61)." -msgstr "helm_info - Helm チャート情報を取得する新規モジュール (https://github.com/ansible-collections/kubernetes.core/pull/61)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:200 -msgid "helm_plugin - new module to manage Helm plugins (https://github.com/ansible-collections/kubernetes.core/pull/154)." -msgstr "helm_plugin - Helm プラグインを管理する新しいモジュール (https://github.com/ansible-collections/kubernetes.core/pull/154)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:201 -msgid "helm_plugin_info - new modules to gather information about Helm plugins (https://github.com/ansible-collections/kubernetes.core/pull/154)." -msgstr "helm_plugin_info - Helm プラグインに関する情報を収集する新しいモジュール (https://github.com/ansible-collections/kubernetes.core/pull/154)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:202 -msgid "helm_repository - New module for managing Helm repositories (https://github.com/ansible-collections/kubernetes.core/pull/61)." -msgstr "helm_repository - Helm リポジトリーを管理するための新規モジュール (https://github.com/ansible-collections/kubernetes.core/pull/61)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:203 -msgid "k8s - Add support for template parameter (https://github.com/ansible-collections/kubernetes.core/pull/230)." -msgstr "k8s - テンプレートパラメーターのサポートを追加します (https://github.com/ansible-collections/kubernetes.core/pull/230)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:207 -msgid "k8s_* - Add support for vaulted kubeconfig and src (https://github.com/ansible-collections/kubernetes.core/pull/193)." -msgstr "k8s_* - Vault 済み kubeconfig および src のサポートを追加します (https://github.com/ansible-collections/kubernetes.core/pull/193)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:210 -msgid "k8s_exec - New module for executing commands on pods via Kubernetes API (https://github.com/ansible-collections/kubernetes.core/pull/14)." -msgstr "k8s_exec - Kubernetes API を使用して Pod でコマンドを実行する新規モジュール (https://github.com/ansible-collections/kubernetes.core/pull/14)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:211 -msgid "k8s_exec - Return rc for the command executed (https://github.com/ansible-collections/kubernetes.core/pull/158)." -msgstr "k8s_exec - 実行したコマンドの rc を返します (https://github.com/ansible-collections/kubernetes.core/pull/158)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:213 -msgid "k8s_log - New module for retrieving pod logs (https://github.com/ansible-collections/kubernetes.core/pull/16)." -msgstr "k8s_log - Pod ログを取得する新規モジュール (https://github.com/ansible-collections/kubernetes.core/pull/16)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:284 -msgid "All Google cloud modules and plugins have now been migrated away from this collection. They can be found in either the `community.google `_ or `google.cloud `_ collections. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "Google クラウドモジュールおよびプラグインはすべて、このコレクションから移行されました。これらは `community.google `_ コレクションまたは `google.cloud `_ コレクションにあります。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されています。" - -#: ../../rst/porting_guides/porting_guide_3.rst:288 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.gce_img`` → ``community.google.gce_img``) and make sure to install the community.google or google.cloud collections as appropriate." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN を調整 (``community.general.gce_img`` →``community.google.gce_img``) し、必要に応じて community.google コレクションまたは google.cloud collections コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:289 -msgid "All Kubevirt modules and plugins have now been migrated from community.general to the `community.kubevirt `_ Ansible collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "すべての Kubevirt モジュールおよびプラグインは、community.general から `community.kubevirt `_ Ansibleコレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:292 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.kubevirt_vm`` → ``community.kubevirt.kubevirt_vm``) and make sure to install the community.kubevirt collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.kubevirt_vm`` →``community.kubevirt.kubevirt_vm``) を調整し、community.kubevirt コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:293 -msgid "All ``docker`` modules and plugins have been removed from this collection. They have been migrated to the `community.docker `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "すべての ``docker`` モジュールとプラグインが、このコレクションから削除されました。これらは `community.docker `_ コレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:297 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.docker_container`` → ``community.docker.docker_container``) and make sure to install the community.docker collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.docker_container`` →``community.docker.docker_container``) を調整し、community.docker コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:298 -msgid "All ``hetzner`` modules have been removed from this collection. They have been migrated to the `community.hrobot `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "すべての ``hetzner`` モジュールが、このコレクションから削除されました。これらは `community.hrobot `_ コレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:302 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.hetzner_firewall`` → ``community.hrobot.firewall``) and make sure to install the community.hrobot collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.hetzner_firewall`` →``community.hrobot.firewall``) を調整し、community.hrobot コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:303 -msgid "All ``postgresql`` modules have been removed from this collection. They have been migrated to the `community.postgresql `_ collection." -msgstr "すべての ``postgresql`` モジュールはこのコレクションから削除されました。これらは `community.postgresql `_ コレクションに移行しました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:306 -msgid "If you use ansible-base 2.10 or newer, redirections have been provided. If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.postgresql_info`` → ``community.postgresql.postgresql_info``) and make sure to install the community.postgresql collection." -msgstr "ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されています。Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.postgresql_info`` →``community.postgresql.postgresql_info``) を調整し、必要に応じて community.postgresql コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:309 -msgid "The ``hashi_vault`` lookup plugin has been removed from this collection. It has been migrated to the `community.hashi_vault `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "``hashi_vault`` lookup プラグインはこのコレクションから削除されました。これは `community.hashi_vault `_ コレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されています。" - -#: ../../rst/porting_guides/porting_guide_3.rst:313 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.hashi_vault`` → ``community.hashi_vault.hashi_vault``) and make sure to install the community.hashi_vault collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.hashi_vault`` →``community.hashi_vault.hashi_vault``) を調整し、community.hashi_vault コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:314 -msgid "The ``oc`` connection plugin has been removed from this collection. It has been migrated to the `community.okd `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "``oc`` connection プラグインはこのコレクションから削除されました。これは `community.okd `_ コレクションに移行されました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:318 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.oc`` → ``community.okd.oc``) and make sure to install the community.okd collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.oc`` →``community.okd.oc``) を調整し、community.okd コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:319 -msgid "The deprecated ``actionable`` callback plugin has been removed. Use the ``ansible.builtin.default`` callback plugin with ``display_skipped_hosts = no`` and ``display_ok_hosts = no`` options instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``actionable`` コールバックプラグインが削除されました。代わりに、``ansible.builtin.default`` コールバックプラグインを ``display_skipped_hosts = no`` オプションおよび ``display_ok_hosts = no`` オプションと一緒に使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:320 -msgid "The deprecated ``foreman`` module has been removed. Use the modules from the theforeman.foreman collection instead (https://github.com/ansible-collections/community.general/pull/1347) (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``foreman`` モジュールが削除されました。代わりに theforeman.foreman コレクションのモジュールを使用してください (https://github.com/ansible-collections/community.general/pull/1347) (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:321 -msgid "The deprecated ``full_skip`` callback plugin has been removed. Use the ``ansible.builtin.default`` callback plugin with ``display_skipped_hosts = no`` option instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``full_skip`` コールバックプラグインが削除されました。代わりに、``ansible.builtin.default`` コールバックプラグインを ``display_skipped_hosts = no`` オプションと一緒に使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:322 -msgid "The deprecated ``gcdns_record`` module has been removed. Use ``google.cloud.gcp_dns_resource_record_set`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcdns_record`` モジュールが削除されました。代わりに ``google.cloud.gcp_dns_resource_record_set`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:323 -msgid "The deprecated ``gcdns_zone`` module has been removed. Use ``google.cloud.gcp_dns_managed_zone`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcdns_zone`` モジュールが削除されました。代わりに ``google.cloud.gcp_dns_managed_zone`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:324 -msgid "The deprecated ``gce`` module has been removed. Use ``google.cloud.gcp_compute_instance`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gce`` モジュールが削除されました。代わりに ``google.cloud.gcp_compute_instance`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:325 -msgid "The deprecated ``gcp_backend_service`` module has been removed. Use ``google.cloud.gcp_compute_backend_service`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcp_backend_service`` モジュールが削除されました。代わりに ``google.cloud.gcp_compute_backend_service`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:326 -msgid "The deprecated ``gcp_forwarding_rule`` module has been removed. Use ``google.cloud.gcp_compute_forwarding_rule`` or ``google.cloud.gcp_compute_global_forwarding_rule`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcp_forwarding_rule`` モジュールが削除されました。代わりに ``google.cloud.gcp_compute_forwarding_rule`` または ``google.cloud.gcp_compute_global_forwarding_rule`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:327 -msgid "The deprecated ``gcp_healthcheck`` module has been removed. Use ``google.cloud.gcp_compute_health_check``, ``google.cloud.gcp_compute_http_health_check`` or ``google.cloud.gcp_compute_https_health_check`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcp_healthcheck`` モジュールが削除されました。代わりに ``google.cloud.gcp_compute_health_check``、``google.cloud.gcp_compute_http_health_check``、または ``google.cloud.gcp_compute_https_health_check`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:328 -msgid "The deprecated ``gcp_target_proxy`` module has been removed. Use ``google.cloud.gcp_compute_target_http_proxy`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcp_target_proxy`` モジュールが削除されました。代わりに ``google.cloud.gcp_compute_target_http_proxy`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:329 -msgid "The deprecated ``gcp_url_map`` module has been removed. Use ``google.cloud.gcp_compute_url_map`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcp_url_map`` モジュールが削除されました。代わりに ``google.cloud.gcp_compute_url_map`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:330 -msgid "The deprecated ``gcspanner`` module has been removed. Use ``google.cloud.gcp_spanner_database`` and/or ``google.cloud.gcp_spanner_instance`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcspanner`` モジュールが削除されました。代わりに ``google.cloud.gcp_spanner_database`` や ``google.cloud.gcp_spanner_instance`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:331 -msgid "The deprecated ``github_hooks`` module has been removed. Use ``community.general.github_webhook`` and ``community.general.github_webhook_info`` instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``github_hooks`` モジュールが削除されました。代わりに ``community.general.github_webhook`` および ``community.general.github_webhook_info`` を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:332 -msgid "The deprecated ``katello`` module has been removed. Use the modules from the theforeman.foreman collection instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``katello`` モジュールが削除されました。代わりに theforeman.foreman コレクションのモジュールを使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:333 -msgid "The deprecated ``na_cdot_aggregate`` module has been removed. Use netapp.ontap.na_ontap_aggregate instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_aggregate`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_aggregate を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:334 -msgid "The deprecated ``na_cdot_license`` module has been removed. Use netapp.ontap.na_ontap_license instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_license`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_license を使用します (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:335 -msgid "The deprecated ``na_cdot_lun`` module has been removed. Use netapp.ontap.na_ontap_lun instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_lun`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_lun を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:336 -msgid "The deprecated ``na_cdot_qtree`` module has been removed. Use netapp.ontap.na_ontap_qtree instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_qtree`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_qtree を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:337 -msgid "The deprecated ``na_cdot_svm`` module has been removed. Use netapp.ontap.na_ontap_svm instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_svm`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_svm を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:338 -msgid "The deprecated ``na_cdot_user_role`` module has been removed. Use netapp.ontap.na_ontap_user_role instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_user_role`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_user_role を使用します (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:339 -msgid "The deprecated ``na_cdot_user`` module has been removed. Use netapp.ontap.na_ontap_user instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_user`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_user を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:340 -msgid "The deprecated ``na_cdot_volume`` module has been removed. Use netapp.ontap.na_ontap_volume instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_volume`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_volume を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:341 -msgid "The deprecated ``sf_account_manager`` module has been removed. Use netapp.elementsw.na_elementsw_account instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``sf_account_manager`` モジュールが削除されました。代わりに netapp.elementsw.na_elementsw_account を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:342 -msgid "The deprecated ``sf_check_connections`` module has been removed. Use netapp.elementsw.na_elementsw_check_connections instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``sf_check_connections`` モジュールが削除されました。代わりに netapp.elementsw.na_elementsw_check_connections を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:343 -msgid "The deprecated ``sf_snapshot_schedule_manager`` module has been removed. Use netapp.elementsw.na_elementsw_snapshot_schedule instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``sf_snapshot_schedule_manager`` モジュールが削除されました。代わりに netapp.elementsw.na_elementsw_snapshot_schedule を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:344 -msgid "The deprecated ``sf_volume_access_group_manager`` module has been removed. Use netapp.elementsw.na_elementsw_access_group instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``sf_volume_access_group_manager`` モジュールが削除されました。代わりに netapp.elementsw.na_elementsw_access_group を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:345 -msgid "The deprecated ``sf_volume_manager`` module has been removed. Use netapp.elementsw.na_elementsw_volume instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``sf_volume_manager`` モジュールが削除されました。代わりに netapp.elementsw.na_elementsw_volume を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:346 -msgid "The deprecated ``stderr`` callback plugin has been removed. Use the ``ansible.builtin.default`` callback plugin with ``display_failed_stderr = yes`` option instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``stderr`` コールバックプラグインが削除されました。代わりに、``ansible.builtin.default`` コールバックプラグインを ``display_failed_stderr = yes`` オプションと一緒に使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:347 -msgid "The redirect of the ``conjur_variable`` lookup plugin to ``cyberark.conjur.conjur_variable`` collection was removed (https://github.com/ansible-collections/community.general/pull/1346)." -msgstr "``conjur_variable`` ルックアッププラグインの ``cyberark.conjur.conjur_variable`` コレクションへのリダイレクトが削除されました (https://github.com/ansible-collections/community.general/pull/1346)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:348 -msgid "The redirect of the ``firewalld`` module and the ``firewalld`` module_utils to the ``ansible.posix`` collection was removed (https://github.com/ansible-collections/community.general/pull/1346)." -msgstr "``firewalld`` モジュールおよび ``firewalld`` module_utils の ``ansible.posix`` コレクションへのリダイレクトが削除されました (https://github.com/ansible-collections/community.general/pull/1346)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:349 -msgid "The redirect to the ``community.digitalocean`` collection was removed for: the ``digital_ocean`` doc fragment, the ``digital_ocean`` module_utils, and the following modules: ``digital_ocean``, ``digital_ocean_account_facts``, ``digital_ocean_account_info``, ``digital_ocean_block_storage``, ``digital_ocean_certificate``, ``digital_ocean_certificate_facts``, ``digital_ocean_certificate_info``, ``digital_ocean_domain``, ``digital_ocean_domain_facts``, ``digital_ocean_domain_info``, ``digital_ocean_droplet``, ``digital_ocean_firewall_facts``, ``digital_ocean_firewall_info``, ``digital_ocean_floating_ip``, ``digital_ocean_floating_ip_facts``, ``digital_ocean_floating_ip_info``, ``digital_ocean_image_facts``, ``digital_ocean_image_info``, ``digital_ocean_load_balancer_facts``, ``digital_ocean_load_balancer_info``, ``digital_ocean_region_facts``, ``digital_ocean_region_info``, ``digital_ocean_size_facts``, ``digital_ocean_size_info``, ``digital_ocean_snapshot_facts``, ``digital_ocean_snapshot_info``, ``digital_ocean_sshkey``, ``digital_ocean_sshkey_facts``, ``digital_ocean_sshkey_info``, ``digital_ocean_tag``, ``digital_ocean_tag_facts``, ``digital_ocean_tag_info``, ``digital_ocean_volume_facts``, ``digital_ocean_volume_info`` (https://github.com/ansible-collections/community.general/pull/1346)." -msgstr "``community.digitalocean`` コレクションへのリダイレクトが削除されたのは、``digital_ocean`` ドキュメントのフラグメント、``digital_ocean`` module_utils、およびモジュール ``digital_ocean``、``digital_ocean_account_facts``、``digital_ocean_account_info``、``digital_ocean_block_storage``、``digital_ocean_certificate``、``digital_ocean_certificate_facts``、``digital_ocean_certificate_info``、``digital_ocean_domain``、``digital_ocean_domain_facts``、``digital_ocean_domain_info``、``digital_ocean_droplet``、``digital_ocean_firewall_facts``、``digital_ocean_firewall_info``、``digital_ocean_floating_ip``、``digital_ocean_floating_ip_facts``、``digital_ocean_floating_ip_info``、``digital_ocean_image_facts``、``digital_ocean_image_info``、``digital_ocean_load_balancer_facts``、``digital_ocean_load_balancer_info``、``digital_ocean_region_facts``、``digital_ocean_region_info``、``digital_ocean_size_facts``、``digital_ocean_size_info``、``digital_ocean_snapshot_facts``、``digital_ocean_snapshot_info``、``digital_ocean_sshkey``、``digital_ocean_sshkey_facts``、``digital_ocean_sshkey_info``、``digital_ocean_tag``、``digital_ocean_tag_facts``、``digital_ocean_tag_info``、``digital_ocean_volume_facts``、``digital_ocean_volume_info`` です (https://github.com/ansible-collections/community.general/pull/1346)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:350 -msgid "The redirect to the ``community.mysql`` collection was removed for: the ``mysql`` doc fragment, the ``mysql`` module_utils, and the following modules: ``mysql_db``, ``mysql_info``, ``mysql_query``, ``mysql_replication``, ``mysql_user``, ``mysql_variables`` (https://github.com/ansible-collections/community.general/pull/1346)." -msgstr "``community.mysql`` コレクションへのリダイレクトが削除されたのは、``mysql`` ドキュメントのフラグメント、``mysql`` module_utils、およびモジュール ``mysql_db``、``mysql_info``、``mysql_query``、``mysql_replication``、``mysql_user``、``mysql_variables`` です (https://github.com/ansible-collections/community.general/pull/1346)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:351 -msgid "The redirect to the ``community.proxysql`` collection was removed for: the ``proxysql`` doc fragment, and the following modules: ``proxysql_backend_servers``, ``proxysql_global_variables``, ``proxysql_manage_config``, ``proxysql_mysql_users``, ``proxysql_query_rules``, ``proxysql_replication_hostgroups``, ``proxysql_scheduler`` (https://github.com/ansible-collections/community.general/pull/1346)." -msgstr "``proxysql`` doc フラグメントと、モジュール ``proxysql_backend_servers``、``proxysql_global_variables``、``proxysql_manage_config``、``proxysql_mysql_users``、``proxysql_query_rules``、``proxysql_replication_hostgroups``、および ``proxysql_scheduler`` で、``community.proxysql`` コレクションへのリダイレクトが削除されました (https://github.com/ansible-collections/community.general/pull/1346)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:352 -msgid "The redirect to the ``infinidat.infinibox`` collection was removed for: the ``infinibox`` doc fragment, the ``infinibox`` module_utils, and the following modules: ``infini_export``, ``infini_export_client``, ``infini_fs``, ``infini_host``, ``infini_pool``, ``infini_vol`` (https://github.com/ansible-collections/community.general/pull/1346)." -msgstr "``infinidat.infinibox`` コレクションへのリダイレクトが削除されたのは、``infinibox`` ドキュメントのフラグメント、``infinibox`` module_utils、およびモジュール ``infini_export``、``infini_export_client``、``infini_fs``、``infini_host``、``infini_pool``、``infini_vol`` です (https://github.com/ansible-collections/community.general/pull/1346)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:356 -msgid "iptables_state - the ``ANSIBLE_ASYNC_DIR`` environment is no longer supported, use the ``async_dir`` shell option instead (https://github.com/ansible-collections/community.general/pull/1371)." -msgstr "iptables_state - ``ANSIBLE_ASYNC_DIR`` 環境はサポート対象外になったため、代わりに ``async_dir`` シェルオプションを使用してください (https://github.com/ansible-collections/community.general/pull/1371)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:359 -msgid "memcached cache plugin - do not import ``CacheModule``s directly. Use ``ansible.plugins.loader.cache_loader`` instead (https://github.com/ansible-collections/community.general/pull/1371)." -msgstr "memcached cache プラグイン - ``CacheModule`` を直接インポートしません。代わりに ``ansible.plugins.loader.cache_loader`` を使用します (https://github.com/ansible-collections/community.general/pull/1371)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:362 -msgid "redis cache plugin - do not import ``CacheModule``s directly. Use ``ansible.plugins.loader.cache_loader`` instead (https://github.com/ansible-collections/community.general/pull/1371)." -msgstr "redis cache プラグイン - ``CacheModule`` を直接インポートしません。代わりに ``ansible.plugins.loader.cache_loader`` を使用してください (https://github.com/ansible-collections/community.general/pull/1371)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:363 -msgid "xml - when ``content=attribute``, the ``attribute`` option is ignored (https://github.com/ansible-collections/community.general/pull/1371)." -msgstr "XML - ``content=attribute`` の場合、``attribute`` オプションが無視されます (https://github.com/ansible-collections/community.general/pull/1371)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:368 -msgid "All FortiOS modules and plugins have been removed from this collection. They have been migrated to the `community.fortios `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "すべての FortiOS モジュールとプラグインが、このコレクションから削除されました。これらは `community.fortios `_ コレクションに移行されました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:372 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.fmgr_device`` → ``community.fortios.fmgr_device``) and make sure to install the `community.fortios` collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.network.fmgr_device`` →``community.fortios.fmgr_device``) を調整し、`community.fortios` コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:373 -msgid "All ``nso`` modules have been removed from this collection. They have been migrated to the `cisco.nso `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "すべての ``nso`` モジュールが、このコレクションから削除されました。これらは `cisco.nso `_ コレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:377 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.nso_config`` → ``cisco.nso.nso_config``) and make sure to install the `cisco.nso` collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.network.nso_config`` →``cisco.nso.nso_config``) を調整し、`cisco.nso` コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:378 -msgid "All ``routeros`` modules and plugins have been removed from this collection. They have been migrated to the `community.routeros `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "すべての ``routeros`` モジュールとプラグインが、このコレクションから削除されました。これらは `community.routeros `_ コレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:382 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.routeros_command`` → ``community.routeros.command``) and make sure to install the community.routeros collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN を調整 (``community.network.routeros_command`` →``community.routeros.command``) し、community.routeros コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:383 -msgid "The ``cp_publish`` module has been removed from this collection. It was a duplicate of ``check_point.mgmt.cp_mgmt_publish`` in the `check_point.mgmt `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided. If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.cp_publish`` → ``check_point.mgmt.cp_mgmt_publish``) and make sure to install the check_point.mgmt collection." -msgstr "``cp_publish`` モジュールはこのコレクションから削除されました。これは `check_point.mgmt `_ コレクションの ``check_point.mgmt.cp_mgmt_publish`` と重複していました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.network.cp_publish`` →``check_point.mgmt.cp_mgmt_publish``) を調整する必要があります。また、check_point.mgmt コレクションをインストールしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:385 -msgid "The ``fortimanager`` httpapi plugin has been removed from this collection. It was a duplicate of the one in the `fortinet.fortimanager `_ collection. If you use ansible-base 2.10 or newer, a redirection has been provided." -msgstr "``fortimanager`` httpapi プラグインはこのコレクションから削除されました。これは `fortinet.fortimanager `_ コレクションにあるものと重複していました。ansible-base 2.10 以降をお使いの方は、リダイレクトが用意されています。" - -#: ../../rst/porting_guides/porting_guide_3.rst:389 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.fortimanager`` → ``fortinet.fortimanager.fortimanager``) and make sure to install the `fortinet.fortimanager` collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.network.fortimanager`` →``fortinet.fortimanager.fortimanager``) を調整し、`fortinet.fortimanager` コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:390 -msgid "The dependency on the ``check_point.mgmt`` collection has been removed. If you depend on that installing ``community.network`` also installs ``check_point.mgmt``, you have to make sure to install ``check_point.mgmt`` explicitly." -msgstr "``check_point.mgmt`` コレクションの依存関係が削除されました。``community.network`` のインストールによって ``check_point.mgmt`` もインストールされている場合は、必ず ``check_point.mgmt`` を明示的にインストールする必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:391 -msgid "The deprecated Pluribus Networks modules ``pn_cluster``, ``pn_ospf``, ``pn_ospfarea``, ``pn_show``, ``pn_trunk``, ``pn_vlag``, ``pn_vlan``, ``pn_vrouter``, ``pn_vrouterbgp``, ``pn_vrouterif``, ``pn_vrouterlbif`` have been removed (https://github.com/ansible-collections/community.network/pull/176)." -msgstr "非推奨の Pluribus Networks モジュール ``pn_cluster``、``pn_ospf``、``pn_ospfarea``、``pn_show``、``pn_trunk``、``pn_vlag`` ``pn_vlan``、``pn_vrouter``、``pn_vrouterbgp``、``pn_vrouterif``、および ``pn_vrouterlbif`` が削除されました (https://github.com/ansible-collections/community.network/pull/176)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:392 -msgid "The deprecated modules ``panos_admin``, ``panos_admpwd``, ``panos_cert_gen_ssh``, ``panos_check``, ``panos_commit``, ``panos_dag``, ``panos_dag_tags``, ``panos_import``, ``panos_interface``, ``panos_lic``, ``panos_loadcfg``, ``panos_match_rule``, ``panos_mgtconfig``, ``panos_nat_rule``, ``panos_object``, ``panos_op``, ``panos_pg``, ``panos_query_rules``, ``panos_restart``, ``panos_sag``, ``panos_security_rule``, ``panos_set`` have been removed. Use modules from the `paloaltonetworks.panos collection `_ instead (https://github.com/ansible-collections/community.network/pull/176)." -msgstr "非推奨のモジュール ``panos_admin``、``panos_admpwd``、``panos_cert_gen_ssh``、``panos_check``、``panos_commit``、``panos_dag``、``panos_dag_tags`` ``panos_import``、``panos_interface``、``panos_lic``、``panos_loadcfg``、``panos_match_rule``、``panos_mgtconfig``、``panos_nat_rule``、``panos_object``、``panos_op``、``panos_pg``、``panos_query_rules``、``panos_restart``、``panos_sag``、``panos_security_rule``、および ``panos_set`` が削除されました。代わりに `paloaltonetworks.panos collection `_ のモジュールを使用します (https://github.com/ansible-collections/community.network/pull/176)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:393 -msgid "The redirect to the ``mellanox.onyx`` collection was removed for: the ``onyx`` cliconf plugin, terminal plugin, module_utils, action plugin, doc fragment, and the following modules: ``onyx_aaa``, ``onyx_bfd``, ``onyx_bgp``, ``onyx_buffer_pool``, ``onyx_command``, ``onyx_config``, ``onyx_facts``, ``onyx_igmp``, ``onyx_igmp_interface``, ``onyx_igmp_vlan``, ``onyx_interface``, ``onyx_l2_interface``, ``onyx_l3_interface``, ``onyx_linkagg``, ``onyx_lldp``, ``onyx_lldp_interface``, ``onyx_magp``, ``onyx_mlag_ipl``, ``onyx_mlag_vip``, ``onyx_ntp``, ``onyx_ntp_servers_peers``, ``onyx_ospf``, ``onyx_pfc_interface``, ``onyx_protocol``, ``onyx_ptp_global``, ``onyx_ptp_interface``, ``onyx_qos``, ``onyx_snmp``, ``onyx_snmp_hosts``, ``onyx_snmp_users``, ``onyx_syslog_files``, ``onyx_syslog_remote``, ``onyx_traffic_class``, ``onyx_username``, ``onyx_vlan``, ``onyx_vxlan``, ``onyx_wjh`` (https://github.com/ansible-collections/community.network/pull/175)." -msgstr "``mellanox.onyx`` コレクションのリダイレクトは、``onyx`` cliconf プラグイン、ターミナルプラグイン、module_utils、action プラグイン、doc フラグメント、およびモジュール ``onyx_aaa``、``onyx_bfd``、``onyx_bgp``、``onyx_buffer_pool``、``onyx_command``、``onyx_config``、``onyx_facts``、``onyx_igmp``、``onyx_igmp_interface``、``onyx_igmp_vlan``、``onyx_interface``、``onyx_l2_interface``、``onyx_l3_interface``、``onyx_linkagg``、``onyx_lldp``、``onyx_lldp_interface``、``onyx_magp``、``onyx_mlag_ipl``、``onyx_mlag_vip``、``onyx_ntp``、``onyx_ntp_servers_peers``、``onyx_ospf``、``onyx_pfc_interface``、``onyx_protocol``、``onyx_ptp_global``、``onyx_ptp_interface``、``onyx_qos``、``onyx_snmp``、``onyx_snmp_hosts``、``onyx_snmp_users``、``onyx_syslog_files``、``onyx_syslog_remote``、``onyx_traffic_class``、``onyx_username``、``onyx_vlan``、``onyx_vxlan``、および ``onyx_wjh`` に対して削除されました (https://github.com/ansible-collections/community.network/pull/175)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:425 -msgid "The ``gluster_heal_info``, ``gluster_peer`` and ``gluster_volume`` modules have migrated to the `gluster.gluster `_ collection. Ansible-base 2.10.1 adjusted the routing target to point to the modules in that collection, so we will remove these modules in community.general 3.0.0. If you use Ansible 2.9, or use FQCNs ``community.general.gluster_*`` in your playbooks and/or roles, please update them to use the modules from ``gluster.gluster`` instead." -msgstr "``gluster_heal_info`` モジュール、``gluster_peer`` モジュール、および ``gluster_volume`` モジュールは `gluster.gluster `_ コレクションに移行しました。Ansible-base 2.10.1 では、ルーティングターゲットがこのコレクションのモジュールを参照するように調整されたため、community.general 3.0.0 でこれらのモジュールを削除する予定です。Ansible 2.9 を使用している場合や、Playbook やロールで FQCN の ``community.general.gluster_*`` を使用している場合は、代わりにこれらをアップデートして ``gluster.gluster`` のモジュールを使用するようにしてください。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:6 -msgid "Ansible-base 2.10 Porting Guide" -msgstr "Ansible-base 2.10 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:10 -msgid "In preparation for the release of 2.10, many plugins and modules have migrated to Collections on `Ansible Galaxy `_. For the current development status of Collections and FAQ see `Ansible Collections Community Guide `_. We expect the 2.10 Porting Guide to change frequently up to the 2.10 release. Follow the conversations about collections on our various :ref:`communication` channels for the latest information on the status of the ``devel`` branch." -msgstr "2.10 のリリース準備のために、多くのプラグインおよびモジュールが `Ansible Galaxy `_ の Collection に移行しています。Collection および FAQ の現在の開発ステータスは、「`Ansible Collections コミュニティーガイド `_」を参照してください。2.10 の「移植ガイド」は、2.10 のリリースに合わせて頻繁に変更することを想定しています。``devel`` ブランチのステータスに関する最新情報は、さまざまな :ref:`communication` チャンネルにあるコレクションに関する議論を確認してください。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:12 -msgid "This section discusses the behavioral changes between Ansible 2.9 and Ansible-base 2.10." -msgstr "このセクションでは、Ansible 2.9 と Ansible-base 2.10 での動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:14 -msgid "It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible-base." -msgstr "本ガイドは、このバージョンの Ansible-base で動作するように、Playbook、プラグイン、その他の Ansible インフラストラクチャーを更新する際にご利用になります。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:16 -msgid "We suggest you read this page along with the `Ansible-base Changelog for 2.10 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible-base Changelog for 2.10 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:18 -msgid "Ansible-base is mainly of interest for developers and users who only want to use a small, controlled subset of the available collections. Regular users should install ansible." -msgstr "Ansible-base は、主に、利用可能なコレクションのうち、制御された小さなサブセットのみを使用したい開発者やユーザーの興味を引く製品です。一般ユーザーは Ansible をインストールしてください。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:20 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:16 -msgid "The complete list of porting guides can be found at :ref:`porting guides `." -msgstr "移植ガイドの完全なリストは、「:ref:`移植ガイド `」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:23 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:18 -msgid "Contents" -msgstr "内容" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:6 -msgid "Ansible-core 2.11 Porting Guide" -msgstr "Ansible-core 2.11 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:8 -msgid "This section discusses the behavioral changes between ``ansible-base`` 2.10 and ``ansible-core`` 2.11." -msgstr "このセクションでは、``ansible-base`` 2.10 から ``ansible-core`` 2.11 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:10 -msgid "It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of ``ansible-core``." -msgstr "本ガイドは、このバージョンの ``ansible-core`` で動作するように、Playbook、プラグイン、その他の Ansible インフラストラクチャーを更新する際にご利用になります。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:12 -msgid "We suggest you read this page along with the `ansible-core Changelog for 2.11 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`ansible-core Changelog for 2.11 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:14 -msgid "``ansible-core`` is mainly of interest for developers and users who only want to use a small, controlled subset of the available collections. Regular users should install Ansible." -msgstr "``ansible-core`` は、主に、利用可能なコレクションのうち、制御された小さなサブセットのみを使用したい開発者やユーザーの興味を引く製品です。一般ユーザーは Ansible をインストールしてください。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:23 -msgid "The ``jinja2_native`` setting now does not affect the template module which implicitly returns strings. For the template lookup there is a new argument ``jinja2_native`` (off by default) to control that functionality. The rest of the Jinja2 expressions still operate based on the ``jinja2_native`` setting." -msgstr "``jinja2_native`` 設定は、暗黙的に文字列を返すテンプレートモジュールには影響を及ぼしません。テンプレートの検索では、その機能を制御する新しい引数 ``jinja2_native`` (デフォルトでは off) が追加されました。残りの Jinja2 式は、``jinja2_native`` 設定に基づいて動作します。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:35 -msgid "Other:" -msgstr "その他:" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:37 -msgid "**Upgrading**: If upgrading from ``ansible < 2.10`` or from ``ansible-base`` and using pip, you will need to ``pip uninstall ansible`` or ``pip uninstall ansible-base`` before installing ``ansible-core`` to avoid conflicts." -msgstr "**アップグレード**: ``2.10 より前の ansible`` または ``ansible-base`` から pip を使用してアップグレードする場合は、競合を回避するために ``ansible-core`` をインストールする前に ``pip uninstall ansible`` または ``pip uninstall ansible-base`` が必要になります。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:38 -msgid "Python 3.8 on the controller node is a soft requirement for this release. ``ansible-core`` 2.11 will continue to work with the same versions of Python that ``ansible-base`` 2.10 worked with, however it will emit a warning when running on a controller node with a Python version less than 3.8. This warning can be disabled by setting ``ANSIBLE_CONTROLLER_PYTHON_WARNING=False`` in your environment. ``ansible-core`` 2.12 will require Python 3.8 or greater." -msgstr "コントローラーノードの Python 3.8 は、本リリースではソフト要件です。``ansible-core`` 2.11 は、``ansible-base`` 2.10 が動作したのと同じバージョンの Python で引き続き機能しますが、Python バージョンが 3.8 未満のコントローラーノードで実行すると警告が表示されます。この警告は、お使いの環境に ``ANSIBLE_CONTROLLER_PYTHON_WARNING=False`` を設定して無効にできます。``ansible-core`` 2.12 の場合は Python 3.8 以降が必要になります。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:39 -msgid "The configuration system now validates the ``choices`` field, so any settings that currently violate it and are currently ignored will now cause an error. For example, `ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH=0` will now cause an error (valid choices are 'ignore', 'warn' or 'error')." -msgstr "設定システムは ``choices`` フィールドを検証するため、現在それに違反している設定があるとエラーが生じます。たとえば、`ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH=0` を選択すると、エラーが発生します (有効な選択肢は「ignore」、「warn」、または「error」です)。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:41 -msgid "The ``ansible-galaxy`` command now uses ``resolvelib`` for resolving dependencies. In most cases this should not make a user-facing difference beyond being more performant, but we note it here for posterity and completeness." -msgstr "``ansible-galaxy`` コマンドでは、依存関係の解決に ``resolvelib`` が使用されます。ほとんどの場合、パフォーマンスが向上するだけで、ユーザーにとっては何の変化もありませんが、記録のためにここに記しておきます。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:52 -msgid "The ``apt_key`` module has explicitly defined ``file`` as mutually exclusive with ``data``, ``keyserver`` and ``url``. They cannot be used together anymore." -msgstr "``apt_key`` モジュールは、``data``、``keyserver``、および ``url`` と相互に排他的なものとして、``file`` を明示的に定義します。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:53 -msgid "The ``meta`` module now supports tags for user-defined tasks. Set the task's tags to 'always' to maintain the previous behavior. Internal ``meta`` tasks continue to always run." -msgstr "``meta`` モジュールは、ユーザー定義のタスクのタグをサポートするようになりました。以前の動作を維持するために、タスクのタグを「always」に設定します。内部の ``meta`` タスクは常に実行を継続します。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:73 -msgid "facts - On NetBSD, ``ansible_virtualization_type`` now tries to report a more accurate result than ``xen`` when virtualized and not running on Xen." -msgstr "ファクト - NetBSD において、Xen 上で仮想化されていて実行していない場合、``ansible_virtualization_type`` は、``xen`` よりも正確な結果を報告しようとするようになりました。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:74 -msgid "facts - Virtualization facts now include ``virtualization_tech_guest`` and ``virtualization_tech_host`` keys. These are lists of virtualization technologies that a guest is a part of, or that a host provides, respectively. As an example, a host may be set up to provide both KVM and VirtualBox, and these will be included in ``virtualization_tech_host``, and a podman container running on a VM powered by KVM will have a ``virtualization_tech_guest`` of ``[\"kvm\", \"podman\", \"container\"]``." -msgstr "ファクト: 仮想化ファクトに ``virtualization_tech_guest`` キーおよび ``virtualization_tech_host`` キーが含まれるようになりました。以下は、ゲストが、またはホストが提供する仮想化テクノロジーの一覧です。たとえば、KVM と VirtualBox の両方を提供するようにホストを設定し、これらは ``virtualization_tech_host`` に組み込まれ、KVM で動作する仮想マシンで実行している podman コンテナーは ``[\"kvm\", \"podman\", \"container\"]`` の ``virtualization_tech_guest`` になります。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:75 -msgid "The parameter ``filter`` type is changed from ``string`` to ``list`` in the :ref:`setup ` module in order to use more than one filter. Previous behaviour (using a ``string``) still remains and works as a single filter." -msgstr "複数のフィルターを使用するために、パラメーター ``filter`` タイプは :ref:`setup ` モジュールの ``string`` から ``list`` に変更されています。以前の動作は (``string`` を使用) はそのままで、単一のフィルターとして機能します。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:81 -msgid "inventory plugins - ``CachePluginAdjudicator.flush()`` now calls the underlying cache plugin's ``flush()`` instead of only deleting keys that it knows about. Inventory plugins should use ``delete()`` to remove any specific keys. As a user, this means that when an inventory plugin calls its ``clear_cache()`` method, facts could also be flushed from the cache. To work around this, users can configure inventory plugins to use a cache backend that is independent of the facts cache." -msgstr "インベントリープラグイン - ``CachePluginAdjudicator.flush()`` は、認識している鍵を削除するのではなく、基礎となるキャッシュプラグインの ``flush()`` を呼び出すようになりました。インベントリープラグインは、``delete()`` を使用して特定キーを削除する必要があります。ユーザーとして、インベントリープラグインが ``clear_cache()`` メソッドを呼び出すと、ファクトをキャッシュからフラッシュすることもできます。これを回避するには、ファクトキャッシュから独立したキャッシュバックエンドを使用するようにインベントリープラグインを設定できます。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:82 -msgid "callback plugins - ``meta`` task execution is now sent to ``v2_playbook_on_task_start`` like any other task. By default, only explicit meta tasks are sent there. Callback plugins can opt-in to receiving internal, implicitly created tasks to act on those as well, as noted in the plugin development documentation." -msgstr "callback plugins -``meta`` タスクの実行は、他のタスクと同様に ``v2_playbook_on_task_start`` に送られるようになりました。デフォルトでは、明示的なメタタスクのみが送信されます。コールバックプラグインは、プラグイン開発のドキュメントにあるように、内部で暗黙的に作成されたタスクを受け取って、それらにも対処することを選択できます。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:83 -msgid "The ``choices`` are now validated, so plugins that were using incorrect or incomplete choices will now issue an error if the value provided does not match. This has a simple fix: update the entries in ``choices`` to match reality." -msgstr "``choices`` が検証されるようになったため、誤った選択、または不完全な選択肢を使用したプラグインが、提供された値が一致しない場合にエラーになるようになりました。これには、``choices`` のエントリーを実際に一致させるための単純な修正があります。" - -#: ../../rst/porting_guides/porting_guides.rst:5 -msgid "Ansible Porting Guides" -msgstr "Ansible 移植ガイド" - -#: ../../rst/porting_guides/porting_guides.rst:7 -msgid "This section lists porting guides that can help you in updating playbooks, plugins and other parts of your Ansible infrastructure from one version of Ansible to the next." -msgstr "本セクションでは、Ansible のあるバージョンから次のバージョンに、Ansible インフラストラクチャーの Playbook、プラグインなどを更新するのに役に立つ移植ガイドを紹介します。" - -#~ msgid "We suggest you read this page along with the `ansible-core Changelog for 2.11 `_ to understand what updates you may need to make." -#~ msgstr "" - -#~ msgid "The configuration system now validates the ``choices`` field, so any settings that currently violate it and are currently ignored will now cause an error. For example, `ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH=0` will now cause an error (valid chioces are 'ignore', 'warn' or 'error'." -#~ msgstr "" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/reference_appendices.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/reference_appendices.po deleted file mode 100644 index 9d321b8a697..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/reference_appendices.po +++ /dev/null @@ -1,9475 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-03-08 20:25+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:5 -msgid "YAML Syntax" -msgstr "YAML 構文" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:7 -msgid "This page provides a basic overview of correct YAML syntax, which is how Ansible playbooks (our configuration management language) are expressed." -msgstr "このページでは、Ansible Playbook (Ansible での設定管理言語) の表現方法である、正しい YAML 構文について概説します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:10 -msgid "We use YAML because it is easier for humans to read and write than other common data formats like XML or JSON. Further, there are libraries available in most programming languages for working with YAML." -msgstr "Ansible では、XML や JSON などのような一般的なその他のデータ形式に比べて人間による解読および記述が簡単であるため、YAML を使用しています。さらに、プログラミング言語の多くには、YAML に対応するライブラリーが提供されています。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:14 -msgid "You may also wish to read :ref:`working_with_playbooks` at the same time to see how this is used in practice." -msgstr ":ref:`working_with_playbooks` も合わせて参照し、実際にどのように使用されているかを確認してください。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:19 -msgid "YAML Basics" -msgstr "YAML の基礎" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:21 -msgid "For Ansible, nearly every YAML file starts with a list. Each item in the list is a list of key/value pairs, commonly called a \"hash\" or a \"dictionary\". So, we need to know how to write lists and dictionaries in YAML." -msgstr "Ansible で使用する場合は、YAML ファイルのほぼすべてがリストで開始します。リストの各項目は、一般的に「ハッシュ」または「ディクショナリー」と呼ばれるキー/値のペアのリストとなっています。そのため、YAML でリストとディクショナリーを記述する方法を理解する必要があります。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:26 -msgid "There's another small quirk to YAML. All YAML files (regardless of their association with Ansible or not) can optionally begin with ``---`` and end with ``...``. This is part of the YAML format and indicates the start and end of a document." -msgstr "YAML には、他にもわずかな特徴があります。YAML ファイルはすべて (Ansible との関係の有無に関係なく)、必要に応じて ``---`` で開始して ``...`` で終わらせることができます。これは、YAML 形式の一部で、ドキュメントの最初と最後を示します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:29 -msgid "All members of a list are lines beginning at the same indentation level starting with a ``\"- \"`` (a dash and a space)::" -msgstr "リストのメンバーはすべて同じインデントレベルで、``\"- \"`` (ダッシュとスペース) で開始する行になります::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:39 -msgid "A dictionary is represented in a simple ``key: value`` form (the colon must be followed by a space)::" -msgstr "ディクショナリーは、シンプルな ``key: value`` の形式で表現します (コロンの後にはスペースを挿入する必要があります)::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:47 -msgid "More complicated data structures are possible, such as lists of dictionaries, dictionaries whose values are lists or a mix of both::" -msgstr "リストがディクショナリーやその値の場合や、ディクショナリーと値が混合している場合など、より複雑なデータ構造も可能です。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:65 -msgid "Dictionaries and lists can also be represented in an abbreviated form if you really want to::" -msgstr "ディクショナリーとリストは、必要であれば、略語形式で表現することも可能です::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:71 -msgid "These are called \"Flow collections\"." -msgstr "以下は「フローコレクション」と呼ばれます。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:75 -msgid "Ansible doesn't really use these too much, but you can also specify a boolean value (true/false) in several forms::" -msgstr "Ansible では以下の形式はあまり使用されませんが、ブール型値 (True/False) を複数の形式で指定することもできます::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:83 -msgid "Use lowercase 'true' or 'false' for boolean values in dictionaries if you want to be compatible with default yamllint options." -msgstr "デフォルトの yamllint オプションと互換性を持たせる場合は、ディクショナリーのブール値に小文字の「true」または「false」を使用します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:85 -msgid "Values can span multiple lines using ``|`` or ``>``. Spanning multiple lines using a \"Literal Block Scalar\" ``|`` will include the newlines and any trailing spaces. Using a \"Folded Block Scalar\" ``>`` will fold newlines to spaces; it's used to make what would otherwise be a very long line easier to read and edit. In either case the indentation will be ignored. Examples are::" -msgstr "値は、``|`` または ``>`` を使用することで複数の行にまたがって指定することができます。「リテラル形式のブロックスカラー」``|`` を使用して複数行にまたがる場合は、改行と末尾のスペースが含まれます。「折り畳み形式のブロックスカラー」``>`` を使用すると、折り返しに使用される改行はすべてスペースに変換されます。これは、非常に長い行を読みやすく、編集しやすくするために使われます。いずれの場合も、インデントは無視されます。以下に例を示します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:100 -msgid "While in the above ``>`` example all newlines are folded into spaces, there are two ways to enforce a newline to be kept::" -msgstr "上記の ``>`` の例では、改行はすべてスペースに変換されますが、強制的に改行を行う方法が 2 種類あります。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:112 -msgid "Let's combine what we learned so far in an arbitrary YAML example. This really has nothing to do with Ansible, but will give you a feel for the format::" -msgstr "これまでに説明した内容を、任意の YAML の例にまとめてみましょう。以下は、Ansible とは関係ありませんが、どのような形式になるかを示しています::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:135 -msgid "That's all you really need to know about YAML to start writing `Ansible` playbooks." -msgstr "`Ansible` Playbook の記述を開始するにあたり、以上が YAML について理解しておく必要のある内容です。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:138 -msgid "Gotchas" -msgstr "Gotchas" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:140 -msgid "While you can put just about anything into an unquoted scalar, there are some exceptions. A colon followed by a space (or newline) ``\": \"`` is an indicator for a mapping. A space followed by the pound sign ``\" #\"`` starts a comment." -msgstr "引用符で囲まれていないスカラーには何でも挿入できますが、一部例外があります。コロンの後にスペース (または改行) を続けて記述 (``\": \"``) した場合は、マッピングを示すインジケーターになります。スペースに続けてポンド記号を記述 (``\" #\"``) した場合は、コメントの開始を表します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:144 -msgid "Because of this, the following is going to result in a YAML syntax error::" -msgstr "このため、以下のような場合には、YAML 構文がエラーになります。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:150 -msgid "...but this will work::" -msgstr "...ただし、以下は有効します::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:154 -msgid "You will want to quote hash values using colons followed by a space or the end of the line::" -msgstr "コロンを使用してハッシュ記号を引用し、その後ろにスペースを指定するか、行末にしてください::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:160 -msgid "...and then the colon will be preserved." -msgstr "...そしてコロンが保存されます。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:162 -msgid "Alternatively, you can use double quotes::" -msgstr "または、二重引用符を使用してください。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:168 -msgid "The difference between single quotes and double quotes is that in double quotes you can use escapes::" -msgstr "二重引用符ではエスケープを使用できる点が、一重引用符と二重引用符との相違点です::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:173 -msgid "The list of allowed escapes can be found in the YAML Specification under \"Escape Sequences\" (YAML 1.1) or \"Escape Characters\" (YAML 1.2)." -msgstr "使用可能なエスケープの一覧は、YAML 仕様の「Escape Sequences」(YAML 1.1) または「Escape Characters」(YAML 1.2) を参照してください。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:175 -msgid "The following is invalid YAML:" -msgstr "以下は無効な YAML です。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:182 -msgid "Further, Ansible uses \"{{ var }}\" for variables. If a value after a colon starts with a \"{\", YAML will think it is a dictionary, so you must quote it, like so::" -msgstr "さらに、Ansible は変数に \"{{ var }}\" を使用します。コロンの後に \"{\" が指定されている場合は、その値がディクショナリーであると YAML が認識するため、以下のように引用する必要があります::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:187 -msgid "If your value starts with a quote the entire value must be quoted, not just part of it. Here are some additional examples of how to properly quote things::" -msgstr "値を引用符でする場合は、値の一部だけでなく、値全体を引用符で囲む必要があります。値を引用する方法について正しい例を以下に示します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:193 -msgid "Not valid::" -msgstr "以下は有効ではありません::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:197 -msgid "In addition to ``'`` and ``\"`` there are a number of characters that are special (or reserved) and cannot be used as the first character of an unquoted scalar: ``[] {} > | * & ! % # ` @ ,``." -msgstr "``'`` および ``\"`` 以外に、引用符で囲まれていないスカラーの最初の文字として使用できない特殊文字 (予約文字) がいくつかあります (``[] {} > | * & ! % # ` @ ,`` など)。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:200 -msgid "You should also be aware of ``? : -``. In YAML, they are allowed at the beginning of a string if a non-space character follows, but YAML processor implementations differ, so it's better to use quotes." -msgstr "また、``? : -`` には常に注意してください。YAML では、スペース以外の文字が続く場合は、文字列の先頭で許可されますが、YAML プロセッサーの実装は異なるため、引用符を使用することが推奨されます。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:203 -msgid "In Flow Collections, the rules are a bit more strict::" -msgstr "フローコレクションでは、ルールはもう少し厳密です::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:209 -msgid "Boolean conversion is helpful, but this can be a problem when you want a literal `yes` or other boolean values as a string. In these cases just use quotes::" -msgstr "ブール値の変換は便利ですが、リテラルの `yes` や、文字列として他のブール値を指定する場合など問題になる場合があります。この場合は、引用符だけを使用します::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:216 -msgid "YAML converts certain strings into floating-point values, such as the string `1.0`. If you need to specify a version number (in a requirements.yml file, for example), you will need to quote the value if it looks like a floating-point value::" -msgstr "YAML は、特定の文字列を文字列 `1.0` などの浮動小数点値に変換します。(たとえば requirements.yml ファイルで) バージョン番号を指定する必要があり、それが浮動小数点の値のように見える場合は、その値を引用符で囲む必要があります。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:226 -#: ../../rst/reference_appendices/faq.rst:774 -#: ../../rst/reference_appendices/glossary.rst:521 -#: ../../rst/reference_appendices/test_strategies.rst:267 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:227 -msgid "Learn what playbooks can do and how to write/run them." -msgstr "Playbook でできることと、Playbook を記述および実行する方法を学びます。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:228 -msgid "`YAMLLint `_" -msgstr "`YAMLLint `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:229 -msgid "YAML Lint (online) helps you debug YAML syntax if you are having problems" -msgstr "YAML ヒント (オンライン) は、問題が発生した場合に YAML 構文のデバッグに役立ちます。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:230 -msgid "`GitHub examples directory `_" -msgstr "`GitHub examples ディレクトリー `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:231 -msgid "Complete playbook files from the github project source" -msgstr "Github プロジェクトソースの完全な Playbook ファイル" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:232 -msgid "`Wikipedia YAML syntax reference `_" -msgstr "`Wikipedia YAML 構文リファレンス `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:233 -msgid "A good guide to YAML syntax" -msgstr "YAML 構文の適切なガイド" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:234 -msgid "`Mailing List `_" -msgstr "`メーリングリスト `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:235 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:236 -#: ../../rst/reference_appendices/common_return_values.rst:250 -#: ../../rst/reference_appendices/faq.rst:780 -#: ../../rst/reference_appendices/glossary.rst:527 -#: ../../rst/reference_appendices/release_and_maintenance.rst:218 -#: ../../rst/reference_appendices/test_strategies.rst:273 -msgid "`irc.freenode.net `_" -msgstr "`irc.freenode.net `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:237 -msgid "#ansible IRC chat channel and #yaml for YAML specific questions" -msgstr "IRC チャットチャンネル (#Ansible) および YAML 固有の質問 (#yaml)" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:239 -msgid "`YAML 1.1 Specification `_" -msgstr "`YAML 1.1 仕様 `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:239 -msgid "The Specification for YAML 1.1, which PyYAML and libyaml are currently implementing" -msgstr "PyYAML および libyaml が現在実装されている YAML 1.1 の仕様" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:241 -msgid "`YAML 1.2 Specification `_" -msgstr "`YAML 1.2 仕様 `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:242 -msgid "For completeness, YAML 1.2 is the successor of 1.1" -msgstr "完全を期すため、YAML 1.2 は 1.1 の後継となります。" - -#: ../../rst/reference_appendices/automationhub.rst:4 -msgid "Ansible Automation Hub" -msgstr "Ansible Automation Hub" - -#: ../../rst/reference_appendices/automationhub.rst:6 -msgid "`Ansible Automation Hub `_ is the official location to discover and download supported :ref:`collections `, included as part of an Ansible Automation Platform subscription. These content collections contain modules, plugins, roles, and playbooks in a downloadable package." -msgstr "`Ansible Automation Hub `_ は、Ansible Platform サブスクリプションに同梱される、サポート対象の :ref:`コレクション ` を検出してダウンロードする公式の場所です。このようなコンテンツコレクションでは、ダウンロード可能なパッケージにモジュール、プラグイン、ロール、Playbook が含まれます。" - -#: ../../rst/reference_appendices/automationhub.rst:8 -msgid "Ansible Automation Hub gives you direct access to trusted content collections from Red Hat and Certified Partners. You can find content by topic or Ansible Partner organizations." -msgstr "Ansible Automation Hub を使用すると、Red Hat および認定パートナーから、信頼できるコンテンツコレクションに直接アクセスできます。コンテンツは、トピック別または Ansible パートナー組織別に検索できます。" - -#: ../../rst/reference_appendices/automationhub.rst:10 -msgid "Ansible Automation Hub is the downstream Red Hat supported product version of Ansible Galaxy. Find out more about Ansible Automation Hub features and how to access it at `Ansible Automation Hub `_. Ansible Automation Hub is part of the Red Hat Ansible Automation Platform subscription, and comes bundled with support from Red Hat, Inc." -msgstr "Ansible Automation Hub は、Red Hat がサポートする Ansible Galaxy の製品バージョン (ダウンストリーム) です。Ansible Automation Hub の機能とそのアクセス方法の詳細は、「`Ansible Automation Hub `_」を参照してください。Ansible Automation Hub は、Red Hat Ansible Automation Platform サブスクリプションで利用でき、Red Hat, Inc のサポートが含まれています。" - -#: ../../rst/reference_appendices/common_return_values.rst:4 -msgid "Return Values" -msgstr "戻り値" - -#: ../../rst/reference_appendices/common_return_values.rst:6 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/reference_appendices/common_return_values.rst:8 -msgid "Ansible modules normally return a data structure that can be registered into a variable, or seen directly when output by the `ansible` program. Each module can optionally document its own unique return values (visible through ansible-doc and on the :ref:`main docsite`)." -msgstr "Ansible のモジュールは通常、データ構造を返します。このデータ構造は、変数に登録したり、`ansible` プログラムで出力されたときに直接確認したりできます。各モジュールは任意で、独自の戻り値をドキュメント化できます (ansible-doc や :ref:`メインのドキュメントサイト` で確認できます)。" - -#: ../../rst/reference_appendices/common_return_values.rst:11 -msgid "This document covers return values common to all modules." -msgstr "本ガイドでは、全モジュールに共通する戻り値を説明します。" - -#: ../../rst/reference_appendices/common_return_values.rst:13 -msgid "Some of these keys might be set by Ansible itself once it processes the module's return information." -msgstr "モジュールの戻り値情報の処理が終わると、Ansible によりこのキーの一部が設定される場合があります。" - -#: ../../rst/reference_appendices/common_return_values.rst:17 -msgid "Common" -msgstr "共通" - -#: ../../rst/reference_appendices/common_return_values.rst:20 -msgid "backup_file" -msgstr "backup_file" - -#: ../../rst/reference_appendices/common_return_values.rst:21 -msgid "For those modules that implement `backup=no|yes` when manipulating files, a path to the backup file created." -msgstr "ファイルを操作するときに `backup=no|yes` を実装するモジュール向け。作成したバックアップファイルへのパス。" - -#: ../../rst/reference_appendices/common_return_values.rst:29 -#: ../../rst/reference_appendices/config.rst:492 -msgid "changed" -msgstr "changed" - -#: ../../rst/reference_appendices/common_return_values.rst:30 -msgid "A boolean indicating if the task had to make changes to the target or delegated host." -msgstr "タスクがターゲットまたは委任されたホストに変更を加える必要があるかどうかを示すブール値。" - -#: ../../rst/reference_appendices/common_return_values.rst:37 -#: ../../rst/reference_appendices/playbooks_keywords.rst:62 -#: ../../rst/reference_appendices/playbooks_keywords.rst:205 -#: ../../rst/reference_appendices/playbooks_keywords.rst:303 -#: ../../rst/reference_appendices/playbooks_keywords.rst:416 -msgid "diff" -msgstr "diff" - -#: ../../rst/reference_appendices/common_return_values.rst:38 -msgid "Information on differences between the previous and current state. Often a dictionary with entries ``before`` and ``after``, which will then be formatted by the callback plugin to a diff view." -msgstr "直前と現在の状態の相違点に関する情報。通常、``before`` と ``after`` のエントリーが含まれるディクショナリーを指し、callback プラグインによって、このディクショナリーが相違点のビュー書式に整えられます。" - -#: ../../rst/reference_appendices/common_return_values.rst:55 -msgid "failed" -msgstr "failed" - -#: ../../rst/reference_appendices/common_return_values.rst:56 -msgid "A boolean that indicates if the task was failed or not." -msgstr "タスクが失敗したかどうかを示すブール値。" - -#: ../../rst/reference_appendices/common_return_values.rst:63 -msgid "invocation" -msgstr "invocation" - -#: ../../rst/reference_appendices/common_return_values.rst:64 -msgid "Information on how the module was invoked." -msgstr "モジュールがどのように呼び出されたかを示す情報。" - -#: ../../rst/reference_appendices/common_return_values.rst:96 -msgid "msg" -msgstr "msg" - -#: ../../rst/reference_appendices/common_return_values.rst:97 -msgid "A string with a generic message relayed to the user." -msgstr "ユーザーに渡される一般的なメッセージを含む文字列。" - -#: ../../rst/reference_appendices/common_return_values.rst:104 -msgid "rc" -msgstr "rc" - -#: ../../rst/reference_appendices/common_return_values.rst:105 -msgid "Some modules execute command line utilities or are geared for executing commands directly (raw, shell, command, and so on), this field contains 'return code' of these utilities." -msgstr "コマンドラインユーティリティーを実行したり、(raw、shell、command など) 直接コマンドを実行するように設定されているモジュール。このフィールドにはこのようなユーティリティーの「戻りコード」が含まれます。" - -#: ../../rst/reference_appendices/common_return_values.rst:112 -msgid "results" -msgstr "results" - -#: ../../rst/reference_appendices/common_return_values.rst:113 -msgid "If this key exists, it indicates that a loop was present for the task and that it contains a list of the normal module 'result' per item." -msgstr "このキーが存在する場合には、タスクに対してループが存在し、アイテムごとに通常のモジュールの「結果」が含まれていることを示します。" - -#: ../../rst/reference_appendices/common_return_values.rst:175 -msgid "skipped" -msgstr "skipped" - -#: ../../rst/reference_appendices/common_return_values.rst:176 -msgid "A boolean that indicates if the task was skipped or not" -msgstr "タスクがスキップされたかどうかを示すブール値。" - -#: ../../rst/reference_appendices/common_return_values.rst:183 -msgid "stderr" -msgstr "stderr" - -#: ../../rst/reference_appendices/common_return_values.rst:184 -msgid "Some modules execute command line utilities or are geared for executing commands directly (raw, shell, command, and so on), this field contains the error output of these utilities." -msgstr "コマンドラインユーティリティーを実行したり、(raw、shell、command などの) コマンドを直接実行するように調整されているモジュール。このフィールドにはこのようなユーティリティーのエラー出力が含まれます。" - -#: ../../rst/reference_appendices/common_return_values.rst:191 -msgid "stderr_lines" -msgstr "stderr_lines" - -#: ../../rst/reference_appendices/common_return_values.rst:192 -msgid "When `stderr` is returned we also always provide this field which is a list of strings, one item per line from the original." -msgstr "`stderr` が返されると、文字列のリストであるこのフィールドも常に表示されます (元の出力の 1 行に 1 項目)。" - -#: ../../rst/reference_appendices/common_return_values.rst:201 -msgid "stdout" -msgstr "stdout" - -#: ../../rst/reference_appendices/common_return_values.rst:202 -msgid "Some modules execute command line utilities or are geared for executing commands directly (raw, shell, command, and so on). This field contains the normal output of these utilities." -msgstr "コマンドラインユーティリティーを実行したり、(raw、shell、command などの) コマンドを直接実行するように調整されているモジュール。このフィールドにはこのようなユーティリティーの通常出力が含まれます。" - -#: ../../rst/reference_appendices/common_return_values.rst:209 -msgid "stdout_lines" -msgstr "stdout_lines" - -#: ../../rst/reference_appendices/common_return_values.rst:210 -msgid "When `stdout` is returned, Ansible always provides a list of strings, each containing one item per line from the original output." -msgstr "`stdout` が返されると、Ansible は常に文字列のリスト (元の出力の 1 行に項目を 1 つ含める) を渡します。" - -#: ../../rst/reference_appendices/common_return_values.rst:222 -msgid "Internal use" -msgstr "Ansible 内での使用" - -#: ../../rst/reference_appendices/common_return_values.rst:224 -msgid "These keys can be added by modules but will be removed from registered variables; they are 'consumed' by Ansible itself." -msgstr "以下のキーはモジュールで追加できますが、登録変数からは削除されます。これらのキーは、Ansible 自体が「使用」します。" - -#: ../../rst/reference_appendices/common_return_values.rst:227 -#: ../../rst/reference_appendices/config.rst:342 -#: ../../rst/reference_appendices/config.rst:2483 -#: ../../rst/reference_appendices/special_variables.rst:139 -msgid "ansible_facts" -msgstr "ansible_facts" - -#: ../../rst/reference_appendices/common_return_values.rst:228 -msgid "This key should contain a dictionary which will be appended to the facts assigned to the host. These will be directly accessible and don't require using a registered variable." -msgstr "このキーには、ホストに割り当てられたファクトに追加するディクショナリーが含まれているはずです。このキーは、直接アクセスでき、登録変数を使用する必要はありません。" - -#: ../../rst/reference_appendices/common_return_values.rst:231 -msgid "exception" -msgstr "exception" - -#: ../../rst/reference_appendices/common_return_values.rst:232 -msgid "This key can contain traceback information caused by an exception in a module. It will only be displayed on high verbosity (-vvv)." -msgstr "このキーには、モジュールの例外で発生したトレースバックの情報が含まれます。これは、詳細レベルが高い (-vvv) 場合に限り表示されます。" - -#: ../../rst/reference_appendices/common_return_values.rst:235 -msgid "warnings" -msgstr "warnings" - -#: ../../rst/reference_appendices/common_return_values.rst:236 -msgid "This key contains a list of strings that will be presented to the user." -msgstr "このキーには、ユーザーに表示される文字列の一覧が含まれます。" - -#: ../../rst/reference_appendices/common_return_values.rst:239 -msgid "deprecations" -msgstr "deprecations" - -#: ../../rst/reference_appendices/common_return_values.rst:240 -msgid "This key contains a list of dictionaries that will be presented to the user. Keys of the dictionaries are `msg` and `version`, values are string, value for the `version` key can be an empty string." -msgstr "このキーには、ユーザーに表示されるディクショナリー一覧が含まれます。ディクショナリーのキーは `msg` と `version` で、値は文字列です。`version` キーの値は空白の文字列にすることができます。" - -#: ../../rst/reference_appendices/common_return_values.rst:244 -#: ../../rst/reference_appendices/test_strategies.rst:265 -msgid ":ref:`list_of_collections`" -msgstr ":ref:`list_of_collections`" - -#: ../../rst/reference_appendices/common_return_values.rst:245 -#: ../../rst/reference_appendices/test_strategies.rst:266 -msgid "Browse existing collections, modules, and plugins" -msgstr "既存のコレクション、モジュール、およびプラグインの閲覧" - -#: ../../rst/reference_appendices/common_return_values.rst:246 -msgid "`GitHub modules directory `_" -msgstr "`GitHub モジュールディレクトリー `_" - -#: ../../rst/reference_appendices/common_return_values.rst:247 -msgid "Browse source of core and extras modules" -msgstr "コアモジュールおよび追加モジュールのソースの参照" - -#: ../../rst/reference_appendices/common_return_values.rst:248 -msgid "`Mailing List `_" -msgstr "`メーリングリスト`_" - -#: ../../rst/reference_appendices/common_return_values.rst:249 -msgid "Development mailing list" -msgstr "開発メーリングリスト" - -#: ../../rst/reference_appendices/common_return_values.rst:251 -#: ../../rst/reference_appendices/faq.rst:781 -#: ../../rst/reference_appendices/glossary.rst:528 -#: ../../rst/reference_appendices/release_and_maintenance.rst:219 -#: ../../rst/reference_appendices/test_strategies.rst:274 -msgid "#ansible IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible)" - -#: ../../rst/reference_appendices/config.rst:5 -msgid "Ansible Configuration Settings" -msgstr "Ansible 構成設定" - -#: ../../rst/reference_appendices/config.rst:7 -msgid "Ansible supports several sources for configuring its behavior, including an ini file named ``ansible.cfg``, environment variables, command-line options, playbook keywords, and variables. See :ref:`general_precedence_rules` for details on the relative precedence of each source." -msgstr "Ansible は、``ansible.cfg`` という名前の ini ファイル、環境変数、コマンドラインオプション、Playbook のキーワード、変数など、動作を設定するための複数のソースをサポートします。各ソースの相対優先順位に関する詳細は「:ref:`general_precedence_rules`」を参照してください。" - -#: ../../rst/reference_appendices/config.rst:9 -msgid "The ``ansible-config`` utility allows users to see all the configuration settings available, their defaults, how to set them and where their current value comes from. See :ref:`ansible-config` for more information." -msgstr "``ansible-config`` ユーティリティーを使用すると、ユーザーは利用可能なすべての構成設定、デフォルト値、設定方法、および現在の値を受け取る場所を確認できます。詳細は「:ref:`ansible-config`」を参照してください。" - -#: ../../rst/reference_appendices/config.rst:15 -msgid "The configuration file" -msgstr "設定ファイル" - -#: ../../rst/reference_appendices/config.rst:17 -msgid "Changes can be made and used in a configuration file which will be searched for in the following order:" -msgstr "変更を行い、次の順序で検索される構成ファイルで使用できます。" - -#: ../../rst/reference_appendices/config.rst:19 -#: ../../rst/reference_appendices/general_precedence.rst:34 -msgid "``ANSIBLE_CONFIG`` (environment variable if set)" -msgstr "``ANSIBLE_CONFIG`` (設定されている場合は環境変数メソッド)" - -#: ../../rst/reference_appendices/config.rst:20 -#: ../../rst/reference_appendices/general_precedence.rst:35 -msgid "``ansible.cfg`` (in the current directory)" -msgstr "``ansible.cfg`` (現在のディレクトリー)" - -#: ../../rst/reference_appendices/config.rst:21 -#: ../../rst/reference_appendices/general_precedence.rst:36 -msgid "``~/.ansible.cfg`` (in the home directory)" -msgstr "``~/.ansible.cfg`` (ホームディレクトリー)" - -#: ../../rst/reference_appendices/config.rst:22 -#: ../../rst/reference_appendices/general_precedence.rst:37 -msgid "``/etc/ansible/ansible.cfg``" -msgstr "``/etc/ansible/ansible.cfg``" - -#: ../../rst/reference_appendices/config.rst:24 -msgid "Ansible will process the above list and use the first file found, all others are ignored." -msgstr "Ansible は上記の一覧を処理し、見つかった最初のファイルを使用しますが、その他はすべて無視されます。" - -#: ../../rst/reference_appendices/config.rst:28 -msgid "The configuration file is one variant of an INI format. Both the hash sign (``#``) and semicolon (``;``) are allowed as comment markers when the comment starts the line. However, if the comment is inline with regular values, only the semicolon is allowed to introduce the comment. For instance::" -msgstr "設定ファイルは、INI 形式の 1 つのバリアントです。コメントが行を開始する場合は、ハッシュ記号 (``#``) とセミコロン (``;``) の両方がコメントマーカーとして許可されます。ただし、コメントが通常の値でインラインである場合は、セミコロンだけがコメントを追加できます。以下に例を示します。" - -#: ../../rst/reference_appendices/config.rst:42 -msgid "Avoiding security risks with ``ansible.cfg`` in the current directory" -msgstr "現行ディレクトリーで ``ansible.cfg`` を使用したセキュリティーリスクを回避" - -#: ../../rst/reference_appendices/config.rst:45 -msgid "If Ansible were to load ``ansible.cfg`` from a world-writable current working directory, it would create a serious security risk. Another user could place their own config file there, designed to make Ansible run malicious code both locally and remotely, possibly with elevated privileges. For this reason, Ansible will not automatically load a config file from the current working directory if the directory is world-writable." -msgstr "Ansible が、グローバルで書き込み可能な現在の作業ディレクトリーから ``ansible.cfg`` を読み込んだ場合は、深刻なセキュリティーリスクが発生します。別のユーザーが、場合により昇格した権限で Ansible がローカルとリモートの両方で悪意のあるコードを実行するように設計された独自の構成ファイルをそこに配置できます。そのため、ディレクトリーが誰でも書き込み可能な状態である場合、Ansible は現在の作業ディレクトリーから設定ファイルを自動的に読み込みません。" - -#: ../../rst/reference_appendices/config.rst:52 -msgid "If you depend on using Ansible with a config file in the current working directory, the best way to avoid this problem is to restrict access to your Ansible directories to particular user(s) and/or group(s). If your Ansible directories live on a filesystem which has to emulate Unix permissions, like Vagrant or Windows Subsystem for Linux (WSL), you may, at first, not know how you can fix this as ``chmod``, ``chown``, and ``chgrp`` might not work there. In most of those cases, the correct fix is to modify the mount options of the filesystem so the files and directories are readable and writable by the users and groups running Ansible but closed to others. For more details on the correct settings, see:" -msgstr "現在の作業ディレクトリーの設定ファイルで Ansible を使用する場合、この問題を回避する最善の方法は、Ansible ディレクトリーへのアクセスを特定のユーザーやグループに制限することです。Ansible ディレクトリーが、Vagrant や Windows Subsystem for Linux (WSL) などの Unix パーミッションをエミュレートする必要があるファイルシステムに存在する場合、そこでは ``chmod``、``chown``、および ``chgrp`` が機能しない可能性があるため、最初はどのように修正するか分からない場合があります。ほとんどの場合は、適切な修正が、ファイルシステムのマウントオプションを修正することです。これにより、ファイルおよびディレクトリーは、Ansible を実行しているユーザーおよびグループが読み取りおよび書き込みをできるようになり、他のユーザーには許可しないようにすることができます。正しい設定の詳細は、以下を参照してください。" - -#: ../../rst/reference_appendices/config.rst:63 -msgid "for Vagrant, the `Vagrant documentation `_ covers synced folder permissions." -msgstr "Vagrant の場合、`Vagrant documentation `_ は同期されたフォルダーのパーミッションに対応します。" - -#: ../../rst/reference_appendices/config.rst:64 -msgid "for WSL, the `WSL docs `_ and this `Microsoft blog post `_ cover mount options." -msgstr "WSL の場合、`WSL docs `_ とこの `Microsoft blog post `_ はマウントオプションに対応しています。" - -#: ../../rst/reference_appendices/config.rst:67 -msgid "If you absolutely depend on storing your Ansible config in a world-writable current working directory, you can explicitly specify the config file via the :envvar:`ANSIBLE_CONFIG` environment variable. Please take appropriate steps to mitigate the security concerns above before doing so." -msgstr "誰でも書き込み可能な現在の作業ディレクトリーに Ansible 設定を保存することを完全に依存している場合は、:envvar:`ANSIBLE_CONFIG` 環境変数を介して設定ファイルを明示的に指定できます。セキュリティーに関する懸念を軽減するための適切な手順を実行してください。" - -#: ../../rst/reference_appendices/config.rst:74 -msgid "Relative paths for configuration" -msgstr "設定の相対パス" - -#: ../../rst/reference_appendices/config.rst:76 -msgid "You can specify a relative path for many configuration options. In most of those cases the path used will be relative to the ``ansible.cfg`` file used for the current execution. If you need a path relative to your current working directory (CWD) you can use the ``{{CWD}}`` macro to specify it. We do not recommend this approach, as using your CWD as the root of relative paths can be a security risk. For example: ``cd /tmp; secureinfo=./newrootpassword ansible-playbook ~/safestuff/change_root_pwd.yml``." -msgstr "多くの設定オプションに相対パスを指定できます。ほとんどの場合、使用されるパスは、現在の実行に使用される ``ansible.cfg`` ファイルの相対パスになります。現在の作業ディレクトリー (CWD) への相対パスが必要な場合は、``{{CWD}}`` マクロを使用して指定できます。相対パスのルートとして CWD を使用するとセキュリティーリスクが発生する可能性があるため、この方法は推奨されません。たとえば、``cd /tmp; secureinfo=./newrootpassword ansible-playbook ~/safestuff/change_root_pwd.yml`` となります。" - -#: ../../rst/reference_appendices/config.rst:86 -msgid "Common Options" -msgstr "共通オプション" - -#: ../../rst/reference_appendices/config.rst:88 -msgid "This is a copy of the options available from our release, your local install might have extra options due to additional plugins, you can use the command line utility mentioned above (`ansible-config`) to browse through those." -msgstr "これは、リリースで利用可能なオプションのコピーで、追加プラグインにより、ローカルインストールに追加のオプションが存在する可能性があります。上記のコマンドラインユーティリティー (`ansible-config`) を使用して、これらを閲覧することができます。" - -#: ../../rst/reference_appendices/config.rst:96 -msgid "ACTION_WARNINGS" -msgstr "ACTION_WARNINGS" - -#: ../../rst/reference_appendices/config.rst -msgid "Description" -msgstr "説明" - -#: ../../rst/reference_appendices/config.rst:98 -msgid "By default Ansible will issue a warning when received from a task action (module or action plugin) These warnings can be silenced by adjusting this setting to False." -msgstr "デフォルトでは、Ansible はタスクアクション (モジュールまたは action プラグイン) から受け取ると、警告を False に調整することで警告を非表示にすることができます。" - -#: ../../rst/reference_appendices/config.rst -msgid "Type" -msgstr "タイプ" - -#: ../../rst/reference_appendices/config.rst:99 -#: ../../rst/reference_appendices/config.rst:114 -#: ../../rst/reference_appendices/config.rst:129 -#: ../../rst/reference_appendices/config.rst:212 -#: ../../rst/reference_appendices/config.rst:226 -#: ../../rst/reference_appendices/config.rst:242 -#: ../../rst/reference_appendices/config.rst:256 -#: ../../rst/reference_appendices/config.rst:272 -#: ../../rst/reference_appendices/config.rst:287 -#: ../../rst/reference_appendices/config.rst:455 -#: ../../rst/reference_appendices/config.rst:932 -#: ../../rst/reference_appendices/config.rst:949 -#: ../../rst/reference_appendices/config.rst:978 -#: ../../rst/reference_appendices/config.rst:1031 -#: ../../rst/reference_appendices/config.rst:1044 -#: ../../rst/reference_appendices/config.rst:1058 -#: ../../rst/reference_appendices/config.rst:1072 -#: ../../rst/reference_appendices/config.rst:1086 -#: ../../rst/reference_appendices/config.rst:1208 -#: ../../rst/reference_appendices/config.rst:1263 -#: ../../rst/reference_appendices/config.rst:1339 -#: ../../rst/reference_appendices/config.rst:1441 -#: ../../rst/reference_appendices/config.rst:1456 -#: ../../rst/reference_appendices/config.rst:1470 -#: ../../rst/reference_appendices/config.rst:1489 -#: ../../rst/reference_appendices/config.rst:1648 -#: ../../rst/reference_appendices/config.rst:1662 -#: ../../rst/reference_appendices/config.rst:1721 -#: ../../rst/reference_appendices/config.rst:1832 -#: ../../rst/reference_appendices/config.rst:1859 -#: ../../rst/reference_appendices/config.rst:1932 -#: ../../rst/reference_appendices/config.rst:2042 -#: ../../rst/reference_appendices/config.rst:2056 -#: ../../rst/reference_appendices/config.rst:2098 -#: ../../rst/reference_appendices/config.rst:2113 -#: ../../rst/reference_appendices/config.rst:2176 -#: ../../rst/reference_appendices/config.rst:2191 -#: ../../rst/reference_appendices/config.rst:2251 -#: ../../rst/reference_appendices/config.rst:2335 -#: ../../rst/reference_appendices/config.rst:2367 -#: ../../rst/reference_appendices/config.rst:2414 -#: ../../rst/reference_appendices/config.rst:2430 -#: ../../rst/reference_appendices/config.rst:2584 -#: ../../rst/reference_appendices/config.rst:2657 -#: ../../rst/reference_appendices/config.rst:2671 -#: ../../rst/reference_appendices/config.rst:2684 -#: ../../rst/reference_appendices/config.rst:2909 -#: ../../rst/reference_appendices/config.rst:2953 -#: ../../rst/reference_appendices/config.rst:3003 -msgid "boolean" -msgstr "boolean" - -#: ../../rst/reference_appendices/config.rst -msgid "Default" -msgstr "デフォルト" - -#: ../../rst/reference_appendices/config.rst:100 -#: ../../rst/reference_appendices/config.rst:115 -#: ../../rst/reference_appendices/config.rst:456 -#: ../../rst/reference_appendices/config.rst:979 -#: ../../rst/reference_appendices/config.rst:1933 -#: ../../rst/reference_appendices/config.rst:2043 -#: ../../rst/reference_appendices/config.rst:2057 -#: ../../rst/reference_appendices/config.rst:2114 -#: ../../rst/reference_appendices/config.rst:2192 -#: ../../rst/reference_appendices/config.rst:2336 -#: ../../rst/reference_appendices/config.rst:2368 -#: ../../rst/reference_appendices/config.rst:2415 -#: ../../rst/reference_appendices/config.rst:2585 -#: ../../rst/reference_appendices/config.rst:2685 -#: ../../rst/reference_appendices/config.rst:2910 -#: ../../rst/reference_appendices/config.rst:2954 -msgid "True" -msgstr "True" - -#: ../../rst/reference_appendices/config.rst -msgid "Version Added" -msgstr "追加されたバージョン" - -#: ../../rst/reference_appendices/config.rst:101 -#: ../../rst/reference_appendices/config.rst:116 -#: ../../rst/reference_appendices/config.rst:2178 -#: ../../rst/reference_appendices/config.rst:2369 -#: ../../rst/reference_appendices/config.rst:2925 -#: ../../rst/reference_appendices/config.rst:2940 -msgid "2.5" -msgstr "2.5" - -#: ../../rst/reference_appendices/config.rst -msgid "Ini" -msgstr "Ini" - -#: ../../rst/reference_appendices/config.rst -msgid "Section" -msgstr "セクション" - -#: ../../rst/reference_appendices/config.rst:103 -#: ../../rst/reference_appendices/config.rst:133 -#: ../../rst/reference_appendices/config.rst:163 -#: ../../rst/reference_appendices/config.rst:168 -#: ../../rst/reference_appendices/config.rst:188 -#: ../../rst/reference_appendices/config.rst:201 -#: ../../rst/reference_appendices/config.rst:215 -#: ../../rst/reference_appendices/config.rst:229 -#: ../../rst/reference_appendices/config.rst:245 -#: ../../rst/reference_appendices/config.rst:261 -#: ../../rst/reference_appendices/config.rst:276 -#: ../../rst/reference_appendices/config.rst:305 -#: ../../rst/reference_appendices/config.rst:318 -#: ../../rst/reference_appendices/config.rst:331 -#: ../../rst/reference_appendices/config.rst:344 -#: ../../rst/reference_appendices/config.rst:358 -#: ../../rst/reference_appendices/config.rst:372 -#: ../../rst/reference_appendices/config.rst:377 -#: ../../rst/reference_appendices/config.rst:397 -#: ../../rst/reference_appendices/config.rst:402 -#: ../../rst/reference_appendices/config.rst:425 -#: ../../rst/reference_appendices/config.rst:440 -#: ../../rst/reference_appendices/config.rst:442 -#: ../../rst/reference_appendices/config.rst:458 -#: ../../rst/reference_appendices/config.rst:936 -#: ../../rst/reference_appendices/config.rst:953 -#: ../../rst/reference_appendices/config.rst:967 -#: ../../rst/reference_appendices/config.rst:981 -#: ../../rst/reference_appendices/config.rst:1020 -#: ../../rst/reference_appendices/config.rst:1035 -#: ../../rst/reference_appendices/config.rst:1047 -#: ../../rst/reference_appendices/config.rst:1061 -#: ../../rst/reference_appendices/config.rst:1155 -#: ../../rst/reference_appendices/config.rst:1169 -#: ../../rst/reference_appendices/config.rst:1183 -#: ../../rst/reference_appendices/config.rst:1197 -#: ../../rst/reference_appendices/config.rst:1211 -#: ../../rst/reference_appendices/config.rst:1224 -#: ../../rst/reference_appendices/config.rst:1238 -#: ../../rst/reference_appendices/config.rst:1252 -#: ../../rst/reference_appendices/config.rst:1267 -#: ../../rst/reference_appendices/config.rst:1281 -#: ../../rst/reference_appendices/config.rst:1296 -#: ../../rst/reference_appendices/config.rst:1310 -#: ../../rst/reference_appendices/config.rst:1328 -#: ../../rst/reference_appendices/config.rst:1342 -#: ../../rst/reference_appendices/config.rst:1362 -#: ../../rst/reference_appendices/config.rst:1376 -#: ../../rst/reference_appendices/config.rst:1390 -#: ../../rst/reference_appendices/config.rst:1405 -#: ../../rst/reference_appendices/config.rst:1417 -#: ../../rst/reference_appendices/config.rst:1430 -#: ../../rst/reference_appendices/config.rst:1445 -#: ../../rst/reference_appendices/config.rst:1459 -#: ../../rst/reference_appendices/config.rst:1493 -#: ../../rst/reference_appendices/config.rst:1507 -#: ../../rst/reference_appendices/config.rst:1521 -#: ../../rst/reference_appendices/config.rst:1535 -#: ../../rst/reference_appendices/config.rst:1549 -#: ../../rst/reference_appendices/config.rst:1562 -#: ../../rst/reference_appendices/config.rst:1573 -#: ../../rst/reference_appendices/config.rst:1586 -#: ../../rst/reference_appendices/config.rst:1597 -#: ../../rst/reference_appendices/config.rst:1609 -#: ../../rst/reference_appendices/config.rst:1623 -#: ../../rst/reference_appendices/config.rst:1637 -#: ../../rst/reference_appendices/config.rst:1651 -#: ../../rst/reference_appendices/config.rst:1665 -#: ../../rst/reference_appendices/config.rst:1682 -#: ../../rst/reference_appendices/config.rst:1696 -#: ../../rst/reference_appendices/config.rst:1710 -#: ../../rst/reference_appendices/config.rst:1724 -#: ../../rst/reference_appendices/config.rst:1738 -#: ../../rst/reference_appendices/config.rst:1751 -#: ../../rst/reference_appendices/config.rst:1765 -#: ../../rst/reference_appendices/config.rst:1793 -#: ../../rst/reference_appendices/config.rst:1807 -#: ../../rst/reference_appendices/config.rst:1821 -#: ../../rst/reference_appendices/config.rst:1835 -#: ../../rst/reference_appendices/config.rst:1848 -#: ../../rst/reference_appendices/config.rst:1863 -#: ../../rst/reference_appendices/config.rst:1880 -#: ../../rst/reference_appendices/config.rst:1894 -#: ../../rst/reference_appendices/config.rst:1908 -#: ../../rst/reference_appendices/config.rst:1921 -#: ../../rst/reference_appendices/config.rst:1936 -#: ../../rst/reference_appendices/config.rst:1950 -#: ../../rst/reference_appendices/config.rst:1963 -#: ../../rst/reference_appendices/config.rst:1976 -#: ../../rst/reference_appendices/config.rst:1989 -#: ../../rst/reference_appendices/config.rst:2003 -#: ../../rst/reference_appendices/config.rst:2017 -#: ../../rst/reference_appendices/config.rst:2031 -#: ../../rst/reference_appendices/config.rst:2045 -#: ../../rst/reference_appendices/config.rst:2059 -#: ../../rst/reference_appendices/config.rst:2102 -#: ../../rst/reference_appendices/config.rst:2116 -#: ../../rst/reference_appendices/config.rst:2134 -#: ../../rst/reference_appendices/config.rst:2148 -#: ../../rst/reference_appendices/config.rst:2165 -#: ../../rst/reference_appendices/config.rst:2180 -#: ../../rst/reference_appendices/config.rst:2194 -#: ../../rst/reference_appendices/config.rst:2208 -#: ../../rst/reference_appendices/config.rst:2338 -#: ../../rst/reference_appendices/config.rst:2371 -#: ../../rst/reference_appendices/config.rst:2385 -#: ../../rst/reference_appendices/config.rst:2418 -#: ../../rst/reference_appendices/config.rst:2540 -#: ../../rst/reference_appendices/config.rst:2556 -#: ../../rst/reference_appendices/config.rst:2588 -#: ../../rst/reference_appendices/config.rst:2602 -#: ../../rst/reference_appendices/config.rst:2616 -#: ../../rst/reference_appendices/config.rst:2642 -#: ../../rst/reference_appendices/config.rst:2661 -#: ../../rst/reference_appendices/config.rst:2757 -#: ../../rst/reference_appendices/config.rst:2775 -#: ../../rst/reference_appendices/config.rst:2795 -#: ../../rst/reference_appendices/config.rst:2807 -#: ../../rst/reference_appendices/config.rst:2823 -#: ../../rst/reference_appendices/config.rst:2837 -#: ../../rst/reference_appendices/config.rst:2855 -#: ../../rst/reference_appendices/config.rst:2869 -#: ../../rst/reference_appendices/config.rst:2884 -#: ../../rst/reference_appendices/config.rst:2912 -#: ../../rst/reference_appendices/config.rst:2957 -#: ../../rst/reference_appendices/config.rst:2972 -#: ../../rst/reference_appendices/config.rst:2992 -#: ../../rst/reference_appendices/config.rst:3006 -#: ../../rst/reference_appendices/config.rst:3021 -#: ../../rst/reference_appendices/config.rst:3036 -#: ../../rst/reference_appendices/config.rst:3051 -#: ../../rst/reference_appendices/config.rst:3066 -#: ../../rst/reference_appendices/config.rst:3106 -msgid "[defaults]" -msgstr "[defaults]" - -#: ../../rst/reference_appendices/config.rst -msgid "Key" -msgstr "キー" - -#: ../../rst/reference_appendices/config.rst:104 -msgid "action_warnings" -msgstr "action_warnings" - -#: ../../rst/reference_appendices/config.rst -msgid "Environment" -msgstr "環境" - -#: ../../rst/reference_appendices/config.rst -msgid "Variable" -msgstr "変数" - -#: ../../rst/reference_appendices/config.rst:106 -msgid ":envvar:`ANSIBLE_ACTION_WARNINGS`" -msgstr ":envvar:`ANSIBLE_ACTION_WARNINGS`" - -#: ../../rst/reference_appendices/config.rst:111 -msgid "AGNOSTIC_BECOME_PROMPT" -msgstr "AGNOSTIC_BECOME_PROMPT" - -#: ../../rst/reference_appendices/config.rst:113 -#: ../../rst/reference_appendices/config.rst:3223 -msgid "Display an agnostic become prompt instead of displaying a prompt containing the command line supplied become method" -msgstr "become メソッドを提供するコマンドラインを含むプロンプトを表示する代わりに、依存しない become プロンプトを表示します。" - -#: ../../rst/reference_appendices/config.rst:118 -#: ../../rst/reference_appendices/config.rst:290 -#: ../../rst/reference_appendices/config.rst:1075 -#: ../../rst/reference_appendices/config.rst:1089 -#: ../../rst/reference_appendices/config.rst:1102 -#: ../../rst/reference_appendices/config.rst:1115 -#: ../../rst/reference_appendices/config.rst:1128 -#: ../../rst/reference_appendices/config.rst:1141 -msgid "[privilege_escalation]" -msgstr "[privilege_escalation]" - -#: ../../rst/reference_appendices/config.rst:119 -msgid "agnostic_become_prompt" -msgstr "agnostic_become_prompt" - -#: ../../rst/reference_appendices/config.rst:121 -msgid ":envvar:`ANSIBLE_AGNOSTIC_BECOME_PROMPT`" -msgstr ":envvar:`ANSIBLE_AGNOSTIC_BECOME_PROMPT`" - -#: ../../rst/reference_appendices/config.rst:126 -msgid "ALLOW_WORLD_READABLE_TMPFILES" -msgstr "ALLOW_WORLD_READABLE_TMPFILES" - -#: ../../rst/reference_appendices/config.rst:128 -msgid "This makes the temporary files created on the machine world-readable and will issue a warning instead of failing the task. It is useful when becoming an unprivileged user." -msgstr "これにより、マシンで作成された一時ファイルが誰でも読み取り可能になり、タスクが失敗する代わりに警告が表示されます。これは、権限のないユーザーに変わる (become) 場合に役立ちます。" - -#: ../../rst/reference_appendices/config.rst:130 -#: ../../rst/reference_appendices/config.rst:213 -#: ../../rst/reference_appendices/config.rst:227 -#: ../../rst/reference_appendices/config.rst:243 -#: ../../rst/reference_appendices/config.rst:257 -#: ../../rst/reference_appendices/config.rst:273 -#: ../../rst/reference_appendices/config.rst:288 -#: ../../rst/reference_appendices/config.rst:933 -#: ../../rst/reference_appendices/config.rst:950 -#: ../../rst/reference_appendices/config.rst:1032 -#: ../../rst/reference_appendices/config.rst:1045 -#: ../../rst/reference_appendices/config.rst:1059 -#: ../../rst/reference_appendices/config.rst:1073 -#: ../../rst/reference_appendices/config.rst:1087 -#: ../../rst/reference_appendices/config.rst:1209 -#: ../../rst/reference_appendices/config.rst:1264 -#: ../../rst/reference_appendices/config.rst:1340 -#: ../../rst/reference_appendices/config.rst:1442 -#: ../../rst/reference_appendices/config.rst:1457 -#: ../../rst/reference_appendices/config.rst:1471 -#: ../../rst/reference_appendices/config.rst:1490 -#: ../../rst/reference_appendices/config.rst:1649 -#: ../../rst/reference_appendices/config.rst:1663 -#: ../../rst/reference_appendices/config.rst:1722 -#: ../../rst/reference_appendices/config.rst:1833 -#: ../../rst/reference_appendices/config.rst:1860 -#: ../../rst/reference_appendices/config.rst:1974 -#: ../../rst/reference_appendices/config.rst:2071 -#: ../../rst/reference_appendices/config.rst:2099 -#: ../../rst/reference_appendices/config.rst:2177 -#: ../../rst/reference_appendices/config.rst:2252 -#: ../../rst/reference_appendices/config.rst:2431 -#: ../../rst/reference_appendices/config.rst:2446 -#: ../../rst/reference_appendices/config.rst:2524 -#: ../../rst/reference_appendices/config.rst:2571 -#: ../../rst/reference_appendices/config.rst:2658 -#: ../../rst/reference_appendices/config.rst:2672 -#: ../../rst/reference_appendices/config.rst:2821 -#: ../../rst/reference_appendices/config.rst:2867 -#: ../../rst/reference_appendices/config.rst:3004 -#: ../../rst/reference_appendices/config.rst:3048 -msgid "False" -msgstr "False" - -#: ../../rst/reference_appendices/config.rst:131 -#: ../../rst/reference_appendices/config.rst:1294 -#: ../../rst/reference_appendices/config.rst:1472 -#: ../../rst/reference_appendices/config.rst:1861 -#: ../../rst/reference_appendices/config.rst:2100 -msgid "2.1" -msgstr "2.1" - -#: ../../rst/reference_appendices/config.rst:134 -msgid "allow_world_readable_tmpfiles" -msgstr "allow_world_readable_tmpfiles" - -#: ../../rst/reference_appendices/config.rst -msgid "Deprecated in" -msgstr "非推奨になるバージョン" - -#: ../../rst/reference_appendices/config.rst:135 -#: ../../rst/reference_appendices/config.rst:940 -msgid "2.14" -msgstr "2.14" - -#: ../../rst/reference_appendices/config.rst -msgid "Deprecated detail" -msgstr "非推奨の詳細" - -#: ../../rst/reference_appendices/config.rst:136 -msgid "moved to a per plugin approach that is more flexible" -msgstr "より柔軟なプラグインのアプローチへ移行" - -#: ../../rst/reference_appendices/config.rst -msgid "Deprecated alternatives" -msgstr "非推奨の代替手段" - -#: ../../rst/reference_appendices/config.rst:137 -msgid "mostly the same config will work, but now controlled from the plugin itself and not using the general constant." -msgstr "ほとんどの同じ設定は機能しますが、プラグイン自体から制御され、一般的な定数は使用しません。" - -#: ../../rst/reference_appendices/config.rst:142 -msgid "ANSIBLE_CONNECTION_PATH" -msgstr "ANSIBLE_CONNECTION_PATH" - -#: ../../rst/reference_appendices/config.rst:144 -msgid "Specify where to look for the ansible-connection script. This location will be checked before searching $PATH. If null, ansible will start with the same directory as the ansible script." -msgstr "ansible-connection スクリプトを探す場所を指定します。この場所は、$PATH の検索前に確認されます。null に設定すると、Ansible は ansible スクリプトと同じディレクトリーで起動します。" - -#: ../../rst/reference_appendices/config.rst:145 -#: ../../rst/reference_appendices/config.rst:1532 -#: ../../rst/reference_appendices/config.rst:1707 -#: ../../rst/reference_appendices/config.rst:2014 -#: ../../rst/reference_appendices/config.rst:2221 -#: ../../rst/reference_appendices/config.rst:2265 -#: ../../rst/reference_appendices/config.rst:2320 -#: ../../rst/reference_appendices/config.rst:2740 -#: ../../rst/reference_appendices/config.rst:2754 -#: ../../rst/reference_appendices/config.rst:2786 -#: ../../rst/reference_appendices/config.rst:2834 -msgid "path" -msgstr "path" - -#: ../../rst/reference_appendices/config.rst:146 -#: ../../rst/reference_appendices/config.rst:186 -#: ../../rst/reference_appendices/config.rst:329 -#: ../../rst/reference_appendices/config.rst:1100 -#: ../../rst/reference_appendices/config.rst:1236 -#: ../../rst/reference_appendices/config.rst:1533 -#: ../../rst/reference_appendices/config.rst:1680 -#: ../../rst/reference_appendices/config.rst:1708 -#: ../../rst/reference_appendices/config.rst:1736 -#: ../../rst/reference_appendices/config.rst:1749 -#: ../../rst/reference_appendices/config.rst:1961 -#: ../../rst/reference_appendices/config.rst:2015 -#: ../../rst/reference_appendices/config.rst:2237 -#: ../../rst/reference_appendices/config.rst:2266 -#: ../../rst/reference_appendices/config.rst:2627 -#: ../../rst/reference_appendices/config.rst:2787 -#: ../../rst/reference_appendices/config.rst:2835 -msgid "None" -msgstr "なし" - -#: ../../rst/reference_appendices/config.rst:147 -#: ../../rst/reference_appendices/config.rst:303 -#: ../../rst/reference_appendices/config.rst:951 -#: ../../rst/reference_appendices/config.rst:2146 -#: ../../rst/reference_appendices/config.rst:2354 -#: ../../rst/reference_appendices/config.rst:2383 -#: ../../rst/reference_appendices/config.rst:2398 -#: ../../rst/reference_appendices/config.rst:2406 -#: ../../rst/reference_appendices/config.rst:2659 -#: ../../rst/reference_appendices/config.rst:2805 -#: ../../rst/reference_appendices/config.rst:2882 -#: ../../rst/reference_appendices/config.rst:2990 -#: ../../rst/reference_appendices/config.rst:3049 -msgid "2.8" -msgstr "2.8" - -#: ../../rst/reference_appendices/config.rst:149 -#: ../../rst/reference_appendices/config.rst:2701 -#: ../../rst/reference_appendices/config.rst:2715 -#: ../../rst/reference_appendices/config.rst:2729 -#: ../../rst/reference_appendices/config.rst:2743 -msgid "[persistent_connection]" -msgstr "[persistent_connection]" - -#: ../../rst/reference_appendices/config.rst:150 -msgid "ansible_connection_path" -msgstr "ansible_connection_path" - -#: ../../rst/reference_appendices/config.rst:152 -msgid ":envvar:`ANSIBLE_CONNECTION_PATH`" -msgstr ":envvar:`ANSIBLE_CONNECTION_PATH`" - -#: ../../rst/reference_appendices/config.rst:157 -#: ../../rst/reference_appendices/config.rst:177 -#: ../../rst/reference_appendices/config.rst:3146 -msgid "ANSIBLE_COW_ACCEPTLIST" -msgstr "ANSIBLE_COW_ACCEPTLIST" - -#: ../../rst/reference_appendices/config.rst:159 -#: ../../rst/reference_appendices/config.rst:3140 -#: ../../rst/reference_appendices/config.rst:3150 -msgid "White list of cowsay templates that are 'safe' to use, set to empty list if you want to enable all installed templates." -msgstr "「安全」に使用できる cowsay テンプレートのホワイトリスト。インストールされたすべてのテンプレートを有効にする場合は空のリストに設定します。" - -#: ../../rst/reference_appendices/config.rst:160 -#: ../../rst/reference_appendices/config.rst:369 -#: ../../rst/reference_appendices/config.rst:394 -#: ../../rst/reference_appendices/config.rst:1292 -#: ../../rst/reference_appendices/config.rst:1518 -#: ../../rst/reference_appendices/config.rst:1776 -#: ../../rst/reference_appendices/config.rst:2000 -#: ../../rst/reference_appendices/config.rst:2205 -#: ../../rst/reference_appendices/config.rst:2279 -#: ../../rst/reference_appendices/config.rst:2306 -#: ../../rst/reference_appendices/config.rst:2509 -#: ../../rst/reference_appendices/config.rst:2537 -#: ../../rst/reference_appendices/config.rst:2553 -#: ../../rst/reference_appendices/config.rst:2613 -#: ../../rst/reference_appendices/config.rst:2639 -#: ../../rst/reference_appendices/config.rst:2895 -#: ../../rst/reference_appendices/config.rst:2923 -#: ../../rst/reference_appendices/config.rst:2938 -#: ../../rst/reference_appendices/config.rst:3017 -#: ../../rst/reference_appendices/config.rst:3032 -#: ../../rst/reference_appendices/config.rst:3103 -msgid "list" -msgstr "list" - -#: ../../rst/reference_appendices/config.rst:161 -msgid "['bud-frogs', 'bunny', 'cheese', 'daemon', 'default', 'dragon', 'elephant-in-snake', 'elephant', 'eyes', 'hellokitty', 'kitty', 'luke-koala', 'meow', 'milk', 'moofasa', 'moose', 'ren', 'sheep', 'small', 'stegosaurus', 'stimpy', 'supermilker', 'three-eyes', 'turkey', 'turtle', 'tux', 'udder', 'vader-koala', 'vader', 'www']" -msgstr "['bud-frogs', 'bunny', 'cheese', 'daemon', 'default', 'dragon', 'elephant-in-snake', 'elephant', 'eyes', 'hellokitty', 'kitty', 'luke-koala', 'meow', 'milk', 'moofasa', 'moose', 'ren', 'sheep', 'small', 'stegosaurus', 'stimpy', 'supermilker', 'three-eyes', 'turkey', 'turtle', 'tux', 'udder', 'vader-koala', 'vader', 'www']" - -#: ../../rst/reference_appendices/config.rst:164 -msgid "cow_whitelist" -msgstr "cow_whitelist" - -#: ../../rst/reference_appendices/config.rst:165 -#: ../../rst/reference_appendices/config.rst:175 -#: ../../rst/reference_appendices/config.rst:374 -#: ../../rst/reference_appendices/config.rst:384 -#: ../../rst/reference_appendices/config.rst:399 -#: ../../rst/reference_appendices/config.rst:407 -#: ../../rst/reference_appendices/config.rst:3144 -#: ../../rst/reference_appendices/config.rst:3557 -#: ../../rst/reference_appendices/config.rst:3592 -msgid "2.15" -msgstr "2.15" - -#: ../../rst/reference_appendices/config.rst:166 -#: ../../rst/reference_appendices/config.rst:176 -#: ../../rst/reference_appendices/config.rst:375 -#: ../../rst/reference_appendices/config.rst:385 -#: ../../rst/reference_appendices/config.rst:400 -#: ../../rst/reference_appendices/config.rst:408 -#: ../../rst/reference_appendices/config.rst:3145 -#: ../../rst/reference_appendices/config.rst:3558 -#: ../../rst/reference_appendices/config.rst:3593 -msgid "normalizing names to new standard" -msgstr "名前を新しい標準に正規化" - -#: ../../rst/reference_appendices/config.rst:167 -#: ../../rst/reference_appendices/config.rst:169 -msgid "cowsay_enabled_stencils" -msgstr "cowsay_enabled_stencils" - -#: ../../rst/reference_appendices/config.rst:170 -#: ../../rst/reference_appendices/config.rst:173 -#: ../../rst/reference_appendices/config.rst:234 -#: ../../rst/reference_appendices/config.rst:379 -#: ../../rst/reference_appendices/config.rst:382 -#: ../../rst/reference_appendices/config.rst:404 -#: ../../rst/reference_appendices/config.rst:411 -#: ../../rst/reference_appendices/config.rst:2223 -#: ../../rst/reference_appendices/config.rst:3154 -#: ../../rst/reference_appendices/config.rst:3178 -#: ../../rst/reference_appendices/config.rst:3567 -#: ../../rst/reference_appendices/config.rst:3602 -msgid "2.11" -msgstr "2.11" - -#: ../../rst/reference_appendices/config.rst:172 -msgid ":envvar:`ANSIBLE_COW_ACCEPTLIST`" -msgstr ":envvar:`ANSIBLE_COW_ACCEPTLIST`" - -#: ../../rst/reference_appendices/config.rst:174 -msgid ":envvar:`ANSIBLE_COW_WHITELIST`" -msgstr ":envvar:`ANSIBLE_COW_WHITELIST`" - -#: ../../rst/reference_appendices/config.rst:182 -msgid "ANSIBLE_COW_PATH" -msgstr "ANSIBLE_COW_PATH" - -#: ../../rst/reference_appendices/config.rst:184 -#: ../../rst/reference_appendices/config.rst:3191 -msgid "Specify a custom cowsay path or swap in your cowsay implementation of choice" -msgstr "選択する Cowsay 実装でカスタムの Cowsay パスまたは swap を指定します。" - -#: ../../rst/reference_appendices/config.rst:185 -#: ../../rst/reference_appendices/config.rst:1235 -#: ../../rst/reference_appendices/config.rst:1356 -#: ../../rst/reference_appendices/config.rst:2157 -#: ../../rst/reference_appendices/config.rst:2880 -#: ../../rst/reference_appendices/config.rst:2983 -msgid "string" -msgstr "string" - -#: ../../rst/reference_appendices/config.rst:189 -msgid "cowpath" -msgstr "cowpath" - -#: ../../rst/reference_appendices/config.rst:191 -msgid ":envvar:`ANSIBLE_COW_PATH`" -msgstr ":envvar:`ANSIBLE_COW_PATH`" - -#: ../../rst/reference_appendices/config.rst:196 -msgid "ANSIBLE_COW_SELECTION" -msgstr "ANSIBLE_COW_SELECTION" - -#: ../../rst/reference_appendices/config.rst:198 -#: ../../rst/reference_appendices/config.rst:3132 -msgid "This allows you to chose a specific cowsay stencil for the banners or use 'random' to cycle through them." -msgstr "これにより、バナーの特定の cowsay ステンシルを選択するか、「random」を使用してバナーを循環させることができます。" - -#: ../../rst/reference_appendices/config.rst:199 -#: ../../rst/reference_appendices/config.rst:1791 -#: ../../rst/reference_appendices/config.rst:1987 -msgid "default" -msgstr "default" - -#: ../../rst/reference_appendices/config.rst:202 -msgid "cow_selection" -msgstr "cow_selection" - -#: ../../rst/reference_appendices/config.rst:204 -msgid ":envvar:`ANSIBLE_COW_SELECTION`" -msgstr ":envvar:`ANSIBLE_COW_SELECTION`" - -#: ../../rst/reference_appendices/config.rst:209 -msgid "ANSIBLE_FORCE_COLOR" -msgstr "ANSIBLE_FORCE_COLOR" - -#: ../../rst/reference_appendices/config.rst:211 -#: ../../rst/reference_appendices/config.rst:3159 -msgid "This option forces color mode even when running without a TTY or the \"nocolor\" setting is True." -msgstr "このオプションは、TTY を使用せずに実行し、または「nocolor」設定が True であっても色モードを強制的に実行します。" - -#: ../../rst/reference_appendices/config.rst:216 -msgid "force_color" -msgstr "force_color" - -#: ../../rst/reference_appendices/config.rst:218 -msgid ":envvar:`ANSIBLE_FORCE_COLOR`" -msgstr ":envvar:`ANSIBLE_FORCE_COLOR`" - -#: ../../rst/reference_appendices/config.rst:223 -msgid "ANSIBLE_NOCOLOR" -msgstr "ANSIBLE_NOCOLOR" - -#: ../../rst/reference_appendices/config.rst:225 -#: ../../rst/reference_appendices/config.rst:3167 -#: ../../rst/reference_appendices/config.rst:3174 -msgid "This setting allows suppressing colorizing output, which is used to give a better indication of failure and status information." -msgstr "この設定により、色付け出力を抑制できます。これは、障害およびステータスの情報をより適切に示すために使用されます。" - -#: ../../rst/reference_appendices/config.rst:230 -msgid "nocolor" -msgstr "nocolor" - -#: ../../rst/reference_appendices/config.rst:232 -msgid ":envvar:`ANSIBLE_NOCOLOR`" -msgstr ":envvar:`ANSIBLE_NOCOLOR`" - -#: ../../rst/reference_appendices/config.rst:233 -msgid ":envvar:`NO_COLOR`" -msgstr ":envvar:`NO_COLOR`" - -#: ../../rst/reference_appendices/config.rst:239 -msgid "ANSIBLE_NOCOWS" -msgstr "ANSIBLE_NOCOWS" - -#: ../../rst/reference_appendices/config.rst:241 -#: ../../rst/reference_appendices/config.rst:3183 -msgid "If you have cowsay installed but want to avoid the 'cows' (why????), use this." -msgstr "cowsay がインストールされているにもかかわらず、「cows」を回避するには、これを使用します。" - -#: ../../rst/reference_appendices/config.rst:246 -msgid "nocows" -msgstr "nocows" - -#: ../../rst/reference_appendices/config.rst:248 -msgid ":envvar:`ANSIBLE_NOCOWS`" -msgstr ":envvar:`ANSIBLE_NOCOWS`" - -#: ../../rst/reference_appendices/config.rst:253 -msgid "ANSIBLE_PIPELINING" -msgstr "ANSIBLE_PIPELINING" - -#: ../../rst/reference_appendices/config.rst:255 -msgid "Pipelining, if supported by the connection plugin, reduces the number of network operations required to execute a module on the remote server, by executing many Ansible modules without actual file transfer. This can result in a very significant performance improvement when enabled. However this conflicts with privilege escalation (become). For example, when using 'sudo:' operations you must first disable 'requiretty' in /etc/sudoers on all managed hosts, which is why it is disabled by default. This option is disabled if ``ANSIBLE_KEEP_REMOTE_FILES`` is enabled. This is a global option, each connection plugin can override either by having more specific options or not supporting pipelining at all." -msgstr "パイプライン (connection プラグインでサポートされる場合) は、実際のファイル転送を行わずに多数の Ansible モジュールを実行して、リモートサーバーでモジュールを実行するために必要なネットワーク操作の数を減らします。これにより、有効にするとパフォーマンスが大幅に改善する可能性があります。ただし、これは特権昇格 (become) と競合します。たとえば、「sudo:」操作を使用する場合は、すべての管理対象ホストの /etc/sudoers で「requiretty」を無効にする必要があります。これが、デフォルトで無効になっている理由です。``ANSIBLE_KEEP_REMOTE_FILES`` が有効な場合、このオプションは無効になります。これはグローバルオプションであり、各 connection プラグインは、より具体的なオプションを指定するか、パイプライン処理をサポートしないかのいずれかによりオーバーライドすることができます。" - -#: ../../rst/reference_appendices/config.rst:259 -msgid "[connection]" -msgstr "[connection]" - -#: ../../rst/reference_appendices/config.rst:260 -#: ../../rst/reference_appendices/config.rst:262 -msgid "pipelining" -msgstr "pipelining" - -#: ../../rst/reference_appendices/config.rst:264 -msgid ":envvar:`ANSIBLE_PIPELINING`" -msgstr ":envvar:`ANSIBLE_PIPELINING`" - -#: ../../rst/reference_appendices/config.rst:269 -msgid "ANY_ERRORS_FATAL" -msgstr "ANY_ERRORS_FATAL" - -#: ../../rst/reference_appendices/config.rst:271 -#: ../../rst/reference_appendices/config.rst:3207 -msgid "Sets the default value for the any_errors_fatal keyword, if True, Task failures will be considered fatal errors." -msgstr "any_errors_fatal キーワードのデフォルト値を設定します。True の場合、タスクの失敗は致命的なエラーとみなされます。" - -#: ../../rst/reference_appendices/config.rst:274 -#: ../../rst/reference_appendices/config.rst:3034 -msgid "2.4" -msgstr "2.4" - -#: ../../rst/reference_appendices/config.rst:277 -#: ../../rst/reference_appendices/playbooks_keywords.rst:26 -#: ../../rst/reference_appendices/playbooks_keywords.rst:163 -#: ../../rst/reference_appendices/playbooks_keywords.rst:258 -#: ../../rst/reference_appendices/playbooks_keywords.rst:362 -msgid "any_errors_fatal" -msgstr "any_errors_fatal" - -#: ../../rst/reference_appendices/config.rst:279 -msgid ":envvar:`ANSIBLE_ANY_ERRORS_FATAL`" -msgstr ":envvar:`ANSIBLE_ANY_ERRORS_FATAL`" - -#: ../../rst/reference_appendices/config.rst:284 -msgid "BECOME_ALLOW_SAME_USER" -msgstr "BECOME_ALLOW_SAME_USER" - -#: ../../rst/reference_appendices/config.rst:286 -#: ../../rst/reference_appendices/config.rst:3215 -msgid "This setting controls if become is skipped when remote user and become user are the same. I.E root sudo to root." -msgstr "この設定は、リモートユーザーと become ユーザーが同じである場合に、become をスキップするかどうかを制御します。つまり、root sudo から root に変更できます。" - -#: ../../rst/reference_appendices/config.rst:291 -msgid "become_allow_same_user" -msgstr "become_allow_same_user" - -#: ../../rst/reference_appendices/config.rst:293 -msgid ":envvar:`ANSIBLE_BECOME_ALLOW_SAME_USER`" -msgstr ":envvar:`ANSIBLE_BECOME_ALLOW_SAME_USER`" - -#: ../../rst/reference_appendices/config.rst:298 -msgid "BECOME_PLUGIN_PATH" -msgstr "BECOME_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:300 -#: ../../rst/reference_appendices/config.rst:3529 -msgid "Colon separated paths in which Ansible will search for Become Plugins." -msgstr "Ansible が Become プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:301 -#: ../../rst/reference_appendices/config.rst:437 -#: ../../rst/reference_appendices/config.rst:1017 -#: ../../rst/reference_appendices/config.rst:1152 -#: ../../rst/reference_appendices/config.rst:1166 -#: ../../rst/reference_appendices/config.rst:1180 -#: ../../rst/reference_appendices/config.rst:1194 -#: ../../rst/reference_appendices/config.rst:1249 -#: ../../rst/reference_appendices/config.rst:1387 -#: ../../rst/reference_appendices/config.rst:1414 -#: ../../rst/reference_appendices/config.rst:1546 -#: ../../rst/reference_appendices/config.rst:1606 -#: ../../rst/reference_appendices/config.rst:1620 -#: ../../rst/reference_appendices/config.rst:1634 -#: ../../rst/reference_appendices/config.rst:1762 -#: ../../rst/reference_appendices/config.rst:1818 -#: ../../rst/reference_appendices/config.rst:1877 -#: ../../rst/reference_appendices/config.rst:1891 -#: ../../rst/reference_appendices/config.rst:1947 -#: ../../rst/reference_appendices/config.rst:2131 -msgid "pathspec" -msgstr "pathspec" - -#: ../../rst/reference_appendices/config.rst:302 -msgid "~/.ansible/plugins/become:/usr/share/ansible/plugins/become" -msgstr "~/.ansible/plugins/become:/usr/share/ansible/plugins/become" - -#: ../../rst/reference_appendices/config.rst:306 -msgid "become_plugins" -msgstr "become_plugins" - -#: ../../rst/reference_appendices/config.rst:308 -msgid ":envvar:`ANSIBLE_BECOME_PLUGINS`" -msgstr ":envvar:`ANSIBLE_BECOME_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:313 -msgid "CACHE_PLUGIN" -msgstr "CACHE_PLUGIN" - -#: ../../rst/reference_appendices/config.rst:315 -#: ../../rst/reference_appendices/config.rst:3231 -msgid "Chooses which cache plugin to use, the default 'memory' is ephemeral." -msgstr "使用する cache プラグインを選択します。デフォルトの「メモリー」は一時的です。" - -#: ../../rst/reference_appendices/config.rst:316 -msgid "memory" -msgstr "memory" - -#: ../../rst/reference_appendices/config.rst:319 -msgid "fact_caching" -msgstr "fact_caching" - -#: ../../rst/reference_appendices/config.rst:321 -msgid ":envvar:`ANSIBLE_CACHE_PLUGIN`" -msgstr ":envvar:`ANSIBLE_CACHE_PLUGIN`" - -#: ../../rst/reference_appendices/config.rst:326 -msgid "CACHE_PLUGIN_CONNECTION" -msgstr "CACHE_PLUGIN_CONNECTION" - -#: ../../rst/reference_appendices/config.rst:328 -#: ../../rst/reference_appendices/config.rst:3239 -msgid "Defines connection or path information for the cache plugin" -msgstr "cache プラグインの接続またはパスの情報を定義" - -#: ../../rst/reference_appendices/config.rst:332 -msgid "fact_caching_connection" -msgstr "fact_caching_connection" - -#: ../../rst/reference_appendices/config.rst:334 -msgid ":envvar:`ANSIBLE_CACHE_PLUGIN_CONNECTION`" -msgstr ":envvar:`ANSIBLE_CACHE_PLUGIN_CONNECTION`" - -#: ../../rst/reference_appendices/config.rst:339 -msgid "CACHE_PLUGIN_PREFIX" -msgstr "CACHE_PLUGIN_PREFIX" - -#: ../../rst/reference_appendices/config.rst:341 -#: ../../rst/reference_appendices/config.rst:3247 -msgid "Prefix to use for cache plugin files/tables" -msgstr "cache プラグインファイル/テーブルに使用する接頭辞" - -#: ../../rst/reference_appendices/config.rst:345 -msgid "fact_caching_prefix" -msgstr "fact_caching_prefix" - -#: ../../rst/reference_appendices/config.rst:347 -msgid ":envvar:`ANSIBLE_CACHE_PLUGIN_PREFIX`" -msgstr ":envvar:`ANSIBLE_CACHE_PLUGIN_PREFIX`" - -#: ../../rst/reference_appendices/config.rst:352 -msgid "CACHE_PLUGIN_TIMEOUT" -msgstr "CACHE_PLUGIN_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:354 -#: ../../rst/reference_appendices/config.rst:3255 -msgid "Expiration timeout for the cache plugin data" -msgstr "cache プラグインデータの有効期限のタイムアウト" - -#: ../../rst/reference_appendices/config.rst:355 -#: ../../rst/reference_appendices/config.rst:1278 -#: ../../rst/reference_appendices/config.rst:1307 -#: ../../rst/reference_appendices/config.rst:1693 -#: ../../rst/reference_appendices/config.rst:1735 -#: ../../rst/reference_appendices/config.rst:1905 -#: ../../rst/reference_appendices/config.rst:2028 -#: ../../rst/reference_appendices/config.rst:2084 -#: ../../rst/reference_appendices/config.rst:2712 -#: ../../rst/reference_appendices/config.rst:2726 -#: ../../rst/reference_appendices/config.rst:2968 -#: ../../rst/reference_appendices/config.rst:3062 -#: ../../rst/reference_appendices/config.rst:3079 -msgid "integer" -msgstr "integer" - -#: ../../rst/reference_appendices/config.rst:356 -msgid "86400" -msgstr "86400" - -#: ../../rst/reference_appendices/config.rst:359 -msgid "fact_caching_timeout" -msgstr "fact_caching_timeout" - -#: ../../rst/reference_appendices/config.rst:361 -msgid ":envvar:`ANSIBLE_CACHE_PLUGIN_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_CACHE_PLUGIN_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:366 -msgid "CALLABLE_ACCEPT_LIST" -msgstr "CALLABLE_ACCEPT_LIST" - -#: ../../rst/reference_appendices/config.rst:368 -#: ../../rst/reference_appendices/config.rst:3553 -#: ../../rst/reference_appendices/config.rst:3563 -msgid "Whitelist of callable methods to be made available to template evaluation" -msgstr "テンプレート評価で利用できる呼び出し可能なメソッドのホワイトリスト" - -#: ../../rst/reference_appendices/config.rst:370 -#: ../../rst/reference_appendices/config.rst:395 -#: ../../rst/reference_appendices/config.rst:1428 -#: ../../rst/reference_appendices/config.rst:1519 -#: ../../rst/reference_appendices/config.rst:2001 -#: ../../rst/reference_appendices/config.rst:2554 -#: ../../rst/reference_appendices/config.rst:2924 -#: ../../rst/reference_appendices/config.rst:2939 -msgid "[]" -msgstr "[]" - -#: ../../rst/reference_appendices/config.rst:373 -msgid "callable_whitelist" -msgstr "callable_whitelist" - -#: ../../rst/reference_appendices/config.rst:376 -#: ../../rst/reference_appendices/config.rst:378 -msgid "callable_enabled" -msgstr "callable_enabled" - -#: ../../rst/reference_appendices/config.rst:381 -msgid ":envvar:`ANSIBLE_CALLABLE_ENABLED`" -msgstr ":envvar:`ANSIBLE_CALLABLE_ENABLED`" - -#: ../../rst/reference_appendices/config.rst:383 -msgid ":envvar:`ANSIBLE_CALLABLE_WHITELIST`" -msgstr ":envvar:`ANSIBLE_CALLABLE_WHITELIST`" - -#: ../../rst/reference_appendices/config.rst:386 -#: ../../rst/reference_appendices/config.rst:3559 -msgid "ANSIBLE_CALLABLE_ENABLED" -msgstr "ANSIBLE_CALLABLE_ENABLED" - -#: ../../rst/reference_appendices/config.rst:391 -msgid "CALLBACKS_ENABLED" -msgstr "CALLBACKS_ENABLED" - -#: ../../rst/reference_appendices/config.rst:393 -#: ../../rst/reference_appendices/config.rst:3588 -#: ../../rst/reference_appendices/config.rst:3598 -msgid "List of enabled callbacks, not all callbacks need enabling, but many of those shipped with Ansible do as we don't want them activated by default." -msgstr "有効なコールバックのリストです。すべてのコールバックを有効にする必要はありませんが、Ansible に同梱されるコールバックの多くは、デフォルトでアクティブ化されたくないため、そのようになっています。" - -#: ../../rst/reference_appendices/config.rst:398 -msgid "callback_whitelist" -msgstr "callback_whitelist" - -#: ../../rst/reference_appendices/config.rst:401 -msgid "callback_enabled" -msgstr "callback_enabled" - -#: ../../rst/reference_appendices/config.rst:403 -msgid "callbacks_enabled" -msgstr "callbacks_enabled" - -#: ../../rst/reference_appendices/config.rst:406 -msgid ":envvar:`ANSIBLE_CALLBACK_WHITELIST`" -msgstr ":envvar:`ANSIBLE_CALLBACK_WHITELIST`" - -#: ../../rst/reference_appendices/config.rst:409 -#: ../../rst/reference_appendices/config.rst:3594 -msgid "ANSIBLE_CALLBACKS_ENABLED" -msgstr "ANSIBLE_CALLBACKS_ENABLED" - -#: ../../rst/reference_appendices/config.rst:410 -msgid ":envvar:`ANSIBLE_CALLBACKS_ENABLED`" -msgstr ":envvar:`ANSIBLE_CALLBACKS_ENABLED`" - -#: ../../rst/reference_appendices/config.rst:416 -msgid "COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH" -msgstr "COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH" - -#: ../../rst/reference_appendices/config.rst:418 -#: ../../rst/reference_appendices/config.rst:3288 -msgid "When a collection is loaded that does not support the running Ansible version (via the collection metadata key `requires_ansible`), the default behavior is to issue a warning and continue anyway. Setting this value to `ignore` skips the warning entirely, while setting it to `fatal` will immediately halt Ansible execution." -msgstr "(コレクションメタデータキー `requires_ansible` を介して) 実行中の Ansible バージョンをサポートしないコレクションが読み込まれると、デフォルトの動作では、警告を表示してとにかく続行します。この値を `ignore` に設定すると警告を完全に飛ばします。`fatal` に設定すると、Ansible の実行をすぐに停止します。" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:419 -#: ../../rst/reference_appendices/config.rst:2349 -msgid "warning" -msgstr "warning" - -#: ../../rst/reference_appendices/config.rst -msgid "Choices" -msgstr "選択肢" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:724 -msgid "error" -msgstr "error" - -#: ../../rst/reference_appendices/config.rst -msgid "ignore" -msgstr "ignore" - -#: ../../rst/reference_appendices/config.rst:426 -msgid "collections_on_ansible_version_mismatch" -msgstr "collections_on_ansible_version_mismatch" - -#: ../../rst/reference_appendices/config.rst:428 -msgid ":envvar:`ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH`" -msgstr ":envvar:`ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH`" - -#: ../../rst/reference_appendices/config.rst:433 -msgid "COLLECTIONS_PATHS" -msgstr "COLLECTIONS_PATHS" - -#: ../../rst/reference_appendices/config.rst:435 -#: ../../rst/reference_appendices/config.rst:3270 -#: ../../rst/reference_appendices/config.rst:3278 -msgid "Colon separated paths in which Ansible will search for collections content. Collections must be in nested *subdirectories*, not directly in these directories. For example, if ``COLLECTIONS_PATHS`` includes ``~/.ansible/collections``, and you want to add ``my.collection`` to that directory, it must be saved as ``~/.ansible/collections/ansible_collections/my/collection``." -msgstr "Ansible がコレクションコンテンツを検索するコロン区切りパス。コレクションは、これらのディレクトリーに直接ではなく、入れ子の * サブディレクトリー* に置かれる必要があります。たとえば、``COLLECTIONS_PATHS`` には ``~/.ansible/collections`` が含まれ、そのディレクトリーに ``my.collection`` を追加する場合は、``~/.ansible/collections/ansible_collections/my/collection`` として保存する必要があります。" - -#: ../../rst/reference_appendices/config.rst:438 -msgid "~/.ansible/collections:/usr/share/ansible/collections" -msgstr "~/.ansible/collections:/usr/share/ansible/collections" - -#: ../../rst/reference_appendices/config.rst:441 -msgid "collections_paths" -msgstr "collections_paths" - -#: ../../rst/reference_appendices/config.rst:443 -msgid "collections_path" -msgstr "collections_path" - -#: ../../rst/reference_appendices/config.rst:444 -#: ../../rst/reference_appendices/config.rst:447 -#: ../../rst/reference_appendices/config.rst:2238 -#: ../../rst/reference_appendices/config.rst:2853 -#: ../../rst/reference_appendices/config.rst:2970 -#: ../../rst/reference_appendices/config.rst:3019 -#: ../../rst/reference_appendices/config.rst:3064 -#: ../../rst/reference_appendices/config.rst:3081 -#: ../../rst/reference_appendices/config.rst:3093 -#: ../../rst/reference_appendices/config.rst:3283 -msgid "2.10" -msgstr "2.10" - -#: ../../rst/reference_appendices/config.rst:446 -msgid ":envvar:`ANSIBLE_COLLECTIONS_PATH`" -msgstr ":envvar:`ANSIBLE_COLLECTIONS_PATH`" - -#: ../../rst/reference_appendices/config.rst:448 -msgid ":envvar:`ANSIBLE_COLLECTIONS_PATHS`" -msgstr ":envvar:`ANSIBLE_COLLECTIONS_PATHS`" - -#: ../../rst/reference_appendices/config.rst:453 -msgid "COLLECTIONS_SCAN_SYS_PATH" -msgstr "COLLECTIONS_SCAN_SYS_PATH" - -#: ../../rst/reference_appendices/config.rst:459 -msgid "collections_scan_sys_path" -msgstr "collections_scan_sys_path" - -#: ../../rst/reference_appendices/config.rst:461 -msgid ":envvar:`ANSIBLE_COLLECTIONS_SCAN_SYS_PATH`" -msgstr ":envvar:`ANSIBLE_COLLECTIONS_SCAN_SYS_PATH`" - -#: ../../rst/reference_appendices/config.rst:466 -msgid "COLOR_CHANGED" -msgstr "COLOR_CHANGED" - -#: ../../rst/reference_appendices/config.rst:468 -#: ../../rst/reference_appendices/config.rst:3296 -msgid "Defines the color to use on 'Changed' task status" -msgstr "「Changed」タスクの状態に使用する色を定義" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:469 -msgid "yellow" -msgstr "yellow" - -#: ../../rst/reference_appendices/config.rst -msgid "black" -msgstr "black" - -#: ../../rst/reference_appendices/config.rst -msgid "bright gray" -msgstr "bright gray" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:866 -msgid "blue" -msgstr "blue" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:502 -#: ../../rst/reference_appendices/config.rst:734 -msgid "white" -msgstr "white" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:602 -#: ../../rst/reference_appendices/config.rst:767 -msgid "green" -msgstr "green" - -#: ../../rst/reference_appendices/config.rst -msgid "bright blue" -msgstr "bright blue" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:635 -#: ../../rst/reference_appendices/config.rst:800 -msgid "cyan" -msgstr "cyan" - -#: ../../rst/reference_appendices/config.rst -msgid "bright green" -msgstr "bright green" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:668 -#: ../../rst/reference_appendices/config.rst:701 -msgid "red" -msgstr "red" - -#: ../../rst/reference_appendices/config.rst -msgid "bright cyan" -msgstr "bright cyan" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:569 -msgid "purple" -msgstr "purple" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:833 -msgid "bright red" -msgstr "bright red" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:899 -msgid "bright purple" -msgstr "bright purple" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:536 -msgid "dark gray" -msgstr "dark gray" - -#: ../../rst/reference_appendices/config.rst -msgid "bright yellow" -msgstr "bright yellow" - -#: ../../rst/reference_appendices/config.rst -msgid "magenta" -msgstr "magenta" - -#: ../../rst/reference_appendices/config.rst -msgid "bright magenta" -msgstr "bright magenta" - -#: ../../rst/reference_appendices/config.rst -msgid "normal" -msgstr "normal" - -#: ../../rst/reference_appendices/config.rst:491 -#: ../../rst/reference_appendices/config.rst:525 -#: ../../rst/reference_appendices/config.rst:558 -#: ../../rst/reference_appendices/config.rst:591 -#: ../../rst/reference_appendices/config.rst:624 -#: ../../rst/reference_appendices/config.rst:657 -#: ../../rst/reference_appendices/config.rst:690 -#: ../../rst/reference_appendices/config.rst:723 -#: ../../rst/reference_appendices/config.rst:756 -#: ../../rst/reference_appendices/config.rst:789 -#: ../../rst/reference_appendices/config.rst:822 -#: ../../rst/reference_appendices/config.rst:855 -#: ../../rst/reference_appendices/config.rst:888 -#: ../../rst/reference_appendices/config.rst:921 -msgid "[colors]" -msgstr "[colors]" - -#: ../../rst/reference_appendices/config.rst:494 -msgid ":envvar:`ANSIBLE_COLOR_CHANGED`" -msgstr ":envvar:`ANSIBLE_COLOR_CHANGED`" - -#: ../../rst/reference_appendices/config.rst:499 -msgid "COLOR_CONSOLE_PROMPT" -msgstr "COLOR_CONSOLE_PROMPT" - -#: ../../rst/reference_appendices/config.rst:501 -#: ../../rst/reference_appendices/config.rst:3304 -msgid "Defines the default color to use for ansible-console" -msgstr "ansible-console に使用するデフォルトの色を定義します。" - -#: ../../rst/reference_appendices/config.rst:523 -#: ../../rst/reference_appendices/config.rst:1443 -#: ../../rst/reference_appendices/config.rst:2416 -#: ../../rst/reference_appendices/config.rst:2432 -#: ../../rst/reference_appendices/config.rst:2955 -msgid "2.7" -msgstr "2.7" - -#: ../../rst/reference_appendices/config.rst:526 -msgid "console_prompt" -msgstr "console_prompt" - -#: ../../rst/reference_appendices/config.rst:528 -msgid ":envvar:`ANSIBLE_COLOR_CONSOLE_PROMPT`" -msgstr ":envvar:`ANSIBLE_COLOR_CONSOLE_PROMPT`" - -#: ../../rst/reference_appendices/config.rst:533 -msgid "COLOR_DEBUG" -msgstr "COLOR_DEBUG" - -#: ../../rst/reference_appendices/config.rst:535 -#: ../../rst/reference_appendices/config.rst:3312 -msgid "Defines the color to use when emitting debug messages" -msgstr "デバッグメッセージを生成する際に使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:559 -#: ../../rst/reference_appendices/config.rst:1212 -msgid "debug" -msgstr "debug" - -#: ../../rst/reference_appendices/config.rst:561 -msgid ":envvar:`ANSIBLE_COLOR_DEBUG`" -msgstr ":envvar:`ANSIBLE_COLOR_DEBUG`" - -#: ../../rst/reference_appendices/config.rst:566 -msgid "COLOR_DEPRECATE" -msgstr "COLOR_DEPRECATE" - -#: ../../rst/reference_appendices/config.rst:568 -#: ../../rst/reference_appendices/config.rst:3320 -msgid "Defines the color to use when emitting deprecation messages" -msgstr "非推奨メッセージを生成するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:592 -msgid "deprecate" -msgstr "deprecate" - -#: ../../rst/reference_appendices/config.rst:594 -msgid ":envvar:`ANSIBLE_COLOR_DEPRECATE`" -msgstr ":envvar:`ANSIBLE_COLOR_DEPRECATE`" - -#: ../../rst/reference_appendices/config.rst:599 -msgid "COLOR_DIFF_ADD" -msgstr "COLOR_DIFF_ADD" - -#: ../../rst/reference_appendices/config.rst:601 -#: ../../rst/reference_appendices/config.rst:3328 -msgid "Defines the color to use when showing added lines in diffs" -msgstr "diffs で追加した行を表示するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:625 -msgid "diff_add" -msgstr "diff_add" - -#: ../../rst/reference_appendices/config.rst:627 -msgid ":envvar:`ANSIBLE_COLOR_DIFF_ADD`" -msgstr ":envvar:`ANSIBLE_COLOR_DIFF_ADD`" - -#: ../../rst/reference_appendices/config.rst:632 -msgid "COLOR_DIFF_LINES" -msgstr "COLOR_DIFF_LINES" - -#: ../../rst/reference_appendices/config.rst:634 -#: ../../rst/reference_appendices/config.rst:3336 -msgid "Defines the color to use when showing diffs" -msgstr "差異を表示するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:658 -msgid "diff_lines" -msgstr "diff_lines" - -#: ../../rst/reference_appendices/config.rst:660 -msgid ":envvar:`ANSIBLE_COLOR_DIFF_LINES`" -msgstr ":envvar:`ANSIBLE_COLOR_DIFF_LINES`" - -#: ../../rst/reference_appendices/config.rst:665 -msgid "COLOR_DIFF_REMOVE" -msgstr "COLOR_DIFF_REMOVE" - -#: ../../rst/reference_appendices/config.rst:667 -#: ../../rst/reference_appendices/config.rst:3344 -msgid "Defines the color to use when showing removed lines in diffs" -msgstr "diffs で削除した行を表示するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:691 -msgid "diff_remove" -msgstr "diff_remove" - -#: ../../rst/reference_appendices/config.rst:693 -msgid ":envvar:`ANSIBLE_COLOR_DIFF_REMOVE`" -msgstr ":envvar:`ANSIBLE_COLOR_DIFF_REMOVE`" - -#: ../../rst/reference_appendices/config.rst:698 -msgid "COLOR_ERROR" -msgstr "COLOR_ERROR" - -#: ../../rst/reference_appendices/config.rst:700 -#: ../../rst/reference_appendices/config.rst:3352 -msgid "Defines the color to use when emitting error messages" -msgstr "エラーメッセージを生成する際に使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:726 -msgid ":envvar:`ANSIBLE_COLOR_ERROR`" -msgstr ":envvar:`ANSIBLE_COLOR_ERROR`" - -#: ../../rst/reference_appendices/config.rst:731 -msgid "COLOR_HIGHLIGHT" -msgstr "COLOR_HIGHLIGHT" - -#: ../../rst/reference_appendices/config.rst:733 -#: ../../rst/reference_appendices/config.rst:3360 -msgid "Defines the color to use for highlighting" -msgstr "強調表示に使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:757 -msgid "highlight" -msgstr "highlight" - -#: ../../rst/reference_appendices/config.rst:759 -msgid ":envvar:`ANSIBLE_COLOR_HIGHLIGHT`" -msgstr ":envvar:`ANSIBLE_COLOR_HIGHLIGHT`" - -#: ../../rst/reference_appendices/config.rst:764 -msgid "COLOR_OK" -msgstr "COLOR_OK" - -#: ../../rst/reference_appendices/config.rst:766 -#: ../../rst/reference_appendices/config.rst:3368 -msgid "Defines the color to use when showing 'OK' task status" -msgstr "タスク状態「OK」を表示するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:790 -msgid "ok" -msgstr "ok" - -#: ../../rst/reference_appendices/config.rst:792 -msgid ":envvar:`ANSIBLE_COLOR_OK`" -msgstr ":envvar:`ANSIBLE_COLOR_OK`" - -#: ../../rst/reference_appendices/config.rst:797 -msgid "COLOR_SKIP" -msgstr "COLOR_SKIP" - -#: ../../rst/reference_appendices/config.rst:799 -#: ../../rst/reference_appendices/config.rst:3376 -msgid "Defines the color to use when showing 'Skipped' task status" -msgstr "タスク状態「Skipped」を表示するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:823 -#: ../../rst/reference_appendices/config.rst:2943 -msgid "skip" -msgstr "skip" - -#: ../../rst/reference_appendices/config.rst:825 -msgid ":envvar:`ANSIBLE_COLOR_SKIP`" -msgstr ":envvar:`ANSIBLE_COLOR_SKIP`" - -#: ../../rst/reference_appendices/config.rst:830 -msgid "COLOR_UNREACHABLE" -msgstr "COLOR_UNREACHABLE" - -#: ../../rst/reference_appendices/config.rst:832 -#: ../../rst/reference_appendices/config.rst:3384 -msgid "Defines the color to use on 'Unreachable' status" -msgstr "タスク状態「到達不能」状態で使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:856 -msgid "unreachable" -msgstr "unreachable" - -#: ../../rst/reference_appendices/config.rst:858 -msgid ":envvar:`ANSIBLE_COLOR_UNREACHABLE`" -msgstr ":envvar:`ANSIBLE_COLOR_UNREACHABLE`" - -#: ../../rst/reference_appendices/config.rst:863 -msgid "COLOR_VERBOSE" -msgstr "COLOR_VERBOSE" - -#: ../../rst/reference_appendices/config.rst:865 -#: ../../rst/reference_appendices/config.rst:3392 -msgid "Defines the color to use when emitting verbose messages. i.e those that show with '-v's." -msgstr "詳細メッセージを生成する際に使用する色を定義します (つまり、'-v's で示されるものとなります)。" - -#: ../../rst/reference_appendices/config.rst:889 -msgid "verbose" -msgstr "verbose" - -#: ../../rst/reference_appendices/config.rst:891 -msgid ":envvar:`ANSIBLE_COLOR_VERBOSE`" -msgstr ":envvar:`ANSIBLE_COLOR_VERBOSE`" - -#: ../../rst/reference_appendices/config.rst:896 -msgid "COLOR_WARN" -msgstr "COLOR_WARN" - -#: ../../rst/reference_appendices/config.rst:898 -#: ../../rst/reference_appendices/config.rst:3400 -msgid "Defines the color to use when emitting warning messages" -msgstr "警告メッセージを生成するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:922 -#: ../../rst/reference_appendices/config.rst:2158 -#: ../../rst/reference_appendices/config.rst:2881 -msgid "warn" -msgstr "warn" - -#: ../../rst/reference_appendices/config.rst:924 -msgid ":envvar:`ANSIBLE_COLOR_WARN`" -msgstr ":envvar:`ANSIBLE_COLOR_WARN`" - -#: ../../rst/reference_appendices/config.rst:929 -msgid "COMMAND_WARNINGS" -msgstr "COMMAND_WARNINGS" - -#: ../../rst/reference_appendices/config.rst:931 -msgid "Ansible can issue a warning when the shell or command module is used and the command appears to be similar to an existing Ansible module. These warnings can be silenced by adjusting this setting to False. You can also control this at the task level with the module option ``warn``. As of version 2.11, this is disabled by default." -msgstr "Ansible は、シェルまたはコマンドモジュールが使用され、コマンドが既存の Ansible モジュールと類似しているように見えます。これらの設定を False に設定することで、これらの警告を非表示にすることができます。また、モジュールのオプション ``warn`` を使用してタスクレベルで制御することもできます。バージョン 2.11 の時点で、これはデフォルトでは無効になっています。" - -#: ../../rst/reference_appendices/config.rst:934 -#: ../../rst/reference_appendices/config.rst:1491 -msgid "1.8" -msgstr "1.8" - -#: ../../rst/reference_appendices/config.rst:937 -msgid "command_warnings" -msgstr "command_warnings" - -#: ../../rst/reference_appendices/config.rst:939 -msgid ":envvar:`ANSIBLE_COMMAND_WARNINGS`" -msgstr ":envvar:`ANSIBLE_COMMAND_WARNINGS`" - -#: ../../rst/reference_appendices/config.rst:941 -msgid "the command warnings feature is being removed" -msgstr "コマンド警告機能が削除されています。" - -#: ../../rst/reference_appendices/config.rst:946 -msgid "CONDITIONAL_BARE_VARS" -msgstr "CONDITIONAL_BARE_VARS" - -#: ../../rst/reference_appendices/config.rst:948 -msgid "With this setting on (True), running conditional evaluation 'var' is treated differently than 'var.subkey' as the first is evaluated directly while the second goes through the Jinja2 parser. But 'false' strings in 'var' get evaluated as booleans. With this setting off they both evaluate the same but in cases in which 'var' was 'false' (a string) it won't get evaluated as a boolean anymore. Currently this setting defaults to 'True' but will soon change to 'False' and the setting itself will be removed in the future. Expect that this setting eventually will be deprecated after 2.12" -msgstr "この設定を (True) にすると、条件付き評価「var」の実行は「var.subkey」とは異なる方法で処理されます。最初の評価は直接評価され、2 番目の評価は Jinja2 パーサーを通過するためです。ただし、「var」の「false」文字列はブール値として評価されます。この設定をオフにすると、どちらも同じように評価されますが、「var」が「false」(文字列) の場合は、ブール値として評価されなくなります。現在、この設定のデフォルトは「True」ですが、まもなく「False」に変更され、将来のバージョンで設定自体が削除されます。この設定は、2.12 以降で最終的に非推奨になると予想されます。" - -#: ../../rst/reference_appendices/config.rst:954 -msgid "conditional_bare_variables" -msgstr "conditional_bare_variables" - -#: ../../rst/reference_appendices/config.rst:956 -msgid ":envvar:`ANSIBLE_CONDITIONAL_BARE_VARS`" -msgstr ":envvar:`ANSIBLE_CONDITIONAL_BARE_VARS`" - -#: ../../rst/reference_appendices/config.rst:961 -msgid "CONNECTION_FACTS_MODULES" -msgstr "CONNECTION_FACTS_MODULES" - -#: ../../rst/reference_appendices/config.rst:963 -#: ../../rst/reference_appendices/config.rst:4169 -msgid "Which modules to run during a play's fact gathering stage based on connection" -msgstr "接続に基づいてプレイのファクト収集ステージ時に実行するモジュール" - -#: ../../rst/reference_appendices/config.rst:964 -msgid "dict" -msgstr "dict" - -#: ../../rst/reference_appendices/config.rst:965 -msgid "{'asa': 'ansible.legacy.asa_facts', 'cisco.asa.asa': 'cisco.asa.asa_facts', 'eos': 'ansible.legacy.eos_facts', 'arista.eos.eos': 'arista.eos.eos_facts', 'frr': 'ansible.legacy.frr_facts', 'frr.frr.frr': 'frr.frr.frr_facts', 'ios': 'ansible.legacy.ios_facts', 'cisco.ios.ios': 'cisco.ios.ios_facts', 'iosxr': 'ansible.legacy.iosxr_facts', 'cisco.iosxr.iosxr': 'cisco.iosxr.iosxr_facts', 'junos': 'ansible.legacy.junos_facts', 'junipernetworks.junos.junos': 'junipernetworks.junos.junos_facts', 'nxos': 'ansible.legacy.nxos_facts', 'cisco.nxos.nxos': 'cisco.nxos.nxos_facts', 'vyos': 'ansible.legacy.vyos_facts', 'vyos.vyos.vyos': 'vyos.vyos.vyos_facts', 'exos': 'ansible.legacy.exos_facts', 'extreme.exos.exos': 'extreme.exos.exos_facts', 'slxos': 'ansible.legacy.slxos_facts', 'extreme.slxos.slxos': 'extreme.slxos.slxos_facts', 'voss': 'ansible.legacy.voss_facts', 'extreme.voss.voss': 'extreme.voss.voss_facts', 'ironware': 'ansible.legacy.ironware_facts', 'community.network.ironware': 'community.network.ironware_facts'}" -msgstr "{'asa': 'ansible.legacy.asa_facts', 'cisco.asa.asa': 'cisco.asa.asa_facts', 'eos': 'ansible.legacy.eos_facts', 'arista.eos.eos': 'arista.eos.eos_facts', 'frr': 'ansible.legacy.frr_facts', 'frr.frr.frr': 'frr.frr.frr_facts', 'ios': 'ansible.legacy.ios_facts', 'cisco.ios.ios': 'cisco.ios.ios_facts', 'iosxr': 'ansible.legacy.iosxr_facts', 'cisco.iosxr.iosxr': 'cisco.iosxr.iosxr_facts', 'junos': 'ansible.legacy.junos_facts', 'junipernetworks.junos.junos': 'junipernetworks.junos.junos_facts', 'nxos': 'ansible.legacy.nxos_facts', 'cisco.nxos.nxos': 'cisco.nxos.nxos_facts', 'vyos': 'ansible.legacy.vyos_facts', 'vyos.vyos.vyos': 'vyos.vyos.vyos_facts', 'exos': 'ansible.legacy.exos_facts', 'extreme.exos.exos': 'extreme.exos.exos_facts', 'slxos': 'ansible.legacy.slxos_facts', 'extreme.slxos.slxos': 'extreme.slxos.slxos_facts', 'voss': 'ansible.legacy.voss_facts', 'extreme.voss.voss': 'extreme.voss.voss_facts', 'ironware': 'ansible.legacy.ironware_facts', 'community.network.ironware': 'community.network.ironware_facts'}" - -#: ../../rst/reference_appendices/config.rst:968 -msgid "connection_facts_modules" -msgstr "connection_facts_modules" - -#: ../../rst/reference_appendices/config.rst:970 -msgid ":envvar:`ANSIBLE_CONNECTION_FACTS_MODULES`" -msgstr ":envvar:`ANSIBLE_CONNECTION_FACTS_MODULES`" - -#: ../../rst/reference_appendices/config.rst:975 -msgid "CONTROLLER_PYTHON_WARNING" -msgstr "CONTROLLER_PYTHON_WARNING" - -#: ../../rst/reference_appendices/config.rst:977 -#: ../../rst/reference_appendices/config.rst:3572 -msgid "Toggle to control showing warnings related to running a Python version older than Python 3.8 on the controller" -msgstr "コントローラーで Python 3.8 よりも古い Python の実行に関連する警告の表示を制御するように切り替えます。" - -#: ../../rst/reference_appendices/config.rst:982 -msgid "controller_python_warning" -msgstr "controller_python_warning" - -#: ../../rst/reference_appendices/config.rst:984 -msgid ":envvar:`ANSIBLE_CONTROLLER_PYTHON_WARNING`" -msgstr ":envvar:`ANSIBLE_CONTROLLER_PYTHON_WARNING`" - -#: ../../rst/reference_appendices/config.rst:989 -msgid "COVERAGE_REMOTE_OUTPUT" -msgstr "COVERAGE_REMOTE_OUTPUT" - -#: ../../rst/reference_appendices/config.rst:991 -msgid "Sets the output directory on the remote host to generate coverage reports to. Currently only used for remote coverage on PowerShell modules. This is for internal use only." -msgstr "リモートホストの出力ディレクトリーを設定してカバレッジレポートを生成します。現在 PowerShell モジュールのリモートカバレッジにのみ使用されます。これは内部使用のみを目的としています。" - -#: ../../rst/reference_appendices/config.rst:992 -#: ../../rst/reference_appendices/config.rst:1005 -#: ../../rst/reference_appendices/config.rst:2848 -msgid "str" -msgstr "str" - -#: ../../rst/reference_appendices/config.rst:993 -#: ../../rst/reference_appendices/config.rst:1007 -#: ../../rst/reference_appendices/config.rst:2163 -#: ../../rst/reference_appendices/config.rst:2307 -#: ../../rst/reference_appendices/config.rst:2322 -#: ../../rst/reference_appendices/config.rst:2755 -#: ../../rst/reference_appendices/config.rst:3929 -msgid "2.9" -msgstr "2.9" - -#: ../../rst/reference_appendices/config.rst:995 -msgid ":envvar:`_ANSIBLE_COVERAGE_REMOTE_OUTPUT`" -msgstr ":envvar:`_ANSIBLE_COVERAGE_REMOTE_OUTPUT`" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/general_precedence.rst:23 -#: ../../rst/reference_appendices/general_precedence.rst:92 -msgid "Variables" -msgstr "変数" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/playbooks_keywords.rst:101 -#: ../../rst/reference_appendices/playbooks_keywords.rst:220 -#: ../../rst/reference_appendices/playbooks_keywords.rst:318 -#: ../../rst/reference_appendices/playbooks_keywords.rst:446 -msgid "name" -msgstr "name" - -#: ../../rst/reference_appendices/config.rst:997 -msgid "`_ansible_coverage_remote_output`" -msgstr "`_ansible_coverage_remote_output`" - -#: ../../rst/reference_appendices/config.rst:1002 -msgid "COVERAGE_REMOTE_PATHS" -msgstr "COVERAGE_REMOTE_PATHS" - -#: ../../rst/reference_appendices/config.rst:1004 -msgid "A list of paths for files on the Ansible controller to run coverage for when executing on the remote host. Only files that match the path glob will have its coverage collected. Multiple path globs can be specified and are separated by ``:``. Currently only used for remote coverage on PowerShell modules. This is for internal use only." -msgstr "リモートホストで実行するときにカバレッジを実行する Ansible コントローラー上のファイルのパスのリスト。パスグロブに一致するファイルのみがカバレッジを収集します。パスグロブは、``:`` で区切ることで複数指定できます。現在 PowerShell モジュールのリモートカバレッジにのみ使用されます。これは内部使用のみを目的としています。" - -#: ../../rst/reference_appendices/config.rst:1009 -msgid ":envvar:`_ANSIBLE_COVERAGE_REMOTE_PATH_FILTER`" -msgstr ":envvar:`_ANSIBLE_COVERAGE_REMOTE_PATH_FILTER`" - -#: ../../rst/reference_appendices/config.rst:1014 -msgid "DEFAULT_ACTION_PLUGIN_PATH" -msgstr "DEFAULT_ACTION_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1016 -#: ../../rst/reference_appendices/config.rst:3464 -msgid "Colon separated paths in which Ansible will search for Action Plugins." -msgstr "Ansible が Action プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1018 -msgid "~/.ansible/plugins/action:/usr/share/ansible/plugins/action" -msgstr "~/.ansible/plugins/action:/usr/share/ansible/plugins/action" - -#: ../../rst/reference_appendices/config.rst:1021 -msgid "action_plugins" -msgstr "action_plugins" - -#: ../../rst/reference_appendices/config.rst:1023 -msgid ":envvar:`ANSIBLE_ACTION_PLUGINS`" -msgstr ":envvar:`ANSIBLE_ACTION_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1028 -msgid "DEFAULT_ALLOW_UNSAFE_LOOKUPS" -msgstr "DEFAULT_ALLOW_UNSAFE_LOOKUPS" - -#: ../../rst/reference_appendices/config.rst:1030 -msgid "When enabled, this option allows lookup plugins (whether used in variables as ``{{lookup('foo')}}`` or as a loop as with_foo) to return data that is not marked 'unsafe'. By default, such data is marked as unsafe to prevent the templating engine from evaluating any jinja2 templating language, as this could represent a security risk. This option is provided to allow for backwards-compatibility, however users should first consider adding allow_unsafe=True to any lookups which may be expected to contain data which may be run through the templating engine late" -msgstr "このオプションを有効にすると、(変数で ``{{lookup('foo')}}`` として、または with_foo のようなループとして使用されているかに関係なく) lookup プラグインが「安全でない」と表示されていないデータを返します。デフォルトでは、このようなデータは、テンプレートエンジンが jinja2 テンプレート言語を評価できないようにするために、安全ではないと表示されています。これは、セキュリティーリスクを示している場合があるためです。このオプションは、下位互換性を確保するために提供されていますが、ユーザーはまず、後でテンプレートエンジンを介して実行する可能性のあるデータが含まれていると予想されるルックアップに allow_unsafe=True を追加することを検討する必要があります。" - -#: ../../rst/reference_appendices/config.rst:1033 -msgid "2.2.3" -msgstr "2.2.3" - -#: ../../rst/reference_appendices/config.rst:1036 -msgid "allow_unsafe_lookups" -msgstr "allow_unsafe_lookups" - -#: ../../rst/reference_appendices/config.rst:1041 -msgid "DEFAULT_ASK_PASS" -msgstr "DEFAULT_ASK_PASS" - -#: ../../rst/reference_appendices/config.rst:1043 -#: ../../rst/reference_appendices/config.rst:3473 -msgid "This controls whether an Ansible playbook should prompt for a login password. If using SSH keys for authentication, you probably do not need to change this setting." -msgstr "これは、Ansible Playbook がログインパスワードを要求するかどうかを制御します。認証に SSH 鍵を使用する場合は、この設定を変更する必要がない可能性があります。" - -#: ../../rst/reference_appendices/config.rst:1048 -msgid "ask_pass" -msgstr "ask_pass" - -#: ../../rst/reference_appendices/config.rst:1050 -msgid ":envvar:`ANSIBLE_ASK_PASS`" -msgstr ":envvar:`ANSIBLE_ASK_PASS`" - -#: ../../rst/reference_appendices/config.rst:1055 -msgid "DEFAULT_ASK_VAULT_PASS" -msgstr "DEFAULT_ASK_VAULT_PASS" - -#: ../../rst/reference_appendices/config.rst:1057 -#: ../../rst/reference_appendices/config.rst:3481 -msgid "This controls whether an Ansible playbook should prompt for a vault password." -msgstr "これは、Ansible Playbook が Vault パスワードを要求するかどうかを制御します。" - -#: ../../rst/reference_appendices/config.rst:1062 -msgid "ask_vault_pass" -msgstr "ask_vault_pass" - -#: ../../rst/reference_appendices/config.rst:1064 -msgid ":envvar:`ANSIBLE_ASK_VAULT_PASS`" -msgstr ":envvar:`ANSIBLE_ASK_VAULT_PASS`" - -#: ../../rst/reference_appendices/config.rst:1069 -msgid "DEFAULT_BECOME" -msgstr "DEFAULT_BECOME" - -#: ../../rst/reference_appendices/config.rst:1071 -#: ../../rst/reference_appendices/config.rst:3489 -msgid "Toggles the use of privilege escalation, allowing you to 'become' another user after login." -msgstr "権限昇格の使用を切り替えて、ログイン後に別のユーザーになる (「become」) ことができるようにします。" - -#: ../../rst/reference_appendices/config.rst:1076 -#: ../../rst/reference_appendices/playbooks_keywords.rst:29 -#: ../../rst/reference_appendices/playbooks_keywords.rst:166 -#: ../../rst/reference_appendices/playbooks_keywords.rst:261 -#: ../../rst/reference_appendices/playbooks_keywords.rst:371 -msgid "become" -msgstr "become" - -#: ../../rst/reference_appendices/config.rst:1078 -msgid ":envvar:`ANSIBLE_BECOME`" -msgstr ":envvar:`ANSIBLE_BECOME`" - -#: ../../rst/reference_appendices/config.rst:1083 -msgid "DEFAULT_BECOME_ASK_PASS" -msgstr "DEFAULT_BECOME_ASK_PASS" - -#: ../../rst/reference_appendices/config.rst:1085 -#: ../../rst/reference_appendices/config.rst:3497 -msgid "Toggle to prompt for privilege escalation password." -msgstr "切り替えて、権限昇格パスワードの入力を求めます。" - -#: ../../rst/reference_appendices/config.rst:1090 -msgid "become_ask_pass" -msgstr "become_ask_pass" - -#: ../../rst/reference_appendices/config.rst:1092 -msgid ":envvar:`ANSIBLE_BECOME_ASK_PASS`" -msgstr ":envvar:`ANSIBLE_BECOME_ASK_PASS`" - -#: ../../rst/reference_appendices/config.rst:1097 -msgid "DEFAULT_BECOME_EXE" -msgstr "DEFAULT_BECOME_EXE" - -#: ../../rst/reference_appendices/config.rst:1099 -#: ../../rst/reference_appendices/config.rst:3513 -msgid "executable to use for privilege escalation, otherwise Ansible will depend on PATH" -msgstr "特権昇格に使用する実行ファイル。それ以外の場合、Ansible は PATH に依存します。" - -#: ../../rst/reference_appendices/config.rst:1103 -#: ../../rst/reference_appendices/playbooks_keywords.rst:32 -#: ../../rst/reference_appendices/playbooks_keywords.rst:169 -#: ../../rst/reference_appendices/playbooks_keywords.rst:264 -#: ../../rst/reference_appendices/playbooks_keywords.rst:374 -msgid "become_exe" -msgstr "become_exe" - -#: ../../rst/reference_appendices/config.rst:1105 -msgid ":envvar:`ANSIBLE_BECOME_EXE`" -msgstr ":envvar:`ANSIBLE_BECOME_EXE`" - -#: ../../rst/reference_appendices/config.rst:1110 -msgid "DEFAULT_BECOME_FLAGS" -msgstr "DEFAULT_BECOME_FLAGS" - -#: ../../rst/reference_appendices/config.rst:1112 -#: ../../rst/reference_appendices/config.rst:3521 -msgid "Flags to pass to the privilege escalation executable." -msgstr "権限昇格実行ファイルに渡すフラグ。" - -#: ../../rst/reference_appendices/config.rst:1116 -#: ../../rst/reference_appendices/playbooks_keywords.rst:35 -#: ../../rst/reference_appendices/playbooks_keywords.rst:172 -#: ../../rst/reference_appendices/playbooks_keywords.rst:267 -#: ../../rst/reference_appendices/playbooks_keywords.rst:377 -msgid "become_flags" -msgstr "become_flags" - -#: ../../rst/reference_appendices/config.rst:1118 -msgid ":envvar:`ANSIBLE_BECOME_FLAGS`" -msgstr ":envvar:`ANSIBLE_BECOME_FLAGS`" - -#: ../../rst/reference_appendices/config.rst:1123 -msgid "DEFAULT_BECOME_METHOD" -msgstr "DEFAULT_BECOME_METHOD" - -#: ../../rst/reference_appendices/config.rst:1125 -#: ../../rst/reference_appendices/config.rst:3505 -msgid "Privilege escalation method to use when `become` is enabled." -msgstr "`become` が有効な場合に使用する権限昇格方法です。" - -#: ../../rst/reference_appendices/config.rst:1126 -msgid "sudo" -msgstr "sudo" - -#: ../../rst/reference_appendices/config.rst:1129 -#: ../../rst/reference_appendices/playbooks_keywords.rst:38 -#: ../../rst/reference_appendices/playbooks_keywords.rst:175 -#: ../../rst/reference_appendices/playbooks_keywords.rst:270 -#: ../../rst/reference_appendices/playbooks_keywords.rst:380 -msgid "become_method" -msgstr "become_method" - -#: ../../rst/reference_appendices/config.rst:1131 -msgid ":envvar:`ANSIBLE_BECOME_METHOD`" -msgstr ":envvar:`ANSIBLE_BECOME_METHOD`" - -#: ../../rst/reference_appendices/config.rst:1136 -msgid "DEFAULT_BECOME_USER" -msgstr "DEFAULT_BECOME_USER" - -#: ../../rst/reference_appendices/config.rst:1138 -#: ../../rst/reference_appendices/config.rst:3537 -msgid "The user your login/remote user 'becomes' when using privilege escalation, most systems will use 'root' when no user is specified." -msgstr "権限昇格を使用する際にログイン/リモートユーザーが「なる(becomes)」ユーザー。ユーザーを指定しないと、ほとんどのシステムは「root」を使用します。" - -#: ../../rst/reference_appendices/config.rst:1139 -msgid "root" -msgstr "root" - -#: ../../rst/reference_appendices/config.rst:1142 -#: ../../rst/reference_appendices/playbooks_keywords.rst:41 -#: ../../rst/reference_appendices/playbooks_keywords.rst:178 -#: ../../rst/reference_appendices/playbooks_keywords.rst:273 -#: ../../rst/reference_appendices/playbooks_keywords.rst:383 -msgid "become_user" -msgstr "become_user" - -#: ../../rst/reference_appendices/config.rst:1144 -msgid ":envvar:`ANSIBLE_BECOME_USER`" -msgstr ":envvar:`ANSIBLE_BECOME_USER`" - -#: ../../rst/reference_appendices/config.rst:1149 -msgid "DEFAULT_CACHE_PLUGIN_PATH" -msgstr "DEFAULT_CACHE_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1151 -#: ../../rst/reference_appendices/config.rst:3545 -msgid "Colon separated paths in which Ansible will search for Cache Plugins." -msgstr "Ansible が Cache プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1153 -msgid "~/.ansible/plugins/cache:/usr/share/ansible/plugins/cache" -msgstr "~/.ansible/plugins/cache:/usr/share/ansible/plugins/cache" - -#: ../../rst/reference_appendices/config.rst:1156 -msgid "cache_plugins" -msgstr "cache_plugins" - -#: ../../rst/reference_appendices/config.rst:1158 -msgid ":envvar:`ANSIBLE_CACHE_PLUGINS`" -msgstr ":envvar:`ANSIBLE_CACHE_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1163 -msgid "DEFAULT_CALLBACK_PLUGIN_PATH" -msgstr "DEFAULT_CALLBACK_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1165 -#: ../../rst/reference_appendices/config.rst:3580 -msgid "Colon separated paths in which Ansible will search for Callback Plugins." -msgstr "Ansible が Callback プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1167 -msgid "~/.ansible/plugins/callback:/usr/share/ansible/plugins/callback" -msgstr "~/.ansible/plugins/callback:/usr/share/ansible/plugins/callback" - -#: ../../rst/reference_appendices/config.rst:1170 -msgid "callback_plugins" -msgstr "callback_plugins" - -#: ../../rst/reference_appendices/config.rst:1172 -msgid ":envvar:`ANSIBLE_CALLBACK_PLUGINS`" -msgstr ":envvar:`ANSIBLE_CALLBACK_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1177 -msgid "DEFAULT_CLICONF_PLUGIN_PATH" -msgstr "DEFAULT_CLICONF_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1179 -#: ../../rst/reference_appendices/config.rst:3607 -msgid "Colon separated paths in which Ansible will search for Cliconf Plugins." -msgstr "Ansible が Cliconf プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1181 -msgid "~/.ansible/plugins/cliconf:/usr/share/ansible/plugins/cliconf" -msgstr "~/.ansible/plugins/cliconf:/usr/share/ansible/plugins/cliconf" - -#: ../../rst/reference_appendices/config.rst:1184 -msgid "cliconf_plugins" -msgstr "cliconf_plugins" - -#: ../../rst/reference_appendices/config.rst:1186 -msgid ":envvar:`ANSIBLE_CLICONF_PLUGINS`" -msgstr ":envvar:`ANSIBLE_CLICONF_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1191 -msgid "DEFAULT_CONNECTION_PLUGIN_PATH" -msgstr "DEFAULT_CONNECTION_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1193 -#: ../../rst/reference_appendices/config.rst:3615 -msgid "Colon separated paths in which Ansible will search for Connection Plugins." -msgstr "Ansible が connection プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1195 -msgid "~/.ansible/plugins/connection:/usr/share/ansible/plugins/connection" -msgstr "~/.ansible/plugins/connection:/usr/share/ansible/plugins/connection" - -#: ../../rst/reference_appendices/config.rst:1198 -msgid "connection_plugins" -msgstr "connection_plugins" - -#: ../../rst/reference_appendices/config.rst:1200 -msgid ":envvar:`ANSIBLE_CONNECTION_PLUGINS`" -msgstr ":envvar:`ANSIBLE_CONNECTION_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1205 -msgid "DEFAULT_DEBUG" -msgstr "DEFAULT_DEBUG" - -#: ../../rst/reference_appendices/config.rst:1207 -#: ../../rst/reference_appendices/config.rst:3623 -msgid "Toggles debug output in Ansible. This is *very* verbose and can hinder multiprocessing. Debug output can also include secret information despite no_log settings being enabled, which means debug mode should not be used in production." -msgstr "Ansible でデバッグ出力を切り替えます。これは *非常に* 詳細であり、マルチプロセッシングを妨げる可能性があります。no_log 設定が有効になっている場合でも、デバッグ出力に秘密情報を含めることができます。つまり、デバッグモードは、実稼働環境で使用しないでください。" - -#: ../../rst/reference_appendices/config.rst:1214 -msgid ":envvar:`ANSIBLE_DEBUG`" -msgstr ":envvar:`ANSIBLE_DEBUG`" - -#: ../../rst/reference_appendices/config.rst:1219 -msgid "DEFAULT_EXECUTABLE" -msgstr "DEFAULT_EXECUTABLE" - -#: ../../rst/reference_appendices/config.rst:1221 -#: ../../rst/reference_appendices/config.rst:3631 -msgid "This indicates the command to use to spawn a shell under for Ansible's execution needs on a target. Users may need to change this in rare instances when shell usage is constrained, but in most cases it may be left as is." -msgstr "これは、ターゲットでの Ansible の実行ニーズに合わせてシェルを生成するために使用するコマンドを示します。シェルの使用が制限されている場合、ユーザーはまれにこれを変更する必要がありますが、ほとんどの場合、そのままにしておくことができます。" - -#: ../../rst/reference_appendices/config.rst:1222 -msgid "/bin/sh" -msgstr "/bin/sh" - -#: ../../rst/reference_appendices/config.rst:1225 -msgid "executable" -msgstr "executable" - -#: ../../rst/reference_appendices/config.rst:1227 -msgid ":envvar:`ANSIBLE_EXECUTABLE`" -msgstr ":envvar:`ANSIBLE_EXECUTABLE`" - -#: ../../rst/reference_appendices/config.rst:1232 -msgid "DEFAULT_FACT_PATH" -msgstr "DEFAULT_FACT_PATH" - -#: ../../rst/reference_appendices/config.rst:1234 -msgid "This option allows you to globally configure a custom path for 'local_facts' for the implied M(ansible.builtin.setup) task when using fact gathering. If not set, it will fallback to the default from the M(ansible.builtin.setup) module: ``/etc/ansible/facts.d``. This does **not** affect user defined tasks that use the M(ansible.builtin.setup) module." -msgstr "このオプションを使用すると、ファクト収集を使用するときに、暗黙の M(ansible.builtin.setup) タスクの「local_facts」のカスタムパスをグローバルに設定できます。設定されていない場合は、M(ansible.builtin.setup) モジュールからデフォルトにフォールバックします (``/etc/ansible/facts.d``)。これは、M(ansible.builtin.setup) モジュールを使用するユーザー定義のタスクには **影響しません**。" - -#: ../../rst/reference_appendices/config.rst:1239 -#: ../../rst/reference_appendices/playbooks_keywords.rst:68 -msgid "fact_path" -msgstr "fact_path" - -#: ../../rst/reference_appendices/config.rst:1241 -msgid ":envvar:`ANSIBLE_FACT_PATH`" -msgstr ":envvar:`ANSIBLE_FACT_PATH`" - -#: ../../rst/reference_appendices/config.rst:1246 -msgid "DEFAULT_FILTER_PLUGIN_PATH" -msgstr "DEFAULT_FILTER_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1248 -#: ../../rst/reference_appendices/config.rst:3647 -msgid "Colon separated paths in which Ansible will search for Jinja2 Filter Plugins." -msgstr "Ansible が Jinja2 フィルタープラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1250 -msgid "~/.ansible/plugins/filter:/usr/share/ansible/plugins/filter" -msgstr "~/.ansible/plugins/filter:/usr/share/ansible/plugins/filter" - -#: ../../rst/reference_appendices/config.rst:1253 -msgid "filter_plugins" -msgstr "filter_plugins" - -#: ../../rst/reference_appendices/config.rst:1255 -msgid ":envvar:`ANSIBLE_FILTER_PLUGINS`" -msgstr ":envvar:`ANSIBLE_FILTER_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1260 -msgid "DEFAULT_FORCE_HANDLERS" -msgstr "DEFAULT_FORCE_HANDLERS" - -#: ../../rst/reference_appendices/config.rst:1262 -msgid "This option controls if notified handlers run on a host even if a failure occurs on that host. When false, the handlers will not run if a failure has occurred on a host. This can also be set per play or on the command line. See Handlers and Failure for more details." -msgstr "このオプションは、ホストで障害が発生した場合でも、通知されたハンドラーがホストで実行されるかどうかを制御します。false にすると、ホストで障害が発生した場合に、ハンドラーは実行されません。これは、プレイごとまたはコマンドラインで設定することもできます。詳細は、「ハンドラーおよび失敗」を参照してください。" - -#: ../../rst/reference_appendices/config.rst:1265 -msgid "1.9.1" -msgstr "1.9.1" - -#: ../../rst/reference_appendices/config.rst:1268 -#: ../../rst/reference_appendices/playbooks_keywords.rst:71 -msgid "force_handlers" -msgstr "force_handlers" - -#: ../../rst/reference_appendices/config.rst:1270 -msgid ":envvar:`ANSIBLE_FORCE_HANDLERS`" -msgstr ":envvar:`ANSIBLE_FORCE_HANDLERS`" - -#: ../../rst/reference_appendices/config.rst:1275 -msgid "DEFAULT_FORKS" -msgstr "DEFAULT_FORKS" - -#: ../../rst/reference_appendices/config.rst:1277 -#: ../../rst/reference_appendices/config.rst:3663 -msgid "Maximum number of forks Ansible will use to execute tasks on target hosts." -msgstr "ターゲットホストでタスクを実行するのに Ansible が使用するフォークの最大数。" - -#: ../../rst/reference_appendices/config.rst:1279 -#: ../../rst/reference_appendices/config.rst:3063 -msgid "5" -msgstr "5" - -#: ../../rst/reference_appendices/config.rst:1282 -msgid "forks" -msgstr "forks" - -#: ../../rst/reference_appendices/config.rst:1284 -msgid ":envvar:`ANSIBLE_FORKS`" -msgstr ":envvar:`ANSIBLE_FORKS`" - -#: ../../rst/reference_appendices/config.rst:1289 -msgid "DEFAULT_GATHER_SUBSET" -msgstr "DEFAULT_GATHER_SUBSET" - -#: ../../rst/reference_appendices/config.rst:1291 -msgid "Set the `gather_subset` option for the M(ansible.builtin.setup) task in the implicit fact gathering. See the module documentation for specifics. It does **not** apply to user defined M(ansible.builtin.setup) tasks." -msgstr "暗黙的なファクト収集の M(ansible.builtin.setup) タスクに `gather_subset` オプションを設定します。詳細は、モジュールドキュメントを参照してください。ユーザー定義の M(ansible.builtin.setup) タスクには **適用されません**。" - -#: ../../rst/reference_appendices/config.rst:1293 -msgid "['all']" -msgstr "['all']" - -#: ../../rst/reference_appendices/config.rst:1297 -#: ../../rst/reference_appendices/playbooks_keywords.rst:77 -msgid "gather_subset" -msgstr "gather_subset" - -#: ../../rst/reference_appendices/config.rst:1299 -msgid ":envvar:`ANSIBLE_GATHER_SUBSET`" -msgstr ":envvar:`ANSIBLE_GATHER_SUBSET`" - -#: ../../rst/reference_appendices/config.rst:1304 -msgid "DEFAULT_GATHER_TIMEOUT" -msgstr "DEFAULT_GATHER_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:1306 -msgid "Set the timeout in seconds for the implicit fact gathering. It does **not** apply to user defined M(ansible.builtin.setup) tasks." -msgstr "暗黙的なファクト収集のタイムアウトを秒単位で設定します。ユーザー定義の M(ansible.builtin.setup) タスクには **適用されません**。" - -#: ../../rst/reference_appendices/config.rst:1308 -#: ../../rst/reference_appendices/config.rst:1906 -msgid "10" -msgstr "10" - -#: ../../rst/reference_appendices/config.rst:1311 -#: ../../rst/reference_appendices/playbooks_keywords.rst:80 -msgid "gather_timeout" -msgstr "gather_timeout" - -#: ../../rst/reference_appendices/config.rst:1313 -msgid ":envvar:`ANSIBLE_GATHER_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_GATHER_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:1318 -msgid "DEFAULT_GATHERING" -msgstr "DEFAULT_GATHERING" - -#: ../../rst/reference_appendices/config.rst:1320 -msgid "This setting controls the default policy of fact gathering (facts discovered about remote systems). When 'implicit' (the default), the cache plugin will be ignored and facts will be gathered per play unless 'gather_facts: False' is set. When 'explicit' the inverse is true, facts will not be gathered unless directly requested in the play. The 'smart' value means each new host that has no facts discovered will be scanned, but if the same host is addressed in multiple plays it will not be contacted again in the playbook run. This option can be useful for those wishing to save fact gathering time. Both 'smart' and 'explicit' will use the cache plugin." -msgstr "この設定は、ファクト収集 (リモートシステムに関して検出されたファクト) のデフォルトポリシーを制御します。「implicit」(デフォルト) の場合、cache プラグインは無視され、「gather_facts: False」が設定されていない限り、プレイごとにファクトが収集されます。「explicit」の場合はその逆で、プレイ中に直接要求されない限り、ファクトは収集されません。「smart」の値は、検出されたファクトを持たない各新規ホストがスキャンされることを意味しますが、同じホストが複数のプレイで扱われた場合は、Playbook の実行中に再び接触することはありません。このオプションは、ファクト収集の時間を短縮したい場合に便利です。「smart」と「explicit」の両方とも、cache プラグインを使用します。" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:1321 -msgid "implicit" -msgstr "implicit" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:1919 -msgid "smart" -msgstr "smart" - -#: ../../rst/reference_appendices/config.rst -msgid "explicit" -msgstr "explicit" - -#: ../../rst/reference_appendices/config.rst:1326 -msgid "1.6" -msgstr "1.6" - -#: ../../rst/reference_appendices/config.rst:1329 -msgid "gathering" -msgstr "gathering" - -#: ../../rst/reference_appendices/config.rst:1331 -msgid ":envvar:`ANSIBLE_GATHERING`" -msgstr ":envvar:`ANSIBLE_GATHERING`" - -#: ../../rst/reference_appendices/config.rst:1336 -msgid "DEFAULT_HANDLER_INCLUDES_STATIC" -msgstr "DEFAULT_HANDLER_INCLUDES_STATIC" - -#: ../../rst/reference_appendices/config.rst:1338 -#: ../../rst/reference_appendices/config.rst:3695 -msgid "Since 2.0 M(ansible.builtin.include) can be 'dynamic', this setting (if True) forces that if the include appears in a ``handlers`` section to be 'static'." -msgstr "2.0 M(ansible.builtin.include) は「動的」である可能性があるため、この設定 (True の場合) は、``handlers`` セクションに表示されるインクルードが「静的」になります。" - -#: ../../rst/reference_appendices/config.rst:1343 -msgid "handler_includes_static" -msgstr "handler_includes_static" - -#: ../../rst/reference_appendices/config.rst:1345 -msgid ":envvar:`ANSIBLE_HANDLER_INCLUDES_STATIC`" -msgstr ":envvar:`ANSIBLE_HANDLER_INCLUDES_STATIC`" - -#: ../../rst/reference_appendices/config.rst:1346 -#: ../../rst/reference_appendices/config.rst:1479 -#: ../../rst/reference_appendices/config.rst:1867 -#: ../../rst/reference_appendices/config.rst:2121 -#: ../../rst/reference_appendices/config.rst:2647 -#: ../../rst/reference_appendices/config.rst:2792 -#: ../../rst/reference_appendices/config.rst:3764 -#: ../../rst/reference_appendices/config.rst:4138 -#: ../../rst/reference_appendices/config.rst:4392 -msgid "2.12" -msgstr "2.12" - -#: ../../rst/reference_appendices/config.rst:1347 -#: ../../rst/reference_appendices/config.rst:1868 -msgid "include itself is deprecated and this setting will not matter in the future" -msgstr "インクルード自体は非推奨であるため、この設定は今後重要ではありません。" - -#: ../../rst/reference_appendices/config.rst:1348 -msgid "none as its already built into the decision between include_tasks and import_tasks" -msgstr "include_tasks と import_tasks の決定にすでに組み込まれてるため、none です。" - -#: ../../rst/reference_appendices/config.rst:1353 -msgid "DEFAULT_HASH_BEHAVIOUR" -msgstr "DEFAULT_HASH_BEHAVIOUR" - -#: ../../rst/reference_appendices/config.rst:1355 -msgid "This setting controls how duplicate definitions of dictionary variables (aka hash, map, associative array) are handled in Ansible. This does not affect variables whose values are scalars (integers, strings) or arrays. **WARNING**, changing this setting is not recommended as this is fragile and makes your content (plays, roles, collections) non portable, leading to continual confusion and misuse. Don't change this setting unless you think you have an absolute need for it. We recommend avoiding reusing variable names and relying on the ``combine`` filter and ``vars`` and ``varnames`` lookups to create merged versions of the individual variables. In our experience this is rarely really needed and a sign that too much complexity has been introduced into the data structures and plays. For some uses you can also look into custom vars_plugins to merge on input, even substituting the default ``host_group_vars`` that is in charge of parsing the ``host_vars/`` and ``group_vars/`` directories. Most users of this setting are only interested in inventory scope, but the setting itself affects all sources and makes debugging even harder. All playbooks and roles in the official examples repos assume the default for this setting. Changing the setting to ``merge`` applies across variable sources, but many sources will internally still overwrite the variables. For example ``include_vars`` will dedupe variables internally before updating Ansible, with 'last defined' overwriting previous definitions in same file. The Ansible project recommends you **avoid ``merge`` for new projects.** It is the intention of the Ansible developers to eventually deprecate and remove this setting, but it is being kept as some users do heavily rely on it. New projects should **avoid 'merge'**." -msgstr "この設定は、辞書変数 (別名ハッシュ、マップ、連想配列) の重複した定義を Ansible でどのように扱うかを制御します。この設定は、値がスカラー (整数、文字列) や配列である変数には影響しません。**警告** これは脆弱で、コンテンツ (プレイ、ロール、コレクション) が移植できなくなり、継続的な混乱と誤用を招く恐れがあるため、この設定を変更することは推奨されません。絶対に必要だと思われる場合を除き、この設定を変更しないでください。変数名の再利用は回避し、``combine`` フィルターと``vars`` ルックアップおよび``varnames`` ルックアップを利用して、個々の変数のマージバージョンを作成することが推奨されます。経験上、このようなことが本当に必要とされることはほとんどなく、データ構造やプレイが複雑になりすぎていることを示しています。用途によっては、入力時にマージするカスタム vars_plugins を検討することもできますし、``host_vars/`` ディレクトリーおよび ``group_vars/`` ディレクトリーの解析を担当するデフォルトの ``host_group_vars`` を置き換えることもできます。この設定のほとんどのユーザーはインベントリースコープにしか興味がありませんが、この設定自体がすべてのソースに影響し、デバッグをさらに困難にします。公式のサンプルリポジトリーにある Playbook およびロールはすべて、この設定のデフォルトを想定しています。``merge`` に設定を変更すると、変数ソース全体に適用されますが、多くのソースでは内部的に変数が上書きされたままになります。たとえば、``include_vars`` は、Ansible を更新する前に内部で変数の重複を排除し、「最終定義」が同じファイルの以前の定義を上書きします。Ansible プロジェクトでは、**新規プロジェクトでは ``merge`` を回避する** ことが推奨されます。Ansible 開発者は、最終的にこの設定を非推奨にして削除することを意図していますが、一部のユーザーがこの設定に大きく依存しているため、この設定を残しています。新しいプロジェクトでは、**「merge」を回避** してください。" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:1357 -msgid "replace" -msgstr "replace" - -#: ../../rst/reference_appendices/config.rst:1359 -msgid "Any variable that is defined more than once is overwritten using the order from variable precedence rules (highest wins)." -msgstr "複数の変数が定義されている変数は、変数の優先順位ルール (最も高いものが優先されます) の順序を使用して上書きされます。" - -#: ../../rst/reference_appendices/config.rst -msgid "merge" -msgstr "merge" - -#: ../../rst/reference_appendices/config.rst:1360 -msgid "Any dictionary variable will be recursively merged with new definitions across the different variable definition sources." -msgstr "ディクショナリー変数は、異なる変数定義ソース全体で新しい定義と再帰的にマージされます。" - -#: ../../rst/reference_appendices/config.rst:1363 -msgid "hash_behaviour" -msgstr "hash_behaviour" - -#: ../../rst/reference_appendices/config.rst:1365 -msgid ":envvar:`ANSIBLE_HASH_BEHAVIOUR`" -msgstr ":envvar:`ANSIBLE_HASH_BEHAVIOUR`" - -#: ../../rst/reference_appendices/config.rst:1370 -msgid "DEFAULT_HOST_LIST" -msgstr "DEFAULT_HOST_LIST" - -#: ../../rst/reference_appendices/config.rst:1372 -#: ../../rst/reference_appendices/config.rst:3711 -msgid "Comma separated list of Ansible inventory sources" -msgstr "Ansible インベントリーソースのコンマ区切り一覧" - -#: ../../rst/reference_appendices/config.rst:1373 -msgid "pathlist" -msgstr "pathlist" - -#: ../../rst/reference_appendices/config.rst:1374 -msgid "/etc/ansible/hosts" -msgstr "/etc/ansible/hosts" - -#: ../../rst/reference_appendices/config.rst:1377 -msgid "inventory" -msgstr "inventory" - -#: ../../rst/reference_appendices/config.rst:1379 -msgid ":envvar:`ANSIBLE_INVENTORY`" -msgstr ":envvar:`ANSIBLE_INVENTORY`" - -#: ../../rst/reference_appendices/config.rst:1384 -msgid "DEFAULT_HTTPAPI_PLUGIN_PATH" -msgstr "DEFAULT_HTTPAPI_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1386 -#: ../../rst/reference_appendices/config.rst:3719 -msgid "Colon separated paths in which Ansible will search for HttpApi Plugins." -msgstr "Ansible が HttpApi プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1388 -msgid "~/.ansible/plugins/httpapi:/usr/share/ansible/plugins/httpapi" -msgstr "~/.ansible/plugins/httpapi:/usr/share/ansible/plugins/httpapi" - -#: ../../rst/reference_appendices/config.rst:1391 -msgid "httpapi_plugins" -msgstr "httpapi_plugins" - -#: ../../rst/reference_appendices/config.rst:1393 -msgid ":envvar:`ANSIBLE_HTTPAPI_PLUGINS`" -msgstr ":envvar:`ANSIBLE_HTTPAPI_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1398 -msgid "DEFAULT_INTERNAL_POLL_INTERVAL" -msgstr "DEFAULT_INTERNAL_POLL_INTERVAL" - -#: ../../rst/reference_appendices/config.rst:1400 -msgid "This sets the interval (in seconds) of Ansible internal processes polling each other. Lower values improve performance with large playbooks at the expense of extra CPU load. Higher values are more suitable for Ansible usage in automation scenarios, when UI responsiveness is not required but CPU usage might be a concern. The default corresponds to the value hardcoded in Ansible <= 2.1" -msgstr "これにより、Ansible の内部プロセスが相互にポーリングする間隔 (秒単位) が設定されます。値を低くすると、CPU の負荷が増える代わりに、大きな Playbook のパフォーマンスが改善します。UI の応答性は必要ありませんが、CPU 使用率が問題になる可能性がある場合は、自動化シナリオでの Ansible の使用には高い値が適しています。デフォルトは、2.1 以下の Ansible でハードコードされた値に対応します" - -#: ../../rst/reference_appendices/config.rst:1401 -#: ../../rst/reference_appendices/config.rst:3091 -msgid "float" -msgstr "float" - -#: ../../rst/reference_appendices/config.rst:1402 -msgid "0.001" -msgstr "0.001" - -#: ../../rst/reference_appendices/config.rst:1403 -msgid "2.2" -msgstr "2.2" - -#: ../../rst/reference_appendices/config.rst:1406 -msgid "internal_poll_interval" -msgstr "internal_poll_interval" - -#: ../../rst/reference_appendices/config.rst:1411 -msgid "DEFAULT_INVENTORY_PLUGIN_PATH" -msgstr "DEFAULT_INVENTORY_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1413 -#: ../../rst/reference_appendices/config.rst:3728 -msgid "Colon separated paths in which Ansible will search for Inventory Plugins." -msgstr "Ansible が inventory プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1415 -msgid "~/.ansible/plugins/inventory:/usr/share/ansible/plugins/inventory" -msgstr "~/.ansible/plugins/inventory:/usr/share/ansible/plugins/inventory" - -#: ../../rst/reference_appendices/config.rst:1418 -msgid "inventory_plugins" -msgstr "inventory_plugins" - -#: ../../rst/reference_appendices/config.rst:1420 -msgid ":envvar:`ANSIBLE_INVENTORY_PLUGINS`" -msgstr ":envvar:`ANSIBLE_INVENTORY_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1425 -msgid "DEFAULT_JINJA2_EXTENSIONS" -msgstr "DEFAULT_JINJA2_EXTENSIONS" - -#: ../../rst/reference_appendices/config.rst:1427 -msgid "This is a developer-specific feature that allows enabling additional Jinja2 extensions. See the Jinja2 documentation for details. If you do not know what these do, you probably don't need to change this setting :)" -msgstr "これは、追加の Jinja2 拡張機能を有効にすることができる開発者固有の機能です。詳細については、Jinja2 ドキュメントを参照してください。この拡張機能が何をするのかわからない場合は、おそらくこの設定を変更する必要はありません。" - -#: ../../rst/reference_appendices/config.rst:1431 -msgid "jinja2_extensions" -msgstr "jinja2_extensions" - -#: ../../rst/reference_appendices/config.rst:1433 -msgid ":envvar:`ANSIBLE_JINJA2_EXTENSIONS`" -msgstr ":envvar:`ANSIBLE_JINJA2_EXTENSIONS`" - -#: ../../rst/reference_appendices/config.rst:1438 -msgid "DEFAULT_JINJA2_NATIVE" -msgstr "DEFAULT_JINJA2_NATIVE" - -#: ../../rst/reference_appendices/config.rst:1440 -#: ../../rst/reference_appendices/config.rst:3744 -msgid "This option preserves variable types during template operations. This requires Jinja2 >= 2.10." -msgstr "このオプションは、テンプレート操作中、変数タイプを保持します。これには Jinja2 >= 2.10 が必要です。" - -#: ../../rst/reference_appendices/config.rst:1446 -msgid "jinja2_native" -msgstr "jinja2_native" - -#: ../../rst/reference_appendices/config.rst:1448 -msgid ":envvar:`ANSIBLE_JINJA2_NATIVE`" -msgstr ":envvar:`ANSIBLE_JINJA2_NATIVE`" - -#: ../../rst/reference_appendices/config.rst:1453 -msgid "DEFAULT_KEEP_REMOTE_FILES" -msgstr "DEFAULT_KEEP_REMOTE_FILES" - -#: ../../rst/reference_appendices/config.rst:1455 -msgid "Enables/disables the cleaning up of the temporary files Ansible used to execute the tasks on the remote. If this option is enabled it will disable ``ANSIBLE_PIPELINING``." -msgstr "リモートでタスクを実行するために Ansible が使用する一時ファイルのクリーンアップを有効または無効にします。このオプションを有効にすると、``ANSIBLE_PIPELINING`` を無効にします。" - -#: ../../rst/reference_appendices/config.rst:1460 -msgid "keep_remote_files" -msgstr "keep_remote_files" - -#: ../../rst/reference_appendices/config.rst:1462 -msgid ":envvar:`ANSIBLE_KEEP_REMOTE_FILES`" -msgstr ":envvar:`ANSIBLE_KEEP_REMOTE_FILES`" - -#: ../../rst/reference_appendices/config.rst:1467 -msgid "DEFAULT_LIBVIRT_LXC_NOSECLABEL" -msgstr "DEFAULT_LIBVIRT_LXC_NOSECLABEL" - -#: ../../rst/reference_appendices/config.rst:1469 -#: ../../rst/reference_appendices/config.rst:3760 -#: ../../rst/reference_appendices/config.rst:3770 -msgid "This setting causes libvirt to connect to lxc containers by passing --noseclabel to virsh. This is necessary when running on systems which do not have SELinux." -msgstr "この設定により、--noseclabel を virsh に渡して、libvirt が lxc コンテナーに接続します。これは、SELinux がないシステムで実行する際に必要です。" - -#: ../../rst/reference_appendices/config.rst:1474 -#: ../../rst/reference_appendices/config.rst:1779 -msgid "[selinux]" -msgstr "[selinux]" - -#: ../../rst/reference_appendices/config.rst:1475 -msgid "libvirt_lxc_noseclabel" -msgstr "libvirt_lxc_noseclabel" - -#: ../../rst/reference_appendices/config.rst:1477 -msgid ":envvar:`ANSIBLE_LIBVIRT_LXC_NOSECLABEL`" -msgstr ":envvar:`ANSIBLE_LIBVIRT_LXC_NOSECLABEL`" - -#: ../../rst/reference_appendices/config.rst:1478 -msgid ":envvar:`LIBVIRT_LXC_NOSECLABEL`" -msgstr ":envvar:`LIBVIRT_LXC_NOSECLABEL`" - -#: ../../rst/reference_appendices/config.rst:1480 -#: ../../rst/reference_appendices/config.rst:2122 -#: ../../rst/reference_appendices/config.rst:2648 -#: ../../rst/reference_appendices/config.rst:3765 -#: ../../rst/reference_appendices/config.rst:4139 -#: ../../rst/reference_appendices/config.rst:4393 -msgid "environment variables without ``ANSIBLE_`` prefix are deprecated" -msgstr "``ANSIBLE_`` 接頭辞のない環境変数が非推奨になりました。" - -#: ../../rst/reference_appendices/config.rst:1481 -#: ../../rst/reference_appendices/config.rst:3766 -msgid "the ``ANSIBLE_LIBVIRT_LXC_NOSECLABEL`` environment variable" -msgstr "``ANSIBLE_LIBVIRT_LXC_NOSECLABEL`` 環境変数" - -#: ../../rst/reference_appendices/config.rst:1486 -msgid "DEFAULT_LOAD_CALLBACK_PLUGINS" -msgstr "DEFAULT_LOAD_CALLBACK_PLUGINS" - -#: ../../rst/reference_appendices/config.rst:1488 -#: ../../rst/reference_appendices/config.rst:3778 -msgid "Controls whether callback plugins are loaded when running /usr/bin/ansible. This may be used to log activity from the command line, send notifications, and so on. Callback plugins are always loaded for ``ansible-playbook``." -msgstr "/usr/bin/ansible の実行時に callback プラグインを読み込まれるかどうかを制御します。これは、コマンドラインからのアクティビティのログ記録、通知の送信などに使用できます。``ansible-playbook`` に callback プラグインが常に読み込まれます。" - -#: ../../rst/reference_appendices/config.rst:1494 -msgid "bin_ansible_callbacks" -msgstr "bin_ansible_callbacks" - -#: ../../rst/reference_appendices/config.rst:1496 -msgid ":envvar:`ANSIBLE_LOAD_CALLBACK_PLUGINS`" -msgstr ":envvar:`ANSIBLE_LOAD_CALLBACK_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1501 -msgid "DEFAULT_LOCAL_TMP" -msgstr "DEFAULT_LOCAL_TMP" - -#: ../../rst/reference_appendices/config.rst:1503 -#: ../../rst/reference_appendices/config.rst:3786 -msgid "Temporary directory for Ansible to use on the controller." -msgstr "Ansible がコントローラーで使用するための一時ディレクトリー。" - -#: ../../rst/reference_appendices/config.rst:1504 -msgid "tmppath" -msgstr "tmppath" - -#: ../../rst/reference_appendices/config.rst:1505 -msgid "~/.ansible/tmp" -msgstr "~/.ansible/tmp" - -#: ../../rst/reference_appendices/config.rst:1508 -msgid "local_tmp" -msgstr "local_tmp" - -#: ../../rst/reference_appendices/config.rst:1510 -msgid ":envvar:`ANSIBLE_LOCAL_TEMP`" -msgstr ":envvar:`ANSIBLE_LOCAL_TEMP`" - -#: ../../rst/reference_appendices/config.rst:1515 -msgid "DEFAULT_LOG_FILTER" -msgstr "DEFAULT_LOG_FILTER" - -#: ../../rst/reference_appendices/config.rst:1517 -#: ../../rst/reference_appendices/config.rst:3802 -msgid "List of logger names to filter out of the log file" -msgstr "ログファイルから除外するロガー名の一覧" - -#: ../../rst/reference_appendices/config.rst:1522 -msgid "log_filter" -msgstr "log_filter" - -#: ../../rst/reference_appendices/config.rst:1524 -msgid ":envvar:`ANSIBLE_LOG_FILTER`" -msgstr ":envvar:`ANSIBLE_LOG_FILTER`" - -#: ../../rst/reference_appendices/config.rst:1529 -msgid "DEFAULT_LOG_PATH" -msgstr "DEFAULT_LOG_PATH" - -#: ../../rst/reference_appendices/config.rst:1531 -#: ../../rst/reference_appendices/config.rst:3794 -msgid "File to which Ansible will log on the controller. When empty logging is disabled." -msgstr "Ansible がコントローラーにログインするファイル。空のロギングが無効になっている場合。" - -#: ../../rst/reference_appendices/config.rst:1536 -msgid "log_path" -msgstr "log_path" - -#: ../../rst/reference_appendices/config.rst:1538 -msgid ":envvar:`ANSIBLE_LOG_PATH`" -msgstr ":envvar:`ANSIBLE_LOG_PATH`" - -#: ../../rst/reference_appendices/config.rst:1543 -msgid "DEFAULT_LOOKUP_PLUGIN_PATH" -msgstr "DEFAULT_LOOKUP_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1545 -#: ../../rst/reference_appendices/config.rst:3810 -msgid "Colon separated paths in which Ansible will search for Lookup Plugins." -msgstr "Ansible が Lookup プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1547 -msgid "~/.ansible/plugins/lookup:/usr/share/ansible/plugins/lookup" -msgstr "~/.ansible/plugins/lookup:/usr/share/ansible/plugins/lookup" - -#: ../../rst/reference_appendices/config.rst:1550 -msgid "lookup_plugins" -msgstr "lookup_plugins" - -#: ../../rst/reference_appendices/config.rst:1552 -msgid ":envvar:`ANSIBLE_LOOKUP_PLUGINS`" -msgstr ":envvar:`ANSIBLE_LOOKUP_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1557 -msgid "DEFAULT_MANAGED_STR" -msgstr "DEFAULT_MANAGED_STR" - -#: ../../rst/reference_appendices/config.rst:1559 -msgid "Sets the macro for the 'ansible_managed' variable available for M(ansible.builtin.template) and M(ansible.windows.win_template) modules. This is only relevant for those two modules." -msgstr "M(ansible.builtin.template) モジュールおよび M(ansible.windows.win_template) モジュールで使用可能な「ansible_managed」変数にマクロを設定します。これは、これら 2 つのモジュールにのみ関係します。" - -#: ../../rst/reference_appendices/config.rst:1560 -msgid "Ansible managed" -msgstr "Ansible が管理" - -#: ../../rst/reference_appendices/config.rst:1563 -msgid "ansible_managed" -msgstr "ansible_managed" - -#: ../../rst/reference_appendices/config.rst:1568 -msgid "DEFAULT_MODULE_ARGS" -msgstr "DEFAULT_MODULE_ARGS" - -#: ../../rst/reference_appendices/config.rst:1570 -#: ../../rst/reference_appendices/config.rst:3819 -msgid "This sets the default arguments to pass to the ``ansible`` adhoc binary if no ``-a`` is specified." -msgstr "これにより、``ansible`` が指定されていない場合に、``-a`` アドホックバイナリーに渡すデフォルトの引数が設定されます。" - -#: ../../rst/reference_appendices/config.rst:1574 -msgid "module_args" -msgstr "module_args" - -#: ../../rst/reference_appendices/config.rst:1576 -msgid ":envvar:`ANSIBLE_MODULE_ARGS`" -msgstr ":envvar:`ANSIBLE_MODULE_ARGS`" - -#: ../../rst/reference_appendices/config.rst:1581 -msgid "DEFAULT_MODULE_COMPRESSION" -msgstr "DEFAULT_MODULE_COMPRESSION" - -#: ../../rst/reference_appendices/config.rst:1583 -msgid "Compression scheme to use when transferring Python modules to the target." -msgstr "Python モジュールをターゲットに転送する際に使用する圧縮スキーム。" - -#: ../../rst/reference_appendices/config.rst:1584 -msgid "ZIP_DEFLATED" -msgstr "ZIP_DEFLATED" - -#: ../../rst/reference_appendices/config.rst:1587 -msgid "module_compression" -msgstr "module_compression" - -#: ../../rst/reference_appendices/config.rst:1592 -msgid "DEFAULT_MODULE_NAME" -msgstr "DEFAULT_MODULE_NAME" - -#: ../../rst/reference_appendices/config.rst:1594 -msgid "Module to use with the ``ansible`` AdHoc command, if none is specified via ``-m``." -msgstr "``-m`` で何も指定されていない場合は、``ansible`` AdHoc コマンドで使用するモジュール。" - -#: ../../rst/reference_appendices/config.rst:1595 -msgid "command" -msgstr "command" - -#: ../../rst/reference_appendices/config.rst:1598 -msgid "module_name" -msgstr "module_name" - -#: ../../rst/reference_appendices/config.rst:1603 -msgid "DEFAULT_MODULE_PATH" -msgstr "DEFAULT_MODULE_PATH" - -#: ../../rst/reference_appendices/config.rst:1605 -#: ../../rst/reference_appendices/config.rst:3829 -msgid "Colon separated paths in which Ansible will search for Modules." -msgstr "Ansible がモジュールを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1607 -msgid "~/.ansible/plugins/modules:/usr/share/ansible/plugins/modules" -msgstr "~/.ansible/plugins/modules:/usr/share/ansible/plugins/modules" - -#: ../../rst/reference_appendices/config.rst:1610 -msgid "library" -msgstr "library" - -#: ../../rst/reference_appendices/config.rst:1612 -msgid ":envvar:`ANSIBLE_LIBRARY`" -msgstr ":envvar:`ANSIBLE_LIBRARY`" - -#: ../../rst/reference_appendices/config.rst:1617 -msgid "DEFAULT_MODULE_UTILS_PATH" -msgstr "DEFAULT_MODULE_UTILS_PATH" - -#: ../../rst/reference_appendices/config.rst:1619 -#: ../../rst/reference_appendices/config.rst:3837 -msgid "Colon separated paths in which Ansible will search for Module utils files, which are shared by modules." -msgstr "モジュールが共有するモジュールのユーティリティーファイルを Ansible が検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1621 -msgid "~/.ansible/plugins/module_utils:/usr/share/ansible/plugins/module_utils" -msgstr "~/.ansible/plugins/module_utils:/usr/share/ansible/plugins/module_utils" - -#: ../../rst/reference_appendices/config.rst:1624 -msgid "module_utils" -msgstr "module_utils" - -#: ../../rst/reference_appendices/config.rst:1626 -msgid ":envvar:`ANSIBLE_MODULE_UTILS`" -msgstr ":envvar:`ANSIBLE_MODULE_UTILS`" - -#: ../../rst/reference_appendices/config.rst:1631 -msgid "DEFAULT_NETCONF_PLUGIN_PATH" -msgstr "DEFAULT_NETCONF_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1633 -#: ../../rst/reference_appendices/config.rst:3845 -msgid "Colon separated paths in which Ansible will search for Netconf Plugins." -msgstr "Ansible が Netconf プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1635 -msgid "~/.ansible/plugins/netconf:/usr/share/ansible/plugins/netconf" -msgstr "~/.ansible/plugins/netconf:/usr/share/ansible/plugins/netconf" - -#: ../../rst/reference_appendices/config.rst:1638 -msgid "netconf_plugins" -msgstr "netconf_plugins" - -#: ../../rst/reference_appendices/config.rst:1640 -msgid ":envvar:`ANSIBLE_NETCONF_PLUGINS`" -msgstr ":envvar:`ANSIBLE_NETCONF_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1645 -msgid "DEFAULT_NO_LOG" -msgstr "DEFAULT_NO_LOG" - -#: ../../rst/reference_appendices/config.rst:1647 -#: ../../rst/reference_appendices/config.rst:3853 -msgid "Toggle Ansible's display and logging of task details, mainly used to avoid security disclosures." -msgstr "主にセキュリティーの公開を回避するために、Ansible の表示およびタスク詳細のロギングを使用します。" - -#: ../../rst/reference_appendices/config.rst:1652 -#: ../../rst/reference_appendices/playbooks_keywords.rst:104 -#: ../../rst/reference_appendices/playbooks_keywords.rst:223 -#: ../../rst/reference_appendices/playbooks_keywords.rst:321 -#: ../../rst/reference_appendices/playbooks_keywords.rst:449 -msgid "no_log" -msgstr "no_log" - -#: ../../rst/reference_appendices/config.rst:1654 -msgid ":envvar:`ANSIBLE_NO_LOG`" -msgstr ":envvar:`ANSIBLE_NO_LOG`" - -#: ../../rst/reference_appendices/config.rst:1659 -msgid "DEFAULT_NO_TARGET_SYSLOG" -msgstr "DEFAULT_NO_TARGET_SYSLOG" - -#: ../../rst/reference_appendices/config.rst:1661 -#: ../../rst/reference_appendices/config.rst:3861 -msgid "Toggle Ansible logging to syslog on the target when it executes tasks. On Windows hosts this will disable a newer style PowerShell modules from writing to the event log." -msgstr "タスクの実行時に、Ansible ログをターゲットの syslog へ切り替えます。Windows ホストでは、これにより、新しいスタイルの PowerShell モジュールがイベントログに書き込むことができなくなります。" - -#: ../../rst/reference_appendices/config.rst:1666 -msgid "no_target_syslog" -msgstr "no_target_syslog" - -#: ../../rst/reference_appendices/config.rst:1668 -msgid ":envvar:`ANSIBLE_NO_TARGET_SYSLOG`" -msgstr ":envvar:`ANSIBLE_NO_TARGET_SYSLOG`" - -#: ../../rst/reference_appendices/config.rst:1670 -msgid "`ansible_no_target_syslog` :Version Added: 2.10" -msgstr "`ansible_no_target_syslog` :Version Added: 2.10" - -#: ../../rst/reference_appendices/config.rst:1676 -msgid "DEFAULT_NULL_REPRESENTATION" -msgstr "DEFAULT_NULL_REPRESENTATION" - -#: ../../rst/reference_appendices/config.rst:1678 -#: ../../rst/reference_appendices/config.rst:3869 -msgid "What templating should return as a 'null' value. When not set it will let Jinja2 decide." -msgstr "テンプレートが「null」値として返すもの。設定しないと、Jinja2 が決定します。" - -#: ../../rst/reference_appendices/config.rst:1679 -msgid "none" -msgstr "none" - -#: ../../rst/reference_appendices/config.rst:1683 -msgid "null_representation" -msgstr "null_representation" - -#: ../../rst/reference_appendices/config.rst:1685 -msgid ":envvar:`ANSIBLE_NULL_REPRESENTATION`" -msgstr ":envvar:`ANSIBLE_NULL_REPRESENTATION`" - -#: ../../rst/reference_appendices/config.rst:1690 -msgid "DEFAULT_POLL_INTERVAL" -msgstr "DEFAULT_POLL_INTERVAL" - -#: ../../rst/reference_appendices/config.rst:1692 -#: ../../rst/reference_appendices/config.rst:3877 -msgid "For asynchronous tasks in Ansible (covered in Asynchronous Actions and Polling), this is how often to check back on the status of those tasks when an explicit poll interval is not supplied. The default is a reasonably moderate 15 seconds which is a tradeoff between checking in frequently and providing a quick turnaround when something may have completed." -msgstr "Ansible の非同期タスク (「非同期アクションとポーリング」で説明) の場合、これは、明示的なポーリング間隔が指定されていない場合に、これらのタスクのステータスを確認する頻度です。デフォルトは適度に中程度の 15 秒です。これは、頻繁に確認することと、何かが完了したときに迅速に対応することとのトレードオフになっています。" - -#: ../../rst/reference_appendices/config.rst:1694 -#: ../../rst/reference_appendices/config.rst:2713 -msgid "15" -msgstr "15" - -#: ../../rst/reference_appendices/config.rst:1697 -msgid "poll_interval" -msgstr "poll_interval" - -#: ../../rst/reference_appendices/config.rst:1699 -msgid ":envvar:`ANSIBLE_POLL_INTERVAL`" -msgstr ":envvar:`ANSIBLE_POLL_INTERVAL`" - -#: ../../rst/reference_appendices/config.rst:1704 -msgid "DEFAULT_PRIVATE_KEY_FILE" -msgstr "DEFAULT_PRIVATE_KEY_FILE" - -#: ../../rst/reference_appendices/config.rst:1706 -#: ../../rst/reference_appendices/config.rst:3885 -msgid "Option for connections using a certificate or key file to authenticate, rather than an agent or passwords, you can set the default value here to avoid re-specifying --private-key with every invocation." -msgstr "エージェントやパスワードではなく、証明書またはキーファイルを使用して認証する接続のオプション。ここでデフォルト値を設定して、呼び出しごとに --private-key が再指定されないようにすることができます。" - -#: ../../rst/reference_appendices/config.rst:1711 -msgid "private_key_file" -msgstr "private_key_file" - -#: ../../rst/reference_appendices/config.rst:1713 -msgid ":envvar:`ANSIBLE_PRIVATE_KEY_FILE`" -msgstr ":envvar:`ANSIBLE_PRIVATE_KEY_FILE`" - -#: ../../rst/reference_appendices/config.rst:1718 -msgid "DEFAULT_PRIVATE_ROLE_VARS" -msgstr "DEFAULT_PRIVATE_ROLE_VARS" - -#: ../../rst/reference_appendices/config.rst:1720 -msgid "Makes role variables inaccessible from other roles. This was introduced as a way to reset role variables to default values if a role is used more than once in a playbook." -msgstr "ロール変数が他のロールからアクセスできないようにします。これは、Playbook でロールが複数回使用されている場合に、ロール変数をデフォルト値にリセットする方法として導入されました。" - -#: ../../rst/reference_appendices/config.rst:1725 -msgid "private_role_vars" -msgstr "private_role_vars" - -#: ../../rst/reference_appendices/config.rst:1727 -msgid ":envvar:`ANSIBLE_PRIVATE_ROLE_VARS`" -msgstr ":envvar:`ANSIBLE_PRIVATE_ROLE_VARS`" - -#: ../../rst/reference_appendices/config.rst:1732 -msgid "DEFAULT_REMOTE_PORT" -msgstr "DEFAULT_REMOTE_PORT" - -#: ../../rst/reference_appendices/config.rst:1734 -#: ../../rst/reference_appendices/config.rst:3901 -msgid "Port to use in remote connections, when blank it will use the connection plugin default." -msgstr "リモート接続で使用するポート。空の場合は、connection プラグインのデフォルトを使用します。" - -#: ../../rst/reference_appendices/config.rst:1739 -msgid "remote_port" -msgstr "remote_port" - -#: ../../rst/reference_appendices/config.rst:1741 -msgid ":envvar:`ANSIBLE_REMOTE_PORT`" -msgstr ":envvar:`ANSIBLE_REMOTE_PORT`" - -#: ../../rst/reference_appendices/config.rst:1746 -msgid "DEFAULT_REMOTE_USER" -msgstr "DEFAULT_REMOTE_USER" - -#: ../../rst/reference_appendices/config.rst:1748 -msgid "Sets the login user for the target machines When blank it uses the connection plugin's default, normally the user currently executing Ansible." -msgstr "ターゲットマシンのログインユーザーを設定します。空の場合は、connection プラグインのデフォルト (通常は現在 Ansible を実行しているユーザー) を使用します。" - -#: ../../rst/reference_appendices/config.rst:1752 -#: ../../rst/reference_appendices/playbooks_keywords.rst:119 -#: ../../rst/reference_appendices/playbooks_keywords.rst:229 -#: ../../rst/reference_appendices/playbooks_keywords.rst:330 -#: ../../rst/reference_appendices/playbooks_keywords.rst:464 -msgid "remote_user" -msgstr "remote_user" - -#: ../../rst/reference_appendices/config.rst:1754 -msgid ":envvar:`ANSIBLE_REMOTE_USER`" -msgstr ":envvar:`ANSIBLE_REMOTE_USER`" - -#: ../../rst/reference_appendices/config.rst:1759 -msgid "DEFAULT_ROLES_PATH" -msgstr "DEFAULT_ROLES_PATH" - -#: ../../rst/reference_appendices/config.rst:1761 -#: ../../rst/reference_appendices/config.rst:3917 -msgid "Colon separated paths in which Ansible will search for Roles." -msgstr "Ansible がロールを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1763 -msgid "~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles" -msgstr "~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles" - -#: ../../rst/reference_appendices/config.rst:1766 -msgid "roles_path" -msgstr "roles_path" - -#: ../../rst/reference_appendices/config.rst:1768 -msgid ":envvar:`ANSIBLE_ROLES_PATH`" -msgstr ":envvar:`ANSIBLE_ROLES_PATH`" - -#: ../../rst/reference_appendices/config.rst:1773 -msgid "DEFAULT_SELINUX_SPECIAL_FS" -msgstr "DEFAULT_SELINUX_SPECIAL_FS" - -#: ../../rst/reference_appendices/config.rst:1775 -msgid "Some filesystems do not support safe operations and/or return inconsistent errors, this setting makes Ansible 'tolerate' those in the list w/o causing fatal errors. Data corruption may occur and writes are not always verified when a filesystem is in the list." -msgstr "一部のファイルシステムは安全な操作をサポートしていないか、一貫性のないエラーを返します。この設定により、Ansible はリスト内のエラーを「許容」し、致命的なエラーを引き起こしません。ファイルシステムがリストに含まれていると、データが破損する可能性があり、書き込みが常に検証されるとは限りません。" - -#: ../../rst/reference_appendices/config.rst:1777 -msgid "fuse, nfs, vboxsf, ramfs, 9p, vfat" -msgstr "fuse, nfs, vboxsf, ramfs, 9p, vfat" - -#: ../../rst/reference_appendices/config.rst:1780 -msgid "special_context_filesystems" -msgstr "special_context_filesystems" - -#: ../../rst/reference_appendices/config.rst:1782 -msgid ":envvar:`ANSIBLE_SELINUX_SPECIAL_FS` :Version Added: 2.9" -msgstr ":envvar:`ANSIBLE_SELINUX_SPECIAL_FS` :Version Added: 2.9" - -#: ../../rst/reference_appendices/config.rst:1788 -msgid "DEFAULT_STDOUT_CALLBACK" -msgstr "DEFAULT_STDOUT_CALLBACK" - -#: ../../rst/reference_appendices/config.rst:1790 -msgid "Set the main callback used to display Ansible output, you can only have one at a time. You can have many other callbacks, but just one can be in charge of stdout." -msgstr "Ansible 出力の表示に使用されるメインのコールバックを設定します。一度に 1 つしか使用できません。他にも多くのコールバックを設定できますが、stdout に使用できるのは 1 つだけです。" - -#: ../../rst/reference_appendices/config.rst:1794 -msgid "stdout_callback" -msgstr "stdout_callback" - -#: ../../rst/reference_appendices/config.rst:1796 -msgid ":envvar:`ANSIBLE_STDOUT_CALLBACK`" -msgstr ":envvar:`ANSIBLE_STDOUT_CALLBACK`" - -#: ../../rst/reference_appendices/config.rst:1801 -msgid "DEFAULT_STRATEGY" -msgstr "DEFAULT_STRATEGY" - -#: ../../rst/reference_appendices/config.rst:1803 -#: ../../rst/reference_appendices/config.rst:3958 -msgid "Set the default strategy used for plays." -msgstr "プレイに使用するデフォルトのストラテジーを設定します。" - -#: ../../rst/reference_appendices/config.rst:1804 -msgid "linear" -msgstr "linear" - -#: ../../rst/reference_appendices/config.rst:1805 -msgid "2.3" -msgstr "2.3" - -#: ../../rst/reference_appendices/config.rst:1808 -#: ../../rst/reference_appendices/playbooks_keywords.rst:134 -msgid "strategy" -msgstr "strategy" - -#: ../../rst/reference_appendices/config.rst:1810 -msgid ":envvar:`ANSIBLE_STRATEGY`" -msgstr ":envvar:`ANSIBLE_STRATEGY`" - -#: ../../rst/reference_appendices/config.rst:1815 -msgid "DEFAULT_STRATEGY_PLUGIN_PATH" -msgstr "DEFAULT_STRATEGY_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1817 -#: ../../rst/reference_appendices/config.rst:3966 -msgid "Colon separated paths in which Ansible will search for Strategy Plugins." -msgstr "Ansible が Strategy プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1819 -msgid "~/.ansible/plugins/strategy:/usr/share/ansible/plugins/strategy" -msgstr "~/.ansible/plugins/strategy:/usr/share/ansible/plugins/strategy" - -#: ../../rst/reference_appendices/config.rst:1822 -msgid "strategy_plugins" -msgstr "strategy_plugins" - -#: ../../rst/reference_appendices/config.rst:1824 -msgid ":envvar:`ANSIBLE_STRATEGY_PLUGINS`" -msgstr ":envvar:`ANSIBLE_STRATEGY_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1829 -msgid "DEFAULT_SU" -msgstr "DEFAULT_SU" - -#: ../../rst/reference_appendices/config.rst:1831 -#: ../../rst/reference_appendices/config.rst:3974 -msgid "Toggle the use of \"su\" for tasks." -msgstr "タスクに「su」の使用を切り替えます。" - -#: ../../rst/reference_appendices/config.rst:1836 -msgid "su" -msgstr "su" - -#: ../../rst/reference_appendices/config.rst:1838 -msgid ":envvar:`ANSIBLE_SU`" -msgstr ":envvar:`ANSIBLE_SU`" - -#: ../../rst/reference_appendices/config.rst:1843 -msgid "DEFAULT_SYSLOG_FACILITY" -msgstr "DEFAULT_SYSLOG_FACILITY" - -#: ../../rst/reference_appendices/config.rst:1845 -#: ../../rst/reference_appendices/config.rst:3982 -msgid "Syslog facility to use when Ansible logs to the remote target" -msgstr "Ansible がリモートターゲットにログを記録するときに使用する syslog ファシリティー" - -#: ../../rst/reference_appendices/config.rst:1846 -msgid "LOG_USER" -msgstr "LOG_USER" - -#: ../../rst/reference_appendices/config.rst:1849 -msgid "syslog_facility" -msgstr "syslog_facility" - -#: ../../rst/reference_appendices/config.rst:1851 -msgid ":envvar:`ANSIBLE_SYSLOG_FACILITY`" -msgstr ":envvar:`ANSIBLE_SYSLOG_FACILITY`" - -#: ../../rst/reference_appendices/config.rst:1856 -msgid "DEFAULT_TASK_INCLUDES_STATIC" -msgstr "DEFAULT_TASK_INCLUDES_STATIC" - -#: ../../rst/reference_appendices/config.rst:1858 -#: ../../rst/reference_appendices/config.rst:3990 -msgid "The `include` tasks can be static or dynamic, this toggles the default expected behaviour if autodetection fails and it is not explicitly set in task." -msgstr "`include` タスクは静的または動的にすることができます。これは、自動検出が失敗し、タスクに自動検出が明示的に設定されていない場合に、デフォルトの想定される動作を切り替えます。" - -#: ../../rst/reference_appendices/config.rst:1864 -msgid "task_includes_static" -msgstr "task_includes_static" - -#: ../../rst/reference_appendices/config.rst:1866 -msgid ":envvar:`ANSIBLE_TASK_INCLUDES_STATIC`" -msgstr ":envvar:`ANSIBLE_TASK_INCLUDES_STATIC`" - -#: ../../rst/reference_appendices/config.rst:1869 -msgid "None, as its already built into the decision between include_tasks and import_tasks" -msgstr "include_tasks と import_tasks の決定にすでに組み込まれてるため、none です。" - -#: ../../rst/reference_appendices/config.rst:1874 -msgid "DEFAULT_TERMINAL_PLUGIN_PATH" -msgstr "DEFAULT_TERMINAL_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1876 -#: ../../rst/reference_appendices/config.rst:3998 -msgid "Colon separated paths in which Ansible will search for Terminal Plugins." -msgstr "Ansible が Terminal プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1878 -msgid "~/.ansible/plugins/terminal:/usr/share/ansible/plugins/terminal" -msgstr "~/.ansible/plugins/terminal:/usr/share/ansible/plugins/terminal" - -#: ../../rst/reference_appendices/config.rst:1881 -msgid "terminal_plugins" -msgstr "terminal_plugins" - -#: ../../rst/reference_appendices/config.rst:1883 -msgid ":envvar:`ANSIBLE_TERMINAL_PLUGINS`" -msgstr ":envvar:`ANSIBLE_TERMINAL_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1888 -msgid "DEFAULT_TEST_PLUGIN_PATH" -msgstr "DEFAULT_TEST_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1890 -#: ../../rst/reference_appendices/config.rst:4006 -msgid "Colon separated paths in which Ansible will search for Jinja2 Test Plugins." -msgstr "Ansible が Jinja2 テストプラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1892 -msgid "~/.ansible/plugins/test:/usr/share/ansible/plugins/test" -msgstr "~/.ansible/plugins/test:/usr/share/ansible/plugins/test" - -#: ../../rst/reference_appendices/config.rst:1895 -msgid "test_plugins" -msgstr "test_plugins" - -#: ../../rst/reference_appendices/config.rst:1897 -msgid ":envvar:`ANSIBLE_TEST_PLUGINS`" -msgstr ":envvar:`ANSIBLE_TEST_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1902 -msgid "DEFAULT_TIMEOUT" -msgstr "DEFAULT_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:1904 -#: ../../rst/reference_appendices/config.rst:4014 -msgid "This is the default timeout for connection plugins to use." -msgstr "これは、connection プラグインが使用するデフォルトのタイムアウトです。" - -#: ../../rst/reference_appendices/config.rst:1909 -#: ../../rst/reference_appendices/playbooks_keywords.rst:146 -#: ../../rst/reference_appendices/playbooks_keywords.rst:241 -#: ../../rst/reference_appendices/playbooks_keywords.rst:345 -#: ../../rst/reference_appendices/playbooks_keywords.rst:479 -msgid "timeout" -msgstr "timeout" - -#: ../../rst/reference_appendices/config.rst:1911 -msgid ":envvar:`ANSIBLE_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:1916 -msgid "DEFAULT_TRANSPORT" -msgstr "DEFAULT_TRANSPORT" - -#: ../../rst/reference_appendices/config.rst:1918 -#: ../../rst/reference_appendices/config.rst:4022 -msgid "Default connection plugin to use, the 'smart' option will toggle between 'ssh' and 'paramiko' depending on controller OS and ssh versions" -msgstr "使用するデフォルトの connection プラグイン。「smart」オプションは、コントローラー OS と ssh のバージョンに応じて、「ssh」と「paramiko」の間で切り替えられます。" - -#: ../../rst/reference_appendices/config.rst:1922 -msgid "transport" -msgstr "transport" - -#: ../../rst/reference_appendices/config.rst:1924 -msgid ":envvar:`ANSIBLE_TRANSPORT`" -msgstr ":envvar:`ANSIBLE_TRANSPORT`" - -#: ../../rst/reference_appendices/config.rst:1929 -msgid "DEFAULT_UNDEFINED_VAR_BEHAVIOR" -msgstr "DEFAULT_UNDEFINED_VAR_BEHAVIOR" - -#: ../../rst/reference_appendices/config.rst:1931 -msgid "When True, this causes ansible templating to fail steps that reference variable names that are likely typoed. Otherwise, any '{{ template_expression }}' that contains undefined variables will be rendered in a template or ansible action line exactly as written." -msgstr "True にすると、タイプミスの可能性が高い変数名を参照するステップが失敗するテンプレートが作成されます。True に設定しないと、未定義の変数を含む '{{ template_expression }}' は、記述されたとおりにテンプレートまたは ansible のアクション行にレンダリングされます。" - -#: ../../rst/reference_appendices/config.rst:1934 -msgid "1.3" -msgstr "1.3" - -#: ../../rst/reference_appendices/config.rst:1937 -msgid "error_on_undefined_vars" -msgstr "error_on_undefined_vars" - -#: ../../rst/reference_appendices/config.rst:1939 -msgid ":envvar:`ANSIBLE_ERROR_ON_UNDEFINED_VARS`" -msgstr ":envvar:`ANSIBLE_ERROR_ON_UNDEFINED_VARS`" - -#: ../../rst/reference_appendices/config.rst:1944 -msgid "DEFAULT_VARS_PLUGIN_PATH" -msgstr "DEFAULT_VARS_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1946 -#: ../../rst/reference_appendices/config.rst:4038 -msgid "Colon separated paths in which Ansible will search for Vars Plugins." -msgstr "Ansible が Vars プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1948 -msgid "~/.ansible/plugins/vars:/usr/share/ansible/plugins/vars" -msgstr "~/.ansible/plugins/vars:/usr/share/ansible/plugins/vars" - -#: ../../rst/reference_appendices/config.rst:1951 -msgid "vars_plugins" -msgstr "vars_plugins" - -#: ../../rst/reference_appendices/config.rst:1953 -msgid ":envvar:`ANSIBLE_VARS_PLUGINS`" -msgstr ":envvar:`ANSIBLE_VARS_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1958 -msgid "DEFAULT_VAULT_ENCRYPT_IDENTITY" -msgstr "DEFAULT_VAULT_ENCRYPT_IDENTITY" - -#: ../../rst/reference_appendices/config.rst:1960 -#: ../../rst/reference_appendices/config.rst:4062 -msgid "The vault_id to use for encrypting by default. If multiple vault_ids are provided, this specifies which to use for encryption. The --encrypt-vault-id cli option overrides the configured value." -msgstr "デフォルトで暗号化に使用する vault_id です。複数の vault_ids が提供されると、暗号化に使用するものを指定します。--encrypt-vault-id cli オプションは、設定した値をオーバーライドします。" - -#: ../../rst/reference_appendices/config.rst:1964 -msgid "vault_encrypt_identity" -msgstr "vault_encrypt_identity" - -#: ../../rst/reference_appendices/config.rst:1966 -msgid ":envvar:`ANSIBLE_VAULT_ENCRYPT_IDENTITY`" -msgstr ":envvar:`ANSIBLE_VAULT_ENCRYPT_IDENTITY`" - -#: ../../rst/reference_appendices/config.rst:1971 -msgid "DEFAULT_VAULT_ID_MATCH" -msgstr "DEFAULT_VAULT_ID_MATCH" - -#: ../../rst/reference_appendices/config.rst:1973 -#: ../../rst/reference_appendices/config.rst:4046 -msgid "If true, decrypting vaults with a vault id will only try the password from the matching vault-id" -msgstr "true の場合、Vault id で Vault を復号すると、一致する Vault id からのみパスワードを試みます。" - -#: ../../rst/reference_appendices/config.rst:1977 -msgid "vault_id_match" -msgstr "vault_id_match" - -#: ../../rst/reference_appendices/config.rst:1979 -msgid ":envvar:`ANSIBLE_VAULT_ID_MATCH`" -msgstr ":envvar:`ANSIBLE_VAULT_ID_MATCH`" - -#: ../../rst/reference_appendices/config.rst:1984 -msgid "DEFAULT_VAULT_IDENTITY" -msgstr "DEFAULT_VAULT_IDENTITY" - -#: ../../rst/reference_appendices/config.rst:1986 -#: ../../rst/reference_appendices/config.rst:4054 -msgid "The label to use for the default vault id label in cases where a vault id label is not provided" -msgstr "Vault id ラベルが指定されていない場合にデフォルトの Vault id ラベルに使用するラベル" - -#: ../../rst/reference_appendices/config.rst:1990 -msgid "vault_identity" -msgstr "vault_identity" - -#: ../../rst/reference_appendices/config.rst:1992 -msgid ":envvar:`ANSIBLE_VAULT_IDENTITY`" -msgstr ":envvar:`ANSIBLE_VAULT_IDENTITY`" - -#: ../../rst/reference_appendices/config.rst:1997 -msgid "DEFAULT_VAULT_IDENTITY_LIST" -msgstr "DEFAULT_VAULT_IDENTITY_LIST" - -#: ../../rst/reference_appendices/config.rst:1999 -#: ../../rst/reference_appendices/config.rst:4070 -msgid "A list of vault-ids to use by default. Equivalent to multiple --vault-id args. Vault-ids are tried in order." -msgstr "デフォルトで使用する vault-id の一覧。複数の --vault-id 引数と同等です。vault-ids は順番に試行されます。" - -#: ../../rst/reference_appendices/config.rst:2004 -msgid "vault_identity_list" -msgstr "vault_identity_list" - -#: ../../rst/reference_appendices/config.rst:2006 -msgid ":envvar:`ANSIBLE_VAULT_IDENTITY_LIST`" -msgstr ":envvar:`ANSIBLE_VAULT_IDENTITY_LIST`" - -#: ../../rst/reference_appendices/config.rst:2011 -msgid "DEFAULT_VAULT_PASSWORD_FILE" -msgstr "DEFAULT_VAULT_PASSWORD_FILE" - -#: ../../rst/reference_appendices/config.rst:2013 -#: ../../rst/reference_appendices/config.rst:4078 -msgid "The vault password file to use. Equivalent to --vault-password-file or --vault-id" -msgstr "使用する vault パスワードファイル。--vault-password-file または --vault-id と同等です。" - -#: ../../rst/reference_appendices/config.rst:2018 -msgid "vault_password_file" -msgstr "vault_password_file" - -#: ../../rst/reference_appendices/config.rst:2020 -msgid ":envvar:`ANSIBLE_VAULT_PASSWORD_FILE`" -msgstr ":envvar:`ANSIBLE_VAULT_PASSWORD_FILE`" - -#: ../../rst/reference_appendices/config.rst:2025 -msgid "DEFAULT_VERBOSITY" -msgstr "DEFAULT_VERBOSITY" - -#: ../../rst/reference_appendices/config.rst:2027 -#: ../../rst/reference_appendices/config.rst:4086 -msgid "Sets the default verbosity, equivalent to the number of ``-v`` passed in the command line." -msgstr "コマンドラインで渡された ``-v`` の数と同等の、デフォルトの詳細レベルを設定します。" - -#: ../../rst/reference_appendices/config.rst:2029 -#: ../../rst/reference_appendices/config.rst:2804 -#: ../../rst/reference_appendices/config.rst:2969 -#: ../../rst/reference_appendices/config.rst:3080 -msgid "0" -msgstr "0" - -#: ../../rst/reference_appendices/config.rst:2032 -msgid "verbosity" -msgstr "verbosity" - -#: ../../rst/reference_appendices/config.rst:2034 -msgid ":envvar:`ANSIBLE_VERBOSITY`" -msgstr ":envvar:`ANSIBLE_VERBOSITY`" - -#: ../../rst/reference_appendices/config.rst:2039 -msgid "DEPRECATION_WARNINGS" -msgstr "DEPRECATION_WARNINGS" - -#: ../../rst/reference_appendices/config.rst:2041 -#: ../../rst/reference_appendices/config.rst:4094 -msgid "Toggle to control the showing of deprecation warnings" -msgstr "非推奨の警告の表示を制御するために切り替え" - -#: ../../rst/reference_appendices/config.rst:2046 -msgid "deprecation_warnings" -msgstr "deprecation_warnings" - -#: ../../rst/reference_appendices/config.rst:2048 -msgid ":envvar:`ANSIBLE_DEPRECATION_WARNINGS`" -msgstr ":envvar:`ANSIBLE_DEPRECATION_WARNINGS`" - -#: ../../rst/reference_appendices/config.rst:2053 -msgid "DEVEL_WARNING" -msgstr "DEVEL_WARNING" - -#: ../../rst/reference_appendices/config.rst:2055 -#: ../../rst/reference_appendices/config.rst:4102 -msgid "Toggle to control showing warnings related to running devel" -msgstr "devel の実行に関連する警告を表示するように制御を切り替え" - -#: ../../rst/reference_appendices/config.rst:2060 -msgid "devel_warning" -msgstr "devel_warning" - -#: ../../rst/reference_appendices/config.rst:2062 -msgid ":envvar:`ANSIBLE_DEVEL_WARNING`" -msgstr ":envvar:`ANSIBLE_DEVEL_WARNING`" - -#: ../../rst/reference_appendices/config.rst:2067 -msgid "DIFF_ALWAYS" -msgstr "DIFF_ALWAYS" - -#: ../../rst/reference_appendices/config.rst:2069 -#: ../../rst/reference_appendices/config.rst:4110 -msgid "Configuration toggle to tell modules to show differences when in 'changed' status, equivalent to ``--diff``." -msgstr "構成の切り替えにより、「changed」状態のときに相違点を表示するようにモジュールに指示します (``--diff`` 相当)。" - -#: ../../rst/reference_appendices/config.rst:2070 -#: ../../rst/reference_appendices/config.rst:2236 -#: ../../rst/reference_appendices/config.rst:2445 -#: ../../rst/reference_appendices/config.rst:2523 -#: ../../rst/reference_appendices/config.rst:2570 -#: ../../rst/reference_appendices/config.rst:2820 -#: ../../rst/reference_appendices/config.rst:2866 -#: ../../rst/reference_appendices/config.rst:3047 -msgid "bool" -msgstr "bool" - -#: ../../rst/reference_appendices/config.rst:2073 -#: ../../rst/reference_appendices/config.rst:2087 -msgid "[diff]" -msgstr "[diff]" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:2074 -#: ../../rst/reference_appendices/playbooks_keywords.rst:255 -msgid "always" -msgstr "always" - -#: ../../rst/reference_appendices/config.rst:2076 -msgid ":envvar:`ANSIBLE_DIFF_ALWAYS`" -msgstr ":envvar:`ANSIBLE_DIFF_ALWAYS`" - -#: ../../rst/reference_appendices/config.rst:2081 -msgid "DIFF_CONTEXT" -msgstr "DIFF_CONTEXT" - -#: ../../rst/reference_appendices/config.rst:2083 -#: ../../rst/reference_appendices/config.rst:4118 -msgid "How many lines of context to show when displaying the differences between files." -msgstr "ファイル間の差異を表示する際に表示するコンテキストの行数。" - -#: ../../rst/reference_appendices/config.rst:2085 -msgid "3" -msgstr "3" - -#: ../../rst/reference_appendices/config.rst:2088 -msgid "context" -msgstr "context" - -#: ../../rst/reference_appendices/config.rst:2090 -msgid ":envvar:`ANSIBLE_DIFF_CONTEXT`" -msgstr ":envvar:`ANSIBLE_DIFF_CONTEXT`" - -#: ../../rst/reference_appendices/config.rst:2095 -msgid "DISPLAY_ARGS_TO_STDOUT" -msgstr "DISPLAY_ARGS_TO_STDOUT" - -#: ../../rst/reference_appendices/config.rst:2097 -msgid "Normally ``ansible-playbook`` will print a header for each task that is run. These headers will contain the name: field from the task if you specified one. If you didn't then ``ansible-playbook`` uses the task's action to help you tell which task is presently running. Sometimes you run many of the same action and so you want more information about the task to differentiate it from others of the same action. If you set this variable to True in the config then ``ansible-playbook`` will also include the task's arguments in the header. This setting defaults to False because there is a chance that you have sensitive values in your parameters and you do not want those to be printed. If you set this to True you should be sure that you have secured your environment's stdout (no one can shoulder surf your screen and you aren't saving stdout to an insecure file) or made sure that all of your playbooks explicitly added the ``no_log: True`` parameter to tasks which have sensitive values See How do I keep secret data in my playbook? for more information." -msgstr "通常、``ansible-playbook`` は、実行された各タスクのヘッダーが出力されます。これらのヘッダーにはタスクの name: フィールドが指定されていればそれが含まれます。指定していない場合は、``ansible-playbook`` がタスクのアクションを使用して、どのタスクが現在実行されているかを知ることができます。同じアクションの多くを実行する場合は、同じアクションの他のタスクと区別するために、タスクに関する詳細情報が必要になることがあります。設定でこの変数を True に設定すると、``ansible-playbook`` では、タスクの引数もヘッダーに含まれます。パラメーターに機密性の高い値が含まれている可能性があり、それらを出力しないため、この設定の既定値は False です。これを True に設定した場合は、環境の標準出力 (誰もあなたの画面を肩越しに盗み見ることができず、あなたは標準出力を安全でないファイルに保存していません) を確実に保護するか、すべての Playbook で機密性の高い値を持つタスクに ``no_log: True`` パラメーターを明示的に追加する必要があります。詳細は、「Playbook に機密データを保存するにはどうすれば良いですか」を参照してください。" - -#: ../../rst/reference_appendices/config.rst:2103 -msgid "display_args_to_stdout" -msgstr "display_args_to_stdout" - -#: ../../rst/reference_appendices/config.rst:2105 -msgid ":envvar:`ANSIBLE_DISPLAY_ARGS_TO_STDOUT`" -msgstr ":envvar:`ANSIBLE_DISPLAY_ARGS_TO_STDOUT`" - -#: ../../rst/reference_appendices/config.rst:2110 -msgid "DISPLAY_SKIPPED_HOSTS" -msgstr "DISPLAY_SKIPPED_HOSTS" - -#: ../../rst/reference_appendices/config.rst:2112 -#: ../../rst/reference_appendices/config.rst:4134 -#: ../../rst/reference_appendices/config.rst:4144 -msgid "Toggle to control displaying skipped task/host entries in a task in the default callback" -msgstr "デフォルトのコールバックのタスクにスキップされたタスク/ホストエントリーの表示を制御するように切り替えます。" - -#: ../../rst/reference_appendices/config.rst:2117 -msgid "display_skipped_hosts" -msgstr "display_skipped_hosts" - -#: ../../rst/reference_appendices/config.rst:2119 -msgid ":envvar:`ANSIBLE_DISPLAY_SKIPPED_HOSTS`" -msgstr ":envvar:`ANSIBLE_DISPLAY_SKIPPED_HOSTS`" - -#: ../../rst/reference_appendices/config.rst:2120 -msgid ":envvar:`DISPLAY_SKIPPED_HOSTS`" -msgstr ":envvar:`DISPLAY_SKIPPED_HOSTS`" - -#: ../../rst/reference_appendices/config.rst:2123 -#: ../../rst/reference_appendices/config.rst:4140 -msgid "the ``ANSIBLE_DISPLAY_SKIPPED_HOSTS`` environment variable" -msgstr "``ANSIBLE_DISPLAY_SKIPPED_HOSTS`` 環境変数" - -#: ../../rst/reference_appendices/config.rst:2128 -msgid "DOC_FRAGMENT_PLUGIN_PATH" -msgstr "DOC_FRAGMENT_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:2130 -#: ../../rst/reference_appendices/config.rst:3456 -msgid "Colon separated paths in which Ansible will search for Documentation Fragments Plugins." -msgstr "Ansible が Documentation Fragment Plugins を検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:2132 -msgid "~/.ansible/plugins/doc_fragments:/usr/share/ansible/plugins/doc_fragments" -msgstr "~/.ansible/plugins/doc_fragments:/usr/share/ansible/plugins/doc_fragments" - -#: ../../rst/reference_appendices/config.rst:2135 -msgid "doc_fragment_plugins" -msgstr "doc_fragment_plugins" - -#: ../../rst/reference_appendices/config.rst:2137 -msgid ":envvar:`ANSIBLE_DOC_FRAGMENT_PLUGINS`" -msgstr ":envvar:`ANSIBLE_DOC_FRAGMENT_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:2142 -msgid "DOCSITE_ROOT_URL" -msgstr "DOCSITE_ROOT_URL" - -#: ../../rst/reference_appendices/config.rst:2144 -msgid "Root docsite URL used to generate docs URLs in warning/error text; must be an absolute URL with valid scheme and trailing slash." -msgstr "警告/エラーテキストでドキュメント URL を生成するために使用されるルートドキュメントサイト URL。有効なスキームおよび末尾のスラッシュが含まれる絶対 URL でなければなりません。" - -#: ../../rst/reference_appendices/config.rst:2145 -msgid "https://docs.ansible.com/ansible/" -msgstr "https://docs.ansible.com/ansible/" - -#: ../../rst/reference_appendices/config.rst:2149 -msgid "docsite_root_url" -msgstr "docsite_root_url" - -#: ../../rst/reference_appendices/config.rst:2154 -msgid "DUPLICATE_YAML_DICT_KEY" -msgstr "DUPLICATE_YAML_DICT_KEY" - -#: ../../rst/reference_appendices/config.rst:2156 -msgid "By default Ansible will issue a warning when a duplicate dict key is encountered in YAML. These warnings can be silenced by adjusting this setting to False." -msgstr "デフォルトでは、Ansible は、YAML で重複した dict キーが発生した場合に警告を発行します。この警告は、この設定を False に設定すると非表示にすることができます。" - -#: ../../rst/reference_appendices/config.rst:2166 -msgid "duplicate_dict_key" -msgstr "duplicate_dict_key" - -#: ../../rst/reference_appendices/config.rst:2168 -msgid ":envvar:`ANSIBLE_DUPLICATE_YAML_DICT_KEY`" -msgstr ":envvar:`ANSIBLE_DUPLICATE_YAML_DICT_KEY`" - -#: ../../rst/reference_appendices/config.rst:2173 -msgid "ENABLE_TASK_DEBUGGER" -msgstr "ENABLE_TASK_DEBUGGER" - -#: ../../rst/reference_appendices/config.rst:2175 -msgid "Whether or not to enable the task debugger, this previously was done as a strategy plugin. Now all strategy plugins can inherit this behavior. The debugger defaults to activating when a task is failed on unreachable. Use the debugger keyword for more flexibility." -msgstr "タスクデバッガーを有効にするかどうかにかかわらず、これは以前は strategy プラグインとして実行されていました。これで、すべての strategy プラグインがこの動作を継承できるようになりました。デバッガーは、タスクが到達不能で失敗したときにデフォルトでアクティブになります。柔軟性を高めるには、debugger キーワードを使用します。" - -#: ../../rst/reference_appendices/config.rst:2181 -msgid "enable_task_debugger" -msgstr "enable_task_debugger" - -#: ../../rst/reference_appendices/config.rst:2183 -msgid ":envvar:`ANSIBLE_ENABLE_TASK_DEBUGGER`" -msgstr ":envvar:`ANSIBLE_ENABLE_TASK_DEBUGGER`" - -#: ../../rst/reference_appendices/config.rst:2188 -msgid "ERROR_ON_MISSING_HANDLER" -msgstr "ERROR_ON_MISSING_HANDLER" - -#: ../../rst/reference_appendices/config.rst:2190 -#: ../../rst/reference_appendices/config.rst:4161 -msgid "Toggle to allow missing handlers to become a warning instead of an error when notifying." -msgstr "通知時に、エラーではなく、不足しているハンドラーが警告になるように切り替えます。" - -#: ../../rst/reference_appendices/config.rst:2195 -msgid "error_on_missing_handler" -msgstr "error_on_missing_handler" - -#: ../../rst/reference_appendices/config.rst:2197 -msgid ":envvar:`ANSIBLE_ERROR_ON_MISSING_HANDLER`" -msgstr ":envvar:`ANSIBLE_ERROR_ON_MISSING_HANDLER`" - -#: ../../rst/reference_appendices/config.rst:2202 -msgid "FACTS_MODULES" -msgstr "FACTS_MODULES" - -#: ../../rst/reference_appendices/config.rst:2204 -#: ../../rst/reference_appendices/config.rst:4177 -msgid "Which modules to run during a play's fact gathering stage, using the default of 'smart' will try to figure it out based on connection type." -msgstr "プレイのファクト収集段階で実行するモジュールは、デフォルトの「smart」を使用すると接続タイプに基づいて確認を試みます。" - -#: ../../rst/reference_appendices/config.rst:2206 -msgid "['smart']" -msgstr "['smart']" - -#: ../../rst/reference_appendices/config.rst:2209 -msgid "facts_modules" -msgstr "facts_modules" - -#: ../../rst/reference_appendices/config.rst:2211 -msgid ":envvar:`ANSIBLE_FACTS_MODULES`" -msgstr ":envvar:`ANSIBLE_FACTS_MODULES`" - -#: ../../rst/reference_appendices/config.rst:2213 -msgid "`ansible_facts_modules`" -msgstr "`ansible_facts_modules`" - -#: ../../rst/reference_appendices/config.rst:2218 -msgid "GALAXY_CACHE_DIR" -msgstr "GALAXY_CACHE_DIR" - -#: ../../rst/reference_appendices/config.rst:2220 -msgid "The directory that stores cached responses from a Galaxy server. This is only used by the ``ansible-galaxy collection install`` and ``download`` commands. Cache files inside this dir will be ignored if they are world writable." -msgstr "Galaxy サーバーからキャッシュされた応答を保存するディレクトリーです。これは ``ansible-galaxy collection install`` コマンドおよび ``download`` コマンドによってのみ使用されます。このディレクトリー内のキャッシュファイルは、誰でも書き込み可能であれば無視されます。" - -#: ../../rst/reference_appendices/config.rst:2222 -msgid "~/.ansible/galaxy_cache" -msgstr "~/.ansible/galaxy_cache" - -#: ../../rst/reference_appendices/config.rst:2225 -#: ../../rst/reference_appendices/config.rst:2240 -#: ../../rst/reference_appendices/config.rst:2254 -#: ../../rst/reference_appendices/config.rst:2268 -#: ../../rst/reference_appendices/config.rst:2282 -#: ../../rst/reference_appendices/config.rst:2295 -#: ../../rst/reference_appendices/config.rst:2309 -#: ../../rst/reference_appendices/config.rst:2324 -msgid "[galaxy]" -msgstr "[galaxy]" - -#: ../../rst/reference_appendices/config.rst:2226 -msgid "cache_dir" -msgstr "cache_dir" - -#: ../../rst/reference_appendices/config.rst:2228 -msgid ":envvar:`ANSIBLE_GALAXY_CACHE_DIR`" -msgstr ":envvar:`ANSIBLE_GALAXY_CACHE_DIR`" - -#: ../../rst/reference_appendices/config.rst:2233 -msgid "GALAXY_DISPLAY_PROGRESS" -msgstr "GALAXY_DISPLAY_PROGRESS" - -#: ../../rst/reference_appendices/config.rst:2235 -msgid "Some steps in ``ansible-galaxy`` display a progress wheel which can cause issues on certain displays or when outputting the stdout to a file. This config option controls whether the display wheel is shown or not. The default is to show the display wheel if stdout has a tty." -msgstr "``ansible-galaxy`` の一部の手順では、特定の表示で、または標準出力 (stdout) をファイルに出力するときに問題が発生する可能性のある進行状況ホイールを表示します。この設定オプションは、表示ホイールを表示するかどうかを制御します。デフォルトでは、stdout に tty があると、表示ホイールが表示されます。" - -#: ../../rst/reference_appendices/config.rst:2241 -msgid "display_progress" -msgstr "display_progress" - -#: ../../rst/reference_appendices/config.rst:2243 -msgid ":envvar:`ANSIBLE_GALAXY_DISPLAY_PROGRESS`" -msgstr ":envvar:`ANSIBLE_GALAXY_DISPLAY_PROGRESS`" - -#: ../../rst/reference_appendices/config.rst:2248 -msgid "GALAXY_IGNORE_CERTS" -msgstr "GALAXY_IGNORE_CERTS" - -#: ../../rst/reference_appendices/config.rst:2250 -#: ../../rst/reference_appendices/config.rst:4185 -msgid "If set to yes, ansible-galaxy will not validate TLS certificates. This can be useful for testing against a server with a self-signed certificate." -msgstr "yes に設定すると、ansible-galaxy が TLS 証明書を検証しません。これは、自己署名証明書を使用するサーバーに対してテストを行う場合に便利です。" - -#: ../../rst/reference_appendices/config.rst:2255 -msgid "ignore_certs" -msgstr "ignore_certs" - -#: ../../rst/reference_appendices/config.rst:2257 -msgid ":envvar:`ANSIBLE_GALAXY_IGNORE`" -msgstr ":envvar:`ANSIBLE_GALAXY_IGNORE`" - -#: ../../rst/reference_appendices/config.rst:2262 -msgid "GALAXY_ROLE_SKELETON" -msgstr "GALAXY_ROLE_SKELETON" - -#: ../../rst/reference_appendices/config.rst:2264 -#: ../../rst/reference_appendices/config.rst:4193 -msgid "Role or collection skeleton directory to use as a template for the ``init`` action in ``ansible-galaxy``, same as ``--role-skeleton``." -msgstr "``ansible-galaxy`` の ``init`` アクションのテンプレートとして使用するロールまたはコレクションのスケルトンディレクトリー。``--role-skeleton`` と同じです。" - -#: ../../rst/reference_appendices/config.rst:2269 -msgid "role_skeleton" -msgstr "role_skeleton" - -#: ../../rst/reference_appendices/config.rst:2271 -msgid ":envvar:`ANSIBLE_GALAXY_ROLE_SKELETON`" -msgstr ":envvar:`ANSIBLE_GALAXY_ROLE_SKELETON`" - -#: ../../rst/reference_appendices/config.rst:2276 -msgid "GALAXY_ROLE_SKELETON_IGNORE" -msgstr "GALAXY_ROLE_SKELETON_IGNORE" - -#: ../../rst/reference_appendices/config.rst:2278 -#: ../../rst/reference_appendices/config.rst:4201 -msgid "patterns of files to ignore inside a Galaxy role or collection skeleton directory" -msgstr "Galaxy ロールまたはコレクションスケルトンディレクトリー内で無視するファイルのパターン" - -#: ../../rst/reference_appendices/config.rst:2280 -msgid "['^.git$', '^.*/.git_keep$']" -msgstr "['^.git$', '^.*/.git_keep$']" - -#: ../../rst/reference_appendices/config.rst:2283 -msgid "role_skeleton_ignore" -msgstr "role_skeleton_ignore" - -#: ../../rst/reference_appendices/config.rst:2285 -msgid ":envvar:`ANSIBLE_GALAXY_ROLE_SKELETON_IGNORE`" -msgstr ":envvar:`ANSIBLE_GALAXY_ROLE_SKELETON_IGNORE`" - -#: ../../rst/reference_appendices/config.rst:2290 -msgid "GALAXY_SERVER" -msgstr "GALAXY_SERVER" - -#: ../../rst/reference_appendices/config.rst:2292 -#: ../../rst/reference_appendices/config.rst:4209 -msgid "URL to prepend when roles don't specify the full URI, assume they are referencing this server as the source." -msgstr "ロールが完全な URI を指定していない場合に先頭に追加する URL。このサーバーがソースとして参照されていることを前提とします。" - -#: ../../rst/reference_appendices/config.rst:2293 -msgid "https://galaxy.ansible.com" -msgstr "https://galaxy.ansible.com" - -#: ../../rst/reference_appendices/config.rst:2296 -msgid "server" -msgstr "server" - -#: ../../rst/reference_appendices/config.rst:2298 -msgid ":envvar:`ANSIBLE_GALAXY_SERVER`" -msgstr ":envvar:`ANSIBLE_GALAXY_SERVER`" - -#: ../../rst/reference_appendices/config.rst:2303 -msgid "GALAXY_SERVER_LIST" -msgstr "GALAXY_SERVER_LIST" - -#: ../../rst/reference_appendices/config.rst:2305 -msgid "A list of Galaxy servers to use when installing a collection. The value corresponds to the config ini header ``[galaxy_server.{{item}}]`` which defines the server details. See :ref:`galaxy_server_config` for more details on how to define a Galaxy server. The order of servers in this list is used to as the order in which a collection is resolved. Setting this config option will ignore the :ref:`galaxy_server` config option." -msgstr "コレクションのインストール時に使用する Galaxy サーバーの一覧。値は、サーバーの詳細を定義する config ini ヘッダー ``[galaxy_server.{{item}}]`` に対応します。Galaxy サーバーの定義方法の詳細は、「:ref:`galaxy_server_config`」を参照してください。この一覧のサーバーの順序は、コレクションの解決順序として使用されます。この設定オプションを設定すると、:ref:`galaxy_server` の設定オプションは無視されます。" - -#: ../../rst/reference_appendices/config.rst:2310 -msgid "server_list" -msgstr "server_list" - -#: ../../rst/reference_appendices/config.rst:2312 -msgid ":envvar:`ANSIBLE_GALAXY_SERVER_LIST`" -msgstr ":envvar:`ANSIBLE_GALAXY_SERVER_LIST`" - -#: ../../rst/reference_appendices/config.rst:2317 -msgid "GALAXY_TOKEN_PATH" -msgstr "GALAXY_TOKEN_PATH" - -#: ../../rst/reference_appendices/config.rst:2319 -#: ../../rst/reference_appendices/config.rst:4225 -msgid "Local path to galaxy access token file" -msgstr "galaxy アクセストークンファイルへのローカルパス" - -#: ../../rst/reference_appendices/config.rst:2321 -msgid "~/.ansible/galaxy_token" -msgstr "~/.ansible/galaxy_token" - -#: ../../rst/reference_appendices/config.rst:2325 -msgid "token_path" -msgstr "token_path" - -#: ../../rst/reference_appendices/config.rst:2327 -msgid ":envvar:`ANSIBLE_GALAXY_TOKEN_PATH`" -msgstr ":envvar:`ANSIBLE_GALAXY_TOKEN_PATH`" - -#: ../../rst/reference_appendices/config.rst:2332 -msgid "HOST_KEY_CHECKING" -msgstr "HOST_KEY_CHECKING" - -#: ../../rst/reference_appendices/config.rst:2334 -#: ../../rst/reference_appendices/config.rst:4249 -msgid "Set this to \"False\" if you want to avoid host key checking by the underlying tools Ansible uses to connect to the host" -msgstr "Ansible がホストへの接続に使用する基盤のツールでホストキーの確認を行わないようにするには、このパラメーターを「False」に設定します。" - -#: ../../rst/reference_appendices/config.rst:2339 -msgid "host_key_checking" -msgstr "host_key_checking" - -#: ../../rst/reference_appendices/config.rst:2341 -msgid ":envvar:`ANSIBLE_HOST_KEY_CHECKING`" -msgstr ":envvar:`ANSIBLE_HOST_KEY_CHECKING`" - -#: ../../rst/reference_appendices/config.rst:2346 -msgid "HOST_PATTERN_MISMATCH" -msgstr "HOST_PATTERN_MISMATCH" - -#: ../../rst/reference_appendices/config.rst:2348 -#: ../../rst/reference_appendices/config.rst:4257 -msgid "This setting changes the behaviour of mismatched host patterns, it allows you to force a fatal error, a warning or just ignore it" -msgstr "この設定により、一致しないホストパターンの動作が変更されます。これにより、致命的なエラーや警告を強制したり、無視することが可能になります。" - -#: ../../rst/reference_appendices/config.rst:2356 -#: ../../rst/reference_appendices/config.rst:2434 -#: ../../rst/reference_appendices/config.rst:2448 -#: ../../rst/reference_appendices/config.rst:2460 -#: ../../rst/reference_appendices/config.rst:2472 -#: ../../rst/reference_appendices/config.rst:2485 -#: ../../rst/reference_appendices/config.rst:2498 -#: ../../rst/reference_appendices/config.rst:2512 -#: ../../rst/reference_appendices/config.rst:2526 -#: ../../rst/reference_appendices/config.rst:2542 -#: ../../rst/reference_appendices/config.rst:2558 -#: ../../rst/reference_appendices/config.rst:2573 -msgid "[inventory]" -msgstr "[inventory]" - -#: ../../rst/reference_appendices/config.rst:2357 -msgid "host_pattern_mismatch" -msgstr "host_pattern_mismatch" - -#: ../../rst/reference_appendices/config.rst:2359 -msgid ":envvar:`ANSIBLE_HOST_PATTERN_MISMATCH`" -msgstr ":envvar:`ANSIBLE_HOST_PATTERN_MISMATCH`" - -#: ../../rst/reference_appendices/config.rst:2364 -msgid "INJECT_FACTS_AS_VARS" -msgstr "INJECT_FACTS_AS_VARS" - -#: ../../rst/reference_appendices/config.rst:2366 -msgid "Facts are available inside the `ansible_facts` variable, this setting also pushes them as their own vars in the main namespace. Unlike inside the `ansible_facts` dictionary, these will have an `ansible_` prefix." -msgstr "ファクトは `ansible_facts` 変数内で利用できます。この設定は、主な名前空間で独自の変数としてプッシュされます。`ansible_facts` ディクショナリー内とは異なり、これは `ansible_` の接頭辞があります。" - -#: ../../rst/reference_appendices/config.rst:2372 -msgid "inject_facts_as_vars" -msgstr "inject_facts_as_vars" - -#: ../../rst/reference_appendices/config.rst:2374 -msgid ":envvar:`ANSIBLE_INJECT_FACT_VARS`" -msgstr ":envvar:`ANSIBLE_INJECT_FACT_VARS`" - -#: ../../rst/reference_appendices/config.rst:2379 -msgid "INTERPRETER_PYTHON" -msgstr "INTERPRETER_PYTHON" - -#: ../../rst/reference_appendices/config.rst:2381 -#: ../../rst/reference_appendices/config.rst:4265 -msgid "Path to the Python interpreter to be used for module execution on remote targets, or an automatic discovery mode. Supported discovery modes are ``auto``, ``auto_silent``, and ``auto_legacy`` (the default). All discovery modes employ a lookup table to use the included system Python (on distributions known to include one), falling back to a fixed ordered list of well-known Python interpreter locations if a platform-specific default is not available. The fallback behavior will issue a warning that the interpreter should be set explicitly (since interpreters installed later may change which one is used). This warning behavior can be disabled by setting ``auto_silent``. The default value of ``auto_legacy`` provides all the same behavior, but for backwards-compatibility with older Ansible releases that always defaulted to ``/usr/bin/python``, will use that interpreter if present (and issue a warning that the default behavior will change to that of ``auto`` in a future Ansible release." -msgstr "リモートターゲットまたは自動検出モードでのモジュール実行に使用される Python インタープリターへのパス。サポートされている検出モードは、``auto``、``auto_silent``、および ``auto_legacy`` (デフォルト) です。すべての検出モードは、含まれているシステムの Python (含むことがディストリビューションで) を使用するためにルックアップテーブルを使用し、プラットフォーム固有のデフォルトが使用できない場合は、よく知られた Python インタープリターの位置の固定された順序リストにフォールバックします。フォールバック動作では、インタープリターを明示的に設定する必要があるという警告が出力されます (後からインストールされたインタープリターが、使用するインタープリターを変更する可能性があるからです)。この警告動作を無効にするには、``auto_silent`` を設定します。``auto_legacy`` のデフォルト値はすべて同じ動作を提供しますが、以前の Ansible リリースとの下位互換性のために、常にデフォルトで ``/usr/bin/python`` に設定されていた場合、存在する場合はそのインタープリターを使用します (デフォルトの動作が将来の Ansible リリースの ``auto`` の動作に変更することを示す警告を表示します)。" - -#: ../../rst/reference_appendices/config.rst:2382 -#: ../../rst/reference_appendices/interpreter_discovery.rst:31 -msgid "auto_legacy" -msgstr "auto_legacy" - -#: ../../rst/reference_appendices/config.rst:2386 -msgid "interpreter_python" -msgstr "interpreter_python" - -#: ../../rst/reference_appendices/config.rst:2388 -msgid ":envvar:`ANSIBLE_PYTHON_INTERPRETER`" -msgstr ":envvar:`ANSIBLE_PYTHON_INTERPRETER`" - -#: ../../rst/reference_appendices/config.rst:2390 -msgid "`ansible_python_interpreter`" -msgstr "`ansible_python_interpreter`" - -#: ../../rst/reference_appendices/config.rst:2395 -msgid "INTERPRETER_PYTHON_DISTRO_MAP" -msgstr "INTERPRETER_PYTHON_DISTRO_MAP" - -#: ../../rst/reference_appendices/config.rst:2397 -msgid "{'centos': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'debian': {'10': '/usr/bin/python3'}, 'fedora': {'23': '/usr/bin/python3'}, 'oracle': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'redhat': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'rhel': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'ubuntu': {'14': '/usr/bin/python', '16': '/usr/bin/python3'}}" -msgstr "{'centos': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'debian': {'10': '/usr/bin/python3'}, 'fedora': {'23': '/usr/bin/python3'}, 'oracle': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'redhat': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'rhel': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'ubuntu': {'14': '/usr/bin/python', '16': '/usr/bin/python3'}}" - -#: ../../rst/reference_appendices/config.rst:2403 -msgid "INTERPRETER_PYTHON_FALLBACK" -msgstr "INTERPRETER_PYTHON_FALLBACK" - -#: ../../rst/reference_appendices/config.rst:2405 -msgid "['/usr/bin/python', 'python3.9', 'python3.8', 'python3.7', 'python3.6', 'python3.5', 'python2.7', 'python2.6', '/usr/libexec/platform-python', '/usr/bin/python3', 'python']" -msgstr "['/usr/bin/python', 'python3.9', 'python3.8', 'python3.7', 'python3.6', 'python3.5', 'python2.7', 'python2.6', '/usr/libexec/platform-python', '/usr/bin/python3', 'python']" - -#: ../../rst/reference_appendices/config.rst:2411 -msgid "INVALID_TASK_ATTRIBUTE_FAILED" -msgstr "INVALID_TASK_ATTRIBUTE_FAILED" - -#: ../../rst/reference_appendices/config.rst:2413 -#: ../../rst/reference_appendices/config.rst:4283 -msgid "If 'false', invalid attributes for a task will result in warnings instead of errors" -msgstr "「false」の場合は、タスクの無効な属性により、エラーではなく警告が発生します。" - -#: ../../rst/reference_appendices/config.rst:2419 -msgid "invalid_task_attribute_failed" -msgstr "invalid_task_attribute_failed" - -#: ../../rst/reference_appendices/config.rst:2421 -msgid ":envvar:`ANSIBLE_INVALID_TASK_ATTRIBUTE_FAILED`" -msgstr ":envvar:`ANSIBLE_INVALID_TASK_ATTRIBUTE_FAILED`" - -#: ../../rst/reference_appendices/config.rst:2426 -msgid "INVENTORY_ANY_UNPARSED_IS_FAILED" -msgstr "INVENTORY_ANY_UNPARSED_IS_FAILED" - -#: ../../rst/reference_appendices/config.rst:2428 -#: ../../rst/reference_appendices/config.rst:4291 -msgid "If 'true', it is a fatal error when any given inventory source cannot be successfully parsed by any available inventory plugin; otherwise, this situation only attracts a warning." -msgstr "「true」の場合は、指定のインベントリーソースを利用可能な inventory プラグインで正常に解析できない場合に致命的なエラーになります。そうでないと、この状況は警告を招くだけとなります。" - -#: ../../rst/reference_appendices/config.rst:2435 -msgid "any_unparsed_is_failed" -msgstr "any_unparsed_is_failed" - -#: ../../rst/reference_appendices/config.rst:2437 -msgid ":envvar:`ANSIBLE_INVENTORY_ANY_UNPARSED_IS_FAILED`" -msgstr ":envvar:`ANSIBLE_INVENTORY_ANY_UNPARSED_IS_FAILED`" - -#: ../../rst/reference_appendices/config.rst:2442 -msgid "INVENTORY_CACHE_ENABLED" -msgstr "INVENTORY_CACHE_ENABLED" - -#: ../../rst/reference_appendices/config.rst:2444 -#: ../../rst/reference_appendices/config.rst:4300 -msgid "Toggle to turn on inventory caching" -msgstr "インベントリーキャッシュを有効に切り替えます。" - -#: ../../rst/reference_appendices/config.rst:2449 -msgid "cache" -msgstr "cache" - -#: ../../rst/reference_appendices/config.rst:2451 -msgid ":envvar:`ANSIBLE_INVENTORY_CACHE`" -msgstr ":envvar:`ANSIBLE_INVENTORY_CACHE`" - -#: ../../rst/reference_appendices/config.rst:2456 -msgid "INVENTORY_CACHE_PLUGIN" -msgstr "INVENTORY_CACHE_PLUGIN" - -#: ../../rst/reference_appendices/config.rst:2458 -#: ../../rst/reference_appendices/config.rst:4308 -msgid "The plugin for caching inventory. If INVENTORY_CACHE_PLUGIN is not provided CACHE_PLUGIN can be used instead." -msgstr "インベントリーのキャッシュ用のプラグイン。INVENTORY_CACHE_PLUGIN が指定されていない場合は、CACHE_PLUGIN を代わりに使用できます。" - -#: ../../rst/reference_appendices/config.rst:2461 -msgid "cache_plugin" -msgstr "cache_plugin" - -#: ../../rst/reference_appendices/config.rst:2463 -msgid ":envvar:`ANSIBLE_INVENTORY_CACHE_PLUGIN`" -msgstr ":envvar:`ANSIBLE_INVENTORY_CACHE_PLUGIN`" - -#: ../../rst/reference_appendices/config.rst:2468 -msgid "INVENTORY_CACHE_PLUGIN_CONNECTION" -msgstr "INVENTORY_CACHE_PLUGIN_CONNECTION" - -#: ../../rst/reference_appendices/config.rst:2470 -#: ../../rst/reference_appendices/config.rst:4316 -msgid "The inventory cache connection. If INVENTORY_CACHE_PLUGIN_CONNECTION is not provided CACHE_PLUGIN_CONNECTION can be used instead." -msgstr "インベントリーキャッシュ接続。INVENTORY_CACHE_PLUGIN_CONNECTION が指定されていない場合は、代わりに CACHE_PLUGIN_CONNECTION を使用できます。" - -#: ../../rst/reference_appendices/config.rst:2473 -msgid "cache_connection" -msgstr "cache_connection" - -#: ../../rst/reference_appendices/config.rst:2475 -msgid ":envvar:`ANSIBLE_INVENTORY_CACHE_CONNECTION`" -msgstr ":envvar:`ANSIBLE_INVENTORY_CACHE_CONNECTION`" - -#: ../../rst/reference_appendices/config.rst:2480 -msgid "INVENTORY_CACHE_PLUGIN_PREFIX" -msgstr "INVENTORY_CACHE_PLUGIN_PREFIX" - -#: ../../rst/reference_appendices/config.rst:2482 -#: ../../rst/reference_appendices/config.rst:4324 -msgid "The table prefix for the cache plugin. If INVENTORY_CACHE_PLUGIN_PREFIX is not provided CACHE_PLUGIN_PREFIX can be used instead." -msgstr "cache プラグインのテーブル接頭辞。INVENTORY_CACHE_PLUGIN_PREFIX が指定されていない場合は、代わりに CACHE_PLUGIN_PREFIX を使用できます。" - -#: ../../rst/reference_appendices/config.rst:2486 -msgid "cache_prefix" -msgstr "cache_prefix" - -#: ../../rst/reference_appendices/config.rst:2488 -msgid ":envvar:`ANSIBLE_INVENTORY_CACHE_PLUGIN_PREFIX`" -msgstr ":envvar:`ANSIBLE_INVENTORY_CACHE_PLUGIN_PREFIX`" - -#: ../../rst/reference_appendices/config.rst:2493 -msgid "INVENTORY_CACHE_TIMEOUT" -msgstr "INVENTORY_CACHE_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:2495 -#: ../../rst/reference_appendices/config.rst:4332 -msgid "Expiration timeout for the inventory cache plugin data. If INVENTORY_CACHE_TIMEOUT is not provided CACHE_TIMEOUT can be used instead." -msgstr "inventory cache プラグインデータの有効期限のタイムアウト。INVENTORY_CACHE_TIMEOUT が指定されていない場合は、代わりに CACHE_TIMEOUT を使用できます。" - -#: ../../rst/reference_appendices/config.rst:2496 -msgid "3600" -msgstr "3600" - -#: ../../rst/reference_appendices/config.rst:2499 -msgid "cache_timeout" -msgstr "cache_timeout" - -#: ../../rst/reference_appendices/config.rst:2501 -msgid ":envvar:`ANSIBLE_INVENTORY_CACHE_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_INVENTORY_CACHE_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:2506 -msgid "INVENTORY_ENABLED" -msgstr "INVENTORY_ENABLED" - -#: ../../rst/reference_appendices/config.rst:2508 -#: ../../rst/reference_appendices/config.rst:4340 -msgid "List of enabled inventory plugins, it also determines the order in which they are used." -msgstr "有効な inventory プラグインのリスト。また、使用する順序も決定します。" - -#: ../../rst/reference_appendices/config.rst:2510 -msgid "['host_list', 'script', 'auto', 'yaml', 'ini', 'toml']" -msgstr "['host_list', 'script', 'auto', 'yaml', 'ini', 'toml']" - -#: ../../rst/reference_appendices/config.rst:2513 -msgid "enable_plugins" -msgstr "enable_plugins" - -#: ../../rst/reference_appendices/config.rst:2515 -msgid ":envvar:`ANSIBLE_INVENTORY_ENABLED`" -msgstr ":envvar:`ANSIBLE_INVENTORY_ENABLED`" - -#: ../../rst/reference_appendices/config.rst:2520 -msgid "INVENTORY_EXPORT" -msgstr "INVENTORY_EXPORT" - -#: ../../rst/reference_appendices/config.rst:2522 -#: ../../rst/reference_appendices/config.rst:4348 -msgid "Controls if ansible-inventory will accurately reflect Ansible's view into inventory or its optimized for exporting." -msgstr "ansible-inventory が Ansible のビューをインベントリーに正確に反映させるか、またはエクスポートに最適化するかを制御します。" - -#: ../../rst/reference_appendices/config.rst:2527 -msgid "export" -msgstr "export" - -#: ../../rst/reference_appendices/config.rst:2529 -msgid ":envvar:`ANSIBLE_INVENTORY_EXPORT`" -msgstr ":envvar:`ANSIBLE_INVENTORY_EXPORT`" - -#: ../../rst/reference_appendices/config.rst:2534 -msgid "INVENTORY_IGNORE_EXTS" -msgstr "INVENTORY_IGNORE_EXTS" - -#: ../../rst/reference_appendices/config.rst:2536 -#: ../../rst/reference_appendices/config.rst:4356 -msgid "List of extensions to ignore when using a directory as an inventory source" -msgstr "ディレクトリーをインベントリーソースとして使用する際に無視する拡張機能の一覧" - -#: ../../rst/reference_appendices/config.rst:2538 -msgid "{{(REJECT_EXTS + ('.orig', '.ini', '.cfg', '.retry'))}}" -msgstr "{{(REJECT_EXTS + ('.orig', '.ini', '.cfg', '.retry'))}}" - -#: ../../rst/reference_appendices/config.rst:2541 -msgid "inventory_ignore_extensions" -msgstr "inventory_ignore_extensions" - -#: ../../rst/reference_appendices/config.rst:2543 -msgid "ignore_extensions" -msgstr "ignore_extensions" - -#: ../../rst/reference_appendices/config.rst:2545 -msgid ":envvar:`ANSIBLE_INVENTORY_IGNORE`" -msgstr ":envvar:`ANSIBLE_INVENTORY_IGNORE`" - -#: ../../rst/reference_appendices/config.rst:2550 -msgid "INVENTORY_IGNORE_PATTERNS" -msgstr "INVENTORY_IGNORE_PATTERNS" - -#: ../../rst/reference_appendices/config.rst:2552 -#: ../../rst/reference_appendices/config.rst:4364 -msgid "List of patterns to ignore when using a directory as an inventory source" -msgstr "ディレクトリーをインベントリーソースとして使用する場合に無視するパターンの一覧" - -#: ../../rst/reference_appendices/config.rst:2557 -msgid "inventory_ignore_patterns" -msgstr "inventory_ignore_patterns" - -#: ../../rst/reference_appendices/config.rst:2559 -msgid "ignore_patterns" -msgstr "ignore_patterns" - -#: ../../rst/reference_appendices/config.rst:2561 -msgid ":envvar:`ANSIBLE_INVENTORY_IGNORE_REGEX`" -msgstr ":envvar:`ANSIBLE_INVENTORY_IGNORE_REGEX`" - -#: ../../rst/reference_appendices/config.rst:2566 -msgid "INVENTORY_UNPARSED_IS_FAILED" -msgstr "INVENTORY_UNPARSED_IS_FAILED" - -#: ../../rst/reference_appendices/config.rst:2568 -#: ../../rst/reference_appendices/config.rst:4372 -msgid "If 'true' it is a fatal error if every single potential inventory source fails to parse, otherwise this situation will only attract a warning." -msgstr "「true」にすると、すべての潜在的なインベントリーソースが解析に失敗した場合に致命的なエラーとなります。そうしないと、この状況は警告を招くだけです。" - -#: ../../rst/reference_appendices/config.rst:2574 -msgid "unparsed_is_failed" -msgstr "unparsed_is_failed" - -#: ../../rst/reference_appendices/config.rst:2576 -msgid ":envvar:`ANSIBLE_INVENTORY_UNPARSED_FAILED`" -msgstr ":envvar:`ANSIBLE_INVENTORY_UNPARSED_FAILED`" - -#: ../../rst/reference_appendices/config.rst:2581 -msgid "LOCALHOST_WARNING" -msgstr "LOCALHOST_WARNING" - -#: ../../rst/reference_appendices/config.rst:2583 -msgid "By default Ansible will issue a warning when there are no hosts in the inventory. These warnings can be silenced by adjusting this setting to False." -msgstr "デフォルトでは、Ansible は、インベントリーにホストがない場合に警告を表示します。この警告は、この設定を False に設定すると非表示にすることができます。" - -#: ../../rst/reference_appendices/config.rst:2586 -msgid "2.6" -msgstr "2.6" - -#: ../../rst/reference_appendices/config.rst:2589 -msgid "localhost_warning" -msgstr "localhost_warning" - -#: ../../rst/reference_appendices/config.rst:2591 -msgid ":envvar:`ANSIBLE_LOCALHOST_WARNING`" -msgstr ":envvar:`ANSIBLE_LOCALHOST_WARNING`" - -#: ../../rst/reference_appendices/config.rst:2596 -msgid "MAX_FILE_SIZE_FOR_DIFF" -msgstr "MAX_FILE_SIZE_FOR_DIFF" - -#: ../../rst/reference_appendices/config.rst:2598 -#: ../../rst/reference_appendices/config.rst:4381 -msgid "Maximum size of files to be considered for diff display" -msgstr "diff 表示に考慮されるファイルの最大サイズ" - -#: ../../rst/reference_appendices/config.rst:2599 -#: ../../rst/reference_appendices/config.rst:2698 -msgid "int" -msgstr "int" - -#: ../../rst/reference_appendices/config.rst:2600 -msgid "104448" -msgstr "104448" - -#: ../../rst/reference_appendices/config.rst:2603 -msgid "max_diff_size" -msgstr "max_diff_size" - -#: ../../rst/reference_appendices/config.rst:2605 -msgid ":envvar:`ANSIBLE_MAX_DIFF_SIZE`" -msgstr ":envvar:`ANSIBLE_MAX_DIFF_SIZE`" - -#: ../../rst/reference_appendices/config.rst:2610 -msgid "MODULE_IGNORE_EXTS" -msgstr "MODULE_IGNORE_EXTS" - -#: ../../rst/reference_appendices/config.rst:2612 -msgid "List of extensions to ignore when looking for modules to load This is for rejecting script and binary module fallback extensions" -msgstr "読み込むモジュールを探すときに無視する拡張機能のリスト。これは、スクリプトおよびバイナリーモジュールのフォールバック拡張機能を拒否するためのものです。" - -#: ../../rst/reference_appendices/config.rst:2614 -msgid "{{(REJECT_EXTS + ('.yaml', '.yml', '.ini'))}}" -msgstr "{{(REJECT_EXTS + ('.yaml', '.yml', '.ini'))}}" - -#: ../../rst/reference_appendices/config.rst:2617 -msgid "module_ignore_exts" -msgstr "module_ignore_exts" - -#: ../../rst/reference_appendices/config.rst:2619 -msgid ":envvar:`ANSIBLE_MODULE_IGNORE_EXTS`" -msgstr ":envvar:`ANSIBLE_MODULE_IGNORE_EXTS`" - -#: ../../rst/reference_appendices/config.rst:2624 -msgid "NETCONF_SSH_CONFIG" -msgstr "NETCONF_SSH_CONFIG" - -#: ../../rst/reference_appendices/config.rst:2626 -#: ../../rst/reference_appendices/config.rst:4628 -msgid "This variable is used to enable bastion/jump host with netconf connection. If set to True the bastion/jump host ssh settings should be present in ~/.ssh/config file, alternatively it can be set to custom ssh configuration file path to read the bastion/jump host settings." -msgstr "この変数は、netconf 接続で bastion/ジャンプホストを有効にするために使用されます。Trueに設定すると、bastion/ジャンプホストの ssh 設定が ~/.ssh/config ファイルに存在する必要があります。または、カスタムの ssh 設定ファイルパスに設定して、bastion/ジャンプホストの設定を読み取ることもできます。" - -#: ../../rst/reference_appendices/config.rst:2629 -msgid "[netconf_connection]" -msgstr "[netconf_connection]" - -#: ../../rst/reference_appendices/config.rst:2630 -msgid "ssh_config" -msgstr "ssh_config" - -#: ../../rst/reference_appendices/config.rst:2632 -msgid ":envvar:`ANSIBLE_NETCONF_SSH_CONFIG`" -msgstr ":envvar:`ANSIBLE_NETCONF_SSH_CONFIG`" - -#: ../../rst/reference_appendices/config.rst:2637 -msgid "NETWORK_GROUP_MODULES" -msgstr "NETWORK_GROUP_MODULES" - -#: ../../rst/reference_appendices/config.rst:2640 -msgid "['eos', 'nxos', 'ios', 'iosxr', 'junos', 'enos', 'ce', 'vyos', 'sros', 'dellos9', 'dellos10', 'dellos6', 'asa', 'aruba', 'aireos', 'bigip', 'ironware', 'onyx', 'netconf', 'exos', 'voss', 'slxos']" -msgstr "['eos', 'nxos', 'ios', 'iosxr', 'junos', 'enos', 'ce', 'vyos', 'sros', 'dellos9', 'dellos10', 'dellos6', 'asa', 'aruba', 'aireos', 'bigip', 'ironware', 'onyx', 'netconf', 'exos', 'voss', 'slxos']" - -#: ../../rst/reference_appendices/config.rst:2643 -msgid "network_group_modules" -msgstr "network_group_modules" - -#: ../../rst/reference_appendices/config.rst:2645 -msgid ":envvar:`ANSIBLE_NETWORK_GROUP_MODULES`" -msgstr ":envvar:`ANSIBLE_NETWORK_GROUP_MODULES`" - -#: ../../rst/reference_appendices/config.rst:2646 -msgid ":envvar:`NETWORK_GROUP_MODULES`" -msgstr ":envvar:`NETWORK_GROUP_MODULES`" - -#: ../../rst/reference_appendices/config.rst:2649 -#: ../../rst/reference_appendices/config.rst:4394 -msgid "the ``ANSIBLE_NETWORK_GROUP_MODULES`` environment variable" -msgstr "``ANSIBLE_NETWORK_GROUP_MODULES`` 環境変数" - -#: ../../rst/reference_appendices/config.rst:2654 -msgid "OLD_PLUGIN_CACHE_CLEARING" -msgstr "OLD_PLUGIN_CACHE_CLEARING" - -#: ../../rst/reference_appendices/config.rst:2656 -#: ../../rst/reference_appendices/config.rst:4421 -msgid "Previously Ansible would only clear some of the plugin loading caches when loading new roles, this led to some behaviours in which a plugin loaded in previous plays would be unexpectedly 'sticky'. This setting allows to return to that behaviour." -msgstr "以前の Ansible は、新しいロールを読み込むときにプラグインの読み込みキャッシュの一部のみを削除していました。これにより、以前のプレイで読み込まれたプラグインが予期せず「スティッキー」になる動作が発生しました。この設定により、その動作に戻ることができます。" - -#: ../../rst/reference_appendices/config.rst:2662 -msgid "old_plugin_cache_clear" -msgstr "old_plugin_cache_clear" - -#: ../../rst/reference_appendices/config.rst:2664 -msgid ":envvar:`ANSIBLE_OLD_PLUGIN_CACHE_CLEAR`" -msgstr ":envvar:`ANSIBLE_OLD_PLUGIN_CACHE_CLEAR`" - -#: ../../rst/reference_appendices/config.rst:2669 -msgid "PARAMIKO_HOST_KEY_AUTO_ADD" -msgstr "PARAMIKO_HOST_KEY_AUTO_ADD" - -#: ../../rst/reference_appendices/config.rst:2674 -#: ../../rst/reference_appendices/config.rst:2687 -msgid "[paramiko_connection]" -msgstr "[paramiko_connection]" - -#: ../../rst/reference_appendices/config.rst:2675 -msgid "host_key_auto_add" -msgstr "host_key_auto_add" - -#: ../../rst/reference_appendices/config.rst:2677 -msgid ":envvar:`ANSIBLE_PARAMIKO_HOST_KEY_AUTO_ADD`" -msgstr ":envvar:`ANSIBLE_PARAMIKO_HOST_KEY_AUTO_ADD`" - -#: ../../rst/reference_appendices/config.rst:2682 -msgid "PARAMIKO_LOOK_FOR_KEYS" -msgstr "PARAMIKO_LOOK_FOR_KEYS" - -#: ../../rst/reference_appendices/config.rst:2688 -msgid "look_for_keys" -msgstr "look_for_keys" - -#: ../../rst/reference_appendices/config.rst:2690 -msgid ":envvar:`ANSIBLE_PARAMIKO_LOOK_FOR_KEYS`" -msgstr ":envvar:`ANSIBLE_PARAMIKO_LOOK_FOR_KEYS`" - -#: ../../rst/reference_appendices/config.rst:2695 -msgid "PERSISTENT_COMMAND_TIMEOUT" -msgstr "PERSISTENT_COMMAND_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:2697 -#: ../../rst/reference_appendices/config.rst:4467 -msgid "This controls the amount of time to wait for response from remote device before timing out persistent connection." -msgstr "これは、永続的な接続をタイムアウトする前に、リモートデバイスからの応答を待つ時間を制御します。" - -#: ../../rst/reference_appendices/config.rst:2699 -#: ../../rst/reference_appendices/config.rst:2727 -msgid "30" -msgstr "30" - -#: ../../rst/reference_appendices/config.rst:2702 -msgid "command_timeout" -msgstr "command_timeout" - -#: ../../rst/reference_appendices/config.rst:2704 -msgid ":envvar:`ANSIBLE_PERSISTENT_COMMAND_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_PERSISTENT_COMMAND_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:2709 -msgid "PERSISTENT_CONNECT_RETRY_TIMEOUT" -msgstr "PERSISTENT_CONNECT_RETRY_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:2711 -#: ../../rst/reference_appendices/config.rst:4459 -msgid "This controls the retry timeout for persistent connection to connect to the local domain socket." -msgstr "これにより、ローカルドメインソケットに接続する永続接続の再試行タイムアウトを制御します。" - -#: ../../rst/reference_appendices/config.rst:2716 -msgid "connect_retry_timeout" -msgstr "connect_retry_timeout" - -#: ../../rst/reference_appendices/config.rst:2718 -msgid ":envvar:`ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:2723 -msgid "PERSISTENT_CONNECT_TIMEOUT" -msgstr "PERSISTENT_CONNECT_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:2725 -#: ../../rst/reference_appendices/config.rst:4451 -msgid "This controls how long the persistent connection will remain idle before it is destroyed." -msgstr "これは、アイドル状態になり、永続接続が破棄されるまでの期間を制御します。" - -#: ../../rst/reference_appendices/config.rst:2730 -msgid "connect_timeout" -msgstr "connect_timeout" - -#: ../../rst/reference_appendices/config.rst:2732 -msgid ":envvar:`ANSIBLE_PERSISTENT_CONNECT_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_PERSISTENT_CONNECT_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:2737 -msgid "PERSISTENT_CONTROL_PATH_DIR" -msgstr "PERSISTENT_CONTROL_PATH_DIR" - -#: ../../rst/reference_appendices/config.rst:2739 -#: ../../rst/reference_appendices/config.rst:4443 -msgid "Path to socket to be used by the connection persistence system." -msgstr "接続永続システムによって使用されるソケットへのパス。" - -#: ../../rst/reference_appendices/config.rst:2741 -msgid "~/.ansible/pc" -msgstr "~/.ansible/pc" - -#: ../../rst/reference_appendices/config.rst:2744 -msgid "control_path_dir" -msgstr "control_path_dir" - -#: ../../rst/reference_appendices/config.rst:2746 -msgid ":envvar:`ANSIBLE_PERSISTENT_CONTROL_PATH_DIR`" -msgstr ":envvar:`ANSIBLE_PERSISTENT_CONTROL_PATH_DIR`" - -#: ../../rst/reference_appendices/config.rst:2751 -msgid "PLAYBOOK_DIR" -msgstr "PLAYBOOK_DIR" - -#: ../../rst/reference_appendices/config.rst:2753 -#: ../../rst/reference_appendices/config.rst:4475 -msgid "A number of non-playbook CLIs have a ``--playbook-dir`` argument; this sets the default value for it." -msgstr "Playbook 以外の CLI の多くに ``--playbook-dir`` 引数があり、これによりデフォルト値が設定されます。" - -#: ../../rst/reference_appendices/config.rst:2758 -#: ../../rst/reference_appendices/special_variables.rst:122 -msgid "playbook_dir" -msgstr "playbook_dir" - -#: ../../rst/reference_appendices/config.rst:2760 -msgid ":envvar:`ANSIBLE_PLAYBOOK_DIR`" -msgstr ":envvar:`ANSIBLE_PLAYBOOK_DIR`" - -#: ../../rst/reference_appendices/config.rst:2765 -msgid "PLAYBOOK_VARS_ROOT" -msgstr "PLAYBOOK_VARS_ROOT" - -#: ../../rst/reference_appendices/config.rst:2767 -msgid "This sets which playbook dirs will be used as a root to process vars plugins, which includes finding host_vars/group_vars The ``top`` option follows the traditional behaviour of using the top playbook in the chain to find the root directory. The ``bottom`` option follows the 2.4.0 behaviour of using the current playbook to find the root directory. The ``all`` option examines from the first parent to the current playbook." -msgstr "これにより、vars プラグインを処理するためのルートとして使用される Playbook ディレクトリーが設定されます。これには、host_vars/group_vars の検索が含まれます。``top`` オプションは、チェーンの最上位の Playbook を使用してルートディレクトリーを見つけるという従来の動作に従います。``bottom`` オプションは、現在の Playbook を使用してルートディレクトリーを検索する 2.4.0 の動作に従います。``all`` オプションは、最初の親から現在の Playbook までを調べます。" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:2768 -msgid "top" -msgstr "top" - -#: ../../rst/reference_appendices/config.rst -msgid "bottom" -msgstr "bottom" - -#: ../../rst/reference_appendices/config.rst -msgid "all" -msgstr "all" - -#: ../../rst/reference_appendices/config.rst:2773 -msgid "2.4.1" -msgstr "2.4.1" - -#: ../../rst/reference_appendices/config.rst:2776 -msgid "playbook_vars_root" -msgstr "playbook_vars_root" - -#: ../../rst/reference_appendices/config.rst:2778 -msgid ":envvar:`ANSIBLE_PLAYBOOK_VARS_ROOT`" -msgstr ":envvar:`ANSIBLE_PLAYBOOK_VARS_ROOT`" - -#: ../../rst/reference_appendices/config.rst:2783 -msgid "PLUGIN_FILTERS_CFG" -msgstr "PLUGIN_FILTERS_CFG" - -#: ../../rst/reference_appendices/config.rst:2785 -msgid "A path to configuration for filtering which plugins installed on the system are allowed to be used. See :ref:`plugin_filtering_config` for details of the filter file's format. The default is /etc/ansible/plugin_filters.yml" -msgstr "システムにインストールされているプラグインのうち、どのプラグインの使用を許可するかをフィルタリングするための設定のパスです。フィルターファイルの形式の詳細は、「:ref:`plugin_filtering_config`」を参照してください。デフォルトは /etc/ansible/plugin_filters.yml です。" - -#: ../../rst/reference_appendices/config.rst:2788 -msgid "2.5.0" -msgstr "2.5.0" - -#: ../../rst/reference_appendices/config.rst:2790 -msgid "[default]" -msgstr "[default]" - -#: ../../rst/reference_appendices/config.rst:2791 -#: ../../rst/reference_appendices/config.rst:2796 -msgid "plugin_filters_cfg" -msgstr "plugin_filters_cfg" - -#: ../../rst/reference_appendices/config.rst:2793 -msgid "specifying \"plugin_filters_cfg\" under the \"default\" section is deprecated" -msgstr "「default」セクションに「plugin_filters_cfg」を指定することが非推奨になりました。" - -#: ../../rst/reference_appendices/config.rst:2794 -msgid "the \"defaults\" section instead" -msgstr "代わりに「default」セクションが使用されます。" - -#: ../../rst/reference_appendices/config.rst:2801 -msgid "PYTHON_MODULE_RLIMIT_NOFILE" -msgstr "PYTHON_MODULE_RLIMIT_NOFILE" - -#: ../../rst/reference_appendices/config.rst:2803 -#: ../../rst/reference_appendices/config.rst:4492 -msgid "Attempts to set RLIMIT_NOFILE soft limit to the specified value when executing Python modules (can speed up subprocess usage on Python 2.x. See https://bugs.python.org/issue11284). The value will be limited by the existing hard limit. Default value of 0 does not attempt to adjust existing system-defined limits." -msgstr "Python モジュールの実行時に RLIMIT_NOFILE ソフト制限を指定された値に設定しようとします (Python2.x でのサブプロセスの使用を高速化できます。https://bugs.python.org/issue11284 を参照してください)。この値は、既存のハード制限によって制限されます。デフォルト値の 0 は、既存のシステム定義の制限を調整しようとはしません。" - -#: ../../rst/reference_appendices/config.rst:2808 -msgid "python_module_rlimit_nofile" -msgstr "python_module_rlimit_nofile" - -#: ../../rst/reference_appendices/config.rst:2810 -msgid ":envvar:`ANSIBLE_PYTHON_MODULE_RLIMIT_NOFILE`" -msgstr ":envvar:`ANSIBLE_PYTHON_MODULE_RLIMIT_NOFILE`" - -#: ../../rst/reference_appendices/config.rst:2812 -msgid "`ansible_python_module_rlimit_nofile`" -msgstr "`ansible_python_module_rlimit_nofile`" - -#: ../../rst/reference_appendices/config.rst:2817 -msgid "RETRY_FILES_ENABLED" -msgstr "RETRY_FILES_ENABLED" - -#: ../../rst/reference_appendices/config.rst:2819 -#: ../../rst/reference_appendices/config.rst:4500 -msgid "This controls whether a failed Ansible playbook should create a .retry file." -msgstr "これにより、失敗した Ansible Playbook が .retry ファイルを作成するかどうかを制御します。" - -#: ../../rst/reference_appendices/config.rst:2824 -msgid "retry_files_enabled" -msgstr "retry_files_enabled" - -#: ../../rst/reference_appendices/config.rst:2826 -msgid ":envvar:`ANSIBLE_RETRY_FILES_ENABLED`" -msgstr ":envvar:`ANSIBLE_RETRY_FILES_ENABLED`" - -#: ../../rst/reference_appendices/config.rst:2831 -msgid "RETRY_FILES_SAVE_PATH" -msgstr "RETRY_FILES_SAVE_PATH" - -#: ../../rst/reference_appendices/config.rst:2833 -msgid "This sets the path in which Ansible will save .retry files when a playbook fails and retry files are enabled. This file will be overwritten after each run with the list of failed hosts from all plays." -msgstr "これにより、Playbook が失敗し、再試行ファイルが有効になっている場合に、Ansible が .retry ファイルを保存するパスが設定されます。このファイルは、実行するたびに、すべてのプレイで失敗したホストのリストで上書きされます。" - -#: ../../rst/reference_appendices/config.rst:2838 -msgid "retry_files_save_path" -msgstr "retry_files_save_path" - -#: ../../rst/reference_appendices/config.rst:2840 -msgid ":envvar:`ANSIBLE_RETRY_FILES_SAVE_PATH`" -msgstr ":envvar:`ANSIBLE_RETRY_FILES_SAVE_PATH`" - -#: ../../rst/reference_appendices/config.rst:2845 -msgid "RUN_VARS_PLUGINS" -msgstr "RUN_VARS_PLUGINS" - -#: ../../rst/reference_appendices/config.rst:2847 -msgid "This setting can be used to optimize vars_plugin usage depending on user's inventory size and play selection. Setting to C(demand) will run vars_plugins relative to inventory sources anytime vars are 'demanded' by tasks. Setting to C(start) will run vars_plugins relative to inventory sources after importing that inventory source." -msgstr "この設定は、ユーザーのインベントリーサイズとプレイの選択に応じて vars_plugin の使用を最適化するために使用できます。C(demand) に設定すると、タスクによって変数が「要求」されるたびに、インベントリーソースに関連して vars_plugins が実行されます。C(start) に設定すると、インベントリーソースをインポートした後、インベントリーソースに関連して vars_plugins が実行されます。" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:2849 -msgid "demand" -msgstr "demand" - -#: ../../rst/reference_appendices/config.rst -msgid "start" -msgstr "start" - -#: ../../rst/reference_appendices/config.rst:2856 -msgid "run_vars_plugins" -msgstr "run_vars_plugins" - -#: ../../rst/reference_appendices/config.rst:2858 -msgid ":envvar:`ANSIBLE_RUN_VARS_PLUGINS`" -msgstr ":envvar:`ANSIBLE_RUN_VARS_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:2863 -msgid "SHOW_CUSTOM_STATS" -msgstr "SHOW_CUSTOM_STATS" - -#: ../../rst/reference_appendices/config.rst:2865 -#: ../../rst/reference_appendices/config.rst:4524 -msgid "This adds the custom stats set via the set_stats plugin to the default output" -msgstr "これにより、set_stats プラグインを介してカスタム統計セットがデフォルトの出力に追加されます。" - -#: ../../rst/reference_appendices/config.rst:2870 -msgid "show_custom_stats" -msgstr "show_custom_stats" - -#: ../../rst/reference_appendices/config.rst:2872 -msgid ":envvar:`ANSIBLE_SHOW_CUSTOM_STATS`" -msgstr ":envvar:`ANSIBLE_SHOW_CUSTOM_STATS`" - -#: ../../rst/reference_appendices/config.rst:2877 -msgid "STRING_CONVERSION_ACTION" -msgstr "STRING_CONVERSION_ACTION" - -#: ../../rst/reference_appendices/config.rst:2879 -msgid "Action to take when a module parameter value is converted to a string (this does not affect variables). For string parameters, values such as '1.00', \"['a', 'b',]\", and 'yes', 'y', etc. will be converted by the YAML parser unless fully quoted. Valid options are 'error', 'warn', and 'ignore'. Since 2.8, this option defaults to 'warn' but will change to 'error' in 2.12." -msgstr "モジュールパラメーター値が文字列に変換されるときに実行するアクション (これは変数には影響しません)。文字列パラメーターの場合、「1.00」、「['a', 'b',]」、「yes」、「y」などの値は、完全に引用されていない限り、YAML パーサーにより変換されます。有効なオプションは、「error」、「warn」、および「ignore」です。2.8 以降、このオプションのデフォルトは「warn」ですが、2.12では「error」に変更されます。" - -#: ../../rst/reference_appendices/config.rst:2885 -msgid "string_conversion_action" -msgstr "string_conversion_action" - -#: ../../rst/reference_appendices/config.rst:2887 -msgid ":envvar:`ANSIBLE_STRING_CONVERSION_ACTION`" -msgstr ":envvar:`ANSIBLE_STRING_CONVERSION_ACTION`" - -#: ../../rst/reference_appendices/config.rst:2892 -msgid "STRING_TYPE_FILTERS" -msgstr "STRING_TYPE_FILTERS" - -#: ../../rst/reference_appendices/config.rst:2894 -msgid "This list of filters avoids 'type conversion' when templating variables Useful when you want to avoid conversion into lists or dictionaries for JSON strings, for example." -msgstr "このフィルターのリストは、変数をテンプレート化するときに「型変換」を回避します。たとえば、JSON 文字列のリストやディレクトリーへの変換を回避したい場合に便利です。" - -#: ../../rst/reference_appendices/config.rst:2896 -msgid "['string', 'to_json', 'to_nice_json', 'to_yaml', 'to_nice_yaml', 'ppretty', 'json']" -msgstr "['string', 'to_json', 'to_nice_json', 'to_yaml', 'to_nice_yaml', 'ppretty', 'json']" - -#: ../../rst/reference_appendices/config.rst:2898 -msgid "[jinja2]" -msgstr "[jinja2]" - -#: ../../rst/reference_appendices/config.rst:2899 -msgid "dont_type_filters" -msgstr "dont_type_filters" - -#: ../../rst/reference_appendices/config.rst:2901 -msgid ":envvar:`ANSIBLE_STRING_TYPE_FILTERS`" -msgstr ":envvar:`ANSIBLE_STRING_TYPE_FILTERS`" - -#: ../../rst/reference_appendices/config.rst:2906 -msgid "SYSTEM_WARNINGS" -msgstr "SYSTEM_WARNINGS" - -#: ../../rst/reference_appendices/config.rst:2908 -msgid "Allows disabling of warnings related to potential issues on the system running ansible itself (not on the managed hosts) These may include warnings about 3rd party packages or other conditions that should be resolved if possible." -msgstr "Ansible 自体を実行している (管理対象ホストではない) システムの潜在的な問題に関連する警告を無効にすることができます。これには、サードパーティーのパッケージに関する警告や、可能であれば解決する必要のあるその他の条件が含まれる場合があります。" - -#: ../../rst/reference_appendices/config.rst:2913 -msgid "system_warnings" -msgstr "system_warnings" - -#: ../../rst/reference_appendices/config.rst:2915 -msgid ":envvar:`ANSIBLE_SYSTEM_WARNINGS`" -msgstr ":envvar:`ANSIBLE_SYSTEM_WARNINGS`" - -#: ../../rst/reference_appendices/config.rst:2920 -msgid "TAGS_RUN" -msgstr "TAGS_RUN" - -#: ../../rst/reference_appendices/config.rst:2922 -#: ../../rst/reference_appendices/config.rst:4548 -msgid "default list of tags to run in your plays, Skip Tags has precedence." -msgstr "プレイで実行するタグのデフォルト一覧。Skip Tags が優先されます。" - -#: ../../rst/reference_appendices/config.rst:2927 -#: ../../rst/reference_appendices/config.rst:2942 -msgid "[tags]" -msgstr "[tags]" - -#: ../../rst/reference_appendices/config.rst:2928 -msgid "run" -msgstr "run" - -#: ../../rst/reference_appendices/config.rst:2930 -msgid ":envvar:`ANSIBLE_RUN_TAGS`" -msgstr ":envvar:`ANSIBLE_RUN_TAGS`" - -#: ../../rst/reference_appendices/config.rst:2935 -msgid "TAGS_SKIP" -msgstr "TAGS_SKIP" - -#: ../../rst/reference_appendices/config.rst:2937 -#: ../../rst/reference_appendices/config.rst:4556 -msgid "default list of tags to skip in your plays, has precedence over Run Tags" -msgstr "プレイでスキップするタグのデフォルト一覧は Run Tags よりも優先" - -#: ../../rst/reference_appendices/config.rst:2945 -msgid ":envvar:`ANSIBLE_SKIP_TAGS`" -msgstr ":envvar:`ANSIBLE_SKIP_TAGS`" - -#: ../../rst/reference_appendices/config.rst:2950 -msgid "TASK_DEBUGGER_IGNORE_ERRORS" -msgstr "TASK_DEBUGGER_IGNORE_ERRORS" - -#: ../../rst/reference_appendices/config.rst:2952 -msgid "This option defines whether the task debugger will be invoked on a failed task when ignore_errors=True is specified. True specifies that the debugger will honor ignore_errors, False will not honor ignore_errors." -msgstr "このオプションは、ignore_errors=True が指定されている場合に、失敗したタスクでタスクデバッガーが呼び出されるかどうかを定義します。True に設定すると、デバッガーが ignore_errors を許可するように指定し、False に設定すると ignore_errors が無効になります。" - -#: ../../rst/reference_appendices/config.rst:2958 -msgid "task_debugger_ignore_errors" -msgstr "task_debugger_ignore_errors" - -#: ../../rst/reference_appendices/config.rst:2960 -msgid ":envvar:`ANSIBLE_TASK_DEBUGGER_IGNORE_ERRORS`" -msgstr ":envvar:`ANSIBLE_TASK_DEBUGGER_IGNORE_ERRORS`" - -#: ../../rst/reference_appendices/config.rst:2965 -msgid "TASK_TIMEOUT" -msgstr "TASK_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:2967 -msgid "Set the maximum time (in seconds) that a task can run for. If set to 0 (the default) there is no timeout." -msgstr "タスクを実行できる最大時間 (秒単位) を設定します。0 (デフォルト) に設定するとタイムアウトはありません。" - -#: ../../rst/reference_appendices/config.rst:2973 -msgid "task_timeout" -msgstr "task_timeout" - -#: ../../rst/reference_appendices/config.rst:2975 -msgid ":envvar:`ANSIBLE_TASK_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_TASK_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:2980 -msgid "TRANSFORM_INVALID_GROUP_CHARS" -msgstr "TRANSFORM_INVALID_GROUP_CHARS" - -#: ../../rst/reference_appendices/config.rst:2982 -msgid "Make ansible transform invalid characters in group names supplied by inventory sources. If 'never' it will allow for the group name but warn about the issue. When 'ignore', it does the same as 'never', without issuing a warning. When 'always' it will replace any invalid characters with '_' (underscore) and warn the user When 'silently', it does the same as 'always', without issuing a warning." -msgstr "インベントリーソースから提供されたグループ名の無効な文字を Ansible が変換します。「never」の場合、グループ名は許可されますが、問題について警告されます。「ignore」の場合は、警告を出力せずに「never」と同じように動作します。「always」の場合は、無効な文字を「_」(アンダースコア) に置き換えてユーザーに警告します。「silently」の場合は、警告を発行せずに「always」と同じように動作します。" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:2984 -msgid "never" -msgstr "never" - -#: ../../rst/reference_appendices/config.rst -msgid "silently" -msgstr "silently" - -#: ../../rst/reference_appendices/config.rst:2993 -msgid "force_valid_group_names" -msgstr "force_valid_group_names" - -#: ../../rst/reference_appendices/config.rst:2995 -msgid ":envvar:`ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS`" -msgstr ":envvar:`ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS`" - -#: ../../rst/reference_appendices/config.rst:3000 -msgid "USE_PERSISTENT_CONNECTIONS" -msgstr "USE_PERSISTENT_CONNECTIONS" - -#: ../../rst/reference_appendices/config.rst:3002 -#: ../../rst/reference_appendices/config.rst:4588 -msgid "Toggles the use of persistence for connections." -msgstr "接続に対して永続性の使用を切り替えます。" - -#: ../../rst/reference_appendices/config.rst:3007 -msgid "use_persistent_connections" -msgstr "use_persistent_connections" - -#: ../../rst/reference_appendices/config.rst:3009 -msgid ":envvar:`ANSIBLE_USE_PERSISTENT_CONNECTIONS`" -msgstr ":envvar:`ANSIBLE_USE_PERSISTENT_CONNECTIONS`" - -#: ../../rst/reference_appendices/config.rst:3014 -msgid "VARIABLE_PLUGINS_ENABLED" -msgstr "VARIABLE_PLUGINS_ENABLED" - -#: ../../rst/reference_appendices/config.rst:3016 -#: ../../rst/reference_appendices/config.rst:4596 -msgid "Whitelist for variable plugins that require it." -msgstr "必要になる vars プラグインのホワイトリストです。" - -#: ../../rst/reference_appendices/config.rst:3018 -msgid "['host_group_vars']" -msgstr "['host_group_vars']" - -#: ../../rst/reference_appendices/config.rst:3022 -msgid "vars_plugins_enabled" -msgstr "vars_plugins_enabled" - -#: ../../rst/reference_appendices/config.rst:3024 -msgid ":envvar:`ANSIBLE_VARS_ENABLED`" -msgstr ":envvar:`ANSIBLE_VARS_ENABLED`" - -#: ../../rst/reference_appendices/config.rst:3029 -msgid "VARIABLE_PRECEDENCE" -msgstr "VARIABLE_PRECEDENCE" - -#: ../../rst/reference_appendices/config.rst:3031 -#: ../../rst/reference_appendices/config.rst:4604 -msgid "Allows to change the group variable precedence merge order." -msgstr "グループ変数の優先順位のマージ順序を変更できます。" - -#: ../../rst/reference_appendices/config.rst:3033 -msgid "['all_inventory', 'groups_inventory', 'all_plugins_inventory', 'all_plugins_play', 'groups_plugins_inventory', 'groups_plugins_play']" -msgstr "['all_inventory', 'groups_inventory', 'all_plugins_inventory', 'all_plugins_play', 'groups_plugins_inventory', 'groups_plugins_play']" - -#: ../../rst/reference_appendices/config.rst:3037 -msgid "precedence" -msgstr "precedence" - -#: ../../rst/reference_appendices/config.rst:3039 -msgid ":envvar:`ANSIBLE_PRECEDENCE`" -msgstr ":envvar:`ANSIBLE_PRECEDENCE`" - -#: ../../rst/reference_appendices/config.rst:3044 -msgid "VERBOSE_TO_STDERR" -msgstr "VERBOSE_TO_STDERR" - -#: ../../rst/reference_appendices/config.rst:3046 -#: ../../rst/reference_appendices/config.rst:4644 -msgid "Force 'verbose' option to use stderr instead of stdout" -msgstr "stdout の代わりに「verbose」オプションを強制的に使用" - -#: ../../rst/reference_appendices/config.rst:3052 -msgid "verbose_to_stderr" -msgstr "verbose_to_stderr" - -#: ../../rst/reference_appendices/config.rst:3054 -msgid ":envvar:`ANSIBLE_VERBOSE_TO_STDERR`" -msgstr ":envvar:`ANSIBLE_VERBOSE_TO_STDERR`" - -#: ../../rst/reference_appendices/config.rst:3059 -msgid "WIN_ASYNC_STARTUP_TIMEOUT" -msgstr "WIN_ASYNC_STARTUP_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:3061 -msgid "For asynchronous tasks in Ansible (covered in Asynchronous Actions and Polling), this is how long, in seconds, to wait for the task spawned by Ansible to connect back to the named pipe used on Windows systems. The default is 5 seconds. This can be too low on slower systems, or systems under heavy load. This is not the total time an async command can run for, but is a separate timeout to wait for an async command to start. The task will only start to be timed against its async_timeout once it has connected to the pipe, so the overall maximum duration the task can take will be extended by the amount specified here." -msgstr "Ansible の非同期タスク (「非同期アクションおよびポーリング」で説明) の場合、これは、Ansible が生成するタスクが Windows システムで使用される名前付きパイプに接続するのを待機する時間 (秒単位) です。デフォルトは 5 秒です。これは、低速のシステムや高負荷のシステムでは低すぎる可能性があります。これは、非同期コマンドを実行できる合計時間ではありませんが、非同期コマンドの開始を待機する別のタイムアウトです。タスクは、パイプに接続された後にのみ async_timeout に対してタイムアウトが開始するため、タスクの全体的な最大期間は、ここで指定された分だけ延長されます。" - -#: ../../rst/reference_appendices/config.rst:3067 -msgid "win_async_startup_timeout" -msgstr "win_async_startup_timeout" - -#: ../../rst/reference_appendices/config.rst:3069 -msgid ":envvar:`ANSIBLE_WIN_ASYNC_STARTUP_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_WIN_ASYNC_STARTUP_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:3071 -msgid "`ansible_win_async_startup_timeout`" -msgstr "`ansible_win_async_startup_timeout`" - -#: ../../rst/reference_appendices/config.rst:3076 -msgid "WORKER_SHUTDOWN_POLL_COUNT" -msgstr "WORKER_SHUTDOWN_POLL_COUNT" - -#: ../../rst/reference_appendices/config.rst:3078 -msgid "The maximum number of times to check Task Queue Manager worker processes to verify they have exited cleanly. After this limit is reached any worker processes still running will be terminated. This is for internal use only." -msgstr "Task Queue Manager ワーカープロセスをチェックして、それらが正常に終了したことを確認する最大回数。この制限に達すると、まだ実行中のワーカープロセスはすべて終了します。これは内部使用のみです。" - -#: ../../rst/reference_appendices/config.rst:3083 -msgid ":envvar:`ANSIBLE_WORKER_SHUTDOWN_POLL_COUNT`" -msgstr ":envvar:`ANSIBLE_WORKER_SHUTDOWN_POLL_COUNT`" - -#: ../../rst/reference_appendices/config.rst:3088 -msgid "WORKER_SHUTDOWN_POLL_DELAY" -msgstr "WORKER_SHUTDOWN_POLL_DELAY" - -#: ../../rst/reference_appendices/config.rst:3090 -msgid "The number of seconds to sleep between polling loops when checking Task Queue Manager worker processes to verify they have exited cleanly. This is for internal use only." -msgstr "Task Queue Manager ワーカープロセスをチェックして、それらが正常に終了したことを確認するときに、ポーリングループ間でスリープする秒数。これは内部使用のみです。" - -#: ../../rst/reference_appendices/config.rst:3092 -msgid "0.1" -msgstr "0.1" - -#: ../../rst/reference_appendices/config.rst:3095 -msgid ":envvar:`ANSIBLE_WORKER_SHUTDOWN_POLL_DELAY`" -msgstr ":envvar:`ANSIBLE_WORKER_SHUTDOWN_POLL_DELAY`" - -#: ../../rst/reference_appendices/config.rst:3100 -msgid "YAML_FILENAME_EXTENSIONS" -msgstr "YAML_FILENAME_EXTENSIONS" - -#: ../../rst/reference_appendices/config.rst:3102 -msgid "Check all of these extensions when looking for 'variable' files which should be YAML or JSON or vaulted versions of these. This affects vars_files, include_vars, inventory and vars plugins among others." -msgstr "YAML または JSON、あるいはこれらの Vault バージョンである必要がある「変数」ファイルを探すときは、これらすべての拡張子を確認してください。これは、vars_files、include_vars、inventory、vars プラグインなどに影響します。" - -#: ../../rst/reference_appendices/config.rst:3104 -msgid "['.yml', '.yaml', '.json']" -msgstr "['.yml', '.yaml', '.json']" - -#: ../../rst/reference_appendices/config.rst:3107 -msgid "yaml_valid_extensions" -msgstr "yaml_valid_extensions" - -#: ../../rst/reference_appendices/config.rst:3109 -msgid ":envvar:`ANSIBLE_YAML_FILENAME_EXT`" -msgstr ":envvar:`ANSIBLE_YAML_FILENAME_EXT`" - -#: ../../rst/reference_appendices/config.rst:3113 -msgid "Environment Variables" -msgstr "環境変数" - -#: ../../rst/reference_appendices/config.rst:3118 -msgid "Override the default ansible config file" -msgstr "デフォルトの ansible config ファイルを上書きします" - -#: ../../rst/reference_appendices/config.rst:3124 -msgid "Specify where to look for the ansible-connection script. This location will be checked before searching $PATH.If null, ansible will start with the same directory as the ansible script." -msgstr "ansible-connection スクリプトを探す場所を指定します。この場所は、$PATH の検索前にチェックされます。null に設定すると、Ansible は ansible スクリプトと同じディレクトリーで起動します。" - -#: ../../rst/reference_appendices/config.rst:3126 -msgid "See also :ref:`ANSIBLE_CONNECTION_PATH `" -msgstr "「:ref:`ANSIBLE_CONNECTION_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3134 -msgid "See also :ref:`ANSIBLE_COW_SELECTION `" -msgstr "「:ref:`ANSIBLE_COW_SELECTION `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3142 -#: ../../rst/reference_appendices/config.rst:3152 -msgid "See also :ref:`ANSIBLE_COW_ACCEPTLIST `" -msgstr "「:ref:`ANSIBLE_COW_ACCEPTLIST `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3161 -msgid "See also :ref:`ANSIBLE_FORCE_COLOR `" -msgstr "「:ref:`ANSIBLE_FORCE_COLOR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3169 -#: ../../rst/reference_appendices/config.rst:3176 -msgid "See also :ref:`ANSIBLE_NOCOLOR `" -msgstr "「:ref:`ANSIBLE_NOCOLOR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3185 -msgid "See also :ref:`ANSIBLE_NOCOWS `" -msgstr "「:ref:`ANSIBLE_NOCOWS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3193 -msgid "See also :ref:`ANSIBLE_COW_PATH `" -msgstr "「:ref:`ANSIBLE_COW_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3199 -msgid "Pipelining, if supported by the connection plugin, reduces the number of network operations required to execute a module on the remote server, by executing many Ansible modules without actual file transfer.This can result in a very significant performance improvement when enabled.However this conflicts with privilege escalation (become). For example, when using 'sudo:' operations you must first disable 'requiretty' in /etc/sudoers on all managed hosts, which is why it is disabled by default.This option is disabled if ``ANSIBLE_KEEP_REMOTE_FILES`` is enabled.This is a global option, each connection plugin can override either by having more specific options or not supporting pipelining at all." -msgstr "パイプライン (connection プラグインでサポートされる場合) は、実際のファイル転送をせずにで多数の Ansible モジュールを実行して、リモートサーバーでモジュールを実行するために必要なネットワーク操作の数を減らします。これにより、有効にするとパフォーマンスが大幅に向上する可能性があります。ただし、これは特権昇格 (become) と競合します。たとえば、「sudo:」操作を使用する場合は、すべての管理対象ホストの /etc/sudoers で「requiretty」を無効にする必要があります。これが、デフォルトで無効になっている理由です。``ANSIBLE_KEEP_REMOTE_FILES`` が有効な場合、このオプションは無効になります。これはグローバルオプションであり、各 connection プラグインは、より具体的なオプションを指定するか、パイプをサポートしないかのいずれかによりオーバーライドすることができます。" - -#: ../../rst/reference_appendices/config.rst:3201 -msgid "See also :ref:`ANSIBLE_PIPELINING `" -msgstr "「:ref:`ANSIBLE_PIPELINING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3209 -msgid "See also :ref:`ANY_ERRORS_FATAL `" -msgstr "「:ref:`ANY_ERRORS_FATAL `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3217 -msgid "See also :ref:`BECOME_ALLOW_SAME_USER `" -msgstr "「:ref:`BECOME_ALLOW_SAME_USER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3225 -msgid "See also :ref:`AGNOSTIC_BECOME_PROMPT `" -msgstr "「:ref:`AGNOSTIC_BECOME_PROMPT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3233 -msgid "See also :ref:`CACHE_PLUGIN `" -msgstr "「:ref:`CACHE_PLUGIN `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3241 -msgid "See also :ref:`CACHE_PLUGIN_CONNECTION `" -msgstr "「:ref:`CACHE_PLUGIN_CONNECTION `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3249 -msgid "See also :ref:`CACHE_PLUGIN_PREFIX `" -msgstr "「:ref:`CACHE_PLUGIN_PREFIX `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3257 -msgid "See also :ref:`CACHE_PLUGIN_TIMEOUT `" -msgstr "「:ref:`CACHE_PLUGIN_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3264 -msgid "See also :ref:`COLLECTIONS_SCAN_SYS_PATH `" -msgstr "「:ref:`COLLECTIONS_SCAN_SYS_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3273 -#: ../../rst/reference_appendices/config.rst:3281 -msgid "See also :ref:`COLLECTIONS_PATHS `" -msgstr "「:ref:`COLLECTIONS_PATHS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3290 -msgid "See also :ref:`COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH `" -msgstr "「:ref:`COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3298 -msgid "See also :ref:`COLOR_CHANGED `" -msgstr "「:ref:`COLOR_CHANGED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3306 -msgid "See also :ref:`COLOR_CONSOLE_PROMPT `" -msgstr "「:ref:`COLOR_CONSOLE_PROMPT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3314 -msgid "See also :ref:`COLOR_DEBUG `" -msgstr "「:ref:`COLOR_DEBUG `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3322 -msgid "See also :ref:`COLOR_DEPRECATE `" -msgstr "「:ref:`COLOR_DEPRECATE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3330 -msgid "See also :ref:`COLOR_DIFF_ADD `" -msgstr "「:ref:`COLOR_DIFF_ADD `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3338 -msgid "See also :ref:`COLOR_DIFF_LINES `" -msgstr "「:ref:`COLOR_DIFF_LINES `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3346 -msgid "See also :ref:`COLOR_DIFF_REMOVE `" -msgstr "「:ref:`COLOR_DIFF_REMOVE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3354 -msgid "See also :ref:`COLOR_ERROR `" -msgstr "「:ref:`COLOR_ERROR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3362 -msgid "See also :ref:`COLOR_HIGHLIGHT `" -msgstr "「:ref:`COLOR_HIGHLIGHT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3370 -msgid "See also :ref:`COLOR_OK `" -msgstr "「:ref:`COLOR_OK `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3378 -msgid "See also :ref:`COLOR_SKIP `" -msgstr "「:ref:`COLOR_SKIP `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3386 -msgid "See also :ref:`COLOR_UNREACHABLE `" -msgstr "「:ref:`COLOR_UNREACHABLE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3394 -msgid "See also :ref:`COLOR_VERBOSE `" -msgstr "「:ref:`COLOR_VERBOSE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3402 -msgid "See also :ref:`COLOR_WARN `" -msgstr "「:ref:`COLOR_WARN `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3408 -msgid "With this setting on (True), running conditional evaluation 'var' is treated differently than 'var.subkey' as the first is evaluated directly while the second goes through the Jinja2 parser. But 'false' strings in 'var' get evaluated as booleans.With this setting off they both evaluate the same but in cases in which 'var' was 'false' (a string) it won't get evaluated as a boolean anymore.Currently this setting defaults to 'True' but will soon change to 'False' and the setting itself will be removed in the future.Expect that this setting eventually will be deprecated after 2.12" -msgstr "この設定を (True) にすると、条件付き評価「var」の実行は「var.subkey」とは異なる方法で処理されます。最初の評価は直接評価され、2 番目の評価は Jinja2 パーサーを通過するためです。ただし、「var」の「false」文字列はブール値として評価されます。この設定をオフにすると、どちらも同じように評価されますが、「var」が「false」(文字列) の場合は、ブール値として評価されなくなります。現在、この設定のデフォルトは「True」ですが、まもなく「False」に変更され、将来のバージョンで設定自体が削除されます。この設定は、2.12 以降で最終的に非推奨になると予想されます。" - -#: ../../rst/reference_appendices/config.rst:3410 -msgid "See also :ref:`CONDITIONAL_BARE_VARS `" -msgstr "「:ref:`CONDITIONAL_BARE_VARS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3416 -msgid "Sets the output directory on the remote host to generate coverage reports to.Currently only used for remote coverage on PowerShell modules.This is for internal use only." -msgstr "リモートホストの出力ディレクトリーを設定してカバレッジレポートを生成します。現在 PowerShell モジュールのリモートカバレッジにのみ使用されます。これは内部使用のみを目的としています。" - -#: ../../rst/reference_appendices/config.rst:3418 -msgid "See also :ref:`COVERAGE_REMOTE_OUTPUT `" -msgstr "「:ref:`COVERAGE_REMOTE_OUTPUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3424 -msgid "A list of paths for files on the Ansible controller to run coverage for when executing on the remote host.Only files that match the path glob will have its coverage collected.Multiple path globs can be specified and are separated by ``:``.Currently only used for remote coverage on PowerShell modules.This is for internal use only." -msgstr "リモートホストで実行するときにカバレッジを実行する Ansible コントローラー上のファイルのパスのリスト。パスグロブに一致するファイルのみがカバレッジを収集します。パスグロブは、``:`` で区切ることで複数指定できます。現在 PowerShell モジュールのリモートカバレッジにのみ使用されます。これは内部使用のみを目的としています。" - -#: ../../rst/reference_appendices/config.rst:3426 -msgid "See also :ref:`COVERAGE_REMOTE_PATHS `" -msgstr "「:ref:`COVERAGE_REMOTE_PATHS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3432 -msgid "By default Ansible will issue a warning when received from a task action (module or action plugin)These warnings can be silenced by adjusting this setting to False." -msgstr "デフォルトでは、Ansible はタスクアクション (モジュールまたは action プラグイン) から受け取ると、警告を False に調整することで警告を非表示にすることができます。" - -#: ../../rst/reference_appendices/config.rst:3434 -msgid "See also :ref:`ACTION_WARNINGS `" -msgstr "「:ref:`ACTION_WARNINGS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3440 -msgid "Ansible can issue a warning when the shell or command module is used and the command appears to be similar to an existing Ansible module.These warnings can be silenced by adjusting this setting to False. You can also control this at the task level with the module option ``warn``.As of version 2.11, this is disabled by default." -msgstr "Ansible は、シェルまたはコマンドモジュールが使用され、コマンドが既存の Ansible モジュールと類似しているように見えます。これらの設定を False に設定することで、これらの警告を非表示にすることができます。また、モジュールのオプション ``warn`` を使用してタスクレベルで制御することもできます。バージョン 2.11 の時点で、これはデフォルトでは無効になっています。" - -#: ../../rst/reference_appendices/config.rst:3442 -msgid "See also :ref:`COMMAND_WARNINGS `" -msgstr "「:ref:`COMMAND_WARNINGS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3448 -msgid "By default Ansible will issue a warning when there are no hosts in the inventory.These warnings can be silenced by adjusting this setting to False." -msgstr "デフォルトでは、Ansible は、インベントリーにホストがない場合に警告を表示します。この警告は、この設定を False に設定すると非表示にすることができます。" - -#: ../../rst/reference_appendices/config.rst:3450 -msgid "See also :ref:`LOCALHOST_WARNING `" -msgstr "「:ref:`LOCALHOST_WARNING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3458 -msgid "See also :ref:`DOC_FRAGMENT_PLUGIN_PATH `" -msgstr "「:ref:`DOC_FRAGMENT_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3466 -msgid "See also :ref:`DEFAULT_ACTION_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_ACTION_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3475 -msgid "See also :ref:`DEFAULT_ASK_PASS `" -msgstr "「:ref:`DEFAULT_ASK_PASS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3483 -msgid "See also :ref:`DEFAULT_ASK_VAULT_PASS `" -msgstr "「:ref:`DEFAULT_ASK_VAULT_PASS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3491 -msgid "See also :ref:`DEFAULT_BECOME `" -msgstr "「:ref:`DEFAULT_BECOME `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3499 -msgid "See also :ref:`DEFAULT_BECOME_ASK_PASS `" -msgstr "「:ref:`DEFAULT_BECOME_ASK_PASS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3507 -msgid "See also :ref:`DEFAULT_BECOME_METHOD `" -msgstr "「:ref:`DEFAULT_BECOME_METHOD `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3515 -msgid "See also :ref:`DEFAULT_BECOME_EXE `" -msgstr "「:ref:`DEFAULT_BECOME_EXE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3523 -msgid "See also :ref:`DEFAULT_BECOME_FLAGS `" -msgstr "「:ref:`DEFAULT_BECOME_FLAGS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3531 -msgid "See also :ref:`BECOME_PLUGIN_PATH `" -msgstr "「:ref:`BECOME_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3539 -msgid "See also :ref:`DEFAULT_BECOME_USER `" -msgstr "「:ref:`DEFAULT_BECOME_USER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3547 -msgid "See also :ref:`DEFAULT_CACHE_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_CACHE_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3555 -#: ../../rst/reference_appendices/config.rst:3565 -msgid "See also :ref:`CALLABLE_ACCEPT_LIST `" -msgstr "「:ref:`CALLABLE_ACCEPT_LIST `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3574 -msgid "See also :ref:`CONTROLLER_PYTHON_WARNING `" -msgstr "「:ref:`CONTROLLER_PYTHON_WARNING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3582 -msgid "See also :ref:`DEFAULT_CALLBACK_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_CALLBACK_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3590 -#: ../../rst/reference_appendices/config.rst:3600 -msgid "See also :ref:`CALLBACKS_ENABLED `" -msgstr "「:ref:`CALLBACKS_ENABLED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3609 -msgid "See also :ref:`DEFAULT_CLICONF_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_CLICONF_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3617 -msgid "See also :ref:`DEFAULT_CONNECTION_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_CONNECTION_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3625 -msgid "See also :ref:`DEFAULT_DEBUG `" -msgstr "「:ref:`DEFAULT_DEBUG `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3633 -msgid "See also :ref:`DEFAULT_EXECUTABLE `" -msgstr "「:ref:`DEFAULT_EXECUTABLE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3639 -msgid "This option allows you to globally configure a custom path for 'local_facts' for the implied M(ansible.builtin.setup) task when using fact gathering.If not set, it will fallback to the default from the M(ansible.builtin.setup) module: ``/etc/ansible/facts.d``.This does **not** affect user defined tasks that use the M(ansible.builtin.setup) module." -msgstr "このオプションを使用すると、ファクト収集を使用するときに、暗黙の M(ansible.builtin.setup) タスクの「local_facts」のカスタムパスをグローバルに設定できます。設定されていない場合は、M(ansible.builtin.setup) モジュールからデフォルトにフォールバックします (``/etc/ansible/facts.d``)。これは、M(ansible.builtin.setup) モジュールを使用するユーザー定義のタスクには **影響しません**。" - -#: ../../rst/reference_appendices/config.rst:3641 -msgid "See also :ref:`DEFAULT_FACT_PATH `" -msgstr "「:ref:`DEFAULT_FACT_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3649 -msgid "See also :ref:`DEFAULT_FILTER_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_FILTER_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3655 -msgid "This option controls if notified handlers run on a host even if a failure occurs on that host.When false, the handlers will not run if a failure has occurred on a host.This can also be set per play or on the command line. See Handlers and Failure for more details." -msgstr "このオプションは、ホストで障害が発生した場合でも、通知されたハンドラーがホストで実行されるかどうかを制御します。false にすると、ホストで障害が発生した場合に、ハンドラーは実行されません。これは、プレイごとまたはコマンドラインで設定することもできます。詳細については、「ハンドラーおよび失敗」を参照してください。" - -#: ../../rst/reference_appendices/config.rst:3657 -msgid "See also :ref:`DEFAULT_FORCE_HANDLERS `" -msgstr "「:ref:`DEFAULT_FORCE_HANDLERS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3665 -msgid "See also :ref:`DEFAULT_FORKS `" -msgstr "「:ref:`DEFAULT_FORKS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3671 -msgid "This setting controls the default policy of fact gathering (facts discovered about remote systems).When 'implicit' (the default), the cache plugin will be ignored and facts will be gathered per play unless 'gather_facts: False' is set.When 'explicit' the inverse is true, facts will not be gathered unless directly requested in the play.The 'smart' value means each new host that has no facts discovered will be scanned, but if the same host is addressed in multiple plays it will not be contacted again in the playbook run.This option can be useful for those wishing to save fact gathering time. Both 'smart' and 'explicit' will use the cache plugin." -msgstr "この設定は、ファクト収集 (リモートシステムに関して検出されたファクト) のデフォルトポリシーを制御します。「implicit」(デフォルト) の場合、cache プラグインは無視され、「gather_facts: False」が設定されていない限り、プレイごとにファクトが収集されます。「explicit」の場合はその逆で、プレイ中に直接要求されない限り、ファクトは収集されません。「smart」の値は、検出されたファクトを持たない各新規ホストがスキャンされることを意味しますが、同じホストが複数のプレイで扱われた場合は、Playbook の実行中に再び接触することはありません。このオプションは、ファクト収集の時間を短縮したい場合に便利です。「smart」と「explicit」の両方とも、cache プラグインを使用します。" - -#: ../../rst/reference_appendices/config.rst:3673 -msgid "See also :ref:`DEFAULT_GATHERING `" -msgstr "「:ref:`DEFAULT_GATHERING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3679 -msgid "Set the `gather_subset` option for the M(ansible.builtin.setup) task in the implicit fact gathering. See the module documentation for specifics.It does **not** apply to user defined M(ansible.builtin.setup) tasks." -msgstr "暗黙的なファクト収集の M(ansible.builtin.setup) タスクに `gather_subset` オプションを設定します。詳細は、モジュールドキュメントを参照してください。ユーザー定義の M(ansible.builtin.setup) タスクには **適用されません**。" - -#: ../../rst/reference_appendices/config.rst:3681 -msgid "See also :ref:`DEFAULT_GATHER_SUBSET `" -msgstr "「:ref:`DEFAULT_GATHER_SUBSET `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3687 -msgid "Set the timeout in seconds for the implicit fact gathering.It does **not** apply to user defined M(ansible.builtin.setup) tasks." -msgstr "暗黙的なファクト収集のタイムアウトを秒単位で設定します。ユーザー定義の M(ansible.builtin.setup) タスクには **適用されません**。" - -#: ../../rst/reference_appendices/config.rst:3689 -msgid "See also :ref:`DEFAULT_GATHER_TIMEOUT `" -msgstr "「:ref:`DEFAULT_GATHER_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3697 -msgid "See also :ref:`DEFAULT_HANDLER_INCLUDES_STATIC `" -msgstr "「:ref:`DEFAULT_HANDLER_INCLUDES_STATIC `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3703 -msgid "This setting controls how duplicate definitions of dictionary variables (aka hash, map, associative array) are handled in Ansible.This does not affect variables whose values are scalars (integers, strings) or arrays.**WARNING**, changing this setting is not recommended as this is fragile and makes your content (plays, roles, collections) non portable, leading to continual confusion and misuse. Don't change this setting unless you think you have an absolute need for it.We recommend avoiding reusing variable names and relying on the ``combine`` filter and ``vars`` and ``varnames`` lookups to create merged versions of the individual variables. In our experience this is rarely really needed and a sign that too much complexity has been introduced into the data structures and plays.For some uses you can also look into custom vars_plugins to merge on input, even substituting the default ``host_group_vars`` that is in charge of parsing the ``host_vars/`` and ``group_vars/`` directories. Most users of this setting are only interested in inventory scope, but the setting itself affects all sources and makes debugging even harder.All playbooks and roles in the official examples repos assume the default for this setting.Changing the setting to ``merge`` applies across variable sources, but many sources will internally still overwrite the variables. For example ``include_vars`` will dedupe variables internally before updating Ansible, with 'last defined' overwriting previous definitions in same file.The Ansible project recommends you **avoid ``merge`` for new projects.**It is the intention of the Ansible developers to eventually deprecate and remove this setting, but it is being kept as some users do heavily rely on it. New projects should **avoid 'merge'**." -msgstr "この設定は、ディクショナリー変数 (別名ハッシュ、マップ、連想配列) の重複した定義を Ansible でどのように扱うかを制御します。この設定は、値がスカラー (整数、文字列) や配列である変数には影響しません。**警告** これは脆弱で、コンテンツ (プレイ、ロール、コレクション) が移植できなくなり、継続的な混乱と誤用を招く恐れがあるため、この設定を変更することは推奨されません。絶対に必要だと思われる場合を除き、この設定を変更しないでください。変数名の再利用は避け、``combine`` フィルターと``vars`` ルックアップおよび``varnames`` ルックアップを利用して、個々の変数のマージバージョンを作成することが推奨されます。経験上、このようなことが本当に必要とされることはほとんどなく、データ構造やプレイが複雑になりすぎていることを示しています。用途によっては、入力時にマージするカスタム vars_plugins を検討することもできますし、``host_vars/`` ディレクトリーおよび ``group_vars/`` ディレクトリーの解析を担当するデフォルトの ``host_group_vars`` を置き換えることもできます。この設定を使用するほとんどのユーザーはインベントリスコープにしか興味がありませんが、この設定自体がすべてのソースに影響し、デバッグをさらに困難にします。公式のサンプルリポジトリーにある Playbook およびロールはすべて、この設定のデフォルトを想定しています。``merge`` に設定を変更すると、変数ソース全体に適用されますが、多くのソースでは内部的に変数が上書きされたままになります。たとえば、``include_vars`` は、Ansible を更新する前に内部で変数の重複を排除し、「最終定義」が同じファイルの以前の定義を上書きします。Ansible プロジェクトでは、**新規プロジェクトでは ``merge`` を回避する** ことが推奨されます。Ansible 開発者は、最終的にこの設定を非推奨にして削除することを意図していますが、一部のユーザーがこの設定に大きく依存しているため、この設定を残しています。新しいプロジェクトでは、**「merge」を回避** してください。" - -#: ../../rst/reference_appendices/config.rst:3705 -msgid "See also :ref:`DEFAULT_HASH_BEHAVIOUR `" -msgstr "「:ref:`DEFAULT_HASH_BEHAVIOUR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3713 -msgid "See also :ref:`DEFAULT_HOST_LIST `" -msgstr "「:ref:`DEFAULT_HOST_LIST `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3721 -msgid "See also :ref:`DEFAULT_HTTPAPI_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_HTTPAPI_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3730 -msgid "See also :ref:`DEFAULT_INVENTORY_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_INVENTORY_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3736 -msgid "This is a developer-specific feature that allows enabling additional Jinja2 extensions.See the Jinja2 documentation for details. If you do not know what these do, you probably don't need to change this setting :)" -msgstr "これは、追加の Jinja2 拡張機能を有効にすることができる開発者固有の機能です。詳細については、Jinja2 ドキュメントを参照してください。この拡張機能が何をするのかわからない場合は、おそらくこの設定を変更する必要はありません。" - -#: ../../rst/reference_appendices/config.rst:3738 -msgid "See also :ref:`DEFAULT_JINJA2_EXTENSIONS `" -msgstr "「:ref:`DEFAULT_JINJA2_EXTENSIONS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3746 -msgid "See also :ref:`DEFAULT_JINJA2_NATIVE `" -msgstr "「:ref:`DEFAULT_JINJA2_NATIVE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3752 -msgid "Enables/disables the cleaning up of the temporary files Ansible used to execute the tasks on the remote.If this option is enabled it will disable ``ANSIBLE_PIPELINING``." -msgstr "リモートでタスクを実行するために Ansible が使用する一時ファイルのクリーンアップを有効または無効にします。このオプションを有効にすると、``ANSIBLE_PIPELINING`` を無効にします。" - -#: ../../rst/reference_appendices/config.rst:3754 -msgid "See also :ref:`DEFAULT_KEEP_REMOTE_FILES `" -msgstr "「:ref:`DEFAULT_KEEP_REMOTE_FILES `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3762 -#: ../../rst/reference_appendices/config.rst:3772 -msgid "See also :ref:`DEFAULT_LIBVIRT_LXC_NOSECLABEL `" -msgstr "「:ref:`DEFAULT_LIBVIRT_LXC_NOSECLABEL `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3780 -msgid "See also :ref:`DEFAULT_LOAD_CALLBACK_PLUGINS `" -msgstr "「:ref:`DEFAULT_LOAD_CALLBACK_PLUGINS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3788 -msgid "See also :ref:`DEFAULT_LOCAL_TMP `" -msgstr "「:ref:`DEFAULT_LOCAL_TMP `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3796 -msgid "See also :ref:`DEFAULT_LOG_PATH `" -msgstr "「:ref:`DEFAULT_LOG_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3804 -msgid "See also :ref:`DEFAULT_LOG_FILTER `" -msgstr "「:ref:`DEFAULT_LOG_FILTER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3812 -msgid "See also :ref:`DEFAULT_LOOKUP_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_LOOKUP_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3821 -msgid "See also :ref:`DEFAULT_MODULE_ARGS `" -msgstr "「:ref:`DEFAULT_MODULE_ARGS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3831 -msgid "See also :ref:`DEFAULT_MODULE_PATH `" -msgstr "「:ref:`DEFAULT_MODULE_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3839 -msgid "See also :ref:`DEFAULT_MODULE_UTILS_PATH `" -msgstr "「:ref:`DEFAULT_MODULE_UTILS_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3847 -msgid "See also :ref:`DEFAULT_NETCONF_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_NETCONF_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3855 -msgid "See also :ref:`DEFAULT_NO_LOG `" -msgstr "「:ref:`DEFAULT_NO_LOG `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3863 -msgid "See also :ref:`DEFAULT_NO_TARGET_SYSLOG `" -msgstr "「:ref:`DEFAULT_NO_TARGET_SYSLOG `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3871 -msgid "See also :ref:`DEFAULT_NULL_REPRESENTATION `" -msgstr "「:ref:`DEFAULT_NULL_REPRESENTATION `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3879 -msgid "See also :ref:`DEFAULT_POLL_INTERVAL `" -msgstr "「:ref:`DEFAULT_POLL_INTERVAL `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3887 -msgid "See also :ref:`DEFAULT_PRIVATE_KEY_FILE `" -msgstr "「:ref:`DEFAULT_PRIVATE_KEY_FILE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3893 -msgid "Makes role variables inaccessible from other roles.This was introduced as a way to reset role variables to default values if a role is used more than once in a playbook." -msgstr "ロール変数が他のロールからアクセスできないようにします。これは、Playbook でロールが複数回使用されている場合に、ロール変数をデフォルト値にリセットする方法として導入されました。" - -#: ../../rst/reference_appendices/config.rst:3895 -msgid "See also :ref:`DEFAULT_PRIVATE_ROLE_VARS `" -msgstr "「:ref:`DEFAULT_PRIVATE_ROLE_VARS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3903 -msgid "See also :ref:`DEFAULT_REMOTE_PORT `" -msgstr "「:ref:`DEFAULT_REMOTE_PORT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3909 -msgid "Sets the login user for the target machinesWhen blank it uses the connection plugin's default, normally the user currently executing Ansible." -msgstr "ターゲットマシンのログインユーザーを設定します。空の場合は、connection プラグインのデフォルト (通常は現在 Ansible を実行しているユーザー) を使用します。" - -#: ../../rst/reference_appendices/config.rst:3911 -msgid "See also :ref:`DEFAULT_REMOTE_USER `" -msgstr "「:ref:`DEFAULT_REMOTE_USER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3919 -msgid "See also :ref:`DEFAULT_ROLES_PATH `" -msgstr "「:ref:`DEFAULT_ROLES_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3925 -msgid "Some filesystems do not support safe operations and/or return inconsistent errors, this setting makes Ansible 'tolerate' those in the list w/o causing fatal errors.Data corruption may occur and writes are not always verified when a filesystem is in the list." -msgstr "一部のファイルシステムは安全な操作をサポートしていないか、一貫性のないエラーを返します。この設定により、Ansible はリスト内のエラーを「許容」し、致命的なエラーを引き起こしません。ファイルシステムがリストに含まれていると、データが破損する可能性があり、書き込みが常に検証されるとは限りません。" - -#: ../../rst/reference_appendices/config.rst:3927 -msgid "See also :ref:`DEFAULT_SELINUX_SPECIAL_FS `" -msgstr "「:ref:`DEFAULT_SELINUX_SPECIAL_FS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3934 -msgid "Set the main callback used to display Ansible output, you can only have one at a time.You can have many other callbacks, but just one can be in charge of stdout." -msgstr "Ansible 出力の表示に使用されるメインコールバックを設定します。一度に 1 つしか使用できません。他にも多くのコールバックを設定できますが、標準出力 (stdout) に使用できるのは 1 つだけです。" - -#: ../../rst/reference_appendices/config.rst:3936 -msgid "See also :ref:`DEFAULT_STDOUT_CALLBACK `" -msgstr "「:ref:`DEFAULT_STDOUT_CALLBACK `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3942 -msgid "Whether or not to enable the task debugger, this previously was done as a strategy plugin.Now all strategy plugins can inherit this behavior. The debugger defaults to activating whena task is failed on unreachable. Use the debugger keyword for more flexibility." -msgstr "タスクデバッガーを有効にするかどうかにかかわらず、これは以前は戦略プラグインとして実行されていました。これで、すべての strategy プラグインがこの動作を継承できるようになりました。デバッガーは、タスクが到達不能で失敗したときにデフォルトでアクティブになります。柔軟性を高めるには、debugger キーワードを使用します。" - -#: ../../rst/reference_appendices/config.rst:3944 -msgid "See also :ref:`ENABLE_TASK_DEBUGGER `" -msgstr "「:ref:`ENABLE_TASK_DEBUGGER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3950 -msgid "This option defines whether the task debugger will be invoked on a failed task when ignore_errors=True is specified.True specifies that the debugger will honor ignore_errors, False will not honor ignore_errors." -msgstr "このオプションは、ignore_errors=True が指定されている場合に、失敗したタスクでタスクデバッガーが呼び出されるかどうかを定義します。True に設定すると、デバッガーが ignore_errors を許可するように指定し、False に設定すると ignore_errors が無効になります。" - -#: ../../rst/reference_appendices/config.rst:3952 -msgid "See also :ref:`TASK_DEBUGGER_IGNORE_ERRORS `" -msgstr "「:ref:`TASK_DEBUGGER_IGNORE_ERRORS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3960 -msgid "See also :ref:`DEFAULT_STRATEGY `" -msgstr "「:ref:`DEFAULT_STRATEGY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3968 -msgid "See also :ref:`DEFAULT_STRATEGY_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_STRATEGY_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3976 -msgid "See also :ref:`DEFAULT_SU `" -msgstr "「:ref:`DEFAULT_SU `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3984 -msgid "See also :ref:`DEFAULT_SYSLOG_FACILITY `" -msgstr "「:ref:`DEFAULT_SYSLOG_FACILITY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3992 -msgid "See also :ref:`DEFAULT_TASK_INCLUDES_STATIC `" -msgstr "「:ref:`DEFAULT_TASK_INCLUDES_STATIC `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4000 -msgid "See also :ref:`DEFAULT_TERMINAL_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_TERMINAL_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4008 -msgid "See also :ref:`DEFAULT_TEST_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_TEST_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4016 -msgid "See also :ref:`DEFAULT_TIMEOUT `" -msgstr "「:ref:`DEFAULT_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4024 -msgid "See also :ref:`DEFAULT_TRANSPORT `" -msgstr "「:ref:`DEFAULT_TRANSPORT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4030 -msgid "When True, this causes ansible templating to fail steps that reference variable names that are likely typoed.Otherwise, any '{{ template_expression }}' that contains undefined variables will be rendered in a template or ansible action line exactly as written." -msgstr "True にすると、これにより、タイプミスの可能性が高い変数名を参照するステップが失敗するテンプレートが作成されます。それ以外の場合は、未定義の変数を含む '{{ template_expression }}' は、記述されたとおりにテンプレートまたは Ansible のアクション行にレンダリングされます。" - -#: ../../rst/reference_appendices/config.rst:4032 -msgid "See also :ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR `" -msgstr "「:ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4040 -msgid "See also :ref:`DEFAULT_VARS_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_VARS_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4048 -msgid "See also :ref:`DEFAULT_VAULT_ID_MATCH `" -msgstr "「:ref:`DEFAULT_VAULT_ID_MATCH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4056 -msgid "See also :ref:`DEFAULT_VAULT_IDENTITY `" -msgstr "「:ref:`DEFAULT_VAULT_IDENTITY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4064 -msgid "See also :ref:`DEFAULT_VAULT_ENCRYPT_IDENTITY `" -msgstr "「:ref:`DEFAULT_VAULT_ENCRYPT_IDENTITY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4072 -msgid "See also :ref:`DEFAULT_VAULT_IDENTITY_LIST `" -msgstr "「:ref:`DEFAULT_VAULT_IDENTITY_LIST `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4080 -msgid "See also :ref:`DEFAULT_VAULT_PASSWORD_FILE `" -msgstr "「:ref:`DEFAULT_VAULT_PASSWORD_FILE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4088 -msgid "See also :ref:`DEFAULT_VERBOSITY `" -msgstr "「:ref:`DEFAULT_VERBOSITY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4096 -msgid "See also :ref:`DEPRECATION_WARNINGS `" -msgstr "「:ref:`DEPRECATION_WARNINGS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4104 -msgid "See also :ref:`DEVEL_WARNING `" -msgstr "「:ref:`DEVEL_WARNING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4112 -msgid "See also :ref:`DIFF_ALWAYS `" -msgstr "「:ref:`DIFF_ALWAYS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4120 -msgid "See also :ref:`DIFF_CONTEXT `" -msgstr "「:ref:`DIFF_CONTEXT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4126 -msgid "Normally ``ansible-playbook`` will print a header for each task that is run. These headers will contain the name: field from the task if you specified one. If you didn't then ``ansible-playbook`` uses the task's action to help you tell which task is presently running. Sometimes you run many of the same action and so you want more information about the task to differentiate it from others of the same action. If you set this variable to True in the config then ``ansible-playbook`` will also include the task's arguments in the header.This setting defaults to False because there is a chance that you have sensitive values in your parameters and you do not want those to be printed.If you set this to True you should be sure that you have secured your environment's stdout (no one can shoulder surf your screen and you aren't saving stdout to an insecure file) or made sure that all of your playbooks explicitly added the ``no_log: True`` parameter to tasks which have sensitive values See How do I keep secret data in my playbook? for more information." -msgstr "通常、``ansible-playbook`` は、実行された各タスクのヘッダーが出力されます。これらのヘッダーにはタスクの name: フィールドが指定されていればそれが含まれます。指定していない場合は、``ansible-playbook`` がタスクのアクションを使用して、どのタスクが現在実行されているかを知ることができます。多くの同じアクションを実行する場合は、同じアクションの他のタスクと区別するために、タスクに関する詳細情報が必要になることがあります。設定でこの変数を True に設定すると、``ansible-playbook`` では、タスクの引数もヘッダーに含まれます。パラメーターに機密性の高い値が含まれている可能性があり、それらを出力しないため、この設定のデフォルトは False です。これを True に設定した場合は、環境の標準出力 (誰もあなたの画面を肩越しに盗み見ることができず、あなたは標準出力を安全でないファイルに保存していません) を確実に保護するか、すべての Playbook で機密性の高い値を持つタスクに ``no_log: True`` パラメーターを明示的に追加する必要があります。詳細は、「Playbook に機密データを保存するにはどうすれば良いですか」を参照してください。" - -#: ../../rst/reference_appendices/config.rst:4128 -msgid "See also :ref:`DISPLAY_ARGS_TO_STDOUT `" -msgstr "「:ref:`DISPLAY_ARGS_TO_STDOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4136 -#: ../../rst/reference_appendices/config.rst:4146 -msgid "See also :ref:`DISPLAY_SKIPPED_HOSTS `" -msgstr "「:ref:`DISPLAY_SKIPPED_HOSTS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4153 -msgid "By default Ansible will issue a warning when a duplicate dict key is encountered in YAML.These warnings can be silenced by adjusting this setting to False." -msgstr "デフォルトでは、Ansible は、YAML で重複した dict キーが発生した場合に警告を発行します。この警告は、この設定を False に設定すると非表示にすることができます。" - -#: ../../rst/reference_appendices/config.rst:4155 -msgid "See also :ref:`DUPLICATE_YAML_DICT_KEY `" -msgstr "「:ref:`DUPLICATE_YAML_DICT_KEY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4163 -msgid "See also :ref:`ERROR_ON_MISSING_HANDLER `" -msgstr "「:ref:`ERROR_ON_MISSING_HANDLER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4171 -msgid "See also :ref:`CONNECTION_FACTS_MODULES `" -msgstr "「:ref:`CONNECTION_FACTS_MODULES `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4179 -msgid "See also :ref:`FACTS_MODULES `" -msgstr "「:ref:`FACTS_MODULES `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4187 -msgid "See also :ref:`GALAXY_IGNORE_CERTS `" -msgstr "「:ref:`GALAXY_IGNORE_CERTS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4195 -msgid "See also :ref:`GALAXY_ROLE_SKELETON `" -msgstr "「:ref:`GALAXY_ROLE_SKELETON `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4203 -msgid "See also :ref:`GALAXY_ROLE_SKELETON_IGNORE `" -msgstr "「:ref:`GALAXY_ROLE_SKELETON_IGNORE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4211 -msgid "See also :ref:`GALAXY_SERVER `" -msgstr "「:ref:`GALAXY_SERVER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4217 -msgid "A list of Galaxy servers to use when installing a collection.The value corresponds to the config ini header ``[galaxy_server.{{item}}]`` which defines the server details.See :ref:`galaxy_server_config` for more details on how to define a Galaxy server.The order of servers in this list is used to as the order in which a collection is resolved.Setting this config option will ignore the :ref:`galaxy_server` config option." -msgstr "コレクションのインストール時に使用する Galaxy サーバーの一覧。値は、サーバーの詳細を定義する config ini ヘッダー ``[galaxy_server.{{item}}]`` に対応します。Galaxy サーバーの定義方法の詳細は、「:ref:`galaxy_server_config`」を参照してください。この一覧のサーバーの順序は、コレクションの解決順序として使用されます。この設定オプションを設定すると、:ref:`galaxy_server` の設定オプションは無視されます。" - -#: ../../rst/reference_appendices/config.rst:4219 -msgid "See also :ref:`GALAXY_SERVER_LIST `" -msgstr "「:ref:`GALAXY_SERVER_LIST `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4227 -msgid "See also :ref:`GALAXY_TOKEN_PATH `" -msgstr "「:ref:`GALAXY_TOKEN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4233 -msgid "Some steps in ``ansible-galaxy`` display a progress wheel which can cause issues on certain displays or when outputting the stdout to a file.This config option controls whether the display wheel is shown or not.The default is to show the display wheel if stdout has a tty." -msgstr "``ansible-galaxy`` の一部の手順では、特定の表示で、または標準出力 (stdout) をファイルに出力するときに問題を引き起こす可能性のある進行状況ホイールを表示します。この設定オプションは、表示ホイールを表示するかどうかを制御します。デフォルトでは、stdout に tty があると、表示ホイールが表示されます。" - -#: ../../rst/reference_appendices/config.rst:4235 -msgid "See also :ref:`GALAXY_DISPLAY_PROGRESS `" -msgstr "「:ref:`GALAXY_DISPLAY_PROGRESS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4241 -msgid "The directory that stores cached responses from a Galaxy server.This is only used by the ``ansible-galaxy collection install`` and ``download`` commands.Cache files inside this dir will be ignored if they are world writable." -msgstr "Galaxy サーバーからキャッシュされた応答を保存するディレクトリーです。これは ``ansible-galaxy collection install`` コマンドおよび ``download`` コマンドによってのみ使用されます。このディレクトリー内のキャッシュファイルは、誰でも書き込み可能であれば無視されます。" - -#: ../../rst/reference_appendices/config.rst:4243 -msgid "See also :ref:`GALAXY_CACHE_DIR `" -msgstr "「:ref:`GALAXY_CACHE_DIR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4251 -msgid "See also :ref:`HOST_KEY_CHECKING `" -msgstr "「:ref:`HOST_KEY_CHECKING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4259 -msgid "See also :ref:`HOST_PATTERN_MISMATCH `" -msgstr "「:ref:`HOST_PATTERN_MISMATCH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4267 -msgid "See also :ref:`INTERPRETER_PYTHON `" -msgstr "「:ref:`INTERPRETER_PYTHON `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4275 -msgid "Make ansible transform invalid characters in group names supplied by inventory sources.If 'never' it will allow for the group name but warn about the issue.When 'ignore', it does the same as 'never', without issuing a warning.When 'always' it will replace any invalid characters with '_' (underscore) and warn the userWhen 'silently', it does the same as 'always', without issuing a warning." -msgstr "インベントリーソースから提供されたグループ名の無効な文字を Ansible が変換します。「never」の場合、グループ名は許可されますが、問題について警告されます。「ignore」の場合は、警告を出力せずに「never」と同じように動作します。「always」の場合は、無効な文字を「_」(アンダースコア) に置き換えてユーザーに警告します。「silently」の場合は、警告を出力しませんが「always」と同じように動作します。" - -#: ../../rst/reference_appendices/config.rst:4277 -msgid "See also :ref:`TRANSFORM_INVALID_GROUP_CHARS `" -msgstr "「:ref:`TRANSFORM_INVALID_GROUP_CHARS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4285 -msgid "See also :ref:`INVALID_TASK_ATTRIBUTE_FAILED `" -msgstr "「:ref:`INVALID_TASK_ATTRIBUTE_FAILED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4294 -msgid "See also :ref:`INVENTORY_ANY_UNPARSED_IS_FAILED `" -msgstr "「:ref:`INVENTORY_ANY_UNPARSED_IS_FAILED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4302 -msgid "See also :ref:`INVENTORY_CACHE_ENABLED `" -msgstr "「:ref:`INVENTORY_CACHE_ENABLED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4310 -msgid "See also :ref:`INVENTORY_CACHE_PLUGIN `" -msgstr "「:ref:`INVENTORY_CACHE_PLUGIN `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4318 -msgid "See also :ref:`INVENTORY_CACHE_PLUGIN_CONNECTION `" -msgstr "「:ref:`INVENTORY_CACHE_PLUGIN_CONNECTION `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4326 -msgid "See also :ref:`INVENTORY_CACHE_PLUGIN_PREFIX `" -msgstr "「:ref:`INVENTORY_CACHE_PLUGIN_PREFIX `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4334 -msgid "See also :ref:`INVENTORY_CACHE_TIMEOUT `" -msgstr "「:ref:`INVENTORY_CACHE_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4342 -msgid "See also :ref:`INVENTORY_ENABLED `" -msgstr "「:ref:`INVENTORY_ENABLED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4350 -msgid "See also :ref:`INVENTORY_EXPORT `" -msgstr "「:ref:`INVENTORY_EXPORT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4358 -msgid "See also :ref:`INVENTORY_IGNORE_EXTS `" -msgstr "「:ref:`INVENTORY_IGNORE_EXTS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4366 -msgid "See also :ref:`INVENTORY_IGNORE_PATTERNS `" -msgstr "「:ref:`INVENTORY_IGNORE_PATTERNS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4375 -msgid "See also :ref:`INVENTORY_UNPARSED_IS_FAILED `" -msgstr "「:ref:`INVENTORY_UNPARSED_IS_FAILED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4383 -msgid "See also :ref:`MAX_FILE_SIZE_FOR_DIFF `" -msgstr "「:ref:`MAX_FILE_SIZE_FOR_DIFF `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4390 -#: ../../rst/reference_appendices/config.rst:4399 -msgid "See also :ref:`NETWORK_GROUP_MODULES `" -msgstr "「:ref:`NETWORK_GROUP_MODULES `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4405 -msgid "Facts are available inside the `ansible_facts` variable, this setting also pushes them as their own vars in the main namespace.Unlike inside the `ansible_facts` dictionary, these will have an `ansible_` prefix." -msgstr "ファクトは `ansible_facts` 変数内で利用できます。この設定は、主な名前空間で独自の変数としてプッシュされます。`ansible_facts` ディクショナリー内とは異なり、これには `ansible_` の接頭辞があります。" - -#: ../../rst/reference_appendices/config.rst:4407 -msgid "See also :ref:`INJECT_FACTS_AS_VARS `" -msgstr "「:ref:`INJECT_FACTS_AS_VARS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4413 -msgid "List of extensions to ignore when looking for modules to loadThis is for rejecting script and binary module fallback extensions" -msgstr "読み込むモジュールを探すときに無視する拡張機能のリスト。これは、スクリプトおよびバイナリーモジュールのフォールバック拡張機能を拒否するためのものです。" - -#: ../../rst/reference_appendices/config.rst:4415 -msgid "See also :ref:`MODULE_IGNORE_EXTS `" -msgstr "「:ref:`MODULE_IGNORE_EXTS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4423 -msgid "See also :ref:`OLD_PLUGIN_CACHE_CLEARING `" -msgstr "「:ref:`OLD_PLUGIN_CACHE_CLEARING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4430 -msgid "See also :ref:`PARAMIKO_HOST_KEY_AUTO_ADD `" -msgstr "「:ref:`PARAMIKO_HOST_KEY_AUTO_ADD `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4437 -msgid "See also :ref:`PARAMIKO_LOOK_FOR_KEYS `" -msgstr "「:ref:`PARAMIKO_LOOK_FOR_KEYS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4445 -msgid "See also :ref:`PERSISTENT_CONTROL_PATH_DIR `" -msgstr "「:ref:`PERSISTENT_CONTROL_PATH_DIR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4453 -msgid "See also :ref:`PERSISTENT_CONNECT_TIMEOUT `" -msgstr "「:ref:`PERSISTENT_CONNECT_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4461 -msgid "See also :ref:`PERSISTENT_CONNECT_RETRY_TIMEOUT `" -msgstr "「:ref:`PERSISTENT_CONNECT_RETRY_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4469 -msgid "See also :ref:`PERSISTENT_COMMAND_TIMEOUT `" -msgstr "「:ref:`PERSISTENT_COMMAND_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4477 -msgid "See also :ref:`PLAYBOOK_DIR `" -msgstr "「:ref:`PLAYBOOK_DIR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4483 -msgid "This sets which playbook dirs will be used as a root to process vars plugins, which includes finding host_vars/group_varsThe ``top`` option follows the traditional behaviour of using the top playbook in the chain to find the root directory.The ``bottom`` option follows the 2.4.0 behaviour of using the current playbook to find the root directory.The ``all`` option examines from the first parent to the current playbook." -msgstr "これにより、vars プラグインを処理するためのルートとして使用される Playbook ディレクトリーが設定されます。これには、host_vars/group_vars の検索が含まれます。``top`` オプションは、チェーンの最上位の Playbook を使用してルートディレクトリーを見つけるという従来の動作に従います。``bottom`` オプションは、現在の Playbook を使用してルートディレクトリーを検索する 2.4.0 の動作に従います。``all`` オプションは、最初の親から現在の Playbook までを調べます。" - -#: ../../rst/reference_appendices/config.rst:4485 -msgid "See also :ref:`PLAYBOOK_VARS_ROOT `" -msgstr "「:ref:`PLAYBOOK_VARS_ROOT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4494 -msgid "See also :ref:`PYTHON_MODULE_RLIMIT_NOFILE `" -msgstr "「:ref:`PYTHON_MODULE_RLIMIT_NOFILE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4502 -msgid "See also :ref:`RETRY_FILES_ENABLED `" -msgstr "「:ref:`RETRY_FILES_ENABLED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4508 -msgid "This sets the path in which Ansible will save .retry files when a playbook fails and retry files are enabled.This file will be overwritten after each run with the list of failed hosts from all plays." -msgstr "これにより、Playbook が失敗し、再試行ファイルが有効になっている場合に、Ansible が .retry ファイルを保存するパスが設定されます。このファイルは、実行するたびに、すべてのプレイで失敗したホストのリストで上書きされます。" - -#: ../../rst/reference_appendices/config.rst:4510 -msgid "See also :ref:`RETRY_FILES_SAVE_PATH `" -msgstr "「:ref:`RETRY_FILES_SAVE_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4516 -msgid "This setting can be used to optimize vars_plugin usage depending on user's inventory size and play selection.Setting to C(demand) will run vars_plugins relative to inventory sources anytime vars are 'demanded' by tasks.Setting to C(start) will run vars_plugins relative to inventory sources after importing that inventory source." -msgstr "この設定は、ユーザーのインベントリーサイズとプレイの選択に応じて vars_plugin の使用を最適化するために使用できます。C(demand) に設定すると、タスクによって変数が「要求」されるたびに、インベントリーソースに関連して vars_plugins が実行されます。C(start) に設定すると、インベントリーソースをインポートした後、インベントリーソースに関連して vars_plugins が実行されます。" - -#: ../../rst/reference_appendices/config.rst:4518 -msgid "See also :ref:`RUN_VARS_PLUGINS `" -msgstr "「:ref:`RUN_VARS_PLUGINS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4526 -msgid "See also :ref:`SHOW_CUSTOM_STATS `" -msgstr "「:ref:`SHOW_CUSTOM_STATS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4532 -msgid "This list of filters avoids 'type conversion' when templating variablesUseful when you want to avoid conversion into lists or dictionaries for JSON strings, for example." -msgstr "このフィルターのリストは、変数をテンプレート化するときに「型変換」を回避します。たとえば、JSON 文字列のリストやディレクトリーへの変換を回避したい場合に便利です。" - -#: ../../rst/reference_appendices/config.rst:4534 -msgid "See also :ref:`STRING_TYPE_FILTERS `" -msgstr "「:ref:`STRING_TYPE_FILTERS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4540 -msgid "Allows disabling of warnings related to potential issues on the system running ansible itself (not on the managed hosts)These may include warnings about 3rd party packages or other conditions that should be resolved if possible." -msgstr "Ansible 自体を実行している (管理対象ホストではない) システムの潜在的な問題に関連する警告を無効にすることができます。これには、サードパーティーのパッケージに関する警告や、可能であれば解決する必要のあるその他の条件が含まれる場合があります。" - -#: ../../rst/reference_appendices/config.rst:4542 -msgid "See also :ref:`SYSTEM_WARNINGS `" -msgstr "「:ref:`SYSTEM_WARNINGS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4550 -msgid "See also :ref:`TAGS_RUN `" -msgstr "「:ref:`TAGS_RUN `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4558 -msgid "See also :ref:`TAGS_SKIP `" -msgstr "「:ref:`TAGS_SKIP `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4564 -msgid "Set the maximum time (in seconds) that a task can run for.If set to 0 (the default) there is no timeout." -msgstr "タスクを実行する最大時間 (秒単位) を設定します。0 (デフォルト) に設定するとタイムアウトはありません。" - -#: ../../rst/reference_appendices/config.rst:4566 -msgid "See also :ref:`TASK_TIMEOUT `" -msgstr "「:ref:`TASK_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4572 -msgid "The maximum number of times to check Task Queue Manager worker processes to verify they have exited cleanly.After this limit is reached any worker processes still running will be terminated.This is for internal use only." -msgstr "Task Queue Manager ワーカープロセスをチェックして、それらが正常に終了したことを確認する最大回数。この制限に達すると、まだ実行中のワーカープロセスはすべて終了します。これは内部使用のみです。" - -#: ../../rst/reference_appendices/config.rst:4574 -msgid "See also :ref:`WORKER_SHUTDOWN_POLL_COUNT `" -msgstr "「:ref:`WORKER_SHUTDOWN_POLL_COUNT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4580 -msgid "The number of seconds to sleep between polling loops when checking Task Queue Manager worker processes to verify they have exited cleanly.This is for internal use only." -msgstr "Task Queue Manager ワーカープロセスをチェックして、それらが正常に終了したことを確認するときに、ポーリングループ間でスリープする秒数。これは内部使用のみです。" - -#: ../../rst/reference_appendices/config.rst:4582 -msgid "See also :ref:`WORKER_SHUTDOWN_POLL_DELAY `" -msgstr "「:ref:`WORKER_SHUTDOWN_POLL_DELAY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4590 -msgid "See also :ref:`USE_PERSISTENT_CONNECTIONS `" -msgstr "「:ref:`USE_PERSISTENT_CONNECTIONS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4598 -msgid "See also :ref:`VARIABLE_PLUGINS_ENABLED `" -msgstr "「:ref:`VARIABLE_PLUGINS_ENABLED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4606 -msgid "See also :ref:`VARIABLE_PRECEDENCE `" -msgstr "「:ref:`VARIABLE_PRECEDENCE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4612 -msgid "For asynchronous tasks in Ansible (covered in Asynchronous Actions and Polling), this is how long, in seconds, to wait for the task spawned by Ansible to connect back to the named pipe used on Windows systems. The default is 5 seconds. This can be too low on slower systems, or systems under heavy load.This is not the total time an async command can run for, but is a separate timeout to wait for an async command to start. The task will only start to be timed against its async_timeout once it has connected to the pipe, so the overall maximum duration the task can take will be extended by the amount specified here." -msgstr "Ansible の非同期タスク (「非同期アクションおよびポーリング」で説明) の場合、これは、Ansible が生成するタスクが Windows システムで使用される名前付きパイプに接続するのを待機する時間 (秒単位) です。デフォルトは 5 秒です。これは、低速のシステムや高負荷のシステムでは低すぎる可能性があります。これは、非同期コマンドを実行できる合計時間ではありませんが、非同期コマンドの開始を待機する別のタイムアウトです。タスクは、パイプに接続された後にのみ async_timeout に対してタイムアウトが開始するため、タスクの全体的な最大期間は、ここで指定された分だけ延長されます。" - -#: ../../rst/reference_appendices/config.rst:4614 -msgid "See also :ref:`WIN_ASYNC_STARTUP_TIMEOUT `" -msgstr "「:ref:`WIN_ASYNC_STARTUP_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4620 -msgid "Check all of these extensions when looking for 'variable' files which should be YAML or JSON or vaulted versions of these.This affects vars_files, include_vars, inventory and vars plugins among others." -msgstr "YAML または JSON、あるいはこれらの Vault バージョンである必要がある「変数」ファイルを探すときは、これらすべての拡張子を確認してください。これは、vars_files、include_vars、inventory、vars プラグインなどに影響します。" - -#: ../../rst/reference_appendices/config.rst:4622 -msgid "See also :ref:`YAML_FILENAME_EXTENSIONS `" -msgstr "「:ref:`YAML_FILENAME_EXTENSIONS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4630 -msgid "See also :ref:`NETCONF_SSH_CONFIG `" -msgstr "「:ref:`NETCONF_SSH_CONFIG `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4636 -msgid "Action to take when a module parameter value is converted to a string (this does not affect variables). For string parameters, values such as '1.00', \"['a', 'b',]\", and 'yes', 'y', etc. will be converted by the YAML parser unless fully quoted.Valid options are 'error', 'warn', and 'ignore'.Since 2.8, this option defaults to 'warn' but will change to 'error' in 2.12." -msgstr "モジュールパラメーター値が文字列に変換されるときに実行するアクション (これは変数には影響しません)。文字列パラメーターの場合、「1.00」、「['a', 'b',]」、「yes」、「y」などの値は、完全に引用されていない限り、YAML パーサーにより変換されます。有効なオプションは、「error」、「warn」、および「ignore」です。2.8 以降、このオプションのデフォルトは「warn」ですが、2.12では「error」に変更されます。" - -#: ../../rst/reference_appendices/config.rst:4638 -msgid "See also :ref:`STRING_CONVERSION_ACTION `" -msgstr "「:ref:`STRING_CONVERSION_ACTION `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4646 -msgid "See also :ref:`VERBOSE_TO_STDERR `" -msgstr "「:ref:`VERBOSE_TO_STDERR `」も参照してください。" - -#: ../../rst/reference_appendices/faq.rst:4 -msgid "Frequently Asked Questions" -msgstr "よくある質問 (FAQ)" - -#: ../../rst/reference_appendices/faq.rst:6 -msgid "Here are some commonly asked questions and their answers." -msgstr "以下に、よくある質問とその回答を紹介しています。" - -#: ../../rst/reference_appendices/faq.rst:11 -msgid "Where did all the modules go?" -msgstr "すべてのモジュールはどこに移されましたか" - -#: ../../rst/reference_appendices/faq.rst:13 -msgid "In July, 2019, we announced that collections would be the `future of Ansible content delivery `_. A collection is a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. In Ansible 2.9 we added support for collections. In Ansible 2.10 we `extracted most modules from the main ansible/ansible repository `_ and placed them in :ref:`collections `. Collections may be maintained by the Ansible team, by the Ansible community, or by Ansible partners. The `ansible/ansible repository `_ now contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-base``." -msgstr "2019 年 7 月、私たちはコレクションが `Ansible コンテンツデリバリーの未来 `_ になることを発表しました。コレクションは、Playbook、ロール、モジュール、およびプラグインを含む Ansible コンテンツの配布形式です。Ansible 2.9 では、コレクションのサポートを追加しました。Ansible 2.10 では、私たちは `主な ansible/ansible リポジトリーからほとんどのモジュールを抽出 `_ して、そのモジュールを :ref:`コレクション ` に置きました。コレクションは、Ansible チーム、Ansible コミュニティー、または Ansible パートナーによって維持されます。`ansible/ansible リポジトリー `_ には、モジュールコードを管理対象ノードにコピーするなど、基本的な機能および関数のコードが含まれています。このコードは ``ansible-base`` とも呼ばれます。" - -#: ../../rst/reference_appendices/faq.rst:15 -msgid "To learn more about using collections, see :ref:`collections`." -msgstr "コレクションの使用に関する詳細は、「:ref:`collections`」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:16 -msgid "To learn more about developing collections, see :ref:`developing_collections`." -msgstr "コレクション開発に関する詳細は、「:ref:`developing_collections`」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:17 -msgid "To learn more about contributing to existing collections, see the individual collection repository for guidelines, or see :ref:`contributing_maintained_collections` to contribute to one of the Ansible-maintained collections." -msgstr "既存のコレクションへの貢献の詳細については、個々のコレクションリポジトリーでガイドラインを参照するか、Ansible が管理するコレクションのいずれかに貢献する方法を「:ref:`contributing_maintained_collections`」で参照してください。" - -#: ../../rst/reference_appendices/faq.rst:22 -msgid "Where did this specific module go?" -msgstr "この特定のモジュールはどこに移されましたか" - -#: ../../rst/reference_appendices/faq.rst:24 -msgid "IF you are searching for a specific module, you can check the `runtime.yml `_ file, which lists the first destination for each module that we extracted from the main ansible/ansible repository. Some modules have moved again since then. You can also search on `Ansible Galaxy `_ or ask on one of our :ref:`IRC channels `." -msgstr "特定のモジュールを検索する場合は、`runtime.yml `_ ファイルをチェックできます。このファイルには、メインの ansible/ansible リポジトリーから抽出した各モジュールの最初の宛先がリストされています。その後、いくつかのモジュールが再び移動しました。`Ansible Galaxy `_ で検索することもできますし、いずれかの :ref:`IRC チャンネル ` で尋ねることもできます。" - -#: ../../rst/reference_appendices/faq.rst:29 -msgid "How can I set the PATH or any other environment variable for a task or entire play?" -msgstr "タスクやプレイ全体に PATH またはその他の環境変数をどのように設定すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:31 -msgid "Setting environment variables can be done with the `environment` keyword. It can be used at the task or other levels in the play." -msgstr "環境変数の設定は、`environment` キーワードで実行できます。これは、プレイ内のタスクや他のレベルで使用できます。" - -#: ../../rst/reference_appendices/faq.rst:47 -msgid "starting in 2.0.1 the setup task from ``gather_facts`` also inherits the environment directive from the play, you might need to use the ``|default`` filter to avoid errors if setting this at play level." -msgstr "2.0.1 以降で、``gather_facts`` の設定タスクは、プレイからの環境ディレクティブも継承します。これがプレイレベルで設定されている場合は、``|default`` フィルターを使用したエラーの回避が必要になる場合があります。" - -#: ../../rst/reference_appendices/faq.rst:52 -msgid "How do I handle different machines needing different user accounts or ports to log in with?" -msgstr "異なるユーザーアカウントまたはポートでログインする必要のある各種マシンをどのように処理すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:54 -msgid "Setting inventory variables in the inventory file is the easiest way." -msgstr "インベントリーファイルにインベントリー変数を設定する方法が最も簡単です。" - -#: ../../rst/reference_appendices/faq.rst:56 -msgid "For instance, suppose these hosts have different usernames and ports:" -msgstr "たとえば、以下では、ホストに異なるユーザー名とポートが指定されています。" - -#: ../../rst/reference_appendices/faq.rst:64 -msgid "You can also dictate the connection type to be used, if you want:" -msgstr "任意で、使用する接続タイプを指定できます。" - -#: ../../rst/reference_appendices/faq.rst:73 -msgid "You may also wish to keep these in group variables instead, or file them in a group_vars/ file. See the rest of the documentation for more information about how to organize variables." -msgstr "上記の値を、代わりにグループ変数や group_vars/ ファイルに保持できます。変数を整理する方法は、本ガイドの他のセクションを参照してください。" - -#: ../../rst/reference_appendices/faq.rst:79 -msgid "How do I get ansible to reuse connections, enable Kerberized SSH, or have Ansible pay attention to my local SSH config file?" -msgstr "Ansible を使用して接続を再利用したり、Kerberos を設定した SSH を有効にしたり、Ansible がローカルの SSH 設定を使用するにはどうしたら良いですか" - -#: ../../rst/reference_appendices/faq.rst:81 -msgid "Switch your default connection type in the configuration file to ``ssh``, or use ``-c ssh`` to use Native OpenSSH for connections instead of the python paramiko library. In Ansible 1.2.1 and later, ``ssh`` will be used by default if OpenSSH is new enough to support ControlPersist as an option." -msgstr "設定ファイルのデフォルトの接続タイプを ``ssh`` に切り替えるか、Python Paramiko ライブラリーの代わりに、``-c ssh`` で、接続にネイティブの OpenSSH を使用してください。Ansible 1.2.1 以降では、OpenSSH が新しく、オプションとして ControlPersist をサポートする場合にはデフォルトで ``ssh`` を使用します。" - -#: ../../rst/reference_appendices/faq.rst:85 -msgid "Paramiko is great for starting out, but the OpenSSH type offers many advanced options. You will want to run Ansible from a machine new enough to support ControlPersist, if you are using this connection type. You can still manage older clients. If you are using RHEL 6, CentOS 6, SLES 10 or SLES 11 the version of OpenSSH is still a bit old, so consider managing from a Fedora or openSUSE client even though you are managing older nodes, or just use paramiko." -msgstr "Paramiko は使用を開始するときには便利ですが、OpenSSH のタイプでは多数の詳細オプションを利用できます。OpenSSH の接続タイプを使用する場合には、ControlPersist をサポートできる新しいマシンから Ansible を実行してください。古いクライアントは引き続き管理できます。RHEL 6、CentOS 6、SLES 10、または SLES 11 を使用している場合は、OpenSSH のバージョンが若干古いため、以前のノードを管理している場合でも、Fedora または openSUSE クライアントからの管理を検討するか、paramiko を使用してください。" - -#: ../../rst/reference_appendices/faq.rst:90 -msgid "We keep paramiko as the default as if you are first installing Ansible on these enterprise operating systems, it offers a better experience for new users." -msgstr "Paramiko は、これらのエンタープライズオペレーティングシステムに Ansible を最初にインストールしている場合と同じようにデフォルトのままとなっており、新規ユーザーによって使用しやすくなっています。" - -#: ../../rst/reference_appendices/faq.rst:95 -msgid "How do I configure a jump host to access servers that I have no direct access to?" -msgstr "直接アクセス権のないサーバーにジャンプホストを使用してアクセスできるように設定するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:97 -msgid "You can set a ``ProxyCommand`` in the ``ansible_ssh_common_args`` inventory variable. Any arguments specified in this variable are added to the sftp/scp/ssh command line when connecting to the relevant host(s). Consider the following inventory group:" -msgstr "``ansible_ssh_common_args`` インベントリー変数に ``ProxyCommand`` を設定することができます。該当のホストに接続したときに、この変数に指定した引数は、sftp/scp/ssh コマンドラインに追加されます。次のインベントリーグループについて考えてみます。" - -#: ../../rst/reference_appendices/faq.rst:108 -msgid "You can create `group_vars/gatewayed.yml` with the following contents::" -msgstr "以下の内容で `group_vars/gatewayed.yml` を作成できます::" - -#: ../../rst/reference_appendices/faq.rst:112 -msgid "Ansible will append these arguments to the command line when trying to connect to any hosts in the group ``gatewayed``. (These arguments are used in addition to any ``ssh_args`` from ``ansible.cfg``, so you do not need to repeat global ``ControlPersist`` settings in ``ansible_ssh_common_args``.)" -msgstr "Ansible は、``gatewayed`` グループのホストに接続しようとすると、コマンドラインに 3 つの引数を追加します。(``ansible.cfg`` からの ``ssh_args`` に加えて、上記の引数が使用されるため、``ansible_ssh_common_args`` のグローバル ``ControlPersist`` 設定を繰り返す必要はありません)。" - -#: ../../rst/reference_appendices/faq.rst:117 -msgid "Note that ``ssh -W`` is available only with OpenSSH 5.4 or later. With older versions, it's necessary to execute ``nc %h:%p`` or some equivalent command on the bastion host." -msgstr "``ssh -W`` は、OpenSSH 5.4 以降でのみ利用できます。以前のバージョンでは、bastion ホストで ``nc %h:%p`` を実行するか、同等のコマンドを実行する必要があります。" - -#: ../../rst/reference_appendices/faq.rst:121 -msgid "With earlier versions of Ansible, it was necessary to configure a suitable ``ProxyCommand`` for one or more hosts in ``~/.ssh/config``, or globally by setting ``ssh_args`` in ``ansible.cfg``." -msgstr "Ansible の以前のバージョンでは、``~/.ssh/config`` のホスト 1 台または複数台に適切な ``ProxyCommand`` を設定するか、``ansible.cfg`` に ``ssh_args`` をグローバルに設定する必要がありました。" - -#: ../../rst/reference_appendices/faq.rst:128 -msgid "How do I get Ansible to notice a dead target in a timely manner?" -msgstr "Ansible がダウンしているターゲットを適宜検出できるようにするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:130 -msgid "You can add ``-o ServerAliveInterval=NumberOfSeconds`` in ``ssh_args`` from ``ansible.cfg``. Without this option, SSH and therefore Ansible will wait until the TCP connection times out. Another solution is to add ``ServerAliveInterval`` into your global SSH configuration. A good value for ``ServerAliveInterval`` is up to you to decide; keep in mind that ``ServerAliveCountMax=3`` is the SSH default so any value you set will be tripled before terminating the SSH session." -msgstr "``ansible.cfg`` から、``ssh_args`` に ``-o ServerAliveInterval=NumberOfSeconds`` を追加できます。このオプションがないと、SSH と Ansible は TCP 接続がタイムアウトになるまで待機します。別の解決方法は、``ServerAliveInterval`` をグローバルの SSH 設定に追加することです。``ServerAliveInterval`` に適した値は、ユーザーが決定します。ただし、SSH のデフォルトは ``ServerAliveCountMax=3`` であるため、SSH セッションの終了前に設定した値が 3 倍になる点に注意してください。" - -#: ../../rst/reference_appendices/faq.rst:138 -msgid "How do I speed up run of ansible for servers from cloud providers (EC2, openstack,.. )?" -msgstr "クラウドプロバイダー (EC2、openstack など) からのサーバーで Ansible の実行を高速化するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:140 -msgid "Don't try to manage a fleet of machines of a cloud provider from your laptop. Rather connect to a management node inside this cloud provider first and run Ansible from there." -msgstr "ラップトップからクラウドプロバイダーのマシンのフリートを管理しようとしないでください。代わりに、最初にこのクラウドプロバイダー内の管理ノードに接続し、そこから Ansible を実行します。" - -#: ../../rst/reference_appendices/faq.rst:146 -msgid "How do I handle not having a Python interpreter at /usr/bin/python on a remote machine?" -msgstr "リモートマシンの /usr/bin/python に Python インタープリターを配置せずに対応するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:148 -msgid "While you can write Ansible modules in any language, most Ansible modules are written in Python, including the ones central to letting Ansible work." -msgstr "Ansible モジュールはどの言語でも記述できますが、Ansible の機能を司るコアモジュールなど、Ansible モジュールの多くは Python で記述されています。" - -#: ../../rst/reference_appendices/faq.rst:151 -msgid "By default, Ansible assumes it can find a :command:`/usr/bin/python` on your remote system that is either Python2, version 2.6 or higher or Python3, 3.5 or higher." -msgstr "デフォルトでは、Ansible は、Python2 のバージョン 2.6 以降または Python3 の 3.5 以降のリモートマシンの :command:`/usr/bin/python` を検出できます。" - -#: ../../rst/reference_appendices/faq.rst:154 -msgid "Setting the inventory variable ``ansible_python_interpreter`` on any host will tell Ansible to auto-replace the Python interpreter with that value instead. Thus, you can point to any Python you want on the system if :command:`/usr/bin/python` on your system does not point to a compatible Python interpreter." -msgstr "ホストにインベントリー変数 ``ansible_python_interpreter`` を設定すると、Ansible に対して、代わりに Python インタープリターをこのインベントリー変数の値に自動で置き換えるように指示を出します。このように、お使いのシステムの :command:`/usr/bin/python` が互換性のある Python インタープリターを指定していない場合は、使用する Python を指定できます。" - -#: ../../rst/reference_appendices/faq.rst:159 -msgid "Some platforms may only have Python 3 installed by default. If it is not installed as :command:`/usr/bin/python`, you will need to configure the path to the interpreter via ``ansible_python_interpreter``. Although most core modules will work with Python 3, there may be some special purpose ones which do not or you may encounter a bug in an edge case. As a temporary workaround you can install Python 2 on the managed host and configure Ansible to use that Python via ``ansible_python_interpreter``. If there's no mention in the module's documentation that the module requires Python 2, you can also report a bug on our `bug tracker `_ so that the incompatibility can be fixed in a future release." -msgstr "プラットフォームによっては、デフォルトで Python3 のみがインストールされている場合があります。:command:`/usr/bin/python` としてインストールされていない場合は、``ansible_python_interpreter`` を介してインタープリターへのパスを設定する必要があります。コアモジュールの多くが Python 3 と連携しますが、いくつかの特殊用途のモジュールは動作しないかもしれないし、特殊なケースでバグが発生するかもしれません。一時的な回避策として、管理対象ホストに Python 2をインストールし、``ansible_python_interpreter`` からその Python を使用するように Ansible を構成できます。モジュールのドキュメントに Python 2 が必要あるとの記載がない場合は、今後このリリースで非互換性の問題が解決されるように、`バグトラッカー `_ で、バグを報告できます。" - -#: ../../rst/reference_appendices/faq.rst:168 -msgid "Do not replace the shebang lines of your python modules. Ansible will do this for you automatically at deploy time." -msgstr "Python モジュールのシバン行は置き換えないでください。デプロイ時に Ansible が自動でこれを行います。" - -#: ../../rst/reference_appendices/faq.rst:170 -msgid "Also, this works for ANY interpreter, for example ruby: ``ansible_ruby_interpreter``, perl: ``ansible_perl_interpreter``, and so on, so you can use this for custom modules written in any scripting language and control the interpreter location." -msgstr "また、これは、ruby などのすべてのインタープリター (ruby: ``ansible_ruby_interpreter``、perl: ``ansible_perl_interpreter`` など) で機能するため、任意のスクリプト言語で記述したカスタムモジュールにこれを使用して、インタープリターの場所を管理できます。" - -#: ../../rst/reference_appendices/faq.rst:173 -msgid "Keep in mind that if you put ``env`` in your module shebang line (``#!/usr/bin/env ``), this facility will be ignored so you will be at the mercy of the remote `$PATH`." -msgstr "モジュールのシバンの行 (``#!/usr/bin/env ``) に ``env`` を挿入すると、この機能は無視され、リモートの `$PATH` の設定が使用されます。" - -#: ../../rst/reference_appendices/faq.rst:179 -msgid "How do I handle the package dependencies required by Ansible package dependencies during Ansible installation ?" -msgstr "Ansible インストール中に Ansible パッケージに必要な依存関係にどのように対応すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:181 -msgid "While installing Ansible, sometimes you may encounter errors such as `No package 'libffi' found` or `fatal error: Python.h: No such file or directory` These errors are generally caused by the missing packages, which are dependencies of the packages required by Ansible. For example, `libffi` package is dependency of `pynacl` and `paramiko` (Ansible -> paramiko -> pynacl -> libffi)." -msgstr "Ansible のインストール中に、`No package 'libffi' found` または `fatal error: Python.h: No such file or directory` などのエラーが発生する場合があります。このようなエラーは通常、Ansible で必要なパッケージの依存関係パッケージが不足している場合に発生します。たとえば、`libffi` パッケージは `pynacl` および `paramiko` の依存関係です (Ansible -> paramiko -> pynacl -> libffi)。" - -#: ../../rst/reference_appendices/faq.rst:185 -msgid "In order to solve these kinds of dependency issues, you might need to install required packages using the OS native package managers, such as `yum`, `dnf`, or `apt`, or as mentioned in the package installation guide." -msgstr "このような依存関係の問題を解決するには、OS ネイティブのパッケージマネージャー (`yum`、`dnf`、`apt`、またはパッケージのインストールガイドに記載のもの) を使用して必要なパッケージをインストールしないといけない場合があります。" - -#: ../../rst/reference_appendices/faq.rst:188 -msgid "Refer to the documentation of the respective package for such dependencies and their installation methods." -msgstr "このような依存関係とそのインストール方法については、各パッケージのドキュメントを参照してください。" - -#: ../../rst/reference_appendices/faq.rst:191 -msgid "Common Platform Issues" -msgstr "一般的なプラットフォームの問題" - -#: ../../rst/reference_appendices/faq.rst:194 -msgid "What customer platforms does Red Hat support?" -msgstr "Red Hat では、どのような顧客のプラットフォームをサポートしていますか" - -#: ../../rst/reference_appendices/faq.rst:196 -msgid "A number of them! For a definitive list please see this `Knowledge Base article `_." -msgstr "その数は多数です。具体的な一覧は、`ナレッジベースの記事 `_ を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:199 -msgid "Running in a virtualenv" -msgstr "virtualenv での実行" - -#: ../../rst/reference_appendices/faq.rst:201 -msgid "You can install Ansible into a virtualenv on the controller quite simply:" -msgstr "コントローラーの virtualenv に Ansible を簡単にインストールできます。" - -#: ../../rst/reference_appendices/faq.rst:209 -msgid "If you want to run under Python 3 instead of Python 2 you may want to change that slightly:" -msgstr "Python 2 ではなく Python 3 で実行する場合は、以下のように変更する場合があります。" - -#: ../../rst/reference_appendices/faq.rst:217 -msgid "If you need to use any libraries which are not available via pip (for instance, SELinux Python bindings on systems such as Red Hat Enterprise Linux or Fedora that have SELinux enabled), then you need to install them into the virtualenv. There are two methods:" -msgstr "pip で入手できないライブラリーを使用する必要がある場合は (例: SELinux が有効な Red Hat Enterprise Linux または Fedora などのシステムにある SELinux Python のバインディング)、virtualenv にインストールする必要があります。2 つの方法があります。" - -#: ../../rst/reference_appendices/faq.rst:221 -msgid "When you create the virtualenv, specify ``--system-site-packages`` to make use of any libraries installed in the system's Python:" -msgstr "virtualenv の作成時に、``--system-site-packages`` を指定して、お使いのシステムの Python にインストールされているライブラリーを使用します。" - -#: ../../rst/reference_appendices/faq.rst:228 -msgid "Copy those files in manually from the system. For instance, for SELinux bindings you might do:" -msgstr "システムから手動でこれらのファイルをコピーします。たとえば、SELinux バインディングでは、以下を行うことができます。" - -#: ../../rst/reference_appendices/faq.rst:238 -msgid "Running on BSD" -msgstr "BSD での実行" - -#: ../../rst/reference_appendices/faq.rst:240 -msgid ":ref:`working_with_bsd`" -msgstr ":ref:`working_with_bsd`" - -#: ../../rst/reference_appendices/faq.rst:244 -msgid "Running on Solaris" -msgstr "Solaris での実行" - -#: ../../rst/reference_appendices/faq.rst:246 -msgid "By default, Solaris 10 and earlier run a non-POSIX shell which does not correctly expand the default tmp directory Ansible uses ( :file:`~/.ansible/tmp`). If you see module failures on Solaris machines, this is likely the problem. There are several workarounds:" -msgstr "デフォルトでは Solaris 10 以前では POSIX 以外のシェルを実行しますが、Ansible が使用するデフォルトの tmp ディレクトリー (:file:`~/.ansible/tmp`) を正しく展開しません。Solaris マシンでモジュールの問題が発生する場合には、上記が問題の可能性が高いです。回避策はいくつかあります。" - -#: ../../rst/reference_appendices/faq.rst:250 -msgid "You can set ``remote_tmp`` to a path that will expand correctly with the shell you are using (see the plugin documentation for :ref:`C shell`, :ref:`fish shell`, and :ref:`Powershell`). For example, in the ansible config file you can set::" -msgstr "使用するシェル (:ref:`C shell`、:ref:`fish shell`、および :ref:`Powershell` のプラグインのドキュメントを参照) で正しく展開されるパスに ``remote_tmp`` を設定します。設定する ansible 設定ファイルで、以下を指定します。" - -#: ../../rst/reference_appendices/faq.rst:256 -msgid "In Ansible 2.5 and later, you can also set it per-host in inventory like this::" -msgstr "Ansible 2.5 以降では、以下のようにインベントリーでホストごとに設定することも可能です。" - -#: ../../rst/reference_appendices/faq.rst:260 -msgid "You can set :ref:`ansible_shell_executable` to the path to a POSIX compatible shell. For instance, many Solaris hosts have a POSIX shell located at :file:`/usr/xpg4/bin/sh` so you can set this in inventory like so::" -msgstr ":ref:`ansible_shell_executable` を、POSIX の互換性のあるパスに設定します。たとえば、多数の Solaris ホストでは POSIX シェルが、:file:`/usr/xpg4/bin/sh` に配置されているため、インベントリーにこの値を以下のように設定できます。" - -#: ../../rst/reference_appendices/faq.rst:266 -msgid "(bash, ksh, and zsh should also be POSIX compatible if you have any of those installed)." -msgstr "(bash、ksh、または zsh のいずれかがインストールされている場合には、これも POSIX の互換性が必要です)。" - -#: ../../rst/reference_appendices/faq.rst:269 -msgid "Running on z/OS" -msgstr "z/OS での実行" - -#: ../../rst/reference_appendices/faq.rst:271 -msgid "There are a few common errors that one might run into when trying to execute Ansible on z/OS as a target." -msgstr "z/OS でターゲットとして Ansible を実行しようとすると、複数の共通のエラーが発生する可能性があります。" - -#: ../../rst/reference_appendices/faq.rst:273 -msgid "Version 2.7.6 of python for z/OS will not work with Ansible because it represents strings internally as EBCDIC." -msgstr "z/OS 向けの Python バージョン 2.7.6 は、内部で文字列を EBCDIC として表現するため、Ansible では機能しない。" - -#: ../../rst/reference_appendices/faq.rst:275 -msgid "To get around this limitation, download and install a later version of `python for z/OS `_ (2.7.13 or 3.6.1) that represents strings internally as ASCII. Version 2.7.13 is verified to work." -msgstr "この制限を回避するには、文字列を ASCII で表現する `python for z/OS `_ (2.7.13 または 3.6.1) をダウンロードしてインストールしてください。バージョン 2.7.13 では機能することが確認されています。" - -#: ../../rst/reference_appendices/faq.rst:277 -msgid "When ``pipelining = False`` in `/etc/ansible/ansible.cfg` then Ansible modules are transferred in binary mode via sftp however execution of python fails with" -msgstr "`/etc/ansible/ansible.cfg` で ``pipelining = False`` と指定されている場合、以下により、Ansible モジュールは Python の実行エラーが何であっても、sftp 経由でバイナリーモードで転送されます。" - -#: ../../rst/reference_appendices/faq.rst:280 -msgid "SyntaxError: Non-UTF-8 code starting with \\'\\\\x83\\' in file /a/user1/.ansible/tmp/ansible-tmp-1548232945.35-274513842609025/AnsiballZ_stat.py on line 1, but no encoding declared; see https://python.org/dev/peps/pep-0263/ for details" -msgstr "SyntaxError: Non-UTF-8 code starting with \\'\\\\x83\\' in file /a/user1/.ansible/tmp/ansible-tmp-1548232945.35-274513842609025/AnsiballZ_stat.py on line 1, but no encoding declared; see https://python.org/dev/peps/pep-0263/ for details" - -#: ../../rst/reference_appendices/faq.rst:282 -msgid "To fix it set ``pipelining = True`` in `/etc/ansible/ansible.cfg`." -msgstr "これを修正するには、`/etc/ansible/ansible.cfg` に ``pipelining = True`` を設定します。" - -#: ../../rst/reference_appendices/faq.rst:284 -msgid "Python interpret cannot be found in default location ``/usr/bin/python`` on target host." -msgstr "Python インタープリターがターゲットホストのデフォルトの場所 ``/usr/bin/python`` で検出できない。" - -#: ../../rst/reference_appendices/faq.rst:287 -msgid "/usr/bin/python: EDC5129I No such file or directory" -msgstr "/usr/bin/python: EDC5129I No such file or directory" - -#: ../../rst/reference_appendices/faq.rst:289 -msgid "To fix this set the path to the python installation in your inventory like so::" -msgstr "これを解決するには、以下のようにインベントリーでパスを Python インストールに設定してください。" - -#: ../../rst/reference_appendices/faq.rst:293 -msgid "Start of python fails with ``The module libpython2.7.so was not found.``" -msgstr "python の起動に失敗し、``The module libpython2.7.so was not found.`` が表示" - -#: ../../rst/reference_appendices/faq.rst:296 -msgid "EE3501S The module libpython2.7.so was not found." -msgstr "EE3501S The module libpython2.7.so was not found." - -#: ../../rst/reference_appendices/faq.rst:298 -msgid "On z/OS, you must execute python from gnu bash. If gnu bash is installed at ``/usr/lpp/bash``, you can fix this in your inventory by specifying an ``ansible_shell_executable``::" -msgstr "z/OS では、gnu bash から python を実行する必要があります。gnu bash が ``/usr/lpp/bash`` にインストールされている場合は、インベントリーで ``ansible_shell_executable`` を指定して修正できます。" - -#: ../../rst/reference_appendices/faq.rst:304 -msgid "Running under fakeroot" -msgstr "fakeroot 下で実行" - -#: ../../rst/reference_appendices/faq.rst:306 -msgid "Some issues arise as ``fakeroot`` does not create a full nor POSIX compliant system by default. It is known that it will not correctly expand the default tmp directory Ansible uses (:file:`~/.ansible/tmp`). If you see module failures, this is likely the problem. The simple workaround is to set ``remote_tmp`` to a path that will expand correctly (see documentation of the shell plugin you are using for specifics)." -msgstr "``fakeroot`` は、デフォルトでは完全なシステムも POSIX 準拠のシステムも作成しないため、いくつかの問題が発生します。Ansible が使用するデフォルトの tmp ディレクトリー (:file:`~/.ansible/tmp`) を正しく展開しないことがわかっています。モジュール障害が発生している場合は、これが問題である可能性があります。簡単な回避策は、正しく展開されるパスに ``remote_tmp`` を設定することです (詳細については、使用している shell プラグインのドキュメントを参照してください)。" - -#: ../../rst/reference_appendices/faq.rst:311 -msgid "For example, in the ansible config file (or via environment variable) you can set::" -msgstr "設定する ansible 設定ファイルで (または環境変数を介して)、以下を指定します。" - -#: ../../rst/reference_appendices/faq.rst:320 -msgid "What is the best way to make content reusable/redistributable?" -msgstr "コンテンツを再利用/再配信できるようにする最適な方法にはどんなものがありますか" - -#: ../../rst/reference_appendices/faq.rst:322 -msgid "If you have not done so already, read all about \"Roles\" in the playbooks documentation. This helps you make playbook content self-contained, and works well with things like git submodules for sharing content with others." -msgstr "Playbook ドキュメントの「ロール」の情報をまだ読んでいない場合は、一読してください。Playbook のコンテンツを自己完結型にし、git submodules などと連携させて、他とのコンテンツ共有が容易になります。" - -#: ../../rst/reference_appendices/faq.rst:325 -msgid "If some of these plugin types look strange to you, see the API documentation for more details about ways Ansible can be extended." -msgstr "このようなプラグインタイプの詳細は、Ansible の拡張方法に関する詳細を API ドキュメントで確認してください。" - -#: ../../rst/reference_appendices/faq.rst:330 -msgid "Where does the configuration file live and what can I configure in it?" -msgstr "設定ファイルの配置場所はどこですか。または、どのように設定すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:333 -msgid "See :ref:`intro_configuration`." -msgstr "「:ref:`intro_configuration`」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:338 -msgid "How do I disable cowsay?" -msgstr "cowsay はどのように無効化すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:340 -msgid "If cowsay is installed, Ansible takes it upon itself to make your day happier when running playbooks. If you decide that you would like to work in a professional cow-free environment, you can either uninstall cowsay, set ``nocows=1`` in ``ansible.cfg``, or set the :envvar:`ANSIBLE_NOCOWS` environment variable:" -msgstr "cowsay がインストールされている場合は、Playbook を実行すると、Ansible がすべてを引き受けて処理します。プロフェッショナルな cowsay のない環境で作業する場合は、cowsay をアンインストールするか、``ansible.cfg`` に ``nocows=1`` を設定するか、:envvar:`ANSIBLE_NOCOWS` の環境変数を設定します。" - -#: ../../rst/reference_appendices/faq.rst:351 -msgid "How do I see a list of all of the ansible\\_ variables?" -msgstr "ansible\\_ 変数一覧を確認するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:353 -msgid "Ansible by default gathers \"facts\" about the machines under management, and these facts can be accessed in playbooks and in templates. To see a list of all of the facts that are available about a machine, you can run the ``setup`` module as an ad hoc action:" -msgstr "Ansible はデフォルトで、管理対象のマシンの「ファクト」を収集し、このファクトには Playbook またはテンプレートでアクセスできます。あるマシンで利用可能なファクトの一覧を表示するには、``setup`` モジュールを ad-hoc アクションとして実行できます。" - -#: ../../rst/reference_appendices/faq.rst:361 -msgid "This will print out a dictionary of all of the facts that are available for that particular host. You might want to pipe the output to a pager.This does NOT include inventory variables or internal 'magic' variables. See the next question if you need more than just 'facts'." -msgstr "これにより、特定のホストで利用可能な全ファクトのディクショナリーが出力されます。ページャーの出力をパイプする場合は、インベントリー変数や内部の「magic」変数は含まれません。「ファクト」以外の情報が必要な場合は、次の質問を確認してください。" - -#: ../../rst/reference_appendices/faq.rst:369 -msgid "How do I see all the inventory variables defined for my host?" -msgstr "ホストに定義されたインベントリー変数をすべて確認するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:371 -msgid "By running the following command, you can see inventory variables for a host:" -msgstr "以下のコマンドを実行すると、ホストのインベントリー変数を確認できます。" - -#: ../../rst/reference_appendices/faq.rst:381 -msgid "How do I see all the variables specific to my host?" -msgstr "ホスト固有の全変数を確認するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:383 -msgid "To see all host specific variables, which might include facts and other sources:" -msgstr "ホスト固有の変数をすべて確認するには以下を実行します (ファクトや他のソースが含まれる可能性があります)。" - -#: ../../rst/reference_appendices/faq.rst:389 -msgid "Unless you are using a fact cache, you normally need to use a play that gathers facts first, for facts included in the task above." -msgstr "ファクトキャッシュを使用していない限り、上記のタスクに含まれるファクトについては、通常、先にファクトを収集するプレイを使用する必要があります。" - -#: ../../rst/reference_appendices/faq.rst:395 -msgid "How do I loop over a list of hosts in a group, inside of a template?" -msgstr "テンプレート内のグループに含まれるホストの一覧をループするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:397 -msgid "A pretty common pattern is to iterate over a list of hosts inside of a host group, perhaps to populate a template configuration file with a list of servers. To do this, you can just access the \"$groups\" dictionary in your template, like this:" -msgstr "非常に一般的なパターンでは、ホストグループ内でホストのリストを反復処理することです。おそらく、テンプレート設定ファイルにサーバーの一覧を入力します。これを行うには、次のように、テンプレートで「$ groups」ディクショナリーにアクセスするだけです。" - -#: ../../rst/reference_appendices/faq.rst:406 -msgid "If you need to access facts about these hosts, for instance, the IP address of each hostname, you need to make sure that the facts have been populated. For example, make sure you have a play that talks to db_servers::" -msgstr "このようなホストに関するファクト (各ホスト名の IP アドレスなど) にアクセスする必要がある場合には、ファクトが生成されていることを確認する必要があります。たとえば、db_servers と対話するプレイがあることを確認します::" - -#: ../../rst/reference_appendices/faq.rst:413 -msgid "Then you can use the facts inside your template, like this:" -msgstr "次に、以下のように、テンプレート内のファクトを使用できます。" - -#: ../../rst/reference_appendices/faq.rst:424 -msgid "How do I access a variable name programmatically?" -msgstr "プログラムで変数名にアクセスするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:426 -msgid "An example may come up where we need to get the ipv4 address of an arbitrary interface, where the interface to be used may be supplied via a role parameter or other input. Variable names can be built by adding strings together, like so:" -msgstr "たとえば、任意のインターフェースの ipv4 アドレスを取得する必要があるるかもしれません。そこでは、使用されるインターフェースがロールパラメーターまたは他の入力を介して提供される場合があります。変数名は、次のように文字列を一緒に追加することで作成できます。" - -#: ../../rst/reference_appendices/faq.rst:433 -msgid "The trick about going through hostvars is necessary because it's a dictionary of the entire namespace of variables. ``inventory_hostname`` is a magic variable that indicates the current host you are looping over in the host loop." -msgstr "それは、変数の名前空間全体のディクショナリーであるため、hostvars 全体をチェックするにはコツが必要です。``inventory_hostname`` はマジック変数で、ホストループでループを行う現在のホストを指定します。" - -#: ../../rst/reference_appendices/faq.rst:436 -msgid "In the example above, if your interface names have dashes, you must replace them with underscores:" -msgstr "上記の例では、インターフェース名にダッシュが含まれている場合は、アンダースコアに置き換える必要があります。" - -#: ../../rst/reference_appendices/faq.rst:442 -msgid "Also see dynamic_variables_." -msgstr "「dynamic_variables_」も参照してください。" - -#: ../../rst/reference_appendices/faq.rst:448 -msgid "How do I access a group variable?" -msgstr "グループ変数にアクセスするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:450 -msgid "Technically, you don't, Ansible does not really use groups directly. Groups are labels for host selection and a way to bulk assign variables, they are not a first class entity, Ansible only cares about Hosts and Tasks." -msgstr "技術的には、Ansible は実際にはグループを直接使用しません。グループはホスト選択のラベルであり、変数を一括で割り当てる手段を提供します。グループは第一級のエンティティーではなく、Ansible はホストとタスクのみを考慮します。" - -#: ../../rst/reference_appendices/faq.rst:453 -msgid "That said, you could just access the variable by selecting a host that is part of that group, see first_host_in_a_group_ below for an example." -msgstr "ただし、対象のグループに含まれるホストを選択すると、変数にアクセスできます。例については、以下の「first_host_in_a_group_」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:459 -msgid "How do I access a variable of the first host in a group?" -msgstr "グループ内の最初のホストの変数にアクセスするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:461 -msgid "What happens if we want the ip address of the first webserver in the webservers group? Well, we can do that too. Note that if we are using dynamic inventory, which host is the 'first' may not be consistent, so you wouldn't want to do this unless your inventory is static and predictable. (If you are using :ref:`ansible_tower`, it will use database order, so this isn't a problem even if you are using cloud based inventory scripts)." -msgstr "webservers グループの最初の webserver の IP アドレスが必要な場合にはどうすれば良いですか。私たちはそれも行うことができます。動的インベントリーを使用している場合は、どのホストが「最初」であるかが一貫していない可能性があるため、インベントリーが静的で予測可能でない限り、これを実行したくないことに注意してください (:ref:`ansible_tower` を使用している場合は、データベースの順序を使用するため、クラウドベースのインベントリースクリプトを使用している場合でも、これは問題になりません)。" - -#: ../../rst/reference_appendices/faq.rst:466 -msgid "Anyway, here's the trick:" -msgstr "以下に方法を示します。" - -#: ../../rst/reference_appendices/faq.rst:472 -msgid "Notice how we're pulling out the hostname of the first machine of the webservers group. If you are doing this in a template, you could use the Jinja2 '#set' directive to simplify this, or in a playbook, you could also use set_fact::" -msgstr "webserver グループの最初のマシンのホスト名を取得している点に注意してください。テンプレートでこれを実行する場合は、Jinja2 '#set' ディレクティブを使用して簡素化するか、Playbook の場合は set_fact を使用することも可能です。" - -#: ../../rst/reference_appendices/faq.rst:479 -msgid "Notice how we interchanged the bracket syntax for dots -- that can be done anywhere." -msgstr "ドットの代わりに括弧の構文を使用している点に注意してください。これはどこでも使用できます。" - -#: ../../rst/reference_appendices/faq.rst:484 -msgid "How do I copy files recursively onto a target host?" -msgstr "ターゲットホストにファイルを再帰的にコピーするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:486 -msgid "The ``copy`` module has a recursive parameter. However, take a look at the ``synchronize`` module if you want to do something more efficient for a large number of files. The ``synchronize`` module wraps rsync. See the module index for info on both of these modules." -msgstr "``copy`` モジュールには再帰的なパラメーターがありますが、多数のファイルにより効率的な場合は、``synchronize`` モジュールを参照してください。``synchronize`` モジュールは rsync をラップします。これらの両方のモジュールの情報は、モジュールインデックスを参照してください。" - -#: ../../rst/reference_appendices/faq.rst:492 -msgid "How do I access shell environment variables?" -msgstr "shell 環境変数にアクセスするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:495 -msgid "**On controller machine :** Access existing variables from controller use the ``env`` lookup plugin. For example, to access the value of the HOME environment variable on the management machine::" -msgstr "**コントローラーマシンの場合:** コントローラーから既存の変数にアクセスするには、``env`` lookup プラグインを使用します。たとえば、管理マシンで HOME 環境変数の値にアクセスするには、以下を指定します。" - -#: ../../rst/reference_appendices/faq.rst:504 -msgid "**On target machines :** Environment variables are available via facts in the ``ansible_env`` variable:" -msgstr "**ターゲットマシン:** 環境変数の場合には、``ansible_env`` 変数のファクトを使用して入手します。" - -#: ../../rst/reference_appendices/faq.rst:510 -msgid "If you need to set environment variables for TASK execution, see :ref:`playbooks_environment` in the :ref:`Advanced Playbooks ` section. There are several ways to set environment variables on your target machines. You can use the :ref:`template `, :ref:`replace `, or :ref:`lineinfile ` modules to introduce environment variables into files. The exact files to edit vary depending on your OS and distribution and local configuration." -msgstr "タスクを実行するために環境変数を設定する必要がある場合は、:ref:`詳細な Playbook ` セクションの「:ref:`playbooks_environment`」を参照してください。ターゲットマシンで環境変数を設定するには、いくつかの方法があります。:ref:`template ` モジュール、:ref:`replace ` モジュール、または :ref:`lineinfile ` モジュールを使用して、環境変数をファイルに取り込むことができます。編集するファイルは、OS、ディストリビューション、およびローカル設定によって異なります。" - -#: ../../rst/reference_appendices/faq.rst:520 -msgid "How do I generate encrypted passwords for the user module?" -msgstr "ユーザーモジュールの暗号化パスワードを生成するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:522 -msgid "Ansible ad hoc command is the easiest option:" -msgstr "Ansible ad-hoc コマンドを使用するのが最も簡単なオプションです。" - -#: ../../rst/reference_appendices/faq.rst:528 -msgid "The ``mkpasswd`` utility that is available on most Linux systems is also a great option:" -msgstr "ほとんどの Linux システムで利用できる ``mkpasswd`` ユーティリティーも優れたオプションです。" - -#: ../../rst/reference_appendices/faq.rst:535 -msgid "If this utility is not installed on your system (for example, you are using macOS) then you can still easily generate these passwords using Python. First, ensure that the `Passlib `_ password hashing library is installed:" -msgstr "お使いのシステムにこのユーティリティーがインストールされていない場合 (例: MacOS を使用している場合など) には、Python を使用してこのようなパスワードを簡単に生成できます。まず、`Passlib `_ パスワードハッシュライブラリーがインストールされていることを確認します。" - -#: ../../rst/reference_appendices/faq.rst:543 -msgid "Once the library is ready, SHA512 password values can then be generated as follows:" -msgstr "ライブラリーの準備ができたら、以下のように SHA512 パスワードの値を生成できます。" - -#: ../../rst/reference_appendices/faq.rst:549 -msgid "Use the integrated :ref:`hash_filters` to generate a hashed version of a password. You shouldn't put plaintext passwords in your playbook or host_vars; instead, use :ref:`playbooks_vault` to encrypt sensitive data." -msgstr "統合された :ref:`hash_filters` を使用して、ハッシュ化されたパスワードを生成します。Playbook や host_vars にプレーンテキストのパスワードは使用しないでください。代わりに、:ref:`playbooks_vault` を使用して、機密データを暗号化してください。" - -#: ../../rst/reference_appendices/faq.rst:552 -msgid "In OpenBSD, a similar option is available in the base system called ``encrypt (1)``" -msgstr "OpenBSDでは、``encrypt (1)`` と呼ばれるベースシステムで同様のオプションが利用可能です。" - -#: ../../rst/reference_appendices/faq.rst:557 -msgid "Ansible allows dot notation and array notation for variables. Which notation should I use?" -msgstr "Ansible では、変数のドット表記とアレイ表記が可能です。どの表記を使用する必要がありますか。" - -#: ../../rst/reference_appendices/faq.rst:559 -msgid "The dot notation comes from Jinja and works fine for variables without special characters. If your variable contains dots (.), colons (:), or dashes (-), if a key begins and ends with two underscores, or if a key uses any of the known public attributes, it is safer to use the array notation. See :ref:`playbooks_variables` for a list of the known public attributes." -msgstr "ドット表記は Jinja からのもので、特殊文字なしに変数と合わせて使用できます。変数にドット (.)、コロン (:)、またはハイフン (-) が含まれていて、キーが 2 つのアンダースコアで開始および終了する場合、またはキーが既知のパブリック属性のいずれかを使用する場合は、配列表記を使用する方が安全です。既知のパブリック属性の一覧は、「:ref:`playbooks_variables`」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:572 -msgid "Also array notation allows for dynamic variable composition, see dynamic_variables_." -msgstr "また、アレイ表記は、動的な変数の構成が可能です。詳細は、「dynamic_variables_」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:574 -msgid "Another problem with 'dot notation' is that some keys can cause problems because they collide with attributes and methods of python dictionaries." -msgstr "「ドット表記」の他の問題として、ドット表記のキーによっては、Python ディクショナリーの属性とメソッドと競合するため、問題が発生する可能性があります。" - -#: ../../rst/reference_appendices/faq.rst:585 -msgid "When is it unsafe to bulk-set task arguments from a variable?" -msgstr "変数からタスク引数の一括設定をすると安全でないのはどのような場合ですか" - -#: ../../rst/reference_appendices/faq.rst:588 -msgid "You can set all of a task's arguments from a dictionary-typed variable. This technique can be useful in some dynamic execution scenarios. However, it introduces a security risk. We do not recommend it, so Ansible issues a warning when you do something like this::" -msgstr "ディクショナリー型の変数からタスクの引数をすべて設定することができます。この手法は、動的な実行シナリオで便利な場合があります。ただし、セキュリティーリスクがあります。これは推奨されないため、このような操作を行うと、Ansible では警告を発行します。" - -#: ../../rst/reference_appendices/faq.rst:602 -msgid "This particular example is safe. However, constructing tasks like this is risky because the parameters and values passed to ``usermod_args`` could be overwritten by malicious values in the ``host facts`` on a compromised target machine. To mitigate this risk:" -msgstr "この特定の例は、安全です。ただし、``usermod_args`` に渡されるパラメーターや値が、セキュリティー侵害を受けたターゲットマシンの ``host facts`` に含まれる悪意のある値で置き換えられる可能性があるため、このようなタスクの構築にはリスクがあります。このリスクを軽減するには、以下を行います。" - -#: ../../rst/reference_appendices/faq.rst:607 -msgid "set bulk variables at a level of precedence greater than ``host facts`` in the order of precedence found in :ref:`ansible_variable_precedence` (the example above is safe because play vars take precedence over facts)" -msgstr ":ref:`ansible_variable_precedence` にある優先順位で、``host facts`` より優先順位の高いレベルで一括変数を設定します (プレイ変数はファクトより優先度が高いため、上記の例は安全です)。" - -#: ../../rst/reference_appendices/faq.rst:610 -msgid "disable the :ref:`inject_facts_as_vars` configuration setting to prevent fact values from colliding with variables (this will also disable the original warning)" -msgstr "ファクトの値が変数と競合しないように :ref:`inject_facts_as_vars` 設定オプションを無効にします (元の警告も無効になります)。" - -#: ../../rst/reference_appendices/faq.rst:617 -msgid "Can I get training on Ansible?" -msgstr "Ansible のトレーニングはありますか" - -#: ../../rst/reference_appendices/faq.rst:619 -msgid "Yes! See our `services page `_ for information on our services and training offerings. Email `info@ansible.com `_ for further details." -msgstr "サービスおよびトレーニングサービスに関する情報は、「`サービスページ `」を参照してください。詳細は、`info@ansible.com `_ にお問い合わせください。" - -#: ../../rst/reference_appendices/faq.rst:622 -msgid "We also offer free web-based training classes on a regular basis. See our `webinar page `_ for more info on upcoming webinars." -msgstr "また、定期的に、Web ベースのトレーニングも無料で提供しています。今後予定されているウェビナーの詳細は、`ウェビナーページ `_ を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:629 -msgid "Is there a web interface / REST API / GUI?" -msgstr "Web インターフェース、REST API、GUI などがありますか。" - -#: ../../rst/reference_appendices/faq.rst:631 -msgid "Yes! Ansible, Inc makes a great product that makes Ansible even more powerful and easy to use. See :ref:`ansible_tower`." -msgstr "Ansible, Inc は、Ansible がより強力で使いやすくなるように、優れた製品を提供しています。「:ref:`ansible_tower`」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:637 -msgid "How do I keep secret data in my playbook?" -msgstr "Playbook に機密データを保存するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:639 -msgid "If you would like to keep secret data in your Ansible content and still share it publicly or keep things in source control, see :ref:`playbooks_vault`." -msgstr "Ansible のコンテンツに機密データを保存してそのコンテンツを公開するか、ソースコントロールに保持する場合は、「:ref:`playbooks_vault`」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:641 -msgid "If you have a task that you don't want to show the results or command given to it when using -v (verbose) mode, the following task or playbook attribute can be useful::" -msgstr "-v (詳細) モードの使用時に、結果や指定したコマンドを表示したくないタスクがある場合は、次のようなタスクや Playbook 属性が便利です。" - -#: ../../rst/reference_appendices/faq.rst:647 -msgid "This can be used to keep verbose output but hide sensitive information from others who would otherwise like to be able to see the output." -msgstr "これは、詳細な出力を維持しつつ、出力を見たいと思っている人から機密情報を隠すために使うことができます。" - -#: ../../rst/reference_appendices/faq.rst:649 -msgid "The ``no_log`` attribute can also apply to an entire play::" -msgstr "``no_log`` 属性は、プレイ全体にも適用できます。" - -#: ../../rst/reference_appendices/faq.rst:654 -msgid "Though this will make the play somewhat difficult to debug. It's recommended that this be applied to single tasks only, once a playbook is completed. Note that the use of the ``no_log`` attribute does not prevent data from being shown when debugging Ansible itself via the :envvar:`ANSIBLE_DEBUG` environment variable." -msgstr "ただし、これを使用すると、プレイのデバッグが困難になります。Playbook が完了すると、この属性は単一のタスクにのみ適用することが推奨されます。``no_log`` 属性を使用しても、:envvar:`ANSIBLE_DEBUG` 環境変数で Ansible 自体をデバッグするときに、データが表示されてしまう点に注意してください。" - -#: ../../rst/reference_appendices/faq.rst:665 -msgid "When should I use {{ }}? Also, how to interpolate variables or dynamic variable names" -msgstr "{{ }} はいつ使用する必要がありますか。また、変数または動的な変数名を補間するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:667 -msgid "A steadfast rule is 'always use ``{{ }}`` except when ``when:``'. Conditionals are always run through Jinja2 as to resolve the expression, so ``when:``, ``failed_when:`` and ``changed_when:`` are always templated and you should avoid adding ``{{ }}``." -msgstr "不動のルールは「``when:`` の場合を除いて常に ``{{ }}`` を使用する」です。この条件は、式の解決として Jinja2 を介して実行するため、``when:``、``failed_when:``、および ``changed_when:`` は常にテンプレート化され、``{{ }}`` の追加は回避してください。" - -#: ../../rst/reference_appendices/faq.rst:671 -msgid "In most other cases you should always use the brackets, even if previously you could use variables without specifying (like ``loop`` or ``with_`` clauses), as this made it hard to distinguish between an undefined variable and a string." -msgstr "それ以外のケースでは、以前は ``loop`` 句または ``with_`` 句などを指定しなくても変数を使用できていた場合でも、常に括弧を使用するようにしてください。理由は、未定義の変数と文字列を区別しにくいためです。" - -#: ../../rst/reference_appendices/faq.rst:674 -msgid "Another rule is 'moustaches don't stack'. We often see this:" -msgstr "他には「波括弧は並べて使用できない」というルールがありますが、これは頻繁に見受けられます。" - -#: ../../rst/reference_appendices/faq.rst:680 -msgid "The above DOES NOT WORK as you expect, if you need to use a dynamic variable use the following as appropriate:" -msgstr "上記の例は想定通り、機能しません。動的変数を使用する必要がある場合には、随時、以下を使用してください。" - -#: ../../rst/reference_appendices/faq.rst:686 -msgid "For 'non host vars' you can use the :ref:`vars lookup` plugin:" -msgstr "「non host vars」の場合には、:ref:`vars lookup` プラグインを使用できます。" - -#: ../../rst/reference_appendices/faq.rst:696 -msgid "Why don't you ship ansible in wheel format (or other packaging format) ?" -msgstr "wheel 形式 (またはその他のパッケージ形式) で ansible が同梱されないのはなぜですか。" - -#: ../../rst/reference_appendices/faq.rst:698 -msgid "In most cases it has to do with maintainability. There are many ways to ship software and we do not have the resources to release Ansible on every platform. In some cases there are technical issues. For example, our dependencies are not present on Python Wheels." -msgstr "多くの場合に、メンテナンスができるかどうかに関係します。ソフトウェアを提供する方法は多数あり、全プラットフォームで Ansible をリリースするリソースがありません。場合によっては、技術的な問題があります。たとえば、Python Wheel には依存関係がありません。" - -#: ../../rst/reference_appendices/faq.rst:705 -msgid "How do I get the original ansible_host when I delegate a task?" -msgstr "タスクを委譲した場合に元の ansible_host をどのように取得すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:707 -msgid "As the documentation states, connection variables are taken from the ``delegate_to`` host so ``ansible_host`` is overwritten, but you can still access the original via ``hostvars``::" -msgstr "ドキュメントに記載されているように、接続変数は ``delegate_to`` ホストから取得されるため、``ansible_host`` は上書きされますが、``hostvars`` を使用して元の ansible_host にアクセスできます。" - -#: ../../rst/reference_appendices/faq.rst:712 -msgid "This works for all overridden connection variables, like ``ansible_user``, ``ansible_port``, and so on." -msgstr "これは、``ansible_user``、``ansible_port`` などのように、すべての上書きされた接続変数に有効です。" - -#: ../../rst/reference_appendices/faq.rst:718 -msgid "How do I fix 'protocol error: filename does not match request' when fetching a file?" -msgstr "ファイルの取得時の「protocol error: filename does not match request」のエラーはどのように修正すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:720 -msgid "Since release ``7.9p1`` of OpenSSH there is a `bug `_ in the SCP client that can trigger this error on the Ansible controller when using SCP as the file transfer mechanism::" -msgstr "OpenSSH のリリース ``7.9p1`` では、SCP クライアントに `bug `_ があり、ファイル転送メカニズムとして SCP を使用する場合に、Ansible コントローラーで以下のエラーが出力される可能性があります。" - -#: ../../rst/reference_appendices/faq.rst:725 -msgid "In these releases, SCP tries to validate that the path of the file to fetch matches the requested path. The validation fails if the remote filename requires quotes to escape spaces or non-ascii characters in its path. To avoid this error:" -msgstr "新しいリリースでは、SCP は、取得するファイルのパスが要求したパスと一致することを検証しようとします。リモートのファイル名が、パスでスペースや ASCII 文字以外の文字を引用符でエスケープする必要がある場合には、検証に失敗します。このエラーを回避するには、以下を行います。" - -#: ../../rst/reference_appendices/faq.rst:733 -msgid "Use SFTP instead of SCP by setting ``scp_if_ssh`` to ``smart`` (which tries SFTP first) or to ``False``. You can do this in one of four ways:" -msgstr "``scp_if_ssh`` を ``smart`` (先に SFTP を試す)、または ``False`` に設定して、SCP の代わりに SFTP を使用します。" - -#: ../../rst/reference_appendices/faq.rst:730 -msgid "Rely on the default setting, which is ``smart`` - this works if ``scp_if_ssh`` is not explicitly set anywhere" -msgstr "``smart`` のデフォルトの設定に依存します。``scp_if_ssh`` が明示的にどこにも設定されていない場合に機能します。" - -#: ../../rst/reference_appendices/faq.rst:731 -msgid "Set a :ref:`host variable ` or :ref:`group variable ` in inventory: ``ansible_scp_if_ssh: False``" -msgstr "インベントリーに :ref:`ホスト変数 ` または :ref:`グループ変数 ` を設定します (``ansible_scp_if_ssh: False``)。" - -#: ../../rst/reference_appendices/faq.rst:732 -msgid "Set an environment variable on your control node: ``export ANSIBLE_SCP_IF_SSH=False``" -msgstr "コントロールノードで環境変数を設定します (``export ANSIBLE_SCP_IF_SSH=False``)。" - -#: ../../rst/reference_appendices/faq.rst:733 -msgid "Pass an environment variable when you run Ansible: ``ANSIBLE_SCP_IF_SSH=smart ansible-playbook``" -msgstr "Ansible を実行するときに環境変数を渡します (``ANSIBLE_SCP_IF_SSH=smart ansible-playbook``)。" - -#: ../../rst/reference_appendices/faq.rst:734 -msgid "Modify your ``ansible.cfg`` file: add ``scp_if_ssh=False`` to the ``[ssh_connection]`` section" -msgstr "``ansible.cfg`` ファイルの変更: ``scp_if_ssh=False`` を ``[ssh_connection]`` セクションに追加します。" - -#: ../../rst/reference_appendices/faq.rst:738 -msgid "If you must use SCP, set the ``-T`` arg to tell the SCP client to ignore path validation. You can do this in one of three ways:" -msgstr "SCP を使用する必要がある場合は、``-T`` 引数を設定して、SCP クライアントにパスの検証を無視するように指示します。以下の 3 つの方法のいずれかで実行できます。" - -#: ../../rst/reference_appendices/faq.rst:736 -msgid "Set a :ref:`host variable ` or :ref:`group variable `: ``ansible_scp_extra_args=-T``," -msgstr ":ref:`ホスト変数 ` または :ref:`グループ変数 ` を設定します (``ansible_scp_extra_args=-T``)。" - -#: ../../rst/reference_appendices/faq.rst:737 -msgid "Export or pass an environment variable: ``ANSIBLE_SCP_EXTRA_ARGS=-T``" -msgstr "環境変数をエクスポートするか、渡します (``ANSIBLE_SCP_EXTRA_ARGS=-T``)。" - -#: ../../rst/reference_appendices/faq.rst:738 -msgid "Modify your ``ansible.cfg`` file: add ``scp_extra_args=-T`` to the ``[ssh_connection]`` section" -msgstr "``ansible.cfg`` ファイルの変更: ``scp_extra_args=-T`` を ``[ssh_connection]`` セクションに追加します。" - -#: ../../rst/reference_appendices/faq.rst:740 -msgid "If you see an ``invalid argument`` error when using ``-T``, then your SCP client is not performing filename validation and will not trigger this error." -msgstr "``-T`` の使用時に ``invalid argument`` エラーが表示される場合は、SCP クライアントがファイル名を検証しておらず、このエラーは発生しません。" - -#: ../../rst/reference_appendices/faq.rst:745 -msgid "Does Ansible support multiple factor authentication 2FA/MFA/biometrics/finterprint/usbkey/OTP/..." -msgstr "Ansible では、複数のファクター認証 2FA/MFA/biometrics/finterprint/usbkey/OTP/... がサポートされます。" - -#: ../../rst/reference_appendices/faq.rst:747 -msgid "No, Ansible is designed to execute multiple tasks against multiple targets, minimizing user interaction. As with most automation tools, it is not compatible with interactive security systems designed to handle human interaction. Most of these systems require a secondary prompt per target, which prevents scaling to thousands of targets. They also tend to have very short expiration periods so it requires frequent reauthorization, also an issue with many hosts and/or a long set of tasks." -msgstr "いいえ、Ansible は複数のターゲットに対して複数のタスクを実行するように設計されており、ユーザーの操作を最小限に抑えることができます。ほとんどの自動化ツールと同様に、人間の相互作用を処理するように設計されたインタラクティブなセキュリティーシステムとの互換性はありません。これらのシステムのほとんどは、ターゲットごとにセカンダリープロンプトを必要とするため、数千のターゲットに拡張することができません。また、これらのシステムは有効期限が非常に短いため、再認証が頻繁に必要となりますが、これも多くのホストや長いタスクセットでは問題となります。" - -#: ../../rst/reference_appendices/faq.rst:753 -msgid "In such environments we recommend securing around Ansible's execution but still allowing it to use an 'automation user' that does not require such measures. This is something that Tower/AWX excels at by allowing administrators to set up RBAC access to inventory, along with managing credentials and job execution." -msgstr "このような環境では、Ansible の実行を保護しながら、そのような手段を必要としない「自動化ユーザー」の使用を許可することが推奨されます。これが Tower/AWX の優れている点で、管理者がインベントリーへの RBAC アクセスを設定し、認証情報とジョブの実行を管理することができます。" - -#: ../../rst/reference_appendices/faq.rst:760 -msgid "How do I submit a change to the documentation?" -msgstr "ドキュメントへの変更を提出するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:762 -msgid "Documentation for Ansible is kept in the main project git repository, and complete instructions for contributing can be found in the docs README `viewable on GitHub `_. Thanks!" -msgstr "Ansible のドキュメントは、主要プロジェクトの git リポジトリーに保存されており、貢献に関する説明が `GitHub で確認できる `_ README に記載されています。" - -#: ../../rst/reference_appendices/faq.rst:768 -msgid "I don't see my question here" -msgstr "ここに記載されている以外に質問があります" - -#: ../../rst/reference_appendices/faq.rst:770 -msgid "Please see the section below for a link to IRC and the Google Group, where you can ask your question there." -msgstr "以下のセクションに、IRC および Google グループへのリンクがあります。こちらから、質問をしてください。" - -#: ../../rst/reference_appendices/faq.rst:775 -#: ../../rst/reference_appendices/glossary.rst:522 -#: ../../rst/reference_appendices/test_strategies.rst:268 -msgid "An introduction to playbooks" -msgstr "Playbook の概要" - -#: ../../rst/reference_appendices/faq.rst:776 -#: ../../rst/reference_appendices/glossary.rst:523 -msgid ":ref:`playbooks_best_practices`" -msgstr ":ref:`playbooks_best_practices`" - -#: ../../rst/reference_appendices/faq.rst:777 -#: ../../rst/reference_appendices/glossary.rst:524 -msgid "Tips and tricks for playbooks" -msgstr "Playbook のヒントと裏技" - -#: ../../rst/reference_appendices/faq.rst:778 -#: ../../rst/reference_appendices/test_strategies.rst:271 -msgid "`User Mailing List `_" -msgstr "`メーリングリストの使用 `_" - -#: ../../rst/reference_appendices/faq.rst:779 -#: ../../rst/reference_appendices/glossary.rst:526 -#: ../../rst/reference_appendices/test_strategies.rst:272 -msgid "Have a question? Stop by the google group!" -msgstr "ご質問はございますか。Google Group をご覧ください。" - -#: ../../rst/reference_appendices/general_precedence.rst:4 -msgid "Controlling how Ansible behaves: precedence rules" -msgstr "Ansible の動作の制御: 優先順位のルール" - -#: ../../rst/reference_appendices/general_precedence.rst:6 -msgid "To give you maximum flexibility in managing your environments, Ansible offers many ways to control how Ansible behaves: how it connects to managed nodes, how it works once it has connected. If you use Ansible to manage a large number of servers, network devices, and cloud resources, you may define Ansible behavior in several different places and pass that information to Ansible in several different ways. This flexibility is convenient, but it can backfire if you do not understand the precedence rules." -msgstr "Ansible には、環境の管理に最大限の柔軟性をもたせられるように、管理対象ノードへの接続方法や、接続後の動作など、Ansible の動作を制御する手段が多数あります。Ansible を使用して多数のサーバー、ネットワークデバイス、クラウドリソースを管理する場合に、Ansible の動作をさまざまな場所で定義して、さまざまな方法で Ansible にその情報を渡すことができます。柔軟性があると便利ですが、優先順位ルールを理解していない場合は、逆効果となる可能性があります。" - -#: ../../rst/reference_appendices/general_precedence.rst:10 -msgid "These precedence rules apply to any setting that can be defined in multiple ways (by configuration settings, command-line options, playbook keywords, variables)." -msgstr "このような優先順位ルールは、複数の方法で定義できるオプション (設定オプション、コマンドラインオプション、Playbook キーワード、変数) に適用されます。" - -#: ../../rst/reference_appendices/general_precedence.rst:16 -msgid "Precedence categories" -msgstr "優先順位のカテゴリー" - -#: ../../rst/reference_appendices/general_precedence.rst:18 -msgid "Ansible offers four sources for controlling its behavior. In order of precedence from lowest (most easily overridden) to highest (overrides all others), the categories are:" -msgstr "Ansible では、動作の制御に使用するソースが 4 つあります。カテゴリーは以下のとおりです (優先順位の低いもの、つまり最も簡単にオーバーライドされるものから、高いもの、つまり他のすべてをオーバーライドするものに並べています)。" - -#: ../../rst/reference_appendices/general_precedence.rst:20 -#: ../../rst/reference_appendices/general_precedence.rst:30 -msgid "Configuration settings" -msgstr "設定オプション" - -#: ../../rst/reference_appendices/general_precedence.rst:21 -#: ../../rst/reference_appendices/general_precedence.rst:42 -msgid "Command-line options" -msgstr "コマンドラインオプション" - -#: ../../rst/reference_appendices/general_precedence.rst:22 -#: ../../rst/reference_appendices/general_precedence.rst:61 -msgid "Playbook keywords" -msgstr "Playbook キーワード" - -#: ../../rst/reference_appendices/general_precedence.rst:25 -msgid "Each category overrides any information from all lower-precedence categories. For example, a playbook keyword will override any configuration setting." -msgstr "各カテゴリーは、そのカテゴリーよりも優先順位の低いカテゴリーからの情報をすべてオーバーライドします。たとえば、Playbook キーワードは、設定オプションをオーバーライドします。" - -#: ../../rst/reference_appendices/general_precedence.rst:27 -msgid "Within each precedence category, specific rules apply. However, generally speaking, 'last defined' wins and overrides any previous definitions." -msgstr "各優先順位カテゴリーで、固有のルールが適用されます。ただし、一般的に「最後に定義 (last defined)」した内容の優先度が高く、以前の定義をオーバーライドします。" - -#: ../../rst/reference_appendices/general_precedence.rst:32 -msgid ":ref:`Configuration settings` include both values from the ``ansible.cfg`` file and environment variables. Within this category, values set in configuration files have lower precedence. Ansible uses the first ``ansible.cfg`` file it finds, ignoring all others. Ansible searches for ``ansible.cfg`` in these locations in order:" -msgstr ":ref:`構成設定` には、``ansible.cfg`` ファイルと環境変数からの両方の値が含まれます。このカテゴリーでは、設定ファイルに指定した値のほうが優先順位が低くなります。Ansible では最初に見つかった ``ansible.cfg`` を使用し、他はすべて無視します。Ansible は、これらの場所で順番に ``ansible.cfg`` を選択します。" - -#: ../../rst/reference_appendices/general_precedence.rst:39 -msgid "Environment variables have a higher precedence than entries in ``ansible.cfg``. If you have environment variables set on your control node, they override the settings in whichever ``ansible.cfg`` file Ansible loads. The value of any given environment variable follows normal shell precedence: the last value defined overwrites previous values." -msgstr "環境変数は、``ansible.cfg`` のエントリーよりも優先されます。コントロールノードに環境変数を設定している場合には、Ansible が読み込む ``ansible.cfg`` ファイルの設定よりも、環境変数が優先されます。指定された環境変数の値は、shell の通常の優先順位 (最後に定義した値が、それ以前の値をオーバーライド) に準拠します。" - -#: ../../rst/reference_appendices/general_precedence.rst:44 -msgid "Any command-line option will override any configuration setting." -msgstr "コマンドラインオプションは、設定オプションをすべてオーバーライドします。" - -#: ../../rst/reference_appendices/general_precedence.rst:46 -msgid "When you type something directly at the command line, you may feel that your hand-crafted values should override all others, but Ansible does not work that way. Command-line options have low precedence - they override configuration only. They do not override playbook keywords, variables from inventory or variables from playbooks." -msgstr "コマンドラインに直接入力すると、手動で入力した値が、それ以外の設定をすべてオーバーライドするように感じますが、Ansible の仕様は異なります。コマンドラインオプションの優先順位は低いため、オーバーライドできるのは、設定のみです。Playbook のキーワードや、インベントリーからの変数、または Playbook から変数をオーバーライドすることはありません。" - -#: ../../rst/reference_appendices/general_precedence.rst:48 -msgid "You can override all other settings from all other sources in all other precedence categories at the command line by :ref:`general_precedence_extra_vars`, but that is not a command-line option, it is a way of passing a :ref:`variable`." -msgstr ":ref:`general_precedence_extra_vars` により、コマンドラインで、他の優先順位カテゴリーの他のソースからの他の設定をすべて上書きできます。ただし、これはコマンドラインオプションではなく、:ref:`variable` を渡す手段としてコマンドラインを使用しています。" - -#: ../../rst/reference_appendices/general_precedence.rst:50 -msgid "At the command line, if you pass multiple values for a parameter that accepts only a single value, the last defined value wins. For example, this :ref:`ad hoc task` will connect as ``carol``, not as ``mike``::" -msgstr "コマンドラインで、単値のみを受け入れるパラメーターに多値を渡すと、最後に定義された値が優先されます。たとえば、この :ref:`ad hoc task` は、``mike`` ではなく、``carol`` として接続します。" - -#: ../../rst/reference_appendices/general_precedence.rst:54 -msgid "Some parameters allow multiple values. In this case, Ansible will append all values from the hosts listed in inventory files inventory1 and inventory2::" -msgstr "パラメーターによっては、多値を使用できます。以下の場合には、Ansible は、インベントリーファイル「inventory1」および「inventory2」に記載されているホストからの値をすべて追加します。" - -#: ../../rst/reference_appendices/general_precedence.rst:58 -msgid "The help for each :ref:`command-line tool` lists available options for that tool." -msgstr "各 :ref:`コマンドラインツール` のヘルプは、対象のツールで利用可能なオプションを表示します。" - -#: ../../rst/reference_appendices/general_precedence.rst:63 -msgid "Any :ref:`playbook keyword` will override any command-line option and any configuration setting." -msgstr ":ref:`Playbook キーワード` は、コマンドラインオプションと、構成設定をすべてオーバーライドします。" - -#: ../../rst/reference_appendices/general_precedence.rst:65 -msgid "Within playbook keywords, precedence flows with the playbook itself; the more specific wins against the more general:" -msgstr "Playbook キーワード内の優先順位は、Playbook の内容により左右されます (一般的な設定より具体的な設定が優先されます)。" - -#: ../../rst/reference_appendices/general_precedence.rst:67 -msgid "play (most general)" -msgstr "プレイ (最も一般的)" - -#: ../../rst/reference_appendices/general_precedence.rst:68 -msgid "blocks/includes/imports/roles (optional and can contain tasks and each other)" -msgstr "blocks/includes/imports/roles (任意で、タスクを含めることも、相互に含めることも可能)" - -#: ../../rst/reference_appendices/general_precedence.rst:69 -msgid "tasks (most specific)" -msgstr "タスク (最も具体的)" - -#: ../../rst/reference_appendices/general_precedence.rst:71 -msgid "A simple example::" -msgstr "簡単な例::" - -#: ../../rst/reference_appendices/general_precedence.rst:83 -msgid "In this example, the ``connection`` keyword is set to ``ssh`` at the play level. The first task inherits that value, and connects using ``ssh``. The second task inherits that value, overrides it, and connects using ``paramiko``. The same logic applies to blocks and roles as well. All tasks, blocks, and roles within a play inherit play-level keywords; any task, block, or role can override any keyword by defining a different value for that keyword within the task, block, or role." -msgstr "この例では、``connection`` キーワードはプレイレベルで ``ssh`` に設定されています。最初のタスクはその値を継承し、``ssh`` を使用して接続します。2 番目のタスクは、その値を継承してオーバーライドし、``paramiko`` を使用して接続します。block や role でも同じロジックが適用されます。プレイ内の task、block、role はすべて、プレイレベルのキーワードを継承します。キーワードより task または block、role を優先させるには、task、block、role 内の対象のキーワードに異なる値を定義します。" - -#: ../../rst/reference_appendices/general_precedence.rst:86 -msgid "Remember that these are KEYWORDS, not variables. Both playbooks and variable files are defined in YAML but they have different significance. Playbooks are the command or 'state description' structure for Ansible, variables are data we use to help make playbooks more dynamic." -msgstr "上記は、変数ではなく、キーワードである点に注意してください。Playbook や変数ファイルはいずれも YAML で定義しますが、それぞれ重要性が異なります。Playbook はコマンドまたは Ansible の「状態記述」構造で、変数は Playbook をより動的に使用できるようにするためのデータです。" - -#: ../../rst/reference_appendices/general_precedence.rst:94 -msgid "Any variable will override any playbook keyword, any command-line option, and any configuration setting." -msgstr "変数は、Playbook のキーワード、コマンドラインオプション、構成設定をすべてオーバーライドします。" - -#: ../../rst/reference_appendices/general_precedence.rst:96 -msgid "Variables that have equivalent playbook keywords, command-line options, and configuration settings are known as :ref:`connection_variables`. Originally designed for connection parameters, this category has expanded to include other core variables like the temporary directory and the python interpreter." -msgstr "同等の Playbook キーワード、コマンドラインオプション、および構成設定を含む変数は :ref:`connection_variables` と呼ばれています。このカテゴリーは、当初は設定パラメーター向けに設計されてましたが、一時ディレクトリーや Python インタープリターなど、他のコア変数を含めるように拡張されました。" - -#: ../../rst/reference_appendices/general_precedence.rst:98 -msgid "Connection variables, like all variables, can be set in multiple ways and places. You can define variables for hosts and groups in :ref:`inventory`. You can define variables for tasks and plays in ``vars:`` blocks in :ref:`playbooks`. However, they are still variables - they are data, not keywords or configuration settings. Variables that override playbook keywords, command-line options, and configuration settings follow the same rules of :ref:`variable precedence ` as any other variables." -msgstr "接続変数はすべての変数と同様、複数の手法や場所で設定できます。:ref:`インベントリー` でホストとグループの変数を定義できます。:ref:`Playbook` の ``vars:`` ブロックに、タスクとプレイの変数を定義できます。ただし、上記は、キーワードや構成設定ではなく、データを格納する変数です。Playbook キーワード、コマンドラインオプション、および設定オプションをオーバーライドする変数は、他の変数が使用する :ref:`変数の優先順位 ` と同じルールに従います。" - -#: ../../rst/reference_appendices/general_precedence.rst:100 -msgid "When set in a playbook, variables follow the same inheritance rules as playbook keywords. You can set a value for the play, then override it in a task, block, or role::" -msgstr "変数は、Playbook に設定されると、Playbook キーワードと同じ継承ルールに従います。プレイの値を設定すると、タスク、ブロック、またはロールの値をオーバーライドできます。" - -#: ../../rst/reference_appendices/general_precedence.rst:125 -msgid "Variable scope: how long is a value available?" -msgstr "変数の範囲: 値が有効な期間" - -#: ../../rst/reference_appendices/general_precedence.rst:127 -msgid "Variable values set in a playbook exist only within the playbook object that defines them. These 'playbook object scope' variables are not available to subsequent objects, including other plays." -msgstr "Playbook に設定した変数の値は、その値を定義する Playbook オブジェクト内にのみ存在します。このような「Playbook オブジェクトの範囲」の変数は、他のプレイなど、後続のオブジェクトでは利用できません。" - -#: ../../rst/reference_appendices/general_precedence.rst:129 -msgid "Variable values associated directly with a host or group, including variables defined in inventory, by vars plugins, or using modules like :ref:`set_fact` and :ref:`include_vars`, are available to all plays. These 'host scope' variables are also available via the ``hostvars[]`` dictionary." -msgstr "インベントリー、vars プラグイン、:ref:`set_fact` や :ref:`include_vars` といったモジュールの使用など、ホストやグループに直接関連付けられた変数値は、全プレイで利用できます。また、これらの「ホスト範囲」変数は、``hostvars[]`` ディクショナリーから利用できます。" - -#: ../../rst/reference_appendices/general_precedence.rst:134 -msgid "Using ``-e`` extra variables at the command line" -msgstr "コマンドラインでの追加変数 (``-e``) の使用" - -#: ../../rst/reference_appendices/general_precedence.rst:136 -msgid "To override all other settings in all other categories, you can use extra variables: ``--extra-vars`` or ``-e`` at the command line. Values passed with ``-e`` are variables, not command-line options, and they will override configuration settings, command-line options, and playbook keywords as well as variables set elsewhere. For example, this task will connect as ``brian`` not as ``carol``::" -msgstr "他のカテゴリーの全設定をオーバーライドするには、コマンドラインで追加変数 (``--extra-vars`` または ``-e``) を使用します。``-e`` で渡される値は、コマンドラインオプションではなく変数で、他で設定した変数をはじめ、構成設定、コマンドラインオプション、Playbook キーワードをオーバーライドします。たとえば、このタスクは、``carol`` ではなく ``brian`` として接続します。" - -#: ../../rst/reference_appendices/general_precedence.rst:140 -msgid "You must specify both the variable name and the value with ``--extra-vars``." -msgstr "変数名と値は、``--extra-vars`` で指定する必要があります。" - -#: ../../rst/reference_appendices/glossary.rst:2 -msgid "Glossary" -msgstr "用語集" - -#: ../../rst/reference_appendices/glossary.rst:4 -msgid "The following is a list (and re-explanation) of term definitions used elsewhere in the Ansible documentation." -msgstr "以下は、Ansible ドキュメントの各所で使用される用語の定義 (と再説) 一覧です。" - -#: ../../rst/reference_appendices/glossary.rst:6 -msgid "Consult the documentation home page for the full documentation and to see the terms in context, but this should be a good resource to check your knowledge of Ansible's components and understand how they fit together. It's something you might wish to read for review or when a term comes up on the mailing list." -msgstr "全ドキュメント、および文中で用語を確認するには、ドキュメントのホームページを参照してください。このページは、Ansible のコンポーネントの説明を読み、どのように組み合わされているかを理解するのに適しています。レビューのために、またはメーリングリストで用語が使用された時などにご利用になれます。" - -#: ../../rst/reference_appendices/glossary.rst:11 -msgid "Action" -msgstr "アクション" - -#: ../../rst/reference_appendices/glossary.rst:13 -msgid "An action is a part of a task that specifies which of the modules to run and which arguments to pass to that module. Each task can have only one action, but it may also have other parameters." -msgstr "アクションはタスクの一部を指し、実行するモジュールや、そのモジュールが渡す引数を指定します。各タスクには、アクションを 1 つだけ指定できますが、他に複数のパラメーターが指定されている可能性があります。" - -#: ../../rst/reference_appendices/glossary.rst:16 -msgid "Ad Hoc" -msgstr "アドホック" - -#: ../../rst/reference_appendices/glossary.rst:18 -msgid "Refers to running Ansible to perform some quick command, using :command:`/usr/bin/ansible`, rather than the :term:`orchestration` language, which is :command:`/usr/bin/ansible-playbook`. An example of an ad hoc command might be rebooting 50 machines in your infrastructure. Anything you can do ad hoc can be accomplished by writing a :term:`playbook ` and playbooks can also glue lots of other operations together." -msgstr "Ansible を実行して、:command:`/usr/bin/ansible-playbook` の :term:`オーケストレーション` 言語ではなく、:command:`/usr/bin/ansible` を使用してクイックコマンドを実行することを指します。アドホックコマンドの例には、インフラストラクチャー内での 50 台のマシンを再起動することなどが含まれます。アドホックに実行できるすべてのことは :term:`playbook ` を作成して実行でき、Playbook は数多くの他の操作を 1 つにまとめることができます。" - -#: ../../rst/reference_appendices/glossary.rst:25 -msgid "Ansible (the package)" -msgstr "Ansible (パッケージ)" - -#: ../../rst/reference_appendices/glossary.rst:27 -msgid "A software package (Python, deb, rpm, and so on) that contains ansible-base and a select group of collections. Playbooks that worked with Ansible 2.9 should still work with the Ansible 2.10 package. See the :file:`ansible-.build` file in the release-specific directory at `ansible-build-data `_ for a list of collections included in Ansible, as well as the included ``ansible-base`` version." -msgstr "ansible-base および選択したコレクショングループを含むソフトウェアパッケージ (Python、deb、rpm など)。Ansible 2.9 で動作した Playbook は、Ansible 2.10 パッケージでも動作するはずです。Ansible に含まれているコレクションのリストと同梱されている ``ansible-base`` バージョンについては、`ansible-build-data `_ のリリース固有のディレクトリーにある :file:`ansible-.build` ファイルを参照してください。" - -#: ../../rst/reference_appendices/glossary.rst:28 -msgid "ansible-base" -msgstr "ansible-base" - -#: ../../rst/reference_appendices/glossary.rst:30 -msgid "New for 2.10. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository `_. Contains the command-line tools and the code for basic features and functions, such as copying module code to managed nodes. The ``ansible-base`` package includes a few modules and plugins and allows you to add others by installing collections." -msgstr "2.10 の新機能。`ansible/ansible リポジトリー `_ から生成されるインストール可能なパッケージ (RPM/Python/Deb パッケージ)。コマンドラインツールと、基本的な機能と関数 (モジュールコードの管理対象ノードへのコピーなど) のコードが含まれています。``ansible-base`` パッケージにはいくつかのモジュールとプラグインが含まれており、コレクションをインストールすることで他のモジュールを追加できます。" - -#: ../../rst/reference_appendices/glossary.rst:31 -msgid "Ansible Galaxy" -msgstr "Ansible Galaxy" - -#: ../../rst/reference_appendices/glossary.rst:33 -msgid "An `online resource `_ for finding and sharing Ansible community content. Also, the command-line utility that lets users install individual Ansible Collections, for example`` ansible-galaxy install community.crypto``." -msgstr "Ansible コミュニティーのコンテンツを見つけて共有するための `オンラインリソース `_。また、ユーザーが個々の Ansible コレクションをインストールできるようにするコマンドラインユーティリティー (`` ansible-galaxy install community.crypto`` など)。" - -#: ../../rst/reference_appendices/glossary.rst:34 -msgid "Async" -msgstr "非同期" - -#: ../../rst/reference_appendices/glossary.rst:36 -msgid "Refers to a task that is configured to run in the background rather than waiting for completion. If you have a long process that would run longer than the SSH timeout, it would make sense to launch that task in async mode. Async modes can poll for completion every so many seconds or can be configured to \"fire and forget\", in which case Ansible will not even check on the task again; it will just kick it off and proceed to future steps. Async modes work with both :command:`/usr/bin/ansible` and :command:`/usr/bin/ansible-playbook`." -msgstr "完了を待たずにバックグラウンドで実行するように構成されたタスクを指します。SSH タイムアウトよりも長く実行される長いプロセスがある場合は、そのタスクを非同期モードで起動することは理にかなっています。非同期モードでは、何秒かごとに完了をポーリングすることも、「ファイアアンドフォーゲット (自動追尾機能)」ように設定することもできます。その場合、Ansible は再度タスクをチェックしません。起動して次のステップに進みます。非同期モードは :command:`/usr/bin/ansible` と :command:`/usr/bin/ansible-playbook` の両方で動作します。" - -#: ../../rst/reference_appendices/glossary.rst:44 -msgid "Callback Plugin" -msgstr "Callback プラグイン" - -#: ../../rst/reference_appendices/glossary.rst:46 -msgid "Refers to some user-written code that can intercept results from Ansible and do something with them. Some supplied examples in the GitHub project perform custom logging, send email, or even play sound effects." -msgstr "Ansible からの結果を傍受でき、それらについて何らかの処理を行うユーザー作成コードを指します。GitHub プロジェクトで提供されている一部のサンプルの実行内容には、カスタムロギングやメール送信、さらにはサウンド効果のプレイなどが含まれます。" - -#: ../../rst/reference_appendices/glossary.rst:50 -msgid "Check Mode" -msgstr "Check Mode (チェックモード)" - -#: ../../rst/reference_appendices/glossary.rst:52 -msgid "Refers to running Ansible with the ``--check`` option, which does not make any changes on the remote systems, but only outputs the changes that might occur if the command ran without this flag. This is analogous to so-called \"dry run\" modes in other systems, though the user should be warned that this does not take into account unexpected command failures or cascade effects (which is true of similar modes in other systems). Use this to get an idea of what might happen, but do not substitute it for a good staging environment." -msgstr "``--check`` オプションを指定して Ansible を実行することを指します。このオプションを選択してもリモートシステムに変更は加えられることはなく、コマンドがこのフラグなしに実行された場合に生じる可能性のある変更のみを出力します。これは、他のシステムでのいわゆる「ドライラン」モードに類似しています。ただし、この場合は予期しないコマンドの失敗やカスケード効果が考慮されないことに注意してください (他のシステムの同様のモードについても同じです)。このモードを使用すると、起こり得ることの概要を把握することはできますが、これが適切なステージング環境の代わりになる訳ではありません。" - -#: ../../rst/reference_appendices/glossary.rst:60 -msgid "Collection" -msgstr "コレクション" - -#: ../../rst/reference_appendices/glossary.rst:62 -msgid "A packaging format for bundling and distributing Ansible content, including plugins, roles, modules, and more. Collections release independent of other collections or ``ansible-base`` so features can be available sooner to users. Some collections are packaged with Ansible (version 2.10 or later). You can install other collections (or other versions of collections) with ``ansible-galaxy collection install ``." -msgstr "プラグイン、ロール、モジュールなどを含む Ansible コンテンツをバンドルして配布するためのパッケージングフォーマット。コレクションは他のコレクションまたは ``ansible-base`` とは独立してリリースされるため、ユーザーはより早く機能を利用できます。一部のコレクションは Ansible (バージョン 2.10 以降) でパッケージ化されています。他のコレクション (またはコレクションの他のバージョン) は、``ansible-galaxy collection install `` でインストールできます。" - -#: ../../rst/reference_appendices/glossary.rst:63 -msgid "Collection name" -msgstr "コレクション名" - -#: ../../rst/reference_appendices/glossary.rst:65 -msgid "The second part of a Fully Qualified Collection Name. The collection name divides the collection namespace and usually reflects the function of the collection content. For example, the ``cisco`` namespace might contain ``cisco.ios``, ``cisco.aci``, and ``cisco.nxos``, with content for managing the different network devices maintained by Cisco." -msgstr "完全修飾コレクション名の 2 番目の部分。コレクション名は、コレクションの名前空間を分割し、通常はコレクションの内容の機能を反映します。たとえば、``cisco`` 名前空間には、``cisco.ios``、``cisco.aci``、および ``cisco.nxos`` が含まれ、シスコが管理するさまざまなネットワークデバイスを管理するためのコンテンツが含まれます。" - -#: ../../rst/reference_appendices/glossary.rst:66 -msgid "community.general (collection)" -msgstr "community.general (コレクション)" - -#: ../../rst/reference_appendices/glossary.rst:68 -msgid "A special collection managed by the Ansible Community Team containing all the modules and plugins which shipped in Ansible 2.9 that do ont have their own dedicated Collection. See `community.general `_` on Galaxy." -msgstr "Ansible 2.9 に同梱された、専用のコレクションを持たないすべてのモジュールとプラグインを含む Ansible Community Team が管理する特定のコレクション。Galaxy の「`community.general `_`」を参照してください。" - -#: ../../rst/reference_appendices/glossary.rst:69 -msgid "community.network (collection)" -msgstr "community.network (コレクション)" - -#: ../../rst/reference_appendices/glossary.rst:71 -msgid "Similar to ``community.general``, focusing on network content. `community.network `_` on Galaxy." -msgstr "``community.general`` と同様に、ネットワークコンテンツに焦点を宛てています (Galaxy の `community.network `_')。" - -#: ../../rst/reference_appendices/glossary.rst:72 -msgid "Connection Plugin" -msgstr "Connection プラグイン" - -#: ../../rst/reference_appendices/glossary.rst:74 -msgid "By default, Ansible talks to remote machines through pluggable libraries. Ansible uses native OpenSSH (:term:`SSH (Native)`) or a Python implementation called :term:`paramiko`. OpenSSH is preferred if you are using a recent version, and also enables some features like Kerberos and jump hosts. This is covered in the :ref:`getting started section `. There are also other connection types like ``accelerate`` mode, which must be bootstrapped over one of the SSH-based connection types but is very fast, and local mode, which acts on the local system. Users can also write their own connection plugins." -msgstr "デフォルトでは、Ansible はプラグ可能なライブラリーを介してリモートマシンと対話します。Ansible はネイティブの OpenSSH (:term:`SSH (Native)`) や、:term:`paramiko` と呼ばれる Python の実装を使用します。最新バージョンを使用している場合は OpenSSH が推奨され、Kerberos やジャンプホストなどの一部の機能も有効になります。これについては、「:ref:`getting started section `」で説明します。他にも ``accelerate`` モードのような接続タイプがあります。これは SSH ベースの接続タイプのうちのひとつを使用して起動しなければなりませんが、非常に高速です。また、ローカルシステム上で動作するローカルモードもあります。ユーザーは独自の connection プラグインを記述することもできます。" - -#: ../../rst/reference_appendices/glossary.rst:84 -msgid "Conditionals" -msgstr "条件 (Conditional)" - -#: ../../rst/reference_appendices/glossary.rst:86 -msgid "A conditional is an expression that evaluates to true or false that decides whether a given task is executed on a given machine or not. Ansible's conditionals are powered by the 'when' statement, which are discussed in the :ref:`working_with_playbooks`." -msgstr "条件は、True または False に評価して、指定のタスクを所定のマシンで実行するかどうかを決定する式のことです。Ansible の条件文は、「when」ステートメントによって強化されています。「:ref:`working_with_playbooks`」を参照してください。" - -#: ../../rst/reference_appendices/glossary.rst:90 -msgid "Declarative" -msgstr "宣言的 (Declarative)" - -#: ../../rst/reference_appendices/glossary.rst:92 -msgid "An approach to achieving a task that uses a description of the final state rather than a description of the sequence of steps necessary to achieve that state. For a real world example, a declarative specification of a task would be: \"put me in California\". Depending on your current location, the sequence of steps to get you to California may vary, and if you are already in California, nothing at all needs to be done. Ansible's Resources are declarative; it figures out the steps needed to achieve the final state. It also lets you know whether or not any steps needed to be taken to get to the final state." -msgstr "あるタスクを達成するために、その状態を達成するために必要な一連の手順を記述するのではなく、最終的な状態を記述するアプローチのこと。現実世界の例では、「私をカリフォルニアに連れて行ってください」というタスクの宣言的な指定があります。あなたの現在地によって、あなたをカリフォルニアに連れて行くための一連のステップは異なるかもしれないし、あなたがすでにカリフォルニアにいる場合は、何もする必要はありません。Ansible の Resource は宣言型で、最終的な状態を実現するために必要なステップを把握しています。また、最終的な状態に到達するために必要なステップがあるかどうかも知ることができます。" - -#: ../../rst/reference_appendices/glossary.rst:102 -msgid "Diff Mode" -msgstr "差分モード" - -#: ../../rst/reference_appendices/glossary.rst:104 -msgid "A ``--diff`` flag can be passed to Ansible to show what changed on modules that support it. You can combine it with ``--check`` to get a good 'dry run'. File diffs are normally in unified diff format." -msgstr "``--diff`` フラグを Ansible に渡して、それをサポートするモジュールで何が変更されたかを示すことができます。``--check`` と組み合わせると優れた「ドライラン」を得ることができます。ファイルの差分は通常、統一された差分形式です。" - -#: ../../rst/reference_appendices/glossary.rst:107 -msgid "Executor" -msgstr "エグゼキューター (Executor)" - -#: ../../rst/reference_appendices/glossary.rst:109 -msgid "A core software component of Ansible that is the power behind :command:`/usr/bin/ansible` directly -- and corresponds to the invocation of each task in a :term:`playbook `. The Executor is something Ansible developers may talk about, but it's not really user land vocabulary." -msgstr "Ansible の中核となるソフトウェアコンポーネントで、:command:`/usr/bin/ansible` を直接支える力であり、:term:`playbook ` の各タスクの呼び出しに対応しています。エグゼキューターは、Ansible の開発者が使用する用語で、ユーザー側が使用する用語ではありません。" - -#: ../../rst/reference_appendices/glossary.rst:114 -#: ../../rst/reference_appendices/special_variables.rst:134 -msgid "Facts" -msgstr "ファクト" - -#: ../../rst/reference_appendices/glossary.rst:116 -msgid "Facts are simply things that are discovered about remote nodes. While they can be used in :term:`playbooks` and templates just like variables, facts are things that are inferred, rather than set. Facts are automatically discovered by Ansible when running plays by executing the internal :ref:`setup module ` on the remote nodes. You never have to call the setup module explicitly, it just runs, but it can be disabled to save time if it is not needed or you can tell ansible to collect only a subset of the full facts via the ``gather_subset:`` option. For the convenience of users who are switching from other configuration management systems, the fact module will also pull in facts from the :program:`ohai` and :program:`facter` tools if they are installed. These are fact libraries from Chef and Puppet, respectively. (These may also be disabled via ``gather_subset:``)" -msgstr "端的に言うと、ファクトはリモートノードについて発見される事柄を指します。ファクトは変数のように :term:`playbooks` やテンプレートで使用できますが、ファクトは設定される事柄というよりは推測される事柄と言えます。ファクトは、リモートノードで内部 :ref:`セットアップモジュール ` を実行することでプレイの実行中に Ansible により自動的に検出されるため、セットアップモジュールを明示的に呼び出すはありません。それはただ実行されます。その必要がなければ時間を節約するために無効にすることもできますし、``gather_subset:`` オプションで全ファクトのサブセットだけを収集するように Ansible に指示することもできます。他の設定管理システムから切り替えを行われている場合の利点として、ファクトモジュールは、Chef と Puppet のファクトライブラリーから、それぞれ :program:`ohai` ツールおよび :program:`facter` ツールからも (インストールされている場合) ファクトを取り込みます (これは ``gather_subset:`` で無効にすることもできます)。" - -#: ../../rst/reference_appendices/glossary.rst:130 -msgid "Filter Plugin" -msgstr "Filter プラグイン" - -#: ../../rst/reference_appendices/glossary.rst:132 -msgid "A filter plugin is something that most users will never need to understand. These allow for the creation of new :term:`Jinja2` filters, which are more or less only of use to people who know what Jinja2 filters are. If you need them, you can learn how to write them in the :ref:`API docs section `." -msgstr "filter プラグインは、ほとんどのユーザーが理解する必要がないものです。この filter プラグインは、新しい :term:`Jinja2` フィルターを作成するためのもので、多かれ少なかれ、Jinja2 のフィルターを知っている人にしか使えません。必要であれば、:ref:`API ドキュメントのセクション ` で記述方法を参照してください。" - -#: ../../rst/reference_appendices/glossary.rst:137 -msgid "Forks" -msgstr "フォーク" - -#: ../../rst/reference_appendices/glossary.rst:139 -msgid "Ansible talks to remote nodes in parallel and the level of parallelism can be set either by passing ``--forks`` or editing the default in a configuration file. The default is a very conservative five (5) forks, though if you have a lot of RAM, you can easily set this to a value like 50 for increased parallelism." -msgstr "Ansible は、複数のリモートノードと同時に対話でき、その並列処理のレベルは、``--forks`` を渡すか、設定ファイルのデフォルトを編集することで設定できます。デフォルトには非常に控え目に 5 つのフォークが設定されていますが、RAM が多数ある場合は、並列処理のレベルを上げるために値を大きく (50 など) 設定することもできます。" - -#: ../../rst/reference_appendices/glossary.rst:144 -msgid "Fully Qualified Collection Name (FQCN)" -msgstr "FQCN (完全修飾コレクション名)" - -#: ../../rst/reference_appendices/glossary.rst:146 -msgid "The full definition of a module, plugin, or role hosted within a collection, in the form . Allows a Playbook to refer to a specific module or plugin from a specific source in an unambiguous manner, for example, ``community.grafana.grafana_dashboard``. The FQCN is required when you want to specify the exact source of a plugin. For example, if multiple collections contain a module plugin called ``user``, the FQCN specifies which one to use for a given task. When you have multiple collections installed, the FQCN is always the explicit and authoritative indicator of which collection to search for the correct plugin for each task." -msgstr "コレクション内でホストされているモジュール、プラグイン、またはロールの完全な定義を のような形で示します。Playbook が特定のソースから特定のモジュールまたはプラグインを曖昧さのない方法で参照できるようにします (たとえば、``community.grafana.grafana_dashboard`` です)。FQCN は、プラグインの正確なソースを指定したい場合に必要です。たとえば、複数のコレクションに ``user`` という名前の module プラグインが含まれている場合、FQCN は特定のタスクにどのプラグインを使用するかを指定します。複数のコレクションがインストールされている場合、FQCN は常に、各タスクに適したプラグインをどのコレクションで検索するかを明示的かつ権威的に示します。" - -#: ../../rst/reference_appendices/glossary.rst:147 -msgid "Gather Facts (Boolean)" -msgstr "ファクトの収集 (ブール値)" - -#: ../../rst/reference_appendices/glossary.rst:149 -msgid ":term:`Facts` are mentioned above. Sometimes when running a multi-play :term:`playbook `, it is desirable to have some plays that don't bother with fact computation if they aren't going to need to utilize any of these values. Setting ``gather_facts: False`` on a playbook allows this implicit fact gathering to be skipped." -msgstr ":term:`Facts` は上述のとおりです。マルチプレイ (:term:`playbook `) を実行する際に、これらの値を利用する必要がない場合は、ファクト計算を行わないプレイをいくつか用意することが望ましい場合があります。Playbook に ``gather_facts: False`` を設定すると、この暗黙のファクト収集を省略することができます。" - -#: ../../rst/reference_appendices/glossary.rst:154 -msgid "Globbing" -msgstr "グラッビング (Globbing)" - -#: ../../rst/reference_appendices/glossary.rst:156 -msgid "Globbing is a way to select lots of hosts based on wildcards, rather than the name of the host specifically, or the name of the group they are in. For instance, it is possible to select ``ww*`` to match all hosts starting with ``www``. This concept is pulled directly from :program:`Func`, one of Michael DeHaan's (an Ansible Founder) earlier projects. In addition to basic globbing, various set operations are also possible, such as 'hosts in this group and not in another group', and so on." -msgstr "グラッビングとは、特定のホスト名や所属するグループ名ではなく、ワイルドカードに基づいて多数のホストを選択する方法です。たとえば ``ww*`` を選択すると、``www`` で始まるすべてのホストに一致させることができます。この概念は、Ansible の創始者である Michael DeHaan 氏の初期のプロジェクトの 1 つである :program:`Func` から直接引用しています。基本的なグラッビングに加えて、「このグループに含まれ、他のグループには含まれないホスト」など、さまざまなセット操作が可能です。" - -#: ../../rst/reference_appendices/glossary.rst:164 -msgid "Group" -msgstr "グループ" - -#: ../../rst/reference_appendices/glossary.rst:166 -msgid "A group consists of several hosts assigned to a pool that can be conveniently targeted together, as well as given variables that they share in common." -msgstr "グループは、プールに割り当てられた複数のホストで構成されます。これらのホストは、一緒に対象に設定でき、それらが共通して共有する特定の変数です。" - -#: ../../rst/reference_appendices/glossary.rst:169 -msgid "Group Vars" -msgstr "グループ変数" - -#: ../../rst/reference_appendices/glossary.rst:171 -msgid "The :file:`group_vars/` files are files that live in a directory alongside an inventory file, with an optional filename named after each group. This is a convenient place to put variables that are provided to a given group, especially complex data structures, so that these variables do not have to be embedded in the :term:`inventory` file or :term:`playbook `." -msgstr ":file:`group_vars/` ファイルは、各グループに由来する任意のファイル名で、インベントリーファイルと共にディレクトリーに存在するファイルのことです。このファイルは、特にデータ構造が複雑な場合などに、所定グループに提供される変数を配置できる便利な場所になります。これにより、これらの変数が :term:`inventory` ファイルまたは :term:`playbook ` に埋め込む必要がなくなります。" - -#: ../../rst/reference_appendices/glossary.rst:177 -msgid "Handlers" -msgstr "ハンドラー" - -#: ../../rst/reference_appendices/glossary.rst:179 -msgid "Handlers are just like regular tasks in an Ansible :term:`playbook ` (see :term:`Tasks`) but are only run if the Task contains a ``notify`` directive and also indicates that it changed something. For example, if a config file is changed, then the task referencing the config file templating operation may notify a service restart handler. This means services can be bounced only if they need to be restarted. Handlers can be used for things other than service restarts, but service restarts are the most common usage." -msgstr "ハンドラーは Ansible :term:`playbook ` の通常のタスクのような機能を持ちます(「:term:`タスク`」を参照) が、タスクに ``notify`` ディレクティブがあり、変更があったことが示唆される場合にのみ実行されます。たとえば、設定ファイルが変更された後に、設定ファイルを参照するテンプレート作成操作のタスクは、サービス再起動ハンドラーに通知する可能性があります。これは、サービスが再起動する必要がある場合にのみバウンスできることを意味します。ハンドラーはサービスの再起動以外のタスクに使用できますが、サービスの再起動が最も一般的な使用例になります。" - -#: ../../rst/reference_appendices/glossary.rst:187 -msgid "Host" -msgstr "ホスト" - -#: ../../rst/reference_appendices/glossary.rst:189 -msgid "A host is simply a remote machine that Ansible manages. They can have individual variables assigned to them, and can also be organized in groups. All hosts have a name they can be reached at (which is either an IP address or a domain name) and, optionally, a port number, if they are not to be accessed on the default SSH port." -msgstr "ホストとは、Ansible が管理するリモートマシンのことです。ホストには、個別に変数を割り当てることも、グループでまとめることもできます。すべてのホストには、アクセス可能な名前 (IP アドレスまたはドメイン名) と、デフォルトの SSH ポートでアクセスしない場合は、任意でポート番号が割り当てられます。" - -#: ../../rst/reference_appendices/glossary.rst:194 -msgid "Host Specifier" -msgstr "ホスト指定子" - -#: ../../rst/reference_appendices/glossary.rst:196 -msgid "Each :term:`Play ` in Ansible maps a series of :term:`tasks` (which define the role, purpose, or orders of a system) to a set of systems." -msgstr "Ansible の各 :term:`プレイ ` は、一連の :term:`タスク` (システムのロール、目的、または順序を定義します) を一連のシステムにマッピングします。" - -#: ../../rst/reference_appendices/glossary.rst:199 -msgid "This ``hosts:`` directive in each play is often called the hosts specifier." -msgstr "各プレイの ``hosts:`` ディレクティブは、しばしばホスト指定子と呼ばれます。" - -#: ../../rst/reference_appendices/glossary.rst:201 -msgid "It may select one system, many systems, one or more groups, or even some hosts that are in one group and explicitly not in another." -msgstr "1 つのシステム、多数のシステム、1 つ以上のグループ、または 1 つのグループにあり明示的に別のグループにはない複数のホストを選択することができます。" - -#: ../../rst/reference_appendices/glossary.rst:203 -msgid "Host Vars" -msgstr "ホスト変数" - -#: ../../rst/reference_appendices/glossary.rst:205 -msgid "Just like :term:`Group Vars`, a directory alongside the inventory file named :file:`host_vars/` can contain a file named after each hostname in the inventory file, in :term:`YAML` format. This provides a convenient place to assign variables to the host without having to embed them in the :term:`inventory` file. The Host Vars file can also be used to define complex data structures that can't be represented in the inventory file." -msgstr ":term:`Group Vars` のように、インベントリーファイルの横にある :file:`host_vars/` ディレクトリーには、インベントリーファイルの各ホスト名にちなんで :term:`YAML` 形式のファイルを置くことができます。これは、:term:`inventory` ファイルに変数を埋め込まなくても、ホストに変数を割り当てるための便利な場所となります。ホストの vars ファイルは、インベントリーファイルでは表現できない複雑なデータ構造を定義するのにも使用できます。" - -#: ../../rst/reference_appendices/glossary.rst:211 -msgid "Idempotency" -msgstr "冪等性" - -#: ../../rst/reference_appendices/glossary.rst:213 -msgid "An operation is idempotent if the result of performing it once is exactly the same as the result of performing it repeatedly without any intervening actions." -msgstr "操作を 1 回実行した結果が、何も介入せずに繰り返し実行した結果とまったく同じであれば、操作は冪等です。" - -#: ../../rst/reference_appendices/glossary.rst:216 -msgid "Includes" -msgstr "インクルード (Include)" - -#: ../../rst/reference_appendices/glossary.rst:218 -msgid "The idea that :term:`playbook ` files (which are nothing more than lists of :term:`plays`) can include other lists of plays, and task lists can externalize lists of :term:`tasks` in other files, and similarly with :term:`handlers`. Includes can be parameterized, which means that the loaded file can pass variables. For instance, an included play for setting up a WordPress blog may take a parameter called ``user`` and that play could be included more than once to create a blog for both ``alice`` and ``bob``." -msgstr ":term:`playbook ` のファイル (これは :term:`plays` のリストに他ならない) は、他のプレイリストを含むことができ、タスクリストは他のファイルの :term:`tasks` のリストを具体化することができ、:term:`handlers` でも同様となるという考え方です。インクルードはパラメーター化できるため、読み込まれたファイルは変数を渡すことができます。たとえば、WordPress ブログをセットアップするためのインクルードプレイは、``user`` というパラメーターを取り、そのプレイを複数回インクルードすることで、``alice`` と ``bob`` の両方にブログを作成することができます。" - -#: ../../rst/reference_appendices/glossary.rst:226 -msgid "Inventory" -msgstr "インベントリー" - -#: ../../rst/reference_appendices/glossary.rst:228 -msgid "A file (by default, Ansible uses a simple INI format) that describes :term:`Hosts ` and :term:`Groups ` in Ansible. Inventory can also be provided via an :term:`Inventory Script` (sometimes called an \"External Inventory Script\")." -msgstr "Ansible で :term:`ホスト ` と :term:`グループ ` を記述したファイル (デフォルトでは、Ansible は簡単な INI 形式を使用)。インベントリーは、:term:`Inventory Script` (「外部インベントリースクリプト」と呼ばれることもあります) を介して提供することもできます。" - -#: ../../rst/reference_appendices/glossary.rst:232 -msgid "Inventory Script" -msgstr "インベントリースクリプト" - -#: ../../rst/reference_appendices/glossary.rst:234 -msgid "A very simple program (or a complicated one) that looks up :term:`hosts `, :term:`group` membership for hosts, and variable information from an external resource -- whether that be a SQL database, a CMDB solution, or something like LDAP. This concept was adapted from Puppet (where it is called an \"External Nodes Classifier\") and works more or less exactly the same way." -msgstr ":term:`ホスト `、ホストの :term:`グループ` メンバーシップ、および変数情報を、SQL データベース、CMDB ソリューションまたは LDAP に類する外部リソースから参照する非常に簡単なプログラム (または複雑なプログラム) のことです。この概念は Puppet (「外部ノード分類子」と呼ばれています) から採用されたもので、ほぼ同じように機能します。" - -#: ../../rst/reference_appendices/glossary.rst:240 -msgid "Jinja2" -msgstr "Jinja2" - -#: ../../rst/reference_appendices/glossary.rst:242 -msgid "Jinja2 is the preferred templating language of Ansible's template module. It is a very simple Python template language that is generally readable and easy to write." -msgstr "Jinja2 は、Ansible のテンプレートモジュールで推奨されるテンプレート言語です。これは非常にシンプルな Python テンプレート言語であり、一般的に読みやすく、簡単に記述できます。" - -#: ../../rst/reference_appendices/glossary.rst:245 -msgid "JSON" -msgstr "JSON" - -#: ../../rst/reference_appendices/glossary.rst:247 -msgid "Ansible uses JSON for return data from remote modules. This allows modules to be written in any language, not just Python." -msgstr "Ansible はリモートモジュールから返されるデータに JSON を使用します。モジュールは Python だけではなくすべての言語で作成することができます。" - -#: ../../rst/reference_appendices/glossary.rst:249 -msgid "Lazy Evaluation" -msgstr "遅延評価" - -#: ../../rst/reference_appendices/glossary.rst:251 -msgid "In general, Ansible evaluates any variables in :term:`playbook ` content at the last possible second, which means that if you define a data structure that data structure itself can define variable values within it, and everything \"just works\" as you would expect. This also means variable strings can include other variables inside of those strings." -msgstr "一般的に Ansible は、:term:`playbook ` のコンテンツに含まれるすべての変数を可能な限り最後の瞬間に評価します。つまり、データ構造を定義した場合、そのデータ構造自体がその中に変数値を定義することができ、すべてが期待通りに「ただ動く」のです。これは、変数文字列が、その文字列内に他の変数を含むことができることも意味します。" - -#: ../../rst/reference_appendices/glossary.rst:257 -msgid "Library" -msgstr "ライブラリー" - -#: ../../rst/reference_appendices/glossary.rst:259 -msgid "A collection of modules made available to :command:`/usr/bin/ansible` or an Ansible :term:`playbook `." -msgstr ":command:`/usr/bin/ansible` または Ansible :term:`playbook ` で利用できるようになったモジュールのコレクション。" - -#: ../../rst/reference_appendices/glossary.rst:261 -msgid "Limit Groups" -msgstr "グループの制限" - -#: ../../rst/reference_appendices/glossary.rst:263 -msgid "By passing ``--limit somegroup`` to :command:`ansible` or :command:`ansible-playbook`, the commands can be limited to a subset of :term:`hosts `. For instance, this can be used to run a :term:`playbook ` that normally targets an entire set of servers to one particular server." -msgstr "``--limit somegroup`` を :command:`ansible` または :command:`ansible-playbook` に渡すことで、コマンドを :term:`hosts ` のサブセットに限定することができます。たとえば、通常はサーバーのセット全体を対象としている :term:`playbook ` を、特定のサーバーに向けて実行する場合に使用できます。" - -#: ../../rst/reference_appendices/glossary.rst:268 -msgid "Local Action" -msgstr "ローカルアクション" - -#: ../../rst/reference_appendices/glossary.rst:270 -msgid "A local_action directive in a :term:`playbook ` targeting remote machines means that the given step will actually occur on the local machine, but that the variable ``{{ ansible_hostname }}`` can be passed in to reference the remote hostname being referred to in that step. This can be used to trigger, for example, an rsync operation." -msgstr "リモートマシンを対象とした :term:`playbook ` の local_action ディレクティブは、指定した手順が実際にはローカルマシン上で実行されるが、そのステップで参照されるリモートホスト名を参照するために変数 ``{{ ansible_hostname }}`` を渡すことができることを意味します。これを利用して、たとえば rsync の操作を行うことができます。" - -#: ../../rst/reference_appendices/glossary.rst:275 -msgid "Local Connection" -msgstr "ローカル接続" - -#: ../../rst/reference_appendices/glossary.rst:277 -msgid "By using ``connection: local`` in a :term:`playbook `, or passing ``-c local`` to :command:`/usr/bin/ansible`, this indicates that we are managing the local host and not a remote machine." -msgstr ":term:`playbook ` で ``connection: local`` を使用するか、``-c local`` を :command:`/usr/bin/ansible` に渡した場合は、リモートホストではなくローカルホストを管理していることを示しています。" - -#: ../../rst/reference_appendices/glossary.rst:280 -msgid "Lookup Plugin" -msgstr "Lookup プラグイン" - -#: ../../rst/reference_appendices/glossary.rst:282 -msgid "A lookup plugin is a way to get data into Ansible from the outside world. Lookup plugins are an extension of Jinja2 and can be accessed in templates, for example, ``{{ lookup('file','/path/to/file') }}``. These are how such things as ``with_items``, are implemented. There are also lookup plugins like ``file`` which loads data from a file and ones for querying environment variables, DNS text records, or key value stores." -msgstr "Lookup プラグインとは、外部から Ansible にデータを取り込むための方法です。Lookup プラグインは Jinja2 の拡張機能で、``{{ lookup('file','/path/to/file') }}`` などのテンプレートでアクセスできます。``with_items`` のようなものがこれらによって実装されています。Lookup プラグインには、``file`` のようにファイルからデータを読み込むものや、環境変数や DNS のテキストレコード、キーバリューストアなどを照会するものもあります。" - -#: ../../rst/reference_appendices/glossary.rst:289 -msgid "Loops" -msgstr "ループ" - -#: ../../rst/reference_appendices/glossary.rst:291 -msgid "Generally, Ansible is not a programming language. It prefers to be more declarative, though various constructs like ``loop`` allow a particular task to be repeated for multiple items in a list. Certain modules, like :ref:`yum ` and :ref:`apt `, actually take lists directly, and can install all packages given in those lists within a single transaction, dramatically speeding up total time to configuration, so they can be used without loops." -msgstr "一般的に、Ansible はプログラミング言語ではありません。しかし、``loop`` のような様々な構造によって、リストの複数のアイテムに対して特定のタスクを繰り返すことができます。:ref:`yum ` や:ref:`apt ` などのモジュールは、実際にリストを直接受け取り、それらのリストで指定されたすべてのパッケージを 1 つのトランザクション内でインストールすることができ、設定にかかる時間を劇的に短縮することができます。したがってループを使用せずに使用できます。" - -#: ../../rst/reference_appendices/glossary.rst:298 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/reference_appendices/glossary.rst:300 -msgid "Modules are the units of work that Ansible ships out to remote machines. Modules are kicked off by either :command:`/usr/bin/ansible` or :command:`/usr/bin/ansible-playbook` (where multiple tasks use lots of different modules in conjunction). Modules can be implemented in any language, including Perl, Bash, or Ruby -- but can leverage some useful communal library code if written in Python. Modules just have to return :term:`JSON`. Once modules are executed on remote machines, they are removed, so no long running daemons are used. Ansible refers to the collection of available modules as a :term:`library`." -msgstr "モジュールは、Ansible がリモートマシンに送出する作業単位です。モジュールは、:command:`/usr/bin/ansible` か :command:`/usr/bin/ansible-playbook` (複数のタスクが多数の異なるモジュールを組み合わせて使用する場合) のいずれかで起動します。モジュールは、Perl、Bash、Ruby を含む任意の言語で実装できますが、Python で記述されている場合は、いくつかの有用な共通ライブラリーコードを利用できます。モジュールは :term:`JSON` を返せば十分です。モジュールがリモートマシン上で実行すると、それらは削除されるため、実行中のデーモンは使用されません。Ansible は、利用可能なモジュールの集合を :term:`library` として参照します。" - -#: ../../rst/reference_appendices/glossary.rst:310 -msgid "Multi-Tier" -msgstr "多層" - -#: ../../rst/reference_appendices/glossary.rst:312 -msgid "The concept that IT systems are not managed one system at a time, but by interactions between multiple systems and groups of systems in well defined orders. For instance, a web server may need to be updated before a database server and pieces on the web server may need to be updated after *THAT* database server and various load balancers and monitoring servers may need to be contacted. Ansible models entire IT topologies and workflows rather than looking at configuration from a \"one system at a time\" perspective." -msgstr "IT システムは、一度に 1 つのシステムではなく、複数のシステムとシステムのグループ間の相互作用によって、明確に定義された順序で管理されるという概念。たとえば、データベースサーバーの前に Web サーバーを更新する必要があり、*その* データベースサーバーとさまざまなロードバランサーおよび監視サーバーに接続する必要がある場合は、Web サーバー上の部分を更新する必要があります。Ansible は、「一度に 1 つのシステム」の観点から構成を検討するのではなく、IT トポロジーとワークフロー全体をモデル化します。" - -#: ../../rst/reference_appendices/glossary.rst:320 -msgid "Namespace" -msgstr "名前空間" - -#: ../../rst/reference_appendices/glossary.rst:322 -msgid "The first part of a fully qualified collection name, the namespace usually reflects a functional content category. Example: in ``cisco.ios.ios_config``, ``cisco`` is the namespace. Namespaces are reserved and distributed by Red Hat at Red Hat's discretion. Many, but not all, namespaces will correspond with vendor names. See `Galaxy namespaces `_ on the Galaxy docsite for namespace requirements." -msgstr "完全修飾コレクション名の最初の部分で、名前空間は通常、機能的なコンテンツカテゴリーを反映しています。たとえば、``cisco.ios.ios_config`` では、``cisco`` が名前空間になります。名前空間は Red Hat によって予約され、Red Hat の裁量で配布されます。すべてではありませんが、多くの名前空間はベンダーの名前に対応しています。名前空間の要件については、Galaxy ドキュメントサイトの「`Galaxy 名前空間 `_」を参照してください。" - -#: ../../rst/reference_appendices/glossary.rst:323 -msgid "Notify" -msgstr "Notify (通知)" - -#: ../../rst/reference_appendices/glossary.rst:325 -msgid "The act of a :term:`task ` registering a change event and informing a :term:`handler ` task that another :term:`action` needs to be run at the end of the :term:`play `. If a handler is notified by multiple tasks, it will still be run only once. Handlers are run in the order they are listed, not in the order that they are notified." -msgstr "変更イベントを登録し、:term:`ハンドラー ` タスクに :term:`プレイ ` の終了時に別の :term:`操作` の実行が必要であることを知らせる :term:`タスク ` の行為です。ハンドラーが複数のタスクによる通知を受けても、ハンドラーは 1 回のみ実行されます。ハンドラーは、それらが通知を受けた順番ではなく、一覧表示された順に実行されます。" - -#: ../../rst/reference_appendices/glossary.rst:331 -msgid "Orchestration" -msgstr "オーケストレーション" - -#: ../../rst/reference_appendices/glossary.rst:333 -msgid "Many software automation systems use this word to mean different things. Ansible uses it as a conductor would conduct an orchestra. A datacenter or cloud architecture is full of many systems, playing many parts -- web servers, database servers, maybe load balancers, monitoring systems, continuous integration systems, and so on. In performing any process, it is necessary to touch systems in particular orders, often to simulate rolling updates or to deploy software correctly. Some system may perform some steps, then others, then previous systems already processed may need to perform more steps. Along the way, emails may need to be sent or web services contacted. Ansible orchestration is all about modeling that kind of process." -msgstr "多くのソフトウェア自動化システムでは、この言葉をさまざまな意味で使用しています。Ansible は、この言葉を「指揮者がオーケストラを指揮する」という意味で使用しています。データセンターやクラウドのアーキテクチャには、Web サーバー、データベースサーバー、ロードバランサー、監視システム、継続的統合システムなど、多くのシステムが存在し、さまざまな役割を担っています。プロセスを実行する際には、特定の順序でシステムに触れる必要があります。これは、ローリングアップデートをシミュレートしたり、ソフトウェアを正しくデプロイするためです。あるシステムがいくつかのステップを実行し、次に他のシステムを実行し、すでに処理された前のシステムがさらにステップを実行する必要があるかもしれません。その過程で、メールの送信や Web サービスへの問い合わせが必要になることもあります。Ansible のオーケストレーションは、このようなプロセスをモデル化するためのものです。" - -#: ../../rst/reference_appendices/glossary.rst:344 -msgid "paramiko" -msgstr "Paramiko" - -#: ../../rst/reference_appendices/glossary.rst:346 -msgid "By default, Ansible manages machines over SSH. The library that Ansible uses by default to do this is a Python-powered library called paramiko. The paramiko library is generally fast and easy to manage, though users who want to use Kerberos or Jump Hosts may wish to switch to a native SSH binary such as OpenSSH by specifying the connection type in their :term:`playbooks`, or using the ``-c ssh`` flag." -msgstr "デフォルトでは、Ansible は SSH でマシンを管理します。Ansible がこれを行うためにデフォルトで使用しているのは、paramiko という名前の Python を使用したライブラリーです。paramiko ライブラリーは一般的に高速で管理も簡単ですが、Kerberos や Jump Host を使いたい場合は、:term:`playbooks` で接続タイプを指定するか、``-c ssh`` フラグを使用して OpenSSH などのネイティブな SSH バイナリーに切り替えたほうがいいでしょう。" - -#: ../../rst/reference_appendices/glossary.rst:352 -msgid "Playbooks" -msgstr "Playbook" - -#: ../../rst/reference_appendices/glossary.rst:354 -msgid "Playbooks are the language by which Ansible orchestrates, configures, administers, or deploys systems. They are called playbooks partially because it's a sports analogy, and it's supposed to be fun using them. They aren't workbooks :)" -msgstr "Playbook は、Ansible がシステムのオーケストレーション、設定、管理、またはデプロイするための言語です。これが Playbook と呼ばれるのは、ある種スポーツに似ており、それを使用することで楽しめるからです。したがって、ワークブックではありません。" - -#: ../../rst/reference_appendices/glossary.rst:358 -msgid "Plays" -msgstr "プレイ" - -#: ../../rst/reference_appendices/glossary.rst:360 -msgid "A :term:`playbook ` is a list of plays. A play is minimally a mapping between a set of :term:`hosts ` selected by a host specifier (usually chosen by :term:`groups ` but sometimes by hostname :term:`globs `) and the :term:`tasks` which run on those hosts to define the role that those systems will perform. There can be one or many plays in a playbook." -msgstr ":term:`playbook ` はプレイのリストです。最小単位のプレイのマッピングは、ホスト指定子で選択される :term:`ホスト ` のセット (通常は :term:`グループ ` で選択されますが、ホスト名 :term:`globs ` で選択されることもある) と、システムが実行するロールを定義するためにホストで実行される :term:`タスク` 間のマッピングです。Playbook には 1 つまたは数多くのプレイが含まれる場合があります。" - -#: ../../rst/reference_appendices/glossary.rst:366 -msgid "Pull Mode" -msgstr "プルモード" - -#: ../../rst/reference_appendices/glossary.rst:368 -msgid "By default, Ansible runs in :term:`push mode`, which allows it very fine-grained control over when it talks to each system. Pull mode is provided for when you would rather have nodes check in every N minutes on a particular schedule. It uses a program called :command:`ansible-pull` and can also be set up (or reconfigured) using a push-mode :term:`playbook `. Most Ansible users use push mode, but pull mode is included for variety and the sake of having choices." -msgstr "デフォルトでは、Ansible は :term:`push mode` で実行します。これにより、各システムと対話するタイミングを非常に細かく制御することができます。また、特定のスケジュールで N 分ごとにノードをチェックしたい場合は、プルモードが用意されています。これには :command:`ansible-pull` というプログラムを使用します。また、プッシュモード :term:`playbook ` を使用して設定 (または再設定) することもできます。ほとんどの Ansible ユーザーはプッシュモードを使用していますが、多様性と選択肢を持たせるためにプルモードも含まれています。" - -#: ../../rst/reference_appendices/glossary.rst:377 -msgid ":command:`ansible-pull` works by checking configuration orders out of git on a crontab and then managing the machine locally, using the :term:`local connection` plugin." -msgstr ":command:`ansible-pull` は、crontab で git から設定順序を確認し、:term:`local connection` プラグインを使用してマシンをローカルで管理することで機能します。" - -#: ../../rst/reference_appendices/glossary.rst:380 -msgid "Push Mode" -msgstr "プッシュモード" - -#: ../../rst/reference_appendices/glossary.rst:382 -msgid "Push mode is the default mode of Ansible. In fact, it's not really a mode at all -- it's just how Ansible works when you aren't thinking about it. Push mode allows Ansible to be fine-grained and conduct nodes through complex orchestration processes without waiting for them to check in." -msgstr "プッシュモードは、Ansible のデフォルトモードです。実際には、モードというよりも、意識していないときに Ansible がどのように動作するかを示すものです。プッシュモードでは、Ansible を細かく設定することができ、複雑なオーケストレーションプロセスでもノードのチェックインを待たずに実行することができます。" - -#: ../../rst/reference_appendices/glossary.rst:387 -msgid "Register Variable" -msgstr "登録変数" - -#: ../../rst/reference_appendices/glossary.rst:389 -msgid "The result of running any :term:`task ` in Ansible can be stored in a variable for use in a template or a conditional statement. The keyword used to define the variable is called ``register``, taking its name from the idea of registers in assembly programming (though Ansible will never feel like assembly programming). There are an infinite number of variable names you can use for registration." -msgstr "Ansible で :term:`task ` を実行した結果を変数に格納し、テンプレートや条件文で使用することができます。変数の定義に使用されるキーワードは ``register`` と呼ばれ、その名前はアセンブリープログラミングにおけるレジスターの考え方に由来しています (ただし、Ansible がアセンブリープログラミングのように感じることはありません)。登録に使用できる変数名は無限にあります。" - -#: ../../rst/reference_appendices/glossary.rst:395 -msgid "Resource Model" -msgstr "リソースモデル" - -#: ../../rst/reference_appendices/glossary.rst:397 -msgid "Ansible modules work in terms of resources. For instance, the :ref:`file module ` will select a particular file and ensure that the attributes of that resource match a particular model. As an example, we might wish to change the owner of :file:`/etc/motd` to ``root`` if it is not already set to ``root``, or set its mode to ``0644`` if it is not already set to ``0644``. The resource models are :term:`idempotent ` meaning change commands are not run unless needed, and Ansible will bring the system back to a desired state regardless of the actual state -- rather than you having to tell it how to get to the state." -msgstr "Ansible モジュールは、リソースの観点から動作します。たとえば、:ref:`file module ` は、特定のファイルを選択し、そのリソースの属性が特定のモデルと一致することを確認します。たとえば、:file:`/etc/motd` の所有者が ``root`` に設定されていなければ ``root`` に変更し、そのモードが ``0644`` に設定されていなければ ``0644`` に設定したいとします。リソースモデルは :term:`idempotent `、つまり変更コマンドは必要な時以外は実行されず、Ansibl eは、実際の状態に関わらず、システムを望ましい状態に戻してくれますが、その状態になるための方法を指示する必要はありません。" - -#: ../../rst/reference_appendices/glossary.rst:407 -msgid "Roles" -msgstr "ロール" - -#: ../../rst/reference_appendices/glossary.rst:409 -msgid "Roles are units of organization in Ansible. Assigning a role to a group of :term:`hosts ` (or a set of :term:`groups `, or :term:`host patterns `, and so on) implies that they should implement a specific behavior. A role may include applying certain variable values, certain :term:`tasks`, and certain :term:`handlers` -- or just one or more of these things. Because of the file structure associated with a role, roles become redistributable units that allow you to share behavior among :term:`playbooks` -- or even with other users." -msgstr "ロールは Ansible における組織単位です。ロールを :term:`ホスト ` のグループ (または :term:`グループ ` または :term:`ホストパターン ` のセットなど) に割り当てることは、ホストのグループが特定の動作を実装することを意味します。ロールには特定の変数の値、特定の :term:`タスク`、特定の :term:`ハンドラー`、またはこれらの 1 つまたは複数を適用することが含まれます。ファイル構造がロールに関連付けられていることから、ロールは再配布可能な単位であり、これを使用して :term:`playbooks` 間または他のユーザーと動作を共有することができます。" - -#: ../../rst/reference_appendices/glossary.rst:417 -msgid "Rolling Update" -msgstr "ローリング更新" - -#: ../../rst/reference_appendices/glossary.rst:419 -msgid "The act of addressing a number of nodes in a group N at a time to avoid updating them all at once and bringing the system offline. For instance, in a web topology of 500 nodes handling very large volume, it may be reasonable to update 10 or 20 machines at a time, moving on to the next 10 or 20 when done. The ``serial:`` keyword in an Ansible :term:`playbooks` control the size of the rolling update pool. The default is to address the batch size all at once, so this is something that you must opt-in to. OS configuration (such as making sure config files are correct) does not typically have to use the rolling update model, but can do so if desired." -msgstr "一度にすべてのノードを更新してシステムがオフラインになるのを回避するために、グループ N 内のいくつかのノードに対して一度に処理する行為。たとえば、非常に大きなボリュームを扱う 500 台のノードからなる Web トポロジーでは、一度に 10 台または 20 台のマシンを更新し、更新が完了したら次の 10 台または 20 台に移るのが妥当な場合があります。Ansible :term:`playbook` の ``serial:`` キーワードは、ローリングアップデートプールのサイズを制御します。デフォルトでは、一度にバッチサイズに対応するようになっているため、これを選択する必要があります。OS の設定 (設定ファイルが正しいかどうかの確認など) では、通常、ローリング更新モデルを使用する必要はありませんが、必要に応じて使用することができます。" - -#: ../../rst/reference_appendices/glossary.rst:429 -msgid "Serial" -msgstr "シリアル" - -#: ../../rst/reference_appendices/glossary.rst:433 -msgid ":term:`Rolling Update`" -msgstr ":term:`Rolling Update`" - -#: ../../rst/reference_appendices/glossary.rst:434 -msgid "Sudo" -msgstr "Sudo" - -#: ../../rst/reference_appendices/glossary.rst:436 -msgid "Ansible does not require root logins, and since it's daemonless, definitely does not require root level daemons (which can be a security concern in sensitive environments). Ansible can log in and perform many operations wrapped in a sudo command, and can work with both password-less and password-based sudo. Some operations that don't normally work with sudo (like scp file transfer) can be achieved with Ansible's :ref:`copy `, :ref:`template `, and :ref:`fetch ` modules while running in sudo mode." -msgstr "Ansible では root ログインが不要であり、デーモンも不要のため、root レベルのデーモンも要求されません (これは機密環境ではセキュリティー上の懸念点となる可能性があります)。Ansible は sudo コマンドでログインでき、このコマンドでラップされた数多くの操作を実行でき、パスワードなしか、またはパスワードを使用する sudo で機能します。通常 sudo で機能しない操作 (scp ファイル転送など) については、sudo モードで実行中の Ansible の :ref:`copy `、:ref:`template `、および :ref:`fetch ` モジュールを使用して実行できます。" - -#: ../../rst/reference_appendices/glossary.rst:444 -msgid "SSH (Native)" -msgstr "SSH (ネイティブ)" - -#: ../../rst/reference_appendices/glossary.rst:446 -msgid "Native OpenSSH as an Ansible transport is specified with ``-c ssh`` (or a config file, or a directive in the :term:`playbook `) and can be useful if wanting to login via Kerberized SSH or using SSH jump hosts, and so on. In 1.2.1, ``ssh`` will be used by default if the OpenSSH binary on the control machine is sufficiently new. Previously, Ansible selected ``paramiko`` as a default. Using a client that supports ``ControlMaster`` and ``ControlPersist`` is recommended for maximum performance -- if you don't have that and don't need Kerberos, jump hosts, or other features, ``paramiko`` is a good choice. Ansible will warn you if it doesn't detect ControlMaster/ControlPersist capability." -msgstr "Ansible のトランスポートとしてのネイティブな OpenSSH は、``-c ssh`` (または設定ファイル、あるいは :term:`playbook ` のディレクティブ) で指定します。これは Kerberized SSH でログインしたい場合や、SSH ジャンプホストを使用したい場合などに便利です。1.2.1 では、コントロールマシン上の OpenSSH バイナリーが十分に新しい場合は、``ssh`` がデフォルトで使用されます。これまでの Ansible では、デフォルトで ``paramiko`` が選択されていました。最大限のパフォーマンスを得るためには、``ControlMaster`` および ``ControlPersist`` をサポートしているクライアントを使用することが推奨されています。もしそれがなく、Kerberos やジャンプホストなどの機能が不要な場合は、``paramiko`` を使用することが推奨されます。Ansible は、ControlMaster/ControlPersist 機能を検出できないと警告を発します。" - -#: ../../rst/reference_appendices/glossary.rst:457 -msgid "Tags" -msgstr "タグ" - -#: ../../rst/reference_appendices/glossary.rst:459 -msgid "Ansible allows tagging resources in a :term:`playbook ` with arbitrary keywords, and then running only the parts of the playbook that correspond to those keywords. For instance, it is possible to have an entire OS configuration, and have certain steps labeled ``ntp``, and then run just the ``ntp`` steps to reconfigure the time server information on a remote host." -msgstr "Ansible では、:term:`playbook ` 内のリソースに任意のキーワードをタグ付けし、そのキーワードに対応する Playbook の部分のみを実行することができます。たとえば、OS 全体の設定を行い、特定のステップにラベル ``ntp`` を付け、``ntp`` のステップだけを実行して、リモートホストのタイムサーバー情報を再設定することができます。" - -#: ../../rst/reference_appendices/glossary.rst:465 -#: ../../rst/reference_appendices/playbooks_keywords.rst:357 -msgid "Task" -msgstr "タスク" - -#: ../../rst/reference_appendices/glossary.rst:467 -msgid ":term:`Playbooks` exist to run tasks. Tasks combine an :term:`action` (a module and its arguments) with a name and optionally some other keywords (like :term:`looping directives `). :term:`Handlers` are also tasks, but they are a special kind of task that do not run unless they are notified by name when a task reports an underlying change on a remote system." -msgstr ":term:`Playbooks` はタスクを実行するために存在します。タスクは、:term:`action` (モジュールとその引数) と名前、そして (:term:`looping directives ` のような) その他の任意のキーワードを組み合わせたものです。:term:`Handlers` もタスクですが、これは特別な種類のタスクで、タスクがリモートシステム上で根本的な変更を報告したときに名前で通知されない限り実行されません。" - -#: ../../rst/reference_appendices/glossary.rst:473 -msgid "Tasks" -msgstr "タスク" - -#: ../../rst/reference_appendices/glossary.rst:475 -msgid "A list of :term:`Task`." -msgstr ":term:`タスク` の一覧です。" - -#: ../../rst/reference_appendices/glossary.rst:476 -msgid "Templates" -msgstr "テンプレート" - -#: ../../rst/reference_appendices/glossary.rst:478 -msgid "Ansible can easily transfer files to remote systems but often it is desirable to substitute variables in other files. Variables may come from the :term:`inventory` file, :term:`Host Vars`, :term:`Group Vars`, or :term:`Facts`. Templates use the :term:`Jinja2` template engine and can also include logical constructs like loops and if statements." -msgstr "Ansible は、ファイルをリモートシステムに簡単に転送できますが、他のファイルの変数を置き換えることが望ましい場合があります。変数は、:term:`inventory` ファイル、:term:`Host Vars`、:term:`Group Vars`、または :term:`Facts` から設定できます。テンプレートは、:term:`Jinja2` テンプレートエンジンを使用し、ループや if ステートメントなどの論理構造を含めることもできます。" - -#: ../../rst/reference_appendices/glossary.rst:484 -msgid "Transport" -msgstr "トランスポート" - -#: ../../rst/reference_appendices/glossary.rst:486 -msgid "Ansible uses :term:``Connection Plugins`` to define types of available transports. These are simply how Ansible will reach out to managed systems. Transports included are :term:`paramiko`, :term:`ssh ` (using OpenSSH), and :term:`local `." -msgstr "Ansible は :term:``Connection Plugins`` を使用して、利用可能なトランスポートの種類を定義します。これらは単に、Ansible が管理されたシステムに到達する方法です。含まれるトランスポートは、:term:`paramiko`、:term:`ssh ` (OpenSSH を使用)、および :term:`local ` です。" - -#: ../../rst/reference_appendices/glossary.rst:491 -msgid "When" -msgstr "When" - -#: ../../rst/reference_appendices/glossary.rst:493 -msgid "An optional conditional statement attached to a :term:`task ` that is used to determine if the task should run or not. If the expression following the ``when:`` keyword evaluates to false, the task will be ignored." -msgstr ":term:`task ` に付けられた任意の条件文で、タスクが実行されるべきかどうかを判断するために使用されます。``when:`` キーワードに続く式が false と評価された場合、そのタスクは無視されます。" - -#: ../../rst/reference_appendices/glossary.rst:496 -msgid "Vars (Variables)" -msgstr "変数" - -#: ../../rst/reference_appendices/glossary.rst:498 -msgid "As opposed to :term:`Facts`, variables are names of values (they can be simple scalar values -- integers, booleans, strings) or complex ones (dictionaries/hashes, lists) that can be used in templates and :term:`playbooks`. They are declared things, not things that are inferred from the remote system's current state or nature (which is what Facts are)." -msgstr ":term:`Facts` とは対照的に、変数は、テンプレートや :term:`playbooks` で使用できる値の名前 (整数、ブール値、文字列などの単純なスカラー値など) や複雑な名前 (辞書/ハッシュ、リスト) となります。これらは宣言されたものであり、リモートシステムの現在の状態や性質から推測されるものではありません (これがファクトです)。" - -#: ../../rst/reference_appendices/glossary.rst:504 -msgid "YAML" -msgstr "YAML" - -#: ../../rst/reference_appendices/glossary.rst:506 -msgid "Ansible does not want to force people to write programming language code to automate infrastructure, so Ansible uses YAML to define :term:`playbook ` configuration languages and also variable files. YAML is nice because it has a minimum of syntax and is very clean and easy for people to skim. It is a good data format for configuration files and humans, but also machine readable. Ansible's usage of YAML stemmed from Michael DeHaan's first use of it inside of Cobbler around 2006. YAML is fairly popular in the dynamic language community and the format has libraries available for serialization in many languages (Python, Perl, Ruby, and so on)." -msgstr "Ansible は、インフラストラクチャーを自動化するためのプログラミング言語コードの記述を強制しないように、YAML を使用して :term:`playbook ` 設定言語と変数ファイル定義します。YAML は、最小限の構文しか使用されていないため、非常にわかりやすく、簡単に確認できるため優れています。これは、設定ファイルやユーザーにとって優れたデータ形式ですが、機械でも判別可能です。Ansible での YAML の使用は、2006 年頃に Michael DeHaan が Cobbler 内で最初に使用したことに端を発しています。YAML は動的言語コミュニティーで非常に人気があり、この形式には多くの言語 (Python、Perl、Ruby など) でシリアル化できるライブラリーがあります。" - -#: ../../rst/reference_appendices/glossary.rst:519 -msgid ":ref:`ansible_faq`" -msgstr ":ref:`ansible_faq`" - -#: ../../rst/reference_appendices/glossary.rst:520 -msgid "Frequently asked questions" -msgstr "よくある質問 (FAQ)" - -#: ../../rst/reference_appendices/glossary.rst:525 -msgid "`User Mailing List `_" -msgstr "`メーリングリストの使用 `_" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:4 -msgid "Interpreter Discovery" -msgstr "インタープリターの検出" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:6 -msgid "Most Ansible modules that execute under a POSIX environment require a Python interpreter on the target host. Unless configured otherwise, Ansible will attempt to discover a suitable Python interpreter on each target host the first time a Python module is executed for that host." -msgstr "POSIX 環境で実行されるほとんどの Ansible モジュールには、ターゲットホスト上に Python インタープリターが必要です。特に設定されていない限り、Ansible は、Python モジュールがそのホストに対して最初に実行されるときに、各ターゲットホストで適切な Python インタープリターを検出しようとします。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:11 -msgid "To control the discovery behavior:" -msgstr "検出動作を制御するには、以下を実行します。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:13 -msgid "for individual hosts and groups, use the ``ansible_python_interpreter`` inventory variable" -msgstr "個別のホストおよびグループの場合は、``ansible_python_interpreter`` インベントリー変数を使用します。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:14 -msgid "globally, use the ``interpreter_python`` key in the ``[defaults]`` section of ``ansible.cfg``" -msgstr "グローバルに、``interpreter_python`` の ``[defaults]`` セクションに ``ansible.cfg`` キーを使用します。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:16 -msgid "Use one of the following values:" -msgstr "以下のいずれかの値を使用します。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:19 -msgid "Detects the target OS platform, distribution, and version, then consults a table listing the correct Python interpreter and path for each platform/distribution/version. If an entry is found, and ``/usr/bin/python`` is absent, uses the discovered interpreter (and path). If an entry is found, and ``/usr/bin/python`` is present, uses ``/usr/bin/python`` and issues a warning. This exception provides temporary compatibility with previous versions of Ansible that always defaulted to ``/usr/bin/python``, so if you have installed Python and other dependencies at ``/usr/bin/python`` on some hosts, Ansible will find and use them with this setting. If no entry is found, or the listed Python is not present on the target host, searches a list of common Python interpreter paths and uses the first one found; also issues a warning that future installation of another Python interpreter could alter the one chosen." -msgstr "ターゲット OS プラットフォーム、ディストリビューション、およびバージョンを検出してから、各プラットフォーム/ディストリビューション/バージョンに適した Python インタープリターとパスを表示するテーブルを参照します。エントリーが見つかり、``/usr/bin/python`` が存在していない場合は、検出されたインタープリター (およびパス) を使用します。エントリーが見つかり、``/usr/bin/python`` が存在する場合は、``/usr/bin/python`` を使用して警告を出力します。この例外は、常に ``/usr/bin/python`` にデフォルトで設定されていた以前のバージョンの Ansible との一時的な互換性を提供されているため、Python や一部のホストの ``/usr/bin/python`` にその他の依存関係である場合は、Ansible はこの設定でそれらを見つけて使用します。エントリーが見つからなかった場合や、リストされた Python がターゲットホストにない場合は、一般的な Python インタープリターパスのリストを検索し、最初に検出したインタープリターを使用します。また、今後別の Python インタープリターをインストールすると、選択したパスが変更する可能性があるという警告が表示されます。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:41 -msgid "auto" -msgstr "auto" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:34 -msgid "Detects the target OS platform, distribution, and version, then consults a table listing the correct Python interpreter and path for each platform/distribution/version. If an entry is found, uses the discovered interpreter. If no entry is found, or the listed Python is not present on the target host, searches a list of common Python interpreter paths and uses the first one found; also issues a warning that future installation of another Python interpreter could alter the one chosen." -msgstr "ターゲット OS プラットフォーム、ディストリビューション、およびバージョンを検出してから、各プラットフォーム/ディストリビューション/バージョンに適した Python インタープリターとパスを表示するテーブルを参照します。エントリーが見つからなかった場合や、リストされた Python がターゲットホストにない場合は、一般的な Python インタープリターパスのリストを検索し、最初に検出したインタープリターを使用します。また、今後別のインタープリターをインストールすると、選択したパスが変更する可能性があるという警告が表示されます。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:44 -msgid "auto_legacy_silent" -msgstr "auto_legacy_silent" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:44 -msgid "Same as ``auto_legacy``, but does not issue warnings." -msgstr "``auto_legacy`` と同じですが、警告は表示しません。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:47 -msgid "auto_silent" -msgstr "auto_silent" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:47 -msgid "Same as ``auto``, but does not issue warnings." -msgstr "``auto`` と同じですが、警告は表示しません。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:49 -msgid "You can still set ``ansible_python_interpreter`` to a specific path at any variable level (for example, in host_vars, in vars files, in playbooks, and so on). Setting a specific path completely disables automatic interpreter discovery; Ansible always uses the path specified." -msgstr "``ansible_python_interpreter`` を変数レベルで特定のパスに設定できます (例: host_vars では、vars ファイルでは、Playbook ではなど)。特定のパスを設定すると、自動インタープリターの検出が完全に無効化され、Ansible は常に指定されたパスを使用します。" - -#: ../../rst/reference_appendices/logging.rst:3 -msgid "Logging Ansible output" -msgstr "Ansible 出力のロギング" - -#: ../../rst/reference_appendices/logging.rst:5 -msgid "By default Ansible sends output about plays, tasks, and module arguments to your screen (STDOUT) on the control node. If you want to capture Ansible output in a log, you have three options:" -msgstr "デフォルトでは、Ansible はプレイ、タスク、およびモジュール引数の出力を、コントロールノードの画面 (STDOUT) に送信します。Ansible 出力をログに記録する場合は、以下の 3 つのオプションを使用することができます。" - -#: ../../rst/reference_appendices/logging.rst:7 -msgid "To save Ansible output in a single log on the control node, set the ``log_path`` :ref:`configuration file setting `. You may also want to set ``display_args_to_stdout``, which helps to differentiate similar tasks by including variable values in the Ansible output." -msgstr "コントロールノードの 1 つのログに Ansible 出力を保存するには、``log_path`` の :ref:`設定ファイルオプション ` を設定します。``display_args_to_stdout`` を設定すると、Ansible の出力に変数の値を追加し、同様のタスクを区別しやすくなります。" - -#: ../../rst/reference_appendices/logging.rst:8 -msgid "To save Ansible output in separate logs, one on each managed node, set the ``no_target_syslog`` and ``syslog_facility`` :ref:`configuration file settings `." -msgstr "各管理ノードごとに異なるログに Ansible 出力を保存するには、``no_target_syslog`` および ``syslog_facility`` の :ref:`構成ファイル設定 ` を設定します。" - -#: ../../rst/reference_appendices/logging.rst:9 -msgid "To save Ansible output to a secure database, use :ref:`Ansible Tower `. Tower allows you to review history based on hosts, projects, and particular inventories over time, using graphs and/or a REST API." -msgstr "Ansible の出力を安全なデータベースに保存するには、:ref:`Ansible Tower ` を使用します。Tower を使用すると、グラフや REST API を使用して、ホスト、プロジェクト、および特定のインベントリーに基づいて履歴を確認できます。" - -#: ../../rst/reference_appendices/logging.rst:12 -msgid "Protecting sensitive data with ``no_log``" -msgstr "``no_log`` を使用した機密データの保護" - -#: ../../rst/reference_appendices/logging.rst:14 -msgid "If you save Ansible output to a log, you expose any secret data in your Ansible output, such as passwords and user names. To keep sensitive values out of your logs, mark tasks that expose them with the ``no_log: True`` attribute. However, the ``no_log`` attribute does not affect debugging output, so be careful not to debug playbooks in a production environment. See :ref:`keep_secret_data` for an example." -msgstr "Ansible 出力をログに保存すると、パスワードやユーザー名などの秘密データが Ansible 出力に公開されます。機密性の高い値をログに記録しないようにするには、それらを公開するタスクに、``no_log: True`` 属性で印を付けます。ただし、``no_log`` 属性は、デバッグ出力に影響を与えないため、実稼働環境で Playbook をデバッグしないように注意してください。サンプルは、「:ref:`keep_secret_data`」を参照してください。" - -#: ../../rst/reference_appendices/module_utils.rst:6 -msgid "Ansible Reference: Module Utilities" -msgstr "Ansible 参考資料: モジュールユーティリティー" - -#: ../../rst/reference_appendices/module_utils.rst:8 -msgid "This page documents utilities intended to be helpful when writing Ansible modules in Python." -msgstr "このページでは、Python で Ansible モジュールを記述するときに役立つユーティリティーについてまとめています。" - -#: ../../rst/reference_appendices/module_utils.rst:13 -msgid "AnsibleModule" -msgstr "AnsibleModule" - -#: ../../rst/reference_appendices/module_utils.rst:15 -msgid "To use this functionality, include ``from ansible.module_utils.basic import AnsibleModule`` in your module." -msgstr "この機能を使用するには、モジュールに ``from ansible.module_utils.basic import AnsibleModule`` を追加します。" - -#: ansible.module_utils.basic.AnsibleModule:1 of -msgid "Common code for quickly building an ansible module in Python (although you can write modules with anything that can return JSON)." -msgstr "Python で Ansible モジュールを迅速に構築するための一般的なコード (ただし、JSON を返すことができるものならなんでもモジュールを作成できます）。" - -#: ansible.module_utils.basic.AnsibleModule:4 of -msgid "See :ref:`developing_modules_general` for a general introduction and :ref:`developing_program_flow_modules` for more detailed explanation." -msgstr "全般の概要は「:ref:`developing_modules_general`」を参照してください。詳細な説明は「:ref:`developing_program_flow_modules`」を参照してください。" - -#: ansible.module_utils.basic.AnsibleModule.add_path_info:1 of -msgid "for results that are files, supplement the info about the file in the return path with stats about the file path." -msgstr "ファイルの結果については、ファイルパスに関する統計で、リターンパスのファイルに関する情報を補完します。" - -#: ansible.module_utils.basic.AnsibleModule.atomic_move:1 of -msgid "atomically move src to dest, copying attributes from dest, returns true on success it uses os.rename to ensure this as it is an atomic operation, rest of the function is to work around limitations, corner cases and ensure selinux context is saved if possible" -msgstr "src を dest にアトミックに移動し、dest から属性をコピーし、成功すると true を返します。これはアトミック操作であるため、os.rename を使用してこれを確認します。残りの関数は、制限や、めったに発生しない厄介なケースを回避し、可能であれば selinux コンテキストが保存されるようにします。" - -#: ansible.module_utils.basic.AnsibleModule.backup_local:1 of -msgid "make a date-marked backup of the specified file, return True or False on success or failure" -msgstr "指定されたファイルの日付マーク付きバックアップを作成し、成功した場合は True、失敗した場合は False を返します" - -#: ansible.module_utils.basic.AnsibleModule.boolean:1 of -msgid "Convert the argument to a boolean" -msgstr "引数をブール値に変換します。" - -#: ansible.module_utils.basic.AnsibleModule.digest_from_file:1 of -msgid "Return hex digest of local file for a digest_method specified by name, or None if file is not present." -msgstr "名前が指定した digest_method のローカルファイルの 16 進数ダイジェストを返します。ファイルが存在しない場合は None を返します。" - -#: ansible.module_utils.basic.AnsibleModule.exit_json:1 of -msgid "return from the module, without error" -msgstr "モジュールから返します。エラーはありません。" - -#: ansible.module_utils.basic.AnsibleModule.fail_json:1 of -msgid "return from the module, with an error message" -msgstr "エラーメッセージを含むモジュールから返します。" - -#: ansible.module_utils.basic.AnsibleModule.find_mount_point:1 of -msgid "Takes a path and returns it's mount point" -msgstr "パスを取得し、そのマウントポイントを返します。" - -#: ansible.module_utils.basic.AnsibleModule.find_mount_point -#: ansible.module_utils.basic.AnsibleModule.get_bin_path -#: ansible.module_utils.basic.AnsibleModule.is_executable -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "Parameters" -msgstr "パラメーター" - -#: ansible.module_utils.basic.AnsibleModule.find_mount_point:3 of -msgid "a string type with a filesystem path" -msgstr "ファイルシステムパスがある文字列のタイプ" - -#: ansible.module_utils.basic.AnsibleModule.find_mount_point -#: ansible.module_utils.basic.AnsibleModule.get_bin_path -#: ansible.module_utils.basic.AnsibleModule.run_command -#: ansible.module_utils.basic.get_platform of -msgid "Returns" -msgstr "戻り値" - -#: ansible.module_utils.basic.AnsibleModule.find_mount_point:4 of -msgid "the path to the mount point as a text type" -msgstr "テキストタイプとしてのマウントポイントへのパス" - -#: ansible.module_utils.basic.AnsibleModule.get_bin_path:1 of -msgid "Find system executable in PATH." -msgstr "PATH でシステムの実行ファイルを検索します。" - -#: ansible.module_utils.basic.AnsibleModule.get_bin_path:3 of -msgid "The executable to find." -msgstr "検索する実行ファイル。" - -#: ansible.module_utils.basic.AnsibleModule.get_bin_path:4 of -msgid "if executable is not found and required is ``True``, fail_json" -msgstr "実行ファイルが見つからず、required が ``True`` の場合は、fail_json となります。" - -#: ansible.module_utils.basic.AnsibleModule.get_bin_path:5 of -msgid "optional list of directories to search in addition to ``PATH``" -msgstr "``PATH`` と、検索するディレクトリーのオプションの一覧です。" - -#: ansible.module_utils.basic.AnsibleModule.get_bin_path:6 of -msgid "if found return full path; otherwise return None" -msgstr "見つかった場合はフルパスを返します。見つからない場合は None を返します。" - -#: ansible.module_utils.basic.AnsibleModule.is_executable:1 of -msgid "is the given path executable?" -msgstr "指定のパスは実行ファイルですか。" - -#: ansible.module_utils.basic.AnsibleModule.is_executable:3 of -msgid "The path of the file to check." -msgstr "確認するファイルのパス。" - -#: ansible.module_utils.basic.AnsibleModule.is_executable:5 of -msgid "Limitations:" -msgstr "制限事項:" - -#: ansible.module_utils.basic.AnsibleModule.is_executable:7 of -msgid "Does not account for FSACLs." -msgstr "FSACL を考慮しません。" - -#: ansible.module_utils.basic.AnsibleModule.is_executable:8 of -msgid "Most times we really want to know \"Can the current user execute this file\". This function does not tell us that, only if any execute bit is set." -msgstr "ほとんどの場合は、「現在のユーザーがこのファイルを実行できるかどうか」を本当に知りたいのです。この関数は、実行ビットが設定されているかどうかだけで、それを知ることはできません。" - -#: ansible.module_utils.basic.AnsibleModule.is_special_selinux_path:1 of -msgid "Returns a tuple containing (True, selinux_context) if the given path is on a NFS or other 'special' fs mount point, otherwise the return will be (False, None)." -msgstr "指定されたパスが NFS またはその他の「特別な」fs マウントポイント上にある場合は (True, selinux_context) を含むタプルを返し、そうでない場合は (False, None) を返します。" - -#: ansible.module_utils.basic.AnsibleModule.load_file_common_arguments:1 of -msgid "many modules deal with files, this encapsulates common options that the file module accepts such that it is directly available to all modules and they can share code." -msgstr "多くのモジュールがファイルを扱うため、ファイルモジュールが受け付ける共通のオプションをカプセル化して、すべてのモジュールが直接利用できるようにし、コードを共有できるようにしています。" - -#: ansible.module_utils.basic.AnsibleModule.load_file_common_arguments:5 of -msgid "Allows to overwrite the path/dest module argument by providing path." -msgstr "パスを指定して、パス/dest モジュール引数を上書きできるようにします。" - -#: ansible.module_utils.basic.AnsibleModule.md5:1 of -msgid "Return MD5 hex digest of local file using digest_from_file()." -msgstr "digest_from_file() を使用してローカルファイルの MD5 hex ダイジェストを返します。" - -#: ansible.module_utils.basic.AnsibleModule.md5:5 of -msgid "Do not use this function unless you have no other choice for:" -msgstr "他の選択肢がない場合は、この機能を使用しないでください。" - -#: ansible.module_utils.basic.AnsibleModule.md5:4 of -msgid "Optional backwards compatibility" -msgstr "任意の下位互換性" - -#: ansible.module_utils.basic.AnsibleModule.md5:5 of -msgid "Compatibility with a third party protocol" -msgstr "サードパーティープロトコルとの互換性" - -#: ansible.module_utils.basic.AnsibleModule.md5:7 of -msgid "This function will not work on systems complying with FIPS-140-2." -msgstr "この機能は、FIPS-140-2 に準拠するシステムでは機能しません。" - -#: ansible.module_utils.basic.AnsibleModule.md5:9 of -msgid "Most uses of this function can use the module.sha1 function instead." -msgstr "この機能の大半は、代わりに module.sha1 関数を使用できます。" - -#: ansible.module_utils.basic.AnsibleModule.preserved_copy:1 of -msgid "Copy a file with preserved ownership, permissions and context" -msgstr "保存済みの所有権、パーミッション、およびコンテキストでファイルをコピーします。" - -#: ansible.module_utils.basic.AnsibleModule.run_command:1 of -msgid "Execute a command, returns rc, stdout, and stderr." -msgstr "コマンドを実行して、rc、stdout、および stderr を返します。" - -#: ansible.module_utils.basic.AnsibleModule.run_command:3 of -msgid "is the command to run * If args is a list, the command will be run with shell=False. * If args is a string and use_unsafe_shell=False it will split args to a list and run with shell=False * If args is a string and use_unsafe_shell=True it runs with shell=True." -msgstr "これは実行するコマンドです * 引数がリストの場合、コマンドは shell=False で実行します。 * 引数が文字列で、use_unsafe_shell=False の場合は、引数をリストに分割して shell=False で実行します * 引数が文字列で use_unsafe_shell=True の場合は、shell=True で実行します。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw check_rc" -msgstr "kw check_rc" - -#: ansible.module_utils.basic.AnsibleModule.run_command:7 of -msgid "Whether to call fail_json in case of non zero RC. Default False" -msgstr "RC がゼロ以外の場合に fail_json を呼び出すかどうか。デフォルトは False です。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw close_fds" -msgstr "kw close_fds" - -#: ansible.module_utils.basic.AnsibleModule.run_command:9 of -msgid "See documentation for subprocess.Popen(). Default True" -msgstr "subprocess.Popen() のドキュメントを参照してください。デフォルト は True です。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw executable" -msgstr "kw executable" - -#: ansible.module_utils.basic.AnsibleModule.run_command:10 of -msgid "See documentation for subprocess.Popen(). Default None" -msgstr "subprocess.Popen() のドキュメントを参照してください。デフォルトは None です。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw data" -msgstr "kw data" - -#: ansible.module_utils.basic.AnsibleModule.run_command:11 of -msgid "If given, information to write to the stdin of the command" -msgstr "指定した場合は、コマンドの stdin に書き込む情報" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw binary_data" -msgstr "kw binary_data" - -#: ansible.module_utils.basic.AnsibleModule.run_command:12 of -msgid "If False, append a newline to the data. Default False" -msgstr "False の場合は、データに新しい行を追加します。デフォルトは False です。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw path_prefix" -msgstr "kw path_prefix" - -#: ansible.module_utils.basic.AnsibleModule.run_command:13 of -msgid "If given, additional path to find the command in. This adds to the PATH environment variable so helper commands in the same directory can also be found" -msgstr "指定されている場合、コマンドを見つけるための追加のパス。これにより、PATH 環境変数が追加されるため、同じディレクトリー内のヘルパーコマンドも見つけることができます。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw cwd" -msgstr "kw cwd" - -#: ansible.module_utils.basic.AnsibleModule.run_command:16 of -msgid "If given, working directory to run the command inside" -msgstr "指定した場合は、コマンドを実行する作業ディレクトリー" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw use_unsafe_shell" -msgstr "kw use_unsafe_shell" - -#: ansible.module_utils.basic.AnsibleModule.run_command:17 of -msgid "See `args` parameter. Default False" -msgstr "`args` パラメーターを参照してください (デフォルトは False)。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw prompt_regex" -msgstr "kw prompt_regex" - -#: ansible.module_utils.basic.AnsibleModule.run_command:18 of -msgid "Regex string (not a compiled regex) which can be used to detect prompts in the stdout which would otherwise cause the execution to hang (especially if no input data is specified)" -msgstr "標準出力内のプロンプトを検出するために使用できる Regex 文字列 (コンパイルされた正規表現ではありません)。そうしないと、実行がハングします (特に入力データが指定されていない場合)。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw environ_update" -msgstr "kw environ_update" - -#: ansible.module_utils.basic.AnsibleModule.run_command:21 of -msgid "dictionary to *update* os.environ with" -msgstr "os.environ を *更新* するディクショナリー" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw umask" -msgstr "kw umask" - -#: ansible.module_utils.basic.AnsibleModule.run_command:22 of -msgid "Umask to be used when running the command. Default None" -msgstr "コマンドを実行する際に使用される umask です。デフォルトは None。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw encoding" -msgstr "kw encoding" - -#: ansible.module_utils.basic.AnsibleModule.run_command:23 of -msgid "Since we return native strings, on python3 we need to know the encoding to use to transform from bytes to text. If you want to always get bytes back, use encoding=None. The default is \"utf-8\". This does not affect transformation of strings given as args." -msgstr "ネイティブ文字列を返すため、python3 では、バイトからテキストに変換するためのエンコーディングを知る必要があります。常にバイトを返したい場合は、encoding=None を使用してください。デフォルトは「utf-8」です。これは引数として与えられた文字列の変換には影響しません。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw errors" -msgstr "kw errors" - -#: ansible.module_utils.basic.AnsibleModule.run_command:28 of -msgid "Since we return native strings, on python3 we need to transform stdout and stderr from bytes to text. If the bytes are undecodable in the ``encoding`` specified, then use this error handler to deal with them. The default is ``surrogate_or_strict`` which means that the bytes will be decoded using the surrogateescape error handler if available (available on all python3 versions we support) otherwise a UnicodeError traceback will be raised. This does not affect transformations of strings given as args." -msgstr "ネイティブ文字列を返すため、python3 では stdout と stderr をバイトからテキストに変換する必要があります。もしバイトが指定された ``encoding`` でデコードできない場合は、このエラーハンドラを使用して処理します。デフォルトは ``surrogate_or_strict`` で、利用可能であれば surrogateescape エラーハンドラーを使ってバイトがデコードされることを意味します (サポートしている python3 バージョンで利用可能)。これは、引数として与えられた文字列の変換には影響しません。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw expand_user_and_vars" -msgstr "kw expand_user_and_vars" - -#: ansible.module_utils.basic.AnsibleModule.run_command:37 of -msgid "When ``use_unsafe_shell=False`` this argument dictates whether ``~`` is expanded in paths and environment variables are expanded before running the command. When ``True`` a string such as ``$SHELL`` will be expanded regardless of escaping. When ``False`` and ``use_unsafe_shell=False`` no path or variable expansion will be done." -msgstr "``use_unsafe_shell=False`` の場合、この引数は、コマンドを実行する前に、パスで ``~`` を展開し、環境変数を展開するかどうかを指示します。``True`` の場合、``$SHELL`` のような文字列は、エスケープに関係なく展開されます。``False`` および``use_unsafe_shell=False`` の場合、パスや変数の展開は行われません。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw pass_fds" -msgstr "kw pass_fds" - -#: ansible.module_utils.basic.AnsibleModule.run_command:42 of -msgid "When running on Python 3 this argument dictates which file descriptors should be passed to an underlying ``Popen`` constructor. On Python 2, this will set ``close_fds`` to False." -msgstr "Python 3 で実行する場合、この引数は ``Popen`` の基礎となるコンストラクターにどのファイル記述子を渡すべきかを指示します。Python 2 では、この引数は ``close_fds`` を False に設定します。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw before_communicate_callback" -msgstr "kw before_communicate_callback" - -#: ansible.module_utils.basic.AnsibleModule.run_command:46 of -msgid "This function will be called after ``Popen`` object will be created but before communicating to the process. (``Popen`` object will be passed to callback as a first argument)" -msgstr "この関数は、``Popen`` オブジェクトが作成されると呼び出されますが、プロセスに通信する前に呼び出されます (``Popen`` オブジェクトは最初の引数としてコールバックに渡されます)。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw ignore_invalid_cwd" -msgstr "kw ignore_invalid_cwd" - -#: ansible.module_utils.basic.AnsibleModule.run_command:50 of -msgid "This flag indicates whether an invalid ``cwd`` (non-existent or not a directory) should be ignored or should raise an exception." -msgstr "このフラグは、無効な ``cwd`` (存在しないまたはディレクトリーではない) を無視するべきか、例外を発生させるべきかを示します。" - -#: ansible.module_utils.basic.AnsibleModule.run_command:53 of -msgid "A 3-tuple of return code (integer), stdout (native string), and stderr (native string). On python2, stdout and stderr are both byte strings. On python3, stdout and stderr are text strings converted according to the encoding and errors parameters. If you want byte strings on python3, use encoding=None to turn decoding to text off." -msgstr "リターンコード (整数)、stdout (ネイティブ文字列) 、および stderr (ネイティブ文字列) の 3 つのタプルです。python2 では stdout と stderr はどちらもバイト文字列です。python3 では、stdout と stderr は、encoding パラメーターと errors パラメーターに従って変換されたテキスト文字列です。python3 でバイト文字列にしたい場合は、encoding=None を使用してテキストへのデコードをオフにしてください。" - -#: ansible.module_utils.basic.AnsibleModule.sha1:1 of -msgid "Return SHA1 hex digest of local file using digest_from_file()." -msgstr "digest_from_file() を使用してローカルファイルの SHA1 hex ダイジェストを返します。" - -#: ansible.module_utils.basic.AnsibleModule.sha256:1 of -msgid "Return SHA-256 hex digest of local file using digest_from_file()." -msgstr "digest_from_file() を使用してローカルファイルの SHA-256 hex ダイジェストを返します。" - -#: ../../rst/reference_appendices/module_utils.rst:22 -msgid "Basic" -msgstr "基本" - -#: ../../rst/reference_appendices/module_utils.rst:24 -msgid "To use this functionality, include ``import ansible.module_utils.basic`` in your module." -msgstr "この機能を使用するには、モジュールに ``import ansible.module_utils.basic`` を追加します。" - -#: ansible.module_utils.basic.get_all_subclasses:1 of -msgid "**Deprecated**: Use ansible.module_utils.common._utils.get_all_subclasses instead" -msgstr "**非推奨**: 代わりに ansible.module_utils.common._utils.get_all_subclasses を使用します。" - -#: ansible.module_utils.basic.get_platform:1 of -msgid "**Deprecated** Use :py:func:`platform.system` directly." -msgstr "**非推奨** :py:func:`platform.system` を直接使用します。" - -#: ansible.module_utils.basic.get_platform:3 of -msgid "Name of the platform the module is running on in a native string" -msgstr "モジュールがネイティブ文字列で実行されているプラットフォームの名前" - -#: ansible.module_utils.basic.get_platform:5 of -msgid "Returns a native string that labels the platform (\"Linux\", \"Solaris\", etc). Currently, this is the result of calling :py:func:`platform.system`." -msgstr "プラットフォーム (「Linux」、「Solaris」など) にラベルを付けるネイティブ文字列を返します。現在、これは :py:func:`platform.system` を呼び出した結果になります。" - -#: ansible.module_utils.basic.heuristic_log_sanitize:1 of -msgid "Remove strings that look like passwords from log messages" -msgstr "ログメッセージからパスワードのように見える文字列を削除" - -#: ansible.module_utils.basic.load_platform_subclass:1 of -msgid "**Deprecated**: Use ansible.module_utils.common.sys_info.get_platform_subclass instead" -msgstr "**非推奨**: 代わりに ansible.module_utils.common.sys_info.get_platform_subclass を使用します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:4 -msgid "Playbook Keywords" -msgstr "Playbook キーワード" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:6 -msgid "These are the keywords available on common playbook objects. Keywords are one of several sources for configuring Ansible behavior. See :ref:`general_precedence_rules` for details on the relative precedence of each source." -msgstr "これらのキーワードは、一般的な Playbook オブジェクトで利用できます。キーワードは、Ansible の動作を設定する複数のソースのいずれかです。各ソースの相対優先順位に関する詳細は、「:ref:`general_precedence_rules`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:9 -msgid "Please note:" -msgstr "注意:" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:11 -msgid "Aliases for the directives are not reflected here, nor are mutable one. For example, :term:`action` in task can be substituted by the name of any Ansible module." -msgstr "ディレクティブのエイリアスはここでは反映されておらず、変更可能なものでもありません。たとえば、タスクの :term:`action` は、Ansible モジュールの名前に置き換えられます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:13 -msgid "The keywords do not have ``version_added`` information at this time" -msgstr "現時点ではキーワードに ``version_added`` 情報がありません" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:14 -msgid "Some keywords set defaults for the objects inside of them rather than for the objects themselves" -msgstr "キーワードによっては、オブジェクト自体ではなく、オブジェクト内にデフォルトを設定するものもあります。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:24 -msgid "Play" -msgstr "プレイ" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:28 -#: ../../rst/reference_appendices/playbooks_keywords.rst:165 -#: ../../rst/reference_appendices/playbooks_keywords.rst:260 -#: ../../rst/reference_appendices/playbooks_keywords.rst:364 -msgid "Force any un-handled task errors on any host to propagate to all hosts and end the play." -msgstr "ホストで処理されていないタスクエラーを強制的に実行し、すべてのホストに伝播してプレイを終了します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:31 -#: ../../rst/reference_appendices/playbooks_keywords.rst:168 -#: ../../rst/reference_appendices/playbooks_keywords.rst:263 -#: ../../rst/reference_appendices/playbooks_keywords.rst:373 -msgid "Boolean that controls if privilege escalation is used or not on :term:`Task` execution. Implemented by the become plugin. See :ref:`become_plugins`." -msgstr ":term:`Task` 実行時に特権昇格が使用されるかどうかを制御するブール値。become プラグインによって実装されます。「:ref:`become_plugins`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:34 -#: ../../rst/reference_appendices/playbooks_keywords.rst:171 -#: ../../rst/reference_appendices/playbooks_keywords.rst:266 -#: ../../rst/reference_appendices/playbooks_keywords.rst:376 -msgid "Path to the executable used to elevate privileges. Implemented by the become plugin. See :ref:`become_plugins`." -msgstr "権限の昇格に使用する実行可能ファイルへのパス。become プラグインによって実装されます。「:ref:`become_plugins`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:37 -#: ../../rst/reference_appendices/playbooks_keywords.rst:174 -#: ../../rst/reference_appendices/playbooks_keywords.rst:269 -#: ../../rst/reference_appendices/playbooks_keywords.rst:379 -msgid "A string of flag(s) to pass to the privilege escalation program when :term:`become` is True." -msgstr ":term:`become` が True の場合に特権昇格プログラムに渡すフラグの文字列。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:40 -#: ../../rst/reference_appendices/playbooks_keywords.rst:177 -#: ../../rst/reference_appendices/playbooks_keywords.rst:272 -#: ../../rst/reference_appendices/playbooks_keywords.rst:382 -msgid "Which method of privilege escalation to use (such as sudo or su)." -msgstr "使用する権限昇格の方法 (sudo、su など)。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:43 -#: ../../rst/reference_appendices/playbooks_keywords.rst:180 -#: ../../rst/reference_appendices/playbooks_keywords.rst:275 -#: ../../rst/reference_appendices/playbooks_keywords.rst:385 -msgid "User that you 'become' after using privilege escalation. The remote/login user must have permissions to become this user." -msgstr "特権昇格を使用した後に「become」となるユーザーです。リモート/ログインユーザーには、このユーザーになる (become) ためのパーミッションが必要です。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:44 -#: ../../rst/reference_appendices/playbooks_keywords.rst:181 -#: ../../rst/reference_appendices/playbooks_keywords.rst:279 -#: ../../rst/reference_appendices/playbooks_keywords.rst:389 -msgid "check_mode" -msgstr "check_mode" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:46 -#: ../../rst/reference_appendices/playbooks_keywords.rst:183 -#: ../../rst/reference_appendices/playbooks_keywords.rst:281 -#: ../../rst/reference_appendices/playbooks_keywords.rst:391 -msgid "A boolean that controls if a task is executed in 'check' mode. See :ref:`check_mode_dry`." -msgstr "「check」モードでタスクが実行されるかどうかを制御するブール値。「:ref:`check_mode_dry`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:47 -#: ../../rst/reference_appendices/playbooks_keywords.rst:184 -#: ../../rst/reference_appendices/playbooks_keywords.rst:282 -#: ../../rst/reference_appendices/playbooks_keywords.rst:392 -msgid "collections" -msgstr "collections" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:50 -#: ../../rst/reference_appendices/playbooks_keywords.rst:187 -#: ../../rst/reference_appendices/playbooks_keywords.rst:285 -#: ../../rst/reference_appendices/playbooks_keywords.rst:395 -msgid "List of collection namespaces to search for modules, plugins, and roles. See :ref:`collections_using_playbook`" -msgstr "モジュール、プラグイン、およびロールを検索するコレクション名前空間の一覧。「:ref:`collections_using_playbook`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:54 -#: ../../rst/reference_appendices/playbooks_keywords.rst:191 -#: ../../rst/reference_appendices/playbooks_keywords.rst:289 -#: ../../rst/reference_appendices/playbooks_keywords.rst:399 -msgid "Tasks within a role do not inherit the value of ``collections`` from the play. To have a role search a list of collections, use the ``collections`` keyword in ``meta/main.yml`` within a role." -msgstr "ロール内のタスクは、プレイから ``collections`` の値を継承しません。ロール検索でコレクションの一覧を取得するには、ロール内で ``meta/main.yml`` の ``collections`` キーワードを使用します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:56 -#: ../../rst/reference_appendices/playbooks_keywords.rst:193 -#: ../../rst/reference_appendices/playbooks_keywords.rst:291 -#: ../../rst/reference_appendices/playbooks_keywords.rst:401 -msgid "connection" -msgstr "connection" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:58 -#: ../../rst/reference_appendices/playbooks_keywords.rst:195 -#: ../../rst/reference_appendices/playbooks_keywords.rst:293 -#: ../../rst/reference_appendices/playbooks_keywords.rst:403 -msgid "Allows you to change the connection plugin used for tasks to execute on the target. See :ref:`using_connection`." -msgstr "ターゲットで実行するタスクに使用される connection プラグインを変更できます。「:ref:`using_connection`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:59 -#: ../../rst/reference_appendices/playbooks_keywords.rst:196 -#: ../../rst/reference_appendices/playbooks_keywords.rst:294 -#: ../../rst/reference_appendices/playbooks_keywords.rst:404 -msgid "debugger" -msgstr "debugger" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:61 -#: ../../rst/reference_appendices/playbooks_keywords.rst:198 -#: ../../rst/reference_appendices/playbooks_keywords.rst:296 -#: ../../rst/reference_appendices/playbooks_keywords.rst:406 -msgid "Enable debugging tasks based on state of the task result. See :ref:`playbook_debugger`." -msgstr "タスク結果の状態に基づいて、デバッグタスクを有効にします。「:ref:`playbook_debugger`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:64 -#: ../../rst/reference_appendices/playbooks_keywords.rst:207 -#: ../../rst/reference_appendices/playbooks_keywords.rst:305 -#: ../../rst/reference_appendices/playbooks_keywords.rst:418 -msgid "Toggle to make tasks return 'diff' information or not." -msgstr "タスクが「diff」情報を返すように切り替えます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:65 -#: ../../rst/reference_appendices/playbooks_keywords.rst:208 -#: ../../rst/reference_appendices/playbooks_keywords.rst:306 -#: ../../rst/reference_appendices/playbooks_keywords.rst:419 -msgid "environment" -msgstr "environment" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:67 -#: ../../rst/reference_appendices/playbooks_keywords.rst:210 -#: ../../rst/reference_appendices/playbooks_keywords.rst:308 -#: ../../rst/reference_appendices/playbooks_keywords.rst:421 -msgid "A dictionary that gets converted into environment vars to be provided for the task upon execution. This can ONLY be used with modules. This isn't supported for any other type of plugins nor Ansible itself nor its configuration, it just sets the variables for the code responsible for executing the task. This is not a recommended way to pass in confidential data." -msgstr "実行時に、タスク用に提供された環境変数に変換されるディクショナリー。これは、モジュールでのみ使用できます。これは、他のタイプのプラグインや Ansible 自体、その設定ではサポートされていません。タスクの実行を担当するコードの変数だけを設定します。これは、機密性の高いデータに渡すための推奨方法ではありません。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:70 -msgid "Set the fact path option for the fact gathering plugin controlled by :term:`gather_facts`." -msgstr ":term:`gather_facts` が制御するファクト収集プラグインのファクトパスオプションを設定します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:73 -msgid "Will force notified handler execution for hosts even if they failed during the play. Will not trigger if the play itself fails." -msgstr "プレイ中に失敗した場合でも、ホストの通知ハンドラー実行を強制的に実行します。プレイ自体が失敗した場合は発生しません。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:74 -msgid "gather_facts" -msgstr "gather_facts" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:76 -msgid "A boolean that controls if the play will automatically run the 'setup' task to gather facts for the hosts." -msgstr "プレイが自動的に「setup」タスクを実行してホストのファクトを収集するかどうかを制御するブール値。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:79 -msgid "Allows you to pass subset options to the fact gathering plugin controlled by :term:`gather_facts`." -msgstr ":term:`gather_facts` が制御するファクト収集プラグインにサブセットオプションを渡すことができます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:82 -msgid "Allows you to set the timeout for the fact gathering plugin controlled by :term:`gather_facts`." -msgstr ":term:`gather_facts` が制御するファクト収集プラグインのタイムアウトを設定できます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:83 -msgid "handlers" -msgstr "handlers" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:85 -msgid "A section with tasks that are treated as handlers, these won't get executed normally, only when notified after each section of tasks is complete. A handler's `listen` field is not templatable." -msgstr "ハンドラーとして扱われるタスクが含まれるセクションは、タスクの各セクションの完了後に通知される場合にのみ、通常どおり実行されません。ハンドラーの `listen` フィールドはテンプレート化できません。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:86 -msgid "hosts" -msgstr "hosts" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:88 -msgid "A list of groups, hosts or host pattern that translates into a list of hosts that are the play's target." -msgstr "プレイのターゲットであるホストの一覧に変換するグループ、ホスト、またはホストパターンの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:89 -#: ../../rst/reference_appendices/playbooks_keywords.rst:211 -#: ../../rst/reference_appendices/playbooks_keywords.rst:309 -#: ../../rst/reference_appendices/playbooks_keywords.rst:425 -msgid "ignore_errors" -msgstr "ignore_errors" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:91 -#: ../../rst/reference_appendices/playbooks_keywords.rst:213 -#: ../../rst/reference_appendices/playbooks_keywords.rst:311 -#: ../../rst/reference_appendices/playbooks_keywords.rst:427 -msgid "Boolean that allows you to ignore task failures and continue with play. It does not affect connection errors." -msgstr "タスクの失敗を無視してプレイを続行できるブール値。接続エラーには影響を及ぼしません。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:92 -#: ../../rst/reference_appendices/playbooks_keywords.rst:214 -#: ../../rst/reference_appendices/playbooks_keywords.rst:312 -#: ../../rst/reference_appendices/playbooks_keywords.rst:428 -msgid "ignore_unreachable" -msgstr "ignore_unreachable" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:94 -#: ../../rst/reference_appendices/playbooks_keywords.rst:216 -#: ../../rst/reference_appendices/playbooks_keywords.rst:314 -#: ../../rst/reference_appendices/playbooks_keywords.rst:430 -msgid "Boolean that allows you to ignore task failures due to an unreachable host and continue with the play. This does not affect other task errors (see :term:`ignore_errors`) but is useful for groups of volatile/ephemeral hosts." -msgstr "到達不可能なホストが原因でタスクの失敗を無視し、プレイを続行できるブール値。これは他のタスクエラーには影響を与えません (「:term:`ignore_errors`」参照)。揮発性/一時ホストのグループに役に立ちます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:95 -msgid "max_fail_percentage" -msgstr "max_fail_percentage" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:97 -msgid "can be used to abort the run after a given percentage of hosts in the current batch has failed. This only wokrs on linear or linear derived strategies." -msgstr "現在のバッチ内の特定の割合のホストに障害が発生した後、実行を中止するために使用できます。これは、線形または線形派生戦略にのみ影響します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:98 -#: ../../rst/reference_appendices/playbooks_keywords.rst:217 -#: ../../rst/reference_appendices/playbooks_keywords.rst:315 -#: ../../rst/reference_appendices/playbooks_keywords.rst:443 -msgid "module_defaults" -msgstr "module_defaults" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:100 -#: ../../rst/reference_appendices/playbooks_keywords.rst:219 -#: ../../rst/reference_appendices/playbooks_keywords.rst:317 -#: ../../rst/reference_appendices/playbooks_keywords.rst:445 -msgid "Specifies default parameter values for modules." -msgstr "モジュールのデフォルトパラメーター値を指定します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:103 -#: ../../rst/reference_appendices/playbooks_keywords.rst:222 -#: ../../rst/reference_appendices/playbooks_keywords.rst:320 -#: ../../rst/reference_appendices/playbooks_keywords.rst:448 -msgid "Identifier. Can be used for documentation, or in tasks/handlers." -msgstr "識別子。ドキュメントまたはタスク/ハンドラーに使用することができます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:106 -#: ../../rst/reference_appendices/playbooks_keywords.rst:225 -#: ../../rst/reference_appendices/playbooks_keywords.rst:323 -#: ../../rst/reference_appendices/playbooks_keywords.rst:451 -msgid "Boolean that controls information disclosure." -msgstr "情報の公開を制御するブール値。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:107 -msgid "order" -msgstr "order" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:109 -msgid "Controls the sorting of hosts as they are used for executing the play. Possible values are inventory (default), sorted, reverse_sorted, reverse_inventory and shuffle." -msgstr "プレイの実行に使用するホストのソートを制御します。使用できる値は、inventory (デフォルト)、sorted、reverse_sorted、reverse_inventory、および shuffle です。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:110 -#: ../../rst/reference_appendices/playbooks_keywords.rst:226 -#: ../../rst/reference_appendices/playbooks_keywords.rst:327 -#: ../../rst/reference_appendices/playbooks_keywords.rst:458 -msgid "port" -msgstr "port" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:112 -#: ../../rst/reference_appendices/playbooks_keywords.rst:228 -#: ../../rst/reference_appendices/playbooks_keywords.rst:329 -#: ../../rst/reference_appendices/playbooks_keywords.rst:460 -msgid "Used to override the default port used in a connection." -msgstr "接続で使用されるデフォルトのポートを上書きするのに使用します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:113 -msgid "post_tasks" -msgstr "post_tasks" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:115 -msgid "A list of tasks to execute after the :term:`tasks` section." -msgstr ":term:`tasks` セクションの後に実行するタスクの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:116 -msgid "pre_tasks" -msgstr "pre_tasks" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:118 -msgid "A list of tasks to execute before :term:`roles`." -msgstr ":term:`roles` の前に実行するタスクの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:121 -#: ../../rst/reference_appendices/playbooks_keywords.rst:231 -#: ../../rst/reference_appendices/playbooks_keywords.rst:332 -#: ../../rst/reference_appendices/playbooks_keywords.rst:466 -msgid "User used to log into the target via the connection plugin." -msgstr "connection プラグインでターゲットにログインするのに使用するユーザー。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:122 -msgid "roles" -msgstr "roles" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:124 -msgid "List of roles to be imported into the play" -msgstr "プレイにインポートするロールの一覧" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:125 -#: ../../rst/reference_appendices/playbooks_keywords.rst:232 -#: ../../rst/reference_appendices/playbooks_keywords.rst:336 -#: ../../rst/reference_appendices/playbooks_keywords.rst:470 -msgid "run_once" -msgstr "run_once" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:127 -#: ../../rst/reference_appendices/playbooks_keywords.rst:234 -#: ../../rst/reference_appendices/playbooks_keywords.rst:338 -#: ../../rst/reference_appendices/playbooks_keywords.rst:472 -msgid "Boolean that will bypass the host loop, forcing the task to attempt to execute on the first host available and afterwards apply any results and facts to all active hosts in the same batch." -msgstr "ホストループを回避するブール値。タスクは、使用可能な最初のホストで実行を試行し、その後、同じバッチ内のすべてのアクティブなホストに結果とファクトを適用します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:128 -msgid "serial" -msgstr "serial" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:130 -msgid "Explicitly define how Ansible batches the execution of the current play on the play's target" -msgstr "Ansible が、プレイのターゲットで現在のプレイの実行をバッチ処理する方法を明示的に定義します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:132 -msgid ":ref:`rolling_update_batch_size`" -msgstr ":ref:`rolling_update_batch_size`" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:136 -msgid "Allows you to choose the connection plugin to use for the play." -msgstr "プレイに使用する connection プラグインを選択できます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:137 -#: ../../rst/reference_appendices/playbooks_keywords.rst:235 -#: ../../rst/reference_appendices/playbooks_keywords.rst:339 -#: ../../rst/reference_appendices/playbooks_keywords.rst:473 -msgid "tags" -msgstr "tags" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:139 -#: ../../rst/reference_appendices/playbooks_keywords.rst:237 -#: ../../rst/reference_appendices/playbooks_keywords.rst:341 -#: ../../rst/reference_appendices/playbooks_keywords.rst:475 -msgid "Tags applied to the task or included tasks, this allows selecting subsets of tasks from the command line." -msgstr "タスクまたは含まれるタスクに適用されるタグ。これにより、コマンドラインからタスクのサブセットを選択できます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:140 -msgid "tasks" -msgstr "tasks" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:142 -msgid "Main list of tasks to execute in the play, they run after :term:`roles` and before :term:`post_tasks`." -msgstr "プレイで実行するタスクの主な一覧。:term:`roles` から :term:`post_tasks` の間に実行されます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:143 -#: ../../rst/reference_appendices/playbooks_keywords.rst:238 -#: ../../rst/reference_appendices/playbooks_keywords.rst:342 -#: ../../rst/reference_appendices/playbooks_keywords.rst:476 -msgid "throttle" -msgstr "throttle" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:145 -#: ../../rst/reference_appendices/playbooks_keywords.rst:240 -#: ../../rst/reference_appendices/playbooks_keywords.rst:344 -#: ../../rst/reference_appendices/playbooks_keywords.rst:478 -msgid "Limit number of concurrent task runs on task, block and playbook level. This is independent of the forks and serial settings, but cannot be set higher than those limits. For example, if forks is set to 10 and the throttle is set to 15, at most 10 hosts will be operated on in parallel." -msgstr "タスク、ブロック、および Playbook レベルで実行される同時タスクの数を制限します。これはフォークとシリアル設定とは独立していますが、このような制限よりも高く設定することはできません。たとえば、フォークを 10 に設定し、スロットルが 15 に設定すると、ほぼ 10 台のホストを並行して操作します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:148 -#: ../../rst/reference_appendices/playbooks_keywords.rst:243 -#: ../../rst/reference_appendices/playbooks_keywords.rst:347 -#: ../../rst/reference_appendices/playbooks_keywords.rst:481 -msgid "Time limit for task to execute in, if exceeded Ansible will interrupt and fail the task." -msgstr "実行するタスクの時間制限。これを超えると、Ansible が割り込みし、タスクが失敗します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:149 -#: ../../rst/reference_appendices/playbooks_keywords.rst:244 -#: ../../rst/reference_appendices/playbooks_keywords.rst:348 -#: ../../rst/reference_appendices/playbooks_keywords.rst:485 -msgid "vars" -msgstr "vars" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:151 -#: ../../rst/reference_appendices/playbooks_keywords.rst:246 -#: ../../rst/reference_appendices/playbooks_keywords.rst:350 -#: ../../rst/reference_appendices/playbooks_keywords.rst:487 -msgid "Dictionary/map of variables" -msgstr "変数のディクショナリー/マップ" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:152 -msgid "vars_files" -msgstr "vars_files" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:154 -msgid "List of files that contain vars to include in the play." -msgstr "プレイに含まれる vars が含まれるファイルの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:155 -msgid "vars_prompt" -msgstr "vars_prompt" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:157 -msgid "list of variables to prompt for." -msgstr "プロンプトする変数の一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:161 -msgid "Role" -msgstr "ロール" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:199 -#: ../../rst/reference_appendices/playbooks_keywords.rst:297 -#: ../../rst/reference_appendices/playbooks_keywords.rst:410 -msgid "delegate_facts" -msgstr "delegate_facts" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:201 -#: ../../rst/reference_appendices/playbooks_keywords.rst:299 -#: ../../rst/reference_appendices/playbooks_keywords.rst:412 -msgid "Boolean that allows you to apply facts to a delegated host instead of inventory_hostname." -msgstr "inventory_hostname の代わりに委譲されたホストにファクトを適用できるようにするブール値。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:202 -#: ../../rst/reference_appendices/playbooks_keywords.rst:300 -#: ../../rst/reference_appendices/playbooks_keywords.rst:413 -msgid "delegate_to" -msgstr "delegate_to" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:204 -#: ../../rst/reference_appendices/playbooks_keywords.rst:302 -#: ../../rst/reference_appendices/playbooks_keywords.rst:415 -msgid "Host to execute task instead of the target (inventory_hostname). Connection vars from the delegated host will also be used for the task." -msgstr "ターゲットの代わりにタスクを実行するホスト (inventory_hostname)。委譲されたホストからの接続変数もタスクに使用されます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:247 -#: ../../rst/reference_appendices/playbooks_keywords.rst:351 -#: ../../rst/reference_appendices/playbooks_keywords.rst:488 -msgid "when" -msgstr "when" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:249 -#: ../../rst/reference_appendices/playbooks_keywords.rst:353 -#: ../../rst/reference_appendices/playbooks_keywords.rst:490 -msgid "Conditional expression, determines if an iteration of a task is run or not." -msgstr "条件式。タスクの反復を実行するかどうかを決定します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:253 -msgid "Block" -msgstr "ブロック (Block)" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:257 -msgid "List of tasks, in a block, that execute no matter if there is an error in the block or not." -msgstr "ブロックにエラーがあるかどうかに関係なく実行される、ブロック内のタスクのリスト。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:276 -msgid "block" -msgstr "block" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:278 -msgid "List of tasks in a block." -msgstr "ブロック内のタスクの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:324 -#: ../../rst/reference_appendices/playbooks_keywords.rst:452 -msgid "notify" -msgstr "notify" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:326 -#: ../../rst/reference_appendices/playbooks_keywords.rst:454 -msgid "List of handlers to notify when the task returns a 'changed=True' status." -msgstr "タスクが「changed=True」の状態を返す際に通知するハンドラーのリスト。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:333 -msgid "rescue" -msgstr "rescue" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:335 -msgid "List of tasks in a :term:`block` that run if there is a task error in the main :term:`block` list." -msgstr "メインの :term:`block` 一覧にタスクエラーがある場合に実行される :term:`block` 内のタスクの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:359 -msgid "action" -msgstr "action" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:361 -msgid "The 'action' to execute for a task, it normally translates into a C(module) or action plugin." -msgstr "タスクで実行する「アクション」は、通常 C(module) または action プラグインに変換されます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:365 -msgid "args" -msgstr "args" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:367 -msgid "A secondary way to add arguments into a task. Takes a dictionary in which keys map to options and values." -msgstr "引数をタスクに追加するセカンダリー方法。キーをオプションおよび値にマップするディクショナリーを作成します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:368 -msgid "async" -msgstr "async" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:370 -msgid "Run a task asynchronously if the C(action) supports this; value is maximum runtime in seconds." -msgstr "C(action) がこれをサポートする場合はタスクを非同期に実行します。値は、最大ランタイム (秒単位) です。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:386 -msgid "changed_when" -msgstr "changed_when" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:388 -msgid "Conditional expression that overrides the task's normal 'changed' status." -msgstr "タスクの通常の「changed」状態を上書きする条件式。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:407 -msgid "delay" -msgstr "delay" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:409 -msgid "Number of seconds to delay between retries. This setting is only used in combination with :term:`until`." -msgstr "再試行の間隔の遅延秒数。この設定は :term:`until` と組み合わせてのみ使用されます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:422 -msgid "failed_when" -msgstr "failed_when" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:424 -msgid "Conditional expression that overrides the task's normal 'failed' status." -msgstr "タスクの通常の「failed」状態を上書きする条件式。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:431 -msgid "local_action" -msgstr "local_action" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:433 -msgid "Same as action but also implies ``delegate_to: localhost``" -msgstr "アクションと同じですが、``delegate_to: localhost`` という意味を含みます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:434 -msgid "loop" -msgstr "loop" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:436 -msgid "Takes a list for the task to iterate over, saving each list element into the ``item`` variable (configurable via loop_control)" -msgstr "タスクのリストを取り、各リスト要素を ``item`` 変数に保存します (loop_control で設定可能)。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:437 -msgid "loop_control" -msgstr "loop_control" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:439 -msgid "Several keys here allow you to modify/set loop behaviour in a task." -msgstr "ここにあるいくつかのキーを使用すると、タスクのループ動作を変更/設定できます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:441 -msgid ":ref:`loop_control`" -msgstr ":ref:`loop_control`" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:455 -msgid "poll" -msgstr "poll" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:457 -msgid "Sets the polling interval in seconds for async tasks (default 10s)." -msgstr "非同期タスク (デフォルトは 10) のポーリング間隔を秒単位で設定します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:461 -msgid "register" -msgstr "register" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:463 -msgid "Name of variable that will contain task status and module return data." -msgstr "タスクステータスとモジュールリターンデータが含まれる変数の名前。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:467 -msgid "retries" -msgstr "retries" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:469 -msgid "Number of retries before giving up in a :term:`until` loop. This setting is only used in combination with :term:`until`." -msgstr ":term:`until` ループで断念するまでの再試行回数。この設定は :term:`until` と組み合わせる場合にのみ使用されます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:482 -msgid "until" -msgstr "until" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:484 -msgid "This keyword implies a ':term:`retries` loop' that will go on until the condition supplied here is met or we hit the :term:`retries` limit." -msgstr "このキーワードは、ここで提供された条件が満たされるまで、または :term:`retries` の制限に到達するまで実行される ':term:`retries` loop' を意味します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:491 -msgid "with_" -msgstr "with_" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:493 -msgid "The same as ``loop`` but magically adds the output of any lookup plugin to generate the item list." -msgstr "``loop`` と同じですが、アイテム一覧を生成するために lookup プラグインの出力が視覚的に追加されます。" - -#: ../../rst/reference_appendices/python_3_support.rst:3 -msgid "Python 3 Support" -msgstr "Python 3 サポート" - -#: ../../rst/reference_appendices/python_3_support.rst:5 -msgid "Ansible 2.5 and above work with Python 3. Previous to 2.5, using Python 3 was considered a tech preview. This topic discusses how to set up your controller and managed machines to use Python 3." -msgstr "Ansible 2.5 以降では、Python 3 を使用しますが、Python 3 を使用する Ansible 2.4 以前のバージョンは、テクノロジープレビューとみなされます。以下のトピックでは、Python 3 を使用できるようにコントローラーと管理マシンを設定する方法を説明します。" - -#: ../../rst/reference_appendices/python_3_support.rst:9 -msgid "On the controller we support Python 3.5 or greater and Python 2.7 or greater. Module-side, we support Python 3.5 or greater and Python 2.6 or greater." -msgstr "コントローラーでは、Python 3.5 以降、および Python 2.7 以降をサポートしています。モジュール側では、Python 3.5 以降、Python 2.6 以降をサポートします。" - -#: ../../rst/reference_appendices/python_3_support.rst:12 -msgid "On the controller side" -msgstr "コントローラー側" - -#: ../../rst/reference_appendices/python_3_support.rst:14 -msgid "The easiest way to run :command:`/usr/bin/ansible` under Python 3 is to install it with the Python3 version of pip. This will make the default :command:`/usr/bin/ansible` run with Python3:" -msgstr "Python 3 で :command:`/usr/bin/ansible` を最も簡単に実行するには、pip の Python 3 バージョンをインストールします。これでデフォルトで、Python 3 を使用して :command:`/usr/bin/ansible` を実行できます。" - -#: ../../rst/reference_appendices/python_3_support.rst:23 -msgid "If you are running Ansible :ref:`from_source` and want to use Python 3 with your source checkout, run your command via ``python3``. For example:" -msgstr "Ansible :ref:`from_source` を実行していて、ソースのチェックアウトに Python 3 を使用するには、``python3`` でコマンドを実行します。以下に例を示します。" - -#: ../../rst/reference_appendices/python_3_support.rst:32 -msgid "Individual Linux distribution packages may be packaged for Python2 or Python3. When running from distro packages you'll only be able to use Ansible with the Python version for which it was installed. Sometimes distros will provide a means of installing for several Python versions (via a separate package or via some commands that are run after install). You'll need to check with your distro to see if that applies in your case." -msgstr "個々の Linux ディストリビューションパッケージは、Python2 または Python3 にパッケージ化されます。ディストリビューションから実行する場合は、インストールされている Python バージョンでのみ Ansible を使用できます。障害により、複数の Python バージョン (別のパッケージ、またはインストール後に実行される一部のコマンドを介して) インストールを行う手段が提供されます。" - -#: ../../rst/reference_appendices/python_3_support.rst:40 -msgid "Using Python 3 on the managed machines with commands and playbooks" -msgstr "コマンドおよび Playbook を使用した管理マシンでの Python 3 の使用" - -#: ../../rst/reference_appendices/python_3_support.rst:42 -msgid "Ansible will automatically detect and use Python 3 on many platforms that ship with it. To explicitly configure a Python 3 interpreter, set the ``ansible_python_interpreter`` inventory variable at a group or host level to the location of a Python 3 interpreter, such as :command:`/usr/bin/python3`. The default interpreter path may also be set in ``ansible.cfg``." -msgstr "Ansible は、同梱されている多数のプラットフォームで Python 3 を自動的に検出して使用します。Python 3 インタープリターを明示的に設定するには、グループまたはホストレベルで、:command:`/usr/bin/python3` などのように、``ansible_python_interpreter`` のインベントリー変数を Python 3 インタープリターの場所に指定します。デフォルトのインタープリターパスも、``ansible.cfg`` に設定できます。" - -#: ../../rst/reference_appendices/python_3_support.rst:47 -msgid ":ref:`interpreter_discovery` for more information." -msgstr "詳細は :ref:`interpreter_discovery`" - -#: ../../rst/reference_appendices/python_3_support.rst:62 -msgid ":ref:`intro_inventory` for more information." -msgstr "詳細は :ref:`intro_inventory`" - -#: ../../rst/reference_appendices/python_3_support.rst:64 -msgid "Run your command or playbook:" -msgstr "コマンドまたは Playbook を実行します。" - -#: ../../rst/reference_appendices/python_3_support.rst:72 -msgid "Note that you can also use the `-e` command line option to manually set the python interpreter when you run a command. This can be useful if you want to test whether a specific module or playbook has any bugs under Python 3. For example:" -msgstr "コマンドの実行時に、`-e` コマンドラインオプションを指定して、手動で Python インタープリターを設定することもできる点に注意してください。これは、Python 3 で固有のモジュールや Playbook にバグが発生しているかをテストする場合に便利です。" - -#: ../../rst/reference_appendices/python_3_support.rst:82 -msgid "What to do if an incompatibility is found" -msgstr "非互換性が見つかった場合の対処方法" - -#: ../../rst/reference_appendices/python_3_support.rst:84 -msgid "We have spent several releases squashing bugs and adding new tests so that Ansible's core feature set runs under both Python 2 and Python 3. However, bugs may still exist in edge cases and many of the modules shipped with Ansible are maintained by the community and not all of those may be ported yet." -msgstr "Python 2 および Python 3 の両方で Ansible でコアとなる機能が実行できるように、複数リリースにわたってバグ修正や、新規テストが追加されました。ただし、バグは、エッジケースなどでまだ存在する可能性があります。また、Ansible に同梱されている多くのモジュールは、コミュニティーがメンテナンスを実施しており、すべてが移植されているわけではありません。" - -#: ../../rst/reference_appendices/python_3_support.rst:89 -msgid "If you find a bug running under Python 3 you can submit a bug report on `Ansible's GitHub project `_. Be sure to mention Python3 in the bug report so that the right people look at it." -msgstr "Python 3 で実行中にバグを発見した場合には、`Ansible の GitHub プロジェクト `_ からバグ報告を提出してください。適切な担当者が対応できるように、バグ報告には Python3 と記載するようにしてください。" - -#: ../../rst/reference_appendices/python_3_support.rst:93 -msgid "If you would like to fix the code and submit a pull request on github, you can refer to :ref:`developing_python_3` for information on how we fix common Python3 compatibility issues in the Ansible codebase." -msgstr "コードを修正して github へのプル要求を送信する場合は、Ansible コードベースで一般的な Python 3 の互換性の問題を修正する方法は、「:ref:`developing_python_3`」参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:4 -msgid "Release and maintenance" -msgstr "リリースおよびメンテナンス" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:6 -msgid "This section describes the Ansible and ``ansible-core`` releases. Ansible is the package that most users install. ``ansible-core`` is primarily for developers." -msgstr "本セクションでは、Ansible および ``ansible-core`` リリースを説明します。Ansible は、ほとんどのユーザーがインストールするパッケージです。``ansible-core`` は主に開発者向けのものです。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:16 -msgid "Ansible release cycle" -msgstr "Ansible リリースサイクル" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:18 -msgid "Ansible is developed and released on a flexible release cycle. This cycle can be extended in order to allow for larger changes to be properly implemented and tested before a new release is made available. See :ref:`roadmaps` for upcoming release details." -msgstr "Ansibleは、柔軟なリリースサイクルで開発およびリリースされます。このサイクルは、大規模な変更を正しく実装して、テストしてから新しいリリースが公開されるように、延長することが可能です。今後のリリースの詳細については、「:ref:`roadmaps`」を参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:22 -msgid "For Ansible version 2.10 or later, the major release is maintained for one release cycle. When the next release comes out (for example, 2.11), the older release (2.10 in this example) is no longer maintained." -msgstr "Ansible バージョン 2.10 以降では、メジャーリリースは 1 つのリリースサイクルで維持されます。次のリリースがなくなると (この例では 2.11)、古いリリース (この例では 2.10) は維持されなくなります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:24 -msgid "If you are using a release of Ansible that is no longer maintained, we strongly encourage you to upgrade as soon as possible in order to benefit from the latest features and security fixes." -msgstr "メンテナンスされていない Ansible のリリースを使用している場合には、最新の機能やセキュリティー修正からの恩恵を受けられるようにできるだけ早くアップグレードすることを強く推奨します。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:28 -msgid "Older, unmaintained versions of Ansible can contain unfixed security vulnerabilities (*CVE*)." -msgstr "メンテナンスのない、以前の Ansible バージョンには、未修正のセキュリティーの脆弱性が含まれている可能性があります (*CVE*)。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:31 -msgid "You can refer to the :ref:`porting guides` for tips on updating your Ansible playbooks to run on newer versions. For Ansible 2.10 and later releases, you can install the Ansible package with ``pip``. See :ref:`intro_installation_guide` for details. For older releases, You can download the Ansible release from ``_." -msgstr "Ansible Playbook を更新して新しいバージョンで実行するときのヒントについては、「:ref:`ポーティングガイド`」を参照してください。Ansible 2.10 以降のリリースでは、``pip`` で Ansible パッケージをインストールできます。詳細は、「:ref:`intro_installation_guide`」を参照してください。古いリリースでは、Ansible リリースは ``_ からダウンロードできます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:37 -msgid "This table links to the release notes for each major Ansible release. These release notes (changelogs) contain the dates and significant changes in each minor release." -msgstr "以下の表には、Ansible の各メジャーリリースのリリースノートへのリンクが含まれています。このようなリリースノート (変更ログ) には、各マイナーリリースの日付や、大きな変更が含まれます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:40 -msgid "Ansible Release" -msgstr "Ansible リリース" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:40 -#: ../../rst/reference_appendices/release_and_maintenance.rst:104 -msgid "Status" -msgstr "ステータス" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:42 -#: ../../rst/reference_appendices/release_and_maintenance.rst:106 -msgid "devel" -msgstr "devel" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:42 -msgid "In development (2.11 unreleased, trunk)" -msgstr "開発中 (未リリースの 2.11 (trunk))" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:43 -msgid "`2.10 Release Notes`_" -msgstr "`2.10 リリースノート`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:43 -msgid "In development (2.10 alpha/beta)" -msgstr "開発 (2.10 アルファ/ベータ)" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:44 -msgid "`2.9 Release Notes`_" -msgstr "`2.9 リリースノート`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:44 -#: ../../rst/reference_appendices/release_and_maintenance.rst:107 -msgid "Maintained (security **and** general bug fixes)" -msgstr "メンテナンス対象 (セキュリティー **および** 一般的なバグの修正)" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:45 -msgid "`2.8 Release Notes`_" -msgstr "`2.8 リリースノート`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:45 -msgid "Maintained (security fixes)" -msgstr "メンテナンス対象 (セキュリティーの修正)" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:46 -msgid "`2.7 Release Notes`_" -msgstr "`2.7 リリースノート`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:46 -#: ../../rst/reference_appendices/release_and_maintenance.rst:47 -#: ../../rst/reference_appendices/release_and_maintenance.rst:48 -#: ../../rst/reference_appendices/release_and_maintenance.rst:49 -msgid "Unmaintained (end of life)" -msgstr "メンテナンス対象外 (エンドオフライフ)" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:47 -msgid "`2.6 Release Notes`_" -msgstr "`2.6 リリースノート`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:48 -msgid "`2.5 Release Notes`_" -msgstr "`2.5 リリースノート`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:49 -msgid "<2.5" -msgstr "2.5 より前のバージョン" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:68 -msgid "ansible-core release cycle" -msgstr "ansible-core リリースサイクル" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:70 -msgid "``ansible-core`` is developed and released on a flexible release cycle. This cycle can be extended in order to allow for larger changes to be properly implemented and tested before a new release is made available. See :ref:`roadmaps` for upcoming release details." -msgstr "``ansible-core`` は、柔軟なリリースサイクルで開発およびリリースされます。このサイクルは、大規模な変更を正しく実装して、テストしてから新しいリリースが公開されるように、延長することが可能です。今後のリリースの詳細は、「:ref:`roadmaps`」を参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:74 -msgid "``ansible-core`` has a graduated maintenance structure that extends to three major releases. For more information, read about the :ref:`development_and_stable_version_maintenance_workflow` or see the chart in :ref:`release_schedule` for the degrees to which current releases are maintained." -msgstr "``ansible-core`` には、3 つのメジャーリリースで展開される段階的なメンテナンス構造があります。詳細は、「:ref:`development_and_stable_version_maintenance_workflow`」を参照してください。また、現在のリリースがどの程度メンテナンスされているかについては、:ref:`release_schedule` の表を参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:78 -msgid "If you are using a release of ``ansible-core`` that is no longer maintained, we strongly encourage you to upgrade as soon as possible in order to benefit from the latest features and security fixes." -msgstr "メンテナンスされなくなった ``ansible-core`` のリリースを使用している場合は、最新の機能やセキュリティー修正からの恩恵を受けられるようにできるだけ早くアップグレードすることが強く推奨されます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:82 -msgid "Older, unmaintained versions of ``ansible-core`` can contain unfixed security vulnerabilities (*CVE*)." -msgstr "メンテナンスされていない、以前の ``ansible-core`` バージョンには、未修正のセキュリティーの脆弱性が含まれている可能性があります (*CVE*)。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:85 -msgid "You can refer to the :ref:`porting guides` for tips on updating your Ansible playbooks to run on newer versions." -msgstr "Ansible Playbook を更新して新しいバージョンで実行するときのヒントは、「:ref:`ポーティングガイド`」を参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:88 -msgid "You can install ``ansible-core`` with ``pip``. See :ref:`intro_installation_guide` for details." -msgstr "``pip`` で ``ansible-core`` をインストールできます。詳細は、「:ref:`intro_installation_guide`」を参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:90 -msgid "``ansible-core`` maintenance continues for 3 releases. Thus the latest release receives security and general bug fixes when it is first released, security and critical bug fixes when the next ``ansible-core`` version is released, and **only** security fixes once the follow on to that version is released." -msgstr "``ansible-core`` メンテナンスは 3 リリース期間、継続します。つまり、最新のリリースでは、最初のリリース時にセキュリティーおよび一般的なバグ修正が、次回の ``ansible-core`` バージョンのリリース時に、セキュリティーと重要なバグ修正が、その次のバージョンのリリース時にはセキュリティー修正 **のみ** が提供されます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:99 -msgid "This table links to the release notes for each major ``ansible-core`` release. These release notes (changelogs) contain the dates and significant changes in each minor release." -msgstr "以下の表には、``ansible-core`` の各メジャーリリースのリリースノートへのリンクが含まれています。このようなリリースノート (変更ログ) には、各マイナーリリースの日付や、大きな変更が含まれます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:104 -msgid "``ansible-core`` / ``ansible-base`` Release" -msgstr "``ansible-core`` / ``ansible-base`` リリース" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:106 -msgid "In development (ansible-core 2.11 unreleased, trunk)" -msgstr "開発中 (未リリースの ansible-core 2.11 (trunk))" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:107 -msgid "`2.10 ansible-base Release Notes`_" -msgstr "`2.10 ansible-base Release Notes`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:119 -msgid "Development and stable version maintenance workflow" -msgstr "開発版および安定版のメンテナンスワークフロー" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:121 -msgid "The Ansible community develops and maintains Ansible and ``ansible-core`` on GitHub_." -msgstr "Ansible コミュニティーは、GitHub_ で Ansible および ``ansible-core`` を開発して維持します。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:123 -msgid "Collection updates (new modules, plugins, features and bugfixes) will always be integrated in what will become the next version of Ansible. This work is tracked within the individual collection repositories." -msgstr "コレクションの更新 (新しいモジュール、プラグイン、機能、バグ修正) は常に、Ansible の次のバージョンに統合されます。この作業は、個々のコレクションリポジトリー内で追跡されます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:125 -msgid "Ansible and ``ansible-core`` provide bugfixes and security improvements for the most recent major release. The previous major release of ``ansible-core`` will only receive fixes for security issues and critical bugs. ``ansible-core`` only applies security fixes to releases which are two releases old. This work is tracked on the ``stable-`` git branches." -msgstr "Ansible と ``ansible-core`` は、最新のメジャーリリースに対するバグ修正およびセキュリティーの改善を提供します。``ansible-core`` の 1 つ前のメジャーリリースでは、セキュリティー問題や重要なバグの修正のみが含まれます。``ansible-core`` では、2 リリース前のリリースに対してのみセキュリティー修正が適用されます。この作業は ``stable-`` の git ブランチで追跡されています。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:132 -msgid "The fixes that land in maintained stable branches will eventually be released as a new version when necessary." -msgstr "維持される安定版のブランチに保存された修正は、最終的に、必要に応じて新しいバージョンとしてリリースされます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:135 -msgid "Note that while there are no guarantees for providing fixes for unmaintained releases of Ansible, there can sometimes be exceptions for critical issues." -msgstr "維持されない Ansible リリースに修正が提供されるという保証はありませんが、重要な問題については例外対応となる可能性がある点に注意してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:143 -msgid "Changelogs" -msgstr "変更ログ (Changelog)" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:145 -msgid "We generate changelogs based on fragments. Here is the generated changelog for 2.9_ as an example. When creating new features or fixing bugs, create a changelog fragment describing the change. A changelog entry is not needed for new modules or plugins. Details for those items will be generated from the module documentation." -msgstr "変更ログは、フラグメントに基づいて生成されます。ここに例として 2.9_ の生成された変更ログがあります。新しい機能を作成したり、バグを修正したりするときは、変更点を記述した変更ログフラグメントを作成します。変更ログのエントリーは、新しいモジュールやプラグインには必要ありません。それらの項目の詳細は、モジュールのドキュメントから生成されます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:147 -msgid "We've got :ref:`examples and instructions on creating changelog fragments ` in the Community Guide." -msgstr "コミュニティーガイドの :ref:`changelog フラグメントの作成例および指示 ` にあります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:151 -msgid "Release candidates" -msgstr "リリースの候補 (Release Candidate)" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:153 -msgid "Before a new release or version of Ansible or ``ansible-core`` can be done, it will typically go through a release candidate process." -msgstr "Ansible または ``ansible-core`` の新規リリースまたはバージョンを公開する前に、通常はリリース候補のプロセスを行います。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:156 -msgid "This provides the Ansible community the opportunity to test these releases and report bugs or issues they might come across." -msgstr "このプロセスでは、Ansible コミュニティーは、これらのリリースをテストして、今後発生する可能性のあるバグや修正を報告する機会があります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:159 -msgid "Ansible and ``ansible-core`` tag the first release candidate (``RC1``) which is usually scheduled to last five business days. The final release is done if no major bugs or issues are identified during this period." -msgstr "Ansible および ``ansible-core`` は、最初のリリース候補のタグ (``RC1``) が付けられます。通常、RC1 はリリース前の最後の 5 営業日にスケジュールされます。この期間に主要なバグや問題が特定されない場合は、最終的なリリースとなります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:163 -msgid "If there are major problems with the first candidate, a second candidate will be tagged (``RC2``) once the necessary fixes have landed. This second candidate lasts for a shorter duration than the first. If no problems have been reported after two business days, the final release is done." -msgstr "最初の候補に大きな問題がある場合は、必要な修正がプッシュされた時点で、2 番目の候補のタグ (``RC2``) が付けられます。2 番目の候補は、1 番目よりも期間は短くなります。2 営業日が経過して問題が報告されない場合は、最終的なリリースとなります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:169 -msgid "More release candidates can be tagged as required, so long as there are bugs that the Ansible or ``ansible-core`` core maintainers consider should be fixed before the final release." -msgstr "Ansible または ``ansible-core`` の中心となるメンテナーが最終リリース前に修正が必要とみなしたバグがある場合は、必要に応じて追加のリリース候補タグを付けることができます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:176 -msgid "Feature freeze" -msgstr "機能フリーズ" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:178 -msgid "While there is a pending release candidate, the focus of core developers and maintainers will on fixes towards the release candidate." -msgstr "保留中のリリース候補がある場合は、中心となる開発者やメンテナーは、リリース候補に向けた修正に焦点を当てます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:181 -msgid "Merging new features or fixes that are not related to the release candidate may be delayed in order to allow the new release to be shipped as soon as possible." -msgstr "できるだけ早く新規リリースを公開するために、リリース候補に関連のない新機能や修正のマージが遅れる可能性があります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:186 -msgid "Deprecation Cycle" -msgstr "非推奨サイクル" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:188 -msgid "Sometimes we need to remove a feature, normally in favor of a reimplementation that we hope does a better job. To do this we have a deprecation cycle. First we mark a feature as 'deprecated'. This is normally accompanied with warnings to the user as to why we deprecated it, what alternatives they should switch to and when (which version) we are scheduled to remove the feature permanently." -msgstr "機能を削除する必要がある場合があります。通常、再実装してジョブ実行の改善を希望する場合です。これを行うために、非推奨のサイクルがあります。まず、機能を「非推奨」としてマークします。これには通常、非推奨になった理由、ユーザーが切り替える必要のある代替手段、および機能を完全に削除する予定の時期 (バージョン) に関する警告が伴います。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:194 -msgid "Ansible deprecation cycle" -msgstr "Ansible 非推奨サイクル" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:196 -msgid "Since Ansible is a package of individual collections, the deprecation cycle depends on the collection maintainers. We recommend the collection maintainers deprecate a feature in one Ansible major version and do not remove that feature for one year, or at least until the next major Ansible version. For example, deprecate the feature in 2.10.2, and do not remove the feature until 2.12.0. Collections should use semantic versioning, such that the major collection version cannot be changed within an Ansible major version. Thus the removal should not happen before the next major Ansible release. This is up to each collection maintainer and cannot be guaranteed." -msgstr "Ansible は個別のコレクションのパッケージであるため、非推奨のサイクルはコレクションのメンテナーによって異なります。コレクションメンテナーは 1 つの Ansible メジャーバージョンでこの機能を非推奨にし、1 年間でその機能を削除するか、少なくとも次の Ansible バージョンまでに削除しないことを推奨します。たとえば、2.10.2 ではこの機能を非推奨にした場合は、2.12.0 までの機能を削除しないでください。コレクションはセマンティックバージョニングを使用する必要があります。したがって、メジャーコレクションバージョンは、Ansible メジャーバージョン内で変更できません。したがって、次のメジャーリリースの Ansible リリースの前に削除することはできません。これは、各コレクションのメンテナーの役割であり、保証されているものではありません。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:199 -msgid "ansible-core deprecation cycle" -msgstr "ansible-core 非推奨サイクル" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:201 -msgid "The cycle is normally across 4 feature releases (2.x.y, where the x marks a feature release and the y a bugfix release), so the feature is normally removed in the 4th release after we announce the deprecation. For example, something deprecated in 2.9 will be removed in 2.13, assuming we don't jump to 3.x before that point. The tracking is tied to the number of releases, not the release numbering." -msgstr "サイクルは通常 4 つの機能リリース (たとえば 2.x.y では、x は機能リリースを示し、y はバグ修正リリースを示します) にまたがるため、機能は通常、非推奨を発表してから 4 番目のリリースで削除されます。たとえば、2.9 で非推奨になったものは、バージョンがそのまま 3.x に続くと仮定すると、2.13 で削除されます。追跡は、リリース番号ではなく、リリースの数に関連付けられています。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:206 -msgid "For modules/plugins, we keep the documentation after the removal for users of older versions." -msgstr "モジュール/プラグインについては、以前のバージョンをご利用の方のために、削除後もドキュメントは保持します。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:210 -msgid ":ref:`community_committer_guidelines`" -msgstr ":ref:`community_committer_guidelines`" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:211 -msgid "Guidelines for Ansible core contributors and maintainers" -msgstr "Ansible で中心となる貢献者およびメンテナー向けガイドライン" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:212 -msgid ":ref:`testing_strategies`" -msgstr ":ref:`testing_strategies`" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:213 -msgid "Testing strategies" -msgstr "ストラテジーのテスト" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:214 -msgid ":ref:`ansible_community_guide`" -msgstr ":ref:`ansible_community_guide`" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:215 -msgid "Community information and contributing" -msgstr "コミュニティー情報および貢献" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:216 -msgid "`Development Mailing List `_" -msgstr "`開発メーリングリスト `_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:217 -msgid "Mailing list for development topics" -msgstr "開発トピックのメーリングリスト" - -#: ../../rst/reference_appendices/special_variables.rst:4 -msgid "Special Variables" -msgstr "特別な変数" - -#: ../../rst/reference_appendices/special_variables.rst:7 -msgid "Magic variables" -msgstr "マジック変数" - -#: ../../rst/reference_appendices/special_variables.rst:8 -msgid "These variables cannot be set directly by the user; Ansible will always override them to reflect internal state." -msgstr "マジック変数は、ユーザーが直接設定できません。Ansible がシステム内の状態を反映してこの変数を常にオーバーライドします。" - -#: ../../rst/reference_appendices/special_variables.rst:11 -msgid "ansible_check_mode" -msgstr "ansible_check_mode" - -#: ../../rst/reference_appendices/special_variables.rst:11 -msgid "Boolean that indicates if we are in check mode or not" -msgstr "チェックモードかどうかを指定するブール値" - -#: ../../rst/reference_appendices/special_variables.rst:14 -msgid "ansible_config_file" -msgstr "ansible_config_file" - -#: ../../rst/reference_appendices/special_variables.rst:14 -msgid "The full path of used Ansible configuration file" -msgstr "Ansbile 設定ファイルに使用するフルパス" - -#: ../../rst/reference_appendices/special_variables.rst:17 -msgid "ansible_dependent_role_names" -msgstr "ansible_dependent_role_names" - -#: ../../rst/reference_appendices/special_variables.rst:17 -msgid "The names of the roles currently imported into the current play as dependencies of other plays" -msgstr "他のプレイの依存関係として現在のプレイに現在インポートされているロールの名前" - -#: ../../rst/reference_appendices/special_variables.rst:20 -msgid "ansible_diff_mode" -msgstr "ansible_diff_mode" - -#: ../../rst/reference_appendices/special_variables.rst:20 -msgid "Boolean that indicates if we are in diff mode or not" -msgstr "diff モードかどうかを指定するブール値" - -#: ../../rst/reference_appendices/special_variables.rst:23 -msgid "ansible_forks" -msgstr "ansible_forks" - -#: ../../rst/reference_appendices/special_variables.rst:23 -msgid "Integer reflecting the number of maximum forks available to this run" -msgstr "今回の実行で利用可能な最大フォーク数 (整数)" - -#: ../../rst/reference_appendices/special_variables.rst:26 -msgid "ansible_inventory_sources" -msgstr "ansible_inventory_sources" - -#: ../../rst/reference_appendices/special_variables.rst:26 -msgid "List of sources used as inventory" -msgstr "インベントリーとして使用されるソースの一覧" - -#: ../../rst/reference_appendices/special_variables.rst:29 -msgid "ansible_limit" -msgstr "ansible_limit" - -#: ../../rst/reference_appendices/special_variables.rst:29 -msgid "Contents of the ``--limit`` CLI option for the current execution of Ansible" -msgstr "Ansible の現在の実行に対して、CLI オプション ``--limit`` として指定する内容" - -#: ../../rst/reference_appendices/special_variables.rst:32 -msgid "ansible_loop" -msgstr "ansible_loop" - -#: ../../rst/reference_appendices/special_variables.rst:32 -msgid "A dictionary/map containing extended loop information when enabled via ``loop_control.extended``" -msgstr "``loop_control.extended`` で有効にした場合に loop の拡張情報を含むディクショナリー/マップ" - -#: ../../rst/reference_appendices/special_variables.rst:35 -msgid "ansible_loop_var" -msgstr "ansible_loop_var" - -#: ../../rst/reference_appendices/special_variables.rst:35 -msgid "The name of the value provided to ``loop_control.loop_var``. Added in ``2.8``" -msgstr "``loop_control.loop_var`` に渡す値の名前。``2.8`` に追加。" - -#: ../../rst/reference_appendices/special_variables.rst:38 -msgid "ansible_index_var" -msgstr "ansible_index_var" - -#: ../../rst/reference_appendices/special_variables.rst:38 -msgid "The name of the value provided to ``loop_control.index_var``. Added in ``2.9``" -msgstr "``loop_control.index_var`` に渡す値の名前。``2.9`` に追加。" - -#: ../../rst/reference_appendices/special_variables.rst:44 -msgid "ansible_parent_role_names" -msgstr "ansible_parent_role_names" - -#: ../../rst/reference_appendices/special_variables.rst:41 -msgid "When the current role is being executed by means of an :ref:`include_role ` or :ref:`import_role ` action, this variable contains a list of all parent roles, with the most recent role (in other words, the role that included/imported this role) being the first item in the list. When multiple inclusions occur, this list lists the *last* role (in other words, the role that included this role) as the *first* item in the list. It is also possible that a specific role exists more than once in this list." -msgstr "現在のロールが、:ref:`include_role ` アクションまたは :ref:`import_role ` アクションによって実行されている場合、この変数にはすべての親ロールのリストが含まれ、最新のロール (つまり、このロールを含む/インポートしたロール) がリストの最初の項目になります。複数の包含が発生する場合、このリストには、*最後の*ロール (つまり、このロールを含むロール) がリストの*最初の*項目として挙げられます。このリストに特定の役割が複数存在する可能性もあります。" - -#: ../../rst/reference_appendices/special_variables.rst:44 -msgid "For example: When role **A** includes role **B**, inside role B, ``ansible_parent_role_names`` will equal to ``['A']``. If role **B** then includes role **C**, the list becomes ``['B', 'A']``." -msgstr "たとえば、ロール **A** にロール **B** が含まれる場合は、ロール B 内の ``ansible_parent_role_names`` は ``['A']`` と等しくなります。次にロール **B** にロール **C** が含まれると、一覧は ``['B', 'A']`` になります。" - -#: ../../rst/reference_appendices/special_variables.rst:48 -msgid "ansible_parent_role_paths" -msgstr "ansible_parent_role_paths" - -#: ../../rst/reference_appendices/special_variables.rst:47 -msgid "When the current role is being executed by means of an :ref:`include_role ` or :ref:`import_role ` action, this variable contains a list of all parent roles, with the most recent role (in other words, the role that included/imported this role) being the first item in the list. Please refer to ``ansible_parent_role_names`` for the order of items in this list." -msgstr "現在のロールが :ref:`include_role ` アクションまたは :ref:`import_role ` アクションで実行されていると、この変数には親のロールの全一覧と、その一覧の最初の項目である最新のロール (つまり、このロールを追加/インポートしたロール) が含まれます。このリストの項目の順序は、「``ansible_parent_role_names``」を参照してください。" - -#: ../../rst/reference_appendices/special_variables.rst:51 -msgid "ansible_play_batch" -msgstr "ansible_play_batch" - -#: ../../rst/reference_appendices/special_variables.rst:51 -msgid "List of active hosts in the current play run limited by the serial, aka 'batch'. Failed/Unreachable hosts are not considered 'active'." -msgstr "シリアルで制限される現在のプレイ実行に含まれるアクティブなホスト一覧 (「バッチ」と呼ばれます)。失敗したホストや到達不可能なホストは、「アクティブ」とはみなされません。" - -#: ../../rst/reference_appendices/special_variables.rst:54 -msgid "ansible_play_hosts" -msgstr "ansible_play_hosts" - -#: ../../rst/reference_appendices/special_variables.rst:54 -msgid "List of hosts in the current play run, not limited by the serial. Failed/Unreachable hosts are excluded from this list." -msgstr "現在のプレイのホスト一覧は、シリアルによって制限されません。失敗したホストまたは到達不可能なホストはこの一覧から除外されます。" - -#: ../../rst/reference_appendices/special_variables.rst:57 -msgid "ansible_play_hosts_all" -msgstr "ansible_play_hosts_all" - -#: ../../rst/reference_appendices/special_variables.rst:57 -msgid "List of all the hosts that were targeted by the play" -msgstr "プレイが対象としたホストの一覧" - -#: ../../rst/reference_appendices/special_variables.rst:61 -msgid "ansible_play_role_names" -msgstr "ansible_play_role_names" - -#: ../../rst/reference_appendices/special_variables.rst:60 -msgid "The names of the roles currently imported into the current play. This list does **not** contain the role names that are implicitly included via dependencies." -msgstr "現在のプレイにインポートされているロール名。この一覧には、依存関係で暗黙的に含まれるロール名は **含まれません**。" - -#: ../../rst/reference_appendices/special_variables.rst:64 -msgid "ansible_playbook_python" -msgstr "ansible_playbook_python" - -#: ../../rst/reference_appendices/special_variables.rst:64 -msgid "The path to the python interpreter being used by Ansible on the controller" -msgstr "Ansible が使用する Python インタープリターへのコントローラー上のパス" - -#: ../../rst/reference_appendices/special_variables.rst:68 -msgid "ansible_role_names" -msgstr "ansible_role_names" - -#: ../../rst/reference_appendices/special_variables.rst:67 -msgid "The names of the roles currently imported into the current play, or roles referenced as dependencies of the roles imported into the current play." -msgstr "現在のプレイに現在インポートされているロール名、または現在のプレイにインポートされているロールの依存関係として参照されているロール名" - -#: ../../rst/reference_appendices/special_variables.rst:71 -msgid "ansible_role_name" -msgstr "ansible_role_name" - -#: ../../rst/reference_appendices/special_variables.rst:71 -msgid "The fully qualified collection role name, in the format of ``namespace.collection.role_name``" -msgstr "``namespace.collection.role_name`` の形式である完全修飾コレクションのロール名" - -#: ../../rst/reference_appendices/special_variables.rst:74 -msgid "ansible_collection_name" -msgstr "ansible_collection_name" - -#: ../../rst/reference_appendices/special_variables.rst:74 -msgid "The name of the collection the task that is executing is a part of. In the format of ``namespace.collection``" -msgstr "実行しているタスクが一部であるコレクションの名前 (``namespace.collection`` の形式)。" - -#: ../../rst/reference_appendices/special_variables.rst:77 -msgid "ansible_run_tags" -msgstr "ansible_run_tags" - -#: ../../rst/reference_appendices/special_variables.rst:77 -msgid "Contents of the ``--tags`` CLI option, which specifies which tags will be included for the current run. Note that if ``--tags`` is not passed, this variable will default to ``[\"all\"]``." -msgstr "CLI オプション ``--tags`` の内容。現在の実行に含まれるタグを指定します。``--tags`` が渡されない場合、この変数はデフォルトで ``[\"all\"]`` になります。" - -#: ../../rst/reference_appendices/special_variables.rst:80 -msgid "ansible_search_path" -msgstr "ansible_search_path" - -#: ../../rst/reference_appendices/special_variables.rst:80 -msgid "Current search path for action plugins and lookups, in other words, where we search for relative paths when you do ``template: src=myfile``" -msgstr "action プラグインとルックアップの現在の検索パス。つまり、``template: src=myfile`` を指定したときに検索する相対パスです。" - -#: ../../rst/reference_appendices/special_variables.rst:83 -msgid "ansible_skip_tags" -msgstr "ansible_skip_tags" - -#: ../../rst/reference_appendices/special_variables.rst:83 -msgid "Contents of the ``--skip-tags`` CLI option, which specifies which tags will be skipped for the current run." -msgstr "現在の実行で省略するタグを指定する ``--skip-tags`` CLI オプションの内容。" - -#: ../../rst/reference_appendices/special_variables.rst:86 -msgid "ansible_verbosity" -msgstr "ansible_verbosity" - -#: ../../rst/reference_appendices/special_variables.rst:86 -msgid "Current verbosity setting for Ansible" -msgstr "Ansible の現在の詳細レベル設定" - -#: ../../rst/reference_appendices/special_variables.rst:89 -msgid "ansible_version" -msgstr "ansible_version" - -#: ../../rst/reference_appendices/special_variables.rst:89 -msgid "Dictionary/map that contains information about the current running version of ansible, it has the following keys: full, major, minor, revision and string." -msgstr "現在実行している Ansible のバージョンに関する情報を含むディクショナリー/マップ。full、major、minor、revision、string などのキーが含まれます。" - -#: ../../rst/reference_appendices/special_variables.rst:92 -msgid "group_names" -msgstr "group_names" - -#: ../../rst/reference_appendices/special_variables.rst:92 -msgid "List of groups the current host is part of" -msgstr "現在のホストが所属するグループの一覧" - -#: ../../rst/reference_appendices/special_variables.rst:95 -msgid "groups" -msgstr "groups" - -#: ../../rst/reference_appendices/special_variables.rst:95 -msgid "A dictionary/map with all the groups in inventory and each group has the list of hosts that belong to it" -msgstr "インベントリー内の全グループを含むディクショナリー/マップ。各グループには、所属するホストの一覧が含まれます。" - -#: ../../rst/reference_appendices/special_variables.rst:98 -msgid "hostvars" -msgstr "hostvars" - -#: ../../rst/reference_appendices/special_variables.rst:98 -msgid "A dictionary/map with all the hosts in inventory and variables assigned to them" -msgstr "インベントリー内の全ホスト、そのホストに割当てられた変数を含むディクショナリー/マップ。" - -#: ../../rst/reference_appendices/special_variables.rst:101 -msgid "inventory_hostname" -msgstr "inventory_hostname" - -#: ../../rst/reference_appendices/special_variables.rst:101 -msgid "The inventory name for the 'current' host being iterated over in the play" -msgstr "プレイで繰り返される「現在」のホストのイベントリー名" - -#: ../../rst/reference_appendices/special_variables.rst:104 -msgid "inventory_hostname_short" -msgstr "inventory_hostname_short" - -#: ../../rst/reference_appendices/special_variables.rst:104 -msgid "The short version of `inventory_hostname`" -msgstr "`inventory_hostname` の短縮版" - -#: ../../rst/reference_appendices/special_variables.rst:107 -msgid "inventory_dir" -msgstr "inventory_dir" - -#: ../../rst/reference_appendices/special_variables.rst:107 -msgid "The directory of the inventory source in which the `inventory_hostname` was first defined" -msgstr "`inventory_hostname` を最初に定義したインベントリーソースのディレクトリー" - -#: ../../rst/reference_appendices/special_variables.rst:110 -msgid "inventory_file" -msgstr "inventory_file" - -#: ../../rst/reference_appendices/special_variables.rst:110 -msgid "The file name of the inventory source in which the `inventory_hostname` was first defined" -msgstr "`inventory_hostname` を最初に定義したインベントリーソースのファイル名" - -#: ../../rst/reference_appendices/special_variables.rst:113 -msgid "omit" -msgstr "omit" - -#: ../../rst/reference_appendices/special_variables.rst:113 -msgid "Special variable that allows you to 'omit' an option in a task, for example ``- user: name=bob home={{ bobs_home|default(omit) }}``" -msgstr "タスクのオプションを「省略」できるようにする特別変数 (つまり ``- user: name=bob home={{ bobs_home|default(omit) }}``)" - -#: ../../rst/reference_appendices/special_variables.rst:116 -msgid "play_hosts" -msgstr "play_hosts" - -#: ../../rst/reference_appendices/special_variables.rst:116 -msgid "Deprecated, the same as ansible_play_batch" -msgstr "非推奨。ansible_play_batch と同じです。" - -#: ../../rst/reference_appendices/special_variables.rst:119 -msgid "ansible_play_name" -msgstr "ansible_play_name" - -#: ../../rst/reference_appendices/special_variables.rst:119 -msgid "The name of the currently executed play. Added in ``2.8``. (`name` attribute of the play, not file name of the playbook.)" -msgstr "現在実行されたプレイの名前です。``2.8`` で追加されました (Playbook のファイル名ではなく、プレイの`name` 属性)。" - -#: ../../rst/reference_appendices/special_variables.rst:122 -msgid "The path to the directory of the playbook that was passed to the ``ansible-playbook`` command line." -msgstr "``ansible-playbook`` コマンドラインに渡した Playbook のディレクトリーへのパス" - -#: ../../rst/reference_appendices/special_variables.rst:125 -msgid "role_name" -msgstr "role_name" - -#: ../../rst/reference_appendices/special_variables.rst:125 -msgid "The name of the role currently being executed." -msgstr "現在実行中のロール名。" - -#: ../../rst/reference_appendices/special_variables.rst:128 -msgid "role_names" -msgstr "role_names" - -#: ../../rst/reference_appendices/special_variables.rst:128 -msgid "Deprecated, the same as ansible_play_role_names" -msgstr "非推奨。ansible_play_role_names と同じです。" - -#: ../../rst/reference_appendices/special_variables.rst:131 -msgid "role_path" -msgstr "role_path" - -#: ../../rst/reference_appendices/special_variables.rst:131 -msgid "The path to the dir of the currently running role" -msgstr "現在実行中のロールのディレクトリーへのパス" - -#: ../../rst/reference_appendices/special_variables.rst:135 -msgid "These are variables that contain information pertinent to the current host (`inventory_hostname`). They are only available if gathered first. See :ref:`vars_and_facts` for more information." -msgstr "これは、現在のホストに関連する情報を含む変数です (`inventory_hostname`)。この変数は、最初に収集した場合にのみ利用できます。詳細は、「:ref:`vars_and_facts`」を参照してください。" - -#: ../../rst/reference_appendices/special_variables.rst:138 -msgid "Contains any facts gathered or cached for the `inventory_hostname` Facts are normally gathered by the :ref:`setup ` module automatically in a play, but any module can return facts." -msgstr "`inventory_hostname` 向けに収集またはキャッシュしたファクトが含まれます。ファクトは通常、プレイで自動的に :ref:`setup ` モジュールにより収集されますが、どのモジュールでもファクトを返すことができます。" - -#: ../../rst/reference_appendices/special_variables.rst:144 -msgid "ansible_local" -msgstr "ansible_local" - -#: ../../rst/reference_appendices/special_variables.rst:142 -msgid "Contains any 'local facts' gathered or cached for the `inventory_hostname`. The keys available depend on the custom facts created. See the :ref:`setup ` module and :ref:`local_facts` for more details." -msgstr "`inventory_hostname` が収集またはキャッシュする「ローカルファクト」が含まれます。利用可能なキーは、作成したカスタムファクトによって異なります。詳細は、:ref:`setup ` モジュールおよび :ref:`local_facts` モジュールを参照してください。" - -#: ../../rst/reference_appendices/special_variables.rst:149 -msgid "Connection variables" -msgstr "接続変数" - -#: ../../rst/reference_appendices/special_variables.rst:150 -msgid "Connection variables are normally used to set the specifics on how to execute actions on a target. Most of them correspond to connection plugins, but not all are specific to them; other plugins like shell, terminal and become are normally involved. Only the common ones are described as each connection/become/shell/etc plugin can define its own overrides and specific variables. See :ref:`general_precedence_rules` for how connection variables interact with :ref:`configuration settings`, :ref:`command-line options`, and :ref:`playbook keywords`." -msgstr "接続変数は通常、ターゲットでのアクション実行方法を具体的に設定する時に使用します。接続変数の大半が connection プラグインに対応していますが、connection プラグイン固有のものではなく、通常は shell、terminal、become などの他のプラグインも使用します。各 connection/become/shell/etc プラグインは、自身のオーバーライドや固有の変数を定義するため、一般的なもののみを説明します。接続変数が :ref:`configuration settings`、:ref:`command-line options`、および :ref:`playbook keywords` と対話する方法は、「:ref:`general_precedence_rules`」を参照してください。" - -#: ../../rst/reference_appendices/special_variables.rst:155 -msgid "ansible_become_user" -msgstr "ansible_become_user" - -#: ../../rst/reference_appendices/special_variables.rst:155 -msgid "The user Ansible 'becomes' after using privilege escalation. This must be available to the 'login user'." -msgstr "特権昇格後に Ansible がなる (become) ユーザー。このユーザーは、「ログインユーザー」が利用できるようになっている必要があります。" - -#: ../../rst/reference_appendices/special_variables.rst:158 -msgid "ansible_connection" -msgstr "ansible_connection" - -#: ../../rst/reference_appendices/special_variables.rst:158 -msgid "The connection plugin actually used for the task on the target host." -msgstr "ターゲットホストでタスクに実際に使用する connection プラグイン" - -#: ../../rst/reference_appendices/special_variables.rst:161 -msgid "ansible_host" -msgstr "ansible_host" - -#: ../../rst/reference_appendices/special_variables.rst:161 -msgid "The ip/name of the target host to use instead of `inventory_hostname`." -msgstr "`inventory_hostname` の代わりに使用するターゲットホストの ip/名前" - -#: ../../rst/reference_appendices/special_variables.rst:164 -msgid "ansible_python_interpreter" -msgstr "ansible_python_interpreter" - -#: ../../rst/reference_appendices/special_variables.rst:164 -msgid "The path to the Python executable Ansible should use on the target host." -msgstr "Ansible がターゲットホストで使用すべき Python 実行ファイルへのパス" - -#: ../../:1 -msgid "ansible_user" -msgstr "ansible_user" - -#: ../../rst/reference_appendices/special_variables.rst:167 -msgid "The user Ansible 'logs in' as." -msgstr "Ansible がログインするユーザー" - -#: ../../rst/reference_appendices/test_strategies.rst:4 -msgid "Testing Strategies" -msgstr "ストラテジーのテスト" - -#: ../../rst/reference_appendices/test_strategies.rst:9 -msgid "Integrating Testing With Ansible Playbooks" -msgstr "Ansible Playbook とテストの統合" - -#: ../../rst/reference_appendices/test_strategies.rst:11 -msgid "Many times, people ask, \"how can I best integrate testing with Ansible playbooks?\" There are many options. Ansible is actually designed to be a \"fail-fast\" and ordered system, therefore it makes it easy to embed testing directly in Ansible playbooks. In this chapter, we'll go into some patterns for integrating tests of infrastructure and discuss the right level of testing that may be appropriate." -msgstr "「Ansible Playbook とテストを最適な方法で統合するにはどうしたらいいのか」との質問が多数寄せられます。統合のオプションは、多数あります。Ansible は実際には、「フェイルファースト (Fail fast)」の順番ベースのシステムとなるように設計されているため、Ansible Playbookに直接、テストを簡単に埋め込むことができます。本章では、インフラストラクチャーのテスト統合パターンについて触れ、適切にテストするための正しいレベルについても説明します。" - -#: ../../rst/reference_appendices/test_strategies.rst:15 -msgid "This is a chapter about testing the application you are deploying, not the chapter on how to test Ansible modules during development. For that content, please hop over to the Development section." -msgstr "以下の章は、デプロイするアプリケーションをテストする方法を説明しており、開発時に Ansible モジュールをテストする方法は説明していません。Ansible のテスト方法は、開発のセクションで参照してください。" - -#: ../../rst/reference_appendices/test_strategies.rst:17 -msgid "By incorporating a degree of testing into your deployment workflow, there will be fewer surprises when code hits production and, in many cases, tests can be leveraged in production to prevent failed updates from migrating across an entire installation. Since it's push-based, it's also very easy to run the steps on the localhost or testing servers. Ansible lets you insert as many checks and balances into your upgrade workflow as you would like to have." -msgstr "開発のワークフローにテストをある程度組み込むことで、実稼働環境でコードを使用時に、慌てることが少なくなります。多くの場合は、実稼働環境でテストを活用して、更新の失敗が、インストール全体に移行されてしまうのを防ぐことができます。また、プッシュベースになっているため、ローカルホストやテストサーバーで手順を非常に簡単に実行することができます。Ansible は、多くのチェックを挿入できるため、アップグレードのワークフローを希望のレベルに調節できます。" - -#: ../../rst/reference_appendices/test_strategies.rst:22 -msgid "The Right Level of Testing" -msgstr "適切なレベルのテスト" - -#: ../../rst/reference_appendices/test_strategies.rst:24 -msgid "Ansible resources are models of desired-state. As such, it should not be necessary to test that services are started, packages are installed, or other such things. Ansible is the system that will ensure these things are declaratively true. Instead, assert these things in your playbooks." -msgstr "Ansible リソースは、任意の状態のモデルです。サービスの起動、パッケージのインストールなどのテストを行う必要はありません。Ansible は、上記の内容が True と宣言されていることを確認するシステムで、代わりに、以下の項目を Playbook にアサートします。" - -#: ../../rst/reference_appendices/test_strategies.rst:36 -msgid "If you think the service may not be started, the best thing to do is request it to be started. If the service fails to start, Ansible will yell appropriately. (This should not be confused with whether the service is doing something functional, which we'll show more about how to do later)." -msgstr "サービスが起動しない可能性があると思われる場合は、サービスの開始を要求するのが最善の方法です。サービスの開始に失敗した場合は、Ansible により随時指示がでます (これは、サービスが機能的なことを行っているかどうかと混同しないでください。これについては、後で詳しく説明します)。" - -#: ../../rst/reference_appendices/test_strategies.rst:43 -msgid "Check Mode As A Drift Test" -msgstr "ドリフトテストとしての check モード" - -#: ../../rst/reference_appendices/test_strategies.rst:45 -msgid "In the above setup, `--check` mode in Ansible can be used as a layer of testing as well. If running a deployment playbook against an existing system, using the `--check` flag to the `ansible` command will report if Ansible thinks it would have had to have made any changes to bring the system into a desired state." -msgstr "上記の設定では、Ansible の `--check` モードは、テストのレイヤーとしても使用できます。既存のシステムに対してデプロイメントの Playbook を実行する場合に `--check` フラグを `ansible` コマンドに使用すると、変更が加えられてシステムが適切な状態になっていると Ansible が判断しているかどうかをレポートします。" - -#: ../../rst/reference_appendices/test_strategies.rst:49 -msgid "This can let you know up front if there is any need to deploy onto the given system. Ordinarily, scripts and commands don't run in check mode, so if you want certain steps to execute in normal mode even when the `--check` flag is used, such as calls to the script module, disable check mode for those tasks::" -msgstr "このレポートにより、特定のシステムにデプロイメントが必要かどうかを事前に把握できます。check モードでは、一般的なスクリプトやコマンドは実行されないため、スクリプトモジュールへの呼び出しなど、`--check` フラグが使用されていても通常モードで特定の手順を実行する場合は、このようなタスクのチェックモードを無効にしてください::" - -#: ../../rst/reference_appendices/test_strategies.rst:61 -msgid "Modules That Are Useful for Testing" -msgstr "テストに便利なモジュール" - -#: ../../rst/reference_appendices/test_strategies.rst:63 -msgid "Certain playbook modules are particularly good for testing. Below is an example that ensures a port is open::" -msgstr "Playbook のモジュールでは、特にテストに適しているものもあります。以下の例は、ポートが開放されていることを確認します。" - -#: ../../rst/reference_appendices/test_strategies.rst:72 -msgid "Here's an example of using the URI module to make sure a web service returns::" -msgstr "以下の例は、URI モジュールを使用して、Web サービスが返されることを確認します。" - -#: ../../rst/reference_appendices/test_strategies.rst:83 -msgid "It's easy to push an arbitrary script (in any language) on a remote host and the script will automatically fail if it has a non-zero return code::" -msgstr "リモートホストで任意のスクリプト (言語は問わない) が簡単にプッシュされるため、ゼロ以外のリターンコードが指定されていると、スクリプトは自動的に失敗します。" - -#: ../../rst/reference_appendices/test_strategies.rst:90 -msgid "If using roles (you should be, roles are great!), scripts pushed by the script module can live in the 'files/' directory of a role." -msgstr "ロールを使用する場合 (ロールは便利なので使用を推奨)、スクリプトモジュールがプッシュするスクリプトは、ロールの「files/」ディレクトリーに配置されます。" - -#: ../../rst/reference_appendices/test_strategies.rst:92 -msgid "And the assert module makes it very easy to validate various kinds of truth::" -msgstr "また、アサートモジュールを使用すると、さまざまな真偽の検証が非常に簡単にできます。" - -#: ../../rst/reference_appendices/test_strategies.rst:104 -msgid "Should you feel the need to test for the existence of files that are not declaratively set by your Ansible configuration, the 'stat' module is a great choice::" -msgstr "Ansible 設定で設定が宣言されていないファイルの存在をテストする必要がある場合は、「stat」モジュールが最適です。" - -#: ../../rst/reference_appendices/test_strategies.rst:117 -msgid "As mentioned above, there's no need to check things like the return codes of commands. Ansible is checking them automatically. Rather than checking for a user to exist, consider using the user module to make it exist." -msgstr "上記のように、コマンドのリターンコードなどをチェックする必要はありません。Ansible がこのようなコードを自動的にチェックします。ユーザーの存在をチェックする代わりに、ユーザーモジュールを使用してユーザーを存在させます。" - -#: ../../rst/reference_appendices/test_strategies.rst:120 -msgid "Ansible is a fail-fast system, so when there is an error creating that user, it will stop the playbook run. You do not have to check up behind it." -msgstr "Ansible はフェイルファーストシステムであるため、ユーザーの作成時にエラーがあると、Playbook の実行が停止します。バックグラウンドで行われている内容を確認する必要はありません。" - -#: ../../rst/reference_appendices/test_strategies.rst:124 -msgid "Testing Lifecycle" -msgstr "ライフサイクルのテスト" - -#: ../../rst/reference_appendices/test_strategies.rst:126 -msgid "If writing some degree of basic validation of your application into your playbooks, they will run every time you deploy." -msgstr "アプリケーションの基本検証を Playbook に記述すると、デプロイ時に必ずこの検証が実行されます。" - -#: ../../rst/reference_appendices/test_strategies.rst:128 -msgid "As such, deploying into a local development VM and a staging environment will both validate that things are according to plan ahead of your production deploy." -msgstr "そのため、ローカルの開発仮想マシンやステージ環境にデプロイするといずれも、実稼働でのデプロイの前に計画通りに作業が進んでいるかどうかを検証します。" - -#: ../../rst/reference_appendices/test_strategies.rst:131 -msgid "Your workflow may be something like this::" -msgstr "ワークフローは、次のようになります。" - -#: ../../rst/reference_appendices/test_strategies.rst:138 -msgid "Something like an integration test battery should be written by your QA team if you are a production webservice. This would include things like Selenium tests or automated API tests and would usually not be something embedded into your Ansible playbooks." -msgstr "実稼働の Web サービスを使用する場合には、QA チームが同様の統合テストバッテリーを記述するようにしてください。このようなテストには Selenium テストや自動化 API テストなどが含まれ、通常は、Ansible Playbook に組み込まれているものではありません。" - -#: ../../rst/reference_appendices/test_strategies.rst:141 -msgid "However, it does make sense to include some basic health checks into your playbooks, and in some cases it may be possible to run a subset of the QA battery against remote nodes. This is what the next section covers." -msgstr "ただし、いくつかの基本的なヘルスチェックを Playbook に追加すると便利です。場合によっては、リモートノードに対して QA バッテリーのサブセットを実行することもできます。この点については、次のセクションで説明します。" - -#: ../../rst/reference_appendices/test_strategies.rst:145 -msgid "Integrating Testing With Rolling Updates" -msgstr "ローリングアップデートへのテストの統合" - -#: ../../rst/reference_appendices/test_strategies.rst:147 -msgid "If you have read into :ref:`playbooks_delegation` it may quickly become apparent that the rolling update pattern can be extended, and you can use the success or failure of the playbook run to decide whether to add a machine into a load balancer or not." -msgstr ":ref:`playbooks_delegation` を読むと、ローリングアップデートのパターンを拡張でき、また、Playbook 実行の成否でロードバランサーにマシンを 1 台追加するかどうかを決定できることが即座に明確になったことでしょう。" - -#: ../../rst/reference_appendices/test_strategies.rst:150 -msgid "This is the great culmination of embedded tests::" -msgstr "これは、組み込みテストの集大成です。" - -#: ../../rst/reference_appendices/test_strategies.rst:175 -msgid "Of course in the above, the \"take out of the pool\" and \"add back\" steps would be replaced with a call to an Ansible load balancer module or appropriate shell command. You might also have steps that use a monitoring module to start and end an outage window for the machine." -msgstr "上記では当然、「プールから取得する」手順や「追加し直す」手順は、Ansible のロードバランサーモジュールや、適切な shell コマンドの呼び出しに置き換えられます。また、マシンのサービス停止期間を開始/終了するモニタリングモジュールを使用する手順なども含まれている場合がありますが、" - -#: ../../rst/reference_appendices/test_strategies.rst:179 -msgid "However, what you can see from the above is that tests are used as a gate -- if the \"apply_testing_checks\" step is not performed, the machine will not go back into the pool." -msgstr "上記で分かるように、テストはゲートとして使用されています。つまり、「apply_testing_checks」の手順が実行されない場合は、マシンがプールに戻らないようになっています。" - -#: ../../rst/reference_appendices/test_strategies.rst:182 -msgid "Read the delegation chapter about \"max_fail_percentage\" and you can also control how many failing tests will stop a rolling update from proceeding." -msgstr "ローリングアップデートの続行を妨げるテストの失敗回数を制御できます。この点については、「max_fail_percentage」向けの章を参照してください。" - -#: ../../rst/reference_appendices/test_strategies.rst:185 -msgid "This above approach can also be modified to run a step from a testing machine remotely against a machine::" -msgstr "上記のアプローチを変更して、マシンに対してリモートのテストマシンから手順を実行することも可能です。" - -#: ../../rst/reference_appendices/test_strategies.rst:213 -msgid "In the above example, a script is run from the testing server against a remote node prior to bringing it back into the pool." -msgstr "上記の例では、プールにマシンを戻す前に、リモートのノードに対してテストサーバーからスクリプトを実行します。" - -#: ../../rst/reference_appendices/test_strategies.rst:216 -msgid "In the event of a problem, fix the few servers that fail using Ansible's automatically generated retry file to repeat the deploy on just those servers." -msgstr "問題が発生した場合には、Ansible が自動で生成した再試行ファイルを使用して、失敗したサーバー数台を修正し、そのサーバーだけにデプロイメントを繰り返し実行します。" - -#: ../../rst/reference_appendices/test_strategies.rst:220 -msgid "Achieving Continuous Deployment" -msgstr "継続的なデプロイメントの実現" - -#: ../../rst/reference_appendices/test_strategies.rst:222 -msgid "If desired, the above techniques may be extended to enable continuous deployment practices." -msgstr "任意で、上記の手法を拡張して、継続してデプロイメントができるようにします。" - -#: ../../rst/reference_appendices/test_strategies.rst:224 -msgid "The workflow may look like this::" -msgstr "ワークフローは、次のようになります。" - -#: ../../rst/reference_appendices/test_strategies.rst:231 -msgid "Some Ansible users use the above approach to deploy a half-dozen or dozen times an hour without taking all of their infrastructure offline. A culture of automated QA is vital if you wish to get to this level." -msgstr "Ansible ユーザーによっては、上記のアプローチを使用して、すべてのインフラストラクチャーをオフラインにすることなく、1 時間に 6 回、または 12 回デプロイしています。このレベルに到達するには、自動化 QA の文化が必要不可欠です。" - -#: ../../rst/reference_appendices/test_strategies.rst:234 -msgid "If you are still doing a large amount of manual QA, you should still make the decision on whether to deploy manually as well, but it can still help to work in the rolling update patterns of the previous section and incorporate some basic health checks using modules like 'script', 'stat', 'uri', and 'assert'." -msgstr "大量の QA を手動で続けている場合には、手動でデプロイするべきかどうか決定する必要がありますが、前項のようにローリングアップデートのパターンを使用して作業をし、「script」、「stat」、「uri」、「assert」などのモジュールで基本的なヘルスチェックを組み込むだけでも役立つ場合があります。" - -#: ../../rst/reference_appendices/test_strategies.rst:239 -msgid "Conclusion" -msgstr "まとめ" - -#: ../../rst/reference_appendices/test_strategies.rst:241 -msgid "Ansible believes you should not need another framework to validate basic things of your infrastructure is true. This is the case because Ansible is an order-based system that will fail immediately on unhandled errors for a host, and prevent further configuration of that host. This forces errors to the top and shows them in a summary at the end of the Ansible run." -msgstr "Ansible では、インフラストラクチャーの基本的な内容が正しいかを検証するフレームワークを別に用意する必要はないと考えます。これは、Ansible は順序ベースのシステムで、ホストに未処理のエラーがあると即座に失敗し、そのホストの設定がこれ以上進まないようにします。こうすることで、エラーが表面化し、Ansible の実行の最後にまとめとして、エラーが表示されます。" - -#: ../../rst/reference_appendices/test_strategies.rst:245 -msgid "However, as Ansible is designed as a multi-tier orchestration system, it makes it very easy to incorporate tests into the end of a playbook run, either using loose tasks or roles. When used with rolling updates, testing steps can decide whether to put a machine back into a load balanced pool or not." -msgstr "ただし、Ansible は、複数階層のオーケストレーションシステムとして設計されているため、非常に簡単にタスクまたはロールを使用して Playbook 実行の最後にテストを組み込むことができます。ローリングアップデートで使用する場合は、テストの手順で、ロードバランサーのプールにマシンを戻すかどうかを判断できます。" - -#: ../../rst/reference_appendices/test_strategies.rst:249 -msgid "Finally, because Ansible errors propagate all the way up to the return code of the Ansible program itself, and Ansible by default runs in an easy push-based mode, Ansible is a great step to put into a build environment if you wish to use it to roll out systems as part of a Continuous Integration/Continuous Delivery pipeline, as is covered in sections above." -msgstr "最後に、Ansible のエラーは、Ansible のプログラム自体のリターンコードにまで伝搬され、また Ansible はデフォルトで簡単なプッシュベースモードで実行されるため、上記のセクションで説明されているように、これを使用して継続的な統合/継続的なデリバリーパイプラインの一部としてシステムを展開する場合に Ansible をビルド環境に活用すると大きな一歩になります。" - -#: ../../rst/reference_appendices/test_strategies.rst:253 -msgid "The focus should not be on infrastructure testing, but on application testing, so we strongly encourage getting together with your QA team and ask what sort of tests would make sense to run every time you deploy development VMs, and which sort of tests they would like to run against the staging environment on every deploy. Obviously at the development stage, unit tests are great too. But don't unit test your playbook. Ansible describes states of resources declaratively, so you don't have to. If there are cases where you want to be sure of something though, that's great, and things like stat/assert are great go-to modules for that purpose." -msgstr "インフラストラクチャーテストではなく、アプリケーションのテストに焦点を当てるため、QA チームと連携して、どのようなテストを、開発仮想マシンのデプロイメント時に毎回実行すると便利か、またデプロイメント時に毎回、ステージ環境にどのようなテストを実行するかを確認してください。明らかに、開発段階では、単体テストも素晴らしいですが、Playbook を単体テストにはしないでください。Ansibl eはリソースの状態を宣言的に記述するため、その必要はありません。ただし、何かを確認したい場合は、stat/assert のようなモジュールを使用すると良いでしょう。" - -#: ../../rst/reference_appendices/test_strategies.rst:259 -msgid "In all, testing is a very organizational and site-specific thing. Everybody should be doing it, but what makes the most sense for your environment will vary with what you are deploying and who is using it -- but everyone benefits from a more robust and reliable deployment system." -msgstr "結局、テストは非常に組織的で、サイト固有の内容となっています。テストは必ず行うべきですが、貴社の環境に最も有用なテストは、デプロイメントの内容や、誰が使用するかにより異なります。しかし、誰もが、強力で信頼性の高いデプロイメントシステムから恩恵を受けることができます。" - -#: ../../rst/reference_appendices/test_strategies.rst:269 -msgid ":ref:`playbooks_delegation`" -msgstr ":ref:`playbooks_delegation`" - -#: ../../rst/reference_appendices/test_strategies.rst:270 -msgid "Delegation, useful for working with load balancers, clouds, and locally executed steps." -msgstr "委譲 (ロードバランサー、クラウド、およびローカルで実行した手順を使用する際に役に立ちます)" - -#: ../../rst/reference_appendices/tower.rst:4 -msgid "Red Hat Ansible Tower" -msgstr "Red Hat Ansible Tower" - -#: ../../rst/reference_appendices/tower.rst:6 -msgid "`Red Hat Ansible Tower `_ is a web console and REST API for operationalizing Ansible across your team, organization, and enterprise. It's designed to be the hub for all of your automation tasks." -msgstr "`Red Hat Ansible Tower `_ は、チーム、組織、企業全体で Ansible を操作する Web コンソールおよび REST API です。Red Hat Ansible Tower は、すべての自動化タスクのハブとなるように設計されています。" - -#: ../../rst/reference_appendices/tower.rst:8 -msgid "Ansible Tower gives you role-based access control, including control over the use of securely stored credentials for SSH and other services. You can sync your Ansible Tower inventory with a wide variety of cloud sources, and powerful multi-playbook workflows allow you to model complex processes." -msgstr "Ansible Tower には、セキュアに保存されている SSH や他のサービスの認証情報の使用時に制御するなど、ロールベースのアクセス制御が含まれています。Ansible Tower インベントリーは、幅広いクラウドソースと同期でき、強力な Playbook ワークフローを複数使用することで、複雑なプロセスをモデル化できます。" - -#: ../../rst/reference_appendices/tower.rst:11 -msgid "It logs all of your jobs, integrates well with LDAP, SAML, and other authentication sources, and has an amazing browsable REST API. Command line tools are available for easy integration with Jenkins as well." -msgstr "すべてのジョブをログ記録し、LDAP、SAML、他の認証ソースと統合の相性がよく、ブラウザーで使用可能な素晴らしい REST API が含まれます。また、Jenkins と簡単に統合できるように、コマンドラインも利用できます。" - -#: ../../rst/reference_appendices/tower.rst:13 -msgid "Ansible Tower is the downstream Red-Hat supported product version of Ansible AWX. Find out more about Ansible Tower features and how to download it on the `Ansible Tower webpage `_. Ansible Tower is part of the Red Hat Ansible Automation subscription, and comes bundled with amazing support from Red Hat, Inc." -msgstr "Ansible Tower は、Red Hat がサポートする Ansible AWX の製品のバージョン (ダウンストリーム) です。Ansible Tower の機能とそのダウンロード方法の詳細は、`Ansible Tower web ページ `_ を参照してください。Ansible Tower は、Red Hat Ansible Automation サブスクリプションに含まれ、Red Hat, Inc のサポートが利用できます。" - -#~ msgid "ANSIBLE_SSH_ARGS" -#~ msgstr "" - -#~ msgid "If set, this will override the Ansible default ssh arguments. In particular, users may wish to raise the ControlPersist time to encourage performance. A value of 30 minutes may be appropriate. Be aware that if `-o ControlPath` is set in ssh_args, the control path setting is not used." -#~ msgstr "" - -#~ msgid "-C -o ControlMaster=auto -o ControlPersist=60s" -#~ msgstr "" - -#~ msgid "[ssh_connection]" -#~ msgstr "" - -#~ msgid "ssh_args" -#~ msgstr "" - -#~ msgid ":envvar:`ANSIBLE_SSH_ARGS`" -#~ msgstr "" - -#~ msgid "ANSIBLE_SSH_CONTROL_PATH" -#~ msgstr "" - -#~ msgid "This is the location to save ssh's ControlPath sockets, it uses ssh's variable substitution. Since 2.3, if null, ansible will generate a unique hash. Use `%(directory)s` to indicate where to use the control dir path setting. Before 2.3 it defaulted to `control_path=%(directory)s/ansible-ssh-%%h-%%p-%%r`. Be aware that this setting is ignored if `-o ControlPath` is set in ssh args." -#~ msgstr "" - -#~ msgid "control_path" -#~ msgstr "" - -#~ msgid ":envvar:`ANSIBLE_SSH_CONTROL_PATH`" -#~ msgstr "" - -#~ msgid "ANSIBLE_SSH_CONTROL_PATH_DIR" -#~ msgstr "" - -#~ msgid "This sets the directory to use for ssh control path if the control path setting is null. Also, provides the `%(directory)s` variable for the control path setting." -#~ msgstr "" - -#~ msgid "~/.ansible/cp" -#~ msgstr "" - -#~ msgid ":envvar:`ANSIBLE_SSH_CONTROL_PATH_DIR`" -#~ msgstr "" - -#~ msgid "ANSIBLE_SSH_EXECUTABLE" -#~ msgstr "" - -#~ msgid "This defines the location of the ssh binary. It defaults to `ssh` which will use the first ssh binary available in $PATH. This option is usually not required, it might be useful when access to system ssh is restricted, or when using ssh wrappers to connect to remote hosts." -#~ msgstr "" - -#~ msgid "ssh" -#~ msgstr "" - -#~ msgid "ssh_executable" -#~ msgstr "" - -#~ msgid ":envvar:`ANSIBLE_SSH_EXECUTABLE`" -#~ msgstr "" - -#~ msgid "ANSIBLE_SSH_RETRIES" -#~ msgstr "" - -#~ msgid "Number of attempts to establish a connection before we give up and report the host as 'UNREACHABLE'" -#~ msgstr "" - -#~ msgid ":envvar:`ANSIBLE_SSH_RETRIES`" -#~ msgstr "" - -#~ msgid "DEFAULT_SCP_IF_SSH" -#~ msgstr "" - -#~ msgid "Preferred method to use when transferring files over ssh. When set to smart, Ansible will try them until one succeeds or they all fail. If set to True, it will force 'scp', if False it will use 'sftp'." -#~ msgstr "" - -#~ msgid "scp_if_ssh" -#~ msgstr "" - -#~ msgid ":envvar:`ANSIBLE_SCP_IF_SSH`" -#~ msgstr "" - -#~ msgid "DEFAULT_SFTP_BATCH_MODE" -#~ msgstr "" - -#~ msgid "sftp_batch_mode" -#~ msgstr "" - -#~ msgid ":envvar:`ANSIBLE_SFTP_BATCH_MODE`" -#~ msgstr "" - -#~ msgid "DEFAULT_SSH_TRANSFER_METHOD" -#~ msgstr "" - -#~ msgid "unused?" -#~ msgstr "" - -#~ msgid "transfer_method" -#~ msgstr "" - -#~ msgid ":envvar:`ANSIBLE_SSH_TRANSFER_METHOD`" -#~ msgstr "" - -#~ msgid "If set, this will override the Ansible default ssh arguments.In particular, users may wish to raise the ControlPersist time to encourage performance. A value of 30 minutes may be appropriate.Be aware that if `-o ControlPath` is set in ssh_args, the control path setting is not used." -#~ msgstr "" - -#~ msgid "See also :ref:`ANSIBLE_SSH_ARGS `" -#~ msgstr "" - -#~ msgid "This is the location to save ssh's ControlPath sockets, it uses ssh's variable substitution.Since 2.3, if null, ansible will generate a unique hash. Use `%(directory)s` to indicate where to use the control dir path setting.Before 2.3 it defaulted to `control_path=%(directory)s/ansible-ssh-%%h-%%p-%%r`.Be aware that this setting is ignored if `-o ControlPath` is set in ssh args." -#~ msgstr "" - -#~ msgid "See also :ref:`ANSIBLE_SSH_CONTROL_PATH `" -#~ msgstr "" - -#~ msgid "This sets the directory to use for ssh control path if the control path setting is null.Also, provides the `%(directory)s` variable for the control path setting." -#~ msgstr "" - -#~ msgid "See also :ref:`ANSIBLE_SSH_CONTROL_PATH_DIR `" -#~ msgstr "" - -#~ msgid "This defines the location of the ssh binary. It defaults to `ssh` which will use the first ssh binary available in $PATH.This option is usually not required, it might be useful when access to system ssh is restricted, or when using ssh wrappers to connect to remote hosts." -#~ msgstr "" - -#~ msgid "See also :ref:`ANSIBLE_SSH_EXECUTABLE `" -#~ msgstr "" - -#~ msgid "See also :ref:`ANSIBLE_SSH_RETRIES `" -#~ msgstr "" - -#~ msgid "Preferred method to use when transferring files over ssh.When set to smart, Ansible will try them until one succeeds or they all fail.If set to True, it will force 'scp', if False it will use 'sftp'." -#~ msgstr "" - -#~ msgid "See also :ref:`DEFAULT_SCP_IF_SSH `" -#~ msgstr "" - -#~ msgid "See also :ref:`DEFAULT_SFTP_BATCH_MODE `" -#~ msgstr "" - -#~ msgid "See also :ref:`DEFAULT_SSH_TRANSFER_METHOD `" -#~ msgstr "" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/roadmap.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/roadmap.po deleted file mode 100644 index f1a55fb5c4c..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/roadmap.po +++ /dev/null @@ -1,1351 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-03-08 20:25+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:3 -msgid "Ansible project 2.10" -msgstr "Ansible プロジェクト 2.10" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:5 -msgid "This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-base `_ package as well. All dates are subject to change. See :ref:`base_roadmap_2_10` for the most recent updates on ansible-base." -msgstr "本リリーススケジュールには、`ansible `_ パッケージの日付が含まれており、`ansible-base `_ パッケージの日付もいくつか含まれています。この日付はすべて変更する可能性があります。ansible-base の最新の更新については「:ref:`base_roadmap_2_10`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:11 -#: ../../rst/roadmap/ROADMAP_2_10.rst:11 ../../rst/roadmap/ROADMAP_2_11.rst:11 -#: ../../rst/roadmap/ROADMAP_2_6.rst:8 ../../rst/roadmap/ROADMAP_2_7.rst:8 -#: ../../rst/roadmap/ROADMAP_2_8.rst:9 ../../rst/roadmap/ROADMAP_2_9.rst:9 -msgid "Release Schedule" -msgstr "リリーススケジュール" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:13 -#: ../../rst/roadmap/ROADMAP_2_10.rst:19 ../../rst/roadmap/ROADMAP_2_11.rst:19 -msgid "Dates subject to change." -msgstr "日付は変更する可能性があります。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:14 -msgid "We plan to post weekly alpha releases to the `PyPI ansible project `_ for testing." -msgstr "テストのため、`PyPI ansible プロジェクト `_ に Alpha リリースを毎週公開することが予定されています。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:17 -msgid "We initially were going to have feature freeze on 2020-08-18. We tried this but decided to change course. Instead, we'll enter feature freeze when ansible-2.10.0 beta1 is released." -msgstr "当初は 2020 年 08 月 18 日に機能フリーズが行われる予定でした。フリーズを試みましたが、予定が変更になりました。代わりに、ansible-2.10.0 Beta1 がリリースされたときに機能フリーズになります。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:20 -msgid "2020-06-23: ansible-2.10 alpha freeze. No net new collections will be added to the ``ansible-2.10`` package after this date." -msgstr "2020 年 06 月 23 日: ansible-2.10 Alpha フリーズ。この日付を過ぎると、新しいコレクションが ``ansible-2.10`` パッケージに追加されなくなります。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:22 -msgid "2020-07-10: Ansible collections freeze date for content shuffling. Content should be in its final collection for the ansible-2.10 series of releases. No more content should move out of the ``community.general`` or ``community.network`` collections." -msgstr "2020 年 07 月 10 日: コンテンツ入れ替えの Ansible コレクション。コンテンツは、ansible-2.10 シリーズのリリースの最終コレクションにあるはずです。他のコンテンツは ``community.general`` コレクションまたは ``community.network`` コレクションに含まれるコンテンツは他にありません。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:24 -msgid "2020-08-13: ansible-base 2.10 Release date, see :ref:`base_roadmap_2_10`." -msgstr "2020 年 08 月 13 日: ansible-base 2.10 リリース日。「:ref:`base_roadmap_2_10`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:25 -msgid "2020-08-14: final ansible-2.10 alpha." -msgstr "2020 年 08 月 14 日: 最終的な ansible-2.10 Alpha。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:26 -msgid "2020-09-01: ansible-2.10.0 beta1 and feature freeze." -msgstr "2020 年 09 月 01 日: ansible-2.10.0 Beta1 および機能フリーズ。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:28 -msgid "No new modules or major features will be added after this date. In practice this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-1.1.0; ansible-2.10.0 could ship with community-crypto-1.1.1. It would not ship with community-crypto-1.2.0." -msgstr "この日付以降は、新しいモジュールや主な機能は追加されません。実際には、semver コレクションのバージョンは互換性のあるリリースバージョンにフリーズします。たとえば、この日付の community.crypto のバージョンが community-crypto-1.1.0 であれば、ansible-2.10.0 は community-crypto-1.1.1 に同梱される可能性がありました。community-crypto-1.2.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:30 -msgid "2020-09-08: ansible-2.10.0 beta2." -msgstr "2020 年 09 月 08 日: Ansible-2.10.0 beta2。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:31 -msgid "2020-09-15: ansible-2.10.0 rc1 and final freeze." -msgstr "2020 年 09 月 15 日: Ansible-2.10.0 rc1 および最終フリーズ。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:33 -msgid "After this date only changes blocking a release are accepted." -msgstr "この日付以降は、リリースをブロックする変更のみが許可されます。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:34 -msgid "Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at the community IRC meeting (on 9-17) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda `_." -msgstr "コレクションは、ブロッカーが承認された場合にのみ新規バージョンに更新されます。コレクションの所有者は、修正のためにコレクションのバージョンを上げるかどうかを決めるために、コミュニティー IRC ミーティングのブロッカーについて (9 ~ 17 上) 議論する必要があります。`Community IRC meeting agenda `_ を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:36 -msgid "** Additional release candidates to be published as needed as blockers are fixed **" -msgstr "**ブロッカーが修正されると、必要に応じて公開される追加のリリース候補**" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:38 -msgid "2020-09-22: ansible-2.10 GA release date." -msgstr "2020 年 09 月 22 日: Ansible-2.10 GA リリース日。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:40 -msgid "Ansible-2.10.x patch releases will occur roughly every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x. Ansible-2.10.x patch releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed (example: Ansible-2.10 ships with community-crypto-1.1.0; ansible-2.10.1 may ship with community-crypto-1.2.0 but would not ship with community-crypto-2.0.0)." -msgstr "コレクションに変更が加えられた場合、または後で ansible-base-2.10.x へのアップグレードを強制する必要があると見なされた場合、Ansible-2.10.x パッチのリリースは約 3 週間ごとに行われます。Ansible-2.10.x パッチリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときは変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-2.10 が community-crypto-1.1.0 に同梱されると、ansible-2.10.1 は community-crypto-1.2.0 に同梱される場合がありますが、community-crypto-2.0.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:42 -msgid "Breaking changes may be introduced in ansible-2.11.0 although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before being changed incompatibly." -msgstr "ansible-2.11.0 で重大な変更が導入される可能性がありますが、コレクションの所有者は、非互換性になる前に少なくとも 1 つの Ansible リリースに含まれる非推奨期間を使用することが推奨されます。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:44 -msgid "The rough schedule for Ansible-2.11 and beyond (such as how many months we'll aim for between versions) is still to be discussed and likely will be made after 2.10.0 has been released." -msgstr "Ansible-2.11 以降の大まかなスケジュール (バージョン間の目標数など) は依然として検討されており、2.10.0 のリリース後に行われる可能性があります。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:46 -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:45 -#: ../../rst/roadmap/COLLECTIONS_4.rst:48 -msgid "For more information, reach out on a mailing list or an IRC channel - see :ref:`communication` for more details." -msgstr "詳細は、メーリングリストまたは IRC チャンネルをご利用ください。「:ref:`communication`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:3 -msgid "Ansible project 3.0" -msgstr "Ansible プロジェクト 3.0" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:5 -msgid "This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-base `_ package as well. All dates are subject to change. Ansible 3.x.x includes ``ansible-base`` 2.10. See :ref:`base_roadmap_2_10` for the most recent updates on ``ansible-base``." -msgstr "本リリーススケジュールには、`ansible `_ パッケージの日付が含まれており、`ansible-base `_ パッケージの日付もいくつか含まれています。この日付はすべて変更する可能性があります。Ansible 3.x.x には ``ansible-base`` 2.10 が含まれます。``ansible-base`` の最新の更新については、「:ref:`base_roadmap_2_10`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:11 -#: ../../rst/roadmap/COLLECTIONS_4.rst:12 -msgid "Release schedule" -msgstr "リリーススケジュール" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:15 -msgid "Ansible is switching from its traditional versioning scheme to `semantic versioning `_ starting with this release. So this version is 3.0.0 instead of 2.11.0." -msgstr "Ansible は、本リリース以降の従来のバージョン管理スキームから `semantic versioning `_ に切り替えるため、このバージョンは 2.11.0 ではなく 3.0.0 になります。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst -msgid "2020-12-16" -msgstr "2020 年 12 月 16 日" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:19 -msgid "Finalize rules for net-new collections submitted for the ansible release." -msgstr "Ansible リリースに送信された net-new コレクションのルールのファイナライズ。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst -msgid "2021-01-27" -msgstr "2021 年 01 月 27 日" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:20 -msgid "Final day for new collections to be **reviewed and approved**. They MUST be submitted prior to this to give reviewers a chance to look them over and for collection owners to fix any problems." -msgstr "新しいコレクションの **レビューおよび承認** の最終日。レビュー担当者が新しいコレクションを確認し、コレクションの所有者が問題を修正する機会を得るために、この日付までに提出する必要があります。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst -msgid "2021-02-02" -msgstr "2021 年 02 月 02 日" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:23 -msgid "Ansible-3.0.0-beta1 -- feature freeze [1]_" -msgstr "ansible-3.0.0-beta1 -- 機能フリーズ [1]_" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst -msgid "2021-02-09" -msgstr "2021 年 02 月 09 日" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:24 -msgid "Ansible-3.0.0-rc1 -- final freeze [2]_ [3]_" -msgstr "Ansible-3.0.0-rc1 -- 最終フリーズ [2]_ [3]_" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst -msgid "2021-02-16" -msgstr "2021 年 02 月 16 日" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:25 -msgid "Release of Ansible-3.0.0" -msgstr "Ansible-3.0.0 のリリース" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst -msgid "2021-03-09" -msgstr "2021 年 03 月 09 日" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:26 -msgid "Release of Ansible-3.1.0 (bugfix + compatible features: every three weeks)" -msgstr "Ansible-3.1.0 のリリース (バグ修正 + 互換性のある機能: 3 週間ごと)" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:28 -#: ../../rst/roadmap/COLLECTIONS_4.rst:31 -msgid "No new modules or major features accepted after this date. In practice this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-2.1.0; ansible-3.0.0 could ship with community-crypto-2.1.1. It would not ship with community-crypto-2.2.0." -msgstr "この日付以降は、新しいモジュールやメジャー機能は追加されません。実際には、semver コレクションのバージョンは互換性のあるリリースバージョンにフリーズします。たとえば、この日付の community.crypto のバージョンが community-crypto-2.1.0 であれば、ansible-3.0.0 は community-crypto-2.1.1 に同梱される可能性がありました。community-crypto-2.2.0 は同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:30 -#: ../../rst/roadmap/COLLECTIONS_4.rst:33 -msgid "After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date." -msgstr "この日付以降は、リリースをブロックする変更のみが許可されます。受け入れ可能な変更には、新しい rc を作成する必要があり、最終リリース日は処理されない可能性があります。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:31 -#: ../../rst/roadmap/COLLECTIONS_4.rst:34 -msgid "Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda `_." -msgstr "コレクションは、ブロッカーが承認された場合にのみ新しいバージョンに更新されます。コレクションの所有者は、(フリーズの前に) 修正のためにコレクションのバージョンを上げるかどうかを決定するために、コミュニティー IRC ミーティングのブロッカーについて検討する必要があります。`コミュニティー IRC ミーティングの議題 `_ を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:36 -msgid "Breaking changes may be introduced in Ansible 3.0.0, although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before the breaking change happens." -msgstr "Ansible3.0.0 で重大な変更が導入される可能性がありますが、コレクションの所有者は、重大な変更が発生する前に少なくとも 1 つの Ansible リリースに含まれる非推奨期間を使用することが推奨されます。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:40 -#: ../../rst/roadmap/COLLECTIONS_4.rst:43 -msgid "Ansible minor releases" -msgstr "Ansible マイナーリリース" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:42 -msgid "Ansible 3.x.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x. Ansible 3.x.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-3.0.0 ships with community-crypto-2.1.0; Ansible-3.1.0 may ship with community-crypto-2.2.0 but would not ship with community-crypto-3.0.0)." -msgstr "コレクションに変更が加えられた場合、または後で ansible-base-2.10.x へのアップグレードを強制する必要があると見なされた場合、Ansible 3.x.x マイナーリリースは約 3 週間ごとに行われます。Ansible 3.x.x マイナーリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときに変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-3.0.0 が community-crypto-2.1.0 に同梱されると、Ansible-3.1.0 は community-crypto-2.2.0 に同梱される場合がありますが、community-crypto-3.0.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:48 -msgid "ansible-base release" -msgstr "ansible-base リリース" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:50 -msgid "Ansible 3.x.x works with ``ansible-base`` 2.10. See :ref:`base_roadmap_2_10` for details." -msgstr "Ansible 3.x.x は ``ansible-base`` 2.10 で動作します。詳細は、「:ref:`base_roadmap_2_10`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:3 -msgid "Ansible project 4.0" -msgstr "Ansible プロジェクト 4.0" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:5 -msgid "This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See :ref:`base_roadmap_2_11` for the most recent updates on ``ansible-core``." -msgstr "本リリーススケジュールには、`ansible `_ パッケージの日付が含まれており、`ansible-core `_ パッケージの日付もいくつか含まれています。この日付はすべて変更される可能性があります。``ansible-core`` の最新の更新については「:ref:`base_roadmap_2_11`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-01-26" -msgstr "2021 年 01 月 26日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:15 -msgid "New Collections will be reviewed for inclusion in Ansible 4." -msgstr "新しいコレクションは、Ansible 4 に含まれるようにレビューされています。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-03-03" -msgstr "2021 年 03 月 03 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:16 -msgid "Ansible-4.0.0 alpha1 (biweekly ``ansible`` alphas. These are timed to coincide with the start of the ``ansible-core-2.11`` pre-releases)." -msgstr "Ansible-4.0.0 alpha1 (``ansible`` Alpha は隔週)。これらは ``ansible-core-2.11`` プレリリースの開始と合致するようにタイミングが調整されます。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-03-16" -msgstr "2021 年 03 月 16 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:17 -msgid "Ansible-4.0.0 alpha2" -msgstr "Ansible-4.0.0 alpha2" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-03-30" -msgstr "2021 年 03 月 30 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:18 -msgid "Ansible-4.0.0 alpha3" -msgstr "Ansible-4.0.0 alpha3" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-04-13" -msgstr "2021 年 04 月 13 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:19 -msgid "Last day for new collections to be submitted for inclusion in Ansible 4. Note that collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion." -msgstr "Ansible 4 に含めるために新しいコレクションを送信する最終日。コレクションを含める前に、コレクションをレビューして承認する必要があることに注意してください。すべてのコレクションをレビューする保証はありません。コレクションが早く提出されるほど、コレクションがレビューされ、必要なフィードバックが含まれるのに間に合うように対処される可能性が高くなります。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:20 -msgid "Ansible-4.0.0 alpha4" -msgstr "Ansible-4.0.0 alpha4" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-04-14" -msgstr "2021 年 04 月 14 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:21 -msgid "Community IRC Meeting topic: list any new collection reviews which block release. List any backwards incompatible collection releases that beta1 should try to accommodate." -msgstr "コミュニティー IRC ミーティングのトピック: リリースをブロックする新しいコレクションレビューを一覧表示します。beta1 が対応しようとする後方互換性のないコレクションリリースの一覧を表示します。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-04-21" -msgstr "2021 年 04 月 21 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:22 -msgid "Community IRC Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline." -msgstr "コミュニティー IRC ミーティングのトピック: 期限に間に合わないブロッカーに対してアクティブにする不測の事態を決定します。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-04-26" -msgstr "2021 年 04 月 26 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:23 -msgid "Last day for new collections to be **reviewed and approved** for inclusion in Ansible 4." -msgstr "新しいコレクションを Ansible 4 に含めるために **レビューおよび承認** される最終日。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:24 -msgid "Last day for collections to make backwards incompatible releases that will be accepted into Ansible 4." -msgstr "コレクションが Ansible 4 に受け入れられる後方互換性のないリリースを作成する最終日。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-04-27" -msgstr "2021 年 04 月 27 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:25 -msgid "Ansible-4.0.0 beta1 -- feature freeze [1]_ (weekly beta releases. Collection owners and interested users should test for bugs)." -msgstr "Ansible-4.0.0 beta1 -- 機能フリーズ [1]_ (週次 Beta リリース)。コレクションの所有者と対象のユーザーはバグについてテストする必要があります。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-05-04" -msgstr "2021 年 05 月 04 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:26 -msgid "Ansible-4.0.0 beta2" -msgstr "Ansible-4.0.0 beta2" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-05-11" -msgstr "2021 年 05 月 11 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:27 -msgid "Ansible-4.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed. Test and alert us to any blocker bugs)." -msgstr "Ansible-4.0.0 rc1 [2]_ [3]_ (必要に応じて週次リリース候補。すべてのブロッカーバグに対してテストし、警告します)" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-05-18" -msgstr "2021 年 05 月 18 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:28 -msgid "Ansible-4.0.0 release" -msgstr "Ansible-4.0.0 リリース" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-06-08" -msgstr "2021 年 06 月 08 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:29 -msgid "Release of Ansible-4.1.0 (bugfix + compatible features: every three weeks)" -msgstr "Ansible-4.1.0 のリリース (バグ修正 + 互換性のある機能: 3 週間ごと)" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:39 -msgid "Breaking changes will be introduced in Ansible 4.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed." -msgstr "Ansible 4.0.0 で 重大な変更が導入されますが、重大な変更が発生する前に少なくとも 1 つの Ansible リリースに表示される非推奨期間の使用が推奨されますが、これは保証されません。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:45 -msgid "Ansible 4.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.11.x. Ansible 4.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-4.0.0 ships with community-crypto-2.1.0; Ansible-4.1.0 may ship with community-crypto-2.2.0 but would not ship with community-crypto-3.0.0)." -msgstr "コレクションに変更が加えられた場合、または後で ansible-core-2.11.x へのアップグレードを強制する必要があると見なされた場合、Ansible 4.x マイナーリリースは約 3 週間ごとに行われます。Ansible 4.x マイナーリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときに変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-4.0.0 が community-crypto-2.1.0 に同梱されると、Ansible-4.1.0 は community-crypto-2.2.0 に同梱される場合がありますが、community-crypto-3.0.0 には同梱されません。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:5 -msgid "Ansible-base 2.10" -msgstr "Ansible-base 2.10" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:14 ../../rst/roadmap/ROADMAP_2_11.rst:14 -#: ../../rst/roadmap/ROADMAP_2_7.rst:11 ../../rst/roadmap/ROADMAP_2_8.rst:12 -#: ../../rst/roadmap/ROADMAP_2_9.rst:12 -msgid "Expected" -msgstr "予定" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:16 -msgid "PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-base release." -msgstr "プル要求は、この ansible-base リリースに含まれる可能性を高めるために、以下の期日に間に合うように、十分な余裕をもって提案してください。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:18 -msgid "There is no Alpha phase in 2.10." -msgstr "2.10 には、Alpha フェーズはありません。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:21 -msgid "2020-06-16 Beta 1 **Feature freeze** No new functionality (including modules/plugins) to any code" -msgstr "2020 年 06 月 16 日 Beta 1 **機能フリーズ** どのコードにも新しい機能 (モジュール、プラグインなど) はありません。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:24 -msgid "2020-07-21 Release Candidate 1 (bumped from 2020-07-14)" -msgstr "2020 年 07 月 21 日 リリース候補 1 (2020-07-14 からバージョンを上げました)" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:25 -msgid "2020-07-24 Release Candidate 2" -msgstr "2020 年 07 月 24 日 リリース候補 2" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:26 -msgid "2020-07-25 Release Candidate 3" -msgstr "2020 年 07 月 25 日 リリース候補 3" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:27 -msgid "2020-07-30 Release Candidate 4" -msgstr "2020 年 07 月 30 日 リリース候補 4" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:28 -msgid "2020-08-13 Release" -msgstr "2020 年 08 月 13 日 リリース" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:31 ../../rst/roadmap/ROADMAP_2_11.rst:33 -#: ../../rst/roadmap/ROADMAP_2_5.rst:19 ../../rst/roadmap/ROADMAP_2_6.rst:27 -#: ../../rst/roadmap/ROADMAP_2_7.rst:24 ../../rst/roadmap/ROADMAP_2_8.rst:31 -#: ../../rst/roadmap/ROADMAP_2_9.rst:31 -msgid "Release Manager" -msgstr "リリースマネージャー" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:33 -msgid "@sivel" -msgstr "@sivel" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:36 ../../rst/roadmap/ROADMAP_2_11.rst:38 -#: ../../rst/roadmap/ROADMAP_2_8.rst:36 ../../rst/roadmap/ROADMAP_2_9.rst:37 -msgid "Planned work" -msgstr "予定される作業" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:38 -msgid "Migrate non-base plugins and modules from the ``ansible/ansible`` repository to smaller collection repositories" -msgstr "ベースでないプラグインとモジュールを ``ansible/ansible`` リポジトリーから小規模なコレクションリポジトリーに移行する" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:39 -msgid "Add functionality to ease transition to collections, such as automatic redirects from the 2.9 names to the new FQCN of the plugin" -msgstr "2.9 の名前からプラグインの新しい FQCN への自動リダイレクトなど、コレクションへの移行を容易にする機能を追加します。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:40 -msgid "Create new ``ansible-base`` package representing the ``ansible/ansible`` repository" -msgstr "``ansible-base`` リポジトリーを表す新しい ``ansible/ansible`` パッケージを作成します。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:43 -msgid "Additional Resources" -msgstr "追加情報" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:45 -msgid "The 2.10 release of Ansible will fundamentally change the scope of plugins included in the ``ansible/ansible`` repository, by moving much of the plugins into smaller collection repositories that will be shipped through https://galaxy.ansible.com/" -msgstr "Ansible の 2.10 リリースでは、プラグインの大半を、https://galaxy.ansible.com/ から同梱する小規模なコレクションリポジトリーに移動することで、``ansible/ansible`` リポジトリーに含まれるプラグインの範囲を基本的に変更します。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:48 -msgid "The following links have more information about this process:" -msgstr "以下のリンクには、このプロセスに関する詳細情報が含まれます。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:50 -msgid "https://groups.google.com/d/msg/ansible-devel/oKqgCeYTs-M/cHrOgMw8CAAJ" -msgstr "https://groups.google.com/d/msg/ansible-devel/oKqgCeYTs-M/cHrOgMw8CAAJ" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:51 -msgid "https://github.com/ansible-collections/overview/blob/main/README.rst" -msgstr "https://github.com/ansible-collections/overview/blob/main/README.rst" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:5 -msgid "Ansible-core 2.11" -msgstr "Ansible-core 2.11" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:16 -msgid "PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release." -msgstr "プル要求は、この ansible-core リリースに含まれる可能性を高めるために、以下の期日に間に合うように、十分な余裕をもって提案してください。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:18 -msgid "There is no Alpha phase in 2.11." -msgstr "2.11 には、Alpha フェーズはありません。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:21 -msgid "2021-02-12 Feature Freeze No new functionality (including modules/plugins) to any code" -msgstr "2021 年 02 月 12 日 機能フリーズ。コードへの新しい機能 (モジュール/プラグインを含む) はありません。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:24 -msgid "2021-03-02 Beta 1" -msgstr "2021 年 03 月 02 日 Beta 1" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:25 -msgid "2021-03-15 Beta 2 (if necessary)" -msgstr "2021 年 03 月 15 日 Beta 2 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:27 -msgid "2021-03-29 Release Candidate 1 (and ``stable-2.11`` branching from ``devel``)" -msgstr "2021 年 03 月 29 日 リリース候補 1 (および ``devel`` の ``stable-2.11`` ブランチ)" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:28 -msgid "2021-04-12 Release Candidate 2 (if necessary)" -msgstr "2021 年 04 月 12 日 リリース候補 2 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:30 -msgid "2021-04-26 Release" -msgstr "2021 年 04 月 26 日 リリース" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:35 -msgid "Ansible Core Team" -msgstr "Ansible Core Team" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:40 -msgid "Rename ``ansible-base`` to ``ansible-core``." -msgstr "``ansible-base`` の名前を ``ansible-core`` に変更します。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:41 -msgid "Improve UX of ``ansible-galaxy collection`` CLI, specifically as it relates to install and upgrade." -msgstr "特にインストールおよびアップグレードに関連する ``ansible-galaxy collection`` CLI の UX が改善されます。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:42 -msgid "Add new Role Argument Spec feature that will allow a role to define an argument spec to be used in validating variables used by the role." -msgstr "ロールが使用する変数の検証に使用する引数の仕様を定義できるように、新規の Role 引数仕様機能を追加します。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:44 -msgid "Bump the minimum Python version requirement for the controller to Python 3.8. There will be no breaking changes to this release, however ``ansible-core`` will only be packaged for Python 3.8+. ``ansible-core==2.12`` will include breaking changes requiring at least Python 3.8." -msgstr "コントローラーの最小 Python バージョン要件を Python 3.8 に上げます。今回のリリースには、重大な変更はありませんが、``ansible-core`` は Python 3.8 以降に対してのみパッケージ化されます。``ansible-core==2.12`` には、Python 3.8 以上を必要とする重大な変更が含まれます。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:47 -msgid "Introduce split-controller testing in ``ansible-test`` to separate dependencies for the controller from dependencies on the target." -msgstr "``ansible-test`` に split-controller テストが導入され、コントローラーの依存関係をターゲットの依存関係から分離します。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:3 -msgid "Ansible 2.5" -msgstr "Ansible 2.5" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:4 -msgid "**Core Engine Freeze and Module Freeze: 22 January 2018**" -msgstr "**コアエンジンのフリーズおよびモジュールのフリーズ: 2018 年 1 月 22 日**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:6 -msgid "**Core and Curated Module Freeze: 22 January 2018**" -msgstr "**コアおよびキューレーションモジュールのフリーズ: 2018 年 1 月 22 日**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:8 -msgid "**Community Module Freeze: 7 February 2018**" -msgstr "**コミュニティーモジュールのフリーズ: 2018 年 2 月 7 日**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:10 -msgid "**Release Candidate 1 will be 21 February, 2018**" -msgstr "**リリース候補 1 は 2018 年 2 月 21 日です。**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:12 -msgid "**Target: March 2018**" -msgstr "**ターゲット: 2018 年 3 月**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:14 -msgid "**Service Release schedule: every 2-3 weeks**" -msgstr "**サービスリリーススケジュール: 2 ~ 3 週間ごと**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:16 ../../rst/roadmap/ROADMAP_2_6.rst:5 -#: ../../rst/roadmap/ROADMAP_2_7.rst:5 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:20 -msgid "Matt Davis (IRC/GitHub: @nitzmahone)" -msgstr "Matt Davis (IRC/GitHub: @nitzmahone)" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:24 ../../rst/roadmap/ROADMAP_2_6.rst:33 -msgid "Engine improvements" -msgstr "エンジンの改善" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:25 -msgid "Assemble module improvements - assemble just skips when in check mode, it should be able to test if there is a difference and changed=true/false. - The same with diff, it should work as template modules does" -msgstr "assemble モジュールの改善 - チェックモードでは assemble はスキップするだけで、違いがあり、変更があるかどうかをテストできます (true/false)。diff と同じように、テンプレートモジュールと同じように機能するはずです。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:28 -msgid "Handle Password reset prompts cleaner" -msgstr "パスワードリセットプロンプトクリーナーの処理" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:29 -msgid "Tasks stats for rescues and ignores" -msgstr "rescue および ignore のタスク統計" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:30 -msgid "Normalize temp dir usage across all subsystems" -msgstr "すべてのサブシステムで一時ディレクトリーの使用を正規化" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:31 -msgid "Add option to set playbook dir for adhoc, inventory and console to allow for 'relative path loading'" -msgstr "アドホック、インベントリー、およびコンソールに Playbook ディレクトリーを設定して、「相対パスの読み込み」を可能にするオプションを追加します" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:35 -msgid "Ansible-Config" -msgstr "Ansible-Config" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:36 -msgid "Extend config to more plugin types and update plugins to support the new config" -msgstr "設定を他のプラグインタイプに拡張し、新しい設定をサポートするようにプラグインを更新します。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:39 -msgid "Inventory" -msgstr "インベントリー" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:40 -msgid "ansible-inventory option to output group variable assignment and data (--export)" -msgstr "グループ変数の割り当ておよびデータを出力する ansible-inventory オプション (--export)" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:41 -msgid "Create inventory plugins for: - aws" -msgstr "- aws にインベントリープラグインを作成します。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:45 -msgid "Facts" -msgstr "ファクト" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:46 -msgid "Namespacing fact variables (via a config option) implemented in ansible/ansible PR `#18445 `_. Proposal found in ansible/proposals issue `#17 `_." -msgstr "ansible/ansible のプル要求に実装されたファクト変数 (設定オプション経由) の名前空間 (`#18445 `_)。ansible/proposals 問題に表示される提案 (`#17 `_)。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:48 -msgid "Make fact collectors and gather_subset specs finer grained" -msgstr "ファクトコレクターと gather_subset の仕様をより詳細にする" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:49 -msgid "Eliminate unneeded deps between fact collectors" -msgstr "ファクトコレクター間の不要なデッドを排除する" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:50 -msgid "Allow fact collectors to indicate if they need information from another fact collector to be gathered first." -msgstr "ファクトコレクターは、別のファクトコレクターからの情報を最初に収集する必要があるかどうかを示すことができるようにします。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:53 -msgid "Static Loop Keyword" -msgstr "静的ループキーのパスワード" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:55 -msgid "A simpler alternative to ``with_``, ``loop:`` only takes a list" -msgstr "``with_`` のより簡単な代替方法としては、``loop:`` はリストのみを使用します。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:56 -msgid "Remove complexity from loops, lookups are still available to users" -msgstr "ループから複雑性を削除し、ユーザーは、引き続き検索を利用できます。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:57 -msgid "Less confusing having a static directive vs a one that is dynamic depending on plugins loaded." -msgstr "読み込まれたプラグインに応じて動的なディレクティブと比較して、静的なディレクティブを持つことで混乱が少なくなります。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:60 -msgid "Vault" -msgstr "Vault" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:61 -msgid "Vault secrets client inc new 'keyring' client" -msgstr "新しい「キーリング」クライアントを含む Vault シークレットクライアント" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:64 -msgid "Runtime Check on Modules for Disabling" -msgstr "無効にするモジュールのランタイムチェック" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:65 -msgid "Filter on things like \"supported_by\" in module metadata" -msgstr "モジュールメタデータに「supported_by」などの内容にフィルタリングする" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:66 -msgid "Provide users with an option of \"warning, error or allow/ignore\"" -msgstr "「warning, error or allow/ignore」のオプションをユーザーに指定する" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:67 -msgid "Configurable via ansible.cfg and environment variable" -msgstr "ansible.cfg および環境変数を使用して設定可能に" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:70 ../../rst/roadmap/ROADMAP_2_6.rst:78 -#: ../../rst/roadmap/ROADMAP_2_7.rst:94 -msgid "Windows" -msgstr "Windows" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:71 -msgid "Implement gather_subset on Windows facts" -msgstr "Windows ファクトへの gather_subset の実装" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:72 -msgid "Fix Windows async + become to allow them to work together" -msgstr "Windows の非同期を修正し、それらが連携できるようにする" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:73 -msgid "Implement Windows become flags for controlling various modes **(done)** - logontype - elevation behavior" -msgstr "さまざまなモードを制御するための Windows の become フラグを実装する **(完了)** - logontype - elevation behavior" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:76 -msgid "Convert win_updates to action plugin for auto reboot and extra features **(done)**" -msgstr "自動再起動および追加機能の Win_updates からアクションプラグインに変換する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:77 -msgid "Spike out changing the connection over to PSRP instead of WSMV **(done- it's possible)**" -msgstr "接続を WSMV ではなく PSRP に変更することを明確にする **(完了 - 可能)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:78 -msgid "Module updates" -msgstr "モジュールの更新" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:80 -msgid "win_updates **(done)**" -msgstr "win_updates **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:82 -msgid "Fix win_updates to detect (or request) become" -msgstr "become を検出 (または要求) するように win_updates を修正する" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:83 -msgid "Add enable/disable features to win_updates" -msgstr "win_updates に有効化/無効化機能を追加する" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:84 -msgid "win_dsc further improvements **(done)**" -msgstr "win_dsc をさらに改善する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:87 -msgid "General Cloud" -msgstr "一般クラウド" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:88 -msgid "Make multi-cloud provisioning easier" -msgstr "マルチクラウドのプロビジョニングを容易にする" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:89 -msgid "Diff mode will output provisioning task results of ansible-playbook runs" -msgstr "diff モードは、ansible-playbook の実行のプロビジョニングタスク結果を出力する" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:90 -msgid "Terraform module" -msgstr "Terraform モジュール" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:93 ../../rst/roadmap/ROADMAP_2_7.rst:62 -msgid "AWS" -msgstr "AWS" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:94 -msgid "Focus on pull requests for various modules" -msgstr "さまざまなモジュールのプル要求に焦点" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:95 -msgid "Triage existing merges for modules" -msgstr "モジュールの既存マージの優先順位付け" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:96 -msgid "Module work" -msgstr "モジュール作業" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:98 -msgid "ec2_instance" -msgstr "ec2_instance" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:99 -msgid "ec2_vpc: Allow the addition of secondary IPv4 CIDRS to existing VPCs." -msgstr "ec2_vpc: 既存の VPC へのセカンダリー IPv4 CIDRS の追加を許可します。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:100 -msgid "AWS Network Load Balancer support (NLB module, ASG support, and so on)" -msgstr "AWS Network Load Balancer サポート (NLB モジュール、ASG サポートなど)" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:101 -msgid "rds_instance" -msgstr "rds_instance" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:104 ../../rst/roadmap/ROADMAP_2_7.rst:71 -msgid "Azure" -msgstr "Azure" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:105 -msgid "Azure CLI auth **(done)**" -msgstr "Azure CLI 認証 **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:106 -msgid "Fix Azure module results to have \"high-level\" output instead of raw REST API dictionary **(partial, more to come in 2.6)**" -msgstr "生の REST API ディレクトリーではなく「高レベル」の出力を表示するように Azure モジュールの結果を修正する **(部分的。2.6 でさらに追加予定)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:107 -msgid "Deprecate Azure automatic storage accounts in azure_rm_virtualmachine **(breaks on Azure Stack, punted until AS supports managed disks)**" -msgstr "azure_rm_virtualmachine の Azure 自動ストレージアカウントを非推奨に **(Azure Stack で中断。AS が管理対象ディスクをサポートするまで保留)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:110 -msgid "Network Roadmap" -msgstr "ネットワークのロードマップ" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:111 -msgid "Refactor common network shared code into package **(done)**" -msgstr "共通ネットワーク共有コードをパッケージにリファクタリングする **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:112 -msgid "Convert various nxos modules to leverage declarative intent **(done)**" -msgstr "さまざまな nxos モジュールを変換し、宣言的推論 **(完了)** を活用" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:113 -msgid "Refactor various modules to leverage the cliconf plugin **(done)**" -msgstr "cliconf プラグインを活用するために各種モジュールをリファクタリングする **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:114 -msgid "Add various missing declarative modules for supported platforms and functions **(done)**" -msgstr "サポートされるプラットフォームおよび機能用に、不足しているさまざまな宣言型モジュールを追加する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:115 -msgid "Implement a feature that handles platform differences and feature unavailability **(done)**" -msgstr "プラットフォームの違いと機能の利用不可に対応する機能を実装する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:116 -msgid "netconf-config.py should provide control for deployment strategy" -msgstr "netconf-config.py がデプロイメントストラテジーの制御を提供する必要がある" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:117 -msgid "Create netconf connection plugin **(done)**" -msgstr "netconf 接続プラグインを作成する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:118 -msgid "Create netconf fact module" -msgstr "netconf ファクトモジュールを作成する" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:119 -msgid "Turn network_cli into a usable connection type **(done)**" -msgstr "network_cli を使用可能な接続タイプに変換する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:120 -msgid "Implements jsonrpc message passing for ansible-connection **(done)**" -msgstr "ansible-connection に渡す jsonrpc メッセージを実装する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:121 -msgid "Improve logging for ansible-connection **(done)**" -msgstr "ansible-connection のロギングを改善する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:122 -msgid "Improve stdout output for failures whilst using persistent connection **(done)**" -msgstr "永続的な接続の使用中に傷害が発生した場合の stdout 出力を改善する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:123 -msgid "Create IOS-XR NetConf Plugin and refactor iosxr modules to leverage netconf plugin **(done)**" -msgstr "IOS-XR NetConf プラグインを作成し、iosxr モジュールをリファクタリングして netconf プラグインを活用する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:124 -msgid "Refactor junos modules to use netconf plugin **(done)**" -msgstr "netconf プラグインを使用するように junos モジュールをリファクタリングする **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:125 -msgid "Filters: Add a filter to convert XML response from a network device to JSON object **(done)**" -msgstr "フィルター: XML 応答をネットワークデバイスから JSON オブジェクトに変換するフィルターを追加する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:128 -msgid "Documentation" -msgstr "ドキュメント" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:129 -msgid "Extend documentation to more plugins" -msgstr "ドキュメントを他のプラグインへ拡張" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:130 -msgid "Document vault-password-client scripts." -msgstr "vault-password-client スクリプトを文書化します。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:131 -msgid "Network Documentation" -msgstr "ネットワークドキュメント" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:133 -msgid "New landing page (to replace intro_networking) **(done)**" -msgstr "新しいランディングページ (intro_networking を置き換えるため) **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:134 -msgid "Platform specific guides **(done)**" -msgstr "プラットフォーム固有のガイド **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:135 -msgid "Walk through: Getting Started **(done)**" -msgstr "ウォークスルー: はじめに **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:136 -msgid "Networking and ``become`` **(done)**" -msgstr "ネットワークおよび ``become`` **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:137 -msgid "Best practice **(done)**" -msgstr "ベストプラクティス **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:140 -msgid "Contributor Quality of Life" -msgstr "貢献者の生活の質" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:141 -msgid "Finish PSScriptAnalyer integration with ansible-test (for enforcing Powershell style) **(done)**" -msgstr "PSScriptAnalyer と ansible-test の統合を完了する (Powershell スタイルを適用するため) **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:142 -msgid "Resolve issues requiring skipping of some integration tests on Python 3." -msgstr "Python 3 で一部の統合テストをスキップする必要がある問題を解決する。" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:3 -msgid "Ansible 2.6" -msgstr "Ansible 2.6" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:11 -msgid "Actual" -msgstr "実績" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:13 -msgid "2018-05-17 Core Freeze (Engine and Core Modules/Plugins)" -msgstr "2018 年 05 月 17 日 コアフリーズ (Engine および Core モジュール/プラグイン)" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:14 -msgid "2018-05-21 Alpha Release 1" -msgstr "2018 年 05 月 21 日 Alpha リリース 1" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:15 -msgid "2018-05-25 Community Freeze (Non-Core Modules/Plugins)" -msgstr "2018 年 05 月 25 日 コミュニティーフリーズ (非 Core モジュール/プラグイン)" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:16 -msgid "2018-05-25 Branch stable-2.6" -msgstr "2018 年 05 月 25 日 ブランチの stable-2.6" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:17 -msgid "2018-05-30 Alpha Release 2" -msgstr "2018 年 05 月 30 日 Ahpha リリース 2" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:18 -msgid "2018-06-05 Release Candidate 1" -msgstr "2018 年 06 月 05 日 リリース候補 1" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:19 -msgid "2018-06-08 Release Candidate 2" -msgstr "2018 年 06 月 08 日 リリース候補 2" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:20 -msgid "2018-06-18 Release Candidate 3" -msgstr "2018 年 06 月 18 日 リリース候補 3" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:21 -msgid "2018-06-25 Release Candidate 4" -msgstr "2018 年 06 月 25 日 リリース候補 4" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:22 -msgid "2018-06-26 Release Candidate 5" -msgstr "2018 年 06 月 26 日 リリース候補 5" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:23 -msgid "2018-06-28 Final Release" -msgstr "2018 年 06 月 28 日 最終リリース" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:28 -msgid "2.6.0-2.6.12 Matt Clay (IRC/GitHub: @mattclay)" -msgstr "2.6.0-2.6.12 Matt Clay (IRC/GitHub: @mattclay)" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:29 -msgid "2.6.13+ Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger)" -msgstr "2.6.13+ Toshio Kuratomi (IRC: abadger1999、GitHub: @abadger)" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:35 -msgid "Version 2.6 is largely going to be a stabilization release for Core code." -msgstr "バージョン 2.6 は、主に Core コード用の安定版リリースになります。" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:36 -msgid "Some of the items covered in this release, but are not limited to are the following:" -msgstr "一部の項目は、本リリースで説明されていますが、以下に限定されません。" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:38 -msgid "``ansible-inventory``" -msgstr "``ansible-inventory``" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:39 -msgid "``import_*``" -msgstr "``import_*``" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:40 -msgid "``include_*``" -msgstr "``include_*``" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:41 -msgid "Test coverage" -msgstr "テストカバレッジ" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:42 -msgid "Performance Testing" -msgstr "パフォーマンステスト" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:45 ../../rst/roadmap/ROADMAP_2_7.rst:44 -msgid "Core Modules" -msgstr "コアモジュール" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:46 -msgid "Adopt-a-module Campaign" -msgstr "adopt-a-module キャンペーン" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:48 -msgid "Review current status of all Core Modules" -msgstr "すべての Core モジュールの現在の状態の確認" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:49 -msgid "Reduce backlog of open issues against these modules" -msgstr "これらのモジュールに対してオープン問題のバックログを減らす" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:52 ../../rst/roadmap/ROADMAP_2_7.rst:55 -msgid "Cloud Modules" -msgstr "クラウドモジュール" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:55 ../../rst/roadmap/ROADMAP_2_7.rst:77 -msgid "Network" -msgstr "ネットワーク" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:58 -msgid "Connection work" -msgstr "接続作業" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:60 -msgid "New connection plugin: eAPI `proposal#102 `_" -msgstr "新規接続プラグイン: eAPI (`proposal#102 `_)" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:61 -msgid "New connection plugin: NX-API" -msgstr "新規接続プラグイン: NX-API" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:62 -msgid "Support for configurable options for network_cli & netconf" -msgstr "network_cli & netconf の設定可能なオプションのサポート" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:65 ../../rst/roadmap/ROADMAP_2_7.rst:87 -#: ../../rst/roadmap/ROADMAP_2_7.rst:102 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:67 -msgid "New ``net_get`` - platform agnostic module for pulling configuration via SCP/SFTP over network_cli" -msgstr "新しい ``net_get`` - network_cli 経由で SCP/SFTP を介して設定をプルするプラットフォームに依存しないモジュール" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:68 -msgid "New ``net_put`` - platform agnostic module for pushing configuration via SCP/SFTP over network_cli" -msgstr "新しい ``net_put`` - network_cli 経由で SCP/SFTP を介して設定をプッシュするプラットフォームに依存しないモジュール" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:69 -msgid "New ``netconf_get`` - Netconf module to fetch configuration and state data `proposal#104 `_" -msgstr "新しい ``netconf_get`` - 設定および状態データを取得する Netconf モジュール (`proposal#104 `_)。" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:72 -msgid "Other Features" -msgstr "その他の機能" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:74 -msgid "Stretch & tech preview: Configuration caching for network_cli. Opt-in feature to avoid ``show running`` performance hit" -msgstr "ストレッチおよびテクノロジープレビュー: network_cli の構成キャッシュ。``show running`` パフォーマンスヒットを回避するオプトイン機能" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:3 -msgid "Ansible 2.7" -msgstr "Ansible 2.7" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:13 -msgid "2018-08-23 Core Freeze (Engine and Core Modules/Plugins)" -msgstr "2018 年 08 月 23 日 コアフリーズ (Engine および Core モジュール/プラグイン)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:14 -msgid "2018-08-23 Alpha Release 1" -msgstr "2018 年 08 月 23 日 Ahpha リリース 1" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:15 -msgid "2018-08-30 Community Freeze (Non-Core Modules/Plugins)" -msgstr "2018 年 08 月 30 日 コミュニティーフリーズ (非 Core モジュール/プラグイン)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:16 -msgid "2018-08-30 Beta Release 1" -msgstr "2018 年 08 月 30 日 Beta リリース 1" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:17 -msgid "2018-09-06 Release Candidate 1 (If needed)" -msgstr "2018 年 09 月 06 日 リリース候補 1 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:18 -msgid "2018-09-13 Release Candidate 2 (If needed)" -msgstr "2018 年 09 月 13日 リリース候補 2 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:19 -msgid "2018-09-20 Release Candidate 3 (If needed)" -msgstr "2018 年 09 月 20 日 リリース候補 3 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:20 -msgid "2018-09-27 Release Candidate 4 (If needed)" -msgstr "2018 年 09 月 27日 リリース候補 4 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:21 -msgid "2018-10-04 General Availability" -msgstr "2018 年 10 月 04 日 一般提供 (GA)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:25 ../../rst/roadmap/ROADMAP_2_8.rst:33 -msgid "Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger)" -msgstr "Toshio Kuratomi (IRC: abadger1999、GitHub: @abadger)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:29 -msgid "Cleaning Duty" -msgstr "責務の消去" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:31 -msgid "Drop Py2.6 for controllers `Docs PR #42971 `_ and `issue #42972 `_" -msgstr "コントローラー `Docs PR #42971 `_ および `issue #42972 `_ の場合は、Py2.6 を破棄します。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:33 -msgid "Remove dependency on simplejson `issue #42761 `_" -msgstr "simplejson `issue #42761 `_ の依存関係を削除します。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:37 -msgid "Engine Improvements" -msgstr "エンジンの改善" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:39 -msgid "Performance improvement invoking Python modules `pr #41749 `_" -msgstr "Python モジュール `pr #41749 `_ を呼び出すパフォーマンスが向上しました。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:40 -msgid "Jinja native types will allow for users to render a Python native type. `pr #32738 `_" -msgstr "Jinja ネイティブタイプを使用すると、ユーザーは Python ネイティブタイプをレンダリングできます (`pr #32738 `_)。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:46 -msgid "Include feature changes and improvements" -msgstr "機能変更および改善の追加" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:48 -msgid "Create new argument ``apply`` that will allow for included tasks to inherit explicitly provided attributes. `pr #39236 `_" -msgstr "含まれるタスクが明示的に指定した属性を継承するように、新しい引数 ``apply`` を作成します (`pr #39236 `)。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:49 -msgid "Create \"private\" functionality for allowing vars/default to be exposed outside of roles. `pr #41330 `_" -msgstr "ロール外に vars/default が公開されるように「プライベート」機能を作成します (`pr #41330 `)。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:50 -msgid "Provide a parameter for the ``template`` module to output to different encoding formats `pr #42171 `_" -msgstr "``template`` モジュールが、異なるエンコーディング形式に出力するパラメーターを提供します (`pr #42171 `_)。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:52 -msgid "``reboot`` module for Linux hosts (@samdoran) `pr #35205 `_" -msgstr "Linux ホストの ``reboot`` モジュール (@samdoran) (`pr #35205 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:58 ../../rst/roadmap/ROADMAP_2_7.rst:80 -#: ../../rst/roadmap/ROADMAP_2_7.rst:97 -msgid "General" -msgstr "全般" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:59 -msgid "Cloud auth plugin `proposal #24 `_" -msgstr "クラウド認証プラグイン (`proposal #24 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:63 -msgid "Inventory plugin for RDS `pr #41919 `_" -msgstr "RDS のインベントリープラグイン (`pr #41919 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:64 -msgid "Count support for `ec2_instance`" -msgstr "`ec2_instance` のカウントサポート" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:65 -msgid "`aws_eks` module `pr #41183 `_" -msgstr "`aws_eks` モジュール `pr #41183 `_" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:66 -msgid "Cloudformation stack sets support (`PR#41669 `_)" -msgstr "CloudFormation スタックセットのサポート (`PR#41669 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:67 -msgid "RDS instance and snapshot modules `pr #39994 `_ `pr #43789 `_" -msgstr "RDS インスタンスおよびスナップショットモジュール (`pr #39994 `_ `pr #43789 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:68 -msgid "Diff mode improvements for cloud modules `pr #44533 `_" -msgstr "クラウドモジュールの diff モードが改善 (`pr #44533 `)。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:73 -msgid "Azure inventory plugin `issue #42769 `__" -msgstr "Azure インベントリープラグイン (`issue #42769 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:82 -msgid "Refactor the APIs in cliconf (`issue #39056 `_) and netconf (`issue #39160 `_) plugins so that they have a uniform signature across supported network platforms. **done** (`PR #41846 `_) (`PR #43643 `_) (`PR #43837 `_) (`PR #43203 `_) (`PR #42300 `_) (`PR #44157 `_)" -msgstr "サポートされているネットワークプラットフォーム全体で統一された署名を持つように cliconf (`issue #39056 `_) プラグインおよび netconf (`issue #39160 `_) プラグインで API をリファクタリングする。**完了** (`PR #41846 `_) (`PR #43643 `_) (`PR #43837 `_) (`PR #43203 `_) (`PR #42300 `_) (`PR #44157 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:89 -msgid "New ``cli_config`` module `issue #39228 `_ **done** `PR #42413 `_." -msgstr "新しい ``cli_config`` モジュール (`issue #39228 `_ **完了** (`PR #42413 `_))。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:90 -msgid "New ``cli_command`` module `issue #39284 `_" -msgstr "新しい ``cli_command`` モジュール (`issue #39284 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:91 -msgid "Refactor ``netconf_config`` module to add additional functionality. **done** `proposal #104 `_ (`PR #44379 `_)" -msgstr "``netconf_config`` モジュールをリファクタリングして、追加機能を追加する **完了** (`proposal #104 `_ (`PR #44379 `_))" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:99 -msgid "Added new connection plugin that uses PSRP as the connection protocol `pr #41729 `__" -msgstr "PSRP を接続プロトコルとして使用する新規接続プラグインを追加する (`pr #41729 `_)。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:104 -msgid "Revamp Chocolatey to fix bugs and support offline installation `pr #43013 `_." -msgstr "Chocolatey を改良してバグを修正し、オフラインインストールをサポートする (`pr #43013 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:105 -msgid "Add Chocolatey modules that can manage the following Chocolatey features" -msgstr "以下の Chocolatey 機能を管理できる Chocolatey モジュールを追加する。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:107 -msgid "`Sources `_ `pr #42790 `_" -msgstr "`Sources `_ `pr #42790 `_" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:108 -msgid "`Features `_ `pr #42848 `_" -msgstr "`Features `_ `pr #42848 `_" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:109 -msgid "`Config `_ `pr #42915 `_" -msgstr "`Config `_ `pr #42915 `_" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:3 -msgid "Ansible 2.8" -msgstr "Ansible 2.8" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:14 ../../rst/roadmap/ROADMAP_2_9.rst:14 -msgid "PRs must be raised well in advance of the dates below to have a chance of being included in this Ansible release." -msgstr "プル要求は、この Ansible リリースに含まれる可能性を高めるために、以下の期日に間に合うように、十分な余裕をもって提案してください。" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:16 -msgid "2019-04-04 Alpha 1 **Core freeze** No new features to ``support:core`` code. Includes no new options to existing Core modules" -msgstr "2019 年 04 月 04 日 Alpha 1 **コアフリーズ** ``support:core`` コードへの新機能はありません。既存のコアモジュールに新しいオプションは含まれません。" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:20 -msgid "2019-04-11 Beta 1 **Feature freeze** No new functionality (including modules/plugins) to any code" -msgstr "2019 年 04 月 11 日 ベータ 1 ** 機能フリーズ** いずれのコードへの新機能なし (モジュール/プラグインを含む)" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:23 -msgid "2019-04-25 Release Candidate 1" -msgstr "2019 年 04 月 25 日 リリース候補 1" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:24 -msgid "2019-05-02 Release Candidate 2" -msgstr "2019 年 05 月 02 日 リリース候補 2" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:25 -msgid "2019-05-10 Release Candidate 3" -msgstr "2019 年 05 月 10 日 リリース候補 3" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:26 -msgid "2019-05-16 Release" -msgstr "2019 年 05 月 16 日 リリース" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:38 -msgid "See the `Ansible 2.8 Project Board `_" -msgstr "「`Ansible 2.8 Project Board `_」を参照してください。" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:3 -msgid "Ansible 2.9" -msgstr "Ansible 2.9" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:16 -msgid "There is no Alpha phase in 2.9." -msgstr "2.9 には、Alpha フェーズはありません。" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:18 -msgid "2019-08-29 Beta 1 **Feature freeze** No new functionality (including modules/plugins) to any code" -msgstr "2019 年 08 月 29 日 Beta 1 **機能フリーズ** どのコードにも新しい機能 (モジュール、プラグインなど) はありません。" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:21 -msgid "2019-09-19 Release Candidate 1" -msgstr "2019 年 09 月 19 日 リリースの候補 1" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:22 -msgid "2019-10-03 Release Candidate 2" -msgstr "2019 年 10 月 03 日 リリースの候補 2" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:23 -msgid "2019-10-10 Release Candidate 3" -msgstr "2019 年 10 月 10 日 リリースの候補 3" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:24 -msgid "2019-10-17 Release Candidate 4 (if needed)" -msgstr "2019 年 10 月 17 日 リリースの候補 4 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:25 -msgid "2019-10-24 Release Candidate 5 (if needed)" -msgstr "2019 年 10 月 24 日 リリースの候補 5 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:26 -msgid "2019-10-31 Release" -msgstr "2019 年 10 月 31 日 リリース" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:32 -msgid "TBD" -msgstr "TBD" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:34 -msgid "Temporarily, Matt Davis (@nitzmahone) or Matt Clay (@mattclay) on IRC or github." -msgstr "IRC または github で、暫定的に Matt Davis (@nitzmahone) または Matt Clay (@mattclay) が担当しています。" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:39 -msgid "See the `Ansible 2.9 Project Board `_" -msgstr "「`Ansible 2.9 Project Board `_」を参照してください。" - -#: ../../rst/roadmap/ansible_base_roadmap_index.rst:4 -#: ../../rst/roadmap/ansible_base_roadmap_index.rst:26 -msgid "ansible-core Roadmaps" -msgstr "ansible-core ロードマップ" - -#: ../../rst/roadmap/ansible_base_roadmap_index.rst:6 -msgid "The ``ansible-core`` team develops a roadmap for each major and minor ``ansible-core`` release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.10 and 2.11 have roadmaps, but 2.10.1 does not." -msgstr "``ansible-core`` チームは、``ansible-core`` の各メジャーリリースとマイナーリリースのロードマップを開発しています。最新のロードマップは現在の作業を示し、古いロードマップはプロジェクトの履歴を示します。サブマイナーバージョンのロードマップは公開していません。2.10 と 2.11 にはロードマップがありますが、2.10.1 にはありません。" - -#: ../../rst/roadmap/ansible_base_roadmap_index.rst:10 -msgid "Ansible renamed ``ansible-base`` to ``ansible-core``." -msgstr "Ansible の名前は ``ansible-base`` から ``ansible-core`` に変更しました。" - -#: ../../rst/roadmap/ansible_base_roadmap_index.rst:12 -#: ../../rst/roadmap/ansible_roadmap_index.rst:8 -msgid "We incorporate team and community feedback in each roadmap, and aim for further transparency and better inclusion of both community desires and submissions." -msgstr "各ロードマップにチームとコミュニティーのフィードバックを組み込むことで、コミュニティーの要望と提供されたものをより多く追加し、透明性もより高いものにすることを目指しています。" - -#: ../../rst/roadmap/ansible_base_roadmap_index.rst:14 -msgid "Each roadmap offers a *best guess*, based on the ``ansible-core`` team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, and so on." -msgstr "各ロードマップは、``ansible-core`` チームの経験とコミュニティーからの要求やフィードバックに基づいて、特定のリリースに何が含まれるかについて *最良の推測* を提供します。ただし、ロードマップの一部の項目は、時間的制約、コミュニティーのメンテナー不足などのために削除される場合があります。" - -#: ../../rst/roadmap/ansible_base_roadmap_index.rst:16 -msgid "Each roadmap is published both as an idea of what is upcoming in ``ansible-core``, and as a medium for seeking further feedback from the community." -msgstr "各ロードマップは、``ansible-core`` の今後の予定、およびコミュニティーからのフィードバックを募る媒体として公開されています。" - -#: ../../rst/roadmap/ansible_base_roadmap_index.rst:18 -#: ../../rst/roadmap/ansible_roadmap_index.rst:14 -msgid "You can submit feedback on the current roadmap in multiple ways:" -msgstr "現在のロードマップに関するフィードバックは、複数の方法で送信できます。" - -#: ../../rst/roadmap/ansible_base_roadmap_index.rst:20 -msgid "Edit the agenda of an IRC `Core Team Meeting `_ (preferred)" -msgstr "IRC `Core Team Meeting `_ の議題を編集 (推奨)" - -#: ../../rst/roadmap/ansible_base_roadmap_index.rst:21 -msgid "Post on the ``#ansible-devel`` Freenode IRC channel" -msgstr "Freenode IRC チャンネル ``#ansible-devel`` で発言" - -#: ../../rst/roadmap/ansible_base_roadmap_index.rst:22 -msgid "Email the ansible-devel list" -msgstr "ansible-devel リストへのメール送信" - -#: ../../rst/roadmap/ansible_base_roadmap_index.rst:24 -msgid "See :ref:`Ansible communication channels ` for details on how to join and use the email lists and IRC channels." -msgstr "メーリングリストおよび IRC チャンネルに参加して使用する方法は、「:ref:`Ansible コミュニケーションチャンネル `」を参照してください。" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:21 -msgid "Ansible Release Roadmaps" -msgstr "Ansible リリースロードマップ" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:4 -msgid "Ansible Roadmap" -msgstr "Ansible ロードマップ" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:6 -msgid "The Ansible team develops a roadmap for each major and minor Ansible release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.10 and 2.11 have roadmaps, but 2.10.1 does not." -msgstr "Ansible チームは、Ansible の各メジャーリリースとマイナーリリースのロードマップを開発しています。最新のロードマップは現在の作業を示し、古いロードマップはプロジェクトの履歴を示します。サブマイナーバージョンのロードマップは公開していません。2.10 と 2.11 にはロードマップがありますが、2.10.1 にはありません。" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:10 -msgid "Each roadmap offers a *best guess*, based on the Ansible team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, and so on." -msgstr "各ロードマップは、Ansible チームの経験とコミュニティーからの要求やフィードバックに基づいて、特定のリリースに何が含まれるかについて *最良の推測* を提供します。ただし、ロードマップの一部の項目は、時間的制約、コミュニティーのメンテナー不足などのために削除される場合があります。" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:12 -msgid "Each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community." -msgstr "各ロードマップは、Ansible の今後の予定、およびコミュニティーからのフィードバックを募る媒体として公開されています。" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:16 -msgid "Edit the agenda of an IRC `Ansible Community Meeting `_ (preferred)" -msgstr "IRC `Ansible コミュニティーミーティング `_ の議題を編集 (推奨)" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:17 -msgid "Post on the ``#ansible-community`` Freenode IRC channel" -msgstr "Freenode IRC チャンネル ``#ansible-community`` で発言" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:19 -msgid "See :ref:`Ansible communication channels ` for details on how to join and use the IRC channels." -msgstr "IRC チャンネルに参加して使用する方法は、「:ref:`Ansible コミュニケーションチャンネル `」を参照してください。" - -#: ../../rst/roadmap/index.rst:4 -msgid "Roadmaps" -msgstr "ロードマップ" - -#: ../../rst/roadmap/old_roadmap_index.rst:4 -#: ../../rst/roadmap/old_roadmap_index.rst:10 -msgid "Older Roadmaps" -msgstr "古いロードマップ" - -#: ../../rst/roadmap/old_roadmap_index.rst:6 -msgid "Older roadmaps are listed here to provide a history of the Ansible project." -msgstr "Ansible プロジェクトの履歴は、以下に示す以前のロードマップから確認できます。" - -#: ../../rst/roadmap/old_roadmap_index.rst:8 -msgid "See :ref:`roadmaps` to find current Ansible and ``ansible-base`` roadmaps." -msgstr "現在の Ansible および ``ansible-base`` のロードマップを確認するには、「:ref:`roadmaps`」を参照してください。" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/scenario_guides.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/scenario_guides.po deleted file mode 100644 index d7df308aba0..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/scenario_guides.po +++ /dev/null @@ -1,8346 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2019 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-03-08 20:25+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/scenario_guides/cloud_guides.rst:5 -#: ../../rst/scenario_guides/guides.rst:12 -msgid "Public Cloud Guides" -msgstr "パブリッククラウドガイド" - -#: ../../rst/scenario_guides/cloud_guides.rst:7 -msgid "The guides in this section cover using Ansible with a range of public cloud platforms. They explore particular use cases in greater depth and provide a more \"top-down\" explanation of some basic features." -msgstr "本セクションのガイドでは、さまざまなパブリッククラウドプラットフォームでの Ansible の使用を説明します。特定のユースケースをより深く掘り下げ、いくつかの基本的な機能を「トップダウン」で説明します。" - -#: ../../rst/scenario_guides/guide_aci.rst:4 -msgid "Cisco ACI Guide" -msgstr "Cisco ACI ガイド" - -#: ../../rst/scenario_guides/guide_aci.rst:10 -msgid "What is Cisco ACI ?" -msgstr "Cisco ACI とは" - -#: ../../rst/scenario_guides/guide_aci.rst:13 -msgid "Application Centric Infrastructure (ACI)" -msgstr "ACI (Application Centric Infrastructure)" - -#: ../../rst/scenario_guides/guide_aci.rst:14 -msgid "The Cisco Application Centric Infrastructure (ACI) allows application requirements to define the network. This architecture simplifies, optimizes, and accelerates the entire application deployment life cycle." -msgstr "ACI (Cisco Application Centric Infrastructure) を使用すると、アプリケーション要件でネットワークを定義できます。このアーキテクチャーは、アプリケーションのデプロイメントライフサイクル全体を単純化し、最適化し、高速化します。" - -#: ../../rst/scenario_guides/guide_aci.rst:18 -msgid "Application Policy Infrastructure Controller (APIC)" -msgstr "APIC (Application Policy Infrastructure Controller)" - -#: ../../rst/scenario_guides/guide_aci.rst:19 -msgid "The APIC manages the scalable ACI multi-tenant fabric. The APIC provides a unified point of automation and management, policy programming, application deployment, and health monitoring for the fabric. The APIC, which is implemented as a replicated synchronized clustered controller, optimizes performance, supports any application anywhere, and provides unified operation of the physical and virtual infrastructure." -msgstr "APIC は、スケーラブルな ACI マルチテナントファブリックを管理します。APIC は、ファブリックの自動化と管理、ポリシープログラミング、アプリケーションのデプロイメント、ヘルスモニタリングの統合ポイントを提供します。APIC は、複製された同期クラスターコントローラーとして実装され、パフォーマンスを最適化し、任意のアプリケーションをどこでもサポートし、物理インフラストラクチャーおよび仮想インフラストラクチャーの統一された操作を提供します。" - -#: ../../rst/scenario_guides/guide_aci.rst:21 -msgid "The APIC enables network administrators to easily define the optimal network for applications. Data center operators can clearly see how applications consume network resources, easily isolate and troubleshoot application and infrastructure problems, and monitor and profile resource usage patterns." -msgstr "APIC により、ネットワーク管理者はアプリケーションに最適なネットワークを簡単に定義できます。データセンターオペレーターは、アプリケーションがネットワークリソースをどのように消費するかを明確に確認し、アプリケーションとインフラストラクチャーの問題を簡単に特定してトラブルシューティングを行い、リソースの使用状況パターンを監視およびプロファイルできます。" - -#: ../../rst/scenario_guides/guide_aci.rst:23 -msgid "The Cisco Application Policy Infrastructure Controller (APIC) API enables applications to directly connect with a secure, shared, high-performance resource pool that includes network, compute, and storage capabilities." -msgstr "APIC (Cisco Application Policy Infrastructure Controller) API を使用すると、アプリケーションと、ネットワーク、コンピュート、およびストレージの機能を含む、安全で共有されている高性能リソースプールを直接接続できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:27 -msgid "ACI Fabric" -msgstr "ACI Fabric" - -#: ../../rst/scenario_guides/guide_aci.rst:28 -msgid "The Cisco Application Centric Infrastructure (ACI) Fabric includes Cisco Nexus 9000 Series switches with the APIC to run in the leaf/spine ACI fabric mode. These switches form a \"fat-tree\" network by connecting each leaf node to each spine node; all other devices connect to the leaf nodes. The APIC manages the ACI fabric." -msgstr "Cisco ACI (Application Centric Infrastructure) Fabric には、リーフ/スパインの ACI ファブリックモードで実行する APIC を搭載した Cisco Nexus 9000 シリーズスイッチと同梱されます。このスイッチは、各リーフノードを各スパインノードに接続し、その他のデバイスはリーフノードに接続することで「fat-tree」ネットワークを形成します。APIC は ACI ファブリックを管理します。" - -#: ../../rst/scenario_guides/guide_aci.rst:30 -msgid "The ACI fabric provides consistent low-latency forwarding across high-bandwidth links (40 Gbps, with a 100-Gbps future capability). Traffic with the source and destination on the same leaf switch is handled locally, and all other traffic travels from the ingress leaf to the egress leaf through a spine switch. Although this architecture appears as two hops from a physical perspective, it is actually a single Layer 3 hop because the fabric operates as a single Layer 3 switch." -msgstr "ACI ファブリックは、高帯域幅のリンクで一貫した低レイテンシー転送を提供します (40 Gbps、将来的には 100-Gbps)。送信元および宛先が同じリーフスイッチにあるトラフィックはローカルで処理され、他のすべてのトラフィックはスパインスイッチを介して入力リーフから出力リーフに送信されます。このアーキテクチャーは、物理的には 2 つのホップとして表示されますが、このファブリックが単一の Layer 3 スイッチとして機能するため、実際には単一の Layer 3 ホップとなります。" - -#: ../../rst/scenario_guides/guide_aci.rst:32 -msgid "The ACI fabric object-oriented operating system (OS) runs on each Cisco Nexus 9000 Series node. It enables programming of objects for each configurable element of the system. The ACI fabric OS renders policies from the APIC into a concrete model that runs in the physical infrastructure. The concrete model is analogous to compiled software; it is the form of the model that the switch operating system can execute." -msgstr "ACI ファブリックオブジェクト指向のオペレーティングシステム (OS) は、それぞれの Cisco Nexus 9000 シリーズノードで実行します。ACI ファブリック OS は、APIC からのポリシーを物理インフラストラクチャーで実行する具体的なモデルにレンダリングします。具体的なモデルは、コンパイルされたソフトウェアに似ています。これは、スイッチオペレーティングシステムを実行できるモデルの形式です。" - -#: ../../rst/scenario_guides/guide_aci.rst:34 -msgid "All the switch nodes contain a complete copy of the concrete model. When an administrator creates a policy in the APIC that represents a configuration, the APIC updates the logical model. The APIC then performs the intermediate step of creating a fully elaborated policy that it pushes into all the switch nodes where the concrete model is updated." -msgstr "すべてのスイッチノードには、具体的なモデルの完全なコピーが含まれます。管理者が設定を表す APIC にポリシーを作成すると、APIC は論理モデルを更新します。その後、APIC は、具体的なモデルが更新されるすべてのスイッチノードにプッシュされる完全に改良されたポリシーを作成する中間ステップを実行します。" - -#: ../../rst/scenario_guides/guide_aci.rst:36 -msgid "The APIC is responsible for fabric activation, switch firmware management, network policy configuration, and instantiation. While the APIC acts as the centralized policy and network management engine for the fabric, it is completely removed from the data path, including the forwarding topology. Therefore, the fabric can still forward traffic even when communication with the APIC is lost." -msgstr "APIC は、ファブリックのアクティブ化、ファームウェア管理の切り替え、ネットワークポリシーの設定、およびインスタンス化を行います。APIC はそのファブリックの集中管理ポリシーおよびネットワーク管理エンジンとして機能しますが、転送トポロジーを含むデータパスから完全に削除されます。したがって、ファブリックは APIC との通信が失われてもトラフィックを転送できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:40 -#: ../../rst/scenario_guides/guide_aci.rst:285 -#: ../../rst/scenario_guides/guide_aci.rst:435 -#: ../../rst/scenario_guides/guide_aci.rst:528 -msgid "More information" -msgstr "詳細情報" - -#: ../../rst/scenario_guides/guide_aci.rst:41 -msgid "Various resources exist to start learning ACI, here is a list of interesting articles from the community." -msgstr "ACI の学習を開始するためのさまざまなリソースが存在します。ここでは、コミュニティーからの興味深い記事を記載しています。" - -#: ../../rst/scenario_guides/guide_aci.rst:43 -msgid "`Adam Raffe: Learning ACI `_" -msgstr "`Adam Raffe: Learning ACI `_" - -#: ../../rst/scenario_guides/guide_aci.rst:44 -msgid "`Luca Relandini: ACI for dummies `_" -msgstr "`Luca Relandini: ACI for dummies `_" - -#: ../../rst/scenario_guides/guide_aci.rst:45 -msgid "`Cisco DevNet Learning Labs about ACI `_" -msgstr "`Cisco DevNet Learning Labs about ACI `_" - -#: ../../rst/scenario_guides/guide_aci.rst:51 -msgid "Using the ACI modules" -msgstr "ACI モジュールの使用" - -#: ../../rst/scenario_guides/guide_aci.rst:52 -msgid "The Ansible ACI modules provide a user-friendly interface to managing your ACI environment using Ansible playbooks." -msgstr "Ansible ACI モジュールは、Ansible Playbook を使用して ACI 環境を管理するユーザーフレンドリーなインターフェースを提供します。" - -#: ../../rst/scenario_guides/guide_aci.rst:54 -msgid "For instance ensuring that a specific tenant exists, is done using the following Ansible task using the aci_tenant module:" -msgstr "たとえば、特定のテナントが存在することを確認するには、aci_tenant モジュールを使用して以下の Ansible タスクを使用します。" - -#: ../../rst/scenario_guides/guide_aci.rst:68 -msgid "A complete list of existing ACI modules is available on the content tab of the `ACI collection on Ansible Galaxy `_." -msgstr "既存の ACI モジュールの完全な一覧は、「`Ansible Galaxy での ACI コレクション `_」にあるコンテンツタブで確認できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:70 -msgid "If you want to learn how to write your own ACI modules to contribute, look at the :ref:`Developing Cisco ACI modules ` section." -msgstr "独自の ACI モジュールを作成して貢献する方法を学ぶ場合は、「:ref:`Cisco ACI モジュールの開発 `」セクションを参照してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:73 -msgid "Querying ACI configuration" -msgstr "ACI 設定のクエリー" - -#: ../../rst/scenario_guides/guide_aci.rst:75 -msgid "A module can also be used to query a specific object." -msgstr "モジュールは、特定のオブジェクトのクエリーにも使用できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:89 -msgid "Or query all objects." -msgstr "または、すべてのオブジェクトをクエリーします。" - -#: ../../rst/scenario_guides/guide_aci.rst:102 -msgid "After registering the return values of the aci_tenant task as shown above, you can access all tenant information from variable ``all_tenants``." -msgstr "上記のように aci_tenant タスクの戻り値を登録した後、変数 ``all_tenants`` からすべてのテナント情報にアクセスできます。" - -#: ../../rst/scenario_guides/guide_aci.rst:106 -msgid "Running on the controller locally" -msgstr "コントローラーでローカルに実行" - -#: ../../rst/scenario_guides/guide_aci.rst:107 -msgid "As originally designed, Ansible modules are shipped to and run on the remote target(s), however the ACI modules (like most network-related modules) do not run on the network devices or controller (in this case the APIC), but they talk directly to the APIC's REST interface." -msgstr "最初に設計されたように、Ansible モジュールはリモートターゲットに同梱され、実行しますが、ACI モジュール (ほとんどのネットワーク関連モジュールなど) はネットワークデバイスやコントローラー (この場合は APIC) では動作しませんが、APIC の REST インターフェースと直接対話します。" - -#: ../../rst/scenario_guides/guide_aci.rst:109 -msgid "For this very reason, the modules need to run on the local Ansible controller (or are delegated to another system that *can* connect to the APIC)." -msgstr "このため、モジュールはローカルの Ansible コントローラーで実行する必要があります (または、APIC に接続 *できる* 別のシステムに委譲されます)。" - -#: ../../rst/scenario_guides/guide_aci.rst:113 -msgid "Gathering facts" -msgstr "ファクトの収集" - -#: ../../rst/scenario_guides/guide_aci.rst:114 -msgid "Because we run the modules on the Ansible controller gathering facts will not work. That is why when using these ACI modules it is mandatory to disable facts gathering. You can do this globally in your ``ansible.cfg`` or by adding ``gather_facts: no`` to every play." -msgstr "Ansible コントローラーでモジュールを実行するため、ファクトの収集は機能しません。そのため、これらの ACI モジュールを使用する場合はファクトの収集を無効にする必要があります。これは、``ansible.cfg`` でグローバルに行うか、すべてのプレイに ``gather_facts: no`` を追加して行うことができます。" - -#: ../../rst/scenario_guides/guide_aci.rst:128 -msgid "Delegating to localhost" -msgstr "ローカルホストへの委譲" - -#: ../../rst/scenario_guides/guide_aci.rst:129 -msgid "So let us assume we have our target configured in the inventory using the FQDN name as the ``ansible_host`` value, as shown below." -msgstr "そのため、以下に示すように、FQDN 名を ``ansible_host`` 値として使用し、ターゲットをインベントリーに設定したと仮定します。" - -#: ../../rst/scenario_guides/guide_aci.rst:140 -msgid "One way to set this up is to add to every task the directive: ``delegate_to: localhost``." -msgstr "これを設定する方法は、ディレクティブのすべてのタスク (``delegate_to: localhost``) に追加することです。" - -#: ../../rst/scenario_guides/guide_aci.rst:155 -msgid "If one would forget to add this directive, Ansible will attempt to connect to the APIC using SSH and attempt to copy the module and run it remotely. This will fail with a clear error, yet may be confusing to some." -msgstr "このディレクティブの追加を忘れると、Ansible は SSH を使用して APIC への接続を試み、モジュールをコピーしてリモートで実行しようとします。これはクリアエラーで失敗しますが、混乱が生じる可能性があります。" - -#: ../../rst/scenario_guides/guide_aci.rst:159 -msgid "Using the local connection method" -msgstr "ローカル接続方法の使用" - -#: ../../rst/scenario_guides/guide_aci.rst:160 -msgid "Another option frequently used, is to tie the ``local`` connection method to this target so that every subsequent task for this target will use the local connection method (hence run it locally, rather than use SSH)." -msgstr "よく使用される別のオプションは、``local`` 接続方法をこのターゲットに結び付けることです。これにより、このターゲットの後続のすべてのタスクでローカル接続方法が使用されます (したがって、SSH を使用するのではなくローカルで実行します)。" - -#: ../../rst/scenario_guides/guide_aci.rst:162 -msgid "In this case the inventory may look like this:" -msgstr "この場合、インベントリーは以下のようになります。" - -#: ../../rst/scenario_guides/guide_aci.rst:174 -msgid "But used tasks do not need anything special added." -msgstr "ただし、使用したタスクには特別な追加は必要ありません。" - -#: ../../rst/scenario_guides/guide_aci.rst:187 -msgid "For clarity we have added ``delegate_to: localhost`` to all the examples in the module documentation. This helps to ensure first-time users can easily copy&paste parts and make them work with a minimum of effort." -msgstr "分かりやすくするために、モジュールドキュメントのすべての例に ``delegate_to: localhost`` を追加しました。これにより、初回のユーザーが簡単に一部をコピーして、最低限の努力で作業できるようになります。" - -#: ../../rst/scenario_guides/guide_aci.rst:191 -msgid "Common parameters" -msgstr "一般的なパラメーター" - -#: ../../rst/scenario_guides/guide_aci.rst:192 -msgid "Every Ansible ACI module accepts the following parameters that influence the module's communication with the APIC REST API:" -msgstr "すべての Ansible ACI モジュールは、APIC REST API を使用したモジュールの通信に影響を与える以下のパラメーターを受け入れます。" - -#: ../../rst/scenario_guides/guide_aci.rst:195 -#: ../../rst/scenario_guides/guide_meraki.rst:65 -msgid "host" -msgstr "host" - -#: ../../rst/scenario_guides/guide_aci.rst:195 -msgid "Hostname or IP address of the APIC." -msgstr "APIC のホスト名または IP アドレス。" - -#: ../../rst/scenario_guides/guide_aci.rst:198 -msgid "port" -msgstr "port" - -#: ../../rst/scenario_guides/guide_aci.rst:198 -msgid "Port to use for communication. (Defaults to ``443`` for HTTPS, and ``80`` for HTTP)" -msgstr "通信に使用するポート (デフォルトでは、HTTPS の場合は ``443``、HTTP の場合は ``80``)。" - -#: ../../rst/scenario_guides/guide_aci.rst:201 -msgid "username" -msgstr "username" - -#: ../../rst/scenario_guides/guide_aci.rst:201 -msgid "User name used to log on to the APIC. (Defaults to ``admin``)" -msgstr "APIC にログインするのに使用されるユーザー名 (デフォルトは ``admin``)。" - -#: ../../rst/scenario_guides/guide_aci.rst:204 -#: ../../rst/scenario_guides/guide_azure.rst:132 -#: ../../rst/scenario_guides/guide_azure.rst:138 -msgid "password" -msgstr "password" - -#: ../../rst/scenario_guides/guide_aci.rst:204 -msgid "Password for ``username`` to log on to the APIC, using password-based authentication." -msgstr "パスワードベースの認証を使用して APIC にログインする ``username`` のパスワード。" - -#: ../../rst/scenario_guides/guide_aci.rst:209 -msgid "private_key" -msgstr "private_key" - -#: ../../rst/scenario_guides/guide_aci.rst:207 -msgid "Private key for ``username`` to log on to APIC, using signature-based authentication. This could either be the raw private key content (include header/footer) or a file that stores the key content. *New in version 2.5*" -msgstr "署名ベースの認証を使用して APIC にログインする ``username`` の秘密鍵。これは、(ヘッダー/フッターを含む) 生の秘密鍵コンテンツ、または鍵コンテンツを格納するファイルのいずれかになります。*バージョン 2.5 の新機能* です。" - -#: ../../rst/scenario_guides/guide_aci.rst:214 -msgid "certificate_name" -msgstr "certificate_name" - -#: ../../rst/scenario_guides/guide_aci.rst:212 -msgid "Name of the certificate in the ACI Web GUI. This defaults to either the ``username`` value or the ``private_key`` file base name). *New in version 2.5*" -msgstr "ACI Web GUI の証明書の名前。デフォルトは ``username`` 値または ``private_key`` ファイルのベース名になります。*バージョン 2.5 の新機能* です。" - -#: ../../rst/scenario_guides/guide_aci.rst:217 -#: ../../rst/scenario_guides/guide_docker.rst:53 -msgid "timeout" -msgstr "timeout" - -#: ../../rst/scenario_guides/guide_aci.rst:217 -msgid "Timeout value for socket-level communication." -msgstr "ソケットレベルの通信のタイムアウト値。" - -#: ../../rst/scenario_guides/guide_aci.rst:220 -#: ../../rst/scenario_guides/guide_meraki.rst:71 -msgid "use_proxy" -msgstr "use_proxy" - -#: ../../rst/scenario_guides/guide_aci.rst:220 -msgid "Use system proxy settings. (Defaults to ``yes``)" -msgstr "システムプロキシー設定を使用します (``yes`` にデフォルト設定)。" - -#: ../../rst/scenario_guides/guide_aci.rst:223 -msgid "use_ssl" -msgstr "use_ssl" - -#: ../../rst/scenario_guides/guide_aci.rst:223 -msgid "Use HTTPS or HTTP for APIC REST communication. (Defaults to ``yes``)" -msgstr "APIC REST 通信には HTTPS または HTTP を使用します (``yes`` にデフォルト設定)。" - -#: ../../rst/scenario_guides/guide_aci.rst:226 -#: ../../rst/scenario_guides/guide_docker.rst:59 -#: ../../rst/scenario_guides/guide_meraki.rst:74 -msgid "validate_certs" -msgstr "validate_certs" - -#: ../../rst/scenario_guides/guide_aci.rst:226 -msgid "Validate certificate when using HTTPS communication. (Defaults to ``yes``)" -msgstr "HTTPS 通信を使用する場合に証明書を検証します (``yes`` にデフォルト設定)。" - -#: ../../rst/scenario_guides/guide_aci.rst:230 -msgid "output_level" -msgstr "output_level" - -#: ../../rst/scenario_guides/guide_aci.rst:229 -msgid "Influence the level of detail ACI modules return to the user. (One of ``normal``, ``info`` or ``debug``) *New in version 2.5*" -msgstr "詳細な ACI モジュールがユーザーに返すレベルに影響します (``normal``、``info``、または ``debug`` のいずれか)。*バージョン 2.5 の新機能* です。" - -#: ../../rst/scenario_guides/guide_aci.rst:233 -msgid "Proxy support" -msgstr "プロキシーのサポート" - -#: ../../rst/scenario_guides/guide_aci.rst:234 -msgid "By default, if an environment variable ``_proxy`` is set on the target host, requests will be sent through that proxy. This behaviour can be overridden by setting a variable for this task (see :ref:`playbooks_environment`), or by using the ``use_proxy`` module parameter." -msgstr "デフォルトでは、環境変数 ``_proxy`` がターゲットホストに設定されていると、要求はそのプロキシー経由で送信されます。この動作は、このタスクに変数を設定して上書きする (「:ref:`playbooks_environment`」を参照) か、``use_proxy`` モジュールパラメーターを使用して上書きできます。" - -#: ../../rst/scenario_guides/guide_aci.rst:236 -msgid "HTTP redirects can redirect from HTTP to HTTPS so ensure that the proxy environment for both protocols is correctly configured." -msgstr "HTTP リダイレクトは HTTP から HTTPS へリダイレクトできるため、両方のプロトコルのプロキシー環境が正しく設定されていることを確認します。" - -#: ../../rst/scenario_guides/guide_aci.rst:238 -msgid "If proxy support is not needed, but the system may have it configured nevertheless, use the parameter ``use_proxy: no`` to avoid accidental system proxy usage." -msgstr "プロキシーサポートが必要なくても、システムがそれを設定する可能性がある場合は、``use_proxy: no`` パラメーターを使用して、誤ったシステムプロキシーの使用を回避します。" - -#: ../../rst/scenario_guides/guide_aci.rst:240 -msgid "Selective proxy support using the ``no_proxy`` environment variable is also supported." -msgstr "``no_proxy`` 環境変数を使用した選択的プロキシーサポートにも対応しています。" - -#: ../../rst/scenario_guides/guide_aci.rst:244 -msgid "Return values" -msgstr "戻り値" - -#: ../../rst/scenario_guides/guide_aci.rst:248 -msgid "The following values are always returned:" -msgstr "以下の値が常に返されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:251 -msgid "current" -msgstr "current" - -#: ../../rst/scenario_guides/guide_aci.rst:251 -msgid "The resulting state of the managed object, or results of your query." -msgstr "管理オブジェクトの結果の状態、またはクエリーの結果。" - -#: ../../rst/scenario_guides/guide_aci.rst:253 -msgid "The following values are returned when ``output_level: info``:" -msgstr "``output_level: info`` の場合は、以下の値が常に返されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:256 -msgid "previous" -msgstr "previous" - -#: ../../rst/scenario_guides/guide_aci.rst:256 -msgid "The original state of the managed object (before any change was made)." -msgstr "管理オブジェクトの元の状態 (変更を行う前)。" - -#: ../../rst/scenario_guides/guide_aci.rst:259 -msgid "proposed" -msgstr "proposed" - -#: ../../rst/scenario_guides/guide_aci.rst:259 -msgid "The proposed config payload, based on user-supplied values." -msgstr "ユーザーが指定した値に基づく、提案された設定ペイロード。" - -#: ../../rst/scenario_guides/guide_aci.rst:262 -msgid "sent" -msgstr "sent" - -#: ../../rst/scenario_guides/guide_aci.rst:262 -msgid "The sent config payload, based on user-supplied values and the existing configuration." -msgstr "ユーザーが指定した値、および既存の設定に基づく、送信された設定ペイロード。" - -#: ../../rst/scenario_guides/guide_aci.rst:264 -msgid "The following values are returned when ``output_level: debug`` or ``ANSIBLE_DEBUG=1``:" -msgstr "``output_level: debug`` または``ANSIBLE_DEBUG=1`` の場合は、以下の値が常に返されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:267 -msgid "filter_string" -msgstr "filter_string" - -#: ../../rst/scenario_guides/guide_aci.rst:267 -msgid "The filter used for specific APIC queries." -msgstr "特定の APIC クエリーに使用されるフィルター。" - -#: ../../rst/scenario_guides/guide_aci.rst:270 -msgid "method" -msgstr "method" - -#: ../../rst/scenario_guides/guide_aci.rst:270 -msgid "The HTTP method used for the sent payload. (Either ``GET`` for queries, ``DELETE`` or ``POST`` for changes)" -msgstr "送信されたペイロードに使用される HTTP メソッド (問い合わせの ``GET``、もしくは変更の ``DELETE`` または``POST`` のいずれか)。" - -#: ../../rst/scenario_guides/guide_aci.rst:273 -msgid "response" -msgstr "response" - -#: ../../rst/scenario_guides/guide_aci.rst:273 -msgid "The HTTP response from the APIC." -msgstr "APIC からの HTTP 応答。" - -#: ../../rst/scenario_guides/guide_aci.rst:276 -msgid "status" -msgstr "status" - -#: ../../rst/scenario_guides/guide_aci.rst:276 -msgid "The HTTP status code for the request." -msgstr "要求の HTTP ステータスコード。" - -#: ../../rst/scenario_guides/guide_aci.rst:279 -msgid "url" -msgstr "url" - -#: ../../rst/scenario_guides/guide_aci.rst:279 -msgid "The url used for the request." -msgstr "要求に使用される URL。" - -#: ../../rst/scenario_guides/guide_aci.rst:281 -msgid "The module return values are documented in detail as part of each module's documentation." -msgstr "モジュールの戻り値は、各モジュールのドキュメントで詳細に説明されています。" - -#: ../../rst/scenario_guides/guide_aci.rst:286 -msgid "Various resources exist to start learn more about ACI programmability, we recommend the following links:" -msgstr "ACI プログラミングの詳細を学ぶために、さまざまなリソースがあります。以下のリンクが推奨されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:288 -#: ../../rst/scenario_guides/guide_aci.rst:650 -msgid ":ref:`Developing Cisco ACI modules `" -msgstr ":ref:`Developing Cisco ACI modules `" - -#: ../../rst/scenario_guides/guide_aci.rst:289 -msgid "`Jacob McGill: Automating Cisco ACI with Ansible `_" -msgstr "`Jacob McGill: Automating Cisco ACI with Ansible `_" - -#: ../../rst/scenario_guides/guide_aci.rst:290 -msgid "`Cisco DevNet Learning Labs about ACI and Ansible `_" -msgstr "`Cisco DevNet Learning Labs about ACI and Ansible `_" - -#: ../../rst/scenario_guides/guide_aci.rst:296 -msgid "ACI authentication" -msgstr "ACI 認証" - -#: ../../rst/scenario_guides/guide_aci.rst:299 -msgid "Password-based authentication" -msgstr "パスワードベースの認証" - -#: ../../rst/scenario_guides/guide_aci.rst:300 -msgid "If you want to log on using a username and password, you can use the following parameters with your ACI modules:" -msgstr "ユーザー名とパスワードを使用してログインする場合は、ACI モジュールで以下のパラメーターを使用できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:307 -msgid "Password-based authentication is very simple to work with, but it is not the most efficient form of authentication from ACI's point-of-view as it requires a separate login-request and an open session to work. To avoid having your session time-out and requiring another login, you can use the more efficient Signature-based authentication." -msgstr "パスワードベースの認証は非常に簡単ですが、別のログイン要求とオープンセッションが機能する必要があるため、ACI の観点から最も効率的な認証形式ではありません。セッションのタイムアウトや別のログインを必要としないように、より効率的な署名ベースの認証を使用できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:309 -msgid "Password-based authentication also may trigger anti-DoS measures in ACI v3.1+ that causes session throttling and results in HTTP 503 errors and login failures." -msgstr "パスワードベースの認証では、ACI v3.1 以降の DoS 対策がトリガーとなり、セッションスロットルが発生し、HTTP 503 エラーとなり、ログインが失敗する可能性があります。" - -#: ../../rst/scenario_guides/guide_aci.rst:311 -msgid "Never store passwords in plain text." -msgstr "プレーンテキストにパスワードを保存しないでください。" - -#: ../../rst/scenario_guides/guide_aci.rst:313 -#: ../../rst/scenario_guides/guide_meraki.rst:100 -msgid "The \"Vault\" feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See :ref:`playbooks_vault` for more information." -msgstr "Ansible の「Vault」機能を使用すると、パスワードやキーなどの機密データを、Playbook やロールのプレーンテキストとしてではなく、暗号化されたファイルに保存することができます。この Vault ファイルは、ソース制御に配布または配置することができます。詳細は、「:ref:`playbooks_vault`」を参照してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:317 -msgid "Signature-based authentication using certificates" -msgstr "証明書を使用した署名ベースの認証" - -#: ../../rst/scenario_guides/guide_aci.rst:321 -msgid "Using signature-based authentication is more efficient and more reliable than password-based authentication." -msgstr "署名ベースの認証の使用は、パスワードベースの認証よりも効率的で、信頼性が高くなります。" - -#: ../../rst/scenario_guides/guide_aci.rst:324 -msgid "Generate certificate and private key" -msgstr "証明書と秘密鍵の生成" - -#: ../../rst/scenario_guides/guide_aci.rst:325 -msgid "Signature-based authentication requires a (self-signed) X.509 certificate with private key, and a configuration step for your AAA user in ACI. To generate a working X.509 certificate and private key, use the following procedure:" -msgstr "署名ベースの認証では、秘密鍵を持つ (自己署名) X.509 証明書と、ACI の AAA ユーザーの設定手順が必要になります。稼働中の X.509 証明書および秘密鍵を生成するには、以下の手順に従います。" - -#: ../../rst/scenario_guides/guide_aci.rst:332 -msgid "Configure your local user" -msgstr "ローカルユーザーの設定" - -#: ../../rst/scenario_guides/guide_aci.rst:333 -msgid "Perform the following steps:" -msgstr "以下の手順を実行します。" - -#: ../../rst/scenario_guides/guide_aci.rst:335 -msgid "Add the X.509 certificate to your ACI AAA local user at :guilabel:`ADMIN` » :guilabel:`AAA`" -msgstr ":guilabel:`ADMIN` » :guilabel:`AAA` で、ACI AAA ローカルユーザーに X.509 証明書を追加します。" - -#: ../../rst/scenario_guides/guide_aci.rst:336 -msgid "Click :guilabel:`AAA Authentication`" -msgstr ":guilabel:`AAA Authentication` をクリックします。" - -#: ../../rst/scenario_guides/guide_aci.rst:337 -msgid "Check that in the :guilabel:`Authentication` field the :guilabel:`Realm` field displays :guilabel:`Local`" -msgstr ":guilabel:`Authentication` フィールドで、:guilabel:`Realm` フィールドが :guilabel:`Local` と表示されていることを確認します。" - -#: ../../rst/scenario_guides/guide_aci.rst:338 -msgid "Expand :guilabel:`Security Management` » :guilabel:`Local Users`" -msgstr ":guilabel:`Security Management` » :guilabel:`Local Users` と展開します。" - -#: ../../rst/scenario_guides/guide_aci.rst:339 -msgid "Click the name of the user you want to add a certificate to, in the :guilabel:`User Certificates` area" -msgstr ":guilabel:`User Certificates` エリアで、証明書を追加するユーザー名をクリックします。" - -#: ../../rst/scenario_guides/guide_aci.rst:340 -msgid "Click the :guilabel:`+` sign and in the :guilabel:`Create X509 Certificate` enter a certificate name in the :guilabel:`Name` field" -msgstr ":guilabel:`+` 記号をクリックし、:guilabel:`Create X509 Certificate` の :guilabel:`Name` フィールドに証明書名を入力します。" - -#: ../../rst/scenario_guides/guide_aci.rst:342 -msgid "If you use the basename of your private key here, you don't need to enter ``certificate_name`` in Ansible" -msgstr "ここで秘密鍵のベース名を使用する場合は、Ansible で ``certificate_name`` を入力する必要はありません。" - -#: ../../rst/scenario_guides/guide_aci.rst:344 -msgid "Copy and paste your X.509 certificate in the :guilabel:`Data` field." -msgstr ":guilabel:`Data` フィールドに X.509 証明書をコピーして貼り付けます。" - -#: ../../rst/scenario_guides/guide_aci.rst:346 -msgid "You can automate this by using the following Ansible task:" -msgstr "これは、以下の Ansible タスクを使用して自動化できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:360 -msgid "Signature-based authentication only works with local users." -msgstr "署名ベースの認証は、ローカルユーザーでのみ機能します。" - -#: ../../rst/scenario_guides/guide_aci.rst:364 -msgid "Use signature-based authentication with Ansible" -msgstr "Ansible での署名ベースの認証の使用" - -#: ../../rst/scenario_guides/guide_aci.rst:365 -msgid "You need the following parameters with your ACI module(s) for it to work:" -msgstr "これを有効にするには、ACI モジュールで以下のパラメーターが必要です。" - -#: ../../rst/scenario_guides/guide_aci.rst:374 -msgid "or you can use the private key content:" -msgstr "または、秘密鍵のコンテンツを使用できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:387 -msgid "If you use a certificate name in ACI that matches the private key's basename, you can leave out the ``certificate_name`` parameter like the example above." -msgstr "秘密鍵のベース名に一致する ACI で証明書名を使用する場合は、上記の例のような ``certificate_name`` パラメーターを省略できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:391 -msgid "Using Ansible Vault to encrypt the private key" -msgstr "Ansible Vault を使用した秘密鍵の暗号化" - -#: ../../rst/scenario_guides/guide_aci.rst:394 -msgid "To start, encrypt the private key and give it a strong password." -msgstr "まず、秘密鍵を暗号化して強固なパスワードを付与します。" - -#: ../../rst/scenario_guides/guide_aci.rst:400 -msgid "Use a text editor to open the private-key. You should have an encrypted cert now." -msgstr "テキストエディターを使用して、秘密鍵を開きます。これで、暗号化された証明書が存在するはずです。" - -#: ../../rst/scenario_guides/guide_aci.rst:409 -msgid "Copy and paste the new encrypted cert into your playbook as a new variable." -msgstr "新しい暗号化された証明書を新規の変数として Playbook にコピーアンドペーストします。" - -#: ../../rst/scenario_guides/guide_aci.rst:419 -msgid "Use the new variable for the private_key:" -msgstr "private_key の新しい変数を使用します。" - -#: ../../rst/scenario_guides/guide_aci.rst:427 -msgid "When running the playbook, use \"--ask-vault-pass\" to decrypt the private key." -msgstr "Playbook の実行時に、「--ask-vault-pass」を使用して秘密鍵を復号します。" - -#: ../../rst/scenario_guides/guide_aci.rst:436 -msgid "Detailed information about Signature-based Authentication is available from `Cisco APIC Signature-Based Transactions `_." -msgstr "- 署名ベースの認証に関する詳細情報は、「`Cisco APIC Signature-Based Transactions `_」を参照してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:437 -msgid "More information on Ansible Vault can be found on the :ref:`Ansible Vault ` page." -msgstr "Ansible Vault の詳細は、「:ref:`Ansible Vault `」ページを参照してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:443 -msgid "Using ACI REST with Ansible" -msgstr "Ansible での ACI REST の使用" - -#: ../../rst/scenario_guides/guide_aci.rst:444 -msgid "While already a lot of ACI modules exists in the Ansible distribution, and the most common actions can be performed with these existing modules, there's always something that may not be possible with off-the-shelf modules." -msgstr "すでに多くの ACI モジュールが Ansible ディストリビューションに同梱されており、最も一般的なアクションはこれらの既存のモジュールで実行できますが、既製のモジュールではできないことは常にあります。" - -#: ../../rst/scenario_guides/guide_aci.rst:446 -msgid "The aci_rest module provides you with direct access to the APIC REST API and enables you to perform any task not already covered by the existing modules. This may seem like a complex undertaking, but you can generate the needed REST payload for any action performed in the ACI web interface effortlessly." -msgstr "aci_rest モジュールを使用すると、APIC REST API に直接アクセスでき、既存のモジュールで対応していないタスクを実行できます。これは複雑な作業のように思えるかもしれませんが、ACI Web インターフェースで実行されるアクションに必要な REST ペイロードを簡単に生成できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:450 -msgid "Built-in idempotency" -msgstr "組み込みの冪等性" - -#: ../../rst/scenario_guides/guide_aci.rst:451 -msgid "Because the APIC REST API is intrinsically idempotent and can report whether a change was made, the aci_rest module automatically inherits both capabilities and is a first-class solution for automating your ACI infrastructure. As a result, users that require more powerful low-level access to their ACI infrastructure don't have to give up on idempotency and don't have to guess whether a change was performed when using the aci_rest module." -msgstr "APIC REST API は冪等であり、変更されたかどうかを報告することができるため、aci_rest モジュールは両方の機能を自動的に継承し、ACI インフラストラクチャーを自動化するファーストクラスソリューションとなります。その結果、ACI インフラストラクチャーへのより強力な低レベルアクセスを必要とするユーザーは、冪等性をあきらめる必要がなく、aci_rest モジュールの使用時に変更が行われたかどうかを推測する必要もありません。" - -#: ../../rst/scenario_guides/guide_aci.rst:455 -msgid "Using the aci_rest module" -msgstr "aci_rest モジュールの使用" - -#: ../../rst/scenario_guides/guide_aci.rst:456 -msgid "The aci_rest module accepts the native XML and JSON payloads, but additionally accepts inline YAML payload (structured like JSON). The XML payload requires you to use a path ending with ``.xml`` whereas JSON or YAML require the path to end with ``.json``." -msgstr "aci_rest モジュールはネイティブの XML ペイロードおよび JSON ペイロードを受け入れますが、(JSON などの) インライン YAML ペイロードも追加で受け入れます。XML ペイロードでは、``.xml`` で終わるパスを使用する必要がありますが、JSON または YAML には ``.json`` で終わるパスが必要です。" - -#: ../../rst/scenario_guides/guide_aci.rst:458 -msgid "When you're making modifications, you can use the POST or DELETE methods, whereas doing just queries require the GET method." -msgstr "変更を行う場合は、POST メソッドまたは DELETE メソッドを使用できますが、クエリーのみを実行するには GET メソッドが必要です。" - -#: ../../rst/scenario_guides/guide_aci.rst:460 -msgid "For instance, if you would like to ensure a specific tenant exists on ACI, these below four examples are functionally identical:" -msgstr "たとえば、特定のテナントが ACI に存在することを確認する場合は、以下の 4 つの例が機能的に同じです。" - -#: ../../rst/scenario_guides/guide_aci.rst:462 -msgid "**XML** (Native ACI REST)" -msgstr "**XML** (ネイティブの ACI REST)" - -#: ../../rst/scenario_guides/guide_aci.rst:475 -msgid "**JSON** (Native ACI REST)" -msgstr "**JSON** (ネイティブの ACI REST)" - -#: ../../rst/scenario_guides/guide_aci.rst:495 -msgid "**YAML** (Ansible-style REST)" -msgstr "**YAML** (Ansible スタイルの REST)" - -#: ../../rst/scenario_guides/guide_aci.rst:511 -msgid "**Ansible task** (Dedicated module)" -msgstr "**Ansible タスク** (専用モジュール)" - -#: ../../rst/scenario_guides/guide_aci.rst:524 -msgid "The XML format is more practical when there is a need to template the REST payload (inline), but the YAML format is more convenient for maintaining your infrastructure-as-code and feels more naturally integrated with Ansible playbooks. The dedicated modules offer a more simple, abstracted, but also a more limited experience. Use what feels best for your use-case." -msgstr "XML 形式は、REST ペイロード (インライン) のテンプレートが必要な場合により実用的なものですが、YAML 形式は infrastructure-as-code を維持するのに便利で、Ansible Playbook との統合もより自然に感じられます。専用モジュールは、よりシンプルで抽象化されたモジュールを提供しますが、より限定的なエクスペリエンスも提供します。ユースケースに最適なものを使用してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:529 -msgid "Plenty of resources exist to learn about ACI's APIC REST interface, we recommend the links below:" -msgstr "ACI の APIC REST インターフェースを学ぶためのリソースは多数あります。以下のリンクが推奨されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:531 -msgid "`The ACI collection on Ansible Galaxy `_" -msgstr "`The ACI collection on Ansible Galaxy `_" - -#: ../../rst/scenario_guides/guide_aci.rst:532 -msgid "`APIC REST API Configuration Guide `_ -- Detailed guide on how the APIC REST API is designed and used, incl. many examples" -msgstr "`APIC REST API 設定ガイド `_ -- APIC REST API を設計および使用する方法についての詳細ガイド。多数の例があります。" - -#: ../../rst/scenario_guides/guide_aci.rst:533 -msgid "`APIC Management Information Model reference `_ -- Complete reference of the APIC object model" -msgstr "`APIC 管理情報モデルリファレンス `_ -- APIC オブジェクトモデルの完全なリファレンス。" - -#: ../../rst/scenario_guides/guide_aci.rst:534 -msgid "`Cisco DevNet Learning Labs about ACI and REST `_" -msgstr "`Cisco DevNet Learning Labs about ACI and REST `_" - -#: ../../rst/scenario_guides/guide_aci.rst:540 -msgid "Operational examples" -msgstr "運用例" - -#: ../../rst/scenario_guides/guide_aci.rst:541 -msgid "Here is a small overview of useful operational tasks to reuse in your playbooks." -msgstr "以下は、Playbook で再利用するのに役立つ運用タスクの概要です。" - -#: ../../rst/scenario_guides/guide_aci.rst:543 -msgid "Feel free to contribute more useful snippets." -msgstr "より有用なスニペットを自由に投稿してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:547 -msgid "Waiting for all controllers to be ready" -msgstr "Waiting for all controllers to be ready" - -#: ../../rst/scenario_guides/guide_aci.rst:548 -msgid "You can use the below task after you started to build your APICs and configured the cluster to wait until all the APICs have come online. It will wait until the number of controllers equals the number listed in the ``apic`` inventory group." -msgstr "APIC の構築を開始し、すべての APIC がオンラインになるまで待機するようにクラスターを設定したら、以下のタスクを使用できます。これは、コントローラーの数が ``apic`` インベントリーに挙げられている数と等しくなるまで待機します。" - -#: ../../rst/scenario_guides/guide_aci.rst:565 -msgid "Waiting for cluster to be fully-fit" -msgstr "Waiting for cluster to be fully-fit" - -#: ../../rst/scenario_guides/guide_aci.rst:566 -msgid "The below example waits until the cluster is fully-fit. In this example you know the number of APICs in the cluster and you verify each APIC reports a 'fully-fit' status." -msgstr "以下の例では、クラスターが完全に調整されるまで待機します。この例では、クラスター内の APIC の数を把握し、各 APIC が「完全に適切な」状態を報告することを確認します。" - -#: ../../rst/scenario_guides/guide_aci.rst:590 -msgid "APIC error messages" -msgstr "APIC エラーメッセージ" - -#: ../../rst/scenario_guides/guide_aci.rst:591 -msgid "The following error messages may occur and this section can help you understand what exactly is going on and how to fix/avoid them." -msgstr "以下のエラーメッセージが発生する場合があります。本セクションは、正確な状況と、その修正方法や回避方法を理解するのに役立ちます。" - -#: ../../rst/scenario_guides/guide_aci.rst:595 -msgid "APIC Error 122: unknown managed object class 'polUni'" -msgstr "APIC Error 122: unknown managed object class 'polUni'" - -#: ../../rst/scenario_guides/guide_aci.rst:594 -msgid "In case you receive this error while you are certain your aci_rest payload and object classes are seemingly correct, the issue might be that your payload is not in fact correct JSON (for example, the sent payload is using single quotes, rather than double quotes), and as a result the APIC is not correctly parsing your object classes from the payload. One way to avoid this is by using a YAML or an XML formatted payload, which are easier to construct correctly and modify later." -msgstr "aci_rest ペイロードとオブジェクトクラスが一見正しいように見える場合にこのエラーが発生する場合は、ペイロードの JSON に誤りがあり (たとえば、送信されたペイロードが二重引用符ではなく一重引用符を使用している) 、その結果 APIC がペイロードからオブジェクトクラスを正しく解析していない可能性があります。これを回避する 1 つの方法は、YAML 形式または XML 形式のペイロードを使用することです。これにより、正しく構築して後で変更するのが簡単になります。" - -#: ../../rst/scenario_guides/guide_aci.rst:599 -msgid "APIC Error 400: invalid data at line '1'. Attributes are missing, tag 'attributes' must be specified first, before any other tag" -msgstr "APIC Error 400: invalid data at line '1'. Attributes are missing, tag 'attributes' must be specified first, before any other tag" - -#: ../../rst/scenario_guides/guide_aci.rst:598 -msgid "Although the JSON specification allows unordered elements, the APIC REST API requires that the JSON ``attributes`` element precede the ``children`` array or other elements. So you need to ensure that your payload conforms to this requirement. Sorting your dictionary keys will do the trick just fine. If you don't have any attributes, it may be necessary to add: ``attributes: {}`` as the APIC does expect the entry to precede any ``children``." -msgstr "JSON 仕様は順序付けされていない要素を許可しますが、APIC REST API では、JSON の ``attributes`` 要素が ``children`` アレイまたは他の要素の前になければなりません。そのため、ペイロードがこの要件に準拠していることを確認する必要があります。ディクショナリーキーを並び替えると問題なく終了します。属性を持たない場合、APIC は、エントリーが ``children`` の前にあることを期待しているため、``attributes: {}`` を追加する必要があるかもしれません。" - -#: ../../rst/scenario_guides/guide_aci.rst:603 -msgid "APIC Error 801: property descr of uni/tn-TENANT/ap-AP failed validation for value 'A \"legacy\" network'" -msgstr "APIC Error 801: property descr of uni/tn-TENANT/ap-AP failed validation for value 'A \"legacy\" network'" - -#: ../../rst/scenario_guides/guide_aci.rst:602 -msgid "Some values in the APIC have strict format-rules to comply to, and the internal APIC validation check for the provided value failed. In the above case, the ``description`` parameter (internally known as ``descr``) only accepts values conforming to `Regex: [a-zA-Z0-9\\\\!#$%()*,-./:;@ _{|}~?&+]+ `_, in general it must not include quotes or square brackets." -msgstr "APIC 内の一部の値には準拠が必要な厳格な形式ルールがあり、提供される値に対する内部 APIC 検証チェックに失敗しました。上記のケースでは、``description`` パラメーター (内部的には``descr``) は、`Regex: [a-zA-Z0-9\\\\!#$%()*,-./:;@ _{|}~?&+]+ `_ に準拠した値のみを受け入れ、一般的には引用符や角括弧を含むことはできません。" - -#: ../../rst/scenario_guides/guide_aci.rst:608 -msgid "Known issues" -msgstr "既知の問題" - -#: ../../rst/scenario_guides/guide_aci.rst:609 -msgid "The aci_rest module is a wrapper around the APIC REST API. As a result any issues related to the APIC will be reflected in the use of this module." -msgstr "aci_rest モジュールは、APIC REST API のラッパーです。これにより、APIC に関連する問題がこのモジュールの使用に反映されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:611 -msgid "All below issues either have been reported to the vendor, and most can simply be avoided." -msgstr "以下の問題はすべてベンダー企業に報告されており、ほとんどの場合は回避できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:617 -msgid "Too many consecutive API calls may result in connection throttling" -msgstr "連続する API 呼び出しが多くなりすぎると、接続のスロットルが発生する可能性があります。" - -#: ../../rst/scenario_guides/guide_aci.rst:614 -msgid "Starting with ACI v3.1 the APIC will actively throttle password-based authenticated connection rates over a specific threshold. This is as part of an anti-DDOS measure but can act up when using Ansible with ACI using password-based authentication. Currently, one solution is to increase this threshold within the nginx configuration, but using signature-based authentication is recommended." -msgstr "ACI v3.1 以降、APIC は特定のしきい値で、パスワードベースの認証接続レートをアクティブにスロットルします。これは DDOS 対策の一環ですが、ACI でパスワードベースの認証で Ansible を使用している場合に問題が発生する可能性があります。現在のところ、nginx の設定でこのしきい値を増やすことで解決していますが、署名ベースの認証を使用することが推奨されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:616 -msgid "**NOTE:** It is advisable to use signature-based authentication with ACI as it not only prevents connection-throttling, but also improves general performance when using the ACI modules." -msgstr "**注記:** 接続スロットルを回避するだけでなく、ACI モジュールを使用する場合の全般的なパフォーマンスを向上させるため、ACI で署名ベースの認証を使用することが推奨されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:623 -msgid "Specific requests may not reflect changes correctly (`#35401 `_)" -msgstr "特定の要求には、変更が正しく反映されない場合があります (`#35401 `_)。" - -#: ../../rst/scenario_guides/guide_aci.rst:620 -msgid "There is a known issue where specific requests to the APIC do not properly reflect changed in the resulting output, even when we request those changes explicitly from the APIC. In one instance using the path ``api/node/mo/uni/infra.xml`` fails, where ``api/node/mo/uni/infra/.xml`` does work correctly." -msgstr "APIC に明示的に変更を要求しても、結果の出力に変更が正しく反映されないという問題がありました。ある例では、``api/node/mo/uni/infra.xml`` というパスを使用すると失敗しますが、``api/node/mo/uni/infra/.xml`` は正しく動作します。" - -#: ../../rst/scenario_guides/guide_aci.rst:622 -msgid "**NOTE:** A workaround is to register the task return values (for example, ``register: this``) and influence when the task should report a change by adding: ``changed_when: this.imdata != []``." -msgstr "**注記:** 回避策は、タスクの戻り値 (例: ``register: this``) を登録し、``changed_when: this.imdata != []`` を追加してタスクが変更を報告する場合に影響を及ぼすことです。" - -#: ../../rst/scenario_guides/guide_aci.rst:629 -msgid "Specific requests are known to not be idempotent (`#35050 `_)" -msgstr "特定のリクエストは冪等でないことが知られています (`#35050 `_)。" - -#: ../../rst/scenario_guides/guide_aci.rst:626 -msgid "The behaviour of the APIC is inconsistent to the use of ``status=\"created\"`` and ``status=\"deleted\"``. The result is that when you use ``status=\"created\"`` in your payload the resulting tasks are not idempotent and creation will fail when the object was already created. However this is not the case with ``status=\"deleted\"`` where such call to an non-existing object does not cause any failure whatsoever." -msgstr "APIC の動作は、``status=\"created\"`` および ``status=\"deleted\"`` の使用と矛盾しています。そのため、ペイロードで ``status=\"created\"`` を使用すると、作成されるタスクが冪等ではなく、オブジェクトがすでに作成されても作成に失敗します。しかし、``status=\"deleted\"`` の場合はそのようなことはなく、存在しないオブジェクトへの呼び出しでも何も失敗しません。" - -#: ../../rst/scenario_guides/guide_aci.rst:628 -msgid "**NOTE:** A workaround is to avoid using ``status=\"created\"`` and instead use ``status=\"modified\"`` when idempotency is essential to your workflow.." -msgstr "**注記:** ワークフローにおける冪等が必須である場合は、回避策として、``status=\"created\"`` を使用せず、``status=\"modified\"`` を使用してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:635 -msgid "Setting user password is not idempotent (`#35544 `_)" -msgstr "ユーザーパスワードの設定は冪等ではありません (`#35544 `_)" - -#: ../../rst/scenario_guides/guide_aci.rst:632 -msgid "Due to an inconsistency in the APIC REST API, a task that sets the password of a locally-authenticated user is not idempotent. The APIC will complain with message ``Password history check: user dag should not use previous 5 passwords``." -msgstr "APIC REST API の不整合により、ローカル認証されたユーザーのパスワードを設定するタスクは冪等ではありません。APIC は、``Password history check: user dag should not use previous 5 passwords`` メッセージを出力します。" - -#: ../../rst/scenario_guides/guide_aci.rst:634 -msgid "**NOTE:** There is no workaround for this issue." -msgstr "**注記:** この問題に対する回避策はありません。" - -#: ../../rst/scenario_guides/guide_aci.rst:640 -msgid "ACI Ansible community" -msgstr "ACI Ansible コミュニティー" - -#: ../../rst/scenario_guides/guide_aci.rst:641 -msgid "If you have specific issues with the ACI modules, or a feature request, or you like to contribute to the ACI project by proposing changes or documentation updates, look at the Ansible Community wiki ACI page at: https://github.com/ansible/community/wiki/Network:-ACI" -msgstr "ACI モジュールまたは機能要求に特定の問題が発生した場合や、変更やドキュメントの更新を提案して ACI プロジェクトに貢献する場合は、Ansible Community wiki の ACI ページ (https://github.com/ansible/community/wiki/Network:-ACI) を参照してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:643 -msgid "You will find our roadmap, an overview of open ACI issues and pull-requests, and more information about who we are. If you have an interest in using ACI with Ansible, feel free to join! We occasionally meet online to track progress and prepare for new Ansible releases." -msgstr "ロードマップ、オープンな ACI の問題およびプル要求の概要、ならびにこのコミュニティーに関する詳細情報を確認できます。ACI を Ansible で使用することを検討している場合は、お気軽にご参加ください。進捗状況を追跡し、新しい Ansible リリースの準備をするために、オンラインミーティングを行う場合もあります。" - -#: ../../rst/scenario_guides/guide_aci.rst:648 -msgid "`ACI collection on Ansible Galaxy `_" -msgstr "`ACI collection on Ansible Galaxy `_" - -#: ../../rst/scenario_guides/guide_aci.rst:649 -msgid "View the content tab for a complete list of supported ACI modules." -msgstr "サポートされている ACI モジュールの完全なリストは、コンテンツタブをご覧ください。" - -#: ../../rst/scenario_guides/guide_aci.rst:651 -msgid "A walkthrough on how to develop new Cisco ACI modules to contribute back." -msgstr "新しい Cisco ACI モジュールを開発して貢献する方法に関するウォークスルー" - -#: ../../rst/scenario_guides/guide_aci.rst:652 -msgid "`ACI community `_" -msgstr "`ACI community `_" - -#: ../../rst/scenario_guides/guide_aci.rst:653 -msgid "The Ansible ACI community wiki page, includes roadmap, ideas and development documentation." -msgstr "Ansible ACI コミュニティーの wiki ページ。ロードマップ、概念、および開発ドキュメントが含まれます。" - -#: ../../rst/scenario_guides/guide_aci.rst:654 -msgid ":ref:`network_guide`" -msgstr ":ref:`network_guide`" - -#: ../../rst/scenario_guides/guide_aci.rst:655 -msgid "A detailed guide on how to use Ansible for automating network infrastructure." -msgstr "ネットワークインフラストラクチャーの自動化に Ansible を使用する方法に関する詳細なガイドです。" - -#: ../../rst/scenario_guides/guide_aci.rst:656 -msgid "`Network Working Group `_" -msgstr "`Network Working Group `_" - -#: ../../rst/scenario_guides/guide_aci.rst:657 -msgid "The Ansible Network community page, includes contact information and meeting information." -msgstr "Ansible Network コミュニティーページ。連絡先情報およびミーティング情報が含まれます。" - -#: ../../rst/scenario_guides/guide_aci.rst:658 -msgid "`#ansible-network `_" -msgstr "`#ansible-network `_" - -#: ../../rst/scenario_guides/guide_aci.rst:659 -msgid "The #ansible-network IRC chat channel on Freenode.net." -msgstr "Freenode.net の IRC チャットチャンネル (#ansible-network)" - -#: ../../rst/scenario_guides/guide_aci.rst:660 -msgid "`User Mailing List `_" -msgstr "`ユーザーメーリングリスト `_" - -#: ../../rst/scenario_guides/guide_aci.rst:661 -#: ../../rst/scenario_guides/guide_aws.rst:279 -msgid "Have a question? Stop by the google group!" -msgstr "ご質問はございますか。Google Group をご覧ください。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:2 -msgid "Alibaba Cloud Compute Services Guide" -msgstr "Alibaba Cloud コンピュートサービスガイド" - -#: ../../rst/scenario_guides/guide_alicloud.rst:7 -#: ../../rst/scenario_guides/guide_aws.rst:7 -#: ../../rst/scenario_guides/guide_cloudstack.rst:7 -#: ../../rst/scenario_guides/guide_gce.rst:7 -#: ../../rst/scenario_guides/guide_online.rst:6 -#: ../../rst/scenario_guides/guide_oracle.rst:7 -#: ../../rst/scenario_guides/guide_packet.rst:6 -#: ../../rst/scenario_guides/guide_rax.rst:7 -#: ../../rst/scenario_guides/guide_scaleway.rst:10 -#: ../../rst/scenario_guides/guide_vagrant.rst:7 -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:11 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:11 -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:12 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:11 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:11 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:11 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:11 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:11 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:11 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:11 -msgid "Introduction" -msgstr "はじめに" - -#: ../../rst/scenario_guides/guide_alicloud.rst:9 -msgid "Ansible contains several modules for controlling and managing Alibaba Cloud Compute Services (Alicloud). This guide explains how to use the Alicloud Ansible modules together." -msgstr "Ansible には、Alibaba Cloud Compute Services (Alicloud) を制御および管理するためのモジュールが複数含まれています。Alicloud Ansible モジュールを一緒に使用する方法を説明します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:12 -msgid "All Alicloud modules require ``footmark`` - install it on your control machine with ``pip install footmark``." -msgstr "すべての Alicloud モジュールには ``footmark`` が必要です。これは、``pip install footmark`` で、コントロールマシンにインストールします。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:14 -msgid "Cloud modules, including Alicloud modules, execute on your local machine (the control machine) with ``connection: local``, rather than on remote machines defined in your hosts." -msgstr "Alicloud モジュールを含むクラウドモジュールは、ホストに定義されたリモートマシンではなく、ローカルマシン (コントロールマシン) で ``connection: local`` を使用して実行します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:16 -msgid "Normally, you'll use the following pattern for plays that provision Alicloud resources::" -msgstr "通常、Alicloud リソースをプロビジョニングするプレイには次のパターンを使用します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:28 -#: ../../rst/scenario_guides/guide_aws.rst:28 -#: ../../rst/scenario_guides/guide_vultr.rst:45 -msgid "Authentication" -msgstr "認証" - -#: ../../rst/scenario_guides/guide_alicloud.rst:30 -msgid "You can specify your Alicloud authentication credentials (access key and secret key) by passing them as environment variables or by storing them in a vars file." -msgstr "Alicloud の認証情報 (アクセスキーおよびシークレットキー) を指定するには、その認証情報を環境変数として渡すか、vars ファイルに保存します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:33 -msgid "To pass authentication credentials as environment variables::" -msgstr "環境変数として認証情報を渡すには、以下を実行します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:38 -msgid "To store authentication credentials in a vars_file, encrypt them with :ref:`Ansible Vault` to keep them secure, then list them::" -msgstr "認証情報を vars_file に保存するには、:ref:`Ansible Vault` で認証情報を暗号化してセキュアに維持してから、その認証情報の一覧を表示します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:44 -msgid "Note that if you store your credentials in a vars_file, you need to refer to them in each Alicloud module. For example::" -msgstr "認証情報を vars_file に保存する場合は、各 Alicloud モジュールで認証情報を参照する必要があることに注意してください。以下に例を示します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:54 -#: ../../rst/scenario_guides/guide_aws.rst:54 -#: ../../rst/scenario_guides/guide_rax.rst:86 -msgid "Provisioning" -msgstr "プロビジョニング" - -#: ../../rst/scenario_guides/guide_alicloud.rst:56 -msgid "Alicloud modules create Alicloud ECS instances, disks, virtual private clouds, virtual switches, security groups and other resources." -msgstr "Alicloud モジュールは、Alicloud ECS インスタンス、ディスク、仮想プライベートクラウド、仮想スイッチ、セキュリティーグループ、およびその他のリソースを作成します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:58 -msgid "You can use the ``count`` parameter to control the number of resources you create or terminate. For example, if you want exactly 5 instances tagged ``NewECS``, set the ``count`` of instances to 5 and the ``count_tag`` to ``NewECS``, as shown in the last task of the example playbook below. If there are no instances with the tag ``NewECS``, the task creates 5 new instances. If there are 2 instances with that tag, the task creates 3 more. If there are 8 instances with that tag, the task terminates 3 of those instances." -msgstr "``count`` パラメーターを使用して、作成または終了するリソースの数を制御することができます。たとえば、``NewECS`` とタグが付いたインスタンスが 5 つ必要な場合は、以下の Playbook の例の最後のタスクのように、インスタンスの ``count`` を 5 に、``count_tag`` を ``NewECS`` に、それぞれ設定します。タグが ``NewECS`` のインスタンスがない場合、タスクは 5 つの新規インスタンスを作成します。そのタグを持つインスタンスが 2 つある場合、このタスクはさらに 3 つのインスタンスを作成します。そのタグを持つ 8 つのインスタンスがある場合、タスクはそのインスタンスのうち 3 つを終了します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:63 -msgid "If you do not specify a ``count_tag``, the task creates the number of instances you specify in ``count`` with the ``instance_name`` you provide." -msgstr "``count_tag`` を指定しないと、タスクは、指定した ``instance_name`` で ``count`` に指定したインスタンスの数を作成します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:121 -msgid "In the example playbook above, data about the vpc, vswitch, group, and instances created by this playbook are saved in the variables defined by the \"register\" keyword in each task." -msgstr "上記のサンプル Playbook では、この Playbook で作成される vpc、vswitch、group、およびインスタンスに関するデータが、各タスクの「register」キーワードで定義される変数に保存されます。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:124 -msgid "Each Alicloud module offers a variety of parameter options. Not all options are demonstrated in the above example. See each individual module for further details and examples." -msgstr "各 Alicloud モジュールは、さまざまなパラメーターオプションを提供します。上記の例で、すべてのオプションが示されているわけではありません。詳細およびサンプルは、各モジュールを参照してください。" - -#: ../../rst/scenario_guides/guide_aws.rst:2 -msgid "Amazon Web Services Guide" -msgstr "Amazon Web Services ガイド" - -#: ../../rst/scenario_guides/guide_aws.rst:9 -msgid "Ansible contains a number of modules for controlling Amazon Web Services (AWS). The purpose of this section is to explain how to put Ansible modules together (and use inventory scripts) to use Ansible in AWS context." -msgstr "Ansible には、Amazon Web Services (AWS) を制御するモジュールが多数含まれています。このセクションの目的は、AWS のコンテキストで Ansible を使用するために、Ansible モジュールをどのように組み合わせるか (インベントリースクリプトを使用するか) を説明することです。" - -#: ../../rst/scenario_guides/guide_aws.rst:12 -msgid "Requirements for the AWS modules are minimal." -msgstr "AWS モジュールの要件は最小限です。" - -#: ../../rst/scenario_guides/guide_aws.rst:14 -msgid "All of the modules require and are tested against recent versions of boto, usually boto3. Check the module documentation for the minimum required version for each module. You must have the boto3 Python module installed on your control machine. You may also need the original boto package. You can install these modules from your OS distribution or using the python package installer: ``pip install boto3``." -msgstr "モジュールはすべて必要で、最新バージョンの boto、通常は boto3 に対してテストされています。各モジュールに必要な最小バージョンについては、そのモジュールのドキュメントを確認します。boto3 の Python モジュールをコントロールマシンにインストールする必要があります。元の boto パッケージもインストールする必要があります。これらのモジュールは、OS のディストリビューションからインストールするか、Python パッケージインストーラー ``pip install boto3`` を使用してインストールすることができます。" - -#: ../../rst/scenario_guides/guide_aws.rst:16 -msgid "Whereas classically Ansible will execute tasks in its host loop against multiple remote machines, most cloud-control steps occur on your local machine with reference to the regions to control." -msgstr "従来、Ansible はホストループ内のタスクを複数のリモートマシンに対して実行しますが、ほとんどのクラウド制御手順は、制御するリージョンを参照するローカルマシンで実行します。" - -#: ../../rst/scenario_guides/guide_aws.rst:18 -msgid "In your playbook steps we'll typically be using the following pattern for provisioning steps::" -msgstr "Playbook の手順では、通常、プロビジョニング手順に以下のパターンを使用します::" - -#: ../../rst/scenario_guides/guide_aws.rst:30 -msgid "Authentication with the AWS-related modules is handled by either specifying your access and secret key as ENV variables or module arguments." -msgstr "AWS 関連のモジュールを使用した認証は、ENV 変数またはモジュール引数としてアクセスおよび秘密鍵を指定することにより処理されます。" - -#: ../../rst/scenario_guides/guide_aws.rst:33 -msgid "For environment variables::" -msgstr "環境変数の場合::" - -#: ../../rst/scenario_guides/guide_aws.rst:38 -msgid "For storing these in a vars_file, ideally encrypted with ansible-vault::" -msgstr "vars_file に保存するには、ansible-vault で暗号化することが理想的です::" - -#: ../../rst/scenario_guides/guide_aws.rst:44 -msgid "Note that if you store your credentials in vars_file, you need to refer to them in each AWS-module. For example::" -msgstr "認証情報を vars_file に保存する場合は、各 AWS モジュールで認証情報を参照する必要があることに注意してください。以下に例を示します。" - -#: ../../rst/scenario_guides/guide_aws.rst:56 -msgid "The ec2 module provisions and de-provisions instances within EC2." -msgstr "ec2 モジュールは、EC2 内でインスタンスのプロビジョニングおよびプロビジョニング解除を行います。" - -#: ../../rst/scenario_guides/guide_aws.rst:58 -msgid "An example of making sure there are only 5 instances tagged 'Demo' in EC2 follows." -msgstr "EC2 で「Demo」とタグ付けされたインスタンスが 5 個になるようにする例を以下に示します。" - -#: ../../rst/scenario_guides/guide_aws.rst:60 -msgid "In the example below, the \"exact_count\" of instances is set to 5. This means if there are 0 instances already existing, then 5 new instances would be created. If there were 2 instances, only 3 would be created, and if there were 8 instances, 3 instances would be terminated." -msgstr "以下の例では、インスタンスの「exact_count」は 5 に設定されます。これは、インスタンスがない場合は、新規インスタンスが 5 個作成されることを示しています。インスタンスが 2 個ある場合は、3 個作成され、インスタンスが 8 個ある場合は、3 個のインスタンスが終了します。" - -#: ../../rst/scenario_guides/guide_aws.rst:64 -msgid "What is being counted is specified by the \"count_tag\" parameter. The parameter \"instance_tags\" is used to apply tags to the newly created instance.::" -msgstr "カウントされるものは「count_tag」パラメーターで指定します。「instance_tags」パラメーターは、新たに作成されたインスタンスをタグに適用するために使用されます。" - -#: ../../rst/scenario_guides/guide_aws.rst:88 -msgid "The data about what instances are created is being saved by the \"register\" keyword in the variable named \"ec2\"." -msgstr "作成されるインスタンスに関するデータは、「ec2」という変数の「register」キーワードによって保存されます。" - -#: ../../rst/scenario_guides/guide_aws.rst:90 -msgid "From this, we'll use the add_host module to dynamically create a host group consisting of these new instances. This facilitates performing configuration actions on the hosts immediately in a subsequent task.::" -msgstr "このモジュールから add_host モジュールを使用し、これらの新規インスタンスで構成されるホストグループを動的に作成します。これにより、後続のタスクで、ホストでの設定アクションをすぐに実行できます。" - -#: ../../rst/scenario_guides/guide_aws.rst:117 -msgid "With the host group now created, a second play at the bottom of the same provisioning playbook file might now have some configuration steps::" -msgstr "これでホストグループが作成されたので、同じプロビジョニング Playbook ファイルの下部にある2つ目のプレイでは、以下のような設定ステップが必要になります。" - -#: ../../rst/scenario_guides/guide_aws.rst:138 -msgid "Security Groups" -msgstr "セキュリティーグループ" - -#: ../../rst/scenario_guides/guide_aws.rst:140 -msgid "Security groups on AWS are stateful. The response of a request from your instance is allowed to flow in regardless of inbound security group rules and vice-versa. In case you only want allow traffic with AWS S3 service, you need to fetch the current IP ranges of AWS S3 for one region and apply them as an egress rule.::" -msgstr "AWS のセキュリティーグループはステートフルです。インスタンスからの要求の応答は、受信セキュリティーグループルールに関係なく流入が許可され、その逆も同様です。AWS S3 サービスを使用するトラフィックのみを許可する場合は、あるリージョンに対して AWS S3 の現在の IP 範囲を取得し、それを egress ルールとして適用する必要があります。" - -#: ../../rst/scenario_guides/guide_aws.rst:169 -#: ../../rst/scenario_guides/guide_rax.rst:155 -msgid "Host Inventory" -msgstr "ホストインベントリー" - -#: ../../rst/scenario_guides/guide_aws.rst:171 -msgid "Once your nodes are spun up, you'll probably want to talk to them again. With a cloud setup, it's best to not maintain a static list of cloud hostnames in text files. Rather, the best way to handle this is to use the aws_ec2 inventory plugin. See :ref:`dynamic_inventory`." -msgstr "ノードが起動したら、おそらく再通信するようにしたいでしょう。クラウド設定では、テキストファイルに、クラウドホスト名の静的リストを維持しないことが推奨されます。これを処理する最善の方法は、aws_ec2 インベントリープラグインを使用することです。:ref:`dynamic_inventory` を参照してください。" - -#: ../../rst/scenario_guides/guide_aws.rst:174 -msgid "The plugin will also return instances that were created outside of Ansible and allow Ansible to manage them." -msgstr "このプラグインにより、Ansible 外で作成されたインスタンスも選択され、Ansible がインスタンスを管理できるようになります。" - -#: ../../rst/scenario_guides/guide_aws.rst:179 -msgid "Tags And Groups And Variables" -msgstr "タグ、グループ、および変数" - -#: ../../rst/scenario_guides/guide_aws.rst:181 -msgid "When using the inventory plugin, you can configure extra inventory structure based on the metadata returned by AWS." -msgstr "インベントリープラグインを使用する場合は、AWS により返されるメタデータに基づいて追加のインベントリー構造を設定できます。" - -#: ../../rst/scenario_guides/guide_aws.rst:183 -msgid "For instance, you might use ``keyed_groups`` to create groups from instance tags::" -msgstr "たとえば、``keyed_groups`` を使用してインスタンスタグからグループを作成することができます。" - -#: ../../rst/scenario_guides/guide_aws.rst:191 -msgid "You can then target all instances with a \"class\" tag where the value is \"webserver\" in a play::" -msgstr "次に、「class」タグの付いたすべてのインスタンスをターゲットにすることができます。ここで、値はプレイ内の「webserver」になります。" - -#: ../../rst/scenario_guides/guide_aws.rst:197 -msgid "You can also use these groups with 'group_vars' to set variables that are automatically applied to matching instances. See :ref:`splitting_out_vars`." -msgstr "「group_vars」でこれらのグループを使用して、一致するインスタンスに自動的に適用される変数を設定することもできます。「:ref:`splitting_out_vars`」を参照してください。" - -#: ../../rst/scenario_guides/guide_aws.rst:202 -msgid "Autoscaling with Ansible Pull" -msgstr "Ansible Pull を使用した自動スケーリング" - -#: ../../rst/scenario_guides/guide_aws.rst:204 -msgid "Amazon Autoscaling features automatically increase or decrease capacity based on load. There are also Ansible modules shown in the cloud documentation that can configure autoscaling policy." -msgstr "Amazon Autoscaling 機能は、負荷に応じて容量を自動的に増減します。また、クラウドドキュメントで説明されるように、自動スケーリングポリシーを設定する Ansible モジュールがあります。" - -#: ../../rst/scenario_guides/guide_aws.rst:207 -msgid "When nodes come online, it may not be sufficient to wait for the next cycle of an ansible command to come along and configure that node." -msgstr "ノードがオンラインになると、ansible コマンドの次のサイクルが反映されてそのノードを設定するのを待つことができない可能性があります。" - -#: ../../rst/scenario_guides/guide_aws.rst:209 -msgid "To do this, pre-bake machine images which contain the necessary ansible-pull invocation. Ansible-pull is a command line tool that fetches a playbook from a git server and runs it locally." -msgstr "そのためには、必要な ansible-pull 呼び出しを含むマシンイメージを事前に作成します。ansible-pull は、git サーバーから Playbook を取得し、ローカルで実行するコマンドラインツールです。" - -#: ../../rst/scenario_guides/guide_aws.rst:211 -msgid "One of the challenges of this approach is that there needs to be a centralized way to store data about the results of pull commands in an autoscaling context. For this reason, the autoscaling solution provided below in the next section can be a better approach." -msgstr "このアプローチの課題の 1 つとして、pull コマンドの結果に関するデータを自動スケーリングコンテキストに保存する集中的な方法が必要になります。このため、次のセクションで提供される自動スケーリングソリューションの方が適切です。" - -#: ../../rst/scenario_guides/guide_aws.rst:214 -msgid "Read :ref:`ansible-pull` for more information on pull-mode playbooks." -msgstr "pull モードの Playbook の詳細は、「:ref:`ansible-pull`」を参照してください。" - -#: ../../rst/scenario_guides/guide_aws.rst:219 -msgid "Autoscaling with Ansible Tower" -msgstr "Ansible Tower を使用した自動スケーリング" - -#: ../../rst/scenario_guides/guide_aws.rst:221 -msgid ":ref:`ansible_tower` also contains a very nice feature for auto-scaling use cases. In this mode, a simple curl script can call a defined URL and the server will \"dial out\" to the requester and configure an instance that is spinning up. This can be a great way to reconfigure ephemeral nodes. See the Tower install and product documentation for more details." -msgstr "また、:ref:`ansible_tower` は、自動スケーリングのユースケースには非常に優れた機能も含まれています。このモードでは、簡単な curl スクリプトは定義された URL を呼び出すことができ、サーバーは要求元に対して「ダイヤルアウト」し、起動しているインスタンスを構成します。これは、一時ノードを再設定する優れた方法になります。詳細は、Tower のインストールと製品のドキュメントを参照してください。" - -#: ../../rst/scenario_guides/guide_aws.rst:225 -#: ../../rst/scenario_guides/guide_rax.rst:793 -msgid "A benefit of using the callback in Tower over pull mode is that job results are still centrally recorded and less information has to be shared with remote hosts." -msgstr "pull モードで Tower のコールバックを使用する利点は、ジョブの結果が引き続き中央で記録され、リモートホストと共有する必要のある情報が少なくなることです。" - -#: ../../rst/scenario_guides/guide_aws.rst:231 -msgid "Ansible With (And Versus) CloudFormation" -msgstr "CloudFormation を使用した Ansible (Ansible と CloudFormation の比較)" - -#: ../../rst/scenario_guides/guide_aws.rst:233 -msgid "CloudFormation is a Amazon technology for defining a cloud stack as a JSON or YAML document." -msgstr "CloudFormation は、クラウドスタックを JSON または YAML のドキュメントとして定義する Amazon テクノロジーです。" - -#: ../../rst/scenario_guides/guide_aws.rst:235 -msgid "Ansible modules provide an easier to use interface than CloudFormation in many examples, without defining a complex JSON/YAML document. This is recommended for most users." -msgstr "Ansible モジュールは、複雑な JSON/YAML ドキュメントを定義せずに、多くの例で CloudFormation よりも簡単にインターフェースを使用できます。これは、ほとんどのユーザーに推奨されます。" - -#: ../../rst/scenario_guides/guide_aws.rst:238 -msgid "However, for users that have decided to use CloudFormation, there is an Ansible module that can be used to apply a CloudFormation template to Amazon." -msgstr "ただし、CloudFormation を使用するユーザーには、CloudFormation テンプレートを Amazon に適用するのに使用できる Ansible モジュールがあります。" - -#: ../../rst/scenario_guides/guide_aws.rst:241 -msgid "When using Ansible with CloudFormation, typically Ansible will be used with a tool like Packer to build images, and CloudFormation will launch those images, or ansible will be invoked through user data once the image comes online, or a combination of the two." -msgstr "CloudFormation で Ansible を使用する場合は、通常、Ansible を Packer などのツールで使用してイメージを作成し、CloudFormation がそのイメージを起動するか、イメージがオンラインになると、ユーザーデータを通じて ansible が呼び出されるか、その組み合わせとなります。" - -#: ../../rst/scenario_guides/guide_aws.rst:244 -msgid "Please see the examples in the Ansible CloudFormation module for more details." -msgstr "詳細は、Ansible CloudFormation モジュールのサンプルを参照してください。" - -#: ../../rst/scenario_guides/guide_aws.rst:249 -msgid "AWS Image Building With Ansible" -msgstr "Ansible での AWS イメージの構築" - -#: ../../rst/scenario_guides/guide_aws.rst:251 -msgid "Many users may want to have images boot to a more complete configuration rather than configuring them entirely after instantiation. To do this, one of many programs can be used with Ansible playbooks to define and upload a base image, which will then get its own AMI ID for usage with the ec2 module or other Ansible AWS modules such as ec2_asg or the cloudformation module. Possible tools include Packer, aminator, and Ansible's ec2_ami module." -msgstr "多くの場合、インスタンス化後にイメージを完全に設定するのではなく、より完全な設定での起動を望みます。これを行うには、Ansible Playbook とともに多くのプログラムの中から 1 つ使用してベースイメージを定義し、アップロードできます。これにより、ec2 モジュール、ec2_asg モジュールや cloudformation モジュールなどのその他の Ansible AWS モジュールと使用するため、独自の AMI ID を取得します。ツールには Packer、aminator、および Ansible の ec2_ami モジュールが含まれます。" - -#: ../../rst/scenario_guides/guide_aws.rst:256 -msgid "Generally speaking, we find most users using Packer." -msgstr "一般的には、Packer が使用されます。" - -#: ../../rst/scenario_guides/guide_aws.rst:258 -msgid "See the Packer documentation of the `Ansible local Packer provisioner `_ and `Ansible remote Packer provisioner `_." -msgstr "`Ansible ローカル Packer プロビジョナー `_ および `Ansible リモート Packer プロビジョナー `_ の Packer ドキュメントを参照してください。" - -#: ../../rst/scenario_guides/guide_aws.rst:260 -msgid "If you do not want to adopt Packer at this time, configuring a base-image with Ansible after provisioning (as shown above) is acceptable." -msgstr "現時点では、Packer を使用しない場合は、プロビジョニング後に (上記のように) Ansible を使用したベースイメージの設定が可能です。" - -#: ../../rst/scenario_guides/guide_aws.rst:265 -msgid "Next Steps: Explore Modules" -msgstr "次のステップ: モジュールの検証" - -#: ../../rst/scenario_guides/guide_aws.rst:267 -msgid "Ansible ships with lots of modules for configuring a wide array of EC2 services. Browse the \"Cloud\" category of the module documentation for a full list with examples." -msgstr "Ansible には、さまざまな EC2 サービスを設定するモジュールが多数同梱されています。例を含む完全な一覧については、モジュールドキュメントの「クラウド」カテゴリーを参照してください。" - -#: ../../rst/scenario_guides/guide_aws.rst:272 -msgid ":ref:`list_of_collections`" -msgstr ":ref:`list_of_collections`" - -#: ../../rst/scenario_guides/guide_aws.rst:273 -msgid "Browse existing collections, modules, and plugins" -msgstr "既存のコレクション、モジュール、およびプラグインの閲覧" - -#: ../../rst/scenario_guides/guide_aws.rst:274 -#: ../../rst/scenario_guides/guide_vagrant.rst:135 -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:92 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:87 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:52 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:88 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:213 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:125 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1181 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/scenario_guides/guide_aws.rst:275 -#: ../../rst/scenario_guides/guide_vagrant.rst:136 -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:93 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:88 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:53 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:89 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:214 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:126 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1182 -msgid "An introduction to playbooks" -msgstr "Playbook の概要" - -#: ../../rst/scenario_guides/guide_aws.rst:276 -msgid ":ref:`playbooks_delegation`" -msgstr ":ref:`playbooks_delegation`" - -#: ../../rst/scenario_guides/guide_aws.rst:277 -msgid "Delegation, useful for working with loud balancers, clouds, and locally executed steps." -msgstr "委譲 (ロードバランサー、クラウド、ローカルで実行した手順を使用する際に役に立ちます)" - -#: ../../rst/scenario_guides/guide_aws.rst:278 -msgid "`User Mailing List `_" -msgstr "`ユーザーメーリングリスト `_" - -#: ../../rst/scenario_guides/guide_aws.rst:280 -msgid "`irc.freenode.net `_" -msgstr "`irc.freenode.net `_" - -#: ../../rst/scenario_guides/guide_aws.rst:281 -msgid "#ansible IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible)" - -#: ../../rst/scenario_guides/guide_azure.rst:2 -msgid "Microsoft Azure Guide" -msgstr "Microsoft Azure ガイド" - -#: ../../rst/scenario_guides/guide_azure.rst:4 -msgid "Ansible includes a suite of modules for interacting with Azure Resource Manager, giving you the tools to easily create and orchestrate infrastructure on the Microsoft Azure Cloud." -msgstr "Ansible には、Azure Resource Manager と対話するためのモジュールのスイートが含まれており、簡単に作成し、Microsoft Azure Cloud 上のインフラストラクチャーを調整するツールを提供します。" - -#: ../../rst/scenario_guides/guide_azure.rst:8 -#: ../../rst/scenario_guides/guide_docker.rst:12 -#: ../../rst/scenario_guides/guide_oracle.rst:13 -#: ../../rst/scenario_guides/guide_packet.rst:16 -#: ../../rst/scenario_guides/guide_scaleway.rst:26 -#: ../../rst/scenario_guides/guide_vultr.rst:10 -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:16 -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:17 -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:12 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:17 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:18 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:19 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:19 -msgid "Requirements" -msgstr "要件" - -#: ../../rst/scenario_guides/guide_azure.rst:10 -msgid "Using the Azure Resource Manager modules requires having specific Azure SDK modules installed on the host running Ansible." -msgstr "Azure Resource Manager モジュールを使用するには、Ansible を実行しているホストに特定の Azure SDK モジュールをインストールする必要があります。" - -#: ../../rst/scenario_guides/guide_azure.rst:17 -msgid "If you are running Ansible from source, you can install the dependencies from the root directory of the Ansible repo." -msgstr "ソースから Ansible を実行している場合は、Ansible リポジトリーの root ディレクトリーから依存関係をインストールできます。" - -#: ../../rst/scenario_guides/guide_azure.rst:24 -msgid "You can also directly run Ansible in `Azure Cloud Shell `_, where Ansible is pre-installed." -msgstr "また、Ansible が事前にインストールされている `Azure Cloud Shell `_ で Ansible を直接実行することもできます。" - -#: ../../rst/scenario_guides/guide_azure.rst:27 -msgid "Authenticating with Azure" -msgstr "API での認証" - -#: ../../rst/scenario_guides/guide_azure.rst:29 -msgid "Using the Azure Resource Manager modules requires authenticating with the Azure API. You can choose from two authentication strategies:" -msgstr "Azure Resource Manager モジュールを使用するには、Azure API で認証する必要があります。以下の認証ストラテジーを選択できます。" - -#: ../../rst/scenario_guides/guide_azure.rst:31 -msgid "Active Directory Username/Password" -msgstr "Active Directory ユーザー名/パスワード" - -#: ../../rst/scenario_guides/guide_azure.rst:32 -msgid "Service Principal Credentials" -msgstr "サービスプリンシパルの認証情報" - -#: ../../rst/scenario_guides/guide_azure.rst:34 -msgid "Follow the directions for the strategy you wish to use, then proceed to `Providing Credentials to Azure Modules`_ for instructions on how to actually use the modules and authenticate with the Azure API." -msgstr "使用するストラテジーの指示に従い、実際にモジュールを使用して Azure API で認証する方法は、「`Azure モジュールへの認証情報の提供`_」を参照してください。" - -#: ../../rst/scenario_guides/guide_azure.rst:39 -msgid "Using Service Principal" -msgstr "サービスプリンシパルの使用" - -#: ../../rst/scenario_guides/guide_azure.rst:41 -msgid "There is now a detailed official tutorial describing `how to create a service principal `_." -msgstr "「`サービスプリンシパルの作成方法 `_」を説明する詳細な公式チュートリアルがあります。" - -#: ../../rst/scenario_guides/guide_azure.rst:43 -msgid "After stepping through the tutorial you will have:" -msgstr "チュートリアルを実行すると、以下が可能になります。" - -#: ../../rst/scenario_guides/guide_azure.rst:45 -msgid "Your Client ID, which is found in the \"client id\" box in the \"Configure\" page of your application in the Azure portal" -msgstr "Azure ポータルのアプリケーションの「設定」ページの「クライアント ID」ボックスにあるクライアント ID。" - -#: ../../rst/scenario_guides/guide_azure.rst:46 -msgid "Your Secret key, generated when you created the application. You cannot show the key after creation. If you lost the key, you must create a new one in the \"Configure\" page of your application." -msgstr "シークレットキーは、アプリケーションの作成時に生成されます。キーが紛失した場合は、アプリケーションの「設定」ページで新しいキーを作成する必要があります。" - -#: ../../rst/scenario_guides/guide_azure.rst:48 -msgid "And finally, a tenant ID. It's a UUID (for example, ABCDEFGH-1234-ABCD-1234-ABCDEFGHIJKL) pointing to the AD containing your application. You will find it in the URL from within the Azure portal, or in the \"view endpoints\" of any given URL." -msgstr "そして最後に、テナント ID です。これは、アプリケーションを含む AD を指し示す UUID (例: ABCDEFGH-1234-ABCD-1234-ABCDEFGHIJKL) です。この ID は、Azure ポータル内の URL や、指定の URL の「エンドポイントの表示」に記載されています。" - -#: ../../rst/scenario_guides/guide_azure.rst:53 -msgid "Using Active Directory Username/Password" -msgstr "Active Directory のユーザー名/パスワードの使用" - -#: ../../rst/scenario_guides/guide_azure.rst:55 -msgid "To create an Active Directory username/password:" -msgstr "Active Directory のユーザー名/パスワードを作成するには、以下を行います。" - -#: ../../rst/scenario_guides/guide_azure.rst:57 -msgid "Connect to the Azure Classic Portal with your admin account" -msgstr "管理者アカウントを使用して Azure Classic Portal に接続します。" - -#: ../../rst/scenario_guides/guide_azure.rst:58 -msgid "Create a user in your default AAD. You must NOT activate Multi-Factor Authentication" -msgstr "デフォルトの AAD でユーザーを作成します。マルチファクター認証をアクティブにしないでください。" - -#: ../../rst/scenario_guides/guide_azure.rst:59 -msgid "Go to Settings - Administrators" -msgstr "Settings、Administrator の順に移動します。" - -#: ../../rst/scenario_guides/guide_azure.rst:60 -msgid "Click on Add and enter the email of the new user." -msgstr "Add をクリックして、新規ユーザーの電子メールを入力します。" - -#: ../../rst/scenario_guides/guide_azure.rst:61 -msgid "Check the checkbox of the subscription you want to test with this user." -msgstr "このユーザーでテストするサブスクリプションのチェックボックスを選択します。" - -#: ../../rst/scenario_guides/guide_azure.rst:62 -msgid "Login to Azure Portal with this new user to change the temporary password to a new one. You will not be able to use the temporary password for OAuth login." -msgstr "この新規ユーザーで Azure Portal にログインし、一時パスワードを新規パスワードに変更します。OAuth ログインに、一時パスワードを使用することはできません。" - -#: ../../rst/scenario_guides/guide_azure.rst:66 -msgid "Providing Credentials to Azure Modules" -msgstr "Azure モジュールへの認証情報の提供" - -#: ../../rst/scenario_guides/guide_azure.rst:68 -msgid "The modules offer several ways to provide your credentials. For a CI/CD tool such as Ansible Tower or Jenkins, you will most likely want to use environment variables. For local development you may wish to store your credentials in a file within your home directory. And of course, you can always pass credentials as parameters to a task within a playbook. The order of precedence is parameters, then environment variables, and finally a file found in your home directory." -msgstr "モジュールには、認証情報を提供するいくつかの方法があります。Ansible Tower や Jenkins のような CI/CD ツールでは、環境変数を使用することが多いでしょう。ローカルでの開発では、ホームディレクトリー内のファイルに認証情報を保存することができます。認証情報はパラメーターとして Playbook 内のタスクに渡すこともできます。優先される順序は、パラメーター、環境変数、および最後にホームディレクトリーにあるファイルになります。" - -#: ../../rst/scenario_guides/guide_azure.rst:74 -msgid "Using Environment Variables" -msgstr "追加の環境変数" - -#: ../../rst/scenario_guides/guide_azure.rst:76 -msgid "To pass service principal credentials via the environment, define the following variables:" -msgstr "環境経由でサービスプリンシパルの認証情報を渡すには、以下の変数を定義します。" - -#: ../../rst/scenario_guides/guide_azure.rst:78 -#: ../../rst/scenario_guides/guide_azure.rst:93 -msgid "AZURE_CLIENT_ID" -msgstr "AZURE_CLIENT_ID" - -#: ../../rst/scenario_guides/guide_azure.rst:79 -msgid "AZURE_SECRET" -msgstr "AZURE_SECRET" - -#: ../../rst/scenario_guides/guide_azure.rst:80 -#: ../../rst/scenario_guides/guide_azure.rst:87 -msgid "AZURE_SUBSCRIPTION_ID" -msgstr "AZURE_SUBSCRIPTION_ID" - -#: ../../rst/scenario_guides/guide_azure.rst:81 -#: ../../rst/scenario_guides/guide_azure.rst:94 -msgid "AZURE_TENANT" -msgstr "AZURE_TENANT" - -#: ../../rst/scenario_guides/guide_azure.rst:83 -msgid "To pass Active Directory username/password via the environment, define the following variables:" -msgstr "環境経由で Active Directory のユーザー名/パスワードのペアを渡すには、以下の変数を定義します。" - -#: ../../rst/scenario_guides/guide_azure.rst:85 -#: ../../rst/scenario_guides/guide_azure.rst:91 -msgid "AZURE_AD_USER" -msgstr "AZURE_AD_USER" - -#: ../../rst/scenario_guides/guide_azure.rst:86 -#: ../../rst/scenario_guides/guide_azure.rst:92 -msgid "AZURE_PASSWORD" -msgstr "AZURE_PASSWORD" - -#: ../../rst/scenario_guides/guide_azure.rst:89 -msgid "To pass Active Directory username/password in ADFS via the environment, define the following variables:" -msgstr "環境経由で Active Directory のユーザー名/パスワードを渡すには、以下の変数を定義します。" - -#: ../../rst/scenario_guides/guide_azure.rst:95 -msgid "AZURE_ADFS_AUTHORITY_URL" -msgstr "AZURE_ADFS_AUTHORITY_URL" - -#: ../../rst/scenario_guides/guide_azure.rst:97 -msgid "\"AZURE_ADFS_AUTHORITY_URL\" is optional. It's necessary only when you have own ADFS authority like https://yourdomain.com/adfs." -msgstr "「AZURE_ADFS_AUTHORITY_URL」は任意です。これは、https://yourdomain.com/adfs といった独自の認証機関がある場合にのみ必要です。" - -#: ../../rst/scenario_guides/guide_azure.rst:100 -msgid "Storing in a File" -msgstr "ファイルへの保存" - -#: ../../rst/scenario_guides/guide_azure.rst:102 -msgid "When working in a development environment, it may be desirable to store credentials in a file. The modules will look for credentials in ``$HOME/.azure/credentials``. This file is an ini style file. It will look as follows:" -msgstr "開発環境で作業する場合は、ファイルに認証情報を保存することが望ましい場合があります。このモジュールは ``$HOME/.azure/credentials`` にある認証情報を探します。このファイルは ini 形式のファイルです。以下のようになります。" - -#: ../../rst/scenario_guides/guide_azure.rst:113 -msgid "If your secret values contain non-ASCII characters, you must `URL Encode `_ them to avoid login errors." -msgstr "シークレット値に ASCII 以外の文字が含まれる場合は、ログインエラーを回避するために `URL エンコード `_ を行う必要があります。" - -#: ../../rst/scenario_guides/guide_azure.rst:115 -msgid "It is possible to store multiple sets of credentials within the credentials file by creating multiple sections. Each section is considered a profile. The modules look for the [default] profile automatically. Define AZURE_PROFILE in the environment or pass a profile parameter to specify a specific profile." -msgstr "複数のセクションを作成することで、認証情報ファイルに複数の認証情報を保存することができます。各セクションはプロファイルとみなされます。モジュールは [default] プロファイルを自動的に検索します。環境内で AZURE_PROFILE を定義するか、特定のプロファイルを指定するために profile パラメーターを渡すことができます。" - -#: ../../rst/scenario_guides/guide_azure.rst:120 -msgid "Passing as Parameters" -msgstr "パラメーターとして渡す" - -#: ../../rst/scenario_guides/guide_azure.rst:122 -msgid "If you wish to pass credentials as parameters to a task, use the following parameters for service principal:" -msgstr "認証情報をパラメーターとしてタスクに渡すには、サービスプリンシパルについて以下のパラメーターを使用します。" - -#: ../../rst/scenario_guides/guide_azure.rst:124 -#: ../../rst/scenario_guides/guide_azure.rst:139 -msgid "client_id" -msgstr "client_id" - -#: ../../rst/scenario_guides/guide_azure.rst:125 -msgid "secret" -msgstr "secret" - -#: ../../rst/scenario_guides/guide_azure.rst:126 -#: ../../rst/scenario_guides/guide_azure.rst:133 -msgid "subscription_id" -msgstr "subscription_id" - -#: ../../rst/scenario_guides/guide_azure.rst:127 -#: ../../rst/scenario_guides/guide_azure.rst:140 -msgid "tenant" -msgstr "tenant" - -#: ../../rst/scenario_guides/guide_azure.rst:129 -msgid "Or, pass the following parameters for Active Directory username/password:" -msgstr "または、Active Directory のユーザー名/パスワードについて以下のパラメーターを渡します。" - -#: ../../rst/scenario_guides/guide_azure.rst:131 -#: ../../rst/scenario_guides/guide_azure.rst:137 -msgid "ad_user" -msgstr "ad_user" - -#: ../../rst/scenario_guides/guide_azure.rst:135 -msgid "Or, pass the following parameters for ADFS username/password:" -msgstr "または、以下のパラメーターを ADFS ユーザー名またはパスワードに渡します。" - -#: ../../rst/scenario_guides/guide_azure.rst:141 -msgid "adfs_authority_url" -msgstr "adfs_authority_url" - -#: ../../rst/scenario_guides/guide_azure.rst:143 -msgid "\"adfs_authority_url\" is optional. It's necessary only when you have own ADFS authority like https://yourdomain.com/adfs." -msgstr "「adfs_authority_url」は任意です。これは、https://yourdomain.com/adfs といった独自の認証機関がある場合に限り必要です。" - -#: ../../rst/scenario_guides/guide_azure.rst:147 -msgid "Other Cloud Environments" -msgstr "その他のクラウド環境" - -#: ../../rst/scenario_guides/guide_azure.rst:149 -msgid "To use an Azure Cloud other than the default public cloud (for example, Azure China Cloud, Azure US Government Cloud, Azure Stack), pass the \"cloud_environment\" argument to modules, configure it in a credential profile, or set the \"AZURE_CLOUD_ENVIRONMENT\" environment variable. The value is either a cloud name as defined by the Azure Python SDK (for example, \"AzureChinaCloud\", \"AzureUSGovernment\"; defaults to \"AzureCloud\") or an Azure metadata discovery URL (for Azure Stack)." -msgstr "デフォルトのパブリッククラウド (Azure China Cloud、Azure US Government Cloud、Azure US Government Cloud、Azure Stack など) 以外の Azure Cloud を使用するには、「cloud_environment」引数をモジュールに渡すか、認証情報プロファイルでこれを設定するか、「AZURE_CLOUD_ENVIRONMENT」環境変数を設定します。この値は、Azure Python SDK で定義されるクラウド名 (例:「AzureChinaCloud」、「AzureUSGovernment」。デフォルトは「AzureCloud」) または Azure メタデータ検出 URL (Azure Stack 用) のいずれかになります。" - -#: ../../rst/scenario_guides/guide_azure.rst:155 -msgid "Creating Virtual Machines" -msgstr "仮想マシンの作成" - -#: ../../rst/scenario_guides/guide_azure.rst:157 -msgid "There are two ways to create a virtual machine, both involving the azure_rm_virtualmachine module. We can either create a storage account, network interface, security group and public IP address and pass the names of these objects to the module as parameters, or we can let the module do the work for us and accept the defaults it chooses." -msgstr "azure_rm_virtualmachine モジュールに関連する仮想マシンを作成する方法は 2 つあります。ストレージアカウント、ネットワークインターフェース、セキュリティーグループ、パブリック IP アドレスを作成し、これらのオブジェクトの名前をパラメーターとしてモジュールに渡す方法と、モジュールに作業を任せ、モジュールが選択するデフォルトを受け入れる方法です。" - -#: ../../rst/scenario_guides/guide_azure.rst:162 -msgid "Creating Individual Components" -msgstr "個別コンポーネントの作成" - -#: ../../rst/scenario_guides/guide_azure.rst:164 -msgid "An Azure module is available to help you create a storage account, virtual network, subnet, network interface, security group and public IP. Here is a full example of creating each of these and passing the names to the ``azure.azcollection.azure_rm_virtualmachine`` module at the end:" -msgstr "Azure モジュールは、ストレージアカウント、仮想ネットワーク、サブネット、ネットワークインターフェース、セキュリティーグループ、およびパブリック IP の作成に役立ちます。ここでは、これらを作成し、最後に ``azure.azcollection.azure_rm_virtualmachine`` モジュールに名前を渡すための完全な例を紹介します。" - -#: ../../rst/scenario_guides/guide_azure.rst:233 -msgid "Each of the Azure modules offers a variety of parameter options. Not all options are demonstrated in the above example. See each individual module for further details and examples." -msgstr "Azure の各モジュールは、さまざまなパラメーターオプションを提供します。上記の例で、すべてのオプションが示されているわけではありません。詳細およびサンプルは、各モジュールを参照してください。" - -#: ../../rst/scenario_guides/guide_azure.rst:238 -msgid "Creating a Virtual Machine with Default Options" -msgstr "デフォルトオプションを使用した仮想マシンの作成" - -#: ../../rst/scenario_guides/guide_azure.rst:240 -msgid "If you simply want to create a virtual machine without specifying all the details, you can do that as well. The only caveat is that you will need a virtual network with one subnet already in your resource group. Assuming you have a virtual network already with an existing subnet, you can run the following to create a VM:" -msgstr "すべての詳細を指定せずに仮想マシンを作成する場合は、これも実行できます。唯一の注意点は、リソースグループ内に 1 つのサブネットを持つ仮想ネットワークが必要となることです。既存サブネットを使用する仮想ネットワークが既にある場合は、以下のように実行して仮想マシンを作成できます。" - -#: ../../rst/scenario_guides/guide_azure.rst:261 -msgid "Creating a Virtual Machine in Availability Zones" -msgstr "アベイラビリティーゾーンでの仮想マシンの作成" - -#: ../../rst/scenario_guides/guide_azure.rst:263 -msgid "If you want to create a VM in an availability zone, consider the following:" -msgstr "アベイラビリティーゾーンに仮想マシンを作成する場合は、以下を検討してください。" - -#: ../../rst/scenario_guides/guide_azure.rst:266 -msgid "Both OS disk and data disk must be a 'managed disk', not an 'unmanaged disk'." -msgstr "OS ディスクとデータディスクはいずれも「非管理ディスク」ではなく、「管理ディスク」である必要があります。" - -#: ../../rst/scenario_guides/guide_azure.rst:267 -msgid "When creating a VM with the ``azure.azcollection.azure_rm_virtualmachine`` module, you need to explicitly set the ``managed_disk_type`` parameter to change the OS disk to a managed disk. Otherwise, the OS disk becomes an unmanaged disk." -msgstr "``azure.azcollection.azure_rm_virtualmachine`` モジュールで仮想マシンを作成する場合は、``managed_disk_type`` パラメーターを明示的に設定して OS ディスクを管理ディスクに変更します。そうでないと、OS ディスクは非管理ディスクになります。" - -#: ../../rst/scenario_guides/guide_azure.rst:271 -msgid "When you create a data disk with the ``azure.azcollection.azure_rm_manageddisk`` module, you need to explicitly specify the ``storage_account_type`` parameter to make it a managed disk. Otherwise, the data disk will be an unmanaged disk." -msgstr "``azure.azcollection.azure_rm_manageddisk`` モジュールでデータディスクを作成する場合は、``storage_account_type`` パラメーターを明示的に指定して管理ディスクを作成する必要があります。そうでないと、データディスクは非管理ディスクになります。" - -#: ../../rst/scenario_guides/guide_azure.rst:275 -msgid "A managed disk does not require a storage account or a storage container, unlike an unmanaged disk. In particular, note that once a VM is created on an unmanaged disk, an unnecessary storage container named \"vhds\" is automatically created." -msgstr "管理ディスクは、非管理ディスクと異なり、ストレージアカウントやストレージコンテナーを必要としません。特に、非管理ディスクに仮想マシン作成すると、「vhds」という名前の不要なストレージコンテナーが自動的に作成されることに注意してください。" - -#: ../../rst/scenario_guides/guide_azure.rst:279 -msgid "When you create an IP address with the ``azure.azcollection.azure_rm_publicipaddress`` module, you must set the ``sku`` parameter to ``standard``. Otherwise, the IP address cannot be used in an availability zone." -msgstr "``azure.azcollection.azure_rm_publicipaddress`` モジュールで IP アドレスを作成する場合は、``sku`` パラメーターを ``standard`` に設定する必要があります。そうでない場合は、アベイラビリティーゾーンで IP アドレスを使用することができません。" - -#: ../../rst/scenario_guides/guide_azure.rst:285 -#: ../../rst/scenario_guides/guide_packet.rst:207 -#: ../../rst/scenario_guides/guide_scaleway.rst:170 -msgid "Dynamic Inventory Script" -msgstr "動的インベントリースクリプト" - -#: ../../rst/scenario_guides/guide_azure.rst:287 -msgid "If you are not familiar with Ansible's dynamic inventory scripts, check out :ref:`Intro to Dynamic Inventory `." -msgstr "Ansible の動的インベントリースクリプトに慣れていない場合は、「:ref:`動的インベントリーの概要 `」を参照してください。" - -#: ../../rst/scenario_guides/guide_azure.rst:289 -msgid "The Azure Resource Manager inventory script is called `azure_rm.py `_. It authenticates with the Azure API exactly the same as the Azure modules, which means you will either define the same environment variables described above in `Using Environment Variables`_, create a ``$HOME/.azure/credentials`` file (also described above in `Storing in a File`_), or pass command line parameters. To see available command line options execute the following:" -msgstr "Azure Resource Manager インベントリースクリプトは `azure_rm.py `_ と呼ばれます。Azure API での認証は Azure モジュールと同じになります。つまり、「`環境変数の使用`_」で説明されている環境変数と同じ環境変数を定義するか、``$HOME/.azure/credentials`` ファイルを作成するか (「`ファイルの保存`_」を参照)、またはコマンドラインパラメーターを渡します。利用可能なコマンドラインオプションを表示するには、以下のコマンドを実行します。" - -#: ../../rst/scenario_guides/guide_azure.rst:299 -msgid "As with all dynamic inventory scripts, the script can be executed directly, passed as a parameter to the ansible command, or passed directly to ansible-playbook using the -i option. No matter how it is executed the script produces JSON representing all of the hosts found in your Azure subscription. You can narrow this down to just hosts found in a specific set of Azure resource groups, or even down to a specific host." -msgstr "すべての動的インベントリースクリプトと同様に、このスクリプトは直接実行することも、ansible コマンドのパラメータとして渡すことも、-i オプションを使用して ansible-playbook に直接渡すこともできます。どのように実行しても、スクリプトは、Azure サブスクリプションで見つかったすべてのホストを表す JSON を生成します。これを、特定の Azure リソースグループのセットで見つかったホストだけに絞り込んだり、特定のホストに絞り込んだりすることができます。" - -#: ../../rst/scenario_guides/guide_azure.rst:304 -msgid "For a given host, the inventory script provides the following host variables:" -msgstr "インベントリースクリプトは、指定のホストに対して以下のホスト変数を提供します。" - -#: ../../rst/scenario_guides/guide_azure.rst:350 -msgid "Host Groups" -msgstr "ホストグループ" - -#: ../../rst/scenario_guides/guide_azure.rst:352 -msgid "By default hosts are grouped by:" -msgstr "デフォルトでは、ホストは以下のようにグループ化されます。" - -#: ../../rst/scenario_guides/guide_azure.rst:354 -msgid "azure (all hosts)" -msgstr "azure (全ホスト)" - -#: ../../rst/scenario_guides/guide_azure.rst:355 -msgid "location name" -msgstr "location name" - -#: ../../rst/scenario_guides/guide_azure.rst:356 -msgid "resource group name" -msgstr "resource group name" - -#: ../../rst/scenario_guides/guide_azure.rst:357 -msgid "security group name" -msgstr "security group name" - -#: ../../rst/scenario_guides/guide_azure.rst:358 -msgid "tag key" -msgstr "tag key" - -#: ../../rst/scenario_guides/guide_azure.rst:359 -msgid "tag key_value" -msgstr "tag key_value" - -#: ../../rst/scenario_guides/guide_azure.rst:360 -msgid "os_disk operating_system_type (Windows/Linux)" -msgstr "os_disk operating_system_type (Windows/Linux)" - -#: ../../rst/scenario_guides/guide_azure.rst:362 -msgid "You can control host groupings and host selection by either defining environment variables or creating an azure_rm.ini file in your current working directory." -msgstr "環境変数を定義するか、現在の作業ディレクトリーに azure_rm.ini ファイルを作成して、ホストのグループ化とホストの選択を制御できます。" - -#: ../../rst/scenario_guides/guide_azure.rst:365 -msgid "NOTE: An .ini file will take precedence over environment variables." -msgstr "注記: .ini ファイルは環境変数よりも優先されます。" - -#: ../../rst/scenario_guides/guide_azure.rst:367 -msgid "NOTE: The name of the .ini file is the basename of the inventory script (in other words, 'azure_rm') with a '.ini' extension. This allows you to copy, rename and customize the inventory script and have matching .ini files all in the same directory." -msgstr "注記: .ini ファイルの名前は、「.ini」拡張子が付いたインベントリースクリプトのベース名 (つまり「azure_rm」) です。これにより、インベントリースクリプトのコピー、名前変更、カスタマイズが可能となり、すべて同じディレクトリー内の .ini ファイルが一致します。" - -#: ../../rst/scenario_guides/guide_azure.rst:371 -msgid "Control grouping using the following variables defined in the environment:" -msgstr "環境で定義された以下の変数を使用してグループ化を制御します。" - -#: ../../rst/scenario_guides/guide_azure.rst:373 -msgid "AZURE_GROUP_BY_RESOURCE_GROUP=yes" -msgstr "AZURE_GROUP_BY_RESOURCE_GROUP=yes" - -#: ../../rst/scenario_guides/guide_azure.rst:374 -msgid "AZURE_GROUP_BY_LOCATION=yes" -msgstr "AZURE_GROUP_BY_LOCATION=yes" - -#: ../../rst/scenario_guides/guide_azure.rst:375 -msgid "AZURE_GROUP_BY_SECURITY_GROUP=yes" -msgstr "AZURE_GROUP_BY_SECURITY_GROUP=yes" - -#: ../../rst/scenario_guides/guide_azure.rst:376 -msgid "AZURE_GROUP_BY_TAG=yes" -msgstr "AZURE_GROUP_BY_TAG=yes" - -#: ../../rst/scenario_guides/guide_azure.rst:377 -msgid "AZURE_GROUP_BY_OS_FAMILY=yes" -msgstr "AZURE_GROUP_BY_OS_FAMILY=yes" - -#: ../../rst/scenario_guides/guide_azure.rst:379 -msgid "Select hosts within specific resource groups by assigning a comma separated list to:" -msgstr "コンマ区切りリストを以下に割り当てて、特定のリソースグループ内のホストを選択します。" - -#: ../../rst/scenario_guides/guide_azure.rst:381 -msgid "AZURE_RESOURCE_GROUPS=resource_group_a,resource_group_b" -msgstr "AZURE_RESOURCE_GROUPS=resource_group_a,resource_group_b" - -#: ../../rst/scenario_guides/guide_azure.rst:383 -msgid "Select hosts for specific tag key by assigning a comma separated list of tag keys to:" -msgstr "タグキーのコンマ区切りリストを以下に割り当てて、特定のタグキーのホストを選択します。" - -#: ../../rst/scenario_guides/guide_azure.rst:385 -msgid "AZURE_TAGS=key1,key2,key3" -msgstr "AZURE_TAGS=key1,key2,key3" - -#: ../../rst/scenario_guides/guide_azure.rst:387 -msgid "Select hosts for specific locations by assigning a comma separated list of locations to:" -msgstr "場所のコンマ区切りリストを割り当てて、特定の場所のホストを選択します。" - -#: ../../rst/scenario_guides/guide_azure.rst:389 -msgid "AZURE_LOCATIONS=eastus,eastus2,westus" -msgstr "AZURE_LOCATIONS=eastus,eastus2,westus" - -#: ../../rst/scenario_guides/guide_azure.rst:391 -msgid "Or, select hosts for specific tag key:value pairs by assigning a comma separated list key:value pairs to:" -msgstr "または、コンマ区切りリストの key:value ペアを以下に割り当てることで、特定のタグ key:value ペアのホストを選択します。" - -#: ../../rst/scenario_guides/guide_azure.rst:393 -msgid "AZURE_TAGS=key1:value1,key2:value2" -msgstr "AZURE_TAGS=key1:value1,key2:value2" - -#: ../../rst/scenario_guides/guide_azure.rst:395 -msgid "If you don't need the powerstate, you can improve performance by turning off powerstate fetching:" -msgstr "電力状態が必要ない場合は、powerstate 取得をオフにすることでパフォーマンスを向上させることができます。" - -#: ../../rst/scenario_guides/guide_azure.rst:397 -msgid "AZURE_INCLUDE_POWERSTATE=no" -msgstr "AZURE_INCLUDE_POWERSTATE=no" - -#: ../../rst/scenario_guides/guide_azure.rst:399 -msgid "A sample azure_rm.ini file is included along with the inventory script in `here `_. An .ini file will contain the following:" -msgstr "azure_rm.ini ファイルのサンプルは、`こちら `_ のインベントリースクリプトとともに含まれています。.ini ファイルには、以下が含まれます。" - -#: ../../rst/scenario_guides/guide_azure.rst:428 -#: ../../rst/scenario_guides/guide_oracle.rst:73 -msgid "Examples" -msgstr "例" - -#: ../../rst/scenario_guides/guide_azure.rst:430 -msgid "Here are some examples using the inventory script:" -msgstr "以下は、インベントリースクリプトの使用例です。" - -#: ../../rst/scenario_guides/guide_azure.rst:452 -msgid "Here is a simple playbook to exercise the Azure inventory script:" -msgstr "以下は、Azure インベントリースクリプトを実行するための単純な Playbook です。" - -#: ../../rst/scenario_guides/guide_azure.rst:464 -msgid "You can execute the playbook with something like:" -msgstr "Playbook は以下のような方法で実行できます。" - -#: ../../rst/scenario_guides/guide_azure.rst:472 -msgid "Disabling certificate validation on Azure endpoints" -msgstr "Azure エンドポイントでの証明書検証の無効化" - -#: ../../rst/scenario_guides/guide_azure.rst:474 -msgid "When an HTTPS proxy is present, or when using Azure Stack, it may be necessary to disable certificate validation for Azure endpoints in the Azure modules. This is not a recommended security practice, but may be necessary when the system CA store cannot be altered to include the necessary CA certificate. Certificate validation can be controlled by setting the \"cert_validation_mode\" value in a credential profile, via the \"AZURE_CERT_VALIDATION_MODE\" environment variable, or by passing the \"cert_validation_mode\" argument to any Azure module. The default value is \"validate\"; setting the value to \"ignore\" will prevent all certificate validation. The module argument takes precedence over a credential profile value, which takes precedence over the environment value." -msgstr "HTTPS プロキシーが存在する場合、または Azure Stack を使用している場合は、Azure モジュールで Azure エンドポイントの証明書検証を無効にしなければならない場合があります。これは推奨されるセキュリティー対策ではありませんが、システム CA ストアを変更して必要な CA 証明書を含めることができない場合に必要になることがあります。証明書の検証は、認証情報プロファイルで「cert_validation_mode」値を設定するか、環境変数「AZURE_CERT_VALIDATION_MODE」を経由するか、「cert_validation_mode」引数を任意の Azure モジュールに渡すことで制御できます。デフォルト値は「validate」で、「ignore」に設定すると証明書の検証は行われません。モジュールの引数は、環境の値よりも優先される認証情報プロファイルの値よりも優先されます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:2 -msgid "CloudStack Cloud Guide" -msgstr "CloudStack Cloud ガイド" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:8 -msgid "The purpose of this section is to explain how to put Ansible modules together to use Ansible in a CloudStack context. You will find more usage examples in the details section of each module." -msgstr "本セクションの目的は、Ansible モジュールを 1 つにまとめて CloudStack コンテキストで Ansible を使用する方法を説明します。詳細は、各モジュールの詳細セクションを参照してください。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:10 -msgid "Ansible contains a number of extra modules for interacting with CloudStack based clouds. All modules support check mode, are designed to be idempotent, have been created and tested, and are maintained by the community." -msgstr "Ansible には、CloudStack ベースのクラウドと対話するための追加モジュールが多数含まれています。モジュールサポートのチェックモードはすべて、冪等性があり、コミュニティーによって作成、テストされ、維持されています。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:12 -msgid "Some of the modules will require domain admin or root admin privileges." -msgstr "一部のモジュールには、ドメイン管理または root 管理者権限が必要です。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:15 -#: ../../rst/scenario_guides/guide_infoblox.rst:16 -#: ../../rst/scenario_guides/scenario_template.rst:17 -msgid "Prerequisites" -msgstr "要件" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:16 -msgid "Prerequisites for using the CloudStack modules are minimal. In addition to Ansible itself, all of the modules require the python library ``cs`` https://pypi.org/project/cs/" -msgstr "CloudStack モジュールを使用するための前提条件は最小限です。Ansible 自体に加えて、すべてのモジュールには python ライブラリー ``cs`` https://pypi.org/project/cs/ が必要です。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:18 -msgid "You'll need this Python module installed on the execution host, usually your workstation." -msgstr "この Python モジュールは、実行ホスト (通常はワークステーション) にインストールする必要があります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:24 -msgid "Or alternatively starting with Debian 9 and Ubuntu 16.04:" -msgstr "もしくは、Debian 9 および Ubuntu 16.04 から始まります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:30 -msgid "cs also includes a command line interface for ad hoc interaction with the CloudStack API, for example ``$ cs listVirtualMachines state=Running``." -msgstr "cs には、CloudStack API とのアドホック対話用のコマンドラインインターフェース (例: ``$ cs listVirtualMachines state=Running``) も含まれます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:33 -msgid "Limitations and Known Issues" -msgstr "制限および既知の問題" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:34 -msgid "VPC support has been improved since Ansible 2.3 but is still not yet fully implemented. The community is working on the VPC integration." -msgstr "Ansible 2.3 以降、VPC サポートが改善されましたが、まだ実装されていません。コミュニティーは VPC の統合に取り組んでいます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:37 -#: ../../rst/scenario_guides/guide_rax.rst:48 -msgid "Credentials File" -msgstr "認証情報ファイル" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:38 -msgid "You can pass credentials and the endpoint of your cloud as module arguments, however in most cases it is a far less work to store your credentials in the cloudstack.ini file." -msgstr "認証情報とクラウドのエンドポイントをモジュール引数として渡すことができますが、ほとんどの場合、認証情報を cloudstack.ini ファイルに保存する作業ははるかに少なくなります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:40 -msgid "The python library cs looks for the credentials file in the following order (last one wins):" -msgstr "Python ライブラリー cs は、以下の順番で認証情報ファイルを検索します (最後のコピーが優先されます)。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:42 -msgid "A ``.cloudstack.ini`` (note the dot) file in the home directory." -msgstr "ホームディレクトリーの ``.cloudstack.ini`` ファイル (ドットに注意)。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:43 -msgid "A ``CLOUDSTACK_CONFIG`` environment variable pointing to an .ini file." -msgstr ".ini ファイルを参照する ``CLOUDSTACK_CONFIG`` 環境変数。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:44 -msgid "A ``cloudstack.ini`` (without the dot) file in the current working directory, same directory as your playbooks are located." -msgstr "現在の作業ディレクトリー内の ``cloudstack.ini`` ファイル (ドットなし) は、Playbook が置かれているディレクトリーと同じディレクトリーです。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:46 -msgid "The structure of the ini file must look like this:" -msgstr "ini ファイルの構造は以下のようになります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:57 -msgid "The section ``[cloudstack]`` is the default section. ``CLOUDSTACK_REGION`` environment variable can be used to define the default section." -msgstr "``[cloudstack]`` セクションはデフォルトのセクションです。``CLOUDSTACK_REGION`` 環境変数を使用して、デフォルトのセクションを定義できます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:61 -msgid "The ENV variables support ``CLOUDSTACK_*`` as written in the documentation of the library ``cs``, like ``CLOUDSTACK_TIMEOUT``, ``CLOUDSTACK_METHOD``, and so on. has been implemented into Ansible. It is even possible to have some incomplete config in your cloudstack.ini:" -msgstr "ENV 変数はライブラリー ``cs`` のドキュメントに記載されているように、``CLOUDSTACK_TIMEOUT``、``CLOUDSTACK_METHOD`` などの ``CLOUDSTACK_*`` をサポートします。cloudstack.ini に不完全な設定の一部を含めることもできます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:70 -msgid "and fulfill the missing data by either setting ENV variables or tasks params:" -msgstr "ENV 変数または tasks パラメーターを設定して、不足しているデータに対応します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:86 -msgid "Regions" -msgstr "リージョン" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:87 -msgid "If you use more than one CloudStack region, you can define as many sections as you want and name them as you like, for example:" -msgstr "複数の CloudStack リージョンを使用する場合は、必要な数だけセクションを定義し、任意の名前を付けることができます。以下に例を示します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:107 -msgid "Sections can also be used to for login into the same region using different accounts." -msgstr "セクションは、異なるアカウントを使用して同じリージョンにログインするのにも使用できます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:109 -msgid "By passing the argument ``api_region`` with the CloudStack modules, the region wanted will be selected." -msgstr "CloudStack モジュールで引数 ``api_region`` を渡すと、希望のリージョンが選択されます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:120 -msgid "Or by looping over a regions list if you want to do the task in every region:" -msgstr "または、すべてのリージョンでタスクを実行する場合は、リージョンリストをループします。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:135 -msgid "Environment Variables" -msgstr "環境変数" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:138 -msgid "Since Ansible 2.3 it is possible to use environment variables for domain (``CLOUDSTACK_DOMAIN``), account (``CLOUDSTACK_ACCOUNT``), project (``CLOUDSTACK_PROJECT``), VPC (``CLOUDSTACK_VPC``) and zone (``CLOUDSTACK_ZONE``). This simplifies the tasks by not repeating the arguments for every tasks." -msgstr "Ansible 2.3 以降、ドメイン (``CLOUDSTACK_DOMAIN``)、アカウント (``CLOUDSTACK_ACCOUNT``)、プロジェクト (``CLOUDSTACK_PROJECT``)、VPC (``CLOUDSTACK_VPC``)、およびゾーン (``CLOUDSTACK_ZONE``) に環境変数を使用することができます。これにより、全タスクの引数を繰り返す必要がなくなり、タスクが簡素化されます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:140 -msgid "Below you see an example how it can be used in combination with Ansible's block feature:" -msgstr "以下は、Ansible のブロック機能と組み合わせて使用する例を示しています。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:166 -msgid "You are still able overwrite the environment variables using the module arguments, for example ``zone: sf-2``" -msgstr "モジュールの引数を使用して環境変数を上書きできます (例: ``zone: sf-2``)。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:168 -msgid "Unlike ``CLOUDSTACK_REGION`` these additional environment variables are ignored in the CLI ``cs``." -msgstr "``CLOUDSTACK_REGION`` とは異なり、CLI ``cs`` ではこれらの追加の環境変数は無視されます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:171 -#: ../../rst/scenario_guides/guide_rax.rst:406 -msgid "Use Cases" -msgstr "ユースケース" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:172 -msgid "The following should give you some ideas how to use the modules to provision VMs to the cloud. As always, there isn't only one way to do it. But as always: keep it simple for the beginning is always a good start." -msgstr "以下では、モジュールを使用して仮想マシンをクラウドにプロビジョニングする方法を示します。これを行う方法は 1 つではありませんが、最初はシンプルにすることが推奨されます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:175 -msgid "Use Case: Provisioning in a Advanced Networking CloudStack setup" -msgstr "ユースケース: Advanced Networking CloudStack 設定でのプロビジョニング" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:176 -msgid "Our CloudStack cloud has an advanced networking setup, we would like to provision web servers, which get a static NAT and open firewall ports 80 and 443. Further we provision database servers, to which we do not give any access to. For accessing the VMs by SSH we use a SSH jump host." -msgstr "CloudStack クラウドには高度なネットワーク設定があり、静的な NAT を取得し、ファイアウォールポート 80 および 443 を開く Web サーバーのプロビジョニングを行います。また、データベースサーバーもプロビジョニングしますが、これにはアクセス権が付与されていません。SSH による仮想マシンへのアクセスには SSH ジャンプホストを使用します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:178 -#: ../../rst/scenario_guides/guide_cloudstack.rst:285 -msgid "This is how our inventory looks like:" -msgstr "インベントリーは以下のようになります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:198 -msgid "As you can see, the public IPs for our web servers and jumphost has been assigned as variable ``public_ip`` directly in the inventory." -msgstr "ご覧のように、Web サーバーおよびジャンプホストのパブリック IP は、インベントリーで直接変数 ``public_ip`` として割り当てられます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:200 -msgid "The configure the jumphost, web servers and database servers, we use ``group_vars``. The ``group_vars`` directory contains 4 files for configuration of the groups: cloud-vm, jumphost, webserver and db-server. The cloud-vm is there for specifying the defaults of our cloud infrastructure." -msgstr "ジャンプホスト、Web サーバー、およびデータベースサーバーを設定します。``group_vars`` を使用します。``group_vars`` ディレクトリーには、グループ設定用の 4 つのファイル (cloud-vm、jumphost、webserver、および db-server) を含みます。cloud-vm はクラウドインフラストラクチャーのデフォルトを指定するために存在します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:209 -msgid "Our database servers should get more CPU and RAM, so we define to use a ``Large`` offering for them." -msgstr "データベースサーバーはより多くの CPU および RAM を取得する必要があるため、``Large`` オファリングの使用を定義します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:217 -msgid "The web servers should get a ``Small`` offering as we would scale them horizontally, which is also our default offering. We also ensure the known web ports are opened for the world." -msgstr "Web サーバーは、水平方向に拡張するため、``Small`` を提供しています。これは、デフォルトのオファリングでもあります。また、既知の Web ポートがグローバルに開いていることを確認します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:227 -msgid "Further we provision a jump host which has only port 22 opened for accessing the VMs from our office IPv4 network." -msgstr "さらに、オフィス IPv4 ネットワークから仮想マシンにアクセスするためにポート 22 のみを開くジャンプホストをプロビジョニングします。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:236 -msgid "Now to the fun part. We create a playbook to create our infrastructure we call it ``infra.yml``:" -msgstr "ここからが重要です。インフラストラクチャーを構築するための Playbook を作成します。これは、``infra.yml`` と呼ばれます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:267 -msgid "In the above play we defined 3 tasks and use the group ``cloud-vm`` as target to handle all VMs in the cloud but instead SSH to these VMs, we use ``delegate_to: localhost`` to execute the API calls locally from our workstation." -msgstr "上記のプレイでは、3 つのタスクを定義し、グループ ``cloud-vm`` をターゲットとして使用し、クラウド内の仮想マシンをすべて処理しますが、代わりにこれらの仮想マシンに SSH を使用するため、``delegate_to: localhost`` を使用してワークステーションからローカルに API 呼び出しを実行します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:269 -msgid "In the first task, we ensure we have a running VM created with the Debian template. If the VM is already created but stopped, it would just start it. If you like to change the offering on an existing VM, you must add ``force: yes`` to the task, which would stop the VM, change the offering and start the VM again." -msgstr "最初のタスクでは、Debian テンプレートで実行中の仮想マシンが作成されていることを確認しました。仮想マシンが作成されていて停止している場合は、開始するだけです。既存の仮想マシンでオファリングを変更する場合は ``force: yes`` をタスクに追加します。これにより、仮想マシンは停止し、オファリングを変更して再度仮想マシンを開始します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:271 -msgid "In the second task we ensure the ports are opened if we give a public IP to the VM." -msgstr "2 つ目のタスクでは、仮想マシンにパブリック IP を付与した場合にポートが開くようにします。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:273 -msgid "In the third task we add static NAT to the VMs having a public IP defined." -msgstr "3 つ目のタスクでは、パブリック IP が定義されている仮想マシンに静的 NAT を追加します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:276 -msgid "The public IP addresses must have been acquired in advance, also see ``cs_ip_address``" -msgstr "パブリック IP アドレスは事前に取得されている必要があります。「``cs_ip_address``」を参照してください。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:278 -msgid "For some modules, for example ``cs_sshkeypair`` you usually want this to be executed only once, not for every VM. Therefore you would make a separate play for it targeting localhost. You find an example in the use cases below." -msgstr "たとえば、``cs_sshkeypair`` などの一部のモジュールでは、仮想マシンごとに一度だけこれを実行する必要があります。ローカルホストを対象とする別のプレイを作成します。以下のユースケースで例を見てみましょう。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:281 -msgid "Use Case: Provisioning on a Basic Networking CloudStack setup" -msgstr "ユースケース: 基本的なネットワーク CloudStack 設定のプロビジョニング" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:283 -msgid "A basic networking CloudStack setup is slightly different: Every VM gets a public IP directly assigned and security groups are used for access restriction policy." -msgstr "基本的なネットワーク CloudStack の設定は若干異なります。すべての仮想マシンが直接割り当てられたパブリック IP を取得し、セキュリティーグループがアクセス制限ポリシーに使用されます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:296 -msgid "The default for your VMs looks like this:" -msgstr "仮想マシンのデフォルトは以下のようになります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:305 -msgid "Our webserver will also be in security group ``web``:" -msgstr "Web サーバーもセキュリティーグループ ``web`` に含まれます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:313 -msgid "The playbook looks like the following:" -msgstr "Playbook は以下のようになります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:375 -msgid "In the first play we setup the security groups, in the second play the VMs will created be assigned to these groups. Further you see, that we assign the public IP returned from the modules to the host inventory. This is needed as we do not know the IPs we will get in advance. In a next step you would configure the DNS servers with these IPs for accessing the VMs with their DNS name." -msgstr "最初のプレイでは、セキュリティグループを設定し、2 つ目のプレイでは、仮想マシンがこれらのグループに割り当てられるように作成されます。さらに、モジュールから返されたパブリック IP をホストのインベントリーに割り当てることが確認できます。これは、事前に取得する IP を把握していないため必要になります。次のステップでは、このような IP を使用して DNS サーバーを設定し、仮想マシンに DNS 名でアクセスできるようにします。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:377 -msgid "In the last task we wait for SSH to be accessible, so any later play would be able to access the VM by SSH without failure." -msgstr "最後のタスクでは、SSH がアクセス可能になるのを待ちます。したがって、後続のプレイでは、SSH で仮想マシンにアクセスする際に失敗せずに実行できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:2 -msgid "Docker Guide" -msgstr "Docker ガイド" - -#: ../../rst/scenario_guides/guide_docker.rst:4 -msgid "The `community.docker collection `_ offers several modules and plugins for orchestrating Docker containers and Docker Swarm." -msgstr "`community.docker collection `_ は、複数のモジュールと、Docker コンテナーおよび Docker Swarm のオーケストレーション用のプラグインを提供します。" - -#: ../../rst/scenario_guides/guide_docker.rst:14 -msgid "Most of the modules and plugins in community.docker require the `Docker SDK for Python `_. The SDK needs to be installed on the machines where the modules and plugins are executed, and for the Python version(s) with which the modules and plugins are executed. You can use the :ref:`community.general.python_requirements_info module ` to make sure that the Docker SDK for Python is installed on the correct machine and for the Python version used by Ansible." -msgstr "community.docker におけるほとんどのモジュールおよびプラグインには `Docker SDK for Python `_ が必要です。モジュールとプラグインが実行するマシンに SDK をインストールする必要があり、モジュールおよびプラグインが実行する Python バージョンで :ref:`community.general.python_requirements_info module ` を使用して、Docker SDK for Python が正しいマシンに、Ansible が使用する Python バージョン用にインストールされているようにすることができます。" - -#: ../../rst/scenario_guides/guide_docker.rst:16 -msgid "Note that plugins (inventory plugins and connection plugins) are always executed in the context of Ansible itself. If you use a plugin that requires the Docker SDK for Python, you need to install it on the machine running ``ansible`` or ``ansible-playbook`` and for the same Python interpreter used by Ansible. To see which Python is used, run ``ansible --version``." -msgstr "プラグイン (インベントリープラグインおよび接続プラグイン) は常に Ansible のコンテキストで実行されます。Python 用の Docker SDK を必要とするプラグインを使用する場合は、``ansible`` または ``ansible-playbook`` を実行しているマシンにプラグインをインストールする必要があります。使用する Python を確認するには、``ansible --version`` を実行します。" - -#: ../../rst/scenario_guides/guide_docker.rst:18 -msgid "You can install the Docker SDK for Python for Python 2.7 or Python 3 as follows:" -msgstr "Python 2.7 または Python 3 用の Docker SDK は、以下のようにインストールできます。" - -#: ../../rst/scenario_guides/guide_docker.rst:24 -msgid "For Python 2.6, you need a version before 2.0. For these versions, the SDK was called ``docker-py``, so you need to install it as follows:" -msgstr "Python 2.6 では 2.0 よりも前のバージョンが必要です。これらのバージョンでは、SDK は ``docker-py`` と呼ばれ、以下のようにインストールする必要があります。" - -#: ../../rst/scenario_guides/guide_docker.rst:30 -msgid "Please install only one of ``docker`` or ``docker-py``. Installing both will result in a broken installation. If this happens, Ansible will detect it and inform you about it. If that happens, you must uninstall both and reinstall the correct version." -msgstr "``docker`` または ``docker-py`` のいずれかをインストールするには、インストールが破損します。これがインストールされると、Ansible によって検出され、それについて通知されます。その場合は、両方をアンインストールして再インストールする必要があります。" - -#: ../../rst/scenario_guides/guide_docker.rst:32 -msgid "If in doubt, always install ``docker`` and never ``docker-py``." -msgstr "不明な場合は、常に ``docker`` をインストールし、``docker-py`` はインストールしません。" - -#: ../../rst/scenario_guides/guide_docker.rst:36 -msgid "Connecting to the Docker API" -msgstr "Docker API への接続" - -#: ../../rst/scenario_guides/guide_docker.rst:38 -msgid "You can connect to a local or remote API using parameters passed to each task or by setting environment variables. The order of precedence is command line parameters and then environment variables. If neither a command line option nor an environment variable is found, Ansible uses the default value provided under `Parameters`_." -msgstr "各タスクに渡されるパラメーターを使用するか、環境変数を設定してローカルまたはリモートの API に接続できます。優先順位の順番はコマンドラインパラメーターとその環境変数です。コマンドラインオプションも環境変数も見つからない場合、Ansible は `Parameters`_ で指定したデフォルト値を使用します。" - -#: ../../rst/scenario_guides/guide_docker.rst:42 -msgid "Parameters" -msgstr "パラメーター" - -#: ../../rst/scenario_guides/guide_docker.rst:44 -msgid "Most plugins and modules can be configured by the following parameters:" -msgstr "ほとんどのプラグインおよびモジュールは、以下のパラメーターで設定できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:47 -msgid "docker_host" -msgstr "docker_host" - -#: ../../rst/scenario_guides/guide_docker.rst:47 -msgid "The URL or Unix socket path used to connect to the Docker API. Defaults to ``unix://var/run/docker.sock``. To connect to a remote host, provide the TCP connection string (for example: ``tcp://192.0.2.23:2376``). If TLS is used to encrypt the connection to the API, then the module will automatically replace 'tcp' in the connection URL with 'https'." -msgstr "Docker API への接続に使用される URL または Unix ソケットパス。デフォルトは ``unix://var/run/docker.sock`` です。リモートホストに接続するには、TCP 接続文字列を指定します (例: ``tcp://192.0.2.23:2376``)。TLS を使用して API への接続を暗号化すると、モジュールは、接続 URL の 「tcp」を自動的に「https」に置き換えます。" - -#: ../../rst/scenario_guides/guide_docker.rst:50 -msgid "api_version" -msgstr "api_version" - -#: ../../rst/scenario_guides/guide_docker.rst:50 -msgid "The version of the Docker API running on the Docker Host. Defaults to the latest version of the API supported by the Docker SDK for Python installed." -msgstr "Docker Host 上で実行される Docker API のバージョンです。デフォルトでは、Python 用の Docker SDK によってサポートされる API の最新バージョンに設定されます。" - -#: ../../rst/scenario_guides/guide_docker.rst:53 -msgid "The maximum amount of time in seconds to wait on a response from the API. Defaults to 60 seconds." -msgstr "API からのレスポンスで待機する最大時間 (秒単位)。デフォルトは 60 秒です。" - -#: ../../rst/scenario_guides/guide_docker.rst:56 -msgid "tls" -msgstr "tls" - -#: ../../rst/scenario_guides/guide_docker.rst:56 -msgid "Secure the connection to the API by using TLS without verifying the authenticity of the Docker host server. Defaults to ``false``." -msgstr "Docker ホストサーバーの信頼性を検証せずに TLS を使用して API への接続を保護します。デフォルトは ``false`` です。" - -#: ../../rst/scenario_guides/guide_docker.rst:59 -msgid "Secure the connection to the API by using TLS and verifying the authenticity of the Docker host server. Default is ``false``." -msgstr "TLS を使用し、Docker ホストサーバーの信頼性を検証して、API への接続を保護します。デフォルトは``false`` です。" - -#: ../../rst/scenario_guides/guide_docker.rst:62 -msgid "cacert_path" -msgstr "cacert_path" - -#: ../../rst/scenario_guides/guide_docker.rst:62 -msgid "Use a CA certificate when performing server verification by providing the path to a CA certificate file." -msgstr "CA 証明書ファイルへのパスを指定してサーバーの検証を実行する際に CA 証明書を使用します。" - -#: ../../rst/scenario_guides/guide_docker.rst:65 -msgid "cert_path" -msgstr "cert_path" - -#: ../../rst/scenario_guides/guide_docker.rst:65 -msgid "Path to the client's TLS certificate file." -msgstr "クライアントの TLS 証明書ファイルへのパスです。" - -#: ../../rst/scenario_guides/guide_docker.rst:68 -msgid "key_path" -msgstr "key_path" - -#: ../../rst/scenario_guides/guide_docker.rst:68 -msgid "Path to the client's TLS key file." -msgstr "クライアントの TLS キーファイルへのパスです。" - -#: ../../rst/scenario_guides/guide_docker.rst:71 -msgid "tls_hostname" -msgstr "tls_hostname" - -#: ../../rst/scenario_guides/guide_docker.rst:71 -msgid "When verifying the authenticity of the Docker Host server, provide the expected name of the server. Defaults to ``localhost``." -msgstr "Docker Host サーバーの信頼性を確認する際に、予想されるサーバー名を提供します。デフォルトは ``localhost`` です。" - -#: ../../rst/scenario_guides/guide_docker.rst:75 -msgid "ssl_version" -msgstr "ssl_version" - -#: ../../rst/scenario_guides/guide_docker.rst:74 -msgid "Provide a valid SSL version number. The default value is determined by the Docker SDK for Python." -msgstr "有効な SSL バージョン番号を提供します。デフォルト値は、Python の Docker SDK により決定されます。" - -#: ../../rst/scenario_guides/guide_docker.rst:78 -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:17 -msgid "Environment variables" -msgstr "環境変数" - -#: ../../rst/scenario_guides/guide_docker.rst:80 -msgid "You can also control how the plugins and modules connect to the Docker API by setting the following environment variables." -msgstr "以下の環境変数を設定して、プラグインおよびモジュールが Docker API に接続する方法を制御することもできます。" - -#: ../../rst/scenario_guides/guide_docker.rst:82 -msgid "For plugins, they have to be set for the environment Ansible itself runs in. For modules, they have to be set for the environment the modules are executed in. For modules running on remote machines, the environment variables have to be set on that machine for the user used to execute the modules with." -msgstr "プラグインには、Ansible 自体が実行する環境に合わせて設定する必要があります。モジュールの場合は、モジュールが実行する環境に設定する必要があります。リモートマシンで実行しているモジュールの場合は、モジュールを実行するユーザーのマシンに環境変数を設定する必要があります。" - -#: ../../rst/scenario_guides/guide_docker.rst:85 -msgid "DOCKER_HOST" -msgstr "DOCKER_HOST" - -#: ../../rst/scenario_guides/guide_docker.rst:85 -msgid "The URL or Unix socket path used to connect to the Docker API." -msgstr "Docker API への接続に使用される URL または Unix ソケットパス。" - -#: ../../rst/scenario_guides/guide_docker.rst:89 -msgid "DOCKER_API_VERSION" -msgstr "DOCKER_API_VERSION" - -#: ../../rst/scenario_guides/guide_docker.rst:88 -msgid "The version of the Docker API running on the Docker Host. Defaults to the latest version of the API supported by docker-py." -msgstr "Docker Host 上で実行する Docker API のバージョンです。デフォルトでは、docker-py でサポートされる API の最新バージョンに設定されます。" - -#: ../../rst/scenario_guides/guide_docker.rst:92 -msgid "DOCKER_TIMEOUT" -msgstr "DOCKER_TIMEOUT" - -#: ../../rst/scenario_guides/guide_docker.rst:92 -msgid "The maximum amount of time in seconds to wait on a response from the API." -msgstr "API からの応答で待機する最大時間 (秒単位)。" - -#: ../../rst/scenario_guides/guide_docker.rst:95 -msgid "DOCKER_CERT_PATH" -msgstr "DOCKER_CERT_PATH" - -#: ../../rst/scenario_guides/guide_docker.rst:95 -msgid "Path to the directory containing the client certificate, client key and CA certificate." -msgstr "クライアント証明書、クライアントキー、および CA 証明書を含むディレクトリーへのパス。" - -#: ../../rst/scenario_guides/guide_docker.rst:98 -msgid "DOCKER_SSL_VERSION" -msgstr "DOCKER_SSL_VERSION" - -#: ../../rst/scenario_guides/guide_docker.rst:98 -msgid "Provide a valid SSL version number." -msgstr "有効な SSL バージョン番号を指定します。" - -#: ../../rst/scenario_guides/guide_docker.rst:101 -msgid "DOCKER_TLS" -msgstr "DOCKER_TLS" - -#: ../../rst/scenario_guides/guide_docker.rst:101 -msgid "Secure the connection to the API by using TLS without verifying the authenticity of the Docker Host." -msgstr "Docker ホストの信頼性を検証せずに TLS を使用して API への接続のセキュリティーを保護します。" - -#: ../../rst/scenario_guides/guide_docker.rst:105 -msgid "DOCKER_TLS_VERIFY" -msgstr "DOCKER_TLS_VERIFY" - -#: ../../rst/scenario_guides/guide_docker.rst:104 -msgid "Secure the connection to the API by using TLS and verify the authenticity of the Docker Host." -msgstr "TLS を使用して API への接続のセキュリティーを確保し、Docker ホストの信頼性を検証します。" - -#: ../../rst/scenario_guides/guide_docker.rst:108 -msgid "Plain Docker daemon: images, networks, volumes, and containers" -msgstr "単純な Docker デーモン: イメージ、ネットワーク、ボリューム、およびコンテナー" - -#: ../../rst/scenario_guides/guide_docker.rst:110 -msgid "For working with a plain Docker daemon, that is without Swarm, there are connection plugins, an inventory plugin, and several modules available:" -msgstr "Swarm を使用しないプレーンな Docker デーモンを使用する場合は、接続プラグイン、インベントリープラグイン、および複数のモジュールが利用できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:113 -msgid "docker connection plugin" -msgstr "Docker 接続プラグイン" - -#: ../../rst/scenario_guides/guide_docker.rst:113 -msgid "The :ref:`community.docker.docker connection plugin ` uses the Docker CLI utility to connect to Docker containers and execute modules in them. It essentially wraps ``docker exec`` and ``docker cp``. This connection plugin is supported by the :ref:`ansible.posix.synchronize module `." -msgstr ":ref:`community.docker.docker 接続プラグイン ` は、Docker CLI ユーティリティーを使用して Docker コンテナーに接続し、そのコンテナーでモジュールを実行します。基本的に ``docker exec`` と ``docker cp`` をラップします。この接続プラグインは :ref:`ansible.posix.synchronize module ` によりサポートされます。" - -#: ../../rst/scenario_guides/guide_docker.rst:116 -msgid "docker_api connection plugin" -msgstr "docker_api connection プラグイン" - -#: ../../rst/scenario_guides/guide_docker.rst:116 -msgid "The :ref:`community.docker.docker_api connection plugin ` talks directly to the Docker daemon to connect to Docker containers and execute modules in them." -msgstr ":ref:`community.docker.docker_api 接続プラグイン ` は Docker デーモンに直接対話し、Docker コンテナーに接続し、そのコンテナーでモジュールを実行します。" - -#: ../../rst/scenario_guides/guide_docker.rst:121 -msgid "docker_containers inventory plugin" -msgstr "docker_containers インベントリープラグイン" - -#: ../../rst/scenario_guides/guide_docker.rst:119 -msgid "The :ref:`community.docker.docker_containers inventory plugin ` allows you to dynamically add Docker containers from a Docker Daemon to your Ansible inventory. See :ref:`dynamic_inventory` for details on dynamic inventories." -msgstr ":ref:`community.docker.docker_containers インベントリープラグイン ` では、Docker Daemon から Ansible インベントリーに Docker コンテナーを動的に追加できます。動的インベントリーの詳細は、「:ref:`dynamic_inventory`」を参照してください。" - -#: ../../rst/scenario_guides/guide_docker.rst:121 -msgid "The `docker inventory script `_ is deprecated. Please use the inventory plugin instead. The inventory plugin has several compatibility options. If you need to collect Docker containers from multiple Docker daemons, you need to add every Docker daemon as an individual inventory source." -msgstr "`Docker インベントリースクリプト `_ は非推奨になりました。代わりにインベントリープラグインを使用してください。インベントリープラグインには、複数の互換性オプションがあります。複数の Docker デーモンから Docker コンテナーを収集する必要がある場合は、すべての Docker デーモンを個別のインベントリーソースとして追加する必要があります。" - -#: ../../rst/scenario_guides/guide_docker.rst:124 -msgid "docker_host_info module" -msgstr "docker_host_info モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:124 -msgid "The :ref:`community.docker.docker_host_info module ` allows you to retrieve information on a Docker daemon, such as all containers, images, volumes, networks and so on." -msgstr ":ref:`community.docker.docker_host_info モジュール ` では、すべてのコンテナー、イメージ、ボリューム、ネットワークなど、Docker デーモンの情報を取得できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:127 -msgid "docker_login module" -msgstr "docker_login モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:127 -msgid "The :ref:`community.docker.docker_login module ` allows you to log in and out of a remote registry, such as Docker Hub or a private registry. It provides similar functionality to the ``docker login`` and ``docker logout`` CLI commands." -msgstr ":ref:`community.docker.docker_login モジュール ` では、Docker Hub、プライベートレジストリーなどのリモートレジストリーへのログイン、およびリモートレジストリーからのログアウトできます。CLI コマンド ``docker login`` および ``docker logout`` と同様の機能を提供します。" - -#: ../../rst/scenario_guides/guide_docker.rst:130 -msgid "docker_prune module" -msgstr "docker_prune モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:130 -msgid "The :ref:`community.docker.docker_prune module ` allows you to prune no longer needed containers, images, volumes and so on. It provides similar functionality to the ``docker prune`` CLI command." -msgstr ":ref:`community.docker.docker_prune モジュール ` では、コンテナー、イメージ、ボリュームなどは取り除くことができなくなり、CLI コマンド ``docker prune`` と同様の機能を提供します。" - -#: ../../rst/scenario_guides/guide_docker.rst:133 -msgid "docker_image module" -msgstr "docker_image モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:133 -msgid "The :ref:`community.docker.docker_image module ` provides full control over images, including: build, pull, push, tag and remove." -msgstr ":ref:`community.docker.docker_image モジュール ` は、build、pull、push、tag、remove などのイメージを完全に制御します。" - -#: ../../rst/scenario_guides/guide_docker.rst:136 -msgid "docker_image_info module" -msgstr "docker_image_info モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:136 -msgid "The :ref:`community.docker.docker_image_info module ` allows you to list and inspect images." -msgstr ":ref:`community.docker.docker_image_info モジュール ` を使用すると、イメージを一覧表示し、検査することができます。" - -#: ../../rst/scenario_guides/guide_docker.rst:139 -msgid "docker_network module" -msgstr "docker_network モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:139 -msgid "The :ref:`community.docker.docker_network module ` provides full control over Docker networks." -msgstr ":ref:`community.docker.docker_network モジュール ` は、Docker ネットワークを完全に制御します。" - -#: ../../rst/scenario_guides/guide_docker.rst:142 -msgid "docker_network_info module" -msgstr "docker_network_info モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:142 -msgid "The :ref:`community.docker.docker_network_info module ` allows you to inspect Docker networks." -msgstr ":ref:`community.docker.docker_network_info モジュール ` では、Docker ネットワークを調べることができます。" - -#: ../../rst/scenario_guides/guide_docker.rst:145 -msgid "docker_volume_info module" -msgstr "docker_volume_info モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:145 -msgid "The :ref:`community.docker.docker_volume_info module ` provides full control over Docker volumes." -msgstr ":ref:`community.docker.docker_volume_info モジュール ` は、Docker ボリュームを完全に制御します。" - -#: ../../rst/scenario_guides/guide_docker.rst:148 -msgid "docker_volume module" -msgstr "docker_volume モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:148 -msgid "The :ref:`community.docker.docker_volume module ` allows you to inspect Docker volumes." -msgstr ":ref:`community.docker.docker_volume モジュール ` を使用すると、Docker ボリュームを検査できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:151 -msgid "docker_container module" -msgstr "docker_container モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:151 -msgid "The :ref:`community.docker.docker_container module ` manages the container lifecycle by providing the ability to create, update, stop, start and destroy a Docker container." -msgstr ":ref:`community.docker.docker_container モジュール ` は、Docker コンテナーの作成、更新、停止、開始、および破棄の機能を提供することで、コンテナーのライフサイクルを管理します。" - -#: ../../rst/scenario_guides/guide_docker.rst:155 -msgid "docker_container_info module" -msgstr "docker_container_info モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:154 -msgid "The :ref:`community.docker.docker_container_info module ` allows you to inspect a Docker container." -msgstr ":ref:`community.docker.docker_container_info モジュール ` では、Docker コンテナーを検査できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:158 -msgid "Docker Compose" -msgstr "Docker Compose" - -#: ../../rst/scenario_guides/guide_docker.rst:160 -msgid "The :ref:`community.docker.docker_compose module ` allows you to use your existing Docker compose files to orchestrate containers on a single Docker daemon or on Swarm. Supports compose versions 1 and 2." -msgstr ":ref:`community.docker.docker_compose モジュール ` では、既存の Docker Compose ファイルを使用して、単一の Docker デーモンまたは Swarm でコンテナーをオーケストレーションできます。Compose のバージョン 1 および 2 をサポートします。" - -#: ../../rst/scenario_guides/guide_docker.rst:164 -msgid "Next to Docker SDK for Python, you need to install `docker-compose `_ on the remote machines to use the module." -msgstr "モジュールを使用するには、Python の Docker SDK の次に、リモートマシンに `docker-compose `_ をインストールする必要があります。" - -#: ../../rst/scenario_guides/guide_docker.rst:168 -msgid "Docker Machine" -msgstr "Docker マシン" - -#: ../../rst/scenario_guides/guide_docker.rst:170 -msgid "The :ref:`community.docker.docker_machine inventory plugin ` allows you to dynamically add Docker Machine hosts to your Ansible inventory." -msgstr ":ref:`community.docker.docker_machine inventory plugin ` では、Docker マシンホストを Ansible インベントリーに動的に追加できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:174 -msgid "Docker stack" -msgstr "Docker スタック" - -#: ../../rst/scenario_guides/guide_docker.rst:176 -msgid "The :ref:`community.docker.docker_stack module ` module allows you to control Docker stacks. Information on stacks can be retrieved by the :ref:`community.docker.docker_stack_info module `, and information on stack tasks can be retrieved by the :ref:`community.docker.docker_stack_task_info module `." -msgstr ":ref:`community.docker.docker_stack モジュール ` モジュールにより、Docker スタックを制御できます。スタックの情報は、:ref:`community.docker.docker_stack_info モジュール ` で取得でき、スタックタスクに関する情報は :ref:`community.docker.docker_stack_task_info モジュール ` で取得できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:180 -msgid "Docker Swarm" -msgstr "Docker Swarm" - -#: ../../rst/scenario_guides/guide_docker.rst:182 -msgid "The community.docker collection provides multiple plugins and modules for managing Docker Swarms." -msgstr "community.docker コレクションは、Docker Swarm を管理するための複数のプラグインとモジュールを提供します。" - -#: ../../rst/scenario_guides/guide_docker.rst:185 -msgid "Swarm management" -msgstr "Swarm 管理" - -#: ../../rst/scenario_guides/guide_docker.rst:187 -msgid "One inventory plugin and several modules are provided to manage Docker Swarms:" -msgstr "Docker Swarms を管理するために、インベントリープラグインと複数のモジュールが提供されます。" - -#: ../../rst/scenario_guides/guide_docker.rst:190 -msgid "docker_swarm inventory plugin" -msgstr "docker_swarm インベントリープラグイン" - -#: ../../rst/scenario_guides/guide_docker.rst:190 -msgid "The :ref:`community.docker.docker_swarm inventory plugin ` allows you to dynamically add all Docker Swarm nodes to your Ansible inventory." -msgstr ":ref:`community.docker.docker_swarm インベントリープラグイン ` により、すべての Docker Swarm ノードを Ansible インベントリーに動的に追加できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:193 -msgid "docker_swarm module" -msgstr "docker_swarm モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:193 -msgid "The :ref:`community.docker.docker_swarm module ` allows you to globally configure Docker Swarm manager nodes to join and leave swarms, and to change the Docker Swarm configuration." -msgstr ":ref:`community.docker.docker_swarm モジュール ` では、Docker Swarm マネージャーノードをグローバルに設定し、swarm に参加および swarm から離脱し、Docker Swarm 設定の変更を行うことができます。" - -#: ../../rst/scenario_guides/guide_docker.rst:196 -msgid "docker_swarm_info module" -msgstr "docker_swarm_info モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:196 -msgid "The :ref:`community.docker.docker_swarm_info module ` allows you to retrieve information on Docker Swarm." -msgstr ":ref:`community.docker.docker_swarm_info モジュール ` では、Docker Swarm に関する情報を取得できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:199 -msgid "docker_node module" -msgstr "docker_node モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:199 -msgid "The :ref:`community.docker.docker_node module ` allows you to manage Docker Swarm nodes." -msgstr ":ref:`community.docker.docker_node モジュール ` では、Docker Swarm ノードを管理できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:202 -msgid "docker_node_info module" -msgstr "docker_node_info モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:202 -msgid "The :ref:`community.docker.docker_node_info module ` allows you to retrieve information on Docker Swarm nodes." -msgstr ":ref:`community.docker.docker_node_info モジュール ` では、Docker Swarm ノードの情報を取得できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:205 -msgid "Configuration management" -msgstr "設定管理" - -#: ../../rst/scenario_guides/guide_docker.rst:207 -msgid "The community.docker collection offers modules to manage Docker Swarm configurations and secrets:" -msgstr "community.docker コレクションは、Docker Swarm 設定およびシークレットを管理するモジュールを提供します。" - -#: ../../rst/scenario_guides/guide_docker.rst:210 -msgid "docker_config module" -msgstr "docker_config モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:210 -msgid "The :ref:`community.docker.docker_config module ` allows you to create and modify Docker Swarm configs." -msgstr ":ref:`community.docker.docker_config モジュール ` を使用すると、Docker Swarm 設定を作成および変更できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:214 -msgid "docker_secret module" -msgstr "docker_secret モジュール" - -#: ../../rst/scenario_guides/guide_docker.rst:213 -msgid "The :ref:`community.docker.docker_secret module ` allows you to create and modify Docker Swarm secrets." -msgstr ":ref:`community.docker.docker_secret モジュール ` では、Docker Swarm シークレットを作成および変更できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:217 -msgid "Swarm services" -msgstr "Swarm サービス" - -#: ../../rst/scenario_guides/guide_docker.rst:219 -msgid "Docker Swarm services can be created and updated with the :ref:`community.docker.docker_swarm_service module `, and information on them can be queried by the :ref:`community.docker.docker_swarm_service_info module `." -msgstr "Docker Swarm サービスは、:ref:`community.docker.docker_swarm_service モジュール ` で作成および更新でき、その情報は、:ref:`community.docker.docker_swarm_service_info モジュール ` でクエリーできます。" - -#: ../../rst/scenario_guides/guide_docker.rst:223 -msgid "Helpful links" -msgstr "便利なリンク" - -#: ../../rst/scenario_guides/guide_docker.rst:225 -msgid "Still using Dockerfile to build images? Check out `ansible-bender `_, and start building images from your Ansible playbooks." -msgstr "Dockerfile を使用してイメージを構築していますか。`ansible-bender `_ を確認して、Ansible Playbook からイメージの構築を開始します。" - -#: ../../rst/scenario_guides/guide_docker.rst:227 -msgid "Use `Ansible Operator `_ to launch your docker-compose file on `OpenShift `_. Go from an app on your laptop to a fully scalable app in the cloud with Kubernetes in just a few moments." -msgstr "`Ansible Operator `_ を使用して、`OpenShift `_ で docker 構成のファイルを起動します。ラップトップ上のアプリケーションから、Kubernetes を使用するクラウド内の完全なスケーラブルなアプリケーション (数分間) に移動します。" - -#: ../../rst/scenario_guides/guide_gce.rst:2 -msgid "Google Cloud Platform Guide" -msgstr "Google Cloud Platform ガイド" - -#: ../../rst/scenario_guides/guide_gce.rst:9 -msgid "Ansible + Google have been working together on a set of auto-generated Ansible modules designed to consistently and comprehensively cover the entirety of the Google Cloud Platform (GCP)." -msgstr "Ansible および Google はともに、Google Cloud Platform (GCP) 全体を一貫して包括的に対応するために設計された、自動生成される Ansible モジュールのセットを開発しました。" - -#: ../../rst/scenario_guides/guide_gce.rst:13 -msgid "Ansible contains modules for managing Google Cloud Platform resources, including creating instances, controlling network access, working with persistent disks, managing load balancers, and a lot more." -msgstr "Ansible には、インスタンスの作成、ネットワークアクセスの制御、永続的なディスクの使用、ロードバランサーの管理など、Google Cloud Platform リソースを管理するためのモジュールが含まれます。" - -#: ../../rst/scenario_guides/guide_gce.rst:17 -msgid "These new modules can be found under a new consistent name scheme \"gcp_*\" (Note: gcp_target_proxy and gcp_url_map are legacy modules, despite the \"gcp_*\" name. Please use gcp_compute_target_proxy and gcp_compute_url_map instead)." -msgstr "これらの新しいモジュールは、新しい一貫した名前スキーム「gcp_*」で見つけることができます (注: gcp_target_proxy および gcp_url_map は 「gcp_*」の名前ですが、レガシーモジュールです。代わりに gcp_compute_target_proxy および gcp_compute_url_map を使用してください)。" - -#: ../../rst/scenario_guides/guide_gce.rst:21 -msgid "Additionally, the gcp_compute inventory plugin can discover all Google Compute Engine (GCE) instances and make them automatically available in your Ansible inventory." -msgstr "さらに、gcp_compute インベントリープラグインは、すべての Google Compute Engine(GCE) インスタンスを検出し、Ansible インベントリーで自動的に利用可能にすることができます。" - -#: ../../rst/scenario_guides/guide_gce.rst:25 -msgid "You may see a collection of other GCP modules that do not conform to this naming convention. These are the original modules primarily developed by the Ansible community. You will find some overlapping functionality such as with the \"gce\" module and the new \"gcp_compute_instance\" module. Either can be used, but you may experience issues trying to use them together." -msgstr "この命名規則に準拠していない他の GCP モジュールのコレクションが表示されることがあります。これらは、主に Ansible コミュニティーによって開発されたオリジナルのモジュールです。「gce」モジュールと新しい「gcp_compute_instance」モジュールのように、機能が重複しているものがあります。どちらを使用しても構いませんが、一緒に使用すると問題が発生する可能性があります。" - -#: ../../rst/scenario_guides/guide_gce.rst:31 -msgid "While the community GCP modules are not going away, Google is investing effort into the new \"gcp_*\" modules. Google is committed to ensuring the Ansible community has a great experience with GCP and therefore recommends adopting these new modules if possible." -msgstr "コミュニティーの GCP モジュールはなくなるわけではありませんが、Google は新しい「gcp_*」モジュールに力を注いでいます。Google は、Ansible コミュニティーが GCP で豊富な経験があることを確かにするためにコミットされているため、可能な場合はこれらの新規モジュールの導入を推奨しています。" - -#: ../../rst/scenario_guides/guide_gce.rst:38 -msgid "Requisites" -msgstr "要件" - -#: ../../rst/scenario_guides/guide_gce.rst:39 -msgid "The GCP modules require both the ``requests`` and the ``google-auth`` libraries to be installed." -msgstr "GCP モジュールでは、``requests`` ライブラリーと ``google-auth`` ライブラリーの両方をインストールする必要があります。" - -#: ../../rst/scenario_guides/guide_gce.rst:46 -msgid "Alternatively for RHEL / CentOS, the ``python-requests`` package is also available to satisfy ``requests`` libraries." -msgstr "RHEL/CentOS の場合は、``python-requests`` ライブラリーを満たすために ``requests`` パッケージも利用できます。" - -#: ../../rst/scenario_guides/guide_gce.rst:54 -msgid "Credentials" -msgstr "認証情報" - -#: ../../rst/scenario_guides/guide_gce.rst:55 -msgid "It's easy to create a GCP account with credentials for Ansible. You have multiple options to get your credentials - here are two of the most common options:" -msgstr "Ansible の認証情報を使用して GCP アカウントを作成できます。認証情報を取得するオプションは複数あります。以下に、最も一般的なオプションの 2 つがあります。" - -#: ../../rst/scenario_guides/guide_gce.rst:58 -msgid "Service Accounts (Recommended): Use JSON service accounts with specific permissions." -msgstr "サービスアカウント (推奨): 特定のパーミッションを持つ JSON サービスアカウントを使用します。" - -#: ../../rst/scenario_guides/guide_gce.rst:59 -msgid "Machine Accounts: Use the permissions associated with the GCP Instance you're using Ansible on." -msgstr "マシンアカウント: Ansible をお使いの GCP インスタンスに関連付けられたパーミッションを使用します。" - -#: ../../rst/scenario_guides/guide_gce.rst:61 -msgid "For the following examples, we'll be using service account credentials." -msgstr "以下の例では、サービスアカウントの認証情報を使用します。" - -#: ../../rst/scenario_guides/guide_gce.rst:63 -msgid "To work with the GCP modules, you'll first need to get some credentials in the JSON format:" -msgstr "GCP モジュールを使用するには、最初に JSON 形式でいくつかの認証情報を取得する必要があります。" - -#: ../../rst/scenario_guides/guide_gce.rst:66 -msgid "`Create a Service Account `_" -msgstr "`Create a Service Account `_" - -#: ../../rst/scenario_guides/guide_gce.rst:67 -msgid "`Download JSON credentials `_" -msgstr "`Download JSON credentials `_" - -#: ../../rst/scenario_guides/guide_gce.rst:69 -msgid "Once you have your credentials, there are two different ways to provide them to Ansible:" -msgstr "認証情報を取得したあと、Ansible に提供する方法は 2 つあります。" - -#: ../../rst/scenario_guides/guide_gce.rst:71 -msgid "by specifying them directly as module parameters" -msgstr "モジュールパラメーターとして直接指定する" - -#: ../../rst/scenario_guides/guide_gce.rst:72 -msgid "by setting environment variables" -msgstr "追加の環境変数を設定する" - -#: ../../rst/scenario_guides/guide_gce.rst:75 -msgid "Providing Credentials as Module Parameters" -msgstr "認証情報をモジュールパラメーターとして指定" - -#: ../../rst/scenario_guides/guide_gce.rst:77 -msgid "For the GCE modules you can specify the credentials as arguments:" -msgstr "GCE モジュールでは、認証情報を引数として指定できます。" - -#: ../../rst/scenario_guides/guide_gce.rst:79 -msgid "``auth_kind``: type of authentication being used (choices: machineaccount, serviceaccount, application)" -msgstr "``auth_kind``: 使用される認証のタイプ (選択肢: machineaccount、serviceaccount、application)" - -#: ../../rst/scenario_guides/guide_gce.rst:80 -msgid "``service_account_email``: email associated with the project" -msgstr "``service_account_email``: プロジェクトに関連する電子メール" - -#: ../../rst/scenario_guides/guide_gce.rst:81 -msgid "``service_account_file``: path to the JSON credentials file" -msgstr "``service_account_file``: JSON 認証情報ファイルへのパス" - -#: ../../rst/scenario_guides/guide_gce.rst:82 -msgid "``project``: id of the project" -msgstr "``project``: プロジェクトの ID" - -#: ../../rst/scenario_guides/guide_gce.rst:83 -msgid "``scopes``: The specific scopes that you want the actions to use." -msgstr "``scopes``: アクションで使用する特定のスコープ。" - -#: ../../rst/scenario_guides/guide_gce.rst:85 -msgid "For example, to create a new IP address using the ``gcp_compute_address`` module, you can use the following configuration:" -msgstr "たとえば、``gcp_compute_address`` モジュールを使用して新規 IP アドレスを作成するには、以下の設定を使用できます。" - -#: ../../rst/scenario_guides/guide_gce.rst:114 -msgid "Providing Credentials as Environment Variables" -msgstr "認証情報を環境変数として指定" - -#: ../../rst/scenario_guides/guide_gce.rst:116 -msgid "Set the following environment variables before running Ansible in order to configure your credentials:" -msgstr "認証情報を設定するために Ansible を実行する前に、以下の環境変数を設定します。" - -#: ../../rst/scenario_guides/guide_gce.rst:126 -msgid "GCE Dynamic Inventory" -msgstr "GCE 動的インベントリー" - -#: ../../rst/scenario_guides/guide_gce.rst:128 -msgid "The best way to interact with your hosts is to use the gcp_compute inventory plugin, which dynamically queries GCE and tells Ansible what nodes can be managed." -msgstr "ホストと対話する最適な方法は、gcp_compute インベントリープラグインを使用することです。このプラグインは、GCE に動的にクエリーを送信し、管理できるノードを Ansible に通知します。" - -#: ../../rst/scenario_guides/guide_gce.rst:130 -msgid "To be able to use this GCE dynamic inventory plugin, you need to enable it first by specifying the following in the ``ansible.cfg`` file:" -msgstr "この GCE 動的インベントリープラグインを使用するには、最初に ``ansible.cfg`` ファイルに以下を指定して有効にする必要があります。" - -#: ../../rst/scenario_guides/guide_gce.rst:137 -msgid "Then, create a file that ends in ``.gcp.yml`` in your root directory." -msgstr "次に、root ディレクトリーに、名前の末尾が ``.gcp.yml`` で終わるファイルを作成します。" - -#: ../../rst/scenario_guides/guide_gce.rst:139 -msgid "The gcp_compute inventory script takes in the same authentication information as any module." -msgstr "gcp_compute スクリプトは、モジュールと同じ認証情報を取得します。" - -#: ../../rst/scenario_guides/guide_gce.rst:141 -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:39 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:41 -msgid "Here's an example of a valid inventory file:" -msgstr "以下は、有効なインベントリーファイルの例です。" - -#: ../../rst/scenario_guides/guide_gce.rst:152 -msgid "Executing ``ansible-inventory --list -i .gcp.yml`` will create a list of GCP instances that are ready to be configured using Ansible." -msgstr "``ansible-inventory --list -i .gcp.yml`` を実行すると、Ansible を使用して設定する準備ができている GCP インスタンスの一覧が作成されます。" - -#: ../../rst/scenario_guides/guide_gce.rst:155 -msgid "Create an instance" -msgstr "インスタンスの作成" - -#: ../../rst/scenario_guides/guide_gce.rst:157 -msgid "The full range of GCP modules provide the ability to create a wide variety of GCP resources with the full support of the entire GCP API." -msgstr "GCP モジュールの全範囲により、GCP API 全体の完全なサポートにより、さまざまな GCP リソースを作成することができます。" - -#: ../../rst/scenario_guides/guide_gce.rst:160 -msgid "The following playbook creates a GCE Instance. This instance relies on other GCP resources like Disk. By creating other resources separately, we can give as much detail as necessary about how we want to configure the other resources, for example formatting of the Disk. By registering it to a variable, we can simply insert the variable into the instance task. The gcp_compute_instance module will figure out the rest." -msgstr "以下の Playbook は GCE インスタンスを作成します。このインスタンスは、Disk などの他の GCP リソースに依存します。他のリソースを個別に作成すると、ディスクのフォーマットなど、他のリソースの設定方法を必要なだけ提供できます。これを変数に登録すると、その変数をインスタンスタスクに挿入することができます。gcp_compute_instance モジュールは、残りを確認できます。" - -#: ../../rst/scenario_guides/guide_gce.rst:242 -msgid "Note that use of the \"add_host\" module above creates a temporary, in-memory group. This means that a play in the same playbook can then manage machines in the 'new_instances' group, if so desired. Any sort of arbitrary configuration is possible at this point." -msgstr "上記の「add_host」モジュールを使用すると、一時的なインメモリーグループが作成されます。これは、同じ Playbook 内のプレイが「new_instances」グループ内のマシンを管理できることを意味します。この時点で任意の設定が可能です。" - -#: ../../rst/scenario_guides/guide_gce.rst:245 -msgid "For more information about Google Cloud, please visit the `Google Cloud website `_." -msgstr "Google Cloud の詳細は、`Google Cloud Web サイト `_ を参照してください。" - -#: ../../rst/scenario_guides/guide_gce.rst:248 -msgid "Migration Guides" -msgstr "移行ガイド" - -#: ../../rst/scenario_guides/guide_gce.rst:251 -msgid "gce.py -> gcp_compute_instance.py" -msgstr "gce.py -> gcp_compute_instance.py" - -#: ../../rst/scenario_guides/guide_gce.rst:252 -msgid "As of Ansible 2.8, we're encouraging everyone to move from the ``gce`` module to the ``gcp_compute_instance`` module. The ``gcp_compute_instance`` module has better support for all of GCP's features, fewer dependencies, more flexibility, and better supports GCP's authentication systems." -msgstr "Ansible 2.8 では、すべてのユーザーが ``gce`` モジュールから ``gcp_compute_instance`` モジュールに移行することを推奨しています。``gcp_compute_instance`` モジュールは、すべての GCP の機能のサポートと、依存関係が少なく、柔軟性が高い、GCP の認証システムにもより良いサポートを提供します。" - -#: ../../rst/scenario_guides/guide_gce.rst:257 -msgid "The ``gcp_compute_instance`` module supports all of the features of the ``gce`` module (and more!). Below is a mapping of ``gce`` fields over to ``gcp_compute_instance`` fields." -msgstr "``gcp_compute_instance`` モジュールは、``gce`` モジュール (およびそれ以上) のすべての機能をサポートします。これは、``gce`` フィールドから ``gcp_compute_instance`` フィールドへのマッピングです。" - -#: ../../rst/scenario_guides/guide_gce.rst:262 -msgid "gce.py" -msgstr "gce.py" - -#: ../../rst/scenario_guides/guide_gce.rst:262 -msgid "gcp_compute_instance.py" -msgstr "gcp_compute_instance.py" - -#: ../../rst/scenario_guides/guide_gce.rst:262 -msgid "Notes" -msgstr "備考" - -#: ../../rst/scenario_guides/guide_gce.rst:264 -#: ../../rst/scenario_guides/guide_meraki.rst:91 -msgid "state" -msgstr "state" - -#: ../../rst/scenario_guides/guide_gce.rst:264 -msgid "state/status" -msgstr "state/status" - -#: ../../rst/scenario_guides/guide_gce.rst:264 -msgid "State on gce has multiple values: \"present\", \"absent\", \"stopped\", \"started\", \"terminated\". State on gcp_compute_instance is used to describe if the instance exists (present) or does not (absent). Status is used to describe if the instance is \"started\", \"stopped\" or \"terminated\"." -msgstr "gce の状態には、複数の値 (「present」、「absent」、「stopped」、「started」、「terminated」) があります。gcp_compute_instance は、インスタンスが存在するか (present) か、そうでないか (absent) を示します。ステータスは、インスタンスが「started」、「stopped」、または「terminated」であるかを説明するために使用されます。" - -#: ../../rst/scenario_guides/guide_gce.rst:265 -msgid "image" -msgstr "image" - -#: ../../rst/scenario_guides/guide_gce.rst:265 -#: ../../rst/scenario_guides/guide_gce.rst:266 -#: ../../rst/scenario_guides/guide_gce.rst:267 -msgid "disks[].initialize_params.source_image" -msgstr "disks[].initialize_params.source_image" - -#: ../../rst/scenario_guides/guide_gce.rst:265 -msgid "You'll need to create a single disk using the disks[] parameter and set it to be the boot disk (disks[].boot = true)" -msgstr "disks[] パラメーターを使用してディスクを 1 つ作成し、それをブートディスクに設定する必要があります (disks[].boot = true)。" - -#: ../../rst/scenario_guides/guide_gce.rst:266 -msgid "image_family" -msgstr "image_family" - -#: ../../rst/scenario_guides/guide_gce.rst:266 -msgid "See above." -msgstr "上記を参照してください。" - -#: ../../rst/scenario_guides/guide_gce.rst:267 -msgid "external_projects" -msgstr "external_projects" - -#: ../../rst/scenario_guides/guide_gce.rst:267 -msgid "The name of the source_image will include the name of the project." -msgstr "source_image の名前には、プロジェクトの名前が含まれます。" - -#: ../../rst/scenario_guides/guide_gce.rst:268 -msgid "instance_names" -msgstr "instance_names" - -#: ../../rst/scenario_guides/guide_gce.rst:268 -msgid "Use a loop or multiple tasks." -msgstr "ループまたは複数のタスクを使用します。" - -#: ../../rst/scenario_guides/guide_gce.rst:268 -msgid "Using loops is a more Ansible-centric way of creating multiple instances and gives you the most flexibility." -msgstr "ループの使用は、複数のインスタンスを作成するよりも Ansible に適した方法で、柔軟性が最も高くなります。" - -#: ../../rst/scenario_guides/guide_gce.rst:269 -msgid "service_account_email" -msgstr "service_account_email" - -#: ../../rst/scenario_guides/guide_gce.rst:269 -msgid "service_accounts[].email" -msgstr "service_accounts[].email" - -#: ../../rst/scenario_guides/guide_gce.rst:269 -msgid "This is the service_account email address that you want the instance to be associated with. It is not the service_account email address that is used for the credentials necessary to create the instance." -msgstr "これは、インスタンスが関連付けられる service_account のメールアドレスです。インスタンスの作成に必要な認証情報に使用される service_account のメールアドレスではありません。" - -#: ../../rst/scenario_guides/guide_gce.rst:270 -msgid "service_account_permissions" -msgstr "service_account_permissions" - -#: ../../rst/scenario_guides/guide_gce.rst:270 -msgid "service_accounts[].scopes" -msgstr "service_accounts[].scopes" - -#: ../../rst/scenario_guides/guide_gce.rst:270 -msgid "These are the permissions you want to grant to the instance." -msgstr "これらは、インスタンスに付与するパーミッションです。" - -#: ../../rst/scenario_guides/guide_gce.rst:271 -msgid "pem_file" -msgstr "pem_file" - -#: ../../rst/scenario_guides/guide_gce.rst:271 -msgid "Not supported." -msgstr "サポート対象外。" - -#: ../../rst/scenario_guides/guide_gce.rst:271 -msgid "We recommend using JSON service account credentials instead of PEM files." -msgstr "PEM ファイルの代わりに JSON サービスアカウントの認証情報を使用することが推奨されます。" - -#: ../../rst/scenario_guides/guide_gce.rst:272 -msgid "credentials_file" -msgstr "credentials_file" - -#: ../../rst/scenario_guides/guide_gce.rst:272 -msgid "service_account_file" -msgstr "service_account_file" - -#: ../../rst/scenario_guides/guide_gce.rst:273 -msgid "project_id" -msgstr "project_id" - -#: ../../rst/scenario_guides/guide_gce.rst:273 -msgid "project" -msgstr "project" - -#: ../../rst/scenario_guides/guide_gce.rst:274 -msgid "name" -msgstr "name" - -#: ../../rst/scenario_guides/guide_gce.rst:274 -msgid "This field does not accept an array of names. Use a loop to create multiple instances." -msgstr "このフィールドは名前の配列を受け入れません。複数インスタンスを作成するにはループを使用します。" - -#: ../../rst/scenario_guides/guide_gce.rst:275 -msgid "num_instances" -msgstr "num_instances" - -#: ../../rst/scenario_guides/guide_gce.rst:275 -msgid "Use a loop" -msgstr "ループの使用" - -#: ../../rst/scenario_guides/guide_gce.rst:275 -msgid "For maximum flexibility, we're encouraging users to use Ansible features to create multiple instances, rather than letting the module do it for you." -msgstr "最大限の柔軟性を得るには、モジュールに任せず、Ansible 機能を使用して複数のインスタンスを作成することを推奨しています。" - -#: ../../rst/scenario_guides/guide_gce.rst:276 -msgid "network" -msgstr "network" - -#: ../../rst/scenario_guides/guide_gce.rst:276 -msgid "network_interfaces[].network" -msgstr "network_interfaces[].network" - -#: ../../rst/scenario_guides/guide_gce.rst:277 -msgid "subnetwork" -msgstr "subnetwork" - -#: ../../rst/scenario_guides/guide_gce.rst:277 -msgid "network_interfaces[].subnetwork" -msgstr "network_interfaces[].subnetwork" - -#: ../../rst/scenario_guides/guide_gce.rst:278 -msgid "persistent_boot_disk" -msgstr "persistent_boot_disk" - -#: ../../rst/scenario_guides/guide_gce.rst:278 -msgid "disks[].type = 'PERSISTENT'" -msgstr "disks[].type = 'PERSISTENT'" - -#: ../../rst/scenario_guides/guide_gce.rst:279 -msgid "disks" -msgstr "disks" - -#: ../../rst/scenario_guides/guide_gce.rst:279 -msgid "disks[]" -msgstr "disks[]" - -#: ../../rst/scenario_guides/guide_gce.rst:280 -msgid "ip_forward" -msgstr "ip_forward" - -#: ../../rst/scenario_guides/guide_gce.rst:280 -msgid "can_ip_forward" -msgstr "can_ip_forward" - -#: ../../rst/scenario_guides/guide_gce.rst:281 -msgid "external_ip" -msgstr "external_ip" - -#: ../../rst/scenario_guides/guide_gce.rst:281 -msgid "network_interfaces[].access_configs.nat_ip" -msgstr "network_interfaces[].access_configs.nat_ip" - -#: ../../rst/scenario_guides/guide_gce.rst:281 -msgid "This field takes multiple types of values. You can create an IP address with ``gcp_compute_address`` and place the name/output of the address here. You can also place the string value of the IP address's GCP name or the actual IP address." -msgstr "このフィールドは、複数のタイプの値を取ります。``gcp_compute_address`` で IP アドレスを作成し、そのアドレスの名前/出力をここに入力します。IP アドレスの GCP 名または実際の IP アドレスの文字列値を入力することもできます。" - -#: ../../rst/scenario_guides/guide_gce.rst:282 -msgid "disks_auto_delete" -msgstr "disks_auto_delete" - -#: ../../rst/scenario_guides/guide_gce.rst:282 -msgid "disks[].auto_delete" -msgstr "disks[].auto_delete" - -#: ../../rst/scenario_guides/guide_gce.rst:283 -msgid "preemptible" -msgstr "preemptible" - -#: ../../rst/scenario_guides/guide_gce.rst:283 -msgid "scheduling.preemptible" -msgstr "scheduling.preemptible" - -#: ../../rst/scenario_guides/guide_gce.rst:284 -msgid "disk_size" -msgstr "disk_size" - -#: ../../rst/scenario_guides/guide_gce.rst:284 -msgid "disks[].initialize_params.disk_size_gb" -msgstr "disks[].initialize_params.disk_size_gb" - -#: ../../rst/scenario_guides/guide_gce.rst:287 -msgid "An example playbook is below:" -msgstr "Playbook の例を以下に示します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:5 -msgid "Infoblox Guide" -msgstr "Infoblox ガイド" - -#: ../../rst/scenario_guides/guide_infoblox.rst:7 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/scenario_guides/guide_infoblox.rst:9 -msgid "This guide describes how to use Ansible with the Infoblox Network Identity Operating System (NIOS). With Ansible integration, you can use Ansible playbooks to automate Infoblox Core Network Services for IP address management (IPAM), DNS, and inventory tracking." -msgstr "本ガイドでは、Infoblox NIOS (Network Identity Operating System) で Ansible を使用する方法を説明します。Ansible 統合では、Ansible Playbook を使用して、IP アドレス管理 (IPAM)、DNS、およびインベントリー追跡について Infoblox Core Network Services を自動化できます。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:11 -msgid "You can review simple example tasks in the documentation for any of the :ref:`NIOS modules ` or look at the `Use cases with modules`_ section for more elaborate examples. See the `Infoblox `_ website for more information on the Infoblox product." -msgstr "簡単なタスクの例については、:ref:`NIOS モジュール ` のいずれかについてのドキュメントを参照するか、`モジュールのユースケース`_ セクションを参照してタスクの例を確認してください。Infoblox 製品の詳細は、`Infoblox `_ の Web サイトを参照してください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:13 -msgid "You can retrieve most of the example playbooks used in this guide from the `network-automation/infoblox_ansible `_ GitHub repository." -msgstr "本ガイドで使用されている Playbook サンプルの大半は、`network-automation/infoblox_ansible `_ GitHub リポジトリーから取得できます。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:17 -msgid "Before using Ansible ``nios`` modules with Infoblox, you must install the ``infoblox-client`` on your Ansible control node:" -msgstr "Infoblox で Ansible ``nios`` モジュールを使用する前に、Ansible コントロールノードに ``infoblox-client`` をインストールする必要があります。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:24 -msgid "You need an NIOS account with the WAPI feature enabled to use Ansible with Infoblox." -msgstr "Infoblox で Ansible を使用するには、WAPI 機能が有効になっている NIOS アカウントが必要です。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:29 -#: ../../rst/scenario_guides/scenario_template.rst:22 -msgid "Credentials and authenticating" -msgstr "認証情報および認証" - -#: ../../rst/scenario_guides/guide_infoblox.rst:31 -msgid "To use Infoblox ``nios`` modules in playbooks, you need to configure the credentials to access your Infoblox system. The examples in this guide use credentials stored in ``/group_vars/nios.yml``. Replace these values with your Infoblox credentials:" -msgstr "Playbook で Infoblox ``nios`` モジュールを使用するには、Infoblox システムにアクセスするための認証情報を設定する必要があります。本ガイドの例では、``/group_vars/nios.yml`` に保存されている認証情報を使用します。この値をお使いの Infoblox 認証情報に置き換えます。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:42 -msgid "NIOS lookup plugins" -msgstr "NIOS Lookup プラグイン" - -#: ../../rst/scenario_guides/guide_infoblox.rst:44 -msgid "Ansible includes the following lookup plugins for NIOS:" -msgstr "Ansible には、NIOS 用に以下の lookup プラグインが含まれます。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:46 -msgid ":ref:`nios ` Uses the Infoblox WAPI API to fetch NIOS specified objects, for example network views, DNS views, and host records." -msgstr ":ref:`nios ` Infoblox WAPI API を使用して NIOS が指定されたオブジェクト (ネットワークビュー、DNS ビュー、ホストレコードなど) を取得します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:47 -msgid ":ref:`nios_next_ip ` Provides the next available IP address from a network. You'll see an example of this in `Creating a host record`_." -msgstr ":ref:`nios_next_ip ` は、ネットワークから次に利用可能な IP アドレスを提供します。「`ホストレコードの作成`_」に、この例を示します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:48 -msgid ":ref:`nios_next_network ` - Returns the next available network range for a network-container." -msgstr ":ref:`nios_next_network ` - ネットワークコンテナーの次に利用可能なネットワーク範囲を返します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:50 -msgid "You must run the NIOS lookup plugins locally by specifying ``connection: local``. See :ref:`lookup plugins ` for more detail." -msgstr "``connection: local`` を指定して NIOS ルックアッププラグインをローカルで実行する必要があります。詳細は「:ref:`lookup プラグイン `」を参照してください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:54 -msgid "Retrieving all network views" -msgstr "すべてのネットワークビューの取得" - -#: ../../rst/scenario_guides/guide_infoblox.rst:56 -msgid "To retrieve all network views and save them in a variable, use the :ref:`set_fact ` module with the :ref:`nios ` lookup plugin:" -msgstr "すべてのネットワークビューを取得して変数に保存するには、:ref:`nios ` ルックアッププラグインで :ref:`set_fact ` モジュールを使用します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:74 -msgid "Retrieving a host record" -msgstr "ホストレコードの取得" - -#: ../../rst/scenario_guides/guide_infoblox.rst:76 -msgid "To retrieve a set of host records, use the ``set_fact`` module with the ``nios`` lookup plugin and include a filter for the specific hosts you want to retrieve:" -msgstr "ホストレコードのセットを取得するには、``nios`` ルックアッププラグインで ``set_fact`` モジュールを使用し、取得する特定ホストのフィルターを追加します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:105 -msgid "If you run this ``get_host_record.yml`` playbook, you should see results similar to the following:" -msgstr "この ``get_host_record.yml`` Playbook を実行すると、以下のような結果が表示されるはずです。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:156 -msgid "The output above shows the host record for ``leaf01.ansible.com`` and ``leaf02.ansible.com`` that were retrieved by the ``nios`` lookup plugin. This playbook saves the information in variables which you can use in other playbooks. This allows you to use Infoblox as a single source of truth to gather and use information that changes dynamically. See :ref:`playbooks_variables` for more information on using Ansible variables. See the :ref:`nios ` examples for more data options that you can retrieve." -msgstr "上記の出力には、``nios`` ルックアッププラグインによって取得された ``leaf01.ansible.com`` および ``leaf02.ansible.com`` のホストレコードが表示されます。この Playbook は、他の Playbook で使用できる変数に情報を保存します。これにより、Infoblox を信頼できる単一のソースとして使用し、動的に変更する情報を収集し、使用できます。Ansible 変数の使用の詳細は、「:ref:`playbooks_variables`」を参照してください。取得できるその他のデータオプションは、「:ref:`nios `」の例を参照してください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:158 -msgid "You can access these playbooks at `Infoblox lookup playbooks `_." -msgstr "この Playbook には、「`Infoblox lookup playbooks `_」からアクセスできます。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:161 -msgid "Use cases with modules" -msgstr "モジュールを使用したユースケース" - -#: ../../rst/scenario_guides/guide_infoblox.rst:163 -msgid "You can use the ``nios`` modules in tasks to simplify common Infoblox workflows. Be sure to set up your :ref:`NIOS credentials` before following these examples." -msgstr "``nios`` モジュールをタスクで使用すると、共通の Infoblox ワークフローを単純化できます。これらの例を行う前に、「:ref:`NIOS 認証情報`」を設定するようにしてください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:166 -msgid "Configuring an IPv4 network" -msgstr "IPv4 ネットワークの設定" - -#: ../../rst/scenario_guides/guide_infoblox.rst:168 -msgid "To configure an IPv4 network, use the :ref:`nios_network ` module:" -msgstr "IPv4 ネットワークを設定するには、:ref:`nios_network ` モジュールを使用します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:186 -msgid "Notice the last parameter, ``provider``, uses the variable ``nios_provider`` defined in the ``group_vars/`` directory." -msgstr "最後のパラメーター ``provider`` は、``nios_provider`` ディレクトリーで定義されている ``group_vars/`` 変数を使用することに注意してください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:189 -msgid "Creating a host record" -msgstr "ホストレコードの作成" - -#: ../../rst/scenario_guides/guide_infoblox.rst:191 -msgid "To create a host record named `leaf03.ansible.com` on the newly-created IPv4 network:" -msgstr "新たに作成した IPv4 ネットワーク上で `leaf03.ansible.com` という名前のホストレコードを作成するには、次を実行します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:208 -msgid "Notice the IPv4 address in this example uses the :ref:`nios_next_ip ` lookup plugin to find the next available IPv4 address on the network." -msgstr "この例の IPv4 アドレスは、:ref:`nios_next_ip ` lookup プラグインを使用して、ネットワーク上で次に利用可能な IPv4 アドレスを検索します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:211 -msgid "Creating a forward DNS zone" -msgstr "正引き DNS ゾーンの作成" - -#: ../../rst/scenario_guides/guide_infoblox.rst:213 -msgid "To configure a forward DNS zone use, the ``nios_zone`` module:" -msgstr "正引き DNS ゾーンを設定するには、``nios_zone`` モジュールを使用します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:229 -msgid "Creating a reverse DNS zone" -msgstr "逆引き DNS ゾーンの作成" - -#: ../../rst/scenario_guides/guide_infoblox.rst:231 -msgid "To configure a reverse DNS zone:" -msgstr "逆引き DNS ゾーンを設定するには、以下を行います。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:247 -msgid "Dynamic inventory script" -msgstr "動的インベントリースクリプト" - -#: ../../rst/scenario_guides/guide_infoblox.rst:249 -msgid "You can use the Infoblox dynamic inventory script to import your network node inventory with Infoblox NIOS. To gather the inventory from Infoblox, you need two files:" -msgstr "Infoblox 動的インベントリースクリプトを使用して、Infoblox NIOS でネットワークノードのインベントリーをインポートできます。Infoblox からインベントリーを収集するには、以下の 2 つのファイルが必要です。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:251 -msgid "`infoblox.yaml `_ - A file that specifies the NIOS provider arguments and optional filters." -msgstr "`infoblox.yaml `_ - NIOS プロバイダー引数および任意のフィルターを指定するファイル。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:253 -msgid "`infoblox.py `_ - The python script that retrieves the NIOS inventory." -msgstr "`infoblox.py `_ - NIOS インベントリーを取得する python スクリプト。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:257 -msgid "Please note that the inventory script only works when Ansible 2.9, 2.10 or 3 have been installed. The inventory script will eventually be removed from `community.general `_, and will not work if `community.general` is only installed with `ansible-galaxy collection install`. Please use the inventory plugin from `infoblox.nios_modules `_ instead." -msgstr "インベントリースクリプトは、Ansible 2.9、2.10、または 3 がインストールされた場合にのみ機能することに注意してください。インベントリースクリプトは最終的に `community.general `_ から削除され、`community.general` が `ansible-galaxy collection install` と共にインストールされている場合に限り動作しません。代わりに `infoblox.nios_modules `_ からインベントリープラグインを使用してください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:259 -msgid "To use the Infoblox dynamic inventory script:" -msgstr "Infoblox 動的インベントリースクリプトを使用するには、以下を実行します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:261 -msgid "Download the ``infoblox.yaml`` file and save it in the ``/etc/ansible`` directory." -msgstr "``infoblox.yaml`` ファイルをダウンロードして、``/etc/ansible`` ディレクトリーに保存します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:263 -msgid "Modify the ``infoblox.yaml`` file with your NIOS credentials." -msgstr "NIOS 認証情報を使用して ``infoblox.yaml`` ファイルを変更します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:265 -msgid "Download the ``infoblox.py`` file and save it in the ``/etc/ansible/hosts`` directory." -msgstr "``infoblox.py`` ファイルをダウンロードして、``/etc/ansible/hosts`` ディレクトリーに保存します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:267 -msgid "Change the permissions on the ``infoblox.py`` file to make the file an executable:" -msgstr "``infoblox.py`` ファイルのパーミッションを変更して、ファイルを実行可能にします。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:273 -msgid "You can optionally use ``./infoblox.py --list`` to test the script. After a few minutes, you should see your Infoblox inventory in JSON format. You can explicitly use the Infoblox dynamic inventory script as follows:" -msgstr "必要に応じて ``./infoblox.py --list`` を使用してスクリプトをテストすることができます。数分後、JSON 形式で Infoblox インベントリーが表示されるはずです。以下のように Infoblox 動的インベントリースクリプトを明示的に使用できます。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:279 -msgid "You can also implicitly use the Infoblox dynamic inventory script by including it in your inventory directory (``etc/ansible/hosts`` by default). See :ref:`dynamic_inventory` for more details." -msgstr "また、インベントリーディレクトリー (``etc/ansible/hosts`` がデフォルト) に追加して Infoblox 動的インベントリースクリプトを暗黙的で使用することもできます。詳細は「:ref:`dynamic_inventory`」を参照してください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:283 -msgid "`Infoblox website `_" -msgstr "`Infoblox Web サイト `_" - -#: ../../rst/scenario_guides/guide_infoblox.rst:284 -msgid "The Infoblox website" -msgstr "Infoblox の Web サイト" - -#: ../../rst/scenario_guides/guide_infoblox.rst:285 -msgid "`Infoblox and Ansible Deployment Guide `_" -msgstr "`Infoblox and Ansible Deployment Guide `_" - -#: ../../rst/scenario_guides/guide_infoblox.rst:286 -msgid "The deployment guide for Ansible integration provided by Infoblox." -msgstr "Infoblox が提供する Ansible 統合のデプロイメントガイド" - -#: ../../rst/scenario_guides/guide_infoblox.rst:287 -msgid "`Infoblox Integration in Ansible 2.5 `_" -msgstr "`Infoblox Integration in Ansible 2.5 `_" - -#: ../../rst/scenario_guides/guide_infoblox.rst:288 -msgid "Ansible blog post about Infoblox." -msgstr "Infoblox に関する Ansible ブログ投稿" - -#: ../../rst/scenario_guides/guide_infoblox.rst:289 -msgid ":ref:`Ansible NIOS modules `" -msgstr ":ref:`Ansible NIOS modules `" - -#: ../../rst/scenario_guides/guide_infoblox.rst:290 -msgid "The list of supported NIOS modules, with examples." -msgstr "対応している NIOS モジュールの一覧 (サンプルあり)" - -#: ../../rst/scenario_guides/guide_infoblox.rst:291 -msgid "`Infoblox Ansible Examples `_" -msgstr "`Infoblox Ansible Examples `_" - -#: ../../rst/scenario_guides/guide_infoblox.rst:292 -msgid "Infoblox example playbooks." -msgstr "Infoblox の Playbook サンプル" - -#: ../../rst/scenario_guides/guide_kubernetes.rst:5 -msgid "Kubernetes Guide" -msgstr "Kubernetes ゲスト" - -#: ../../rst/scenario_guides/guide_kubernetes.rst:7 -msgid "Welcome to the Ansible for Kubernetes Guide!" -msgstr "Kubernetes 向け Ansible ガイドにようこそ!" - -#: ../../rst/scenario_guides/guide_kubernetes.rst:9 -msgid "The purpose of this guide is to teach you everything you need to know about using Ansible with Kubernetes." -msgstr "本ガイドの目的は、Kubernetes での Ansible の使用について理解しておく必要があります。" - -#: ../../rst/scenario_guides/guide_kubernetes.rst:11 -#: ../../rst/scenario_guides/guide_vmware.rst:11 -msgid "To get started, please select one of the following topics." -msgstr "最初に以下のトピックのいずれかを選択してください。" - -#: ../../rst/scenario_guides/guide_meraki.rst:5 -msgid "Cisco Meraki Guide" -msgstr "Cisco Meraki ガイド" - -#: ../../rst/scenario_guides/guide_meraki.rst:14 -msgid "What is Cisco Meraki?" -msgstr "Cisco Meraki とは" - -#: ../../rst/scenario_guides/guide_meraki.rst:16 -msgid "Cisco Meraki is an easy-to-use, cloud-based, network infrastructure platform for enterprise environments. While most network hardware uses command-line interfaces (CLIs) for configuration, Meraki uses an easy-to-use Dashboard hosted in the Meraki cloud. No on-premises management hardware or software is required - only the network infrastructure to run your business." -msgstr "Cisco Meraki は、エンタープライズ環境向けの使いやすいクラウドベースのネットワークインフラストラクチャープラットフォームです。ほとんどのネットワークハードウェアは、設定にコマンドラインインターフェース (CLI) を使用しますが、Meraki は Meraki クラウドでホストされる使いやすい Dashboard を使用します。オンプレミスの管理用ハードウェアやソフトウェアは必要なく、ビジネスに必要なネットワークインフラストラクチャーのみが用意されています。" - -#: ../../rst/scenario_guides/guide_meraki.rst:19 -msgid "MS Switches" -msgstr "MS スイッチ" - -#: ../../rst/scenario_guides/guide_meraki.rst:21 -msgid "Meraki MS switches come in multiple flavors and form factors. Meraki switches support 10/100/1000/10000 ports, as well as Cisco's mGig technology for 2.5/5/10Gbps copper connectivity. 8, 24, and 48 port flavors are available with PoE (802.3af/802.3at/UPoE) available on many models." -msgstr "Meraki MS スイッチには複数のフレーバーおよび形式要素があります。Meraki スイッチは、10/100/1000/10000 ポートと、2.5/5/10 Gbps のカッパー接続用である Cisco 社の mGig テクノロジーに対応しています。8、24、および 48 のポートフレーバーは、多くのモデルで利用可能な PoE (802.3af/802.3at/UPoE) で利用できます。" - -#: ../../rst/scenario_guides/guide_meraki.rst:24 -msgid "MX Firewalls" -msgstr "MX ファイアウォール" - -#: ../../rst/scenario_guides/guide_meraki.rst:26 -msgid "Meraki's MX firewalls support full layer 3-7 deep packet inspection. MX firewalls are compatible with a variety of VPN technologies including IPSec, SSL VPN, and Meraki's easy-to-use AutoVPN." -msgstr "Meraki の MX ファイアウォールは、レイヤー 3 から 7 のディープパケット検査をサポートします。MX ファイアウォールは、IPsec、SSL VPN、および Meraki の使いやすい AutoVPN など、さまざまな VPN テクノロジーと互換性があります。" - -#: ../../rst/scenario_guides/guide_meraki.rst:29 -msgid "MR Wireless Access Points" -msgstr "MR ワイヤレスアクセスポイント" - -#: ../../rst/scenario_guides/guide_meraki.rst:31 -msgid "MR access points are enterprise-class, high-performance access points for the enterprise. MR access points have MIMO technology and integrated beamforming built-in for high performance applications. BLE allows for advanced location applications to be developed with no on-premises analytics platforms." -msgstr "MR アクセスポイントは、エンタープライズクラスの高パフォーマンスのアクセスポイントです。MR アクセスポイントには、高性能アプリケーション向けに、MIMO テクノロジーと統合ビームフォーマーが組み込まれています。BLE は、オンプレミスの解析プラットフォームを使用せずに高度なロケーションアプリケーションを開発できるようにします。" - -#: ../../rst/scenario_guides/guide_meraki.rst:34 -msgid "Using the Meraki modules" -msgstr "Meraki モジュールの使用" - -#: ../../rst/scenario_guides/guide_meraki.rst:36 -msgid "Meraki modules provide a user-friendly interface to manage your Meraki environment using Ansible. For example, details about SNMP settings for a particular organization can be discovered using the module `meraki_snmp `." -msgstr "Meraki モジュールは、Ansible を使用して Meraki 環境を管理するユーザーフレンドリーなインターフェースを提供します。たとえば、特定の組織の SNMP 設定の詳細は、`meraki_snmp ` モジュールを使用して検出できます。" - -#: ../../rst/scenario_guides/guide_meraki.rst:47 -msgid "Information about a particular object can be queried. For example, the `meraki_admin ` module supports" -msgstr "特定のオブジェクトに関する情報をクエリーできます。たとえば、`meraki_admin ` モジュールがサポートするものです。" - -#: ../../rst/scenario_guides/guide_meraki.rst:60 -msgid "Common Parameters" -msgstr "一般的なパラメーター" - -#: ../../rst/scenario_guides/guide_meraki.rst:62 -msgid "All Ansible Meraki modules support the following parameters which affect communication with the Meraki Dashboard API. Most of these should only be used by Meraki developers and not the general public." -msgstr "すべての Ansible Meraki モジュールは、Meraki Dashboard API との通信に影響する以下のパラメーターに対応します。これらのほとんどは、一般的には使用するものではなく、Meraki 開発者が使用するためのものです。" - -#: ../../rst/scenario_guides/guide_meraki.rst:65 -msgid "Hostname or IP of Meraki Dashboard." -msgstr "Meraki Dashboard のホスト名または IP。" - -#: ../../rst/scenario_guides/guide_meraki.rst:68 -msgid "use_https" -msgstr "use_https" - -#: ../../rst/scenario_guides/guide_meraki.rst:68 -msgid "Specifies whether communication should be over HTTPS. (Defaults to ``yes``)" -msgstr "通信が HTTPS を使用するかどうかを指定します (デフォルトは ``yes``)。" - -#: ../../rst/scenario_guides/guide_meraki.rst:71 -msgid "Whether to use a proxy for any communication." -msgstr "通信にプロキシーを使用するかどうか。" - -#: ../../rst/scenario_guides/guide_meraki.rst:74 -msgid "Determine whether certificates should be validated or trusted. (Defaults to ``yes``)" -msgstr "証明書を検証すべきか、それとも信用すべきを指定します (デフォルトは ``yes``)。" - -#: ../../rst/scenario_guides/guide_meraki.rst:76 -msgid "These are the common parameters which are used for most every module." -msgstr "以下は、大抵のモジュールに使用される一般的なパラメーターです。" - -#: ../../rst/scenario_guides/guide_meraki.rst:79 -msgid "org_name" -msgstr "org_name" - -#: ../../rst/scenario_guides/guide_meraki.rst:79 -msgid "Name of organization to perform actions in." -msgstr "アクションを実行する組織の名前。" - -#: ../../rst/scenario_guides/guide_meraki.rst:82 -msgid "org_id" -msgstr "org_id" - -#: ../../rst/scenario_guides/guide_meraki.rst:82 -msgid "ID of organization to perform actions in." -msgstr "アクションを実行する組織の ID。" - -#: ../../rst/scenario_guides/guide_meraki.rst:85 -msgid "net_name" -msgstr "net_name" - -#: ../../rst/scenario_guides/guide_meraki.rst:85 -msgid "Name of network to perform actions in." -msgstr "アクションを実行するネットワークの名前。" - -#: ../../rst/scenario_guides/guide_meraki.rst:88 -msgid "net_id" -msgstr "net_id" - -#: ../../rst/scenario_guides/guide_meraki.rst:88 -msgid "ID of network to perform actions in." -msgstr "アクションを実行するネットワークの ID。" - -#: ../../rst/scenario_guides/guide_meraki.rst:91 -msgid "General specification of what action to take. ``query`` does lookups. ``present`` creates or edits. ``absent`` deletes." -msgstr "実行するアクションに関する一般的な仕様。``query`` は検索を行い、``present`` は作成または編集を行います。``absent`` は削除します。" - -#: ../../rst/scenario_guides/guide_meraki.rst:93 -msgid "Use the ``org_id`` and ``net_id`` parameters when possible. ``org_name`` and ``net_name`` require additional behind-the-scenes API calls to learn the ID values. ``org_id`` and ``net_id`` will perform faster." -msgstr "可能な場合は、``org_id`` パラメーターおよび ``net_id`` パラメーターを使用します。``org_name`` および ``net_name``は、ID 値を確認するために、その裏で追加の API 呼び出しが必要です。``org_id`` および ``net_id`` の動作はより速くなります。" - -#: ../../rst/scenario_guides/guide_meraki.rst:96 -msgid "Meraki Authentication" -msgstr "Meraki 認証" - -#: ../../rst/scenario_guides/guide_meraki.rst:98 -msgid "All API access with the Meraki Dashboard requires an API key. An API key can be generated from the organization's settings page. Each play in a playbook requires the ``api_key`` parameter to be specified." -msgstr "Meraki Dashboard を使用した API アクセスはすべて API キーを必要とします。API キーは組織の設定ページから生成できます。Playbook の各プレイには ``api_key`` パラメーターを指定する必要があります。" - -#: ../../rst/scenario_guides/guide_meraki.rst:102 -msgid "Meraki's API returns a 404 error if the API key is not correct. It does not provide any specific error saying the key is incorrect. If you receive a 404 error, check the API key first." -msgstr "API キーが正しくない場合は、Meraki の API が 404 エラーを返します。キーが正しくないことを示す特定のエラーは提供されません。404 エラーを受け取った場合は、最初に API キーを確認してください。" - -#: ../../rst/scenario_guides/guide_meraki.rst:105 -msgid "Returned Data Structures" -msgstr "返されたデータ構造" - -#: ../../rst/scenario_guides/guide_meraki.rst:107 -msgid "Meraki and its related Ansible modules return most information in the form of a list. For example, this is returned information by ``meraki_admin`` querying administrators. It returns a list even though there's only one." -msgstr "Meraki とその関連 Ansible モジュールは、リスト形式でほとんどの情報を返します。たとえば、これは、管理者のクエリーを行う ``meraki_admin`` により情報を返します。管理者が 1 人しかいなくても一覧を返します。" - -#: ../../rst/scenario_guides/guide_meraki.rst:123 -msgid "Handling Returned Data" -msgstr "返されたデータの処理" - -#: ../../rst/scenario_guides/guide_meraki.rst:125 -msgid "Since Meraki's response data uses lists instead of properly keyed dictionaries for responses, certain strategies should be used when querying data for particular information. For many situations, use the ``selectattr()`` Jinja2 function." -msgstr "Meraki の応答データは応答に適切に鍵付けされたディクショナリーではなくリストを使用するため、特定情報に対してデータのクエリーを行う際に特定のストラテジーを使用する必要があります。多くの状況では、Jinja2 機能 ``selectattr()`` を使用します。" - -#: ../../rst/scenario_guides/guide_meraki.rst:128 -msgid "Merging Existing and New Data" -msgstr "既存データと新規データのマージ" - -#: ../../rst/scenario_guides/guide_meraki.rst:130 -msgid "Ansible's Meraki modules do not allow for manipulating data. For example, you may need to insert a rule in the middle of a firewall ruleset. Ansible and the Meraki modules lack a way to directly merge to manipulate data. However, a playlist can use a few tasks to split the list where you need to insert a rule and then merge them together again with the new rule added. The steps involved are as follows:" -msgstr "Ansible の Meraki モジュールは、データの操作を許可しません。たとえば、ファイアウォールルールセットの途中でルールを挿入しなければならない場合があります。Ansible モジュールおよび Meraki モジュールには、データを操作するために直接マージする方法がありません。ただし、プレイリストでは、いくつかのタスクを使用して、ルールを挿入する必要のあるリストを分割し、新しいルールを追加して再びマージすることができます。その手順は以下の通りです。" - -#: ../../rst/scenario_guides/guide_meraki.rst:136 -msgid "Create blank \"front\" and \"back\" lists." -msgstr "空の「前」リストおよび「後」リストを作成します。" - -#: ../../rst/scenario_guides/guide_meraki.rst:149 -msgid "Get existing firewall rules from Meraki and create a new variable." -msgstr "Meraki から既存のファイアウォールルールを取得して、新しい変数を作成します。" - -#: ../../rst/scenario_guides/guide_meraki.rst:162 -msgid "Write the new rule. The new rule needs to be in a list so it can be merged with other lists in an upcoming step. The blank `-` puts the rule in a list so it can be merged." -msgstr "新しいルールを記述します。新しいルールは、今後のステップで他のリストにマージできるように、リストに入れる必要があります。空白の `-` は、ルールをリストに入れて、マージできるようにします。" - -#: ../../rst/scenario_guides/guide_meraki.rst:169 -msgid "Split the rules into two lists. This assumes the existing ruleset is 2 rules long." -msgstr "ルールを 2 つのリストに分割します。これは、既存のルールセットが 2 つのルールの長さであることを前提としています。" - -#: ../../rst/scenario_guides/guide_meraki.rst:174 -msgid "Merge rules with the new rule in the middle." -msgstr "ルールを、中間の新しいルールとマージします。" - -#: ../../rst/scenario_guides/guide_meraki.rst:186 -msgid "Upload new ruleset to Meraki." -msgstr "新しいルールセットを Meraki にアップロードします。" - -#: ../../rst/scenario_guides/guide_meraki.rst:189 -msgid "Error Handling" -msgstr "エラー処理" - -#: ../../rst/scenario_guides/guide_meraki.rst:191 -msgid "Ansible's Meraki modules will often fail if improper or incompatible parameters are specified. However, there will likely be scenarios where the module accepts the information but the Meraki API rejects the data. If this happens, the error will be returned in the ``body`` field for HTTP status of 400 return code." -msgstr "Ansible の Meraki モジュールは、不適切なパラメーターや互換性のないパラメーターが指定されている場合に失敗することがよくあります。ただし、モジュールが情報を受け入れても Meraki API がデータを拒否する場合があります。これに生じると、``body`` フィールドにエラーが返され、HTTP ステータスは 400 の戻りコードになります。" - -#: ../../rst/scenario_guides/guide_meraki.rst:193 -msgid "Meraki's API returns a 404 error if the API key is not correct. It does not provide any specific error saying the key is incorrect. If you receive a 404 error, check the API key first. 404 errors can also occur if improper object IDs (ex. ``org_id``) are specified." -msgstr "API キーが正しくないと、Meraki の API は 404 エラーを返します。このキーが正しくないことを示す特別なエラーはありません。404 エラーを受け取った場合は、最初に API キーを確認してください。また、不適切なオブジェクトID (例: ``org_id``) を指定した場合にも 404 エラーが出力される可能性があります。" - -#: ../../rst/scenario_guides/guide_online.rst:3 -msgid "Online.net Guide" -msgstr "Online.net ガイド" - -#: ../../rst/scenario_guides/guide_online.rst:8 -msgid "Online is a French hosting company mainly known for providing bare-metal servers named Dedibox. Check it out: `https://www.online.net/en `_" -msgstr "Online は、主に Dedibox という名前のベアメタルサーバーを提供するフランス系のホスティング企業です。`https://www.online.net/en `_ を参照してください。" - -#: ../../rst/scenario_guides/guide_online.rst:12 -msgid "Dynamic inventory for Online resources" -msgstr "Online リソースの動的インベントリー" - -#: ../../rst/scenario_guides/guide_online.rst:14 -msgid "Ansible has a dynamic inventory plugin that can list your resources." -msgstr "Ansible には、リソースを一覧表示できる動的インベントリープラグインがあります。" - -#: ../../rst/scenario_guides/guide_online.rst:16 -msgid "Create a YAML configuration such as ``online_inventory.yml`` with this content:" -msgstr "以下の内容で ``online_inventory.yml`` などの YAML 設定を作成します。" - -#: ../../rst/scenario_guides/guide_online.rst:24 -msgid "Set your ``ONLINE_TOKEN`` environment variable with your token." -msgstr "トークンを使用して、``ONLINE_TOKEN`` 環境変数を設定します。" - -#: ../../rst/scenario_guides/guide_online.rst:23 -msgid "You need to open an account and log into it before you can get a token. You can find your token at the following page: `https://console.online.net/en/api/access `_" -msgstr "トークンを取得するには、アカウントを開き、ログインする必要があります。トークンは、`https://console.online.net/en/api/access `_ のページで確認することができます。" - -#: ../../rst/scenario_guides/guide_online.rst:26 -msgid "You can test that your inventory is working by running:" -msgstr "以下を実行すると、インベントリーが機能していることをテストできます。" - -#: ../../rst/scenario_guides/guide_online.rst:33 -msgid "Now you can run your playbook or any other module with this inventory:" -msgstr "これで、Playbook またはその他のモジュールをこのインベントリーで実行できます。" - -#: ../../rst/scenario_guides/guide_oracle.rst:3 -msgid "Oracle Cloud Infrastructure Guide" -msgstr "Oracle Cloud Infrastructure ガイド" - -#: ../../rst/scenario_guides/guide_oracle.rst:9 -msgid "Oracle provides a number of Ansible modules to interact with Oracle Cloud Infrastructure (OCI). In this guide, we will explain how you can use these modules to orchestrate, provision and configure your infrastructure on OCI." -msgstr "Oracle では、Oracle Cloud Infrastructure (OCI) と対話する Ansible モジュールが多数提供されています。本ガイドでは、OCI でこれらのモジュールを使用したインフラストラクチャーのオーケストレーション、プロビジョニング、および設定の方法を説明します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:14 -msgid "To use the OCI Ansible modules, you must have the following prerequisites on your control node, the computer from which Ansible playbooks are executed." -msgstr "OCI Ansible モジュールを使用するには、Ansible Playbook を実行するコンピューターのコントロールノードに、以下の前提条件を設定する必要があります。" - -#: ../../rst/scenario_guides/guide_oracle.rst:16 -msgid "`An Oracle Cloud Infrastructure account. `_" -msgstr "`An Oracle Cloud Infrastructure account. `_" - -#: ../../rst/scenario_guides/guide_oracle.rst:18 -msgid "A user created in that account, in a security group with a policy that grants the necessary permissions for working with resources in those compartments. For guidance, see `How Policies Work `_." -msgstr "それらのコンパートメント内のリソースを操作するために必要なパーミッションを付与するポリシーを持つセキュリティーグループで、そのアカウントで作成されたユーザー。ガイダンスについては、「`ポリシーの仕組み `_」を参照してください。" - -#: ../../rst/scenario_guides/guide_oracle.rst:20 -msgid "The necessary credentials and OCID information." -msgstr "必要な認証情報および OCID 情報" - -#: ../../rst/scenario_guides/guide_oracle.rst:24 -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:25 -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:37 -msgid "Installation" -msgstr "インストール" - -#: ../../rst/scenario_guides/guide_oracle.rst:25 -msgid "Install the Oracle Cloud Infrastructure Python SDK (`detailed installation instructions `_):" -msgstr "Oracle Cloud Infrastructure Python SDK (`detailed installation instructions `_) をインストールします。" - -#: ../../rst/scenario_guides/guide_oracle.rst:31 -msgid "Install the Ansible OCI Modules in one of two ways:" -msgstr "以下のいずれかの方法で Ansible OCI モジュールをインストールします。" - -#: ../../rst/scenario_guides/guide_oracle.rst:33 -msgid "From Galaxy:" -msgstr "Galaxy の場合:" - -#: ../../rst/scenario_guides/guide_oracle.rst:39 -msgid "From GitHub:" -msgstr "GitHub で、以下を行います。" - -#: ../../rst/scenario_guides/guide_oracle.rst:50 -msgid "Run one of the following commands:" -msgstr "以下のコマンドのいずれかを実行します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:52 -msgid "If Ansible is installed only for your user:" -msgstr "Ansible をお使いのユーザーにのみインストールする場合は、以下を実行します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:58 -msgid "If Ansible is installed as root:" -msgstr "Ansible を root でインストールする場合は、以下を実行します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:66 -#: ../../rst/scenario_guides/guide_vultr.rst:16 -msgid "Configuration" -msgstr "設定" - -#: ../../rst/scenario_guides/guide_oracle.rst:68 -msgid "When creating and configuring Oracle Cloud Infrastructure resources, Ansible modules use the authentication information outlined `here `_. ." -msgstr "Oracle Cloud Infrastructure リソースを作成して設定する際に、Ansible モジュールは `こちら `_ で説明されている認証情報を使用します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:75 -msgid "Launch a compute instance" -msgstr "コンピュートインスタンスの起動" - -#: ../../rst/scenario_guides/guide_oracle.rst:76 -msgid "This `sample launch playbook `_ launches a public Compute instance and then accesses the instance from an Ansible module over an SSH connection. The sample illustrates how to:" -msgstr "この `サンプルの起動 Playbook `_ は、パブリック Compute インスタンスを起動し、SSH 接続を介して Ansible モジュールからインスタンスにアクセスします。以下に例を示します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:79 -msgid "Generate a temporary, host-specific SSH key pair." -msgstr "一時的なホスト固有の SSH キーペアを生成します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:80 -msgid "Specify the public key from the key pair for connecting to the instance, and then launch the instance." -msgstr "インスタンスへの接続に使用するキーペアの公開鍵を指定し、インスタンスを起動します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:81 -msgid "Connect to the newly launched instance using SSH." -msgstr "SSH を使用して、新たに起動したインスタンスに接続します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:84 -msgid "Create and manage Autonomous Data Warehouses" -msgstr "Autonomous Data Warehouse の作成および管理" - -#: ../../rst/scenario_guides/guide_oracle.rst:85 -msgid "This `sample warehouse playbook `_ creates an Autonomous Data Warehouse and manage its lifecycle. The sample shows how to:" -msgstr "この `サンプルのウェアハウス Playbook `_ は自律型データウェアハウス (Autonomous Data Warehouse ) を作成し、そのライフサイクルを管理します。サンプルでは以下の方法を示します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:87 -msgid "Set up an Autonomous Data Warehouse." -msgstr "Autonomous Data Warehouse を設定します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:88 -msgid "List all of the Autonomous Data Warehouse instances available in a compartment, filtered by the display name." -msgstr "表示名で対象を絞った、コンパートメントで利用可能な Autonomous Data Warehouse の一覧を表示します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:89 -msgid "Get the \"facts\" for a specified Autonomous Data Warehouse." -msgstr "指定された Autonomous Data Warehouse の「ファクト」を取得します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:90 -msgid "Stop and start an Autonomous Data Warehouse instance." -msgstr "Autonomous Data Warehouse インスタンスを停止して開始します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:91 -msgid "Delete an Autonomous Data Warehouse instance." -msgstr "Autonomous Data Warehouse インスタンスを削除します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:94 -msgid "Create and manage Autonomous Transaction Processing" -msgstr "Autonomous Transaction Processing の作成と管理" - -#: ../../rst/scenario_guides/guide_oracle.rst:95 -msgid "This `sample playbook `_ creates an Autonomous Transaction Processing database and manage its lifecycle. The sample shows how to:" -msgstr "この `Playbook サンプル `_ は、自律型トランザクション処理データベースを作成し、そのライフサイクルを管理します。サンプルは以下の方法を示します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:98 -msgid "Set up an Autonomous Transaction Processing database instance." -msgstr "Autonomous Transaction Processing データベースインスタンスを設定します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:99 -msgid "List all of the Autonomous Transaction Processing instances in a compartment, filtered by the display name." -msgstr "表示名で対象を絞った、コンパートメントで利用可能な Autonomous Transaction Processing インスタンスの一覧を表示します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:100 -msgid "Get the \"facts\" for a specified Autonomous Transaction Processing instance." -msgstr "指定された Autonomous Transaction Processing インスタンスの「ファクト」を取得します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:101 -msgid "Delete an Autonomous Transaction Processing database instance." -msgstr "Autonomous Transaction Processing データベースインスタンスを削除します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:103 -msgid "You can find more examples here: `Sample Ansible Playbooks `_." -msgstr "詳細は、`サンプル Ansible Playbook `_ を参照してください。" - -#: ../../rst/scenario_guides/guide_packet.rst:3 -msgid "Packet.net Guide" -msgstr "Packet.net ガイド" - -#: ../../rst/scenario_guides/guide_packet.rst:8 -msgid "`Packet.net `_ is a bare metal infrastructure host that's supported by Ansible (>=2.3) via a dynamic inventory script and two cloud modules. The two modules are:" -msgstr "`Packet.net `_ は、動的インベントリースクリプトと 2 つのクラウドモジュールを介して Ansible (2.3 以降) で対応しているベアメタルインフラストラクチャーホストです。この 2 つのモジュールは次のとおりです。" - -#: ../../rst/scenario_guides/guide_packet.rst:10 -msgid "packet_sshkey: adds a public SSH key from file or value to the Packet infrastructure. Every subsequently-created device will have this public key installed in .ssh/authorized_keys." -msgstr "packet_sshkey: ファイルまたは値から Packet インフラストラクチャーに公開 SSH 鍵を追加します。今後作成されるすべてのデバイスの .ssh/authorized_keys にこの公開鍵がインストールされます。" - -#: ../../rst/scenario_guides/guide_packet.rst:11 -msgid "packet_device: manages servers on Packet. You can use this module to create, restart and delete devices." -msgstr "packet_device: パケット上のサーバーを管理します。このモジュールを使用して、デバイスの作成、再起動、および削除を行うことができます。" - -#: ../../rst/scenario_guides/guide_packet.rst:13 -msgid "Note, this guide assumes you are familiar with Ansible and how it works. If you're not, have a look at their :ref:`docs ` before getting started." -msgstr "本ガイドでは、Ansible に精通していることを前提としています。Ansible にあまり精通していない場合は、開始する前に「:ref:`docs `」をお読みください。" - -#: ../../rst/scenario_guides/guide_packet.rst:18 -msgid "The Packet modules and inventory script connect to the Packet API using the packet-python package. You can install it with pip:" -msgstr "Packet モジュールとインベントリースクリプトは、packets-python パッケージを使用して Packet API に接続します。これは、pip でインストールできます。" - -#: ../../rst/scenario_guides/guide_packet.rst:24 -msgid "In order to check the state of devices created by Ansible on Packet, it's a good idea to install one of the `Packet CLI clients `_. Otherwise you can check them via the `Packet portal `_." -msgstr "パケット上で Ansible が作成したデバイスの状態をチェックするには、`Packet CLI clients `_ のいずれかをインストールすることが推奨されます。そうでない場合は、`Packet portal `_ で確認することができます。" - -#: ../../rst/scenario_guides/guide_packet.rst:26 -msgid "To use the modules and inventory script you'll need a Packet API token. You can generate an API token via the Packet portal `here `__. The simplest way to authenticate yourself is to set the Packet API token in an environment variable:" -msgstr "モジュールおよびインベントリースクリプトを使用するには、パケット API トークンが必要です。パケットポータル (`こちら `__) を使用して API トークンを生成することができます。認証する最も簡単な方法は、環境変数で Packet API トークンを設定することです。" - -#: ../../rst/scenario_guides/guide_packet.rst:32 -msgid "If you're not comfortable exporting your API token, you can pass it as a parameter to the modules." -msgstr "API トークンのエクスポートが不明な場合は、これをパラメーターとしてモジュールに渡すことができます。" - -#: ../../rst/scenario_guides/guide_packet.rst:34 -msgid "On Packet, devices and reserved IP addresses belong to `projects `_. In order to use the packet_device module, you need to specify the UUID of the project in which you want to create or manage devices. You can find a project's UUID in the Packet portal `here `_ (it's just under the project table) or via one of the available `CLIs `_." -msgstr "パケットでは、デバイスと予約済みの IP アドレスは、`プロジェクト `_ に属します。packet_device モジュールを使用するには、デバイスの作成または管理を行うプロジェクトの UUID を指定する必要があります。プロジェクトの UUID は、パケットポータル (`こちら `_ (プロジェクトテーブルのすぐ下にあります)) または利用可能な `CLI `_ のいずれかを介して見つけることができます。" - -#: ../../rst/scenario_guides/guide_packet.rst:37 -#: ../../rst/scenario_guides/guide_scaleway.rst:39 -msgid "If you want to use a new SSH key pair in this tutorial, you can generate it to ``./id_rsa`` and ``./id_rsa.pub`` as:" -msgstr "本チュートリアルで新しい SSH キーペアを使用する場合は、以下のように ``./id_rsa`` および ``./id_rsa.pub`` に生成してください。" - -#: ../../rst/scenario_guides/guide_packet.rst:43 -#: ../../rst/scenario_guides/guide_scaleway.rst:45 -msgid "If you want to use an existing key pair, just copy the private and public key over to the playbook directory." -msgstr "既存のキーペアを使用する場合は、秘密鍵と公開鍵を Playbook ディレクトリーにコピーします。" - -#: ../../rst/scenario_guides/guide_packet.rst:47 -msgid "Device Creation" -msgstr "デバイスの作成" - -#: ../../rst/scenario_guides/guide_packet.rst:49 -msgid "The following code block is a simple playbook that creates one `Type 0 `_ server (the 'plan' parameter). You have to supply 'plan' and 'operating_system'. 'location' defaults to 'ewr1' (Parsippany, NJ). You can find all the possible values for the parameters via a `CLI client `_." -msgstr "以下のコードブロックは、`Type 0 `_ サーバー (「plan」パラメーター) を作成する簡単な Playbook です。「plan」および「operating_system」を定義する必要があります。「location」は、「ewr1」(Parsippany、NJ) に設定されます。`CLI クライアント `_ を介して、パラメーターで可能な値をすべて確認できます。" - -#: ../../rst/scenario_guides/guide_packet.rst:70 -msgid "After running ``ansible-playbook playbook_create.yml``, you should have a server provisioned on Packet. You can verify via a CLI or in the `Packet portal `__." -msgstr "``ansible-playbook playbook_create.yml`` の実行後に、パケット上にサーバーをプロビジョニングする必要があります。CLI または `パケットポータル `__ で確認することができます。" - -#: ../../rst/scenario_guides/guide_packet.rst:72 -msgid "If you get an error with the message \"failed to set machine state present, error: Error 404: Not Found\", please verify your project UUID." -msgstr "エラーが発生して「failed to set machine state present, error: Error 404: Not Found」メッセージが表示された場合は、プロジェクトの UUID を確認してください。" - -#: ../../rst/scenario_guides/guide_packet.rst:76 -msgid "Updating Devices" -msgstr "デバイスの更新" - -#: ../../rst/scenario_guides/guide_packet.rst:78 -msgid "The two parameters used to uniquely identify Packet devices are: \"device_ids\" and \"hostnames\". Both parameters accept either a single string (later converted to a one-element list), or a list of strings." -msgstr "Packet デバイスを一意に識別するために、「device_ids」および「hostnames」という 2 つのパラメーターがあります。どちらのパラメーターも、1 つの文字列 (後で単一の要素の一覧に変換) または文字列の一覧を受け入れます。" - -#: ../../rst/scenario_guides/guide_packet.rst:80 -msgid "The 'device_ids' and 'hostnames' parameters are mutually exclusive. The following values are all acceptable:" -msgstr "「device_ids」パラメーターおよび「hostnames」パラメーターは相互排他的です。以下の値はすべて受け入れ可能です。" - -#: ../../rst/scenario_guides/guide_packet.rst:82 -msgid "device_ids: a27b7a83-fc93-435b-a128-47a5b04f2dcf" -msgstr "device_ids: a27b7a83-fc93-435b-a128-47a5b04f2dcf" - -#: ../../rst/scenario_guides/guide_packet.rst:84 -msgid "hostnames: mydev1" -msgstr "hostnames: mydev1" - -#: ../../rst/scenario_guides/guide_packet.rst:86 -msgid "device_ids: [a27b7a83-fc93-435b-a128-47a5b04f2dcf, 4887130f-0ccd-49a0-99b0-323c1ceb527b]" -msgstr "device_ids: [a27b7a83-fc93-435b-a128-47a5b04f2dcf, 4887130f-0ccd-49a0-99b0-323c1ceb527b]" - -#: ../../rst/scenario_guides/guide_packet.rst:88 -msgid "hostnames: [mydev1, mydev2]" -msgstr "hostnames: [mydev1, mydev2]" - -#: ../../rst/scenario_guides/guide_packet.rst:90 -#, python-format -msgid "In addition, hostnames can contain a special '%d' formatter along with a 'count' parameter that lets you easily expand hostnames that follow a simple name and number pattern; in other words, ``hostnames: \"mydev%d\", count: 2`` will expand to [mydev1, mydev2]." -msgstr "さらに、ホスト名には、簡単な名前と数字のパターンに従うホスト名を簡単に拡張できる「count」パラメーターとともに特別な「%d」フォーマッターを含めることができます。つまり、``hostnames: \"mydev%d\", count: 2`` は [mydev1, mydev2] に拡張されます。" - -#: ../../rst/scenario_guides/guide_packet.rst:92 -msgid "If your playbook acts on existing Packet devices, you can only pass the 'hostname' and 'device_ids' parameters. The following playbook shows how you can reboot a specific Packet device by setting the 'hostname' parameter:" -msgstr "Playbook が既存のパケットデバイスに機能する場合は、「hostname」および「device_ids」のパラメーターを渡すことができます。以下の Playbook は、「hostname」パラメーターを設定して特定のパケットデバイスを再起動する方法を示しています。" - -#: ../../rst/scenario_guides/guide_packet.rst:107 -msgid "You can also identify specific Packet devices with the 'device_ids' parameter. The device's UUID can be found in the `Packet Portal `_ or by using a `CLI `_. The following playbook removes a Packet device using the 'device_ids' field:" -msgstr "「device_ids」パラメーターを使用して特定のパケットデバイスを識別することもできます。デバイスの UUID は、`Packet ポータル `_ か `CLI `_ を使用して確認できます。以下の Playbook は「device_ids」フィールドを使用してパケットデバイスを削除します。" - -#: ../../rst/scenario_guides/guide_packet.rst:124 -msgid "More Complex Playbooks" -msgstr "より複雑な Playbook" - -#: ../../rst/scenario_guides/guide_packet.rst:126 -msgid "In this example, we'll create a CoreOS cluster with `user data `_." -msgstr "この例では、`ユーザーデータ `_ で CoreOS クラスターを作成します。" - -#: ../../rst/scenario_guides/guide_packet.rst:129 -msgid "The CoreOS cluster will use `etcd `_ for discovery of other servers in the cluster. Before provisioning your servers, you'll need to generate a discovery token for your cluster:" -msgstr "CoreOS クラスターは、クラスター内の他のサーバーの検出に `etcd `_ を使用します。サーバーをプロビジョニングする前に、クラスターの検出トークンを生成する必要があります。" - -#: ../../rst/scenario_guides/guide_packet.rst:135 -msgid "The following playbook will create an SSH key, 3 Packet servers, and then wait until SSH is ready (or until 5 minutes passed). Make sure to substitute the discovery token URL in 'user_data', and the 'project_id' before running ``ansible-playbook``. Also, feel free to change 'plan' and 'facility'." -msgstr "以下の Playbook は、SSH キー、3 台の Packet サーバーを作成し、SSH の準備ができるまで (または 5 分経過するまで) 待ちます。``ansible-playbook`` を実行する前に、「user_data」の検出トークン URL と「project_id」を置き換えてください。また、「plan」と「facility」は自由に変更してください。" - -#: ../../rst/scenario_guides/guide_packet.rst:184 -msgid "As with most Ansible modules, the default states of the Packet modules are idempotent, meaning the resources in your project will remain the same after re-runs of a playbook. Thus, we can keep the ``packet_sshkey`` module call in our playbook. If the public key is already in your Packet account, the call will have no effect." -msgstr "ほとんどの Ansible モジュールと同様に、Packet モジュールのデフォルト状態は冪等です。つまり、Playbook を再実行した後もプロジェクトのリソースは同じままになります。したがって、Playbook で ``packet_sshkey`` モジュールの呼び出しを維持できます。パブリックキーがすでにパケットアカウントにある場合は、呼び出しても効果がありません。" - -#: ../../rst/scenario_guides/guide_packet.rst:186 -msgid "The second module call provisions 3 Packet Type 0 (specified using the 'plan' parameter) servers in the project identified via the 'project_id' parameter. The servers are all provisioned with CoreOS beta (the 'operating_system' parameter) and are customized with cloud-config user data passed to the 'user_data' parameter." -msgstr "2 つ目のモジュール呼び出しは、「project_id」パラメーターで識別されるプロジェクトの 3 Packet タイプ 0 (「plan」パラメーターで指定) サーバーをプロビジョニングします。サーバーはすべて CoreOS ベータでプロビジョニングされ (「operating_system」パラメーター)、「user_data」パラメーターに渡される cloud-config ユーザーデータでカスタマイズされます。" - -#: ../../rst/scenario_guides/guide_packet.rst:188 -msgid "The ``packet_device`` module has a ``wait_for_public_IPv`` that is used to specify the version of the IP address to wait for (valid values are ``4`` or ``6`` for IPv4 or IPv6). If specified, Ansible will wait until the GET API call for a device contains an Internet-routeable IP address of the specified version. When referring to an IP address of a created device in subsequent module calls, it's wise to use the ``wait_for_public_IPv`` parameter, or ``state: active`` in the packet_device module call." -msgstr "``packet_device`` モジュールには、待機する IP アドレスのバージョンを指定するために使用される ``wait_for_public_IPv`` があります (有効な値は、IPv4 または IPv6 である ``4`` または ``6``)。これが指定されている場合、Ansible はデバイスの GET API 呼び出しに指定バージョンのインターネットルーティング可能な IP アドレスが含まれるまで待機します。後続のモジュール呼び出しで作成されたデバイスの IP アドレスを参照する場合は、packet_device モジュール呼び出しで ``wait_for_public_IPv`` パラメーターまたは ``state: active`` を使用することが推奨されます。" - -#: ../../rst/scenario_guides/guide_packet.rst:190 -msgid "Run the playbook:" -msgstr "Playbook を実行します。" - -#: ../../rst/scenario_guides/guide_packet.rst:196 -msgid "Once the playbook quits, your new devices should be reachable via SSH. Try to connect to one and check if etcd has started properly:" -msgstr "Playbook が終了すると、SSH を介して新規デバイスにアクセスできるはずです。1 つのデバイスに接続して、etcd が正常に起動したかどうかを確認します。" - -#: ../../rst/scenario_guides/guide_packet.rst:203 -msgid "Once you create a couple of devices, you might appreciate the dynamic inventory script..." -msgstr "いくつかのデバイスを作成したら、動的インベントリースクリプトを利用できます。" - -#: ../../rst/scenario_guides/guide_packet.rst:209 -msgid "The dynamic inventory script queries the Packet API for a list of hosts, and exposes it to Ansible so you can easily identify and act on Packet devices." -msgstr "動的インベントリースクリプトは、ホストの一覧に Packet API をクエリーし、これを Ansible に公開して、Packet デバイスを簡単に識別し、操作できるようにします。" - -#: ../../rst/scenario_guides/guide_packet.rst:211 -msgid "You can find it in Ansible Community General Collection's git repo at `scripts/inventory/packet_net.py `_." -msgstr "Ansible Community General Collection の git リポジトリーは、`scripts/inventory/packet_net.py `_ にあります。" - -#: ../../rst/scenario_guides/guide_packet.rst:213 -msgid "The inventory script is configurable via a `ini file `_." -msgstr "インベントリースクリプトは、`ini file `_ で設定可能です。" - -#: ../../rst/scenario_guides/guide_packet.rst:215 -msgid "If you want to use the inventory script, you must first export your Packet API token to a PACKET_API_TOKEN environment variable." -msgstr "インベントリースクリプトを使用する場合、最初に Packet API トークンを PACKET_API_TOKEN 環境変数にエクスポートする必要があります。" - -#: ../../rst/scenario_guides/guide_packet.rst:217 -msgid "You can either copy the inventory and ini config out from the cloned git repo, or you can download it to your working directory like so:" -msgstr "インベントリーおよび ini 設定をクローンされた git リポジトリーからコピーするか、以下のように作業ディレクトリーにダウンロードできます。" - -#: ../../rst/scenario_guides/guide_packet.rst:225 -msgid "In order to understand what the inventory script gives to Ansible you can run:" -msgstr "インベントリースクリプトが Ansible に与える影響を理解するために、次を実行できます。" - -#: ../../rst/scenario_guides/guide_packet.rst:231 -msgid "It should print a JSON document looking similar to following trimmed dictionary:" -msgstr "以下のトリムされたディクショナリーのような JSON ドキュメントを出力する必要があります。" - -#: ../../rst/scenario_guides/guide_packet.rst:289 -msgid "In the ``['_meta']['hostvars']`` key, there is a list of devices (uniquely identified by their public IPv4 address) with their parameters. The other keys under ``['_meta']`` are lists of devices grouped by some parameter. Here, it is type (all devices are of type baremetal_0), operating system, and facility (ewr1 and sjc1)." -msgstr "``['_meta']['hostvars']`` キーには、デバイスの一覧 (特にパブリック IPv4 アドレスで識別されるもの) とそのパラメーターがあります。``['_meta']`` 以下の他のキーは、何らかのパラメータでグループ化されたデバイスのリストです。これは種類 (すべてのデバイスの種類は baremetal_0)、オペレーティングシステム、およびファシリティー (ewr1 および sjc1) です。" - -#: ../../rst/scenario_guides/guide_packet.rst:291 -msgid "In addition to the parameter groups, there are also one-item groups with the UUID or hostname of the device." -msgstr "パラメーターグループの他に、デバイスの UUID またはホスト名を持つ 1 項目グループもあります。" - -#: ../../rst/scenario_guides/guide_packet.rst:293 -msgid "You can now target groups in playbooks! The following playbook will install a role that supplies resources for an Ansible target into all devices in the \"coreos_beta\" group:" -msgstr "Playbook でグループをターゲットにできるようになりました。以下の Playbook は、「coreos_beta」グループのすべてのデバイスに Ansible ターゲットのリソースを提供するロールをインストールします。" - -#: ../../rst/scenario_guides/guide_packet.rst:304 -msgid "Don't forget to supply the dynamic inventory in the ``-i`` argument!" -msgstr "``-i`` 引数で忘れずに動的インベントリーを指定してください。" - -#: ../../rst/scenario_guides/guide_packet.rst:311 -msgid "If you have any questions or comments let us know! help@packet.net" -msgstr "ご質問やご感想は、help@packet.net までご連絡ください。" - -#: ../../rst/scenario_guides/guide_rax.rst:2 -msgid "Rackspace Cloud Guide" -msgstr "Rackspace Cloud ガイド" - -#: ../../rst/scenario_guides/guide_rax.rst:9 -msgid "This section of the documentation is under construction. We are in the process of adding more examples about the Rackspace modules and how they work together. Once complete, there will also be examples for Rackspace Cloud in `ansible-examples `_." -msgstr "本ガイドに記載するセクションは作成中です。ここでは、Rackspace モジュールやそれがどのように連携するかについての例を追加するプロセスです。完了後は、`ansible-examples `_ に Rackspace Cloud の例もあります。" - -#: ../../rst/scenario_guides/guide_rax.rst:11 -msgid "Ansible contains a number of core modules for interacting with Rackspace Cloud." -msgstr "Ansible には、Rackspace Cloud と対話するためのコアモジュールが多数含まれています。" - -#: ../../rst/scenario_guides/guide_rax.rst:13 -msgid "The purpose of this section is to explain how to put Ansible modules together (and use inventory scripts) to use Ansible in a Rackspace Cloud context." -msgstr "本セクションでは、Ansible モジュールを組み合わせて (インベントリースクリプトを使用して)、Rackspace Cloudのコンテキストで Ansible を使用する方法を説明します。" - -#: ../../rst/scenario_guides/guide_rax.rst:16 -msgid "Prerequisites for using the rax modules are minimal. In addition to ansible itself, all of the modules require and are tested against pyrax 1.5 or higher. You'll need this Python module installed on the execution host." -msgstr "rax モジュール使用の前提条件は最小限です。Ansible 自体の他に、すべてのモジュールが必要で、pyrax 1.5 以降に対してテストされています。実行ホストに、この Python モジュールをインストールする必要があります。" - -#: ../../rst/scenario_guides/guide_rax.rst:20 -msgid "``pyrax`` is not currently available in many operating system package repositories, so you will likely need to install it via pip:" -msgstr "``pyrax`` は、現在多くのオペレーティングシステムパッケージリポジトリーでは利用できないため、pip を使用してインストールしなければならない場合があります。" - -#: ../../rst/scenario_guides/guide_rax.rst:27 -msgid "Ansible creates an implicit localhost that executes in the same context as the ``ansible-playbook`` and the other CLI tools. If for any reason you need or want to have it in your inventory you should do something like the following:" -msgstr "Ansible は、``ansible-playbook`` およびその他の CLI ツールと同じコンテキストで実行する暗黙的なローカルホストを作成します。何らかの理由で必要な場合やこれを使用する場合は、以下のような作業を行います。" - -#: ../../rst/scenario_guides/guide_rax.rst:35 -msgid "For more information see :ref:`Implicit Localhost `" -msgstr "詳細情報は、「:ref:`Implicit Localhost `」を参照してください。" - -#: ../../rst/scenario_guides/guide_rax.rst:37 -msgid "In playbook steps, we'll typically be using the following pattern:" -msgstr "Playbook のステップでは、通常、以下のパターンを使用します。" - -#: ../../rst/scenario_guides/guide_rax.rst:50 -msgid "The `rax.py` inventory script and all `rax` modules support a standard `pyrax` credentials file that looks like:" -msgstr "`rax.py` インベントリースクリプトとすべての `rax` モジュールは、以下のような標準の `pyrax` 認証情報ファイルをサポートします。" - -#: ../../rst/scenario_guides/guide_rax.rst:58 -msgid "Setting the environment parameter ``RAX_CREDS_FILE`` to the path of this file will help Ansible find how to load this information." -msgstr "環境パラメーター ``RAX_CREDS_FILE`` にこのファイルのパスを設定することで、Ansible はこの情報を読み込む方法を見つけることができます。" - -#: ../../rst/scenario_guides/guide_rax.rst:61 -msgid "More information about this credentials file can be found at https://github.com/pycontribs/pyrax/blob/master/docs/getting_started.md#authenticating" -msgstr "この認証情報ファイルに関する詳細情報は、https://github.com/pycontribs/pyrax/blob/master/docs/getting_started.md#authenticating を参照してください。" - -#: ../../rst/scenario_guides/guide_rax.rst:68 -msgid "Running from a Python Virtual Environment (Optional)" -msgstr "Python 仮想環境からの実行 (任意)" - -#: ../../rst/scenario_guides/guide_rax.rst:70 -msgid "Most users will not be using virtualenv, but some users, particularly Python developers sometimes like to." -msgstr "ほとんどのユーザーは virtualenv を使用しませんが、一部のユーザー、特に Python の開発者はそれを使用する場合があります。" - -#: ../../rst/scenario_guides/guide_rax.rst:72 -msgid "There are special considerations when Ansible is installed to a Python virtualenv, rather than the default of installing at a global scope. Ansible assumes, unless otherwise instructed, that the python binary will live at /usr/bin/python. This is done via the interpreter line in modules, however when instructed by setting the inventory variable 'ansible_python_interpreter', Ansible will use this specified path instead to find Python. This can be a cause of confusion as one may assume that modules running on 'localhost', or perhaps running via 'local_action', are using the virtualenv Python interpreter. By setting this line in the inventory, the modules will execute in the virtualenv interpreter and have available the virtualenv packages, specifically pyrax. If using virtualenv, you may wish to modify your localhost inventory definition to find this location as follows:" -msgstr "Ansible が Python virtualenv にインストールされる場合には、デフォルトのグローバルスコープでのインストールではなく、特別な考慮事項があります。Ansible は、特に指示がない限り、Python のバイナリーを /usr/bin/python に置くことを前提としています。これは、モジュールのインタープリターの行から行われますが、インベントリー変数「ansible_python_interpreter」を設定して指示すると、Ansible は Python の検索の代わりに、この指定されたパスを使用します。これは、「localhost」で実行しているモジュール、または「local_action」で実行されるモジュールが virtualenv Python インタープリターを使用していると思い込んでしまうため、混乱が生じる可能性があります。この行をインベントリーに設定すると、モジュールは virtualenv インタープリターで実行し、virtualenv パッケージ (具体的には pyrax) が利用できるようになります。virtualenv を使用している場合は、以下のように、localhost インベントリー定義を変更してこの場所が検出されるようにします。" - -#: ../../rst/scenario_guides/guide_rax.rst:81 -msgid "pyrax may be installed in the global Python package scope or in a virtual environment. There are no special considerations to keep in mind when installing pyrax." -msgstr "pyrax は、グローバルな Python パッケージスコープまたは仮想環境にインストールすることができます。pyrax をインストールする際には、特別な考慮事項に留意してください。" - -#: ../../rst/scenario_guides/guide_rax.rst:88 -msgid "Now for the fun parts." -msgstr "ここからが重要です。" - -#: ../../rst/scenario_guides/guide_rax.rst:90 -msgid "The 'rax' module provides the ability to provision instances within Rackspace Cloud. Typically the provisioning task will be performed from your Ansible control server (in our example, localhost) against the Rackspace cloud API. This is done for several reasons:" -msgstr "「rax」モジュールは、Rackspace Cloud 内でインスタンスをプロビジョニングする機能を提供します。通常、プロビジョニングタスクは、Rackspace Cloud API に対して Ansible コントロールサーバー (この例ではローカルホスト) から実行します。これには、いくつかの理由があります。" - -#: ../../rst/scenario_guides/guide_rax.rst:92 -msgid "Avoiding installing the pyrax library on remote nodes" -msgstr "リモートノードに pyrax ライブラリーをインストールしないようにする" - -#: ../../rst/scenario_guides/guide_rax.rst:93 -msgid "No need to encrypt and distribute credentials to remote nodes" -msgstr "認証情報を暗号化してリモートノードに配布する必要はない" - -#: ../../rst/scenario_guides/guide_rax.rst:94 -msgid "Speed and simplicity" -msgstr "スピードおよび単純化" - -#: ../../rst/scenario_guides/guide_rax.rst:98 -msgid "Authentication with the Rackspace-related modules is handled by either specifying your username and API key as environment variables or passing them as module arguments, or by specifying the location of a credentials file." -msgstr "Rackspace に関連するモジュールを使用した認証は、ユーザー名および API キーを環境変数として指定するか、モジュール引数として渡すか、認証情報ファイルの場所を指定して処理されます。" - -#: ../../rst/scenario_guides/guide_rax.rst:103 -msgid "Here is a basic example of provisioning an instance in ad hoc mode:" -msgstr "以下は、アドホックモードでのインスタンスをプロビジョニングする基本的な例です。" - -#: ../../rst/scenario_guides/guide_rax.rst:109 -msgid "Here's what it would look like in a playbook, assuming the parameters were defined in variables:" -msgstr "以下は、パラメーターが変数に定義されていると仮定した場合の、Playbook で表示される内容です。" - -#: ../../rst/scenario_guides/guide_rax.rst:125 -msgid "The rax module returns data about the nodes it creates, like IP addresses, hostnames, and login passwords. By registering the return value of the step, it is possible used this data to dynamically add the resulting hosts to inventory (temporarily, in memory). This facilitates performing configuration actions on the hosts in a follow-on task. In the following example, the servers that were successfully created using the above task are dynamically added to a group called \"raxhosts\", with each nodes hostname, IP address, and root password being added to the inventory." -msgstr "rax モジュールは、IP アドレス、ホスト名、ログインパスワードなど、作成するノードのデータを返します。ステップの戻り値を登録すると、このデータを使用して、作成されるホストをインベントリー (通常はメモリー内) に動的に追加できます。これにより、後続のタスクによるホストでの設定アクションの実行が容易になります。以下の例では、上記のタスクを使用して正常に作成されたサーバーは「raxhosts」というグループに動的に追加され、各ノードのホスト名、IP アドレス、および root パスワードがインベントリーに追加されます。" - -#: ../../rst/scenario_guides/guide_rax.rst:138 -msgid "With the host group now created, the next play in this playbook could now configure servers belonging to the raxhosts group." -msgstr "これでホストグループが作成され、この Playbook の次のプレイで raxhosts グループに属するサーバーを設定できるようになりました。" - -#: ../../rst/scenario_guides/guide_rax.rst:149 -msgid "The method above ties the configuration of a host with the provisioning step. This isn't always what you want, and leads us to the next section." -msgstr "上記の方法でプロビジョニングステップでホストの設定を統合します。これは必ずしも望ましいことではなく、次のセクションにつながります。" - -#: ../../rst/scenario_guides/guide_rax.rst:157 -msgid "Once your nodes are spun up, you'll probably want to talk to them again. The best way to handle this is to use the \"rax\" inventory plugin, which dynamically queries Rackspace Cloud and tells Ansible what nodes you have to manage. You might want to use this even if you are spinning up cloud instances via other tools, including the Rackspace Cloud user interface. The inventory plugin can be used to group resources by metadata, region, OS, and so on. Utilizing metadata is highly recommended in \"rax\" and can provide an easy way to sort between host groups and roles. If you don't want to use the ``rax.py`` dynamic inventory script, you could also still choose to manually manage your INI inventory file, though this is less recommended." -msgstr "ノードが起動したら、再びノードとやり取りしたくなるでしょう。これを処理する最善の方法は、「rax」インベントリープラグインを使用することです。これは、Rackspace Cloud に動的にクエリーを実行し、管理する必要があるノードを Ansible に通知します。Rackspace Cloud ユーザーインターフェースなど、他のツールでクラウドインスタンスを起動している場合でも、このプラグインを使用することができます。インベントリープラグインは、メタデータ、リージョン、OS などでリソースをグループ化するために使用できます。メタデータの使用は「rax」で強く推奨され、ホストグループとロールとの間で簡単に並べ替えることができます。``rax.py`` ダイナミックインベントリースクリプトを使用したくない場合は、INI インベントリーファイルを手動で管理することもできますが、これはあまりお勧めできません。" - -#: ../../rst/scenario_guides/guide_rax.rst:159 -msgid "In Ansible it is quite possible to use multiple dynamic inventory plugins along with INI file data. Just put them in a common directory and be sure the scripts are chmod +x, and the INI-based ones are not." -msgstr "Ansible では、INI ファイルデータとともに複数の動的インベントリープラグインを使用できます。これらのプラグインを共通ディレクトリーに置き、スクリプトに chmod +x を設定し、INI ベースのファイルには chmod +x を設定しないようにします。" - -#: ../../rst/scenario_guides/guide_rax.rst:164 -msgid "rax.py" -msgstr "rax.py" - -#: ../../rst/scenario_guides/guide_rax.rst:166 -msgid "To use the Rackspace dynamic inventory script, copy ``rax.py`` into your inventory directory and make it executable. You can specify a credentials file for ``rax.py`` utilizing the ``RAX_CREDS_FILE`` environment variable." -msgstr "Rackspace 動的インベントリースクリプトを使用するには、``rax.py`` をインベントリーディレクトリーにコピーして、実行可能にします。``RAX_CREDS_FILE`` 環境変数を使用すると、``rax.py`` 用の認証情報ファイルを指定できます。" - -#: ../../rst/scenario_guides/guide_rax.rst:168 -msgid "Dynamic inventory scripts (like ``rax.py``) are saved in ``/usr/share/ansible/inventory`` if Ansible has been installed globally. If installed to a virtualenv, the inventory scripts are installed to ``$VIRTUALENV/share/inventory``." -msgstr "Ansible がグローバルにインストールされている場合は、動的インベントリースクリプト (``rax.py`` など) が ``/usr/share/ansible/inventory`` に保存されます。virtualenv にインストールされると、インベントリースクリプトは ``$VIRTUALENV/share/inventory`` にインストールされます。" - -#: ../../rst/scenario_guides/guide_rax.rst:170 -msgid "Users of :ref:`ansible_tower` will note that dynamic inventory is natively supported by Tower, and all you have to do is associate a group with your Rackspace Cloud credentials, and it will easily synchronize without going through these steps::" -msgstr ":ref:`ansible_tower` のユーザーは、Tower が動的インベントリーをネイティブにサポートしており、グループを Rackspace Cloud 認証情報に関連付けるだけで、このステップを実行せずに簡単に同期できます。" - -#: ../../rst/scenario_guides/guide_rax.rst:174 -msgid "``rax.py`` also accepts a ``RAX_REGION`` environment variable, which can contain an individual region, or a comma separated list of regions." -msgstr "``rax.py`` は、個別のリージョンまたはコンマ区切りのリージョン一覧を指定できる ``RAX_REGION`` 環境変数も受け入れます。" - -#: ../../rst/scenario_guides/guide_rax.rst:176 -msgid "When using ``rax.py``, you will not have a 'localhost' defined in the inventory." -msgstr "``rax.py`` を使用する場合は、インベントリーに「localhost」が定義されません。" - -#: ../../rst/scenario_guides/guide_rax.rst:178 -msgid "As mentioned previously, you will often be running most of these modules outside of the host loop, and will need 'localhost' defined. The recommended way to do this, would be to create an ``inventory`` directory, and place both the ``rax.py`` script and a file containing ``localhost`` in it." -msgstr "前述したように、これらのモジュールのほとんどは、ホストループの外で実行されることが多いため、「localhost」を定義する必要があります。これを行うには、``inventory`` ディレクトリーを作成し、``rax.py`` スクリプトと、``localhost`` を含むファイルの両方をそのディレクトリーに置くことが推奨されます。" - -#: ../../rst/scenario_guides/guide_rax.rst:180 -msgid "Executing ``ansible`` or ``ansible-playbook`` and specifying the ``inventory`` directory instead of an individual file, will cause ansible to evaluate each file in that directory for inventory." -msgstr "``ansible`` または ``ansible-playbook`` を実行し、個別のファイルではなく ``inventory`` ディレクトリーを指定すると、Ansible はインベントリー用にそのディレクトリー内の各ファイルを評価します。" - -#: ../../rst/scenario_guides/guide_rax.rst:183 -msgid "Let's test our inventory script to see if it can talk to Rackspace Cloud." -msgstr "インベントリースクリプトをテストし、Rackspace Cloud と通信できるかどうかを確認します。" - -#: ../../rst/scenario_guides/guide_rax.rst:189 -msgid "Assuming things are properly configured, the ``rax.py`` inventory script will output information similar to the following information, which will be utilized for inventory and variables." -msgstr "設定が適切に行われていれば、``rax.py`` インベントリスクリプトは、インベントリーおよび変数に使用される以下のような情報と同様の情報を出力します。" - -#: ../../rst/scenario_guides/guide_rax.rst:287 -msgid "Standard Inventory" -msgstr "標準インベントリー" - -#: ../../rst/scenario_guides/guide_rax.rst:289 -msgid "When utilizing a standard ini formatted inventory file (as opposed to the inventory plugin), it may still be advantageous to retrieve discoverable hostvar information from the Rackspace API." -msgstr "(インベントリープラグインではなく) 標準の ini 形式のインベントリーファイルを使用する場合でも、検出可能な hostvar 情報を Rackspace API から取得すると有効な場合があります。" - -#: ../../rst/scenario_guides/guide_rax.rst:291 -msgid "This can be achieved with the ``rax_facts`` module and an inventory file similar to the following:" -msgstr "これは、``rax_facts`` モジュールと以下のようなインベントリーファイルで実現できます。" - -#: ../../rst/scenario_guides/guide_rax.rst:315 -msgid "While you don't need to know how it works, it may be interesting to know what kind of variables are returned." -msgstr "どのように機能するかを知る必要はありませんが、返される変数の種類を把握しておくといいでしょう、" - -#: ../../rst/scenario_guides/guide_rax.rst:317 -msgid "The ``rax_facts`` module provides facts as following, which match the ``rax.py`` inventory script:" -msgstr "``rax_facts`` モジュールは、``rax.py`` インベントリースクリプトに一致する以下のようなファクトを提供します。" - -#: ../../rst/scenario_guides/guide_rax.rst:408 -msgid "This section covers some additional usage examples built around a specific use case." -msgstr "本セクションでは、特定のユースケースを中心とした、その他の使用例を説明します。" - -#: ../../rst/scenario_guides/guide_rax.rst:413 -msgid "Network and Server" -msgstr "ネットワークおよびサーバー" - -#: ../../rst/scenario_guides/guide_rax.rst:415 -msgid "Create an isolated cloud network and build a server" -msgstr "分離したクラウドネットワークを作成し、サーバーを構築します。" - -#: ../../rst/scenario_guides/guide_rax.rst:455 -msgid "Complete Environment" -msgstr "完全な環境" - -#: ../../rst/scenario_guides/guide_rax.rst:457 -msgid "Build a complete webserver environment with servers, custom networks and load balancers, install nginx and create a custom index.html" -msgstr "サーバー、カスタムネットワーク、およびロードバランサーで完全な Web サーバー環境を構築し、nginx をインストールしてカスタムの index.html を作成します。" - -#: ../../rst/scenario_guides/guide_rax.rst:555 -msgid "RackConnect and Managed Cloud" -msgstr "RackConnect および Managed Cloud" - -#: ../../rst/scenario_guides/guide_rax.rst:557 -msgid "When using RackConnect version 2 or Rackspace Managed Cloud there are Rackspace automation tasks that are executed on the servers you create after they are successfully built. If your automation executes before the RackConnect or Managed Cloud automation, you can cause failures and unusable servers." -msgstr "RackConnect バージョン 2 または Rackspace Managed Cloud を使用する場合は、作成したサーバーが正常に構築された後に実行される Rackspace の自動化タスクがあります。その自動化が「RackConnect」または「Managed Cloud」の自動化よりも前に実行されてしまうと、障害が発生したり、サーバーが利用できなくなったりします。" - -#: ../../rst/scenario_guides/guide_rax.rst:559 -msgid "These examples show creating servers, and ensuring that the Rackspace automation has completed before Ansible continues onwards." -msgstr "これらの例は、サーバーを作成し、Ansible が続行する前に、Rackspace 自動化が完了したことを確認します。" - -#: ../../rst/scenario_guides/guide_rax.rst:561 -msgid "For simplicity, these examples are joined, however both are only needed when using RackConnect. When only using Managed Cloud, the RackConnect portion can be ignored." -msgstr "分かりやすくするために、この例は一緒になっていますが、どちらも RackConnect を使用する場合に限り必要です。Managed Cloud のみを使用する場合は、RackConnect の部分が無視されます。" - -#: ../../rst/scenario_guides/guide_rax.rst:563 -msgid "The RackConnect portions only apply to RackConnect version 2." -msgstr "RackConnect の部分は、RackConnect バージョン 2 にのみ適用されます。" - -#: ../../rst/scenario_guides/guide_rax.rst:568 -msgid "Using a Control Machine" -msgstr "コントロールマシンの使用" - -#: ../../rst/scenario_guides/guide_rax.rst:655 -msgid "Using Ansible Pull" -msgstr "Ansible Pull の使用" - -#: ../../rst/scenario_guides/guide_rax.rst:713 -msgid "Using Ansible Pull with XenStore" -msgstr "XenStore での Ansible Pull の使用" - -#: ../../rst/scenario_guides/guide_rax.rst:781 -msgid "Advanced Usage" -msgstr "高度な使用方法" - -#: ../../rst/scenario_guides/guide_rax.rst:786 -msgid "Autoscaling with Tower" -msgstr "Tower を使用した自動スケーリング" - -#: ../../rst/scenario_guides/guide_rax.rst:788 -msgid ":ref:`ansible_tower` also contains a very nice feature for auto-scaling use cases. In this mode, a simple curl script can call a defined URL and the server will \"dial out\" to the requester and configure an instance that is spinning up. This can be a great way to reconfigure ephemeral nodes. See the Tower documentation for more details." -msgstr "また、:ref:`ansible_tower` は、自動スケーリングのユースケースには非常に優れた機能も含まれています。このモードでは、簡単な curl スクリプトは定義された URL を呼び出すことができ、サーバーは要求元に対して「ダイヤルアウト」し、起動しているインスタンスを構成します。これは、一時ノードを再設定する優れた方法になります。詳細は、Tower ドキュメントを参照してください。" - -#: ../../rst/scenario_guides/guide_rax.rst:799 -msgid "Orchestration in the Rackspace Cloud" -msgstr "Rackspace Cloud のオーケストレーション" - -#: ../../rst/scenario_guides/guide_rax.rst:801 -msgid "Ansible is a powerful orchestration tool, and rax modules allow you the opportunity to orchestrate complex tasks, deployments, and configurations. The key here is to automate provisioning of infrastructure, like any other piece of software in an environment. Complex deployments might have previously required manual manipulation of load balancers, or manual provisioning of servers. Utilizing the rax modules included with Ansible, one can make the deployment of additional nodes contingent on the current number of running nodes, or the configuration of a clustered application dependent on the number of nodes with common metadata. One could automate the following scenarios, for example:" -msgstr "Ansible は強力なオーケストレーションツールであり、rax モジュールを使用することで、複雑なタスク、デプロイメント、および設定のオーケストレーションが可能になります。ここでは、環境内にある他のソフトウェアと同様、インフラストラクチャーのプロビジョニングを自動化することが重要になります。複雑なデプロイメントを行う場合、これまではロードバランサーを手動で操作したり、サーバーのプロビジョニングを手動で行う必要があったかもしれません。Ansible に含まれる rax モジュールを利用すると、現在稼働しているノードの数に応じてノードを追加したり、共通のメタデータを使用してノードの数に応じてクラスター化されたアプリケーションを構成したりすることができます。たとえば、以下のようなシナリオを自動化できます。" - -#: ../../rst/scenario_guides/guide_rax.rst:803 -msgid "Servers that are removed from a Cloud Load Balancer one-by-one, updated, verified, and returned to the load balancer pool" -msgstr "Cloud Load Balancer から 1 つずつ削除され、更新され、検証され、ロードバランサープールに返されるサーバー" - -#: ../../rst/scenario_guides/guide_rax.rst:804 -msgid "Expansion of an already-online environment, where nodes are provisioned, bootstrapped, configured, and software installed" -msgstr "ノードのプロビジョニング、ブートストラップ、設定、およびソフトウェアがインストールされている、すでにオンラインの環境の拡張" - -#: ../../rst/scenario_guides/guide_rax.rst:805 -msgid "A procedure where app log files are uploaded to a central location, like Cloud Files, before a node is decommissioned" -msgstr "ノードが非推奨になる前に、アプリケーションログファイルが中央の場所 (Cloud Files など) にアップロードされる手順" - -#: ../../rst/scenario_guides/guide_rax.rst:806 -msgid "Servers and load balancers that have DNS records created and destroyed on creation and decommissioning, respectively" -msgstr "作成時に DNS レコードが作成され、廃止時に破棄されるサーバーとロードバランサー" - -#: ../../rst/scenario_guides/guide_scaleway.rst:5 -msgid "Scaleway Guide" -msgstr "Scaleway ガイド" - -#: ../../rst/scenario_guides/guide_scaleway.rst:12 -msgid "`Scaleway `_ is a cloud provider supported by Ansible, version 2.6 or higher via a dynamic inventory plugin and modules. Those modules are:" -msgstr "`Scaleway `_ は、動的インベントリープラグインおよびモジュールを介して Ansible (バージョン 2.6 以降) が対応するクラウドプロバイダーです。このモジュールは以下のようになります。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:15 -msgid ":ref:`scaleway_sshkey_module`: adds a public SSH key from a file or value to the Packet infrastructure. Every subsequently-created device will have this public key installed in .ssh/authorized_keys." -msgstr ":ref:`scaleway_sshkey_module`: ファイルまたは値から Packet インフラストラクチャーに公開 SSH 鍵を追加します。後に作成したすべてのデバイスの .ssh/authorized_keys にこの公開鍵がインストールされます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:16 -msgid ":ref:`scaleway_compute_module`: manages servers on Scaleway. You can use this module to create, restart and delete servers." -msgstr ":ref:`scaleway_compute_module`: Scaleway でサーバーを管理します。このモジュールを使用してサーバーを作成、再起動、および削除できます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:17 -msgid ":ref:`scaleway_volume_module`: manages volumes on Scaleway." -msgstr ":ref:`scaleway_volume_module`: Scaleway でボリュームを管理します。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:20 -msgid "This guide assumes you are familiar with Ansible and how it works. If you're not, have a look at :ref:`ansible_documentation` before getting started." -msgstr "本ガイドでは、Ansible に精通していることを前提としています。Ansible にあまり精通していない場合は、開始する前に「:ref:`ansible_documentation`」をお読みください。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:28 -msgid "The Scaleway modules and inventory script connect to the Scaleway API using `Scaleway REST API `_. To use the modules and inventory script you'll need a Scaleway API token. You can generate an API token via the Scaleway console `here `__. The simplest way to authenticate yourself is to set the Scaleway API token in an environment variable:" -msgstr "Scaleway モジュールとインベントリースクリプトは、`Scaleway REST API `_ を使用して Scaleway API に接続します。モジュールとインベントリースクリプトを使用するには、Scaleway API トークンが必要です。API トークンは、Scaleway コンソール (`こちら `__) で生成できます。自身を認証する最も簡単な方法は、環境変数に Scaleway API トークンを設定することです。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:37 -msgid "If you're not comfortable exporting your API token, you can pass it as a parameter to the modules using the ``api_token`` argument." -msgstr "API トークンのエクスポートに抵抗がある場合は、``api_token`` 引数を使用してこれをパラメーターとしてモジュールに渡すことができます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:50 -msgid "How to add an SSH key?" -msgstr "SSH キーの追加方法" - -#: ../../rst/scenario_guides/guide_scaleway.rst:52 -msgid "Connection to Scaleway Compute nodes use Secure Shell. SSH keys are stored at the account level, which means that you can re-use the same SSH key in multiple nodes. The first step to configure Scaleway compute resources is to have at least one SSH key configured." -msgstr "Scaleway コンピュートノードへの接続は、Secure Shell を使用します。SSH キーはアカウントレベルに保存されるため、同じ SSH キーを複数のノードで再利用できます。Scaleway コンピュートリソースを設定する最初の手順は、少なくとも 1 つの SSH キーを設定することです。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:56 -msgid ":ref:`scaleway_sshkey_module` is a module that manages SSH keys on your Scaleway account. You can add an SSH key to your account by including the following task in a playbook:" -msgstr ":ref:`scaleway_sshkey_module` は、Scaleway アカウントで SSH キーを管理するモジュールです。SSH キーは、Playbook に以下のタスクを含めることでアカウントに追加できます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:66 -msgid "The ``ssh_pub_key`` parameter contains your ssh public key as a string. Here is an example inside a playbook:" -msgstr "``ssh_pub_key`` パラメーターには、文字列として ssh 公開鍵が含まれます。これは、Playbook 内の例です。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:91 -msgid "How to create a compute instance?" -msgstr "コンピュートインスタンスの作成方法" - -#: ../../rst/scenario_guides/guide_scaleway.rst:93 -msgid "Now that we have an SSH key configured, the next step is to spin up a server! :ref:`scaleway_compute_module` is a module that can create, update and delete Scaleway compute instances:" -msgstr "これで SSH キーが設定されたため、次の手順ではサーバーを起動します。:ref:`scaleway_compute_module` は、Scaleway コンピュートインスタンスの作成、更新、および削除が可能なモジュールです。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:107 -msgid "Here are the parameter details for the example shown above:" -msgstr "以下は、上述のパラメーターの詳細です。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:109 -msgid "``name`` is the name of the instance (the one that will show up in your web console)." -msgstr "``name`` インスタンスの名前 (Web コンソールに表示されるもの)。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:110 -msgid "``image`` is the UUID of the system image you would like to use. A list of all images is available for each availability zone." -msgstr "``image`` は、使用するシステムイメージの UUID です。各アベイラビリティーゾーンでイメージ一覧が利用できます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:112 -msgid "``organization`` represents the organization that your account is attached to." -msgstr "``organization`` アカウントを登録している組織を表します。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:113 -msgid "``region`` represents the Availability Zone which your instance is in (for this example, par1 and ams1)." -msgstr "``region`` は、インスタンスが存在するアベイラビリティーゾーン (例: par1 および ams1) を表します。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:114 -msgid "``commercial_type`` represents the name of the commercial offers. You can check out the Scaleway pricing page to find which instance is right for you." -msgstr "``commercial_type`` は、販売サービスの名前を表します。Scaleway 価格ページでは、どのインスタンスが適しているかを確認できます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:117 -msgid "Take a look at this short playbook to see a working example using ``scaleway_compute``:" -msgstr "この短い Playbook を参照して、``scaleway_compute`` を使用した作業例を確認してください。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:172 -msgid "Ansible ships with :ref:`scaleway_inventory`. You can now get a complete inventory of your Scaleway resources through this plugin and filter it on different parameters (``regions`` and ``tags`` are currently supported)." -msgstr "Ansible には :ref:`scaleway_inventory` が同梱されます。このプラグインを介して、Scaleway リソースの完全なインベントリーを取得し、異なるパラメーターでフィルターできるようになりました (``regions`` および ``tags`` は現在サポートされています)。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:176 -msgid "Let's create an example! Suppose that we want to get all hosts that got the tag web_server. Create a file named ``scaleway_inventory.yml`` with the following content:" -msgstr "以下に例を示します。web_server タグを付けたすべてのホストを取得します。以下の内容で ``scaleway_inventory.yml`` という名前のファイルを作成します。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:189 -msgid "This inventory means that we want all hosts that got the tag ``web_server`` on the zones ``ams1`` and ``par1``. Once you have configured this file, you can get the information using the following command:" -msgstr "このインベントリーは、``ams1`` ゾーンおよび ``par1`` ゾーンでタグ ``web_server`` を取得したすべてのホストが必要なことを示しています。このファイルを設定したら、以下のコマンドを使用して情報を取得できます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:196 -msgid "The output will be:" -msgstr "出力は以下のようになります。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:239 -msgid "As you can see, we get different groups of hosts. ``par1`` and ``ams1`` are groups based on location. ``web_server`` is a group based on a tag." -msgstr "ご覧のとおり、ホストのグループが異なります。``par1`` および ``ams1`` は場所に基づいたグループです。``web_server`` は、タグに基づいたグループです。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:243 -msgid "In case a filter parameter is not defined, the plugin supposes all values possible are wanted. This means that for each tag that exists on your Scaleway compute nodes, a group based on each tag will be created." -msgstr "フィルターパラメーターが定義されていないと、プラグインは可能な値がすべて必要であると想定します。これにより、Scaleway コンピュートノードに存在するタグごとに、各タグに基づいたグループが作成されます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:247 -msgid "Scaleway S3 object storage" -msgstr "Scaleway S3 オブジェクトストレージ" - -#: ../../rst/scenario_guides/guide_scaleway.rst:249 -msgid "`Object Storage `_ allows you to store any kind of objects (documents, images, videos, and so on). As the Scaleway API is S3 compatible, Ansible supports it natively through the modules: :ref:`s3_bucket_module`, :ref:`aws_s3_module`." -msgstr "`Object Storage `_ を使用すると、あらゆる種類のオブジェクト (ドキュメント、イメージ、録画など) を保存できます。Scaleway API は S3 互換であるため、Ansible はモジュール :ref:`s3_bucket_module`、:ref:`aws_s3_module` でネイティブにサポートします。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:252 -msgid "You can find many examples in the `scaleway_s3 integration tests `_." -msgstr "`scaleway_s3 統合ゲスト `_ に、例が多数あります。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:2 -msgid "Vagrant Guide" -msgstr "Vagrant ガイド" - -#: ../../rst/scenario_guides/guide_vagrant.rst:9 -msgid "`Vagrant `_ is a tool to manage virtual machine environments, and allows you to configure and use reproducible work environments on top of various virtualization and cloud platforms. It also has integration with Ansible as a provisioner for these virtual machines, and the two tools work together well." -msgstr "`Vagrant `_ は、仮想マシン環境を管理するためのツールで、さまざまな仮想化やクラウドプラットフォームで、再現性のある作業環境を構成して利用することができます。また、これらの仮想マシンのプロビジョナーとして Ansible と連携しており、2 つのツールが適切に連携しています。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:15 -msgid "This guide will describe how to use Vagrant 1.7+ and Ansible together." -msgstr "本ガイドでは、Vagrant 1.7 以降および Ansible を一緒に使用する方法を説明します。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:17 -msgid "If you're not familiar with Vagrant, you should visit `the documentation `_." -msgstr "Vagrant に精通していない場合は、`the documentation `_ にアクセスする必要があります。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:20 -msgid "This guide assumes that you already have Ansible installed and working. Running from a Git checkout is fine. Follow the :ref:`installation_guide` guide for more information." -msgstr "本ガイドでは、すでに Ansible がインストールされ、動作していることを前提としています。Git checkout からの実行も可能です。詳細は、「:ref:`installation_guide`」ガイドを参照してください。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:27 -msgid "Vagrant Setup" -msgstr "Vagrant 設定" - -#: ../../rst/scenario_guides/guide_vagrant.rst:29 -msgid "The first step once you've installed Vagrant is to create a ``Vagrantfile`` and customize it to suit your needs. This is covered in detail in the Vagrant documentation, but here is a quick example that includes a section to use the Ansible provisioner to manage a single machine:" -msgstr "Vagrant をインストールしたらまず、``Vagrantfile`` を作成し、ニーズに合わせてカスタマイズすることになります。これについては Vagrant のドキュメントで詳しく説明されていますが、ここでは簡単な例として、Ansible プロビジョナーを使用して 1 台のマシンを管理するセクションを紹介します。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:50 -msgid "Notice the ``config.vm.provision`` section that refers to an Ansible playbook called ``playbook.yml`` in the same directory as the ``Vagrantfile``. Vagrant runs the provisioner once the virtual machine has booted and is ready for SSH access." -msgstr "``Vagrantfile`` と同じディレクトリーにある ``playbook.yml`` という名前の Ansible Playbook を参照している ``config.vm.provision`` セクションに注目してください。Vagrant は、仮想マシンが起動し、SSH アクセスの準備が整ったらプロビジョナーを実行します。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:55 -msgid "There are a lot of Ansible options you can configure in your ``Vagrantfile``. Visit the `Ansible Provisioner documentation `_ for more information." -msgstr "``Vagrantfile`` で設定できる Ansible オプションが多数あります。詳細は、`Ansible Provisioner ドキュメント `_ を参照してください。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:64 -msgid "This will start the VM, and run the provisioning playbook (on the first VM startup)." -msgstr "これにより、仮想マシンが起動し、(最初の仮想マシンの起動で) プロビジョニング Playbook を実行します。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:68 -msgid "To re-run a playbook on an existing VM, just run:" -msgstr "既存の仮想マシンで Playbook を再実行するには、以下を実行します。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:74 -msgid "This will re-run the playbook against the existing VM." -msgstr "これにより、Playbook が既存の仮想マシンに対して再実行されます。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:76 -msgid "Note that having the ``ansible.verbose`` option enabled will instruct Vagrant to show the full ``ansible-playbook`` command used behind the scene, as illustrated by this example:" -msgstr "``ansible.verbose`` オプションを有効にすると、以下の例のように、内部で使用される ``ansible-playbook`` コマンド全体を表示するよう Vagrant に指示することに注意してください。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:84 -msgid "This information can be quite useful to debug integration issues and can also be used to manually execute Ansible from a shell, as explained in the next section." -msgstr "この情報は、統合の問題のデバッグに非常に便利です。また、次のセクションで説明されているように、シェルから Ansible を手動で実行するために使用できます。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:91 -msgid "Running Ansible Manually" -msgstr "Ansible の手動実行" - -#: ../../rst/scenario_guides/guide_vagrant.rst:93 -msgid "Sometimes you may want to run Ansible manually against the machines. This is faster than kicking ``vagrant provision`` and pretty easy to do." -msgstr "マシンに対して手動で Ansible を実行したい場合があります。これは、``vagrant provision`` を実行するよりも速く、非常に簡単にできます。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:96 -msgid "With our ``Vagrantfile`` example, Vagrant automatically creates an Ansible inventory file in ``.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory``. This inventory is configured according to the SSH tunnel that Vagrant automatically creates. A typical automatically-created inventory file for a single machine environment may look something like this:" -msgstr "``Vagrantfile`` の例では、Vagrant が ``.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory`` に Ansible インベントリーファイルを自動的に作成します。このインベントリーは Vagrant が自動的に作成する SSH トンネルに従って設定されます。シングルマシン環境用で典型的な自動作成されたインベントリーファイルは、以下のようになります。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:108 -msgid "If you want to run Ansible manually, you will want to make sure to pass ``ansible`` or ``ansible-playbook`` commands the correct arguments, at least for the *inventory*." -msgstr "Ansible を手動で実行する場合は、少なくとも *インベントリー* 対して、``ansible`` コマンドまたは ``ansible-playbook`` コマンドに正しい引数を渡す必要があります。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:117 -msgid "Advanced Usages" -msgstr "高度な使用方法" - -#: ../../rst/scenario_guides/guide_vagrant.rst:119 -msgid "The \"Tips and Tricks\" chapter of the `Ansible Provisioner documentation `_ provides detailed information about more advanced Ansible features like:" -msgstr "`Ansible Provisioner ドキュメント `_ の「ヒントおよび裏技」の章では、以下のような高度な Ansible 機能に関する詳細情報が提供されています。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:122 -msgid "how to execute a playbook in parallel within a multi-machine environment" -msgstr "マルチマシン環境内で Playbook を並行して実行する方法" - -#: ../../rst/scenario_guides/guide_vagrant.rst:123 -msgid "how to integrate a local ``ansible.cfg`` configuration file" -msgstr "ローカルの ``ansible.cfg`` 設定ファイルを統合する方法" - -#: ../../rst/scenario_guides/guide_vagrant.rst:127 -msgid "`Vagrant Home `_" -msgstr "`Vagrant ホーム `_" - -#: ../../rst/scenario_guides/guide_vagrant.rst:128 -msgid "The Vagrant homepage with downloads" -msgstr "ダウンロードを含む Vagrant ホームページ" - -#: ../../rst/scenario_guides/guide_vagrant.rst:129 -msgid "`Vagrant Documentation `_" -msgstr "`Vagrant ドキュメント `_" - -#: ../../rst/scenario_guides/guide_vagrant.rst:130 -msgid "Vagrant Documentation" -msgstr "Vagrant ドキュメント" - -#: ../../rst/scenario_guides/guide_vagrant.rst:131 -msgid "`Ansible Provisioner `_" -msgstr "`Ansible Provisioner `_" - -#: ../../rst/scenario_guides/guide_vagrant.rst:132 -msgid "The Vagrant documentation for the Ansible provisioner" -msgstr "Ansible プロビジョナーの Vagrant ドキュメント" - -#: ../../rst/scenario_guides/guide_vagrant.rst:133 -#, python-format -msgid "`Vagrant Issue Tracker `_" -msgstr "`Vagrant Issue Tracker `_" - -#: ../../rst/scenario_guides/guide_vagrant.rst:134 -msgid "The open issues for the Ansible provisioner in the Vagrant project" -msgstr "Vagrant プロジェクトでの Ansible プロビジョナーに関する未解決な問題" - -#: ../../rst/scenario_guides/guide_vmware.rst:5 -msgid "VMware Guide" -msgstr "VMware ガイド" - -#: ../../rst/scenario_guides/guide_vmware.rst:7 -msgid "Welcome to the Ansible for VMware Guide!" -msgstr "VMware 向け Ansible ガイドでようこそ!" - -#: ../../rst/scenario_guides/guide_vmware.rst:9 -msgid "The purpose of this guide is to teach you everything you need to know about using Ansible with VMware." -msgstr "本ガイドの目的は、VMware で Ansible を使用する際に必要な知識を学習することです。" - -#: ../../rst/scenario_guides/guide_vmware_rest.rst:5 -msgid "VMware REST Scenarios" -msgstr "VMware REST シナリオ" - -#: ../../rst/scenario_guides/guide_vmware_rest.rst:7 -msgid "These scenarios teach you how to accomplish common VMware tasks using the REST API and the Ansible ``vmware.vmware_rest`` collection. To get started, please select the task you want to accomplish." -msgstr "これらのシナリオは、REST API と Ansible ``vmware.vmware_rest`` コレクションを使用して一般的な VMware タスクを実現する方法を説明します。開始するには、達成するタスクを選択してください。" - -#: ../../rst/scenario_guides/guide_vultr.rst:2 -msgid "Vultr Guide" -msgstr "Vultr ガイド" - -#: ../../rst/scenario_guides/guide_vultr.rst:4 -msgid "Ansible offers a set of modules to interact with `Vultr `_ cloud platform." -msgstr "Ansible は、`Vultr `_ クラウドプラットフォームと対話するためのモジュールセットを提供します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:6 -msgid "This set of module forms a framework that allows one to easily manage and orchestrate one's infrastructure on Vultr cloud platform." -msgstr "このモジュールセットは、Vultr クラウドプラットフォームのインフラストラクチャーを簡単に管理および調整できるようにするフレームワークを形成します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:12 -msgid "There is actually no technical requirement; simply an already created Vultr account." -msgstr "技術的要件はありません。すでに作成されている Vultr アカウントが必要です。" - -#: ../../rst/scenario_guides/guide_vultr.rst:18 -msgid "Vultr modules offer a rather flexible way with regard to configuration." -msgstr "Vultr モジュールは、設定に関してかなり柔軟な方法を提供します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:20 -msgid "Configuration is read in that order:" -msgstr "設定は、以下の順序で読み込まれます。" - -#: ../../rst/scenario_guides/guide_vultr.rst:22 -msgid "Environment Variables (eg. ``VULTR_API_KEY``, ``VULTR_API_TIMEOUT``)" -msgstr "環境変数 (例: ``VULTR_API_KEY``、``VULTR_API_TIMEOUT``)" - -#: ../../rst/scenario_guides/guide_vultr.rst:23 -msgid "File specified by environment variable ``VULTR_API_CONFIG``" -msgstr "環境変数 ``VULTR_API_CONFIG`` で指定されるファイル" - -#: ../../rst/scenario_guides/guide_vultr.rst:24 -msgid "``vultr.ini`` file located in current working directory" -msgstr "現在の作業ディレクトリーにある ``vultr.ini`` ファイル" - -#: ../../rst/scenario_guides/guide_vultr.rst:25 -msgid "``$HOME/.vultr.ini``" -msgstr "``$HOME/.vultr.ini``" - -#: ../../rst/scenario_guides/guide_vultr.rst:28 -msgid "Ini file are structured this way:" -msgstr "ini ファイルは以下のような構成になっています。" - -#: ../../rst/scenario_guides/guide_vultr.rst:41 -msgid "If ``VULTR_API_ACCOUNT`` environment variable or ``api_account`` module parameter is not specified, modules will look for the section named \"default\"." -msgstr "``VULTR_API_ACCOUNT`` 環境変数または ``api_account`` モジュールパラメーターが指定されていない場合、モジュールは「default」という名前のセクションを探します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:47 -msgid "Before using the Ansible modules to interact with Vultr, ones need an API key. If one doesn't own one yet, log in to `Vultr `_ go to Account, then API, enable API then the API key should show up." -msgstr "Ansible モジュールを使用して Vultr と対話する前に、API キーが必要です。API キーを所有していない場合は、`Vultr `_ にログインしてアカウントに移動して API を有効にすると、API キーが表示されるはずです。" - -#: ../../rst/scenario_guides/guide_vultr.rst:50 -msgid "Ensure you allow the usage of the API key from the proper IP addresses." -msgstr "適切な IP アドレスから API キーを使用できるようにします。" - -#: ../../rst/scenario_guides/guide_vultr.rst:52 -msgid "Refer to the Configuration section to find out where to put this information." -msgstr "この情報をどこに置くかは、「構成」セクションを参照してください。" - -#: ../../rst/scenario_guides/guide_vultr.rst:54 -msgid "To check that everything is working properly run the following command:" -msgstr "すべてが適切に機能していることを確認するには、次のコマンドを実行します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:76 -msgid "If a similar output displays then everything is setup properly, else please ensure the proper ``VULTR_API_KEY`` has been specified and that Access Control on Vultr > Account > API page are accurate." -msgstr "同様の出力が表示され、すべての設定が適切に行われた場合は、適切な ``VULTR_API_KEY`` が正しく指定されており、Vultr > Account > API ページのアクセス制御が正確であることを確認してください。" - -#: ../../rst/scenario_guides/guide_vultr.rst:80 -msgid "Usage" -msgstr "使用法" - -#: ../../rst/scenario_guides/guide_vultr.rst:82 -msgid "Since `Vultr `_ offers a public API, the execution of the module to manage the infrastructure on their platform will happen on localhost. This translates to:" -msgstr "`Vultr `_ は、パブリック API を提供するため、プラットフォーム上のインフラストラクチャーを管理するためのモジュールの実行はローカルホストで行われます。これは、以下に変換されます。" - -#: ../../rst/scenario_guides/guide_vultr.rst:96 -msgid "From that point on, only your creativity is the limit. Make sure to read the documentation of the `available modules `_." -msgstr "これ以降は、ユーザーの創造性だけが限界となります。`利用可能なモジュール `_ のドキュメントを確認してください。" - -#: ../../rst/scenario_guides/guide_vultr.rst:100 -msgid "Dynamic Inventory" -msgstr "動的インベントリー" - -#: ../../rst/scenario_guides/guide_vultr.rst:102 -msgid "Ansible provides a dynamic inventory plugin for `Vultr `_. The configuration process is exactly the same as the one for the modules." -msgstr "Ansible は、`Vultr `_ の動的インベントリープラグインを提供します。設定プロセスは、モジュールの場合と同じです。" - -#: ../../rst/scenario_guides/guide_vultr.rst:105 -msgid "To be able to use it you need to enable it first by specifying the following in the ``ansible.cfg`` file:" -msgstr "これを使用できるようにするには、``ansible.cfg`` ファイルで以下を指定して、まず有効にする必要があります。" - -#: ../../rst/scenario_guides/guide_vultr.rst:112 -msgid "And provide a configuration file to be used with the plugin, the minimal configuration file looks like this:" -msgstr "また、プラグインで使用する設定ファイルを提供します。最小設定ファイルは以下のようになります。" - -#: ../../rst/scenario_guides/guide_vultr.rst:119 -msgid "To list the available hosts one can simply run:" -msgstr "利用可能なホストを一覧表示するには、以下を実行します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:126 -msgid "For example, this allows you to take action on nodes grouped by location or OS name:" -msgstr "たとえば、これにより、場所別または OS 名別にグループにまとめたノードでアクションを実行できます。" - -#: ../../rst/scenario_guides/guide_vultr.rst:139 -msgid "Integration tests" -msgstr "統合テスト" - -#: ../../rst/scenario_guides/guide_vultr.rst:141 -msgid "Ansible includes integration tests for all Vultr modules." -msgstr "Ansible には、すべての Vultr モジュールの統合テストが含まれます。" - -#: ../../rst/scenario_guides/guide_vultr.rst:143 -msgid "These tests are meant to run against the public Vultr API and that is why they require a valid key to access the API." -msgstr "このテストは、パブリックの Vultr API に対して実行されることが意図されていますが、これは API にアクセスするために有効なキーを必要とするためです。" - -#: ../../rst/scenario_guides/guide_vultr.rst:145 -msgid "Prepare the test setup:" -msgstr "テスト設定を準備します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:152 -msgid "Set the Vultr API key:" -msgstr "Vultr API キーを設定します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:160 -msgid "Run all Vultr tests:" -msgstr "すべての Vultr テストを実行します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:167 -msgid "To run a specific test, for example vultr_account_info:" -msgstr "特定のテスト (例: vultr_account_info) を実行するには、以下を実行します。" - -#: ../../rst/scenario_guides/guides.rst:28 -#: ../../rst/scenario_guides/network_guides.rst:5 -msgid "Network Technology Guides" -msgstr "ネットワークテクノロジーガイド" - -#: ../../rst/scenario_guides/guides.rst:36 -msgid "Virtualization & Containerization Guides" -msgstr "仮想化およびコンテナー化ガイド" - -#: ../../rst/scenario_guides/guides.rst:7 -msgid "Scenario Guides" -msgstr "シナリオガイド" - -#: ../../rst/scenario_guides/guides.rst:9 -msgid "The guides in this section cover integrating Ansible with a variety of platforms, products, and technologies. They explore particular use cases in greater depth and provide a more \"top-down\" explanation of some basic features." -msgstr "本セクションのガイドでは、Ansible とさまざまなプラットフォーム、製品、およびテクノロジーの統合を説明します。特定のユースケースをより深く掘り下げ、いくつかの基本的な機能を「トップダウン」で説明します。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:5 -msgid "Introduction to Ansible for Kubernetes" -msgstr "Kubernetes 向け Ansible の概要" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:13 -msgid "Modules for interacting with the Kubernetes (K8s) and OpenShift API are under development, and can be used in preview mode. To use them, review the requirements, and then follow the installation and use instructions." -msgstr "Kubernetes (K8s) および OpenShift API と対話するためのモジュールは開発中であり、プレビューモードで使用することができます。このモジュールを使用するには、要件を確認し、インストールおよび指示に従ってください。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:18 -msgid "To use the modules, you'll need the following:" -msgstr "モジュールを使用するには、以下が必要になります。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:20 -msgid "Run Ansible from source. For assistance, view :ref:`from_source`." -msgstr "ソースから Ansible を実行します。サポートについては、「:ref:`from_source`」をご覧ください。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:21 -msgid "`OpenShift Rest Client `_ installed on the host that will execute the modules." -msgstr "`OpenShift Rest クライアント ` が、モジュールを実行するホストにインストールされている。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:27 -msgid "The Kubernetes modules are part of the `Ansible Kubernetes collection `_." -msgstr "Kubernetes モジュールは、`Ansible Kubernetes コレクション `_ の一部です。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:29 -msgid "To install the collection, run the following:" -msgstr "コレクションをインストールするには、以下を実行します。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:37 -msgid "Authenticating with the API" -msgstr "API での認証" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:39 -msgid "By default the OpenShift Rest Client will look for ``~/.kube/config``, and if found, connect using the active context. You can override the location of the file using the``kubeconfig`` parameter, and the context, using the ``context`` parameter." -msgstr "デフォルトでは、OpenShift Rest Client は ``~/.kube/config`` を検索し、見つかった場合はアクティブなコンテキストを使用して接続します。``kubeconfig`` パラメーターを使用してファイルの場所を上書きし、``context`` パラメーターを使用してコンテキストを上書きできます。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:41 -msgid "Basic authentication is also supported using the ``username`` and ``password`` options. You can override the URL using the ``host`` parameter. Certificate authentication works through the ``ssl_ca_cert``, ``cert_file``, and ``key_file`` parameters, and for token authentication, use the ``api_key`` parameter." -msgstr "Basic 認証は、``username`` オプションおよび ``password`` オプションを使用してもサポートされます。``host`` パラメーターを使用して URL を上書きできます。証明書認証は、``ssl_ca_cert`` パラメーター、``cert_file`` パラメーター、および ``key_file`` パラメーターで機能します。また、トークン認証には ``api_key`` パラメーターを使用します。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:43 -msgid "To disable SSL certificate verification, set ``verify_ssl`` to false." -msgstr "SSL 証明書の検証を無効にするには、``verify_ssl`` を false に設定します。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:46 -msgid "Reporting an issue" -msgstr "問題の報告" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_intro.rst:48 -msgid "If you find a bug or have a suggestion regarding modules, please file issues at `Ansible Kubernetes collection `_. If you find a bug regarding OpenShift client, please file issues at `OpenShift REST Client issues `_. If you find a bug regarding Kubectl binary, please file issues at `Kubectl issue tracker `_" -msgstr "バグが見つかった場合やモジュールに関する提案をお寄せいただける場合は、`Ansible Kubernetes コレクション `_ にファイルの問題を報告してください。OpenShift クライアントに関するバグが見つかった場合は、`OpenShift REST クライアントの問題 `_ に問題を作成してください。Kubectl バイナリーに関するバグは、`Kubectl issue tracker `_ で問題を作成してください。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:5 -msgid "Using Kubernetes dynamic inventory plugin" -msgstr "Kubernetes 動的インベントリープラグインの使用" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:11 -msgid "Kubernetes dynamic inventory plugin" -msgstr "Kubernetes 動的インベントリープラグイン" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:14 -msgid "The best way to interact with your Pods is to use the Kubernetes dynamic inventory plugin, which dynamically queries Kubernetes APIs using ``kubectl`` command line available on controller node and tells Ansible what Pods can be managed." -msgstr "Pod と対話する最適な方法として、Kubernetes 動的インベントリープラグインを使用します。これは、コントローラーノードで利用可能な ``kubectl`` コマンドラインを使用して Kubernetes API を動的にクエリーし、Ansible で管理できる Pod を示します。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:19 -msgid "To use the Kubernetes dynamic inventory plugins, you must install `Kubernetes Python client `_, `kubectl `_ and `OpenShift Python client `_ on your control node (the host running Ansible)." -msgstr "Kubernetes の動的インベントリープラグインを使用するには、`Kubernetes Python クライアント `_、`kubectl `_、および `OpenShift Python client `_ をコントロールノード (Ansible を実行するホスト) にインストールする必要があります。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:26 -msgid "Please refer to Kubernetes official documentation for `installing kubectl `_ on the given operating systems." -msgstr "該当するオペレーティングシステムでは、`kubectl のインストール `_ の Kubernetes の公式ドキュメントを参照してください。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:28 -msgid "To use this Kubernetes dynamic inventory plugin, you need to enable it first by specifying the following in the ``ansible.cfg`` file:" -msgstr "この Kubernetes 動的インベントリープラグインを使用するには、``ansible.cfg`` ファイルで以下を指定して、まずこれを有効にする必要があります。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:35 -msgid "Then, create a file that ends in ``.k8s.yml`` or ``.k8s.yaml`` in your working directory." -msgstr "次に、作業ディレクトリーに、名前の末尾が ``.k8s.yml`` または ``.k8s.yaml`` で終わるファイルを作成します。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:37 -msgid "The ``community.kubernetes.k8s`` inventory plugin takes in the same authentication information as any other Kubernetes modules." -msgstr "``community.kubernetes.k8s`` インベントリープラグインは、他の Kubernetes モジュールと同じ認証情報を取得します。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:45 -msgid "Executing ``ansible-inventory --list -i .k8s.yml`` will create a list of Pods that are ready to be configured using Ansible." -msgstr "``ansible-inventory --list -i .k8s.yml`` を実行すると、Ansible を使用して設定できる Pod の一覧が作成されます。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:47 -msgid "You can also provide the namespace to gather information about specific pods from the given namespace. For example, to gather information about Pods under the ``test`` namespace you will specify the ``namespaces`` parameter:" -msgstr "また、指定された名前空間から特定の Pod に関する情報を収集する名前空間を提供することもできます。たとえば、``test`` 名前空間で Pod に関する情報を収集するには、``namespaces`` パラメーターを指定します。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:57 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:57 -msgid "Using vaulted configuration files" -msgstr "Vault が設定された設定ファイルの使用" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:59 -msgid "Since the inventory configuration file contains Kubernetes related sensitive information in plain text, a security risk, you may want to encrypt your entire inventory configuration file." -msgstr "インベントリー設定ファイルには、Kubernetes 関連の機密情報がプレーンテキストで含まれるため、セキュリティー上のリスクがあります。インベントリー設定ファイル全体を暗号化できます。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:62 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:62 -msgid "You can encrypt a valid inventory configuration file as follows:" -msgstr "有効なインベントリー設定ファイルは以下のように暗号化できます。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:73 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:71 -msgid "And you can use this vaulted inventory configuration file using:" -msgstr "また、以下を使用して、Vault が設定されたこのインベントリー設定ファイルを使用できます。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:82 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:77 -msgid "`Kubernetes Python client `_" -msgstr "`Kubernetes Python クライアント `_" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:83 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:78 -msgid "The GitHub Page of Kubernetes Python client" -msgstr "Kubernetes Python クライアントの GitHub ページ" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:84 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:79 -msgid "`Kubernetes Python client - Issue Tracker `_" -msgstr "`Kubernetes Python クライアント - Issue Tracker `_" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:85 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:80 -msgid "The issue tracker for Kubernetes Python client" -msgstr "Kubernetes Python クライアントの問題トラッカー" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:86 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:81 -msgid "`OpenShift Python client `_" -msgstr "`OpenShift Python クライアント `_" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:87 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:82 -msgid "The GitHub Page of OpenShift Dynamic API client" -msgstr "OpenShift Dynamic API クライアントの GitHub ページ" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:88 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:83 -msgid "`OpenShift Python client - Issue Tracker `_" -msgstr "`OpenShift Python クライアント - Issue Tracker `_" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:89 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:84 -msgid "The issue tracker for OpenShift Dynamic API client" -msgstr "OpenShift Dynamic API クライアントの問題トラッカー" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:90 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:85 -msgid "`Kubectl installation `_" -msgstr "`Kubectl インストール `_" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:91 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:86 -msgid "Installation guide for installing Kubectl" -msgstr "Kubectl をインストールするためのインストールガイド" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:94 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:89 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:90 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:215 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:127 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1183 -msgid ":ref:`playbooks_vault`" -msgstr ":ref:`playbooks_vault`" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_inventory.rst:95 -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:90 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:91 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:216 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:128 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1184 -msgid "Using Vault in playbooks" -msgstr "Playbook での Vault の使用" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_scenarios.rst:5 -msgid "Ansible for Kubernetes Scenarios" -msgstr "Kubernetes シナリオにおける Ansible" - -#: ../../rst/scenario_guides/kubernetes_scenarios/k8s_scenarios.rst:7 -msgid "These scenarios teach you how to accomplish common Kubernetes tasks using Ansible. To get started, please select the task you want to accomplish." -msgstr "これらのシナリオは、Ansible を使用して一般的な Kubernetes タスクを実現する方法を説明します。開始するには、達成するタスクを選択してください。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:5 -msgid "Creating K8S object" -msgstr "K8S オブジェクトの作成" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:13 -msgid "This guide will show you how to utilize Ansible to create Kubernetes objects such as Pods, Deployments, and Secrets." -msgstr "以下では、Ansible を使用して Pod、Deployment、Secret などの Kubernetes オブジェクトを作成する方法を説明します。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:16 -msgid "Scenario Requirements" -msgstr "シナリオの要件" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:18 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:18 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:18 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:18 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:18 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:18 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:18 -msgid "Software" -msgstr "ソフトウェア" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:20 -msgid "Ansible 2.9.10 or later must be installed" -msgstr "Ansible 2.9.10 以降がインストールされています。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:22 -msgid "The Python modules ``openshift`` and ``kubernetes`` must be installed on the Ansible controller (or Target host if not executing against localhost)" -msgstr "Python モジュール ``openshift`` および ``kubernetes`` は、Ansible コントローラー (またはローカルホストに対して実行されていない場合のターゲットホスト) にインストールする必要があります。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:24 -msgid "Kubernetes Cluster" -msgstr "Kubernetes クラスター" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:26 -msgid "Kubectl binary installed on the Ansible controller" -msgstr "Ansible コントローラーにインストールされた Kubectl バイナリー" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:29 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:30 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:32 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:32 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:32 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:29 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:29 -msgid "Access / Credentials" -msgstr "アクセス/認証情報" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:31 -msgid "Kubeconfig configured with the given Kubernetes cluster" -msgstr "指定の Kubernetes クラスターで設定された kubeconfig" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:35 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:66 -msgid "Assumptions" -msgstr "前提条件" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:37 -msgid "User has required level of authorization to create, delete and update resources on the given Kubernetes cluster." -msgstr "ユーザーには、指定の Kubernetes クラスターでリソースを作成、削除、および更新するのに必要な承認レベルがあります。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:40 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:73 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:39 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:41 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:41 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:36 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:38 -msgid "Caveats" -msgstr "注意事項" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:42 -msgid "community.kubernetes 1.1.0 is going to migrate to `kubernetes.core `_" -msgstr "community.kubernetes 1.1.0 は `kubernetes.core `_ に移行する予定です。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:45 -msgid "Example Description" -msgstr "例の説明" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:47 -msgid "In this use case / example, we will create a Pod in the given Kubernetes Cluster. The following Ansible playbook showcases the basic parameters that are needed for this." -msgstr "このユースケース/サンプルでは、指定した Kubernetes Cluster に Pod を作成します。以下の Ansible Playbook では、これに必要な基本パラメーターについて取り上げます。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:51 -msgid "Since Ansible utilizes the Kubernetes API to perform actions, in this use case we will be connecting directly to the Kubernetes cluster." -msgstr "Ansible は Kubernetes API を使用してアクションを実行するため、このユースケースでは Kubernetes クラスターに直接接続します。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:53 -msgid "To begin, there are a few bits of information we will need. Here you are using Kubeconfig which is pre-configured in your machine. The Kubeconfig is generally located at ``~/.kube/config``. It is highly recommended to store sensitive information such as password, user certificates in a more secure fashion using :ref:`ansible-vault` or using `Ansible Tower credentials `_." -msgstr "まず、必要な情報をいくつか紹介します。マシン内で事前設定されている Kubeconfig を使用します。Kubeconfig は通常 ``~/.kube/config`` に置かれます。パスワードやユーザー証明書などの機密情報は、:ref:`ansible-vault` または`Ansible Tower 認証情報 `_ を使用して、より安全な方法で保存することが強く推奨されます。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:55 -msgid "Now you need to supply the information about the Pod which will be created. Using ``definition`` parameter of the ``community.kubernetes.k8s`` module, you specify `PodTemplate `_. This PodTemplate is identical to what you provide to the ``kubectl`` command." -msgstr "作成される Pod に関する情報を提供する必要があります。``definition`` モジュールの ``community.kubernetes.k8s`` パラメーターを使用して `PodTemplate `_ を指定します。この PodTemplate は、``kubectl`` コマンドに指定する内容と同じです。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:58 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:115 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:97 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:106 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:113 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:114 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:95 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:163 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:74 -msgid "What to expect" -msgstr "予想されること" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:60 -msgid "You will see a bit of JSON output after this playbook completes. This output shows various parameters that are returned from the module and from cluster about the newly created Pod." -msgstr "この Playbook が完了すると、JSON の出力が少し表示されます。この出力には、モジュールから返されたさまざまなパラメーターや、新たに作成された Pod に関するクラスターから返されたさまざまなパラメーターが表示されます。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:64 -msgid "In the above example, 'changed' is ``True`` which notifies that the Pod creation started on the given cluster. This can take some time depending on your environment." -msgstr "上記の例では、「changed」は ``True`` で、指定のクラスターで Pod の作成が開始されていることを通知します。これには、環境に応じて多少時間がかかる場合があります。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:68 -#: ../../rst/scenario_guides/scenario_template.rst:45 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:215 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:114 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:120 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:167 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:150 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:115 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:103 -msgid "Troubleshooting" -msgstr "トラブルシューティング" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:70 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:217 -msgid "Things to inspect" -msgstr "調べること" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:72 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:219 -msgid "Check if the values provided for username and password are correct" -msgstr "ユーザー名およびパスワードの値が正しいかどうかを確認します。" - -#: ../../rst/scenario_guides/kubernetes_scenarios/scenario_k8s_object.rst:73 -msgid "Check if the Kubeconfig is populated with correct values" -msgstr "Kubeconfig が正しい値で入力されているかどうかを確認します。" - -#: ../../rst/scenario_guides/network_guides.rst:7 -msgid "The guides in this section cover using Ansible with specific network technologies. They explore particular use cases in greater depth and provide a more \"top-down\" explanation of some basic features." -msgstr "本セクションのガイドでは、特定のネットワーク技術を使用した Ansible の使用について説明します。特定のユースケースをより深く掘り下げ、いくつかの基本的な機能を「トップダウン」で説明します。" - -#: ../../rst/scenario_guides/network_guides.rst:16 -msgid "To learn more about Network Automation with Ansible, see :ref:`network_getting_started` and :ref:`network_advanced`." -msgstr "Ansible を使用したネットワーク自動化の詳細は、「:ref:`network_getting_started`」および「:ref:`network_advanced`」を参照してください。" - -#: ../../rst/scenario_guides/scenario_template.rst:7 -msgid "Sample scenario for Ansible platforms" -msgstr "Ansible プラットフォームのサンプルシナリオ" - -#: ../../rst/scenario_guides/scenario_template.rst:9 -msgid "*Use this ``rst`` file as a starting point to create a scenario guide for your platform. The sections below are suggestions on what should be in a scenario guide.*" -msgstr "*この ``rst`` ファイルを、お使いのプラットフォームのシナリオガイドを作成するための出発点として使用します。以下のセクションは、シナリオガイドに含まれるべき内容を提案しています。*" - -#: ../../rst/scenario_guides/scenario_template.rst:11 -msgid "Introductory paragraph." -msgstr "概要" - -#: ../../rst/scenario_guides/scenario_template.rst:19 -msgid "Describe the requirements and assumptions for this scenario. This should include applicable subsections for hardware, software, and any other caveats to using the scenarios in this guide." -msgstr "このシナリオの要件および前提条件を説明します。これには、ハードウェア、ソフトウェア、およびその他のシナリオで使用するための適用可能なサブセクションを含める必要があります。" - -#: ../../rst/scenario_guides/scenario_template.rst:24 -msgid "Describe credential requirements and how to authenticate to this platform." -msgstr "認証情報の要件と、このプラットフォームへの認証方法を説明します。" - -#: ../../rst/scenario_guides/scenario_template.rst:27 -msgid "Using dynamic inventory" -msgstr "動的インベントリーの使用" - -#: ../../rst/scenario_guides/scenario_template.rst:29 -msgid "If applicable, describe how to use a dynamic inventory plugin for this platform." -msgstr "該当する場合は、このプラットフォームの動的インベントリープラグインの使用方法を説明します。" - -#: ../../rst/scenario_guides/scenario_template.rst:33 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:81 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:46 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:52 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:48 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:45 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:45 -msgid "Example description" -msgstr "例の説明" - -#: ../../rst/scenario_guides/scenario_template.rst:35 -msgid "Description and code here. Change the section header to something descriptive about this example, such as \"Renaming a virtual machine\". The goal is that this is the text someone would search for to find your example." -msgstr "ここには説明とコードが含まれます。セクションヘッダーを、「Renaming a virtual machine (仮想マシンの名前変更)」など、このサンプルを説明するものに変更します。これは、作成した例を他の誰かが検索する際に使用するテキストになります。" - -#: ../../rst/scenario_guides/scenario_template.rst:39 -msgid "Example output" -msgstr "出力例" - -#: ../../rst/scenario_guides/scenario_template.rst:41 -msgid "What the user should expect to see." -msgstr "期待される結果。" - -#: ../../rst/scenario_guides/scenario_template.rst:47 -msgid "What to look for if it breaks." -msgstr "壊れたときの注意点・" - -#: ../../rst/scenario_guides/scenario_template.rst:51 -msgid "Conclusion and where to go next" -msgstr "結論および次のステップ" - -#: ../../rst/scenario_guides/scenario_template.rst:53 -msgid "Recap of important points. For more information please see: links." -msgstr "重要なポイントの要約。詳細は、リンクを参照してください。" - -#: ../../rst/scenario_guides/virt_guides.rst:5 -msgid "Virtualization and Containerization Guides" -msgstr "仮想化およびコンテナー化ガイド" - -#: ../../rst/scenario_guides/virt_guides.rst:7 -msgid "The guides in this section cover integrating Ansible with popular tools for creating virtual machines and containers. They explore particular use cases in greater depth and provide a more \"top-down\" explanation of some basic features." -msgstr "このセクションのガイドでは、仮想マシンやコンテナーを作成する一般的なツールと Ansible の統合を説明しています。特定のユースケースをより深く掘り下げ、いくつかの基本的な機能を「トップダウン」で説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:5 -msgid "How to configure the vmware_rest collection" -msgstr "vmware_rest コレクションの設定方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:14 -msgid "The vcenter_rest modules need to be authenticated. There are two different" -msgstr "vcenter_rest モジュールを認証する必要があります。2 つの異なるモジュールがあります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:20 -msgid "This solution requires that you call the modules from the local machine." -msgstr "このソリューションでは、ローカルマシンからモジュールを呼び出す必要があります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:22 -msgid "You need to export some environment variables in your shell before you call the modules." -msgstr "モジュールを呼び出す前に、シェルで環境変数の一部をエクスポートする必要があります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:32 -msgid "Module parameters" -msgstr "モジュールパラメーター" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:34 -msgid "All the vcenter_rest modules accept the following arguments:" -msgstr "すべての vcenter_rest モジュールは、以下の引数を受け入れます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:36 -msgid "``vcenter_host``" -msgstr "``vcenter_host``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:37 -msgid "``vcenter_username``" -msgstr "``vcenter_username``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:38 -msgid "``vcenter_password``" -msgstr "``vcenter_password``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:42 -msgid "Ignore SSL certificate error" -msgstr "SSL 証明書エラーを無視します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:44 -msgid "It's common to run a test environment without a proper SSL certificate configuration." -msgstr "適切な SSL 証明書設定なしでテスト環境を実行することが一般的です。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:46 -msgid "To ignore the SSL error, you can use the ``vcenter_validate_certs: no`` argument or ``export VMWARE_VALIDATE_CERTS=no`` to set the environment variable." -msgstr "SSL エラーを無視するには、``vcenter_validate_certs: no`` 引数または ``export VMWARE_VALIDATE_CERTS=no`` を使用して環境変数を設定します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:5 -msgid "How to collect information about your environment" -msgstr "環境に関する情報を収集する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:14 -msgid "This section shows you how to utilize Ansible to collect information about your environment. This information is useful for the other tutorials." -msgstr "本セクションでは、Ansible を使用してお使いの環境に関する情報を収集する方法を説明します。この情報は、他のチュートリアルに役立ちます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:18 -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:17 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:17 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:17 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:17 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:17 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:16 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:16 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:16 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:16 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:16 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:16 -msgid "Scenario requirements" -msgstr "シナリオの要件" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:20 -msgid "In this scenario we've got a vCenter with an ESXi host." -msgstr "このシナリオでは、ESXi ホストを搭載する vCenter があります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:22 -msgid "Our environment is pre-initialized with the following elements:" -msgstr "お使いの環境は、以下の要素で事前に初期化されています。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:24 -msgid "A datacenter called ``my_dc``" -msgstr "``my_dc`` という名前のデータセンター" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:25 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:26 -msgid "A cluster called ``my_cluser``" -msgstr "``my_cluser`` という名前のクラスター" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:27 -msgid "An ESXi host called ``esxi1`` is in the cluster" -msgstr "``esxi1`` という名前の ESXi ホストがクラスター内にあります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:28 -msgid "Two datastores on the ESXi: ``rw_datastore`` and ``ro_datastore``" -msgstr "ESXi 上の 2 つのデータストア: ``rw_datastore`` および ``ro_datastore``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:29 -msgid "A dvswitch based guest network" -msgstr "dvswitch ベースのゲストネットワーク" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:31 -msgid "Finally, we use the environment variables to authenticate ourselves as explained in :ref:`vmware_rest_authentication`." -msgstr "最後に、「:ref:`vmware_rest_authentication`」で説明されているように、環境変数を使用して認証を行います。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:34 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:22 -msgid "How to collect information" -msgstr "情報の収集方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:36 -msgid "In these examples, we use the ``vcenter_*_info`` module to collect information about the associated resources." -msgstr "この例では、``vcenter_*_info`` モジュールを使用して、関連付けられたリソースに関する情報を収集します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:38 -msgid "All these modules return a ``value`` key. Depending on the context, this ``value`` key will be either a list or a dictionary." -msgstr "これらのモジュールはすべて ``value`` キーを返します。コンテキストに応じて、この ``value`` キーはリストまたはディクショナリーのいずれかになります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:41 -msgid "Datacenter" -msgstr "データセンター" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:43 -msgid "Here we use the ``vcenter_datacenter_info`` module to list all the datacenters:" -msgstr "ここでは、``vcenter_datacenter_info`` モジュールを使用して、すべてのデータセンターを一覧表示します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:48 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:62 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:71 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:86 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:98 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:107 -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:34 -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:24 -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:37 -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:50 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:34 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:46 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:66 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:76 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:88 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:100 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:112 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:124 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:136 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:148 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:34 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:48 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:65 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:79 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:91 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:103 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:115 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:127 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:32 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:43 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:37 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:49 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:61 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:75 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:87 -msgid "Result" -msgstr "結果" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:50 -msgid "As expected, the ``value`` key of the output is a list." -msgstr "想定どおりに、出力の ``value`` キーはリストになります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:55 -msgid "Cluster" -msgstr "クラスター" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:57 -msgid "Here we do the same with ``vcenter_cluster_info``:" -msgstr "ここでは、``vcenter_cluster_info`` でも同じことを行います。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:66 -msgid "And we can also fetch the details about a specific cluster, with the ``cluster`` parameter:" -msgstr "また、``cluster`` パラメーターを使用して、特定のクラスターの詳細を取得することもできます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:73 -msgid "And the ``value`` key of the output is this time a dictionary." -msgstr "また、出力の ``value`` キーは、今回ディクショナリーです。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:79 -msgid "Datastore" -msgstr "データストア" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:81 -msgid "Here we use ``vcenter_datastore_info`` to get a list of all the datastores:" -msgstr "ここでは、``vcenter_datastore_info`` を使用してすべてのデータストアの一覧を取得します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:91 -msgid "Folder" -msgstr "フォルダー" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:93 -msgid "And here again, you use the ``vcenter_folder_info`` module to retrieve a list of all the folders." -msgstr "また、ここでは ``vcenter_folder_info`` モジュールを使用してすべてのフォルダーの一覧を取得します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:102 -msgid "Most of the time, you will just want one type of folder. In this case we can use filters to reduce the amount to collect. Most of the ``_info`` modules come with similar filters." -msgstr "多くの場合は、1 種類のディレクトリーが必要です。この場合は、フィルターを使用して収集する量を減らすことができます。ほとんどの ``_info`` モジュールには同様のフィルターが含まれます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:5 -msgid "How to create a Virtual Machine" -msgstr "仮想マシンの作成方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:14 -msgid "This section shows you how to use Ansible to create a virtual machine." -msgstr "本セクションでは、Ansible を使用して仮想マシンを作成する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:19 -msgid "You've already followed :ref:`vmware_rest_collect_info` and you've got the following variables defined:" -msgstr "すでに :ref:`vmware_rest_collect_info` に従い、以下の変数が定義済みである。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:21 -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:24 -msgid "``my_cluster_info``" -msgstr "``my_cluster_info``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:22 -msgid "``my_datastore``" -msgstr "``my_datastore``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:23 -msgid "``my_virtual_machine_folder``" -msgstr "``my_virtual_machine_folder``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:27 -msgid "How to create a virtual machine" -msgstr "仮想マシンの作成方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:29 -msgid "In this example, we will use the ``vcenter_vm`` module to create a new guest." -msgstr "この例では、``vcenter_vm`` モジュールを使用して新規ゲストを作成します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:39 -msgid "``vcenter_vm`` accepts more parameters, however you may prefer to start with a simple VM and use the ``vcenter_vm_hardware`` modules to tune it up afterwards. It's easier this way to identify a potential problematical step." -msgstr "``vcenter_vm`` は、より多くのパラメーターを受け入れることができますが、単純な仮想マシンで開始し、後で ``vcenter_vm_hardware`` モジュールを使用して調整したい場合があります。これにより、問題のあるステップを特定するのが容易になります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:5 -msgid "How to install the vmware_rest collection" -msgstr "vmware_rest コレクションをインストールする方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:14 -msgid "The collection depends on:" -msgstr "コレクションは、以下の条件で使用します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:16 -msgid "Ansible >=2.9.10 or greater" -msgstr "2.9.10 以降の Ansible" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:17 -msgid "Python 3.6 or greater" -msgstr "Python 3.6 以降" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:20 -msgid "aiohttp" -msgstr "aiohttp" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:22 -msgid "aiohttp_ is the only dependency of the collection. You can install it with ``pip`` if you use a virtualenv to run Ansible." -msgstr "aiohttp_ はコレクションの唯一の依存関係です。virtualenv を使用して Ansible を実行する場合は ``pip`` でインストールできます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:28 -msgid "Or using an RPM." -msgstr "または RPM を使用します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:39 -msgid "The best option to install the collection is to use the ``ansible-galaxy`` command:" -msgstr "コレクションをインストールする場合は、``ansible-galaxy`` コマンドを使用するのが最適です。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:5 -msgid "How to run a virtual machine" -msgstr "仮想マシンの実行方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:14 -msgid "This section covers the power management of your virtual machine." -msgstr "本セクションでは、仮想マシンの電源管理を説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:17 -msgid "Power information" -msgstr "電源情報" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:19 -msgid "Use ``vcenter_vm_power_info`` to know the power state of the VM." -msgstr "``vcenter_vm_power_info`` を使用して、仮想マシンの電源状態を確認します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:30 -msgid "How to start a virtual machine" -msgstr "仮想マシンの起動方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:32 -msgid "Use the ``vcenter_vm_power`` module to start your VM:" -msgstr "``vcenter_vm_power`` モジュールを使用して仮想マシンを起動します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:42 -msgid "How to wait until my virtual machine is ready" -msgstr "仮想マシンの準備ができるまで待機する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:44 -msgid "If your virtual machine runs VMware Tools, you can build a loop around the ``center_vm_tools_info`` module:" -msgstr "仮想マシンが VMware Tool を実行している場合は、``center_vm_tools_info`` モジュールを中心にループを構築できます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:5 -msgid "How to modify a virtual machine" -msgstr "仮想マシンの変更方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:14 -msgid "This section shows you how to use Ansible to modify an existing virtual machine." -msgstr "本セクションでは、Ansible を使用して既存の仮想マシンを変更する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:19 -msgid "You've already followed :ref:`vmware_rest_create_vm` and created a VM." -msgstr "すでに :ref:`vmware_rest_create_vm` に従い、仮想マシンを作成している。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:22 -msgid "How to add a CDROM drive to a virtual machine" -msgstr "CDROM ドライブを仮想マシンに追加する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:24 -msgid "In this example, we use the ``vcenter_vm_hardware_*`` modules to add a new CDROM to an existing VM." -msgstr "この例では、``vcenter_vm_hardware_*`` モジュールを使用して、新しい CDROM を既存の仮想マシンに追加します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:27 -msgid "Add a new SATA adapter" -msgstr "新しい SATA アダプターの追加" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:29 -msgid "First we create a new SATA adapter. We specify the ``pci_slot_number``. This way if we run the task again it won't do anything if there is already an adapter there." -msgstr "最初に新しい SATA アダプターを作成します。``pci_slot_number`` を指定します。これにより、タスクを再度実行する場合は、アダプターがすでに存在していても何も実行されません。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:39 -msgid "Add a CDROM drive" -msgstr "CDROM ドライブの追加" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:41 -msgid "Now we can create the CDROM drive:" -msgstr "これで CDROM ドライブを作成できます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:54 -msgid "How to attach a VM to a network" -msgstr "仮想マシンをネットワークに割り当てる方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:57 -msgid "Attach a new NIC" -msgstr "新規 NIC の割り当て" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:59 -msgid "Here we attach the VM to the network (through the portgroup). We specify a ``pci_slot_number`` for the same reason." -msgstr "ここでは、(portgroup から) 仮想マシンをネットワークに接続します。同様に ``pci_slot_number`` を指定します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:61 -msgid "The second task adjusts the NIC configuration." -msgstr "2 つ目のタスクは、NIC 設定を調整します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:71 -msgid "Adjust the configuration of the NIC" -msgstr "NIC の設定の調整" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:81 -msgid "Increase the memory of the VM" -msgstr "仮想マシンのメモリーの増加" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:83 -msgid "We can also adjust the amount of memory that we dedicate to our VM." -msgstr "また、仮想マシンに割り当てるメモリー容量を調整することもできます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:93 -msgid "Upgrade the hardware version of the VM" -msgstr "仮想マシンのハードウェアバージョンをアップグレードします。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:95 -msgid "Here we use the ``vcenter_vm_hardware`` module to upgrade the version of the hardware:" -msgstr "ここでは、``vcenter_vm_hardware`` モジュールを使用してハードウェアのバージョンをアップグレードします。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:105 -msgid "Adjust the number of CPUs of the VM" -msgstr "仮想マシンの CPU 数を調整する" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:107 -msgid "You can use ``vcenter_vm_hardware_cpu`` for that:" -msgstr "そのためには、``vcenter_vm_hardware_cpu`` を使用できます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:117 -msgid "Remove a SATA controller" -msgstr "SATA コントローラーの削除" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:119 -msgid "In this example, we remove the SATA controller of the PCI slot 34." -msgstr "この例では、PCI スロット 34 の SATA コントローラーを削除します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:129 -msgid "Attach a floppy drive" -msgstr "フロッピードライブの接続" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:131 -msgid "Here we attach a floppy drive to a VM." -msgstr "ここでは、フロッピードライブを仮想マシンに割り当てます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:141 -msgid "Attach a new disk" -msgstr "新規ディスクの割り当て" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:143 -msgid "Here we attach a tiny disk to the VM. The ``capacity`` is in bytes." -msgstr "ここでは、仮想マシンに小規模なディスクを割り当てます。``capacity`` はバイト単位です。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:5 -msgid "Retrieve information from a specific VM" -msgstr "特定の仮想マシンからの情報の取得" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:14 -msgid "This section shows you how to use Ansible to retrieve information about a specific virtual machine." -msgstr "本セクションでは、Ansible を使用して特定の仮想マシンに関する情報を取得する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:19 -msgid "You've already followed :ref:`vmware_rest_create_vm` and you've got create a new VM called ``test_vm1``." -msgstr "すでに :ref:`vmware_rest_create_vm` に従い、``test_vm1`` という名前の新しい仮想マシンを作成している。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:22 -msgid "How to collect virtual machine information" -msgstr "仮想マシン情報を収集する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:25 -msgid "List the VM" -msgstr "仮想マシンの一覧表示" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:27 -msgid "In this example, we use the ``vcenter_vm_info`` module to collect information about our new VM." -msgstr "この例では、``vcenter_vm_info`` モジュールを使用して、新しい仮想マシンに関する情報を収集します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:29 -msgid "In this example, we start by asking for a list of VMs. We use a filter to limit the results to just the VM called ``test_vm1``. So we are in a list context, with one single entry in the ``value`` key." -msgstr "この例では、仮想マシンの一覧を求めることから開始します。結果は、``test_vm1`` と呼ばれる仮想マシンに制限します。そのため、``value`` キーには 1 つのエントリーがあります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:36 -msgid "As expected, we get a list. And thanks to our filter, we just get one entry." -msgstr "予想通り、リストが表示されます。そして、フィルターのおかげで、エントリーを 1 だけつ得ることができました。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:41 -msgid "Collect the details about a specific VM" -msgstr "特定の仮想マシンに関する詳細の収集" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:43 -msgid "For the next steps, we pass the ID of the VM through the ``vm`` parameter. This allow us to collect more details about this specific VM." -msgstr "次のステップでは、``vm`` パラメーターを使用して仮想マシンの ID を渡します。これにより、この特定の仮想マシンに関する詳細を収集できます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:50 -msgid "The result is a structure with all the details about our VM. You will note this is actually the same information that we get when we created the VM." -msgstr "結果は、仮想マシンに関する詳細がすべて記載されている構造です。これは、仮想マシンの作成時に得られる情報と同じです。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:56 -msgid "Get the hardware version of a specific VM" -msgstr "特定の仮想マシンのハードウェアバージョンの取得" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:58 -msgid "We can also use all the ``vcenter_vm_*_info`` modules to retrieve a smaller amount of information. Here we use ``vcenter_vm_hardware_info`` to know the hardware version of the VM." -msgstr "すべての ``vcenter_vm_*_info`` モジュールを使用して、より詳細な情報を取得することもできます。ここでは、``vcenter_vm_hardware_info`` を使用して仮想マシンのハードウェアバージョンを把握します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:70 -msgid "List the SCSI adapter(s) of a specific VM" -msgstr "特定の仮想マシンの SCSI アダプターを一覧表示する" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:72 -msgid "Here for instance, we list the SCSI adapter(s) of the VM:" -msgstr "たとえば、仮想マシンの SCSI アダプターを一覧表示します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:76 -msgid "You can do the same for the SATA controllers with ``vcenter_vm_adapter_sata_info``." -msgstr "``vcenter_vm_adapter_sata_info`` を使用して SATA コントローラーで同じ操作を行うことができます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:84 -msgid "List the CDROM drive(s) of a specific VM" -msgstr "特定の仮想マシンの CDROM ドライブを一覧表示します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:86 -msgid "And we list its CDROM drives." -msgstr "その CDROM ドライブを一覧表示します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:96 -msgid "Get the memory information of the VM" -msgstr "仮想マシンのメモリー情報を取得します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:98 -msgid "Here we collect the memory information of the VM:" -msgstr "ここでは、仮想マシンのメモリー情報を収集します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:108 -msgid "Get the storage policy of the VM" -msgstr "仮想マシンのストレージポリシーを取得します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:110 -msgid "We use the ``vcenter_vm_storage_policy_info`` module for that:" -msgstr "そのために ``vcenter_vm_storage_policy_info`` モジュールを使用しています。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:120 -msgid "Get the disk information of the VM" -msgstr "仮想マシンのディスク情報の取得" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:122 -msgid "We use the ``vcenter_vm_hardware_disk_info`` for this operation:" -msgstr "この操作には ``vcenter_vm_hardware_disk_info`` を使用します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:5 -msgid "How to configure the VMware tools of a running virtual machine" -msgstr "実行中の仮想マシンの VMware ツールを設定する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:14 -msgid "This section show you how to collection information from a running virtual machine." -msgstr "本セクションでは、実行中の仮想マシンから情報を取得する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:19 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:19 -msgid "You've already followed :ref:`vmware_rest_run_a_vm` and your virtual machine runs VMware Tools." -msgstr "すでに :ref:`vmware_rest_run_a_vm` に従い、仮想マシンが VMware ツールを実行している。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:22 -msgid "How to change the upgrade policy" -msgstr "アップグレードポリシーを変更する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:25 -msgid "Change the upgrade policy to MANUAL" -msgstr "アップグレードポリシーを MANUAL に変更" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:27 -msgid "You can adjust the VMware Tools upgrade policy with the ``vcenter_vm_tools`` module." -msgstr "``vcenter_vm_tools`` モジュールで VMware Tools アップグレードポリシーを調整することができます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:38 -msgid "Change the upgrade policy to UPGRADE_AT_POWER_CYCLE" -msgstr "アップグレードポリシーを UPGRADE_AT_POWER_CYCLE に変更" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:5 -msgid "How to get information from a running virtual machine" -msgstr "実行中の仮想マシンから情報を取得する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:14 -msgid "This section shows you how to collection information from a running virtual machine." -msgstr "このセクションでは、実行中の仮想マシンから情報を取得する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:24 -msgid "In this example, we use the ``vcenter_vm_guest_*`` module to collect information about the associated resources." -msgstr "この例では、``vcenter_vm_guest_*`` モジュールを使用して、関連付けられたリソースに関する情報を収集します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:27 -msgid "Filesystem" -msgstr "ファイルシステム" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:29 -msgid "Here we use ``vcenter_vm_guest_localfilesystem_info`` to retrieve the details about the filesystem of the guest. In this example we also use a ``retries`` loop. The VMware Tools may take a bit of time to start and by doing so, we give the VM a bit more time." -msgstr "この例では、``vcenter_vm_guest_localfilesystem_info`` を使用してゲストのファイルシステムの詳細を取得します。この例では、``retries`` ループも使用します。VMware Tool の開始には少し時間がかかる場合がありますが、このようにすることで仮想マシンに少し時間に余裕ができます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:42 -msgid "Guest identity" -msgstr "ゲスト ID" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:44 -msgid "You can use ``vcenter_vm_guest_identity_info`` to get details like the OS family or the hostname of the running VM." -msgstr "``vcenter_vm_guest_identity_info`` を使用すると、OS ファミリーや実行中の仮想マシンのホスト名などの詳細を取得できます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:54 -msgid "Network" -msgstr "ネットワーク" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:56 -msgid "``vcenter_vm_guest_networking_info`` will return the OS network configuration." -msgstr "``vcenter_vm_guest_networking_info`` は、OS のネットワーク設定を返します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:66 -msgid "Network interfaces" -msgstr "ネットワークインターフェース" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:68 -msgid "``vcenter_vm_guest_networking_interfaces_info`` will return a list of NIC configurations." -msgstr "``vcenter_vm_guest_networking_interfaces_info`` は、NC 設定の一覧を返します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:70 -msgid "See also :ref:`vmware_rest_attach_a_network`." -msgstr "「:ref:`vmware_rest_attach_a_network`」も参照してください。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:80 -msgid "Network routes" -msgstr "ネットワークルート" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:82 -msgid "Use ``vcenter_vm_guest_networking_routes_info`` to explore the route table of your virtual machine." -msgstr "仮想マシンのルートテーブルを確認するには、``vcenter_vm_guest_networking_routes_info`` を使用します。" - -#: ../../rst/scenario_guides/vmware_scenarios/faq.rst:5 -msgid "Ansible VMware FAQ" -msgstr "Ansible VMware FAQ" - -#: ../../rst/scenario_guides/vmware_scenarios/faq.rst:8 -msgid "vmware_guest" -msgstr "vmware_guest" - -#: ../../rst/scenario_guides/vmware_scenarios/faq.rst:11 -msgid "Can I deploy a virtual machine on a standalone ESXi server ?" -msgstr "スタンドアロンの ESXi サーバーに仮想マシンをデプロイすることはできますか。" - -#: ../../rst/scenario_guides/vmware_scenarios/faq.rst:13 -msgid "Yes. ``vmware_guest`` can deploy a virtual machine with required settings on a standalone ESXi server. However, you must have a paid license to deploy virtual machines this way. If you are using the free version, the API is read-only." -msgstr "はい。``vmware_guest`` はスタンドアロン ESXi サーバーに必要な設定で仮想マシンをデプロイできます。ただし、この方法で仮想マシンをデプロイするには有料のライセンスが必要になります。フリーバージョンを使用している場合、API は読み取り専用です。" - -#: ../../rst/scenario_guides/vmware_scenarios/faq.rst:17 -msgid "Is ``/vm`` required for ``vmware_guest`` module ?" -msgstr "``vmware_guest`` モジュールには ``/vm`` が必要ですか。" - -#: ../../rst/scenario_guides/vmware_scenarios/faq.rst:19 -msgid "Prior to Ansible version 2.5, ``folder`` was an optional parameter with a default value of ``/vm``." -msgstr "Ansible バージョン 2.5 より前のバージョンでは、``folder`` は、任意のパラメーターで、デフォルト値は ``/vm`` でした。" - -#: ../../rst/scenario_guides/vmware_scenarios/faq.rst:21 -msgid "The folder parameter was used to discover information about virtual machines in the given infrastructure." -msgstr "folder パラメーターは、指定したインフラストラクチャーの仮想マシンに関する情報を検出するために使用されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/faq.rst:23 -msgid "Starting with Ansible version 2.5, ``folder`` is still an optional parameter with no default value. This parameter will be now used to identify a user's virtual machine, if multiple virtual machines or virtual machine templates are found with same name. VMware does not restrict the system administrator from creating virtual machines with same name." -msgstr "Ansible バージョン 2.5 以降、``folder`` は、デフォルト値のない任意のパラメーターです。このパラメーターは、複数の仮想マシンまたは仮想マシンテンプレートが同じ名前で見つかった場合に、ユーザーの仮想マシンを識別するために使用されます。VMware は、システム管理者が同じ名前を持つ仮想マシンを作成することを制限していません。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:5 -msgid "Deploy a virtual machine from a template" -msgstr "テンプレートからの仮想マシンのデプロイメント" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:13 -msgid "This guide will show you how to utilize Ansible to clone a virtual machine from already existing VMware template or existing VMware guest." -msgstr "本ガイドでは、Ansible を使用して、既存の VMware テンプレートまたは既存の VMware ゲストから仮想マシンのクローンを作成する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:20 -msgid "Ansible 2.5 or later must be installed" -msgstr "Ansible 2.5 以降がインストールされています。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:22 -msgid "The Python module ``Pyvmomi`` must be installed on the Ansible (or Target host if not executing against localhost)" -msgstr "Python モジュール ``Pyvmomi`` を Ansible (ローカルホストに対して実行しない場合にはターゲットホスト) にインストールしている。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:24 -msgid "Installing the latest ``Pyvmomi`` via ``pip`` is recommended [as the OS provided packages are usually out of date and incompatible]" -msgstr "``pip`` を介して最新の ``Pyvmomi`` をインストールすることが推奨されます (OS 提供パッケージは通常古くなり、互換性がないため)。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:26 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:26 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:26 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:26 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:25 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:25 -msgid "Hardware" -msgstr "ハードウェア" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:28 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:30 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:30 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:30 -msgid "vCenter Server with at least one ESXi server" -msgstr "ESXi サーバーが 1 台以上搭載されている vCenter Server" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:32 -msgid "Ansible (or the target server) must have network access to the either vCenter server or the ESXi server you will be deploying to" -msgstr "Ansible (またはターゲットサーバー) には、デプロイする vCenter サーバーまたは ESXi サーバーへのネットワークアクセスが必要です。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:34 -msgid "Username and Password" -msgstr "ユーザー名とパスワード" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:36 -msgid "Administrator user with following privileges" -msgstr "以下の権限を持つ管理ユーザー" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:38 -msgid "``Datastore.AllocateSpace`` on the destination datastore or datastore folder" -msgstr "宛先データストアまたはデータストアディレクトリーの ``Datastore.AllocateSpace``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:39 -msgid "``Network.Assign`` on the network to which the virtual machine will be assigned" -msgstr "仮想マシンが割り当てられるネットワークの ``Network.Assign``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:40 -msgid "``Resource.AssignVMToPool`` on the destination host, cluster, or resource pool" -msgstr "移行先ホスト、クラスター、またはリソースプールの ``Resource.AssignVMToPool``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:41 -msgid "``VirtualMachine.Config.AddNewDisk`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.AddNewDisk``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:42 -msgid "``VirtualMachine.Config.AddRemoveDevice`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.AddRemoveDevice``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:43 -msgid "``VirtualMachine.Interact.PowerOn`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Interact.PowerOn``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:44 -msgid "``VirtualMachine.Inventory.CreateFromExisting`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Inventory.CreateFromExisting``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:45 -msgid "``VirtualMachine.Provisioning.Clone`` on the virtual machine you are cloning" -msgstr "クローンを作成している仮想マシンの ``VirtualMachine.Provisioning.Clone``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:46 -msgid "``VirtualMachine.Provisioning.Customize`` on the virtual machine or virtual machine folder if you are customizing the guest operating system" -msgstr "ゲストオペレーティングシステムをカスタマイズしている場合は、仮想マシンまたは仮想マシンディレクトリーの ``VirtualMachine.Provisioning.Customize``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:47 -msgid "``VirtualMachine.Provisioning.DeployTemplate`` on the template you are using" -msgstr "使用しているテンプレートの ``VirtualMachine.Provisioning.DeployTemplate``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:48 -msgid "``VirtualMachine.Provisioning.ReadCustSpecs`` on the root vCenter Server if you are customizing the guest operating system" -msgstr "ゲストオペレーティングシステムをカスタマイズする場合は、ルート vCenter サーバーの ``VirtualMachine.Provisioning.ReadCustSpecs``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:50 -msgid "Depending on your requirements, you could also need one or more of the following privileges:" -msgstr "要件によっては、以下の権限が 1 つ以上必要になる場合があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:52 -msgid "``VirtualMachine.Config.CPUCount`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.CPUCount``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:53 -msgid "``VirtualMachine.Config.Memory`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.Memory``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:54 -msgid "``VirtualMachine.Config.DiskExtend`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.DiskExtend``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:55 -msgid "``VirtualMachine.Config.Annotation`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.Annotation``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:56 -msgid "``VirtualMachine.Config.AdvancedConfig`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.AdvancedConfig``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:57 -msgid "``VirtualMachine.Config.EditDevice`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.EditDevice``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:58 -msgid "``VirtualMachine.Config.Resource`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.Resource``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:59 -msgid "``VirtualMachine.Config.Settings`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.Settings``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:60 -msgid "``VirtualMachine.Config.UpgradeVirtualHardware`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.UpgradeVirtualHardware``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:61 -msgid "``VirtualMachine.Interact.SetCDMedia`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Interact.SetCDMedia``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:62 -msgid "``VirtualMachine.Interact.SetFloppyMedia`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Interact.SetFloppyMedia``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:63 -msgid "``VirtualMachine.Interact.DeviceConnection`` on the datacenter or virtual machine folder" -msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Interact.DeviceConnection``" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:68 -msgid "All variable names and VMware object names are case sensitive" -msgstr "変数名および VMware オブジェクト名はすべて大文字と小文字を区別します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:69 -msgid "VMware allows creation of virtual machine and templates with same name across datacenters and within datacenters" -msgstr "VMware では、データセンター間およびデータセンター内で、同じ名前の仮想マシンおよびテンプレートを作成できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:70 -msgid "You need to use Python 2.7.9 version in order to use ``validate_certs`` option, as this version is capable of changing the SSL verification behaviours" -msgstr "``validate_certs`` オプションを使用するには、Python 2.7.9 バージョンを使用する必要があります。このバージョンは、SSL 検証の動作を変更できるためです。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:75 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:38 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:38 -msgid "Hosts in the ESXi cluster must have access to the datastore that the template resides on." -msgstr "ESXi クラスター内のホストが、テンプレートが存在するデータストアにアクセスできる必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:76 -msgid "Multiple templates with the same name will cause module failures." -msgstr "同じ名前のテンプレートが複数存在する場合、モジュールは失敗します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:77 -msgid "In order to utilize Guest Customization, VMware Tools must be installed on the template. For Linux, the ``open-vm-tools`` package is recommended, and it requires that ``Perl`` be installed." -msgstr "ゲストのカスタマイズを使用するには、VMware Tool をテンプレートにインストールする必要があります。Linux の場合は ``open-vm-tools`` パッケージが推奨され、``Perl`` がインストールされている必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:83 -msgid "In this use case / example, we will be selecting a virtual machine template and cloning it into a specific folder in our Datacenter / Cluster. The following Ansible playbook showcases the basic parameters that are needed for this." -msgstr "このユースケースまたはサンプルでは、仮想マシンテンプレートを選択し、データセンター/クラスターの特定のディレクトリーにクローンを作成します。以下の Ansible Playbook では、これに必要な基本的なパラメーターについて取り上げます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:107 -msgid "Since Ansible utilizes the VMware API to perform actions, in this use case we will be connecting directly to the API from our localhost. This means that our playbooks will not be running from the vCenter or ESXi Server. We do not necessarily need to collect facts about our localhost, so the ``gather_facts`` parameter will be disabled. You can run these modules against another server that would then connect to the API if your localhost does not have access to vCenter. If so, the required Python modules will need to be installed on that target server." -msgstr "Ansible は VMware API を使用してアクションを実行するため、このユースケースではローカルホストから直接 API に接続します。つまり、Playbook は vCenter または ESXi サーバーから実行しないことを意味します。必ずしもローカルホストに関するファクトを収集する必要がないため、``gather_facts`` パラメーターは無効になります。ローカルホストが vCenter にアクセスできない場合は、API に接続する別のサーバーに対してこれらのモジュールを実行することができます。その場合は、必要な Python モジュールを、そのターゲットサーバーにインストールする必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:109 -msgid "To begin, there are a few bits of information we will need. First and foremost is the hostname of the ESXi server or vCenter server. After this, you will need the username and password for this server. For now, you will be entering these directly, but in a more advanced playbook this can be abstracted out and stored in a more secure fashion using :ref:`ansible-vault` or using `Ansible Tower credentials `_. If your vCenter or ESXi server is not setup with proper CA certificates that can be verified from the Ansible server, then it is necessary to disable validation of these certificates by using the ``validate_certs`` parameter. To do this you need to set ``validate_certs=False`` in your playbook." -msgstr "まず、いくつかの情報が必要になります。まず第一に、ESXi サーバーのホスト名または vCenter サーバーのホスト名です。その後、このサーバーのユーザー名とパスワードが必要になります。ここでは、これらを直接入力しますが、より高度な Playbook ではこの情報を抽象化し、:ref:`ansible-vault` または `Ansible Tower 認証情報 `_ を使用して、よりセキュアな方法で保存することができます。vCenter サーバーまたは ESXi サーバーに、Ansible サーバーから検証可能な適切な CA 証明書が設定されていない場合は、``validate_certs`` パラメーターを使用してこれらの証明書の検証を無効にする必要があります。そのためには、Playbook で ``validate_certs=False`` を設定する必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:111 -msgid "Now you need to supply the information about the virtual machine which will be created. Give your virtual machine a name, one that conforms to all VMware requirements for naming conventions. Next, select the display name of the template from which you want to clone new virtual machine. This must match what's displayed in VMware Web UI exactly. Then you can specify a folder to place this new virtual machine in. This path can either be a relative path or a full path to the folder including the Datacenter. You may need to specify a state for the virtual machine. This simply tells the module which action you want to take, in this case you will be ensure that the virtual machine exists and is powered on. An optional parameter is ``wait_for_ip_address``, this will tell Ansible to wait for the virtual machine to fully boot up and VMware Tools is running before completing this task." -msgstr "ここで、作成される仮想マシンに関する情報を入力する必要があります。仮想マシンの名前は、VMware が要求する命名規則に準拠したものにしてください。次に、新しい仮想マシンのクローンを作成するテンプレートの表示名を選択します。これは、VMware Web UI に表示される内容に一致する必要があります。次に、この新しい仮想マシンを配置するディレクトリーを指定します。このパスは、相対パスでも、データセンターを含むディレクトリーへの完全パスでも構いません。仮想マシンの状態を指定しないといけない場合があります。これは単に、実行するアクションをモジュールに指示するだけです。この場合は、仮想マシンが存在することと、電源がオンになっていることを確認します。任意のパラメーターは ``wait_for_ip_address`` です。これにより、このタスクを完了する前に、仮想マシンが完全に起動し、VMware Tools が実行するのを待つよう Ansible に指示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:117 -msgid "You will see a bit of JSON output after this playbook completes. This output shows various parameters that are returned from the module and from vCenter about the newly created VM." -msgstr "この Playbook が完了すると、JSON の出力が少し表示されます。この出力には、モジュールから返されたさまざまなパラメーターや、新たに作成された仮想マシンに関する vCenter から返されたさまざまなパラメーターが表示されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:208 -msgid "State is changed to ``True`` which notifies that the virtual machine is built using given template. The module will not complete until the clone task in VMware is finished. This can take some time depending on your environment." -msgstr "状態が ``True`` に変更され、仮想マシンが指定のテンプレートを使用して構築されることを通知します。モジュールは、VMware のクローンタスクが終了するまで完了しません。これは環境に応じて多少時間がかかる場合があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:210 -msgid "If you utilize the ``wait_for_ip_address`` parameter, then it will also increase the clone time as it will wait until virtual machine boots into the OS and an IP Address has been assigned to the given NIC." -msgstr "``wait_for_ip_address`` パラメーターを使用すると、仮想マシンが OS で起動し、指定の NIC に IP アドレスが割り当てられるまで待機するため、クローンを作成する時間も長くなります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:220 -msgid "Check if the datacenter you provided is available" -msgstr "指定したデータセンターが利用可能かどうかを確認します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:221 -msgid "Check if the template specified exists and you have permissions to access the datastore" -msgstr "指定したテンプレートが存在しているかどうか、およびデータストアにアクセスするパーミッションがあるかどうかを確認します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_clone_template.rst:222 -msgid "Ensure the full folder path you specified already exists. It will not create folders automatically for you" -msgstr "指定した完全なディレクトリーパスが存在することを確認してください。ディレクトリーは自動的に作成されません" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:5 -msgid "Find folder path of an existing VMware virtual machine" -msgstr "既存の VMware 仮想マシンのディレクトリーパスの検索" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:13 -msgid "This guide will show you how to utilize Ansible to find folder path of an existing VMware virtual machine." -msgstr "本ガイドでは、Ansible を使用して既存の VMware 仮想マシンのディレクトリーパスを検索する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:20 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:20 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:20 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:20 -msgid "Ansible 2.5 or later must be installed." -msgstr "Ansible 2.5 以降がインストールされている必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:22 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:22 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:22 -msgid "The Python module ``Pyvmomi`` must be installed on the Ansible control node (or Target host if not executing against localhost)." -msgstr "Ansible コントロールノード (またはローカルホストで実行していない場合はターゲットホスト) に、Python モジュール ``Pyvmomi`` をインストールしている必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:24 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:24 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:24 -msgid "We recommend installing the latest version with pip: ``pip install Pyvmomi`` (as the OS packages are usually out of date and incompatible)." -msgstr "pip で最新版をインストール (``pip install Pyvmomi``) することが推奨されます (OSのパッケージはたいてい古くて互換性がないため)。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:28 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:28 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:28 -msgid "At least one standalone ESXi server or" -msgstr "少なくともスタンドアロンの ESXi サーバー 1 台、または" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:34 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:34 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:34 -msgid "Ansible (or the target server) must have network access to the either vCenter server or the ESXi server" -msgstr "Ansible (またはターゲットサーバー) には、vCenter サーバーまたは ESXi サーバーへのネットワークアクセスが必要です。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:36 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:36 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:36 -msgid "Username and Password for vCenter or ESXi server" -msgstr "vCenter サーバーまたは ESXi サーバーのユーザー名およびパスワード" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:41 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:43 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:43 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:38 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:40 -msgid "All variable names and VMware object names are case sensitive." -msgstr "変数名および VMware オブジェクト名はすべて大文字と小文字を区別します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:42 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:44 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:44 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:39 -msgid "You need to use Python 2.7.9 version in order to use ``validate_certs`` option, as this version is capable of changing the SSL verification behaviours." -msgstr "``validate_certs`` オプションを使用するには、Python 2.7.9 バージョンを使用する必要があります。このバージョンは、SSL 検証の動作を変更できるためです。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:48 -msgid "With the following Ansible playbook you can find the folder path of an existing virtual machine using name." -msgstr "次の Ansible Playbook では、名前を使用して既存の仮想マシンのディレクトリーパスを検索できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:75 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:84 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:90 -msgid "Since Ansible utilizes the VMware API to perform actions, in this use case it will be connecting directly to the API from localhost." -msgstr "Ansible は VMware API を使用してアクションを実行するため、このユースケースではローカルホストから API に直接接続されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:77 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:86 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:92 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:95 -msgid "This means that playbooks will not be running from the vCenter or ESXi Server." -msgstr "つまり、Playbook は vCenter サーバーまたは ESXi サーバーから実行されないことを示しています。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:79 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:88 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:94 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:97 -msgid "Note that this play disables the ``gather_facts`` parameter, since you don't want to collect facts about localhost." -msgstr "ローカルホストに関するファクトを収集しないため、このプレイは ``gather_facts`` パラメーターを無効にすることに注意してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:81 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:90 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:96 -msgid "You can run these modules against another server that would then connect to the API if localhost does not have access to vCenter. If so, the required Python modules will need to be installed on that target server. We recommend installing the latest version with pip: ``pip install Pyvmomi`` (as the OS packages are usually out of date and incompatible)." -msgstr "ローカルホストが vCenter サーバーにアクセスできない場合は、API に接続する別のサーバーに対してこのモジュールを実行できます。その場合は、必要な Python モジュールをターゲットサーバーにインストールする必要があります。pip で最新バージョンをインストールすることが推奨されます。インストールするには ``pip install Pyvmomi`` を実行してください (通常は OS パッケージが古く、互換性がないため)。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:83 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:92 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:98 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:99 -msgid "Before you begin, make sure you have:" -msgstr "開始する前に、以下の点を確認してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:85 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:94 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:100 -msgid "Hostname of the ESXi server or vCenter server" -msgstr "ESXi サーバーまたは vCenter サーバーのホスト名" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:86 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:95 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:101 -msgid "Username and password for the ESXi or vCenter server" -msgstr "ESXi サーバーまたは vCenter サーバーのユーザー名およびパスワード" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:87 -msgid "Name of the existing Virtual Machine for which you want to collect folder path" -msgstr "ディレクトリーパスを収集する既存の仮想マシンの名前" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:89 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:98 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:104 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:105 -msgid "For now, you will be entering these directly, but in a more advanced playbook this can be abstracted out and stored in a more secure fashion using :ref:`ansible-vault` or using `Ansible Tower credentials `_." -msgstr "ここでは、これらを直接入力しますが、より高度な Playbook では :ref:`ansible-vault` または `Ansible Tower 認証情報 `_ を使用して、よりセキュアな方法で保存することができます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:91 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:100 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:106 -msgid "If your vCenter or ESXi server is not setup with proper CA certificates that can be verified from the Ansible server, then it is necessary to disable validation of these certificates by using the ``validate_certs`` parameter. To do this you need to set ``validate_certs=False`` in your playbook." -msgstr "vCenter サーバーまたは ESXi サーバーが Ansible サーバーから検証できる適切な CA 証明書で設定されていない場合は、``validate_certs`` パラメーターを使用してこれらの証明書の検証を無効にする必要があります。これを行うには、Playbook で ``validate_certs=False`` を設定する必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:93 -msgid "The name of existing virtual machine will be used as input for ``vmware_guest_find`` module via ``name`` parameter." -msgstr "既存の仮想マシンの名前は、``vmware_guest_find`` パラメーターにより ``name`` モジュールの入力として使用されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:99 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:115 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:116 -msgid "Running this playbook can take some time, depending on your environment and network connectivity. When the run is complete you will see" -msgstr "ご使用の環境およびネットワーク接続によっては、この Playbook の実行に時間がかかる場合があります。実行が完了すると、以下のようになります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:116 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:122 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:169 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:152 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:117 -msgid "If your playbook fails:" -msgstr "Playbook が失敗した場合は、以下を行います。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:118 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:124 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:171 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:154 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:119 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:195 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:107 -msgid "Check if the values provided for username and password are correct." -msgstr "ユーザー名およびパスワードの値が正しいことを確認します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:119 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:125 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:172 -msgid "Check if the datacenter you provided is available." -msgstr "指定したデータセンターが利用可能かどうかを確認します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:120 -msgid "Check if the virtual machine specified exists and you have respective permissions to access VMware object." -msgstr "指定した仮想マシンが存在しているかどうか、および VMware オブジェクトにアクセスする各パーミッションがあるかどうかを確認します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_find_vm_folder.rst:121 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:174 -msgid "Ensure the full folder path you specified already exists." -msgstr "指定したディレクトリーの完全パスが存在していることを確認します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:5 -msgid "Remove an existing VMware virtual machine" -msgstr "既存の VMware 仮想マシンの削除" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:13 -msgid "This guide will show you how to utilize Ansible to remove an existing VMware virtual machine." -msgstr "本ガイドでは、Ansible を使用して既存の VMware 仮想マシンを削除する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:45 -msgid "``vmware_guest`` module tries to mimic VMware Web UI and workflow, so the virtual machine must be in powered off state in order to remove it from the VMware inventory." -msgstr "``vmware_guest`` モジュールは、VMware Web UI およびワークフローを模倣するため、VMware インベントリーから仮想マシンを削除するには、電源がオフになっている必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:49 -msgid "The removal VMware virtual machine using ``vmware_guest`` module is destructive operation and can not be reverted, so it is strongly recommended to take the backup of virtual machine and related files (vmx and vmdk files) before proceeding." -msgstr "``vmware_guest`` モジュールを使用して VMware 仮想マシンを削除することは破壊的な操作であり、元に戻すことができないため、先に進む前に仮想マシンと関連ファイル (vmx ファイルおよび vmdk ファイル) のバックアップを作成することが強く推奨されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:54 -msgid "In this use case / example, user will be removing a virtual machine using name. The following Ansible playbook showcases the basic parameters that are needed for this." -msgstr "このユースケースまたはサンプルでは、ユーザーが名前を使用して仮想マシンを削除します。以下の Ansible Playbook では、このように削除するのに必要な基本パラメーターについて取り上げます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:96 -msgid "Name of the existing Virtual Machine you want to remove" -msgstr "削除する既存の仮想マシンの名前" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:102 -msgid "The name of existing virtual machine will be used as input for ``vmware_guest`` module via ``name`` parameter." -msgstr "既存の仮想マシンの名前は、``vmware_guest`` パラメーターにより ``name`` モジュールの入力として使用されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:108 -msgid "You will not see any JSON output after this playbook completes as compared to other operations performed using ``vmware_guest`` module." -msgstr "``vmware_guest`` モジュールを使用して実行した他の操作と異なり、この Playbook が完了しても、JSON 出力は表示されません。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:116 -msgid "State is changed to ``True`` which notifies that the virtual machine is removed from the VMware inventory. This can take some time depending upon your environment and network connectivity." -msgstr "状態が ``True`` に変更になり、仮想マシンが VMware インベントリーから削除されたことが通知されます。この処理には、ご使用の環境やネットワーク接続によっては時間がかかる場合があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:126 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:173 -msgid "Check if the virtual machine specified exists and you have permissions to access the datastore." -msgstr "指定した仮想マシンが存在しているかどうか、およびデータストアにアクセスするパーミッションがあるかどうかを確認します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst:127 -msgid "Ensure the full folder path you specified already exists. It will not create folders automatically for you." -msgstr "指定した完全なディレクトリーパスが存在することを確認してください。ディレクトリーは自動的に作成されません。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:5 -msgid "Rename an existing virtual machine" -msgstr "既存の仮想マシンの名前変更" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:13 -msgid "This guide will show you how to utilize Ansible to rename an existing virtual machine." -msgstr "本ガイドでは、Ansible を使用して既存の仮想マシンの名前を変更する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:50 -msgid "With the following Ansible playbook you can rename an existing virtual machine by changing the UUID." -msgstr "以下の Ansible Playbook を使用して、UUID を変更して既存の仮想マシンの名前を変更できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:102 -msgid "The UUID of the existing Virtual Machine you want to rename" -msgstr "名前を変更する既存の仮想マシンの UUID" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:108 -msgid "Now you need to supply the information about the existing virtual machine which will be renamed. For renaming virtual machine, ``vmware_guest`` module uses VMware UUID, which is unique across vCenter environment. This value is autogenerated and can not be changed. You will use ``vmware_guest_facts`` module to find virtual machine and get information about VMware UUID of the virtual machine." -msgstr "ここで、名前を変更する既存の仮想マシンの情報を入力する必要があります。仮想マシンの名前を変更するために、``vmware_guest`` モジュールは vCenter 環境全体で一意となる VMware UUID を使用します。この値は自動生成され、変更はできません。``vmware_guest_facts`` モジュールを使用して、仮想マシンの VMware UUID に関する情報を取得します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:110 -msgid "This value will be used input for ``vmware_guest`` module. Specify new name to virtual machine which conforms to all VMware requirements for naming conventions as ``name`` parameter. Also, provide ``uuid`` as the value of VMware UUID." -msgstr "この値は、``vmware_guest`` モジュールの入力を使用します。``name`` パラメーターとして命名規則のすべての VMware 要件に準拠する仮想マシンに新しい名前を指定します。また、``uuid`` を VMware UUID の値として指定します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_rename_vm.rst:163 -msgid "confirming that you've renamed the virtual machine." -msgstr "仮想マシンの名前が変更されたことを確認します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:5 -msgid "Using VMware HTTP API using Ansible" -msgstr "Ansible を使用した VMware HTTP API の使用" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:13 -msgid "This guide will show you how to utilize Ansible to use VMware HTTP APIs to automate various tasks." -msgstr "本書では、Ansible で VMware HTTP API を使用してさまざまなタスクを自動化する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:22 -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:22 -msgid "We recommend installing the latest version with pip: ``pip install Pyvmomi`` on the Ansible control node (as the OS packages are usually out of date and incompatible) if you are planning to use any existing VMware modules." -msgstr "既存の VMware モジュールを使用する予定がある場合は、Ansible コントロールノードで pip を使用して最新版をインストール (``pip install Pyvmomi``) することが推奨されます (OS のパッケージはたいてい古くて互換性がないため)。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:27 -msgid "vCenter Server 6.5 and above with at least one ESXi server" -msgstr "少なくとも 1 台の ESXi サーバーを備えた vCenter Server 6.5 以降" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:31 -msgid "Ansible (or the target server) must have network access to either the vCenter server or the ESXi server" -msgstr "Ansible (またはターゲットサーバー) には、vCenter サーバーまたは ESXi サーバーへのネットワークアクセスが必要です。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:33 -msgid "Username and Password for vCenter" -msgstr "vCenter のユーザー名およびパスワード" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:40 -msgid "VMware HTTP APIs are introduced in vSphere 6.5 and above so minimum level required in 6.5." -msgstr "VMware HTTP API は、vSphere 6.5 以降で導入され、6.5 以上のレベルが必要です。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:41 -msgid "There are very limited number of APIs exposed, so you may need to rely on XMLRPC based VMware modules." -msgstr "公開される API の数は非常に限られているため、XMLRPC ベースの VMware モジュールが必要になる場合があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:47 -msgid "With the following Ansible playbook you can find the VMware ESXi host system(s) and can perform various tasks depending on the list of host systems. This is a generic example to show how Ansible can be utilized to consume VMware HTTP APIs." -msgstr "以下の Ansible Playbook を使用すると、VMware ESXi ホストシステムを見つけ、ホストシステムの一覧に応じてさまざまなタスクを実行できます。これは、Ansible を使用して VMware HTTP API をどのように消費するかを示す一般的な例です。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:93 -msgid "Since Ansible utilizes the VMware HTTP API using the ``uri`` module to perform actions, in this use case it will be connecting directly to the VMware HTTP API from localhost." -msgstr "Ansible は ``uri`` モジュールを使用してアクションを実行するために VMware HTTP API を利用して、このユースケースでは、ローカルホストから VMware HTTP API に直接接続されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:101 -msgid "Hostname of the vCenter server" -msgstr "vCenter サーバーのホスト名" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:102 -msgid "Username and password for the vCenter server" -msgstr "vCenter サーバーのユーザー名およびパスワード" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:103 -msgid "Version of vCenter is at least 6.5" -msgstr "vCenter のバージョンは 6.5 以上" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:107 -msgid "If your vCenter server is not setup with proper CA certificates that can be verified from the Ansible server, then it is necessary to disable validation of these certificates by using the ``validate_certs`` parameter. To do this you need to set ``validate_certs=False`` in your playbook." -msgstr "vCenter サーバーが Ansible サーバーから検証できる適切な CA 証明書で設定されていない場合は、``validate_certs`` パラメーターを使用してこれらの証明書の検証を無効にする必要があります。これを行うには、Playbook で ``validate_certs=False`` を設定する必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:109 -msgid "As you can see, we are using the ``uri`` module in first task to login into the vCenter server and storing result in the ``login`` variable using register. In the second task, using cookies from the first task we are gathering information about the ESXi host system." -msgstr "ご覧のとおり、最初のタスクで ``uri`` モジュールを使用して vCenter サーバーにログインし、登録を使用して ``login`` 変数に結果を保存しています。次のタスクでは、最初のタスクの Cookie を使用して ESXi ホストシステムに関する情報を収集します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:111 -msgid "Using this information, we are changing the ESXi host system's advance configuration." -msgstr "この情報を使用して、ESXi ホストシステムの事前設定を変更します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:155 -msgid "Check if you are using vCenter 6.5 and onwards to use this HTTP APIs." -msgstr "この HTTP API を使用するために、vCenter 6.5 以降を使用しているかどうかを確認します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:159 -msgid "`VMware vSphere and Ansible From Zero to Useful by @arielsanchezmor `_" -msgstr "`VMware vSphere and Ansible From Zero to Useful by @arielsanchezmor `_" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:160 -msgid "vBrownBag session video related to VMware HTTP APIs" -msgstr "VMware HTTP API に関連する vBrownBag セッションビデオ" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:161 -msgid "`Sample Playbooks for using VMware HTTP APIs `_" -msgstr "`Sample Playbooks for using VMware HTTP APIs `_" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_http.rst:162 -msgid "GitHub repo for examples of Ansible playbook to manage VMware using HTTP APIs" -msgstr "HTTP API を使用して VMware を管理する Ansible Playbook 例の GitHub リポジトリー" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:5 -msgid "Using vmware_tools connection plugin" -msgstr "vmware_tools 接続プラグインの使用" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:13 -msgid "This guide will show you how to utilize VMware Connection plugin to communicate and automate various tasks on VMware guest machines." -msgstr "本ガイドでは、VMware Connection プラグインを使用して、VMware ゲストマシンでさまざまなタスクと通信し、自動化する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:20 -msgid "Ansible 2.9 or later must be installed." -msgstr "Ansible 2.9 以降がインストールされている必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:27 -msgid "vCenter Server 6.5 and above" -msgstr "vCenter Server 6.5 以降" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:31 -msgid "Ansible (or the target server) must have network access to either the vCenter server" -msgstr "Ansible (またはターゲットサーバー) には、いずれかの vCenter サーバーへのネットワークアクセスが必要です。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:33 -msgid "Username and Password for vCenter with required permissions" -msgstr "必要なパーミッションを持つ vCenter のユーザー名およびパスワード" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:35 -msgid "VMware tools or openvm-tools with required dependencies like Perl installed on the given virtual machine" -msgstr "指定の仮想マシンにインストールされている Perl などの必要な依存関係のある VMware ツールまたは openvm-tools" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:41 -msgid "You need to use Python 2.7.9 version in order to use ``validate_certs`` option, as this version is capable of changing the SSL verification behaviors." -msgstr "``validate_certs`` オプションを使用するには、Python 2.7.9 バージョンを使用する必要があります。このバージョンは、SSL 検証の動作を変更できるためです。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:47 -msgid "User can run playbooks against VMware virtual machines using ``vmware_tools`` connection plugin." -msgstr "ユーザーは、``vmware_tools`` 接続プラグインを使用して VMware 仮想マシンに対して Playbook を実行できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:49 -msgid "In order work with ``vmware_tools`` connection plugin, you will need to specify hostvars for the given virtual machine." -msgstr "``vmware_tools`` 接続プラグインと連携するには、指定の仮想マシンの hostvar を指定する必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:51 -msgid "For example, if you want to run a playbook on a virtual machine called ``centos_7`` located at ``/Asia-Datacenter1/prod/centos_7`` in the given vCenter, you will need to specify hostvars as follows:" -msgstr "たとえば、指定の vCenter の ``/Asia-Datacenter1/prod/centos_7`` にある ``centos_7`` という名前の仮想マシンで Playbook を実行する場合は、以下のように hostvars を指定する必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:73 -msgid "Here, we are providing vCenter details and credentials for the given virtual machine to run the playbook on. If your virtual machine path is ``Asia-Datacenter1/prod/centos_7``, you specify ``ansible_vmware_guest_path`` as ``Asia-Datacenter1/vm/prod/centos_7``. Please take a note that ``/vm`` is added in the virtual machine path, since this is a logical folder structure in the VMware inventory." -msgstr "ここでは、Playbook を実行するために、指定した仮想マシンの vCenter の詳細と認証情報を提供しています。仮想マシンのパスが ``Asia-Datacenter1/prod/centos_7`` の場合は、``ansible_vmware_guest_path`` を ``Asia-Datacenter1/vm/prod/centos_7`` として指定します。仮想マシンのパスに ``/vm`` が追加されている点に注意してください。これは、VMware インベントリー内が論理的なディレクトリー構造であるためです。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:76 -msgid "Let us now run following playbook," -msgstr "以下の Playbook を実行します。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:88 -msgid "Since Ansible utilizes the ``vmware-tools`` or ``openvm-tools`` service capabilities running in the virtual machine to perform actions, in this use case it will be connecting directly to the guest machine." -msgstr "Ansible は仮想マシンで実行している ``vmware-tools`` または ``openvm-tools`` のサービス機能を使用してアクションを実行するため、このユースケースではゲストマシンに直接接続されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:91 -msgid "For now, you will be entering credentials in plain text, but in a more advanced playbook this can be abstracted out and stored in a more secure fashion using :ref:`ansible-vault` or using `Ansible Tower credentials `_." -msgstr "ここでは、プレーンテキストで認証情報を入力しますが、より高度な Playbook では、:ref:`ansible-vault` または `Ansible Tower 認証情報 `_ を使用してよりセキュアな方法で抽象化および保存できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:97 -msgid "Running this playbook can take some time, depending on your environment and network connectivity. When the run is complete you will see:" -msgstr "ご使用の環境およびネットワーク接続によっては、この Playbook の実行に時間がかかる場合があります。実行が完了すると、以下のようになります。" - -#: ../../rst/scenario_guides/vmware_scenarios/scenario_vmware_tools_connection.rst:120 -msgid "Check if the path of virtual machine is correct. Please mind that ``/vm/`` needs to be provided while specifying virtual machine location." -msgstr "仮想マシンのパスが正しいかどうかを確認します。仮想マシンの場所を指定する際に、``/vm/`` を提供する必要があることに注意してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:5 -msgid "Ansible for VMware Concepts" -msgstr "VMware 向け Ansible の概念" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:7 -msgid "Some of these concepts are common to all uses of Ansible, including VMware automation; some are specific to VMware. You need to understand them to use Ansible for VMware automation. This introduction provides the background you need to follow the :ref:`scenarios` in this guide." -msgstr "これらの概念の中には、VMware の自動化を含む Ansible のすべての用途に共通するものもあれば、VMware に固有のものもあります。VMware の自動化に Ansible を使用するには、これらの概念を理解する必要があります。この章では、本ガイドの :ref:`シナリオ` に従うために必要な背景を説明します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:13 -msgid "Control Node" -msgstr "コントロールノード" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:15 -msgid "Any machine with Ansible installed. You can run commands and playbooks, invoking ``/usr/bin/ansible`` or ``/usr/bin/ansible-playbook``, from any control node. You can use any computer that has Python installed on it as a control node - laptops, shared desktops, and servers can all run Ansible. However, you cannot use a Windows machine as a control node. You can have multiple control nodes." -msgstr "Ansible がインストールされているマシン。どのコントロールノードから でも``/usr/bin/ansible`` または ``/usr/bin/ansible-playbook`` を起動して、コマンドや Playbook を実行できます。コントロールノードとして使用し、Python がインストールされているコンピューターであれば、ラップトップ、共有ディスクトップ、サーバーなど、どのコンピューターでも Ansible を実行することができます。ただし、Windows マシンをコントロールノードとして使用することはできません。コントロールノードは複数使用できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:18 -msgid "Delegation" -msgstr "委譲" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:20 -msgid "Delegation allows you to select the system that executes a given task. If you do not have ``pyVmomi`` installed on your control node, use the ``delegate_to`` keyword on VMware-specific tasks to execute them on any host where you have ``pyVmomi`` installed." -msgstr "委譲を使用すると、特定のタスクを実行するシステムを選択できます。コントロールノードに ``pyVmomi`` がインストールされていない場合は、VMware 固有のタスクで ``delegate_to`` キーワードを使用して、``pyVmomi`` がインストールされている任意のホストで実行します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:23 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:25 -msgid "The units of code Ansible executes. Each module has a particular use, from creating virtual machines on vCenter to managing distributed virtual switches in the vCenter environment. You can invoke a single module with a task, or invoke several different modules in a playbook. For an idea of how many modules Ansible includes, take a look at the :ref:`list of cloud modules`, which includes VMware modules." -msgstr "Ansible が実行するコードの単位。各モジュールには、vCenter での仮想マシンの作成から、vCenter 環境における分散型仮想スイッチの管理まで、特定の用途があります。単一のモジュールを呼び出すか、Playbook でいくつかの異なるモジュールを呼び出します。Ansible に含まれるモジュール数を理解するには、VMware モジュールを含む「:ref:`クラウドモジュールのリスト`」を参照してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:28 -msgid "Playbooks" -msgstr "Playbook" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:30 -msgid "Ordered lists of tasks, saved so you can run those tasks in that order repeatedly. Playbooks can include variables as well as tasks. Playbooks are written in YAML and are easy to read, write, share and understand." -msgstr "順番に並べられたタスクの一覧は保存されているため、その順番でタスクを繰り返し実行することができます。Playbook には、タスクだけでなく、変数も含めることができます。Playbook は YAML で記述されているため、読みやすく、書きやすく、共有しやすく、理解しやすい特徴があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:33 -msgid "pyVmomi" -msgstr "pyVmomi" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:35 -msgid "Ansible VMware modules are written on top of `pyVmomi `_. ``pyVmomi`` is the official Python SDK for the VMware vSphere API that allows user to manage ESX, ESXi, and vCenter infrastructure." -msgstr "Ansible VMware モジュールは、`pyVmomi `_ に記述されています。``pyVmomi`` は、VMware vSphere API の公式 Python SDK で、ユーザーが ESX、ESXi、および vCenter インフラストラクチャーを管理できるようになります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:37 -msgid "You need to install this Python SDK on host from where you want to invoke VMware automation. For example, if you are using control node then ``pyVmomi`` must be installed on control node." -msgstr "VMware の自動化を呼び出すホストに、この Python SDK をインストールする必要があります。たとえば、コントロールノードを使用している場合は、``pyVmomi`` をコントロールノードにインストールする必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:39 -msgid "If you are using any ``delegate_to`` host which is different from your control node then you need to install ``pyVmomi`` on that ``delegate_to`` node." -msgstr "コントロールノードとは異なる ``delegate_to`` ホストを使用している場合は、その ``delegate_to`` ノードに ``pyVmomi`` をインストールする必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_concepts.rst:41 -msgid "You can install pyVmomi using pip:" -msgstr "pip を使用して pyVmomi をインストールできます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_external_doc_links.rst:5 -msgid "Other useful VMware resources" -msgstr "他の便利な VMware リソース" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_external_doc_links.rst:7 -msgid "`VMware API and SDK Documentation `_" -msgstr "`VMware API and SDK Documentation `_" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_external_doc_links.rst:8 -msgid "`VCSIM test container image `_" -msgstr "`VCSIM test container image `_" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_external_doc_links.rst:9 -msgid "`Ansible VMware community wiki page `_" -msgstr "`Ansible VMware community wiki page `_" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_external_doc_links.rst:10 -msgid "`VMware's official Guest Operating system customization matrix `_" -msgstr "`VMware's official Guest Operating system customization matrix `_" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_external_doc_links.rst:11 -msgid "`VMware Compatibility Guide `_" -msgstr "`VMware Compatibility Guide `_" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_getting_started.rst:7 -msgid "Getting Started with Ansible for VMware" -msgstr "VMware 向け Ansible の概要" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_getting_started.rst:9 -msgid "This will have a basic \"hello world\" scenario/walkthrough that gets the user introduced to the basics." -msgstr "ここでは、基本動作を説明する基本的な「hello world」シナリオおよびウォークスルーを紹介します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:5 -msgid "Introduction to Ansible for VMware" -msgstr "VMware 向け Ansible の概要" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:13 -msgid "Ansible provides various modules to manage VMware infrastructure, which includes datacenter, cluster, host system and virtual machine." -msgstr "Ansible は、データセンター、クラスター、ホストシステム、仮想マシンを含む VMware インフラストラクチャーを管理するさまざまなモジュールを提供します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:19 -msgid "Ansible VMware modules are written on top of `pyVmomi `_. pyVmomi is the Python SDK for the VMware vSphere API that allows user to manage ESX, ESXi, and vCenter infrastructure. You can install pyVmomi using pip:" -msgstr "Ansible VMware モジュールは `pyVmomi `_ に記述されています。pyVmomi は VMware vSphere API の Python SDK で、ユーザーが ESX、ESXi、および vCenter インフラストラクチャーを管理できるようにします。pip を使用して pyVmomi をインストールできます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:27 -msgid "Ansible VMware modules leveraging latest vSphere(6.0+) features are using `vSphere Automation Python SDK `_. The vSphere Automation Python SDK also has client libraries, documentation, and sample code for VMware Cloud on AWS Console APIs, NSX VMware Cloud on AWS integration APIs, VMware Cloud on AWS site recovery APIs, NSX-T APIs." -msgstr "最新の vSphere (6.0 以降) 機能を使用する Ansible VMware モジュールは、`vSphere Automation Python SDK `_ を使用しています。VSphere Automation Python SDK には、AWS Console API 向け VMware Cloud、AWS 統合 API 向け NSX VMware Cloud、AWS サイトリカバリー API 向け VMware Cloud、NSX-T API のクライアントライブラリー、ドキュメント、サンプルコードもあります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:29 -msgid "You can install vSphere Automation Python SDK using pip:" -msgstr "VSphere Automation Python SDK は、pip を使用してインストールできます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:36 -msgid "Note:" -msgstr "注記:" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:36 -msgid "Installing vSphere Automation Python SDK also installs ``pyvmomi``. A separate installation of ``pyvmomi`` is not required." -msgstr "vSphere Automation Python SDK をインストールすると、``pyvmomi`` もインストールされます。``pyvmomi`` の個別インストールは必要ありません。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:39 -msgid "vmware_guest module" -msgstr "vmware_guest モジュール" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:41 -msgid "The :ref:`vmware_guest` module manages various operations related to virtual machines in the given ESXi or vCenter server." -msgstr ":ref:`vmware_guest` モジュールは、指定の ESXi または vCenter サーバーで仮想マシンに関連するさまざまな操作を管理します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:46 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:80 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:203 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:115 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1173 -msgid "`pyVmomi `_" -msgstr "`pyVmomi `_" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:47 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:81 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:204 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:116 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1174 -msgid "The GitHub Page of pyVmomi" -msgstr "pyVmomi の GitHub ページ" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:48 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:82 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:205 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:117 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1175 -msgid "`pyVmomi Issue Tracker `_" -msgstr "`pyVmomi Issue Tracker `_" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:49 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:83 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:206 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:118 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1176 -msgid "The issue tracker for the pyVmomi project" -msgstr "pyVmomi プロジェクトの問題トラッカー" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:50 -msgid "`govc `_" -msgstr "`govc `_" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_intro.rst:51 -msgid "govc is a vSphere CLI built on top of govmomi" -msgstr "govc は、govmomi に構築された vSphere CLI です。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:5 -msgid "Using VMware dynamic inventory plugin" -msgstr "VMware 動的インベントリープラグインの使用" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:11 -msgid "VMware Dynamic Inventory Plugin" -msgstr "VMware 動的インベントリープラグイン" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:14 -msgid "The best way to interact with your hosts is to use the VMware dynamic inventory plugin, which dynamically queries VMware APIs and tells Ansible what nodes can be managed." -msgstr "ホストと対話する最適な方法として、VMware の動的インベントリープラグインを使用します。これにより、VMware API を動的にクエリーし、どのノードが管理できるかを Ansible に通知することができます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:20 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:21 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:21 -msgid "To use the VMware dynamic inventory plugins, you must install `pyVmomi `_ on your control node (the host running Ansible)." -msgstr "VMware 動的インベントリープラグインを使用するには、コントロールノード (Ansible を実行するホスト) に `pyVmomi `_ をインストールする必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:23 -msgid "To include tag-related information for the virtual machines in your dynamic inventory, you also need the `vSphere Automation SDK `_, which supports REST API features like tagging and content libraries, on your control node. You can install the ``vSphere Automation SDK`` following `these instructions `_." -msgstr "動的インベントリーに仮想マシンのタグ関連の情報を含めるには、コントロールノードにタグ付けやコンテンツライブラリーなどの REST API 機能をサポートする `vSphere Automation SDK `__ も必要です。`こちらの手順 ` に従って ``vSphere Automation SDK`` をインストールできます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:30 -msgid "To use this VMware dynamic inventory plugin, you need to enable it first by specifying the following in the ``ansible.cfg`` file:" -msgstr "この VMware 動的インベントリープラグインを使用するには、最初に ``ansible.cfg`` ファイルに以下を指定して有効にする必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:37 -msgid "Then, create a file that ends in ``.vmware.yml`` or ``.vmware.yaml`` in your working directory." -msgstr "次に、作業ディレクトリーに、名前の末尾が ``.vmware.yml`` または ``.vmware.yaml`` で終わるファイルを作成します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:39 -msgid "The ``vmware_vm_inventory`` script takes in the same authentication information as any VMware module." -msgstr "``vmware_vm_inventory`` スクリプトは、VMware モジュールと同じ認証情報を取得します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:54 -msgid "Executing ``ansible-inventory --list -i .vmware.yml`` will create a list of VMware instances that are ready to be configured using Ansible." -msgstr "``ansible-inventory --list -i .vmware.yml`` を実行すると、Ansible を使用して設定できる VMware インスタンスの一覧が作成されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:59 -msgid "Since the inventory configuration file contains vCenter password in plain text, a security risk, you may want to encrypt your entire inventory configuration file." -msgstr "インベントリー設定ファイルにはプレーンテキストの vCenter パスワードが含まれるため、セキュリティーリスクがあります。インベントリー設定ファイル全体を暗号化できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:84 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:207 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:119 -msgid "`vSphere Automation SDK GitHub Page `_" -msgstr "`vSphere Automation SDK GitHub Page `_" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:85 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:208 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:120 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1178 -msgid "The GitHub Page of vSphere Automation SDK for Python" -msgstr "Python 向けの vSphere Automation SDK の GitHub ページ" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:86 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:209 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:121 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1179 -msgid "`vSphere Automation SDK Issue Tracker `_" -msgstr "`vSphere Automation SDK Issue Tracker `_" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory.rst:87 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:210 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:122 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1180 -msgid "The issue tracker for vSphere Automation SDK for Python" -msgstr "Python 向けの vSphere Automation SDK の問題トラッカー" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:5 -msgid "Using VMware dynamic inventory plugin - Filters" -msgstr "VMware 動的インベントリープラグインの使用 - フィルター" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:11 -msgid "VMware dynamic inventory plugin - filtering VMware guests" -msgstr "VMware 動的インベントリープラグイン - VMware ゲストのフィルター設定" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:14 -msgid "VMware inventory plugin allows you to filter VMware guests using the ``filters`` configuration parameter." -msgstr "VMware インベントリープラグインを使用すると、``filters`` 設定パラメーターを使用して VMware ゲストにフィルターを設定できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:16 -msgid "This section shows how you configure ``filters`` for the given VMware guest in the inventory." -msgstr "本セクションでは、インベントリー内の特定の VMware ゲストの ``filters`` を設定する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:24 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:24 -msgid "To include tag-related information for the virtual machines in your dynamic inventory, you also need the `vSphere Automation SDK `_, which supports REST API features such as tagging and content libraries, on your control node. You can install the ``vSphere Automation SDK`` following `these instructions `_." -msgstr "動的インベントリーに仮想マシンのタグ関連の情報を含めるには、コントロールノードにタグ付けやコンテンツライブラリーなどの REST API 機能をサポートする `vSphere Automation SDK `__ も必要です。`こちらの手順 ` に従って ``vSphere Automation SDK`` をインストールできます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:31 -msgid "Starting in Ansible 2.10, the VMware dynamic inventory plugin is available in the ``community.vmware`` collection included Ansible. Alternately, to install the latest ``community.vmware`` collection:" -msgstr "Ansible 2.10 以降では、Ansible を含む ``community.vmware`` コレクションで VMware 動的インベントリープラグインを利用できます。最新の ``community.vmware`` コレクションをインストールする場合は、以下を実行します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:38 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:38 -msgid "To use this VMware dynamic inventory plugin:" -msgstr "VMware 動的インベントリープラグインを使用するには、以下を行います。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:40 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:40 -msgid "Enable it first by specifying the following in the ``ansible.cfg`` file:" -msgstr "``ansible.cfg`` ファイルで以下を指定して、まず有効にします。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:47 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:47 -msgid "Create a file that ends in ``vmware.yml`` or ``vmware.yaml`` in your working directory." -msgstr "作業ディレクトリーに、名前の末尾が ``vmware.yml`` または ``vmware.yaml`` で終わるファイルを作成します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:49 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:49 -msgid "The ``vmware_vm_inventory`` inventory plugin takes in the same authentication information as any other VMware modules does." -msgstr "``vmware_vm_inventory`` インベントリープラグインは、他の VMware モジュールと同様に認証情報を取得します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:51 -msgid "Let us assume we want to list all RHEL7 VMs with the power state as \"poweredOn\". A valid inventory file with filters for the given VMware guest looks as follows:" -msgstr "電源状態が「PoweredOn」である RHEL7 仮想マシンの一覧を表示するとします。指定した VMware ゲストに対してフィルター機能が有効なインベントリーファイルは次のようになります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:69 -msgid "Here, we have configured two filters -" -msgstr "ここでは、フィルターを 2 つ設定しました。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:71 -msgid "``config.guestId`` is equal to ``rhel7_64Guest``" -msgstr "``config.guestId`` は ``rhel7_64Guest`` と等しい" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:72 -msgid "``summary.runtime.powerState`` is equal to ``poweredOn``" -msgstr "``summary.runtime.powerState`` は ``poweredOn`` と等しい" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:74 -msgid "This retrieves all the VMs which satisfy these two conditions and populates them in the inventory. Notice that the conditions are combined using an ``and`` operation." -msgstr "これにより、この 2 つの条件を満たすすべての仮想マシンが取得され、インベントリーに反映されます。``and`` 操作を使用して条件が組み合わされていることに注意してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:78 -msgid "Using ``or`` conditions in filters" -msgstr "フィルターでの ``or`` 条件の使用" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:80 -msgid "Let us assume you want filter RHEL7 and Ubuntu VMs. You can use multiple filters using ``or`` condition in your inventory file." -msgstr "RHEL7 および Ubuntu の仮想マシンにフィルターを設定するとします。インベントリーファイルで ``or`` 条件を使用して複数のフィルターを使用できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:82 -msgid "A valid filter in the VMware inventory file for this example is:" -msgstr "この例の VMware インベントリーファイルにおける有効なフィルターは以下のとおりです。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:99 -msgid "You can check all allowed properties for filters for the given virtual machine at :ref:`vmware_inventory_vm_attributes`." -msgstr ":ref:`vmware_inventory_vm_attributes` で指定の仮想マシンのフィルターに許可されるすべてのプロパティーを確認できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:101 -msgid "If you are using the ``properties`` parameter with custom VM properties, make sure that you include all the properties used by filters as well in your VM property list." -msgstr "カスタムの仮想マシンのプロパティーで ``properties`` パラメーターを使用している場合は、仮想マシンのプロパティーの一覧にフィルターが使用するすべてのプロパティーを含めるようにしてください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:103 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:136 -msgid "For example, if we want all RHEL7 and Ubuntu VMs that are poweredOn, you can use inventory file:" -msgstr "たとえば、RHEL7 および Ubuntu の仮想マシンにすべて電源が入っているようにするには、インベントリーファイルを使用できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:125 -msgid "Here, we are using minimum VM properties, that is ``config.name``, ``config.guestId``, ``summary.runtime.powerState``, and ``guest.ipAddress``." -msgstr "ここでは、最小の仮想マシンプロパティー (``config.name``、``config.guestId``、``summary.runtime.powerState``、および ``guest.ipAddress``) を使用します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:127 -msgid "``config.name`` is used by the ``hostnames`` parameter." -msgstr "``config.name`` は、``hostnames`` パラメーターにより使用されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:128 -msgid "``config.guestId`` and ``summary.runtime.powerState`` are used by the ``filters`` parameter." -msgstr "``config.guestId`` および ``summary.runtime.powerState`` は、``filters`` パラメーターで使用されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:129 -msgid "``guest.guestId`` is used by ``ansible_host`` internally by the inventory plugin." -msgstr "``guest.guestId`` は、インベントリープラグインにより ``ansible_host`` に内部的に使用されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:132 -msgid "Using regular expression in filters" -msgstr "フィルターでの正規表現の使用" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:134 -msgid "Let us assume you want filter VMs with specific IP range. You can use regular expression in ``filters`` in your inventory file." -msgstr "特定の IP 範囲を持つ仮想マシンにフィルターを設定するとします。インベントリーファイルの ``filters`` で正規表現を使用できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:157 -msgid "Here, we are using ``guest.ipAddress`` VM property. This property is optional and depended upon VMware tools installed on VMs. We are using ``match`` to validate the regular expression for the given IP range." -msgstr "ここで、``guest.ipAddress`` 仮想マシンプロパティーを使用します。このプロパティーは任意で、仮想マシンにインストールされている VMware ツールに依存します。``match`` を使用して、指定された IP 範囲の正規表現を検証します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:160 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:71 -msgid "Executing ``ansible-inventory --list -i .vmware.yml`` creates a list of the virtual machines that are ready to be configured using Ansible." -msgstr "``ansible-inventory --list -i .vmware.yml`` を実行すると、Ansible を使用して設定できる仮想マシンの一覧が作成されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:165 -msgid "You will notice that the inventory hosts are filtered depending on your ``filters`` section." -msgstr "``filters`` セクションに応じてインベントリーホストにフィルターが設定される点に注意してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:191 -msgid "Troubleshooting filters" -msgstr "フィルターのトラブルシューティング" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:193 -msgid "If the custom property specified in ``filters`` fails:" -msgstr "``filters`` で指定されたカスタムプロパティーが失敗する場合:" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:196 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:108 -msgid "Make sure it is a valid property, see :ref:`vmware_inventory_vm_attributes`." -msgstr "有効なプロパティーであることを確認します。「:ref:`vmware_inventory_vm_attributes`」を参照してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:197 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:109 -msgid "Use ``strict: True`` to get more information about the error." -msgstr "``strict: True`` を使用して、エラーに関する詳細情報を取得します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:198 -msgid "Please make sure that you are using latest version of the VMware collection." -msgstr "VMware コレクションの最新バージョンを使用していることを確認してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:211 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:123 -msgid ":ref:`vmware_inventory_vm_attributes`" -msgstr ":ref:`vmware_inventory_vm_attributes`" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst:212 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:124 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:5 -msgid "Using Virtual machine attributes in VMware dynamic inventory plugin" -msgstr "VMware 動的インベントリープラグインでの仮想マシン属性の使用" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:5 -msgid "Using VMware dynamic inventory plugin - Hostnames" -msgstr "VMware 動的インベントリープラグインの使用 - ホスト名" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:11 -msgid "VMware dynamic inventory plugin - customizing hostnames" -msgstr "VMware 動的インベントリープラグイン - ホスト名のカスタマイズ" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:14 -msgid "VMware inventory plugin allows you to configure hostnames using the ``hostnames`` configuration parameter." -msgstr "VMware インベントリープラグインでは、``hostnames`` 設定パラメーターを使用してホスト名を設定できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:16 -msgid "In this scenario guide we will see how you configure hostnames from the given VMware guest in the inventory." -msgstr "このシナリオでは、インベントリーで、指定した VMware ゲストからホスト名を設定する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:31 -msgid "Starting in Ansible 2.10, the VMware dynamic inventory plugin is available in the ``community.vmware`` collection included Ansible. To install the latest ``community.vmware`` collection:" -msgstr "Ansible 2.10 以降では、VMware 動的インベントリープラグインが Ansible に含まれる ``community.vmware`` コレクションで利用可能になりました。最新の ``community.vmware`` コレクションをインストールするには、以下を実行します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:51 -msgid "Here's an example of a valid inventory file with custom hostname for the given VMware guest:" -msgstr "以下は、特定の VMware ゲストのカスタムホスト名を持つ有効なインベントリーファイルの例です。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:66 -msgid "Here, we have configured a custom hostname by setting the ``hostnames`` parameter to ``config.name``. This will retrieve the ``config.name`` property from the virtual machine and populate it in the inventory." -msgstr "ここでは、``hostnames`` パラメーターを ``config.name`` に設定してカスタムのホスト名を設定し、仮想マシンから ``config.name`` プロパティーを取得し、これをインベントリーに反映します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:69 -msgid "You can check all allowed properties for the given virtual machine at :ref:`vmware_inventory_vm_attributes`." -msgstr ":ref:`vmware_inventory_vm_attributes` で指定の仮想マシンに対して許可されるすべてのプロパティーを確認できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:76 -msgid "You will notice that instead of default behavior of representing the hostname as ``config.name + _ + config.uuid``, the inventory hosts show value as ``config.name``." -msgstr "ホスト名を ``config.name + _ + config.uuid`` として表示する代わりに、インベントリーホストは値を ``config.name`` と表示することに注意してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:105 -msgid "If the custom property specified in ``hostnames`` fails:" -msgstr "``hostnames`` で指定されたカスタムプロパティーが失敗する場合:" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst:110 -msgid "Please make sure that you are using latest version VMware collection." -msgstr "最新バージョンの VMware コレクションを使用していることを確認してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:11 -msgid "Virtual machine attributes" -msgstr "仮想マシンの属性" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:13 -msgid "You can use virtual machine properties which can be used to populate ``hostvars`` for the given virtual machine in a VMware dynamic inventory plugin." -msgstr "VMware 動的インベントリープラグインで指定の仮想マシンの ``hostvars`` を設定するのに使用できる仮想マシンプロパティーを使用できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:17 -msgid "capability" -msgstr "機能" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:19 -msgid "This section describes settings for the runtime capabilities of the virtual machine." -msgstr "本セクションでは、仮想マシンのランタイム機能の設定を説明します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:22 -msgid "snapshotOperationsSupported (bool)" -msgstr "snapshotOperationsSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:24 -msgid "Indicates whether or not a virtual machine supports snapshot operations." -msgstr "仮想マシンでスナップショットの操作をサポートするかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:27 -msgid "multipleSnapshotsSupported (bool)" -msgstr "multipleSnapshotsSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:29 -msgid "Indicates whether or not a virtual machine supports multiple snapshots. This value is not set when the virtual machine is unavailable, for instance, when it is being created or deleted." -msgstr "仮想マシンが複数のスナップショットをサポートするかどうかを示します。この値は、仮想マシンの作成時や削除時など、仮想マシンが利用できないときには設定されません。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:33 -msgid "snapshotConfigSupported (bool)" -msgstr "snapshotConfigSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:35 -msgid "Indicates whether or not a virtual machine supports snapshot config." -msgstr "仮想マシンがスナップショット設定をサポートするかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:38 -msgid "poweredOffSnapshotsSupported (bool)" -msgstr "poweredOffSnapshotsSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:40 -msgid "Indicates whether or not a virtual machine supports snapshot operations in ``poweredOff`` state." -msgstr "仮想マシンが ``poweredOff`` 状態のスナップショット操作に対応しているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:43 -msgid "memorySnapshotsSupported (bool)" -msgstr "memorySnapshotsSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:45 -msgid "Indicates whether or not a virtual machine supports memory snapshots." -msgstr "仮想マシンがメモリースナップショットをサポートするかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:48 -msgid "revertToSnapshotSupported (bool)" -msgstr "revertToSnapshotSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:50 -msgid "Indicates whether or not a virtual machine supports reverting to a snapshot." -msgstr "仮想マシンをスナップショットの状態に戻すかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:53 -msgid "quiescedSnapshotsSupported (bool)" -msgstr "quiescedSnapshotsSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:55 -msgid "Indicates whether or not a virtual machine supports quiesced snapshots." -msgstr "仮想マシンが静止状態のスナップショットをサポートするかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:58 -msgid "disableSnapshotsSupported (bool)" -msgstr "disableSnapshotsSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:60 -msgid "Indicates whether or not snapshots can be disabled." -msgstr "スナップショットを無効にすることができるかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:63 -msgid "lockSnapshotsSupported (bool)" -msgstr "lockSnapshotsSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:65 -msgid "Indicates whether or not the snapshot tree can be locked." -msgstr "スナップショットツリーがロックされるかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:68 -msgid "consolePreferencesSupported (bool)" -msgstr "consolePreferencesSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:70 -msgid "Indicates whether console preferences can be set for the virtual machine." -msgstr "コンソール設定を仮想マシンに設定できるかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:73 -msgid "cpuFeatureMaskSupported (bool)" -msgstr "cpuFeatureMaskSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:75 -msgid "Indicates whether CPU feature requirements masks can be set for the virtual machine." -msgstr "CPU 機能要件のマスクを仮想マシンに設定できるかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:78 -msgid "s1AcpiManagementSupported (bool)" -msgstr "s1AcpiManagementSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:80 -msgid "Indicates whether or not a virtual machine supports ACPI S1 settings management." -msgstr "仮想マシンが ACPI S1 設定管理をサポートするかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:83 -msgid "settingScreenResolutionSupported (bool)" -msgstr "settingScreenResolutionSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:85 -msgid "Indicates whether or not the virtual machine supports setting the screen resolution of the console window." -msgstr "仮想マシンがコンソールウィンドウの画面の解像度の設定をサポートするかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:88 -msgid "toolsAutoUpdateSupported (bool)" -msgstr "toolsAutoUpdateSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:90 -msgid "Supports tools auto-update." -msgstr "ツールの自動更新をサポートします。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:93 -msgid "vmNpivWwnSupported (bool)" -msgstr "vmNpivWwnSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:95 -msgid "Supports virtual machine NPIV WWN." -msgstr "仮想マシンの NPIV WWN をサポートします。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:98 -msgid "npivWwnOnNonRdmVmSupported (bool)" -msgstr "npivWwnOnNonRdmVmSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:100 -msgid "Supports assigning NPIV WWN to virtual machines that do not have RDM disks." -msgstr "RDM ディスクを持たない仮想マシンへの NPIV WWN の割り当てをサポートします。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:103 -msgid "vmNpivWwnDisableSupported (bool)" -msgstr "vmNpivWwnDisableSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:105 -msgid "Indicates whether the NPIV disabling operation is supported on the virtual machine." -msgstr "仮想マシンで NPIV の無効化操作がサポートされているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:108 -msgid "vmNpivWwnUpdateSupported (bool)" -msgstr "vmNpivWwnUpdateSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:110 -msgid "Indicates whether the update of NPIV WWNs are supported on the virtual machine." -msgstr "仮想マシンで NPIV WWN の更新がサポートされているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:113 -msgid "swapPlacementSupported (bool)" -msgstr "swapPlacementSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:115 -msgid "Flag indicating whether the virtual machine has a configurable (swapfile placement policy)." -msgstr "仮想マシンに設定可能な (swapfile の配置ポリシー) があるかどうかを示すフラグ。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:118 -msgid "toolsSyncTimeSupported (bool)" -msgstr "toolsSyncTimeSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:120 -msgid "Indicates whether asking tools to sync time with the host is supported." -msgstr "ツールにホストと時刻の同期を要求することをサポートしているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:123 -msgid "virtualMmuUsageSupported (bool)" -msgstr "virtualMmuUsageSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:125 -msgid "Indicates whether or not the use of nested page table hardware support can be explicitly set." -msgstr "入れ子ページテーブルのハードウェアサポートを明示的に設定できるかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:128 -msgid "diskSharesSupported (bool)" -msgstr "diskSharesSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:130 -msgid "Indicates whether resource settings for disks can be applied to the virtual machine." -msgstr "ディスクのリソース設定を仮想マシンに適用できるかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:133 -msgid "bootOptionsSupported (bool)" -msgstr "bootOptionsSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:135 -msgid "Indicates whether boot options can be configured for the virtual machine." -msgstr "仮想マシンに起動オプションを設定できるかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:138 -msgid "bootRetryOptionsSupported (bool)" -msgstr "bootRetryOptionsSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:140 -msgid "Indicates whether automatic boot retry can be configured for the virtual machine." -msgstr "仮想マシンに自動起動再試行を設定できるかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:143 -msgid "settingVideoRamSizeSupported (bool)" -msgstr "settingVideoRamSizeSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:145 -msgid "Flag indicating whether the video RAM size of the virtual machine can be configured." -msgstr "仮想マシンのビデオ RAM サイズを設定できるかどうかを示すフラグ。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:148 -msgid "settingDisplayTopologySupported (bool)" -msgstr "settingDisplayTopologySupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:150 -msgid "Indicates whether or not the virtual machine supports setting the display topology of the console window." -msgstr "仮想マシンがコンソールウィンドウの表示トポロジーの設定に対応しているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:153 -msgid "recordReplaySupported (bool)" -msgstr "recordReplaySupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:155 -msgid "Indicates whether record and replay functionality is supported on the virtual machine." -msgstr "仮想マシンで記録機能および再生機能がサポートされるかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:158 -msgid "changeTrackingSupported (bool)" -msgstr "changeTrackingSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:160 -msgid "Indicates that change tracking is supported for virtual disks of the virtual machine. However, even if change tracking is supported, it might not be available for all disks of the virtual machine. For example, passthru raw disk mappings or disks backed by any Ver1BackingInfo cannot be tracked." -msgstr "仮想マシンの仮想ディスクで、変更追跡がサポートされることを示しますが、変更追跡がサポートされる場合でも、仮想マシンのすべてのディスクで利用できるわけではありません。たとえば、パススルーの RAW ディスクマッピングや、任意の Ver1BackingInfo でバックアップされたディスクは追跡できません。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:165 -msgid "multipleCoresPerSocketSupported (bool)" -msgstr "multipleCoresPerSocketSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:167 -msgid "Indicates whether multiple virtual cores per socket is supported on the virtual machine." -msgstr "1 ソケットあたりの複数の仮想コアが仮想マシンでサポートされているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:170 -msgid "hostBasedReplicationSupported (bool)" -msgstr "hostBasedReplicationSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:172 -msgid "Indicates that host based replication is supported on the virtual machine. However, even if host based replication is supported, it might not be available for all disk types. For example, passthru raw disk mappings can not be replicated." -msgstr "仮想マシンでホストベースのレプリケーションがサポートされていることを示しますが、ホストベースのレプリケーションがサポートされる場合でも、すべてのディスクタイプで利用できない可能性があります。たとえば、パススルーの RAW ディスクマッピングは複製できません。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:177 -msgid "guestAutoLockSupported (bool)" -msgstr "guestAutoLockSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:179 -msgid "Indicates whether or not guest autolock is supported on the virtual machine." -msgstr "仮想マシンでゲストの自動ロックがサポートされているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:182 -msgid "memoryReservationLockSupported (bool)" -msgstr "memoryReservationLockSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:184 -msgid "Indicates whether :ref:`memory_reservation_locked_to_max` may be set to true for the virtual machine." -msgstr "仮想マシンに対して :ref:`memory_reservation_locked_to_max` が true に設定されるかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:187 -msgid "featureRequirementSupported (bool)" -msgstr "featureRequirementSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:189 -msgid "Indicates whether the featureRequirement feature is supported." -msgstr "featureRequirement 機能がサポートされているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:192 -msgid "poweredOnMonitorTypeChangeSupported (bool)" -msgstr "poweredOnMonitorTypeChangeSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:194 -msgid "Indicates whether a monitor type change is supported while the virtual machine is in the ``poweredOn`` state." -msgstr "仮想マシンが ``poweredOn`` 状態にある間にモニタータイプの変更がサポートされているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:197 -msgid "seSparseDiskSupported (bool)" -msgstr "seSparseDiskSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:199 -msgid "Indicates whether the virtual machine supports the Flex-SE (space-efficent, sparse) format for virtual disks." -msgstr "仮想マシンが仮想ディスクの Flex-SE (スペースが有効、スパース) 形式をサポートしているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:202 -msgid "nestedHVSupported (bool)" -msgstr "nestedHVSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:204 -msgid "Indicates whether the virtual machine supports nested hardware-assisted virtualization." -msgstr "仮想マシンがネストされたハードウェア支援型仮想化をサポートしているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:207 -msgid "vPMCSupported (bool)" -msgstr "vPMCSupported (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:209 -msgid "Indicates whether the virtual machine supports virtualized CPU performance counters." -msgstr "仮想マシンが仮想 CPU パフォーマンスカウンターをサポートしているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:213 -msgid "config" -msgstr "設定" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:215 -msgid "This section describes the configuration settings of the virtual machine, including the name and UUID. This property is set when a virtual machine is created or when the ``reconfigVM`` method is called. The virtual machine configuration is not guaranteed to be available. For example, the configuration information would be unavailable if the server is unable to access the virtual machine files on disk, and is often also unavailable during the initial phases of virtual machine creation." -msgstr "このセクションでは、名前および UUID を含む仮想マシンの設定を説明します。このプロパティーは、仮想マシンの作成時または ``reconfigVM`` メソッドが呼び出される際に設定されます。たとえば、仮想マシンの設定が利用可能になる保証はありません。たとえば、サーバーがディスク上の仮想マシンファイルにアクセスできない場合は、設定情報は利用できません。仮想マシン作成の初期段階でも利用できないことが多々あります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:221 -msgid "changeVersion (str)" -msgstr "changeVersion (str)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:223 -msgid "The changeVersion is a unique identifier for a given version of the configuration. Each change to the configuration updates this value. This is typically implemented as an ever increasing count or a time-stamp. However, a client should always treat this as an opaque string." -msgstr "changeVersion は、設定の特定バージョンの一意の識別子です。設定への変更はそれぞれこの値を更新します。これは通常、増加し続けるカウントやタイムスタンプとして実装されますが、クライアントは常にこれを不透明な文字列として扱う必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:228 -msgid "modified (datetime)" -msgstr "modified (datetime)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:230 -msgid "Last time a virtual machine's configuration was modified." -msgstr "仮想マシンの設定が最後に変更した時間。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:233 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:680 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1113 -msgid "name (str)" -msgstr "name (str)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:235 -#, python-format -msgid "Display name of the virtual machine. Any / (slash), \\ (backslash), character used in this name element is escaped. Similarly, any % (percent) character used in this name element is escaped, unless it is used to start an escape sequence. A slash is escaped as %2F or %2f. A backslash is escaped as %5C or %5c, and a percent is escaped as %25." -msgstr "仮想マシンの表示名です。/ (スラッシュ)、\\ (バックスラッシュ)、この名前要素で使用される文字がエスケープされます。同様に、エスケープ処理を開始するのに使用されていない限り、この名前要素で使用される % (パーセント) 文字はエスケープされます。スラッシュをエスケープする場合は %2F または %2f となり、バックスラッシュをエスケープする場合は %5C または %5c となり、パーセントをエスケープする場合は %25 となります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:240 -msgid "guestFullName (str)" -msgstr "guestFullName (str)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:242 -msgid "This is the full name of the guest operating system for the virtual machine. For example: Windows 2000 Professional. See :ref:`alternate_guest_name`." -msgstr "これは、仮想マシンのゲストオペレーティングシステムの完全な名前です (たとえば、Windows 2000 Professional)。「:ref:`alternate_guest_name`」を参照してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:245 -msgid "version (str)" -msgstr "version (str)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:247 -msgid "The version string for the virtual machine." -msgstr "仮想マシンのバージョン文字列。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:250 -msgid "uuid (str)" -msgstr "uuid (str)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:252 -msgid "128-bit SMBIOS UUID of a virtual machine represented as a hexadecimal string in \"12345678-abcd-1234-cdef-123456789abc\" format." -msgstr "仮想マシンの 128 ビット SMBIOS UUID は、「12345678-abcd-1234-cdef-123456789abc」形式で 16 進数の文字列として表されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:255 -msgid "instanceUuid (str, optional)" -msgstr "instanceUuid (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:257 -msgid "VirtualCenter-specific 128-bit UUID of a virtual machine, represented as a hexadecimal string. This identifier is used by VirtualCenter to uniquely identify all virtual machine instances, including those that may share the same SMBIOS UUID." -msgstr "仮想マシンの VirtualCenter 固有の 128 ビットの UUID は 16 進法として表示されます。この識別子は、同じ SMBIOS UUID を共有する可能性のある仮想マシンインスタンスを含め、すべての仮想マシンインスタンスを一意に識別するために VirtualCenter により使用されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:260 -msgid "npivNodeWorldWideName (long, optional)" -msgstr "npivNodeWorldWideName (long, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:262 -msgid "A 64-bit node WWN (World Wide Name)." -msgstr "64 ビットノード WWN (World Wide Name)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:265 -msgid "npivPortWorldWideName (long, optional)" -msgstr "npivPortWorldWideName (long, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:267 -msgid "A 64-bit port WWN (World Wide Name)." -msgstr "64 ビットのポート WWN (World Wide Name)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:270 -msgid "npivWorldWideNameType (str, optional)" -msgstr "npivWorldWideNameType (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:272 -msgid "The source that provides/generates the assigned WWNs." -msgstr "割り当てられた WWN を提供または生成するソース。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:275 -msgid "npivDesiredNodeWwns (short, optional)" -msgstr "npivDesiredNodeWwns (short, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:277 -msgid "The NPIV node WWNs to be extended from the original list of WWN numbers." -msgstr "WWN 番号の元の一覧から拡張される NPIV ノード WWN。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:280 -msgid "npivDesiredPortWwns (short, optional)" -msgstr "npivDesiredPortWwns (short, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:282 -msgid "The NPIV port WWNs to be extended from the original list of WWN numbers." -msgstr "WWN 番号の元のリストから拡張される NPIV ポート WWN。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:285 -msgid "npivTemporaryDisabled (bool, optional)" -msgstr "npivTemporaryDisabled (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:287 -msgid "This property is used to enable or disable the NPIV capability on a desired virtual machine on a temporary basis." -msgstr "このプロパティーは、必要な仮想マシンの NPIV 機能を一時的に有効または無効にするために使用されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:290 -msgid "npivOnNonRdmDisks (bool, optional)" -msgstr "npivOnNonRdmDisks (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:292 -msgid "This property is used to check whether the NPIV can be enabled on the Virtual machine with non-rdm disks in the configuration, so this is potentially not enabling npiv on vmfs disks. Also this property is used to check whether RDM is required to generate WWNs for a virtual machine." -msgstr "このプロパティーは、設定内の非 rdm ディスクを持つ仮想マシンで NPIV を有効にすることができるかどうかを確認するのに使用するため、vmfs ディスクで npiv が有効になっていない可能性があります。また、このプロパティーは、仮想マシンの WWN を生成する必要があるかどうかを確認するのに使用されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:296 -msgid "locationId (str, optional)" -msgstr "locationId (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:298 -msgid "Hash incorporating the virtual machine's config file location and the UUID of the host assigned to run the virtual machine." -msgstr "仮想マシンの設定ファイルの場所と、仮想マシンの実行に割り当てられたホストの UUID を組み込んだハッシュ。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:301 -msgid "template (bool)" -msgstr "template (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:303 -msgid "Flag indicating whether or not a virtual machine is a template." -msgstr "仮想マシンがテンプレートであるかどうかを示すフラグ。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:306 -msgid "guestId (str)" -msgstr "guestId (str)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:308 -msgid "Guest operating system configured on a virtual machine." -msgstr "仮想マシンに設定されたゲストオペレーティングシステム。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:313 -msgid "alternateGuestName (str)" -msgstr "alternateGuestName (str)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:315 -msgid "Used as display name for the operating system if guestId isotherorother-64. See :ref:`guest_full_name`." -msgstr "guestId が other または other-64 の場合、オペレーティングシステムの表示名として使用されます。「:ref:`guest_full_name`」を参照してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:318 -msgid "annotation (str, optional)" -msgstr "annotation (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:320 -msgid "Description for the virtual machine." -msgstr "仮想マシンの説明。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:323 -msgid "files (vim.vm.FileInfo)" -msgstr "files (vim.vm.FileInfo)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:325 -msgid "Information about the files associated with a virtual machine. This information does not include files for specific virtual disks or snapshots." -msgstr "仮想マシンに関連付けられたファイルに関する情報。この情報には、特定の仮想ディスクやスナップショットのファイルが含まれません。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:329 -msgid "tools (vim.vm.ToolsConfigInfo, optional)" -msgstr "tools (vim.vm.ToolsConfigInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:331 -msgid "Configuration of VMware Tools running in the guest operating system." -msgstr "ゲストオペレーティングシステムで実行している VMware ツールの設定。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:334 -msgid "flags (vim.vm.FlagInfo)" -msgstr "flags (vim.vm.FlagInfo)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:336 -msgid "Additional flags for a virtual machine." -msgstr "仮想マシンの追加フラグ。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:339 -msgid "consolePreferences (vim.vm.ConsolePreferences, optional)" -msgstr "consolePreferences (vim.vm.ConsolePreferences, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:341 -msgid "Legacy console viewer preferences when doing power operations." -msgstr "レガシーコンソールビューアーは、電源操作を実行する際に設定できます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:344 -msgid "defaultPowerOps (vim.vm.DefaultPowerOpInfo)" -msgstr "defaultPowerOps (vim.vm.DefaultPowerOpInfo)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:346 -msgid "Configuration of default power operations." -msgstr "デフォルトの電源操作の設定。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:349 -msgid "hardware (vim.vm.VirtualHardware)" -msgstr "hardware (vim.vm.VirtualHardware)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:351 -msgid "Processor, memory, and virtual devices for a virtual machine." -msgstr "仮想マシンのプロセッサー、メモリー、および仮想デバイス。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:354 -msgid "cpuAllocation (vim.ResourceAllocationInfo, optional)" -msgstr "cpuAllocation (vim.ResourceAllocationInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:356 -msgid "Resource limits for CPU." -msgstr "CPU のリソース制限。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:359 -msgid "memoryAllocation (vim.ResourceAllocationInfo, optional)" -msgstr "memoryAllocation (vim.ResourceAllocationInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:361 -msgid "Resource limits for memory." -msgstr "メモリーのリソース制限。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:364 -msgid "latencySensitivity (vim.LatencySensitivity, optional)" -msgstr "latencySensitivity (vim.LatencySensitivity, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:366 -msgid "The latency-sensitivity of the virtual machine." -msgstr "仮想マシンのレイテンシーの感度。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:369 -msgid "memoryHotAddEnabled (bool, optional)" -msgstr "memoryHotAddEnabled (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:371 -msgid "Whether memory can be added while the virtual machine is running." -msgstr "仮想マシンの実行中にメモリーを追加できるかどうか。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:374 -msgid "cpuHotAddEnabled (bool, optional)" -msgstr "cpuHotAddEnabled (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:376 -msgid "Whether virtual processors can be added while the virtual machine is running." -msgstr "仮想マシンの実行中に仮想プロセッサーを追加できるかどうか。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:379 -msgid "cpuHotRemoveEnabled (bool, optional)" -msgstr "cpuHotRemoveEnabled (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:381 -msgid "Whether virtual processors can be removed while the virtual machine is running." -msgstr "仮想マシンの実行中に仮想プロセッサーを削除できるかどうか。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:384 -msgid "hotPlugMemoryLimit (long, optional)" -msgstr "hotPlugMemoryLimit (long, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:386 -msgid "The maximum amount of memory, in MB, than can be added to a running virtual machine." -msgstr "実行中の仮想マシンに追加できるメモリーの最大量 (MB 単位)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:389 -msgid "hotPlugMemoryIncrementSize (long, optional)" -msgstr "hotPlugMemoryIncrementSize (long, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:391 -msgid "Memory, in MB that can be added to a running virtual machine." -msgstr "実行中の仮想マシンに追加できるメモリー (MB 単位)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:394 -msgid "cpuAffinity (vim.vm.AffinityInfo, optional)" -msgstr "cpuAffinity (vim.vm.AffinityInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:396 -msgid "Affinity settings for CPU." -msgstr "CPU のアフィニティー設定。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:399 -msgid "memoryAffinity (vim.vm.AffinityInfo, optional)" -msgstr "memoryAffinity (vim.vm.AffinityInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:401 -msgid "Affinity settings for memory." -msgstr "メモリーのアフィニティー設定。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:404 -msgid "networkShaper (vim.vm.NetworkShaperInfo, optional)" -msgstr "networkShaper (vim.vm.NetworkShaperInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:406 -msgid "Resource limits for network." -msgstr "ネットワークのリソース制限。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:409 -msgid "extraConfig (vim.option.OptionValue, optional)" -msgstr "extraConfig (vim.option.OptionValue, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:411 -msgid "Additional configuration information for the virtual machine." -msgstr "仮想マシンの追加設定情報。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:414 -msgid "cpuFeatureMask (vim.host.CpuIdInfo, optional)" -msgstr "cpuFeatureMask (vim.host.CpuIdInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:416 -msgid "Specifies CPU feature compatibility masks that override the defaults from the ``GuestOsDescriptor`` of the virtual machine's guest OS." -msgstr "仮想マシンのゲスト OS の ``GuestOsDescriptor`` からデフォルトを上書きする CPU 機能互換性マスクを指定します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:419 -msgid "datastoreUrl (vim.vm.ConfigInfo.DatastoreUrlPair, optional)" -msgstr "datastoreUrl (vim.vm.ConfigInfo.DatastoreUrlPair, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:421 -msgid "Enumerates the set of datastores that the virtual machine is stored on, as well as the URL identification for each of these." -msgstr "仮想マシンが保存されるデータストアのセットと、その各 URL ID を列挙します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:424 -msgid "swapPlacement (str, optional)" -msgstr "swapPlacement (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:426 -msgid "Virtual machine swapfile placement policy." -msgstr "仮想マシンの swapfile 配置ポリシー。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:429 -msgid "bootOptions (vim.vm.BootOptions, optional)" -msgstr "bootOptions (vim.vm.BootOptions, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:431 -msgid "Configuration options for the boot behavior of the virtual machine." -msgstr "仮想マシンのブート動作の設定オプション。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:434 -msgid "ftInfo (vim.vm.FaultToleranceConfigInfo, optional)" -msgstr "ftInfo (vim.vm.FaultToleranceConfigInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:436 -msgid "Fault tolerance settings for the virtual machine." -msgstr "仮想マシンのフォールトトレランス設定。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:439 -msgid "vAppConfig (vim.vApp.VmConfigInfo, optional)" -msgstr "vAppConfig (vim.vApp.VmConfigInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:441 -msgid "vApp meta-data for the virtual machine." -msgstr "仮想マシンの vApp メタデータ。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:444 -msgid "vAssertsEnabled (bool, optional)" -msgstr "vAssertsEnabled (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:446 -msgid "Indicates whether user-configured virtual asserts will be triggered during virtual machine replay." -msgstr "仮想マシンの再生中にユーザー定義の仮想アサートがトリガーされるかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:449 -msgid "changeTrackingEnabled (bool, optional)" -msgstr "changeTrackingEnabled (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:451 -msgid "Indicates whether changed block tracking for the virtual machine's disks is active." -msgstr "仮想マシンのディスクのブロック追跡がアクティブかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:454 -msgid "firmware (str, optional)" -msgstr "firmware (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:456 -msgid "Information about firmware type for the virtual machine." -msgstr "仮想マシンのファームウェアの種類に関する情報。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:459 -msgid "maxMksConnections (int, optional)" -msgstr "maxMksConnections (int, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:461 -msgid "Indicates the maximum number of active remote display connections that the virtual machine will support." -msgstr "仮想マシンがサポートするアクティブなリモートディスプレイ接続の最大数を示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:464 -msgid "guestAutoLockEnabled (bool, optional)" -msgstr "guestAutoLockEnabled (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:466 -msgid "Indicates whether the guest operating system will logout any active sessions whenever there are no remote display connections open to the virtual machine." -msgstr "仮想マシンにリモートディスプレイ接続が開かない場合に、ゲストオペレーティングシステムがアクティブなセッションをすべてログアウトするかどうかを指定します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:469 -msgid "managedBy (vim.ext.ManagedByInfo, optional)" -msgstr "managedBy (vim.ext.ManagedByInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:471 -msgid "Specifies that the virtual machine is managed by a VC Extension." -msgstr "仮想マシンが VC 拡張で管理されるように指定します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:476 -msgid "memoryReservationLockedToMax (bool, optional)" -msgstr "memoryReservationLockedToMax (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:478 -msgid "If set true, memory resource reservation for the virtual machine will always be equal to the virtual machine's memory size; increases in memory size will be rejected when a corresponding reservation increase is not possible." -msgstr "true に設定すると、仮想マシンのメモリーリソース予約は常に仮想マシンのメモリーサイズと同じになります。対応する予約が増えないと、メモリーサイズの増加は拒否されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:481 -msgid "initialOverhead (vim.vm.ConfigInfo.OverheadInfo), optional)" -msgstr "initialOverhead (vim.vm.ConfigInfo.OverheadInfo), optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:483 -msgid "Set of values to be used only to perform admission control when determining if a host has sufficient resources for the virtual machine to power on." -msgstr "ホストに仮想マシンの電源を入れるのに十分なリソースがあるかどうかを判別する際にのみ受付制御を実行するのに使用する値のセット。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:486 -msgid "nestedHVEnabled (bool, optional)" -msgstr "nestedHVEnabled (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:488 -msgid "Indicates whether the virtual machine is configured to use nested hardware-assisted virtualization." -msgstr "仮想マシンがネストされたハードウェア支援型仮想化を使用するように設定されているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:491 -msgid "vPMCEnabled (bool, optional)" -msgstr "vPMCEnabled (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:493 -msgid "Indicates whether the virtual machine have virtual CPU performance counters enabled." -msgstr "仮想マシンの仮想 CPU パフォーマンスカウンターが有効になっているかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:496 -msgid "scheduledHardwareUpgradeInfo (vim.vm.ScheduledHardwareUpgradeInfo, optional)" -msgstr "scheduledHardwareUpgradeInfo (vim.vm.ScheduledHardwareUpgradeInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:498 -msgid "Configuration of scheduled hardware upgrades and result from last attempt to run scheduled hardware upgrade." -msgstr "スケジュールされたハードウェアアップグレードの設定と、スケジュールされたハードウェアアップグレードを最後に実行したときの結果。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:501 -msgid "vFlashCacheReservation (long, optional)" -msgstr "vFlashCacheReservation (long, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:503 -msgid "Specifies the total vFlash resource reservation for the vFlash caches associated with the virtual machine's virtual disks, in bytes." -msgstr "仮想マシンの仮想ディスクに関連付けられた vFlash キャッシュの vFlash リソース予約の合計をバイト単位で指定します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:506 -msgid "layout" -msgstr "レイアウト" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:508 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:544 -msgid "Detailed information about the files that comprise the virtual machine." -msgstr "仮想マシンを構成するファイルに関する詳細情報。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:511 -msgid "configFile (str, optional)" -msgstr "configFile (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:513 -msgid "A list of files that makes up the configuration of the virtual machine (excluding the .vmx file, since that file is represented in the FileInfo). These are relative paths from the configuration directory. A slash is always used as a separator. This list will typically include the NVRAM file, but could also include other meta-data files." -msgstr "仮想マシンの設定を構成するファイルの一覧 (.vmx ファイルは FileInfo で表現されるため除く)。これらは設定ディレクトリーからの相対パスになります。スラッシュは常にセパレーターとして使用されます。この一覧には通常 NVRAM ファイルが含まれますが、他のメタデータファイルを含めることもできます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:519 -msgid "logFile (str, optional)" -msgstr "logFile (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:521 -msgid "A list of files stored in the virtual machine's log directory. These are relative paths from the ``logDirectory``. A slash is always used as a separator." -msgstr "仮想マシンのログディレクトリーに保存されているファイルの一覧。これらは ``logDirectory`` からの相対パスになります。スラッシュは常にセパレーターとして使用されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:526 -msgid "disk (vim.vm.FileLayout.DiskLayout, optional)" -msgstr "disk (vim.vm.FileLayout.DiskLayout, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:528 -msgid "Files making up each virtual disk." -msgstr "各仮想ディスクを作成するファイル。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:531 -msgid "snapshot (vim.vm.FileLayout.SnapshotLayout, optional)" -msgstr "snapshot (vim.vm.FileLayout.SnapshotLayout, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:533 -msgid "Files of each snapshot." -msgstr "各スナップショットのファイル。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:536 -msgid "swapFile (str, optional)" -msgstr "swapFile (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:538 -msgid "The swapfile specific to the virtual machine, if any. This is a complete datastore path, not a relative path." -msgstr "仮想マシンに固有のスワップファイル (存在する場合)。これは完全データストアパスであり、相対パスではありません。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:542 -msgid "layoutEx" -msgstr "layoutEx" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:547 -msgid "file (vim.vm.FileLayoutEx.FileInfo, optional)" -msgstr "file (vim.vm.FileLayoutEx.FileInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:549 -msgid "Information about all the files that constitute the virtual machine including configuration files, disks, swap file, suspend file, log files, core files, memory file and so on." -msgstr "設定ファイル、ディスク、スワップファイル、一時停止ファイル、ログファイル、コアファイル、メモリーファイルなど、仮想マシンを構成するすべてのファイルに関する情報。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:552 -msgid "disk (vim.vm.FileLayoutEx.DiskLayout, optional)" -msgstr "disk (vim.vm.FileLayoutEx.DiskLayout, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:554 -msgid "Layout of each virtual disk attached to the virtual machine. For a virtual machine with snaphots, this property gives only those disks that are attached to it at the current point of running." -msgstr "仮想マシンに接続されている各仮想ディスクのレイアウト。スナップショットを持つ仮想マシンでは、このプロパティーは、実行中の時点でアタッチされているディスクのみを提供します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:558 -msgid "snapshot (vim.vm.FileLayoutEx.SnapshotLayout, optional)" -msgstr "snapshot (vim.vm.FileLayoutEx.SnapshotLayout, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:560 -msgid "Layout of each snapshot of the virtual machine." -msgstr "仮想マシンの各スナップショットのレイアウト。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:563 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:579 -msgid "timestamp (datetime)" -msgstr "timestamp (datetime)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:565 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:581 -msgid "Time when values in this structure were last updated." -msgstr "この構造の値が最後に更新された時間。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:568 -msgid "storage (vim.vm.StorageInfo)" -msgstr "storage (vim.vm.StorageInfo)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:570 -msgid "Storage space used by the virtual machine, split by datastore." -msgstr "仮想マシンによって使用されるストレージ領域。データストアによって分割されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:573 -msgid "perDatastoreUsage (vim.vm.StorageInfo.UsageOnDatastore, optional)" -msgstr "perDatastoreUsage (vim.vm.StorageInfo.UsageOnDatastore, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:575 -msgid "Storage space used by the virtual machine on all datastores that it is located on. Total storage space committed to the virtual machine across all datastores is simply an aggregate of the property ``committed``" -msgstr "仮想マシンが配置されているすべてのデータストアで使用されているストレージ領域。すべてのデータストアで仮想マシンにコミットされている総ストレージ容量は、単純にプロパティー ``committed`` を集約したものです。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:584 -msgid "environmentBrowser (vim.EnvironmentBrowser)" -msgstr "environmentBrowser (vim.EnvironmentBrowser)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:586 -msgid "The current virtual machine's environment browser object. This contains information on all the configurations that can be used on the virtual machine. This is identical to the environment browser on the ComputeResource to which the virtual machine belongs." -msgstr "現在の仮想マシンの環境ブラウザーオブジェクト。仮想マシンで使用できるすべての設定に関する情報が含まれます。これは、仮想マシンが属する ComputeResource の環境ブラウザーと同じです。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:591 -msgid "datastoreBrowser (vim.host.DatastoreBrowser)" -msgstr "datastoreBrowser (vim.host.DatastoreBrowser)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:593 -msgid "DatastoreBrowser to browse datastores that are available on this entity." -msgstr "DatastoreBrowser は、このエンティティーで利用可能なデータストアを参照します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:596 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:618 -msgid "resourcePool (vim.ResourcePool)" -msgstr "resourcePool (vim.ResourcePool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:598 -msgid "The current resource pool that specifies resource allocation for the virtual machine. This property is set when a virtual machine is created or associated with a different resource pool. Returns null if the virtual machine is a template or the session has no access to the resource pool." -msgstr "仮想マシンのリソース割り当てを指定する現在のリソースプール。このプロパティーは、仮想マシンが作成されたか、別のリソースプールに関連付けられたときに設定されます。仮想マシンがテンプレートであるか、セッションがリソースプールにアクセスできない場合は null を返します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:603 -msgid "summary (vim.ResourcePool.Summary)" -msgstr "summary (vim.ResourcePool.Summary)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:605 -msgid "Basic information about a resource pool." -msgstr "リソースプールに関する基本情報。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:608 -msgid "runtime (vim.ResourcePool.RuntimeInfo)" -msgstr "runtime (vim.ResourcePool.RuntimeInfo)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:610 -msgid "Runtime information about a resource pool." -msgstr "リソースプールに関するランタイム情報。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:613 -msgid "owner (vim.ComputeResource)" -msgstr "owner (vim.ComputeResource)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:615 -msgid "The ComputeResource to which this set of one or more nested resource pools belong." -msgstr "1 つ以上のネストされたリソースプールのセットが属する ComputeResource。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:620 -msgid "The set of child resource pools." -msgstr "子リソースプールのセット。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:623 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1086 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1128 -msgid "vm (vim.VirtualMachine)" -msgstr "vm (vim.VirtualMachine)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:625 -msgid "The set of virtual machines associated with this resource pool." -msgstr "このリソースプールに関連付けられた仮想マシンのセット。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:628 -msgid "config (vim.ResourceConfigSpec)" -msgstr "config (vim.ResourceConfigSpec)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:630 -msgid "Configuration of this resource pool." -msgstr "このリソースプールの設定。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:633 -msgid "childConfiguration (vim.ResourceConfigSpec)" -msgstr "childConfiguration (vim.ResourceConfigSpec)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:635 -msgid "The resource configuration of all direct children (VirtualMachine and ResourcePool) of this resource group." -msgstr "このリソースグループのすべての直接の子 (VirtualMachine および ResourcePool) のリソース設定。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:638 -msgid "parentVApp (vim.ManagedEntity)" -msgstr "parentVApp (vim.ManagedEntity)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:640 -msgid "Reference to the parent vApp." -msgstr "親 vApp への参照。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:643 -msgid "parent (vim.ManagedEntity)" -msgstr "parent (vim.ManagedEntity)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:645 -msgid "Parent of this entity. This value is null for the root object and for (VirtualMachine) objects that are part of a (VirtualApp)." -msgstr "このエンティティーの親。ルートオブジェクトと、(VirtualApp) の一部である (VirtualMachine) オブジェクトの場合、この値は null です。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:649 -msgid "customValue (vim.CustomFieldsManager.Value)" -msgstr "customValue (vim.CustomFieldsManager.Value)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:651 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1062 -msgid "Custom field values." -msgstr "カスタムフィールドの値。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:654 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1055 -msgid "overallStatus (vim.ManagedEntity.Status)" -msgstr "overallStatus (vim.ManagedEntity.Status)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:656 -msgid "General health of this managed entity." -msgstr "この管理エンティティーの一般的な正常性。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:659 -msgid "configStatus (vim.ManagedEntity.Status)" -msgstr "configStatus (vim.ManagedEntity.Status)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:661 -msgid "The configStatus indicates whether or not the system has detected a configuration issue involving this entity. For example, it might have detected a duplicate IP address or MAC address, or a host in a cluster might be out of ``compliance.property``." -msgstr "configStatus は、システムがこのエンティティーに関連する設定問題を検出したかどうかを示します。たとえば、重複する IP アドレスまたは MAC アドレスを検出したり、クラスター内のホストが ``compliance.property`` 外の可能性があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:665 -msgid "configIssue (vim.event.Event)" -msgstr "configIssue (vim.event.Event)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:667 -msgid "Current configuration issues that have been detected for this entity." -msgstr "このエンティティーについて検出された現在の設定の問題。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:670 -msgid "effectiveRole (int)" -msgstr "effectiveRole (int)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:672 -msgid "Access rights the current session has to this entity." -msgstr "現在のセッションがこのエンティティーに対して設定されているアクセス権。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:675 -msgid "permission (vim.AuthorizationManager.Permission)" -msgstr "permission (vim.AuthorizationManager.Permission)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:677 -msgid "List of permissions defined for this entity." -msgstr "このエンティティーに定義されたパーミッションの一覧。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:682 -#, python-format -msgid "Name of this entity, unique relative to its parent. Any / (slash), \\ (backslash), character used in this name element will be escaped. Similarly, any % (percent) character used in this name element will be escaped, unless it is used to start an escape sequence. A slash is escaped as %2F or %2f. A backslash is escaped as %5C or %5c, and a percent is escaped as %25." -msgstr "このエンティティーの名前で、親との関係は一意です。/ (スラッシュ)、\\ (バックスラッシュ)、この名前要素で使用される文字がエスケープされます。同様に、エスケープ処理を開始するのに使用されていない限り、この名前要素で使用される % (パーセント) 文字はエスケープされます。スラッシュをエスケープする場合は %2F または %2f となり、バックスラッシュをエスケープする場合は %5C または %5c となり、パーセントをエスケープする場合は %25 となります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:688 -msgid "disabledMethod (str)" -msgstr "disabledMethod (str)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:690 -msgid "List of operations that are disabled, given the current runtime state of the entity. For example, a power-on operation always fails if a virtual machine is already powered on." -msgstr "エンティティーの現在のランタイム状態を考慮して、無効となる操作のリスト。たとえば、仮想マシンの電源が入っている場合は常に、パワーオン操作は失敗します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:694 -msgid "recentTask (vim.Task)" -msgstr "recentTask (vim.Task)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:696 -msgid "The set of recent tasks operating on this managed entity. A task in this list could be in one of the four states: pending, running, success or error." -msgstr "この管理エンティティーで動作する最近のタスクセット。このリストのタスクは、4 つの状態 (保留、実行、成功、またはエラー) のいずれかになります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:700 -msgid "declaredAlarmState (vim.alarm.AlarmState)" -msgstr "declaredAlarmState (vim.alarm.AlarmState)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:702 -msgid "A set of alarm states for alarms that apply to this managed entity." -msgstr "この管理エンティティーに適用されるアラームのアラーム状態のセット。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:705 -msgid "triggeredAlarmState (vim.alarm.AlarmState)" -msgstr "triggeredAlarmState (vim.alarm.AlarmState)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:707 -msgid "A set of alarm states for alarms triggered by this entity or by its descendants." -msgstr "このエンティティーまたはその子孫によってトリガーされるアラームのアラーム状態のセット。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:710 -msgid "alarmActionsEnabled (bool)" -msgstr "alarmActionsEnabled (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:712 -msgid "Whether alarm actions are enabled for this entity. True if enabled; false otherwise." -msgstr "このエンティティーに対してアラームアクションが有効になっているかどうか。有効な場合は True。そうでない場合は false。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:715 -msgid "tag (vim.Tag)" -msgstr "tag (vim.Tag)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:717 -msgid "The set of tags associated with this managed entity. Experimental. Subject to change." -msgstr "この管理エンティティーに関連付けられたタグのセット。実験的で、変更する可能性があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:720 -msgid "resourceConfig (vim.ResourceConfigSpec)" -msgstr "resourceConfig (vim.ResourceConfigSpec)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:722 -msgid "The resource configuration for a virtual machine." -msgstr "仮想マシンのリソース設定。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:725 -msgid "entity (vim.ManagedEntity, optional)" -msgstr "entity (vim.ManagedEntity, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:727 -msgid "Reference to the entity with this resource specification: either a VirtualMachine or a ResourcePool." -msgstr "このリソース仕様を持つエンティティーへの参照 (VirtualMachine または ResourcePool のいずれか)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:730 -msgid "changeVersion (str, optional)" -msgstr "changeVersion (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:732 -msgid "The changeVersion is a unique identifier for a given version of the configuration. Each change to the configuration will update this value. This is typically implemented as an ever increasing count or a time-stamp." -msgstr "changeVersion は、設定の特定バージョンの一意の識別子です。設定への変更はそれぞれこの値を更新します。これは通常、増加し続けるカウントやタイムスタンプとして実装されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:737 -msgid "lastModified (datetime, optional)" -msgstr "lastModified (datetime, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:739 -msgid "Timestamp when the resources were last modified. This is ignored when the object is used to update a configuration." -msgstr "リソースが最後に変更した時点のタイムスタンプ。これは、オブジェクトを使用して設定を更新する場合は無視されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:742 -msgid "cpuAllocation (vim.ResourceAllocationInfo)" -msgstr "cpuAllocation (vim.ResourceAllocationInfo)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:744 -msgid "Resource allocation for CPU." -msgstr "CPU のリソース割り当て。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:747 -msgid "memoryAllocation (vim.ResourceAllocationInfo)" -msgstr "memoryAllocation (vim.ResourceAllocationInfo)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:749 -msgid "Resource allocation for memory." -msgstr "メモリーのリソース割り当て。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:752 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1027 -msgid "runtime (vim.vm.RuntimeInfo)" -msgstr "runtime (vim.vm.RuntimeInfo)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:754 -msgid "Execution state and history for the virtual machine." -msgstr "仮想マシンの実行状態および履歴。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:757 -msgid "device (vim.vm.DeviceRuntimeInfo, optional)" -msgstr "device (vim.vm.DeviceRuntimeInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:759 -msgid "Per-device runtime info. This array will be empty if the host software does not provide runtime info for any of the device types currently in use by the virtual machine." -msgstr "デバイスごとのランタイム情報。ホストソフトウェアが、仮想マシンで現在使用されているデバイスタイプのランタイム情報を提供していない場合、この配列は空になります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:762 -msgid "host (vim.HostSystem, optional)" -msgstr "host (vim.HostSystem, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:764 -msgid "The host that is responsible for running a virtual machine. This property is null if the virtual machine is not running and is not assigned to run on a particular host." -msgstr "仮想マシンの実行を担当するホスト。このプロパティーは、仮想マシンが実行中ではなく、特定のホストで実行するように割り当てられていない場合に null になります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:768 -msgid "connectionState (vim.VirtualMachine.ConnectionState)" -msgstr "connectionState (vim.VirtualMachine.ConnectionState)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:770 -msgid "Indicates whether or not the virtual machine is available for management." -msgstr "仮想マシンが管理に使用できるかどうかを示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:773 -msgid "powerState (vim.VirtualMachine.PowerState)" -msgstr "powerState (vim.VirtualMachine.PowerState)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:775 -msgid "The current power state of the virtual machine." -msgstr "仮想マシンの現在の状態。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:778 -msgid "faultToleranceState (vim.VirtualMachine.FaultToleranceState)" -msgstr "faultToleranceState (vim.VirtualMachine.FaultToleranceState)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:780 -msgid "The fault tolerance state of the virtual machine." -msgstr "仮想マシンのフォールトトレランス状態。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:783 -msgid "dasVmProtection (vim.vm.RuntimeInfo.DasProtectionState, optional)" -msgstr "dasVmProtection (vim.vm.RuntimeInfo.DasProtectionState, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:785 -msgid "The vSphere HA protection state for a virtual machine. Property is unset if vSphere HA is not enabled." -msgstr "仮想マシンの vSphere HA 保護の状態。vSphere HA が有効になっていないと、プロパティーは設定されません。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:789 -msgid "toolsInstallerMounted (bool)" -msgstr "toolsInstallerMounted (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:791 -msgid "Flag to indicate whether or not the VMware Tools installer is mounted as a CD-ROM." -msgstr "VMware Tool インストーラーが CD-ROM としてマウントされているかどうかを示すフラグ。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:794 -msgid "suspendTime (datetime, optional)" -msgstr "suspendTime (datetime, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:796 -msgid "The timestamp when the virtual machine was most recently suspended. This property is updated every time the virtual machine is suspended." -msgstr "仮想マシンが最近一時停止された時点のタイムスタンプ。このプロパティーは、仮想マシンが一時停止されるたびに更新されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:800 -msgid "bootTime (datetime, optional)" -msgstr "bootTime (datetime, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:802 -msgid "The timestamp when the virtual machine was most recently powered on. This property is updated when the virtual machine is powered on from the poweredOff state, and is cleared when the virtual machine is powered off. This property is not updated when a virtual machine is resumed from a suspended state." -msgstr "仮想マシンの電源が最後に入った時のタイムスタンプです。このプロパティーは、仮想マシンが、poweredOff 状態から電源がオンになると更新し、仮想マシンの電源がオフになる削除されます。このプロパティーは、仮想マシンが一時停止状態から再開したときには更新されません。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:807 -msgid "suspendInterval (long, optional)" -msgstr "suspendInterval (long, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:809 -msgid "The total time the virtual machine has been suspended since it was initially powered on. This time excludes the current period, if the virtual machine is currently suspended. This property is updated when the virtual machine resumes, and is reset to zero when the virtual machine is powered off." -msgstr "仮想マシンの電源が最初に入ってから一時停止状態になっていた合計時間。この時間により、仮想マシンが現在一時停止になっている場合は、現在の期間が除外されます。このプロパティーは仮想マシンが再開したときに更新され、仮想マシンの電源オフ時にゼロにリセットされます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:814 -msgid "question (vim.vm.QuestionInfo, optional)" -msgstr "question (vim.vm.QuestionInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:816 -msgid "The current question, if any, that is blocking the virtual machine's execution." -msgstr "仮想マシンの実行をブロックする現在の質問 (ある場合)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:819 -msgid "memoryOverhead (long, optional)" -msgstr "memoryOverhead (long, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:821 -msgid "The amount of memory resource (in bytes) that will be used by the virtual machine above its guest memory requirements. This value is set if and only if the virtual machine is registered on a host that supports memory resource allocation features. For powered off VMs, this is the minimum overhead required to power on the VM on the registered host. For powered on VMs, this is the current overhead reservation, a value which is almost always larger than the minimum overhead, and which grows with time." -msgstr "仮想マシンがゲストのメモリー要件を超えて使用するメモリーリソースの量 (バイト数) です。この値は、仮想マシンがメモリーリソースの割り当て機能に対応するホストに登録されている場合にのみ設定されます。仮想マシンの電源が切れている場合、これは登録されているホストの仮想マシンの電源を入れるために必要な最小のオーバーヘッドです。仮想マシンの電源が入っている場合、これは現在のオーバーヘッドの予約値で、ほとんどの場合、最小オーバーヘッドよりも大きく、時間とともに増加します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:827 -msgid "maxCpuUsage (int, optional)" -msgstr "maxCpuUsage (int, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:829 -msgid "Current upper-bound on CPU usage. The upper-bound is based on the host the virtual machine is current running on, as well as limits configured on the virtual machine itself or any parent resource pool. Valid while the virtual machine is running." -msgstr "CPU 使用率の現在の上限。上限は、仮想マシンが現在実行しているホストに基づき、仮想マシン自体または親リソースプールに設定された制限に基づいています。仮想マシンが実行中の間有効です。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:834 -msgid "maxMemoryUsage (int, optional)" -msgstr "maxMemoryUsage (int, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:836 -msgid "Current upper-bound on memory usage. The upper-bound is based on memory configuration of the virtual machine, as well as limits configured on the virtual machine itself or any parent resource pool. Valid while the virtual machine is running." -msgstr "メモリー使用量の現在の上限。上限は仮想マシンのメモリー設定と、仮想マシン自体または親リソースプールに設定された制限に基づいています。仮想マシンが実行中の間は有効です。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:841 -msgid "numMksConnections (int)" -msgstr "numMksConnections (int)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:843 -msgid "Number of active MKS connections to the virtual machine." -msgstr "仮想マシンへのアクティブな MKS 接続の数。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:846 -msgid "recordReplayState (vim.VirtualMachine.RecordReplayState)" -msgstr "recordReplayState (vim.VirtualMachine.RecordReplayState)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:848 -msgid "Record / replay state of the virtual machine." -msgstr "仮想マシンの状態の記録/再生。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:851 -msgid "cleanPowerOff (bool, optional)" -msgstr "cleanPowerOff (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:853 -msgid "For a powered off virtual machine, indicates whether the virtual machine's last shutdown was an orderly power off or not. Unset if the virtual machine is running or suspended." -msgstr "仮想マシンの電源がオフの場合、仮想マシンの最後のシャットダウンが順序通り行われたかどうかを示します。仮想マシンが実行中か、サスペンドされていた場合は設定されません。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:857 -msgid "needSecondaryReason (str, optional)" -msgstr "needSecondaryReason (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:859 -msgid "If set, indicates the reason the virtual machine needs a secondary." -msgstr "設定されていると、仮想マシンがセカンダリーを必要とする理由を示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:862 -msgid "onlineStandby (bool)" -msgstr "onlineStandby (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:864 -msgid "This property indicates whether the guest has gone into one of the s1, s2 or s3 standby modes. False indicates the guest is awake." -msgstr "このプロパティーは、ゲストが s1、s2、または s3 のスタンバイモードのいずれかに切り替わったかどうかを示します。False は、ゲストが稼働していることを示しています。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:867 -msgid "minRequiredEVCModeKey (str, optional)" -msgstr "minRequiredEVCModeKey (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:869 -msgid "For a powered-on or suspended virtual machine in a cluster with Enhanced VMotion Compatibility (EVC) enabled, this identifies the least-featured EVC mode (among those for the appropriate CPU vendor) that could admit the virtual machine. This property will be unset if the virtual machine is powered off or is not in an EVC cluster. This property may be used as a general indicator of the CPU feature baseline currently in use by the virtual machine. However, the virtual machine may be suppressing some of the features present in the CPU feature baseline of the indicated mode, either explicitly (in the virtual machine's configured ``cpuFeatureMask``) or implicitly (in the default masks for the ``GuestOsDescriptor`` appropriate for the virtual machine's configured guest OS)." -msgstr "EVC (Enhanced VMotion Compatibility) が有効になっているクラスターで仮想マシンの電源が入っている、または一時停止している場合、これは仮想マシンを許可する可能性がある最小機能の EVC モード (適切な CPU ベンダー用) を特定します。仮想マシンの電源がオフの場合、または EVC クラスターにない場合は、このプロパティーの設定を解除します。このプロパティーは、仮想マシンが現在使用している CPU 機能ベースラインの一般的なインジケーターとして使用できます。ただし、仮想マシンは、明示的 (仮想マシンの設定済み ``cpuFeatureMask``) または暗黙的 (仮想マシンの設定済みゲスト OS に適切な ``GuestOsDescriptor`` のデフォルトマスク) に指定したモードの CPU 機能ベースラインに存在する機能の一部を抑制している可能性があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:875 -msgid "consolidationNeeded (bool)" -msgstr "consolidationNeeded (bool)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:877 -msgid "Whether any disk of the virtual machine requires consolidation. This can happen for example when a snapshot is deleted but its associated disk is not committed back to the base disk." -msgstr "仮想マシンのディスクが統合する必要があるかどうか。これは、スナップショットが削除されても、関連付けられたディスクがベースディスクにコミットされない場合などに発生する可能性があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:881 -msgid "offlineFeatureRequirement (vim.vm.FeatureRequirement, optional)" -msgstr "offlineFeatureRequirement (vim.vm.FeatureRequirement, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:883 -msgid "These requirements must have equivalent host capabilities ``featureCapability`` in order to power on." -msgstr "これらの要件には、電源を入れるのに同等のホスト機能 ``featureCapability`` が必要です。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:886 -msgid "featureRequirement (vim.vm.FeatureRequirement, optional)" -msgstr "featureRequirement (vim.vm.FeatureRequirement, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:888 -msgid "These requirements must have equivalent host capabilities ``featureCapability`` in order to power on, resume, or migrate to the host." -msgstr "ホストの電源オン、再開、または移行を行うには、これらの要件に同等のホスト機能 ``featureCapability`` が必要です。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:891 -msgid "featureMask (vim.host.FeatureMask, optional)" -msgstr "featureMask (vim.host.FeatureMask, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:893 -msgid "The masks applied to an individual virtual machine as a result of its configuration." -msgstr "設定の結果として、個々の仮想マシンに適用されるマスク。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:896 -msgid "vFlashCacheAllocation (long, optional)" -msgstr "vFlashCacheAllocation (long, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:898 -msgid "Specifies the total allocated vFlash resource for the vFlash caches associated with VM's VMDKs when VM is powered on, in bytes." -msgstr "仮想マシンの電源が入ったときに、仮想マシンの VMDK に関連付けられた vFlash キャッシュに割り当てられる vFlash リソースの合計をバイト単位で指定します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:902 -msgid "guest (vim.vm.GuestInfo)" -msgstr "guest (vim.vm.GuestInfo)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:904 -msgid "Information about VMware Tools and about the virtual machine from the perspective of VMware Tools. Information about the guest operating system is available in VirtualCenter. Guest operating system information reflects the last known state of the virtual machine. For powered on machines, this is current information. For powered off machines, this is the last recorded state before the virtual machine was powered off." -msgstr "VMware Tool に関する情報、および VMware Tool ツールから見た仮想マシンに関する情報。ゲストオペレーティングシステムに関する情報は、VirtualCenter で利用できます。ゲストオペレーティングシステムの情報には、仮想マシンの最後の既知の状態を反映します。マシンの電源が入っていると、これは現在の情報になります。マシンの電源が切れていると、仮想マシンの電源が切れる前に最後に記録された状態になります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:911 -msgid "toolsStatus (vim.vm.GuestInfo.ToolsStatus, optional)" -msgstr "toolsStatus (vim.vm.GuestInfo.ToolsStatus, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:913 -msgid "Current status of VMware Tools in the guest operating system, if known." -msgstr "ゲストオペレーティングシステムの VMware Tool の現在の状態 (判明している場合)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:916 -msgid "toolsVersionStatus (str, optional)" -msgstr "toolsVersionStatus (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:918 -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:923 -msgid "Current version status of VMware Tools in the guest operating system, if known." -msgstr "ゲストオペレーティングシステムの VMware ツールの現在のバージョンステータス (判明している場合)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:921 -msgid "toolsVersionStatus2 (str, optional)" -msgstr "toolsVersionStatus2 (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:926 -msgid "toolsRunningStatus (str, optional)" -msgstr "toolsRunningStatus (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:928 -msgid "Current running status of VMware Tools in the guest operating system, if known." -msgstr "ゲストオペレーティングシステムの VMware ツールの現在の実行ステータス (判明している場合)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:931 -msgid "toolsVersion (str, optional)" -msgstr "toolsVersion (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:933 -msgid "Current version of VMware Tools, if known." -msgstr "VMware ツールの現行バージョン (判明している場合)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:936 -msgid "guestId (str, optional)" -msgstr "guestId (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:938 -msgid "Guest operating system identifier (short name), if known." -msgstr "既知の場合は、ゲストオペレーティングシステム識別子 (短縮名)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:941 -msgid "guestFamily (str, optional)" -msgstr "guestFamily (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:943 -msgid "Guest operating system family, if known." -msgstr "ゲストオペレーティングシステムファミリー (判明している場合)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:946 -msgid "guestFullName (str, optional)" -msgstr "guestFullName (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:948 -msgid "See :ref:`guest_full_name`." -msgstr "「:ref:`guest_full_name`」を参照してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:951 -msgid "hostName (str, optional)" -msgstr "hostName (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:953 -msgid "Hostname of the guest operating system, if known." -msgstr "ゲストオペレーティングシステムのホスト名 (判明している場合)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:956 -msgid "ipAddress (str, optional)" -msgstr "ipAddress (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:958 -msgid "Primary IP address assigned to the guest operating system, if known." -msgstr "ゲストオペレーティングシステムに割り当てられるプライマリー IP アドレス (判明している場合)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:961 -msgid "net (vim.vm.GuestInfo.NicInfo, optional)" -msgstr "net (vim.vm.GuestInfo.NicInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:963 -msgid "Guest information about network adapters, if known." -msgstr "ネットワークアダプターに関するゲスト情報 (判明している場合)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:966 -msgid "ipStack (vim.vm.GuestInfo.StackInfo, optional)" -msgstr "ipStack (vim.vm.GuestInfo.StackInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:968 -msgid "Guest information about IP networking stack, if known." -msgstr "IP ネットワークスタックに関するゲスト情報 (判明している場合)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:971 -msgid "disk (vim.vm.GuestInfo.DiskInfo, optional)" -msgstr "disk (vim.vm.GuestInfo.DiskInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:973 -msgid "Guest information about disks. You can obtain Linux guest disk information for the following file system types only: Ext2, Ext3, Ext4, ReiserFS, ZFS, NTFS, VFAT, UFS, PCFS, HFS, and MS-DOS." -msgstr "ディスクに関するゲスト情報。次のファイルシステムタイプの Linux ゲストディスク情報を取得できます (Ext2、Ext3、Ext4、ReiserFS、ZFS、NTFS、VFAT、UFS、PCFS、HFS、および MS-DOS)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:977 -msgid "screen (vim.vm.GuestInfo.ScreenInfo, optional)" -msgstr "screen (vim.vm.GuestInfo.ScreenInfo, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:979 -msgid "Guest screen resolution info, if known." -msgstr "ゲスト画面の解像度情報 (判明している場合)。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:982 -msgid "guestState (str)" -msgstr "guestState (str)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:984 -msgid "Operation mode of guest operating system." -msgstr "ゲストオペレーティングシステムの操作モード。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:987 -msgid "appHeartbeatStatus (str, optional)" -msgstr "appHeartbeatStatus (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:989 -msgid "Application heartbeat status." -msgstr "アプリケーションのハートビート状態。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:992 -msgid "appState (str, optional)" -msgstr "appState (str, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:994 -msgid "Application state. If vSphere HA is enabled and the vm is configured for Application Monitoring and this field's value is ``appStateNeedReset`` then HA will attempt immediately reset the virtual machine. There are some system conditions which may delay the immediate reset. The immediate reset will be performed as soon as allowed by vSphere HA and ESX. If during these conditions the value is changed to ``appStateOk`` the reset will be cancelled." -msgstr "アプリケーションの状態。vSphere HA が有効で、仮想マシンがアプリケーション監視用に設定されていて、およびこのフィールドの値が ``appStateNeedReset`` の場合、HA は仮想マシンの即時リセットを試みます。システムの状態によっては、即時リセットが遅れる場合があります。即時リセットは、vSphere HA と ESX で許可されるとすぐに、即時リセットが実行されます。これらの条件で値が ``appStateOk`` に変更になると、リセットが取り消されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1001 -msgid "guestOperationsReady (bool, optional)" -msgstr "guestOperationsReady (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1003 -msgid "Guest Operations availability. If true, the vitrual machine is ready to process guest operations." -msgstr "ゲスト操作の可用性。true の場合は、ゲスト操作を処理する準備が整います。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1006 -msgid "interactiveGuestOperationsReady (bool, optional)" -msgstr "interactiveGuestOperationsReady (bool, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1008 -msgid "Interactive Guest Operations availability. If true, the virtual machine is ready to process guest operations as the user interacting with the guest desktop." -msgstr "インタラクティブなゲスト操作の可用性。true の場合は、ゲストデスクトップと対話するユーザーがゲスト操作を処理する準備が整います。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1011 -msgid "generationInfo (vim.vm.GuestInfo.NamespaceGenerationInfo, privilege: VirtualMachine.Namespace.EventNotify, optional)" -msgstr "generationInfo (vim.vm.GuestInfo.NamespaceGenerationInfo, privilege: VirtualMachine.Namespace.EventNotify, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1013 -msgid "A list of namespaces and their corresponding generation numbers. Only namespaces with non-zero ``maxSizeEventsFromGuest`` are guaranteed to be present here." -msgstr "名前空間の一覧とそれに対応する生成番号。ゼロ以外の ``maxSizeEventsFromGuest`` の名前空間のみがここに存在することが保証されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1017 -msgid "summary (vim.vm.Summary)" -msgstr "summary (vim.vm.Summary)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1019 -msgid "Basic information about the virtual machine." -msgstr "仮想マシンに関する基本情報。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1022 -msgid "vm (vim.VirtualMachine, optional)" -msgstr "vm (vim.VirtualMachine, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1024 -msgid "Reference to the virtual machine managed object." -msgstr "仮想マシン管理オブジェクトへの参照。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1029 -msgid "Runtime and state information of a running virtual machine. Most of this information is also available when a virtual machine is powered off. In that case, it contains information from the last run, if available." -msgstr "実行中の仮想マシンのランタイムおよび状態の情報。この情報のほとんどは、仮想マシンの電源が切れたときにも利用できます。その場合は、最後の実行からの情報 (利用可能な場合) が含まれます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1034 -msgid "guest (vim.vm.Summary.GuestSummary, optional)" -msgstr "guest (vim.vm.Summary.GuestSummary, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1036 -msgid "Guest operating system and VMware Tools information." -msgstr "ゲストオペレーティングシステムおよび VMware Tool の情報。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1039 -msgid "config (vim.vm.Summary.ConfigSummary)" -msgstr "config (vim.vm.Summary.ConfigSummary)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1041 -msgid "Basic configuration information about the virtual machine. This information is not available when the virtual machine is unavailable, for instance, when it is being created or deleted." -msgstr "仮想マシンの基本的な設定情報です。この情報は、仮想マシンの作成時や削除時など、仮想マシンが利用できないときには利用できません。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1045 -msgid "storage (vim.vm.Summary.StorageSummary, optional)" -msgstr "storage (vim.vm.Summary.StorageSummary, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1047 -msgid "Storage information of the virtual machine." -msgstr "仮想マシンのストレージ情報。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1050 -msgid "quickStats (vim.vm.Summary.QuickStats)" -msgstr "quickStats (vim.vm.Summary.QuickStats)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1052 -msgid "A set of statistics that are typically updated with near real-time regularity." -msgstr "通常、ほぼリアルタイム正規表現で更新される統計セット。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1057 -msgid "Overall alarm status on this node." -msgstr "このノードの全体的なアラーム状態。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1060 -msgid "customValue (vim.CustomFieldsManager.Value, optional)" -msgstr "customValue (vim.CustomFieldsManager.Value, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1066 -msgid "datastore (vim.Datastore)" -msgstr "datastore (vim.Datastore)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1068 -msgid "A collection of references to the subset of datastore objects in the datacenter that is used by the virtual machine." -msgstr "仮想マシンが使用するデータセンターのデータストアオブジェクトのサブセットへの参照のコレクション。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1071 -msgid "info (vim.Datastore.Info)" -msgstr "info (vim.Datastore.Info)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1073 -msgid "Specific information about the datastore." -msgstr "データストアに関する具体的な情報。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1076 -msgid "summary (vim.Datastore.Summary)" -msgstr "summary (vim.Datastore.Summary)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1078 -msgid "Global properties of the datastore." -msgstr "データストアのグローバルプロパティー。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1081 -msgid "host (vim.Datastore.HostMount)" -msgstr "host (vim.Datastore.HostMount)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1083 -msgid "Hosts attached to this datastore." -msgstr "このデータストアに接続されたホスト。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1088 -msgid "Virtual machines stored on this datastore." -msgstr "このデータストアに保存されている仮想マシン。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1091 -msgid "browser (vim.host.DatastoreBrowser)" -msgstr "browser (vim.host.DatastoreBrowser)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1093 -msgid "DatastoreBrowser used to browse this datastore." -msgstr "このデータストアの閲覧に使用する DatastoreBrowser。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1096 -msgid "capability (vim.Datastore.Capability)" -msgstr "capability (vim.Datastore.Capability)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1098 -msgid "Capabilities of this datastore." -msgstr "このデータストアの機能。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1101 -msgid "iormConfiguration (vim.StorageResourceManager.IORMConfigInfo)" -msgstr "iormConfiguration (vim.StorageResourceManager.IORMConfigInfo)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1103 -msgid "Configuration of storage I/O resource management for the datastore. Currently VMware only support storage I/O resource management on VMFS volumes of a datastore. This configuration may not be available if the datastore is not accessible from any host, or if the datastore does not have VMFS volume." -msgstr "データストアのストレージ I/O リソース管理の設定。現在、VMware は、データストアの VMFS ボリュームでのストレージ I/O リソース管理のみをサポートします。この設定は、データストアがいずれかのホストからアクセスできない場合や、データストアに VMFS ボリュームがない場合には利用できません。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1108 -msgid "network (vim.Network)" -msgstr "network (vim.Network)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1110 -msgid "A collection of references to the subset of network objects in the datacenter that is used by the virtual machine." -msgstr "仮想マシンが使用するデータセンター内のネットワークオブジェクトのサブセットへの参照のコレクション。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1115 -msgid "Name of this network." -msgstr "このネットワークの名前。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1118 -msgid "summary (vim.Network.Summary)" -msgstr "summary (vim.Network.Summary)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1120 -msgid "Properties of a network." -msgstr "ネットワークのプロパティー。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1123 -msgid "host (vim.HostSystem)" -msgstr "host (vim.HostSystem)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1125 -msgid "Hosts attached to this network." -msgstr "このネットワークに接続されたホスト。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1130 -msgid "Virtual machines using this network." -msgstr "このネットワークを使用する仮想マシン。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1134 -msgid "snapshot (vim.vm.SnapshotInfo)" -msgstr "snapshot (vim.vm.SnapshotInfo)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1136 -msgid "Current snapshot and tree. The property is valid if snapshots have been created for the virtual machine." -msgstr "現在のスナップショットおよびツリー。このプロパティーは、仮想マシン用にスナップショットが作成された場合に有効です。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1140 -msgid "currentSnapshot (vim.vm.Snapshot, optional)" -msgstr "currentSnapshot (vim.vm.Snapshot, optional)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1142 -msgid "Current snapshot of the virtual machineThis property is set by calling ``Snapshot.revert`` or ``VirtualMachine.createSnapshot``. This property will be empty when the working snapshot is at the root of the snapshot tree." -msgstr "仮想マシンの現在のスナップショット。このプロパティーは、``Snapshot.revert`` または ``VirtualMachine.createSnapshot`` を呼び出すことで設定されます。このプロパティーは、作業スナップショットがスナップショットツリーのルートにあると空になります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1146 -msgid "rootSnapshotList (vim.vm.SnapshotTree)" -msgstr "rootSnapshotList (vim.vm.SnapshotTree)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1148 -msgid "Data for the entire set of snapshots for one virtual machine." -msgstr "1 台の仮想マシンのスナップショットの全セットのデータ。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1151 -msgid "rootSnapshot (vim.vm.Snapshot)" -msgstr "rootSnapshot (vim.vm.Snapshot)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1153 -msgid "The roots of all snapshot trees for the virtual machine." -msgstr "仮想マシンのすべてのスナップショットツリーのルート。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1156 -msgid "config (vim.vm.ConfigInfo)" -msgstr "config (vim.vm.ConfigInfo)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1158 -msgid "Information about the configuration of the virtual machine when this snapshot was taken. The datastore paths for the virtual machine disks point to the head of the disk chain that represents the disk at this given snapshot." -msgstr "このスナップショットが取られた時点の仮想マシンの設定に関する情報。仮想マシンディスクのデータストアパスは、この指定したスナップショットのディスクを表すディスクチェーンのヘッドを参照します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1162 -msgid "childSnapshot (vim.vm.Snapshot)" -msgstr "childSnapshot (vim.vm.Snapshot)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1164 -msgid "All snapshots for which this snapshot is the parent." -msgstr "このスナップショットが親であるすべてのスナップショット。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1167 -msgid "guestHeartbeatStatus (vim.ManagedEntity.Status)" -msgstr "guestHeartbeatStatus (vim.ManagedEntity.Status)" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1169 -msgid "The guest heartbeat." -msgstr "ゲストのハートビート。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_inventory_vm_attributes.rst:1177 -msgid "rst/scenario_guides/guide_vmware.rst" -msgstr "rst/scenario_guides/guide_vmware.rst" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_module_reference.rst:7 -msgid "Ansible VMware Module Guide" -msgstr "Ansible VMware モジュールガイド" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_module_reference.rst:9 -msgid "This will be a listing similar to the module index in our core docs." -msgstr "ここでは、コアドキュメントのモジュールインデックスと同様のリストを紹介します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:5 -msgid "VMware Prerequisites" -msgstr "VMware の要件" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:11 -msgid "Installing SSL Certificates" -msgstr "SSL 証明書のインストール" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:13 -msgid "All vCenter and ESXi servers require SSL encryption on all connections to enforce secure communication. You must enable SSL encryption for Ansible by installing the server's SSL certificates on your Ansible control node or delegate node." -msgstr "すべての vCenter サーバーおよび ESXi サーバーでは、安全な通信を実現するために、すべての接続に SSL 暗号化が必要です。サーバーの SSL 証明書を Ansible コントロールノードまたは委譲ノードにインストールして、Ansible の SSL 暗号化を有効にする必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:15 -msgid "If the SSL certificate of your vCenter or ESXi server is not correctly installed on your Ansible control node, you will see the following warning when using Ansible VMware modules:" -msgstr "vCenter サーバーまたは ESXi サーバーの SSL 証明書が Ansible コントロールノードに正しくインストールされていない場合は、Ansible VMware モジュールを使用する際に以下の警告が表示されます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:17 -msgid "``Unable to connect to vCenter or ESXi API at xx.xx.xx.xx on TCP/443: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:777)``" -msgstr "``Unable to connect to vCenter or ESXi API at xx.xx.xx.xx on TCP/443: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:777)``" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:19 -msgid "To install the SSL certificate for your VMware server, and run your Ansible VMware modules in encrypted mode, please follow the instructions for the server you are running with VMware." -msgstr "VMware サーバーに SSL 証明書をインストールし、Ansible VMware モジュールを暗号化モードで実行するには、VMware で実行しているサーバーの手順に従ってください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:22 -msgid "Installing vCenter SSL certificates for Ansible" -msgstr "Ansible 用の vCenter SSL 証明書のインストール" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:24 -msgid "From any web browser, go to the base URL of the vCenter Server without port number like ``https://vcenter-domain.example.com``" -msgstr "任意の Web ブラウザーから、``https://vcenter-domain.example.com`` などポート番号のない vCenter Server のベース URL に移動します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:26 -msgid "Click the \"Download trusted root CA certificates\" link at the bottom of the grey box on the right and download the file." -msgstr "右側の灰色の領域の下部にある「Download trusted root CA certificates (信頼されたルート CA 証明書のダウンロード)」のリンクをクリックして、ファイルをダウンロードします。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:28 -msgid "Change the extension of the file to .zip. The file is a ZIP file of all root certificates and all CRLs." -msgstr "ファイルの拡張子を .zip に変更します。このファイルは、すべてのルート証明書とすべての CRL が含まれる ZIP ファイルです。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:30 -msgid "Extract the contents of the zip file. The extracted directory contains a ``.certs`` directory that contains two types of files. Files with a number as the extension (.0, .1, and so on) are root certificates." -msgstr "zip ファイルの内容を展開します。展開したディレクトリーには、両タイプのファイルが含まれる ``.certs`` ディレクトリーが含まれます。数字が拡張子 (.0、.1 など) になっているファイルは、ルート証明書です。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:32 -msgid "Install the certificate files are trusted certificates by the process that is appropriate for your operating system." -msgstr "証明書ファイルを、オペレーティングシステムに適したプロセスで信頼されている証明書にインストールします。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:36 -msgid "Installing ESXi SSL certificates for Ansible" -msgstr "Ansible 用の ESXi SSL 証明書のインストール" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:38 -msgid "Enable SSH Service on ESXi either by using Ansible VMware module `vmware_host_service_manager `_ or manually using vSphere Web interface." -msgstr "Ansible VMware モジュール `vmware_host_service_manager `_ を使用するか、vSphere Web インターフェースを手動で使用して、ESXi で SSH サービスを有効にします。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:40 -msgid "SSH to ESXi server using administrative credentials, and navigate to directory ``/etc/vmware/ssl``" -msgstr "管理認証情報を使用して ESXi サーバーに SSH 接続し、``/etc/vmware/ssl`` ディレクトリーに移動します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:42 -msgid "Secure copy (SCP) ``rui.crt`` located in ``/etc/vmware/ssl`` directory to Ansible control node." -msgstr "``/etc/vmware/ssl`` ディレクトリーにある SCP (Secure Copy) ``rui.crt`` を Ansible コントロールノードへ置きます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:44 -msgid "Install the certificate file by the process that is appropriate for your operating system." -msgstr "オペレーティングシステムに適したプロセスで、証明書ファイルをインストールします。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:47 -msgid "Using custom path for SSL certificates" -msgstr "SSL 証明書のカスタムパスの使用" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:49 -msgid "If you need to use a custom path for SSL certificates, you can set the ``REQUESTS_CA_BUNDLE`` environment variable in your playbook." -msgstr "SSL 証明書にカスタムパスを使用しないといけない場合は、Playbook に ``REQUESTS_CA_BUNDLE`` 環境変数を設定することができます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_requirements.rst:51 -msgid "For example, if ``/var/vmware/certs/vcenter1.crt`` is the SSL certificate for your vCenter Server, you can use the :ref:`environment ` keyword to pass it to the modules:" -msgstr "たとえば、``/var/vmware/certs/vcenter1.crt`` が vCenter Server の SSL 証明書である場合は、:ref:`environment ` キーワードを使用してモジュールに渡すことができます。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_scenarios.rst:5 -msgid "Ansible for VMware Scenarios" -msgstr "VMware シナリオにおける Ansible" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_scenarios.rst:7 -msgid "These scenarios teach you how to accomplish common VMware tasks using Ansible. To get started, please select the task you want to accomplish." -msgstr "以下のシナリオでは、Ansible を使用して一般的な VMware タスクを実行する方法を説明します。最初に、実行するタスクを選択してください。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:5 -msgid "Troubleshooting Ansible for VMware" -msgstr "Ansible for VMware のトラブルシューティング" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:10 -msgid "This section lists things that can go wrong and possible ways to fix them." -msgstr "本セクションでは、問題が発生する可能性があるものと、その修正方法を紹介します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:13 -msgid "Debugging Ansible for VMware" -msgstr "Ansible for VMware のデバッグ" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:15 -msgid "When debugging or creating a new issue, you will need information about your VMware infrastructure. You can get this information using `govc `_, For example:" -msgstr "新しい問題をデバッグまたは作成する場合は、VMware インフラストラクチャーに関する情報が必要になります。この情報は、`govc `_ を使用して取得できます。以下に例を示します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:27 -msgid "Known issues with Ansible for VMware" -msgstr "Ansible for VMware に関する既知の問題" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:31 -msgid "Network settings with vmware_guest in Ubuntu 18.04" -msgstr "Ubuntu 18.04 で vmware_guest を使用したネットワーク設定" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:33 -msgid "Setting the network with ``vmware_guest`` in Ubuntu 18.04 is known to be broken, due to missing support for ``netplan`` in the ``open-vm-tools``. This issue is tracked via:" -msgstr "``open-vm-tools`` に ``netplan`` のサポートがないため、Ubuntu 18.04 で ``vmware_guest`` を使用してネットワークを設定すると破損することが知られています。これは以下の問題で追跡されています。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:36 -msgid "https://github.com/vmware/open-vm-tools/issues/240" -msgstr "https://github.com/vmware/open-vm-tools/issues/240" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:37 -msgid "https://github.com/ansible/ansible/issues/41133" -msgstr "https://github.com/ansible/ansible/issues/41133" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:40 -msgid "Potential Workarounds" -msgstr "潜在的な回避策" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:42 -msgid "There are several workarounds for this issue." -msgstr "この問題には、複数の回避策があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:44 -msgid "Modify the Ubuntu 18.04 images and installing ``ifupdown`` in them via ``sudo apt install ifupdown``. If so you need to remove ``netplan`` via ``sudo apt remove netplan.io`` and you need stop ``systemd-networkd`` via ``sudo systemctl disable systemctl-networkd``." -msgstr "Ubuntu 18.04 イメージを変更し、``sudo apt install ifupdown`` で ``ifupdown`` をインストールします。この場合、``sudo apt remove netplan.io`` から ``netplan`` を削除して、``sudo systemctl disable systemctl-networkd`` で ``systemd-networkd`` を停止する必要があります。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:47 -msgid "Generate the ``systemd-networkd`` files with a task in your VMware Ansible role:" -msgstr "VMware Ansible ロールでタスクを使用して ``systemd-networkd`` ファイルを生成します。" - -#: ../../rst/scenario_guides/vmware_scenarios/vmware_troubleshooting.rst:103 -msgid "Wait for ``netplan`` support in ``open-vm-tools``" -msgstr "``open-vm-tools`` で ``netplan`` がサポートされるのを待ちます。" - -#~ msgid "To use an Azure Cloud other than the default public cloud (eg, Azure China Cloud, Azure US Government Cloud, Azure Stack), pass the \"cloud_environment\" argument to modules, configure it in a credential profile, or set the \"AZURE_CLOUD_ENVIRONMENT\" environment variable. The value is either a cloud name as defined by the Azure Python SDK (eg, \"AzureChinaCloud\", \"AzureUSGovernment\"; defaults to \"AzureCloud\") or an Azure metadata discovery URL (for Azure Stack)." -#~ msgstr "" - -#~ msgid "An Azure module is available to help you create a storage account, virtual network, subnet, network interface, security group and public IP. Here is a full example of creating each of these and passing the names to the azure_rm_virtualmachine module at the end:" -#~ msgstr "" - -#~ msgid "When creating a VM with the ``azure_rm_virtualmachine`` module, you need to explicitly set the ``managed_disk_type`` parameter to change the OS disk to a managed disk. Otherwise, the OS disk becomes an unmanaged disk.." -#~ msgstr "" - -#~ msgid "When you create a data disk with the ``azure_rm_manageddisk`` module, you need to explicitly specify the ``storage_account_type`` parameter to make it a managed disk. Otherwise, the data disk will be an unmanaged disk." -#~ msgstr "" - -#~ msgid "A managed disk does not require a storage account or a storage container, unlike a n unmanaged disk. In particular, note that once a VM is created on an unmanaged disk, an unnecessary storage container named \"vhds\" is automatically created." -#~ msgstr "" - -#~ msgid "When you create an IP address with the ``azure_rm_publicipaddress`` module, you must set the ``sku`` parameter to ``standard``. Otherwise, the IP address cannot be used in an availability zone." -#~ msgstr "" - -#~ msgid "cs also includes a command line interface for ad-hoc interaction with the CloudStack API, for example ``$ cs listVirtualMachines state=Running``." -#~ msgstr "" - -#~ msgid "Ansible offers the following modules for orchestrating Docker containers:" -#~ msgstr "" - -#~ msgid "docker_compose" -#~ msgstr "" - -#~ msgid "Use your existing Docker compose files to orchestrate containers on a single Docker daemon or on Swarm. Supports compose versions 1 and 2." -#~ msgstr "" - -#~ msgid "docker_container" -#~ msgstr "" - -#~ msgid "Manages the container lifecycle by providing the ability to create, update, stop, start and destroy a container." -#~ msgstr "" - -#~ msgid "docker_image" -#~ msgstr "" - -#~ msgid "Provides full control over images, including: build, pull, push, tag and remove." -#~ msgstr "" - -#~ msgid "docker_image_info" -#~ msgstr "" - -#~ msgid "Inspects one or more images in the Docker host's image cache, providing the information for making decision or assertions in a playbook." -#~ msgstr "" - -#~ msgid "docker_login" -#~ msgstr "" - -#~ msgid "Authenticates with Docker Hub or any Docker registry and updates the Docker Engine config file, which in turn provides password-free pushing and pulling of images to and from the registry." -#~ msgstr "" - -#~ msgid "docker (dynamic inventory)" -#~ msgstr "" - -#~ msgid "Dynamically builds an inventory of all the available containers from a set of one or more Docker hosts." -#~ msgstr "" - -#~ msgid "Ansible 2.1.0 includes major updates to the Docker modules, marking the start of a project to create a complete and integrated set of tools for orchestrating containers. In addition to the above modules, we are also working on the following:" -#~ msgstr "" - -#~ msgid "There's more planned. See the latest ideas and thinking at the `Ansible proposal repo `_." -#~ msgstr "" - -#~ msgid "Using the docker modules requires having the `Docker SDK for Python `_ installed on the host running Ansible. You will need to have >= 1.7.0 installed. For Python 2.7 or Python 3, you can install it as follows:" -#~ msgstr "" - -#~ msgid "Please note that only one of ``docker`` and ``docker-py`` must be installed. Installing both will result in a broken installation. If this happens, Ansible will detect it and inform you about it::" -#~ msgstr "" - -#~ msgid "The docker_compose module also requires `docker-compose `_" -#~ msgstr "" - -#~ msgid "You can connect to a local or remote API using parameters passed to each task or by setting environment variables. The order of precedence is command line parameters and then environment variables. If neither a command line option or an environment variable is found, a default value will be used. The default values are provided under `Parameters`_" -#~ msgstr "" - -#~ msgid "Control how modules connect to the Docker API by passing the following parameters:" -#~ msgstr "" - -#~ msgid "The URL or Unix socket path used to connect to the Docker API. Defaults to ``unix://var/run/docker.sock``. To connect to a remote host, provide the TCP connection string. For example: ``tcp://192.0.2.23:2376``. If TLS is used to encrypt the connection to the API, then the module will automatically replace 'tcp' in the connection URL with 'https'." -#~ msgstr "" - -#~ msgid "Secure the connection to the API by using TLS without verifying the authenticity of the Docker host server. Defaults to False." -#~ msgstr "" - -#~ msgid "tls_verify" -#~ msgstr "" - -#~ msgid "Secure the connection to the API by using TLS and verifying the authenticity of the Docker host server. Default is False." -#~ msgstr "" - -#~ msgid "When verifying the authenticity of the Docker Host server, provide the expected name of the server. Defaults to 'localhost'." -#~ msgstr "" - -#~ msgid "Provide a valid SSL version number. Default value determined by docker-py, which at the time of this writing was 1.0" -#~ msgstr "" - -#~ msgid "Control how the modules connect to the Docker API by setting the following variables in the environment of the host running Ansible:" -#~ msgstr "" - -#~ msgid "The inventory script generates dynamic inventory by making API requests to one or more Docker APIs. It's dynamic because the inventory is generated at run-time rather than being read from a static file. The script generates the inventory by connecting to one or many Docker APIs and inspecting the containers it finds at each API. Which APIs the script contacts can be defined using environment variables or a configuration file." -#~ msgstr "" - -#~ msgid "Groups" -#~ msgstr "" - -#~ msgid "The script will create the following host groups:" -#~ msgstr "" - -#~ msgid "container id" -#~ msgstr "" - -#~ msgid "container name" -#~ msgstr "" - -#~ msgid "container short id" -#~ msgstr "" - -#~ msgid "image_name (image_)" -#~ msgstr "" - -#~ msgid "running" -#~ msgstr "" - -#~ msgid "stopped" -#~ msgstr "" - -#~ msgid "You can run the script interactively from the command line or pass it as the inventory to a playbook. Here are few examples to get you started:" -#~ msgstr "" - -#~ msgid "You can control the behavior of the inventory script by defining environment variables, or creating a docker.yml file (sample provided in https://raw.githubusercontent.com/ansible-collections/community.general/main/scripts/inventory/docker.py). The order of precedence is the docker.yml file and then environment variables." -#~ msgstr "" - -#~ msgid "To connect to a single Docker API the following variables can be defined in the environment to control the connection options. These are the same environment variables used by the Docker modules." -#~ msgstr "" - -#~ msgid "The URL or Unix socket path used to connect to the Docker API. Defaults to unix://var/run/docker.sock." -#~ msgstr "" - -#~ msgid "DOCKER_API_VERSION:" -#~ msgstr "" - -#~ msgid "DOCKER_TIMEOUT:" -#~ msgstr "" - -#~ msgid "DOCKER_TLS:" -#~ msgstr "" - -#~ msgid "DOCKER_TLS_VERIFY:" -#~ msgstr "" - -#~ msgid "Secure the connection to the API by using TLS and verifying the authenticity of the Docker host server. Default is False" -#~ msgstr "" - -#~ msgid "DOCKER_TLS_HOSTNAME:" -#~ msgstr "" - -#~ msgid "When verifying the authenticity of the Docker Host server, provide the expected name of the server. Defaults to localhost." -#~ msgstr "" - -#~ msgid "DOCKER_CERT_PATH:" -#~ msgstr "" - -#~ msgid "DOCKER_SSL_VERSION:" -#~ msgstr "" - -#~ msgid "In addition to the connection variables there are a couple variables used to control the execution and output of the script:" -#~ msgstr "" - -#~ msgid "DOCKER_CONFIG_FILE" -#~ msgstr "" - -#~ msgid "Path to the configuration file. Defaults to ./docker.yml." -#~ msgstr "" - -#~ msgid "DOCKER_PRIVATE_SSH_PORT:" -#~ msgstr "" - -#~ msgid "The private port (container port) on which SSH is listening for connections. Defaults to 22." -#~ msgstr "" - -#~ msgid "DOCKER_DEFAULT_IP:" -#~ msgstr "" - -#~ msgid "The IP address to assign to ansible_host when the container's SSH port is mapped to interface '0.0.0.0'." -#~ msgstr "" - -#~ msgid "Configuration File" -#~ msgstr "" - -#~ msgid "Using a configuration file provides a means for defining a set of Docker APIs from which to build an inventory." -#~ msgstr "" - -#~ msgid "The default name of the file is derived from the name of the inventory script. By default the script will look for basename of the script (in other words, docker) with an extension of '.yml'." -#~ msgstr "" - -#~ msgid "You can also override the default name of the script by defining DOCKER_CONFIG_FILE in the environment." -#~ msgstr "" - -#~ msgid "Here's what you can define in docker_inventory.yml:" -#~ msgstr "" - -#~ msgid "defaults" -#~ msgstr "" - -#~ msgid "Defines a default connection. Defaults will be taken from this and applied to any values not provided for a host defined in the hosts list." -#~ msgstr "" - -#~ msgid "hosts" -#~ msgstr "" - -#~ msgid "If you wish to get inventory from more than one Docker host, define a hosts list." -#~ msgstr "" - -#~ msgid "For the default host and each host in the hosts list define the following attributes:" -#~ msgstr "" - -#~ msgid "Here is a basic example of provisioning an instance in ad-hoc mode:" -#~ msgstr "" - diff --git a/docs/docsite/rst/module_plugin_guide/index.rst b/docs/docsite/rst/module_plugin_guide/index.rst deleted file mode 100644 index 6f914d0e70d..00000000000 --- a/docs/docsite/rst/module_plugin_guide/index.rst +++ /dev/null @@ -1,30 +0,0 @@ -.. _modules_plugins_index: - -################################# -Using Ansible modules and plugins -################################# - -.. 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 `_. - -Welcome to the Ansible guide for working with modules, plugins, and collections. - -Ansible modules are units of code that can control system resources or execute system commands. -Ansible provides a module library that you can execute directly on remote hosts or through playbooks. -You can also write custom modules. - -Similar to modules are plugins, which are pieces of code that extend core Ansible functionality. -Ansible uses a plugin architecture to enable a rich, flexible, and expandable feature set. -Ansible ships with several plugins and lets you easily use your own plugins. - -.. toctree:: - :maxdepth: 2 - - modules_intro - modules_support - plugin_filtering_config - ../plugins/plugins - modules_plugins_index \ No newline at end of file diff --git a/docs/docsite/rst/module_plugin_guide/modules_intro.rst b/docs/docsite/rst/module_plugin_guide/modules_intro.rst deleted file mode 100644 index 5af9e147335..00000000000 --- a/docs/docsite/rst/module_plugin_guide/modules_intro.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _intro_modules: - -Introduction to modules -======================= - -Modules (also referred to as "task plugins" or "library plugins") are discrete units of code that can be used from the command line or in a playbook task. Ansible executes each module, usually on the remote managed node, and collects return values. In Ansible 2.10 and later, most modules are hosted in collections. - -You can execute modules from the command line. - -.. code-block:: shell-session - - ansible webservers -m service -a "name=httpd state=started" - ansible webservers -m ping - ansible webservers -m command -a "/sbin/reboot -t now" - -Each module supports taking arguments. Nearly all modules take ``key=value`` arguments, space delimited. Some modules take no arguments, and the command/shell modules simply take the string of the command you want to run. - -From playbooks, Ansible modules are executed in a very similar way. - -.. code-block:: yaml - - - name: reboot the servers - command: /sbin/reboot -t now - -Another way to pass arguments to a module is using YAML syntax, also called 'complex args'. - -.. code-block:: yaml - - - name: restart webserver - service: - name: httpd - state: restarted - -All modules return JSON format data. This means modules can be written in any programming language. Modules should be idempotent, and should avoid making any changes if they detect that the current state matches the desired final state. When used in an Ansible playbook, modules can trigger 'change events' in the form of notifying :ref:`handlers ` to run additional tasks. - -You can access the documentation for each module from the command line with the ansible-doc tool. - -.. code-block:: shell-session - - ansible-doc yum - -For a list of all available modules, see the :ref:`Collection docs `, or run the following at a command prompt. - -.. code-block:: shell-session - - ansible-doc -l - - -.. seealso:: - - :ref:`intro_adhoc` - Examples of using modules in /usr/bin/ansible - :ref:`working_with_playbooks` - Examples of using modules with /usr/bin/ansible-playbook - :ref:`developing_modules` - How to write your own modules - :ref:`developing_api` - Examples of using modules with the Python API - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels - :ref:`all_modules_and_plugins` - All modules and plugins available - diff --git a/docs/docsite/rst/module_plugin_guide/modules_plugins_index.rst b/docs/docsite/rst/module_plugin_guide/modules_plugins_index.rst deleted file mode 100644 index 4b7f5503237..00000000000 --- a/docs/docsite/rst/module_plugin_guide/modules_plugins_index.rst +++ /dev/null @@ -1,6 +0,0 @@ -.. _index_modules_plugins: - -Modules and plugins index -========================= - -You can find an index of modules and plugins at :ref:`all_modules_and_plugins`. \ No newline at end of file diff --git a/docs/docsite/rst/module_plugin_guide/modules_support.rst b/docs/docsite/rst/module_plugin_guide/modules_support.rst deleted file mode 100644 index 566ae438834..00000000000 --- a/docs/docsite/rst/module_plugin_guide/modules_support.rst +++ /dev/null @@ -1,70 +0,0 @@ -.. _modules_support: - -****************************** -Module maintenance and support -****************************** - -If you are using a module and you discover a bug, you may want to know where to report that bug, who is responsible for fixing it, and how you can track changes to the module. If you are a Red Hat subscriber, you may want to know whether you can get support for the issue you are facing. - -Starting in Ansible 2.10, most modules live in collections. The distribution method for each collection reflects the maintenance and support for the modules in that collection. - -.. contents:: - :local: - -Maintenance -=========== - -.. table:: - :class: documentation-table - - ============================= ========================================== ========================== - Collection Code location Maintained by - ============================= ========================================== ========================== - ansible.builtin `ansible/ansible repo`_ on GitHub core team - - distributed on Galaxy various; follow ``repo`` link community or partners - - distributed on Automation Hub various; follow ``repo`` link content team or partners - ============================= ========================================== ========================== - -.. _ansible/ansible repo: https://github.com/ansible/ansible/tree/devel/lib/ansible/modules - -Issue Reporting -=============== - -If you find a bug that affects a plugin in the main Ansible repo, also known as ``ansible-core``: - - #. Confirm that you are running the latest stable version of Ansible or the devel branch. - #. Look at the `issue tracker in the Ansible repo `_ to see if an issue has already been filed. - #. Create an issue if one does not already exist. Include as much detail as you can about the behavior you discovered. - -If you find a bug that affects a plugin in a Galaxy collection: - - #. Find the collection on Galaxy. - #. Find the issue tracker for the collection. - #. Look there to see if an issue has already been filed. - #. Create an issue if one does not already exist. Include as much detail as you can about the behavior you discovered. - -Some partner collections may be hosted in private repositories. - -If you are not sure whether the behavior you see is a bug, if you have questions, if you want to discuss development-oriented topics, or if you just want to get in touch, use one of our Google mailing lists or chat channels (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) to :ref:`communicate with Ansiblers `. - -If you find a bug that affects a module in an Automation Hub collection: - - #. If the collection offers an Issue Tracker link on Automation Hub, click there and open an issue on the collection repository. If it does not, follow the standard process for reporting issues on the `Red Hat Customer Portal `_. You must have a subscription to the Red Hat Ansible Automation Platform to create an issue on the portal. - -Support -======= - -All plugins that remain in ``ansible-core`` and all collections hosted in Automation Hub are supported by Red Hat. No other plugins or collections are supported by Red Hat. If you have a subscription to the Red Hat Ansible Automation Platform, you can find more information and resources on the `Red Hat Customer Portal. `_ - -.. seealso:: - - :ref:`intro_adhoc` - Examples of using modules in /usr/bin/ansible - :ref:`working_with_playbooks` - Examples of using modules with /usr/bin/ansible-playbook - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/module_plugin_guide/plugin_filtering_config.rst b/docs/docsite/rst/module_plugin_guide/plugin_filtering_config.rst deleted file mode 100644 index 28f7d48794b..00000000000 --- a/docs/docsite/rst/module_plugin_guide/plugin_filtering_config.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _plugin_filtering_config: - -Rejecting modules -================= - -If you want to avoid using certain modules, you can add them to a reject list to prevent Ansible from loading them. To reject plugins, create a yaml configuration file. The default location for this file is :file:`/etc/ansible/plugin_filters.yml`. You can select a different path for the reject list using the :ref:`PLUGIN_FILTERS_CFG` setting in the ``defaults`` section of your ansible.cfg. Here is an example reject list: - -.. code-block:: YAML - - --- - filter_version: '1.0' - module_rejectlist: - # Deprecated - - docker - # We only allow pip, not easy_install - - easy_install - -The file contains two fields: - - * A file version so that you can update the format while keeping backwards compatibility in the future. The present version should be the string, ``"1.0"`` - - * A list of modules to reject. Ansible will not load any module in this list when it searches for a module to invoke for a task. - -.. note:: - - The ``stat`` module is required for Ansible to run. Do not add this module to your reject list. diff --git a/docs/docsite/rst/network/dev_guide/developing_plugins_network.rst b/docs/docsite/rst/network/dev_guide/developing_plugins_network.rst deleted file mode 100644 index b550c280ff6..00000000000 --- a/docs/docsite/rst/network/dev_guide/developing_plugins_network.rst +++ /dev/null @@ -1,265 +0,0 @@ - -.. _developing_modules_network: -.. _developing_plugins_network: - -************************** -Developing network plugins -************************** - -You can extend the existing network modules with custom plugins in your collection. - -.. contents:: - :local: - -Network connection plugins -========================== -Each network connection plugin has a set of its own plugins which provide a specification of the -connection for a particular set of devices. The specific plugin used is selected at runtime based -on the value of the ``ansible_network_os`` variable assigned to the host. This variable should be -set to the same value as the name of the plugin to be loaded. Thus, ``ansible_network_os=nxos`` -will try to load a plugin in a file named ``nxos.py``, so it is important to name the plugin in a -way that will be sensible to users. - -Public methods of these plugins may be called from a module or module_utils with the connection -proxy object just as other connection methods can. The following is a very simple example of using -such a call in a module_utils file so it may be shared with other modules. - -.. code-block:: python - - from ansible.module_utils.connection import Connection - - def get_config(module): - # module is your AnsibleModule instance. - connection = Connection(module._socket_path) - - # You can now call any method (that doesn't start with '_') of the connection - # plugin or its platform-specific plugin - return connection.get_config() - -.. contents:: - :local: - -.. _developing_plugins_httpapi: - -Developing httpapi plugins -========================== - -:ref:`httpapi plugins ` serve as adapters for various HTTP(S) APIs for use with the ``httpapi`` connection plugin. They should implement a minimal set of convenience methods tailored to the API you are attempting to use. - -Specifically, there are a few methods that the ``httpapi`` connection plugin expects to exist. - -Making requests ---------------- - -The ``httpapi`` connection plugin has a ``send()`` method, but an httpapi plugin needs a ``send_request(self, data, **message_kwargs)`` method as a higher-level wrapper to ``send()``. This method should prepare requests by adding fixed values like common headers or URL root paths. This method may do more complex work such as turning data into formatted payloads, or determining which path or method to request. It may then also unpack responses to be more easily consumed by the caller. - -.. code-block:: python - - from ansible.module_utils.six.moves.urllib.error import HTTPError - - def send_request(self, data, path, method='POST'): - # Fixed headers for requests - headers = {'Content-Type': 'application/json'} - try: - response, response_content = self.connection.send(path, data, method=method, headers=headers) - except HTTPError as exc: - return exc.code, exc.read() - - # handle_response (defined separately) will take the format returned by the device - # and transform it into something more suitable for use by modules. - # This may be JSON text to Python dictionaries, for example. - return handle_response(response_content) - -Authenticating --------------- - -By default, all requests will authenticate with HTTP Basic authentication. If a request can return some kind of token to stand in place of HTTP Basic, the ``update_auth(self, response, response_text)`` method should be implemented to inspect responses for such tokens. If the token is meant to be included with the headers of each request, it is sufficient to return a dictionary which will be merged with the computed headers for each request. The default implementation of this method does exactly this for cookies. If the token is used in another way, say in a query string, you should instead save that token to an instance variable, where the ``send_request()`` method (above) can add it to each request - -.. code-block:: python - - def update_auth(self, response, response_text): - cookie = response.info().get('Set-Cookie') - if cookie: - return {'Cookie': cookie} - - return None - -If instead an explicit login endpoint needs to be requested to receive an authentication token, the ``login(self, username, password)`` method can be implemented to call that endpoint. If implemented, this method will be called once before requesting any other resources of the server. By default, it will also be attempted once when a HTTP 401 is returned from a request. - -.. code-block:: python - - def login(self, username, password): - login_path = '/my/login/path' - data = {'user': username, 'password': password} - - response = self.send_request(data, path=login_path) - try: - # This is still sent as an HTTP header, so we can set our connection's _auth - # variable manually. If the token is returned to the device in another way, - # you will have to keep track of it another way and make sure that it is sent - # with the rest of the request from send_request() - self.connection._auth = {'X-api-token': response['token']} - except KeyError: - raise AnsibleAuthenticationFailure(message="Failed to acquire login token.") - -Similarly, ``logout(self)`` can be implemented to call an endpoint to invalidate and/or release the current token, if such an endpoint exists. This will be automatically called when the connection is closed (and, by extension, when reset). - -.. code-block:: python - - def logout(self): - logout_path = '/my/logout/path' - self.send_request(None, path=logout_path) - - # Clean up tokens - self.connection._auth = None - -Error handling --------------- - -The ``handle_httperror(self, exception)`` method can deal with status codes returned by the server. The return value indicates how the plugin will continue with the request: - -* A value of ``true`` means that the request can be retried. This my be used to indicate a transient error, or one that has been resolved. For example, the default implementation will try to call ``login()`` when presented with a 401, and return ``true`` if successful. - -* A value of ``false`` means that the plugin is unable to recover from this response. The status code will be raised as an exception to the calling module. - -* Any other value will be taken as a nonfatal response from the request. This may be useful if the server returns error messages in the body of the response. Returning the original exception is usually sufficient in this case, as HTTPError objects have the same interface as a successful response. - -For example httpapi plugins, see the `source code for the httpapi plugins `_ included with Ansible Core. - - - -Developing NETCONF plugins -========================== - -The :ref:`netconf ` connection plugin provides a connection to remote devices over the ``SSH NETCONF`` subsystem. Network devices typically use this connection plugin to send and receive ``RPC`` calls over ``NETCONF``. - -The ``netconf`` connection plugin uses the ``ncclient`` Python library under the hood to initiate a NETCONF session with a NETCONF-enabled remote network device. ``ncclient`` also executes NETCONF RPC requests and receives responses. You must install the ``ncclient`` on the local Ansible controller. - -To use the ``netconf`` connection plugin for network devices that support standard NETCONF (:RFC:`6241`) operations such as ``get``, ``get-config``, ``edit-config``, set ``ansible_network_os=default``. -You can use :ref:`netconf_get `, :ref:`netconf_config ` and :ref:`netconf_rpc ` modules to talk to a NETCONF enabled remote host. - -As a contributor and user, you should be able to use all the methods under the ``NetconfBase`` class if your device supports standard NETCONF. You can contribute a new plugin if the device you are working with has a vendor specific NETCONF RPC. -To support a vendor specific NETCONF RPC, add the implementation in the network OS specific NETCONF plugin. - -For Junos for example: - -* See the vendor-specific Junos RPC methods implemented in ``plugins/netconf/junos.py``. -* Set the value of ``ansible_network_os`` to the name of the netconf plugin file, that is ``junos`` in this case. - -.. _developing_plugins_network_cli: - -Developing network_cli plugins -============================== - -The :ref:`network_cli ` connection type uses ``paramiko_ssh`` under the hood which creates a pseudo terminal to send commands and receive responses. -``network_cli`` loads two platform specific plugins based on the value of ``ansible_network_os``: - -* Terminal plugin (for example ``plugins/terminal/ios.py``) - Controls the parameters related to terminal, such as setting terminal length and width, page disabling and privilege escalation. Also defines regex to identify the command prompt and error prompts. - -* :ref:`cliconf_plugins` (for example, :ref:`ios cliconf `) - Provides an abstraction layer for low level send and receive operations. For example, the ``edit_config()`` method ensures that the prompt is in ``config`` mode before executing configuration commands. - -To contribute a new network operating system to work with the ``network_cli`` connection, implement the ``cliconf`` and ``terminal`` plugins for that network OS. - -The plugins can reside in: - -* Adjacent to playbook in folders - - .. code-block:: bash - - cliconf_plugins/ - terminal_plugins/ - -* Roles - - .. code-block:: bash - - myrole/cliconf_plugins/ - myrole/terminal_plugins/ - -* Collections - - .. code-block:: bash - - myorg/mycollection/plugins/terminal/ - myorg/mycollection/plugins/cliconf/ - -The user can also set the :ref:`DEFAULT_CLICONF_PLUGIN_PATH` to configure the ``cliconf`` plugin path. - -After adding the ``cliconf`` and ``terminal`` plugins in the expected locations, users can: - -* Use the :ref:`cli_command ` to run an arbitrary command on the network device. -* Use the :ref:`cli_config ` to implement configuration changes on the remote hosts without platform-specific modules. - - -.. _develop_cli_parse_plugins: - -Developing cli_parser plugins in a collection -=============================================== - -You can use ``cli_parse`` as an entry point for a cli_parser plugin in -your own collection. - -The following sample shows the start of a custom cli_parser plugin: - -.. code-block:: python - - from ansible_collections.ansible.netcommon.plugins.module_utils.cli_parser.cli_parserbase import ( - CliParserBase, - ) - - class CliParser(CliParserBase): - """ Sample cli_parser plugin - """ - - # Use the follow extension when loading a template - DEFAULT_TEMPLATE_EXTENSION = "txt" - # Provide the contents of the template to the parse function - PROVIDE_TEMPLATE_CONTENTS = True - - def myparser(text, template_contents): - # parse the text using the template contents - return {...} - - def parse(self, *_args, **kwargs): - """ Standard entry point for a cli_parse parse execution - - :return: Errors or parsed text as structured data - :rtype: dict - - :example: - - The parse function of a parser should return a dict: - {"errors": [a list of errors]} - or - {"parsed": obj} - """ - template_contents = kwargs["template_contents"] - text = self._task_args.get("text") - try: - parsed = myparser(text, template_contents) - except Exception as exc: - msg = "Custom parser returned an error while parsing. Error: {err}" - return {"errors": [msg.format(err=to_native(exc))]} - return {"parsed": parsed} - -The following task uses this custom cli_parser plugin: - -.. code-block:: yaml - - - name: Use a custom cli_parser - ansible.netcommon.cli_parse: - command: ls -l - parser: - name: my_organiztion.my_collection.custom_parser - -To develop a custom plugin: -- Each cli_parser plugin requires a ``CliParser`` class. -- Each cli_parser plugin requires a ``parse`` function. -- Always return a dictionary with ``errors`` or ``parsed``. -- Place the custom cli_parser in plugins/cli_parsers directory of the collection. -- See the `current cli_parsers `_ for examples to follow. - - -.. seealso:: - - * :ref:`cli_parsing` diff --git a/docs/docsite/rst/network/dev_guide/developing_resource_modules_network.rst b/docs/docsite/rst/network/dev_guide/developing_resource_modules_network.rst deleted file mode 100644 index eefedb67f15..00000000000 --- a/docs/docsite/rst/network/dev_guide/developing_resource_modules_network.rst +++ /dev/null @@ -1,826 +0,0 @@ - -.. _developing_resource_modules: - -*********************************** -Developing network resource modules -*********************************** - -.. contents:: - :local: - :depth: 2 - -Understanding network and security resource modules -=================================================== - -Network and security devices separate configuration into sections (such as interfaces, VLANs, and so on) that apply to a network or security service. Ansible resource modules take advantage of this to allow users to configure subsections or resources within the device configuration. Resource modules provide a consistent experience across different network and security devices. For example, a network resource module may only update the configuration for a specific portion of the network interfaces, VLANs, ACLs, and so on for a network device. The resource module: - -#. Fetches a piece of the configuration (fact gathering), for example, the interfaces configuration. -#. Converts the returned configuration into key-value pairs. -#. Places those key-value pairs into an internal independent structured data format. - -Now that the configuration data is normalized, the user can update and modify the data and then use the resource module to send the configuration data back to the device. This results in a full round-trip configuration update without the need for manual parsing, data manipulation, and data model management. - -The resource module has two top-level keys - ``config`` and ``state``: - -* ``config`` defines the resource configuration data model as key-value pairs. The type of the ``config`` option can be ``dict`` or ``list of dict`` based on the resource managed. That is, if the device has a single global configuration, it should be a ``dict`` (for example, a global LLDP configuration). If the device has multiple instances of configuration, it should be of type ``list`` with each element in the list of type ``dict`` (for example, interfaces configuration). - - -* ``state`` defines the action the resource module takes on the end device. - -The ``state`` for a new resource module should support the following values (as applicable for the devices that support them): - -merged - Ansible merges the on-device configuration with the provided configuration in the task. - -replaced - Ansible replaces the on-device configuration subsection with the provided configuration subsection in the task. - -overridden - Ansible overrides the on-device configuration for the resource with the provided configuration in the task. Use caution with this state as you could remove your access to the device (for example, by overriding the management interface configuration). - -deleted - Ansible deletes the on-device configuration subsection and restores any default settings. - -gathered - Ansible displays the resource details gathered from the network device and accessed with the ``gathered`` key in the result. - -rendered - Ansible renders the provided configuration in the task in the device-native format (for example, Cisco IOS CLI). Ansible returns this rendered configuration in the ``rendered`` key in the result. Note this state does not communicate with the network device and can be used offline. - -parsed - Ansible parses the configuration from the ``running_configuration`` option into Ansible structured data in the ``parsed`` key in the result. Note this does not gather the configuration from the network device so this state can be used offline. - - -Modules in Ansible-maintained collections must support these state values. If you develop a module with only "present" and "absent" for state, you may submit it to a community collection. - -.. note:: - - The states ``rendered``, ``gathered``, and ``parsed`` do not perform any change on the device. - -.. seealso:: - - `Deep Dive on VLANs Resource Modules for Network Automation `_ - Walkthrough of how state values are implemented for VLANs. - - -Developing network and security resource modules -================================================= - -The Ansible Engineering team ensures the module design and code pattern within Ansible-maintained collections is uniform across resources and across platforms to give a vendor-independent feel and deliver good quality code. We recommend you use the `resource module builder `_ to develop a resource module. - - -The highlevel process for developing a resource module is: - -#. Create and share a resource model design in the `resource module models repository `_ as a PR for review. -#. Download the latest version of the `resource module builder `_. -#. Run the ``resource module builder`` to create a collection scaffold from your approved resource model. -#. Write the code to implement your resource module. -#. Develop integration and unit tests to verify your resource module. -#. Create a PR to the appropriate collection that you want to add your new resource module to. See :ref:`contributing_maintained_collections` for details on determining the correct collection for your module. - - -Understanding the model and resource module builder ------------------------------------------------------ - -The resource module builder is an Ansible Playbook that helps developers scaffold and maintain an Ansible resource module. It uses a model as the single source of truth for the module. This model is a ``yaml`` file that is used for the module DOCUMENTATION section and the argument spec. - -The resource module builder has the following capabilities: - -- Uses a defined model to scaffold a resource module directory layout and initial class files. -- Scaffolds either an Ansible role or a collection. -- Subsequent uses of the resource module builder will only replace the module arspec and file containing the module docstring. -- Allows you to store complex examples along side the model in the same directory. -- Maintains the model as the source of truth for the module and use resource module builder to update the source files as needed. -- Generates working sample modules for both ``_`` and ``_facts``. - -Accessing the resource module builder -------------------------------------- - -To access the resource module builder: - -1. clone the github repository: - - .. code-block:: bash - - git clone https://github.com/ansible-network/resource_module_builder.git - -2. Install the requirements: - - .. code-block:: bash - - pip install -r requirements.txt - -Creating a model ------------------ - -You must create a model for your new resource. The model is the single source of truth for both the argspec and docstring, keeping them in sync. Once your model is approved, you can use the resource module builder to generate three items based on the model: - -* The scaffold for a new module -* The argspec for the new module -* The docstring for the new module - -For any subsequent changes to the functionality, update the model first and use the resource module builder to update the module argspec and docstring. - -For example, the resource model builder includes the ``myos_interfaces.yml`` sample in the :file:`models` directory, as seen below: - -.. code-block:: yaml - - --- - GENERATOR_VERSION: '1.0' - - NETWORK_OS: myos - RESOURCE: interfaces - COPYRIGHT: Copyright 2019 Red Hat - LICENSE: gpl-3.0.txt - - DOCUMENTATION: | - module: myos_interfaces - version_added: 1.0.0 - short_description: 'Manages attributes of ' - description: 'Manages attributes of .' - author: Ansible Network Engineer - notes: - - 'Tested against ' - options: - config: - description: The provided configuration - type: list - elements: dict - suboptions: - name: - type: str - description: The name of the - some_string: - type: str - description: - - The some_string_01 - choices: - - choice_a - - choice_b - - choice_c - default: choice_a - some_bool: - description: - - The some_bool. - type: bool - some_int: - description: - - The some_int. - type: int - version_added: '1.1.0' - some_dict: - type: dict - description: - - The some_dict. - suboptions: - property_01: - description: - - The property_01 - type: str - state: - description: - - The state of the configuration after module completion. - type: str - choices: - - merged - - replaced - - overridden - - deleted - default: merged - EXAMPLES: - - deleted_example_01.txt - - merged_example_01.txt - - overridden_example_01.txt - - replaced_example_01.txt - -Notice that you should include examples for each of the states that the resource supports. The resource module builder also includes these in the sample model. - -Share this model as a PR for review at `resource module models repository `_. You can also see more model examples at that location. - - -Creating a collection scaffold from a resource model ----------------------------------------------------- - -To use the resource module builder to create a collection scaffold from your approved resource model: - -.. code-block:: bash - - ansible-playbook -e rm_dest= \ - -e structure=collection \ - -e collection_org= \ - -e collection_name= \ - -e model= \ - site.yml - -Where the parameters are as follows: - -- ``rm_dest``: The directory where the resource module builder places the files and directories for the resource module and facts modules. -- ``structure``: The directory layout type (role or collection) - - - ``role``: Generate a role directory layout. - - ``collection``: Generate a collection directory layout. - -- ``collection_org``: The organization of the collection, required when `structure=collection`. -- ``collection_name``: The name of the collection, required when `structure=collection`. -- ``model``: The path to the model file. - -To use the resource module builder to create a role scaffold: - -.. code-block:: bash - - ansible-playbook -e rm_dest= \ - -e structure=role \ - -e model= \ - site.yml - -Examples -======== - -Collection directory layout ---------------------------- - -This example shows the directory layout for the following: - -- ``network_os``: myos -- ``resource``: interfaces - -.. code-block:: bash - - ansible-playbook -e rm_dest=~/github/rm_example \ - -e structure=collection \ - -e collection_org=cidrblock \ - -e collection_name=my_collection \ - -e model=models/myos/interfaces/myos_interfaces.yml \ - site.yml - -.. code-block:: text - - ├── docs - ├── LICENSE.txt - ├── playbooks - ├── plugins - | ├── action - | ├── filter - | ├── inventory - | ├── modules - | | ├── __init__.py - | | ├── myos_facts.py - | | └── myos_interfaces.py - | └── module_utils - | ├── __init__.py - | └── network - | ├── __init__.py - | └── myos - | ├── argspec - | | ├── facts - | | | ├── facts.py - | | | └── __init__.py - | | ├── __init__.py - | | └── interfaces - | | ├── __init__.py - | | └── interfaces.py - | ├── config - | | ├── __init__.py - | | └── interfaces - | | ├── __init__.py - | | └── interfaces.py - | ├── facts - | | ├── facts.py - | | ├── __init__.py - | | └── interfaces - | | ├── __init__.py - | | └── interfaces.py - | ├── __init__.py - | └── utils - | ├── __init__.py - | └── utils.py - ├── README.md - └── roles - - -Role directory layout ---------------------- - -This example displays the role directory layout for the following: - -- ``network_os``: myos -- ``resource``: interfaces - -.. code-block:: bash - - ansible-playbook -e rm_dest=~/github/rm_example/roles/my_role \ - -e structure=role \ - -e model=models/myos/interfaces/myos_interfaces.yml \ - site.yml - - -.. code-block:: text - - roles - └── my_role - ├── library - │ ├── __init__.py - │ ├── myos_facts.py - │ └── myos_interfaces.py - ├── LICENSE.txt - ├── module_utils - │ ├── __init__.py - │ └── network - │ ├── __init__.py - │ └── myos - │ ├── argspec - │ │ ├── facts - │ │ │ ├── facts.py - │ │ │ └── __init__.py - │ │ ├── __init__.py - │ │ └── interfaces - │ │ ├── __init__.py - │ │ └── interfaces.py - │ ├── config - │ │ ├── __init__.py - │ │ └── interfaces - │ │ ├── __init__.py - │ │ └── interfaces.py - │ ├── facts - │ │ ├── facts.py - │ │ ├── __init__.py - │ │ └── interfaces - │ │ ├── __init__.py - │ │ └── interfaces.py - │ ├── __init__.py - │ └── utils - │ ├── __init__.py - │ └── utils.py - └── README.md - - -Using the collection --------------------- - -This example shows how to use the generated collection in a playbook: - - .. code-block:: yaml - - ---- - - hosts: myos101 - gather_facts: False - tasks: - - cidrblock.my_collection.myos_interfaces: - register: result - - debug: - var: result - - cidrblock.my_collection.myos_facts: - - debug: - var: ansible_network_resources - - -Using the role --------------- - -This example shows how to use the generated role in a playbook: - -.. code-block:: yaml - - - hosts: myos101 - gather_facts: False - roles: - - my_role - - - hosts: myos101 - gather_facts: False - tasks: - - myos_interfaces: - register: result - - debug: - var: result - - myos_facts: - - debug: - var: ansible_network_resources - - -Resource module structure and workflow -====================================== - -The resource module structure includes the following components: - -Module - * ``library/_.py``. - * Imports the ``module_utils`` resource package and calls ``execute_module`` API: - - .. code-block:: text - - def main(): - result = (module).execute_module() - -Module argspec - * ``module_utils//argspec//``. - * Argspec for the resource. - -Facts - * ``module_utils//facts//``. - * Populate facts for the resource. - * Entry in ``module_utils//facts/facts.py`` for ``get_facts`` API to keep ``_facts`` module and facts gathered for the resource module in sync for every subset. - * Entry of Resource subset in FACTS_RESOURCE_SUBSETS list in ``module_utils//facts/facts.py`` to make facts collection work. - -Module package in module_utils - * ``module_utils////``. - * Implement ``execute_module`` API that loads the configuration to device and generates the result with ``changed``, ``commands``, ``before`` and ``after`` keys. - * Call ``get_facts`` API that returns the ```` configuration facts or return the difference if the device has onbox diff support. - * Compare facts gathered and given key-values if diff is not supported. - * Generate final configuration. - -Utils - * ``module_utils//utils``. - * Utilities for the ```` platform. - -.. _tox_resource_modules: - -Running ``ansible-test sanity`` and ``tox`` on resource modules -================================================================ - -You should run ``ansible-test sanity`` and ``tox -elinters`` from the collection root directory before pushing your PR to an Ansible-maintained collection. The CI runs both and will fail if these tests fail. See :ref:`developing_testing` for details on ``ansible-test sanity``. - -To install the necessary packages: - -#. Ensure you have a valid Ansible development environment configured. See :ref:`environment_setup` for details. -#. Run ``pip install -r requirements.txt`` from the collection root directory. - - - Running ``tox -elinters``: - - * Reads :file:`tox.ini` from the collection root directory and installs required dependencies (such as ``black`` and ``flake8``). - * Runs these with preconfigured options (such as line-length and ignores.) - * Runs ``black`` in check mode to show which files will be formatted without actually formatting them. - -Testing resource modules -======================== - -The tests rely on a role generated by the resource module builder. After changes to the resource module builder, the role should be regenerated and the tests modified and run as needed. To generate the role after changes: - -.. code-block:: bash - - rm -rf rmb_tests/roles/my_role - ansible-playbook -e rm_dest=./rmb_tests/roles/my_role \ - -e structure=role \ - -e model=models/myos/interfaces/myos_interfaces.yml \ - site.yml - - -.. _testing_resource_modules: - -Resource module integration tests ----------------------------------- - -High-level integration test requirements for new resource modules are as follows: - -#. Write a test case for every state. -#. Write additional test cases to test the behavior of the module when an empty ``config.yaml`` is given. -#. Add a round trip test case. This involves a ``merge`` operation, followed by ``gather_facts``, a ``merge`` update with additional configuration, and then reverting back to the base configuration using the previously gathered facts with the ``state`` set to ``overridden``. -#. Wherever applicable, assertions should check after and before ``dicts`` against a hard coded Source of Truth. - -.. _using_zuul_resource_modules: - -We use Zuul as the CI to run the integration test. - -* To view the report, click :guilabel:`Details` on the CI comment in the PR -* To view a failure report, click :guilabel:`ansible/check` and select the failed test. -* To view logs while the test is running, check for your PR number in the `Zuul status board `_. -* To fix static test failure locally, run the :command:`tox -e black` **inside the root folder of collection**. - -To view The Ansible run logs and debug test failures: - -#. Click the failed job to get the summary, and click :guilabel:`Logs` for the log. -#. Click :guilabel:`console` and scroll down to find the failed test. -#. Click :guilabel:`>` next to the failed test for complete details. - - -Integration test structure -........................... - -Each test case should generally follow this pattern: - -* setup —> test —> assert —> test again (for idempotency) —> assert —> tear down (if needed) -> done. This keeps test playbooks from becoming monolithic and difficult to troubleshoot. -* Include a name for each task that is not an assertion. You can add names to assertions as well, but it is easier to identify the broken task within a failed test if you add a name for each task. -* Files containing test cases must end in ``.yaml`` - -Implementation -.............. - -For platforms that support ``connection: local`` *and* ``connection: network_cli`` use the following guidance: - -* Name the :file:`targets/` directories after the module name. -* The :file:`main.yaml` file should just reference the transport. - -The following example walks through the integration tests for the ``vyos.vyos.vyos_l3_interfaces`` module in the `vyos.vyos `_ collection: - -``test/integration/targets/vyos_l3_interfaces/tasks/main.yaml`` - -.. code-block:: yaml - - --- - - import_tasks: cli.yaml - tags: - - cli - -``test/integration/targets/vyos_l3_interfaces/tasks/cli.yaml`` - -.. code-block:: yaml - - --- - - name: collect all cli test cases - find: - paths: "{{ role_path }}/tests/cli" - patterns: "{{ testcase }}.yaml" - register: test_cases - delegate_to: localhost - - - name: set test_items - set_fact: test_items="{{ test_cases.files | map(attribute='path') | list }}" - - - name: run test cases (connection=network_cli) - include_tasks: - file: "{{ test_case_to_run }}" - vars: - ansible_connection: network_cli - with_items: "{{ test_items }}" - loop_control: - loop_var: test_case_to_run - - - name: run test case (connection=local) - include_tasks: - file: "{{ test_case_to_run }}" - vars: - ansible_connection: local - ansible_become: false - with_first_found: "{{ test_items }}" - loop_control: - loop_var: test_case_to_run - -``test/integration/targets/vyos_l3_interfaces/tests/cli/overridden.yaml`` - -.. code-block:: yaml - - --- - - debug: - msg: START vyos_l3_interfaces merged integration tests on connection={{ ansible_connection - }} - - - import_tasks: _remove_config.yaml - - - block: - - - import_tasks: _populate.yaml - - - name: Overrides all device configuration with provided configuration - register: result - vyos.vyos.vyos_l3_interfaces: &id001 - config: - - - name: eth0 - ipv4: - - - address: dhcp - - - name: eth1 - ipv4: - - - address: 192.0.2.15/24 - state: overridden - - - name: Assert that before dicts were correctly generated - assert: - that: - - "{{ populate | symmetric_difference(result['before']) |length == 0 }}" - - - name: Assert that correct commands were generated - assert: - that: - - "{{ overridden['commands'] | symmetric_difference(result['commands'])\ - \ |length == 0 }}" - - - name: Assert that after dicts were correctly generated - assert: - that: - - "{{ overridden['after'] | symmetric_difference(result['after']) |length\ - \ == 0 }}" - - - name: Overrides all device configuration with provided configurations (IDEMPOTENT) - register: result - vyos.vyos.vyos_l3_interfaces: *id001 - - - name: Assert that the previous task was idempotent - assert: - that: - - result['changed'] == false - - - name: Assert that before dicts were correctly generated - assert: - that: - - "{{ overridden['after'] | symmetric_difference(result['before']) |length\ - \ == 0 }}" - always: - - - import_tasks: _remove_config.yaml - - -Detecting test resources at runtime -................................... - -Your tests should detect resources (such as interfaces) at runtime rather than hard-coding them into the test. This allows the test to run on a variety of systems. - -For example: - -.. code-block:: yaml - - - name: Collect interface list - connection: ansible.netcommon.network_cli - register: intout - cisco.nxos.nxos_command: - commands: - - show interface brief | json - - - set_fact: - intdataraw: "{{ intout.stdout_lines[0]['TABLE_interface']['ROW_interface'] }}" - - - set_fact: - nxos_int1: '{{ intdataraw[1].interface }}' - - - set_fact: - nxos_int2: '{{ intdataraw[2].interface }}' - - - set_fact: - nxos_int3: '{{ intdataraw[3].interface }}' - - -See the complete test example of this at https://github.com/ansible-collections/cisco.nxos/blob/main/tests/integration/targets/prepare_nxos_tests/tasks/main.yml. - - -Running network integration tests -.................................. - -Ansible uses Zuul to run an integration test suite on every PR, including new tests introduced by that PR. To find and fix problems in network modules, run the network integration test locally before you submit a PR. - - -First, create an inventory file that points to your test machines. The inventory group should match the platform name (for example, ``eos``, ``ios``): - -.. code-block:: bash - - cd test/integration - cp inventory.network.template inventory.networking - ${EDITOR:-vi} inventory.networking - # Add in machines for the platform(s) you wish to test - -To run these network integration tests, use ``ansible-test network-integration --inventory     ``: - -.. code-block:: console - - ansible-test network-integration --inventory ~/myinventory -vvv vyos_facts - ansible-test network-integration --inventory ~/myinventory -vvv vyos_.* - - - -To run all network tests for a particular platform: - -.. code-block:: bash - - ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking vyos_.* - -This example will run against all ``vyos`` modules. Note that ``vyos_.*`` is a regex match, not a bash wildcard - include the `.` if you modify this example. - -To run integration tests for a specific module: - -.. code-block:: bash - - ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking vyos_l3_interfaces - -To run a single test case on a specific module: - -.. code-block:: bash - - # Only run vyos_l3_interfaces/tests/cli/gathered.yaml - ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking vyos_l3_interfaces --testcase gathered - -To run integration tests for a specific transport: - -.. code-block:: bash - - # Only run nxapi test - ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking --tags="nxapi" nxos_.* - - # Skip any cli tests - ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking --skip-tags="cli" nxos_.* - -See `test/integration/targets/nxos_bgp/tasks/main.yaml `_ for how this is implemented in the tests. - -For more options: - -.. code-block:: bash - - ansible-test network-integration --help - -If you need additional help or feedback, reach out in the ``#ansible-network`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). - -Unit test requirements ------------------------ - -High-level unit test requirements that new resource modules should follow: - -#. Write test cases for all the states with all possible combinations of config values. -#. Write test cases to test the error conditions ( negative scenarios). -#. Check the value of ``changed`` and ``commands`` keys in every test case. - -We run all unit test cases on our Zuul test suite, on the latest python version supported by our CI setup. - -Use the :ref:`same procedure ` as the integration tests to view Zuul unit tests reports and logs. - -See :ref:`unit module testing ` for general unit test details. - -.. end of cut n .. parsed-literal:: - - -Example: Unit testing Ansible network resource modules -====================================================== - - -This section walks through an example of how to develop unit tests for Ansible resource -modules. - -See :ref:`testing_units` and :ref:`testing_units_modules` for general documentation on Ansible unit tests for modules. -Please read those pages first to understand unit tests and why and when you should use them. - - -Using mock objects to unit test Ansible network resource modules ----------------------------------------------------------------- - - -`Mock objects `_ can be very -useful in building unit tests for special or difficult cases, but they can also -lead to complex and confusing coding situations. One good use for mocks would be to -simulate an API. The ``mock`` Python package is bundled with Ansible (use -``import units.compat.mock``). - -You can mock the device connection and output from the device as follows: - -.. code-block:: python - - self.mock_get_config = patch( "ansible_collections.ansible.netcommon.plugins.module_utils.network.common.network.Config.get_config" - ) - self.get_config = self.mock_get_config.start() - - self.mock_load_config = patch( - "ansible_collections.ansible.netcommon.plugins.module_utils.network.common.network.Config.load_config" - ) - self.load_config = self.mock_load_config.start() - - self.mock_get_resource_connection_config = patch( - "ansible_collections.ansible.netcommon.plugins.module_utils.network.common.cfg.base.get_resource_connection" - ) - self.get_resource_connection_config = (self.mock_get_resource_connection_config.start()) - - self.mock_get_resource_connection_facts = patch( - "ansible_collections.ansible.netcommon.plugins.module_utils.network.common.facts.facts.get_resource_connection" - ) - self.get_resource_connection_facts = (self.mock_get_resource_connection_facts.start()) - - self.mock_edit_config = patch( - "ansible_collections.arista.eos.plugins.module_utils.network.eos.providers.providers.CliProvider.edit_config" - ) - self.edit_config = self.mock_edit_config.start() - - self.mock_execute_show_command = patch( - "ansible_collections.arista.eos.plugins.module_utils.network.eos.facts.l2_interfaces.l2_interfaces.L2_interfacesFacts.get_device_data" - ) - self.execute_show_command = self.mock_execute_show_command.start() - - -The facts file of the module now includes a new method, ``get_device_data``. Call ``get_device_data`` here to emulate the device output. - - -Mocking device data ------------------------ - -To mock fetching results from devices or provide other complex data structures that -come from external libraries, you can use ``fixtures`` to read in pre-generated data. The text files for this pre-generated data live in ``test/units/modules/network/PLATFORM/fixtures/``. See for example the `eos_l2_interfaces.cfg file `_. - -Load data using the ``load_fixture`` method and set this data as the return value of the -``get_device_data`` method in the facts file: - -.. code-block:: python - - def load_fixtures(self, commands=None, transport='cli'): - def load_from_file(*args, **kwargs): - return load_fixture('eos_l2_interfaces_config.cfg') - self.execute_show_command.side_effect = load_from_file - -See the unit test file `test_eos_l2_interfaces `_ -for a practical example. - - -.. seealso:: - - :ref:`testing_units` - Deep dive into developing unit tests for Ansible modules - :ref:`testing_running_locally` - Running tests locally including gathering and reporting coverage data - :ref:`developing_modules_general` - Get started developing a module diff --git a/docs/docsite/rst/network/dev_guide/documenting_modules_network.rst b/docs/docsite/rst/network/dev_guide/documenting_modules_network.rst deleted file mode 100644 index 99ba7a95e50..00000000000 --- a/docs/docsite/rst/network/dev_guide/documenting_modules_network.rst +++ /dev/null @@ -1,52 +0,0 @@ - -.. _documenting_modules_network: - -********************************* -Documenting new network platforms -********************************* - -.. contents:: - :local: - -When you create network modules for a new platform, or modify the connections provided by an existing network platform (such as ``network_cli`` and ``httpapi``), you also need to update the :ref:`settings_by_platform` table and add or modify the Platform Options file for your platform. - -You should already have documented each module as described in :ref:`developing_modules_documenting`. - -Modifying the platform options table -==================================== - -The :ref:`settings_by_platform` table is a convenient summary of the connections options provided by each network platform that has modules in Ansible. Add a row for your platform to this table, in alphabetical order. For example: - -.. code-block:: text - - +-------------------+-------------------------+-------------+---------+---------+----------+ - | My OS | ``myos`` | ✓ | ✓ | | ✓ | - -Ensure that the table stays formatted correctly. That is: - -* Each row is inserted in alphabetical order. -* The cell division ``|`` markers line up with the ``+`` markers. -* The check marks appear only for the connection types provided by the network modules. - - - -Adding a platform-specific options section -========================================== - -The platform- specific sections are individual ``.rst`` files that provide more detailed information for the users of your network platform modules. Name your new file ``platform_.rst`` (for example, ``platform_myos.rst``). The platform name should match the module prefix. See `platform_eos.rst `_ and :ref:`eos_platform_options` for an example of the details you should provide in your platform-specific options section. - -Your platform-specific section should include the following: - -* **Connections available table** - a deeper dive into each connection type, including details on credentials, indirect access, connections settings, and enable mode. -* **How to use each connection type** - with working examples of each connection type. - -If your network platform supports SSH connections, also include the following at the bottom of your ``.rst`` file: - -.. code-block:: text - - .. include:: shared_snippets/SSH_warning.txt - -Adding your new file to the table of contents -============================================= - -As a final step, add your new file in alphabetical order in the ``platform_index.rst`` file. You should then build the documentation to verify your additions. See :ref:`community_documentation_contributions` for more details. diff --git a/docs/docsite/rst/network/dev_guide/index.rst b/docs/docsite/rst/network/dev_guide/index.rst deleted file mode 100644 index 5f0e7924ec0..00000000000 --- a/docs/docsite/rst/network/dev_guide/index.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _network_developer_guide: - -********************************** -Network Developer Guide -********************************** - -Welcome to the Developer Guide for Ansible Network Automation! - -**Who should use this guide?** - -If you want to extend Ansible for Network Automation by creating a module or plugin, this guide is for you. This guide is specific to networking. You should already be familiar with how to create, test, and document modules and plugins, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository. See the :ref:`developer_guide` for details. Before you proceed, please read: - -* How to :ref:`add a custom plugin or module locally `. -* How to figure out if :ref:`developing a module is the right approach ` for my use case. -* How to :ref:`set up my Python development environment `. -* How to :ref:`get started writing a module `. - - -Find the network developer task that best describes what you want to do: - - * I want to :ref:`develop a network resource module `. - * I want to :ref:`develop a network connection plugin `. - * I want to :ref:`document my set of modules for a network platform `. - -If you prefer to read the entire guide, here's a list of the pages in order. - -.. toctree:: - :maxdepth: 1 - - developing_resource_modules_network - developing_plugins_network - documenting_modules_network diff --git a/docs/docsite/rst/network/getting_started/basic_concepts.rst b/docs/docsite/rst/network/getting_started/basic_concepts.rst deleted file mode 100644 index 980b144d35b..00000000000 --- a/docs/docsite/rst/network/getting_started/basic_concepts.rst +++ /dev/null @@ -1,10 +0,0 @@ -************** -Basic Concepts -************** - -These concepts are common to all uses of Ansible, including network automation. You need to understand them to use Ansible for network automation. This basic introduction provides the background you need to follow the examples in this guide. - -.. contents:: - :local: - -.. include:: ../../shared_snippets/basic_concepts.txt diff --git a/docs/docsite/rst/network/getting_started/first_inventory.rst b/docs/docsite/rst/network/getting_started/first_inventory.rst deleted file mode 100644 index 1562ed42c65..00000000000 --- a/docs/docsite/rst/network/getting_started/first_inventory.rst +++ /dev/null @@ -1,431 +0,0 @@ -*********************************************** -Build Your Inventory -*********************************************** - -Running a playbook without an inventory requires several command-line flags. Also, running a playbook against a single device is not a huge efficiency gain over making the same change manually. The next step to harnessing the full power of Ansible is to use an inventory file to organize your managed nodes into groups with information like the ``ansible_network_os`` and the SSH user. A fully-featured inventory file can serve as the source of truth for your network. Using an inventory file, a single playbook can maintain hundreds of network devices with a single command. This page shows you how to build an inventory file, step by step. - -.. contents:: - :local: - -Basic inventory -================================================== - -First, group your inventory logically. Best practice is to group servers and network devices by their What (application, stack or microservice), Where (datacenter or region), and When (development stage): - -- **What**: db, web, leaf, spine -- **Where**: east, west, floor_19, building_A -- **When**: dev, test, staging, prod - -Avoid spaces, hyphens, and preceding numbers (use ``floor_19``, not ``19th_floor``) in your group names. Group names are case sensitive. - -This tiny example data center illustrates a basic group structure. You can group groups using the syntax ``[metagroupname:children]`` and listing groups as members of the metagroup. Here, the group ``network`` includes all leafs and all spines; the group ``datacenter`` includes all network devices plus all webservers. - -.. code-block:: yaml - - --- - - leafs: - hosts: - leaf01: - ansible_host: 10.16.10.11 - leaf02: - ansible_host: 10.16.10.12 - - spines: - hosts: - spine01: - ansible_host: 10.16.10.13 - spine02: - ansible_host: 10.16.10.14 - - network: - children: - leafs: - spines: - - webservers: - hosts: - webserver01: - ansible_host: 10.16.10.15 - webserver02: - ansible_host: 10.16.10.16 - - datacenter: - children: - network: - webservers: - - - -You can also create this same inventory in INI format. - -.. code-block:: ini - - [leafs] - leaf01 - leaf02 - - [spines] - spine01 - spine02 - - [network:children] - leafs - spines - - [webservers] - webserver01 - webserver02 - - [datacenter:children] - network - webservers - - -Add variables to the inventory -================================================================================ - -Next, you can set values for many of the variables you needed in your first Ansible command in the inventory, so you can skip them in the ``ansible-playbook`` command. In this example, the inventory includes each network device's IP, OS, and SSH user. If your network devices are only accessible by IP, you must add the IP to the inventory file. If you access your network devices using hostnames, the IP is not necessary. - -.. code-block:: yaml - - --- - - leafs: - hosts: - leaf01: - ansible_host: 10.16.10.11 - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - leaf02: - ansible_host: 10.16.10.12 - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - - spines: - hosts: - spine01: - ansible_host: 10.16.10.13 - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - spine02: - ansible_host: 10.16.10.14 - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - - network: - children: - leafs: - spines: - - webservers: - hosts: - webserver01: - ansible_host: 10.16.10.15 - ansible_user: my_server_user - webserver02: - ansible_host: 10.16.10.16 - ansible_user: my_server_user - - datacenter: - children: - network: - webservers: - - -Group variables within inventory -================================================================================ - -When devices in a group share the same variable values, such as OS or SSH user, you can reduce duplication and simplify maintenance by consolidating these into group variables: - -.. code-block:: yaml - - --- - - leafs: - hosts: - leaf01: - ansible_host: 10.16.10.11 - leaf02: - ansible_host: 10.16.10.12 - vars: - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - - spines: - hosts: - spine01: - ansible_host: 10.16.10.13 - spine02: - ansible_host: 10.16.10.14 - vars: - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - - network: - children: - leafs: - spines: - - webservers: - hosts: - webserver01: - ansible_host: 10.16.10.15 - webserver02: - ansible_host: 10.16.10.16 - vars: - ansible_user: my_server_user - - datacenter: - children: - network: - webservers: - -Variable syntax -================================================================================ - -The syntax for variable values is different in inventory, in playbooks, and in the ``group_vars`` files, which are covered below. Even though playbook and ``group_vars`` files are both written in YAML, you use variables differently in each. - -- In an ini-style inventory file you **must** use the syntax ``key=value`` for variable values: ``ansible_network_os=vyos.vyos.vyos``. -- In any file with the ``.yml`` or ``.yaml`` extension, including playbooks and ``group_vars`` files, you **must** use YAML syntax: ``key: value``. - -- In ``group_vars`` files, use the full ``key`` name: ``ansible_network_os: vyos.vyos.vyos``. -- In playbooks, use the short-form ``key`` name, which drops the ``ansible`` prefix: ``network_os: vyos.vyos.vyos``. - - -Group inventory by platform -================================================================================ - -As your inventory grows, you may want to group devices by platform. This allows you to specify platform-specific variables easily for all devices on that platform: - -.. code-block:: yaml - - --- - - leafs: - hosts: - leaf01: - ansible_host: 10.16.10.11 - leaf02: - ansible_host: 10.16.10.12 - - spines: - hosts: - spine01: - ansible_host: 10.16.10.13 - spine02: - ansible_host: 10.16.10.14 - - network: - children: - leafs: - spines: - vars: - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - - webservers: - hosts: - webserver01: - ansible_host: 10.16.10.15 - webserver02: - ansible_host: 10.16.10.16 - vars: - ansible_user: my_server_user - - datacenter: - children: - network: - webservers: - -With this setup, you can run ``first_playbook.yml`` with only two flags: - -.. code-block:: console - - ansible-playbook -i inventory.yml -k first_playbook.yml - -With the ``-k`` flag, you provide the SSH password(s) at the prompt. Alternatively, you can store SSH and other secrets and passwords securely in your group_vars files with ``ansible-vault``. See :ref:`network_vault` for details. - -Verifying the inventory -========================= - -You can use the :ref:`ansible-inventory` CLI command to display the inventory as Ansible sees it. - -.. code-block:: console - - $ ansible-inventory -i test.yml --list - { - "_meta": { - "hostvars": { - "leaf01": { - "ansible_connection": "ansible.netcommon.network_cli", - "ansible_host": "10.16.10.11", - "ansible_network_os": "vyos.vyos.vyos", - "ansible_user": "my_vyos_user" - }, - "leaf02": { - "ansible_connection": "ansible.netcommon.network_cli", - "ansible_host": "10.16.10.12", - "ansible_network_os": "vyos.vyos.vyos", - "ansible_user": "my_vyos_user" - }, - "spine01": { - "ansible_connection": "ansible.netcommon.network_cli", - "ansible_host": "10.16.10.13", - "ansible_network_os": "vyos.vyos.vyos", - "ansible_user": "my_vyos_user" - }, - "spine02": { - "ansible_connection": "ansible.netcommon.network_cli", - "ansible_host": "10.16.10.14", - "ansible_network_os": "vyos.vyos.vyos", - "ansible_user": "my_vyos_user" - }, - "webserver01": { - "ansible_host": "10.16.10.15", - "ansible_user": "my_server_user" - }, - "webserver02": { - "ansible_host": "10.16.10.16", - "ansible_user": "my_server_user" - } - } - }, - "all": { - "children": [ - "datacenter", - "ungrouped" - ] - }, - "datacenter": { - "children": [ - "network", - "webservers" - ] - }, - "leafs": { - "hosts": [ - "leaf01", - "leaf02" - ] - }, - "network": { - "children": [ - "leafs", - "spines" - ] - }, - "spines": { - "hosts": [ - "spine01", - "spine02" - ] - }, - "webservers": { - "hosts": [ - "webserver01", - "webserver02" - ] - } - } - -.. _network_vault: - -Protecting sensitive variables with ``ansible-vault`` -================================================================================ - -The ``ansible-vault`` command provides encryption for files and/or individual variables like passwords. This tutorial will show you how to encrypt a single SSH password. You can use the commands below to encrypt other sensitive information, such as database passwords, privilege-escalation passwords and more. - -First you must create a password for ansible-vault itself. It is used as the encryption key, and with this you can encrypt dozens of different passwords across your Ansible project. You can access all those secrets (encrypted values) with a single password (the ansible-vault password) when you run your playbooks. Here's a simple example. - -1. Create a file and write your password for ansible-vault to it: - -.. code-block:: console - - echo "my-ansible-vault-pw" > ~/my-ansible-vault-pw-file - -2. Create the encrypted ssh password for your VyOS network devices, pulling your ansible-vault password from the file you just created: - -.. code-block:: console - - ansible-vault encrypt_string --vault-id my_user@~/my-ansible-vault-pw-file 'VyOS_SSH_password' --name 'ansible_password' - -If you prefer to type your ansible-vault password rather than store it in a file, you can request a prompt: - -.. code-block:: console - - ansible-vault encrypt_string --vault-id my_user@prompt 'VyOS_SSH_password' --name 'ansible_password' - -and type in the vault password for ``my_user``. - -The :option:`--vault-id ` flag allows different vault passwords for different users or different levels of access. The output includes the user name ``my_user`` from your ``ansible-vault`` command and uses the YAML syntax ``key: value``: - -.. code-block:: yaml - - ansible_password: !vault | - $ANSIBLE_VAULT;1.2;AES256;my_user - 66386134653765386232383236303063623663343437643766386435663632343266393064373933 - 3661666132363339303639353538316662616638356631650a316338316663666439383138353032 - 63393934343937373637306162366265383461316334383132626462656463363630613832313562 - 3837646266663835640a313164343535316666653031353763613037656362613535633538386539 - 65656439626166666363323435613131643066353762333232326232323565376635 - Encryption successful - -This is an example using an extract from a YAML inventory, as the INI format does not support inline vaults: - -.. code-block:: yaml - - ... - - vyos: # this is a group in yaml inventory, but you can also do under a host - vars: - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - ansible_password: !vault | - $ANSIBLE_VAULT;1.2;AES256;my_user - 66386134653765386232383236303063623663343437643766386435663632343266393064373933 - 3661666132363339303639353538316662616638356631650a316338316663666439383138353032 - 63393934343937373637306162366265383461316334383132626462656463363630613832313562 - 3837646266663835640a313164343535316666653031353763613037656362613535633538386539 - 65656439626166666363323435613131643066353762333232326232323565376635 - - ... - -To use an inline vaulted variables with an INI inventory you need to store it in a 'vars' file in YAML format, -it can reside in host_vars/ or group_vars/ to be automatically picked up or referenced from a play through ``vars_files`` or ``include_vars``. - -To run a playbook with this setup, drop the ``-k`` flag and add a flag for your ``vault-id``: - -.. code-block:: console - - ansible-playbook -i inventory --vault-id my_user@~/my-ansible-vault-pw-file first_playbook.yml - -Or with a prompt instead of the vault password file: - -.. code-block:: console - - ansible-playbook -i inventory --vault-id my_user@prompt first_playbook.yml - -To see the original value, you can use the debug module. Please note if your YAML file defines the `ansible_connection` variable (as we used in our example), it will take effect when you execute the command below. To prevent this, please make a copy of the file without the ansible_connection variable. - -.. code-block:: console - - cat vyos.yml | grep -v ansible_connection >> vyos_no_connection.yml - - ansible localhost -m debug -a var="ansible_password" -e "@vyos_no_connection.yml" --ask-vault-pass - Vault password: - - localhost | SUCCESS => { - "ansible_password": "VyOS_SSH_password" - } - - -.. warning:: - - Vault content can only be decrypted with the password that was used to encrypt it. If you want to stop using one password and move to a new one, you can update and re-encrypt existing vault content with ``ansible-vault rekey myfile``, then provide the old password and the new password. Copies of vault content still encrypted with the old password can still be decrypted with old password. - -For more details on building inventory files, see :ref:`the introduction to inventory`; for more details on ansible-vault, see :ref:`the full Ansible Vault documentation`. - -Now that you understand the basics of commands, playbooks, and inventory, it's time to explore some more complex Ansible Network examples. diff --git a/docs/docsite/rst/network/getting_started/first_playbook.rst b/docs/docsite/rst/network/getting_started/first_playbook.rst deleted file mode 100644 index 15a4ed16f51..00000000000 --- a/docs/docsite/rst/network/getting_started/first_playbook.rst +++ /dev/null @@ -1,212 +0,0 @@ - -.. _first_network_playbook: - -*************************************************** -Run Your First Command and Playbook -*************************************************** - -Put the concepts you learned to work with this quick tutorial. Install Ansible, execute a network configuration command manually, execute the same command with Ansible, then create a playbook so you can execute the command any time on multiple network devices. - -.. contents:: - :local: - -Prerequisites -================================================== - -Before you work through this tutorial you need: - -- Ansible 2.10 (or higher) installed -- One or more network devices that are compatible with Ansible -- Basic Linux command line knowledge -- Basic knowledge of network switch & router configuration - -Install Ansible -================================================== - -Install Ansible using your preferred method. See :ref:`installation_guide`. Then return to this tutorial. - -Confirm the version of Ansible (must be >= 2.10): - -.. code-block:: bash - - ansible --version - - -Establish a manual connection to a managed node -================================================== - -To confirm your credentials, connect to a network device manually and retrieve its configuration. Replace the sample user and device name with your real credentials. For example, for a VyOS router: - -.. code-block:: bash - - ssh my_vyos_user@vyos.example.net - show config - exit - -This manual connection also establishes the authenticity of the network device, adding its RSA key fingerprint to your list of known hosts. (If you have connected to the device before, you have already established its authenticity.) - - -Run your first network Ansible command -================================================== - -Instead of manually connecting and running a command on the network device, you can retrieve its configuration with a single, stripped-down Ansible command: - -.. code-block:: bash - - ansible all -i vyos.example.net, -c ansible.netcommon.network_cli -u my_vyos_user -k -m vyos.vyos.vyos_facts -e ansible_network_os=vyos.vyos.vyos - -The flags in this command set seven values: - - the host group(s) to which the command should apply (in this case, all) - - the inventory (-i, the device or devices to target - without the trailing comma -i points to an inventory file) - - the connection method (-c, the method for connecting and executing ansible) - - the user (-u, the username for the SSH connection) - - the SSH connection method (-k, please prompt for the password) - - the module (-m, the Ansible module to run, using the fully qualified collection name (FQCN)) - - an extra variable ( -e, in this case, setting the network OS value) - -NOTE: If you use ``ssh-agent`` with ssh keys, Ansible loads them automatically. You can omit ``-k`` flag. - -.. note:: - - If you are running Ansible in a virtual environment, you will also need to add the variable ``ansible_python_interpreter=/path/to/venv/bin/python`` - - -Create and run your first network Ansible Playbook -================================================== - -If you want to run this command every day, you can save it in a playbook and run it with ``ansible-playbook`` instead of ``ansible``. The playbook can store a lot of the parameters you provided with flags at the command line, leaving less to type at the command line. You need two files for this - a playbook and an inventory file. - -1. Download :download:`first_playbook.yml `, which looks like this: - -.. literalinclude:: sample_files/first_playbook.yml - :language: YAML - -The playbook sets three of the seven values from the command line above: the group (``hosts: all``), the connection method (``connection: ansible.netcommon.network_cli``) and the module (in each task). With those values set in the playbook, you can omit them on the command line. The playbook also adds a second task to show the config output. When a module runs in a playbook, the output is held in memory for use by future tasks instead of written to the console. The debug task here lets you see the results in your shell. - -2. Run the playbook with the command: - -.. code-block:: bash - - ansible-playbook -i vyos.example.net, -u ansible -k -e ansible_network_os=vyos.vyos.vyos first_playbook.yml - -The playbook contains one play with two tasks, and should generate output like this: - -.. code-block:: shell - - $ ansible-playbook -i vyos.example.net, -u ansible -k -e ansible_network_os=vyos.vyos.vyos first_playbook.yml - - PLAY [Network Getting Started First Playbook] - *************************************************************************************************************************** - - TASK [Get config for VyOS devices] - *************************************************************************************************************************** - ok: [vyos.example.net] - - TASK [Display the config] - *************************************************************************************************************************** - ok: [vyos.example.net] => { - "msg": "The hostname is vyos and the OS is VyOS 1.1.8" - } - -3. Now that you can retrieve the device config, try updating it with Ansible. Download :download:`first_playbook_ext.yml `, which is an extended version of the first playbook: - -.. literalinclude:: sample_files/first_playbook_ext.yml - :language: YAML - -The extended first playbook has five tasks in a single play. Run it with the same command you used above. The output shows you the change Ansible made to the config: - -.. code-block:: shell - - $ ansible-playbook -i vyos.example.net, -u ansible -k -e ansible_network_os=vyos.vyos.vyos first_playbook_ext.yml - - PLAY [Network Getting Started First Playbook Extended] - ************************************************************************************************************************************ - - TASK [Get config for VyOS devices] - ********************************************************************************************************************************** - ok: [vyos.example.net] - - TASK [Display the config] - ************************************************************************************************************************************* - ok: [vyos.example.net] => { - "msg": "The hostname is vyos and the OS is VyOS 1.1.8" - } - - TASK [Update the hostname] - ************************************************************************************************************************************* - changed: [vyos.example.net] - - TASK [Get changed config for VyOS devices] - ************************************************************************************************************************************* - ok: [vyos.example.net] - - TASK [Display the changed config] - ************************************************************************************************************************************* - ok: [vyos.example.net] => { - "msg": "The new hostname is vyos-changed and the OS is VyOS 1.1.8" - } - - PLAY RECAP - ************************************************************************************************************************************ - vyos.example.net : ok=5 changed=1 unreachable=0 failed=0 - - - -.. _network_gather_facts: - -Gathering facts from network devices -==================================== - -The ``gather_facts`` keyword now supports gathering network device facts in standardized key/value pairs. You can feed these network facts into further tasks to manage the network device. - -You can also use the new ``gather_network_resources`` parameter with the network ``*_facts`` modules (such as :ref:`arista.eos.eos_facts `) to return just a subset of the device configuration, as shown below. - -.. code-block:: yaml - - - hosts: arista - gather_facts: True - gather_subset: interfaces - module_defaults: - arista.eos.eos_facts: - gather_network_resources: interfaces - -The playbook returns the following interface facts: - -.. code-block:: yaml - - "network_resources": { - "interfaces": [ - { - "description": "test-interface", - "enabled": true, - "mtu": "512", - "name": "Ethernet1" - }, - { - "enabled": true, - "mtu": "3000", - "name": "Ethernet2" - }, - { - "enabled": true, - "name": "Ethernet3" - }, - { - "enabled": true, - "name": "Ethernet4" - }, - { - "enabled": true, - "name": "Ethernet5" - }, - { - "enabled": true, - "name": "Ethernet6" - }, - ] - } - - -Note that this returns a subset of what is returned by just setting ``gather_subset: interfaces``. - -You can store these facts and use them directly in another task, such as with the :ref:`eos_interfaces ` resource module. diff --git a/docs/docsite/rst/network/getting_started/index.rst b/docs/docsite/rst/network/getting_started/index.rst deleted file mode 100644 index bf9f2eb01b7..00000000000 --- a/docs/docsite/rst/network/getting_started/index.rst +++ /dev/null @@ -1,34 +0,0 @@ -.. _network_getting_started: - -********************************** -Network Getting Started -********************************** - -Ansible collections support a wide range of vendors, device types, and actions, so you can manage your entire network with a single automation tool. With Ansible, you can: - -- Automate repetitive tasks to speed routine network changes and free up your time for more strategic work -- Leverage the same simple, powerful, and agentless automation tool for network tasks that operations and development use -- Separate the data model (in a playbook or role) from the execution layer (through Ansible modules) to manage heterogeneous network devices -- Benefit from community and vendor-generated sample playbooks and roles to help accelerate network automation projects -- Communicate securely with network hardware over SSH or HTTPS - -**Who should use this guide?** - -This guide is intended for network engineers using Ansible for the first time. If you understand networks but have never used Ansible, work through the guide from start to finish. - -This guide is also useful for experienced Ansible users automating network tasks for the first time. You can use Ansible commands, playbooks and modules to configure hubs, switches, routers, bridges and other network devices. But network modules are different from Linux/Unix and Windows modules, and you must understand some network-specific concepts to succeed. If you understand Ansible but have never automated a network task, start with the second section. - -This guide introduces basic Ansible concepts and guides you through your first Ansible commands, playbooks and inventory entries. - -.. toctree:: - :maxdepth: 2 - :caption: Getting Started Guide - - basic_concepts - network_differences - first_playbook - first_inventory - network_roles - intermediate_concepts - network_connection_options - network_resources diff --git a/docs/docsite/rst/network/getting_started/intermediate_concepts.rst b/docs/docsite/rst/network/getting_started/intermediate_concepts.rst deleted file mode 100644 index e53d6b851d9..00000000000 --- a/docs/docsite/rst/network/getting_started/intermediate_concepts.rst +++ /dev/null @@ -1,39 +0,0 @@ -***************** -Beyond the basics -***************** - -This page introduces some concepts that help you manage your Ansible workflow with directory structure and source control. Like the Basic Concepts at the beginning of this guide, these intermediate concepts are common to all uses of Ansible. - -.. contents:: - :local: - - -A typical Ansible filetree -========================== - -Ansible expects to find certain files in certain places. As you expand your inventory and create and run more network playbooks, keep your files organized in your working Ansible project directory like this: - -.. code-block:: console - - . - ├── backup - │   ├── vyos.example.net_config.2018-02-08@11:10:15 - │   ├── vyos.example.net_config.2018-02-12@08:22:41 - ├── first_playbook.yml - ├── inventory - ├── group_vars - │   ├── vyos.yml - │   └── eos.yml - ├── roles - │   ├── static_route - │   └── system - ├── second_playbook.yml - └── third_playbook.yml - -The ``backup`` directory and the files in it get created when you run modules like ``vyos_config`` with the ``backup: true`` parameter. - - -Tracking changes to inventory and playbooks: source control with git -==================================================================== - -As you expand your inventory, roles and playbooks, you should place your Ansible projects under source control. We recommend ``git`` for source control. ``git`` provides an audit trail, letting you track changes, roll back mistakes, view history and share the workload of managing, maintaining and expanding your Ansible ecosystem. There are plenty of tutorials and guides to using ``git`` available. diff --git a/docs/docsite/rst/network/getting_started/network_connection_options.rst b/docs/docsite/rst/network/getting_started/network_connection_options.rst deleted file mode 100644 index bdfb93cb97b..00000000000 --- a/docs/docsite/rst/network/getting_started/network_connection_options.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. _network_connection_options: - -*************************************** -Working with network connection options -*************************************** - -Network modules can support multiple connection protocols, such as ``ansible.netcommon.network_cli``, ``ansible.netcommon.netconf``, and ``ansible.netcommon.httpapi``. These connections include some common options you can set to control how the connection to your network device behaves. - -Common options are: - -* ``become`` and ``become_method`` as described in :ref:`privilege_escalation`. -* ``network_os`` - set to match your network platform you are communicating with. See the :ref:`platform-specific ` pages. -* ``remote_user`` as described in :ref:`connection_set_user`. -* Timeout options - ``persistent_command_timeout``, ``persistent_connect_timeout``, and ``timeout``. - -.. _timeout_options: - -Setting timeout options -======================= - -When communicating with a remote device, you have control over how long Ansible maintains the connection to that device, as well as how long Ansible waits for a command to complete on that device. Each of these options can be set as variables in your playbook files, environment variables, or settings in your :ref:`ansible.cfg file `. - -For example, the three options for controlling the connection timeout are as follows. - -Using vars (per task): - -.. code-block:: yaml - - - name: save running-config - cisco.ios.ios_command: - commands: copy running-config startup-config - vars: - ansible_command_timeout: 30 - -Using the environment variable: - -.. code-block:: bash - - $export ANSIBLE_PERSISTENT_COMMAND_TIMEOUT=30 - -Using the global configuration (in :file:`ansible.cfg`) - -.. code-block:: ini - - [persistent_connection] - command_timeout = 30 - -See :ref:`ansible_variable_precedence` for details on the relative precedence of each of these variables. See the individual connection type to understand each option. diff --git a/docs/docsite/rst/network/getting_started/network_differences.rst b/docs/docsite/rst/network/getting_started/network_differences.rst deleted file mode 100644 index ef9e97c3fa0..00000000000 --- a/docs/docsite/rst/network/getting_started/network_differences.rst +++ /dev/null @@ -1,68 +0,0 @@ -************************************************************ -How Network Automation is Different -************************************************************ - -Network automation uses the basic Ansible concepts, but there are important differences in how the network modules work. This introduction prepares you to understand the exercises in this guide. - -.. contents:: - :local: - -Execution on the control node -================================================================================ - -Unlike most Ansible modules, network modules do not run on the managed nodes. From a user's point of view, network modules work like any other modules. They work with ad hoc commands, playbooks, and roles. Behind the scenes, however, network modules use a different methodology than the other (Linux/Unix and Windows) modules use. Ansible is written and executed in Python. Because the majority of network devices can not run Python, the Ansible network modules are executed on the Ansible control node, where ``ansible`` or ``ansible-playbook`` runs. - -Network modules also use the control node as a destination for backup files, for those modules that offer a ``backup`` option. With Linux/Unix modules, where a configuration file already exists on the managed node(s), the backup file gets written by default in the same directory as the new, changed file. Network modules do not update configuration files on the managed nodes, because network configuration is not written in files. Network modules write backup files on the control node, usually in the `backup` directory under the playbook root directory. - -Multiple communication protocols -================================================================================ - -Because network modules execute on the control node instead of on the managed nodes, they can support multiple communication protocols. The communication protocol (XML over SSH, CLI over SSH, API over HTTPS) selected for each network module depends on the platform and the purpose of the module. Some network modules support only one protocol; some offer a choice. The most common protocol is CLI over SSH. You set the communication protocol with the ``ansible_connection`` variable: - -.. csv-table:: - :header: "Value of ansible_connection", "Protocol", "Requires", "Persistent?" - :widths: 30, 10, 10, 10 - - "ansible.netcommon.network_cli", "CLI over SSH", "network_os setting", "yes" - "ansible.netcommon.netconf", "XML over SSH", "network_os setting", "yes" - "ansible.netcommon.httpapi", "API over HTTP/HTTPS", "network_os setting", "yes" - "local", "depends on provider", "provider setting", "no" - -.. note:: - ``ansible.netcommon.httpapi`` deprecates ``eos_eapi`` and ``nxos_nxapi``. See :ref:`httpapi_plugins` for details and an example. - -The ``ansible_connection: local`` has been deprecated. Please use one of the persistent connection types listed above instead. With persistent connections, you can define the hosts and credentials only once, rather than in every task. You also need to set the ``network_os`` variable for the specific network platform you are communicating with. For more details on using each connection type on various platforms, see the :ref:`platform-specific ` pages. - - -Collections organized by network platform -================================================================================ - -A network platform is a set of network devices with a common operating system that can be managed by an Ansible collection, for example: - -- Arista: `arista.eos `_ -- Cisco: `cisco.ios `_, `cisco.iosxr `_, `cisco.nxos `_ -- Juniper: `junipernetworks.junos `_ -- VyOS `vyos.vyos `_ - -All modules within a network platform share certain requirements. Some network platforms have specific differences - see the :ref:`platform-specific ` documentation for details. - -.. _privilege_escalation: - -Privilege Escalation: ``enable`` mode, ``become``, and ``authorize`` -================================================================================ - -Several network platforms support privilege escalation, where certain tasks must be done by a privileged user. On network devices this is called the ``enable`` mode (the equivalent of ``sudo`` in \*nix administration). Ansible network modules offer privilege escalation for those network devices that support it. For details of which platforms support ``enable`` mode, with examples of how to use it, see the :ref:`platform-specific ` documentation. - -Using ``become`` for privilege escalation ------------------------------------------ - -Use the top-level Ansible parameter ``become: true`` with ``become_method: enable`` to run a task, play, or playbook with escalated privileges on any network platform that supports privilege escalation. You must use either ``connection: network_cli`` or ``connection: httpapi`` with ``become: true`` with ``become_method: enable``. If you are using ``network_cli`` to connect Ansible to your network devices, a ``group_vars`` file would look like: - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: cisco.ios.ios - ansible_become: true - ansible_become_method: enable - -For more information, see :ref:`Become and Networks` diff --git a/docs/docsite/rst/network/getting_started/network_resources.rst b/docs/docsite/rst/network/getting_started/network_resources.rst deleted file mode 100644 index a69aba905d7..00000000000 --- a/docs/docsite/rst/network/getting_started/network_resources.rst +++ /dev/null @@ -1,47 +0,0 @@ - -.. _network_resources: - -************************ -Resources and next steps -************************ - -.. contents:: - :local: - -Documents -========= - -Read more about Ansible for Network Automation: - -- :ref:`Network Platform Options ` -- Network Automation on the `Ansible website `_ -- Ansible Network `Blog posts `_ - -Events (on video and in person) -=============================== - -All sessions at Ansible events are recorded and include many Network-related topics (use Filter by Category to view only Network topics). You can also join us for future events in your area. See: - -- `Recorded AnsibleFests `_ -- `Recorded AnsibleAutomates `_ -- `Upcoming Ansible Events `_ page. - -GitHub repos -============ - -Ansible hosts module code, examples, demonstrations, and other content on GitHub. Anyone with a GitHub account is able to create Pull Requests (PRs) or issues on these repos: - -- `Network-Automation `_ is an open community for all things network automation. Have an idea, some playbooks, or roles to share? Email ansible-network@redhat.com and we will add you as a contributor to the repository. - -- `Ansible collections `_ is the main repository for Ansible-maintained and community collections, including collections for network devices. - - - -Chat channels -============= - -Got questions? Chat with us on: - -* the ``#ansible-network`` channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) - -* `Ansible Network Slack `_ - Network & Security Automation Slack community. Check out the #devel channel for discussions on module and plugin development. diff --git a/docs/docsite/rst/network/getting_started/network_roles.rst b/docs/docsite/rst/network/getting_started/network_roles.rst deleted file mode 100644 index 4ffb833026f..00000000000 --- a/docs/docsite/rst/network/getting_started/network_roles.rst +++ /dev/null @@ -1,267 +0,0 @@ - -.. _using_network_roles: - -************************* -Use Ansible network roles -************************* - -Roles are sets of Ansible defaults, files, tasks, templates, variables, and other Ansible components that work together. As you saw on :ref:`first_network_playbook`, moving from a command to a playbook makes it easy to run multiple tasks and repeat the same tasks in the same order. Moving from a playbook to a role makes it even easier to reuse and share your ordered tasks. You can look at :ref:`Ansible Galaxy `, which lets you share your roles and use others' roles, either directly or as inspiration. - -.. contents:: - :local: - -Understanding roles -=================== - -So what exactly is a role, and why should you care? Ansible roles are basically playbooks broken up into a known file structure. Moving to roles from a playbook makes sharing, reading, and updating your Ansible workflow easier. Users can write their own roles. So for example, you don't have to write your own DNS playbook. Instead, you specify a DNS server and a role to configure it for you. - -To simplify your workflow even further, the Ansible Network team has written a series of roles for common network use cases. Using these roles means you don't have to reinvent the wheel. Instead of writing and maintaining your own ``create_vlan`` playbooks or roles, you can concentrate on designing, codifying and maintaining the parser templates that describe your network topologies and inventory, and let Ansible's network roles do the work. See the `network-related roles `_ on Ansible Galaxy. - -A sample DNS playbook ---------------------- - -To demonstrate the concept of what a role is, the example ``playbook.yml`` below is a single YAML file containing a two-task playbook. This Ansible Playbook configures the hostname on a Cisco IOS XE device, then it configures the DNS (domain name system) servers. - -.. code-block:: yaml - - --- - - name: configure cisco routers - hosts: routers - connection: ansible.netcommon.network_cli - gather_facts: no - vars: - dns: "8.8.8.8 8.8.4.4" - - tasks: - - name: configure hostname - cisco.ios.ios_config: - lines: hostname {{ inventory_hostname }} - - - name: configure DNS - cisco.ios.ios_config: - lines: ip name-server {{dns}} - -If you run this playbook using the ``ansible-playbook`` command, you'll see the output below. This example used ``-l`` option to limit the playbook to only executing on the **rtr1** node. - -.. code-block:: bash - - [user@ansible ~]$ ansible-playbook playbook.yml -l rtr1 - - PLAY [configure cisco routers] ************************************************* - - TASK [configure hostname] ****************************************************** - changed: [rtr1] - - TASK [configure DNS] *********************************************************** - changed: [rtr1] - - PLAY RECAP ********************************************************************* - rtr1 : ok=2 changed=2 unreachable=0 failed=0 - - -This playbook configured the hostname and DNS servers. You can verify that configuration on the Cisco IOS XE **rtr1** router: - -.. code-block:: bash - - rtr1#sh run | i name - hostname rtr1 - ip name-server 8.8.8.8 8.8.4.4 - -Convert the playbook into a role ---------------------------------- - -The next step is to convert this playbook into a reusable role. You can create the directory structure manually, or you can use ``ansible-galaxy init`` to create the standard framework for a role. - -.. code-block:: bash - - [user@ansible ~]$ ansible-galaxy init system-demo - [user@ansible ~]$ cd system-demo/ - [user@ansible system-demo]$ tree - . - ├── defaults - │ └── main.yml - ├── files - ├── handlers - │ └── main.yml - ├── meta - │ └── main.yml - ├── README.md - ├── tasks - │ └── main.yml - ├── templates - ├── tests - │ ├── inventory - │ └── test.yml - └── vars - └── main.yml - -This first demonstration uses only the **tasks** and **vars** directories. The directory structure would look as follows: - -.. code-block:: bash - - [user@ansible system-demo]$ tree - . - ├── tasks - │ └── main.yml - └── vars - └── main.yml - -Next, move the content of the ``vars`` and ``tasks`` sections from the original Ansible Playbook into the role. First, move the two tasks into the ``tasks/main.yml`` file: - -.. code-block:: bash - - [user@ansible system-demo]$ cat tasks/main.yml - --- - - name: configure hostname - cisco.ios.ios_config: - lines: hostname {{ inventory_hostname }} - - - name: configure DNS - cisco.ios.ios_config: - lines: ip name-server {{dns}} - -Next, move the variables into the ``vars/main.yml`` file: - -.. code-block:: bash - - [user@ansible system-demo]$ cat vars/main.yml - --- - dns: "8.8.8.8 8.8.4.4" - -Finally, modify the original Ansible Playbook to remove the ``tasks`` and ``vars`` sections and add the keyword ``roles`` with the name of the role, in this case ``system-demo``. You'll have this playbook: - -.. code-block:: yaml - - --- - - name: configure cisco routers - hosts: routers - connection: ansible.netcommon.network_cli - gather_facts: no - - roles: - - system-demo - -To summarize, this demonstration now has a total of three directories and three YAML files. There is the ``system-demo`` folder, which represents the role. This ``system-demo`` contains two folders, ``tasks`` and ``vars``. There is a ``main.yml`` is each respective folder. The ``vars/main.yml`` contains the variables from ``playbook.yml``. The ``tasks/main.yml`` contains the tasks from ``playbook.yml``. The ``playbook.yml`` file has been modified to call the role rather than specifying vars and tasks directly. Here is a tree of the current working directory: - -.. code-block:: bash - - [user@ansible ~]$ tree - . - ├── playbook.yml - └── system-demo - ├── tasks - │ └── main.yml - └── vars - └── main.yml - -Running the playbook results in identical behavior with slightly different output: - -.. code-block:: bash - - [user@ansible ~]$ ansible-playbook playbook.yml -l rtr1 - - PLAY [configure cisco routers] ************************************************* - - TASK [system-demo : configure hostname] **************************************** - ok: [rtr1] - - TASK [system-demo : configure DNS] ********************************************* - ok: [rtr1] - - PLAY RECAP ********************************************************************* - rtr1 : ok=2 changed=0 unreachable=0 failed=0 - -As seen above each task is now prepended with the role name, in this case ``system-demo``. When running a playbook that contains several roles, this will help pinpoint where a task is being called from. This playbook returned ``ok`` instead of ``changed`` because it has identical behavior for the single file playbook we started from. - -As before, the playbook will generate the following configuration on a Cisco IOS-XE router: - -.. code-block:: bash - - rtr1#sh run | i name - hostname rtr1 - ip name-server 8.8.8.8 8.8.4.4 - - -This is why Ansible roles can be simply thought of as deconstructed playbooks. They are simple, effective and reusable. Now another user can simply include the ``system-demo`` role instead of having to create a custom "hard coded" playbook. - -Variable precedence -------------------- - -What if you want to change the DNS servers? You aren't expected to change the ``vars/main.yml`` within the role structure. Ansible has many places where you can specify variables for a given play. See :ref:`playbooks_variables` for details on variables and precedence. There are actually 21 places to put variables. While this list can seem overwhelming at first glance, the vast majority of use cases only involve knowing the spot for variables of least precedence and how to pass variables with most precedence. See :ref:`ansible_variable_precedence` for more guidance on where you should put variables. - -Lowest precedence -^^^^^^^^^^^^^^^^^ - -The lowest precedence is the ``defaults`` directory within a role. This means all the other 20 locations you could potentially specify the variable will all take higher precedence than ``defaults``, no matter what. To immediately give the vars from the ``system-demo`` role the least precedence, rename the ``vars`` directory to ``defaults``. - -.. code-block:: bash - - [user@ansible system-demo]$ mv vars defaults - [user@ansible system-demo]$ tree - . - ├── defaults - │ └── main.yml - ├── tasks - │ └── main.yml - -Add a new ``vars`` section to the playbook to override the default behavior (where the variable ``dns`` is set to 8.8.8.8 and 8.8.4.4). For this demonstration, set ``dns`` to 1.1.1.1, so ``playbook.yml`` becomes: - -.. code-block:: yaml - - --- - - name: configure cisco routers - hosts: routers - connection: ansible.netcommon.network_cli - gather_facts: no - vars: - dns: 1.1.1.1 - roles: - - system-demo - -Run this updated playbook on **rtr2**: - -.. code-block:: bash - - [user@ansible ~]$ ansible-playbook playbook.yml -l rtr2 - -The configuration on the **rtr2** Cisco router will look as follows: - -.. code-block:: bash - - rtr2#sh run | i name-server - ip name-server 1.1.1.1 - -The variable configured in the playbook now has precedence over the ``defaults`` directory. In fact, any other spot you configure variables would win over the values in the ``defaults`` directory. - -Highest precedence -^^^^^^^^^^^^^^^^^^ - -Specifying variables in the ``defaults`` directory within a role will always take the lowest precedence, while specifying ``vars`` as extra vars with the ``-e`` or ``--extra-vars=`` will always take the highest precedence, no matter what. Re-running the playbook with the ``-e`` option overrides both the ``defaults`` directory (8.8.4.4 and 8.8.8.8) as well as the newly created ``vars`` within the playbook that contains the 1.1.1.1 dns server. - -.. code-block:: bash - - [user@ansible ~]$ ansible-playbook playbook.yml -e "dns=192.168.1.1" -l rtr3 - -The result on the Cisco IOS XE router will only contain the highest precedence setting of 192.168.1.1: - -.. code-block:: bash - - rtr3#sh run | i name-server - ip name-server 192.168.1.1 - -How is this useful? Why should you care? Extra vars are commonly used by network operators to override defaults. A powerful example of this is with the Job Template Survey feature on AWX or the :ref:`ansible_platform`. It is possible through the web UI to prompt a network operator to fill out parameters with a Web form. This can be really simple for non-technical playbook writers to execute a playbook using their Web browser. - - -Update an installed role ------------------------- - -The Ansible Galaxy page for a role lists all available versions. To update a locally installed role to a new or different version, use the ``ansible-galaxy install`` command with the version and ``--force`` option. You may also need to manually update any dependent roles to support this version. See the role **Read Me** tab in Galaxy for dependent role minimum version requirements. - -.. code-block:: bash - - [user@ansible]$ ansible-galaxy install mynamespace.my_role,v2.7.1 --force - -.. seealso:: - - `Ansible Galaxy documentation `_ - Ansible Galaxy user guide diff --git a/docs/docsite/rst/network/getting_started/sample_files/first_playbook.yml b/docs/docsite/rst/network/getting_started/sample_files/first_playbook.yml deleted file mode 100644 index 908b89f9ae3..00000000000 --- a/docs/docsite/rst/network/getting_started/sample_files/first_playbook.yml +++ /dev/null @@ -1,15 +0,0 @@ ---- - -- name: Network Getting Started First Playbook - connection: ansible.netcommon.network_cli - gather_facts: false - hosts: all - tasks: - - - name: Get config for VyOS devices - vyos.vyos.vyos_facts: - gather_subset: all - - - name: Display the config - debug: - msg: "The hostname is {{ ansible_net_hostname }} and the OS is {{ ansible_net_version }}" diff --git a/docs/docsite/rst/network/getting_started/sample_files/first_playbook_ext.yml b/docs/docsite/rst/network/getting_started/sample_files/first_playbook_ext.yml deleted file mode 100644 index 2d5f6a5f1f1..00000000000 --- a/docs/docsite/rst/network/getting_started/sample_files/first_playbook_ext.yml +++ /dev/null @@ -1,29 +0,0 @@ ---- - -- name: Network Getting Started First Playbook Extended - connection: ansible.netcommon.network_cli - gather_facts: false - hosts: all - tasks: - - - name: Get config for VyOS devices - vyos.vyos.vyos_facts: - gather_subset: all - - - name: Display the config - debug: - msg: "The hostname is {{ ansible_net_hostname }} and the OS is {{ ansible_net_version }}" - - - name: Update the hostname - vyos.vyos.vyos_config: - backup: yes - lines: - - set system host-name vyos-changed - - - name: Get changed config for VyOS devices - vyos.vyos.vyos_facts: - gather_subset: all - - - name: Display the changed config - debug: - msg: "The new hostname is {{ ansible_net_hostname }} and the OS is {{ ansible_net_version }}" diff --git a/docs/docsite/rst/network/index.rst b/docs/docsite/rst/network/index.rst deleted file mode 100644 index 257563910c9..00000000000 --- a/docs/docsite/rst/network/index.rst +++ /dev/null @@ -1,20 +0,0 @@ -:orphan: - -.. _network_guide: - -****************************** -Ansible for Network Automation -****************************** - -Ansible Network modules extend the benefits of simple, powerful, agentless automation to network administrators and teams. Ansible Network modules can configure your network stack, test and validate existing network state, and discover and correct network configuration drift. - -If you're new to Ansible, or new to using Ansible for network management, start with :ref:`network_getting_started`. If you are already familiar with network automation with Ansible, see :ref:`network_advanced`. - -For documentation on using a particular network module, consult the :ref:`list of all network modules`. Network modules for various hardware are supported by different teams including the hardware vendors themselves, volunteers from the Ansible community, and the Ansible Network Team. - -.. toctree:: - :maxdepth: 3 - - getting_started/index - user_guide/index - dev_guide/index diff --git a/docs/docsite/rst/network/user_guide/cli_parsing.rst b/docs/docsite/rst/network/user_guide/cli_parsing.rst deleted file mode 100644 index 5b6b40ee1ea..00000000000 --- a/docs/docsite/rst/network/user_guide/cli_parsing.rst +++ /dev/null @@ -1,744 +0,0 @@ -.. _cli_parsing: - -***************************************** -Parsing semi-structured text with Ansible -***************************************** - -The :ref:`cli_parse ` module parses semi-structured data such as network configurations into structured data to allow programmatic use of the data from that device. You can pull information from a network device and update a CMDB in one playbook. Use cases include automated troubleshooting, creating dynamic documentation, updating IPAM (IP address management) tools and so on. - - -.. contents:: - :local: - - -Understanding the CLI parser -============================= - -The `ansible.utils `_ collection version 1.0.0 or later includes the :ref:`cli_parse ` module that can run CLI commands and parse the semi-structured text output. You can use the ``cli_parse`` module on a device, host, or platform that only supports a command-line interface and the commands issued return semi-structured text. The ``cli_parse`` module can either run a CLI command on a device and return a parsed result or can simply parse any text document. The ``cli_parse`` module includes cli_parser plugins to interface with a variety of parsing engines. - -Why parse the text? --------------------- - -Parsing semi-structured data such as network configurations into structured data allows programmatic use of the data from that device. Use cases include automated troubleshooting, creating dynamic documentation, updating IPAM (IP address management) tools and so on. You may prefer to do this with Ansible natively to take advantage of native Ansible constructs such as: - -- The ``when`` clause to conditionally run other tasks or roles -- The ``assert`` module to check configuration and operational state compliance -- The ``template`` module to generate reports about configuration and operational state information -- Templates and ``command`` or ``config`` modules to generate host, device, or platform commands or configuration -- The current platform ``facts`` modules to supplement native facts information - -By parsing semi-structured text into Ansible native data structures, you can take full advantage of Ansible's network modules and plugins. - - -When not to parse the text ---------------------------- - -You should not parse semi-structured text when: - -- The device, host, or platform has a RESTAPI and returns JSON. -- Existing Ansible facts modules already return the desired data. -- Ansible network resource modules exist for configuration management of the device and resource. - -Parsing the CLI -========================= - -The ``cli_parse`` module includes the following cli_parsing plugins: - -``native`` - The native parsing engine built into Ansible and requires no addition python libraries -``xml`` - Convert XML to an Ansible native data structure -``textfsm`` - A python module which implements a template based state machine for parsing semi-formatted text -``ntc_templates`` - Predefined ``textfsm`` templates packages supporting a variety of platforms and commands -``ttp`` - A library for semi-structured text parsing using templates, with added capabilities to simplify the process -``pyats`` - Uses the parsers included with the Cisco Test Automation & Validation Solution -``jc`` - A python module that converts the output of dozens of popular Linux/UNIX/macOS/Windows commands and file types to python dictionaries or lists of dictionaries. Note: this filter plugin can be found in the ``community.general`` collection. -``json`` - Converts JSON output at the CLI to an Ansible native data structure - -Although Ansible contains a number of plugins that can convert XML to Ansible native data structures, the ``cli_parse`` module runs the command on devices that return XML and returns the converted data in a single task. - -Because ``cli_parse`` uses a plugin based architecture, it can use additional parsing engines from any Ansible collection. - -.. note:: - - The ``ansible.netcommon.native`` and ``ansible.utils.json`` parsing engines are fully supported with a Red Hat Ansible Automation Platform subscription. Red Hat Ansible Automation Platform subscription support is limited to the use of the ``ntc_templates``, pyATS, ``textfsm``, ``xmltodict``, public APIs as documented. - -Parsing with the native parsing engine --------------------------------------- - -The native parsing engine is included with the ``cli_parse`` module. It uses data captured using regular expressions to populate the parsed data structure. The native parsing engine requires a YAML template file to parse the command output. - -Networking example -^^^^^^^^^^^^^^^^^^ - -This example uses the output of a network device command and applies a native template to produce an output in Ansible structured data format. - -The ``show interface`` command output from the network device looks as follows: - -.. code-block:: console - - Ethernet1/1 is up - admin state is up, Dedicated Interface - Hardware: 100/1000/10000 Ethernet, address: 5254.005a.f8bd (bia 5254.005a.f8bd) - MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec - reliability 255/255, txload 1/255, rxload 1/255 - Encapsulation ARPA, medium is broadcast - Port mode is access - full-duplex, auto-speed - Beacon is turned off - Auto-Negotiation is turned on FEC mode is Auto - Input flow-control is off, output flow-control is off - Auto-mdix is turned off - Switchport monitor is off - EtherType is 0x8100 - EEE (efficient-ethernet) : n/a - Last link flapped 4week(s) 6day(s) - Last clearing of "show interface" counters never - <...> - - -Create the native template to match this output and store it as ``templates/nxos_show_interface.yaml``: - -.. code-block:: yaml - - --- - - example: Ethernet1/1 is up - getval: '(?P\S+) is (?P\S+)' - result: - "{{ name }}": - name: "{{ name }}" - state: - operating: "{{ oper_state }}" - shared: true - - - example: admin state is up, Dedicated Interface - getval: 'admin state is (?P\S+),' - result: - "{{ name }}": - name: "{{ name }}" - state: - admin: "{{ admin_state }}" - - - example: " Hardware: Ethernet, address: 5254.005a.f8b5 (bia 5254.005a.f8b5)" - getval: '\s+Hardware: (?P.*), address: (?P\S+)' - result: - "{{ name }}": - hardware: "{{ hardware }}" - mac_address: "{{ mac }}" - - -This native parser template is structured as a list of parsers, each containing the following key-value pairs: - -- ``example`` - An example line of the text line to be parsed -- ``getval`` - A regular expression using named capture groups to store the extracted data -- ``result`` - A data tree, populated as a template, from the parsed data -- ``shared`` - (optional) The shared key makes the parsed values available to the rest of the parser entries until matched again. - -The following example task uses ``cli_parse`` with the native parser and the example template above to parse the ``show interface`` command from a Cisco NXOS device: - -.. code-block:: yaml - - - name: "Run command and parse with native" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.netcommon.native - set_fact: interfaces - -Taking a deeper dive into this task: - -- The ``command`` option provides the command you want to run on the device or host. Alternately, you can provide text from a previous command with the ``text`` option instead. -- The ``parser`` option provides information specific to the parser engine. -- The ``name`` suboption provides the fully qualified collection name (FQCN) of the parsing engine (``ansible.netcommon.native``). -- The ``cli_parse`` module, by default, looks for the template in the templates directory as ``{{ short_os }}_{{ command }}.yaml``. - - - The ``short_os`` in the template filename is derived from either the host ``ansible_network_os`` or ``ansible_distribution``. - - Spaces in the network or host command are replace with ``_`` in the ``command`` portion of the template filename. In this example, the ``show interfaces`` network CLI command becomes ``show_interfaces`` in the filename. - -.. note:: - - ``ansible.netcommon.native`` parsing engine is fully supported with a Red Hat Ansible Automation Platform subscription. - -Lastly in this task, the ``set_fact`` option sets the following ``interfaces`` fact for the device based on the now-structured data returned from ``cli_parse``: - -.. code-block:: yaml - - Ethernet1/1: - hardware: 100/1000/10000 Ethernet - mac_address: 5254.005a.f8bd - name: Ethernet1/1 - state: - admin: up - operating: up - Ethernet1/10: - hardware: 100/1000/10000 Ethernet - mac_address: 5254.005a.f8c6 - <...> - - -Linux example -^^^^^^^^^^^^^ - -You can also use the native parser to run commands and parse output from Linux hosts. - -The output of a sample Linux command (``ip addr show``) looks as follows: - -.. code-block:: bash - - 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 - link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 - inet 127.0.0.1/8 scope host lo - valid_lft forever preferred_lft forever - inet6 ::1/128 scope host - valid_lft forever preferred_lft forever - 2: enp0s31f6: mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 - link/ether x2:6a:64:9d:84:19 brd ff:ff:ff:ff:ff:ff - 3: wlp2s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 - link/ether x6:c2:44:f7:41:e0 brd ff:ff:ff:ff:ff:ff permaddr d8:f2:ca:99:5c:82 - -Create the native template to match this output and store it as ``templates/fedora_ip_addr_show.yaml``: - -.. code-block:: yaml - - --- - - example: '1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000' - getval: | - (?x) # free-spacing - \d+:\s # the interface index - (?P\S+):\s # the name - <(?P\S+)> # the properties - \smtu\s(?P\d+) # the mtu - .* # gunk - state\s(?P\S+) # the state of the interface - result: - "{{ name }}": - name: "{{ name }}" - loopback: "{{ 'LOOPBACK' in stats.split(',') }}" - up: "{{ 'UP' in properties.split(',') }}" - carrier: "{{ not 'NO-CARRIER' in properties.split(',') }}" - broadcast: "{{ 'BROADCAST' in properties.split(',') }}" - multicast: "{{ 'MULTICAST' in properties.split(',') }}" - state: "{{ state|lower() }}" - mtu: "{{ mtu }}" - shared: True - - - example: 'inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0' - getval: | - (?x) # free-spacing - \s+inet\s(?P([0-9]{1,3}\.){3}[0-9]{1,3}) # the ip address - /(?P\d{1,2}) # the mask bits - result: - "{{ name }}": - ip_address: "{{ inet }}" - mask_bits: "{{ bits }}" - -.. note:: - - The ``shared`` key in the parser template allows the interface name to be used in subsequent parser entries. The use of examples and free-spacing mode with the regular expressions makes the template easier to read. - -The following example task uses ``cli_parse`` with the native parser and the example template above to parse the Linux output: - -.. code-block:: yaml - - - name: Run command and parse - ansible.utils.cli_parse: - command: ip addr show - parser: - name: ansible.netcommon.native - set_fact: interfaces - -This task assumes you previously gathered facts to determine the ``ansible_distribution`` needed to locate the template. Alternately, you could provide the path in the ``parser/template_path`` option. - - -Lastly in this task, the ``set_fact`` option sets the following ``interfaces`` fact for the host, based on the now-structured data returned from ``cli_parse``: - -.. code-block:: yaml - - lo: - broadcast: false - carrier: true - ip_address: 127.0.0.1 - mask_bits: 8 - mtu: 65536 - multicast: false - name: lo - state: unknown - up: true - enp64s0u1: - broadcast: true - carrier: true - ip_address: 192.168.86.83 - mask_bits: 24 - mtu: 1500 - multicast: true - name: enp64s0u1 - state: up - up: true - <...> - - -Parsing JSON -------------- - -Although Ansible will natively convert serialized JSON to Ansible native data when recognized, you can also use the ``cli_parse`` module for this conversion. - -Example task: - -.. code-block:: yaml - - - name: "Run command and parse as json" - ansible.utils.cli_parse: - command: show interface | json - parser: - name: ansible.utils.json - register: interfaces - -Taking a deeper dive into this task: - -- The ``show interface | json`` command is issued on the device. -- The output is set as the ``interfaces`` fact for the device. -- JSON support is provided primarily for playbook consistency. - -.. note:: - - The use of ``ansible.netcommon.json`` is fully supported with a Red Hat Ansible Automation Platform subscription - -Parsing with ntc_templates ----------------------------- - -The ``ntc_templates`` python library includes pre-defined ``textfsm`` templates for parsing a variety of network device commands output. - -Example task: - -.. code-block:: yaml - - - name: "Run command and parse with ntc_templates" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.netcommon.ntc_templates - set_fact: interfaces - -Taking a deeper dive into this task: - -- The ``ansible_network_os`` of the device is converted to the ntc_template format ``cisco_nxos``. Alternately, you can provide the ``os`` with the ``parser/os`` option instead. -- The ``cisco_nxos_show_interface.textfsm`` template, included with the ``ntc_templates`` package, parses the output. -- See `the ntc_templates README `_ for additional information about the ``ntc_templates`` python library. - -.. note:: - - Red Hat Ansible Automation Platform subscription support is limited to the use of the ``ntc_templates`` public APIs as documented. - - -This task and and the predefined template sets the following fact as the ``interfaces`` fact for the host: - -.. code-block:: yaml - - interfaces: - - address: 5254.005a.f8b5 - admin_state: up - bandwidth: 1000000 Kbit - bia: 5254.005a.f8b5 - delay: 10 usec - description: '' - duplex: full-duplex - encapsulation: ARPA - hardware_type: Ethernet - input_errors: '' - input_packets: '' - interface: mgmt0 - ip_address: 192.168.101.14/24 - last_link_flapped: '' - link_status: up - mode: '' - mtu: '1500' - output_errors: '' - output_packets: '' - speed: 1000 Mb/s - - address: 5254.005a.f8bd - admin_state: up - bandwidth: 1000000 Kbit - bia: 5254.005a.f8bd - delay: 10 usec - - -Parsing with pyATS ----------------------- - -``pyATS`` is part of the Cisco Test Automation & Validation Solution. It includes many predefined parsers for a number of network platforms and commands. You can use the predefined parsers that are part of the ``pyATS`` package with the ``cli_parse`` module. - -Example task: - -.. code-block:: yaml - - - name: "Run command and parse with pyats" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.netcommon.pyats - set_fact: interfaces - - -Taking a deeper dive into this task: - -- The ``cli_parse`` modules converts the ``ansible_network_os`` automatically (in this example, ``ansible_network_os`` set to ``cisco.nxos.nxos``, converts to ``nxos`` for pyATS. Alternately, you can set the OS with the ``parser/os`` option instead. -- Using a combination of the command and OS, the pyATS selects the following parser: https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/parsers/show%2520interface. -- The ``cli_parse`` module sets ``cisco.ios.ios`` to ``iosxe`` for pyATS. You can override this with the ``parser/os`` option. -- ``cli_parse`` only uses the predefined parsers in pyATS. See the `pyATS documentation `_ and the full list of `pyATS included parsers `_. - -.. note:: - - Red Hat Ansible Automation Platform subscription support is limited to the use of the pyATS public APIs as documented. - - -This task sets the following fact as the ``interfaces`` fact for the host: - -.. code-block:: yaml - - mgmt0: - admin_state: up - auto_mdix: 'off' - auto_negotiate: true - bandwidth: 1000000 - counters: - in_broadcast_pkts: 3 - in_multicast_pkts: 1652395 - in_octets: 556155103 - in_pkts: 2236713 - in_unicast_pkts: 584259 - rate: - in_rate: 320 - in_rate_pkts: 0 - load_interval: 1 - out_rate: 48 - out_rate_pkts: 0 - rx: true - tx: true - delay: 10 - duplex_mode: full - enabled: true - encapsulations: - encapsulation: arpa - ethertype: '0x0000' - ipv4: - 192.168.101.14/24: - ip: 192.168.101.14 - prefix_length: '24' - link_state: up - <...> - - -Parsing with textfsm ---------------------- - -``textfsm`` is a Python module which implements a template-based state machine for parsing semi-formatted text. - -The following sample ``textfsm`` template is stored as ``templates/nxos_show_interface.textfsm`` - -.. code-block:: text - - - Value Required INTERFACE (\S+) - Value LINK_STATUS (.+?) - Value ADMIN_STATE (.+?) - Value HARDWARE_TYPE (.\*) - Value ADDRESS ([a-zA-Z0-9]+.[a-zA-Z0-9]+.[a-zA-Z0-9]+) - Value BIA ([a-zA-Z0-9]+.[a-zA-Z0-9]+.[a-zA-Z0-9]+) - Value DESCRIPTION (.\*) - Value IP_ADDRESS (\d+\.\d+\.\d+\.\d+\/\d+) - Value MTU (\d+) - Value MODE (\S+) - Value DUPLEX (.+duplex?) - Value SPEED (.+?) - Value INPUT_PACKETS (\d+) - Value OUTPUT_PACKETS (\d+) - Value INPUT_ERRORS (\d+) - Value OUTPUT_ERRORS (\d+) - Value BANDWIDTH (\d+\s+\w+) - Value DELAY (\d+\s+\w+) - Value ENCAPSULATION (\w+) - Value LAST_LINK_FLAPPED (.+?) - - Start - ^\S+\s+is.+ -> Continue.Record - ^${INTERFACE}\s+is\s+${LINK_STATUS},\sline\sprotocol\sis\s${ADMIN_STATE}$$ - ^${INTERFACE}\s+is\s+${LINK_STATUS}$$ - ^admin\s+state\s+is\s+${ADMIN_STATE}, - ^\s+Hardware(:|\s+is)\s+${HARDWARE_TYPE},\s+address(:|\s+is)\s+${ADDRESS}(.*bia\s+${BIA})* - ^\s+Description:\s+${DESCRIPTION} - ^\s+Internet\s+Address\s+is\s+${IP_ADDRESS} - ^\s+Port\s+mode\s+is\s+${MODE} - ^\s+${DUPLEX}, ${SPEED}(,|$$) - ^\s+MTU\s+${MTU}.\*BW\s+${BANDWIDTH}.\*DLY\s+${DELAY} - ^\s+Encapsulation\s+${ENCAPSULATION} - ^\s+${INPUT_PACKETS}\s+input\s+packets\s+\d+\s+bytes\s\*$$ - ^\s+${INPUT_ERRORS}\s+input\s+error\s+\d+\s+short\s+frame\s+\d+\s+overrun\s+\d+\s+underrun\s+\d+\s+ignored\s\*$$ - ^\s+${OUTPUT_PACKETS}\s+output\s+packets\s+\d+\s+bytes\s\*$$ - ^\s+${OUTPUT_ERRORS}\s+output\s+error\s+\d+\s+collision\s+\d+\s+deferred\s+\d+\s+late\s+collision\s\*$$ - ^\s+Last\s+link\s+flapped\s+${LAST_LINK_FLAPPED}\s\*$$ - -The following task uses the example template for ``textfsm`` with the ``cli_parse`` module. - -.. code-block:: yaml - - - name: "Run command and parse with textfsm" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.utils.textfsm - set_fact: interfaces - -Taking a deeper dive into this task: - -- The ``ansible_network_os`` for the device (``cisco.nxos.nxos``) is converted to ``nxos``. Alternately you can provide the OS in the ``parser/os`` option instead. -- The textfsm template name defaulted to ``templates/nxos_show_interface.textfsm`` using a combination of the OS and command run. Alternately you can override the generated template path with the ``parser/template_path`` option. -- See the `textfsm README `_ for details. -- ``textfsm`` was previously made available as a filter plugin. Ansible users should transition to the ``cli_parse`` module. - -.. note:: - - Red Hat Ansible Automation Platform subscription support is limited to the use of the ``textfsm`` public APIs as documented. - -This task sets the following fact as the ``interfaces`` fact for the host: - -.. code-block:: yaml - - - ADDRESS: X254.005a.f8b5 - ADMIN_STATE: up - BANDWIDTH: 1000000 Kbit - BIA: X254.005a.f8b5 - DELAY: 10 usec - DESCRIPTION: '' - DUPLEX: full-duplex - ENCAPSULATION: ARPA - HARDWARE_TYPE: Ethernet - INPUT_ERRORS: '' - INPUT_PACKETS: '' - INTERFACE: mgmt0 - IP_ADDRESS: 192.168.101.14/24 - LAST_LINK_FLAPPED: '' - LINK_STATUS: up - MODE: '' - MTU: '1500' - OUTPUT_ERRORS: '' - OUTPUT_PACKETS: '' - SPEED: 1000 Mb/s - - ADDRESS: X254.005a.f8bd - ADMIN_STATE: up - BANDWIDTH: 1000000 Kbit - BIA: X254.005a.f8bd - - -Parsing with TTP ------------------ - -TTP is a Python library for semi-structured text parsing using templates. TTP uses a jinja-like syntax to limit the need for regular expressions. Users familiar with jinja templating may find the TTP template syntax familiar. - -The following is an example TTP template stored as ``templates/nxos_show_interface.ttp``: - -.. code-block:: jinja - - {{ interface }} is {{ state }} - admin state is {{ admin_state }}{{ ignore(".\*") }} - -The following task uses this template to parse the ``show interface`` command output: - -.. code-block:: yaml - - - name: "Run command and parse with ttp" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.utils.ttp - set_fact: interfaces - -Taking a deeper dive in this task: - -- The default template path ``templates/nxos_show_interface.ttp`` was generated using the ``ansible_network_os`` for the host and ``command`` provided. -- TTP supports several additional variables that will be passed to the parser. These include: - - - ``parser/vars/ttp_init`` - Additional parameter passed when the parser is initialized. - - ``parser/vars/ttp_results`` - Additional parameters used to influence the parser output. - - ``parser/vars/ttp_vars`` - Additional variables made available in the template. - -- See the `TTP documentation `_ for details. - - -The task sets the follow fact as the ``interfaces`` fact for the host: - -.. code-block:: yaml - - - admin_state: up, - interface: mgmt0 - state: up - - admin_state: up, - interface: Ethernet1/1 - state: up - - admin_state: up, - interface: Ethernet1/2 - state: up - - -Parsing with JC ------------------ - -JC is a python library that converts the output of dozens of common Linux/UNIX/macOS/Windows command-line tools and file types to python dictionaries or lists of dictionaries for easier parsing. JC is available as a filter plugin in the ``community.general`` collection. - -The following is an example using JC to parse the output of the ``dig`` command: - -.. code-block:: yaml - - - name: "Run dig command and parse with jc" - hosts: ubuntu - tasks: - - shell: dig example.com - register: result - - set_fact: - myvar: "{{ result.stdout | community.general.jc('dig') }}" - - debug: - msg: "The IP is: {{ myvar[0].answer[0].data }}" - -- The JC project and documentation can be found `here `_. -- See this `blog entry `_ for more information. - - -Converting XML ------------------ - -Although Ansible contains a number of plugins that can convert XML to Ansible native data structures, the ``cli_parse`` module runs the command on devices that return XML and returns the converted data in a single task. - -This example task runs the ``show interface`` command and parses the output as XML: - -.. code-block:: yaml - - - name: "Run command and parse as xml" - ansible.utils.cli_parse: - command: show interface | xml - parser: - name: ansible.utils.xml - set_fact: interfaces - -.. note:: - - Red Hat Ansible Automation Platform subscription support is limited to the use of the ``xmltodict`` public APIs as documented. - -This task sets the ``interfaces`` fact for the host based on this returned output: - -.. code-block:: yaml - - nf:rpc-reply: - '@xmlns': http://www.cisco.com/nxos:1.0:if_manager - '@xmlns:nf': urn:ietf:params:xml:ns:netconf:base:1.0 - nf:data: - show: - interface: - __XML__OPT_Cmd_show_interface_quick: - __XML__OPT_Cmd_show_interface___readonly__: - __readonly__: - TABLE_interface: - ROW_interface: - - admin_state: up - encapsulation: ARPA - eth_autoneg: 'on' - eth_bia_addr: x254.005a.f8b5 - eth_bw: '1000000' - - -Advanced use cases -=================== - -The ``cli_parse`` module supports several features to support more complex uses cases. - -Provide a full template path ------------------------------ - -Use the ``template_path`` option to override the default template path in the task: - -.. code-block:: yaml - - - name: "Run command and parse with native" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.netcommon.native - template_path: /home/user/templates/filename.yaml - - -Provide command to parser different than the command run ------------------------------------------------------------ - -Use the ``command`` suboption for the ``parser`` to configure the command the parser expects if it is different from the command ``cli_parse`` runs: - -.. code-block:: yaml - - - name: "Run command and parse with native" - ansible.utils.cli_parse: - command: sho int - parser: - name: ansible.netcommon.native - command: show interface - -Provide a custom OS value --------------------------------- - -Use the ``os`` suboption to the parser to directly set the OS instead of using ``ansible_network_os`` or ``ansible_distribution`` to generate the template path or with the specified parser engine: - -.. code-block:: yaml - - - name: Use ios instead of iosxe for pyats - ansible.utils.cli_parse: - command: show something - parser: - name: ansible.netcommon.pyats - os: ios - - - name: Use linux instead of fedora from ansible_distribution - ansible.utils.cli_parse: - command: ps -ef - parser: - name: ansible.netcommon.native - os: linux - - -Parse existing text --------------------- - -Use the ``text`` option instead of ``command`` to parse text collected earlier in the playbook. - -.. code-block:: yaml - - # using /home/user/templates/filename.yaml - - name: "Parse text from previous task" - ansible.utils.cli_parse: - text: "{{ output['stdout'] }}" - parser: - name: ansible.netcommon.native - template_path: /home/user/templates/filename.yaml - - # using /home/user/templates/filename.yaml - - name: "Parse text from file" - ansible.utils.cli_parse: - text: "{{ lookup('file', 'path/to/file.txt') }}" - parser: - name: ansible.netcommon.native - template_path: /home/user/templates/filename.yaml - - # using templates/nxos_show_version.yaml - - name: "Parse text from previous task" - ansible.utils.cli_parse: - text: "{{ sho_version['stdout'] }}" - parser: - name: ansible.netcommon.native - os: nxos - command: show version - - -.. seealso:: - - * :ref:`develop_cli_parse_plugins` diff --git a/docs/docsite/rst/network/user_guide/faq.rst b/docs/docsite/rst/network/user_guide/faq.rst deleted file mode 100644 index cb43ac28fec..00000000000 --- a/docs/docsite/rst/network/user_guide/faq.rst +++ /dev/null @@ -1,76 +0,0 @@ -.. _network_faq: - -******************* -Ansible Network FAQ -******************* - -.. contents:: Topics - -.. _network_faq_performance: - -How can I improve performance for network playbooks? -==================================================== - -.. _network_faq_strategy_free: - -Consider ``strategy: free`` if you are running on multiple hosts ---------------------------------------------------------------------------------- - -The ``strategy`` plugin tells Ansible how to order multiple tasks on multiple hosts. :ref:`Strategy` is set at the playbook level. - -The default strategy is ``linear``. With strategy set to ``linear``, Ansible waits until the current task has run on all hosts before starting the next task on any host. Ansible may have forks free, but will not use them until all hosts have completed the current task. If each task in your playbook must succeed on all hosts before you run the next task, use the ``linear`` strategy. - -Using the ``free`` strategy, Ansible uses available forks to execute tasks on each host as quickly as possible. Even if an earlier task is still running on one host, Ansible executes later tasks on other hosts. The ``free`` strategy uses available forks more efficiently. If your playbook stalls on each task, waiting for one slow host, consider using ``strategy: free`` to boost overall performance. - -.. _network_faq_limit_show_running: - -Execute ``show running`` only if you absolutely must ---------------------------------------------------------------------------------- - -The ``show running`` command is the most resource-intensive command to execute on a network device, because of the way queries are handled by the network OS. Using the command in your Ansible playbook will slow performance significantly, especially on large devices; repeating it will multiply the performance hit. If you have a playbook that checks the running config, then executes changes, then checks the running config again, you should expect that playbook to be very slow. - -.. _network_faq_limit_ProxyCommand: - -Use ``ProxyCommand`` only if you absolutely must ---------------------------------------------------------------------------------- - -Network modules support the use of a :ref:`proxy or jump host` with the ``ProxyCommand`` parameter. However, when you use a jump host, Ansible must open a new SSH connection for every task, even if you are using a persistent connection type (``network_cli`` or ``netconf``). To maximize the performance benefits of the persistent connection types introduced in version 2.5, avoid using jump hosts whenever possible. - -.. _network_faq_set_forks: - -Set ``--forks`` to match your needs ---------------------------------------------------------------------------------- - -Every time Ansible runs a task, it forks its own process. The ``--forks`` parameter defines the number of concurrent tasks - if you retain the default setting, which is ``--forks=5``, and you are running a playbook on 10 hosts, five of those hosts will have to wait until a fork is available. Of course, the more forks you allow, the more memory and processing power Ansible will use. Since most network tasks are run on the control host, this means your laptop can quickly become cpu- or memory-bound. - -.. _network_faq_redacted_output: - -Why is my output sometimes replaced with ``********``? -====================================================== - -Ansible replaces any string marked ``no_log``, including passwords, with ``********`` in Ansible output. This is done by design, to protect your sensitive data. Most users are happy to have their passwords redacted. However, Ansible replaces every string that matches your password with ``********``. If you use a common word for your password, this can be a problem. For example, if you choose ``Admin`` as your password, Ansible will replace every instance of the word ``Admin`` with ``********`` in your output. This may make your output harder to read. To avoid this problem, select a secure password that will not occur elsewhere in your Ansible output. - -.. _network_faq_no_abbreviations_with_config: - -Why do the ``*_config`` modules always return ``changed=true`` with abbreviated commands? -========================================================================================= - -When you issue commands directly on a network device, you can use abbreviated commands. For example, ``int g1/0/11`` and ``interface GigabitEthernet1/0/11`` do the same thing; ``shut`` and ``shutdown`` do the same thing. Ansible Network ``*_command`` modules work with abbreviations, because they run commands through the network OS. - -When committing configuration, however, the network OS converts abbreviations into long-form commands. Whether you use ``shut`` or ``shutdown`` on ``GigabitEthernet1/0/11``, the result in the configuration is the same: ``shutdown``. - -Ansible Network ``*_config`` modules compare the text of the commands you specify in ``lines`` to the text in the configuration. If you use ``shut`` in the ``lines`` section of your task, and the configuration reads ``shutdown``, the module returns ``changed=true`` even though the configuration is already correct. Your task will update the configuration every time it runs. - -To avoid this problem, use long-form commands with the ``*_config`` modules: - - -.. code-block:: yaml - - --- - - hosts: all - gather_facts: no - tasks: - - cisco.ios.ios_config: - lines: - - shutdown - parents: interface GigabitEthernet1/0/11 diff --git a/docs/docsite/rst/network/user_guide/index.rst b/docs/docsite/rst/network/user_guide/index.rst deleted file mode 100644 index 306a62704df..00000000000 --- a/docs/docsite/rst/network/user_guide/index.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _network_advanced: - -********************************** -Network Advanced Topics -********************************** - -Once you have mastered the basics of network automation with Ansible, as presented in :ref:`network_getting_started`, use this guide understand platform-specific details, optimization, and troubleshooting tips for Ansible for network automation. - -**Who should use this guide?** - -This guide is intended for network engineers using Ansible for automation. It covers advanced topics. If you understand networks and Ansible, this guide is for you. You may read through the entire guide if you choose, or use the links below to find the specific information you need. - -If you're new to Ansible, or new to using Ansible for network automation, start with the :ref:`network_getting_started`. - -.. toctree:: - :maxdepth: 2 - :caption: Advanced Topics - - network_resource_modules - network_best_practices_2.5 - cli_parsing - validate - network_debug_troubleshooting - network_working_with_command_output - faq - platform_index diff --git a/docs/docsite/rst/network/user_guide/network_best_practices_2.5.rst b/docs/docsite/rst/network/user_guide/network_best_practices_2.5.rst deleted file mode 100644 index 4b236ce6c84..00000000000 --- a/docs/docsite/rst/network/user_guide/network_best_practices_2.5.rst +++ /dev/null @@ -1,483 +0,0 @@ -.. _network-best-practices: - -************************ -Ansible Network Examples -************************ - -This document describes some examples of using Ansible to manage your network infrastructure. - -.. contents:: - :local: - -Prerequisites -============= - -This example requires the following: - -* **Ansible 2.10** (or higher) installed. See :ref:`intro_installation_guide` for more information. -* One or more network devices that are compatible with Ansible. -* Basic understanding of YAML :ref:`yaml_syntax`. -* Basic understanding of Jinja2 templates. See :ref:`playbooks_templating` for more information. -* Basic Linux command line use. -* Basic knowledge of network switch & router configurations. - - -Groups and variables in an inventory file -========================================= - -An ``inventory`` file is a YAML or INI-like configuration file that defines the mapping of hosts into groups. - -In our example, the inventory file defines the groups ``eos``, ``ios``, ``vyos`` and a "group of groups" called ``switches``. Further details about subgroups and inventory files can be found in the :ref:`Ansible inventory Group documentation `. - -Because Ansible is a flexible tool, there are a number of ways to specify connection information and credentials. We recommend using the ``[my_group:vars]`` capability in your inventory file. - -.. code-block:: ini - - [all:vars] - # these defaults can be overridden for any group in the [group:vars] section - ansible_connection=ansible.netcommon.network_cli - ansible_user=ansible - - [switches:children] - eos - ios - vyos - - [eos] - veos01 ansible_host=veos-01.example.net - veos02 ansible_host=veos-02.example.net - veos03 ansible_host=veos-03.example.net - veos04 ansible_host=veos-04.example.net - - [eos:vars] - ansible_become=yes - ansible_become_method=enable - ansible_network_os=arista.eos.eos - ansible_user=my_eos_user - ansible_password=my_eos_password - - [ios] - ios01 ansible_host=ios-01.example.net - ios02 ansible_host=ios-02.example.net - ios03 ansible_host=ios-03.example.net - - [ios:vars] - ansible_become=yes - ansible_become_method=enable - ansible_network_os=cisco.ios.ios - ansible_user=my_ios_user - ansible_password=my_ios_password - - [vyos] - vyos01 ansible_host=vyos-01.example.net - vyos02 ansible_host=vyos-02.example.net - vyos03 ansible_host=vyos-03.example.net - - [vyos:vars] - ansible_network_os=vyos.vyos.vyos - ansible_user=my_vyos_user - ansible_password=my_vyos_password - -If you use ssh-agent, you do not need the ``ansible_password`` lines. If you use ssh keys, but not ssh-agent, and you have multiple keys, specify the key to use for each connection in the ``[group:vars]`` section with ``ansible_ssh_private_key_file=/path/to/correct/key``. For more information on ``ansible_ssh_`` options see :ref:`behavioral_parameters`. - -.. FIXME FUTURE Gundalow - Link to network auth & proxy page (to be written) - -.. warning:: Never store passwords in plain text. - -Ansible vault for password encryption -------------------------------------- - -The "Vault" feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See :ref:`playbooks_vault` for more information. - -Here's what it would look like if you specified your SSH passwords (encrypted with Ansible Vault) among your variables: - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - ansible_ssh_pass: !vault | - $ANSIBLE_VAULT;1.1;AES256 - 39336231636137663964343966653162353431333566633762393034646462353062633264303765 - 6331643066663534383564343537343334633031656538370a333737656236393835383863306466 - 62633364653238323333633337313163616566383836643030336631333431623631396364663533 - 3665626431626532630a353564323566316162613432373738333064366130303637616239396438 - 9853 - -Common inventory variables --------------------------- - -The following variables are common for all platforms in the inventory, though they can be overwritten for a particular inventory group or host. - -:ansible_connection: - - Ansible uses the ansible-connection setting to determine how to connect to a remote device. When working with Ansible Networking, set this to an appropriate network connection option, such as``ansible.netcommon.network_cli``, so Ansible treats the remote node as a network device with a limited execution environment. Without this setting, Ansible would attempt to use ssh to connect to the remote and execute the Python script on the network device, which would fail because Python generally isn't available on network devices. -:ansible_network_os: - Informs Ansible which Network platform this hosts corresponds to. This is required when using the ``ansible.netcommon.*`` connection options. -:ansible_user: The user to connect to the remote device (switch) as. Without this the user that is running ``ansible-playbook`` would be used. - Specifies which user on the network device the connection -:ansible_password: - The corresponding password for ``ansible_user`` to log in as. If not specified SSH key will be used. -:ansible_become: - If enable mode (privilege mode) should be used, see the next section. -:ansible_become_method: - Which type of `become` should be used, for ``network_cli`` the only valid choice is ``enable``. - -Privilege escalation --------------------- - -Certain network platforms, such as Arista EOS and Cisco IOS, have the concept of different privilege modes. Certain network modules, such as those that modify system state including users, will only work in high privilege states. Ansible supports ``become`` when using ``connection: ansible.netcommon.network_cli``. This allows privileges to be raised for the specific tasks that need them. Adding ``become: yes`` and ``become_method: enable`` informs Ansible to go into privilege mode before executing the task, as shown here: - -.. code-block:: ini - - [eos:vars] - ansible_connection=ansible.netcommon.network_cli - ansible_network_os=arista.eos.eos - ansible_become=yes - ansible_become_method=enable - -For more information, see the :ref:`using become with network modules` guide. - - -Jump hosts ----------- - -If the Ansible Controller does not have a direct route to the remote device and you need to use a Jump Host, please see the :ref:`Ansible Network Proxy Command ` guide for details on how to achieve this. - -Example 1: collecting facts and creating backup files with a playbook -===================================================================== - -Ansible facts modules gather system information 'facts' that are available to the rest of your playbook. - -Ansible Networking ships with a number of network-specific facts modules. In this example, we use the ``_facts`` modules :ref:`arista.eos.eos_facts `, :ref:`cisco.ios.ios_facts ` and :ref:`vyos.vyos.vyos_facts ` to connect to the remote networking device. As the credentials are not explicitly passed with module arguments, Ansible uses the username and password from the inventory file. - -Ansible's "Network Fact modules" gather information from the system and store the results in facts prefixed with ``ansible_net_``. The data collected by these modules is documented in the `Return Values` section of the module docs, in this case :ref:`arista.eos.eos_facts ` and :ref:`vyos.vyos.vyos_facts `. We can use the facts, such as ``ansible_net_version`` late on in the "Display some facts" task. - -To ensure we call the correct mode (``*_facts``) the task is conditionally run based on the group defined in the inventory file, for more information on the use of conditionals in Ansible Playbooks see :ref:`the_when_statement`. - -In this example, we will create an inventory file containing some network switches, then run a playbook to connect to the network devices and return some information about them. - -Step 1: Creating the inventory ------------------------------- - -First, create a file called ``inventory``, containing: - -.. code-block:: ini - - [switches:children] - eos - ios - vyos - - [eos] - eos01.example.net - - [ios] - ios01.example.net - - [vyos] - vyos01.example.net - - -Step 2: Creating the playbook ------------------------------ - -Next, create a playbook file called ``facts-demo.yml`` containing the following: - -.. code-block:: yaml - - - name: "Demonstrate connecting to switches" - hosts: switches - gather_facts: no - - tasks: - ### - # Collect data - # - - name: Gather facts (eos) - arista.eos.eos_facts: - when: ansible_network_os == 'arista.eos.eos' - - - name: Gather facts (ios) - cisco.ios.ios_facts: - when: ansible_network_os == 'cisco.ios.ios' - - - name: Gather facts (vyos) - vyos.vyos.vyos_facts: - when: ansible_network_os == 'vyos.vyos.vyos' - - ### - # Demonstrate variables - # - - name: Display some facts - debug: - msg: "The hostname is {{ ansible_net_hostname }} and the OS is {{ ansible_net_version }}" - - - name: Facts from a specific host - debug: - var: hostvars['vyos01.example.net'] - - - name: Write facts to disk using a template - copy: - content: | - #jinja2: lstrip_blocks: True - EOS device info: - {% for host in groups['eos'] %} - Hostname: {{ hostvars[host].ansible_net_hostname }} - Version: {{ hostvars[host].ansible_net_version }} - Model: {{ hostvars[host].ansible_net_model }} - Serial: {{ hostvars[host].ansible_net_serialnum }} - {% endfor %} - - IOS device info: - {% for host in groups['ios'] %} - Hostname: {{ hostvars[host].ansible_net_hostname }} - Version: {{ hostvars[host].ansible_net_version }} - Model: {{ hostvars[host].ansible_net_model }} - Serial: {{ hostvars[host].ansible_net_serialnum }} - {% endfor %} - - VyOS device info: - {% for host in groups['vyos'] %} - Hostname: {{ hostvars[host].ansible_net_hostname }} - Version: {{ hostvars[host].ansible_net_version }} - Model: {{ hostvars[host].ansible_net_model }} - Serial: {{ hostvars[host].ansible_net_serialnum }} - {% endfor %} - dest: /tmp/switch-facts - run_once: yes - - ### - # Get running configuration - # - - - name: Backup switch (eos) - arista.eos.eos_config: - backup: yes - register: backup_eos_location - when: ansible_network_os == 'arista.eos.eos' - - - name: backup switch (vyos) - vyos.vyos.vyos_config: - backup: yes - register: backup_vyos_location - when: ansible_network_os == 'vyos.vyos.vyos' - - - name: Create backup dir - file: - path: "/tmp/backups/{{ inventory_hostname }}" - state: directory - recurse: yes - - - name: Copy backup files into /tmp/backups/ (eos) - copy: - src: "{{ backup_eos_location.backup_path }}" - dest: "/tmp/backups/{{ inventory_hostname }}/{{ inventory_hostname }}.bck" - when: ansible_network_os == 'arista.eos.eos' - - - name: Copy backup files into /tmp/backups/ (vyos) - copy: - src: "{{ backup_vyos_location.backup_path }}" - dest: "/tmp/backups/{{ inventory_hostname }}/{{ inventory_hostname }}.bck" - when: ansible_network_os == 'vyos.vyos.vyos' - -Step 3: Running the playbook ----------------------------- - -To run the playbook, run the following from a console prompt: - -.. code-block:: console - - ansible-playbook -i inventory facts-demo.yml - -This should return output similar to the following: - -.. code-block:: console - - PLAY RECAP - eos01.example.net : ok=7 changed=2 unreachable=0 failed=0 - ios01.example.net : ok=7 changed=2 unreachable=0 failed=0 - vyos01.example.net : ok=6 changed=2 unreachable=0 failed=0 - -Step 4: Examining the playbook results --------------------------------------- - -Next, look at the contents of the file we created containing the switch facts: - -.. code-block:: console - - cat /tmp/switch-facts - -You can also look at the backup files: - -.. code-block:: console - - find /tmp/backups - - -If `ansible-playbook` fails, please follow the debug steps in :ref:`network_debug_troubleshooting`. - - -.. _network-independent-examples: - -Example 2: simplifying playbooks with platform-independent modules -================================================================== - -(This example originally appeared in the `Deep Dive on cli_command for Network Automation `_ blog post by Sean Cavanaugh -`@IPvSean `_). - -If you have two or more network platforms in your environment, you can use the platform-independent modules to simplify your playbooks. You can use platform-independent modules such as ``ansible.netcommon.cli_command`` or ``ansible.netcommon.cli_config`` in place of the platform-specific modules such as ``arista.eos.eos_config``, ``cisco.ios.ios_config``, and ``junipernetworks.junos.junos_config``. This reduces the number of tasks and conditionals you need in your playbooks. - -.. note:: - Platform-independent modules require the :ref:`ansible.netcommon.network_cli ` connection plugin. - - -Sample playbook with platform-specific modules ----------------------------------------------- - -This example assumes three platforms, Arista EOS, Cisco NXOS, and Juniper JunOS. Without the platform-independent modules, a sample playbook might contain the following three tasks with platform-specific commands: - -.. code-block:: yaml - - --- - - name: Run Arista command - arista.eos.eos_command: - commands: show ip int br - when: ansible_network_os == 'arista.eos.eos' - - - name: Run Cisco NXOS command - cisco.nxos.nxos_command: - commands: show ip int br - when: ansible_network_os == 'cisco.nxos.nxos' - - - name: Run Vyos command - vyos.vyos.vyos_command: - commands: show interface - when: ansible_network_os == 'vyos.vyos.vyos' - -Simplified playbook with ``cli_command`` platform-independent module --------------------------------------------------------------------- - -You can replace these platform-specific modules with the platform-independent ``ansible.netcommon.cli_command`` module as follows: - -.. code-block:: yaml - - --- - - hosts: network - gather_facts: false - connection: ansible.netcommon.network_cli - - tasks: - - name: Run cli_command on Arista and display results - block: - - name: Run cli_command on Arista - ansible.netcommon.cli_command: - command: show ip int br - register: result - - - name: Display result to terminal window - debug: - var: result.stdout_lines - when: ansible_network_os == 'arista.eos.eos' - - - name: Run cli_command on Cisco IOS and display results - block: - - name: Run cli_command on Cisco IOS - ansible.netcommon.cli_command: - command: show ip int br - register: result - - - name: Display result to terminal window - debug: - var: result.stdout_lines - when: ansible_network_os == 'cisco.ios.ios' - - - name: Run cli_command on Vyos and display results - block: - - name: Run cli_command on Vyos - ansible.netcommon.cli_command: - command: show interfaces - register: result - - - name: Display result to terminal window - debug: - var: result.stdout_lines - when: ansible_network_os == 'vyos.vyos.vyos' - - -If you use groups and group_vars by platform type, this playbook can be further simplified to : - -.. code-block:: yaml - - --- - - name: Run command and print to terminal window - hosts: routers - gather_facts: false - - tasks: - - name: Run show command - ansible.netcommon.cli_command: - command: "{{show_interfaces}}" - register: command_output - - -You can see a full example of this using group_vars and also a configuration backup example at `Platform-independent examples `_. - -Using multiple prompts with the ``ansible.netcommon.cli_command`` -------------------------------------------------------------------- - -The ``ansible.netcommon.cli_command`` also supports multiple prompts. - -.. code-block:: yaml - - --- - - name: Change password to default - ansible.netcommon.cli_command: - command: "{{ item }}" - prompt: - - "New password" - - "Retype new password" - answer: - - "mypassword123" - - "mypassword123" - check_all: True - loop: - - "configure" - - "rollback" - - "set system root-authentication plain-text-password" - - "commit" - -See the :ref:`ansible.netcommon.cli_command ` for full documentation on this command. - - -Implementation Notes -==================== - - -Demo variables --------------- - -Although these tasks are not needed to write data to disk, they are used in this example to demonstrate some methods of accessing facts about the given devices or a named host. - -Ansible ``hostvars`` allows you to access variables from a named host. Without this we would return the details for the current host, rather than the named host. - -For more information, see :ref:`magic_variables_and_hostvars`. - -Get running configuration -------------------------- - -The :ref:`arista.eos.eos_config ` and :ref:`vyos.vyos.vyos_config ` modules have a ``backup:`` option that when set will cause the module to create a full backup of the current ``running-config`` from the remote device before any changes are made. The backup file is written to the ``backup`` folder in the playbook root directory. If the directory does not exist, it is created. - -To demonstrate how we can move the backup file to a different location, we register the result and move the file to the path stored in ``backup_path``. - -Note that when using variables from tasks in this way we use double quotes (``"``) and double curly-brackets (``{{...}}`` to tell Ansible that this is a variable. - -Troubleshooting -=============== - -If you receive an connection error please double check the inventory and playbook for typos or missing lines. If the issue still occurs follow the debug steps in :ref:`network_debug_troubleshooting`. - -.. seealso:: - - * :ref:`network_guide` - * :ref:`intro_inventory` - * :ref:`Keeping vaulted variables visible ` diff --git a/docs/docsite/rst/network/user_guide/network_debug_troubleshooting.rst b/docs/docsite/rst/network/user_guide/network_debug_troubleshooting.rst deleted file mode 100644 index ce28e0bcf1b..00000000000 --- a/docs/docsite/rst/network/user_guide/network_debug_troubleshooting.rst +++ /dev/null @@ -1,840 +0,0 @@ -.. _network_debug_troubleshooting: - -*************************************** -Network Debug and Troubleshooting Guide -*************************************** - -This section discusses how to debug and troubleshoot network modules in Ansible. - -.. contents:: - :local: - - -How to troubleshoot -=================== - -Ansible network automation errors generally fall into one of the following categories: - -:Authentication issues: - * Not correctly specifying credentials - * Remote device (network switch/router) not falling back to other other authentication methods - * SSH key issues -:Timeout issues: - * Can occur when trying to pull a large amount of data - * May actually be masking a authentication issue -:Playbook issues: - * Use of ``delegate_to``, instead of ``ProxyCommand``. See :ref:`network proxy guide ` for more information. - -.. warning:: ``unable to open shell`` - - The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully - talk to the remote network device. This generally means that there is an authentication issue. See the "Authentication and connection issues" section - in this document for more information. - -.. _enable_network_logging: - -Enabling Networking logging and how to read the logfile -------------------------------------------------------- - -**Platforms:** Any - -Ansible includes logging to help diagnose and troubleshoot issues regarding Ansible Networking modules. - -Because logging is very verbose, it is disabled by default. It can be enabled with the :envvar:`ANSIBLE_LOG_PATH` and :envvar:`ANSIBLE_DEBUG` options on the ansible-controller, that is the machine running ``ansible-playbook``. - -Before running ``ansible-playbook``, run the following commands to enable logging: - -.. code:: shell - - # Specify the location for the log file - export ANSIBLE_LOG_PATH=~/ansible.log - # Enable Debug - export ANSIBLE_DEBUG=True - - # Run with 4*v for connection level verbosity - ansible-playbook -vvvv ... - -After Ansible has finished running you can inspect the log file which has been created on the ansible-controller: - -.. code:: - - less $ANSIBLE_LOG_PATH - - 2017-03-30 13:19:52,740 p=28990 u=fred | creating new control socket for host veos01:22 as user admin - 2017-03-30 13:19:52,741 p=28990 u=fred | control socket path is /home/fred/.ansible/pc/ca5960d27a - 2017-03-30 13:19:52,741 p=28990 u=fred | current working directory is /home/fred/ansible/test/integration - 2017-03-30 13:19:52,741 p=28990 u=fred | using connection plugin network_cli - ... - 2017-03-30 13:20:14,771 paramiko.transport userauth is OK - 2017-03-30 13:20:15,283 paramiko.transport Authentication (keyboard-interactive) successful! - 2017-03-30 13:20:15,302 p=28990 u=fred | ssh connection done, setting terminal - 2017-03-30 13:20:15,321 p=28990 u=fred | ssh connection has completed successfully - 2017-03-30 13:20:15,322 p=28990 u=fred | connection established to veos01 in 0:00:22.580626 - - -From the log notice: - -* ``p=28990`` Is the PID (Process ID) of the ``ansible-connection`` process -* ``u=fred`` Is the user `running` ansible, not the remote-user you are attempting to connect as -* ``creating new control socket for host veos01:22 as user admin`` host:port as user -* ``control socket path is`` location on disk where the persistent connection socket is created -* ``using connection plugin network_cli`` Informs you that persistent connection is being used -* ``connection established to veos01 in 0:00:22.580626`` Time taken to obtain a shell on the remote device - - -.. note:: Port None ``creating new control socket for host veos01:None`` - - If the log reports the port as ``None`` this means that the default port is being used. - A future Ansible release will improve this message so that the port is always logged. - -Because the log files are verbose, you can use grep to look for specific information. For example, once you have identified the ``pid`` from the ``creating new control socket for host`` line you can search for other connection log entries: - -.. code:: shell - - grep "p=28990" $ANSIBLE_LOG_PATH - - -Enabling Networking device interaction logging ----------------------------------------------- - -**Platforms:** Any - -Ansible includes logging of device interaction in the log file to help diagnose and troubleshoot -issues regarding Ansible Networking modules. The messages are logged in the file pointed to by the ``log_path`` configuration -option in the Ansible configuration file or by setting the :envvar:`ANSIBLE_LOG_PATH`. - -.. warning:: - The device interaction messages consist of command executed on the target device and the returned response. Since this - log data can contain sensitive information including passwords in plain text it is disabled by default. - Additionally, in order to prevent accidental leakage of data, a warning will be shown on every task with this - setting enabled, specifying which host has it enabled and where the data is being logged. - -Be sure to fully understand the security implications of enabling this option. The device interaction logging can be enabled either globally by setting in configuration file or by setting environment or enabled on per task basis by passing a special variable to the task. - -Before running ``ansible-playbook`` run the following commands to enable logging: - -.. code-block:: text - - # Specify the location for the log file - export ANSIBLE_LOG_PATH=~/ansible.log - - -Enable device interaction logging for a given task - -.. code-block:: yaml - - - name: get version information - cisco.ios.ios_command: - commands: - - show version - vars: - ansible_persistent_log_messages: True - - -To make this a global setting, add the following to your ``ansible.cfg`` file: - -.. code-block:: ini - - [persistent_connection] - log_messages = True - -or enable the environment variable `ANSIBLE_PERSISTENT_LOG_MESSAGES`: - -.. code-block:: text - - # Enable device interaction logging - export ANSIBLE_PERSISTENT_LOG_MESSAGES=True - -If the task is failing on connection initialization itself, you should enable this option -globally. If an individual task is failing intermittently this option can be enabled for that task itself to find the root cause. - -After Ansible has finished running you can inspect the log file which has been created on the ansible-controller - -.. note:: Be sure to fully understand the security implications of enabling this option as it can log sensitive - information in log file thus creating security vulnerability. - - -Isolating an error ------------------- - -**Platforms:** Any - -As with any effort to troubleshoot it's important to simplify the test case as much as possible. - -For Ansible this can be done by ensuring you are only running against one remote device: - -* Using ``ansible-playbook --limit switch1.example.net...`` -* Using an ad hoc ``ansible`` command - -`ad hoc` refers to running Ansible to perform some quick command using ``/usr/bin/ansible``, rather than the orchestration language, which is ``/usr/bin/ansible-playbook``. In this case we can ensure connectivity by attempting to execute a single command on the remote device: - -.. code-block:: text - - ansible -m arista.eos.eos_command -a 'commands=?' -i inventory switch1.example.net -e 'ansible_connection=ansible.netcommon.network_cli' -u admin -k - -In the above example, we: - -* connect to ``switch1.example.net`` specified in the inventory file ``inventory`` -* use the module ``arista.eos.eos_command`` -* run the command ``?`` -* connect using the username ``admin`` -* inform the ``ansible`` command to prompt for the SSH password by specifying ``-k`` - -If you have SSH keys configured correctly, you don't need to specify the ``-k`` parameter. - -If the connection still fails you can combine it with the enable_network_logging parameter. For example: - -.. code-block:: text - - # Specify the location for the log file - export ANSIBLE_LOG_PATH=~/ansible.log - # Enable Debug - export ANSIBLE_DEBUG=True - # Run with ``-vvvv`` for connection level verbosity - ansible -m arista.eos.eos_command -a 'commands=?' -i inventory switch1.example.net -e 'ansible_connection=ansible.netcommon.network_cli' -u admin -k - -Then review the log file and find the relevant error message in the rest of this document. - -.. For details on other ways to authenticate, see LINKTOAUTHHOWTODOCS. - -.. _socket_path_issue: - -Troubleshooting socket path issues -================================== - -**Platforms:** Any - -The ``Socket path does not exist or cannot be found`` and ``Unable to connect to socket`` messages indicate that the socket used to communicate with the remote network device is unavailable or does not exist. - -For example: - -.. code-block:: none - - fatal: [spine02]: FAILED! => { - "changed": false, - "failed": true, - "module_stderr": "Traceback (most recent call last):\n File \"/tmp/ansible_TSqk5J/ansible_modlib.zip/ansible/module_utils/connection.py\", line 115, in _exec_jsonrpc\nansible.module_utils.connection.ConnectionError: Socket path XX does not exist or cannot be found. See Troubleshooting socket path issues in the Network Debug and Troubleshooting Guide\n", - "module_stdout": "", - "msg": "MODULE FAILURE", - "rc": 1 - } - -or - -.. code-block:: none - - fatal: [spine02]: FAILED! => { - "changed": false, - "failed": true, - "module_stderr": "Traceback (most recent call last):\n File \"/tmp/ansible_TSqk5J/ansible_modlib.zip/ansible/module_utils/connection.py\", line 123, in _exec_jsonrpc\nansible.module_utils.connection.ConnectionError: Unable to connect to socket XX. See Troubleshooting socket path issues in Network Debug and Troubleshooting Guide\n", - "module_stdout": "", - "msg": "MODULE FAILURE", - "rc": 1 - } - -Suggestions to resolve: - -#. Verify that you have write access to the socket path described in the error message. - -#. Follow the steps detailed in :ref:`enable network logging `. - -If the identified error message from the log file is: - -.. code-block:: yaml - - 2017-04-04 12:19:05,670 p=18591 u=fred | command timeout triggered, timeout value is 30 secs - -or - -.. code-block:: yaml - - 2017-04-04 12:19:05,670 p=18591 u=fred | persistent connection idle timeout triggered, timeout value is 30 secs - -Follow the steps detailed in :ref:`timeout issues ` - - -.. _unable_to_open_shell: - -Category "Unable to open shell" -=============================== - - -**Platforms:** Any - -The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. It is a "catch all" message, meaning you need to enable :ref:`logging ` to find the underlying issues. - - - -For example: - -.. code-block:: none - - TASK [prepare_eos_tests : enable cli on remote device] ************************************************** - fatal: [veos01]: FAILED! => {"changed": false, "failed": true, "msg": "unable to open shell"} - - -or: - - -.. code-block:: none - - TASK [ios_system : configure name_servers] ************************************************************* - task path: - fatal: [ios-csr1000v]: FAILED! => { - "changed": false, - "failed": true, - "msg": "unable to open shell", - } - -Suggestions to resolve: - -Follow the steps detailed in enable_network_logging_. - -Once you've identified the error message from the log file, the specific solution can be found in the rest of this document. - - - -Error: "[Errno -2] Name or service not known" ---------------------------------------------- - -**Platforms:** Any - -Indicates that the remote host you are trying to connect to can not be reached - -For example: - -.. code-block:: yaml - - 2017-04-04 11:39:48,147 p=15299 u=fred | control socket path is /home/fred/.ansible/pc/ca5960d27a - 2017-04-04 11:39:48,147 p=15299 u=fred | current working directory is /home/fred/git/ansible-inc/stable-2.3/test/integration - 2017-04-04 11:39:48,147 p=15299 u=fred | using connection plugin network_cli - 2017-04-04 11:39:48,340 p=15299 u=fred | connecting to host veos01 returned an error - 2017-04-04 11:39:48,340 p=15299 u=fred | [Errno -2] Name or service not known - - -Suggestions to resolve: - -* If you are using the ``provider:`` options ensure that its suboption ``host:`` is set correctly. -* If you are not using ``provider:`` nor top-level arguments ensure your inventory file is correct. - - - - - -Error: "Authentication failed" ------------------------------- - -**Platforms:** Any - -Occurs if the credentials (username, passwords, or ssh keys) passed to ``ansible-connection`` (through ``ansible`` or ``ansible-playbook``) can not be used to connect to the remote device. - - - -For example: - -.. code-block:: yaml - - ESTABLISH CONNECTION FOR USER: cisco on PORT 22 TO ios01 - Authentication failed. - - -Suggestions to resolve: - -If you are specifying credentials through ``password:`` (either directly or through ``provider:``) or the environment variable `ANSIBLE_NET_PASSWORD` it is possible that ``paramiko`` (the Python SSH library that Ansible uses) is using ssh keys, and therefore the credentials you are specifying are being ignored. To find out if this is the case, disable "look for keys". This can be done like this: - -.. code-block:: yaml - - export ANSIBLE_PARAMIKO_LOOK_FOR_KEYS=False - -To make this a permanent change, add the following to your ``ansible.cfg`` file: - -.. code-block:: ini - - [paramiko_connection] - look_for_keys = False - - -Error: "connecting to host returned an error" or "Bad address" -------------------------------------------------------------------------- - -This may occur if the SSH fingerprint hasn't been added to Paramiko's (the Python SSH library) know hosts file. - -When using persistent connections with Paramiko, the connection runs in a background process. If the host doesn't already have a valid SSH key, by default Ansible will prompt to add the host key. This will cause connections running in background processes to fail. - -For example: - -.. code-block:: yaml - - 2017-04-04 12:06:03,486 p=17981 u=fred | using connection plugin network_cli - 2017-04-04 12:06:04,680 p=17981 u=fred | connecting to host veos01 returned an error - 2017-04-04 12:06:04,682 p=17981 u=fred | (14, 'Bad address') - 2017-04-04 12:06:33,519 p=17981 u=fred | number of connection attempts exceeded, unable to connect to control socket - 2017-04-04 12:06:33,520 p=17981 u=fred | persistent_connect_interval=1, persistent_connect_retries=30 - - -Suggestions to resolve: - -Use ``ssh-keyscan`` to pre-populate the known_hosts. You need to ensure the keys are correct. - -.. code-block:: shell - - ssh-keyscan veos01 - - -or - -You can tell Ansible to automatically accept the keys - -Environment variable method: - -.. code-block:: shell - - export ANSIBLE_PARAMIKO_HOST_KEY_AUTO_ADD=True - ansible-playbook ... - -``ansible.cfg`` method: - -ansible.cfg - -.. code-block:: ini - - [paramiko_connection] - host_key_auto_add = True - - - -.. warning: Security warning - - Care should be taken before accepting keys. - -Error: "No authentication methods available" --------------------------------------------- - -For example: - -.. code-block:: yaml - - 2017-04-04 12:19:05,670 p=18591 u=fred | creating new control socket for host veos01:None as user admin - 2017-04-04 12:19:05,670 p=18591 u=fred | control socket path is /home/fred/.ansible/pc/ca5960d27a - 2017-04-04 12:19:05,670 p=18591 u=fred | current working directory is /home/fred/git/ansible-inc/ansible-workspace-2/test/integration - 2017-04-04 12:19:05,670 p=18591 u=fred | using connection plugin network_cli - 2017-04-04 12:19:06,606 p=18591 u=fred | connecting to host veos01 returned an error - 2017-04-04 12:19:06,606 p=18591 u=fred | No authentication methods available - 2017-04-04 12:19:35,708 p=18591 u=fred | connect retry timeout expired, unable to connect to control socket - 2017-04-04 12:19:35,709 p=18591 u=fred | persistent_connect_retry_timeout is 15 secs - - -Suggestions to resolve: - -No password or SSH key supplied - -Clearing Out Persistent Connections ------------------------------------ - -**Platforms:** Any - -In Ansible 2.3, persistent connection sockets are stored in ``~/.ansible/pc`` for all network devices. When an Ansible playbook runs, the persistent socket connection is displayed when verbose output is specified. - -`` socket_path: /home/fred/.ansible/pc/f64ddfa760`` - -To clear out a persistent connection before it times out (the default timeout is 30 seconds -of inactivity), simple delete the socket file. - - -.. _timeout_issues: - -Timeout issues -============== - -Persistent connection idle timeout ----------------------------------- - -By default, ``ANSIBLE_PERSISTENT_CONNECT_TIMEOUT`` is set to 30 (seconds). You may see the following error if this value is too low: - -.. code-block:: yaml - - 2017-04-04 12:19:05,670 p=18591 u=fred | persistent connection idle timeout triggered, timeout value is 30 secs - -Suggestions to resolve: - -Increase value of persistent connection idle timeout: - -.. code-block:: sh - - export ANSIBLE_PERSISTENT_CONNECT_TIMEOUT=60 - -To make this a permanent change, add the following to your ``ansible.cfg`` file: - -.. code-block:: ini - - [persistent_connection] - connect_timeout = 60 - -Command timeout ---------------- - -By default, ``ANSIBLE_PERSISTENT_COMMAND_TIMEOUT`` is set to 30 (seconds). Prior versions of Ansible had this value set to 10 seconds by default. -You may see the following error if this value is too low: - - -.. code-block:: yaml - - 2017-04-04 12:19:05,670 p=18591 u=fred | command timeout triggered, timeout value is 30 secs - -Suggestions to resolve: - -* Option 1 (Global command timeout setting): - Increase value of command timeout in configuration file or by setting environment variable. - - .. code-block:: yaml - - export ANSIBLE_PERSISTENT_COMMAND_TIMEOUT=60 - - To make this a permanent change, add the following to your ``ansible.cfg`` file: - - .. code-block:: ini - - [persistent_connection] - command_timeout = 60 - -* Option 2 (Per task command timeout setting): - Increase command timeout per task basis. All network modules support a - timeout value that can be set on a per task basis. - The timeout value controls the amount of time in seconds before the - task will fail if the command has not returned. - - For local connection type: - - .. FIXME: Detail error here - - Suggestions to resolve: - - Some modules support a ``timeout`` option, which is different to the ``timeout`` keyword for tasks. - - .. code-block:: yaml - - - name: save running-config - cisco.ios.ios_command: - commands: copy running-config startup-config - provider: "{{ cli }}" - timeout: 30 - - - Suggestions to resolve: - - If the module does not support the ``timeout`` option directly, most networking connection plugins can enable similar functionality with the ``ansible_command_timeout`` variable. - - .. code-block:: yaml - - - name: save running-config - cisco.ios.ios_command: - commands: copy running-config startup-config - vars: - ansible_command_timeout: 60 - -Some operations take longer than the default 30 seconds to complete. One good -example is saving the current running config on IOS devices to startup config. -In this case, changing the timeout value from the default 30 seconds to 60 -seconds will prevent the task from failing before the command completes -successfully. - -Persistent connection retry timeout ------------------------------------ - -By default, ``ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT`` is set to 15 (seconds). You may see the following error if this value is too low: - -.. code-block:: yaml - - 2017-04-04 12:19:35,708 p=18591 u=fred | connect retry timeout expired, unable to connect to control socket - 2017-04-04 12:19:35,709 p=18591 u=fred | persistent_connect_retry_timeout is 15 secs - -Suggestions to resolve: - -Increase the value of the persistent connection idle timeout. -Note: This value should be greater than the SSH timeout value (the timeout value under the defaults -section in the configuration file) and less than the value of the persistent -connection idle timeout (connect_timeout). - -.. code-block:: yaml - - export ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT=30 - -To make this a permanent change, add the following to your ``ansible.cfg`` file: - -.. code-block:: ini - - [persistent_connection] - connect_retry_timeout = 30 - - -Timeout issue due to platform specific login menu with ``network_cli`` connection type --------------------------------------------------------------------------------------- - -In Ansible 2.9 and later, the network_cli connection plugin configuration options are added -to handle the platform specific login menu. These options can be set as group/host or tasks -variables. - -Example: Handle single login menu prompts with host variables - -.. code-block:: console - - $cat host_vars/.yaml - --- - ansible_terminal_initial_prompt: - - "Connect to a host" - ansible_terminal_initial_answer: - - "3" - -Example: Handle remote host multiple login menu prompts with host variables - -.. code-block:: console - - $cat host_vars/.yaml - --- - ansible_terminal_initial_prompt: - - "Press any key to enter main menu" - - "Connect to a host" - ansible_terminal_initial_answer: - - "\\r" - - "3" - ansible_terminal_initial_prompt_checkall: True - -To handle multiple login menu prompts: - -* The values of ``ansible_terminal_initial_prompt`` and ``ansible_terminal_initial_answer`` should be a list. -* The prompt sequence should match the answer sequence. -* The value of ``ansible_terminal_initial_prompt_checkall`` should be set to ``True``. - -.. note:: If all the prompts in sequence are not received from remote host at the time connection initialization it will result in a timeout. - - -Playbook issues -=============== - -This section details issues are caused by issues with the Playbook itself. - -Error: "Unable to enter configuration mode" -------------------------------------------- - -**Platforms:** Arista EOS and Cisco IOS - -This occurs when you attempt to run a task that requires privileged mode in a user mode shell. - -For example: - -.. code-block:: console - - TASK [ios_system : configure name_servers] ***************************************************************************** - task path: - fatal: [ios-csr1000v]: FAILED! => { - "changed": false, - "failed": true, - "msg": "unable to enter configuration mode", - } - -Suggestions to resolve: - - Use ``connection: ansible.netcommon.network_cli`` and ``become: true`` - - -Proxy Issues -============ - - .. _network_delegate_to_vs_ProxyCommand: - -delegate_to vs ProxyCommand ---------------------------- - -In order to use a bastion or intermediate jump host to connect to network devices over ``cli`` -transport, network modules support the use of ``ProxyCommand``. - -To use ``ProxyCommand``, configure the proxy settings in the Ansible inventory -file to specify the proxy host. - -.. code-block:: ini - - [nxos] - nxos01 - nxos02 - - [nxos:vars] - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -With the configuration above, simply build and run the playbook as normal with -no additional changes necessary. The network module will now connect to the -network device by first connecting to the host specified in -``ansible_ssh_common_args``, which is ``bastion01`` in the above example. - -You can also set the proxy target for all hosts by using environment variables. - -.. code-block:: sh - - export ANSIBLE_SSH_ARGS='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - -Using bastion/jump host with netconf connection ------------------------------------------------ - -Enabling jump host setting --------------------------- - - -Bastion/jump host with netconf connection can be enabled by: - - Setting Ansible variable ``ansible_netconf_ssh_config`` either to ``True`` or custom ssh config file path - - Setting environment variable ``ANSIBLE_NETCONF_SSH_CONFIG`` to ``True`` or custom ssh config file path - - Setting ``ssh_config = 1`` or ``ssh_config = `` under ``netconf_connection`` section - -If the configuration variable is set to 1 the proxycommand and other ssh variables are read from -default ssh config file (~/.ssh/config). - -If the configuration variable is set to file path the proxycommand and other ssh variables are read -from the given custom ssh file path - -Example ssh config file (~/.ssh/config) ---------------------------------------- - -.. code-block:: ini - - Host jumphost - HostName jumphost.domain.name.com - User jumphost-user - IdentityFile "/path/to/ssh-key.pem" - Port 22 - - # Note: Due to the way that Paramiko reads the SSH Config file, - # you need to specify the NETCONF port that the host uses. - # In other words, it does not automatically use ansible_port - # As a result you need either: - - Host junos01 - HostName junos01 - ProxyCommand ssh -W %h:22 jumphost - - # OR - - Host junos01 - HostName junos01 - ProxyCommand ssh -W %h:830 jumphost - - # Depending on the netconf port used. - -Example Ansible inventory file - -.. code-block:: ini - - [junos] - junos01 - - [junos:vars] - ansible_connection=ansible.netcommon.netconf - ansible_network_os=junipernetworks.junos.junos - ansible_user=myuser - ansible_password=!vault... - - -.. note:: Using ``ProxyCommand`` with passwords through variables - - By design, SSH doesn't support providing passwords through environment variables. - This is done to prevent secrets from leaking out, for example in ``ps`` output. - - We recommend using SSH Keys, and if needed an ssh-agent, rather than passwords, where ever possible. - -Miscellaneous Issues -==================== - - -Intermittent failure while using ``ansible.netcommon.network_cli`` connection type ------------------------------------------------------------------------------------- - -If the command prompt received in response is not matched correctly within -the ``ansible.netcommon.network_cli`` connection plugin the task might fail intermittently with truncated -response or with the error message ``operation requires privilege escalation``. -Starting in 2.7.1 a new buffer read timer is added to ensure prompts are matched properly -and a complete response is send in output. The timer default value is 0.2 seconds and -can be adjusted on a per task basis or can be set globally in seconds. - -Example Per task timer setting - -.. code-block:: yaml - - - name: gather ios facts - cisco.ios.ios_facts: - gather_subset: all - register: result - vars: - ansible_buffer_read_timeout: 2 - - -To make this a global setting, add the following to your ``ansible.cfg`` file: - -.. code-block:: ini - - [persistent_connection] - buffer_read_timeout = 2 - -This timer delay per command executed on remote host can be disabled by setting the value to zero. - - -Task failure due to mismatched error regex within command response using ``ansible.netcommon.network_cli`` connection type ----------------------------------------------------------------------------------------------------------------------------- - -In Ansible 2.9 and later, the ``ansible.netcommon.network_cli`` connection plugin configuration options are added -to handle the stdout and stderr regex to identify if the command execution response consist -of a normal response or an error response. These options can be set group/host variables or as -tasks variables. - -Example: For mismatched error response - -.. code-block:: yaml - - - name: fetch logs from remote host - cisco.ios.ios_command: - commands: - - show logging - - -Playbook run output: - -.. code-block:: console - - TASK [first fetch logs] ******************************************************** - fatal: [ios01]: FAILED! => { - "changed": false, - "msg": "RF Name:\r\n\r\n <--nsip--> - \"IPSEC-3-REPLAY_ERROR: Test log\"\r\n*Aug 1 08:36:18.483: %SYS-7-USERLOG_DEBUG: - Message from tty578(user id: ansible): test\r\nan-ios-02#"} - -Suggestions to resolve: - -Modify the error regex for individual task. - -.. code-block:: yaml - - - name: fetch logs from remote host - cisco.ios.ios_command: - commands: - - show logging - vars: - ansible_terminal_stderr_re: - - pattern: 'connection timed out' - flags: 're.I' - -The terminal plugin regex options ``ansible_terminal_stderr_re`` and ``ansible_terminal_stdout_re`` have -``pattern`` and ``flags`` as keys. The value of the ``flags`` key should be a value that is accepted by -the ``re.compile`` python method. - - -Intermittent failure while using ``ansible.netcommon.network_cli`` connection type due to slower network or remote target host ----------------------------------------------------------------------------------------------------------------------------------- - -In Ansible 2.9 and later, the ``ansible.netcommon.network_cli`` connection plugin configuration option is added to control -the number of attempts to connect to a remote host. The default number of attempts is three. -After every retry attempt the delay between retries is increased by power of 2 in seconds until either the -maximum attempts are exhausted or either the ``persistent_command_timeout`` or ``persistent_connect_timeout`` timers are triggered. - -To make this a global setting, add the following to your ``ansible.cfg`` file: - -.. code-block:: ini - - [persistent_connection] - network_cli_retries = 5 diff --git a/docs/docsite/rst/network/user_guide/network_resource_modules.rst b/docs/docsite/rst/network/user_guide/network_resource_modules.rst deleted file mode 100644 index 1d048f5a41f..00000000000 --- a/docs/docsite/rst/network/user_guide/network_resource_modules.rst +++ /dev/null @@ -1,196 +0,0 @@ -.. _resource_modules: - -************************ -Network Resource Modules -************************ - -Ansible network resource modules simplify and standardize how you manage different network devices. Network devices separate configuration into sections (such as interfaces and VLANs) that apply to a network service. Ansible network resource modules take advantage of this to allow you to configure subsections or *resources* within the network device configuration. Network resource modules provide a consistent experience across different network devices. - - -.. contents:: - :local: - -Network resource module states -=============================== - -You use the network resource modules by assigning a state to what you want the module to do. The resource modules support the following states: - -merged - Ansible merges the on-device configuration with the provided configuration in the task. - -replaced - Ansible replaces the on-device configuration subsection with the provided configuration subsection in the task. - -overridden - Ansible overrides the on-device configuration for the resource with the provided configuration in the task. Use caution with this state as you could remove your access to the device (for example, by overriding the management interface configuration). - -deleted - Ansible deletes the on-device configuration subsection and restores any default settings. - -gathered - Ansible displays the resource details gathered from the network device and accessed with the ``gathered`` key in the result. - -rendered - Ansible renders the provided configuration in the task in the device-native format (for example, Cisco IOS CLI). Ansible returns this rendered configuration in the ``rendered`` key in the result. Note this state does not communicate with the network device and can be used offline. - -parsed - Ansible parses the configuration from the ``running_config`` option into Ansible structured data in the ``parsed`` key in the result. Note this does not gather the configuration from the network device so this state can be used offline. - -Using network resource modules -============================== - -This example configures the L3 interface resource on a Cisco IOS device, based on different state settings. - - .. code-block:: yaml - - - name: configure l3 interface - cisco.ios.ios_l3_interfaces: - config: "{{ config }}" - state: - -The following table shows an example of how an initial resource configuration changes with this task for different states. - -+-----------------------------------------+------------------------------------+-----------------------------------------+ -| Resource starting configuration | task-provided configuration (YAML) | Final resource configuration on device | -+=========================================+====================================+=========================================+ -| .. code-block:: text | .. code-block:: yaml | *merged* | -| | | .. code-block:: text | -| interface loopback100 | config: | | -| ip address 10.10.1.100 255.255.255.0 | - ipv6: | interface loopback100 | -| ipv6 address FC00:100/64 | - address: fc00::100/64 | ip address 10.10.1.100 255.255.255.0| -| | - address: fc00::101/64 | ipv6 address FC00:100/64 | -| | name: loopback100 | ipv6 address FC00:101/64 | -| | +-----------------------------------------+ -| | | *replaced* | -| | | .. code-block:: text | -| | | | -| | | interface loopback100 | -| | | no ip address | -| | | ipv6 address FC00:100/64 | -| | | ipv6 address FC00:101/64 | -| | +-----------------------------------------+ -| | | *overridden* | -| | | Incorrect use case. This would remove | -| | | all interfaces from the device | -| | | (including the mgmt interface) except | -| | | the configured loopback100 | -| | +-----------------------------------------+ -| | | *deleted* | -| | | .. code-block:: text | -| | | | -| | | interface loopback100 | -| | | no ip address | -+-----------------------------------------+------------------------------------+-----------------------------------------+ - -Network resource modules return the following details: - -* The *before* state - the existing resource configuration before the task was executed. -* The *after* state - the new resource configuration that exists on the network device after the task was executed. -* Commands - any commands configured on the device. - -.. code-block:: yaml - - ok: [nxos101] => - result: - after: - contact: IT Support - location: Room E, Building 6, Seattle, WA 98134 - users: - - algorithm: md5 - group: network-admin - localized_key: true - password: '0x73fd9a2cc8c53ed3dd4ed8f4ff157e69' - privacy_password: '0x73fd9a2cc8c53ed3dd4ed8f4ff157e69' - username: admin - before: - contact: IT Support - location: Room E, Building 5, Seattle HQ - users: - - algorithm: md5 - group: network-admin - localized_key: true - password: '0x73fd9a2cc8c53ed3dd4ed8f4ff157e69' - privacy_password: '0x73fd9a2cc8c53ed3dd4ed8f4ff157e69' - username: admin - changed: true - commands: - - snmp-server location Room E, Building 6, Seattle, WA 98134 - failed: false - - -Example: Verifying the network device configuration has not changed -==================================================================== - -The following playbook uses the :ref:`arista.eos.eos_l3_interfaces ` module to gather a subset of the network device configuration (Layer 3 interfaces only) and verifies the information is accurate and has not changed. This playbook passes the results of :ref:`arista.eos.eos_facts ` directly to the ``arista.eos.eos_l3_interfaces`` module. - - -.. code-block:: yaml - - - name: Example of facts being pushed right back to device. - hosts: arista - gather_facts: false - tasks: - - name: grab arista eos facts - arista.eos.eos_facts: - gather_subset: min - gather_network_resources: l3_interfaces - - - name: Ensure that the IP address information is accurate. - arista.eos.eos_l3_interfaces: - config: "{{ ansible_network_resources['l3_interfaces'] }}" - register: result - - - name: Ensure config did not change. - assert: - that: not result.changed - -Example: Acquiring and updating VLANs on a network device -========================================================== - -This example shows how you can use resource modules to: - -#. Retrieve the current configuration on a network device. -#. Save that configuration locally. -#. Update that configuration and apply it to the network device. - -This example uses the ``cisco.ios.ios_vlans`` resource module to retrieve and update the VLANs on an IOS device. - -1. Retrieve the current IOS VLAN configuration: - -.. code-block:: yaml - - - name: Gather VLAN information as structured data - cisco.ios.ios_facts: - gather_subset: - - '!all' - - '!min' - gather_network_resources: - - 'vlans' - -2. Store the VLAN configuration locally: - -.. code-block:: yaml - - - name: Store VLAN facts to host_vars - copy: - content: "{{ ansible_network_resources | to_nice_yaml }}" - dest: "{{ playbook_dir }}/host_vars/{{ inventory_hostname }}" - -3. Modify the stored file to update the VLAN configuration locally. - -4. Merge the updated VLAN configuration with the existing configuration on the device: - -.. code-block:: yaml - - - name: Make VLAN config changes by updating stored facts on the controller. - cisco.ios.ios_vlans: - config: "{{ vlans }}" - state: merged - tags: update_config - -.. seealso:: - - `Network Features in Ansible 2.9 `_ - A introductory blog post on network resource modules. - `Deep Dive into Network Resource Modules `_ - A deeper dive presentation into network resource modules. diff --git a/docs/docsite/rst/network/user_guide/network_working_with_command_output.rst b/docs/docsite/rst/network/user_guide/network_working_with_command_output.rst deleted file mode 100644 index 6215df97efe..00000000000 --- a/docs/docsite/rst/network/user_guide/network_working_with_command_output.rst +++ /dev/null @@ -1,126 +0,0 @@ -.. _networking_working_with_command_output: - -********************************************************** -Working with command output and prompts in network modules -********************************************************** - -.. contents:: - :local: - -Conditionals in networking modules -=================================== - -Ansible allows you to use conditionals to control the flow of your playbooks. Ansible networking command modules use the following unique conditional statements. - -* ``eq`` - Equal -* ``neq`` - Not equal -* ``gt`` - Greater than -* ``ge`` - Greater than or equal -* ``lt`` - Less than -* ``le`` - Less than or equal -* ``contains`` - Object contains specified item - - -Conditional statements evaluate the results from the commands that are -executed remotely on the device. Once the task executes the command -set, the ``wait_for`` argument can be used to evaluate the results before -returning control to the Ansible playbook. - -For example: - -.. code-block:: yaml - - --- - - name: wait for interface to be admin enabled - arista.eos.eos_command: - commands: - - show interface Ethernet4 | json - wait_for: - - "result[0].interfaces.Ethernet4.interfaceStatus eq connected" - -In the above example task, the command :code:`show interface Ethernet4 | json` -is executed on the remote device and the results are evaluated. If -the path -:code:`(result[0].interfaces.Ethernet4.interfaceStatus)` is not equal to -"connected", then the command is retried. This process continues -until either the condition is satisfied or the number of retries has -expired (by default, this is 10 retries at 1 second intervals). - -The commands module can also evaluate more than one set of command -results in an interface. For instance: - -.. code-block:: yaml - - --- - - name: wait for interfaces to be admin enabled - arista.eos.eos_command: - commands: - - show interface Ethernet4 | json - - show interface Ethernet5 | json - wait_for: - - "result[0].interfaces.Ethernet4.interfaceStatus eq connected" - - "result[1].interfaces.Ethernet5.interfaceStatus eq connected" - -In the above example, two commands are executed on the -remote device, and the results are evaluated. By specifying the result -index value (0 or 1), the correct result output is checked against the -conditional. - -The ``wait_for`` argument must always start with result and then the -command index in ``[]``, where ``0`` is the first command in the commands list, -``1`` is the second command, ``2`` is the third and so on. - - -Handling prompts in network modules -=================================== - -Network devices may require that you answer a prompt before performing a change on the device. Individual network modules such as :ref:`cisco.ios.ios_command ` and :ref:`cisco.nxos.nxos_command ` can handle this with a ``prompt`` parameter. - -.. note:: - - ``prompt`` is a Python regex. If you add special characters such as ``?`` in the ``prompt`` value, the prompt won't match and you will get a timeout. To avoid this, ensure that the ``prompt`` value is a Python regex that matches the actual device prompt. Any special characters must be handled correctly in the ``prompt`` regex. - -You can also use the :ref:`ansible.netcommon.cli_command ` to handle multiple prompts. - -.. code-block:: yaml - - --- - - name: multiple prompt, multiple answer (mandatory check for all prompts) - ansible.netcommon.cli_command: - command: "copy sftp sftp://user@host//user/test.img" - check_all: True - prompt: - - "Confirm download operation" - - "Password" - - "Do you want to change that to the standby image" - answer: - - 'y' - - - - 'y' - -You must list the prompt and the answers in the same order (that is, prompt[0] is answered by answer[0]). - -In the above example, ``check_all: True`` ensures that the task gives the matching answer to each prompt. Without that setting, a task with multiple prompts would give the first answer to every prompt. - -In the following example, the second answer would be ignored and ``y`` would be the answer given to both prompts. That is, this task only works because both answers are identical. Also notice again that ``prompt`` must be a Python regex, which is why the ``?`` is escaped in the first prompt. - -.. code-block:: yaml - - --- - - name: reboot ios device - ansible.netcommon.cli_command: - command: reload - prompt: - - Save\? - - confirm - answer: - - y - - y - -.. seealso:: - - `Rebooting network devices with Ansible `_ - Examples using ``wait_for``, ``wait_for_connection``, and ``prompt`` for network devices. - - `Deep dive on cli_command `_ - Detailed overview of how to use the ``cli_command``. diff --git a/docs/docsite/rst/network/user_guide/platform_ce.rst b/docs/docsite/rst/network/user_guide/platform_ce.rst deleted file mode 100644 index 194917482c1..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_ce.rst +++ /dev/null @@ -1,213 +0,0 @@ -.. _ce_platform_options: - -*************************************** -CloudEngine OS Platform Options -*************************************** - -CloudEngine CE OS is part of the `community.network `_ collection and supports multiple connections. This page offers details on how each connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== ========================= - .. CLI NETCONF - - - ==================== ========================================== ========================= - Protocol SSH XML over SSH - - Credentials uses SSH keys / SSH-agent if present uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password accepts ``-u myuser -k`` if using password - - Indirect Access via a bastion (jump host) via a bastion (jump host) - - Connection Settings ``ansible_connection:`` ``ansible_connection:`` - ``ansible.netcommon.network_cli`` ``ansible.netcommon.netconf`` - - |enable_mode| not supported by ce OS not supported by ce OS - - Returned Data Format Refer to individual module documentation Refer to individual module documentation - ==================== ========================================== ========================= - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.netconf`` or ``ansible_connection=ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -==================== - -Example CLI inventory ``[ce:vars]`` --------------------------------------- - -.. code-block:: yaml - - [ce:vars] - ansible_connection=ansible.netcommon.network_cli - ansible_network_os=community.network.ce - ansible_user=myuser - ansible_password=!vault... - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords via environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve CE OS version - community.network.ce_command: - commands: display version - when: ansible_network_os == 'community.network.ce' - - -Using NETCONF in Ansible -======================== - -Enabling NETCONF ----------------- - -Before you can use NETCONF to connect to a switch, you must: - -- install the ``ncclient`` python package on your control node(s) with ``pip install ncclient`` -- enable NETCONF on the CloudEngine OS device(s) - -To enable NETCONF on a new switch using Ansible, use the ``community.network.ce_config`` module with the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this: - -.. code-block:: yaml - - - name: Enable NETCONF - connection: ansible.netcommon.network_cli - community.network.ce_config: - lines: - - snetconf server enable - when: ansible_network_os == 'community.network.ce' - -Once NETCONF is enabled, change your variables to use the NETCONF connection. - -Example NETCONF inventory ``[ce:vars]`` ------------------------------------------- - -.. code-block:: yaml - - [ce:vars] - ansible_connection=ansible.netcommon.netconf - ansible_network_os=community.network.ce - ansible_user=myuser - ansible_password=!vault | - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -Example NETCONF task --------------------- - -.. code-block:: yaml - - - name: Create a vlan, id is 50(ce) - community.network.ce_vlan: - vlan_id: 50 - name: WEB - when: ansible_network_os == 'community.network.ce' - - -Notes -======================== - -Modules that work with ``ansible.netcommon.network_cli`` ---------------------------------------------------------- - -.. code-block:: yaml - - community.network.ce_acl_interface - community.network.ce_command - community.network.ce_config - community.network.ce_evpn_bgp - community.network.ce_evpn_bgp_rr - community.network.ce_evpn_global - community.network.ce_facts - community.network.ce_mlag_interface - community.network.ce_mtu - community.network.ce_netstream_aging - community.network.ce_netstream_export - community.network.ce_netstream_global - community.network.ce_netstream_template - community.network.ce_ntp_auth - community.network.ce_rollback - community.network.ce_snmp_contact - community.network.ce_snmp_location - community.network.ce_snmp_traps - community.network.ce_startup - community.network.ce_stp - community.network.ce_vxlan_arp - community.network.ce_vxlan_gateway - community.network.ce_vxlan_global - - -Modules that work with ``ansible.netcommon.netconf`` ------------------------------------------------------ - -.. code-block:: yaml - - community.network.ce_aaa_server - community.network.ce_aaa_server_host - community.network.ce_acl - community.network.ce_acl_advance - community.network.ce_bfd_global - community.network.ce_bfd_session - community.network.ce_bfd_view - community.network.ce_bgp - community.network.ce_bgp_af - community.network.ce_bgp_neighbor - community.network.ce_bgp_neighbor_af - community.network.ce_dldp - community.network.ce_dldp_interface - community.network.ce_eth_trunk - community.network.ce_evpn_bd_vni - community.network.ce_file_copy - community.network.ce_info_center_debug - community.network.ce_info_center_global - community.network.ce_info_center_log - community.network.ce_info_center_trap - community.network.ce_interface - community.network.ce_interface_ospf - community.network.ce_ip_interface - community.network.ce_lacp - community.network.ce_link_status - community.network.ce_lldp - community.network.ce_lldp_interface - community.network.ce_mlag_config - community.network.ce_netconf - community.network.ce_ntp - community.network.ce_ospf - community.network.ce_ospf_vrf - community.network.ce_reboot - community.network.ce_sflow - community.network.ce_snmp_community - community.network.ce_snmp_target_host - community.network.ce_snmp_user - community.network.ce_static_route - community.network.ce_static_route_bfd - community.network.ce_switchport - community.network.ce_vlan - community.network.ce_vrf - community.network.ce_vrf_af - community.network.ce_vrf_interface - community.network.ce_vrrp - community.network.ce_vxlan_tunnel - community.network.ce_vxlan_vap - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_cnos.rst b/docs/docsite/rst/network/user_guide/platform_cnos.rst deleted file mode 100644 index cb79c7dac26..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_cnos.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _cnos_platform_options: - -*************************************** -CNOS Platform Options -*************************************** - -CNOS is part of the `community.network `_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on CNOS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: true`` - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -================================================================================ - -Example CLI ``group_vars/cnos.yml`` --------------------------------------------------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.cnos - ansible_user: myuser - ansible_password: !vault... - ansible_become: true - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve CNOS OS version - community.network.cnos_command: - commands: show version - when: ansible_network_os == 'community.network.cnos' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_dellos10.rst b/docs/docsite/rst/network/user_guide/platform_dellos10.rst deleted file mode 100644 index 35686b9b7c8..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_dellos10.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _dellos10_platform_options: - -*************************************** -Dell OS10 Platform Options -*************************************** - -The `dellemc.os10 `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS10 in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access through a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: true`` - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - - -Using CLI in Ansible -================================================================================ - -Example CLI ``group_vars/dellos10.yml`` ---------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: dellemc.os10.os10 - ansible_user: myuser - ansible_password: !vault... - ansible_become: true - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (dellos10) - dellemc.os10.os10_config: - backup: yes - register: backup_dellos10_location - when: ansible_network_os == 'dellemc.os10.os10' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_dellos6.rst b/docs/docsite/rst/network/user_guide/platform_dellos6.rst deleted file mode 100644 index c4df091e6c3..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_dellos6.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. _dellos6_platform_options: - -*************************************** -Dell OS6 Platform Options -*************************************** - -The `dellemc.os6 `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS6 in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access through a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: true`` - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -================================================================================ - -Example CLI ``group_vars/dellos6.yml`` --------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: dellemc.os6.os6 - ansible_user: myuser - ansible_password: !vault... - ansible_become: true - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (dellos6) - dellemc.os6.os6_config: - backup: yes - register: backup_dellso6_location - when: ansible_network_os == 'dellemc.os6.os6' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_dellos9.rst b/docs/docsite/rst/network/user_guide/platform_dellos9.rst deleted file mode 100644 index 91e525e43cf..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_dellos9.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. _dellos9_platform_options: - -*************************************** -Dell OS9 Platform Options -*************************************** - -The `dellemc.os9 `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS9 in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access through a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: true`` - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -================================================================================ - -Example CLI ``group_vars/dellos9.yml`` --------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: dellemc.os9.os9 - ansible_user: myuser - ansible_password: !vault... - ansible_become: true - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (dellos9) - dellemc.os9.os9_config: - backup: yes - register: backup_dellos9_location - when: ansible_network_os == 'dellemc.os9.os9' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_enos.rst b/docs/docsite/rst/network/user_guide/platform_enos.rst deleted file mode 100644 index 4ba9a761961..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_enos.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _enos_platform_options: - -*************************************** -ENOS Platform Options -*************************************** - -ENOS is part of the `community.network `_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on ENOS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: true`` - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -+---------------------------+-----------------------------------------------+ - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -================================================================================ - -Example CLI ``group_vars/enos.yml`` --------------------------------------------------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.enos - ansible_user: myuser - ansible_password: !vault... - ansible_become: true - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve ENOS OS version - community.network.enos_command: - commands: show version - when: ansible_network_os == 'community.network.enos' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_eos.rst b/docs/docsite/rst/network/user_guide/platform_eos.rst deleted file mode 100644 index a48c7809600..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_eos.rst +++ /dev/null @@ -1,140 +0,0 @@ -.. _eos_platform_options: - -*************************************** -EOS Platform Options -*************************************** - -The `Arista EOS `_ collection supports multiple connections. This page offers details on how each connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== =========================== - .. CLI eAPI - ==================== ========================================== =========================== - Protocol SSH HTTP(S) - - Credentials uses SSH keys / SSH-agent if present uses HTTPS certificates if - present - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) through a web proxy - - Connection Settings ``ansible_connection:`` ``ansible_connection:`` - ``ansible.netcommon.network_cli`` ``ansible.netcommon.httpapi`` - - - |enable_mode| supported: |br| supported: |br| - - * use ``ansible_become: true`` * ``httpapi`` - with ``ansible_become_method: enable`` uses ``ansible_become: true`` - with ``ansible_become_method: enable`` - - Returned Data Format ``stdout[0].`` ``stdout[0].messages[0].`` - ==================== ========================================== =========================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.httpapi`` instead. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/eos.yml`` ----------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: arista.eos.eos - ansible_user: myuser - ansible_password: !vault... - ansible_become: true - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (eos) - arista.eos.eos_config: - backup: yes - register: backup_eos_location - when: ansible_network_os == 'arista.eos.eos' - - - -Using eAPI in Ansible -===================== - -Enabling eAPI -------------- - -Before you can use eAPI to connect to a switch, you must enable eAPI. To enable eAPI on a new switch with Ansible, use the ``arista.eos.eos_eapi`` module through the CLI connection. Set up ``group_vars/eos.yml`` just like in the CLI example above, then run a playbook task like this: - -.. code-block:: yaml - - - name: Enable eAPI - arista.eos.eos_eapi: - enable_http: yes - enable_https: yes - become: true - become_method: enable - when: ansible_network_os == 'arista.eos.eos' - -You can find more options for enabling HTTP/HTTPS connections in the :ref:`arista.eos.eos_eapi ` module documentation. - -Once eAPI is enabled, change your ``group_vars/eos.yml`` to use the eAPI connection. - -Example eAPI ``group_vars/eos.yml`` ------------------------------------ - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.httpapi - ansible_network_os: arista.eos.eos - ansible_user: myuser - ansible_password: !vault... - ansible_become: true - ansible_become_method: enable - proxy_env: - http_proxy: http://proxy.example.com:8080 - -- If you are accessing your host directly (not through a web proxy) you can remove the ``proxy_env`` configuration. -- If you are accessing your host through a web proxy using ``https``, change ``http_proxy`` to ``https_proxy``. - - -Example eAPI task ------------------ - -.. code-block:: yaml - - - name: Backup current switch config (eos) - arista.eos.eos_config: - backup: yes - register: backup_eos_location - environment: "{{ proxy_env }}" - when: ansible_network_os == 'arista.eos.eos' - -In this example the ``proxy_env`` variable defined in ``group_vars`` gets passed to the ``environment`` option of the module in the task. - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_eric_eccli.rst b/docs/docsite/rst/network/user_guide/platform_eric_eccli.rst deleted file mode 100644 index 8e8bef0178c..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_eric_eccli.rst +++ /dev/null @@ -1,73 +0,0 @@ -.. _eic_eccli_platform_options: - -*************************************** -ERIC_ECCLI Platform Options -*************************************** - -Extreme ERIC_ECCLI is part of the `community.network `_ collection and only supports CLI connections today. This page offers details on how to use ``ansible.netcommon.network_cli`` on ERIC_ECCLI in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| not supported by ERIC_ECCLI - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -ERIC_ECCLI does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/eric_eccli.yml`` ------------------------------------------ - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.eric_eccli - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: run show version on remote devices (eric_eccli) - community.network.eric_eccli_command: - commands: show version - when: ansible_network_os == 'community.network.eric_eccli' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_exos.rst b/docs/docsite/rst/network/user_guide/platform_exos.rst deleted file mode 100644 index 2e74be53f33..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_exos.rst +++ /dev/null @@ -1,108 +0,0 @@ -.. _exos_platform_options: - -*************************************** -EXOS Platform Options -*************************************** - -Extreme EXOS is part of the `community.network `_ collection and supports multiple connections. This page offers details on how each connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ - - -.. table:: - :class: documentation-table - - ==================== ========================================== ========================= - .. CLI EXOS-API - ==================== ========================================== ========================= - Protocol SSH HTTP(S) - - Credentials uses SSH keys / SSH-agent if present uses HTTPS certificates if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) through a web proxy - - Connection Settings ``ansible_connection:`` ``ansible_connection:`` - ``ansible.netcommon.network_cli`` ``ansible.netcommon.httpapi`` - - |enable_mode| not supported by EXOS not supported by EXOS - - Returned Data Format ``stdout[0].`` ``stdout[0].messages[0].`` - ==================== ========================================== ========================= - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -EXOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.httpapi``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/exos.yml`` ------------------------------------ - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.exos - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve EXOS OS version - community.network.exos_command: - commands: show version - when: ansible_network_os == 'community.network.exos' - - - -Using EXOS-API in Ansible -========================= - -Example EXOS-API ``group_vars/exos.yml`` ----------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.httpapi - ansible_network_os: community.network.exos - ansible_user: myuser - ansible_password: !vault... - proxy_env: - http_proxy: http://proxy.example.com:8080 - -- If you are accessing your host directly (not through a web proxy) you can remove the ``proxy_env`` configuration. -- If you are accessing your host through a web proxy using ``https``, change ``http_proxy`` to ``https_proxy``. - - -Example EXOS-API task ---------------------- - -.. code-block:: yaml - - - name: Retrieve EXOS OS version - community.network.exos_command: - commands: show version - when: ansible_network_os == 'community.network.exos' - -In this example the ``proxy_env`` variable defined in ``group_vars`` gets passed to the ``environment`` option of the module used in the task. - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_frr.rst b/docs/docsite/rst/network/user_guide/platform_frr.rst deleted file mode 100644 index 026125098c5..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_frr.rst +++ /dev/null @@ -1,73 +0,0 @@ -.. _frr_platform_options: - -*************************************** -FRR Platform Options -*************************************** - -The `FRR `_ collection supports the ``ansible.netcommon.network_cli`` connection. This section provides details on how to use this connection for Free Range Routing (FRR). - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| not supported - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/frr.yml`` ----------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: frr.frr.frr - ansible_user: frruser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - -- The ``ansible_user`` should be a part of the ``frrvty`` group and should have the default shell set to ``/bin/vtysh``. -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Gather FRR facts - frr.frr.frr_facts: - gather_subset: - - config - - hardware - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_icx.rst b/docs/docsite/rst/network/user_guide/platform_icx.rst deleted file mode 100644 index 204312c5bce..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_icx.rst +++ /dev/null @@ -1,77 +0,0 @@ -.. _icx_platform_options: - -*************************************** -ICX Platform Options -*************************************** - -ICX is part of the `community.network `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on ICX in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: true`` with - ``ansible_become_method: enable`` and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/icx.yml`` ----------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.icx - ansible_user: myuser - ansible_password: !vault... - ansible_become: true - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (icx) - community.network.icx_config: - backup: yes - register: backup_icx_location - when: ansible_network_os == 'community.network.icx' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_index.rst b/docs/docsite/rst/network/user_guide/platform_index.rst deleted file mode 100644 index f9a8bc5f3c7..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_index.rst +++ /dev/null @@ -1,124 +0,0 @@ -.. _platform_options: - -**************** -Platform Options -**************** - -Some Ansible Network platforms support multiple connection types, privilege escalation (``enable`` mode), or other options. The pages in this section offer standardized guides to understanding available options on each network platform. We welcome contributions from community-maintained platforms to this section. - -.. toctree:: - :maxdepth: 2 - :caption: Platform Options - - platform_ce - platform_cnos - platform_dellos6 - platform_dellos9 - platform_dellos10 - platform_enos - platform_eos - platform_eric_eccli - platform_exos - platform_frr - platform_icx - platform_ios - platform_iosxr - platform_ironware - platform_junos - platform_meraki - platform_netvisor - platform_nos - platform_nxos - platform_routeros - platform_slxos - platform_voss - platform_vyos - platform_weos4 - platform_netconf_enabled - -.. _settings_by_platform: - -Settings by Platform -================================ - -.. raw:: html - - - -.. table:: - :name: network-platform-table - - =============================== ================================ =========== ======= ======= =========== - .. ``ansible_connection:`` settings available - ----------------------------------------------------------------- ------------------------------------------ - Network OS ``ansible_network_os:`` network_cli netconf httpapi local - =============================== ================================ =========== ======= ======= =========== - `Arista EOS`_ `[†]`_ ``arista.eos.eos`` ✓ ✓ ✓ - `Ciena SAOS6`_ ``ciena.saos6.saos6`` ✓ ✓ - `Cisco ASA`_ `[†]`_ ``cisco.asa.asa`` ✓ ✓ - `Cisco IOS`_ `[†]`_ ``cisco.ios.ios`` ✓ ✓ - `Cisco IOS XR`_ `[†]`_ ``cisco.iosxr.iosxr`` ✓ ✓ - `Cisco NX-OS`_ `[†]`_ ``cisco.nxos.nxos`` ✓ ✓ ✓ - `Cloudengine OS`_ ``community.network.ce`` ✓ ✓ ✓ - `Dell OS6`_ ``dellemc.os6.os6`` ✓ ✓ - `Dell OS9`_ ``dellemc.os9.os9`` ✓ ✓ - `Dell OS10`_ ``dellemc.os10.os10`` ✓ ✓ - `Ericsson ECCLI`_ ``community.network.eric_eccli`` ✓ ✓ - `Extreme EXOS`_ ``community.network.exos`` ✓ ✓ - `Extreme IronWare`_ ``community.network.ironware`` ✓ ✓ - `Extreme NOS`_ ``community.network.nos`` ✓ - `Extreme SLX-OS`_ ``community.network.slxos`` ✓ - `Extreme VOSS`_ ``community.network.voss`` ✓ - `F5 BIG-IP`_ ✓ - `F5 BIG-IQ`_ ✓ - `Junos OS`_ `[†]`_ ``junipernetworks.junos.junos`` ✓ ✓ ✓ - `Lenovo CNOS`_ ``community.network.cnos`` ✓ ✓ - `Lenovo ENOS`_ ``community.network.enos`` ✓ ✓ - `Meraki`_ ✓ - `MikroTik RouterOS`_ ``community.network.routeros`` ✓ - `Nokia SR OS`_ ✓ - `Pluribus Netvisor`_ ``community.network.netvisor`` ✓ - `Ruckus ICX`_ ``community.network.icx`` ✓ - `VyOS`_ `[†]`_ ``vyos.vyos.vyos`` ✓ ✓ - `Westermo WeOS 4`_ ``community.network.weos4`` ✓ - OS that supports Netconf `[†]`_ ```` ✓ ✓ - =============================== ================================ =========== ======= ======= =========== - -.. _Arista EOS: https://galaxy.ansible.com/arista/eos -.. _Ciena SAOS6: https://galaxy.ansible.com/ciena/saos6 -.. _Cisco ASA: https://galaxy.ansible.com/cisco/asa -.. _Cisco IOS: https://galaxy.ansible.com/cisco/ios -.. _Cisco IOS XR: https://galaxy.ansible.com/cisco/iosxr -.. _Cisco NX-OS: https://galaxy.ansible.com/cisco/nxos -.. _Cloudengine OS: https://galaxy.ansible.com/community/network -.. _Dell OS6: https://github.com/ansible-collections/dellemc.os6 -.. _Dell OS9: https://github.com/ansible-collections/dellemc.os9 -.. _Dell OS10: https://galaxy.ansible.com/dellemc/os10 -.. _Ericsson ECCLI: https://galaxy.ansible.com/community/network -.. _Extreme EXOS: https://galaxy.ansible.com/community/network -.. _Extreme IronWare: https://galaxy.ansible.com/community/network -.. _Extreme NOS: https://galaxy.ansible.com/community/network -.. _Extreme SLX-OS: https://galaxy.ansible.com/community/network -.. _Extreme VOSS: https://galaxy.ansible.com/community/network -.. _F5 BIG-IP: https://galaxy.ansible.com/f5networks/f5_modules -.. _F5 BIG-IQ: https://galaxy.ansible.com/f5networks/f5_modules -.. _Junos OS: https://galaxy.ansible.com/junipernetworks/junos -.. _Lenovo CNOS: https://galaxy.ansible.com/community/network -.. _Lenovo ENOS: https://galaxy.ansible.com/community/network -.. _Meraki: https://galaxy.ansible.com/cisco/meraki -.. _MikroTik RouterOS: https://galaxy.ansible.com/community/network -.. _Nokia SR OS: https://galaxy.ansible.com/community/network -.. _Pluribus Netvisor: https://galaxy.ansible.com/community/network -.. _Ruckus ICX: https://galaxy.ansible.com/community/network -.. _VyOS: https://galaxy.ansible.com/vyos/vyos -.. _Westermo WeOS 4: https://galaxy.ansible.com/community/network -.. _`[†]`: - -**[†]** Maintained by Ansible Network Team diff --git a/docs/docsite/rst/network/user_guide/platform_ios.rst b/docs/docsite/rst/network/user_guide/platform_ios.rst deleted file mode 100644 index 70cf8c84ad1..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_ios.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. _ios_platform_options: - -*************************************** -IOS Platform Options -*************************************** - -The `Cisco IOS `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on IOS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: true`` with - ``ansible_become_method: enable`` and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/ios.yml`` ----------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: cisco.ios.ios - ansible_user: myuser - ansible_password: !vault... - ansible_become: true - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (ios) - cisco.ios.ios_config: - backup: yes - register: backup_ios_location - when: ansible_network_os == 'cisco.ios.ios' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_iosxr.rst b/docs/docsite/rst/network/user_guide/platform_iosxr.rst deleted file mode 100644 index 30e49951c3c..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_iosxr.rst +++ /dev/null @@ -1,130 +0,0 @@ -.. _iosxr_platform_options: - -*************************************** -IOS-XR Platform Options -*************************************** - -The `Cisco IOS-XR collection `_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== ========================= - .. CLI NETCONF - - only for modules ``iosxr_banner``, - ``iosxr_interface``, ``iosxr_logging``, - ``iosxr_system``, ``iosxr_user`` - ==================== ========================================== ========================= - Protocol SSH XML over SSH - - Credentials uses SSH keys / SSH-agent if present uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) by a bastion (jump host) - - Connection Settings ``ansible_connection:`` ``ansible_connection:`` - ``ansible.netcommon.network_cli`` ``ansible.netcommon.netconf`` - - |enable_mode| not supported not supported - - Returned Data Format Refer to individual module documentation Refer to individual module documentation - ==================== ========================================== ========================= - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.netconf`` instead. - -Using CLI in Ansible -==================== - -Example CLI inventory ``[iosxr:vars]`` --------------------------------------- - -.. code-block:: yaml - - [iosxr:vars] - ansible_connection=ansible.netcommon.network_cli - ansible_network_os=cisco.iosxr.iosxr - ansible_user=myuser - ansible_password=!vault... - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve IOS-XR version - cisco.iosxr.iosxr_command: - commands: show version - when: ansible_network_os == 'cisco.iosxr.iosxr' - - -Using NETCONF in Ansible -======================== - -Enabling NETCONF ----------------- - -Before you can use NETCONF to connect to a switch, you must: - -- install the ``ncclient`` python package on your control node(s) with ``pip install ncclient`` -- enable NETCONF on the Cisco IOS-XR device(s) - -To enable NETCONF on a new switch via Ansible, use the ``cisco.iosxr.iosxr_netconf`` module through the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this: - -.. code-block:: yaml - - - name: Enable NETCONF - connection: ansible.netcommon.network_cli - cisco.iosxr.iosxr_netconf: - when: ansible_network_os == 'cisco.iosxr.iosxr' - -Once NETCONF is enabled, change your variables to use the NETCONF connection. - -Example NETCONF inventory ``[iosxr:vars]`` ------------------------------------------- - -.. code-block:: yaml - - [iosxr:vars] - ansible_connection=ansible.netcommon.netconf - ansible_network_os=cisco.iosxr.iosxr - ansible_user=myuser - ansible_password=!vault | - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -Example NETCONF task --------------------- - -.. code-block:: yaml - - - name: Configure hostname and domain-name - cisco.iosxr.iosxr_system: - hostname: iosxr01 - domain_name: test.example.com - domain_search: - - ansible.com - - redhat.com - - cisco.com - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_ironware.rst b/docs/docsite/rst/network/user_guide/platform_ironware.rst deleted file mode 100644 index da1530bac16..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_ironware.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _ironware_platform_options: - -*************************************** -IronWare Platform Options -*************************************** - -IronWare is part of the `community.network `_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on IronWare in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: true`` - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/mlx.yml`` ----------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.ironware - ansible_user: myuser - ansible_password: !vault... - ansible_become: true - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (ironware) - community.network.ironware_config: - backup: yes - register: backup_ironware_location - when: ansible_network_os == 'community.network.ironware' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_junos.rst b/docs/docsite/rst/network/user_guide/platform_junos.rst deleted file mode 100644 index 08cf8fc0d11..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_junos.rst +++ /dev/null @@ -1,129 +0,0 @@ -.. _junos_platform_options: - -*************************************** -Junos OS Platform Options -*************************************** - -The `Juniper Junos OS `_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== ========================= - .. CLI NETCONF - - ``junos_netconf`` & ``junos_command`` all modules except ``junos_netconf``, - modules only which enables NETCONF - ==================== ========================================== ========================= - Protocol SSH XML over SSH - - Credentials uses SSH keys / SSH-agent if present uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) by a bastion (jump host) - - Connection Settings ``ansible_connection: ``ansible_connection: - ``ansible.netcommon.network_cli`` ``ansible.netcommon.netconf`` - - |enable_mode| not supported by Junos OS not supported by Junos OS - - Returned Data Format ``stdout[0].`` * json: ``result[0]['software-information'][0]['host-name'][0]['data'] foo lo0`` - * text: ``result[1].interface-information[0].physical-interface[0].name[0].data foo lo0`` - * xml: ``result[1].rpc-reply.interface-information[0].physical-interface[0].name[0].data foo lo0`` - ==================== ========================================== ========================= - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.netconf`` instead. - -Using CLI in Ansible -==================== - -Example CLI inventory ``[junos:vars]`` --------------------------------------- - -.. code-block:: yaml - - [junos:vars] - ansible_connection=ansible.netcommon.network_cli - ansible_network_os=junipernetworks.junos.junos - ansible_user=myuser - ansible_password=!vault... - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve Junos OS version - junipernetworks.junos.junos_command: - commands: show version - when: ansible_network_os == 'junipernetworks.junos.junos' - - -Using NETCONF in Ansible -======================== - -Enabling NETCONF ----------------- - -Before you can use NETCONF to connect to a switch, you must: - -- install the ``ncclient`` python package on your control node(s) with ``pip install ncclient`` -- enable NETCONF on the Junos OS device(s) - -To enable NETCONF on a new switch through Ansible, use the ``junipernetworks.junos.junos_netconf`` module through the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this: - -.. code-block:: yaml - - - name: Enable NETCONF - connection: ansible.netcommon.network_cli - junipernetworks.junos.junos_netconf: - when: ansible_network_os == 'junipernetworks.junos.junos' - -Once NETCONF is enabled, change your variables to use the NETCONF connection. - -Example NETCONF inventory ``[junos:vars]`` ------------------------------------------- - -.. code-block:: yaml - - [junos:vars] - ansible_connection=ansible.netcommon.netconf - ansible_network_os=junipernetworks.junos.junos - ansible_user=myuser - ansible_password=!vault | - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -Example NETCONF task --------------------- - -.. code-block:: yaml - - - name: Backup current switch config (junos) - junipernetworks.junos.junos_config: - backup: yes - register: backup_junos_location - when: ansible_network_os == 'junipernetworks.junos.junos' - - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_meraki.rst b/docs/docsite/rst/network/user_guide/platform_meraki.rst deleted file mode 100644 index e51ca5b9120..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_meraki.rst +++ /dev/null @@ -1,44 +0,0 @@ -.. _meraki_platform_options: - -*************************************** -Meraki Platform Options -*************************************** - -The `cisco.meraki `_ collection only supports the ``local`` connection type at this time. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. Dashboard API - ==================== ========================================== - Protocol HTTP(S) - - Credentials uses API key from Dashboard - - Connection Settings ``ansible_connection: localhost`` - - Returned Data Format ``data.`` - ==================== ========================================== - - -Example Meraki task -------------------- - -.. code-block:: yaml - - cisco.meraki.meraki_organization: - auth_key: abc12345 - org_name: YourOrg - state: present - delegate_to: localhost - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_netconf_enabled.rst b/docs/docsite/rst/network/user_guide/platform_netconf_enabled.rst deleted file mode 100644 index e481ed62735..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_netconf_enabled.rst +++ /dev/null @@ -1,133 +0,0 @@ -.. _netconf_enabled_platform_options: - -*************************************** -Netconf enabled Platform Options -*************************************** - -This page offers details on how the netconf connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ -.. table:: - :class: documentation-table - - ==================== ========================================== - .. NETCONF - - all modules except ``junos_netconf``, - which enables NETCONF - ==================== ========================================== - Protocol XML over SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access through a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.netconf`` - ==================== ========================================== - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.netconf`` instead. - -Using NETCONF in Ansible -======================== - -Enabling NETCONF ----------------- - -Before you can use NETCONF to connect to a switch, you must: - -- install the ``ncclient`` Python package on your control node(s) with ``pip install ncclient`` -- enable NETCONF on the Junos OS device(s) - -To enable NETCONF on a new switch through Ansible, use the platform specific module through the CLI connection or set it manually. -For example set up your platform-level variables just like in the CLI example above, then run a playbook task like this: - -.. code-block:: yaml - - - name: Enable NETCONF - connection: ansible.netcommon.network_cli - junipernetworks.junos.junos_netconf: - when: ansible_network_os == 'junipernetworks.junos.junos' - -Once NETCONF is enabled, change your variables to use the NETCONF connection. - -Example NETCONF inventory ``[junos:vars]`` ------------------------------------------- - -.. code-block:: yaml - - [junos:vars] - ansible_connection=ansible.netcommon.netconf - ansible_network_os=junipernetworks.junos.junos - ansible_user=myuser - ansible_password=!vault | - - -Example NETCONF task --------------------- - -.. code-block:: yaml - - - name: Backup current switch config - junipernetworks.junos.netconf_config: - backup: yes - register: backup_junos_location - -Example NETCONF task with configurable variables ------------------------------------------------- - -.. code-block:: yaml - - - name: configure interface while providing different private key file path - junipernetworks.junos.netconf_config: - backup: yes - register: backup_junos_location - vars: - ansible_private_key_file: /home/admin/.ssh/newprivatekeyfile - -Note: For netconf connection plugin configurable variables see :ref:`ansible.netcommon.netconf `. - -Bastion/Jumphost configuration ------------------------------- -To use a jump host to connect to a NETCONF enabled device you must set the ``ANSIBLE_NETCONF_SSH_CONFIG`` environment variable. - -``ANSIBLE_NETCONF_SSH_CONFIG`` can be set to either: - - 1 or TRUE (to trigger the use of the default SSH config file ~/.ssh/config) - - The absolute path to a custom SSH config file. - -The SSH config file should look something like: - -.. code-block:: ini - - Host * - proxycommand ssh -o StrictHostKeyChecking=no -W %h:%p jumphost-username@jumphost.fqdn.com - StrictHostKeyChecking no - -Authentication for the jump host must use key based authentication. - -You can either specify the private key used in the SSH config file: - -.. code-block:: ini - - IdentityFile "/absolute/path/to/private-key.pem" - -Or you can use an ssh-agent. - -ansible_network_os auto-detection ---------------------------------- - -If ``ansible_network_os`` is not specified for a host, then Ansible will attempt to automatically detect what ``network_os`` plugin to use. - -``ansible_network_os`` auto-detection can also be triggered by using ``auto`` as the ``ansible_network_os``. (Note: Previously ``default`` was used instead of ``auto``). - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_netvisor.rst b/docs/docsite/rst/network/user_guide/platform_netvisor.rst deleted file mode 100644 index 648e9c1cad6..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_netvisor.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _netvisor_platform_options: - -********************************** -Pluribus NETVISOR Platform Options -********************************** - -Pluribus NETVISOR Ansible is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. -This page offers details on how to use ``ansible.netcommon.network_cli`` on NETVISOR in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| not supported by NETVISOR - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -Pluribus NETVISOR does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/netvisor.yml`` ---------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.netcommon.netvisor - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Create access list - community.network.pn_access_list: - pn_name: "foo" - pn_scope: "local" - state: "present" - register: acc_list - when: ansible_network_os == 'community.network.netvisor' - - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_nos.rst b/docs/docsite/rst/network/user_guide/platform_nos.rst deleted file mode 100644 index 6bc244c8d9b..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_nos.rst +++ /dev/null @@ -1,76 +0,0 @@ -.. _nos_platform_options: - -*************************************** -NOS Platform Options -*************************************** - -Extreme NOS is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. -This page offers details on how to use ``ansible.netcommon.network_cli`` on NOS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: community.netcommon.network_cli`` - - |enable_mode| not supported by NOS - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -NOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/nos.yml`` ----------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.nos - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Get version information (nos) - community.network.nos_command: - commands: "show version" - register: show_ver - when: ansible_network_os == 'community.network.nos' - - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_nxos.rst b/docs/docsite/rst/network/user_guide/platform_nxos.rst deleted file mode 100644 index 73912389488..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_nxos.rst +++ /dev/null @@ -1,166 +0,0 @@ -.. _nxos_platform_options: - -*************************************** -NXOS Platform Options -*************************************** - -The `Cisco NXOS `_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== ========================= - .. CLI NX-API - ==================== ========================================== ========================= - Protocol SSH HTTP(S) - - Credentials uses SSH keys / SSH-agent if present uses HTTPS certificates if - present - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) by a web proxy - - Connection Settings ``ansible_connection:`` ``ansible_connection:`` - ``ansible.netcommon.network_cli`` ``ansible.netcommon.httpapi`` - - |enable_mode| supported: use ``ansible_become: true`` not supported by NX-API - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` ``stdout[0].messages[0].`` - ==================== ========================================== ========================= - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) |br| supported as of 2.5.3 - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.httpapi`` instead. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/nxos.yml`` ------------------------------------ - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: cisco.nxos.nxos - ansible_user: myuser - ansible_password: !vault... - ansible_become: true - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (nxos) - cisco.nxos.nxos_config: - backup: yes - register: backup_nxos_location - when: ansible_network_os == 'cisco.nxos.nxos' - - - -Using NX-API in Ansible -======================= - -Enabling NX-API ---------------- - -Before you can use NX-API to connect to a switch, you must enable NX-API. To enable NX-API on a new switch through Ansible, use the ``nxos_nxapi`` module through the CLI connection. Set up group_vars/nxos.yml just like in the CLI example above, then run a playbook task like this: - -.. code-block:: yaml - - - name: Enable NX-API - cisco.nxos.nxos_nxapi: - enable_http: yes - enable_https: yes - when: ansible_network_os == 'cisco.nxos.nxos' - -To find out more about the options for enabling HTTP/HTTPS and local http see the :ref:`nxos_nxapi ` module documentation. - -Once NX-API is enabled, change your ``group_vars/nxos.yml`` to use the NX-API connection. - -Example NX-API ``group_vars/nxos.yml`` --------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.httpapi - ansible_network_os: cisco.nxos.nxos - ansible_user: myuser - ansible_password: !vault... - proxy_env: - http_proxy: http://proxy.example.com:8080 - -- If you are accessing your host directly (not through a web proxy) you can remove the ``proxy_env`` configuration. -- If you are accessing your host through a web proxy using ``https``, change ``http_proxy`` to ``https_proxy``. - - -Example NX-API task -------------------- - -.. code-block:: yaml - - - name: Backup current switch config (nxos) - cisco.nxos.nxos_config: - backup: yes - register: backup_nxos_location - environment: "{{ proxy_env }}" - when: ansible_network_os == 'cisco.nxos.nxos' - -In this example the ``proxy_env`` variable defined in ``group_vars`` gets passed to the ``environment`` option of the module used in the task. - -.. include:: shared_snippets/SSH_warning.txt - -Cisco Nexus platform support matrix -=================================== - -The following platforms and software versions have been certified by Cisco to work with this version of Ansible. - -.. table:: Platform / Software Minimum Requirements - :align: center - - =================== ===================== - Supported Platforms Minimum NX-OS Version - =================== ===================== - Cisco Nexus N3k 7.0(3)I2(5) and later - Cisco Nexus N9k 7.0(3)I2(5) and later - Cisco Nexus N5k 7.3(0)N1(1) and later - Cisco Nexus N6k 7.3(0)N1(1) and later - Cisco Nexus N7k 7.3(0)D1(1) and later - Cisco Nexus MDS 8.4(1) and later (Please see individual module documentation for compatibility) - =================== ===================== - -.. table:: Platform Models - :align: center - - ======== ============================================== - Platform Description - ======== ============================================== - N3k Support includes N30xx, N31xx and N35xx models - N5k Support includes all N5xxx models - N6k Support includes all N6xxx models - N7k Support includes all N7xxx models - N9k Support includes all N9xxx models - MDS Support includes all MDS 9xxx models - ======== ============================================== - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_routeros.rst b/docs/docsite/rst/network/user_guide/platform_routeros.rst deleted file mode 100644 index 842ad4c424e..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_routeros.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _routeros_platform_options: - -*************************************** -RouterOS Platform Options -*************************************** - -RouterOS is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. -This page offers details on how to use ``ansible.netcommon.network_cli`` on RouterOS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.network.network_cli`` - - |enable_mode| not supported by RouterOS - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -RouterOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/routeros.yml`` ---------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.routeros - ansible_user: myuser - ansible_password: !vault... - ansible_become: true - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. -- If you are getting timeout errors you may want to add ``+cet1024w`` suffix to your username which will disable console colors, enable "dumb" mode, tell RouterOS not to try detecting terminal capabilities and set terminal width to 1024 columns. See article `Console login process `_ in MikroTik wiki for more information. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Display resource statistics (routeros) - community.network.routeros_command: - commands: /system resource print - register: routeros_resources - when: ansible_network_os == 'community.network.routeros' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_slxos.rst b/docs/docsite/rst/network/user_guide/platform_slxos.rst deleted file mode 100644 index 4c4145130ca..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_slxos.rst +++ /dev/null @@ -1,77 +0,0 @@ -.. _slxos_platform_options: - -*************************************** -SLX-OS Platform Options -*************************************** - -Extreme SLX-OS is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. -This page offers details on how to use ``ansible.netcommon.network_cli`` on SLX-OS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| not supported by SLX-OS - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -SLX-OS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/slxos.yml`` ------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.slxos - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (slxos) - community.network.slxos_config: - backup: yes - register: backup_slxos_location - when: ansible_network_os == 'community.network.slxos' - - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_voss.rst b/docs/docsite/rst/network/user_guide/platform_voss.rst deleted file mode 100644 index a66e42e65bb..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_voss.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _voss_platform_options: - -*************************************** -VOSS Platform Options -*************************************** - -Extreme VOSS is part of the `community.network `_ collection and only supports CLI connections today. This page offers details on how to -use ``ansible.netcommon.network_cli`` on VOSS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: true`` - with ``ansible_become_method: enable`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -VOSS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/voss.yml`` ------------------------------------ - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.voss - ansible_user: myuser - ansible_become: true - ansible_become_method: enable - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve VOSS info - community.network.voss_command: - commands: show sys-info - when: ansible_network_os == 'community.network.voss' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_vyos.rst b/docs/docsite/rst/network/user_guide/platform_vyos.rst deleted file mode 100644 index f101fe778c5..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_vyos.rst +++ /dev/null @@ -1,74 +0,0 @@ -.. _vyos_platform_options: - -*************************************** -VyOS Platform Options -*************************************** - -The `VyOS `_ collection supports the ``ansible.netcommon.network_cli`` connection type. This page offers details on connection options to manage VyOS using Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| not supported - - Returned Data Format Refer to individual module documentation - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/vyos.yml`` ------------------------------------ - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: vyos.vyos.vyos - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve VyOS version info - vyos.vyos.vyos_command: - commands: show version - when: ansible_network_os == 'vyos.vyos.vyos' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_weos4.rst b/docs/docsite/rst/network/user_guide/platform_weos4.rst deleted file mode 100644 index dd5dc83290d..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_weos4.rst +++ /dev/null @@ -1,88 +0,0 @@ -.. _weos4_platform_options: - -*************************************** -WeOS 4 Platform Options -*************************************** - -Westermo WeOS 4 is part of the `community.network `_ collection and only supports CLI connections. -This page offers details on how to use ``ansible.netcommon.network_cli`` on WeOS 4 in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: community.netcommon.network_cli`` - - |enable_mode| not supported by WeOS 4 - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -WeOS 4 does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/weos4.yml`` ------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.weos4 - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Get version information (WeOS 4) - ansible.netcommon.cli_command: - commands: "show version" - register: show_ver - when: ansible_network_os == 'community.network.weos4' - -Example Configuration task --------------------------- - -.. code-block:: yaml - - - name: Replace configuration with file on ansible host (WeOS 4) - ansible.netcommon.cli_config: - config: "{{ lookup('file', 'westermo.conf') }}" - replace: "yes" - diff_match: exact - diff_replace: config - when: ansible_network_os == 'community.network.weos4' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/shared_snippets/SSH_warning.txt b/docs/docsite/rst/network/user_guide/shared_snippets/SSH_warning.txt deleted file mode 100644 index 27424f57776..00000000000 --- a/docs/docsite/rst/network/user_guide/shared_snippets/SSH_warning.txt +++ /dev/null @@ -1,2 +0,0 @@ -.. warning:: - Never store passwords in plain text. We recommend using SSH keys to authenticate SSH connections. Ansible supports ssh-agent to manage your SSH keys. If you must use passwords to authenticate SSH connections, we recommend encrypting them with :ref:`Ansible Vault `. diff --git a/docs/docsite/rst/network/user_guide/validate.rst b/docs/docsite/rst/network/user_guide/validate.rst deleted file mode 100644 index aeda1b2436a..00000000000 --- a/docs/docsite/rst/network/user_guide/validate.rst +++ /dev/null @@ -1,164 +0,0 @@ -.. _validate_data: - -************************************************* -Validate data against set criteria with Ansible -************************************************* - -The :ref:`validate ` module validates data against your predefined criteria using a validation engine. You can pull this data from a device or file, validate it against your defined criteria, and use the results to identify configuration or operational state drift and optionally take remedial action. - - -.. contents:: - :local: - -Understanding the validate plugin -================================== - -The `ansible.utils `_ collection includes the :ref:`validate ` module. - -To validate data: - -#. Pull in structured data or convert your data to structured format with the :ref:`cli_parse ` module. -#. Define the criteria to test that data against. -#. Select a validation engine and test the data to see if it is valid based on the selected criteria and validation engine. - -The structure of the data and the criteria depends on the validation engine you select. The examples here use the ``jsonschema`` validation engine provided in the `ansible.utils `_ collection.Red Hat Ansible Automation Platform subscription supports limited use if jsonschema public APIs as documented. - -Structuring the data -===================== - -You can pull previously structured data from a file, or use the :ref:`cli_parse ` module to structure your data. - -The following example fetches the operational state of some network (Cisco NXOS) interfaces and translates that state to structured data using the ``ansible.netcommon.pyats`` parser. - -.. code-block:: yaml - - --- - - hosts: nxos - connection: ansible.netcommon.network_cli - gather_facts: false - vars: - ansible_network_os: cisco.nxos.nxos - ansible_user: "changeme" - ansible_password: "changeme" - - tasks: - - name: "Fetch interface state and parse with pyats" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.netcommon.pyats - register: nxos_pyats_show_interface - - - name: print structured interface state data - ansible.builtin.debug: - msg: "{{ nxos_pyats_show_interface['parsed'] }}" - ---- - -This results in the following structured data. - -.. code-block:: text - - ok: [nxos] => { - "changed": false, - "parsed": { - "Ethernet2/1": { - "admin_state": "down", - "auto_mdix": "off", - "auto_negotiate": false, - "bandwidth": 1000000, - "beacon": "off" - <--output omitted--> - }, - "Ethernet2/10": { - "admin_state": "down", - "auto_mdix": "off", - "auto_negotiate": false, - "bandwidth": 1000000, - "beacon": "off", - <--output omitted--> - } - } - } - -See :ref:`cli_parsing` for details on how to parse semi-structured data into structured data. - -Defining the criteria to validate against -========================================= - -This example uses the `jsonschema `_ validation engine to parse the JSON structured data we created in the prior section. the criteria defines the state we want the data to conform to. In this instance, we can validate against a desired admin state of ``up`` for all the interfaces. - -The criteria for ``jsonschema`` in this example is as follows: - -.. code-block:: text - - $cat criteria/nxos_show_interface_admin_criteria.json - { - "type" : "object", - "patternProperties": { - "^.*": { - "type": "object", - "properties": { - "admin_state": { - "type": "string", - "pattern": "up" - } - } - } - } - } - -Validating the data -==================== - -Now that we have the structured data and the criteria, we can validate this data with the :ref:`validate ` module. - -The following tasks check if the current state of the interfaces match the desired state defined in the criteria file. - -.. code-block:: yaml - - - name: Validate interface admin state - ansible.utils.validate: - data: "{{ nxos_pyats_show_interface['parsed'] }}" - criteria: - - "{{ lookup('file', './criteria/nxos_show_interface_admin_criteria.json') | from_json }}" - engine: ansible.utils.jsonschema - ignore_errors: true - register: result - - - name: Print the interface names that do not satisfy the desired state - ansible.builtin.debug: - msg: "{{ item['data_path'].split('.')[0] }}" - loop: "{{ result['errors'] }}" - when: "'errors' in result" - - -In these tasks, we have: - -#. Set ``data`` to the structured JSON data from the :ref:`cli_parse ` module. -#. Set ``criteria`` to the JSON criteria file we defined. -#. Set the validate engine to ``jsonschema``. - -.. note:: - - The value of the criteria option can be a list and should be in a format that is defined by the validation engine used. You need to install the `jsonschema `_ on the control node for this example. - -The tasks output a list of errors indicating interfaces that do not have admin value in ``up`` state. - -.. code-block:: text - - TASK [Validate interface for admin state] *********************************************************************************************************** - fatal: [nxos02]: FAILED! => {"changed": false, "errors": [{"data_path": "Ethernet2/1.admin_state", "expected": "up", "found": "down", "json_path": "$.Ethernet2/1.admin_state", "message": "'down' does not match 'up'", "relative_schema": {"pattern": "up", "type": "string"}, "schema_path": "patternProperties.^.*.properties.admin_state.pattern", "validator": "pattern"}, {"data_path": "Ethernet2/10.admin_state", "expected": "up", "found": "down", "json_path": "$.Ethernet2/10.admin_state", "message": "'down' does not match 'up'", "relative_schema": {"pattern": "up", "type": "string"}, "schema_path": "patternProperties.^.*.properties.admin_state.pattern", "validator": "pattern"}], "msg": "Validation errors were found.\nAt 'patternProperties.^.*.properties.admin_state.pattern' 'down' does not match 'up'. \nAt 'patternProperties.^.*.properties.admin_state.pattern' 'down' does not match 'up'. \nAt 'patternProperties.^.*.properties.admin_state.pattern' 'down' does not match 'up'. "} - ...ignoring - - - TASK [Print the interface names that do not satisfy the desired state] **************************************************************************** - Monday 14 December 2020 11:05:38 +0530 (0:00:01.661) 0:00:28.676 ******* - ok: [nxos] => { - "msg": "Ethernet2/1" - } - ok: [nxos] => { - "msg": "Ethernet2/10" - } - - -This shows Ethernet2/1 and Ethernet2/10 are not in the desired state based on the defined criteria. You can create a report or take further action to remediate this to bring the interfaces to the desired state based on the defined criteria. diff --git a/docs/docsite/rst/os_guide/index.rst b/docs/docsite/rst/os_guide/index.rst deleted file mode 100644 index 210a69b1c56..00000000000 --- a/docs/docsite/rst/os_guide/index.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. _os_guide_index: - -################################ -Using Ansible on Windows and BSD -################################ - -.. 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 `_. - -Welcome to the Ansible guide for Microsoft Windows and BSD. -Because Windows is not a POSIX-compliant operating system, Ansible interacts with Windows hosts differently to Linux/Unix hosts. -Likewise managing hosts that run BSD is different to managing other Unix-like host operating systems. -Find out everything you need to know about using Ansible on Windows and with BSD hosts. - -.. toctree:: - :maxdepth: 2 - - windows_setup - windows_usage - windows_winrm - windows_dsc - windows_performance - windows_faq - intro_bsd \ No newline at end of file diff --git a/docs/docsite/rst/os_guide/intro_bsd.rst b/docs/docsite/rst/os_guide/intro_bsd.rst deleted file mode 100644 index 6e92b2a3d4e..00000000000 --- a/docs/docsite/rst/os_guide/intro_bsd.rst +++ /dev/null @@ -1,278 +0,0 @@ -.. _working_with_bsd: - -Managing BSD hosts with Ansible -=============================== - -Managing BSD machines is different from managing other Unix-like machines. If you have managed nodes running BSD, review these topics. - -.. contents:: - :local: - -Connecting to BSD nodes ------------------------ - -Ansible connects to managed nodes using OpenSSH by default. This works on BSD if you use SSH keys for authentication. However, if you use SSH passwords for authentication, Ansible relies on sshpass. Most -versions of sshpass do not deal well with BSD login prompts, so when using SSH passwords against BSD machines, use ``paramiko`` to connect instead of OpenSSH. You can do this in ansible.cfg globally or you can set it as an inventory/group/host variable. For example: - -.. code-block:: text - - [freebsd] - mybsdhost1 ansible_connection=paramiko - -.. _bootstrap_bsd: - -Bootstrapping BSD ------------------ - -Ansible is agentless by default, however, it requires Python on managed nodes. Only the :ref:`raw ` module will operate without Python. Although this module can be used to bootstrap Ansible and install Python on BSD variants (see below), it is very limited and the use of Python is required to make full use of Ansible's features. - -The following example installs Python which includes the json library required for full functionality of Ansible. -On your control machine you can execute the following for most versions of FreeBSD: - -.. code-block:: bash - - ansible -m raw -a "pkg install -y python" mybsdhost1 - -Or for OpenBSD: - -.. code-block:: bash - - ansible -m raw -a "pkg_add python%3.8" - -Once this is done you can now use other Ansible modules apart from the ``raw`` module. - -.. note:: - This example demonstrated using pkg on FreeBSD and pkg_add on OpenBSD, however you should be able to substitute the appropriate package tool for your BSD; the package name may also differ. Refer to the package list or documentation of the BSD variant you are using for the exact Python package name you intend to install. - -.. BSD_python_location: - -Setting the Python interpreter ------------------------------- - -To support a variety of Unix-like operating systems and distributions, Ansible cannot always rely on the existing environment or ``env`` variables to locate the correct Python binary. By default, modules point at ``/usr/bin/python`` as this is the most common location. On BSD variants, this path may differ, so it is advised to inform Ansible of the binary's location. See :ref:`INTERPRETER_PYTHON`. For example, set ``ansible_python_interpreter`` inventory variable: - -.. code-block:: ini - - [freebsd:vars] - ansible_python_interpreter=/usr/local/bin/python - [openbsd:vars] - ansible_python_interpreter=/usr/local/bin/python3.8 - - -FreeBSD packages and ports -"""""""""""""""""""""""""" - -In FreeBSD, there is no guarantee that either ``/usr/local/bin/python`` executable file or a link to an executable file is installed by default. The best practice for a remote host, with respect to Ansible, is to install at least the Python version supported by Ansible, for example, ``lang/python38``, and both meta ports ``lang/python3`` and ``lang/python``. Quoting from */usr/ports/lang/python3/pkg-descr*: - -.. code-block:: text - - This is a meta port to the Python 3.x interpreter and provides symbolic links - to bin/python3, bin/pydoc3, bin/idle3 and so on to allow compatibility with - minor version agnostic python scripts. - -Quoting from */usr/ports/lang/python/pkg-descr*: - -.. code-block:: text - - This is a meta port to the Python interpreter and provides symbolic links - to bin/python, bin/pydoc, bin/idle and so on to allow compatibility with - version agnostic python scripts. - -As a result, the following packages are installed: - -.. code-block:: text - - shell> pkg info | grep python - python-3.8_3,2 "meta-port" for the default version of Python interpreter - python3-3_3 Meta-port for the Python interpreter 3.x - python38-3.8.12_1 Interpreted object-oriented programming language - -and the following executables and links - -.. code-block:: text - - shell> ll /usr/local/bin/ | grep python - lrwxr-xr-x 1 root wheel 7 Jan 24 08:30 python@ -> python3 - lrwxr-xr-x 1 root wheel 14 Jan 24 08:30 python-config@ -> python3-config - lrwxr-xr-x 1 root wheel 9 Jan 24 08:29 python3@ -> python3.8 - lrwxr-xr-x 1 root wheel 16 Jan 24 08:29 python3-config@ -> python3.8-config - -r-xr-xr-x 1 root wheel 5248 Jan 13 01:12 python3.8* - -r-xr-xr-x 1 root wheel 3153 Jan 13 01:12 python3.8-config* - - -INTERPRETER_PYTHON_FALLBACK -""""""""""""""""""""""""""" - -Since version 2.8 Ansible provides a useful variable ``ansible_interpreter_python_fallback`` to specify a list of paths to search for Python. See :ref:`INTERPRETER_PYTHON_FALLBACK`. This list will be searched and the first item found will be used. For example, the configuration below would make the installation of the meta-ports in the previous section redundant, that is, if you don't install the Python meta ports the first two items in the list will be skipped and ``/usr/local/bin/python3.8`` will be discovered. - -.. code-block:: ini - - ansible_interpreter_python_fallback=['/usr/local/bin/python', '/usr/local/bin/python3', '/usr/local/bin/python3.8'] - - -You can use this variable, prolonged by the lower versions of Python, and put it, for example, into the ``group_vars/all``. Then, override it for specific groups in ``group_vars/{group1, group2, ...}`` and for specific hosts in ``host_vars/{host1, host2, ...}`` if needed. See :ref:`ansible_variable_precedence`. - - -Debug the discovery of Python -""""""""""""""""""""""""""""" - -For example, given the inventory - -.. code-block:: ini - - shell> cat hosts - [test] - test_11 - test_12 - test_13 - - [test:vars] - ansible_connection=ssh - ansible_user=admin - ansible_become=true - ansible_become_user=root - ansible_become_method=sudo - ansible_interpreter_python_fallback=['/usr/local/bin/python', '/usr/local/bin/python3', '/usr/local/bin/python3.8'] - ansible_perl_interpreter=/usr/local/bin/perl - -The playbook below - -.. code-block:: yaml+jinja - - shell> cat playbook.yml - - hosts: test_11 - gather_facts: false - tasks: - - command: which python - register: result - - debug: - var: result.stdout - - debug: - msg: |- - {% for i in _vars %} - {{ i }}: - {{ lookup('vars', i)|to_nice_yaml|indent(2) }} - {% endfor %} - vars: - _vars: "{{ query('varnames', '.*python.*') }}" - -displays the details - -.. code-block:: yaml - - shell> ansible-playbook -i hosts playbook.yml - - PLAY [test_11] ******************************************************************************* - - TASK [command] ******************************************************************************* - [WARNING]: Platform freebsd on host test_11 is using the discovered Python interpreter at - /usr/local/bin/python, but future installation of another Python interpreter could change the - meaning of that path. See https://docs.ansible.com/ansible- - core/2.12/reference_appendices/interpreter_discovery.html for more information. - changed: [test_11] - - TASK [debug] ********************************************************************************* - ok: [test_11] => - result.stdout: /usr/local/bin/python - - TASK [debug] ********************************************************************************* - ok: [test_11] => - msg: |- - ansible_interpreter_python_fallback: - - /usr/local/bin/python - - /usr/local/bin/python3 - - /usr/local/bin/python3.8 - - discovered_interpreter_python: - /usr/local/bin/python - - ansible_playbook_python: - /usr/bin/python3 - -You can see that the first item from the list ``ansible_interpreter_python_fallback`` was discovered at the FreeBSD remote host. The variable ``ansible_playbook_python`` keeps the path to Python at the Linux controller that ran the playbook. - -Regarding the warning, quoting from :ref:`INTERPRETER_PYTHON` - -.. code-block:: text - - The fallback behavior will issue a warning that the interpreter - should be set explicitly (since interpreters installed later may - change which one is used). This warning behavior can be disabled by - setting auto_silent or auto_legacy_silent. ... - -You can either ignore it or get rid of it by setting the variable ``ansible_python_interpreter=auto_silent`` because this is, actually, what you want by using ``/usr/local/bin/python`` (*"interpreters installed later may change which one is used"*). For example - -.. code-block:: ini - - shell> cat hosts - [test] - test_11 - test_12 - test_13 - - [test:vars] - ansible_connection=ssh - ansible_user=admin - ansible_become=true - ansible_become_user=root - ansible_become_method=sudo - ansible_interpreter_python_fallback=['/usr/local/bin/python', '/usr/local/bin/python3', '/usr/local/bin/python3.8'] - ansible_python_interpreter=auto_silent - ansible_perl_interpreter=/usr/local/bin/perl - - -.. seealso:: - - * :ref:`interpreter_discovery` - * `FreeBSD Wiki: Ports/DEFAULT_VERSIONS `_ - - -Additional variables -"""""""""""""""""""" - -If you use additional plugins beyond those bundled with Ansible, you can set similar variables for ``bash``, ``perl`` or ``ruby``, depending on how the plugin is written. For example: - -.. code-block:: ini - - [freebsd:vars] - ansible_python_interpreter=/usr/local/bin/python - ansible_perl_interpreter=/usr/local/bin/perl - - -Which modules are available? ----------------------------- - -The majority of the core Ansible modules are written for a combination of Unix-like machines and other generic services, so most should function well on the BSDs with the obvious exception of those that are aimed at Linux-only technologies (such as LVG). - -Using BSD as the control node ------------------------------ - -Using BSD as the control machine is as simple as installing the Ansible package for your BSD variant or by following the ``pip`` or 'from source' instructions. - -.. _bsd_facts: - -BSD facts ---------- - -Ansible gathers facts from the BSDs in a similar manner to Linux machines, but since the data, names and structures can vary for network, disks and other devices, one should expect the output to be slightly different yet still familiar to a BSD administrator. - -.. _bsd_contributions: - -BSD efforts and contributions ------------------------------ - -BSD support is important to us at Ansible. Even though the majority of our contributors use and target Linux we have an active BSD community and strive to be as BSD-friendly as possible. -Please feel free to report any issues or incompatibilities you discover with BSD; pull requests with an included fix are also welcome! - -.. seealso:: - - :ref:`intro_adhoc` - Examples of basic commands - :ref:`working_with_playbooks` - Learning ansible's configuration management language - :ref:`developing_modules` - How to write modules - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/os_guide/windows_dsc.rst b/docs/docsite/rst/os_guide/windows_dsc.rst deleted file mode 100644 index 1588a2329fc..00000000000 --- a/docs/docsite/rst/os_guide/windows_dsc.rst +++ /dev/null @@ -1,508 +0,0 @@ -.. _windows_dsc: - -Desired State Configuration -=========================== - -.. contents:: Topics - :local: - -What is Desired State Configuration? -```````````````````````````````````` -Desired State Configuration, or DSC, is a tool built into PowerShell that can -be used to define a Windows host setup through code. The overall purpose of DSC -is the same as Ansible, it is just executed in a different manner. Since -Ansible 2.4, the ``win_dsc`` module has been added and can be used to take advantage of -existing DSC resources when interacting with a Windows host. - -More details on DSC can be viewed at `DSC Overview `_. - -Host Requirements -````````````````` -To use the ``win_dsc`` module, a Windows host must have PowerShell v5.0 or -newer installed. All supported hosts can be upgraded to PowerShell v5. - -Once the PowerShell requirements have been met, using DSC is as simple as -creating a task with the ``win_dsc`` module. - -Why Use DSC? -```````````` -DSC and Ansible modules have a common goal which is to define and ensure the state of a -resource. Because of -this, resources like the DSC `File resource `_ -and Ansible ``win_file`` can be used to achieve the same result. Deciding which to use depends -on the scenario. - -Reasons for using an Ansible module over a DSC resource: - -* The host does not support PowerShell v5.0, or it cannot easily be upgraded -* The DSC resource does not offer a feature present in an Ansible module. For example, - win_regedit can manage the ``REG_NONE`` property type, while the DSC - ``Registry`` resource cannot -* DSC resources have limited check mode support, while some Ansible modules have - better checks -* DSC resources do not support diff mode, while some Ansible modules do -* Custom resources require further installation steps to be run on the host - beforehand, while Ansible modules are built-in to Ansible -* There are bugs in a DSC resource where an Ansible module works - -Reasons for using a DSC resource over an Ansible module: - -* The Ansible module does not support a feature present in a DSC resource -* There is no Ansible module available -* There are bugs in an existing Ansible module - -In the end, it doesn't matter whether the task is performed with DSC or an -Ansible module; what matters is that the task is performed correctly and the -playbooks are still readable. If you have more experience with DSC over Ansible -and it does the job, just use DSC for that task. - -How to Use DSC? -``````````````` -The ``win_dsc`` module takes in a free-form of options so that it changes -according to the resource it is managing. A list of built-in resources can be -found at `resources `_. - -Using the `Registry `_ -resource as an example, this is the DSC definition as documented by Microsoft: - -.. code-block:: powershell - - Registry [string] #ResourceName - { - Key = [string] - ValueName = [string] - [ Ensure = [string] { Enable | Disable } ] - [ Force = [bool] ] - [ Hex = [bool] ] - [ DependsOn = [string[]] ] - [ ValueData = [string[]] ] - [ ValueType = [string] { Binary | Dword | ExpandString | MultiString | Qword | String } ] - } - -When defining the task, ``resource_name`` must be set to the DSC resource being -used - in this case, the ``resource_name`` should be set to ``Registry``. The -``module_version`` can refer to a specific version of the DSC resource -installed; if left blank it will default to the latest version. The other -options are parameters that are used to define the resource, such as ``Key`` and -``ValueName``. While the options in the task are not case sensitive, -keeping the case as-is is recommended because it makes it easier to distinguish DSC -resource options from Ansible's ``win_dsc`` options. - -This is what the Ansible task version of the above DSC Registry resource would look like: - -.. code-block:: yaml+jinja - - - name: Use win_dsc module with the Registry DSC resource - win_dsc: - resource_name: Registry - Ensure: Present - Key: HKEY_LOCAL_MACHINE\SOFTWARE\ExampleKey - ValueName: TestValue - ValueData: TestData - -Starting in Ansible 2.8, the ``win_dsc`` module automatically validates the -input options from Ansible with the DSC definition. This means Ansible will -fail if the option name is incorrect, a mandatory option is not set, or the -value is not a valid choice. When running Ansible with a verbosity level of 3 -or more (``-vvv``), the return value will contain the possible invocation -options based on the ``resource_name`` specified. Here is an example of the -invocation output for the above ``Registry`` task: - -.. code-block:: ansible-output - - changed: [2016] => { - "changed": true, - "invocation": { - "module_args": { - "DependsOn": null, - "Ensure": "Present", - "Force": null, - "Hex": null, - "Key": "HKEY_LOCAL_MACHINE\\SOFTWARE\\ExampleKey", - "PsDscRunAsCredential_password": null, - "PsDscRunAsCredential_username": null, - "ValueData": [ - "TestData" - ], - "ValueName": "TestValue", - "ValueType": null, - "module_version": "latest", - "resource_name": "Registry" - } - }, - "module_version": "1.1", - "reboot_required": false, - "verbose_set": [ - "Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = ResourceSet,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'.", - "An LCM method call arrived from computer SERVER2016 with user sid S-1-5-21-3088887838-4058132883-1884671576-1105.", - "[SERVER2016]: LCM: [ Start Set ] [[Registry]DirectResourceAccess]", - "[SERVER2016]: [[Registry]DirectResourceAccess] (SET) Create registry key 'HKLM:\\SOFTWARE\\ExampleKey'", - "[SERVER2016]: [[Registry]DirectResourceAccess] (SET) Set registry key value 'HKLM:\\SOFTWARE\\ExampleKey\\TestValue' to 'TestData' of type 'String'", - "[SERVER2016]: LCM: [ End Set ] [[Registry]DirectResourceAccess] in 0.1930 seconds.", - "[SERVER2016]: LCM: [ End Set ] in 0.2720 seconds.", - "Operation 'Invoke CimMethod' complete.", - "Time taken for configuration job to complete is 0.402 seconds" - ], - "verbose_test": [ - "Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = ResourceTest,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'.", - "An LCM method call arrived from computer SERVER2016 with user sid S-1-5-21-3088887838-4058132883-1884671576-1105.", - "[SERVER2016]: LCM: [ Start Test ] [[Registry]DirectResourceAccess]", - "[SERVER2016]: [[Registry]DirectResourceAccess] Registry key 'HKLM:\\SOFTWARE\\ExampleKey' does not exist", - "[SERVER2016]: LCM: [ End Test ] [[Registry]DirectResourceAccess] False in 0.2510 seconds.", - "[SERVER2016]: LCM: [ End Set ] in 0.3310 seconds.", - "Operation 'Invoke CimMethod' complete.", - "Time taken for configuration job to complete is 0.475 seconds" - ] - } - -The ``invocation.module_args`` key shows the actual values that were set as -well as other possible values that were not set. Unfortunately, this will not -show the default value for a DSC property, only what was set from the Ansible -task. Any ``*_password`` option will be masked in the output for security -reasons; if there are any other sensitive module options, set ``no_log: True`` -on the task to stop all task output from being logged. - - -Property Types --------------- -Each DSC resource property has a type that is associated with it. Ansible -will try to convert the defined options to the correct type during execution. -For simple types like ``[string]`` and ``[bool]``, this is a simple operation, -but complex types like ``[PSCredential]`` or arrays (like ``[string[]]``) -require certain rules. - -PSCredential -++++++++++++ -A ``[PSCredential]`` object is used to store credentials in a secure way, but -Ansible has no way to serialize this over JSON. To set a DSC PSCredential property, -the definition of that parameter should have two entries that are suffixed with -``_username`` and ``_password`` for the username and password, respectively. -For example: - -.. code-block:: yaml+jinja - - PsDscRunAsCredential_username: '{{ ansible_user }}' - PsDscRunAsCredential_password: '{{ ansible_password }}' - - SourceCredential_username: AdminUser - SourceCredential_password: PasswordForAdminUser - -.. Note:: On versions of Ansible older than 2.8, you should set ``no_log: true`` - on the task definition in Ansible to ensure any credentials used are not - stored in any log file or console output. - -A ``[PSCredential]`` is defined with ``EmbeddedInstance("MSFT_Credential")`` in -a DSC resource MOF definition. - -CimInstance Type -++++++++++++++++ -A ``[CimInstance]`` object is used by DSC to store a dictionary object based on -a custom class defined by that resource. Defining a value that takes in a -``[CimInstance]`` in YAML is the same as defining a dictionary in YAML. -For example, to define a ``[CimInstance]`` value in Ansible: - -.. code-block:: yaml+jinja - - # [CimInstance]AuthenticationInfo == MSFT_xWebAuthenticationInformation - AuthenticationInfo: - Anonymous: false - Basic: true - Digest: false - Windows: true - -In the above example, the CIM instance is a representation of the class -`MSFT_xWebAuthenticationInformation `_. -This class accepts four boolean variables, ``Anonymous``, ``Basic``, -``Digest``, and ``Windows``. The keys to use in a ``[CimInstance]`` depend on -the class it represents. Please read through the documentation of the resource -to determine the keys that can be used and the types of each key value. The -class definition is typically located in the ``.schema.mof``. - -HashTable Type -++++++++++++++ -A ``[HashTable]`` object is also a dictionary but does not have a strict set of -keys that can/need to be defined. Like a ``[CimInstance]``, define it as a -normal dictionary value in YAML. A ``[HashTable]]`` is defined with -``EmbeddedInstance("MSFT_KeyValuePair")`` in a DSC resource MOF definition. - -Arrays -++++++ -Simple type arrays like ``[string[]]`` or ``[UInt32[]]`` are defined as a list -or as a comma-separated string which is then cast to their type. Using a list -is recommended because the values are not manually parsed by the ``win_dsc`` -module before being passed to the DSC engine. For example, to define a simple -type array in Ansible: - -.. code-block:: yaml+jinja - - # [string[]] - ValueData: entry1, entry2, entry3 - ValueData: - - entry1 - - entry2 - - entry3 - - # [UInt32[]] - ReturnCode: 0,3010 - ReturnCode: - - 0 - - 3010 - -Complex type arrays like ``[CimInstance[]]`` (array of dicts), can be defined -like this example: - -.. code-block:: yaml+jinja - - # [CimInstance[]]BindingInfo == MSFT_xWebBindingInformation - BindingInfo: - - Protocol: https - Port: 443 - CertificateStoreName: My - CertificateThumbprint: C676A89018C4D5902353545343634F35E6B3A659 - HostName: DSCTest - IPAddress: '*' - SSLFlags: 1 - - Protocol: http - Port: 80 - IPAddress: '*' - -The above example is an array with two values of the class `MSFT_xWebBindingInformation `_. -When defining a ``[CimInstance[]]``, be sure to read the resource documentation -to find out what keys to use in the definition. - -DateTime -++++++++ -A ``[DateTime]`` object is a DateTime string representing the date and time in -the `ISO 8601 `_ date time format. The -value for a ``[DateTime]`` field should be quoted in YAML to ensure the string -is properly serialized to the Windows host. Here is an example of how to define -a ``[DateTime]`` value in Ansible: - -.. code-block:: yaml+jinja - - # As UTC-0 (No timezone) - DateTime: '2019-02-22T13:57:31.2311892+00:00' - - # As UTC+4 - DateTime: '2019-02-22T17:57:31.2311892+04:00' - - # As UTC-4 - DateTime: '2019-02-22T09:57:31.2311892-04:00' - -All the values above are equal to a UTC date time of February 22nd 2019 at -1:57pm with 31 seconds and 2311892 milliseconds. - -Run As Another User -------------------- -By default, DSC runs each resource as the SYSTEM account and not the account -that Ansible uses to run the module. This means that resources that are dynamically -loaded based on a user profile, like the ``HKEY_CURRENT_USER`` registry hive, -will be loaded under the ``SYSTEM`` profile. The parameter -``PsDscRunAsCredential`` is a parameter that can be set for every DSC resource, and -force the DSC engine to run under a different account. As -``PsDscRunAsCredential`` has a type of ``PSCredential``, it is defined with the -``_username`` and ``_password`` suffix. - -Using the Registry resource type as an example, this is how to define a task -to access the ``HKEY_CURRENT_USER`` hive of the Ansible user: - -.. code-block:: yaml+jinja - - - name: Use win_dsc with PsDscRunAsCredential to run as a different user - win_dsc: - resource_name: Registry - Ensure: Present - Key: HKEY_CURRENT_USER\ExampleKey - ValueName: TestValue - ValueData: TestData - PsDscRunAsCredential_username: '{{ ansible_user }}' - PsDscRunAsCredential_password: '{{ ansible_password }}' - no_log: true - -Custom DSC Resources -```````````````````` -DSC resources are not limited to the built-in options from Microsoft. Custom -modules can be installed to manage other resources that are not usually available. - -Finding Custom DSC Resources ----------------------------- -You can use the -`PSGallery `_ to find custom resources, along with documentation on how to install them on a Windows host. - -The ``Find-DscResource`` cmdlet can also be used to find custom resources. For example: - -.. code-block:: powershell - - # Find all DSC resources in the configured repositories - Find-DscResource - - # Find all DSC resources that relate to SQL - Find-DscResource -ModuleName "*sql*" - -.. Note:: DSC resources developed by Microsoft that start with ``x`` means the - resource is experimental and comes with no support. - -Installing a Custom Resource ----------------------------- -There are three ways that a DSC resource can be installed on a host: - -* Manually with the ``Install-Module`` cmdlet -* Using the ``win_psmodule`` Ansible module -* Saving the module manually and copying it to another host - -The following is an example of installing the ``xWebAdministration`` resources using -``win_psmodule``: - -.. code-block:: yaml+jinja - - - name: Install xWebAdministration DSC resource - win_psmodule: - name: xWebAdministration - state: present - -Once installed, the win_dsc module will be able to use the resource by referencing it -with the ``resource_name`` option. - -The first two methods above only work when the host has access to the internet. -When a host does not have internet access, the module must first be installed -using the methods above on another host with internet access and then copied -across. To save a module to a local filepath, the following PowerShell cmdlet -can be run: - -.. code-block:: powershell - - Save-Module -Name xWebAdministration -Path C:\temp - -This will create a folder called ``xWebAdministration`` in ``C:\temp``, which -can be copied to any host. For PowerShell to see this offline resource, it must -be copied to a directory set in the ``PSModulePath`` environment variable. -In most cases, the path ``C:\Program Files\WindowsPowerShell\Module`` is set -through this variable, but the ``win_path`` module can be used to add different -paths. - -Examples -```````` -Extract a zip file ------------------- - -.. code-block:: yaml+jinja - - - name: Extract a zip file - win_dsc: - resource_name: Archive - Destination: C:\temp\output - Path: C:\temp\zip.zip - Ensure: Present - -Create a directory ------------------- - -.. code-block:: yaml+jinja - - - name: Create file with some text - win_dsc: - resource_name: File - DestinationPath: C:\temp\file - Contents: | - Hello - World - Ensure: Present - Type: File - - - name: Create directory that is hidden is set with the System attribute - win_dsc: - resource_name: File - DestinationPath: C:\temp\hidden-directory - Attributes: Hidden,System - Ensure: Present - Type: Directory - -Interact with Azure -------------------- - -.. code-block:: yaml+jinja - - - name: Install xAzure DSC resources - win_psmodule: - name: xAzure - state: present - - - name: Create virtual machine in Azure - win_dsc: - resource_name: xAzureVM - ImageName: a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-201409.01-en.us-127GB.vhd - Name: DSCHOST01 - ServiceName: ServiceName - StorageAccountName: StorageAccountName - InstanceSize: Medium - Windows: true - Ensure: Present - Credential_username: '{{ ansible_user }}' - Credential_password: '{{ ansible_password }}' - -Setup IIS Website ------------------ - -.. code-block:: yaml+jinja - - - name: Install xWebAdministration module - win_psmodule: - name: xWebAdministration - state: present - - - name: Install IIS features that are required - win_dsc: - resource_name: WindowsFeature - Name: '{{ item }}' - Ensure: Present - loop: - - Web-Server - - Web-Asp-Net45 - - - name: Setup web content - win_dsc: - resource_name: File - DestinationPath: C:\inetpub\IISSite\index.html - Type: File - Contents: | - - IIS Site - This is the body - - Ensure: present - - - name: Create new website - win_dsc: - resource_name: xWebsite - Name: NewIISSite - State: Started - PhysicalPath: C:\inetpub\IISSite\index.html - BindingInfo: - - Protocol: https - Port: 8443 - CertificateStoreName: My - CertificateThumbprint: C676A89018C4D5902353545343634F35E6B3A659 - HostName: DSCTest - IPAddress: '*' - SSLFlags: 1 - - Protocol: http - Port: 8080 - IPAddress: '*' - AuthenticationInfo: - Anonymous: false - Basic: true - Digest: false - Windows: true - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - :ref:`List of Windows Modules ` - Windows specific module list, all implemented in PowerShell - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/os_guide/windows_faq.rst b/docs/docsite/rst/os_guide/windows_faq.rst deleted file mode 100644 index f64f2a952d4..00000000000 --- a/docs/docsite/rst/os_guide/windows_faq.rst +++ /dev/null @@ -1,249 +0,0 @@ -.. _windows_faq: - -Windows Frequently Asked Questions -================================== - -Here are some commonly asked questions in regards to Ansible and Windows and -their answers. - -.. note:: This document covers questions about managing Microsoft Windows servers with Ansible. - For questions about Ansible Core, please see the - :ref:`general FAQ page `. - -Does Ansible work with Windows XP or Server 2003? -`````````````````````````````````````````````````` -Ansible does not work with Windows XP or Server 2003 hosts. Ansible does work with these Windows operating system versions: - -* Windows Server 2016 -* Windows Server 2019 -* Windows Server 2022 -* Windows 10 -* Windows 11 - -Support for Windows Server 2008, 2008 R2, and Windows 7 ended in the 2.10 -release. Support for Windows Server 2012, 2012 R2, Windows 8, and 8.1 ended in -the 2.16 release. - -Ansible also has minimum PowerShell version requirements - please see -:ref:`windows_setup` for the latest information. - -Can I manage Windows Nano Server with Ansible? -`````````````````````````````````````````````` -Ansible does not currently work with Windows Nano Server, since it does -not have access to the full .NET Framework that is used by the majority of the -modules and internal components. - -.. _windows_faq_ansible: - -Can Ansible run on Windows? -``````````````````````````` -No, Ansible can only manage Windows hosts. Ansible cannot run on a Windows host -natively, though it can run under the Windows Subsystem for Linux (WSL). - -.. note:: The Windows Subsystem for Linux is not supported by Ansible and - should not be used for production systems. - -To install Ansible on WSL, the following commands -can be run in the bash terminal: - -.. code-block:: shell - - sudo apt-get update - sudo apt-get install python3-pip git libffi-dev libssl-dev -y - pip install --user ansible pywinrm - -To run Ansible from source instead of a release on the WSL, simply uninstall the pip -installed version and then clone the git repo. - -.. code-block:: shell - - pip uninstall ansible -y - git clone https://github.com/ansible/ansible.git - source ansible/hacking/env-setup - - # To enable Ansible on login, run the following - echo ". ~/ansible/hacking/env-setup -q' >> ~/.bashrc - -If you encounter timeout errors when running Ansible on the WSL, this may be due to an issue -with ``sleep`` not returning correctly. The following workaround may resolve the issue: - -.. code-block:: shell - - mv /usr/bin/sleep /usr/bin/sleep.orig - ln -s /bin/true /usr/bin/sleep - -Another option is to use WSL 2 if running Windows 10 later than build 2004. - -.. code-block:: shell - - wsl --set-default-version 2 - - -Can I use SSH keys to authenticate to Windows hosts? -```````````````````````````````````````````````````` -You cannot use SSH keys with the WinRM or PSRP connection plugins. -These connection plugins use X509 certificates for authentication instead -of the SSH key pairs that SSH uses. - -The way X509 certificates are generated and mapped to a user is different -from the SSH implementation; consult the :ref:`windows_winrm` documentation for -more information. - -Ansible 2.8 has added an experimental option to use the SSH connection plugin, -which uses SSH keys for authentication, for Windows servers. See :ref:`this question ` -for more information. - -.. _windows_faq_winrm: - -Why can I run a command locally that does not work under Ansible? -````````````````````````````````````````````````````````````````` -Ansible executes commands through WinRM. These processes are different from -running a command locally in these ways: - -* Unless using an authentication option like CredSSP or Kerberos with - credential delegation, the WinRM process does not have the ability to - delegate the user's credentials to a network resource, causing ``Access is - Denied`` errors. - -* All processes run under WinRM are in a non-interactive session. Applications - that require an interactive session will not work. - -* When running through WinRM, Windows restricts access to internal Windows - APIs like the Windows Update API and DPAPI, which some installers and - programs rely on. - -Some ways to bypass these restrictions are to: - -* Use ``become``, which runs a command as it would when run locally. This will - bypass most WinRM restrictions, as Windows is unaware the process is running - under WinRM when ``become`` is used. See the :ref:`become` documentation for more - information. - -* Use a scheduled task, which can be created with ``win_scheduled_task``. Like - ``become``, it will bypass all WinRM restrictions, but it can only be used to run - commands, not modules. - -* Use ``win_psexec`` to run a command on the host. PSExec does not use WinRM - and so will bypass any of the restrictions. - -* To access network resources without any of these workarounds, you can use - CredSSP or Kerberos with credential delegation enabled. - -See :ref:`become` more info on how to use become. The limitations section at -:ref:`windows_winrm` has more details around WinRM limitations. - -This program won't install on Windows with Ansible -`````````````````````````````````````````````````` -See :ref:`this question ` for more information about WinRM limitations. - -What Windows modules are available? -``````````````````````````````````` -Most of the Ansible modules in Ansible Core are written for a combination of -Linux/Unix machines and arbitrary web services. These modules are written in -Python and most of them do not work on Windows. - -Because of this, there are dedicated Windows modules that are written in -PowerShell and are meant to be run on Windows hosts. A list of these modules -can be found :ref:`here `. - -In addition, the following Ansible Core modules/action-plugins work with Windows: - -* add_host -* assert -* async_status -* debug -* fail -* fetch -* group_by -* include -* include_role -* include_vars -* meta -* pause -* raw -* script -* set_fact -* set_stats -* setup -* slurp -* template (also: win_template) -* wait_for_connection - -Ansible Windows modules exist in the :ref:`plugins_in_ansible.windows`, :ref:`plugins_in_community.windows`, and :ref:`plugins_in_chocolatey.chocolatey` collections. - -Can I run Python modules on Windows hosts? -`````````````````````````````````````````` -No, the WinRM connection protocol is set to use PowerShell modules, so Python -modules will not work. A way to bypass this issue to use -``delegate_to: localhost`` to run a Python module on the Ansible controller. -This is useful if during a playbook, an external service needs to be contacted -and there is no equivalent Windows module available. - -.. _windows_faq_ssh: - -Can I connect to Windows hosts over SSH? -```````````````````````````````````````` -Ansible 2.8 has added an experimental option to use the SSH connection plugin -to manage Windows hosts. To connect to Windows hosts over SSH, you must install and configure the `Win32-OpenSSH `_ -fork that is in development with Microsoft on -the Windows host(s). While most of the basics should work with SSH, -``Win32-OpenSSH`` is rapidly changing, with new features added and bugs -fixed in every release. It is highly recommend you `install `_ the latest release -of ``Win32-OpenSSH`` from the GitHub Releases page when using it with Ansible -on Windows hosts. - -To use SSH as the connection to a Windows host, set the following variables in -the inventory: - -.. code-block:: shell - - ansible_connection=ssh - - # Set either cmd or powershell not both - ansible_shell_type=cmd - # ansible_shell_type=powershell - -The value for ``ansible_shell_type`` should either be ``cmd`` or ``powershell``. -Use ``cmd`` if the ``DefaultShell`` has not been configured on the SSH service -and ``powershell`` if that has been set as the ``DefaultShell``. - -Why is connecting to a Windows host through SSH failing? -```````````````````````````````````````````````````````` -Unless you are using ``Win32-OpenSSH`` as described above, you must connect to -Windows hosts using :ref:`windows_winrm`. If your Ansible output indicates that -SSH was used, either you did not set the connection vars properly or the host is not inheriting them correctly. - -Make sure ``ansible_connection: winrm`` is set in the inventory for the Windows -host(s). - -Why are my credentials being rejected? -`````````````````````````````````````` -This can be due to a myriad of reasons unrelated to incorrect credentials. - -See HTTP 401/Credentials Rejected at :ref:`windows_setup` for a more detailed -guide of this could mean. - -Why am I getting an error SSL CERTIFICATE_VERIFY_FAILED? -```````````````````````````````````````````````````````` -When the Ansible controller is running on Python 2.7.9+ or an older version of Python that -has backported SSLContext (like Python 2.7.5 on RHEL 7), the controller will attempt to -validate the certificate WinRM is using for an HTTPS connection. If the -certificate cannot be validated (such as in the case of a self signed cert), it will -fail the verification process. - -To ignore certificate validation, add -``ansible_winrm_server_cert_validation: ignore`` to inventory for the Windows -host. - -.. seealso:: - - :ref:`windows` - The Windows documentation index - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/os_guide/windows_performance.rst b/docs/docsite/rst/os_guide/windows_performance.rst deleted file mode 100644 index c922b4d9edd..00000000000 --- a/docs/docsite/rst/os_guide/windows_performance.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. _windows_performance: - -Windows performance -=================== -This document offers some performance optimizations you might like to apply to -your Windows hosts to speed them up specifically in the context of using Ansible -with them, and generally. - -Optimize PowerShell performance to reduce Ansible task overhead ---------------------------------------------------------------- -To speed up the startup of PowerShell by around 10x, run the following -PowerShell snippet in an Administrator session. Expect it to take tens of -seconds. - -.. note:: - - If native images have already been created by the ngen task or service, you - will observe no difference in performance (but this snippet will at that - point execute faster than otherwise). - -.. code-block:: powershell - - function Optimize-PowershellAssemblies { - # NGEN powershell assembly, improves startup time of powershell by 10x - $old_path = $env:path - try { - $env:path = [Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory() - [AppDomain]::CurrentDomain.GetAssemblies() | % { - if (! $_.location) {continue} - $Name = Split-Path $_.location -leaf - if ($Name.startswith("Microsoft.PowerShell.")) { - Write-Progress -Activity "Native Image Installation" -Status "$name" - ngen install $_.location | % {"`t$_"} - } - } - } finally { - $env:path = $old_path - } - } - Optimize-PowershellAssemblies - -PowerShell is used by every Windows Ansible module. This optimization reduces -the time PowerShell takes to start up, removing that overhead from every invocation. - -This snippet uses `the native image generator, ngen `_ -to pre-emptively create native images for the assemblies that PowerShell relies on. - -Fix high-CPU-on-boot for VMs/cloud instances --------------------------------------------- -If you are creating golden images to spawn instances from, you can avoid a disruptive -high CPU task near startup through `processing the ngen queue `_ -within your golden image creation, if you know the CPU types won't change between -golden image build process and runtime. - -Place the following near the end of your playbook, bearing in mind the factors that can cause native images to be invalidated (`see MSDN `_). - -.. code-block:: yaml - - - name: generate native .NET images for CPU - win_dotnet_ngen: - diff --git a/docs/docsite/rst/os_guide/windows_setup.rst b/docs/docsite/rst/os_guide/windows_setup.rst deleted file mode 100644 index 78381c19690..00000000000 --- a/docs/docsite/rst/os_guide/windows_setup.rst +++ /dev/null @@ -1,499 +0,0 @@ -.. _windows_setup: - -Setting up a Windows Host -========================= -This document discusses the setup that is required before Ansible can communicate with a Microsoft Windows host. - -.. contents:: - :local: - -Host Requirements -````````````````` -For Ansible to communicate to a Windows host and use Windows modules, the -Windows host must meet these base requirements for connectivity: - -* With Ansible you can generally manage Windows versions under the current and extended support from Microsoft. You can also manage desktop OSs including Windows 10 and 11, and server OSs including Windows Server 2016, 2019, and 2022. - -* You need to install PowerShell 5.1 or newer and at least .NET 4.0 on the Windows host. - -* You need to create and activate a WinRM listener. More details, see `WinRM Setup `_. - -.. Note:: Some Ansible modules have additional requirements, such as a newer OS or PowerShell version. Consult the module documentation page to determine whether a host meets those requirements. - -Upgrading PowerShell and .NET Framework ---------------------------------------- -Ansible requires PowerShell version 5.1 and .NET Framework 4.6 or newer to function. The base image for older unsupported OS' do not meet these -requirement. You can use the `Upgrade-PowerShell.ps1 `_ script to update these. - -This is an example of how to run this script from PowerShell: - -.. code-block:: powershell - - [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 - $url = "https://raw.githubusercontent.com/jborean93/ansible-windows/master/scripts/Upgrade-PowerShell.ps1" - $file = "$env:temp\Upgrade-PowerShell.ps1" - $username = "Administrator" - $password = "Password" - - (New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file) - Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force - - &$file -Version 5.1 -Username $username -Password $password -Verbose - -In the script, the ``file`` value can be the PowerShell version 3.0, 4.0, or 5.1. - -Once completed, you need to run the following PowerShell commands: - -1. As an optional but good security practice, you can set the execution policy back to the default. - -.. code-block:: powershell - - Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force - -Use the ``RemoteSigned`` value for Windows servers, or ``Restricted`` for Windows clients. - -2. Remove the auto logon. - -.. code-block:: powershell - - $reg_winlogon_path = "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" - Set-ItemProperty -Path $reg_winlogon_path -Name AutoAdminLogon -Value 0 - Remove-ItemProperty -Path $reg_winlogon_path -Name DefaultUserName -ErrorAction SilentlyContinue - Remove-ItemProperty -Path $reg_winlogon_path -Name DefaultPassword -ErrorAction SilentlyContinue - -The script determines what programs you need to install (such as .NET Framework 4.5.2) and what PowerShell version needs to be present. If a reboot is needed and the ``username`` and ``password`` parameters are set, the script will automatically reboot the machine and then logon. If the ``username`` and ``password`` parameters are not set, the script will prompt the user to manually reboot and logon when required. When the user is next logged in, the script will continue where it left off and the process continues until no more -actions are required. - -.. Note:: If you run the script on Server 2008, then you need to install SP2. For Server 2008 R2 or Windows 7 you need SP1. - - On Windows Server 2008 you can install only PowerShell 3.0. A newer version will result in the script failure. - - The ``username`` and ``password`` parameters are stored in plain text in the registry. Run the cleanup commands after the script finishes to ensure no credentials are stored on the host. - - -WinRM Memory Hotfix -------------------- -On PowerShell v3.0, there is a bug that limits the amount of memory available to the WinRM service. Use the `Install-WMF3Hotfix.ps1 `_ script to install a hotfix on affected hosts as part of the system bootstrapping or imaging process. Without this hotfix, Ansible fails to execute certain commands on the Windows host. - -To install the hotfix: - -.. code-block:: powershell - - [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 - $url = "https://raw.githubusercontent.com/jborean93/ansible-windows/master/scripts/Install-WMF3Hotfix.ps1" - $file = "$env:temp\Install-WMF3Hotfix.ps1" - - (New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file) - powershell.exe -ExecutionPolicy ByPass -File $file -Verbose - -For more details, refer to the `"Out of memory" error on a computer that has a customized MaxMemoryPerShellMB quota set and has WMF 3.0 installed `_ article. - -WinRM Setup -``````````` -You need to configure the WinRM service so that Ansible can connect to it. There are two main components of the WinRM service that governs how Ansible can interface with the Windows host: the ``listener`` and the ``service`` configuration settings. - -WinRM Listener --------------- -The WinRM services listen for requests on one or more ports. Each of these ports must have a listener created and configured. - -To view the current listeners that are running on the WinRM service: - -.. code-block:: powershell - - winrm enumerate winrm/config/Listener - -This will output something like: - -.. code-block:: powershell - - Listener - Address = * - Transport = HTTP - Port = 5985 - Hostname - Enabled = true - URLPrefix = wsman - CertificateThumbprint - ListeningOn = 10.0.2.15, 127.0.0.1, 192.168.56.155, ::1, fe80::5efe:10.0.2.15%6, fe80::5efe:192.168.56.155%8, fe80:: - ffff:ffff:fffe%2, fe80::203d:7d97:c2ed:ec78%3, fe80::e8ea:d765:2c69:7756%7 - - Listener - Address = * - Transport = HTTPS - Port = 5986 - Hostname = SERVER2016 - Enabled = true - URLPrefix = wsman - CertificateThumbprint = E6CDAA82EEAF2ECE8546E05DB7F3E01AA47D76CE - ListeningOn = 10.0.2.15, 127.0.0.1, 192.168.56.155, ::1, fe80::5efe:10.0.2.15%6, fe80::5efe:192.168.56.155%8, fe80:: - ffff:ffff:fffe%2, fe80::203d:7d97:c2ed:ec78%3, fe80::e8ea:d765:2c69:7756%7 - -In the example above there are two listeners activated. One is listening on port 5985 over HTTP and the other is listening on port 5986 over HTTPS. Some of the key options that are useful to understand are: - -* ``Transport``: Whether the listener is run over HTTP or HTTPS. We recommend you use a listener over HTTPS because the data is encrypted without any further changes required. - -* ``Port``: The port the listener runs on. By default it is ``5985`` for HTTP and ``5986`` for HTTPS. This port can be changed to whatever is required and corresponds to the host var ``ansible_port``. - -* ``URLPrefix``: The URL prefix to listen on. By default it is ``wsman``. If you change this option, you need to set the host var ``ansible_winrm_path`` to the same value. - -* ``CertificateThumbprint``: If you use an HTTPS listener, this is the thumbprint of the certificate in the Windows Certificate Store that is used in the connection. To get the details of the certificate itself, run this command with the relevant certificate thumbprint in PowerShell: - -.. code-block:: powershell - - $thumbprint = "E6CDAA82EEAF2ECE8546E05DB7F3E01AA47D76CE" - Get-ChildItem -Path cert:\LocalMachine\My -Recurse | Where-Object { $_.Thumbprint -eq $thumbprint } | Select-Object * - -Setup WinRM Listener -++++++++++++++++++++ -There are three ways to set up a WinRM listener: - -* Using ``winrm quickconfig`` for HTTP or ``winrm quickconfig -transport:https`` for HTTPS. This is the easiest option to use when running outside of a domain environment and a simple listener is required. Unlike the other options, this process also has the added benefit of opening up the firewall for the ports required and starts the WinRM service. - -* Using Group Policy Objects (GPO). This is the best way to create a listener when the host is a member of a domain because the configuration is done automatically without any user input. For more information on group policy objects, see the `Group Policy Objects documentation `_. - -* Using PowerShell to create a listener with a specific configuration. This can be done by running the following PowerShell commands: - - .. code-block:: powershell - - $selector_set = @{ - Address = "*" - Transport = "HTTPS" - } - $value_set = @{ - CertificateThumbprint = "E6CDAA82EEAF2ECE8546E05DB7F3E01AA47D76CE" - } - - New-WSManInstance -ResourceURI "winrm/config/Listener" -SelectorSet $selector_set -ValueSet $value_set - - To see the other options with this PowerShell command, refer to the - `New-WSManInstance `_ documentation. - -.. Note:: When creating an HTTPS listener, you must create and store a certificate in the ``LocalMachine\My`` certificate store. - -Delete WinRM Listener -+++++++++++++++++++++ -* To remove all WinRM listeners: - -.. code-block:: powershell - - Remove-Item -Path WSMan:\localhost\Listener\* -Recurse -Force - -* To remove only those listeners that run over HTTPS: - -.. code-block:: powershell - - Get-ChildItem -Path WSMan:\localhost\Listener | Where-Object { $_.Keys -contains "Transport=HTTPS" } | Remove-Item -Recurse -Force - -.. Note:: The ``Keys`` object is an array of strings, so it can contain different values. By default, it contains a key for ``Transport=`` and ``Address=`` which correspond to the values from the ``winrm enumerate winrm/config/Listeners`` command. - -WinRM Service Options ---------------------- -You can control the behavior of the WinRM service component, including authentication options and memory settings. - -To get an output of the current service configuration options, run the following command: - -.. code-block:: powershell - - winrm get winrm/config/Service - winrm get winrm/config/Winrs - -This will output something like: - -.. code-block:: powershell - - Service - RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD) - MaxConcurrentOperations = 4294967295 - MaxConcurrentOperationsPerUser = 1500 - EnumerationTimeoutms = 240000 - MaxConnections = 300 - MaxPacketRetrievalTimeSeconds = 120 - AllowUnencrypted = false - Auth - Basic = true - Kerberos = true - Negotiate = true - Certificate = true - CredSSP = true - CbtHardeningLevel = Relaxed - DefaultPorts - HTTP = 5985 - HTTPS = 5986 - IPv4Filter = * - IPv6Filter = * - EnableCompatibilityHttpListener = false - EnableCompatibilityHttpsListener = false - CertificateThumbprint - AllowRemoteAccess = true - - Winrs - AllowRemoteShellAccess = true - IdleTimeout = 7200000 - MaxConcurrentUsers = 2147483647 - MaxShellRunTime = 2147483647 - MaxProcessesPerShell = 2147483647 - MaxMemoryPerShellMB = 2147483647 - MaxShellsPerUser = 2147483647 - -You do not need to change the majority of these options. However, some of the important ones to know about are: - -* ``Service\AllowUnencrypted`` - specifies whether WinRM will allow HTTP traffic without message encryption. Message level encryption is only possible when the ``ansible_winrm_transport`` variable is ``ntlm``, ``kerberos`` or ``credssp``. By default, this is ``false`` and you should only set it to ``true`` when debugging WinRM messages. - -* ``Service\Auth\*`` - defines what authentication options you can use with the WinRM service. By default, ``Negotiate (NTLM)`` and ``Kerberos`` are enabled. - -* ``Service\Auth\CbtHardeningLevel`` - specifies whether channel binding tokens are not verified (None), verified but not required (Relaxed), or verified and required (Strict). CBT is only used when connecting with NT LAN Manager (NTLM) or Kerberos over HTTPS. - -* ``Service\CertificateThumbprint`` - thumbprint of the certificate for encrypting the TLS channel used with CredSSP authentication. By default, this is empty. A self-signed certificate is generated when the WinRM service starts and is used in the TLS process. - -* ``Winrs\MaxShellRunTime`` - maximum time, in milliseconds, that a remote command is allowed to execute. - -* ``Winrs\MaxMemoryPerShellMB`` - maximum amount of memory allocated per shell, including its child processes. - -To modify a setting under the ``Service`` key in PowerShell, you need to provide a path to the option after ``winrm/config/Service``: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Service\{path} -Value {some_value} - -For example, to change ``Service\Auth\CbtHardeningLevel``: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Service\Auth\CbtHardeningLevel -Value Strict - -To modify a setting under the ``Winrs`` key in PowerShell, you need to provide a path to the option after ``winrm/config/Winrs``: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Shell\{path} -Value {some_value} - -For example, to change ``Winrs\MaxShellRunTime``: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Shell\MaxShellRunTime -Value 2147483647 - -.. Note:: If you run the command in a domain environment, some of these options are set by - GPO and cannot be changed on the host itself. When you configured a key with GPO, it contains the text ``[Source="GPO"]`` next to the value. - -Common WinRM Issues -------------------- -WinRM has a wide range of configuration options, which makes its configuration complex. As a result, errors that Ansible displays could in fact be problems with the host setup instead. - -To identify a host issue, run the following command from another Windows host to connect to the target Windows host. - -* To test HTTP: - -.. code-block:: powershell - - winrs -r:http://server:5985/wsman -u:Username -p:Password ipconfig - -* To test HTTPS: - -.. code-block:: powershell - - winrs -r:https://server:5986/wsman -u:Username -p:Password -ssl ipconfig - -The command will fail if the certificate is not verifiable. - -* To test HTTPS ignoring certificate verification: - -.. code-block:: powershell - - $username = "Username" - $password = ConvertTo-SecureString -String "Password" -AsPlainText -Force - $cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $password - - $session_option = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck - Invoke-Command -ComputerName server -UseSSL -ScriptBlock { ipconfig } -Credential $cred -SessionOption $session_option - -If any of the above commands fail, the issue is probably related to the WinRM setup. - -HTTP 401/Credentials Rejected -+++++++++++++++++++++++++++++ -An HTTP 401 error indicates the authentication process failed during the initial -connection. You can check the following to troubleshoot: - -* The credentials are correct and set properly in your inventory with the ``ansible_user`` and ``ansible_password`` variables. - -* The user is a member of the local Administrators group, or has been explicitly granted access. You can perform a connection test with the ``winrs`` command to rule this out. - -* The authentication option set by the ``ansible_winrm_transport`` variable is enabled under ``Service\Auth\*``. - -* If running over HTTP and not HTTPS, use ``ntlm``, ``kerberos`` or ``credssp`` with the ``ansible_winrm_message_encryption: auto`` custom inventory variable to enable message encryption. If you use another authentication option, or if it is not possible to upgrade the installed ``pywinrm`` package, you can set ``Service\AllowUnencrypted`` to ``true``. This is recommended only for troubleshooting. - -* The downstream packages ``pywinrm``, ``requests-ntlm``, ``requests-kerberos``, and/or ``requests-credssp`` are up to date using ``pip``. - -* For Kerberos authentication, ensure that ``Service\Auth\CbtHardeningLevel`` is not set to ``Strict``. - -* For Basic or Certificate authentication, make sure that the user is a local account. Domain accounts do not work with Basic and Certificate authentication. - -HTTP 500 Error -++++++++++++++ -An HTTP 500 error indicates a problem with the WinRM service. You can check the following to troubleshoot: - -* The number of your currently open shells has not exceeded either ``WinRsMaxShellsPerUser``. Alternatively, you did not exceed any of the other Winrs quotas. - -Timeout Errors -+++++++++++++++ -Sometimes Ansible is unable to reach the host. These instances usually indicate a problem with the network connection. You can check the following to troubleshoot: - -* The firewall is not set to block the configured WinRM listener ports. -* A WinRM listener is enabled on the port and path set by the host vars. -* The ``winrm`` service is running on the Windows host and is configured for the automatic start. - -Connection Refused Errors -+++++++++++++++++++++++++ -When you communicate with the WinRM service on the host you can encounter some problems. Check the following to help the troubleshooting: - -* The WinRM service is up and running on the host. Use the ``(Get-Service -Name winrm).Status`` command to get the status of the service. -* The host firewall is allowing traffic over the WinRM port. By default this is ``5985`` for HTTP and ``5986`` for HTTPS. - -Sometimes an installer may restart the WinRM or HTTP service and cause this error. The best way to deal with this is to use the ``win_psexec`` module from another Windows host. - -Failure to Load Builtin Modules -+++++++++++++++++++++++++++++++ -Sometimes PowerShell fails with an error message similar to: - -.. code-block:: powershell - - The 'Out-String' command was found in the module 'Microsoft.PowerShell.Utility', but the module could not be loaded. - -In that case, there could be a problem when trying to access all the paths specified by the ``PSModulePath`` environment variable. - -A common cause of this issue is that ``PSModulePath`` contains a Universal Naming Convention (UNC) path to a file share. Additionally, the double hop/credential delegation issue causes that the Ansible process cannot access these folders. To work around this problem is to either: - -* Remove the UNC path from ``PSModulePath``. - -or - -* Use an authentication option that supports credential delegation like ``credssp`` or ``kerberos``. You need to have the credential delegation enabled. - -See `KB4076842 `_ for more information on this problem. - -Windows SSH Setup -````````````````` -Ansible 2.8 has added an experimental SSH connection for Windows managed nodes. - -.. warning:: - Use this feature at your own risk! Using SSH with Windows is experimental. This implementation may make - backwards incompatible changes in future releases. The server-side components can be unreliable depending on your installed version. - -Installing OpenSSH using Windows Settings ------------------------------------------ -You can use OpenSSH to connect Window 10 clients to Windows Server 2019. OpenSSH Client is available to install on Windows 10 build 1809 and later. OpenSSH Server is available to install on Windows Server 2019 and later. - -For more information, refer to `Get started with OpenSSH for Windows `_. - -Installing Win32-OpenSSH ------------------------- -To install the `Win32-OpenSSH `_ service for use with -Ansible, select one of these installation options: - -* Manually install ``Win32-OpenSSH``, following the `install instructions `_ from Microsoft. - -* Use Chocolatey: - -.. code-block:: powershell - - choco install --package-parameters=/SSHServerFeature openssh - -* Use the ``win_chocolatey`` Ansible module: - -.. code-block:: yaml - - - name: install the Win32-OpenSSH service - win_chocolatey: - name: openssh - package_params: /SSHServerFeature - state: present - -* Install an Ansible Galaxy role for example `jborean93.win_openssh `_: - -.. code-block:: powershell - - ansible-galaxy install jborean93.win_openssh - -* Use the role in your playbook: - -.. code-block:: yaml - - - name: install Win32-OpenSSH service - hosts: windows - gather_facts: false - roles: - - role: jborean93.win_openssh - opt_openssh_setup_service: True - -.. note:: ``Win32-OpenSSH`` is still a beta product and is constantly being updated to include new features and bugfixes. If you use SSH as a connection option for Windows, we highly recommend you install the latest version. - -Configuring the Win32-OpenSSH shell ------------------------------------ - -By default ``Win32-OpenSSH`` uses ``cmd.exe`` as a shell. - -* To configure a different shell, use an Ansible playbook with a task to define the registry setting: - -.. code-block:: yaml - - - name: set the default shell to PowerShell - win_regedit: - path: HKLM:\SOFTWARE\OpenSSH - name: DefaultShell - data: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe - type: string - state: present - -* To revert the settings back to the default shell: - -.. code-block:: yaml - - - name: set the default shell to cmd - win_regedit: - path: HKLM:\SOFTWARE\OpenSSH - name: DefaultShell - state: absent - -Win32-OpenSSH Authentication ----------------------------- -Win32-OpenSSH authentication with Windows is similar to SSH authentication on Unix/Linux hosts. You can use a plaintext password or SSH public key authentication. - -For the key-based authentication: - -* Add your public keys to an ``authorized_key`` file in the ``.ssh`` folder of the user's profile directory. - -* Configure the SSH service using the ``sshd_config`` file. - -When using SSH key authentication with Ansible, the remote session will not have access to user credentials and will fail when attempting to access a network resource. This is also known as the double-hop or credential delegation issue. To work around this problem: - -* Use plaintext password authentication by setting the ``ansible_password`` variable. -* Use the ``become`` directive on the task with the credentials of the user that needs access to the remote resource. - -Configuring Ansible for SSH on Windows --------------------------------------- -To configure Ansible to use SSH for Windows hosts, you must set two connection variables: - -* set ``ansible_connection`` to ``ssh`` -* set ``ansible_shell_type`` to ``cmd`` or ``powershell`` - -The ``ansible_shell_type`` variable should reflect the ``DefaultShell`` configured on the Windows host. Set ``ansible_shell_type`` to ``cmd`` for the default shell. Alternatively, set ``ansible_shell_type`` to ``powershell`` if you changed ``DefaultShell`` to PowerShell. - -Known issues with SSH on Windows --------------------------------- -Using SSH with Windows is experimental. Currently existing issues are: - -* Win32-OpenSSH versions older than ``v7.9.0.0p1-Beta`` do not work when ``powershell`` is the shell type. -* While Secure Copy Protocol (SCP) should work, SSH File Transfer Protocol (SFTP) is the recommended mechanism to use when copying or fetching a file. - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - :ref:`List of Windows Modules ` - Windows specific module list, all implemented in PowerShell - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/os_guide/windows_usage.rst b/docs/docsite/rst/os_guide/windows_usage.rst deleted file mode 100644 index 0e76646efab..00000000000 --- a/docs/docsite/rst/os_guide/windows_usage.rst +++ /dev/null @@ -1,519 +0,0 @@ -.. _windows_usage: - -Using Ansible and Windows -========================= -When using Ansible to manage Windows, many of the syntax and rules that apply -for Unix/Linux hosts also apply to Windows, but there are still some differences -when it comes to components like path separators and OS-specific tasks. -This document covers details specific to using Ansible for Windows. - -.. contents:: Topics - :local: - -Use Cases -````````` -Ansible can be used to orchestrate a multitude of tasks on Windows servers. -Below are some examples and info about common tasks. - -Installing Software -------------------- -There are three main ways that Ansible can be used to install software: - -* Using the ``win_chocolatey`` module. This sources the program data from the default - public `Chocolatey `_ repository. Internal repositories can - be used instead by setting the ``source`` option. - -* Using the ``win_package`` module. This installs software using an MSI or .exe installer - from a local/network path or URL. - -* Using the ``win_command`` or ``win_shell`` module to run an installer manually. - -The ``win_chocolatey`` module is recommended since it has the most complete logic for checking to see if a package has already been installed and is up-to-date. - -Below are some examples of using all three options to install 7-Zip: - -.. code-block:: yaml+jinja - - # Install/uninstall with chocolatey - - name: Ensure 7-Zip is installed through Chocolatey - win_chocolatey: - name: 7zip - state: present - - - name: Ensure 7-Zip is not installed through Chocolatey - win_chocolatey: - name: 7zip - state: absent - - # Install/uninstall with win_package - - name: Download the 7-Zip package - win_get_url: - url: https://www.7-zip.org/a/7z1701-x64.msi - dest: C:\temp\7z.msi - - - name: Ensure 7-Zip is installed through win_package - win_package: - path: C:\temp\7z.msi - state: present - - - name: Ensure 7-Zip is not installed through win_package - win_package: - path: C:\temp\7z.msi - state: absent - - # Install/uninstall with win_command - - name: Download the 7-Zip package - win_get_url: - url: https://www.7-zip.org/a/7z1701-x64.msi - dest: C:\temp\7z.msi - - - name: Check if 7-Zip is already installed - win_reg_stat: - name: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{23170F69-40C1-2702-1701-000001000000} - register: 7zip_installed - - - name: Ensure 7-Zip is installed through win_command - win_command: C:\Windows\System32\msiexec.exe /i C:\temp\7z.msi /qn /norestart - when: 7zip_installed.exists == false - - - name: Ensure 7-Zip is uninstalled through win_command - win_command: C:\Windows\System32\msiexec.exe /x {23170F69-40C1-2702-1701-000001000000} /qn /norestart - when: 7zip_installed.exists == true - -Some installers like Microsoft Office or SQL Server require credential delegation or -access to components restricted by WinRM. The best method to bypass these -issues is to use ``become`` with the task. With ``become``, Ansible will run -the installer as if it were run interactively on the host. - -.. Note:: Many installers do not properly pass back error information over WinRM. In these cases, if the install has been verified to work locally the recommended method is to use become. - -.. Note:: Some installers restart the WinRM or HTTP services, or cause them to become temporarily unavailable, making Ansible assume the system is unreachable. - -Installing Updates ------------------- -The ``win_updates`` and ``win_hotfix`` modules can be used to install updates -or hotfixes on a host. The module ``win_updates`` is used to install multiple -updates by category, while ``win_hotfix`` can be used to install a single -update or hotfix file that has been downloaded locally. - -.. Note:: The ``win_hotfix`` module has a requirement that the DISM PowerShell cmdlets are - present. These cmdlets were only added by default on Windows Server 2012 - and newer and must be installed on older Windows hosts. - -The following example shows how ``win_updates`` can be used: - -.. code-block:: yaml+jinja - - - name: Install all critical and security updates - win_updates: - category_names: - - CriticalUpdates - - SecurityUpdates - state: installed - register: update_result - - - name: Reboot host if required - win_reboot: - when: update_result.reboot_required - -The following example show how ``win_hotfix`` can be used to install a single -update or hotfix: - -.. code-block:: yaml+jinja - - - name: Download KB3172729 for Server 2012 R2 - win_get_url: - url: http://download.windowsupdate.com/d/msdownload/update/software/secu/2016/07/windows8.1-kb3172729-x64_e8003822a7ef4705cbb65623b72fd3cec73fe222.msu - dest: C:\temp\KB3172729.msu - - - name: Install hotfix - win_hotfix: - hotfix_kb: KB3172729 - source: C:\temp\KB3172729.msu - state: present - register: hotfix_result - - - name: Reboot host if required - win_reboot: - when: hotfix_result.reboot_required - -Set Up Users and Groups ------------------------ -Ansible can be used to create Windows users and groups both locally and on a domain. - -Local -+++++ -The modules ``win_user``, ``win_group`` and ``win_group_membership`` manage -Windows users, groups and group memberships locally. - -The following is an example of creating local accounts and groups that can -access a folder on the same host: - -.. code-block:: yaml+jinja - - - name: Create local group to contain new users - win_group: - name: LocalGroup - description: Allow access to C:\Development folder - - - name: Create local user - win_user: - name: '{{ item.name }}' - password: '{{ item.password }}' - groups: LocalGroup - update_password: false - password_never_expires: true - loop: - - name: User1 - password: Password1 - - name: User2 - password: Password2 - - - name: Create Development folder - win_file: - path: C:\Development - state: directory - - - name: Set ACL of Development folder - win_acl: - path: C:\Development - rights: FullControl - state: present - type: allow - user: LocalGroup - - - name: Remove parent inheritance of Development folder - win_acl_inheritance: - path: C:\Development - reorganize: true - state: absent - -Domain -++++++ -The modules ``win_domain_user`` and ``win_domain_group`` manages users and -groups in a domain. The below is an example of ensuring a batch of domain users -are created: - -.. code-block:: yaml+jinja - - - name: Ensure each account is created - win_domain_user: - name: '{{ item.name }}' - upn: '{{ item.name }}@MY.DOMAIN.COM' - password: '{{ item.password }}' - password_never_expires: false - groups: - - Test User - - Application - company: Ansible - update_password: on_create - loop: - - name: Test User - password: Password - - name: Admin User - password: SuperSecretPass01 - - name: Dev User - password: '@fvr3IbFBujSRh!3hBg%wgFucD8^x8W5' - -Running Commands ----------------- -In cases where there is no appropriate module available for a task, -a command or script can be run using the ``win_shell``, ``win_command``, ``raw``, and ``script`` modules. - -The ``raw`` module simply executes a Powershell command remotely. Since ``raw`` -has none of the wrappers that Ansible typically uses, ``become``, ``async`` -and environment variables do not work. - -The ``script`` module executes a script from the Ansible controller on -one or more Windows hosts. Like ``raw``, ``script`` currently does not support -``become``, ``async``, or environment variables. - -The ``win_command`` module is used to execute a command which is either an -executable or batch file, while the ``win_shell`` module is used to execute commands within a shell. - -Choosing Command or Shell -+++++++++++++++++++++++++ -The ``win_shell`` and ``win_command`` modules can both be used to execute a command or commands. -The ``win_shell`` module is run within a shell-like process like ``PowerShell`` or ``cmd``, so it has access to shell -operators like ``<``, ``>``, ``|``, ``;``, ``&&``, and ``||``. Multi-lined commands can also be run in ``win_shell``. - -The ``win_command`` module simply runs a process outside of a shell. It can still -run a shell command like ``mkdir`` or ``New-Item`` by passing the shell commands -to a shell executable like ``cmd.exe`` or ``PowerShell.exe``. - -Here are some examples of using ``win_command`` and ``win_shell``: - -.. code-block:: yaml+jinja - - - name: Run a command under PowerShell - win_shell: Get-Service -Name service | Stop-Service - - - name: Run a command under cmd - win_shell: mkdir C:\temp - args: - executable: cmd.exe - - - name: Run a multiple shell commands - win_shell: | - New-Item -Path C:\temp -ItemType Directory - Remove-Item -Path C:\temp -Force -Recurse - $path_info = Get-Item -Path C:\temp - $path_info.FullName - - - name: Run an executable using win_command - win_command: whoami.exe - - - name: Run a cmd command - win_command: cmd.exe /c mkdir C:\temp - - - name: Run a vbs script - win_command: cscript.exe script.vbs - -.. Note:: Some commands like ``mkdir``, ``del``, and ``copy`` only exist in - the CMD shell. To run them with ``win_command`` they must be - prefixed with ``cmd.exe /c``. - -Argument Rules -++++++++++++++ -When running a command through ``win_command``, the standard Windows argument -rules apply: - -* Each argument is delimited by a white space, which can either be a space or a - tab. - -* An argument can be surrounded by double quotes ``"``. Anything inside these - quotes is interpreted as a single argument even if it contains whitespace. - -* A double quote preceded by a backslash ``\`` is interpreted as just a double - quote ``"`` and not as an argument delimiter. - -* Backslashes are interpreted literally unless it immediately precedes double - quotes; for example ``\`` == ``\`` and ``\"`` == ``"`` - -* If an even number of backslashes is followed by a double quote, one - backslash is used in the argument for every pair, and the double quote is - used as a string delimiter for the argument. - -* If an odd number of backslashes is followed by a double quote, one backslash - is used in the argument for every pair, and the double quote is escaped and - made a literal double quote in the argument. - -With those rules in mind, here are some examples of quoting: - -.. code-block:: yaml+jinja - - - win_command: C:\temp\executable.exe argument1 "argument 2" "C:\path\with space" "double \"quoted\"" - - argv[0] = C:\temp\executable.exe - argv[1] = argument1 - argv[2] = argument 2 - argv[3] = C:\path\with space - argv[4] = double "quoted" - - - win_command: '"C:\Program Files\Program\program.exe" "escaped \\\" backslash" unquoted-end-backslash\' - - argv[0] = C:\Program Files\Program\program.exe - argv[1] = escaped \" backslash - argv[2] = unquoted-end-backslash\ - - # Due to YAML and Ansible parsing '\"' must be written as '{% raw %}\\{% endraw %}"' - - win_command: C:\temp\executable.exe C:\no\space\path "arg with end \ before end quote{% raw %}\\{% endraw %}" - - argv[0] = C:\temp\executable.exe - argv[1] = C:\no\space\path - argv[2] = arg with end \ before end quote\" - -For more information, see `escaping arguments `_. - -Creating and Running a Scheduled Task -------------------------------------- -WinRM has some restrictions in place that cause errors when running certain -commands. One way to bypass these restrictions is to run a command through a -scheduled task. A scheduled task is a Windows component that provides the -ability to run an executable on a schedule and under a different account. - -Ansible version 2.5 added modules that make it easier to work with scheduled tasks in Windows. -The following is an example of running a script as a scheduled task that deletes itself after -running: - -.. code-block:: yaml+jinja - - - name: Create scheduled task to run a process - win_scheduled_task: - name: adhoc-task - username: SYSTEM - actions: - - path: PowerShell.exe - arguments: | - Start-Sleep -Seconds 30 # This isn't required, just here as a demonstration - New-Item -Path C:\temp\test -ItemType Directory - # Remove this action if the task shouldn't be deleted on completion - - path: cmd.exe - arguments: /c schtasks.exe /Delete /TN "adhoc-task" /F - triggers: - - type: registration - - - name: Wait for the scheduled task to complete - win_scheduled_task_stat: - name: adhoc-task - register: task_stat - until: (task_stat.state is defined and task_stat.state.status != "TASK_STATE_RUNNING") or (task_stat.task_exists == False) - retries: 12 - delay: 10 - -.. Note:: The modules used in the above example were updated/added in Ansible - version 2.5. - -Path Formatting for Windows -``````````````````````````` -Windows differs from a traditional POSIX operating system in many ways. One of -the major changes is the shift from ``/`` as the path separator to ``\``. This -can cause major issues with how playbooks are written, since ``\`` is often used -as an escape character on POSIX systems. - -Ansible allows two different styles of syntax; each deals with path separators for Windows differently: - -YAML Style ----------- -When using the YAML syntax for tasks, the rules are well-defined by the YAML -standard: - -* When using a normal string (without quotes), YAML will not consider the - backslash an escape character. - -* When using single quotes ``'``, YAML will not consider the backslash an - escape character. - -* When using double quotes ``"``, the backslash is considered an escape - character and needs to escaped with another backslash. - -.. Note:: You should only quote strings when it is absolutely - necessary or required by YAML, and then use single quotes. - -The YAML specification considers the following `escape sequences `_: - -* ``\0``, ``\\``, ``\"``, ``\_``, ``\a``, ``\b``, ``\e``, ``\f``, ``\n``, ``\r``, ``\t``, - ``\v``, ``\L``, ``\N`` and ``\P`` -- Single character escape - -* ````, ````, ````, ````, ```` -- Special - characters - -* ``\x..`` -- 2-digit hex escape - -* ``\u....`` -- 4-digit hex escape - -* ``\U........`` -- 8-digit hex escape - -Here are some examples on how to write Windows paths: - -.. code-block:: ini - - # GOOD - tempdir: C:\Windows\Temp - - # WORKS - tempdir: 'C:\Windows\Temp' - tempdir: "C:\\Windows\\Temp" - - # BAD, BUT SOMETIMES WORKS - tempdir: C:\\Windows\\Temp - tempdir: 'C:\\Windows\\Temp' - tempdir: C:/Windows/Temp - -This is an example which will fail: - -.. code-block:: text - - # FAILS - tempdir: "C:\Windows\Temp" - -This example shows the use of single quotes when they are required: - -.. code-block:: yaml+jinja - - --- - - name: Copy tomcat config - win_copy: - src: log4j.xml - dest: '{{tc_home}}\lib\log4j.xml' - -Legacy key=value Style ----------------------- -The legacy ``key=value`` syntax is used on the command line for ad hoc commands, -or inside playbooks. The use of this style is discouraged within playbooks -because backslash characters need to be escaped, making playbooks harder to read. -The legacy syntax depends on the specific implementation in Ansible, and quoting -(both single and double) does not have any effect on how it is parsed by -Ansible. - -The Ansible key=value parser parse_kv() considers the following escape -sequences: - -* ``\``, ``'``, ``"``, ``\a``, ``\b``, ``\f``, ``\n``, ``\r``, ``\t`` and - ``\v`` -- Single character escape - -* ``\x..`` -- 2-digit hex escape - -* ``\u....`` -- 4-digit hex escape - -* ``\U........`` -- 8-digit hex escape - -* ``\N{...}`` -- Unicode character by name - -This means that the backslash is an escape character for some sequences, and it -is usually safer to escape a backslash when in this form. - -Here are some examples of using Windows paths with the key=value style: - -.. code-block:: ini - - # GOOD - tempdir=C:\\Windows\\Temp - - # WORKS - tempdir='C:\\Windows\\Temp' - tempdir="C:\\Windows\\Temp" - - # BAD, BUT SOMETIMES WORKS - tempdir=C:\Windows\Temp - tempdir='C:\Windows\Temp' - tempdir="C:\Windows\Temp" - tempdir=C:/Windows/Temp - - # FAILS - tempdir=C:\Windows\temp - tempdir='C:\Windows\temp' - tempdir="C:\Windows\temp" - -The failing examples don't fail outright but will substitute ``\t`` with the -```` character resulting in ``tempdir`` being ``C:\Windowsemp``. - -Limitations -``````````` -Some things you cannot do with Ansible and Windows are: - -* Upgrade PowerShell - -* Interact with the WinRM listeners - -Because WinRM is reliant on the services being online and running during normal operations, you cannot upgrade PowerShell or interact with WinRM listeners with Ansible. Both of these actions will cause the connection to fail. This can technically be avoided by using ``async`` or a scheduled task, but those methods are fragile if the process it runs breaks the underlying connection Ansible uses, and are best left to the bootstrapping process or before an image is -created. - -Developing Windows Modules -`````````````````````````` -Because Ansible modules for Windows are written in PowerShell, the development -guides for Windows modules differ substantially from those for standard standard modules. Please see -:ref:`developing_modules_general_windows` for more information. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - :ref:`List of Windows Modules ` - Windows specific module list, all implemented in PowerShell - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/os_guide/windows_winrm.rst b/docs/docsite/rst/os_guide/windows_winrm.rst deleted file mode 100644 index 0c03a7861cd..00000000000 --- a/docs/docsite/rst/os_guide/windows_winrm.rst +++ /dev/null @@ -1,1013 +0,0 @@ -.. _windows_winrm: - -Windows Remote Management -========================= -Unlike Linux/Unix hosts, which use SSH by default, Windows hosts are -configured with WinRM. This topic covers how to configure and use WinRM with Ansible. - -.. contents:: - :local: - :depth: 2 - - -What is WinRM? ----------------- - -WinRM is a management protocol used by Windows to remotely communicate with -another server. It is a SOAP-based protocol that communicates over HTTP/HTTPS, and is -included in all recent Windows operating systems. Since Windows -Server 2012, WinRM has been enabled by default, but in most cases extra -configuration is required to use WinRM with Ansible. - -Ansible uses the `pywinrm `_ package to -communicate with Windows servers over WinRM. It is not installed by default -with the Ansible package, but can be installed by running the following: - -.. code-block:: shell - - pip install "pywinrm>=0.3.0" - -.. Note:: on distributions with multiple python versions, use pip2 or pip2.x, - where x matches the python minor version Ansible is running under. - -.. Warning:: - Using the ``winrm`` or ``psrp`` connection plugins in Ansible on MacOS in - the latest releases typically fail. This is a known problem that occurs - deep within the Python stack and cannot be changed by Ansible. The only - workaround today is to set the environment variable ``no_proxy=*`` and - avoid using Kerberos auth. - - -.. _winrm_auth: - -WinRM authentication options ------------------------------ - -When connecting to a Windows host, there are several different options that can be used -when authenticating with an account. The authentication type may be set on inventory -hosts or groups with the ``ansible_winrm_transport`` variable. - -The following matrix is a high level overview of the options: - -+-------------+----------------+---------------------------+-----------------------+-----------------+ -| Option | Local Accounts | Active Directory Accounts | Credential Delegation | HTTP Encryption | -+=============+================+===========================+=======================+=================+ -| Basic | Yes | No | No | No | -+-------------+----------------+---------------------------+-----------------------+-----------------+ -| Certificate | Yes | No | No | No | -+-------------+----------------+---------------------------+-----------------------+-----------------+ -| Kerberos | No | Yes | Yes | Yes | -+-------------+----------------+---------------------------+-----------------------+-----------------+ -| NTLM | Yes | Yes | No | Yes | -+-------------+----------------+---------------------------+-----------------------+-----------------+ -| CredSSP | Yes | Yes | Yes | Yes | -+-------------+----------------+---------------------------+-----------------------+-----------------+ - -.. _winrm_basic: - -Basic -^^^^^^ - -Basic authentication is one of the simplest authentication options to use, but is -also the most insecure. This is because the username and password are simply -base64 encoded, and if a secure channel is not in use (eg, HTTPS) then it can be -decoded by anyone. Basic authentication can only be used for local accounts (not domain accounts). - -The following example shows host vars configured for basic authentication: - -.. code-block:: yaml+jinja - - ansible_user: LocalUsername - ansible_password: Password - ansible_connection: winrm - ansible_winrm_transport: basic - -Basic authentication is not enabled by default on a Windows host but can be -enabled by running the following in PowerShell: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Service\Auth\Basic -Value $true - - -.. _winrm_certificate: - -Certificate -^^^^^^^^^^^^ - -Certificate authentication uses certificates as keys similar to SSH key -pairs, but the file format and key generation process is different. - -The following example shows host vars configured for certificate authentication: - -.. code-block:: yaml+jinja - - ansible_connection: winrm - ansible_winrm_cert_pem: /path/to/certificate/public/key.pem - ansible_winrm_cert_key_pem: /path/to/certificate/private/key.pem - ansible_winrm_transport: certificate - -Certificate authentication is not enabled by default on a Windows host but can -be enabled by running the following in PowerShell: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Service\Auth\Certificate -Value $true - -.. Note:: Encrypted private keys cannot be used as the urllib3 library that - is used by Ansible for WinRM does not support this functionality. - -.. Note:: Certificate authentication does not work with a TLS 1.3 connection. - -.._winrm_certificate_generate: - -Generate a Certificate -++++++++++++++++++++++ - -A certificate must be generated before it can be mapped to a local user. -This can be done using one of the following methods: - -* OpenSSL -* PowerShell, using the ``New-SelfSignedCertificate`` cmdlet -* Active Directory Certificate Services - -Active Directory Certificate Services is beyond of scope in this documentation but may be -the best option to use when running in a domain environment. For more information, -see the `Active Directory Certificate Services documentation `_. - -.. Note:: Using the PowerShell cmdlet ``New-SelfSignedCertificate`` to generate - a certificate for authentication only works when being generated from a - Windows 10 or Windows Server 2012 R2 host or later. OpenSSL is still required to - extract the private key from the PFX certificate to a PEM file for Ansible - to use. - -To generate a certificate with ``OpenSSL``: - -.. code-block:: shell - - # Set the name of the local user that will have the key mapped to - USERNAME="username" - - cat > openssl.conf << EOL - distinguished_name = req_distinguished_name - [req_distinguished_name] - [v3_req_client] - extendedKeyUsage = clientAuth - subjectAltName = otherName:1.3.6.1.4.1.311.20.2.3;UTF8:$USERNAME@localhost - EOL - - export OPENSSL_CONF=openssl.conf - openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out cert.pem -outform PEM -keyout cert_key.pem -subj "/CN=$USERNAME" -extensions v3_req_client - rm openssl.conf - - -To generate a certificate with ``New-SelfSignedCertificate``: - -.. code-block:: powershell - - # Set the name of the local user that will have the key mapped - $username = "username" - $output_path = "C:\temp" - - # Instead of generating a file, the cert will be added to the personal - # LocalComputer folder in the certificate store - $cert = New-SelfSignedCertificate -Type Custom ` - -Subject "CN=$username" ` - -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2","2.5.29.17={text}upn=$username@localhost") ` - -KeyUsage DigitalSignature,KeyEncipherment ` - -KeyAlgorithm RSA ` - -KeyLength 2048 - - # Export the public key - $pem_output = @() - $pem_output += "-----BEGIN CERTIFICATE-----" - $pem_output += [System.Convert]::ToBase64String($cert.RawData) -replace ".{64}", "$&`n" - $pem_output += "-----END CERTIFICATE-----" - [System.IO.File]::WriteAllLines("$output_path\cert.pem", $pem_output) - - # Export the private key in a PFX file - [System.IO.File]::WriteAllBytes("$output_path\cert.pfx", $cert.Export("Pfx")) - - -.. Note:: To convert the PFX file to a private key that pywinrm can use, run - the following command with OpenSSL - ``openssl pkcs12 -in cert.pfx -nocerts -nodes -out cert_key.pem -passin pass: -passout pass:`` - -.. _winrm_certificate_import: - -Import a Certificate to the Certificate Store -+++++++++++++++++++++++++++++++++++++++++++++ - -Once a certificate has been generated, the issuing certificate needs to be -imported into the ``Trusted Root Certificate Authorities`` of the -``LocalMachine`` store, and the client certificate public key must be present -in the ``Trusted People`` folder of the ``LocalMachine`` store. For this example, -both the issuing certificate and public key are the same. - -Following example shows how to import the issuing certificate: - -.. code-block:: powershell - - $cert = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2 "cert.pem" - - $store_name = [System.Security.Cryptography.X509Certificates.StoreName]::Root - $store_location = [System.Security.Cryptography.X509Certificates.StoreLocation]::LocalMachine - $store = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $store_name, $store_location - $store.Open("MaxAllowed") - $store.Add($cert) - $store.Close() - - -.. Note:: If using ADCS to generate the certificate, then the issuing - certificate will already be imported and this step can be skipped. - -The code to import the client certificate public key is: - -.. code-block:: powershell - - $cert = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2 "cert.pem" - - $store_name = [System.Security.Cryptography.X509Certificates.StoreName]::TrustedPeople - $store_location = [System.Security.Cryptography.X509Certificates.StoreLocation]::LocalMachine - $store = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $store_name, $store_location - $store.Open("MaxAllowed") - $store.Add($cert) - $store.Close() - - -.. _winrm_certificate_mapping: - -Mapping a Certificate to an Account -+++++++++++++++++++++++++++++++++++ - -Once the certificate has been imported, map it to the local user account: - -.. code-block:: powershell - - $username = "username" - $password = ConvertTo-SecureString -String "password" -AsPlainText -Force - $credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $password - - # This is the issuer thumbprint which in the case of a self generated cert - # is the public key thumbprint, additional logic may be required for other - # scenarios - $thumbprint = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object { $_.Subject -eq "CN=$username" }).Thumbprint - - New-Item -Path WSMan:\localhost\ClientCertificate ` - -Subject "$username@localhost" ` - -URI * ` - -Issuer $thumbprint ` - -Credential $credential ` - -Force - - -Once this is complete, the hostvar ``ansible_winrm_cert_pem`` should be set to -the path of the public key and the ``ansible_winrm_cert_key_pem`` variable should be set to -the path of the private key. - - -.. _winrm_ntlm: - -NTLM -^^^^^ - -NTLM is an older authentication mechanism used by Microsoft that can support -both local and domain accounts. NTLM is enabled by default on the WinRM -service, so no setup is required before using it. - -NTLM is the easiest authentication protocol to use and is more secure than -``Basic`` authentication. If running in a domain environment, ``Kerberos`` should be used -instead of NTLM. - -Kerberos has several advantages over using NTLM: - -* NTLM is an older protocol and does not support newer encryption - protocols. -* NTLM is slower to authenticate because it requires more round trips to the host in - the authentication stage. -* Unlike Kerberos, NTLM does not allow credential delegation. - -This example shows host variables configured to use NTLM authentication: - -.. code-block:: yaml+jinja - - ansible_user: LocalUsername - ansible_password: Password - ansible_connection: winrm - ansible_winrm_transport: ntlm - -.. _winrm_kerberos: - -Kerberos -^^^^^^^^^ - -Kerberos is the recommended authentication option to use when running in a -domain environment. Kerberos supports features like credential delegation and -message encryption over HTTP and is one of the more secure options that -is available through WinRM. - -Kerberos requires some additional setup work on the Ansible host before it can be -used properly. - -The following example shows host vars configured for Kerberos authentication: - -.. code-block:: yaml+jinja - - ansible_user: username@MY.DOMAIN.COM - ansible_password: Password - ansible_connection: winrm - ansible_port: 5985 - ansible_winrm_transport: kerberos - -As of Ansible version 2.3, the Kerberos ticket will be created based on -``ansible_user`` and ``ansible_password``. If running on an older version of -Ansible or when ``ansible_winrm_kinit_mode`` is ``manual``, a Kerberos -ticket must already be obtained. See below for more details. - -There are some extra host variables that can be set: - -.. code-block:: yaml - - ansible_winrm_kinit_mode: managed/manual (manual means Ansible will not obtain a ticket) - ansible_winrm_kinit_cmd: the kinit binary to use to obtain a Kerberos ticket (default to kinit) - ansible_winrm_service: overrides the SPN prefix that is used, the default is ``HTTP`` and should rarely ever need changing - ansible_winrm_kerberos_delegation: allows the credentials to traverse multiple hops - ansible_winrm_kerberos_hostname_override: the hostname to be used for the kerberos exchange - -.. _winrm_kerberos_install: - -Installing the Kerberos Library -+++++++++++++++++++++++++++++++ - -Some system dependencies that must be installed prior to using Kerberos. The script below lists the dependencies based on the distro: - -.. code-block:: shell - - # Through Yum (RHEL/Centos/Fedora for the older version) - yum -y install gcc python-devel krb5-devel krb5-libs krb5-workstation - - # Through DNF (RHEL/Centos/Fedora for the newer version) - dnf -y install gcc python3-devel krb5-devel krb5-libs krb5-workstation - - # Through Apt (Ubuntu) - sudo apt-get install python-dev libkrb5-dev krb5-user - - # Through Portage (Gentoo) - emerge -av app-crypt/mit-krb5 - emerge -av dev-python/setuptools - - # Through Pkg (FreeBSD) - sudo pkg install security/krb5 - - # Through OpenCSW (Solaris) - pkgadd -d http://get.opencsw.org/now - /opt/csw/bin/pkgutil -U - /opt/csw/bin/pkgutil -y -i libkrb5_3 - - # Through Pacman (Arch Linux) - pacman -S krb5 - - -Once the dependencies have been installed, the ``python-kerberos`` wrapper can -be install using ``pip``: - -.. code-block:: shell - - pip install pywinrm[kerberos] - - -.. note:: - While Ansible has supported Kerberos auth through ``pywinrm`` for some - time, optional features or more secure options may only be available in - newer versions of the ``pywinrm`` and/or ``pykerberos`` libraries. It is - recommended you upgrade each version to the latest available to resolve - any warnings or errors. This can be done through tools like ``pip`` or a - system package manager like ``dnf``, ``yum``, ``apt`` but the package - names and versions available may differ between tools. - - -.. _winrm_kerberos_config: - -Configuring Host Kerberos -+++++++++++++++++++++++++ - -Once the dependencies have been installed, Kerberos needs to be configured so -that it can communicate with a domain. This configuration is done through the -``/etc/krb5.conf`` file, which is installed with the packages in the script above. - -To configure Kerberos, in the section that starts with: - -.. code-block:: ini - - [realms] - -Add the full domain name and the fully qualified domain names of the primary -and secondary Active Directory domain controllers. It should look something -like this: - -.. code-block:: ini - - [realms] - MY.DOMAIN.COM = { - kdc = domain-controller1.my.domain.com - kdc = domain-controller2.my.domain.com - } - -In the section that starts with: - -.. code-block:: ini - - [domain_realm] - -Add a line like the following for each domain that Ansible needs access for: - -.. code-block:: ini - - [domain_realm] - .my.domain.com = MY.DOMAIN.COM - -You can configure other settings in this file such as the default domain. See -`krb5.conf `_ -for more details. - -.. _winrm_kerberos_ticket_auto: - -Automatic Kerberos Ticket Management -++++++++++++++++++++++++++++++++++++ - -Ansible version 2.3 and later defaults to automatically managing Kerberos tickets -when both ``ansible_user`` and ``ansible_password`` are specified for a host. In -this process, a new ticket is created in a temporary credential cache for each -host. This is done before each task executes to minimize the chance of ticket -expiration. The temporary credential caches are deleted after each task -completes and will not interfere with the default credential cache. - -To disable automatic ticket management, set ``ansible_winrm_kinit_mode=manual`` -through the inventory. - -Automatic ticket management requires a standard ``kinit`` binary on the control -host system path. To specify a different location or binary name, set the -``ansible_winrm_kinit_cmd`` hostvar to the fully qualified path to a MIT krbv5 -``kinit``-compatible binary. - -.. _winrm_kerberos_ticket_manual: - -Manual Kerberos Ticket Management -+++++++++++++++++++++++++++++++++ - -To manually manage Kerberos tickets, the ``kinit`` binary is used. To -obtain a new ticket the following command is used: - -.. code-block:: shell - - kinit username@MY.DOMAIN.COM - -.. Note:: The domain must match the configured Kerberos realm exactly, and must be in upper case. - -To see what tickets (if any) have been acquired, use the following command: - -.. code-block:: shell - - klist - -To destroy all the tickets that have been acquired, use the following command: - -.. code-block:: shell - - kdestroy - -.. _winrm_kerberos_troubleshoot: - -Troubleshooting Kerberos -++++++++++++++++++++++++ - -Kerberos is reliant on a properly-configured environment to -work. To troubleshoot Kerberos issues, ensure that: - -* The hostname set for the Windows host is the FQDN and not an IP address. - * If you connect using an IP address you will get the error message `Server not found in Kerberos database`. - * To determine if you are connecting using an IP address or an FQDN run your playbook (or call the ``win_ping`` module) using the `-vvv` flag. - -* The forward and reverse DNS lookups are working properly in the domain. To - test this, ping the windows host by name and then use the ip address returned - with ``nslookup``. The same name should be returned when using ``nslookup`` - on the IP address. - -* The Ansible host's clock is synchronized with the domain controller. Kerberos - is time sensitive, and a little clock drift can cause the ticket generation - process to fail. - -* Ensure that the fully qualified domain name for the domain is configured in - the ``krb5.conf`` file. To check this, run: - - .. code-block:: console - - kinit -C username@MY.DOMAIN.COM - klist - - If the domain name returned by ``klist`` is different from the one requested, - an alias is being used. The ``krb5.conf`` file needs to be updated so that - the fully qualified domain name is used and not an alias. - -* If the default kerberos tooling has been replaced or modified (some IdM solutions may do this), this may cause issues when installing or upgrading the Python Kerberos library. As of the time of this writing, this library is called ``pykerberos`` and is known to work with both MIT and Heimdal Kerberos libraries. To resolve ``pykerberos`` installation issues, ensure the system dependencies for Kerberos have been met (see: `Installing the Kerberos Library`_), remove any custom Kerberos tooling paths from the PATH environment variable, and retry the installation of Python Kerberos library package. - -.. _winrm_credssp: - -CredSSP -^^^^^^^ - -CredSSP authentication is a newer authentication protocol that allows -credential delegation. This is achieved by encrypting the username and password -after authentication has succeeded and sending that to the server using the -CredSSP protocol. - -Because the username and password are sent to the server to be used for double -hop authentication, ensure that the hosts that the Windows host communicates with are -not compromised and are trusted. - -CredSSP can be used for both local and domain accounts and also supports -message encryption over HTTP. - -To use CredSSP authentication, the host vars are configured like so: - -.. code-block:: yaml+jinja - - ansible_user: Username - ansible_password: Password - ansible_connection: winrm - ansible_winrm_transport: credssp - -There are some extra host variables that can be set as shown below: - -.. code-block:: yaml - - ansible_winrm_credssp_disable_tlsv1_2: when true, will not use TLS 1.2 in the CredSSP auth process - -CredSSP authentication is not enabled by default on a Windows host, but can -be enabled by running the following in PowerShell: - -.. code-block:: powershell - - Enable-WSManCredSSP -Role Server -Force - -.. _winrm_credssp_install: - -Installing CredSSP Library -++++++++++++++++++++++++++ - -The ``requests-credssp`` wrapper can be installed using ``pip``: - -.. code-block:: bash - - pip install pywinrm[credssp] - -.. _winrm_credssp_tls: - -CredSSP and TLS 1.2 -+++++++++++++++++++ - -By default the ``requests-credssp`` library is configured to authenticate over -the TLS 1.2 protocol. TLS 1.2 is installed and enabled by default for Windows Server 2012 -and Windows 8 and more recent releases. - -There are two ways that older hosts can be used with CredSSP: - -* Install and enable a hotfix to enable TLS 1.2 support (recommended - for Server 2008 R2 and Windows 7). - -* Set ``ansible_winrm_credssp_disable_tlsv1_2=True`` in the inventory to run - over TLS 1.0. This is the only option when connecting to Windows Server 2008, which - has no way of supporting TLS 1.2 - -See :ref:`winrm_tls12` for more information on how to enable TLS 1.2 on the -Windows host. - -.. _winrm _credssp_cert: - -Set CredSSP Certificate -+++++++++++++++++++++++ - -CredSSP works by encrypting the credentials through the TLS protocol and uses a self-signed certificate by default. The ``CertificateThumbprint`` option under the WinRM service configuration can be used to specify the thumbprint of -another certificate. - -.. Note:: This certificate configuration is independent of the WinRM listener - certificate. With CredSSP, message transport still occurs over the WinRM listener, - but the TLS-encrypted messages inside the channel use the service-level certificate. - -To explicitly set the certificate to use for CredSSP: - -.. code-block:: powershell - - # Note the value $certificate_thumbprint will be different in each - # situation, this needs to be set based on the cert that is used. - $certificate_thumbprint = "7C8DCBD5427AFEE6560F4AF524E325915F51172C" - - # Set the thumbprint value - Set-Item -Path WSMan:\localhost\Service\CertificateThumbprint -Value $certificate_thumbprint - -.. _winrm_nonadmin: - -Non-Administrator Accounts ---------------------------- - -WinRM is configured by default to only allow connections from accounts in the local -``Administrators`` group. This can be changed by running: - -.. code-block:: powershell - - winrm configSDDL default - -This will display an ACL editor, where new users or groups may be added. To run commands -over WinRM, users and groups must have at least the ``Read`` and ``Execute`` permissions -enabled. - -While non-administrative accounts can be used with WinRM, most typical server administration -tasks require some level of administrative access, so the utility is usually limited. - -.. _winrm_encrypt: - -WinRM Encryption ------------------ - -By default WinRM will fail to work when running over an unencrypted channel. -The WinRM protocol considers the channel to be encrypted if using TLS over HTTP -(HTTPS) or using message level encryption. Using WinRM with TLS is the -recommended option as it works with all authentication options, but requires -a certificate to be created and used on the WinRM listener. - -If in a domain environment, ADCS can create a certificate for the host that -is issued by the domain itself. - -If using HTTPS is not an option, then HTTP can be used when the authentication -option is ``NTLM``, ``Kerberos`` or ``CredSSP``. These protocols will encrypt -the WinRM payload with their own encryption method before sending it to the -server. The message-level encryption is not used when running over HTTPS because the -encryption uses the more secure TLS protocol instead. If both transport and -message encryption is required, set ``ansible_winrm_message_encryption=always`` -in the host vars. - -.. Note:: Message encryption over HTTP requires pywinrm>=0.3.0. - -A last resort is to disable the encryption requirement on the Windows host. This -should only be used for development and debugging purposes, as anything sent -from Ansible can be viewed, manipulated and also the remote session can completely -be taken over by anyone on the same network. To disable the encryption -requirement: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Service\AllowUnencrypted -Value $true - -.. Note:: Do not disable the encryption check unless it is - absolutely required. Doing so could allow sensitive information like - credentials and files to be intercepted by others on the network. - -.. _winrm_inventory: - -Inventory Options ------------------- - -Ansible's Windows support relies on a few standard variables to indicate the -username, password, and connection type of the remote hosts. These variables -are most easily set up in the inventory, but can be set on the ``host_vars``/ -``group_vars`` level. - -When setting up the inventory, the following variables are required: - -.. code-block:: yaml+jinja - - # It is suggested that these be encrypted with ansible-vault: - # ansible-vault edit group_vars/windows.yml - ansible_connection: winrm - - # May also be passed on the command-line through --user - ansible_user: Administrator - - # May also be supplied at runtime with --ask-pass - ansible_password: SecretPasswordGoesHere - - -Using the variables above, Ansible will connect to the Windows host with Basic -authentication through HTTPS. If ``ansible_user`` has a UPN value like -``username@MY.DOMAIN.COM`` then the authentication option will automatically attempt -to use Kerberos unless ``ansible_winrm_transport`` has been set to something other than -``kerberos``. - -The following custom inventory variables are also supported -for additional configuration of WinRM connections: - -* ``ansible_port``: The port WinRM will run over, HTTPS is ``5986`` which is - the default while HTTP is ``5985`` - -* ``ansible_winrm_scheme``: Specify the connection scheme (``http`` or - ``https``) to use for the WinRM connection. Ansible uses ``https`` by default - unless ``ansible_port`` is ``5985`` - -* ``ansible_winrm_path``: Specify an alternate path to the WinRM endpoint, - Ansible uses ``/wsman`` by default - -* ``ansible_winrm_realm``: Specify the realm to use for Kerberos - authentication. If ``ansible_user`` contains ``@``, Ansible will use the part - of the username after ``@`` by default - -* ``ansible_winrm_transport``: Specify one or more authentication transport - options as a comma-separated list. By default, Ansible will use ``kerberos, - basic`` if the ``kerberos`` module is installed and a realm is defined, - otherwise it will be ``plaintext`` - -* ``ansible_winrm_server_cert_validation``: Specify the server certificate - validation mode (``ignore`` or ``validate``). Ansible defaults to - ``validate`` on Python 2.7.9 and higher, which will result in certificate - validation errors against the Windows self-signed certificates. Unless - verifiable certificates have been configured on the WinRM listeners, this - should be set to ``ignore`` - -* ``ansible_winrm_operation_timeout_sec``: Increase the default timeout for - WinRM operations, Ansible uses ``20`` by default - -* ``ansible_winrm_read_timeout_sec``: Increase the WinRM read timeout, Ansible - uses ``30`` by default. Useful if there are intermittent network issues and - read timeout errors keep occurring - -* ``ansible_winrm_message_encryption``: Specify the message encryption - operation (``auto``, ``always``, ``never``) to use, Ansible uses ``auto`` by - default. ``auto`` means message encryption is only used when - ``ansible_winrm_scheme`` is ``http`` and ``ansible_winrm_transport`` supports - message encryption. ``always`` means message encryption will always be used - and ``never`` means message encryption will never be used - -* ``ansible_winrm_ca_trust_path``: Used to specify a different cacert container - than the one used in the ``certifi`` module. See the HTTPS Certificate - Validation section for more details. - -* ``ansible_winrm_send_cbt``: When using ``ntlm`` or ``kerberos`` over HTTPS, - the authentication library will try to send channel binding tokens to - mitigate against man in the middle attacks. This flag controls whether these - bindings will be sent or not (default: ``true``). - -* ``ansible_winrm_*``: Any additional keyword arguments supported by - ``winrm.Protocol`` may be provided in place of ``*`` - -In addition, there are also specific variables that need to be set -for each authentication option. See the section on authentication above for more information. - -.. Note:: Ansible 2.0 has deprecated the "ssh" from ``ansible_ssh_user``, - ``ansible_ssh_pass``, ``ansible_ssh_host``, and ``ansible_ssh_port`` to - become ``ansible_user``, ``ansible_password``, ``ansible_host``, and - ``ansible_port``. If using a version of Ansible prior to 2.0, the older - style (``ansible_ssh_*``) should be used instead. The shorter variables - are ignored, without warning, in older versions of Ansible. - -.. Note:: ``ansible_winrm_message_encryption`` is different from transport - encryption done over TLS. The WinRM payload is still encrypted with TLS - when run over HTTPS, even if ``ansible_winrm_message_encryption=never``. - -.. _winrm_ipv6: - -IPv6 Addresses ---------------- - -IPv6 addresses can be used instead of IPv4 addresses or hostnames. This option -is normally set in an inventory. Ansible will attempt to parse the address -using the `ipaddress `_ -package and pass to pywinrm correctly. - -When defining a host using an IPv6 address, just add the IPv6 address as you -would an IPv4 address or hostname: - -.. code-block:: ini - - [windows-server] - 2001:db8::1 - - [windows-server:vars] - ansible_user=username - ansible_password=password - ansible_connection=winrm - - -.. Note:: The ipaddress library is only included by default in Python 3.x. To - use IPv6 addresses in Python 2.7, make sure to run ``pip install ipaddress`` which installs - a backported package. - -.. _winrm_https: - -HTTPS Certificate Validation ------------------------------ - -As part of the TLS protocol, the certificate is validated to ensure the host -matches the subject and the client trusts the issuer of the server certificate. -When using a self-signed certificate or setting -``ansible_winrm_server_cert_validation: ignore`` these security mechanisms are -bypassed. While self signed certificates will always need the ``ignore`` flag, -certificates that have been issued from a certificate authority can still be -validated. - -One of the more common ways of setting up a HTTPS listener in a domain -environment is to use Active Directory Certificate Service (AD CS). AD CS is -used to generate signed certificates from a Certificate Signing Request (CSR). -If the WinRM HTTPS listener is using a certificate that has been signed by -another authority, like AD CS, then Ansible can be set up to trust that -issuer as part of the TLS handshake. - -To get Ansible to trust a Certificate Authority (CA) like AD CS, the issuer -certificate of the CA can be exported as a PEM encoded certificate. This -certificate can then be copied locally to the Ansible controller and used as a -source of certificate validation, otherwise known as a CA chain. - -The CA chain can contain a single or multiple issuer certificates and each -entry is contained on a new line. To then use the custom CA chain as part of -the validation process, set ``ansible_winrm_ca_trust_path`` to the path of the -file. If this variable is not set, the default CA chain is used instead which -is located in the install path of the Python package -`certifi `_. - -.. Note:: Each HTTP call is done by the Python requests library which does not - use the systems built-in certificate store as a trust authority. - Certificate validation will fail if the server's certificate issuer is - only added to the system's truststore. - -.. _winrm_tls12: - -TLS 1.2 Support ----------------- - -As WinRM runs over the HTTP protocol, using HTTPS means that the TLS protocol -is used to encrypt the WinRM messages. TLS will automatically attempt to -negotiate the best protocol and cipher suite that is available to both the -client and the server. If a match cannot be found then Ansible will error out -with a message similar to: - -.. code-block:: ansible-output - - HTTPSConnectionPool(host='server', port=5986): Max retries exceeded with url: /wsman (Caused by SSLError(SSLError(1, '[SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:1056)'))) - -Commonly this is when the Windows host has not been configured to support -TLS v1.2 but it could also mean the Ansible controller has an older OpenSSL -version installed. - -Windows 8 and Windows Server 2012 come with TLS v1.2 installed and enabled by -default but older hosts, like Server 2008 R2 and Windows 7, have to be enabled -manually. - -.. Note:: There is a bug with the TLS 1.2 patch for Server 2008 which will stop - Ansible from connecting to the Windows host. This means that Server 2008 - cannot be configured to use TLS 1.2. Server 2008 R2 and Windows 7 are not - affected by this issue and can use TLS 1.2. - -To verify what protocol the Windows host supports, you can run the following -command on the Ansible controller: - -.. code-block:: shell - - openssl s_client -connect :5986 - -The output will contain information about the TLS session and the ``Protocol`` -line will display the version that was negotiated: - -.. code-block:: console - - New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA - Server public key is 2048 bit - Secure Renegotiation IS supported - Compression: NONE - Expansion: NONE - No ALPN negotiated - SSL-Session: - Protocol : TLSv1 - Cipher : ECDHE-RSA-AES256-SHA - Session-ID: 962A00001C95D2A601BE1CCFA7831B85A7EEE897AECDBF3D9ECD4A3BE4F6AC9B - Session-ID-ctx: - Master-Key: .... - Start Time: 1552976474 - Timeout : 7200 (sec) - Verify return code: 21 (unable to verify the first certificate) - --- - - New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 - Server public key is 2048 bit - Secure Renegotiation IS supported - Compression: NONE - Expansion: NONE - No ALPN negotiated - SSL-Session: - Protocol : TLSv1.2 - Cipher : ECDHE-RSA-AES256-GCM-SHA384 - Session-ID: AE16000050DA9FD44D03BB8839B64449805D9E43DBD670346D3D9E05D1AEEA84 - Session-ID-ctx: - Master-Key: .... - Start Time: 1552976538 - Timeout : 7200 (sec) - Verify return code: 21 (unable to verify the first certificate) - -If the host is returning ``TLSv1`` then it should be configured so that -TLS v1.2 is enable. You can do this by running the following PowerShell -script: - -.. code-block:: powershell - - Function Enable-TLS12 { - param( - [ValidateSet("Server", "Client")] - [String]$Component = "Server" - ) - - $protocols_path = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' - New-Item -Path "$protocols_path\TLS 1.2\$Component" -Force - New-ItemProperty -Path "$protocols_path\TLS 1.2\$Component" -Name Enabled -Value 1 -Type DWORD -Force - New-ItemProperty -Path "$protocols_path\TLS 1.2\$Component" -Name DisabledByDefault -Value 0 -Type DWORD -Force - } - - Enable-TLS12 -Component Server - - # Not required but highly recommended to enable the Client side TLS 1.2 components - Enable-TLS12 -Component Client - - Restart-Computer - -The below Ansible tasks can also be used to enable TLS v1.2: - -.. code-block:: yaml+jinja - - - name: enable TLSv1.2 support - win_regedit: - path: HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\{{ item.type }} - name: '{{ item.property }}' - data: '{{ item.value }}' - type: dword - state: present - register: enable_tls12 - loop: - - type: Server - property: Enabled - value: 1 - - type: Server - property: DisabledByDefault - value: 0 - - type: Client - property: Enabled - value: 1 - - type: Client - property: DisabledByDefault - value: 0 - - - name: reboot if TLS config was applied - win_reboot: - when: enable_tls12 is changed - -There are other ways to configure the TLS protocols as well as the cipher -suites that are offered by the Windows host. One tool that can give you a GUI -to manage these settings is `IIS Crypto `_ -from Nartac Software. - -.. _winrm_limitations: - -WinRM limitations ------------------- -Due to the design of the WinRM protocol , there are a few limitations -when using WinRM that can cause issues when creating playbooks for Ansible. -These include: - -* Credentials are not delegated for most authentication types, which causes - authentication errors when accessing network resources or installing certain - programs. - -* Many calls to the Windows Update API are blocked when running over WinRM. - -* Some programs fail to install with WinRM due to no credential delegation or - because they access forbidden Windows API like WUA over WinRM. - -* Commands under WinRM are done under a non-interactive session, which can prevent - certain commands or executables from running. - -* You cannot run a process that interacts with ``DPAPI``, which is used by some - installers (like Microsoft SQL Server). - -Some of these limitations can be mitigated by doing one of the following: - -* Set ``ansible_winrm_transport`` to ``credssp`` or ``kerberos`` (with - ``ansible_winrm_kerberos_delegation=true``) to bypass the double hop issue - and access network resources - -* Use ``become`` to bypass all WinRM restrictions and run a command as it would - locally. Unlike using an authentication transport like ``credssp``, this will - also remove the non-interactive restriction and API restrictions like WUA and - DPAPI - -* Use a scheduled task to run a command which can be created with the - ``win_scheduled_task`` module. Like ``become``, this bypasses all WinRM - restrictions but can only run a command and not modules. - - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - :ref:`List of Windows Modules ` - Windows specific module list, all implemented in PowerShell - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/complex_data_manipulation.rst b/docs/docsite/rst/playbook_guide/complex_data_manipulation.rst deleted file mode 100644 index e7d23b336fc..00000000000 --- a/docs/docsite/rst/playbook_guide/complex_data_manipulation.rst +++ /dev/null @@ -1,314 +0,0 @@ -.. _complex_data_manipulation: - -Manipulating data -################# - -In many cases, you need to do some complex operation with your variables, while Ansible is not recommended as a data processing/manipulation tool, you can use the existing Jinja2 templating in conjunction with the many added Ansible filters, lookups and tests to do some very complex transformations. - -Let's start with a quick definition of each type of plugin: - - lookups: Mainly used to query 'external data', in Ansible these were the primary part of loops using the ``with_`` construct, but they can be used independently to return data for processing. They normally return a list due to their primary function in loops as mentioned previously. Used with the ``lookup`` or ``query`` Jinja2 operators. - - filters: used to change/transform data, used with the ``|`` Jinja2 operator. - - tests: used to validate data, used with the ``is`` Jinja2 operator. - -.. _note: - * Some tests and filters are provided directly by Jinja2, so their availability depends on the Jinja2 version, not Ansible. - -.. _for_loops_or_list_comprehensions: - -Loops and list comprehensions -============================= - -Most programming languages have loops (``for``, ``while``, and so on) and list comprehensions to do transformations on lists including lists of objects. Jinja2 has a few filters that provide this functionality: ``map``, ``select``, ``reject``, ``selectattr``, ``rejectattr``. - -- map: this is a basic for loop that just allows you to change every item in a list, using the 'attribute' keyword you can do the transformation based on attributes of the list elements. -- select/reject: this is a for loop with a condition, that allows you to create a subset of a list that matches (or not) based on the result of the condition. -- selectattr/rejectattr: very similar to the above but it uses a specific attribute of the list elements for the conditional statement. - - -.. _exponential_backoff: - -Use a loop to create exponential backoff for retries/until. - -.. code-block:: yaml - - - name: retry ping 10 times with exponential backoff delay - ping: - retries: 10 - delay: '{{item|int}}' - loop: '{{ range(1, 10)|map("pow", 2) }}' - - -.. _keys_from_dict_matching_list: - -Extract keys from a dictionary matching elements from a list ------------------------------------------------------------- - -The Python equivalent code would be: - -.. code-block:: python - - chains = [1, 2] - for chain in chains: - for config in chains_config[chain]['configs']: - print(config['type']) - -There are several ways to do it in Ansible, this is just one example: - -.. code-block:: YAML+Jinja - :emphasize-lines: 4 - :caption: Way to extract matching keys from a list of dictionaries - - tasks: - - name: Show extracted list of keys from a list of dictionaries - ansible.builtin.debug: - msg: "{{ chains | map('extract', chains_config) | map(attribute='configs') | flatten | map(attribute='type') | flatten }}" - vars: - chains: [1, 2] - chains_config: - 1: - foo: bar - configs: - - type: routed - version: 0.1 - - type: bridged - version: 0.2 - 2: - foo: baz - configs: - - type: routed - version: 1.0 - - type: bridged - version: 1.1 - - -.. code-block:: ansible-output - :caption: Results of debug task, a list with the extracted keys - - ok: [localhost] => { - "msg": [ - "routed", - "bridged", - "routed", - "bridged" - ] - } - - -.. code-block:: YAML+Jinja - :caption: Get the unique list of values of a variable that vary per host - - vars: - unique_value_list: "{{ groups['all'] | map ('extract', hostvars, 'varname') | list | unique}}" - - -.. _find_mount_point: - -Find mount point ----------------- - -In this case, we want to find the mount point for a given path across our machines, since we already collect mount facts, we can use the following: - -.. code-block:: YAML+Jinja - :caption: Use selectattr to filter mounts into list I can then sort and select the last from - :emphasize-lines: 8 - - - hosts: all - gather_facts: True - vars: - path: /var/lib/cache - tasks: - - name: The mount point for {{path}}, found using the Ansible mount facts, [-1] is the same as the 'last' filter - ansible.builtin.debug: - msg: "{{(ansible_facts.mounts | selectattr('mount', 'in', path) | list | sort(attribute='mount'))[-1]['mount']}}" - - -.. _omit_elements_from_list: - -Omit elements from a list -------------------------- - -The special ``omit`` variable ONLY works with module options, but we can still use it in other ways as an identifier to tailor a list of elements: - -.. code-block:: YAML+Jinja - :caption: Inline list filtering when feeding a module option - :emphasize-lines: 3, 6 - - - name: Enable a list of Windows features, by name - ansible.builtin.set_fact: - win_feature_list: "{{ namestuff | reject('equalto', omit) | list }}" - vars: - namestuff: - - "{{ (fs_installed_smb_v1 | default(False)) | ternary(omit, 'FS-SMB1') }}" - - "foo" - - "bar" - - -Another way is to avoid adding elements to the list in the first place, so you can just use it directly: - -.. code-block:: YAML+Jinja - :caption: Using set_fact in a loop to increment a list conditionally - :emphasize-lines: 3, 4, 6 - - - name: Build unique list with some items conditionally omitted - ansible.builtin.set_fact: - namestuff: ' {{ (namestuff | default([])) | union([item]) }}' - when: item != omit - loop: - - "{{ (fs_installed_smb_v1 | default(False)) | ternary(omit, 'FS-SMB1') }}" - - "foo" - - "bar" - - - -.. _combine_optional_values: - -Combine values from same list of dicts ---------------------------------------- -Combining positive and negative filters from examples above, you can get a 'value when it exists' and a 'fallback' when it doesn't. - -.. code-block:: YAML+Jinja - :caption: Use selectattr and rejectattr to get the ansible_host or inventory_hostname as needed - - - hosts: localhost - tasks: - - name: Check hosts in inventory that respond to ssh port - wait_for: - host: "{{ item }}" - port: 22 - loop: '{{ has_ah + no_ah }}' - vars: - has_ah: '{{ hostvars|dictsort|selectattr("1.ansible_host", "defined")|map(attribute="1.ansible_host")|list }}' - no_ah: '{{ hostvars|dictsort|rejectattr("1.ansible_host", "defined")|map(attribute="0")|list }}' - - -.. _custom_fileglob_variable: - -Custom Fileglob Based on a Variable ------------------------------------ - -This example uses `Python argument list unpacking `_ to create a custom list of fileglobs based on a variable. - -.. code-block:: YAML+Jinja - :caption: Using fileglob with a list based on a variable. - - - hosts: all - vars: - mygroups: - - prod - - web - tasks: - - name: Copy a glob of files based on a list of groups - copy: - src: "{{ item }}" - dest: "/tmp/{{ item }}" - loop: '{{ q("fileglob", *globlist) }}' - vars: - globlist: '{{ mygroups | map("regex_replace", "^(.*)$", "files/\1/*.conf") | list }}' - - -.. _complex_type_transformations: - -Complex Type transformations -============================= - -Jinja provides filters for simple data type transformations (``int``, ``bool``, and so on), but when you want to transform data structures things are not as easy. -You can use loops and list comprehensions as shown above to help, also other filters and lookups can be chained and used to achieve more complex transformations. - - -.. _create_dictionary_from_list: - -Create dictionary from list ---------------------------- - -In most languages it is easy to create a dictionary (a.k.a. map/associative array/hash and so on) from a list of pairs, in Ansible there are a couple of ways to do it and the best one for you might depend on the source of your data. - - -These example produces ``{"a": "b", "c": "d"}`` - -.. code-block:: YAML+Jinja - :caption: Simple list to dict by assuming the list is [key, value , key, value, ...] - - vars: - single_list: [ 'a', 'b', 'c', 'd' ] - mydict: "{{ dict(single_list[::2] | zip_longest(single_list[1::2])) }}" - - -.. code-block:: YAML+Jinja - :caption: It is simpler when we have a list of pairs: - - vars: - list_of_pairs: [ ['a', 'b'], ['c', 'd'] ] - mydict: "{{ dict(list_of_pairs) }}" - -Both end up being the same thing, with ``zip_longest`` transforming ``single_list`` to a ``list_of_pairs`` generator. - - - -A bit more complex, using ``set_fact`` and a ``loop`` to create/update a dictionary with key value pairs from 2 lists: - -.. code-block:: YAML+Jinja - :caption: Using set_fact to create a dictionary from a set of lists - :emphasize-lines: 3, 4 - - - name: Uses 'combine' to update the dictionary and 'zip' to make pairs of both lists - ansible.builtin.set_fact: - mydict: "{{ mydict | default({}) | combine({item[0]: item[1]}) }}" - loop: "{{ (keys | zip(values)) | list }}" - vars: - keys: - - foo - - var - - bar - values: - - a - - b - - c - -This results in ``{"foo": "a", "var": "b", "bar": "c"}``. - - -You can even combine these simple examples with other filters and lookups to create a dictionary dynamically by matching patterns to variable names: - -.. code-block:: YAML+Jinja - :caption: Using 'vars' to define dictionary from a set of lists without needing a task - - vars: - xyz_stuff: 1234 - xyz_morestuff: 567 - myvarnames: "{{ q('varnames', '^xyz_') }}" - mydict: "{{ dict(myvarnames|map('regex_replace', '^xyz_', '')|list | zip(q('vars', *myvarnames))) }}" - -A quick explanation, since there is a lot to unpack from these two lines: - - - The ``varnames`` lookup returns a list of variables that match "begin with ``xyz_``". - - Then feeding the list from the previous step into the ``vars`` lookup to get the list of values. - The ``*`` is used to 'dereference the list' (a pythonism that works in Jinja), otherwise it would take the list as a single argument. - - Both lists get passed to the ``zip`` filter to pair them off into a unified list (key, value, key2, value2, ...). - - The dict function then takes this 'list of pairs' to create the dictionary. - - -An example on how to use facts to find a host's data that meets condition X: - - -.. code-block:: YAML+Jinja - - vars: - uptime_of_host_most_recently_rebooted: "{{ansible_play_hosts_all | map('extract', hostvars, 'ansible_uptime_seconds') | sort | first}}" - -An example to show a host uptime in days/hours/minutes/seconds (assumes facts were gathered). - -.. code-block:: YAML+Jinja - - - name: Show the uptime in days/hours/minutes/seconds - ansible.builtin.debug: - msg: Uptime {{ now().replace(microsecond=0) - now().fromtimestamp(now(fmt='%s') | int - ansible_uptime_seconds) }} - - -.. seealso:: - - :ref:`playbooks_filters` - Jinja2 filters included with Ansible - :ref:`playbooks_tests` - Jinja2 tests included with Ansible - `Jinja2 Docs `_ - Jinja2 documentation, includes lists for core filters and tests diff --git a/docs/docsite/rst/playbook_guide/guide_rolling_upgrade.rst b/docs/docsite/rst/playbook_guide/guide_rolling_upgrade.rst deleted file mode 100644 index 3031bf7b937..00000000000 --- a/docs/docsite/rst/playbook_guide/guide_rolling_upgrade.rst +++ /dev/null @@ -1,324 +0,0 @@ -********************************************************** -Playbook Example: Continuous Delivery and Rolling Upgrades -********************************************************** - -.. contents:: - :local: - -.. _lamp_introduction: - -What is continuous delivery? -============================ - -Continuous delivery (CD) means frequently delivering updates to your software application. - -The idea is that by updating more often, you do not have to wait for a specific timed period, and your organization -gets better at the process of responding to change. - -Some Ansible users are deploying updates to their end users on an hourly or even more frequent basis -- sometimes every time -there is an approved code change. To achieve this, you need tools to be able to quickly apply those updates in a zero-downtime way. - -This document describes in detail how to achieve this goal, using one of Ansible's most complete example -playbooks as a template: lamp_haproxy. This example uses a lot of Ansible features: roles, templates, -and group variables, and it also comes with an orchestration playbook that can do zero-downtime -rolling upgrades of the web application stack. - -.. note:: - - `Click here for the latest playbooks for this example - `_. - -The playbooks deploy Apache, PHP, MySQL, Nagios, and HAProxy to a CentOS-based set of servers. - -We're not going to cover how to run these playbooks here. Read the included README in the github project along with the -example for that information. Instead, we're going to take a close look at every part of the playbook and describe what it does. - -.. _lamp_deployment: - -Site deployment -=============== - -Let's start with ``site.yml``. This is our site-wide deployment playbook. It can be used to initially deploy the site, as well -as push updates to all of the servers: - -.. code-block:: yaml - - --- - # This playbook deploys the whole application stack in this site. - - # Apply common configuration to all hosts - - hosts: all - - roles: - - common - - # Configure and deploy database servers. - - hosts: dbservers - - roles: - - db - - # Configure and deploy the web servers. Note that we include two roles - # here, the 'base-apache' role which simply sets up Apache, and 'web' - # which includes our example web application. - - - hosts: webservers - - roles: - - base-apache - - web - - # Configure and deploy the load balancer(s). - - hosts: lbservers - - roles: - - haproxy - - # Configure and deploy the Nagios monitoring node(s). - - hosts: monitoring - - roles: - - base-apache - - nagios - -.. note:: - - If you're not familiar with terms like playbooks and plays, you should review :ref:`working_with_playbooks`. - -In this playbook we have 5 plays. The first one targets ``all`` hosts and applies the ``common`` role to all of the hosts. -This is for site-wide things like yum repository configuration, firewall configuration, and anything else that needs to apply to all of the servers. - -The next four plays run against specific host groups and apply specific roles to those servers. -Along with the roles for Nagios monitoring, the database, and the web application, we've implemented a -``base-apache`` role that installs and configures a basic Apache setup. This is used by both the -sample web application and the Nagios hosts. - -.. _lamp_roles: - -Reusable content: roles -======================= - -By now you should have a bit of understanding about roles and how they work in Ansible. Roles are a way to organize -content: tasks, handlers, templates, and files, into reusable components. - -This example has six roles: ``common``, ``base-apache``, ``db``, ``haproxy``, ``nagios``, and ``web``. How you organize -your roles is up to you and your application, but most sites will have one or more common roles that are applied to -all systems, and then a series of application-specific roles that install and configure particular parts of the site. - -Roles can have variables and dependencies, and you can pass in parameters to roles to modify their behavior. -You can read more about roles in the :ref:`playbooks_reuse_roles` section. - -.. _lamp_group_variables: - -Configuration: group variables -============================== - -Group variables are variables that are applied to groups of servers. They can be used in templates and in -playbooks to customize behavior and to provide easily-changed settings and parameters. They are stored in -a directory called ``group_vars`` in the same location as your inventory. -Here is lamp_haproxy's ``group_vars/all`` file. As you might expect, these variables are applied to all of the machines in your inventory: - -.. code-block:: yaml - - --- - httpd_port: 80 - ntpserver: 192.0.2.23 - -This is a YAML file, and you can create lists and dictionaries for more complex variable structures. -In this case, we are just setting two variables, one for the port for the web server, and one for the -NTP server that our machines should use for time synchronization. - -Here's another group variables file. This is ``group_vars/dbservers`` which applies to the hosts in the ``dbservers`` group: - -.. code-block:: yaml - - --- - mysqlservice: mysqld - mysql_port: 3306 - dbuser: root - dbname: foodb - upassword: usersecret - -If you look in the example, there are group variables for the ``webservers`` group and the ``lbservers`` group, similarly. - -These variables are used in a variety of places. You can use them in playbooks, like this, in ``roles/db/tasks/main.yml``: - -.. code-block:: yaml - - - name: Create Application Database - mysql_db: - name: "{{ dbname }}" - state: present - - - name: Create Application DB User - mysql_user: - name: "{{ dbuser }}" - password: "{{ upassword }}" - priv: "*.*:ALL" - host: '%' - state: present - -You can also use these variables in templates, like this, in ``roles/common/templates/ntp.conf.j2``: - -.. code-block:: text - - driftfile /var/lib/ntp/drift - - restrict 127.0.0.1 - restrict -6 ::1 - - server {{ ntpserver }} - - includefile /etc/ntp/crypto/pw - - keys /etc/ntp/keys - -You can see that the variable substitution syntax of {{ and }} is the same for both templates and variables. The syntax -inside the curly braces is Jinja2, and you can do all sorts of operations and apply different filters to the -data inside. In templates, you can also use for loops and if statements to handle more complex situations, -like this, in ``roles/common/templates/iptables.j2``: - -.. code-block:: jinja - - {% if inventory_hostname in groups['dbservers'] %} - -A INPUT -p tcp --dport 3306 -j ACCEPT - {% endif %} - -This is testing to see if the inventory name of the machine we're currently operating on (``inventory_hostname``) -exists in the inventory group ``dbservers``. If so, that machine will get an iptables ACCEPT line for port 3306. - -Here's another example, from the same template: - -.. code-block:: jinja - - {% for host in groups['monitoring'] %} - -A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT - {% endfor %} - -This loops over all of the hosts in the group called ``monitoring``, and adds an ACCEPT line for -each monitoring hosts' default IPv4 address to the current machine's iptables configuration, so that Nagios can monitor those hosts. - -You can learn a lot more about Jinja2 and its capabilities `here `_, and you -can read more about Ansible variables in general in the :ref:`playbooks_variables` section. - -.. _lamp_rolling_upgrade: - -The rolling upgrade -=================== - -Now you have a fully-deployed site with web servers, a load balancer, and monitoring. How do you update it? This is where Ansible's -orchestration features come into play. While some applications use the term 'orchestration' to mean basic ordering or command-blasting, Ansible -refers to orchestration as 'conducting machines like an orchestra', and has a pretty sophisticated engine for it. - -Ansible has the capability to do operations on multi-tier applications in a coordinated way, making it easy to orchestrate a sophisticated zero-downtime rolling upgrade of our web application. This is implemented in a separate playbook, called ``rolling_update.yml``. - -Looking at the playbook, you can see it is made up of two plays. The first play is very simple and looks like this: - -.. code-block:: yaml - - - hosts: monitoring - tasks: [] - -What's going on here, and why are there no tasks? You might know that Ansible gathers "facts" from the servers before operating upon them. These facts are useful for all sorts of things: networking information, OS/distribution versions, and so on. In our case, we need to know something about all of the monitoring servers in our environment before we perform the update, so this simple play forces a fact-gathering step on our monitoring servers. You will see this pattern sometimes, and it's a useful trick to know. - -The next part is the update play. The first part looks like this: - -.. code-block:: yaml - - - hosts: webservers - user: root - serial: 1 - -This is just a normal play definition, operating on the ``webservers`` group. The ``serial`` keyword tells Ansible how many servers to operate on at once. If it's not specified, Ansible will parallelize these operations up to the default "forks" limit specified in the configuration file. But for a zero-downtime rolling upgrade, you may not want to operate on that many hosts at once. If you had just a handful of webservers, you may want to set ``serial`` to 1, for one host at a time. If you have 100, maybe you could set ``serial`` to 10, for ten at a time. - -Here is the next part of the update play: - -.. code-block:: yaml - - pre_tasks: - - name: disable nagios alerts for this host webserver service - nagios: - action: disable_alerts - host: "{{ inventory_hostname }}" - services: webserver - delegate_to: "{{ item }}" - loop: "{{ groups.monitoring }}" - - - name: disable the server in haproxy - shell: echo "disable server myapplb/{{ inventory_hostname }}" | socat stdio /var/lib/haproxy/stats - delegate_to: "{{ item }}" - loop: "{{ groups.lbservers }}" - -.. note:: - - The ``serial`` keyword forces the play to be executed in 'batches'. Each batch counts as a full play with a subselection of hosts. - This has some consequences on play behavior. For example, if all hosts in a batch fails, the play fails, which in turn fails the entire run. You should consider this when combining with ``max_fail_percentage``. - -The ``pre_tasks`` keyword just lets you list tasks to run before the roles are called. This will make more sense in a minute. If you look at the names of these tasks, you can see that we are disabling Nagios alerts and then removing the webserver that we are currently updating from the HAProxy load balancing pool. - -The ``delegate_to`` and ``loop`` arguments, used together, cause Ansible to loop over each monitoring server and load balancer, and perform that operation (delegate that operation) on the monitoring or load balancing server, "on behalf" of the webserver. In programming terms, the outer loop is the list of web servers, and the inner loop is the list of monitoring servers. - -Note that the HAProxy step looks a little complicated. We're using HAProxy in this example because it's freely available, though if you have (for instance) an F5 or Netscaler in your infrastructure (or maybe you have an AWS Elastic IP setup?), you can use Ansible modules to communicate with them instead. You might also wish to use other monitoring modules instead of nagios, but this just shows the main goal of the 'pre tasks' section -- take the server out of monitoring, and take it out of rotation. - -The next step simply re-applies the proper roles to the web servers. This will cause any configuration management declarations in ``web`` and ``base-apache`` roles to be applied to the web servers, including an update of the web application code itself. We don't have to do it this way--we could instead just purely update the web application, but this is a good example of how roles can be used to reuse tasks: - -.. code-block:: yaml - - roles: - - common - - base-apache - - web - -Finally, in the ``post_tasks`` section, we reverse the changes to the Nagios configuration and put the web server back in the load balancing pool: - -.. code-block:: yaml - - post_tasks: - - name: Enable the server in haproxy - shell: echo "enable server myapplb/{{ inventory_hostname }}" | socat stdio /var/lib/haproxy/stats - delegate_to: "{{ item }}" - loop: "{{ groups.lbservers }}" - - - name: re-enable nagios alerts - nagios: - action: enable_alerts - host: "{{ inventory_hostname }}" - services: webserver - delegate_to: "{{ item }}" - loop: "{{ groups.monitoring }}" - -Again, if you were using a Netscaler or F5 or Elastic Load Balancer, you would just substitute in the appropriate modules instead. - -.. _lamp_end_notes: - -Managing other load balancers -============================= - -In this example, we use the simple HAProxy load balancer to front-end the web servers. It's easy to configure and easy to manage. As we have mentioned, Ansible has support for a variety of other load balancers like Citrix NetScaler, F5 BigIP, Amazon Elastic Load Balancers, and more. See the :ref:`working_with_modules` documentation for more information. - -For other load balancers, you may need to send shell commands to them (like we do for HAProxy above), or call an API, if your load balancer exposes one. For the load balancers for which Ansible has modules, you may want to run them as a ``local_action`` if they contact an API. You can read more about local actions in the :ref:`playbooks_delegation` section. Should you develop anything interesting for some hardware where there is not a module, it might make for a good contribution! - -.. _lamp_end_to_end: - -Continuous delivery end-to-end -============================== - -Now that you have an automated way to deploy updates to your application, how do you tie it all together? A lot of organizations use a continuous integration tool like `Jenkins `_ or `Atlassian Bamboo `_ to tie the development, test, release, and deploy steps together. You may also want to use a tool like `Gerrit `_ to add a code review step to commits to either the application code itself, or to your Ansible playbooks, or both. - -Depending on your environment, you might be deploying continuously to a test environment, running an integration test battery against that environment, and then deploying automatically into production. Or you could keep it simple and just use the rolling-update for on-demand deployment into test or production specifically. This is all up to you. - -For integration with Continuous Integration systems, you can easily trigger playbook runs using the ``ansible-playbook`` command line tool, or, if you're using AWX, the ``tower-cli`` command or the built-in REST API. (The tower-cli command 'joblaunch' will spawn a remote job over the REST API and is pretty slick). - -This should give you a good idea of how to structure a multi-tier application with Ansible, and orchestrate operations upon that app, with the eventual goal of continuous delivery to your customers. You could extend the idea of the rolling upgrade to lots of different parts of the app; maybe add front-end web servers along with application servers, for instance, or replace the SQL database with something like MongoDB or Riak. Ansible gives you the capability to easily manage complicated environments and automate common operations. - -.. seealso:: - - `lamp_haproxy example `_ - The lamp_haproxy example discussed here. - :ref:`working_with_playbooks` - An introduction to playbooks - :ref:`playbooks_reuse_roles` - An introduction to playbook roles - :ref:`playbooks_variables` - An introduction to Ansible variables - `Ansible.com: Continuous Delivery `_ - An introduction to Continuous Delivery with Ansible diff --git a/docs/docsite/rst/playbook_guide/index.rst b/docs/docsite/rst/playbook_guide/index.rst deleted file mode 100644 index 56f4d2e9b44..00000000000 --- a/docs/docsite/rst/playbook_guide/index.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _playbook_guide_index: - -####################### -Using Ansible playbooks -####################### - -.. 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 `_. - -Welcome to the Ansible playbooks guide. -Playbooks are automation blueprints, in ``YAML`` format, that Ansible uses to deploy and configure nodes in an inventory. -This guide introduces you to playbooks and then covers different use cases for tasks and plays, such as: - -* Executing tasks with elevated privileges or as a different user. -* Using loops to repeat tasks for items in a list. -* Delegating playbooks to execute tasks on different machines. -* Running conditional tasks and evaluating conditions with playbook tests. -* Using blocks to group sets of tasks. - -You can also learn how to use Ansible playbooks more effectively by creating re-usable files and roles, including and importing playbooks, and running selected parts of a playbook with tags. - -.. toctree:: - :maxdepth: 2 - - playbooks_intro - playbooks - playbooks_execution - playbooks_advanced_syntax - complex_data_manipulation \ No newline at end of file diff --git a/docs/docsite/rst/playbook_guide/playbook_pathing.rst b/docs/docsite/rst/playbook_guide/playbook_pathing.rst deleted file mode 100644 index a049ef0f1cf..00000000000 --- a/docs/docsite/rst/playbook_guide/playbook_pathing.rst +++ /dev/null @@ -1,45 +0,0 @@ -:orphan: - -*********************** -Search paths in Ansible -*********************** - -You can control the paths Ansible searches to find resources on your control node (including configuration, modules, roles, ssh keys, and more) as well as resources on the remote nodes you are managing. Use absolute paths to tell Ansible where to find resources whenever you can. However, absolute paths are not always practical. This page covers how Ansible interprets relative search paths, along with ways to troubleshoot when Ansible cannot find the resource you need. - -.. contents:: - :local: - -Config paths -============ - -By default these should be relative to the config file, some are specifically relative to the current working directory or the playbook and should have this noted in their description. Things like ssh keys are left to use the current working directory because it mirrors how the underlying tools would use it. - -.. _playbook_task_paths: - -Task paths -========== - -Relative paths used in a task typically refer to remote files and directories on the managed nodes. However, paths passed to lookup plugins and some paths used in action plugins such as the "src" path for the :ref:`template ` and :ref:`copy ` modules refer to local files and directories on the control node. - -Resolving local relative paths ------------------------------- - -When you specify a relative path for a local file, Ansible will try to find that file first in the current task's role, then in other roles that included or depend on the current role, then relative to the file in which the task is defined, and finally relative to the current play. It will take the first matching file that it finds. This way, if multiple files with the same filename exist, Ansible will find the file that is closest to the current task and that is most likely to be file you wanted. - -Specifically, Ansible tries to find the file - -1. In the current role. - - 1. In its appropriate subdirectory—"files", "vars", "templates" or "tasks", depending on the kind of file Ansible is searching for. - 2. Directly in its directory. - -2. Like 1, in the parent role that called into this current role with `include_role`, `import_role`, or with a role dependency. If the parent role has its own parent role, Ansible will repeat this step with that role. -3. Like 1, in the current task file's directory. -4. Like 1, in the current play file's directory. - -Ansible does not search the current working directory. (The directory you're in when you execute Ansible.) Also, Ansible will only search within a role if you actually included it with an `include_role` or `import_role` task or a dependency. If you instead use `include`, `include_task` or `import_task` to include just the tasks from a specific file but not the full role, Ansible will not search that role in steps 1 and 2. - -When you execute Ansible, the variable `ansible_search_path` will contain the paths searched, in the order they were searched in but without listing their subdirectories. If you run Ansible in verbosity level 5 by passing the `-vvvvv` argument, Ansible will report each directory as it searches, except when it searches for a tasks file. - - -.. note:: The current working directory might vary depending on the connection plugin and if the action is local or remote. For the remote it is normally the directory on which the login shell puts the user. For local it is either the directory you executed ansible from or in some cases the playbook directory. diff --git a/docs/docsite/rst/playbook_guide/playbooks.rst b/docs/docsite/rst/playbook_guide/playbooks.rst deleted file mode 100644 index 48ea92fb57e..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks.rst +++ /dev/null @@ -1,42 +0,0 @@ -.. _working_with_playbooks: - -Working with playbooks -====================== - -Playbooks record and execute Ansible's configuration, deployment, and orchestration functions. -They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process. - -If Ansible modules are the tools in your workshop, playbooks are your instruction manuals, and your inventory of hosts are your raw material. - -At a basic level, playbooks can be used to manage configurations of and deployments to remote machines. -At a more advanced level, they can sequence multi-tier rollouts involving rolling updates, and can delegate actions to other hosts, interacting with monitoring servers and load balancers along the way. - -Playbooks are designed to be human-readable and are developed in a basic text language. -There are multiple ways to organize playbooks and the files they include, and we'll offer up some suggestions on that and making the most out of Ansible. - -You should look at `Example Playbooks `_ while reading along with the playbook documentation. -These illustrate best practices as well as how to put many of the various concepts together. - -.. toctree:: - :maxdepth: 2 - - playbooks_templating - playbooks_filters - playbooks_tests - playbooks_lookups - playbooks_python_version - playbooks_templating_now - playbooks_loops - playbooks_delegation - playbooks_conditionals - playbooks_blocks - playbooks_handlers - playbooks_error_handling - playbooks_environment - playbooks_reuse - playbooks_reuse_roles - playbooks_module_defaults - playbooks_prompts - playbooks_variables - playbooks_vars_facts - guide_rolling_upgrade diff --git a/docs/docsite/rst/playbook_guide/playbooks_advanced_syntax.rst b/docs/docsite/rst/playbook_guide/playbooks_advanced_syntax.rst deleted file mode 100644 index ee6ff67fe98..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_advanced_syntax.rst +++ /dev/null @@ -1,122 +0,0 @@ -.. _playbooks_advanced_syntax: - -************************ -Advanced playbook syntax -************************ - -The advanced YAML syntax examples on this page give you more control over the data placed in YAML files used by Ansible. -You can find additional information about Python-specific YAML in the official `PyYAML Documentation `_. - -.. _unsafe_strings: - -Unsafe or raw strings -===================== - -When handling values returned by lookup plugins, Ansible uses a data type called ``unsafe`` to block templating. Marking data as unsafe prevents malicious users from abusing Jinja2 templates to execute arbitrary code on target machines. The Ansible implementation ensures that unsafe values are never templated. It is more comprehensive than escaping Jinja2 with ``{% raw %} ... {% endraw %}`` tags. - -You can use the same ``unsafe`` data type in variables you define, to prevent templating errors and information disclosure. You can mark values supplied by :ref:`vars_prompts` as unsafe. You can also use ``unsafe`` in playbooks. The most common use cases include passwords that allow special characters like ``{`` or ``%``, and JSON arguments that look like templates but should not be templated. For example: - -.. code-block:: yaml - - --- - mypassword: !unsafe 234%234{435lkj{{lkjsdf - -In a playbook: - -.. code-block:: yaml - - --- - hosts: all - vars: - my_unsafe_variable: !unsafe 'unsafe % value' - tasks: - ... - -For complex variables such as hashes or arrays, use ``!unsafe`` on the individual elements: - -.. code-block:: yaml - - --- - my_unsafe_array: - - !unsafe 'unsafe element' - - 'safe element' - - my_unsafe_hash: - unsafe_key: !unsafe 'unsafe value' - -.. _anchors_and_aliases: - -YAML anchors and aliases: sharing variable values -================================================= - -`YAML anchors and aliases `_ help you define, maintain, and use shared variable values in a flexible way. -You define an anchor with ``&``, then refer to it using an alias, denoted with ``*``. Here's an example that sets three values with an anchor, uses two of those values with an alias, and overrides the third value: - -.. code-block:: yaml - - --- - ... - vars: - app1: - jvm: &jvm_opts - opts: '-Xms1G -Xmx2G' - port: 1000 - path: /usr/lib/app1 - app2: - jvm: - <<: *jvm_opts - path: /usr/lib/app2 - ... - -Here, ``app1`` and ``app2`` share the values for ``opts`` and ``port`` using the anchor ``&jvm_opts`` and the alias ``*jvm_opts``. -The value for ``path`` is merged by ``<<`` or `merge operator `_. - -Anchors and aliases also let you share complex sets of variable values, including nested variables. If you have one variable value that includes another variable value, you can define them separately: - -.. code-block:: yaml - - vars: - webapp_version: 1.0 - webapp_custom_name: ToDo_App-1.0 - -This is inefficient and, at scale, means more maintenance. To incorporate the version value in the name, you can use an anchor in ``app_version`` and an alias in ``custom_name``: - -.. code-block:: yaml - - vars: - webapp: - version: &my_version 1.0 - custom_name: - - "ToDo_App" - - *my_version - -Now, you can re-use the value of ``app_version`` within the value of ``custom_name`` and use the output in a template: - -.. code-block:: yaml - - --- - - name: Using values nested inside dictionary - hosts: localhost - vars: - webapp: - version: &my_version 1.0 - custom_name: - - "ToDo_App" - - *my_version - tasks: - - name: Using Anchor value - ansible.builtin.debug: - msg: My app is called "{{ webapp.custom_name | join('-') }}". - -You've anchored the value of ``version`` with the ``&my_version`` anchor, and re-used it with the ``*my_version`` alias. Anchors and aliases let you access nested values inside dictionaries. - -.. seealso:: - - :ref:`playbooks_variables` - All about variables - :ref:`complex_data_manipulation` - Doing complex data manipulation in Ansible - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_async.rst b/docs/docsite/rst/playbook_guide/playbooks_async.rst deleted file mode 100644 index 2f56dbf78cb..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_async.rst +++ /dev/null @@ -1,189 +0,0 @@ -.. _playbooks_async: - -Asynchronous actions and polling -================================ - -By default Ansible runs tasks synchronously, holding the connection to the remote node open until the action is completed. This means within a playbook, each task blocks the next task by default, meaning subsequent tasks will not run until the current task completes. This behavior can create challenges. For example, a task may take longer to complete than the SSH session allows for, causing a timeout. Or you may want a long-running process to execute in the background while you perform other tasks concurrently. Asynchronous mode lets you control how long-running tasks execute. - -.. contents:: - :local: - -Asynchronous ad hoc tasks -------------------------- - -You can execute long-running operations in the background with :ref:`ad hoc tasks `. For example, to execute ``long_running_operation`` asynchronously in the background, with a timeout (``-B``) of 3600 seconds, and without polling (``-P``): - -.. code-block:: bash - - $ ansible all -B 3600 -P 0 -a "/usr/bin/long_running_operation --do-stuff" - -To check on the job status later, use the ``async_status`` module, passing it the job ID that was returned when you ran the original job in the background: - -.. code-block:: bash - - $ ansible web1.example.com -m async_status -a "jid=488359678239.2844" - -Ansible can also check on the status of your long-running job automatically with polling. In most cases, Ansible will keep the connection to your remote node open between polls. To run for 30 minutes and poll for status every 60 seconds: - -.. code-block:: bash - - $ ansible all -B 1800 -P 60 -a "/usr/bin/long_running_operation --do-stuff" - -Poll mode is smart so all jobs will be started before polling begins on any machine. Be sure to use a high enough ``--forks`` value if you want to get all of your jobs started very quickly. After the time limit (in seconds) runs out (``-B``), the process on the remote nodes will be terminated. - -Asynchronous mode is best suited to long-running shell commands or software upgrades. Running the copy module asynchronously, for example, does not do a background file transfer. - -Asynchronous playbook tasks ---------------------------- - -:ref:`Playbooks ` also support asynchronous mode and polling, with a simplified syntax. You can use asynchronous mode in playbooks to avoid connection timeouts or to avoid blocking subsequent tasks. The behavior of asynchronous mode in a playbook depends on the value of `poll`. - -Avoid connection timeouts: poll > 0 -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you want to set a longer timeout limit for a certain task in your playbook, use ``async`` with ``poll`` set to a positive value. Ansible will still block the next task in your playbook, waiting until the async task either completes, fails or times out. However, the task will only time out if it exceeds the timeout limit you set with the ``async`` parameter. - -To avoid timeouts on a task, specify its maximum runtime and how frequently you would like to poll for status: - -.. code-block:: yaml - - --- - - - hosts: all - remote_user: root - - tasks: - - - name: Simulate long running op (15 sec), wait for up to 45 sec, poll every 5 sec - ansible.builtin.command: /bin/sleep 15 - async: 45 - poll: 5 - -.. note:: - The default poll value is set by the :ref:`DEFAULT_POLL_INTERVAL` setting. - There is no default for the async time limit. If you leave off the - 'async' keyword, the task runs synchronously, which is Ansible's - default. - -.. note:: - As of Ansible 2.3, async does not support check mode and will fail the - task when run in check mode. See :ref:`check_mode_dry` on how to - skip a task in check mode. - -.. note:: - When an async task completes with polling enabled, the temporary async job cache - file (by default in ~/.ansible_async/) is automatically removed. - -Run tasks concurrently: poll = 0 -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you want to run multiple tasks in a playbook concurrently, use ``async`` with ``poll`` set to 0. When you set ``poll: 0``, Ansible starts the task and immediately moves on to the next task without waiting for a result. Each async task runs until it either completes, fails or times out (runs longer than its ``async`` value). The playbook run ends without checking back on async tasks. - -To run a playbook task asynchronously: - -.. code-block:: yaml - - --- - - - hosts: all - remote_user: root - - tasks: - - - name: Simulate long running op, allow to run for 45 sec, fire and forget - ansible.builtin.command: /bin/sleep 15 - async: 45 - poll: 0 - -.. note:: - Do not specify a poll value of 0 with operations that require exclusive locks (such as yum transactions) if you expect to run other commands later in the playbook against those same resources. - -.. note:: - Using a higher value for ``--forks`` will result in kicking off asynchronous tasks even faster. This also increases the efficiency of polling. - -.. note:: - When running with ``poll: 0``, Ansible will not automatically cleanup the async job cache file. - You will need to manually clean this up with the :ref:`async_status ` module - with ``mode: cleanup``. - -If you need a synchronization point with an async task, you can register it to obtain its job ID and use the :ref:`async_status ` module to observe it in a later task. For example: - -.. code-block:: yaml+jinja - - - name: Run an async task - ansible.builtin.yum: - name: docker-io - state: present - async: 1000 - poll: 0 - register: yum_sleeper - - - name: Check on an async task - async_status: - jid: "{{ yum_sleeper.ansible_job_id }}" - register: job_result - until: job_result.finished - retries: 100 - delay: 10 - -.. note:: - If the value of ``async:`` is not high enough, this will cause the - "check on it later" task to fail because the temporary status file that - the ``async_status:`` is looking for will not have been written or no longer exist - -.. note:: - Asynchronous playbook tasks always return changed. If the task is using a module - that requires the user to annotate changes with ``changed_when``, ``creates``, and so on, - then those should be added to the following ``async_status`` task. - -To run multiple asynchronous tasks while limiting the number of tasks running concurrently: - -.. code-block:: yaml+jinja - - ##################### - # main.yml - ##################### - - name: Run items asynchronously in batch of two items - vars: - sleep_durations: - - 1 - - 2 - - 3 - - 4 - - 5 - durations: "{{ item }}" - include_tasks: execute_batch.yml - loop: "{{ sleep_durations | batch(2) | list }}" - - ##################### - # execute_batch.yml - ##################### - - name: Async sleeping for batched_items - ansible.builtin.command: sleep {{ async_item }} - async: 45 - poll: 0 - loop: "{{ durations }}" - loop_control: - loop_var: "async_item" - register: async_results - - - name: Check sync status - async_status: - jid: "{{ async_result_item.ansible_job_id }}" - loop: "{{ async_results.results }}" - loop_control: - loop_var: "async_result_item" - register: async_poll_results - until: async_poll_results.finished - retries: 30 - -.. seealso:: - - :ref:`playbooks_strategies` - Options for controlling playbook execution - :ref:`playbooks_intro` - An introduction to playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_blocks.rst b/docs/docsite/rst/playbook_guide/playbooks_blocks.rst deleted file mode 100644 index 947d1060225..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_blocks.rst +++ /dev/null @@ -1,193 +0,0 @@ -.. _playbooks_blocks: - -****** -Blocks -****** - -Blocks create logical groups of tasks. Blocks also offer ways to handle task errors, similar to exception handling in many programming languages. - -.. contents:: - :local: - -Grouping tasks with blocks -========================== - -All tasks in a block inherit directives applied at the block level. Most of what you can apply to a single task (with the exception of loops) can be applied at the block level, so blocks make it much easier to set data or directives common to the tasks. The directive does not affect the block itself, it is only inherited by the tasks enclosed by a block. For example, a `when` statement is applied to the tasks within a block, not to the block itself. - -.. code-block:: YAML - :emphasize-lines: 3 - :caption: Block example with named tasks inside the block - - tasks: - - name: Install, configure, and start Apache - block: - - name: Install httpd and memcached - ansible.builtin.yum: - name: - - httpd - - memcached - state: present - - - name: Apply the foo config template - ansible.builtin.template: - src: templates/src.j2 - dest: /etc/foo.conf - - - name: Start service bar and enable it - ansible.builtin.service: - name: bar - state: started - enabled: True - when: ansible_facts['distribution'] == 'CentOS' - become: true - become_user: root - ignore_errors: true - -In the example above, the 'when' condition will be evaluated before Ansible runs each of the three tasks in the block. All three tasks also inherit the privilege escalation directives, running as the root user. Finally, ``ignore_errors: true`` ensures that Ansible continues to execute the playbook even if some of the tasks fail. - -Names for blocks have been available since Ansible 2.3. We recommend using names in all tasks, within blocks or elsewhere, for better visibility into the tasks being executed when you run the playbook. - -.. _block_error_handling: - -Handling errors with blocks -=========================== - -You can control how Ansible responds to task errors using blocks with ``rescue`` and ``always`` sections. - -Rescue blocks specify tasks to run when an earlier task in a block fails. This approach is similar to exception handling in many programming languages. Ansible only runs rescue blocks after a task returns a 'failed' state. Bad task definitions and unreachable hosts will not trigger the rescue block. - -.. _block_rescue: -.. code-block:: YAML - :emphasize-lines: 3,14 - :caption: Block error handling example - - tasks: - - name: Handle the error - block: - - name: Print a message - ansible.builtin.debug: - msg: 'I execute normally' - - - name: Force a failure - ansible.builtin.command: /bin/false - - - name: Never print this - ansible.builtin.debug: - msg: 'I never execute, due to the above task failing, :-(' - rescue: - - name: Print when errors - ansible.builtin.debug: - msg: 'I caught an error, can do stuff here to fix it, :-)' - -You can also add an ``always`` section to a block. Tasks in the ``always`` section run no matter what the task status of the previous block is. - -.. _block_always: -.. code-block:: YAML - :emphasize-lines: 2,13 - :caption: Block with always section - - - name: Always do X - block: - - name: Print a message - ansible.builtin.debug: - msg: 'I execute normally' - - - name: Force a failure - ansible.builtin.command: /bin/false - - - name: Never print this - ansible.builtin.debug: - msg: 'I never execute :-(' - always: - - name: Always do this - ansible.builtin.debug: - msg: "This always executes, :-)" - -Together, these elements offer complex error handling. - -.. code-block:: YAML - :emphasize-lines: 2,13,24 - :caption: Block with all sections - - - name: Attempt and graceful roll back demo - block: - - name: Print a message - ansible.builtin.debug: - msg: 'I execute normally' - - - name: Force a failure - ansible.builtin.command: /bin/false - - - name: Never print this - ansible.builtin.debug: - msg: 'I never execute, due to the above task failing, :-(' - rescue: - - name: Print when errors - ansible.builtin.debug: - msg: 'I caught an error' - - - name: Force a failure in middle of recovery! >:-) - ansible.builtin.command: /bin/false - - - name: Never print this - ansible.builtin.debug: - msg: 'I also never execute :-(' - always: - - name: Always do this - ansible.builtin.debug: - msg: "This always executes" - -The tasks in the ``block`` execute normally. If any tasks in the block return ``failed``, the ``rescue`` section executes tasks to recover from the error. The ``always`` section runs regardless of the results of the ``block`` and ``rescue`` sections. - -If an error occurs in the block and the rescue task succeeds, Ansible reverts the failed status of the original task for the run and continues to run the play as if the original task had succeeded. The rescued task is considered successful, and does not trigger ``max_fail_percentage`` or ``any_errors_fatal`` configurations. However, Ansible still reports a failure in the playbook statistics. - -You can use blocks with ``flush_handlers`` in a rescue task to ensure that all handlers run even if an error occurs: - -.. code-block:: YAML - :emphasize-lines: 3,12 - :caption: Block run handlers in error handling - - tasks: - - name: Attempt and graceful roll back demo - block: - - name: Print a message - ansible.builtin.debug: - msg: 'I execute normally' - changed_when: true - notify: Run me even after an error - - - name: Force a failure - ansible.builtin.command: /bin/false - rescue: - - name: Make sure all handlers run - meta: flush_handlers - handlers: - - name: Run me even after an error - ansible.builtin.debug: - msg: 'This handler runs even on error' - - -.. versionadded:: 2.1 - -Ansible provides a couple of variables for tasks in the ``rescue`` portion of a block: - -ansible_failed_task - The task that returned 'failed' and triggered the rescue. For example, to get the name use ``ansible_failed_task.name``. - -ansible_failed_result - The captured return result of the failed task that triggered the rescue. This would equate to having used this var in the ``register`` keyword. - -.. note:: - - In ``ansible-core`` 2.14 or later, both variables are propagated from an inner block to an outer ``rescue`` portion of a block. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst b/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst deleted file mode 100644 index 8e5619d0a5a..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst +++ /dev/null @@ -1,107 +0,0 @@ -.. _check_mode_dry: - -****************************************** -Validating tasks: check mode and diff mode -****************************************** - -Ansible provides two modes of execution that validate tasks: check mode and diff mode. These modes can be used separately or together. They are useful when you are creating or editing a playbook or role and you want to know what it will do. In check mode, Ansible runs without making any changes on remote systems. Modules that support check mode report the changes they would have made. Modules that do not support check mode report nothing and do nothing. In diff mode, Ansible provides before-and-after comparisons. Modules that support diff mode display detailed information. You can combine check mode and diff mode for detailed validation of your playbook or role. - -.. contents:: - :local: - -Using check mode -================ - -Check mode is just a simulation. It will not generate output for tasks that use :ref:`conditionals based on registered variables ` (results of prior tasks). However, it is great for validating configuration management playbooks that run on one node at a time. To run a playbook in check mode: - -.. code-block:: console - - ansible-playbook foo.yml --check - -.. _forcing_to_run_in_check_mode: - -Enforcing or preventing check mode on tasks -------------------------------------------- - -.. versionadded:: 2.2 - -If you want certain tasks to run in check mode always, or never, regardless of whether you run the playbook with or without ``--check``, you can add the ``check_mode`` option to those tasks: - - - To force a task to run in check mode, even when the playbook is called without ``--check``, set ``check_mode: true``. - - To force a task to run in normal mode and make changes to the system, even when the playbook is called with ``--check``, set ``check_mode: false``. - -For example: - -.. code-block:: yaml - - tasks: - - name: This task will always make changes to the system - ansible.builtin.command: /something/to/run --even-in-check-mode - check_mode: false - - - name: This task will never make changes to the system - ansible.builtin.lineinfile: - line: "important config" - dest: /path/to/myconfig.conf - state: present - check_mode: true - register: changes_to_important_config - -Running single tasks with ``check_mode: true`` can be useful for testing Ansible modules, either to test the module itself or to test the conditions under which a module would make changes. You can register variables (see :ref:`playbooks_conditionals`) on these tasks for even more detail on the potential changes. - -.. note:: Prior to version 2.2 only the equivalent of ``check_mode: false`` existed. The notation for that was ``always_run: true``. - -Skipping tasks or ignoring errors in check mode ------------------------------------------------ - -.. versionadded:: 2.1 - -If you want to skip a task or ignore errors on a task when you run Ansible in check mode, you can use a boolean magic variable ``ansible_check_mode``, which is set to ``True`` when Ansible runs in check mode. For example: - -.. code-block:: yaml - - tasks: - - - name: This task will be skipped in check mode - ansible.builtin.git: - repo: ssh://git@github.com/mylogin/hello.git - dest: /home/mylogin/hello - when: not ansible_check_mode - - - name: This task will ignore errors in check mode - ansible.builtin.git: - repo: ssh://git@github.com/mylogin/hello.git - dest: /home/mylogin/hello - ignore_errors: "{{ ansible_check_mode }}" - -.. _diff_mode: - -Using diff mode -=============== - -The ``--diff`` option for ansible-playbook can be used alone or with ``--check``. When you run in diff mode, any module that supports diff mode reports the changes made or, if used with ``--check``, the changes that would have been made. Diff mode is most common in modules that manipulate files (for example, the template module) but other modules might also show 'before and after' information (for example, the user module). - -Diff mode produces a large amount of output, so it is best used when checking a single host at a time. For example: - -.. code-block:: console - - ansible-playbook foo.yml --check --diff --limit foo.example.com - -.. versionadded:: 2.4 - -Enforcing or preventing diff mode on tasks ------------------------------------------- - -Because the ``--diff`` option can reveal sensitive information, you can disable it for a task by specifying ``diff: false``. For example: - -.. code-block:: yaml - - tasks: - - name: This task will not report a diff when the file changes - ansible.builtin.template: - src: secret.conf.j2 - dest: /etc/secret.conf - owner: root - group: root - mode: '0600' - diff: false diff --git a/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst b/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst deleted file mode 100644 index c6e4c871771..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst +++ /dev/null @@ -1,593 +0,0 @@ -.. _playbooks_conditionals: - -************ -Conditionals -************ - -In a playbook, you may want to execute different tasks, or have different goals, depending on the value of a fact (data about the remote system), a variable, or the result of a previous task. You may want the value of some variables to depend on the value of other variables. Or you may want to create additional groups of hosts based on whether the hosts match other criteria. You can do all of these things with conditionals. - -Ansible uses Jinja2 :ref:`tests ` and :ref:`filters ` in conditionals. Ansible supports all the standard tests and filters, and adds some unique ones as well. - -.. note:: - - There are many options to control execution flow in Ansible. You can find more examples of supported conditionals at ``_. - -.. contents:: - :local: - -.. _the_when_statement: - -Basic conditionals with ``when`` -================================ - -The simplest conditional statement applies to a single task. Create the task, then add a ``when`` statement that applies a test. The ``when`` clause is a raw Jinja2 expression without double curly braces (see :ref:`group_by_module`). When you run the task or playbook, Ansible evaluates the test for all hosts. On any host where the test passes (returns a value of True), Ansible runs that task. For example, if you are installing mysql on multiple machines, some of which have SELinux enabled, you might have a task to configure SELinux to allow mysql to run. You would only want that task to run on machines that have SELinux enabled: - -.. code-block:: yaml - - tasks: - - name: Configure SELinux to start mysql on any port - ansible.posix.seboolean: - name: mysql_connect_any - state: true - persistent: true - when: ansible_selinux.status == "enabled" - # all variables can be used directly in conditionals without double curly braces - -Conditionals based on ansible_facts ------------------------------------ - -Often you want to execute or skip a task based on facts. Facts are attributes of individual hosts, including IP address, operating system, the status of a filesystem, and many more. With conditionals based on facts: - - - You can install a certain package only when the operating system is a particular version. - - You can skip configuring a firewall on hosts with internal IP addresses. - - You can perform cleanup tasks only when a filesystem is getting full. - -See :ref:`commonly_used_facts` for a list of facts that frequently appear in conditional statements. Not all facts exist for all hosts. For example, the 'lsb_major_release' fact used in an example below only exists when the lsb_release package is installed on the target host. To see what facts are available on your systems, add a debug task to your playbook: - -.. code-block:: yaml - - - name: Show facts available on the system - ansible.builtin.debug: - var: ansible_facts - -Here is a sample conditional based on a fact: - -.. code-block:: yaml - - tasks: - - name: Shut down Debian flavored systems - ansible.builtin.command: /sbin/shutdown -t now - when: ansible_facts['os_family'] == "Debian" - -If you have multiple conditions, you can group them with parentheses: - -.. code-block:: yaml - - tasks: - - name: Shut down CentOS 6 and Debian 7 systems - ansible.builtin.command: /sbin/shutdown -t now - when: (ansible_facts['distribution'] == "CentOS" and ansible_facts['distribution_major_version'] == "6") or - (ansible_facts['distribution'] == "Debian" and ansible_facts['distribution_major_version'] == "7") - -You can use `logical operators `_ to combine conditions. When you have multiple conditions that all need to be true (that is, a logical ``and``), you can specify them as a list: - -.. code-block:: yaml - - tasks: - - name: Shut down CentOS 6 systems - ansible.builtin.command: /sbin/shutdown -t now - when: - - ansible_facts['distribution'] == "CentOS" - - ansible_facts['distribution_major_version'] == "6" - -If a fact or variable is a string, and you need to run a mathematical comparison on it, use a filter to ensure that Ansible reads the value as an integer: - -.. code-block:: yaml - - tasks: - - ansible.builtin.shell: echo "only on Red Hat 6, derivatives, and later" - when: ansible_facts['os_family'] == "RedHat" and ansible_facts['lsb']['major_release'] | int >= 6 - -.. _conditionals_registered_vars: - -Conditions based on registered variables ----------------------------------------- - -Often in a playbook you want to execute or skip a task based on the outcome of an earlier task. For example, you might want to configure a service after it is upgraded by an earlier task. To create a conditional based on a registered variable: - - #. Register the outcome of the earlier task as a variable. - #. Create a conditional test based on the registered variable. - -You create the name of the registered variable using the ``register`` keyword. A registered variable always contains the status of the task that created it as well as any output that task generated. You can use registered variables in templates and action lines as well as in conditional ``when`` statements. You can access the string contents of the registered variable using ``variable.stdout``. For example: - -.. code-block:: yaml - - - name: Test play - hosts: all - - tasks: - - - name: Register a variable - ansible.builtin.shell: cat /etc/motd - register: motd_contents - - - name: Use the variable in conditional statement - ansible.builtin.shell: echo "motd contains the word hi" - when: motd_contents.stdout.find('hi') != -1 - -You can use registered results in the loop of a task if the variable is a list. If the variable is not a list, you can convert it into a list, with either ``stdout_lines`` or with ``variable.stdout.split()``. You can also split the lines by other fields: - -.. code-block:: yaml - - - name: Registered variable usage as a loop list - hosts: all - tasks: - - - name: Retrieve the list of home directories - ansible.builtin.command: ls /home - register: home_dirs - - - name: Add home dirs to the backup spooler - ansible.builtin.file: - path: /mnt/bkspool/{{ item }} - src: /home/{{ item }} - state: link - loop: "{{ home_dirs.stdout_lines }}" - # same as loop: "{{ home_dirs.stdout.split() }}" - -The string content of a registered variable can be empty. If you want to run another task only on hosts where the stdout of your registered variable is empty, check the registered variable's string contents for emptiness: - -.. code-block:: yaml - - - name: check registered variable for emptiness - hosts: all - - tasks: - - - name: List contents of directory - ansible.builtin.command: ls mydir - register: contents - - - name: Check contents for emptiness - ansible.builtin.debug: - msg: "Directory is empty" - when: contents.stdout == "" - -Ansible always registers something in a registered variable for every host, even on hosts where a task fails or Ansible skips a task because a condition is not met. To run a follow-up task on these hosts, query the registered variable for ``is skipped`` (not for "undefined" or "default"). See :ref:`registered_variables` for more information. Here are sample conditionals based on the success or failure of a task. Remember to ignore errors if you want Ansible to continue executing on a host when a failure occurs: - -.. code-block:: yaml - - tasks: - - name: Register a variable, ignore errors and continue - ansible.builtin.command: /bin/false - register: result - ignore_errors: true - - - name: Run only if the task that registered the "result" variable fails - ansible.builtin.command: /bin/something - when: result is failed - - - name: Run only if the task that registered the "result" variable succeeds - ansible.builtin.command: /bin/something_else - when: result is succeeded - - - name: Run only if the task that registered the "result" variable is skipped - ansible.builtin.command: /bin/still/something_else - when: result is skipped - - - name: Run only if the task that registered the "result" variable changed something. - ansible.builtin.command: /bin/still/something_else - when: result is changed - -.. note:: Older versions of Ansible used ``success`` and ``fail``, but ``succeeded`` and ``failed`` use the correct tense. All of these options are now valid. - - -Conditionals based on variables -------------------------------- - -You can also create conditionals based on variables defined in the playbooks or inventory. Because conditionals require boolean input (a test must evaluate as True to trigger the condition), you must apply the ``| bool`` filter to non boolean variables, such as string variables with content like 'yes', 'on', '1', or 'true'. You can define variables like this: - -.. code-block:: yaml - - vars: - epic: true - monumental: "yes" - -With the variables above, Ansible would run one of these tasks and skip the other: - -.. code-block:: yaml - - tasks: - - name: Run the command if "epic" or "monumental" is true - ansible.builtin.shell: echo "This certainly is epic!" - when: epic or monumental | bool - - - name: Run the command if "epic" is false - ansible.builtin.shell: echo "This certainly isn't epic!" - when: not epic - -If a required variable has not been set, you can skip or fail using Jinja2's `defined` test. For example: - -.. code-block:: yaml - - tasks: - - name: Run the command if "foo" is defined - ansible.builtin.shell: echo "I've got '{{ foo }}' and am not afraid to use it!" - when: foo is defined - - - name: Fail if "bar" is undefined - ansible.builtin.fail: msg="Bailing out. This play requires 'bar'" - when: bar is undefined - -This is especially useful in combination with the conditional import of vars files (see below). -As the examples show, you do not need to use `{{ }}` to use variables inside conditionals, as these are already implied. - -.. _loops_and_conditionals: - -Using conditionals in loops ---------------------------- - -If you combine a ``when`` statement with a :ref:`loop `, Ansible processes the condition separately for each item. This is by design, so you can execute the task on some items in the loop and skip it on other items. For example: - -.. code-block:: yaml - - tasks: - - name: Run with items greater than 5 - ansible.builtin.command: echo {{ item }} - loop: [ 0, 2, 4, 6, 8, 10 ] - when: item > 5 - -If you need to skip the whole task when the loop variable is undefined, use the `|default` filter to provide an empty iterator. For example, when looping over a list: - -.. code-block:: yaml - - - name: Skip the whole task when a loop variable is undefined - ansible.builtin.command: echo {{ item }} - loop: "{{ mylist|default([]) }}" - when: item > 5 - -You can do the same thing when looping over a dict: - -.. code-block:: yaml - - - name: The same as above using a dict - ansible.builtin.command: echo {{ item.key }} - loop: "{{ query('dict', mydict|default({})) }}" - when: item.value > 5 - -.. _loading_in_custom_facts: - -Loading custom facts --------------------- - -You can provide your own facts, as described in :ref:`developing_modules`. To run them, just make a call to your own custom fact gathering module at the top of your list of tasks, and variables returned there will be accessible to future tasks: - -.. code-block:: yaml - - tasks: - - name: Gather site specific fact data - action: site_facts - - - name: Use a custom fact - ansible.builtin.command: /usr/bin/thingy - when: my_custom_fact_just_retrieved_from_the_remote_system == '1234' - -.. _when_with_reuse: - -Conditionals with re-use ------------------------- - -You can use conditionals with re-usable tasks files, playbooks, or roles. Ansible executes these conditional statements differently for dynamic re-use (includes) and for static re-use (imports). See :ref:`playbooks_reuse` for more information on re-use in Ansible. - -.. _conditional_imports: - -Conditionals with imports -^^^^^^^^^^^^^^^^^^^^^^^^^ - -When you add a conditional to an import statement, Ansible applies the condition to all tasks within the imported file. This behavior is the equivalent of :ref:`tag_inheritance`. Ansible applies the condition to every task, and evaluates each task separately. For example, if you want to define and then display a variable that was not previously defined, you might have a playbook called ``main.yml`` and a tasks file called ``other_tasks.yml``: - -.. code-block:: yaml - - # all tasks within an imported file inherit the condition from the import statement - # main.yml - - hosts: all - tasks: - - import_tasks: other_tasks.yml # note "import" - when: x is not defined - - # other_tasks.yml - - name: Set a variable - ansible.builtin.set_fact: - x: foo - - - name: Print a variable - ansible.builtin.debug: - var: x - -Ansible expands this at execution time to the equivalent of: - -.. code-block:: yaml - - - name: Set a variable if not defined - ansible.builtin.set_fact: - x: foo - when: x is not defined - # this task sets a value for x - - - name: Do the task if "x" is not defined - ansible.builtin.debug: - var: x - when: x is not defined - # Ansible skips this task, because x is now defined - -If ``x`` is initially defined, both tasks are skipped as intended. But if ``x`` is initially undefined, the debug task will be skipped since the conditional is evaluated for every imported task. The conditional will evaluate to ``true`` for the ``set_fact`` task, which will define the variable and cause the ``debug`` conditional to evaluate to ``false``. - -If this is not the behavior you want, use an ``include_*`` statement to apply a condition only to that statement itself. - -.. code-block:: yaml - - # using a conditional on include_* only applies to the include task itself - # main.yml - - hosts: all - tasks: - - include_tasks: other_tasks.yml # note "include" - when: x is not defined - -Now if ``x`` is initially undefined, the debug task will not be skipped because the conditional is evaluated at the time of the include and does not apply to the individual tasks. - -You can apply conditions to ``import_playbook`` as well as to the other ``import_*`` statements. When you use this approach, Ansible returns a 'skipped' message for every task on every host that does not match the criteria, creating repetitive output. In many cases the :ref:`group_by module ` can be a more streamlined way to accomplish the same objective; see :ref:`os_variance`. - -.. _conditional_includes: - -Conditionals with includes -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When you use a conditional on an ``include_*`` statement, the condition is applied only to the include task itself and not to any other tasks within the included file(s). To contrast with the example used for conditionals on imports above, look at the same playbook and tasks file, but using an include instead of an import: - -.. code-block:: yaml - - # Includes let you re-use a file to define a variable when it is not already defined - - # main.yml - - include_tasks: other_tasks.yml - when: x is not defined - - # other_tasks.yml - - name: Set a variable - ansible.builtin.set_fact: - x: foo - - - name: Print a variable - ansible.builtin.debug: - var: x - -Ansible expands this at execution time to the equivalent of: - -.. code-block:: yaml - - # main.yml - - include_tasks: other_tasks.yml - when: x is not defined - # if condition is met, Ansible includes other_tasks.yml - - # other_tasks.yml - - name: Set a variable - ansible.builtin.set_fact: - x: foo - # no condition applied to this task, Ansible sets the value of x to foo - - - name: Print a variable - ansible.builtin.debug: - var: x - # no condition applied to this task, Ansible prints the debug statement - -By using ``include_tasks`` instead of ``import_tasks``, both tasks from ``other_tasks.yml`` will be executed as expected. For more information on the differences between ``include`` v ``import`` see :ref:`playbooks_reuse`. - -Conditionals with roles -^^^^^^^^^^^^^^^^^^^^^^^ - -There are three ways to apply conditions to roles: - - - Add the same condition or conditions to all tasks in the role by placing your ``when`` statement under the ``roles`` keyword. See the example in this section. - - Add the same condition or conditions to all tasks in the role by placing your ``when`` statement on a static ``import_role`` in your playbook. - - Add a condition or conditions to individual tasks or blocks within the role itself. This is the only approach that allows you to select or skip some tasks within the role based on your ``when`` statement. To select or skip tasks within the role, you must have conditions set on individual tasks or blocks, use the dynamic ``include_role`` in your playbook, and add the condition or conditions to the include. When you use this approach, Ansible applies the condition to the include itself plus any tasks in the role that also have that ``when`` statement. - -When you incorporate a role in your playbook statically with the ``roles`` keyword, Ansible adds the conditions you define to all the tasks in the role. For example: - -.. code-block:: yaml - - - hosts: webservers - roles: - - role: debian_stock_config - when: ansible_facts['os_family'] == 'Debian' - -.. _conditional_variable_and_files: - -Selecting variables, files, or templates based on facts -------------------------------------------------------- - -Sometimes the facts about a host determine the values you want to use for certain variables or even the file or template you want to select for that host. For example, the names of packages are different on CentOS and on Debian. The configuration files for common services are also different on different OS flavors and versions. To load different variables file, templates, or other files based on a fact about the hosts: - - 1) name your vars files, templates, or files to match the Ansible fact that differentiates them - - 2) select the correct vars file, template, or file for each host with a variable based on that Ansible fact - -Ansible separates variables from tasks, keeping your playbooks from turning into arbitrary code with nested conditionals. This approach results in more streamlined and auditable configuration rules because there are fewer decision points to track. - -Selecting variables files based on facts -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can create a playbook that works on multiple platforms and OS versions with a minimum of syntax by placing your variable values in vars files and conditionally importing them. If you want to install Apache on some CentOS and some Debian servers, create variables files with YAML keys and values. For example: - -.. code-block:: yaml - - --- - # for vars/RedHat.yml - apache: httpd - somethingelse: 42 - -Then import those variables files based on the facts you gather on the hosts in your playbook: - -.. code-block:: yaml - - --- - - hosts: webservers - remote_user: root - vars_files: - - "vars/common.yml" - - [ "vars/{{ ansible_facts['os_family'] }}.yml", "vars/os_defaults.yml" ] - tasks: - - name: Make sure apache is started - ansible.builtin.service: - name: '{{ apache }}' - state: started - -Ansible gathers facts on the hosts in the webservers group, then interpolates the variable "ansible_facts['os_family']" into a list of filenames. If you have hosts with Red Hat operating systems (CentOS, for example), Ansible looks for 'vars/RedHat.yml'. If that file does not exist, Ansible attempts to load 'vars/os_defaults.yml'. For Debian hosts, Ansible first looks for 'vars/Debian.yml', before falling back on 'vars/os_defaults.yml'. If no files in the list are found, Ansible raises an error. - -Selecting files and templates based on facts -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can use the same approach when different OS flavors or versions require different configuration files or templates. Select the appropriate file or template based on the variables assigned to each host. This approach is often much cleaner than putting a lot of conditionals into a single template to cover multiple OS or package versions. - -For example, you can template out a configuration file that is very different between, say, CentOS and Debian: - -.. code-block:: yaml - - - name: Template a file - ansible.builtin.template: - src: "{{ item }}" - dest: /etc/myapp/foo.conf - loop: "{{ query('first_found', { 'files': myfiles, 'paths': mypaths}) }}" - vars: - myfiles: - - "{{ ansible_facts['distribution'] }}.conf" - - default.conf - mypaths: ['search_location_one/somedir/', '/opt/other_location/somedir/'] - -.. _debugging_conditionals: - -Debugging conditionals -====================== - -If your conditional ``when`` statement is not behaving as you intended, you can add a ``debug`` statement to determine if the condition evaluates to ``true`` or ``false``. A common cause of unexpected behavior in conditionals is testing an integer as a string or a string as an integer. To debug a conditional statement, add the entire statement as the ``var:`` value in a ``debug`` task. Ansible then shows the test and how the statement evaluates. For example, here is a set of tasks and sample output: - -.. code-block:: yaml - - - name: check value of return code - ansible.builtin.debug: - var: bar_status.rc - - - name: check test for rc value as string - ansible.builtin.debug: - var: bar_status.rc == "127" - - - name: check test for rc value as integer - ansible.builtin.debug: - var: bar_status.rc == 127 - -.. code-block:: ansible-output - - TASK [check value of return code] ********************************************************************************* - ok: [foo-1] => { - "bar_status.rc": "127" - } - - TASK [check test for rc value as string] ************************************************************************** - ok: [foo-1] => { - "bar_status.rc == \"127\"": false - } - - TASK [check test for rc value as integer] ************************************************************************* - ok: [foo-1] => { - "bar_status.rc == 127": true - } - -.. _commonly_used_facts: - -Commonly-used facts -=================== - -The following Ansible facts are frequently used in conditionals. - -.. _ansible_distribution: - -ansible_facts['distribution'] ------------------------------ - -Possible values (sample, not complete list): - -.. code-block:: text - - Alpine - Altlinux - Amazon - Archlinux - ClearLinux - Coreos - CentOS - Debian - Fedora - Gentoo - Mandriva - NA - OpenWrt - OracleLinux - RedHat - Slackware - SLES - SMGL - SUSE - Ubuntu - VMwareESX - -.. See `OSDIST_LIST` - -.. _ansible_distribution_major_version: - -ansible_facts['distribution_major_version'] -------------------------------------------- - -The major version of the operating system. For example, the value is `16` for Ubuntu 16.04. - -.. _ansible_os_family: - -ansible_facts['os_family'] --------------------------- - -Possible values (sample, not complete list): - -.. code-block:: text - - AIX - Alpine - Altlinux - Archlinux - Darwin - Debian - FreeBSD - Gentoo - HP-UX - Mandrake - RedHat - SMGL - Slackware - Solaris - Suse - Windows - -.. Ansible checks `OS_FAMILY_MAP`; if there's no match, it returns the value of `platform.system()`. - -.. seealso:: - - :ref:`working_with_playbooks` - An introduction to playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - :ref:`tips_and_tricks` - Tips and tricks for playbooks - :ref:`playbooks_variables` - All about variables - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_debugger.rst b/docs/docsite/rst/playbook_guide/playbooks_debugger.rst deleted file mode 100644 index 79d7c31ee09..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_debugger.rst +++ /dev/null @@ -1,342 +0,0 @@ -.. _playbook_debugger: - -*************** -Debugging tasks -*************** - -Ansible offers a task debugger so you can fix errors during execution instead of editing your playbook and running it again to see if your change worked. You have access to all of the features of the debugger in the context of the task. You can check or set the value of variables, update module arguments, and re-run the task with the new variables and arguments. The debugger lets you resolve the cause of the failure and continue with playbook execution. - -.. contents:: - :local: - -Enabling the debugger -===================== - -The debugger is not enabled by default. If you want to invoke the debugger during playbook execution, you must enable it first. - -Use one of these three methods to enable the debugger: - - * with the debugger keyword - * in configuration or an environment variable, or - * as a strategy - -Enabling the debugger with the ``debugger`` keyword ---------------------------------------------------- - -.. versionadded:: 2.5 - -You can use the ``debugger`` keyword to enable (or disable) the debugger for a specific play, role, block, or task. This option is especially useful when developing or extending playbooks, plays, and roles. You can enable the debugger on new or updated tasks. If they fail, you can fix the errors efficiently. The ``debugger`` keyword accepts five values: - -.. table:: - :class: documentation-table - - ========================= ====================================================== - Value Result - ========================= ====================================================== - always Always invoke the debugger, regardless of the outcome - - never Never invoke the debugger, regardless of the outcome - - on_failed Only invoke the debugger if a task fails - - on_unreachable Only invoke the debugger if a host is unreachable - - on_skipped Only invoke the debugger if the task is skipped - - ========================= ====================================================== - -When you use the ``debugger`` keyword, the value you specify overrides any global configuration to enable or disable the debugger. If you define ``debugger`` at multiple levels, such as in a role and in a task, Ansible honors the most granular definition. The definition at the play or role level applies to all blocks and tasks within that play or role, unless they specify a different value. The definition at the block level overrides the definition at the play or role level, and applies to all tasks within that block, unless they specify a different value. The definition at the task level always applies to the task; it overrides the definitions at the block, play, or role level. - -Examples of using the ``debugger`` keyword -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Example of setting the ``debugger`` keyword on a task: - -.. code-block:: yaml - - - name: Execute a command - ansible.builtin.command: "false" - debugger: on_failed - -Example of setting the ``debugger`` keyword on a play: - -.. code-block:: yaml - - - name: My play - hosts: all - debugger: on_skipped - tasks: - - name: Execute a command - ansible.builtin.command: "true" - when: False - -Example of setting the ``debugger`` keyword at multiple levels: - -.. code-block:: yaml - - - name: Play - hosts: all - debugger: never - tasks: - - name: Execute a command - ansible.builtin.command: "false" - debugger: on_failed - -In this example, the debugger is set to ``never`` at the play level and to ``on_failed`` at the task level. If the task fails, Ansible invokes the debugger, because the definition on the task overrides the definition on its parent play. - -Enabling the debugger in configuration or an environment variable ------------------------------------------------------------------ - -.. versionadded:: 2.5 - -You can enable the task debugger globally with a setting in ansible.cfg or with an environment variable. The only options are ``True`` or ``False``. If you set the configuration option or environment variable to ``True``, Ansible runs the debugger on failed tasks by default. - -To enable the task debugger from ansible.cfg, add this setting to the defaults section: - -.. code-block:: yaml - - [defaults] - enable_task_debugger = True - -To enable the task debugger with an environment variable, pass the variable when you run your playbook: - -.. code-block:: shell - - ANSIBLE_ENABLE_TASK_DEBUGGER=True ansible-playbook -i hosts site.yml - -When you enable the debugger globally, every failed task invokes the debugger, unless the role, play, block, or task explicitly disables the debugger. If you need more granular control over what conditions trigger the debugger, use the ``debugger`` keyword. - -Enabling the debugger as a strategy ------------------------------------ - -If you are running legacy playbooks or roles, you may see the debugger enabled as a :ref:`strategy `. You can do this at the play level, in ansible.cfg, or with the environment variable ``ANSIBLE_STRATEGY=debug``. For example: - -.. code-block:: yaml - - - hosts: test - strategy: debug - tasks: - ... - -Or in ansible.cfg: - -.. code-block:: ini - - [defaults] - strategy = debug - -.. note:: - - This backwards-compatible method, which matches Ansible versions before 2.5, may be removed in a future release. - -Resolving errors in the debugger -================================ - -After Ansible invokes the debugger, you can use the seven :ref:`debugger commands ` to resolve the error that Ansible encountered. Consider this example playbook, which defines the ``var1`` variable but uses the undefined ``wrong_var`` variable in a task by mistake. - -.. code-block:: yaml - - - hosts: test - debugger: on_failed - gather_facts: false - vars: - var1: value1 - tasks: - - name: Use a wrong variable - ansible.builtin.ping: data={{ wrong_var }} - -If you run this playbook, Ansible invokes the debugger when the task fails. From the debug prompt, you can change the module arguments or the variables and run the task again. - -.. code-block:: ansible-output - - PLAY *************************************************************************** - - TASK [wrong variable] ********************************************************** - fatal: [192.0.2.10]: FAILED! => {"failed": true, "msg": "ERROR! 'wrong_var' is undefined"} - Debugger invoked - [192.0.2.10] TASK: wrong variable (debug)> p result._result - {'failed': True, - 'msg': 'The task includes an option with an undefined variable. The error ' - "was: 'wrong_var' is undefined\n" - '\n' - 'The error appears to have been in ' - "'playbooks/debugger.yml': line 7, " - 'column 7, but may\n' - 'be elsewhere in the file depending on the exact syntax problem.\n' - '\n' - 'The offending line appears to be:\n' - '\n' - ' tasks:\n' - ' - name: wrong variable\n' - ' ^ here\n'} - [192.0.2.10] TASK: wrong variable (debug)> p task.args - {u'data': u'{{ wrong_var }}'} - [192.0.2.10] TASK: wrong variable (debug)> task.args['data'] = '{{ var1 }}' - [192.0.2.10] TASK: wrong variable (debug)> p task.args - {u'data': '{{ var1 }}'} - [192.0.2.10] TASK: wrong variable (debug)> redo - ok: [192.0.2.10] - - PLAY RECAP ********************************************************************* - 192.0.2.10 : ok=1 changed=0 unreachable=0 failed=0 - -Changing the task arguments in the debugger to use ``var1`` instead of ``wrong_var`` makes the task run successfully. - -.. _available_commands: - -Available debug commands -======================== - -You can use these seven commands at the debug prompt: - -.. table:: - :class: documentation-table - - ========================== ============ ========================================================= - Command Shortcut Action - ========================== ============ ========================================================= - print p Print information about the task - - task.args[*key*] = *value* no shortcut Update module arguments - - task_vars[*key*] = *value* no shortcut Update task variables (you must ``update_task`` next) - - update_task u Recreate a task with updated task variables - - redo r Run the task again - - continue c Continue executing, starting with the next task - - quit q Quit the debugger - - ========================== ============ ========================================================= - -For more details, see the individual descriptions and examples below. - -.. _pprint_command: - -Print command -------------- - -``print *task/task.args/task_vars/host/result*`` prints information about the task. - -.. code-block:: ansible-output - - [192.0.2.10] TASK: install package (debug)> p task - TASK: install package - [192.0.2.10] TASK: install package (debug)> p task.args - {u'name': u'{{ pkg_name }}'} - [192.0.2.10] TASK: install package (debug)> p task_vars - {u'ansible_all_ipv4_addresses': [u'192.0.2.10'], - u'ansible_architecture': u'x86_64', - ... - } - [192.0.2.10] TASK: install package (debug)> p task_vars['pkg_name'] - u'bash' - [192.0.2.10] TASK: install package (debug)> p host - 192.0.2.10 - [192.0.2.10] TASK: install package (debug)> p result._result - {'_ansible_no_log': False, - 'changed': False, - u'failed': True, - ... - u'msg': u"No package matching 'not_exist' is available"} - -.. _update_args_command: - -Update args command -------------------- - -``task.args[*key*] = *value*`` updates a module argument. This sample playbook has an invalid package name. - -.. code-block:: yaml - - - hosts: test - strategy: debug - gather_facts: true - vars: - pkg_name: not_exist - tasks: - - name: Install a package - ansible.builtin.apt: name={{ pkg_name }} - -When you run the playbook, the invalid package name triggers an error, and Ansible invokes the debugger. You can fix the package name by viewing, then updating the module argument. - -.. code-block:: ansible-output - - [192.0.2.10] TASK: install package (debug)> p task.args - {u'name': u'{{ pkg_name }}'} - [192.0.2.10] TASK: install package (debug)> task.args['name'] = 'bash' - [192.0.2.10] TASK: install package (debug)> p task.args - {u'name': 'bash'} - [192.0.2.10] TASK: install package (debug)> redo - -After you update the module argument, use ``redo`` to run the task again with the new args. - -.. _update_vars_command: - -Update vars command -------------------- - -``task_vars[*key*] = *value*`` updates the ``task_vars``. You could fix the playbook above by viewing, then updating the task variables instead of the module args. - -.. code-block:: ansible-output - - [192.0.2.10] TASK: install package (debug)> p task_vars['pkg_name'] - u'not_exist' - [192.0.2.10] TASK: install package (debug)> task_vars['pkg_name'] = 'bash' - [192.0.2.10] TASK: install package (debug)> p task_vars['pkg_name'] - 'bash' - [192.0.2.10] TASK: install package (debug)> update_task - [192.0.2.10] TASK: install package (debug)> redo - -After you update the task variables, you must use ``update_task`` to load the new variables before using ``redo`` to run the task again. - -.. note:: - In 2.5 this was updated from ``vars`` to ``task_vars`` to avoid conflicts with the ``vars()`` python function. - -.. _update_task_command: - -Update task command -------------------- - -.. versionadded:: 2.8 - -``u`` or ``update_task`` recreates the task from the original task data structure and templates with updated task variables. See the entry :ref:`update_vars_command` for an example of use. - -.. _redo_command: - -Redo command ------------- - -``r`` or ``redo`` runs the task again. - -.. _continue_command: - -Continue command ----------------- - -``c`` or ``continue`` continues executing, starting with the next task. - -.. _quit_command: - -Quit command ------------- - -``q`` or ``quit`` quits the debugger. The playbook execution is aborted. - -How the debugger interacts with the free strategy -================================================= - -With the default ``linear`` strategy enabled, Ansible halts execution while the debugger is active, and runs the debugged task immediately after you enter the ``redo`` command. With the ``free`` strategy enabled, however, Ansible does not wait for all hosts, and may queue later tasks on one host before a task fails on another host. With the ``free`` strategy, Ansible does not queue or execute any tasks while the debugger is active. However, all queued tasks remain in the queue and run as soon as you exit the debugger. If you use ``redo`` to reschedule a task from the debugger, other queued tasks may execute before your rescheduled task. For more information about strategies, see :ref:`playbooks_strategies`. - -.. seealso:: - - :ref:`playbooks_start_and_step` - Running playbooks while debugging or testing - :ref:`playbooks_intro` - An introduction to playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_delegation.rst b/docs/docsite/rst/playbook_guide/playbooks_delegation.rst deleted file mode 100644 index faf7c5b14ce..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_delegation.rst +++ /dev/null @@ -1,174 +0,0 @@ -.. _playbooks_delegation: - -Controlling where tasks run: delegation and local actions -========================================================= - -By default Ansible gathers facts and executes all tasks on the machines that match the ``hosts`` line of your playbook. This page shows you how to delegate tasks to a different machine or group, delegate facts to specific machines or groups, or run an entire playbook locally. Using these approaches, you can manage inter-related environments precisely and efficiently. For example, when updating your webservers, you might need to remove them from a load-balanced pool temporarily. You cannot perform this task on the webservers themselves. By delegating the task to localhost, you keep all the tasks within the same play. - -.. contents:: - :local: - -Tasks that cannot be delegated ------------------------------- - -Some tasks always execute on the controller. These tasks, including ``include``, ``add_host``, and ``debug``, cannot be delegated. - -.. _delegation: - -Delegating tasks ----------------- - -If you want to perform a task on one host with reference to other hosts, use the ``delegate_to`` keyword on a task. This is ideal for managing nodes in a load balanced pool or for controlling outage windows. You can use delegation with the :ref:`serial ` keyword to control the number of hosts executing at one time: - -.. code-block:: yaml - - --- - - hosts: webservers - serial: 5 - - tasks: - - name: Take out of load balancer pool - ansible.builtin.command: /usr/bin/take_out_of_pool {{ inventory_hostname }} - delegate_to: 127.0.0.1 - - - name: Actual steps would go here - ansible.builtin.yum: - name: acme-web-stack - state: latest - - - name: Add back to load balancer pool - ansible.builtin.command: /usr/bin/add_back_to_pool {{ inventory_hostname }} - delegate_to: 127.0.0.1 - -The first and third tasks in this play run on 127.0.0.1, which is the machine running Ansible. There is also a shorthand syntax that you can use on a per-task basis: ``local_action``. Here is the same playbook as above, but using the shorthand syntax for delegating to 127.0.0.1: - -.. code-block:: yaml - - --- - # ... - - tasks: - - name: Take out of load balancer pool - local_action: ansible.builtin.command /usr/bin/take_out_of_pool {{ inventory_hostname }} - - # ... - - - name: Add back to load balancer pool - local_action: ansible.builtin.command /usr/bin/add_back_to_pool {{ inventory_hostname }} - -You can use a local action to call 'rsync' to recursively copy files to the managed servers: - -.. code-block:: yaml - - --- - # ... - - tasks: - - name: Recursively copy files from management server to target - local_action: ansible.builtin.command rsync -a /path/to/files {{ inventory_hostname }}:/path/to/target/ - -Note that you must have passphrase-less SSH keys or an ssh-agent configured for this to work, otherwise rsync asks for a passphrase. - -To specify more arguments, use the following syntax: - -.. code-block:: yaml - - --- - # ... - - tasks: - - name: Send summary mail - local_action: - module: community.general.mail - subject: "Summary Mail" - to: "{{ mail_recipient }}" - body: "{{ mail_body }}" - run_once: True - -.. note:: - - The `ansible_host` variable and other connection variables, if present, reflects information about the host a task is delegated to, not the inventory_hostname. - -.. warning:: - - Although you can ``delegate_to`` a host that does not exist in inventory (by adding IP address, DNS name or whatever requirement the connection plugin has), doing so does not add the host to your inventory and might cause issues. Hosts delegated to in this way do not inherit variables from the "all" group', so variables like connection user and key are missing. If you must ``delegate_to`` a non-inventory host, use the :ref:`add host module `. - - -.. _delegate_parallel: - -Delegation and parallel execution ---------------------------------- -By default Ansible tasks are executed in parallel. Delegating a task does not change this and does not handle concurrency issues (multiple forks writing to the same file). -Most commonly, users are affected by this when updating a single file on a single delegated to host for all hosts (using the ``copy``, ``template``, or ``lineinfile`` modules, for example). They will still operate in parallel forks (default 5) and overwrite each other. - -This can be handled in several ways: - -.. code-block:: yaml - - - name: "handle concurrency with a loop on the hosts with `run_once: true`" - lineinfile: "" - run_once: true - loop: '{{ ansible_play_hosts_all }}' - -By using an intermediate play with `serial: 1` or using `throttle: 1` at task level, for more detail see :ref:`playbooks_strategies` - -.. _delegate_facts: - -Delegating facts ----------------- - -Delegating Ansible tasks is like delegating tasks in the real world - your groceries belong to you, even if someone else delivers them to your home. Similarly, any facts gathered by a delegated task are assigned by default to the `inventory_hostname` (the current host), not to the host which produced the facts (the delegated to host). To assign gathered facts to the delegated host instead of the current host, set ``delegate_facts`` to ``true``: - -.. code-block:: yaml - - --- - - hosts: app_servers - - tasks: - - name: Gather facts from db servers - ansible.builtin.setup: - delegate_to: "{{ item }}" - delegate_facts: true - loop: "{{ groups['dbservers'] }}" - -This task gathers facts for the machines in the dbservers group and assigns the facts to those machines, even though the play targets the app_servers group. This way you can lookup `hostvars['dbhost1']['ansible_default_ipv4']['address']` even though dbservers were not part of the play, or left out by using `--limit`. - -.. _local_playbooks: - -Local playbooks ---------------- - -It may be useful to use a playbook locally on a remote host, rather than by connecting over SSH. This can be useful for assuring the configuration of a system by putting a playbook in a crontab. This may also be used -to run a playbook inside an OS installer, such as an Anaconda kickstart. - -To run an entire playbook locally, just set the ``hosts:`` line to ``hosts: 127.0.0.1`` and then run the playbook like so: - -.. code-block:: shell - - ansible-playbook playbook.yml --connection=local - -Alternatively, a local connection can be used in a single playbook play, even if other plays in the playbook -use the default remote connection type: - -.. code-block:: yaml - - --- - - hosts: 127.0.0.1 - connection: local - -.. note:: - If you set the connection to local and there is no ansible_python_interpreter set, modules will run under /usr/bin/python and not - under {{ ansible_playbook_python }}. Be sure to set ansible_python_interpreter: "{{ ansible_playbook_python }}" in - host_vars/localhost.yml, for example. You can avoid this issue by using ``local_action`` or ``delegate_to: localhost`` instead. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_strategies` - More ways to control how and where Ansible executes - `Ansible Examples on GitHub `_ - Many examples of full-stack deployments - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_environment.rst b/docs/docsite/rst/playbook_guide/playbooks_environment.rst deleted file mode 100644 index d347812b9c2..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_environment.rst +++ /dev/null @@ -1,153 +0,0 @@ -.. _playbooks_environment: - -Setting the remote environment -============================== - -.. versionadded:: 1.1 - -You can use the ``environment`` keyword at the play, block, or task level to set an environment variable for an action on a remote host. With this keyword, you can enable using a proxy for a task that does http requests, set the required environment variables for language-specific version managers, and more. - -When you set a value with ``environment:`` at the play or block level, it is available only to tasks within the play or block that are executed by the same user. The ``environment:`` keyword does not affect Ansible itself, Ansible configuration settings, the environment for other users, or the execution of other plugins like lookups and filters. Variables set with ``environment:`` do not automatically become Ansible facts, even when you set them at the play level. You must include an explicit ``gather_facts`` task in your playbook and set the ``environment`` keyword on that task to turn these values into Ansible facts. - -.. contents:: - :local: - -Setting the remote environment in a task ----------------------------------------- - -You can set the environment directly at the task level. - -.. code-block:: yaml - - - hosts: all - remote_user: root - - tasks: - - - name: Install cobbler - ansible.builtin.package: - name: cobbler - state: present - environment: - http_proxy: http://proxy.example.com:8080 - -You can re-use environment settings by defining them as variables in your play and accessing them in a task as you would access any stored Ansible variable. - -.. code-block:: yaml - - - hosts: all - remote_user: root - - # create a variable named "proxy_env" that is a dictionary - vars: - proxy_env: - http_proxy: http://proxy.example.com:8080 - - tasks: - - - name: Install cobbler - ansible.builtin.package: - name: cobbler - state: present - environment: "{{ proxy_env }}" - -You can store environment settings for re-use in multiple playbooks by defining them in a group_vars file. - -.. code-block:: yaml - - --- - # file: group_vars/boston - - ntp_server: ntp.bos.example.com - backup: bak.bos.example.com - proxy_env: - http_proxy: http://proxy.bos.example.com:8080 - https_proxy: http://proxy.bos.example.com:8080 - -You can set the remote environment at the play level. - -.. code-block:: yaml - - - hosts: testing - - roles: - - php - - nginx - - environment: - http_proxy: http://proxy.example.com:8080 - -These examples show proxy settings, but you can provide any number of settings this way. - -Working with language-specific version managers -=============================================== - -Some language-specific version managers (such as rbenv and nvm) require you to set environment variables while these tools are in use. When using these tools manually, you usually source some environment variables from a script or from lines added to your shell configuration file. In Ansible, you can do this with the environment keyword at the play level. - -.. code-block:: yaml+jinja - - --- - ### A playbook demonstrating a common npm workflow: - # - Check for package.json in the application directory - # - If package.json exists: - # * Run npm prune - # * Run npm install - - - hosts: application - become: false - - vars: - node_app_dir: /var/local/my_node_app - - environment: - NVM_DIR: /var/local/nvm - PATH: /var/local/nvm/versions/node/v4.2.1/bin:{{ ansible_env.PATH }} - - tasks: - - name: Check for package.json - ansible.builtin.stat: - path: '{{ node_app_dir }}/package.json' - register: packagejson - - - name: Run npm prune - ansible.builtin.command: npm prune - args: - chdir: '{{ node_app_dir }}' - when: packagejson.stat.exists - - - name: Run npm install - community.general.npm: - path: '{{ node_app_dir }}' - when: packagejson.stat.exists - -.. note:: - The example above uses ``ansible_env`` as part of the PATH. Basing variables on ``ansible_env`` is risky. Ansible populates ``ansible_env`` values by gathering facts, so the value of the variables depends on the remote_user or become_user Ansible used when gathering those facts. If you change remote_user/become_user the values in ``ansible_env`` may not be the ones you expect. - -.. warning:: - Environment variables are normally passed in clear text (shell plugin dependent) so they are not a recommended way of passing secrets to the module being executed. - -You can also specify the environment at the task level. - -.. code-block:: yaml+jinja - - --- - - name: Install ruby 2.3.1 - ansible.builtin.command: rbenv install {{ rbenv_ruby_version }} - args: - creates: '{{ rbenv_root }}/versions/{{ rbenv_ruby_version }}/bin/ruby' - vars: - rbenv_root: /usr/local/rbenv - rbenv_ruby_version: 2.3.1 - environment: - CONFIGURE_OPTS: '--disable-install-doc' - RBENV_ROOT: '{{ rbenv_root }}' - PATH: '{{ rbenv_root }}/bin:{{ rbenv_root }}/shims:{{ rbenv_plugins }}/ruby-build/bin:{{ ansible_env.PATH }}' - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_error_handling.rst b/docs/docsite/rst/playbook_guide/playbooks_error_handling.rst deleted file mode 100644 index d94fc1ef46c..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_error_handling.rst +++ /dev/null @@ -1,279 +0,0 @@ -.. _playbooks_error_handling: - -*************************** -Error handling in playbooks -*************************** - -When Ansible receives a non-zero return code from a command or a failure from a module, by default it stops executing on that host and continues on other hosts. However, in some circumstances you may want different behavior. Sometimes a non-zero return code indicates success. Sometimes you want a failure on one host to stop execution on all hosts. Ansible provides tools and settings to handle these situations and help you get the behavior, output, and reporting you want. - -.. contents:: - :local: - -.. _ignoring_failed_commands: - -Ignoring failed commands -======================== - -By default Ansible stops executing tasks on a host when a task fails on that host. You can use ``ignore_errors`` to continue on in spite of the failure. - -.. code-block:: yaml - - - name: Do not count this as a failure - ansible.builtin.command: /bin/false - ignore_errors: true - -The ``ignore_errors`` directive only works when the task is able to run and returns a value of 'failed'. It does not make Ansible ignore undefined variable errors, connection failures, execution issues (for example, missing packages), or syntax errors. - -.. _ignore_unreachable: - -Ignoring unreachable host errors -================================ - -.. versionadded:: 2.7 - -You can ignore a task failure due to the host instance being 'UNREACHABLE' with the ``ignore_unreachable`` keyword. Ansible ignores the task errors, but continues to execute future tasks against the unreachable host. For example, at the task level: - -.. code-block:: yaml - - - name: This executes, fails, and the failure is ignored - ansible.builtin.command: /bin/true - ignore_unreachable: true - - - name: This executes, fails, and ends the play for this host - ansible.builtin.command: /bin/true - -And at the playbook level: - -.. code-block:: yaml - - - hosts: all - ignore_unreachable: true - tasks: - - name: This executes, fails, and the failure is ignored - ansible.builtin.command: /bin/true - - - name: This executes, fails, and ends the play for this host - ansible.builtin.command: /bin/true - ignore_unreachable: false - -.. _resetting_unreachable: - -Resetting unreachable hosts -=========================== - -If Ansible cannot connect to a host, it marks that host as 'UNREACHABLE' and removes it from the list of active hosts for the run. You can use `meta: clear_host_errors` to reactivate all hosts, so subsequent tasks can try to reach them again. - - -.. _handlers_and_failure: - -Handlers and failure -==================== - -Ansible runs :ref:`handlers ` at the end of each play. If a task notifies a handler but -another task fails later in the play, by default the handler does *not* run on that host, -which may leave the host in an unexpected state. For example, a task could update -a configuration file and notify a handler to restart some service. If a -task later in the same play fails, the configuration file might be changed but -the service will not be restarted. - -You can change this behavior with the ``--force-handlers`` command-line option, -by including ``force_handlers: True`` in a play, or by adding ``force_handlers = True`` -to ansible.cfg. When handlers are forced, Ansible will run all notified handlers on -all hosts, even hosts with failed tasks. (Note that certain errors could still prevent -the handler from running, such as a host becoming unreachable.) - -.. _controlling_what_defines_failure: - -Defining failure -================ - -Ansible lets you define what "failure" means in each task using the ``failed_when`` conditional. As with all conditionals in Ansible, lists of multiple ``failed_when`` conditions are joined with an implicit ``and``, meaning the task only fails when *all* conditions are met. If you want to trigger a failure when any of the conditions is met, you must define the conditions in a string with an explicit ``or`` operator. - -You may check for failure by searching for a word or phrase in the output of a command - -.. code-block:: yaml - - - name: Fail task when the command error output prints FAILED - ansible.builtin.command: /usr/bin/example-command -x -y -z - register: command_result - failed_when: "'FAILED' in command_result.stderr" - -or based on the return code - -.. code-block:: yaml - - - name: Fail task when both files are identical - ansible.builtin.raw: diff foo/file1 bar/file2 - register: diff_cmd - failed_when: diff_cmd.rc == 0 or diff_cmd.rc >= 2 - -You can also combine multiple conditions for failure. This task will fail if both conditions are true: - -.. code-block:: yaml - - - name: Check if a file exists in temp and fail task if it does - ansible.builtin.command: ls /tmp/this_should_not_be_here - register: result - failed_when: - - result.rc == 0 - - '"No such" not in result.stdout' - -If you want the task to fail when only one condition is satisfied, change the ``failed_when`` definition to - -.. code-block:: yaml - - failed_when: result.rc == 0 or "No such" not in result.stdout - -If you have too many conditions to fit neatly into one line, you can split it into a multi-line YAML value with ``>``. - -.. code-block:: yaml - - - name: example of many failed_when conditions with OR - ansible.builtin.shell: "./myBinary" - register: ret - failed_when: > - ("No such file or directory" in ret.stdout) or - (ret.stderr != '') or - (ret.rc == 10) - -.. _override_the_changed_result: - -Defining "changed" -================== - -Ansible lets you define when a particular task has "changed" a remote node using the ``changed_when`` conditional. This lets you determine, based on return codes or output, whether a change should be reported in Ansible statistics and whether a handler should be triggered or not. As with all conditionals in Ansible, lists of multiple ``changed_when`` conditions are joined with an implicit ``and``, meaning the task only reports a change when *all* conditions are met. If you want to report a change when any of the conditions is met, you must define the conditions in a string with an explicit ``or`` operator. For example: - -.. code-block:: yaml - - tasks: - - - name: Report 'changed' when the return code is not equal to 2 - ansible.builtin.shell: /usr/bin/billybass --mode="take me to the river" - register: bass_result - changed_when: "bass_result.rc != 2" - - - name: This will never report 'changed' status - ansible.builtin.shell: wall 'beep' - changed_when: False - -You can also combine multiple conditions to override "changed" result. - -.. code-block:: yaml - - - name: Combine multiple conditions to override 'changed' result - ansible.builtin.command: /bin/fake_command - register: result - ignore_errors: True - changed_when: - - '"ERROR" in result.stderr' - - result.rc == 2 - -.. note:: - - Just like ``when`` these two conditionals do not require templating delimiters (``{{ }}``) as they are implied. - -See :ref:`controlling_what_defines_failure` for more conditional syntax examples. - -Ensuring success for command and shell -====================================== - -The :ref:`command ` and :ref:`shell ` modules care about return codes, so if you have a command whose successful exit code is not zero, you can do this: - -.. code-block:: yaml - - tasks: - - name: Run this command and ignore the result - ansible.builtin.shell: /usr/bin/somecommand || /bin/true - - -Aborting a play on all hosts -============================ - -Sometimes you want a failure on a single host, or failures on a certain percentage of hosts, to abort the entire play on all hosts. You can stop play execution after the first failure happens with ``any_errors_fatal``. For finer-grained control, you can use ``max_fail_percentage`` to abort the run after a given percentage of hosts has failed. - -Aborting on the first error: any_errors_fatal ---------------------------------------------- - -If you set ``any_errors_fatal`` and a task returns an error, Ansible finishes the fatal task on all hosts in the current batch, then stops executing the play on all hosts. Subsequent tasks and plays are not executed. You can recover from fatal errors by adding a :ref:`rescue section ` to the block. You can set ``any_errors_fatal`` at the play or block level. - -.. code-block:: yaml - - - hosts: somehosts - any_errors_fatal: true - roles: - - myrole - - - hosts: somehosts - tasks: - - block: - - include_tasks: mytasks.yml - any_errors_fatal: true - -You can use this feature when all tasks must be 100% successful to continue playbook execution. For example, if you run a service on machines in multiple data centers with load balancers to pass traffic from users to the service, you want all load balancers to be disabled before you stop the service for maintenance. To ensure that any failure in the task that disables the load balancers will stop all other tasks: - -.. code-block:: yaml - - --- - - hosts: load_balancers_dc_a - any_errors_fatal: true - - tasks: - - name: Shut down datacenter 'A' - ansible.builtin.command: /usr/bin/disable-dc - - - hosts: frontends_dc_a - - tasks: - - name: Stop service - ansible.builtin.command: /usr/bin/stop-software - - - name: Update software - ansible.builtin.command: /usr/bin/upgrade-software - - - hosts: load_balancers_dc_a - - tasks: - - name: Start datacenter 'A' - ansible.builtin.command: /usr/bin/enable-dc - -In this example Ansible starts the software upgrade on the front ends only if all of the load balancers are successfully disabled. - -.. _maximum_failure_percentage: - -Setting a maximum failure percentage ------------------------------------- - -By default, Ansible continues to execute tasks as long as there are hosts that have not yet failed. In some situations, such as when executing a rolling update, you may want to abort the play when a certain threshold of failures has been reached. To achieve this, you can set a maximum failure percentage on a play: - -.. code-block:: yaml - - --- - - hosts: webservers - max_fail_percentage: 30 - serial: 10 - -The ``max_fail_percentage`` setting applies to each batch when you use it with :ref:`serial `. In the example above, if more than 3 of the 10 servers in the first (or any) batch of servers failed, the rest of the play would be aborted. - -.. note:: - - The percentage set must be exceeded, not equaled. For example, if serial were set to 4 and you wanted the task to abort the play when 2 of the systems failed, set the max_fail_percentage at 49 rather than 50. - -Controlling errors in blocks -============================ - -You can also use blocks to define responses to task errors. This approach is similar to exception handling in many programming languages. See :ref:`block_error_handling` for details and examples. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`tips_and_tricks` - Tips and tricks for playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_variables` - All about variables - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_execution.rst b/docs/docsite/rst/playbook_guide/playbooks_execution.rst deleted file mode 100644 index b1377cd52ae..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_execution.rst +++ /dev/null @@ -1,22 +0,0 @@ -.. _executing_playbooks: - -Executing playbooks -=================== - -Ready to run your Ansible playbook? - -Running complex playbooks requires some trial and error so learn about some of the abilities that Ansible gives you to ensure successful execution. -You can validate your tasks with "dry run" playbooks, use the start-at-task and step mode options to efficiently troubleshoot playbooks. -You can also use Ansible debugger to correct tasks during execution. -Ansible also offers flexibility with asynchronous playbook execution and tags that let you run specific parts of your playbook. - -.. toctree:: - :maxdepth: 2 - - playbooks_checkmode - playbooks_privilege_escalation - playbooks_tags - playbooks_startnstep - playbooks_debugger - playbooks_async - playbooks_strategies \ No newline at end of file diff --git a/docs/docsite/rst/playbook_guide/playbooks_filters.rst b/docs/docsite/rst/playbook_guide/playbooks_filters.rst deleted file mode 100644 index 52fb861ac12..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_filters.rst +++ /dev/null @@ -1,2203 +0,0 @@ -.. _playbooks_filters: - -******************************** -Using filters to manipulate data -******************************** - -Filters let you transform JSON data into YAML data, split a URL to extract the hostname, get the SHA1 hash of a string, add or multiply integers, and much more. You can use the Ansible-specific filters documented here to manipulate your data, or use any of the standard filters shipped with Jinja2 - see the list of :ref:`built-in filters ` in the official Jinja2 template documentation. You can also use :ref:`Python methods ` to transform data. You can :ref:`create custom Ansible filters as plugins `, though we generally welcome new filters into the ansible-core repo so everyone can use them. - -Because templating happens on the Ansible controller, **not** on the target host, filters execute on the controller and transform data locally. - -.. contents:: - :local: - -Handling undefined variables -============================ - -Filters can help you manage missing or undefined variables by providing defaults or making some variables optional. If you configure Ansible to ignore most undefined variables, you can mark some variables as requiring values with the ``mandatory`` filter. - -.. _defaulting_undefined_variables: - -Providing default values ------------------------- - -You can provide default values for variables directly in your templates using the Jinja2 'default' filter. This is often a better approach than failing if a variable is not defined: - -.. code-block:: yaml+jinja - - {{ some_variable | default(5) }} - -In the above example, if the variable 'some_variable' is not defined, Ansible uses the default value 5, rather than raising an "undefined variable" error and failing. If you are working within a role, you can also add a ``defaults/main.yml`` to define the default values for variables in your role. - -Beginning in version 2.8, attempting to access an attribute of an Undefined value in Jinja will return another Undefined value, rather than throwing an error immediately. This means that you can now simply use -a default with a value in a nested data structure (in other words, :code:`{{ foo.bar.baz | default('DEFAULT') }}`) when you do not know if the intermediate values are defined. - -If you want to use the default value when variables evaluate to false or an empty string you have to set the second parameter to ``true``: - -.. code-block:: yaml+jinja - - {{ lookup('env', 'MY_USER') | default('admin', true) }} - -.. _omitting_undefined_variables: - -Making variables optional -------------------------- - -By default Ansible requires values for all variables in a templated expression. However, you can make specific variables optional. For example, you might want to use a system default for some items and control the value for others. To make a variable optional, set the default value to the special variable ``omit``: - -.. code-block:: yaml+jinja - - - name: Touch files with an optional mode - ansible.builtin.file: - dest: "{{ item.path }}" - state: touch - mode: "{{ item.mode | default(omit) }}" - loop: - - path: /tmp/foo - - path: /tmp/bar - - path: /tmp/baz - mode: "0444" - -In this example, the default mode for the files ``/tmp/foo`` and ``/tmp/bar`` is determined by the umask of the system. Ansible does not send a value for ``mode``. Only the third file, ``/tmp/baz``, receives the `mode=0444` option. - -.. note:: If you are "chaining" additional filters after the ``default(omit)`` filter, you should instead do something like this: - ``"{{ foo | default(None) | some_filter or omit }}"``. In this example, the default ``None`` (Python null) value will cause the later filters to fail, which will trigger the ``or omit`` portion of the logic. Using ``omit`` in this manner is very specific to the later filters you are chaining though, so be prepared for some trial and error if you do this. - -.. _forcing_variables_to_be_defined: - -Defining mandatory values -------------------------- - -If you configure Ansible to ignore undefined variables, you may want to define some values as mandatory. By default, Ansible fails if a variable in your playbook or command is undefined. You can configure Ansible to allow undefined variables by setting :ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR` to ``false``. In that case, you may want to require some variables to be defined. You can do this with: - -.. code-block:: yaml+jinja - - {{ variable | mandatory }} - -The variable value will be used as is, but the template evaluation will raise an error if it is undefined. - -A convenient way of requiring a variable to be overridden is to give it an undefined value using the ``undef`` keyword. This can be useful in a role's defaults. - -.. code-block:: yaml+jinja - - galaxy_url: "https://galaxy.ansible.com" - galaxy_api_key: "{{ undef(hint='You must specify your Galaxy API key') }}" - -Defining different values for true/false/null (ternary) -======================================================= - -You can create a test, then define one value to use when the test returns true and another when the test returns false (new in version 1.9): - -.. code-block:: yaml+jinja - - {{ (status == 'needs_restart') | ternary('restart', 'continue') }} - -In addition, you can define a one value to use on true, one value on false and a third value on null (new in version 2.8): - -.. code-block:: yaml+jinja - - {{ enabled | ternary('no shutdown', 'shutdown', omit) }} - -Managing data types -=================== - -You might need to know, change, or set the data type on a variable. For example, a registered variable might contain a dictionary when your next task needs a list, or a user :ref:`prompt ` might return a string when your playbook needs a boolean value. Use the ``type_debug``, ``dict2items``, and ``items2dict`` filters to manage data types. You can also use the data type itself to cast a value as a specific data type. - -Discovering the data type -------------------------- - -.. versionadded:: 2.3 - -If you are unsure of the underlying Python type of a variable, you can use the ``type_debug`` filter to display it. This is useful in debugging when you need a particular type of variable: - -.. code-block:: yaml+jinja - - {{ myvar | type_debug }} - -You should note that, while this may seem like a useful filter for checking that you have the right type of data in a variable, you should often prefer :ref:`type tests `, which will allow you to test for specific data types. - -.. _dict_filter: - -Transforming dictionaries into lists ------------------------------------- - -.. versionadded:: 2.6 - - -Use the ``dict2items`` filter to transform a dictionary into a list of items suitable for :ref:`looping `: - -.. code-block:: yaml+jinja - - {{ dict | dict2items }} - -Dictionary data (before applying the ``dict2items`` filter): - -.. code-block:: yaml - - tags: - Application: payment - Environment: dev - -List data (after applying the ``dict2items`` filter): - -.. code-block:: yaml - - - key: Application - value: payment - - key: Environment - value: dev - -.. versionadded:: 2.8 - -The ``dict2items`` filter is the reverse of the ``items2dict`` filter. - -If you want to configure the names of the keys, the ``dict2items`` filter accepts 2 keyword arguments. Pass the ``key_name`` and ``value_name`` arguments to configure the names of the keys in the list output: - -.. code-block:: yaml+jinja - - {{ files | dict2items(key_name='file', value_name='path') }} - -Dictionary data (before applying the ``dict2items`` filter): - -.. code-block:: yaml - - files: - users: /etc/passwd - groups: /etc/group - -List data (after applying the ``dict2items`` filter): - -.. code-block:: yaml - - - file: users - path: /etc/passwd - - file: groups - path: /etc/group - - -Transforming lists into dictionaries ------------------------------------- - -.. versionadded:: 2.7 - -Use the ``items2dict`` filter to transform a list into a dictionary, mapping the content into ``key: value`` pairs: - -.. code-block:: yaml+jinja - - {{ tags | items2dict }} - -List data (before applying the ``items2dict`` filter): - -.. code-block:: yaml - - tags: - - key: Application - value: payment - - key: Environment - value: dev - -Dictionary data (after applying the ``items2dict`` filter): - -.. code-block:: text - - Application: payment - Environment: dev - -The ``items2dict`` filter is the reverse of the ``dict2items`` filter. - -Not all lists use ``key`` to designate keys and ``value`` to designate values. For example: - -.. code-block:: yaml - - fruits: - - fruit: apple - color: red - - fruit: pear - color: yellow - - fruit: grapefruit - color: yellow - -In this example, you must pass the ``key_name`` and ``value_name`` arguments to configure the transformation. For example: - -.. code-block:: yaml+jinja - - {{ tags | items2dict(key_name='fruit', value_name='color') }} - -If you do not pass these arguments, or do not pass the correct values for your list, you will see ``KeyError: key`` or ``KeyError: my_typo``. - -Forcing the data type ---------------------- - -You can cast values as certain types. For example, if you expect the input "True" from a :ref:`vars_prompt ` and you want Ansible to recognize it as a boolean value instead of a string: - -.. code-block:: yaml - - - ansible.builtin.debug: - msg: test - when: some_string_value | bool - -If you want to perform a mathematical comparison on a fact and you want Ansible to recognize it as an integer instead of a string: - -.. code-block:: yaml - - - shell: echo "only on Red Hat 6, derivatives, and later" - when: ansible_facts['os_family'] == "RedHat" and ansible_facts['lsb']['major_release'] | int >= 6 - - -.. versionadded:: 1.6 - -.. _filters_for_formatting_data: - -Formatting data: YAML and JSON -============================== - -You can switch a data structure in a template from or to JSON or YAML format, with options for formatting, indenting, and loading data. The basic filters are occasionally useful for debugging: - -.. code-block:: yaml+jinja - - {{ some_variable | to_json }} - {{ some_variable | to_yaml }} - -For human readable output, you can use: - -.. code-block:: yaml+jinja - - {{ some_variable | to_nice_json }} - {{ some_variable | to_nice_yaml }} - -You can change the indentation of either format: - -.. code-block:: yaml+jinja - - {{ some_variable | to_nice_json(indent=2) }} - {{ some_variable | to_nice_yaml(indent=8) }} - -The ``to_yaml`` and ``to_nice_yaml`` filters use the `PyYAML library`_ which has a default 80 symbol string length limit. That causes unexpected line break after 80th symbol (if there is a space after 80th symbol) -To avoid such behavior and generate long lines, use the ``width`` option. You must use a hardcoded number to define the width, instead of a construction like ``float("inf")``, because the filter does not support proxying Python functions. For example: - -.. code-block:: yaml+jinja - - {{ some_variable | to_yaml(indent=8, width=1337) }} - {{ some_variable | to_nice_yaml(indent=8, width=1337) }} - -The filter does support passing through other YAML parameters. For a full list, see the `PyYAML documentation`_ for ``dump()``. - -If you are reading in some already formatted data: - -.. code-block:: yaml+jinja - - {{ some_variable | from_json }} - {{ some_variable | from_yaml }} - -for example: - -.. code-block:: yaml+jinja - - tasks: - - name: Register JSON output as a variable - ansible.builtin.shell: cat /some/path/to/file.json - register: result - - - name: Set a variable - ansible.builtin.set_fact: - myvar: "{{ result.stdout | from_json }}" - - -Filter `to_json` and Unicode support ------------------------------------- - -By default `to_json` and `to_nice_json` will convert data received to ASCII, so: - -.. code-block:: yaml+jinja - - {{ 'München'| to_json }} - -will return: - -.. code-block:: text - - 'M\u00fcnchen' - -To keep Unicode characters, pass the parameter `ensure_ascii=False` to the filter: - -.. code-block:: yaml+jinja - - {{ 'München'| to_json(ensure_ascii=False) }} - - 'München' - -.. versionadded:: 2.7 - -To parse multi-document YAML strings, the ``from_yaml_all`` filter is provided. -The ``from_yaml_all`` filter will return a generator of parsed YAML documents. - -for example: - -.. code-block:: yaml+jinja - - tasks: - - name: Register a file content as a variable - ansible.builtin.shell: cat /some/path/to/multidoc-file.yaml - register: result - - - name: Print the transformed variable - ansible.builtin.debug: - msg: '{{ item }}' - loop: '{{ result.stdout | from_yaml_all | list }}' - -Combining and selecting data -============================ - -You can combine data from multiple sources and types, and select values from large data structures, giving you precise control over complex data. - -.. _zip_filter_example: - -Combining items from multiple lists: zip and zip_longest --------------------------------------------------------- - -.. versionadded:: 2.3 - -To get a list combining the elements of other lists use ``zip``: - -.. code-block:: yaml+jinja - - - name: Give me list combo of two lists - ansible.builtin.debug: - msg: "{{ [1,2,3,4,5,6] | zip(['a','b','c','d','e','f']) | list }}" - - # => [[1, "a"], [2, "b"], [3, "c"], [4, "d"], [5, "e"], [6, "f"]] - - - name: Give me shortest combo of two lists - ansible.builtin.debug: - msg: "{{ [1,2,3] | zip(['a','b','c','d','e','f']) | list }}" - - # => [[1, "a"], [2, "b"], [3, "c"]] - -To always exhaust all lists use ``zip_longest``: - -.. code-block:: yaml+jinja - - - name: Give me longest combo of three lists , fill with X - ansible.builtin.debug: - msg: "{{ [1,2,3] | zip_longest(['a','b','c','d','e','f'], [21, 22, 23], fillvalue='X') | list }}" - - # => [[1, "a", 21], [2, "b", 22], [3, "c", 23], ["X", "d", "X"], ["X", "e", "X"], ["X", "f", "X"]] - -Similarly to the output of the ``items2dict`` filter mentioned above, these filters can be used to construct a ``dict``: - -.. code-block:: yaml+jinja - - {{ dict(keys_list | zip(values_list)) }} - -List data (before applying the ``zip`` filter): - -.. code-block:: yaml - - keys_list: - - one - - two - values_list: - - apple - - orange - -Dictionary data (after applying the ``zip`` filter): - -.. code-block:: yaml - - one: apple - two: orange - -Combining objects and subelements ---------------------------------- - -.. versionadded:: 2.7 - -The ``subelements`` filter produces a product of an object and the subelement values of that object, similar to the ``subelements`` lookup. This lets you specify individual subelements to use in a template. For example, this expression: - -.. code-block:: yaml+jinja - - {{ users | subelements('groups', skip_missing=True) }} - -Data before applying the ``subelements`` filter: - -.. code-block:: yaml - - users: - - name: alice - authorized: - - /tmp/alice/onekey.pub - - /tmp/alice/twokey.pub - groups: - - wheel - - docker - - name: bob - authorized: - - /tmp/bob/id_rsa.pub - groups: - - docker - -Data after applying the ``subelements`` filter: - -.. code-block:: yaml - - - - - name: alice - groups: - - wheel - - docker - authorized: - - /tmp/alice/onekey.pub - - /tmp/alice/twokey.pub - - wheel - - - - name: alice - groups: - - wheel - - docker - authorized: - - /tmp/alice/onekey.pub - - /tmp/alice/twokey.pub - - docker - - - - name: bob - authorized: - - /tmp/bob/id_rsa.pub - groups: - - docker - - docker - -You can use the transformed data with ``loop`` to iterate over the same subelement for multiple objects: - -.. code-block:: yaml+jinja - - - name: Set authorized ssh key, extracting just that data from 'users' - ansible.posix.authorized_key: - user: "{{ item.0.name }}" - key: "{{ lookup('file', item.1) }}" - loop: "{{ users | subelements('authorized') }}" - -.. _combine_filter: - -Combining hashes/dictionaries ------------------------------ - -.. versionadded:: 2.0 - -The ``combine`` filter allows hashes to be merged. For example, the following would override keys in one hash: - -.. code-block:: yaml+jinja - - {{ {'a':1, 'b':2} | combine({'b':3}) }} - -The resulting hash would be: - -.. code-block:: text - - {'a':1, 'b':3} - -The filter can also take multiple arguments to merge: - -.. code-block:: yaml+jinja - - {{ a | combine(b, c, d) }} - {{ [a, b, c, d] | combine }} - -In this case, keys in ``d`` would override those in ``c``, which would override those in ``b``, and so on. - -The filter also accepts two optional parameters: ``recursive`` and ``list_merge``. - -recursive - Is a boolean, default to ``False``. - Should the ``combine`` recursively merge nested hashes. - Note: It does **not** depend on the value of the ``hash_behaviour`` setting in ``ansible.cfg``. - -list_merge - Is a string, its possible values are ``replace`` (default), ``keep``, ``append``, ``prepend``, ``append_rp`` or ``prepend_rp``. - It modifies the behaviour of ``combine`` when the hashes to merge contain arrays/lists. - -.. code-block:: yaml - - default: - a: - x: default - y: default - b: default - c: default - patch: - a: - y: patch - z: patch - b: patch - -If ``recursive=False`` (the default), nested hash aren't merged: - -.. code-block:: yaml+jinja - - {{ default | combine(patch) }} - -This would result in: - -.. code-block:: yaml - - a: - y: patch - z: patch - b: patch - c: default - -If ``recursive=True``, recurse into nested hash and merge their keys: - -.. code-block:: yaml+jinja - - {{ default | combine(patch, recursive=True) }} - -This would result in: - -.. code-block:: yaml - - a: - x: default - y: patch - z: patch - b: patch - c: default - -If ``list_merge='replace'`` (the default), arrays from the right hash will "replace" the ones in the left hash: - -.. code-block:: yaml - - default: - a: - - default - patch: - a: - - patch - -.. code-block:: yaml+jinja - - {{ default | combine(patch) }} - -This would result in: - -.. code-block:: yaml - - a: - - patch - -If ``list_merge='keep'``, arrays from the left hash will be kept: - -.. code-block:: yaml+jinja - - {{ default | combine(patch, list_merge='keep') }} - -This would result in: - -.. code-block:: yaml - - a: - - default - -If ``list_merge='append'``, arrays from the right hash will be appended to the ones in the left hash: - -.. code-block:: yaml+jinja - - {{ default | combine(patch, list_merge='append') }} - -This would result in: - -.. code-block:: yaml - - a: - - default - - patch - -If ``list_merge='prepend'``, arrays from the right hash will be prepended to the ones in the left hash: - -.. code-block:: yaml+jinja - - {{ default | combine(patch, list_merge='prepend') }} - -This would result in: - -.. code-block:: yaml - - a: - - patch - - default - -If ``list_merge='append_rp'``, arrays from the right hash will be appended to the ones in the left hash. Elements of arrays in the left hash that are also in the corresponding array of the right hash will be removed ("rp" stands for "remove present"). Duplicate elements that aren't in both hashes are kept: - -.. code-block:: yaml - - default: - a: - - 1 - - 1 - - 2 - - 3 - patch: - a: - - 3 - - 4 - - 5 - - 5 - -.. code-block:: yaml+jinja - - {{ default | combine(patch, list_merge='append_rp') }} - -This would result in: - -.. code-block:: yaml - - a: - - 1 - - 1 - - 2 - - 3 - - 4 - - 5 - - 5 - -If ``list_merge='prepend_rp'``, the behavior is similar to the one for ``append_rp``, but elements of arrays in the right hash are prepended: - -.. code-block:: yaml+jinja - - {{ default | combine(patch, list_merge='prepend_rp') }} - -This would result in: - -.. code-block:: yaml - - a: - - 3 - - 4 - - 5 - - 5 - - 1 - - 1 - - 2 - -``recursive`` and ``list_merge`` can be used together: - -.. code-block:: yaml - - default: - a: - a': - x: default_value - y: default_value - list: - - default_value - b: - - 1 - - 1 - - 2 - - 3 - patch: - a: - a': - y: patch_value - z: patch_value - list: - - patch_value - b: - - 3 - - 4 - - 4 - - key: value - -.. code-block:: yaml+jinja - - {{ default | combine(patch, recursive=True, list_merge='append_rp') }} - -This would result in: - -.. code-block:: yaml - - a: - a': - x: default_value - y: patch_value - z: patch_value - list: - - default_value - - patch_value - b: - - 1 - - 1 - - 2 - - 3 - - 4 - - 4 - - key: value - - -.. _extract_filter: - -Selecting values from arrays or hashtables -------------------------------------------- - -.. versionadded:: 2.1 - -The `extract` filter is used to map from a list of indices to a list of values from a container (hash or array): - -.. code-block:: yaml+jinja - - {{ [0,2] | map('extract', ['x','y','z']) | list }} - {{ ['x','y'] | map('extract', {'x': 42, 'y': 31}) | list }} - -The results of the above expressions would be: - -.. code-block:: none - - ['x', 'z'] - [42, 31] - -The filter can take another argument: - -.. code-block:: yaml+jinja - - {{ groups['x'] | map('extract', hostvars, 'ec2_ip_address') | list }} - -This takes the list of hosts in group 'x', looks them up in `hostvars`, and then looks up the `ec2_ip_address` of the result. The final result is a list of IP addresses for the hosts in group 'x'. - -The third argument to the filter can also be a list, for a recursive lookup inside the container: - -.. code-block:: yaml+jinja - - {{ ['a'] | map('extract', b, ['x','y']) | list }} - -This would return a list containing the value of `b['a']['x']['y']`. - -Combining lists ---------------- - -This set of filters returns a list of combined lists. - - -permutations -^^^^^^^^^^^^ -To get permutations of a list: - -.. code-block:: yaml+jinja - - - name: Give me largest permutations (order matters) - ansible.builtin.debug: - msg: "{{ [1,2,3,4,5] | ansible.builtin.permutations | list }}" - - - name: Give me permutations of sets of three - ansible.builtin.debug: - msg: "{{ [1,2,3,4,5] | ansible.builtin.permutations(3) | list }}" - -combinations -^^^^^^^^^^^^ -Combinations always require a set size: - -.. code-block:: yaml+jinja - - - name: Give me combinations for sets of two - ansible.builtin.debug: - msg: "{{ [1,2,3,4,5] | ansible.builtin.combinations(2) | list }}" - -Also see the :ref:`zip_filter` - -products -^^^^^^^^ -The product filter returns the `cartesian product `_ of the input iterables. This is roughly equivalent to nested for-loops in a generator expression. - -For example: - -.. code-block:: yaml+jinja - - - name: Generate multiple hostnames - ansible.builtin.debug: - msg: "{{ ['foo', 'bar'] | product(['com']) | map('join', '.') | join(',') }}" - -This would result in: - -.. code-block:: json - - { "msg": "foo.com,bar.com" } - -.. json_query_filter: - -Selecting JSON data: JSON queries ---------------------------------- - -To select a single element or a data subset from a complex data structure in JSON format (for example, Ansible facts), use the ``json_query`` filter. The ``json_query`` filter lets you query a complex JSON structure and iterate over it using a loop structure. - -.. note:: - - This filter has migrated to the `community.general `_ collection. Follow the installation instructions to install that collection. - - -.. note:: You must manually install the **jmespath** dependency on the Ansible controller before using this filter. This filter is built upon **jmespath**, and you can use the same syntax. For examples, see `jmespath examples `_. - -Consider this data structure: - -.. code-block:: json - - { - "domain_definition": { - "domain": { - "cluster": [ - { - "name": "cluster1" - }, - { - "name": "cluster2" - } - ], - "server": [ - { - "name": "server11", - "cluster": "cluster1", - "port": "8080" - }, - { - "name": "server12", - "cluster": "cluster1", - "port": "8090" - }, - { - "name": "server21", - "cluster": "cluster2", - "port": "9080" - }, - { - "name": "server22", - "cluster": "cluster2", - "port": "9090" - } - ], - "library": [ - { - "name": "lib1", - "target": "cluster1" - }, - { - "name": "lib2", - "target": "cluster2" - } - ] - } - } - } - -To extract all clusters from this structure, you can use the following query: - -.. code-block:: yaml+jinja - - - name: Display all cluster names - ansible.builtin.debug: - var: item - loop: "{{ domain_definition | community.general.json_query('domain.cluster[*].name') }}" - -To extract all server names: - -.. code-block:: yaml+jinja - - - name: Display all server names - ansible.builtin.debug: - var: item - loop: "{{ domain_definition | community.general.json_query('domain.server[*].name') }}" - -To extract ports from cluster1: - -.. code-block:: yaml+jinja - - - name: Display all ports from cluster1 - ansible.builtin.debug: - var: item - loop: "{{ domain_definition | community.general.json_query(server_name_cluster1_query) }}" - vars: - server_name_cluster1_query: "domain.server[?cluster=='cluster1'].port" - -.. note:: You can use a variable to make the query more readable. - -To print out the ports from cluster1 in a comma separated string: - -.. code-block:: yaml+jinja - - - name: Display all ports from cluster1 as a string - ansible.builtin.debug: - msg: "{{ domain_definition | community.general.json_query('domain.server[?cluster==`cluster1`].port') | join(', ') }}" - -.. note:: In the example above, quoting literals using backticks avoids escaping quotes and maintains readability. - -You can use YAML `single quote escaping `_: - -.. code-block:: yaml+jinja - - - name: Display all ports from cluster1 - ansible.builtin.debug: - var: item - loop: "{{ domain_definition | community.general.json_query('domain.server[?cluster==''cluster1''].port') }}" - -.. note:: Escaping single quotes within single quotes in YAML is done by doubling the single quote. - -To get a hash map with all ports and names of a cluster: - -.. code-block:: yaml+jinja - - - name: Display all server ports and names from cluster1 - ansible.builtin.debug: - var: item - loop: "{{ domain_definition | community.general.json_query(server_name_cluster1_query) }}" - vars: - server_name_cluster1_query: "domain.server[?cluster=='cluster2'].{name: name, port: port}" - -To extract ports from all clusters with name starting with 'server1': - -.. code-block:: yaml+jinja - - - name: Display all ports from cluster1 - ansible.builtin.debug: - msg: "{{ domain_definition | to_json | from_json | community.general.json_query(server_name_query) }}" - vars: - server_name_query: "domain.server[?starts_with(name,'server1')].port" - -To extract ports from all clusters with name containing 'server1': - -.. code-block:: yaml+jinja - - - name: Display all ports from cluster1 - ansible.builtin.debug: - msg: "{{ domain_definition | to_json | from_json | community.general.json_query(server_name_query) }}" - vars: - server_name_query: "domain.server[?contains(name,'server1')].port" - -.. note:: while using ``starts_with`` and ``contains``, you have to use `` to_json | from_json `` filter for correct parsing of data structure. - - -Randomizing data -================ - -When you need a randomly generated value, use one of these filters. - - -.. _random_mac_filter: - -Random MAC addresses --------------------- - -.. versionadded:: 2.6 - -This filter can be used to generate a random MAC address from a string prefix. - -.. note:: - - This filter has migrated to the `community.general `_ collection. Follow the installation instructions to install that collection. - -To get a random MAC address from a string prefix starting with '52:54:00': - -.. code-block:: yaml+jinja - - "{{ '52:54:00' | community.general.random_mac }}" - # => '52:54:00:ef:1c:03' - -Note that if anything is wrong with the prefix string, the filter will issue an error. - - .. versionadded:: 2.9 - -As of Ansible version 2.9, you can also initialize the random number generator from a seed to create random-but-idempotent MAC addresses: - -.. code-block:: yaml+jinja - - "{{ '52:54:00' | community.general.random_mac(seed=inventory_hostname) }}" - - -.. _random_filter_example: - -Random items or numbers ------------------------ - -The ``random`` filter in Ansible is an extension of the default Jinja2 random filter, and can be used to return a random item from a sequence of items or to generate a random number based on a range. - -To get a random item from a list: - -.. code-block:: yaml+jinja - - "{{ ['a','b','c'] | random }}" - # => 'c' - -To get a random number between 0 (inclusive) and a specified integer (exclusive): - -.. code-block:: yaml+jinja - - "{{ 60 | random }} * * * * root /script/from/cron" - # => '21 * * * * root /script/from/cron' - -To get a random number from 0 to 100 but in steps of 10: - -.. code-block:: yaml+jinja - - {{ 101 | random(step=10) }} - # => 70 - -To get a random number from 1 to 100 but in steps of 10: - -.. code-block:: yaml+jinja - - {{ 101 | random(1, 10) }} - # => 31 - {{ 101 | random(start=1, step=10) }} - # => 51 - -You can initialize the random number generator from a seed to create random-but-idempotent numbers: - -.. code-block:: yaml+jinja - - "{{ 60 | random(seed=inventory_hostname) }} * * * * root /script/from/cron" - -Shuffling a list ----------------- - -The ``shuffle`` filter randomizes an existing list, giving a different order every invocation. - -To get a random list from an existing list: - -.. code-block:: yaml+jinja - - {{ ['a','b','c'] | shuffle }} - # => ['c','a','b'] - {{ ['a','b','c'] | shuffle }} - # => ['b','c','a'] - -You can initialize the shuffle generator from a seed to generate a random-but-idempotent order: - -.. code-block:: yaml+jinja - - {{ ['a','b','c'] | shuffle(seed=inventory_hostname) }} - # => ['b','a','c'] - -The shuffle filter returns a list whenever possible. If you use it with a non 'listable' item, the filter does nothing. - - -.. _list_filters: - -Managing list variables -======================= - -You can search for the minimum or maximum value in a list, or flatten a multi-level list. - -To get the minimum value from list of numbers: - -.. code-block:: yaml+jinja - - {{ list1 | min }} - -.. versionadded:: 2.11 - -To get the minimum value in a list of objects: - -.. code-block:: yaml+jinja - - {{ [{'val': 1}, {'val': 2}] | min(attribute='val') }} - -To get the maximum value from a list of numbers: - -.. code-block:: yaml+jinja - - {{ [3, 4, 2] | max }} - -.. versionadded:: 2.11 - -To get the maximum value in a list of objects: - -.. code-block:: yaml+jinja - - {{ [{'val': 1}, {'val': 2}] | max(attribute='val') }} - -.. versionadded:: 2.5 - -Flatten a list (same thing the `flatten` lookup does): - -.. code-block:: yaml+jinja - - {{ [3, [4, 2] ] | flatten }} - # => [3, 4, 2] - -Flatten only the first level of a list (akin to the `items` lookup): - -.. code-block:: yaml+jinja - - {{ [3, [4, [2]] ] | flatten(levels=1) }} - # => [3, 4, [2]] - - -.. versionadded:: 2.11 - -Preserve nulls in a list, by default flatten removes them. : - -.. code-block:: yaml+jinja - - {{ [3, None, [4, [2]] ] | flatten(levels=1, skip_nulls=False) }} - # => [3, None, 4, [2]] - - -.. _set_theory_filters: - -Selecting from sets or lists (set theory) -========================================= - -You can select or combine items from sets or lists. - -.. versionadded:: 1.4 - -To get a unique set from a list: - -.. code-block:: yaml+jinja - - # list1: [1, 2, 5, 1, 3, 4, 10] - {{ list1 | unique }} - # => [1, 2, 5, 3, 4, 10] - -To get a union of two lists: - -.. code-block:: yaml+jinja - - # list1: [1, 2, 5, 1, 3, 4, 10] - # list2: [1, 2, 3, 4, 5, 11, 99] - {{ list1 | union(list2) }} - # => [1, 2, 5, 1, 3, 4, 10, 11, 99] - -To get the intersection of 2 lists (unique list of all items in both): - -.. code-block:: yaml+jinja - - # list1: [1, 2, 5, 3, 4, 10] - # list2: [1, 2, 3, 4, 5, 11, 99] - {{ list1 | intersect(list2) }} - # => [1, 2, 5, 3, 4] - -To get the difference of 2 lists (items in 1 that don't exist in 2): - -.. code-block:: yaml+jinja - - # list1: [1, 2, 5, 1, 3, 4, 10] - # list2: [1, 2, 3, 4, 5, 11, 99] - {{ list1 | difference(list2) }} - # => [10] - -To get the symmetric difference of 2 lists (items exclusive to each list): - -.. code-block:: yaml+jinja - - # list1: [1, 2, 5, 1, 3, 4, 10] - # list2: [1, 2, 3, 4, 5, 11, 99] - {{ list1 | symmetric_difference(list2) }} - # => [10, 11, 99] - -.. _math_stuff: - -Calculating numbers (math) -========================== - -.. versionadded:: 1.9 - -You can calculate logs, powers, and roots of numbers with Ansible filters. Jinja2 provides other mathematical functions like abs() and round(). - -Get the logarithm (default is e): - -.. code-block:: yaml+jinja - - {{ 8 | log }} - # => 2.0794415416798357 - -Get the base 10 logarithm: - -.. code-block:: yaml+jinja - - {{ 8 | log(10) }} - # => 0.9030899869919435 - -Give me the power of 2! (or 5): - -.. code-block:: yaml+jinja - - {{ 8 | pow(5) }} - # => 32768.0 - -Square root, or the 5th: - -.. code-block:: yaml+jinja - - {{ 8 | root }} - # => 2.8284271247461903 - - {{ 8 | root(5) }} - # => 1.5157165665103982 - - -Managing network interactions -============================= - -These filters help you with common network tasks. - -.. note:: - - These filters have migrated to the `ansible.netcommon `_ collection. Follow the installation instructions to install that collection. - -.. _ipaddr_filter: - -IP address filters ------------------- - -.. versionadded:: 1.9 - -To test if a string is a valid IP address: - -.. code-block:: yaml+jinja - - {{ myvar | ansible.netcommon.ipaddr }} - -You can also require a specific IP protocol version: - -.. code-block:: yaml+jinja - - {{ myvar | ansible.netcommon.ipv4 }} - {{ myvar | ansible.netcommon.ipv6 }} - -IP address filter can also be used to extract specific information from an IP -address. For example, to get the IP address itself from a CIDR, you can use: - -.. code-block:: yaml+jinja - - {{ '192.0.2.1/24' | ansible.netcommon.ipaddr('address') }} - # => 192.0.2.1 - -More information about ``ipaddr`` filter and complete usage guide can be found -in :ref:`playbooks_filters_ipaddr`. - -.. _network_filters: - -Network CLI filters -------------------- - -.. versionadded:: 2.4 - -To convert the output of a network device CLI command into structured JSON -output, use the ``parse_cli`` filter: - -.. code-block:: yaml+jinja - - {{ output | ansible.netcommon.parse_cli('path/to/spec') }} - -The ``parse_cli`` filter will load the spec file and pass the command output -through it, returning JSON output. The YAML spec file defines how to parse the CLI output. - -The spec file should be valid formatted YAML. It defines how to parse the CLI -output and return JSON data. Below is an example of a valid spec file that -will parse the output from the ``show vlan`` command. - -.. code-block:: yaml - - --- - vars: - vlan: - vlan_id: "{{ item.vlan_id }}" - name: "{{ item.name }}" - enabled: "{{ item.state != 'act/lshut' }}" - state: "{{ item.state }}" - - keys: - vlans: - value: "{{ vlan }}" - items: "^(?P\\d+)\\s+(?P\\w+)\\s+(?Pactive|act/lshut|suspended)" - state_static: - value: present - - -The spec file above will return a JSON data structure that is a list of hashes -with the parsed VLAN information. - -The same command could be parsed into a hash by using the key and values -directives. Here is an example of how to parse the output into a hash -value using the same ``show vlan`` command. - -.. code-block:: yaml - - --- - vars: - vlan: - key: "{{ item.vlan_id }}" - values: - vlan_id: "{{ item.vlan_id }}" - name: "{{ item.name }}" - enabled: "{{ item.state != 'act/lshut' }}" - state: "{{ item.state }}" - - keys: - vlans: - value: "{{ vlan }}" - items: "^(?P\\d+)\\s+(?P\\w+)\\s+(?Pactive|act/lshut|suspended)" - state_static: - value: present - -Another common use case for parsing CLI commands is to break a large command -into blocks that can be parsed. This can be done using the ``start_block`` and -``end_block`` directives to break the command into blocks that can be parsed. - -.. code-block:: yaml - - --- - vars: - interface: - name: "{{ item[0].match[0] }}" - state: "{{ item[1].state }}" - mode: "{{ item[2].match[0] }}" - - keys: - interfaces: - value: "{{ interface }}" - start_block: "^Ethernet.*$" - end_block: "^$" - items: - - "^(?PEthernet\\d\\/\\d*)" - - "admin state is (?P.+)," - - "Port mode is (.+)" - - -The example above will parse the output of ``show interface`` into a list of -hashes. - -The network filters also support parsing the output of a CLI command using the -TextFSM library. To parse the CLI output with TextFSM use the following -filter: - -.. code-block:: yaml+jinja - - {{ output.stdout[0] | ansible.netcommon.parse_cli_textfsm('path/to/fsm') }} - -Use of the TextFSM filter requires the TextFSM library to be installed. - -Network XML filters -------------------- - -.. versionadded:: 2.5 - -To convert the XML output of a network device command into structured JSON -output, use the ``parse_xml`` filter: - -.. code-block:: yaml+jinja - - {{ output | ansible.netcommon.parse_xml('path/to/spec') }} - -The ``parse_xml`` filter will load the spec file and pass the command output -through formatted as JSON. - -The spec file should be valid formatted YAML. It defines how to parse the XML -output and return JSON data. - -Below is an example of a valid spec file that -will parse the output from the ``show vlan | display xml`` command. - -.. code-block:: yaml - - --- - vars: - vlan: - vlan_id: "{{ item.vlan_id }}" - name: "{{ item.name }}" - desc: "{{ item.desc }}" - enabled: "{{ item.state.get('inactive') != 'inactive' }}" - state: "{% if item.state.get('inactive') == 'inactive'%} inactive {% else %} active {% endif %}" - - keys: - vlans: - value: "{{ vlan }}" - top: configuration/vlans/vlan - items: - vlan_id: vlan-id - name: name - desc: description - state: ".[@inactive='inactive']" - - -The spec file above will return a JSON data structure that is a list of hashes -with the parsed VLAN information. - -The same command could be parsed into a hash by using the key and values -directives. Here is an example of how to parse the output into a hash -value using the same ``show vlan | display xml`` command. - -.. code-block:: yaml - - --- - vars: - vlan: - key: "{{ item.vlan_id }}" - values: - vlan_id: "{{ item.vlan_id }}" - name: "{{ item.name }}" - desc: "{{ item.desc }}" - enabled: "{{ item.state.get('inactive') != 'inactive' }}" - state: "{% if item.state.get('inactive') == 'inactive'%} inactive {% else %} active {% endif %}" - - keys: - vlans: - value: "{{ vlan }}" - top: configuration/vlans/vlan - items: - vlan_id: vlan-id - name: name - desc: description - state: ".[@inactive='inactive']" - - -The value of ``top`` is the XPath relative to the XML root node. -In the example XML output given below, the value of ``top`` is ``configuration/vlans/vlan``, -which is an XPath expression relative to the root node (). -``configuration`` in the value of ``top`` is the outer most container node, and ``vlan`` -is the inner-most container node. - -``items`` is a dictionary of key-value pairs that map user-defined names to XPath expressions -that select elements. The Xpath expression is relative to the value of the XPath value contained in ``top``. -For example, the ``vlan_id`` in the spec file is a user defined name and its value ``vlan-id`` is the -relative to the value of XPath in ``top`` - -Attributes of XML tags can be extracted using XPath expressions. The value of ``state`` in the spec -is an XPath expression used to get the attributes of the ``vlan`` tag in output XML.: - -.. code-block:: none - - - - - - vlan-1 - 200 - This is vlan-1 - - - - - -.. note:: - For more information on supported XPath expressions, see `XPath Support `_. - -Network VLAN filters --------------------- - -.. versionadded:: 2.8 - -Use the ``vlan_parser`` filter to transform an unsorted list of VLAN integers into a -sorted string list of integers according to IOS-like VLAN list rules. This list has the following properties: - -* Vlans are listed in ascending order. -* Three or more consecutive VLANs are listed with a dash. -* The first line of the list can be first_line_len characters long. -* Subsequent list lines can be other_line_len characters. - -To sort a VLAN list: - -.. code-block:: yaml+jinja - - {{ [3003, 3004, 3005, 100, 1688, 3002, 3999] | ansible.netcommon.vlan_parser }} - -This example renders the following sorted list: - -.. code-block:: text - - ['100,1688,3002-3005,3999'] - - -Another example Jinja template: - -.. code-block:: yaml+jinja - - {% set parsed_vlans = vlans | ansible.netcommon.vlan_parser %} - switchport trunk allowed vlan {{ parsed_vlans[0] }} - {% for i in range (1, parsed_vlans | count) %} - switchport trunk allowed vlan add {{ parsed_vlans[i] }} - {% endfor %} - -This allows for dynamic generation of VLAN lists on a Cisco IOS tagged interface. You can store an exhaustive raw list of the exact VLANs required for an interface and then compare that to the parsed IOS output that would actually be generated for the configuration. - - -.. _hash_filters: - -Hashing and encrypting strings and passwords -============================================== - -.. versionadded:: 1.9 - -To get the sha1 hash of a string: - -.. code-block:: yaml+jinja - - {{ 'test1' | hash('sha1') }} - # => "b444ac06613fc8d63795be9ad0beaf55011936ac" - -To get the md5 hash of a string: - -.. code-block:: yaml+jinja - - {{ 'test1' | hash('md5') }} - # => "5a105e8b9d40e1329780d62ea2265d8a" - -Get a string checksum: - -.. code-block:: yaml+jinja - - {{ 'test2' | checksum }} - # => "109f4b3c50d7b0df729d299bc6f8e9ef9066971f" - -Other hashes (platform dependent): - -.. code-block:: yaml+jinja - - {{ 'test2' | hash('blowfish') }} - -To get a sha512 password hash (random salt): - -.. code-block:: yaml+jinja - - {{ 'passwordsaresecret' | password_hash('sha512') }} - # => "$6$UIv3676O/ilZzWEE$ktEfFF19NQPF2zyxqxGkAceTnbEgpEKuGBtk6MlU4v2ZorWaVQUMyurgmHCh2Fr4wpmQ/Y.AlXMJkRnIS4RfH/" - -To get a sha256 password hash with a specific salt: - -.. code-block:: yaml+jinja - - {{ 'secretpassword' | password_hash('sha256', 'mysecretsalt') }} - # => "$5$mysecretsalt$ReKNyDYjkKNqRVwouShhsEqZ3VOE8eoVO4exihOfvG4" - -An idempotent method to generate unique hashes per system is to use a salt that is consistent between runs: - -.. code-block:: yaml+jinja - - {{ 'secretpassword' | password_hash('sha512', 65534 | random(seed=inventory_hostname) | string) }} - # => "$6$43927$lQxPKz2M2X.NWO.gK.t7phLwOKQMcSq72XxDZQ0XzYV6DlL1OD72h417aj16OnHTGxNzhftXJQBcjbunLEepM0" - -Hash types available depend on the control system running Ansible, 'hash' depends on `hashlib `_, password_hash depends on `passlib `_. The `crypt `_ is used as a fallback if ``passlib`` is not installed. - -.. versionadded:: 2.7 - -Some hash types allow providing a rounds parameter: - -.. code-block:: yaml+jinja - - {{ 'secretpassword' | password_hash('sha256', 'mysecretsalt', rounds=10000) }} - # => "$5$rounds=10000$mysecretsalt$Tkm80llAxD4YHll6AgNIztKn0vzAACsuuEfYeGP7tm7" - -The filter `password_hash` produces different results depending on whether you installed `passlib` or not. - -To ensure idempotency, specify `rounds` to be neither `crypt`'s nor `passlib`'s default, which is `5000` for `crypt` and a variable value (`535000` for sha256, `656000` for sha512) for `passlib`: - -.. code-block:: yaml+jinja - - {{ 'secretpassword' | password_hash('sha256', 'mysecretsalt', rounds=5001) }} - # => "$5$rounds=5001$mysecretsalt$wXcTWWXbfcR8er5IVf7NuquLvnUA6s8/qdtOhAZ.xN." - -Hash type 'blowfish' (BCrypt) provides the facility to specify the version of the BCrypt algorithm. - -.. code-block:: yaml+jinja - - {{ 'secretpassword' | password_hash('blowfish', '1234567890123456789012', ident='2b') }} - # => "$2b$12$123456789012345678901uuJ4qFdej6xnWjOQT.FStqfdoY8dYUPC" - -.. note:: - The parameter is only available for `blowfish (BCrypt) `_. - Other hash types will simply ignore this parameter. - Valid values for this parameter are: ['2', '2a', '2y', '2b'] - -.. versionadded:: 2.12 - -You can also use the Ansible :ref:`vault ` filter to encrypt data: - -.. code-block:: yaml+jinja - - # simply encrypt my key in a vault - vars: - myvaultedkey: "{{ keyrawdata|vault(passphrase) }}" - - - name: save templated vaulted data - template: src=dump_template_data.j2 dest=/some/key/vault.txt - vars: - mysalt: '{{ 2**256|random(seed=inventory_hostname) }}' - template_data: '{{ secretdata|vault(vaultsecret, salt=mysalt) }}' - - -And then decrypt it using the unvault filter: - -.. code-block:: yaml+jinja - - # simply decrypt my key from a vault - vars: - mykey: "{{ myvaultedkey|unvault(passphrase) }}" - - - name: save templated unvaulted data - template: src=dump_template_data.j2 dest=/some/key/clear.txt - vars: - template_data: '{{ secretdata|unvault(vaultsecret) }}' - - -.. _other_useful_filters: - -Manipulating text -================= - -Several filters work with text, including URLs, file names, and path names. - -.. _comment_filter: - -Adding comments to files ------------------------- - -The ``comment`` filter lets you create comments in a file from text in a template, with a variety of comment styles. By default Ansible uses ``#`` to start a comment line and adds a blank comment line above and below your comment text. For example the following: - -.. code-block:: yaml+jinja - - {{ "Plain style (default)" | comment }} - -produces this output: - -.. code-block:: text - - # - # Plain style (default) - # - -Ansible offers styles for comments in C (``//...``), C block -(``/*...*/``), Erlang (``%...``) and XML (````): - -.. code-block:: yaml+jinja - - {{ "C style" | comment('c') }} - {{ "C block style" | comment('cblock') }} - {{ "Erlang style" | comment('erlang') }} - {{ "XML style" | comment('xml') }} - -You can define a custom comment character. This filter: - -.. code-block:: yaml+jinja - - {{ "My Special Case" | comment(decoration="! ") }} - -produces: - -.. code-block:: text - - ! - ! My Special Case - ! - -You can fully customize the comment style: - -.. code-block:: yaml+jinja - - {{ "Custom style" | comment('plain', prefix='#######\n#', postfix='#\n#######\n ###\n #') }} - -That creates the following output: - -.. code-block:: text - - ####### - # - # Custom style - # - ####### - ### - # - -The filter can also be applied to any Ansible variable. For example to -make the output of the ``ansible_managed`` variable more readable, we can -change the definition in the ``ansible.cfg`` file to this: - -.. code-block:: ini - - [defaults] - - ansible_managed = This file is managed by Ansible.%n - template: {file} - date: %Y-%m-%d %H:%M:%S - user: {uid} - host: {host} - -and then use the variable with the `comment` filter: - -.. code-block:: yaml+jinja - - {{ ansible_managed | comment }} - -which produces this output: - -.. code-block:: sh - - # - # This file is managed by Ansible. - # - # template: /home/ansible/env/dev/ansible_managed/roles/role1/templates/test.j2 - # date: 2015-09-10 11:02:58 - # user: ansible - # host: myhost - # - -URLEncode Variables -------------------- - -The ``urlencode`` filter quotes data for use in a URL path or query using UTF-8: - -.. code-block:: yaml+jinja - - {{ 'Trollhättan' | urlencode }} - # => 'Trollh%C3%A4ttan' - -Splitting URLs --------------- - -.. versionadded:: 2.4 - -The ``urlsplit`` filter extracts the fragment, hostname, netloc, password, path, port, query, scheme, and username from an URL. With no arguments, returns a dictionary of all the fields: - -.. code-block:: yaml+jinja - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('hostname') }} - # => 'www.acme.com' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('netloc') }} - # => 'user:password@www.acme.com:9000' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('username') }} - # => 'user' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('password') }} - # => 'password' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('path') }} - # => '/dir/index.html' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('port') }} - # => '9000' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('scheme') }} - # => 'http' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('query') }} - # => 'query=term' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('fragment') }} - # => 'fragment' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit }} - # => - # { - # "fragment": "fragment", - # "hostname": "www.acme.com", - # "netloc": "user:password@www.acme.com:9000", - # "password": "password", - # "path": "/dir/index.html", - # "port": 9000, - # "query": "query=term", - # "scheme": "http", - # "username": "user" - # } - -Searching strings with regular expressions ------------------------------------------- - -To search in a string or extract parts of a string with a regular expression, use the ``regex_search`` filter: - -.. code-block:: yaml+jinja - - # Extracts the database name from a string - {{ 'server1/database42' | regex_search('database[0-9]+') }} - # => 'database42' - - # Example for a case insensitive search in multiline mode - {{ 'foo\nBAR' | regex_search('^bar', multiline=True, ignorecase=True) }} - # => 'BAR' - - # Extracts server and database id from a string - {{ 'server1/database42' | regex_search('server([0-9]+)/database([0-9]+)', '\\1', '\\2') }} - # => ['1', '42'] - - # Extracts dividend and divisor from a division - {{ '21/42' | regex_search('(?P[0-9]+)/(?P[0-9]+)', '\\g', '\\g') }} - # => ['21', '42'] - -The ``regex_search`` filter returns an empty string if it cannot find a match: - -.. code-block:: yaml+jinja - - {{ 'ansible' | regex_search('foobar') }} - # => '' - - -.. note:: - - - The ``regex_search`` filter returns ``None`` when used in a Jinja expression (for example in conjunction with operators, other filters, and so on). See the two examples below. - - .. code-block:: Jinja - - {{ 'ansible' | regex_search('foobar') == '' }} - # => False - {{ 'ansible' | regex_search('foobar') is none }} - # => True - - This is due to historic behavior and the custom re-implementation of some of the Jinja internals in Ansible. Enable the ``jinja2_native`` setting if you want the ``regex_search`` filter to always return ``None`` if it cannot find a match. See :ref:`jinja2_faqs` for details. - -To extract all occurrences of regex matches in a string, use the ``regex_findall`` filter: - -.. code-block:: yaml+jinja - - # Returns a list of all IPv4 addresses in the string - {{ 'Some DNS servers are 8.8.8.8 and 8.8.4.4' | regex_findall('\\b(?:[0-9]{1,3}\\.){3}[0-9]{1,3}\\b') }} - # => ['8.8.8.8', '8.8.4.4'] - - # Returns all lines that end with "ar" - {{ 'CAR\ntar\nfoo\nbar\n' | regex_findall('^.ar$', multiline=True, ignorecase=True) }} - # => ['CAR', 'tar', 'bar'] - - -To replace text in a string with regex, use the ``regex_replace`` filter: - -.. code-block:: yaml+jinja - - # Convert "ansible" to "able" - {{ 'ansible' | regex_replace('^a.*i(.*)$', 'a\\1') }} - # => 'able' - - # Convert "foobar" to "bar" - {{ 'foobar' | regex_replace('^f.*o(.*)$', '\\1') }} - # => 'bar' - - # Convert "localhost:80" to "localhost, 80" using named groups - {{ 'localhost:80' | regex_replace('^(?P.+):(?P\\d+)$', '\\g, \\g') }} - # => 'localhost, 80' - - # Convert "localhost:80" to "localhost" - {{ 'localhost:80' | regex_replace(':80') }} - # => 'localhost' - - # Comment all lines that end with "ar" - {{ 'CAR\ntar\nfoo\nbar\n' | regex_replace('^(.ar)$', '#\\1', multiline=True, ignorecase=True) }} - # => '#CAR\n#tar\nfoo\n#bar\n' - -.. note:: - If you want to match the whole string and you are using ``*`` make sure to always wraparound your regular expression with the start/end anchors. For example ``^(.*)$`` will always match only one result, while ``(.*)`` on some Python versions will match the whole string and an empty string at the end, which means it will make two replacements: - -.. code-block:: yaml+jinja - - # add "https://" prefix to each item in a list - GOOD: - {{ hosts | map('regex_replace', '^(.*)$', 'https://\\1') | list }} - {{ hosts | map('regex_replace', '(.+)', 'https://\\1') | list }} - {{ hosts | map('regex_replace', '^', 'https://') | list }} - - BAD: - {{ hosts | map('regex_replace', '(.*)', 'https://\\1') | list }} - - # append ':80' to each item in a list - GOOD: - {{ hosts | map('regex_replace', '^(.*)$', '\\1:80') | list }} - {{ hosts | map('regex_replace', '(.+)', '\\1:80') | list }} - {{ hosts | map('regex_replace', '$', ':80') | list }} - - BAD: - {{ hosts | map('regex_replace', '(.*)', '\\1:80') | list }} - -.. note:: - Prior to ansible 2.0, if ``regex_replace`` filter was used with variables inside YAML arguments (as opposed to simpler 'key=value' arguments), then you needed to escape backreferences (for example, ``\\1``) with 4 backslashes (``\\\\``) instead of 2 (``\\``). - -.. versionadded:: 2.0 - -To escape special characters within a standard Python regex, use the ``regex_escape`` filter (using the default ``re_type='python'`` option): - -.. code-block:: yaml+jinja - - # convert '^f.*o(.*)$' to '\^f\.\*o\(\.\*\)\$' - {{ '^f.*o(.*)$' | regex_escape() }} - -.. versionadded:: 2.8 - -To escape special characters within a POSIX basic regex, use the ``regex_escape`` filter with the ``re_type='posix_basic'`` option: - -.. code-block:: yaml+jinja - - # convert '^f.*o(.*)$' to '\^f\.\*o(\.\*)\$' - {{ '^f.*o(.*)$' | regex_escape('posix_basic') }} - - -Managing file names and path names ----------------------------------- - -To get the last name of a file path, like 'foo.txt' out of '/etc/asdf/foo.txt': - -.. code-block:: yaml+jinja - - {{ path | basename }} - -To get the last name of a windows style file path (new in version 2.0): - -.. code-block:: yaml+jinja - - {{ path | win_basename }} - -To separate the windows drive letter from the rest of a file path (new in version 2.0): - -.. code-block:: yaml+jinja - - {{ path | win_splitdrive }} - -To get only the windows drive letter: - -.. code-block:: yaml+jinja - - {{ path | win_splitdrive | first }} - -To get the rest of the path without the drive letter: - -.. code-block:: yaml+jinja - - {{ path | win_splitdrive | last }} - -To get the directory from a path: - -.. code-block:: yaml+jinja - - {{ path | dirname }} - -To get the directory from a windows path (new version 2.0): - -.. code-block:: yaml+jinja - - {{ path | win_dirname }} - -To expand a path containing a tilde (`~`) character (new in version 1.5): - -.. code-block:: yaml+jinja - - {{ path | expanduser }} - -To expand a path containing environment variables: - -.. code-block:: yaml+jinja - - {{ path | expandvars }} - -.. note:: `expandvars` expands local variables; using it on remote paths can lead to errors. - -.. versionadded:: 2.6 - -To get the real path of a link (new in version 1.8): - -.. code-block:: yaml+jinja - - {{ path | realpath }} - -To get the relative path of a link, from a start point (new in version 1.7): - -.. code-block:: yaml+jinja - - {{ path | relpath('/etc') }} - -To get the root and extension of a path or file name (new in version 2.0): - -.. code-block:: yaml+jinja - - # with path == 'nginx.conf' the return would be ('nginx', '.conf') - {{ path | splitext }} - -The ``splitext`` filter always returns a pair of strings. The individual components can be accessed by using the ``first`` and ``last`` filters: - -.. code-block:: yaml+jinja - - # with path == 'nginx.conf' the return would be 'nginx' - {{ path | splitext | first }} - - # with path == 'nginx.conf' the return would be '.conf' - {{ path | splitext | last }} - -To join one or more path components: - -.. code-block:: yaml+jinja - - {{ ('/etc', path, 'subdir', file) | path_join }} - -.. versionadded:: 2.10 - -Manipulating strings -==================== - -To add quotes for shell usage: - -.. code-block:: yaml+jinja - - - name: Run a shell command - ansible.builtin.shell: echo {{ string_value | quote }} - -To concatenate a list into a string: - -.. code-block:: yaml+jinja - - {{ list | join(" ") }} - -To split a string into a list: - -.. code-block:: yaml+jinja - - {{ csv_string | split(",") }} - -.. versionadded:: 2.11 - -To work with Base64 encoded strings: - -.. code-block:: yaml+jinja - - {{ encoded | b64decode }} - {{ decoded | string | b64encode }} - -As of version 2.6, you can define the type of encoding to use, the default is ``utf-8``: - -.. code-block:: yaml+jinja - - {{ encoded | b64decode(encoding='utf-16-le') }} - {{ decoded | string | b64encode(encoding='utf-16-le') }} - -.. note:: The ``string`` filter is only required for Python 2 and ensures that text to encode is a unicode string. Without that filter before b64encode the wrong value will be encoded. - -.. note:: The return value of b64decode is a string. If you decrypt a binary blob using b64decode and then try to use it (for example by using :ref:`copy ` to write it to a file) you will mostly likely find that your binary has been corrupted. If you need to take a base64 encoded binary and write it to disk, it is best to use the system ``base64`` command with the :ref:`shell module `, piping in the encoded data using the ``stdin`` parameter. For example: ``shell: cmd="base64 --decode > myfile.bin" stdin="{{ encoded }}"`` - -.. versionadded:: 2.6 - -Managing UUIDs -============== - -To create a namespaced UUIDv5: - -.. code-block:: yaml+jinja - - {{ string | to_uuid(namespace='11111111-2222-3333-4444-555555555555') }} - -.. versionadded:: 2.10 - -To create a namespaced UUIDv5 using the default Ansible namespace '361E6D51-FAEC-444A-9079-341386DA8E2E': - -.. code-block:: yaml+jinja - - {{ string | to_uuid }} - -.. versionadded:: 1.9 - -To make use of one attribute from each item in a list of complex variables, use the :func:`Jinja2 map filter `: - -.. code-block:: yaml+jinja - - # get a comma-separated list of the mount points (for example, "/,/mnt/stuff") on a host - {{ ansible_mounts | map(attribute='mount') | join(',') }} - -Handling dates and times -======================== - -To get a date object from a string use the `to_datetime` filter: - -.. code-block:: yaml+jinja - - # Get total amount of seconds between two dates. Default date format is %Y-%m-%d %H:%M:%S but you can pass your own format - {{ (("2016-08-14 20:00:12" | to_datetime) - ("2015-12-25" | to_datetime('%Y-%m-%d'))).total_seconds() }} - - # Get remaining seconds after delta has been calculated. NOTE: This does NOT convert years, days, hours, and so on to seconds. For that, use total_seconds() - {{ (("2016-08-14 20:00:12" | to_datetime) - ("2016-08-14 18:00:00" | to_datetime)).seconds }} - # This expression evaluates to "12" and not "132". Delta is 2 hours, 12 seconds - - # get amount of days between two dates. This returns only number of days and discards remaining hours, minutes, and seconds - {{ (("2016-08-14 20:00:12" | to_datetime) - ("2015-12-25" | to_datetime('%Y-%m-%d'))).days }} - -.. note:: For a full list of format codes for working with python date format strings, see the `python datetime documentation `_. - -.. versionadded:: 2.4 - -To format a date using a string (like with the shell date command), use the "strftime" filter: - -.. code-block:: yaml+jinja - - # Display year-month-day - {{ '%Y-%m-%d' | strftime }} - # => "2021-03-19" - - # Display hour:min:sec - {{ '%H:%M:%S' | strftime }} - # => "21:51:04" - - # Use ansible_date_time.epoch fact - {{ '%Y-%m-%d %H:%M:%S' | strftime(ansible_date_time.epoch) }} - # => "2021-03-19 21:54:09" - - # Use arbitrary epoch value - {{ '%Y-%m-%d' | strftime(0) }} # => 1970-01-01 - {{ '%Y-%m-%d' | strftime(1441357287) }} # => 2015-09-04 - -.. versionadded:: 2.13 - -strftime takes an optional utc argument, defaulting to False, meaning times are in the local timezone: - -.. code-block:: yaml+jinja - - {{ '%H:%M:%S' | strftime }} # time now in local timezone - {{ '%H:%M:%S' | strftime(utc=True) }} # time now in UTC - -.. note:: To get all string possibilities, check https://docs.python.org/3/library/time.html#time.strftime - -Getting Kubernetes resource names -================================= - -.. note:: - - These filters have migrated to the `kubernetes.core `_ collection. Follow the installation instructions to install that collection. - -Use the "k8s_config_resource_name" filter to obtain the name of a Kubernetes ConfigMap or Secret, -including its hash: - -.. code-block:: yaml+jinja - - {{ configmap_resource_definition | kubernetes.core.k8s_config_resource_name }} - -This can then be used to reference hashes in Pod specifications: - -.. code-block:: yaml+jinja - - my_secret: - kind: Secret - metadata: - name: my_secret_name - - deployment_resource: - kind: Deployment - spec: - template: - spec: - containers: - - envFrom: - - secretRef: - name: {{ my_secret | kubernetes.core.k8s_config_resource_name }} - -.. versionadded:: 2.8 - -.. _PyYAML library: https://pyyaml.org/ - -.. _PyYAML documentation: https://pyyaml.org/wiki/PyYAMLDocumentation - - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_variables` - All about variables - :ref:`playbooks_loops` - Looping in playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - :ref:`tips_and_tricks` - Tips and tricks for playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_handlers.rst b/docs/docsite/rst/playbook_guide/playbooks_handlers.rst deleted file mode 100644 index 69a865883e3..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_handlers.rst +++ /dev/null @@ -1,196 +0,0 @@ -.. _handlers: - -Handlers: running operations on change -====================================== - -Sometimes you want a task to run only when a change is made on a machine. For example, you may want to restart a service if a task updates the configuration of that service, but not if the configuration is unchanged. Ansible uses handlers to address this use case. Handlers are tasks that only run when notified. - -.. contents:: - :local: - -Handler example ---------------- - -This playbook, ``verify-apache.yml``, contains a single play with a handler. - -.. code-block:: yaml - - --- - - name: Verify apache installation - hosts: webservers - vars: - http_port: 80 - max_clients: 200 - remote_user: root - tasks: - - name: Ensure apache is at the latest version - ansible.builtin.yum: - name: httpd - state: latest - - - name: Write the apache config file - ansible.builtin.template: - src: /srv/httpd.j2 - dest: /etc/httpd.conf - notify: - - Restart apache - - - name: Ensure apache is running - ansible.builtin.service: - name: httpd - state: started - - handlers: - - name: Restart apache - ansible.builtin.service: - name: httpd - state: restarted - -In this example playbook, the Apache server is restarted by the handler after all tasks complete in the play. - - -Notifying handlers ------------------- - -Tasks can instruct one or more handlers to execute using the ``notify`` keyword. The ``notify`` keyword can be applied to a task and accepts a list of handler names that are notified on a task change. Alternately, a string containing a single handler name can be supplied as well. The following example demonstrates how multiple handlers can be notified by a single task: - -.. code-block:: yaml - - tasks: - - name: Template configuration file - ansible.builtin.template: - src: template.j2 - dest: /etc/foo.conf - notify: - - Restart apache - - Restart memcached - - handlers: - - name: Restart memcached - ansible.builtin.service: - name: memcached - state: restarted - - - name: Restart apache - ansible.builtin.service: - name: apache - state: restarted - -In the above example the handlers are executed on task change in the following order: ``Restart memcached``, ``Restart apache``. Handlers are executed in the order they are defined in the ``handlers`` section, not in the order listed in the ``notify`` statement. Notifying the same handler multiple times will result in executing the handler only once regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts. - - -Naming handlers ---------------- - -Handlers must be named in order for tasks to be able to notify them using the ``notify`` keyword. - -Alternately, handlers can utilize the ``listen`` keyword. Using this handler keyword, handlers can listen on topics that can group multiple handlers as follows: - -.. code-block:: yaml - - tasks: - - name: Restart everything - command: echo "this task will restart the web services" - notify: "restart web services" - - handlers: - - name: Restart memcached - service: - name: memcached - state: restarted - listen: "restart web services" - - - name: Restart apache - service: - name: apache - state: restarted - listen: "restart web services" - -Notifying the ``restart web services`` topic results in executing all handlers listening to that topic regardless of how those handlers are named. - -This use makes it much easier to trigger multiple handlers. It also decouples handlers from their names, making it easier to share handlers among playbooks and roles (especially when using third-party roles from a shared source such as Ansible Galaxy). - -Each handler should have a globally unique name. If multiple handlers are defined with the same name, only the last one defined is notified with ``notify``, effectively shadowing all of the previous handlers with the same name. Alternately handlers sharing the same name can all be notified and executed if they listen on the same topic by notifying that topic. - -There is only one global scope for handlers (handler names and listen topics) regardless of where the handlers are defined. This also includes handlers defined in roles. - - -Controlling when handlers run ------------------------------ - -By default, handlers run after all the tasks in a particular play have been completed. Notified handlers are executed automatically after each of the following sections, in the following order: ``pre_tasks``, ``roles``/``tasks`` and ``post_tasks``. This approach is efficient, because the handler only runs once, regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts. - -If you need handlers to run before the end of the play, add a task to flush them using the :ref:`meta module `, which executes Ansible actions: - -.. code-block:: yaml - - tasks: - - name: Some tasks go here - ansible.builtin.shell: ... - - - name: Flush handlers - meta: flush_handlers - - - name: Some other tasks - ansible.builtin.shell: ... - -The ``meta: flush_handlers`` task triggers any handlers that have been notified at that point in the play. - -Once handlers are executed, either automatically after each mentioned section or manually by the ``flush_handlers`` meta task, they can be notified and run again in later sections of the play. - - -Using variables with handlers ------------------------------ - -You may want your Ansible handlers to use variables. For example, if the name of a service varies slightly by distribution, you want your output to show the exact name of the restarted service for each target machine. Avoid placing variables in the name of the handler. Since handler names are templated early on, Ansible may not have a value available for a handler name like this: - -.. code-block:: yaml+jinja - - handlers: - # This handler name may cause your play to fail! - - name: Restart "{{ web_service_name }}" - -If the variable used in the handler name is not available, the entire play fails. Changing that variable mid-play **will not** result in newly created handler. - -Instead, place variables in the task parameters of your handler. You can load the values using ``include_vars`` like this: - -.. code-block:: yaml+jinja - - tasks: - - name: Set host variables based on distribution - include_vars: "{{ ansible_facts.distribution }}.yml" - - handlers: - - name: Restart web service - ansible.builtin.service: - name: "{{ web_service_name | default('httpd') }}" - state: restarted - -While handler names can contain a template, ``listen`` topics cannot. - - -Handlers in roles ------------------ - -Handlers from roles are not just contained in their roles but rather inserted into global scope with all other handlers from a play. As such they can be used outside of the role they are defined in. It also means that their name can conflict with handlers from outside the role. To ensure that a handler from a role is notified as opposed to one from outside the role with the same name, notify the handler by using its name in the following form: ``role_name : handler_name``. - -Handlers notified within the ``roles`` section are automatically flushed at the end of the ``tasks`` section, but before any ``tasks`` handlers. - - -Includes and imports in handlers --------------------------------- -Notifying a dynamic include such as ``include_task`` as a handler results in executing all tasks from within the include. It is not possible to notify a handler defined inside a dynamic include. - -Having a static include such as ``import_task`` as a handler results in that handler being effectively rewritten by handlers from within that import before the play execution. A static include itself cannot be notified; the tasks from within that include, on the other hand, can be notified individually. - - -Meta tasks as handlers ----------------------- - -Since Ansible 2.14 :ref:`meta tasks ` are allowed to be used and notified as handlers. Note that however ``flush_handlers`` cannot be used as a handler to prevent unexpected behavior. - - -Limitations ------------ - -A handler cannot run ``import_role`` or ``include_role``. diff --git a/docs/docsite/rst/playbook_guide/playbooks_intro.rst b/docs/docsite/rst/playbook_guide/playbooks_intro.rst deleted file mode 100644 index 8592b0429ff..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_intro.rst +++ /dev/null @@ -1,159 +0,0 @@ -.. _about_playbooks: -.. _playbooks_intro: - -***************** -Ansible playbooks -***************** - -Ansible Playbooks offer a repeatable, re-usable, simple configuration management and multi-machine deployment system, one that is well suited to deploying complex applications. If you need to execute a task with Ansible more than once, write a playbook and put it under source control. Then you can use the playbook to push out new configuration or confirm the configuration of remote systems. The playbooks in the `ansible-examples repository `_ illustrate many useful techniques. You may want to look at these in another tab as you read the documentation. - -Playbooks can: - -* declare configurations -* orchestrate steps of any manual ordered process, on multiple sets of machines, in a defined order -* launch tasks synchronously or :ref:`asynchronously ` - -.. contents:: - :local: - -.. _playbook_language_example: - -Playbook syntax -=============== - -Playbooks are expressed in YAML format with a minimum of syntax. If you are not familiar with YAML, look at our overview of :ref:`yaml_syntax` and consider installing an add-on for your text editor (see :ref:`other_tools_and_programs`) to help you write clean YAML syntax in your playbooks. - -A playbook is composed of one or more 'plays' in an ordered list. The terms 'playbook' and 'play' are sports analogies. Each play executes part of the overall goal of the playbook, running one or more tasks. Each task calls an Ansible module. - -Playbook execution -================== - -A playbook runs in order from top to bottom. Within each play, tasks also run in order from top to bottom. Playbooks with multiple 'plays' can orchestrate multi-machine deployments, running one play on your webservers, then another play on your database servers, then a third play on your network infrastructure, and so on. At a minimum, each play defines two things: - -* the managed nodes to target, using a :ref:`pattern ` -* at least one task to execute - -.. note:: - - In Ansible 2.10 and later, we recommend you use the fully-qualified collection name in your playbooks to ensure the correct module is selected, because multiple collections can contain modules with the same name (for example, ``user``). See :ref:`collections_using_playbook`. - -In this example, the first play targets the web servers; the second play targets the database servers. - -.. code-block:: yaml - - --- - - name: Update web servers - hosts: webservers - remote_user: root - - tasks: - - name: Ensure apache is at the latest version - ansible.builtin.yum: - name: httpd - state: latest - - name: Write the apache config file - ansible.builtin.template: - src: /srv/httpd.j2 - dest: /etc/httpd.conf - - - name: Update db servers - hosts: databases - remote_user: root - - tasks: - - name: Ensure postgresql is at the latest version - ansible.builtin.yum: - name: postgresql - state: latest - - name: Ensure that postgresql is started - ansible.builtin.service: - name: postgresql - state: started - -Your playbook can include more than just a hosts line and tasks. For example, the playbook above sets a ``remote_user`` for each play. This is the user account for the SSH connection. You can add other :ref:`playbook_keywords` at the playbook, play, or task level to influence how Ansible behaves. Playbook keywords can control the :ref:`connection plugin `, whether to use :ref:`privilege escalation `, how to handle errors, and more. To support a variety of environments, Ansible lets you set many of these parameters as command-line flags, in your Ansible configuration, or in your inventory. Learning the :ref:`precedence rules ` for these sources of data will help you as you expand your Ansible ecosystem. - -.. _tasks_list: - -Task execution --------------- - -By default, Ansible executes each task in order, one at a time, against all machines matched by the host pattern. Each task executes a module with specific arguments. When a task has executed on all target machines, Ansible moves on to the next task. You can use :ref:`strategies ` to change this default behavior. Within each play, Ansible applies the same task directives to all hosts. If a task fails on a host, Ansible takes that host out of the rotation for the rest of the playbook. - -When you run a playbook, Ansible returns information about connections, the ``name`` lines of all your plays and tasks, whether each task has succeeded or failed on each machine, and whether each task has made a change on each machine. At the bottom of the playbook execution, Ansible provides a summary of the nodes that were targeted and how they performed. General failures and fatal "unreachable" communication attempts are kept separate in the counts. - -.. _idempotency: - -Desired state and 'idempotency' -------------------------------- - -Most Ansible modules check whether the desired final state has already been achieved, and exit without performing any actions if that state has been achieved, so that repeating the task does not change the final state. Modules that behave this way are often called 'idempotent.' Whether you run a playbook once, or multiple times, the outcome should be the same. However, not all playbooks and not all modules behave this way. If you are unsure, test your playbooks in a sandbox environment before running them multiple times in production. - -.. _executing_a_playbook: - -Running playbooks ------------------ - -To run your playbook, use the :ref:`ansible-playbook` command. - -.. code-block:: bash - - ansible-playbook playbook.yml -f 10 - -Use the ``--verbose`` flag when running your playbook to see detailed output from successful modules as well as unsuccessful ones. - -.. _playbook_ansible-pull: - -Ansible-Pull -============ - -Should you want to invert the architecture of Ansible, so that nodes check in to a central location, instead -of pushing configuration out to them, you can. - -The ``ansible-pull`` is a small script that will checkout a repo of configuration instructions from git, and then -run ``ansible-playbook`` against that content. - -Assuming you load balance your checkout location, ``ansible-pull`` scales essentially infinitely. - -Run ``ansible-pull --help`` for details. - -There's also a `clever playbook `_ available to configure ``ansible-pull`` through a crontab from push mode. - -Verifying playbooks -=================== - -You may want to verify your playbooks to catch syntax errors and other problems before you run them. The :ref:`ansible-playbook` command offers several options for verification, including ``--check``, ``--diff``, ``--list-hosts``, ``--list-tasks``, and ``--syntax-check``. The :ref:`validate-playbook-tools` describes other tools for validating and testing playbooks. - -.. _linting_playbooks: - -ansible-lint ------------- - -You can use `ansible-lint `_ for detailed, Ansible-specific feedback on your playbooks before you execute them. For example, if you run ``ansible-lint`` on the playbook called ``verify-apache.yml`` near the top of this page, you should get the following results: - -.. code-block:: bash - - $ ansible-lint verify-apache.yml - [403] Package installs should not use latest - verify-apache.yml:8 - Task/Handler: ensure apache is at the latest version - -The `ansible-lint default rules `_ page describes each error. For ``[403]``, the recommended fix is to change ``state: latest`` to ``state: present`` in the playbook. - -.. seealso:: - - `ansible-lint `_ - Learn how to test Ansible Playbooks syntax - :ref:`yaml_syntax` - Learn about YAML syntax - :ref:`tips_and_tricks` - Tips for managing playbooks in the real world - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_modules` - Learn to extend Ansible by writing your own modules - :ref:`intro_patterns` - Learn about how to select hosts - `GitHub examples directory `_ - Complete end-to-end playbook examples - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups diff --git a/docs/docsite/rst/playbook_guide/playbooks_lookups.rst b/docs/docsite/rst/playbook_guide/playbooks_lookups.rst deleted file mode 100644 index 785f150be69..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_lookups.rst +++ /dev/null @@ -1,39 +0,0 @@ -.. _playbooks_lookups: - -******* -Lookups -******* - -Lookup plugins retrieve data from outside sources such as files, databases, key/value stores, APIs, and other services. Like all templating, lookups execute and are evaluated on the Ansible control machine. Ansible makes the data returned by a lookup plugin available using the standard templating system. Before Ansible 2.5, lookups were mostly used indirectly in ``with_`` constructs for looping. Starting with Ansible 2.5, lookups are used more explicitly as part of Jinja2 expressions fed into the ``loop`` keyword. - -.. _lookups_and_variables: - -Using lookups in variables -========================== - -You can populate variables using lookups. Ansible evaluates the value each time it is executed in a task (or template). - -.. code-block:: yaml+jinja - - vars: - motd_value: "{{ lookup('file', '/etc/motd') }}" - tasks: - - debug: - msg: "motd value is {{ motd_value }}" - -For more details and a list of lookup plugins in ansible-core, see :ref:`plugins_lookup`. You may also find lookup plugins in collections. You can review a list of lookup plugins installed on your control machine with the command ``ansible-doc -l -t lookup``. - -.. seealso:: - - :ref:`working_with_playbooks` - An introduction to playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_variables` - All about variables - :ref:`playbooks_loops` - Looping in playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_loops.rst b/docs/docsite/rst/playbook_guide/playbooks_loops.rst deleted file mode 100644 index 4d2272f1c08..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_loops.rst +++ /dev/null @@ -1,499 +0,0 @@ -.. _playbooks_loops: - -***** -Loops -***** - -Ansible offers the ``loop``, ``with_``, and ``until`` keywords to execute a task multiple times. Examples of commonly-used loops include changing ownership on several files and/or directories with the :ref:`file module `, creating multiple users with the :ref:`user module `, and -repeating a polling step until a certain result is reached. - -.. note:: - * We added ``loop`` in Ansible 2.5. It is not yet a full replacement for ``with_``, but we recommend it for most use cases. - * We have not deprecated the use of ``with_`` - that syntax will still be valid for the foreseeable future. - * We are looking to improve ``loop`` syntax - watch this page and the `changelog `_ for updates. - -.. contents:: - :local: - -Comparing ``loop`` and ``with_*`` -================================= - -* The ``with_`` keywords rely on :ref:`lookup_plugins` - even ``items`` is a lookup. -* The ``loop`` keyword is equivalent to ``with_list``, and is the best choice for simple loops. -* The ``loop`` keyword will not accept a string as input, see :ref:`query_vs_lookup`. -* Generally speaking, any use of ``with_*`` covered in :ref:`migrating_to_loop` can be updated to use ``loop``. -* Be careful when changing ``with_items`` to ``loop``, as ``with_items`` performed implicit single-level flattening. You may need to use ``flatten(1)`` with ``loop`` to match the exact outcome. For example, to get the same output as: - -.. code-block:: yaml - - with_items: - - 1 - - [2,3] - - 4 - -you would need - -.. code-block:: yaml+jinja - - loop: "{{ [1, [2, 3], 4] | flatten(1) }}" - -* Any ``with_*`` statement that requires using ``lookup`` within a loop should not be converted to use the ``loop`` keyword. For example, instead of doing: - -.. code-block:: yaml+jinja - - loop: "{{ lookup('fileglob', '*.txt', wantlist=True) }}" - -it's cleaner to keep - -.. code-block:: yaml - - with_fileglob: '*.txt' - -.. _standard_loops: - -Standard loops -============== - -Iterating over a simple list ----------------------------- - -Repeated tasks can be written as standard loops over a simple list of strings. You can define the list directly in the task. - -.. code-block:: yaml+jinja - - - name: Add several users - ansible.builtin.user: - name: "{{ item }}" - state: present - groups: "wheel" - loop: - - testuser1 - - testuser2 - -You can define the list in a variables file, or in the 'vars' section of your play, then refer to the name of the list in the task. - -.. code-block:: yaml+jinja - - loop: "{{ somelist }}" - -Either of these examples would be the equivalent of - -.. code-block:: yaml - - - name: Add user testuser1 - ansible.builtin.user: - name: "testuser1" - state: present - groups: "wheel" - - - name: Add user testuser2 - ansible.builtin.user: - name: "testuser2" - state: present - groups: "wheel" - -You can pass a list directly to a parameter for some plugins. Most of the packaging modules, like :ref:`yum ` and :ref:`apt `, have this capability. When available, passing the list to a parameter is better than looping over the task. For example - -.. code-block:: yaml+jinja - - - name: Optimal yum - ansible.builtin.yum: - name: "{{ list_of_packages }}" - state: present - - - name: Non-optimal yum, slower and may cause issues with interdependencies - ansible.builtin.yum: - name: "{{ item }}" - state: present - loop: "{{ list_of_packages }}" - -Check the :ref:`module documentation ` to see if you can pass a list to any particular module's parameter(s). - -Iterating over a list of hashes -------------------------------- - -If you have a list of hashes, you can reference subkeys in a loop. For example: - -.. code-block:: yaml+jinja - - - name: Add several users - ansible.builtin.user: - name: "{{ item.name }}" - state: present - groups: "{{ item.groups }}" - loop: - - { name: 'testuser1', groups: 'wheel' } - - { name: 'testuser2', groups: 'root' } - -When combining :ref:`conditionals ` with a loop, the ``when:`` statement is processed separately for each item. -See :ref:`the_when_statement` for examples. - -Iterating over a dictionary ---------------------------- - -To loop over a dict, use the :ref:`dict2items `: - -.. code-block:: yaml+jinja - - - name: Using dict2items - ansible.builtin.debug: - msg: "{{ item.key }} - {{ item.value }}" - loop: "{{ tag_data | dict2items }}" - vars: - tag_data: - Environment: dev - Application: payment - -Here, we are iterating over `tag_data` and printing the key and the value from it. - -Registering variables with a loop -================================= - -You can register the output of a loop as a variable. For example - -.. code-block:: yaml+jinja - - - name: Register loop output as a variable - ansible.builtin.shell: "echo {{ item }}" - loop: - - "one" - - "two" - register: echo - -When you use ``register`` with a loop, the data structure placed in the variable will contain a ``results`` attribute that is a list of all responses from the module. This differs from the data structure returned when using ``register`` without a loop. - -.. code-block:: json - - { - "changed": true, - "msg": "All items completed", - "results": [ - { - "changed": true, - "cmd": "echo \"one\" ", - "delta": "0:00:00.003110", - "end": "2013-12-19 12:00:05.187153", - "invocation": { - "module_args": "echo \"one\"", - "module_name": "shell" - }, - "item": "one", - "rc": 0, - "start": "2013-12-19 12:00:05.184043", - "stderr": "", - "stdout": "one" - }, - { - "changed": true, - "cmd": "echo \"two\" ", - "delta": "0:00:00.002920", - "end": "2013-12-19 12:00:05.245502", - "invocation": { - "module_args": "echo \"two\"", - "module_name": "shell" - }, - "item": "two", - "rc": 0, - "start": "2013-12-19 12:00:05.242582", - "stderr": "", - "stdout": "two" - } - ] - } - -Subsequent loops over the registered variable to inspect the results may look like - -.. code-block:: yaml+jinja - - - name: Fail if return code is not 0 - ansible.builtin.fail: - msg: "The command ({{ item.cmd }}) did not have a 0 return code" - when: item.rc != 0 - loop: "{{ echo.results }}" - -During iteration, the result of the current item will be placed in the variable. - -.. code-block:: yaml+jinja - - - name: Place the result of the current item in the variable - ansible.builtin.shell: echo "{{ item }}" - loop: - - one - - two - register: echo - changed_when: echo.stdout != "one" - -.. _complex_loops: - -Complex loops -============= - -Iterating over nested lists ---------------------------- - -You can use Jinja2 expressions to iterate over complex lists. For example, a loop can combine nested lists. - -.. code-block:: yaml+jinja - - - name: Give users access to multiple databases - community.mysql.mysql_user: - name: "{{ item[0] }}" - priv: "{{ item[1] }}.*:ALL" - append_privs: true - password: "foo" - loop: "{{ ['alice', 'bob'] | product(['clientdb', 'employeedb', 'providerdb']) | list }}" - - -.. _do_until_loops: - -Retrying a task until a condition is met ----------------------------------------- - -.. versionadded:: 1.4 - -You can use the ``until`` keyword to retry a task until a certain condition is met. Here's an example: - -.. code-block:: yaml - - - name: Retry a task until a certain condition is met - ansible.builtin.shell: /usr/bin/foo - register: result - until: result.stdout.find("all systems go") != -1 - retries: 5 - delay: 10 - -This task runs up to 5 times with a delay of 10 seconds between each attempt. If the result of any attempt has "all systems go" in its stdout, the task succeeds. The default value for "retries" is 3 and "delay" is 5. - -To see the results of individual retries, run the play with ``-vv``. - -When you run a task with ``until`` and register the result as a variable, the registered variable will include a key called "attempts", which records the number of the retries for the task. - -.. note:: You must set the ``until`` parameter if you want a task to retry. If ``until`` is not defined, the value for the ``retries`` parameter is forced to 1. - -Looping over inventory ----------------------- - -To loop over your inventory, or just a subset of it, you can use a regular ``loop`` with the ``ansible_play_batch`` or ``groups`` variables. - -.. code-block:: yaml+jinja - - - name: Show all the hosts in the inventory - ansible.builtin.debug: - msg: "{{ item }}" - loop: "{{ groups['all'] }}" - - - name: Show all the hosts in the current play - ansible.builtin.debug: - msg: "{{ item }}" - loop: "{{ ansible_play_batch }}" - -There is also a specific lookup plugin ``inventory_hostnames`` that can be used like this - -.. code-block:: yaml+jinja - - - name: Show all the hosts in the inventory - ansible.builtin.debug: - msg: "{{ item }}" - loop: "{{ query('inventory_hostnames', 'all') }}" - - - name: Show all the hosts matching the pattern, ie all but the group www - ansible.builtin.debug: - msg: "{{ item }}" - loop: "{{ query('inventory_hostnames', 'all:!www') }}" - -More information on the patterns can be found in :ref:`intro_patterns`. - -.. _query_vs_lookup: - -Ensuring list input for ``loop``: using ``query`` rather than ``lookup`` -======================================================================== - -The ``loop`` keyword requires a list as input, but the ``lookup`` keyword returns a string of comma-separated values by default. Ansible 2.5 introduced a new Jinja2 function named :ref:`query ` that always returns a list, offering a simpler interface and more predictable output from lookup plugins when using the ``loop`` keyword. - -You can force ``lookup`` to return a list to ``loop`` by using ``wantlist=True``, or you can use ``query`` instead. - -The following two examples do the same thing. - -.. code-block:: yaml+jinja - - loop: "{{ query('inventory_hostnames', 'all') }}" - - loop: "{{ lookup('inventory_hostnames', 'all', wantlist=True) }}" - - -.. _loop_control: - -Adding controls to loops -======================== -.. versionadded:: 2.1 - -The ``loop_control`` keyword lets you manage your loops in useful ways. - -Limiting loop output with ``label`` ------------------------------------ -.. versionadded:: 2.2 - -When looping over complex data structures, the console output of your task can be enormous. To limit the displayed output, use the ``label`` directive with ``loop_control``. - -.. code-block:: yaml+jinja - - - name: Create servers - digital_ocean: - name: "{{ item.name }}" - state: present - loop: - - name: server1 - disks: 3gb - ram: 15Gb - network: - nic01: 100Gb - nic02: 10Gb - ... - loop_control: - label: "{{ item.name }}" - -The output of this task will display just the ``name`` field for each ``item`` instead of the entire contents of the multi-line ``{{ item }}`` variable. - -.. note:: This is for making console output more readable, not protecting sensitive data. If there is sensitive data in ``loop``, set ``no_log: true`` on the task to prevent disclosure. - -Pausing within a loop ---------------------- -.. versionadded:: 2.2 - -To control the time (in seconds) between the execution of each item in a task loop, use the ``pause`` directive with ``loop_control``. - -.. code-block:: yaml+jinja - - # main.yml - - name: Create servers, pause 3s before creating next - community.digitalocean.digital_ocean: - name: "{{ item }}" - state: present - loop: - - server1 - - server2 - loop_control: - pause: 3 - -Tracking progress through a loop with ``index_var`` ---------------------------------------------------- -.. versionadded:: 2.5 - -To keep track of where you are in a loop, use the ``index_var`` directive with ``loop_control``. This directive specifies a variable name to contain the current loop index. - -.. code-block:: yaml+jinja - - - name: Count our fruit - ansible.builtin.debug: - msg: "{{ item }} with index {{ my_idx }}" - loop: - - apple - - banana - - pear - loop_control: - index_var: my_idx - -.. note:: `index_var` is 0 indexed. - -Defining inner and outer variable names with ``loop_var`` ---------------------------------------------------------- -.. versionadded:: 2.1 - -You can nest two looping tasks using ``include_tasks``. However, by default Ansible sets the loop variable ``item`` for each loop. This means the inner, nested loop will overwrite the value of ``item`` from the outer loop. -You can specify the name of the variable for each loop using ``loop_var`` with ``loop_control``. - -.. code-block:: yaml+jinja - - # main.yml - - include_tasks: inner.yml - loop: - - 1 - - 2 - - 3 - loop_control: - loop_var: outer_item - - # inner.yml - - name: Print outer and inner items - ansible.builtin.debug: - msg: "outer item={{ outer_item }} inner item={{ item }}" - loop: - - a - - b - - c - -.. note:: If Ansible detects that the current loop is using a variable which has already been defined, it will raise an error to fail the task. - -Extended loop variables ------------------------ -.. versionadded:: 2.8 - -As of Ansible 2.8 you can get extended loop information using the ``extended`` option to loop control. This option will expose the following information. - -========================== =========== -Variable Description --------------------------- ----------- -``ansible_loop.allitems`` The list of all items in the loop -``ansible_loop.index`` The current iteration of the loop. (1 indexed) -``ansible_loop.index0`` The current iteration of the loop. (0 indexed) -``ansible_loop.revindex`` The number of iterations from the end of the loop (1 indexed) -``ansible_loop.revindex0`` The number of iterations from the end of the loop (0 indexed) -``ansible_loop.first`` ``True`` if first iteration -``ansible_loop.last`` ``True`` if last iteration -``ansible_loop.length`` The number of items in the loop -``ansible_loop.previtem`` The item from the previous iteration of the loop. Undefined during the first iteration. -``ansible_loop.nextitem`` The item from the following iteration of the loop. Undefined during the last iteration. -========================== =========== - -:: - - loop_control: - extended: true - -.. note:: When using ``loop_control.extended`` more memory will be utilized on the control node. This is a result of ``ansible_loop.allitems`` containing a reference to the full loop data for every loop. When serializing the results for display in callback plugins within the main ansible process, these references may be dereferenced causing memory usage to increase. - -.. versionadded:: 2.14 - -To disable the ``ansible_loop.allitems`` item, to reduce memory consumption, set ``loop_control.extended_allitems: false``. - -:: - - loop_control: - extended: true - extended_allitems: false - -Accessing the name of your loop_var ------------------------------------ -.. versionadded:: 2.8 - -As of Ansible 2.8 you can get the name of the value provided to ``loop_control.loop_var`` using the ``ansible_loop_var`` variable - -For role authors, writing roles that allow loops, instead of dictating the required ``loop_var`` value, you can gather the value through the following - -.. code-block:: yaml+jinja - - "{{ lookup('vars', ansible_loop_var) }}" - -.. _migrating_to_loop: - -Migrating from with_X to loop -============================= - -.. include:: shared_snippets/with2loop.txt - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - :ref:`tips_and_tricks` - Tips and tricks for playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_variables` - All about variables - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_module_defaults.rst b/docs/docsite/rst/playbook_guide/playbooks_module_defaults.rst deleted file mode 100644 index 3a4bdfc31f8..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_module_defaults.rst +++ /dev/null @@ -1,175 +0,0 @@ -.. _module_defaults: - -Module defaults -=============== - -If you frequently call the same module with the same arguments, it can be useful to define default arguments for that particular module using the ``module_defaults`` keyword. - -Here is a basic example: - -.. code-block:: YAML - - - hosts: localhost - module_defaults: - ansible.builtin.file: - owner: root - group: root - mode: 0755 - tasks: - - name: Create file1 - ansible.builtin.file: - state: touch - path: /tmp/file1 - - - name: Create file2 - ansible.builtin.file: - state: touch - path: /tmp/file2 - - - name: Create file3 - ansible.builtin.file: - state: touch - path: /tmp/file3 - -The ``module_defaults`` keyword can be used at the play, block, and task level. Any module arguments explicitly specified in a task will override any established default for that module argument. - -.. code-block:: YAML - - - block: - - name: Print a message - ansible.builtin.debug: - msg: "Different message" - module_defaults: - ansible.builtin.debug: - msg: "Default message" - -You can remove any previously established defaults for a module by specifying an empty dict. - -.. code-block:: YAML - - - name: Create file1 - ansible.builtin.file: - state: touch - path: /tmp/file1 - module_defaults: - file: {} - -.. note:: - Any module defaults set at the play level (and block/task level when using ``include_role`` or ``import_role``) will apply to any roles used, which may cause unexpected behavior in the role. - -Here are some more realistic use cases for this feature. - -Interacting with an API that requires auth. - -.. code-block:: YAML - - - hosts: localhost - module_defaults: - ansible.builtin.uri: - force_basic_auth: true - user: some_user - password: some_password - tasks: - - name: Interact with a web service - ansible.builtin.uri: - url: http://some.api.host/v1/whatever1 - - - name: Interact with a web service - ansible.builtin.uri: - url: http://some.api.host/v1/whatever2 - - - name: Interact with a web service - ansible.builtin.uri: - url: http://some.api.host/v1/whatever3 - -Setting a default AWS region for specific EC2-related modules. - -.. code-block:: YAML - - - hosts: localhost - vars: - my_region: us-west-2 - module_defaults: - amazon.aws.ec2: - region: '{{ my_region }}' - community.aws.ec2_instance_info: - region: '{{ my_region }}' - amazon.aws.ec2_vpc_net_info: - region: '{{ my_region }}' - -.. _module_defaults_groups: - -Module defaults groups ----------------------- - -.. versionadded:: 2.7 - -Ansible 2.7 adds a preview-status feature to group together modules that share common sets of parameters. This makes it easier to author playbooks making heavy use of API-based modules such as cloud modules. - -+---------+---------------------------+-----------------+ -| Group | Purpose | Ansible Version | -+=========+===========================+=================+ -| aws | Amazon Web Services | 2.7 | -+---------+---------------------------+-----------------+ -| azure | Azure | 2.7 | -+---------+---------------------------+-----------------+ -| gcp | Google Cloud Platform | 2.7 | -+---------+---------------------------+-----------------+ -| k8s | Kubernetes | 2.8 | -+---------+---------------------------+-----------------+ -| os | OpenStack | 2.8 | -+---------+---------------------------+-----------------+ -| acme | ACME | 2.10 | -+---------+---------------------------+-----------------+ -| docker* | Docker | 2.10 | -+---------+---------------------------+-----------------+ -| ovirt | oVirt | 2.10 | -+---------+---------------------------+-----------------+ -| vmware | VMware | 2.10 | -+---------+---------------------------+-----------------+ - -* The `docker_stack `_ module is not included in the ``docker`` defaults group. - -Use the groups with ``module_defaults`` by prefixing the group name with ``group/`` - for example ``group/aws``. - -In a playbook, you can set module defaults for whole groups of modules, such as setting a common AWS region. - -.. code-block:: YAML - - # example_play.yml - - hosts: localhost - module_defaults: - group/aws: - region: us-west-2 - tasks: - - name: Get info - aws_s3_bucket_info: - - # now the region is shared between both info modules - - - name: Get info - ec2_ami_info: - filters: - name: 'RHEL*7.5*' - -In ansible-core 2.12, collections can define their own groups in the ``meta/runtime.yml`` file. ``module_defaults`` does not take the ``collections`` keyword into account, so the fully qualified group name must be used for new groups in ``module_defaults``. - -Here is an example ``runtime.yml`` file for a collection and a sample playbook using the group. - -.. code-block:: YAML - - # collections/ansible_collections/ns/coll/meta/runtime.yml - action_groups: - groupname: - - module - - another.collection.module - -.. code-block:: YAML - - - hosts: localhost - module_defaults: - group/ns.coll.groupname: - option_name: option_value - tasks: - - ns.coll.module: - - another.collection.module diff --git a/docs/docsite/rst/playbook_guide/playbooks_privilege_escalation.rst b/docs/docsite/rst/playbook_guide/playbooks_privilege_escalation.rst deleted file mode 100644 index f2b9fbe06b8..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_privilege_escalation.rst +++ /dev/null @@ -1,776 +0,0 @@ -.. _become: -.. _playbooks_privilege_escalation: - -****************************************** -Understanding privilege escalation: become -****************************************** - -Ansible uses existing privilege escalation systems to execute tasks with root privileges or with another user's permissions. Because this feature allows you to 'become' another user, different from the user that logged into the machine (remote user), we call it ``become``. The ``become`` keyword uses existing privilege escalation tools like `sudo`, `su`, `pfexec`, `doas`, `pbrun`, `dzdo`, `ksu`, `runas`, `machinectl` and others. - -.. contents:: - :local: - -Using become -============ - -You can control the use of ``become`` with play or task directives, connection variables, or at the command line. If you set privilege escalation properties in multiple ways, review the :ref:`general precedence rules` to understand which settings will be used. - -A full list of all become plugins that are included in Ansible can be found in the :ref:`become_plugin_list`. - -Become directives ------------------ - -You can set the directives that control ``become`` at the play or task level. You can override these by setting connection variables, which often differ from one host to another. These variables and directives are independent. For example, setting ``become_user`` does not set ``become``. - -become - set to ``true`` to activate privilege escalation. - -become_user - set to user with desired privileges — the user you `become`, NOT the user you login as. Does NOT imply ``become: true``, to allow it to be set at host level. Default value is ``root``. - -become_method - (at play or task level) overrides the default method set in ansible.cfg, set to use any of the :ref:`become_plugins`. - -become_flags - (at play or task level) permit the use of specific flags for the tasks or role. One common use is to change the user to nobody when the shell is set to nologin. Added in Ansible 2.2. - -For example, to manage a system service (which requires ``root`` privileges) when connected as a non-``root`` user, you can use the default value of ``become_user`` (``root``): - -.. code-block:: yaml - - - name: Ensure the httpd service is running - service: - name: httpd - state: started - become: true - -To run a command as the ``apache`` user: - -.. code-block:: yaml - - - name: Run a command as the apache user - command: somecommand - become: true - become_user: apache - -To do something as the ``nobody`` user when the shell is nologin: - -.. code-block:: yaml - - - name: Run a command as nobody - command: somecommand - become: true - become_method: su - become_user: nobody - become_flags: '-s /bin/sh' - -To specify a password for sudo, run ``ansible-playbook`` with ``--ask-become-pass`` (``-K`` for short). -If you run a playbook utilizing ``become`` and the playbook seems to hang, most likely it is stuck at the privilege escalation prompt. Stop it with `CTRL-c`, then execute the playbook with ``-K`` and the appropriate password. - -Become connection variables ---------------------------- - -You can define different ``become`` options for each managed node or group. You can define these variables in inventory or use them as normal variables. - -ansible_become - overrides the ``become`` directive, decides if privilege escalation is used or not. - -ansible_become_method - which privilege escalation method should be used - -ansible_become_user - set the user you become through privilege escalation; does not imply ``ansible_become: true`` - -ansible_become_password - set the privilege escalation password. See :ref:`playbooks_vault` for details on how to avoid having secrets in plain text - -ansible_common_remote_group - determines if Ansible should try to ``chgrp`` its temporary files to a group if ``setfacl`` and ``chown`` both fail. See `Risks of becoming an unprivileged user`_ for more information. Added in version 2.10. - -For example, if you want to run all tasks as ``root`` on a server named ``webserver``, but you can only connect as the ``manager`` user, you could use an inventory entry like this: - -.. code-block:: text - - webserver ansible_user=manager ansible_become=true - -.. note:: - The variables defined above are generic for all become plugins but plugin specific ones can also be set instead. - Please see the documentation for each plugin for a list of all options the plugin has and how they can be defined. - A full list of become plugins in Ansible can be found at :ref:`become_plugins`. - -Become command-line options ---------------------------- - ---ask-become-pass, -K - ask for privilege escalation password; does not imply become will be used. Note that this password will be used for all hosts. - ---become, -b - run operations with become (no password implied) - ---become-method=BECOME_METHOD - privilege escalation method to use (default=sudo), - valid choices: [ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ] - ---become-user=BECOME_USER - run operations as this user (default=root), does not imply --become/-b - -Risks and limitations of become -=============================== - -Although privilege escalation is mostly intuitive, there are a few limitations -on how it works. Users should be aware of these to avoid surprises. - -Risks of becoming an unprivileged user --------------------------------------- - -Ansible modules are executed on the remote machine by first substituting the -parameters into the module file, then copying the file to the remote machine, -and finally executing it there. - -Everything is fine if the module file is executed without using ``become``, -when the ``become_user`` is root, or when the connection to the remote machine -is made as root. In these cases Ansible creates the module file with -permissions that only allow reading by the user and root, or only allow reading -by the unprivileged user being switched to. - -However, when both the connection user and the ``become_user`` are unprivileged, -the module file is written as the user that Ansible connects as (the -``remote_user``), but the file needs to be readable by the user Ansible is set -to ``become``. The details of how Ansible solves this can vary based on platform. -However, on POSIX systems, Ansible solves this problem in the following way: - -First, if :command:`setfacl` is installed and available in the remote ``PATH``, -and the temporary directory on the remote host is mounted with POSIX.1e -filesystem ACL support, Ansible will use POSIX ACLs to share the module file -with the second unprivileged user. - -Next, if POSIX ACLs are **not** available or :command:`setfacl` could not be -run, Ansible will attempt to change ownership of the module file using -:command:`chown` for systems which support doing so as an unprivileged user. - -New in Ansible 2.11, at this point, Ansible will try :command:`chmod +a` which -is a macOS-specific way of setting ACLs on files. - -New in Ansible 2.10, if all of the above fails, Ansible will then check the -value of the configuration setting ``ansible_common_remote_group``. Many -systems will allow a given user to change the group ownership of a file to a -group the user is in. As a result, if the second unprivileged user (the -``become_user``) has a UNIX group in common with the user Ansible is connected -as (the ``remote_user``), and if ``ansible_common_remote_group`` is defined to -be that group, Ansible can try to change the group ownership of the module file -to that group by using :command:`chgrp`, thereby likely making it readable to -the ``become_user``. - -At this point, if ``ansible_common_remote_group`` was defined and a -:command:`chgrp` was attempted and returned successfully, Ansible assumes (but, -importantly, does not check) that the new group ownership is enough and does not -fall back further. That is, Ansible **does not check** that the ``become_user`` -does in fact share a group with the ``remote_user``; so long as the command -exits successfully, Ansible considers the result successful and does not proceed -to check ``allow_world_readable_tmpfiles`` per below. - -If ``ansible_common_remote_group`` is **not** set and the chown above it failed, -or if ``ansible_common_remote_group`` *is* set but the :command:`chgrp` (or -following group-permissions :command:`chmod`) returned a non-successful exit -code, Ansible will lastly check the value of -``allow_world_readable_tmpfiles``. If this is set, Ansible will place the module -file in a world-readable temporary directory, with world-readable permissions to -allow the ``become_user`` (and incidentally any other user on the system) to -read the contents of the file. **If any of the parameters passed to the module -are sensitive in nature, and you do not trust the remote machines, then this is -a potential security risk.** - -Once the module is done executing, Ansible deletes the temporary file. - -Several ways exist to avoid the above logic flow entirely: - -* Use `pipelining`. When pipelining is enabled, Ansible does not save the - module to a temporary file on the client. Instead it pipes the module to - the remote python interpreter's stdin. Pipelining does not work for - python modules involving file transfer (for example: :ref:`copy `, - :ref:`fetch `, :ref:`template `), or for non-python modules. - -* Avoid becoming an unprivileged - user. Temporary files are protected by UNIX file permissions when you - ``become`` root or do not use ``become``. In Ansible 2.1 and above, UNIX - file permissions are also secure if you make the connection to the managed - machine as root and then use ``become`` to access an unprivileged account. - -.. warning:: Although the Solaris ZFS filesystem has filesystem ACLs, the ACLs - are not POSIX.1e filesystem acls (they are NFSv4 ACLs instead). Ansible - cannot use these ACLs to manage its temp file permissions so you may have - to resort to ``allow_world_readable_tmpfiles`` if the remote machines use ZFS. - -.. versionchanged:: 2.1 - -Ansible makes it hard to unknowingly use ``become`` insecurely. Starting in Ansible 2.1, -Ansible defaults to issuing an error if it cannot execute securely with ``become``. -If you cannot use pipelining or POSIX ACLs, must connect as an unprivileged user, -must use ``become`` to execute as a different unprivileged user, -and decide that your managed nodes are secure enough for the -modules you want to run there to be world readable, you can turn on -``allow_world_readable_tmpfiles`` in the :file:`ansible.cfg` file. Setting -``allow_world_readable_tmpfiles`` will change this from an error into -a warning and allow the task to run as it did prior to 2.1. - -.. versionchanged:: 2.10 - -Ansible 2.10 introduces the above-mentioned ``ansible_common_remote_group`` -fallback. As mentioned above, if enabled, it is used when ``remote_user`` and -``become_user`` are both unprivileged users. Refer to the text above for details -on when this fallback happens. - -.. warning:: As mentioned above, if ``ansible_common_remote_group`` and - ``allow_world_readable_tmpfiles`` are both enabled, it is unlikely that the - world-readable fallback will ever trigger, and yet Ansible might still be - unable to access the module file. This is because after the group ownership - change is successful, Ansible does not fall back any further, and also does - not do any check to ensure that the ``become_user`` is actually a member of - the "common group". This is a design decision made by the fact that doing - such a check would require another round-trip connection to the remote - machine, which is a time-expensive operation. Ansible does, however, emit a - warning in this case. - -Not supported by all connection plugins ---------------------------------------- - -Privilege escalation methods must also be supported by the connection plugin -used. Most connection plugins will warn if they do not support become. Some -will just ignore it as they always run as root (jail, chroot, and so on). - -Only one method may be enabled per host ---------------------------------------- - -Methods cannot be chained. You cannot use ``sudo /bin/su -`` to become a user, -you need to have privileges to run the command as that user in sudo or be able -to su directly to it (the same for pbrun, pfexec or other supported methods). - -Privilege escalation must be general ------------------------------------- - -You cannot limit privilege escalation permissions to certain commands. -Ansible does not always -use a specific command to do something but runs modules (code) from -a temporary file name which changes every time. If you have '/sbin/service' -or '/bin/chmod' as the allowed commands this will fail with ansible as those -paths won't match with the temporary file that Ansible creates to run the -module. If you have security rules that constrain your sudo/pbrun/doas environment -to running specific command paths only, use Ansible from a special account that -does not have this constraint, or use AWX or the :ref:`ansible_platform` to manage indirect access to SSH credentials. - -May not access environment variables populated by pamd_systemd --------------------------------------------------------------- - -For most Linux distributions using ``systemd`` as their init, the default -methods used by ``become`` do not open a new "session", in the sense of -systemd. Because the ``pam_systemd`` module will not fully initialize a new -session, you might have surprises compared to a normal session opened through -ssh: some environment variables set by ``pam_systemd``, most notably -``XDG_RUNTIME_DIR``, are not populated for the new user and instead inherited -or just emptied. - -This might cause trouble when trying to invoke systemd commands that depend on -``XDG_RUNTIME_DIR`` to access the bus: - -.. code-block:: console - - $ echo $XDG_RUNTIME_DIR - - $ systemctl --user status - Failed to connect to bus: Permission denied - -To force ``become`` to open a new systemd session that goes through -``pam_systemd``, you can use ``become_method: machinectl``. - -For more information, see `this systemd issue -`_. - -Resolving Temporary File Error Messsages ----------------------------------------- - -* Failed to set permissions on the temporary files Ansible needs to create when becoming an unprivileged user" -* This error can be resolved by installing the package that provides the ``setfacl`` command. (This is frequently the ``acl`` package but check your OS documentation.) - -.. _become_network: - -Become and network automation -============================= - -As of version 2.6, Ansible supports ``become`` for privilege escalation (entering ``enable`` mode or privileged EXEC mode) on all Ansible-maintained network platforms that support ``enable`` mode. Using ``become`` replaces the ``authorize`` and ``auth_pass`` options in a ``provider`` dictionary. - -You must set the connection type to either ``connection: ansible.netcommon.network_cli`` or ``connection: ansible.netcommon.httpapi`` to use ``become`` for privilege escalation on network devices. Check the :ref:`platform_options` documentation for details. - -You can use escalated privileges on only the specific tasks that need them, on an entire play, or on all plays. Adding ``become: true`` and ``become_method: enable`` instructs Ansible to enter ``enable`` mode before executing the task, play, or playbook where those parameters are set. - -If you see this error message, the task that generated it requires ``enable`` mode to succeed: - -.. code-block:: console - - Invalid input (privileged mode required) - -To set ``enable`` mode for a specific task, add ``become`` at the task level: - -.. code-block:: yaml - - - name: Gather facts (eos) - arista.eos.eos_facts: - gather_subset: - - "!hardware" - become: true - become_method: enable - -To set enable mode for all tasks in a single play, add ``become`` at the play level: - -.. code-block:: yaml - - - hosts: eos-switches - become: true - become_method: enable - tasks: - - name: Gather facts (eos) - arista.eos.eos_facts: - gather_subset: - - "!hardware" - -Setting enable mode for all tasks ---------------------------------- - -Often you wish for all tasks in all plays to run using privilege mode, that is best achieved by using ``group_vars``: - -**group_vars/eos.yml** - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: arista.eos.eos - ansible_user: myuser - ansible_become: true - ansible_become_method: enable - -Passwords for enable mode -^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you need a password to enter ``enable`` mode, you can specify it in one of two ways: - -* providing the :option:`--ask-become-pass ` command line option -* setting the ``ansible_become_password`` connection variable - -.. warning:: - - As a reminder passwords should never be stored in plain text. For information on encrypting your passwords and other secrets with Ansible Vault, see :ref:`vault`. - -authorize and auth_pass ------------------------ - -Ansible still supports ``enable`` mode with ``connection: local`` for legacy network playbooks. To enter ``enable`` mode with ``connection: local``, use the module options ``authorize`` and ``auth_pass``: - -.. code-block:: yaml - - - hosts: eos-switches - ansible_connection: local - tasks: - - name: Gather facts (eos) - eos_facts: - gather_subset: - - "!hardware" - provider: - authorize: true - auth_pass: " {{ secret_auth_pass }}" - -We recommend updating your playbooks to use ``become`` for network-device ``enable`` mode consistently. The use of ``authorize`` and of ``provider`` dictionaries will be deprecated in future. Check the :ref:`platform_options` documentation for details. - -.. _become_windows: - -Become and Windows -================== - -Since Ansible 2.3, ``become`` can be used on Windows hosts through the -``runas`` method. Become on Windows uses the same inventory setup and -invocation arguments as ``become`` on a non-Windows host, so the setup and -variable names are the same as what is defined in this document with the exception -of ``become_user``. As there is no sensible default for ``become_user`` on Windows -it is required when using ``become``. See :ref:`ansible.builtin.runas become plugin ` for details. - -While ``become`` can be used to assume the identity of another user, there are other uses for -it with Windows hosts. One important use is to bypass some of the -limitations that are imposed when running on WinRM, such as constrained network -delegation or accessing forbidden system calls like the WUA API. You can use -``become`` with the same user as ``ansible_user`` to bypass these limitations -and run commands that are not normally accessible in a WinRM session. - -.. Note:: - On Windows you cannot connect with an underprivileged account and use become - to elevate your rights. Become can only be used if your connection account - is already an Administrator of the target host. - -Administrative rights ---------------------- - -Many tasks in Windows require administrative privileges to complete. When using -the ``runas`` become method, Ansible will attempt to run the module with the -full privileges that are available to the become user. If it fails to elevate -the user token, it will continue to use the limited token during execution. - -A user must have the ``SeDebugPrivilege`` to run a become process with elevated -privileges. This privilege is assigned to Administrators by default. If the -debug privilege is not available, the become process will run with a limited -set of privileges and groups. - -To determine the type of token that Ansible was able to get, run the following -task: - -.. code-block:: yaml - - - Check my user name - ansible.windows.win_whoami: - become: true - -The output will look something similar to the below: - -.. code-block:: ansible-output - - ok: [windows] => { - "account": { - "account_name": "vagrant-domain", - "domain_name": "DOMAIN", - "sid": "S-1-5-21-3088887838-4058132883-1884671576-1105", - "type": "User" - }, - "authentication_package": "Kerberos", - "changed": false, - "dns_domain_name": "DOMAIN.LOCAL", - "groups": [ - { - "account_name": "Administrators", - "attributes": [ - "Mandatory", - "Enabled by default", - "Enabled", - "Owner" - ], - "domain_name": "BUILTIN", - "sid": "S-1-5-32-544", - "type": "Alias" - }, - { - "account_name": "INTERACTIVE", - "attributes": [ - "Mandatory", - "Enabled by default", - "Enabled" - ], - "domain_name": "NT AUTHORITY", - "sid": "S-1-5-4", - "type": "WellKnownGroup" - }, - ], - "impersonation_level": "SecurityAnonymous", - "label": { - "account_name": "High Mandatory Level", - "domain_name": "Mandatory Label", - "sid": "S-1-16-12288", - "type": "Label" - }, - "login_domain": "DOMAIN", - "login_time": "2018-11-18T20:35:01.9696884+00:00", - "logon_id": 114196830, - "logon_server": "DC01", - "logon_type": "Interactive", - "privileges": { - "SeBackupPrivilege": "disabled", - "SeChangeNotifyPrivilege": "enabled-by-default", - "SeCreateGlobalPrivilege": "enabled-by-default", - "SeCreatePagefilePrivilege": "disabled", - "SeCreateSymbolicLinkPrivilege": "disabled", - "SeDebugPrivilege": "enabled", - "SeDelegateSessionUserImpersonatePrivilege": "disabled", - "SeImpersonatePrivilege": "enabled-by-default", - "SeIncreaseBasePriorityPrivilege": "disabled", - "SeIncreaseQuotaPrivilege": "disabled", - "SeIncreaseWorkingSetPrivilege": "disabled", - "SeLoadDriverPrivilege": "disabled", - "SeManageVolumePrivilege": "disabled", - "SeProfileSingleProcessPrivilege": "disabled", - "SeRemoteShutdownPrivilege": "disabled", - "SeRestorePrivilege": "disabled", - "SeSecurityPrivilege": "disabled", - "SeShutdownPrivilege": "disabled", - "SeSystemEnvironmentPrivilege": "disabled", - "SeSystemProfilePrivilege": "disabled", - "SeSystemtimePrivilege": "disabled", - "SeTakeOwnershipPrivilege": "disabled", - "SeTimeZonePrivilege": "disabled", - "SeUndockPrivilege": "disabled" - }, - "rights": [ - "SeNetworkLogonRight", - "SeBatchLogonRight", - "SeInteractiveLogonRight", - "SeRemoteInteractiveLogonRight" - ], - "token_type": "TokenPrimary", - "upn": "vagrant-domain@DOMAIN.LOCAL", - "user_flags": [] - } - -Under the ``label`` key, the ``account_name`` entry determines whether the user -has Administrative rights. Here are the labels that can be returned and what -they represent: - -* ``Medium``: Ansible failed to get an elevated token and ran under a limited - token. Only a subset of the privileges assigned to user are available during - the module execution and the user does not have administrative rights. - -* ``High``: An elevated token was used and all the privileges assigned to the - user are available during the module execution. - -* ``System``: The ``NT AUTHORITY\System`` account is used and has the highest - level of privileges available. - -The output will also show the list of privileges that have been granted to the -user. When the privilege value is ``disabled``, the privilege is assigned to -the logon token but has not been enabled. In most scenarios these privileges -are automatically enabled when required. - -If running on a version of Ansible that is older than 2.5 or the normal -``runas`` escalation process fails, an elevated token can be retrieved by: - -* Set the ``become_user`` to ``System`` which has full control over the - operating system. - -* Grant ``SeTcbPrivilege`` to the user Ansible connects with on - WinRM. ``SeTcbPrivilege`` is a high-level privilege that grants - full control over the operating system. No user is given this privilege by - default, and care should be taken if you grant this privilege to a user or group. - For more information on this privilege, please see - `Act as part of the operating system `_. - You can use the below task to set this privilege on a Windows host: - - .. code-block:: yaml - - - name: grant the ansible user the SeTcbPrivilege right - ansible.windows.win_user_right: - name: SeTcbPrivilege - users: '{{ansible_user}}' - action: add - -* Turn UAC off on the host and reboot before trying to become the user. UAC is - a security protocol that is designed to run accounts with the - ``least privilege`` principle. You can turn UAC off by running the following - tasks: - - .. code-block:: yaml - - - name: turn UAC off - win_regedit: - path: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system - name: EnableLUA - data: 0 - type: dword - state: present - register: uac_result - - - name: reboot after disabling UAC - win_reboot: - when: uac_result is changed - -.. Note:: Granting the ``SeTcbPrivilege`` or turning UAC off can cause Windows - security vulnerabilities and care should be given if these steps are taken. - -Local service accounts ----------------------- - -Prior to Ansible version 2.5, ``become`` only worked on Windows with a local or domain -user account. Local service accounts like ``System`` or ``NetworkService`` -could not be used as ``become_user`` in these older versions. This restriction -has been lifted since the 2.5 release of Ansible. The three service accounts -that can be set under ``become_user`` are: - -* System -* NetworkService -* LocalService - -Because local service accounts do not have passwords, the -``ansible_become_password`` parameter is not required and is ignored if -specified. - -Become without setting a password ---------------------------------- - -As of Ansible 2.8, ``become`` can be used to become a Windows local or domain account -without requiring a password for that account. For this method to work, the -following requirements must be met: - -* The connection user has the ``SeDebugPrivilege`` privilege assigned -* The connection user is part of the ``BUILTIN\Administrators`` group -* The ``become_user`` has either the ``SeBatchLogonRight`` or ``SeNetworkLogonRight`` user right - -Using become without a password is achieved in one of two different methods: - -* Duplicating an existing logon session's token if the account is already logged on -* Using S4U to generate a logon token that is valid on the remote host only - -In the first scenario, the become process is spawned from another logon of that -user account. This could be an existing RDP logon, console logon, but this is -not guaranteed to occur all the time. This is similar to the -``Run only when user is logged on`` option for a Scheduled Task. - -In the case where another logon of the become account does not exist, S4U is -used to create a new logon and run the module through that. This is similar to -the ``Run whether user is logged on or not`` with the ``Do not store password`` -option for a Scheduled Task. In this scenario, the become process will not be -able to access any network resources like a normal WinRM process. - -To make a distinction between using become with no password and becoming an -account that has no password make sure to keep ``ansible_become_password`` as -undefined or set ``ansible_become_password:``. - -.. Note:: Because there are no guarantees an existing token will exist for a - user when Ansible runs, there's a high change the become process will only - have access to local resources. Use become with a password if the task needs - to access network resources - -Accounts without a password ---------------------------- - -.. Warning:: As a general security best practice, you should avoid allowing accounts without passwords. - -Ansible can be used to become a Windows account that does not have a password (like the -``Guest`` account). To become an account without a password, set up the -variables like normal but set ``ansible_become_password: ''``. - -Before become can work on an account like this, the local policy -`Accounts: Limit local account use of blank passwords to console logon only `_ -must be disabled. This can either be done through a Group Policy Object (GPO) -or with this Ansible task: - -.. code-block:: yaml - - - name: allow blank password on become - ansible.windows.win_regedit: - path: HKLM:\SYSTEM\CurrentControlSet\Control\Lsa - name: LimitBlankPasswordUse - data: 0 - type: dword - state: present - -.. Note:: This is only for accounts that do not have a password. You still need - to set the account's password under ``ansible_become_password`` if the - become_user has a password. - -Become flags for Windows ------------------------- - -Ansible 2.5 added the ``become_flags`` parameter to the ``runas`` become method. -This parameter can be set using the ``become_flags`` task directive or set in -Ansible's configuration using ``ansible_become_flags``. The two valid values -that are initially supported for this parameter are ``logon_type`` and -``logon_flags``. - -.. Note:: These flags should only be set when becoming a normal user account, not a local service account like LocalSystem. - -The key ``logon_type`` sets the type of logon operation to perform. The value -can be set to one of the following: - -* ``interactive``: The default logon type. The process will be run under a - context that is the same as when running a process locally. This bypasses all - WinRM restrictions and is the recommended method to use. - -* ``batch``: Runs the process under a batch context that is similar to a - scheduled task with a password set. This should bypass most WinRM - restrictions and is useful if the ``become_user`` is not allowed to log on - interactively. - -* ``new_credentials``: Runs under the same credentials as the calling user, but - outbound connections are run under the context of the ``become_user`` and - ``become_password``, similar to ``runas.exe /netonly``. The ``logon_flags`` - flag should also be set to ``netcredentials_only``. Use this flag if - the process needs to access a network resource (like an SMB share) using a - different set of credentials. - -* ``network``: Runs the process under a network context without any cached - credentials. This results in the same type of logon session as running a - normal WinRM process without credential delegation, and operates under the same - restrictions. - -* ``network_cleartext``: Like the ``network`` logon type, but instead caches - the credentials so it can access network resources. This is the same type of - logon session as running a normal WinRM process with credential delegation. - -For more information, see -`dwLogonType `_. - -The ``logon_flags`` key specifies how Windows will log the user on when creating -the new process. The value can be set to none or multiple of the following: - -* ``with_profile``: The default logon flag set. The process will load the - user's profile in the ``HKEY_USERS`` registry key to ``HKEY_CURRENT_USER``. - -* ``netcredentials_only``: The process will use the same token as the caller - but will use the ``become_user`` and ``become_password`` when accessing a remote - resource. This is useful in inter-domain scenarios where there is no trust - relationship, and should be used with the ``new_credentials`` ``logon_type``. - -By default ``logon_flags=with_profile`` is set, if the profile should not be -loaded set ``logon_flags=`` or if the profile should be loaded with -``netcredentials_only``, set ``logon_flags=with_profile,netcredentials_only``. - -For more information, see `dwLogonFlags `_. - -Here are some examples of how to use ``become_flags`` with Windows tasks: - -.. code-block:: yaml - - - name: copy a file from a fileshare with custom credentials - ansible.windows.win_copy: - src: \\server\share\data\file.txt - dest: C:\temp\file.txt - remote_src: true - vars: - ansible_become: true - ansible_become_method: runas - ansible_become_user: DOMAIN\user - ansible_become_password: Password01 - ansible_become_flags: logon_type=new_credentials logon_flags=netcredentials_only - - - name: run a command under a batch logon - ansible.windows.win_whoami: - become: true - become_flags: logon_type=batch - - - name: run a command and not load the user profile - ansible.windows.win_whomai: - become: true - become_flags: logon_flags= - - -Limitations of become on Windows --------------------------------- - -* Running a task with ``async`` and ``become`` on Windows Server 2008, 2008 R2 - and Windows 7 only works when using Ansible 2.7 or newer. - -* By default, the become user logs on with an interactive session, so it must - have the right to do so on the Windows host. If it does not inherit the - ``SeAllowLogOnLocally`` privilege or inherits the ``SeDenyLogOnLocally`` - privilege, the become process will fail. Either add the privilege or set the - ``logon_type`` flag to change the logon type used. - -* Prior to Ansible version 2.3, become only worked when - ``ansible_winrm_transport`` was either ``basic`` or ``credssp``. This - restriction has been lifted since the 2.4 release of Ansible for all hosts - except Windows Server 2008 (non R2 version). - -* The Secondary Logon service ``seclogon`` must be running to use ``ansible_become_method: runas`` - -* The connection user must already be an Administrator on the Windows host to - use ``runas``. The target become user does not need to be an Administrator - though. - - -.. seealso:: - - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_prompts.rst b/docs/docsite/rst/playbook_guide/playbooks_prompts.rst deleted file mode 100644 index 6f7abc9d001..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_prompts.rst +++ /dev/null @@ -1,124 +0,0 @@ -.. _playbooks_prompts: - -************************** -Interactive input: prompts -************************** - -If you want your playbook to prompt the user for certain input, add a 'vars_prompt' section. Prompting the user for variables lets you avoid recording sensitive data like passwords. In addition to security, prompts support flexibility. For example, if you use one playbook across multiple software releases, you could prompt for the particular release version. - -.. contents:: - :local: - -Here is a most basic example: - -.. code-block:: yaml - - --- - - hosts: all - vars_prompt: - - - name: username - prompt: What is your username? - private: false - - - name: password - prompt: What is your password? - - tasks: - - - name: Print a message - ansible.builtin.debug: - msg: 'Logging in as {{ username }}' - -The user input is hidden by default but it can be made visible by setting ``private: false``. - -.. note:: - Prompts for individual ``vars_prompt`` variables will be skipped for any variable that is already defined through the command line ``--extra-vars`` option, or when running from a non-interactive session (such as cron or Ansible AWX). See :ref:`passing_variables_on_the_command_line`. - -If you have a variable that changes infrequently, you can provide a default value that can be overridden. - -.. code-block:: yaml - - vars_prompt: - - - name: release_version - prompt: Product release version - default: "1.0" - -Hashing values supplied by ``vars_prompt`` ------------------------------------------- - -You can hash the entered value so you can use it, for instance, with the user module to define a password: - -.. code-block:: yaml - - vars_prompt: - - - name: my_password2 - prompt: Enter password2 - private: true - encrypt: sha512_crypt - confirm: true - salt_size: 7 - -If you have `Passlib `_ installed, you can use any crypt scheme the library supports: - -- *des_crypt* - DES Crypt -- *bsdi_crypt* - BSDi Crypt -- *bigcrypt* - BigCrypt -- *crypt16* - Crypt16 -- *md5_crypt* - MD5 Crypt -- *bcrypt* - BCrypt -- *sha1_crypt* - SHA-1 Crypt -- *sun_md5_crypt* - Sun MD5 Crypt -- *sha256_crypt* - SHA-256 Crypt -- *sha512_crypt* - SHA-512 Crypt -- *apr_md5_crypt* - Apache's MD5-Crypt variant -- *phpass* - PHPass' Portable Hash -- *pbkdf2_digest* - Generic PBKDF2 Hashes -- *cta_pbkdf2_sha1* - Cryptacular's PBKDF2 hash -- *dlitz_pbkdf2_sha1* - Dwayne Litzenberger's PBKDF2 hash -- *scram* - SCRAM Hash -- *bsd_nthash* - FreeBSD's MCF-compatible nthash encoding - -The only parameters accepted are 'salt' or 'salt_size'. You can use your own salt by defining -'salt', or have one generated automatically using 'salt_size'. By default Ansible generates a salt -of size 8. - -.. versionadded:: 2.7 - -If you do not have Passlib installed, Ansible uses the `crypt `_ library as a fallback. Ansible supports at most four crypt schemes, depending on your platform at most the following crypt schemes are supported: - -- *bcrypt* - BCrypt -- *md5_crypt* - MD5 Crypt -- *sha256_crypt* - SHA-256 Crypt -- *sha512_crypt* - SHA-512 Crypt - -.. versionadded:: 2.8 -.. _unsafe_prompts: - -Allowing special characters in ``vars_prompt`` values ------------------------------------------------------ - -Some special characters, such as ``{`` and ``%`` can create templating errors. If you need to accept special characters, use the ``unsafe`` option: - -.. code-block:: yaml - - vars_prompt: - - name: my_password_with_weird_chars - prompt: Enter password - unsafe: true - private: true - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_variables` - All about variables - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_python_version.rst b/docs/docsite/rst/playbook_guide/playbooks_python_version.rst deleted file mode 100644 index ee18b60713e..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_python_version.rst +++ /dev/null @@ -1,68 +0,0 @@ -.. _pb-py-compat: - -******************** -Python3 in templates -******************** - -Ansible uses Jinja2 to take advantage of Python data types and standard functions in templates and variables. -You can use these data types and standard functions to perform a rich set of operations on your data. However, -if you use templates, you must be aware of differences between Python versions. - -These topics help you design templates that work on both Python2 and Python3. They might also help if you are upgrading from Python2 to Python3. Upgrading within Python2 or Python3 does not usually introduce changes that affect Jinja2 templates. - -.. _pb-py-compat-dict-views: - -Dictionary views -================ - -In Python2, the :meth:`dict.keys`, :meth:`dict.values`, and :meth:`dict.items` -methods return a list. Jinja2 returns that to Ansible using a string -representation that Ansible can turn back into a list. - -In Python3, those methods return a :ref:`dictionary view ` object. The -string representation that Jinja2 returns for dictionary views cannot be parsed back -into a list by Ansible. It is, however, easy to make this portable by -using the :func:`list ` filter whenever using :meth:`dict.keys`, -:meth:`dict.values`, or :meth:`dict.items`. - -.. code-block:: yaml+jinja - - vars: - hosts: - testhost1: 127.0.0.2 - testhost2: 127.0.0.3 - tasks: - - debug: - msg: '{{ item }}' - # Only works with Python 2 - #loop: "{{ hosts.keys() }}" - # Works with both Python 2 and Python 3 - loop: "{{ hosts.keys() | list }}" - -.. _pb-py-compat-iteritems: - -dict.iteritems() -================ - -Python2 dictionaries have :meth:`~dict.iterkeys`, :meth:`~dict.itervalues`, and :meth:`~dict.iteritems` methods. - -Python3 dictionaries do not have these methods. Use :meth:`dict.keys`, :meth:`dict.values`, and :meth:`dict.items` to make your playbooks and templates compatible with both Python2 and Python3. - -.. code-block:: yaml+jinja - - vars: - hosts: - testhost1: 127.0.0.2 - testhost2: 127.0.0.3 - tasks: - - debug: - msg: '{{ item }}' - # Only works with Python 2 - #loop: "{{ hosts.iteritems() }}" - # Works with both Python 2 and Python 3 - loop: "{{ hosts.items() | list }}" - -.. seealso:: - * The :ref:`pb-py-compat-dict-views` entry for information on - why the :func:`list filter ` is necessary - here. diff --git a/docs/docsite/rst/playbook_guide/playbooks_reuse.rst b/docs/docsite/rst/playbook_guide/playbooks_reuse.rst deleted file mode 100644 index 89cc5a42161..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_reuse.rst +++ /dev/null @@ -1,226 +0,0 @@ -.. _playbooks_reuse: - -************************** -Re-using Ansible artifacts -************************** - -You can write a simple playbook in one very large file, and most users learn the one-file approach first. However, breaking your automation work up into smaller files is an excellent way to organize complex sets of tasks and reuse them. Smaller, more distributed artifacts let you re-use the same variables, tasks, and plays in multiple playbooks to address different use cases. You can use distributed artifacts across multiple parent playbooks or even multiple times within one playbook. For example, you might want to update your customer database as part of several different playbooks. If you put all the tasks related to updating your database in a tasks file or a role, you can re-use them in many playbooks while only maintaining them in one place. - -.. contents:: - :local: - -Creating re-usable files and roles -================================== - -Ansible offers four distributed, re-usable artifacts: variables files, task files, playbooks, and roles. - - - A variables file contains only variables. - - A task file contains only tasks. - - A playbook contains at least one play, and may contain variables, tasks, and other content. You can re-use tightly focused playbooks, but you can only re-use them statically, not dynamically. - - A role contains a set of related tasks, variables, defaults, handlers, and even modules or other plugins in a defined file-tree. Unlike variables files, task files, or playbooks, roles can be easily uploaded and shared through Ansible Galaxy. See :ref:`playbooks_reuse_roles` for details about creating and using roles. - -.. versionadded:: 2.4 - -Re-using playbooks -================== - -You can incorporate multiple playbooks into a main playbook. However, you can only use imports to re-use playbooks. For example: - -.. code-block:: yaml - - - import_playbook: webservers.yml - - import_playbook: databases.yml - -Importing incorporates playbooks in other playbooks statically. Ansible runs the plays and tasks in each imported playbook in the order they are listed, just as if they had been defined directly in the main playbook. - -You can select which playbook you want to import at runtime by defining your imported playbook filename with a variable, then passing the variable with either ``--extra-vars`` or the ``vars`` keyword. For example: - -.. code-block:: yaml - - - import_playbook: "/path/to/{{ import_from_extra_var }}" - - import_playbook: "{{ import_from_vars }}" - vars: - import_from_vars: /path/to/one_playbook.yml - -If you run this playbook with ``ansible-playbook my_playbook -e import_from_extra_var=other_playbook.yml``, Ansible imports both one_playbook.yml and other_playbook.yml. - -When to turn a playbook into a role -=================================== - -For some use cases, simple playbooks work well. However, starting at a certain level of complexity, roles work better than playbooks. A role lets you store your defaults, handlers, variables, and tasks in separate directories, instead of in a single long document. Roles are easy to share on Ansible Galaxy. For complex use cases, most users find roles easier to read, understand, and maintain than all-in-one playbooks. - -Re-using files and roles -======================== - -Ansible offers two ways to re-use files and roles in a playbook: dynamic and static. - - - For dynamic re-use, add an ``include_*`` task in the tasks section of a play: - - - :ref:`include_role ` - - :ref:`include_tasks ` - - :ref:`include_vars ` - - - For static re-use, add an ``import_*`` task in the tasks section of a play: - - - :ref:`import_role ` - - :ref:`import_tasks ` - -Task include and import statements can be used at arbitrary depth. - -You can still use the bare :ref:`roles ` keyword at the play level to incorporate a role in a playbook statically. However, the bare :ref:`include ` keyword, once used for both task files and playbook-level includes, is now deprecated. - -Includes: dynamic re-use ------------------------- - -Including roles, tasks, or variables adds them to a playbook dynamically. Ansible processes included files and roles as they come up in a playbook, so included tasks can be affected by the results of earlier tasks within the top-level playbook. Included roles and tasks are similar to handlers - they may or may not run, depending on the results of other tasks in the top-level playbook. - -The primary advantage of using ``include_*`` statements is looping. When a loop is used with an include, the included tasks or role will be executed once for each item in the loop. - -The filenames for included roles, tasks, and vars are templated before inclusion. - -You can pass variables into includes. See :ref:`ansible_variable_precedence` for more details on variable inheritance and precedence. - -Imports: static re-use ----------------------- - -Importing roles, tasks, or playbooks adds them to a playbook statically. Ansible pre-processes imported files and roles before it runs any tasks in a playbook, so imported content is never affected by other tasks within the top-level playbook. - -The filenames for imported roles and tasks support templating, but the variables must be available when Ansible is pre-processing the imports. This can be done with the ``vars`` keyword or by using ``--extra-vars``. - -You can pass variables to imports. You must pass variables if you want to run an imported file more than once in a playbook. For example: - -.. code-block:: yaml - - tasks: - - import_tasks: wordpress.yml - vars: - wp_user: timmy - - - import_tasks: wordpress.yml - vars: - wp_user: alice - - - import_tasks: wordpress.yml - vars: - wp_user: bob - -See :ref:`ansible_variable_precedence` for more details on variable inheritance and precedence. - -.. _dynamic_vs_static: - -Comparing includes and imports: dynamic and static re-use ------------------------------------------------------------- - -Each approach to re-using distributed Ansible artifacts has advantages and limitations. You may choose dynamic re-use for some playbooks and static re-use for others. Although you can use both dynamic and static re-use in a single playbook, it is best to select one approach per playbook. Mixing static and dynamic re-use can introduce difficult-to-diagnose bugs into your playbooks. This table summarizes the main differences so you can choose the best approach for each playbook you create. - -.. table:: - :class: documentation-table - - ========================= ======================================== ======================================== - .. Include_* Import_* - ========================= ======================================== ======================================== - Type of re-use Dynamic Static - - When processed At runtime, when encountered Pre-processed during playbook parsing - - Task or play All includes are tasks ``import_playbook`` cannot be a task - - Task options Apply only to include task itself Apply to all child tasks in import - - Calling from loops Executed once for each loop item Cannot be used in a loop - - Using ``--list-tags`` Tags within includes not listed All tags appear with ``--list-tags`` - - Using ``--list-tasks`` Tasks within includes not listed All tasks appear with ``--list-tasks`` - - Notifying handlers Cannot trigger handlers within includes Can trigger individual imported handlers - - Using ``--start-at-task`` Cannot start at tasks within includes Can start at imported tasks - - Using inventory variables Can ``include_*: {{ inventory_var }}`` Cannot ``import_*: {{ inventory_var }}`` - - With playbooks No ``include_playbook`` Can import full playbooks - - With variables files Can include variables files Use ``vars_files:`` to import variables - - ========================= ======================================== ======================================== - - -.. note:: - * There are also big differences in resource consumption and performance, imports are quite lean and fast, while includes require a lot of management - and accounting. - -Re-using tasks as handlers -========================== - -You can also use includes and imports in the :ref:`handlers` section of a playbook. For instance, if you want to define how to restart Apache, you only have to do that once for all of your playbooks. You might make a ``restarts.yml`` file that looks like: - -.. code-block:: yaml - - # restarts.yml - - name: Restart apache - ansible.builtin.service: - name: apache - state: restarted - - - name: Restart mysql - ansible.builtin.service: - name: mysql - state: restarted - -You can trigger handlers from either an import or an include, but the procedure is different for each method of re-use. If you include the file, you must notify the include itself, which triggers all the tasks in ``restarts.yml``. If you import the file, you must notify the individual task(s) within ``restarts.yml``. You can mix direct tasks and handlers with included or imported tasks and handlers. - -Triggering included (dynamic) handlers --------------------------------------- - -Includes are executed at run-time, so the name of the include exists during play execution, but the included tasks do not exist until the include itself is triggered. To use the ``Restart apache`` task with dynamic re-use, refer to the name of the include itself. This approach triggers all tasks in the included file as handlers. For example, with the task file shown above: - -.. code-block:: yaml - - - name: Trigger an included (dynamic) handler - hosts: localhost - handlers: - - name: Restart services - include_tasks: restarts.yml - tasks: - - command: "true" - notify: Restart services - -Triggering imported (static) handlers -------------------------------------- - -Imports are processed before the play begins, so the name of the import no longer exists during play execution, but the names of the individual imported tasks do exist. To use the ``Restart apache`` task with static re-use, refer to the name of each task or tasks within the imported file. For example, with the task file shown above: - -.. code-block:: yaml - - - name: Trigger an imported (static) handler - hosts: localhost - handlers: - - name: Restart services - import_tasks: restarts.yml - tasks: - - command: "true" - notify: Restart apache - - command: "true" - notify: Restart mysql - -.. seealso:: - - :ref:`utilities_modules` - Documentation of the ``include*`` and ``import*`` modules discussed here. - :ref:`working_with_playbooks` - Review the basic Playbook language features - :ref:`playbooks_variables` - All about variables in playbooks - :ref:`playbooks_conditionals` - Conditionals in playbooks - :ref:`playbooks_loops` - Loops in playbooks - :ref:`tips_and_tricks` - Tips and tricks for playbooks - :ref:`ansible_galaxy` - How to share roles on galaxy, role management - `GitHub Ansible examples `_ - Complete playbook files from the GitHub project source - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups diff --git a/docs/docsite/rst/playbook_guide/playbooks_reuse_roles.rst b/docs/docsite/rst/playbook_guide/playbooks_reuse_roles.rst deleted file mode 100644 index 99ca2bf1240..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_reuse_roles.rst +++ /dev/null @@ -1,615 +0,0 @@ -.. _playbooks_reuse_roles: - -***** -Roles -***** - -Roles let you automatically load related vars, files, tasks, handlers, and other Ansible artifacts based on a known file structure. After you group your content in roles, you can easily reuse them and share them with other users. - -.. contents:: - :local: - -Role directory structure -======================== - -An Ansible role has a defined directory structure with eight main standard directories. You must include at least one of these directories in each role. You can omit any directories the role does not use. For example: - -.. code-block:: text - - # playbooks - site.yml - webservers.yml - fooservers.yml -.. include:: shared_snippets/role_directory.txt - - -By default Ansible will look in each directory within a role for a ``main.yml`` file for relevant content (also ``main.yaml`` and ``main``): - -- ``tasks/main.yml`` - the main list of tasks that the role executes. -- ``handlers/main.yml`` - handlers, which may be used within or outside this role. -- ``library/my_module.py`` - modules, which may be used within this role (see :ref:`embedding_modules_and_plugins_in_roles` for more information). -- ``defaults/main.yml`` - default variables for the role (see :ref:`playbooks_variables` for more information). These variables have the lowest priority of any variables available, and can be easily overridden by any other variable, including inventory variables. -- ``vars/main.yml`` - other variables for the role (see :ref:`playbooks_variables` for more information). -- ``files/main.yml`` - files that the role deploys. -- ``templates/main.yml`` - templates that the role deploys. -- ``meta/main.yml`` - metadata for the role, including role dependencies and optional Galaxy metadata such as platforms supported. - -You can add other YAML files in some directories. For example, you can place platform-specific tasks in separate files and refer to them in the ``tasks/main.yml`` file: - -.. code-block:: yaml - - # roles/example/tasks/main.yml - - name: Install the correct web server for RHEL - import_tasks: redhat.yml - when: ansible_facts['os_family']|lower == 'redhat' - - - name: Install the correct web server for Debian - import_tasks: debian.yml - when: ansible_facts['os_family']|lower == 'debian' - - # roles/example/tasks/redhat.yml - - name: Install web server - ansible.builtin.yum: - name: "httpd" - state: present - - # roles/example/tasks/debian.yml - - name: Install web server - ansible.builtin.apt: - name: "apache2" - state: present - -Roles may also include modules and other plugin types in a directory called ``library``. For more information, please refer to :ref:`embedding_modules_and_plugins_in_roles` below. - -.. _role_search_path: - -Storing and finding roles -========================= - -By default, Ansible looks for roles in the following locations: - -- in collections, if you are using them -- in a directory called ``roles/``, relative to the playbook file -- in the configured :ref:`roles_path `. The default search path is ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles``. -- in the directory where the playbook file is located - -If you store your roles in a different location, set the :ref:`roles_path ` configuration option so Ansible can find your roles. Checking shared roles into a single location makes them easier to use in multiple playbooks. See :ref:`intro_configuration` for details about managing settings in ansible.cfg. - -Alternatively, you can call a role with a fully qualified path: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - role: '/path/to/my/roles/common' - -Using roles -=========== - -You can use roles in three ways: - -- at the play level with the ``roles`` option: This is the classic way of using roles in a play. -- at the tasks level with ``include_role``: You can reuse roles dynamically anywhere in the ``tasks`` section of a play using ``include_role``. -- at the tasks level with ``import_role``: You can reuse roles statically anywhere in the ``tasks`` section of a play using ``import_role``. - -.. _roles_keyword: - -Using roles at the play level ------------------------------ - -The classic (original) way to use roles is with the ``roles`` option for a given play: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - common - - webservers - -When you use the ``roles`` option at the play level, for each role 'x': - -- If roles/x/tasks/main.yml exists, Ansible adds the tasks in that file to the play. -- If roles/x/handlers/main.yml exists, Ansible adds the handlers in that file to the play. -- If roles/x/vars/main.yml exists, Ansible adds the variables in that file to the play. -- If roles/x/defaults/main.yml exists, Ansible adds the variables in that file to the play. -- If roles/x/meta/main.yml exists, Ansible adds any role dependencies in that file to the list of roles. -- Any copy, script, template or include tasks (in the role) can reference files in roles/x/{files,templates,tasks}/ (dir depends on task) without having to path them relatively or absolutely. - -When you use the ``roles`` option at the play level, Ansible treats the roles as static imports and processes them during playbook parsing. Ansible executes each play in this order: - -- Any ``pre_tasks`` defined in the play. -- Any handlers triggered by pre_tasks. -- Each role listed in ``roles:``, in the order listed. Any role dependencies defined in the role's ``meta/main.yml`` run first, subject to tag filtering and conditionals. See :ref:`role_dependencies` for more details. -- Any ``tasks`` defined in the play. -- Any handlers triggered by the roles or tasks. -- Any ``post_tasks`` defined in the play. -- Any handlers triggered by post_tasks. - -.. note:: - If using tags with tasks in a role, be sure to also tag your pre_tasks, post_tasks, and role dependencies and pass those along as well, especially if the pre/post tasks and role dependencies are used for monitoring outage window control or load balancing. See :ref:`tags` for details on adding and using tags. - -You can pass other keywords to the ``roles`` option: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - common - - role: foo_app_instance - vars: - dir: '/opt/a' - app_port: 5000 - tags: typeA - - role: foo_app_instance - vars: - dir: '/opt/b' - app_port: 5001 - tags: typeB - -When you add a tag to the ``role`` option, Ansible applies the tag to ALL tasks within the role. - -When using ``vars:`` within the ``roles:`` section of a playbook, the variables are added to the play variables, making them available to all tasks within the play before and after the role. This behavior can be changed by :ref:`DEFAULT_PRIVATE_ROLE_VARS`. - -Including roles: dynamic reuse ------------------------------- - -You can reuse roles dynamically anywhere in the ``tasks`` section of a play using ``include_role``. While roles added in a ``roles`` section run before any other tasks in a play, included roles run in the order they are defined. If there are other tasks before an ``include_role`` task, the other tasks will run first. - -To include a role: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Print a message - ansible.builtin.debug: - msg: "this task runs before the example role" - - - name: Include the example role - include_role: - name: example - - - name: Print a message - ansible.builtin.debug: - msg: "this task runs after the example role" - -You can pass other keywords, including variables and tags, when including roles: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Include the foo_app_instance role - include_role: - name: foo_app_instance - vars: - dir: '/opt/a' - app_port: 5000 - tags: typeA - ... - -When you add a :ref:`tag ` to an ``include_role`` task, Ansible applies the tag `only` to the include itself. This means you can pass ``--tags`` to run only selected tasks from the role, if those tasks themselves have the same tag as the include statement. See :ref:`selective_reuse` for details. - -You can conditionally include a role: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Include the some_role role - include_role: - name: some_role - when: "ansible_facts['os_family'] == 'RedHat'" - -Importing roles: static reuse ------------------------------ - -You can reuse roles statically anywhere in the ``tasks`` section of a play using ``import_role``. The behavior is the same as using the ``roles`` keyword. For example: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Print a message - ansible.builtin.debug: - msg: "before we run our role" - - - name: Import the example role - import_role: - name: example - - - name: Print a message - ansible.builtin.debug: - msg: "after we ran our role" - -You can pass other keywords, including variables and tags, when importing roles: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Import the foo_app_instance role - import_role: - name: foo_app_instance - vars: - dir: '/opt/a' - app_port: 5000 - ... - -When you add a tag to an ``import_role`` statement, Ansible applies the tag to `all` tasks within the role. See :ref:`tag_inheritance` for details. - -.. _role_argument_spec: - -Role argument validation -======================== - -Beginning with version 2.11, you may choose to enable role argument validation based on an argument -specification. This specification is defined in the ``meta/argument_specs.yml`` file (or with the ``.yaml`` -file extension). When this argument specification is defined, a new task is inserted at the beginning of role execution -that will validate the parameters supplied for the role against the specification. If the parameters fail -validation, the role will fail execution. - -.. note:: - - Ansible also supports role specifications defined in the role ``meta/main.yml`` file, as well. However, - any role that defines the specs within this file will not work on versions below 2.11. For this reason, - we recommend using the ``meta/argument_specs.yml`` file to maintain backward compatibility. - -.. note:: - - When role argument validation is used on a role that has defined :ref:`dependencies `, - then validation on those dependencies will run before the dependent role, even if argument validation fails - for the dependent role. - -Specification format --------------------- - -The role argument specification must be defined in a top-level ``argument_specs`` block within the -role ``meta/argument_specs.yml`` file. All fields are lower-case. - -:entry-point-name: - - * The name of the role entry point. - * This should be ``main`` in the case of an unspecified entry point. - * This will be the base name of the tasks file to execute, with no ``.yml`` or ``.yaml`` file extension. - - :short_description: - - * A short, one-line description of the entry point. - * The ``short_description`` is displayed by ``ansible-doc -t role -l``. - - :description: - - * A longer description that may contain multiple lines. - - :author: - - * Name of the entry point authors. - * Use a multi-line list if there is more than one author. - - :options: - - * Options are often called "parameters" or "arguments". This section defines those options. - * For each role option (argument), you may include: - - :option-name: - - * The name of the option/argument. - - :description: - - * Detailed explanation of what this option does. It should be written in full sentences. - - :type: - - * The data type of the option. See :ref:`Argument spec ` for allowed values for ``type``. Default is ``str``. - * If an option is of type ``list``, ``elements`` should be specified. - - :required: - - * Only needed if ``true``. - * If missing, the option is not required. - - :default: - - * If ``required`` is false/missing, ``default`` may be specified (assumed 'null' if missing). - * Ensure that the default value in the docs matches the default value in the code. The actual - default for the role variable will always come from ``defaults/main.yml``. - * The default field must not be listed as part of the description, unless it requires additional information or conditions. - * If the option is a boolean value, you should use `true/false` if you want to be compatible with `ansible-lint`. - - :choices: - - * List of option values. - * Should be absent if empty. - - :elements: - - * Specifies the data type for list elements when type is ``list``. - - :options: - - * If this option takes a dict or list of dicts, you can define the structure here. - -Sample specification --------------------- - -.. code-block:: yaml - - # roles/myapp/meta/argument_specs.yml - --- - argument_specs: - # roles/myapp/tasks/main.yml entry point - main: - short_description: The main entry point for the myapp role. - options: - myapp_int: - type: "int" - required: false - default: 42 - description: "The integer value, defaulting to 42." - - myapp_str: - type: "str" - required: true - description: "The string value" - - # roles/myapp/tasks/alternate.yml entry point - alternate: - short_description: The alternate entry point for the myapp role. - options: - myapp_int: - type: "int" - required: false - default: 1024 - description: "The integer value, defaulting to 1024." - -.. _run_role_twice: - -Running a role multiple times in one play -========================================= - -Ansible only executes each role once in a play, even if you define it multiple times, unless the parameters defined on the role are different for each definition. For example, Ansible only runs the role ``foo`` once in a play like this: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - foo - - bar - - foo - -You have two options to force Ansible to run a role more than once. - -Passing different parameters ----------------------------- - -If you pass different parameters in each role definition, Ansible runs the role more than once. Providing different variable values is not the same as passing different role parameters. You must use the ``roles`` keyword for this behavior, since ``import_role`` and ``include_role`` do not accept role parameters. - -This play runs the ``foo`` role twice: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - { role: foo, message: "first" } - - { role: foo, message: "second" } - -This syntax also runs the ``foo`` role twice; - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - role: foo - message: "first" - - role: foo - message: "second" - -In these examples, Ansible runs ``foo`` twice because each role definition has different parameters. - -Using ``allow_duplicates: true`` --------------------------------- - -Add ``allow_duplicates: true`` to the ``meta/main.yml`` file for the role: - -.. code-block:: yaml - - # playbook.yml - --- - - hosts: webservers - roles: - - foo - - foo - - # roles/foo/meta/main.yml - --- - allow_duplicates: true - -In this example, Ansible runs ``foo`` twice because we have explicitly enabled it to do so. - -.. _role_dependencies: - -Using role dependencies -======================= - -Role dependencies let you automatically pull in other roles when using a role. - -Role dependencies are prerequisites, not true dependencies. The roles do not have a parent/child relationship. Ansible loads all listed roles, runs the roles listed under ``dependencies`` first, then runs the role that lists them. The play object is the parent of all roles, including roles called by a ``dependencies`` list. - -Role dependencies are stored in the ``meta/main.yml`` file within the role directory. This file should contain a list of roles and parameters to insert before the specified role. For example: - -.. code-block:: yaml - - # roles/myapp/meta/main.yml - --- - dependencies: - - role: common - vars: - some_parameter: 3 - - role: apache - vars: - apache_port: 80 - - role: postgres - vars: - dbname: blarg - other_parameter: 12 - -Ansible always executes roles listed in ``dependencies`` before the role that lists them. Ansible executes this pattern recursively when you use the ``roles`` keyword. For example, if you list role ``foo`` under ``roles:``, role ``foo`` lists role ``bar`` under ``dependencies`` in its meta/main.yml file, and role ``bar`` lists role ``baz`` under ``dependencies`` in its meta/main.yml, Ansible executes ``baz``, then ``bar``, then ``foo``. - -Running role dependencies multiple times in one play ----------------------------------------------------- - -Ansible treats duplicate role dependencies like duplicate roles listed under ``roles:``: Ansible only executes role dependencies once, even if defined multiple times, unless the parameters, tags, or when clause defined on the role are different for each definition. If two roles in a play both list a third role as a dependency, Ansible only runs that role dependency once, unless you pass different parameters, tags, when clause, or use ``allow_duplicates: true`` in the role you want to run multiple times. See :ref:`Galaxy role dependencies ` for more details. - -.. note:: - - Role deduplication does not consult the invocation signature of parent roles. Additionally, when using ``vars:`` instead of role params, there is a side effect of changing variable scoping. Using ``vars:`` results in those variables being scoped at the play level. In the below example, using ``vars:`` would cause ``n`` to be defined as ``4`` through the entire play, including roles called before it. - - In addition to the above, users should be aware that role de-duplication occurs before variable evaluation. This means that :term:`Lazy Evaluation` may make seemingly different role invocations equivalently the same, preventing the role from running more than once. - - -For example, a role named ``car`` depends on a role named ``wheel`` as follows: - -.. code-block:: yaml - - --- - dependencies: - - role: wheel - n: 1 - - role: wheel - n: 2 - - role: wheel - n: 3 - - role: wheel - n: 4 - -And the ``wheel`` role depends on two roles: ``tire`` and ``brake``. The ``meta/main.yml`` for wheel would then contain the following: - -.. code-block:: yaml - - --- - dependencies: - - role: tire - - role: brake - -And the ``meta/main.yml`` for ``tire`` and ``brake`` would contain the following: - -.. code-block:: yaml - - --- - allow_duplicates: true - -The resulting order of execution would be as follows: - -.. code-block:: text - - tire(n=1) - brake(n=1) - wheel(n=1) - tire(n=2) - brake(n=2) - wheel(n=2) - ... - car - -To use ``allow_duplicates: true`` with role dependencies, you must specify it for the role listed under ``dependencies``, not for the role that lists it. In the example above, ``allow_duplicates: true`` appears in the ``meta/main.yml`` of the ``tire`` and ``brake`` roles. The ``wheel`` role does not require ``allow_duplicates: true``, because each instance defined by ``car`` uses different parameter values. - -.. note:: - See :ref:`playbooks_variables` for details on how Ansible chooses among variable values defined in different places (variable inheritance and scope). - Also deduplication happens ONLY at the play level, so multiple plays in the same playbook may rerun the roles. - -.. _embedding_modules_and_plugins_in_roles: - -Embedding modules and plugins in roles -====================================== - -.. note:: - This applies only to standalone roles. Roles in collections do not support plugin embedding; they must use the collection's ``plugins`` structure to distribute plugins. - -If you write a custom module (see :ref:`developing_modules`) or a plugin (see :ref:`developing_plugins`), you might wish to distribute it as part of a role. For example, if you write a module that helps configure your company's internal software, and you want other people in your organization to use this module, but you do not want to tell everyone how to configure their Ansible library path, you can include the module in your internal_config role. - -To add a module or a plugin to a role: -Alongside the 'tasks' and 'handlers' structure of a role, add a directory named 'library' and then include the module directly inside the 'library' directory. - -Assuming you had this: - -.. code-block:: text - - roles/ - my_custom_modules/ - library/ - module1 - module2 - -The module will be usable in the role itself, as well as any roles that are called *after* this role, as follows: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - my_custom_modules - - some_other_role_using_my_custom_modules - - yet_another_role_using_my_custom_modules - -If necessary, you can also embed a module in a role to modify a module in Ansible's core distribution. For example, you can use the development version of a particular module before it is released in production releases by copying the module and embedding the copy in a role. Use this approach with caution, as API signatures may change in core components, and this workaround is not guaranteed to work. - -The same mechanism can be used to embed and distribute plugins in a role, using the same schema. For example, for a filter plugin: - -.. code-block:: text - - roles/ - my_custom_filter/ - filter_plugins - filter1 - filter2 - -These filters can then be used in a Jinja template in any role called after 'my_custom_filter'. - -Sharing roles: Ansible Galaxy -============================= - -`Ansible Galaxy `_ is a free site for finding, downloading, rating, and reviewing all kinds of community-developed Ansible roles and can be a great way to get a jumpstart on your automation projects. - -The client ``ansible-galaxy`` is included in Ansible. The Galaxy client allows you to download roles from Ansible Galaxy and provides an excellent default framework for creating your own roles. - -Read the `Ansible Galaxy documentation `_ page for more information. A page that refers back to this one frequently is the Galaxy Roles document which explains the required metadata your role needs for use in Galaxy . - -.. seealso:: - - :ref:`ansible_galaxy` - How to create new roles, share roles on Galaxy, role management - :ref:`yaml_syntax` - Learn about YAML syntax - :ref:`working_with_playbooks` - Review the basic Playbook language features - :ref:`tips_and_tricks` - Tips and tricks for playbooks - :ref:`playbooks_variables` - Variables in playbooks - :ref:`playbooks_conditionals` - Conditionals in playbooks - :ref:`playbooks_loops` - Loops in playbooks - :ref:`tags` - Using tags to select or skip roles/tasks in long playbooks - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_modules` - Extending Ansible by writing your own modules - `GitHub Ansible examples `_ - Complete playbook files from the GitHub project source - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups diff --git a/docs/docsite/rst/playbook_guide/playbooks_roles.rst b/docs/docsite/rst/playbook_guide/playbooks_roles.rst deleted file mode 100644 index f79e23087d5..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_roles.rst +++ /dev/null @@ -1,19 +0,0 @@ -:orphan: - -Playbook Roles and Include Statements -===================================== - -.. contents:: Topics - - -The documentation regarding roles and includes for playbooks have moved. Their new location is here: :ref:`playbooks_reuse`. Please update any links you may have made directly to this page. - -.. seealso:: - - :ref:`ansible_galaxy` - How to share roles on galaxy, role management - :ref:`working_with_playbooks` - Review the basic Playbook language features - :ref:`playbooks_reuse` - Creating reusable Playbooks. - diff --git a/docs/docsite/rst/playbook_guide/playbooks_special_topics.rst b/docs/docsite/rst/playbook_guide/playbooks_special_topics.rst deleted file mode 100644 index 5df72c11d96..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_special_topics.rst +++ /dev/null @@ -1,8 +0,0 @@ -:orphan: - -.. _playbooks_special_topics: - -Advanced playbooks features -=========================== - -This page is obsolete. Refer to the :ref:`main User Guide index page ` for links to all playbook-related topics. Please update any links you may have made directly to this page. diff --git a/docs/docsite/rst/playbook_guide/playbooks_startnstep.rst b/docs/docsite/rst/playbook_guide/playbooks_startnstep.rst deleted file mode 100644 index e6c78d24edd..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_startnstep.rst +++ /dev/null @@ -1,46 +0,0 @@ -.. _playbooks_start_and_step: - -*************************************** -Executing playbooks for troubleshooting -*************************************** - -When you are testing new plays or debugging playbooks, you may need to run the same play multiple times. To make this more efficient, Ansible offers two alternative ways to execute a playbook: start-at-task and step mode. - -.. _start_at_task: - -start-at-task -------------- - -To start executing your playbook at a particular task (usually the task that failed on the previous run), use the ``--start-at-task`` option. - -.. code-block:: shell - - ansible-playbook playbook.yml --start-at-task="install packages" - -In this example, Ansible starts executing your playbook at a task named "install packages". This feature does not work with tasks inside dynamically re-used roles or tasks (``include_*``), see :ref:`dynamic_vs_static`. - -.. _step: - -Step mode ---------- - -To execute a playbook interactively, use ``--step``. - -.. code-block:: shell - - ansible-playbook playbook.yml --step - -With this option, Ansible stops on each task, and asks if it should execute that task. For example, if you have a task called "configure ssh", the playbook run will stop and ask. - -.. code-block:: shell - - Perform task: configure ssh (y/n/c): - -Answer "y" to execute the task, answer "n" to skip the task, and answer "c" to exit step mode, executing all remaining tasks without asking. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbook_debugger` - Using the Ansible debugger diff --git a/docs/docsite/rst/playbook_guide/playbooks_strategies.rst b/docs/docsite/rst/playbook_guide/playbooks_strategies.rst deleted file mode 100644 index 43d1605c332..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_strategies.rst +++ /dev/null @@ -1,254 +0,0 @@ -.. _playbooks_strategies: - -Controlling playbook execution: strategies and more -=================================================== - -By default, Ansible runs each task on all hosts affected by a play before starting the next task on any host, using 5 forks. If you want to change this default behavior, you can use a different strategy plugin, change the number of forks, or apply one of several keywords like ``serial``. - -.. contents:: - :local: - -Selecting a strategy --------------------- -The default behavior described above is the :ref:`linear strategy`. Ansible offers other strategies, including the :ref:`debug strategy` (see also :ref:`playbook_debugger`) and the :ref:`free strategy`, which allows each host to run until the end of the play as fast as it can: - -.. code-block:: yaml - - - hosts: all - strategy: free - tasks: - # ... - -You can select a different strategy for each play as shown above, or set your preferred strategy globally in ``ansible.cfg``, under the ``defaults`` stanza: - -.. code-block:: ini - - [defaults] - strategy = free - -All strategies are implemented as :ref:`strategy plugins`. Please review the documentation for each strategy plugin for details on how it works. - -Setting the number of forks ---------------------------- -If you have the processing power available and want to use more forks, you can set the number in ``ansible.cfg``: - -.. code-block:: ini - - [defaults] - forks = 30 - -or pass it on the command line: `ansible-playbook -f 30 my_playbook.yml`. - -Using keywords to control execution ------------------------------------ - -In addition to strategies, several :ref:`keywords` also affect play execution. You can set a number, a percentage, or a list of numbers of hosts you want to manage at a time with ``serial``. Ansible completes the play on the specified number or percentage of hosts before starting the next batch of hosts. You can restrict the number of workers allotted to a block or task with ``throttle``. You can control how Ansible selects the next host in a group to execute against with ``order``. You can run a task on a single host with ``run_once``. These keywords are not strategies. They are directives or options applied to a play, block, or task. - -Other keywords that affect play execution include ``ignore_errors``, ``ignore_unreachable``, and ``any_errors_fatal``. These options are documented in :ref:`playbooks_error_handling`. - -.. _rolling_update_batch_size: - -Setting the batch size with ``serial`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default, Ansible runs in parallel against all the hosts in the :ref:`pattern ` you set in the ``hosts:`` field of each play. If you want to manage only a few machines at a time, for example during a rolling update, you can define how many hosts Ansible should manage at a single time using the ``serial`` keyword: - -.. code-block:: yaml - - - --- - - name: test play - hosts: webservers - serial: 3 - gather_facts: False - - tasks: - - name: first task - command: hostname - - name: second task - command: hostname - -In the above example, if we had 6 hosts in the group 'webservers', Ansible would execute the play completely (both tasks) on 3 of the hosts before moving on to the next 3 hosts: - -.. code-block:: ansible-output - - PLAY [webservers] **************************************** - - TASK [first task] **************************************** - changed: [web3] - changed: [web2] - changed: [web1] - - TASK [second task] *************************************** - changed: [web1] - changed: [web2] - changed: [web3] - - PLAY [webservers] **************************************** - - TASK [first task] **************************************** - changed: [web4] - changed: [web5] - changed: [web6] - - TASK [second task] *************************************** - changed: [web4] - changed: [web5] - changed: [web6] - - PLAY RECAP *********************************************** - web1 : ok=2 changed=2 unreachable=0 failed=0 - web2 : ok=2 changed=2 unreachable=0 failed=0 - web3 : ok=2 changed=2 unreachable=0 failed=0 - web4 : ok=2 changed=2 unreachable=0 failed=0 - web5 : ok=2 changed=2 unreachable=0 failed=0 - web6 : ok=2 changed=2 unreachable=0 failed=0 - - -.. note:: - Setting the batch size with ``serial`` changes the scope of the Ansible failures to the batch size, not the entire host list. You can use :ref:`ignore_unreachable ` or :ref:`max_fail_percentage ` to modify this behavior. - -You can also specify a percentage with the ``serial`` keyword. Ansible applies the percentage to the total number of hosts in a play to determine the number of hosts per pass: - -.. code-block:: yaml - - --- - - name: test play - hosts: webservers - serial: "30%" - -If the number of hosts does not divide equally into the number of passes, the final pass contains the remainder. In this example, if you had 20 hosts in the webservers group, the first batch would contain 6 hosts, the second batch would contain 6 hosts, the third batch would contain 6 hosts, and the last batch would contain 2 hosts. - -You can also specify batch sizes as a list. For example: - -.. code-block:: yaml - - --- - - name: test play - hosts: webservers - serial: - - 1 - - 5 - - 10 - -In the above example, the first batch would contain a single host, the next would contain 5 hosts, and (if there are any hosts left), every following batch would contain either 10 hosts or all the remaining hosts, if fewer than 10 hosts remained. - -You can list multiple batch sizes as percentages: - -.. code-block:: yaml - - --- - - name: test play - hosts: webservers - serial: - - "10%" - - "20%" - - "100%" - -You can also mix and match the values: - -.. code-block:: yaml - - --- - - name: test play - hosts: webservers - serial: - - 1 - - 5 - - "20%" - -.. note:: - No matter how small the percentage, the number of hosts per pass will always be 1 or greater. - -Restricting execution with ``throttle`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``throttle`` keyword limits the number of workers for a particular task. It can be set at the block and task level. Use ``throttle`` to restrict tasks that may be CPU-intensive or interact with a rate-limiting API: - -.. code-block:: yaml - - tasks: - - command: /path/to/cpu_intensive_command - throttle: 1 - -If you have already restricted the number of forks or the number of machines to execute against in parallel, you can reduce the number of workers with ``throttle``, but you cannot increase it. In other words, to have an effect, your ``throttle`` setting must be lower than your ``forks`` or ``serial`` setting if you are using them together. - -Ordering execution based on inventory -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``order`` keyword controls the order in which hosts are run. Possible values for order are: - -inventory: - (default) The order provided by the inventory for the selection requested (see note below) -reverse_inventory: - The same as above, but reversing the returned list -sorted: - Sorted alphabetically sorted by name -reverse_sorted: - Sorted by name in reverse alphabetical order -shuffle: - Randomly ordered on each run - -.. note:: - the 'inventory' order does not equate to the order in which hosts/groups are defined in the inventory source file, but the 'order in which a selection is returned from the compiled inventory'. This is a backwards compatible option and while reproducible it is not normally predictable. Due to the nature of inventory, host patterns, limits, inventory plugins and the ability to allow multiple sources it is almost impossible to return such an order. For simple cases this might happen to match the file definition order, but that is not guaranteed. - -.. _run_once: - -Running on a single machine with ``run_once`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you want a task to run only on the first host in your batch of hosts, set ``run_once`` to true on that task: - -.. code-block:: yaml - - --- - # ... - - tasks: - - # ... - - - command: /opt/application/upgrade_db.py - run_once: true - - # ... - -Ansible executes this task on the first host in the current batch and applies all results and facts to all the hosts in the same batch. This approach is similar to applying a conditional to a task such as: - -.. code-block:: yaml - - - command: /opt/application/upgrade_db.py - when: inventory_hostname == webservers[0] - -However, with ``run_once``, the results are applied to all the hosts. To run the task on a specific host, instead of the first host in the batch, delegate the task: - -.. code-block:: yaml - - - command: /opt/application/upgrade_db.py - run_once: true - delegate_to: web01.example.org - -As always with :ref:`delegation `, the action will be executed on the delegated host, but the information is still that of the original host in the task. - -.. note:: - When used together with ``serial``, tasks marked as ``run_once`` will be run on one host in *each* serial batch. If the task must run only once regardless of ``serial`` mode, use - :code:`when: inventory_hostname == ansible_play_hosts_all[0]` construct. - -.. note:: - Any conditional (in other words, `when:`) will use the variables of the 'first host' to decide if the task runs or not, no other hosts will be tested. - -.. note:: - If you want to avoid the default behavior of setting the fact for all hosts, set ``delegate_facts: True`` for the specific task or block. - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_delegation` - Running tasks on or assigning facts to specific machines - :ref:`playbooks_reuse_roles` - Playbook organization by roles - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_tags.rst b/docs/docsite/rst/playbook_guide/playbooks_tags.rst deleted file mode 100644 index e6de2321c9b..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_tags.rst +++ /dev/null @@ -1,438 +0,0 @@ -.. _tags: - -**** -Tags -**** - -If you have a large playbook, it may be useful to run only specific parts of it instead of running the entire playbook. You can do this with Ansible tags. Using tags to execute or skip selected tasks is a two-step process: - - #. Add tags to your tasks, either individually or with tag inheritance from a block, play, role, or import. - #. Select or skip tags when you run your playbook. - -.. contents:: - :local: - -Adding tags with the tags keyword -================================= - -You can add tags to a single task or include. You can also add tags to multiple tasks by defining them at the level of a block, play, role, or import. The keyword ``tags`` addresses all these use cases. The ``tags`` keyword always defines tags and adds them to tasks; it does not select or skip tasks for execution. You can only select or skip tasks based on tags at the command line when you run a playbook. See :ref:`using_tags` for more details. - -Adding tags to individual tasks -------------------------------- - -At the simplest level, you can apply one or more tags to an individual task. You can add tags to tasks in playbooks, in task files, or within a role. Here is an example that tags two tasks with different tags: - -.. code-block:: yaml - - tasks: - - name: Install the servers - ansible.builtin.yum: - name: - - httpd - - memcached - state: present - tags: - - packages - - webservers - - - name: Configure the service - ansible.builtin.template: - src: templates/src.j2 - dest: /etc/foo.conf - tags: - - configuration - -You can apply the same tag to more than one individual task. This example tags several tasks with the same tag, "ntp": - -.. code-block:: yaml - - --- - # file: roles/common/tasks/main.yml - - - name: Install ntp - ansible.builtin.yum: - name: ntp - state: present - tags: ntp - - - name: Configure ntp - ansible.builtin.template: - src: ntp.conf.j2 - dest: /etc/ntp.conf - notify: - - restart ntpd - tags: ntp - - - name: Enable and run ntpd - ansible.builtin.service: - name: ntpd - state: started - enabled: true - tags: ntp - - - name: Install NFS utils - ansible.builtin.yum: - name: - - nfs-utils - - nfs-util-lib - state: present - tags: filesharing - -If you ran these four tasks in a playbook with ``--tags ntp``, Ansible would run the three tasks tagged ``ntp`` and skip the one task that does not have that tag. - -.. _tags_on_includes: - -Adding tags to includes ------------------------ - -You can apply tags to dynamic includes in a playbook. As with tags on an individual task, tags on an ``include_*`` task apply only to the include itself, not to any tasks within the included file or role. If you add ``mytag`` to a dynamic include, then run that playbook with ``--tags mytag``, Ansible runs the include itself, runs any tasks within the included file or role tagged with ``mytag``, and skips any tasks within the included file or role without that tag. See :ref:`selective_reuse` for more details. - -You add tags to includes the same way you add tags to any other task: - -.. code-block:: yaml - - --- - # file: roles/common/tasks/main.yml - - - name: Dynamic re-use of database tasks - include_tasks: db.yml - tags: db - -You can add a tag only to the dynamic include of a role. In this example, the ``foo`` tag will `not` apply to tasks inside the ``bar`` role: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Include the bar role - include_role: - name: bar - tags: - - foo - -With plays, blocks, the ``role`` keyword, and static imports, Ansible applies tag inheritance, adding the tags you define to every task inside the play, block, role, or imported file. However, tag inheritance does *not* apply to dynamic re-use with ``include_role`` and ``include_tasks``. With dynamic re-use (includes), the tags you define apply only to the include itself. If you need tag inheritance, use a static import. If you cannot use an import because the rest of your playbook uses includes, see :ref:`apply_keyword` for ways to work around this behavior. - -.. _tag_inheritance: - -Tag inheritance: adding tags to multiple tasks ----------------------------------------------- - -If you want to apply the same tag or tags to multiple tasks without adding a ``tags`` line to every task, you can define the tags at the level of your play or block, or when you add a role or import a file. Ansible applies the tags down the dependency chain to all child tasks. With roles and imports, Ansible appends the tags set by the ``roles`` section or import to any tags set on individual tasks or blocks within the role or imported file. This is called tag inheritance. Tag inheritance is convenient, because you do not have to tag every task. However, the tags still apply to the tasks individually. - -Adding tags to blocks -^^^^^^^^^^^^^^^^^^^^^ - -If you want to apply a tag to many, but not all, of the tasks in your play, use a :ref:`block ` and define the tags at that level. For example, we could edit the NTP example shown above to use a block: - -.. code-block:: yaml - - # myrole/tasks/main.yml - - name: ntp tasks - tags: ntp - block: - - name: Install ntp - ansible.builtin.yum: - name: ntp - state: present - - - name: Configure ntp - ansible.builtin.template: - src: ntp.conf.j2 - dest: /etc/ntp.conf - notify: - - restart ntpd - - - name: Enable and run ntpd - ansible.builtin.service: - name: ntpd - state: started - enabled: true - - - name: Install NFS utils - ansible.builtin.yum: - name: - - nfs-utils - - nfs-util-lib - state: present - tags: filesharing - -Adding tags to plays -^^^^^^^^^^^^^^^^^^^^ - -If all the tasks in a play should get the same tag, you can add the tag at the level of the play. For example, if you had a play with only the NTP tasks, you could tag the entire play: - -.. code-block:: yaml - - - hosts: all - tags: ntp - tasks: - - name: Install ntp - ansible.builtin.yum: - name: ntp - state: present - - - name: Configure ntp - ansible.builtin.template: - src: ntp.conf.j2 - dest: /etc/ntp.conf - notify: - - restart ntpd - - - name: Enable and run ntpd - ansible.builtin.service: - name: ntpd - state: started - enabled: true - - - hosts: fileservers - tags: filesharing - tasks: - ... - -Adding tags to roles -^^^^^^^^^^^^^^^^^^^^ - -There are three ways to add tags to roles: - - #. Add the same tag or tags to all tasks in the role by setting tags under ``roles``. See examples in this section. - #. Add the same tag or tags to all tasks in the role by setting tags on a static ``import_role`` in your playbook. See examples in :ref:`tags_on_imports`. - #. Add a tag or tags to individual tasks or blocks within the role itself. This is the only approach that allows you to select or skip some tasks within the role. To select or skip tasks within the role, you must have tags set on individual tasks or blocks, use the dynamic ``include_role`` in your playbook, and add the same tag or tags to the include. When you use this approach, and then run your playbook with ``--tags foo``, Ansible runs the include itself plus any tasks in the role that also have the tag ``foo``. See :ref:`tags_on_includes` for details. - -When you incorporate a role in your playbook statically with the ``roles`` keyword, Ansible adds any tags you define to all the tasks in the role. For example: - -.. code-block:: yaml - - roles: - - role: webserver - vars: - port: 5000 - tags: [ web, foo ] - -or: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - role: foo - tags: - - bar - - baz - # using YAML shorthand, this is equivalent to: - # - { role: foo, tags: ["bar", "baz"] } - -.. _tags_on_imports: - -Adding tags to imports -^^^^^^^^^^^^^^^^^^^^^^ - -You can also apply a tag or tags to all the tasks imported by the static ``import_role`` and ``import_tasks`` statements: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Import the foo role - import_role: - name: foo - tags: - - bar - - baz - - - name: Import tasks from foo.yml - import_tasks: foo.yml - tags: [ web, foo ] - -.. _apply_keyword: - -Tag inheritance for includes: blocks and the ``apply`` keyword -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default, Ansible does not apply :ref:`tag inheritance ` to dynamic re-use with ``include_role`` and ``include_tasks``. If you add tags to an include, they apply only to the include itself, not to any tasks in the included file or role. This allows you to execute selected tasks within a role or task file - see :ref:`selective_reuse` when you run your playbook. - -If you want tag inheritance, you probably want to use imports. However, using both includes and imports in a single playbook can lead to difficult-to-diagnose bugs. For this reason, if your playbook uses ``include_*`` to re-use roles or tasks, and you need tag inheritance on one include, Ansible offers two workarounds. You can use the ``apply`` keyword: - -.. code-block:: yaml - - - name: Apply the db tag to the include and to all tasks in db.yml - include_tasks: - file: db.yml - # adds 'db' tag to tasks within db.yml - apply: - tags: db - # adds 'db' tag to this 'include_tasks' itself - tags: db - -Or you can use a block: - -.. code-block:: yaml - - - block: - - name: Include tasks from db.yml - include_tasks: db.yml - tags: db - -.. _special_tags: - -Special tags: always and never -============================== - -Ansible reserves two tag names for special behavior: always and never. If you assign the ``always`` tag to a task or play, Ansible will always run that task or play, unless you specifically skip it (``--skip-tags always``). - -For example: - -.. code-block:: yaml - - tasks: - - name: Print a message - ansible.builtin.debug: - msg: "Always runs" - tags: - - always - - - name: Print a message - ansible.builtin.debug: - msg: "runs when you use tag1" - tags: - - tag1 - -.. warning:: - * Fact gathering is tagged with 'always' by default. It is only skipped if - you apply a tag to the play and then use a different tag in ``--tags`` or the same - tag in ``--skip-tags``. - -.. warning:: - * The role argument specification validation task is tagged with 'always' by default. This validation - will be skipped if you use ``--skip-tags always``. - -.. versionadded:: 2.5 - -If you assign the ``never`` tag to a task or play, Ansible will skip that task or play unless you specifically request it (``--tags never``). - -For example: - -.. code-block:: yaml - - tasks: - - name: Run the rarely-used debug task - ansible.builtin.debug: - msg: '{{ showmevar }}' - tags: [ never, debug ] - -The rarely-used debug task in the example above only runs when you specifically request the ``debug`` or ``never`` tags. - -.. _using_tags: - -Selecting or skipping tags when you run a playbook -================================================== - -Once you have added tags to your tasks, includes, blocks, plays, roles, and imports, you can selectively execute or skip tasks based on their tags when you run :ref:`ansible-playbook`. Ansible runs or skips all tasks with tags that match the tags you pass at the command line. If you have added a tag at the block or play level, with ``roles``, or with an import, that tag applies to every task within the block, play, role, or imported role or file. If you have a role with lots of tags and you want to call subsets of the role at different times, either :ref:`use it with dynamic includes `, or split the role into multiple roles. - -:ref:`ansible-playbook` offers five tag-related command-line options: - -* ``--tags all`` - run all tasks, ignore tags (default behavior) -* ``--tags [tag1, tag2]`` - run only tasks with either the tag ``tag1`` or the tag ``tag2`` -* ``--skip-tags [tag3, tag4]`` - run all tasks except those with either the tag ``tag3`` or the tag ``tag4`` -* ``--tags tagged`` - run only tasks with at least one tag -* ``--tags untagged`` - run only tasks with no tags - -For example, to run only tasks and blocks tagged either ``configuration`` or ``packages`` in a very long playbook: - -.. code-block:: bash - - ansible-playbook example.yml --tags "configuration,packages" - -To run all tasks except those tagged ``packages``: - -.. code-block:: bash - - ansible-playbook example.yml --skip-tags "packages" - -To run all tasks, even those excluded because are tagged ``never``: - -.. code-block:: bash - - ansible-playbook example.yml --tags "all,never" - -Previewing the results of using tags ------------------------------------- - -When you run a role or playbook, you might not know or remember which tasks have which tags, or which tags exist at all. Ansible offers two command-line flags for :ref:`ansible-playbook` that help you manage tagged playbooks: - -* ``--list-tags`` - generate a list of available tags -* ``--list-tasks`` - when used with ``--tags tagname`` or ``--skip-tags tagname``, generate a preview of tagged tasks - -For example, if you do not know whether the tag for configuration tasks is ``config`` or ``conf`` in a playbook, role, or tasks file, you can display all available tags without running any tasks: - -.. code-block:: bash - - ansible-playbook example.yml --list-tags - -If you do not know which tasks have the tags ``configuration`` and ``packages``, you can pass those tags and add ``--list-tasks``. Ansible lists the tasks but does not execute any of them. - -.. code-block:: bash - - ansible-playbook example.yml --tags "configuration,packages" --list-tasks - -These command-line flags have one limitation: they cannot show tags or tasks within dynamically included files or roles. See :ref:`dynamic_vs_static` for more information on differences between static imports and dynamic includes. - -.. _selective_reuse: - -Selectively running tagged tasks in re-usable files ---------------------------------------------------- - -If you have a role or a tasks file with tags defined at the task or block level, you can selectively run or skip those tagged tasks in a playbook if you use a dynamic include instead of a static import. You must use the same tag on the included tasks and on the include statement itself. For example you might create a file with some tagged and some untagged tasks: - -.. code-block:: yaml - - # mixed.yml - tasks: - - name: Run the task with no tags - ansible.builtin.debug: - msg: this task has no tags - - - name: Run the tagged task - ansible.builtin.debug: - msg: this task is tagged with mytag - tags: mytag - - - block: - - name: Run the first block task with mytag - ... - - name: Run the second block task with mytag - ... - tags: - - mytag - -And you might include the tasks file above in a playbook: - -.. code-block:: yaml - - # myplaybook.yml - - hosts: all - tasks: - - name: Run tasks from mixed.yml - include_tasks: - name: mixed.yml - tags: mytag - -When you run the playbook with ``ansible-playbook -i hosts myplaybook.yml --tags "mytag"``, Ansible skips the task with no tags, runs the tagged individual task, and runs the two tasks in the block. - -Configuring tags globally -------------------------- - -If you run or skip certain tags by default, you can use the :ref:`TAGS_RUN` and :ref:`TAGS_SKIP` options in Ansible configuration to set those defaults. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_templating.rst b/docs/docsite/rst/playbook_guide/playbooks_templating.rst deleted file mode 100644 index ef0836432d6..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_templating.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _playbooks_templating: - -******************* -Templating (Jinja2) -******************* - -Ansible uses Jinja2 templating to enable dynamic expressions and access to :ref:`variables ` and :ref:`facts `. -You can use templating with the :ref:`template module `. -For example, you can create a template for a configuration file, then deploy that configuration file to multiple environments and supply the correct data (IP address, hostname, version) for each environment. -You can also use templating in playbooks directly, by templating task names and more. -You can use all the :ref:`standard filters and tests ` included in Jinja2. -Ansible includes additional specialized filters for selecting and transforming data, tests for evaluating template expressions, and :ref:`lookup_plugins` for retrieving data from external sources such as files, APIs, and databases for use in templating. - -All templating happens on the Ansible controller **before** the task is sent and executed on the target machine. -This approach minimizes the package requirements on the target (jinja2 is only required on the controller). -It also limits the amount of data Ansible passes to the target machine. -Ansible parses templates on the controller and passes only the information needed for each task to the target machine, instead of passing all the data on the controller and parsing it on the target. - -.. note:: - - Files and data used by the :ref:`template module ` must be utf-8 encoded. - -Jinja2 Example -================== - -In this example, we want to write the server hostname to its /tmp/hostname. - -Our directory looks like this: - -.. code-block:: - - ├── hostname.yml - ├── templates - └── test.j2 - -Our hostname.yml: - -.. code-block:: yaml - - --- - - name: Write hostname - hosts: all - tasks: - - name: write hostname using jinja2 - ansible.builtin.template: - src: templates/test.j2 - dest: /tmp/hostname - -Our test.j2: - -.. code-block:: yaml - - My name is {{ ansible_facts['hostname'] }} - - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbook_tips` - Tips and tricks for playbooks - `Jinja2 Docs `_ - Jinja2 documentation, includes the syntax and semantics of the templates - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_templating_now.rst b/docs/docsite/rst/playbook_guide/playbooks_templating_now.rst deleted file mode 100644 index 1ca608016f5..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_templating_now.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. _templating_now: - -The now function: get the current time -====================================== - -.. versionadded:: 2.8 - -The ``now()`` Jinja2 function retrieves a Python datetime object or a string representation for the current time. - -The ``now()`` function supports 2 arguments: - -utc - Specify ``True`` to get the current time in UTC. Defaults to ``False``. - -fmt - Accepts a `strftime `_ string that returns a formatted date time string. \ No newline at end of file diff --git a/docs/docsite/rst/playbook_guide/playbooks_tests.rst b/docs/docsite/rst/playbook_guide/playbooks_tests.rst deleted file mode 100644 index ccf6f9e642d..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_tests.rst +++ /dev/null @@ -1,542 +0,0 @@ -.. _playbooks_tests: - -***** -Tests -***** - -`Tests `_ in Jinja are a way of evaluating template expressions and returning True or False. Jinja ships with many of these. See `builtin tests`_ in the official Jinja template documentation. - -The main difference between tests and filters are that Jinja tests are used for comparisons, whereas filters are used for data manipulation, and have different applications in jinja. Tests can also be used in list processing filters, like ``map()`` and ``select()`` to choose items in the list. - -Like all templating, tests always execute on the Ansible controller, **not** on the target of a task, as they test local data. - -In addition to those Jinja2 tests, Ansible supplies a few more and users can easily create their own. - -.. contents:: - :local: - -.. _test_syntax: - -Test syntax -=========== - -`Test syntax `_ varies from `filter syntax `_ (``variable | filter``). Historically Ansible has registered tests as both jinja tests and jinja filters, allowing for them to be referenced using filter syntax. - -As of Ansible 2.5, using a jinja test as a filter will generate a deprecation warning. As of Ansible 2.9+ using jinja test syntax is required. - -The syntax for using a jinja test is as follows - -.. code-block:: console - - variable is test_name - -Such as - -.. code-block:: console - - result is failed - -.. _testing_strings: - -Testing strings -=============== - -To match strings against a substring or a regular expression, use the ``match``, ``search`` or ``regex`` tests - -.. code-block:: yaml - - vars: - url: "https://example.com/users/foo/resources/bar" - - tasks: - - debug: - msg: "matched pattern 1" - when: url is match("https://example.com/users/.*/resources") - - - debug: - msg: "matched pattern 2" - when: url is search("users/.*/resources/.*") - - - debug: - msg: "matched pattern 3" - when: url is search("users") - - - debug: - msg: "matched pattern 4" - when: url is regex("example\.com/\w+/foo") - -``match`` succeeds if it finds the pattern at the beginning of the string, while ``search`` succeeds if it finds the pattern anywhere within string. By default, ``regex`` works like ``search``, but ``regex`` can be configured to perform other tests as well, by passing the ``match_type`` keyword argument. In particular, ``match_type`` determines the ``re`` method that gets used to perform the search. The full list can be found in the relevant Python documentation `here `_. - -All of the string tests also take optional ``ignorecase`` and ``multiline`` arguments. These correspond to ``re.I`` and ``re.M`` from Python's ``re`` library, respectively. - -.. _testing_vault: - -Vault -===== - -.. versionadded:: 2.10 - -You can test whether a variable is an inline single vault encrypted value using the ``vault_encrypted`` test. - -.. code-block:: yaml - - vars: - variable: !vault | - $ANSIBLE_VAULT;1.2;AES256;dev - 61323931353866666336306139373937316366366138656131323863373866376666353364373761 - 3539633234313836346435323766306164626134376564330a373530313635343535343133316133 - 36643666306434616266376434363239346433643238336464643566386135356334303736353136 - 6565633133366366360a326566323363363936613664616364623437336130623133343530333739 - 3039 - - tasks: - - debug: - msg: '{{ (variable is vault_encrypted) | ternary("Vault encrypted", "Not vault encrypted") }}' - -.. _testing_truthiness: - -Testing truthiness -================== - -.. versionadded:: 2.10 - -As of Ansible 2.10, you can now perform Python like truthy and falsy checks. - -.. code-block:: yaml - - - debug: - msg: "Truthy" - when: value is truthy - vars: - value: "some string" - - - debug: - msg: "Falsy" - when: value is falsy - vars: - value: "" - -Additionally, the ``truthy`` and ``falsy`` tests accept an optional parameter called ``convert_bool`` that will attempt -to convert boolean indicators to actual booleans. - -.. code-block:: yaml - - - debug: - msg: "Truthy" - when: value is truthy(convert_bool=True) - vars: - value: "yes" - - - debug: - msg: "Falsy" - when: value is falsy(convert_bool=True) - vars: - value: "off" - -.. _testing_versions: - -Comparing versions -================== - -.. versionadded:: 1.6 - -.. note:: In 2.5 ``version_compare`` was renamed to ``version`` - -To compare a version number, such as checking if the ``ansible_facts['distribution_version']`` -version is greater than or equal to '12.04', you can use the ``version`` test. - -The ``version`` test can also be used to evaluate the ``ansible_facts['distribution_version']`` - -.. code-block:: yaml+jinja - - {{ ansible_facts['distribution_version'] is version('12.04', '>=') }} - -If ``ansible_facts['distribution_version']`` is greater than or equal to 12.04, this test returns True, otherwise False. - -The ``version`` test accepts the following operators - -.. code-block:: console - - <, lt, <=, le, >, gt, >=, ge, ==, =, eq, !=, <>, ne - -This test also accepts a 3rd parameter, ``strict`` which defines if strict version parsing as defined by ``ansible.module_utils.compat.version.StrictVersion`` should be used. The default is ``False`` (using ``ansible.module_utils.compat.version.LooseVersion``), ``True`` enables strict version parsing - -.. code-block:: yaml+jinja - - {{ sample_version_var is version('1.0', operator='lt', strict=True) }} - -As of Ansible 2.11 the ``version`` test accepts a ``version_type`` parameter which is mutually exclusive with ``strict``, and accepts the following values - -.. code-block:: console - - loose, strict, semver, semantic, pep440 - -``loose`` - This type corresponds to the Python ``distutils.version.LooseVersion`` class. All version formats are valid for this type. The rules for comparison are simple and predictable, but may not always give expected results. - -``strict`` - This type corresponds to the Python ``distutils.version.StrictVersion`` class. A version number consists of two or three dot-separated numeric components, with an optional "pre-release" tag on the end. The pre-release tag consists of a single letter 'a' or 'b' followed by a number. If the numeric components of two version numbers are equal, then one with a pre-release tag will always be deemed earlier (lesser) than one without. - -``semver``/``semantic`` - This type implements the `Semantic Version `_ scheme for version comparison. - -``pep440`` - This type implements the Python `PEP-440 `_ versioning rules for version comparison. Added in version 2.14. - -Using ``version_type`` to compare a semantic version would be achieved like the following - -.. code-block:: yaml+jinja - - {{ sample_semver_var is version('2.0.0-rc.1+build.123', 'lt', version_type='semver') }} - -In Ansible 2.14, the ``pep440`` option for ``version_type`` was added, and the rules of this type are defined in `PEP-440 `_. The following example showcases how this type can differentiate pre-releases as being less than a general release. - -.. code-block:: yaml+jinja - - {{ '2.14.0rc1' is version('2.14.0', 'lt', version_type='pep440') }} - -When using ``version`` in a playbook or role, don't use ``{{ }}`` as described in the `FAQ `_ - -.. code-block:: yaml - - vars: - my_version: 1.2.3 - - tasks: - - debug: - msg: "my_version is higher than 1.0.0" - when: my_version is version('1.0.0', '>') - -.. _math_tests: - -Set theory tests -================ - -.. versionadded:: 2.1 - -.. note:: In 2.5 ``issubset`` and ``issuperset`` were renamed to ``subset`` and ``superset`` - -To see if a list includes or is included by another list, you can use 'subset' and 'superset' - -.. code-block:: yaml - - vars: - a: [1,2,3,4,5] - b: [2,3] - tasks: - - debug: - msg: "A includes B" - when: a is superset(b) - - - debug: - msg: "B is included in A" - when: b is subset(a) - -.. _contains_test: - -Testing if a list contains a value -================================== - -.. versionadded:: 2.8 - -Ansible includes a ``contains`` test which operates similarly, but in reverse of the Jinja2 provided ``in`` test. -The ``contains`` test is designed to work with the ``select``, ``reject``, ``selectattr``, and ``rejectattr`` filters - -.. code-block:: yaml - - vars: - lacp_groups: - - master: lacp0 - network: 10.65.100.0/24 - gateway: 10.65.100.1 - dns4: - - 10.65.100.10 - - 10.65.100.11 - interfaces: - - em1 - - em2 - - - master: lacp1 - network: 10.65.120.0/24 - gateway: 10.65.120.1 - dns4: - - 10.65.100.10 - - 10.65.100.11 - interfaces: - - em3 - - em4 - - tasks: - - debug: - msg: "{{ (lacp_groups|selectattr('interfaces', 'contains', 'em1')|first).master }}" - -Testing if a list value is True -=============================== - -.. versionadded:: 2.4 - -You can use `any` and `all` to check if any or all elements in a list are true or not - -.. code-block:: yaml - - vars: - mylist: - - 1 - - "{{ 3 == 3 }}" - - True - myotherlist: - - False - - True - tasks: - - - debug: - msg: "all are true!" - when: mylist is all - - - debug: - msg: "at least one is true" - when: myotherlist is any - -.. _path_tests: - -Testing paths -============= - -.. note:: In 2.5 the following tests were renamed to remove the ``is_`` prefix - -The following tests can provide information about a path on the controller - -.. code-block:: yaml - - - debug: - msg: "path is a directory" - when: mypath is directory - - - debug: - msg: "path is a file" - when: mypath is file - - - debug: - msg: "path is a symlink" - when: mypath is link - - - debug: - msg: "path already exists" - when: mypath is exists - - - debug: - msg: "path is {{ (mypath is abs)|ternary('absolute','relative')}}" - - - debug: - msg: "path is the same file as path2" - when: mypath is same_file(path2) - - - debug: - msg: "path is a mount" - when: mypath is mount - - - debug: - msg: "path is a directory" - when: mypath is directory - vars: - mypath: /my/patth - - - debug: - msg: "path is a file" - when: "'/my/path' is file" - - -Testing size formats -==================== - -The ``human_readable`` and ``human_to_bytes`` functions let you test your -playbooks to make sure you are using the right size format in your tasks, and that -you provide Byte format to computers and human-readable format to people. - -Human readable --------------- - -Asserts whether the given string is human readable or not. - -For example - -.. code-block:: yaml+jinja - - - name: "Human Readable" - assert: - that: - - '"1.00 Bytes" == 1|human_readable' - - '"1.00 bits" == 1|human_readable(isbits=True)' - - '"10.00 KB" == 10240|human_readable' - - '"97.66 MB" == 102400000|human_readable' - - '"0.10 GB" == 102400000|human_readable(unit="G")' - - '"0.10 Gb" == 102400000|human_readable(isbits=True, unit="G")' - -This would result in - -.. code-block:: json - - { "changed": false, "msg": "All assertions passed" } - -Human to bytes --------------- - -Returns the given string in the Bytes format. - -For example - -.. code-block:: yaml+jinja - - - name: "Human to Bytes" - assert: - that: - - "{{'0'|human_to_bytes}} == 0" - - "{{'0.1'|human_to_bytes}} == 0" - - "{{'0.9'|human_to_bytes}} == 1" - - "{{'1'|human_to_bytes}} == 1" - - "{{'10.00 KB'|human_to_bytes}} == 10240" - - "{{ '11 MB'|human_to_bytes}} == 11534336" - - "{{ '1.1 GB'|human_to_bytes}} == 1181116006" - - "{{'10.00 Kb'|human_to_bytes(isbits=True)}} == 10240" - -This would result in - -.. code-block:: json - - { "changed": false, "msg": "All assertions passed" } - - -.. _test_task_results: - -Testing task results -==================== - -The following tasks are illustrative of the tests meant to check the status of tasks - -.. code-block:: yaml - - tasks: - - - shell: /usr/bin/foo - register: result - ignore_errors: True - - - debug: - msg: "it failed" - when: result is failed - - # in most cases you'll want a handler, but if you want to do something right now, this is nice - - debug: - msg: "it changed" - when: result is changed - - - debug: - msg: "it succeeded in Ansible >= 2.1" - when: result is succeeded - - - debug: - msg: "it succeeded" - when: result is success - - - debug: - msg: "it was skipped" - when: result is skipped - -.. note:: From 2.1, you can also use success, failure, change, and skip so that the grammar matches, for those who need to be strict about it. - -.. _type_tests: - -Type Tests -========== - -When looking to determine types, it may be tempting to use the ``type_debug`` filter and compare that to the string name of that type, however, you should instead use type test comparisons, such as: - -.. code-block:: yaml - - tasks: - - name: "String interpretation" - vars: - a_string: "A string" - a_dictionary: {"a": "dictionary"} - a_list: ["a", "list"] - assert: - that: - # Note that a string is classed as also being "iterable" and "sequence", but not "mapping" - - a_string is string and a_string is iterable and a_string is sequence and a_string is not mapping - - # Note that a dictionary is classed as not being a "string", but is "iterable", "sequence" and "mapping" - - a_dictionary is not string and a_dictionary is iterable and a_dictionary is mapping - - # Note that a list is classed as not being a "string" or "mapping" but is "iterable" and "sequence" - - a_list is not string and a_list is not mapping and a_list is iterable - - - name: "Number interpretation" - vars: - a_float: 1.01 - a_float_as_string: "1.01" - an_integer: 1 - an_integer_as_string: "1" - assert: - that: - # Both a_float and an_integer are "number", but each has their own type as well - - a_float is number and a_float is float - - an_integer is number and an_integer is integer - - # Both a_float_as_string and an_integer_as_string are not numbers - - a_float_as_string is not number and a_float_as_string is string - - an_integer_as_string is not number and a_float_as_string is string - - # a_float or a_float_as_string when cast to a float and then to a string should match the same value cast only to a string - - a_float | float | string == a_float | string - - a_float_as_string | float | string == a_float_as_string | string - - # Likewise an_integer and an_integer_as_string when cast to an integer and then to a string should match the same value cast only to an integer - - an_integer | int | string == an_integer | string - - an_integer_as_string | int | string == an_integer_as_string | string - - # However, a_float or a_float_as_string cast as an integer and then a string does not match the same value cast to a string - - a_float | int | string != a_float | string - - a_float_as_string | int | string != a_float_as_string | string - - # Again, Likewise an_integer and an_integer_as_string cast as a float and then a string does not match the same value cast to a string - - an_integer | float | string != an_integer | string - - an_integer_as_string | float | string != an_integer_as_string | string - - - name: "Native Boolean interpretation" - loop: - - yes - - true - - True - - TRUE - - no - - No - - NO - - false - - False - - FALSE - assert: - that: - # Note that while other values may be cast to boolean values, these are the only ones which are natively considered boolean - # Note also that `yes` is the only case sensitive variant of these values. - - item is boolean - -.. _builtin tests: https://jinja.palletsprojects.com/en/latest/templates/#builtin-tests - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_variables` - All about variables - :ref:`playbooks_loops` - Looping in playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - :ref:`tips_and_tricks` - Tips and tricks for playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_variables.rst b/docs/docsite/rst/playbook_guide/playbooks_variables.rst deleted file mode 100644 index 9482845dfd9..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_variables.rst +++ /dev/null @@ -1,534 +0,0 @@ -.. _playbooks_variables: - -*************** -Using Variables -*************** - -Ansible uses variables to manage differences between systems. With Ansible, you can execute tasks and playbooks on multiple different systems with a single command. To represent the variations among those different systems, you can create variables with standard YAML syntax, including lists and dictionaries. You can define these variables in your playbooks, in your :ref:`inventory `, in re-usable :ref:`files ` or :ref:`roles `, or at the command line. You can also create variables during a playbook run by registering the return value or values of a task as a new variable. - -After you create variables, either by defining them in a file, passing them at the command line, or registering the return value or values of a task as a new variable, you can use those variables in module arguments, in :ref:`conditional "when" statements `, in :ref:`templates `, and in :ref:`loops `. The `ansible-examples github repository `_ contains many examples of using variables in Ansible. - -Once you understand the concepts and examples on this page, read about :ref:`Ansible facts `, which are variables you retrieve from remote systems. - -.. contents:: - :local: - -.. _valid_variable_names: - -Creating valid variable names -============================= - -Not all strings are valid Ansible variable names. A variable name can only include letters, numbers, and underscores. `Python keywords`_ or :ref:`playbook keywords` are not valid variable names. A variable name cannot begin with a number. - -Variable names can begin with an underscore. In many programming languages, variables that begin with an underscore are private. This is not true in Ansible. Variables that begin with an underscore are treated exactly the same as any other variable. Do not rely on this convention for privacy or security. - -This table gives examples of valid and invalid variable names: - -.. table:: - :class: documentation-table - - ====================== ==================================================================== - Valid variable names Not valid - ====================== ==================================================================== - ``foo`` ``*foo``, `Python keywords`_ such as ``async`` and ``lambda`` - - ``foo_env`` :ref:`playbook keywords` such as ``environment`` - - ``foo_port`` ``foo-port``, ``foo port``, ``foo.port`` - - ``foo5``, ``_foo`` ``5foo``, ``12`` - ====================== ==================================================================== - -.. _Python keywords: https://docs.python.org/3/reference/lexical_analysis.html#keywords - -Simple variables -================ - -Simple variables combine a variable name with a single value. You can use this syntax (and the syntax for lists and dictionaries shown below) in a variety of places. For details about setting variables in inventory, in playbooks, in reusable files, in roles, or at the command line, see :ref:`setting_variables`. - -Defining simple variables -------------------------- - -You can define a simple variable using standard YAML syntax. For example: - -.. code-block:: text - - remote_install_path: /opt/my_app_config - -Referencing simple variables ----------------------------- - -After you define a variable, use Jinja2 syntax to reference it. Jinja2 variables use double curly braces. For example, the expression ``My amp goes to {{ max_amp_value }}`` demonstrates the most basic form of variable substitution. You can use Jinja2 syntax in playbooks. For example: - -.. code-block:: yaml+jinja - - ansible.builtin.template: - src: foo.cfg.j2 - dest: '{{ remote_install_path }}/foo.cfg' - -In this example, the variable defines the location of a file, which can vary from one system to another. - -.. note:: - - Ansible allows Jinja2 loops and conditionals in :ref:`templates ` but not in playbooks. You cannot create a loop of tasks. Ansible playbooks are pure machine-parseable YAML. - -.. _yaml_gotchas: - -When to quote variables (a YAML gotcha) -======================================= - -If you start a value with ``{{ foo }}``, you must quote the whole expression to create valid YAML syntax. If you do not quote the whole expression, the YAML parser cannot interpret the syntax - it might be a variable or it might be the start of a YAML dictionary. For guidance on writing YAML, see the :ref:`yaml_syntax` documentation. - -If you use a variable without quotes like this: - -.. code-block:: yaml+jinja - - - hosts: app_servers - vars: - app_path: {{ base_path }}/22 - -You will see: ``ERROR! Syntax Error while loading YAML.`` If you add quotes, Ansible works correctly: - -.. code-block:: yaml+jinja - - - hosts: app_servers - vars: - app_path: "{{ base_path }}/22" - -.. _boolean_variables: - -Boolean variables -================= - -Ansible accepts a broad range of values for boolean variables: ``true/false``, ``1/0``, ``yes/no``, ``True/False`` and so on. The matching of valid strings is case insensitive. -While documentation examples focus on ``true/false`` to be compatible with ``ansible-lint`` default settings, you can use any of the following: - -.. table:: - :class: documentation-table - - =============================================================================================== ==================================================================== - Valid values Description - =============================================================================================== ==================================================================== - ``True`` , ``'true'`` , ``'t'`` , ``'yes'`` , ``'y'`` , ``'on'`` , ``'1'`` , ``1`` , ``1.0`` Truthy values - - ``False`` , ``'false'`` , ``'f'`` , ``'no'`` , ``'n'`` , ``'off'`` , ``'0'`` , ``0`` , ``0.0`` Falsy values - - =============================================================================================== ==================================================================== - -.. _list_variables: - -List variables -============== - -A list variable combines a variable name with multiple values. The multiple values can be stored as an itemized list or in square brackets ``[]``, separated with commas. - -Defining variables as lists ---------------------------- - -You can define variables with multiple values using YAML lists. For example: - -.. code-block:: yaml - - region: - - northeast - - southeast - - midwest - -Referencing list variables --------------------------- - -When you use variables defined as a list (also called an array), you can use individual, specific fields from that list. The first item in a list is item 0, the second item is item 1. For example: - -.. code-block:: yaml+jinja - - region: "{{ region[0] }}" - -The value of this expression would be "northeast". - -.. _dictionary_variables: - -Dictionary variables -==================== - -A dictionary stores the data in key-value pairs. Usually, dictionaries are used to store related data, such as the information contained in an ID or a user profile. - -Defining variables as key:value dictionaries --------------------------------------------- - -You can define more complex variables using YAML dictionaries. A YAML dictionary maps keys to values. For example: - -.. code-block:: yaml - - foo: - field1: one - field2: two - -Referencing key:value dictionary variables ------------------------------------------- - -When you use variables defined as a key:value dictionary (also called a hash), you can use individual, specific fields from that dictionary using either bracket notation or dot notation: - -.. code-block:: yaml - - foo['field1'] - foo.field1 - -Both of these examples reference the same value ("one"). Bracket notation always works. Dot notation can cause problems because some keys collide with attributes and methods of python dictionaries. Use bracket notation if you use keys which start and end with two underscores (which are reserved for special meanings in python) or are any of the known public attributes: - -``add``, ``append``, ``as_integer_ratio``, ``bit_length``, ``capitalize``, ``center``, ``clear``, ``conjugate``, ``copy``, ``count``, ``decode``, ``denominator``, ``difference``, ``difference_update``, ``discard``, ``encode``, ``endswith``, ``expandtabs``, ``extend``, ``find``, ``format``, ``fromhex``, ``fromkeys``, ``get``, ``has_key``, ``hex``, ``imag``, ``index``, ``insert``, ``intersection``, ``intersection_update``, ``isalnum``, ``isalpha``, ``isdecimal``, ``isdigit``, ``isdisjoint``, ``is_integer``, ``islower``, ``isnumeric``, ``isspace``, ``issubset``, ``issuperset``, ``istitle``, ``isupper``, ``items``, ``iteritems``, ``iterkeys``, ``itervalues``, ``join``, ``keys``, ``ljust``, ``lower``, ``lstrip``, ``numerator``, ``partition``, ``pop``, ``popitem``, ``real``, ``remove``, ``replace``, ``reverse``, ``rfind``, ``rindex``, ``rjust``, ``rpartition``, ``rsplit``, ``rstrip``, ``setdefault``, ``sort``, ``split``, ``splitlines``, ``startswith``, ``strip``, ``swapcase``, ``symmetric_difference``, ``symmetric_difference_update``, ``title``, ``translate``, ``union``, ``update``, ``upper``, ``values``, ``viewitems``, ``viewkeys``, ``viewvalues``, ``zfill``. - -.. _registered_variables: - -Registering variables -===================== - -You can create variables from the output of an Ansible task with the task keyword ``register``. You can use registered variables in any later tasks in your play. For example: - -.. code-block:: yaml - - - hosts: web_servers - - tasks: - - - name: Run a shell command and register its output as a variable - ansible.builtin.shell: /usr/bin/foo - register: foo_result - ignore_errors: true - - - name: Run a shell command using output of the previous task - ansible.builtin.shell: /usr/bin/bar - when: foo_result.rc == 5 - -For more examples of using registered variables in conditions on later tasks, see :ref:`playbooks_conditionals`. Registered variables may be simple variables, list variables, dictionary variables, or complex nested data structures. The documentation for each module includes a ``RETURN`` section describing the return values for that module. To see the values for a particular task, run your playbook with ``-v``. - -Registered variables are stored in memory. You cannot cache registered variables for use in future playbook runs. Registered variables are only valid on the host for the rest of the current playbook run, including subsequent plays within the same playbook run. - -Registered variables are host-level variables. When you register a variable in a task with a loop, the registered variable contains a value for each item in the loop. The data structure placed in the variable during the loop will contain a ``results`` attribute, that is a list of all responses from the module. For a more in-depth example of how this works, see the :ref:`playbooks_loops` section on using register with a loop. - -.. note:: If a task fails or is skipped, Ansible still registers a variable with a failure or skipped status, unless the task is skipped based on tags. See :ref:`tags` for information on adding and using tags. - -.. _accessing_complex_variable_data: - -Referencing nested variables -============================ - -Many registered variables (and :ref:`facts `) are nested YAML or JSON data structures. You cannot access values from these nested data structures with the simple ``{{ foo }}`` syntax. You must use either bracket notation or dot notation. For example, to reference an IP address from your facts using the bracket notation: - -.. code-block:: yaml+jinja - - {{ ansible_facts["eth0"]["ipv4"]["address"] }} - -To reference an IP address from your facts using the dot notation: - -.. code-block:: yaml+jinja - - {{ ansible_facts.eth0.ipv4.address }} - -.. _about_jinja2: -.. _jinja2_filters: - -Transforming variables with Jinja2 filters -========================================== - -Jinja2 filters let you transform the value of a variable within a template expression. For example, the ``capitalize`` filter capitalizes any value passed to it; the ``to_yaml`` and ``to_json`` filters change the format of your variable values. Jinja2 includes many `built-in filters `_ and Ansible supplies many more filters. To find more examples of filters, see :ref:`playbooks_filters`. - -.. _setting_variables: - -Where to set variables -====================== - -You can define variables in a variety of places, such as in inventory, in playbooks, in reusable files, in roles, and at the command line. Ansible loads every possible variable it finds, then chooses the variable to apply based on :ref:`variable precedence rules `. - -.. _define_variables_in_inventory: - -Defining variables in inventory -------------------------------- - -You can define different variables for each individual host, or set shared variables for a group of hosts in your inventory. For example, if all machines in the ``[Boston]`` group use 'boston.ntp.example.com' as an NTP server, you can set a group variable. The :ref:`intro_inventory` page has details on setting :ref:`host variables ` and :ref:`group variables ` in inventory. - -.. _playbook_variables: - -Defining variables in a play ----------------------------- - -You can define variables directly in a playbook play: - -.. code-block:: yaml - - - hosts: webservers - vars: - http_port: 80 - -When you define variables in a play, they are only visible to tasks executed in that play. - -.. _included_variables: -.. _variable_file_separation_details: - -Defining variables in included files and roles ----------------------------------------------- - -You can define variables in reusable variables files and/or in reusable roles. When you define variables in reusable variable files, the sensitive variables are separated from playbooks. This separation enables you to store your playbooks in a source control software and even share the playbooks, without the risk of exposing passwords or other sensitive and personal data. For information about creating reusable files and roles, see :ref:`playbooks_reuse`. - -This example shows how you can include variables defined in an external file: - -.. code-block:: yaml - - --- - - - hosts: all - remote_user: root - vars: - favcolor: blue - vars_files: - - /vars/external_vars.yml - - tasks: - - - name: This is just a placeholder - ansible.builtin.command: /bin/echo foo - -The contents of each variables file is a simple YAML dictionary. For example: - -.. code-block:: yaml - - --- - # in the above example, this would be vars/external_vars.yml - somevar: somevalue - password: magic - -.. note:: - You can keep per-host and per-group variables in similar files. To learn about organizing your variables, see :ref:`splitting_out_vars`. - -.. _passing_variables_on_the_command_line: - -Defining variables at runtime ------------------------------ - -You can define variables when you run your playbook by passing variables at the command line using the ``--extra-vars`` (or ``-e``) argument. You can also request user input with a ``vars_prompt`` (see :ref:`playbooks_prompts`). When you pass variables at the command line, use a single quoted string, that contains one or more variables, in one of the formats below. - -key=value format -^^^^^^^^^^^^^^^^ - -Values passed in using the ``key=value`` syntax are interpreted as strings. Use the JSON format if you need to pass non-string values such as Booleans, integers, floats, lists, and so on. - -.. code-block:: text - - ansible-playbook release.yml --extra-vars "version=1.23.45 other_variable=foo" - -JSON string format -^^^^^^^^^^^^^^^^^^ - -.. code-block:: shell - - ansible-playbook release.yml --extra-vars '{"version":"1.23.45","other_variable":"foo"}' - ansible-playbook arcade.yml --extra-vars '{"pacman":"mrs","ghosts":["inky","pinky","clyde","sue"]}' - -When passing variables with ``--extra-vars``, you must escape quotes and other special characters appropriately for both your markup (for example, JSON), and for your shell: - -.. code-block:: shell - - ansible-playbook arcade.yml --extra-vars "{\"name\":\"Conan O\'Brien\"}" - ansible-playbook arcade.yml --extra-vars '{"name":"Conan O'\\\''Brien"}' - ansible-playbook script.yml --extra-vars "{\"dialog\":\"He said \\\"I just can\'t get enough of those single and double-quotes"\!"\\\"\"}" - - -vars from a JSON or YAML file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you have a lot of special characters, use a JSON or YAML file containing the variable definitions. Prepend both JSON and YAML filenames with `@`. - -.. code-block:: text - - ansible-playbook release.yml --extra-vars "@some_file.json" - ansible-playbook release.yml --extra-vars "@some_file.yaml" - - -.. _ansible_variable_precedence: - -Variable precedence: Where should I put a variable? -=================================================== - -You can set multiple variables with the same name in many different places. When you do this, Ansible loads every possible variable it finds, then chooses the variable to apply based on variable precedence. In other words, the different variables will override each other in a certain order. - -Teams and projects that agree on guidelines for defining variables (where to define certain types of variables) usually avoid variable precedence concerns. We suggest that you define each variable in one place: figure out where to define a variable, and keep it simple. For examples, see :ref:`variable_examples`. - -Some behavioral parameters that you can set in variables you can also set in Ansible configuration, as command-line options, and using playbook keywords. For example, you can define the user Ansible uses to connect to remote devices as a variable with ``ansible_user``, in a configuration file with ``DEFAULT_REMOTE_USER``, as a command-line option with ``-u``, and with the playbook keyword ``remote_user``. If you define the same parameter in a variable and by another method, the variable overrides the other setting. This approach allows host-specific settings to override more general settings. For examples and more details on the precedence of these various settings, see :ref:`general_precedence_rules`. - -Understanding variable precedence ---------------------------------- - -Ansible does apply variable precedence, and you might have a use for it. Here is the order of precedence from least to greatest (the last listed variables override all other variables): - - #. command line values (for example, ``-u my_user``, these are not variables) - #. role defaults (defined in role/defaults/main.yml) [1]_ - #. inventory file or script group vars [2]_ - #. inventory group_vars/all [3]_ - #. playbook group_vars/all [3]_ - #. inventory group_vars/* [3]_ - #. playbook group_vars/* [3]_ - #. inventory file or script host vars [2]_ - #. inventory host_vars/* [3]_ - #. playbook host_vars/* [3]_ - #. host facts / cached set_facts [4]_ - #. play vars - #. play vars_prompt - #. play vars_files - #. role vars (defined in role/vars/main.yml) - #. block vars (only for tasks in block) - #. task vars (only for the task) - #. include_vars - #. set_facts / registered vars - #. role (and include_role) params - #. include params - #. extra vars (for example, ``-e "user=my_user"``)(always win precedence) - -In general, Ansible gives precedence to variables that were defined more recently, more actively, and with more explicit scope. Variables in the defaults folder inside a role are easily overridden. Anything in the vars directory of the role overrides previous versions of that variable in the namespace. Host and/or inventory variables override role defaults, but explicit includes such as the vars directory or an ``include_vars`` task override inventory variables. - -Ansible merges different variables set in inventory so that more specific settings override more generic settings. For example, ``ansible_ssh_user`` specified as a group_var is overridden by ``ansible_user`` specified as a host_var. For details about the precedence of variables set in inventory, see :ref:`how_we_merge`. - -.. rubric:: Footnotes - -.. [1] Tasks in each role see their own role's defaults. Tasks defined outside of a role see the last role's defaults. -.. [2] Variables defined in inventory file or provided by dynamic inventory. -.. [3] Includes vars added by 'vars plugins' as well as host_vars and group_vars which are added by the default vars plugin shipped with Ansible. -.. [4] When created with set_facts's cacheable option, variables have the high precedence in the play, - but are the same as a host facts precedence when they come from the cache. - -.. note:: Within any section, redefining a var overrides the previous instance. - If multiple groups have the same variable, the last one loaded wins. - If you define a variable twice in a play's ``vars:`` section, the second one wins. -.. note:: The previous describes the default config ``hash_behaviour=replace``, switch to ``merge`` to only partially overwrite. - -.. _variable_scopes: - -Scoping variables ------------------ - -You can decide where to set a variable based on the scope you want that value to have. Ansible has three main scopes: - - * Global: this is set by config, environment variables and the command line - * Play: each play and contained structures, vars entries (vars; vars_files; vars_prompt), role defaults and vars. - * Host: variables directly associated to a host, like inventory, include_vars, facts or registered task outputs - -Inside a template, you automatically have access to all variables that are in scope for a host, plus any registered variables, facts, and magic variables. - -.. _variable_examples: - -Tips on where to set variables ------------------------------- - -You should choose where to define a variable based on the kind of control you might want over values. - -Set variables in inventory that deal with geography or behavior. Since groups are frequently the entity that maps roles onto hosts, you can often set variables on the group instead of defining them on a role. Remember: child groups override parent groups, and host variables override group variables. See :ref:`define_variables_in_inventory` for details on setting host and group variables. - -Set common defaults in a ``group_vars/all`` file. See :ref:`splitting_out_vars` for details on how to organize host and group variables in your inventory. Group variables are generally placed alongside your inventory file, but they can also be returned by dynamic inventory (see :ref:`intro_dynamic_inventory`) or defined in AWX or on :ref:`ansible_platform` from the UI or API: - -.. code-block:: yaml - - --- - # file: /etc/ansible/group_vars/all - # this is the site wide default - ntp_server: default-time.example.com - -Set location-specific variables in ``group_vars/my_location`` files. All groups are children of the ``all`` group, so variables set here override those set in ``group_vars/all``: - -.. code-block:: yaml - - --- - # file: /etc/ansible/group_vars/boston - ntp_server: boston-time.example.com - -If one host used a different NTP server, you could set that in a host_vars file, which would override the group variable: - -.. code-block:: yaml - - --- - # file: /etc/ansible/host_vars/xyz.boston.example.com - ntp_server: override.example.com - -Set defaults in roles to avoid undefined-variable errors. If you share your roles, other users can rely on the reasonable defaults you added in the ``roles/x/defaults/main.yml`` file, or they can easily override those values in inventory or at the command line. See :ref:`playbooks_reuse_roles` for more info. For example: - -.. code-block:: yaml - - --- - # file: roles/x/defaults/main.yml - # if no other value is supplied in inventory or as a parameter, this value will be used - http_port: 80 - -Set variables in roles to ensure a value is used in that role, and is not overridden by inventory variables. If you are not sharing your role with others, you can define app-specific behaviors like ports this way, in ``roles/x/vars/main.yml``. If you are sharing roles with others, putting variables here makes them harder to override, although they still can by passing a parameter to the role or setting a variable with ``-e``: - -.. code-block:: yaml - - --- - # file: roles/x/vars/main.yml - # this will absolutely be used in this role - http_port: 80 - -Pass variables as parameters when you call roles for maximum clarity, flexibility, and visibility. This approach overrides any defaults that exist for a role. For example: - -.. code-block:: yaml - - roles: - - role: apache - vars: - http_port: 8080 - -When you read this playbook it is clear that you have chosen to set a variable or override a default. You can also pass multiple values, which allows you to run the same role multiple times. See :ref:`run_role_twice` for more details. For example: - -.. code-block:: yaml - - roles: - - role: app_user - vars: - myname: Ian - - role: app_user - vars: - myname: Terry - - role: app_user - vars: - myname: Graham - - role: app_user - vars: - myname: John - -Variables set in one role are available to later roles. You can set variables in a ``roles/common_settings/vars/main.yml`` file and use them in other roles and elsewhere in your playbook: - -.. code-block:: yaml - - roles: - - role: common_settings - - role: something - vars: - foo: 12 - - role: something_else - -.. note:: There are some protections in place to avoid the need to namespace variables. - In this example, variables defined in 'common_settings' are available to 'something' and 'something_else' tasks, but tasks in 'something' have foo set at 12, even if 'common_settings' sets foo to 20. - -Instead of worrying about variable precedence, we encourage you to think about how easily or how often you want to override a variable when deciding where to set it. If you are not sure what other variables are defined, and you need a particular value, use ``--extra-vars`` (``-e``) to override all other variables. - -Using advanced variable syntax -============================== - -For information about advanced YAML syntax used to declare variables and have more control over the data placed in YAML files used by Ansible, see :ref:`playbooks_advanced_syntax`. - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_filters` - Jinja2 filters and their uses - :ref:`playbooks_loops` - Looping in playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - :ref:`tips_and_tricks` - Tips and tricks for playbooks - :ref:`special_variables` - List of special variables - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_vars_facts.rst b/docs/docsite/rst/playbook_guide/playbooks_vars_facts.rst deleted file mode 100644 index e90947e6f54..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_vars_facts.rst +++ /dev/null @@ -1,714 +0,0 @@ -.. _vars_and_facts: - -************************************************ -Discovering variables: facts and magic variables -************************************************ - -With Ansible you can retrieve or discover certain variables containing information about your remote systems or about Ansible itself. Variables related to remote systems are called facts. With facts, you can use the behavior or state of one system as configuration on other systems. For example, you can use the IP address of one system as a configuration value on another system. Variables related to Ansible are called magic variables. - -.. contents:: - :local: - -Ansible facts -============= - -Ansible facts are data related to your remote systems, including operating systems, IP addresses, attached filesystems, and more. You can access this data in the ``ansible_facts`` variable. By default, you can also access some Ansible facts as top-level variables with the ``ansible_`` prefix. You can disable this behavior using the :ref:`INJECT_FACTS_AS_VARS` setting. To see all available facts, add this task to a play: - -.. code-block:: yaml - - - name: Print all available facts - ansible.builtin.debug: - var: ansible_facts - -To see the 'raw' information as gathered, run this command at the command line: - -.. code-block:: shell - - ansible -m ansible.builtin.setup - -Facts include a large amount of variable data, which may look like this: - -.. code-block:: json - - { - "ansible_all_ipv4_addresses": [ - "REDACTED IP ADDRESS" - ], - "ansible_all_ipv6_addresses": [ - "REDACTED IPV6 ADDRESS" - ], - "ansible_apparmor": { - "status": "disabled" - }, - "ansible_architecture": "x86_64", - "ansible_bios_date": "11/28/2013", - "ansible_bios_version": "4.1.5", - "ansible_cmdline": { - "BOOT_IMAGE": "/boot/vmlinuz-3.10.0-862.14.4.el7.x86_64", - "console": "ttyS0,115200", - "no_timer_check": true, - "nofb": true, - "nomodeset": true, - "ro": true, - "root": "LABEL=cloudimg-rootfs", - "vga": "normal" - }, - "ansible_date_time": { - "date": "2018-10-25", - "day": "25", - "epoch": "1540469324", - "hour": "12", - "iso8601": "2018-10-25T12:08:44Z", - "iso8601_basic": "20181025T120844109754", - "iso8601_basic_short": "20181025T120844", - "iso8601_micro": "2018-10-25T12:08:44.109968Z", - "minute": "08", - "month": "10", - "second": "44", - "time": "12:08:44", - "tz": "UTC", - "tz_offset": "+0000", - "weekday": "Thursday", - "weekday_number": "4", - "weeknumber": "43", - "year": "2018" - }, - "ansible_default_ipv4": { - "address": "REDACTED", - "alias": "eth0", - "broadcast": "REDACTED", - "gateway": "REDACTED", - "interface": "eth0", - "macaddress": "REDACTED", - "mtu": 1500, - "netmask": "255.255.255.0", - "network": "REDACTED", - "type": "ether" - }, - "ansible_default_ipv6": {}, - "ansible_device_links": { - "ids": {}, - "labels": { - "xvda1": [ - "cloudimg-rootfs" - ], - "xvdd": [ - "config-2" - ] - }, - "masters": {}, - "uuids": { - "xvda1": [ - "cac81d61-d0f8-4b47-84aa-b48798239164" - ], - "xvdd": [ - "2018-10-25-12-05-57-00" - ] - } - }, - "ansible_devices": { - "xvda": { - "holders": [], - "host": "", - "links": { - "ids": [], - "labels": [], - "masters": [], - "uuids": [] - }, - "model": null, - "partitions": { - "xvda1": { - "holders": [], - "links": { - "ids": [], - "labels": [ - "cloudimg-rootfs" - ], - "masters": [], - "uuids": [ - "cac81d61-d0f8-4b47-84aa-b48798239164" - ] - }, - "sectors": "83883999", - "sectorsize": 512, - "size": "40.00 GB", - "start": "2048", - "uuid": "cac81d61-d0f8-4b47-84aa-b48798239164" - } - }, - "removable": "0", - "rotational": "0", - "sas_address": null, - "sas_device_handle": null, - "scheduler_mode": "deadline", - "sectors": "83886080", - "sectorsize": "512", - "size": "40.00 GB", - "support_discard": "0", - "vendor": null, - "virtual": 1 - }, - "xvdd": { - "holders": [], - "host": "", - "links": { - "ids": [], - "labels": [ - "config-2" - ], - "masters": [], - "uuids": [ - "2018-10-25-12-05-57-00" - ] - }, - "model": null, - "partitions": {}, - "removable": "0", - "rotational": "0", - "sas_address": null, - "sas_device_handle": null, - "scheduler_mode": "deadline", - "sectors": "131072", - "sectorsize": "512", - "size": "64.00 MB", - "support_discard": "0", - "vendor": null, - "virtual": 1 - }, - "xvde": { - "holders": [], - "host": "", - "links": { - "ids": [], - "labels": [], - "masters": [], - "uuids": [] - }, - "model": null, - "partitions": { - "xvde1": { - "holders": [], - "links": { - "ids": [], - "labels": [], - "masters": [], - "uuids": [] - }, - "sectors": "167770112", - "sectorsize": 512, - "size": "80.00 GB", - "start": "2048", - "uuid": null - } - }, - "removable": "0", - "rotational": "0", - "sas_address": null, - "sas_device_handle": null, - "scheduler_mode": "deadline", - "sectors": "167772160", - "sectorsize": "512", - "size": "80.00 GB", - "support_discard": "0", - "vendor": null, - "virtual": 1 - } - }, - "ansible_distribution": "CentOS", - "ansible_distribution_file_parsed": true, - "ansible_distribution_file_path": "/etc/redhat-release", - "ansible_distribution_file_variety": "RedHat", - "ansible_distribution_major_version": "7", - "ansible_distribution_release": "Core", - "ansible_distribution_version": "7.5.1804", - "ansible_dns": { - "nameservers": [ - "127.0.0.1" - ] - }, - "ansible_domain": "", - "ansible_effective_group_id": 1000, - "ansible_effective_user_id": 1000, - "ansible_env": { - "HOME": "/home/zuul", - "LANG": "en_US.UTF-8", - "LESSOPEN": "||/usr/bin/lesspipe.sh %s", - "LOGNAME": "zuul", - "MAIL": "/var/mail/zuul", - "PATH": "/usr/local/bin:/usr/bin", - "PWD": "/home/zuul", - "SELINUX_LEVEL_REQUESTED": "", - "SELINUX_ROLE_REQUESTED": "", - "SELINUX_USE_CURRENT_RANGE": "", - "SHELL": "/bin/bash", - "SHLVL": "2", - "SSH_CLIENT": "REDACTED 55672 22", - "SSH_CONNECTION": "REDACTED 55672 REDACTED 22", - "USER": "zuul", - "XDG_RUNTIME_DIR": "/run/user/1000", - "XDG_SESSION_ID": "1", - "_": "/usr/bin/python2" - }, - "ansible_eth0": { - "active": true, - "device": "eth0", - "ipv4": { - "address": "REDACTED", - "broadcast": "REDACTED", - "netmask": "255.255.255.0", - "network": "REDACTED" - }, - "ipv6": [ - { - "address": "REDACTED", - "prefix": "64", - "scope": "link" - } - ], - "macaddress": "REDACTED", - "module": "xen_netfront", - "mtu": 1500, - "pciid": "vif-0", - "promisc": false, - "type": "ether" - }, - "ansible_eth1": { - "active": true, - "device": "eth1", - "ipv4": { - "address": "REDACTED", - "broadcast": "REDACTED", - "netmask": "255.255.224.0", - "network": "REDACTED" - }, - "ipv6": [ - { - "address": "REDACTED", - "prefix": "64", - "scope": "link" - } - ], - "macaddress": "REDACTED", - "module": "xen_netfront", - "mtu": 1500, - "pciid": "vif-1", - "promisc": false, - "type": "ether" - }, - "ansible_fips": false, - "ansible_form_factor": "Other", - "ansible_fqdn": "centos-7-rax-dfw-0003427354", - "ansible_hostname": "centos-7-rax-dfw-0003427354", - "ansible_interfaces": [ - "lo", - "eth1", - "eth0" - ], - "ansible_is_chroot": false, - "ansible_kernel": "3.10.0-862.14.4.el7.x86_64", - "ansible_lo": { - "active": true, - "device": "lo", - "ipv4": { - "address": "127.0.0.1", - "broadcast": "host", - "netmask": "255.0.0.0", - "network": "127.0.0.0" - }, - "ipv6": [ - { - "address": "::1", - "prefix": "128", - "scope": "host" - } - ], - "mtu": 65536, - "promisc": false, - "type": "loopback" - }, - "ansible_local": {}, - "ansible_lsb": { - "codename": "Core", - "description": "CentOS Linux release 7.5.1804 (Core)", - "id": "CentOS", - "major_release": "7", - "release": "7.5.1804" - }, - "ansible_machine": "x86_64", - "ansible_machine_id": "2db133253c984c82aef2fafcce6f2bed", - "ansible_memfree_mb": 7709, - "ansible_memory_mb": { - "nocache": { - "free": 7804, - "used": 173 - }, - "real": { - "free": 7709, - "total": 7977, - "used": 268 - }, - "swap": { - "cached": 0, - "free": 0, - "total": 0, - "used": 0 - } - }, - "ansible_memtotal_mb": 7977, - "ansible_mounts": [ - { - "block_available": 7220998, - "block_size": 4096, - "block_total": 9817227, - "block_used": 2596229, - "device": "/dev/xvda1", - "fstype": "ext4", - "inode_available": 10052341, - "inode_total": 10419200, - "inode_used": 366859, - "mount": "/", - "options": "rw,seclabel,relatime,data=ordered", - "size_available": 29577207808, - "size_total": 40211361792, - "uuid": "cac81d61-d0f8-4b47-84aa-b48798239164" - }, - { - "block_available": 0, - "block_size": 2048, - "block_total": 252, - "block_used": 252, - "device": "/dev/xvdd", - "fstype": "iso9660", - "inode_available": 0, - "inode_total": 0, - "inode_used": 0, - "mount": "/mnt/config", - "options": "ro,relatime,mode=0700", - "size_available": 0, - "size_total": 516096, - "uuid": "2018-10-25-12-05-57-00" - } - ], - "ansible_nodename": "centos-7-rax-dfw-0003427354", - "ansible_os_family": "RedHat", - "ansible_pkg_mgr": "yum", - "ansible_processor": [ - "0", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "1", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "2", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "3", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "4", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "5", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "6", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "7", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz" - ], - "ansible_processor_cores": 8, - "ansible_processor_count": 8, - "ansible_processor_nproc": 8, - "ansible_processor_threads_per_core": 1, - "ansible_processor_vcpus": 8, - "ansible_product_name": "HVM domU", - "ansible_product_serial": "REDACTED", - "ansible_product_uuid": "REDACTED", - "ansible_product_version": "4.1.5", - "ansible_python": { - "executable": "/usr/bin/python2", - "has_sslcontext": true, - "type": "CPython", - "version": { - "major": 2, - "micro": 5, - "minor": 7, - "releaselevel": "final", - "serial": 0 - }, - "version_info": [ - 2, - 7, - 5, - "final", - 0 - ] - }, - "ansible_python_version": "2.7.5", - "ansible_real_group_id": 1000, - "ansible_real_user_id": 1000, - "ansible_selinux": { - "config_mode": "enforcing", - "mode": "enforcing", - "policyvers": 31, - "status": "enabled", - "type": "targeted" - }, - "ansible_selinux_python_present": true, - "ansible_service_mgr": "systemd", - "ansible_ssh_host_key_ecdsa_public": "REDACTED KEY VALUE", - "ansible_ssh_host_key_ed25519_public": "REDACTED KEY VALUE", - "ansible_ssh_host_key_rsa_public": "REDACTED KEY VALUE", - "ansible_swapfree_mb": 0, - "ansible_swaptotal_mb": 0, - "ansible_system": "Linux", - "ansible_system_capabilities": [ - "" - ], - "ansible_system_capabilities_enforced": "True", - "ansible_system_vendor": "Xen", - "ansible_uptime_seconds": 151, - "ansible_user_dir": "/home/zuul", - "ansible_user_gecos": "", - "ansible_user_gid": 1000, - "ansible_user_id": "zuul", - "ansible_user_shell": "/bin/bash", - "ansible_user_uid": 1000, - "ansible_userspace_architecture": "x86_64", - "ansible_userspace_bits": "64", - "ansible_virtualization_role": "guest", - "ansible_virtualization_type": "xen", - "gather_subset": [ - "all" - ], - "module_setup": true - } - -You can reference the model of the first disk in the facts shown above in a template or playbook as: - -.. code-block:: jinja - - {{ ansible_facts['devices']['xvda']['model'] }} - -To reference the system hostname: - -.. code-block:: jinja - - {{ ansible_facts['nodename'] }} - -You can use facts in conditionals (see :ref:`playbooks_conditionals`) and also in templates. You can also use facts to create dynamic groups of hosts that match particular criteria, see the :ref:`group_by module ` documentation for details. - -.. note:: Because ``ansible_date_time`` is created and cached when Ansible gathers facts before each playbook run, it can get stale with long-running playbooks. If your playbook takes a long time to run, use the ``pipe`` filter (for example, ``lookup('pipe', 'date +%Y-%m-%d.%H:%M:%S')``) or :ref:`now() ` with a Jinja 2 template instead of ``ansible_date_time``. - -.. _fact_requirements: - -Package requirements for fact gathering ---------------------------------------- - -On some distros, you may see missing fact values or facts set to default values because the packages that support gathering those facts are not installed by default. You can install the necessary packages on your remote hosts using the OS package manager. Known dependencies include: - -* Linux Network fact gathering - Depends on the ``ip`` binary, commonly included in the ``iproute2`` package. - -.. _fact_caching: - -Caching facts -------------- - -Like registered variables, facts are stored in memory by default. However, unlike registered variables, facts can be gathered independently and cached for repeated use. With cached facts, you can refer to facts from one system when configuring a second system, even if Ansible executes the current play on the second system first. For example: - -.. code-block:: jinja - - {{ hostvars['asdf.example.com']['ansible_facts']['os_family'] }} - -Caching is controlled by the cache plugins. By default, Ansible uses the memory cache plugin, which stores facts in memory for the duration of the current playbook run. To retain Ansible facts for repeated use, select a different cache plugin. See :ref:`cache_plugins` for details. - -Fact caching can improve performance. If you manage thousands of hosts, you can configure fact caching to run nightly, then manage configuration on a smaller set of servers periodically throughout the day. With cached facts, you have access to variables and information about all hosts even when you are only managing a small number of servers. - -.. _disabling_facts: - -Disabling facts ---------------- - -By default, Ansible gathers facts at the beginning of each play. If you do not need to gather facts (for example, if you know everything about your systems centrally), you can turn off fact gathering at the play level to improve scalability. Disabling facts may particularly improve performance in push mode with very large numbers of systems, or if you are using Ansible on experimental platforms. To disable fact gathering: - -.. code-block:: yaml - - - hosts: whatever - gather_facts: false - -Adding custom facts -------------------- - -The setup module in Ansible automatically discovers a standard set of facts about each host. If you want to add custom values to your facts, you can write a custom facts module, set temporary facts with a ``ansible.builtin.set_fact`` task, or provide permanent custom facts using the facts.d directory. - -.. _local_facts: - -facts.d or local facts -^^^^^^^^^^^^^^^^^^^^^^ - -.. versionadded:: 1.3 - -You can add static custom facts by adding static files to facts.d, or add dynamic facts by adding executable scripts to facts.d. For example, you can add a list of all users on a host to your facts by creating and running a script in facts.d. - -To use facts.d, create an ``/etc/ansible/facts.d`` directory on the remote host or hosts. If you prefer a different directory, create it and specify it using the ``fact_path`` play keyword. Add files to the directory to supply your custom facts. All file names must end with ``.fact``. The files can be JSON, INI, or executable files returning JSON. - -To add static facts, simply add a file with the ``.fact`` extension. For example, create ``/etc/ansible/facts.d/preferences.fact`` with this content: - -.. code-block:: ini - - [general] - asdf=1 - bar=2 - -.. note:: Make sure the file is not executable as this will break the ``ansible.builtin.setup`` module. - -The next time fact gathering runs, your facts will include a hash variable fact named ``general`` with ``asdf`` and ``bar`` as members. To validate this, run the following: - -.. code-block:: shell - - ansible -m ansible.builtin.setup -a "filter=ansible_local" - -And you will see your custom fact added: - -.. code-block:: json - - { - "ansible_local": { - "preferences": { - "general": { - "asdf" : "1", - "bar" : "2" - } - } - } - } - -The ansible_local namespace separates custom facts created by facts.d from system facts or variables defined elsewhere in the playbook, so variables will not override each other. You can access this custom fact in a template or playbook as: - -.. code-block:: jinja - - {{ ansible_local['preferences']['general']['asdf'] }} - -.. note:: The key part in the key=value pairs will be converted into lowercase inside the ansible_local variable. Using the example above, if the ini file contained ``XYZ=3`` in the ``[general]`` section, then you should expect to access it as: ``{{ ansible_local['preferences']['general']['xyz'] }}`` and not ``{{ ansible_local['preferences']['general']['XYZ'] }}``. This is because Ansible uses Python's `ConfigParser`_ which passes all option names through the `optionxform`_ method and this method's default implementation converts option names to lower case. - -.. _ConfigParser: https://docs.python.org/3/library/configparser.html -.. _optionxform: https://docs.python.org/3/library/configparser.html#ConfigParser.RawConfigParser.optionxform - -You can also use facts.d to execute a script on the remote host, generating dynamic custom facts to the ansible_local namespace. For example, you can generate a list of all users that exist on a remote host as a fact about that host. To generate dynamic custom facts using facts.d: - - #. Write and test a script to generate the JSON data you want. - #. Save the script in your facts.d directory. - #. Make sure your script has the ``.fact`` file extension. - #. Make sure your script is executable by the Ansible connection user. - #. Gather facts to execute the script and add the JSON output to ansible_local. - -By default, fact gathering runs once at the beginning of each play. If you create a custom fact using facts.d in a playbook, it will be available in the next play that gathers facts. If you want to use it in the same play where you created it, you must explicitly re-run the setup module. For example: - -.. code-block:: yaml - - - hosts: webservers - tasks: - - - name: Create directory for ansible custom facts - ansible.builtin.file: - state: directory - recurse: true - path: /etc/ansible/facts.d - - - name: Install custom ipmi fact - ansible.builtin.copy: - src: ipmi.fact - dest: /etc/ansible/facts.d - - - name: Re-read facts after adding custom fact - ansible.builtin.setup: - filter: ansible_local - -If you use this pattern frequently, a custom facts module would be more efficient than facts.d. - -.. _magic_variables_and_hostvars: - -Information about Ansible: magic variables -========================================== - -You can access information about Ansible operations, including the python version being used, the hosts and groups in inventory, and the directories for playbooks and roles, using "magic" variables. Like connection variables, magic variables are :ref:`special_variables`. Magic variable names are reserved - do not set variables with these names. The variable ``environment`` is also reserved. - -The most commonly used magic variables are ``hostvars``, ``groups``, ``group_names``, and ``inventory_hostname``. With ``hostvars``, you can access variables defined for any host in the play, at any point in a playbook. You can access Ansible facts using the ``hostvars`` variable too, but only after you have gathered (or cached) facts. Note that variables defined at play objects are not defined for specific hosts and therefore are not mapped to hostvars. - -If you want to configure your database server using the value of a 'fact' from another node, or the value of an inventory variable assigned to another node, you can use ``hostvars`` in a template or on an action line: - -.. code-block:: jinja - - {{ hostvars['test.example.com']['ansible_facts']['distribution'] }} - -With ``groups``, a list of all the groups (and hosts) in the inventory, you can enumerate all hosts within a group. For example: - -.. code-block:: jinja - - {% for host in groups['app_servers'] %} - # something that applies to all app servers. - {% endfor %} - -You can use ``groups`` and ``hostvars`` together to find all the IP addresses in a group. - -.. code-block:: jinja - - {% for host in groups['app_servers'] %} - {{ hostvars[host]['ansible_facts']['eth0']['ipv4']['address'] }} - {% endfor %} - -You can use this approach to point a frontend proxy server to all the hosts in your app servers group, to set up the correct firewall rules between servers, and so on. You must either cache facts or gather facts for those hosts before the task that fills out the template. - -With ``group_names``, a list (array) of all the groups the current host is in, you can create templated files that vary based on the group membership (or role) of the host: - -.. code-block:: jinja - - {% if 'webserver' in group_names %} - # some part of a configuration file that only applies to webservers - {% endif %} - -You can use the magic variable ``inventory_hostname``, the name of the host as configured in your inventory, as an alternative to ``ansible_hostname`` when fact-gathering is disabled. If you have a long FQDN, you can use ``inventory_hostname_short``, which contains the part up to the first period, without the rest of the domain. - -Other useful magic variables refer to the current play or playbook. These vars may be useful for filling out templates with multiple hostnames or for injecting the list into the rules for a load balancer. - -``ansible_play_hosts`` is the list of all hosts still active in the current play. - -``ansible_play_batch`` is a list of hostnames that are in scope for the current 'batch' of the play. - -The batch size is defined by ``serial``, when not set it is equivalent to the whole play (making it the same as ``ansible_play_hosts``). - -``ansible_playbook_python`` is the path to the python executable used to invoke the Ansible command line tool. - -``inventory_dir`` is the pathname of the directory holding Ansible's inventory host file. - -``inventory_file`` is the pathname and the filename pointing to the Ansible's inventory host file. - -``playbook_dir`` contains the playbook base directory. - -``role_path`` contains the current role's pathname and only works inside a role. - -``ansible_check_mode`` is a boolean, set to ``True`` if you run Ansible with ``--check``. - -.. _ansible_version: - -Ansible version ---------------- - -.. versionadded:: 1.8 - -To adapt playbook behavior to different versions of Ansible, you can use the variable ``ansible_version``, which has the following structure: - -.. code-block:: json - - { - "ansible_version": { - "full": "2.10.1", - "major": 2, - "minor": 10, - "revision": 1, - "string": "2.10.1" - } - } diff --git a/docs/docsite/rst/playbook_guide/playbooks_vault.rst b/docs/docsite/rst/playbook_guide/playbooks_vault.rst deleted file mode 100644 index 03bd2c040f3..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_vault.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Using vault in playbooks -======================== - -The documentation regarding Ansible Vault has moved. The new location is here: :ref:`vault`. Please update any links you may have made directly to this page. diff --git a/docs/docsite/rst/playbook_guide/shared_snippets/role_directory.txt b/docs/docsite/rst/playbook_guide/shared_snippets/role_directory.txt deleted file mode 100644 index 5722f0ee894..00000000000 --- a/docs/docsite/rst/playbook_guide/shared_snippets/role_directory.txt +++ /dev/null @@ -1,26 +0,0 @@ -.. code-block:: yaml - - roles/ - common/ # this hierarchy represents a "role" - tasks/ # - main.yml # <-- tasks file can include smaller files if warranted - handlers/ # - main.yml # <-- handlers file - templates/ # <-- files for use with the template resource - ntp.conf.j2 # <------- templates end in .j2 - files/ # - bar.txt # <-- files for use with the copy resource - foo.sh # <-- script files for use with the script resource - vars/ # - main.yml # <-- variables associated with this role - defaults/ # - main.yml # <-- default lower priority variables for this role - meta/ # - main.yml # <-- role dependencies - library/ # roles can also include custom modules - module_utils/ # roles can also include custom module_utils - lookup_plugins/ # or other types of plugins, like lookup in this case - - webtier/ # same kind of structure as "common" was above, done for the webtier role - monitoring/ # "" - fooapp/ # "" diff --git a/docs/docsite/rst/playbook_guide/shared_snippets/with2loop.txt b/docs/docsite/rst/playbook_guide/shared_snippets/with2loop.txt deleted file mode 100644 index c563dcec2dd..00000000000 --- a/docs/docsite/rst/playbook_guide/shared_snippets/with2loop.txt +++ /dev/null @@ -1,206 +0,0 @@ -In most cases, loops work best with the ``loop`` keyword instead of ``with_X`` style loops. The ``loop`` syntax is usually best expressed using filters instead of more complex use of ``query`` or ``lookup``. - -These examples show how to convert many common ``with_`` style loops to ``loop`` and filters. - -with_list ---------- - -``with_list`` is directly replaced by ``loop``. - -.. code-block:: yaml+jinja - - - name: with_list - ansible.builtin.debug: - msg: "{{ item }}" - with_list: - - one - - two - - - name: with_list -> loop - ansible.builtin.debug: - msg: "{{ item }}" - loop: - - one - - two - -with_items ----------- - -``with_items`` is replaced by ``loop`` and the ``flatten`` filter. - -.. code-block:: yaml+jinja - - - name: with_items - ansible.builtin.debug: - msg: "{{ item }}" - with_items: "{{ items }}" - - - name: with_items -> loop - ansible.builtin.debug: - msg: "{{ item }}" - loop: "{{ items|flatten(levels=1) }}" - -with_indexed_items ------------------- - -``with_indexed_items`` is replaced by ``loop``, the ``flatten`` filter and ``loop_control.index_var``. - -.. code-block:: yaml+jinja - - - name: with_indexed_items - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }}" - with_indexed_items: "{{ items }}" - - - name: with_indexed_items -> loop - ansible.builtin.debug: - msg: "{{ index }} - {{ item }}" - loop: "{{ items|flatten(levels=1) }}" - loop_control: - index_var: index - -with_flattened --------------- - -``with_flattened`` is replaced by ``loop`` and the ``flatten`` filter. - -.. code-block:: yaml+jinja - - - name: with_flattened - ansible.builtin.debug: - msg: "{{ item }}" - with_flattened: "{{ items }}" - - - name: with_flattened -> loop - ansible.builtin.debug: - msg: "{{ item }}" - loop: "{{ items|flatten }}" - -with_together -------------- - -``with_together`` is replaced by ``loop`` and the ``zip`` filter. - -.. code-block:: yaml+jinja - - - name: with_together - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }}" - with_together: - - "{{ list_one }}" - - "{{ list_two }}" - - - name: with_together -> loop - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }}" - loop: "{{ list_one|zip(list_two)|list }}" - -Another example with complex data - -.. code-block:: yaml+jinja - - - name: with_together -> loop - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }} - {{ item.2 }}" - loop: "{{ data[0]|zip(*data[1:])|list }}" - vars: - data: - - ['a', 'b', 'c'] - - ['d', 'e', 'f'] - - ['g', 'h', 'i'] - -with_dict ---------- - -``with_dict`` can be substituted by ``loop`` and either the ``dictsort`` or ``dict2items`` filters. - -.. code-block:: yaml+jinja - - - name: with_dict - ansible.builtin.debug: - msg: "{{ item.key }} - {{ item.value }}" - with_dict: "{{ dictionary }}" - - - name: with_dict -> loop (option 1) - ansible.builtin.debug: - msg: "{{ item.key }} - {{ item.value }}" - loop: "{{ dictionary|dict2items }}" - - - name: with_dict -> loop (option 2) - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }}" - loop: "{{ dictionary|dictsort }}" - -with_sequence -------------- - -``with_sequence`` is replaced by ``loop`` and the ``range`` function, and potentially the ``format`` filter. - -.. code-block:: yaml+jinja - - - name: with_sequence - ansible.builtin.debug: - msg: "{{ item }}" - with_sequence: start=0 end=4 stride=2 format=testuser%02x - - - name: with_sequence -> loop - ansible.builtin.debug: - msg: "{{ 'testuser%02x' | format(item) }}" - loop: "{{ range(0, 4 + 1, 2)|list }}" - -The range of the loop is exclusive of the end point. - -with_subelements ----------------- - -``with_subelements`` is replaced by ``loop`` and the ``subelements`` filter. - -.. code-block:: yaml+jinja - - - name: with_subelements - ansible.builtin.debug: - msg: "{{ item.0.name }} - {{ item.1 }}" - with_subelements: - - "{{ users }}" - - mysql.hosts - - - name: with_subelements -> loop - ansible.builtin.debug: - msg: "{{ item.0.name }} - {{ item.1 }}" - loop: "{{ users|subelements('mysql.hosts') }}" - -with_nested/with_cartesian --------------------------- - -``with_nested`` and ``with_cartesian`` are replaced by loop and the ``product`` filter. - -.. code-block:: yaml+jinja - - - name: with_nested - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }}" - with_nested: - - "{{ list_one }}" - - "{{ list_two }}" - - - name: with_nested -> loop - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }}" - loop: "{{ list_one|product(list_two)|list }}" - -with_random_choice ------------------- - -``with_random_choice`` is replaced by just use of the ``random`` filter, without need of ``loop``. - -.. code-block:: yaml+jinja - - - name: with_random_choice - ansible.builtin.debug: - msg: "{{ item }}" - with_random_choice: "{{ my_list }}" - - - name: with_random_choice -> loop (No loop is needed here) - ansible.builtin.debug: - msg: "{{ my_list|random }}" - tags: random diff --git a/docs/docsite/rst/plugins/action.rst b/docs/docsite/rst/plugins/action.rst deleted file mode 100644 index fe7c547f4bc..00000000000 --- a/docs/docsite/rst/plugins/action.rst +++ /dev/null @@ -1,55 +0,0 @@ -.. _action_plugins: - -Action plugins -============== - -.. contents:: - :local: - :depth: 2 - -Action plugins act in conjunction with :ref:`modules ` to execute the actions required by playbook tasks. They usually execute automatically in the background doing prerequisite work before modules execute. - -The 'normal' action plugin is used for modules that do not already have an action plugin. If necessary, you can :ref:`create custom action plugins `. - -.. _enabling_action: - -Enabling action plugins ------------------------ - -You can enable a custom action plugin by either dropping it into the ``action_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the action plugin directory sources configured in :ref:`ansible.cfg `. - -.. _using_action: - -Using action plugins --------------------- - -Action plugin are executed by default when an associated module is used; no action is required. - -Plugin list ------------ - -You cannot list action plugins directly, they show up as their counterpart modules: - -Use ``ansible-doc -l`` to see the list of available modules. -Use ``ansible-doc `` to see specific documentation and examples, this should note if the module has a corresponding action plugin. - -.. seealso:: - - :ref:`cache_plugins` - Cache plugins - :ref:`callback_plugins` - Callback plugins - :ref:`connection_plugins` - Connection plugins - :ref:`inventory_plugins` - Inventory plugins - :ref:`shell_plugins` - Shell plugins - :ref:`strategy_plugins` - Strategy plugins - :ref:`vars_plugins` - Vars plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/become.rst b/docs/docsite/rst/plugins/become.rst deleted file mode 100644 index 206a9950864..00000000000 --- a/docs/docsite/rst/plugins/become.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _become_plugins: - -Become plugins -============== - -.. contents:: - :local: - :depth: 2 - -.. versionadded:: 2.8 - -Become plugins work to ensure that Ansible can use certain privilege escalation systems when running the basic -commands to work with the target machine as well as the modules required to execute the tasks specified in -the play. - -These utilities (``sudo``, ``su``, ``doas``, and so on) generally let you 'become' another user to execute a command -with the permissions of that user. - - -.. _enabling_become: - -Enabling Become Plugins ------------------------ - -The become plugins shipped with Ansible are already enabled. Custom plugins can be added by placing -them into a ``become_plugins`` directory adjacent to your play, inside a role, or by placing them in one of -the become plugin directory sources configured in :ref:`ansible.cfg `. - - -.. _using_become: - -Using Become Plugins --------------------- - -In addition to the default configuration settings in :ref:`ansible_configuration_settings` or the -``--become-method`` command line option, you can use the ``become_method`` keyword in a play or, if you need -to be 'host specific', the connection variable ``ansible_become_method`` to select the plugin to use. - -You can further control the settings for each plugin via other configuration options detailed in the plugin -themselves (linked below). - -.. _become_plugin_list: - -Plugin List ------------ - -You can use ``ansible-doc -t become -l`` to see the list of available plugins. -Use ``ansible-doc -t become `` to see specific documentation and examples. - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`inventory_plugins` - Inventory plugins - :ref:`callback_plugins` - Callback plugins - :ref:`filter_plugins` - Filter plugins - :ref:`test_plugins` - Test plugins - :ref:`lookup_plugins` - Lookup plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/cache.rst b/docs/docsite/rst/plugins/cache.rst deleted file mode 100644 index 4aa88f9246b..00000000000 --- a/docs/docsite/rst/plugins/cache.rst +++ /dev/null @@ -1,139 +0,0 @@ -.. _cache_plugins: - -Cache plugins -============= - -.. contents:: - :local: - :depth: 2 - -Cache plugins allow Ansible to store gathered facts or inventory source data without the performance hit of retrieving them from source. - -The default cache plugin is the :ref:`memory ` plugin, which only caches the data for the current execution of Ansible. Other plugins with persistent storage are available to allow caching the data across runs. Some of these cache plugins write to files, others write to databases. - -You can use different cache plugins for inventory and facts. If you enable inventory caching without setting an inventory-specific cache plugin, Ansible uses the fact cache plugin for both facts and inventory. If necessary, you can :ref:`create custom cache plugins `. - -.. _enabling_cache: - -Enabling fact cache plugins ---------------------------- - -Fact caching is always enabled. However, only one fact cache plugin can be active at a time. You can select the cache plugin to use for fact caching in the Ansible configuration, either with an environment variable: - -.. code-block:: shell - - export ANSIBLE_CACHE_PLUGIN=jsonfile - -or in the ``ansible.cfg`` file: - -.. code-block:: ini - - [defaults] - fact_caching=redis - -If the cache plugin is in a collection use the fully qualified name: - -.. code-block:: ini - - [defaults] - fact_caching = namespace.collection_name.cache_plugin_name - -To enable a custom cache plugin, save it in a ``cache_plugins`` directory adjacent to your play, inside a role, or in one of the directory sources configured in :ref:`ansible.cfg `. - -You also need to configure other settings specific to each plugin. Consult the individual plugin documentation or the Ansible :ref:`configuration ` for more details. - -Enabling inventory cache plugins --------------------------------- - -Inventory caching is disabled by default. To cache inventory data, you must enable inventory caching and then select the specific cache plugin you want to use. Not all inventory plugins support caching, so check the documentation for the inventory plugin(s) you want to use. You can enable inventory caching with an environment variable: - -.. code-block:: shell - - export ANSIBLE_INVENTORY_CACHE=True - -or in the ``ansible.cfg`` file: - -.. code-block:: ini - - [inventory] - cache=True - -or if the inventory plugin accepts a YAML configuration source, in the configuration file: - -.. code-block:: yaml - - # dev.aws_ec2.yaml - plugin: aws_ec2 - cache: True - -Only one inventory cache plugin can be active at a time. You can set it with an environment variable: - -.. code-block:: shell - - export ANSIBLE_INVENTORY_CACHE_PLUGIN=jsonfile - -or in the ansible.cfg file: - -.. code-block:: ini - - [inventory] - cache_plugin=jsonfile - -or if the inventory plugin accepts a YAML configuration source, in the configuration file: - -.. code-block:: yaml - - # dev.aws_ec2.yaml - plugin: aws_ec2 - cache_plugin: jsonfile - -To cache inventory with a custom plugin in your plugin path, follow the :ref:`developer guide on cache plugins`. - -To cache inventory with a cache plugin in a collection, use the FQCN: - -.. code-block:: ini - - [inventory] - cache_plugin=collection_namespace.collection_name.cache_plugin - -If you enable caching for inventory plugins without selecting an inventory-specific cache plugin, Ansible falls back to caching inventory with the fact cache plugin you configured. Consult the individual inventory plugin documentation or the Ansible :ref:`configuration ` for more details. - -.. Note: In Ansible 2.7 and earlier, inventory plugins can only use file-based cache plugins, such as jsonfile, pickle, and yaml. - - -.. _using_cache: - -Using cache plugins -------------------- - -Cache plugins are used automatically once they are enabled. - - -.. _cache_plugin_list: - -Plugin list ------------ - -You can use ``ansible-doc -t cache -l`` to see the list of available plugins. -Use ``ansible-doc -t cache `` to see specific documentation and examples. - -.. seealso:: - - :ref:`action_plugins` - Action plugins - :ref:`callback_plugins` - Callback plugins - :ref:`connection_plugins` - Connection plugins - :ref:`inventory_plugins` - Inventory plugins - :ref:`shell_plugins` - Shell plugins - :ref:`strategy_plugins` - Strategy plugins - :ref:`vars_plugins` - Vars plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/callback.rst b/docs/docsite/rst/plugins/callback.rst deleted file mode 100644 index 98e4beb754c..00000000000 --- a/docs/docsite/rst/plugins/callback.rst +++ /dev/null @@ -1,116 +0,0 @@ -.. _callback_plugins: - -Callback plugins -================ - -.. contents:: - :local: - :depth: 2 - -Callback plugins enable adding new behaviors to Ansible when responding to events. By default, callback plugins control most of the output you see when running the command line programs, but can also be used to add additional output, integrate with other tools and marshal the events to a storage backend. If necessary, you can :ref:`create custom callback plugins `. - -.. _callback_examples: - -Example callback plugins ------------------------- - -The :ref:`log_plays ` callback is an example of how to record playbook events to a log file, and the :ref:`mail ` callback sends email on playbook failures. - -The :ref:`say ` callback responds with computer synthesized speech in relation to playbook events. - -.. _enabling_callbacks: - -Enabling callback plugins -------------------------- - -You can activate a custom callback by either dropping it into a ``callback_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the callback directory sources configured in :ref:`ansible.cfg `. - -Plugins are loaded in alphanumeric order. For example, a plugin implemented in a file named `1_first.py` would run before a plugin file named `2_second.py`. - -Most callbacks shipped with Ansible are disabled by default and need to be enabled in your :ref:`ansible.cfg ` file in order to function. For example: - -.. code-block:: ini - - #callbacks_enabled = timer, mail, profile_roles, collection_namespace.collection_name.custom_callback - -Setting a callback plugin for ``ansible-playbook`` --------------------------------------------------- - -You can only have one plugin be the main manager of your console output. If you want to replace the default, you should define ``CALLBACK_TYPE = stdout`` in the subclass and then configure the stdout plugin in :ref:`ansible.cfg `. For example: - -.. code-block:: ini - - stdout_callback = dense - -or for my custom callback: - -.. code-block:: ini - - stdout_callback = mycallback - -This only affects :ref:`ansible-playbook` by default. - -Setting a callback plugin for ad hoc commands ---------------------------------------------- - -The :ref:`ansible` ad hoc command specifically uses a different callback plugin for stdout, so there is an extra setting in :ref:`ansible_configuration_settings` you need to add to use the stdout callback defined above: - -.. code-block:: ini - - [defaults] - bin_ansible_callbacks=True - -You can also set this as an environment variable: - -.. code-block:: shell - - export ANSIBLE_LOAD_CALLBACK_PLUGINS=1 - - -.. _callback_plugin_types: - -Types of callback plugins -------------------------- - -There are three types of callback plugins: - -:stdout callback plugins: - - These plugins handle the main console output. Only one of these can be active. - -:aggregate callback plugins: - - Aggregate callbacks can add additional console output next to a stdout callback. This can be aggregate information at the end of a playbook run, additional per-task output, or anything else. - -:notification callback plugins: - - Notification callbacks inform other applications, services, or systems. This can be anything from logging to databases, informing on errors in Instant Messaging applications, or sending emails when a server is unreachable. - -.. _callback_plugin_list: - -Plugin list ------------ - -You can use ``ansible-doc -t callback -l`` to see the list of available plugins. -Use ``ansible-doc -t callback `` to see specific documents and examples. - -.. seealso:: - - :ref:`action_plugins` - Action plugins - :ref:`cache_plugins` - Cache plugins - :ref:`connection_plugins` - Connection plugins - :ref:`inventory_plugins` - Inventory plugins - :ref:`shell_plugins` - Shell plugins - :ref:`strategy_plugins` - Strategy plugins - :ref:`vars_plugins` - Vars plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/cliconf.rst b/docs/docsite/rst/plugins/cliconf.rst deleted file mode 100644 index f5af78c2124..00000000000 --- a/docs/docsite/rst/plugins/cliconf.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _cliconf_plugins: - -Cliconf plugins -=============== - -.. contents:: - :local: - :depth: 2 - -Cliconf plugins are abstractions over the CLI interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices. - -These plugins generally correspond one-to-one to network device platforms. Ansible loads the appropriate cliconf plugin automatically based on the ``ansible_network_os`` variable. - -.. _enabling_cliconf: - -Adding cliconf plugins -------------------------- - -You can extend Ansible to support other network devices by dropping a custom plugin into the ``cliconf_plugins`` directory. - -.. _using_cliconf: - -Using cliconf plugins ------------------------- - -The cliconf plugin to use is determined automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality. - -Most cliconf plugins can operate without configuration. A few have additional options that can be set to affect how tasks are translated into CLI commands. - -Plugins are self-documenting. Each plugin should document its configuration options. - -.. _cliconf_plugin_list: - -Viewing cliconf plugins ------------------------ - -These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several cliconf plugins. To list all available cliconf plugins on your control node, type ``ansible-doc -t cliconf -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t cliconf``. - - -.. seealso:: - - :ref:`Ansible for Network Automation` - An overview of using Ansible to automate networking devices. - `User Mailing List `_ - Have a question? Stop by the google group! - `irc.libera.chat `_ - #ansible-network IRC chat channel diff --git a/docs/docsite/rst/plugins/connection.rst b/docs/docsite/rst/plugins/connection.rst deleted file mode 100644 index 3652ffe1783..00000000000 --- a/docs/docsite/rst/plugins/connection.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _connection_plugins: - -Connection plugins -================== - -.. contents:: - :local: - :depth: 2 - -Connection plugins allow Ansible to connect to the target hosts so it can execute tasks on them. Ansible ships with many connection plugins, but only one can be used per host at a time. - -By default, Ansible ships with several connection plugins. The most commonly used are the :ref:`paramiko SSH`, native ssh (just called :ref:`ssh`), and :ref:`local` connection types. All of these can be used in playbooks and with :command:`/usr/bin/ansible` to decide how you want to talk to remote machines. If necessary, you can :ref:`create custom connection plugins `. - -The basics of these connection types are covered in the :ref:`getting started` section. - -.. _ssh_plugins: - -``ssh`` plugins ---------------- - -Because ssh is the default protocol used in system administration and the protocol most used in Ansible, ssh options are included in the command line tools. See :ref:`ansible-playbook` for more details. - -.. _enabling_connection: - -Adding connection plugins -------------------------- - -You can extend Ansible to support other transports (such as SNMP or message bus) by dropping a custom plugin -into the ``connection_plugins`` directory. - -.. _using_connection: - -Using connection plugins ------------------------- - -You can set the connection plugin globally via :ref:`configuration`, at the command line (``-c``, ``--connection``), as a :ref:`keyword ` in your play, or by setting a :ref:`variable`, most often in your inventory. -For example, for Windows machines you might want to set the :ref:`winrm ` plugin as an inventory variable. - -Most connection plugins can operate with minimal configuration. By default they use the :ref:`inventory hostname` and defaults to find the target host. - -Plugins are self-documenting. Each plugin should document its configuration options. The following are connection variables common to most connection plugins: - -:ref:`ansible_host` - The name of the host to connect to, if different from the :ref:`inventory ` hostname. -:ref:`ansible_port` - The ssh port number, for :ref:`ssh ` and :ref:`paramiko_ssh ` it defaults to 22. -:ref:`ansible_user` - The default user name to use for log in. Most plugins default to the 'current user running Ansible'. - -Each plugin might also have a specific version of a variable that overrides the general version. For example, ``ansible_ssh_host`` for the :ref:`ssh ` plugin. - -.. _connection_plugin_list: - -Plugin list ------------ - -You can use ``ansible-doc -t connection -l`` to see the list of available plugins. -Use ``ansible-doc -t connection `` to see detailed documentation and examples. - - -.. seealso:: - - :ref:`Working with Playbooks` - An introduction to playbooks - :ref:`callback_plugins` - Callback plugins - :ref:`filter_plugins` - Filter plugins - :ref:`test_plugins` - Test plugins - :ref:`lookup_plugins` - Lookup plugins - :ref:`vars_plugins` - Vars plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/docs_fragment.rst b/docs/docsite/rst/plugins/docs_fragment.rst deleted file mode 100644 index 546229bee79..00000000000 --- a/docs/docsite/rst/plugins/docs_fragment.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. _docs_fragment_plugins: - -Docs fragments -============== - -.. contents:: - :local: - :depth: 2 - -Docs fragments allow you to document common parameters of multiple plugins or modules in a single place. - -.. _enabling_docs_fragments: - -Enabling docs fragments ------------------------ - -You can add a custom docs fragment by dropping it into a ``doc_fragments`` directory adjacent to your collection or role, just like any other plugin. - -.. _using_docs_fragments: - -Using docs fragments --------------------- - -Only collection developers and maintainers use docs fragments. For more information on using docs fragments, see :ref:`module_docs_fragments` or :ref:`docfragments_collections`. - -.. seealso:: - - :ref:`developing_modules_general` - An introduction to creating Ansible modules - :ref:`developing_collections` - An guide to creating Ansible collections - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/filter.rst b/docs/docsite/rst/plugins/filter.rst deleted file mode 100644 index b768cfe5944..00000000000 --- a/docs/docsite/rst/plugins/filter.rst +++ /dev/null @@ -1,63 +0,0 @@ -.. _filter_plugins: - -Filter plugins -============== - -.. contents:: - :local: - :depth: 2 - -Filter plugins manipulate data. With the right filter you can extract a particular value, transform data types and formats, perform mathematical calculations, split and concatenate strings, insert dates and times, and do much more. Ansible uses the :ref:`standard filters ` shipped with Jinja2 and adds some specialized filter plugins. You can :ref:`create custom Ansible filters as plugins `. - -.. _enabling_filter: - -Enabling filter plugins ------------------------ - -You can add a custom filter plugin by dropping it into a ``filter_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the filter plugin directory sources configured in :ref:`ansible.cfg `. - -.. _using_filter: - -Using filter plugins --------------------- - -You can use filters anywhere you can use templating in Ansible: in a play, in variables file, or in a Jinja2 template for the :ref:`template ` module. For more information on using filter plugins, see :ref:`playbooks_filters`. Filters can return any type of data, but if you want to always return a boolean (``True`` or ``False``) you should be looking at a test instead. - -.. code-block:: YAML+Jinja - - vars: - yaml_string: "{{ some_variable|to_yaml }}" - -Filters are the preferred way to manipulate data in Ansible, you can identify a filter because it is normally preceded by a ``|``, with the expression on the left of it being the first input of the filter. Additional parameters may be passed into the filter itself as you would to most programming functions. These parameters can be either ``positional`` (passed in order) or ``named`` (passed as key=value pairs). When passing both types, positional arguments should go first. - -.. code-block:: YAML+Jinja - - passing_positional: {{ (x == 32) | ternary('x is 32', 'x is not 32') }} - passing_extra_named_parameters: {{ some_variable | to_yaml(indent=8, width=1337) }} - passing_both: {{ some_variable| ternary('true value', 'false value', none_val='NULL') }} - -In the documentation, filters will always have a C(_input) option that corresponds to the expression to the left of c(|). A C(positional:) field in the documentation will show which options are positional and in which order they are required. - - -Plugin list ------------ - -You can use ``ansible-doc -t filter -l`` to see the list of available plugins. Use ``ansible-doc -t filter `` to see specific documents and examples. - - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`inventory_plugins` - Inventory plugins - :ref:`callback_plugins` - Callback plugins - :ref:`test_plugins` - Test plugins - :ref:`lookup_plugins` - Lookup plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/httpapi.rst b/docs/docsite/rst/plugins/httpapi.rst deleted file mode 100644 index 7ce0573b918..00000000000 --- a/docs/docsite/rst/plugins/httpapi.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. _httpapi_plugins: - -Httpapi plugins -=============== - -.. contents:: - :local: - :depth: 2 - -Httpapi plugins tell Ansible how to interact with a remote device's HTTP-based API and execute tasks on the -device. - -Each plugin represents a particular dialect of API. Some are platform-specific (Arista eAPI, Cisco NXAPI), while others might be usable on a variety of platforms (RESTCONF). Ansible loads the appropriate httpapi plugin automatically based on the ``ansible_network_os`` variable. - - -.. _enabling_httpapi: - -Adding httpapi plugins -------------------------- - -You can extend Ansible to support other APIs by dropping a custom plugin into the ``httpapi_plugins`` directory. See :ref:`developing_plugins_httpapi` for details. - -.. _using_httpapi: - -Using httpapi plugins ------------------------- - -The httpapi plugin to use is determined automatically from the ``ansible_network_os`` variable. - -Most httpapi plugins can operate without configuration. Additional options may be defined by each plugin. - -Plugins are self-documenting. Each plugin should document its configuration options. - - -The following sample playbook shows the httpapi plugin for an Arista network device, assuming an inventory variable set as ``ansible_network_os=eos`` for the httpapi plugin to trigger off: - -.. code-block:: yaml - - - hosts: leaf01 - connection: httpapi - gather_facts: false - tasks: - - - name: type a simple arista command - eos_command: - commands: - - show version | json - register: command_output - - - name: print command output to terminal window - debug: - var: command_output.stdout[0]["version"] - -See the full working example `on GitHub `_. - -.. _httpapi_plugin_list: - -Viewing httpapi plugins ------------------------ - -These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several httpapi plugins. To list all available httpapi plugins on your control node, type ``ansible-doc -t httpapi -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t httpapi``. - -.. seealso:: - - :ref:`Ansible for Network Automation` - An overview of using Ansible to automate networking devices. - :ref:`Developing network modules` - How to develop network modules. - `User Mailing List `_ - Have a question? Stop by the google group! - `irc.libera.chat `_ - #ansible-network IRC chat channel diff --git a/docs/docsite/rst/plugins/index.html b/docs/docsite/rst/plugins/index.html deleted file mode 100644 index a7eac85695c..00000000000 --- a/docs/docsite/rst/plugins/index.html +++ /dev/null @@ -1,4 +0,0 @@ - - -`` to see plugin-specific documentation and examples. - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`callback_plugins` - Callback plugins - :ref:`connection_plugins` - Connection plugins - :ref:`filter_plugins` - Filter plugins - :ref:`test_plugins` - Test plugins - :ref:`lookup_plugins` - Lookup plugins - :ref:`vars_plugins` - Vars plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/lookup.rst b/docs/docsite/rst/plugins/lookup.rst deleted file mode 100644 index d0336e91a52..00000000000 --- a/docs/docsite/rst/plugins/lookup.rst +++ /dev/null @@ -1,167 +0,0 @@ -.. _lookup_plugins: - -Lookup plugins -============== - -.. contents:: - :local: - :depth: 2 - -Lookup plugins are an Ansible-specific extension to the Jinja2 templating language. You can use lookup plugins to access data from outside sources (files, databases, key/value stores, APIs, and other services) within your playbooks. Like all :ref:`templating `, lookups execute and are evaluated on the Ansible control machine. Ansible makes the data returned by a lookup plugin available using the standard templating system. You can use lookup plugins to load variables or templates with information from external sources. You can :ref:`create custom lookup plugins `. - -.. note:: - - Lookups are executed with a working directory relative to the role or play, - as opposed to local tasks, which are executed relative the executed script. - - Pass ``wantlist=True`` to lookups to use in Jinja2 template "for" loops. - - By default, lookup return values are marked as unsafe for security reasons. If you trust the outside source your lookup accesses, pass ``allow_unsafe=True`` to allow Jinja2 templates to evaluate lookup values. - -.. warning:: - - Some lookups pass arguments to a shell. When using variables from a remote/untrusted source, use the `|quote` filter to ensure safe usage. - - -.. _enabling_lookup: - -Enabling lookup plugins ------------------------ - -Ansible enables all lookup plugins it can find. You can activate a custom lookup by either dropping it into a ``lookup_plugins`` directory adjacent to your play, inside the ``plugins/lookup/`` directory of a collection you have installed, inside a standalone role, or in one of the lookup directory sources configured in :ref:`ansible.cfg `. - - -.. _using_lookup: - -Using lookup plugins --------------------- - -You can use lookup plugins anywhere you can use templating in Ansible: in a play, in variables file, or in a Jinja2 template for the :ref:`template ` module. For more information on using lookup plugins, see :ref:`playbooks_lookups`. - -.. code-block:: YAML+Jinja - - vars: - file_contents: "{{ lookup('file', 'path/to/file.txt') }}" - -Lookups are an integral part of loops. Wherever you see ``with_``, the part after the underscore is the name of a lookup. For this reason, lookups are expected to output lists; for example, ``with_items`` uses the :ref:`items ` lookup: - -.. code-block:: YAML+Jinja - - tasks: - - name: count to 3 - debug: msg={{ item }} - with_items: [1, 2, 3] - -You can combine lookups with :ref:`filters `, :ref:`tests ` and even each other to do some complex data generation and manipulation. For example: - -.. code-block:: YAML+Jinja - - tasks: - - name: valid but useless and over complicated chained lookups and filters - debug: msg="find the answer here:\n{{ lookup('url', 'https://google.com/search/?q=' + item|urlencode)|join(' ') }}" - with_nested: - - "{{ lookup('consul_kv', 'bcs/' + lookup('file', '/the/question') + ', host=localhost, port=2000')|shuffle }}" - - "{{ lookup('sequence', 'end=42 start=2 step=2')|map('log', 4)|list) }}" - - ['a', 'c', 'd', 'c'] - -.. versionadded:: 2.6 - -You can control how errors behave in all lookup plugins by setting ``errors`` to ``ignore``, ``warn``, or ``strict``. The default setting is ``strict``, which causes the task to fail if the lookup returns an error. For example: - -To ignore lookup errors: - -.. code-block:: YAML+Jinja - - - name: if this file does not exist, I do not care .. file plugin itself warns anyway ... - debug: msg="{{ lookup('file', '/nosuchfile', errors='ignore') }}" - -.. code-block:: ansible-output - - [WARNING]: Unable to find '/nosuchfile' in expected paths (use -vvvvv to see paths) - - ok: [localhost] => { - "msg": "" - } - - -To get a warning instead of a failure: - -.. code-block:: YAML+Jinja - - - name: if this file does not exist, let me know, but continue - debug: msg="{{ lookup('file', '/nosuchfile', errors='warn') }}" - -.. code-block:: ansible-output - - [WARNING]: Unable to find '/nosuchfile' in expected paths (use -vvvvv to see paths) - - [WARNING]: An unhandled exception occurred while running the lookup plugin 'file'. Error was a , original message: could not locate file in lookup: /nosuchfile - - ok: [localhost] => { - "msg": "" - } - - -To get a fatal error (the default): - -.. code-block:: YAML+Jinja - - - name: if this file does not exist, FAIL (this is the default) - debug: msg="{{ lookup('file', '/nosuchfile', errors='strict') }}" - -.. code-block:: ansible-output - - [WARNING]: Unable to find '/nosuchfile' in expected paths (use -vvvvv to see paths) - - fatal: [localhost]: FAILED! => {"msg": "An unhandled exception occurred while running the lookup plugin 'file'. Error was a , original message: could not locate file in lookup: /nosuchfile"} - - -.. _query: - -Forcing lookups to return lists: ``query`` and ``wantlist=True`` ----------------------------------------------------------------- - -.. versionadded:: 2.5 - -In Ansible 2.5, a new Jinja2 function called ``query`` was added for invoking lookup plugins. The difference between ``lookup`` and ``query`` is largely that ``query`` will always return a list. -The default behavior of ``lookup`` is to return a string of comma separated values. ``lookup`` can be explicitly configured to return a list using ``wantlist=True``. - -This feature provides an easier and more consistent interface for interacting with the new ``loop`` keyword, while maintaining backwards compatibility with other uses of ``lookup``. - -The following examples are equivalent: - -.. code-block:: jinja - - lookup('dict', dict_variable, wantlist=True) - - query('dict', dict_variable) - -As demonstrated above, the behavior of ``wantlist=True`` is implicit when using ``query``. - -Additionally, ``q`` was introduced as a shortform of ``query``: - -.. code-block:: jinja - - q('dict', dict_variable) - - -.. _lookup_plugins_list: - -Plugin list ------------ - -You can use ``ansible-doc -t lookup -l`` to see the list of available plugins. Use ``ansible-doc -t lookup `` to see specific documents and examples. - - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`inventory_plugins` - Ansible inventory plugins - :ref:`callback_plugins` - Ansible callback plugins - :ref:`filter_plugins` - Jinja2 filter plugins - :ref:`test_plugins` - Jinja2 test plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/module.rst b/docs/docsite/rst/plugins/module.rst deleted file mode 100644 index 4d44f46979c..00000000000 --- a/docs/docsite/rst/plugins/module.rst +++ /dev/null @@ -1,43 +0,0 @@ -.. _module_plugins: - -Modules -======= - -.. contents:: - :local: - :depth: 2 - -Modules are the main building blocks of Ansible playbooks. Although we do not generally speak of "module plugins", a module is a type of plugin. For a developer-focused description of the differences between modules and other plugins, see :ref:`modules_vs_plugins`. - -.. _enabling_modules: - -Enabling modules ----------------- - -You can enable a custom module by dropping it into one of these locations: - -* any directory added to the ``ANSIBLE_LIBRARY`` environment variable (``$ANSIBLE_LIBRARY`` takes a colon-separated list like ``$PATH``) -* ``~/.ansible/plugins/modules/`` -* ``/usr/share/ansible/plugins/modules/`` - -For more information on using local custom modules, see :ref:`local_modules`. - -.. _using_modules: - -Using modules -------------- - -For information on using modules in ad hoc tasks, see :ref:`intro_adhoc`. For information on using modules in playbooks, see :ref:`playbooks_intro`. - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`developing_modules_general` - An introduction to creating Ansible modules - :ref:`developing_collections` - An guide to creating Ansible collections - `User Mailing List `_ - Have a question? Stop by the google group! - `irc.libera.chat `_ - #ansible-devel IRC chat channel diff --git a/docs/docsite/rst/plugins/module_util.rst b/docs/docsite/rst/plugins/module_util.rst deleted file mode 100644 index c694380c6d4..00000000000 --- a/docs/docsite/rst/plugins/module_util.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. _module_util_plugins: - -Module utilities -================ - -.. contents:: - :local: - :depth: 2 - -Module utilities contain shared code used by multiple plugins. You can write :ref:`custom module utilities `. - -.. _enabling_module_utils: - -Enabling module utilities -------------------------- - -You can add a custom module utility by dropping it into a ``module_utils`` directory adjacent to your collection or role, just like any other plugin. - -.. _using_module_utils: - -Using module utilities ----------------------- - -For information on using module utilities, see :ref:`developing_module_utilities`. - -.. seealso:: - - :ref:`developing_modules_general` - An introduction to creating Ansible modules - :ref:`developing_collections` - An guide to creating Ansible collections - `User Mailing List `_ - Have a question? Stop by the google group! - `irc.libera.chat `_ - #ansible-devel IRC chat channel diff --git a/docs/docsite/rst/plugins/netconf.rst b/docs/docsite/rst/plugins/netconf.rst deleted file mode 100644 index 4f79809d12e..00000000000 --- a/docs/docsite/rst/plugins/netconf.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _netconf_plugins: - -Netconf plugins -=============== - -.. contents:: - :local: - :depth: 2 - -Netconf plugins are abstractions over the Netconf interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices. - -These plugins generally correspond one-to-one to network device platforms. Ansible loads the appropriate netconf plugin automatically based on the ``ansible_network_os`` variable. If the platform supports standard Netconf implementation as defined in the Netconf RFC specification, Ansible loads the ``default`` netconf plugin. If the platform supports propriety Netconf RPCs, Ansible loads the platform-specific netconf plugin. - -.. _enabling_netconf: - -Adding netconf plugins -------------------------- - -You can extend Ansible to support other network devices by dropping a custom plugin into the ``netconf_plugins`` directory. - -.. _using_netconf: - -Using netconf plugins ------------------------- - -The netconf plugin to use is determined automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality. - -Most netconf plugins can operate without configuration. A few have additional options that can be set to affect how tasks are translated into netconf commands. A ncclient device specific handler name can be set in the netconf plugin or else the value of ``default`` is used as per ncclient device handler. - -Plugins are self-documenting. Each plugin should document its configuration options. - -.. _netconf_plugin_list: - -Listing netconf plugins ------------------------ - -These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several netconf plugins. To list all available netconf plugins on your control node, type ``ansible-doc -t netconf -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t netconf``. - - -.. seealso:: - - :ref:`Ansible for Network Automation` - An overview of using Ansible to automate networking devices. - `User Mailing List `_ - Have a question? Stop by the google group! - `irc.libera.chat `_ - #ansible-network IRC chat channel diff --git a/docs/docsite/rst/plugins/plugins.rst b/docs/docsite/rst/plugins/plugins.rst deleted file mode 100644 index 46ed28ee542..00000000000 --- a/docs/docsite/rst/plugins/plugins.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. _plugins_lookup: -.. _working_with_plugins: - -******************** -Working with plugins -******************** - -Plugins are pieces of code that augment Ansible's core functionality. Ansible uses a plugin architecture to enable a rich, flexible and expandable feature set. - -Ansible ships with a number of handy plugins, and you can easily write your own. - -This section covers the various types of plugins that are included with Ansible: - -.. toctree:: - :maxdepth: 1 - - action - become - cache - callback - cliconf - connection - docs_fragment - filter - httpapi - inventory - lookup - module - module_util - netconf - shell - strategy - terminal - test - vars - -.. seealso:: - - :ref:`plugin_filtering_config` - Controlling access to modules - :ref:`ansible_configuration_settings` - Ansible configuration documentation and settings - :ref:`command_line_tools` - Ansible tools, description and options - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/shell.rst b/docs/docsite/rst/plugins/shell.rst deleted file mode 100644 index 3c9daf3c142..00000000000 --- a/docs/docsite/rst/plugins/shell.rst +++ /dev/null @@ -1,53 +0,0 @@ -.. _shell_plugins: - -Shell plugins -============= - -.. contents:: - :local: - :depth: 2 - -Shell plugins work to ensure that the basic commands Ansible runs are properly formatted to work with -the target machine and allow the user to configure certain behaviors related to how Ansible executes tasks. - -.. _enabling_shell: - -Enabling shell plugins ----------------------- - -You can add a custom shell plugin by dropping it into a ``shell_plugins`` directory adjacent to your play, inside a role, -or by putting it in one of the shell plugin directory sources configured in :ref:`ansible.cfg `. - -.. warning:: You should not alter which plugin is used unless you have a setup in which the default ``/bin/sh`` - is not a POSIX compatible shell or is not available for execution. - -.. _using_shell: - -Using shell plugins -------------------- - -In addition to the default configuration settings in :ref:`ansible_configuration_settings`, you can use -the connection variable :ref:`ansible_shell_type ` to select the plugin to use. -In this case, you will also want to update the :ref:`ansible_shell_executable ` to match. - -You can further control the settings for each plugin via other configuration options -detailed in the plugin themselves (linked below). - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`inventory_plugins` - Inventory plugins - :ref:`callback_plugins` - Callback plugins - :ref:`filter_plugins` - Filter plugins - :ref:`test_plugins` - Test plugins - :ref:`lookup_plugins` - Lookup plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/strategy.rst b/docs/docsite/rst/plugins/strategy.rst deleted file mode 100644 index 3a90b56c380..00000000000 --- a/docs/docsite/rst/plugins/strategy.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _strategy_plugins: - -Strategy plugins -================ - -.. contents:: - :local: - :depth: 2 - -Strategy plugins control the flow of play execution by handling task and host scheduling. For more information on using strategy plugins and other ways to control execution order, see :ref:`playbooks_strategies`. - -.. _enable_strategy: - -Enabling strategy plugins -------------------------- - -All strategy plugins shipped with Ansible are enabled by default. You can enable a custom strategy plugin by -putting it in one of the lookup directory sources configured in :ref:`ansible.cfg `. - -.. _using_strategy: - -Using strategy plugins ----------------------- - -Only one strategy plugin can be used in a play, but you can use different ones for each play in a playbook or ansible run. By default Ansible uses the :ref:`linear ` plugin. You can change this default in Ansible :ref:`configuration ` using an environment variable: - -.. code-block:: shell - - export ANSIBLE_STRATEGY=free - -or in the `ansible.cfg` file: - -.. code-block:: ini - - [defaults] - strategy=linear - -You can also specify the strategy plugin in the play via the :ref:`strategy keyword ` in a play: - -.. code-block:: yaml - - - hosts: all - strategy: debug - tasks: - - copy: src=myhosts dest=/etc/hosts - notify: restart_tomcat - - - package: name=tomcat state=present - - handlers: - - name: restart_tomcat - service: name=tomcat state=restarted - -.. _strategy_plugin_list: - -Plugin list ------------ - -You can use ``ansible-doc -t strategy -l`` to see the list of available plugins. -Use ``ansible-doc -t strategy `` to see plugin-specific specific documentation and examples. - - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`inventory_plugins` - Inventory plugins - :ref:`callback_plugins` - Callback plugins - :ref:`filter_plugins` - Filter plugins - :ref:`test_plugins` - Test plugins - :ref:`lookup_plugins` - Lookup plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/terminal.rst b/docs/docsite/rst/plugins/terminal.rst deleted file mode 100644 index 4c5f502ef67..00000000000 --- a/docs/docsite/rst/plugins/terminal.rst +++ /dev/null @@ -1,42 +0,0 @@ -.. _terminal_plugins: - -Terminal plugins -================ - -.. contents:: - :local: - :depth: 2 - -Terminal plugins contain information on how to prepare a particular network device's SSH shell is properly initialized to be used with Ansible. This typically includes disabling automatic paging, detecting errors in output, and enabling privileged mode if supported and required on the device. - -These plugins correspond one-to-one to network device platforms. Ansible loads the appropriate terminal plugin automatically based on the ``ansible_network_os`` variable. - -.. _enabling_terminal: - -Adding terminal plugins -------------------------- - -You can extend Ansible to support other network devices by dropping a custom plugin into the ``terminal_plugins`` directory. - -.. _using_terminal: - -Using terminal plugins ------------------------- - -Ansible determines which terminal plugin to use automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality. - -Terminal plugins operate without configuration. All options to control the terminal are exposed in the ``network_cli`` connection plugin. - -Plugins are self-documenting. Each plugin should document its configuration options. - - -.. seealso:: - - :ref:`Ansible for Network Automation` - An overview of using Ansible to automate networking devices. - :ref:`connection_plugins` - Connection plugins - `User Mailing List `_ - Have a question? Stop by the google group! - `irc.libera.chat `_ - #ansible-network IRC chat channel diff --git a/docs/docsite/rst/plugins/test.rst b/docs/docsite/rst/plugins/test.rst deleted file mode 100644 index 7922c122f77..00000000000 --- a/docs/docsite/rst/plugins/test.rst +++ /dev/null @@ -1,101 +0,0 @@ -.. _test_plugins: - -Test plugins -============= - -.. contents:: - :local: - :depth: 2 - -Test plugins evaluate template expressions and return True or False. With test plugins you can create :ref:`conditionals ` to implement the logic of your tasks, blocks, plays, playbooks, and roles. Ansible uses the `standard tests `_ shipped as part of Jinja, and adds some specialized test plugins. You can :ref:`create custom Ansible test plugins `. - - -.. _enabling_test: - -Enabling test plugins ----------------------- - -You can add a custom test plugin by dropping it into a ``test_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the test plugin directory sources configured in :ref:`ansible.cfg `. - - -.. _using_test: - -Using test plugins -------------------- - -You can use tests anywhere you can use templating in Ansible: in a play, in variables file, or in a Jinja2 template for the :ref:`template ` module. For more information on using test plugins, see :ref:`playbooks_tests`. - -Tests always return ``True`` or ``False``, they are always a boolean, if you need a different return type, you should be looking at filters. - -You can recognize test plugins by the use of the ``is`` statement in a template, they can also be used as part of the ``select`` family of filters. - -.. code-block:: YAML+Jinja - - vars: - is_ready: '{{ task_result is success }}' - - tasks: - - name: conditionals are always in 'template' context - action: dostuff - when: task_result is failed - -Tests will always have an ``_input`` and this is normally what is on the left side of ``is``. Tests can also take additional parameters as you would to most programming functions. These parameters can be either ``positional`` (passed in order) or ``named`` (passed as key=value pairs). When passing both types, positional arguments should go first. - -.. code-block:: YAML+Jinja - - tasks: - - name: pass positional parameter to match test - action: dostuff - when: myurl is match("https://example.com/users/.*/resources") - - - name: pass named parameter to truthy test - action: dostuff - when: myvariable is truthy(convert_bool=True) - - - name: pass both types to 'version' test - action: dostuff - when: sample_semver_var is version('2.0.0-rc.1+build.123', 'lt', version_type='semver') - - -Using test plugins with lists -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -As mentioned above, one way to use tests is with the ``select`` family of filters (``select``, ``reject``, ``selectattr``, ``rejectattr``). - -.. code-block:: YAML+Jinja - - # give me only defined variables from a list of variables, using 'defined' test - good_vars: "{{ all_vars|select('defined') }}" - - # this uses the 'equalto' test to filter out non 'fixed' type of addresses from a list - only_fixed_addresses: "{{ all_addresses|selectattr('type', 'equalsto', 'fixed') }}" - - # this does the opposite of the previous one - only_fixed_addresses: "{{ all_addresses|rejectattr('type', 'equalsto', 'fixed') }}" - - -Plugin list ------------ - -You can use ``ansible-doc -t filter -l`` to see the list of available plugins. Use ``ansible-doc -t filter `` to see specific documents and examples. - - - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_tests` - Using tests - :ref:`playbooks_conditionals` - Using conditional statements - :ref:`filter_plugins` - Filter plugins - :ref:`playbooks_tests` - Using tests - :ref:`lookup_plugins` - Lookup plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/vars.rst b/docs/docsite/rst/plugins/vars.rst deleted file mode 100644 index 054db623cfb..00000000000 --- a/docs/docsite/rst/plugins/vars.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _vars_plugins: - -Vars plugins -============ - -.. contents:: - :local: - :depth: 2 - -Vars plugins inject additional variable data into Ansible runs that did not come from an inventory source, playbook, or command line. Playbook constructs like 'host_vars' and 'group_vars' work using vars plugins. For more details about variables in Ansible, see :ref:`playbooks_variables`. - -Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4. - -The :ref:`host_group_vars ` plugin shipped with Ansible enables reading variables from :ref:`host_variables` and :ref:`group_variables`. - -.. _enable_vars: - -Enabling vars plugins ---------------------- - -You can activate a custom vars plugin by either dropping it into a ``vars_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the directory sources configured in :ref:`ansible.cfg `. - -Most vars plugins are disabled by default. To enable a vars plugin, set ``vars_plugins_enabled`` in the ``defaults`` section of :ref:`ansible.cfg ` or set the ``ANSIBLE_VARS_ENABLED`` environment variable to the list of vars plugins you want to execute. By default, the :ref:`host_group_vars ` plugin shipped with Ansible is enabled. - -Starting in Ansible 2.10, you can use vars plugins in collections. All vars plugins in collections must be explicitly enabled and must use the fully qualified collection name in the format ``namespace.collection_name.vars_plugin_name``. - -.. code-block:: yaml - - [defaults] - vars_plugins_enabled = host_group_vars,namespace.collection_name.vars_plugin_name - -.. _using_vars: - -Using vars plugins ------------------- - -By default, vars plugins are used on demand automatically after they are enabled. - -Starting in Ansible 2.10, vars plugins can be made to run at specific times. `ansible-inventory` does not use these settings, and always loads vars plugins. - -The global setting ``RUN_VARS_PLUGINS`` can be set in ``ansible.cfg`` using ``run_vars_plugins`` in the ``defaults`` section or by the ``ANSIBLE_RUN_VARS_PLUGINS`` environment variable. The default option, ``demand``, runs any enabled vars plugins relative to inventory sources whenever variables are demanded by tasks. You can use the option ``start`` to run any enabled vars plugins relative to inventory sources after importing that inventory source instead. - -You can also control vars plugin execution on a per-plugin basis for vars plugins that support the ``stage`` option. To run the :ref:`host_group_vars ` plugin after importing inventory you can add the following to :ref:`ansible.cfg `: - -.. code-block:: ini - - [vars_host_group_vars] - stage = inventory - -.. _vars_plugin_list: - -Plugin list ------------ - -You can use ``ansible-doc -t vars -l`` to see the list of available vars plugins. Use ``ansible-doc -t vars `` to see plugin-specific documentation and examples. - - -.. seealso:: - - :ref:`cache_plugins` - Cache plugins - :ref:`lookup_plugins` - Lookup plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/porting_guides/core_porting_guides.rst b/docs/docsite/rst/porting_guides/core_porting_guides.rst deleted file mode 100644 index c3994251f28..00000000000 --- a/docs/docsite/rst/porting_guides/core_porting_guides.rst +++ /dev/null @@ -1,21 +0,0 @@ -.. _core_porting_guides: - -*************************** -Ansible Core Porting Guides -*************************** - -This section lists porting guides that can help you in updating playbooks, plugins and other parts of your Ansible infrastructure from one version of ``ansible-core`` to the next. - -Please note that this is not a complete list. If you believe any extra information would be useful in these pages, you can edit by clicking `Edit on GitHub` on the top right, or raising an issue. - -.. toctree:: - :maxdepth: 1 - :glob: - - porting_guide_core_2.16 - porting_guide_core_2.15 - porting_guide_core_2.14 - porting_guide_core_2.13 - porting_guide_core_2.12 - porting_guide_core_2.11 - porting_guide_base_2.10 diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.0.rst b/docs/docsite/rst/porting_guides/porting_guide_2.0.rst deleted file mode 100644 index 876ca5e27e9..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.0.rst +++ /dev/null @@ -1,431 +0,0 @@ - -.. _porting_2.0_guide: - -************************* -Ansible 2.0 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 1.x and Ansible 2.0. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - - -We suggest you read this page along with `Ansible Changelog for 2.0 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - -Playbook -======== - -This section discusses any changes you may need to make to your playbooks. - -* Syntax in 1.9.x - -.. code-block:: yaml - - - debug: - msg: "{{ 'test1_junk 1\\\\3' | regex_replace('(.*)_junk (.*)', '\\\\1 \\\\2') }}" - - -* Syntax in 2.0.x - -.. code-block:: yaml - - - debug: - msg: "{{ 'test1_junk 1\\3' | regex_replace('(.*)_junk (.*)', '\\1 \\2') }}" - - -* Output: - -.. code-block:: yaml - - "msg": "test1 1\\3" - -To make an escaped string that will work on all versions you have two options:: - -- debug: msg="{{ 'test1_junk 1\\3' | regex_replace('(.*)_junk (.*)', '\\1 \\2') }}" - -uses key=value escaping which has not changed. The other option is to check for the ansible version:: - -"{{ (ansible_version|version_compare('2.0', 'ge'))|ternary( 'test1_junk 1\\3' | regex_replace('(.*)_junk (.*)', '\\1 \\2') , 'test1_junk 1\\\\3' | regex_replace('(.*)_junk (.*)', '\\\\1 \\\\2') ) }}" - -* trailing newline When a string with a trailing newline was specified in the - playbook through yaml dict format, the trailing newline was stripped. When - specified in key=value format, the trailing newlines were kept. In v2, both - methods of specifying the string will keep the trailing newlines. If you - relied on the trailing newline being stripped, you can change your playbook - using the following as an example:: - - - * Syntax in 1.9.x - - .. code-block:: yaml - - vars: - message: > - Testing - some things - tasks: - - debug: - msg: "{{ message }}" - - - * Syntax in 2.0.x - - .. code-block:: yaml - - vars: - old_message: > - Testing - some things - message: "{{ old_message[:-1] }}" - - debug: - msg: "{{ message }}" - - - * Output - - .. code-block:: yaml - - "msg": "Testing some things" - -* Behavior of templating DOS-type text files changes with Ansible v2. - - A bug in Ansible v1 causes DOS-type text files (using a carriage return and newline) to be templated to Unix-type text files (using only a newline). In Ansible v2 this long-standing bug was finally fixed and DOS-type text files are preserved correctly. This may be confusing when you expect your playbook to not show any differences when migrating to Ansible v2, while in fact you will see every DOS-type file being completely replaced (with what appears to be the exact same content). - -* When specifying complex args as a variable, the variable must use the full jinja2 - variable syntax (```{{var_name}}```) - bare variable names there are no longer accepted. - In fact, even specifying args with variables has been deprecated, and will not be - allowed in future versions: - -.. code-block:: yaml - - --- - - hosts: localhost - connection: local - gather_facts: false - vars: - my_dirs: - - { path: /tmp/3a, state: directory, mode: 0755 } - - { path: /tmp/3b, state: directory, mode: 0700 } - tasks: - - file: - args: "{{item}}" - with_items: "{{my_dirs}}" - -* porting task includes -* More dynamic. Corner-case formats that were not supposed to work now do not, as expected. -* variables defined in the yaml dict format see `issue 13324 `_ -* templating (variables in playbooks and template lookups) has improved with regard to keeping the original instead of turning everything into a string. - If you need the old behavior, quote the value to pass it around as a string. -* Empty variables and variables set to null in yaml are no longer converted to empty strings. They will retain the value of `None`. - You can override the `null_representation` setting to an empty string in your config file by setting the :envvar:`ANSIBLE_NULL_REPRESENTATION` environment variable. -* Extras callbacks must be enabled in ansible.cfg. Copying is no longer necessary but you must enable them in ansible.cfg. -* dnf module has been rewritten. Some minor changes in behavior may be observed. -* win_updates has been rewritten and works as expected now. -* from 2.0.1 onwards, the implicit setup task from gather_facts now correctly inherits everything from play, but this might cause issues for those setting - `environment` at the play level and depending on `ansible_env` existing. Previously this was ignored but now might issue an 'Undefined' error. - -Deprecated ----------- - -While all items listed here will show a deprecation warning message, they still work as they did in 1.9.x. Please note that they will be removed in 2.2 (Ansible always waits two major releases to remove a deprecated feature). - -* Bare variables in ``with_`` loops should instead use the ``"{{ var }}"`` syntax, which helps eliminate ambiguity. -* The ansible-galaxy text format requirements file. Users should use the YAML format for requirements instead. -* Undefined variables within a ``with_`` loop's list currently do not interrupt the loop, but they do issue a warning; in the future, they will issue an error. -* Using dictionary variables to set all task parameters is unsafe and will be removed in a future version. Example of a deprecated variant: - -.. code-block:: yaml - - - hosts: localhost - gather_facts: no - vars: - debug_params: - msg: "hello there" - tasks: - - debug: "{{debug_params}}" - - debug: - args: "{{debug_params}}" - -Example of a recommended variant: - -.. code-block:: yaml - - - hosts: localhost - gather_facts: no - vars: - debug_params: - msg: "hello there" - tasks: - - debug: - msg: "{{debug_params['msg']}}" - -* Host patterns should use a comma (,) or colon (:) instead of a semicolon (;) to separate hosts/groups in the pattern. -* Ranges specified in host patterns should use the [x:y] syntax, instead of [x-y]. -* Playbooks using privilege escalation should always use "become*" options rather than the old su*/sudo* options. -* The "short form" for vars_prompt is no longer supported. - For example:: - - vars_prompt: - variable_name: "Prompt string" - -* Specifying variables at the top level of a task include statement is no longer supported. For example:: - - - include_tasks: foo.yml - a: 1 - -Should now be:: - - - include_tasks: foo.yml - vars: - a: 1 - -* Setting any_errors_fatal on a task is no longer supported. This should be set at the play level only. -* Bare variables in the `environment` dictionary (for plays/tasks/and so on) are no longer supported. Variables specified there should use the full variable syntax: '{{foo}}'. -* Tags (or any directive) should no longer be specified with other parameters in a task include. Instead, they should be specified as an option on the task. - For example:: - - - include_tasks: foo.yml tags=a,b,c - - Should be:: - - - include_tasks: foo.yml - tags: [a, b, c] - -* The first_available_file option on tasks has been deprecated. Users should use the with_first_found option or lookup ('first_found', …) plugin. - - -Other caveats -------------- - -Here are some corner cases encountered when updating. These are mostly caused by the more stringent parser validation and the capture of errors that were previously ignored. - -* Bad variable composition:: - - with_items: myvar_{{rest_of_name}} - - This worked 'by accident' as the errors were retemplated and ended up resolving the variable, it was never intended as valid syntax and now properly returns an error, use the following instead.:: - - hostvars[inventory_hostname]['myvar_' + rest_of_name] - -* Misspelled directives:: - - - task: dostuf - becom: yes - - The task always ran without using privilege escalation (for that you need `become`) but was also silently ignored so the play 'ran' even though it should not, now this is a parsing error. - - -* Duplicate directives:: - - - task: dostuf - when: True - when: False - - The first `when` was ignored and only the 2nd one was used as the play ran w/o warning it was ignoring one of the directives, now this produces a parsing error. - -* Conflating variables and directives:: - - - role: {name=rosy, port=435 } - - # in tasks/main.yml - - wait_for: port={{port}} - - The `port` variable is reserved as a play/task directive for overriding the connection port, in previous versions this got conflated with a variable named `port` and was usable - later in the play, this created issues if a host tried to reconnect or was using a non caching connection. Now it will be correctly identified as a directive and the `port` variable - will appear as undefined, this now forces the use of non conflicting names and removes ambiguity when adding settings and variables to a role invocation. - -* Bare operations on `with_`:: - - with_items: var1 + var2 - - An issue with the 'bare variable' features, which was supposed only template a single variable without the need of braces ({{ )}}, would in some versions of Ansible template full expressions. - Now you need to use proper templating and braces for all expressions everywhere except conditionals (`when`):: - - with_items: "{{var1 + var2}}" - - The bare feature itself is deprecated as an undefined variable is indistinguishable from a string which makes it difficult to display a proper error. - -Porting plugins -=============== - -In ansible-1.9.x, you would generally copy an existing plugin to create a new one. Simply implementing the methods and attributes that the caller of the plugin expected made it a plugin of that type. In ansible-2.0, most plugins are implemented by subclassing a base class for each plugin type. This way the custom plugin does not need to contain methods which are not customized. - - -Lookup plugins --------------- - -* lookup plugins ; import version - - -Connection plugins ------------------- - -* connection plugins - -Action plugins --------------- - - -* action plugins - -Callback plugins ----------------- - -Although Ansible 2.0 provides a new callback API the old one continues to work -for most callback plugins. However, if your callback plugin makes use of -:attr:`self.playbook`, :attr:`self.play`, or :attr:`self.task` then you will -have to store the values for these yourself as ansible no longer automatically -populates the callback with them. Here's a short snippet that shows you how: - -.. code-block:: python - - import os - from ansible.plugins.callback import CallbackBase - - class CallbackModule(CallbackBase): - def __init__(self): - self.playbook = None - self.playbook_name = None - self.play = None - self.task = None - - def v2_playbook_on_start(self, playbook): - self.playbook = playbook - self.playbook_name = os.path.basename(self.playbook._file_name) - - def v2_playbook_on_play_start(self, play): - self.play = play - - def v2_playbook_on_task_start(self, task, is_conditional): - self.task = task - - def v2_on_any(self, *args, **kwargs): - self._display.display('%s: %s: %s' % (self.playbook_name, - self.play.name, self.task)) - - -Connection plugins ------------------- - -* connection plugins - - -Hybrid plugins -============== - -In specific cases you may want a plugin that supports both ansible-1.9.x *and* ansible-2.0. Much like porting plugins from v1 to v2, you need to understand how plugins work in each version and support both requirements. - -Since the ansible-2.0 plugin system is more advanced, it is easier to adapt your plugin to provide similar pieces (subclasses, methods) for ansible-1.9.x as ansible-2.0 expects. This way your code will look a lot cleaner. - -You may find the following tips useful: - -* Check whether the ansible-2.0 class(es) are available and if they are missing (ansible-1.9.x) mimic them with the needed methods (for example, ``__init__``) - -* When ansible-2.0 python modules are imported, and they fail (ansible-1.9.x), catch the ``ImportError`` exception and perform the equivalent imports for ansible-1.9.x. With possible translations (for example, importing specific methods). - -* Use the existence of these methods as a qualifier to what version of Ansible you are running. So rather than using version checks, you can do capability checks instead. (See examples below) - -* Document for each if-then-else case for which specific version each block is needed. This will help others to understand how they have to adapt their plugins, but it will also help you to remove the older ansible-1.9.x support when it is deprecated. - -* When doing plugin development, it is very useful to have the ``warning()`` method during development, but it is also important to emit warnings for deadends (cases that you expect should never be triggered) or corner cases (for example, cases where you expect misconfigurations). - -* It helps to look at other plugins in ansible-1.9.x and ansible-2.0 to understand how the API works and what modules, classes and methods are available. - - -Lookup plugins --------------- - -As a simple example we are going to make a hybrid ``fileglob`` lookup plugin. - -.. code-block:: python - - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type - - import os - import glob - - try: - # ansible-2.0 - from ansible.plugins.lookup import LookupBase - except ImportError: - # ansible-1.9.x - - class LookupBase(object): - def __init__(self, basedir=None, runner=None, **kwargs): - self.runner = runner - self.basedir = self.runner.basedir - - def get_basedir(self, variables): - return self.basedir - - try: - # ansible-1.9.x - from ansible.utils import (listify_lookup_plugin_terms, path_dwim, warning) - except ImportError: - # ansible-2.0 - from ansible.utils.display import Display - warning = Display().warning - - class LookupModule(LookupBase): - - # For ansible-1.9.x, we added inject=None as valid argument - def run(self, terms, inject=None, variables=None, **kwargs): - - # ansible-2.0, but we made this work for ansible-1.9.x too ! - basedir = self.get_basedir(variables) - - # ansible-1.9.x - if 'listify_lookup_plugin_terms' in globals(): - terms = listify_lookup_plugin_terms(terms, basedir, inject) - - ret = [] - for term in terms: - term_file = os.path.basename(term) - - # For ansible-1.9.x, we imported path_dwim() from ansible.utils - if 'path_dwim' in globals(): - # ansible-1.9.x - dwimmed_path = path_dwim(basedir, os.path.dirname(term)) - else: - # ansible-2.0 - dwimmed_path = self._loader.path_dwim_relative(basedir, 'files', os.path.dirname(term)) - - globbed = glob.glob(os.path.join(dwimmed_path, term_file)) - ret.extend(g for g in globbed if os.path.isfile(g)) - - return ret - -.. Note:: In the above example we did not use the ``warning()`` method as we had no direct use for it in the final version. However we left this code in so people can use this part during development/porting/use. - - - -Connection plugins ------------------- - -* connection plugins - -Action plugins --------------- - -* action plugins - -Callback plugins ----------------- - -* callback plugins - -Connection plugins ------------------- - -* connection plugins - - -Porting custom scripts -====================== - -Custom scripts that used the ``ansible.runner.Runner`` API in 1.x have to be ported in 2.x. Please refer to: :ref:`developing_api` diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.10.rst b/docs/docsite/rst/porting_guides/porting_guide_2.10.rst deleted file mode 100644 index ff0a1eff690..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.10.rst +++ /dev/null @@ -1,962 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_base_2.10.rst) - -.. _porting_2.10_guide: - -========================== -Ansible 2.10 Porting Guide -========================== - -.. warning:: - - In Ansible 2.10, many plugins and modules have migrated to Collections on `Ansible Galaxy `_. Your playbooks should continue to work without any changes. We recommend you start using the fully-qualified collection name (FQCN) in your playbooks as the explicit and authoritative indicator of which collection to use as some collections may contain duplicate module names. You can search the `index of all modules `_ to find the collection a module has been relocated to. - -This section discusses the behavioral changes between Ansible 2.9 and Ansible 2.10. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with the `Ansible Changelog for 2.10 `_ to understand what updates you may need to make. - -Since 2.10, Ansible consists of two parts: - -* ansible-base, which includes the command line tools with a small selection of plugins and modules, and -* a `set of collections `_. - -The :ref:`porting_2.10_guide_base` is included in this porting guide. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: - :local: - :depth: 2 - - -Playbook -======== - -* Fixed a bug on boolean keywords that made random strings return 'False', now they should return an error if they are not a proper boolean - Example: ``diff: yes-`` was returning ``False``. -* A new fact, ``ansible_processor_nproc`` reflects the number of vcpus - available to processes (falls back to the number of vcpus available to - the scheduler). - - -Command Line -============ - -* The ``ansible-galaxy login`` command has been removed, as the underlying API it used for GitHub auth is being shut down. Publishing roles or - collections to Galaxy through ``ansible-galaxy`` now requires that a Galaxy API token be passed to the CLI through a token file (default location - ``~/.ansible/galaxy_token``) or (insecurely) through the ``--token`` argument to ``ansible-galaxy``. - - -Deprecated -========== - -* Windows Server 2008 and 2008 R2 will no longer be supported or tested in the next Ansible release, see :ref:`windows_faq_server2008`. - - -Modules -======= - -.. warning:: - - Links on this page may not point to the most recent versions of modules. We will update them when we can. - -* Version 2.10.0 of ansible-base changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the mode change has been reverted in 2.10.1, and mode will now default to ``0o666 & ~umask`` as in previous versions of Ansible. -* If you changed any tasks to specify less restrictive permissions while using 2.10.0, those changes will be unnecessary (but will do no harm) in 2.10.1. -* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it. - -* ``dnf`` and ``yum`` - As of version 2.10.1, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task. - - -Noteworthy module changes -------------------------- - -* Ansible modules created with ``add_file_common_args=True`` added a number of undocumented arguments which were mostly there to ease implementing certain action plugins. The undocumented arguments ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode`` are now no longer added. Modules relying on these options to be added need to specify them by themselves. -* Ansible no longer looks for Python modules in the current working directory (typically the ``remote_user``'s home directory) when an Ansible module is run. This is to fix becoming an unprivileged user on OpenBSD and to mitigate any attack vector if the current working directory is writable by a malicious user. Install any Python modules needed to run the Ansible modules on the managed node in a system-wide location or in another directory which is in the ``remote_user``'s ``$PYTHONPATH`` and readable by the ``become_user``. - - -Plugins -======= - -Lookup plugin names case-sensitivity ------------------------------------- - -* Prior to Ansible ``2.10`` lookup plugin names passed in as an argument to the ``lookup()`` function were treated as case-insensitive as opposed to lookups invoked through ``with_``. ``2.10`` brings consistency to ``lookup()`` and ``with_`` to be both case-sensitive. - -Noteworthy plugin changes -------------------------- - -* Cache plugins in collections can be used to cache data from inventory plugins. Previously, cache plugins in collections could only be used for fact caching. -* Some undocumented arguments from ``FILE_COMMON_ARGUMENTS`` have been removed; plugins using these, in particular action plugins, need to be adjusted. The undocumented arguments which were removed are ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode``. - -Action plugins which execute modules should use fully-qualified module names ----------------------------------------------------------------------------- - -* Action plugins that call modules should pass explicit, fully-qualified module names to ``_execute_module()`` whenever possible (eg, ``ansible.builtin.file`` rather than ``file``). This ensures that the task's collection search order is not consulted to resolve the module. Otherwise, a module from a collection earlier in the search path could be used when not intended. - -Porting custom scripts -====================== - -No notable changes - -Porting Guide for v2.10.7 -========================= - -Breaking Changes ----------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- utm_proxy_auth_profile - the ``frontend_cookie_secret`` return value now contains a placeholder string instead of the module's ``frontend_cookie_secret`` parameter (https://github.com/ansible-collections/community.general/pull/1736). - -Major Changes -------------- - -- Restricting the version of the community.okd collection to 1.0.0. The previously included version, 1.0.1, had a dependency on kubernetes.core and thus required the installation of an additional collection that was not included in Ansible 2.10. Version 1.0.0 is essentially identical to 1.0.1, except that it uses community.kubernetes, which is included in Ansible 2.10. - -ovirt.ovirt -~~~~~~~~~~~ - -- ovirt_system_option_info - Add new module (https://github.com/oVirt/ovirt-ansible-collection/pull/206). - -servicenow.servicenow -~~~~~~~~~~~~~~~~~~~~~ - -- add new tests (find with no result, search many) -- add related tests -- add support for ServiceNOW table api display_value exclude_reference_link and suppress_pagination_header -- use new API for pysnow >=0.6.0 - -Deprecated Features -------------------- - -cisco.nxos -~~~~~~~~~~ - -- Deprecated `nxos_bgp` and `nxos_bgp_neighbor` modules in favor of `nxos_bgp_global` resource module. - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_host_firewall_manager - the creation of new rule with no ``allowed_ip`` entry in the ``allowed_hosts`` dictionary won't be allowed after 2.0.0 release. - -Porting Guide for v2.10.6 -========================= - -Major Changes -------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- For community.general 2.0.0, the kubevirt modules will be moved to the `community.kubevirt `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use kubevirt modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.kubevirt.`` instead of ``community.general.``, - for example replace ``community.general.kubevirt_vm`` in a task by ``community.kubevirt.kubevirt_vm``. - - If you use ansible-base and installed ``community.general`` manually and rely on the kubevirt modules, you have to make sure to install the ``community.kubevirt`` collection as well. - If you are using FQCNs, for example ``community.general.kubevirt_vm`` instead of ``kubevirt_vm``, it will continue working, but we still recommend to adjust the FQCNs as well. - -community.network -~~~~~~~~~~~~~~~~~ - -- For community.network 2.0.0, the Cisco NSO modules will be moved to the `cisco.nso `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use Cisco NSO modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``cisco.nso.`` instead of ``community.network.``, - for example replace ``community.network.nso_config`` in a task by ``cisco.nso.nso_config``. - - If you use ansible-base and installed ``community.network`` manually and rely on the Cisco NSO modules, you have to make sure to install the ``cisco.nso`` collection as well. - If you are using FQCNs, for example ``community.network.nso_config`` instead of ``nso_config``, it will continue working, but we still recommend to adjust the FQCNs as well. -- For community.network 2.0.0, the FortiOS modules will be moved to the `community.fortios `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use FortiOS modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.fortios.`` instead of ``community.network.``, - for example replace ``community.network.fmgr_device`` in a task by ``community.fortios.fmgr_device``. - - If you use ansible-base and installed ``community.network`` manually and rely on the FortiOS modules, you have to make sure to install the ``community.fortios`` collection as well. - If you are using FQCNs, for example ``community.network.fmgr_device`` instead of ``fmgr_device``, it will continue working, but we still recommend to adjust the FQCNs as well. - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Added async_timeout parameter to bigip_ucs_fetch module to allow customization of module wait for async interface -- Changed bigip_ucs_fetch module to use asynchronous interface when generating UCS files - -Porting Guide for v2.10.5 -========================= - -Breaking Changes ----------------- - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault - the ``VAULT_ADDR`` environment variable is now checked last for the ``url`` parameter. For details on which use cases are impacted, see (https://github.com/ansible-collections/community.hashi_vault/issues/8). - -Major Changes -------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- For community.general 2.0.0, the Google modules will be moved to the `community.google `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use Google modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.google.`` instead of ``community.general.``, - for example replace ``community.general.gcpubsub`` in a task by ``community.google.gcpubsub``. - - If you use ansible-base and installed ``community.general`` manually and rely on the Google modules, you have to make sure to install the ``community.google`` collection as well. - If you are using FQCNs, for example ``community.general.gcpubsub`` instead of ``gcpubsub``, it will continue working, but we still recommend to adjust the FQCNs as well. -- For community.general 2.0.0, the OC connection plugin will be moved to the `community.okd `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use OC connection plugin from this collection, you will need to adjust your playbooks and roles to use FQCNs ``community.okd.oc`` instead of ``community.general.oc``. - - If you use ansible-base and installed ``community.general`` manually and rely on the OC connection plugin, you have to make sure to install the ``community.okd`` collection as well. - If you are using FQCNs, in other words ``community.general.oc`` instead of ``oc``, it will continue working, but we still recommend to adjust this FQCN as well. -- For community.general 2.0.0, the hashi_vault lookup plugin will be moved to the `community.hashi_vault `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use hashi_vault lookup plugin from this collection, you will need to adjust your playbooks and roles to use FQCNs ``community.hashi_vault.hashi_vault`` instead of ``community.general.hashi_vault``. - - If you use ansible-base and installed ``community.general`` manually and rely on the hashi_vault lookup plugin, you have to make sure to install the ``community.hashi_vault`` collection as well. - If you are using FQCNs, in other words ``community.general.hashi_vault`` instead of ``hashi_vault``, it will continue working, but we still recommend to adjust this FQCN as well. - -netbox.netbox -~~~~~~~~~~~~~ - -- nb_inventory - Add ``dns_name`` option that adds ``dns_name`` to the host when ``True`` and device has a primary IP address. (#394) -- nb_inventory - Add ``status`` as a ``group_by`` option. (398) -- nb_inventory - Move around ``extracted_primary_ip`` to allow for ``config_context`` or ``custom_field`` to overwrite. (#377) -- nb_inventory - Services are now a list of integers due to NetBox 2.10 changes. (#396) -- nb_lookup - Allow ID to be passed in and use ``.get`` instead of ``.filter``. (#376) -- nb_lookup - Allow ``api_endpoint`` and ``token`` to be found through env. (#391) - -Deprecated Features -------------------- - -community.aws -~~~~~~~~~~~~~ - -- ec2_vpc_igw_info - After 2022-06-22 the ``convert_tags`` parameter default value will change from ``False`` to ``True`` to match the collection standard behavior (https://github.com/ansible-collections/community.aws/pull/318). - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_container - currently ``published_ports`` can contain port mappings next to the special value ``all``, in which case the port mappings are ignored. This behavior is deprecated for community.docker 2.0.0, at which point it will either be forbidden, or this behavior will be properly implemented similar to how the Docker CLI tool handles this (https://github.com/ansible-collections/community.docker/issues/8, https://github.com/ansible-collections/community.docker/pull/60). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault - ``VAULT_ADDR`` environment variable for option ``url`` will have its precedence lowered in 1.0.0; use ``ANSIBLE_HASHI_VAULT_ADDR`` to intentionally override a config value (https://github.com/ansible-collections/community.hashi_vault/issues/8). -- hashi_vault - ``VAULT_AUTH_METHOD`` environment variable for option ``auth_method`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_AUTH_METHOD`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/17). -- hashi_vault - ``VAULT_ROLE_ID`` environment variable for option ``role_id`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_ROLE_ID`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/20). -- hashi_vault - ``VAULT_SECRET_ID`` environment variable for option ``secret_id`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_SECRET_ID`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/20). -- hashi_vault - ``VAULT_TOKEN_FILE`` environment variable for option ``token_file`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_TOKEN_FILE`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/15). -- hashi_vault - ``VAULT_TOKEN_PATH`` environment variable for option ``token_path`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_TOKEN_PATH`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/15). - -Porting Guide for v2.10.4 -========================= - -Breaking Changes ----------------- - -community.hrobot -~~~~~~~~~~~~~~~~ - -- firewall - now requires the `ipaddress `_ library (https://github.com/ansible-collections/community.hrobot/pull/2). - -Major Changes -------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- For community.general 2.0.0, the Hetzner Robot modules will be moved to the `community.hrobot `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use Hetzner Robot modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.hrobot.`` instead of ``community.general.hetzner_``, - for example replace ``community.general.hetzner_firewall_info`` in a task by ``community.hrobot.firewall_info``. - - If you use ansible-base and installed ``community.general`` manually and rely on the Hetzner Robot modules, you have to make sure to install the ``community.hrobot`` collection as well. - If you are using FQCNs, i.e. ``community.general.hetzner_failover_ip`` instead of ``hetzner_failover_ip``, it will continue working, but we still recommend to adjust the FQCNs as well. -- For community.general 2.0.0, the ``docker`` modules and plugins will be moved to the `community.docker `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use ``docker`` content from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.docker.`` instead of ``community.general.``, - for example replace ``community.general.docker_container`` in a task by ``community.docker.docker_container``. - - If you use ansible-base and installed ``community.general`` manually and rely on the ``docker`` content, you have to make sure to install the ``community.docker`` collection as well. - If you are using FQCNs, i.e. ``community.general.docker_container`` instead of ``docker_container``, it will continue working, but we still recommend to adjust the FQCNs as well. -- For community.general 2.0.0, the ``postgresql`` modules and plugins will be moved to the `community.postgresql `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use ``postgresql`` content from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.postgresql.`` instead of ``community.general.``, - for example replace ``community.general.postgresql_info`` in a task by ``community.postgresql.postgresql_info``. - - If you use ansible-base and installed ``community.general`` manually and rely on the ``postgresql`` content, you have to make sure to install the ``community.postgresql`` collection as well. - If you are using FQCNs, i.e. ``community.general.postgresql_info`` instead of ``postgresql_info``, it will continue working, but we still recommend to adjust the FQCNs as well. -- The community.general collection no longer depends on the ansible.posix collection (https://github.com/ansible-collections/community.general/pull/1157). - -community.network -~~~~~~~~~~~~~~~~~ - -- For community.network 2.0.0, the ``routeros`` modules and plugins will be moved to the `community.routeros `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use ``routeros`` content from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.routeros.`` instead of ``community.network.routeros_``, - for example replace ``community.network.routeros_api`` in a task by ``community.routeros.api``. - - If you use ansible-base and installed ``community.network`` manually and rely on the ``routeros`` content, you have to make sure to install the ``community.routeros`` collection as well. - If you are using FQCNs, i.e. ``community.network.routeros_command`` instead of ``routeros_command``, it will continue working, but we still recommend to adjust the FQCNs as well. -- In community.network 2.0.0, the ``fortimanager`` httpapi plugin will be removed and replaced by a redirect to the corresponding plugin in the fortios.fortimanager collection. For Ansible 2.10 and ansible-base 2.10 users, this means that it will continue to work assuming that collection is installed. For Ansible 2.9 users, this means that they have to adjust the FQCN from ``community.network.fortimanager`` to ``fortios.fortimanager.fortimanager`` (https://github.com/ansible-collections/community.network/pull/151). - -community.okd -~~~~~~~~~~~~~ - -- Add custom k8s module, integrate better Molecule tests (https://github.com/ansible-collections/community.okd/pull/7). -- Add downstream build scripts to build redhat.openshift (https://github.com/ansible-collections/community.okd/pull/20). -- Add openshift connection plugin, update inventory plugin to use it (https://github.com/ansible-collections/community.okd/pull/18). -- Add openshift_process module for template rendering and optional application of rendered resources (https://github.com/ansible-collections/community.okd/pull/44). -- Add openshift_route module for creating routes from services (https://github.com/ansible-collections/community.okd/pull/40). -- Initial content migration from community.kubernetes (https://github.com/ansible-collections/community.okd/pull/3). -- openshift_auth - new module (migrated from k8s_auth in community.kubernetes) (https://github.com/ansible-collections/community.okd/pull/33). - -Removed Features ----------------- - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_container - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_container - the default of ``networks_cli_compatible`` changed to ``true`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_container - the unused option ``trust_image_content`` has been removed (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - ``state=build`` has been removed. Use ``present`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``container_limits``, ``dockerfile``, ``http_timeout``, ``nocache``, ``rm``, ``path``, ``buildargs``, ``pull`` have been removed. Use the corresponding suboptions of ``build`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``force`` option has been removed. Use the more specific ``force_*`` options instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``source`` option is now mandatory (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``use_tls`` option has been removed. Use ``tls`` and ``validate_certs`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the default of the ``build.pull`` option changed to ``false`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image_facts - this alias is on longer available, use ``docker_image_info`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_network - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_network - the ``ipam_options`` option has been removed. Use ``ipam_config`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_service - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm - ``state=inspect`` has been removed. Use ``docker_swarm_info`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``constraints`` option has been removed. Use ``placement.constraints`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``limit_cpu`` and ``limit_memory`` options has been removed. Use the corresponding suboptions in ``limits`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``log_driver`` and ``log_driver_options`` options has been removed. Use the corresponding suboptions in ``logging`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``reserve_cpu`` and ``reserve_memory`` options has been removed. Use the corresponding suboptions in ``reservations`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``restart_policy``, ``restart_policy_attempts``, ``restart_policy_delay`` and ``restart_policy_window`` options has been removed. Use the corresponding suboptions in ``restart_config`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``update_delay``, ``update_parallelism``, ``update_failure_action``, ``update_monitor``, ``update_max_failure_ratio`` and ``update_order`` options has been removed. Use the corresponding suboptions in ``update_config`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_volume - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_volume - the ``force`` option has been removed. Use ``recreate`` instead (https://github.com/ansible-collections/community.docker/pull/1). - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- django_manage - the parameter ``liveserver`` relates to a no longer maintained third-party module for django. It is now deprecated, and will be remove in community.general 3.0.0 (https://github.com/ansible-collections/community.general/pull/1154). -- proxmox - the default of the new ``proxmox_default_behavior`` option will change from ``compatibility`` to ``no_defaults`` in community.general 4.0.0. Set the option to an explicit value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/850). -- proxmox_kvm - the default of the new ``proxmox_default_behavior`` option will change from ``compatibility`` to ``no_defaults`` in community.general 4.0.0. Set the option to an explicit value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/850). -- syspatch - deprecate the redundant ``apply`` argument (https://github.com/ansible-collections/community.general/pull/360). - -community.network -~~~~~~~~~~~~~~~~~ - -- Deprecate connection=local support for network platforms using persistent framework (https://github.com/ansible-collections/community.network/pull/120). - -Porting Guide for v2.10.2 -========================= - -Breaking Changes ----------------- - -Ansible-base -~~~~~~~~~~~~ - -- ansible-galaxy login command has been removed (see https://github.com/ansible/ansible/issues/71560) - -Major Changes -------------- - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Add phone home Teem integration into all modules, functionality can be disabled by setting up F5_TEEM environment variable or no_f5_teem provider parameter - -ovirt.ovirt -~~~~~~~~~~~ - -- cluster_upgrade - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/94). -- disaster_recovery - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/134). -- engine_setup - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/69). -- hosted_engine_setup - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/106). -- image_template - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/95). -- infra - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/92). -- manageiq - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/97). -- repositories - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/96). -- shutdown_env - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/112). -- vm_infra - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/93). - -Removed Features ----------------- - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Removed arp_state parameter from the bigip_virtual_address module - -Deprecated Features -------------------- - -cisco.nxos -~~~~~~~~~~ - -- Deprecated `nxos_interface_ospf` in favor of `nxos_ospf_interfaces` Resource Module. - -Porting Guide for v2.10.1 -========================= - -Major Changes -------------- - -community.kubernetes -~~~~~~~~~~~~~~~~~~~~ - -- k8s - Add support for template parameter (https://github.com/ansible-collections/community.kubernetes/pull/230). -- k8s_* - Add support for vaulted kubeconfig and src (https://github.com/ansible-collections/community.kubernetes/pull/193). - -Deprecated Features -------------------- - -cisco.nxos -~~~~~~~~~~ - -- Deprecated `nxos_smu` in favor of `nxos_rpm` module. -- The `nxos_ospf_vrf` module is deprecated by `nxos_ospfv2` and `nxos_ospfv3` Resource Modules. - -Porting Guide for v2.10.0 -========================= - -Known Issues ------------- - -- Due to a limitation in pip, you cannot ``pip install --upgrade`` from ansible-2.9 or earlier to ansible-2.10 or higher. Instead, you must explicitly use ``pip uninstall ansible`` before pip installing the new version. If you attempt to upgrade Ansible with pip without first uninstalling, the installer warns you to uninstall first. -- The individual collections that make up the ansible-2.10.0 package can be viewed independently. However, they are not currently listed by ansible-galaxy. To view these collections with ansible-galaxy, explicitly specify where ansible has installed the collections -- ``COLLECTION_INSTALL=$(python -c 'import ansible, os.path ; print("%s/../ansible_collections" % os.path.dirname(ansible.__file__))') ansible-galaxy collection list -p "$COLLECTION_INSTALL"``. -- These fortios modules are not automatically redirected from their 2.9.x names to the new 2.10.x names within collections. You must modify your playbooks to use fully qualified collection names for them. You can use the documentation (https://docs.ansible.com/ansible/2.10/collections/fortinet/fortios/) for the ``fortinet.fortios`` collection to determine what the fully qualified collection names are. - - * fortios_address - * fortios_config - * fortios_firewall_DoS_policy - * fortios_firewall_DoS_policy6 - * fortios_ipv4_policy - * fortios_switch_controller_802_1X_settings - * fortios_switch_controller_security_policy_802_1X - * fortios_system_firmware_upgrade - * fortios_system_nd_proxy - * fortios_webfilter - -community.grafana -~~~~~~~~~~~~~~~~~ - -- grafana_datasource doesn't set password correctly (#113) - -Breaking Changes ----------------- - -- cisco.nxos.nxos_igmp_interface - no longer supports the deprecated ``oif_prefix`` and ``oif_source`` options. These have been superseded by ``oif_ps``. -- community.grafana.grafana_dashboard - the parameter ``message`` is renamed to ``commit_message`` since ``message`` is used by Ansible Core engine internally. -- purestorage.flashblade.purefb_fs - no longer supports the deprecated ``nfs`` option. This has been superseded by ``nfsv3``. - -amazon.aws -~~~~~~~~~~ - -- aws_s3 - can now delete versioned buckets even when they are not empty - set mode to delete to delete a versioned bucket and everything in it. - -ansible.windows -~~~~~~~~~~~~~~~ - -- setup - Make sure ``ansible_date_time.epoch`` is seconds since EPOCH in UTC to mirror the POSIX facts. The ``ansible_date_time.epoch_local`` contains seconds since EPOCH in the local timezone for backwards compatibility -- setup - Will now add the IPv6 scope on link local addresses for ``ansible_ip_addresses`` -- setup - ``ansible_processor`` will now return the index before the other values to match the POSIX fact behaviour -- win_find - No longer filters by size on directories, this feature had a lot of bugs, slowed down the module, and not a supported scenario with the ``find`` module. -- win_find - module has been refactored to better match the behaviour of the ``find`` module. Here is what has changed: - * When the directory specified by ``paths`` does not exist or is a file, it will no longer fail and will just warn the user - * Junction points are no longer reported as ``islnk``, use ``isjunction`` to properly report these files. This behaviour matches the win_stat module - * Directories no longer return a ``size``, this matches the ``stat`` and ``find`` behaviour and has been removed due to the difficulties in correctly reporting the size of a directory -- win_user - Change idempotency checks for ``description`` to be case sensitive -- win_user - Change idempotency checks for ``fullname`` to be case sensitive - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_device - Changed tags from string to list -- meraki_device - Removed serial_lldp_cdp parameter -- meraki_device - Removed serial_uplink parameter -- meraki_intrusion_prevention - Rename whitedlisted_rules to allowed_rules -- meraki_mx_l3_firewall - Rule responses are now in a `rules` list -- meraki_mx_l7_firewall - Rename blacklisted_countries to blocked_countries -- meraki_mx_l7_firewall - Rename whitelisted_countries to allowed_countries -- meraki_network - Local and remote status page settings cannot be set during network creation -- meraki_network - `disableRemoteStatusPage` response is now `remote_status_page_enabled` -- meraki_network - `disable_my_meraki_com` response is now `local_status_page_enabled` -- meraki_network - `disable_my_meraki` has been deprecated -- meraki_network - `enable_my_meraki` is now called `local_status_page_enabled` -- meraki_network - `enable_remote_status_page` is now called `remote_status_page_enabled` -- meraki_network - `enabled` response for VLAN status is now `vlans_enabled` -- meraki_network - `tags` and `type` now return a list -- meraki_snmp - peer_ips is now a list -- meraki_switchport - `access_policy_number` is now an int and not a string -- meraki_switchport - `tags` is now a list and not a string -- meraki_webhook - Querying test status now uses state of query. - -community.general -~~~~~~~~~~~~~~~~~ - -- The environment variable for the auth context for the oc.py connection plugin has been corrected (K8S_CONTEXT). It was using an initial lowercase k by mistake. (https://github.com/ansible-collections/community.general/pull/377). -- bigpanda - the parameter ``message`` was renamed to ``deployment_message`` since ``message`` is used by Ansible Core engine internally. -- cisco_spark - the module option ``message`` was renamed to ``msg``, as ``message`` is used internally in Ansible Core engine (https://github.com/ansible/ansible/issues/39295) -- datadog - the parameter ``message`` was renamed to ``notification_message`` since ``message`` is used by Ansible Core engine internally. -- docker_container - no longer passes information on non-anonymous volumes or binds as ``Volumes`` to the Docker daemon. This increases compatibility with the ``docker`` CLI program. Note that if you specify ``volumes: strict`` in ``comparisons``, this could cause existing containers created with docker_container from Ansible 2.9 or earlier to restart. -- docker_container - support for port ranges was adjusted to be more compatible to the ``docker`` command line utility: a one-port container range combined with a multiple-port host range will no longer result in only the first host port be used, but the whole range being passed to Docker so that a free port in that range will be used. -- hashi_vault lookup - now returns the latest version when using the KV v2 secrets engine. Previously, it returned all versions of the secret which required additional steps to extract and filter the desired version. -- log_plays callback - add missing information to the logs generated by the callback plugin. This changes the log message format (https://github.com/ansible-collections/community.general/pull/442). -- pkgng - passing ``name: *`` with ``state: absent`` will no longer remove every installed package from the system. It is now a noop. (https://github.com/ansible-collections/community.general/pull/569). -- pkgng - passing ``name: *`` with ``state: latest`` or ``state: present`` will no longer install every package from the configured package repositories. Instead, ``name: *, state: latest`` will upgrade all already-installed packages, and ``name: *, state: present`` is a noop. (https://github.com/ansible-collections/community.general/pull/569). - -community.network -~~~~~~~~~~~~~~~~~ - -- routeros_facts - allow multiple addresses and neighbors per interface. This makes ``ansible_net_neighbors`` a list instead of a dict (https://github.com/ansible-collections/community.network/pull/6). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_datastore_maintenancemode - now returns ``datastore_status`` instead of Ansible internal key ``results``. -- vmware_guest_custom_attributes - does not require VM name which was a required parameter for releases prior to Ansible 2.10. -- vmware_guest_find - the ``datacenter`` option has been removed. -- vmware_host_kernel_manager - now returns ``host_kernel_status`` instead of Ansible internal key ``results``. -- vmware_host_ntp - now returns ``host_ntp_status`` instead of Ansible internal key ``results``. -- vmware_host_service_manager - now returns ``host_service_status`` instead of Ansible internal key ``results``. -- vmware_tag - now returns ``tag_status`` instead of Ansible internal key ``results``. -- vmware_vmkernel - the options ``ip_address`` and ``subnet_mask`` have been removed; use the suboptions ``ip_address`` and ``subnet_mask`` of the ``network`` option instead. - -community.windows -~~~~~~~~~~~~~~~~~ - -- win_pester - no longer runs all ``*.ps1`` file in the directory specified due to it executing potentially unknown scripts. It will follow the default behaviour of only running tests for files that are like ``*.tests.ps1`` which is built into Pester itself. - -community.zabbix -~~~~~~~~~~~~~~~~ - -- zabbix_javagateway - options ``javagateway_pidfile``, ``javagateway_listenip``, ``javagateway_listenport`` and ``javagateway_startpollers`` renamed to ``zabbix_javagateway_xyz`` (see `UPGRADE.md `_). - -netbox.netbox -~~~~~~~~~~~~~ - -- Change ``ip-addresses`` key in netbox inventory plugin to ``ip_addresses`` (https://github.com/netbox-community/ansible_modules/issues/139) -- Changed ``group`` to ``tenant_group`` in ``netbox_tenant.py`` (https://github.com/netbox-community/ansible_modules/issues/9) -- Changed ``role`` to ``prefix_role`` in ``netbox_prefix.py`` (https://github.com/netbox-community/ansible_modules/issues/9) -- Module failures when required fields aren't provided (https://github.com/netbox-community/ansible_modules/issues/24) -- Renamed ``netbox_interface`` to ``netbox_device_interface`` (https://github.com/netbox-community/ansible_modules/issues/9) -- This version has a few breaking changes due to new namespace and collection name. I felt it necessary to change the name of the lookup plugin and inventory plugin just not to have a non descriptive namespace call to use them. Below is an example: - ``netbox.netbox.netbox`` would be used for both inventory plugin and lookup plugin, but in different contexts so no collision will arise, but confusion will. - I renamed the lookup plugin to ``nb_lookup`` so it will be used with the FQCN ``netbox.netbox.nb_lookup``. - The inventory plugin will now be called within an inventory file by ``netbox.netbox.nb_inventory`` -- To pass in integers through Ansible Jinja filters for a key in ``data`` that - requires querying an endpoint is now done by making it a dictionary with - an ``id`` key. The previous behavior was to just pass in an integer and - it was converted when normalizing the data, but some people may have names - that are all integers and those were being converted erroneously so we made - the decision to change the method to convert to an integer for the NetBox - API. - - :: - - tasks: - - name: Create device within NetBox with only required information - netbox_device: - netbox_url: http://netbox-demo.org:32768 - netbox_token: 0123456789abcdef0123456789abcdef01234567 - data: - name: Test66 - device_type: - id: "{{ some_jinja_variable }}" - device_role: Core Switch - site: Test Site - status: Staged - state: present -- ``pynetbox`` changed to using ``requests.Session()`` to manage the HTTP session - which broke passing in ``ssl_verify`` when building the NetBox API client. - This PR makes ``pynetbox 5.0.4+`` the new required version of `pynetbox` for - the Ansible modules and lookup plugin. (https://github.com/netbox-community/ansible_modules/pull/269) - -theforeman.foreman -~~~~~~~~~~~~~~~~~~ - -- All modules were renamed to drop the ``foreman_`` and ``katello_`` prefixes. - Additionally to the prefix removal, the following modules were further ranamed: - - * katello_upload to content_upload - * katello_sync to repository_sync - * katello_manifest to subscription_manifest - * foreman_search_facts to resource_info - * foreman_ptable to partition_table - * foreman_model to hardware_model - * foreman_environment to puppet_environment - -Major Changes -------------- - -Ansible-base -~~~~~~~~~~~~ - -- Both ansible-doc and ansible-console's help command will error for modules and plugins whose return documentation cannot be parsed as YAML. All modules and plugins passing ``ansible-test sanity --test yamllint`` will not be affected by this. -- Collections may declare a list of supported/tested Ansible versions for the collection. A warning is issued if a collection does not support the Ansible version that loads it (can also be configured as silent or a fatal error). Collections that do not declare supported Ansible versions do not issue a warning/error. -- Plugin routing allows collections to declare deprecation, redirection targets, and removals for all plugin types. -- Plugins that import module_utils and other ansible namespaces that have moved to collections should continue to work unmodified. -- Routing data built into Ansible 2.10 ensures that 2.9 content should work unmodified on 2.10. Formerly included modules and plugins that were moved to collections are still accessible by their original unqualified names, so long as their destination collections are installed. -- When deprecations are done in code, they to specify a ``collection_name`` so that deprecation warnings can mention which collection - or ansible-base - is deprecating a feature. This affects all ``Display.deprecated()`` or ``AnsibleModule.deprecate()`` or ``Ansible.Basic.Deprecate()`` calls, and ``removed_in_version``/``removed_at_date`` or ``deprecated_aliases`` in module argument specs. -- ansible-test now uses a different ``default`` test container for Ansible Collections - -amazon.aws -~~~~~~~~~~ - -- ec2 module_utils - The ``AWSRetry`` decorator no longer catches ``NotFound`` exceptions by default. ``NotFound`` exceptions need to be explicitly added using ``catch_extra_error_codes``. Some AWS modules may see an increase in transient failures due to AWS''s eventual consistency model. - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- Add libssh connection plugin and refactor network_cli (https://github.com/ansible-collections/ansible.netcommon/pull/30) - -ansible.posix -~~~~~~~~~~~~~ - -- Bootstrap Collection (https://github.com/ansible-collections/ansible.posix/pull/1). - -cisco.meraki -~~~~~~~~~~~~ - -- Rewrite requests method for version 1.0 API and improved readability -- meraki_mr_rf_profile - Configure wireless RF profiles. -- meraki_mr_settings - Configure network settings for wireless. -- meraki_ms_l3_interface - New module -- meraki_ms_ospf - Configure OSPF. - -community.general -~~~~~~~~~~~~~~~~~ - -- docker_container - the ``network_mode`` option will be set by default to the name of the first network in ``networks`` if at least one network is given and ``networks_cli_compatible`` is ``true`` (will be default from community.general 2.0.0 on). Set to an explicit value to avoid deprecation warnings if you specify networks and set ``networks_cli_compatible`` to ``true``. The current default (not specifying it) is equivalent to the value ``default``. -- docker_container - the module has a new option, ``container_default_behavior``, whose default value will change from ``compatibility`` to ``no_defaults``. Set to an explicit value to avoid deprecation warnings. -- gitlab_user - no longer requires ``name``, ``email`` and ``password`` arguments when ``state=absent``. - -community.grafana -~~~~~~~~~~~~~~~~~ - -- Add changelog management for ansible 2.10 (#112) -- grafana_datasource ; adding additional_json_data param - -community.kubernetes -~~~~~~~~~~~~~~~~~~~~ - -- Add changelog and fragments and document changelog process (https://github.com/ansible-collections/community.kubernetes/pull/131). -- helm - New module for managing Helm charts (https://github.com/ansible-collections/community.kubernetes/pull/61). -- helm_info - New module for retrieving Helm chart information (https://github.com/ansible-collections/community.kubernetes/pull/61). -- helm_plugin - new module to manage Helm plugins (https://github.com/ansible-collections/community.kubernetes/pull/154). -- helm_plugin_info - new modules to gather information about Helm plugins (https://github.com/ansible-collections/community.kubernetes/pull/154). -- helm_repository - New module for managing Helm repositories (https://github.com/ansible-collections/community.kubernetes/pull/61). -- k8s - Inventory source migrated from Ansible 2.9 to Kubernetes collection. -- k8s - Lookup plugin migrated from Ansible 2.9 to Kubernetes collection. -- k8s - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_auth - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_config_resource_name - Filter plugin migrated from Ansible 2.9 to Kubernetes collection. -- k8s_exec - New module for executing commands on pods through Kubernetes API (https://github.com/ansible-collections/community.kubernetes/pull/14). -- k8s_exec - Return rc for the command executed (https://github.com/ansible-collections/community.kubernetes/pull/158). -- k8s_info - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_log - New module for retrieving pod logs (https://github.com/ansible-collections/community.kubernetes/pull/16). -- k8s_scale - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_service - Module migrated from Ansible 2.9 to Kubernetes collection. -- kubectl - Connection plugin migrated from Ansible 2.9 to Kubernetes collection. -- openshift - Inventory source migrated from Ansible 2.9 to Kubernetes collection. - -community.libvirt -~~~~~~~~~~~~~~~~~ - -- added generic libvirt inventory plugin -- removed libvirt_lxc inventory script - -dellemc.os10 -~~~~~~~~~~~~ - -- New role os10_aaa - Facilitates the configuration of Authentication Authorization and Accounting (AAA), TACACS and RADIUS server. -- New role os10_acl - Facilitates the configuration of Access Control lists. -- New role os10_bfd - Facilitates the configuration of BFD global attributes. -- New role os10_bgp - Facilitates the configuration of border gateway protocol (BGP) attributes. -- New role os10_copy_config - This role pushes the backup running configuration into a OS10 device. -- New role os10_dns - Facilitates the configuration of domain name service (DNS). -- New role os10_ecmp - Facilitates the configuration of equal cost multi-path (ECMP) for IPv4. -- New role os10_fabric_summary Facilitates to get show system information of all the OS10 switches in the fabric. -- New role os10_flow_monitor Facilitates the configuration of ACL flow-based monitoring attributes. -- New role os10_image_upgrade Facilitates installation of OS10 software images. -- New role os10_interface Facilitates the configuration of interface attributes. -- New role os10_lag Facilitates the configuration of link aggregation group (LAG) attributes. -- New role os10_lldp Facilitates the configuration of link layer discovery protocol (LLDP) attributes at global and interface level. -- New role os10_logging Facilitates the configuration of global logging attributes and logging servers. -- New role os10_network_validation Facilitates validation of wiring connection, BGP neighbors, MTU between neighbors and VLT pair. -- New role os10_ntp Facilitates the configuration of network time protocol (NTP) attributes. -- New role os10_prefix_list Facilitates the configuration of IP prefix-list. -- New role os10_qos Facilitates the configuration of quality of service attributes including policy-map and class-map. -- New role os10_raguard Facilitates the configuration of IPv6 RA Guard attributes. -- New role os10_route_map Facilitates the configuration of route-map attributes. -- New role os10_snmp Facilitates the configuration of global SNMP attributes. -- New role os10_system Facilitates the configuration of hostname and hashing algorithm. -- New role os10_template The role takes the raw string input from the CLI of OS10 device, and returns a structured text in the form of a Python dictionary. -- New role os10_uplink Facilitates the configuration of uplink attributes like uplink-state group. -- New role os10_users Facilitates the configuration of global system user attributes. -- New role os10_vlan Facilitates the configuration of virtual LAN (VLAN) attributes. -- New role os10_vlt Facilitates the configuration of virtual link trunking (VLT). -- New role os10_vrf Facilitates the configuration of virtual routing and forwarding (VRF). -- New role os10_vrrp Facilitates the configuration of virtual router redundancy protocol (VRRP) attributes. -- New role os10_vxlan Facilitates the configuration of virtual extensible LAN (VXLAN) attributes. -- New role os10_xstp Facilitates the configuration of xSTP attributes. - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Broke apart bigip_device_auth_radius to implement radius server configuration in bigip_device_auth_server module. Refer to module documentation for usage details -- Remove redundant parameters in f5_provider to fix disparity between documentation and module parameters - -gluster.gluster -~~~~~~~~~~~~~~~ - -- geo_rep - Added the independent module of geo rep with other gluster modules (https://github.com/gluster/gluster-ansible-collection/pull/2). - -ovirt.ovirt -~~~~~~~~~~~ - -- ovirt_disk - Add backup (https://github.com/oVirt/ovirt-ansible-collection/pull/57). -- ovirt_disk - Support direct upload/download (https://github.com/oVirt/ovirt-ansible-collection/pull/35). -- ovirt_host - Add ssh_port (https://github.com/oVirt/ovirt-ansible-collection/pull/60). -- ovirt_vm_os_info - Creation of module (https://github.com/oVirt/ovirt-ansible-collection/pull/26). - -purestorage.flasharray -~~~~~~~~~~~~~~~~~~~~~~ - -- purefa_console - manage Console Lock setting for the FlashArray -- purefa_endpoint - manage VMware protocol-endpoints on the FlashArray -- purefa_eula - sign, or resign, FlashArray EULA -- purefa_inventory - get hardware inventory information from a FlashArray -- purefa_network - manage the physical and virtual network settings on the FlashArray -- purefa_pgsched - manage protection group snapshot and replication schedules on the FlashArray -- purefa_pod - manage ActiveCluster pods in FlashArrays -- purefa_pod_replica - manage ActiveDR pod replica links in FlashArrays -- purefa_proxy - manage the phonehome HTTPS proxy setting for the FlashArray -- purefa_smis - manage SMI-S settings on the FlashArray -- purefa_subnet - manage network subnets on the FlashArray -- purefa_timeout - manage the GUI idle timeout on the FlashArray -- purefa_vlan - manage VLAN interfaces on the FlashArray -- purefa_vnc - manage VNC for installed applications on the FlashArray -- purefa_volume_tags - manage volume tags on the FlashArray - -purestorage.flashblade -~~~~~~~~~~~~~~~~~~~~~~ - -- purefb_alert - manage alert email settings on a FlashBlade -- purefb_bladename - manage FlashBlade name -- purefb_bucket_replica - manage bucket replica links on a FlashBlade -- purefb_connect - manage connections between FlashBlades -- purefb_dns - manage DNS settings on a FlashBlade -- purefb_fs_replica - manage filesystem replica links on a FlashBlade -- purefb_inventory - get information about the hardware inventory of a FlashBlade -- purefb_ntp - manage the NTP settings for a FlashBlade -- purefb_phonehome - manage the phone home settings for a FlashBlade -- purefb_policy - manage the filesystem snapshot policies for a FlashBlade -- purefb_proxy - manage the phone home HTTP proxy settings for a FlashBlade -- purefb_remote_cred - manage the Object Store Remote Credentials on a FlashBlade -- purefb_snmp_agent - modify the FlashBlade SNMP Agent -- purefb_snmp_mgr - manage SNMP Managers on a FlashBlade -- purefb_target - manage remote S3-capable targets for a FlashBlade -- purefb_user - manage local ``pureuser`` account password on a FlashBlade - -Removed Features ----------------- - -Ansible-base -~~~~~~~~~~~~ - -- core - remove support for ``check_invalid_arguments`` in ``AnsibleModule``, ``AzureModule`` and ``UTMModule``. - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- module_utils.network.common.utils.ComplexDict has been removed - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_stat - removed the deprecated ``get_md55`` option and ``md5`` return value. - -community.crypto -~~~~~~~~~~~~~~~~ - -- The ``letsencrypt`` module has been removed. Use ``acme_certificate`` instead. - -community.general -~~~~~~~~~~~~~~~~~ - -- conjur_variable lookup - has been moved to the ``cyberark.conjur`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/570). -- core - remove support for ``check_invalid_arguments`` in ``UTMModule``. -- digital_ocean_* - all DigitalOcean modules have been moved to the ``community.digitalocean`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/622). -- infini_* - all infinidat modules have been moved to the ``infinidat.infinibox`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/607). -- logicmonitor - the module has been removed in 1.0.0 since it is unmaintained and the API used by the module has been turned off in 2017 (https://github.com/ansible-collections/community.general/issues/539, https://github.com/ansible-collections/community.general/pull/541). -- logicmonitor_facts - the module has been removed in 1.0.0 since it is unmaintained and the API used by the module has been turned off in 2017 (https://github.com/ansible-collections/community.general/issues/539, https://github.com/ansible-collections/community.general/pull/541). -- mysql_* - all MySQL modules have been moved to the ``community.mysql`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/633). -- pacman - Removed deprecated ``recurse`` option, use ``extra_args=--recursive`` instead -- proxysql_* - all ProxySQL modules have been moved to the ``community.proxysql`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/624). - -community.network -~~~~~~~~~~~~~~~~~ - -- onyx - all onyx modules and plugins have been moved to the mellanox.onyx collection. Redirects have been added that will be removed in community.network 2.0.0 (https://github.com/ansible-collections/community.network/pull/83). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_guest_find - Removed deprecated ``datacenter`` option -- vmware_portgroup - removed 'inbound_policy', and 'rolling_order' deprecated options. -- vmware_vmkernel - Removed deprecated ``ip_address`` option; use sub-option ip_address in the network option instead -- vmware_vmkernel - Removed deprecated ``subnet_mask`` option; use sub-option subnet_mask in the network option instead - -community.windows -~~~~~~~~~~~~~~~~~ - -- win_disk_image - removed the deprecated return value ``mount_path`` in favor of ``mount_paths``. -- win_psexec - removed the deprecated ``extra_opts`` option. - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Remove _bigip_iapplx_package alias -- Remove _bigip_security_address_list alias -- Remove _bigip_security_port_list alias -- Remove _bigip_traffic_group alias -- Remove bigip_appsvcs_extension module -- Remove bigip_asm_policy module - -Deprecated Features -------------------- - -- The vyos.vyos.vyos_static_route module has been deprecated and will be removed in a later release; use vyos.vyos.vyos_static_routes instead. - -Ansible-base -~~~~~~~~~~~~ - -- Using the DefaultCallback without the correspodning doc_fragment or copying the documentation. -- hash_behaviour - Deprecate ``hash_behaviour`` for future removal. -- script inventory plugin - The 'cache' option is deprecated and will be removed in 2.12. Its use has been removed from the plugin since it has never had any effect. - -amazon.aws -~~~~~~~~~~ - -- All AWS Modules - ``aws_access_key``, ``aws_secret_key`` and ``security_token`` will be made mutually exclusive with ``profile`` after 2022-06-01. -- cloudformation - The ``template_format`` option had no effect since Ansible 2.3 and will be removed after 2022-06-01 -- cloudformation - the ``template_format`` option has been deprecated and will be removed in a later release. It has been ignored by the module since Ansible 2.3. -- data_pipeline - The ``version`` option had no effect and will be removed in after 2022-06-01 -- ec2 - in a later release, the ``group`` and ``group_id`` options will become mutually exclusive. Currently ``group_id`` is ignored if you pass both. -- ec2_ami - The ``no_device`` alias ``NoDevice`` has been deprecated and will be removed after 2022-06-01 -- ec2_ami - The ``virtual_name`` alias ``VirtualName`` has been deprecated and will be removed after 2022-06-01 -- ec2_eip - The ``wait_timeout`` option had no effect and will be removed after 2022-06-01 -- ec2_key - The ``wait_timeout`` option had no effect and will be removed after 2022-06-01 -- ec2_key - The ``wait`` option had no effect and will be removed after 2022-06-01 -- ec2_key - the ``wait_timeout`` option has been deprecated and will be removed in a later release. It has had no effect since Ansible 2.5. -- ec2_key - the ``wait`` option has been deprecated and will be removed in a later release. It has had no effect since Ansible 2.5. -- ec2_lc - The ``associate_public_ip_address`` option had no effect and will be removed after 2022-06-01 -- ec2_tag - deprecate the ``list`` option in favor of ec2_tag_info -- ec2_tag - support for ``list`` as a state has been deprecated and will be removed in a later release. The ``ec2_tag_info`` can be used to fetch the tags on an EC2 resource. - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_domain_computer - Deprecated the undocumented ``log_path`` option. This option will be removed in a major release after ``2022-07-01``. -- win_domain_controller - the ``log_path`` option has been deprecated and will be removed in a later release. This was undocumented and only related to debugging information for module development. -- win_package - the ``ensure`` alias for the ``state`` option has been deprecated and will be removed in a later release. Please use ``state`` instead of ``ensure``. -- win_package - the ``productid`` alias for the ``product_id`` option has been deprecated and will be removed in a later release. Please use ``product_id`` instead of ``productid``. -- win_package - the ``username`` and ``password`` options has been deprecated and will be removed in a later release. The same functionality can be done by using ``become: yes`` and ``become_flags: logon_type=new_credentials logon_flags=netcredentials_only`` on the task. -- win_regedit - Deprecated using forward slashes as a path separator, use backslashes to avoid ambiguity between a forward slash in the key name or a forward slash as a path separator. This feature will be removed in a major release after ``2021-07-01``. - -community.aws -~~~~~~~~~~~~~ - -- cloudformation - The ``template_format`` option had no effect since Ansible 2.3 and will be removed after 2022-06-01 -- data_pipeline - The ``version`` option had no effect and will be removed after 2022-06-01 -- data_pipeline - the ``version`` option has been deprecated and will be removed in a later release. It has always been ignored by the module. -- ec2_eip - The ``wait_timeout`` option had no effect and will be removed after 2022-06-01 -- ec2_eip - the ``wait_timeout`` option has been deprecated and will be removed in a later release. It has had no effect since Ansible 2.3. -- ec2_key - The ``wait_timeout`` option had no effect and will be removed after 2022-06-01 -- ec2_key - The ``wait`` option had no effect and will be removed after 2022-06-01 -- ec2_lc - The ``associate_public_ip_address`` option had no effect and will be removed after 2022-06-01 -- ec2_lc - the ``associate_public_ip_address`` option has been deprecated and will be removed after a later release. It has always been ignored by the module. -- elb_network_lb - The current default value of the ``state`` option has been deprecated and will change from absent to present after 2022-06-01 -- elb_network_lb - in a later release, the default behaviour for the ``state`` option will change from ``absent`` to ``present``. To maintain the existing behavior explicitly set state to ``absent``. -- iam_managed_policy - The ``fail_on_delete`` option had no effect and will be removed after 2022-06-01 -- iam_managed_policy - the ``fail_on_delete`` option has been deprecated and will be removed after a later release. It has always been ignored by the module. -- iam_policy - The ``policy_document`` will be removed after 2022-06-01. To maintain the existing behavior use the ``policy_json`` option and read the file with the ``lookup`` plugin. -- iam_policy - The default value of ``skip_duplicates`` will change after 2022-06-01 from ``true`` to ``false``. -- iam_policy - in a later release, the default value for the ``skip_duplicates`` option will change from ``true`` to ``false``. To maintain the existing behavior explicitly set it to ``true``. -- iam_policy - the ``policy_document`` option has been deprecated and will be removed after a later release. To maintain the existing behavior use the ``policy_json`` option and read the file with the ``lookup`` plugin. -- iam_role - The default value of the purge_policies has been deprecated and will change from true to false after 2022-06-01 -- iam_role - in a later release, the ``purge_policies`` option (also know as ``purge_policy``) default value will change from ``true`` to ``false`` -- s3_lifecycle - The ``requester_pays`` option had no effect and will be removed after 2022-06-01 -- s3_lifecycle - the ``requester_pays`` option has been deprecated and will be removed after a later release. It has always been ignored by the module. -- s3_sync - The ``retries`` option had no effect and will be removed after 2022-06-01 -- s3_sync - the ``retries`` option has been deprecated and will be removed after 2022-06-01. It has always been ignored by the module. - -community.crypto -~~~~~~~~~~~~~~~~ - -- openssl_csr - all values for the ``version`` option except ``1`` are deprecated. The value 1 denotes the current only standardized CSR version. - -community.general -~~~~~~~~~~~~~~~~~ - -- The ldap_attr module has been deprecated and will be removed in a later release; use ldap_attrs instead. -- airbrake_deployment - Add deprecation notice for ``token`` parameter and v2 api deploys. This feature will be removed in community.general 3.0.0. -- clc_aa_policy - The ``wait`` option had no effect and will be removed in community.general 3.0.0. -- clc_aa_policy - the ``wait`` parameter will be removed. It has always been ignored by the module. -- docker_container - the ``trust_image_content`` option is now deprecated and will be removed in community.general 3.0.0. It has never been used by the module. -- docker_container - the ``trust_image_content`` option will be removed. It has always been ignored by the module. -- docker_container - the default of ``container_default_behavior`` will change from ``compatibility`` to ``no_defaults`` in community.general 3.0.0. Set the option to an explicit value to avoid a deprecation warning. -- docker_container - the default value for ``network_mode`` will change in community.general 3.0.0, provided at least one network is specified and ``networks_cli_compatible`` is ``true``. See porting guide, module documentation or deprecation warning for more details. -- docker_stack - Return values ``out`` and ``err`` have been deprecated and will be removed in community.general 3.0.0. Use ``stdout`` and ``stderr`` instead. -- docker_stack - the return values ``err`` and ``out`` have been deprecated. Use ``stdout`` and ``stderr`` from now on instead. -- helm - Put ``helm`` module to deprecated. New implementation is available in community.kubernetes collection. -- redfish_config - Deprecate ``bios_attribute_name`` and ``bios_attribute_value`` in favor of new `bios_attributes`` option. -- redfish_config - the ``bios_attribute_name`` and ``bios_attribute_value`` options will be removed. To maintain the existing behavior use the ``bios_attributes`` option instead. -- redfish_config and redfish_command - the behavior to select the first System, Manager, or Chassis resource to modify when multiple are present will be removed. Use the new ``resource_id`` option to specify target resource to modify. -- redfish_config, redfish_command - Behavior to modify the first System, Manager, or Chassis resource when multiple are present is deprecated. Use the new ``resource_id`` option to specify target resource to modify. -- xbps - the ``force`` option never had any effect. It is now deprecated, and will be removed in 3.0.0 (https://github.com/ansible-collections/community.general/pull/568). - -community.vmware -~~~~~~~~~~~~~~~~ - -- The vmware_dns_config module has been deprecated and will be removed in a later release; use vmware_host_dns instead. -- vca - vca_fw, vca_nat, vca_app are deprecated since these modules rely on deprecated part of Pyvcloud library. -- vmware_dns_config - Deprecate in favor of new module vmware_host_dns. -- vmware_guest - deprecate specifying CDROM configuration as a dict, instead use a list. -- vmware_tag_info - in a later release, the module will not return ``tag_facts`` since it does not return multiple tags with the same name and different category id. To maintain the existing behavior use ``tag_info`` which is a list of tag metadata. - -community.zabbix -~~~~~~~~~~~~~~~~ - -- zabbix_proxy (module) - deprecates ``interface`` sub-options ``type`` and ``main`` when proxy type is set to passive through ``status=passive``. Make sure these suboptions are removed from your playbook as they were never supported by Zabbix in the first place. - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Deprecated bigip_appsvcs_extension module -- Deprecated bigip_device_facts module name -- Deprecated bigiq_device_facts module name diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.3.rst b/docs/docsite/rst/porting_guides/porting_guide_2.3.rst deleted file mode 100644 index 9a66c23d0f1..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.3.rst +++ /dev/null @@ -1,233 +0,0 @@ - -.. _porting_2.3_guide: - -************************* -Ansible 2.3 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.2 and Ansible 2.3. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - - -We suggest you read this page along with `Ansible Changelog for 2.3 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - -Playbook -======== - -Restructured async to work with action plugins ----------------------------------------------- - -In Ansible 2.2 (and possibly earlier) the `async:` keyword could not be used in conjunction with the action plugins such as `service`. This limitation has been removed in Ansible 2.3 - -**NEW** In Ansible 2.3: - - -.. code-block:: yaml - - - name: Install nginx asynchronously - service: - name: nginx - state: restarted - async: 45 - - -OpenBSD version facts ---------------------- - -The `ansible_distribution_release` and `ansible_distribution_version` facts on OpenBSD hosts were reversed in Ansible 2.2 and earlier. This has been changed so that version has the numeric portion and release has the name of the release. - -**OLD** In Ansible 2.2 (and earlier) - - -.. code-block:: bash - - "ansible_distribution": "OpenBSD" - "ansible_distribution_release": "6.0", - "ansible_distribution_version": "release", - -**NEW** In Ansible 2.3: - - -.. code-block:: bash - - "ansible_distribution": "OpenBSD", - "ansible_distribution_release": "release", - "ansible_distribution_version": "6.0", - - -Names Blocks ------------- - -Blocks can now have names, this allows you to avoid the ugly `# this block is for...` comments. - - -**NEW** In Ansible 2.3: - - -.. code-block:: yaml - - - name: Block test case - hosts: localhost - tasks: - - name: Attempt to setup foo - block: - - debug: msg='I execute normally' - - command: /bin/false - - debug: msg='I never execute, cause ERROR!' - rescue: - - debug: msg='I caught an error' - - command: /bin/false - - debug: msg='I also never execute :-(' - always: - - debug: msg="this always executes" - - -Use of multiple tags --------------------- - -Specifying ``--tags`` (or ``--skip-tags``) multiple times on the command line currently leads to the last specified tag overriding all the other specified tags. This behaviour is deprecated. In the future, if you specify --tags multiple times the tags will be merged together. From now on, using ``--tags`` multiple times on one command line will emit a deprecation warning. Setting the ``merge_multiple_cli_tags`` option to True in the ``ansible.cfg`` file will enable the new behaviour. - -In 2.4, the default will be to merge the tags. You can enable the old overwriting behavior through the config option. -In 2.5, multiple ``--tags`` options will be merged with no way to go back to the old behaviour. - - -Other caveats -------------- - -Here are some rare cases that might be encountered when updating. These are mostly caused by the more stringent parser validation and the capture of errors that were previously ignored. - - -* Made ``any_errors_fatal`` inheritable from play to task and all other objects in between. - -Modules -======= - -No major changes in this version. - -Modules removed ---------------- - -No major changes in this version. - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.5. Please update your playbooks accordingly. - -* ec2_vpc -* cl_bond -* cl_bridge -* cl_img_install -* cl_interface -* cl_interface_policy -* cl_license -* cl_ports -* nxos_mtu use :ref:`nxos_system ` instead - -.. note:: - - These modules may no longer have documentation in the current release. Please see the - `Ansible 2.3 module documentation - `_ if you need - to know how they worked for porting your playbooks. - - -Noteworthy module changes -------------------------- - -AWS lambda -^^^^^^^^^^ -Previously ignored changes that only affected one parameter. Existing deployments may have outstanding changes that this bug fix will apply. - - -Mount -^^^^^ - -Mount: Some fixes so bind mounts are not mounted each time the playbook runs. - - -Plugins -======= - -No major changes in this version. - -Porting custom scripts -====================== - -No major changes in this version. - -Networking -========== - -There have been a number of changes to number of changes to how Networking Modules operate. - -Playbooks should still use ``connection: local``. - -The following changes apply to: - -* dellos6 -* dellos9 -* dellos10 -* eos -* ios -* iosxr -* junos -* sros -* vyos - -Deprecation of top-level connection arguments ---------------------------------------------- - -**OLD** In Ansible 2.2: - -.. code-block:: yaml - - - name: example of using top-level options for connection properties - ios_command: - commands: show version - host: "{{ inventory_hostname }}" - username: cisco - password: cisco - authorize: yes - auth_pass: cisco - -Will result in: - -.. code-block:: bash - - [WARNING]: argument username has been deprecated and will be removed in a future version - [WARNING]: argument host has been deprecated and will be removed in a future version - [WARNING]: argument password has been deprecated and will be removed in a future version - - -**NEW** In Ansible 2.3: - - -.. code-block:: yaml - - - name: Gather facts - eos_facts: - gather_subset: all - provider: - username: myuser - password: "{{ networkpassword }}" - transport: cli - host: "{{ ansible_host }}" - -ProxyCommand replaces delegate_to ---------------------------------- - -The new connection framework for Network Modules in Ansible 2.3 that uses ``cli`` transport -no longer supports the use of the ``delegate_to`` directive. -In order to use a bastion or intermediate jump host to connect to network devices over ``cli`` -transport, network modules now support the use of ``ProxyCommand``. - -To use ``ProxyCommand`` configure the proxy settings in the Ansible inventory -file to specify the proxy host through ``ansible_ssh_common_args``. - -For details on how to do this see the :ref:`network proxy guide `. diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.4.rst b/docs/docsite/rst/porting_guides/porting_guide_2.4.rst deleted file mode 100644 index d58ae48d138..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.4.rst +++ /dev/null @@ -1,227 +0,0 @@ - -.. _porting_2.4_guide: - -************************* -Ansible 2.4 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.3 and Ansible 2.4. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - - -We suggest you read this page along with `Ansible Changelog for 2.4 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - -Python version -============== - -Ansible will not support Python 2.4 or 2.5 on the target hosts anymore. Going forward, Python 2.6+ will be required on targets, as already is the case on the controller. - - -Inventory -========= - -Inventory has been refactored to be implemented through plugins and now allows for multiple sources. This change is mostly transparent to users. - -One exception is the ``inventory_dir``, which is now a host variable; previously it could only have one value so it was set globally. -This means you can no longer use it early in plays to determine ``hosts:`` or similar keywords. -This also changes the behaviour of ``add_hosts`` and the implicit localhost; -because they no longer automatically inherit the global value, they default to ``None``. See the module documentation for more information. - -The ``inventory_file`` remains mostly unchanged, as it was always host specific. - -Since there is no longer a single inventory, the 'implicit localhost' doesn't get either of these variables defined. - -A bug was fixed with the inventory path/directory, which was defaulting to the current working directory. This caused ``group_vars`` and ``host_vars`` to be picked up from the current working directory instead of just adjacent to the playbook or inventory directory when a host list (comma separated host names) was provided as inventory. - -Initial playbook relative group_vars and host_vars --------------------------------------------------- - -In Ansible versions prior to 2.4, the inventory system would maintain the context of the initial playbook that was executed. This allowed successively included playbooks from other directories to inherit group_vars and host_vars placed relative to the top level playbook file. - -Due to some behavioral inconsistencies, this functionality will not be included in the new -inventory system starting with Ansible version 2.4. - -Similar functionality can still be achieved by using vars_files, include_vars, or group_vars and host_vars placed relative to the inventory file. - -Deprecated -========== - -Specifying Inventory sources ------------------------------ - -Use of ``--inventory-file`` on the command line is now deprecated. Use ``--inventory`` or ``-i``. -The associated ini configuration key, ``hostfile``, and environment variable, ``ANSIBLE_HOSTS``, -are also deprecated. Replace them with the configuration key ``inventory`` and environment variable :envvar:`ANSIBLE_INVENTORY`. - -Use of multiple tags --------------------- - -Specifying ``--tags`` (or ``--skip-tags``) multiple times on the command line currently leads to the last one overriding all the previous ones. This behavior is deprecated. In the future, if you specify --tags multiple times the tags will be merged together. From now on, using ``--tags`` multiple times on one command line will emit a deprecation warning. Setting the ``merge_multiple_cli_tags`` option to True in the ``ansible.cfg`` file will enable the new behavior. - -In 2.4, the default has change to merge the tags. You can enable the old overwriting behavior through the config option. - -In 2.5, multiple ``--tags`` options will be merged with no way to go back to the old behavior. - - -Other caveats -------------- - -No major changes in this version. - -Modules -======= - -Major changes in popular modules are detailed here - -* The :ref:`win_shell ` and :ref:`win_command ` modules now properly preserve quoted arguments in the command-line. Tasks that attempted to work around the issue by adding extra quotes/escaping may need to be reworked to remove the superfluous escaping. See `Issue 23019 `_ for additional detail. - -Modules removed ---------------- - -The following modules no longer exist: - -* None - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.8. Please update your playbooks accordingly. - -* azure, use :ref:`azure_rm_virtualmachine `, which uses the new Resource Manager SDK. -* win_msi, use :ref:`win_package ` instead - -Noteworthy module changes -------------------------- - -* The :ref:`win_get_url ` module has the dictionary ``win_get_url`` in its results deprecated, its content is now also available directly in the resulting output, like other modules. This dictionary will be removed in Ansible 2.8. -* The :ref:`win_unzip ` module no longer includes the dictionary ``win_unzip`` in its results; the contents are now included directly in the resulting output, like other modules. -* The :ref:`win_package ` module return values ``exit_code`` and ``restart_required`` have been deprecated in favor of ``rc`` and ``reboot_required`` respectively. The deprecated return values will be removed in Ansible 2.6. - - -Plugins -======= - -A new way to configure and document plugins has been introduced. This does not require changes to existing setups but developers should start adapting to the new infrastructure now. More details will be available in the developer documentation for each plugin type. - -Vars plugin changes -------------------- - -There have been many changes to the implementation of vars plugins, but both users and developers should not need to change anything to keep current setups working. Developers should consider changing their plugins take advantage of new features. - -The most notable difference to users is that vars plugins now get invoked on demand instead of at inventory build time. This should make them more efficient for large inventories, especially when using a subset of the hosts. - - -.. note:: - - This also creates a difference with group/host_vars when using them adjacent to playbooks. Before, the 'first' playbook loaded determined the variables; now the 'current' playbook does. We are looking to fix this soon, since 'all playbooks' in the path should be considered for variable loading. - - In 2.4.1 we added a toggle to allow you to control this behaviour, 'top' will be the pre 2.4, 'bottom' will use the current playbook hosting the task and 'all' will use them all from top to bottom. - - -Inventory plugins ------------------ - -Developers should start migrating from hardcoded inventory with dynamic inventory scripts to the new Inventory Plugins. The scripts will still work through the ``script`` inventory plugin but Ansible development efforts will now concentrate on writing plugins rather than enhancing existing scripts. - -Both users and developers should look into the new plugins because they are intended to alleviate the need for many of the hacks and workarounds found in the dynamic inventory scripts. - -Callback plugins ----------------- - -Users: - -* Callbacks are now using the new configuration system. Users should not need to change anything as the old system still works, - but you might see a deprecation notice if any callbacks used are not inheriting from the built in classes. Developers need to update them as stated below. - -Developers: - -* If your callback does not inherit from ``CallbackBase`` (directly or indirectly through another callback), it will still work, but issue a deprecation notice. - To avoid this and ensure it works in the future change it to inherit from ``CallbackBase`` so it has the new options handling methods and properties. - You can also implement the new options handling methods and properties but that won't automatically inherit changes added in the future. You can look at ``CallbackBase`` itself and/or ``AnsiblePlugin`` for details. -* Any callbacks inheriting from other callbacks might need to also be updated to contain the same documented options - as the parent or the options won't be available. This is noted in the developer guide. - -Template lookup plugin: Escaping Strings ----------------------------------------- - -Prior to Ansible 2.4, backslashes in strings passed to the template lookup plugin would be escaped -automatically. In 2.4, users are responsible for escaping backslashes themselves. This change -brings the template lookup plugin inline with the template module so that the same backslash -escaping rules apply to both. - -If you have a template lookup like this:: - - - debug: - msg: '{{ lookup("template", "template.j2") }}' - -**OLD** In Ansible 2.3 (and earlier) :file:`template.j2` would look like this: - -.. code-block:: jinja - - {{ "name surname" | regex_replace("^[^\s]+\s+(.*)", "\1") }} - -**NEW** In Ansible 2.4 it should be changed to look like this: - -.. code-block:: jinja - - {{ "name surname" | regex_replace("^[^\\s]+\\s+(.*)", "\\1") }} - -Tests -===== - -Tests succeeded/failed ------------------------ - -Prior to Ansible version 2.4, a task return code of ``rc`` would override a return code of ``failed``. In version 2.4, both ``rc`` and ``failed`` are used to calculate the state of the task. Because of this, test plugins ``succeeded``/``failed``` have also been changed. This means that overriding a task failure with ``failed_when: no`` will result in ``succeeded``/``failed`` returning ``True``/``False``. For example:: - - - command: /bin/false - register: result - failed_when: no - - - debug: - msg: 'This is printed on 2.3' - when: result|failed - - - debug: - msg: 'This is printed on 2.4' - when: result|succeeded - - - debug: - msg: 'This is always printed' - when: result.rc != 0 - -As we can see from the example above, in Ansible 2.3 ``succeeded``/``failed`` only checked the value of ``rc``. - -Networking -========== - -There have been a number of changes to how Networking Modules operate. - -Playbooks should still use ``connection: local``. - -Persistent Connection ---------------------- - -The configuration variables ``connection_retries`` and ``connect_interval`` which were added in Ansible 2.3 are now deprecated. For Ansible 2.4 and later use ``connection_retry_timeout``. - -To control timeouts use ``command_timeout`` rather than the previous top level ``timeout`` variable under ``[default]`` - -See :ref:`Ansible Network debug guide ` for more information. - - -Configuration -============= - - -The configuration system has had some major changes. Users should be unaffected except for the following: - -* All relative paths defined are relative to the `ansible.cfg` file itself. Previously they varied by setting. The new behavior should be more predictable. -* A new macro ``{{CWD}}`` is available for paths, which will make paths relative to the 'current working directory', - this is unsafe but some users really want to rely on this behaviour. - -Developers that were working directly with the previous API should revisit their usage as some methods (for example, ``get_config``) were kept for backwards compatibility but will warn users that the function has been deprecated. - -The new configuration has been designed to minimize the need for code changes in core for new plugins. The plugins just need to document their settings and the configuration system will use the documentation to provide what they need. This is still a work in progress; currently only 'callback' and 'connection' plugins support this. More details will be added to the specific plugin developer guides. diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.5.rst b/docs/docsite/rst/porting_guides/porting_guide_2.5.rst deleted file mode 100644 index 7a58229d35b..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.5.rst +++ /dev/null @@ -1,392 +0,0 @@ -.. _porting_2.5_guide: - -************************* -Ansible 2.5 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.4 and Ansible 2.5. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `Ansible Changelog for 2.5 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - -Playbook -======== - -Dynamic includes and attribute inheritance ------------------------------------------- - -In Ansible version 2.4, the concept of dynamic includes (``include_tasks``), as opposed to static imports (``import_tasks``), was introduced to clearly define the differences in how ``include`` works between dynamic and static includes. - -All attributes applied to a dynamic ``include_*`` would only apply to the include itself, while attributes applied to a -static ``import_*`` would be inherited by the tasks within. - -This separation was only partially implemented in Ansible version 2.4. As of Ansible version 2.5, this work is complete and the separation now behaves as designed; attributes applied to an ``include_*`` task will not be inherited by the tasks within. - -To achieve an outcome similar to how Ansible worked prior to version 2.5, playbooks should use an explicit application of the attribute on the needed tasks, or use blocks to apply the attribute to many tasks. Another option is to use a static ``import_*`` when possible instead of a dynamic task. - -**OLD** In Ansible 2.4: - -.. code-block:: yaml - - - include_tasks: "{{ ansible_distribution }}.yml" - tags: - - distro_include - -Included file: - -.. code-block:: yaml - - - block: - - debug: - msg: "In included file" - - - apt: - name: nginx - state: latest - -**NEW** In Ansible 2.5: - -Including task: - -.. code-block:: yaml - - - include_tasks: "{{ ansible_distribution }}.yml" - tags: - - distro_include - -Included file: - -.. code-block:: yaml - - - block: - - debug: - msg: "In included file" - - - apt: - name: nginx - state: latest - tags: - - distro_include - -The relevant change in those examples is, that in Ansible 2.5, the included file defines the tag ``distro_include`` again. The tag is not inherited automatically. - -Fixed handling of keywords and inline variables ------------------------------------------------ - -We made several fixes to how we handle keywords and 'inline variables', to avoid conflating the two. Unfortunately these changes mean you must specify whether `name` is a keyword or a variable when calling roles. If you have playbooks that look like this:: - - roles: - - { role: myrole, name: Justin, othervar: othervalue, become: True} - -You will run into errors because Ansible reads name in this context as a keyword. Beginning in 2.5, if you want to use a variable name that is also a keyword, you must explicitly declare it as a variable for the role:: - - roles: - - { role: myrole, vars: {name: Justin, othervar: othervalue}, become: True} - - -For a full list of keywords see :ref:`playbook_keywords`. - -Migrating from with_X to loop ------------------------------ - -.. include:: ../playbook_guide/shared_snippets/with2loop.txt - - -Deprecated -========== - -Jinja tests used as filters ---------------------------- - -Using Ansible-provided jinja tests as filters will be removed in Ansible 2.9. - -Prior to Ansible 2.5, jinja tests included within Ansible were most often used as filters. The large difference in use is that filters are referenced as ``variable | filter_name`` while jinja tests are referenced as ``variable is test_name``. - -Jinja tests are used for comparisons, while filters are used for data manipulation and have different applications in jinja. This change is to help differentiate the concepts for a better understanding of jinja, and where each can be appropriately used. - -As of Ansible 2.5, using an Ansible provided jinja test with filter syntax, will display a deprecation error. - -**OLD** In Ansible 2.4 (and earlier) the use of an Ansible included jinja test would likely look like this: - -.. code-block:: yaml - - when: - - result | failed - - not result | success - -**NEW** In Ansible 2.5 it should be changed to look like this: - -.. code-block:: yaml - - when: - - result is failed - - results is not successful - -In addition to the deprecation warnings, many new tests have been introduced that are aliases of the old tests. These new tests make more sense grammatically with the jinja test syntax, such as the new ``successful`` test which aliases ``success``. - -.. code-block:: yaml - - when: result is successful - -See :ref:`playbooks_tests` for more information. - -Additionally, a script was created to assist in the conversion for tests using filter syntax to proper jinja test syntax. This script has been used to convert all of the Ansible integration tests to the correct format. There are a few limitations documented, and all changes made by this script should be evaluated for correctness before executing the modified playbooks. The script can be found at `https://github.com/ansible/ansible/blob/devel/hacking/fix_test_syntax.py `_. - -Ansible fact namespacing ------------------------- - -Ansible facts, which have historically been written to names like ``ansible_*`` -in the main facts namespace, have been placed in their own new namespace, -``ansible_facts.*`` For example, the fact ``ansible_distribution`` is now best -queried through the variable structure ``ansible_facts.distribution``. - -A new configuration variable, ``inject_facts_as_vars``, has been added to -ansible.cfg. Its default setting, 'True', keeps the 2.4 behavior of facts -variables being set in the old ``ansible_*`` locations (while also writing them -to the new namespace). This variable is expected to be set to 'False' in a -future release. When ``inject_facts_as_vars`` is set to False, you must -refer to ansible_facts through the new ``ansible_facts.*`` namespace. - -Modules -======= - -Major changes in popular modules are detailed here. - -github_release --------------- - -In Ansible versions 2.4 and older, after creating a GitHub release using the ``create_release`` state, the ``github_release`` module reported state as ``skipped``. -In Ansible version 2.5 and later, after creating a GitHub release using the ``create_release`` state, the ``github_release`` module now reports state as ``changed``. - - -Modules removed ---------------- - -The following modules no longer exist: - -* nxos_mtu use :ref:`nxos_system `'s ``system_mtu`` option or :ref:`nxos_interface ` instead -* cl_interface_policy use :ref:`nclu ` instead -* cl_bridge use :ref:`nclu ` instead -* cl_img_install use :ref:`nclu ` instead -* cl_ports use :ref:`nclu ` instead -* cl_license use :ref:`nclu ` instead -* cl_interface use :ref:`nclu ` instead -* cl_bond use :ref:`nclu ` instead -* ec2_vpc use :ref:`ec2_vpc_net ` along with supporting modules :ref:`ec2_vpc_igw `, :ref:`ec2_vpc_route_table `, :ref:`ec2_vpc_subnet `, :ref:`ec2_vpc_dhcp_option `, :ref:`ec2_vpc_nat_gateway `, :ref:`ec2_vpc_nacl ` instead. -* ec2_ami_search use :ref:`ec2_ami_facts ` instead -* docker use :ref:`docker_container ` and :ref:`docker_image ` instead - -.. note:: - - These modules may no longer have documentation in the current release. Please see the - `Ansible 2.4 module documentation - `_ if you need - to know how they worked for porting your playbooks. - - - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.9. Please update your playbooks accordingly. - -* Apstra's ``aos_*`` modules are deprecated as they do not work with AOS 2.1 or higher. See new modules at `https://github.com/apstra `_. -* nxos_ip_interface use :ref:`nxos_l3_interface ` instead. -* nxos_portchannel use :ref:`nxos_linkagg ` instead. -* nxos_switchport use :ref:`nxos_l2_interface ` instead. -* panos_security_policy use :ref:`panos_security_rule ` instead. -* panos_nat_policy use :ref:`panos_nat_rule ` instead. -* vsphere_guest use :ref:`vmware_guest ` instead. - -Noteworthy module changes -------------------------- - -* The :ref:`stat ` and :ref:`win_stat ` modules have changed the default of the option ``get_md5`` from ``true`` to ``false``. - -This option will be removed starting with Ansible version 2.9. The options ``get_checksum: True`` -and ``checksum_algorithm: md5`` can still be used if an MD5 checksum is -desired. - -* ``osx_say`` module was renamed into :ref:`say `. -* Several modules which could deal with symlinks had the default value of their ``follow`` option - changed as part of a feature to `standardize the behavior of follow - `_: - - * The :ref:`file module ` changed from ``follow=False`` to ``follow=True`` because - its purpose is to modify the attributes of a file and most systems do not allow attributes to be - applied to symlinks, only to real files. - * The :ref:`replace module ` had its ``follow`` parameter removed because it - inherently modifies the content of an existing file so it makes no sense to operate on the link - itself. - * The :ref:`blockinfile module ` had its ``follow`` parameter removed because - it inherently modifies the content of an existing file so it makes no sense to operate on the - link itself. - * In Ansible-2.5.3, the :ref:`template module ` became more strict about its - ``src`` file being proper utf-8. Previously, non-utf8 contents in a template module src file - would result in a mangled output file (the non-utf8 characters would be replaced with a unicode - replacement character). Now, on Python2, the module will error out with the message, "Template - source files must be utf-8 encoded". On Python3, the module will first attempt to pass the - non-utf8 characters through verbatim and fail if that does not succeed. - -Plugins -======= - -As a developer, you can now use 'doc fragments' for common configuration options on plugin types that support the new plugin configuration system. - -Inventory ---------- - -Inventory plugins have been fine tuned, and we have started to add some common features: - -* The ability to use a cache plugin to avoid costly API/DB queries is disabled by default. - If using inventory scripts, some may already support a cache, but it is outside of Ansible's knowledge and control. - Moving to the internal cache will allow you to use Ansible's existing cache refresh/invalidation mechanisms. - -* A new 'auto' plugin, enabled by default, that can automatically detect the correct plugin to use IF that plugin is using our 'common YAML configuration format'. - The previous host_list, script, yaml and ini plugins still work as they did, the auto plugin is now the last one we attempt to use. - If you had customized the enabled plugins you should revise the setting to include the new auto plugin. - -Shell ------ - -Shell plugins have been migrated to the new plugin configuration framework. It is now possible to customize more settings, and settings which were previously 'global' can now also be overridden using host specific variables. - -For example, ``system_temps`` is a new setting that allows you to control what Ansible will consider a 'system temporary dir'. This is used when escalating privileges for a non-administrative user. Previously this was hardcoded to '/tmp', which some systems cannot use for privilege escalation. This setting now defaults to ``[ '/var/tmp', '/tmp']``. - -Another new setting is ``admin_users`` which allows you to specify a list of users to be considered 'administrators'. Previously this was hardcoded to ``root``. It now it defaults to ``[root, toor, admin]``. This information is used when choosing between your ``remote_temp`` and ``system_temps`` directory. - -For a full list, check the shell plugin you are using, the default shell plugin is ``sh``. - -Those that had to work around the global configuration limitations can now migrate to a per host/group settings, -but also note that the new defaults might conflict with existing usage if the assumptions don't correlate to your environment. - -Filter ------- - -The lookup plugin API now throws an error if a non-iterable value is returned from a plugin. Previously, numbers or -other non-iterable types returned by a plugin were accepted without error or warning. This change was made because plugins should always return a list. Please note that plugins that return strings and other non-list iterable values will not throw an error, but may cause unpredictable behavior. If you have a custom lookup plugin that does not return a list, you should modify it to wrap the return values in a list. - -Lookup -------- - -A new option was added to lookup plugins globally named ``error`` which allows you to control how errors produced by the lookup are handled, before this option they were always fatal. Valid values for this option are ``warn``, ``ignore`` and ``strict``. See the :ref:`lookup ` page for more details. - - -Porting custom scripts -====================== - -No notable changes. - -Network -======= - -Expanding documentation ------------------------ - -We're expanding the network documentation. There's new content and a :ref:`new Ansible Network landing page`. We will continue to build the network-related documentation moving forward. - -Top-level connection arguments will be removed in 2.9 ------------------------------------------------------ - -Top-level connection arguments like ``username``, ``host``, and ``password`` are deprecated and will be removed in version 2.9. - -**OLD** In Ansible < 2.4 - -.. code-block:: yaml - - - name: example of using top-level options for connection properties - ios_command: - commands: show version - host: "{{ inventory_hostname }}" - username: cisco - password: cisco - authorize: yes - auth_pass: cisco - -The deprecation warnings reflect this schedule. The task above, run in Ansible 2.5, will result in: - -.. code-block:: yaml - - [DEPRECATION WARNING]: Param 'username' is deprecated. See the module docs for more information. This feature will be removed in version - 2.9. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. - [DEPRECATION WARNING]: Param 'password' is deprecated. See the module docs for more information. This feature will be removed in version - 2.9. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. - [DEPRECATION WARNING]: Param 'host' is deprecated. See the module docs for more information. This feature will be removed in version 2.9. - Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. - -We recommend using the new connection types ``network_cli`` and ``netconf`` (see below), using standard Ansible connection properties, and setting those properties in inventory by group. As you update your playbooks and inventory files, you can easily make the change to ``become`` for privilege escalation (on platforms that support it). For more information, see the :ref:`using become with network modules` guide and the :ref:`platform documentation`. - -Adding persistent connection types ``network_cli`` and ``netconf`` ------------------------------------------------------------------- - -Ansible 2.5 introduces two top-level persistent connection types, ``network_cli`` and ``netconf``. With ``connection: local``, each task passed the connection parameters, which had to be stored in your playbooks. With ``network_cli`` and ``netconf`` the playbook passes the connection parameters once, so you can pass them at the command line if you prefer. We recommend you use ``network_cli`` and ``netconf`` whenever possible. -Note that eAPI and NX-API still require ``local`` connections with ``provider`` dictionaries. See the :ref:`platform documentation` for more information. Unless you need a ``local`` connection, update your playbooks to use ``network_cli`` or ``netconf`` and to specify your connection variables with standard Ansible connection variables: - -**OLD** In Ansible 2.4 - -.. code-block:: yaml - - --- - vars: - cli: - host: "{{ inventory_hostname }}" - username: operator - password: secret - transport: cli - - tasks: - - nxos_config: - src: config.j2 - provider: "{{ cli }}" - username: admin - password: admin - -**NEW** In Ansible 2.5 - -.. code-block:: ini - - [nxos:vars] - ansible_connection=network_cli - ansible_network_os=nxos - ansible_user=operator - ansible_password=secret - -.. code-block:: yaml - - tasks: - - nxos_config: - src: config.j2 - -Using a provider dictionary with either ``network_cli`` or ``netconf`` will result in a warning. - - -Developers: Shared Module Utilities Moved ------------------------------------------ - -Beginning with Ansible 2.5, shared module utilities for network modules moved to ``ansible.module_utils.network``. - -* Platform-independent utilities are found in ``ansible.module_utils.network.common`` - -* Platform-specific utilities are found in ``ansible.module_utils.network.{{ platform }}`` - -If your module uses shared module utilities, you must update all references. For example, change: - -**OLD** In Ansible 2.4 - -.. code-block:: python - - from ansible.module_utils.vyos import get_config, load_config - -**NEW** In Ansible 2.5 - -.. code-block:: python - - from ansible.module_utils.network.vyos.vyos import get_config, load_config - - -See the module utilities developer guide see :ref:`developing_module_utilities` for more information. diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.6.rst b/docs/docsite/rst/porting_guides/porting_guide_2.6.rst deleted file mode 100644 index d585c00491f..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.6.rst +++ /dev/null @@ -1,114 +0,0 @@ -.. _porting_2.6_guide: - -************************* -Ansible 2.6 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.5 and Ansible 2.6. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `Ansible Changelog for 2.6 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - -Playbook -======== - -* The deprecated task option ``always_run`` has been removed, please use ``check_mode: no`` instead. - -Deprecated -========== - -* In the :ref:`nxos_igmp_interface module`, ``oif_prefix`` and ``oif_source`` properties are deprecated. Use ``ois_ps`` parameter with a dictionary of prefix and source to values instead. - -Modules -======= - -Major changes in popular modules are detailed here: - - -Modules removed ---------------- - -The following modules no longer exist: - - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.10. Please update your playbooks accordingly. - -* ``k8s_raw`` use :ref:`k8s ` instead. -* ``openshift_raw`` use :ref:`k8s ` instead. -* ``openshift_scale`` use :ref:`k8s_scale ` instead. - -Noteworthy module changes -------------------------- - -* The ``upgrade`` module option for ``win_chocolatey`` has been removed; use ``state: latest`` instead. -* The ``reboot`` module option for ``win_feature`` has been removed; use the ``win_reboot`` action plugin instead. -* The ``win_iis_webapppool`` module no longer accepts a string for the ``attributes`` module option; use the free form dictionary value instead. -* The ``name`` module option for ``win_package`` has been removed; this is not used anywhere and should just be removed from your playbooks. -* The ``win_regedit`` module no longer automatically corrects the hive path ``HCCC`` to ``HKCC``; use ``HKCC`` because this is the correct hive path. -* The :ref:`file_module` now emits a deprecation warning when ``src`` is specified with a state - other than ``hard`` or ``link`` as it is only supposed to be useful with those. This could have - an effect on people who were depending on a buggy interaction between src and other state's to - place files into a subdirectory. For instance:: - - $ ansible localhost -m file -a 'path=/var/lib src=/tmp/ state=directory' - - Would create a directory named ``/tmp/lib``. Instead of the above, simply spell out the entire - destination path like this:: - - $ ansible localhost -m file -a 'path=/tmp/lib state=directory' - -* The ``k8s_raw`` and ``openshift_raw`` modules have been aliased to the new ``k8s`` module. -* The ``k8s`` module supports all Kubernetes resources including those from Custom Resource Definitions and aggregated API servers. This includes all OpenShift resources. -* The ``k8s`` module will not accept resources where subkeys have been snake_cased. This was a workaround that was suggested with the ``k8s_raw`` and ``openshift_raw`` modules. -* The ``k8s`` module may not accept resources where the ``api_version`` has been changed to match the shortened version in the Kubernetes Python client. You should now specify the proper full Kubernetes ``api_version`` for a resource. -* The ``k8s`` module can now process multi-document YAML files if they are passed with the ``src`` parameter. It will process each document as a separate resource. Resources provided inline with the ``resource_definition`` parameter must still be a single document. -* The ``k8s`` module will not automatically change ``Project`` creation requests into ``ProjectRequest`` creation requests as the ``openshift_raw`` module did. You must now specify the ``ProjectRequest`` kind explicitly. -* The ``k8s`` module will not automatically remove secrets from the Ansible return values (and by extension the log). In order to prevent secret values in a task from being logged, specify the ``no_log`` parameter on the task block. -* The ``k8s_scale`` module now supports scalable OpenShift objects, such as ``DeploymentConfig``. -* The ``lineinfile`` module was changed to show a warning when using an empty string as a regexp. - Since an empty regexp matches every line in a file, it will replace the last line in a file rather - than inserting. If this is the desired behavior, use ``'^'`` which will match every line and - will not trigger the warning. -* Openstack modules are no longer using ``shade`` library. Instead ``openstacksdk`` is used. Since ``openstacksdk`` should be already present as a dependency to ``shade`` no additional actions are required. - -Plugins -======= - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.10. Please update your playbooks accordingly. - -* ``openshift`` use ``k8s`` instead. - - -Noteworthy plugin changes -------------------------- - -* The ``k8s`` lookup plugin now supports all Kubernetes resources including those from Custom Resource Definitions and aggregated API servers. This includes all OpenShift resources. -* The ``k8s`` lookup plugin may not accept resources where the ``api_version`` has been changed to match the shortened version in the Kubernetes Python client. You should now specify the proper full Kubernetes ``api_version`` for a resource. -* The ``k8s`` lookup plugin will no longer remove secrets from the Ansible return values (and by extension the log). In order to prevent secret values in a task from being logged, specify the ``no_log`` parameter on the task block. - - -Porting custom scripts -====================== - -No notable changes. - -Networking -========== - -No notable changes. - -Dynamic inventory scripts -========================= - -* ``contrib/inventory/openstack.py`` has been renamed to ``contrib/inventory/openstack_inventory.py``. If you have used ``openstack.py`` as a name for your OpenStack dynamic inventory file, change it to ``openstack_inventory.py``. Otherwise the file name will conflict with imports from ``openstacksdk``. diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.7.rst b/docs/docsite/rst/porting_guides/porting_guide_2.7.rst deleted file mode 100644 index 0ab53655d08..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.7.rst +++ /dev/null @@ -1,248 +0,0 @@ -.. _porting_2.7_guide: - -************************* -Ansible 2.7 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.6 and Ansible 2.7. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `Ansible Changelog for 2.7 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - -Command Line -============ - -If you specify ``--tags`` or ``--skip-tags`` multiple times on the command line, Ansible will merge the specified -tags together. In previous versions of Ansible, you could set ``merge_multiple_cli_tags`` to ``False`` -if you wanted to keep only the last-specified ``--tags``. This config -option existed for backwards compatibility. The overwriting behavior was deprecated in 2.3 and -the default behavior was changed in 2.4. Ansible-2.7 removes the config option; multiple -``--tags`` are now always merged. - -If you have a shell script that depends on setting ``merge_multiple_cli_tags`` to ``False``, please upgrade your script -so it only adds the ``--tags`` you actually want before upgrading to Ansible-2.7. - - -Python Compatibility -==================== - -Ansible has dropped compatibility with Python-2.6 on the controller (The host where :command:`/usr/bin/ansible` -or :command:`/usr/bin/ansible-playbook` is run). Modules shipped with Ansible can still be used to -manage hosts which only have Python-2.6. You just need to have a host with Python-2.7 or Python-3.5 -or greater to manage those hosts from. - -One thing that this does affect is the ability to use :command:`/usr/bin/ansible-pull` to manage -a host which has Python-2.6. ``ansible-pull`` runs on the host being managed but it is a controller -script, not a module so it will need an updated Python. Actively developed Linux distros which ship -with Python-2.6 have some means to install newer Python versions (For instance, you can install -Python-2.7 through an SCL on RHEL-6) but you may need to also install Python bindings for many common -modules to work (For RHEL-6, for instance, selinux bindings and yum would have to be installed for -the updated Python install). - -The decision to drop Python-2.6 support on the controller was made because many dependent libraries -are becoming unavailable there. In particular, python-cryptography is no longer available for Python-2.6 -and the last release of pycrypto (the alternative to python-cryptography) has known security bugs -which will never be fixed. - - -Playbook -======== - -Role Precedence Fix during Role Loading ---------------------------------------- - -Ansible 2.7 makes a small change to variable precedence when loading roles, resolving a bug, ensuring that role loading matches :ref:`variable precedence expectations `. - -Before Ansible 2.7, when loading a role, the variables defined in the role's ``vars/main.yml`` and ``defaults/main.yml`` were not available when parsing the role's ``tasks/main.yml`` file. This prevented the role from utilizing these variables when being parsed. The problem manifested when ``import_tasks`` or ``import_role`` was used with a variable defined in the role's vars or defaults. - -In Ansible 2.7, role ``vars`` and ``defaults`` are now parsed before ``tasks/main.yml``. This can cause a change in behavior if the same variable is defined at the play level and the role level with different values, and used in ``import_tasks`` or ``import_role`` to define the role or file to import. - -include_role and import_role variable exposure ----------------------------------------------- - -In Ansible 2.7 a new module argument named ``public`` was added to the ``include_role`` module that dictates whether or not the role's ``defaults`` and ``vars`` will be exposed outside of the role, allowing those variables to be used by later tasks. This value defaults to ``public: False``, matching current behavior. - -``import_role`` does not support the ``public`` argument, and will unconditionally expose the role's ``defaults`` and ``vars`` to the rest of the playbook. This functionality brings ``import_role`` into closer alignment with roles listed within the ``roles`` header in a play. - -There is an important difference in the way that ``include_role`` (dynamic) will expose the role's variables, as opposed to ``import_role`` (static). ``import_role`` is a pre-processor, and the ``defaults`` and ``vars`` are evaluated at playbook parsing, making the variables available to tasks and roles listed at any point in the play. ``include_role`` is a conditional task, and the ``defaults`` and ``vars`` are evaluated at execution time, making the variables available to tasks and roles listed *after* the ``include_role`` task. - -include_tasks/import_tasks inline variables -------------------------------------------- - -As of Ansible 2.7, `include_tasks` and `import_tasks` can no longer accept inline variables. Instead of using inline variables, tasks should supply variables under the ``vars`` keyword. - -**OLD** In Ansible 2.6 (and earlier) the following was valid syntax for specifying variables: - -.. code-block:: yaml - - - include_tasks: include_me.yml variable=value - -**NEW** In Ansible 2.7 the task should be changed to use the ``vars`` keyword: - -.. code-block:: yaml - - - include_tasks: include_me.yml - vars: - variable: value - -vars_prompt with unknown algorithms ------------------------------------ - -vars_prompt now throws an error if the hash algorithm specified in encrypt is not supported by -the controller. This increases the safety of vars_prompt as it previously returned None if the -algorithm was unknown. Some modules, notably the user module, treated a password of None as -a request not to set a password. If your playbook starts erroring because of this, change the -hashing algorithm being used with this filter. - - -Deprecated -========== - -Expedited Deprecation: Use of ``__file__`` in ``AnsibleModule`` ---------------------------------------------------------------- - -.. note:: The use of the ``__file__`` variable is deprecated in Ansible 2.7 and **will be eliminated in Ansible 2.8**. This is much quicker than our usual 4-release deprecation cycle. - -We are deprecating the use of the ``__file__`` variable to refer to the file containing the currently-running code. This common Python technique for finding a filesystem path does not always work (even in vanilla Python). Sometimes a Python module can be imported from a virtual location (like inside of a zip file). When this happens, the ``__file__`` variable will reference a virtual location pointing to inside of the zip file. This can cause problems if, for instance, the code was trying to use ``__file__`` to find the directory containing the python module to write some temporary information. - -Before the introduction of AnsiBallZ in Ansible 2.1, using ``__file__`` worked in ``AnsibleModule`` sometimes, but any module that used it would fail when pipelining was turned on (because the module would be piped into the python interpreter's standard input, so ``__file__`` wouldn't contain a file path). AnsiBallZ unintentionally made using ``__file__`` work, by always creating a temporary file for ``AnsibleModule`` to reside in. - -Ansible 2.8 will no longer create a temporary file for ``AnsibleModule``; instead it will read the file out of a zip file. This change should speed up module execution, but it does mean that starting with Ansible 2.8, referencing ``__file__`` will always fail in ``AnsibleModule``. - -If you are the author of a third-party module which uses ``__file__`` with ``AnsibleModule``, please update your module(s) now, while the use of ``__file__`` is deprecated but still available. The most common use of ``__file__`` is to find a directory to write a temporary file. In Ansible 2.5 and above, you can use the ``tmpdir`` attribute on an ``AnsibleModule`` instance instead, as shown in this code from the :ref:`apt module `: - -.. code-block:: diff - - - tempdir = os.path.dirname(__file__) - - package = os.path.join(tempdir, to_native(deb.rsplit('/', 1)[1])) - + package = os.path.join(module.tmpdir, to_native(deb.rsplit('/', 1)[1])) - - -Using a loop on a package module through squash_actions -------------------------------------------------------- - -The use of ``squash_actions`` to invoke a package module, such as "yum", to only invoke the module once is deprecated, and will be removed in Ansible 2.11. - -Instead of relying on implicit squashing, tasks should instead supply the list directly to the ``name``, ``pkg`` or ``package`` parameter of the module. This functionality has been supported in most modules since Ansible 2.3. - -**OLD** In Ansible 2.6 (and earlier) the following task would invoke the "yum" module only 1 time to install multiple packages - -.. code-block:: yaml - - - name: Install packages - yum: - name: "{{ item }}" - state: present - with_items: "{{ packages }}" - -**NEW** In Ansible 2.7 it should be changed to look like this: - -.. code-block:: yaml - - - name: Install packages - yum: - name: "{{ packages }}" - state: present - - -Modules -======= - -Major changes in popular modules are detailed here - -* The :ref:`DEFAULT_SYSLOG_FACILITY` configuration option tells Ansible modules to use a specific - `syslog facility `_ when logging information on all - managed machines. Due to a bug with older Ansible versions, this setting did not affect machines - using journald with the systemd Python bindings installed. On those machines, Ansible log - messages were sent to ``/var/log/messages``, even if you set :ref:`DEFAULT_SYSLOG_FACILITY`. - Ansible 2.7 fixes this bug, routing all Ansible log messages according to the value set for - :ref:`DEFAULT_SYSLOG_FACILITY`. If you have :ref:`DEFAULT_SYSLOG_FACILITY` configured, the - location of remote logs on systems which use journald may change. - -Modules removed ---------------- - -The following modules no longer exist: - - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.11. Please update your playbooks accordingly. - -* ``na_cdot_aggregate`` use :ref:`na_ontap_aggregate ` instead. -* ``na_cdot_license`` use :ref:`na_ontap_license ` instead. -* ``na_cdot_lun`` use :ref:`na_ontap_lun ` instead. -* ``na_cdot_qtree`` use :ref:`na_ontap_qtree ` instead. -* ``na_cdot_svm`` use :ref:`na_ontap_svm ` instead. -* ``na_cdot_user`` use :ref:`na_ontap_user ` instead. -* ``na_cdot_user_role`` use :ref:`na_ontap_user_role ` instead. -* ``na_cdot_volume`` use :ref:`na_ontap_volume ` instead. -* ``sf_account_manager`` use :ref:`na_elementsw_account` instead. -* ``sf_check_connections`` use :ref:`na_elementsw_check_connections` instead. -* ``sf_snapshot_schedule_manager`` use :ref:`na_elementsw_snapshot_schedule` instead. -* ``sf_volume_access_group_manager`` use :ref:`na_elementsw_access_group` instead. -* ``sf_volume_manager`` use :ref:`na_elementsw_volume` instead. - -Noteworthy module changes -------------------------- - -* Check mode is now supported in the ``command`` and ``shell`` modules. However, only when ``creates`` or ``removes`` is - specified. If either of these are specified, the module will check for existence of the file and report the correct - changed status, if they are not included the module will skip like it had done previously. - -* The ``win_chocolatey`` module originally required the ``proxy_username`` and ``proxy_password`` to - escape any double quotes in the value. This is no longer required and the escaping may cause further - issues. - -* The ``win_uri`` module has removed the deprecated option ``use_basic_parsing``, since Ansible 2.5 this option did - nothing - -* The ``win_scheduled_task`` module has removed the following deprecated options: - - * ``executable``, use ``path`` in an actions entry instead - * ``argument``, use ``arguments`` in an actions entry instead - * ``store_password``, set ``logon_type: password`` instead - * ``days_of_week``, use ``monthlydow`` in a triggers entry instead - * ``frequency``, use ``type``, in a triggers entry instead - * ``time``, use ``start_boundary`` in a triggers entry instead - -* The ``interface_name`` module option for ``na_ontap_net_vlan`` has been removed and should be removed from your playbooks - -* The ``win_disk_image`` module has deprecated the return value ``mount_path``, use ``mount_paths[0]`` instead. This will - be removed in Ansible 2.11. - -* ``include_role`` and ``include_tasks`` can now be used directly from ``ansible`` (adhoc) and ``ansible-console``:: - - #> ansible -m include_role -a 'name=myrole' all - -* The ``pip`` module has added a dependency on ``setuptools`` to support version requirements, this requirement is for - the Python interpreter that executes the module and not the Python interpreter that the module is managing. - -* Prior to Ansible 2.7.10, the ``replace`` module did the opposite of what was intended when using the ``before`` and ``after`` options together. This now works properly but may require changes to tasks. - - -Plugins -======= - -* The hash_password filter now throws an error if the hash algorithm specified is not supported by - the controller. This increases the safety of the filter as it previously returned None if the - algorithm was unknown. Some modules, notably the user module, treated a password of None as - a request not to set a password. If your playbook starts erroring because of this, change the - hashing algorithm being used with this filter. - - -Porting custom scripts -====================== - -No notable changes. - -Networking -========== - -No notable changes. diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.8.rst b/docs/docsite/rst/porting_guides/porting_guide_2.8.rst deleted file mode 100644 index 1f3903476e8..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.8.rst +++ /dev/null @@ -1,582 +0,0 @@ -.. _porting_2.8_guide: - -************************* -Ansible 2.8 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.7 and Ansible 2.8. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `Ansible Changelog for 2.8 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: - :local: - -Playbook -======== - -Distribution Facts ------------------- - -The information returned for the ``ansible_distribution_*`` group of facts may have changed -slightly. Ansible 2.8 uses a new backend library for information about distributions: `nir0s/distro `_. This library runs on Python-3.8 and fixes many bugs, including correcting release and version names. - -The two facts used in playbooks most often, ``ansible_distribution`` and ``ansible_distribution_major_version``, should not change. If you discover a change in these facts, please file a bug so we can address the -difference. However, other facts like ``ansible_distribution_release`` and -``ansible_distribution_version`` may change as erroneous information gets corrected. - -Imports as handlers -------------------- - -Beginning in version 2.8, a task cannot notify ``import_tasks`` or a static ``include`` that is specified in ``handlers``. - -The goal of a static import is to act as a pre-processor, where the import is replaced by the tasks defined within the imported file. When -using an import, a task can notify any of the named tasks within the imported file, but not the name of the import itself. - -To achieve the results of notifying a single name but running multiple handlers, utilize ``include_tasks``, or ``listen`` :ref:`handlers`. - -Jinja Undefined values ----------------------- - -Beginning in version 2.8, attempting to access an attribute of an Undefined value in Jinja will return another Undefined value, rather than throwing an error immediately. This means that you can now simply use -a default with a value in a nested data structure when you don't know if the intermediate values are defined. - -In Ansible 2.8:: - - {{ foo.bar.baz | default('DEFAULT') }} - -In Ansible 2.7 and older:: - - {{ ((foo | default({})).bar | default({})).baz | default('DEFAULT') }} - -or:: - - {{ foo.bar.baz if (foo is defined and foo.bar is defined and foo.bar.baz is defined) else 'DEFAULT' }} - -Module option conversion to string ----------------------------------- - -Beginning in version 2.8, Ansible will warn if a module expects a string, but a non-string value is passed and automatically converted to a string. This highlights potential problems where, for example, a ``yes`` or ``true`` (parsed as truish boolean value) would be converted to the string ``'True'``, or where a version number ``1.10`` (parsed as float value) would be converted to ``'1.1'``. Such conversions can result in unexpected behavior depending on context. - -This behavior can be changed to be an error or to be ignored by setting the ``ANSIBLE_STRING_CONVERSION_ACTION`` environment variable, or by setting the ``string_conversion_action`` configuration in the ``defaults`` section of ``ansible.cfg``. - -Command line facts ------------------- - -``cmdline`` facts returned in system will be deprecated in favor of ``proc_cmdline``. This change handles special case where Kernel command line parameter contains multiple values with the same key. - -Bare variables in conditionals ------------------------------- - -In Ansible 2.7 and earlier, top-level variables sometimes treated boolean strings as if they were boolean values. This led to inconsistent behavior in conditional tests built on top-level variables defined as strings. Ansible 2.8 began changing this behavior. For example, if you set two conditions like this: - -.. code-block:: yaml - - tasks: - - include_tasks: teardown.yml - when: teardown - - - include_tasks: provision.yml - when: not teardown - -based on a variable you define **as a string** (with quotation marks around it): - -* In Ansible 2.7 and earlier, the two conditions above evaluated as ``True`` and ``False`` respectively if ``teardown: 'true'`` -* In Ansible 2.7 and earlier, both conditions evaluated as ``False`` if ``teardown: 'false'`` -* In Ansible 2.8 and later, you have the option of disabling conditional bare variables, so ``when: teardown`` always evaluates as ``True`` and ``when: not teardown`` always evaluates as ``False`` when ``teardown`` is a non-empty string (including ``'true'`` or ``'false'``) - -Ultimately, ``when: 'string'`` will always evaluate as ``True`` and ``when: not 'string'`` will always evaluate as ``False``, as long as ``'string'`` is not empty, even if the value of ``'string'`` itself looks like a boolean. For users with playbooks that depend on the old behavior, we added a config setting that preserves it. You can use the ``ANSIBLE_CONDITIONAL_BARE_VARS`` environment variable or ``conditional_bare_variables`` in the ``defaults`` section of ``ansible.cfg`` to select the behavior you want on your control node. The default setting is ``true``, which preserves the old behavior. Set the config value or environment variable to ``false`` to start using the new option. - -.. note:: - - In 2.10 the default setting for ``conditional_bare_variables`` will change to ``false``. In 2.12 the old behavior will be deprecated. - -Updating your playbooks -^^^^^^^^^^^^^^^^^^^^^^^ - -To prepare your playbooks for the new behavior, you must update your conditional statements so they accept only boolean values. For variables, you can use the ``bool`` filter to evaluate the string ``'false'`` as ``False``: - -.. code-block:: yaml - - vars: - teardown: 'false' - - tasks: - - include_tasks: teardown.yml - when: teardown | bool - - - include_tasks: provision.yml - when: not teardown | bool - -Alternatively, you can re-define your variables as boolean values (without quotation marks) instead of strings: - -.. code-block:: yaml - - vars: - teardown: false - - tasks: - - include_tasks: teardown.yml - when: teardown - - - include_tasks: provision.yml - when: not teardown - -For dictionaries and lists, use the ``length`` filter to evaluate the presence of a dictionary or list as ``True``: - -.. code-block:: yaml+jinja - - - debug: - when: my_list | length > 0 - - - debug: - when: my_dictionary | length > 0 - -Do not use the ``bool`` filter with lists or dictionaries. If you use ``bool`` with a list or dict, Ansible will always evaluate it as ``False``. - -Double-interpolation -^^^^^^^^^^^^^^^^^^^^ - -The ``conditional_bare_variables`` setting also affects variables set based on other variables. The old behavior unexpectedly double-interpolated those variables. For example: - -.. code-block:: yaml - - vars: - double_interpolated: 'bare_variable' - bare_variable: false - - tasks: - - debug: - when: double_interpolated - -* In Ansible 2.7 and earlier, ``when: double_interpolated`` evaluated to the value of ``bare_variable``, in this case, ``False``. If the variable ``bare_variable`` is undefined, the conditional fails. -* In Ansible 2.8 and later, with bare variables disabled, Ansible evaluates ``double_interpolated`` as the string ``'bare_variable'``, which is ``True``. - -To double-interpolate variable values, use curly braces: - -.. code-block:: yaml+jinja - - vars: - double_interpolated: "{{ other_variable }}" - other_variable: false - -Nested variables -^^^^^^^^^^^^^^^^ - -The ``conditional_bare_variables`` setting does not affect nested variables. Any string value assigned to a subkey is already respected and not treated as a boolean. If ``complex_variable['subkey']`` is a non-empty string, then ``when: complex_variable['subkey']`` is always ``True`` and ``when: not complex_variable['subkey']`` is always ``False``. If you want a string subkey like ``complex_variable['subkey']`` to be evaluated as a boolean, you must use the ``bool`` filter. - -Gathering Facts ---------------- - -In Ansible 2.8 the implicit "Gathering Facts" task in a play was changed to -obey play tags. Previous to 2.8, the "Gathering Facts" task would ignore play -tags and tags supplied from the command line and always run in a task. - -The behavior change affects the following example play. - -.. code-block:: yaml - - - name: Configure Webservers - hosts: webserver - tags: - - webserver - tasks: - - name: Install nginx - package: - name: nginx - tags: - - nginx - -In Ansible 2.8, if you supply ``--tags nginx``, the implicit -"Gathering Facts" task will be skipped, as the task now inherits -the tag of ``webserver`` instead of ``always``. - -If no play level tags are set, the "Gathering Facts" task will -be given a tag of ``always`` and will effectively match prior -behavior. - -You can achieve similar results to the pre-2.8 behavior, by -using an explicit ``gather_facts`` task in your ``tasks`` list. - -.. code-block:: yaml - - - name: Configure Webservers - hosts: webserver - gather_facts: false - tags: - - webserver - tasks: - - name: Gathering Facts - gather_facts: - tags: - - always - - - name: Install nginx - package: - name: nginx - tags: - - nginx - -Python Interpreter Discovery -============================ - -In Ansible 2.7 and earlier, Ansible defaulted to :command:`/usr/bin/python` as the -setting for ``ansible_python_interpreter``. If you ran Ansible against a system -that installed Python with a different name or a different path, your playbooks -would fail with ``/usr/bin/python: bad interpreter: No such file or directory`` -unless you either set ``ansible_python_interpreter`` to the correct value for -that system or added a Python interpreter and any necessary dependencies at -:command:`usr/bin/python`. - -Starting in Ansible 2.8, Ansible searches for the correct path and executable -name for Python on each target system, first in a lookup table of default -Python interpreters for common distros, then in an ordered fallback list of -possible Python interpreter names/paths. - -It's risky to rely on a Python interpreter set from the fallback list, because -the interpreter may change on future runs. If an interpreter from -higher in the fallback list gets installed (for example, as a side-effect of -installing other packages), your original interpreter and its dependencies will -no longer be used. For this reason, Ansible warns you when it uses a Python -interpreter discovered from the fallback list. If you see this warning, the -best solution is to explicitly set ``ansible_python_interpreter`` to the path -of the correct interpreter for those target systems. - -You can still set ``ansible_python_interpreter`` to a specific path at any -variable level (as a host variable, in vars files, in playbooks, and so on). -If you prefer to use the Python interpreter discovery behavior, use -one of the four new values for ``ansible_python_interpreter`` introduced in -Ansible 2.8: - -+---------------------------+---------------------------------------------+ -| New value | Behavior | -+===========================+=============================================+ -| auto |br| | If a Python interpreter is discovered, | -| (future default) | Ansible uses the discovered Python, even if | -| | :command:`/usr/bin/python` is also present. | -| | Warns when using the fallback list. | -+---------------------------+---------------------------------------------+ -| **auto_legacy** |br| | If a Python interpreter is discovered, and | -| (Ansible 2.8 default) | :command:`/usr/bin/python` is absent, | -| | Ansible uses the discovered Python. Warns | -| | when using the fallback list. | -| | | -| | If a Python interpreter is discovered, and | -| | :command:`/usr/bin/python` is present, | -| | Ansible uses :command:`/usr/bin/python` and | -| | prints a deprecation warning about future | -| | default behavior. Warns when using the | -| | fallback list. | -+---------------------------+---------------------------------------------+ -| auto_legacy_silent | Behaves like ``auto_legacy`` but suppresses | -| | the deprecation and fallback-list warnings. | -+---------------------------+---------------------------------------------+ -| auto_silent | Behaves like ``auto`` but suppresses the | -| | fallback-list warning. | -+---------------------------+---------------------------------------------+ - - -In Ansible 2.12, Ansible will switch the default from :literal:`auto_legacy` to :literal:`auto`. -The difference in behaviour is that :literal:`auto_legacy` uses :command:`/usr/bin/python` if -present and falls back to the discovered Python when it is not present. :literal:`auto` will always -use the discovered Python, regardless of whether :command:`/usr/bin/python` exists. The -:literal:`auto_legacy` setting provides compatibility with previous versions of Ansible that always -defaulted to :command:`/usr/bin/python`. - -If you installed Python and dependencies (``boto``, and so on) to -:command:`/usr/bin/python` as a workaround on distros with a different default Python -interpreter (for example, Ubuntu 16.04+, RHEL8, Fedora 23+), you have two -options: - - #. Move existing dependencies over to the default Python for each platform/distribution/version. - #. Use ``auto_legacy``. This setting lets Ansible find and use the workaround Python on hosts that have it, while also finding the correct default Python on newer hosts. But remember, the default will change in 4 releases. - - -Retry File Creation default ---------------------------- - -In Ansible 2.8, ``retry_files_enabled`` now defaults to ``False`` instead of ``True``. The behavior can be -modified to previous version by editing the default ``ansible.cfg`` file and setting the value to ``True``. - -Command Line -============ - -Become Prompting ----------------- - -Beginning in version 2.8, by default Ansible will use the word ``BECOME`` to prompt you for a password for elevated privileges (``sudo`` privileges on Unix systems or ``enable`` mode on network devices): - -By default in Ansible 2.8:: - - ansible-playbook --become --ask-become-pass site.yml - BECOME password: - -If you want the prompt to display the specific ``become_method`` you're using, instead of the general value ``BECOME``, set :ref:`AGNOSTIC_BECOME_PROMPT` to ``False`` in your Ansible configuration. - -By default in Ansible 2.7, or with ``AGNOSTIC_BECOME_PROMPT=False`` in Ansible 2.8:: - - ansible-playbook --become --ask-become-pass site.yml - SUDO password: - -Deprecated -========== - -* Setting the async directory using ``ANSIBLE_ASYNC_DIR`` as an task/play environment key is deprecated and will be - removed in Ansible 2.12. You can achieve the same result by setting ``ansible_async_dir`` as a variable like:: - - - name: run task with custom async directory - command: sleep 5 - async: 10 - vars: - ansible_async_dir: /tmp/.ansible_async - -* Plugin writers who need a ``FactCache`` object should be aware of two deprecations: - - 1. The ``FactCache`` class has moved from ``ansible.plugins.cache.FactCache`` to - ``ansible.vars.fact_cache.FactCache``. This is because the ``FactCache`` is not part of the - cache plugin API and cache plugin authors should not be subclassing it. ``FactCache`` is still - available from its old location but will issue a deprecation warning when used from there. The - old location will be removed in Ansible 2.12. - - 2. The ``FactCache.update()`` method has been converted to follow the dict API. It now takes a - dictionary as its sole argument and updates itself with the dictionary's items. The previous - API where ``update()`` took a key and a value will now issue a deprecation warning and will be - removed in 2.12. If you need the old behavior switch to ``FactCache.first_order_merge()`` - instead. - -* Supporting file-backed caching through self.cache is deprecated and will - be removed in Ansible 2.12. If you maintain an inventory plugin, update it to use ``self._cache`` as a dictionary. For implementation details, see - the :ref:`developer guide on inventory plugins`. - -* Importing cache plugins directly is deprecated and will be removed in Ansible 2.12. Use the plugin_loader - so direct options, environment variables, and other means of configuration can be reconciled using the config - system rather than constants. - - .. code-block:: python - - from ansible.plugins.loader import cache_loader - cache = cache_loader.get('redis', **kwargs) - -Modules -======= - -Major changes in popular modules are detailed here - -The exec wrapper that runs PowerShell modules has been changed to set ``$ErrorActionPreference = "Stop"`` globally. -This may mean that custom modules can fail if they implicitly relied on this behavior. To get the old behavior back, -add ``$ErrorActionPreference = "Continue"`` to the top of the module. This change was made to restore the old behavior -of the EAP that was accidentally removed in a previous release and ensure that modules are more resilient to errors -that may occur in execution. - -* Version 2.8.14 of Ansible changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the ``mode`` change has been reverted in 2.8.15, and ``mode`` will now default to ``0o666 & ~umask`` as in previous versions of Ansible. -* If you changed any tasks to specify less restrictive permissions while using 2.8.14, those changes will be unnecessary (but will do no harm) in 2.8.15. -* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it. - -* ``dnf`` and ``yum`` - As of version 2.8.15, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task. - - -Modules removed ---------------- - -The following modules no longer exist: - -* ec2_remote_facts -* azure -* cs_nic -* netscaler -* win_msi - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.12. Please update your playbooks accordingly. - -* ``foreman`` use `foreman-ansible-modules `_ instead. -* ``katello`` use `foreman-ansible-modules `_ instead. -* ``github_hooks`` use :ref:`github_webhook ` and :ref:`github_webhook_facts ` instead. -* ``digital_ocean`` use :ref:`digital_ocean_droplet ` instead. -* ``gce`` use :ref:`gcp_compute_instance ` instead. -* ``gcspanner`` use :ref:`gcp_spanner_instance ` and :ref:`gcp_spanner_database ` instead. -* ``gcdns_record`` use :ref:`gcp_dns_resource_record_set ` instead. -* ``gcdns_zone`` use :ref:`gcp_dns_managed_zone ` instead. -* ``gcp_forwarding_rule`` use :ref:`gcp_compute_global_forwarding_rule ` or :ref:`gcp_compute_forwarding_rule ` instead. -* ``gcp_healthcheck`` use :ref:`gcp_compute_health_check `, :ref:`gcp_compute_http_health_check `, or :ref:`gcp_compute_https_health_check ` instead. -* ``gcp_backend_service`` use :ref:`gcp_compute_backend_service ` instead. -* ``gcp_target_proxy`` use :ref:`gcp_compute_target_http_proxy ` instead. -* ``gcp_url_map`` use :ref:`gcp_compute_url_map ` instead. -* ``panos`` use the `Palo Alto Networks Ansible Galaxy role `_ instead. - - -Noteworthy module changes -------------------------- - -* The ``foreman`` and ``katello`` modules have been deprecated in favor of a set of modules that are broken out per entity with better idempotency in mind. -* The ``foreman`` and ``katello`` modules replacement is officially part of the Foreman Community and supported there. -* The ``tower_credential`` module originally required the ``ssh_key_data`` to be the path to a ssh_key_file. - In order to work like AWX/Tower/RHAAP, ``ssh_key_data`` now contains the content of the file. - The previous behavior can be achieved with ``lookup('file', '/path/to/file')``. -* The ``win_scheduled_task`` module deprecated support for specifying a trigger repetition as a list and this format - will be removed in Ansible 2.12. Instead specify the repetition as a dictionary value. - -* The ``win_feature`` module has removed the deprecated ``restart_needed`` return value, use the standardized - ``reboot_required`` value instead. - -* The ``win_package`` module has removed the deprecated ``restart_required`` and ``exit_code`` return value, use the - standardized ``reboot_required`` and ``rc`` value instead. - -* The ``win_get_url`` module has removed the deprecated ``win_get_url`` return dictionary, contained values are - returned directly. - -* The ``win_get_url`` module has removed the deprecated ``skip_certificate_validation`` option, use the standardized - ``validate_certs`` option instead. - -* The ``vmware_local_role_facts`` module now returns a list of dicts instead of a dict of dicts for role information. - -* If ``docker_network`` or ``docker_volume`` were called with ``diff: yes``, ``check_mode: yes`` or ``debug: yes``, - a return value called ``diff`` was returned of type ``list``. To enable proper diff output, this was changed to - type ``dict``; the original ``list`` is returned as ``diff.differences``. - -* The ``na_ontap_cluster_peer`` module has replaced ``source_intercluster_lif`` and ``dest_intercluster_lif`` string options with - ``source_intercluster_lifs`` and ``dest_intercluster_lifs`` list options - -* The ``modprobe`` module now detects kernel builtins. Previously, attempting to remove (with ``state: absent``) - a builtin kernel module succeeded without any error message because ``modprobe`` did not detect the module as - ``present``. Now, ``modprobe`` will fail if a kernel module is builtin and ``state: absent`` (with an error message - from the modprobe binary like ``modprobe: ERROR: Module nfs is builtin.``), and it will succeed without reporting - changed if ``state: present``. Any playbooks that are using ``changed_when: no`` to mask this quirk can safely - remove that workaround. To get the previous behavior when applying ``state: absent`` to a builtin kernel module, - use ``failed_when: false`` or ``ignore_errors: true`` in your playbook. - -* The ``digital_ocean`` module has been deprecated in favor of modules that do not require external dependencies. - This allows for more flexibility and better module support. - -* The ``docker_container`` module has deprecated the returned fact ``docker_container``. The same value is - available as the returned variable ``container``. The returned fact will be removed in Ansible 2.12. -* The ``docker_network`` module has deprecated the returned fact ``docker_container``. The same value is - available as the returned variable ``network``. The returned fact will be removed in Ansible 2.12. -* The ``docker_volume`` module has deprecated the returned fact ``docker_container``. The same value is - available as the returned variable ``volume``. The returned fact will be removed in Ansible 2.12. - -* The ``docker_service`` module was renamed to :ref:`docker_compose `. -* The renamed ``docker_compose`` module used to return one fact per service, named same as the service. A dictionary - of these facts is returned as the regular return value ``services``. The returned facts will be removed in - Ansible 2.12. - -* The ``docker_swarm_service`` module no longer sets a defaults for the following options: - * ``user``. Before, the default was ``root``. - * ``update_delay``. Before, the default was ``10``. - * ``update_parallelism``. Before, the default was ``1``. - -* ``vmware_vm_facts`` used to return dict of dict with virtual machine's facts. Ansible 2.8 and onwards will return list of dict with virtual machine's facts. - Please see module ``vmware_vm_facts`` documentation for example. - -* ``vmware_guest_snapshot`` module used to return ``results``. Since Ansible 2.8 and onwards ``results`` is a reserved keyword, it is replaced by ``snapshot_results``. - Please see module ``vmware_guest_snapshots`` documentation for example. - -* The ``panos`` modules have been deprecated in favor of using the Palo Alto Networks `Ansible Galaxy role - `_. Contributions to the role can be made - `here `_. - -* The ``ipa_user`` module originally always sent ``password`` to FreeIPA regardless of whether the password changed. Now the module only sends ``password`` if ``update_password`` is set to ``always``, which is the default. - -* The ``win_psexec`` has deprecated the undocumented ``extra_opts`` module option. This will be removed in Ansible 2.10. - -* The ``win_nssm`` module has deprecated the following options in favor of using the ``win_service`` module to configure the service after installing it with ``win_nssm``: - * ``dependencies``, use ``dependencies`` of ``win_service`` instead - * ``start_mode``, use ``start_mode`` of ``win_service`` instead - * ``user``, use ``username`` of ``win_service`` instead - * ``password``, use ``password`` of ``win_service`` instead - These options will be removed in Ansible 2.12. - -* The ``win_nssm`` module has also deprecated the ``start``, ``stop``, and ``restart`` values of the ``status`` option. - You should use the ``win_service`` module to control the running state of the service. This will be removed in Ansible 2.12. - -* The ``status`` module option for ``win_nssm`` has changed its default value to ``present``. Before, the default was ``start``. - Consequently, the service is no longer started by default after creation with ``win_nssm``, and you should use - the ``win_service`` module to start it if needed. - -* The ``app_parameters`` module option for ``win_nssm`` has been deprecated; use ``argument`` instead. This will be removed in Ansible 2.12. - -* The ``app_parameters_free_form`` module option for ``win_nssm`` has been aliased to the new ``arguments`` option. - -* The ``win_dsc`` module will now validate the input options for a DSC resource. In previous versions invalid options - would be ignored but are now not. - -* The ``openssl_pkcs12`` module will now regenerate the pkcs12 file if there are differences between the file on disk and the parameters passed to the module. - -Plugins -======= - -* Ansible no longer defaults to the ``paramiko`` connection plugin when using macOS as the control node. Ansible will now use the ``ssh`` connection plugin by default on a macOS control node. Since ``ssh`` supports connection persistence between tasks and playbook runs, it performs better than ``paramiko``. If you are using password authentication, you will need to install ``sshpass`` when using the ``ssh`` connection plugin. Or you can explicitly set the connection type to ``paramiko`` to maintain the pre-2.8 behavior on macOS. - -* Connection plugins have been standardized to allow use of ``ansible__user`` - and ``ansible__password`` variables. Variables such as - ``ansible__pass`` and ``ansible__username`` are treated - with lower priority than the standardized names and may be deprecated in the - future. In general, the ``ansible_user`` and ``ansible_password`` vars should - be used unless there is a reason to use the connection-specific variables. - -* The ``powershell`` shell plugin now uses ``async_dir`` to define the async path for the results file and the default - has changed to ``%USERPROFILE%\.ansible_async``. To control this path now, either set the ``ansible_async_dir`` - variable or the ``async_dir`` value in the ``powershell`` section of the config ini. - -* Order of enabled inventory plugins (:ref:`INVENTORY_ENABLED`) has been updated, :ref:`auto ` is now before :ref:`yaml ` and :ref:`ini `. - -* The private ``_options`` attribute has been removed from the ``CallbackBase`` class of callback - plugins. If you have a third-party callback plugin which needs to access the command line arguments, - use code like the following instead of trying to use ``self._options``: - - .. code-block:: python - - from ansible import context - [...] - tags = context.CLIARGS['tags'] - - ``context.CLIARGS`` is a read-only dictionary so normal dictionary retrieval methods like - ``CLIARGS.get('tags')`` and ``CLIARGS['tags']`` work as expected but you won't be able to modify - the cli arguments at all. - -* Play recap now counts ``ignored`` and ``rescued`` tasks as well as ``ok``, ``changed``, ``unreachable``, ``failed`` and ``skipped`` tasks, thanks to two additional stat counters in the ``default`` callback plugin. Tasks that fail and have ``ignore_errors: yes`` set are listed as ``ignored``. Tasks that fail and then execute a rescue section are listed as ``rescued``. Note that ``rescued`` tasks are no longer counted as ``failed`` as in Ansible 2.7 (and earlier). - -* ``osx_say`` callback plugin was renamed into :ref:`say `. - -* Inventory plugins now support caching through cache plugins. To start using a cache plugin with your inventory see the section on caching in the :ref:`inventory guide`. To port a custom cache plugin to be compatible with inventory see :ref:`developer guide on cache plugins`. - -Porting custom scripts -====================== - -Display class -------------- - -As of Ansible 2.8, the ``Display`` class is now a "singleton". Instead of using ``__main__.display`` each file should -import and instantiate ``ansible.utils.display.Display`` on its own. - -**OLD** In Ansible 2.7 (and earlier) the following was used to access the ``display`` object: - -.. code-block:: python - - try: - from __main__ import display - except ImportError: - from ansible.utils.display import Display - display = Display() - -**NEW** In Ansible 2.8 the following should be used: - -.. code-block:: python - - from ansible.utils.display import Display - display = Display() - -Networking -========== - -* The ``eos_config``, ``ios_config``, and ``nxos_config`` modules have removed the deprecated - ``save`` and ``force`` parameters, use the ``save_when`` parameter to replicate their - functionality. - -* The ``nxos_vrf_af`` module has removed the ``safi`` parameter. This parameter was deprecated - in Ansible 2.4 and has had no impact on the module since then. diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.9.rst b/docs/docsite/rst/porting_guides/porting_guide_2.9.rst deleted file mode 100644 index 463e807ac7c..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.9.rst +++ /dev/null @@ -1,759 +0,0 @@ - -.. _porting_2.9_guide: - -************************* -Ansible 2.9 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.8 and Ansible 2.9. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `Ansible Changelog for 2.9 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - - -Playbook -======== - -Inventory ---------- - - * ``hash_behaviour`` now affects inventory sources. If you have it set to ``merge``, the data you get from inventory might change and you will have to update playbooks accordingly. If you're using the default setting (``overwrite``), you will see no changes. Inventory was ignoring this setting. - -Loops ------ - -Ansible 2.9 handles "unsafe" data more robustly, ensuring that data marked "unsafe" is not templated. In previous versions, Ansible recursively marked all data returned by the direct use of ``lookup()`` as "unsafe", but only marked structured data returned by indirect lookups using ``with_X`` style loops as "unsafe" if the returned elements were strings. Ansible 2.9 treats these two approaches consistently. - -As a result, if you use ``with_dict`` to return keys with templatable values, your templates may no longer work as expected in Ansible 2.9. - -To allow the old behavior, switch from using ``with_X`` to using ``loop`` with a filter as described at :ref:`migrating_to_loop`. - -Command Line -============ - -* The location of the Galaxy token file has changed from ``~/.ansible_galaxy`` to ``~/.ansible/galaxy_token``. You can configure both path and file name with the :ref:`galaxy_token_path` config. - - -Deprecated -========== - -No notable changes - - -Collection loader changes -========================= - -The way to import a PowerShell or C# module util from a collection has changed in the Ansible 2.9 release. In Ansible -2.8 a util was imported with the following syntax: - -.. code-block:: powershell - - #AnsibleRequires -CSharpUtil AnsibleCollections.namespace_name.collection_name.util_filename - #AnsibleRequires -PowerShell AnsibleCollections.namespace_name.collection_name.util_filename - -In Ansible 2.9 this was changed to: - -.. code-block:: powershell - - #AnsibleRequires -CSharpUtil ansible_collections.namespace_name.collection_name.plugins.module_utils.util_filename - #AnsibleRequires -PowerShell ansible_collections.namespace_name.collection_name.plugins.module_utils.util_filename - -The change in the collection import name also requires any C# util namespaces to be updated with the newer name -format. This is more verbose but is designed to make sure we avoid plugin name conflicts across separate plugin types -and to standardise how imports work in PowerShell with how Python modules work. - - -Modules -======= - -* The ``win_get_url`` and ``win_uri`` module now sends requests with a default ``User-Agent`` of ``ansible-httpget``. This can be changed by using the ``http_agent`` key. -* The ``apt`` module now honors ``update_cache=false`` while installing its own dependency and skips the cache update. Explicitly setting ``update_cache=true`` or omitting the param ``update_cache`` will result in a cache update while installing its own dependency. - -* Version 2.9.12 of Ansible changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the mode change has been reverted in 2.9.13, and mode will now default to ``0o666 & ~umask`` as in previous versions of Ansible. -* If you changed any tasks to specify less restrictive permissions while using 2.9.12, those changes will be unnecessary (but will do no harm) in 2.9.13. -* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it. - -* ``dnf`` and ``yum`` - As of version 2.9.13, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task. - - -Renaming from ``_facts`` to ``_info`` --------------------------------------- - -Ansible 2.9 renamed a lot of modules from ``_facts`` to ``_info``, because the modules do not return :ref:`Ansible facts `. Ansible facts relate to a specific host. For example, the configuration of a network interface, the operating system on a unix server, and the list of packages installed on a Windows box are all Ansible facts. The renamed modules return values that are not unique to the host. For example, account information or region data for a cloud provider. Renaming these modules should provide more clarity about the types of return values each set of modules offers. - -Writing modules ---------------- - -* Module and module_utils files can now use relative imports to include other module_utils files. - This is useful for shortening long import lines, especially in collections. - - Example of using a relative import in collections: - - .. code-block:: python - - # File: ansible_collections/my_namespace/my_collection/plugins/modules/my_module.py - # Old way to use an absolute import to import module_utils from the collection: - from ansible_collections.my_namespace.my_collection.plugins.module_utils import my_util - # New way using a relative import: - from ..module_utils import my_util - - Modules and module_utils shipped with Ansible can use relative imports as well but the savings - are smaller: - - .. code-block:: python - - # File: ansible/modules/system/ping.py - # Old way to use an absolute import to import module_utils from core: - from ansible.module_utils.basic import AnsibleModule - # New way using a relative import: - from ...module_utils.basic import AnsibleModule - - Each single dot (``.``) represents one level of the tree (equivalent to ``../`` in filesystem relative links). - - .. seealso:: `The Python Relative Import Docs `_ go into more detail of how to write relative imports. - - -Modules removed ---------------- - -The following modules no longer exist: - -* Apstra's ``aos_*`` modules. See the new modules at `https://github.com/apstra `_. -* ec2_ami_find use :ref:`ec2_ami_facts ` instead. -* kubernetes use :ref:`k8s ` instead. -* nxos_ip_interface use :ref:`nxos_l3_interface ` instead. -* nxos_portchannel use :ref:`nxos_linkagg ` instead. -* nxos_switchport use :ref:`nxos_l2_interface ` instead. -* oc use :ref:`k8s ` instead. -* panos_nat_policy use :ref:`panos_nat_rule ` instead. -* panos_security_policy use :ref:`panos_security_rule ` instead. -* vsphere_guest use :ref:`vmware_guest ` instead. - - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.13. Please update update your playbooks accordingly. - -* cs_instance_facts use :ref:`cs_instance_info ` instead. - -* cs_zone_facts use :ref:`cs_zone_info ` instead. - -* digital_ocean_sshkey_facts use :ref:`digital_ocean_sshkey_info ` instead. - -* eos_interface use :ref:`eos_interfaces ` instead. - -* eos_l2_interface use :ref:`eos_l2_interfaces ` instead. - -* eos_l3_interface use :ref:`eos_l3_interfaces ` instead. - -* eos_linkagg use :ref:`eos_lag_interfaces ` instead. - -* eos_lldp_interface use :ref:`eos_lldp_interfaces ` instead. - -* eos_vlan use :ref:`eos_vlans ` instead. - -* ios_interface use :ref:`ios_interfaces ` instead. - -* ios_l2_interface use :ref:`ios_l2_interfaces ` instead. - -* ios_l3_interface use :ref:`ios_l3_interfaces ` instead. - -* ios_vlan use :ref:`ios_vlans ` instead. - -* iosxr_interface use :ref:`iosxr_interfaces ` instead. - -* junos_interface use :ref:`junos_interfaces ` instead. - -* junos_l2_interface use :ref:`junos_l2_interfaces ` instead. - -* junos_l3_interface use :ref:`junos_l3_interfaces ` instead. - -* junos_linkagg use :ref:`junos_lag_interfaces ` instead. - -* junos_lldp use :ref:`junos_lldp_global ` instead. - -* junos_lldp_interface use :ref:`junos_lldp_interfaces ` instead. - -* junos_vlan use :ref:`junos_vlans ` instead. - -* lambda_facts use :ref:`lambda_info ` instead. - -* na_ontap_gather_facts use :ref:`na_ontap_info ` instead. - -* net_banner use the platform-specific [netos]_banner modules instead. - -* net_interface use the new platform-specific [netos]_interfaces modules instead. - -* net_l2_interface use the new platform-specific [netos]_l2_interfaces modules instead. - -* net_l3_interface use the new platform-specific [netos]_l3_interfaces modules instead. - -* net_linkagg use the new platform-specific [netos]_lag modules instead. - -* net_lldp use the new platform-specific [netos]_lldp_global modules instead. - -* net_lldp_interface use the new platform-specific [netos]_lldp_interfaces modules instead. - -* net_logging use the platform-specific [netos]_logging modules instead. - -* net_static_route use the platform-specific [netos]_static_route modules instead. - -* net_system use the platform-specific [netos]_system modules instead. - -* net_user use the platform-specific [netos]_user modules instead. - -* net_vlan use the new platform-specific [netos]_vlans modules instead. - -* net_vrf use the platform-specific [netos]_vrf modules instead. - -* nginx_status_facts use :ref:`nginx_status_info ` instead. - -* nxos_interface use :ref:`nxos_interfaces ` instead. - -* nxos_l2_interface use :ref:`nxos_l2_interfaces ` instead. - -* nxos_l3_interface use :ref:`nxos_l3_interfaces ` instead. - -* nxos_linkagg use :ref:`nxos_lag_interfaces ` instead. - -* nxos_vlan use :ref:`nxos_vlans ` instead. - -* online_server_facts use :ref:`online_server_info ` instead. - -* online_user_facts use :ref:`online_user_info ` instead. - -* purefa_facts use :ref:`purefa_info ` instead. - -* purefb_facts use :ref:`purefb_info ` instead. - -* scaleway_image_facts use :ref:`scaleway_image_info ` instead. - -* scaleway_ip_facts use :ref:`scaleway_ip_info ` instead. - -* scaleway_organization_facts use :ref:`scaleway_organization_info ` instead. - -* scaleway_security_group_facts use :ref:`scaleway_security_group_info ` instead. - -* scaleway_server_facts use :ref:`scaleway_server_info ` instead. - -* scaleway_snapshot_facts use :ref:`scaleway_snapshot_info ` instead. - -* scaleway_volume_facts use :ref:`scaleway_volume_info ` instead. - -* vcenter_extension_facts use :ref:`vcenter_extension_info ` instead. - -* vmware_about_facts use :ref:`vmware_about_info ` instead. - -* vmware_category_facts use :ref:`vmware_category_info ` instead. - -* vmware_drs_group_facts use :ref:`vmware_drs_group_info ` instead. - -* vmware_drs_rule_facts use :ref:`vmware_drs_rule_info ` instead. - -* vmware_dvs_portgroup_facts use :ref:`vmware_dvs_portgroup_info ` instead. - -* vmware_guest_boot_facts use :ref:`vmware_guest_boot_info ` instead. - -* vmware_guest_customization_facts use :ref:`vmware_guest_customization_info ` instead. - -* vmware_guest_disk_facts use :ref:`vmware_guest_disk_info ` instead. - -* vmware_host_capability_facts use :ref:`vmware_host_capability_info ` instead. - -* vmware_host_config_facts use :ref:`vmware_host_config_info ` instead. - -* vmware_host_dns_facts use :ref:`vmware_host_dns_info ` instead. - -* vmware_host_feature_facts use :ref:`vmware_host_feature_info ` instead. - -* vmware_host_firewall_facts use :ref:`vmware_host_firewall_info ` instead. - -* vmware_host_ntp_facts use :ref:`vmware_host_ntp_info ` instead. - -* vmware_host_package_facts use :ref:`vmware_host_package_info ` instead. - -* vmware_host_service_facts use :ref:`vmware_host_service_info ` instead. - -* vmware_host_ssl_facts use :ref:`vmware_host_ssl_info ` instead. - -* vmware_host_vmhba_facts use :ref:`vmware_host_vmhba_info ` instead. - -* vmware_host_vmnic_facts use :ref:`vmware_host_vmnic_info ` instead. - -* vmware_local_role_facts use :ref:`vmware_local_role_info ` instead. - -* vmware_local_user_facts use :ref:`vmware_local_user_info ` instead. - -* vmware_portgroup_facts use :ref:`vmware_portgroup_info ` instead. - -* vmware_resource_pool_facts use :ref:`vmware_resource_pool_info ` instead. - -* vmware_target_canonical_facts use :ref:`vmware_target_canonical_info ` instead. - -* vmware_vmkernel_facts use :ref:`vmware_vmkernel_info ` instead. - -* vmware_vswitch_facts use :ref:`vmware_vswitch_info ` instead. - -* vultr_account_facts use :ref:`vultr_account_info ` instead. - -* vultr_block_storage_facts use :ref:`vultr_block_storage_info ` instead. - -* vultr_dns_domain_facts use :ref:`vultr_dns_domain_info ` instead. - -* vultr_firewall_group_facts use :ref:`vultr_firewall_group_info ` instead. - -* vultr_network_facts use :ref:`vultr_network_info ` instead. - -* vultr_os_facts use :ref:`vultr_os_info ` instead. - -* vultr_plan_facts use :ref:`vultr_plan_info ` instead. - -* vultr_region_facts use :ref:`vultr_region_info ` instead. - -* vultr_server_facts use :ref:`vultr_server_info ` instead. - -* vultr_ssh_key_facts use :ref:`vultr_ssh_key_info ` instead. - -* vultr_startup_script_facts use :ref:`vultr_startup_script_info ` instead. - -* vultr_user_facts use :ref:`vultr_user_info ` instead. - -* vyos_interface use :ref:`vyos_interfaces ` instead. - -* vyos_l3_interface use :ref:`vyos_l3_interfaces ` instead. - -* vyos_linkagg use :ref:`vyos_lag_interfaces ` instead. - -* vyos_lldp use :ref:`vyos_lldp_global ` instead. - -* vyos_lldp_interface use :ref:`vyos_lldp_interfaces ` instead. - - -The following functionality will be removed in Ansible 2.12. Please update update your playbooks accordingly. - -* ``vmware_cluster`` DRS, HA and VSAN configuration; use :ref:`vmware_cluster_drs `, :ref:`vmware_cluster_ha ` and :ref:`vmware_cluster_vsan ` instead. - - -The following functionality will be removed in Ansible 2.13. Please update update your playbooks accordingly. - -* ``openssl_certificate`` deprecates the ``assertonly`` provider. - Please see the :ref:`openssl_certificate ` documentation examples on how to - replace the provider with the :ref:`openssl_certificate_info `, - :ref:`openssl_csr_info `, :ref:`openssl_privatekey_info ` - and :ref:`assert ` modules. - - -For the following modules, the PyOpenSSL-based backend ``pyopenssl`` has been deprecated and will be -removed in Ansible 2.13: - -* :ref:`get_certificate ` -* :ref:`openssl_certificate ` -* :ref:`openssl_certificate_info ` -* :ref:`openssl_csr ` -* :ref:`openssl_csr_info ` -* :ref:`openssl_privatekey ` -* :ref:`openssl_privatekey_info ` -* :ref:`openssl_publickey ` - - -Renamed modules -^^^^^^^^^^^^^^^ - -The following modules have been renamed. The old name is deprecated and will -be removed in Ansible 2.13. Please update update your playbooks accordingly. - -* The ``ali_instance_facts`` module was renamed to :ref:`ali_instance_info `. -* The ``aws_acm_facts`` module was renamed to :ref:`aws_acm_info `. -* The ``aws_az_facts`` module was renamed to :ref:`aws_az_info `. -* The ``aws_caller_facts`` module was renamed to :ref:`aws_caller_info `. -* The ``aws_kms_facts`` module was renamed to :ref:`aws_kms_info `. -* The ``aws_region_facts`` module was renamed to :ref:`aws_region_info `. -* The ``aws_s3_bucket_facts`` module was renamed to :ref:`aws_s3_bucket_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``aws_sgw_facts`` module was renamed to :ref:`aws_sgw_info `. -* The ``aws_waf_facts`` module was renamed to :ref:`aws_waf_info `. -* The ``azure_rm_aks_facts`` module was renamed to :ref:`azure_rm_aks_info `. -* The ``azure_rm_aksversion_facts`` module was renamed to :ref:`azure_rm_aksversion_info `. -* The ``azure_rm_applicationsecuritygroup_facts`` module was renamed to :ref:`azure_rm_applicationsecuritygroup_info `. -* The ``azure_rm_appserviceplan_facts`` module was renamed to :ref:`azure_rm_appserviceplan_info `. -* The ``azure_rm_automationaccount_facts`` module was renamed to :ref:`azure_rm_automationaccount_info `. -* The ``azure_rm_autoscale_facts`` module was renamed to :ref:`azure_rm_autoscale_info `. -* The ``azure_rm_availabilityset_facts`` module was renamed to :ref:`azure_rm_availabilityset_info `. -* The ``azure_rm_cdnendpoint_facts`` module was renamed to :ref:`azure_rm_cdnendpoint_info `. -* The ``azure_rm_cdnprofile_facts`` module was renamed to :ref:`azure_rm_cdnprofile_info `. -* The ``azure_rm_containerinstance_facts`` module was renamed to :ref:`azure_rm_containerinstance_info `. -* The ``azure_rm_containerregistry_facts`` module was renamed to :ref:`azure_rm_containerregistry_info `. -* The ``azure_rm_cosmosdbaccount_facts`` module was renamed to :ref:`azure_rm_cosmosdbaccount_info `. -* The ``azure_rm_deployment_facts`` module was renamed to :ref:`azure_rm_deployment_info `. -* The ``azure_rm_resourcegroup_facts`` module was renamed to :ref:`azure_rm_resourcegroup_info `. -* The ``bigip_device_facts`` module was renamed to :ref:`bigip_device_info `. -* The ``bigiq_device_facts`` module was renamed to :ref:`bigiq_device_info `. -* The ``cloudformation_facts`` module was renamed to :ref:`cloudformation_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``cloudfront_facts`` module was renamed to :ref:`cloudfront_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``cloudwatchlogs_log_group_facts`` module was renamed to :ref:`cloudwatchlogs_log_group_info `. -* The ``digital_ocean_account_facts`` module was renamed to :ref:`digital_ocean_account_info `. -* The ``digital_ocean_certificate_facts`` module was renamed to :ref:`digital_ocean_certificate_info `. -* The ``digital_ocean_domain_facts`` module was renamed to :ref:`digital_ocean_domain_info `. -* The ``digital_ocean_firewall_facts`` module was renamed to :ref:`digital_ocean_firewall_info `. -* The ``digital_ocean_floating_ip_facts`` module was renamed to :ref:`digital_ocean_floating_ip_info `. -* The ``digital_ocean_image_facts`` module was renamed to :ref:`digital_ocean_image_info `. -* The ``digital_ocean_load_balancer_facts`` module was renamed to :ref:`digital_ocean_load_balancer_info `. -* The ``digital_ocean_region_facts`` module was renamed to :ref:`digital_ocean_region_info `. -* The ``digital_ocean_size_facts`` module was renamed to :ref:`digital_ocean_size_info `. -* The ``digital_ocean_snapshot_facts`` module was renamed to :ref:`digital_ocean_snapshot_info `. -* The ``digital_ocean_tag_facts`` module was renamed to :ref:`digital_ocean_tag_info `. -* The ``digital_ocean_volume_facts`` module was renamed to :ref:`digital_ocean_volume_info `. -* The ``ec2_ami_facts`` module was renamed to :ref:`ec2_ami_info `. -* The ``ec2_asg_facts`` module was renamed to :ref:`ec2_asg_info `. -* The ``ec2_customer_gateway_facts`` module was renamed to :ref:`ec2_customer_gateway_info `. -* The ``ec2_eip_facts`` module was renamed to :ref:`ec2_eip_info `. -* The ``ec2_elb_facts`` module was renamed to :ref:`ec2_elb_info `. -* The ``ec2_eni_facts`` module was renamed to :ref:`ec2_eni_info `. -* The ``ec2_group_facts`` module was renamed to :ref:`ec2_group_info `. -* The ``ec2_instance_facts`` module was renamed to :ref:`ec2_instance_info `. -* The ``ec2_lc_facts`` module was renamed to :ref:`ec2_lc_info `. -* The ``ec2_placement_group_facts`` module was renamed to :ref:`ec2_placement_group_info `. -* The ``ec2_snapshot_facts`` module was renamed to :ref:`ec2_snapshot_info `. -* The ``ec2_vol_facts`` module was renamed to :ref:`ec2_vol_info `. -* The ``ec2_vpc_dhcp_option_facts`` module was renamed to :ref:`ec2_vpc_dhcp_option_info `. -* The ``ec2_vpc_endpoint_facts`` module was renamed to :ref:`ec2_vpc_endpoint_info `. -* The ``ec2_vpc_igw_facts`` module was renamed to :ref:`ec2_vpc_igw_info `. -* The ``ec2_vpc_nacl_facts`` module was renamed to :ref:`ec2_vpc_nacl_info `. -* The ``ec2_vpc_nat_gateway_facts`` module was renamed to :ref:`ec2_vpc_nat_gateway_info `. -* The ``ec2_vpc_net_facts`` module was renamed to :ref:`ec2_vpc_net_info `. -* The ``ec2_vpc_peering_facts`` module was renamed to :ref:`ec2_vpc_peering_info `. -* The ``ec2_vpc_route_table_facts`` module was renamed to :ref:`ec2_vpc_route_table_info `. -* The ``ec2_vpc_subnet_facts`` module was renamed to :ref:`ec2_vpc_subnet_info `. -* The ``ec2_vpc_vgw_facts`` module was renamed to :ref:`ec2_vpc_vgw_info `. -* The ``ec2_vpc_vpn_facts`` module was renamed to :ref:`ec2_vpc_vpn_info `. -* The ``ecs_service_facts`` module was renamed to :ref:`ecs_service_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ecs_taskdefinition_facts`` module was renamed to :ref:`ecs_taskdefinition_info `. -* The ``efs_facts`` module was renamed to :ref:`efs_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``elasticache_facts`` module was renamed to :ref:`elasticache_info `. -* The ``elb_application_lb_facts`` module was renamed to :ref:`elb_application_lb_info `. -* The ``elb_classic_lb_facts`` module was renamed to :ref:`elb_classic_lb_info `. -* The ``elb_target_facts`` module was renamed to :ref:`elb_target_info `. -* The ``elb_target_group_facts`` module was renamed to :ref:`elb_target_group_info `. -* The ``gcp_bigquery_dataset_facts`` module was renamed to :ref:`gcp_bigquery_dataset_info `. -* The ``gcp_bigquery_table_facts`` module was renamed to :ref:`gcp_bigquery_table_info `. -* The ``gcp_cloudbuild_trigger_facts`` module was renamed to :ref:`gcp_cloudbuild_trigger_info `. -* The ``gcp_compute_address_facts`` module was renamed to :ref:`gcp_compute_address_info `. -* The ``gcp_compute_backend_bucket_facts`` module was renamed to :ref:`gcp_compute_backend_bucket_info `. -* The ``gcp_compute_backend_service_facts`` module was renamed to :ref:`gcp_compute_backend_service_info `. -* The ``gcp_compute_disk_facts`` module was renamed to :ref:`gcp_compute_disk_info `. -* The ``gcp_compute_firewall_facts`` module was renamed to :ref:`gcp_compute_firewall_info `. -* The ``gcp_compute_forwarding_rule_facts`` module was renamed to :ref:`gcp_compute_forwarding_rule_info `. -* The ``gcp_compute_global_address_facts`` module was renamed to :ref:`gcp_compute_global_address_info `. -* The ``gcp_compute_global_forwarding_rule_facts`` module was renamed to :ref:`gcp_compute_global_forwarding_rule_info `. -* The ``gcp_compute_health_check_facts`` module was renamed to :ref:`gcp_compute_health_check_info `. -* The ``gcp_compute_http_health_check_facts`` module was renamed to :ref:`gcp_compute_http_health_check_info `. -* The ``gcp_compute_https_health_check_facts`` module was renamed to :ref:`gcp_compute_https_health_check_info `. -* The ``gcp_compute_image_facts`` module was renamed to :ref:`gcp_compute_image_info `. -* The ``gcp_compute_instance_facts`` module was renamed to :ref:`gcp_compute_instance_info `. -* The ``gcp_compute_instance_group_facts`` module was renamed to :ref:`gcp_compute_instance_group_info `. -* The ``gcp_compute_instance_group_manager_facts`` module was renamed to :ref:`gcp_compute_instance_group_manager_info `. -* The ``gcp_compute_instance_template_facts`` module was renamed to :ref:`gcp_compute_instance_template_info `. -* The ``gcp_compute_interconnect_attachment_facts`` module was renamed to :ref:`gcp_compute_interconnect_attachment_info `. -* The ``gcp_compute_network_facts`` module was renamed to :ref:`gcp_compute_network_info `. -* The ``gcp_compute_region_disk_facts`` module was renamed to :ref:`gcp_compute_region_disk_info `. -* The ``gcp_compute_route_facts`` module was renamed to :ref:`gcp_compute_route_info `. -* The ``gcp_compute_router_facts`` module was renamed to :ref:`gcp_compute_router_info `. -* The ``gcp_compute_ssl_certificate_facts`` module was renamed to :ref:`gcp_compute_ssl_certificate_info `. -* The ``gcp_compute_ssl_policy_facts`` module was renamed to :ref:`gcp_compute_ssl_policy_info `. -* The ``gcp_compute_subnetwork_facts`` module was renamed to :ref:`gcp_compute_subnetwork_info `. -* The ``gcp_compute_target_http_proxy_facts`` module was renamed to :ref:`gcp_compute_target_http_proxy_info `. -* The ``gcp_compute_target_https_proxy_facts`` module was renamed to :ref:`gcp_compute_target_https_proxy_info `. -* The ``gcp_compute_target_pool_facts`` module was renamed to :ref:`gcp_compute_target_pool_info `. -* The ``gcp_compute_target_ssl_proxy_facts`` module was renamed to :ref:`gcp_compute_target_ssl_proxy_info `. -* The ``gcp_compute_target_tcp_proxy_facts`` module was renamed to :ref:`gcp_compute_target_tcp_proxy_info `. -* The ``gcp_compute_target_vpn_gateway_facts`` module was renamed to :ref:`gcp_compute_target_vpn_gateway_info `. -* The ``gcp_compute_url_map_facts`` module was renamed to :ref:`gcp_compute_url_map_info `. -* The ``gcp_compute_vpn_tunnel_facts`` module was renamed to :ref:`gcp_compute_vpn_tunnel_info `. -* The ``gcp_container_cluster_facts`` module was renamed to :ref:`gcp_container_cluster_info `. -* The ``gcp_container_node_pool_facts`` module was renamed to :ref:`gcp_container_node_pool_info `. -* The ``gcp_dns_managed_zone_facts`` module was renamed to :ref:`gcp_dns_managed_zone_info `. -* The ``gcp_dns_resource_record_set_facts`` module was renamed to :ref:`gcp_dns_resource_record_set_info `. -* The ``gcp_iam_role_facts`` module was renamed to :ref:`gcp_iam_role_info `. -* The ``gcp_iam_service_account_facts`` module was renamed to :ref:`gcp_iam_service_account_info `. -* The ``gcp_pubsub_subscription_facts`` module was renamed to :ref:`gcp_pubsub_subscription_info `. -* The ``gcp_pubsub_topic_facts`` module was renamed to :ref:`gcp_pubsub_topic_info `. -* The ``gcp_redis_instance_facts`` module was renamed to :ref:`gcp_redis_instance_info `. -* The ``gcp_resourcemanager_project_facts`` module was renamed to :ref:`gcp_resourcemanager_project_info `. -* The ``gcp_sourcerepo_repository_facts`` module was renamed to :ref:`gcp_sourcerepo_repository_info `. -* The ``gcp_spanner_database_facts`` module was renamed to :ref:`gcp_spanner_database_info `. -* The ``gcp_spanner_instance_facts`` module was renamed to :ref:`gcp_spanner_instance_info `. -* The ``gcp_sql_database_facts`` module was renamed to :ref:`gcp_sql_database_info `. -* The ``gcp_sql_instance_facts`` module was renamed to :ref:`gcp_sql_instance_info `. -* The ``gcp_sql_user_facts`` module was renamed to :ref:`gcp_sql_user_info `. -* The ``gcp_tpu_node_facts`` module was renamed to :ref:`gcp_tpu_node_info `. -* The ``gcpubsub_facts`` module was renamed to :ref:`gcpubsub_info `. -* The ``github_webhook_facts`` module was renamed to :ref:`github_webhook_info `. -* The ``gluster_heal_facts`` module was renamed to :ref:`gluster_heal_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_datacenter_facts`` module was renamed to :ref:`hcloud_datacenter_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_floating_ip_facts`` module was renamed to :ref:`hcloud_floating_ip_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_image_facts`` module was renamed to :ref:`hcloud_image_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_location_facts`` module was renamed to :ref:`hcloud_location_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_server_facts`` module was renamed to :ref:`hcloud_server_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_server_type_facts`` module was renamed to :ref:`hcloud_server_type_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_ssh_key_facts`` module was renamed to :ref:`hcloud_ssh_key_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_volume_facts`` module was renamed to :ref:`hcloud_volume_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hpilo_facts`` module was renamed to :ref:`hpilo_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``iam_mfa_device_facts`` module was renamed to :ref:`iam_mfa_device_info `. -* The ``iam_role_facts`` module was renamed to :ref:`iam_role_info `. -* The ``iam_server_certificate_facts`` module was renamed to :ref:`iam_server_certificate_info `. -* The ``idrac_redfish_facts`` module was renamed to :ref:`idrac_redfish_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``intersight_facts`` module was renamed to :ref:`intersight_info `. -* The ``jenkins_job_facts`` module was renamed to :ref:`jenkins_job_info `. -* The ``k8s_facts`` module was renamed to :ref:`k8s_info `. -* The ``memset_memstore_facts`` module was renamed to :ref:`memset_memstore_info `. -* The ``memset_server_facts`` module was renamed to :ref:`memset_server_info `. -* The ``one_image_facts`` module was renamed to :ref:`one_image_info `. -* The ``onepassword_facts`` module was renamed to :ref:`onepassword_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_datacenter_facts`` module was renamed to :ref:`oneview_datacenter_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_enclosure_facts`` module was renamed to :ref:`oneview_enclosure_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_ethernet_network_facts`` module was renamed to :ref:`oneview_ethernet_network_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_fc_network_facts`` module was renamed to :ref:`oneview_fc_network_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_fcoe_network_facts`` module was renamed to :ref:`oneview_fcoe_network_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_logical_interconnect_group_facts`` module was renamed to :ref:`oneview_logical_interconnect_group_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_network_set_facts`` module was renamed to :ref:`oneview_network_set_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_san_manager_facts`` module was renamed to :ref:`oneview_san_manager_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_flavor_facts`` module was renamed to :ref:`os_flavor_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_image_facts`` module was renamed to :ref:`os_image_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_keystone_domain_facts`` module was renamed to :ref:`os_keystone_domain_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_networks_facts`` module was renamed to :ref:`os_networks_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_port_facts`` module was renamed to :ref:`os_port_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_project_facts`` module was renamed to :ref:`os_project_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_server_facts`` module was renamed to :ref:`os_server_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_subnets_facts`` module was renamed to :ref:`os_subnets_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_user_facts`` module was renamed to :ref:`os_user_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_affinity_label_facts`` module was renamed to :ref:`ovirt_affinity_label_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_api_facts`` module was renamed to :ref:`ovirt_api_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_cluster_facts`` module was renamed to :ref:`ovirt_cluster_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_datacenter_facts`` module was renamed to :ref:`ovirt_datacenter_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_disk_facts`` module was renamed to :ref:`ovirt_disk_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_event_facts`` module was renamed to :ref:`ovirt_event_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_external_provider_facts`` module was renamed to :ref:`ovirt_external_provider_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_group_facts`` module was renamed to :ref:`ovirt_group_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_host_facts`` module was renamed to :ref:`ovirt_host_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_host_storage_facts`` module was renamed to :ref:`ovirt_host_storage_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_network_facts`` module was renamed to :ref:`ovirt_network_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_nic_facts`` module was renamed to :ref:`ovirt_nic_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_permission_facts`` module was renamed to :ref:`ovirt_permission_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_quota_facts`` module was renamed to :ref:`ovirt_quota_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_scheduling_policy_facts`` module was renamed to :ref:`ovirt_scheduling_policy_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_snapshot_facts`` module was renamed to :ref:`ovirt_snapshot_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_storage_domain_facts`` module was renamed to :ref:`ovirt_storage_domain_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_storage_template_facts`` module was renamed to :ref:`ovirt_storage_template_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_storage_vm_facts`` module was renamed to :ref:`ovirt_storage_vm_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_tag_facts`` module was renamed to :ref:`ovirt_tag_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_template_facts`` module was renamed to :ref:`ovirt_template_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_user_facts`` module was renamed to :ref:`ovirt_user_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_vm_facts`` module was renamed to :ref:`ovirt_vm_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_vmpool_facts`` module was renamed to :ref:`ovirt_vmpool_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``python_requirements_facts`` module was renamed to :ref:`python_requirements_info `. -* The ``rds_instance_facts`` module was renamed to :ref:`rds_instance_info `. -* The ``rds_snapshot_facts`` module was renamed to :ref:`rds_snapshot_info `. -* The ``redfish_facts`` module was renamed to :ref:`redfish_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``redshift_facts`` module was renamed to :ref:`redshift_info `. -* The ``route53_facts`` module was renamed to :ref:`route53_info `. -* The ``smartos_image_facts`` module was renamed to :ref:`smartos_image_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``vertica_facts`` module was renamed to :ref:`vertica_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``vmware_cluster_facts`` module was renamed to :ref:`vmware_cluster_info `. -* The ``vmware_datastore_facts`` module was renamed to :ref:`vmware_datastore_info `. -* The ``vmware_guest_facts`` module was renamed to :ref:`vmware_guest_info `. -* The ``vmware_guest_snapshot_facts`` module was renamed to :ref:`vmware_guest_snapshot_info `. -* The ``vmware_tag_facts`` module was renamed to :ref:`vmware_tag_info `. -* The ``vmware_vm_facts`` module was renamed to :ref:`vmware_vm_info `. -* The ``xenserver_guest_facts`` module was renamed to :ref:`xenserver_guest_info `. -* The ``zabbix_group_facts`` module was renamed to :ref:`zabbix_group_info `. -* The ``zabbix_host_facts`` module was renamed to :ref:`zabbix_host_info `. - -Noteworthy module changes -------------------------- - -* :ref:`vmware_cluster ` was refactored for easier maintenance/bugfixes. Use the three new, specialized modules to configure clusters. Configure DRS with :ref:`vmware_cluster_drs `, HA with :ref:`vmware_cluster_ha ` and vSAN with :ref:`vmware_cluster_vsan `. -* :ref:`vmware_dvswitch ` accepts ``folder`` parameter to place dvswitch in user defined folder. This option makes ``datacenter`` as an optional parameter. -* :ref:`vmware_datastore_cluster ` accepts ``folder`` parameter to place datastore cluster in user defined folder. This option makes ``datacenter`` as an optional parameter. -* :ref:`mysql_db ` returns new ``db_list`` parameter in addition to ``db`` parameter. This ``db_list`` parameter refers to list of database names. ``db`` parameter will be deprecated in version 2.13. -* :ref:`snow_record ` and :ref:`snow_record_find ` now takes environment variables for ``instance``, ``username`` and ``password`` parameters. This change marks these parameters as optional. -* The deprecated ``force`` option in ``win_firewall_rule`` has been removed. -* :ref:`openssl_certificate `'s ``ownca`` provider creates authority key identifiers if not explicitly disabled with ``ownca_create_authority_key_identifier: no``. This is only the case for the ``cryptography`` backend, which is selected by default if the ``cryptography`` library is available. -* :ref:`openssl_certificate `'s ``ownca`` and ``selfsigned`` providers create subject key identifiers if not explicitly disabled with ``ownca_create_subject_key_identifier: never_create`` resp. ``selfsigned_create_subject_key_identifier: never_create``. If a subject key identifier is provided by the CSR, it is taken; if not, it is created from the public key. This is only the case for the ``cryptography`` backend, which is selected by default if the ``cryptography`` library is available. -* :ref:`openssh_keypair ` now applies the same file permissions and ownership to both public and private keys (both get the same ``mode``, ``owner``, ``group``, and so on). If you need to change permissions / ownership on one key, use the :ref:`file ` to modify it after it is created. - - -Plugins -======= - -Removed Lookup Plugins ----------------------- - -* ``redis_kv`` use :ref:`redis ` instead. - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -Network resource modules ------------------------- - -Ansible 2.9 introduced the first batch of network resource modules. Sections of a network device's configuration can be thought of as a resource provided by that device. Network resource modules are intentionally scoped to configure a single resource and you can combine them as building blocks to configure complex network services. The older modules are deprecated in Ansible 2.9 and will be removed in Ansible 2.13. You should scan the list of deprecated modules above and replace them with the new network resource modules in your playbooks. See `Ansible Network Features in 2.9 `_ for details. - -Improved ``gather_facts`` support for network devices ------------------------------------------------------ - -In Ansible 2.9, the ``gather_facts`` keyword now supports gathering network device facts in standardized key/value pairs. You can feed these network facts into further tasks to manage the network device. You can also use the new ``gather_network_resources`` parameter with the network ``*_facts`` modules (such as :ref:`eos_facts `) to return just a subset of the device configuration. See :ref:`network_gather_facts` for an example. - -Top-level connection arguments removed in 2.9 ---------------------------------------------- - -Top-level connection arguments like ``username``, ``host``, and ``password`` are removed in version 2.9. - -**OLD** In Ansible < 2.4 - -.. code-block:: yaml - - - name: example of using top-level options for connection properties - ios_command: - commands: show version - host: "{{ inventory_hostname }}" - username: cisco - password: cisco - authorize: yes - auth_pass: cisco - - -Change your playbooks to the connection types ``network_cli`` and ``netconf`` using standard Ansible connection properties, and setting those properties in inventory by group. As you update your playbooks and inventory files, you can easily make the change to ``become`` for privilege escalation (on platforms that support it). For more information, see the :ref:`using become with network modules` guide and the :ref:`platform documentation`. diff --git a/docs/docsite/rst/porting_guides/porting_guide_3.rst b/docs/docsite/rst/porting_guides/porting_guide_3.rst deleted file mode 100644 index 12ec21cd08e..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_3.rst +++ /dev/null @@ -1,653 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_base_2.10.rst) - -.. _porting_3_guide: - -======================= -Ansible 3 Porting Guide -======================= - -.. contents:: - :local: - :depth: 2 - - -Ansible 3 is based on Ansible-Base 2.10, which is the same major release as Ansible 2.10. Therefore, there is no section on ansible-base in this porting guide. If you are upgrading from Ansible 2.9, please first consult the Ansible 2.10 porting guide before continuing with the Ansible 3 porting guide. - -We suggest you read this page along with the `Ansible 3 Changelog `_ to understand what updates you may need to make. - -Porting Guide for v3.4.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_configuration_compliance_info - Issue(195592) Module may error out with the message ``unable to process the request because an error occurred``. If the issue persists, report it to the system administrator. -- ome_smart_fabric - Issue(185322) Only three design types are supported by OpenManage Enterprise Modular but the module successfully creates a fabric when the design type is not supported. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Major Changes -------------- - -Ansible-base -~~~~~~~~~~~~ - -- ansible-test - Tests run with the ``centos6`` and ``default`` test containers now use a PyPI proxy container to access PyPI when Python 2.6 is used. This allows tests running under Python 2.6 to continue functioning even though PyPI is discontinuing support for non-SNI capable clients. - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_query - the default value of the ``as_single_query`` option will be changed to ``yes`` in community.postgresql 2.0.0 (https://github.com/ansible-collections/community.postgresql/issues/85). - -netapp.ontap -~~~~~~~~~~~~ - -- na_ontap_autosupport - Added REST support to the module. - -Deprecated Features -------------------- - -community.aws -~~~~~~~~~~~~~ - -- ec2_vpc_endpoint_info - the ``query`` option has been deprecated and will be removed after 2022-12-01 (https://github.com/ansible-collections/community.aws/pull/346). The ec2_vpc_endpoint_info now defaults to listing information about endpoints. The ability to search for information about available services has been moved to the dedicated module ``ec2_vpc_endpoint_service_info``. - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_* modules and plugins, except ``docker_swarm`` connection plugin and ``docker_compose`` and ``docker_stack*` modules - the current default ``localhost`` for ``tls_hostname`` is deprecated. In community.docker 2.0.0 it will be computed from ``docker_host`` instead (https://github.com/ansible-collections/community.docker/pull/134). - -Porting Guide for v3.3.0 -======================== - -Major Changes -------------- - -community.mysql -~~~~~~~~~~~~~~~ - -- mysql_user - the ``REQUIRESSL`` is an alias for the ``ssl`` key in the ``tls_requires`` option in ``community.mysql`` 2.0.0 and support will be dropped altogether in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/issues/121). - -Deprecated Features -------------------- - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_vmkernel_ip_config - deprecate in favor of vmware_vmkernel (https://github.com/ansible-collections/community.vmware/pull/667). - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Support for Python versions earlier than 3.5 is being deprecated - -Porting Guide for v3.2.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_configuration_compliance_info - Issue(195592) Module may error out with the message ``unable to process the request because an error occurred``. If the issue persists, report it to the system administrator. -- ome_smart_fabric - Issue(185322) Only three design types are supported by OpenManage Enterprise Modular but the module successfully creates a fabric when the design type is not supported. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Breaking Changes ----------------- - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_swarm - if ``join_token`` is specified, a returned join token with the same value will be replaced by ``VALUE_SPECIFIED_IN_NO_LOG_PARAMETER``. Make sure that you do not blindly use the join tokens from the return value of this module when the module is invoked with ``join_token`` specified! This breaking change appears in a minor release since it is necessary to fix a security issue (https://github.com/ansible-collections/community.docker/pull/103). - -Deprecated Features -------------------- - -community.crypto -~~~~~~~~~~~~~~~~ - -- acme module_utils - the ``acme`` module_utils (``ansible_collections.community.crypto.plugins.module_utils.acme``) is deprecated and will be removed in community.crypto 2.0.0. Use the new Python modules in the ``acme`` package instead (``ansible_collections.community.crypto.plugins.module_utils.acme.xxx``) (https://github.com/ansible-collections/community.crypto/pull/184). - -Porting Guide for v3.1.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- ome_smart_fabric - Issue(185322) Only three design types are supported by OpenManage Enterprise Modular but the module successfully creates a fabric when the design type is not supported. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Major Changes -------------- - -community.grafana -~~~~~~~~~~~~~~~~~ - -- introduce "skip_version_check" parameter in grafana_teams and grafana_folder modules (#147) - -community.mysql -~~~~~~~~~~~~~~~ - -- mysql_replication - the mode options values ``getslave``, ``startslave``, ``stopslave``, ``resetslave``, ``resetslaveall` and the master_use_gtid option ``slave_pos`` are deprecated (see the alternative values) and will be removed in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/pull/97). -- mysql_replication - the word ``SLAVE`` in messages returned by the module will be changed to ``REPLICA`` in ``community.mysql`` 2.0.0 (https://github.com/ansible-collections/community.mysql/issues/98). - -Removed Features ----------------- - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Removed TMOS v11 support for bigip_gtm_pool and bigip_gtm_wide_ip modules -- Removed quorum and monitor_type parameters in bigip_node module. See porting guides section at https://clouddocs.f5.com/products/orchestration/ansible/devel/usage/porting-guides.html -- Removed syslog_settings and pool_settings parameters in bigip_log_destination moduke. See porting guides section at https://clouddocs.f5.com/products/orchestration/ansible/devel/usage/porting-guides.html - -Deprecated Features -------------------- - -cloudscale_ch.cloud -~~~~~~~~~~~~~~~~~~~ - -- The aliases ``server_uuids`` and ``server_uuid`` of the servers parameter in the volume module will be removed in version 3.0.0. - -community.aws -~~~~~~~~~~~~~ - -- ec2_eip - formally deprecate the ``instance_id`` alias for ``device_id`` (https://github.com/ansible-collections/community.aws/pull/349). -- ec2_vpc_endpoint - deprecate the policy_file option and recommend using policy with a lookup (https://github.com/ansible-collections/community.aws/pull/366). - -community.crypto -~~~~~~~~~~~~~~~~ - -- acme_account_info - when ``retrieve_orders=url_list``, ``orders`` will no longer be returned in community.crypto 2.0.0. Use ``order_uris`` instead (https://github.com/ansible-collections/community.crypto/pull/178). - -community.general -~~~~~~~~~~~~~~~~~ - -- apt_rpm - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- composer - deprecated invalid parameter aliases ``working-dir``, ``global-command``, ``prefer-source``, ``prefer-dist``, ``no-dev``, ``no-scripts``, ``no-plugins``, ``optimize-autoloader``, ``classmap-authoritative``, ``apcu-autoloader``, ``ignore-platform-reqs``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- github_deploy_key - deprecated invalid parameter alias ``2fa_token``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- grove - the option ``message`` will be removed in community.general 4.0.0. Use the new option ``message_content`` instead (https://github.com/ansible-collections/community.general/pull/1929). -- homebrew - deprecated invalid parameter alias ``update-brew``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- homebrew_cask - deprecated invalid parameter alias ``update-brew``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- opkg - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- pacman - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- puppet - deprecated undocumented parameter ``show_diff``, will be removed in 7.0.0. (https://github.com/ansible-collections/community.general/pull/1927). -- runit - unused parameter ``dist`` marked for deprecation (https://github.com/ansible-collections/community.general/pull/1830). -- slackpkg - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- urpmi - deprecated invalid parameter aliases ``update-cache`` and ``no-recommends``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- xbps - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- xfconf - returning output as facts is deprecated, this will be removed in community.general 4.0.0. Please register the task output in a variable and use it instead. You can already switch to the new behavior now by using the new ``disable_facts`` option (https://github.com/ansible-collections/community.general/pull/1747). - -Porting Guide for v3.0.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- Issue 1(186024): ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. -- Issue 2(187956): If an invalid job_id is provided, idrac_lifecycle_controller_job_status_info returns an error message. This error message does not contain information about the exact issue with the invalid job_id. -- Issue 3(188267): While updating the iDRAC firmware, the idrac_firmware module completes execution before the firmware update job is completed. An incorrect message is displayed in the task output as 'DRAC WSMAN endpoint returned HTTP code '400' Reason 'Bad Request''. This issue may occur if the target iDRAC firmware version is less than 3.30.30.30 - -Breaking Changes ----------------- - -Ansible-base -~~~~~~~~~~~~ - -- ansible-galaxy login command has been removed ( see `issue 71560 `_) - -ansible.utils -~~~~~~~~~~~~~ - -- If added custom sub plugins in your collection move from old location `plugins/` to the new location `plugins/sub_plugins/` and update the imports as required -- Move sub plugins cli_parsers, fact_diff and validate to `plugins/sub_plugins` folder -- The `cli_parsers` sub plugins folder name is changed to `cli_parse` to have consistent naming convention, that is all the cli_parse subplugins will now be in `plugins/sub_plugins/cli_parse` folder - -cloudscale_ch.cloud -~~~~~~~~~~~~~~~~~~~ - -- floating_ip - ``name`` is required for assigning a new floating IP. - -community.general -~~~~~~~~~~~~~~~~~ - -- If you use Ansible 2.9 and the Google cloud plugins or modules from this collection, community.general 2.0.0 results in errors when trying to use the Google cloud content by FQCN, like ``community.general.gce_img``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.google.gce_img`` for the previous example) and to make sure that you have ``community.google`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install the ``community.google`` or ``google.cloud`` collections if you are using any of the Google cloud plugins or modules. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (such as community.google) must be installed for them to work. -- If you use Ansible 2.9 and the Kubevirt plugins or modules from this collection, community.general 2.0.0 results in errors when trying to use the Kubevirt content by FQCN, like ``community.general.kubevirt_vm``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.kubevirt.kubevirt_vm`` for the previous example) and to make sure that you have ``community.kubevirt`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install the ``community.kubevirt`` collection if you are using any of the Kubevirt plugins or modules. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (such as community.google) must be installed for them to work. -- If you use Ansible 2.9 and the ``docker`` plugins or modules from this collections, community.general 2.0.0 results in errors when trying to use the docker content by FQCN, like ``community.general.docker_container``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.docker.docker_container`` for the previous example) and to make sure that you have ``community.docker`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.docker`` if you are using any of the ``docker`` plugins or modules. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.docker) must be installed for them to work. -- If you use Ansible 2.9 and the ``hashi_vault`` lookup plugin from this collections, community.general 2.0.0 results in errors when trying to use the Hashi Vault content by FQCN, like ``community.general.hashi_vault``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your inventories, variable files, playbooks and roles manually to use the new FQCN (``community.hashi_vault.hashi_vault``) and to make sure that you have ``community.hashi_vault`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.hashi_vault`` if you are using the ``hashi_vault`` plugin. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.hashi_vault) must be installed for them to work. -- If you use Ansible 2.9 and the ``hetzner`` modules from this collections, community.general 2.0.0 results in errors when trying to use the hetzner content by FQCN, like ``community.general.hetzner_firewall``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.hrobot.firewall`` for the previous example) and to make sure that you have ``community.hrobot`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.hrobot`` if you are using any of the ``hetzner`` modules. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.hrobot) must be installed for them to work. -- If you use Ansible 2.9 and the ``oc`` connection plugin from this collections, community.general 2.0.0 results in errors when trying to use the oc content by FQCN, like ``community.general.oc``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your inventories, variable files, playbooks and roles manually to use the new FQCN (``community.okd.oc``) and to make sure that you have ``community.okd`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.okd`` if you are using the ``oc`` plugin. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.okd) must be installed for them to work. -- If you use Ansible 2.9 and the ``postgresql`` modules from this collections, community.general 2.0.0 results in errors when trying to use the postgresql content by FQCN, like ``community.general.postgresql_info``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.postgresql.postgresql_info`` for the previous example) and to make sure that you have ``community.postgresql`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.postgresql`` if you are using any of the ``postgresql`` modules. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.postgresql) must be installed for them to work. -- The Google cloud inventory script ``gce.py`` has been migrated to the ``community.google`` collection. Install the ``community.google`` collection in order to continue using it. -- archive - remove path folder itself when ``remove`` parameter is true (https://github.com/ansible-collections/community.general/issues/1041). -- log_plays callback - add missing information to the logs generated by the callback plugin. This changes the log message format (https://github.com/ansible-collections/community.general/pull/442). -- passwordstore lookup plugin - now parsing a password store entry as YAML if possible, skipping the first line (which by convention only contains the password and nothing else). If it cannot be parsed as YAML, the old ``key: value`` parser will be used to process the entry. Can break backwards compatibility if YAML formatted code was parsed in a non-YAML interpreted way, for example ``foo: [bar, baz]``, will become a list with two elements in the new version, but a string ``'[bar, baz]'`` in the old (https://github.com/ansible-collections/community.general/issues/1673). -- pkgng - passing ``name: *`` with ``state: absent`` will no longer remove every installed package from the system. It is now a noop. (https://github.com/ansible-collections/community.general/pull/569). -- pkgng - passing ``name: *`` with ``state: latest`` or ``state: present`` will no longer install every package from the configured package repositories. Instead, ``name: *, state: latest`` will upgrade all already-installed packages, and ``name: *, state: present`` is a noop. (https://github.com/ansible-collections/community.general/pull/569). -- proxmox_kvm - recognize ``force=yes`` in conjunction with ``state=absent`` to forcibly remove a running VM (https://github.com/ansible-collections/community.general/pull/849). -- utm_proxy_auth_profile - the ``frontend_cookie_secret`` return value now contains a placeholder string instead of the module's ``frontend_cookie_secret`` parameter (https://github.com/ansible-collections/community.general/pull/1736). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault - the ``VAULT_ADDR`` environment variable is now checked last for the ``url`` parameter. For details on which use cases are impacted, see (https://github.com/ansible-collections/community.hashi_vault/issues/8). - -community.hrobot -~~~~~~~~~~~~~~~~ - -- firewall - now requires the `ipaddress `_ library (https://github.com/ansible-collections/community.hrobot/pull/2). - -community.network -~~~~~~~~~~~~~~~~~ - -- If you use Ansible 2.9 and the FortiOS modules from this collection, community.network 2.0.0 results in errors when trying to use the FortiOS content by FQCN, like ``community.network.fmgr_device``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.fortios.fmgr_device`` for the previous example) and to make sure that you have ``community.fortios`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``community.fortios`` if you are using any of the FortiOS modules. - While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (community.fortios) must be installed for them to work. -- If you use Ansible 2.9 and the ``cp_publish`` module from this collection, community.network 2.0.0 results in errors when trying to use the module by FQCN, i.e. ``community.network.cp_publish``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``check_point.mgmt.cp_mgmt_publish``) and to make sure that you have ``check_point.mgmt`` installed. - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``check_point.mgmt`` if you are using the ``cp_publish`` module. While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (check_point.mgmt) must be installed for them to work. -- If you use Ansible 2.9 and the ``fortimanager`` httpapi plugin from this collection, community.network 2.0.0 results in errors when trying to use it by FQCN (``community.network.fortimanager``). - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCN ``fortinet.fortimanager.fortimanager`` and to make sure that you have ``fortinet.fortimanager`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``fortinet.fortimanager`` if you are using the ``fortimanager`` httpapi plugin. - While ansible-base 2.10 or newer can use the redirect that community.network 2.0.0 adds, the collection they point to (fortinet.fortimanager) must be installed for it to work. -- If you use Ansible 2.9 and the ``nso`` modules from this collection, community.network 2.0.0 results in errors when trying to use the nso content by FQCN, like ``community.network.nso_config``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``cisco.nso.nso_config`` for the previous example) and to make sure that you have ``cisco.nso`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``cisco.nso`` if you are using any of the ``nso`` modules. - While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (cisco.nso) must be installed for them to work. -- If you use Ansible 2.9 and the ``routeros`` plugins or modules from this collections, community.network 2.0.0 results in errors when trying to use the routeros content by FQCN, like ``community.network.routeros_command``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.routeros.command`` for the previous example) and to make sure that you have ``community.routeros`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``community.routeros`` if you are using any of the ``routeros`` plugins or modules. - While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (community.routeros) must be installed for them to work. -- cnos_static_route - move ipaddress import from ansible.netcommon to builtin or package before ipaddress is removed from ansible.netcommon. You need to make sure to have the ipaddress package installed if you are using this module on Python 2.7 (https://github.com/ansible-collections/community.network/pull/129). - -dellemc.os10 -~~~~~~~~~~~~ - -- os10_bgp - Changed "subnet" key as list format instead of dictionary format under "listen" key to support multiple neighbor prefix for listen command -- os10_bgp - Changed "vrf" key as list format instead of dictionary format to support multiple VRF in router BGP and changed the "vrf" key name to "vrfs" - -ngine_io.cloudstack -~~~~~~~~~~~~~~~~~~~ - -- Authentication option using INI files for example ``cloudstack.ini``, has been removed. The only supported option to authenticate is by using the module params with fallback to the ENV variables. -- default zone deprecation - The `zone` param default value, across multiple modules, has been deprecated due to unreliable API (https://github.com/ngine-io/ansible-collection-cloudstack/pull/62). - -Major Changes -------------- - -cisco.aci -~~~~~~~~~ - -- Change certificate_name to name in aci_aaa_user_certificate module for query operation - -community.general -~~~~~~~~~~~~~~~~~ - -- For community.general 3.0.0, the ``ome_device_info``, ``idrac_firmware`` and ``idrac_server_config_profile`` modules will be moved to the `dellemc.openmanage `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use the DellEMC modules mentioned above from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``dellemc.openmanage.`` instead of ``community.general.``, - for example replace ``community.general.ome_device_info`` in a task by ``dellemc.openmanage.ome_device_info``. - - If you use ansible-base and installed ``community.general`` manually and rely on the DellEMC modules mentioned above, you have to make sure to install the ``dellemc.openmanage`` collection as well. - If you are using FQCNs, for example ``community.general.ome_device_info`` instead of ``ome_device_info``, it will continue working, but we still recommend to adjust the FQCNs as well. -- The community.general collection no longer depends on the ansible.netcommon collection (https://github.com/ansible-collections/community.general/pull/1561). -- The community.general collection no longer depends on the ansible.posix collection (https://github.com/ansible-collections/community.general/pull/1157). - -community.kubernetes -~~~~~~~~~~~~~~~~~~~~ - -- k8s - Add support for template parameter (https://github.com/ansible-collections/community.kubernetes/pull/230). -- k8s_* - Add support for vaulted kubeconfig and src (https://github.com/ansible-collections/community.kubernetes/pull/193). - -community.okd -~~~~~~~~~~~~~ - -- Add custom k8s module, integrate better Molecule tests (https://github.com/ansible-collections/community.okd/pull/7). -- Add downstream build scripts to build redhat.openshift (https://github.com/ansible-collections/community.okd/pull/20). -- Add openshift connection plugin, update inventory plugin to use it (https://github.com/ansible-collections/community.okd/pull/18). -- Add openshift_process module for template rendering and optional application of rendered resources (https://github.com/ansible-collections/community.okd/pull/44). -- Add openshift_route module for creating routes from services (https://github.com/ansible-collections/community.okd/pull/40). -- Initial content migration from community.kubernetes (https://github.com/ansible-collections/community.okd/pull/3). -- openshift_auth - new module (migrated from k8s_auth in community.kubernetes) (https://github.com/ansible-collections/community.okd/pull/33). - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- Removed the existing deprecated modules. -- Standardization of ten iDRAC ansible modules based on ansible guidelines. -- Support for OpenManage Enterprise Modular. - -dellemc.os10 -~~~~~~~~~~~~ - -- os10_bgp - Enhanced router bgp keyword support for non-default vrf which are supported for default vrf and additional keyword to support both default and non-default vrf -- os10_snmp role - Added support for snmp V3 features in community, group, host, engineID - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Add phone home Teem integration into all modules, functionality can be disabled by setting up F5_TEEM environment variable or no_f5_teem provider parameter -- Added async_timeout parameter to bigip_ucs_fetch module to allow customization of module wait for async interface -- Changed bigip_ucs_fetch module to use asynchronous interface when generating UCS files - -kubernetes.core -~~~~~~~~~~~~~~~ - -- Add changelog and fragments and document changelog process (https://github.com/ansible-collections/kubernetes.core/pull/131). -- helm - New module for managing Helm charts (https://github.com/ansible-collections/kubernetes.core/pull/61). -- helm_info - New module for retrieving Helm chart information (https://github.com/ansible-collections/kubernetes.core/pull/61). -- helm_plugin - new module to manage Helm plugins (https://github.com/ansible-collections/kubernetes.core/pull/154). -- helm_plugin_info - new modules to gather information about Helm plugins (https://github.com/ansible-collections/kubernetes.core/pull/154). -- helm_repository - New module for managing Helm repositories (https://github.com/ansible-collections/kubernetes.core/pull/61). -- k8s - Add support for template parameter (https://github.com/ansible-collections/kubernetes.core/pull/230). -- k8s - Inventory source migrated from Ansible 2.9 to Kubernetes collection. -- k8s - Lookup plugin migrated from Ansible 2.9 to Kubernetes collection. -- k8s - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_* - Add support for vaulted kubeconfig and src (https://github.com/ansible-collections/kubernetes.core/pull/193). -- k8s_auth - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_config_resource_name - Filter plugin migrated from Ansible 2.9 to Kubernetes collection. -- k8s_exec - New module for executing commands on pods through Kubernetes API (https://github.com/ansible-collections/kubernetes.core/pull/14). -- k8s_exec - Return rc for the command executed (https://github.com/ansible-collections/kubernetes.core/pull/158). -- k8s_info - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_log - New module for retrieving pod logs (https://github.com/ansible-collections/kubernetes.core/pull/16). -- k8s_scale - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_service - Module migrated from Ansible 2.9 to Kubernetes collection. -- kubectl - Connection plugin migrated from Ansible 2.9 to Kubernetes collection. -- openshift - Inventory source migrated from Ansible 2.9 to Kubernetes collection. - -netbox.netbox -~~~~~~~~~~~~~ - -- nb_inventory - Add ``dns_name`` option that adds ``dns_name`` to the host when ``True`` and device has a primary IP address. (#394) -- nb_inventory - Add ``status`` as a ``group_by`` option. (398) -- nb_inventory - Move around ``extracted_primary_ip`` to allow for ``config_context`` or ``custom_field`` to overwrite. (#377) -- nb_inventory - Services are now a list of integers due to NetBox 2.10 changes. (#396) -- nb_lookup - Allow ID to be passed in and use ``.get`` instead of ``.filter``. (#376) -- nb_lookup - Allow ``api_endpoint`` and ``token`` to be found through env. (#391) - -ovirt.ovirt -~~~~~~~~~~~ - -- cluster_upgrade - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/94). -- disaster_recovery - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/134). -- engine_setup - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/69). -- hosted_engine_setup - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/106). -- image_template - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/95). -- infra - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/92). -- manageiq - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/97). -- ovirt_system_option_info - Add new module (https://github.com/oVirt/ovirt-ansible-collection/pull/206). -- repositories - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/96). -- shutdown_env - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/112). -- vm_infra - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/93). - -servicenow.servicenow -~~~~~~~~~~~~~~~~~~~~~ - -- add new tests (find with no result, search many) -- add related tests -- add support for ServiceNOW table api display_value exclude_reference_link and suppress_pagination_header -- use new API for pysnow >=0.6.0 - -Removed Features ----------------- - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_container - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_container - the default of ``networks_cli_compatible`` changed to ``true`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_container - the unused option ``trust_image_content`` has been removed (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - ``state=build`` has been removed. Use ``present`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``container_limits``, ``dockerfile``, ``http_timeout``, ``nocache``, ``rm``, ``path``, ``buildargs``, ``pull`` have been removed. Use the corresponding suboptions of ``build`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``force`` option has been removed. Use the more specific ``force_*`` options instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``source`` option is now mandatory (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``use_tls`` option has been removed. Use ``tls`` and ``validate_certs`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the default of the ``build.pull`` option changed to ``false`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image_facts - this alias is on longer available, use ``docker_image_info`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_network - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_network - the ``ipam_options`` option has been removed. Use ``ipam_config`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_service - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm - ``state=inspect`` has been removed. Use ``docker_swarm_info`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``constraints`` option has been removed. Use ``placement.constraints`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``limit_cpu`` and ``limit_memory`` options has been removed. Use the corresponding suboptions in ``limits`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``log_driver`` and ``log_driver_options`` options has been removed. Use the corresponding suboptions in ``logging`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``reserve_cpu`` and ``reserve_memory`` options has been removed. Use the corresponding suboptions in ``reservations`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``restart_policy``, ``restart_policy_attempts``, ``restart_policy_delay`` and ``restart_policy_window`` options has been removed. Use the corresponding suboptions in ``restart_config`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``update_delay``, ``update_parallelism``, ``update_failure_action``, ``update_monitor``, ``update_max_failure_ratio`` and ``update_order`` options has been removed. Use the corresponding suboptions in ``update_config`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_volume - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_volume - the ``force`` option has been removed. Use ``recreate`` instead (https://github.com/ansible-collections/community.docker/pull/1). - -community.general -~~~~~~~~~~~~~~~~~ - -- All Google cloud modules and plugins have now been migrated away from this collection. - They can be found in either the `community.google `_ or `google.cloud `_ collections. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.gce_img`` → ``community.google.gce_img``) and make sure to install the community.google or google.cloud collections as appropriate. -- All Kubevirt modules and plugins have now been migrated from community.general to the `community.kubevirt `_ Ansible collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.kubevirt_vm`` → ``community.kubevirt.kubevirt_vm``) and make sure to install the community.kubevirt collection. -- All ``docker`` modules and plugins have been removed from this collection. - They have been migrated to the `community.docker `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.docker_container`` → ``community.docker.docker_container``) and make sure to install the community.docker collection. -- All ``hetzner`` modules have been removed from this collection. - They have been migrated to the `community.hrobot `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.hetzner_firewall`` → ``community.hrobot.firewall``) and make sure to install the community.hrobot collection. -- All ``postgresql`` modules have been removed from this collection. - They have been migrated to the `community.postgresql `_ collection. - - If you use ansible-base 2.10 or newer, redirections have been provided. - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.postgresql_info`` → ``community.postgresql.postgresql_info``) and make sure to install the community.postgresql collection. -- The Google cloud inventory script ``gce.py`` has been migrated to the ``community.google`` collection. Install the ``community.google`` collection in order to continue using it. -- The ``hashi_vault`` lookup plugin has been removed from this collection. - It has been migrated to the `community.hashi_vault `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.hashi_vault`` → ``community.hashi_vault.hashi_vault``) and make sure to install the community.hashi_vault collection. -- The ``oc`` connection plugin has been removed from this collection. - It has been migrated to the `community.okd `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.oc`` → ``community.okd.oc``) and make sure to install the community.okd collection. -- The deprecated ``actionable`` callback plugin has been removed. Use the ``ansible.builtin.default`` callback plugin with ``display_skipped_hosts = no`` and ``display_ok_hosts = no`` options instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``foreman`` module has been removed. Use the modules from the theforeman.foreman collection instead (https://github.com/ansible-collections/community.general/pull/1347) (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``full_skip`` callback plugin has been removed. Use the ``ansible.builtin.default`` callback plugin with ``display_skipped_hosts = no`` option instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``gcdns_record`` module has been removed. Use ``google.cloud.gcp_dns_resource_record_set`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcdns_zone`` module has been removed. Use ``google.cloud.gcp_dns_managed_zone`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gce`` module has been removed. Use ``google.cloud.gcp_compute_instance`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcp_backend_service`` module has been removed. Use ``google.cloud.gcp_compute_backend_service`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcp_forwarding_rule`` module has been removed. Use ``google.cloud.gcp_compute_forwarding_rule`` or ``google.cloud.gcp_compute_global_forwarding_rule`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcp_healthcheck`` module has been removed. Use ``google.cloud.gcp_compute_health_check``, ``google.cloud.gcp_compute_http_health_check`` or ``google.cloud.gcp_compute_https_health_check`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcp_target_proxy`` module has been removed. Use ``google.cloud.gcp_compute_target_http_proxy`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcp_url_map`` module has been removed. Use ``google.cloud.gcp_compute_url_map`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcspanner`` module has been removed. Use ``google.cloud.gcp_spanner_database`` and/or ``google.cloud.gcp_spanner_instance`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``github_hooks`` module has been removed. Use ``community.general.github_webhook`` and ``community.general.github_webhook_info`` instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``katello`` module has been removed. Use the modules from the theforeman.foreman collection instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_aggregate`` module has been removed. Use netapp.ontap.na_ontap_aggregate instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_license`` module has been removed. Use netapp.ontap.na_ontap_license instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_lun`` module has been removed. Use netapp.ontap.na_ontap_lun instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_qtree`` module has been removed. Use netapp.ontap.na_ontap_qtree instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_svm`` module has been removed. Use netapp.ontap.na_ontap_svm instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_user_role`` module has been removed. Use netapp.ontap.na_ontap_user_role instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_user`` module has been removed. Use netapp.ontap.na_ontap_user instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_volume`` module has been removed. Use netapp.ontap.na_ontap_volume instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``sf_account_manager`` module has been removed. Use netapp.elementsw.na_elementsw_account instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``sf_check_connections`` module has been removed. Use netapp.elementsw.na_elementsw_check_connections instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``sf_snapshot_schedule_manager`` module has been removed. Use netapp.elementsw.na_elementsw_snapshot_schedule instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``sf_volume_access_group_manager`` module has been removed. Use netapp.elementsw.na_elementsw_access_group instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``sf_volume_manager`` module has been removed. Use netapp.elementsw.na_elementsw_volume instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``stderr`` callback plugin has been removed. Use the ``ansible.builtin.default`` callback plugin with ``display_failed_stderr = yes`` option instead (https://github.com/ansible-collections/community.general/pull/1347). -- The redirect of the ``conjur_variable`` lookup plugin to ``cyberark.conjur.conjur_variable`` collection was removed (https://github.com/ansible-collections/community.general/pull/1346). -- The redirect of the ``firewalld`` module and the ``firewalld`` module_utils to the ``ansible.posix`` collection was removed (https://github.com/ansible-collections/community.general/pull/1346). -- The redirect to the ``community.digitalocean`` collection was removed for: the ``digital_ocean`` doc fragment, the ``digital_ocean`` module_utils, and the following modules: ``digital_ocean``, ``digital_ocean_account_facts``, ``digital_ocean_account_info``, ``digital_ocean_block_storage``, ``digital_ocean_certificate``, ``digital_ocean_certificate_facts``, ``digital_ocean_certificate_info``, ``digital_ocean_domain``, ``digital_ocean_domain_facts``, ``digital_ocean_domain_info``, ``digital_ocean_droplet``, ``digital_ocean_firewall_facts``, ``digital_ocean_firewall_info``, ``digital_ocean_floating_ip``, ``digital_ocean_floating_ip_facts``, ``digital_ocean_floating_ip_info``, ``digital_ocean_image_facts``, ``digital_ocean_image_info``, ``digital_ocean_load_balancer_facts``, ``digital_ocean_load_balancer_info``, ``digital_ocean_region_facts``, ``digital_ocean_region_info``, ``digital_ocean_size_facts``, ``digital_ocean_size_info``, ``digital_ocean_snapshot_facts``, ``digital_ocean_snapshot_info``, ``digital_ocean_sshkey``, ``digital_ocean_sshkey_facts``, ``digital_ocean_sshkey_info``, ``digital_ocean_tag``, ``digital_ocean_tag_facts``, ``digital_ocean_tag_info``, ``digital_ocean_volume_facts``, ``digital_ocean_volume_info`` (https://github.com/ansible-collections/community.general/pull/1346). -- The redirect to the ``community.mysql`` collection was removed for: the ``mysql`` doc fragment, the ``mysql`` module_utils, and the following modules: ``mysql_db``, ``mysql_info``, ``mysql_query``, ``mysql_replication``, ``mysql_user``, ``mysql_variables`` (https://github.com/ansible-collections/community.general/pull/1346). -- The redirect to the ``community.proxysql`` collection was removed for: the ``proxysql`` doc fragment, and the following modules: ``proxysql_backend_servers``, ``proxysql_global_variables``, ``proxysql_manage_config``, ``proxysql_mysql_users``, ``proxysql_query_rules``, ``proxysql_replication_hostgroups``, ``proxysql_scheduler`` (https://github.com/ansible-collections/community.general/pull/1346). -- The redirect to the ``infinidat.infinibox`` collection was removed for: the ``infinibox`` doc fragment, the ``infinibox`` module_utils, and the following modules: ``infini_export``, ``infini_export_client``, ``infini_fs``, ``infini_host``, ``infini_pool``, ``infini_vol`` (https://github.com/ansible-collections/community.general/pull/1346). -- conjur_variable lookup - has been moved to the ``cyberark.conjur`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/570). -- digital_ocean_* - all DigitalOcean modules have been moved to the ``community.digitalocean`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/622). -- infini_* - all infinidat modules have been moved to the ``infinidat.infinibox`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/607). -- iptables_state - the ``ANSIBLE_ASYNC_DIR`` environment is no longer supported, use the ``async_dir`` shell option instead (https://github.com/ansible-collections/community.general/pull/1371). -- logicmonitor - the module has been removed in 1.0.0 since it is unmaintained and the API used by the module has been turned off in 2017 (https://github.com/ansible-collections/community.general/issues/539, https://github.com/ansible-collections/community.general/pull/541). -- logicmonitor_facts - the module has been removed in 1.0.0 since it is unmaintained and the API used by the module has been turned off in 2017 (https://github.com/ansible-collections/community.general/issues/539, https://github.com/ansible-collections/community.general/pull/541). -- memcached cache plugin - do not import ``CacheModule``s directly. Use ``ansible.plugins.loader.cache_loader`` instead (https://github.com/ansible-collections/community.general/pull/1371). -- mysql_* - all MySQL modules have been moved to the ``community.mysql`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/633). -- proxysql_* - all ProxySQL modules have been moved to the ``community.proxysql`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/624). -- redis cache plugin - do not import ``CacheModule``s directly. Use ``ansible.plugins.loader.cache_loader`` instead (https://github.com/ansible-collections/community.general/pull/1371). -- xml - when ``content=attribute``, the ``attribute`` option is ignored (https://github.com/ansible-collections/community.general/pull/1371). - -community.network -~~~~~~~~~~~~~~~~~ - -- All FortiOS modules and plugins have been removed from this collection. - They have been migrated to the `community.fortios `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.fmgr_device`` → ``community.fortios.fmgr_device``) and make sure to install the `community.fortios` collection. -- All ``nso`` modules have been removed from this collection. - They have been migrated to the `cisco.nso `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.nso_config`` → ``cisco.nso.nso_config``) and make sure to install the `cisco.nso` collection. -- All ``routeros`` modules and plugins have been removed from this collection. - They have been migrated to the `community.routeros `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.routeros_command`` → ``community.routeros.command``) and make sure to install the community.routeros collection. -- The ``cp_publish`` module has been removed from this collection. It was a duplicate of ``check_point.mgmt.cp_mgmt_publish`` in the `check_point.mgmt `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided. - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.cp_publish`` → ``check_point.mgmt.cp_mgmt_publish``) and make sure to install the check_point.mgmt collection. -- The ``fortimanager`` httpapi plugin has been removed from this collection. - It was a duplicate of the one in the `fortinet.fortimanager `_ collection. - If you use ansible-base 2.10 or newer, a redirection has been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.fortimanager`` → ``fortinet.fortimanager.fortimanager``) and make sure to install the `fortinet.fortimanager` collection. -- The dependency on the ``check_point.mgmt`` collection has been removed. If you depend on that installing ``community.network`` also installs ``check_point.mgmt``, you have to make sure to install ``check_point.mgmt`` explicitly. -- The deprecated Pluribus Networks modules ``pn_cluster``, ``pn_ospf``, ``pn_ospfarea``, ``pn_show``, ``pn_trunk``, ``pn_vlag``, ``pn_vlan``, ``pn_vrouter``, ``pn_vrouterbgp``, ``pn_vrouterif``, ``pn_vrouterlbif`` have been removed (https://github.com/ansible-collections/community.network/pull/176). -- The deprecated modules ``panos_admin``, ``panos_admpwd``, ``panos_cert_gen_ssh``, ``panos_check``, ``panos_commit``, ``panos_dag``, ``panos_dag_tags``, ``panos_import``, ``panos_interface``, ``panos_lic``, ``panos_loadcfg``, ``panos_match_rule``, ``panos_mgtconfig``, ``panos_nat_rule``, ``panos_object``, ``panos_op``, ``panos_pg``, ``panos_query_rules``, ``panos_restart``, ``panos_sag``, ``panos_security_rule``, ``panos_set`` have been removed. Use modules from the `paloaltonetworks.panos collection `_ instead (https://github.com/ansible-collections/community.network/pull/176). -- The redirect to the ``mellanox.onyx`` collection was removed for: the ``onyx`` cliconf plugin, terminal plugin, module_utils, action plugin, doc fragment, and the following modules: ``onyx_aaa``, ``onyx_bfd``, ``onyx_bgp``, ``onyx_buffer_pool``, ``onyx_command``, ``onyx_config``, ``onyx_facts``, ``onyx_igmp``, ``onyx_igmp_interface``, ``onyx_igmp_vlan``, ``onyx_interface``, ``onyx_l2_interface``, ``onyx_l3_interface``, ``onyx_linkagg``, ``onyx_lldp``, ``onyx_lldp_interface``, ``onyx_magp``, ``onyx_mlag_ipl``, ``onyx_mlag_vip``, ``onyx_ntp``, ``onyx_ntp_servers_peers``, ``onyx_ospf``, ``onyx_pfc_interface``, ``onyx_protocol``, ``onyx_ptp_global``, ``onyx_ptp_interface``, ``onyx_qos``, ``onyx_snmp``, ``onyx_snmp_hosts``, ``onyx_snmp_users``, ``onyx_syslog_files``, ``onyx_syslog_remote``, ``onyx_traffic_class``, ``onyx_username``, ``onyx_vlan``, ``onyx_vxlan``, ``onyx_wjh`` (https://github.com/ansible-collections/community.network/pull/175). -- onyx - all onyx modules and plugins have been moved to the mellanox.onyx collection. Redirects have been added that will be removed in community.network 2.0.0 (https://github.com/ansible-collections/community.network/pull/83). - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Removed arp_state parameter from the bigip_virtual_address module - -Deprecated Features -------------------- - -cisco.nxos -~~~~~~~~~~ - -- Deprecated `nxos_bgp` and `nxos_bgp_neighbor` modules in favor of `nxos_bgp_global` resource module. -- Deprecated `nxos_interface_ospf` in favor of `nxos_ospf_interfaces` Resource Module. -- Deprecated `nxos_smu` in favor of `nxos_rpm` module. -- The `nxos_ospf_vrf` module is deprecated by `nxos_ospfv2` and `nxos_ospfv3` Resource Modules. - -community.aws -~~~~~~~~~~~~~ - -- ec2_vpc_igw_info - After 2022-06-22 the ``convert_tags`` parameter default value will change from ``False`` to ``True`` to match the collection standard behavior (https://github.com/ansible-collections/community.aws/pull/318). - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_container - currently ``published_ports`` can contain port mappings next to the special value ``all``, in which case the port mappings are ignored. This behavior is deprecated for community.docker 2.0.0, at which point it will either be forbidden, or this behavior will be properly implemented similar to how the Docker CLI tool handles this (https://github.com/ansible-collections/community.docker/issues/8, https://github.com/ansible-collections/community.docker/pull/60). - -community.general -~~~~~~~~~~~~~~~~~ - -- The ``gluster_heal_info``, ``gluster_peer`` and ``gluster_volume`` modules have migrated to the `gluster.gluster `_ collection. Ansible-base 2.10.1 adjusted the routing target to point to the modules in that collection, so we will remove these modules in community.general 3.0.0. If you use Ansible 2.9, or use FQCNs ``community.general.gluster_*`` in your playbooks and/or roles, please update them to use the modules from ``gluster.gluster`` instead. -- The ldap_attr module has been deprecated and will be removed in a later release; use ldap_attrs instead. -- django_manage - the parameter ``liveserver`` relates to a no longer maintained third-party module for django. It is now deprecated, and will be remove in community.general 3.0.0 (https://github.com/ansible-collections/community.general/pull/1154). -- proxmox - the default of the new ``proxmox_default_behavior`` option will change from ``compatibility`` to ``no_defaults`` in community.general 4.0.0. Set the option to an explicit value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/850). -- proxmox_kvm - the default of the new ``proxmox_default_behavior`` option will change from ``compatibility`` to ``no_defaults`` in community.general 4.0.0. Set the option to an explicit value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/850). -- syspatch - deprecate the redundant ``apply`` argument (https://github.com/ansible-collections/community.general/pull/360). -- xbps - the ``force`` option never had any effect. It is now deprecated, and will be removed in 3.0.0 (https://github.com/ansible-collections/community.general/pull/568). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault - ``VAULT_ADDR`` environment variable for option ``url`` will have its precedence lowered in 1.0.0; use ``ANSIBLE_HASHI_VAULT_ADDR`` to intentionally override a config value (https://github.com/ansible-collections/community.hashi_vault/issues/8). -- hashi_vault - ``VAULT_AUTH_METHOD`` environment variable for option ``auth_method`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_AUTH_METHOD`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/17). -- hashi_vault - ``VAULT_ROLE_ID`` environment variable for option ``role_id`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_ROLE_ID`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/20). -- hashi_vault - ``VAULT_SECRET_ID`` environment variable for option ``secret_id`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_SECRET_ID`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/20). -- hashi_vault - ``VAULT_TOKEN_FILE`` environment variable for option ``token_file`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_TOKEN_FILE`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/15). -- hashi_vault - ``VAULT_TOKEN_PATH`` environment variable for option ``token_path`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_TOKEN_PATH`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/15). - -community.network -~~~~~~~~~~~~~~~~~ - -- Deprecate connection=local support for network platforms using persistent framework (https://github.com/ansible-collections/community.network/pull/120). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_host_firewall_manager - the creation of new rule with no ``allowed_ip`` entry in the ``allowed_hosts`` dictionary won't be allowed after 2.0.0 release. - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- The ``dellemc_get_firmware_inventory`` module is deprecated and replaced with ``idrac_firmware_info``. -- The ``dellemc_get_system_inventory`` module is deprecated and replaced with ``idrac_system_info``. -- The dellemc_change_power_state module is deprecated and replaced with the redfish_powerstate module. -- The dellemc_configure_bios module is deprecated and replaced with the idrac_bios module. -- The dellemc_configure_idrac_network module is deprecated and replaced with the idrac_network module. -- The dellemc_configure_idrac_timezone module is deprecated and replaced with the idrac_timezone_ntp module. -- The dellemc_configure_idrac_users module is deprecated and replaced with the idrac_user module. -- The dellemc_delete_lc_job and dellemc_delete_lc_job_queue modules are deprecated and replaced with the idrac_lifecycle_controller_jobs module. -- The dellemc_export_lc_logs module is deprecated and replaced with the idrac_lifecycle_controller_logs module. -- The dellemc_get_lc_job_status module is deprecated and replaced with the idrac_lifecycle_controller_job_status_info module. -- The dellemc_get_lcstatus module is deprecated and replaced with the idrac_lifecycle_controller_status_info module. -- The dellemc_idrac_reset module is deprecated and replaced with the idrac_reset module. -- The dellemc_setup_idrac_syslog module is deprecated and replaced with the idrac_syslog module. diff --git a/docs/docsite/rst/porting_guides/porting_guide_4.rst b/docs/docsite/rst/porting_guides/porting_guide_4.rst deleted file mode 100644 index 5f45910b4f0..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_4.rst +++ /dev/null @@ -1,894 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_base_2.11.rst) - -.. _porting_4_guide: - -======================= -Ansible 4 Porting Guide -======================= - -.. contents:: - :local: - :depth: 2 - - -We suggest you read this page along with the `Ansible 4 Changelog `_ to understand what updates you may need to make. - -Playbook -======== - -* The ``jinja2_native`` setting now does not affect the template module which implicitly returns strings. For the template lookup there is a new argument ``jinja2_native`` (off by default) to control that functionality. The rest of the Jinja2 expressions still operate based on the ``jinja2_native`` setting. - - -Command Line -============ - -* The ``ansible-galaxy login`` command has been removed, as the underlying API it used for GitHub auth has been shut down. Publishing roles or collections to Galaxy with ``ansible-galaxy`` now requires that a Galaxy API token be passed to the CLI using a token file (default location ``~/.ansible/galaxy_token``) or (insecurely) with the ``--token`` argument to ``ansible-galaxy``. - - -Deprecated -========== - -The constant ``ansible.module_utils.basic._CHECK_ARGUMENT_TYPES_DISPATCHER`` is deprecated. Use :const:`ansible.module_utils.common.parameters.DEFAULT_TYPE_VALIDATORS` instead. - - -Breaking Changes -================ - -Changes to ``AnsibleModule`` ----------------------------- - -With the move to :class:`ArgumentSpecValidator ` for performing argument spec validation, the following private methods in :class:`AnsibleModule ` have been removed: - - - ``_check_argument_types()`` - - ``_check_argument_values()`` - - ``_check_arguments()`` - - ``_check_mutually_exclusive()`` --> :func:`ansible.module_utils.common.validation.check_mutually_exclusive` - - ``_check_required_arguments()`` --> :func:`ansible.module_utils.common.validation.check_required_arguments` - - ``_check_required_by()`` --> :func:`ansible.module_utils.common.validation.check_required_by` - - ``_check_required_if()`` --> :func:`ansible.module_utils.common.validation.check_required_if` - - ``_check_required_one_of()`` --> :func:`ansible.module_utils.common.validation.check_required_one_of` - - ``_check_required_together()`` --> :func:`ansible.module_utils.common.validation.check_required_together` - - ``_check_type_bits()`` --> :func:`ansible.module_utils.common.validation.check_type_bits` - - ``_check_type_bool()`` --> :func:`ansible.module_utils.common.validation.check_type_bool` - - ``_check_type_bytes()`` --> :func:`ansible.module_utils.common.validation.check_type_bytes` - - ``_check_type_dict()`` --> :func:`ansible.module_utils.common.validation.check_type_dict` - - ``_check_type_float()`` --> :func:`ansible.module_utils.common.validation.check_type_float` - - ``_check_type_int()`` --> :func:`ansible.module_utils.common.validation.check_type_int` - - ``_check_type_jsonarg()`` --> :func:`ansible.module_utils.common.validation.check_type_jsonarg` - - ``_check_type_list()`` --> :func:`ansible.module_utils.common.validation.check_type_list` - - ``_check_type_path()`` --> :func:`ansible.module_utils.common.validation.check_type_path` - - ``_check_type_raw()`` --> :func:`ansible.module_utils.common.validation.check_type_raw` - - ``_check_type_str()`` --> :func:`ansible.module_utils.common.validation.check_type_str` - - ``_count_terms()`` --> :func:`ansible.module_utils.common.validation.count_terms` - - ``_get_wanted_type()`` - - ``_handle_aliases()`` - - ``_handle_no_log_values()`` - - ``_handle_options()`` - - ``_set_defaults()`` - - ``_set_fallbacks()`` - -Modules or plugins using these private methods should use the public functions in :mod:`ansible.module_utils.common.validation` or :meth:`ArgumentSpecValidator.validate() ` if no public function was listed above. - - -Changes to :mod:`ansible.module_utils.common.parameters` --------------------------------------------------------- - -The following functions in :mod:`ansible.module_utils.common.parameters` are now private and should not be used directly. Use :meth:`ArgumentSpecValidator.validate() ` instead. - - - ``list_no_log_values`` - - ``list_deprecations`` - - ``handle_aliases`` - - -Other -====== - -* **Upgrading**: If upgrading from ``ansible < 2.10`` or from ``ansible-base`` and using pip, you must ``pip uninstall ansible`` or ``pip uninstall ansible-base`` before installing ``ansible-core`` to avoid conflicts. -* Python 3.8 on the controller node is a soft requirement for this release. ``ansible-core`` 2.11 still works with the same versions of Python that ``ansible-base`` 2.10 worked with, however 2.11 emits a warning when running on a controller node with a Python version less than 3.8. This warning can be disabled by setting ``ANSIBLE_CONTROLLER_PYTHON_WARNING=False`` in your environment. ``ansible-core`` 2.12 will require Python 3.8 or greater. -* The configuration system now validates the ``choices`` field, so any settings that violate it and were ignored in 2.10 cause an error in 2.11. For example, ``ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH=0`` now causes an error (valid choices are ``ignore``, ``warn`` or ``error``). -* The ``ansible-galaxy`` command now uses ``resolvelib`` for resolving dependencies. In most cases this should not make a user-facing difference beyond being more performant, but we note it here for posterity and completeness. -* If you import Python ``module_utils`` into any modules you maintain, you may now mark the import as optional during the module payload build by wrapping the ``import`` statement in a ``try`` or ``if`` block. This allows modules to use ``module_utils`` that may not be present in all versions of Ansible or a collection, and to perform arbitrary recovery or fallback actions during module runtime. - - -Modules -======= - -* The ``apt_key`` module has explicitly defined ``file`` as mutually exclusive with ``data``, ``keyserver`` and ``url``. They cannot be used together anymore. -* The ``meta`` module now supports tags for user-defined tasks. Set the task's tags to 'always' to maintain the previous behavior. Internal ``meta`` tasks continue to always run. - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -* facts - On NetBSD, ``ansible_virtualization_type`` now tries to report a more accurate result than ``xen`` when virtualized and not running on Xen. -* facts - Virtualization facts now include ``virtualization_tech_guest`` and ``virtualization_tech_host`` keys. These are lists of virtualization technologies that a guest is a part of, or that a host provides, respectively. As an example, if you set up a host to provide both KVM and VirtualBox, both values are included in ``virtualization_tech_host``. Similarly, a podman container running on a VM powered by KVM has a ``virtualization_tech_guest`` of ``["kvm", "podman", "container"]``. -* The parameter ``filter`` type is changed from ``string`` to ``list`` in the :ref:`setup ` module in order to use more than one filter. Previous behavior (using a ``string``) still remains and works as a single filter. - - -Plugins -======= - -* inventory plugins - ``CachePluginAdjudicator.flush()`` now calls the underlying cache plugin's ``flush()`` instead of only deleting keys that it knows about. Inventory plugins should use ``delete()`` to remove any specific keys. As a user, this means that when an inventory plugin calls its ``clear_cache()`` method, facts could also be flushed from the cache. To work around this, users can configure inventory plugins to use a cache backend that is independent of the facts cache. -* callback plugins - ``meta`` task execution is now sent to ``v2_playbook_on_task_start`` like any other task. By default, only explicit meta tasks are sent there. Callback plugins can opt-in to receiving internal, implicitly created tasks to act on those as well, as noted in the plugin development documentation. -* The ``choices`` are now validated, so plugins that were using incorrect or incomplete choices issue an error in 2.11 if the value provided does not match. This has a simple fix: update the entries in ``choices`` to match reality. - -Porting custom scripts -====================== - -No notable changes - -Porting Guide for v4.10.0 -========================= - -Major Changes -------------- - -containers.podman -~~~~~~~~~~~~~~~~~ - -- Add podman_tag module -- Add secrets driver and driver opts support - -Deprecated Features -------------------- - -cisco.nxos -~~~~~~~~~~ - -- Deprecated nxos_snmp_community module. -- Deprecated nxos_snmp_contact module. -- Deprecated nxos_snmp_host module. -- Deprecated nxos_snmp_location module. -- Deprecated nxos_snmp_traps module. -- Deprecated nxos_snmp_user module. - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resource module. - -Porting Guide for v4.9.0 -======================== - -Known Issues ------------- - -purestorage.flashblade -~~~~~~~~~~~~~~~~~~~~~~ - -- purefb_lag - The mac_address field in the response is not populated. This will be fixed in a future FlashBlade update. - -Major Changes -------------- - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Add real-world use cases in the example section for some configuration modules. -- Collect the current configurations of the modules and convert them into playbooks. -- Support FortiOS 7.0.1. -- Support member operation (delete/add extra members) on an object that has a list of members in it. -- Support selectors feature in ``fortios_monitor_fact`` and ``fortios_log_fact``. - -Porting Guide for v4.8.0 -======================== - -Breaking Changes ----------------- - -community.zabbix -~~~~~~~~~~~~~~~~ - -- all roles now reference other roles and modules through their fully qualified collection names, which makes Ansible 2.10 minimum supported version for roles (see `issue 477 `_). - -Deprecated Features -------------------- - -community.azure -~~~~~~~~~~~~~~~ - -- All community.azure.azure_rm__facts modules are deprecated. Use azure.azcollection.azure_rm__info modules instead (https://github.com/ansible-collections/community.azure/pull/24). -- All community.azure.azure_rm__info modules are deprecated. Use azure.azcollection.azure_rm__info modules instead (https://github.com/ansible-collections/community.azure/pull/24). -- community.azure.azure_rm_managed_disk and community.azure.azure_rm_manageddisk are deprecated. Use azure.azcollection.azure_rm_manageddisk instead (https://github.com/ansible-collections/community.azure/pull/24). -- community.azure.azure_rm_virtualmachine_extension and community.azure.azure_rm_virtualmachineextension are deprecated. Use azure.azcollection.azure_rm_virtualmachineextension instead (https://github.com/ansible-collections/community.azure/pull/24). -- community.azure.azure_rm_virtualmachine_scaleset and community.azure.azure_rm_virtualmachinescaleset are deprecated. Use azure.azcollection.azure_rm_virtualmachinescaleset instead (https://github.com/ansible-collections/community.azure/pull/24). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- lookup hashi_vault - the ``[lookup_hashi_vault]`` section in the ``ansible.cfg`` file is deprecated and will be removed in collection version ``3.0.0``. Instead, the section ``[hashi_vault_collection]`` can be used, which will apply to all plugins in the collection going forward (https://github.com/ansible-collections/community.hashi_vault/pull/144). - -Porting Guide for v4.7.0 -======================== - -Major Changes -------------- - -openvswitch.openvswitch -~~~~~~~~~~~~~~~~~~~~~~~ - -- By mistake we tagged the repo to 2.0.0 and as it wasn't intended and cannot be reverted we're releasing 2.0.1 to make the community aware of the major version update. - -Deprecated Features -------------------- - -cisco.ios -~~~~~~~~~ - -- Deprecated ios_ntp modules. - -cisco.nxos -~~~~~~~~~~ - -- Deprecated `nxos_ntp`, `nxos_ntp_options`, `nxos_ntp_auth` modules. - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_guest_vnc - Sphere 7.0 removed the built-in VNC server (https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-vcenter-server-70-release-notes.html#productsupport). - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Deprecated router_id from ospfv2 resource module. - -Porting Guide for v4.6.0 -======================== - -Major Changes -------------- - -containers.podman -~~~~~~~~~~~~~~~~~ - -- Add systemd generation for pods -- Generate systemd service files for containers - -gluster.gluster -~~~~~~~~~~~~~~~ - -- enable client.ssl,server.ssl before starting the gluster volume (https://github.com/gluster/gluster-ansible-collection/pull/19) - -Deprecated Features -------------------- - -community.grafana -~~~~~~~~~~~~~~~~~ - -- grafana_dashboard lookup - Providing a mangled version of the API key is no longer preferred. - -Porting Guide for v4.5.0 -======================== - -Major Changes -------------- - -hetzner.hcloud -~~~~~~~~~~~~~~ - -- Introduction of placement groups - -ovirt.ovirt -~~~~~~~~~~~ - -- remove_stale_lun - Add role for removing stale LUN (https://bugzilla.redhat.com/1966873). - -Deprecated Features -------------------- - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- network_cli - The paramiko_ssh setting ``look_for_keys`` was set automatically based on the values of the ``password`` and ``private_key_file`` options passed to network_cli. This option can now be set explicitly, and the automatic setting of ``look_for_keys`` will be removed after 2024-01-01 (https://github.com/ansible-collections/ansible.netcommon/pull/271). - -cisco.ios -~~~~~~~~~ - -- Deprecated ios_bgp in favor of ios_bgp_global and ios_bgp_address_family. -- Remove testing with provider for ansible-test integration jobs. This helps prepare us to move to network-ee integration tests. - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Deprecated router_id from ospfv3 resource module. - -Porting Guide for v4.4.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. - -Deprecated Features -------------------- - -cisco.iosxr -~~~~~~~~~~~ - -- The iosxr_logging module has been deprecated in favor of the new iosxr_logging_global resource module and will be removed in a release after '2023-08-01'. - -cisco.nxos -~~~~~~~~~~ - -- The nxos_logging module has been deprecated in favor of the new nxos_logging_global resource module and will be removed in a release after '2023-08-01'. - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_container - the new ``command_handling``'s default value, ``compatibility``, is deprecated and will change to ``correct`` in community.docker 3.0.0. A deprecation warning is emitted by the module in cases where the behavior will change. Please note that ansible-core will output a deprecation warning only once, so if it is shown for an earlier task, there could be more tasks with this warning where it is not shown (https://github.com/ansible-collections/community.docker/pull/186). - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- The junos_logging module has been deprecated in favor of the new junos_logging_global resource module and will be removed in a release after '2023-08-01'. - -vyos.vyos -~~~~~~~~~ - -- The vyos_logging module has been deprecated in favor of the new vyos_logging_global resource module and will be removed in a release after "2023-08-01". - -Porting Guide for v4.3.0 -======================== - -Major Changes -------------- - -netapp.cloudmanager -~~~~~~~~~~~~~~~~~~~ - -- Adding stage environment to all modules in cloudmanager - -Deprecated Features -------------------- - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault collection - support for Python 3.5 will be dropped in version ``2.0.0`` of ``community.hashi_vault`` (https://github.com/ansible-collections/community.hashi_vault/issues/81). - -Porting Guide for v4.2.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Major Changes -------------- - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_object_custom_attributes_info - added a new module to gather custom attributes of an object (https://github.com/ansible-collections/community.vmware/pull/851). - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_server_config_profile - Added support for exporting and importing Server Configuration Profile through HTTP/HTTPS share. -- ome_device_group - Added support for adding devices to a group using the IP addresses of the devices and group ID. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- New module fortios_monitor_fact. -- Support Fortios 7.0. -- Support Log APIs. - -Deprecated Features -------------------- - -- The community.kubernetes collection is being renamed to kubernetes.core. In Ansible 5, community.kubernetes will be replaced by an empty collection which has deprecated redirects for all the current content to kubernetes.core. If you are using FQCNs starting with ``community.kubernetes.``, please update them to ``kubernetes.core.`` now. Note that kubernetes.core has been included in Ansible since Ansible 3.0.0 (https://github.com/ansible-community/community-topics/issues/22). - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_updates - Deprecated the ``filtered_reason`` return value for each filtered up in favour of ``filtered_reasons``. This has been done to show all the reasons why an update was filtered and not just the first reason. -- win_updates - Deprecated the ``use_scheduled_task`` option as it is no longer used. -- win_updates - Deprecated the ``whitelist`` and ``blacklist`` options in favour of ``accept_list`` and ``reject_list`` respectively to conform to the new standards used in Ansible for these types of options. - -community.general -~~~~~~~~~~~~~~~~~ - -- ali_instance_info - marked removal version of deprecated parameters ``availability_zone`` and ``instance_names`` (https://github.com/ansible-collections/community.general/issues/2429). -- serverless - deprecating parameter ``functions`` because it was not used in the code (https://github.com/ansible-collections/community.general/pull/2845). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault collection - support for Python 2 will be dropped in version ``2.0.0`` of ``community.hashi_vault`` (https://github.com/ansible-collections/community.hashi_vault/issues/81). - -Porting Guide for v4.1.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Major Changes -------------- - -cloudscale_ch.cloud -~~~~~~~~~~~~~~~~~~~ - -- Add custom_image module - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_query - the default value of the ``as_single_query`` option will be changed to ``yes`` in community.postgresql 2.0.0 (https://github.com/ansible-collections/community.postgresql/issues/85). - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- ome_firmware_baseline - Module supports check mode, and allows the modification and deletion of firmware baselines. -- ome_firmware_catalog - Module supports check mode, and allows the modification and deletion of firmware catalogs. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Improve ``fortios_configuration_fact`` to use multiple selectors concurrently. -- Support ``check_mode`` in all cofigurationAPI-based modules. -- Support filtering for fact gathering modules ``fortios_configuration_fact`` and ``fortios_monitor_fact``. -- Support moving policy in ``firewall_central_snat_map``. -- Unify schemas for monitor API. - -netbox.netbox -~~~~~~~~~~~~~ - -- packages is now a required Python package and gets installed through Ansible 2.10+. - -Removed Features ----------------- - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_reboot - Removed ``shutdown_timeout`` and ``shutdown_timeout_sec`` which has not done anything since Ansible 2.5. - -Deprecated Features -------------------- - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_reboot - Unreachable hosts can be ignored with ``ignore_errors: True``, this ability will be removed in a future version. Use ``ignore_unreachable: True`` to ignore unreachable hosts instead. - https://github.com/ansible-collections/ansible.windows/issues/62 - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_* modules and plugins, except ``docker_swarm`` connection plugin and ``docker_compose`` and ``docker_stack*` modules - the current default ``localhost`` for ``tls_hostname`` is deprecated. In community.docker 2.0.0 it will be computed from ``docker_host`` instead (https://github.com/ansible-collections/community.docker/pull/134). - -community.general -~~~~~~~~~~~~~~~~~ - -- All inventory and vault scripts will be removed from community.general in version 4.0.0. If you are referencing them, please update your references to the new `contrib-scripts GitHub repository `_ so your workflow will not break once community.general 4.0.0 is released (https://github.com/ansible-collections/community.general/pull/2697). -- The nios, nios_next_ip, nios_next_network lookup plugins, the nios documentation fragment, and the nios_host_record, nios_ptr_record, nios_mx_record, nios_fixed_address, nios_zone, nios_member, nios_a_record, nios_aaaa_record, nios_network, nios_dns_view, nios_txt_record, nios_naptr_record, nios_srv_record, nios_cname_record, nios_nsgroup, and nios_network_view module have been deprecated and will be removed from community.general 5.0.0. Please install the `infoblox.nios_modules `_ collection instead and use its plugins and modules (https://github.com/ansible-collections/community.general/pull/2458). -- The vendored copy of ``ipaddress`` will be removed in community.general 4.0.0. Please switch to ``ipaddress`` from the Python 3 standard library, or `from pypi `_, if your code relies on the vendored version of ``ipaddress`` (https://github.com/ansible-collections/community.general/pull/2459). -- linode - parameter ``backupsenabled`` is deprecated and will be removed in community.general 5.0.0 (https://github.com/ansible-collections/community.general/pull/2410). -- lxd inventory plugin - the plugin will require ``ipaddress`` installed when used with Python 2 from community.general 4.0.0 on. ``ipaddress`` is part of the Python 3 standard library, but can be installed for Python 2 from pypi (https://github.com/ansible-collections/community.general/pull/2459). -- scaleway_security_group_rule - the module will require ``ipaddress`` installed when used with Python 2 from community.general 4.0.0 on. ``ipaddress`` is part of the Python 3 standard library, but can be installed for Python 2 from pypi (https://github.com/ansible-collections/community.general/pull/2459). - -inspur.sm -~~~~~~~~~ - -- add_ad_group - This feature will be removed in inspur.sm.add_ad_group 3.0.0. replaced with inspur.sm.ad_group. -- add_ldap_group - This feature will be removed in inspur.sm.add_ldap_group 3.0.0. replaced with inspur.sm.ldap_group. -- add_user - This feature will be removed in inspur.sm.add_user 3.0.0. replaced with inspur.sm.user. -- add_user_group - This feature will be removed in inspur.sm.add_user_group 3.0.0. replaced with inspur.sm.user_group. -- del_ad_group - This feature will be removed in inspur.sm.del_ad_group 3.0.0. replaced with inspur.sm.ad_group. -- del_ldap_group - This feature will be removed in inspur.sm.del_ldap_group 3.0.0. replaced with inspur.sm.ldap_group. -- del_user - This feature will be removed in inspur.sm.del_user 3.0.0. replaced with inspur.sm.user. -- del_user_group - This feature will be removed in inspur.sm.del_user_group 3.0.0. replaced with inspur.sm.user_group. -- edit_ad_group - This feature will be removed in inspur.sm.edit_ad_group 3.0.0. replaced with inspur.sm.ad_group. -- edit_ldap_group - This feature will be removed in inspur.sm.edit_ldap_group 3.0.0. replaced with inspur.sm.ldap_group. -- edit_user - This feature will be removed in inspur.sm.edit_user 3.0.0. replaced with inspur.sm.user. -- edit_user_group - This feature will be removed in inspur.sm.edit_user_group 3.0.0. replaced with inspur.sm.user_group. - -Porting Guide for v4.0.0 -======================== - -Known Issues ------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - The ``pylint`` sanity test no longer correctly detects "bad" variable names for non-constants. See `issue 3701 `_ for additional details. - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_configuration_compliance_info - Issue(195592) Module may error out with the message ``unable to process the request because an error occurred``. If the issue persists, report it to the system administrator. -- ome_smart_fabric - Issue(185322) Only three design types are supported by OpenManage Enterprise Modular but the module successfully creates a fabric when the design type is not supported. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Modules for monitor API are not versioned yet. - -Breaking Changes ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- Made SCM collections be reinstalled regardless of ``--force`` being present. -- NetBSD virtualization facts (specifically ``ansible_virtualization_type``) now returns a more accurate value by checking the value of the ``machdep.hypervisor`` ``sysctl`` key. This change is breaking because in some cases previously, we would erroneously report ``xen`` even when the target is not running on Xen. This prevents that behavior in most cases. (https://github.com/ansible/ansible/issues/69352) -- Replaced the in-tree dependency resolver with an external implementation that pip >= 20.3 uses now by default — ``resolvelib``. (https://github.com/ansible/ansible/issues/71784) -- The ``meta`` module now supports tags for user-defined tasks. Internal ``meta`` tasks continue to always run. (https://github.com/ansible/ansible/issues/64558) -- ansible-galaxy login command has been removed (see `issue 71560 `_) - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- Removed vendored ipaddress package from collection. If you use ansible_collections.ansible.netcommon.plugins.module_utils.compat.ipaddress in your collection, you will need to change this to import ipaddress instead. If your content using ipaddress supports Python 2.7, you will additionally need to make sure that the user has the ipaddress package installed. Please refer to https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_best_practices.html#importing-and-using-shared-code to see how to safely import external packages that may be missing from the user's system A backport of ipaddress for Python 2.7 is available at https://pypi.org/project/ipaddress/ - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_swarm - if ``join_token`` is specified, a returned join token with the same value will be replaced by ``VALUE_SPECIFIED_IN_NO_LOG_PARAMETER``. Make sure that you do not blindly use the join tokens from the return value of this module when the module is invoked with ``join_token`` specified! This breaking change appears in a minor release since it is necessary to fix a security issue (https://github.com/ansible-collections/community.docker/pull/103). - -community.general -~~~~~~~~~~~~~~~~~ - -- If you use Ansible 2.9 and these plugins or modules from this collection, community.general 3.0.0 results in errors when trying to use the DellEMC content by FQCN, like ``community.general.idrac_firmware``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``dellemc.openmanage.idrac_firmware`` for the previous example) and to make sure that you have ``dellemc.openmanage`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 4.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install the ``dellemc.openmanage`` collection if you are using any of these plugins or modules. - While ansible-base 2.10 or newer can use the redirects that community.general 3.0.0 adds, the collection they point to (such as dellemc.openmanage) must be installed for them to work. -- gitlab_deploy_key - if for an already existing key title a different public key was given as parameter nothing happened, now this changed so that the public key is updated to the new value (https://github.com/ansible-collections/community.general/pull/1661). -- java_keystore - instead of failing, now overwrites keystore if the alias (name) is changed. This was originally the intended behavior, but did not work due to a logic error. Make sure that your playbooks and roles do not depend on the old behavior of failing instead of overwriting (https://github.com/ansible-collections/community.general/issues/1671). -- java_keystore - instead of failing, now overwrites keystore if the passphrase is changed. Make sure that your playbooks and roles do not depend on the old behavior of failing instead of overwriting (https://github.com/ansible-collections/community.general/issues/1671). -- one_image - use pyone instead of python-oca (https://github.com/ansible-collections/community.general/pull/2032). -- utm_proxy_auth_profile - the ``frontend_cookie_secret`` return value now contains a placeholder string instead of the module's ``frontend_cookie_secret`` parameter (https://github.com/ansible-collections/community.general/pull/1736). - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Generic FortiOS Module - FOS module to issue generic request with Ansible. -- Support for FOS Monitor API - several modules are new for monitor API. -- Unified Collection - The fortios collection itself will be adapting any FOS platforms. - -servicenow.servicenow -~~~~~~~~~~~~~~~~~~~~~ - -- auth field now required for anything other than Basic authentication - -theforeman.foreman -~~~~~~~~~~~~~~~~~~ - -- All role variables are now prefixed with ``foreman_`` to avoid clashes with similarly named variables from roles outside this collection. - -Major Changes -------------- - -Ansible-core -~~~~~~~~~~~~ - -- A collection can be reinstalled with new version requirements without using the ``--force`` flag. The collection's dependencies will also be updated if necessary with the new requirements. Use ``--upgrade`` to force transitive dependency updates. -- AnsibleModule - use ``ArgumentSpecValidator`` class for validating argument spec and remove private methods related to argument spec validation. Any modules using private methods should now use the ``ArgumentSpecValidator`` class or the appropriate validation function. -- Declared ``resolvelib >= 0.5.3, < 0.6.0`` a direct dependency of - ansible-core. Refs: - - https://github.com/sarugaku/resolvelib - - https://pypi.org/p/resolvelib - - https://pradyunsg.me/blog/2020/03/27/pip-resolver-testing -- It became possible to install Ansible Collections from local folders and namespaces folder similar to SCM structure with multiple collections. -- It became possible to upgrade Ansible collections from Galaxy servers using the ``--upgrade`` option with ``ansible-galaxy collection install``. -- Support for role argument specification validation at role execution time. When a role contains an argument spec, an implicit validation task is inserted at the start of role execution. -- add ``ArgumentSpecValidator`` class for validating parameters against an argument spec outside of ``AnsibleModule`` (https://github.com/ansible/ansible/pull/73335) -- ansible-test - Tests run with the ``centos6`` and ``default`` test containers now use a PyPI proxy container to access PyPI when Python 2.6 is used. This allows tests running under Python 2.6 to continue functioning even though PyPI is discontinuing support for non-SNI capable clients. - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- Remove deprecated connection arguments from netconf_config - -arista.eos -~~~~~~~~~~ - -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules` - Please refer to ansible.netcommon `changelog `_ for more details. - -cisco.asa -~~~~~~~~~ - -- Please refer to ansible.netcommon `changelog ` for more details. -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules`. - -cisco.ios -~~~~~~~~~ - -- Please refer to ansible.netcommon `changelog `_ for more details. -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules`. - -cisco.iosxr -~~~~~~~~~~~ - -- Please refer to ansible.netcommon `changelog `_ for more details. -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules`. -- ipaddress is no longer in ansible.netcommon. For Python versions without ipaddress (< 3.0), the ipaddress package is now required. - -cisco.nxos -~~~~~~~~~~ - -- Please refer to ansible.netcommon `changelog `_ for more details. -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules`. - -community.grafana -~~~~~~~~~~~~~~~~~ - -- introduce "skip_version_check" parameter in grafana_teams and grafana_folder modules (#147) - -community.mysql -~~~~~~~~~~~~~~~ - -- mysql_replication - add deprecation warning that the ``Is_Slave`` and ``Is_Master`` return values will be replaced with ``Is_Primary`` and ``Is_Replica`` in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/pull/147). -- mysql_replication - the choices of the ``state`` option containing ``master`` will be finally replaced with the alternative ``primary`` choices in ``community.mysql`` 3.0.0, add deprecation warnings (https://github.com/ansible-collections/community.mysql/pull/150). -- mysql_replication - the mode options values ``getslave``, ``startslave``, ``stopslave``, ``resetslave``, ``resetslaveall` and the master_use_gtid option ``slave_pos`` are deprecated (see the alternative values) and will be removed in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/pull/97). -- mysql_replication - the return value ``Is_Slave`` and ``Is_Master`` will be replaced with ``Is_Replica`` and ``Is_Primary`` in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/issues/145). -- mysql_replication - the word ``SLAVE`` in messages returned by the module will be changed to ``REPLICA`` in ``community.mysql`` 2.0.0 (https://github.com/ansible-collections/community.mysql/issues/98). -- mysql_replication - the word ``master`` in messages returned by the module will be replaced with ``primary`` in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/issues/145). -- mysql_replication - the word ``slave`` in messages returned by the module replaced with ``replica`` (https://github.com/ansible-collections/community.mysql/issues/98). -- mysql_user - the ``REQUIRESSL`` is an alias for the ``ssl`` key in the ``tls_requires`` option in ``community.mysql`` 2.0.0 and support will be dropped altogether in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/issues/121). - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- New module fortios_configuration_fact -- New module fortios_json_generic -- New module fortios_monitor -- New module fortios_monitor_fact - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Please refer to ansible.netcommon `changelog `_ for more details. -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules`. - -netapp.ontap -~~~~~~~~~~~~ - -- na_ontap_autosupport - Added REST support to the module. - -openvswitch.openvswitch -~~~~~~~~~~~~~~~~~~~~~~~ - -- There is no major changes for this particular release and it was tagged by mistake and cannot be reverted. - -servicenow.servicenow -~~~~~~~~~~~~~~~~~~~~~ - -- refactored client to inherit from AnsibleModule -- supports OpenID Connect authentication protocol -- supports bearer tokens for authentication - -vyos.vyos -~~~~~~~~~ - -- Please refer to ansible.netcommon `changelog `_ for more details. -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules` -- ipaddress is no longer in ansible.netcommon. For Python versions without ipaddress (< 3.0), the ipaddress package is now required. - -Removed Features ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- Removed `SharedPluginLoaderObj` class from ansible.plugins.strategy. It was deprecated in favor of using the standard plugin loader. -- Removed `_get_item()` alias from callback plugin base class which had been deprecated in favor of `_get_item_label()`. -- The "user" parameter was previously deprecated and is now removed in favor of "scope" -- The deprecated ``ansible.constants.BECOME_METHODS`` has been removed. -- The deprecated ``ansible.constants.get_config()`` has been removed. -- The deprecated ``ansible.constants.mk_boolean()`` has been removed. -- `with_*` loops are no longer optimized for modules whose `name` parameters can take lists (mostly package managers). Use `name` instead of looping over individual names with `with_items` and friends. - -community.general -~~~~~~~~~~~~~~~~~ - -- The ``ome_device_info``, ``idrac_firmware`` and ``idrac_server_config_profile`` modules have now been migrated from community.general to the `dellemc.openmanage `_ Ansible collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.idrac_firmware`` → ``dellemc.openmanage.idrac_firmware``) and make sure to install the dellemc.openmanage collection. -- The deprecated ali_instance_facts module has been removed. Use ali_instance_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated gluster_heal_info module has been removed. Use gluster.gluster.gluster_heal_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated gluster_peer module has been removed. Use gluster.gluster.gluster_peer instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated gluster_volume module has been removed. Use gluster.gluster.gluster_volume instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated helm module has been removed. Use community.kubernetes.helm instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated hpilo_facts module has been removed. Use hpilo_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated idrac_redfish_facts module has been removed. Use idrac_redfish_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated jenkins_job_facts module has been removed. Use jenkins_job_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ldap_attr module has been removed. Use ldap_attrs instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated memset_memstore_facts module has been removed. Use memset_memstore_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated memset_server_facts module has been removed. Use memset_server_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated na_ontap_gather_facts module has been removed. Use netapp.ontap.na_ontap_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated nginx_status_facts module has been removed. Use nginx_status_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated one_image_facts module has been removed. Use one_image_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated onepassword_facts module has been removed. Use onepassword_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_datacenter_facts module has been removed. Use oneview_datacenter_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_enclosure_facts module has been removed. Use oneview_enclosure_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_ethernet_network_facts module has been removed. Use oneview_ethernet_network_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_fc_network_facts module has been removed. Use oneview_fc_network_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_fcoe_network_facts module has been removed. Use oneview_fcoe_network_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_logical_interconnect_group_facts module has been removed. Use oneview_logical_interconnect_group_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_network_set_facts module has been removed. Use oneview_network_set_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_san_manager_facts module has been removed. Use oneview_san_manager_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated online_server_facts module has been removed. Use online_server_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated online_user_facts module has been removed. Use online_user_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt module has been removed. Use ovirt.ovirt.ovirt_vm instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_affinity_label_facts module has been removed. Use ovirt.ovirt.ovirt_affinity_label_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_api_facts module has been removed. Use ovirt.ovirt.ovirt_api_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_cluster_facts module has been removed. Use ovirt.ovirt.ovirt_cluster_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_datacenter_facts module has been removed. Use ovirt.ovirt.ovirt_datacenter_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_disk_facts module has been removed. Use ovirt.ovirt.ovirt_disk_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_event_facts module has been removed. Use ovirt.ovirt.ovirt_event_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_external_provider_facts module has been removed. Use ovirt.ovirt.ovirt_external_provider_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_group_facts module has been removed. Use ovirt.ovirt.ovirt_group_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_host_facts module has been removed. Use ovirt.ovirt.ovirt_host_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_host_storage_facts module has been removed. Use ovirt.ovirt.ovirt_host_storage_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_network_facts module has been removed. Use ovirt.ovirt.ovirt_network_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_nic_facts module has been removed. Use ovirt.ovirt.ovirt_nic_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_permission_facts module has been removed. Use ovirt.ovirt.ovirt_permission_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_quota_facts module has been removed. Use ovirt.ovirt.ovirt_quota_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_scheduling_policy_facts module has been removed. Use ovirt.ovirt.ovirt_scheduling_policy_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_snapshot_facts module has been removed. Use ovirt.ovirt.ovirt_snapshot_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_storage_domain_facts module has been removed. Use ovirt.ovirt.ovirt_storage_domain_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_storage_template_facts module has been removed. Use ovirt.ovirt.ovirt_storage_template_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_storage_vm_facts module has been removed. Use ovirt.ovirt.ovirt_storage_vm_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_tag_facts module has been removed. Use ovirt.ovirt.ovirt_tag_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_template_facts module has been removed. Use ovirt.ovirt.ovirt_template_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_user_facts module has been removed. Use ovirt.ovirt.ovirt_user_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_vm_facts module has been removed. Use ovirt.ovirt.ovirt_vm_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_vmpool_facts module has been removed. Use ovirt.ovirt.ovirt_vmpool_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated purefa_facts module has been removed. Use purestorage.flasharray.purefa_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated purefb_facts module has been removed. Use purestorage.flasharray.purefb_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated python_requirements_facts module has been removed. Use python_requirements_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated redfish_facts module has been removed. Use redfish_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_image_facts module has been removed. Use scaleway_image_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_ip_facts module has been removed. Use scaleway_ip_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_organization_facts module has been removed. Use scaleway_organization_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_security_group_facts module has been removed. Use scaleway_security_group_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_server_facts module has been removed. Use scaleway_server_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_snapshot_facts module has been removed. Use scaleway_snapshot_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_volume_facts module has been removed. Use scaleway_volume_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated smartos_image_facts module has been removed. Use smartos_image_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated vertica_facts module has been removed. Use vertica_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated xenserver_guest_facts module has been removed. Use xenserver_guest_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The ovirt_facts docs fragment has been removed (https://github.com/ansible-collections/community.general/pull/1924). -- airbrake_deployment - removed deprecated ``token`` parameter. Use ``project_id`` and ``project_key`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- bigpanda - the alias ``message`` has been removed. Use ``deployment_message`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- cisco_spark, cisco_webex - the alias ``message`` has been removed. Use ``msg`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- clc_aa_policy - the ``wait`` parameter has been removed. It did not have any effect (https://github.com/ansible-collections/community.general/pull/1926). -- datadog_monitor - the alias ``message`` has been removed. Use ``notification_message`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- django_manage - the parameter ``liveserver`` has been removed (https://github.com/ansible-collections/community.general/pull/1926). -- idrac_redfish_config - the parameters ``manager_attribute_name`` and ``manager_attribute_value`` have been removed. Use ``manager_attributes`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- iso_extract - the alias ``thirsty`` has been removed. Use ``force`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- ldap_entry - the ``params`` parameter is now completely removed. Using it already triggered an error since community.general 0.1.2 (https://github.com/ansible-collections/community.general/pull/2257). -- pulp_repo - the ``feed_client_cert`` parameter no longer defaults to the value of the ``client_cert`` parameter (https://github.com/ansible-collections/community.general/pull/1926). -- pulp_repo - the ``feed_client_key`` parameter no longer defaults to the value of the ``client_key`` parameter (https://github.com/ansible-collections/community.general/pull/1926). -- pulp_repo - the alias ``ca_cert`` has been removed. Use ``feed_ca_cert`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- rax - unused parameter ``service`` removed (https://github.com/ansible-collections/community.general/pull/2020). -- redfish modules - issuing a data modification command without specifying the ID of the target System, Chassis or Manager resource when there is more than one is no longer allowed. Use the ``resource_id`` option to specify the target ID (https://github.com/ansible-collections/community.general/pull/1926). -- redfish_config - the parameters ``bios_attribute_name`` and ``bios_attribute_value`` have been removed. Use ``bios_attributes`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- syspatch - the ``apply`` parameter has been removed. This is the default mode, so simply removing it will not change the behavior (https://github.com/ansible-collections/community.general/pull/1926). -- xbps - the ``force`` parameter has been removed. It did not have any effect (https://github.com/ansible-collections/community.general/pull/1926). - -community.network -~~~~~~~~~~~~~~~~~ - -- The deprecated ``community.network.ce_sflow`` parameters: ``rate_limit``, ``rate_limit_slot``, and ``forward_enp_slot`` have been removed (https://github.com/ansible-collections/community.network/pull/255). -- The deprecated ``community.network.sros`` netconf plugin has been removed. Use ``nokia.sros.md`` instead (https://github.com/ansible-collections/community.network/pull/255). - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Removed TMOS v11 support for bigip_gtm_pool and bigip_gtm_wide_ip modules -- Removed quorum and monitor_type parameters in bigip_node module. See porting guides section at https://clouddocs.f5.com/products/orchestration/ansible/devel/usage/porting-guides.html -- Removed syslog_settings and pool_settings parameters in bigip_log_destination moduke. See porting guides section at https://clouddocs.f5.com/products/orchestration/ansible/devel/usage/porting-guides.html - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Removed module fortios_facts -- Removed module fortios_registration_forticare -- Removed module fortios_registration_vdom -- Removed module fortios_system_config_backup_restore -- Removed module fortios_system_vmlicense - -Deprecated Features -------------------- - -Ansible-core -~~~~~~~~~~~~ - -- Starting in 2.14, shell and command modules will no longer have the option to warn and suggest modules in lieu of commands. The ``warn`` parameter to these modules is now deprecated and defaults to ``False``. Similarly, the ``COMMAND_WARNINGS`` configuration option is also deprecated and defaults to ``False``. These will be removed and their presence will become an error in 2.14. -- apt_key - the parameter ``key`` does not have any effect, has been deprecated and will be removed in ansible-core version 2.14 (https://github.com/ansible/ansible/pull/70319). -- psrp - Set the minimum version of ``pypsrp`` to ``0.4.0``. - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- Deprecate cli_parse module and textfsm, ttp, xml, json parser plugins as they are moved to ansible.utils collection (https://github.com/ansible-collections/ansible.netcommon/pull/182 https://github.com/ansible-collections/ansible.utils/pull/28) - -cisco.nxos -~~~~~~~~~~ - -- Deprecated nxos_bgp_af in favour of nxos_bgp_address_family resource module. -- Deprecated nxos_bgp_neighbor_af in favour of nxos_bgp_neighbor_address_family resource module. - -cloudscale_ch.cloud -~~~~~~~~~~~~~~~~~~~ - -- The aliases ``server_uuids`` and ``server_uuid`` of the servers parameter in the volume module will be removed in version 3.0.0. - -community.aws -~~~~~~~~~~~~~ - -- ec2_eip - formally deprecate the ``instance_id`` alias for ``device_id`` (https://github.com/ansible-collections/community.aws/pull/349). -- ec2_vpc_endpoint - deprecate the policy_file option and recommend using policy with a lookup (https://github.com/ansible-collections/community.aws/pull/366). -- ec2_vpc_endpoint_info - the ``query`` option has been deprecated and will be removed after 2022-12-01 (https://github.com/ansible-collections/community.aws/pull/346). The ec2_vpc_endpoint_info now defaults to listing information about endpoints. The ability to search for information about available services has been moved to the dedicated module ``ec2_vpc_endpoint_service_info``. - -community.crypto -~~~~~~~~~~~~~~~~ - -- acme module_utils - the ``acme`` module_utils (``ansible_collections.community.crypto.plugins.module_utils.acme``) is deprecated and will be removed in community.crypto 2.0.0. Use the new Python modules in the ``acme`` package instead (``ansible_collections.community.crypto.plugins.module_utils.acme.xxx``) (https://github.com/ansible-collections/community.crypto/pull/184). -- acme_account_info - when ``retrieve_orders=url_list``, ``orders`` will no longer be returned in community.crypto 2.0.0. Use ``order_uris`` instead (https://github.com/ansible-collections/community.crypto/pull/178). - -community.general -~~~~~~~~~~~~~~~~~ - -- apt_rpm - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- composer - deprecated invalid parameter aliases ``working-dir``, ``global-command``, ``prefer-source``, ``prefer-dist``, ``no-dev``, ``no-scripts``, ``no-plugins``, ``optimize-autoloader``, ``classmap-authoritative``, ``apcu-autoloader``, ``ignore-platform-reqs``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- cpanm - parameter ``system_lib`` deprecated in favor of using ``become`` (https://github.com/ansible-collections/community.general/pull/2218). -- github_deploy_key - deprecated invalid parameter alias ``2fa_token``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- grove - the option ``message`` will be removed in community.general 4.0.0. Use the new option ``message_content`` instead (https://github.com/ansible-collections/community.general/pull/1929). -- homebrew - deprecated invalid parameter alias ``update-brew``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- homebrew_cask - deprecated invalid parameter alias ``update-brew``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- opkg - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- pacman - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- puppet - deprecated undocumented parameter ``show_diff``, will be removed in 7.0.0. (https://github.com/ansible-collections/community.general/pull/1927). -- runit - unused parameter ``dist`` marked for deprecation (https://github.com/ansible-collections/community.general/pull/1830). -- slackpkg - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- urpmi - deprecated invalid parameter aliases ``update-cache`` and ``no-recommends``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- xbps - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- xfconf - returning output as facts is deprecated, this will be removed in community.general 4.0.0. Please register the task output in a variable and use it instead. You can already switch to the new behavior now by using the new ``disable_facts`` option (https://github.com/ansible-collections/community.general/pull/1747). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_vmkernel_ip_config - deprecate in favor of vmware_vmkernel (https://github.com/ansible-collections/community.vmware/pull/667). - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Support for Python versions earlier than 3.5 is being deprecated diff --git a/docs/docsite/rst/porting_guides/porting_guide_5.rst b/docs/docsite/rst/porting_guides/porting_guide_5.rst deleted file mode 100644 index 7afc11e2112..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_5.rst +++ /dev/null @@ -1,1031 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_core_2.12.rst) - -.. _porting_5_guide: - -======================= -Ansible 5 Porting Guide -======================= - -.. contents:: - :local: - :depth: 2 - - -Ansible 5 is based on Ansible-core 2.12. - - -We suggest you read this page along with the `Ansible 5 Changelog `_ to understand what updates you may need to make. - - -Playbook -======== - -* When calling tasks and setting ``async``, setting ``ANSIBLE_ASYNC_DIR`` under ``environment:`` is no longer valid. Instead, use the shell configuration variable ``async_dir``, for example by setting ``ansible_async_dir``: - -.. code-block:: yaml - - tasks: - - dnf: - name: '*' - state: latest - async: 300 - poll: 5 - vars: - ansible_async_dir: /path/to/my/custom/dir - -* The ``undef()`` function is added to the templating environment for creating undefined variables directly in a template. Optionally, a hint may be provided for variables which are intended to be overridden. - -.. code-block:: yaml - - vars: - old: "{{ undef }}" - new: "{{ undef() }}" - new_with_hint: "{{ undef(hint='You must override this variable') }}" - -Python Interpreter Discovery -============================ - -The default value of ``INTERPRETER_PYTHON`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``. - -``INTERPRETER_PYTHON_FALLBACK`` can be changed from the default list of interpreters by setting the ``ansible_interpreter_python_fallback`` variable. - -See :ref:`interpreter discovery documentation ` for more details. - - -Command Line -============ - -* Python 3.8 on the controller node is a hard requirement for this release. The command line scripts will not function with a lower Python version. -* ``ansible-vault`` no longer supports ``PyCrypto`` and requires ``cryptography``. - -Deprecated -========== - -* Python 2.6 on the target node is deprecated in this release. ``ansible-core`` 2.13 will remove support for Python 2.6. -* Bare variables in conditionals: ``when`` conditionals no longer automatically parse string booleans such as ``"true"`` and ``"false"`` into actual booleans. Any variable containing a non-empty string is considered true. This was previously configurable with the ``CONDITIONAL_BARE_VARS`` configuration option (and the ``ANSIBLE_CONDITIONAL_BARE_VARS`` environment variable). This setting no longer has any effect. Users can work around the issue by using the ``|bool`` filter: - -.. code-block:: yaml - - vars: - teardown: 'false' - - tasks: - - include_tasks: teardown.yml - when: teardown | bool - - - include_tasks: provision.yml - when: not teardown | bool - -* The ``_remote_checksum()`` method in ``ActionBase`` is deprecated. Any action plugin using this method should use ``_execute_remote_stat()`` instead. - -Modules -======= - -* ``cron`` now requires ``name`` to be specified in all cases. -* ``cron`` no longer allows a ``reboot`` parameter. Use ``special_time: reboot`` instead. -* ``hostname`` - On FreeBSD, the ``before`` result will no longer be ``"temporarystub"`` if permanent hostname file does not exist. It will instead be ``""`` (empty string) for consistency with other systems. -* ``hostname`` - On OpenRC and Solaris based systems, the ``before`` result will no longer be ``"UNKNOWN"`` if the permanent hostname file does not exist. It will instead be ``""`` (empty string) for consistency with other systems. -* ``pip`` now uses the ``pip`` Python module installed for the Ansible module's Python interpreter, if available, unless ``executable`` or ``virtualenv`` were specified. - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Plugins -======= - -* ``unique`` filter with Jinja2 < 2.10 is case-sensitive and now raise coherently an error if ``case_sensitive=False`` instead of when ``case_sensitive=True``. -* Set theory filters (``intersect``, ``difference``, ``symmetric_difference`` and ``union``) are now case-sensitive. Explicitly use ``case_sensitive=False`` to keep previous behavior. Note: with Jinja2 < 2.10, the filters were already case-sensitive by default. -* ``password_hash``` now uses ``passlib`` defaults when an option is unspecified, for example ``bcrypt_sha256``, now default to the "2b" format and if the "2a" format is required it must be specified. - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes - -Porting Guide for v5.9.0 -======================== - -Added Collections ------------------ - -- cisco.dnac (version 6.4.0) -- community.sap_libs (version 1.1.0) - -Major Changes -------------- - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support FortiOS 7.0.2, 7.0.3, 7.0.4, 7.0.5. - -Deprecated Features -------------------- - -- The collection ``community.sap`` has been renamed to ``community.sap_libs``. For now both collections are included in Ansible. The content in ``community.sap`` will be replaced with deprecated redirects to the new collection in Ansible 7.0.0, and these redirects will eventually be removed from Ansible. Please update your FQCNs for ``community.sap``. - -community.docker -~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.docker 3.0.0). Some modules might still work with these versions afterwards, but we will no longer keep compatibility code that was needed to support them (https://github.com/ansible-collections/community.docker/pull/361). -- The dependency on docker-compose for Execution Environments is deprecated and will be removed in community.docker 3.0.0. The `Python docker-compose library `__ is unmaintained and can cause dependency issues. You can manually still install it in an Execution Environment when needed (https://github.com/ansible-collections/community.docker/pull/373). -- Various modules - the default of ``tls_hostname`` that was supposed to be removed in community.docker 2.0.0 will now be removed in version 3.0.0 (https://github.com/ansible-collections/community.docker/pull/362). -- docker_stack - the return values ``out`` and ``err`` that were supposed to be removed in community.docker 2.0.0 will now be removed in version 3.0.0 (https://github.com/ansible-collections/community.docker/pull/362). - -Porting Guide for v5.8.0 -======================== - -Added Collections ------------------ - -- vmware.vmware_rest (version 2.1.5) - -Breaking Changes ----------------- - -vmware.vmware_rest -~~~~~~~~~~~~~~~~~~ - -- The vmware_rest 2.0.0 support vSphere 7.0.2 onwards. -- vcenter_vm_storage_policy - the format of the ``disks`` parameter has changed. -- vcenter_vm_storage_policy - the module has a new mandatory parameter: ``vm_home``. - -Major Changes -------------- - -community.mysql -~~~~~~~~~~~~~~~ - -- The community.mysql collection no longer supports ``Ansible 2.9`` and ``ansible-base 2.10``. While we take no active measures to prevent usage and there are no plans to introduce incompatible code to the modules, we will stop testing against ``Ansible 2.9`` and ``ansible-base 2.10``. Both will very soon be End of Life and if you are still using them, you should consider upgrading to the ``latest Ansible / ansible-core 2.11 or later`` as soon as possible (https://github.com/ansible-collections/community.mysql/pull/343). - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- The community.postgresql collection no longer supports ``Ansible 2.9`` and ``ansible-base 2.10``. While we take no active measures to prevent usage and there are no plans to introduce incompatible code to the modules, we will stop testing against ``Ansible 2.9`` and ``ansible-base 2.10``. Both will very soon be End of Life and if you are still using them, you should consider upgrading to the ``latest Ansible / ansible-core 2.11 or later`` as soon as possible (https://github.com/ansible-collections/community.postgresql/pull/245). - -Deprecated Features -------------------- - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- token_validate options - the shared auth option ``token_validate`` will change its default from ``True`` to ``False`` in community.hashi_vault version 4.0.0. The ``vault_login`` lookup and module will keep the default value of ``True`` (https://github.com/ansible-collections/community.hashi_vault/issues/248). - -community.network -~~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.network 4.0.0) this spring. While most content will probably still work with ansible-base 2.10, we will remove symbolic links for modules and action plugins, which will make it impossible to use them with Ansible 2.9 anymore. Please use community.network 3.x.y with Ansible 2.9 and ansible-base 2.10, as these releases will continue to support Ansible 2.9 and ansible-base 2.10 even after they are End of Life (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.network/pull/382). - -vmware.vmware_rest -~~~~~~~~~~~~~~~~~~ - -- vcenter_vm_storage_policy_compliance - drop the module, it returns 404 error. -- vcenter_vm_tools - remove the ``upgrade`` state. -- vcenter_vm_tools_installer - remove the module from the collection. - -Porting Guide for v5.7.0 -======================== - -Major Changes -------------- - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_user - the ``priv`` argument has been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``postgresql_privs`` module to grant/revoke privileges instead (https://github.com/ansible-collections/community.postgresql/issues/212). - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support FortiOS 7.0.2, 7.0.3, 7.0.4, 7.0.5. - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- nmcli - deprecate default hairpin mode for a bridge. This so we can change it to ``false`` in community.general 7.0.0, as this is also the default in ``nmcli`` (https://github.com/ansible-collections/community.general/pull/4334). -- proxmox inventory plugin - the current default ``true`` of the ``want_proxmox_nodes_ansible_host`` option has been deprecated. The default will change to ``false`` in community.general 6.0.0. To keep the current behavior, explicitly set ``want_proxmox_nodes_ansible_host`` to ``true`` in your inventory configuration. We suggest to already switch to the new behavior by explicitly setting it to ``false``, and by using ``compose:`` to set ``ansible_host`` to the correct value. See the examples in the plugin documentation for details (https://github.com/ansible-collections/community.general/pull/4466). - -Porting Guide for v5.6.0 -======================== - -Added Collections ------------------ - -- community.sap (version 1.0.0) - -Deprecated Features -------------------- - -cisco.ios -~~~~~~~~~ - -- Deprecates lldp module. - -Porting Guide for v5.5.0 -======================== - -Known Issues ------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- pacman - ``update_cache`` cannot differentiate between up to date and outdated package lists and will report ``changed`` in both situations (https://github.com/ansible-collections/community.general/pull/4318). -- pacman - binaries specified in the ``executable`` parameter must support ``--print-format`` in order to be used by this module. In particular, AUR helper ``yay`` is known not to currently support it (https://github.com/ansible-collections/community.general/pull/4312). - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- pacman - from community.general 5.0.0 on, the ``changed`` status of ``update_cache`` will no longer be ignored if ``name`` or ``upgrade`` is specified. To keep the old behavior, add something like ``register: result`` and ``changed_when: result.packages | length > 0`` to your task (https://github.com/ansible-collections/community.general/pull/4329). - -Porting Guide for v5.4.0 -======================== - -Major Changes -------------- - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Added choco_args option to pass additional arguments directly to Chocolatey. - -vyos.vyos -~~~~~~~~~ - -- Add 'pool' as value to server key in ntp_global. - -Deprecated Features -------------------- - -cisco.ios -~~~~~~~~~ - -- `ios_acls` - Deprecated fragment attribute added boolean alternate as enable_fragment. - -Porting Guide for v5.3.0 -======================== - -Major Changes -------------- - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- bigip_device_info - pagination logic has also been added to help with api stability. -- bigip_device_info - the module no longer gathers information from all partitions on device. This change will stabalize the module by gathering resources only from the given partition and prevent the module from gathering way too much information that might result in crashing. - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- mail callback plugin - not specifying ``sender`` is deprecated and will be disallowed in community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/4140). - -Porting Guide for v5.2.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_application_alerts_smtp - Issue(212310) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_device_local_access_configuration - Issue(215035) - The module reports ``Successfully updated the local access setting`` if an unsupported value is provided for the parameter timeout_limit. However, this value is not actually applied on OpenManage Enterprise Modular. -- ome_device_local_access_configuration - Issue(217865) - The module does not display a proper error message if an unsupported value is provided for the user_defined and lcd_language parameters. -- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout. -- ome_device_power_settings - Issue(212679) - The module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -purestorage.flasharray -~~~~~~~~~~~~~~~~~~~~~~ - -- purefa_admin - Once `max_login` and `lockout` have been set there is currently no way to rest these to zero except through the FlashArray GUI - -Major Changes -------------- - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_mr_radio - New module - -Deprecated Features -------------------- - -purestorage.flasharray -~~~~~~~~~~~~~~~~~~~~~~ - -- purefa_sso - Deprecated in favor of M(purefa_admin). Will be removed in Collection 2.0 - -Porting Guide for v5.1.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_application_alerts_smtp - Issue(212310) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout. -- ome_device_power_settings - Issue(212679) - The module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Major Changes -------------- - -containers.podman -~~~~~~~~~~~~~~~~~ - -- Add podman_tag module -- Add secrets driver and driver opts support - -Removed Features ----------------- - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- the "legacy" integration test setup has been removed; this does not affect end users and is only relevant to contributors (https://github.com/ansible-collections/community.hashi_vault/pull/191). - -Deprecated Features -------------------- - -cisco.nxos -~~~~~~~~~~ - -- Deprecated nxos_snmp_community module. -- Deprecated nxos_snmp_contact module. -- Deprecated nxos_snmp_host module. -- Deprecated nxos_snmp_location module. -- Deprecated nxos_snmp_traps module. -- Deprecated nxos_snmp_user module. - -community.general -~~~~~~~~~~~~~~~~~ - -- module_helper module utils - deprecated the attribute ``ModuleHelper.VarDict`` (https://github.com/ansible-collections/community.general/pull/3801). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.hashi_vault 3.0.0) next spring (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.hashi_vault/issues/189). -- aws_iam_login auth method - the ``aws_iam_login`` method has been renamed to ``aws_iam``. The old name will be removed in collection version ``3.0.0``. Until then both names will work, and a warning will be displayed when using the old name (https://github.com/ansible-collections/community.hashi_vault/pull/193). - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resource module. - -Porting Guide for v5.0.1 -======================== - -Major Changes -------------- - -- Raised python requirement of the ansible package from >=2.7 to >=3.8 to match ansible-core - -Porting Guide for v5.0.0 -======================== - -Added Collections ------------------ - -- cisco.ise (version 1.2.1) -- cloud.common (version 2.1.0) -- community.ciscosmb (version 1.0.4) -- community.dns (version 2.0.3) -- infoblox.nios_modules (version 1.1.2) -- netapp.storagegrid (version 21.7.0) - -Known Issues ------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - Tab completion anywhere other than the end of the command with the new composite options will provide incorrect results. See `issue 351 `_ for additional details. - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_device_power_settings - Issue(212679) The ome_device_power_settings module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -purestorage.flashblade -~~~~~~~~~~~~~~~~~~~~~~ - -- purefb_lag - The mac_address field in the response is not populated. This will be fixed in a future FlashBlade update. - -Breaking Changes ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- Action, module, and group names in module_defaults must be static values. Their values can still be templates. -- Fully qualified 'ansible.legacy' plugin names are not included implicitly in action_groups. -- Unresolvable groups, action plugins, and modules in module_defaults are an error. -- ansible-test - Automatic installation of requirements for "cloud" test plugins no longer occurs. The affected test plugins are ``aws``, ``azure``, ``cs``, ``hcloud``, ``nios``, ``opennebula``, ``openshift`` and ``vcenter``. Collections should instead use one of the supported integration test requirements files, such as the ``tests/integration/requirements.txt`` file. -- ansible-test - The HTTP Tester is no longer available with the ``ansible-test shell`` command. Only the ``integration`` and ``windows-integration`` commands provide HTTP Tester. -- ansible-test - The ``--disable-httptester`` option is no longer available. The HTTP Tester is no longer optional for tests that specify it. -- ansible-test - The ``--httptester`` option is no longer available. To override the container used for HTTP Tester tests, set the ``ANSIBLE_HTTP_TEST_CONTAINER`` environment variable instead. -- ansible-test - Unit tests for ``modules`` and ``module_utils`` are now limited to importing only ``ansible.module_utils`` from the ``ansible`` module. -- conditionals - ``when`` conditionals no longer automatically parse string booleans such as ``"true"`` and ``"false"`` into actual booleans. Any non-empty string is now considered true. The ``CONDITIONAL_BARE_VARS`` configuration variable no longer has any effect. -- hostname - Drops any remaining support for Python 2.4 by using ``with open()`` to simplify exception handling code which leaked file handles in several spots -- hostname - On FreeBSD, the string ``temporarystub`` no longer gets written to the hostname file in the get methods (and in check_mode). As a result, the default hostname will now appear as ``''`` (empty string) instead of ``temporarystub`` for consistency with other strategies. This means the ``before`` result will be different. -- hostname - On OpenRC systems and Solaris, the ``before`` value will now be ``''`` (empty string) if the permanent hostname file does not exist, for consistency with other strategies. -- intersect, difference, symmetric_difference, union filters - the default behavior is now to be case-sensitive (https://github.com/ansible/ansible/issues/74255) -- unique filter - the default behavior is now to fail if Jinja2's filter fails and explicit ``case_sensitive=False`` as the Ansible's fallback is case-sensitive (https://github.com/ansible/ansible/pull/74256) - -amazon.aws -~~~~~~~~~~ - -- ec2_instance - instance wait for state behaviour has changed. If plays require the old behavior of waiting for the instance monitoring status to become ``OK`` when launching a new instance, the action will need to specify ``state: started`` (https://github.com/ansible-collections/amazon.aws/pull/481). -- ec2_snapshot - support for waiting indefinitely has been dropped, new default is 10 minutes (https://github.com/ansible-collections/amazon.aws/pull/356). -- ec2_vol_info - return ``attachment_set`` is now a list of attachments with Multi-Attach support on disk. (https://github.com/ansible-collections/amazon.aws/pull/362). -- ec2_vpc_dhcp_option - The module has been refactored to use boto3. Keys and value types returned by the module are now consistent, which is a change from the previous behaviour. A ``purge_tags`` option has been added, which defaults to ``True``. (https://github.com/ansible-collections/amazon.aws/pull/252) -- ec2_vpc_dhcp_option_info - Now preserves case for tag keys in return value. (https://github.com/ansible-collections/amazon.aws/pull/252) -- module_utils.core - The boto3 switch has been removed from the region parameter (https://github.com/ansible-collections/amazon.aws/pull/287). -- module_utils/compat - vendored copy of ipaddress removed (https://github.com/ansible-collections/amazon.aws/pull/461). -- module_utils/core - updated the ``scrub_none_parameters`` function so that ``descend_into_lists`` is set to ``True`` by default (https://github.com/ansible-collections/amazon.aws/pull/297). - -arista.eos -~~~~~~~~~~ - -- Arista released train 4.23.X and newer and along with it replaced and deprecated lots of commands. This PR adds support for syntax changes in release train 4.23 and after. Going forward the eos modules will not support eos sw version < 4.23. - -community.aws -~~~~~~~~~~~~~ - -- ec2_instance - The module has been migrated to the ``amazon.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance``. -- ec2_instance_info - The module has been migrated to the ``amazon.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance_info``. -- ec2_vpc_endpoint - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint``. -- ec2_vpc_endpoint_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_info``. -- ec2_vpc_endpoint_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_info``. -- ec2_vpc_endpoint_service_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_service_info``. -- ec2_vpc_igw - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw``. -- ec2_vpc_igw_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw_info``. -- ec2_vpc_igw_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw_info``. -- ec2_vpc_nat_gateway - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway``. -- ec2_vpc_nat_gateway_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway_info``. -- ec2_vpc_nat_gateway_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway_info``. -- kms_info - key details are now returned in the ``kms_keys`` attribute rather than the ``keys`` attribute (https://github.com/ansible-collections/community.aws/pull/648). - -community.crypto -~~~~~~~~~~~~~~~~ - -- Adjust ``dirName`` text parsing and to text converting code to conform to `Sections 2 and 3 of RFC 4514 `_. This is similar to how `cryptography handles this `_ (https://github.com/ansible-collections/community.crypto/pull/274). -- acme module utils - removing compatibility code (https://github.com/ansible-collections/community.crypto/pull/290). -- acme_* modules - removed vendored copy of the Python library ``ipaddress``. If you are using Python 2.x, please make sure to install the library (https://github.com/ansible-collections/community.crypto/pull/287). -- compatibility module_utils - removed vendored copy of the Python library ``ipaddress`` (https://github.com/ansible-collections/community.crypto/pull/287). -- crypto module utils - removing compatibility code (https://github.com/ansible-collections/community.crypto/pull/290). -- get_certificate, openssl_csr_info, x509_certificate_info - depending on the ``cryptography`` version used, the modules might not return the ASN.1 value for an extension as contained in the certificate respectively CSR, but a re-encoded version of it. This should usually be identical to the value contained in the source file, unless the value was malformed. For extensions not handled by C(cryptography) the value contained in the source file is always returned unaltered (https://github.com/ansible-collections/community.crypto/pull/318). -- module_utils - removed various PyOpenSSL support functions and default backend values that are not needed for the openssl_pkcs12 module (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_csr, openssl_csr_pipe, x509_crl - the ``subject`` respectively ``issuer`` fields no longer ignore empty values, but instead fail when encountering them (https://github.com/ansible-collections/community.crypto/pull/316). -- openssl_privatekey_info - by default consistency checks are not run; they need to be explicitly requested by passing ``check_consistency=true`` (https://github.com/ansible-collections/community.crypto/pull/309). -- x509_crl - for idempotency checks, the ``issuer`` order is ignored. If order is important, use the new ``issuer_ordered`` option (https://github.com/ansible-collections/community.crypto/pull/316). - -community.dns -~~~~~~~~~~~~~ - -- All Hetzner modules and plugins which handle DNS records now work with unquoted TXT values by default. The old behavior can be obtained by setting ``txt_transformation=api`` (https://github.com/ansible-collections/community.dns/issues/48, https://github.com/ansible-collections/community.dns/pull/57, https://github.com/ansible-collections/community.dns/pull/60). -- Hosttech API creation - now requires a ``ModuleOptionProvider`` object instead of an ``AnsibleModule`` object. Alternatively an Ansible plugin instance can be passed (https://github.com/ansible-collections/community.dns/pull/37). -- The hetzner_dns_record_info and hosttech_dns_record_info modules have been renamed to hetzner_dns_record_set_info and hosttech_dns_record_set_info, respectively (https://github.com/ansible-collections/community.dns/pull/54). -- The hosttech_dns_record module has been renamed to hosttech_dns_record_set (https://github.com/ansible-collections/community.dns/pull/31). -- The internal bulk record updating helper (``bulk_apply_changes``) now also returns the records that were deleted, created or updated (https://github.com/ansible-collections/community.dns/pull/63). -- The internal record API no longer allows to manage comments explicitly (https://github.com/ansible-collections/community.dns/pull/63). -- When using the internal modules API, now a zone ID type and a provider information object must be passed (https://github.com/ansible-collections/community.dns/pull/27). -- hetzner_dns_record* modules - implement correct handling of default TTL. The value ``none`` is now accepted and returned in this case (https://github.com/ansible-collections/community.dns/pull/52, https://github.com/ansible-collections/community.dns/issues/50). -- hetzner_dns_record, hetzner_dns_record_set, hetzner_dns_record_sets - the default TTL is now 300 and no longer 3600, which equals the default in the web console (https://github.com/ansible-collections/community.dns/pull/43). -- hosttech_* module_utils - completely rewrite and refactor to support new JSON API and allow to re-use provider-independent module logic (https://github.com/ansible-collections/community.dns/pull/4). -- hosttech_dns_record_set - the option ``overwrite`` was replaced by a new option ``on_existing``. Specifying ``overwrite=true`` is equivalent to ``on_existing=replace`` (the new default). Specifying ``overwrite=false`` with ``state=present`` is equivalent to ``on_existing=keep_and_fail``, and specifying ``overwrite=false`` with ``state=absent`` is equivalent to ``on_existing=keep`` (https://github.com/ansible-collections/community.dns/pull/31). - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_compose - fixed ``timeout`` defaulting behavior so that ``stop_grace_period``, if defined in the compose file, will be used if `timeout`` is not specified (https://github.com/ansible-collections/community.docker/pull/163). - -community.general -~~~~~~~~~~~~~~~~~ - -- archive - adding idempotency checks for changes to file names and content within the ``destination`` file (https://github.com/ansible-collections/community.general/pull/3075). -- lxd inventory plugin - when used with Python 2, the plugin now needs ``ipaddress`` installed `from pypi `_ (https://github.com/ansible-collections/community.general/pull/2441). -- scaleway_security_group_rule - when used with Python 2, the module now needs ``ipaddress`` installed `from pypi `_ (https://github.com/ansible-collections/community.general/pull/2441). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- connection options - there is no longer a default value for the ``url`` option (the Vault address), so a value must be supplied (https://github.com/ansible-collections/community.hashi_vault/issues/83). - -community.okd -~~~~~~~~~~~~~ - -- drop python 2 support (https://github.com/openshift/community.okd/pull/93). - -community.routeros -~~~~~~~~~~~~~~~~~~ - -- api - due to a programming error, the module never failed on errors. This has now been fixed. If you are relying on the module not failing in case of idempotent commands (resulting in errors like ``failure: already have such address``), you need to adjust your roles/playbooks. We suggest to use ``failed_when`` to accept failure in specific circumstances, for example ``failed_when: "'failure: already have ' in result.msg[0]"`` (https://github.com/ansible-collections/community.routeros/pull/39). -- api - splitting commands no longer uses a naive split by whitespace, but a more RouterOS CLI compatible splitting algorithm (https://github.com/ansible-collections/community.routeros/pull/45). -- command - the module now always indicates that a change happens. If this is not correct, please use ``changed_when`` to determine the correct changed status for a task (https://github.com/ansible-collections/community.routeros/pull/50). - -community.zabbix -~~~~~~~~~~~~~~~~ - -- all roles now reference other roles and modules through their fully qualified collection names, which makes Ansible 2.10 minimum supported version for roles (See `issue 477 `_). - -kubernetes.core -~~~~~~~~~~~~~~~ - -- Drop python 2 support (https://github.com/ansible-collections/kubernetes.core/pull/86). -- helm_plugin - remove unused ``release_namespace`` parameter (https://github.com/ansible-collections/kubernetes.core/pull/85). -- helm_plugin_info - remove unused ``release_namespace`` parameter (https://github.com/ansible-collections/kubernetes.core/pull/85). -- k8s_cluster_info - returned apis as list to avoid being overwritten in case of multiple version (https://github.com/ansible-collections/kubernetes.core/pull/41). -- k8s_facts - remove the deprecated alias from k8s_facts to k8s_info (https://github.com/ansible-collections/kubernetes.core/pull/125). - -netapp.storagegrid -~~~~~~~~~~~~~~~~~~ - -- This version introduces a breaking change. - All modules have been renamed from ``nac_sg_*`` to ``na_sg_*``. - Playbooks and Roles must be updated to match. - -Major Changes -------------- - -Ansible-core -~~~~~~~~~~~~ - -- Python Controller Requirement - Python 3.8 or newer is required for the control node (the machine that runs Ansible) (https://github.com/ansible/ansible/pull/74013) -- ansible-test - All "cloud" plugins which use containers can now be used with all POSIX and Windows hosts. Previously the plugins did not work with Windows at all, and support for hosts created with the ``--remote`` option was inconsistent. -- ansible-test - Collections can now specify controller and target specific integration test requirements and constraints. If provided, they take precedence over the previously available requirements and constraints files. -- ansible-test - Integration tests run with the ``integration`` command can now be executed on two separate hosts instead of always running on the controller. The target host can be one provided by ``ansible-test`` or by the user, as long as it is accessible using SSH. -- ansible-test - Most container features are now supported under Podman. Previously a symbolic link for ``docker`` pointing to ``podman`` was required. -- ansible-test - New ``--controller`` and ``--target`` / ``--target-python`` options have been added to allow more control over test environments. -- ansible-test - Python 3.8 - 3.10 are now required to run ``ansible-test``, thus matching the Ansible controller Python requirements. Older Python versions (2.6 - 2.7 and 3.5 - 3.10) can still be the target for relevant tests. -- ansible-test - SSH port forwarding and redirection is now used exclusively to make container ports available on non-container hosts. When testing on POSIX systems this requires SSH login as root. Previously SSH port forwarding was combined with firewall rules or other port redirection methods, with some platforms being unsupported. -- ansible-test - Sanity tests always run in isolated Python virtual environments specific to the requirements of each test. The environments are cached. -- ansible-test - Sanity tests are now separated into two categories, controller and target. All tests except ``import`` and ``compile`` are controller tests. The controller tests always run using the same Python version used to run ``ansible-test``. The target tests use the Python version(s) specified by the user, or all available Python versions. -- ansible-test - Sanity tests now use fully pinned requirements that are independent of each other and other test types. -- ansible-test - Tests run with the ``centos6`` and ``default`` test containers now use a PyPI proxy container to access PyPI when Python 2.6 is used. This allows tests running under Python 2.6 to continue functioning even though PyPI is discontinuing support for non-SNI capable clients. -- ansible-test - The ``future-import-boilerplate`` and ``metaclass-boilerplate`` sanity tests are limited to remote-only code. Additionally, they are skipped for collections which declare no support for Python 2.x. -- ansible-test - The ``import`` and ``compile`` sanity tests limit remote-only Python version checks to remote-only code. -- ansible-test - Unit tests for controller-only code now require Python 3.8 or later. -- ansible-test - Version neutral sanity tests now require Python 3.8 or later. -- junit callback - The ``junit_xml`` and ``ordereddict`` Python modules are no longer required to use the ``junit`` callback plugin. - -amazon.aws -~~~~~~~~~~ - -- amazon.aws collection - Due to the AWS SDKs announcing the end of support for Python less than 3.6 (https://boto3.amazonaws.com/v1/documentation/api/1.17.64/guide/migrationpy3.html) this collection now requires Python 3.6+ (https://github.com/ansible-collections/amazon.aws/pull/298). -- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.18.0`` and ``boto3<1.15.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/502). -- ec2_instance - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance``. -- ec2_instance_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance_info``. -- ec2_vpc_endpoint - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint``. -- ec2_vpc_endpoint_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_info``. -- ec2_vpc_endpoint_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_info``. -- ec2_vpc_endpoint_service_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_service_info``. -- ec2_vpc_igw - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw``. -- ec2_vpc_igw_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw_facts``. -- ec2_vpc_igw_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw_info``. -- ec2_vpc_nat_gateway - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway``. -- ec2_vpc_nat_gateway_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway_info``. -- ec2_vpc_nat_gateway_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway_info``. -- ec2_vpc_route_table - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table``. -- ec2_vpc_route_table_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table_facts``. -- ec2_vpc_route_table_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table_info``. - -cisco.ise -~~~~~~~~~ - -- Adds ``ise_uses_api_gateway`` to module options. -- Adds a 'aws_deployment' role that allows the deployment of an arbitrary large ISE cluster to AWS. -- Adds ise_responses to return values of info modules. -- Adds ise_update_response to return values of non-info modules. -- Fixes inner logic of modules that have no get by name and have not working filter. -- Renamed module device_administration_authorization_exception_rules to device_administration_local_exception_rules. -- Renamed module device_administration_authorization_global_exception_rules to device_administration_global_exception_rules. -- Renamed module network_access_authorization_exception_rules to network_access_local_exception_rules. -- Renamed module network_access_authorization_global_exception_rules to network_access_global_exception_rules. -- Updates options required for modules. -- Updates sdk parameters for previous modules -- device_administration_authorization_exception_rules - removed module. -- device_administration_authorization_exception_rules_info - removed module. -- device_administration_authorization_global_exception_rules - removed module. -- device_administration_authorization_global_exception_rules_info - removed module. -- guest_user_reinstante - removed module. -- import_trust_cert - removed module. -- network_access_authorization_exception_rules - removed module. -- network_access_authorization_exception_rules_info - removed module. -- network_access_authorization_global_exception_rules - removed module. -- network_access_authorization_global_exception_rules_info - removed module. -- personas_check_standalone - Adds module for the deployment of personas to existing nodes in an ISE cluster. -- personas_export_certs - Adds module for the deployment of personas to existing nodes in an ISE cluster. -- personas_promote_primary - Adds module for the deployment of personas to existing nodes in an ISE cluster. -- personas_update_roles - Adds module for the deployment of personas to existing nodes in an ISE cluster. -- service_info - removed module. -- system_certificate_export - removed module. -- telemetry_info_info - removed module. - -cloud.common -~~~~~~~~~~~~ - -- turbo - enable turbo mode for lookup plugins - -cloudscale_ch.cloud -~~~~~~~~~~~~~~~~~~~ - -- Add custom_image module - -community.aws -~~~~~~~~~~~~~ - -- community.aws collection - The community.aws collection has dropped support for ``botocore<1.18.0`` and ``boto3<1.15.0`` (https://github.com/ansible-collections/community.aws/pull/711). Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/442). - -community.ciscosmb -~~~~~~~~~~~~~~~~~~ - -- Python 2.6, 2.7, 3.5 is required -- add CBS350 support -- add antsibull-changelog support -- add ciscosmb_command -- added facts subset "interfaces" -- ciscosmb_facts with default subset and unit tests -- interface name canonicalization -- transform collection qaxi.ciscosmb to community.ciscosmb -- transform community.ciscosmb.ciscosmb_command to community.ciscosmb.command -- transform community.ciscosmb.ciscosmb_facts to community.ciscosmb.facts -- unit tests for CBS350 - -community.dns -~~~~~~~~~~~~~ - -- hosttech_* modules - support the new JSON API at https://api.ns1.hosttech.eu/api/documentation/ (https://github.com/ansible-collections/community.dns/pull/4). - -community.general -~~~~~~~~~~~~~~~~~ - -- bitbucket_* modules - ``client_id`` is no longer marked as ``no_log=true``. If you relied on its value not showing up in logs and output, please mark the whole tasks with ``no_log: true`` (https://github.com/ansible-collections/community.general/pull/2045). - -community.kubernetes -~~~~~~~~~~~~~~~~~~~~ - -- redirect everything from ``community.kubernetes`` to ``kubernetes.core`` (https://github.com/ansible-collections/community.kubernetes/pull/425). - -community.okd -~~~~~~~~~~~~~ - -- update to use kubernetes.core 2.0 (https://github.com/openshift/community.okd/pull/93). - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_query - the default value of the ``as_single_query`` option will be changed to ``yes`` in community.postgresql 2.0.0 (https://github.com/ansible-collections/community.postgresql/issues/85). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_object_custom_attributes_info - added a new module to gather custom attributes of an object (https://github.com/ansible-collections/community.vmware/pull/851). - -containers.podman -~~~~~~~~~~~~~~~~~ - -- Add systemd generation for pods -- Generate systemd service files for containers - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_server_config_profile - Added support for exporting and importing Server Configuration Profile through HTTP/HTTPS share. -- ome_device_group - Added support for adding devices to a group using the IP addresses of the devices and group ID. -- ome_firmware - Added option to stage the firmware update and support for selecting components and devices for baseline-based firmware update. -- ome_firmware_baseline - Module supports check mode, and allows the modification and deletion of firmware baselines. -- ome_firmware_catalog - Module supports check mode, and allows the modification and deletion of firmware catalogs. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Add real-world use cases in the example section for some configuration modules. -- Collect the current configurations of the modules and convert them into playbooks. -- Improve ``fortios_configuration_fact`` to use multiple selectors concurrently. -- New module fortios_monitor_fact. -- Support FortiOS 7.0.1. -- Support Fortios 7.0. -- Support Log APIs. -- Support ``check_mode`` in all cofigurationAPI-based modules. -- Support filtering for fact gathering modules ``fortios_configuration_fact`` and ``fortios_monitor_fact``. -- Support member operation (delete/add extra members) on an object that has a list of members in it. -- Support moving policy in ``firewall_central_snat_map``. -- Support selectors feature in ``fortios_monitor_fact`` and ``fortios_log_fact``. -- Unify schemas for monitor API. - -gluster.gluster -~~~~~~~~~~~~~~~ - -- enable client.ssl,server.ssl before starting the gluster volume (https://github.com/gluster/gluster-ansible-collection/pull/19) - -hetzner.hcloud -~~~~~~~~~~~~~~ - -- Introduction of placement groups - -kubernetes.core -~~~~~~~~~~~~~~~ - -- k8s - deprecate merge_type=json. The JSON patch functionality has never worked (https://github.com/ansible-collections/kubernetes.core/pull/99). -- k8s_json_patch - split JSON patch functionality out into a separate module (https://github.com/ansible-collections/kubernetes.core/pull/99). -- replaces the openshift client with the official kubernetes client (https://github.com/ansible-collections/kubernetes.core/issues/34). - -netapp.cloudmanager -~~~~~~~~~~~~~~~~~~~ - -- Adding stage environment to all modules in cloudmanager - -netbox.netbox -~~~~~~~~~~~~~ - -- packages is now a required Python package and gets installed through Ansible 2.10+. - -openvswitch.openvswitch -~~~~~~~~~~~~~~~~~~~~~~~ - -- By mistake we tagged the repo to 2.0.0 and as it wasn't intended and cannot be reverted we're releasing 2.0.1 to make the community aware of the major version update. - -ovirt.ovirt -~~~~~~~~~~~ - -- remove_stale_lun - Add role for removing stale LUN (https://bugzilla.redhat.com/1966873). - -Removed Features ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- The built-in module_util ``ansible.module_utils.common.removed`` was previously deprecated and has been removed. -- connections, removed password check stubs that had been moved to become plugins. -- task, inline parameters being auto coerced into variables has been removed. - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_reboot - Removed ``shutdown_timeout`` and ``shutdown_timeout_sec`` which has not done anything since Ansible 2.5. - -community.crypto -~~~~~~~~~~~~~~~~ - -- acme_* modules - the ``acme_directory`` option is now required (https://github.com/ansible-collections/community.crypto/pull/290). -- acme_* modules - the ``acme_version`` option is now required (https://github.com/ansible-collections/community.crypto/pull/290). -- acme_account_facts - the deprecated redirect has been removed. Use community.crypto.acme_account_info instead (https://github.com/ansible-collections/community.crypto/pull/290). -- acme_account_info - ``retrieve_orders=url_list`` no longer returns the return value ``orders``. Use the ``order_uris`` return value instead (https://github.com/ansible-collections/community.crypto/pull/290). -- crypto.info module utils - the deprecated redirect has been removed. Use ``crypto.pem`` instead (https://github.com/ansible-collections/community.crypto/pull/290). -- get_certificate - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_certificate - the deprecated redirect has been removed. Use community.crypto.x509_certificate instead (https://github.com/ansible-collections/community.crypto/pull/290). -- openssl_certificate_info - the deprecated redirect has been removed. Use community.crypto.x509_certificate_info instead (https://github.com/ansible-collections/community.crypto/pull/290). -- openssl_csr - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_csr and openssl_csr_pipe - ``version`` now only accepts the (default) value 1 (https://github.com/ansible-collections/community.crypto/pull/290). -- openssl_csr_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_csr_pipe - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_privatekey - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_privatekey_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_privatekey_pipe - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_publickey - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_publickey_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_signature - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_signature_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- x509_certificate - remove ``assertonly`` provider (https://github.com/ansible-collections/community.crypto/pull/289). -- x509_certificate - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- x509_certificate_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- x509_certificate_pipe - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_container - the default value of ``container_default_behavior`` changed to ``no_defaults`` (https://github.com/ansible-collections/community.docker/pull/210). -- docker_container - the default value of ``network_mode`` is now the name of the first network specified in ``networks`` if such are specified and ``networks_cli_compatible=true`` (https://github.com/ansible-collections/community.docker/pull/210). -- docker_container - the special value ``all`` can no longer be used in ``published_ports`` next to other values. Please use ``publish_all_ports=true`` instead (https://github.com/ansible-collections/community.docker/pull/210). -- docker_login - removed the ``email`` option (https://github.com/ansible-collections/community.docker/pull/210). - -community.general -~~~~~~~~~~~~~~~~~ - -- All inventory and vault scripts contained in community.general were moved to the `contrib-scripts GitHub repository `_ (https://github.com/ansible-collections/community.general/pull/2696). -- ModuleHelper module utils - remove fallback when value could not be determined for a parameter (https://github.com/ansible-collections/community.general/pull/3461). -- Removed deprecated netapp module utils and doc fragments (https://github.com/ansible-collections/community.general/pull/3197). -- The nios, nios_next_ip, nios_next_network lookup plugins, the nios documentation fragment, and the nios_host_record, nios_ptr_record, nios_mx_record, nios_fixed_address, nios_zone, nios_member, nios_a_record, nios_aaaa_record, nios_network, nios_dns_view, nios_txt_record, nios_naptr_record, nios_srv_record, nios_cname_record, nios_nsgroup, and nios_network_view module have been removed from community.general 4.0.0 and were replaced by redirects to the `infoblox.nios_modules `_ collection. Please install the ``infoblox.nios_modules`` collection to continue using these plugins and modules, and update your FQCNs (https://github.com/ansible-collections/community.general/pull/3592). -- The vendored copy of ``ipaddress`` has been removed. Please use ``ipaddress`` from the Python 3 standard library, or `from pypi `_. (https://github.com/ansible-collections/community.general/pull/2441). -- cpanm - removed the deprecated ``system_lib`` option. Use Ansible's privilege escalation mechanism instead; the option basically used ``sudo`` (https://github.com/ansible-collections/community.general/pull/3461). -- grove - removed the deprecated alias ``message`` of the ``message_content`` option (https://github.com/ansible-collections/community.general/pull/3461). -- proxmox - default value of ``proxmox_default_behavior`` changed to ``no_defaults`` (https://github.com/ansible-collections/community.general/pull/3461). -- proxmox_kvm - default value of ``proxmox_default_behavior`` changed to ``no_defaults`` (https://github.com/ansible-collections/community.general/pull/3461). -- runit - removed the deprecated ``dist`` option which was not used by the module (https://github.com/ansible-collections/community.general/pull/3461). -- telegram - removed the deprecated ``msg``, ``msg_format`` and ``chat_id`` options (https://github.com/ansible-collections/community.general/pull/3461). -- xfconf - the default value of ``disable_facts`` changed to ``true``, and the value ``false`` is no longer allowed. Register the module results instead (https://github.com/ansible-collections/community.general/pull/3461). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- drop support for Python 2 and Python 3.5 (https://github.com/ansible-collections/community.hashi_vault/issues/81). -- support for the following deprecated environment variables has been removed: ``VAULT_AUTH_METHOD``, ``VAULT_TOKEN_PATH``, ``VAULT_TOKEN_FILE``, ``VAULT_ROLE_ID``, ``VAULT_SECRET_ID`` (https://github.com/ansible-collections/community.hashi_vault/pull/173). - -Deprecated Features -------------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - The ``--docker-no-pull`` option is deprecated and has no effect. -- ansible-test - The ``--no-pip-check`` option is deprecated and has no effect. -- include action is deprecated in favor of include_tasks, import_tasks and import_playbook. -- module_utils' FileLock is scheduled to be removed, it is not used due to its unreliable nature. - -amazon.aws -~~~~~~~~~~ - -- ec2 - the boto based ``ec2`` module has been deprecated in favour of the boto3 based ``ec2_instance`` module. The ``ec2`` module will be removed in release 4.0.0 (https://github.com/ansible-collections/amazon.aws/pull/424). -- ec2_classic_lb - setting of the ``ec2_elb`` fact has been deprecated and will be removed in release 4.0.0 of the collection. The module now returns ``elb`` which can be accessed using the register keyword (https://github.com/ansible-collections/amazon.aws/pull/552). -- ec2_vpc_dhcp_option - The ``new_config`` return key has been deprecated and will be removed in a future release. It will be replaced by ``dhcp_config``. Both values are returned in the interim. (https://github.com/ansible-collections/amazon.aws/pull/252) - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- network_cli - The paramiko_ssh setting ``look_for_keys`` was set automatically based on the values of the ``password`` and ``private_key_file`` options passed to network_cli. This option can now be set explicitly, and the automatic setting of ``look_for_keys`` will be removed after 2024-01-01 (https://github.com/ansible-collections/ansible.netcommon/pull/271). - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_reboot - Unreachable hosts can be ignored with ``ignore_errors: True``, this ability will be removed in a future version. Use ``ignore_unreachable: True`` to ignore unreachable hosts instead. - https://github.com/ansible-collections/ansible.windows/issues/62 -- win_updates - Deprecated the ``filtered_reason`` return value for each filtered up in favour of ``filtered_reasons``. This has been done to show all the reasons why an update was filtered and not just the first reason. -- win_updates - Deprecated the ``use_scheduled_task`` option as it is no longer used. -- win_updates - Deprecated the ``whitelist`` and ``blacklist`` options in favour of ``accept_list`` and ``reject_list`` respectively to conform to the new standards used in Ansible for these types of options. - -arista.eos -~~~~~~~~~~ - -- Remove testing with provider for ansible-test integration jobs. This helps prepare us to move to network-ee integration tests. - -cisco.ios -~~~~~~~~~ - -- Deprecated ios_bgp in favor of ios_bgp_global and ios_bgp_address_family. -- Deprecated ios_ntp modules. -- Remove testing with provider for ansible-test integration jobs. This helps prepare us to move to network-ee integration tests. - -cisco.iosxr -~~~~~~~~~~~ - -- The iosxr_logging module has been deprecated in favor of the new iosxr_logging_global resource module and will be removed in a release after '2023-08-01'. - -cisco.nxos -~~~~~~~~~~ - -- Deprecated `nxos_ntp`, `nxos_ntp_options`, `nxos_ntp_auth` modules. -- The nxos_logging module has been deprecated in favor of the new nxos_logging_global resource module and will be removed in a release after '2023-08-01'. - -community.aws -~~~~~~~~~~~~~ - -- dynamodb_table - DynamoDB does not support specifying non-key-attributes when creating an ``ALL`` index. Passing ``includes`` for such indexes is currently ignored but will result in failures after version 3.0.0 (https://github.com/ansible-collections/community.aws/pull/726). -- dynamodb_table - DynamoDB does not support updating the primary indexes on a table. Attempts to make such changes are currently ignored but will result in failures after version 3.0.0 (https://github.com/ansible-collections/community.aws/pull/726). -- ec2_elb - the ``ec2_elb`` module has been removed and redirected to the ``elb_instance`` module which functions identically. The original ``ec2_elb`` name is now deprecated and will be removed in release 3.0.0 (https://github.com/ansible-collections/community.aws/pull/586). -- ec2_elb_info - the boto based ``ec2_elb_info`` module has been deprecated in favour of the boto3 based ``elb_classic_lb_info`` module. The ``ec2_elb_info`` module will be removed in release 3.0.0 (https://github.com/ansible-collections/community.aws/pull/586). -- elb_classic_lb - the ``elb_classic_lb`` module has been removed and redirected to the ``amazon.aws.ec2_elb_lb`` module which functions identically. -- elb_instance - setting of the ``ec2_elb`` fact has been deprecated and will be removed in release 4.0.0 of the collection. See the module documentation for an alternative example using the register keyword (https://github.com/ansible-collections/community.aws/pull/773). -- iam - the boto based ``iam`` module has been deprecated in favour of the boto3 based ``iam_user``, ``iam_group`` and ``iam_role`` modules. The ``iam`` module will be removed in release 3.0.0 (https://github.com/ansible-collections/community.aws/pull/664). -- iam_cert - the iam_cert module has been renamed to iam_server_certificate for consistency with the companion iam_server_certificate_info module. The usage of the module has not changed. The iam_cert alias will be removed in version 4.0.0 (https://github.com/ansible-collections/community.aws/pull/728). -- iam_server_certificate - Passing file names to the ``cert``, ``chain_cert`` and ``key`` parameters has been deprecated. We recommend using a lookup plugin to read the files instead, see the documentation for an example (https://github.com/ansible-collections/community.aws/pull/735). -- iam_server_certificate - the default value for the ``dup_ok`` parameter is currently ``false``, in version 4.0.0 this will be updated to ``true``. To preserve the current behaviour explicitly set the ``dup_ok`` parameter to ``false`` (https://github.com/ansible-collections/community.aws/pull/737). -- rds - the boto based ``rds`` module has been deprecated in favour of the boto3 based ``rds_instance`` module. The ``rds`` module will be removed in release 3.0.0 (https://github.com/ansible-collections/community.aws/pull/663). -- rds_snapshot - the rds_snapshot module has been renamed to rds_instance_snapshot. The usage of the module has not changed. The rds_snapshot alias will be removed in version 4.0.0 (https://github.com/ansible-collections/community.aws/pull/783). -- script_inventory_ec2 - The ec2.py inventory script is being moved to a new repository. The script can now be downloaded from https://github.com/ansible-community/contrib-scripts/blob/main/inventory/ec2.py and will be removed from this collection in the 3.0 release. We recommend migrating from the script to the `amazon.aws.ec2` inventory plugin. - -community.azure -~~~~~~~~~~~~~~~ - -- All community.azure.azure_rm__facts modules are deprecated. Use azure.azcollection.azure_rm__info modules instead (https://github.com/ansible-collections/community.azure/pull/24). -- All community.azure.azure_rm__info modules are deprecated. Use azure.azcollection.azure_rm__info modules instead (https://github.com/ansible-collections/community.azure/pull/24). -- community.azure.azure_rm_managed_disk and community.azure.azure_rm_manageddisk are deprecated. Use azure.azcollection.azure_rm_manageddisk instead (https://github.com/ansible-collections/community.azure/pull/24). -- community.azure.azure_rm_virtualmachine_extension and community.azure.azure_rm_virtualmachineextension are deprecated. Use azure.azcollection.azure_rm_virtualmachineextension instead (https://github.com/ansible-collections/community.azure/pull/24). -- community.azure.azure_rm_virtualmachine_scaleset and community.azure.azure_rm_virtualmachinescaleset are deprecated. Use azure.azcollection.azure_rm_virtualmachinescaleset instead (https://github.com/ansible-collections/community.azure/pull/24). - -community.crypto -~~~~~~~~~~~~~~~~ - -- acme_* modules - ACME version 1 is now deprecated and support for it will be removed in community.crypto 2.0.0 (https://github.com/ansible-collections/community.crypto/pull/288). - -community.dns -~~~~~~~~~~~~~ - -- The hosttech_dns_records module has been renamed to hosttech_dns_record_sets. The old name will stop working in community.dns 3.0.0 (https://github.com/ansible-collections/community.dns/pull/31). - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_* modules and plugins, except ``docker_swarm`` connection plugin and ``docker_compose`` and ``docker_stack*` modules - the current default ``localhost`` for ``tls_hostname`` is deprecated. In community.docker 2.0.0 it will be computed from ``docker_host`` instead (https://github.com/ansible-collections/community.docker/pull/134). -- docker_container - the new ``command_handling``'s default value, ``compatibility``, is deprecated and will change to ``correct`` in community.docker 3.0.0. A deprecation warning is emitted by the module in cases where the behavior will change. Please note that ansible-core will output a deprecation warning only once, so if it is shown for an earlier task, there could be more tasks with this warning where it is not shown (https://github.com/ansible-collections/community.docker/pull/186). -- docker_container - using the special value ``all`` in ``published_ports`` has been deprecated. Use ``publish_all_ports=true`` instead (https://github.com/ansible-collections/community.docker/pull/210). - -community.general -~~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.general 5.0.0) next spring. While most content will probably still work with ansible-base 2.10, we will remove symbolic links for modules and action plugins, which will make it impossible to use them with Ansible 2.9 anymore. Please use community.general 4.x.y with Ansible 2.9 and ansible-base 2.10, as these releases will continue to support Ansible 2.9 and ansible-base 2.10 even after they are End of Life (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.general/pull/3723). -- ali_instance_info - marked removal version of deprecated parameters ``availability_zone`` and ``instance_names`` (https://github.com/ansible-collections/community.general/issues/2429). -- bitbucket_* modules - ``username`` options have been deprecated in favor of ``workspace`` and will be removed in community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/2045). -- dnsimple - python-dnsimple < 2.0.0 is deprecated and support for it will be removed in community.general 5.0.0 (https://github.com/ansible-collections/community.general/pull/2946#discussion_r667624693). -- gitlab_group_members - setting ``gitlab_group`` to ``name`` or ``path`` is deprecated. Use ``full_path`` instead (https://github.com/ansible-collections/community.general/pull/3451). -- keycloak_authentication - the return value ``flow`` is now deprecated and will be removed in community.general 6.0.0; use ``end_state`` instead (https://github.com/ansible-collections/community.general/pull/3280). -- keycloak_group - the return value ``group`` is now deprecated and will be removed in community.general 6.0.0; use ``end_state`` instead (https://github.com/ansible-collections/community.general/pull/3280). -- linode - parameter ``backupsenabled`` is deprecated and will be removed in community.general 5.0.0 (https://github.com/ansible-collections/community.general/pull/2410). -- lxd_container - the current default value ``true`` of ``ignore_volatile_options`` is deprecated and will change to ``false`` in community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/3429). -- serverless - deprecating parameter ``functions`` because it was not used in the code (https://github.com/ansible-collections/community.general/pull/2845). -- xfconf - deprecate the ``get`` state. The new module ``xfconf_info`` should be used instead (https://github.com/ansible-collections/community.general/pull/3049). - -community.grafana -~~~~~~~~~~~~~~~~~ - -- grafana_dashboard lookup - Providing a mangled version of the API key is no longer preferred. - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault collection - support for Python 2 will be dropped in version ``2.0.0`` of ``community.hashi_vault`` (https://github.com/ansible-collections/community.hashi_vault/issues/81). -- hashi_vault collection - support for Python 3.5 will be dropped in version ``2.0.0`` of ``community.hashi_vault`` (https://github.com/ansible-collections/community.hashi_vault/issues/81). -- lookup hashi_vault - the ``[lookup_hashi_vault]`` section in the ``ansible.cfg`` file is deprecated and will be removed in collection version ``3.0.0``. Instead, the section ``[hashi_vault_collection]`` can be used, which will apply to all plugins in the collection going forward (https://github.com/ansible-collections/community.hashi_vault/pull/144). - -community.kubernetes -~~~~~~~~~~~~~~~~~~~~ - -- The ``community.kubernetes`` collection is being renamed to ``kubernetes.core``. All content in the collection has been replaced by deprecated redirects to ``kubernetes.core``. If you are using FQCNs starting with ``community.kubernetes``, please update them to ``kubernetes.core`` (https://github.com/ansible-collections/community.kubernetes/pull/439). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_guest_vnc - Sphere 7.0 removed the built-in VNC server (https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-vcenter-server-70-release-notes.html#productsupport). - -inspur.sm -~~~~~~~~~ - -- add_ad_group - This feature will be removed in inspur.sm.add_ad_group 3.0.0. replaced with inspur.sm.ad_group. -- add_ldap_group - This feature will be removed in inspur.sm.add_ldap_group 3.0.0. replaced with inspur.sm.ldap_group. -- add_user - This feature will be removed in inspur.sm.add_user 3.0.0. replaced with inspur.sm.user. -- add_user_group - This feature will be removed in inspur.sm.add_user_group 3.0.0. replaced with inspur.sm.user_group. -- del_ad_group - This feature will be removed in inspur.sm.del_ad_group 3.0.0. replaced with inspur.sm.ad_group. -- del_ldap_group - This feature will be removed in inspur.sm.del_ldap_group 3.0.0. replaced with inspur.sm.ldap_group. -- del_user - This feature will be removed in inspur.sm.del_user 3.0.0. replaced with inspur.sm.user. -- del_user_group - This feature will be removed in inspur.sm.del_user_group 3.0.0. replaced with inspur.sm.user_group. -- edit_ad_group - This feature will be removed in inspur.sm.edit_ad_group 3.0.0. replaced with inspur.sm.ad_group. -- edit_ldap_group - This feature will be removed in inspur.sm.edit_ldap_group 3.0.0. replaced with inspur.sm.ldap_group. -- edit_user - This feature will be removed in inspur.sm.edit_user 3.0.0. replaced with inspur.sm.user. -- edit_user_group - This feature will be removed in inspur.sm.edit_user_group 3.0.0. replaced with inspur.sm.user_group. - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Deprecated router_id from ospfv2 resource module. -- Deprecated router_id from ospfv3 resource module. -- The junos_logging module has been deprecated in favor of the new junos_logging_global resource module and will be removed in a release after '2023-08-01'. - -vyos.vyos -~~~~~~~~~ - -- The vyos_logging module has been deprecated in favor of the new vyos_logging_global resource module and will be removed in a release after "2023-08-01". diff --git a/docs/docsite/rst/porting_guides/porting_guide_6.rst b/docs/docsite/rst/porting_guides/porting_guide_6.rst deleted file mode 100644 index d7a0e98dd46..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_6.rst +++ /dev/null @@ -1,964 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_core_2.13.rst) - -.. _porting_6_guide: - -======================= -Ansible 6 Porting Guide -======================= - -.. contents:: - :local: - :depth: 2 - - -Ansible 6 is based on Ansible-core 2.13. - - -We suggest you read this page along with the `Ansible 6 Changelog `_ to understand what updates you may need to make. - - -Playbook -======== - -* Templating - You can no longer perform arithmetic and concatenation operations outside of the jinja template. The following statement will need to be rewritten to produce ``[1, 2]``: - - .. code-block:: yaml - - - name: Prior to 2.13 - debug: - msg: '[1] + {{ [2] }}' - - - name: 2.13 and forward - debug: - msg: '{{ [1] + [2] }}' - -* The return value of the ``__repr__`` method of an undefined variable represented by the ``AnsibleUndefined`` object changed. ``{{ '%r'|format(undefined_variable) }}`` returns ``AnsibleUndefined(hint=None, obj=missing, name='undefined_variable')`` in 2.13 as opposed to just ``AnsibleUndefined`` in versions 2.12 and prior. - -* The ``finalize`` method is no longer exposed in the globals for use in templating. To convert ``None`` to an empty string the following expression can be used: ``{{ value if value is not none }}``. - - -Command Line -============ - -No notable changes - - -Deprecated -========== - -No notable changes - - -Modules -======= - -* To use ansible-core 2.13 for module execution, you must use Python 2 version 2.7 or Python 3 version 3.5 or newer. Any code utilizing ``ansible.module_utils.basic`` will not function with lower Python versions. - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Breaking Changes ----------------- - -* ``ansible.module_utils.urls.fetch_url`` will now return the captured ``HTTPError`` exception as ``r``. ``HTTPError`` is a response like object that can offer more information to module authors. Modules should rely on ``info['status'] >= 400`` to determine if there was a failure, instead of using ``r is None`` or catching ``AttributeError`` when attempting ``r.read()``. - - -Plugins -======= - -No notable changes - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes - -Porting Guide for v6.7.0 -======================== - -Known Issues ------------- - -community.routeros -~~~~~~~~~~~~~~~~~~ - -- api_modify - when limits for entries in ``queue tree`` are defined as human readable - for example ``25M`` -, the configuration will be correctly set in ROS, but the module will indicate the item is changed on every run even when there was no change done. This is caused by the ROS API which returns the number in bytes - for example ``25000000`` (which is inconsistent with the CLI behavior). In order to mitigate that, the limits have to be defined in bytes (those will still appear as human readable in the ROS CLI) (https://github.com/ansible-collections/community.routeros/pull/131). -- api_modify, api_info - ``routing ospf area``, ``routing ospf area range``, ``routing ospf instance``, ``routing ospf interface-template`` paths are not fully implemeted for ROS6 due to the significat changes between ROS6 and ROS7 (https://github.com/ansible-collections/community.routeros/pull/131). - -Major Changes -------------- - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_mr_l7_firewall - New module -- meraki_webhook_payload_template - New module - -community.zabbix -~~~~~~~~~~~~~~~~ - -- all modules are opting away from zabbix-api and using httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate -- zabbix_agent and zabbix_proxy roles are opting away from zabbix-api and use httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate - -containers.podman -~~~~~~~~~~~~~~~~~ - -- New become plugin - podman_unshare -- Podman generate systemd module - -fortinet.fortimanager -~~~~~~~~~~~~~~~~~~~~~ - -- Fix compatibility issue for ansible 2.9.x and ansible-base 2.10.x. -- support Ansible changelogs. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support FortiOS v7.0.6, v7.0.7, v7.0.8, v7.2.1, v7.2.2. - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- Please note that some tools, like the VScode plugin (https://github.com/ansible/vscode-ansible/issues/573), or ``ansible-doc --list --type module``, suggest to replace the correct FQCNs for modules and actions in community.general with internal names that have more than three components. For example, ``community.general.ufw`` is suggested to be replaced by ``community.general.system.ufw``. While these longer names do work, they are considered **internal names** by the collection and are subject to change and be removed at all time. They **will** be removed in community.general 6.0.0 and result in deprecation messages. Avoid using these internal names, and use general three-component FQCNs (``community.general.``) instead (https://github.com/ansible-collections/community.general/pull/5373). - -Porting Guide for v6.6.0 -======================== - -Added Collections ------------------ - -- lowlydba.sqlserver (version 1.0.4) - -Known Issues ------------- - -community.routeros -~~~~~~~~~~~~~~~~~~ - -- The ``community.routeros.command`` module claims to support check mode. Since it cannot judge whether the commands executed modify state or not, this behavior is incorrect. Since this potentially breaks existing playbooks, we will not change this behavior until community.routeros 3.0.0. - -Breaking Changes ----------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- newrelic_deployment - ``revision`` is required for v2 API (https://github.com/ansible-collections/community.general/pull/5341). - -Major Changes -------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- newrelic_deployment - removed New Relic v1 API, added support for v2 API (https://github.com/ansible-collections/community.general/pull/5341). - -fortinet.fortimanager -~~~~~~~~~~~~~~~~~~~~~ - -- Many fixes for Ansible sanity test warnings & errors. -- Support FortiManager Schema 7.2.0 , 98 new modules - -Deprecated Features -------------------- - -- The mellanox.onyx collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/136). - -cisco.mso -~~~~~~~~~ - -- The mso_schema_template_contract_filter contract_filter_type attribute is deprecated. The value is now deduced from filter_type. - -community.general -~~~~~~~~~~~~~~~~~ - -- ArgFormat module utils - deprecated along ``CmdMixin``, in favor of the ``cmd_runner_fmt`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- CmdMixin module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- CmdModuleHelper module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- CmdStateModuleHelper module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- django_manage - support for Django releases older than 4.1 has been deprecated and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5400). -- django_manage - support for the commands ``cleanup``, ``syncdb`` and ``validate`` that have been deprecated in Django long time ago will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5400). -- django_manage - the behavior of "creating the virtual environment when missing" is being deprecated and will be removed in community.general version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5405). -- newrelic_deployment - ``appname`` and ``environment`` are no longer valid options in the v2 API. They will be removed in community.general 7.0.0 (https://github.com/ansible-collections/community.general/pull/5341). - -Porting Guide for v6.5.0 -======================== - -Major Changes -------------- - -infoblox.nios_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Feature for extra layer security , with `cert` and `key` parameters in playbooks for authenticating using certificate and key ``*.pem`` file absolute path `#154 `_ -- Fix to remove issue causing due to template attr in deleting network using Ansible module nios network `#147 `_ - -Deprecated Features -------------------- - -- The dellemc.os10 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/134). -- The dellemc.os6 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/132). -- The dellemc.os9 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/133). - -community.general -~~~~~~~~~~~~~~~~~ - -- lxc_container - the module will no longer make any effort to support Python 2 (https://github.com/ansible-collections/community.general/pull/5304). - -Porting Guide for v6.4.0 -======================== - -Added Collections ------------------ - -- inspur.ispim (version 1.0.1) -- vultr.cloud (version 1.1.0) - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- proxmox - deprecated the current ``unprivileged`` default value, will be changed to ``true`` in community.general 7.0.0 (https://github.com/pull/5224). - -Porting Guide for v6.3.0 -======================== - -Major Changes -------------- - -community.mysql -~~~~~~~~~~~~~~~ - -- mysql_db - the ``pipefail`` argument's default value will be changed to ``true`` in community.mysql 4.0.0. If your target machines do not use ``bash`` as a default interpreter, set ``pipefail`` to ``false`` explicitly. However, we strongly recommend setting up ``bash`` as a default and ``pipefail=true`` as it will protect you from getting broken dumps you don't know about (https://github.com/ansible-collections/community.mysql/issues/407). - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support Diff feature in check_mode. -- Support Fortios 7.2.0. - -Deprecated Features -------------------- - -- The google.cloud collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/105). -- The servicenow.servicenow collection has been deprecated by its maintainers (https://github.com/ServiceNowITOM/servicenow-ansible/pull/69) and will be removed from Ansible 7. It can still be installed manually, but it is suggested to switch to `servicenow.itsm `__ instead (https://github.com/ansible-community/community-topics/issues/124). - -Porting Guide for v6.2.0 -======================== - -Added Collections ------------------ - -- ibm.spectrum_virtualize (version 1.9.0) - -Known Issues ------------- - -netapp.ontap -~~~~~~~~~~~~ - -- na_ontap_snapshot - added documentation to use UTC format for ``expiry_time``. - -Major Changes -------------- - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_user - the ``groups`` argument has been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``postgresql_membership`` module to specify group/role memberships instead (https://github.com/ansible-collections/community.postgresql/issues/277). - -Deprecated Features -------------------- - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- vault_kv2_get lookup - the ``engine_mount_point option`` in the ``vault_kv2_get`` lookup only will change its default from ``kv`` to ``secret`` in community.hashi_vault version 4.0.0 (https://github.com/ansible-collections/community.hashi_vault/issues/279). - -Porting Guide for v6.1.0 -======================== - -Added Collections ------------------ - -- purestorage.fusion (version 1.0.2) - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_application_alerts_smtp - Issue(212310) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_device_local_access_configuration - Issue(215035) - The module reports ``Successfully updated the local access setting`` if an unsupported value is provided for the parameter timeout_limit. However, this value is not actually applied on OpenManage Enterprise Modular. -- ome_device_local_access_configuration - Issue(217865) - The module does not display a proper error message if an unsupported value is provided for the user_defined and lcd_language parameters. -- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout. -- ome_device_power_settings - Issue(212679) - The module displays the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_device_quick_deploy - Issue(216352) - The module does not display a proper error message if an unsupported value is provided for the ipv6_prefix_length and vlan_id parameters. -- ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Major Changes -------------- - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Added bootstrap_script option to allow users to target a script URL for installing Chocolatey on clients. -- win_chocolatey_facts - Added outdated packages list to data returned. - -infoblox.nios_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Update `text` field of TXT Record `#128 `_ -- Update operation using `old_name` and `new_name` for the object with dummy name in `old_name` (which does not exist in system) will not create a new object in the system. An error will be thrown stating the object does not exist in the system `#129 `_ - -Deprecated Features -------------------- - -cisco.ios -~~~~~~~~~ - -- Deprecated ios_linkagg_module in favor of ios_lag_interfaces. - -community.aws -~~~~~~~~~~~~~ - -- aws_codebuild - The ``tags`` parameter currently uses a non-standard format and has been deprecated. In release 6.0.0 this parameter will accept a simple key/value pair dictionary instead of the current list of dictionaries. It is recommended to migrate to using the resource_tags parameter which already accepts the simple dictionary format (https://github.com/ansible-collections/community.aws/pull/1221). -- route53_info - The CamelCase return values for ``HostedZones``, ``ResourceRecordSets``, and ``HealthChecks`` have been deprecated, in the future release you must use snake_case return values ``hosted_zones``, ``resource_record_sets``, and ``health_checks`` instead respectively". - -community.crypto -~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.crypto 3.0.0). Some modules might still work with these versions afterwards, but we will no longer keep compatibility code that was needed to support them (https://github.com/ansible-collections/community.crypto/pull/460). - -community.docker -~~~~~~~~~~~~~~~~ - -- Support for Docker API version 1.20 to 1.24 has been deprecated and will be removed in community.docker 3.0.0. The first Docker version supporting API version 1.25 was Docker 1.13, released in January 2017. This affects the modules ``docker_container``, ``docker_container_exec``, ``docker_container_info``, ``docker_compose``, ``docker_login``, ``docker_image``, ``docker_image_info``, ``docker_image_load``, ``docker_host_info``, ``docker_network``, ``docker_network_info``, ``docker_node_info``, ``docker_swarm_info``, ``docker_swarm_service``, ``docker_swarm_service_info``, ``docker_volume_info``, and ``docker_volume``, whose minimally supported API version is between 1.20 and 1.24 (https://github.com/ansible-collections/community.docker/pull/396). -- Support for Python 2.6 is deprecated and will be removed in the next major release (community.docker 3.0.0). Some modules might still work with Python 2.6, but we will no longer try to ensure compatibility (https://github.com/ansible-collections/community.docker/pull/388). - -community.general -~~~~~~~~~~~~~~~~~ - -- cmd_runner module utils - deprecated ``fmt`` in favour of ``cmd_runner_fmt`` as the parameter format object (https://github.com/ansible-collections/community.general/pull/4777). - -Porting Guide for v6.0.0 -======================== - -Added Collections ------------------ - -- cisco.dnac (version 6.4.0) -- community.sap (version 1.0.0) -- community.sap_libs (version 1.1.0) -- vmware.vmware_rest (version 2.1.5) - -Known Issues ------------- - -Ansible-core -~~~~~~~~~~~~ - -- get_url - document ``check_mode`` correctly with unreliable changed status (https://github.com/ansible/ansible/issues/65687). - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- eos - When using eos modules on Ansible 2.9, tasks will occasionally fail with ``import_modules`` enabled. This can be avoided by setting ``import_modules: no`` - -community.general -~~~~~~~~~~~~~~~~~ - -- pacman - ``update_cache`` cannot differentiate between up to date and outdated package lists and will report ``changed`` in both situations (https://github.com/ansible-collections/community.general/pull/4318). -- pacman - binaries specified in the ``executable`` parameter must support ``--print-format`` in order to be used by this module. In particular, AUR helper ``yay`` is known not to currently support it (https://github.com/ansible-collections/community.general/pull/4312). - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_application_alerts_smtp - Issue(212310) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_application_console_preferences - Issue(224690) - The module does not display a proper error message when an unsupported value is provided for the parameters report_row_limit, email_sender_settings, and metric_collection_settings, and the value is applied on OpenManage Enterprise. -- ome_device_local_access_configuration - Issue(215035) - The module reports ``Successfully updated the local access setting`` if an unsupported value is provided for the parameter timeout_limit. However, this value is not actually applied on OpenManage Enterprise Modular. -- ome_device_local_access_configuration - Issue(217865) - The module does not display a proper error message if an unsupported value is provided for the user_defined and lcd_language parameters. -- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout. -- ome_device_power_settings - Issue(212679) - The module displays the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_device_power_settings - Issue(212679) - The module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_device_power_settings - Issue(212679) - The module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_device_quick_deploy - Issue(216352) - The module does not display a proper error message if an unsupported value is provided for the ipv6_prefix_length and vlan_id parameters. -- ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -purestorage.flasharray -~~~~~~~~~~~~~~~~~~~~~~ - -- purefa_admin - Once `max_login` and `lockout` have been set there is currently no way to rest these to zero except through the FlashArray GUI - -Breaking Changes ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- Module Python Dependency - Drop support for Python 2.6 in module execution. -- Templating - it is no longer allowed to perform arithmetic and concatenation operations outside of the jinja template (https://github.com/ansible/ansible/pull/75587) -- The ``finalize`` method is no longer exposed in the globals for use in templating. - -amazon.aws -~~~~~~~~~~ - -- aws_caller_facts - Remove deprecated ``aws_caller_facts`` alias. Please use ``aws_caller_info`` instead. -- cloudformation_facts - Remove deprecated ``cloudformation_facts`` alias. Please use ``cloudformation_info`` instead. -- ec2_ami_facts - Remove deprecated ``ec2_ami_facts`` alias. Please use ``ec2_ami_info`` instead. -- ec2_eni_facts - Remove deprecated ``ec2_eni_facts`` alias. Please use ``ec2_eni_info`` instead. -- ec2_group_facts - Remove deprecated ``ec2_group_facts`` alias. Please use ``ec2_group_info`` instead. -- ec2_instance_facts - Remove deprecated ``ec2_instance_facts`` alias. Please use ``ec2_instance_info`` instead. -- ec2_snapshot_facts - Remove deprecated ``ec2_snapshot_facts`` alias. Please use ``ec2_snapshot_info`` instead. -- ec2_vol_facts - Remove deprecated ``ec2_vol_facts`` alias. Please use ``ec2_vol_info`` instead. -- ec2_vpc_dhcp_option_facts - Remove deprecated ``ec2_vpc_dhcp_option_facts`` alias. Please use ``ec2_vpc_dhcp_option_info`` instead. -- ec2_vpc_endpoint_facts - Remove deprecated ``ec2_vpc_endpoint_facts`` alias. Please use ``ec2_vpc_endpoint_info`` instead. -- ec2_vpc_igw_facts - Remove deprecated ``ec2_vpc_igw_facts`` alias. Please use ``ec2_vpc_igw_info`` instead. -- ec2_vpc_nat_gateway_facts - Remove deprecated ``ec2_vpc_nat_gateway_facts`` alias. Please use ``ec2_vpc_nat_gateway_info`` instead. -- ec2_vpc_net_facts - Remove deprecated ``ec2_vpc_net_facts`` alias. Please use ``ec2_vpc_net_info`` instead. -- ec2_vpc_route_table_facts - Remove deprecated ``ec2_vpc_route_table_facts`` alias. Please use ``ec2_vpc_route_table_info`` instead. -- ec2_vpc_subnet_facts - Remove deprecated ``ec2_vpc_subnet_facts`` alias. Please use ``ec2_vpc_subnet_info`` instead. - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- httpapi - Change default value of ``import_modules`` option from ``no`` to ``yes`` -- netconf - Change default value of ``import_modules`` option from ``no`` to ``yes`` -- network_cli - Change default value of ``import_modules`` option from ``no`` to ``yes`` - -arista.eos -~~~~~~~~~~ - -- eos_command - new suboption ``version`` of parameter ``command``, which controls the JSON response version. Previously the value was assumed to be "latest" for network_cli and "1" for httpapi, but the default will now be "latest" for both connections. This option is also available for use in modules making their own device requests with ``plugins.module_utils.network.eos.eos.run_commands()`` with the same new default behavior. (https://github.com/ansible-collections/arista.eos/pull/258). -- httpapi - the ``eos_use_sessions`` option is now a boolean instead of an integer. - -community.aws -~~~~~~~~~~~~~ - -- aws_acm_facts - Remove deprecated alias ``aws_acm_facts``. Please use ``aws_acm_info`` instead. -- aws_kms_facts - Remove deprecated alias ``aws_kms_facts``. Please use ``aws_kms_info`` instead. -- aws_kms_info - Deprecated ``keys_attr`` field is now ignored (https://github.com/ansible-collections/community.aws/pull/838). -- aws_region_facts - Remove deprecated alias ``aws_region_facts``. Please use ``aws_region_info`` instead. -- aws_s3_bucket_facts - Remove deprecated alias ``aws_s3_bucket_facts``. Please use ``aws_s3_bucket_info`` instead. -- aws_sgw_facts - Remove deprecated alias ``aws_sgw_facts``. Please use ``aws_sgw_info`` instead. -- aws_waf_facts - Remove deprecated alias ``aws_waf_facts``. Please use ``aws_waf_info`` instead. -- cloudfront_facts - Remove deprecated alias ``cloudfront_facts``. Please use ``cloudfront_info`` instead. -- cloudwatchlogs_log_group_facts - Remove deprecated alias ``cloudwatchlogs_log_group_facts``. Please use ``cloudwatchlogs_log_group_info`` instead. -- dynamodb_table - deprecated updates currently ignored for primary keys and global_all indexes will now result in a failure. (https://github.com/ansible-collections/community.aws/pull/837). -- ec2_asg_facts - Remove deprecated alias ``ec2_asg_facts``. Please use ``ec2_asg_info`` instead. -- ec2_customer_gateway_facts - Remove deprecated alias ``ec2_customer_gateway_facts``. Please use ``ec2_customer_gateway_info`` instead. -- ec2_eip_facts - Remove deprecated alias ``ec2_eip_facts``. Please use ``ec2_eip_info`` instead. -- ec2_elb_facts - Remove deprecated alias ``ec2_elb_facts``. Please use ``ec2_elb_info`` instead. -- ec2_elb_info - The ``ec2_elb_info`` module has been removed. Please use ``the ``elb_classic_lb_info`` module. -- ec2_lc_facts - Remove deprecated alias ``ec2_lc_facts``. Please use ``ec2_lc_info`` instead. -- ec2_placement_group_facts - Remove deprecated alias ``ec2_placement_group_facts``. Please use ``ec2_placement_group_info`` instead. -- ec2_vpc_nacl_facts - Remove deprecated alias ``ec2_vpc_nacl_facts``. Please use ``ec2_vpc_nacl_info`` instead. -- ec2_vpc_peering_facts - Remove deprecated alias ``ec2_vpc_peering_facts``. Please use ``ec2_vpc_peering_info`` instead. -- ec2_vpc_route_table_facts - Remove deprecated alias ``ec2_vpc_route_table_facts``. Please use ``ec2_vpc_route_table_info`` instead. -- ec2_vpc_vgw_facts - Remove deprecated alias ``ec2_vpc_vgw_facts``. Please use ``ec2_vpc_vgw_info`` instead. -- ec2_vpc_vpn_facts - Remove deprecated alias ``ec2_vpc_vpn_facts``. Please use ``ec2_vpc_vpn_info`` instead. -- ecs_service_facts - Remove deprecated alias ``ecs_service_facts``. Please use ``ecs_service_info`` instead. -- ecs_taskdefinition_facts - Remove deprecated alias ``ecs_taskdefinition_facts``. Please use ``ecs_taskdefinition_info`` instead. -- efs_facts - Remove deprecated alias ``efs_facts``. Please use ``efs_info`` instead. -- elasticache_facts - Remove deprecated alias ``elasticache_facts``. Please use ``elasticache_info`` instead. -- elb_application_lb_facts - Remove deprecated alias ``elb_application_lb_facts``. Please use ``elb_application_lb_info`` instead. -- elb_classic_lb_facts - Remove deprecated alias ``elb_classic_lb_facts``. Please use ``elb_classic_lb_info`` instead. -- elb_target_facts - Remove deprecated alias ``elb_target_facts``. Please use ``elb_target_info`` instead. -- elb_target_group_facts - Remove deprecated alias ``elb_target_group_facts``. Please use ``elb_target_group_info`` instead. -- iam - Removed deprecated ``community.aws.iam`` module. Please use ``community.aws.iam_user``, ``community.aws.iam_access_key`` or ``community.aws.iam_group`` (https://github.com/ansible-collections/community.aws/pull/839). -- iam_cert_facts - Remove deprecated alias ``iam_cert_facts``. Please use ``iam_cert_info`` instead. -- iam_mfa_device_facts - Remove deprecated alias ``iam_mfa_device_facts``. Please use ``iam_mfa_device_info`` instead. -- iam_role_facts - Remove deprecated alias ``iam_role_facts``. Please use ``iam_role_info`` instead. -- iam_server_certificate_facts - Remove deprecated alias ``iam_server_certificate_facts``. Please use ``iam_server_certificate_info`` instead. -- lambda_facts - Remove deprecated module lambda_facts``. Please use ``lambda_info`` instead. -- rds - Removed deprecated ``community.aws.rds`` module. Please use ``community.aws.rds_instance`` (https://github.com/ansible-collections/community.aws/pull/839). -- rds_instance_facts - Remove deprecated alias ``rds_instance_facts``. Please use ``rds_instance_info`` instead. -- rds_snapshot_facts - Remove deprecated alias ``rds_snapshot_facts``. Please use ``rds_snapshot_info`` instead. -- redshift_facts - Remove deprecated alias ``redshift_facts``. Please use ``redshift_info`` instead. -- route53_facts - Remove deprecated alias ``route53_facts``. Please use ``route53_info`` instead. - -community.general -~~~~~~~~~~~~~~~~~ - -- Parts of this collection do not work with ansible-core 2.11 on Python 3.12+. Please either upgrade to ansible-core 2.12+, or use Python 3.11 or earlier (https://github.com/ansible-collections/community.general/pull/3988). -- The symbolic links used to implement flatmapping for all modules were removed and replaced by ``meta/runtime.yml`` redirects. This effectively breaks compatibility with Ansible 2.9 for all modules (without using their "long" names, which is discouraged and which can change without previous notice since they are considered an implementation detail) (https://github.com/ansible-collections/community.general/pull/4548). -- a_module test plugin - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- archive - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- git_config - remove Ansible 2.9 and early ansible-base 2.10 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- java_keystore - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- lists_mergeby and groupby_as_dict filter plugins - adjust filter plugin filename. This change is not visible to end-users, it only affects possible other collections importing Python paths (https://github.com/ansible-collections/community.general/pull/4625). -- lists_mergeby filter plugin - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- maven_artifact - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- memcached cache plugin - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- path_join filter plugin shim - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- redis cache plugin - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- yarn - remove unsupported and unnecessary ``--no-emoji`` flag (https://github.com/ansible-collections/community.general/pull/4662). - -community.mysql -~~~~~~~~~~~~~~~ - -- mysql_replication - remove ``Is_Slave`` and ``Is_Master`` return values (were replaced with ``Is_Primary`` and ``Is_Replica`` (https://github.com/ansible-collections /community.mysql/issues/145). -- mysql_replication - remove the mode options values containing ``master``/``slave`` and the master_use_gtid option ``slave_pos`` (were replaced with corresponding ``primary``/``replica`` values) (https://github.com/ansible-collections/community.mysql/issues/145). -- mysql_user - remove support for the `REQUIRESSL` special privilege as it has ben superseded by the `tls_requires` option (https://github.com/ansible-collections/community.mysql/discussions/121). -- mysql_user - validate privileges using database engine directly (https://github.com/ansible-collections/community.mysql/issues/234 https://github.com/ansible-collections/community.mysql/pull/243). Do not validate privileges in this module anymore. - -community.vmware -~~~~~~~~~~~~~~~~ - -- The collection now requires at least ansible-core 2.11.0. Ansible 3 and before, and ansible-base versions are no longer supported. -- vmware_cluster_drs - The default for ``enable`` has been changed from ``false`` to ``true``. -- vmware_cluster_drs - The parameter alias ``enable_drs`` has been removed, use ``enable`` instead. -- vmware_cluster_ha - The default for ``enable`` has been changed from ``false`` to ``true``. -- vmware_cluster_ha - The parameter alias ``enable_ha`` has been removed, use ``enable`` instead. -- vmware_cluster_vsan - The default for ``enable`` has been changed from ``false`` to ``true``. -- vmware_cluster_vsan - The parameter alias ``enable_vsan`` has been removed, use ``enable`` instead. -- vmware_guest - Virtualization Based Security has some requirements (``nested_virt``, ``secure_boot`` and ``iommu``) that the module silently enabled. They have to be enabled explicitly now. - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- HTTPS SSL certificate validation is a **breaking change** and will require modification in the existing playbooks. Please refer to `SSL Certificate Validation `_ section in the `README.md `_ for modification to existing playbooks. - -theforeman.foreman -~~~~~~~~~~~~~~~~~~ - -- Set use_reports_api default value to true for the inventory plugin -- Support for Ansible 2.8 is removed - -Major Changes -------------- - -- Add a ``ansible-community`` CLI tool that allows to print the version of the Ansible community distribution. Use ``ansible-community --version`` to print this version. - -Ansible-core -~~~~~~~~~~~~ - -- Jinja2 Controller Requirement - Jinja2 3.0.0 or newer is required for the control node (the machine that runs Ansible) (https://github.com/ansible/ansible/pull/75881) -- Templating - remove ``safe_eval`` in favor of using ``NativeEnvironment`` but utilizing ``literal_eval`` only in cases when ``safe_eval`` was used (https://github.com/ansible/ansible/pull/75587) - -amazon.aws -~~~~~~~~~~ - -- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.19.0`` and ``boto3<1.16.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/574). - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- cli_parse - this module has been moved to the ansible.utils collection. ``ansible.netcommon.cli_parse`` will continue to work to reference the module in its new location, but this redirect will be removed in a future release -- network_cli - Change default value of `ssh_type` option from `paramiko` to `auto`. This value will use libssh if the ansible-pylibssh module is installed, otherwise will fallback to paramiko. - -arista.eos -~~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. -- `eos_facts` - change default gather_subset to `min` from `!config` (https://github.com/ansible-collections/arista.eos/issues/306). - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Added choco_args option to pass additional arguments directly to Chocolatey. - -cisco.asa -~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. - -cisco.ios -~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. -- facts - default value for gather_subset is changed to min instead of !config. - -cisco.iosxr -~~~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. -- `facts` - default value for `gather_subset` is changed to min instead of !config. - -cisco.ise -~~~~~~~~~ - -- Update ciscoisesdk requirement to 1.2.0 -- anc_endpoint_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- anc_policy_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- backup_last_status_info - change return value, it returns response content. -- device_administration_authentication_rules - deletes parameter identitySourceId. -- device_administration_authentication_rules_info - change return value, it returns response content. -- device_administration_authorization_rules_info - change return value, it returns response content. -- device_administration_conditions - deletes parameter attributeId. -- device_administration_conditions_for_authentication_rule_info - change return value, it returns response content. -- device_administration_conditions_for_authorization_rule_info - change return value, it returns response content. -- device_administration_conditions_for_policy_set_info - change return value, it returns response content. -- device_administration_conditions_info - change return value, it returns response content. -- device_administration_dictionary_attributes_authentication_info - change return value, it returns response content. -- device_administration_dictionary_attributes_authorization_info - change return value, it returns response content. -- device_administration_dictionary_attributes_policy_set_info - change return value, it returns response content. -- device_administration_global_exception_rules_info - change return value, it returns response content. -- device_administration_network_conditions_info - change return value, it returns response content. -- device_administration_time_date_conditions - deletes parameter attributeId. -- device_administration_time_date_conditions_info - change return value, it returns response content. -- egress_matrix_cell_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- network_access_authentication_rules - deletes parameter identitySourceId. -- network_access_conditions - deletes parameter attributeId. -- network_access_time_date_conditions - deletes parameter attributeId. -- node_deployment - update parameters. -- node_deployment_info - add filter and filterType parameters. -- node_group - fixes response recollection. -- node_group_info - fixes response recollection. -- repository_files_info - change return value, it returns response content. -- repository_info - change return value, it returns response content. -- sg_acl_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sg_mapping_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sg_mapping_group_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sg_mapping_group_info - change return value, it returns BulkStatus content. -- sg_to_vn_to_vlan_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sgt - change generationId type from int to str. -- sgt_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sxp_connections_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sxp_local_bindings_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sxp_vpns_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- system_certificate - new parameters portalTagTransferForSameSubject and roleTransferForSameSubject. -- system_certificate - portalTagTransferForSameSubject parameter renamed to allowPortalTagTransferForSameSubject. -- system_certificate - roleTransferForSameSubject parameter renamed to allowRoleTransferForSameSubject. -- system_certificate_import - new parameters portalTagTransferForSameSubject and roleTransferForSameSubject. -- system_certificate_import - portalTagTransferForSameSubject parameter renamed to allowPortalTagTransferForSameSubject. -- system_certificate_import - roleTransferForSameSubject parameter renamed to allowRoleTransferForSameSubject. -- trustsec_nbar_app_info - change type from str to list. -- trustsec_vn_info - change type from str to list. - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_mr_radio - New module - -cisco.nxos -~~~~~~~~~~ - -- The minimum required ansible.netcommon version has been bumped to v2.6.1. -- Updated base plugin references to ansible.netcommon. -- `nxos_facts` - change default gather_subset to `min` from `!config` (https://github.com/ansible-collections/cisco.nxos/issues/418). -- nxos_file_copy has been rewritten as a module. This change also removes the dependency on pexpect for file_pull operation. Since this now uses AnsibleModule class for argspec validation, the validation messages will be slightly different. Expect changes in the return payload in some cases. All functionality remains unchanged. - -community.aws -~~~~~~~~~~~~~ - -- community.aws collection - The community.aws collection has dropped support for ``botocore<1.19.0`` and ``boto3<1.16.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/809). -- s3_bucket_notifications - refactor module to support SNS / SQS targets as well as the existing support for Lambda functions (https://github.com/ansible-collections/community.aws/issues/140). - -community.general -~~~~~~~~~~~~~~~~~ - -- The community.general collection no longer supports Ansible 2.9 and ansible-base 2.10. While we take no active measures to prevent usage, we will remove a lot of compatibility code and other compatility measures that will effectively prevent using most content from this collection with Ansible 2.9, and some content of this collection with ansible-base 2.10. Both Ansible 2.9 and ansible-base 2.10 will very soon be End of Life and if you are still using them, you should consider upgrading to ansible-core 2.11 or later as soon as possible (https://github.com/ansible-collections/community.general/pull/4548). - -community.mysql -~~~~~~~~~~~~~~~ - -- The community.mysql collection no longer supports ``Ansible 2.9`` and ``ansible-base 2.10``. While we take no active measures to prevent usage and there are no plans to introduce incompatible code to the modules, we will stop testing against ``Ansible 2.9`` and ``ansible-base 2.10``. Both will very soon be End of Life and if you are still using them, you should consider upgrading to the ``latest Ansible / ansible-core 2.11 or later`` as soon as possible (https://github.com/ansible-collections/community.mysql/pull/343). - -community.network -~~~~~~~~~~~~~~~~~ - -- The community.network collection no longer supports Ansible 2.9 and ansible-base 2.10. While we take no active measures to prevent usage, we will remove compatibility code and other compatility measures that will effectively prevent using most content from this collection with Ansible 2.9, and some content of this collection with ansible-base 2.10. Both Ansible 2.9 and ansible-base 2.10 will very soon be End of Life and if you are still using them, you should consider upgrading to ansible-core 2.11 or later as soon as possible (https://github.com/ansible-collections/community.network/pull/426). - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- The community.postgresql collection no longer supports ``Ansible 2.9`` and ``ansible-base 2.10``. While we take no active measures to prevent usage and there are no plans to introduce incompatible code to the modules, we will stop testing against ``Ansible 2.9`` and ``ansible-base 2.10``. Both will very soon be End of Life and if you are still using them, you should consider upgrading to the ``latest Ansible / ansible-core 2.11 or later`` as soon as possible (https://github.com/ansible-collections/community.postgresql/pull/245). -- postgresql_privs - the ``usage_on_types`` feature have been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``type`` option with the ``type`` value to explicitly grant/revoke privileges on types (https://github.com/ansible-collections/community.postgresql/issues/207). -- postgresql_query - the ``path_to_script`` and ``as_single_query`` options as well as the ``query_list`` and ``query_all_results`` return values have been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``community.postgresql.postgresql_script`` module to execute statements from scripts (https://github.com/ansible-collections/community.postgresql/issues/189). -- postgresql_query - the default value of the ``as_single_query`` option changes to ``yes``. If the related behavior of your tasks where the module is involved changes, please adjust the parameter's value correspondingly (https://github.com/ansible-collections/community.postgresql/issues/85). -- postgresql_user - the ``priv`` argument has been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``postgresql_privs`` module to grant/revoke privileges instead (https://github.com/ansible-collections/community.postgresql/issues/212). - -community.vmware -~~~~~~~~~~~~~~~~ - -- Drop VCSIM as a test target (https://github.com/ansible-collections/community.vmware/pull/1294). - -containers.podman -~~~~~~~~~~~~~~~~~ - -- Add podman_tag module -- Add secrets driver and driver opts support - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- All modules can read custom or organizational CA signed certificate from the environment variables. Please refer to `SSL Certificate Validation `_ section in the `README.md `_ for modification to existing playbooks or setting environment variable. -- All modules now support SSL over HTTPS and socket level timeout. -- idrac_server_config_profile - The module is enhanced to support export, import, and preview the SCP configuration using Redfish and added support for check mode. - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- bigip_device_info - pagination logic has also been added to help with api stability. -- bigip_device_info - the module no longer gathers information from all partitions on device. This change will stabalize the module by gathering resources only from the given partition and prevent the module from gathering way too much information that might result in crashing. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support FortiOS 7.0.2, 7.0.3, 7.0.4, 7.0.5. - -frr.frr -~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. - -ibm.qradar -~~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. -- `junos_facts` - change default gather_subset to `min` from `!config`. - -ovirt.ovirt -~~~~~~~~~~~ - -- manageiq - role removed (https://github.com/oVirt/ovirt-ansible-collection/pull/375). - -splunk.es -~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. - -vyos.vyos -~~~~~~~~~ - -- Add 'pool' as value to server key in ntp_global. -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. -- `vyos_facts` - change default gather_subset to `min` from `!config` (https://github.com/ansible-collections/vyos.vyos/issues/231). - -Removed Collections -------------------- - -- community.kubernetes (previously included version: 2.0.1) -- community.kubevirt (previously included version: 1.0.0) - -Removed Features ----------------- - -- The community.kubernetes collection has been removed from Ansible 6. It has been deprecated since Ansible 4.2, and version 2.0.0 included since Ansible 5 is only a set of deprecated redirects from community.kubernetes to kubernetes.core. If you still need the redirects, you can manually install community.kubernetes with ``ansible-galaxy collection install community.kubernetes`` (https://github.com/ansible-community/community-topics/issues/93). -- The community.kubevirt collection has been removed from Ansible 6. It has not been working with the community.kubernetes collection included since Ansible 5.0.0, and unfortunately nobody managed to adjust the collection to work with kubernetes.core >= 2.0.0. If you need to use this collection, you need to manually install community.kubernetes < 2.0.0 together with community.kubevirt with ``ansible-galaxy collection install community.kubevirt 'community.kubernetes:<2.0.0'`` (https://github.com/ansible-community/community-topics/issues/92). - -Ansible-core -~~~~~~~~~~~~ - -- Remove deprecated ``Templar.set_available_variables()`` method (https://github.com/ansible/ansible/issues/75828) -- cli - remove deprecated ability to set verbosity before the sub-command (https://github.com/ansible/ansible/issues/75823) -- copy - remove deprecated ``thirsty`` alias (https://github.com/ansible/ansible/issues/75824) -- psrp - Removed fallback on ``put_file`` with older ``pypsrp`` versions. Users must have at least ``pypsrp>=0.4.0``. -- url_argument_spec - remove deprecated ``thirsty`` alias for ``get_url`` and ``uri`` modules (https://github.com/ansible/ansible/issues/75825, https://github.com/ansible/ansible/issues/75826) - -community.general -~~~~~~~~~~~~~~~~~ - -- ali_instance_info - removed the options ``availability_zone``, ``instance_ids``, and ``instance_names``. Use filter item ``zone_id`` instead of ``availability_zone``, filter item ``instance_ids`` instead of ``instance_ids``, and filter item ``instance_name`` instead of ``instance_names`` (https://github.com/ansible-collections/community.general/pull/4516). -- apt_rpm - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516). -- compose - removed various deprecated aliases. Use the version with ``_`` instead of ``-`` instead (https://github.com/ansible-collections/community.general/pull/4516). -- dnsimple - remove support for dnsimple < 2.0.0 (https://github.com/ansible-collections/community.general/pull/4516). -- github_deploy_key - removed the deprecated alias ``2fa_token`` of ``otp`` (https://github.com/ansible-collections/community.general/pull/4516). -- homebrew, homebrew_cask - removed the deprecated alias ``update-brew`` of ``update_brew`` (https://github.com/ansible-collections/community.general/pull/4516). -- linode - removed the ``backupsenabled`` option. Use ``backupweeklyday`` or ``backupwindow`` to enable backups (https://github.com/ansible-collections/community.general/pull/4516). -- opkg - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516). -- pacman - if ``update_cache=true`` is used with ``name`` or ``upgrade``, the changed state will now also indicate if only the cache was updated. To keep the old behavior - only indicate ``changed`` when a package was installed/upgraded -, use ``changed_when`` as indicated in the module examples (https://github.com/ansible-collections/community.general/pull/4516). -- pacman - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516). -- proxmox, proxmox_kvm, proxmox_snap - no longer allow to specify a VM name that matches multiple VMs. If this happens, the modules now fail (https://github.com/ansible-collections/community.general/pull/4516). -- serverless - removed the ``functions`` option. It was not used by the module (https://github.com/ansible-collections/community.general/pull/4516). -- slackpkg - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516). -- urpmi - removed the deprecated alias ``no-recommends`` of ``no_recommends`` (https://github.com/ansible-collections/community.general/pull/4516). -- urpmi - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516). -- xbps - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516). -- xfconf - the ``get`` state has been removed. Use the ``xfconf_info`` module instead (https://github.com/ansible-collections/community.general/pull/4516). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- aws_iam auth - the deprecated alias ``aws_iam_login`` for the ``aws_iam`` value of the ``auth_method`` option has been removed (https://github.com/ansible-collections/community.hashi_vault/issues/194). -- community.hashi_vault collection - support for Ansible 2.9 and ansible-base 2.10 has been removed (https://github.com/ansible-collections/community.hashi_vault/issues/189). -- hashi_vault lookup - the deprecated ``[lookup_hashi_vault]`` INI config section has been removed in favor of the collection-wide ``[hashi_vault_collection]`` section (https://github.com/ansible-collections/community.hashi_vault/issues/179). -- the "legacy" integration test setup has been removed; this does not affect end users and is only relevant to contributors (https://github.com/ansible-collections/community.hashi_vault/pull/191). - -community.network -~~~~~~~~~~~~~~~~~ - -- aireos modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- aireos modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- aruba modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- aruba modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ce modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ce modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- enos modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- enos modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ironware modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ironware modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- sros modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- sros modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vcenter_extension_facts - The deprecated module ``vcenter_extension_facts`` has been removed, use ``vcenter_extension_info`` instead. -- vmware_about_facts - The deprecated module ``vmware_about_facts`` has been removed, use ``vmware_about_info`` instead. -- vmware_category_facts - The deprecated module ``vmware_category_facts`` has been removed, use ``vmware_category_info`` instead. -- vmware_cluster - Remove DRS configuration in favour of module ``vmware_cluster_drs``. -- vmware_cluster - Remove HA configuration in favour of module ``vmware_cluster_ha``. -- vmware_cluster - Remove VSAN configuration in favour of module ``vmware_cluster_vsan``. -- vmware_cluster_facts - The deprecated module ``vmware_cluster_facts`` has been removed, use ``vmware_cluster_info`` instead. -- vmware_datastore_facts - The deprecated module ``vmware_datastore_facts`` has been removed, use ``vmware_datastore_info`` instead. -- vmware_drs_group_facts - The deprecated module ``vmware_drs_group_facts`` has been removed, use ``vmware_drs_group_info`` instead. -- vmware_drs_rule_facts - The deprecated module ``vmware_drs_rule_facts`` has been removed, use ``vmware_drs_rule_info`` instead. -- vmware_dvs_portgroup - The deprecated parameter ``portgroup_type`` has been removed, use ``port_binding`` instead. -- vmware_dvs_portgroup_facts - The deprecated module ``vmware_dvs_portgroup_facts`` has been removed, use ``vmware_dvs_portgroup_info`` instead. -- vmware_guest_boot_facts - The deprecated module ``vmware_guest_boot_facts`` has been removed, use ``vmware_guest_boot_info`` instead. -- vmware_guest_customization_facts - The deprecated module ``vmware_guest_customization_facts`` has been removed, use ``vmware_guest_customization_info`` instead. -- vmware_guest_disk_facts - The deprecated module ``vmware_guest_disk_facts`` has been removed, use ``vmware_guest_disk_info`` instead. -- vmware_guest_facts - The deprecated module ``vmware_guest_facts`` has been removed, use ``vmware_guest_info`` instead. -- vmware_guest_snapshot_facts - The deprecated module ``vmware_guest_snapshot_facts`` has been removed, use ``vmware_guest_snapshot_info`` instead. -- vmware_host_capability_facts - The deprecated module ``vmware_host_capability_facts`` has been removed, use ``vmware_host_capability_info`` instead. -- vmware_host_config_facts - The deprecated module ``vmware_host_config_facts`` has been removed, use ``vmware_host_config_info`` instead. -- vmware_host_dns_facts - The deprecated module ``vmware_host_dns_facts`` has been removed, use ``vmware_host_dns_info`` instead. -- vmware_host_feature_facts - The deprecated module ``vmware_host_feature_facts`` has been removed, use ``vmware_host_feature_info`` instead. -- vmware_host_firewall_facts - The deprecated module ``vmware_host_firewall_facts`` has been removed, use ``vmware_host_firewall_info`` instead. -- vmware_host_ntp_facts - The deprecated module ``vmware_host_ntp_facts`` has been removed, use ``vmware_host_ntp_info`` instead. -- vmware_host_package_facts - The deprecated module ``vmware_host_package_facts`` has been removed, use ``vmware_host_package_info`` instead. -- vmware_host_service_facts - The deprecated module ``vmware_host_service_facts`` has been removed, use ``vmware_host_service_info`` instead. -- vmware_host_ssl_facts - The deprecated module ``vmware_host_ssl_facts`` has been removed, use ``vmware_host_ssl_info`` instead. -- vmware_host_vmhba_facts - The deprecated module ``vmware_host_vmhba_facts`` has been removed, use ``vmware_host_vmhba_info`` instead. -- vmware_host_vmnic_facts - The deprecated module ``vmware_host_vmnic_facts`` has been removed, use ``vmware_host_vmnic_info`` instead. -- vmware_local_role_facts - The deprecated module ``vmware_local_role_facts`` has been removed, use ``vmware_local_role_info`` instead. -- vmware_local_user_facts - The deprecated module ``vmware_local_user_facts`` has been removed, use ``vmware_local_user_info`` instead. -- vmware_portgroup_facts - The deprecated module ``vmware_portgroup_facts`` has been removed, use ``vmware_portgroup_info`` instead. -- vmware_resource_pool_facts - The deprecated module ``vmware_resource_pool_facts`` has been removed, use ``vmware_resource_pool_info`` instead. -- vmware_tag_facts - The deprecated module ``vmware_tag_facts`` has been removed, use ``vmware_tag_info`` instead. -- vmware_target_canonical_facts - The deprecated module ``vmware_target_canonical_facts`` has been removed, use ``vmware_target_canonical_info`` instead. -- vmware_vm_facts - The deprecated module ``vmware_vm_facts`` has been removed, use ``vmware_vm_info`` instead. -- vmware_vmkernel_facts - The deprecated module ``vmware_vmkernel_facts`` has been removed, use ``vmware_vmkernel_info`` instead. -- vmware_vmkernel_ip_config - The deprecated module ``vmware_vmkernel_ip_config`` has been removed, use ``vmware_vmkernel`` instead. -- vmware_vswitch_facts - The deprecated module ``vmware_vswitch_facts`` has been removed, use ``vmware_vswitch_info`` instead. - -Deprecated Features -------------------- - -- The collection ``community.sap`` has been renamed to ``community.sap_libs``. For now both collections are included in Ansible. The content in ``community.sap`` will be replaced with deprecated redirects to the new collection in Ansible 7.0.0, and these redirects will eventually be removed from Ansible. Please update your FQCNs for ``community.sap``. - -Ansible-core -~~~~~~~~~~~~ - -- ansible-core - Remove support for Python 2.6. -- ansible-test - Remove support for Python 2.6. -- ssh connection plugin option scp_if_ssh in favor of ssh_transfer_method. - -amazon.aws -~~~~~~~~~~ - -- ec2_instance - The default value for ```instance_type``` has been deprecated, in the future release you must set an instance_type or a launch_template (https://github.com/ansible-collections/amazon.aws/pull/587). -- module_utils - support for the original AWS SDK `boto` has been deprecated in favour of the `boto3`/`botocore` SDK. All `boto` based modules have either been deprecated or migrated to `botocore`, and the remaining support code in module_utils will be removed in release 4.0.0 of the amazon.aws collection. Any modules outside of the amazon.aws and community.aws collections based on the `boto` library will need to be migrated to the `boto3`/`botocore` libraries (https://github.com/ansible-collections/amazon.aws/pull/575). - -cisco.ios -~~~~~~~~~ - -- Deprecates lldp module. -- ios_acls - Deprecated fragment attribute added boolean alternate as enable_fragment. - -cisco.nxos -~~~~~~~~~~ - -- Deprecated nxos_snmp_community module. -- Deprecated nxos_snmp_contact module. -- Deprecated nxos_snmp_host module. -- Deprecated nxos_snmp_location module. -- Deprecated nxos_snmp_traps module. -- Deprecated nxos_snmp_user module. - -community.docker -~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.docker 3.0.0). Some modules might still work with these versions afterwards, but we will no longer keep compatibility code that was needed to support them (https://github.com/ansible-collections/community.docker/pull/361). -- The dependency on docker-compose for Execution Environments is deprecated and will be removed in community.docker 3.0.0. The `Python docker-compose library `__ is unmaintained and can cause dependency issues. You can manually still install it in an Execution Environment when needed (https://github.com/ansible-collections/community.docker/pull/373). -- Various modules - the default of ``tls_hostname`` that was supposed to be removed in community.docker 2.0.0 will now be removed in version 3.0.0 (https://github.com/ansible-collections/community.docker/pull/362). -- docker_stack - the return values ``out`` and ``err`` that were supposed to be removed in community.docker 2.0.0 will now be removed in version 3.0.0 (https://github.com/ansible-collections/community.docker/pull/362). - -community.general -~~~~~~~~~~~~~~~~~ - -- ansible_galaxy_install - deprecated support for ``ansible`` 2.9 and ``ansible-base`` 2.10 (https://github.com/ansible-collections/community.general/pull/4601). -- dig lookup plugin - the ``DLV`` record type has been decommissioned in 2017 and support for it will be removed from community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/4618). -- gem - the default of the ``norc`` option has been deprecated and will change to ``true`` in community.general 6.0.0. Explicitly specify a value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/4517). -- mail callback plugin - not specifying ``sender`` is deprecated and will be disallowed in community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/4140). -- module_helper module utils - deprecated the attribute ``ModuleHelper.VarDict`` (https://github.com/ansible-collections/community.general/pull/3801). -- nmcli - deprecate default hairpin mode for a bridge. This so we can change it to ``false`` in community.general 7.0.0, as this is also the default in ``nmcli`` (https://github.com/ansible-collections/community.general/pull/4334). -- pacman - from community.general 5.0.0 on, the ``changed`` status of ``update_cache`` will no longer be ignored if ``name`` or ``upgrade`` is specified. To keep the old behavior, add something like ``register: result`` and ``changed_when: result.packages | length > 0`` to your task (https://github.com/ansible-collections/community.general/pull/4329). -- proxmox inventory plugin - the current default ``true`` of the ``want_proxmox_nodes_ansible_host`` option has been deprecated. The default will change to ``false`` in community.general 6.0.0. To keep the current behavior, explicitly set ``want_proxmox_nodes_ansible_host`` to ``true`` in your inventory configuration. We suggest to already switch to the new behavior by explicitly setting it to ``false``, and by using ``compose:`` to set ``ansible_host`` to the correct value. See the examples in the plugin documentation for details (https://github.com/ansible-collections/community.general/pull/4466). -- vmadm - deprecated module parameter ``debug`` that was not used anywhere (https://github.com/ansible-collections/community.general/pull/4580). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.hashi_vault 3.0.0) next spring (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.hashi_vault/issues/189). -- aws_iam_login auth method - the ``aws_iam_login`` method has been renamed to ``aws_iam``. The old name will be removed in collection version ``3.0.0``. Until then both names will work, and a warning will be displayed when using the old name (https://github.com/ansible-collections/community.hashi_vault/pull/193). -- token_validate options - the shared auth option ``token_validate`` will change its default from ``True`` to ``False`` in community.hashi_vault version 4.0.0. The ``vault_login`` lookup and module will keep the default value of ``True`` (https://github.com/ansible-collections/community.hashi_vault/issues/248). -- token_validate options - the shared auth option ``token_validate`` will change its default from ``true`` to ``false`` in community.hashi_vault version 4.0.0. The ``vault_login`` lookup and module will keep the default value of ``true`` (https://github.com/ansible-collections/community.hashi_vault/issues/248). - -community.network -~~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.network 4.0.0) this spring. While most content will probably still work with ansible-base 2.10, we will remove symbolic links for modules and action plugins, which will make it impossible to use them with Ansible 2.9 anymore. Please use community.network 3.x.y with Ansible 2.9 and ansible-base 2.10, as these releases will continue to support Ansible 2.9 and ansible-base 2.10 even after they are End of Life (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.network/pull/382). - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resource module. - -purestorage.flasharray -~~~~~~~~~~~~~~~~~~~~~~ - -- purefa_sso - Deprecated in favor of M(purefa_admin). Will be removed in Collection 2.0 diff --git a/docs/docsite/rst/porting_guides/porting_guide_7.rst b/docs/docsite/rst/porting_guides/porting_guide_7.rst deleted file mode 100644 index a5bd91f53b1..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_7.rst +++ /dev/null @@ -1,1211 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_core_2.14.rst) - -.. _porting_7_guide: - -======================= -Ansible 7 Porting Guide -======================= - -.. contents:: - :local: - :depth: 2 - - -Ansible 7 is based on Ansible-core 2.14. - - -We suggest you read this page along with the `Ansible 7 Changelog `_ to understand what updates you may need to make. - - -Playbook -======== - -* Variables are now evaluated lazily; only when they are actually used. For example, in ansible-core 2.14 an expression ``{{ defined_variable or undefined_variable }}`` does not fail on ``undefined_variable`` if the first part of ``or`` is evaluated to ``True`` as it is not needed to evaluate the second part. One particular case of a change in behavior to note is the task below which uses the ``undefined`` test. Prior to version 2.14 this would result in a fatal error trying to access the undefined value in the dictionary. In 2.14 the assertion passes as the dictionary is evaluated as undefined through one of its undefined values: - - .. code-block:: yaml - - - assert: - that: - - some_defined_dict_with_undefined_values is undefined - vars: - dict_value: 1 - some_defined_dict_with_undefined_values: - key1: value1 - key2: '{{ dict_value }}' - key3: '{{ undefined_dict_value }}' - - -Command Line -============ - -* Python 3.9 on the controller node is a hard requirement for this release. -* At startup the filesystem encoding and locale are checked to verify they are UTF-8. If not, the process exits with an error reporting the errant encoding. If you were previously using the ``C`` or ``POSIX`` locale, you may be able to use ``C.UTF-8``. If you were previously using a locale such as ``en_US.ISO-8859-1``, you may be able to use ``en_US.UTF-8``. For simplicity it may be easiest to export the appropriate locale using the ``LC_ALL`` environment variable. An alternative to modifying your system locale is to run Python in UTF-8 mode; See the `Python documentation `_ for more information. - - -Deprecated -========== - -No notable changes - - -Modules -======= - -No notable changes - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Plugins -======= - -No notable changes - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes - -Porting Guide for v7.6.0 -======================== - -Known Issues ------------- - -community.docker -~~~~~~~~~~~~~~~~ - -- The modules and plugins using the vendored code from Docker SDK for Python currently do not work with requests 2.29.0 and/or urllib3 2.0.0. The same is currently true for the latest version of Docker SDK for Python itself (https://github.com/ansible-collections/community.docker/issues/611, https://github.com/ansible-collections/community.docker/pull/612). -- docker_api connection plugin - does **not work with TCP TLS sockets**! This is caused by the inability to send an ``close_notify`` TLS alert without closing the connection with Python's ``SSLSocket`` (https://github.com/ansible-collections/community.docker/issues/605, https://github.com/ansible-collections/community.docker/pull/621). -- docker_container_exec - does **not work with TCP TLS sockets** when the ``stdin`` option is used! This is caused by the inability to send an ``close_notify`` TLS alert without closing the connection with Python's ``SSLSocket`` (https://github.com/ansible-collections/community.docker/issues/605, https://github.com/ansible-collections/community.docker/pull/621). - -Major Changes -------------- - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_privs - the ``password`` argument is deprecated and will be removed in community.postgresql 4.0.0, use the ``login_password`` argument instead (https://github.com/ansible-collections/community.postgresql/issues/406). - -infoblox.nios_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Added Grid Master Candidate feature `#152 `_ -- Added Member Assignment to network and ranges `#152 `_ -- Added NIOS Range module with Create, Update and Delete features `#152 `_ -- Fixes issue unable to update/delete EAs using Ansible plugin `#180 `_ -- Fixes static and dynamic allocation of IPV4 address of A Record `#182 `_ -- Fixes to Update host name of NIOS member `#176 `_ -- Updates default WAPI version to 2.9 `#176 `_ - -Deprecated Features -------------------- - -community.crypto -~~~~~~~~~~~~~~~~ - -- x509_crl - the ``mode`` option is deprecated; use ``crl_mode`` instead. The ``mode`` option will change its meaning in community.crypto 3.0.0, and will refer to the CRL file's mode instead (https://github.com/ansible-collections/community.crypto/issues/596). - -Porting Guide for v7.5.0 -======================== - -Added Collections ------------------ - -- microsoft.ad (version 1.0.0) - -Deprecated Features -------------------- - -cisco.ios -~~~~~~~~~ - -- ios_bgp_address_family - deprecate redistribute.ospf.match.external with redistribute.ospf.match.externals which enables attributes for OSPF type E1 and E2 routes -- ios_bgp_address_family - deprecate redistribute.ospf.match.nssa_external with redistribute.ospf.match.nssa_externals which enables attributes for OSPF type N1 and N2 routes -- ios_bgp_address_family - deprecate redistribute.ospf.match.type_1 with redistribute.ospf.match.nssa_externals.type_1 -- ios_bgp_address_family - deprecate redistribute.ospf.match.type_2 with redistribute.ospf.match.nssa_externals.type_2 - -Porting Guide for v7.4.0 -======================== - -Breaking Changes ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - Integration tests which depend on specific file permissions when running in an ansible-test managed host environment may require changes. Tests that require permissions other than ``755`` or ``644`` may need to be updated to set the necessary permissions as part of the test run. - -Major Changes -------------- - -community.hrobot -~~~~~~~~~~~~~~~~ - -- firewall - Hetzner added output rules support to the firewall. This change unfortunately means that using old versions of the firewall module will always set the output rule list to empty, thus disallowing the server to send out packets (https://github.com/ansible-collections/community.hrobot/issues/75, https://github.com/ansible-collections/community.hrobot/pull/76). - -community.vmware -~~~~~~~~~~~~~~~~ - -- Use true/false (lowercase) for boolean values in documentation and examples (https://github.com/ansible-collections/community.vmware/issues/1660). - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Add annotations of member operation for every module. -- Update ``fortios.py`` for higher performance; -- supports temporary session key and pre/post login banner; -- update the examples on how to use member operation in Q&A. - -purestorage.fusion -~~~~~~~~~~~~~~~~~~ - -- Patching of resource properties was brought to parity with underlying Python SDK -- fusion_volume - fixed and reorganized, arguments changed - -Deprecated Features -------------------- - -amazon.aws -~~~~~~~~~~ - -- support for passing both profile and security tokens through a mix of environment variables and parameters has been deprecated and support will be removed in release 6.0.0. After release 6.0.0 it will only be possible to pass either a profile or security tokens, regardless of mechanism used to pass them. To explicitly block a parameter coming from an environment variable pass an empty string as the parameter value. Support for passing profile and security tokens together was originally deprecated in release 1.2.0, however only partially implemented in release 5.0.0 (https://github.com/ansible-collections/amazon.aws/pull/1355). - -community.aws -~~~~~~~~~~~~~ - -- ecs_service - In a release after 2024-06-01, tha default value of ``purge_placement_constraints`` will be change from ``false`` to ``true`` (https://github.com/ansible-collections/community.aws/pull/1716). -- ecs_service - In a release after 2024-06-01, tha default value of ``purge_placement_strategy`` will be change from ``false`` to ``true`` (https://github.com/ansible-collections/community.aws/pull/1716). -- iam_role - All top level return values other than ``iam_role`` and ``changed`` have been deprecated and will be removed in a release after 2023-12-01 (https://github.com/ansible-collections/community.aws/issues/551). -- iam_role - In a release after 2023-12-01 the contents of ``assume_role_policy_document`` will no longer be converted from CamelCase to snake_case. The ``assume_role_policy_document_raw`` return value already returns the policy document in this future format (https://github.com/ansible-collections/community.aws/issues/551). -- iam_role_info - In a release after 2023-12-01 the contents of ``assume_role_policy_document`` will no longer be converted from CamelCase to snake_case. The ``assume_role_policy_document_raw`` return value already returns the policy document in this future format (https://github.com/ansible-collections/community.aws/issues/551). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault lookup - in ``v5.0.0`` duplicate term string options will raise an exception instead of showing a warning (https://github.com/ansible-collections/community.hashi_vault/issues/356). - -purestorage.fusion -~~~~~~~~~~~~~~~~~~ - -- fusion_hw - hardware module is being removed as changing hardware type has never been supported by Pure Storage Fusion -- fusion_info - nigs subset is deprecated in favor of network_interface_groups and will be removed in the version 1.7.0 -- fusion_info - placements subset is deprecated in favor of placement_groups and will be removed in the version 1.7.0 -- fusion_pg - placement_engine option is deprecated because Fusion API does not longer support this parameter It will be removed in the version 2.0.0 -- fusion_se - parameters 'addresses', 'gateway' and 'network_interface_groups' are deprecated in favor of 'iscsi' and will be removed in version 2.0.0 -- fusion_tn - tenant networks are being replaced by storage endpoints ```fusion_se``` and Network Interface Groups ```fusion_nig``` - -Porting Guide for v7.3.0 -======================== - -Breaking Changes ----------------- - -hetzner.hcloud -~~~~~~~~~~~~~~ - -- inventory plugin - Python v3.5+ is now required. - -Major Changes -------------- - -kubernetes.core -~~~~~~~~~~~~~~~ - -- refactor K8sAnsibleMixin into module_utils/k8s/ (https://github.com/ansible-collections/kubernetes.core/pull/481). - -Deprecated Features -------------------- - -- Since the google.cloud collection seems to be maintained again, we `cancelled the removal process `__. So contrary to an earlier announcement, this collection is NOT deprecated and will NOT be removed from Ansible 8 (https://github.com/ansible-community/community-topics/issues/105). - -community.general -~~~~~~~~~~~~~~~~~ - -- gitlab_runner - the option ``access_level`` will lose its default value in community.general 8.0.0. From that version on, you have set this option to ``ref_protected`` explicitly, if you want to have a protected runner (https://github.com/ansible-collections/community.general/issues/5925). - -Porting Guide for v7.2.0 -======================== - -Added Collections ------------------ - -- dellemc.powerflex (version 1.5.0) -- dellemc.unity (version 1.5.0) - -Known Issues ------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - Additional configuration may be required for certain container host and container combinations. Further details are available in the testing documentation. -- ansible-test - Custom containers with ``VOLUME`` instructions may be unable to start, when previously the containers started correctly. Remove the ``VOLUME`` instructions to resolve the issue. Containers with this condition will cause ``ansible-test`` to emit a warning. -- ansible-test - Systems with Podman networking issues may be unable to run containers, when previously the issue went unreported. Correct the networking issues to continue using ``ansible-test`` with Podman. -- ansible-test - Using Docker on systems with SELinux may require setting SELinux to permissive mode. Podman should work with SELinux in enforcing mode. - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_network - Updated documentation for `local_status_page_enabled` and `remote_status_page_enabled` as these no longer work. - -Breaking Changes ----------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- ModuleHelper module utils - when the module sets output variables named ``msg``, ``exception``, ``output``, ``vars``, or ``changed``, the actual output will prefix those names with ``_`` (underscore symbol) only when they clash with output variables generated by ModuleHelper itself, which only occurs when handling exceptions. Please note that this breaking change does not require a new major release since before this release, it was not possible to add such variables to the output `due to a bug `__ (https://github.com/ansible-collections/community.general/pull/5765). - -Major Changes -------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - Docker Desktop on WSL2 is now supported (additional configuration required). -- ansible-test - Docker and Podman are now supported on hosts with cgroup v2 unified. Previously only cgroup v1 and cgroup v2 hybrid were supported. -- ansible-test - Podman now works on container hosts without systemd. Previously only some containers worked, while others required rootfull or rootless Podman, but would not work with both. Some containers did not work at all. -- ansible-test - Podman on WSL2 is now supported. -- ansible-test - When additional cgroup setup is required on the container host, this will be automatically detected. Instructions on how to configure the host will be provided in the error message shown. - -ansible.windows -~~~~~~~~~~~~~~~ - -- Set the minimum Ansible version supported by this collection to Ansible 2.12 - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Allow users to select the TLS versions used for bootstrapping Chocolatey installation. - -Deprecated Features -------------------- - -- The cisco.nso collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/155). -- The community.fortios collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/162). -- The community.google collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/160). -- The community.skydive collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/171). - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Deprecate side-by-side installs. - -cisco.ios -~~~~~~~~~ - -- ios_bgp_address_family - deprecate neighbors.address/tag/ipv6_adddress with neighbor_address which enables common attributes for facts rendering -- ios_bgp_address_family - deprecate neighbors.password with password_options which allows encryption and password -- ios_bgp_address_family - deprecate slow_peer with slow_peer_options which supports a dict attribute - -community.dns -~~~~~~~~~~~~~ - -- The default of the newly added option ``txt_character_encoding`` will change from ``octal`` to ``decimal`` in community.dns 3.0.0. The new default will be compatible with `RFC 1035 `__ (https://github.com/ansible-collections/community.dns/pull/134). - -community.general -~~~~~~~~~~~~~~~~~ - -- consul - deprecate using parameters unused for ``state=absent`` (https://github.com/ansible-collections/community.general/pull/5772). -- gitlab_runner - the default of the new option ``access_level_on_creation`` will change from ``false`` to ``true`` in community.general 7.0.0. This will cause ``access_level`` to be used during runner registration as well, and not only during updates (https://github.com/ansible-collections/community.general/pull/5908). -- manageiq_policies - deprecate ``state=list`` in favour of using ``community.general.manageiq_policies_info`` (https://github.com/ansible-collections/community.general/pull/5721). -- rax - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_cbs - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_cbs_attachments - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_cdb - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_cdb_database - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_cdb_user - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_clb - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_clb_nodes - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_clb_ssl - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_dns - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_dns_record - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_facts - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_files - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_files_objects - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_identity - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_keypair - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_meta - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_mon_alarm - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_mon_check - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_mon_entity - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_mon_notification - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_mon_notification_plan - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_network - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_queue - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_scaling_group - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_scaling_policy - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- ansible-core - support for ``ansible-core`` versions ``2.11`` and ``2.12`` will be dropped in collection version ``5.0.0``, making ``2.13`` the minimum supported version of ``ansible-core`` (https://github.com/ansible-collections/community.hashi_vault/issues/340). -- hvac - the minimum version of ``hvac`` to be supported in collection version ``5.0.0`` will be at least ``1.0.2``; this minimum may be raised before ``5.0.0`` is released, so please subscribe to the linked issue and look out for new notices in the changelog (https://github.com/ansible-collections/community.hashi_vault/issues/324). - -Porting Guide for v7.1.0 -======================== - -Added Collections ------------------ - -- grafana.grafana (version 1.1.0) - -Known Issues ------------- - -community.routeros -~~~~~~~~~~~~~~~~~~ - -- api_modify - when limits for entries in ``queue tree`` are defined as human readable - for example ``25M`` -, the configuration will be correctly set in ROS, but the module will indicate the item is changed on every run even when there was no change done. This is caused by the ROS API which returns the number in bytes - for example ``25000000`` (which is inconsistent with the CLI behavior). In order to mitigate that, the limits have to be defined in bytes (those will still appear as human readable in the ROS CLI) (https://github.com/ansible-collections/community.routeros/pull/131). -- api_modify, api_info - ``routing ospf area``, ``routing ospf area range``, ``routing ospf instance``, ``routing ospf interface-template`` paths are not fully implemeted for ROS6 due to the significat changes between ROS6 and ROS7 (https://github.com/ansible-collections/community.routeros/pull/131). - -Major Changes -------------- - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_mr_l7_firewall - New module -- meraki_webhook_payload_template - New module - -community.zabbix -~~~~~~~~~~~~~~~~ - -- all modules are opting away from zabbix-api and using httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate -- zabbix_agent and zabbix_proxy roles are opting away from zabbix-api and use httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate - -containers.podman -~~~~~~~~~~~~~~~~~ - -- New become plugin - podman_unshare -- Podman generate systemd module - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support FortiOS v7.0.6, v7.0.7, v7.0.8, v7.2.1, v7.2.2. - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- The ``sap`` modules ``sapcar_extract``, ``sap_task_list_execute``, and ``hana_query``, will be removed from this collection in community.general 7.0.0 and replaced with redirects to ``community.sap_libs``. If you want to continue using these modules, make sure to also install ``community.sap_libs`` (it is part of the Ansible package) (https://github.com/ansible-collections/community.general/pull/5614). - -Porting Guide for v7.0.0 -======================== - -Added Collections ------------------ - -- ibm.spectrum_virtualize (version 1.10.0) -- inspur.ispim (version 1.2.0) -- lowlydba.sqlserver (version 1.0.4) -- purestorage.fusion (version 1.1.1) -- vultr.cloud (version 1.3.1) - -Known Issues ------------- - -community.routeros -~~~~~~~~~~~~~~~~~~ - -- The ``community.routeros.command`` module claims to support check mode. Since it cannot judge whether the commands executed modify state or not, this behavior is incorrect. Since this potentially breaks existing playbooks, we will not change this behavior until community.routeros 3.0.0. - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_application_alerts_smtp - Issue(212310) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_device_local_access_configuration - Issue(215035) - The module reports ``Successfully updated the local access setting`` if an unsupported value is provided for the parameter timeout_limit. However, this value is not actually applied on OpenManage Enterprise Modular. -- ome_device_local_access_configuration - Issue(217865) - The module does not display a proper error message if an unsupported value is provided for the user_defined and lcd_language parameters. -- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout. -- ome_device_power_settings - Issue(212679) - The module displays the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_device_quick_deploy - Issue(216352) - The module does not display a proper error message if an unsupported value is provided for the ipv6_prefix_length and vlan_id parameters. -- ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -netapp.ontap -~~~~~~~~~~~~ - -- na_ontap_snapshot - added documentation to use UTC format for ``expiry_time``. - -Breaking Changes ----------------- - -- Ansible 7 requires Python 3.9 on the controller, same as ansible-core 2.14. - -Ansible-core -~~~~~~~~~~~~ - -- Allow for lazy evaluation of Jinja2 expressions (https://github.com/ansible/ansible/issues/56017) -- The default ansible-galaxy role skeletons no longer contain .travis.yml files. You can configure ansible-galaxy to use a custom role skeleton that contains a .travis.yml file to continue using Galaxy's integration with Travis CI. -- ansible - At startup the filesystem encoding and locale are checked to verify they are UTF-8. If not, the process exits with an error reporting the errant encoding. -- ansible - Increase minimum Python requirement to Python 3.9 for CLI utilities and controller code -- ansible-test - At startup the filesystem encoding is checked to verify it is UTF-8. If not, the process exits with an error reporting the errant encoding. -- ansible-test - At startup the locale is configured as ``en_US.UTF-8``, with a fallback to ``C.UTF-8``. If neither encoding is available the process exits with an error. If the fallback is used, a warning is displayed. In previous versions the ``en_US.UTF-8`` locale was always requested. However, no startup checking was performed to verify the locale was successfully configured. -- ansible-test validate-modules - Removed the ``missing-python-doc`` error code in validate modules, ``missing-documentation`` is used instead for missing PowerShell module documentation. -- strategy plugins - Make ``ignore_unreachable`` to increase ``ignored`` and ``ok`` and counter, not ``skipped`` and ``unreachable``. (https://github.com/ansible/ansible/issues/77690) - -amazon.aws -~~~~~~~~~~ - -- Tags beginning with ``aws:`` will not be removed when purging tags, these tags are reserved by Amazon and may not be updated or deleted (https://github.com/ansible-collections/amazon.aws/issues/817). -- amazon.aws collection - Support for ansible-core < 2.11 has been dropped (https://github.com/ansible-collections/amazon.aws/pull/1087). -- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.21.0`` and ``boto3<1.18.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/934). -- amazon.aws collection - the ``profile`` parameter is now mutually exclusive with the ``aws_access_key``, ``aws_secret_key`` and ``security_token`` parameters (https://github.com/ansible-collections/amazon.aws/pull/834). -- aws_az_info - the module alias ``aws_az_facts`` was deprecated in Ansible 2.9 and has now been removed (https://github.com/ansible-collections/amazon.aws/pull/832). -- aws_s3 - the default value for ``ensure overwrite`` has been changed to ``different`` instead of ``always`` so that the module is idempotent by default (https://github.com/ansible-collections/amazon.aws/issues/811). -- aws_ssm - on_denied and on_missing now both default to error, for consistency with both aws_secret and the base Lookup class (https://github.com/ansible-collections/amazon.aws/issues/617). -- doc_fragments - remove minimum collection requirements from doc_fragments/aws.py and allow pulling those from doc_fragments/aws_boto3.py instead (https://github.com/ansible-collections/amazon.aws/pull/985). -- ec2 - The ``ec2`` module has been removed in release 4.0.0 and replaced by the ``ec2_instance`` module (https://github.com/ansible-collections/amazon.aws/pull/630). -- ec2_ami - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- ec2_ami - the parameter aliases ``DeviceName``, ``VirtualName`` and ``NoDevice`` were previously deprecated and have been removed, please use ``device_name``, ``virtual_name`` and ``no_device`` instead (https://github.com/ansible-collections/amazon.aws/pull/913). -- ec2_eni_info - the mutual exclusivity of the ``eni_id`` and ``filters`` parameters is now enforced, previously ``filters`` would be ignored if ``eni_id`` was set (https://github.com/ansible-collections/amazon.aws/pull/954). -- ec2_instance - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- ec2_key - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- ec2_vol - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- ec2_vpc_dhcp_option_info - the parameter aliases ``DhcpOptionIds`` and ``DryRun`` were previously deprecated and have been removed, please use ``dhcp_options_ids`` and ``no_device`` instead (https://github.com/ansible-collections/amazon.aws/pull/913). -- ec2_vpc_endpoint - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- ec2_vpc_igw_info - The default value for ``convert_tags`` has been changed to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/835). -- ec2_vpc_net - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- ec2_vpc_route_table - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- elb_classic_lb - the ``ec2_elb`` fact has been removed (https://github.com/ansible-collections/amazon.aws/pull/827). -- module_utils - Support for the original AWS SDK aka ``boto`` has been removed, including all relevant helper functions. All modules should now use the ``boto3``/``botocore`` AWS SDK (https://github.com/ansible-collections/amazon.aws/pull/630) -- s3_bucket - the previously deprecated alias ``S3_URL`` for the ``s3_url`` parameter has been removed. Playbooks shuold be updated to use ``s3_url`` (https://github.com/ansible-collections/amazon.aws/pull/908). -- s3_object - the previously deprecated alias ``S3_URL`` for the ``s3_url`` parameter has been removed. Playbooks should be updated to use ``s3_url`` (https://github.com/ansible-collections/amazon.aws/pull/908). - -check_point.mgmt -~~~~~~~~~~~~~~~~ - -- cp_mgmt_access_role - the 'machines' parameter now accepts a single str and a new parameter 'machines_list' of type dict has been added. the 'users' parameter now accepts a single str and a new parameter 'users_list' of type dict has been added. -- cp_mgmt_access_rule - the 'vpn' parameter now accepts a single str and a new parameter 'vpn_list' of type dict has been added. the 'position_by_rule' parameter has been changed to 'relative_position' with support of positioning above/below a section (and not just a rule). the 'relative_position' parameter has also 'top' and 'bottom' suboptions which allows positioning a rule at the top and bottom of a section respectively. a new parameter 'search_entire_rulebase' has been added to allow the relative positioning to be unlimited (was previously limited to 50 rules) -- cp_mgmt_administrator - the 'permissions_profile' parameter now accepts a single str and a new parameter 'permissions_profile_list' of type dict has been added. -- cp_mgmt_publish - the 'uid' parameter has been removed. - -community.aws -~~~~~~~~~~~~~ - -- Tags beginning with ``aws:`` will not be removed when purging tags, these tags are reserved by Amazon and may not be updated or deleted (https://github.com/ansible-collections/amazon.aws/issues/817). -- acm_certificate - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- autoscaling_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.autoscaling_group``. -- autoscaling_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.autoscaling_group_info``. -- aws_secret - tags are no longer removed when the ``tags`` parameter is not set. To remove all tags set ``tags={}`` (https://github.com/ansible-collections/community.aws/issues/1146). -- cloudfront_distribution - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- cloudtrail - The module has been migrated to the ``amazon.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudtrail``. -- cloudwatch_metric_alarm - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatch_metric_alarm``. -- cloudwatchevent_rule - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchevent_rule``. -- cloudwatchlogs_log_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group``. -- cloudwatchlogs_log_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group_info``. -- cloudwatchlogs_log_group_metric_filter - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group_metric_filter``. -- community.aws collection - Support for ansible-core < 2.11 has been dropped (https://github.com/ansible-collections/community.aws/pull/1541). -- community.aws collection - The ``community.aws`` collection has now dropped support for and any requirements upon the original ``boto`` AWS SDK, and now uses the ``boto3``/``botocore`` AWS SDK (https://github.com/ansible-collections/community.aws/pull/898). -- community.aws collection - The community.aws collection has dropped support for ``botocore<1.21.0`` and ``boto3<1.18.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/1362). -- community.aws collection - the ``profile`` parameter is now mutually exclusive with the ``aws_access_key``, ``aws_secret_key`` and ``security_token`` parameters (https://github.com/ansible-collections/amazon.aws/pull/834). -- ec2_eip - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_eip``. -- ec2_eip_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_eip_info``. -- ec2_vpc_route_table - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table``. -- ec2_vpc_route_table_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table_info``. -- ec2_vpc_vpn - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- elb_application_lb - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.elb_application_lb``. -- elb_application_lb_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.elb_application_lb_info``. -- elb_instance - the ``ec2_elbs`` fact has been removed, ``updated_elbs`` has been added the return values and includes the same information (https://github.com/ansible-collections/community.aws/pull/1173). -- elb_network_lb - the default value of ``state`` has changed from ``absent`` to ``present`` (https://github.com/ansible-collections/community.aws/pull/1167). -- execute_lambda - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.execute_lambda``. -- iam_policy - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_policy``. -- iam_policy_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_policy_info``. -- iam_server_certificate - Passing file names to the ``cert``, ``chain_cert`` and ``key`` parameters has been removed. We recommend using a lookup plugin to read the files instead, see the documentation for an example (https://github.com/ansible-collections/community.aws/pull/1265). -- iam_server_certificate - the default value for the ``dup_ok`` parameter has been changed to ``true``. To preserve the original behaviour explicitly set the ``dup_ok`` parameter to ``false`` (https://github.com/ansible-collections/community.aws/pull/1265). -- iam_user - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_user``. -- iam_user_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_user_info``. -- kms_key - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.kms_key``. -- kms_key - managing the KMS IAM Policy via ``policy_mode`` and ``policy_grant_types`` was previously deprecated and has been removed in favor of the ``policy`` option (https://github.com/ansible-collections/community.aws/pull/1344). -- kms_key - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- kms_key_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.kms_key_info``. -- lambda - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda``. -- lambda_alias - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_alias``. -- lambda_event - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_event``. -- lambda_execute - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_execute``. -- lambda_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_info``. -- lambda_policy - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_policy``. -- rds_cluster - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster``. -- rds_cluster_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster_info``. -- rds_cluster_snapshot - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster_snapshot``. -- rds_instance - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance``. -- rds_instance_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance_info``. -- rds_instance_snapshot - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance_snapshot``. -- rds_option_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_option_group``. -- rds_option_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_option_group_info``. -- rds_param_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_param_group``. -- rds_param_group - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- rds_snapshot_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_snapshot_info``. -- rds_subnet_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_subnet_group``. -- route53 - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53``. -- route53_health_check - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_health_check``. -- route53_health_check - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- route53_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_info``. -- route53_zone - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_zone``. -- route53_zone - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- script_inventory_ec2 - The ec2.py inventory script has been moved to a new repository. The script can now be downloaded from https://github.com/ansible-community/contrib-scripts/blob/main/inventory/ec2.py and has been removed from this collection. We recommend migrating from the script to the amazon.aws.ec2 inventory plugin. (https://github.com/ansible-collections/community.aws/pull/898) -- sqs_queue - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). - -community.docker -~~~~~~~~~~~~~~~~ - -- This collection does not work with ansible-core 2.11 on Python 3.12+. Please either upgrade to ansible-core 2.12+, or use Python 3.11 or earlier (https://github.com/ansible-collections/community.docker/pull/271). -- docker_container - ``exposed_ports`` is no longer ignored in ``comparisons``. Before, its value was assumed to be identical with the value of ``published_ports`` (https://github.com/ansible-collections/community.docker/pull/422). -- docker_container - ``log_options`` can no longer be specified when ``log_driver`` is not specified (https://github.com/ansible-collections/community.docker/pull/422). -- docker_container - ``publish_all_ports`` is no longer ignored in ``comparisons`` (https://github.com/ansible-collections/community.docker/pull/422). -- docker_container - ``restart_retries`` can no longer be specified when ``restart_policy`` is not specified (https://github.com/ansible-collections/community.docker/pull/422). -- docker_container - ``stop_timeout`` is no longer ignored for idempotency if told to be not ignored in ``comparisons``. So far it defaulted to ``ignore`` there, and setting it to ``strict`` had no effect (https://github.com/ansible-collections/community.docker/pull/422). -- modules and plugins communicating directly with the Docker daemon - when connecting by SSH and not using ``use_ssh_client=true``, reject unknown host keys instead of accepting them. This is only a breaking change relative to older community.docker 3.0.0 pre-releases or with respect to Docker SDK for Python < 6.0.0. Docker SDK for Python 6.0.0 will also include this change (https://github.com/ansible-collections/community.docker/pull/434). - -community.general -~~~~~~~~~~~~~~~~~ - -- newrelic_deployment - ``revision`` is required for v2 API (https://github.com/ansible-collections/community.general/pull/5341). -- scaleway_container_registry_info - no longer replace ``secret_environment_variables`` in the output by ``SENSITIVE_VALUE`` (https://github.com/ansible-collections/community.general/pull/5497). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- auth - the default value for ``token_validate`` has changed from ``true`` to ``false``, as previously announced (https://github.com/ansible-collections/community.hashi_vault/issues/248). -- vault_kv2_get lookup - as previously announced, the default value for ``engine_mount_point`` in the ``vault_kv2_get`` lookup has changed from ``kv`` to ``secret`` (https://github.com/ansible-collections/community.hashi_vault/issues/279). - -community.vmware -~~~~~~~~~~~~~~~~ - -- Removed support for ansible-core version < 2.13.0. -- vmware_dvs_portgroup - Add a new sub-option `inherited` to the `in_traffic_shaping` parameter. This means you can keep the setting as-is by not defining the parameter, but also that you have to define the setting as not `inherited` if you want to override it at the PG level (https://github.com/ansible-collections/community.vmware/pull/1483). -- vmware_dvs_portgroup - Add a new sub-option `inherited` to the `out_traffic_shaping` parameter. This means you can keep the setting as-is by not defining the parameter, but also that you have to define the setting as not `inherited` if you want to override it at the PG level (https://github.com/ansible-collections/community.vmware/pull/1483). -- vmware_dvs_portgroup - Change the type of `net_flow` to string to allow setting it implicitly to inherited or to keep the value as-is. This means you can keep the setting as-is by not defining the parameter, but also that while `true` or `no` still work, `True` or `Off` (uppercase) won't (https://github.com/ansible-collections/community.vmware/pull/1483). -- vmware_dvs_portgroup - Remove support for vSphere API less than 6.7. -- vmware_dvs_portgroup - Remove the default for `network_policy` and add a new sub-option `inherited`. This means you can keep the setting as-is by not defining the parameter, but also that you have to define the setting as not `inherited` if you want to override it at the PG level (https://github.com/ansible-collections/community.vmware/pull/1483). -- vmware_dvs_portgroup_info - Remove support for vSphere API less than 6.7. -- vmware_dvswitch - Remove support for vSphere API less than 6.7. -- vmware_dvswitch_uplink_pg - Remove support for vSphere API less than 6.7. -- vmware_guest_boot_manager - Remove default for ``secure_boot_enabled`` parameter (https://github.com/ansible-collections/community.vmware/issues/1461). -- vmware_vm_config_option - Dict item names in result are changed from strings joined with spaces to strings joined with underlines, e.g. `Guest fullname` is changed to `guest_fullname` (https://github.com/ansible-collections/community.vmware/issues/1268). -- vmware_vspan_session - Remove support for vSphere API less than 6.7. - -dellemc.enterprise_sonic -~~~~~~~~~~~~~~~~~~~~~~~~ - -- bgp_af - Add the route_advertise_list dictionary to the argspec to replace the deleted, obsolete advertise_prefix attribute used for SONiC 3.x images on the 1.x branch of this collection. This change corresponds to a SONiC 4.0 OC YANG REST compliance change for the BGP AF REST API. It enables specification of a route map in conjunction with each route advertisement prefix (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/63). -- bgp_af - remove the obsolete 'advertise_prefix' attribute from argspec and config code. This and subsequent co-req replacement with the new route advertise list argument structure require corresponding changes in playbooks previoulsly used for configuring route advertise prefixes for SONiC 3.x images. (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/60) -- bgp_neighbors - Replace the previously defined standalone "bfd" attribute with a bfd dictionary containing multiple attributes. This change corresponds to the revised SONiC 4.x implementation of OC YANG compatible REST APIs. Playbooks previously using the bfd attributes for SONiC 3.x images must be modified for useon SONiC 4.0 images to use the new definition for the bfd attribute argspec structure (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/72). -- bgp_neighbors - Replace, for BGP peer groups, the previously defined standalone "bfd" attribute with a bfd dictionary containing multiple attributes. This change corresponds to the revised SONiC 4.x implementation of OC YANG compatible REST APIs. Playbooks previously using the bfd attributes for SONiC 3.x images must be modified for useon SONiC 4.0 images to use the new definition for the bfd attribute argspec structure (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/81). - -Major Changes -------------- - -Ansible-core -~~~~~~~~~~~~ - -- Move handler processing into new ``PlayIterator`` phase to use the configured strategy (https://github.com/ansible/ansible/issues/65067) -- ansible - At startup the filesystem encoding and locale are checked to verify they are UTF-8. If not, the process exits with an error reporting the errant encoding. -- ansible - Increase minimum Python requirement to Python 3.9 for CLI utilities and controller code -- ansible-test - At startup the filesystem encoding is checked to verify it is UTF-8. If not, the process exits with an error reporting the errant encoding. -- ansible-test - At startup the locale is configured as ``en_US.UTF-8``, with a fallback to ``C.UTF-8``. If neither encoding is available the process exits with an error. If the fallback is used, a warning is displayed. In previous versions the ``en_US.UTF-8`` locale was always requested. However, no startup checking was performed to verify the locale was successfully configured. - -amazon.aws -~~~~~~~~~~ - -- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.20.0`` and ``boto3<1.17.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/574). -- autoscaling_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.autoscaling_group``. -- autoscaling_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.autoscaling_group_info``. -- cloudtrail - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudtrail``. -- cloudwatch_metric_alarm - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatch_metric_alarm``. -- cloudwatchevent_rule - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchevent_rule``. -- cloudwatchlogs_log_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group``. -- cloudwatchlogs_log_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group_info``. -- cloudwatchlogs_log_group_metric_filter - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group_metric_filter``. -- ec2_eip - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_eip``. -- ec2_eip_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_eip_info``. -- elb_application_lb - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.elb_application_lb``. -- elb_application_lb_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.elb_application_lb_info``. -- execute_lambda - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.execute_lambda``. -- iam_policy - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_policy``. -- iam_policy_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_policy_info``. -- iam_user - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_user``. -- iam_user_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_user_info``. -- kms_key - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.kms_key``. -- kms_key_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.kms_key_info``. -- lambda - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda``. -- lambda_alias - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_alias``. -- lambda_event - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_event``. -- lambda_execute - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_execute``. -- lambda_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_info``. -- lambda_policy - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_policy``. -- rds_cluster - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster``. -- rds_cluster_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster_info``. -- rds_cluster_snapshot - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster_snapshot``. -- rds_instance - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance``. -- rds_instance_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance_info``. -- rds_instance_snapshot - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance_snapshot``. -- rds_option_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_option_group``. -- rds_option_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_option_group_info``. -- rds_param_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_param_group``. -- rds_snapshot_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_snapshot_info``. -- rds_subnet_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_subnet_group``. -- route53 - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53``. -- route53_health_check - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_health_check``. -- route53_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_info``. -- route53_zone - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_zone``. - -arista.eos -~~~~~~~~~~ - -- Remove following EOS dprecated modules -- Use of connection: local and the provider option are no longer valid on any modules in this collection. -- eos_interface -- eos_l2_interface -- eos_l3_interface -- eos_linkagg -- eos_static_route -- eos_vlan - -check_point.mgmt -~~~~~~~~~~~~~~~~ - -- plugins/httpapi/checkpoint - Support for Smart-1 Cloud with new variable 'ansible_cloud_mgmt_id' - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Added bootstrap_script option to allow users to target a script URL for installing Chocolatey on clients. -- win_chocolatey_facts - Added outdated packages list to data returned. - -cisco.asa -~~~~~~~~~ - -- Please use either of the following connection types - network_cli, httpapi or netconf. -- This includes the following modules: -- This release drops support for `connection: local` and provider dictionary. -- This release removes all deprecated plugins that have reached their end-of-life. -- Use of connection: local and the provider option are no longer valid on any modules in this collection. -- asa_acl -- asa_og - -cisco.ios -~~~~~~~~~ - -- Only valid connection types for this collection is network_cli. -- This release drops support for `connection: local` and provider dictionary. - -cisco.iosxr -~~~~~~~~~~~ - -- Only valid connection types for this collection are network_cli and netconf. -- This release drops support for `connection: local` and provider dictionary. - -cisco.nxos -~~~~~~~~~~ - -- Please use either of the following connection types - network_cli, httpapi or netconf. -- This release drops support for `connection: local` and provider dictionary. - -community.aws -~~~~~~~~~~~~~ - -- community.aws collection - The amazon.aws collection has dropped support for ``botocore<1.20.0`` and ``boto3<1.17.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/956). - -community.docker -~~~~~~~~~~~~~~~~ - -- The collection now contains vendored code from the Docker SDK for Python to talk to the Docker daemon. Modules and plugins using this code no longer need the Docker SDK for Python installed on the machine the module or plugin is running on (https://github.com/ansible-collections/community.docker/pull/398). -- docker_api connection plugin - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/414). -- docker_container - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/422). -- docker_container - the module was completely rewritten from scratch (https://github.com/ansible-collections/community.docker/pull/422). -- docker_container_exec - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/401). -- docker_container_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/402). -- docker_containers inventory plugin - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/413). -- docker_host_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/403). -- docker_image - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/404). -- docker_image_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/405). -- docker_image_load - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/406). -- docker_login - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/407). -- docker_network - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/408). -- docker_network_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/409). -- docker_plugin - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/429). -- docker_prune - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/410). -- docker_volume - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/411). -- docker_volume_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/412). - -community.general -~~~~~~~~~~~~~~~~~ - -- The internal structure of the collection was changed for modules and action plugins. These no longer live in a directory hierarchy ordered by topic, but instead are now all in a single (flat) directory. This has no impact on users *assuming they did not use internal FQCNs*. These will still work, but result in deprecation warnings. They were never officially supported and thus the redirects are kept as a courtsey, and this is not labelled as a breaking change. Note that for example the Ansible VScode plugin started recommending these internal names. If you followed its recommendation, you will now have to change back to the short names to avoid deprecation warnings, and potential errors in the future as these redirects will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5461). -- newrelic_deployment - removed New Relic v1 API, added support for v2 API (https://github.com/ansible-collections/community.general/pull/5341). - -community.mysql -~~~~~~~~~~~~~~~ - -- mysql_db - the ``pipefail`` argument's default value will be changed to ``true`` in community.mysql 4.0.0. If your target machines do not use ``bash`` as a default interpreter, set ``pipefail`` to ``false`` explicitly. However, we strongly recommend setting up ``bash`` as a default and ``pipefail=true`` as it will protect you from getting broken dumps you don't know about (https://github.com/ansible-collections/community.mysql/issues/407). - -community.network -~~~~~~~~~~~~~~~~~ - -- The community.network collection no longer supports Ansible 2.9 and ansible-base 2.10. While we take no active measures to prevent usage, we will remove compatibility code and other compatility measures that will effectively prevent using most content from this collection with Ansible 2.9, and some content of this collection with ansible-base 2.10. Both Ansible 2.9 and ansible-base 2.10 will very soon be End of Life and if you are still using them, you should consider upgrading to ansible-core 2.11 or later as soon as possible (https://github.com/ansible-collections/community.network/pull/426). -- The internal structure of the collection was changed for modules and action plugins. These no longer live in a directory hierarchy ordered by topic, but instead are now all in a single (flat) directory. This has no impact on users *assuming they did not use internal FQCNs*. These will still work, but result in deprecation warnings. They were never officially supported and thus the redirects are kept as a courtsey, and this is not labelled as a breaking change. Note that for example the Ansible VScode plugin started recommending these internal names. If you followed its recommendation, you will now have to change back to the short names to avoid deprecation warnings, and potential errors in the future as these redirects will be removed in community.network 8.0.0 (https://github.com/ansible-collections/community.network/pull/482). - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_user - the ``groups`` argument has been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``postgresql_membership`` module to specify group/role memberships instead (https://github.com/ansible-collections/community.postgresql/issues/277). - -dellemc.enterprise_sonic -~~~~~~~~~~~~~~~~~~~~~~~~ - -- Added 'static_routes' module to collection (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/82). -- Added a resource module for NTP support (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/99). -- Added a resource module for support of prefix lists (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/100). -- Updated backend REST API request formats in all applicable modules for compatibility with SONiC 4.x openconfig YANG compliant REST APIs. (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/53) - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- Added collection metadata for creating execution environments. -- Refactored the Markdown (MD) files and content for better readability. -- The share parameters are deprecated from the following modules - idrac_network, idrac_timezone_ntp, dellemc_configure_idrac_eventing, dellemc_configure_idrac_services, dellemc_idrac_lc_attributes, dellemc_system_lockdown_mode. -- idrac_bios - The module is enhanced to support clear pending BIOS attributes, reset BIOS to default settings, and configure BIOS attribute using Redfish. -- idrac_boot - Support for configuring the boot settings on iDRAC. -- idrac_redfish_storage_controller - This module is enhanced to support LockVirtualDisk operation. -- idrac_virtual_media - This module allows to configure Remote File Share settings. -- ome_device_group - The module is enhanced to support the removal of devices from a static device group. -- ome_devices - Support for performing device-specific operations on OpenManage Enterprise. - -fortinet.fortimanager -~~~~~~~~~~~~~~~~~~~~~ - -- Fix compatibility issue for ansible 2.9.x and ansible-base 2.10.x. -- Many fixes for Ansible sanity test warnings & errors. -- Support FortiManager Schema 7.2.0 , 98 new modules -- support Ansible changelogs. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support Diff feature in check_mode. -- Support Fortios 7.2.0. - -infoblox.nios_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Feature for extra layer security , with `cert` and `key` parameters in playbooks for authenticating using certificate and key ``*.pem`` file absolute path `#154 `_ -- Fix to remove issue causing due to template attr in deleting network using Ansible module nios network `#147 `_ -- Update `text` field of TXT Record `#128 `_ -- Update operation using `old_name` and `new_name` for the object with dummy name in `old_name` (which does not exist in system) will not create a new object in the system. An error will be thrown stating the object does not exist in the system `#129 `_ - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Use of connection: local and the provider option are no longer valid on any modules in this collection. - -vyos.vyos -~~~~~~~~~ - -- Use of connection: local and the provider option are no longer valid on any modules in this collection. - -Removed Collections -------------------- - -- servicenow.servicenow (previously included version: 1.0.6) - -Removed Features ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- PlayIterator - remove deprecated ``PlayIterator.ITERATING_*`` and ``PlayIterator.FAILED_*`` -- Remove deprecated ``ALLOW_WORLD_READABLE_TMPFILES`` configuration option (https://github.com/ansible/ansible/issues/77393) -- Remove deprecated ``COMMAND_WARNINGS`` configuration option (https://github.com/ansible/ansible/issues/77394) -- Remove deprecated ``DISPLAY_SKIPPED_HOSTS`` environment variable (https://github.com/ansible/ansible/issues/77396) -- Remove deprecated ``LIBVIRT_LXC_NOSECLABEL`` environment variable (https://github.com/ansible/ansible/issues/77395) -- Remove deprecated ``NETWORK_GROUP_MODULES`` environment variable (https://github.com/ansible/ansible/issues/77397) -- Remove deprecated ``UnsafeProxy`` -- Remove deprecated ``plugin_filters_cfg`` config option from ``default`` section (https://github.com/ansible/ansible/issues/77398) -- Remove deprecated functionality that allows loading cache plugins directly without using ``cache_loader``. -- Remove deprecated functionality that allows subclassing ``DefaultCallback`` without the corresponding ``doc_fragment``. -- Remove deprecated powershell functions ``Load-CommandUtils`` and ``Import-PrivilegeUtil`` -- apt_key - remove deprecated ``key`` module param -- command/shell - remove deprecated ``warn`` module param -- get_url - remove deprecated ``sha256sum`` module param -- import_playbook - remove deprecated functionality that allows providing additional parameters in free form - -amazon.aws -~~~~~~~~~~ - -- cloudformation - the ``template_format`` option has been removed. It has been ignored by the module since Ansible 2.3 (https://github.com/ansible-collections/amazon.aws/pull/833). -- ec2_key - the ``wait_timeout`` option had no effect, was deprecated in release 1.0.0, and has now been removed (https://github.com/ansible-collections/amazon.aws/pull/830). -- ec2_key - the ``wait`` option had no effect, was deprecated in release 1.0.0, and has now been removed (https://github.com/ansible-collections/amazon.aws/pull/830). -- ec2_tag - the previously deprecated state ``list`` has been removed. To list tags on an EC2 resource the ``ec2_tag_info`` module can be used (https://github.com/ansible-collections/amazon.aws/pull/829). -- ec2_vol - the previously deprecated state ``list`` has been removed. To list volumes the ``ec2_vol_info`` module can be used (https://github.com/ansible-collections/amazon.aws/pull/828). -- module_utils.batch - the class ``ansible_collections.amazon.aws.plugins.module_utils.batch.AWSConnection`` has been removed. Please use ``AnsibleAWSModule.client()`` instead (https://github.com/ansible-collections/amazon.aws/pull/831). - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- napalm - Removed unused connection plugin. -- net_banner - Use _banner instead. -- net_interface - Use _interfaces instead. -- net_l2_interface - Use _l2_interfaces instead. -- net_l3_interface - Use _l3_interfaces instead. -- net_linkagg - Use _lag_interfaces instead. -- net_lldp - Use _lldp_global instead. -- net_lldp_interface - Use _lldp_interfaces instead. -- net_logging - Use _logging_global instead. -- net_static_route - Use _static_routes instead. -- net_system - Use _system instead. -- net_user - Use _user instead. -- net_vlan - Use _vlans instead. -- net_vrf - Use _vrf instead. - -cisco.ios -~~~~~~~~~ - -- ios_interface - use ios_interfaces instead. -- ios_l2_interface - use ios_l2_interfaces instead. -- ios_l3_interface - use ios_l3_interfaces instead. -- ios_static_route - use ios_static_routes instead. -- ios_vlan - use ios_vlans instead. - -cisco.iosxr -~~~~~~~~~~~ - -- iosxr_interface - use iosxr_interfaces instead. - -cisco.nxos -~~~~~~~~~~ - -- This release removes the following deprecated plugins that have reached their end-of-life. -- nxos_acl -- nxos_acl_interface -- nxos_interface -- nxos_interface_ospf -- nxos_l2_interface -- nxos_l3_interface -- nxos_linkagg -- nxos_lldp -- nxos_ospf -- nxos_ospf_vrf -- nxos_smu -- nxos_static_route -- nxos_vlan - -community.aws -~~~~~~~~~~~~~ - -- aws_kms_info - the unused and deprecated ``keys_attr`` parameter has been removed (https://github.com/ansible-collections/amazon.aws/pull/1172). -- data_pipeline - the ``version`` option has always been ignored and has been removed (https://github.com/ansible-collections/community.aws/pull/1160" -- ec2_eip - The ``wait_timeout`` option has been removed. It has always been ignored by the module (https://github.com/ansible-collections/community.aws/pull/1159). -- ec2_lc - the ``associate_public_ip_address`` option has been removed. It has always been ignored by the module (https://github.com/ansible-collections/community.aws/pull/1158). -- ec2_metric_alarm - support for using the ``<=``, ``<``, ``>`` and ``>=`` operators for comparison has been dropped. Please use ``LessThanOrEqualToThreshold``, ``LessThanThreshold``, ``GreaterThanThreshold`` or ``GreaterThanOrEqualToThreshold`` instead (https://github.com/ansible-collections/amazon.aws/pull/1164). -- ecs_ecr - The deprecated alias ``delete_policy`` has been removed. Please use ``purge_policy`` instead (https://github.com/ansible-collections/community.aws/pull/1161). -- iam_managed_policy - the unused ``fail_on_delete`` parameter has been removed (https://github.com/ansible-collections/community.aws/pull/1168) -- s3_lifecycle - the unused parameter ``requester_pays`` has been removed (https://github.com/ansible-collections/community.aws/pull/1165). -- s3_sync - remove unused ``retries`` parameter (https://github.com/ansible-collections/community.aws/pull/1166). - -community.azure -~~~~~~~~~~~~~~~ - -- azure_rm_aks_facts, azure_rm_aks_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_aks_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_aksversion_facts, azure_rm_aksversion_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_aksversion_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_applicationsecuritygroup_facts, azure_rm_applicationsecuritygroup_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_applicationsecuritygroup_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_appserviceplan_facts, azure_rm_appserviceplan_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_appserviceplan_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_automationaccount_facts, azure_rm_automationaccount_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_automationaccount_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_autoscale_facts, azure_rm_autoscale_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_autoscale_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_availabilityset_facts, azure_rm_availabilityset_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_availabilityset_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_cdnendpoint_facts, azure_rm_cdnendpoint_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_cdnendpoint_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_cdnprofile_facts, azure_rm_cdnprofile_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_cdnprofile_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_containerinstance_facts, azure_rm_containerinstance_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_containerinstance_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_containerregistry_facts, azure_rm_containerregistry_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_containerregistry_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_cosmosdbaccount_facts, azure_rm_cosmosdbaccount_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_cosmosdbaccount_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_deployment_facts, azure_rm_deployment_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_deployment_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlab_facts, azure_rm_devtestlab_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlab_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabarmtemplate_facts, azure_rm_devtestlabarmtemplate_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabarmtemplate_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabartifact_facts, azure_rm_devtestlabartifact_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabartifact_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabartifactsource_facts, azure_rm_devtestlabartifactsource_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabartifactsource_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabcustomimage_facts, azure_rm_devtestlabcustomimage_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabcustomimage_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabenvironment_facts, azure_rm_devtestlabenvironment_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabenvironment_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabpolicy_facts, azure_rm_devtestlabpolicy_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabpolicy_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabschedule_facts, azure_rm_devtestlabschedule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabschedule_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabvirtualmachine_facts, azure_rm_devtestlabvirtualmachine_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabvirtualmachine_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabvirtualnetwork_facts, azure_rm_devtestlabvirtualnetwork_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabvirtualnetwork_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_dnsrecordset_facts, azure_rm_dnsrecordset_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_dnsrecordset_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_dnszone_facts, azure_rm_dnszone_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_dnszone_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_functionapp_facts, azure_rm_functionapp_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_functionapp_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_hdinsightcluster_facts, azure_rm_hdinsightcluster_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_hdinsightcluster_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_image_facts, azure_rm_image_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_image_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_loadbalancer_facts, azure_rm_loadbalancer_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_loadbalancer_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_lock_facts, azure_rm_lock_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_lock_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_loganalyticsworkspace_facts, azure_rm_loganalyticsworkspace_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_loganalyticsworkspace_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_managed_disk, azure_rm_manageddisk - the deprecated modules have been removed. Use azure.azcollection.azure_rm_manageddisk instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_managed_disk_facts, azure_rm_manageddisk_facts, azure_rm_manageddisk_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_manageddisk_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mariadbconfiguration_facts, azure_rm_mariadbconfiguration_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mariadbconfiguration_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mariadbdatabase_facts, azure_rm_mariadbdatabase_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mariadbdatabase_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mariadbfirewallrule_facts, azure_rm_mariadbfirewallrule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mariadbfirewallrule_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mariadbserver_facts, azure_rm_mariadbserver_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mariadbserver_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mysqlconfiguration_facts, azure_rm_mysqlconfiguration_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mysqlconfiguration_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mysqldatabase_facts, azure_rm_mysqldatabase_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mysqldatabase_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mysqlfirewallrule_facts, azure_rm_mysqlfirewallrule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mysqlfirewallrule_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mysqlserver_facts, azure_rm_mysqlserver_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mysqlserver_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_networkinterface_facts, azure_rm_networkinterface_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_networkinterface_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_postgresqlconfiguration_facts, azure_rm_postgresqlconfiguration_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_postgresqlconfiguration_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_postgresqldatabase_facts, azure_rm_postgresqldatabase_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_postgresqldatabase_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_postgresqlfirewallrule_facts, azure_rm_postgresqlfirewallrule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_postgresqlfirewallrule_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_postgresqlserver_facts, azure_rm_postgresqlserver_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_postgresqlserver_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_publicipaddress_facts, azure_rm_publicipaddress_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_publicipaddress_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_rediscache_facts, azure_rm_rediscache_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_rediscache_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_resource_facts, azure_rm_resource_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_resource_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_resourcegroup_facts, azure_rm_resourcegroup_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_resourcegroup_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_roleassignment_facts, azure_rm_roleassignment_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_roleassignment_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_roledefinition_facts, azure_rm_roledefinition_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_roledefinition_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_routetable_facts, azure_rm_routetable_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_routetable_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_securitygroup_facts, azure_rm_securitygroup_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_securitygroup_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_servicebus_facts, azure_rm_servicebus_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_servicebus_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_sqldatabase_facts, azure_rm_sqldatabase_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_sqldatabase_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_sqlfirewallrule_facts, azure_rm_sqlfirewallrule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_sqlfirewallrule_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_sqlserver_facts, azure_rm_sqlserver_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_sqlserver_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_storageaccount_facts, azure_rm_storageaccount_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_storageaccount_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_subnet_facts, azure_rm_subnet_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_subnet_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_trafficmanagerendpoint_facts, azure_rm_trafficmanagerendpoint_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_trafficmanagerendpoint_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_trafficmanagerprofile_facts, azure_rm_trafficmanagerprofile_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_trafficmanagerprofile_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachine_extension, azure_rm_virtualmachineextension - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachineextension instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachine_facts, azure_rm_virtualmachine_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachine_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachine_scaleset, azure_rm_virtualmachinescaleset - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachinescaleset instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachine_scaleset_facts, azure_rm_virtualmachinescaleset_facts, azure_rm_virtualmachinescaleset_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachinescaleset_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachineextension_facts, azure_rm_virtualmachineextension_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachineextension_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachineimage_facts, azure_rm_virtualmachineimage_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachineimage_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachinescalesetextension_facts, azure_rm_virtualmachinescalesetextension_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachinescalesetextension_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachinescalesetinstance_facts, azure_rm_virtualmachinescalesetinstance_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachinescalesetinstance_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualnetwork_facts, azure_rm_virtualnetwork_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualnetwork_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualnetworkpeering_facts, azure_rm_virtualnetworkpeering_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualnetworkpeering_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_webapp_facts, azure_rm_webapp_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_webapp_info instead (https://github.com/ansible-collections/community.azure/pull/31). - -community.docker -~~~~~~~~~~~~~~~~ - -- Execution Environments built with community.docker no longer include docker-compose < 2.0.0. If you need to use it with the ``docker_compose`` module, please install that requirement manually (https://github.com/ansible-collections/community.docker/pull/400). -- Support for Ansible 2.9 and ansible-base 2.10 has been removed. If you need support for Ansible 2.9 or ansible-base 2.10, please use community.docker 2.x.y (https://github.com/ansible-collections/community.docker/pull/400). -- Support for Docker API versions 1.20 to 1.24 has been removed. If you need support for these API versions, please use community.docker 2.x.y (https://github.com/ansible-collections/community.docker/pull/400). -- Support for Python 2.6 has been removed. If you need support for Python 2.6, please use community.docker 2.x.y (https://github.com/ansible-collections/community.docker/pull/400). -- Various modules - the default of ``tls_hostname`` (``localhost``) has been removed. If you want to continue using ``localhost``, you need to specify it explicitly (https://github.com/ansible-collections/community.docker/pull/363). -- docker_container - the ``all`` value is no longer allowed in ``published_ports``. Use ``publish_all_ports=true`` instead (https://github.com/ansible-collections/community.docker/pull/399). -- docker_container - the default of ``command_handling`` was changed from ``compatibility`` to ``correct``. Older versions were warning for every invocation of the module when this would result in a change of behavior (https://github.com/ansible-collections/community.docker/pull/399). -- docker_stack - the return values ``out`` and ``err`` have been removed. Use ``stdout`` and ``stderr`` instead (https://github.com/ansible-collections/community.docker/pull/363). - -community.general -~~~~~~~~~~~~~~~~~ - -- bitbucket* modules - ``username`` is no longer an alias of ``workspace``, but of ``user`` (https://github.com/ansible-collections/community.general/pull/5326). -- gem - the default of the ``norc`` option changed from ``false`` to ``true`` (https://github.com/ansible-collections/community.general/pull/5326). -- gitlab_group_members - ``gitlab_group`` must now always contain the full path, and no longer just the name or path (https://github.com/ansible-collections/community.general/pull/5326). -- keycloak_authentication - the return value ``flow`` has been removed. Use ``end_state`` instead (https://github.com/ansible-collections/community.general/pull/5326). -- keycloak_group - the return value ``group`` has been removed. Use ``end_state`` instead (https://github.com/ansible-collections/community.general/pull/5326). -- lxd_container - the default of the ``ignore_volatile_options`` option changed from ``true`` to ``false`` (https://github.com/ansible-collections/community.general/pull/5326). -- mail callback plugin - the ``sender`` option is now required (https://github.com/ansible-collections/community.general/pull/5326). -- module_helper module utils - remove the ``VarDict`` attribute from ``ModuleHelper``. Import ``VarDict`` from ``ansible_collections.community.general.plugins.module_utils.mh.mixins.vars`` instead (https://github.com/ansible-collections/community.general/pull/5326). -- proxmox inventory plugin - the default of the ``want_proxmox_nodes_ansible_host`` option changed from ``true`` to ``false`` (https://github.com/ansible-collections/community.general/pull/5326). -- vmadm - the ``debug`` option has been removed. It was not used anyway (https://github.com/ansible-collections/community.general/pull/5326). - -community.network -~~~~~~~~~~~~~~~~~ - -- aireos modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- aireos modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- aruba modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- aruba modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ce modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ce modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- enos modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- enos modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ironware modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ironware modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- sros modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- sros modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vca_fw - The deprecated module ``vca_fw`` has been removed. -- vca_nat - The deprecated module ``vca_nat`` has been removed. -- vca_vapp - The deprecated module ``vca_vapp`` has been removed. -- vmware_dns_config - The deprecated module ``vmware_dns_config`` has been removed, you can use ``vmware_host_dns`` instead. -- vmware_guest_network - The deprecated parameter ``networks`` has been removed, use loops to handle multiple interfaces (https://github.com/ansible-collections/community.vmware/pull/1459). -- vmware_guest_vnc - The deprecated module ``vmware_guest_vnc`` has been removed. The VNC support has been dropped with vSphere 7 and later (https://github.com/ansible-collections/community.vmware/pull/1454). -- vmware_host_firewall_manager - The module doesn't accept a list for ``allowed_hosts`` anymore, use a dict instead. Additionally, ``all_ip`` is now a required sub-option of ``allowed_hosts`` (https://github.com/ansible-collections/community.vmware/pull/1463). -- vsphere_copy - The deprecated parameters ``host`` and ``login`` have been removed. Use ``hostname`` and ``username`` instead (https://github.com/ansible-collections/community.vmware/pull/1456). - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Remove following deprecated Junos Modules. -- junos_interface -- junos_l2_interface -- junos_l3_interface -- junos_linkagg -- junos_lldp -- junos_lldp_interface -- junos_static_route -- junos_vlan - -vyos.vyos -~~~~~~~~~ - -- vyos_interface - use vyos_interfaces instead. -- vyos_l3_interface - use vyos_l3_interfaces instead. -- vyos_linkagg - use vyos_lag_interfaces instead. -- vyos_lldp - use vyos_lldp_global instead. -- vyos_lldp_interface - use vyos_lldp_interfaces instead. -- vyos_static_route - use vyos_static_routes instead. - -Deprecated Features -------------------- - -- The dellemc.os10 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/134). -- The dellemc.os6 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/132). -- The dellemc.os9 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/133). -- The google.cloud collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/105). -- The mellanox.onyx collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/136). - -Ansible-core -~~~~~~~~~~~~ - -- Deprecate ability of lookup plugins to return arbitrary data. Lookup plugins must return lists, failing to do so will be an error in 2.18. (https://github.com/ansible/ansible/issues/77788) -- Encryption - Deprecate use of the Python crypt module due to it's impending removal from Python 3.13 -- PlayContext.verbosity is deprecated and will be removed in 2.18. Use ansible.utils.display.Display().verbosity as the single source of truth. -- ``DEFAULT_FACT_PATH``, ``DEFAULT_GATHER_SUBSET`` and ``DEFAULT_GATHER_TIMEOUT`` are deprecated and will be removed in 2.18. Use ``module_defaults`` keyword instead. -- ``PlayIterator`` - deprecate ``cache_block_tasks`` and ``get_original_task`` which are noop and unused. -- ``Templar`` - deprecate ``shared_loader_obj`` option which is unused. ``ansible.plugins.loader`` is used directly instead. -- listify_lookup_plugin_terms, deprecate 'loader/dataloader' parameter as it not used. -- vars plugins - determining whether or not to run ansible.legacy vars plugins with the class attribute REQUIRES_WHITELIST is deprecated, set REQUIRES_ENABLED instead. - -amazon.aws -~~~~~~~~~~ - -- amazon.aws collection - Support for the ``EC2_ACCESS_KEY`` environment variable has been deprecated and will be removed in a release after 2024-12-01. Please use the ``access_key`` parameter or ``AWS_ACCESS_KEY_ID`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - Support for the ``EC2_REGION`` environment variable has been deprecated and will be removed in a release after 2024-12-01. Please use the ``region`` parameter or ``AWS_REGION`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - Support for the ``EC2_SECRET_KEY`` environment variable has been deprecated and will be removed in a release after 2024-12-01. Please use the ``secret_key`` parameter or ``AWS_SECRET_ACCESS_KEY`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - Support for the ``EC2_SECURITY_TOKEN`` environment variable has been deprecated and will be removed in a release after 2024-12-01. Please use the ``session_token`` parameter or ``AWS_SESSION_TOKEN`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - Support for the ``EC2_URL`` and ``S3_URL`` environment variables has been deprecated and will be removed in a release after 2024-12-01. Please use the ``endpoint_url`` parameter or ``AWS_ENDPOINT_URL`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - The ``access_token`` alias for the ``session_token`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``session_token`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - The ``aws_security_token`` alias for the ``session_token`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``session_token`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - The ``ec2_access_key`` alias for the ``access_key`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``access_key`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - The ``ec2_region`` alias for the ``region`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``region`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - The ``ec2_secret_key`` alias for the ``secret_key`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``secret_key`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - The ``security_token`` alias for the ``session_token`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``session_token`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - due to the AWS SDKs announcing the end of support for Python less than 3.7 (https://aws.amazon.com/blogs/developer/python-support-policy-updates-for-aws-sdks-and-tools/) support for Python less than 3.7 by this collection has been deprecated and will be removed in a release after 2023-05-31 (https://github.com/ansible-collections/amazon.aws/pull/935). -- aws_s3 - The ``S3_URL`` alias for the s3_url option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- ec2_ami - The ``DeviceName`` alias for the device_name option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- ec2_ami - The ``NoDevice`` alias for the no_device option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- ec2_ami - The ``VirtualName`` alias for the virtual_name option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- ec2_ami - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846). -- ec2_instance - The default value for ```instance_type``` has been deprecated, in the future release you must set an instance_type or a launch_template (https://github.com/ansible-collections/amazon.aws/pull/587). -- ec2_instance - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/849). -- ec2_key - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846). -- ec2_security_group - support for passing nested lists to ``cidr_ip`` and ``cidr_ipv6`` has been deprecated. Nested lists can be passed through the ``flatten`` filter instead ``cidr_ip: '{{ my_cidrs | flatten }}'`` (https://github.com/ansible-collections/amazon.aws/pull/1213). -- ec2_vol - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846). -- ec2_vpc_dhcp_option_info - The ``DhcpOptionIds`` alias for the dhcp_option_ids option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- ec2_vpc_dhcp_option_info - The ``DryRun`` alias for the dry_run option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- ec2_vpc_endpoint - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846). -- ec2_vpc_net - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/848). -- ec2_vpc_route_table - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846). -- inventory/aws_ec2 - the ``include_extra_api_calls`` is now deprecated, its value is silently ignored (https://github.com/ansible-collections/amazon.aws/pull/1097). -- module_utils.cloud - removal of the ``CloudRetry.backoff`` has been delayed until release 6.0.0. It is recommended to update custom modules to use ``jittered_backoff`` or ``exponential_backoff`` instead (https://github.com/ansible-collections/amazon.aws/pull/951). -- module_utils.url - ``ansible_collections.amazon.aws.module_utils.urls`` is believed to be unused and has been deprecated and will be removed in release 7.0.0. -- s3_bucket - The ``S3_URL`` alias for the s3_url option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- s3_object - Support for creation and deletion of S3 buckets has been deprecated. Please use the ``amazon.aws.s3_bucket`` module to create and delete buckets (https://github.com/ansible-collections/amazon.aws/pull/869). - -cisco.ios -~~~~~~~~~ - -- Deprecated ios_linkagg_module in favor of ios_lag_interfaces. - -cisco.mso -~~~~~~~~~ - -- The mso_schema_template_contract_filter contract_filter_type attribute is deprecated. The value is now deduced from filter_type. - -community.aws -~~~~~~~~~~~~~ - -- aws_acm - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- aws_codebuild - The ``tags`` parameter currently uses a non-standard format and has been deprecated. In release 6.0.0 this parameter will accept a simple key/value pair dictionary instead of the current list of dictionaries. It is recommended to migrate to using the resource_tags parameter which already accepts the simple dictionary format (https://github.com/ansible-collections/community.aws/pull/1221). -- aws_glue_connection - the ``connection_parameters`` return key has been deprecated and will be removed in a release after 2024-06-01, it is being replaced by the ``raw_connection_parameters`` key (https://github.com/ansible-collections/community.aws/pull/518). -- aws_kms - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- cloudfront_distribution - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- community.aws collection - due to the AWS SDKs announcing the end of support for Python less than 3.7 (https://aws.amazon.com/blogs/developer/python-support-policy-updates-for-aws-sdks-and-tools/) support for Python less than 3.7 by this collection has been deprecated and will be removed in a release after 2023-05-31 (https://github.com/ansible-collections/community.aws/pull/1361). -- ec2_vpc_vpn - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- iam_policy - the ``policies`` return value has been renamed ``policy_names`` and will be removed in a release after 2024-08-01, both values are currently returned (https://github.com/ansible-collections/community.aws/pull/1375). -- lambda_info - The ``function`` return key returns a dictionary of dictionaries and has been deprecated. In a release after 2025-01-01, this key will be removed in favor of ``functions``, which returns a list of dictionaries (https://github.com/ansible-collections/community.aws/pull/1239). -- rds_param_group - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- route53_health_check - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- route53_info - The CamelCase return values for ``DelegationSets``, ``CheckerIpRanges``, and ``HealthCheck`` have been deprecated, in the future release you must use snake_case return values ``delegation_sets``, ``checker_ip_ranges``, and ``health_check`` instead respectively" (https://github.com/ansible-collections/community.aws/pull/1322). -- route53_info - The CamelCase return values for ``HostedZones``, ``ResourceRecordSets``, and ``HealthChecks`` have been deprecated, in the future release you must use snake_case return values ``hosted_zones``, ``resource_record_sets``, and ``health_checks`` instead respectively". -- route53_zone - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- sqs_queue - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. - -community.crypto -~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.crypto 3.0.0). Some modules might still work with these versions afterwards, but we will no longer keep compatibility code that was needed to support them (https://github.com/ansible-collections/community.crypto/pull/460). - -community.docker -~~~~~~~~~~~~~~~~ - -- Support for Docker API version 1.20 to 1.24 has been deprecated and will be removed in community.docker 3.0.0. The first Docker version supporting API version 1.25 was Docker 1.13, released in January 2017. This affects the modules ``docker_container``, ``docker_container_exec``, ``docker_container_info``, ``docker_compose``, ``docker_login``, ``docker_image``, ``docker_image_info``, ``docker_image_load``, ``docker_host_info``, ``docker_network``, ``docker_network_info``, ``docker_node_info``, ``docker_swarm_info``, ``docker_swarm_service``, ``docker_swarm_service_info``, ``docker_volume_info``, and ``docker_volume``, whose minimally supported API version is between 1.20 and 1.24 (https://github.com/ansible-collections/community.docker/pull/396). -- Support for Python 2.6 is deprecated and will be removed in the next major release (community.docker 3.0.0). Some modules might still work with Python 2.6, but we will no longer try to ensure compatibility (https://github.com/ansible-collections/community.docker/pull/388). -- docker_container - the ``ignore_image`` option is deprecated and will be removed in community.docker 4.0.0. Use ``image: ignore`` in ``comparisons`` instead (https://github.com/ansible-collections/community.docker/pull/487). -- docker_container - the ``purge_networks`` option is deprecated and will be removed in community.docker 4.0.0. Use ``networks: strict`` in ``comparisons`` instead, and make sure to provide ``networks``, with value ``[]`` if all networks should be removed (https://github.com/ansible-collections/community.docker/pull/487). - -community.general -~~~~~~~~~~~~~~~~~ - -- ArgFormat module utils - deprecated along ``CmdMixin``, in favor of the ``cmd_runner_fmt`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- CmdMixin module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- CmdModuleHelper module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- CmdStateModuleHelper module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- cmd_runner module utils - deprecated ``fmt`` in favour of ``cmd_runner_fmt`` as the parameter format object (https://github.com/ansible-collections/community.general/pull/4777). -- django_manage - support for Django releases older than 4.1 has been deprecated and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5400). -- django_manage - support for the commands ``cleanup``, ``syncdb`` and ``validate`` that have been deprecated in Django long time ago will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5400). -- django_manage - the behavior of "creating the virtual environment when missing" is being deprecated and will be removed in community.general version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5405). -- gconftool2 - deprecates ``state=get`` in favor of using the module ``gconftool2_info`` (https://github.com/ansible-collections/community.general/pull/4778). -- lxc_container - the module will no longer make any effort to support Python 2 (https://github.com/ansible-collections/community.general/pull/5304). -- newrelic_deployment - ``appname`` and ``environment`` are no longer valid options in the v2 API. They will be removed in community.general 7.0.0 (https://github.com/ansible-collections/community.general/pull/5341). -- proxmox - deprecated the current ``unprivileged`` default value, will be changed to ``true`` in community.general 7.0.0 (https://github.com/pull/5224). -- xfconf - deprecated parameter ``disable_facts``, as since version 4.0.0 it only allows value ``true`` (https://github.com/ansible-collections/community.general/pull/4520). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- vault_kv2_get lookup - the ``engine_mount_point option`` in the ``vault_kv2_get`` lookup only will change its default from ``kv`` to ``secret`` in community.hashi_vault version 4.0.0 (https://github.com/ansible-collections/community.hashi_vault/issues/279). diff --git a/docs/docsite/rst/porting_guides/porting_guide_8.rst b/docs/docsite/rst/porting_guides/porting_guide_8.rst deleted file mode 100644 index ca1cbf34ef3..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_8.rst +++ /dev/null @@ -1,564 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_core_2.15.rst) - -.. _porting_8_guide: - -======================= -Ansible 8 Porting Guide -======================= - -.. contents:: - :local: - :depth: 2 - - -Ansible 8 is based on Ansible-core 2.15. - - -We suggest you read this page along with the `Ansible 8 Changelog `_ to understand what updates you may need to make. - - -Playbook -======== - -No notable changes - - -Command Line -============ - -* The return code of ``ansible-galaxy search`` is now 0 instead of 1 and the stdout is empty when results are empty to align with other ``ansible-galaxy`` commands. - - -Deprecated -========== - -* Providing a list of dictionaries to ``vars:`` is deprecated in favor of supplying a dictionary. - - Instead of: - - .. code-block:: yaml - - vars: - - var1: foo - - var2: bar - - Use: - - .. code-block:: yaml - - vars: - var1: foo - var2: bar - -Modules -======= - -No notable changes - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Plugins -======= - -No notable changes - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes - -Porting Guide for v8.0.0 -======================== - -Added Collections ------------------ - -- dellemc.powerflex (version 1.6.0) -- dellemc.unity (version 1.6.0) -- grafana.grafana (version 2.0.0) -- microsoft.ad (version 1.1.0) -- servicenow.servicenow (version 1.0.6) - -Known Issues ------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - Additional configuration may be required for certain container host and container combinations. Further details are available in the testing documentation. -- ansible-test - Custom containers with ``VOLUME`` instructions may be unable to start, when previously the containers started correctly. Remove the ``VOLUME`` instructions to resolve the issue. Containers with this condition will cause ``ansible-test`` to emit a warning. -- ansible-test - Systems with Podman networking issues may be unable to run containers, when previously the issue went unreported. Correct the networking issues to continue using ``ansible-test`` with Podman. -- ansible-test - Unit tests for collections do not support ``pytest`` assertion rewriting on Python 2.7. -- ansible-test - Using Docker on systems with SELinux may require setting SELinux to permissive mode. Podman should work with SELinux in enforcing mode. -- dnf5 - The DNF5 package manager currently does not provide all functionality to ensure feature parity between the existing ``dnf`` and the new ``dnf5`` module. As a result the following ``dnf5`` options are effectively a no-op: ``cacheonly``, ``enable_plugin``, ``disable_plugin`` and ``lock_timeout``. - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_network - Updated documentation for `local_status_page_enabled` and `remote_status_page_enabled` as these no longer work. - -community.docker -~~~~~~~~~~~~~~~~ - -- The modules and plugins using the vendored code from Docker SDK for Python currently do not work with requests 2.29.0 and/or urllib3 2.0.0. The same is currently true for the latest version of Docker SDK for Python itself (https://github.com/ansible-collections/community.docker/issues/611, https://github.com/ansible-collections/community.docker/pull/612). -- docker_api connection plugin - does **not work with TCP TLS sockets**! This is caused by the inability to send an ``close_notify`` TLS alert without closing the connection with Python's ``SSLSocket`` (https://github.com/ansible-collections/community.docker/issues/605, https://github.com/ansible-collections/community.docker/pull/621). -- docker_container_exec - does **not work with TCP TLS sockets** when the ``stdin`` option is used! This is caused by the inability to send an ``close_notify`` TLS alert without closing the connection with Python's ``SSLSocket`` (https://github.com/ansible-collections/community.docker/issues/605, https://github.com/ansible-collections/community.docker/pull/621). - -community.routeros -~~~~~~~~~~~~~~~~~~ - -- api_modify - when limits for entries in ``queue tree`` are defined as human readable - for example ``25M`` -, the configuration will be correctly set in ROS, but the module will indicate the item is changed on every run even when there was no change done. This is caused by the ROS API which returns the number in bytes - for example ``25000000`` (which is inconsistent with the CLI behavior). In order to mitigate that, the limits have to be defined in bytes (those will still appear as human readable in the ROS CLI) (https://github.com/ansible-collections/community.routeros/pull/131). -- api_modify, api_info - ``routing ospf area``, ``routing ospf area range``, ``routing ospf instance``, ``routing ospf interface-template`` paths are not fully implemeted for ROS6 due to the significat changes between ROS6 and ROS7 (https://github.com/ansible-collections/community.routeros/pull/131). - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_firmware - Issue(249879) - Firmware update of iDRAC9-based Servers fails if SOCKS proxy with authentication is used. -- idrac_os_deployment- Issue(260496) - OS installation will support only NFS and CIFS share to store the custom ISO in the destination_path, HTTP/HTTPS/FTP not supported -- idrac_redfish_storage_contoller - Issue(256164) - If incorrect value is provided for one of the attributes in the provided attribute list for controller configuration, then this module does not exit with error. -- idrac_user - Issue(192043) The module may error out with the message ``Unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the following parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout. -- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout. -- ome_device_power_settings - Issue(212679) - The module displays the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_inventory - Issue(256257) - All hosts are not retrieved for ``Modular System`` group and corresponding child groups. -- ome_inventory - Issue(256589) - All hosts are not retrieved for ``Custom Groups`` group and corresponding child groups. -- ome_inventory - Issue(256593) - All hosts are not retrieved for ``PLUGIN GROUPS`` group and corresponding child groups. -- ome_smart_fabric_uplink - Issue(186024) - Despite the module supported by OpenManage Enterprise Modular, it does not allow the creation of multiple uplinks of the same name. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. -- ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Breaking Changes ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-doc - no longer treat plugins in collections whose name starts with ``_`` as deprecated (https://github.com/ansible/ansible/pull/79362). -- ansible-test - Integration tests which depend on specific file permissions when running in an ansible-test managed host environment may require changes. Tests that require permissions other than ``755`` or ``644`` may need to be updated to set the necessary permissions as part of the test run. -- ansible-test - The ``vcenter`` test plugin now defaults to using a user-provided static configuration instead of the ``govcsim`` simulator for collections. Set the ``ANSIBLE_VCSIM_CONTAINER`` environment variable to ``govcsim`` to use the simulator. Keep in mind that the simulator is deprecated and will be removed in a future release. -- ansible-test sanity - previously plugins and modules in collections whose name started with ``_`` were treated as deprecated, even when they were not marked as deprecated in ``meta/runtime.yml``. This is no longer the case (https://github.com/ansible/ansible/pull/79362). -- ansible-test validate-modules - Removed the ``missing-python-doc`` error code in validate modules, ``missing-documentation`` is used instead for missing PowerShell module documentation. - -amazon.aws -~~~~~~~~~~ - -- The amazon.aws collection has dropped support for ``botocore<1.25.0`` and ``boto3<1.22.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/1342). -- amazon.aws - compatibility code for Python < 3.6 has been removed (https://github.com/ansible-collections/amazon.aws/pull/1257). -- ec2_eip - the previously deprecated ``instance_id`` alias for the ``device_id`` parameter has been removed. Please use the ``device_id`` parameter name instead (https://github.com/ansible-collections/amazon.aws/issues/1176). -- ec2_instance - the default value for ``instance_type`` has been removed. At least one of ``instance_type`` or ``launch_template`` must be specified when launching new instances (https://github.com/ansible-collections/amazon.aws/pull/1315). -- ec2_vpc_dhcp_options - the ``new_options`` return value has been deprecated after being renamed to ``dhcp_config``. Please use the ``dhcp_config`` or ``dhcp_options`` return values (https://github.com/ansible-collections/amazon.aws/pull/1327). -- ec2_vpc_endpoint - the ``policy_file`` parameter has been removed. I(policy) with a file lookup can be used instead (https://github.com/ansible-collections/amazon.aws/issues/1178). -- ec2_vpc_net - the ``classic_link_enabled`` return value has been removed. Support for EC2 Classic networking was dropped by AWS (https://github.com/ansible-collections/amazon.aws/pull/1374). -- ec2_vpc_net_info - the ``classic_link_dns_status`` return value has been removed. Support for EC2 Classic networking was dropped by AWS (https://github.com/ansible-collections/amazon.aws/pull/1374). -- ec2_vpc_net_info - the ``classic_link_enabled`` return value has been removed. Support for EC2 Classic networking was dropped by AWS (https://github.com/ansible-collections/amazon.aws/pull/1374). -- module_utils.cloud - the previously deprecated ``CloudRetry.backoff`` has been removed. Please use ``CloudRetry.exponential_backoff`` or ``CloudRetry.jittered_backoff`` instead (https://github.com/ansible-collections/amazon.aws/issues/1110). - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- NetworkConnectionBase now inherits from PersistentConnectionBase in ansible.utils. As a result, the minimum ansible.utils version has increased to 2.7.0. -- NetworkTemplate is no longer importable from ansible_collections.ansible.netcommon.plugins.module_utils.network.common and should now be found at its proper location ansible_collections.ansible.netcommon.plugins.module_utils.network.common.rm_base.network_template -- ResourceModule is no longer importable from ansible_collections.ansible.netcommon.plugins.module_utils.network.common and should now be found at its proper location ansible_collections.ansible.netcommon.plugins.module_utils.network.common.rm_base.resource_module -- VALID_MASKS, is_masklen, is_netmask, to_bits, to_ipv6_network, to_masklen, to_netmask, and to_subnet are no longer importable from ansible_collections.ansible.netcommon.plugins.module_utils.network.common.utils and should now be found at their proper location ansible.module_utils.common.network - -community.aws -~~~~~~~~~~~~~ - -- The community.aws collection has dropped support for ``botocore<1.25.0`` and ``boto3<1.22.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/1743). -- aws_ssm - the AWS SSM plugin was incorrectly prepending ``sudo`` to most commands. This behaviour was incorrect and has been removed. To execute commands as a specific user, including the ``root`` user, the ``become`` and ``become_user`` directives should be used. See the `Ansible documentation for more information `_ (https://github.com/ansible-collections/community.aws/issues/853). -- codebuild_project - ``tags`` parameter now accepts a dict representing the tags, rather than the boto3 format (https://github.com/ansible-collections/community.aws/pull/1643). - -community.general -~~~~~~~~~~~~~~~~~ - -- If you are not using this collection as part of Ansible, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.sap_libs`` if you are using any of the ``sapcar_extract``, ``sap_task_list_execute``, and ``hana_query`` modules. - Without that collection installed, the redirects for these modules do not work. -- ModuleHelper module utils - when the module sets output variables named ``msg``, ``exception``, ``output``, ``vars``, or ``changed``, the actual output will prefix those names with ``_`` (underscore symbol) only when they clash with output variables generated by ModuleHelper itself, which only occurs when handling exceptions. Please note that this breaking change does not require a new major release since before this release, it was not possible to add such variables to the output `due to a bug `__ (https://github.com/ansible-collections/community.general/pull/5765). -- gconftool2 - fix processing of ``gconftool-2`` when ``key`` does not exist, returning ``null`` instead of empty string for both ``value`` and ``previous_value`` return values (https://github.com/ansible-collections/community.general/issues/6028). -- gitlab_runner - the default of ``access_level_on_creation`` changed from ``false`` to ``true`` (https://github.com/ansible-collections/community.general/pull/6428). -- ldap_search - convert all string-like values to UTF-8 (https://github.com/ansible-collections/community.general/issues/5704, https://github.com/ansible-collections/community.general/pull/6473). -- nmcli - the default of the ``hairpin`` option changed from ``true`` to ``false`` (https://github.com/ansible-collections/community.general/pull/6428). -- proxmox - the default of the ``unprivileged`` option changed from ``false`` to ``true`` (https://github.com/ansible-collections/community.general/pull/6428). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- Support for ``ansible-core`` 2.11 and 2.12 has been removed (https://github.com/ansible-collections/community.hashi_vault/issues/340). -- The minimum version of ``hvac`` for ``community.hashi_vault`` is now ``1.1.0`` (https://github.com/ansible-collections/community.hashi_vault/issues/324). -- hashi_vault lookup - duplicate option entries in the term string now raises an exception instead of a warning (https://github.com/ansible-collections/community.hashi_vault/issues/356). - -community.zabbix -~~~~~~~~~~~~~~~~ - -- agent role - removed support for Darwin, Amazon, Fedora, XCP-ng, Suse, Mint, and Sangoma operating systems -- agent role - removed support for zabbix_create_host and replaced it with zabbix_agent_host_state -- agent role - removed support for zabbix_create_hostgroup and replaced it with zabbix_agent_hostgroups_state -- agent role - removed support for zabbix_http_password, zabbix_api_http_password, zabbix_api_pass, and zabbix_api_login_pass and replaced it with zabbix_api_login_pass -- agent role - removed support for zabbix_http_user, zabbix_api_http_user, zabbix_api_user, and zabbix_api_login_user and replaced it with zabbix_api_login_user -- agent role - removed support for zabbix_inventory_mode and replaced it with zabbix_agent_inventory_mode -- agent role - removed support for zabbix_link_templates adn replaced it with zabbix_agent_link_templates -- agent role - removed support for zabbix_macros and replaced it with zabbix_agent_macros -- agent role - removed support for zabbix_proxy and replaced it with zabbix_agent_proxy -- agent role - removed support for zabbix_update_host and replaced it with zabbix_agent_host_update -- all modules - dropped support of Zabbix versions < 6.0 -- all roles - removed support for the zabbix_version variable. -- all roles - removed support for all versions of Zabbix < 6.0. -- all roles - removed support for installation from epel and non-standard repositories -- dropped support of zabbix-api to make REST API calls to Zabbix -- proxy role - removed support for zabbix_database_creation and replaced it with zabbix_proxy_database_creation -- proxy role - removed support for zabbix_database_sqlload and replaced it with zabbix_proxy_database_sqlload -- proxy role - removed support for zabbix_selinux and replaced it with zabbix_proxy_selinux -- server role - removed support for zabbix_server_mysql_login_password and replaced with zabbix_server_dbpassword -- server role - removed support for zabbix_server_mysql_login_user and replaced with zabbix_server_dbuser -- stopped supporting Ansible < 2.12 -- stopped supporting Python < 3.9 -- zabbix_action - message parameter renamed to op_message -- zabbix_group_facts module - removed in favour of zabbix_group_info -- zabbix_host_facts module - removed in favour of zabbix_host_info - -hetzner.hcloud -~~~~~~~~~~~~~~ - -- inventory plugin - Python v3.5+ is now required. - -lowlydba.sqlserver -~~~~~~~~~~~~~~~~~~ - -- Updating minimum DBATools version to v2.0.0 to allow for pwsh 7.3+ compatibility. There may also be breaking change behavior in DBATools, see https://blog.netnerds.net/2023/03/whats-new-dbatools-2.0/. (https://github.com/lowlydba/lowlydba.sqlserver/pull/181) - -Major Changes -------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - Docker Desktop on WSL2 is now supported (additional configuration required). -- ansible-test - Docker and Podman are now supported on hosts with cgroup v2 unified. Previously only cgroup v1 and cgroup v2 hybrid were supported. -- ansible-test - Podman now works on container hosts without systemd. Previously only some containers worked, while others required rootfull or rootless Podman, but would not work with both. Some containers did not work at all. -- ansible-test - Podman on WSL2 is now supported. -- ansible-test - When additional cgroup setup is required on the container host, this will be automatically detected. Instructions on how to configure the host will be provided in the error message shown. - -ansible.windows -~~~~~~~~~~~~~~~ - -- Set the minimum Ansible version supported by this collection to Ansible 2.12 - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Allow users to select the TLS versions used for bootstrapping Chocolatey installation. - -cisco.iosxr -~~~~~~~~~~~ - -- iosxr_l3_interfaces - fix issue in ipv4 address formatting. (https://github.com/ansible-collections/cisco.iosxr/issues/311). - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_mr_l7_firewall - New module -- meraki_webhook_payload_template - New module - -community.hrobot -~~~~~~~~~~~~~~~~ - -- firewall - Hetzner added output rules support to the firewall. This change unfortunately means that using old versions of the firewall module will always set the output rule list to empty, thus disallowing the server to send out packets (https://github.com/ansible-collections/community.hrobot/issues/75, https://github.com/ansible-collections/community.hrobot/pull/76). - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_privs - the ``password`` argument is deprecated and will be removed in community.postgresql 4.0.0, use the ``login_password`` argument instead (https://github.com/ansible-collections/community.postgresql/issues/406). - -community.vmware -~~~~~~~~~~~~~~~~ - -- Use true/false (lowercase) for boolean values in documentation and examples (https://github.com/ansible-collections/community.vmware/issues/1660). - -community.zabbix -~~~~~~~~~~~~~~~~ - -- all modules are opting away from zabbix-api and using httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate -- zabbix_agent and zabbix_proxy roles are opting away from zabbix-api and use httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate - -containers.podman -~~~~~~~~~~~~~~~~~ - -- New become plugin - podman_unshare -- Podman generate systemd module - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- Rebranded from Dell EMC to Dell. -- Support for IPv6 address for OMSDK dependent iDRAC modules. -- idrac_firmware - This module is enhanced to support proxy. -- idrac_redfish_storage_controller - This module is enhanced to configure controller attributes and online capacity expansion. -- idrac_server_config_profile - This module is enhanced to support proxy settings, import buffer, include in export, and ignore certificate warning. -- idrac_user_info - This module allows to retrieve iDRAC Local user information details. -- ome_domian_user_groups - This module allows to import the LDAP directory groups. -- ome_inventory - This plugin allows to create a inventory from the group on OpenManage Enterprise. -- ome_inventory - This plugin is enhanced to support inventory retrieval of System and Plugin Groups of OpenManage Enterprise. -- ome_profile_info - This module allows to retrieve profiles with attributes on OpenManage Enterprise or OpenManage Enterprise Modular. -- ome_smart_fabric_info - This module retrieves the list of smart fabrics in the inventory of OpenManage Enterprise Modular. -- ome_smart_fabric_uplink_info - This module retrieve details of fabric uplink on OpenManage Enterprise Modular. -- ome_template_network_vlan_info - This module allows to retrieve the network configuration of a template on OpenManage Enterprise or OpenManage Enterprise Modular. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Add annotations of member operation for every module. -- Support FortiOS v7.0.6, v7.0.7, v7.0.8, v7.2.1, v7.2.2. -- Update ``fortios.py`` for higher performance; -- supports temporary session key and pre/post login banner; -- update the examples on how to use member operation in Q&A. - -infoblox.nios_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Added Grid Master Candidate feature `#152 `_ -- Added Member Assignment to network and ranges `#152 `_ -- Added NIOS Range module with Create, Update and Delete features `#152 `_ -- Fixes issue unable to update/delete EAs using Ansible plugin `#180 `_ -- Fixes static and dynamic allocation of IPV4 address of A Record `#182 `_ -- Fixes to Update host name of NIOS member `#176 `_ -- Updates default WAPI version to 2.9 `#176 `_ - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- change gathered key from junos_acls to acls - -kubernetes.core -~~~~~~~~~~~~~~~ - -- refactor K8sAnsibleMixin into module_utils/k8s/ (https://github.com/ansible-collections/kubernetes.core/pull/481). - -purestorage.fusion -~~~~~~~~~~~~~~~~~~ - -- Patching of resource properties was brought to parity with underlying Python SDK -- fusion_volume - fixed and reorganized, arguments changed - -Removed Collections -------------------- - -- dellemc.os10 (previously included version: 1.1.1) -- dellemc.os6 (previously included version: 1.0.7) -- dellemc.os9 (previously included version: 1.0.4) -- mellanox.onyx (previously included version: 1.0.0) - -Removed Features ----------------- - -- ``dellemc.os10`` was considered unmaintained and removed from Ansible 8 as per the `removal from Ansible process `_. Users can still install this collection with ``ansible-galaxy collection install dellemc.os10``. -- ``dellemc.os6`` was considered unmaintained and removed from Ansible 8 as per the `removal from Ansible process `_. Users can still install this collection with ``ansible-galaxy collection install dellemc.os6``. -- ``dellemc.os9`` was considered unmaintained and removed from Ansible 8 as per the `removal from Ansible process `_. Users can still install this collection with ``ansible-galaxy collection install dellemc.os9``. -- ``mellanox.onyx`` was considered unmaintained and removed from Ansible 8 as per the `removal from Ansible process `_. Users can still install this collection with ``ansible-galaxy collection install mellanox.onyx``. - -Ansible-core -~~~~~~~~~~~~ - -- Remove deprecated ``ANSIBLE_CALLBACK_WHITELIST`` configuration environment variable, use ``ANSIBLE_CALLBACKS_ENABLED`` instead. (https://github.com/ansible/ansible/issues/78821) -- Remove deprecated ``ANSIBLE_COW_WHITELIST`` configuration environment variable, use ``ANSIBLE_COW_ACCEPTLIST`` instead. (https://github.com/ansible/ansible/issues/78819) -- Remove deprecated ``callback_whitelist`` configuration option, use ``callbacks_enabled`` instead. (https://github.com/ansible/ansible/issues/78822) -- Remove deprecated ``cow_whitelist`` configuration option, use ``cowsay_enabled_stencils`` instead. (https://github.com/ansible/ansible/issues/78820) - -amazon.aws -~~~~~~~~~~ - -- ec2_vpc_endpoint_info - support for the ``query`` parameter was removed. The ``amazon.aws.ec2_vpc_endpoint_info`` module now only queries for endpoints. Services can be queried using the ``amazon.aws.ec2_vpc_endpoint_service_info`` module (https://github.com/ansible-collections/amazon.aws/pull/1308). -- s3_object - support for creating and deleting buckets using the ``s3_object`` module has been removed. S3 buckets can be created and deleted using the ``amazon.aws.s3_bucket`` module (https://github.com/ansible-collections/amazon.aws/issues/1112). - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- cli_parse - This plugin was moved to ansible.utils in version 1.0.0, and the redirect to that collection has now been removed. - -community.general -~~~~~~~~~~~~~~~~~ - -- All ``sap`` modules have been removed from this collection. - They have been migrated to the `community.sap_libs `_ collection. - Redirections have been provided. - Following modules are affected: - - sapcar_extract - - sap_task_list_execute - - hana_query -- cmd_runner module utils - the ``fmt`` alias of ``cmd_runner_fmt`` has been removed. Use ``cmd_runner_fmt`` instead (https://github.com/ansible-collections/community.general/pull/6428). -- newrelic_deployment - the ``appname`` and ``environment`` options have been removed. They did not do anything (https://github.com/ansible-collections/community.general/pull/6428). -- puppet - the alias ``show-diff`` of the ``show_diff`` option has been removed. Use ``show_diff`` instead (https://github.com/ansible-collections/community.general/pull/6428). -- xfconf - generating facts was deprecated in community.general 3.0.0, however three factoids, ``property``, ``channel`` and ``value`` continued to be generated by mistake. This behaviour has been removed and ``xfconf`` generate no facts whatsoever (https://github.com/ansible-collections/community.general/pull/5502). -- xfconf - generating facts was deprecated in community.general 3.0.0, however two factoids, ``previous_value`` and ``type`` continued to be generated by mistake. This behaviour has been removed and ``xfconf`` generate no facts whatsoever (https://github.com/ansible-collections/community.general/pull/5502). - -community.zabbix -~~~~~~~~~~~~~~~~ - -- agent role - removed support to configure firewall -- web role - removed installation of apache, debian, and php - -Deprecated Features -------------------- - -- The cisco.nso collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/155). -- The community.fortios collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/162). -- The community.google collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/160). -- The community.skydive collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/171). -- The netapp.aws collection is considered unmaintained and will be removed from Ansible 10 if no one starts maintaining it again before Ansible 10. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/223). - -Ansible-core -~~~~~~~~~~~~ - -- The ``ConnectionBase()._new_stdin`` attribute is deprecated, use ``display.prompt_until(msg)`` instead. -- ansible-test - The ``foreman`` test plugin is now deprecated. It will be removed in a future release. -- ansible-test - The ``govcsim`` simulator in the ``vcenter`` test plugin is now deprecated. It will be removed in a future release. Users should switch to providing their own test environment through a static configuration file. -- password_hash - deprecate using passlib.hash.hashtype if hashtype isn't in the list of documented choices. -- vars - Specifying a list of dictionaries for ``vars:`` is deprecated in favor of specifying a dictionary. - -amazon.aws -~~~~~~~~~~ - -- amazon.aws collection - due to the AWS SDKs Python support policies (https://aws.amazon.com/blogs/developer/python-support-policy-updates-for-aws-sdks-and-tools/) support for Python less than 3.8 by this collection is expected to be removed in a release after 2024-12-01 (https://github.com/ansible-collections/amazon.aws/pull/1342). -- amazon.aws collection - due to the AWS SDKs announcing the end of support for Python less than 3.7 (https://aws.amazon.com/blogs/developer/python-support-policy-updates-for-aws-sdks-and-tools/) support for Python less than 3.7 by this collection has been deprecated and will be removed in release 7.0.0. (https://github.com/ansible-collections/amazon.aws/pull/1342). -- amazon.aws lookup plugins - the ``boto3_profile`` alias for the ``profile`` option has been deprecated, please use ``profile`` instead (https://github.com/ansible-collections/amazon.aws/pull/1225). -- docs_fragments - ``amazon.aws.aws_credentials`` docs fragment has been deprecated please use ``amazon.aws.common.plugins`` instead (https://github.com/ansible-collections/amazon.aws/pull/1248). -- docs_fragments - ``amazon.aws.aws_region`` docs fragment has been deprecated please use ``amazon.aws.region.plugins`` instead (https://github.com/ansible-collections/amazon.aws/pull/1248). -- docs_fragments - ``amazon.aws.aws`` docs fragment has been deprecated please use ``amazon.aws.common.modules`` instead (https://github.com/ansible-collections/amazon.aws/pull/1248). -- docs_fragments - ``amazon.aws.ec2`` docs fragment has been deprecated please use ``amazon.aws.region.modules`` instead (https://github.com/ansible-collections/amazon.aws/pull/1248). -- module_utils.policy - ``ansible_collections.amazon.aws.module_utils.policy.sort_json_policy_dict`` has been deprecated consider using ``ansible_collections.amazon.aws.module_utils.poilcies.compare_policies`` instead (https://github.com/ansible-collections/amazon.aws/pull/1136). -- s3_object - Support for passing ``dualstack`` and ``endpoint_url`` at the same time has been deprecated, the ``dualstack`` parameter is ignored when ``endpoint_url`` is passed. Support will be removed in a release after 2024-12-01 (https://github.com/ansible-collections/amazon.aws/pull/1305). -- s3_object - Support for passing values of ``overwrite`` other than ``always``, ``never``, ``different`` or last ``last`` has been deprecated. Boolean values should be replaced by the strings ``always`` or ``never`` Support will be removed in a release after 2024-12-01 (https://github.com/ansible-collections/amazon.aws/pull/1305). -- s3_object_info - Support for passing ``dualstack`` and ``endpoint_url`` at the same time has been deprecated, the ``dualstack`` parameter is ignored when ``endpoint_url`` is passed. Support will be removed in a release after 2024-12-01 (https://github.com/ansible-collections/amazon.aws/pull/1305). -- support for passing both profile and security tokens through a mix of environment variables and parameters has been deprecated and support will be removed in release 6.0.0. After release 6.0.0 it will only be possible to pass either a profile or security tokens, regardless of mechanism used to pass them. To explicitly block a parameter coming from an environment variable pass an empty string as the parameter value. Support for passing profile and security tokens together was originally deprecated in release 1.2.0, however only partially implemented in release 5.0.0 (https://github.com/ansible-collections/amazon.aws/pull/1355). - -check_point.mgmt -~~~~~~~~~~~~~~~~ - -- add/set/delete nat-rule modules - will be replaced by the single cp_mgmt_nat_rule module. -- cp_mgmt_show_task/s modules - will be replaced by the by the single cp_mgmt_task_facts module. - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Deprecate side-by-side installs. - -cisco.ios -~~~~~~~~~ - -- ios_bgp_address_family - deprecate neighbors.address/tag/ipv6_adddress with neighbor_address which enables common attributes for facts rendering -- ios_bgp_address_family - deprecate neighbors.password with password_options which allows encryption and password -- ios_bgp_address_family - deprecate redistribute.ospf.match.external with redistribute.ospf.match.externals which enables attributes for OSPF type E1 and E2 routes -- ios_bgp_address_family - deprecate redistribute.ospf.match.nssa_external with redistribute.ospf.match.nssa_externals which enables attributes for OSPF type N1 and N2 routes -- ios_bgp_address_family - deprecate redistribute.ospf.match.type_1 with redistribute.ospf.match.nssa_externals.type_1 -- ios_bgp_address_family - deprecate redistribute.ospf.match.type_2 with redistribute.ospf.match.nssa_externals.type_2 -- ios_bgp_address_family - deprecate slow_peer with slow_peer_options which supports a dict attribute - -community.aws -~~~~~~~~~~~~~ - -- community.aws collection - due to the AWS SDKs Python support policies (https://aws.amazon.com/blogs/developer/python-support-policy-updates-for-aws-sdks-and-tools/) support for Python less than 3.8 by this collection is expected to be removed in a release after 2024-12-01 (https://github.com/ansible-collections/community.aws/pull/1743). -- community.aws collection - due to the AWS SDKs announcing the end of support for Python less than 3.7 (https://aws.amazon.com/blogs/developer/python-support-policy-updates-for-aws-sdks-and-tools/) support for Python less than 3.7 by this collection has been deprecated and will be removed in release 7.0.0. (https://github.com/ansible-collections/community.aws/pull/1743). -- ecs_service - In a release after 2024-06-01, tha default value of ``purge_placement_constraints`` will be change from ``false`` to ``true`` (https://github.com/ansible-collections/community.aws/pull/1716). -- ecs_service - In a release after 2024-06-01, tha default value of ``purge_placement_strategy`` will be change from ``false`` to ``true`` (https://github.com/ansible-collections/community.aws/pull/1716). -- iam_role - All top level return values other than ``iam_role`` and ``changed`` have been deprecated and will be removed in a release after 2023-12-01 (https://github.com/ansible-collections/community.aws/issues/551). -- iam_role - In a release after 2023-12-01 the contents of ``assume_role_policy_document`` will no longer be converted from CamelCase to snake_case. The ``assume_role_policy_document_raw`` return value already returns the policy document in this future format (https://github.com/ansible-collections/community.aws/issues/551). -- iam_role_info - In a release after 2023-12-01 the contents of ``assume_role_policy_document`` will no longer be converted from CamelCase to snake_case. The ``assume_role_policy_document_raw`` return value already returns the policy document in this future format (https://github.com/ansible-collections/community.aws/issues/551). - -community.crypto -~~~~~~~~~~~~~~~~ - -- x509_crl - the ``mode`` option is deprecated; use ``crl_mode`` instead. The ``mode`` option will change its meaning in community.crypto 3.0.0, and will refer to the CRL file's mode instead (https://github.com/ansible-collections/community.crypto/issues/596). - -community.dns -~~~~~~~~~~~~~ - -- The default of the newly added option ``txt_character_encoding`` will change from ``octal`` to ``decimal`` in community.dns 3.0.0. The new default will be compatible with `RFC 1035 `__ (https://github.com/ansible-collections/community.dns/pull/134). - -community.general -~~~~~~~~~~~~~~~~~ - -- ModuleHelper module_utils - ``deps`` mixin for MH classes deprecated in favour of using the ``deps`` module_utils (https://github.com/ansible-collections/community.general/pull/6465). -- consul - deprecate using parameters unused for ``state=absent`` (https://github.com/ansible-collections/community.general/pull/5772). -- gitlab_runner - the default of the new option ``access_level_on_creation`` will change from ``false`` to ``true`` in community.general 7.0.0. This will cause ``access_level`` to be used during runner registration as well, and not only during updates (https://github.com/ansible-collections/community.general/pull/5908). -- gitlab_runner - the option ``access_level`` will lose its default value in community.general 8.0.0. From that version on, you have set this option to ``ref_protected`` explicitly, if you want to have a protected runner (https://github.com/ansible-collections/community.general/issues/5925). -- manageiq_policies - deprecate ``state=list`` in favour of using ``community.general.manageiq_policies_info`` (https://github.com/ansible-collections/community.general/pull/5721). -- manageiq_tags - deprecate ``state=list`` in favour of using ``community.general.manageiq_tags_info`` (https://github.com/ansible-collections/community.general/pull/5727). -- rax - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax module utils - module utils code relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_cbs - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_cbs_attachments - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_cdb - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_cdb_database - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_cdb_user - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_clb - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_clb_nodes - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_clb_ssl - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_dns - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_dns_record - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_facts - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_files - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_files_objects - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_identity - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_keypair - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_meta - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_mon_alarm - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_mon_check - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_mon_entity - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_mon_notification - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_mon_notification_plan - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_network - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_queue - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_scaling_group - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rax_scaling_policy - module relies on deprecated library ``pyrax`` and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5752). -- rhn_channel, rhn_register - RHN hosted at redhat.com was discontinued years - ago, and Spacewalk 5 (which uses RHN) is EOL since 2020, May 31st; - while these modules could work on Uyuni / SUSE Manager (fork of Spacewalk 5), - we have not heard about anyone using them in those setups. Hence, these - modules are deprecated, and will be removed in community.general 10.0.0 - in case there are no reports about being still useful, and potentially - noone that steps up to maintain them - (https://github.com/ansible-collections/community.general/pull/6493). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- ansible-core - support for ``ansible-core`` versions ``2.11`` and ``2.12`` will be dropped in collection version ``5.0.0``, making ``2.13`` the minimum supported version of ``ansible-core`` (https://github.com/ansible-collections/community.hashi_vault/issues/340). -- hashi_vault lookup - in ``v5.0.0`` duplicate term string options will raise an exception instead of showing a warning (https://github.com/ansible-collections/community.hashi_vault/issues/356). -- hvac - the minimum version of ``hvac`` to be supported in collection version ``5.0.0`` will be at least ``1.0.2``; this minimum may be raised before ``5.0.0`` is released, so please subscribe to the linked issue and look out for new notices in the changelog (https://github.com/ansible-collections/community.hashi_vault/issues/324). - -purestorage.fusion -~~~~~~~~~~~~~~~~~~ - -- fusion_hw - hardware module is being removed as changing hardware type has never been supported by Pure Storage Fusion -- fusion_info - nigs subset is deprecated in favor of network_interface_groups and will be removed in the version 1.7.0 -- fusion_info - placements subset is deprecated in favor of placement_groups and will be removed in the version 1.7.0 -- fusion_pg - placement_engine option is deprecated because Fusion API does not longer support this parameter It will be removed in the version 2.0.0 -- fusion_se - parameters 'addresses', 'gateway' and 'network_interface_groups' are deprecated in favor of 'iscsi' and will be removed in version 2.0.0 -- fusion_tn - tenant networks are being replaced by storage endpoints ```fusion_se``` and Network Interface Groups ```fusion_nig``` diff --git a/docs/docsite/rst/porting_guides/porting_guide_base_2.10.rst b/docs/docsite/rst/porting_guides/porting_guide_base_2.10.rst deleted file mode 100644 index 275de7250ef..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_base_2.10.rst +++ /dev/null @@ -1,92 +0,0 @@ - -.. _porting_2.10_guide_base: - -******************************* -Ansible-base 2.10 Porting Guide -******************************* - -.. warning:: - - In preparation for the release of 2.10, many plugins and modules have migrated to Collections on `Ansible Galaxy `_. For the current development status of Collections and FAQ see `Ansible Collections Community Guide `_. We expect the 2.10 Porting Guide to change frequently up to the 2.10 release. Follow the conversations about collections on our various :ref:`communication` channels for the latest information on the status of the ``devel`` branch. - -This section discusses the behavioral changes between Ansible 2.9 and Ansible-base 2.10. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible-base. - -We suggest you read this page along with the `Ansible-base Changelog for 2.10 `_ to understand what updates you may need to make. - -Ansible-base is mainly of interest for developers and users who only want to use a small, controlled subset of the available collections. Regular users should install ansible. - -The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: - - -Playbook -======== - -* Fixed a bug on boolean keywords that made random strings return 'False', now they should return an error if they are not a proper boolean - Example: ``diff: yes-`` was returning ``False``. -* A new fact, ``ansible_processor_nproc`` reflects the number of vcpus - available to processes (falls back to the number of vcpus available to - the scheduler). - - -Command Line -============ - -* The ``ansible-galaxy login`` command has been removed, as the underlying API it used for GitHub auth is being shut down. Publishing roles or - collections to Galaxy through ``ansible-galaxy`` now requires that a Galaxy API token be passed to the CLI through a token file (default location - ``~/.ansible/galaxy_token``) or (insecurely) through the ``--token`` argument to ``ansible-galaxy``. - - -Deprecated -========== - -* Windows Server 2008 and 2008 R2 will no longer be supported or tested in the next Ansible release, see :ref:`windows_faq_server2008`. - - -Modules -======= - -.. warning:: - - Links on this page may not point to the most recent versions of modules. We will update them when we can. - -* Version 2.10.0 of ansible-base changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the mode change has been reverted in 2.10.1, and mode will now default to ``0o666 & ~umask`` as in previous versions of Ansible. -* If you changed any tasks to specify less restrictive permissions while using 2.10.0, those changes will be unnecessary (but will do no harm) in 2.10.1. -* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it. - -* ``dnf`` and ``yum`` - As of version 2.10.1, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task. - - -Noteworthy module changes -------------------------- - -* Ansible modules created with ``add_file_common_args=True`` added a number of undocumented arguments which were mostly there to ease implementing certain action plugins. The undocumented arguments ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode`` are now no longer added. Modules relying on these options to be added need to specify them by themselves. -* Ansible no longer looks for Python modules in the current working directory (typically the ``remote_user``'s home directory) when an Ansible module is run. This is to fix becoming an unprivileged user on OpenBSD and to mitigate any attack vector if the current working directory is writable by a malicious user. Install any Python modules needed to run the Ansible modules on the managed node in a system-wide location or in another directory which is in the ``remote_user``'s ``$PYTHONPATH`` and readable by the ``become_user``. - - -Plugins -======= - -Lookup plugin names case-sensitivity ------------------------------------- - -* Prior to Ansible ``2.10`` lookup plugin names passed in as an argument to the ``lookup()`` function were treated as case-insensitive as opposed to lookups invoked through ``with_``. ``2.10`` brings consistency to ``lookup()`` and ``with_`` to be both case-sensitive. - -Noteworthy plugin changes -------------------------- - -* Cache plugins in collections can be used to cache data from inventory plugins. Previously, cache plugins in collections could only be used for fact caching. -* Some undocumented arguments from ``FILE_COMMON_ARGUMENTS`` have been removed; plugins using these, in particular action plugins, need to be adjusted. The undocumented arguments which were removed are ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode``. - -Action plugins which execute modules should use fully-qualified module names ----------------------------------------------------------------------------- - -* Action plugins that call modules should pass explicit, fully-qualified module names to ``_execute_module()`` whenever possible (eg, ``ansible.builtin.file`` rather than ``file``). This ensures that the task's collection search order is not consulted to resolve the module. Otherwise, a module from a collection earlier in the search path could be used when not intended. - -Porting custom scripts -====================== - -No notable changes diff --git a/docs/docsite/rst/porting_guides/porting_guide_core_2.11.rst b/docs/docsite/rst/porting_guides/porting_guide_core_2.11.rst deleted file mode 100644 index e55482e53ad..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_core_2.11.rst +++ /dev/null @@ -1,136 +0,0 @@ - -.. _porting_2.11_guide_core: - -******************************* -Ansible-core 2.11 Porting Guide -******************************* - -This section discusses the behavioral changes between ``ansible-base`` 2.10 and ``ansible-core`` 2.11. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they work with this version of ``ansible-core``. - -We suggest you read this page along with the `ansible-core Changelog for 2.11 `_ to understand what updates you may need to make. - -``ansible-core`` is mainly of interest for developers and users who only want to use a small, controlled subset of the available collections. Regular users should install Ansible. - -The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: - -Playbook -======== - -* The ``jinja2_native`` setting now does not affect the template module which implicitly returns strings. For the template lookup there is a new argument ``jinja2_native`` (off by default) to control that functionality. The rest of the Jinja2 expressions still operate based on the ``jinja2_native`` setting. - - -Command Line -============ - -* The ``ansible-galaxy login`` command has been removed, as the underlying API it used for GitHub auth has been shut down. Publishing roles or collections to Galaxy with ``ansible-galaxy`` now requires that a Galaxy API token be passed to the CLI using a token file (default location ``~/.ansible/galaxy_token``) or (insecurely) with the ``--token`` argument to ``ansible-galaxy``. - - -Deprecated -========== - -The constant ``ansible.module_utils.basic._CHECK_ARGUMENT_TYPES_DISPATCHER`` is deprecated. Use :const:`ansible.module_utils.common.parameters.DEFAULT_TYPE_VALIDATORS` instead. - - -Breaking Changes -================ - -Changes to ``AnsibleModule`` ----------------------------- - -With the move to :class:`ArgumentSpecValidator ` for performing argument spec validation, the following private methods in :class:`AnsibleModule ` have been removed: - - - ``_check_argument_types()`` - - ``_check_argument_values()`` - - ``_check_arguments()`` - - ``_check_mutually_exclusive()`` --> :func:`ansible.module_utils.common.validation.check_mutually_exclusive` - - ``_check_required_arguments()`` --> :func:`ansible.module_utils.common.validation.check_required_arguments` - - ``_check_required_by()`` --> :func:`ansible.module_utils.common.validation.check_required_by` - - ``_check_required_if()`` --> :func:`ansible.module_utils.common.validation.check_required_if` - - ``_check_required_one_of()`` --> :func:`ansible.module_utils.common.validation.check_required_one_of` - - ``_check_required_together()`` --> :func:`ansible.module_utils.common.validation.check_required_together` - - ``_check_type_bits()`` --> :func:`ansible.module_utils.common.validation.check_type_bits` - - ``_check_type_bool()`` --> :func:`ansible.module_utils.common.validation.check_type_bool` - - ``_check_type_bytes()`` --> :func:`ansible.module_utils.common.validation.check_type_bytes` - - ``_check_type_dict()`` --> :func:`ansible.module_utils.common.validation.check_type_dict` - - ``_check_type_float()`` --> :func:`ansible.module_utils.common.validation.check_type_float` - - ``_check_type_int()`` --> :func:`ansible.module_utils.common.validation.check_type_int` - - ``_check_type_jsonarg()`` --> :func:`ansible.module_utils.common.validation.check_type_jsonarg` - - ``_check_type_list()`` --> :func:`ansible.module_utils.common.validation.check_type_list` - - ``_check_type_path()`` --> :func:`ansible.module_utils.common.validation.check_type_path` - - ``_check_type_raw()`` --> :func:`ansible.module_utils.common.validation.check_type_raw` - - ``_check_type_str()`` --> :func:`ansible.module_utils.common.validation.check_type_str` - - ``_count_terms()`` --> :func:`ansible.module_utils.common.validation.count_terms` - - ``_get_wanted_type()`` - - ``_handle_aliases()`` - - ``_handle_no_log_values()`` - - ``_handle_options()`` - - ``_set_defaults()`` - - ``_set_fallbacks()`` - -Modules or plugins using these private methods should use the public functions in :mod:`ansible.module_utils.common.validation` or :meth:`ArgumentSpecValidator.validate() ` if no public function was listed above. - - -Changes to :mod:`ansible.module_utils.common.parameters` --------------------------------------------------------- - -The following functions in :mod:`ansible.module_utils.common.parameters` are now private and should not be used directly. Use :meth:`ArgumentSpecValidator.validate() ` instead. - - - ``list_no_log_values`` - - ``list_deprecations`` - - ``handle_aliases`` - - -Other -====== - -* **Upgrading**: If upgrading from ``ansible < 2.10`` or from ``ansible-base`` and using pip, you must ``pip uninstall ansible`` or ``pip uninstall ansible-base`` before installing ``ansible-core`` to avoid conflicts. -* Python 3.8 on the controller node is a soft requirement for this release. ``ansible-core`` 2.11 still works with the same versions of Python that ``ansible-base`` 2.10 worked with, however 2.11 emits a warning when running on a controller node with a Python version less than 3.8. This warning can be disabled by setting ``ANSIBLE_CONTROLLER_PYTHON_WARNING=False`` in your environment. ``ansible-core`` 2.12 will require Python 3.8 or greater. -* The configuration system now validates the ``choices`` field, so any settings that violate it and were ignored in 2.10 cause an error in 2.11. For example, ``ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH=0`` now causes an error (valid choices are ``ignore``, ``warn`` or ``error``). -* The ``ansible-galaxy`` command now uses ``resolvelib`` for resolving dependencies. In most cases this should not make a user-facing difference beyond being more performant, but we note it here for posterity and completeness. -* If you import Python ``module_utils`` into any modules you maintain, you may now mark the import as optional during the module payload build by wrapping the ``import`` statement in a ``try`` or ``if`` block. This allows modules to use ``module_utils`` that may not be present in all versions of Ansible or a collection, and to perform arbitrary recovery or fallback actions during module runtime. - - -Modules -======= - -* The ``apt_key`` module has explicitly defined ``file`` as mutually exclusive with ``data``, ``keyserver`` and ``url``. They cannot be used together anymore. -* The ``meta`` module now supports tags for user-defined tasks. Set the task's tags to 'always' to maintain the previous behavior. Internal ``meta`` tasks continue to always run. - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -* facts - On NetBSD, ``ansible_virtualization_type`` now tries to report a more accurate result than ``xen`` when virtualized and not running on Xen. -* facts - Virtualization facts now include ``virtualization_tech_guest`` and ``virtualization_tech_host`` keys. These are lists of virtualization technologies that a guest is a part of, or that a host provides, respectively. As an example, if you set up a host to provide both KVM and VirtualBox, both values are included in ``virtualization_tech_host``. Similarly, a podman container running on a VM powered by KVM has a ``virtualization_tech_guest`` of ``["kvm", "podman", "container"]``. -* The parameter ``filter`` type is changed from ``string`` to ``list`` in the :ref:`setup ` module in order to use more than one filter. Previous behavior (using a ``string``) still remains and works as a single filter. - - -Plugins -======= - -* inventory plugins - ``CachePluginAdjudicator.flush()`` now calls the underlying cache plugin's ``flush()`` instead of only deleting keys that it knows about. Inventory plugins should use ``delete()`` to remove any specific keys. As a user, this means that when an inventory plugin calls its ``clear_cache()`` method, facts could also be flushed from the cache. To work around this, users can configure inventory plugins to use a cache backend that is independent of the facts cache. -* callback plugins - ``meta`` task execution is now sent to ``v2_playbook_on_task_start`` like any other task. By default, only explicit meta tasks are sent there. Callback plugins can opt-in to receiving internal, implicitly created tasks to act on those as well, as noted in the plugin development documentation. -* The ``choices`` are now validated, so plugins that were using incorrect or incomplete choices issue an error in 2.11 if the value provided does not match. This has a simple fix: update the entries in ``choices`` to match reality. - -Porting custom scripts -====================== - -No notable changes diff --git a/docs/docsite/rst/porting_guides/porting_guide_core_2.12.rst b/docs/docsite/rst/porting_guides/porting_guide_core_2.12.rst deleted file mode 100644 index 4e33e84247f..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_core_2.12.rst +++ /dev/null @@ -1,126 +0,0 @@ - -.. _porting_2.12_guide_core: - -******************************* -Ansible-core 2.12 Porting Guide -******************************* - -This section discusses the behavioral changes between ``ansible-core`` 2.11 and ``ansible-core`` 2.12. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `ansible-core Changelog for 2.12 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - - -Playbook -======== - -* When calling tasks and setting ``async``, setting ``ANSIBLE_ASYNC_DIR`` under ``environment:`` is no longer valid. Instead, use the shell configuration variable ``async_dir``, for example by setting ``ansible_async_dir``: - -.. code-block:: yaml - - tasks: - - dnf: - name: '*' - state: latest - async: 300 - poll: 5 - vars: - ansible_async_dir: /path/to/my/custom/dir - -* The ``undef()`` function is added to the templating environment for creating undefined variables directly in a template. Optionally, a hint may be provided for variables which are intended to be overridden. - -.. code-block:: yaml - - vars: - old: "{{ undef }}" - new: "{{ undef() }}" - new_with_hint: "{{ undef(hint='You must override this variable') }}" - -Python Interpreter Discovery -============================ - -The default value of ``INTERPRETER_PYTHON`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``. - -``INTERPRETER_PYTHON_FALLBACK`` can be changed from the default list of interpreters by setting the ``ansible_interpreter_python_fallback`` variable. - -See :ref:`interpreter discovery documentation ` for more details. - - -Command Line -============ - -* Python 3.8 on the controller node is a hard requirement for this release. The command line scripts will not function with a lower Python version. -* ``ansible-vault`` no longer supports ``PyCrypto`` and requires ``cryptography``. - -Deprecated -========== - -* Python 2.6 on the target node is deprecated in this release. ``ansible-core`` 2.13 will remove support for Python 2.6. -* Bare variables in conditionals: ``when`` conditionals no longer automatically parse string booleans such as ``"true"`` and ``"false"`` into actual booleans. Any variable containing a non-empty string is considered true. This was previously configurable with the ``CONDITIONAL_BARE_VARS`` configuration option (and the ``ANSIBLE_CONDITIONAL_BARE_VARS`` environment variable). This setting no longer has any effect. Users can work around the issue by using the ``|bool`` filter: - -.. code-block:: yaml - - vars: - teardown: 'false' - - tasks: - - include_tasks: teardown.yml - when: teardown | bool - - - include_tasks: provision.yml - when: not teardown | bool - -* The ``_remote_checksum()`` method in ``ActionBase`` is deprecated. Any action plugin using this method should use ``_execute_remote_stat()`` instead. - -Modules -======= - -* ``cron`` now requires ``name`` to be specified in all cases. -* ``cron`` no longer allows a ``reboot`` parameter. Use ``special_time: reboot`` instead. -* ``hostname`` - On FreeBSD, the ``before`` result will no longer be ``"temporarystub"`` if permanent hostname file does not exist. It will instead be ``""`` (empty string) for consistency with other systems. -* ``hostname`` - On OpenRC and Solaris based systems, the ``before`` result will no longer be ``"UNKNOWN"`` if the permanent hostname file does not exist. It will instead be ``""`` (empty string) for consistency with other systems. -* ``pip`` now uses the ``pip`` Python module installed for the Ansible module's Python interpreter, if available, unless ``executable`` or ``virtualenv`` were specified. - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Plugins -======= - -* ``unique`` filter with Jinja2 < 2.10 is case-sensitive and now raise coherently an error if ``case_sensitive=False`` instead of when ``case_sensitive=True``. -* Set theory filters (``intersect``, ``difference``, ``symmetric_difference`` and ``union``) are now case-sensitive. Explicitly use ``case_sensitive=False`` to keep previous behavior. Note: with Jinja2 < 2.10, the filters were already case-sensitive by default. -* ``password_hash``` now uses ``passlib`` defaults when an option is unspecified, for example ``bcrypt_sha256`` now default to the "2b" format and if the "2a" format is required it must be specified. - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes diff --git a/docs/docsite/rst/porting_guides/porting_guide_core_2.13.rst b/docs/docsite/rst/porting_guides/porting_guide_core_2.13.rst deleted file mode 100644 index a60b3b2cfde..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_core_2.13.rst +++ /dev/null @@ -1,98 +0,0 @@ - -.. _porting_2.13_guide_core: - -******************************* -Ansible-core 2.13 Porting Guide -******************************* - -This section discusses the behavioral changes between ``ansible-core`` 2.12 and ``ansible-core`` 2.13. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `ansible-core Changelog for 2.13 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - - -Playbook -======== - -* Templating - You can no longer perform arithmetic and concatenation operations outside of the jinja template. The following statement will need to be rewritten to produce ``[1, 2]``: - - .. code-block:: yaml - - - name: Prior to 2.13 - debug: - msg: '[1] + {{ [2] }}' - - - name: 2.13 and forward - debug: - msg: '{{ [1] + [2] }}' - -* The return value of the ``__repr__`` method of an undefined variable represented by the ``AnsibleUndefined`` object changed. ``{{ '%r'|format(undefined_variable) }}`` returns ``AnsibleUndefined(hint=None, obj=missing, name='undefined_variable')`` in 2.13 as opposed to just ``AnsibleUndefined`` in versions 2.12 and prior. - -* The ``finalize`` method is no longer exposed in the globals for use in templating. To convert ``None`` to an empty string the following expression can be used: ``{{ value if value is not none }}``. - - -Command Line -============ - -No notable changes - - -Deprecated -========== - -No notable changes - - -Modules -======= - -* To use ansible-core 2.13 for module execution, you must use Python 2 version 2.7 or Python 3 version 3.5 or newer. Any code utilizing ``ansible.module_utils.basic`` will not function with lower Python versions. - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Breaking Changes ----------------- - -* ``ansible.module_utils.urls.fetch_url`` will now return the captured ``HTTPError`` exception as ``r``. ``HTTPError`` is a response like object that can offer more information to module authors. Modules should rely on ``info['status'] >= 400`` to determine if there was a failure, instead of using ``r is None`` or catching ``AttributeError`` when attempting ``r.read()``. - - -Plugins -======= - -No notable changes - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes diff --git a/docs/docsite/rst/porting_guides/porting_guide_core_2.14.rst b/docs/docsite/rst/porting_guides/porting_guide_core_2.14.rst deleted file mode 100644 index c1325f74b83..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_core_2.14.rst +++ /dev/null @@ -1,91 +0,0 @@ - -.. _porting_2.14_guide_core: - -******************************* -Ansible-core 2.14 Porting Guide -******************************* - -This section discusses the behavioral changes between ``ansible-core`` 2.13 and ``ansible-core`` 2.14. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `ansible-core Changelog for 2.14 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - - -Playbook -======== - -* Variables are now evaluated lazily; only when they are actually used. For example, in ansible-core 2.14 an expression ``{{ defined_variable or undefined_variable }}`` does not fail on ``undefined_variable`` if the first part of ``or`` is evaluated to ``True`` as it is not needed to evaluate the second part. One particular case of a change in behavior to note is the task below which uses the ``undefined`` test. Prior to version 2.14 this would result in a fatal error trying to access the undefined value in the dictionary. In 2.14 the assertion passes as the dictionary is evaluated as undefined through one of its undefined values: - - .. code-block:: yaml - - - assert: - that: - - some_defined_dict_with_undefined_values is undefined - vars: - dict_value: 1 - some_defined_dict_with_undefined_values: - key1: value1 - key2: '{{ dict_value }}' - key3: '{{ undefined_dict_value }}' - - -Command Line -============ - -* Python 3.9 on the controller node is a hard requirement for this release. -* At startup the filesystem encoding and locale are checked to verify they are UTF-8. If not, the process exits with an error reporting the errant encoding. If you were previously using the ``C`` or ``POSIX`` locale, you may be able to use ``C.UTF-8``. If you were previously using a locale such as ``en_US.ISO-8859-1``, you may be able to use ``en_US.UTF-8``. For simplicity it may be easiest to export the appropriate locale using the ``LC_ALL`` environment variable. An alternative to modifying your system locale is to run Python in UTF-8 mode; See the `Python documentation `_ for more information. - - -Deprecated -========== - -No notable changes - - -Modules -======= - -No notable changes - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Plugins -======= - -No notable changes - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes diff --git a/docs/docsite/rst/porting_guides/porting_guide_core_2.15.rst b/docs/docsite/rst/porting_guides/porting_guide_core_2.15.rst deleted file mode 100644 index 8b4478cd1e4..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_core_2.15.rst +++ /dev/null @@ -1,93 +0,0 @@ - -.. _porting_2.15_guide_core: - -******************************* -Ansible-core 2.15 Porting Guide -******************************* - -This section discusses the behavioral changes between ``ansible-core`` 2.14 and ``ansible-core`` 2.15. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `ansible-core Changelog for 2.15 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - - -Playbook -======== - -No notable changes - - -Command Line -============ - -* The return code of ``ansible-galaxy search`` is now 0 instead of 1 and the stdout is empty when results are empty to align with other ``ansible-galaxy`` commands. - - -Deprecated -========== - -* Providing a list of dictionaries to ``vars:`` is deprecated in favor of supplying a dictionary. - - Instead of: - - .. code-block:: yaml - - vars: - - var1: foo - - var2: bar - - Use: - - .. code-block:: yaml - - vars: - var1: foo - var2: bar - -Modules -======= - -No notable changes - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Plugins -======= - -No notable changes - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes diff --git a/docs/docsite/rst/porting_guides/porting_guide_core_2.16.rst b/docs/docsite/rst/porting_guides/porting_guide_core_2.16.rst deleted file mode 100644 index de2b1d63bc3..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_core_2.16.rst +++ /dev/null @@ -1,63 +0,0 @@ - -.. _porting_2.16_guide_core: - -******************************* -Ansible-core 2.16 Porting Guide -******************************* - -This section discusses the behavioral changes between ``ansible-core`` 2.15 and ``ansible-core`` 2.16. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `ansible-core Changelog for 2.16 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - - -Playbook -======== - - -Command Line -============ - - -Deprecated -========== - - -Modules -======= - - - -Modules removed ---------------- - - - -Deprecation notices -------------------- - - - -Noteworthy module changes -------------------------- - - - -Plugins -======= - - - -Porting custom scripts -====================== - - - -Networking -========== - diff --git a/docs/docsite/rst/porting_guides/porting_guides.rst b/docs/docsite/rst/porting_guides/porting_guides.rst deleted file mode 100644 index b97303d0673..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guides.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. _porting_guides: - -********************** -Ansible Porting Guides -********************** - -This section lists porting guides that can help you in updating playbooks, plugins and other parts of your Ansible infrastructure from one version of Ansible to the next. - -.. toctree:: - :maxdepth: 1 - :glob: - - porting_guide_8 - porting_guide_7 - porting_guide_6 - porting_guide_5 - porting_guide_4 - porting_guide_3 - porting_guide_2.10 - porting_guide_2.9 - porting_guide_2.8 - porting_guide_2.7 - porting_guide_2.6 - porting_guide_2.5 - porting_guide_2.4 - porting_guide_2.3 - porting_guide_2.0 diff --git a/docs/docsite/rst/reference_appendices/.rstcheck.cfg b/docs/docsite/rst/reference_appendices/.rstcheck.cfg deleted file mode 100644 index 5b33c0765eb..00000000000 --- a/docs/docsite/rst/reference_appendices/.rstcheck.cfg +++ /dev/null @@ -1,2 +0,0 @@ -[rstcheck] -ignore_directives=autoclass,automodule diff --git a/docs/docsite/rst/reference_appendices/YAMLSyntax.rst b/docs/docsite/rst/reference_appendices/YAMLSyntax.rst deleted file mode 100644 index 13f08ef4c2c..00000000000 --- a/docs/docsite/rst/reference_appendices/YAMLSyntax.rst +++ /dev/null @@ -1,285 +0,0 @@ -.. _yaml_syntax: - - -YAML Syntax -=========== - -This page provides a basic overview of correct YAML syntax, which is how Ansible -playbooks (our configuration management language) are expressed. - -We use YAML because it is easier for humans to read and write than other common -data formats like XML or JSON. Further, there are libraries available in most -programming languages for working with YAML. - -You may also wish to read :ref:`working_with_playbooks` at the same time to see how this -is used in practice. - - -YAML Basics ------------ - -For Ansible, nearly every YAML file starts with a list. -Each item in the list is a list of key/value pairs, commonly -called a "hash" or a "dictionary". So, we need to know how -to write lists and dictionaries in YAML. - -There's another small quirk to YAML. All YAML files (regardless of their association with Ansible or not) can optionally -begin with ``---`` and end with ``...``. This is part of the YAML format and indicates the start and end of a document. - -All members of a list are lines beginning at the same indentation level starting with a ``"- "`` (a dash and a space): - -.. code:: yaml - - --- - # A list of tasty fruits - - Apple - - Orange - - Strawberry - - Mango - ... - -A dictionary is represented in a simple ``key: value`` form (the colon must be followed by a space): - -.. code:: yaml - - # An employee record - martin: - name: Martin D'vloper - job: Developer - skill: Elite - -More complicated data structures are possible, such as lists of dictionaries, dictionaries whose values are lists or a mix of both: - -.. code:: yaml - - # Employee records - - martin: - name: Martin D'vloper - job: Developer - skills: - - python - - perl - - pascal - - tabitha: - name: Tabitha Bitumen - job: Developer - skills: - - lisp - - fortran - - erlang - -Dictionaries and lists can also be represented in an abbreviated form if you really want to: - -.. code:: yaml - - --- - martin: {name: Martin D'vloper, job: Developer, skill: Elite} - fruits: ['Apple', 'Orange', 'Strawberry', 'Mango'] - -These are called "Flow collections". - -.. _truthiness: - -Ansible doesn't really use these too much, but you can also specify a :ref:`boolean value ` (true/false) in several forms: - -.. code:: yaml - - create_key: true - needs_agent: false - knows_oop: True - likes_emacs: TRUE - uses_cvs: false - -Use lowercase 'true' or 'false' for boolean values in dictionaries if you want to be compatible with default yamllint options. - -Values can span multiple lines using ``|`` or ``>``. Spanning multiple lines using a "Literal Block Scalar" ``|`` will include the newlines and any trailing spaces. -Using a "Folded Block Scalar" ``>`` will fold newlines to spaces; it's used to make what would otherwise be a very long line easier to read and edit. -In either case the indentation will be ignored. -Examples are: - -.. code:: yaml - - include_newlines: | - exactly as you see - will appear these three - lines of poetry - - fold_newlines: > - this is really a - single line of text - despite appearances - -While in the above ``>`` example all newlines are folded into spaces, there are two ways to enforce a newline to be kept: - -.. code:: yaml - - fold_some_newlines: > - a - b - - c - d - e - f - -Alternatively, it can be enforced by including newline ``\n`` characters: - -.. code:: yaml - - fold_same_newlines: "a b\nc d\n e\nf\n" - -Let's combine what we learned so far in an arbitrary YAML example. -This really has nothing to do with Ansible, but will give you a feel for the format: - -.. code:: yaml - - --- - # An employee record - name: Martin D'vloper - job: Developer - skill: Elite - employed: True - foods: - - Apple - - Orange - - Strawberry - - Mango - languages: - perl: Elite - python: Elite - pascal: Lame - education: | - 4 GCSEs - 3 A-Levels - BSc in the Internet of Things - -That's all you really need to know about YAML to start writing `Ansible` playbooks. - -Gotchas -------- - -While you can put just about anything into an unquoted scalar, there are some exceptions. -A colon followed by a space (or newline) ``": "`` is an indicator for a mapping. -A space followed by the pound sign ``" #"`` starts a comment. - -Because of this, the following is going to result in a YAML syntax error: - -.. code:: text - - foo: somebody said I should put a colon here: so I did - - windows_drive: c: - -...but this will work: - -.. code:: yaml - - windows_path: c:\windows - -You will want to quote hash values using colons followed by a space or the end of the line: - -.. code:: yaml - - foo: 'somebody said I should put a colon here: so I did' - - windows_drive: 'c:' - -...and then the colon will be preserved. - -Alternatively, you can use double quotes: - -.. code:: yaml - - foo: "somebody said I should put a colon here: so I did" - - windows_drive: "c:" - -The difference between single quotes and double quotes is that in double quotes -you can use escapes: - -.. code:: yaml - - foo: "a \t TAB and a \n NEWLINE" - -The list of allowed escapes can be found in the YAML Specification under "Escape Sequences" (YAML 1.1) or "Escape Characters" (YAML 1.2). - -The following is invalid YAML: - -.. code-block:: text - - foo: "an escaped \' single quote" - - -Further, Ansible uses "{{ var }}" for variables. If a value after a colon starts -with a "{", YAML will think it is a dictionary, so you must quote it, like so: - -.. code:: yaml - - foo: "{{ variable }}" - -If your value starts with a quote the entire value must be quoted, not just part of it. Here are some additional examples of how to properly quote things: - -.. code:: yaml - - foo: "{{ variable }}/additional/string/literal" - foo2: "{{ variable }}\\backslashes\\are\\also\\special\\characters" - foo3: "even if it's just a string literal it must all be quoted" - -Not valid: - -.. code:: text - - foo: "E:\\path\\"rest\\of\\path - -In addition to ``'`` and ``"`` there are a number of characters that are special (or reserved) and cannot be used -as the first character of an unquoted scalar: ``[] {} > | * & ! % # ` @ ,``. - -You should also be aware of ``? : -``. In YAML, they are allowed at the beginning of a string if a non-space -character follows, but YAML processor implementations differ, so it's better to use quotes. - -In Flow Collections, the rules are a bit more strict: - -.. code:: text - - a scalar in block mapping: this } is [ all , valid - - flow mapping: { key: "you { should [ use , quotes here" } - -Boolean conversion is helpful, but this can be a problem when you want a literal `yes` or other boolean values as a string. -In these cases just use quotes: - -.. code:: yaml - - non_boolean: "yes" - other_string: "False" - - -YAML converts certain strings into floating-point values, such as the string -`1.0`. If you need to specify a version number (in a requirements.yml file, for -example), you will need to quote the value if it looks like a floating-point -value: - -.. code:: yaml - - version: "1.0" - - -.. seealso:: - - :ref:`working_with_playbooks` - Learn what playbooks can do and how to write/run them. - `YAMLLint `_ - YAML Lint (online) helps you debug YAML syntax if you are having problems - `GitHub examples directory `_ - Complete playbook files from the github project source - `Wikipedia YAML syntax reference `_ - A good guide to YAML syntax - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels (join #yaml for yaml-specific questions) - `YAML 1.1 Specification `_ - The Specification for YAML 1.1, which PyYAML and libyaml are currently - implementing - `YAML 1.2 Specification `_ - For completeness, YAML 1.2 is the successor of 1.1 diff --git a/docs/docsite/rst/reference_appendices/automationhub.rst b/docs/docsite/rst/reference_appendices/automationhub.rst deleted file mode 100644 index 5ebedb5cba5..00000000000 --- a/docs/docsite/rst/reference_appendices/automationhub.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. _automation_hub: - -Ansible Automation Hub -====================== - -.. important:: - - Red Hat Ansible Automation Platform will soon be available on Microsoft Azure. `Sign up to preview the experience `_. - -`Ansible Automation Hub `_ is the official location to discover and download supported :ref:`collections `, included as part of an Ansible Automation Platform subscription. These content collections contain modules, plugins, roles, and playbooks in a downloadable package. - -Ansible Automation Hub gives you direct access to trusted content collections from Red Hat and Certified Partners. You can find content by topic or Ansible Partner organizations. - -Ansible Automation Hub is the downstream Red Hat supported product version of Ansible Galaxy. Find out more about Ansible Automation Hub features and how to access it at `Ansible Automation Hub `_. Ansible Automation Hub is part of the Red Hat Ansible Automation Platform subscription, and comes bundled with support from Red Hat, Inc. diff --git a/docs/docsite/rst/reference_appendices/common_return_values.rst b/docs/docsite/rst/reference_appendices/common_return_values.rst deleted file mode 100644 index 04f57ac3d6c..00000000000 --- a/docs/docsite/rst/reference_appendices/common_return_values.rst +++ /dev/null @@ -1,251 +0,0 @@ -.. _common_return_values: - -Return Values -------------- - -.. contents:: Topics - -Ansible modules normally return a data structure that can be registered into a variable, or seen directly when output by -the `ansible` program. Each module can optionally document its own unique return values (visible through ansible-doc and on the :ref:`main docsite`). - -This document covers return values common to all modules. - -.. note:: Some of these keys might be set by Ansible itself once it processes the module's return information. - - -Common -^^^^^^ - -backup_file -``````````` -For those modules that implement `backup=no|yes` when manipulating files, a path to the backup file created. - - .. code-block:: console - - "backup_file": "./foo.txt.32729.2020-07-30@06:24:19~" - - -changed -``````` -A boolean indicating if the task had to make changes to the target or delegated host. - - .. code-block:: console - - "changed": true - -diff -```` -Information on differences between the previous and current state. Often a dictionary with entries ``before`` and ``after``, which will then be formatted by the callback plugin to a diff view. - - .. code-block:: console - - "diff": [ - { - "after": "", - "after_header": "foo.txt (content)", - "before": "", - "before_header": "foo.txt (content)" - }, - { - "after_header": "foo.txt (file attributes)", - "before_header": "foo.txt (file attributes)" - } - -failed -`````` -A boolean that indicates if the task was failed or not. - - .. code-block:: console - - "failed": false - -invocation -`````````` -Information on how the module was invoked. - - .. code-block:: console - - "invocation": { - "module_args": { - "_original_basename": "foo.txt", - "attributes": null, - "backup": true, - "checksum": "da39a3ee5e6b4b0d3255bfef95601890afd80709", - "content": null, - "delimiter": null, - "dest": "./foo.txt", - "directory_mode": null, - "follow": false, - "force": true, - "group": null, - "local_follow": null, - "mode": "666", - "owner": null, - "regexp": null, - "remote_src": null, - "selevel": null, - "serole": null, - "setype": null, - "seuser": null, - "src": "/Users/foo/.ansible/tmp/ansible-tmp-1596115458.110205-105717464505158/source", - "unsafe_writes": null, - "validate": null - } - -msg -``` -A string with a generic message relayed to the user. - - .. code-block:: console - - "msg": "line added" - -rc -`` -Some modules execute command line utilities or are geared for executing commands directly (raw, shell, command, and so on), this field contains 'return code' of these utilities. - - .. code-block:: console - - "rc": 257 - -results -``````` -If this key exists, it indicates that a loop was present for the task and that it contains a list of the normal module 'result' per item. - - .. code-block:: console - - "results": [ - { - "ansible_loop_var": "item", - "backup": "foo.txt.83170.2020-07-30@07:03:05~", - "changed": true, - "diff": [ - { - "after": "", - "after_header": "foo.txt (content)", - "before": "", - "before_header": "foo.txt (content)" - }, - { - "after_header": "foo.txt (file attributes)", - "before_header": "foo.txt (file attributes)" - } - ], - "failed": false, - "invocation": { - "module_args": { - "attributes": null, - "backrefs": false, - "backup": true - } - }, - "item": "foo", - "msg": "line added" - }, - { - "ansible_loop_var": "item", - "backup": "foo.txt.83187.2020-07-30@07:03:05~", - "changed": true, - "diff": [ - { - "after": "", - "after_header": "foo.txt (content)", - "before": "", - "before_header": "foo.txt (content)" - }, - { - "after_header": "foo.txt (file attributes)", - "before_header": "foo.txt (file attributes)" - } - ], - "failed": false, - "invocation": { - "module_args": { - "attributes": null, - "backrefs": false, - "backup": true - } - }, - "item": "bar", - "msg": "line added" - } - ] - -skipped -``````` -A boolean that indicates if the task was skipped or not - - .. code-block:: console - - "skipped": true - -stderr -`````` -Some modules execute command line utilities or are geared for executing commands directly (raw, shell, command, and so on), this field contains the error output of these utilities. - - .. code-block:: console - - "stderr": "ls: foo: No such file or directory" - -stderr_lines -```````````` -When `stderr` is returned we also always provide this field which is a list of strings, one item per line from the original. - - .. code-block:: console - - "stderr_lines": [ - "ls: doesntexist: No such file or directory" - ] - -stdout -`````` -Some modules execute command line utilities or are geared for executing commands directly (raw, shell, command, and so on). This field contains the normal output of these utilities. - - .. code-block:: console - - "stdout": "foo!" - -stdout_lines -```````````` -When `stdout` is returned, Ansible always provides a list of strings, each containing one item per line from the original output. - - .. code-block:: console - - "stdout_lines": [ - "foo!" - ] - - -.. _internal_return_values: - -Internal use -^^^^^^^^^^^^ - -These keys can be added by modules but will be removed from registered variables; they are 'consumed' by Ansible itself. - -ansible_facts -````````````` -This key should contain a dictionary which will be appended to the facts assigned to the host. These will be directly accessible and don't require using a registered variable. - -exception -````````` -This key can contain traceback information caused by an exception in a module. It will only be displayed on high verbosity (-vvv). - -warnings -```````` -This key contains a list of strings that will be presented to the user. - -deprecations -```````````` -This key contains a list of dictionaries that will be presented to the user. Keys of the dictionaries are `msg` and `version`, values are string, value for the `version` key can be an empty string. - -.. seealso:: - - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - `GitHub modules directory `_ - Browse source of core and extras modules - `Mailing List `_ - Development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/reference_appendices/faq.rst b/docs/docsite/rst/reference_appendices/faq.rst deleted file mode 100644 index 49bf7453841..00000000000 --- a/docs/docsite/rst/reference_appendices/faq.rst +++ /dev/null @@ -1,949 +0,0 @@ -.. _ansible_faq: - -Frequently Asked Questions -========================== - -Here are some commonly asked questions and their answers. - -.. _collections_transition: - -Where did all the modules go? -+++++++++++++++++++++++++++++ - -In July, 2019, we announced that collections would be the `future of Ansible content delivery `_. A collection is a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. In Ansible 2.9 we added support for collections. In Ansible 2.10 we `extracted most modules from the main ansible/ansible repository `_ and placed them in :ref:`collections `. Collections may be maintained by the Ansible team, by the Ansible community, or by Ansible partners. The `ansible/ansible repository `_ now contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-core`` (it was briefly called ``ansible-base`` for version 2.10). - -* To learn more about using collections, see :ref:`collections`. -* To learn more about developing collections, see :ref:`developing_collections`. -* To learn more about contributing to existing collections, see the individual collection repository for guidelines, or see :ref:`contributing_maintained_collections` to contribute to one of the Ansible-maintained collections. - -.. _find_my_module: - -Where did this specific module go? -++++++++++++++++++++++++++++++++++ - -IF you are searching for a specific module, you can check the `runtime.yml `_ file, which lists the first destination for each module that we extracted from the main ansible/ansible repository. Some modules have moved again since then. You can also search on `Ansible Galaxy `_ or ask on one of our :ref:`chat channels `. - -.. _slow_install: - -How can I speed up Ansible on systems with slow disks? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Ansible may feel sluggish on systems with slow disks, such as Raspberry PI. See `Ansible might be running slow if libyaml is not available `_ for hints on how to improve this. - - - -.. _set_environment: - -How can I set the PATH or any other environment variable for a task or entire play? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Setting environment variables can be done with the `environment` keyword. It can be used at the task or other levels in the play. - -.. code-block:: yaml - - shell: - cmd: date - environment: - LANG=fr_FR.UTF-8 - -.. code-block:: yaml - - hosts: servers - environment: - PATH: "{{ ansible_env.PATH }}:/thingy/bin" - SOME: value - -.. note:: starting in 2.0.1 the setup task from ``gather_facts`` also inherits the environment directive from the play, you might need to use the ``|default`` filter to avoid errors if setting this at play level. - -.. _faq_setting_users_and_ports: - -How do I handle different machines needing different user accounts or ports to log in with? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Setting inventory variables in the inventory file is the easiest way. - -For instance, suppose these hosts have different usernames and ports: - -.. code-block:: ini - - [webservers] - asdf.example.com ansible_port=5000 ansible_user=alice - jkl.example.com ansible_port=5001 ansible_user=bob - -You can also dictate the connection type to be used, if you want: - -.. code-block:: ini - - [testcluster] - localhost ansible_connection=local - /path/to/chroot1 ansible_connection=chroot - foo.example.com ansible_connection=paramiko - -You may also wish to keep these in group variables instead, or file them in a group_vars/ file. -See the rest of the documentation for more information about how to organize variables. - -.. _use_ssh: - -How do I get ansible to reuse connections, enable Kerberized SSH, or have Ansible pay attention to my local SSH config file? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Switch your default connection type in the configuration file to ``ssh``, or use ``-c ssh`` to use -Native OpenSSH for connections instead of the python paramiko library. In Ansible 1.2.1 and later, ``ssh`` will be used -by default if OpenSSH is new enough to support ControlPersist as an option. - -Paramiko is great for starting out, but the OpenSSH type offers many advanced options. You will want to run Ansible -from a machine new enough to support ControlPersist, if you are using this connection type. You can still manage -older clients. If you are using RHEL 6, CentOS 6, SLES 10 or SLES 11 the version of OpenSSH is still a bit old, so -consider managing from a Fedora or openSUSE client even though you are managing older nodes, or just use paramiko. - -We keep paramiko as the default as if you are first installing Ansible on these enterprise operating systems, it offers a better experience for new users. - -.. _use_ssh_jump_hosts: - -How do I configure a jump host to access servers that I have no direct access to? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -You can set a ``ProxyCommand`` in the -``ansible_ssh_common_args`` inventory variable. Any arguments specified in -this variable are added to the sftp/scp/ssh command line when connecting -to the relevant host(s). Consider the following inventory group: - -.. code-block:: ini - - [gatewayed] - foo ansible_host=192.0.2.1 - bar ansible_host=192.0.2.2 - -You can create `group_vars/gatewayed.yml` with the following contents: - -.. code-block:: yaml - - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q user@gateway.example.com"' - -Ansible will append these arguments to the command line when trying to -connect to any hosts in the group ``gatewayed``. (These arguments are used -in addition to any ``ssh_args`` from ``ansible.cfg``, so you do not need to -repeat global ``ControlPersist`` settings in ``ansible_ssh_common_args``.) - -Note that ``ssh -W`` is available only with OpenSSH 5.4 or later. With -older versions, it's necessary to execute ``nc %h:%p`` or some equivalent -command on the bastion host. - -With earlier versions of Ansible, it was necessary to configure a -suitable ``ProxyCommand`` for one or more hosts in ``~/.ssh/config``, -or globally by setting ``ssh_args`` in ``ansible.cfg``. - -.. _ssh_serveraliveinterval: - -How do I get Ansible to notice a dead target in a timely manner? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -You can add ``-o ServerAliveInterval=NumberOfSeconds`` with the ``ssh_args`` parameter in `SSH connection plugin `_. Without this option, -SSH and therefore Ansible will wait until the TCP connection times out. Another solution is to add ``ServerAliveInterval`` -into your global SSH configuration. A good value for ``ServerAliveInterval`` is up to you to decide; keep in mind that -``ServerAliveCountMax=3`` is the SSH default so any value you set will be tripled before terminating the SSH session. - -.. _cloud_provider_performance: - -How do I speed up run of ansible for servers from cloud providers (EC2, openstack,.. )? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Don't try to manage a fleet of machines of a cloud provider from your laptop. -Rather connect to a management node inside this cloud provider first and run Ansible from there. - -.. _python_interpreters: - -How do I handle not having a Python interpreter at /usr/bin/python on a remote machine? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -While you can write Ansible modules in any language, most Ansible modules are written in Python, -including the ones central to letting Ansible work. - -By default, Ansible assumes it can find a :command:`/usr/bin/python` on your remote system that is -either Python2, version 2.6 or higher or Python3, 3.5 or higher. - -Setting the inventory variable ``ansible_python_interpreter`` on any host will tell Ansible to -auto-replace the Python interpreter with that value instead. Thus, you can point to any Python you -want on the system if :command:`/usr/bin/python` on your system does not point to a compatible -Python interpreter. - -Some platforms may only have Python 3 installed by default. If it is not installed as -:command:`/usr/bin/python`, you will need to configure the path to the interpreter through -``ansible_python_interpreter``. Although most core modules will work with Python 3, there may be some -special purpose ones which do not or you may encounter a bug in an edge case. As a temporary -workaround you can install Python 2 on the managed host and configure Ansible to use that Python through -``ansible_python_interpreter``. If there's no mention in the module's documentation that the module -requires Python 2, you can also report a bug on our `bug tracker -`_ so that the incompatibility can be fixed in a future release. - -Do not replace the shebang lines of your python modules. Ansible will do this for you automatically at deploy time. - -Also, this works for ANY interpreter, for example ruby: ``ansible_ruby_interpreter``, perl: ``ansible_perl_interpreter``, and so on, -so you can use this for custom modules written in any scripting language and control the interpreter location. - -Keep in mind that if you put ``env`` in your module shebang line (``#!/usr/bin/env ``), -this facility will be ignored so you will be at the mercy of the remote `$PATH`. - -.. _installation_faqs: - -How do I handle the package dependencies required by Ansible package dependencies during Ansible installation ? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -While installing Ansible, sometimes you may encounter errors such as `No package 'libffi' found` or `fatal error: Python.h: No such file or directory` -These errors are generally caused by the missing packages, which are dependencies of the packages required by Ansible. -For example, `libffi` package is dependency of `pynacl` and `paramiko` (Ansible -> paramiko -> pynacl -> libffi). - -In order to solve these kinds of dependency issues, you might need to install required packages using -the OS native package managers, such as `yum`, `dnf`, or `apt`, or as mentioned in the package installation guide. - -Refer to the documentation of the respective package for such dependencies and their installation methods. - -Common Platform Issues -++++++++++++++++++++++ - -What customer platforms does Red Hat support? ---------------------------------------------- - -A number of them! For a definitive list please see this `Knowledge Base article `_. - -Running in a virtualenv ------------------------ - -You can install Ansible into a virtualenv on the controller quite simply: - -.. code-block:: shell - - $ virtualenv ansible - $ source ./ansible/bin/activate - $ pip install ansible - -If you want to run under Python 3 instead of Python 2 you may want to change that slightly: - -.. code-block:: shell - - $ virtualenv -p python3 ansible - $ source ./ansible/bin/activate - $ pip install ansible - -If you need to use any libraries which are not available through pip (for instance, SELinux Python -bindings on systems such as Red Hat Enterprise Linux or Fedora that have SELinux enabled), then you -need to install them into the virtualenv. There are two methods: - -* When you create the virtualenv, specify ``--system-site-packages`` to make use of any libraries - installed in the system's Python: - - .. code-block:: shell - - $ virtualenv ansible --system-site-packages - -* Copy those files in manually from the system. For instance, for SELinux bindings you might do: - - .. code-block:: shell - - $ virtualenv ansible --system-site-packages - $ cp -r -v /usr/lib64/python3.*/site-packages/selinux/ ./py3-ansible/lib64/python3.*/site-packages/ - $ cp -v /usr/lib64/python3.*/site-packages/*selinux*.so ./py3-ansible/lib64/python3.*/site-packages/ - - -Running on macOS as a controller --------------------------------- - -When executing Ansible on a system with macOS as a controller machine one might encounter the following error: - - .. error:: - +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. - ERROR! A worker was found in a dead state - -In general the recommended workaround is to set the following environment variable in your shell: - - .. code-block:: shell - - $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES - - -.. _macos_as_a_target_faq: - -Running on macOS as a target ----------------------------- - -When managing a system with macOS Monterey 12, macOS Ventura -13 or above over SSH, the following error can occur: - - .. error:: - "eDSPermissionError" DS Error: -14120 (eDSPermissionError) - -This is a good indication that *Allow full disk access for remote users* has not been enabled. - -.. seealso:: - - For more details, check out `the official Apple user guide article - `_. - - -Running on BSD --------------- - -.. seealso:: :ref:`working_with_bsd` - - -Running on Solaris ------------------- - -By default, Solaris 10 and earlier run a non-POSIX shell which does not correctly expand the default -tmp directory Ansible uses ( :file:`~/.ansible/tmp`). If you see module failures on Solaris machines, this -is likely the problem. There are several workarounds: - -* You can set ``remote_tmp`` to a path that will expand correctly with the shell you are using - (see the plugin documentation for :ref:`C shell`, :ref:`fish shell`, - and :ref:`Powershell`). For example, in the ansible config file you can set: - - .. code-block:: ini - - remote_tmp=$HOME/.ansible/tmp - - In Ansible 2.5 and later, you can also set it per-host in inventory like this: - - .. code-block:: ini - - solaris1 ansible_remote_tmp=$HOME/.ansible/tmp - -* You can set :ref:`ansible_shell_executable` to the path to a POSIX compatible shell. For - instance, many Solaris hosts have a POSIX shell located at :file:`/usr/xpg4/bin/sh` so you can set - this in inventory like so: - - .. code-block:: ini - - solaris1 ansible_shell_executable=/usr/xpg4/bin/sh - - (bash, ksh, and zsh should also be POSIX compatible if you have any of those installed). - -Running on z/OS ---------------- - -There are a few common errors that one might run into when trying to execute Ansible on z/OS as a target. - -* Version 2.7.6 of python for z/OS will not work with Ansible because it represents strings internally as EBCDIC. - - To get around this limitation, download and install a later version of `python for z/OS `_ (2.7.13 or 3.6.1) that represents strings internally as ASCII. Version 2.7.13 is verified to work. - -* When ``pipelining = False`` in `/etc/ansible/ansible.cfg` then Ansible modules are transferred in binary mode through sftp however execution of python fails with - - .. error:: - SyntaxError: Non-UTF-8 code starting with \'\\x83\' in file /a/user1/.ansible/tmp/ansible-tmp-1548232945.35-274513842609025/AnsiballZ_stat.py on line 1, but no encoding declared; see https://python.org/dev/peps/pep-0263/ for details - - To fix it set ``pipelining = True`` in `/etc/ansible/ansible.cfg`. - -* Python interpret cannot be found in default location ``/usr/bin/python`` on target host. - - .. error:: - /usr/bin/python: EDC5129I No such file or directory - - To fix this set the path to the python installation in your inventory like so: - - .. code-block:: ini - - zos1 ansible_python_interpreter=/usr/lpp/python/python-2017-04-12-py27/python27/bin/python - -* Start of python fails with ``The module libpython2.7.so was not found.`` - - .. error:: - EE3501S The module libpython2.7.so was not found. - - On z/OS, you must execute python from gnu bash. If gnu bash is installed at ``/usr/lpp/bash``, you can fix this in your inventory by specifying an ``ansible_shell_executable``: - - .. code-block:: ini - - zos1 ansible_shell_executable=/usr/lpp/bash/bin/bash - - -Running under fakeroot ----------------------- - -Some issues arise as ``fakeroot`` does not create a full nor POSIX compliant system by default. -It is known that it will not correctly expand the default tmp directory Ansible uses (:file:`~/.ansible/tmp`). -If you see module failures, this is likely the problem. -The simple workaround is to set ``remote_tmp`` to a path that will expand correctly (see documentation of the shell plugin you are using for specifics). - -For example, in the ansible config file (or through environment variable) you can set: - -.. code-block:: ini - - remote_tmp=$HOME/.ansible/tmp - - - -.. _use_roles: - -What is the best way to make content reusable/redistributable? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -If you have not done so already, read all about "Roles" in the playbooks documentation. This helps you make playbook content -self-contained, and works well with things like git submodules for sharing content with others. - -If some of these plugin types look strange to you, see the API documentation for more details about ways Ansible can be extended. - -.. _configuration_file: - -Where does the configuration file live and what can I configure in it? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - - -See :ref:`intro_configuration`. - -.. _who_would_ever_want_to_disable_cowsay_but_ok_here_is_how: - -How do I disable cowsay? -++++++++++++++++++++++++ - -If cowsay is installed, Ansible takes it upon itself to make your day happier when running playbooks. If you decide -that you would like to work in a professional cow-free environment, you can either uninstall cowsay, set ``nocows=1`` -in ``ansible.cfg``, or set the :envvar:`ANSIBLE_NOCOWS` environment variable: - -.. code-block:: shell-session - - export ANSIBLE_NOCOWS=1 - -.. _browse_facts: - -How do I see a list of all of the ansible\_ variables? -++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Ansible by default gathers "facts" about the machines under management, and these facts can be accessed in playbooks -and in templates. To see a list of all of the facts that are available about a machine, you can run the ``setup`` module -as an ad hoc action: - -.. code-block:: shell-session - - ansible -m setup hostname - -This will print out a dictionary of all of the facts that are available for that particular host. You might want to pipe -the output to a pager.This does NOT include inventory variables or internal 'magic' variables. See the next question -if you need more than just 'facts'. - - -.. _browse_inventory_vars: - -How do I see all the inventory variables defined for my host? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -By running the following command, you can see inventory variables for a host: - -.. code-block:: shell-session - - ansible-inventory --list --yaml - - -.. _browse_host_vars: - -How do I see all the variables specific to my host? -+++++++++++++++++++++++++++++++++++++++++++++++++++ - -To see all host specific variables, which might include facts and other sources: - -.. code-block:: shell-session - - ansible -m debug -a "var=hostvars['hostname']" localhost - -Unless you are using a fact cache, you normally need to use a play that gathers facts first, for facts included in the task above. - - -.. _host_loops: - -How do I loop over a list of hosts in a group, inside of a template? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -A pretty common pattern is to iterate over a list of hosts inside of a host group, perhaps to populate a template configuration -file with a list of servers. To do this, you can just access the "$groups" dictionary in your template, like this: - -.. code-block:: jinja - - {% for host in groups['db_servers'] %} - {{ host }} - {% endfor %} - -If you need to access facts about these hosts, for instance, the IP address of each hostname, -you need to make sure that the facts have been populated. For example, make sure you have a play that talks to db_servers: - -.. code-block:: yaml - - - hosts: db_servers - tasks: - - debug: msg="doesn't matter what you do, just that they were talked to previously." - -Then you can use the facts inside your template, like this: - -.. code-block:: jinja - - {% for host in groups['db_servers'] %} - {{ hostvars[host]['ansible_eth0']['ipv4']['address'] }} - {% endfor %} - -.. _programatic_access_to_a_variable: - -How do I access a variable name programmatically? -+++++++++++++++++++++++++++++++++++++++++++++++++ - -An example may come up where we need to get the ipv4 address of an arbitrary interface, where the interface to be used may be supplied -through a role parameter or other input. Variable names can be built by adding strings together using "~", like so: - -.. code-block:: jinja - - {{ hostvars[inventory_hostname]['ansible_' ~ which_interface]['ipv4']['address'] }} - -The trick about going through hostvars is necessary because it's a dictionary of the entire namespace of variables. ``inventory_hostname`` -is a magic variable that indicates the current host you are looping over in the host loop. - -In the example above, if your interface names have dashes, you must replace them with underscores: - -.. code-block:: jinja - - {{ hostvars[inventory_hostname]['ansible_' ~ which_interface | replace('_', '-') ]['ipv4']['address'] }} - -Also see dynamic_variables_. - - -.. _access_group_variable: - -How do I access a group variable? -+++++++++++++++++++++++++++++++++ - -Technically, you don't, Ansible does not really use groups directly. Groups are labels for host selection and a way to bulk assign variables, -they are not a first class entity, Ansible only cares about Hosts and Tasks. - -That said, you could just access the variable by selecting a host that is part of that group, see first_host_in_a_group_ below for an example. - - -.. _first_host_in_a_group: - -How do I access a variable of the first host in a group? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -What happens if we want the ip address of the first webserver in the webservers group? Well, we can do that too. Note that if we -are using dynamic inventory, which host is the 'first' may not be consistent, so you wouldn't want to do this unless your inventory -is static and predictable. (If you are using AWX or the :ref:`Red Hat Ansible Automation Platform `, it will use database order, so this isn't a problem even if you are using cloud -based inventory scripts). - -Anyway, here's the trick: - -.. code-block:: jinja - - {{ hostvars[groups['webservers'][0]]['ansible_eth0']['ipv4']['address'] }} - -Notice how we're pulling out the hostname of the first machine of the webservers group. If you are doing this in a template, you -could use the Jinja2 '#set' directive to simplify this, or in a playbook, you could also use set_fact: - -.. code-block:: yaml+jinja - - - set_fact: headnode={{ groups['webservers'][0] }} - - - debug: msg={{ hostvars[headnode].ansible_eth0.ipv4.address }} - -Notice how we interchanged the bracket syntax for dots -- that can be done anywhere. - -.. _file_recursion: - -How do I copy files recursively onto a target host? -+++++++++++++++++++++++++++++++++++++++++++++++++++ - -The ``copy`` module has a recursive parameter. However, take a look at the ``synchronize`` module if you want to do something more efficient -for a large number of files. The ``synchronize`` module wraps rsync. See the module index for info on both of these modules. - -.. _shell_env: - -How do I access shell environment variables? -++++++++++++++++++++++++++++++++++++++++++++ - - -**On controller machine :** Access existing variables from controller use the ``env`` lookup plugin. -For example, to access the value of the HOME environment variable on the management machine: - -.. code-block:: yaml+jinja - - --- - # ... - vars: - local_home: "{{ lookup('env','HOME') }}" - - -**On target machines :** Environment variables are available through facts in the ``ansible_env`` variable: - -.. code-block:: jinja - - {{ ansible_env.HOME }} - -If you need to set environment variables for TASK execution, see :ref:`playbooks_environment` -in the :ref:`Advanced Playbooks ` section. -There are several ways to set environment variables on your target machines. You can use the -:ref:`template `, :ref:`replace `, or :ref:`lineinfile ` -modules to introduce environment variables into files. The exact files to edit vary depending on your OS -and distribution and local configuration. - -.. _user_passwords: - -How do I generate encrypted passwords for the user module? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Ansible ad hoc command is the easiest option: - -.. code-block:: shell-session - - ansible all -i localhost, -m debug -a "msg={{ 'mypassword' | password_hash('sha512', 'mysecretsalt') }}" - -The ``mkpasswd`` utility that is available on most Linux systems is also a great option: - -.. code-block:: shell-session - - mkpasswd --method=sha-512 - - -If this utility is not installed on your system (for example, you are using macOS) then you can still easily -generate these passwords using Python. First, ensure that the `Passlib `_ -password hashing library is installed: - -.. code-block:: shell-session - - pip install passlib - -Once the library is ready, SHA512 password values can then be generated as follows: - -.. code-block:: shell-session - - python -c "from passlib.hash import sha512_crypt; import getpass; print(sha512_crypt.using(rounds=5000).hash(getpass.getpass()))" - -Use the integrated :ref:`hash_filters` to generate a hashed version of a password. -You shouldn't put plaintext passwords in your playbook or host_vars; instead, use :ref:`playbooks_vault` to encrypt sensitive data. - -In OpenBSD, a similar option is available in the base system called ``encrypt (1)`` - -.. _dot_or_array_notation: - -Ansible allows dot notation and array notation for variables. Which notation should I use? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -The dot notation comes from Jinja and works fine for variables without special -characters. If your variable contains dots (.), colons (:), or dashes (-), if -a key begins and ends with two underscores, or if a key uses any of the known -public attributes, it is safer to use the array notation. See :ref:`playbooks_variables` -for a list of the known public attributes. - -.. code-block:: jinja - - item[0]['checksum:md5'] - item['section']['2.1'] - item['region']['Mid-Atlantic'] - It is {{ temperature['Celsius']['-3'] }} outside. - -Also array notation allows for dynamic variable composition, see dynamic_variables_. - -Another problem with 'dot notation' is that some keys can cause problems because they collide with attributes and methods of python dictionaries. - -* Example of incorrect syntax when ``item`` is a dictionary: - -.. code-block:: jinja - - item.update - -This variant causes a syntax error because ``update()`` is a Python method for dictionaries. - -* Example of correct syntax: - -.. code-block:: jinja - - item['update'] - - -.. _argsplat_unsafe: - -When is it unsafe to bulk-set task arguments from a variable? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - - -You can set all of a task's arguments from a dictionary-typed variable. This -technique can be useful in some dynamic execution scenarios. However, it -introduces a security risk. We do not recommend it, so Ansible issues a -warning when you do something like this: - -.. code-block:: yaml+jinja - - #... - vars: - usermod_args: - name: testuser - state: present - update_password: always - tasks: - - user: '{{ usermod_args }}' - -This particular example is safe. However, constructing tasks like this is -risky because the parameters and values passed to ``usermod_args`` could -be overwritten by malicious values in the ``host facts`` on a compromised -target machine. To mitigate this risk: - -* set bulk variables at a level of precedence greater than ``host facts`` in the order of precedence - found in :ref:`ansible_variable_precedence` (the example above is safe because play vars take - precedence over facts) -* disable the :ref:`inject_facts_as_vars` configuration setting to prevent fact values from colliding - with variables (this will also disable the original warning) - - -.. _commercial_support: - -Can I get training on Ansible? -++++++++++++++++++++++++++++++ - -Yes! See our `services page `_ for information on our services -and training offerings. Email `info@ansible.com `_ for further details. - -We also offer free web-based training classes on a regular basis. See our -`webinar page `_ for more info on upcoming webinars. - - -.. _web_interface: - -Is there a web interface / REST API / GUI? -++++++++++++++++++++++++++++++++++++++++++++ - -Yes! The open-source web interface is Ansible AWX. The supported Red Hat product that makes Ansible even more powerful and easy to use is :ref:`Red Hat Ansible Automation Platform `. - - -.. _keep_secret_data: - -How do I keep secret data in my playbook? -+++++++++++++++++++++++++++++++++++++++++ - -If you would like to keep secret data in your Ansible content and still share it publicly or keep things in source control, see :ref:`playbooks_vault`. - -If you have a task that you don't want to show the results or command given to it when using -v (verbose) mode, the following task or playbook attribute can be useful: - -.. code-block:: yaml+jinja - - - name: secret task - shell: /usr/bin/do_something --value={{ secret_value }} - no_log: True - -This can be used to keep verbose output but hide sensitive information from others who would otherwise like to be able to see the output. - -The ``no_log`` attribute can also apply to an entire play: - -.. code-block:: yaml - - - hosts: all - no_log: True - -Though this will make the play somewhat difficult to debug. It's recommended that this -be applied to single tasks only, once a playbook is completed. Note that the use of the -``no_log`` attribute does not prevent data from being shown when debugging Ansible itself through -the :envvar:`ANSIBLE_DEBUG` environment variable. - - -.. _when_to_use_brackets: -.. _dynamic_variables: -.. _interpolate_variables: - -When should I use {{ }}? Also, how to interpolate variables or dynamic variable names -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -A steadfast rule is 'always use ``{{ }}`` except when ``when:``'. -Conditionals are always run through Jinja2 as to resolve the expression, -so ``when:``, ``failed_when:`` and ``changed_when:`` are always templated and you should avoid adding ``{{ }}``. - -In most other cases you should always use the brackets, even if previously you could use variables without -specifying (like ``loop`` or ``with_`` clauses), as this made it hard to distinguish between an undefined variable and a string. - -Another rule is 'moustaches don't stack'. We often see this: - -.. code-block:: jinja - - {{ somevar_{{other_var}} }} - -The above DOES NOT WORK as you expect, if you need to use a dynamic variable use the following as appropriate: - -.. code-block:: jinja - - {{ hostvars[inventory_hostname]['somevar_' ~ other_var] }} - -For 'non host vars' you can use the :ref:`vars lookup` plugin: - -.. code-block:: jinja - - {{ lookup('vars', 'somevar_' ~ other_var) }} - -To determine if a keyword requires ``{{ }}`` or even supports templating, use ``ansible-doc -t keyword ``, -this will return documentation on the keyword including a ``template`` field with the values ``explicit`` (requires ``{{ }}``), -``implicit`` (assumes ``{{ }}``, so no needed) or ``static`` (no templating supported, all characters will be interpreted literally) - -.. _ansible_host_delegated: - -How do I get the original ansible_host when I delegate a task? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -As the documentation states, connection variables are taken from the ``delegate_to`` host so ``ansible_host`` is overwritten, -but you can still access the original through ``hostvars``: - -.. code-block:: yaml+jinja - - original_host: "{{ hostvars[inventory_hostname]['ansible_host'] }}" - -This works for all overridden connection variables, like ``ansible_user``, ``ansible_port``, and so on. - - -.. _scp_protocol_error_filename: - -How do I fix 'protocol error: filename does not match request' when fetching a file? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Since release ``7.9p1`` of OpenSSH there is a `bug `_ -in the SCP client that can trigger this error on the Ansible controller when using SCP as the file transfer mechanism: - -.. error:: - - failed to transfer file to /tmp/ansible/file.txt\r\nprotocol error: filename does not match request - -In these releases, SCP tries to validate that the path of the file to fetch matches the requested path. -The validation -fails if the remote filename requires quotes to escape spaces or non-ascii characters in its path. To avoid this error: - -* Use SFTP instead of SCP by setting ``scp_if_ssh`` to ``smart`` (which tries SFTP first) or to ``False``. You can do this in one of four ways: - * Rely on the default setting, which is ``smart`` - this works if ``scp_if_ssh`` is not explicitly set anywhere - * Set a :ref:`host variable ` or :ref:`group variable ` in inventory: ``ansible_scp_if_ssh: False`` - * Set an environment variable on your control node: ``export ANSIBLE_SCP_IF_SSH=False`` - * Pass an environment variable when you run Ansible: ``ANSIBLE_SCP_IF_SSH=smart ansible-playbook`` - * Modify your ``ansible.cfg`` file: add ``scp_if_ssh=False`` to the ``[ssh_connection]`` section -* If you must use SCP, set the ``-T`` arg to tell the SCP client to ignore path validation. You can do this in one of three ways: - * Set a :ref:`host variable ` or :ref:`group variable `: ``ansible_scp_extra_args=-T``, - * Export or pass an environment variable: ``ANSIBLE_SCP_EXTRA_ARGS=-T`` - * Modify your ``ansible.cfg`` file: add ``scp_extra_args=-T`` to the ``[ssh_connection]`` section - -.. note:: If you see an ``invalid argument`` error when using ``-T``, then your SCP client is not performing filename validation and will not trigger this error. - -.. _mfa_support: - -Does Ansible support multiple factor authentication 2FA/MFA/biometrics/finterprint/usbkey/OTP/... -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -No, Ansible is designed to execute multiple tasks against multiple targets, minimizing user interaction. -As with most automation tools, it is not compatible with interactive security systems designed to handle human interaction. -Most of these systems require a secondary prompt per target, which prevents scaling to thousands of targets. They also -tend to have very short expiration periods so it requires frequent reauthorization, also an issue with many hosts and/or -a long set of tasks. - -In such environments we recommend securing around Ansible's execution but still allowing it to use an 'automation user' that does not require such measures. -With AWX or the :ref:`Red Hat Ansible Automation Platform `, administrators can set up RBAC access to inventory, along with managing credentials and job execution. - - -.. _complex_configuration_validation: - -The 'validate' option is not enough for my needs, what do I do? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Many Ansible modules that create or update files have a ``validate`` option that allows you to abort the update if the validation command fails. -This uses the temporary file Ansible creates before doing the final update. In many cases this does not work since the validation tools -for the specific application require either specific names, multiple files or some other factor that is not present in this simple feature. - -For these cases you have to handle the validation and restoration yourself. The following is a simple example of how to do this with block/rescue -and backups, which most file based modules also support: - -.. code-block:: yaml - - - name: update config and backout if validation fails - block: - - name: do the actual update, works with copy, lineinfile and any action that allows for `backup`. - template: src=template.j2 dest=/x/y/z backup=yes moreoptions=stuff - register: updated - - - name: run validation, this will change a lot as needed. We assume it returns an error when not passing, use `failed_when` if otherwise. - shell: run_validation_commmand - become: true - become_user: requiredbyapp - environment: - WEIRD_REQUIREMENT: 1 - rescue: - - name: restore backup file to original, in the hope the previous configuration was working. - copy: - remote_src: true - dest: /x/y/z - src: "{{ updated['backup_file'] }}" - always: - - name: We choose to always delete backup, but could copy or move, or only delete in rescue. - file: - path: "{{ updated['backup_file'] }}" - state: absent - -.. _jinja2_faqs: - -Why does the ``regex_search`` filter return `None` instead of an empty string? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Until the jinja2 2.10 release, Jinja was only able to return strings, but Ansible needed Python objects in some cases. Ansible uses ``safe_eval`` and only sends strings that look like certain types of Python objects through this function. With ``regex_search`` that does not find a match, the result (``None``) is converted to the string "None" which is not useful in non-native jinja2. - -The following example of a single templating action shows this behavior: - -.. code-block:: Jinja - - {{ 'ansible' | regex_search('foobar') }} - -This example does not result in a Python ``None``, so Ansible historically converted it to "" (empty string). - -The native jinja2 functionality actually allows us to return full Python objects, that are always represented as Python objects everywhere, and as such the result of a single templating action with ``regex_search`` can result in the Python ``None``. - -.. note:: - - Native jinja2 functionality is not needed when ``regex_search`` is used as an intermediate result that is then compared to the jinja2 ``none`` test. - - .. code-block:: Jinja - - {{ 'ansible' | regex_search('foobar') is none }} - - -.. _docs_contributions: - -How do I submit a change to the documentation? -++++++++++++++++++++++++++++++++++++++++++++++ - -Documentation for Ansible is kept in the main project git repository, and complete instructions -for contributing can be found in the docs README `viewable on GitHub `_. Thanks! - - -.. _legacy_vs_builtin: - -What is the difference between ``ansible.legacy`` and ``ansible.builtin`` collections? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Neither is a real collection. They are virtually constructed by the core engine (synthetic collections). - -The ``ansible.builtin`` collection only refers to plugins that ship with ``ansible-core``. - -The ``ansible.legacy`` collection is a superset of ``ansible.builtin`` (you can reference the plugins from builtin through ``ansible.legacy``). You also get the ability to -add 'custom' plugins in the :ref:`configured paths and adjacent directories `, with the ability to override the builtin plugins that have the same name. - -Also, ``ansible.legacy`` is what you get by default when you do not specify an FQCN. -So this: - - .. code-block:: yaml - - - shell: echo hi - -Is really equivalent to: - - .. code-block:: yaml - - - ansible.legacy.shell: echo hi - -Though, if you do not override the ``shell`` module, you can also just write it as ``ansible.builtin.shell``, since legacy will resolve to the builtin collection. - - -.. _i_dont_see_my_question: - -I don't see my question here -++++++++++++++++++++++++++++ - -If you have not found an answer to your questions, you can ask on one of our mailing lists or chat channels. For instructions on subscribing to a list or joining a chat channel, see :ref:`communication`. - -.. seealso:: - - :ref:`working_with_playbooks` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - `User Mailing List `_ - Have a question? Stop by the google group! diff --git a/docs/docsite/rst/reference_appendices/general_precedence.rst b/docs/docsite/rst/reference_appendices/general_precedence.rst deleted file mode 100644 index a94f4a64f15..00000000000 --- a/docs/docsite/rst/reference_appendices/general_precedence.rst +++ /dev/null @@ -1,150 +0,0 @@ -.. _general_precedence_rules: - -Controlling how Ansible behaves: precedence rules -================================================= - -To give you maximum flexibility in managing your environments, Ansible offers many ways to control how Ansible behaves: how it connects to managed nodes, how it works once it has connected. -If you use Ansible to manage a large number of servers, network devices, and cloud resources, you may define Ansible behavior in several different places and pass that information to Ansible in several different ways. -This flexibility is convenient, but it can backfire if you do not understand the precedence rules. - -These precedence rules apply to any setting that can be defined in multiple ways (by configuration settings, command-line options, playbook keywords, variables). - -.. contents:: - :local: - -Precedence categories ---------------------- - -Ansible offers four sources for controlling its behavior. In order of precedence from lowest (most easily overridden) to highest (overrides all others), the categories are: - - * Configuration settings - * Command-line options - * Playbook keywords - * Variables - -Each category overrides any information from all lower-precedence categories. For example, a playbook keyword will override any configuration setting. - -Within each precedence category, specific rules apply. However, generally speaking, 'last defined' wins and overrides any previous definitions. - -Configuration settings -^^^^^^^^^^^^^^^^^^^^^^ - -:ref:`Configuration settings` include both values from the ``ansible.cfg`` file and environment variables. Within this category, values set in configuration files have lower precedence. Ansible uses the first ``ansible.cfg`` file it finds, ignoring all others. Ansible searches for ``ansible.cfg`` in these locations in order: - - * ``ANSIBLE_CONFIG`` (environment variable if set) - * ``ansible.cfg`` (in the current directory) - * ``~/.ansible.cfg`` (in the home directory) - * ``/etc/ansible/ansible.cfg`` - -Environment variables have a higher precedence than entries in ``ansible.cfg``. If you have environment variables set on your control node, they override the settings in whichever ``ansible.cfg`` file Ansible loads. The value of any given environment variable follows normal shell precedence: the last value defined overwrites previous values. - -Command-line options -^^^^^^^^^^^^^^^^^^^^ - -Any command-line option will override any configuration setting. - -When you type something directly at the command line, you may feel that your hand-crafted values should override all others, but Ansible does not work that way. Command-line options have low precedence - they override configuration only. They do not override playbook keywords, variables from inventory or variables from playbooks. - -You can override all other settings from all other sources in all other precedence categories at the command line by :ref:`general_precedence_extra_vars`, but that is not a command-line option, it is a way of passing a :ref:`variable`. - -At the command line, if you pass multiple values for a parameter that accepts only a single value, the last defined value wins. For example, this :ref:`ad hoc task` will connect as ``carol``, not as ``mike``: - -.. code:: shell - - ansible -u mike -m ping myhost -u carol - -Some parameters allow multiple values. In this case, Ansible will append all values from the hosts listed in inventory files inventory1 and inventory2: - -.. code:: shell - - ansible -i /path/inventory1 -i /path/inventory2 -m ping all - -The help for each :ref:`command-line tool` lists available options for that tool. - -Playbook keywords -^^^^^^^^^^^^^^^^^ - -Any :ref:`playbook keyword` will override any command-line option and any configuration setting. - -Within playbook keywords, precedence flows with the playbook itself; the more specific wins against the more general: - -- play (most general) -- blocks/includes/imports/roles (optional and can contain tasks and each other) -- tasks (most specific) - -A simple example: - -.. code:: yaml - - - hosts: all - connection: ssh - tasks: - - name: This task uses ssh. - ping: - - - name: This task uses paramiko. - connection: paramiko - ping: - -In this example, the ``connection`` keyword is set to ``ssh`` at the play level. The first task inherits that value, and connects using ``ssh``. The second task inherits that value, overrides it, and connects using ``paramiko``. -The same logic applies to blocks and roles as well. All tasks, blocks, and roles within a play inherit play-level keywords; any task, block, or role can override any keyword by defining a different value for that keyword within the task, block, or role. - -Remember that these are KEYWORDS, not variables. Both playbooks and variable files are defined in YAML but they have different significance. -Playbooks are the command or 'state description' structure for Ansible, variables are data we use to help make playbooks more dynamic. - -.. _general_precedence_variables: - -Variables -^^^^^^^^^ - -Any variable will override any playbook keyword, any command-line option, and any configuration setting. - -Variables that have equivalent playbook keywords, command-line options, and configuration settings are known as :ref:`connection_variables`. Originally designed for connection parameters, this category has expanded to include other core variables like the temporary directory and the python interpreter. - -Connection variables, like all variables, can be set in multiple ways and places. You can define variables for hosts and groups in :ref:`inventory`. You can define variables for tasks and plays in ``vars:`` blocks in :ref:`playbooks`. However, they are still variables - they are data, not keywords or configuration settings. Variables that override playbook keywords, command-line options, and configuration settings follow the same rules of :ref:`variable precedence ` as any other variables. - -When set in a playbook, variables follow the same inheritance rules as playbook keywords. You can set a value for the play, then override it in a task, block, or role: - -.. code:: yaml - - - hosts: cloud - gather_facts: false - become: true - vars: - ansible_become_user: admin - tasks: - - name: This task uses admin as the become user. - dnf: - name: some-service - state: latest - - block: - - name: This task uses service-admin as the become user. - # a task to configure the new service - - name: This task also uses service-admin as the become user, defined in the block. - # second task to configure the service - vars: - ansible_become_user: service-admin - - name: This task (outside of the block) uses admin as the become user again. - service: - name: some-service - state: restarted - -Variable scope: how long is a value available? -"""""""""""""""""""""""""""""""""""""""""""""" - -Variable values set in a playbook exist only within the playbook object that defines them. These 'playbook object scope' variables are not available to subsequent objects, including other plays. - -Variable values associated directly with a host or group, including variables defined in inventory, by vars plugins, or using modules like :ref:`set_fact` and :ref:`include_vars`, are available to all plays. These 'host scope' variables are also available through the ``hostvars[]`` dictionary. - -.. _general_precedence_extra_vars: - -Using ``-e`` extra variables at the command line -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To override all other settings in all other categories, you can use extra variables: ``--extra-vars`` or ``-e`` at the command line. Values passed with ``-e`` are variables, not command-line options, and they will override configuration settings, command-line options, and playbook keywords as well as variables set elsewhere. For example, this task will connect as ``brian`` not as ``carol``: - -.. code:: shell - - ansible -u carol -e 'ansible_user=brian' -a whoami all - -You must specify both the variable name and the value with ``--extra-vars``. diff --git a/docs/docsite/rst/reference_appendices/glossary.rst b/docs/docsite/rst/reference_appendices/glossary.rst deleted file mode 100644 index 1f7d945bf9d..00000000000 --- a/docs/docsite/rst/reference_appendices/glossary.rst +++ /dev/null @@ -1,543 +0,0 @@ -Glossary -======== - -The following is a list (and re-explanation) of term definitions used elsewhere in the Ansible documentation. - -Consult the documentation home page for the full documentation and to see the terms in context, but this should be a good resource -to check your knowledge of Ansible's components and understand how they fit together. It's something you might wish to read for review or -when a term comes up on the mailing list. - -.. glossary:: - - Action - An action is a part of a task that specifies which of the modules to - run and which arguments to pass to that module. Each task can have - only one action, but it may also have other parameters. - - Ad Hoc - Refers to running Ansible to perform some quick command, using - :command:`/usr/bin/ansible`, rather than the :term:`orchestration` - language, which is :command:`/usr/bin/ansible-playbook`. An example - of an ad hoc command might be rebooting 50 machines in your - infrastructure. Anything you can do ad hoc can be accomplished by - writing a :term:`playbook ` and playbooks can also glue - lots of other operations together. - - Ansible (the package) - A software package (Python, deb, rpm, and so on) that contains ansible-core and a select group of collections. Playbooks that worked with Ansible 2.9 should still work with the Ansible 2.10 package. See the :file:`ansible-.build` file in the release-specific directory at `ansible-build-data `_ for a list of collections included in Ansible, as well as the included ``ansible-core`` version. - - ansible-base - Used only for 2.10. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository `_. See ``ansible-core``. - - ansible-core - Name used starting with 2.11. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository `_. Contains the command-line tools and the code for basic features and functions, such as copying module code to managed nodes. The ``ansible-core`` package includes a few modules and plugins and allows you to add others by installing collections. - - Ansible Galaxy - An `online distribution server `_ for finding and sharing Ansible community content, sometimes referred to as community Galaxy. Also, the command-line utility that lets users install individual Ansible Collections, for example ``ansible-galaxy collection install community.crypto``. - - Async - Refers to a task that is configured to run in the background rather - than waiting for completion. If you have a long process that would - run longer than the SSH timeout, it would make sense to launch that - task in async mode. Async modes can poll for completion every so many - seconds or can be configured to "fire and forget", in which case - Ansible will not even check on the task again; it will just kick it - off and proceed to future steps. Async modes work with both - :command:`/usr/bin/ansible` and :command:`/usr/bin/ansible-playbook`. - - Callback Plugin - Refers to some user-written code that can intercept results from - Ansible and do something with them. Some supplied examples in the - GitHub project perform custom logging, send email, or even play sound - effects. - - Check Mode - Refers to running Ansible with the ``--check`` option, which does not - make any changes on the remote systems, but only outputs the changes - that might occur if the command ran without this flag. This is - analogous to so-called "dry run" modes in other systems, though the - user should be warned that this does not take into account unexpected - command failures or cascade effects (which is true of similar modes in - other systems). Use this to get an idea of what might happen, but do - not substitute it for a good staging environment. - - Collection - A packaging format for bundling and distributing Ansible content, including plugins, roles, modules, and more. Collections release independent of other collections or ``ansible-core`` so features can be available sooner to users. Some collections are packaged with Ansible (version 2.10 or later). You can install other collections (or other versions of collections) with ``ansible-galaxy collection install ``. - - Collection name - The second part of a Fully Qualified Collection Name. The collection name divides the collection namespace and usually reflects the function of the collection content. For example, the ``cisco`` namespace might contain ``cisco.ios``, ``cisco.aci``, and ``cisco.nxos``, with content for managing the different network devices maintained by Cisco. - - community.general (collection) - A special collection managed by the Ansible Community Team containing all the modules and plugins which shipped in Ansible 2.9 that do not have their own dedicated Collection. See `community.general `_ on Galaxy. - - community.network (collection) - Similar to ``community.general``, focusing on network content. `community.network `_ on Galaxy. - - Connection Plugin - By default, Ansible talks to remote machines through pluggable - libraries. Ansible uses native OpenSSH (:term:`SSH (Native)`) or - a Python implementation called :term:`paramiko`. OpenSSH is preferred - if you are using a recent version, and also enables some features like - Kerberos and jump hosts. This is covered in the :ref:`getting - started section `. There are also - other connection types like ``accelerate`` mode, which must be - bootstrapped over one of the SSH-based connection types but is very - fast, and local mode, which acts on the local system. Users can also - write their own connection plugins. - - Conditionals - A conditional is an expression that evaluates to true or false that - decides whether a given task is executed on a given machine or not. - Ansible's conditionals are powered by the 'when' statement, which are - discussed in the :ref:`working_with_playbooks`. - - Declarative - An approach to achieving a task that uses a description of the - final state rather than a description of the sequence of steps - necessary to achieve that state. For a real world example, a - declarative specification of a task would be: "put me in California". - Depending on your current location, the sequence of steps to get you to - California may vary, and if you are already in California, nothing - at all needs to be done. Ansible's Resources are declarative; it - figures out the steps needed to achieve the final state. It also lets - you know whether or not any steps needed to be taken to get to the - final state. - - Diff Mode - A ``--diff`` flag can be passed to Ansible to show what changed on - modules that support it. You can combine it with ``--check`` to get a - good 'dry run'. File diffs are normally in unified diff format. - - Distribution server - A server, such as Ansible Galaxy or Red Hat Automation Hub where you can distribute your collections and allow others to access these collections. See :ref:`distributing_collections` for a list of distribution server types. Some Ansible features are only available on certain distribution servers. - - Executor - A core software component of Ansible that is the power behind - :command:`/usr/bin/ansible` directly -- and corresponds to the - invocation of each task in a :term:`playbook `. The - Executor is something Ansible developers may talk about, but it's not - really user land vocabulary. - - Facts - Facts are simply things that are discovered about remote nodes. While - they can be used in :term:`playbooks` and templates just like - variables, facts are things that are inferred, rather than set. Facts - are automatically discovered by Ansible when running plays by - executing the internal :ref:`setup module ` on the remote nodes. You - never have to call the setup module explicitly, it just runs, but it - can be disabled to save time if it is not needed or you can tell - ansible to collect only a subset of the full facts through the - ``gather_subset:`` option. For the convenience of users who are - switching from other configuration management systems, the fact module - will also pull in facts from the :program:`ohai` and :program:`facter` - tools if they are installed. These are fact libraries from Chef and - Puppet, respectively. (These may also be disabled through - ``gather_subset:``) - - Filter Plugin - A filter plugin is something that most users will never need to - understand. These allow for the creation of new :term:`Jinja2` - filters, which are more or less only of use to people who know what - Jinja2 filters are. If you need them, you can learn how to write them - in the :ref:`API docs section `. - - Forks - Ansible talks to remote nodes in parallel and the level of parallelism - can be set either by passing ``--forks`` or editing the default in - a configuration file. The default is a very conservative five (5) - forks, though if you have a lot of RAM, you can easily set this to - a value like 50 for increased parallelism. - - Fully Qualified Collection Name (FQCN) - The full definition of a module, plugin, or role hosted within a collection, in the form . Allows a Playbook to refer to a specific module or plugin from a specific source in an unambiguous manner, for example, ``community.grafana.grafana_dashboard``. The FQCN is required when you want to specify the exact source of a plugin. For example, if multiple collections contain a module plugin called ``user``, the FQCN specifies which one to use for a given task. When you have multiple collections installed, the FQCN is always the explicit and authoritative indicator of which collection to search for the correct plugin for each task. - - Gather Facts (Boolean) - :term:`Facts` are mentioned above. Sometimes when running a multi-play - :term:`playbook `, it is desirable to have some plays that - don't bother with fact computation if they aren't going to need to - utilize any of these values. Setting ``gather_facts: False`` on - a playbook allows this implicit fact gathering to be skipped. - - Globbing - Globbing is a way to select lots of hosts based on wildcards, rather - than the name of the host specifically, or the name of the group they - are in. For instance, it is possible to select ``ww*`` to match all - hosts starting with ``www``. This concept is pulled directly from - :program:`Func`, one of Michael DeHaan's (an Ansible Founder) earlier - projects. In addition to basic globbing, various set operations are - also possible, such as 'hosts in this group and not in another group', - and so on. - - Group - A group consists of several hosts assigned to a pool that can be - conveniently targeted together, as well as given variables that they - share in common. - - Group Vars - The :file:`group_vars/` files are files that live in a directory - alongside an inventory file, with an optional filename named after - each group. This is a convenient place to put variables that are - provided to a given group, especially complex data structures, so that - these variables do not have to be embedded in the :term:`inventory` - file or :term:`playbook `. - - Handlers - Handlers are just like regular tasks in an Ansible - :term:`playbook ` (see :term:`Tasks`) but are only run if - the Task contains a ``notify`` keyword and also indicates that it - changed something. For example, if a config file is changed, then the - task referencing the config file templating operation may notify - a service restart handler. This means services can be bounced only if - they need to be restarted. Handlers can be used for things other than - service restarts, but service restarts are the most common usage. - - Host - A host is simply a remote machine that Ansible manages. They can have - individual variables assigned to them, and can also be organized in - groups. All hosts have a name they can be reached at (which is either - an IP address or a domain name) and, optionally, a port number, if they - are not to be accessed on the default SSH port. - - Host Specifier - Each :term:`Play ` in Ansible maps a series of :term:`tasks` (which define the role, - purpose, or orders of a system) to a set of systems. - - This ``hosts:`` keyword in each play is often called the hosts specifier. - - It may select one system, many systems, one or more groups, or even - some hosts that are in one group and explicitly not in another. - - Host Vars - Just like :term:`Group Vars`, a directory alongside the inventory file named - :file:`host_vars/` can contain a file named after each hostname in the - inventory file, in :term:`YAML` format. This provides a convenient place to - assign variables to the host without having to embed them in the - :term:`inventory` file. The Host Vars file can also be used to define complex - data structures that can't be represented in the inventory file. - - Idempotency - An operation is idempotent if the result of performing it once is - exactly the same as the result of performing it repeatedly without - any intervening actions. - - Includes - The idea that :term:`playbook ` files (which are nothing - more than lists of :term:`plays`) can include other lists of plays, - and task lists can externalize lists of :term:`tasks` in other files, - and similarly with :term:`handlers`. Includes can be parameterized, - which means that the loaded file can pass variables. For instance, an - included play for setting up a WordPress blog may take a parameter - called ``user`` and that play could be included more than once to - create a blog for both ``alice`` and ``bob``. - - Inventory - A file (by default, Ansible uses a simple INI format) that describes - :term:`Hosts ` and :term:`Groups ` in Ansible. Inventory - can also be provided through an :term:`Inventory Script` (sometimes called - an "External Inventory Script"). - - Inventory Script - A very simple program (or a complicated one) that looks up - :term:`hosts `, :term:`group` membership for hosts, and variable - information from an external resource -- whether that be a SQL - database, a CMDB solution, or something like LDAP. This concept was - adapted from Puppet (where it is called an "External Nodes - Classifier") and works more or less exactly the same way. - - Jinja2 - Jinja2 is the preferred templating language of Ansible's template - module. It is a very simple Python template language that is - generally readable and easy to write. - - JSON - Ansible uses JSON for return data from remote modules. This allows - modules to be written in any language, not just Python. - - Keyword - The main expressions that make up Ansible, which apply to playbook objects - (Play, Block, Role and Task). For example 'vars:' is a keyword that lets - you define variables in the scope of the playbook object it is applied to. - - Lazy Evaluation - In general, Ansible evaluates any variables in - :term:`playbook ` content at the last possible second, - which means that if you define a data structure that data structure - itself can define variable values within it, and everything "just - works" as you would expect. This also means variable strings can - include other variables inside of those strings. - - Library - A collection of modules made available to :command:`/usr/bin/ansible` - or an Ansible :term:`playbook `. - - Limit Groups - By passing ``--limit somegroup`` to :command:`ansible` or - :command:`ansible-playbook`, the commands can be limited to a subset - of :term:`hosts `. For instance, this can be used to run - a :term:`playbook ` that normally targets an entire set of - servers to one particular server. - - Local Action - This keyword is an alias for ``delegate_to: localhost``. - Used when you want to redirect an action from the remote to - execute on the controller itself. - - Local Connection - By using ``connection: local`` in a :term:`playbook `, or - passing ``-c local`` to :command:`/usr/bin/ansible`, this indicates - that we are executing a local fork instead of executing on the remote machine. - You probably want ``local_action`` or ``delegate_to: localhost`` instead - as this ONLY changes the connection and no other context for execution. - - Lookup Plugin - A lookup plugin is a way to get data into Ansible from the outside world. - Lookup plugins are an extension of Jinja2 and can be accessed in templates, for example, - ``{{ lookup('file','/path/to/file') }}``. - These are how such things as ``with_items``, are implemented. - There are also lookup plugins like ``file`` which loads data from - a file and ones for querying environment variables, DNS text records, - or key value stores. - - Loops - Generally, Ansible is not a programming language. It prefers to be - more declarative, though various constructs like ``loop`` allow - a particular task to be repeated for multiple items in a list. - Certain modules, like :ref:`yum ` and :ref:`apt `, actually take - lists directly, and can install all packages given in those lists - within a single transaction, dramatically speeding up total time to - configuration, so they can be used without loops. - - Modules - Modules are the units of work that Ansible ships out to remote - machines. Modules are kicked off by either - :command:`/usr/bin/ansible` or :command:`/usr/bin/ansible-playbook` - (where multiple tasks use lots of different modules in conjunction). - Modules can be implemented in any language, including Perl, Bash, or - Ruby -- but can take advantage of some useful communal library code if written - in Python. Modules just have to return :term:`JSON`. Once modules are - executed on remote machines, they are removed, so no long running - daemons are used. Ansible refers to the collection of available - modules as a :term:`library`. - - Multi-Tier - The concept that IT systems are not managed one system at a time, but - by interactions between multiple systems and groups of systems in - well defined orders. For instance, a web server may need to be - updated before a database server and pieces on the web server may - need to be updated after *THAT* database server and various load - balancers and monitoring servers may need to be contacted. Ansible - models entire IT topologies and workflows rather than looking at - configuration from a "one system at a time" perspective. - - Namespace - The first part of a fully qualified collection name, the namespace usually reflects a functional content category. Example: in ``cisco.ios.ios_config``, ``cisco`` is the namespace. Namespaces are reserved and distributed by Red Hat at Red Hat's discretion. Many, but not all, namespaces will correspond with vendor names. See `Galaxy namespaces `_ on the Galaxy docsite for namespace requirements. - - Notify - The act of a :term:`task ` registering a change event and - informing a :term:`handler ` task that another - :term:`action` needs to be run at the end of the :term:`play `. If - a handler is notified by multiple tasks, it will still be run only - once. Handlers are run in the order they are listed, not in the order - that they are notified. - - Orchestration - Many software automation systems use this word to mean different - things. Ansible uses it as a conductor would conduct an orchestra. - A datacenter or cloud architecture is full of many systems, playing - many parts -- web servers, database servers, maybe load balancers, - monitoring systems, continuous integration systems, and so on. In - performing any process, it is necessary to touch systems in particular - orders, often to simulate rolling updates or to deploy software - correctly. Some system may perform some steps, then others, then - previous systems already processed may need to perform more steps. - Along the way, emails may need to be sent or web services contacted. - Ansible orchestration is all about modeling that kind of process. - - paramiko - By default, Ansible manages machines over SSH. The library that - Ansible uses by default to do this is a Python-powered library called - paramiko. The paramiko library is generally fast and easy to manage, - though users who want to use Kerberos or Jump Hosts may wish to switch - to a native SSH binary such as OpenSSH by specifying the connection - type in their :term:`playbooks`, or using the ``-c ssh`` flag. - - Playbooks - Playbooks are the language by which Ansible orchestrates, configures, - administers, or deploys systems. They are called playbooks partially - because it's a sports analogy, and it's supposed to be fun using them. - They aren't workbooks :) - - Plays - A :term:`playbook ` is a list of plays. A play is - minimally a mapping between a set of :term:`hosts ` selected by a host - specifier (usually chosen by :term:`groups ` but sometimes by - hostname :term:`globs `) and the :term:`tasks` which run on those - hosts to define the role that those systems will perform. There can be - one or many plays in a playbook. - - Pull Mode - By default, Ansible runs in :term:`push mode`, which allows it very - fine-grained control over when it talks to each system. Pull mode is - provided for when you would rather have nodes check in every N minutes - on a particular schedule. It uses a program called - :command:`ansible-pull` and can also be set up (or reconfigured) using - a push-mode :term:`playbook `. Most Ansible users use push - mode, but pull mode is included for variety and the sake of having - choices. - - :command:`ansible-pull` works by checking configuration orders out of - git on a crontab and then managing the machine locally, using the - :term:`local connection` plugin. - - Pulp 3 Galaxy - A self-hosted distribution server based on the `GalaxyNG codebase `_, based on Pulp version 3. Use it to find and share your own curated set of content. You can access your content with the ``ansible-galaxy collection`` command. - - - Push Mode - Push mode is the default mode of Ansible. In fact, it's not really - a mode at all -- it's just how Ansible works when you aren't thinking - about it. Push mode allows Ansible to be fine-grained and conduct - nodes through complex orchestration processes without waiting for them - to check in. - - Register Variable - The result of running any :term:`task ` in Ansible can be - stored in a variable for use in a template or a conditional statement. - The keyword used to define the variable is called ``register``, taking - its name from the idea of registers in assembly programming (though - Ansible will never feel like assembly programming). There are an - infinite number of variable names you can use for registration. - - Resource Model - Ansible modules work in terms of resources. For instance, the - :ref:`file module ` will select a particular file and ensure - that the attributes of that resource match a particular model. As an - example, we might wish to change the owner of :file:`/etc/motd` to - ``root`` if it is not already set to ``root``, or set its mode to - ``0644`` if it is not already set to ``0644``. The resource models - are :term:`idempotent ` meaning change commands are not - run unless needed, and Ansible will bring the system back to a desired - state regardless of the actual state -- rather than you having to tell - it how to get to the state. - - Roles - Roles are units of organization in Ansible. Assigning a role to - a group of :term:`hosts ` (or a set of :term:`groups `, - or :term:`host patterns `, and so on) implies that they should - implement a specific behavior. A role may include applying certain - variable values, certain :term:`tasks`, and certain :term:`handlers` - -- or just one or more of these things. Because of the file structure - associated with a role, roles become redistributable units that allow - you to share behavior among :term:`playbooks` -- or even with other users. - - Rolling Update - The act of addressing a number of nodes in a group N at a time to - avoid updating them all at once and bringing the system offline. For - instance, in a web topology of 500 nodes handling very large volume, - it may be reasonable to update 10 or 20 machines at a time, moving on - to the next 10 or 20 when done. The ``serial:`` keyword in an Ansible - :term:`playbooks` control the size of the rolling update pool. The - default is to address the batch size all at once, so this is something - that you must opt-in to. OS configuration (such as making sure config - files are correct) does not typically have to use the rolling update - model, but can do so if desired. - - Serial - .. seealso:: - - :term:`Rolling Update` - - Sudo - Ansible does not require root logins, and since it's daemonless, - definitely does not require root level daemons (which can be - a security concern in sensitive environments). Ansible can log in and - perform many operations wrapped in a sudo command, and can work with - both password-less and password-based sudo. Some operations that - don't normally work with sudo (like scp file transfer) can be achieved - with Ansible's :ref:`copy `, :ref:`template `, and - :ref:`fetch ` modules while running in sudo mode. - - SSH (Native) - Native OpenSSH as an Ansible transport is specified with ``-c ssh`` - (or a config file, or a keyword in the :term:`playbook `) - and can be useful if wanting to login through Kerberized SSH or using SSH - jump hosts, and so on. In 1.2.1, ``ssh`` will be used by default if the - OpenSSH binary on the control machine is sufficiently new. - Previously, Ansible selected ``paramiko`` as a default. Using - a client that supports ``ControlMaster`` and ``ControlPersist`` is - recommended for maximum performance -- if you don't have that and - don't need Kerberos, jump hosts, or other features, ``paramiko`` is - a good choice. Ansible will warn you if it doesn't detect - ControlMaster/ControlPersist capability. - - Tags - Ansible allows tagging resources in a :term:`playbook ` - with arbitrary keywords, and then running only the parts of the - playbook that correspond to those keywords. For instance, it is - possible to have an entire OS configuration, and have certain steps - labeled ``ntp``, and then run just the ``ntp`` steps to reconfigure - the time server information on a remote host. - - Task - :term:`Playbooks` exist to run tasks. Tasks combine an :term:`action` - (a module and its arguments) with a name and optionally some other - keywords (like :term:`looping keywords `). :term:`Handlers` - are also tasks, but they are a special kind of task that do not run - unless they are notified by name when a task reports an underlying - change on a remote system. - - Tasks - A list of :term:`Task`. - - Templates - Ansible can easily transfer files to remote systems but often it is - desirable to substitute variables in other files. Variables may come - from the :term:`inventory` file, :term:`Host Vars`, :term:`Group - Vars`, or :term:`Facts`. Templates use the :term:`Jinja2` template - engine and can also include logical constructs like loops and if - statements. - - Transport - Ansible uses :term:``Connection Plugins`` to define types of available - transports. These are simply how Ansible will reach out to managed - systems. Transports included are :term:`paramiko`, - :term:`ssh ` (using OpenSSH), and - :term:`local `. - - When - An optional conditional statement attached to a :term:`task ` that is used to - determine if the task should run or not. If the expression following - the ``when:`` keyword evaluates to false, the task will be ignored. - - Vars (Variables) - As opposed to :term:`Facts`, variables are names of values (they can - be simple scalar values -- integers, booleans, strings) or complex - ones (dictionaries/hashes, lists) that can be used in templates and - :term:`playbooks`. They are declared things, not things that are - inferred from the remote system's current state or nature (which is - what Facts are). - - YAML - Ansible does not want to force people to write programming language - code to automate infrastructure, so Ansible uses YAML to define - :term:`playbook ` configuration languages and also variable - files. YAML is nice because it has a minimum of syntax and is very - clean and easy for people to skim. It is a good data format for - configuration files and humans, but also machine readable. Ansible's - usage of YAML stemmed from Michael DeHaan's first use of it inside of - Cobbler around 2006. YAML is fairly popular in the dynamic language - community and the format has libraries available for serialization in - many languages (Python, Perl, Ruby, and so on). - -.. seealso:: - - :ref:`ansible_faq` - Frequently asked questions - :ref:`working_with_playbooks` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/reference_appendices/interpreter_discovery.rst b/docs/docsite/rst/reference_appendices/interpreter_discovery.rst deleted file mode 100644 index 23d1d970929..00000000000 --- a/docs/docsite/rst/reference_appendices/interpreter_discovery.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. _interpreter_discovery: - -Interpreter Discovery -===================== - -Most Ansible modules that execute under a POSIX environment require a Python -interpreter on the target host. Unless configured otherwise, Ansible will -attempt to discover a suitable Python interpreter on each target host -the first time a Python module is executed for that host. - -To control the discovery behavior: - -* for individual hosts and groups, use the ``ansible_python_interpreter`` inventory variable -* globally, use the ``interpreter_python`` key in the ``[defaults]`` section of ``ansible.cfg`` - -Use one of the following values: - -auto_legacy : - Detects the target OS platform, distribution, and version, then consults a - table listing the correct Python interpreter and path for each - platform/distribution/version. If an entry is found, and ``/usr/bin/python`` is absent, uses the discovered interpreter (and path). If an entry - is found, and ``/usr/bin/python`` is present, uses ``/usr/bin/python`` - and issues a warning. - This exception provides temporary compatibility with previous versions of - Ansible that always defaulted to ``/usr/bin/python``, so if you have - installed Python and other dependencies at ``/usr/bin/python`` on some hosts, - Ansible will find and use them with this setting. - If no entry is found, or the listed Python is not present on the - target host, searches a list of common Python interpreter - paths and uses the first one found; also issues a warning that future - installation of another Python interpreter could alter the one chosen. - -auto : (default in 2.12) - Detects the target OS platform, distribution, and version, then consults a - table listing the correct Python interpreter and path for each - platform/distribution/version. If an entry is found, uses the discovered - interpreter. - If no entry is found, or the listed Python is not present on the - target host, searches a list of common Python interpreter - paths and uses the first one found; also issues a warning that future - installation of another Python interpreter could alter the one chosen. - -auto_legacy_silent - Same as ``auto_legacy``, but does not issue warnings. - -auto_silent - Same as ``auto``, but does not issue warnings. - -You can still set ``ansible_python_interpreter`` to a specific path at any -variable level (for example, in host_vars, in vars files, in playbooks, and so on). -Setting a specific path completely disables automatic interpreter discovery; Ansible always uses the path specified. diff --git a/docs/docsite/rst/reference_appendices/logging.rst b/docs/docsite/rst/reference_appendices/logging.rst deleted file mode 100644 index 5adac5c8e10..00000000000 --- a/docs/docsite/rst/reference_appendices/logging.rst +++ /dev/null @@ -1,14 +0,0 @@ -********************** -Logging Ansible output -********************** - -By default Ansible sends output about plays, tasks, and module arguments to your screen (STDOUT) on the control node. If you want to capture Ansible output in a log, you have three options: - -* To save Ansible output in a single log on the control node, set the ``log_path`` :ref:`configuration file setting `. You may also want to set ``display_args_to_stdout``, which helps to differentiate similar tasks by including variable values in the Ansible output. -* To save Ansible output in separate logs, one on each managed node, set the ``no_target_syslog`` and ``syslog_facility`` :ref:`configuration file settings `. -* To save Ansible output to a secure database, use AWX or :ref:`Red Hat Ansible Automation Platform `. You can then review history based on hosts, projects, and particular inventories over time, using graphs and/or a REST API. - -Protecting sensitive data with ``no_log`` -========================================= - -If you save Ansible output to a log, you expose any secret data in your Ansible output, such as passwords and user names. To keep sensitive values out of your logs, mark tasks that expose them with the ``no_log: True`` attribute. However, the ``no_log`` attribute does not affect debugging output, so be careful not to debug playbooks in a production environment. See :ref:`keep_secret_data` for an example. diff --git a/docs/docsite/rst/reference_appendices/module_utils.rst b/docs/docsite/rst/reference_appendices/module_utils.rst deleted file mode 100644 index 29cf23106e4..00000000000 --- a/docs/docsite/rst/reference_appendices/module_utils.rst +++ /dev/null @@ -1,74 +0,0 @@ -.. _ansible.module_utils: -.. _module_utils: - -*************************************************************** -Ansible Reference: Module Utilities -*************************************************************** - -This page documents utilities intended to be helpful when writing -Ansible modules in Python. - - -AnsibleModule --------------- - -To use this functionality, include ``from ansible.module_utils.basic import AnsibleModule`` in your module. - -.. autoclass:: ansible.module_utils.basic.AnsibleModule - :members: - :noindex: - -Basic ------- - -To use this functionality, include ``import ansible.module_utils.basic`` in your module. - -.. automodule:: ansible.module_utils.basic - :members: - - -Argument Spec ---------------------- - -Classes and functions for validating parameters against an argument spec. - -ArgumentSpecValidator -===================== - -.. autoclass:: ansible.module_utils.common.arg_spec.ArgumentSpecValidator - :members: - -ValidationResult -================ - -.. autoclass:: ansible.module_utils.common.arg_spec.ValidationResult - :members: - :member-order: bysource - :private-members: _no_log_values # This only works in sphinx >= 3.2. Otherwise it shows all private members with doc strings. - -Parameters -========== - -.. automodule:: ansible.module_utils.common.parameters - :members: - - .. py:data:: DEFAULT_TYPE_VALIDATORS - - :class:`dict` of type names, such as ``'str'``, and the default function - used to check that type, :func:`~ansible.module_utils.common.validation.check_type_str` in this case. - -Validation -========== - -Standalone functions for validating various parameter types. - -.. automodule:: ansible.module_utils.common.validation - :members: - - -Errors ------- - -.. automodule:: ansible.module_utils.errors - :members: - :member-order: bysource diff --git a/docs/docsite/rst/reference_appendices/python_3_support.rst b/docs/docsite/rst/reference_appendices/python_3_support.rst deleted file mode 100644 index e7196d2aaa4..00000000000 --- a/docs/docsite/rst/reference_appendices/python_3_support.rst +++ /dev/null @@ -1,95 +0,0 @@ -================ -Python 3 Support -================ - -Ansible 2.5 and above work with Python 3. Previous to 2.5, using Python 3 was -considered a tech preview. This topic discusses how to set up your controller and managed machines -to use Python 3. - -See :ref: `Control Node Requirements ` and :ref: `Managed Node Requirements ` for the specific versions supported. - -On the controller side ----------------------- - -The easiest way to run :command:`/usr/bin/ansible` under Python 3 is to install it with the Python3 -version of pip. This will make the default :command:`/usr/bin/ansible` run with Python3: - -.. code-block:: shell - - $ pip3 install ansible - $ ansible --version | grep "python version" - python version = 3.10.5 (main, Jun 9 2022, 00:00:00) [GCC 12.1.1 20220507 (Red Hat 12.1.1-1)] (/usr/bin/python) - -If you are running Ansible :ref:`from_source` and want to use Python 3 with your source checkout, run your -command through ``python3``. For example: - -.. code-block:: shell - - $ source ./hacking/env-setup - $ python3 $(which ansible) localhost -m ping - $ python3 $(which ansible-playbook) sample-playbook.yml - -.. note:: Individual Linux distribution packages may be packaged for Python2 or Python3. When running from - distro packages you'll only be able to use Ansible with the Python version for which it was - installed. Sometimes distros will provide a means of installing for several Python versions - (through a separate package or through some commands that are run after install). You'll need to check - with your distro to see if that applies in your case. - - -Using Python 3 on the managed machines with commands and playbooks ------------------------------------------------------------------- - -* Ansible will automatically detect and use Python 3 on many platforms that ship with it. To explicitly configure a - Python 3 interpreter, set the ``ansible_python_interpreter`` inventory variable at a group or host level to the - location of a Python 3 interpreter, such as :command:`/usr/bin/python3`. The default interpreter path may also be - set in ``ansible.cfg``. - -.. seealso:: :ref:`interpreter_discovery` for more information. - -.. code-block:: ini - - # Example inventory that makes an alias for localhost that uses Python3 - localhost-py3 ansible_host=localhost ansible_connection=local ansible_python_interpreter=/usr/bin/python3 - - # Example of setting a group of hosts to use Python3 - [py3_hosts] - ubuntu16 - fedora27 - - [py3_hosts:vars] - ansible_python_interpreter=/usr/bin/python3 - -.. seealso:: :ref:`intro_inventory` for more information. - -* Run your command or playbook: - -.. code-block:: shell - - $ ansible localhost-py3 -m ping - $ ansible-playbook sample-playbook.yml - - -Note that you can also use the `-e` command line option to manually -set the python interpreter when you run a command. This can be useful if you want to test whether -a specific module or playbook has any bugs under Python 3. For example: - -.. code-block:: shell - - $ ansible localhost -m ping -e 'ansible_python_interpreter=/usr/bin/python3' - $ ansible-playbook sample-playbook.yml -e 'ansible_python_interpreter=/usr/bin/python3' - -What to do if an incompatibility is found ------------------------------------------ - -We have spent several releases squashing bugs and adding new tests so that Ansible's core feature -set runs under both Python 2 and Python 3. However, bugs may still exist in edge cases and many of -the modules shipped with Ansible are maintained by the community and not all of those may be ported -yet. - -If you find a bug running under Python 3 you can submit a bug report on `Ansible's GitHub project -`_. Be sure to mention Python3 in the bug report so -that the right people look at it. - -If you would like to fix the code and submit a pull request on github, you can -refer to :ref:`developing_python_3` for information on how we fix -common Python3 compatibility issues in the Ansible codebase. diff --git a/docs/docsite/rst/reference_appendices/release_and_maintenance.rst b/docs/docsite/rst/reference_appendices/release_and_maintenance.rst deleted file mode 100644 index 43a2e925c72..00000000000 --- a/docs/docsite/rst/reference_appendices/release_and_maintenance.rst +++ /dev/null @@ -1,400 +0,0 @@ -.. _release_and_maintenance: - -************************ -Releases and maintenance -************************ - -This section describes release cycles, rules, and maintenance schedules for both Ansible community projects: the Ansible community package and ``ansible-core``. The two projects have different versioning systems, maintenance structures, contents, and workflows. - -==================================================== ======================================================== -Ansible community package ansible-core -==================================================== ======================================================== -Uses new versioning (2.10, then 3.0.0) Continues "classic Ansible" versioning (2.11, then 2.12) -Follows semantic versioning rules Does not use semantic versioning -Maintains only one version at a time Maintains latest version plus two older versions -Includes language, runtime, and selected Collections Includes language, runtime, and builtin plugins -Developed and maintained in Collection repositories Developed and maintained in ansible/ansible repository -==================================================== ======================================================== - -Many community users install the Ansible community package. The Ansible community package offers the functionality that existed in Ansible 2.9, with more than 85 Collections containing thousands of modules and plugins. The ``ansible-core`` option is primarily for developers and users who want to install only the collections they need. - -.. contents:: - :local: - -.. _release_cycle: - -Release cycle overview -====================== - -The two community releases are related - the release cycle follows this pattern: - -#. Release of a new ansible-core major version, for example, ansible-core 2.11 - - * New release of ansible-core and two prior versions are now maintained (in this case, ansible-base 2.10, Ansible 2.9) - * Work on new features for ansible-core continues in the ``devel`` branch - -#. Collection freeze (no new Collections or new versions of existing Collections) on the Ansible community package -#. Release candidate for Ansible community package, testing, additional release candidates as necessary -#. Release of a new Ansible community package major version based on the new ansible-core, for example, Ansible 4.0.0 based on ansible-core 2.11 - - * Newest release of the Ansible community package is the only version now maintained - * Work on new features continues in Collections - * Individual Collections can make multiple minor and major releases - -#. Minor releases of three maintained ansible-core versions every four weeks (2.11.1) -#. Minor releases of the single maintained Ansible community package version every four weeks (4.1.0) -#. Feature freeze on ansible-core -#. Release candidate for ansible-core, testing, additional release candidates as necessary -#. Release of the next ansible-core major version, cycle begins again - -Ansible community package release cycle ---------------------------------------- - -The Ansible community team typically releases two major versions of the community package per year, on a flexible release cycle that trails the release of ``ansible-core``. This cycle can be extended to allow for larger changes to be properly implemented and tested before a new release is made available. See :ref:`ansible_roadmaps` for upcoming release details. Between major versions, we release a new minor version of the Ansible community package every four weeks. Minor releases include new backwards-compatible features, modules and plugins, as well as bug fixes. - -Starting with version 2.10, the Ansible community team guarantees maintenance for only one major community package release at a time. For example, when Ansible 4.0.0 gets released, the team will stop making new 3.x releases. Community members may maintain older versions if desired. - -.. note:: - - Each Ansible EOL version may issue one final maintenance release at or shortly after the first release of the next version. When this happens, the final maintenance release is EOL at the date it releases. - - -.. note:: - - Older, unmaintained versions of the Ansible community package might contain unfixed security vulnerabilities (*CVEs*). If you are using a release of the Ansible community package that is no longer maintained, we strongly encourage you to upgrade as soon as possible to benefit from the latest features and security fixes. - -Each major release of the Ansible community package accepts the latest released version of each included Collection and the latest released version of ansible-core. For specific schedules and deadlines, see the :ref:`ansible_roadmaps` for each version. Major releases of the Ansible community package can contain breaking changes in the modules and other plugins within the included Collections and in core features. - -The Ansible community package follows semantic versioning rules. Minor releases of the Ansible community package accept only backwards-compatible changes in included Collections, that is, not Collections major releases. Collections must also use semantic versioning, so the Collection version numbers reflect this rule. For example, if Ansible 3.0.0 releases with community.general 2.0.0, then all minor releases of Ansible 3.x (such as Ansible 3.1.0 or Ansible 3.5.0) must include a 2.x release of community.general (such as 2.8.0 or 2.9.5) and not 3.x.x or later major releases. - -Work in Collections is tracked within the individual Collection repositories. - -You can refer to the :ref:`Ansible package porting guides` for tips on updating your playbooks to run on newer versions of Ansible. For Ansible 2.10 and later releases, you can install the Ansible package with ``pip``. See :ref:`intro_installation_guide` for details. You can download older Ansible releases from ``_. - -.. _ansible_changelogs: - -Ansible community changelogs ----------------------------- - -This table links to the changelogs for each major Ansible release. These changelogs contain the dates and significant changes in each minor release. - -================================== ============================================== ========================= -Ansible Community Package Release Status Core version dependency -================================== ============================================== ========================= -9.0.0 In development (unreleased) 2.16 -`8.x Changelogs`_ Current 2.15 -`7.x Changelogs`_ Unmaintained (end of life) after Ansible 7.7.0 2.14 -`6.x Changelogs`_ Unmaintained (end of life) 2.13 -`5.x Changelogs`_ Unmaintained (end of life) 2.12 -`4.x Changelogs`_ Unmaintained (end of life) 2.11 -`3.x Changelogs`_ Unmaintained (end of life) 2.10 -`2.10 Changelogs`_ Unmaintained (end of life) 2.10 -================================== ============================================== ========================= - -.. _8.x Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/8/CHANGELOG-v8.rst -.. _7.x Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/7/CHANGELOG-v7.rst -.. _6.x Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/6/CHANGELOG-v6.rst -.. _5.x Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/5/CHANGELOG-v5.rst -.. _4.x Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/4/CHANGELOG-v4.rst -.. _3.x Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/3/CHANGELOG-v3.rst -.. _2.10 Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/2.10/CHANGELOG-v2.10.rst - - -ansible-core release cycle --------------------------- - -``ansible-core`` is developed and released on a flexible release cycle. We can extend this cycle to properly implement and test larger changes before a new release is made available. See :ref:`ansible_core_roadmaps` for upcoming release details. - -``ansible-core`` has a graduated maintenance structure that extends to three major releases. -For more information, read about the :ref:`development_and_stable_version_maintenance_workflow` or -see the chart in :ref:`release_schedule` for the degrees to which current releases are maintained. - -.. note:: - - Older, unmaintained versions of ``ansible-core`` can contain unfixed security vulnerabilities (*CVEs*). If you are using a release of ``ansible-core`` that is no longer maintained, we strongly encourage you to upgrade as soon as possible to benefit from the latest features and security fixes. ``ansible-core`` maintenance continues for 3 releases. Thus the latest release receives security and general bug fixes when it is first released, security and critical bug fixes when the next ``ansible-core`` version is released, and **only** security fixes once the follow on to that version is released. - -You can refer to the :ref:`core_porting_guides` for tips on updating your playbooks to run on newer versions of ``ansible-core``. - -You can install ``ansible-core`` with ``pip``. See :ref:`intro_installation_guide` for details. - -.. _release_schedule: -.. _support_life: - -``ansible-core`` support matrix -------------------------------- - -This table links to the changelogs for each major ``ansible-core`` release. These changelogs contain the dates and significant changes in each minor release. -Dates listed indicate the start date of the maintenance cycle. - -.. list-table:: - :header-rows: 1 - - * - Version - - Support - - End Of Life - - Controller Python - - Target Python / PowerShell - * - `2.16` - - | GA: 06 Nov 2023 - | Critical: 20 May 2024 - | Security: Nov 2024 - - May 2025 - - | Python 3.10 - 3.12 - - | Python 2.7 - | Python 3.6 - 3.12 - | Powershell TBD - * - `2.15`_ - - | GA: 22 May 2023 - | Critical: 06 Nov 2023 - | Security: 20 May 2024 - - Nov 2024 - - | Python 3.9 - 3.11 - - | Python 2.7 - | Python 3.5 - 3.11 - | PowerShell 3 - 5.1 - * - `2.14`_ - - | GA: 07 Nov 2022 - | Critical: 22 May 2023 - | Security: 06 Nov 2023 - - 20 May 2024 - - | Python 3.9 - 3.11 - - | Python 2.7 - | Python 3.5 - 3.11 - | PowerShell 3 - 5.1 - * - `2.13`_ - - | GA: 23 May 2022 - | Critical: 07 Nov 2022 - | Security: 22 May 2023 - - 06 Nov 2023 - - | Python 3.8 - 3.10 - - | Python 2.7 - | Python 3.5 - 3.10 - | PowerShell 3 - 5.1 - * - `2.12`_ - - | GA: 08 Nov 2021 - | Critical: 23 May 2022 - | Security: 07 Nov 2022 - - | **EOL** - | 22 May 2023 - - | Python 3.8 - 3.10 - - | Python 2.6 - 2.7 - | Python 3.5 - 3.10 - | PowerShell 3 - 5.1 - * - `2.11`_ - - | GA: 26 Apr 2021 - | Critical: 08 Nov 2021 - | Security: 23 May 2022 - - | **EOL** - | 07 Nov 2022 - - | Python 2.7 - | Python 3.5 - 3.9 - - | Python 2.6 - 2.7 - | Python 3.5 - 3.9 - | PowerShell 3 - 5.1 - * - `2.10`_ - - | GA: 13 Aug 2020 - | Critical: 26 Apr 2021 - | Security: 08 Nov 2021 - - | **EOL** - | 23 May 2022 - - | Python 2.7 - | Python 3.5 - 3.9 - - | Python 2.6 - 2.7 - | Python 3.5 - 3.9 - | PowerShell 3 - 5.1 - * - `2.9`_ - - | GA: 31 Oct 2019 - | Critical: 13 Aug 2020 - | Security: 26 Apr 2021 - - | **EOL** - | 23 May 2022 - - | Python 2.7 - | Python 3.5 - 3.8 - - | Python 2.6 - 2.7 - | Python 3.5 - 3.8 - | PowerShell 3 - 5.1 -.. * - 2.17 -.. - 20 May 2024 -.. - Nov 2024 -.. - May 2025 -.. - Nov 2025 -.. - | Python 3.10 - 3.12 -.. - | Python 3.6 - 3.12 -.. | PowerShell TBD -.. * - 2.18 -.. - Nov 2024 -.. - May 2025 -.. - Nov 2025 -.. - May 2026 -.. - | Python 3.11 - 3.13 -.. - | Python 3.6 - 3.13 -.. | PowerShell TBD -.. * - 2.19 -.. - May 2025 -.. - Nov 2025 -.. - May 2026 -.. - Nov 2026 -.. - | Python 3.11 - 3.13 -.. - | Python 3.6 - 3.13 -.. | PowerShell TBD -.. * - 2.20 -.. - Nov 2025 -.. - May 2026 -.. - Nov 2026 -.. - May 2027 -.. - | Python 3.12 - 3.14 -.. - | Python 3.8 - 3.14 -.. | PowerShell TBD -.. * - 2.21 -.. - May 2026 -.. - Nov 2026 -.. - May 2027 -.. - Nov 2027 -.. - | Python 3.12 - 3.14 -.. - | Python 3.8 - 3.14 -.. | PowerShell TBD -.. * - 2.22 -.. - Nov 2026 -.. - May 2027 -.. - Nov 2027 -.. - May 2028 -.. - | Python 3.13 - 3.15 -.. - | Python 3.8 - 3.15 -.. | PowerShell TBD -.. * - 2.23 -.. - May 2027 -.. - Nov 2027 -.. - May 2028 -.. - Nov 2028 -.. - | Python 3.13 - 3.15 -.. - | Python 3.8 - 3.15 -.. | PowerShell TBD -.. * - 2.24 -.. - Nov 2027 -.. - May 2028 -.. - Nov 2028 -.. - May 2029 -.. - | Python 3.14 - 3.16 -.. - | Python 3.8 - 3.16 -.. | PowerShell TBD -.. * - 2.25 -.. - May 2028 -.. - Nov 2028 -.. - May 2029 -.. - Nov 2029 -.. - | Python 3.14 - 3.16 -.. - | Python 3.8 - 3.16 -.. | PowerShell TBD - - -.. _2.9: https://github.com/ansible/ansible/blob/stable-2.9/changelogs/CHANGELOG-v2.9.rst -.. _2.10: https://github.com/ansible/ansible/blob/stable-2.10/changelogs/CHANGELOG-v2.10.rst -.. _2.11: https://github.com/ansible/ansible/blob/stable-2.11/changelogs/CHANGELOG-v2.11.rst -.. _2.12: https://github.com/ansible/ansible/blob/stable-2.12/changelogs/CHANGELOG-v2.12.rst -.. _2.13: https://github.com/ansible/ansible/blob/stable-2.13/changelogs/CHANGELOG-v2.13.rst -.. _2.14: https://github.com/ansible/ansible/blob/stable-2.14/changelogs/CHANGELOG-v2.14.rst -.. _2.15: https://github.com/ansible/ansible/blob/stable-2.15/changelogs/CHANGELOG-v2.15.rst - - -Preparing for a new release -=========================== - -.. _release_freezing: - -Feature freezes ---------------- - -During final preparations for a new release, core developers and maintainers focus on improving the release candidate, not on adding or reviewing new features. We may impose a feature freeze. - -A feature freeze means that we delay new features and fixes unrelated to the pending release so we can create the new release as soon as possible. - - - -Release candidates ------------------- - -We create at least one release candidate before each new major release of Ansible or ``ansible-core``. Release candidates allow the Ansible community to try out new features, test existing playbooks on the release candidate, and report bugs or issues they find. - -Ansible and ``ansible-core`` tag the first release candidate (RC1) which is usually scheduled to last five business days. If no major bugs or issues are identified during this period, the release candidate becomes the final release. - -If there are major problems with the first candidate, the team and the community fix them and tag a second release candidate (RC2). This second candidate lasts for a shorter duration than the first. If no problems have been reported for an RC2 after two business days, the second release candidate becomes the final release. - -If there are major problems in RC2, the cycle begins again with another release candidate and repeats until the maintainers agree that all major problems have been fixed. - - -.. _development_and_stable_version_maintenance_workflow: - -Development and maintenance workflows -===================================== - -In between releases, the Ansible community develops new features, maintains existing functionality, and fixes bugs in ``ansible-core`` and in the collections included in the Ansible community package. - -Ansible community package workflow ----------------------------------- - -The Ansible community develops and maintains the features and functionality included in the Ansible community package in Collections repositories, with a workflow that looks like this: - - * Developers add new features and bug fixes to the individual Collections, following each Collection's rules on contributing. - * Each new feature and each bug fix includes a changelog fragment describing the work. - * Release engineers create a minor release for the current version every four weeks to ensure that the latest bug fixes are available to users. - * At the end of the development period, the release engineers announce which Collections, and which major version of each included Collection, will be included in the next release of the Ansible community package. New Collections and new major versions may not be added after this, and the work of creating a new release begins. - -We generally do not provide fixes for unmaintained releases of the Ansible community package, however, there can sometimes be exceptions for critical issues. - -Some Collections are maintained by the Ansible team, some by Partner organizations, and some by community teams. For more information on adding features or fixing bugs in Ansible-maintained Collections, see :ref:`contributing_maintained_collections`. - -ansible-core workflow ---------------------- - -The Ansible community develops and maintains ``ansible-core`` on GitHub_, with a workflow that looks like this: - - * Developers add new features and bug fixes to the ``devel`` branch. - * Each new feature and each bug fix includes a changelog fragment describing the work. - * The development team backports bug fixes to one, two, or three stable branches, depending on the severity of the bug. They do not backport new features. - * Release engineers create a minor release for each maintained version every four weeks to ensure that the latest bug fixes are available to users. - * At the end of the development period, the release engineers impose a feature freeze and the work of creating a new release begins. - -We generally do not provide fixes for unmaintained releases of ``ansible-core``, however, there can sometimes be exceptions for critical issues. - -For more information about adding features or fixing bugs in ``ansible-core`` see :ref:`community_development_process`. - -.. _GitHub: https://github.com/ansible/ansible - -.. _release_changelogs: - -Generating changelogs ----------------------- - -We generate changelogs based on fragments. When creating new features for existing modules and plugins or fixing bugs, create a changelog fragment describing the change. A changelog entry is not needed for new modules or plugins. Details for those items will be generated from the module documentation. - -To add changelog fragments to Collections in the Ansible community package, we recommend the `antsibull-changelog utility `_. - -To add changelog fragments for new features and bug fixes in ``ansible-core``, see the :ref:`changelog examples and instructions` in the Community Guide. - -Deprecation cycles -================== - -Sometimes we remove a feature, normally in favor of a reimplementation that we hope does a better job. To do this we have a deprecation cycle. First we mark a feature as 'deprecated'. This is normally accompanied with warnings to the user as to why we deprecated it, what alternatives they should switch to and when (which version) we are scheduled to remove the feature permanently. - -Ansible community package deprecation cycle --------------------------------------------- - -Since Ansible is a package of individual collections, the deprecation cycle depends on the collection maintainers. We recommend the collection maintainers deprecate a feature in one Ansible major version and do not remove that feature for one year, or at least until the next major Ansible version. For example, deprecate the feature in 3.1.0 and do not remove the feature until 5.0.0 or 4.0.0 at the earliest. Collections should use semantic versioning, such that the major collection version cannot be changed within an Ansible major version. Therefore, the removal should not happen before the next major Ansible community package release. This is up to each collection maintainer and cannot be guaranteed. - -ansible-core deprecation cycle -------------------------------- - -The deprecation cycle in ``ansible-core`` is normally across 4 feature releases (2.x. where the x marks a feature release). The feature is normally removed in the 4th release after we announce the deprecation. For example, something deprecated in 2.10 will be removed in 2.14. The tracking is tied to the number of releases, not the release numbering itself. - -.. seealso:: - - :ref:`community_committer_guidelines` - Guidelines for Ansible core contributors and maintainers - :ref:`testing_strategies` - Testing strategies - :ref:`ansible_community_guide` - Community information and contributing - `Development Mailing List `_ - Mailing list for development topics - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/reference_appendices/special_variables.rst b/docs/docsite/rst/reference_appendices/special_variables.rst deleted file mode 100644 index 73bd07c0866..00000000000 --- a/docs/docsite/rst/reference_appendices/special_variables.rst +++ /dev/null @@ -1,173 +0,0 @@ -.. _special_variables: - -Special Variables -================= - -Magic variables ---------------- -These variables cannot be set directly by the user; Ansible will always override them to reflect internal state. - -.. glossary:: - - ansible_check_mode - Boolean that indicates if we are in check mode or not - - ansible_config_file - The full path of used Ansible configuration file - - ansible_dependent_role_names - The names of the roles currently imported into the current play as dependencies of other plays - - ansible_diff_mode - Boolean that indicates if we are in diff mode or not - - ansible_forks - Integer reflecting the number of maximum forks available to this run - - ansible_inventory_sources - List of sources used as inventory - - ansible_limit - Contents of the ``--limit`` CLI option for the current execution of Ansible - - ansible_loop - A dictionary/map containing extended loop information when enabled through ``loop_control.extended`` - - ansible_loop_var - The name of the value provided to ``loop_control.loop_var``. Added in ``2.8`` - - ansible_index_var - The name of the value provided to ``loop_control.index_var``. Added in ``2.9`` - - ansible_parent_role_names - When the current role is being executed by means of an :ref:`include_role ` or :ref:`import_role ` action, this variable contains a list of all parent roles, with the most recent role (in other words, the role that included/imported this role) being the first item in the list. - When multiple inclusions occur, this list lists the *last* role (in other words, the role that included this role) as the *first* item in the list. It is also possible that a specific role exists more than once in this list. - - For example: When role **A** includes role **B**, inside role B, ``ansible_parent_role_names`` will equal to ``['A']``. If role **B** then includes role **C**, the list becomes ``['B', 'A']``. - - ansible_parent_role_paths - When the current role is being executed by means of an :ref:`include_role ` or :ref:`import_role ` action, this variable contains a list of all parent roles paths, with the most recent role (in other words, the role that included/imported this role) being the first item in the list. - Please refer to ``ansible_parent_role_names`` for the order of items in this list. - - ansible_play_batch - List of active hosts in the current play run limited by the serial, aka 'batch'. Failed/Unreachable hosts are not considered 'active'. - - ansible_play_hosts - List of hosts in the current play run, not limited by the serial. Failed/Unreachable hosts are excluded from this list. - - ansible_play_hosts_all - List of all the hosts that were targeted by the play - - ansible_play_role_names - The names of the roles currently imported into the current play. This list does **not** contain the role names that are - implicitly included through dependencies. - - ansible_playbook_python - The path to the python interpreter being used by Ansible on the controller - - ansible_role_names - The names of the roles currently imported into the current play, or roles referenced as dependencies of the roles - imported into the current play. - - ansible_role_name - The fully qualified collection role name, in the format of ``namespace.collection.role_name`` - - ansible_collection_name - The name of the collection the task that is executing is a part of. In the format of ``namespace.collection`` - - ansible_run_tags - Contents of the ``--tags`` CLI option, which specifies which tags will be included for the current run. Note that if ``--tags`` is not passed, this variable will default to ``["all"]``. - - ansible_search_path - Current search path for action plugins and lookups, in other words, where we search for relative paths when you do ``template: src=myfile`` - - ansible_skip_tags - Contents of the ``--skip-tags`` CLI option, which specifies which tags will be skipped for the current run. - - ansible_verbosity - Current verbosity setting for Ansible - - ansible_version - Dictionary/map that contains information about the current running version of ansible, it has the following keys: full, major, minor, revision and string. - - group_names - List of groups the current host is part of - - groups - A dictionary/map with all the groups in inventory and each group has the list of hosts that belong to it - - hostvars - A dictionary/map with all the hosts in inventory and variables assigned to them - - inventory_hostname - The inventory name for the 'current' host being iterated over in the play - - inventory_hostname_short - The short version of `inventory_hostname` - - inventory_dir - The directory of the inventory source in which the `inventory_hostname` was first defined - - inventory_file - The file name of the inventory source in which the `inventory_hostname` was first defined - - omit - Special variable that allows you to 'omit' an option in a task, for example ``- user: name=bob home={{ bobs_home|default(omit) }}`` - - play_hosts - Deprecated, the same as ansible_play_batch - - ansible_play_name - The name of the currently executed play. Added in ``2.8``. (`name` attribute of the play, not file name of the playbook.) - - playbook_dir - The path to the directory of the current playbook being executed. NOTE: This might be different than directory of the playbook passed to the ``ansible-playbook`` command line when a playbook contains a ``import_playbook`` statement. - - role_name - The name of the role currently being executed. - - role_names - Deprecated, the same as ansible_play_role_names - - role_path - The path to the dir of the currently running role - -Facts ------ -These are variables that contain information pertinent to the current host (`inventory_hostname`). They are only available if gathered first. See :ref:`vars_and_facts` for more information. - -.. glossary:: - - ansible_facts - Contains any facts gathered or cached for the `inventory_hostname` - Facts are normally gathered by the :ref:`setup ` module automatically in a play, but any module can return facts. - - ansible_local - Contains any 'local facts' gathered or cached for the `inventory_hostname`. - The keys available depend on the custom facts created. - See the :ref:`setup ` module and :ref:`local_facts` for more details. - -.. _connection_variables: - -Connection variables ---------------------- -Connection variables are normally used to set the specifics on how to execute actions on a target. Most of them correspond to connection plugins, but not all are specific to them; other plugins like shell, terminal and become are normally involved. -Only the common ones are described as each connection/become/shell/etc plugin can define its own overrides and specific variables. -See :ref:`general_precedence_rules` for how connection variables interact with :ref:`configuration settings`, :ref:`command-line options`, and :ref:`playbook keywords`. - -.. glossary:: - - ansible_become_user - The user Ansible 'becomes' after using privilege escalation. This must be available to the 'login user'. - - ansible_connection - The connection plugin actually used for the task on the target host. - - ansible_host - The ip/name of the target host to use instead of `inventory_hostname`. - - ansible_python_interpreter - The path to the Python executable Ansible should use on the target host. - - ansible_user - The user Ansible 'logs in' as. diff --git a/docs/docsite/rst/reference_appendices/test_strategies.rst b/docs/docsite/rst/reference_appendices/test_strategies.rst deleted file mode 100644 index fa28f76b7f0..00000000000 --- a/docs/docsite/rst/reference_appendices/test_strategies.rst +++ /dev/null @@ -1,303 +0,0 @@ -.. _testing_strategies: - -Testing Strategies -================== - -.. _testing_intro: - -Integrating Testing With Ansible Playbooks -`````````````````````````````````````````` - -Many times, people ask, "how can I best integrate testing with Ansible playbooks?" There are many options. Ansible is actually designed -to be a "fail-fast" and ordered system, therefore it makes it easy to embed testing directly in Ansible playbooks. In this chapter, -we'll go into some patterns for integrating tests of infrastructure and discuss the right level of testing that may be appropriate. - -.. note:: This is a chapter about testing the application you are deploying, not the chapter on how to test Ansible modules during development. For that content, please hop over to the Development section. - -By incorporating a degree of testing into your deployment workflow, there will be fewer surprises when code hits production and, in many cases, -tests can be used in production to prevent failed updates from migrating across an entire installation. Since it's push-based, it's -also very easy to run the steps on the localhost or testing servers. Ansible lets you insert as many checks and balances into your upgrade workflow as you would like to have. - -The Right Level of Testing -`````````````````````````` - -Ansible resources are models of desired-state. As such, it should not be necessary to test that services are started, packages are -installed, or other such things. Ansible is the system that will ensure these things are declaratively true. Instead, assert these -things in your playbooks. - -.. code-block:: yaml - - tasks: - - ansible.builtin.service: - name: foo - state: started - enabled: true - -If you think the service may not be started, the best thing to do is request it to be started. If the service fails to start, Ansible -will yell appropriately. (This should not be confused with whether the service is doing something functional, which we'll show more about how to -do later). - -.. _check_mode_drift: - -Check Mode As A Drift Test -`````````````````````````` - -In the above setup, ``--check`` mode in Ansible can be used as a layer of testing as well. If running a deployment playbook against an -existing system, using the ``--check`` flag to the `ansible` command will report if Ansible thinks it would have had to have made any changes to -bring the system into a desired state. - -This can let you know up front if there is any need to deploy onto the given system. Ordinarily, scripts and commands don't run in check mode, so if you -want certain steps to execute in normal mode even when the ``--check`` flag is used, such as calls to the script module, disable check mode for those tasks: - -.. code:: yaml - - - roles: - - webserver - - tasks: - - ansible.builtin.script: verify.sh - check_mode: false - -Modules That Are Useful for Testing -``````````````````````````````````` - -Certain playbook modules are particularly good for testing. Below is an example that ensures a port is open: - -.. code:: yaml - - tasks: - - - ansible.builtin.wait_for: - host: "{{ inventory_hostname }}" - port: 22 - delegate_to: localhost - -Here's an example of using the URI module to make sure a web service returns: - -.. code:: yaml - - tasks: - - - action: uri url=https://www.example.com return_content=yes - register: webpage - - - fail: - msg: 'service is not happy' - when: "'AWESOME' not in webpage.content" - -It's easy to push an arbitrary script (in any language) on a remote host and the script will automatically fail if it has a non-zero return code: - -.. code:: yaml - - tasks: - - - ansible.builtin.script: test_script1 - - ansible.builtin.script: test_script2 --parameter value --parameter2 value - -If using roles (you should be, roles are great!), scripts pushed by the script module can live in the 'files/' directory of a role. - -And the assert module makes it very easy to validate various kinds of truth: - -.. code:: yaml - - tasks: - - - ansible.builtin.shell: /usr/bin/some-command --parameter value - register: cmd_result - - - ansible.builtin.assert: - that: - - "'not ready' not in cmd_result.stderr" - - "'gizmo enabled' in cmd_result.stdout" - -Should you feel the need to test for the existence of files that are not declaratively set by your Ansible configuration, the 'stat' module is a great choice: - -.. code:: yaml - - tasks: - - - ansible.builtin.stat: - path: /path/to/something - register: p - - - ansible.builtin.assert: - that: - - p.stat.exists and p.stat.isdir - - -As mentioned above, there's no need to check things like the return codes of commands. Ansible is checking them automatically. -Rather than checking for a user to exist, consider using the user module to make it exist. - -Ansible is a fail-fast system, so when there is an error creating that user, it will stop the playbook run. You do not have -to check up behind it. - -Testing Lifecycle -````````````````` - -If writing some degree of basic validation of your application into your playbooks, they will run every time you deploy. - -As such, deploying into a local development VM and a staging environment will both validate that things are according to plan -ahead of your production deploy. - -Your workflow may be something like this: - -.. code:: text - - - Use the same playbook all the time with embedded tests in development - - Use the playbook to deploy to a staging environment (with the same playbooks) that simulates production - - Run an integration test battery written by your QA team against staging - - Deploy to production, with the same integrated tests. - -Something like an integration test battery should be written by your QA team if you are a production webservice. This would include -things like Selenium tests or automated API tests and would usually not be something embedded into your Ansible playbooks. - -However, it does make sense to include some basic health checks into your playbooks, and in some cases it may be possible to run -a subset of the QA battery against remote nodes. This is what the next section covers. - -Integrating Testing With Rolling Updates -```````````````````````````````````````` - -If you have read into :ref:`playbooks_delegation` it may quickly become apparent that the rolling update pattern can be extended, and you -can use the success or failure of the playbook run to decide whether to add a machine into a load balancer or not. - -This is the great culmination of embedded tests: - -.. code:: yaml - - --- - - - hosts: webservers - serial: 5 - - pre_tasks: - - - name: take out of load balancer pool - ansible.builtin.command: /usr/bin/take_out_of_pool {{ inventory_hostname }} - delegate_to: 127.0.0.1 - - tasks: - - - ansible.builtin.include_role: - name: "{{ item }}" - loop: - - common - - webserver - - - name: run any notified handlers - ansible.builtin.meta: flush_handlers - - - name: test the configuration - ansible.builtin.include_role: - name: apply_testing_checks - - post_tasks: - - - name: add back to load balancer pool - ansible.builtin.command: /usr/bin/add_back_to_pool {{ inventory_hostname }} - delegate_to: 127.0.0.1 - -Of course in the above, the "take out of the pool" and "add back" steps would be replaced with a call to an Ansible load balancer -module or appropriate shell command. You might also have steps that use a monitoring module to start and end an outage window -for the machine. - -However, what you can see from the above is that tests are used as a gate -- if the "apply_testing_checks" step is not performed, -the machine will not go back into the pool. - -Read the delegation chapter about "max_fail_percentage" and you can also control how many failing tests will stop a rolling update -from proceeding. - -This above approach can also be modified to run a step from a testing machine remotely against a machine: - -.. code:: yaml - - --- - - - hosts: webservers - serial: 5 - - pre_tasks: - - - name: take out of load balancer pool - ansible.builtin.command: /usr/bin/take_out_of_pool {{ inventory_hostname }} - delegate_to: 127.0.0.1 - - roles: - - - common - - webserver - - tasks: - - ansible.builtin.script: /srv/qa_team/app_testing_script.sh --server {{ inventory_hostname }} - delegate_to: testing_server - - post_tasks: - - - name: add back to load balancer pool - ansible.builtin.command: /usr/bin/add_back_to_pool {{ inventory_hostname }} - delegate_to: 127.0.0.1 - -In the above example, a script is run from the testing server against a remote node prior to bringing it back into -the pool. - -In the event of a problem, fix the few servers that fail using Ansible's automatically generated -retry file to repeat the deploy on just those servers. - -Achieving Continuous Deployment -``````````````````````````````` - -If desired, the above techniques may be extended to enable continuous deployment practices. - -The workflow may look like this: - -.. code:: text - - - Write and use automation to deploy local development VMs - - Have a CI system like Jenkins deploy to a staging environment on every code change - - The deploy job calls testing scripts to pass/fail a build on every deploy - - If the deploy job succeeds, it runs the same deploy playbook against production inventory - -Some Ansible users use the above approach to deploy a half-dozen or dozen times an hour without taking all of their infrastructure -offline. A culture of automated QA is vital if you wish to get to this level. - -If you are still doing a large amount of manual QA, you should still make the decision on whether to deploy manually as well, but -it can still help to work in the rolling update patterns of the previous section and incorporate some basic health checks using -modules like 'script', 'stat', 'uri', and 'assert'. - -Conclusion -`````````` - -Ansible believes you should not need another framework to validate basic things of your infrastructure is true. This is the case -because Ansible is an order-based system that will fail immediately on unhandled errors for a host, and prevent further configuration -of that host. This forces errors to the top and shows them in a summary at the end of the Ansible run. - -However, as Ansible is designed as a multi-tier orchestration system, it makes it very easy to incorporate tests into the end of -a playbook run, either using loose tasks or roles. When used with rolling updates, testing steps can decide whether to put a machine -back into a load balanced pool or not. - -Finally, because Ansible errors propagate all the way up to the return code of the Ansible program itself, and Ansible by default -runs in an easy push-based mode, Ansible is a great step to put into a build environment if you wish to use it to roll out systems -as part of a Continuous Integration/Continuous Delivery pipeline, as is covered in sections above. - -The focus should not be on infrastructure testing, but on application testing, so we strongly encourage getting together with your -QA team and ask what sort of tests would make sense to run every time you deploy development VMs, and which sort of tests they would like -to run against the staging environment on every deploy. Obviously at the development stage, unit tests are great too. But don't unit -test your playbook. Ansible describes states of resources declaratively, so you don't have to. If there are cases where you want -to be sure of something though, that's great, and things like stat/assert are great go-to modules for that purpose. - -In all, testing is a very organizational and site-specific thing. Everybody should be doing it, but what makes the most sense for your -environment will vary with what you are deploying and who is using it -- but everyone benefits from a more robust and reliable deployment -system. - -.. seealso:: - - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`working_with_playbooks` - An introduction to playbooks - :ref:`playbooks_delegation` - Delegation, useful for working with load balancers, clouds, and locally executed steps. - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/reference_appendices/tower.rst b/docs/docsite/rst/reference_appendices/tower.rst deleted file mode 100644 index 3537d606b1e..00000000000 --- a/docs/docsite/rst/reference_appendices/tower.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. _ansible_platform: - -Red Hat Ansible Automation Platform -=================================== - -.. important:: - - Red Hat Ansible Automation Platform is available on multiple cloud platforms. See `Ansible on Clouds `_ for details. - -`Red Hat Ansible Automation Platform `_ (RHAAP) is an integrated solution for operationalizing Ansible across your team, organization, and enterprise. The platform includes a controller with a web console and REST API, analytics, execution environments, and much more. - -RHAAP gives you role-based access control, including control over the use of securely stored credentials for SSH and other services. You can sync your inventory with a wide variety of cloud sources, and powerful multi-playbook workflows allow you to model complex processes. - -RHAAP logs all of your jobs, integrates well with LDAP, SAML, and other authentication sources, and has an amazing browsable REST API. Command line tools are available for easy integration with Jenkins as well. - -RHAAP incorporates the downstream Red Hat supported product version of Ansible AWX, the downstream Red Hat supported product version of Ansible Galaxy, and multiple SaaS offerings. Find out more about RHAAP features and on the `Red Hat Ansible Automation Platform webpage `_. A Red Hat Ansible Automation Platform subscription includes support from Red Hat, Inc. diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_2_10.rst b/docs/docsite/rst/roadmap/COLLECTIONS_2_10.rst deleted file mode 100644 index 72fdc9cfb3a..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_2_10.rst +++ /dev/null @@ -1,51 +0,0 @@ -==================== -Ansible project 2.10 -==================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-base `_ package as well. All dates are subject to change. See :ref:`base_roadmap_2_10` for the most recent updates on ansible-base. - -.. contents:: - :local: - -Release Schedule ----------------- - -.. note:: Dates subject to change. -.. note:: We plan to post weekly alpha releases to the `PyPI ansible project `_ for testing. - -.. warning:: - We initially were going to have feature freeze on 2020-08-18. We tried this but decided to - change course. Instead, we'll enter feature freeze when ansible-2.10.0 beta1 is released. - -- 2020-06-23: ansible-2.10 alpha freeze. - No net new collections will be added to the ``ansible-2.10`` package after this date. -- 2020-07-10: Ansible collections freeze date for content shuffling. - Content should be in its final collection for the ansible-2.10 series of releases. No more content should move out of the ``community.general`` or ``community.network`` collections. -- 2020-08-13: ansible-base 2.10 Release date, see :ref:`base_roadmap_2_10`. -- 2020-08-14: final ansible-2.10 alpha. -- 2020-09-01: ansible-2.10.0 beta1 and feature freeze. - - - No new modules or major features will be added after this date. In practice this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-1.1.0; ansible-2.10.0 could ship with community-crypto-1.1.1. It would not ship with community-crypto-1.2.0. - -- 2020-09-08: ansible-2.10.0 beta2. -- 2020-09-15: ansible-2.10.0 rc1 and final freeze. - - - After this date only changes blocking a release are accepted. - - Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at the community meeting (on 9-17) to decide whether to bump the version of the collection for a fix. See the `Community meeting agenda `_. - -** Additional release candidates to be published as needed as blockers are fixed ** - -- 2020-09-22: ansible-2.10 GA release date. - -Ansible-2.10.x patch releases will occur roughly every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x. Ansible-2.10.x patch releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed (example: Ansible-2.10 ships with community-crypto-1.1.0; ansible-2.10.1 may ship with community-crypto-1.2.0 but would not ship with community-crypto-2.0.0). - - -.. note:: - - Minor releases will stop when :ref:`Ansible-3 ` is released. See the :ref:`Release and Maintenance Page ` for more information. - - -Breaking changes may be introduced in ansible-3.0 although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before being changed incompatibly. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_3_0.rst b/docs/docsite/rst/roadmap/COLLECTIONS_3_0.rst deleted file mode 100644 index e40d49c0315..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_3_0.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. _ansible_3_roadmap: - -=================== -Ansible project 3.0 -=================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-base `_ package as well. All dates are subject to change. Ansible 3.x.x includes ``ansible-base`` 2.10. See :ref:`base_roadmap_2_10` for the most recent updates on ``ansible-base``. - -.. contents:: - :local: - -Release schedule -================= - -.. note:: - - Ansible is switching from its traditional versioning scheme to `semantic versioning `_ starting with this release. So this version is 3.0.0 instead of 2.11.0. - - - -:2020-12-16: Finalize rules for net-new collections submitted for the ansible release. -:2021-01-27: Final day for new collections to be **reviewed and approved**. They MUST be - submitted prior to this to give reviewers a chance to look them over and for collection owners - to fix any problems. -:2021-02-02: Ansible-3.0.0-beta1 -- feature freeze [1]_ -:2021-02-09: Ansible-3.0.0-rc1 -- final freeze [2]_ [3]_ -:2021-02-16: Release of Ansible-3.0.0 -:2021-03-09: Release of Ansible-3.1.0 (bugfix + compatible features: every three weeks) - -.. [1] No new modules or major features accepted after this date. In practice this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-2.1.0; ansible-3.0.0 could ship with community-crypto-2.1.1. It would not ship with community-crypto-2.2.0. - -.. [2] After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. -.. [3] Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community meeting agenda `_. - - -.. note:: - - Breaking changes may be introduced in Ansible 3.0.0, although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before the breaking change happens. - - -Ansible minor releases -======================= - -Ansible 3.x.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x. Ansible 3.x.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-3.0.0 ships with community-crypto-2.1.0; Ansible-3.1.0 may ship with community-crypto-2.2.0 but would not ship with community-crypto-3.0.0). - - -.. note:: - - Minor releases will stop when :ref:`Ansible-4 ` is released. See the :ref:`Release and Maintenance Page ` for more information. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. - - -ansible-base release -==================== - -Ansible 3.x.x works with ``ansible-base`` 2.10. See :ref:`base_roadmap_2_10` for details. diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_4.rst b/docs/docsite/rst/roadmap/COLLECTIONS_4.rst deleted file mode 100644 index 2bcebb54cbd..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_4.rst +++ /dev/null @@ -1,55 +0,0 @@ -.. _ansible_4_roadmap: - -=================== -Ansible project 4.0 -=================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See :ref:`base_roadmap_2_11` for the most recent updates on ``ansible-core``. - -.. contents:: - :local: - - -Release schedule -================= - - -:2021-01-26: New Collections will be reviewed for inclusion in Ansible 4. Submit a request to include a new collection in this `GitHub Discussion `_. -:2021-03-03: Ansible-4.0.0 alpha1 (biweekly ``ansible`` alphas. These are timed to coincide with the start of the ``ansible-core-2.11`` pre-releases). -:2021-03-16: Ansible-4.0.0 alpha2 -:2021-03-30: Ansible-4.0.0 alpha3 -:2021-04-13: Last day for new collections to be submitted for inclusion in Ansible 4. Note that collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion. -:2021-04-13: Ansible-4.0.0 alpha4 -:2021-04-14: Community Meeting topic: list any new collection reviews which block release. List any backwards incompatible collection releases that beta1 should try to accommodate. -:2021-04-21: Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline. -:2021-04-26: Last day for new collections to be **reviewed and approved** for inclusion in Ansible 4. -:2021-04-26: Last day for collections to make backwards incompatible releases that will be accepted into Ansible 4. -:2021-04-27: Ansible-4.0.0 beta1 -- feature freeze [1]_ (weekly beta releases. Collection owners and interested users should test for bugs). -:2021-05-04: Ansible-4.0.0 beta2 -:2021-05-11: Ansible-4.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed. Test and alert us to any blocker bugs). -:2021-05-18: Ansible-4.0.0 release -:2021-06-08: Release of Ansible-4.1.0 (bugfix + compatible features: every three weeks) - -.. [1] No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-2.1.0; ansible-3.0.0 could ship with community-crypto-2.1.1. It would not ship with community-crypto-2.2.0. - -.. [2] After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. -.. [3] Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a Community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community meeting agenda `_. - - -.. note:: - - Breaking changes will be introduced in Ansible 4.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. - - -Ansible minor releases -======================= - -Ansible 4.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.11.x. Ansible 4.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-4.0.0 ships with community-crypto-2.1.0; Ansible-4.1.0 may ship with community-crypto-2.2.0 but would not ship with community-crypto-3.0.0). - - -.. note:: - - Minor releases will stop when Ansible-5 is released. See the :ref:`Release and Maintenance Page ` for more information. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_5.rst b/docs/docsite/rst/roadmap/COLLECTIONS_5.rst deleted file mode 100644 index 9789cd8b934..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_5.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. _ansible_5_roadmap: - -=================== -Ansible project 5.0 -=================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See :ref:`core_roadmap_2_12` for the most recent updates on ``ansible-core``. - -.. contents:: - :local: - - -Release schedule -================= - -:2021-04-14: New Collections can be reviewed for inclusion in Ansible 5. Submit a request to include a new collection in this `GitHub Discussion `_. -:2021-09-24: ansible-core feature freeze. -:2021-09-27: Start of ansible-core 2.12 betas (weekly, as needed). -:2021-10-05: Ansible-5.0.0 alpha1 (roughly biweekly ``ansible`` alphas timed to coincide with ``ansible-core-2.12`` pre-releases). -:2021-10-12: Last day for new collections to be submitted for inclusion in Ansible-5. Collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion. -:2021-10-13: Community Meeting topic: List any new collection reviews which block release. List any backwards incompatible collection releases that beta1 should try to accommodate. -:2021-10-18: First ansible-core release candidate, stable-2.12 branch created. -:2021-10-19: Ansible-5.0.0 alpha2. -:2021-10-26: Last day for new collections to be **reviewed and approved** for inclusion in Ansible-5. -:2021-10-27: Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline. -:2021-11-02: Ansible-5.0.0 alpha3. -:2021-11-08: Ansible-core-2.12 released. -:2021-11-08: Last day for collections to make backwards incompatible releases that will be accepted into Ansible-5. -:2021-11-09: Create the ansible-build-data directory and files for Ansible-6. New collection approvals will target this. -:2021-11-09: Ansible-5.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs). -:2021-11-16: Ansible-5.0.0 beta2. -:2021-11-23: Ansible-5.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. -:2021-11-30: Ansible-5.0.0 release. -:2021-12-21: Release of Ansible-5.1.0 (bugfix + compatible features: every three weeks.) - -.. [1] No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.1.0; Ansible-5.0.0 could ship with community.crypto 2.1.1. It would not ship with community.crypto 2.2.0. - -.. [2] After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. - -.. [3] Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda `_. - -.. note:: - - Breaking changes will be introduced in Ansible 5.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. - - -Ansible minor releases -======================= - -Ansible 5.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.12.x. Ansible 5.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-5.0.0 ships with community.crypto 2.1.0; Ansible-5.1.0 may ship with community.crypto 2.2.0 but would not ship with community.crypto 3.0.0. - - -.. note:: - - Minor releases will stop when Ansible-6 is released. See the :ref:`Release and Maintenance Page ` for more information. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_6.rst b/docs/docsite/rst/roadmap/COLLECTIONS_6.rst deleted file mode 100644 index 957c989df5f..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_6.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _ansible_6_roadmap: - -=================== -Ansible project 6.0 -=================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See the `ansible-core 2.13 Roadmap `_ for the most recent updates on ``ansible-core``. - -.. contents:: - :local: - - -Release schedule -================= - - -:2022-03-28: ansible-core feature freeze, stable-2.13 branch created. -:2022-04-11: Start of ansible-core 2.13 betas (biweekly, as needed). -:2022-04-12: Ansible-6.0.0 alpha1 (roughly biweekly ``ansible`` alphas timed to coincide with ``ansible-core-2.13`` pre-releases). -:2022-04-27: Community Meeting topic: List any backwards incompatible collection releases that beta1 should try to accommodate. -:2022-05-02: First ansible-core release candidate. -:2022-05-03: Ansible-6.0.0 alpha2. -:2022-05-11: Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline. -:2022-05-16: Ansible-core-2.13 released. -:2022-05-17: Ansible-6.0.0 alpha3. -:2022-05-23: Last day for collections to make backwards incompatible releases that will be accepted into Ansible-6. This includes adding new collections to Ansible 6.0.0; from now on new collections have to wait for 6.1.0 or later. -:2022-05-24: Create the ansible-build-data directory and files for Ansible-7. -:2022-05-24: Ansible-6.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs). -:2022-05-31: Ansible-6.0.0 beta2. -:2022-06-07: Ansible-6.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. -:2022-06-21: Ansible-6.0.0 release. -:2022-07-12: Release of Ansible-6.1.0 (bugfix + compatible features: every three weeks.) - -.. [1] No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-6.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. - -.. [2] After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. - -.. [3] Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda `_. - -.. note:: - - Breaking changes will be introduced in Ansible 6.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. - - -Ansible minor releases -======================= - -Ansible 6.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.13.x. Ansible 6.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-6.0.0 ships with community.crypto 2.3.0; Ansible-6.1.0 may ship with community.crypto 2.4.0 but would not ship with community.crypto 3.0.0. - - -.. note:: - - Minor releases will stop when Ansible-7 is released. See the :ref:`Release and Maintenance Page ` for more information. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. - -Planned work -============ - -More details can be found in `the community-topics planning issue `_. - -* Remove compatibility code which prevents parallel install of Ansible 6 with Ansible 2.9 or ansible-base 2.10 -* Stop installing files (such as tests and development artifacts like editor configs) we have no use for -* Ship Python wheels (as ansible-core 2.13 will likely also do) to improve installation performance diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_7.rst b/docs/docsite/rst/roadmap/COLLECTIONS_7.rst deleted file mode 100644 index dcd9262142b..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_7.rst +++ /dev/null @@ -1,57 +0,0 @@ -.. _ansible_7_roadmap: - -=================== -Ansible project 7.0 -=================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See the `ansible-core 2.14 Roadmap `_ for the most recent updates on ``ansible-core``. - -.. contents:: - :local: - - -Release schedule -================= - - -:2022-09-19: ansible-core feature freeze, stable-2.14 branch created. -:2022-09-26: Start of ansible-core 2.14 betas (biweekly, as needed). -:2022-09-27: Ansible-7.0.0 alpha1 (roughly biweekly ``ansible`` alphas timed to coincide with ``ansible-core-2.14`` pre-releases). -:2022-10-12: Community topic: List any backwards incompatible collection releases that beta1 should try to accommodate. -:2022-10-17: First ansible-core 2.14 release candidate. -:2022-10-25: Ansible-7.0.0 alpha2. -:2022-10-26: Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline. -:2022-11-07: Ansible-core-2.14.0 released. -:2022-11-07: Last day for collections to make backwards incompatible releases that will be accepted into Ansible-7. This includes adding new collections to Ansible 7.0.0; from now on new collections have to wait for 7.1.0 or later. -:2022-11-08: Create the ansible-build-data directory and files for Ansible-8. -:2022-11-08: Ansible-7.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs). -:2022-11-15: Ansible-7.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. -:2022-11-18: Last day to trigger an Ansible-7.0.0rc2 release because of major defects in Ansible-7.0.0rc1. -:2022-11-22: Ansible-7.0.0rc2 when necessary, otherwise Ansible-7.0.0 release. -:2022-11-29: Ansible-7.0.0 release when Ansible-7.0.0rc2 was necessary. -:2022-12-05: Release of ansible-core 2.14.1. -:2022-12-06: Release of Ansible-7.1.0 (bugfix + compatible features: every four weeks.) - -.. [1] No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-7.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. - -.. [2] After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. - -.. [3] Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda `_. - -.. note:: - - Breaking changes will be introduced in Ansible 7.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. - - -Ansible minor releases -======================= - -Ansible 7.x minor releases will occur approximately every four weeks if changes to collections have been made or to align to a later ansible-core-2.14.x. Ansible 7.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-7.0.0 ships with community.crypto 2.3.0; Ansible-7.1.0 may ship with community.crypto 2.4.0 but would not ship with community.crypto 3.0.0. - - -.. note:: - - Minor releases will stop when Ansible-8 is released. See the :ref:`Release and Maintenance Page ` for more information. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_8.rst b/docs/docsite/rst/roadmap/COLLECTIONS_8.rst deleted file mode 100644 index 90713603ec4..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_8.rst +++ /dev/null @@ -1,55 +0,0 @@ -.. _ansible_8_roadmap: - -=================== -Ansible project 8.0 -=================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See the `ansible-core 2.15 Roadmap `_ for the most recent updates on ``ansible-core``. - -.. contents:: - :local: - - -Release schedule -================= - - -:2023-03-31: ansible-core feature freeze, stable-2.15 branch created. -:2023-04-03: Start of ansible-core 2.15 betas (biweekly, as needed). -:2023-04-04: Ansible-8.0.0 alpha1 (roughly biweekly ``ansible`` alphas timed to coincide with ``ansible-core-2.15`` pre-releases). -:2023-04-24: First ansible-core 2.15 release candidate. -:2023-05-02: Another Ansible-8.0.0 alpha release. -:2023-05-15: Ansible-core-2.15.0 released. -:2023-05-15: Last day for collections to make backwards incompatible releases that will be accepted into Ansible-8. This includes adding new collections to Ansible 8.0.0; from now on new collections have to wait for 8.1.0 or later. -:2023-05-16: Ansible-8.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs). -:2023-05-23: Ansible-8.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. -:2023-05-26: Last day to trigger an Ansible-8.0.0rc2 release because of major defects in Ansible-8.0.0rc1. -:2023-05-30: Ansible-8.0.0rc2 when necessary, otherwise Ansible-8.0.0 release. -:2023-06-06: Ansible-8.0.0 release when Ansible-8.0.0rc2 was necessary. -:2023-05-30 or 2023-06-06: Create the ansible-build-data directory and files for Ansible-9. -:2023-06-20: Release of ansible-core 2.15.1. -:2023-06-22: Release of Ansible-8.1.0 (bugfix + compatible features: every four weeks.) - -.. [1] No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-8.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. - -.. [2] After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. - -.. [3] Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda `_. - -.. note:: - - Breaking changes will be introduced in Ansible 8.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. - - -Ansible minor releases -======================= - -Ansible 8.x minor releases will occur approximately every four weeks if changes to collections have been made or to align to a later ansible-core-2.15.x. Ansible 8.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-8.0.0 ships with community.crypto 2.3.0; Ansible-8.1.0 may ship with community.crypto 2.4.0 but would not ship with community.crypto 3.0.0. - - -.. note:: - - Minor and patch releases will stop when Ansible-9 is released. See the :ref:`Release and Maintenance Page ` for more information. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_9.rst b/docs/docsite/rst/roadmap/COLLECTIONS_9.rst deleted file mode 100644 index 5fc6c4ef4e6..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_9.rst +++ /dev/null @@ -1,66 +0,0 @@ -.. _ansible_9_roadmap: - -=================== -Ansible project 9.0 -=================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See the `ansible-core 2.16 Roadmap `_ for the most recent updates on ``ansible-core``. - -.. contents:: - :local: - - -Release schedule -================= - - -:2023-09-18: ansible-core feature freeze, stable-2.16 branch created. -:2023-09-25: Start of ansible-core 2.16 betas -:2023-09-26: Ansible-9.0.0 alpha1 (roughly (bi-)weekly ``ansible`` alphas timed to coincide with ``ansible-core-2.16`` pre-releases). -:2023-10-16: First ansible-core 2.16 release candidate. -:2023-10-24/31: Another Ansible-9.0.0 alpha release. -:2023-11-06: Ansible-core-2.16.0 released. -:2023-11-06: Last day for collections to make backwards incompatible releases that will be accepted into Ansible-9. This includes adding new collections to Ansible 9.0.0; from now on new collections have to wait for 9.1.0 or later. -:2023-11-07: Ansible-9.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs). -:2023-11-14: Ansible-9.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. -:2023-11-17: Last day to trigger an Ansible-9.0.0rc2 release because of major defects in Ansible-9.0.0rc1. -:2023-11-21: Ansible-9.0.0rc2 when necessary, otherwise Ansible-9.0.0 release. -:2023-11-28: Ansible-9.0.0 release when Ansible-9.0.0rc2 was necessary. -:2023-11-21 or 2023-11-28: Create the ansible-build-data directory and files for Ansible-10. -:2023-12-04: Release of ansible-core 2.16.1. -:2023-12-05: Release of Ansible-9.1.0 (bugfix + compatible features: every four weeks.) - -.. [1] No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-9.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. - -.. [2] After this date only changes blocking a release are accepted. Accepted changes require creating a new release candidate and may slip the final release date. - -.. [3] Collections will be updated to a new version only if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda `_. - -.. note:: - - Breaking changes will be introduced in Ansible 9.0.0. We encourage the use of deprecation periods that give advance notice of breaking changes at least one Ansible release before they are introduced. However, deprecation notices are not guaranteed to take place. - - -Planned major changes -===================== - -- The cisco.nso collection will be removed as it is unmaintained (https://github.com/ansible-community/ansible-build-data/issues/190). -- The community.fortios collection will be removed as it is unmaintained (https://github.com/ansible-community/ansible-build-data/issues/196). -- The community.google collection will be removed as it is unmaintained (https://github.com/ansible-community/ansible-build-data/issues/198). -- The community.skydive collection will be removed as it is unmaintained (https://github.com/ansible-community/ansible-build-data/issues/199). - -You can install removed collections manually with ``ansible-galaxy collection install ``. - - -Ansible minor releases -======================= - -Ansible 9.x minor releases will occur approximately every four weeks if changes to collections have been made or to align to a later ansible-core-2.16.x. Ansible 9.x minor releases may contain new features (including new collections) but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-9.0.0 ships with community.crypto 2.3.0; Ansible-9.1.0 could ship with community.crypto 2.4.0 but not community.crypto 3.0.0. - - -.. note:: - - Minor and patch releases will stop when Ansible-10 is released. See the :ref:`Release and Maintenance Page ` for more information. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_10.rst b/docs/docsite/rst/roadmap/ROADMAP_2_10.rst deleted file mode 100644 index d303ca4682c..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_10.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. _base_roadmap_2_10: - -================= -Ansible-base 2.10 -================= - -.. contents:: - :local: - -Release Schedule ----------------- - -Expected -======== - -PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-base release. - -.. note:: There is no Alpha phase in 2.10. -.. note:: Dates subject to change. - -- 2020-06-16 Beta 1 **Feature freeze** - No new functionality (including modules/plugins) to any code - -- 2020-07-21 Release Candidate 1 (bumped from 2020-07-14) -- 2020-07-24 Release Candidate 2 -- 2020-07-25 Release Candidate 3 -- 2020-07-30 Release Candidate 4 -- 2020-08-13 Release - -Release Manager ---------------- - -@sivel - -Planned work -============ - -- Migrate non-base plugins and modules from the ``ansible/ansible`` repository to smaller collection repositories -- Add functionality to ease transition to collections, such as automatic redirects from the 2.9 names to the new FQCN of the plugin -- Create new ``ansible-base`` package representing the ``ansible/ansible`` repository - -Additional Resources -==================== - -The 2.10 release of Ansible will fundamentally change the scope of plugins included in the ``ansible/ansible`` repository, by -moving much of the plugins into smaller collection repositories that will be shipped through https://galaxy.ansible.com/ - -The following links have more information about this process: - -- https://groups.google.com/d/msg/ansible-devel/oKqgCeYTs-M/cHrOgMw8CAAJ -- https://github.com/ansible-collections/overview/blob/main/README.rst diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_11.rst b/docs/docsite/rst/roadmap/ROADMAP_2_11.rst deleted file mode 100644 index 3fa3b6bab5f..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_11.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. _base_roadmap_2_11: - -================= -Ansible-core 2.11 -================= - -.. contents:: - :local: - -Release Schedule ----------------- - -Expected -======== - -PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. - -.. note:: There is no Alpha phase in 2.11. -.. note:: Dates subject to change. - -- 2021-02-12 Feature Freeze - No new functionality (including modules/plugins) to any code - -- 2021-03-02 Beta 1 -- 2021-03-15 Beta 2 (if necessary) - -- 2021-03-29 Release Candidate 1 (and ``stable-2.11`` branching from ``devel``) -- 2021-04-12 Release Candidate 2 (if necessary) - -- 2021-04-26 Release - -Release Manager ---------------- - - Ansible Core Team - -Planned work -============ - -- Rename ``ansible-base`` to ``ansible-core``. -- Improve UX of ``ansible-galaxy collection`` CLI, specifically as it relates to install and upgrade. -- Add new Role Argument Spec feature that will allow a role to define an argument spec to be used in - validating variables used by the role. -- Bump the minimum Python version requirement for the controller to Python 3.8. There will be no breaking changes - to this release, however ``ansible-core`` will only be packaged for Python 3.8+. ``ansible-core==2.12`` will include - breaking changes requiring at least Python 3.8. -- Introduce split-controller testing in ``ansible-test`` to separate dependencies for the controller from - dependencies on the target. diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_12.rst b/docs/docsite/rst/roadmap/ROADMAP_2_12.rst deleted file mode 100644 index c0a7ccdbdc8..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_12.rst +++ /dev/null @@ -1,50 +0,0 @@ -.. _core_roadmap_2_12: - -================= -Ansible-core 2.12 -================= - -.. contents:: - :local: - -Release Schedule ----------------- - -Expected -======== - -PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. - -.. note:: There is no Alpha phase in 2.12. -.. note:: Dates subject to change. - -- 2021-09-24 Feature Freeze (and ``stable-2.12`` branching from ``devel``) - No new functionality (including modules/plugins) to any code - -- 2021-09-27 Beta 1 -- 2021-10-04 Beta 2 (if necessary) - -- 2021-10-18 Release Candidate 1 -- 2021-10-25 Release Candidate 2 (if necessary) - -- 2021-11-08 Release - -Release Manager ---------------- - - Ansible Core Team - -Planned work -============ - -- Bump the minimum Python version requirement for the controller to Python 3.8. This will be a hard requirement. -- Deprecate Python 2.6 support for managed/target hosts. The release of ``ansible-core==2.13`` will remove Python 2.6 support. -- Introduce split-controller testing in ``ansible-test`` to separate dependencies for the controller from dependencies on the target. -- Extend the functionality of ``module_defaults`` ``action_groups`` to be created and presented by collections. - -Delayed work -============ - -The following work has been delayed and retargeted for a future release - -- Implement object proxies, to expose restricted interfaces between parts of the code, and enable deprecations of attributes and variables. diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_13.rst b/docs/docsite/rst/roadmap/ROADMAP_2_13.rst deleted file mode 100644 index 00b994a5706..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_13.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _core_roadmap_2_13: - -***************** -Ansible-core 2.13 -***************** - -.. contents:: - :local: - -Release Schedule -================ - -Expected --------- - -PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. - -.. note:: There is no Alpha phase in 2.13. -.. note:: Dates subject to change. - -Development Phase -^^^^^^^^^^^^^^^^^ - -The ``milestone`` branch will be advanced at the start date of each development phase. - -- 2021-09-27 Development Phase 1 -- 2021-12-13 Development Phase 2 -- 2022-02-14 Development Phase 3 - -Release Phase -^^^^^^^^^^^^^ - -- 2022-03-28 Feature Freeze (and ``stable-2.13`` branching from ``devel``) - No new functionality (including modules/plugins) to any code - -- 2022-04-11 Beta 1 -- 2022-04-25 Beta 2 (if necessary) - -- 2022-05-02 Release Candidate 1 - -- 2022-05-16 Release - -Release Manager -=============== - - Ansible Core Team - -Planned work -============ - -* ``ansible-doc`` extended dump support for devtools integration -* ``ansible-galaxy`` CLI collection verification, source, and trust -* ``jinja2`` 3.0+ dependency -* Consolidate template handling to always use ``jinja2`` native -* Drop Python 2.6 support for module execution -* Update the collection loader to Python 3.x loader API, due to removal of the Python 2 API in Python 3.12 -* Modernize python packaging and installation - -Delayed work -============ - -The following work has been delayed and retargeted for a future release - -* Data Tagging -* Implement sidecar docs to support documenting filter/test plugins, as well as non Python modules diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_14.rst b/docs/docsite/rst/roadmap/ROADMAP_2_14.rst deleted file mode 100644 index 0f0bbea8219..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_14.rst +++ /dev/null @@ -1,63 +0,0 @@ -.. _core_roadmap_2.14: - -***************** -Ansible-core 2.14 -***************** - -.. contents:: - :local: - -Release Schedule -================ - -Expected --------- - -PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. - -.. note:: Dates subject to change. - -Development Phase -^^^^^^^^^^^^^^^^^ - -The ``milestone`` branch will be advanced at the start date of each development phase. - -- 2022-05-02 Development Phase 1 -- 2022-06-27 Development Phase 2 -- 2022-08-08 Development Phase 3 - -Release Phase -^^^^^^^^^^^^^ - -- 2022-09-19 Feature Freeze (and ``stable-2.14`` branching from ``devel``) - No new functionality (including modules/plugins) to any code - -- 2022-09-26 Beta 1 - -- 2022-10-17 Release Candidate 1 - -- 2022-11-07 Release - -.. note:: The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. - -Release Manager -=============== - - Ansible Core Team - -Planned work -============ - -* Implement sidecar docs to support documenting filter/test plugins, as well as non Python modules -* Proxy Display over queue from forks -* Move handler processing into new PlayIterator phase to use the configured strategy -* Convert FieldAttribute to data descriptors to avoid complex meta classes -* Drop Python 3.8 support for controller -* Enforce running controller code with the Python locale and filesystem encoding set to UTF-8 - -Delayed work -============ - -The following work has been delayed and retargeted for a future release: - -* Data Tagging diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_15.rst b/docs/docsite/rst/roadmap/ROADMAP_2_15.rst deleted file mode 100644 index 30ad8c775c5..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_15.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. _core_roadmap_2.15: - -***************** -Ansible-core 2.15 -***************** - -.. contents:: - :local: - -Release Schedule -================ - -Expected --------- - -PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. - -.. note:: Dates subject to change. - -Development Phase -^^^^^^^^^^^^^^^^^ - -The ``milestone`` branch will be advanced at the start date of each development phase. - -- 2022-10-17 Development Phase 1 -- 2022-12-19 Development Phase 2 -- 2023-02-20 Development Phase 3 - -Release Phase -^^^^^^^^^^^^^ - -- 2023-03-31 Feature Freeze (and ``stable-2.15`` branching from ``devel``) - No new functionality (including modules/plugins) to any code - -- 2023-04-03 Beta 1 - -- 2023-04-24 Release Candidate 1 - -- 2023-05-15 Release - -.. note:: The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. - -Release Manager -=============== - - Ansible Core Team - -Planned work -============ - -* Proxy prompting over queue from forks - -Delayed work -============ - -The following work has been delayed and retargeted for a future release: - -* Data Tagging diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_16.rst b/docs/docsite/rst/roadmap/ROADMAP_2_16.rst deleted file mode 100644 index 42614f46d7b..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_16.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. _core_roadmap_2.16: - -***************** -Ansible-core 2.16 -***************** - -.. contents:: - :local: - -Release Schedule -================ - -Expected --------- - -PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. - -.. note:: Dates subject to change. - -Development Phase -^^^^^^^^^^^^^^^^^ - -The ``milestone`` branch will be advanced at the start date of each development phase. - -- 2023-05-01 Development Phase 1 -- 2023-06-26 Development Phase 2 -- 2023-08-07 Development Phase 3 - -Release Phase -^^^^^^^^^^^^^ - -- 2023-09-18 Feature Freeze (and ``stable-2.16`` branching from ``devel``) - No new functionality (including modules/plugins) to any code - -- 2023-09-25 Beta 1 - -- 2023-10-16 Release Candidate 1 - -- 2023-11-06 Release - -.. note:: The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. - -Release Manager -=============== - - Ansible Core Team - -Planned work -============ - -* Data Tagging -* Drop Python 3.5 support for module execution -* Drop Python 3.9 support for controller -* Add support to ``ansible-doc`` for collections to declare new plugin types -* Preserve display context when proxying display over the queue -* Update ``TaskExecutor`` to not unnecessarily establish persistent ``ansible-connection`` when not needed -* Remove deprecated functionality -* Decrease incidental integration tests -* Add controller type hinting for descrete areas of the code -* Decrease testing sanity ignores -* Update ansible-test container images and VMs -* Update ansible-test dependencies - -Delayed work -============ - -The following work has been delayed and retargeted for a future release: - - diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_5.rst b/docs/docsite/rst/roadmap/ROADMAP_2_5.rst deleted file mode 100644 index 802a4790f1d..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_5.rst +++ /dev/null @@ -1,142 +0,0 @@ -=========== -Ansible 2.5 -=========== -**Core Engine Freeze and Module Freeze: 22 January 2018** - -**Core and Curated Module Freeze: 22 January 2018** - -**Community Module Freeze: 7 February 2018** - -**Release Candidate 1 will be 21 February, 2018** - -**Target: March 2018** - -**Service Release schedule: every 2-3 weeks** - -.. contents:: Topics - -Release Manager ---------------- -Matt Davis (IRC/GitHub: @nitzmahone) - - -Engine improvements -------------------- -- Assemble module improvements - - assemble just skips when in check mode, it should be able to test if there is a difference and changed=true/false. - - The same with diff, it should work as template modules does -- Handle Password reset prompts cleaner -- Tasks stats for rescues and ignores -- Normalize temp dir usage across all subsystems -- Add option to set playbook dir for adhoc, inventory and console to allow for 'relative path loading' - - -Ansible-Config --------------- -- Extend config to more plugin types and update plugins to support the new config - -Inventory ---------- -- ansible-inventory option to output group variable assignment and data (--export) -- Create inventory plugins for: - - aws - -Facts ------ -- Namespacing fact variables (via a config option) implemented in ansible/ansible PR `#18445 `_. - Proposal found in ansible/proposals issue `#17 `_. -- Make fact collectors and gather_subset specs finer grained -- Eliminate unneeded deps between fact collectors -- Allow fact collectors to indicate if they need information from another fact collector to be gathered first. - -Static Loop Keyword -------------------- - -- A simpler alternative to ``with_``, ``loop:`` only takes a list -- Remove complexity from loops, lookups are still available to users -- Less confusing having a static directive vs a one that is dynamic depending on plugins loaded. - -Vault ------ -- Vault secrets client inc new 'keyring' client - -Runtime Check on Modules for Disabling --------------------------------------- -- Filter on things like "supported_by" in module metadata -- Provide users with an option of "warning, error or allow/ignore" -- Configurable via ansible.cfg and environment variable - -Windows -------- -- Implement gather_subset on Windows facts -- Fix Windows async + become to allow them to work together -- Implement Windows become flags for controlling various modes **(done)** - - logontype - - elevation behavior -- Convert win_updates to action plugin for auto reboot and extra features **(done)** -- Spike out changing the connection over to PSRP instead of WSMV **(done- it's possible)** -- Module updates - - - win_updates **(done)** - - - Fix win_updates to detect (or request) become - - Add enable/disable features to win_updates - - win_dsc further improvements **(done)** - -General Cloud -------------- -- Make multi-cloud provisioning easier -- Diff mode will output provisioning task results of ansible-playbook runs -- Terraform module - -AWS ---- -- Focus on pull requests for various modules -- Triage existing merges for modules -- Module work - - - ec2_instance - - ec2_vpc: Allow the addition of secondary IPv4 CIDRS to existing VPCs. - - AWS Network Load Balancer support (NLB module, ASG support, and so on) - - rds_instance - -Azure ------ -- Azure CLI auth **(done)** -- Fix Azure module results to have "high-level" output instead of raw REST API dictionary **(partial, more to come in 2.6)** -- Deprecate Azure automatic storage accounts in azure_rm_virtualmachine **(breaks on Azure Stack, punted until AS supports managed disks)** - -Network Roadmap ---------------- -- Refactor common network shared code into package **(done)** -- Convert various nxos modules to use declarative intent **(done)** -- Refactor various modules to use the cliconf plugin **(done)** -- Add various missing declarative modules for supported platforms and functions **(done)** -- Implement a feature that handles platform differences and feature unavailability **(done)** -- netconf-config.py should provide control for deployment strategy -- Create netconf connection plugin **(done)** -- Create netconf fact module -- Turn network_cli into a usable connection type **(done)** -- Implements jsonrpc message passing for ansible-connection **(done)** -- Improve logging for ansible-connection **(done)** -- Improve stdout output for failures whilst using persistent connection **(done)** -- Create IOS-XR NetConf Plugin and refactor iosxr modules to use netconf plugin **(done)** -- Refactor junos modules to use netconf plugin **(done)** -- Filters: Add a filter to convert XML response from a network device to JSON object **(done)** - -Documentation -------------- -- Extend documentation to more plugins -- Document vault-password-client scripts. -- Network Documentation - - - New landing page (to replace intro_networking) **(done)** - - Platform specific guides **(done)** - - Walk through: Getting Started **(done)** - - Networking and ``become`` **(done)** - - Best practice **(done)** - -Contributor Quality of Life ---------------------------- -- Finish PSScriptAnalyer integration with ansible-test (for enforcing Powershell style) **(done)** -- Resolve issues requiring skipping of some integration tests on Python 3. diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_6.rst b/docs/docsite/rst/roadmap/ROADMAP_2_6.rst deleted file mode 100644 index 7d8226e2097..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_6.rst +++ /dev/null @@ -1,82 +0,0 @@ -=========== -Ansible 2.6 -=========== - -.. contents:: Topics - -Release Schedule ----------------- - -Actual -====== - -- 2018-05-17 Core Freeze (Engine and Core Modules/Plugins) -- 2018-05-21 Alpha Release 1 -- 2018-05-25 Community Freeze (Non-Core Modules/Plugins) -- 2018-05-25 Branch stable-2.6 -- 2018-05-30 Alpha Release 2 -- 2018-06-05 Release Candidate 1 -- 2018-06-08 Release Candidate 2 -- 2018-06-18 Release Candidate 3 -- 2018-06-25 Release Candidate 4 -- 2018-06-26 Release Candidate 5 -- 2018-06-28 Final Release - - -Release Manager ---------------- -* 2.6.0-2.6.12 Matt Clay (IRC/GitHub: @mattclay) -* 2.6.13+ Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger) - - -Engine improvements -------------------- - -- Version 2.6 is largely going to be a stabilization release for Core code. -- Some of the items covered in this release, but are not limited to are the following: - - - ``ansible-inventory`` - - ``import_*`` - - ``include_*`` - - Test coverage - - Performance Testing - -Core Modules ------------- -- Adopt-a-module Campaign - - - Review current status of all Core Modules - - Reduce backlog of open issues against these modules - -Cloud Modules -------------- - -Network -------- - -Connection work -================ - -* New connection plugin: eAPI `proposal#102 `_ -* New connection plugin: NX-API -* Support for configurable options for network_cli & netconf - -Modules -======= - -* New ``net_get`` - platform independent module for pulling configuration via SCP/SFTP over network_cli -* New ``net_put`` - platform independent module for pushing configuration via SCP/SFTP over network_cli -* New ``netconf_get`` - Netconf module to fetch configuration and state data `proposal#104 `_ - -Other Features -================ - -* Stretch & tech preview: Configuration caching for network_cli. Opt-in feature to avoid ``show running`` performance hit - - -Windows -------- - - - - diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_7.rst b/docs/docsite/rst/roadmap/ROADMAP_2_7.rst deleted file mode 100644 index bf65dcf79fd..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_7.rst +++ /dev/null @@ -1,109 +0,0 @@ -=========== -Ansible 2.7 -=========== - -.. contents:: Topics - -Release Schedule ----------------- - -Expected -======== - -- 2018-08-23 Core Freeze (Engine and Core Modules/Plugins) -- 2018-08-23 Alpha Release 1 -- 2018-08-30 Community Freeze (Non-Core Modules/Plugins) -- 2018-08-30 Beta Release 1 -- 2018-09-06 Release Candidate 1 (If needed) -- 2018-09-13 Release Candidate 2 (If needed) -- 2018-09-20 Release Candidate 3 (If needed) -- 2018-09-27 Release Candidate 4 (If needed) -- 2018-10-04 General Availability - -Release Manager ---------------- -Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger) - - -Cleaning Duty -------------- - -- Drop Py2.6 for controllers `Docs PR #42971 `_ and - `issue #42972 `_ -- Remove dependency on simplejson `issue #42761 `_ - - -Engine Improvements -------------------- - -- Performance improvement invoking Python modules `pr #41749 `_ -- Jinja native types will allow for users to render a Python native type. `pr #32738 `_ - - -Core Modules ------------- - -- Include feature changes and improvements - - - Create new argument ``apply`` that will allow for included tasks to inherit explicitly provided attributes. `pr #39236 `_ - - Create "private" functionality for allowing vars/default to be exposed outside of roles. `pr #41330 `_ -- Provide a parameter for the ``template`` module to output to different encoding formats `pr - #42171 `_ -- ``reboot`` module for Linux hosts (@samdoran) `pr #35205 `_ - -Cloud Modules -------------- - -General -======= -* Cloud auth plugin `proposal #24 `_ - -AWS -=== -* Inventory plugin for RDS `pr #41919 `_ -* Count support for `ec2_instance` -* `aws_eks` module `pr #41183 `_ -* Cloudformation stack sets support (`PR#41669 `_) -* RDS instance and snapshot modules `pr #39994 `_ `pr #43789 `_ -* Diff mode improvements for cloud modules `pr #44533 `_ - -Azure -===== - -* Azure inventory plugin `issue #42769 `__ - - -Network -------- - -General -======= - -* Refactor the APIs in cliconf (`issue #39056 `_) and netconf (`issue #39160 `_) plugins so that they have a uniform signature across supported network platforms. **done** - (`PR #41846 `_) (`PR #43643 `_) (`PR #43837 `_) - (`PR #43203 `_) (`PR #42300 `_) (`PR #44157 `_) - -Modules -======= - -* New ``cli_config`` module `issue #39228 `_ **done** `PR #42413 `_. -* New ``cli_command`` module `issue #39284 `_ -* Refactor ``netconf_config`` module to add additional functionality. **done** `proposal #104 `_ (`PR #44379 `_) - -Windows -------- - -General -======= - -* Added new connection plugin that uses PSRP as the connection protocol `pr #41729 `__ - -Modules -======= - -* Revamp Chocolatey to fix bugs and support offline installation `pr #43013 `_. -* Add Chocolatey modules that can manage the following Chocolatey features - - * `Sources `_ `pr #42790 `_ - * `Features `_ `pr #42848 `_ - * `Config `_ `pr #42915 `_ diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_8.rst b/docs/docsite/rst/roadmap/ROADMAP_2_8.rst deleted file mode 100644 index 04977aa7358..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_8.rst +++ /dev/null @@ -1,38 +0,0 @@ -=========== -Ansible 2.8 -=========== - -.. contents:: - :local: - -Release Schedule ----------------- - -Expected -======== - -PRs must be raised well in advance of the dates below to have a chance of being included in this Ansible release. - -- 2019-04-04 Alpha 1 **Core freeze** - No new features to ``support:core`` code. - Includes no new options to existing Core modules - -- 2019-04-11 Beta 1 **Feature freeze** - No new functionality (including modules/plugins) to any code - -- 2019-04-25 Release Candidate 1 -- 2019-05-02 Release Candidate 2 -- 2019-05-10 Release Candidate 3 -- 2019-05-16 Release - - - -Release Manager ---------------- - -Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger) - -Planned work -============ - -See the `Ansible 2.8 Project Board `_ diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_9.rst b/docs/docsite/rst/roadmap/ROADMAP_2_9.rst deleted file mode 100644 index 370930ac137..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_9.rst +++ /dev/null @@ -1,39 +0,0 @@ -=========== -Ansible 2.9 -=========== - -.. contents:: - :local: - -Release Schedule ----------------- - -Expected -======== - -PRs must be raised well in advance of the dates below to have a chance of being included in this Ansible release. - -.. note:: There is no Alpha phase in 2.9. - -- 2019-08-29 Beta 1 **Feature freeze** - No new functionality (including modules/plugins) to any code - -- 2019-09-19 Release Candidate 1 -- 2019-10-03 Release Candidate 2 -- 2019-10-10 Release Candidate 3 -- 2019-10-17 Release Candidate 4 (if needed) -- 2019-10-24 Release Candidate 5 (if needed) -- 2019-10-31 Release - - - -Release Manager ---------------- -TBD - -Temporarily, Matt Davis (@nitzmahone) or Matt Clay (@mattclay) on IRC or github. - -Planned work -============ - -See the `Ansible 2.9 Project Board `_ diff --git a/docs/docsite/rst/roadmap/ansible_core_roadmap_index.rst b/docs/docsite/rst/roadmap/ansible_core_roadmap_index.rst deleted file mode 100644 index 3712ebec4e3..00000000000 --- a/docs/docsite/rst/roadmap/ansible_core_roadmap_index.rst +++ /dev/null @@ -1,34 +0,0 @@ -.. _roadmaps: -.. _ansible_core_roadmaps: - -ansible-core Roadmaps -===================== - -The ``ansible-core`` team develops a roadmap for each major and minor ``ansible-core`` release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.10 and 2.11 have roadmaps, but 2.10.1 does not. - -We incorporate team and community feedback in each roadmap, and aim for further transparency and better inclusion of both community desires and submissions. - -Each roadmap offers a *best guess*, based on the ``ansible-core`` team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, and so on. - -Each roadmap is published both as an idea of what is upcoming in ``ansible-core``, and as a medium for seeking further feedback from the community. - -You can submit feedback on the current roadmap in multiple ways: - -- Edit the agenda of an `Core Team Meeting `_ (preferred) -- Post on the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) -- Email the ansible-devel list - -See :ref:`Ansible communication channels ` for details on how to join and use the email lists and chat channels. - -.. toctree:: - :maxdepth: 1 - :glob: - :caption: ansible-core Roadmaps - - ROADMAP_2_16 - ROADMAP_2_15 - ROADMAP_2_14 - ROADMAP_2_13 - ROADMAP_2_12 - ROADMAP_2_11 - ROADMAP_2_10 diff --git a/docs/docsite/rst/roadmap/ansible_roadmap_index.rst b/docs/docsite/rst/roadmap/ansible_roadmap_index.rst deleted file mode 100644 index 5b3d72e0566..00000000000 --- a/docs/docsite/rst/roadmap/ansible_roadmap_index.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. _roadmaps: -.. _ansible_roadmaps: - -Ansible Roadmap -=============== - -The Ansible team develops a roadmap for each major and minor Ansible release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.10 and 2.11 have roadmaps, but 2.10.1 does not. - -We incorporate team and community feedback in each roadmap, and aim for further transparency and better inclusion of both community desires and submissions. - -Each roadmap offers a *best guess*, based on the Ansible team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, and so on. - -Each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community. - -You can submit feedback on the current roadmap in multiple ways: - -- Edit the agenda of an `Ansible Community Meeting `_ (preferred) -- Post on the ``#ansible-community`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) - -See :ref:`Ansible communication channels ` for details on how to join and use our chat channels. - -.. toctree:: - :maxdepth: 1 - :glob: - :caption: Ansible Release Roadmaps - - COLLECTIONS_9 - COLLECTIONS_8 - COLLECTIONS_7 - COLLECTIONS_6 - COLLECTIONS_5 - COLLECTIONS_4 - COLLECTIONS_3_0 - COLLECTIONS_2_10 - old_roadmap_index diff --git a/docs/docsite/rst/roadmap/index.rst b/docs/docsite/rst/roadmap/index.rst deleted file mode 100644 index 0b5b4bd11b6..00000000000 --- a/docs/docsite/rst/roadmap/index.rst +++ /dev/null @@ -1,12 +0,0 @@ -.. _roadmaps: - -Roadmaps -=============== - -.. toctree:: - :maxdepth: 1 - :glob: - - ansible_roadmap_index - ansible_core_roadmap_index - old_roadmap_index diff --git a/docs/docsite/rst/roadmap/old_roadmap_index.rst b/docs/docsite/rst/roadmap/old_roadmap_index.rst deleted file mode 100644 index 78769f17584..00000000000 --- a/docs/docsite/rst/roadmap/old_roadmap_index.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. _old_roadmaps: - -Older Roadmaps -=============== - -Older roadmaps are listed here to provide a history of the Ansible project. - -See :ref:`roadmaps` to find current Ansible and ``ansible-base`` roadmaps. - -.. toctree:: - :maxdepth: 1 - :glob: - :caption: Older Roadmaps - - ROADMAP_2_9 - ROADMAP_2_8 - ROADMAP_2_7 - ROADMAP_2_6 - ROADMAP_2_5 diff --git a/docs/docsite/rst/scenario_guides/cloud_guides.rst b/docs/docsite/rst/scenario_guides/cloud_guides.rst deleted file mode 100644 index a0e6e8ed975..00000000000 --- a/docs/docsite/rst/scenario_guides/cloud_guides.rst +++ /dev/null @@ -1,25 +0,0 @@ -.. _cloud_guides: - -************************** -Legacy Public Cloud Guides -************************** - -The legacy guides in this section may be out of date. They cover using Ansible with a range of public cloud platforms. They explore particular use cases in greater depth and provide a more "top-down" explanation of some basic features. - -Guides for using public clouds are moving into collections. We are migrating these guides into collections. Please update your links for the following guides: - -:ref:`ansible_collections.amazon.aws.docsite.aws_intro` - -.. toctree:: - :maxdepth: 1 - - guide_alicloud - guide_cloudstack - guide_gce - guide_azure - guide_online - guide_oracle - guide_packet - guide_rax - guide_scaleway - guide_vultr diff --git a/docs/docsite/rst/scenario_guides/guide_aci.rst b/docs/docsite/rst/scenario_guides/guide_aci.rst deleted file mode 100644 index c7e12d809b1..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_aci.rst +++ /dev/null @@ -1,659 +0,0 @@ -.. _aci_guide: - -Cisco ACI Guide -=============== - - -.. _aci_guide_intro: - -What is Cisco ACI ? -------------------- - -Application Centric Infrastructure (ACI) -........................................ -The Cisco Application Centric Infrastructure (ACI) allows application requirements to define the network. This architecture simplifies, optimizes, and accelerates the entire application deployment life cycle. - - -Application Policy Infrastructure Controller (APIC) -................................................... -The APIC manages the scalable ACI multi-tenant fabric. The APIC provides a unified point of automation and management, policy programming, application deployment, and health monitoring for the fabric. The APIC, which is implemented as a replicated synchronized clustered controller, optimizes performance, supports any application anywhere, and provides unified operation of the physical and virtual infrastructure. - -The APIC enables network administrators to easily define the optimal network for applications. Data center operators can clearly see how applications consume network resources, easily isolate and troubleshoot application and infrastructure problems, and monitor and profile resource usage patterns. - -The Cisco Application Policy Infrastructure Controller (APIC) API enables applications to directly connect with a secure, shared, high-performance resource pool that includes network, compute, and storage capabilities. - - -ACI Fabric -.......... -The Cisco Application Centric Infrastructure (ACI) Fabric includes Cisco Nexus 9000 Series switches with the APIC to run in the leaf/spine ACI fabric mode. These switches form a "fat-tree" network by connecting each leaf node to each spine node; all other devices connect to the leaf nodes. The APIC manages the ACI fabric. - -The ACI fabric provides consistent low-latency forwarding across high-bandwidth links (40 Gbps, with a 100-Gbps future capability). Traffic with the source and destination on the same leaf switch is handled locally, and all other traffic travels from the ingress leaf to the egress leaf through a spine switch. Although this architecture appears as two hops from a physical perspective, it is actually a single Layer 3 hop because the fabric operates as a single Layer 3 switch. - -The ACI fabric object-oriented operating system (OS) runs on each Cisco Nexus 9000 Series node. It enables programming of objects for each configurable element of the system. The ACI fabric OS renders policies from the APIC into a concrete model that runs in the physical infrastructure. The concrete model is analogous to compiled software; it is the form of the model that the switch operating system can execute. - -All the switch nodes contain a complete copy of the concrete model. When an administrator creates a policy in the APIC that represents a configuration, the APIC updates the logical model. The APIC then performs the intermediate step of creating a fully elaborated policy that it pushes into all the switch nodes where the concrete model is updated. - -The APIC is responsible for fabric activation, switch firmware management, network policy configuration, and instantiation. While the APIC acts as the centralized policy and network management engine for the fabric, it is completely removed from the data path, including the forwarding topology. Therefore, the fabric can still forward traffic even when communication with the APIC is lost. - - -More information -................ -Various resources exist to start learning ACI, here is a list of interesting articles from the community. - -- `Adam Raffe: Learning ACI `_ -- `Luca Relandini: ACI for dummies `_ -- `Cisco DevNet Learning Labs about ACI `_ - - -.. _aci_guide_modules: - -Using the ACI modules ---------------------- -The Ansible ACI modules provide a user-friendly interface to managing your ACI environment using Ansible playbooks. - -For instance ensuring that a specific tenant exists, is done using the following Ansible task using the aci_tenant module: - -.. code-block:: yaml - - - name: Ensure tenant customer-xyz exists - aci_tenant: - host: my-apic-1 - username: admin - password: my-password - - tenant: customer-xyz - description: Customer XYZ - state: present - -A complete list of existing ACI modules is available on the content tab of the `ACI collection on Ansible Galaxy `_. - -If you want to learn how to write your own ACI modules to contribute, look at the :ref:`Developing Cisco ACI modules ` section. - -Querying ACI configuration -.......................... - -A module can also be used to query a specific object. - -.. code-block:: yaml - - - name: Query tenant customer-xyz - aci_tenant: - host: my-apic-1 - username: admin - password: my-password - - tenant: customer-xyz - state: query - register: my_tenant - -Or query all objects. - -.. code-block:: yaml - - - name: Query all tenants - aci_tenant: - host: my-apic-1 - username: admin - password: my-password - - state: query - register: all_tenants - -After registering the return values of the aci_tenant task as shown above, you can access all tenant information from variable ``all_tenants``. - - -Running on the controller locally -................................. -As originally designed, Ansible modules are shipped to and run on the remote target(s), however the ACI modules (like most network-related modules) do not run on the network devices or controller (in this case the APIC), but they talk directly to the APIC's REST interface. - -For this very reason, the modules need to run on the local Ansible controller (or are delegated to another system that *can* connect to the APIC). - - -Gathering facts -``````````````` -Because we run the modules on the Ansible controller gathering facts will not work. That is why when using these ACI modules it is mandatory to disable facts gathering. You can do this globally in your ``ansible.cfg`` or by adding ``gather_facts: false`` to every play. - -.. code-block:: yaml - :emphasize-lines: 3 - - - name: Another play in my playbook - hosts: my-apic-1 - gather_facts: false - tasks: - - name: Create a tenant - aci_tenant: - ... - -Delegating to localhost -``````````````````````` -So let us assume we have our target configured in the inventory using the FQDN name as the ``ansible_host`` value, as shown below. - -.. code-block:: yaml - :emphasize-lines: 3 - - apics: - my-apic-1: - ansible_host: apic01.fqdn.intra - ansible_user: admin - ansible_password: my-password - -One way to set this up is to add to every task the directive: ``delegate_to: localhost``. - -.. code-block:: yaml - :emphasize-lines: 8 - - - name: Query all tenants - aci_tenant: - host: '{{ ansible_host }}' - username: '{{ ansible_user }}' - password: '{{ ansible_password }}' - - state: query - delegate_to: localhost - register: all_tenants - -If one would forget to add this directive, Ansible will attempt to connect to the APIC using SSH and attempt to copy the module and run it remotely. This will fail with a clear error, yet may be confusing to some. - - -Using the local connection method -````````````````````````````````` -Another option frequently used, is to tie the ``local`` connection method to this target so that every subsequent task for this target will use the local connection method (hence run it locally, rather than use SSH). - -In this case the inventory may look like this: - -.. code-block:: yaml - :emphasize-lines: 6 - - apics: - my-apic-1: - ansible_host: apic01.fqdn.intra - ansible_user: admin - ansible_password: my-password - ansible_connection: local - -But used tasks do not need anything special added. - -.. code-block:: yaml - - - name: Query all tenants - aci_tenant: - host: '{{ ansible_host }}' - username: '{{ ansible_user }}' - password: '{{ ansible_password }}' - - state: query - register: all_tenants - -.. hint:: For clarity we have added ``delegate_to: localhost`` to all the examples in the module documentation. This helps to ensure first-time users can easily copy&paste parts and make them work with a minimum of effort. - - -Common parameters -................. -Every Ansible ACI module accepts the following parameters that influence the module's communication with the APIC REST API: - - host - Hostname or IP address of the APIC. - - port - Port to use for communication. (Defaults to ``443`` for HTTPS, and ``80`` for HTTP) - - username - User name used to log on to the APIC. (Defaults to ``admin``) - - password - Password for ``username`` to log on to the APIC, using password-based authentication. - - private_key - Private key for ``username`` to log on to APIC, using signature-based authentication. - This could either be the raw private key content (include header/footer) or a file that stores the key content. - *New in version 2.5* - - certificate_name - Name of the certificate in the ACI Web GUI. - This defaults to either the ``username`` value or the ``private_key`` file base name). - *New in version 2.5* - - timeout - Timeout value for socket-level communication. - - use_proxy - Use system proxy settings. (Defaults to ``true``) - - use_ssl - Use HTTPS or HTTP for APIC REST communication. (Defaults to ``true``) - - validate_certs - Validate certificate when using HTTPS communication. (Defaults to ``true``) - - output_level - Influence the level of detail ACI modules return to the user. (One of ``normal``, ``info`` or ``debug``) *New in version 2.5* - - -Proxy support -............. -By default, if an environment variable ``_proxy`` is set on the target host, requests will be sent through that proxy. This behaviour can be overridden by setting a variable for this task (see :ref:`playbooks_environment`), or by using the ``use_proxy`` module parameter. - -HTTP redirects can redirect from HTTP to HTTPS so ensure that the proxy environment for both protocols is correctly configured. - -If proxy support is not needed, but the system may have it configured nevertheless, use the parameter ``use_proxy: false`` to avoid accidental system proxy usage. - -.. hint:: Selective proxy support using the ``no_proxy`` environment variable is also supported. - - -Return values -............. - -.. versionadded:: 2.5 - -The following values are always returned: - - current - The resulting state of the managed object, or results of your query. - -The following values are returned when ``output_level: info``: - - previous - The original state of the managed object (before any change was made). - - proposed - The proposed config payload, based on user-supplied values. - - sent - The sent config payload, based on user-supplied values and the existing configuration. - -The following values are returned when ``output_level: debug`` or ``ANSIBLE_DEBUG=1``: - - filter_string - The filter used for specific APIC queries. - - method - The HTTP method used for the sent payload. (Either ``GET`` for queries, ``DELETE`` or ``POST`` for changes) - - response - The HTTP response from the APIC. - - status - The HTTP status code for the request. - - url - The url used for the request. - -.. note:: The module return values are documented in detail as part of each module's documentation. - - -More information -................ -Various resources exist to start learn more about ACI programmability, we recommend the following links: - -- :ref:`Developing Cisco ACI modules ` -- `Jacob McGill: Automating Cisco ACI with Ansible `_ -- `Cisco DevNet Learning Labs about ACI and Ansible `_ - - -.. _aci_guide_auth: - -ACI authentication ------------------- - -Password-based authentication -............................. -If you want to log on using a username and password, you can use the following parameters with your ACI modules: - -.. code-block:: yaml - - username: admin - password: my-password - -Password-based authentication is very simple to work with, but it is not the most efficient form of authentication from ACI's point-of-view as it requires a separate login-request and an open session to work. To avoid having your session time-out and requiring another login, you can use the more efficient Signature-based authentication. - -.. note:: Password-based authentication also may trigger anti-DoS measures in ACI v3.1+ that causes session throttling and results in HTTP 503 errors and login failures. - -.. warning:: Never store passwords in plain text. - -The "Vault" feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See :ref:`playbooks_vault` for more information. - - -Signature-based authentication using certificates -................................................. - -.. versionadded:: 2.5 - -Using signature-based authentication is more efficient and more reliable than password-based authentication. - -Generate certificate and private key -```````````````````````````````````` -Signature-based authentication requires a (self-signed) X.509 certificate with private key, and a configuration step for your AAA user in ACI. To generate a working X.509 certificate and private key, use the following procedure: - -.. code-block:: bash - - $ openssl req -new -newkey rsa:1024 -days 36500 -nodes -x509 -keyout admin.key -out admin.crt -subj '/CN=Admin/O=Your Company/C=US' - -Configure your local user -````````````````````````` -Perform the following steps: - -- Add the X.509 certificate to your ACI AAA local user at :guilabel:`ADMIN` » :guilabel:`AAA` -- Click :guilabel:`AAA Authentication` -- Check that in the :guilabel:`Authentication` field the :guilabel:`Realm` field displays :guilabel:`Local` -- Expand :guilabel:`Security Management` » :guilabel:`Local Users` -- Click the name of the user you want to add a certificate to, in the :guilabel:`User Certificates` area -- Click the :guilabel:`+` sign and in the :guilabel:`Create X509 Certificate` enter a certificate name in the :guilabel:`Name` field - - * If you use the basename of your private key here, you don't need to enter ``certificate_name`` in Ansible - -- Copy and paste your X.509 certificate in the :guilabel:`Data` field. - -You can automate this by using the following Ansible task: - -.. code-block:: yaml - - - name: Ensure we have a certificate installed - aci_aaa_user_certificate: - host: my-apic-1 - username: admin - password: my-password - - aaa_user: admin - certificate_name: admin - certificate: "{{ lookup('file', 'pki/admin.crt') }}" # This will read the certificate data from a local file - -.. note:: Signature-based authentication only works with local users. - - -Use signature-based authentication with Ansible -``````````````````````````````````````````````` -You need the following parameters with your ACI module(s) for it to work: - -.. code-block:: yaml - :emphasize-lines: 2,3 - - username: admin - private_key: pki/admin.key - certificate_name: admin # This could be left out ! - -or you can use the private key content: - -.. code-block:: yaml - :emphasize-lines: 2,3 - - username: admin - private_key: | - -----BEGIN PRIVATE KEY----- - <> - -----END PRIVATE KEY----- - certificate_name: admin # This could be left out ! - - -.. hint:: If you use a certificate name in ACI that matches the private key's basename, you can leave out the ``certificate_name`` parameter like the example above. - - -Using Ansible Vault to encrypt the private key -`````````````````````````````````````````````` -.. versionadded:: 2.8 - -To start, encrypt the private key and give it a strong password. - -.. code-block:: bash - - ansible-vault encrypt admin.key - -Use a text editor to open the private-key. You should have an encrypted cert now. - -.. code-block:: bash - - $ANSIBLE_VAULT;1.1;AES256 - 56484318584354658465121889743213151843149454864654151618131547984132165489484654 - 45641818198456456489479874513215489484843614848456466655432455488484654848489498 - .... - -Copy and paste the new encrypted cert into your playbook as a new variable. - -.. code-block:: yaml - - private_key: !vault | - $ANSIBLE_VAULT;1.1;AES256 - 56484318584354658465121889743213151843149454864654151618131547984132165489484654 - 45641818198456456489479874513215489484843614848456466655432455488484654848489498 - .... - -Use the new variable for the private_key: - -.. code-block:: yaml - - username: admin - private_key: "{{ private_key }}" - certificate_name: admin # This could be left out ! - -When running the playbook, use "--ask-vault-pass" to decrypt the private key. - -.. code-block:: bash - - ansible-playbook site.yaml --ask-vault-pass - - -More information -```````````````` -- Detailed information about Signature-based Authentication is available from `Cisco APIC Signature-Based Transactions `_. -- More information on Ansible Vault can be found on the :ref:`Ansible Vault ` page. - - -.. _aci_guide_rest: - -Using ACI REST with Ansible ---------------------------- -While already a lot of ACI modules exists in the Ansible distribution, and the most common actions can be performed with these existing modules, there's always something that may not be possible with off-the-shelf modules. - -The aci_rest module provides you with direct access to the APIC REST API and enables you to perform any task not already covered by the existing modules. This may seem like a complex undertaking, but you can generate the needed REST payload for any action performed in the ACI web interface effortlessly. - - -Built-in idempotency -.................... -Because the APIC REST API is intrinsically idempotent and can report whether a change was made, the aci_rest module automatically inherits both capabilities and is a first-class solution for automating your ACI infrastructure. As a result, users that require more powerful low-level access to their ACI infrastructure don't have to give up on idempotency and don't have to guess whether a change was performed when using the aci_rest module. - - -Using the aci_rest module -......................... -The aci_rest module accepts the native XML and JSON payloads, but additionally accepts inline YAML payload (structured like JSON). The XML payload requires you to use a path ending with ``.xml`` whereas JSON or YAML require the path to end with ``.json``. - -When you're making modifications, you can use the POST or DELETE methods, whereas doing just queries require the GET method. - -For instance, if you would like to ensure a specific tenant exists on ACI, these below four examples are functionally identical: - -**XML** (Native ACI REST) - -.. code-block:: yaml - - - aci_rest: - host: my-apic-1 - private_key: pki/admin.key - - method: post - path: /api/mo/uni.xml - content: | - - -**JSON** (Native ACI REST) - -.. code-block:: yaml - - - aci_rest: - host: my-apic-1 - private_key: pki/admin.key - - method: post - path: /api/mo/uni.json - content: - { - "fvTenant": { - "attributes": { - "name": "customer-xyz", - "descr": "Customer XYZ" - } - } - } - -**YAML** (Ansible-style REST) - -.. code-block:: yaml - - - aci_rest: - host: my-apic-1 - private_key: pki/admin.key - - method: post - path: /api/mo/uni.json - content: - fvTenant: - attributes: - name: customer-xyz - descr: Customer XYZ - -**Ansible task** (Dedicated module) - -.. code-block:: yaml - - - aci_tenant: - host: my-apic-1 - private_key: pki/admin.key - - tenant: customer-xyz - description: Customer XYZ - state: present - - -.. hint:: The XML format is more practical when there is a need to template the REST payload (inline), but the YAML format is more convenient for maintaining your infrastructure-as-code and feels more naturally integrated with Ansible playbooks. The dedicated modules offer a more simple, abstracted, but also a more limited experience. Use what feels best for your use-case. - - -More information -................ -Plenty of resources exist to learn about ACI's APIC REST interface, we recommend the links below: - -- `The ACI collection on Ansible Galaxy `_ -- `APIC REST API Configuration Guide `_ -- Detailed guide on how the APIC REST API is designed and used, incl. many examples -- `APIC Management Information Model reference `_ -- Complete reference of the APIC object model -- `Cisco DevNet Learning Labs about ACI and REST `_ - - -.. _aci_guide_ops: - -Operational examples --------------------- -Here is a small overview of useful operational tasks to reuse in your playbooks. - -Feel free to contribute more useful snippets. - - -Waiting for all controllers to be ready -....................................... -You can use the below task after you started to build your APICs and configured the cluster to wait until all the APICs have come online. It will wait until the number of controllers equals the number listed in the ``apic`` inventory group. - -.. code-block:: yaml - - - name: Waiting for all controllers to be ready - aci_rest: - host: my-apic-1 - private_key: pki/admin.key - method: get - path: /api/node/class/topSystem.json?query-target-filter=eq(topSystem.role,"controller") - register: topsystem - until: topsystem|success and topsystem.totalCount|int >= groups['apic']|count >= 3 - retries: 20 - delay: 30 - - -Waiting for cluster to be fully-fit -................................... -The below example waits until the cluster is fully-fit. In this example you know the number of APICs in the cluster and you verify each APIC reports a 'fully-fit' status. - -.. code-block:: yaml - - - name: Waiting for cluster to be fully-fit - aci_rest: - host: my-apic-1 - private_key: pki/admin.key - method: get - path: /api/node/class/infraWiNode.json?query-target-filter=wcard(infraWiNode.dn,"topology/pod-1/node-1/av") - register: infrawinode - until: > - infrawinode|success and - infrawinode.totalCount|int >= groups['apic']|count >= 3 and - infrawinode.imdata[0].infraWiNode.attributes.health == 'fully-fit' and - infrawinode.imdata[1].infraWiNode.attributes.health == 'fully-fit' and - infrawinode.imdata[2].infraWiNode.attributes.health == 'fully-fit' - retries: 30 - delay: 30 - - -.. _aci_guide_errors: - -APIC error messages -------------------- -The following error messages may occur and this section can help you understand what exactly is going on and how to fix/avoid them. - - APIC Error 122: unknown managed object class 'polUni' - In case you receive this error while you are certain your aci_rest payload and object classes are seemingly correct, the issue might be that your payload is not in fact correct JSON (for example, the sent payload is using single quotes, rather than double quotes), and as a result the APIC is not correctly parsing your object classes from the payload. One way to avoid this is by using a YAML or an XML formatted payload, which are easier to construct correctly and modify later. - - - APIC Error 400: invalid data at line '1'. Attributes are missing, tag 'attributes' must be specified first, before any other tag - Although the JSON specification allows unordered elements, the APIC REST API requires that the JSON ``attributes`` element precede the ``children`` array or other elements. So you need to ensure that your payload conforms to this requirement. Sorting your dictionary keys will do the trick just fine. If you don't have any attributes, it may be necessary to add: ``attributes: {}`` as the APIC does expect the entry to precede any ``children``. - - - APIC Error 801: property descr of uni/tn-TENANT/ap-AP failed validation for value 'A "legacy" network' - Some values in the APIC have strict format-rules to comply to, and the internal APIC validation check for the provided value failed. In the above case, the ``description`` parameter (internally known as ``descr``) only accepts values conforming to Regex: ``[a-zA-Z0-9\\!#$%()*,-./:;@ _{|}~?&+]+``, in general it must not include quotes or square brackets. - - -.. _aci_guide_known_issues: - -Known issues ------------- -The aci_rest module is a wrapper around the APIC REST API. As a result any issues related to the APIC will be reflected in the use of this module. - -All below issues either have been reported to the vendor, and most can simply be avoided. - - Too many consecutive API calls may result in connection throttling - Starting with ACI v3.1 the APIC will actively throttle password-based authenticated connection rates over a specific threshold. This is as part of an anti-DDOS measure but can act up when using Ansible with ACI using password-based authentication. Currently, one solution is to increase this threshold within the nginx configuration, but using signature-based authentication is recommended. - - **NOTE:** It is advisable to use signature-based authentication with ACI as it not only prevents connection-throttling, but also improves general performance when using the ACI modules. - - - Specific requests may not reflect changes correctly (`#35401 `_) - There is a known issue where specific requests to the APIC do not properly reflect changed in the resulting output, even when we request those changes explicitly from the APIC. In one instance using the path ``api/node/mo/uni/infra.xml`` fails, where ``api/node/mo/uni/infra/.xml`` does work correctly. - - **NOTE:** A workaround is to register the task return values (for example, ``register: this``) and influence when the task should report a change by adding: ``changed_when: this.imdata != []``. - - - Specific requests are known to not be idempotent (`#35050 `_) - The behaviour of the APIC is inconsistent to the use of ``status="created"`` and ``status="deleted"``. The result is that when you use ``status="created"`` in your payload the resulting tasks are not idempotent and creation will fail when the object was already created. However this is not the case with ``status="deleted"`` where such call to an non-existing object does not cause any failure whatsoever. - - **NOTE:** A workaround is to avoid using ``status="created"`` and instead use ``status="modified"`` when idempotency is essential to your workflow.. - - - Setting user password is not idempotent (`#35544 `_) - Due to an inconsistency in the APIC REST API, a task that sets the password of a locally-authenticated user is not idempotent. The APIC will complain with message ``Password history check: user dag should not use previous 5 passwords``. - - **NOTE:** There is no workaround for this issue. - - -.. _aci_guide_community: - -ACI Ansible community ---------------------- -If you have specific issues with the ACI modules, or a feature request, or you like to contribute to the ACI project by proposing changes or documentation updates, look at the Ansible Community wiki ACI page at: https://github.com/ansible/community/wiki/Network:-ACI - -You will find our roadmap, an overview of open ACI issues and pull-requests, and more information about who we are. If you have an interest in using ACI with Ansible, feel free to join! We occasionally meet online (on the #ansible-network chat channel, using Matrix at ansible.im or using IRC at `irc.libera.chat `_) to track progress and prepare for new Ansible releases. - - -.. seealso:: - - `ACI collection on Ansible Galaxy `_ - View the content tab for a complete list of supported ACI modules. - :ref:`Developing Cisco ACI modules ` - A walkthrough on how to develop new Cisco ACI modules to contribute back. - `ACI community `_ - The Ansible ACI community wiki page, includes roadmap, ideas and development documentation. - :ref:`network_guide` - A detailed guide on how to use Ansible for automating network infrastructure. - `Network Working Group `_ - The Ansible Network community page, includes contact information and meeting information. - `User Mailing List `_ - Have a question? Stop by the google group! diff --git a/docs/docsite/rst/scenario_guides/guide_alicloud.rst b/docs/docsite/rst/scenario_guides/guide_alicloud.rst deleted file mode 100644 index fd78bf19cfb..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_alicloud.rst +++ /dev/null @@ -1,133 +0,0 @@ -Alibaba Cloud Compute Services Guide -==================================== - -.. _alicloud_intro: - -Introduction -```````````` - -Ansible contains several modules for controlling and managing Alibaba Cloud Compute Services (Alicloud). This guide -explains how to use the Alicloud Ansible modules together. - -All Alicloud modules require ``footmark`` - install it on your control machine with ``pip install footmark``. - -Cloud modules, including Alicloud modules, execute on your local machine (the control machine) with ``connection: local``, rather than on remote machines defined in your hosts. - -Normally, you'll use the following pattern for plays that provision Alicloud resources: - -.. code-block:: yaml - - - hosts: localhost - connection: local - vars: - - ... - tasks: - - ... - -.. _alicloud_authentication: - -Authentication -`````````````` - -You can specify your Alicloud authentication credentials (access key and secret key) by passing them as -environment variables or by storing them in a vars file. - -To pass authentication credentials as environment variables: - -.. code-block:: shell - - export ALICLOUD_ACCESS_KEY='Alicloud123' - export ALICLOUD_SECRET_KEY='AlicloudSecret123' - -To store authentication credentials in a vars_files, encrypt them with :ref:`Ansible Vault` to keep them secure, then list them: - -.. code-block:: yaml - - --- - alicloud_access_key: "--REMOVED--" - alicloud_secret_key: "--REMOVED--" - -Note that if you store your credentials in a vars_files, you need to refer to them in each Alicloud module. For example: - -.. code-block:: yaml - - - ali_instance: - alicloud_access_key: "{{alicloud_access_key}}" - alicloud_secret_key: "{{alicloud_secret_key}}" - image_id: "..." - -.. _alicloud_provisioning: - -Provisioning -```````````` - -Alicloud modules create Alicloud ECS instances, disks, virtual private clouds, virtual switches, security groups and other resources. - -You can use the ``count`` parameter to control the number of resources you create or terminate. For example, if you want exactly 5 instances tagged ``NewECS``, -set the ``count`` of instances to 5 and the ``count_tag`` to ``NewECS``, as shown in the last task of the example playbook below. -If there are no instances with the tag ``NewECS``, the task creates 5 new instances. If there are 2 instances with that tag, the task -creates 3 more. If there are 8 instances with that tag, the task terminates 3 of those instances. - -If you do not specify a ``count_tag``, the task creates the number of instances you specify in ``count`` with the ``instance_name`` you provide. - -.. code-block:: yaml - - # alicloud_setup.yml - - - hosts: localhost - connection: local - - tasks: - - - name: Create VPC - ali_vpc: - cidr_block: '{{ cidr_block }}' - vpc_name: new_vpc - register: created_vpc - - - name: Create VSwitch - ali_vswitch: - alicloud_zone: '{{ alicloud_zone }}' - cidr_block: '{{ vsw_cidr }}' - vswitch_name: new_vswitch - vpc_id: '{{ created_vpc.vpc.id }}' - register: created_vsw - - - name: Create security group - ali_security_group: - name: new_group - vpc_id: '{{ created_vpc.vpc.id }}' - rules: - - proto: tcp - port_range: 22/22 - cidr_ip: 0.0.0.0/0 - priority: 1 - rules_egress: - - proto: tcp - port_range: 80/80 - cidr_ip: 192.168.0.54/32 - priority: 1 - register: created_group - - - name: Create a set of instances - ali_instance: - security_groups: '{{ created_group.group_id }}' - instance_type: ecs.n4.small - image_id: "{{ ami_id }}" - instance_name: "My-new-instance" - instance_tags: - Name: NewECS - Version: 0.0.1 - count: 5 - count_tag: - Name: NewECS - allocate_public_ip: true - max_bandwidth_out: 50 - vswitch_id: '{{ created_vsw.vswitch.id}}' - register: create_instance - -In the example playbook above, data about the vpc, vswitch, group, and instances created by this playbook -are saved in the variables defined by the "register" keyword in each task. - -Each Alicloud module offers a variety of parameter options. Not all options are demonstrated in the above example. -See each individual module for further details and examples. diff --git a/docs/docsite/rst/scenario_guides/guide_aws.rst b/docs/docsite/rst/scenario_guides/guide_aws.rst deleted file mode 100644 index f2931556399..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_aws.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Amazon Web Services Guide -========================= - -The content on this page has moved. Please see the updated :ref:`ansible_collections.amazon.aws.docsite.aws_intro` in the AWS collection. diff --git a/docs/docsite/rst/scenario_guides/guide_azure.rst b/docs/docsite/rst/scenario_guides/guide_azure.rst deleted file mode 100644 index 41bdab3c24f..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_azure.rst +++ /dev/null @@ -1,484 +0,0 @@ -Microsoft Azure Guide -===================== - -.. important:: - - Red Hat Ansible Automation Platform will soon be available on Microsoft Azure. `Sign up to preview the experience `_. - -Ansible includes a suite of modules for interacting with Azure Resource Manager, giving you the tools to easily create -and orchestrate infrastructure on the Microsoft Azure Cloud. - -Requirements ------------- - -Using the Azure Resource Manager modules requires having specific Azure SDK modules -installed on the host running Ansible. - -.. code-block:: bash - - $ pip install 'ansible[azure]' - -If you are running Ansible from source, you can install the dependencies from the -root directory of the Ansible repo. - -.. code-block:: bash - - $ pip install .[azure] - -You can also directly run Ansible in `Azure Cloud Shell `_, where Ansible is pre-installed. - -Authenticating with Azure -------------------------- - -Using the Azure Resource Manager modules requires authenticating with the Azure API. You can choose from two authentication strategies: - -* Active Directory Username/Password -* Service Principal Credentials - -Follow the directions for the strategy you wish to use, then proceed to `Providing Credentials to Azure Modules`_ for -instructions on how to actually use the modules and authenticate with the Azure API. - - -Using Service Principal -....................... - -There is now a detailed official tutorial describing `how to create a service principal `_. - -After stepping through the tutorial you will have: - -* Your Client ID, which is found in the "client id" box in the "Configure" page of your application in the Azure portal -* Your Secret key, generated when you created the application. You cannot show the key after creation. - If you lost the key, you must create a new one in the "Configure" page of your application. -* And finally, a tenant ID. It's a UUID (for example, ABCDEFGH-1234-ABCD-1234-ABCDEFGHIJKL) pointing to the AD containing your - application. You will find it in the URL from within the Azure portal, or in the "view endpoints" of any given URL. - - -Using Active Directory Username/Password -........................................ - -To create an Active Directory username/password: - -* Connect to the Azure Classic Portal with your admin account -* Create a user in your default AAD. You must NOT activate Multi-Factor Authentication -* Go to Settings - Administrators -* Click on Add and enter the email of the new user. -* Check the checkbox of the subscription you want to test with this user. -* Login to Azure Portal with this new user to change the temporary password to a new one. You will not be able to use the - temporary password for OAuth login. - -Providing Credentials to Azure Modules -...................................... - -The modules offer several ways to provide your credentials. For a CI/CD tool such as Ansible AWX or Jenkins, you will -most likely want to use environment variables. For local development you may wish to store your credentials in a file -within your home directory. And of course, you can always pass credentials as parameters to a task within a playbook. The -order of precedence is parameters, then environment variables, and finally a file found in your home directory. - -Using Environment Variables -``````````````````````````` - -To pass service principal credentials through the environment, define the following variables: - -* AZURE_CLIENT_ID -* AZURE_SECRET -* AZURE_SUBSCRIPTION_ID -* AZURE_TENANT - -To pass Active Directory username/password through the environment, define the following variables: - -* AZURE_AD_USER -* AZURE_PASSWORD -* AZURE_SUBSCRIPTION_ID - -To pass Active Directory username/password in ADFS through the environment, define the following variables: - -* AZURE_AD_USER -* AZURE_PASSWORD -* AZURE_CLIENT_ID -* AZURE_TENANT -* AZURE_ADFS_AUTHORITY_URL - -"AZURE_ADFS_AUTHORITY_URL" is optional. It's necessary only when you have own ADFS authority like https://yourdomain.com/adfs. - -Storing in a File -````````````````` - -When working in a development environment, it may be desirable to store credentials in a file. The modules will look -for credentials in ``$HOME/.azure/credentials``. This file is an ini style file. It will look as follows: - -.. code-block:: ini - - [default] - subscription_id=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx - client_id=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx - secret=xxxxxxxxxxxxxxxxx - tenant=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx - -.. note:: If your secret values contain non-ASCII characters, you must `URL Encode `_ them to avoid login errors. - -It is possible to store multiple sets of credentials within the credentials file by creating multiple sections. Each -section is considered a profile. The modules look for the [default] profile automatically. Define AZURE_PROFILE in the -environment or pass a profile parameter to specify a specific profile. - -Passing as Parameters -````````````````````` - -If you wish to pass credentials as parameters to a task, use the following parameters for service principal: - -* client_id -* secret -* subscription_id -* tenant - -Or, pass the following parameters for Active Directory username/password: - -* ad_user -* password -* subscription_id - -Or, pass the following parameters for ADFS username/password: - -* ad_user -* password -* client_id -* tenant -* adfs_authority_url - -"adfs_authority_url" is optional. It's necessary only when you have own ADFS authority like https://yourdomain.com/adfs. - - -Other Cloud Environments ------------------------- - -To use an Azure Cloud other than the default public cloud (for example, Azure China Cloud, Azure US Government Cloud, Azure Stack), -pass the "cloud_environment" argument to modules, configure it in a credential profile, or set the "AZURE_CLOUD_ENVIRONMENT" -environment variable. The value is either a cloud name as defined by the Azure Python SDK (for example, "AzureChinaCloud", -"AzureUSGovernment"; defaults to "AzureCloud") or an Azure metadata discovery URL (for Azure Stack). - -Creating Virtual Machines -------------------------- - -There are two ways to create a virtual machine, both involving the azure_rm_virtualmachine module. We can either create -a storage account, network interface, security group and public IP address and pass the names of these objects to the -module as parameters, or we can let the module do the work for us and accept the defaults it chooses. - -Creating Individual Components -.............................. - -An Azure module is available to help you create a storage account, virtual network, subnet, network interface, -security group and public IP. Here is a full example of creating each of these and passing the names to the -``azure.azcollection.azure_rm_virtualmachine`` module at the end: - -.. code-block:: yaml - - - name: Create storage account - azure.azcollection.azure_rm_storageaccount: - resource_group: Testing - name: testaccount001 - account_type: Standard_LRS - - - name: Create virtual network - azure.azcollection.azure_rm_virtualnetwork: - resource_group: Testing - name: testvn001 - address_prefixes: "10.10.0.0/16" - - - name: Add subnet - azure.azcollection.azure_rm_subnet: - resource_group: Testing - name: subnet001 - address_prefix: "10.10.0.0/24" - virtual_network: testvn001 - - - name: Create public ip - azure.azcollection.azure_rm_publicipaddress: - resource_group: Testing - allocation_method: Static - name: publicip001 - - - name: Create security group that allows SSH - azure.azcollection.azure_rm_securitygroup: - resource_group: Testing - name: secgroup001 - rules: - - name: SSH - protocol: Tcp - destination_port_range: 22 - access: Allow - priority: 101 - direction: Inbound - - - name: Create NIC - azure.azcollection.azure_rm_networkinterface: - resource_group: Testing - name: testnic001 - virtual_network: testvn001 - subnet: subnet001 - public_ip_name: publicip001 - security_group: secgroup001 - - - name: Create virtual machine - azure.azcollection.azure_rm_virtualmachine: - resource_group: Testing - name: testvm001 - vm_size: Standard_D1 - storage_account: testaccount001 - storage_container: testvm001 - storage_blob: testvm001.vhd - admin_username: admin - admin_password: Password! - network_interfaces: testnic001 - image: - offer: CentOS - publisher: OpenLogic - sku: '7.1' - version: latest - -Each of the Azure modules offers a variety of parameter options. Not all options are demonstrated in the above example. -See each individual module for further details and examples. - - -Creating a Virtual Machine with Default Options -............................................... - -If you simply want to create a virtual machine without specifying all the details, you can do that as well. The only -caveat is that you will need a virtual network with one subnet already in your resource group. Assuming you have a -virtual network already with an existing subnet, you can run the following to create a VM: - -.. code-block:: yaml - - azure.azcollection.azure_rm_virtualmachine: - resource_group: Testing - name: testvm10 - vm_size: Standard_D1 - admin_username: chouseknecht - ssh_password_enabled: false - ssh_public_keys: "{{ ssh_keys }}" - image: - offer: CentOS - publisher: OpenLogic - sku: '7.1' - version: latest - - -Creating a Virtual Machine in Availability Zones -.................................................. - -If you want to create a VM in an availability zone, -consider the following: - -* Both OS disk and data disk must be a 'managed disk', not an 'unmanaged disk'. -* When creating a VM with the ``azure.azcollection.azure_rm_virtualmachine`` module, - you need to explicitly set the ``managed_disk_type`` parameter - to change the OS disk to a managed disk. - Otherwise, the OS disk becomes an unmanaged disk. -* When you create a data disk with the ``azure.azcollection.azure_rm_manageddisk`` module, - you need to explicitly specify the ``storage_account_type`` parameter - to make it a managed disk. - Otherwise, the data disk will be an unmanaged disk. -* A managed disk does not require a storage account or a storage container, - unlike an unmanaged disk. - In particular, note that once a VM is created on an unmanaged disk, - an unnecessary storage container named "vhds" is automatically created. -* When you create an IP address with the ``azure.azcollection.azure_rm_publicipaddress`` module, - you must set the ``sku`` parameter to ``standard``. - Otherwise, the IP address cannot be used in an availability zone. - - -Dynamic Inventory Script ------------------------- - -If you are not familiar with Ansible's dynamic inventory scripts, check out :ref:`Intro to Dynamic Inventory `. - -The Azure Resource Manager inventory script is called `azure_rm.py `_. It authenticates with the Azure API exactly the same as the -Azure modules, which means you will either define the same environment variables described above in `Using Environment Variables`_, -create a ``$HOME/.azure/credentials`` file (also described above in `Storing in a File`_), or pass command line parameters. To see available command -line options execute the following: - -.. code-block:: bash - - $ wget https://raw.githubusercontent.com/ansible-community/contrib-scripts/main/inventory/azure_rm.py - $ ./azure_rm.py --help - -As with all dynamic inventory scripts, the script can be executed directly, passed as a parameter to the ansible command, -or passed directly to ansible-playbook using the -i option. No matter how it is executed the script produces JSON representing -all of the hosts found in your Azure subscription. You can narrow this down to just hosts found in a specific set of -Azure resource groups, or even down to a specific host. - -For a given host, the inventory script provides the following host variables: - -.. code-block:: JSON - - { - "ansible_host": "XXX.XXX.XXX.XXX", - "computer_name": "computer_name2", - "fqdn": null, - "id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Compute/virtualMachines/object-name", - "image": { - "offer": "CentOS", - "publisher": "OpenLogic", - "sku": "7.1", - "version": "latest" - }, - "location": "westus", - "mac_address": "00-00-5E-00-53-FE", - "name": "object-name", - "network_interface": "interface-name", - "network_interface_id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Network/networkInterfaces/object-name1", - "network_security_group": null, - "network_security_group_id": null, - "os_disk": { - "name": "object-name", - "operating_system_type": "Linux" - }, - "plan": null, - "powerstate": "running", - "private_ip": "172.26.3.6", - "private_ip_alloc_method": "Static", - "provisioning_state": "Succeeded", - "public_ip": "XXX.XXX.XXX.XXX", - "public_ip_alloc_method": "Static", - "public_ip_id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Network/publicIPAddresses/object-name", - "public_ip_name": "object-name", - "resource_group": "galaxy-production", - "security_group": "object-name", - "security_group_id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Network/networkSecurityGroups/object-name", - "tags": { - "db": "mysql" - }, - "type": "Microsoft.Compute/virtualMachines", - "virtual_machine_size": "Standard_DS4" - } - -Host Groups -........... - -By default hosts are grouped by: - -* azure (all hosts) -* location name -* resource group name -* security group name -* tag key -* tag key_value -* os_disk operating_system_type (Windows/Linux) - -You can control host groupings and host selection by either defining environment variables or creating an -azure_rm.ini file in your current working directory. - -NOTE: An .ini file will take precedence over environment variables. - -NOTE: The name of the .ini file is the basename of the inventory script (in other words, 'azure_rm') with a '.ini' -extension. This allows you to copy, rename and customize the inventory script and have matching .ini files all in -the same directory. - -Control grouping using the following variables defined in the environment: - -* AZURE_GROUP_BY_RESOURCE_GROUP=yes -* AZURE_GROUP_BY_LOCATION=yes -* AZURE_GROUP_BY_SECURITY_GROUP=yes -* AZURE_GROUP_BY_TAG=yes -* AZURE_GROUP_BY_OS_FAMILY=yes - -Select hosts within specific resource groups by assigning a comma separated list to: - -* AZURE_RESOURCE_GROUPS=resource_group_a,resource_group_b - -Select hosts for specific tag key by assigning a comma separated list of tag keys to: - -* AZURE_TAGS=key1,key2,key3 - -Select hosts for specific locations by assigning a comma separated list of locations to: - -* AZURE_LOCATIONS=eastus,eastus2,westus - -Or, select hosts for specific tag key:value pairs by assigning a comma separated list key:value pairs to: - -* AZURE_TAGS=key1:value1,key2:value2 - -If you don't need the powerstate, you can improve performance by turning off powerstate fetching: - -* AZURE_INCLUDE_POWERSTATE=no - -A sample azure_rm.ini file is included along with the inventory script in -`here `_. -An .ini file will contain the following: - -.. code-block:: ini - - [azure] - # Control which resource groups are included. By default all resources groups are included. - # Set resource_groups to a comma separated list of resource groups names. - #resource_groups= - - # Control which tags are included. Set tags to a comma separated list of keys or key:value pairs - #tags= - - # Control which locations are included. Set locations to a comma separated list of locations. - #locations= - - # Include powerstate. If you don't need powerstate information, turning it off improves runtime performance. - # Valid values: yes, no, true, false, True, False, 0, 1. - include_powerstate=yes - - # Control grouping with the following boolean flags. Valid values: yes, no, true, false, True, False, 0, 1. - group_by_resource_group=yes - group_by_location=yes - group_by_security_group=yes - group_by_tag=yes - group_by_os_family=yes - -Examples -........ - -Here are some examples using the inventory script: - -.. code-block:: bash - - # Download inventory script - $ wget https://raw.githubusercontent.com/ansible-community/contrib-scripts/main/inventory/azure_rm.py - - # Execute /bin/uname on all instances in the Testing resource group - $ ansible -i azure_rm.py Testing -m shell -a "/bin/uname -a" - - # Execute win_ping on all Windows instances - $ ansible -i azure_rm.py windows -m win_ping - - # Execute ping on all Linux instances - $ ansible -i azure_rm.py linux -m ping - - # Use the inventory script to print instance specific information - $ ./azure_rm.py --host my_instance_host_name --resource-groups=Testing --pretty - - # Use the inventory script with ansible-playbook - $ ansible-playbook -i ./azure_rm.py test_playbook.yml - -Here is a simple playbook to exercise the Azure inventory script: - -.. code-block:: yaml - - - name: Test the inventory script - hosts: azure - connection: local - gather_facts: false - tasks: - - debug: - msg: "{{ inventory_hostname }} has powerstate {{ powerstate }}" - -You can execute the playbook with something like: - -.. code-block:: bash - - $ ansible-playbook -i ./azure_rm.py test_azure_inventory.yml - - -Disabling certificate validation on Azure endpoints -................................................... - -When an HTTPS proxy is present, or when using Azure Stack, it may be necessary to disable certificate validation for -Azure endpoints in the Azure modules. This is not a recommended security practice, but may be necessary when the system -CA store cannot be altered to include the necessary CA certificate. Certificate validation can be controlled by setting -the "cert_validation_mode" value in a credential profile, through the "AZURE_CERT_VALIDATION_MODE" environment variable, or -by passing the "cert_validation_mode" argument to any Azure module. The default value is "validate"; setting the value -to "ignore" will prevent all certificate validation. The module argument takes precedence over a credential profile value, -which takes precedence over the environment value. diff --git a/docs/docsite/rst/scenario_guides/guide_cloudstack.rst b/docs/docsite/rst/scenario_guides/guide_cloudstack.rst deleted file mode 100644 index 6d3f2b4d5ec..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_cloudstack.rst +++ /dev/null @@ -1,377 +0,0 @@ -CloudStack Cloud Guide -====================== - -.. _cloudstack_introduction: - -Introduction -```````````` -The purpose of this section is to explain how to put Ansible modules together to use Ansible in a CloudStack context. You will find more usage examples in the details section of each module. - -Ansible contains a number of extra modules for interacting with CloudStack based clouds. All modules support check mode, are designed to be idempotent, have been created and tested, and are maintained by the community. - -.. note:: Some of the modules will require domain admin or root admin privileges. - -Prerequisites -````````````` -Prerequisites for using the CloudStack modules are minimal. In addition to Ansible itself, all of the modules require the python library ``cs`` https://pypi.org/project/cs/ - -You'll need this Python module installed on the execution host, usually your workstation. - -.. code-block:: bash - - $ pip install cs - -Or alternatively starting with Debian 9 and Ubuntu 16.04: - -.. code-block:: bash - - $ sudo apt install python-cs - -.. note:: cs also includes a command line interface for ad hoc interaction with the CloudStack API, for example ``$ cs listVirtualMachines state=Running``. - -Limitations and Known Issues -```````````````````````````` -VPC support has been improved since Ansible 2.3 but is still not yet fully implemented. The community is working on the VPC integration. - -Credentials File -```````````````` -You can pass credentials and the endpoint of your cloud as module arguments, however in most cases it is a far less work to store your credentials in the cloudstack.ini file. - -The python library cs looks for the credentials file in the following order (last one wins): - -* A ``.cloudstack.ini`` (note the dot) file in the home directory. -* A ``CLOUDSTACK_CONFIG`` environment variable pointing to an .ini file. -* A ``cloudstack.ini`` (without the dot) file in the current working directory, same directory as your playbooks are located. - -The structure of the ini file must look like this: - -.. code-block:: bash - - $ cat $HOME/.cloudstack.ini - [cloudstack] - endpoint = https://cloud.example.com/client/api - key = api key - secret = api secret - timeout = 30 - -.. Note:: The section ``[cloudstack]`` is the default section. ``CLOUDSTACK_REGION`` environment variable can be used to define the default section. - -.. versionadded:: 2.4 - -The ENV variables support ``CLOUDSTACK_*`` as written in the documentation of the library ``cs``, like ``CLOUDSTACK_TIMEOUT``, ``CLOUDSTACK_METHOD``, and so on. has been implemented into Ansible. It is even possible to have some incomplete config in your cloudstack.ini: - -.. code-block:: bash - - $ cat $HOME/.cloudstack.ini - [cloudstack] - endpoint = https://cloud.example.com/client/api - timeout = 30 - -and fulfill the missing data by either setting ENV variables or tasks params: - -.. code-block:: yaml - - --- - - name: provision our VMs - hosts: cloud-vm - tasks: - - name: ensure VMs are created and running - delegate_to: localhost - cs_instance: - api_key: your api key - api_secret: your api secret - ... - -Regions -``````` -If you use more than one CloudStack region, you can define as many sections as you want and name them as you like, for example: - -.. code-block:: bash - - $ cat $HOME/.cloudstack.ini - [exoscale] - endpoint = https://api.exoscale.ch/compute - key = api key - secret = api secret - - [example_cloud_one] - endpoint = https://cloud-one.example.com/client/api - key = api key - secret = api secret - - [example_cloud_two] - endpoint = https://cloud-two.example.com/client/api - key = api key - secret = api secret - -.. Hint:: Sections can also be used to for login into the same region using different accounts. - -By passing the argument ``api_region`` with the CloudStack modules, the region wanted will be selected. - -.. code-block:: yaml - - - name: ensure my ssh public key exists on Exoscale - cs_sshkeypair: - name: my-ssh-key - public_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" - api_region: exoscale - delegate_to: localhost - -Or by looping over a regions list if you want to do the task in every region: - -.. code-block:: yaml - - - name: ensure my ssh public key exists in all CloudStack regions - local_action: cs_sshkeypair - name: my-ssh-key - public_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" - api_region: "{{ item }}" - loop: - - exoscale - - example_cloud_one - - example_cloud_two - -Environment Variables -````````````````````` -.. versionadded:: 2.3 - -Since Ansible 2.3 it is possible to use environment variables for domain (``CLOUDSTACK_DOMAIN``), account (``CLOUDSTACK_ACCOUNT``), project (``CLOUDSTACK_PROJECT``), VPC (``CLOUDSTACK_VPC``) and zone (``CLOUDSTACK_ZONE``). This simplifies the tasks by not repeating the arguments for every tasks. - -Below you see an example how it can be used in combination with Ansible's block feature: - -.. code-block:: yaml - - - hosts: cloud-vm - tasks: - - block: - - name: ensure my ssh public key - cs_sshkeypair: - name: my-ssh-key - public_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" - - - name: ensure my ssh public key - cs_instance: - display_name: "{{ inventory_hostname_short }}" - template: Linux Debian 7 64-bit 20GB Disk - service_offering: "{{ cs_offering }}" - ssh_key: my-ssh-key - state: running - - delegate_to: localhost - environment: - CLOUDSTACK_DOMAIN: root/customers - CLOUDSTACK_PROJECT: web-app - CLOUDSTACK_ZONE: sf-1 - -.. Note:: You are still able overwrite the environment variables using the module arguments, for example ``zone: sf-2`` - -.. Note:: Unlike ``CLOUDSTACK_REGION`` these additional environment variables are ignored in the CLI ``cs``. - -Use Cases -````````` -The following should give you some ideas how to use the modules to provision VMs to the cloud. As always, there isn't only one way to do it. But as always: keep it simple for the beginning is always a good start. - -Use Case: Provisioning in a Advanced Networking CloudStack setup -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Our CloudStack cloud has an advanced networking setup, we would like to provision web servers, which get a static NAT and open firewall ports 80 and 443. Further we provision database servers, to which we do not give any access to. For accessing the VMs by SSH we use a SSH jump host. - -This is how our inventory looks like: - -.. code-block:: none - - [cloud-vm:children] - webserver - db-server - jumphost - - [webserver] - web-01.example.com public_ip=198.51.100.20 - web-02.example.com public_ip=198.51.100.21 - - [db-server] - db-01.example.com - db-02.example.com - - [jumphost] - jump.example.com public_ip=198.51.100.22 - -As you can see, the public IPs for our web servers and jumphost has been assigned as variable ``public_ip`` directly in the inventory. - -The configure the jumphost, web servers and database servers, we use ``group_vars``. The ``group_vars`` directory contains 4 files for configuration of the groups: cloud-vm, jumphost, webserver and db-server. The cloud-vm is there for specifying the defaults of our cloud infrastructure. - -.. code-block:: yaml - - # file: group_vars/cloud-vm - --- - cs_offering: Small - cs_firewall: [] - -Our database servers should get more CPU and RAM, so we define to use a ``Large`` offering for them. - -.. code-block:: yaml - - # file: group_vars/db-server - --- - cs_offering: Large - -The web servers should get a ``Small`` offering as we would scale them horizontally, which is also our default offering. We also ensure the known web ports are opened for the world. - -.. code-block:: yaml - - # file: group_vars/webserver - --- - cs_firewall: - - { port: 80 } - - { port: 443 } - -Further we provision a jump host which has only port 22 opened for accessing the VMs from our office IPv4 network. - -.. code-block:: yaml - - # file: group_vars/jumphost - --- - cs_firewall: - - { port: 22, cidr: "17.17.17.0/24" } - -Now to the fun part. We create a playbook to create our infrastructure we call it ``infra.yml``: - -.. code-block:: yaml - - # file: infra.yaml - --- - - name: provision our VMs - hosts: cloud-vm - tasks: - - name: run all enclosed tasks from localhost - delegate_to: localhost - block: - - name: ensure VMs are created and running - cs_instance: - name: "{{ inventory_hostname_short }}" - template: Linux Debian 7 64-bit 20GB Disk - service_offering: "{{ cs_offering }}" - state: running - - - name: ensure firewall ports opened - cs_firewall: - ip_address: "{{ public_ip }}" - port: "{{ item.port }}" - cidr: "{{ item.cidr | default('0.0.0.0/0') }}" - loop: "{{ cs_firewall }}" - when: public_ip is defined - - - name: ensure static NATs - cs_staticnat: vm="{{ inventory_hostname_short }}" ip_address="{{ public_ip }}" - when: public_ip is defined - -In the above play we defined 3 tasks and use the group ``cloud-vm`` as target to handle all VMs in the cloud but instead SSH to these VMs, we use ``delegate_to: localhost`` to execute the API calls locally from our workstation. - -In the first task, we ensure we have a running VM created with the Debian template. If the VM is already created but stopped, it would just start it. If you like to change the offering on an existing VM, you must add ``force: yes`` to the task, which would stop the VM, change the offering and start the VM again. - -In the second task we ensure the ports are opened if we give a public IP to the VM. - -In the third task we add static NAT to the VMs having a public IP defined. - - -.. Note:: The public IP addresses must have been acquired in advance, also see ``cs_ip_address`` - -.. Note:: For some modules, for example ``cs_sshkeypair`` you usually want this to be executed only once, not for every VM. Therefore you would make a separate play for it targeting localhost. You find an example in the use cases below. - -Use Case: Provisioning on a Basic Networking CloudStack setup -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -A basic networking CloudStack setup is slightly different: Every VM gets a public IP directly assigned and security groups are used for access restriction policy. - -This is how our inventory looks like: - -.. code-block:: none - - [cloud-vm:children] - webserver - - [webserver] - web-01.example.com - web-02.example.com - -The default for your VMs looks like this: - -.. code-block:: yaml - - # file: group_vars/cloud-vm - --- - cs_offering: Small - cs_securitygroups: [ 'default'] - -Our webserver will also be in security group ``web``: - -.. code-block:: yaml - - # file: group_vars/webserver - --- - cs_securitygroups: [ 'default', 'web' ] - -The playbook looks like the following: - -.. code-block:: yaml - - # file: infra.yaml - --- - - name: cloud base setup - hosts: localhost - tasks: - - name: upload ssh public key - cs_sshkeypair: - name: defaultkey - public_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" - - - name: ensure security groups exist - cs_securitygroup: - name: "{{ item }}" - loop: - - default - - web - - - name: add inbound SSH to security group default - cs_securitygroup_rule: - security_group: default - start_port: "{{ item }}" - end_port: "{{ item }}" - loop: - - 22 - - - name: add inbound TCP rules to security group web - cs_securitygroup_rule: - security_group: web - start_port: "{{ item }}" - end_port: "{{ item }}" - loop: - - 80 - - 443 - - - name: install VMs in the cloud - hosts: cloud-vm - tasks: - - delegate_to: localhost - block: - - name: create and run VMs on CloudStack - cs_instance: - name: "{{ inventory_hostname_short }}" - template: Linux Debian 7 64-bit 20GB Disk - service_offering: "{{ cs_offering }}" - security_groups: "{{ cs_securitygroups }}" - ssh_key: defaultkey - state: Running - register: vm - - - name: show VM IP - debug: msg="VM {{ inventory_hostname }} {{ vm.default_ip }}" - - - name: assign IP to the inventory - set_fact: ansible_ssh_host={{ vm.default_ip }} - - - name: waiting for SSH to come up - wait_for: port=22 host={{ vm.default_ip }} delay=5 - -In the first play we setup the security groups, in the second play the VMs will created be assigned to these groups. Further you see, that we assign the public IP returned from the modules to the host inventory. This is needed as we do not know the IPs we will get in advance. In a next step you would configure the DNS servers with these IPs for accessing the VMs with their DNS name. - -In the last task we wait for SSH to be accessible, so any later play would be able to access the VM by SSH without failure. diff --git a/docs/docsite/rst/scenario_guides/guide_docker.rst b/docs/docsite/rst/scenario_guides/guide_docker.rst deleted file mode 100644 index 8fe81112a0b..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_docker.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Docker Guide -============ - -The content on this page has moved. Please see the updated :ref:`ansible_collections.community.docker.docsite.scenario_guide` in the `community.docker collection `_. diff --git a/docs/docsite/rst/scenario_guides/guide_gce.rst b/docs/docsite/rst/scenario_guides/guide_gce.rst deleted file mode 100644 index 54071040e2d..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_gce.rst +++ /dev/null @@ -1,302 +0,0 @@ -Google Cloud Platform Guide -=========================== - -.. gce_intro: - -Introduction --------------------------- - -Ansible + Google have been working together on a set of auto-generated -Ansible modules designed to consistently and comprehensively cover the entirety -of the Google Cloud Platform (GCP). - -Ansible contains modules for managing Google Cloud Platform resources, -including creating instances, controlling network access, working with -persistent disks, managing load balancers, and a lot more. - -These new modules can be found under a new consistent name scheme "gcp_*" -(Note: gcp_target_proxy and gcp_url_map are legacy modules, despite the "gcp_*" -name. Please use gcp_compute_target_proxy and gcp_compute_url_map instead). - -Additionally, the gcp_compute inventory plugin can discover all -Google Compute Engine (GCE) instances -and make them automatically available in your Ansible inventory. - -You may see a collection of other GCP modules that do not conform to this -naming convention. These are the original modules primarily developed by the -Ansible community. You will find some overlapping functionality such as with -the "gce" module and the new "gcp_compute_instance" module. Either can be -used, but you may experience issues trying to use them together. - -While the community GCP modules are not going away, Google is investing effort -into the new "gcp_*" modules. Google is committed to ensuring the Ansible -community has a great experience with GCP and therefore recommends adopting -these new modules if possible. - - -Requisites ---------------- -The GCP modules require both the ``requests`` and the -``google-auth`` libraries to be installed. - -.. code-block:: bash - - $ pip install requests google-auth - -Alternatively for RHEL / CentOS, the ``python-requests`` package is also -available to satisfy ``requests`` libraries. - -.. code-block:: bash - - $ yum install python-requests - -Credentials ------------ -It's easy to create a GCP account with credentials for Ansible. You have multiple options to -get your credentials - here are two of the most common options: - -* Service Accounts (Recommended): Use JSON service accounts with specific permissions. -* Machine Accounts: Use the permissions associated with the GCP Instance you're using Ansible on. - -For the following examples, we'll be using service account credentials. - -To work with the GCP modules, you'll first need to get some credentials in the -JSON format: - -1. `Create a Service Account `_ -2. `Download JSON credentials `_ - -Once you have your credentials, there are two different ways to provide them to Ansible: - -* by specifying them directly as module parameters -* by setting environment variables - -Providing Credentials as Module Parameters -`````````````````````````````````````````` - -For the GCE modules you can specify the credentials as arguments: - -* ``auth_kind``: type of authentication being used (choices: machineaccount, serviceaccount, application) -* ``service_account_email``: email associated with the project -* ``service_account_file``: path to the JSON credentials file -* ``project``: id of the project -* ``scopes``: The specific scopes that you want the actions to use. - -For example, to create a new IP address using the ``gcp_compute_address`` module, -you can use the following configuration: - -.. code-block:: yaml - - - name: Create IP address - hosts: localhost - gather_facts: false - - vars: - service_account_file: /home/my_account.json - project: my-project - auth_kind: serviceaccount - scopes: - - https://www.googleapis.com/auth/compute - - tasks: - - - name: Allocate an IP Address - gcp_compute_address: - state: present - name: 'test-address1' - region: 'us-west1' - project: "{{ project }}" - auth_kind: "{{ auth_kind }}" - service_account_file: "{{ service_account_file }}" - scopes: "{{ scopes }}" - -Providing Credentials as Environment Variables -`````````````````````````````````````````````` - -Set the following environment variables before running Ansible in order to configure your credentials: - -.. code-block:: bash - - GCP_AUTH_KIND - GCP_SERVICE_ACCOUNT_EMAIL - GCP_SERVICE_ACCOUNT_FILE - GCP_SCOPES - -GCE Dynamic Inventory ---------------------- - -The best way to interact with your hosts is to use the gcp_compute inventory plugin, which dynamically queries GCE and tells Ansible what nodes can be managed. - -To be able to use this GCE dynamic inventory plugin, you need to enable it first by specifying the following in the ``ansible.cfg`` file: - -.. code-block:: ini - - [inventory] - enable_plugins = gcp_compute - -Then, create a file that ends in ``.gcp.yml`` in your root directory. - -The gcp_compute inventory script takes in the same authentication information as any module. - -Here's an example of a valid inventory file: - -.. code-block:: yaml - - plugin: gcp_compute - projects: - - graphite-playground - auth_kind: serviceaccount - service_account_file: /home/alexstephen/my_account.json - - -Executing ``ansible-inventory --list -i .gcp.yml`` will create a list of GCP instances that are ready to be configured using Ansible. - -Create an instance -`````````````````` - -The full range of GCP modules provide the ability to create a wide variety of -GCP resources with the full support of the entire GCP API. - -The following playbook creates a GCE Instance. This instance relies on other GCP -resources like Disk. By creating other resources separately, we can give as -much detail as necessary about how we want to configure the other resources, for example -formatting of the Disk. By registering it to a variable, we can simply insert the -variable into the instance task. The gcp_compute_instance module will figure out the -rest. - -.. code-block:: yaml - - - name: Create an instance - hosts: localhost - gather_facts: false - vars: - gcp_project: my-project - gcp_cred_kind: serviceaccount - gcp_cred_file: /home/my_account.json - zone: "us-central1-a" - region: "us-central1" - - tasks: - - name: create a disk - gcp_compute_disk: - name: 'disk-instance' - size_gb: 50 - source_image: 'projects/ubuntu-os-cloud/global/images/family/ubuntu-1604-lts' - zone: "{{ zone }}" - project: "{{ gcp_project }}" - auth_kind: "{{ gcp_cred_kind }}" - service_account_file: "{{ gcp_cred_file }}" - scopes: - - https://www.googleapis.com/auth/compute - state: present - register: disk - - name: create a address - gcp_compute_address: - name: 'address-instance' - region: "{{ region }}" - project: "{{ gcp_project }}" - auth_kind: "{{ gcp_cred_kind }}" - service_account_file: "{{ gcp_cred_file }}" - scopes: - - https://www.googleapis.com/auth/compute - state: present - register: address - - name: create a instance - gcp_compute_instance: - state: present - name: test-vm - machine_type: n1-standard-1 - disks: - - auto_delete: true - boot: true - source: "{{ disk }}" - network_interfaces: - - network: null # use default - access_configs: - - name: 'External NAT' - nat_ip: "{{ address }}" - type: 'ONE_TO_ONE_NAT' - zone: "{{ zone }}" - project: "{{ gcp_project }}" - auth_kind: "{{ gcp_cred_kind }}" - service_account_file: "{{ gcp_cred_file }}" - scopes: - - https://www.googleapis.com/auth/compute - register: instance - - - name: Wait for SSH to come up - wait_for: host={{ address.address }} port=22 delay=10 timeout=60 - - - name: Add host to groupname - add_host: hostname={{ address.address }} groupname=new_instances - - - - name: Manage new instances - hosts: new_instances - connection: ssh - become: True - roles: - - base_configuration - - production_server - -Note that use of the "add_host" module above creates a temporary, in-memory group. This means that a play in the same playbook can then manage machines -in the 'new_instances' group, if so desired. Any sort of arbitrary configuration is possible at this point. - -For more information about Google Cloud, please visit the `Google Cloud website `_. - -Migration Guides ----------------- - -gce.py -> gcp_compute_instance.py -````````````````````````````````` -As of Ansible 2.8, we're encouraging everyone to move from the ``gce`` module to the -``gcp_compute_instance`` module. The ``gcp_compute_instance`` module has better -support for all of GCP's features, fewer dependencies, more flexibility, and -better supports GCP's authentication systems. - -The ``gcp_compute_instance`` module supports all of the features of the ``gce`` -module (and more!). Below is a mapping of ``gce`` fields over to -``gcp_compute_instance`` fields. - -============================ ========================================== ====================== - gce.py gcp_compute_instance.py Notes -============================ ========================================== ====================== - state state/status State on gce has multiple values: "present", "absent", "stopped", "started", "terminated". State on gcp_compute_instance is used to describe if the instance exists (present) or does not (absent). Status is used to describe if the instance is "started", "stopped" or "terminated". - image disks[].initialize_params.source_image You'll need to create a single disk using the disks[] parameter and set it to be the boot disk (disks[].boot = true) - image_family disks[].initialize_params.source_image See above. - external_projects disks[].initialize_params.source_image The name of the source_image will include the name of the project. - instance_names Use a loop or multiple tasks. Using loops is a more Ansible-centric way of creating multiple instances and gives you the most flexibility. - service_account_email service_accounts[].email This is the service_account email address that you want the instance to be associated with. It is not the service_account email address that is used for the credentials necessary to create the instance. - service_account_permissions service_accounts[].scopes These are the permissions you want to grant to the instance. - pem_file Not supported. We recommend using JSON service account credentials instead of PEM files. - credentials_file service_account_file - project_id project - name name This field does not accept an array of names. Use a loop to create multiple instances. - num_instances Use a loop For maximum flexibility, we're encouraging users to use Ansible features to create multiple instances, rather than letting the module do it for you. - network network_interfaces[].network - subnetwork network_interfaces[].subnetwork - persistent_boot_disk disks[].type = 'PERSISTENT' - disks disks[] - ip_forward can_ip_forward - external_ip network_interfaces[].access_configs.nat_ip This field takes multiple types of values. You can create an IP address with ``gcp_compute_address`` and place the name/output of the address here. You can also place the string value of the IP address's GCP name or the actual IP address. - disks_auto_delete disks[].auto_delete - preemptible scheduling.preemptible - disk_size disks[].initialize_params.disk_size_gb -============================ ========================================== ====================== - -An example playbook is below: - -.. code:: yaml - - gcp_compute_instance: - name: "{{ item }}" - machine_type: n1-standard-1 - ... # any other settings - zone: us-central1-a - project: "my-project" - auth_kind: "service_account_file" - service_account_file: "~/my_account.json" - state: present - loop: - - instance-1 - - instance-2 diff --git a/docs/docsite/rst/scenario_guides/guide_infoblox.rst b/docs/docsite/rst/scenario_guides/guide_infoblox.rst deleted file mode 100644 index c7227c50b53..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_infoblox.rst +++ /dev/null @@ -1,292 +0,0 @@ -.. _nios_guide: - -************************ - Infoblox Guide -************************ - -.. contents:: Topics - -This guide describes how to use Ansible with the Infoblox Network Identity Operating System (NIOS). With Ansible integration, you can use Ansible playbooks to automate Infoblox Core Network Services for IP address management (IPAM), DNS, and inventory tracking. - -You can review simple example tasks in the documentation for any of the :ref:`NIOS modules ` or look at the `Use cases with modules`_ section for more elaborate examples. See the `Infoblox `_ website for more information on the Infoblox product. - -.. note:: You can retrieve most of the example playbooks used in this guide from the `network-automation/infoblox_ansible `_ GitHub repository. - -Prerequisites -============= -Before using Ansible ``nios`` modules with Infoblox, you must install the ``infoblox-client`` on your Ansible control node: - -.. code-block:: bash - - $ sudo pip install infoblox-client - -.. note:: - You need an NIOS account with the WAPI feature enabled to use Ansible with Infoblox. - -.. _nios_credentials: - -Credentials and authenticating -============================== - -To use Infoblox ``nios`` modules in playbooks, you need to configure the credentials to access your Infoblox system. The examples in this guide use credentials stored in ``/group_vars/nios.yml``. Replace these values with your Infoblox credentials: - -.. code-block:: yaml - - --- - nios_provider: - host: 192.0.0.2 - username: admin - password: ansible - -NIOS lookup plugins -=================== - -Ansible includes the following lookup plugins for NIOS: - -- :ref:`nios ` Uses the Infoblox WAPI API to fetch NIOS specified objects, for example network views, DNS views, and host records. -- :ref:`nios_next_ip ` Provides the next available IP address from a network. You'll see an example of this in `Creating a host record`_. -- :ref:`nios_next_network ` - Returns the next available network range for a network-container. - -You must run the NIOS lookup plugins locally by specifying ``connection: local``. See :ref:`lookup plugins ` for more detail. - - -Retrieving all network views ----------------------------- - -To retrieve all network views and save them in a variable, use the :ref:`set_fact ` module with the :ref:`nios ` lookup plugin: - -.. code-block:: yaml - - --- - - hosts: nios - connection: local - tasks: - - name: fetch all networkview objects - set_fact: - networkviews: "{{ lookup('nios', 'networkview', provider=nios_provider) }}" - - - name: check the networkviews - debug: - var: networkviews - - -Retrieving a host record ------------------------- - -To retrieve a set of host records, use the ``set_fact`` module with the ``nios`` lookup plugin and include a filter for the specific hosts you want to retrieve: - -.. code-block:: yaml - - --- - - hosts: nios - connection: local - tasks: - - name: fetch host leaf01 - set_fact: - host: "{{ lookup('nios', 'record:host', filter={'name': 'leaf01.ansible.com'}, provider=nios_provider) }}" - - - name: check the leaf01 return variable - debug: - var: host - - - name: debug specific variable (ipv4 address) - debug: - var: host.ipv4addrs[0].ipv4addr - - - name: fetch host leaf02 - set_fact: - host: "{{ lookup('nios', 'record:host', filter={'name': 'leaf02.ansible.com'}, provider=nios_provider) }}" - - - name: check the leaf02 return variable - debug: - var: host - - -If you run this ``get_host_record.yml`` playbook, you should see results similar to the following: - -.. code-block:: none - - $ ansible-playbook get_host_record.yml - - PLAY [localhost] *************************************************************************************** - - TASK [fetch host leaf01] ****************************************************************************** - ok: [localhost] - - TASK [check the leaf01 return variable] ************************************************************* - ok: [localhost] => { - < ...output shortened...> - "host": { - "ipv4addrs": [ - { - "configure_for_dhcp": false, - "host": "leaf01.ansible.com", - } - ], - "name": "leaf01.ansible.com", - "view": "default" - } - } - - TASK [debug specific variable (ipv4 address)] ****************************************************** - ok: [localhost] => { - "host.ipv4addrs[0].ipv4addr": "192.168.1.11" - } - - TASK [fetch host leaf02] ****************************************************************************** - ok: [localhost] - - TASK [check the leaf02 return variable] ************************************************************* - ok: [localhost] => { - < ...output shortened...> - "host": { - "ipv4addrs": [ - { - "configure_for_dhcp": false, - "host": "leaf02.example.com", - "ipv4addr": "192.168.1.12" - } - ], - } - } - - PLAY RECAP ****************************************************************************************** - localhost : ok=5 changed=0 unreachable=0 failed=0 - -The output above shows the host record for ``leaf01.ansible.com`` and ``leaf02.ansible.com`` that were retrieved by the ``nios`` lookup plugin. This playbook saves the information in variables which you can use in other playbooks. This allows you to use Infoblox as a single source of truth to gather and use information that changes dynamically. See :ref:`playbooks_variables` for more information on using Ansible variables. See the :ref:`nios ` examples for more data options that you can retrieve. - -You can access these playbooks at `Infoblox lookup playbooks `_. - -Use cases with modules -====================== - -You can use the ``nios`` modules in tasks to simplify common Infoblox workflows. Be sure to set up your :ref:`NIOS credentials` before following these examples. - -Configuring an IPv4 network ---------------------------- - -To configure an IPv4 network, use the :ref:`nios_network ` module: - -.. code-block:: yaml - - --- - - hosts: nios - connection: local - tasks: - - name: Create a network on the default network view - nios_network: - network: 192.168.100.0/24 - comment: sets the IPv4 network - options: - - name: domain-name - value: ansible.com - state: present - provider: "{{nios_provider}}" - -Notice the last parameter, ``provider``, uses the variable ``nios_provider`` defined in the ``group_vars/`` directory. - -Creating a host record ----------------------- - -To create a host record named `leaf03.ansible.com` on the newly-created IPv4 network: - -.. code-block:: yaml - - --- - - hosts: nios - connection: local - tasks: - - name: configure an IPv4 host record - nios_host_record: - name: leaf03.ansible.com - ipv4addrs: - - ipv4addr: - "{{ lookup('nios_next_ip', '192.168.100.0/24', provider=nios_provider)[0] }}" - state: present - provider: "{{nios_provider}}" - -Notice the IPv4 address in this example uses the :ref:`nios_next_ip ` lookup plugin to find the next available IPv4 address on the network. - -Creating a forward DNS zone ---------------------------- - -To configure a forward DNS zone use, the ``nios_zone`` module: - -.. code-block:: yaml - - --- - - hosts: nios - connection: local - tasks: - - name: Create a forward DNS zone called ansible-test.com - nios_zone: - name: ansible-test.com - comment: local DNS zone - state: present - provider: "{{ nios_provider }}" - -Creating a reverse DNS zone ---------------------------- - -To configure a reverse DNS zone: - -.. code-block:: yaml - - --- - - hosts: nios - connection: local - tasks: - - name: configure a reverse mapping zone on the system using IPV6 zone format - nios_zone: - name: 100::1/128 - zone_format: IPV6 - state: present - provider: "{{ nios_provider }}" - -Dynamic inventory script -======================== - -You can use the Infoblox dynamic inventory script to import your network node inventory with Infoblox NIOS. To gather the inventory from Infoblox, you need two files: - -- `infoblox.yaml `_ - A file that specifies the NIOS provider arguments and optional filters. - -- `infoblox.py `_ - The python script that retrieves the NIOS inventory. - -.. note:: - - Please note that the inventory script only works when Ansible 2.9, 2.10 or 3 have been installed. The inventory script will eventually be removed from `community.general `_, and will not work if `community.general` is only installed with `ansible-galaxy collection install`. Please use the inventory plugin from `infoblox.nios_modules `_ instead. - -To use the Infoblox dynamic inventory script: - -#. Download the ``infoblox.yaml`` file and save it in the ``/etc/ansible`` directory. - -#. Modify the ``infoblox.yaml`` file with your NIOS credentials. - -#. Download the ``infoblox.py`` file and save it in the ``/etc/ansible/hosts`` directory. - -#. Change the permissions on the ``infoblox.py`` file to make the file an executable: - -.. code-block:: bash - - $ sudo chmod +x /etc/ansible/hosts/infoblox.py - -You can optionally use ``./infoblox.py --list`` to test the script. After a few minutes, you should see your Infoblox inventory in JSON format. You can explicitly use the Infoblox dynamic inventory script as follows: - -.. code-block:: bash - - $ ansible -i infoblox.py all -m ping - -You can also implicitly use the Infoblox dynamic inventory script by including it in your inventory directory (``etc/ansible/hosts`` by default). See :ref:`dynamic_inventory` for more details. - -.. seealso:: - - `Infoblox website `_ - The Infoblox website - `Infoblox and Ansible Deployment Guide `_ - The deployment guide for Ansible integration provided by Infoblox. - `Infoblox Integration in Ansible 2.5 `_ - Ansible blog post about Infoblox. - :ref:`Ansible NIOS modules ` - The list of supported NIOS modules, with examples. - `Infoblox Ansible Examples `_ - Infoblox example playbooks. diff --git a/docs/docsite/rst/scenario_guides/guide_meraki.rst b/docs/docsite/rst/scenario_guides/guide_meraki.rst deleted file mode 100644 index a99e569d0e2..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_meraki.rst +++ /dev/null @@ -1,193 +0,0 @@ -.. _meraki_guide: - -****************** -Cisco Meraki Guide -****************** - -.. contents:: - :local: - - -.. _meraki_guide_intro: - -What is Cisco Meraki? -===================== - -Cisco Meraki is an easy-to-use, cloud-based, network infrastructure platform for enterprise environments. While most network hardware uses command-line interfaces (CLIs) for configuration, Meraki uses an easy-to-use Dashboard hosted in the Meraki cloud. No on-premises management hardware or software is required - only the network infrastructure to run your business. - -MS Switches ------------ - -Meraki MS switches come in multiple flavors and form factors. Meraki switches support 10/100/1000/10000 ports, as well as Cisco's mGig technology for 2.5/5/10Gbps copper connectivity. 8, 24, and 48 port flavors are available with PoE (802.3af/802.3at/UPoE) available on many models. - -MX Firewalls ------------- - -Meraki's MX firewalls support full layer 3-7 deep packet inspection. MX firewalls are compatible with a variety of VPN technologies including IPSec, SSL VPN, and Meraki's easy-to-use AutoVPN. - -MR Wireless Access Points -------------------------- - -MR access points are enterprise-class, high-performance access points for the enterprise. MR access points have MIMO technology and integrated beamforming built-in for high performance applications. BLE allows for advanced location applications to be developed with no on-premises analytics platforms. - -Using the Meraki modules -======================== - -Meraki modules provide a user-friendly interface to manage your Meraki environment using Ansible. For example, details about SNMP settings for a particular organization can be discovered using the module `meraki_snmp `. - -.. code-block:: yaml - - - name: Query SNMP settings - meraki_snmp: - api_key: abc123 - org_name: AcmeCorp - state: query - delegate_to: localhost - -Information about a particular object can be queried. For example, the `meraki_admin ` module supports - -.. code-block:: yaml - - - name: Gather information about Jane Doe - meraki_admin: - api_key: abc123 - org_name: AcmeCorp - state: query - email: janedoe@email.com - delegate_to: localhost - -Common Parameters -================= - -All Ansible Meraki modules support the following parameters which affect communication with the Meraki Dashboard API. Most of these should only be used by Meraki developers and not the general public. - - host - Hostname or IP of Meraki Dashboard. - - use_https - Specifies whether communication should be over HTTPS. (Defaults to ``true``) - - use_proxy - Whether to use a proxy for any communication. - - validate_certs - Determine whether certificates should be validated or trusted. (Defaults to ``true``) - -These are the common parameters which are used for most every module. - - org_name - Name of organization to perform actions in. - - org_id - ID of organization to perform actions in. - - net_name - Name of network to perform actions in. - - net_id - ID of network to perform actions in. - - state - General specification of what action to take. ``query`` does lookups. ``present`` creates or edits. ``absent`` deletes. - -.. hint:: Use the ``org_id`` and ``net_id`` parameters when possible. ``org_name`` and ``net_name`` require additional behind-the-scenes API calls to learn the ID values. ``org_id`` and ``net_id`` will perform faster. - -Meraki Authentication -===================== - -All API access with the Meraki Dashboard requires an API key. An API key can be generated from the organization's settings page. Each play in a playbook requires the ``api_key`` parameter to be specified. - -The "Vault" feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See :ref:`playbooks_vault` for more information. - -Meraki's API returns a 404 error if the API key is not correct. It does not provide any specific error saying the key is incorrect. If you receive a 404 error, check the API key first. - -Returned Data Structures -======================== - -Meraki and its related Ansible modules return most information in the form of a list. For example, this is returned information by ``meraki_admin`` querying administrators. It returns a list even though there's only one. - -.. code-block:: json - - [ - { - "orgAccess": "full", - "name": "John Doe", - "tags": [], - "networks": [], - "email": "john@doe.com", - "id": "12345677890" - } - ] - -Handling Returned Data -====================== - -Since Meraki's response data uses lists instead of properly keyed dictionaries for responses, certain strategies should be used when querying data for particular information. For many situations, use the ``selectattr()`` Jinja2 function. - -Merging Existing and New Data -============================= - -Ansible's Meraki modules do not allow for manipulating data. For example, you may need to insert a rule in the middle of a firewall ruleset. Ansible and the Meraki modules lack a way to directly merge to manipulate data. However, a playlist can use a few tasks to split the list where you need to insert a rule and then merge them together again with the new rule added. The steps involved are as follows: - -1. Create blank "front" and "back" lists. - :: - - vars: - - front_rules: [] - - back_rules: [] -2. Get existing firewall rules from Meraki and create a new variable. - :: - - - name: Get firewall rules - meraki_mx_l3_firewall: - auth_key: abc123 - org_name: YourOrg - net_name: YourNet - state: query - delegate_to: localhost - register: rules - - set_fact: - original_ruleset: '{{rules.data}}' -3. Write the new rule. The new rule needs to be in a list so it can be merged with other lists in an upcoming step. The blank `-` puts the rule in a list so it can be merged. - :: - - - set_fact: - new_rule: - - - - comment: Block traffic to server - src_cidr: 192.0.1.0/24 - src_port: any - dst_cidr: 192.0.1.2/32 - dst_port: any - protocol: any - policy: deny -4. Split the rules into two lists. This assumes the existing ruleset is 2 rules long. - :: - - - set_fact: - front_rules: '{{front_rules + [ original_ruleset[:1] ]}}' - - set_fact: - back_rules: '{{back_rules + [ original_ruleset[1:] ]}}' -5. Merge rules with the new rule in the middle. - :: - - - set_fact: - new_ruleset: '{{front_rules + new_rule + back_rules}}' -6. Upload new ruleset to Meraki. - :: - - - name: Set two firewall rules - meraki_mx_l3_firewall: - auth_key: abc123 - org_name: YourOrg - net_name: YourNet - state: present - rules: '{{ new_ruleset }}' - delegate_to: localhost - -Error Handling -============== - -Ansible's Meraki modules will often fail if improper or incompatible parameters are specified. However, there will likely be scenarios where the module accepts the information but the Meraki API rejects the data. If this happens, the error will be returned in the ``body`` field for HTTP status of 400 return code. - -Meraki's API returns a 404 error if the API key is not correct. It does not provide any specific error saying the key is incorrect. If you receive a 404 error, check the API key first. 404 errors can also occur if improper object IDs (ex. ``org_id``) are specified. diff --git a/docs/docsite/rst/scenario_guides/guide_online.rst b/docs/docsite/rst/scenario_guides/guide_online.rst deleted file mode 100644 index 2c181a949c1..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_online.rst +++ /dev/null @@ -1,41 +0,0 @@ -**************** -Online.net Guide -**************** - -Introduction -============ - -Online is a French hosting company mainly known for providing bare-metal servers named Dedibox. -Check it out: `https://www.online.net/en `_ - -Dynamic inventory for Online resources --------------------------------------- - -Ansible has a dynamic inventory plugin that can list your resources. - -1. Create a YAML configuration such as ``online_inventory.yml`` with this content: - -.. code-block:: yaml - - plugin: online - -2. Set your ``ONLINE_TOKEN`` environment variable with your token. - You need to open an account and log into it before you can get a token. - You can find your token at the following page: `https://console.online.net/en/api/access `_ - -3. You can test that your inventory is working by running: - -.. code-block:: bash - - $ ansible-inventory -v -i online_inventory.yml --list - - -4. Now you can run your playbook or any other module with this inventory: - -.. code-block:: console - - $ ansible all -i online_inventory.yml -m ping - sd-96735 | SUCCESS => { - "changed": false, - "ping": "pong" - } diff --git a/docs/docsite/rst/scenario_guides/guide_oracle.rst b/docs/docsite/rst/scenario_guides/guide_oracle.rst deleted file mode 100644 index 170ea9031ba..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_oracle.rst +++ /dev/null @@ -1,103 +0,0 @@ -=================================== -Oracle Cloud Infrastructure Guide -=================================== - -************ -Introduction -************ - -Oracle provides a number of Ansible modules to interact with Oracle Cloud Infrastructure (OCI). In this guide, we will explain how you can use these modules to orchestrate, provision and configure your infrastructure on OCI. - -************ -Requirements -************ -To use the OCI Ansible modules, you must have the following prerequisites on your control node, the computer from which Ansible playbooks are executed. - -1. `An Oracle Cloud Infrastructure account. `_ - -2. A user created in that account, in a security group with a policy that grants the necessary permissions for working with resources in those compartments. For guidance, see `How Policies Work `_. - -3. The necessary credentials and OCID information. - -************ -Installation -************ -1. Install the Oracle Cloud Infrastructure Python SDK (`detailed installation instructions `_): - -.. code-block:: bash - - pip install oci - -2. Install the Ansible OCI Modules in one of two ways: - -a. From Galaxy: - -.. code-block:: bash - - ansible-galaxy install oracle.oci_ansible_modules - -b. From GitHub: - -.. code-block:: bash - - $ git clone https://github.com/oracle/oci-ansible-modules.git - -.. code-block:: bash - - $ cd oci-ansible-modules - - -Run one of the following commands: - -- If Ansible is installed only for your user: - -.. code-block:: bash - - $ ./install.py - -- If Ansible is installed as root: - -.. code-block:: bash - - $ sudo ./install.py - -************* -Configuration -************* - -When creating and configuring Oracle Cloud Infrastructure resources, Ansible modules use the authentication information outlined `here `_. -. - -******** -Examples -******** -Launch a compute instance -========================= -This `sample launch playbook `_ -launches a public Compute instance and then accesses the instance from an Ansible module over an SSH connection. The sample illustrates how to: - -- Generate a temporary, host-specific SSH key pair. -- Specify the public key from the key pair for connecting to the instance, and then launch the instance. -- Connect to the newly launched instance using SSH. - -Create and manage Autonomous Data Warehouses -============================================ -This `sample warehouse playbook `_ creates an Autonomous Data Warehouse and manage its lifecycle. The sample shows how to: - -- Set up an Autonomous Data Warehouse. -- List all of the Autonomous Data Warehouse instances available in a compartment, filtered by the display name. -- Get the "facts" for a specified Autonomous Data Warehouse. -- Stop and start an Autonomous Data Warehouse instance. -- Delete an Autonomous Data Warehouse instance. - -Create and manage Autonomous Transaction Processing -=================================================== -This `sample playbook `_ -creates an Autonomous Transaction Processing database and manage its lifecycle. The sample shows how to: - -- Set up an Autonomous Transaction Processing database instance. -- List all of the Autonomous Transaction Processing instances in a compartment, filtered by the display name. -- Get the "facts" for a specified Autonomous Transaction Processing instance. -- Delete an Autonomous Transaction Processing database instance. - -You can find more examples here: `Sample Ansible Playbooks `_. diff --git a/docs/docsite/rst/scenario_guides/guide_packet.rst b/docs/docsite/rst/scenario_guides/guide_packet.rst deleted file mode 100644 index 512620c2454..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_packet.rst +++ /dev/null @@ -1,311 +0,0 @@ -********************************** -Packet.net Guide -********************************** - -Introduction -============ - -`Packet.net `_ is a bare metal infrastructure host that's supported by Ansible (>=2.3) through a dynamic inventory script and two cloud modules. The two modules are: - -- packet_sshkey: adds a public SSH key from file or value to the Packet infrastructure. Every subsequently-created device will have this public key installed in .ssh/authorized_keys. -- packet_device: manages servers on Packet. You can use this module to create, restart and delete devices. - -Note, this guide assumes you are familiar with Ansible and how it works. If you're not, have a look at their :ref:`docs ` before getting started. - -Requirements -============ - -The Packet modules and inventory script connect to the Packet API using the packet-python package. You can install it with pip: - -.. code-block:: bash - - $ pip install packet-python - -In order to check the state of devices created by Ansible on Packet, it's a good idea to install one of the `Packet CLI clients `_. Otherwise you can check them through the `Packet portal `_. - -To use the modules and inventory script you'll need a Packet API token. You can generate an API token through the Packet portal `here `__. The simplest way to authenticate yourself is to set the Packet API token in an environment variable: - -.. code-block:: bash - - $ export PACKET_API_TOKEN=Bfse9F24SFtfs423Gsd3ifGsd43sSdfs - -If you're not comfortable exporting your API token, you can pass it as a parameter to the modules. - -On Packet, devices and reserved IP addresses belong to `projects `_. In order to use the packet_device module, you need to specify the UUID of the project in which you want to create or manage devices. You can find a project's UUID in the Packet portal `here `_ (it's just under the project table) or through one of the available `CLIs `_. - - -If you want to use a new SSH key pair in this tutorial, you can generate it to ``./id_rsa`` and ``./id_rsa.pub`` as: - -.. code-block:: bash - - $ ssh-keygen -t rsa -f ./id_rsa - -If you want to use an existing key pair, just copy the private and public key over to the playbook directory. - - -Device Creation -=============== - -The following code block is a simple playbook that creates one `Type 0 `_ server (the 'plan' parameter). You have to supply 'plan' and 'operating_system'. 'location' defaults to 'ewr1' (Parsippany, NJ). You can find all the possible values for the parameters through a `CLI client `_. - -.. code-block:: yaml - - # playbook_create.yml - - - name: create ubuntu device - hosts: localhost - tasks: - - - packet_sshkey: - key_file: ./id_rsa.pub - label: tutorial key - - - packet_device: - project_id: - hostnames: myserver - operating_system: ubuntu_16_04 - plan: baremetal_0 - facility: sjc1 - -After running ``ansible-playbook playbook_create.yml``, you should have a server provisioned on Packet. You can verify through a CLI or in the `Packet portal `__. - -If you get an error with the message "failed to set machine state present, error: Error 404: Not Found", please verify your project UUID. - - -Updating Devices -================ - -The two parameters used to uniquely identify Packet devices are: "device_ids" and "hostnames". Both parameters accept either a single string (later converted to a one-element list), or a list of strings. - -The 'device_ids' and 'hostnames' parameters are mutually exclusive. The following values are all acceptable: - -- device_ids: a27b7a83-fc93-435b-a128-47a5b04f2dcf - -- hostnames: mydev1 - -- device_ids: [a27b7a83-fc93-435b-a128-47a5b04f2dcf, 4887130f-0ccd-49a0-99b0-323c1ceb527b] - -- hostnames: [mydev1, mydev2] - -In addition, hostnames can contain a special '%d' formatter along with a 'count' parameter that lets you easily expand hostnames that follow a simple name and number pattern; in other words, ``hostnames: "mydev%d", count: 2`` will expand to [mydev1, mydev2]. - -If your playbook acts on existing Packet devices, you can only pass the 'hostname' and 'device_ids' parameters. The following playbook shows how you can reboot a specific Packet device by setting the 'hostname' parameter: - -.. code-block:: yaml - - # playbook_reboot.yml - - - name: reboot myserver - hosts: localhost - tasks: - - - packet_device: - project_id: - hostnames: myserver - state: rebooted - -You can also identify specific Packet devices with the 'device_ids' parameter. The device's UUID can be found in the `Packet Portal `_ or by using a `CLI `_. The following playbook removes a Packet device using the 'device_ids' field: - -.. code-block:: yaml - - # playbook_remove.yml - - - name: remove a device - hosts: localhost - tasks: - - - packet_device: - project_id: - device_ids: - state: absent - - -More Complex Playbooks -====================== - -In this example, we'll create a CoreOS cluster with `user data `_. - - -The CoreOS cluster will use `etcd `_ for discovery of other servers in the cluster. Before provisioning your servers, you'll need to generate a discovery token for your cluster: - -.. code-block:: bash - - $ curl -w "\n" 'https://discovery.etcd.io/new?size=3' - -The following playbook will create an SSH key, 3 Packet servers, and then wait until SSH is ready (or until 5 minutes passed). Make sure to substitute the discovery token URL in 'user_data', and the 'project_id' before running ``ansible-playbook``. Also, feel free to change 'plan' and 'facility'. - -.. code-block:: yaml - - # playbook_coreos.yml - - - name: Start 3 CoreOS nodes in Packet and wait until SSH is ready - hosts: localhost - tasks: - - - packet_sshkey: - key_file: ./id_rsa.pub - label: new - - - packet_device: - hostnames: [coreos-one, coreos-two, coreos-three] - operating_system: coreos_beta - plan: baremetal_0 - facility: ewr1 - project_id: - wait_for_public_IPv: 4 - user_data: | - #cloud-config - coreos: - etcd2: - discovery: https://discovery.etcd.io/ - advertise-client-urls: http://$private_ipv4:2379,http://$private_ipv4:4001 - initial-advertise-peer-urls: http://$private_ipv4:2380 - listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001 - listen-peer-urls: http://$private_ipv4:2380 - fleet: - public-ip: $private_ipv4 - units: - - name: etcd2.service - command: start - - name: fleet.service - command: start - register: newhosts - - - name: wait for ssh - wait_for: - delay: 1 - host: "{{ item.public_ipv4 }}" - port: 22 - state: started - timeout: 500 - loop: "{{ newhosts.results[0].devices }}" - - -As with most Ansible modules, the default states of the Packet modules are idempotent, meaning the resources in your project will remain the same after re-runs of a playbook. Thus, we can keep the ``packet_sshkey`` module call in our playbook. If the public key is already in your Packet account, the call will have no effect. - -The second module call provisions 3 Packet Type 0 (specified using the 'plan' parameter) servers in the project identified by the 'project_id' parameter. The servers are all provisioned with CoreOS beta (the 'operating_system' parameter) and are customized with cloud-config user data passed to the 'user_data' parameter. - -The ``packet_device`` module has a ``wait_for_public_IPv`` that is used to specify the version of the IP address to wait for (valid values are ``4`` or ``6`` for IPv4 or IPv6). If specified, Ansible will wait until the GET API call for a device contains an Internet-routeable IP address of the specified version. When referring to an IP address of a created device in subsequent module calls, it's wise to use the ``wait_for_public_IPv`` parameter, or ``state: active`` in the packet_device module call. - -Run the playbook: - -.. code-block:: bash - - $ ansible-playbook playbook_coreos.yml - -Once the playbook quits, your new devices should be reachable through SSH. Try to connect to one and check if etcd has started properly: - -.. code-block:: bash - - tomk@work $ ssh -i id_rsa core@$one_of_the_servers_ip - core@coreos-one ~ $ etcdctl cluster-health - -Once you create a couple of devices, you might appreciate the dynamic inventory script... - - -Dynamic Inventory Script -======================== - -The dynamic inventory script queries the Packet API for a list of hosts, and exposes it to Ansible so you can easily identify and act on Packet devices. - -You can find it in Ansible Community General Collection's git repo at `scripts/inventory/packet_net.py `_. - -The inventory script is configurable through an `ini file `_. - -If you want to use the inventory script, you must first export your Packet API token to a PACKET_API_TOKEN environment variable. - -You can either copy the inventory and ini config out from the cloned git repo, or you can download it to your working directory like so: - -.. code-block:: bash - - $ wget https://raw.githubusercontent.com/ansible-community/contrib-scripts/main/inventory/packet_net.py - $ chmod +x packet_net.py - $ wget https://raw.githubusercontent.com/ansible-community/contrib-scripts/main/inventory/packet_net.ini - -In order to understand what the inventory script gives to Ansible you can run: - -.. code-block:: bash - - $ ./packet_net.py --list - -It should print a JSON document looking similar to following trimmed dictionary: - -.. code-block:: json - - { - "_meta": { - "hostvars": { - "147.75.64.169": { - "packet_billing_cycle": "hourly", - "packet_created_at": "2017-02-09T17:11:26Z", - "packet_facility": "ewr1", - "packet_hostname": "coreos-two", - "packet_href": "/devices/d0ab8972-54a8-4bff-832b-28549d1bec96", - "packet_id": "d0ab8972-54a8-4bff-832b-28549d1bec96", - "packet_locked": false, - "packet_operating_system": "coreos_beta", - "packet_plan": "baremetal_0", - "packet_state": "active", - "packet_updated_at": "2017-02-09T17:16:35Z", - "packet_user": "core", - "packet_userdata": "#cloud-config\ncoreos:\n etcd2:\n discovery: https://discovery.etcd.io/e0c8a4a9b8fe61acd51ec599e2a4f68e\n advertise-client-urls: http://$private_ipv4:2379,http://$private_ipv4:4001\n initial-advertise-peer-urls: http://$private_ipv4:2380\n listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001\n listen-peer-urls: http://$private_ipv4:2380\n fleet:\n public-ip: $private_ipv4\n units:\n - name: etcd2.service\n command: start\n - name: fleet.service\n command: start" - } - } - }, - "baremetal_0": [ - "147.75.202.255", - "147.75.202.251", - "147.75.202.249", - "147.75.64.129", - "147.75.192.51", - "147.75.64.169" - ], - "coreos_beta": [ - "147.75.202.255", - "147.75.202.251", - "147.75.202.249", - "147.75.64.129", - "147.75.192.51", - "147.75.64.169" - ], - "ewr1": [ - "147.75.64.129", - "147.75.192.51", - "147.75.64.169" - ], - "sjc1": [ - "147.75.202.255", - "147.75.202.251", - "147.75.202.249" - ], - "coreos-two": [ - "147.75.64.169" - ], - "d0ab8972-54a8-4bff-832b-28549d1bec96": [ - "147.75.64.169" - ] - } - -In the ``['_meta']['hostvars']`` key, there is a list of devices (uniquely identified by their public IPv4 address) with their parameters. The other keys under ``['_meta']`` are lists of devices grouped by some parameter. Here, it is type (all devices are of type baremetal_0), operating system, and facility (ewr1 and sjc1). - -In addition to the parameter groups, there are also one-item groups with the UUID or hostname of the device. - -You can now target groups in playbooks! The following playbook will install a role that supplies resources for an Ansible target into all devices in the "coreos_beta" group: - -.. code-block:: yaml - - # playbook_bootstrap.yml - - - hosts: coreos_beta - gather_facts: false - roles: - - defunctzombie.coreos-boostrap - -Don't forget to supply the dynamic inventory in the ``-i`` argument! - -.. code-block:: bash - - $ ansible-playbook -u core -i packet_net.py playbook_bootstrap.yml - - -If you have any questions or comments let us know! help@packet.net diff --git a/docs/docsite/rst/scenario_guides/guide_rax.rst b/docs/docsite/rst/scenario_guides/guide_rax.rst deleted file mode 100644 index 439ba187250..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_rax.rst +++ /dev/null @@ -1,809 +0,0 @@ -Rackspace Cloud Guide -===================== - -.. _rax_introduction: - -Introduction -```````````` - -.. note:: Rackspace functionality in Ansible is not maintained and users should consider the `OpenStack collection `_ instead. - -Ansible contains a number of core modules for interacting with Rackspace Cloud. - -The purpose of this section is to explain how to put Ansible modules together -(and use inventory scripts) to use Ansible in a Rackspace Cloud context. - -Prerequisites for using the rax modules are minimal. In addition to ansible itself, -all of the modules require and are tested against pyrax 1.5 or higher. -You'll need this Python module installed on the execution host. - -``pyrax`` is not currently available in many operating system -package repositories, so you will likely need to install it through pip: - -.. code-block:: bash - - $ pip install pyrax - -Ansible creates an implicit localhost that executes in the same context as the ``ansible-playbook`` and the other CLI tools. -If for any reason you need or want to have it in your inventory you should do something like the following: - -.. code-block:: ini - - [localhost] - localhost ansible_connection=local ansible_python_interpreter=/usr/local/bin/python2 - -For more information see :ref:`Implicit Localhost ` - -In playbook steps, we'll typically be using the following pattern: - -.. code-block:: yaml - - - hosts: localhost - gather_facts: False - tasks: - -.. _credentials_file: - -Credentials File -```````````````` - -The `rax.py` inventory script and all `rax` modules support a standard `pyrax` credentials file that looks like: - -.. code-block:: ini - - [rackspace_cloud] - username = myraxusername - api_key = d41d8cd98f00b204e9800998ecf8427e - -Setting the environment parameter ``RAX_CREDS_FILE`` to the path of this file will help Ansible find how to load -this information. - -More information about this credentials file can be found at -https://github.com/pycontribs/pyrax/blob/master/docs/getting_started.md#authenticating - - -.. _virtual_environment: - -Running from a Python Virtual Environment (Optional) -++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Most users will not be using virtualenv, but some users, particularly Python developers sometimes like to. - -There are special considerations when Ansible is installed to a Python virtualenv, rather than the default of installing at a global scope. Ansible assumes, unless otherwise instructed, that the python binary will live at /usr/bin/python. This is done through the interpreter line in modules, however when instructed by setting the inventory variable 'ansible_python_interpreter', Ansible will use this specified path instead to find Python. This can be a cause of confusion as one may assume that modules running on 'localhost', or perhaps running through 'local_action', are using the virtualenv Python interpreter. By setting this line in the inventory, the modules will execute in the virtualenv interpreter and have available the virtualenv packages, specifically pyrax. If using virtualenv, you may wish to modify your localhost inventory definition to find this location as follows: - -.. code-block:: ini - - [localhost] - localhost ansible_connection=local ansible_python_interpreter=/path/to/ansible_venv/bin/python - -.. note:: - - pyrax may be installed in the global Python package scope or in a virtual environment. There are no special considerations to keep in mind when installing pyrax. - -.. _provisioning: - -Provisioning -```````````` - -Now for the fun parts. - -The 'rax' module provides the ability to provision instances within Rackspace Cloud. Typically the provisioning task will be performed from your Ansible control server (in our example, localhost) against the Rackspace cloud API. This is done for several reasons: - - - Avoiding installing the pyrax library on remote nodes - - No need to encrypt and distribute credentials to remote nodes - - Speed and simplicity - -.. note:: - - Authentication with the Rackspace-related modules is handled by either - specifying your username and API key as environment variables or passing - them as module arguments, or by specifying the location of a credentials - file. - -Here is a basic example of provisioning an instance in ad hoc mode: - -.. code-block:: bash - - $ ansible localhost -m rax -a "name=awx flavor=4 image=ubuntu-1204-lts-precise-pangolin wait=yes" - -Here's what it would look like in a playbook, assuming the parameters were defined in variables: - -.. code-block:: yaml - - tasks: - - name: Provision a set of instances - rax: - name: "{{ rax_name }}" - flavor: "{{ rax_flavor }}" - image: "{{ rax_image }}" - count: "{{ rax_count }}" - group: "{{ group }}" - wait: true - register: rax - delegate_to: localhost - -The rax module returns data about the nodes it creates, like IP addresses, hostnames, and login passwords. By registering the return value of the step, it is possible used this data to dynamically add the resulting hosts to inventory (temporarily, in memory). This facilitates performing configuration actions on the hosts in a follow-on task. In the following example, the servers that were successfully created using the above task are dynamically added to a group called "raxhosts", with each nodes hostname, IP address, and root password being added to the inventory. - -.. code-block:: yaml - - - name: Add the instances we created (by public IP) to the group 'raxhosts' - add_host: - hostname: "{{ item.name }}" - ansible_host: "{{ item.rax_accessipv4 }}" - ansible_password: "{{ item.rax_adminpass }}" - groups: raxhosts - loop: "{{ rax.success }}" - when: rax.action == 'create' - -With the host group now created, the next play in this playbook could now configure servers belonging to the raxhosts group. - -.. code-block:: yaml - - - name: Configuration play - hosts: raxhosts - user: root - roles: - - ntp - - webserver - -The method above ties the configuration of a host with the provisioning step. This isn't always what you want, and leads us -to the next section. - -.. _host_inventory: - -Host Inventory -`````````````` - -Once your nodes are spun up, you'll probably want to talk to them again. The best way to handle this is to use the "rax" inventory plugin, which dynamically queries Rackspace Cloud and tells Ansible what nodes you have to manage. You might want to use this even if you are spinning up cloud instances through other tools, including the Rackspace Cloud user interface. The inventory plugin can be used to group resources by metadata, region, OS, and so on. Utilizing metadata is highly recommended in "rax" and can provide an easy way to sort between host groups and roles. If you don't want to use the ``rax.py`` dynamic inventory script, you could also still choose to manually manage your INI inventory file, though this is less recommended. - -In Ansible it is quite possible to use multiple dynamic inventory plugins along with INI file data. Just put them in a common directory and be sure the scripts are chmod +x, and the INI-based ones are not. - -.. _raxpy: - -rax.py -++++++ - -To use the Rackspace dynamic inventory script, copy ``rax.py`` into your inventory directory and make it executable. You can specify a credentials file for ``rax.py`` utilizing the ``RAX_CREDS_FILE`` environment variable. - -.. note:: Dynamic inventory scripts (like ``rax.py``) are saved in ``/usr/share/ansible/inventory`` if Ansible has been installed globally. If installed to a virtualenv, the inventory scripts are installed to ``$VIRTUALENV/share/inventory``. - -.. note:: Users of :ref:`ansible_platform` will note that dynamic inventory is natively supported by the controller in the platform, and all you have to do is associate a group with your Rackspace Cloud credentials, and it will easily synchronize without going through these steps:: - - $ RAX_CREDS_FILE=~/.raxpub ansible all -i rax.py -m setup - -``rax.py`` also accepts a ``RAX_REGION`` environment variable, which can contain an individual region, or a comma separated list of regions. - -When using ``rax.py``, you will not have a 'localhost' defined in the inventory. - -As mentioned previously, you will often be running most of these modules outside of the host loop, and will need 'localhost' defined. The recommended way to do this, would be to create an ``inventory`` directory, and place both the ``rax.py`` script and a file containing ``localhost`` in it. - -Executing ``ansible`` or ``ansible-playbook`` and specifying the ``inventory`` directory instead -of an individual file, will cause ansible to evaluate each file in that directory for inventory. - -Let's test our inventory script to see if it can talk to Rackspace Cloud. - -.. code-block:: bash - - $ RAX_CREDS_FILE=~/.raxpub ansible all -i inventory/ -m setup - -Assuming things are properly configured, the ``rax.py`` inventory script will output information similar to the -following information, which will be utilized for inventory and variables. - -.. code-block:: json - - { - "ORD": [ - "test" - ], - "_meta": { - "hostvars": { - "test": { - "ansible_host": "198.51.100.1", - "rax_accessipv4": "198.51.100.1", - "rax_accessipv6": "2001:DB8::2342", - "rax_addresses": { - "private": [ - { - "addr": "192.0.2.2", - "version": 4 - } - ], - "public": [ - { - "addr": "198.51.100.1", - "version": 4 - }, - { - "addr": "2001:DB8::2342", - "version": 6 - } - ] - }, - "rax_config_drive": "", - "rax_created": "2013-11-14T20:48:22Z", - "rax_flavor": { - "id": "performance1-1", - "links": [ - { - "href": "https://ord.servers.api.rackspacecloud.com/111111/flavors/performance1-1", - "rel": "bookmark" - } - ] - }, - "rax_hostid": "e7b6961a9bd943ee82b13816426f1563bfda6846aad84d52af45a4904660cde0", - "rax_human_id": "test", - "rax_id": "099a447b-a644-471f-87b9-a7f580eb0c2a", - "rax_image": { - "id": "b211c7bf-b5b4-4ede-a8de-a4368750c653", - "links": [ - { - "href": "https://ord.servers.api.rackspacecloud.com/111111/images/b211c7bf-b5b4-4ede-a8de-a4368750c653", - "rel": "bookmark" - } - ] - }, - "rax_key_name": null, - "rax_links": [ - { - "href": "https://ord.servers.api.rackspacecloud.com/v2/111111/servers/099a447b-a644-471f-87b9-a7f580eb0c2a", - "rel": "self" - }, - { - "href": "https://ord.servers.api.rackspacecloud.com/111111/servers/099a447b-a644-471f-87b9-a7f580eb0c2a", - "rel": "bookmark" - } - ], - "rax_metadata": { - "foo": "bar" - }, - "rax_name": "test", - "rax_name_attr": "name", - "rax_networks": { - "private": [ - "192.0.2.2" - ], - "public": [ - "198.51.100.1", - "2001:DB8::2342" - ] - }, - "rax_os-dcf_diskconfig": "AUTO", - "rax_os-ext-sts_power_state": 1, - "rax_os-ext-sts_task_state": null, - "rax_os-ext-sts_vm_state": "active", - "rax_progress": 100, - "rax_status": "ACTIVE", - "rax_tenant_id": "111111", - "rax_updated": "2013-11-14T20:49:27Z", - "rax_user_id": "22222" - } - } - } - } - -.. _standard_inventory: - -Standard Inventory -++++++++++++++++++ - -When utilizing a standard ini formatted inventory file (as opposed to the inventory plugin), it may still be advantageous to retrieve discoverable hostvar information from the Rackspace API. - -This can be achieved with the ``rax_facts`` module and an inventory file similar to the following: - -.. code-block:: ini - - [test_servers] - hostname1 rax_region=ORD - hostname2 rax_region=ORD - -.. code-block:: yaml - - - name: Gather info about servers - hosts: test_servers - gather_facts: False - tasks: - - name: Get facts about servers - rax_facts: - credentials: ~/.raxpub - name: "{{ inventory_hostname }}" - region: "{{ rax_region }}" - delegate_to: localhost - - name: Map some facts - set_fact: - ansible_host: "{{ rax_accessipv4 }}" - -While you don't need to know how it works, it may be interesting to know what kind of variables are returned. - -The ``rax_facts`` module provides facts as following, which match the ``rax.py`` inventory script: - -.. code-block:: json - - { - "ansible_facts": { - "rax_accessipv4": "198.51.100.1", - "rax_accessipv6": "2001:DB8::2342", - "rax_addresses": { - "private": [ - { - "addr": "192.0.2.2", - "version": 4 - } - ], - "public": [ - { - "addr": "198.51.100.1", - "version": 4 - }, - { - "addr": "2001:DB8::2342", - "version": 6 - } - ] - }, - "rax_config_drive": "", - "rax_created": "2013-11-14T20:48:22Z", - "rax_flavor": { - "id": "performance1-1", - "links": [ - { - "href": "https://ord.servers.api.rackspacecloud.com/111111/flavors/performance1-1", - "rel": "bookmark" - } - ] - }, - "rax_hostid": "e7b6961a9bd943ee82b13816426f1563bfda6846aad84d52af45a4904660cde0", - "rax_human_id": "test", - "rax_id": "099a447b-a644-471f-87b9-a7f580eb0c2a", - "rax_image": { - "id": "b211c7bf-b5b4-4ede-a8de-a4368750c653", - "links": [ - { - "href": "https://ord.servers.api.rackspacecloud.com/111111/images/b211c7bf-b5b4-4ede-a8de-a4368750c653", - "rel": "bookmark" - } - ] - }, - "rax_key_name": null, - "rax_links": [ - { - "href": "https://ord.servers.api.rackspacecloud.com/v2/111111/servers/099a447b-a644-471f-87b9-a7f580eb0c2a", - "rel": "self" - }, - { - "href": "https://ord.servers.api.rackspacecloud.com/111111/servers/099a447b-a644-471f-87b9-a7f580eb0c2a", - "rel": "bookmark" - } - ], - "rax_metadata": { - "foo": "bar" - }, - "rax_name": "test", - "rax_name_attr": "name", - "rax_networks": { - "private": [ - "192.0.2.2" - ], - "public": [ - "198.51.100.1", - "2001:DB8::2342" - ] - }, - "rax_os-dcf_diskconfig": "AUTO", - "rax_os-ext-sts_power_state": 1, - "rax_os-ext-sts_task_state": null, - "rax_os-ext-sts_vm_state": "active", - "rax_progress": 100, - "rax_status": "ACTIVE", - "rax_tenant_id": "111111", - "rax_updated": "2013-11-14T20:49:27Z", - "rax_user_id": "22222" - }, - "changed": false - } - - -Use Cases -````````` - -This section covers some additional usage examples built around a specific use case. - -.. _network_and_server: - -Network and Server -++++++++++++++++++ - -Create an isolated cloud network and build a server - -.. code-block:: yaml - - - name: Build Servers on an Isolated Network - hosts: localhost - gather_facts: False - tasks: - - name: Network create request - rax_network: - credentials: ~/.raxpub - label: my-net - cidr: 192.168.3.0/24 - region: IAD - state: present - delegate_to: localhost - - - name: Server create request - rax: - credentials: ~/.raxpub - name: web%04d.example.org - flavor: 2 - image: ubuntu-1204-lts-precise-pangolin - disk_config: manual - networks: - - public - - my-net - region: IAD - state: present - count: 5 - exact_count: true - group: web - wait: true - wait_timeout: 360 - register: rax - delegate_to: localhost - -.. _complete_environment: - -Complete Environment -++++++++++++++++++++ - -Build a complete webserver environment with servers, custom networks and load balancers, install nginx and create a custom index.html - -.. code-block:: yaml - - --- - - name: Build environment - hosts: localhost - gather_facts: False - tasks: - - name: Load Balancer create request - rax_clb: - credentials: ~/.raxpub - name: my-lb - port: 80 - protocol: HTTP - algorithm: ROUND_ROBIN - type: PUBLIC - timeout: 30 - region: IAD - wait: true - state: present - meta: - app: my-cool-app - register: clb - - - name: Network create request - rax_network: - credentials: ~/.raxpub - label: my-net - cidr: 192.168.3.0/24 - state: present - region: IAD - register: network - - - name: Server create request - rax: - credentials: ~/.raxpub - name: web%04d.example.org - flavor: performance1-1 - image: ubuntu-1204-lts-precise-pangolin - disk_config: manual - networks: - - public - - private - - my-net - region: IAD - state: present - count: 5 - exact_count: true - group: web - wait: true - register: rax - - - name: Add servers to web host group - add_host: - hostname: "{{ item.name }}" - ansible_host: "{{ item.rax_accessipv4 }}" - ansible_password: "{{ item.rax_adminpass }}" - ansible_user: root - groups: web - loop: "{{ rax.success }}" - when: rax.action == 'create' - - - name: Add servers to Load balancer - rax_clb_nodes: - credentials: ~/.raxpub - load_balancer_id: "{{ clb.balancer.id }}" - address: "{{ item.rax_networks.private|first }}" - port: 80 - condition: enabled - type: primary - wait: true - region: IAD - loop: "{{ rax.success }}" - when: rax.action == 'create' - - - name: Configure servers - hosts: web - handlers: - - name: restart nginx - service: name=nginx state=restarted - - tasks: - - name: Install nginx - apt: pkg=nginx state=latest update_cache=yes cache_valid_time=86400 - notify: - - restart nginx - - - name: Ensure nginx starts on boot - service: name=nginx state=started enabled=yes - - - name: Create custom index.html - copy: content="{{ inventory_hostname }}" dest=/usr/share/nginx/www/index.html - owner=root group=root mode=0644 - -.. _rackconnect_and_manged_cloud: - -RackConnect and Managed Cloud -+++++++++++++++++++++++++++++ - -When using RackConnect version 2 or Rackspace Managed Cloud there are Rackspace automation tasks that are executed on the servers you create after they are successfully built. If your automation executes before the RackConnect or Managed Cloud automation, you can cause failures and unusable servers. - -These examples show creating servers, and ensuring that the Rackspace automation has completed before Ansible continues onwards. - -For simplicity, these examples are joined, however both are only needed when using RackConnect. When only using Managed Cloud, the RackConnect portion can be ignored. - -The RackConnect portions only apply to RackConnect version 2. - -.. _using_a_control_machine: - -Using a Control Machine -*********************** - -.. code-block:: yaml - - - name: Create an exact count of servers - hosts: localhost - gather_facts: False - tasks: - - name: Server build requests - rax: - credentials: ~/.raxpub - name: web%03d.example.org - flavor: performance1-1 - image: ubuntu-1204-lts-precise-pangolin - disk_config: manual - region: DFW - state: present - count: 1 - exact_count: true - group: web - wait: true - register: rax - - - name: Add servers to in memory groups - add_host: - hostname: "{{ item.name }}" - ansible_host: "{{ item.rax_accessipv4 }}" - ansible_password: "{{ item.rax_adminpass }}" - ansible_user: root - rax_id: "{{ item.rax_id }}" - groups: web,new_web - loop: "{{ rax.success }}" - when: rax.action == 'create' - - - name: Wait for rackconnect and managed cloud automation to complete - hosts: new_web - gather_facts: false - tasks: - - name: ensure we run all tasks from localhost - delegate_to: localhost - block: - - name: Wait for rackconnnect automation to complete - rax_facts: - credentials: ~/.raxpub - id: "{{ rax_id }}" - region: DFW - register: rax_facts - until: rax_facts.ansible_facts['rax_metadata']['rackconnect_automation_status']|default('') == 'DEPLOYED' - retries: 30 - delay: 10 - - - name: Wait for managed cloud automation to complete - rax_facts: - credentials: ~/.raxpub - id: "{{ rax_id }}" - region: DFW - register: rax_facts - until: rax_facts.ansible_facts['rax_metadata']['rax_service_level_automation']|default('') == 'Complete' - retries: 30 - delay: 10 - - - name: Update new_web hosts with IP that RackConnect assigns - hosts: new_web - gather_facts: false - tasks: - - name: Get facts about servers - rax_facts: - name: "{{ inventory_hostname }}" - region: DFW - delegate_to: localhost - - name: Map some facts - set_fact: - ansible_host: "{{ rax_accessipv4 }}" - - - name: Base Configure Servers - hosts: web - roles: - - role: users - - - role: openssh - opensshd_PermitRootLogin: "no" - - - role: ntp - -.. _using_ansible_pull: - -Using Ansible Pull -****************** - -.. code-block:: yaml - - --- - - name: Ensure Rackconnect and Managed Cloud Automation is complete - hosts: all - tasks: - - name: ensure we run all tasks from localhost - delegate_to: localhost - block: - - name: Check for completed bootstrap - stat: - path: /etc/bootstrap_complete - register: bootstrap - - - name: Get region - command: xenstore-read vm-data/provider_data/region - register: rax_region - when: bootstrap.stat.exists != True - - - name: Wait for rackconnect automation to complete - uri: - url: "https://{{ rax_region.stdout|trim }}.api.rackconnect.rackspace.com/v1/automation_status?format=json" - return_content: true - register: automation_status - when: bootstrap.stat.exists != True - until: automation_status['automation_status']|default('') == 'DEPLOYED' - retries: 30 - delay: 10 - - - name: Wait for managed cloud automation to complete - wait_for: - path: /tmp/rs_managed_cloud_automation_complete - delay: 10 - when: bootstrap.stat.exists != True - - - name: Set bootstrap completed - file: - path: /etc/bootstrap_complete - state: touch - owner: root - group: root - mode: 0400 - - - name: Base Configure Servers - hosts: all - roles: - - role: users - - - role: openssh - opensshd_PermitRootLogin: "no" - - - role: ntp - -.. _using_ansible_pull_with_xenstore: - -Using Ansible Pull with XenStore -******************************** - -.. code-block:: yaml - - --- - - name: Ensure Rackconnect and Managed Cloud Automation is complete - hosts: all - tasks: - - name: Check for completed bootstrap - stat: - path: /etc/bootstrap_complete - register: bootstrap - - - name: Wait for rackconnect_automation_status xenstore key to exist - command: xenstore-exists vm-data/user-metadata/rackconnect_automation_status - register: rcas_exists - when: bootstrap.stat.exists != True - failed_when: rcas_exists.rc|int > 1 - until: rcas_exists.rc|int == 0 - retries: 30 - delay: 10 - - - name: Wait for rackconnect automation to complete - command: xenstore-read vm-data/user-metadata/rackconnect_automation_status - register: rcas - when: bootstrap.stat.exists != True - until: rcas.stdout|replace('"', '') == 'DEPLOYED' - retries: 30 - delay: 10 - - - name: Wait for rax_service_level_automation xenstore key to exist - command: xenstore-exists vm-data/user-metadata/rax_service_level_automation - register: rsla_exists - when: bootstrap.stat.exists != True - failed_when: rsla_exists.rc|int > 1 - until: rsla_exists.rc|int == 0 - retries: 30 - delay: 10 - - - name: Wait for managed cloud automation to complete - command: xenstore-read vm-data/user-metadata/rackconnect_automation_status - register: rsla - when: bootstrap.stat.exists != True - until: rsla.stdout|replace('"', '') == 'DEPLOYED' - retries: 30 - delay: 10 - - - name: Set bootstrap completed - file: - path: /etc/bootstrap_complete - state: touch - owner: root - group: root - mode: 0400 - - - name: Base Configure Servers - hosts: all - roles: - - role: users - - - role: openssh - opensshd_PermitRootLogin: "no" - - - role: ntp - -.. _advanced_usage: - -Advanced Usage -`````````````` - -.. _awx_autoscale: - -Autoscaling with AWX or Red Hat Ansible Automation Platform -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -The GUI component of :ref:`Red Hat Ansible Automation Platform ` also contains a very nice feature for auto-scaling use cases. In this mode, a simple curl script can call -a defined URL and the server will "dial out" to the requester and configure an instance that is spinning up. This can be a great way -to reconfigure ephemeral nodes. See `the documentation on provisioning callbacks `_ for more details. - -A benefit of using the callback approach over pull mode is that job results are still centrally recorded -and less information has to be shared with remote hosts. - -.. _pending_information: - -Orchestration in the Rackspace Cloud -++++++++++++++++++++++++++++++++++++ - -Ansible is a powerful orchestration tool, and rax modules allow you the opportunity to orchestrate complex tasks, deployments, and configurations. The key here is to automate provisioning of infrastructure, like any other piece of software in an environment. Complex deployments might have previously required manual manipulation of load balancers, or manual provisioning of servers. Utilizing the rax modules included with Ansible, one can make the deployment of additional nodes contingent on the current number of running nodes, or the configuration of a clustered application dependent on the number of nodes with common metadata. One could automate the following scenarios, for example: - -* Servers that are removed from a Cloud Load Balancer one-by-one, updated, verified, and returned to the load balancer pool -* Expansion of an already-online environment, where nodes are provisioned, bootstrapped, configured, and software installed -* A procedure where app log files are uploaded to a central location, like Cloud Files, before a node is decommissioned -* Servers and load balancers that have DNS records created and destroyed on creation and decommissioning, respectively - - - - diff --git a/docs/docsite/rst/scenario_guides/guide_scaleway.rst b/docs/docsite/rst/scenario_guides/guide_scaleway.rst deleted file mode 100644 index 0baf58a5e26..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_scaleway.rst +++ /dev/null @@ -1,293 +0,0 @@ -.. _guide_scaleway: - -************** -Scaleway Guide -************** - -.. _scaleway_introduction: - -Introduction -============ - -`Scaleway `_ is a cloud provider supported by Ansible, version 2.6 or higher through a dynamic inventory plugin and modules. -Those modules are: - -- :ref:`scaleway_sshkey_module`: adds a public SSH key from a file or value to the Packet infrastructure. Every subsequently-created device will have this public key installed in .ssh/authorized_keys. -- :ref:`scaleway_compute_module`: manages servers on Scaleway. You can use this module to create, restart and delete servers. -- :ref:`scaleway_volume_module`: manages volumes on Scaleway. - -.. note:: - This guide assumes you are familiar with Ansible and how it works. - If you're not, have a look at :ref:`ansible_documentation` before getting started. - -.. _scaleway_requirements: - -Requirements -============ - -The Scaleway modules and inventory script connect to the Scaleway API using `Scaleway REST API `_. -To use the modules and inventory script you'll need a Scaleway API token. -You can generate an API token through the Scaleway console `here `__. -The simplest way to authenticate yourself is to set the Scaleway API token in an environment variable: - -.. code-block:: bash - - $ export SCW_TOKEN=00000000-1111-2222-3333-444444444444 - -If you're not comfortable exporting your API token, you can pass it as a parameter to the modules using the ``api_token`` argument. - -If you want to use a new SSH key pair in this tutorial, you can generate it to ``./id_rsa`` and ``./id_rsa.pub`` as: - -.. code-block:: bash - - $ ssh-keygen -t rsa -f ./id_rsa - -If you want to use an existing key pair, just copy the private and public key over to the playbook directory. - -.. _scaleway_add_sshkey: - -How to add an SSH key? -====================== - -Connection to Scaleway Compute nodes use Secure Shell. -SSH keys are stored at the account level, which means that you can re-use the same SSH key in multiple nodes. -The first step to configure Scaleway compute resources is to have at least one SSH key configured. - -:ref:`scaleway_sshkey_module` is a module that manages SSH keys on your Scaleway account. -You can add an SSH key to your account by including the following task in a playbook: - -.. code-block:: yaml - - - name: "Add SSH key" - scaleway_sshkey: - ssh_pub_key: "ssh-rsa AAAA..." - state: "present" - -The ``ssh_pub_key`` parameter contains your ssh public key as a string. Here is an example inside a playbook: - - -.. code-block:: yaml - - - name: Test SSH key lifecycle on a Scaleway account - hosts: localhost - gather_facts: false - environment: - SCW_API_KEY: "" - - tasks: - - - scaleway_sshkey: - ssh_pub_key: "ssh-rsa AAAAB...424242 developer@example.com" - state: present - register: result - - - assert: - that: - - result is success and result is changed - -.. _scaleway_create_instance: - -How to create a compute instance? -================================= - -Now that we have an SSH key configured, the next step is to spin up a server! -:ref:`scaleway_compute_module` is a module that can create, update and delete Scaleway compute instances: - -.. code-block:: yaml - - - name: Create a server - scaleway_compute: - name: foobar - state: present - image: 00000000-1111-2222-3333-444444444444 - organization: 00000000-1111-2222-3333-444444444444 - region: ams1 - commercial_type: START1-S - -Here are the parameter details for the example shown above: - -- ``name`` is the name of the instance (the one that will show up in your web console). -- ``image`` is the UUID of the system image you would like to use. - A list of all images is available for each availability zone. -- ``organization`` represents the organization that your account is attached to. -- ``region`` represents the Availability Zone which your instance is in (for this example, par1 and ams1). -- ``commercial_type`` represents the name of the commercial offers. - You can check out the Scaleway pricing page to find which instance is right for you. - -Take a look at this short playbook to see a working example using ``scaleway_compute``: - -.. code-block:: yaml - - - name: Test compute instance lifecycle on a Scaleway account - hosts: localhost - gather_facts: false - environment: - SCW_API_KEY: "" - - tasks: - - - name: Create a server - register: server_creation_task - scaleway_compute: - name: foobar - state: present - image: 00000000-1111-2222-3333-444444444444 - organization: 00000000-1111-2222-3333-444444444444 - region: ams1 - commercial_type: START1-S - wait: true - - - debug: var=server_creation_task - - - assert: - that: - - server_creation_task is success - - server_creation_task is changed - - - name: Run it - scaleway_compute: - name: foobar - state: running - image: 00000000-1111-2222-3333-444444444444 - organization: 00000000-1111-2222-3333-444444444444 - region: ams1 - commercial_type: START1-S - wait: true - tags: - - web_server - register: server_run_task - - - debug: var=server_run_task - - - assert: - that: - - server_run_task is success - - server_run_task is changed - -.. _scaleway_dynamic_inventory_tutorial: - -Dynamic Inventory Script -======================== - -Ansible ships with :ref:`scaleway_inventory`. -You can now get a complete inventory of your Scaleway resources through this plugin and filter it on -different parameters (``regions`` and ``tags`` are currently supported). - -Let's create an example! -Suppose that we want to get all hosts that got the tag web_server. -Create a file named ``scaleway_inventory.yml`` with the following content: - -.. code-block:: yaml - - plugin: scaleway - regions: - - ams1 - - par1 - tags: - - web_server - -This inventory means that we want all hosts that got the tag ``web_server`` on the zones ``ams1`` and ``par1``. -Once you have configured this file, you can get the information using the following command: - -.. code-block:: bash - - $ ansible-inventory --list -i scaleway_inventory.yml - -The output will be: - -.. code-block:: yaml - - { - "_meta": { - "hostvars": { - "dd8e3ae9-0c7c-459e-bc7b-aba8bfa1bb8d": { - "ansible_verbosity": 6, - "arch": "x86_64", - "commercial_type": "START1-S", - "hostname": "foobar", - "ipv4": "192.0.2.1", - "organization": "00000000-1111-2222-3333-444444444444", - "state": "running", - "tags": [ - "web_server" - ] - } - } - }, - "all": { - "children": [ - "ams1", - "par1", - "ungrouped", - "web_server" - ] - }, - "ams1": {}, - "par1": { - "hosts": [ - "dd8e3ae9-0c7c-459e-bc7b-aba8bfa1bb8d" - ] - }, - "ungrouped": {}, - "web_server": { - "hosts": [ - "dd8e3ae9-0c7c-459e-bc7b-aba8bfa1bb8d" - ] - } - } - -As you can see, we get different groups of hosts. -``par1`` and ``ams1`` are groups based on location. -``web_server`` is a group based on a tag. - -In case a filter parameter is not defined, the plugin supposes all values possible are wanted. -This means that for each tag that exists on your Scaleway compute nodes, a group based on each tag will be created. - -Scaleway S3 object storage -========================== - -`Object Storage `_ allows you to store any kind of objects (documents, images, videos, and so on). -As the Scaleway API is S3 compatible, Ansible supports it natively through the modules: :ref:`s3_bucket_module`, :ref:`aws_s3_module`. - -You can find many examples in the `scaleway_s3 integration tests `_. - -.. code-block:: yaml+jinja - - - hosts: myserver - vars: - scaleway_region: nl-ams - s3_url: https://s3.nl-ams.scw.cloud - environment: - # AWS_ACCESS_KEY matches your scaleway organization id available at https://cloud.scaleway.com/#/account - AWS_ACCESS_KEY: 00000000-1111-2222-3333-444444444444 - # AWS_SECRET_KEY matches a secret token that you can retrieve at https://cloud.scaleway.com/#/credentials - AWS_SECRET_KEY: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee - module_defaults: - group/aws: - s3_url: '{{ s3_url }}' - region: '{{ scaleway_region }}' - tasks: - # use a fact instead of a variable, otherwise template is evaluate each time variable is used - - set_fact: - bucket_name: "{{ 99999999 | random | to_uuid }}" - - # "requester_pays:" is mandatory because Scaleway doesn't implement related API - # another way is to use aws_s3 and "mode: create" ! - - s3_bucket: - name: '{{ bucket_name }}' - requester_pays: - - - name: Another way to create the bucket - aws_s3: - bucket: '{{ bucket_name }}' - mode: create - encrypt: false - register: bucket_creation_check - - - name: add something in the bucket - aws_s3: - mode: put - bucket: '{{ bucket_name }}' - src: /tmp/test.txt # needs to be created before - object: test.txt - encrypt: false # server side encryption must be disabled diff --git a/docs/docsite/rst/scenario_guides/guide_vagrant.rst b/docs/docsite/rst/scenario_guides/guide_vagrant.rst deleted file mode 100644 index f49477b0400..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_vagrant.rst +++ /dev/null @@ -1,136 +0,0 @@ -Vagrant Guide -============= - -.. _vagrant_intro: - -Introduction -```````````` - -`Vagrant `_ is a tool to manage virtual machine -environments, and allows you to configure and use reproducible work -environments on top of various virtualization and cloud platforms. -It also has integration with Ansible as a provisioner for these virtual -machines, and the two tools work together well. - -This guide will describe how to use Vagrant 1.7+ and Ansible together. - -If you're not familiar with Vagrant, you should visit `the documentation -`_. - -This guide assumes that you already have Ansible installed and working. -Running from a Git checkout is fine. Follow the :ref:`installation_guide` -guide for more information. - -.. _vagrant_setup: - -Vagrant Setup -````````````` - -The first step once you've installed Vagrant is to create a ``Vagrantfile`` -and customize it to suit your needs. This is covered in detail in the Vagrant -documentation, but here is a quick example that includes a section to use the -Ansible provisioner to manage a single machine: - -.. code-block:: ruby - - # This guide is optimized for Vagrant 1.8 and above. - # Older versions of Vagrant put less info in the inventory they generate. - Vagrant.require_version ">= 1.8.0" - - Vagrant.configure(2) do |config| - - config.vm.box = "ubuntu/bionic64" - - config.vm.provision "ansible" do |ansible| - ansible.verbose = "v" - ansible.playbook = "playbook.yml" - end - end - -Notice the ``config.vm.provision`` section that refers to an Ansible playbook -called ``playbook.yml`` in the same directory as the ``Vagrantfile``. Vagrant -runs the provisioner once the virtual machine has booted and is ready for SSH -access. - -There are a lot of Ansible options you can configure in your ``Vagrantfile``. -Visit the `Ansible Provisioner documentation -`_ for more -information. - -.. code-block:: bash - - $ vagrant up - -This will start the VM, and run the provisioning playbook (on the first VM -startup). - - -To re-run a playbook on an existing VM, just run: - -.. code-block:: bash - - $ vagrant provision - -This will re-run the playbook against the existing VM. - -Note that having the ``ansible.verbose`` option enabled will instruct Vagrant -to show the full ``ansible-playbook`` command used behind the scene, as -illustrated by this example: - -.. code-block:: bash - - $ PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true ANSIBLE_HOST_KEY_CHECKING=false ANSIBLE_SSH_ARGS='-o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s' ansible-playbook --connection=ssh --timeout=30 --limit="default" --inventory-file=/home/someone/coding-in-a-project/.vagrant/provisioners/ansible/inventory -v playbook.yml - -This information can be quite useful to debug integration issues and can also -be used to manually execute Ansible from a shell, as explained in the next -section. - -.. _running_ansible: - -Running Ansible Manually -```````````````````````` - -Sometimes you may want to run Ansible manually against the machines. This is -faster than kicking ``vagrant provision`` and pretty easy to do. - -With our ``Vagrantfile`` example, Vagrant automatically creates an Ansible -inventory file in ``.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory``. -This inventory is configured according to the SSH tunnel that Vagrant -automatically creates. A typical automatically-created inventory file for a -single machine environment may look something like this: - -.. code-block:: none - - # Generated by Vagrant - - default ansible_host=127.0.0.1 ansible_port=2222 ansible_user='vagrant' ansible_ssh_private_key_file='/home/someone/coding-in-a-project/.vagrant/machines/default/virtualbox/private_key' - -If you want to run Ansible manually, you will want to make sure to pass -``ansible`` or ``ansible-playbook`` commands the correct arguments, at least -for the *inventory*. - -.. code-block:: bash - - $ ansible-playbook -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory playbook.yml - -Advanced Usages -``````````````` - -The "Tips and Tricks" chapter of the `Ansible Provisioner documentation -`_ provides detailed information about more advanced Ansible features like: - - - how to execute a playbook in parallel within a multi-machine environment - - how to integrate a local ``ansible.cfg`` configuration file - -.. seealso:: - - `Vagrant Home `_ - The Vagrant homepage with downloads - `Vagrant Documentation `_ - Vagrant Documentation - `Ansible Provisioner `_ - The Vagrant documentation for the Ansible provisioner - `Vagrant Issue Tracker `_ - The open issues for the Ansible provisioner in the Vagrant project - :ref:`working_with_playbooks` - An introduction to playbooks diff --git a/docs/docsite/rst/scenario_guides/guide_vmware_rest.rst b/docs/docsite/rst/scenario_guides/guide_vmware_rest.rst deleted file mode 100644 index bf6838baa4e..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_vmware_rest.rst +++ /dev/null @@ -1,7 +0,0 @@ -.. _vmware_rest_scenarios: - -**************************** -VMware REST Scenarios -**************************** - -The content on this page has moved to :ref:`ansible_collections.vmware.vmware_rest.docsite.guide_vmware_rest`. diff --git a/docs/docsite/rst/scenario_guides/guide_vultr.rst b/docs/docsite/rst/scenario_guides/guide_vultr.rst deleted file mode 100644 index a946c91dc2e..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_vultr.rst +++ /dev/null @@ -1,171 +0,0 @@ -Vultr Guide -=========== - -Ansible offers a set of modules to interact with `Vultr `_ cloud platform. - -This set of module forms a framework that allows one to easily manage and orchestrate one's infrastructure on Vultr cloud platform. - - -Requirements ------------- - -There is actually no technical requirement; simply an already created Vultr account. - - -Configuration -------------- - -Vultr modules offer a rather flexible way with regard to configuration. - -Configuration is read in that order: - -- Environment Variables (eg. ``VULTR_API_KEY``, ``VULTR_API_TIMEOUT``) -- File specified by environment variable ``VULTR_API_CONFIG`` -- ``vultr.ini`` file located in current working directory -- ``$HOME/.vultr.ini`` - - -Ini file are structured this way: - -.. code-block:: ini - - [default] - key = MY_API_KEY - timeout = 60 - - [personal_account] - key = MY_PERSONAL_ACCOUNT_API_KEY - timeout = 30 - - -If ``VULTR_API_ACCOUNT`` environment variable or ``api_account`` module parameter is not specified, modules will look for the section named "default". - - -Authentication --------------- - -Before using the Ansible modules to interact with Vultr, you need an API key. -If you don't yet own one, log in to `Vultr `_ go to Account, then API, enable API then the API key should show up. - -Ensure you allow the usage of the API key from the proper IP addresses. - -Refer to the Configuration section to find out where to put this information. - -To check that everything is working properly run the following command: - -.. code-block:: console - - #> VULTR_API_KEY=XXX ansible -m vultr_account_info localhost - localhost | SUCCESS => { - "changed": false, - "vultr_account_info": { - "balance": -8.9, - "last_payment_amount": -10.0, - "last_payment_date": "2018-07-21 11:34:46", - "pending_charges": 6.0 - }, - "vultr_api": { - "api_account": "default", - "api_endpoint": "https://api.vultr.com", - "api_retries": 5, - "api_timeout": 60 - } - } - - -If a similar output displays then everything is setup properly, else please ensure the proper ``VULTR_API_KEY`` has been specified and that Access Controls on Vultr > Account > API page are accurate. - - -Usage ------ - -Since `Vultr `_ offers a public API, the execution of the module to manage the infrastructure on their platform will happen on localhost. This translates to: - -.. code-block:: yaml - - --- - - hosts: localhost - tasks: - - name: Create a 10G volume - vultr_block_storage: - name: my_disk - size: 10 - region: New Jersey - - -From that point on, only your creativity is the limit. Make sure to read the documentation of the `available modules `_. - - -Dynamic Inventory ------------------ - -Ansible provides a dynamic inventory plugin for `Vultr `_. -The configuration process is exactly the same as for the modules. - -To be able to use it you need to enable it first by specifying the following in the ``ansible.cfg`` file: - -.. code-block:: ini - - [inventory] - enable_plugins=vultr - -And provide a configuration file to be used with the plugin, the minimal configuration file looks like this: - -.. code-block:: yaml - - --- - plugin: vultr - -To list the available hosts one can simply run: - -.. code-block:: console - - #> ansible-inventory -i vultr.yml --list - - -For example, this allows you to take action on nodes grouped by location or OS name: - -.. code-block:: yaml - - --- - - hosts: Amsterdam - tasks: - - name: Rebooting the machine - shell: reboot - become: True - - -Integration tests ------------------ - -Ansible includes integration tests for all Vultr modules. - -These tests are meant to run against the public Vultr API and that is why they require a valid key to access the API. - -Prepare the test setup: - -.. code-block:: shell - - $ cd ansible # location the ansible source is - $ source ./hacking/env-setup - -Set the Vultr API key: - -.. code-block:: shell - - $ cd test/integration - $ cp cloud-config-vultr.ini.template cloud-config-vultr.ini - $ vi cloud-config-vultr.ini - -Run all Vultr tests: - -.. code-block:: shell - - $ ansible-test integration cloud/vultr/ -v --diff --allow-unsupported - - -To run a specific test, for example vultr_account_info: - -.. code-block:: shell - - $ ansible-test integration cloud/vultr/vultr_account_info -v --diff --allow-unsupported diff --git a/docs/docsite/rst/scenario_guides/guides.rst b/docs/docsite/rst/scenario_guides/guides.rst deleted file mode 100644 index 8b6c54fbcae..00000000000 --- a/docs/docsite/rst/scenario_guides/guides.rst +++ /dev/null @@ -1,44 +0,0 @@ -:orphan: - -.. unified index page included for backwards compatibility - -****************** -Scenario Guides -****************** - -The guides in this section are migrating into collections. Remaining guides may be out of date. - -These guides cover integrating Ansible with a variety of platforms, products, and technologies. They explore particular use cases in greater depth and provide a more "top-down" explanation of some basic features. - -We are migrating these guides into collections. Please update your links for the following guides: - -:ref:`ansible_collections.amazon.aws.docsite.aws_intro` - -.. toctree:: - :maxdepth: 1 - :caption: Legacy Public Cloud Guides - - guide_alicloud - guide_cloudstack - guide_gce - guide_azure - guide_online - guide_oracle - guide_packet - guide_rax - guide_scaleway - guide_vultr - -.. toctree:: - :maxdepth: 1 - :caption: Network Technology Guides - - guide_aci - guide_meraki - guide_infoblox - -.. toctree:: - :maxdepth: 1 - :caption: Virtualization & Containerization Guides - - guide_vagrant diff --git a/docs/docsite/rst/scenario_guides/network_guides.rst b/docs/docsite/rst/scenario_guides/network_guides.rst deleted file mode 100644 index 2b538ff05ed..00000000000 --- a/docs/docsite/rst/scenario_guides/network_guides.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. _network_guides: - -************************* -Network Technology Guides -************************* - -The guides in this section cover using Ansible with specific network technologies. They explore particular use cases in greater depth and provide a more "top-down" explanation of some basic features. - -.. toctree:: - :maxdepth: 1 - - guide_aci - guide_meraki - guide_infoblox - -To learn more about Network Automation with Ansible, see :ref:`network_getting_started` and :ref:`network_advanced`. diff --git a/docs/docsite/rst/scenario_guides/scenario_template.rst b/docs/docsite/rst/scenario_guides/scenario_template.rst deleted file mode 100644 index 14695bed648..00000000000 --- a/docs/docsite/rst/scenario_guides/scenario_template.rst +++ /dev/null @@ -1,53 +0,0 @@ -:orphan: - -.. _scenario_template: - -************************************* -Sample scenario for Ansible platforms -************************************* - -*Use this ``rst`` file as a starting point to create a scenario guide for your platform. The sections below are suggestions on what should be in a scenario guide.* - -Introductory paragraph. - -.. contents:: - :local: - -Prerequisites -============= - -Describe the requirements and assumptions for this scenario. This should include applicable subsections for hardware, software, and any other caveats to using the scenarios in this guide. - -Credentials and authenticating -============================== - -Describe credential requirements and how to authenticate to this platform. - -Using dynamic inventory -========================= - -If applicable, describe how to use a dynamic inventory plugin for this platform. - - -Example description -=================== - -Description and code here. Change the section header to something descriptive about this example, such as "Renaming a virtual machine". The goal is that this is the text someone would search for to find your example. - - -Example output --------------- - -What the user should expect to see. - - -Troubleshooting ---------------- - -What to look for if it breaks. - - -Conclusion and where to go next -=============================== - -Recap of important points. For more information please see: links. diff --git a/docs/docsite/rst/scenario_guides/virt_guides.rst b/docs/docsite/rst/scenario_guides/virt_guides.rst deleted file mode 100644 index bc9007861c7..00000000000 --- a/docs/docsite/rst/scenario_guides/virt_guides.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. _virtualization_guides: - -****************************************** -Virtualization and Containerization Guides -****************************************** - -The guides in this section cover integrating Ansible with popular tools for creating virtual machines and containers. They explore particular use cases in greater depth and provide a more "top-down" explanation of some basic features. - -.. toctree:: - :maxdepth: 1 - - guide_docker - guide_vagrant - guide_vmware_rest diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/authentication.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/authentication.rst deleted file mode 100644 index 4f09cbe1012..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/authentication.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _vmware_rest_authentication: - -******************************************* -How to configure the vmware_rest collection -******************************************* - -.. contents:: - :local: - - -Introduction -============ - -The vcenter_rest modules need to be authenticated. There are two different - -Environment variables -===================== - -.. note:: - This solution requires that you call the modules from the local machine. - -You need to export some environment variables in your shell before you call the modules. - -.. code-block:: shell - - $ export VMWARE_HOST=vcenter.test - $ export VMWARE_USER=myvcenter-user - $ export VMWARE_password=mypassword - $ ansible-playbook my-playbook.yaml - -Module parameters -================= - -All the vcenter_rest modules accept the following arguments: - -- ``vcenter_hostname`` -- ``vcenter_username`` -- ``vcenter_password`` - - -Ignore SSL certificate error -============================ - -It's common to run a test environment without a proper SSL certificate configuration. - -To ignore the SSL error, you can use the ``vcenter_validate_certs: no`` argument or -``export VMWARE_VALIDATE_CERTS=no`` to set the environment variable. diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/collect_information.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/collect_information.rst deleted file mode 100644 index d6c2b86afd1..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/collect_information.rst +++ /dev/null @@ -1,108 +0,0 @@ -.. _vmware_rest_collect_info: - -************************************************* -How to collect information about your environment -************************************************* - -.. contents:: - :local: - - -Introduction -============ - -This section shows you how to utilize Ansible to collect information about your environment. -This information is useful for the other tutorials. - -Scenario requirements -===================== - -In this scenario we've got a vCenter with an ESXi host. - -Our environment is pre-initialized with the following elements: - -- A datacenter called ``my_dc`` -- A cluster called ``my_cluster`` -- An ESXi host called ``esxi1`` is in the cluster -- Two datastores on the ESXi: ``rw_datastore`` and ``ro_datastore`` -- A dvswitch based guest network - -Finally, we use the environment variables to authenticate ourselves as explained in :ref:`vmware_rest_authentication`. - -How to collect information -========================== - -In these examples, we use the ``vcenter_*_info`` module to collect information about the associated resources. - -All these modules return a ``value`` key. Depending on the context, this ``value`` key will be either a list or a dictionary. - -Datacenter ----------- - -Here we use the ``vcenter_datacenter_info`` module to list all the datacenters: - -.. literalinclude:: task_outputs/collect_a_list_of_the_datacenters.task.yaml - -Result -______ - -As expected, the ``value`` key of the output is a list. - -.. literalinclude:: task_outputs/collect_a_list_of_the_datacenters.result.json - -Cluster -------- - -Here we do the same with ``vcenter_cluster_info``: - -.. literalinclude:: task_outputs/Build_a_list_of_all_the_clusters.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Build_a_list_of_all_the_clusters.result.json - -And we can also fetch the details about a specific cluster, with the ``cluster`` parameter: - -.. literalinclude:: task_outputs/Retrieve_details_about_the_first_cluster.task.yaml - -Result -______ - -And the ``value`` key of the output is this time a dictionary. - - -.. literalinclude:: task_outputs/Retrieve_details_about_the_first_cluster.result.json - -Datastore ---------- - -Here we use ``vcenter_datastore_info`` to get a list of all the datastores: - -.. literalinclude:: task_outputs/Retrieve_a_list_of_all_the_datastores.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Retrieve_a_list_of_all_the_datastores.result.json - -Folder ------- - -And here again, you use the ``vcenter_folder_info`` module to retrieve a list of all the folders. - -.. literalinclude:: task_outputs/Build_a_list_of_all_the_folders.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Build_a_list_of_all_the_folders.result.json - -Most of the time, you will just want one type of folder. In this case we can use filters to reduce the amount to collect. Most of the ``_info`` modules come with similar filters. - -.. literalinclude:: task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.result.json diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/create_vm.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/create_vm.rst deleted file mode 100644 index 0e64bd0310e..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/create_vm.rst +++ /dev/null @@ -1,39 +0,0 @@ -.. _vmware_rest_create_vm: - -******************************* -How to create a Virtual Machine -******************************* - -.. contents:: - :local: - - -Introduction -============ - -This section shows you how to use Ansible to create a virtual machine. - -Scenario requirements -===================== - -You've already followed :ref:`vmware_rest_collect_info` and you've got the following variables defined: - -- ``my_cluster_info`` -- ``my_datastore`` -- ``my_virtual_machine_folder`` -- ``my_cluster_info`` - -How to create a virtual machine -=============================== - -In this example, we will use the ``vcenter_vm`` module to create a new guest. - -.. literalinclude:: task_outputs/Create_a_VM.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Create_a_VM.result.json - -.. note:: - ``vcenter_vm`` accepts more parameters, however you may prefer to start with a simple VM and use the ``vcenter_vm_hardware`` modules to tune it up afterwards. It's easier this way to identify a potential problematical step. diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/installation.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/installation.rst deleted file mode 100644 index 7516d0fd455..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/installation.rst +++ /dev/null @@ -1,44 +0,0 @@ -.. _vmware_rest_installation: - -***************************************** -How to install the vmware_rest collection -***************************************** - -.. contents:: - :local: - - -Requirements -============ - -The collection depends on: - -- Ansible >=2.9.10 or greater -- Python 3.6 or greater - -aiohttp -======= - -aiohttp_ is the only dependency of the collection. You can install it with ``pip`` if you use a virtualenv to run Ansible. - -.. code-block:: shell - - $ pip install aiohttp - -Or using an RPM. - -.. code-block:: shell - - $ sudo dnf install python3-aiohttp - -.. _aiohttp: https://docs.aiohttp.org/en/stable/ - -Installation -============ - -The best option to install the collection is to use the ``ansible-galaxy`` command: - -.. code-block:: shell - - - $ ansible-galaxy collection install vmware.vmware_rest diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst deleted file mode 100644 index be723866e78..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst +++ /dev/null @@ -1,52 +0,0 @@ -.. _vmware_rest_run_a_vm: - -**************************** -How to run a virtual machine -**************************** - -.. contents:: - :local: - - -Introduction -============ - -This section covers the power management of your virtual machine. - -Power information -================= - -Use ``vcenter_vm_power_info`` to know the power state of the VM. - -.. literalinclude:: task_outputs/Get_guest_power_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_guest_power_information.result.json - - -How to start a virtual machine -============================== - -Use the ``vcenter_vm_power`` module to start your VM: - -.. literalinclude:: task_outputs/Turn_the_power_of_the_VM_on.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Turn_the_power_of_the_VM_on.result.json - -How to wait until my virtual machine is ready -============================================= - -If your virtual machine runs VMware Tools, you can build a loop -around the ``center_vm_tools_info`` module: - -.. literalinclude:: task_outputs/Wait_until_my_VM_is_ready.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Wait_until_my_VM_is_ready.result.json diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Add_a_floppy_disk_drive.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Add_a_floppy_disk_drive.result.json deleted file mode 100644 index c4bf5cd0e22..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Add_a_floppy_disk_drive.result.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "value": { - "start_connected": false, - "backing": { - "auto_detect": true, - "type": "HOST_DEVICE", - "host_device": "" - }, - "allow_guest_control": true, - "label": "Floppy drive 1", - "state": "NOT_CONNECTED" - }, - "id": "8000", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Add_a_floppy_disk_drive.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Add_a_floppy_disk_drive.task.yaml deleted file mode 100644 index 807b61692b1..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Add_a_floppy_disk_drive.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Add a floppy disk drive - vmware.vmware_rest.vcenter_vm_hardware_floppy: - vm: '{{ test_vm1_info.id }}' - allow_guest_control: true - register: my_floppy_drive diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_a_VM_to_a_dvswitch.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_a_VM_to_a_dvswitch.result.json deleted file mode 100644 index fbb5a6f15d9..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_a_VM_to_a_dvswitch.result.json +++ /dev/null @@ -1,23 +0,0 @@ -{ - "value": { - "start_connected": false, - "pci_slot_number": 4, - "backing": { - "connection_cookie": 2145337177, - "distributed_switch_uuid": "50 33 88 3a 8c 6e f9 02-7a fd c2 c0 2c cf f2 ac", - "distributed_port": "2", - "type": "DISTRIBUTED_PORTGROUP", - "network": "dvportgroup-1649" - }, - "mac_address": "00:50:56:b3:49:5c", - "mac_type": "ASSIGNED", - "allow_guest_control": false, - "wake_on_lan_enabled": false, - "label": "Network adapter 1", - "state": "NOT_CONNECTED", - "type": "VMXNET3", - "upt_compatibility_enabled": false - }, - "id": "4000", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_a_VM_to_a_dvswitch.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_a_VM_to_a_dvswitch.task.yaml deleted file mode 100644 index d35cd83cb47..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_a_VM_to_a_dvswitch.task.yaml +++ /dev/null @@ -1,9 +0,0 @@ -- name: Attach a VM to a dvswitch - vmware.vmware_rest.vcenter_vm_hardware_ethernet: - vm: '{{ test_vm1_info.id }}' - pci_slot_number: 4 - backing: - type: DISTRIBUTED_PORTGROUP - network: "{{ my_portgroup_info.dvs_portgroup_info.dvswitch1[0].key }}" - start_connected: false - register: vm_hardware_ethernet_1 diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_an_ISO_image_to_a_guest_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_an_ISO_image_to_a_guest_VM.result.json deleted file mode 100644 index ee456cb1fe6..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_an_ISO_image_to_a_guest_VM.result.json +++ /dev/null @@ -1,19 +0,0 @@ -{ - "value": { - "start_connected": true, - "backing": { - "iso_file": "[ro_datastore] fedora.iso", - "type": "ISO_FILE" - }, - "allow_guest_control": false, - "label": "CD/DVD drive 1", - "state": "NOT_CONNECTED", - "type": "SATA", - "sata": { - "bus": 0, - "unit": 2 - } - }, - "id": "16002", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_an_ISO_image_to_a_guest_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_an_ISO_image_to_a_guest_VM.task.yaml deleted file mode 100644 index b328788fa5b..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_an_ISO_image_to_a_guest_VM.task.yaml +++ /dev/null @@ -1,12 +0,0 @@ -- name: Attach an ISO image to a guest VM - vmware.vmware_rest.vcenter_vm_hardware_cdrom: - vm: '{{ test_vm1_info.id }}' - type: SATA - sata: - bus: 0 - unit: 2 - start_connected: true - backing: - iso_file: '[ro_datastore] fedora.iso' - type: ISO_FILE - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_clusters.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_clusters.result.json deleted file mode 100644 index 3415fae6f6e..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_clusters.result.json +++ /dev/null @@ -1,11 +0,0 @@ -{ - "value": [ - { - "drs_enabled": false, - "cluster": "domain-c1636", - "name": "my_cluster", - "ha_enabled": false - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_clusters.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_clusters.task.yaml deleted file mode 100644 index cd12250cf91..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_clusters.task.yaml +++ /dev/null @@ -1,3 +0,0 @@ -- name: Build a list of all the clusters - vmware.vmware_rest.vcenter_cluster_info: - register: all_the_clusters diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders.result.json deleted file mode 100644 index 516234d4c69..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders.result.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "value": [ - { - "folder": "group-d1", - "name": "Datacenters", - "type": "DATACENTER" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders.task.yaml deleted file mode 100644 index 12646e73b45..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders.task.yaml +++ /dev/null @@ -1,3 +0,0 @@ -- name: Build a list of all the folders - vmware.vmware_rest.vcenter_folder_info: - register: my_folders diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.result.json deleted file mode 100644 index ecf53f73ebb..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.result.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "value": [ - { - "folder": "group-v1631", - "name": "vm", - "type": "VIRTUAL_MACHINE" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.task.yaml deleted file mode 100644 index 0ab8854d611..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.task.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- name: Build a list of all the folders with the type VIRTUAL_MACHINE and called vm - vmware.vmware_rest.vcenter_folder_info: - filter_type: VIRTUAL_MACHINE - filter_names: - - vm - register: my_folders diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.result.json deleted file mode 100644 index e15f41c5fae..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.result.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "id": null, - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.task.yaml deleted file mode 100644 index a8f411e8790..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Change vm-tools upgrade policy to MANUAL - vmware.vmware_rest.vcenter_vm_tools: - vm: '{{ test_vm1_info.id }}' - upgrade_policy: MANUAL - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.result.json deleted file mode 100644 index e15f41c5fae..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.result.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "id": null, - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.task.yaml deleted file mode 100644 index e7396035288..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Change vm-tools upgrade policy to UPGRADE_AT_POWER_CYCLE - vmware.vmware_rest.vcenter_vm_tools: - vm: '{{ test_vm1_info.id }}' - upgrade_policy: UPGRADE_AT_POWER_CYCLE - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_information_about_a_specific_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_information_about_a_specific_VM.result.json deleted file mode 100644 index d0f17cbb719..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_information_about_a_specific_VM.result.json +++ /dev/null @@ -1,77 +0,0 @@ -{ - "value": { - "instant_clone_frozen": false, - "cdroms": [], - "memory": { - "size_MiB": 1024, - "hot_add_enabled": true - }, - "disks": [ - { - "value": { - "scsi": { - "bus": 0, - "unit": 0 - }, - "backing": { - "vmdk_file": "[local] test_vm1_8/test_vm1.vmdk", - "type": "VMDK_FILE" - }, - "label": "Hard disk 1", - "type": "SCSI", - "capacity": 17179869184 - }, - "key": "2000" - } - ], - "parallel_ports": [], - "sata_adapters": [], - "cpu": { - "hot_remove_enabled": false, - "count": 1, - "hot_add_enabled": false, - "cores_per_socket": 1 - }, - "scsi_adapters": [ - { - "value": { - "scsi": { - "bus": 0, - "unit": 7 - }, - "label": "SCSI controller 0", - "sharing": "NONE", - "type": "PVSCSI" - }, - "key": "1000" - } - ], - "power_state": "POWERED_OFF", - "floppies": [], - "identity": { - "name": "test_vm1", - "instance_uuid": "5033c296-6954-64df-faca-d001de53763d", - "bios_uuid": "42330d17-e603-d925-fa4b-18827dbc1409" - }, - "nvme_adapters": [], - "name": "test_vm1", - "nics": [], - "boot": { - "delay": 0, - "retry_delay": 10000, - "enter_setup_mode": false, - "type": "BIOS", - "retry": false - }, - "serial_ports": [], - "boot_devices": [], - "guest_OS": "DEBIAN_8_64", - "hardware": { - "upgrade_policy": "NEVER", - "upgrade_status": "NONE", - "version": "VMX_11" - } - }, - "id": "vm-1650", - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_information_about_a_specific_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_information_about_a_specific_VM.task.yaml deleted file mode 100644 index a113ecc5fe5..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_information_about_a_specific_VM.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Collect information about a specific VM - vmware.vmware_rest.vcenter_vm_info: - vm: '{{ search_result.value[0].vm }}' - register: test_vm1_info diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_the_hardware_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_the_hardware_information.result.json deleted file mode 100644 index c2e162c5db2..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_the_hardware_information.result.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "value": { - "upgrade_policy": "NEVER", - "upgrade_status": "NONE", - "version": "VMX_11" - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_the_hardware_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_the_hardware_information.task.yaml deleted file mode 100644 index c6401eced1a..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_the_hardware_information.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Collect the hardware information - vmware.vmware_rest.vcenter_vm_hardware_info: - vm: '{{ search_result.value[0].vm }}' - register: my_vm1_hardware_info diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.result.json deleted file mode 100644 index 62ae281ec05..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.result.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "value": { - "bus": 0, - "pci_slot_number": 34, - "label": "SATA controller 0", - "type": "AHCI" - }, - "id": "15000", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.task.yaml deleted file mode 100644 index 37d3f355ed7..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Create a SATA adapter at PCI slot 34 - vmware.vmware_rest.vcenter_vm_hardware_adapter_sata: - vm: '{{ test_vm1_info.id }}' - pci_slot_number: 34 - register: _sata_adapter_result_1 diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_VM.result.json deleted file mode 100644 index d309d076a04..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_VM.result.json +++ /dev/null @@ -1,77 +0,0 @@ -{ - "value": { - "instant_clone_frozen": false, - "cdroms": [], - "memory": { - "size_MiB": 1024, - "hot_add_enabled": true - }, - "disks": [ - { - "value": { - "scsi": { - "bus": 0, - "unit": 0 - }, - "backing": { - "vmdk_file": "[local] test_vm1_8/test_vm1.vmdk", - "type": "VMDK_FILE" - }, - "label": "Hard disk 1", - "type": "SCSI", - "capacity": 17179869184 - }, - "key": "2000" - } - ], - "parallel_ports": [], - "sata_adapters": [], - "cpu": { - "hot_remove_enabled": false, - "count": 1, - "hot_add_enabled": false, - "cores_per_socket": 1 - }, - "scsi_adapters": [ - { - "value": { - "scsi": { - "bus": 0, - "unit": 7 - }, - "label": "SCSI controller 0", - "sharing": "NONE", - "type": "PVSCSI" - }, - "key": "1000" - } - ], - "power_state": "POWERED_OFF", - "floppies": [], - "identity": { - "name": "test_vm1", - "instance_uuid": "5033c296-6954-64df-faca-d001de53763d", - "bios_uuid": "42330d17-e603-d925-fa4b-18827dbc1409" - }, - "nvme_adapters": [], - "name": "test_vm1", - "nics": [], - "boot": { - "delay": 0, - "retry_delay": 10000, - "enter_setup_mode": false, - "type": "BIOS", - "retry": false - }, - "serial_ports": [], - "boot_devices": [], - "guest_OS": "DEBIAN_8_64", - "hardware": { - "upgrade_policy": "NEVER", - "upgrade_status": "NONE", - "version": "VMX_11" - } - }, - "id": "vm-1650", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_VM.task.yaml deleted file mode 100644 index 02a6128d1fe..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_VM.task.yaml +++ /dev/null @@ -1,14 +0,0 @@ -- name: Create a VM - vmware.vmware_rest.vcenter_vm: - placement: - cluster: "{{ my_cluster_info.id }}" - datastore: "{{ my_datastore.datastore }}" - folder: "{{ my_virtual_machine_folder.folder }}" - resource_pool: "{{ my_cluster_info.value.resource_pool }}" - name: test_vm1 - guest_OS: DEBIAN_8_64 - hardware_version: VMX_11 - memory: - hot_add_enabled: true - size_MiB: 1024 - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_new_disk.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_new_disk.result.json deleted file mode 100644 index 7b4275ca7a1..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_new_disk.result.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "value": { - "backing": { - "vmdk_file": "[local] test_vm1_8/test_vm1_1.vmdk", - "type": "VMDK_FILE" - }, - "label": "Hard disk 2", - "type": "SATA", - "sata": { - "bus": 0, - "unit": 0 - }, - "capacity": 320000 - }, - "id": "16000", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_new_disk.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_new_disk.task.yaml deleted file mode 100644 index 06f34b6f9a6..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_new_disk.task.yaml +++ /dev/null @@ -1,7 +0,0 @@ -- name: Create a new disk - vmware.vmware_rest.vcenter_vm_hardware_disk: - vm: '{{ test_vm1_info.id }}' - type: SATA - new_vmdk: - capacity: 320000 - register: my_new_disk diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Dedicate_one_core_to_the_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Dedicate_one_core_to_the_VM.result.json deleted file mode 100644 index 8d2169bbb26..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Dedicate_one_core_to_the_VM.result.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "value": { - "hot_remove_enabled": false, - "count": 1, - "hot_add_enabled": false, - "cores_per_socket": 1 - }, - "id": null, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Dedicate_one_core_to_the_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Dedicate_one_core_to_the_VM.task.yaml deleted file mode 100644 index 9eb9ff947cc..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Dedicate_one_core_to_the_VM.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Dedicate one core to the VM - vmware.vmware_rest.vcenter_vm_hardware_cpu: - vm: '{{ test_vm1_info.id }}' - count: 1 - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_VM_storage_policy.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_VM_storage_policy.result.json deleted file mode 100644 index 204ad5f9afb..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_VM_storage_policy.result.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "value": { - "disks": [] - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_VM_storage_policy.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_VM_storage_policy.task.yaml deleted file mode 100644 index c54620cb820..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_VM_storage_policy.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Get VM storage policy - vmware.vmware_rest.vcenter_vm_storage_policy_info: - vm: '{{ test_vm1_info.id }}' - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_filesystem_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_filesystem_information.result.json deleted file mode 100644 index ad87f76d203..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_filesystem_information.result.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "value": [ - { - "value": { - "mappings": [], - "free_space": 774766592, - "capacity": 2515173376 - }, - "key": "/" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_filesystem_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_filesystem_information.task.yaml deleted file mode 100644 index e14685998f9..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_filesystem_information.task.yaml +++ /dev/null @@ -1,8 +0,0 @@ -- name: Get guest filesystem information - vmware.vmware_rest.vcenter_vm_guest_localfilesystem_info: - vm: '{{ test_vm1_info.id }}' - register: _result - until: - - _result is not failed - retries: 60 - delay: 5 diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_identity_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_identity_information.result.json deleted file mode 100644 index 01e8a8fd1c9..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_identity_information.result.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "value": { - "full_name": { - "args": [], - "default_message": "Red Hat Fedora (64-bit)", - "id": "vmsg.guestos.fedora64Guest.label" - }, - "name": "FEDORA_64", - "ip_address": "192.168.122.242", - "family": "LINUX", - "host_name": "localhost.localdomain" - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_identity_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_identity_information.task.yaml deleted file mode 100644 index cb0f69f9520..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_identity_information.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Get guest identity information - vmware.vmware_rest.vcenter_vm_guest_identity_info: - vm: '{{ test_vm1_info.id }}' - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_interfaces_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_interfaces_information.result.json deleted file mode 100644 index 2c973374afc..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_interfaces_information.result.json +++ /dev/null @@ -1,23 +0,0 @@ -{ - "value": [ - { - "mac_address": "00:50:56:b3:49:5c", - "ip": { - "ip_addresses": [ - { - "ip_address": "192.168.122.242", - "prefix_length": 24, - "state": "PREFERRED" - }, - { - "ip_address": "fe80::b8d0:511b:897f:65a2", - "prefix_length": 64, - "state": "UNKNOWN" - } - ] - }, - "nic": "4000" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_interfaces_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_interfaces_information.task.yaml deleted file mode 100644 index ec7e49861eb..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_interfaces_information.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Get guest network interfaces information - vmware.vmware_rest.vcenter_vm_guest_networking_interfaces_info: - vm: '{{ test_vm1_info.id }}' - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_routes_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_routes_information.result.json deleted file mode 100644 index 68e2033dd73..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_routes_information.result.json +++ /dev/null @@ -1,31 +0,0 @@ -{ - "value": [ - { - "gateway_address": "192.168.122.1", - "interface_index": 0, - "prefix_length": 0, - "network": "0.0.0.0" - }, - { - "interface_index": 0, - "prefix_length": 24, - "network": "192.168.122.0" - }, - { - "interface_index": 0, - "prefix_length": 64, - "network": "fe80::" - }, - { - "interface_index": 0, - "prefix_length": 128, - "network": "fe80::b8d0:511b:897f:65a2" - }, - { - "interface_index": 0, - "prefix_length": 8, - "network": "ff00::" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_routes_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_routes_information.task.yaml deleted file mode 100644 index 5f0148fa4e6..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_routes_information.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Get guest network routes information - vmware.vmware_rest.vcenter_vm_guest_networking_routes_info: - vm: '{{ test_vm1_info.id }}' - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_networking_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_networking_information.result.json deleted file mode 100644 index fe757b647cc..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_networking_information.result.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "value": { - "dns": { - "ip_addresses": [ - "10.0.2.3" - ], - "search_domains": [ - "localdomain" - ] - }, - "dns_values": { - "domain_name": "localdomain", - "host_name": "localhost.localdomain" - } - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_networking_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_networking_information.task.yaml deleted file mode 100644 index 7184971cb72..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_networking_information.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Get guest networking information - vmware.vmware_rest.vcenter_vm_guest_networking_info: - vm: '{{ test_vm1_info.id }}' - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_power_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_power_information.result.json deleted file mode 100644 index da317782489..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_power_information.result.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "value": { - "state": "POWERED_ON" - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_power_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_power_information.task.yaml deleted file mode 100644 index a4ceffd956b..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_power_information.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Get guest power information - vmware.vmware_rest.vcenter_vm_power_info: - vm: '{{ test_vm1_info.id }}' - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Increase_the_memory_of_a_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Increase_the_memory_of_a_VM.result.json deleted file mode 100644 index e15f41c5fae..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Increase_the_memory_of_a_VM.result.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "id": null, - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Increase_the_memory_of_a_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Increase_the_memory_of_a_VM.task.yaml deleted file mode 100644 index bd53b184969..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Increase_the_memory_of_a_VM.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Increase the memory of a VM - vmware.vmware_rest.vcenter_vm_hardware_memory: - vm: '{{ test_vm1_info.id }}' - size_MiB: 1080 - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_SCSI_adapter_of_a_given_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_SCSI_adapter_of_a_given_VM.result.json deleted file mode 100644 index 3ecaa4bdbcf..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_SCSI_adapter_of_a_given_VM.result.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "value": [ - { - "scsi": { - "bus": 0, - "unit": 7 - }, - "label": "SCSI controller 0", - "type": "PVSCSI", - "sharing": "NONE" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_SCSI_adapter_of_a_given_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_SCSI_adapter_of_a_given_VM.task.yaml deleted file mode 100644 index 8b7d0eeae2e..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_SCSI_adapter_of_a_given_VM.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: List the SCSI adapter of a given VM - vmware.vmware_rest.vcenter_vm_hardware_adapter_scsi_info: - vm: '{{ test_vm1_info.id }}' - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_cdrom_devices_on_the_guest.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_cdrom_devices_on_the_guest.result.json deleted file mode 100644 index a838aa542fc..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_cdrom_devices_on_the_guest.result.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "value": [], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_cdrom_devices_on_the_guest.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_cdrom_devices_on_the_guest.task.yaml deleted file mode 100644 index e31ac100fa3..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_cdrom_devices_on_the_guest.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: List the cdrom devices on the guest - vmware.vmware_rest.vcenter_vm_hardware_cdrom_info: - vm: '{{ test_vm1_info.id }}' - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.result.json deleted file mode 100644 index 3b5e197e5a1..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.result.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "value": [ - { - "memory_size_MiB": 1024, - "vm": "vm-1650", - "name": "test_vm1", - "power_state": "POWERED_OFF", - "cpu_count": 1 - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.task.yaml deleted file mode 100644 index 43372ac3834..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Look up the VM called test_vm1 in the inventory - register: search_result - vmware.vmware_rest.vcenter_vm_info: - filter_names: - - test_vm1 diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Remove_SATA_adapter_at_PCI_slot_34.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Remove_SATA_adapter_at_PCI_slot_34.result.json deleted file mode 100644 index aac751af72e..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Remove_SATA_adapter_at_PCI_slot_34.result.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_a_list_of_all_the_datastores.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_a_list_of_all_the_datastores.result.json deleted file mode 100644 index 48c3cf80b78..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_a_list_of_all_the_datastores.result.json +++ /dev/null @@ -1,26 +0,0 @@ -{ - "value": [ - { - "datastore": "datastore-1644", - "name": "local", - "type": "VMFS", - "free_space": 13523484672, - "capacity": 15032385536 - }, - { - "datastore": "datastore-1645", - "name": "ro_datastore", - "type": "NFS", - "free_space": 24638349312, - "capacity": 26831990784 - }, - { - "datastore": "datastore-1646", - "name": "rw_datastore", - "type": "NFS", - "free_space": 24638349312, - "capacity": 26831990784 - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_a_list_of_all_the_datastores.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_a_list_of_all_the_datastores.task.yaml deleted file mode 100644 index 1ded56f0869..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_a_list_of_all_the_datastores.task.yaml +++ /dev/null @@ -1,3 +0,0 @@ -- name: Retrieve a list of all the datastores - vmware.vmware_rest.vcenter_datastore_info: - register: my_datastores diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_details_about_the_first_cluster.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_details_about_the_first_cluster.result.json deleted file mode 100644 index 7c86727a827..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_details_about_the_first_cluster.result.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "value": { - "name": "my_cluster", - "resource_pool": "resgroup-1637" - }, - "id": "domain-c1636", - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_details_about_the_first_cluster.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_details_about_the_first_cluster.task.yaml deleted file mode 100644 index 4b097889525..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_details_about_the_first_cluster.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Retrieve details about the first cluster - vmware.vmware_rest.vcenter_cluster_info: - cluster: "{{ all_the_clusters.value[0].cluster }}" - register: my_cluster_info diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_disk_information_from_the_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_disk_information_from_the_VM.result.json deleted file mode 100644 index 922250ed0ca..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_disk_information_from_the_VM.result.json +++ /dev/null @@ -1,18 +0,0 @@ -{ - "value": [ - { - "scsi": { - "bus": 0, - "unit": 0 - }, - "backing": { - "vmdk_file": "[local] test_vm1_8/test_vm1.vmdk", - "type": "VMDK_FILE" - }, - "label": "Hard disk 1", - "type": "SCSI", - "capacity": 17179869184 - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_disk_information_from_the_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_disk_information_from_the_VM.task.yaml deleted file mode 100644 index e9c39a32124..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_disk_information_from_the_VM.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Retrieve the disk information from the VM - vmware.vmware_rest.vcenter_vm_hardware_disk_info: - vm: '{{ test_vm1_info.id }}' - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_memory_information_from_the_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_memory_information_from_the_VM.result.json deleted file mode 100644 index 88436c13af0..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_memory_information_from_the_VM.result.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "value": { - "size_MiB": 1024, - "hot_add_enabled": true - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_memory_information_from_the_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_memory_information_from_the_VM.task.yaml deleted file mode 100644 index bccf589e530..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_memory_information_from_the_VM.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Retrieve the memory information from the VM - vmware.vmware_rest.vcenter_vm_hardware_memory_info: - vm: '{{ test_vm1_info.id }}' - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_NIC's_start_connected_flag_on.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_NIC's_start_connected_flag_on.result.json deleted file mode 100644 index 9c0c9c1f407..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_NIC's_start_connected_flag_on.result.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "id": "4000", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_NIC's_start_connected_flag_on.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_NIC's_start_connected_flag_on.task.yaml deleted file mode 100644 index a06bbd9db33..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_NIC's_start_connected_flag_on.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Turn the NIC's start_connected flag on - vmware.vmware_rest.vcenter_vm_hardware_ethernet: - nic: '{{ vm_hardware_ethernet_1.id }}' - start_connected: true - vm: '{{ test_vm1_info.id }}' diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_power_of_the_VM_on.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_power_of_the_VM_on.result.json deleted file mode 100644 index a661aa055d3..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_power_of_the_VM_on.result.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_power_of_the_VM_on.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_power_of_the_VM_on.task.yaml deleted file mode 100644 index fc3b21164bf..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_power_of_the_VM_on.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Turn the power of the VM on - vmware.vmware_rest.vcenter_vm_power: - state: start - vm: '{{ test_vm1_info.id }}' diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Upgrade_the_VM_hardware_version.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Upgrade_the_VM_hardware_version.result.json deleted file mode 100644 index e15f41c5fae..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Upgrade_the_VM_hardware_version.result.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "id": null, - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Upgrade_the_VM_hardware_version.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Upgrade_the_VM_hardware_version.task.yaml deleted file mode 100644 index 6a5ad0dc48b..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Upgrade_the_VM_hardware_version.task.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- name: Upgrade the VM hardware version - vmware.vmware_rest.vcenter_vm_hardware: - upgrade_policy: AFTER_CLEAN_SHUTDOWN - upgrade_version: VMX_13 - vm: '{{ test_vm1_info.id }}' - register: _result diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Wait_until_my_VM_is_ready.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Wait_until_my_VM_is_ready.result.json deleted file mode 100644 index 849bde48318..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Wait_until_my_VM_is_ready.result.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "value": { - "auto_update_supported": false, - "upgrade_policy": "MANUAL", - "install_attempt_count": 0, - "version_status": "UNMANAGED", - "version_number": 10346, - "run_state": "RUNNING", - "version": "10346", - "install_type": "OPEN_VM_TOOLS" - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Wait_until_my_VM_is_ready.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Wait_until_my_VM_is_ready.task.yaml deleted file mode 100644 index f6f64e844b5..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Wait_until_my_VM_is_ready.task.yaml +++ /dev/null @@ -1,9 +0,0 @@ -- name: Wait until my VM is ready - vmware.vmware_rest.vcenter_vm_tools_info: - vm: '{{ test_vm1_info.id }}' - register: vm_tools_info - until: - - vm_tools_info is not failed - - vm_tools_info.value.run_state == "RUNNING" - retries: 60 - delay: 5 diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/collect_a_list_of_the_datacenters.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/collect_a_list_of_the_datacenters.result.json deleted file mode 100644 index 1225ad7f93a..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/collect_a_list_of_the_datacenters.result.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "value": [ - { - "name": "my_dc", - "datacenter": "datacenter-1630" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/collect_a_list_of_the_datacenters.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/collect_a_list_of_the_datacenters.task.yaml deleted file mode 100644 index beb2cc62160..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/collect_a_list_of_the_datacenters.task.yaml +++ /dev/null @@ -1,3 +0,0 @@ -- name: collect a list of the datacenters - vmware.vmware_rest.vcenter_datacenter_info: - register: my_datacenters diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst deleted file mode 100644 index 1af1d5b5af5..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst +++ /dev/null @@ -1,150 +0,0 @@ -.. _vmware_rest_vm_hardware_tuning: - -******************************* -How to modify a virtual machine -******************************* - -.. contents:: - :local: - - -Introduction -============ - -This section shows you how to use Ansible to modify an existing virtual machine. - -Scenario requirements -===================== - -You've already followed :ref:`vmware_rest_create_vm` and created a VM. - -How to add a CDROM drive to a virtual machine -============================================= - -In this example, we use the ``vcenter_vm_hardware_*`` modules to add a new CDROM to an existing VM. - -Add a new SATA adapter -______________________ - -First we create a new SATA adapter. We specify the ``pci_slot_number``. This way if we run the task again it won't do anything if there is already an adapter there. - -.. literalinclude:: task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.result.json - -Add a CDROM drive -_________________ - -Now we can create the CDROM drive: - -.. literalinclude:: task_outputs/Attach_an_ISO_image_to_a_guest_VM.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Attach_an_ISO_image_to_a_guest_VM.result.json - - -.. _vmware_rest_attach_a_network: - -How to attach a VM to a network -=============================== - -Attach a new NIC -________________ - -Here we attach the VM to the network (through the portgroup). We specify a ``pci_slot_number`` for the same reason. - -The second task adjusts the NIC configuration. - -.. literalinclude:: task_outputs/Attach_a_VM_to_a_dvswitch.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Attach_a_VM_to_a_dvswitch.result.json - -Adjust the configuration of the NIC -___________________________________ - -.. literalinclude:: task_outputs/Turn_the_NIC's_start_connected_flag_on.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Turn_the_NIC's_start_connected_flag_on.result.json - -Increase the memory of the VM -============================= - -We can also adjust the amount of memory that we dedicate to our VM. - -.. literalinclude:: task_outputs/Increase_the_memory_of_a_VM.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Increase_the_memory_of_a_VM.result.json - -Upgrade the hardware version of the VM -====================================== - -Here we use the ``vcenter_vm_hardware`` module to upgrade the version of the hardware: - -.. literalinclude:: task_outputs/Upgrade_the_VM_hardware_version.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Upgrade_the_VM_hardware_version.result.json - -Adjust the number of CPUs of the VM -=================================== - -You can use ``vcenter_vm_hardware_cpu`` for that: - -.. literalinclude:: task_outputs/Dedicate_one_core_to_the_VM.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Dedicate_one_core_to_the_VM.result.json - -Remove a SATA controller -======================== - -In this example, we remove the SATA controller of the PCI slot 34. - -.. literalinclude:: task_outputs/Remove_SATA_adapter_at_PCI_slot_34.result.json - -Result -______ - -.. literalinclude:: task_outputs/Remove_SATA_adapter_at_PCI_slot_34.result.json - -Attach a floppy drive -===================== - -Here we attach a floppy drive to a VM. - -.. literalinclude:: task_outputs/Add_a_floppy_disk_drive.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Add_a_floppy_disk_drive.result.json - -Attach a new disk -================= - -Here we attach a tiny disk to the VM. The ``capacity`` is in bytes. - -.. literalinclude:: task_outputs/Create_a_new_disk.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Create_a_new_disk.result.json diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_info.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_info.rst deleted file mode 100644 index 097b69b1a13..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_info.rst +++ /dev/null @@ -1,129 +0,0 @@ -.. _vmware_rest_vm_info: - -*************************************** -Retrieve information from a specific VM -*************************************** - -.. contents:: - :local: - - -Introduction -============ - -This section shows you how to use Ansible to retrieve information about a specific virtual machine. - -Scenario requirements -===================== - -You've already followed :ref:`vmware_rest_create_vm` and you've got create a new VM called ``test_vm1``. - -How to collect virtual machine information -========================================== - -List the VM -___________ - -In this example, we use the ``vcenter_vm_info`` module to collect information about our new VM. - -In this example, we start by asking for a list of VMs. We use a filter to limit the results to just the VM called ``test_vm1``. So we are in a list context, with one single entry in the ``value`` key. - -.. literalinclude:: task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.task.yaml - -Result -______ - -As expected, we get a list. And thanks to our filter, we just get one entry. - -.. literalinclude:: task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.result.json - -Collect the details about a specific VM -_______________________________________ - -For the next steps, we pass the ID of the VM through the ``vm`` parameter. This allow us to collect more details about this specific VM. - -.. literalinclude:: task_outputs/Collect_information_about_a_specific_VM.task.yaml - -Result -______ - -The result is a structure with all the details about our VM. You will note this is actually the same information that we get when we created the VM. - -.. literalinclude:: task_outputs/Collect_information_about_a_specific_VM.result.json - - -Get the hardware version of a specific VM -_________________________________________ - -We can also use all the ``vcenter_vm_*_info`` modules to retrieve a smaller amount -of information. Here we use ``vcenter_vm_hardware_info`` to know the hardware version of -the VM. - -.. literalinclude:: task_outputs/Collect_the_hardware_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Collect_the_hardware_information.result.json - -List the SCSI adapter(s) of a specific VM -_________________________________________ - -Here for instance, we list the SCSI adapter(s) of the VM: - -.. literalinclude:: task_outputs/List_the_SCSI_adapter_of_a_given_VM.task.yaml - -You can do the same for the SATA controllers with ``vcenter_vm_adapter_sata_info``. - -Result -______ - -.. literalinclude:: task_outputs/List_the_SCSI_adapter_of_a_given_VM.result.json - -List the CDROM drive(s) of a specific VM -________________________________________ - -And we list its CDROM drives. - -.. literalinclude:: task_outputs/List_the_cdrom_devices_on_the_guest.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/List_the_cdrom_devices_on_the_guest.result.json - -Get the memory information of the VM -____________________________________ - -Here we collect the memory information of the VM: - -.. literalinclude:: task_outputs/Retrieve_the_memory_information_from_the_VM.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Retrieve_the_memory_information_from_the_VM.result.json - -Get the storage policy of the VM --------------------------------- - -We use the ``vcenter_vm_storage_policy_info`` module for that: - -.. literalinclude:: task_outputs/Get_VM_storage_policy.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_VM_storage_policy.result.json - -Get the disk information of the VM ----------------------------------- - -We use the ``vcenter_vm_hardware_disk_info`` for this operation: - -.. literalinclude:: task_outputs/Retrieve_the_disk_information_from_the_VM.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Retrieve_the_disk_information_from_the_VM.result.json diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst deleted file mode 100644 index b29447aec52..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst +++ /dev/null @@ -1,45 +0,0 @@ -.. _vmware_rest_vm_tool_configuration: - -************************************************************** -How to configure the VMware tools of a running virtual machine -************************************************************** - -.. contents:: - :local: - - -Introduction -============ - -This section show you how to collection information from a running virtual machine. - -Scenario requirements -===================== - -You've already followed :ref:`vmware_rest_run_a_vm` and your virtual machine runs VMware Tools. - -How to change the upgrade policy -================================ - -Change the upgrade policy to MANUAL ---------------------------------------------------- - -You can adjust the VMware Tools upgrade policy with the ``vcenter_vm_tools`` module. - -.. literalinclude:: task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.result.json - - -Change the upgrade policy to UPGRADE_AT_POWER_CYCLE ------------------------------------------------------------------------------------------- - -.. literalinclude:: task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.result.json diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst deleted file mode 100644 index 2f92871db37..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst +++ /dev/null @@ -1,90 +0,0 @@ -.. _vmware_rest_vm_tool_information: - -***************************************************** -How to get information from a running virtual machine -***************************************************** - -.. contents:: - :local: - - -Introduction -============ - -This section shows you how to collection information from a running virtual machine. - -Scenario requirements -===================== - -You've already followed :ref:`vmware_rest_run_a_vm` and your virtual machine runs VMware Tools. - -How to collect information -========================== - -In this example, we use the ``vcenter_vm_guest_*`` module to collect information about the associated resources. - -Filesystem ----------- - -Here we use ``vcenter_vm_guest_localfilesystem_info`` to retrieve the details -about the filesystem of the guest. In this example we also use a ``retries`` -loop. The VMware Tools may take a bit of time to start and by doing so, we give -the VM a bit more time. - -.. literalinclude:: task_outputs/Get_guest_filesystem_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_guest_filesystem_information.result.json - -Guest identity --------------- - -You can use ``vcenter_vm_guest_identity_info`` to get details like the OS family or the hostname of the running VM. - -.. literalinclude:: task_outputs/Get_guest_identity_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_guest_identity_information.result.json - -Network -------- - -``vcenter_vm_guest_networking_info`` will return the OS network configuration. - -.. literalinclude:: task_outputs/Get_guest_networking_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_guest_networking_information.result.json - -Network interfaces ------------------- - -``vcenter_vm_guest_networking_interfaces_info`` will return a list of NIC configurations. - -See also :ref:`vmware_rest_attach_a_network`. - -.. literalinclude:: task_outputs/Get_guest_network_interfaces_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_guest_network_interfaces_information.result.json - -Network routes --------------- - -Use ``vcenter_vm_guest_networking_routes_info`` to explore the route table of your virtual machine. - -.. literalinclude:: task_outputs/Get_guest_network_routes_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_guest_network_routes_information.result.json - diff --git a/docs/docsite/rst/shared_snippets/basic_concepts.txt b/docs/docsite/rst/shared_snippets/basic_concepts.txt deleted file mode 100644 index f2648cbf6a9..00000000000 --- a/docs/docsite/rst/shared_snippets/basic_concepts.txt +++ /dev/null @@ -1,69 +0,0 @@ -Control node -============ -The machine from which you run the Ansible CLI tools (``ansible-playbook`` , ``ansible``, ``ansible-vault`` and others). -You can use any computer that meets the software requirements as a control node - laptops, shared desktops, and servers can all run Ansible. -Multiple control nodes are possible, but Ansible itself does not coordinate across them, see ``AAP`` for such features. - - -Managed nodes -============= -Also referred to as 'hosts', these are the target devices (servers, network appliances or any computer) you aim to manage with Ansible. -Ansible is not normally installed on managed nodes, unless you are using ``ansible-pull``, but this is rare and not the recommended setup. - - -Inventory -========= -A list of managed nodes provided by one or more 'inventory sources'. Your inventory can specify information specific to each node, like IP address. -It is also used for assigning groups, that both allow for node selection in the Play and bulk variable assignment. -To learn more about inventory, see :ref:`the Working with Inventory` section. Sometimes an inventory source file is also referred to as a 'hostfile'. - - -Playbooks -========= -They contain Plays (which are the basic unit of Ansible execution). This is both an 'execution concept' and how we describe the files on which ``ansible-playbook`` operates. -Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`. - -Plays ------ -The main context for Ansible execution, this playbook object maps managed nodes (hosts) to tasks. -The Play contains variables, roles and an ordered lists of tasks and can be run repeatedly. -It basically consists of an implicit loop over the mapped hosts and tasks and defines how to iterate over them. - -Roles -..... -A limited distribution of reusable Ansible content (tasks, handlers, variables, plugins, templates and files) for use inside of a Play. -To use any Role resource, the Role itself must be imported into the Play. - -Tasks -..... -The definition of an 'action' to be applied to the managed host. Tasks must always be contained in a Play, directly or indirectly (Role, or imported/included task list file). -You can execute a single task once with an ad hoc command using ``ansible`` or ``ansible-console`` (both create a virtual Play). - -Handlers -........ -A special form of a Task, that only executes when notified by a previous task which resulted in a 'changed' status. - - -Modules -======= -The code or binaries that Ansible copies to and executes on each managed node (when needed) to accomplish the action defined in each Task. -Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device. -You can invoke a single module with a task, or invoke several different modules in a playbook. -Ansible modules are grouped in collections. For an idea of how many collections Ansible includes, see the :ref:`list_of_collections`. - - -Plugins -======= -Pieces of code that expand Ansible's core capabilities, they can control how you connect to a managed node (connection plugins), -manipulate data (filter plugins) and even control what is displayed in the console (callback plugins). -See :ref:`working_with_plugins` for details. - - -Collections -=========== -A format in which Ansible content is distributed that can contain playbooks, roles, modules, and plugins. You can install and use collections through `Ansible Galaxy `_. To learn more about collections, see :ref:`collections`. Collection resources can be used independently and discretely from each other. - - -AAP -=== -Short for 'Ansible Automation Platform'. This is a product that includes enterprise level features and integrates many tools of the Ansible ecosystem: ansible-core, awx, galaxyNG, and so on. diff --git a/docs/docsite/rst/shared_snippets/download_tarball_collections.txt b/docs/docsite/rst/shared_snippets/download_tarball_collections.txt deleted file mode 100644 index 045004be271..00000000000 --- a/docs/docsite/rst/shared_snippets/download_tarball_collections.txt +++ /dev/null @@ -1,8 +0,0 @@ - - -To download the collection tarball from Galaxy for offline use: - -#. Navigate to the collection page. -#. Click on :guilabel:`Download tarball`. - -You may also need to manually download any dependent collections. diff --git a/docs/docsite/rst/shared_snippets/galaxy_server_list.txt b/docs/docsite/rst/shared_snippets/galaxy_server_list.txt deleted file mode 100644 index cb4b682baab..00000000000 --- a/docs/docsite/rst/shared_snippets/galaxy_server_list.txt +++ /dev/null @@ -1,78 +0,0 @@ - - -By default, ``ansible-galaxy`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`). - -You can use either option below to configure ``ansible-galaxy collection`` to use other servers (such as a custom Galaxy server): - -* Set the server list in the :ref:`galaxy_server_list` configuration option in :ref:`ansible_configuration_settings_locations`. -* Use the ``--server`` command line argument to limit to an individual server. - -To configure a Galaxy server list in ``ansible.cfg``: - - -#. Add the ``server_list`` option under the ``[galaxy]`` section to one or more server names. -#. Create a new section for each server name. -#. Set the ``url`` option for each server name. -#. Optionally, set the API token for each server name. Go to https://galaxy.ansible.com/me/preferences and click :guilabel:`Show API key`. - -.. note:: - The ``url`` option for each server name must end with a forward slash ``/``. If you do not set the API token in your Galaxy server list, use the ``--api-key`` argument to pass in the token to the ``ansible-galaxy collection publish`` command. - - -The following example shows how to configure multiple servers: - -.. code-block:: ini - - [galaxy] - server_list = my_org_hub, release_galaxy, test_galaxy, my_galaxy_ng - - [galaxy_server.my_org_hub] - url=https://automation.my_org/ - username=my_user - password=my_pass - - [galaxy_server.release_galaxy] - url=https://galaxy.ansible.com/ - token=my_token - - [galaxy_server.test_galaxy] - url=https://galaxy-dev.ansible.com/ - token=my_test_token - - [galaxy_server.my_galaxy_ng] - url=http://my_galaxy_ng:8000/api/automation-hub/ - auth_url=http://my_keycloak:8080/auth/realms/myco/protocol/openid-connect/token - client_id=galaxy-ng - token=my_keycloak_access_token - -.. note:: - You can use the ``--server`` command line argument to select an explicit Galaxy server in the ``server_list`` and - the value of this argument should match the name of the server. To use a server not in the server list, set the value to the URL to access that server (all servers in the server list will be ignored). Also you cannot use the ``--api-key`` argument for any of the predefined servers. You can only use the ``api_key`` argument if you did not define a server list or if you specify a URL in the - ``--server`` argument. - -**Galaxy server list configuration options** - -The :ref:`galaxy_server_list` option is a list of server identifiers in a prioritized order. When searching for a -collection, the install process will search in that order, for example, ``automation_hub`` first, then ``my_org_hub``, ``release_galaxy``, and -finally ``test_galaxy`` until the collection is found. The actual Galaxy instance is then defined under the section -``[galaxy_server.{{ id }}]`` where ``{{ id }}`` is the server identifier defined in the list. This section can then -define the following keys: - -* ``url``: The URL of the Galaxy instance to connect to. Required. -* ``token``: An API token key to use for authentication against the Galaxy instance. Mutually exclusive with ``username``. -* ``username``: The username to use for basic authentication against the Galaxy instance. Mutually exclusive with ``token``. -* ``password``: The password to use, in conjunction with ``username``, for basic authentication. -* ``auth_url``: The URL of a Keycloak server 'token_endpoint' if using SSO authentication (for example, galaxyNG). Mutually exclusive with ``username``. Requires ``token``. -* ``validate_certs``: Whether or not to verify TLS certificates for the Galaxy server. This defaults to True unless the ``--ignore-certs`` option is provided or ``GALAXY_IGNORE_CERTS`` is configured to True. -* ``client_id``: The Keycloak token's client_id to use for authentication. Requires ``auth_url`` and ``token``. The default ``client_id`` is cloud-services to work with Red Hat SSO. - -As well as defining these server options in the ``ansible.cfg`` file, you can also define them as environment variables. -The environment variable is in the form ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` where ``{{ id }}`` is the upper -case form of the server identifier and ``{{ key }}`` is the key to define. For example, you can define ``token`` for -``release_galaxy`` by setting ``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token``. - -For operations that use only one Galaxy server (for example, the ``publish``, ``info``, or ``install`` commands). the ``ansible-galaxy collection`` command uses the first entry in the -``server_list``, unless you pass in an explicit server with the ``--server`` argument. - -.. note:: - ``ansible-galaxy`` can seek out dependencies on other configured Galaxy instances to support the use case where a collection can depend on a collection from another Galaxy instance. diff --git a/docs/docsite/rst/shared_snippets/installing_collections.txt b/docs/docsite/rst/shared_snippets/installing_collections.txt deleted file mode 100644 index 23f5c3e78cc..00000000000 --- a/docs/docsite/rst/shared_snippets/installing_collections.txt +++ /dev/null @@ -1,72 +0,0 @@ - - -By default, ``ansible-galaxy collection install`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the -:file:`ansible.cfg` file under :ref:`galaxy_server`). You do not need any -further configuration. - -See :ref:`Configuring the ansible-galaxy client ` if you are using any other Galaxy server, such as Red Hat Automation Hub. - -To install a collection hosted in Galaxy: - -.. code-block:: bash - - ansible-galaxy collection install my_namespace.my_collection - -To upgrade a collection to the latest available version from the Galaxy server you can use the ``--upgrade`` option: - -.. code-block:: bash - - ansible-galaxy collection install my_namespace.my_collection --upgrade - -You can also directly use the tarball from your build: - -.. code-block:: bash - - ansible-galaxy collection install my_namespace-my_collection-1.0.0.tar.gz -p ./collections - -You can build and install a collection from a local source directory. The ``ansible-galaxy`` utility builds the collection using the ``MANIFEST.json`` or ``galaxy.yml`` -metadata in the directory. - -.. code-block:: bash - - ansible-galaxy collection install /path/to/collection -p ./collections - -You can also install multiple collections in a namespace directory. - -.. code-block:: text - - ns/ - ├── collection1/ - │   ├── MANIFEST.json - │   └── plugins/ - └── collection2/ - ├── galaxy.yml - └── plugins/ - -.. code-block:: bash - - ansible-galaxy collection install /path/to/ns -p ./collections - -.. note:: - The install command automatically appends the path ``ansible_collections`` to the one specified with the ``-p`` option unless the - parent directory is already in a folder called ``ansible_collections``. - - -When using the ``-p`` option to specify the install path, use one of the values configured in :ref:`COLLECTIONS_PATHS`, as this is -where Ansible itself will expect to find collections. If you don't specify a path, ``ansible-galaxy collection install`` installs -the collection to the first path defined in :ref:`COLLECTIONS_PATHS`, which by default is ``~/.ansible/collections`` - -You can also keep a collection adjacent to the current playbook, under a ``collections/ansible_collections/`` directory structure. - -.. code-block:: text - - ./ - ├── play.yml - ├── collections/ - │ └── ansible_collections/ - │ └── my_namespace/ - │ └── my_collection/ - - -See :ref:`collection_structure` for details on the collection directory structure. - diff --git a/docs/docsite/rst/shared_snippets/installing_collections_file.rst b/docs/docsite/rst/shared_snippets/installing_collections_file.rst deleted file mode 100644 index 7c4fbcd9cb4..00000000000 --- a/docs/docsite/rst/shared_snippets/installing_collections_file.rst +++ /dev/null @@ -1,24 +0,0 @@ -Ansible can also install from a source directory in several ways: - -.. code-block:: yaml - - collections: - # directory containing the collection - - source: ./my_namespace/my_collection/ - type: dir - - # directory containing a namespace, with collections as subdirectories - - source: ./my_namespace/ - type: subdirs - -Ansible can also install a collection collected with ``ansible-galaxy collection build`` or downloaded from Galaxy for offline use by specifying the output file directly: - -.. code-block:: yaml - - collections: - - name: /tmp/my_namespace-my_collection-1.0.0.tar.gz - type: file - -.. note:: - - Relative paths are calculated from the current working directory (where you are invoking ``ansible-galaxy install -r`` from). They are not taken relative to the ``requirements.yml`` file. diff --git a/docs/docsite/rst/shared_snippets/installing_collections_git_repo.txt b/docs/docsite/rst/shared_snippets/installing_collections_git_repo.txt deleted file mode 100644 index ba11d25d3e2..00000000000 --- a/docs/docsite/rst/shared_snippets/installing_collections_git_repo.txt +++ /dev/null @@ -1,105 +0,0 @@ -You can install a collection from a git repository instead of from Galaxy or Automation Hub. As a developer, installing from a git repository lets you review your collection before you create the tarball and publish the collection. As a user, installing from a git repository lets you use collections or versions that are not in Galaxy or Automation Hub yet. - -The repository must contain a ``galaxy.yml`` or ``MANIFEST.json`` file. This file provides metadata such as the version number and namespace of the collection. - -Installing a collection from a git repository at the command line -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To install a collection from a git repository at the command line, use the URI of the repository instead of a collection name or path to a ``tar.gz`` file. Use the prefix ``git+``, unless you're using SSH authentication with the user ``git`` (for example, ``git@github.com:ansible-collections/ansible.windows.git``). You can specify a branch, commit, or tag using the comma-separated `git commit-ish `_ syntax. - -For example: - -.. code-block:: bash - - # Install a collection in a repository using the latest commit on the branch 'devel' - ansible-galaxy collection install git+https://github.com/organization/repo_name.git,devel - - # Install a collection from a private github repository - ansible-galaxy collection install git@github.com:organization/repo_name.git - - # Install a collection from a local git repository - ansible-galaxy collection install git+file:///home/user/path/to/repo_name.git - -.. warning:: - - Embedding credentials into a git URI is not secure. Use safe authentication options to prevent your credentials from being exposed in logs or elsewhere. - - * Use `SSH `_ authentication - * Use `netrc `_ authentication - * Use `http.extraHeader `_ in your git configuration - * Use `url..pushInsteadOf `_ in your git configuration - -Specifying the collection location within the git repository -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When you install a collection from a git repository, Ansible uses the collection ``galaxy.yml`` or ``MANIFEST.json`` metadata file to build the collection. By default, Ansible searches two paths for collection ``galaxy.yml`` or ``MANIFEST.json`` metadata files: - -* The top level of the repository. -* Each directory in the repository path (one level deep). - -If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in the top level of the repository, Ansible uses the collection metadata in that file to install an individual collection. - -.. code-block:: text - - ├── galaxy.yml - ├── plugins/ - │   ├── lookup/ - │   ├── modules/ - │   └── module_utils/ - └─── README.md - -If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in one or more directories in the repository path (one level deep), Ansible installs each directory with a metadata file as a collection. For example, Ansible installs both collection1 and collection2 from this repository structure by default: - -.. code-block:: text - - ├── collection1 - │   ├── docs/ - │   ├── galaxy.yml - │   └── plugins/ - │    ├── inventory/ - │   └── modules/ - └── collection2 -    ├── docs/ -    ├── galaxy.yml -    ├── plugins/ -   |   ├── filter/ -    | └── modules/ -    └── roles/ - -If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate the location of the metadata file or files. The path should be a directory, not the metadata file itself. For example, to install only collection2 from the example repository with two collections: - -.. code-block:: text - - ansible-galaxy collection install git+https://github.com/organization/repo_name.git#/collection2/ - -In some repositories, the main directory corresponds to the namespace: - -.. code-block:: text - - namespace/ - ├── collectionA/ - | ├── docs/ - | ├── galaxy.yml - | ├── plugins/ - | │   ├── README.md - | │   └── modules/ - | ├── README.md - | └── roles/ - └── collectionB/ - ├── docs/ - ├── galaxy.yml - ├── plugins/ - │   ├── connection/ - │   └── modules/ - ├── README.md - └── roles/ - -You can install all collections in this repository, or install one collection from a specific commit: - -.. code-block:: bash - - # Install all collections in the namespace - ansible-galaxy collection install git+https://github.com/organization/repo_name.git#/namespace/ - - # Install an individual collection using a specific commit - ansible-galaxy collection install git+https://github.com/organization/repo_name.git#/namespace/collectionA/,7b60ddc245bc416b72d8ea6ed7b799885110f5e5 diff --git a/docs/docsite/rst/shared_snippets/installing_multiple_collections.txt b/docs/docsite/rst/shared_snippets/installing_multiple_collections.txt deleted file mode 100644 index a1b18b59373..00000000000 --- a/docs/docsite/rst/shared_snippets/installing_multiple_collections.txt +++ /dev/null @@ -1,77 +0,0 @@ - -You can set up a ``requirements.yml`` file to install multiple collections in one command. This file is a YAML file in the format: - -.. code-block:: yaml+jinja - - --- - collections: - # With just the collection name - - my_namespace.my_collection - - # With the collection name, version, and source options - - name: my_namespace.my_other_collection - version: ">=1.2.0" # Version range identifiers (default: ``*``) - source: ... # The Galaxy URL to pull the collection from (default: ``--api-server`` from cmdline) - -You can specify the following keys for each collection entry: - - * ``name`` - * ``version`` - * ``signatures`` - * ``source`` - * ``type`` - -The ``version`` key uses the same range identifier format documented in :ref:`collections_older_version`. - -The ``signatures`` key accepts a list of signature sources that are used to supplement those found on the Galaxy server during collection installation and ``ansible-galaxy collection verify``. Signature sources should be URIs that contain the detached signature. The ``--keyring`` CLI option must be provided if signatures are specified. - -Signatures are only used to verify collections on Galaxy servers. User-provided signatures are not used to verify collections installed from git repositories, source directories, or URLs/paths to tar.gz files. - -.. code-block:: yaml - - collections: - - name: namespace.name - version: 1.0.0 - type: galaxy - signatures: - - https://examplehost.com/detached_signature.asc - - file:///path/to/local/detached_signature.asc - -The ``type`` key can be set to ``file``, ``galaxy``, ``git``, ``url``, ``dir``, or ``subdirs``. If ``type`` is omitted, the ``name`` key is used to implicitly determine the source of the collection. - -When you install a collection with ``type: git``, the ``version`` key can refer to a branch or to a `git commit-ish `_ object (commit or tag). For example: - -.. code-block:: yaml - - collections: - - name: https://github.com/organization/repo_name.git - type: git - version: devel - -You can also add roles to a ``requirements.yml`` file, under the ``roles`` key. The values follow the same format as a requirements file used in older Ansible releases. - -.. code-block:: yaml - - --- - roles: - # Install a role from Ansible Galaxy. - - name: geerlingguy.java - version: "1.9.6" # note that ranges are not supported for roles - - - collections: - # Install a collection from Ansible Galaxy. - - name: geerlingguy.php_roles - version: ">=0.9.3" - source: https://galaxy.ansible.com - -To install both roles and collections at the same time with one command, run the following: - -.. code-block:: bash - - $ ansible-galaxy install -r requirements.yml - -Running ``ansible-galaxy collection install -r`` or ``ansible-galaxy role install -r`` will only install collections, or roles respectively. - -.. note:: - Installing both roles and collections from the same requirements file will not work when specifying a custom collection or role install path. In this scenario the collections will be skipped and the command will process each like ``ansible-galaxy role install`` would. diff --git a/docs/docsite/rst/shared_snippets/installing_older_collection.txt b/docs/docsite/rst/shared_snippets/installing_older_collection.txt deleted file mode 100644 index 511dd2a7375..00000000000 --- a/docs/docsite/rst/shared_snippets/installing_older_collection.txt +++ /dev/null @@ -1,25 +0,0 @@ - -You can only have one version of a collection installed at a time. By default ``ansible-galaxy`` installs the latest available version. If you want to install a specific version, you can add a version range identifier. For example, to install the 1.0.0-beta.1 version of the collection: - -.. code-block:: bash - - ansible-galaxy collection install my_namespace.my_collection:==1.0.0-beta.1 - -You can specify multiple range identifiers separated by ``,``. Use single quotes so the shell passes the entire command, including ``>``, ``!``, and other operators, along. For example, to install the most recent version that is greater than or equal to 1.0.0 and less than 2.0.0: - -.. code-block:: bash - - ansible-galaxy collection install 'my_namespace.my_collection:>=1.0.0,<2.0.0' - -Ansible will always install the most recent version that meets the range identifiers you specify. You can use the following range identifiers: - -* ``*``: The most recent version. This is the default. -* ``!=``: Not equal to the version specified. -* ``==``: Exactly the version specified. -* ``>=``: Greater than or equal to the version specified. -* ``>``: Greater than the version specified. -* ``<=``: Less than or equal to the version specified. -* ``<``: Less than the version specified. - -.. note:: - By default ``ansible-galaxy`` ignores pre-release versions. To install a pre-release version, you must use the ``==`` range identifier to require it explicitly. diff --git a/docs/docsite/rst/tips_tricks/ansible_tips_tricks.rst b/docs/docsite/rst/tips_tricks/ansible_tips_tricks.rst deleted file mode 100644 index 6d2d008992d..00000000000 --- a/docs/docsite/rst/tips_tricks/ansible_tips_tricks.rst +++ /dev/null @@ -1,187 +0,0 @@ -.. _tips_and_tricks: - -General tips -============ - -These concepts apply to all Ansible activities and artifacts. - -Keep it simple --------------- - -Whenever you can, do things simply. Use advanced features only when necessary, and select the feature that best matches your use case. -For example, you will probably not need ``vars``, ``vars_files``, ``vars_prompt`` and ``--extra-vars`` all at once, while also using an external inventory file. -If something feels complicated, it probably is. Take the time to look for a simpler solution. - -Use version control -------------------- - -Keep your playbooks, roles, inventory, and variables files in git or another version control system and make commits to the repository when you make changes. -Version control gives you an audit trail describing when and why you changed the rules that automate your infrastructure. - -Customize the CLI output -------------------------- - -You can change the output from Ansible CLI commands using :ref:`callback_plugins`. - -.. _playbook_tips: - -Playbook tips -============= - -These tips help make playbooks and roles easier to read, maintain, and debug. - -Use whitespace --------------- - -Generous use of whitespace, for example, a blank line before each block or task, makes a playbook easy to scan. - -Always name tasks ------------------ - -Task names are optional, but extremely useful. In its output, Ansible shows you the name of each task it runs. -Choose names that describe what each task does and why. - -Always mention the state ------------------------- - -For many modules, the 'state' parameter is optional. -Different modules have different default settings for 'state', and some modules support several 'state' settings. -Explicitly setting 'state=present' or 'state=absent' makes playbooks and roles clearer. - -Use comments ------------- - -Even with task names and explicit state, sometimes a part of a playbook or role (or inventory/variable file) needs more explanation. -Adding a comment (any line starting with '#') helps others (and possibly yourself in future) understand what a play or task (or variable setting) does, how it does it, and why. - -.. _inventory_tips: - -Inventory tips -============== - -These tips help keep your inventory well organized. - -Use dynamic inventory with clouds ---------------------------------- - -With cloud providers and other systems that maintain canonical lists of your infrastructure, use :ref:`dynamic inventory ` to retrieve those lists instead of manually updating static inventory files. -With cloud resources, you can use tags to differentiate production and staging environments. - -Group inventory by function ---------------------------- - -A system can be in multiple groups. See :ref:`intro_inventory` and :ref:`intro_patterns`. -If you create groups named for the function of the nodes in the group, for example *webservers* or *dbservers*, your playbooks can target machines based on function. -You can assign function-specific variables using the group variable system, and design Ansible roles to handle function-specific use cases. -See :ref:`playbooks_reuse_roles`. - -Separate production and staging inventory ------------------------------------------ - -You can keep your production environment separate from development, test, and staging environments by using separate inventory files or directories for each environment. -This way you pick with -i what you are targeting. -Keeping all your environments in one file can lead to surprises! -For example, all vault passwords used in an inventory need to be available when using that inventory. -If an inventory contains both production and development environments, developers using that inventory would be able to access production secrets. - -.. _tip_for_variables_and_vaults: - -Keep vaulted variables safely visible -------------------------------------- - -You should encrypt sensitive or secret variables with Ansible Vault. -However, encrypting the variable names as well as the variable values makes it hard to find the source of the values. -To circumvent this, you can encrypt the variables individually using ``ansible-vault encrypt_string``, or add the following layer of indirection to keep the names of your variables accessible (by ``grep``, for example) without exposing any secrets: - -#. Create a ``group_vars/`` subdirectory named after the group. -#. Inside this subdirectory, create two files named ``vars`` and ``vault``. -#. In the ``vars`` file, define all of the variables needed, including any sensitive ones. -#. Copy all of the sensitive variables over to the ``vault`` file and prefix these variables with ``vault_``. -#. Adjust the variables in the ``vars`` file to point to the matching ``vault_`` variables using jinja2 syntax: ``db_password: "{{ vault_db_password }}"``. -#. Encrypt the ``vault`` file to protect its contents. -#. Use the variable name from the ``vars`` file in your playbooks. - -When running a playbook, Ansible finds the variables in the unencrypted file, which pulls the sensitive variable values from the encrypted file. -There is no limit to the number of variable and vault files or their names. - -Note that using this strategy in your inventory still requires *all vault passwords to be available* (for example for ``ansible-playbook`` or `AWX/Ansible Tower `_) when run with that inventory. - -.. _execution_tips: - -Execution tricks -================ - -These tips apply to using Ansible, rather than to Ansible artifacts. - -Try it in staging first ------------------------ - -Testing changes in a staging environment before rolling them out in production is always a great idea. -Your environments need not be the same size and you can use group variables to control the differences between those environments. - -Update in batches ------------------ - -Use the 'serial' keyword to control how many machines you update at once in the batch. -See :ref:`playbooks_delegation`. - -.. _os_variance: - -Handling OS and distro differences ----------------------------------- - -Group variables files and the ``group_by`` module work together to help Ansible execute across a range of operating systems and distributions that require different settings, packages, and tools. -The ``group_by`` module creates a dynamic group of hosts that match certain criteria. -This group does not need to be defined in the inventory file. -This approach lets you execute different tasks on different operating systems or distributions. - -For example, the following play categorizes all systems into dynamic groups based on the operating system name: - -.. literalinclude:: yaml/tip_group_by.yaml - :language: yaml - -Subsequent plays can use these groups as patterns on the ``hosts`` line as follows: - -.. literalinclude:: yaml/tip_group_hosts.yaml - :language: yaml - -You can also add group-specific settings in group vars files. -In the following example, CentOS machines get the value of '42' for `asdf` but other machines get '10'. -You can also use group vars files to apply roles to systems as well as set variables. - -.. code-block:: yaml - - --- - # file: group_vars/all - asdf: 10 - - --- - # file: group_vars/os_CentOS.yml - asdf: 42 - -.. note:: - All three names must match: the name created by the ``group_by`` task, the name of the pattern in subsequent plays, and the name of the group vars file. - -You can use the same setup with ``include_vars`` when you only need OS-specific variables, not tasks: - -.. literalinclude:: yaml/tip_include_vars.yaml - :language: yaml - -This pulls in variables from the `group_vars/os_CentOS.yml` file. - -.. seealso:: - - :ref:`yaml_syntax` - Learn about YAML syntax - :ref:`working_with_playbooks` - Review the basic playbook features - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_modules` - Learn how to extend Ansible by writing your own modules - :ref:`intro_patterns` - Learn about how to select hosts - `GitHub examples directory `_ - Complete playbook files from the github project source - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups diff --git a/docs/docsite/rst/tips_tricks/index.rst b/docs/docsite/rst/tips_tricks/index.rst deleted file mode 100644 index 36d83252699..00000000000 --- a/docs/docsite/rst/tips_tricks/index.rst +++ /dev/null @@ -1,23 +0,0 @@ -.. _tips_tricks_index: -.. _playbooks_best_practices: - -####################### -Ansible tips and tricks -####################### - -.. 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 `_. - -Welcome to the Ansible tips and tricks guide. -These tips and tricks have helped us optimize our Ansible usage and we offer them here as suggestions. -We hope they will help you organize content, write playbooks, maintain inventory, and execute Ansible. -Ultimately, though, you should use Ansible in the way that makes most sense for your organization and your goals. - -.. toctree:: - :maxdepth: 2 - - ansible_tips_tricks - sample_setup \ No newline at end of file diff --git a/docs/docsite/rst/tips_tricks/sample_setup.rst b/docs/docsite/rst/tips_tricks/sample_setup.rst deleted file mode 100644 index fc8c477169b..00000000000 --- a/docs/docsite/rst/tips_tricks/sample_setup.rst +++ /dev/null @@ -1,295 +0,0 @@ -.. _sample_setup: - -******************** -Sample Ansible setup -******************** - -You have learned about playbooks, inventory, roles, and variables. This section combines all those elements, and outlines a sample setup for automating a web service. You can find more example playbooks that illustrate these patterns in our `ansible-examples repository `_. (NOTE: These examples do not use all of the latest features, but are still an excellent reference.). - -The sample setup organizes playbooks, roles, inventory, and files with variables by function. Tags at the play and task level provide greater granularity and control. This is a powerful and flexible approach, but there are other ways to organize Ansible content. Your usage of Ansible should fit your needs, so feel free to modify this approach and organize your content accordingly. - -.. contents:: - :local: - -Sample directory layout ------------------------ - -This layout organizes most tasks in roles, with a single inventory file for each environment and a few playbooks in the top-level directory: - -.. code-block:: console - - production # inventory file for production servers - staging # inventory file for staging environment - - group_vars/ - group1.yml # here we assign variables to particular groups - group2.yml - host_vars/ - hostname1.yml # here we assign variables to particular systems - hostname2.yml - - library/ # if any custom modules, put them here (optional) - module_utils/ # if any custom module_utils to support modules, put them here (optional) - filter_plugins/ # if any custom filter plugins, put them here (optional) - - site.yml # main playbook - webservers.yml # playbook for webserver tier - dbservers.yml # playbook for dbserver tier - tasks/ # task files included from playbooks - webservers-extra.yml # <-- avoids confusing playbook with task files -.. include:: shared_snippets/role_directory.txt - -.. note:: By default, Ansible assumes your playbooks are stored in one directory with roles stored in a sub-directory called ``roles/``. With more tasks to automate, you can consider moving your playbooks into a sub-directory called ``playbooks/``. If you do this, you must configure the path to your ``roles/`` directory using the ``roles_path`` setting in the ``ansible.cfg`` file. - -Alternative directory layout ----------------------------- - -You can also put each inventory file with its ``group_vars``/``host_vars`` in a separate directory. This is particularly useful if your ``group_vars``/``host_vars`` do not have that much in common in different environments. The layout could look like this example: - - .. code-block:: console - - inventories/ - production/ - hosts # inventory file for production servers - group_vars/ - group1.yml # here we assign variables to particular groups - group2.yml - host_vars/ - hostname1.yml # here we assign variables to particular systems - hostname2.yml - - staging/ - hosts # inventory file for staging environment - group_vars/ - group1.yml # here we assign variables to particular groups - group2.yml - host_vars/ - stagehost1.yml # here we assign variables to particular systems - stagehost2.yml - - library/ - module_utils/ - filter_plugins/ - - site.yml - webservers.yml - dbservers.yml - - roles/ - common/ - webtier/ - monitoring/ - fooapp/ - -This layout gives you more flexibility for larger environments, as well as a total separation of inventory variables between different environments. However, this approach is harder to maintain, because there are more files. For more information on organizing group and host variables, see :ref:`splitting_out_vars`. - -.. _groups_and_hosts: - -Sample group and host variables -------------------------------- - -These sample group and host files with variables contain the values that apply to each machine or a group of machines. For instance, the data center in Atlanta has its own NTP servers. As a result, when setting up the ``ntp.conf`` file, you could use similar code as in this example: - - .. code-block:: yaml - - --- - # file: group_vars/atlanta - ntp: ntp-atlanta.example.com - backup: backup-atlanta.example.com - -Similarly, hosts in the webservers group have some configuration that does not apply to the database servers: - - .. code-block:: yaml - - --- - # file: group_vars/webservers - apacheMaxRequestsPerChild: 3000 - apacheMaxClients: 900 - -Default values, or values that are universally true, belong in a file called ``group_vars/all``: - - .. code-block:: yaml - - --- - # file: group_vars/all - ntp: ntp-boston.example.com - backup: backup-boston.example.com - -If necessary, you can define specific hardware variance in systems in the ``host_vars`` directory: - - .. code-block:: yaml - - --- - # file: host_vars/db-bos-1.example.com - foo_agent_port: 86 - bar_agent_port: 99 - -If you use :ref:`dynamic inventory `, Ansible creates many dynamic groups automatically. As a result, a tag like ``class:webserver`` will load in variables from the file ``group_vars/ec2_tag_class_webserver`` automatically. - -.. note:: You can access host variables with a special variable called ``hostvars``. See :ref:`special_variables` for a list of these variables. The ``hostvars`` variable can access only host-specific variables, not group variables. - - -.. _split_by_role: - -Sample playbooks organized by function --------------------------------------- - -With this setup, a single playbook can define the entire infrastructure. The ``site.yml`` playbook imports two other playbooks. One for the webservers and one for the database servers: - - .. code-block:: yaml - - --- - # file: site.yml - - import_playbook: webservers.yml - - import_playbook: dbservers.yml - -The ``webservers.yml`` playbook, also at the top level, maps the configuration of the webservers group to the roles related to the webservers group: - - .. code-block:: yaml - - --- - # file: webservers.yml - - hosts: webservers - roles: - - common - - webtier - -With this setup, you can configure your entire infrastructure by running ``site.yml``. Alternatively, to configure just a portion of your infrastructure, run ``webservers.yml``. This is similar to the Ansible ``--limit`` parameter but a little more explicit: - - .. code-block:: shell - - ansible-playbook site.yml --limit webservers - ansible-playbook webservers.yml - -.. _role_organization: - -Sample task and handler files in a function-based role ------------------------------------------------------- - -Ansible loads any file called ``main.yml`` in a role sub-directory. This sample ``tasks/main.yml`` file configures NTP: - - .. code-block:: yaml - - --- - # file: roles/common/tasks/main.yml - - - name: be sure ntp is installed - yum: - name: ntp - state: present - tags: ntp - - - name: be sure ntp is configured - template: - src: ntp.conf.j2 - dest: /etc/ntp.conf - notify: - - restart ntpd - tags: ntp - - - name: be sure ntpd is running and enabled - ansible.builtin.service: - name: ntpd - state: started - enabled: true - tags: ntp - -Here is an example handlers file. Handlers are only triggered when certain tasks report changes. Handlers run at the end of each play: - - .. code-block:: yaml - - --- - # file: roles/common/handlers/main.yml - - name: restart ntpd - ansible.builtin.service: - name: ntpd - state: restarted - -See :ref:`playbooks_reuse_roles` for more information. - - -.. _organization_examples: - -What the sample setup enables ------------------------------ - -The basic organizational structure described above enables a lot of different automation options. To reconfigure your entire infrastructure: - - .. code-block:: shell - - ansible-playbook -i production site.yml - -To reconfigure NTP on everything: - - .. code-block:: shell - - ansible-playbook -i production site.yml --tags ntp - -To reconfigure only the webservers: - - .. code-block:: shell - - ansible-playbook -i production webservers.yml - -To reconfigure only the webservers in Boston: - - .. code-block:: shell - - ansible-playbook -i production webservers.yml --limit boston - -To reconfigure only the first 10 webservers in Boston, and then the next 10: - - .. code-block:: shell - - ansible-playbook -i production webservers.yml --limit boston[0:9] - ansible-playbook -i production webservers.yml --limit boston[10:19] - -The sample setup also supports basic ad hoc commands: - - .. code-block:: shell - - ansible boston -i production -m ping - ansible boston -i production -m command -a '/sbin/reboot' - -To discover what tasks would run or what hostnames would be affected by a particular Ansible command: - - .. code-block:: shell - - # confirm what task names would be run if I ran this command and said "just ntp tasks" - ansible-playbook -i production webservers.yml --tags ntp --list-tasks - - # confirm what hostnames might be communicated with if I said "limit to boston" - ansible-playbook -i production webservers.yml --limit boston --list-hosts - -.. _dep_vs_config: - -Organizing for deployment or configuration ------------------------------------------- - -The sample setup illustrates a typical configuration topology. When you do multi-tier deployments, you will likely need some additional playbooks that hop between tiers to roll out an application. In this case, you can augment ``site.yml`` with playbooks like ``deploy_exampledotcom.yml``. However, the general concepts still apply. With Ansible you can deploy and configure using the same utility. Therefore, you will probably reuse groups and keep the OS configuration in separate playbooks or roles from the application deployment. - -Consider "playbooks" as a sports metaphor -- you can have one set of plays to use against all your infrastructure. Then you have situational plays that you use at different times and for different purposes. - -.. _ship_modules_with_playbooks: - -Using local Ansible modules ---------------------------- - -If a playbook has a :file:`./library` directory relative to its YAML file, you can use this directory to add Ansible modules automatically to the module path. This organizes modules with playbooks. For example, see the directory structure at the start of this section. - -.. seealso:: - - :ref:`yaml_syntax` - Learn about YAML syntax - :ref:`working_with_playbooks` - Review the basic playbook features - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_modules` - Learn how to extend Ansible by writing your own modules - :ref:`intro_patterns` - Learn about how to select hosts - `GitHub examples directory `_ - Complete playbook files from the github project source - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups diff --git a/docs/docsite/rst/tips_tricks/shared_snippets/role_directory.txt b/docs/docsite/rst/tips_tricks/shared_snippets/role_directory.txt deleted file mode 100644 index 25aa1784b19..00000000000 --- a/docs/docsite/rst/tips_tricks/shared_snippets/role_directory.txt +++ /dev/null @@ -1,26 +0,0 @@ -.. code-block:: yaml - - roles/ - common/ # this hierarchy represents a "role" - tasks/ # - main.yml # <-- tasks file can include smaller files if warranted - handlers/ # - main.yml # <-- handlers file - templates/ # <-- files for use with the template resource - ntp.conf.j2 # <------- templates end in .j2 - files/ # - bar.txt # <-- files for use with the copy resource - foo.sh # <-- script files for use with the script resource - vars/ # - main.yml # <-- variables associated with this role - defaults/ # - main.yml # <-- default lower priority variables for this role - meta/ # - main.yml # <-- role dependencies and optional Galaxy info - library/ # roles can also include custom modules - module_utils/ # roles can also include custom module_utils - lookup_plugins/ # or other types of plugins, like lookup in this case - - webtier/ # same kind of structure as "common" was above, done for the webtier role - monitoring/ # "" - fooapp/ # "" diff --git a/docs/docsite/rst/tips_tricks/yaml/tip_group_by.yaml b/docs/docsite/rst/tips_tricks/yaml/tip_group_by.yaml deleted file mode 100644 index f13e5747712..00000000000 --- a/docs/docsite/rst/tips_tricks/yaml/tip_group_by.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- name: talk to all hosts just so we can learn about them - hosts: all - tasks: - - name: Classify hosts depending on their OS distribution - group_by: - key: os_{{ ansible_facts['distribution'] }} diff --git a/docs/docsite/rst/tips_tricks/yaml/tip_group_hosts.yaml b/docs/docsite/rst/tips_tricks/yaml/tip_group_hosts.yaml deleted file mode 100644 index a85b4d92c74..00000000000 --- a/docs/docsite/rst/tips_tricks/yaml/tip_group_hosts.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- hosts: os_CentOS - gather_facts: False - tasks: - # Tasks for CentOS hosts only go in this play. - - name: Ping my CentOS hosts - ansible.builtin.ping: diff --git a/docs/docsite/rst/tips_tricks/yaml/tip_include_vars.yaml b/docs/docsite/rst/tips_tricks/yaml/tip_include_vars.yaml deleted file mode 100644 index 2419525a8c9..00000000000 --- a/docs/docsite/rst/tips_tricks/yaml/tip_include_vars.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- hosts: all - tasks: - - name: Set OS distribution dependent variables - include_vars: "os_{{ ansible_facts['distribution'] }}.yml" - - debug: - var: asdf diff --git a/docs/docsite/rst/user_guide/basic_concepts.rst b/docs/docsite/rst/user_guide/basic_concepts.rst deleted file mode 100644 index b2e20ab578c..00000000000 --- a/docs/docsite/rst/user_guide/basic_concepts.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -**************** -Ansible concepts -**************** - -This page has moved to :ref:`Getting started with Ansible`. diff --git a/docs/docsite/rst/user_guide/become.rst b/docs/docsite/rst/user_guide/become.rst deleted file mode 100644 index 94503b19203..00000000000 --- a/docs/docsite/rst/user_guide/become.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -****************************************** -Understanding privilege escalation: become -****************************************** - -This page has moved to :ref:`playbooks_privilege_escalation`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/cheatsheet.rst b/docs/docsite/rst/user_guide/cheatsheet.rst deleted file mode 100644 index a25dda71c7f..00000000000 --- a/docs/docsite/rst/user_guide/cheatsheet.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -********************** -Ansible CLI cheatsheet -********************** - -This page has moved to :ref:`cheatsheet`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/collections_using.rst b/docs/docsite/rst/user_guide/collections_using.rst deleted file mode 100644 index 02c7e95c513..00000000000 --- a/docs/docsite/rst/user_guide/collections_using.rst +++ /dev/null @@ -1,8 +0,0 @@ - -:orphan: - -***************** -Using collections -***************** - -This page has moved to :ref:`collections_index`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/command_line_tools.rst b/docs/docsite/rst/user_guide/command_line_tools.rst deleted file mode 100644 index 7545f17a3ce..00000000000 --- a/docs/docsite/rst/user_guide/command_line_tools.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Working with command line tools -=============================== - -This page has moved to :ref:`command_line_tools`. diff --git a/docs/docsite/rst/user_guide/complex_data_manipulation.rst b/docs/docsite/rst/user_guide/complex_data_manipulation.rst deleted file mode 100644 index 1cfa0d22f72..00000000000 --- a/docs/docsite/rst/user_guide/complex_data_manipulation.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Data manipulation -################# - -This page has moved to :ref:`complex_data_manipulation`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/connection_details.rst b/docs/docsite/rst/user_guide/connection_details.rst deleted file mode 100644 index 6a54200a181..00000000000 --- a/docs/docsite/rst/user_guide/connection_details.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -****************************** -Connection methods and details -****************************** - -This page has moved to :ref:`connections`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/index.rst b/docs/docsite/rst/user_guide/index.rst deleted file mode 100644 index 9330382f216..00000000000 --- a/docs/docsite/rst/user_guide/index.rst +++ /dev/null @@ -1,26 +0,0 @@ -:orphan: - -.. _user_guide_index: - -########## -User Guide -########## - -.. 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 `_. - -Welcome to the Ansible User Guide! -This guide is now deprecated to improve navigation and organization. -You can find all the user guide content in the following sections: - -* :ref:`inventory_guide_index` -* :ref:`command_guide_index` -* :ref:`playbook_guide_index` -* :ref:`vault_guide_index` -* :ref:`modules_plugins_index` -* :ref:`collections_index` -* :ref:`os_guide_index` -* :ref:`tips_tricks_index` diff --git a/docs/docsite/rst/user_guide/intro.rst b/docs/docsite/rst/user_guide/intro.rst deleted file mode 100644 index 124bde65dea..00000000000 --- a/docs/docsite/rst/user_guide/intro.rst +++ /dev/null @@ -1,15 +0,0 @@ -:orphan: - -Introduction -============ - -Before we start exploring the main components of Ansible -- playbooks, configuration management, deployment, and orchestration -- we'll learn how to get Ansible installed and cover some basic concepts. We'll also go over how to execute ad hoc commands in parallel across your nodes using /usr/bin/ansible, and see what modules are available in Ansible's core (you can also write your own, which is covered later). - -.. toctree:: - :maxdepth: 1 - - ../installation_guide/index - ../dev_guide/overview_architecture - ../installation_guide/intro_configuration - intro_bsd - intro_windows diff --git a/docs/docsite/rst/user_guide/intro_adhoc.rst b/docs/docsite/rst/user_guide/intro_adhoc.rst deleted file mode 100644 index d88200541db..00000000000 --- a/docs/docsite/rst/user_guide/intro_adhoc.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -******************************* -Introduction to ad hoc commands -******************************* - -This page has moved to :ref:`intro_adhoc`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/intro_bsd.rst b/docs/docsite/rst/user_guide/intro_bsd.rst deleted file mode 100644 index 2dd99efd48d..00000000000 --- a/docs/docsite/rst/user_guide/intro_bsd.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Ansible and BSD -=============== - -This page has moved to :ref:`working_with_bsd`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/intro_dynamic_inventory.rst b/docs/docsite/rst/user_guide/intro_dynamic_inventory.rst deleted file mode 100644 index be573b852e2..00000000000 --- a/docs/docsite/rst/user_guide/intro_dynamic_inventory.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -****************************** -Working with dynamic inventory -****************************** - -This page has moved to :ref:`intro_dynamic_inventory`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/intro_inventory.rst b/docs/docsite/rst/user_guide/intro_inventory.rst deleted file mode 100644 index 6a10b219335..00000000000 --- a/docs/docsite/rst/user_guide/intro_inventory.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************************** -How to build your inventory -*************************** - -This page has moved to :ref:`intro_inventory`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/intro_patterns.rst b/docs/docsite/rst/user_guide/intro_patterns.rst deleted file mode 100644 index c0ba462a4c2..00000000000 --- a/docs/docsite/rst/user_guide/intro_patterns.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Patterns: targeting hosts and groups -==================================== - -This page has moved to :ref:`intro_patterns`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/intro_windows.rst b/docs/docsite/rst/user_guide/intro_windows.rst deleted file mode 100644 index 369888c3c56..00000000000 --- a/docs/docsite/rst/user_guide/intro_windows.rst +++ /dev/null @@ -1,4 +0,0 @@ -Windows Support -=============== - -You can find documentation for using Ansible on Windows at :ref:`os_guide_index`. diff --git a/docs/docsite/rst/user_guide/modules.rst b/docs/docsite/rst/user_guide/modules.rst deleted file mode 100644 index e060f6ed54a..00000000000 --- a/docs/docsite/rst/user_guide/modules.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Working With Modules -==================== - -This page has moved to :ref:`modules_plugins_index`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/modules_intro.rst b/docs/docsite/rst/user_guide/modules_intro.rst deleted file mode 100644 index cd7006e8ff3..00000000000 --- a/docs/docsite/rst/user_guide/modules_intro.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Introduction to modules -======================= - -This page has moved to :ref:`modules_plugins_index`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/modules_support.rst b/docs/docsite/rst/user_guide/modules_support.rst deleted file mode 100644 index daeeec4a6ad..00000000000 --- a/docs/docsite/rst/user_guide/modules_support.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -**************************** -Module Maintenance & Support -**************************** - -This page has moved to :ref:`modules_plugins_index`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks.rst b/docs/docsite/rst/user_guide/playbooks.rst deleted file mode 100644 index fe54708cfcd..00000000000 --- a/docs/docsite/rst/user_guide/playbooks.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Working with playbooks -====================== - -This page has moved to :ref:`working_with_playbooks`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_advanced_syntax.rst b/docs/docsite/rst/user_guide/playbooks_advanced_syntax.rst deleted file mode 100644 index f30eb86b31d..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_advanced_syntax.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************** -Advanced Syntax -*************** - -This page has moved to :ref:`playbooks_advanced_syntax`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_async.rst b/docs/docsite/rst/user_guide/playbooks_async.rst deleted file mode 100644 index 5ff2da2bcec..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_async.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Asynchronous actions and polling -================================ - -This page has moved to :ref:`playbooks_async`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_best_practices.rst b/docs/docsite/rst/user_guide/playbooks_best_practices.rst deleted file mode 100644 index 6395e391306..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_best_practices.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************** -Tips and tricks -*************** - -This page has moved to :ref:`tips_and_tricks`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_blocks.rst b/docs/docsite/rst/user_guide/playbooks_blocks.rst deleted file mode 100644 index 1137d6605f2..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_blocks.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -****** -Blocks -****** - -This page has moved to :ref:`playbooks_blocks`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_checkmode.rst b/docs/docsite/rst/user_guide/playbooks_checkmode.rst deleted file mode 100644 index 1b5d51e3897..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_checkmode.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -****************************************** -Validating tasks: check mode and diff mode -****************************************** - -This page has moved to :ref:`check_mode_dry`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_conditionals.rst b/docs/docsite/rst/user_guide/playbooks_conditionals.rst deleted file mode 100644 index 8d09a29664d..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_conditionals.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -************ -Conditionals -************ - -This page has moved to :ref:`playbooks_conditionals`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_debugger.rst b/docs/docsite/rst/user_guide/playbooks_debugger.rst deleted file mode 100644 index 196f3438699..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_debugger.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************** -Debugging tasks -*************** - -This page has moved to :ref:`playbook_debugger`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_delegation.rst b/docs/docsite/rst/user_guide/playbooks_delegation.rst deleted file mode 100644 index f0ff834fd89..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_delegation.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Controlling where tasks run: delegation and local actions -========================================================= - -This page has moved to :ref:`playbooks_delegation`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_environment.rst b/docs/docsite/rst/user_guide/playbooks_environment.rst deleted file mode 100644 index 1527372fe46..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_environment.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Setting the remote environment -============================== - -This page has moved to :ref:`playbooks_environment`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_error_handling.rst b/docs/docsite/rst/user_guide/playbooks_error_handling.rst deleted file mode 100644 index 95c77fd5531..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_error_handling.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************************** -Error handling in playbooks -*************************** - -This page has moved to :ref:`playbooks_error_handling`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_filters.rst b/docs/docsite/rst/user_guide/playbooks_filters.rst deleted file mode 100644 index 57fb4478208..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_filters.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -******************************** -Using filters to manipulate data -******************************** - -This page has moved to :ref:`playbooks_filters`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_filters_ipaddr.rst b/docs/docsite/rst/user_guide/playbooks_filters_ipaddr.rst deleted file mode 100644 index 3c3cdb57d54..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_filters_ipaddr.rst +++ /dev/null @@ -1,8 +0,0 @@ -:orphan: - -.. _playbooks_filters_ipaddr: - -ipaddr filter -````````````` - -This document has moved to :ref:`plugins_in_ansible.utils`. diff --git a/docs/docsite/rst/user_guide/playbooks_handlers.rst b/docs/docsite/rst/user_guide/playbooks_handlers.rst deleted file mode 100644 index 49b3ca5c2fa..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_handlers.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Handlers: running operations on change -====================================== - -This page has moved to :ref:`handlers`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_intro.rst b/docs/docsite/rst/user_guide/playbooks_intro.rst deleted file mode 100644 index cd8bd991e11..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_intro.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -****************** -Intro to playbooks -****************** - -This page has moved to :ref:`playbooks_intro`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_lookups.rst b/docs/docsite/rst/user_guide/playbooks_lookups.rst deleted file mode 100644 index 409555c3855..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_lookups.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -******* -Lookups -******* - -This page has moved to :ref:`playbooks_lookups`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_loops.rst b/docs/docsite/rst/user_guide/playbooks_loops.rst deleted file mode 100644 index bbed1cc9921..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_loops.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -***** -Loops -***** - -This page has moved to :ref:`playbooks_loops`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_module_defaults.rst b/docs/docsite/rst/user_guide/playbooks_module_defaults.rst deleted file mode 100644 index 026e6a50a8f..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_module_defaults.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Module defaults -=============== - -This page has moved to :ref:`module_defaults`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_prompts.rst b/docs/docsite/rst/user_guide/playbooks_prompts.rst deleted file mode 100644 index eacf4a3eda3..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_prompts.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -************************** -Interactive input: prompts -************************** - -This page has moved to :ref:`playbooks_prompts`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_reuse.rst b/docs/docsite/rst/user_guide/playbooks_reuse.rst deleted file mode 100644 index d27b437a5bc..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_reuse.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -************************** -Re-using Ansible artifacts -************************** - -This page has moved to :ref:`playbooks_reuse`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_reuse_includes.rst b/docs/docsite/rst/user_guide/playbooks_reuse_includes.rst deleted file mode 100644 index ec34700d23c..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_reuse_includes.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Including and importing -======================= - -The content on this page has been moved to :ref:`playbooks_reuse`. diff --git a/docs/docsite/rst/user_guide/playbooks_reuse_roles.rst b/docs/docsite/rst/user_guide/playbooks_reuse_roles.rst deleted file mode 100644 index 31d1ad0aa3d..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_reuse_roles.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -***** -Roles -***** - -This page has moved to :ref:`playbooks_reuse_roles`. diff --git a/docs/docsite/rst/user_guide/playbooks_startnstep.rst b/docs/docsite/rst/user_guide/playbooks_startnstep.rst deleted file mode 100644 index 0503683451f..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_startnstep.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************************************** -Executing playbooks for troubleshooting -*************************************** - -This page has moved to :ref:`playbooks_start_and_step`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_strategies.rst b/docs/docsite/rst/user_guide/playbooks_strategies.rst deleted file mode 100644 index 6c39aa121cd..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_strategies.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Controlling playbook execution: strategies and more -=================================================== - -This page has moved to :ref:`playbooks_strategies`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_tags.rst b/docs/docsite/rst/user_guide/playbooks_tags.rst deleted file mode 100644 index 9bd706f81e5..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_tags.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -**** -Tags -**** - -This page has moved to :ref:`tags`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_tests.rst b/docs/docsite/rst/user_guide/playbooks_tests.rst deleted file mode 100644 index 49687053848..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_tests.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -***** -Tests -***** - -This page has moved to :ref:`playbooks_tests`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_variables.rst b/docs/docsite/rst/user_guide/playbooks_variables.rst deleted file mode 100644 index 8b798710922..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_variables.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************** -Using Variables -*************** - -This page has moved to :ref:`playbooks_variables`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_vars_facts.rst b/docs/docsite/rst/user_guide/playbooks_vars_facts.rst deleted file mode 100644 index 9305f58be56..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_vars_facts.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -************************************************ -Discovering variables: facts and magic variables -************************************************ - -This page has moved to :ref:`vars_and_facts`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/plugin_filtering_config.rst b/docs/docsite/rst/user_guide/plugin_filtering_config.rst deleted file mode 100644 index 18a0d769f40..00000000000 --- a/docs/docsite/rst/user_guide/plugin_filtering_config.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Rejecting modules -================= - -This page has moved to :ref:`modules_plugins_index`. diff --git a/docs/docsite/rst/user_guide/sample_setup.rst b/docs/docsite/rst/user_guide/sample_setup.rst deleted file mode 100644 index 40c3df7d37f..00000000000 --- a/docs/docsite/rst/user_guide/sample_setup.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -******************** -Sample Ansible setup -******************** - -This page has moved to :ref:`sample_setup`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/vault.rst b/docs/docsite/rst/user_guide/vault.rst deleted file mode 100644 index ea9c384b1b3..00000000000 --- a/docs/docsite/rst/user_guide/vault.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -************************************* -Encrypting content with Ansible Vault -************************************* - -This page has moved to :ref:`vault_guide_index`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/windows.rst b/docs/docsite/rst/user_guide/windows.rst deleted file mode 100644 index 922a7309323..00000000000 --- a/docs/docsite/rst/user_guide/windows.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Windows Guides -============== - -You can find documentation for using Ansible on Windows at :ref:`os_guide_index`. diff --git a/docs/docsite/rst/user_guide/windows_dsc.rst b/docs/docsite/rst/user_guide/windows_dsc.rst deleted file mode 100644 index e8e781e74b8..00000000000 --- a/docs/docsite/rst/user_guide/windows_dsc.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Desired State Configuration -=========================== - -This page has moved to :ref:`windows_dsc`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/windows_faq.rst b/docs/docsite/rst/user_guide/windows_faq.rst deleted file mode 100644 index 0dc92a9f329..00000000000 --- a/docs/docsite/rst/user_guide/windows_faq.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Windows Frequently Asked Questions -================================== - -This page has moved to :ref:`windows_faq`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/windows_performance.rst b/docs/docsite/rst/user_guide/windows_performance.rst deleted file mode 100644 index 82d8be303f8..00000000000 --- a/docs/docsite/rst/user_guide/windows_performance.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Windows performance -=================== - -This page has moved to :ref:`windows_performance`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/windows_setup.rst b/docs/docsite/rst/user_guide/windows_setup.rst deleted file mode 100644 index 95ac6457436..00000000000 --- a/docs/docsite/rst/user_guide/windows_setup.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Setting up a Windows Host -========================= - -This page has moved to :ref:`windows_setup`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/windows_usage.rst b/docs/docsite/rst/user_guide/windows_usage.rst deleted file mode 100644 index 2d637408799..00000000000 --- a/docs/docsite/rst/user_guide/windows_usage.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Using Ansible and Windows -========================= - -This page has moved to :ref:`windows_usage`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/windows_winrm.rst b/docs/docsite/rst/user_guide/windows_winrm.rst deleted file mode 100644 index 5ecb89d5acc..00000000000 --- a/docs/docsite/rst/user_guide/windows_winrm.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Windows Remote Management -========================= - -This page has moved to :ref:`windows_winrm`. \ No newline at end of file diff --git a/docs/docsite/rst/vault_guide/index.rst b/docs/docsite/rst/vault_guide/index.rst deleted file mode 100644 index ae7ad68db85..00000000000 --- a/docs/docsite/rst/vault_guide/index.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. _vault_guide_index: - -############################################ -Protecting sensitive data with Ansible vault -############################################ - -.. 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 `_. - -Welcome to the Ansible vault documentation. -Ansible vault provides a way to encrypt and manage sensitive data such as passwords. -This guide introduces you to Ansible vault and covers the following topics: - -* Managing vault passwords. -* Encrypting content and files with Ansible vault. -* Using encrypted variables and files. - -.. toctree:: - :maxdepth: 2 - - vault - vault_managing_passwords - vault_encrypting_content - vault_using_encrypted_content \ No newline at end of file diff --git a/docs/docsite/rst/vault_guide/vault.rst b/docs/docsite/rst/vault_guide/vault.rst deleted file mode 100644 index 3fa8d161877..00000000000 --- a/docs/docsite/rst/vault_guide/vault.rst +++ /dev/null @@ -1,18 +0,0 @@ -.. _vault: - -************* -Ansible Vault -************* - -Ansible Vault encrypts variables and files so you can protect sensitive content such as passwords or keys rather than leaving it visible as plaintext in playbooks or roles. -To use Ansible Vault you need one or more passwords to encrypt and decrypt content. -If you store your vault passwords in a third-party tool such as a secret manager, you need a script to access them. -Use the passwords with the :ref:`ansible-vault` command-line tool to create and view encrypted variables, create encrypted files, encrypt existing files, or edit, re-key, or decrypt files. -You can then place encrypted content under source control and share it more safely. - -.. warning:: - * Encryption with Ansible Vault ONLY protects 'data at rest'. - Once the content is decrypted ('data in use'), play and plugin authors are responsible for avoiding any secret disclosure, see :ref:`no_log ` for details on hiding output and :ref:`vault_securing_editor` for security considerations on editors you use with Ansible Vault. - -You can use encrypted variables and files in ad hoc commands and playbooks by supplying the passwords you used to encrypt them. -You can modify your ``ansible.cfg`` file to specify the location of a password file or to always prompt for the password. \ No newline at end of file diff --git a/docs/docsite/rst/vault_guide/vault_encrypting_content.rst b/docs/docsite/rst/vault_guide/vault_encrypting_content.rst deleted file mode 100644 index 5c46309c81a..00000000000 --- a/docs/docsite/rst/vault_guide/vault_encrypting_content.rst +++ /dev/null @@ -1,353 +0,0 @@ -.. _vault_encrypting_content: - -Encrypting content with Ansible Vault -===================================== - -Once you have a strategy for managing and storing vault passwords, you can start encrypting content. You can encrypt two types of content with Ansible Vault: variables and files. Encrypted content always includes the ``!vault`` tag, which tells Ansible and YAML that the content needs to be decrypted, and a ``|`` character, which allows multi-line strings. Encrypted content created with ``--vault-id`` also contains the vault ID label. For more details about the encryption process and the format of content encrypted with Ansible Vault, see :ref:`vault_format`. This table shows the main differences between encrypted variables and encrypted files: - -.. table:: - :class: documentation-table - - ====================== ================================= ==================================== - .. Encrypted variables Encrypted files - ====================== ================================= ==================================== - How much is encrypted? Variables within a plaintext file The entire file - - When is it decrypted? On demand, only when needed Whenever loaded or referenced [#f1]_ - - What can be encrypted? Only variables Any structured data file - - ====================== ================================= ==================================== - -.. [#f1] Ansible cannot know if it needs content from an encrypted file unless it decrypts the file, so it decrypts all encrypted files referenced in your playbooks and roles. - -.. _encrypting_variables: -.. _single_encrypted_variable: - -Encrypting individual variables with Ansible Vault --------------------------------------------------- - -You can encrypt single values inside a YAML file using the :ref:`ansible-vault encrypt_string ` command. For one way to keep your vaulted variables safely visible, see :ref:`tip_for_variables_and_vaults`. - -Advantages and disadvantages of encrypting variables -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -With variable-level encryption, your files are still easily legible. You can mix plaintext and encrypted variables, even inline in a play or role. However, password rotation is not as simple as with file-level encryption. You cannot :ref:`rekey ` encrypted variables. Also, variable-level encryption only works on variables. If you want to encrypt tasks or other content, you must encrypt the entire file. - -.. _encrypt_string_for_use_in_yaml: - -Creating encrypted variables -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The :ref:`ansible-vault encrypt_string ` command encrypts and formats any string you type (or copy or generate) into a format that can be included in a playbook, role, or variables file. To create a basic encrypted variable, pass three options to the :ref:`ansible-vault encrypt_string ` command: - - * a source for the vault password (prompt, file, or script, with or without a vault ID) - * the string to encrypt - * the string name (the name of the variable) - -The pattern looks like this: - -.. code-block:: bash - - ansible-vault encrypt_string '' --name '' - -For example, to encrypt the string 'foobar' using the only password stored in 'a_password_file' and name the variable 'the_secret': - -.. code-block:: bash - - ansible-vault encrypt_string --vault-password-file a_password_file 'foobar' --name 'the_secret' - -The command above creates this content: - - .. code-block:: yaml - - the_secret: !vault | - $ANSIBLE_VAULT;1.1;AES256 - 62313365396662343061393464336163383764373764613633653634306231386433626436623361 - 6134333665353966363534333632666535333761666131620a663537646436643839616531643561 - 63396265333966386166373632626539326166353965363262633030333630313338646335303630 - 3438626666666137650a353638643435666633633964366338633066623234616432373231333331 - 6564 - -To encrypt the string 'foooodev', add the vault ID label 'dev' with the 'dev' vault password stored in 'a_password_file', and call the encrypted variable 'the_dev_secret': - -.. code-block:: bash - - ansible-vault encrypt_string --vault-id dev@a_password_file 'foooodev' --name 'the_dev_secret' - -The command above creates this content: - - .. code-block:: yaml - - the_dev_secret: !vault | - $ANSIBLE_VAULT;1.2;AES256;dev - 30613233633461343837653833666333643061636561303338373661313838333565653635353162 - 3263363434623733343538653462613064333634333464660a663633623939393439316636633863 - 61636237636537333938306331383339353265363239643939666639386530626330633337633833 - 6664656334373166630a363736393262666465663432613932613036303963343263623137386239 - 6330 - -To encrypt the string 'letmein' read from stdin, add the vault ID 'dev' using the 'dev' vault password stored in `a_password_file`, and name the variable 'db_password': - -.. code-block:: bash - - echo -n 'letmein' | ansible-vault encrypt_string --vault-id dev@a_password_file --stdin-name 'db_password' - -.. warning:: - - Typing secret content directly at the command line (without a prompt) leaves the secret string in your shell history. Do not do this outside of testing. - -The command above creates this output: - - .. code-block:: console - - Reading plaintext input from stdin. (ctrl-d to end input, twice if your content does not already have a new line) - db_password: !vault | - $ANSIBLE_VAULT;1.2;AES256;dev - 61323931353866666336306139373937316366366138656131323863373866376666353364373761 - 3539633234313836346435323766306164626134376564330a373530313635343535343133316133 - 36643666306434616266376434363239346433643238336464643566386135356334303736353136 - 6565633133366366360a326566323363363936613664616364623437336130623133343530333739 - 3039 - -To be prompted for a string to encrypt, encrypt it with the 'dev' vault password from 'a_password_file', name the variable 'new_user_password' and give it the vault ID label 'dev': - -.. code-block:: bash - - ansible-vault encrypt_string --vault-id dev@a_password_file --stdin-name 'new_user_password' - -The command above triggers this prompt: - -.. code-block:: text - - Reading plaintext input from stdin. (ctrl-d to end input, twice if your content does not already have a new line) - -Type the string to encrypt (for example, 'hunter2'), hit ctrl-d, and wait. - -.. warning:: - - Do not press ``Enter`` after supplying the string to encrypt. That will add a newline to the encrypted value. - -The sequence above creates this output: - - .. code-block:: yaml - - new_user_password: !vault | - $ANSIBLE_VAULT;1.2;AES256;dev - 37636561366636643464376336303466613062633537323632306566653533383833366462366662 - 6565353063303065303831323539656138653863353230620a653638643639333133306331336365 - 62373737623337616130386137373461306535383538373162316263386165376131623631323434 - 3866363862363335620a376466656164383032633338306162326639643635663936623939666238 - 3161 - -You can add the output from any of the examples above to any playbook, variables file, or role for future use. Encrypted variables are larger than plain-text variables, but they protect your sensitive content while leaving the rest of the playbook, variables file, or role in plain text so you can easily read it. - -Viewing encrypted variables -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can view the original value of an encrypted variable using the debug module. You must pass the password that was used to encrypt the variable. For example, if you stored the variable created by the last example above in a file called 'vars.yml', you could view the unencrypted value of that variable like this: - -.. code-block:: console - - ansible localhost -m ansible.builtin.debug -a var="new_user_password" -e "@vars.yml" --vault-id dev@a_password_file - - localhost | SUCCESS => { - "new_user_password": "hunter2" - } - - -Encrypting files with Ansible Vault ------------------------------------ - -Ansible Vault can encrypt any structured data file used by Ansible, including: - - * group variables files from inventory - * host variables files from inventory - * variables files passed to ansible-playbook with ``-e @file.yml`` or ``-e @file.json`` - * variables files loaded by ``include_vars`` or ``vars_files`` - * variables files in roles - * defaults files in roles - * tasks files - * handlers files - * binary files or other arbitrary files - -The full file is encrypted in the vault. - -.. note:: - - Ansible Vault uses an editor to create or modify encrypted files. See :ref:`vault_securing_editor` for some guidance on securing the editor. - - -Advantages and disadvantages of encrypting files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -File-level encryption is easy to use. Password rotation for encrypted files is straightforward with the :ref:`rekey ` command. Encrypting files can hide not only sensitive values, but the names of the variables you use. However, with file-level encryption the contents of files are no longer easy to access and read. This may be a problem with encrypted tasks files. When encrypting a variables file, see :ref:`tip_for_variables_and_vaults` for one way to keep references to these variables in a non-encrypted file. Ansible always decrypts the entire encrypted file when it is when loaded or referenced, because Ansible cannot know if it needs the content unless it decrypts it. - -.. _creating_files: - -Creating encrypted files -^^^^^^^^^^^^^^^^^^^^^^^^ - -To create a new encrypted data file called 'foo.yml' with the 'test' vault password from 'multi_password_file': - -.. code-block:: bash - - ansible-vault create --vault-id test@multi_password_file foo.yml - -The tool launches an editor (whatever editor you have defined with $EDITOR, default editor is vi). Add the content. When you close the editor session, the file is saved as encrypted data. The file header reflects the vault ID used to create it: - -.. code-block:: text - - ``$ANSIBLE_VAULT;1.2;AES256;test`` - -To create a new encrypted data file with the vault ID 'my_new_password' assigned to it and be prompted for the password: - -.. code-block:: bash - - ansible-vault create --vault-id my_new_password@prompt foo.yml - -Again, add content to the file in the editor and save. Be sure to store the new password you created at the prompt, so you can find it when you want to decrypt that file. - -.. _encrypting_files: - -Encrypting existing files -^^^^^^^^^^^^^^^^^^^^^^^^^ - -To encrypt an existing file, use the :ref:`ansible-vault encrypt ` command. This command can operate on multiple files at once. For example: - -.. code-block:: bash - - ansible-vault encrypt foo.yml bar.yml baz.yml - -To encrypt existing files with the 'project' ID and be prompted for the password: - -.. code-block:: bash - - ansible-vault encrypt --vault-id project@prompt foo.yml bar.yml baz.yml - - -.. _viewing_files: - -Viewing encrypted files -^^^^^^^^^^^^^^^^^^^^^^^ - -To view the contents of an encrypted file without editing it, you can use the :ref:`ansible-vault view ` command: - -.. code-block:: bash - - ansible-vault view foo.yml bar.yml baz.yml - - -.. _editing_encrypted_files: - -Editing encrypted files -^^^^^^^^^^^^^^^^^^^^^^^ - -To edit an encrypted file in place, use the :ref:`ansible-vault edit ` command. This command decrypts the file to a temporary file, allows you to edit the content, then saves and re-encrypts the content and removes the temporary file when you close the editor. For example: - -.. code-block:: bash - - ansible-vault edit foo.yml - -To edit a file encrypted with the ``vault2`` password file and assigned the vault ID ``pass2``: - -.. code-block:: bash - - ansible-vault edit --vault-id pass2@vault2 foo.yml - - -.. _rekeying_files: - -Changing the password and/or vault ID on encrypted files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To change the password on an encrypted file or files, use the :ref:`rekey ` command: - -.. code-block:: bash - - ansible-vault rekey foo.yml bar.yml baz.yml - -This command can rekey multiple data files at once and will ask for the original password and also the new password. To set a different ID for the rekeyed files, pass the new ID to ``--new-vault-id``. For example, to rekey a list of files encrypted with the 'preprod1' vault ID from the 'ppold' file to the 'preprod2' vault ID and be prompted for the new password: - -.. code-block:: bash - - ansible-vault rekey --vault-id preprod1@ppold --new-vault-id preprod2@prompt foo.yml bar.yml baz.yml - - -.. _decrypting_files: - -Decrypting encrypted files -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you have an encrypted file that you no longer want to keep encrypted, you can permanently decrypt it by running the :ref:`ansible-vault decrypt ` command. This command will save the file unencrypted to the disk, so be sure you do not want to :ref:`edit ` it instead. - -.. code-block:: bash - - ansible-vault decrypt foo.yml bar.yml baz.yml - - -.. _vault_securing_editor: - -Steps to secure your editor -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Ansible Vault relies on your configured editor, which can be a source of disclosures. Most editors have ways to prevent loss of data, but these normally rely on extra plain text files that can have a clear text copy of your secrets. Consult your editor documentation to configure the editor to avoid disclosing secure data. The following sections provide some guidance on common editors but should not be taken as a complete guide to securing your editor. - - -vim -... - -You can set the following ``vim`` options in command mode to avoid cases of disclosure. There may be more settings you need to modify to ensure security, especially when using plugins, so consult the ``vim`` documentation. - - -1. Disable swapfiles that act like an autosave in case of crash or interruption. - -.. code-block:: text - - set noswapfile - -2. Disable creation of backup files. - -.. code-block:: text - - set nobackup - set nowritebackup - -3. Disable the viminfo file from copying data from your current session. - -.. code-block:: text - - set viminfo= - -4. Disable copying to the system clipboard. - -.. code-block:: text - - set clipboard= - - -You can optionally add these settings in ``.vimrc`` for all files, or just specific paths or extensions. See the ``vim`` manual for details. - - -Emacs -...... - -You can set the following Emacs options to avoid cases of disclosure. There may be more settings you need to modify to ensure security, especially when using plugins, so consult the Emacs documentation. - -1. Do not copy data to the system clipboard. - -.. code-block:: text - - (setq x-select-enable-clipboard nil) - -2. Disable creation of backup files. - -.. code-block:: text - - (setq make-backup-files nil) - -3. Disable autosave files. - -.. code-block:: text - - (setq auto-save-default nil) diff --git a/docs/docsite/rst/vault_guide/vault_managing_passwords.rst b/docs/docsite/rst/vault_guide/vault_managing_passwords.rst deleted file mode 100644 index 3d286c61958..00000000000 --- a/docs/docsite/rst/vault_guide/vault_managing_passwords.rst +++ /dev/null @@ -1,104 +0,0 @@ -.. _vault_managing_passwords: - -Managing vault passwords -======================== - -Managing your encrypted content is easier if you develop a strategy for managing your vault passwords. A vault password can be any string you choose. There is no special command to create a vault password. However, you need to keep track of your vault passwords. Each time you encrypt a variable or file with Ansible Vault, you must provide a password. When you use an encrypted variable or file in a command or playbook, you must provide the same password that was used to encrypt it. To develop a strategy for managing vault passwords, start with two questions: - - * Do you want to encrypt all your content with the same password, or use different passwords for different needs? - * Where do you want to store your password or passwords? - -Choosing between a single password and multiple passwords ---------------------------------------------------------- - -If you have a small team or few sensitive values, you can use a single password for everything you encrypt with Ansible Vault. Store your vault password securely in a file or a secret manager as described below. - -If you have a larger team or many sensitive values, you can use multiple passwords. For example, you can use different passwords for different users or different levels of access. Depending on your needs, you might want a different password for each encrypted file, for each directory, or for each environment. For example, you might have a playbook that includes two vars files, one for the dev environment and one for the production environment, encrypted with two different passwords. When you run the playbook, select the correct vault password for the environment you are targeting, using a vault ID. - -.. _vault_ids: - -Managing multiple passwords with vault IDs ------------------------------------------- - -If you use multiple vault passwords, you can differentiate one password from another with vault IDs. You use the vault ID in three ways: - - * Pass it with :option:`--vault-id ` to the :ref:`ansible-vault` command when you create encrypted content - * Include it wherever you store the password for that vault ID (see :ref:`storing_vault_passwords`) - * Pass it with :option:`--vault-id ` to the :ref:`ansible-playbook` command when you run a playbook that uses content you encrypted with that vault ID - -When you pass a vault ID as an option to the :ref:`ansible-vault` command, you add a label (a hint or nickname) to the encrypted content. This label documents which password you used to encrypt it. The encrypted variable or file includes the vault ID label in plain text in the header. The vault ID is the last element before the encrypted content. For example: - - .. code-block:: yaml - - my_encrypted_var: !vault | - $ANSIBLE_VAULT;1.2;AES256;dev - 30613233633461343837653833666333643061636561303338373661313838333565653635353162 - 3263363434623733343538653462613064333634333464660a663633623939393439316636633863 - 61636237636537333938306331383339353265363239643939666639386530626330633337633833 - 6664656334373166630a363736393262666465663432613932613036303963343263623137386239 - 6330 - -In addition to the label, you must provide a source for the related password. The source can be a prompt, a file, or a script, depending on how you are storing your vault passwords. The pattern looks like this: - -.. code-block:: bash - - --vault-id label@source - -If your playbook uses multiple encrypted variables or files that you encrypted with different passwords, you must pass the vault IDs when you run that playbook. You can use :option:`--vault-id ` by itself, with :option:`--vault-password-file `, or with :option:`--ask-vault-pass `. The pattern is the same as when you create encrypted content: include the label and the source for the matching password. - -See below for examples of encrypting content with vault IDs and using content encrypted with vault IDs. The :option:`--vault-id ` option works with any Ansible command that interacts with vaults, including :ref:`ansible-vault`, :ref:`ansible-playbook`, and so on. - -Limitations of vault IDs -^^^^^^^^^^^^^^^^^^^^^^^^ - -Ansible does not enforce using the same password every time you use a particular vault ID label. You can encrypt different variables or files with the same vault ID label but different passwords. This usually happens when you type the password at a prompt and make a mistake. It is possible to use different passwords with the same vault ID label on purpose. For example, you could use each label as a reference to a class of passwords, rather than a single password. In this scenario, you must always know which specific password or file to use in context. However, you are more likely to encrypt two files with the same vault ID label and different passwords by mistake. If you encrypt two files with the same label but different passwords by accident, you can :ref:`rekey ` one file to fix the issue. - -Enforcing vault ID matching -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default the vault ID label is only a hint to remind you which password you used to encrypt a variable or file. Ansible does not check that the vault ID in the header of the encrypted content matches the vault ID you provide when you use the content. Ansible decrypts all files and variables called by your command or playbook that are encrypted with the password you provide. To check the encrypted content and decrypt it only when the vault ID it contains matches the one you provide with ``--vault-id``, set the config option :ref:`DEFAULT_VAULT_ID_MATCH`. When you set :ref:`DEFAULT_VAULT_ID_MATCH`, each password is only used to decrypt data that was encrypted with the same label. This is efficient, predictable, and can reduce errors when different values are encrypted with different passwords. - -.. note:: - Even with the :ref:`DEFAULT_VAULT_ID_MATCH` setting enabled, Ansible does not enforce using the same password every time you use a particular vault ID label. - -.. _storing_vault_passwords: - -Storing and accessing vault passwords -------------------------------------- - -You can memorize your vault password, or manually copy vault passwords from any source and paste them at a command-line prompt, but most users store them securely and access them as needed from within Ansible. You have two options for storing vault passwords that work from within Ansible: in files, or in a third-party tool such as the system keyring or a secret manager. If you store your passwords in a third-party tool, you need a vault password client script to retrieve them from within Ansible. - -Storing passwords in files -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To store a vault password in a file, enter the password as a string on a single line in the file. Make sure the permissions on the file are appropriate. Do not add password files to source control. - -.. _vault_password_client_scripts: - -Storing passwords in third-party tools with vault password client scripts -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can store your vault passwords on the system keyring, in a database, or in a secret manager and retrieve them from within Ansible using a vault password client script. Enter the password as a string on a single line. If your password has a vault ID, store it in a way that works with your password storage tool. - -To create a vault password client script: - - * Create a file with a name ending in either ``-client`` or ``-client.EXTENSION`` - * Make the file executable - * Within the script itself: - * Print the passwords to standard output - * Accept a ``--vault-id`` option - * If the script prompts for data (for example, a database password), display the prompts to the TTY. - -When you run a playbook that uses vault passwords stored in a third-party tool, specify the script as the source within the ``--vault-id`` flag. For example: - -.. code-block:: bash - - ansible-playbook --vault-id dev@contrib/vault/vault-keyring-client.py - -Ansible executes the client script with a ``--vault-id`` option so the script knows which vault ID label you specified. For example a script loading passwords from a secret manager can use the vault ID label to pick either the 'dev' or 'prod' password. The example command above results in the following execution of the client script: - -.. code-block:: bash - - contrib/vault/vault-keyring-client.py --vault-id dev - -For an example of a client script that loads passwords from the system keyring, see the `vault-keyring-client script `_. \ No newline at end of file diff --git a/docs/docsite/rst/vault_guide/vault_using_encrypted_content.rst b/docs/docsite/rst/vault_guide/vault_using_encrypted_content.rst deleted file mode 100644 index 476e4a9d22a..00000000000 --- a/docs/docsite/rst/vault_guide/vault_using_encrypted_content.rst +++ /dev/null @@ -1,184 +0,0 @@ -.. _vault_using_encrypted_content: -.. _playbooks_vault: -.. _providing_vault_passwords: - -Using encrypted variables and files -=================================== - -When you run a task or playbook that uses encrypted variables or files, you must provide the passwords to decrypt the variables or files. You can do this at the command line or by setting a default password source in a config option or an environment variable. - -Passing a single password -------------------------- - -If all the encrypted variables and files your task or playbook needs use a single password, you can use the :option:`--ask-vault-pass ` or :option:`--vault-password-file ` cli options. - -To prompt for the password: - -.. code-block:: bash - - ansible-playbook --ask-vault-pass site.yml - -To retrieve the password from the :file:`/path/to/my/vault-password-file` file: - -.. code-block:: bash - - ansible-playbook --vault-password-file /path/to/my/vault-password-file site.yml - -To get the password from the vault password client script :file:`my-vault-password-client.py`: - -.. code-block:: bash - - ansible-playbook --vault-password-file my-vault-password-client.py - - -.. _specifying_vault_ids: - -Passing vault IDs ------------------ - -You can also use the :option:`--vault-id ` option to pass a single password with its vault label. This approach is clearer when multiple vaults are used within a single inventory. - -To prompt for the password for the 'dev' vault ID: - -.. code-block:: bash - - ansible-playbook --vault-id dev@prompt site.yml - -To retrieve the password for the 'dev' vault ID from the :file:`dev-password` file: - -.. code-block:: bash - - ansible-playbook --vault-id dev@dev-password site.yml - -To get the password for the 'dev' vault ID from the vault password client script :file:`my-vault-password-client.py`: - -.. code-block:: bash - - ansible-playbook --vault-id dev@my-vault-password-client.py - -Passing multiple vault passwords --------------------------------- - -If your task or playbook requires multiple encrypted variables or files that you encrypted with different vault IDs, you must use the :option:`--vault-id ` option, passing multiple ``--vault-id`` options to specify the vault IDs ('dev', 'prod', 'cloud', 'db') and sources for the passwords (prompt, file, script). . For example, to use a 'dev' password read from a file and to be prompted for the 'prod' password: - -.. code-block:: bash - - ansible-playbook --vault-id dev@dev-password --vault-id prod@prompt site.yml - -By default the vault ID labels (dev, prod and so on) are only hints. Ansible attempts to decrypt vault content with each password. The password with the same label as the encrypted data will be tried first, after that each vault secret will be tried in the order they were provided on the command line. - -Where the encrypted data has no label, or the label does not match any of the provided labels, the passwords will be tried in the order they are specified. In the example above, the 'dev' password will be tried first, then the 'prod' password for cases where Ansible doesn't know which vault ID is used to encrypt something. - -Using ``--vault-id`` without a vault ID ---------------------------------------- - -The :option:`--vault-id ` option can also be used without specifying a vault-id. This behavior is equivalent to :option:`--ask-vault-pass ` or :option:`--vault-password-file ` so is rarely used. - -For example, to use a password file :file:`dev-password`: - -.. code-block:: bash - - ansible-playbook --vault-id dev-password site.yml - -To prompt for the password: - -.. code-block:: bash - - ansible-playbook --vault-id @prompt site.yml - -To get the password from an executable script :file:`my-vault-password-client.py`: - -.. code-block:: bash - - ansible-playbook --vault-id my-vault-password-client.py - -Configuring defaults for using encrypted content -================================================ - -Setting a default vault ID --------------------------- - -If you use one vault ID more frequently than any other, you can set the config option :ref:`DEFAULT_VAULT_IDENTITY_LIST` to specify a default vault ID and password source. Ansible will use the default vault ID and source any time you do not specify :option:`--vault-id `. You can set multiple values for this option. Setting multiple values is equivalent to passing multiple :option:`--vault-id ` cli options. - -Setting a default password source ---------------------------------- - -If you don't want to provide the password file on the command line or if you use one vault password file more frequently than any other, you can set the :ref:`DEFAULT_VAULT_PASSWORD_FILE` config option or the :envvar:`ANSIBLE_VAULT_PASSWORD_FILE` environment variable to specify a default file to use. For example, if you set ``ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt``, Ansible will automatically search for the password in that file. This is useful if, for example, you use Ansible from a continuous integration system such as Jenkins. - -The file that you reference can be either a file containing the password (in plain text), or it can be a script (with executable permissions set) that returns the password. - -When are encrypted files made visible? -====================================== - -In general, content you encrypt with Ansible Vault remains encrypted after execution. However, there is one exception. If you pass an encrypted file as the ``src`` argument to the :ref:`copy `, :ref:`template `, :ref:`unarchive `, :ref:`script ` or :ref:`assemble ` module, the file will not be encrypted on the target host (assuming you supply the correct vault password when you run the play). This behavior is intended and useful. You can encrypt a configuration file or template to avoid sharing the details of your configuration, but when you copy that configuration to servers in your environment, you want it to be decrypted so local users and processes can access it. - -.. _vault_format: - -Format of files encrypted with Ansible Vault -============================================ - -Ansible Vault creates UTF-8 encoded txt files. The file format includes a newline terminated header. For example: - - .. code-block:: text - - $ANSIBLE_VAULT;1.1;AES256 - -or - - .. code-block:: text - - $ANSIBLE_VAULT;1.2;AES256;vault-id-label - -The header contains up to four elements, separated by semi-colons (``;``). - - 1. The format ID (``$ANSIBLE_VAULT``). Currently ``$ANSIBLE_VAULT`` is the only valid format ID. The format ID identifies content that is encrypted with Ansible Vault (via vault.is_encrypted_file()). - - 2. The vault format version (``1.X``). All supported versions of Ansible will currently default to '1.1' or '1.2' if a labeled vault ID is supplied. The '1.0' format is supported for reading only (and will be converted automatically to the '1.1' format on write). The format version is currently used as an exact string compare only (version numbers are not currently 'compared'). - - 3. The cipher algorithm used to encrypt the data (``AES256``). Currently ``AES256`` is the only supported cipher algorithm. Vault format 1.0 used 'AES', but current code always uses 'AES256'. - - 4. The vault ID label used to encrypt the data (optional, ``vault-id-label``) For example, if you encrypt a file with ``--vault-id dev@prompt``, the vault-id-label is ``dev``. - -Note: In the future, the header could change. Fields after the format ID and format version depend on the format version, and future vault format versions may add more cipher algorithm options and/or additional fields. - -The rest of the content of the file is the 'vaulttext'. The vaulttext is a text armored version of the -encrypted ciphertext. Each line is 80 characters wide, except for the last line which may be shorter. - -Ansible Vault payload format 1.1 - 1.2 --------------------------------------- - -The vaulttext is a concatenation of the ciphertext and a SHA256 digest with the result 'hexlifyied'. - -'hexlify' refers to the ``hexlify()`` method of the Python Standard Library's `binascii `_ module. - -hexlify()'ed result of: - -- hexlify()'ed string of the salt, followed by a newline (``0x0a``) -- hexlify()'ed string of the crypted HMAC, followed by a newline. The HMAC is: - - - a `RFC2104 `_ style HMAC - - - inputs are: - - - The AES256 encrypted ciphertext - - A PBKDF2 key. This key, the cipher key, and the cipher IV are generated from: - - - the salt, in bytes - - 10000 iterations - - SHA256() algorithm - - the first 32 bytes are the cipher key - - the second 32 bytes are the HMAC key - - remaining 16 bytes are the cipher IV - -- hexlify()'ed string of the ciphertext. The ciphertext is: - - - AES256 encrypted data. The data is encrypted using: - - - AES-CTR stream cipher - - cipher key - - IV - - a 128 bit counter block seeded from an integer IV - - the plaintext - - - the original plaintext - - padding up to the AES256 blocksize. (The data used for padding is based on `RFC5652 `_) diff --git a/docs/docsite/sphinx_conf/2.10_conf.py b/docs/docsite/sphinx_conf/2.10_conf.py deleted file mode 100644 index 7e3327e711a..00000000000 --- a/docs/docsite/sphinx_conf/2.10_conf.py +++ /dev/null @@ -1,306 +0,0 @@ -# -*- coding: utf-8 -*- -# -# documentation build configuration file, created by -# sphinx-quickstart on Sat Sep 27 13:23:22 2008-2009. -# -# This file is execfile()d with the current directory set to its -# containing dir. -# -# The contents of this file are pickled, so don't put values in the namespace -# that aren't pickleable (module imports are okay, they're removed -# automatically). -# -# All configuration values have a default value; values that are commented out -# serve to show the default value. - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import sys -import os - -# If your extensions are in another directory, add it here. If the directory -# is relative to the documentation root, use os.path.abspath to make it -# absolute, like shown here. -# sys.path.append(os.path.abspath('some/directory')) -# -sys.path.insert(0, os.path.join('ansible', 'lib')) - -# We want sphinx to document the ansible modules contained in this repository, -# not those that may happen to be installed in the version -# of Python used to run sphinx. When sphinx loads in order to document, -# the repository version needs to be the one that is loaded: -sys.path.insert(0, os.path.abspath(os.path.join('..', '..', '..', 'lib'))) - -VERSION = '2.10' -AUTHOR = 'Ansible, Inc' - - -# General configuration -# --------------------- - -# Add any Sphinx extension module names here, as strings. -# They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -# TEST: 'sphinxcontrib.fulltoc' -extensions = [ - 'sphinx.ext.autodoc', - 'sphinx.ext.intersphinx', - 'notfound.extension', - 'sphinx_antsibull_ext', # provides CSS for the plugin/module docs generated by antsibull -] - -# Later on, add 'sphinx.ext.viewcode' to the list if you want to have -# colorized code generated too for references. - - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['../.templates'] - -# The suffix of source filenames. -source_suffix = '.rst' - -# The master toctree document. -root_doc = master_doc = 'index' # Sphinx 4+ / 3- - -# General substitutions. -project = 'Ansible' -copyright = "Ansible project contributors" - -# The default replacements for |version| and |release|, also used in various -# other places throughout the built documents. -# -# The short X.Y version. -version = VERSION -# The full version, including alpha/beta/rc tags. -release = VERSION - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -# today = '' -# Else, today_fmt is used as the format for a strftime call. -today_fmt = '%B %d, %Y' - -# List of documents that shouldn't be included in the build. -# unused_docs = [] - -# List of directories, relative to source directories, that shouldn't be -# searched for source files. -# exclude_dirs = [] - -# A list of glob-style patterns that should be excluded when looking -# for source files. -exclude_patterns = [ - '2.10_index.rst', - 'ansible_index.rst', - 'core_index.rst', - 'porting_guides/core_porting_guides', -] - -# The reST default role (used for this markup: `text`) to use for all -# documents. -# default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -# add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -# add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -# show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'ansible' - -highlight_language = 'YAML+Jinja' - -# Substitutions, variables, entities, & shortcuts for text which do not need to link to anything. -# For titles which should be a link, use the intersphinx anchors set at the index, chapter, and section levels, such as qi_start_: -# |br| is useful for formatting fields inside of tables -# |_| is a nonbreaking space; similarly useful inside of tables -rst_epilog = """ -.. |br| raw:: html - -
    -.. |_| unicode:: 0xA0 - :trim: -""" - - -# Options for HTML output -# ----------------------- - -html_theme_path = [] -html_theme = 'sphinx_ansible_theme' -html_show_sphinx = False - -html_theme_options = { - 'canonical_url': "https://docs.ansible.com/ansible/latest/", - 'hubspot_id': '330046', - 'satellite_tracking': True, - 'show_extranav': True, - 'swift_id': 'yABGvz2N8PwcwBxyfzUc', - 'tag_manager_id': 'GTM-PSB293', - 'vcs_pageview_mode': 'edit' -} - -html_context = { - 'display_github': 'True', - 'show_sphinx': False, - 'is_eol': False, - 'github_user': 'ansible', - 'github_repo': 'ansible', - 'github_version': 'devel/docs/docsite/rst/', - 'github_module_version': 'devel/lib/ansible/modules/', - 'github_root_dir': 'devel/lib/ansible', - 'github_cli_version': 'devel/lib/ansible/cli/', - 'current_version': version, - 'latest_version': '2.10', - # list specifically out of order to make latest work - 'available_versions': ('latest', '2.9', '2.9_ja', '2.8', 'devel'), -} - -# Add extra CSS styles to the resulting HTML pages -html_css_files = [] - -# The style sheet to use for HTML and HTML Help pages. A file of that name -# must exist either in Sphinx' static/ path, or in one of the custom paths -# given in html_static_path. -# html_style = 'solar.css' - -# The name for this set of Sphinx documents. If None, it defaults to -# " v documentation". -html_title = 'Ansible Documentation' - -# A shorter title for the navigation bar. Default is the same as html_title. -html_short_title = 'Documentation' - -# The name of an image file (within the static path) to place at the top of -# the sidebar. -# html_logo = - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -# html_favicon = 'favicon.ico' - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['../_static'] - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -# html_use_smartypants = True - -# Custom sidebar templates, maps document names to template names. -# html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -# html_additional_pages = {} - -# If false, no module index is generated. -# html_use_modindex = True - -# If false, no index is generated. -# html_use_index = True - -# If true, the index is split into individual pages for each letter. -# html_split_index = False - -# If true, the reST sources are included in the HTML build as _sources/. -html_copy_source = False - -# If true, an OpenSearch description file will be output, and all pages will -# contain a tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -# html_use_opensearch = 'https://docs.ansible.com/ansible/latest' - -# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml"). -# html_file_suffix = '' - -# Output file base name for HTML help builder. -htmlhelp_basename = 'Poseidodoc' - -# Configuration for sphinx-notfound-pages -# with no 'notfound_template' and no 'notfound_context' set, -# the extension builds 404.rst into a location-agnostic 404 page -# -# default is `en` - using this for the sub-site: -notfound_default_language = "ansible" -# default is `latest`: -# setting explicitly - docsite serves up /ansible/latest/404.html -# so keep this set to `latest` even on the `devel` branch -# then no maintenance is needed when we branch a new stable_x.x -notfound_default_version = "latest" -# makes default setting explicit: -notfound_no_urls_prefix = False - -# Options for LaTeX output -# ------------------------ - -# The paper size ('letter' or 'a4'). -# latex_paper_size = 'letter' - -# The font size ('10pt', '11pt' or '12pt'). -# latex_font_size = '10pt' - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, document class -# [howto/manual]). -latex_documents = [ - ('index', 'ansible.tex', 'Ansible 2.2 Documentation', AUTHOR, 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -# latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -# latex_use_parts = False - -# Additional stuff for the LaTeX preamble. -# latex_preamble = '' - -# Documents to append as an appendix to all manuals. -# latex_appendices = [] - -# If false, no module index is generated. -# latex_use_modindex = True - -autoclass_content = 'both' - -# Note: Our strategy for intersphinx mappings is to have the upstream build location as the -# canonical source and then cached copies of the mapping stored locally in case someone is building -# when disconnected from the internet. We then have a script to update the cached copies. -# -# Because of that, each entry in this mapping should have this format: -# name: ('http://UPSTREAM_URL', (None, 'path/to/local/cache.inv')) -# -# The update script depends on this format so deviating from this (for instance, adding a third -# location for the mappning to live) will confuse it. -intersphinx_mapping = {'python': ('https://docs.python.org/2/', (None, '../python2.inv')), - 'python3': ('https://docs.python.org/3/', (None, '../python3.inv')), - 'jinja2': ('http://jinja.palletsprojects.com/', (None, '../jinja2.inv')), - 'ansible_2_10': ('https://docs.ansible.com/ansible/2.10/', (None, '../ansible_2_10.inv')), - 'ansible_2_9': ('https://docs.ansible.com/ansible/2.9/', (None, '../ansible_2_9.inv')), - 'ansible_2_8': ('https://docs.ansible.com/ansible/2.8/', (None, '../ansible_2_8.inv')), - 'ansible_2_7': ('https://docs.ansible.com/ansible/2.7/', (None, '../ansible_2_7.inv')), - 'ansible_2_6': ('https://docs.ansible.com/ansible/2.6/', (None, '../ansible_2_6.inv')), - 'ansible_2_5': ('https://docs.ansible.com/ansible/2.5/', (None, '../ansible_2_5.inv')), - } - -# linckchecker settings -linkcheck_ignore = [ -] -linkcheck_workers = 25 -# linkcheck_anchors = False diff --git a/docs/docsite/sphinx_conf/all_conf.py b/docs/docsite/sphinx_conf/all_conf.py deleted file mode 100644 index 58db693aadb..00000000000 --- a/docs/docsite/sphinx_conf/all_conf.py +++ /dev/null @@ -1,299 +0,0 @@ -# -*- coding: utf-8 -*- -# -# documentation build configuration file, created by -# sphinx-quickstart on Sat Sep 27 13:23:22 2008-2009. -# -# This file is execfile()d with the current directory set to its -# containing dir. -# -# The contents of this file are pickled, so don't put values in the namespace -# that aren't pickleable (module imports are okay, they're removed -# automatically). -# -# All configuration values have a default value; values that are commented out -# serve to show the default value. - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import sys -import os - -# If your extensions are in another directory, add it here. If the directory -# is relative to the documentation root, use os.path.abspath to make it -# absolute, like shown here. -# sys.path.append(os.path.abspath('some/directory')) -# -sys.path.insert(0, os.path.join('ansible', 'lib')) - -# We want sphinx to document the ansible modules contained in this repository, -# not those that may happen to be installed in the version -# of Python used to run sphinx. When sphinx loads in order to document, -# the repository version needs to be the one that is loaded: -sys.path.insert(0, os.path.abspath(os.path.join('..', '..', '..', 'lib'))) - -VERSION = 'devel' -AUTHOR = 'Ansible, Inc' - - -# General configuration -# --------------------- - -# Add any Sphinx extension module names here, as strings. -# They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -# TEST: 'sphinxcontrib.fulltoc' -extensions = [ - 'sphinx.ext.autodoc', - 'sphinx.ext.intersphinx', - 'notfound.extension', - 'sphinx_antsibull_ext', # provides CSS for the plugin/module docs generated by antsibull -] - -# Later on, add 'sphinx.ext.viewcode' to the list if you want to have -# colorized code generated too for references. - - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['../.templates'] - -# The suffix of source filenames. -source_suffix = '.rst' - -# The master toctree document. -root_doc = master_doc = 'index' # Sphinx 4+ / 3- - -# General substitutions. -project = 'Ansible' -copyright = "Ansible project contributors" - -# The default replacements for |version| and |release|, also used in various -# other places throughout the built documents. -# -# The short X.Y version. -version = VERSION -# The full version, including alpha/beta/rc tags. -release = VERSION - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -# today = '' -# Else, today_fmt is used as the format for a strftime call. -today_fmt = '%B %d, %Y' - -# List of documents that shouldn't be included in the build. -# unused_docs = [] - -# List of directories, relative to source directories, that shouldn't be -# searched for source files. -# exclude_dirs = [] - -# A list of glob-style patterns that should be excluded when looking -# for source files. -exclude_patterns = [ -] - -# The reST default role (used for this markup: `text`) to use for all -# documents. -# default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -# add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -# add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -# show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'ansible' - -highlight_language = 'YAML+Jinja' - -# Substitutions, variables, entities, & shortcuts for text which do not need to link to anything. -# For titles which should be a link, use the intersphinx anchors set at the index, chapter, and section levels, such as qi_start_: -# |br| is useful for formatting fields inside of tables -# |_| is a nonbreaking space; similarly useful inside of tables -rst_epilog = """ -.. |br| raw:: html - -
    -.. |_| unicode:: 0xA0 - :trim: -""" - - -# Options for HTML output -# ----------------------- - -html_theme_path = [] -html_theme = 'sphinx_ansible_theme' -html_show_sphinx = False - -html_theme_options = { - 'canonical_url': "https://docs.ansible.com/ansible/latest/", - 'hubspot_id': '330046', - 'satellite_tracking': True, - 'show_extranav': True, - 'swift_id': 'yABGvz2N8PwcwBxyfzUc', - 'tag_manager_id': 'GTM-PSB293', - 'vcs_pageview_mode': 'edit' -} - -html_context = { - 'display_github': 'True', - 'show_sphinx': False, - 'is_eol': False, - 'github_user': 'ansible', - 'github_repo': 'ansible', - 'github_version': 'devel/docs/docsite/rst/', - 'github_module_version': 'devel/lib/ansible/modules/', - 'github_root_dir': 'devel/lib/ansible', - 'github_cli_version': 'devel/lib/ansible/cli/', - 'current_version': version, - 'latest_version': 'devel', - # list specifically out of order to make latest work - 'available_versions': ('devel',), -} - -# Add extra CSS styles to the resulting HTML pages -html_css_files = [] - -# The style sheet to use for HTML and HTML Help pages. A file of that name -# must exist either in Sphinx' static/ path, or in one of the custom paths -# given in html_static_path. -# html_style = 'solar.css' - -# The name for this set of Sphinx documents. If None, it defaults to -# " v documentation". -html_title = 'Ansible Core Documentation' - -# A shorter title for the navigation bar. Default is the same as html_title. -html_short_title = 'Documentation' - -# The name of an image file (within the static path) to place at the top of -# the sidebar. -# html_logo = - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -# html_favicon = 'favicon.ico' - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['../_static'] - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -# html_use_smartypants = True - -# Custom sidebar templates, maps document names to template names. -# html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -# html_additional_pages = {} - -# If false, no module index is generated. -# html_use_modindex = True - -# If false, no index is generated. -# html_use_index = True - -# If true, the index is split into individual pages for each letter. -# html_split_index = False - -# If true, the reST sources are included in the HTML build as _sources/. -html_copy_source = False - -# If true, an OpenSearch description file will be output, and all pages will -# contain a tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -# html_use_opensearch = 'https://docs.ansible.com/ansible/latest' - -# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml"). -# html_file_suffix = '' - -# Output file base name for HTML help builder. -htmlhelp_basename = 'Poseidodoc' - -# Configuration for sphinx-notfound-pages -# with no 'notfound_template' and no 'notfound_context' set, -# the extension builds 404.rst into a location-agnostic 404 page -# -# default is `en` - using this for the sub-site: -notfound_default_language = "ansible" -# default is `latest`: -# setting explicitly - docsite serves up /ansible/latest/404.html -# so keep this set to `latest` even on the `devel` branch -# then no maintenance is needed when we branch a new stable_x.x -notfound_default_version = "latest" -# makes default setting explicit: -notfound_no_urls_prefix = False - -# Options for LaTeX output -# ------------------------ - -# The paper size ('letter' or 'a4'). -# latex_paper_size = 'letter' - -# The font size ('10pt', '11pt' or '12pt'). -# latex_font_size = '10pt' - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, document class -# [howto/manual]). -latex_documents = [ - ('index', 'ansible.tex', 'Ansible 2.2 Documentation', AUTHOR, 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -# latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -# latex_use_parts = False - -# Additional stuff for the LaTeX preamble. -# latex_preamble = '' - -# Documents to append as an appendix to all manuals. -# latex_appendices = [] - -# If false, no module index is generated. -# latex_use_modindex = True - -autoclass_content = 'both' - -# Note: Our strategy for intersphinx mappings is to have the upstream build location as the -# canonical source and then cached copies of the mapping stored locally in case someone is building -# when disconnected from the internet. We then have a script to update the cached copies. -# -# Because of that, each entry in this mapping should have this format: -# name: ('http://UPSTREAM_URL', (None, 'path/to/local/cache.inv')) -# -# The update script depends on this format so deviating from this (for instance, adding a third -# location for the mapping to live) will confuse it. -intersphinx_mapping = {'python': ('https://docs.python.org/2/', (None, '../python2.inv')), - 'python3': ('https://docs.python.org/3/', (None, '../python3.inv')), - 'jinja2': ('http://jinja.palletsprojects.com/', (None, '../jinja2.inv')), - 'ansible_7': ('https://docs.ansible.com/ansible/7/', (None, '../ansible_7.inv')), - 'ansible_6': ('https://docs.ansible.com/ansible/6/', (None, '../ansible_6.inv')), - 'ansible_2_9': ('https://docs.ansible.com/ansible/2.9/', (None, '../ansible_2_9.inv')), - } - -# linckchecker settings -linkcheck_ignore = [ -] -linkcheck_workers = 25 -# linkcheck_anchors = False diff --git a/docs/docsite/sphinx_conf/ansible_conf.py b/docs/docsite/sphinx_conf/ansible_conf.py deleted file mode 100644 index 6f71660af59..00000000000 --- a/docs/docsite/sphinx_conf/ansible_conf.py +++ /dev/null @@ -1,309 +0,0 @@ -# -*- coding: utf-8 -*- -# -# documentation build configuration file, created by -# sphinx-quickstart on Sat Sep 27 13:23:22 2008-2009. -# -# This file is execfile()d with the current directory set to its -# containing dir. -# -# The contents of this file are pickled, so don't put values in the namespace -# that aren't pickleable (module imports are okay, they're removed -# automatically). -# -# All configuration values have a default value; values that are commented out -# serve to show the default value. - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import sys -import os - -# If your extensions are in another directory, add it here. If the directory -# is relative to the documentation root, use os.path.abspath to make it -# absolute, like shown here. -# sys.path.append(os.path.abspath('some/directory')) -# -sys.path.insert(0, os.path.join('ansible', 'lib')) - -# We want sphinx to document the ansible modules contained in this repository, -# not those that may happen to be installed in the version -# of Python used to run sphinx. When sphinx loads in order to document, -# the repository version needs to be the one that is loaded: -sys.path.insert(0, os.path.abspath(os.path.join('..', '..', '..', 'lib'))) - -VERSION = 'devel' -AUTHOR = 'Ansible, Inc' - - -# General configuration -# --------------------- - -# Add any Sphinx extension module names here, as strings. -# They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -# TEST: 'sphinxcontrib.fulltoc' -extensions = [ - 'sphinx.ext.autodoc', - 'sphinx.ext.intersphinx', - 'notfound.extension', - 'sphinx_antsibull_ext', # provides CSS for the plugin/module docs generated by antsibull -] - -# Later on, add 'sphinx.ext.viewcode' to the list if you want to have -# colorized code generated too for references. - - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['../.templates'] - -# The suffix of source filenames. -source_suffix = '.rst' - -# The master toctree document. -root_doc = master_doc = 'index' # Sphinx 4+ / 3- - -# General substitutions. -project = 'Ansible' -copyright = "Ansible project contributors" - -# The default replacements for |version| and |release|, also used in various -# other places throughout the built documents. -# -# The short X.Y version. -version = VERSION -# The full version, including alpha/beta/rc tags. -release = VERSION - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -# today = '' -# Else, today_fmt is used as the format for a strftime call. -today_fmt = '%B %d, %Y' - -# List of documents that shouldn't be included in the build. -# unused_docs = [] - -# List of directories, relative to source directories, that shouldn't be -# searched for source files. -# exclude_dirs = [] - -# A list of glob-style patterns that should be excluded when looking -# for source files. -exclude_patterns = [ - '2.10_index.rst', - 'ansible_index.rst', - 'core_index.rst', - 'dev_guide/ansible_index.rst', - 'dev_guide/core_index.rst', - 'dev_guide/core_branches_and_tags.rst', - 'porting_guides/core_porting_guides.rst', - 'porting_guides/porting_guide_base_2.10.rst', - 'porting_guides/porting_guide_core_*', - 'roadmap/index.rst', -] - -# The reST default role (used for this markup: `text`) to use for all -# documents. -# default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -# add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -# add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -# show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'ansible' - -highlight_language = 'YAML+Jinja' - -# Substitutions, variables, entities, & shortcuts for text which do not need to link to anything. -# For titles which should be a link, use the intersphinx anchors set at the index, chapter, and section levels, such as qi_start_: -# |br| is useful for formatting fields inside of tables -# |_| is a nonbreaking space; similarly useful inside of tables -rst_epilog = """ -.. |br| raw:: html - -
    -.. |_| unicode:: 0xA0 - :trim: -""" - - -# Options for HTML output -# ----------------------- - -html_theme_path = [] -html_theme = 'sphinx_ansible_theme' -html_show_sphinx = False - -html_theme_options = { - 'canonical_url': "https://docs.ansible.com/ansible/latest/", - 'hubspot_id': '330046', - 'satellite_tracking': True, - 'show_extranav': True, - 'swift_id': 'yABGvz2N8PwcwBxyfzUc', - 'tag_manager_id': 'GTM-PSB293', - 'vcs_pageview_mode': 'edit' -} - -html_context = { - 'display_github': 'True', - 'show_sphinx': False, - 'is_eol': False, - 'github_user': 'ansible', - 'github_repo': 'ansible', - 'github_version': 'devel/docs/docsite/rst/', - 'github_module_version': 'devel/lib/ansible/modules/', - 'github_root_dir': 'devel/lib/ansible', - 'github_cli_version': 'devel/lib/ansible/cli/', - 'current_version': version, - 'latest_version': '8', - # list specifically out of order to make latest work - 'available_versions': ('latest', '2.9', 'devel'), -} - -# Add extra CSS styles to the resulting HTML pages -html_css_files = [] - -# The style sheet to use for HTML and HTML Help pages. A file of that name -# must exist either in Sphinx' static/ path, or in one of the custom paths -# given in html_static_path. -# html_style = 'solar.css' - -# The name for this set of Sphinx documents. If None, it defaults to -# " v documentation". -html_title = 'Ansible Documentation' - -# A shorter title for the navigation bar. Default is the same as html_title. -html_short_title = 'Documentation' - -# The name of an image file (within the static path) to place at the top of -# the sidebar. -# html_logo = - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -# html_favicon = 'favicon.ico' - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['../_static'] - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -# html_use_smartypants = True - -# Custom sidebar templates, maps document names to template names. -# html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -# html_additional_pages = {} - -# If false, no module index is generated. -# html_use_modindex = True - -# If false, no index is generated. -# html_use_index = True - -# If true, the index is split into individual pages for each letter. -# html_split_index = False - -# If true, the reST sources are included in the HTML build as _sources/. -html_copy_source = False - -# If true, an OpenSearch description file will be output, and all pages will -# contain a tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -# html_use_opensearch = 'https://docs.ansible.com/ansible/latest' - -# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml"). -# html_file_suffix = '' - -# Output file base name for HTML help builder. -htmlhelp_basename = 'Poseidodoc' - -# Configuration for sphinx-notfound-pages -# with no 'notfound_template' and no 'notfound_context' set, -# the extension builds 404.rst into a location-agnostic 404 page -# -# default is `en` - using this for the sub-site: -notfound_default_language = "ansible" -# default is `latest`: -# setting explicitly - docsite serves up /ansible/latest/404.html -# so keep this set to `latest` even on the `devel` branch -# then no maintenance is needed when we branch a new stable_x.x -notfound_default_version = "latest" -# makes default setting explicit: -notfound_no_urls_prefix = False - -# Options for LaTeX output -# ------------------------ - -# The paper size ('letter' or 'a4'). -# latex_paper_size = 'letter' - -# The font size ('10pt', '11pt' or '12pt'). -# latex_font_size = '10pt' - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, document class -# [howto/manual]). -latex_documents = [ - ('index', 'ansible.tex', 'Ansible 2.2 Documentation', AUTHOR, 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -# latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -# latex_use_parts = False - -# Additional stuff for the LaTeX preamble. -# latex_preamble = '' - -# Documents to append as an appendix to all manuals. -# latex_appendices = [] - -# If false, no module index is generated. -# latex_use_modindex = True - -autoclass_content = 'both' - -# Note: Our strategy for intersphinx mappings is to have the upstream build location as the -# canonical source and then cached copies of the mapping stored locally in case someone is building -# when disconnected from the internet. We then have a script to update the cached copies. -# -# Because of that, each entry in this mapping should have this format: -# name: ('http://UPSTREAM_URL', (None, 'path/to/local/cache.inv')) -# -# The update script depends on this format so deviating from this (for instance, adding a third -# location for the mappning to live) will confuse it. -intersphinx_mapping = {'python': ('https://docs.python.org/2/', (None, '../python2.inv')), - 'python3': ('https://docs.python.org/3/', (None, '../python3.inv')), - 'jinja2': ('http://jinja.palletsprojects.com/', (None, '../jinja2.inv')), - 'ansible_7': ('https://docs.ansible.com/ansible/7/', (None, '../ansible_7.inv')), - 'ansible_6': ('https://docs.ansible.com/ansible/6/', (None, '../ansible_6.inv')), - 'ansible_2_9': ('https://docs.ansible.com/ansible/2.9/', (None, '../ansible_2_9.inv')), - } - -# linckchecker settings -linkcheck_ignore = [ -] -linkcheck_workers = 25 -# linkcheck_anchors = False diff --git a/docs/docsite/sphinx_conf/core_conf.py b/docs/docsite/sphinx_conf/core_conf.py deleted file mode 100644 index 3a328019ab1..00000000000 --- a/docs/docsite/sphinx_conf/core_conf.py +++ /dev/null @@ -1,349 +0,0 @@ -# -*- coding: utf-8 -*- -# -# documentation build configuration file, created by -# sphinx-quickstart on Sat Sep 27 13:23:22 2008-2009. -# -# This file is execfile()d with the current directory set to its -# containing dir. -# -# The contents of this file are pickled, so don't put values in the namespace -# that aren't pickleable (module imports are okay, they're removed -# automatically). -# -# All configuration values have a default value; values that are commented out -# serve to show the default value. - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import sys -import os - -# If your extensions are in another directory, add it here. If the directory -# is relative to the documentation root, use os.path.abspath to make it -# absolute, like shown here. -# sys.path.append(os.path.abspath('some/directory')) -# -sys.path.insert(0, os.path.join('ansible', 'lib')) - -# We want sphinx to document the ansible modules contained in this repository, -# not those that may happen to be installed in the version -# of Python used to run sphinx. When sphinx loads in order to document, -# the repository version needs to be the one that is loaded: -sys.path.insert(0, os.path.abspath(os.path.join('..', '..', '..', 'lib'))) - -VERSION = 'devel' -AUTHOR = 'Ansible, Inc' - - -# General configuration -# --------------------- - -# Add any Sphinx extension module names here, as strings. -# They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -# TEST: 'sphinxcontrib.fulltoc' -extensions = [ - 'sphinx.ext.autodoc', - 'sphinx.ext.intersphinx', - 'notfound.extension', - 'sphinx_antsibull_ext', # provides CSS for the plugin/module docs generated by antsibull -] - -# Later on, add 'sphinx.ext.viewcode' to the list if you want to have -# colorized code generated too for references. - - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['../.templates'] - -# The suffix of source filenames. -source_suffix = '.rst' - -# The master toctree document. -root_doc = master_doc = 'index' # Sphinx 4+ / 3- - -# General substitutions. -project = 'Ansible' -copyright = "Ansible project contributors" - -# The default replacements for |version| and |release|, also used in various -# other places throughout the built documents. -# -# The short X.Y version. -version = VERSION -# The full version, including alpha/beta/rc tags. -release = VERSION - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -# today = '' -# Else, today_fmt is used as the format for a strftime call. -today_fmt = '%B %d, %Y' - -# List of documents that shouldn't be included in the build. -# unused_docs = [] - -# List of directories, relative to source directories, that shouldn't be -# searched for source files. -# exclude_dirs = [] - -# A list of glob-style patterns that should be excluded when looking -# for source files. -exclude_patterns = [ - '2.10_index.rst', - 'ansible_index.rst', - 'core_index.rst', - 'network', - 'scenario_guides', - 'community/collection_contributors/test_index.rst', - 'community/collection_contributors/collection_integration_about.rst', - 'community/collection_contributors/collection_integration_updating.rst', - 'community/collection_contributors/collection_integration_add.rst', - 'community/collection_contributors/collection_test_pr_locally.rst', - 'community/collection_contributors/collection_integration_tests.rst', - 'community/collection_contributors/collection_integration_running.rst', - 'community/collection_contributors/collection_reviewing.rst', - 'community/collection_contributors/collection_requirements.rst', - 'community/collection_contributors/collection_unit_tests.rst', - 'community/maintainers.rst', - 'community/contributions_collections.rst', - 'community/create_pr_quick_start.rst', - 'community/reporting_collections.rst', - 'community/contributing_maintained_collections.rst', - 'community/collection_development_process.rst', - 'community/collection_contributors/collection_release_without_branches.rst', - 'community/collection_contributors/collection_release_with_branches.rst', - 'community/collection_contributors/collection_releasing.rst', - 'community/maintainers_guidelines.rst', - 'community/maintainers_workflow.rst', - 'community/steering/community_steering_committee.rst', - 'community/steering/steering_committee_membership.rst', - 'community/steering/steering_committee_past_members.rst', - 'community/steering/steering_index.rst', - 'dev_guide/ansible_index.rst', - 'dev_guide/core_index.rst', - 'dev_guide/platforms/aws_guidelines.rst', - 'dev_guide/platforms/openstack_guidelines.rst', - 'dev_guide/platforms/ovirt_dev_guide.rst', - 'dev_guide/platforms/vmware_guidelines.rst', - 'dev_guide/platforms/vmware_rest_guidelines.rst', - 'porting_guides/porting_guides.rst', - 'porting_guides/porting_guide_[1-9]*', - 'roadmap/index.rst', - 'roadmap/ansible_roadmap_index.rst', - 'roadmap/old_roadmap_index.rst', - 'roadmap/ROADMAP_2_5.rst', - 'roadmap/ROADMAP_2_6.rst', - 'roadmap/ROADMAP_2_7.rst', - 'roadmap/ROADMAP_2_8.rst', - 'roadmap/ROADMAP_2_9.rst', - 'roadmap/COLLECTIONS*' -] - -# The reST default role (used for this markup: `text`) to use for all -# documents. -# default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -# add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -# add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -# show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'ansible' - -highlight_language = 'YAML+Jinja' - -# Substitutions, variables, entities, & shortcuts for text which do not need to link to anything. -# For titles which should be a link, use the intersphinx anchors set at the index, chapter, and section levels, such as qi_start_: -# |br| is useful for formatting fields inside of tables -# |_| is a nonbreaking space; similarly useful inside of tables -rst_epilog = """ -.. |br| raw:: html - -
    -.. |_| unicode:: 0xA0 - :trim: -""" - - -# Options for HTML output -# ----------------------- - -html_theme_path = [] -html_theme = 'sphinx_ansible_theme' -html_show_sphinx = False - -html_theme_options = { - 'canonical_url': "https://docs.ansible.com/ansible/latest/", - 'hubspot_id': '330046', - 'satellite_tracking': True, - 'show_extranav': True, - 'swift_id': 'yABGvz2N8PwcwBxyfzUc', - 'tag_manager_id': 'GTM-PSB293', - 'vcs_pageview_mode': 'edit' -} - -html_context = { - 'display_github': 'True', - 'show_sphinx': False, - 'is_eol': False, - 'github_user': 'ansible', - 'github_repo': 'ansible', - 'github_version': 'devel/docs/docsite/rst/', - 'github_module_version': 'devel/lib/ansible/modules/', - 'github_root_dir': 'devel/lib/ansible', - 'github_cli_version': 'devel/lib/ansible/cli/', - 'current_version': version, - 'latest_version': '2.15', - # list specifically out of order to make latest work - 'available_versions': ('2.15', '2.14', '2.13', 'devel',), -} - -# Add extra CSS styles to the resulting HTML pages -html_css_files = [ - 'css/core-color-scheme.css', -] - -# The style sheet to use for HTML and HTML Help pages. A file of that name -# must exist either in Sphinx' static/ path, or in one of the custom paths -# given in html_static_path. -# html_style = 'solar.css' - -# The name for this set of Sphinx documents. If None, it defaults to -# " v documentation". -html_title = 'Ansible Core Documentation' - -# A shorter title for the navigation bar. Default is the same as html_title. -html_short_title = 'Documentation' - -# The name of an image file (within the static path) to place at the top of -# the sidebar. -# html_logo = - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -# html_favicon = 'favicon.ico' - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['../_static'] - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -# html_use_smartypants = True - -# Custom sidebar templates, maps document names to template names. -# html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -# html_additional_pages = {} - -# If false, no module index is generated. -# html_use_modindex = True - -# If false, no index is generated. -# html_use_index = True - -# If true, the index is split into individual pages for each letter. -# html_split_index = False - -# If true, the reST sources are included in the HTML build as _sources/. -html_copy_source = False - -# If true, an OpenSearch description file will be output, and all pages will -# contain a tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -# html_use_opensearch = 'https://docs.ansible.com/ansible/latest' - -# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml"). -# html_file_suffix = '' - -# Output file base name for HTML help builder. -htmlhelp_basename = 'Poseidodoc' - -# Configuration for sphinx-notfound-pages -# with no 'notfound_template' and no 'notfound_context' set, -# the extension builds 404.rst into a location-agnostic 404 page -# -# default is `en` - using this for the sub-site: -notfound_default_language = "ansible" -# default is `latest`: -# setting explicitly - docsite serves up /ansible/latest/404.html -# so keep this set to `latest` even on the `devel` branch -# then no maintenance is needed when we branch a new stable_x.x -notfound_default_version = "latest" -# makes default setting explicit: -notfound_no_urls_prefix = False - -# Options for LaTeX output -# ------------------------ - -# The paper size ('letter' or 'a4'). -# latex_paper_size = 'letter' - -# The font size ('10pt', '11pt' or '12pt'). -# latex_font_size = '10pt' - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, document class -# [howto/manual]). -latex_documents = [ - ('index', 'ansible.tex', 'Ansible 2.2 Documentation', AUTHOR, 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -# latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -# latex_use_parts = False - -# Additional stuff for the LaTeX preamble. -# latex_preamble = '' - -# Documents to append as an appendix to all manuals. -# latex_appendices = [] - -# If false, no module index is generated. -# latex_use_modindex = True - -autoclass_content = 'both' - -# Note: Our strategy for intersphinx mappings is to have the upstream build location as the -# canonical source and then cached copies of the mapping stored locally in case someone is building -# when disconnected from the internet. We then have a script to update the cached copies. -# -# Because of that, each entry in this mapping should have this format: -# name: ('http://UPSTREAM_URL', (None, 'path/to/local/cache.inv')) -# -# The update script depends on this format so deviating from this (for instance, adding a third -# location for the mappning to live) will confuse it. -intersphinx_mapping = {'python': ('https://docs.python.org/2/', (None, '../python2.inv')), - 'python3': ('https://docs.python.org/3/', (None, '../python3.inv')), - 'jinja2': ('http://jinja.palletsprojects.com/', (None, '../jinja2.inv')), - 'ansible_7': ('https://docs.ansible.com/ansible/7/', (None, '../ansible_7.inv')), - 'ansible_6': ('https://docs.ansible.com/ansible/6/', (None, '../ansible_6.inv')), - 'ansible_2_9': ('https://docs.ansible.com/ansible/2.9/', (None, '../ansible_2_9.inv')), - } - -# linckchecker settings -linkcheck_ignore = [ -] -linkcheck_workers = 25 -# linkcheck_anchors = False diff --git a/docs/docsite/sphinx_conf/core_lang_conf.py b/docs/docsite/sphinx_conf/core_lang_conf.py deleted file mode 100644 index 5f086e9afa4..00000000000 --- a/docs/docsite/sphinx_conf/core_lang_conf.py +++ /dev/null @@ -1,349 +0,0 @@ -# -*- coding: utf-8 -*- -# -# documentation build configuration file, created by -# sphinx-quickstart on Sat Sep 27 13:23:22 2008-2009. -# -# This file is execfile()d with the current directory set to its -# containing dir. -# -# The contents of this file are pickled, so don't put values in the namespace -# that aren't pickleable (module imports are okay, they're removed -# automatically). -# -# All configuration values have a default value; values that are commented out -# serve to show the default value. - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import sys -import os - -# If your extensions are in another directory, add it here. If the directory -# is relative to the documentation root, use os.path.abspath to make it -# absolute, like shown here. -# sys.path.append(os.path.abspath('some/directory')) -# -sys.path.insert(0, os.path.join('ansible', 'lib')) - -# We want sphinx to document the ansible modules contained in this repository, -# not those that may happen to be installed in the version -# of Python used to run sphinx. When sphinx loads in order to document, -# the repository version needs to be the one that is loaded: -sys.path.insert(0, os.path.abspath(os.path.join('..', '..', '..', 'lib'))) - -VERSION = 'devel' -AUTHOR = 'Ansible, Inc' - - -# General configuration -# --------------------- - -# Add any Sphinx extension module names here, as strings. -# They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -# TEST: 'sphinxcontrib.fulltoc' -extensions = [ - 'sphinx.ext.autodoc', - 'sphinx.ext.intersphinx', - 'notfound.extension', - 'sphinx_antsibull_ext', # provides CSS for the plugin/module docs generated by antsibull -] - -# Later on, add 'sphinx.ext.viewcode' to the list if you want to have -# colorized code generated too for references. - - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['../.templates'] - -# The suffix of source filenames. -source_suffix = '.rst' - -# The master toctree document. -root_doc = master_doc = 'index' # Sphinx 4+ / 3- - -# General substitutions. -project = 'Ansible' -copyright = "Ansible project contributors" - -# The default replacements for |version| and |release|, also used in various -# other places throughout the built documents. -# -# The short X.Y version. -version = VERSION -# The full version, including alpha/beta/rc tags. -release = VERSION - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -# today = '' -# Else, today_fmt is used as the format for a strftime call. -today_fmt = '%B %d, %Y' - -# List of documents that shouldn't be included in the build. -# unused_docs = [] - -# List of directories, relative to source directories, that shouldn't be -# searched for source files. -# exclude_dirs = [] - -# A list of glob-style patterns that should be excluded when looking -# for source files. -exclude_patterns = [ - '2.10_index.rst', - 'ansible_index.rst', - 'core_index.rst', - 'network', - 'scenario_guides', - 'community/collection_contributors/test_index.rst', - 'community/collection_contributors/collection_integration_about.rst', - 'community/collection_contributors/collection_integration_updating.rst', - 'community/collection_contributors/collection_integration_add.rst', - 'community/collection_contributors/collection_test_pr_locally.rst', - 'community/collection_contributors/collection_integration_tests.rst', - 'community/collection_contributors/collection_integration_running.rst', - 'community/collection_contributors/collection_reviewing.rst', - 'community/collection_contributors/collection_requirements.rst', - 'community/collection_contributors/collection_unit_tests.rst', - 'community/maintainers.rst', - 'community/contributions_collections.rst', - 'community/create_pr_quick_start.rst', - 'community/reporting_collections.rst', - 'community/contributing_maintained_collections.rst', - 'community/collection_development_process.rst', - 'community/collection_contributors/collection_release_without_branches.rst', - 'community/collection_contributors/collection_release_with_branches.rst', - 'community/collection_contributors/collection_releasing.rst', - 'community/maintainers_guidelines.rst', - 'community/maintainers_workflow.rst', - 'community/steering/community_steering_committee.rst', - 'community/steering/steering_committee_membership.rst', - 'community/steering/steering_committee_past_members.rst', - 'community/steering/steering_index.rst', - 'dev_guide/ansible_index.rst', - 'dev_guide/core_index.rst', - 'dev_guide/platforms/aws_guidelines.rst', - 'dev_guide/platforms/openstack_guidelines.rst', - 'dev_guide/platforms/ovirt_dev_guide.rst', - 'dev_guide/platforms/vmware_guidelines.rst', - 'dev_guide/platforms/vmware_rest_guidelines.rst', - 'porting_guides/porting_guides.rst', - 'porting_guides/porting_guide_[1-9]*', - 'roadmap/index.rst', - 'roadmap/ansible_roadmap_index.rst', - 'roadmap/old_roadmap_index.rst', - 'roadmap/ROADMAP_2_5.rst', - 'roadmap/ROADMAP_2_6.rst', - 'roadmap/ROADMAP_2_7.rst', - 'roadmap/ROADMAP_2_8.rst', - 'roadmap/ROADMAP_2_9.rst', - 'roadmap/COLLECTIONS*' -] - -# The reST default role (used for this markup: `text`) to use for all -# documents. -# default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -# add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -# add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -# show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'ansible' - -highlight_language = 'YAML+Jinja' - -# Substitutions, variables, entities, & shortcuts for text which do not need to link to anything. -# For titles which should be a link, use the intersphinx anchors set at the index, chapter, and section levels, such as qi_start_: -# |br| is useful for formatting fields inside of tables -# |_| is a nonbreaking space; similarly useful inside of tables -rst_epilog = """ -.. |br| raw:: html - -
    -.. |_| unicode:: 0xA0 - :trim: -""" - - -# Options for HTML output -# ----------------------- - -html_theme_path = [] -html_theme = 'sphinx_ansible_theme' -html_show_sphinx = False - -html_theme_options = { - 'canonical_url': "https://docs.ansible.com/ansible/latest/", - 'hubspot_id': '330046', - 'satellite_tracking': True, - 'show_extranav': True, - 'swift_id': 'yABGvz2N8PwcwBxyfzUc', - 'tag_manager_id': 'GTM-PSB293', - 'vcs_pageview_mode': 'edit' -} - -html_context = { - 'display_github': 'True', - 'show_sphinx': False, - 'is_eol': False, - 'github_user': 'ansible', - 'github_repo': 'ansible', - 'github_version': 'devel/docs/docsite/rst/', - 'github_module_version': 'devel/lib/ansible/modules/', - 'github_root_dir': 'devel/lib/ansible', - 'github_cli_version': 'devel/lib/ansible/cli/', - 'current_version': version, - 'latest_version': '2.14', - # list specifically out of order to make latest work - 'available_versions': ('2.14_ja', '2.13_ja', '2.12_ja',), -} - -# Add extra CSS styles to the resulting HTML pages -html_css_files = [ - 'css/core-color-scheme.css', -] - -# The style sheet to use for HTML and HTML Help pages. A file of that name -# must exist either in Sphinx' static/ path, or in one of the custom paths -# given in html_static_path. -# html_style = 'solar.css' - -# The name for this set of Sphinx documents. If None, it defaults to -# " v documentation". -html_title = 'Ansible Core Documentation' - -# A shorter title for the navigation bar. Default is the same as html_title. -html_short_title = 'Documentation' - -# The name of an image file (within the static path) to place at the top of -# the sidebar. -# html_logo = - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -# html_favicon = 'favicon.ico' - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['../_static'] - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -# html_use_smartypants = True - -# Custom sidebar templates, maps document names to template names. -# html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -# html_additional_pages = {} - -# If false, no module index is generated. -# html_use_modindex = True - -# If false, no index is generated. -# html_use_index = True - -# If true, the index is split into individual pages for each letter. -# html_split_index = False - -# If true, the reST sources are included in the HTML build as _sources/. -html_copy_source = False - -# If true, an OpenSearch description file will be output, and all pages will -# contain a tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -# html_use_opensearch = 'https://docs.ansible.com/ansible/latest' - -# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml"). -# html_file_suffix = '' - -# Output file base name for HTML help builder. -htmlhelp_basename = 'Poseidodoc' - -# Configuration for sphinx-notfound-pages -# with no 'notfound_template' and no 'notfound_context' set, -# the extension builds 404.rst into a location-agnostic 404 page -# -# default is `en` - using this for the sub-site: -notfound_default_language = "ansible" -# default is `latest`: -# setting explicitly - docsite serves up /ansible/latest/404.html -# so keep this set to `latest` even on the `devel` branch -# then no maintenance is needed when we branch a new stable_x.x -notfound_default_version = "latest" -# makes default setting explicit: -notfound_no_urls_prefix = False - -# Options for LaTeX output -# ------------------------ - -# The paper size ('letter' or 'a4'). -# latex_paper_size = 'letter' - -# The font size ('10pt', '11pt' or '12pt'). -# latex_font_size = '10pt' - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, document class -# [howto/manual]). -latex_documents = [ - ('index', 'ansible.tex', 'Ansible Documentation', AUTHOR, 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -# latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -# latex_use_parts = False - -# Additional stuff for the LaTeX preamble. -# latex_preamble = '' - -# Documents to append as an appendix to all manuals. -# latex_appendices = [] - -# If false, no module index is generated. -# latex_use_modindex = True - -autoclass_content = 'both' - -# Note: Our strategy for intersphinx mappings is to have the upstream build location as the -# canonical source and then cached copies of the mapping stored locally in case someone is building -# when disconnected from the internet. We then have a script to update the cached copies. -# -# Because of that, each entry in this mapping should have this format: -# name: ('http://UPSTREAM_URL', (None, 'path/to/local/cache.inv')) -# -# The update script depends on this format so deviating from this (for instance, adding a third -# location for the mappning to live) will confuse it. -intersphinx_mapping = {'python': ('https://docs.python.org/2/', (None, '../python2.inv')), - 'python3': ('https://docs.python.org/3/', (None, '../python3.inv')), - 'jinja2': ('http://jinja.palletsprojects.com/', (None, '../jinja2.inv')), - 'ansible_7': ('https://docs.ansible.com/ansible/7/', (None, '../ansible_7.inv')), - 'ansible_6': ('https://docs.ansible.com/ansible/6/', (None, '../ansible_6.inv')), - 'ansible_2_9': ('https://docs.ansible.com/ansible/2.9/', (None, '../ansible_2_9.inv')), - } - -# linckchecker settings -linkcheck_ignore = [ -] -linkcheck_workers = 25 -# linkcheck_anchors = False diff --git a/docs/docsite/variables.dot b/docs/docsite/variables.dot deleted file mode 100644 index f5860dcbf8c..00000000000 --- a/docs/docsite/variables.dot +++ /dev/null @@ -1,38 +0,0 @@ -digraph G { - - subgraph cluster_0 { - "command line variables" -> "--extra-args" - } - - subgraph cluster_1 { - "role variables" -> "roles/rolename/vars.yml" -> "parameters passed to role" -> "parameters from dependent roles" - } - - subgraph cluster_2 { - "top-level playbook variables" -> "vars: directives" -> "vars_files: directives"; - } - - subgraph cluster_3 { - "inventory variables" -> "group_vars/all" -> "group_vars/grandparent1" -> "group_vars/parent1" -> "host_vars/myhostname"; - "group_vars/all" -> "group_vars/grandparent2"; - "group_vars/grandparent1" -> "group_vars/parent2" - "group_vars/grandparent2" -> "host_vars/myhostname"; - "group_vars/parent2" -> "host_vars/myhostname" - } - - subgraph cluster_4 { - "facts" -> "gathered host facts" - "facts" -> "host facts from /etc/ansible/facts.d" - "facts" -> "set_fact" - "facts" -> "include_vars" - } - - subgraph cluster_5 { - "role defaults" -> "roles/rolename/defaults.yml" - } - - "command line variables" -> "role variables" -> "top-level playbook variables" -> "inventory variables" -> "role defaults" -> "facts" - - - -} diff --git a/docs/docsite/version_helper.py b/docs/docsite/version_helper.py deleted file mode 100644 index 562b947b93f..00000000000 --- a/docs/docsite/version_helper.py +++ /dev/null @@ -1,30 +0,0 @@ -"""Simple helper for printing ansible-core version numbers.""" -import argparse -import pathlib -import sys - -from packaging.version import Version - - -def main() -> None: - """Main program entry point.""" - parser = argparse.ArgumentParser(description=__doc__) - group = parser.add_mutually_exclusive_group() - group.add_argument('--raw', action='store_true') - group.add_argument('--majorversion', action='store_true') - args = parser.parse_args() - - sys.path.insert(0, str(pathlib.Path(__file__).resolve().parent.parent.parent / 'lib')) - - from ansible.release import __version__ - - version = Version(__version__) - - if args.raw: - print(version) - elif args.majorversion: - print(f'{version.major}.{version.minor}') - - -if __name__ == '__main__': - main() diff --git a/docs/man/.gitignore b/docs/man/.gitignore deleted file mode 100644 index 81a33679397..00000000000 --- a/docs/man/.gitignore +++ /dev/null @@ -1,2 +0,0 @@ -*.xml -*.asciidoc diff --git a/docs/man/man3/.gitdir b/docs/man/man3/.gitdir deleted file mode 100644 index e69de29bb2d..00000000000 diff --git a/docs/templates/cli_rst.j2 b/docs/templates/cli_rst.j2 deleted file mode 100644 index 8f5a8db3379..00000000000 --- a/docs/templates/cli_rst.j2 +++ /dev/null @@ -1,161 +0,0 @@ -:source: {{ cli }}.py - -{% set name = cli_name -%} -{% set name_slug = cli_name -%} - -.. _{{name}}: - -{% set name_len = name|length + 0-%} -{{ '=' * name_len }} -{{name}} -{{ '=' * name_len }} - - -:strong:`{{short_desc|default('')}}` - - -.. contents:: - :local: - :depth: {{content_depth}} - - -.. program:: {{cli_name}} - -Synopsis -======== - -.. code-block:: bash - - {{ usage|replace('%prog', cli_name) }} - - -Description -=========== - - -{{ long_desc|default('', True) }} - -{% if options %} -Common Options -============== - - -{% for option in options|sort(attribute='options') if option.options %} - -.. option:: {% for switch in option['options'] %}{{switch}}{% if option['arg'] %} <{{option['arg']}}>{% endif %}{% if not loop.last %}, {% endif %}{% endfor %} - - {{ option['desc'] }} -{% endfor %} -{% endif %} - -{% if arguments %} -ARGUMENTS -========= - -.. program:: {{cli_name}} - -{% for arg in arguments %} -.. option:: {{ arg }} - - {{ (arguments[arg]|default(' '))}} - -{% endfor %} -{% endif %} - -{% if actions %} -Actions -======= - -{% for action in actions %} - -.. program:: {{cli_name}} {{action}} -.. _{{cli_name|replace('-','_')}}_{{action}}: - -{{ action}} -{{ '-' * action|length}} - -{{ (actions[action]['desc']|default(' '))}} - -{% if actions[action]['options'] %} - - -{% for option in actions[action]['options']|sort(attribute='options') %} -.. option:: {% for switch in option['options'] if switch in actions[action]['option_names'] %}{{switch}} {% if option['arg'] %} <{{option['arg']}}>{% endif %}{% if not loop.last %}, {% endif %}{% endfor %} - - {{ (option['desc']) }} -{% endfor %} -{% endif %} - -{% for sub_action in actions[action]['actions'] %} - - -.. program:: {{cli_name}} {{action}} {{sub_action}} -.. _{{cli_name|replace('-','_')}}_{{action}}_{{sub_action}}: - -{{ action + " " + sub_action }} -{{ '+' * (action|length + sub_action|length + 1) }} - -{{ (actions[action]['actions'][sub_action]['desc']|default(' '))}} - -{% if actions[action]['actions'][sub_action]['options'] %} - - -{% for option in actions[action]['actions'][sub_action]['options']|sort(attribute='options') %} -.. option:: {% for switch in option['options'] if switch in actions[action]['actions'][sub_action]['option_names'] %}{{switch}} {% if option['arg'] %} <{{option['arg']}}>{% endif %}{% if not loop.last %}, {% endif %}{% endfor %} - - {{ (option['desc']) }} -{% endfor %} -{% endif %} - -{% endfor %} - -{% endfor %} -.. program:: {{cli_name}} -{% endif %} - -Environment -=========== - -The following environment variables may be specified. - -{% if inventory %} -:envvar:`ANSIBLE_INVENTORY` -- Override the default ansible inventory file - -{% endif %} -{% if library %} -:envvar:`ANSIBLE_LIBRARY` -- Override the default ansible module library path - -{% endif %} -:envvar:`ANSIBLE_CONFIG` -- Override the default ansible config file - -Many more are available for most options in ansible.cfg - - -Files -===== - -{% if inventory %} -:file:`/etc/ansible/hosts` -- Default inventory file - -{% endif %} -:file:`/etc/ansible/ansible.cfg` -- Config file, used if present - -:file:`~/.ansible.cfg` -- User config file, overrides the default config if present - -Author -====== - -Ansible was originally written by Michael DeHaan. - -See the `AUTHORS` file for a complete list of contributors. - - -License -======= - -Ansible is released under the terms of the GPLv3+ License. - -See also -======== - -{% for other in cli_bin_name_list|sort %}{% if other != cli_name %}:manpage:`{{other}}(1)`{% if not loop.last %}, {% endif %}{% endif %}{% endfor %} diff --git a/docs/templates/collections_galaxy_meta.rst.j2 b/docs/templates/collections_galaxy_meta.rst.j2 deleted file mode 100644 index 09d11c3d9bc..00000000000 --- a/docs/templates/collections_galaxy_meta.rst.j2 +++ /dev/null @@ -1,98 +0,0 @@ -.. _collections_galaxy_meta: - -************************************ -Collection Galaxy metadata structure -************************************ - -A key component of an Ansible collection is the ``galaxy.yml`` file placed in the root directory of a collection. This -file contains the metadata of the collection that is used to generate a collection artifact. - -Structure -========= - -The ``galaxy.yml`` file must contain the following keys in valid YAML: - - -.. rst-class:: documentation-table - -.. list-table:: - :header-rows: 1 - :widths: auto - - * - Key - - Comment - -{%- for entry in options %} - - - * - .. rst-class:: value-name - - @{ entry.key }@ |br| - - .. rst-class:: value-type - - @{ entry.type | documented_type }@ |_| - - {% if entry.get('required', False) -%} - .. rst-class:: value-separator - - / |_| - - .. rst-class:: value-required - - required - {%- endif %} - - {% if 'version_added' in entry -%} - - .. rst-class:: value-added-in - - |br| version_added: @{ entry.version_added }@ - - |_| - - {%- endif %} - - - {% for desc in entry.description -%} - @{ desc | trim | rst_ify }@ - - {% endfor -%} -{%- endfor %} - - -Examples -======== - -.. code-block:: yaml - - namespace: "namespace_name" - name: "collection_name" - version: "1.0.12" - readme: "README.md" - authors: - - "Author1" - - "Author2 (https://author2.example.com)" - - "Author3 " - dependencies: - "other_namespace.collection1": ">=1.0.0" - "other_namespace.collection2": ">=2.0.0,<3.0.0" - "anderson55.my_collection": "*" # note: "*" selects the highest version available - license: - - "MIT" - tags: - - demo - - collection - repository: "https://www.github.com/my_org/my_collection" - -.. seealso:: - - :ref:`developing_collections` - Develop or modify a collection. - :ref:`developing_modules_general` - Learn about how to write Ansible modules - :ref:`collections` - Learn how to install and use collections. - `Mailing List `_ - The development mailing list - `irc.libera.chat `_ - #ansible IRC chat channel diff --git a/docs/templates/config.rst.j2 b/docs/templates/config.rst.j2 deleted file mode 100644 index 349b1e39d10..00000000000 --- a/docs/templates/config.rst.j2 +++ /dev/null @@ -1,250 +0,0 @@ -.. _ansible_configuration_settings: - -{% set name = 'Ansible Configuration Settings' -%} -{% set name_slug = 'config' -%} - -{% set name_len = name|length + 0-%} -{{ '=' * name_len }} -{{name}} -{{ '=' * name_len }} - -Ansible supports several sources for configuring its behavior, including an ini file named ``ansible.cfg``, environment variables, command-line options, playbook keywords, and variables. See :ref:`general_precedence_rules` for details on the relative precedence of each source. - -The ``ansible-config`` utility allows users to see all the configuration settings available, their defaults, how to set them and -where their current value comes from. See :ref:`ansible-config` for more information. - -.. _ansible_configuration_settings_locations: - -The configuration file -====================== - -Changes can be made and used in a configuration file which will be searched for in the following order: - - * ``ANSIBLE_CONFIG`` (environment variable if set) - * ``ansible.cfg`` (in the current directory) - * ``~/.ansible.cfg`` (in the home directory) - * ``/etc/ansible/ansible.cfg`` - -Ansible will process the above list and use the first file found, all others are ignored. - -.. note:: - - The configuration file is one variant of an INI format. - Both the hash sign (``#``) and semicolon (``;``) are allowed as - comment markers when the comment starts the line. - However, if the comment is inline with regular values, - only the semicolon is allowed to introduce the comment. - For instance:: - - # some basic default values... - inventory = /etc/ansible/hosts ; This points to the file that lists your hosts - - -.. _generating_ansible.cfg: - -Generating a sample ``ansible.cfg`` file ------------------------------------------ - -You can generate a fully commented-out example ``ansible.cfg`` file, for example:: - - $ ansible-config init --disabled > ansible.cfg - -You can also have a more complete file that includes existing plugins:: - - $ ansible-config init --disabled -t all > ansible.cfg - -You can use these as starting points to create your own ``ansible.cfg`` file. - -.. _cfg_in_world_writable_dir: - -Avoiding security risks with ``ansible.cfg`` in the current directory ---------------------------------------------------------------------- - - -If Ansible were to load ``ansible.cfg`` from a world-writable current working -directory, it would create a serious security risk. Another user could place -their own config file there, designed to make Ansible run malicious code both -locally and remotely, possibly with elevated privileges. For this reason, -Ansible will not automatically load a config file from the current working -directory if the directory is world-writable. - -If you depend on using Ansible with a config file in the current working -directory, the best way to avoid this problem is to restrict access to your -Ansible directories to particular user(s) and/or group(s). If your Ansible -directories live on a filesystem which has to emulate Unix permissions, like -Vagrant or Windows Subsystem for Linux (WSL), you may, at first, not know how -you can fix this as ``chmod``, ``chown``, and ``chgrp`` might not work there. -In most of those cases, the correct fix is to modify the mount options of the -filesystem so the files and directories are readable and writable by the users -and groups running Ansible but closed to others. For more details on the -correct settings, see: - -* for Vagrant, the `Vagrant documentation `_ covers synced folder permissions. -* for WSL, the `WSL docs `_ - and this `Microsoft blog post `_ cover mount options. - -If you absolutely depend on storing your Ansible config in a world-writable current -working directory, you can explicitly specify the config file via the -:envvar:`ANSIBLE_CONFIG` environment variable. Please take -appropriate steps to mitigate the security concerns above before doing so. - - -Relative paths for configuration --------------------------------- - -You can specify a relative path for many configuration options. In most of -those cases the path used will be relative to the ``ansible.cfg`` file used -for the current execution. If you need a path relative to your current working -directory (CWD) you can use the ``{%raw%}{{CWD}}{%endraw%}`` macro to specify -it. We do not recommend this approach, as using your CWD as the root of -relative paths can be a security risk. For example: -``cd /tmp; secureinfo=./newrootpassword ansible-playbook ~/safestuff/change_root_pwd.yml``. - - -Common Options -============== - -This is a copy of the options available from our release, your local install might have extra options due to additional plugins, -you can use the command line utility mentioned above (`ansible-config`) to browse through those. - -{% if config_options %} - - -{% for config_option in config_options|sort %} -{% set config_len = config_option|length -%} -{% set config = config_options[config_option] %} -.. _{{config_option}}: - -{{config_option}} -{{ '-' * config_len }} - -{% if config['description'] and config['description'] != [''] %} -{% if config['description'] != ['TODO: write it'] %} -:Description: {{' '.join(config['description'])}} -{% endif %} -{% endif %} -{% if config['type'] %} -:Type: {{config['type']}} -{% endif %} -{% if 'default' in config %} -{% if config['default'] == '' %} -:Default: {{config['default']}} -{% else %} -:Default: ``{{config['default']}}`` -{% endif %} -{% endif %} -{% if config.get('choices', False) %} -:Choices: -{% if config['choices'] is mapping %} -{% for key in config['choices'].keys() %} - - :{{key}}: {{ config['choices'][key] }} -{% endfor %} -{% else %} -{% for key in config['choices'] %} - - {{key}} -{% endfor %} -{% endif %} -{% endif %} -{% if config['version_added'] %} -:Version Added: {{config['version_added']}} -{% endif %} -{% if config.get('ini', False) %} -:Ini: -{% for ini_map in config['ini']|sort(attribute='section') %} - {% if config['ini']|length > 1 %}- {% endif %}:Section: [{{ini_map['section']}}] - {% if config['ini']|length > 1 %} {% endif %}:Key: {{ini_map['key']}} -{% if ini_map['version_added'] %} - :Version Added: {{ini_map['version_added']}} -{% endif %} -{% if ini_map['deprecated'] %} - :Deprecated in: {{ini_map['deprecated']['version']}} - :Deprecated detail: {{ini_map['deprecated']['why']}} -{% if ini_map['deprecated']['alternatives'] %} - :Deprecated alternatives: {{ini_map['deprecated']['alternatives']}} -{% endif %} -{% endif %} -{% endfor %} -{% endif %} -{% if config.get('env', False) %} -:Environment: -{% for env_var_map in config['env']|sort(attribute='name') %} - {% if config['env']|length > 1 %}- {% endif %}:Variable: :envvar:`{{env_var_map['name']}}` -{% if env_var_map['version_added'] %} - :Version Added: {{env_var_map['version_added']}} -{% endif %} -{% if env_var_map['deprecated'] %} - :Deprecated in: {{env_var_map['deprecated']['version']}} - :Deprecated detail: {{env_var_map['deprecated']['why']}} -{% if env_var_map['deprecated']['alternatives'] %} - :Deprecated alternatives: {{env_var_map['deprecated']['alternatives']}} -{% endif %} -{% endif %} -{% endfor %} -{% endif %} -{% if config.get('vars', False) %} -:Variables: -{% for a_var in config['vars']|sort(attribute='name') %} - {% if config['vars']|length > 1 %}- {%endif%}:name: `{{a_var['name']}}` -{% if a_var['version_added'] %} - :Version Added: {{a_var['version_added']}} -{% endif %} -{% if a_var['deprecated'] %} - :Deprecated in: {{a_var['deprecated']['version']}} - :Deprecated detail: {{a_Var['deprecated']['why']}} -{% if a_var['deprecated']['alternatives'] %} - :Deprecated alternatives: {{a_var['deprecated']['alternatives']}} -{% endif %} -{% endif %} -{% endfor %} -{% endif %} -{% if config['deprecated'] %} -:Deprecated in: {{config['deprecated']['version']}} -:Deprecated detail: {{config['deprecated']['why']}} -{% if config['deprecated']['alternatives'] %} -:Deprecated alternatives: {{config['deprecated']['alternatives']}} -{% endif %} -{% endif %} - -{% endfor %} - -.. _list_of_ansible_env_vars: - -Environment Variables -===================== - -Other environment variables to configure plugins in collections can be found in :ref:`list_of_collection_env_vars`. - -.. envvar:: ANSIBLE_CONFIG - - - Override the default ansible config file - - -{% for config_option in config_options %} -{% for env_var_map in config_options[config_option]['env'] %} -.. envvar:: {{env_var_map['name']}} - -{% if config_options[config_option]['description'] and config_options[config_option]['description'] != [''] %} -{% if config_options[config_option]['description'] != ['TODO: write it'] %} - {{ ''.join(config_options[config_option]['description']) }} -{% endif %} -{% endif %} - - See also :ref:`{{config_option}} <{{config_option}}>` - -{% if env_var_map['version_added'] %} - :Version Added: {{env_var_map['version_added']}} -{% endif %} -{% if env_var_map['deprecated'] %} - :Deprecated in: {{env_var_map['deprecated']['version']}} - :Deprecated detail: {{env_var_map['deprecated']['why']}} -{% if env_var_map['deprecated']['alternatives'] %} - :Deprecated alternatives: {{env_var_map['deprecated']['alternatives']}} -{% endif %} -{% endif %} - -{% endfor %} - -{% endfor %} - -{% endif %} diff --git a/docs/templates/modules_by_category.rst.j2 b/docs/templates/modules_by_category.rst.j2 deleted file mode 100644 index 77635284484..00000000000 --- a/docs/templates/modules_by_category.rst.j2 +++ /dev/null @@ -1,17 +0,0 @@ -.. _modules_by_category: - -{# avoids rST "isn't included in any toctree" errors for module index docs #} -:orphan: - -Module Index -============ - - -.. toctree:: :maxdepth: 1 - -{% for name in categories %} -{# strip out empty category names as a result flattening the dir structure #} -{% if name %} - list_of_@{ name }@_modules -{% endif %} -{% endfor %} diff --git a/docs/templates/playbooks_keywords.rst.j2 b/docs/templates/playbooks_keywords.rst.j2 deleted file mode 100644 index c52998c1990..00000000000 --- a/docs/templates/playbooks_keywords.rst.j2 +++ /dev/null @@ -1,33 +0,0 @@ -.. _playbook_keywords: - -Playbook Keywords -================= - -These are the keywords available on common playbook objects. Keywords are one of several sources for configuring Ansible behavior. See :ref:`general_precedence_rules` for details on the relative precedence of each source. - - -.. note:: Please note: - - * Aliases for the directives are not reflected here, nor are mutable ones. For example, - :term:`action` in task can be substituted by the name of any Ansible module. - * The keywords do not have ``version_added`` information at this time - * Some keywords set defaults for the objects inside of them rather than for the objects - themselves - - -.. contents:: - :local: - :depth: 1 - -{% for name in playbook_class_names %} - -{{ name }} -{{ '-' * name|length }} -{#.. glossary::#} - -{% for attribute in pb_keywords[name]|sort %} - {{ attribute }} - {{ pb_keywords[name][attribute] |indent(8) }} - -{% endfor %} -{% endfor %} diff --git a/examples/DOCUMENTATION.yml b/examples/DOCUMENTATION.yml deleted file mode 100644 index b6ccb866298..00000000000 --- a/examples/DOCUMENTATION.yml +++ /dev/null @@ -1,36 +0,0 @@ ---- -# If a key doesn't apply to your module (ex: choices, default, or -# aliases) you can use the word 'null', or an empty list, [], where -# appropriate. -# See https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_documenting.html for more information -# -module: modulename -short_description: This is a short phrase describing the module -description: - - Longer description of the module. - - You might include instructions. -version_added: "X.Y" -author: "Your AWESOME name (@awesome-github-id)" -deprecated: "X.5" -options: -# One or more of the following - option_name: - description: - - Description of the options goes here. - - Must be written in sentences. - required: true or false - default: a string or the word null - choices: - - enable - - disable - aliases: - - repo_name - version_added: "1.X" -requirements: - - list of required things - - like the factor package - - zypper >= 1.0 -seealso: - - specify references to other modules, useful guides, and so on -notes: - - other things consumers of your module should know diff --git a/examples/ansible.cfg b/examples/ansible.cfg deleted file mode 100644 index 8670215c2fb..00000000000 --- a/examples/ansible.cfg +++ /dev/null @@ -1,11 +0,0 @@ -# Since Ansible 2.12 (core): -# To generate an example config file (a "disabled" one with all default settings, commented out): -# $ ansible-config init --disabled > ansible.cfg -# -# Also you can now have a more complete file by including existing plugins: -# ansible-config init --disabled -t all > ansible.cfg - -# For previous versions of Ansible you can check for examples in the 'stable' branches of each version -# Note that this file was always incomplete and lagging changes to configuration settings - -# for example, for 2.9: https://github.com/ansible/ansible/blob/stable-2.9/examples/ansible.cfg diff --git a/examples/hosts b/examples/hosts deleted file mode 100644 index e84a30cd984..00000000000 --- a/examples/hosts +++ /dev/null @@ -1,44 +0,0 @@ -# This is the default ansible 'hosts' file. -# -# It should live in /etc/ansible/hosts -# -# - Comments begin with the '#' character -# - Blank lines are ignored -# - Groups of hosts are delimited by [header] elements -# - You can enter hostnames or ip addresses -# - A hostname/ip can be a member of multiple groups - -# Ex 1: Ungrouped hosts, specify before any group headers: - -## green.example.com -## blue.example.com -## 192.168.100.1 -## 192.168.100.10 - -# Ex 2: A collection of hosts belonging to the 'webservers' group: - -## [webservers] -## alpha.example.org -## beta.example.org -## 192.168.1.100 -## 192.168.1.110 - -# If you have multiple hosts following a pattern, you can specify -# them like this: - -## www[001:006].example.com - -# Ex 3: A collection of database servers in the 'dbservers' group: - -## [dbservers] -## -## db01.intranet.mydomain.net -## db02.intranet.mydomain.net -## 10.25.1.56 -## 10.25.1.57 - -# Here's another example of host ranges, this time there are no -# leading 0s: - -## db-[99:101]-node.example.com - diff --git a/examples/hosts.yaml b/examples/hosts.yaml deleted file mode 100644 index 4470504c55e..00000000000 --- a/examples/hosts.yaml +++ /dev/null @@ -1,69 +0,0 @@ -# This is the default ansible 'hosts' file. -# -# It should live in /etc/ansible/hosts -# -# - Comments begin with the '#' character -# - Blank lines are ignored -# - Top level entries are assumed to be groups, start with 'all' to have a full hierarchy -# - Hosts must be specified in a group's hosts: -# and they must be a key (: terminated) -# - groups can have children, hosts and vars keys -# - groups are unique and global - if you define a group in multiple locations, Ansible aggregates all the data to the global name. -# - If you define a group as a child of 2 different groups, it will be the child of both, any hosts and variables assigned will not be dependent on the parents, they will all be associated with the group. -# - Anything defined under a host is assumed to be a var -# - You can enter hostnames or IP addresses -# - A hostname/IP can be a member of multiple groups - -# Ex 1: Ungrouped hosts, put them in 'all' or 'ungrouped' group, defines 4 hosts, one with 2 variables -##all: -## hosts: -## green.example.com: -## ansible_ssh_host: 191.168.100.32 -## anyvariable: value -## blue.example.com: -## 192.168.100.1: -## 192.168.100.10: - -# Ex 2: A collection of hosts belonging to the 'webservers' group, with shared group var -##webservers: -## hosts: -## alpha.example.org: -## beta.example.org: -## 192.168.1.100: -## 192.168.1.110: -## vars: -## http_port: 8080 - -# Ex 3: You can create hosts using ranges and add children groups and vars to a group -# The child group can define anything you would normally add to a group. -# Hosts in child groups inherit all variables from parent, parents include all hosts in child groups. -# webservers is added as a child group of testing, so all gamma hosts (1-3) are added -# to the 'webservers' group, including gamma3, which is defined in the tree of another parent group. -# All references to webservers will get any hosts defined under webservers. -# References to testing will get all of those hosts plus any host matching www[001:006].example.com - -##webservers: -## hosts: -## gamma1.example.org: -## gamma2.example.org: -##testing: -## hosts: -## www[001:006].example.com: -## vars: -## testing1: value1 -## children: -## webservers: -##other: -## children: -## webservers: -## gamma3.example.org - -# From above, the testing group contains: gamma1.example.org gamma2.example.org gamma3.example.org www001.example.com www002.example.com www003.example.com www004.example.com www005.example.com www006.example.com - -# Ex 4: all vars -# keeping within 'all' group you can define common 'all' vars here with lowest precedence - - -##all: -## vars: -## commontoall: thisvar diff --git a/examples/hosts.yml b/examples/hosts.yml deleted file mode 120000 index bd6024a93be..00000000000 --- a/examples/hosts.yml +++ /dev/null @@ -1 +0,0 @@ -hosts.yaml \ No newline at end of file diff --git a/examples/inventory_script_schema.json b/examples/inventory_script_schema.json deleted file mode 100644 index c68b7f82700..00000000000 --- a/examples/inventory_script_schema.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "$schema": "http://json-schema.org/draft-06/schema#", - "title": "Ansible Inventory", - "description" : "Ansible Inventory for the script inventory plugin", - "type": "object", - "patternProperties": { - "^\\w$":{ - "type": "object", - "properties": { - "hosts": { - "description" : "list of hosts that are part of this group", - "type": "array", - "items": { "type": "string" } - }, - "vars": { - "type": "object", - "description": "Variables to assign to hosts that are part of this group" , - "patternProperties": { - "^\\w$":{ "type": "object", "description" : "Vars for this hosts in this group" } - } - }, - "children": { - "description" : "list of groups that are children of this group, their hosts will be added to this group", - "type": "array", - "items": { "type": "string" } - } - }, - "additionalProperties": false - }, - "_meta":{ - "type": "object", - "description" : "Key that avoids calling the script per host", - "required": ["hostvars"], - "properties": { - "hostvars": { - "type": "object", - "description" : "Each key is a hostname and the value is a dictionary of the variables for that host", - "patternProperties": { - "^\\w$":{ - "type": "object", - "description" : "Hosts with their associated vars", - "patternProperties": { - "^\\w$":{ "type": "object", "description" : "Vars for this host" } - } - } - } - } - }, - "additionalProperties": false - } - }, - "additionalProperties": false -} diff --git a/examples/play.yml b/examples/play.yml deleted file mode 100644 index b0dee7d757f..00000000000 --- a/examples/play.yml +++ /dev/null @@ -1,525 +0,0 @@ -#!/usr/bin/env ansible-playbook -# ^ Trick: the above line can be used to make your play an executable -# you also must add 'x' permissions to the file -# -# this file is based on phred's 'pedantically commented playbook' -# https://github.com/phred/ansible-examples/blob/master/pedantically_commented_playbook.yml -# ---- -# ^^^ YAML documents can begin with the document separator "---" -# and end with the "...", neither is needed for Ansible # as it does not -# support multiple YAML documents per file, but some linters incorrectly insist -# you must have it .... -# -# The '#' is a comment character, so any line starting with it will be ignored by Ansible. - -# Blank lines are ignored, so can be used # to create spacing to your taste. - -# Note about YAML: like Python, cares about whitespace, it requires actual spaces, tabs won't work. -# Indent consistently throughout. -# Two-space or four space indents is what most users prefer, but do whatever you like. -# -# If you're new to YAML, keep in mind that YAML documents, like XML -# documents, represent a tree-like structure of nodes and text. More -# familiar with JSON? Think of YAML as a strict (with spaces) but also more flexible -# JSON (fewer significant characters, e.g., :, "", {}, [] and liberal quoting). -# Also, JSON is a subset of YAML, so most YAML parser can read JSON just the same. -# -# The curious may read more about YAML at: -# http://www.yaml.org/spec/1.1/current.html -# there is a 1.2, but Ansible uses pyyaml which is mostly 1.1 - -# the following line configures 'vim' to handle 2 space indents. -# vim:ff=unix ts=2 sw=2 ai expandtab - -### -# Notice the minus (-) on the line below, this is the start of a 'list' in YAML -# In Ansible this is the 'list of plays' which starts this playbook. -# Plays map the inventory hosts to the tasks, the most minimal play you can have -# just requires 'hosts' - -- hosts: all - ########### - # Play keyword: hosts - # Required: yes - # Description: - # The selection of hosts (or host) that the tasks in this play play should apply to. - # - ## Example values: - # hosts: all -- applies to all hosts - # hosts: host1 -- apply ONLY to the host that inventory defines as 'host1' - # hosts: group1 -- apply to all hosts in group1 - # hosts: group1,group2 -- apply to hosts in group1 & group2 - # hosts: group1,host1 -- hosts in group1 AND host - # - ## now using host patterns (TODO: url) - # hosts: group1,!group3 -- hosts in group1 that are not in group3 - # hosts: group1,&group3 -- hosts in group1 that are also in group3 - # hosts: group1:&group3 -- same as above, but using : instead of , as separator - # hosts: group1:!group2:&group3 -- hosts in group1 what are not in group2 but are also in group3 - # - ## Using a variable value for 'hosts' - # - # You can, in fact, set hosts to a variable, for example: - # - # hosts: '{{mygroups}}' -- apply to all hosts specified in the variable 'mygroups' - # - # This is handy for testing playbooks, running the same playbook against a - # staging environment before running it against production, occasional - # maintenance tasks, and other cases where you want to run the playbook - # against just a few systems rather than a whole group. - # Note that the variable cannot be set in inventory, since we need to know the hosts - # before we can use inventory variables. So normally 'extra vars' are used, as you can - # see below. - # - # If you set hosts as shown above, then you can specify which hosts to - # apply the playbook to on each run as so: - # - # ansible-playbook playbook.yml --extra-vars="mygroups=staging" - # - # Use --extra-vars to set the variable to any combination of groups, hostnames, - # or host patterns just like the examples in the previous section. - # - - name: my heavily commented play - ########### - # Play keyword: name - # Default: play### - # Required: no - # Description: Just a description to document the play - - gather_facts: yes - ########### - # Play keyword: gather_facts - # Default: None - # Required: no - # Description: - # This controls if the play will trigger a 'fact gathering task' (aka 'gather_facts' or 'setup' action) to get information about the remote target. - # These facts normally provide useful variables on which to base decisions and task inputs. For example `ansible_os_distribution` can tell us if - # the target is a RHEL, Ubuntu or FreeBSD machine (among others), number of CPUs, RAM, etc. - # TODO: url to fact gathering - - remote_user: login_user - ########### - # Play keyword: user - # Default: depends on connection plugin, for ssh it is 'current user executing Ansible' - # Required: no - # Description: - # Remote user to login on remote targets and 'normally' execute the tasks as - - become: True - ########### - # Play keyword: become - # Default: False - # Required: no - # Description: - # If True, always use privilege escalation to run tasks from this play, just like passing the - # --become flag to ansible or ansible-playbook. - - - become_user: root - ########### - # Play keyword: become_user - # Default: None - # Required: no - # Description: - # When using privilege escalation this is the user you 'become' after login with the remote_user - # for example you login to the remote as 'login_user' then you 'become' root to execute the tasks - - become_method: sudo - ########### - # Play keyword: become_method - # Default: sudo - # Required: no - # Description: - # When using privilege escalation this chooses the become plugin to use for privilege escalation. - # use `ansible-doc -t become -l` to list all the options. - - connection: ssh - ########### - # Play keyword: connection - # Default: ssh - # Required: no - # Description: - # This sets which connection plugin Ansible will use to try to communicate with the target host. - # notable options are paramiko (python implementation of ssh, mostly useful in corner cases in which the ssh cli - # does not work well with the target. Also 'local' which forces a 'local fork' to execute the task, but normally - # what you really want is `delegate_to: localhost` see examples below in 'Run things locally!' entry. - # use `ansible-doc -t connection -l` to list all the options. - - vars: - ########### - # Play keyword: vars - # Default: none - # Required: no - # Description: - # Mapping of variables defined for this play, normally for use in templates or as variables for tasks. - - # to get the value just use {{color}} to reference that value - color: brown - - # Mapping structures allow complex variables structures, to use you can reference - # the variable name with {{web['memcache']}} when using nested key value or {{web}} - # when using the whole structure.. - web: - memcache: 192.168.1.2 - httpd: apache - - # lists use a slightly different notation {{ mylist[1] }} to get 'b', they are 0 indexed. - mylist: - - a - - b - - c - - # Variables can be dynamically set via Jinja templates, to be filled when consumed. - # - # In this playbook, this will always evaluate to False, because 'color' - # is set to 'brown' above. - # - # When ansible interprets the following, it will first expand 'color' to - # 'brown' and then evaluate 'brown' == 'blue' as a Jinja expression. - is_color_blue: "{{ color == 'blue' }}" - - # TODO: (url variables) - - vars_files: - ########## - # Play keyword: vars_files - # Required: no - # Description: - # Specifies a list of YAML files to load variables from. - # - # Always evaluated after the 'vars' section, no matter which section - # occurs first in the playbook. Examples are below. - # - # Example YAML for a file to be included by vars_files: - # --- - # monitored_by: phobos.mars.nasa.gov - # fish_sticks: "good with custard" - # ... # (END OF DOCUMENT) - # - # Remove the indentation & comments of course, the '---' should be at - # the left margin in the variables file. - # - # Include a file from this absolute path - - /srv/ansible/vars/vars_file.yml - - # Include a file from a path relative to this playbook - - vars/vars_file.yml - - # By the way, variables set in 'vars' or as extra vars are available here. - - vars/{{something}}.yml - - # It's also possible to pass an array of files, in which case - # Ansible will loop over the array and include the first file that - # exists. If none exist, ansible-playbook will halt with an error. - # - # An excellent way to handle platform-specific differences. - - [ 'vars/{{platform}}.yml', vars/default.yml ] - - # Files in vars_files process in order, so later files can - # provide more specific configuration: - - [ 'vars/{{host}}.yml' ] - - # Hey, but if you're doing host-specific variable files, you might - # consider setting the variable for a group in your inventory and - # adding your host to that group. Just a thought. - - - vars_prompt: - ########## - # Play keyword: vars_prompt - # Required: no - # Description: - # A list of variables that Ansible will prompt for manual input each time this playbook - # runs. Used for sensitive data and also things like release numbers that - # vary on each deployment. - # - # Ansible won't prompts for this value if already provided, like when - # passed through --extra-vars, but not from inventory. - # - # Also it won't prompt if it detects that it is a non interactive session. - # For example, when called from cron. - # - - name: passphrase - prompt: "Please enter the passphrase for the SSL certificate" - private: yes - # The input won't be echoed back to the terminal when private (default yes) - - # Not sensitive, but something that should vary on each playbook run. - - name: release_version - prompt: "Please enter a release tag" - private: no - - # you can even have a default - - name: package_version - prompt: "Please enter a package version" - default: '1.0' - - # You can find more advanced features in https://docs.ansible.com/ansible/latest/user_guide/playbooks_prompts.html - - roles: - ########## - # Play keyword: roles - # Required: no - # Description: A list of roles to import and execute in this play. Executes AFTER pre_tasks and play fact gathering, but before 'tasks'. - # TODO url roles + url to 'play stages' - - tasks: - ########## - # Play keyword: tasks - # Required: no - # Description: A list of tasks to perform in this play. Executes AFTER roles and before post_tasks - - # A simple task - # Each task must have an action. 'name' is optional but very useful to document what the task does - - name: Check that the target can execute Ansible tasks - action: ping - - ########## - # Ansible modules do the work!, 'action' is not needed, you can use the 'action itself' as part of the task - - file: path=/tmp/secret mode=0600 owner=root group=root - # - # Format 'action' like above: - # : - # - # Test your parameters using: - # ansible -m -a "" - # - # Documentation for the stock modules: - # http://ansible.github.com/modules.html - - # normally most will want to use 'k: v' notation instead of 'k=v' used above (but useful for adhoc execution). - # while both formats are mostly interchangable, `k: v` is more explicit, 'type friendly' and simpler to escape. - - name: Ensure secret is locked down - file: - path: /tmp/secret - mode: '0600' - owner: root - group: root - - # note that 'action options' are indented inside the option, while 'task keywords' stay on the top level - - ########## - # Use variables in the task! It expands on use. - - name: Paint the server - command: echo {{color}} - - # you can also define variables at the task level - - name: Ensure secret is locked down - file: - path: '{{secret_file}}' - mode: '0600' - owner: root - group: root - vars: - secret_file: /tmp/secret - - ########## - # Trigger handlers when things change! - # - # Most Ansible actions can detect and report when something changed. - # Like if file permissions were not the same as requested, - # a file's content is different or a package was installed (or removed) - # When a change is reported, the task assumes the 'changed' status. - # Ansible can optionally notify one or more Handlers. - # Handlers are like normal tasks, the main difference is that they only - # run when notified. - # A common use is to restart a service after updating it's configuration file. - # https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#handlers-running-operations-on-change - - # TODO: explain handler per stage execution - - # This will call the "Restart Apache" handler whenever 'copy' alters - # the remote httpd.conf. - - name: Update the Apache config - copy: - src: httpd.conf - dest: /etc/httpd/httpd.conf - notify: Restart Apache - - # Here's how to specify more than one handler - - name: Update our app's configuration - copy: - src: myapp.conf - dest: /etc/myapp/production.conf - notify: - - Restart Apache - - Restart Redis - - ########## - # Include tasks from another file! - # - # Ansible can insert a list of tasks from another file. The file - # must represent a list of tasks, which is different than a play. - # - # Task list format: - # --- - # - name: create user - # user: name={{myuser}} color={{color}} - # - # - name: add user to group - # user: name={{myuser}} groups={{hisgroup}} append=true - # ... # (END OF DOCUMENT) - # - # A 'tasks' YAML file represents a list of tasks. Don't use playbook - # YAML for a 'tasks' file. - # - # Remove the indentation & comments of course, the '---' should be at - # the left margin in the variables file. - - # TODO: point at import_playbook, includes and roles - # In this example the user will be 'sklar' - # and 'color' will be 'red' inside new_user.yml - - import_tasks: tasks/new_user.yml - vars: - myuser: sklar - color: red - - # In this example the user will be 'mosh' - # and $color will be 'mauve' inside new_user.yml - - import_tasks: tasks/new_user.yml - vars: - myuser: mosh - color: mauve - - - ########## - # Run a task on each thing in a list! - # - # Ansible provides a simple loop facility. If 'loop' is provided for - # a task, then the task will be run once for each item in the provided - # list. Each iteration will create the 'item' variable with a different value. - - name: Create a file named via variable in /tmp - file: path=/tmp/{{item}} state=touched - loop: - - tangerine - - lemon - - - name: Loop using a variable - file: path=/tmp/{{item}} state=touched - loop: '{{mylist}}' - vars: - # defined here, but could be anywhere before the task runs - # also note that YAML lists can be flush with their key, - # we normally indent for clarity, but this form is also correct. - mylist: - - tangerine - - lemon - ########## - # Conditionally execute tasks! - # - # Sometimes you only want to run an action when a under certain conditions. - # Ansible supports using conditional Jinja expression, executing the task only when 'True'. - # - # If you're trying to run an task only when a value changes, - # consider rewriting the task as a handler and using 'notify' (see below). - # - - name: "shutdown all ubuntu" - command: /sbin/shutdown -t now - when: '{{is_ubuntu|bool}}' - - - name: "shutdown the if host is in the government" - command: /sbin/shutdown -t now - when: "{{inventory_hostname in groups['government']}}" - - # another way to write the same. - - name: "shutdown the if host is in the government" - command: /sbin/shutdown -t now - when: "{{'government' in group_names}}" - - # Ansible has some built in variables, you can check them here (TODO url) - # inventory_hostname is the name of the current host the task is executing for (derived from the hosts: keyword) - # group_names has the list of groups the current host (inventory_hostname) is part of - # groups is a mapping of the inventory groups with the list of hosts that belong to them - - ########## - # Run things as other users! - # - # Each task has optional keywords that control which - # user a task should run as and whether or not to use privilege escalation - # (like sudo or su) to switch to that user. - - - name: login in as postgres and dump all postgres databases - shell: pg_dumpall -w -f /tmp/backup.psql - remote_user: postgres - become: False - - - name: login normally, but sudo to postgres to dump all postgres databases - shell: pg_dumpall -w -f /tmp/backup.psql - become: true - become_user: postgres - become_method: sudo - - ########## - # Run things locally! - # - # Each task can also be delegated to the control host - - name: create tempfile - local_action: shell dd if=/dev/urandom of=/tmp/random.txt count=100 - - # which is equivalent to the following - - name: create tempfile - shell: dd if=/dev/urandom of=/tmp/random.txt count=100 - delegate_to: localhost - # delegate_to can use any target, but for the case above, it is the same as using local_action - # TODO url to delegation and implicit localhost - - handlers: - ########## - # Play keyword: handlers - # Required: no - # Description: - # Handlers are tasks that run when another task has changed something. - # See above for examples on how to trigger them. - # The format to define a handler is exactly the same as for tasks. - # Note that if multiple tasks notify the same handler in a playbook run - # that handler will only run once for that host. - # - # Handlers are referred to by name or using the listen keyword. - # They will be run in the order declared in the playbook. - # For example: if a task were to notify the handlers in reverse order like so: - # - # - task: ensure file does not exist - # file: - # name: /tmp/lock.txt - # state: absent - # notify: - # - Restart application - # - Restart nginx - # - # The "Restart nginx" handler will still run before the "Restart application" - # handler because it is declared first in this playbook. - - # this one can only be called by name - - name: Restart nginx - service: - name: nginx - state: restarted - - # this one can be called by name or via any entry in the listen keyword - - name: redis restarter - service: - name: redis - state: restarted - listen: - - Restart redis - - # Any module can be used for the handler action - # even though this can be triggered multiple ways and times - # it will only execute once per host - - name: restart application that should really be a service - command: /srv/myapp/restart.sh - listen: - - Restart application - - restart myapp - - # It's also possible to include handlers from another file. Structure is - # the same as a tasks file, see the tasks section above for an example. - - import_tasks: handlers/site.yml - - -# NOTE: this is not a complete list of all possible keywords in a play or task (TODO: url playbook object and keywords), just an example of very common options. - -# below is the "totally optional" YAML "End of document" marker. -... diff --git a/examples/plugin_filters.yml b/examples/plugin_filters.yml deleted file mode 100644 index 4495676a4a9..00000000000 --- a/examples/plugin_filters.yml +++ /dev/null @@ -1,6 +0,0 @@ ---- -filter_version: '1.0' -module_rejectlist: - # List the modules to reject here - #- easy_install - #- s3 diff --git a/examples/scripts/ConfigureRemotingForAnsible.ps1 b/examples/scripts/ConfigureRemotingForAnsible.ps1 deleted file mode 100644 index 7cc86abd7ce..00000000000 --- a/examples/scripts/ConfigureRemotingForAnsible.ps1 +++ /dev/null @@ -1,435 +0,0 @@ -#Requires -Version 3.0 - -# Configure a Windows host for remote management with Ansible -# ----------------------------------------------------------- -# -# This script checks the current WinRM (PS Remoting) configuration and makes -# the necessary changes to allow Ansible to connect, authenticate and -# execute PowerShell commands. -# -# IMPORTANT: This script uses self-signed certificates and authentication mechanisms -# that are intended for development environments and evaluation purposes only. -# Production environments and deployments that are exposed on the network should -# use CA-signed certificates and secure authentication mechanisms such as Kerberos. -# -# To run this script in Powershell: -# -# [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 -# $url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1" -# $file = "$env:temp\ConfigureRemotingForAnsible.ps1" -# -# (New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file) -# -# powershell.exe -ExecutionPolicy ByPass -File $file -# -# All events are logged to the Windows EventLog, useful for unattended runs. -# -# Use option -Verbose in order to see the verbose output messages. -# -# Use option -CertValidityDays to specify how long this certificate is valid -# starting from today. So you would specify -CertValidityDays 3650 to get -# a 10-year valid certificate. -# -# Use option -ForceNewSSLCert if the system has been SysPreped and a new -# SSL Certificate must be forced on the WinRM Listener when re-running this -# script. This is necessary when a new SID and CN name is created. -# -# Use option -EnableCredSSP to enable CredSSP as an authentication option. -# -# Use option -DisableBasicAuth to disable basic authentication. -# -# Use option -SkipNetworkProfileCheck to skip the network profile check. -# Without specifying this the script will only run if the device's interfaces -# are in DOMAIN or PRIVATE zones. Provide this switch if you want to enable -# WinRM on a device with an interface in PUBLIC zone. -# -# Use option -SubjectName to specify the CN name of the certificate. This -# defaults to the system's hostname and generally should not be specified. - -# Written by Trond Hindenes -# Updated by Chris Church -# Updated by Michael Crilly -# Updated by Anton Ouzounov -# Updated by Nicolas Simond -# Updated by Dag Wieërs -# Updated by Jordan Borean -# Updated by Erwan Quélin -# Updated by David Norman -# -# Version 1.0 - 2014-07-06 -# Version 1.1 - 2014-11-11 -# Version 1.2 - 2015-05-15 -# Version 1.3 - 2016-04-04 -# Version 1.4 - 2017-01-05 -# Version 1.5 - 2017-02-09 -# Version 1.6 - 2017-04-18 -# Version 1.7 - 2017-11-23 -# Version 1.8 - 2018-02-23 -# Version 1.9 - 2018-09-21 - -# Support -Verbose option -[CmdletBinding()] - -Param ( - [string]$SubjectName = $env:COMPUTERNAME, - [int]$CertValidityDays = 1095, - [switch]$SkipNetworkProfileCheck, - $CreateSelfSignedCert = $true, - [switch]$ForceNewSSLCert, - [switch]$GlobalHttpFirewallAccess, - [switch]$DisableBasicAuth = $false, - [switch]$EnableCredSSP -) - -Function Write-ProgressLog { - $Message = $args[0] - Write-EventLog -LogName Application -Source $EventSource -EntryType Information -EventId 1 -Message $Message -} - -Function Write-VerboseLog { - $Message = $args[0] - Write-Verbose $Message - Write-ProgressLog $Message -} - -Function Write-HostLog { - $Message = $args[0] - Write-Output $Message - Write-ProgressLog $Message -} - -Function New-LegacySelfSignedCert { - Param ( - [string]$SubjectName, - [int]$ValidDays = 1095 - ) - - $hostnonFQDN = $env:computerName - $hostFQDN = [System.Net.Dns]::GetHostByName(($env:computerName)).Hostname - $SignatureAlgorithm = "SHA256" - - $name = New-Object -COM "X509Enrollment.CX500DistinguishedName.1" - $name.Encode("CN=$SubjectName", 0) - - $key = New-Object -COM "X509Enrollment.CX509PrivateKey.1" - $key.ProviderName = "Microsoft Enhanced RSA and AES Cryptographic Provider" - $key.KeySpec = 1 - $key.Length = 4096 - $key.SecurityDescriptor = "D:PAI(A;;0xd01f01ff;;;SY)(A;;0xd01f01ff;;;BA)(A;;0x80120089;;;NS)" - $key.MachineContext = 1 - $key.Create() - - $serverauthoid = New-Object -COM "X509Enrollment.CObjectId.1" - $serverauthoid.InitializeFromValue("1.3.6.1.5.5.7.3.1") - $ekuoids = New-Object -COM "X509Enrollment.CObjectIds.1" - $ekuoids.Add($serverauthoid) - $ekuext = New-Object -COM "X509Enrollment.CX509ExtensionEnhancedKeyUsage.1" - $ekuext.InitializeEncode($ekuoids) - - $cert = New-Object -COM "X509Enrollment.CX509CertificateRequestCertificate.1" - $cert.InitializeFromPrivateKey(2, $key, "") - $cert.Subject = $name - $cert.Issuer = $cert.Subject - $cert.NotBefore = (Get-Date).AddDays(-1) - $cert.NotAfter = $cert.NotBefore.AddDays($ValidDays) - - $SigOID = New-Object -ComObject X509Enrollment.CObjectId - $SigOID.InitializeFromValue(([Security.Cryptography.Oid]$SignatureAlgorithm).Value) - - [string[]] $AlternativeName += $hostnonFQDN - $AlternativeName += $hostFQDN - $IAlternativeNames = New-Object -ComObject X509Enrollment.CAlternativeNames - - foreach ($AN in $AlternativeName) { - $AltName = New-Object -ComObject X509Enrollment.CAlternativeName - $AltName.InitializeFromString(0x3, $AN) - $IAlternativeNames.Add($AltName) - } - - $SubjectAlternativeName = New-Object -ComObject X509Enrollment.CX509ExtensionAlternativeNames - $SubjectAlternativeName.InitializeEncode($IAlternativeNames) - - [String[]]$KeyUsage = ("DigitalSignature", "KeyEncipherment") - $KeyUsageObj = New-Object -ComObject X509Enrollment.CX509ExtensionKeyUsage - $KeyUsageObj.InitializeEncode([int][Security.Cryptography.X509Certificates.X509KeyUsageFlags]($KeyUsage)) - $KeyUsageObj.Critical = $true - - $cert.X509Extensions.Add($KeyUsageObj) - $cert.X509Extensions.Add($ekuext) - $cert.SignatureInformation.HashAlgorithm = $SigOID - $CERT.X509Extensions.Add($SubjectAlternativeName) - $cert.Encode() - - $enrollment = New-Object -COM "X509Enrollment.CX509Enrollment.1" - $enrollment.InitializeFromRequest($cert) - $certdata = $enrollment.CreateRequest(0) - $enrollment.InstallResponse(2, $certdata, 0, "") - - # extract/return the thumbprint from the generated cert - $parsed_cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 - $parsed_cert.Import([System.Text.Encoding]::UTF8.GetBytes($certdata)) - - return $parsed_cert.Thumbprint -} - -Function Enable-GlobalHttpFirewallAccess { - Write-Verbose "Forcing global HTTP firewall access" - # this is a fairly naive implementation; could be more sophisticated about rule matching/collapsing - $fw = New-Object -ComObject HNetCfg.FWPolicy2 - - # try to find/enable the default rule first - $add_rule = $false - $matching_rules = $fw.Rules | Where-Object { $_.Name -eq "Windows Remote Management (HTTP-In)" } - $rule = $null - If ($matching_rules) { - If ($matching_rules -isnot [Array]) { - Write-Verbose "Editing existing single HTTP firewall rule" - $rule = $matching_rules - } - Else { - # try to find one with the All or Public profile first - Write-Verbose "Found multiple existing HTTP firewall rules..." - $rule = $matching_rules | ForEach-Object { $_.Profiles -band 4 }[0] - - If (-not $rule -or $rule -is [Array]) { - Write-Verbose "Editing an arbitrary single HTTP firewall rule (multiple existed)" - # oh well, just pick the first one - $rule = $matching_rules[0] - } - } - } - - If (-not $rule) { - Write-Verbose "Creating a new HTTP firewall rule" - $rule = New-Object -ComObject HNetCfg.FWRule - $rule.Name = "Windows Remote Management (HTTP-In)" - $rule.Description = "Inbound rule for Windows Remote Management via WS-Management. [TCP 5985]" - $add_rule = $true - } - - $rule.Profiles = 0x7FFFFFFF - $rule.Protocol = 6 - $rule.LocalPorts = 5985 - $rule.RemotePorts = "*" - $rule.LocalAddresses = "*" - $rule.RemoteAddresses = "*" - $rule.Enabled = $true - $rule.Direction = 1 - $rule.Action = 1 - $rule.Grouping = "Windows Remote Management" - - If ($add_rule) { - $fw.Rules.Add($rule) - } - - Write-Verbose "HTTP firewall rule $($rule.Name) updated" -} - -# Setup error handling. -Trap { - $_ - Exit 1 -} -$ErrorActionPreference = "Stop" - -# Get the ID and security principal of the current user account -$myWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent() -$myWindowsPrincipal = new-object System.Security.Principal.WindowsPrincipal($myWindowsID) - -# Get the security principal for the Administrator role -$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator - -# Check to see if we are currently running "as Administrator" -if (-Not $myWindowsPrincipal.IsInRole($adminRole)) { - Write-Output "ERROR: You need elevated Administrator privileges in order to run this script." - Write-Output " Start Windows PowerShell by using the Run as Administrator option." - Exit 2 -} - -$EventSource = $MyInvocation.MyCommand.Name -If (-Not $EventSource) { - $EventSource = "Powershell CLI" -} - -If ([System.Diagnostics.EventLog]::Exists('Application') -eq $False -or [System.Diagnostics.EventLog]::SourceExists($EventSource) -eq $False) { - New-EventLog -LogName Application -Source $EventSource -} - -# Detect PowerShell version. -If ($PSVersionTable.PSVersion.Major -lt 3) { - Write-ProgressLog "PowerShell version 3 or higher is required." - Throw "PowerShell version 3 or higher is required." -} - -# Find and start the WinRM service. -Write-Verbose "Verifying WinRM service." -If (!(Get-Service "WinRM")) { - Write-ProgressLog "Unable to find the WinRM service." - Throw "Unable to find the WinRM service." -} -ElseIf ((Get-Service "WinRM").Status -ne "Running") { - Write-Verbose "Setting WinRM service to start automatically on boot." - Set-Service -Name "WinRM" -StartupType Automatic - Write-ProgressLog "Set WinRM service to start automatically on boot." - Write-Verbose "Starting WinRM service." - Start-Service -Name "WinRM" -ErrorAction Stop - Write-ProgressLog "Started WinRM service." - -} - -# WinRM should be running; check that we have a PS session config. -If (!(Get-PSSessionConfiguration -Verbose:$false) -or (!(Get-ChildItem WSMan:\localhost\Listener))) { - If ($SkipNetworkProfileCheck) { - Write-Verbose "Enabling PS Remoting without checking Network profile." - Enable-PSRemoting -SkipNetworkProfileCheck -Force -ErrorAction Stop - Write-ProgressLog "Enabled PS Remoting without checking Network profile." - } - Else { - Write-Verbose "Enabling PS Remoting." - Enable-PSRemoting -Force -ErrorAction Stop - Write-ProgressLog "Enabled PS Remoting." - } -} -Else { - Write-Verbose "PS Remoting is already enabled." -} - -# Ensure LocalAccountTokenFilterPolicy is set to 1 -# https://github.com/ansible/ansible/issues/42978 -$token_path = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -$token_prop_name = "LocalAccountTokenFilterPolicy" -$token_key = Get-Item -Path $token_path -$token_value = $token_key.GetValue($token_prop_name, $null) -if ($token_value -ne 1) { - Write-Verbose "Setting LocalAccountTOkenFilterPolicy to 1" - if ($null -ne $token_value) { - Remove-ItemProperty -Path $token_path -Name $token_prop_name - } - New-ItemProperty -Path $token_path -Name $token_prop_name -Value 1 -PropertyType DWORD > $null -} - -# Make sure there is a SSL listener. -$listeners = Get-ChildItem WSMan:\localhost\Listener -If (!($listeners | Where-Object { $_.Keys -like "TRANSPORT=HTTPS" })) { - # We cannot use New-SelfSignedCertificate on 2012R2 and earlier - $thumbprint = New-LegacySelfSignedCert -SubjectName $SubjectName -ValidDays $CertValidityDays - Write-HostLog "Self-signed SSL certificate generated; thumbprint: $thumbprint" - - # Create the hashtables of settings to be used. - $valueset = @{ - Hostname = $SubjectName - CertificateThumbprint = $thumbprint - } - - $selectorset = @{ - Transport = "HTTPS" - Address = "*" - } - - Write-Verbose "Enabling SSL listener." - New-WSManInstance -ResourceURI 'winrm/config/Listener' -SelectorSet $selectorset -ValueSet $valueset - Write-ProgressLog "Enabled SSL listener." -} -Else { - Write-Verbose "SSL listener is already active." - - # Force a new SSL cert on Listener if the $ForceNewSSLCert - If ($ForceNewSSLCert) { - - # We cannot use New-SelfSignedCertificate on 2012R2 and earlier - $thumbprint = New-LegacySelfSignedCert -SubjectName $SubjectName -ValidDays $CertValidityDays - Write-HostLog "Self-signed SSL certificate generated; thumbprint: $thumbprint" - - $valueset = @{ - CertificateThumbprint = $thumbprint - Hostname = $SubjectName - } - - # Delete the listener for SSL - $selectorset = @{ - Address = "*" - Transport = "HTTPS" - } - Remove-WSManInstance -ResourceURI 'winrm/config/Listener' -SelectorSet $selectorset - - # Add new Listener with new SSL cert - New-WSManInstance -ResourceURI 'winrm/config/Listener' -SelectorSet $selectorset -ValueSet $valueset - } -} - -# Check for basic authentication. -$basicAuthSetting = Get-ChildItem WSMan:\localhost\Service\Auth | Where-Object { $_.Name -eq "Basic" } - -If ($DisableBasicAuth) { - If (($basicAuthSetting.Value) -eq $true) { - Write-Verbose "Disabling basic auth support." - Set-Item -Path "WSMan:\localhost\Service\Auth\Basic" -Value $false - Write-ProgressLog "Disabled basic auth support." - } - Else { - Write-Verbose "Basic auth is already disabled." - } -} -Else { - If (($basicAuthSetting.Value) -eq $false) { - Write-Verbose "Enabling basic auth support." - Set-Item -Path "WSMan:\localhost\Service\Auth\Basic" -Value $true - Write-ProgressLog "Enabled basic auth support." - } - Else { - Write-Verbose "Basic auth is already enabled." - } -} - -# If EnableCredSSP if set to true -If ($EnableCredSSP) { - # Check for CredSSP authentication - $credsspAuthSetting = Get-ChildItem WSMan:\localhost\Service\Auth | Where-Object { $_.Name -eq "CredSSP" } - If (($credsspAuthSetting.Value) -eq $false) { - Write-Verbose "Enabling CredSSP auth support." - Enable-WSManCredSSP -role server -Force - Write-ProgressLog "Enabled CredSSP auth support." - } -} - -If ($GlobalHttpFirewallAccess) { - Enable-GlobalHttpFirewallAccess -} - -# Configure firewall to allow WinRM HTTPS connections. -$fwtest1 = netsh advfirewall firewall show rule name="Allow WinRM HTTPS" -$fwtest2 = netsh advfirewall firewall show rule name="Allow WinRM HTTPS" profile=any -If ($fwtest1.count -lt 5) { - Write-Verbose "Adding firewall rule to allow WinRM HTTPS." - netsh advfirewall firewall add rule profile=any name="Allow WinRM HTTPS" dir=in localport=5986 protocol=TCP action=allow - Write-ProgressLog "Added firewall rule to allow WinRM HTTPS." -} -ElseIf (($fwtest1.count -ge 5) -and ($fwtest2.count -lt 5)) { - Write-Verbose "Updating firewall rule to allow WinRM HTTPS for any profile." - netsh advfirewall firewall set rule name="Allow WinRM HTTPS" new profile=any - Write-ProgressLog "Updated firewall rule to allow WinRM HTTPS for any profile." -} -Else { - Write-Verbose "Firewall rule already exists to allow WinRM HTTPS." -} - -# Test a remoting connection to localhost, which should work. -$httpResult = Invoke-Command -ComputerName "localhost" -ScriptBlock { $using:env:COMPUTERNAME } -ErrorVariable httpError -ErrorAction SilentlyContinue -$httpsOptions = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck - -$httpsResult = New-PSSession -UseSSL -ComputerName "localhost" -SessionOption $httpsOptions -ErrorVariable httpsError -ErrorAction SilentlyContinue - -If ($httpResult -and $httpsResult) { - Write-Verbose "HTTP: Enabled | HTTPS: Enabled" -} -ElseIf ($httpsResult -and !$httpResult) { - Write-Verbose "HTTP: Disabled | HTTPS: Enabled" -} -ElseIf ($httpResult -and !$httpsResult) { - Write-Verbose "HTTP: Enabled | HTTPS: Disabled" -} -Else { - Write-ProgressLog "Unable to establish an HTTP or HTTPS remoting session." - Throw "Unable to establish an HTTP or HTTPS remoting session." -} -Write-VerboseLog "PS Remoting has been successfully configured for Ansible." diff --git a/examples/scripts/my_test.py b/examples/scripts/my_test.py deleted file mode 100644 index 16aac8934dc..00000000000 --- a/examples/scripts/my_test.py +++ /dev/null @@ -1,134 +0,0 @@ -#!/usr/bin/python - -# Copyright: (c) 2018, Terry Jones -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -DOCUMENTATION = r''' ---- -module: my_test - -short_description: This is my test module - -# If this is part of a collection, you need to use semantic versioning, -# i.e. the version is of the form "2.5.0" and not "2.4". -version_added: "1.0.0" - -description: This is my longer description explaining my test module. - -options: - name: - description: This is the message to send to the test module. - required: true - type: str - new: - description: - - Control to demo if the result of this module is changed or not. - - Parameter description can be a list as well. - required: false - type: bool -# Specify this value according to your collection -# in format of namespace.collection.doc_fragment_name -extends_documentation_fragment: - - my_namespace.my_collection.my_doc_fragment_name - -author: - - Your Name (@yourGitHubHandle) -''' - -EXAMPLES = r''' -# Pass in a message -- name: Test with a message - my_namespace.my_collection.my_test: - name: hello world - -# pass in a message and have changed true -- name: Test with a message and changed output - my_namespace.my_collection.my_test: - name: hello world - new: true - -# fail the module -- name: Test failure of the module - my_namespace.my_collection.my_test: - name: fail me -''' - -RETURN = r''' -# These are examples of possible return values, and in general should use other names for return values. -original_message: - description: The original name param that was passed in. - type: str - returned: always - sample: 'hello world' -message: - description: The output message that the test module generates. - type: str - returned: always - sample: 'goodbye' -''' - -from ansible.module_utils.basic import AnsibleModule - - -def run_module(): - # define available arguments/parameters a user can pass to the module - module_args = dict( - name=dict(type='str', required=True), - new=dict(type='bool', required=False, default=False) - ) - - # seed the result dict in the object - # we primarily care about changed and state - # changed is if this module effectively modified the target - # state will include any data that you want your module to pass back - # for consumption, for example, in a subsequent task - result = dict( - changed=False, - original_message='', - message='' - ) - - # the AnsibleModule object will be our abstraction working with Ansible - # this includes instantiation, a couple of common attr would be the - # args/params passed to the execution, as well as if the module - # supports check mode - module = AnsibleModule( - argument_spec=module_args, - supports_check_mode=True - ) - - # if the user is working with this module in only check mode we do not - # want to make any changes to the environment, just return the current - # state with no modifications - if module.check_mode: - module.exit_json(**result) - - # manipulate or modify the state as needed (this is going to be the - # part where your module will do what it needs to do) - result['original_message'] = module.params['name'] - result['message'] = 'goodbye' - - # use whatever logic you need to determine whether or not this module - # made any modifications to your target - if module.params['new']: - result['changed'] = True - - # during the execution of the module, if there is an exception or a - # conditional state that effectively causes a failure, run - # AnsibleModule.fail_json() to pass in the message and the result - if module.params['name'] == 'fail me': - module.fail_json(msg='You requested this to fail', **result) - - # in the event of a successful module execution, you will want to - # simple AnsibleModule.exit_json(), passing the key/value results - module.exit_json(**result) - - -def main(): - run_module() - - -if __name__ == '__main__': - main() diff --git a/examples/scripts/my_test_facts.py b/examples/scripts/my_test_facts.py deleted file mode 100644 index 555f878efb4..00000000000 --- a/examples/scripts/my_test_facts.py +++ /dev/null @@ -1,96 +0,0 @@ -#!/usr/bin/python - -# Copyright: (c) 2020, Your Name -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -DOCUMENTATION = r''' ---- -module: my_test_facts - -short_description: This is my test facts module - -version_added: "1.0.0" - -description: This is my longer description explaining my test facts module. - -author: - - Your Name (@yourGitHubHandle) -''' - -EXAMPLES = r''' -- name: Return ansible_facts - my_namespace.my_collection.my_test_facts: -''' - -RETURN = r''' -# These are examples of possible return values, and in general should use other names for return values. -ansible_facts: - description: Facts to add to ansible_facts. - returned: always - type: dict - contains: - foo: - description: Foo facts about operating system. - type: str - returned: when operating system foo fact is present - sample: 'bar' - answer: - description: - - Answer facts about operating system. - - This description can be a list as well. - type: str - returned: when operating system answer fact is present - sample: '42' -''' - -from ansible.module_utils.basic import AnsibleModule - - -def run_module(): - # define available arguments/parameters a user can pass to the module - module_args = dict() - - # seed the result dict in the object - # we primarily care about changed and state - # changed is if this module effectively modified the target - # state will include any data that you want your module to pass back - # for consumption, for example, in a subsequent task - result = dict( - changed=False, - ansible_facts=dict(), - ) - - # the AnsibleModule object will be our abstraction working with Ansible - # this includes instantiation, a couple of common attr would be the - # args/params passed to the execution, as well as if the module - # supports check mode - module = AnsibleModule( - argument_spec=module_args, - supports_check_mode=True - ) - - # if the user is working with this module in only check mode we do not - # want to make any changes to the environment, just return the current - # state with no modifications - if module.check_mode: - module.exit_json(**result) - - # manipulate or modify the state as needed (this is going to be the - # part where your module will do what it needs to do) - result['ansible_facts'] = { - 'foo': 'bar', - 'answer': '42', - } - # in the event of a successful module execution, you will want to - # simple AnsibleModule.exit_json(), passing the key/value results - module.exit_json(**result) - - -def main(): - run_module() - - -if __name__ == '__main__': - main() diff --git a/examples/scripts/my_test_info.py b/examples/scripts/my_test_info.py deleted file mode 100644 index 64da3c7b8a8..00000000000 --- a/examples/scripts/my_test_info.py +++ /dev/null @@ -1,111 +0,0 @@ -#!/usr/bin/python - -# Copyright: (c) 2020, Your Name -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -DOCUMENTATION = r''' ---- -module: my_test_info - -short_description: This is my test info module - -version_added: "1.0.0" - -description: This is my longer description explaining my test info module. - -options: - name: - description: This is the message to send to the test module. - required: true - type: str - -author: - - Your Name (@yourGitHubHandle) -''' - -EXAMPLES = r''' -# Pass in a message -- name: Test with a message - my_namespace.my_collection.my_test_info: - name: hello world -''' - -RETURN = r''' -# These are examples of possible return values, and in general should use other names for return values. -original_message: - description: The original name param that was passed in. - type: str - returned: always - sample: 'hello world' -message: - description: The output message that the test module generates. - type: str - returned: always - sample: 'goodbye' -my_useful_info: - description: The dictionary containing information about your system. - type: dict - returned: always - sample: { - 'foo': 'bar', - 'answer': 42, - } -''' - -from ansible.module_utils.basic import AnsibleModule - - -def run_module(): - # define available arguments/parameters a user can pass to the module - module_args = dict( - name=dict(type='str', required=True), - ) - - # seed the result dict in the object - # we primarily care about changed and state - # changed is if this module effectively modified the target - # state will include any data that you want your module to pass back - # for consumption, for example, in a subsequent task - result = dict( - changed=False, - original_message='', - message='', - my_useful_info={}, - ) - - # the AnsibleModule object will be our abstraction working with Ansible - # this includes instantiation, a couple of common attr would be the - # args/params passed to the execution, as well as if the module - # supports check mode - module = AnsibleModule( - argument_spec=module_args, - supports_check_mode=True - ) - - # if the user is working with this module in only check mode we do not - # want to make any changes to the environment, just return the current - # state with no modifications - if module.check_mode: - module.exit_json(**result) - - # manipulate or modify the state as needed (this is going to be the - # part where your module will do what it needs to do) - result['original_message'] = module.params['name'] - result['message'] = 'goodbye' - result['my_useful_info'] = { - 'foo': 'bar', - 'answer': 42, - } - # in the event of a successful module execution, you will want to - # simple AnsibleModule.exit_json(), passing the key/value results - module.exit_json(**result) - - -def main(): - run_module() - - -if __name__ == '__main__': - main() diff --git a/examples/scripts/upgrade_to_ps3.ps1 b/examples/scripts/upgrade_to_ps3.ps1 deleted file mode 100644 index 64867bede89..00000000000 --- a/examples/scripts/upgrade_to_ps3.ps1 +++ /dev/null @@ -1,84 +0,0 @@ - -# Powershell script to upgrade a PowerShell 2.0 system to PowerShell 3.0 -# based on http://occasionalutility.blogspot.com/2013/11/everyday-powershell-part-7-powershell.html -# -# some Ansible modules that may use Powershell 3 features, so systems may need -# to be upgraded. This may be used by a sample playbook. Refer to the windows -# documentation on docs.ansible.com for details. -# -# - hosts: windows -# tasks: -# - script: upgrade_to_ps3.ps1 - -# Get version of OS - -# 6.0 is 2008 -# 6.1 is 2008 R2 -# 6.2 is 2012 -# 6.3 is 2012 R2 - - -if ($PSVersionTable.psversion.Major -ge 3) { - Write-Output "Powershell 3 Installed already; You don't need this" - Exit -} - -$powershellpath = "C:\powershell" - -function download-file { - param ([string]$path, [string]$local) - $client = new-object system.net.WebClient - $client.Headers.Add("user-agent", "PowerShell") - $client.downloadfile($path, $local) -} - -if (!(test-path $powershellpath)) { - New-Item -ItemType directory -Path $powershellpath -} - - -# .NET Framework 4.0 is necessary. - -#if (($PSVersionTable.CLRVersion.Major) -lt 2) -#{ -# $DownloadUrl = "http://download.microsoft.com/download/B/A/4/BA4A7E71-2906-4B2D-A0E1-80CF16844F5F/dotNetFx45_Full_x86_x64.exe" -# $FileName = $DownLoadUrl.Split('/')[-1] -# download-file $downloadurl "$powershellpath\$filename" -# ."$powershellpath\$filename" /quiet /norestart -#} - -#You may need to reboot after the .NET install if so just run the script again. - -# If the Operating System is above 6.2, then you already have PowerShell Version > 3 -if ([Environment]::OSVersion.Version.Major -gt 6) { - Write-Output "OS is new; upgrade not needed." - Exit -} - - -$osminor = [environment]::OSVersion.Version.Minor - -$architecture = $ENV:PROCESSOR_ARCHITECTURE - -if ($architecture -eq "AMD64") { - $architecture = "x64" -} -else { - $architecture = "x86" -} - -if ($osminor -eq 1) { - $DownloadUrl = "http://download.microsoft.com/download/E/7/6/E76850B8-DA6E-4FF5-8CCE-A24FC513FD16/Windows6.1-KB2506143-" + $architecture + ".msu" -} -elseif ($osminor -eq 0) { - $DownloadUrl = "http://download.microsoft.com/download/E/7/6/E76850B8-DA6E-4FF5-8CCE-A24FC513FD16/Windows6.0-KB2506146-" + $architecture + ".msu" -} -else { - # Nothing to do; In theory this point will never be reached. - Exit -} - -$FileName = $DownLoadUrl.Split('/')[-1] -download-file $downloadurl "$powershellpath\$filename" - -Start-Process -FilePath "$powershellpath\$filename" -ArgumentList /quiet diff --git a/examples/scripts/uptime.py b/examples/scripts/uptime.py deleted file mode 100755 index d77a5fb5660..00000000000 --- a/examples/scripts/uptime.py +++ /dev/null @@ -1,130 +0,0 @@ -#!/usr/bin/env python - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import json -import shutil - -import ansible.constants as C -from ansible.executor.task_queue_manager import TaskQueueManager -from ansible.module_utils.common.collections import ImmutableDict -from ansible.inventory.manager import InventoryManager -from ansible.parsing.dataloader import DataLoader -from ansible.playbook.play import Play -from ansible.plugins.callback import CallbackBase -from ansible.vars.manager import VariableManager -from ansible import context - - -# Create a callback plugin so we can capture the output -class ResultsCollectorJSONCallback(CallbackBase): - """A sample callback plugin used for performing an action as results come in. - - If you want to collect all results into a single object for processing at - the end of the execution, look into utilizing the ``json`` callback plugin - or writing your own custom callback plugin. - """ - - def __init__(self, *args, **kwargs): - super(ResultsCollectorJSONCallback, self).__init__(*args, **kwargs) - self.host_ok = {} - self.host_unreachable = {} - self.host_failed = {} - - def v2_runner_on_unreachable(self, result): - host = result._host - self.host_unreachable[host.get_name()] = result - - def v2_runner_on_ok(self, result, *args, **kwargs): - """Print a json representation of the result. - - Also, store the result in an instance attribute for retrieval later - """ - host = result._host - self.host_ok[host.get_name()] = result - print(json.dumps({host.name: result._result}, indent=4)) - - def v2_runner_on_failed(self, result, *args, **kwargs): - host = result._host - self.host_failed[host.get_name()] = result - - -def main(): - host_list = ['localhost', 'www.example.com', 'www.google.com'] - # since the API is constructed for CLI it expects certain options to always be set in the context object - context.CLIARGS = ImmutableDict(connection='smart', module_path=['/to/mymodules', '/usr/share/ansible'], forks=10, become=None, - become_method=None, become_user=None, check=False, diff=False, verbosity=0) - # required for - # https://github.com/ansible/ansible/blob/devel/lib/ansible/inventory/manager.py#L204 - sources = ','.join(host_list) - if len(host_list) == 1: - sources += ',' - - # initialize needed objects - loader = DataLoader() # Takes care of finding and reading yaml, json and ini files - passwords = dict(vault_pass='secret') - - # Instantiate our ResultsCollectorJSONCallback for handling results as they come in. Ansible expects this to be one of its main display outlets - results_callback = ResultsCollectorJSONCallback() - - # create inventory, use path to host config file as source or hosts in a comma separated string - inventory = InventoryManager(loader=loader, sources=sources) - - # variable manager takes care of merging all the different sources to give you a unified view of variables available in each context - variable_manager = VariableManager(loader=loader, inventory=inventory) - - # instantiate task queue manager, which takes care of forking and setting up all objects to iterate over host list and tasks - # IMPORTANT: This also adds library dirs paths to the module loader - # IMPORTANT: and so it must be initialized before calling `Play.load()`. - tqm = TaskQueueManager( - inventory=inventory, - variable_manager=variable_manager, - loader=loader, - passwords=passwords, - stdout_callback=results_callback, # Use our custom callback instead of the ``default`` callback plugin, which prints to stdout - ) - - # create data structure that represents our play, including tasks, this is basically what our YAML loader does internally. - play_source = dict( - name="Ansible Play", - hosts=host_list, - gather_facts='no', - tasks=[ - dict(action=dict(module='shell', args='ls'), register='shell_out'), - dict(action=dict(module='debug', args=dict(msg='{{shell_out.stdout}}'))), - dict(action=dict(module='command', args=dict(cmd='/usr/bin/uptime'))), - ] - ) - - # Create play object, playbook objects use .load instead of init or new methods, - # this will also automatically create the task objects from the info provided in play_source - play = Play().load(play_source, variable_manager=variable_manager, loader=loader) - - # Actually run it - try: - result = tqm.run(play) # most interesting data for a play is actually sent to the callback's methods - finally: - # we always need to cleanup child procs and the structures we use to communicate with them - tqm.cleanup() - if loader: - loader.cleanup_all_tmp_files() - - # Remove ansible tmpdir - shutil.rmtree(C.DEFAULT_LOCAL_TMP, True) - - print("UP ***********") - for host, result in results_callback.host_ok.items(): - print('{0} >>> {1}'.format(host, result._result['stdout'])) - - print("FAILED *******") - for host, result in results_callback.host_failed.items(): - print('{0} >>> {1}'.format(host, result._result['msg'])) - - print("DOWN *********") - for host, result in results_callback.host_unreachable.items(): - print('{0} >>> {1}'.format(host, result._result['msg'])) - - -if __name__ == '__main__': - main() diff --git a/hacking/build-ansible.py b/hacking/build-ansible.py deleted file mode 100755 index 717cf1c1ce0..00000000000 --- a/hacking/build-ansible.py +++ /dev/null @@ -1,130 +0,0 @@ -#!/usr/bin/env python -# coding: utf-8 -# PYTHON_ARGCOMPLETE_OK -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -import argparse -import importlib -import inspect -import os.path -import pkgutil -import sys -import typing as t - -try: - import argcomplete -except ImportError: - argcomplete = None - -C = t.TypeVar('C') - - -def build_lib_path(this_script=__file__): - """Return path to the common build library directory.""" - hacking_dir = os.path.dirname(this_script) - libdir = os.path.abspath(os.path.join(hacking_dir, 'build_library')) - - return libdir - - -def ansible_lib_path(this_script=__file__): - """Return path to the common build library directory.""" - hacking_dir = os.path.dirname(this_script) - libdir = os.path.abspath(os.path.join(hacking_dir, '..', 'lib')) - - return libdir - - -sys.path.insert(0, ansible_lib_path()) -sys.path.insert(0, build_lib_path()) - - -from build_ansible import commands, errors - - -def create_arg_parser(program_name): - """ - Creates a command line argument parser - - :arg program_name: The name of the script. Used in help texts - """ - parser = argparse.ArgumentParser(prog=program_name, - description="Implements utilities to build Ansible") - return parser - - -def load(package: str, subclasses: t.Type[C]) -> list[t.Type[C]]: - """Load modules in the specified package and return concrete types that derive from the specified base class.""" - for module in pkgutil.iter_modules(importlib.import_module(package).__path__, f'{package}.'): - try: - importlib.import_module(module.name) - except ImportError: - pass # ignore plugins which are missing dependencies - - types: set[t.Type[C]] = set() - queue: list[t.Type[C]] = [subclasses] - - while queue: - for child in queue.pop().__subclasses__(): - queue.append(child) - - if not inspect.isabstract(child): - types.add(child) - - return sorted(types, key=lambda sc: sc.__name__) - - -def main(): - """ - Start our run. - - "It all starts here" - """ - subcommands = load('build_ansible.command_plugins', subclasses=commands.Command) - - arg_parser = create_arg_parser(os.path.basename(sys.argv[0])) - arg_parser.add_argument('--debug', dest='debug', required=False, default=False, - action='store_true', - help='Show tracebacks and other debugging information') - subparsers = arg_parser.add_subparsers(title='Subcommands', dest='command', - help='for help use build-ansible.py SUBCOMMANDS -h') - - for subcommand in subcommands: - subcommand.init_parser(subparsers.add_parser) - - if argcomplete: - argcomplete.autocomplete(arg_parser) - - args = arg_parser.parse_args(sys.argv[1:]) - if args.command is None: - print('Please specify a subcommand to run') - sys.exit(1) - - for subcommand in subcommands: - if subcommand.name == args.command: - command = subcommand - break - else: - # Note: We should never trigger this because argparse should shield us from it - print('Error: {0} was not a recognized subcommand'.format(args.command)) - sys.exit(1) - - try: - retval = command.main(args) - except (errors.DependencyError, errors.MissingUserInput, errors.InvalidUserInput) as e: - print(e) - if args.debug: - raise - sys.exit(2) - - sys.exit(retval) - - -if __name__ == '__main__': - main() diff --git a/hacking/build_library/__init__.py b/hacking/build_library/__init__.py deleted file mode 100644 index e69de29bb2d..00000000000 diff --git a/hacking/build_library/build_ansible/__init__.py b/hacking/build_library/build_ansible/__init__.py deleted file mode 100644 index e69de29bb2d..00000000000 diff --git a/hacking/build_library/build_ansible/change_detection.py b/hacking/build_library/build_ansible/change_detection.py deleted file mode 100644 index 22e21d3c253..00000000000 --- a/hacking/build_library/build_ansible/change_detection.py +++ /dev/null @@ -1,33 +0,0 @@ -# Copyright: (c) 2018, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -def update_file_if_different(filename, b_data): - """ - Replace file content only if content is different. - - This preserves timestamps in case the file content has not changed. It performs multiple - operations on the file so it is not atomic and may be slower than simply writing to the file. - - :arg filename: The filename to write to - :b_data: Byte string containing the data to write to the file - """ - try: - with open(filename, 'rb') as f: - b_data_old = f.read() - except IOError as e: - if e.errno != 2: - raise - # File did not exist, set b_data_old to a sentinel value so that - # b_data gets written to the filename - b_data_old = None - - if b_data_old != b_data: - with open(filename, 'wb') as f: - f.write(b_data) - return True - - return False diff --git a/hacking/build_library/build_ansible/command_plugins/collection_meta.py b/hacking/build_library/build_ansible/command_plugins/collection_meta.py deleted file mode 100644 index 5c379a1d710..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/collection_meta.py +++ /dev/null @@ -1,72 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import os -import os.path -import pathlib - -import yaml -from ansible.module_utils.six import string_types -from ansible.module_utils.common.text.converters import to_bytes -from antsibull_docs.jinja2.environment import doc_environment - -# Pylint doesn't understand Python3 namespace modules. -from ..change_detection import update_file_if_different # pylint: disable=relative-beyond-top-level -from ..commands import Command # pylint: disable=relative-beyond-top-level - - -DEFAULT_TEMPLATE_FILE = 'collections_galaxy_meta.rst.j2' -DEFAULT_TEMPLATE_DIR = pathlib.Path(__file__).parents[4] / 'docs/templates' - - -def normalize_options(options): - """Normalize the options to make for easy templating""" - for opt in options: - if isinstance(opt['description'], string_types): - opt['description'] = [opt['description']] - - -class DocumentCollectionMeta(Command): - name = 'collection-meta' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, description='Generate collection galaxy.yml documentation from shared metadata') - parser.add_argument("-t", "--template-file", action="store", dest="template_file", - default=DEFAULT_TEMPLATE_FILE, - help="Jinja2 template to use for the config") - parser.add_argument("-T", "--template-dir", action="store", dest="template_dir", - default=str(DEFAULT_TEMPLATE_DIR), - help="directory containing Jinja2 templates") - parser.add_argument("-o", "--output-dir", action="store", dest="output_dir", default='/tmp/', - help="Output directory for rst files") - parser.add_argument("collection_defs", metavar="COLLECTION-OPTION-DEFINITIONS.yml", type=str, - help="Source for collection metadata option docs") - - @staticmethod - def main(args): - output_dir = os.path.abspath(args.output_dir) - template_file_full_path = os.path.abspath(os.path.join(args.template_dir, args.template_file)) - template_file = os.path.basename(template_file_full_path) - template_dir = os.path.dirname(template_file_full_path) - - with open(args.collection_defs) as f: - options = yaml.safe_load(f) - - normalize_options(options) - - env = doc_environment(template_dir) - - template = env.get_template(template_file) - output_name = os.path.join(output_dir, template_file.replace('.j2', '')) - temp_vars = {'options': options} - - data = to_bytes(template.render(temp_vars)) - update_file_if_different(output_name, data) - - return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/docs_build.py b/hacking/build_library/build_ansible/command_plugins/docs_build.py deleted file mode 100644 index 67a4aeab872..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/docs_build.py +++ /dev/null @@ -1,255 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2020, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import absolute_import, division, print_function - -import glob -import os -import os.path -import pathlib -import shutil -from tempfile import TemporaryDirectory - -import yaml - -from ansible.release import __version__ as ansible_core__version__ - -# Pylint doesn't understand Python3 namespace modules. -# pylint: disable=relative-beyond-top-level -from ..commands import Command -from ..errors import InvalidUserInput -# pylint: enable=relative-beyond-top-level - - -__metaclass__ = type - - -DEFAULT_TOP_DIR = pathlib.Path(__file__).parents[4] -DEFAULT_OUTPUT_DIR = pathlib.Path(__file__).parents[4] / 'docs/docsite' - - -class NoSuchFile(Exception): - """An expected file was not found.""" - - -# -# Helpers -# - -def find_latest_ansible_dir(build_data_working): - """Find the most recent ansible major version.""" - # imports here so that they don't cause unnecessary deps for all of the plugins - from packaging.version import InvalidVersion, Version - - ansible_directories = glob.glob(os.path.join(build_data_working, '[0-9.]*')) - - # Find the latest ansible version directory - latest = None - latest_ver = Version('0') - for directory_name in (d for d in ansible_directories if os.path.isdir(d)): - try: - new_version = Version(os.path.basename(directory_name)) - except InvalidVersion: - continue - - # For the devel build, we only need ansible.in, so make sure it's there - if not os.path.exists(os.path.join(directory_name, 'ansible.in')): - continue - - if new_version > latest_ver: - latest_ver = new_version - latest = directory_name - - if latest is None: - raise NoSuchFile('Could not find an ansible data directory in {0}'.format(build_data_working)) - - return latest - - -def parse_deps_file(filename): - """Parse an antsibull .deps file.""" - with open(filename, 'r', encoding='utf-8') as f: - contents = f.read() - lines = [c for line in contents.splitlines() if (c := line.strip()) and not c.startswith('#')] - return dict([entry.strip() for entry in line.split(':', 1)] for line in lines) - - -def write_deps_file(filename, deps_data): - """Write an antsibull .deps file.""" - with open(filename, 'w', encoding='utf-8') as f: - for key, value in deps_data.items(): - f.write(f'{key}: {value}\n') - - -def find_latest_deps_file(build_data_working, ansible_version): - """Find the most recent ansible deps file for the given ansible major version.""" - # imports here so that they don't cause unnecessary deps for all of the plugins - from packaging.version import Version - - data_dir = os.path.join(build_data_working, ansible_version) - deps_files = glob.glob(os.path.join(data_dir, '*.deps')) - if not deps_files: - raise Exception('No deps files exist for version {0}'.format(ansible_version)) - - # Find the latest version of the deps file for this major version - latest = None - latest_ver = Version('0') - for filename in deps_files: - deps_data = parse_deps_file(filename) - new_version = Version(deps_data['_ansible_version']) - if new_version > latest_ver: - latest_ver = new_version - latest = filename - - if latest is None: - raise NoSuchFile('Could not find an ansible deps file in {0}'.format(data_dir)) - - return latest - - -# -# Subcommand core -# - -def generate_core_docs(args): - """Regenerate the documentation for all plugins listed in the plugin_to_collection_file.""" - # imports here so that they don't cause unnecessary deps for all of the plugins - from antsibull_docs.cli import antsibull_docs - - with TemporaryDirectory() as tmp_dir: - # - # Construct a deps file with our version of ansible_core in it - # - modified_deps_file = os.path.join(tmp_dir, 'ansible.deps') - - # The _ansible_version doesn't matter since we're only building docs for core - deps_file_contents = {'_ansible_version': ansible_core__version__, - '_ansible_core_version': ansible_core__version__} - - with open(modified_deps_file, 'w') as f: - f.write(yaml.dump(deps_file_contents)) - - # Generate the plugin rst - return antsibull_docs.run(['antsibull-docs', 'stable', '--deps-file', modified_deps_file, - '--ansible-core-source', str(args.top_dir), - '--dest-dir', args.output_dir]) - - # If we make this more than just a driver for antsibull: - # Run other rst generation - # Run sphinx build - - -# -# Subcommand full -# - -def generate_full_docs(args): - """Regenerate the documentation for all plugins listed in the plugin_to_collection_file.""" - # imports here so that they don't cause unnecessary deps for all of the plugins - import sh - from antsibull_docs.cli import antsibull_docs - - with TemporaryDirectory() as tmp_dir: - sh.git(['clone', 'https://github.com/ansible-community/ansible-build-data'], _cwd=tmp_dir) - # If we want to validate that the ansible version and ansible-core branch version match, - # this would be the place to do it. - - build_data_working = os.path.join(tmp_dir, 'ansible-build-data') - if args.ansible_build_data: - build_data_working = args.ansible_build_data - - ansible_version = args.ansible_version - if ansible_version is None: - ansible_version = find_latest_ansible_dir(build_data_working) - params = ['devel', '--pieces-file', os.path.join(ansible_version, 'ansible.in')] - else: - latest_filename = find_latest_deps_file(build_data_working, ansible_version) - - # Make a copy of the deps file so that we can set the ansible-core version we'll use - modified_deps_file = os.path.join(tmp_dir, 'ansible.deps') - shutil.copyfile(latest_filename, modified_deps_file) - - # Put our version of ansible-core into the deps file - deps_data = parse_deps_file(modified_deps_file) - - deps_data['_ansible_core_version'] = ansible_core__version__ - - # antsibull-docs will choke when a key `_python` is found. Remove it to work around - # that until antsibull-docs is fixed. - deps_data.pop('_python', None) - - write_deps_file(modified_deps_file, deps_data) - - params = ['stable', '--deps-file', modified_deps_file] - - # Generate the plugin rst - return antsibull_docs.run(['antsibull-docs'] + params + - ['--ansible-core-source', str(args.top_dir), - '--dest-dir', args.output_dir]) - - # If we make this more than just a driver for antsibull: - # Run other rst generation - # Run sphinx build - - -class CollectionPluginDocs(Command): - name = 'docs-build' - _ACTION_HELP = """Action to perform. - full: Regenerate the rst for the full ansible website. - core: Regenerate the rst for plugins in ansible-core and then build the website. - named: Regenerate the rst for the named plugins and then build the website. - """ - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, - description='Generate documentation for plugins in collections.' - ' Plugins in collections will have a stub file in the normal plugin' - ' documentation location that says the module is in a collection and' - ' point to generated plugin documentation under the collections/' - ' hierarchy.') - # I think we should make the actions a subparser but need to look in git history and see if - # we tried that and changed it for some reason. - parser.add_argument('action', action='store', choices=('full', 'core', 'named'), - default='full', help=cls._ACTION_HELP) - parser.add_argument("-o", "--output-dir", action="store", dest="output_dir", - default=DEFAULT_OUTPUT_DIR, - help="Output directory for generated doc files") - parser.add_argument("-t", "--top-dir", action="store", dest="top_dir", - default=DEFAULT_TOP_DIR, - help="Toplevel directory of this ansible-core checkout or expanded" - " tarball.") - parser.add_argument("-l", "--limit-to-modules", '--limit-to', action="store", - dest="limit_to", default=None, - help="Limit building module documentation to comma-separated list of" - " plugins. Specify non-existing plugin name for no plugins.") - parser.add_argument('--ansible-version', action='store', - dest='ansible_version', default=None, - help='The version of the ansible package to make documentation for.' - ' This only makes sense when used with full.') - parser.add_argument('--ansible-build-data', action='store', - dest='ansible_build_data', default=None, - help='A checkout of the ansible-build-data repo. Useful for' - ' debugging.') - - @staticmethod - def main(args): - # normalize and validate CLI args - - if args.ansible_version and args.action != 'full': - raise InvalidUserInput('--ansible-version is only for use with "full".') - - if not args.output_dir: - args.output_dir = os.path.abspath(str(DEFAULT_OUTPUT_DIR)) - - if args.action == 'full': - return generate_full_docs(args) - - if args.action == 'core': - return generate_core_docs(args) - # args.action == 'named' (Invalid actions are caught by argparse) - raise NotImplementedError('Building docs for specific files is not yet implemented') - - # return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/dump_config.py b/hacking/build_library/build_ansible/command_plugins/dump_config.py deleted file mode 100644 index 733f9503e91..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/dump_config.py +++ /dev/null @@ -1,82 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import os -import os.path -import pathlib - -import yaml -from jinja2 import Environment, FileSystemLoader -from ansible.module_utils.common.text.converters import to_bytes - -# Pylint doesn't understand Python3 namespace modules. -from ..change_detection import update_file_if_different # pylint: disable=relative-beyond-top-level -from ..commands import Command # pylint: disable=relative-beyond-top-level - - -DEFAULT_TEMPLATE_FILE = 'config.rst.j2' -DEFAULT_TEMPLATE_DIR = pathlib.Path(__file__).parents[4] / 'docs/templates' - - -def fix_description(config_options): - '''some descriptions are strings, some are lists. workaround it...''' - - for config_key in list(config_options.keys()): - - # drop internal entries - if config_key.startswith('_'): - del config_options[config_key] - continue - - description = config_options[config_key].get('description', []) - if isinstance(description, list): - desc_list = description - else: - desc_list = [description] - config_options[config_key]['description'] = desc_list - return config_options - - -class DocumentConfig(Command): - name = 'document-config' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, description='Generate module documentation from metadata') - parser.add_argument("-t", "--template-file", action="store", dest="template_file", - default=DEFAULT_TEMPLATE_FILE, - help="Jinja2 template to use for the config") - parser.add_argument("-T", "--template-dir", action="store", dest="template_dir", - default=str(DEFAULT_TEMPLATE_DIR), - help="directory containing Jinja2 templates") - parser.add_argument("-o", "--output-dir", action="store", dest="output_dir", default='/tmp/', - help="Output directory for rst files") - parser.add_argument("config_defs", metavar="CONFIG-OPTION-DEFINITIONS.yml", type=str, - help="Source for config option docs") - - @staticmethod - def main(args): - output_dir = os.path.abspath(args.output_dir) - template_file_full_path = os.path.abspath(os.path.join(args.template_dir, args.template_file)) - template_file = os.path.basename(template_file_full_path) - template_dir = os.path.dirname(template_file_full_path) - - with open(args.config_defs) as f: - config_options = yaml.safe_load(f) - - config_options = fix_description(config_options) - - env = Environment(loader=FileSystemLoader(template_dir), trim_blocks=True,) - template = env.get_template(template_file) - output_name = os.path.join(output_dir, template_file.replace('.j2', '')) - temp_vars = {'config_options': config_options} - - data = to_bytes(template.render(temp_vars)) - update_file_if_different(output_name, data) - - return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/dump_keywords.py b/hacking/build_library/build_ansible/command_plugins/dump_keywords.py deleted file mode 100644 index 90a790f68b9..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/dump_keywords.py +++ /dev/null @@ -1,121 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import importlib -import os.path -import pathlib -import re -from ansible.module_utils.compat.version import LooseVersion - -import jinja2 -import yaml -from jinja2 import Environment, FileSystemLoader - -from ansible.module_utils.common.text.converters import to_bytes - -# Pylint doesn't understand Python3 namespace modules. -from ..change_detection import update_file_if_different # pylint: disable=relative-beyond-top-level -from ..commands import Command # pylint: disable=relative-beyond-top-level - - -DEFAULT_TEMPLATE_DIR = str(pathlib.Path(__file__).resolve().parents[4] / 'docs/templates') -TEMPLATE_FILE = 'playbooks_keywords.rst.j2' -PLAYBOOK_CLASS_NAMES = ['Play', 'Role', 'Block', 'Task'] - - -def load_definitions(keyword_definitions_file): - docs = {} - with open(keyword_definitions_file) as f: - docs = yaml.safe_load(f) - - return docs - - -def extract_keywords(keyword_definitions): - pb_keywords = {} - for pb_class_name in PLAYBOOK_CLASS_NAMES: - if pb_class_name == 'Play': - module_name = 'ansible.playbook' - else: - module_name = 'ansible.playbook.{0}'.format(pb_class_name.lower()) - module = importlib.import_module(module_name) - playbook_class = getattr(module, pb_class_name, None) - if playbook_class is None: - raise ImportError("We weren't able to import the module {0}".format(module_name)) - - # Maintain order of the actual class names for our output - # Build up a mapping of playbook classes to the attributes that they hold - pb_keywords[pb_class_name] = {k: v for (k, v) in playbook_class.fattributes.items() - # Filter private attributes as they're not usable in playbooks - if not v.private} - - # pick up definitions if they exist - for keyword in tuple(pb_keywords[pb_class_name]): - if keyword in keyword_definitions: - pb_keywords[pb_class_name][keyword] = keyword_definitions[keyword] - else: - # check if there is an alias, otherwise undocumented - alias = getattr(playbook_class.fattributes.get(keyword), 'alias', None) - if alias and alias in keyword_definitions: - pb_keywords[pb_class_name][alias] = keyword_definitions[alias] - del pb_keywords[pb_class_name][keyword] - else: - pb_keywords[pb_class_name][keyword] = ' UNDOCUMENTED!! ' - - # loop is really with_ for users - if pb_class_name == 'Task': - pb_keywords[pb_class_name]['with_'] = ( - 'The same as ``loop`` but magically adds the output of any lookup plugin to' - ' generate the item list.') - - # local_action is implicit with action - if 'action' in pb_keywords[pb_class_name]: - pb_keywords[pb_class_name]['local_action'] = ('Same as action but also implies' - ' ``delegate_to: localhost``') - - return pb_keywords - - -def generate_page(pb_keywords, template_dir): - env = Environment(loader=FileSystemLoader(template_dir), trim_blocks=True,) - template = env.get_template(TEMPLATE_FILE) - tempvars = {'pb_keywords': pb_keywords, 'playbook_class_names': PLAYBOOK_CLASS_NAMES} - - keyword_page = template.render(tempvars) - if LooseVersion(jinja2.__version__) < LooseVersion('2.10'): - # jinja2 < 2.10's indent filter indents blank lines. Cleanup - keyword_page = re.sub(' +\n', '\n', keyword_page) - - return keyword_page - - -class DocumentKeywords(Command): - name = 'document-keywords' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, description='Generate playbook keyword documentation from' - ' code and descriptions') - parser.add_argument("-T", "--template-dir", action="store", dest="template_dir", - default=DEFAULT_TEMPLATE_DIR, - help="directory containing Jinja2 templates") - parser.add_argument("-o", "--output-dir", action="store", dest="output_dir", - default='/tmp/', help="Output directory for rst files") - parser.add_argument("keyword_defs", metavar="KEYWORD-DEFINITIONS.yml", type=str, - help="Source for playbook keyword docs") - - @staticmethod - def main(args): - keyword_definitions = load_definitions(args.keyword_defs) - pb_keywords = extract_keywords(keyword_definitions) - - keyword_page = generate_page(pb_keywords, args.template_dir) - outputname = os.path.join(args.output_dir, TEMPLATE_FILE.replace('.j2', '')) - update_file_if_different(outputname, to_bytes(keyword_page)) - - return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/file_deprecated_issues.py b/hacking/build_library/build_ansible/command_plugins/file_deprecated_issues.py deleted file mode 100644 index 139ecc4d947..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/file_deprecated_issues.py +++ /dev/null @@ -1,153 +0,0 @@ -# -*- coding: utf-8 -*- -# (c) 2017, Matt Martz -# (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -import argparse -import os -import time - -from collections import defaultdict - -from ansible.release import __version__ as ansible_version - -# Pylint doesn't understand Python3 namespace modules. -from ..commands import Command # pylint: disable=relative-beyond-top-level -from .. import errors # pylint: disable=relative-beyond-top-level - -ANSIBLE_MAJOR_VERSION = '.'.join(ansible_version.split('.')[:2]) - - -def get_token(token_file): - if token_file: - return token_file.read().strip() - - token = os.getenv('GITHUB_TOKEN').strip() - if not token: - raise errors.MissingUserInput( - 'Please provide a file containing a github oauth token with public_repo scope' - ' via the --github-token argument or set the GITHUB_TOKEN env var with your' - ' github oauth token' - ) - return token - - -def parse_deprecations(problems_file_handle): - deprecated = defaultdict(list) - deprecation_errors = problems_file_handle.read() - for line in deprecation_errors.splitlines(): - path = line.split(':')[0] - if path.endswith('__init__.py'): - component = os.path.basename(os.path.dirname(path)) - else: - component, dummy = os.path.splitext(os.path.basename(path).lstrip('_')) - - title = ( - '%s contains deprecated call to be removed in %s' % - (component, ANSIBLE_MAJOR_VERSION) - ) - deprecated[component].append( - dict(title=title, path=path, line=line) - ) - return deprecated - - -def find_project_todo_column(repo, project_name): - project = None - for project in repo.projects(): - if project.name.lower() == project_name: - break - else: - raise errors.InvalidUserInput('%s was an invalid project name' % project_name) - - for project_column in project.columns(): - column_name = project_column.name.lower() - if 'todo' in column_name or 'backlog' in column_name or 'to do' in column_name: - return project_column - - raise Exception('Unable to determine the todo column in' - ' project %s' % project_name) - - -def create_issues(deprecated, body_tmpl, repo): - issues = [] - - for component, items in deprecated.items(): - title = items[0]['title'] - path = '\n'.join(set((i['path']) for i in items)) - line = '\n'.join(i['line'] for i in items) - body = body_tmpl % dict(component=component, path=path, - line=line, - version=ANSIBLE_MAJOR_VERSION) - - issue = repo.create_issue(title, body=body, labels=['deprecated']) - print(issue) - issues.append(issue) - - # Sleep a little, so that the API doesn't block us - time.sleep(0.5) - - return issues - - -class FileDeprecationTickets(Command): - name = 'file-deprecation-tickets' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, description='File tickets to cleanup deprecated features for' - ' the next release') - parser.add_argument('--template', default='deprecated_issue_template.md', - type=argparse.FileType('r'), - help='Path to markdown file template to be used for issue ' - 'body. Default: %(default)s') - parser.add_argument('--project-name', default='', type=str, - help='Name of a github project to assign all issues to') - parser.add_argument('--github-token', type=argparse.FileType('r'), - help='Path to file containing a github token with public_repo scope.' - ' This token in this file will be used to open the deprcation' - ' tickets and add them to the github project. If not given,' - ' the GITHUB_TOKEN environment variable will be tried') - parser.add_argument('problems', type=argparse.FileType('r'), - help='Path to file containing pylint output for the ' - 'ansible-deprecated-version check') - - @staticmethod - def main(args): - try: - from github3 import GitHub - except ImportError: - raise errors.DependencyError( - 'This command needs the github3.py library installed to work' - ) - - token = get_token(args.github_token) - args.github_token.close() - - deprecated = parse_deprecations(args.problems) - args.problems.close() - - body_tmpl = args.template.read() - args.template.close() - - project_name = args.project_name.strip().lower() - - gh_conn = GitHub(token=token) - repo = gh_conn.repository('abadger', 'ansible') - - if project_name: - project_column = find_project_todo_column(repo, project_name) - - issues = create_issues(deprecated, body_tmpl, repo) - - if project_column: - for issue in issues: - project_column.create_card_with_issue(issue) - time.sleep(0.5) - - return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/generate_man.py b/hacking/build_library/build_ansible/command_plugins/generate_man.py deleted file mode 100644 index 4228c48b4df..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/generate_man.py +++ /dev/null @@ -1,302 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -import argparse -import os.path -import pathlib -import sys - -from jinja2 import Environment, FileSystemLoader - -from ansible.module_utils.common.text.converters import to_bytes - -# Pylint doesn't understand Python3 namespace modules. -from ..change_detection import update_file_if_different # pylint: disable=relative-beyond-top-level -from ..commands import Command # pylint: disable=relative-beyond-top-level - - -DEFAULT_TEMPLATE_FILE = pathlib.Path(__file__).parents[4] / 'hacking/templates/man.j2' - - -# from https://www.python.org/dev/peps/pep-0257/ -def trim_docstring(docstring): - if not docstring: - return '' - # Convert tabs to spaces (following the normal Python rules) - # and split into a list of lines: - lines = docstring.expandtabs().splitlines() - # Determine minimum indentation (first line doesn't count): - indent = sys.maxsize - for line in lines[1:]: - stripped = line.lstrip() - if stripped: - indent = min(indent, len(line) - len(stripped)) - # Remove indentation (first line is special): - trimmed = [lines[0].strip()] - if indent < sys.maxsize: - for line in lines[1:]: - trimmed.append(line[indent:].rstrip()) - # Strip off trailing and leading blank lines: - while trimmed and not trimmed[-1]: - trimmed.pop() - while trimmed and not trimmed[0]: - trimmed.pop(0) - # Return a single string: - return '\n'.join(trimmed) - - -def get_options(optlist): - ''' get actual options ''' - - opts = [] - for opt in optlist: - res = { - 'desc': opt.help, - 'options': opt.option_strings - } - if isinstance(opt, argparse._StoreAction): - res['arg'] = opt.dest.upper() - elif not res['options']: - continue - opts.append(res) - - return opts - - -def dedupe_groups(parser): - action_groups = [] - for action_group in parser._action_groups: - found = False - for a in action_groups: - if a._actions == action_group._actions: - found = True - break - if not found: - action_groups.append(action_group) - return action_groups - - -def get_option_groups(option_parser): - groups = [] - for action_group in dedupe_groups(option_parser)[1:]: - group_info = {} - group_info['desc'] = action_group.description - group_info['options'] = action_group._actions - group_info['group_obj'] = action_group - groups.append(group_info) - return groups - - -def opt_doc_list(parser): - ''' iterate over options lists ''' - - results = [] - for option_group in dedupe_groups(parser)[1:]: - results.extend(get_options(option_group._actions)) - - results.extend(get_options(parser._actions)) - - return results - - -# def opts_docs(cli, name): -def opts_docs(cli_class_name, cli_module_name): - ''' generate doc structure from options ''' - - cli_name = 'ansible-%s' % cli_module_name - if cli_module_name == 'adhoc': - cli_name = 'ansible' - - # WIth no action/subcommand - # shared opts set - # instantiate each cli and ask its options - cli_klass = getattr(__import__("ansible.cli.%s" % cli_module_name, - fromlist=[cli_class_name]), cli_class_name) - cli = cli_klass([cli_name]) - - # parse the common options - try: - cli.init_parser() - except Exception: - pass - - # base/common cli info - cli_options = opt_doc_list(cli.parser) - docs = { - 'cli': cli_module_name, - 'cli_name': cli_name, - 'usage': cli.parser.format_usage(), - 'short_desc': cli.parser.description, - 'long_desc': trim_docstring(cli.__doc__), - 'actions': {}, - 'content_depth': 2, - 'options': cli_options, - 'arguments': getattr(cli, 'ARGUMENTS', None), - } - option_info = {'option_names': [], - 'options': cli_options, - 'groups': []} - - groups_info = get_option_groups(cli.parser) - shared_opt_names = [] - for opt in cli_options: - shared_opt_names.extend(opt.get('options', [])) - - option_info['option_names'] = shared_opt_names - - option_info['groups'].extend(groups_info) - - docs.update(option_info) - - # now for each action/subcommand - # force populate parser with per action options - - def get_actions(parser, docs): - # use class attrs not the attrs on a instance (not that it matters here...) - try: - subparser = parser._subparsers._group_actions[0].choices - except AttributeError: - subparser = {} - - depth = 0 - - for action, parser in subparser.items(): - action_info = {'option_names': [], - 'options': [], - 'actions': {}} - # docs['actions'][action] = {} - # docs['actions'][action]['name'] = action - action_info['name'] = action - action_info['desc'] = trim_docstring(getattr(cli, 'execute_%s' % action).__doc__) - - # docs['actions'][action]['desc'] = getattr(cli, 'execute_%s' % action).__doc__.strip() - action_doc_list = opt_doc_list(parser) - - uncommon_options = [] - for action_doc in action_doc_list: - # uncommon_options = [] - - option_aliases = action_doc.get('options', []) - for option_alias in option_aliases: - - if option_alias in shared_opt_names: - continue - - # TODO: use set - if option_alias not in action_info['option_names']: - action_info['option_names'].append(option_alias) - - if action_doc in action_info['options']: - continue - - uncommon_options.append(action_doc) - - action_info['options'] = uncommon_options - - depth = 1 + get_actions(parser, action_info) - - docs['actions'][action] = action_info - - return depth - - action_depth = get_actions(cli.parser, docs) - docs['content_depth'] = action_depth + 1 - - return docs - - -class GenerateMan(Command): - name = 'generate-man' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(name=cls.name, - description='Generate cli documentation from cli docstrings') - - parser.add_argument("-t", "--template-file", action="store", dest="template_file", - default=DEFAULT_TEMPLATE_FILE, help="path to jinja2 template") - parser.add_argument("-o", "--output-dir", action="store", dest="output_dir", - default='/tmp/', help="Output directory for rst files") - parser.add_argument("-f", "--output-format", action="store", dest="output_format", - default='man', - help="Output format for docs (the default 'man' or 'rst')") - parser.add_argument('cli_modules', help='CLI module name(s)', metavar='MODULE_NAME', nargs='*') - - @staticmethod - def main(args): - template_file = args.template_file - template_path = os.path.expanduser(template_file) - template_dir = os.path.abspath(os.path.dirname(template_path)) - template_basename = os.path.basename(template_file) - - output_dir = os.path.abspath(args.output_dir) - output_format = args.output_format - - cli_modules = args.cli_modules - - # various cli parsing things checks sys.argv if the 'args' that are passed in are [] - # so just remove any args so the cli modules dont try to parse them resulting in warnings - sys.argv = [sys.argv[0]] - - allvars = {} - output = {} - cli_list = [] - cli_bin_name_list = [] - - # for binary in os.listdir('../../lib/ansible/cli'): - for cli_module_name in cli_modules: - binary = os.path.basename(os.path.expanduser(cli_module_name)) - - if not binary.endswith('.py'): - continue - elif binary == '__init__.py': - continue - - cli_name = os.path.splitext(binary)[0] - - if cli_name == 'adhoc': - cli_class_name = 'AdHocCLI' - # myclass = 'AdHocCLI' - output[cli_name] = 'ansible.1.rst.in' - cli_bin_name = 'ansible' - else: - # myclass = "%sCLI" % libname.capitalize() - cli_class_name = "%sCLI" % cli_name.capitalize() - output[cli_name] = 'ansible-%s.1.rst.in' % cli_name - cli_bin_name = 'ansible-%s' % cli_name - - # FIXME: - allvars[cli_name] = opts_docs(cli_class_name, cli_name) - cli_bin_name_list.append(cli_bin_name) - - cli_list = allvars.keys() - - doc_name_formats = {'man': '%s.1.rst.in', - 'rst': '%s.rst'} - - for cli_name in cli_list: - - # template it! - env = Environment(loader=FileSystemLoader(template_dir)) - template = env.get_template(template_basename) - - # add rest to vars - tvars = allvars[cli_name] - tvars['cli_bin_name_list'] = cli_bin_name_list - tvars['cli'] = cli_name - if '-i' in tvars['option_names']: - tvars['inventory'] = True - print('uses inventory') - if '-M' in tvars['option_names']: - tvars['library'] = True - print('uses library') - - manpage = template.render(tvars) - filename = os.path.join(output_dir, doc_name_formats[output_format] % tvars['cli_name']) - update_file_if_different(filename, to_bytes(manpage)) diff --git a/hacking/build_library/build_ansible/command_plugins/porting_guide.py b/hacking/build_library/build_ansible/command_plugins/porting_guide.py deleted file mode 100644 index 431485b153c..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/porting_guide.py +++ /dev/null @@ -1,138 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -from jinja2 import Environment, DictLoader - -# Pylint doesn't understand Python3 namespace modules. -from ..commands import Command # pylint: disable=relative-beyond-top-level - - -PORTING_GUIDE_TEMPLATE = """ -.. _porting_{{ ver }}_guide_core: - -******************************* -Ansible-core {{ ver }} Porting Guide -******************************* - -This section discusses the behavioral changes between ``ansible-core`` {{ prev_ver }} and ``ansible-core`` {{ ver }}. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `ansible-core Changelog for {{ ver }} `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - - -Playbook -======== - -No notable changes - - -Command Line -============ - -No notable changes - - -Deprecated -========== - -No notable changes - - -Modules -======= - -No notable changes - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Plugins -======= - -No notable changes - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes - -""" # noqa for E501 (line length). -# jinja2 is horrid about getting rid of extra newlines so we have to have a single line per -# paragraph for proper wrapping to occur - -JINJA_ENV = Environment( - loader=DictLoader({'porting_guide': PORTING_GUIDE_TEMPLATE, - }), - extensions=['jinja2.ext.i18n'], - trim_blocks=True, - lstrip_blocks=True, -) - - -def generate_porting_guide(version): - template = JINJA_ENV.get_template('porting_guide') - - version_list = version.split('.') - version_list[-1] = str(int(version_list[-1]) - 1) - previous_version = '.'.join(version_list) - - content = template.render(ver=version, prev_ver=previous_version) - return content - - -def write_guide(version, guide_content): - filename = 'docs/docsite/rst/porting_guides/porting_guide_core_{0}.rst'.format(version) - with open(filename, 'w') as out_file: - out_file.write(guide_content) - - -class PortingGuideCommand(Command): - name = 'porting-guide' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, description="Generate a fresh porting guide template") - parser.add_argument("--version", dest="version", type=str, required=True, action='store', - help="Version of Ansible to write the porting guide for") - - @staticmethod - def main(args): - guide_content = generate_porting_guide(args.version) - write_guide(args.version, guide_content) - return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/update_intersphinx.py b/hacking/build_library/build_ansible/command_plugins/update_intersphinx.py deleted file mode 100644 index e4637e56cfd..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/update_intersphinx.py +++ /dev/null @@ -1,95 +0,0 @@ -# -*- coding: utf-8 -*- -# (c) 2020, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -import importlib -import pathlib -import urllib.parse - -from ansible.module_utils.common.collections import is_iterable -from ansible.module_utils.urls import Request - -# Pylint doesn't understand Python3 namespace modules. -from ..commands import Command # pylint: disable=relative-beyond-top-level - - -EXAMPLE_CONF = """ -A proper intersphinx_mapping entry should look like: - intersphinx_mapping = { - 'python3': ('https://docs.python.org/3', (None, 'python3.inv')) - } - -See the intersphinx docs for more info: - https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html#confval-intersphinx_mapping -""" - - -class UpdateIntersphinxCache(Command): - name = 'update-intersphinx-cache' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, description='Update cached intersphinx mappings. This' - ' updates the cached intersphinx mappings for docs to reference' - ' documentation from other projects.') - parser.add_argument('-o', '--output-dir', action='store', - help='Path to directory the cached objects.inv files are stored in') - parser.add_argument('-c', '--conf-file', action='store', - help='Path to a sphinx config file to retrieve intersphinx config from') - - @staticmethod - def main(args): - # Retrieve the intersphinx information from the sphinx config file - conf_dir = pathlib.Path(args.conf_file).parent - - conf_module_spec = importlib.util.spec_from_file_location('sphinxconf', args.conf_file) - conf_module = importlib.util.module_from_spec(conf_module_spec) - conf_module_spec.loader.exec_module(conf_module) - intersphinx_mapping = conf_module.intersphinx_mapping - - for intersphinx_name, inventory in intersphinx_mapping.items(): - if not is_iterable(inventory) or len(inventory) != 2: - print('WARNING: The intersphinx entry for {0} must be' - ' a two-tuple.\n{1}'.format(intersphinx_name, EXAMPLE_CONF)) - continue - - url = cache_file = None - for inv_source in inventory: - if isinstance(inv_source, str) and url is None: - url = inv_source - elif is_iterable(inv_source) and cache_file is None: - if len(inv_source) != 2: - print('WARNING: The fallback entry for {0} should be a tuple of (None,' - ' filename).\n{1}'.format(intersphinx_name, EXAMPLE_CONF)) - continue - cache_file = inv_source[1] - else: - print('WARNING: The configuration for {0} should be a tuple of one url and one' - ' tuple for a fallback filename.\n{1}'.format(intersphinx_name, - EXAMPLE_CONF)) - continue - - if url is None or cache_file is None: - print('WARNING: Could not figure out the url or fallback' - ' filename for {0}.\n{1}'.format(intersphinx_name, EXAMPLE_CONF)) - continue - - url = urllib.parse.urljoin(url, 'objects.inv') - # Resolve any relative cache files to be relative to the conf file - cache_file = conf_dir / cache_file - - # Retrieve the inventory and cache it - # The jinja CDN seems to be blocking the default urllib User-Agent - requestor = Request(headers={'User-Agent': 'Definitely Not Python ;-)'}) - with requestor.open('GET', url) as source_file: - with open(cache_file, 'wb') as f: - f.write(source_file.read()) - - print('Download of new cache files complete. Remember to git commit -a the changes') - - return 0 diff --git a/hacking/build_library/build_ansible/commands.py b/hacking/build_library/build_ansible/commands.py deleted file mode 100644 index 826799349e5..00000000000 --- a/hacking/build_library/build_ansible/commands.py +++ /dev/null @@ -1,50 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -from abc import ABCMeta, abstractmethod, abstractproperty - - -class Command(metaclass=ABCMeta): - """ - Subcommands of :program:`build-ansible.py`. - - This defines an interface that all subcommands must conform to. :program:`build-ansible.py` - will require that these things are present in order to proceed. - """ - @staticmethod - @abstractproperty - def name(): - """Name of the subcommand. It's the string to invoked it via on the command line""" - - @staticmethod - @abstractmethod - def init_parser(add_parser): - """ - Initialize and register an argparse ArgumentParser - - :arg add_parser: function which creates an ArgumentParser for the main program. - - Implementations should first create an ArgumentParser using `add_parser` and then populate - it with the command line arguments that are needed. - - .. seealso: - `add_parser` information in the :py:meth:`ArgumentParser.add_subparsers` documentation. - """ - - @staticmethod - @abstractmethod - def main(arguments): - """ - Run the command - - :arg arguments: The **parsed** command line args - - This is the Command's entrypoint. The command line args are already parsed but from here - on, the command can do its work. - """ diff --git a/hacking/build_library/build_ansible/errors.py b/hacking/build_library/build_ansible/errors.py deleted file mode 100644 index a53d1fb1c8e..00000000000 --- a/hacking/build_library/build_ansible/errors.py +++ /dev/null @@ -1,19 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -class DependencyError(Exception): - """A dependency was unmet""" - - -class MissingUserInput(Exception): - """The user failed to provide input (via cli arg or interactively""" - - -class InvalidUserInput(Exception): - """The user provided invalid input""" diff --git a/hacking/templates/man.j2 b/hacking/templates/man.j2 deleted file mode 100644 index 9a8cb1d7931..00000000000 --- a/hacking/templates/man.j2 +++ /dev/null @@ -1,127 +0,0 @@ -{{ cli_name }} -{{ '=' * ( cli_name|length|int ) }} - -{{ '-' * ( short_desc|default('')|string|length|int ) }} -{{short_desc|default('')}} -{{ '-' * ( short_desc|default('')|string|length|int ) }} - -:Version: Ansible %VERSION% -:Manual section: 1 -:Manual group: System administration commands - - - -SYNOPSIS --------- -{{ usage|replace('%prog', cli_name) }} - - -DESCRIPTION ------------ -{{ long_desc|default('', True)|wordwrap }} - -{% if options %} -COMMON OPTIONS --------------- -{% for option in options|sort(attribute='options') %} -{% for switch in option['options'] %}**{{switch}}**{% if option['arg'] %} '{{option['arg']}}'{% endif %}{% if not loop.last %}, {% endif %}{% endfor %} - - {{ option['desc'] }} -{% endfor %} -{% endif %} - -{% if arguments %} -ARGUMENTS ---------- - -{% for arg in arguments %} -{{ arg }} - -{{ (arguments[arg]|default(' '))|wordwrap }} - -{% endfor %} -{% endif %} - -{% if actions %} -ACTIONS -------- -{% for action in actions %} -**{{ action }}** - {{ (actions[action]['desc']|default(' ')) |replace('\n', ' ')}} - -{% if actions[action]['options'] %} -{% for option in actions[action]['options']|sort(attribute='options') %} -{% for switch in option['options'] if switch in actions[action]['option_names'] %} **{{switch}}**{% if option['arg'] %} '{{option['arg']}}'{% endif %}{% if not loop.last %}, {% endif %}{% endfor %} - - {{ (option['desc']) }} -{% endfor %} -{% endif %} -{% endfor %} -{% endif %} - - -{% if inventory %} -INVENTORY ---------- - -Ansible stores the hosts it can potentially operate on in an inventory. -This can be an YAML file, ini-like file, a script, directory, list, etc. -For additional options, see the documentation on https://docs.ansible.com/. - -{% endif %} -ENVIRONMENT ------------ - -The following environment variables may be specified. - -{% if inventory %} -ANSIBLE_INVENTORY -- Override the default ansible inventory sources - -{% endif %} -{% if library %} -ANSIBLE_LIBRARY -- Override the default ansible module library path - -{% endif %} -ANSIBLE_CONFIG -- Specify override location for the ansible config file - -Many more are available for most options in ansible.cfg - -For a full list check https://docs.ansible.com/. or use the `ansible-config` command. - -FILES ------ - -{% if inventory %} -/etc/ansible/hosts -- Default inventory file - -{% endif %} -/etc/ansible/ansible.cfg -- Config file, used if present - -~/.ansible.cfg -- User config file, overrides the default config if present - -./ansible.cfg -- Local config file (in current working directory) assumed to be 'project specific' and overrides the rest if present. - -As mentioned above, the ANSIBLE_CONFIG environment variable will override all others. - -AUTHOR ------- - -Ansible was originally written by Michael DeHaan. - - -COPYRIGHT ---------- - -Copyright © 2018 Red Hat, Inc | Ansible. -Ansible is released under the terms of the GPLv3 license. - - -SEE ALSO --------- - -{% for other in cli_bin_name_list|sort %}{% if other != cli_name %}**{{ other }}** (1){% if not loop.last %}, {% endif %}{% endif %}{% endfor %} - -Extensive documentation is available in the documentation site: -. -IRC and mailing list info can be found in file CONTRIBUTING.md, -available in: diff --git a/test/integration/targets/canonical-pep517-self-packaging/runme_test.py b/test/integration/targets/canonical-pep517-self-packaging/runme_test.py index 86b0f7532a8..9a5e26b74e4 100644 --- a/test/integration/targets/canonical-pep517-self-packaging/runme_test.py +++ b/test/integration/targets/canonical-pep517-self-packaging/runme_test.py @@ -337,6 +337,9 @@ def test_dist_rebuilds_with_manpages_premutations( assert rebuilt_sdist_path.exists() assert rebuilt_sdist_path.is_dir() normalize_unpacked_rebuilt_sdist(rebuilt_sdist_path) + # Ensure the man page directory exists to ease diff comparison. + for dir_path in (rebuilt_sdist_path, sdist_with_manpages_path): + (dir_path / 'docs/man/man1').mkdir(parents=True, exist_ok=True) assert_dirs_equal(rebuilt_sdist_path, sdist_with_manpages_path) # Test building a wheel from the rebuilt sdist with manpages contents diff --git a/test/lib/ansible_test/_internal/classification/__init__.py b/test/lib/ansible_test/_internal/classification/__init__.py index bca02403b3c..8039e273790 100644 --- a/test/lib/ansible_test/_internal/classification/__init__.py +++ b/test/lib/ansible_test/_internal/classification/__init__.py @@ -721,17 +721,6 @@ class PathMapper: if path.startswith('changelogs/'): return minimal - if path.startswith('docs/'): - return minimal - - if path.startswith('examples/'): - if path == 'examples/scripts/ConfigureRemotingForAnsible.ps1': - return { - 'windows-integration': 'connection_winrm', - } - - return minimal - if path.startswith('hacking/'): return minimal diff --git a/test/lib/ansible_test/_internal/classification/python.py b/test/lib/ansible_test/_internal/classification/python.py index 7036de1aced..c074d348d83 100644 --- a/test/lib/ansible_test/_internal/classification/python.py +++ b/test/lib/ansible_test/_internal/classification/python.py @@ -256,7 +256,6 @@ class ModuleUtilFinder(ast.NodeVisitor): # The mapping is a tuple consisting of a path pattern to match and a replacement path. # During analysis, any relative imports not covered here will result in warnings, which can be fixed by adding the appropriate entry. path_map = ( - ('^hacking/build_library/build_ansible/', 'build_ansible/'), ('^lib/ansible/', 'ansible/'), ('^test/lib/ansible_test/_util/controller/sanity/validate-modules/', 'validate_modules/'), ('^test/units/', 'test/units/'), diff --git a/test/lib/ansible_test/_internal/commands/sanity/sanity_docs.py b/test/lib/ansible_test/_internal/commands/sanity/sanity_docs.py deleted file mode 100644 index 48f1b0b100a..00000000000 --- a/test/lib/ansible_test/_internal/commands/sanity/sanity_docs.py +++ /dev/null @@ -1,61 +0,0 @@ -"""Sanity test for documentation of sanity tests.""" -from __future__ import annotations - -import os - -from . import ( - SanityVersionNeutral, - SanityMessage, - SanityFailure, - SanitySuccess, - SanityTargets, - sanity_get_tests, -) - -from ...test import ( - TestResult, -) - -from ...config import ( - SanityConfig, -) - -from ...data import ( - data_context, -) - - -class SanityDocsTest(SanityVersionNeutral): - """Sanity test for documentation of sanity tests.""" - - ansible_only = True - - @property - def can_ignore(self) -> bool: - """True if the test supports ignore entries.""" - return False - - @property - def no_targets(self) -> bool: - """True if the test does not use test targets. Mutually exclusive with all_targets.""" - return True - - def test(self, args: SanityConfig, targets: SanityTargets) -> TestResult: - sanity_dir = 'docs/docsite/rst/dev_guide/testing/sanity' - sanity_docs = set(part[0] for part in (os.path.splitext(os.path.basename(path)) for path in data_context().content.get_files(sanity_dir)) - if part[1] == '.rst') - sanity_tests = set(sanity_test.name for sanity_test in sanity_get_tests()) - - missing = sanity_tests - sanity_docs - - results = [] - - results += [SanityMessage( - message='missing docs for ansible-test sanity --test %s' % r, - path=os.path.join(sanity_dir, '%s.rst' % r), - ) for r in sorted(missing)] - - if results: - return SanityFailure(self.name, messages=results) - - return SanitySuccess(self.name) diff --git a/test/lib/ansible_test/_internal/provider/source/unversioned.py b/test/lib/ansible_test/_internal/provider/source/unversioned.py index 699de889d3e..54831c99e4a 100644 --- a/test/lib/ansible_test/_internal/provider/source/unversioned.py +++ b/test/lib/ansible_test/_internal/provider/source/unversioned.py @@ -48,9 +48,6 @@ class UnversionedSource(SourceProvider): 'tests': ( 'output', ), - 'docs/docsite': ( - '_build', - ), } kill_sub_file = { diff --git a/test/lib/ansible_test/_util/target/setup/ConfigureRemotingForAnsible.ps1 b/test/lib/ansible_test/_util/target/setup/ConfigureRemotingForAnsible.ps1 index 7cc86abd7ce..c1cb91e49fd 100644 --- a/test/lib/ansible_test/_util/target/setup/ConfigureRemotingForAnsible.ps1 +++ b/test/lib/ansible_test/_util/target/setup/ConfigureRemotingForAnsible.ps1 @@ -15,7 +15,7 @@ # To run this script in Powershell: # # [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 -# $url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1" +# $url = "https://raw.githubusercontent.com/ansible/ansible/devel/test/lib/ansible_test/_util/target/setup/ConfigureRemotingForAnsible.ps1" # $file = "$env:temp\ConfigureRemotingForAnsible.ps1" # # (New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file) diff --git a/test/sanity/code-smell/configure-remoting-ps1.json b/test/sanity/code-smell/configure-remoting-ps1.json deleted file mode 100644 index 593b765d14a..00000000000 --- a/test/sanity/code-smell/configure-remoting-ps1.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "no_targets": true, - "output": "path-message" -} diff --git a/test/sanity/code-smell/configure-remoting-ps1.py b/test/sanity/code-smell/configure-remoting-ps1.py deleted file mode 100644 index fe678008c1e..00000000000 --- a/test/sanity/code-smell/configure-remoting-ps1.py +++ /dev/null @@ -1,52 +0,0 @@ -from __future__ import annotations - -import os - - -def main(): - # required by external automated processes and should not be moved, renamed or converted to a symbolic link - original = 'examples/scripts/ConfigureRemotingForAnsible.ps1' - # required to be packaged with ansible-test and must match the original file, but cannot be a symbolic link - # the packaged version is needed to run tests when ansible-test has been installed - # keeping the packaged version identical to the original makes sure tests cover both files - packaged = 'test/lib/ansible_test/_util/target/setup/ConfigureRemotingForAnsible.ps1' - - copy_valid = False - - if os.path.isfile(original) and os.path.isfile(packaged): - with open(original, 'rb') as original_file: - original_content = original_file.read() - - with open(packaged, 'rb') as packaged_file: - packaged_content = packaged_file.read() - - if original_content == packaged_content: - copy_valid = True - - if not copy_valid: - print('%s: must be an exact copy of "%s"' % (packaged, original)) - - for path in [original, packaged]: - directory = path - - while True: - directory = os.path.dirname(directory) - - if not directory: - break - - if not os.path.isdir(directory): - print('%s: must be a directory' % directory) - - if os.path.islink(directory): - print('%s: cannot be a symbolic link' % directory) - - if not os.path.isfile(path): - print('%s: must be a file' % path) - - if os.path.islink(path): - print('%s: cannot be a symbolic link' % path) - - -if __name__ == '__main__': - main() diff --git a/test/sanity/code-smell/docs-build.json b/test/sanity/code-smell/docs-build.json deleted file mode 100644 index a43fa923b2b..00000000000 --- a/test/sanity/code-smell/docs-build.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "disabled": true, - "no_targets": true, - "output": "path-line-column-message" -} diff --git a/test/sanity/code-smell/docs-build.py b/test/sanity/code-smell/docs-build.py deleted file mode 100644 index f0071de8591..00000000000 --- a/test/sanity/code-smell/docs-build.py +++ /dev/null @@ -1,179 +0,0 @@ -from __future__ import annotations - -import os -import re -import shutil -import subprocess -import sys -import tempfile - - -def main(): - base_dir = os.getcwd() - - keep_dirs = [ - 'bin', - 'docs', - 'examples', - 'hacking', - 'lib', - 'packaging', - 'test/lib', - 'test/sanity', - ] - - keep_files = [ - 'MANIFEST.in', - 'pyproject.toml', - 'requirements.txt', - 'setup.cfg', - 'setup.py', - ] - - # The tests write to the source tree, which isn't permitted for sanity tests. - # To work around this a temporary copy is used. - - current_dir = os.getcwd() - - with tempfile.TemporaryDirectory(prefix='docs-build-', suffix='-sanity') as temp_dir: - for keep_dir in keep_dirs: - shutil.copytree(os.path.join(base_dir, keep_dir), os.path.join(temp_dir, keep_dir), symlinks=True) - - for keep_file in keep_files: - shutil.copy2(os.path.join(base_dir, keep_file), os.path.join(temp_dir, keep_file)) - - paths = os.environ['PATH'].split(os.pathsep) - paths = [f'{temp_dir}/bin' if path == f'{current_dir}/bin' else path for path in paths] - - # Fix up the environment so everything runs from the temporary copy. - os.environ['PATH'] = os.pathsep.join(paths) - os.environ['PYTHONPATH'] = f'{temp_dir}/lib' - os.chdir(temp_dir) - - run_test() - - -def run_test(): - base_dir = os.getcwd() + os.path.sep - docs_dir = os.path.abspath('docs/docsite') - - cmd = ['make', 'core_singlehtmldocs'] - sphinx = subprocess.run(cmd, stdin=subprocess.DEVNULL, capture_output=True, cwd=docs_dir, check=False, text=True) - - stdout = sphinx.stdout - stderr = sphinx.stderr - - if sphinx.returncode != 0: - sys.stderr.write("Command '%s' failed with status code: %d\n" % (' '.join(cmd), sphinx.returncode)) - - if stdout.strip(): - stdout = simplify_stdout(stdout) - - sys.stderr.write("--> Standard Output\n") - sys.stderr.write("%s\n" % stdout.strip()) - - if stderr.strip(): - sys.stderr.write("--> Standard Error\n") - sys.stderr.write("%s\n" % stderr.strip()) - - sys.exit(1) - - with open('docs/docsite/rst_warnings', 'r') as warnings_fd: - output = warnings_fd.read().strip() - lines = output.splitlines() - - known_warnings = { - 'block-quote-missing-blank-line': r'^Block quote ends without a blank line; unexpected unindent.$', - 'literal-block-lex-error': r'^Could not lex literal_block as "[^"]*". Highlighting skipped.$', - 'duplicate-label': r'^duplicate label ', - 'undefined-label': r'undefined label: ', - 'unknown-document': r'unknown document: ', - 'toc-tree-missing-document': r'toctree contains reference to nonexisting document ', - 'reference-target-not-found': r'[^ ]* reference target not found: ', - 'not-in-toc-tree': r"document isn't included in any toctree$", - 'unexpected-indentation': r'^Unexpected indentation.$', - 'definition-list-missing-blank-line': r'^Definition list ends without a blank line; unexpected unindent.$', - 'explicit-markup-missing-blank-line': r'Explicit markup ends without a blank line; unexpected unindent.$', - 'toc-tree-glob-pattern-no-match': r"^toctree glob pattern '[^']*' didn't match any documents$", - 'unknown-interpreted-text-role': '^Unknown interpreted text role "[^"]*".$', - } - - for line in lines: - match = re.search('^(?P[^:]+):((?P[0-9]+):)?((?P[0-9]+):)? (?PWARNING|ERROR): (?P.*)$', line) - - if not match: - path = 'docs/docsite/rst/index.rst' - lineno = 0 - column = 0 - code = 'unknown' - message = line - - # surface unknown lines while filtering out known lines to avoid excessive output - print('%s:%d:%d: %s: %s' % (path, lineno, column, code, message)) - continue - - path = match.group('path') - lineno = int(match.group('line') or 0) - column = int(match.group('column') or 0) - level = match.group('level').lower() - message = match.group('message') - - path = os.path.abspath(path) - - if path.startswith(base_dir): - path = path[len(base_dir):] - - if path.startswith('rst/'): - path = 'docs/docsite/' + path # fix up paths reported relative to `docs/docsite/` - - if level == 'warning': - code = 'warning' - - for label, pattern in known_warnings.items(): - if re.search(pattern, message): - code = label - break - else: - code = 'error' - - print('%s:%d:%d: %s: %s' % (path, lineno, column, code, message)) - - -def simplify_stdout(value): - """Simplify output by omitting earlier 'rendering: ...' messages.""" - lines = value.strip().splitlines() - - rendering = [] - keep = [] - - def truncate_rendering(): - """Keep last rendering line (if any) with a message about omitted lines as needed.""" - if not rendering: - return - - notice = rendering[-1] - - if len(rendering) > 1: - notice += ' (%d previous rendering line(s) omitted)' % (len(rendering) - 1) - - keep.append(notice) - # Could change to rendering.clear() if we do not support python2 - rendering[:] = [] - - for line in lines: - if line.startswith('rendering: '): - rendering.append(line) - continue - - truncate_rendering() - keep.append(line) - - truncate_rendering() - - result = '\n'.join(keep) - - return result - - -if __name__ == '__main__': - main() diff --git a/test/sanity/code-smell/docs-build.requirements.in b/test/sanity/code-smell/docs-build.requirements.in deleted file mode 100644 index becc07cbe6a..00000000000 --- a/test/sanity/code-smell/docs-build.requirements.in +++ /dev/null @@ -1,8 +0,0 @@ -jinja2 -pyyaml -resolvelib < 1.1.0 -sphinx == 5.3.0 -sphinx-notfound-page -sphinx-ansible-theme -rstcheck < 6 # rstcheck 6.x has problem with rstcheck.core triggered by include files w/ sphinx directives https://github.com/rstcheck/rstcheck-core/issues/3 -antsibull-docs == 2.0.0 # currently approved version diff --git a/test/sanity/code-smell/docs-build.requirements.txt b/test/sanity/code-smell/docs-build.requirements.txt deleted file mode 100644 index aca07c58044..00000000000 --- a/test/sanity/code-smell/docs-build.requirements.txt +++ /dev/null @@ -1,55 +0,0 @@ -# edit "docs-build.requirements.in" and generate with: hacking/update-sanity-requirements.py --test docs-build -aiofiles==23.1.0 -aiohttp==3.8.4 -aiosignal==1.3.1 -alabaster==0.7.13 -ansible-pygments==0.1.1 -antsibull-core==2.0.0 -antsibull-docs==2.0.0 -antsibull-docs-parser==1.0.0 -async-timeout==4.0.2 -asyncio-pool==0.6.0 -attrs==23.1.0 -Babel==2.12.1 -build==0.10.0 -certifi==2023.5.7 -charset-normalizer==3.1.0 -docutils==0.18.1 -frozenlist==1.3.3 -idna==3.4 -imagesize==1.4.1 -importlib-metadata==6.6.0 -Jinja2==3.1.2 -MarkupSafe==2.1.2 -multidict==6.0.4 -packaging==23.1 -perky==0.6.2 -pydantic==1.10.7 -Pygments==2.15.1 -pyproject_hooks==1.0.0 -PyYAML==6.0 -requests==2.30.0 -resolvelib==1.0.1 -rstcheck==5.0.0 -semantic-version==2.10.0 -sh==1.14.3 -six==1.16.0 -snowballstemmer==2.2.0 -Sphinx==5.3.0 -sphinx-ansible-theme==0.10.2 -sphinx-notfound-page==0.8.3 -sphinx-rtd-theme==1.2.0 -sphinxcontrib-applehelp==1.0.4 -sphinxcontrib-devhelp==1.0.2 -sphinxcontrib-htmlhelp==2.0.1 -sphinxcontrib-jquery==4.1 -sphinxcontrib-jsmath==1.0.1 -sphinxcontrib-qthelp==1.0.3 -sphinxcontrib-serializinghtml==1.1.5 -tomli==2.0.1 -Twiggy==0.5.1 -types-docutils==0.18.3 -typing_extensions==4.5.0 -urllib3==2.0.2 -yarl==1.9.2 -zipp==3.15.0 diff --git a/test/sanity/code-smell/package-data.py b/test/sanity/code-smell/package-data.py index a34ecbd2eb8..6c0879acb5e 100644 --- a/test/sanity/code-smell/package-data.py +++ b/test/sanity/code-smell/package-data.py @@ -55,21 +55,7 @@ def assemble_files_to_ship(complete_file_list): 'hacking/test-module', '.cherry_picker.toml', '.mailmap', - # Generated as part of a build step - 'docs/docsite/rst/conf.py', - 'docs/docsite/rst/index.rst', - 'docs/docsite/rst/dev_guide/index.rst', # Possibly should be included - 'examples/scripts/uptime.py', - 'examples/scripts/my_test.py', - 'examples/scripts/my_test_info.py', - 'examples/scripts/my_test_facts.py', - 'examples/DOCUMENTATION.yml', - 'examples/play.yml', - 'examples/hosts.yaml', - 'examples/hosts.yml', - 'examples/inventory_script_schema.json', - 'examples/plugin_filters.yml', 'hacking/env-setup', 'hacking/env-setup.fish', 'MANIFEST', diff --git a/test/sanity/code-smell/rstcheck.json b/test/sanity/code-smell/rstcheck.json deleted file mode 100644 index 870c19ffddd..00000000000 --- a/test/sanity/code-smell/rstcheck.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "output": "path-line-column-message", - "extensions": [ - ".rst" - ] -} diff --git a/test/sanity/code-smell/rstcheck.py b/test/sanity/code-smell/rstcheck.py deleted file mode 100644 index 4b5a43e69cd..00000000000 --- a/test/sanity/code-smell/rstcheck.py +++ /dev/null @@ -1,62 +0,0 @@ -"""Sanity test using rstcheck and sphinx.""" -from __future__ import annotations - -import re -import subprocess -import sys - - -def main(): - paths = sys.argv[1:] or sys.stdin.read().splitlines() - - encoding = 'utf-8' - - ignore_substitutions = ( - 'br', - ) - - cmd = [ - sys.executable, - '-c', 'import rstcheck; rstcheck.main();', - '--report', 'warning', - '--ignore-substitutions', ','.join(ignore_substitutions), - ] + paths - - process = subprocess.run(cmd, - stdin=subprocess.DEVNULL, - stdout=subprocess.PIPE, - stderr=subprocess.PIPE, - check=False, - ) - - if process.stdout: - raise Exception(process.stdout) - - pattern = re.compile(r'^(?P[^:]*):(?P[0-9]+): \((?PINFO|WARNING|ERROR|SEVERE)/[0-4]\) (?P.*)$') - - results = parse_to_list_of_dict(pattern, process.stderr.decode(encoding)) - - for result in results: - print('%s:%s:%s: %s' % (result['path'], result['line'], 0, result['message'])) - - -def parse_to_list_of_dict(pattern, value): - matched = [] - unmatched = [] - - for line in value.splitlines(): - match = re.search(pattern, line) - - if match: - matched.append(match.groupdict()) - else: - unmatched.append(line) - - if unmatched: - raise Exception('Pattern "%s" did not match values:\n%s' % (pattern, '\n'.join(unmatched))) - - return matched - - -if __name__ == '__main__': - main() diff --git a/test/sanity/code-smell/rstcheck.requirements.in b/test/sanity/code-smell/rstcheck.requirements.in deleted file mode 100644 index e50882bd9b1..00000000000 --- a/test/sanity/code-smell/rstcheck.requirements.in +++ /dev/null @@ -1,3 +0,0 @@ -sphinx == 5.3.0 # required for full rstcheck functionality, installed first to get the correct docutils version -rstcheck < 6 # match version used in other sanity tests - specifically docs-build -jinja2 # ansible-core requirement diff --git a/test/sanity/code-smell/rstcheck.requirements.txt b/test/sanity/code-smell/rstcheck.requirements.txt deleted file mode 100644 index de91b30b174..00000000000 --- a/test/sanity/code-smell/rstcheck.requirements.txt +++ /dev/null @@ -1,27 +0,0 @@ -# edit "rstcheck.requirements.in" and generate with: hacking/update-sanity-requirements.py --test rstcheck -alabaster==0.7.13 -Babel==2.12.1 -certifi==2022.12.7 -charset-normalizer==3.1.0 -docutils==0.18.1 -idna==3.4 -imagesize==1.4.1 -importlib-metadata==6.1.0 -Jinja2==3.1.2 -MarkupSafe==2.1.2 -packaging==23.0 -Pygments==2.14.0 -requests==2.28.2 -rstcheck==5.0.0 -snowballstemmer==2.2.0 -Sphinx==5.3.0 -sphinxcontrib-applehelp==1.0.4 -sphinxcontrib-devhelp==1.0.2 -sphinxcontrib-htmlhelp==2.0.1 -sphinxcontrib-jsmath==1.0.1 -sphinxcontrib-qthelp==1.0.3 -sphinxcontrib-serializinghtml==1.1.5 -types-docutils==0.18.3 -typing_extensions==4.5.0 -urllib3==1.26.15 -zipp==3.15.0 diff --git a/test/sanity/ignore.txt b/test/sanity/ignore.txt index bbd78a1b691..5a3c1f4d48b 100644 --- a/test/sanity/ignore.txt +++ b/test/sanity/ignore.txt @@ -1,9 +1,4 @@ .azure-pipelines/scripts/publish-codecov.py replace-urlopen -docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst no-smart-quotes -docs/docsite/rst/locales/ja/LC_MESSAGES/dev_guide.po no-smart-quotes # Translation of the no-smart-quotes rule -examples/scripts/ConfigureRemotingForAnsible.ps1 pslint:PSCustomUseLiteralPath -examples/scripts/upgrade_to_ps3.ps1 pslint:PSCustomUseLiteralPath -examples/scripts/upgrade_to_ps3.ps1 pslint:PSUseApprovedVerbs lib/ansible/cli/scripts/ansible_connection_cli_stub.py shebang lib/ansible/config/base.yml no-unwanted-files lib/ansible/executor/powershell/async_watchdog.ps1 pslint:PSCustomUseLiteralPath