2019.2.1 breaks IPv6

[chr4]

Description of Issue

After the upgrade to 2019.2.1 we noticed that salt-minions can't connect to the master anymore. The problem occurs when master: <server> is set to a hostname that resolves to IPv6. When using an ipv4 address instead, or when setting ipv6: False, connection succeeds.

The same configuration worked fine with 2019.2.0.

The only additional option in the minion configuration was hash_type: sha512.

A network connectivity issue could be ruled out, as nc was able to properly connect to the master via ipv6.

Setup

minion configuration:

master: salt-master # With AAAA record set
hash_type: sha512

Steps to Reproduce Issue

Use the above minion configuration via ipv6 with 2019.2.1

Debug output of salt-call test.ping -l debug:

[DEBUG   ] Connecting to master. Attempt 1 of 1
[DEBUG   ] "salt-master" Not an IP address? Assuming it is a hostname.
[DEBUG   ] Master URI: tcp://::1:4506
[DEBUG   ] Popen(['git', 'version'], cwd=/etc/salt, universal_newlines=False, shell=None)
[DEBUG   ] Popen(['git', 'version'], cwd=/etc/salt, universal_newlines=False, shell=None)
[DEBUG   ] Initializing new AsyncAuth for ('/etc/salt/pki/minion', 'salt-master', 'tcp://::1:4506')
[DEBUG   ] Generated random reconnect delay between '1000ms' and '11000ms' (9933)
[DEBUG   ] Setting zmq_reconnect_ivl to '9933ms'
[DEBUG   ] Setting zmq_reconnect_ivl_max to '11000ms'
[DEBUG   ] Initializing new AsyncZeroMQReqChannel for ('/etc/salt/pki/minion', 'salt-master', 'tcp://::1:4506', 'clear')
[DEBUG   ] Connecting the Minion to the Master URI (for the return server): tcp://::1:4506
[DEBUG   ] Trying to connect to: tcp://::1:4506
[DEBUG   ] salt.crypt.get_rsa_pub_key: Loading public key
[DEBUG   ] SaltReqTimeoutError, retrying. (1/7)

Versions Report

Salt Version:
           Salt: 2019.2.1

Dependency Versions:
           cffi: 1.12.3
       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: 0.27.3
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: 2.17
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: 0.27.3
         Python: 3.6.8 (default, Aug 20 2019, 17:12:48)
   python-gnupg: 0.4.1
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: 2.0.3
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.2.5

System Versions:
           dist: Ubuntu 18.04 bionic
         locale: UTF-8
        machine: x86_64
        release: 4.15.0-65-generic
         system: Linux
        version: Ubuntu 18.04 bionic

[chr4]

It's also a little unfortunate that the apt repository didn't preserve 2019.2.0 apparently, which makes it very hard to downgrade back to 2019.2.0 :( What's the official procedure here?

[skorpy2009]

Hey this is a duplicate of #54762

As a repo you could use http://repo.saltstack.com/py3/ubuntu/18.04/amd64/archive/2019.2.0/

[chr4]

Thanks for the link to the repo! Yes, seems like exacty the same problem. Will close in favor of #54762

[chrisnew]

I’m stuck on 2019.2.1 on Debian 10 here. My sloppy workaround is for now to use deb https://repo.saltstack.com/apt/debian/9/amd64/archive/2019.2.0/ stretch main as source and downgrade to the Python 2 repo.