docs/docsite/rst/: fix typos (#67645)

pull/67645/merge
Andrew Klychkov 5 years ago committed by GitHub
parent 244277addd
commit ad8df69b58
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -89,7 +89,7 @@ These required packages are listed in two :file:`requirements.txt` files to make
pip install --user -r requirements.txt pip install --user -r requirements.txt
pip install --user -r docs/docsite/requirements.txt pip install --user -r docs/docsite/requirements.txt
You can drop ``--user`` if you have set up a virtual invironment (venv/virtenv). You can drop ``--user`` if you have set up a virtual environment (venv/virtenv).
.. note:: .. note::

@ -33,7 +33,7 @@ You can find the official :ref:`Ansible communication channels <communication>`.
Review, fix, and maintain the documentation 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 out-dated examples. We offer easy ways to :ref:`report and/or fix documentation errors <community_documentation_contributions>`. 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 <community_documentation_contributions>`.
.. _ansible_community_meetup: .. _ansible_community_meetup:

@ -4,7 +4,7 @@
Galaxy Developer Guide Galaxy Developer Guide
********************** **********************
You can host collections and roles on Galaxy to share with the Ansible community. Galaxy content is formated in pre-packaged units of work such as :ref:`roles <playbooks_reuse_roles>`, and new in Galaxy 3.2, :ref:`collections <collections>`. 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 <playbooks_reuse_roles>`, and new in Galaxy 3.2, :ref:`collections <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. 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:: .. contents::
@ -237,7 +237,7 @@ Provide the ID of the integration to be disabled. You can find the ID by using t
.. seealso:: .. seealso::
:ref:`collections` :ref:`collections`
Sharable collections of modules, playbooks and roles Shareable collections of modules, playbooks and roles
:ref:`playbooks_reuse_roles` :ref:`playbooks_reuse_roles`
All about ansible roles All about ansible roles
`Mailing List <https://groups.google.com/group/ansible-project>`_ `Mailing List <https://groups.google.com/group/ansible-project>`_

@ -448,6 +448,6 @@ Use ``remove`` to delete a role from *roles_path*:
.. seealso:: .. seealso::
:ref:`collections` :ref:`collections`
Sharable collections of modules, playbooks and roles Shareable collections of modules, playbooks and roles
:ref:`playbooks_reuse_roles` :ref:`playbooks_reuse_roles`
Reusable tasks, handlers, and other files in a known directory structure Reusable tasks, handlers, and other files in a known directory structure

@ -7,7 +7,7 @@ Cliconf Plugins
:local: :local:
:depth: 2 :depth: 2
Cliconf plugins are abstactions over the CLI interface to network devices. They provide a standard interface 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. for Ansible to execute tasks on those network devices.
These plugins generally correspond one-to-one to network device platforms. The appropriate cliconf plugin will These plugins generally correspond one-to-one to network device platforms. The appropriate cliconf plugin will

@ -7,7 +7,7 @@ Netconf Plugins
:local: :local:
:depth: 2 :depth: 2
Netconf plugins are abstactions over the Netconf interface to network devices. They provide a standard interface 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. for Ansible to execute tasks on those network devices.
These plugins generally correspond one-to-one to network device platforms. The appropriate netconf plugin will These plugins generally correspond one-to-one to network device platforms. The appropriate netconf plugin will

@ -3,7 +3,7 @@
Red Hat Ansible Tower Red Hat Ansible Tower
===================== =====================
`Red Hat Ansible Tower <https://www.ansible.com/products/tower>`_ is a web console and REST API for operationalizing Ansible across your team, organization, and enterpise. It's designed to be the hub for all of your automation tasks. `Red Hat Ansible Tower <https://www.ansible.com/products/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.
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 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. complex processes.

@ -183,7 +183,7 @@ The following playbook will create an SSH key, 3 Packet servers, and then wait u
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. 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 via the 'project_id' parameter. The servers are all provisioned with CoresOS beta (the 'operating_system' parameter) and are customized with cloud-config user data passed to the 'user_data' parameter. 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.
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. 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.

@ -554,7 +554,7 @@ Build a complete webserver environment with servers, custom networks and load ba
RackConnect and Managed 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 un-usable servers. 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. These examples show creating servers, and ensuring that the Rackspace automation has completed before Ansible continues onwards.

@ -64,7 +64,7 @@ define the following keys:
* ``url``: The URL of the Galaxy instance to connect to. Required. * ``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``. * ``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``. * ``username``: The username to use for basic authentication against the Galaxy instance. Mutually exclusive with ``token``.
* ``password``: The password to use, in conjuction with ``username``, for basic authentication. * ``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, Automation Hub). Mutually exclusive with ``username``. Requires ``token``. * ``auth_url``: The URL of a Keycloak server 'token_endpoint' if using SSO authentication (for example, Automation Hub). Mutually exclusive with ``username``. Requires ``token``.
As well as defining these server options in the ``ansible.cfg`` file, you can also define them as environment variables. As well as defining these server options in the ``ansible.cfg`` file, you can also define them as environment variables.

Loading…
Cancel
Save