mirror of
https://github.com/saltstack/salt.git
synced 2025-04-17 10:10:20 +00:00
Remove repeated words in docs (#37871)
Found using find . -name '*.rst' | xargs igor -R -r
This commit is contained in:
parent
7d4ef4caf9
commit
3f2e13d1fc
36 changed files with 44 additions and 44 deletions
|
@ -195,7 +195,7 @@ Glossary
|
|||
of runner modules <all-salt.runners>`.
|
||||
|
||||
Runner Function
|
||||
A function which is is called by the :command:`salt-run` command and
|
||||
A function which is called by the :command:`salt-run` command and
|
||||
executes on the master instead of on a minion. *See also*:
|
||||
:term:`Runner Module`.
|
||||
|
||||
|
|
|
@ -3037,7 +3037,7 @@ will have syndic servers(s) below it, set the "order_masters" setting to True.
|
|||
If this is a master that will be running a syndic daemon for passthrough the
|
||||
"syndic_master" setting needs to be set to the location of the master server.
|
||||
|
||||
Do not not forget that, in other words, it means that it shares with the local minion
|
||||
Do not forget that, in other words, it means that it shares with the local minion
|
||||
its ID and PKI_DIR.
|
||||
|
||||
.. conf_master:: order_masters
|
||||
|
|
|
@ -39,7 +39,7 @@ Default: ``salt``
|
|||
|
||||
master: salt
|
||||
|
||||
The option can can also be set to a list of masters, enabling
|
||||
The option can also be set to a list of masters, enabling
|
||||
:doc:`multi-master </topics/tutorials/multimaster>` mode.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
@ -2192,7 +2192,7 @@ List of git repositories to checkout and include in the winrepo
|
|||
- https://github.com/saltstack/salt-winrepo.git
|
||||
|
||||
To specify a specific revision of the repository, prepend a commit ID to the
|
||||
URL of the the repository:
|
||||
URL of the repository:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
|
@ -114,7 +114,7 @@ module implement the ``render`` function.
|
|||
|
||||
The ``render`` function will be passed the path of the SLS file as an argument.
|
||||
|
||||
The purpose of of ``render`` function is to parse the passed file and to return
|
||||
The purpose of the ``render`` function is to parse the passed file and to return
|
||||
the Python data structure derived from the file.
|
||||
|
||||
Custom renderers must be placed in a ``_renderers`` directory within the
|
||||
|
|
|
@ -124,7 +124,7 @@ Identifier matching
|
|||
|
||||
Requisites match on both the ID Declaration and the ``name`` parameter.
|
||||
This means that, in the "Deploy server package" example above, a ``require``
|
||||
requisite would match with with ``Deploy server package`` *or* ``/usr/local/share/myapp.tar.xz``,
|
||||
requisite would match with ``Deploy server package`` *or* ``/usr/local/share/myapp.tar.xz``,
|
||||
so either of the following versions for "Extract server package" works:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
@ -412,7 +412,7 @@ if any of the watched states changes.
|
|||
``cmd.run`` state has changes (which it always will, since the ``cmd.run``
|
||||
state includes the command results as changes).
|
||||
|
||||
It may semantically seem like the the ``cmd.run`` state should only run
|
||||
It may semantically seem like the ``cmd.run`` state should only run
|
||||
when there are changes in the file state, but remember that requisite
|
||||
relationships involve one state watching another state, and a
|
||||
:ref:`requisite_in <requisites-onchanges-in>` does the opposite: it forces
|
||||
|
|
|
@ -6,8 +6,8 @@ Master Tops
|
|||
===========
|
||||
|
||||
Salt includes a number of built-in subsystems to generate top file data, they
|
||||
are listed listed at
|
||||
are listed at
|
||||
:ref:`all-salt.tops`.
|
||||
|
||||
The source for the built-in Salt master tops can be found here:
|
||||
:blob:`salt/tops`
|
||||
:blob:`salt/tops`
|
||||
|
|
|
@ -119,7 +119,7 @@ manager. These do not need to be handled by the developer in the cloud module.
|
|||
The ``salt.utils.cloud.validate_windows_cred()`` function has been extended to
|
||||
take the number of retries and retry_delay parameters in case a specific cloud
|
||||
host has a delay between providing the Windows credentials and the
|
||||
credentials being available for use. In their ``create()`` function, or as a
|
||||
credentials being available for use. In their ``create()`` function, or as
|
||||
a sub-function called during the creation process, developers should use the
|
||||
``win_deploy_auth_retries`` and ``win_deploy_auth_retry_delay`` parameters from
|
||||
the provider configuration to allow the end-user the ability to customize the
|
||||
|
|
|
@ -12,7 +12,7 @@ http://cloud.dimensiondata.com/
|
|||
|
||||
CaaS has its own non-standard `API`_ , SaltStack provides a
|
||||
wrapper on top of this `API`_ with common methods with other IaaS solutions and
|
||||
Public cloud providers. Therefore, you can use use the Dimension Data
|
||||
Public cloud providers. Therefore, you can use the Dimension Data
|
||||
module to communicate with both the public and private clouds.
|
||||
|
||||
|
||||
|
|
|
@ -209,7 +209,7 @@ ssh_public_key
|
|||
|
||||
ssh_interface
|
||||
This option will use the private LAN IP for node connections (such as
|
||||
as bootstrapping the node) instead of the public LAN IP. The value accepts
|
||||
bootstrapping the node) instead of the public LAN IP. The value accepts
|
||||
'private_lan'.
|
||||
|
||||
cpu_family
|
||||
|
|
|
@ -100,7 +100,7 @@ a few examples:
|
|||
size: m3.large
|
||||
|
||||
Notice that the ``provider`` in our profile matches the provider name that we
|
||||
defined? That is how Salt Cloud knows how to connect to to a cloud host to
|
||||
defined? That is how Salt Cloud knows how to connect to a cloud host to
|
||||
create a VM with these attributes.
|
||||
|
||||
Create VMs
|
||||
|
|
|
@ -26,7 +26,7 @@ https://pypi.python.org/packages/source/s/salt-cloud/salt-cloud-0.7.0.tar.gz
|
|||
|
||||
https://cloud.github.com/downloads/saltstack/salt-cloud/salt-cloud-0.7.0.tar.gz
|
||||
|
||||
Some packages have been made available for salt-cloud and more on on their
|
||||
Some packages have been made available for salt-cloud and more on their
|
||||
way. Packages for Arch, and FreeBSD are being made available thanks to the
|
||||
work of Christer Edwards, and packages for RHEL and Fedora are being created
|
||||
by Clint Savage. Package availability will be announced on the salt mailing list.
|
||||
|
|
|
@ -21,7 +21,7 @@ https://pypi.python.org/packages/source/s/salt-cloud/salt-cloud-0.8.0.tar.gz
|
|||
|
||||
https://cloud.github.com/downloads/saltstack/salt-cloud/salt-cloud-0.8.0.tar.gz
|
||||
|
||||
Some packages have been made available for salt-cloud and more on on their
|
||||
Some packages have been made available for salt-cloud and more on their
|
||||
way. Packages for Arch, and FreeBSD are being made available thanks to the
|
||||
work of Christer Edwards, and packages for RHEL and Fedora are being created
|
||||
by Clint Savage. Package availability will be announced on the salt mailing list.
|
||||
|
|
|
@ -21,7 +21,7 @@ https://pypi.python.org/packages/source/s/salt-cloud/salt-cloud-0.8.1.tar.gz
|
|||
|
||||
https://cloud.github.com/downloads/saltstack/salt-cloud/salt-cloud-0.8.1.tar.gz
|
||||
|
||||
Some packages have been made available for salt-cloud and more on on their
|
||||
Some packages have been made available for salt-cloud and more on their
|
||||
way. Packages for Arch, and FreeBSD are being made available thanks to the
|
||||
work of Christer Edwards, and packages for RHEL and Fedora are being created
|
||||
by Clint Savage. Package availability will be announced on the salt mailing list.
|
||||
|
|
|
@ -22,7 +22,7 @@ https://pypi.python.org/packages/source/s/salt-cloud/salt-cloud-0.8.2.tar.gz
|
|||
|
||||
https://cloud.github.com/downloads/saltstack/salt-cloud/salt-cloud-0.8.2.tar.gz
|
||||
|
||||
Some packages have been made available for salt-cloud and more on on their
|
||||
Some packages have been made available for salt-cloud and more on their
|
||||
way. Packages for Arch, and FreeBSD are being made available thanks to the
|
||||
work of Christer Edwards, and packages for RHEL and Fedora are being created
|
||||
by Clint Savage. Package availability will be announced on the salt mailing list.
|
||||
|
|
|
@ -20,7 +20,7 @@ https://pypi.python.org/packages/source/s/salt-cloud/salt-cloud-0.8.3.tar.gz
|
|||
|
||||
https://cloud.github.com/downloads/saltstack/salt-cloud/salt-cloud-0.8.3.tar.gz
|
||||
|
||||
Some packages have been made available for salt-cloud and more on on their
|
||||
Some packages have been made available for salt-cloud and more on their
|
||||
way. Packages for Arch and FreeBSD are being made available thanks to the
|
||||
work of Christer Edwards, and packages for RHEL and Fedora are being created
|
||||
by Clint Savage. Package availability will be announced on the salt mailing list.
|
||||
|
@ -64,7 +64,7 @@ the default login users. Your mileage will vary.
|
|||
Exception Handling
|
||||
==================
|
||||
There were a handful of spots in the code which would exit when an error
|
||||
occurred, sometimes without any meaningful error messages. This was was neither
|
||||
occurred, sometimes without any meaningful error messages. This was neither
|
||||
helpful to the user, nor Pythonic. Errors now should fire an exception of some
|
||||
sort, and if the error is Salt- or Salt Cloud-specific, a SaltException will be
|
||||
fired. This also helps pave the way for API usage of Salt Cloud.
|
||||
|
|
|
@ -18,7 +18,7 @@ Salt Cloud can be downloaded and install via pypi:
|
|||
|
||||
https://pypi.python.org/packages/source/s/salt-cloud/salt-cloud-0.8.4.tar.gz
|
||||
|
||||
Some packages have been made available for salt-cloud and more on on their
|
||||
Some packages have been made available for salt-cloud and more on their
|
||||
way. Packages for Arch and FreeBSD are being made available thanks to the
|
||||
work of Christer Edwards, and packages for RHEL and Fedora are being created
|
||||
by Clint Savage. The Ubuntu PPA is being managed by Sean Channel. Package
|
||||
|
|
|
@ -20,7 +20,7 @@ Salt Cloud can be downloaded and install via pypi:
|
|||
|
||||
https://pypi.python.org/packages/source/s/salt-cloud/salt-cloud-0.8.5.tar.gz
|
||||
|
||||
Some packages have been made available for salt-cloud and more on on their
|
||||
Some packages have been made available for salt-cloud and more on their
|
||||
way. Packages for Arch and FreeBSD are being made available thanks to the
|
||||
work of Christer Edwards, and packages for RHEL and Fedora are being created
|
||||
by Clint Savage. The Ubuntu PPA is being managed by Sean Channel. Package
|
||||
|
|
|
@ -18,7 +18,7 @@ Salt Cloud can be downloaded and install via pypi:
|
|||
|
||||
https://pypi.python.org/packages/source/s/salt-cloud/salt-cloud-0.8.6.tar.gz
|
||||
|
||||
Some packages have been made available for salt-cloud and more on on their
|
||||
Some packages have been made available for salt-cloud and more on their
|
||||
way. Packages for Arch and FreeBSD are being made available thanks to the
|
||||
work of Christer Edwards, and packages for RHEL and Fedora are being created
|
||||
by Clint Savage. The Ubuntu PPA is being managed by Sean Channel. Package
|
||||
|
|
|
@ -38,7 +38,7 @@ Salt Cloud can be downloaded and install via pypi:
|
|||
|
||||
https://pypi.python.org/packages/source/s/salt-cloud/salt-cloud-0.8.7.tar.gz
|
||||
|
||||
Some packages have been made available for salt-cloud and more on on their
|
||||
Some packages have been made available for salt-cloud and more on their
|
||||
way. Packages for Arch and FreeBSD are being made available thanks to the
|
||||
work of Christer Edwards, and packages for RHEL and Fedora are being created
|
||||
by Clint Savage. The Ubuntu PPA is being managed by Sean Channel. Package
|
||||
|
|
|
@ -20,7 +20,7 @@ Salt Cloud can be downloaded and install via pypi:
|
|||
|
||||
https://pypi.python.org/packages/source/s/salt-cloud/salt-cloud-0.8.9.tar.gz
|
||||
|
||||
Some packages have been made available for salt-cloud and more on on their
|
||||
Some packages have been made available for salt-cloud and more on their
|
||||
way. Packages for Arch and FreeBSD are being made available thanks to the
|
||||
work of Christer Edwards, and packages for RHEL and Fedora are being created
|
||||
by Clint Savage. The Ubuntu PPA is being managed by Sean Channel. Package
|
||||
|
@ -178,4 +178,4 @@ configured:
|
|||
We're now always aware of what was done using what.
|
||||
|
||||
|
||||
.. include:: <isoamsa.txt>
|
||||
.. include:: <isoamsa.txt>
|
||||
|
|
|
@ -13,4 +13,4 @@ Legacy salt-cloud Release Notes
|
|||
:maxdepth: 1
|
||||
:glob:
|
||||
|
||||
*
|
||||
*
|
||||
|
|
|
@ -19,7 +19,7 @@ New Code Entry
|
|||
All new SaltStack code should be submitted against either the ``develop`` branch
|
||||
or a point release branch, depending on the nature of the submission. Please see
|
||||
the :ref:`Which Salt Branch? <which-salt-branch>` section of Salt's
|
||||
:ref:`Contributing <contributing>` documentation or the Release Branching section
|
||||
:ref:`Contributing <contributing>` documentation or the Release Branching
|
||||
section below for more information.
|
||||
|
||||
Release Branching
|
||||
|
@ -75,4 +75,4 @@ if there is a security fix they can be made sooner.
|
|||
The point release is only designated by tagging the commit on the release
|
||||
branch with a release number using the existing convention (version 2015.8.1
|
||||
is tagged with v2015.8.1). From the tag point a new source tarball is generated
|
||||
and published to PyPI, and a release announcement is made.
|
||||
and published to PyPI, and a release announcement is made.
|
||||
|
|
|
@ -274,7 +274,7 @@ external template file.
|
|||
Escaping Jinja
|
||||
==============
|
||||
|
||||
Occasionally, it may be necessary to escape Jinja syntax. There are two ways to
|
||||
Occasionally, it may be necessary to escape Jinja syntax. There are two ways
|
||||
to do this in Jinja. One is escaping individual variables or strings and the
|
||||
other is to escape entire blocks.
|
||||
|
||||
|
|
|
@ -77,7 +77,7 @@ For example, the MySQL returner requires:
|
|||
|
||||
* A database created using provided schema (structure is available at
|
||||
:mod:`MySQL returner <salt.returners.mysql>`)
|
||||
* A user created with with privileges to the database
|
||||
* A user created with privileges to the database
|
||||
* Optional SSL configuration
|
||||
|
||||
A simpler returner, such as Slack or HipChat, requires:
|
||||
|
|
|
@ -298,7 +298,7 @@ More Testing, More BugFixes
|
|||
---------------------------
|
||||
|
||||
0.9.5 comes with more bugfixes due to more testing than any previous release.
|
||||
The growing community and the introduction a a dedicated QA environment have
|
||||
The growing community and the introduction a dedicated QA environment have
|
||||
unearthed many issues that were hiding under the covers. This has further
|
||||
refined and cleaned the state interface, taking care of things from minor
|
||||
visual issues to repairing misleading data.
|
||||
|
|
|
@ -73,7 +73,7 @@ lookup_jid
|
|||
``````````
|
||||
|
||||
When jobs are executed the return data is sent back to the master and cached.
|
||||
By default is is cached for 24 hours, but this can be configured via the
|
||||
By default is cached for 24 hours, but this can be configured via the
|
||||
``keep_jobs`` option in the master configuration.
|
||||
|
||||
Using the ``lookup_jid`` runner will display the same return data that the
|
||||
|
@ -177,4 +177,4 @@ Nodegroups in the Top File
|
|||
Previously the nodegroups defined in the master configuration file could not
|
||||
be used to match nodes for states. The nodegroups support has been expanded
|
||||
and the nodegroups defined in the master configuration can now be used to
|
||||
match minions in the top file.
|
||||
match minions in the top file.
|
||||
|
|
|
@ -131,7 +131,7 @@ GitFS Improvements
|
|||
|
||||
Several performance improvements have been made to the :mod:`Git fileserver
|
||||
backend <salt.fileserver.gitfs>`. Additionally, file states can now use any
|
||||
any SHA1 commit hash as a fileserver environment:
|
||||
SHA1 commit hash as a fileserver environment:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
|
@ -251,7 +251,7 @@ Module Changes
|
|||
previous behavior (:pull:`30275`). A ``bind`` function was also added that allows
|
||||
binding zones to interfaces and sources (:pull:`29497`).
|
||||
- :mod:`journald beacon module <salt.beacons.journald>`: The event string was updated
|
||||
to include a tag. Note this this might impact existing reactors based on this beacon.
|
||||
to include a tag. Note this might impact existing reactors based on this beacon.
|
||||
(:pull:`30116`).
|
||||
- :mod:`postgres_privileges state module <salt.states.postgres_privileges>`:
|
||||
The default value of the ``prepend`` argument was changed from ``None`` to
|
||||
|
|
|
@ -237,7 +237,7 @@ flag and look for a line containing the string, ``SALT_ARGV``. This contains the
|
|||
command that ``salt-ssh`` attempted to execute.
|
||||
|
||||
It is recommended that one modify this command a bit by removing the ``-l quiet``,
|
||||
``--metadata`` and ``--output json`` to get a better idea of what's going on on the target system.
|
||||
``--metadata`` and ``--output json`` to get a better idea of what's going on the target system.
|
||||
|
||||
.. toctree::
|
||||
|
||||
|
|
|
@ -57,8 +57,8 @@ Compound Targeting
|
|||
.. versionadded:: 0.9.5
|
||||
|
||||
Multiple target interfaces can be used in conjunction to determine the command
|
||||
targets. These targets can then be combined using and or or statements. This
|
||||
is well defined with an example:
|
||||
targets. These targets can then be combined using ``and`` or ``or`` statements.
|
||||
This is well defined with an example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
|
|
@ -157,7 +157,7 @@ When a ``salt-master`` daemon issues a command, it will be received by the
|
|||
Syndic and Minion nodes directly connected to it. A Minion node will process
|
||||
the command in the way it ordinarily would. On a Syndic node, the
|
||||
``salt-syndic`` daemon will relay the command to the ``salt-master`` daemon
|
||||
running on the Syndic node, which then propagates the command to to the Minions
|
||||
running on the Syndic node, which then propagates the command to the Minions
|
||||
and Syndics connected to it.
|
||||
|
||||
When events and job return data are generated by ``salt-minion`` daemons, they
|
||||
|
|
|
@ -202,7 +202,7 @@ may be updating for an ESXi host either via the
|
|||
execution module function or via the
|
||||
:doc:`esxi.password_present </ref/modules/all/salt.states.esxi>` state
|
||||
function. This way, after the password is changed, you should not need to
|
||||
restart the proxy minion--it should just pick up the the new password
|
||||
restart the proxy minion--it should just pick up the new password
|
||||
provided in the list. You can then change pillar at will to move that
|
||||
password to the front and retire the unused ones.
|
||||
|
||||
|
|
|
@ -546,7 +546,7 @@ of the Salt fileserver.
|
|||
Before the addition of this feature, if a file being served up via gitfs was
|
||||
deeply nested within the root directory (for example,
|
||||
``salt://webapps/foo/files/foo.conf``, it would be necessary to ensure that the
|
||||
file was properly located in the remote repository, and that all of the the
|
||||
file was properly located in the remote repository, and that all of the
|
||||
parent directories were present (for example, the directories
|
||||
``webapps/foo/files/`` would need to exist at the root of the repository).
|
||||
|
||||
|
|
|
@ -51,7 +51,7 @@ There are two types of profiles:
|
|||
Container Profiles
|
||||
------------------
|
||||
|
||||
LXC container profiles are defined defined underneath the
|
||||
LXC container profiles are defined underneath the
|
||||
``lxc.container_profile`` config option:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
|
|
@ -4,7 +4,7 @@ Preseed Minion with Accepted Key
|
|||
|
||||
In some situations, it is not convenient to wait for a minion to start before
|
||||
accepting its key on the master. For instance, you may want the minion to
|
||||
bootstrap itself as soon as it comes online. You may also want to to let your
|
||||
bootstrap itself as soon as it comes online. You may also want to let your
|
||||
developers provision new development machines on the fly.
|
||||
|
||||
.. seealso:: Many ways to preseed minion keys
|
||||
|
|
|
@ -8,7 +8,7 @@ Windows Software Repository
|
|||
In 2015.8.0 and later, the Windows Software Repository cache is compiled on
|
||||
the Salt Minion, which enables pillar, grains and other things to be
|
||||
available during compilation time. To support this new functionality,
|
||||
a next-generation (ng) package repository was created. See See the
|
||||
a next-generation (ng) package repository was created. See the
|
||||
:ref:`Changes in Version 2015.8.0 <2015-8-0-winrepo-changes>` for details.
|
||||
|
||||
The SaltStack Windows Software Repository provides a package manager and software
|
||||
|
|
Loading…
Add table
Reference in a new issue