Merge pull request #12991 from MTecknology/develop

Added more information about how salt-syndic works.
This commit is contained in:
Joseph Hall 2014-05-23 08:31:51 -06:00
commit 16596d7d2f

View File

@ -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.