mirror of
https://github.com/valitydev/salt.git
synced 2024-11-08 09:23:56 +00:00
Merge pull request #12991 from MTecknology/develop
Added more information about how salt-syndic works.
This commit is contained in:
commit
16596d7d2f
@ -62,3 +62,24 @@ starting the other Salt daemons.
|
||||
to return their events. If you think this is the case, you can set the
|
||||
:conf_master:`syndic_wait` value in the upper master config. The default
|
||||
value is ``1``, and should work for the majority of deployments.
|
||||
|
||||
Topology and Caveats
|
||||
====================
|
||||
|
||||
It's important to understand that ``salt-syndic`` is nothing more than an event
|
||||
forwarder. It attaches to ``salt-master`` on your Master of Masters and listens
|
||||
for events. The ``salt-syndic`` process will take the event from the Master of
|
||||
Masters and bring them to the master process running on the syndic.
|
||||
|
||||
Most situations will call for a Master of Masters running ``salt-master`` and
|
||||
optionally ``salt-minion``. The ``salt-syndic`` process should not be running on
|
||||
the salt-minion. The Salt syndic will be running ``salt-master``,
|
||||
``salt-syndic``, and optionally ``salt-minion``.
|
||||
|
||||
If one minion is connected to multiple syndics and a a command is issued from
|
||||
the Master of Masters targeted for that minion, each syndic will react to the
|
||||
event. Each syndic will create a job to send to the minion connected to it which
|
||||
will cause the minion to receive one job for each syndic it's connected to. In
|
||||
some cases, the syndics will create the same job ID and it will be treated as
|
||||
one job. In other cases the syndics will create diffrent job IDs and the minion
|
||||
will get multiple jobs to respond to.
|
||||
|
Loading…
Reference in New Issue
Block a user