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

Merge pull request #36647 from MTecknology/develop

Browse Source 
Documentation Updates: reactor/orchestrator/git_fileserver
This commit is contained in:
Mike Place 2016-09-30 19:22:33 +09:00 committed by GitHub
commit 76562d2c4e
3 changed files with 32 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
doc/man/salt.7
View File

@ -61703,17 +61703,18 @@ fileserver_backend:
.UNINDENT
.UNINDENT
.sp
As of Salt 2014.7.0, the Git fileserver backend supports \fI\%GitPython\fP, \fI\%pygit2\fP,
and \fI\%dulwich\fP to provide the Python interface to git. If more than one of these
are present, the order of preference for which one will be chosen is the same
as the order in which they were listed: pygit2, GitPython, dulwich (keep in
mind, this order is subject to change).
The Git backend to the fileserver can use a number of different Git providers. As
of 2014.7.0, this includes \fI\%pygit2\fP, \fI\%GitPython\fP, and \fI\%dulwich\fP.
.sp
An optional master config parameter (\fBgitfs_provider\fP) can be used
to specify which provider should be used.
An optional master config parameter (\fBgitfs_provider\fP) can, and should, be used
to specify which provider will be used. If not specified, Salt will attempt to load
the first available module it's able to find.
.sp
More detailed information on how to use gitfs can be found in the Gitfs
Walkthrough\&.
At the time this writing, the current search order is pygit, GitPython, and finally
dulwich. If no provider modules can be loaded, the Git backend will not be available
for use by the fileserver.
.sp
More detailed information on how to use gitfs can be found in the Gitfs Walkthrough\&.
.sp
\fBNOTE:\fP
.INDENT 0.0

30
doc/topics/orchestrate/orchestrate_runner.rst
View File

@ -24,12 +24,10 @@ The Orchestrate Runner
used.
* The states/functions will also work on salt-ssh minions.
The Orchestrate Runner was added with the intent to eventually deprecate the
OverState system, however the OverState will still be maintained until Salt
2015.8.0.
The Orchestrate Runner replaced the OverState system in Salt 2015.8.0.
The orchestrate runner generalizes the Salt state system to a Salt master
context. Whereas the ``state.sls``, ``state.highstate``, et al functions are
context. Whereas the ``state.sls``, ``state.highstate``, et al. functions are
concurrently and independently executed on each Salt minion, the
``state.orchestrate`` runner is executed on the master, giving it a
master-level view and control over requisites, such as state ordering and
@ -38,22 +36,34 @@ application of states on different minions that must not happen simultaneously,
or for halting the state run on all minions if a minion fails one of its
states.
If you want to setup a load balancer in front of a cluster of web servers, for
example, you can ensure the load balancer is setup before the web servers or
stop the state run altogether if one of the minions does not set up correctly.
If you want to set up a load balancer in front of a cluster of web servers, for
example, you can ensure the load balancer is set up before the web servers or
stop the state run altogether if a minion fails to apply any states.
The ``state.sls``, ``state.highstate``, et al functions allow you to statefully
The ``state.sls``, ``state.highstate``, et al. functions allow you to statefully
manage each minion and the ``state.orchestrate`` runner allows you to
statefully manage your entire infrastructure.
Writing SLS Files
~~~~~~~~~~~~~~~~~
Orchestrate SLS files are stored in the same location as State SLS files. This
means that both ``file_roots`` and ``gitfs_remotes`` impact what SLS files are
available to the reactor and orchestrator.
It is recommended to keep reactor and orchestrator SLS files in their own
uniquely named subdirectories such as ``_orch/``, ``orch/``, ``_orchestrate/``,
``react/``, ``_reactor/``, etc. This will avoid duplicate naming and will help
prevent confusion.
Executing the Orchestrate Runner
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Orchestrate Runner command format is the same as for the ``state.sls``
function, except that since it is a runner, it is executed with ``salt-run``
rather than ``salt``. Assuming you have a state.sls file called
``/srv/salt/orch/webserver.sls`` the following command run on the master will
apply the states defined in that file.
``/srv/salt/orch/webserver.sls`` the following command, run on the master,
will apply the states defined in that file.
.. code-block:: bash

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

@ -105,8 +105,8 @@ of the runit orchestrator located at ``/srv/salt/_orch/runit.sls``. Using
``_orch/`` is any arbitrary path but it is recommended to avoid using "orchestrate"
as this is most likely to cause confusion.
Reactor and Orchestrator SLS File Locations
-------------------------------------------
Writing SLS Files
-----------------
Reactor SLS files are stored in the same location as State SLS files. This means
that both ``file_roots`` and ``gitfs_remotes`` impact what SLS files are