2018.3 - Master address: '127.0.0.1' could not be resolved

[ghost]

Description of Issue/Question

Testing the latest 2018.3 branch since we needed a few mysql module fixes in it that didn't make it to a stable release, and we are now seeing an error when setting up a minion to connect to a local master using 127.0.0.1 as address.

2019-01-21 17:00:20,178 [salt.cli.daemons :357 ][ERROR ][30809] Master address: '127.0.0.1' could not be resolved. Invalid or unresolveable address. Set 'master' value in minion config.

Using localhost instead, works as expected.

Setup

Minion configuration is:

id: test.domain
metadata_server_grains: True
use_superseded: [ 'module.run' ]
log_level: "info"
master: "127.0.0.1"

This config is done by salt-cloud as part of our automated environment, so we really cannot set anything other than 127.0.0.1 for the first bootstrap.

Steps to Reproduce Issue

Use latest 2018.3 branch and setup minion to connect to a local master using 127.0.0.1 as address.

Versions Report

           Salt: 2018.3.0

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.6.1
      docker-py: Not Installed
          gitdb: 2.0.3
      gitpython: 2.1.8
          ioflo: Not Installed
         Jinja2: 2.10
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: 1.2.5
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.10 (default, Dec 19 2015, 08:44:39)
   python-gnupg: Not Installed
         PyYAML: 4.1
          PyZMQ: 17.1.2
           RAET: Not Installed
          smmap: 2.0.3
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.1.4

System Versions:
           dist: centos 7.6.1810 Core
         locale: UTF-8
        machine: x86_64
        release: 3.10.0-957.1.3.el7.x86_64
         system: Linux
        version: CentOS Linux 7.6.1810 Core```

[Ch3LL]

looks like i'm able to replicate this on the head of 2018.3

I was not able to bisect this cleanly but it might be related to this PR: #49755

thanks for the heads up we will need to get this fixed.

[Ch3LL]

i tested 2019.2.0.rc1 branch and it is not affected.

[max-arnold]

Have the same problem in 2019.2.0.rc1:

root@minion1:~# salt-minion --version
salt-minion 2019.2.0-n/a-b348034 (Fluorine)

root@minion1:~# salt-minion
[INFO    ] Setting up the Salt Minion "minion1"
[INFO    ] Starting up the Salt Minion
[INFO    ] Starting pull socket on /var/run/salt/minion/minion_event_1e9498c860_pull.ipc
[INFO    ] Creating minion process manager
[ERROR   ] Master address: '192.168.10.10' could not be resolved. Invalid or unresolveable address. Set 'master' value in minion config.
[INFO    ] Stopping the Salt Minion
[ERROR   ] Master address: '192.168.10.10' could not be resolved. Invalid or unresolveable address. Set 'master' value in minion config.
[INFO    ] Shutting down the Salt Minion
The Salt Minion is shutdown.
Master address: '192.168.10.10' could not be resolved. Invalid or unresolveable address. Set 'master' value in minion config.


root@minion1:~# ping 192.168.10.10
PING 192.168.10.10 (192.168.10.10) 56(84) bytes of data.
64 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=0.508 ms
64 bytes from 192.168.10.10: icmp_seq=2 ttl=64 time=0.643 ms
^C
--- 192.168.10.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.508/0.575/0.643/0.071 ms

[Ch3LL]

that commit in your version is on the 2019.2 branch. We will be releasing from the 2019.2.0.rc1 branch which is not affected. This fixes the issue: #51274 which will be merged forward into 2019.2

[arizvisa]

Hey y'all. As a workaround, I found by explicitly disabling IPv6 it forces things to get handled correctly. Unfortunately though, you lose IPv6...but what the hey...

[Ch3LL]

thanks for that workaround @arizvisa i'm sure it might help someone. closing this issue as there is a merged fix. thanks

[takeda]

This is still an issue in 3001.1.