Open amalaguti opened 2 months ago
@amalaguti Can you provide the version you are running please?
@dwoz Salt Minion is on Windows, 3006.8. Master is 3007.1
Additional info, as said, beacon won't load if the first master is not available, even the minion is connect to the 2nd master on start. A few seconds after the first master is started up, and the minion is able to establish connection, the beacon is triggered in the given interval. So definetely it's waiting for the first master to be enabled
Here a trivial beacon module, does nothing else than running test.version, it does not send events.
import logging
import salt.utils.beacons
__virtualname__ = "saltversion"
log = logging.getLogger(__name__)
def validate(config):
"""
Beacon config validation
"""
config = salt.utils.beacons.list_to_dict(config)
if not isinstance(config, dict):
msg = "config is not valid, must be a dict"
log.error("Beacon error: %s" % msg)
return False, msg
return True, "valid config"
def beacon(config):
"""
Execute test.version
"""
events = []
ret = __salt__["test.version"]()
log.info(">>>> Salt version: %s" % ret)
return events
Description I created a custom beacon module and noticed that in my Windows and Linux minions, which are set using multimaster list, if the first master in the list is not reachable/available when the minion starts, the beacon module does not load, despite the second master being available and the minion responding to this master.
Setup Set minion in multimaster (active/active), create and deploy a custom beacon module, sync/provision the module to the Windows minion, stop the minion, stop the master service on the first master, start the minion service, check the minion log, despite the minion connected to the second master, the beacon module is not loaded.
This can be workaround by using the minion config option
beacons_before_connect: True
. But maybe not ideal in all cases.I think the beacon module should load if any of the masters is reachable.