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

Fix multi-master event handling bug

Browse Source 
We had a situation wherein minion generators would race to the sub
socket and only a single minion would actually act on the package. The
result was that events such as refresh_pillar would cause one (or
sometimes both) minions to stop responding. This changes the behaviour
so that the first instance to get the request calls action on all
instances.

While this has the possible side-effect of blocking for O(n) inside the event
handling loop, it also ensures that multi-master minions update in a
linear fashion.
This commit is contained in:
Mike Place 2015-01-16 10:33:53 -07:00
parent afb7faaaf1
commit ad02d09821
1 changed files with 9 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
salt/minion.py
View File

@ -557,24 +557,16 @@ class MultiMinion(MinionBase):
# run scheduled jobs if you have them
loop_interval = self.process_schedule(minion['minion'], loop_interval)
# if you have an event to handle, do it on a single minion
# (first one to not throw an exception)
# If a minion instance receives event, handle the event on all
# instances
if package:
# If we need to expand this, we may want to consider a specific header
# or another approach entirely.
if package.startswith('_minion_mine'):
for multi_minion in minions:
try:
minions[master]['minion'].handle_event(package)
except Exception:
pass
else:
try:
minion['minion'].handle_event(package)
package = None
self.epub_sock.send(package)
except Exception:
pass
try:
for master in masters:
minions[master].handle_event(package)
except Exception:
pass
finally:
package = None # Ensure we don't loop
# have the Minion class run anything it has to run
next(minion['generator'])