Master failover in minion configuration not working as expected #57660
Labels
Bug
broken, incorrect, or confusing behavior
Magnesium
Mg release after Na prior to Al
severity-medium
3rd level, incorrect or bad functionality, confusing and lacks a work around
ZD
The issue is related to a Zendesk customer support ticket.
Projects
Milestone
Description
If a name for configured Salt master cannot be resolved in DNS it silently falls back to 127.0.0.1. It might be Ok for some cases but definitely isn’t Ok of our case when we use ‘master_type=failover’.
With this (see below) configuration we would expect that if minion cannot resolve
master1
it would trymaster2
and thenmaster3
, instead it resolvesmaster1
to127.0.0.1
and tries to connect there. After some timeout it proceeds to the next one and follows the same procedure, tries to resolve, if this DNS resolution fails tries 127.0.0.1 and so on. That creates following issues for use:The problem resides in resolve_dns function in minion.py module. It has a second parameter “fallback=True” that controls fallback to 127.0.0.0 for address that cannot be resolved. Then when minion code loops though the list of given masters it calls that function without second parameter and builds master_uri as tcp://127.0.0.1:4506 for master that cannot be resolved.
Instead it should skip such master all together and raise an exception if no master can be reached. Or that “fallback” feature has to be configurable through minion configuration file.
Setup
Add the following configuration to your minion configuration:
Expected behavior
Masters should be attempted in order specified in minion configuration.
Versions Report
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)The text was updated successfully, but these errors were encountered: