valitydev/salt
14
0
Fork 0
mirror of https://github.com/valitydev/salt.git synced 2024-11-07 00:55:19 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fixed several minor misspellings and acronym capitalizations.

Browse Source
This commit is contained in:
Gary Wilson Jr 2013-03-18 14:59:27 -05:00
parent 8c39c1743a
commit bd499e5640
56 changed files with 149 additions and 149 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/index.rst
View File

@ -15,7 +15,7 @@ for orchestration, remote execution, configuration management and much more.
Download
========
Salt source releases are available for download via pypi:
Salt source releases are available for download via PyPI:
https://pypi.python.org/pypi/salt
@ -201,7 +201,7 @@ Salt is many splendid things.
Looking for an easy way to manage software on Windows machines?
Search no more! Salt has an integrated software package manager for
Windows machines! Install software hosted on the master, somewhere on the
network, or any http, https, or ftp server.
network, or any HTTP, HTTPS, or ftp server.
Reference
---------

2
doc/ref/cli/salt.rst
View File

@ -32,7 +32,7 @@ Options
.. option:: -t TIMEOUT, --timeout=TIMEOUT
The timeout in seconds to wait for replies from the Salt minions. The
timeout number specifes how long the command line client will wait to
timeout number specifies how long the command line client will wait to
query the minions and check on running jobs.
.. option:: -s, --static

4
doc/ref/clientacl.rst
View File

@ -2,10 +2,10 @@
Client ACL system
=================
The salt client acl system is a means to allow system users other than root to
The salt client ACL system is a means to allow system users other than root to
have access to execute select salt commands on minions from the master.
The client acl system is configured in the master configuration file via the
The client ACL system is configured in the master configuration file via the
``client_acl`` configuration option. Under the ``client_acl`` configuration
option the users open to send commands are specified and then a list of regular
expressions which specify the minion functions which will be made available to

12
doc/ref/configuration/master.rst
View File

@ -72,7 +72,7 @@ seeing on the console(and then salt-master crashes)::
Too many open files (tcp_listener.cpp:335)
Aborted (core dumped)
By default this value will be the one of `ulimit -Hn`, ie, the hard limit for
By default this value will be the one of `ulimit -Hn`, i.e., the hard limit for
max open files.
If you wish to set a different value than the default one, uncomment and
@ -409,7 +409,7 @@ at the moment a single state fails
Default:: ``False``
Set all state calls to only test if they are going to acctually make changes
Set all state calls to only test if they are going to actually make changes
or just post what changes are going to be made
.. code-block:: yaml
@ -426,7 +426,7 @@ Master File Server Settings
Default: ``base: [/srv/salt]``
Salt runs a lightweight file server written in zeromq to deliver files to
Salt runs a lightweight file server written in ZeroMQ to deliver files to
minions. This file server is built into the master daemon and does not
require a dedicated port.
@ -706,7 +706,7 @@ One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
Default: ``%H:%M:%S``
The date and time format used in console log messages. Allowed date/time formating
The date and time format used in console log messages. Allowed date/time formatting
can be seen on http://docs.python.org/library/time.html#time.strftime
.. code-block:: yaml
@ -720,7 +720,7 @@ can be seen on http://docs.python.org/library/time.html#time.strftime
Default: ``%Y-%m-%d %H:%M:%S``
The date and time format used in log file messages. Allowed date/time formating
The date and time format used in log file messages. Allowed date/time formatting
can be seen on http://docs.python.org/library/time.html#time.strftime
.. code-block:: yaml
@ -762,7 +762,7 @@ be seen on http://docs.python.org/library/logging.html#logrecord-attributes
Default: ``{}``
This can be used to control logging levels more specificically. The
This can be used to control logging levels more specifically. The
example sets the main salt library at the 'warning' level, but sets
'salt.modules' to log at the 'debug' level:

12
doc/ref/configuration/minion.rst
View File

@ -180,7 +180,7 @@ executed. By default this feature is disabled, to enable set cache_jobs to
Default: ``/var/run/salt/minion``
The directory where unix sockets will be kept.
The directory where Unix sockets will be kept.
.. code-block:: yaml
@ -235,7 +235,7 @@ environment, set this value to ``False``.
Default: ``ipc``
Windows platforms lack posix IPC and must rely on slower TCP based inter-
Windows platforms lack POSIX IPC and must rely on slower TCP based inter-
process communications. Set ipc_mode to ``tcp`` on such systems.
.. code-block:: yaml
@ -450,7 +450,7 @@ Default: ``True``
autoload_dynamic_modules Turns on automatic loading of modules found in the
environments on the master. This is turned on by default, to turn of
autoloading modules when states run set this value to ``False``
auto-loading modules when states run set this value to ``False``
.. code-block:: yaml
@ -579,7 +579,7 @@ One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
Default: ``%H:%M:%S``
The date and time format used in console log messages. Allowed date/time formating
The date and time format used in console log messages. Allowed date/time formatting
can be seen on http://docs.python.org/library/time.html#time.strftime
.. code-block:: yaml
@ -593,7 +593,7 @@ can be seen on http://docs.python.org/library/time.html#time.strftime
Default: ``%Y-%m-%d %H:%M:%S``
The date and time format used in log file messages. Allowed date/time formating
The date and time format used in log file messages. Allowed date/time formatting
can be seen on http://docs.python.org/library/time.html#time.strftime
.. code-block:: yaml
@ -635,7 +635,7 @@ be seen on http://docs.python.org/library/logging.html#logrecord-attributes
Default: ``{}``
This can be used to control logging levels more specificically. This
This can be used to control logging levels more specifically. This
example sets the main salt library at the 'warning' level, but sets
'salt.modules' to log at the 'debug' level:

2
doc/ref/file_server/index.rst
View File

@ -46,7 +46,7 @@ like so:
# salt '*' cp.get_file "salt://{{grains.os}}/vimrc" /etc/vimrc template=jinja
This example would instruct all Salt minions to download the vimrc from a
directory with the same name as their os grain and copy it to /etc/vimrc
directory with the same name as their OS grain and copy it to /etc/vimrc
For larger files, the cp.get_file module also supports gzip compression.
Because gzip is CPU-intensive, this should only be used in

4
doc/ref/index.rst
View File

