wbrawner/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

removes the word 'support' from appendix pages (#61409)

Browse source
This commit is contained in:
Alicia Cozine 2019-08-27 16:11:53 -05:00 committed by Sandra McCann
parent 758c63e4fb
commit 6ad40fd6b8
6 changed files with 33 additions and 36 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
docs/docsite/rst/reference_appendices/faq.rst
View file

@ -160,10 +160,9 @@ Please refer the documentation of the respective package for such dependencies a
Common Platform Issues
++++++++++++++++++++++
What customer platforms does Red Hat Support?
What customer platforms does Red Hat support?
---------------------------------------------
A number of them! For a definitive list please see this `Knowledge Base article <https://access.redhat.com/articles/3168091>`_.
Running in a virtualenv
@ -495,8 +494,8 @@ In OpenBSD, a similar option is available in the base system called encrypt(1):
.. _dot_or_array_notation:
Ansible supports dot notation and array notation for variables. Which notation should I use?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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
@ -639,9 +638,8 @@ For 'non host vars' you can use the :ref:`vars lookup<vars_lookup>` plugin:
Why don't you ship in X format?
+++++++++++++++++++++++++++++++
Several reasons, in most cases it has to do with maintainability, there are tons of ways to ship software and it is a herculean task to try to support them all.
In other cases there are technical issues, for example, for python wheels, our dependencies are not present so there is little to no gain.
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.
.. _ansible_host_delegated:

4
docs/docsite/rst/reference_appendices/galaxy.rst
View file

@ -96,7 +96,7 @@ Each role in the file will have one or more of the following attributes:
The source of the role. Use the format *username.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 supported. See the examples below. Defaults to *git*.
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:
@ -183,7 +183,7 @@ Dependencies
Roles can also be dependent on other roles, and when you install a role that has dependencies, those dependencies will automatically be installed.
You specify role dependencies in the ``meta/main.yml`` file by providing a list of roles. If the source of a role is Galaxy, you can simply specify the role in
the format ``username.role_name``. The more complex format used in ``requirements.yml`` is also supported, allowing you to provide ``src``, ``scm``, ``version``, and ``name``.
the format ``username.role_name``. You can also use the more complex format in ``requirements.yml``, allowing you to provide ``src``, ``scm``, ``version``, and ``name``.
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.

4
docs/docsite/rst/reference_appendices/general_precedence.rst
View file

@ -3,7 +3,7 @@
Controlling how Ansible behaves: precedence rules
=================================================
To give you maximum flexibility in managing your environments, Ansible supports many ways to control how Ansible behaves: how it connects to managed nodes, how it works once it has connected.
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.
@ -15,7 +15,7 @@ These precedence rules apply to any setting that can be defined in multiple ways
Precedence categories
---------------------
Ansible supports four sources for controlling its behavior. In order of precedence from lowest (most easily overridden) to highest (overrides all others), the categories are:
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

5
docs/docsite/rst/reference_appendices/glossary.rst
View file

@ -51,7 +51,7 @@ when a term comes up on the mailing list.
Connection Plugin
By default, Ansible talks to remote machines through pluggable
libraries. Ansible supports native OpenSSH (:term:`SSH (Native)`) or
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
@ -319,7 +319,7 @@ when a term comes up on the mailing list.
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 desiring Kerberos or Jump Host support may wish to switch
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.
@ -499,4 +499,3 @@ when a term comes up on the mailing list.
Have a question? Stop by the google group!
`irc.freenode.net <http://irc.freenode.net>`_
#ansible IRC chat channel

6
docs/docsite/rst/reference_appendices/python_3_support.rst
View file

@ -2,11 +2,11 @@
Python 3 Support
================
Ansible 2.5 and above have support for Python 3. Previous to 2.5, the Python 3 support was
considered a tech preview. This topic discusses how to setup your controller and managed machines
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.
.. note:: Ansible supports Python version 3.5 and above only.
.. note:: Ansible works with Python version 3.5 and above only.
On the controller side
----------------------

38
docs/docsite/rst/reference_appendices/release_and_maintenance.rst
View file

@ -15,15 +15,15 @@ Ansible is developed and released on a flexible 4 months 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.
Ansible has a graduated support structure that extends to three major releases.
Ansible 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 supported.
see the chart in :ref:`release_schedule` for the degrees to which current releases are maintained.
If you are using a release of Ansible that is no longer supported, we strongly
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.
Older, unsupported versions of Ansible can contain unfixed security
Older, unmaintained versions of Ansible can contain unfixed security
vulnerabilities (*CVE*).
You can refer to the :ref:`porting guides<porting_guides>` for tips on updating your Ansible
@ -39,22 +39,22 @@ This table links to the release notes for each major release. These release note
Ansible Release Status
============================== =================================================
devel In development (2.9 unreleased, trunk)
`2.8 Release Notes`_ Supported (security **and** general bug fixes)
`2.7 Release Notes`_ Supported (security **and** critical bug fixes)
`2.6 Release Notes`_ Supported (security fixes)
`2.5 Release Notes`_ Unsupported (end of life)
`2.4 Release Notes`_ Unsupported (end of life)
`2.3 Release Notes`_ Unsupported (end of life)
`2.2 Release Notes`_ Unsupported (end of life)
`2.1 Release Notes`_ Unsupported (end of life)
`2.0 Release Notes`_ Unsupported (end of life)
`1.9 Release Notes`_ Unsupported (end of life)
<1.9 Unsupported (end of life)
`2.8 Release Notes`_ Maintained (security **and** general bug fixes)
`2.7 Release Notes`_ Maintained (security **and** critical bug fixes)
`2.6 Release Notes`_ Maintained (security fixes)
`2.5 Release Notes`_ Unmaintained (end of life)
`2.4 Release Notes`_ Unmaintained (end of life)
`2.3 Release Notes`_ Unmaintained (end of life)
`2.2 Release Notes`_ Unmaintained (end of life)
`2.1 Release Notes`_ Unmaintained (end of life)
`2.0 Release Notes`_ Unmaintained (end of life)
`1.9 Release Notes`_ Unmaintained (end of life)
<1.9 Unmaintained (end of life)
============================== =================================================
You can download the releases from `<https://releases.ansible.com/ansible/>`_.
.. note:: Ansible support lasts for 3 releases. Thus the latest Ansible release receives
.. note:: Ansible maintenance continues for 3 releases. Thus the latest Ansible release receives
security and general bug fixes when it is first released, security and critical bug fixes when
the next Ansible version is released, and **only** security fixes once the follow on to that version is released.
@ -85,17 +85,17 @@ Development and stable version maintenance workflow
The Ansible community develops and maintains Ansible on GitHub_.
New modules, plugins, features and bugfixes will always be integrated in what will become the next
major version of Ansible. This work is tracked on the ``devel`` git branch.
major version of Ansible. This work is tracked on the ``devel`` git branch.
Ansible provides bugfixes and security improvements for the most recent major release. The previous
major release will only receive fixes for security issues and critical bugs. Ansible only applies
security fixes to releases which are two releases old. This work is tracked on the
``stable-<version>`` git branches.
The fixes that land in supported stable branches will eventually be released
The fixes that land in maintained stable branches will eventually be released
as a new version when necessary.
Note that while there are no guarantees for providing fixes for unsupported
Note that while there are no guarantees for providing fixes for Unmaintained
releases of Ansible, there can sometimes be exceptions for critical issues.
.. _GitHub: https://github.com/ansible/ansible