@ -15,7 +15,7 @@ Client API
----------
The primary interface used to extend Salt, is to simply use it. Salt executions
can be called via the Salt client api, making programming master side solutions
can be called via the Salt client API, making programming master side solutions
with Salt is easy.
Adding Loadable Plugins
@ -70,7 +70,7 @@ Renderers
`````````
Salt states are controlled by simple data structures, these structures can be
abstracted in a number of ways. While the default is to be in a yaml file
abstracted in a number of ways. While the default is to be in a YAML file
wrapped in a jinja template, any abstraction can be used. This means that any
format that can be dreamed is possible, so long as a renderer is written for
it.

2
doc/ref/modules/all/salt.modules.yumpkg.rst
View File

@ -4,7 +4,7 @@ salt.modules.yumpkg
.. versionadded:: 0.9.4
This module replaces the "yum" module in previous releases. It is backward
compatibile and uses the native yum Python interface instead of the CLI
compatible and uses the native yum Python interface instead of the CLI
interface.
.. automodule:: salt.modules.yumpkg

2
doc/ref/modules/index.rst
View File

@ -171,7 +171,7 @@ documentation for all available modules:
salt '*' sys.doc
This function simple prints out the docstrings found in the modules, when
writing Salt modules, please follow the formating conventions for docstrings as
writing Salt modules, please follow the formatting conventions for docstrings as
they appear in the other modules.
Adding Documentation to Salt Modules

4
doc/ref/python-api.rst
View File

@ -9,7 +9,7 @@ built directly into third party applications as a communication layer. The Salt
client API is very straightforward.
A number of client command methods are available depending on the exact
behaviour desired.
behavior desired.
Using the LocalClient API
=========================
@ -38,7 +38,7 @@ same interface used by the ``salt`` command line tool.
The tgt option is the target specification, by default a target is passed
in as a bash shell glob. The expr_form option allows the tgt to be passed
as either a pcre regular expression or as a Python list.
as either a PCRE regular expression or as a Python list.
.. cmdoption:: fun

12
doc/ref/renderers/all/salt.renderers.stateconf.rst
View File

@ -9,7 +9,7 @@ salt.renderers.stateconf
:platform: all
This module provides a custom renderer that process a salt file with a
specified templating engine(eg, jinja) and a chosen data renderer(eg, yaml),
specified templating engine(e.g., Jinja) and a chosen data renderer(e.g., YAML),
extract arguments for any ``stateconf.set`` state and provide the extracted
arguments (including salt specific args, such as 'require', etc) as template
context. The goal is to make writing reusable/configurable/ parameterized
@ -48,7 +48,7 @@ Here's a list of features enabled by this renderer.
The leading dot trick can be used with extending state ids as well,
so you can include relatively and extend relatively. For example, when
extending a state in `salt://some/other_file.sls`, eg,::
extending a state in `salt://some/other_file.sls`, e.g.,::
#!stateconf yaml . jinja
@ -75,7 +75,7 @@ Here's a list of features enabled by this renderer.
reference templates files used by your salt file.
- Recognizes the special state function, ``stateconf.set``, that configures a
default list of named arguments useable within the template context of
default list of named arguments usable within the template context of
the salt file. Example::
#!stateconf yaml . jinja
@ -174,7 +174,7 @@ Here's a list of features enabled by this renderer.
- Optionally(enabled by default, *disable* via the `-G` renderer option,
eg, in the shebang line: ``#!stateconf -G``), generates a
e.g., in the shebang line: ``#!stateconf -G``), generates a
``stateconf.set`` goal state(state id named as ``.goal`` by default,
configurable via the master/minion config option, ``stateconf_goal_state``)
that requires all other states in the salt file. Note, the ``.goal``
@ -186,7 +186,7 @@ Here's a list of features enabled by this renderer.
all states in the Tomcat sls file will be executed before some state in
the webapp sls file.
- Optionally(enable via the `-o` renderer option, eg, in the shebang line:
- Optionally(enable via the `-o` renderer option, e.g., in the shebang line:
``#!stateconf -o``), orders the states in a sls file by adding a
``require`` requisite to each state such that every state requires the
state defined just before it. The order of the states here is the order
@ -202,7 +202,7 @@ Here's a list of features enabled by this renderer.
there are many states defined in a sls file, then it tends to be easier
to see the order they will be executed with this feature.
You are still allowed to use all the requisites, with a few restricitons.
You are still allowed to use all the requisites, with a few restrictions.
You cannot ``require`` or ``watch`` a state defined *after* the current
state. Similarly, in a state, you cannot ``require_in`` or ``watch_in``
a state defined *before* it. Breaking any of the two restrictions above

6
doc/ref/renderers/index.rst
View File

@ -14,7 +14,7 @@ the SLS files can be any structured format that can be dreamed up.
Currently there is support for ``Jinja + YAML``, ``Mako + YAML``,
``Wempy + YAML``, ``Jinja + json`` ``Mako + json`` and ``Wempy + json``. But
renderers can be written to support anything. This means that the Salt states
could be managed by xml files, html files, puppet files, or any format that
could be managed by XML files, HTML files, puppet files, or any format that
can be translated into the data structure used by the state system.
Multiple Renderers
@ -49,7 +49,7 @@ Composing Renderers
-------------------
A renderer can be composed from other renderers by connecting them in a series
of pipes(``|``). In fact, the default ``Jinja + YAML`` renderer is implemented
by combining a yaml renderer and a jinja renderer. Such renderer configuration
by combining a YAML renderer and a Jinja renderer. Such renderer configuration
is specified as: ``jinja | yaml``.
Other renderer combinations are possible, here's a few examples:
@ -63,7 +63,7 @@ Other renderer combinations are possible, here's a few examples:
``jinja | mako | yaml``
This one allows you to use both jinja and mako templating syntax in the
input and then parse the final rendererd output as YAML.
input and then parse the final rendered output as YAML.
And here's a contrived example sls file using the ``jinja | mako | yaml`` renderer:

2
doc/ref/returners/index.rst
View File

@ -59,7 +59,7 @@ A simple returner is implemented here:
'''
Return information to a redis server
'''
# Get a redis commection
# Get a redis connection
serv = redis.Redis(
host='redis-serv.example.com',
port=6379,

8
doc/ref/states/index.rst
View File

@ -91,9 +91,9 @@ SLS Files
The Salt state files are simple sets of data. Since the SLS files are just data
they can be represented in a number of different ways. The default format is
yaml generated from a jinja template. This allows for the states files to have
yaml generated from a Jinja template. This allows for the states files to have
all the language constructs of Python and the simplicity of yaml. State files
can then be complicated jinja templates that translate down to yaml, or just
can then be complicated Jinja templates that translate down to yaml, or just
plain and simple yaml files!
The State files are constructed data structures in a simple format. The format
@ -179,9 +179,9 @@ source code:
:blob:`salt/renderers`
By default SLS files are rendered using jinja as a templating engine, and yaml
By default SLS files are rendered using Jinja as a templating engine, and yaml
as the serialization format. Since the rendering system can be extended simply
by adding a new renderer to the renderers directory, it is possible that any
structured file could be used to represent the SLS files.
In the future xml and raw Python will be added, as well as many other formats.
In the future XML and raw Python will be added, as well as many other formats.

6
doc/ref/states/requisites.rst
View File

@ -4,7 +4,7 @@ Requisites
The Salt requisite system is used to create relationships between states. The
core idea being, that when one state it dependent somehow on another that
interdependency can be easily defined.
inter-dependency can be easily defined.
Requisites come in two types. Direct requisites, and requisite_ins. The
relationships are directional, so a requisite statement makes the requiring
@ -133,8 +133,8 @@ Using ``require_in``
- running
The ``require_in`` statement is particularly useful when assigning a require
in a sperate sls file. For instance it may be common for httpd to require
components used to set up php or mod_python, but the http state does not need
in a separate sls file. For instance it may be common for httpd to require
components used to set up PHP or mod_python, but the HTTP state does not need
to be aware of the additional components that require it when it is set up:
http.sls

2
doc/ref/states/writing.rst
View File

@ -17,7 +17,7 @@ illustrate:
.. code-block:: yaml
/etc/salt/master: # maps to "name"
file: # maps to State module filename eg https://github.com/saltstack/salt/blob/develop/salt/states/file.py
file: # maps to State module filename e.g. https://github.com/saltstack/salt/blob/develop/salt/states/file.py
- managed # maps to the managed function in the file State module
- user: root # one of many options passed to the manage function
- group: root

2
doc/ref/syndic.rst
View File

@ -19,7 +19,7 @@ Configuring the Syndic
Since the Syndic only needs to be attached to a higher level master the
configuration is very simple. On a master that is running a syndic to connect
to a higher level master the syndic_master option needs to be set in the
master config file. The syndic_master option contains the hostname or ip
master config file. The syndic_master option contains the hostname or IP
address of the master server that can control the master that the syndic is
running on.

6
doc/ref/topology.rst
View File

@ -13,7 +13,7 @@ The Salt Master runs 2 network services. First is the ZeroMQ PUB system. This
service by default runs on port ``4505`` and can be configured via the
``publish_port`` option in the master configuration.
Second is the ZeroMQ REP system. This is a seperate interface used for all
Second is the ZeroMQ REP system. This is a separate interface used for all
bi-directional communication with minions. By default this system binds to
port ``4506`` and can be configured via the ``ret_port`` option in the master.
@ -22,8 +22,8 @@ PUB/SUB
The commands sent out via the salt client are broadcast out to the minions via
ZeroMQ PUB/SUB. This is done by allowing the minions to maintain a connection
back to the Salt Master and then all connecions are informed to download the
command data at once. The command data is kept extreamly small (usually less
back to the Salt Master and then all connections are informed to download the
command data at once. The command data is kept extremely small (usually less
than 1K) so it is not a burden on the network.
Return

6
doc/ref/windows-package-manager.rst
View File

@ -8,7 +8,7 @@ repository similar to what is provided by yum and apt on Linux.
By default, the Windows software repository is found at ``/srv/salt/win/repo``
Each piece of software should have its own directory which contains the
installers and a package definition file. This package definition file is a
yaml file named ``init.sls``.
YAML file named ``init.sls``.
The package definition file should look similar to this example for Firefox:
``/srv/salt/win/repo/firefox/init.sls``
@ -41,7 +41,7 @@ The package definition file should look similar to this example for Firefox:
uninstaller: '%ProgramFiles(x86)%/Mozilla Firefox/uninstall/helper.exe'
uninstall_flags: ' /S'
Add ``msiexec: True`` if using an msi installer requiring the use of ``msiexec
Add ``msiexec: True`` if using an MSI installer requiring the use of ``msiexec
/i`` to install and ``msiexec /x`` to uninstall.
``/srv/salt/win/repo/7zip/init.sls``
@ -121,7 +121,7 @@ Git Hosted Repo
Windows software package definitions can also be hosted in one or more git
repositories. The default repo is one hosted on Github.com by SaltStack, which
includes package definitions for open source software. This repo points to the
http or ftp locations of the installer files. Anyone is welcome to send a pull
HTTP or ftp locations of the installer files. Anyone is welcome to send a pull
request to this repo to add new package definitions. Browse the repo
here: `https://github.com/saltstack/salt-winrepo
<https://github.com/saltstack/salt-winrepo>`_ .

8
doc/topics/development/package_providers.rst
View File

@ -61,7 +61,7 @@ This function must also accept ``**kwargs``, in order to receive the
``fromrepo`` and ``repo`` keyword arguments from pkg states. Where supported,
these arguments should be used to find the install/upgrade candidate in the
specified repository. The ``fromrepo`` kwarg takes precedence over ``repo``, so
if both of those kwargs are present, the repository specifed in ``fromrepo``
if both of those kwargs are present, the repository specified in ``fromrepo``
should be used. However, if ``repo`` is used instead of ``fromrepo``, it should
still work, to preserve backwards compatibility with older versions of Salt.
@ -131,7 +131,7 @@ done:
dictionary values will be the path/URI for the package.
The second return value will be a string with two possbile values:
The second return value will be a string with two possible values:
``repository`` or ``file``. The :strong:`install` function can use this value
(if necessary) to build the proper command to install the targeted package(s).
@ -216,7 +216,7 @@ success.
mod_repo
^^^^^^^^
Modify the local configuration for one or more option for a conifigured repo.
Modify the local configuration for one or more option for a configured repo.
This is also the way to create new repository configuration on the local
system; if a repo is specified which does not yet exist, it will be created.
@ -247,7 +247,7 @@ function that requires that technique must still use the ``lowpkg`` version.
list_pkgs
^^^^^^^^^
Returns a dict of packages installed, including the package name and version.
Can accept a list of packages; if none are spcified, then all installed
Can accept a list of packages; if none are specified, then all installed
packages will be listed.
.. code-block:: python

2
doc/topics/eauth/access_control.rst
View File

@ -17,7 +17,7 @@ all of the three aforementioned systems. While this adds functionality to the
configuration in 0.10.4, it does not negate the old configuration.
Now specific functions can be opened up to specific minions from specific users
in the case of external auth and client acls, and for specific minions in the
in the case of external auth and client ACLs, and for specific minions in the
case of the peer system.
The access controls are manifested using matchers in these configurations:

2
doc/topics/event/index.rst
View File

@ -16,7 +16,7 @@ Listening for Events
The event system is accessed via the event library and can only be accessed
by the same system user that Salt is running as. To listen to events a
SaltEvent object needs to be created and then the get_event function needs to
be run. The SaltEvent object needs to know the location that the Salt unix
be run. The SaltEvent object needs to know the location that the Salt Unix
sockets are kept. In the configuration this is the ``sock_dir`` option. The
``sock_dir`` option defaults to "/var/run/salt/master" on most systems.

2
doc/topics/git/index.rst
View File

@ -74,4 +74,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 release number using the existing convention (version 0.11.1 is
tagged with v0.11.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.

4
doc/topics/index.rst
View File

@ -90,10 +90,10 @@ versatile as it is practical, suitable for any network.
Open
====
Salt is developed under the `Apache 2.0 licence`_, and can be used for
Salt is developed under the `Apache 2.0 license`_, and can be used for
open and proprietary projects. Please submit your expansions back to
the Salt project so that we can all benefit together as Salt grows.
Please feel free to sprinkle Salt around your systems and let the
deliciousness come forth.
.. _`Apache 2.0 licence`: http://www.apache.org/licenses/LICENSE-2.0.html
.. _`Apache 2.0 license`: http://www.apache.org/licenses/LICENSE-2.0.html

4
doc/topics/installation/rhel.rst
View File

@ -9,7 +9,7 @@ Installation
============
Salt and all dependencies have been accepted into the yum
reposities for EPEL5 and EPEL6. The latest salt version can be found in epel-testing, while an older but more tested version can be found in regular epel.
repositories for EPEL5 and EPEL6. The latest salt version can be found in epel-testing, while an older but more tested version can be found in regular epel.
Example showing how to install salt from epel-testing:
@ -17,7 +17,7 @@ Example showing how to install salt from epel-testing:
yum --enablerepo=epel-testing install salt-minion
On RHEL6, the proper jinja package 'python-jinja2' was moved from EPEL to the
On RHEL6, the proper Jinja package 'python-jinja2' was moved from EPEL to the
"RHEL Server Optional Channel". Verify this repository is enabled before
installing salt on RHEL6.

4
doc/topics/installation/solaris.rst
View File

@ -12,7 +12,7 @@ starts up successfully on Solaris 10.
Comments and patches for better support on these platforms is very welcome.
As of version 0.10.4, solaris is well supported under salt, with all of the
As of version 0.10.4, Solaris is well supported under salt, with all of the
following working well:
1. remote execution
@ -61,7 +61,7 @@ Once pkgutil is installed you'll need to edit it's config file
- #mirror=http://mirror.opencsw.org/opencsw/testing
+ mirror=http://mirror.opencsw.org/opencsw/unstable
Ok, time to install salt.
OK, time to install salt.
.. code-block:: bash

6
doc/topics/reactor/index.rst
View File

@ -46,7 +46,7 @@ with lists of reactor sls formulas (globs can be used for matching):
When an event with a tag of auth is fired the reactor will catch the event and
render the two listed files. The rendered files are standard sls files, so by
default they are yaml + jinja. The jinja is packed with a few data structures
default they are yaml + Jinja. The Jinja is packed with a few data structures
similar to state and pillar sls files. The data available is found in the `tag`
and `data` variables. The `tag` variable is just the tag in the fired event
and the `data` variable is the event's data dict. Here is a simple reactor sls:
@ -59,11 +59,11 @@ and the `data` variable is the event's data dict. Here is a simple reactor sls:
- tgt: mysql1
{% endif %}
This simple reactor file uses jinja to further refine the reaction to be made.
This simple reactor file uses Jinja to further refine the reaction to be made.
If the `id` in the event data is mysql1 (if the name of the minion is mysql1) then
the following reaction is defined. The same data structure and compiler used
for the state system is used for the reactor system. The only difference is that the
data is matched up to the salt command api and the runner system. In this
data is matched up to the salt command API and the runner system. In this
example a command is published to the mysql1 minion with a function of
state.highstate. Similarly, a runner can be called:

4
doc/topics/releases/0.10.0.rst
View File

@ -18,7 +18,7 @@ Event System
The Salt Master now comes equipped with a new event system. This event system
has replaced some of the back end of the Salt client and offers the beginning of
a system which will make plugging external applications into Salt. The event
system relies on a local zeromq publish socket and other processes can connect
system relies on a local ZeroMQ publish socket and other processes can connect
to this socket and listen for events. The new events can be easily managed via
Salt's event library.
@ -43,7 +43,7 @@ YAML Parsing Updates
--------------------
In the past the YAML parser for sls files would return the incorrect numbers
when the file mode was set with a preceding 0. The yaml parser used in Salt
when the file mode was set with a preceding 0. The YAML parser used in Salt
has been modified to no longer convert these number into octal but to keep
them as the correct value so that sls files can be a little cleaner to write.

4
doc/topics/releases/0.10.2.rst
View File

@ -6,7 +6,7 @@ Salt 0.10.2 Release Notes
cleaner ways to access the salt-call capabilities in the API, minion data
caching and the event system has been added to salt minions.
There have also been updates to the zeromq functions, many more tests
There have also been updates to the ZeroMQ functions, many more tests
(thanks to sponsors, the code sprint and many contributors) and a swath
of bug fixes.
@ -99,7 +99,7 @@ OpenBSD.
SQL Modules
^^^^^^^^^^^
The MySQL and Postgres modules have both received a number of additions thanks
The MySQL and PostgreSQL modules have both received a number of additions thanks
to the work of Avi Marcus and Roman Imankulov.
ZFS Support on FreeBSD

2
doc/topics/releases/0.10.4.rst
View File

@ -47,7 +47,7 @@ Access Control System
All Salt systems can now be configured to grant access to non-administrative
users in a granular way. The old configuration continues to work. Specific
functions can be opened up to specific minions from specific users in the case
of external auth and client acls, and for specific minions in the case of the
of external auth and client ACLs, and for specific minions in the case of the
peer system.
Access controls are configured like this:

8
doc/topics/releases/0.10.5.rst
View File

@ -50,7 +50,7 @@ A new API was added to the Salt Master which allows the master to be managed
via an external API. This new system allows Salt API to easily hook into the
Salt Master and manage configs, modify the state tree, manage the pillar and
more. The main motivation for the wheel system is to enable features needed
in the upcoming web ui so users can manage the master just as easily as they
in the upcoming web UI so users can manage the master just as easily as they
manage minions.
The wheel system has also been hooked into the external auth system. This
@ -64,17 +64,17 @@ Jack Kuan has added a substantial new feature. The render pipes system allows
Salt to treat the render system like unix pipes. This new system enables sls
files to be passed through specific render engines. While the default renderer
is still recommended, different engines can now be more easily merged. So to
pipe the output of mako used in YAML use this shebang line:
pipe the output of Mako used in YAML use this shebang line:
#!mako|yaml
Salt Key Overhaul
-----------------
The Salt Key system was originally developed as only a cli interface, but as
The Salt Key system was originally developed as only a CLI interface, but as
time went on it was pressed into becoming a clumsy API. This release marks a
complete overhaul of Salt Key. Salt Key has been rewritten to function purely
from an api and to use the outputter system. The benefit here is that the
from an API and to use the outputter system. The benefit here is that the
outputter system works much more cleanly with Salt Key now, and the internals
of Salt Key can be used much more cleanly.

2
doc/topics/releases/0.11.0.rst
View File

@ -34,7 +34,7 @@ can respond to events within a salted environment. The reactor system uses sls
files to match events fired on the master with actions, enabling Salt
to react to problems in an infrastructure.
Your load-balanced group of webservers is under extra load? Spin up a new vm
Your load-balanced group of webservers is under extra load? Spin up a new VM
and add it to the group. Your fileserver is filling up? Send a notification to
your sysadmin on call. The possibilities are endless!

4
doc/topics/releases/0.12.0.rst
View File

@ -33,13 +33,13 @@ systems. Software on Windows can now be managed in the same way. The SaltStack
team built a package manager that interfaces with the standard Salt pkg module
to allow for installing and removing software on Windows. In addition, a
software package repository has been built on top of the Salt fileserver. A
small yaml file provides the information necessary for the package manager to
small YAML file provides the information necessary for the package manager to
install and remove software.
An interesting feature of the new Salt Windows software package repository is
that one or more remote git repositories can supplement the master's local
repository. The repository can point to software on the master's fileserver or
on an http, https, or ftp server.
on an HTTP, HTTPS, or ftp server.
New Default Outputter
---------------------

6
doc/topics/releases/0.13.0.rst
View File

@ -2,7 +2,7 @@
Salt 0.13.0 Release Notes
=========================
The lucky number 13 has turned the corner! From cli notifications when quitting
The lucky number 13 has turned the corner! From CLI notifications when quitting
a salt command, to substantial improvements on Windows, Salt 0.13.0 has
arrived!
@ -63,8 +63,8 @@ remote executions to also quit. Now a message is displayed showing what
command can be used to track the execution and what the job id is for the
execution.
Version Specification in Muliple-Package States
-----------------------------------------------
Version Specification in Multiple-Package States
------------------------------------------------
Versions can now be specified within multiple-package :mod:`pkg.installed
<salt.states.pkg.installed>` states. An example can be found below:

14
doc/topics/releases/0.6.0.rst
View File

@ -16,15 +16,15 @@ setup and use, the entire application is contained in a single package, and the
master and minion daemons require no running dependencies in the way that Func
requires Certmaster and MCollective requires activeMQ.
Salt also manages authentication and encryption. Rather than using ssl for
Salt also manages authentication and encryption. Rather than using SSL for
encryption, salt manages encryption on a payload level, so the data sent across
the network is encrypted with fast aes encryption, and authentication uses RSA
the network is encrypted with fast AES encryption, and authentication uses RSA
keys. This means that Salt is fast, secure, and very efficient.
Messaging in Salt is executed with zeromq, so the message passing interface is
built into salt and does not require an external MQ server. This also adds
Messaging in Salt is executed with ZeroMQ, so the message passing interface is
built into salt and does not require an external ZeroMQ server. This also adds
speed to Salt since there is no additional bloat on the networking layer, and
zeromq has already proven itself as a very fast networking system.
ZeroMQ has already proven itself as a very fast networking system.
The remote execution in Salt is "Lazy Execution", in that once the command is
sent the requesting network connection is closed. This makes it easier to
@ -36,10 +36,10 @@ Salt also allows users to make execution modules in Python. Writers of these
modules should also be pleased to know that they have access to the impressive
information gathered from PuppetLabs' Facter application, making Salt module
more flexible. In the future I hope to also allow Salt to group servers based
on facter information as well.
on Facter information as well.
All in all Salt is fast, efficient and clean, can be used from a simple command
line client or through an api, uses message queue technology to make network
line client or through an API, uses message queue technology to make network
execution extremely fast, and encryption is handled in a very fast and
efficient manner. Salt is also VERY easy to use and VERY easy to extend.

4
doc/topics/releases/0.7.0.rst
View File

@ -9,8 +9,8 @@ suitable for general use.
0.7.0 Brings the following new features to Salt:
- Integration with facter data from puppet labs
- Allow for matching minions from the salt client via facter information
- Integration with Facter data from puppet labs
- Allow for matching minions from the salt client via Facter information
- Minion job threading, many jobs can be executed from the master at once
- Preview of master clustering support - Still experimental
- Introduce new minion modules for stats, virtualization, service management and more

6
doc/topics/releases/0.8.0.rst
View File

@ -64,7 +64,7 @@ it to a specific module. The returner modules work like minion modules, so any
returner can be added to the minions.
This means that a custom data returner can be added to communicate the return
data so anything from MySQL, redis, mongodb and more!
data so anything from MySQL, Redis, MongoDB and more!
There are 2 simple stock returners in the returners directory:
@ -93,7 +93,7 @@ In 0.7.0 the minion would block after receiving a command from the master, now
the minion will spawn a thread or multiprocess. By default Python threads are
used because for general use they have proved to be faster, but the minion can
now be configured to use the Python multiprocessing module instead. Using
multiprocessing will cause executions that are cpu bound or would otherwise
multiprocessing will cause executions that are CPU bound or would otherwise
exploit the negative aspects of the Python GIL to run faster and more reliably,
but simple calls will still be faster with Python threading.
The configuration option can be found in the minion configuration file:
@ -104,7 +104,7 @@ Lowered Supported Python to 2.6 -
The requirement for Python 2.7 has been removed to support Python 2.6. I have
received requests to take the minimum Python version back to 2.4, but
unfortunately this will not be possible, since the zeromq Python bindings do
unfortunately this will not be possible, since the ZeroMQ Python bindings do
not support Python 2.4.
Salt 0.8.0 is a very major update, it also changes the network protocol slightly

4
doc/topics/releases/0.8.7.rst
View File

@ -4,7 +4,7 @@ Salt 0.8.7 release notes
It has been a month since salt 0.8.0, and it has been a long month! But Salt is
still coming along strong. 0.8.7 has a lot of changes and a lot of updates.
This update makes Salt’s ZeroMQ back end better, strips facter from the
This update makes Salt’s ZeroMQ back end better, strips Facter from the
dependencies, and introduces interfaces to handle more capabilities.
Many of the major updates are in the background, but the changes should shine
@ -24,7 +24,7 @@ The major new features and changes in Salt 0.8.7 are:
* Dynamic state enforcement managers
* Extract the module loader into salt.loader
* Make Job ids more granular
* Replace facter functionality with the new salt grains interface
* Replace Facter functionality with the new salt grains interface
* Support for “virtual” salt modules
* Introduce the salt-call command
* Better debugging for minion modules

14
doc/topics/releases/0.8.8.rst
View File

@ -27,7 +27,7 @@ Much of the salt code has been cleaned up and a new cleaner logging system has
been introduced thanks to the efforts of Pedro Algarvio. These additions will
allow for much more flexible logging to be executed by salt, and fixed a great
deal of my poor spelling in the salt docstrings! Pedro Algarvio has also
cleaned up the api, making it easier to embed salt into another application.
cleaned up the API, making it easier to embed salt into another application.
The biggest addition to salt found in 0.8.8 is the new state system. The salt
module system has received a new front end which allows salt to be used as a
@ -49,14 +49,14 @@ Hosts
The system used to define the salt states is based on a data structure, the
data structure used to define the salt states has been made to be as easy to
use as possible. The data structure is defined by default using a yaml file
rendered via a jinja template. This means that the state definition language
supports all of the data structures that yaml supports, and all of the
programming constructs and logic that jinja supports. If the user does not
like yaml or jinja the states can be defined in yaml-mako, json-jinja, or
use as possible. The data structure is defined by default using a YAML file
rendered via a Jinja template. This means that the state definition language
supports all of the data structures that YAML supports, and all of the
programming constructs and logic that Jinja supports. If the user does not
like YAML or Jinja the states can be defined in yaml-mako, json-jinja, or
json-mako. The system used to render the states is completely dynamic, and any
rendering system can be added to the capabilities of Salt, this means that a
rendering system that renders xml data in a cheetah template, or whatever you
rendering system that renders XML data in a cheetah template, or whatever you
can imagine, can be easily added to the capabilities of salt.
The salt state system also supports isolated environments, as well as matching

6
doc/topics/releases/0.8.9.rst
View File

@ -21,7 +21,7 @@ The Salt source can be downloaded from the salt github site:
:download:`salt-0.8.9.tar.gz`
Or from PiPy:
Or from PyPI:
http://pypi.python.org/packages/source/s/salt/salt-0.8.9.tar.gz
@ -51,7 +51,7 @@ Refined Outputters
One problem often complained about in salt was the fact that the output was
so messy. Thanks to help from Jeff Schroeder a cleaner interface for the
command output for the Salt cli has been made. This new interface makes
command output for the Salt CLI has been made. This new interface makes
adding new printout formats easy and additions to the capabilities of minion
modules makes it possible to set the printout mode or ``outputter`` for
functions in minion modules.
@ -151,7 +151,7 @@ New Returners
mongo_return
~~~~~~~~~~~~
Send the return information to a mongodb server.
Send the return information to a MongoDB server.
New Runners
```````````

6
doc/topics/releases/0.9.0.rst
View File

@ -6,7 +6,7 @@ Salt 0.9.0 is here. This is an exciting release, 0.9.0 includes the new network
topology features allowing peer salt commands and masters of masters via the
syndic interface.
0.9.0 also introduces many more modules, improvements to the api and
0.9.0 also introduces many more modules, improvements to the API and
improvements to the ZeroMQ systems.
Download!
@ -16,7 +16,7 @@ The Salt source can be downloaded from the salt github site:
:download:`salt-0.9.0.tar.gz`
Or from PiPy:
Or from PyPI:
http://pypi.python.org/packages/source/s/salt/salt-0.9.0.tar.gz
@ -87,7 +87,7 @@ Improved 0MQ Master Workers
The 0MQ worker system has been further refined to be faster and more robust.
This new system has been able to handle a much larger load than the previous
setup. The new system uses the ipc protocol in 0MQ instead of tcp.
setup. The new system uses the IPC protocol in 0MQ instead of TCP.
New Modules
-----------

2
doc/topics/releases/0.9.2.rst
View File

@ -19,7 +19,7 @@ The Salt source can be downloaded from the salt github site:
:download:`salt-0.9.2.tar.gz`
Or from PiPy:
Or from PyPI:
http://pypi.python.org/packages/source/s/salt/salt-0.9.2.tar.gz

8
doc/topics/releases/0.9.3.rst
View File

@ -18,7 +18,7 @@ The Salt source can be downloaded from the salt github site:
:download:`salt-0.9.3.tar.gz`
Or from PiPy:
Or from PyPI:
http://pypi.python.org/packages/source/s/salt/salt-0.9.3.tar.gz
@ -104,8 +104,8 @@ displays this new capability.
Python State Renderer
`````````````````````
Until now Salt States could only be declared in yaml or json using jinja or
mako. A new, very powerful, renderer has been added, making it possible to
Until now Salt States could only be declared in yaml or json using Jinja or
Mako. A new, very powerful, renderer has been added, making it possible to
write Salt States in pure Python:
.. code-block:: python
@ -207,7 +207,7 @@ file.recurse
- source: salt://linux
file.absent
Make sure that the file is not on the system, recursively delets
Make sure that the file is not on the system, recursively deletes
directories, files and symlinks.
.. code-block:: yaml

2
doc/topics/releases/0.9.4.rst
View File

@ -20,7 +20,7 @@ The Salt source can be downloaded from the salt github site:
:download:`salt-0.9.4.tar.gz`
Or from PiPy:
Or from PyPI:
http://pypi.python.org/packages/source/s/salt/salt-0.9.4.tar.gz

10
doc/topics/releases/0.9.5.rst
View File

@ -22,7 +22,7 @@ This has proven not only that Salt has great value, but also the
expandability of Salt is as exponential as I originally intended.
0.9.5 has received over 600 additional commits since 0.9.4 with a swath of new
commiters. The following individuals have contributed to the development of
committers. The following individuals have contributed to the development of
0.9.5:
* Aaron Bull Schaefer
@ -276,7 +276,7 @@ More to Come
------------
We are actively seeking inclusion in more distributions. Primarily getting
Salt into Gentoo, Suse, OpenBSD and preparing Solaris support are all turning
Salt into Gentoo, SUSE, OpenBSD and preparing Solaris support are all turning
into higher priorities.
Refinement
@ -366,13 +366,13 @@ Salt can now manage local users on Microsoft Windows Systems
:mod:`yumpkg5 <salt.modules.yumpkg5>`
`````````````````````````````````````
The yumpkg module introduces in 0.9.4 uses the yum api to interact with the
The yumpkg module introduces in 0.9.4 uses the yum API to interact with the
yum package manager. Unfortunately, on Red Hat 5 systems salt does not have
access to the yum api because the yum api is running under Python 2.4 and Salt
access to the yum API because the yum API is running under Python 2.4 and Salt
needs to run under Python 2.6.
The yumpkg5 module bypasses this issue by shelling out to yum on systems where
the yum api is not available.
the yum API is not available.
New States
-----------

4
doc/topics/releases/0.9.6.rst
View File

@ -12,10 +12,10 @@ with Salt, and is required as a dependency.
New Features
============
http and ftp support in files.managed
HTTP and ftp support in files.managed
-------------------------------------
Now under the source option in the file.managed state a http or ftp address
Now under the source option in the file.managed state a HTTP or ftp address
can be used instead of a file located on the salt master.
Allow Multiple Returners

10
doc/topics/releases/0.9.8.rst
View File

@ -7,8 +7,8 @@ well as a number of precursors to advanced future developments.
This version of Salt adds much more power to the command line, making the
old hard timeout issues a thing of the past and adds keyword argument
support. These additions are also available in the salt client api, making
the available api tools much more powerful.
support. These additions are also available in the salt client API, making
the available API tools much more powerful.
The new pillar system allows for data to be stored on the master and
assigned to minions in a granular way similar to the state system. It also
@ -32,7 +32,7 @@ default behavior of grain matching has changed slightly to reflect the rest
of salt and the compound matcher system has been refined.
A number of impressive features with keyword arguments have been added to both
the cli and to the state system. This makes states much more powerful and
the CLI and to the state system. This makes states much more powerful and
flexible while maintaining the simple configuration everyone loves.
The new batch size capability allows for executions to be rolled through a
@ -123,7 +123,7 @@ has just become portable, allowing minions to have a local copy of states
or to manage states without a master entirely.
This is accomplished via the new file client interface in Salt that allows
for the ``salt://`` uri to be redirected to custom interfaces. This means that
for the ``salt://`` URI to be redirected to custom interfaces. This means that
there are now two interfaces for the salt file server, calling the master
or looking in a local, minion defined ``file_roots``.
@ -342,7 +342,7 @@ issues when package installation waits for confirmation.
A :doc:`pkg </ref/modules/all/salt.modules.zypper>` module for OpenSUSE's
zypper was added.
The :doc:`service </ref/modules/all/salt.modules.upstart>` module on ubuntu
The :doc:`service </ref/modules/all/salt.modules.upstart>` module on Ubuntu
natively supports upstart.
A new :doc:`debconf </ref/modules/all/salt.modules.debconfmod>` module was

2
doc/topics/releases/0.9.9.rst
View File

@ -280,5 +280,5 @@ runners and commands like salt-key.
Client Tests
------------
Tests have been added to test the aspects of the client apis and ensure that
Tests have been added to test the aspects of the client APIs and ensure that
the client calls work, and that they manage passed data, in a desirable way.

2
doc/topics/targeting/nodegroups.rst
View File

@ -8,7 +8,7 @@ Node groups
A predefined group of minions declared in the master configuration file
:conf_master:`nodegroups` setting as a compound target.
Nodegroups are declared using a compound target specification. The compount
Nodegroups are declared using a compound target specification. The compound
target documentation can be found here:
:doc:`Compound Matchers <compound>`

2
doc/topics/troubleshooting/index.rst
View File

@ -31,7 +31,7 @@ What Ports do the Master and Minion Need Open?
No ports need to be opened up on each minion. For the master, TCP ports 4505
and 4506 need to be open. If you've put both your Salt master and minion in
debug mode and don't see an acknowledgement that your minion has connected,
debug mode and don't see an acknowledgment that your minion has connected,
it could very well be a firewall.
You can check port connectivity from the minion with the nc command:

2
doc/topics/troubleshooting/yaml_idiosyncrasies.rst
View File

@ -229,7 +229,7 @@ Examples:
List of useable `Unicode characters`_ will help you to identify correct numbers.
List of usable `Unicode characters`_ will help you to identify correct numbers.
.. _`Unicode characters`: http://en.wikipedia.org/wiki/List_of_Unicode_characters

2
doc/topics/tutorials/gitfs.rst
View File

@ -23,7 +23,7 @@ tree to multiple masters seamless and automated.
Salt's file server also has a concept of environments, when using the gitfs
backend, Salt translates git branches and tags into environments, making
environment management very simple. Just merging a qa or staging branch up
environment management very simple. Just merging a QA or staging branch up
to a production branch can be all that is required to make those file changes
available to Salt.

6
doc/topics/tutorials/pillar.rst
View File

@ -4,7 +4,7 @@ Pillar Walkthrough
.. note::
This walkthrough assumes that the reader has already completed the inital
This walkthrough assumes that the reader has already completed the initial
Salt Stack walkthrough:
:doc:`Walkthrough </topics/tutorials/walkthrough>`
@ -15,7 +15,7 @@ for specific minions. The data generated in pillar is made available to almost
every component of Salt and is used for a number of purposes:
Highly Sensitive Data:
Information transfered via pillar is guaranteed to only be presented to the
Information transferred via pillar is guaranteed to only be presented to the
minions that are targeted, this makes pillar the engine to use in Salt for
managing security information, such as cryptographic keys and passwords.
Minion Configuration:
@ -92,7 +92,7 @@ More Complex Data
Pillar files are sls files, just like states, but unlike states they do not
need to define `formulas`, the data can be arbitrary, this example for
instance sets up user data with a uid:
instance sets up user data with a UID:
`/srv/pillar/users/init.sls`

4
doc/topics/tutorials/starting_states.rst
View File

@ -13,7 +13,7 @@ to contain this data simply. This is often called configuration management.
.. note::
This is just the begining of using states, make sure to read up on pillar
This is just the beginning of using states, make sure to read up on pillar
next:
:doc:`Pillar Walkthrough </topics/tutorials/pillar>`
@ -312,7 +312,7 @@ renderers.
The ``py`` renderer allows for SLS files to be written in pure Python, allowing
for the utmost level of flexibility and power when preparing SLS data; while the
:doc:`pydsl</ref/renderers/all/salt.renderers.pydsl>` renderer provides a flexible,
domain-specific languange for authoring SLS data in Python.
domain-specific language for authoring SLS data in Python.
.. _`Jinja2`: http://jinja.pocoo.org/
.. _`Mako`: http://www.makotemplates.org/

4
doc/topics/tutorials/states_pt1.rst
View File

@ -14,7 +14,7 @@ Apache HTTP server and to ensure the server is running.
Setting up the Salt State Tree
==============================
States are stored in text files on the master and transfered to the minions on
States are stored in text files on the master and transferred to the minions on
demand via the master's File Server. The collection of state files make up the
:term:`State Tree`.
@ -60,7 +60,7 @@ minion matches is defined; for now simply specify all hosts (``*``).
.. admonition:: Targeting minions
The expressions can use any of the targeting mechanisms used by Salt —
minions can be matched by glob, pcre regular expression, or by :doc:`grains
minions can be matched by glob, PCRE regular expression, or by :doc:`grains
</topics/targeting/grains>`. For example::
base:

24
doc/topics/tutorials/walkthrough.rst
View File

@ -96,7 +96,7 @@ greatly increases the command output:
# salt-master -l debug
The Salt Master needs to bind to 2 tcp network ports on the system, these ports
The Salt Master needs to bind to 2 TCP network ports on the system, these ports
are 4505 and 4506. For more in depth information on fire walling these ports
the firewall tutorial is available:
@ -109,7 +109,7 @@ Setting up a Salt Minion
The Salt Minion can operate with or without a Salt Master. This walkthrough
assumes that the minion will be connected to the master, for information on
how to run a masterless minion please see the masterless quickstart guide:
how to run a master-less minion please see the masterless quickstart guide:
:doc:`Masterless Minon Quickstart </topics/tutorials/quickstart>`
@ -235,7 +235,7 @@ Grains
~~~~~~
Salt uses a system called `Grains` to build up static data about minions. This
data includes information about the operating system that is running, cpu
data includes information about the operating system that is running, CPU
architecture and many more. The grains system is used throughout Salt to
deliver platform data to many components and to users.
@ -258,7 +258,7 @@ Many other targeting systems can be used other than globs, these systems
include:
Regular Expressions
Target using pcre compliant regular expressions:
Target using PCRE compliant regular expressions:
:doc:`Targeting with Regular Expressions</topics/targeting/pcre>`
Grains
@ -270,12 +270,12 @@ Pillar
:doc:`Targeting with Pillar</topics/targeting/pillar>`
IP
Target based on ip addr/subnet/range:
Target based on IP addr/subnet/range:
:doc:`Targeting with ipcidr</topics/targeting/ipcidr>`
Compound
Create logic to target based on multiple targets:
:doc:`Targeting with Compond</topics/targeting/compound>`
:doc:`Targeting with Compound</topics/targeting/compound>`
Nodegroup
Target with nodegroups:
@ -283,7 +283,7 @@ Nodegroup
The concepts of targets are used on the command line with salt, but also
function in many other areas as well, including the state system and the
systems used for acls and user permission restrictions.
systems used for ACLs and user permission restrictions.
Salt States
===========
@ -368,7 +368,7 @@ Adding Some Depth
-----------------
Obviously maintaining sls formulas right in the root of the file server will
not scale out to resonably sized deployments. This is why more depth is
not scale out to reasonably sized deployments. This is why more depth is
required. Start by making an nginx formula a better way, make a nginx
subdirectory and add an init.sls file:
@ -388,7 +388,7 @@ A few things are introduced in this sls formula, first is the service statement
which ensures that the nginx service is running, but the nginx service can't be
started unless the package is installed, hence the `require`. The `require`
statement makes sure that the required component is executed before and that
it results in sucess.
it results in success.
.. note::
@ -432,7 +432,7 @@ joe or any other editor that may need to be deployed.
Next Reading
------------
Two walkthroughs are specificly reommended at this point, first a deeper run
Two walkthroughs are specifically recommended at this point, first a deeper run
through states:
:doc:`Starting States </topics/tutorials/starting_states>`
@ -464,7 +464,7 @@ This concludes the initial Salt walkthrough, but there are many more things to
yet learn! These documents will cover important core aspects of Salt:
Pillar
Paramaters and minion private data (pillar is a core component of states):
Parameters and minion private data (pillar is a core component of states):
:doc:`States Tutorial</topics/tutorials/states_pt1>`
:doc:`Pillar</topics/pillar/index>`
@ -474,7 +474,7 @@ Job Management
A few more tutorials are also available:
Remote Excution Tutorial
Remote Execution Tutorial
:doc:`Remote Execution Tutorial</topics/tutorials/modules>`
Standalone Minion