mysql states fail because conv is `` instead of None

[jodok]

Description of Issue

when running an operation with the mysql state it fails as the conv object is not defined properly. I'm unsure whether PyMySQL handles it incorrectly, but I suspect it's rather salt as it should get the default value of None.

    Function: mysql_database.present
      Result: False
     Comment: An exception occurred in this state: Traceback (most recent call last):
                File "/usr/lib/python3.6/site-packages/salt/state.py", line 1981, in call
                  **cdata['kwargs'])
                File "/usr/lib/python3.6/site-packages/salt/loader.py", line 1977, in wrapper
                  return f(*args, **kwargs)
                File "/usr/lib/python3.6/site-packages/salt/states/mysql_database.py", line 55, in present
                  existing = __salt__['mysql.db_get'](name, **connection_args)
                File "/usr/lib/python3.6/site-packages/salt/modules/mysql.py", line 1035, in db_get
                  dbc = _connect(**connection_args)
                File "/usr/lib/python3.6/site-packages/salt/modules/mysql.py", line 393, in _connect
                  dbc = MySQLdb.connect(**connargs)
                File "/usr/lib/python3.6/site-packages/pymysql/__init__.py", line 90, in Connect
                  return Connection(*args, **kwargs)
                File "/usr/lib/python3.6/site-packages/pymysql/connections.py", line 689, in __init__
                  self.encoders = dict([(k, v) for (k, v) in conv.items() if type(k) is not int])
              AttributeError: 'str' object has no attribute 'items'

Steps to Reproduce Issue

the mysql connector tries to get the config option for conv https://github.com/saltstack/salt/blob/master/salt/modules/mysql.py#L373:

    _connarg('connection_conv', 'conv', get_opts)

this tries to read it from the config https://github.com/saltstack/salt/blob/master/salt/modules/mysql.py#L357:

            val = __salt__['config.option']('mysql.{0}'.format(name), None)

The default value should be None, but the method returns and empty string `` and therefor not None is returned.

the config option is then passed to PyMySQL which checks if conv is None (but not empty string: https://github.com/PyMySQL/PyMySQL/blob/master/pymysql/connections.py#L302

Therefor it fails shortly after: https://github.com/PyMySQL/PyMySQL/blob/master/pymysql/connections.py#L306

Versions Report

PyMySQL: python3-PyMySQL.noarch 0.8.0-10.module_el8.1.0+245+c39af44f
(CentOS 8)

Salt Version:
           Salt: 3000

Dependency Versions:
           cffi: 1.11.5
       cherrypy: Not Installed
       dateutil: 2.6.1
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
         Jinja2: 2.10.1
        libgit2: Not Installed
       M2Crypto: 0.35.2
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.6.2
   mysql-python: Not Installed
      pycparser: 2.14
       pycrypto: Not Installed
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 3.6.8 (default, Nov 21 2019, 19:31:34)
   python-gnupg: Not Installed
         PyYAML: 3.12
          PyZMQ: 17.0.0
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.3.2

System Versions:
           dist: centos 8.1.1911 Core
         locale: UTF-8
        machine: x86_64
        release: 4.18.0-147.5.1.el8_1.x86_64
         system: Linux
        version: CentOS Linux 8.1.1911 Core

[jodok]

not sure where this has to be fixed. Either in PyMySQL or here?

[mattherrmann]

+1 for this issue. I was able to work around it by adding the following line to my minion config to force SaltStack to set mysql.conv to None:
mysql.conv:

[ymasson]

#56124

[ymasson]

PR: #56174

[sagetherage]

Thankyou @jodok for reporting this. It is similar to some work @garethgreenaway is assigned in the above issue #56124 he has self-assigned, here as well, and will update the labels, today. I also moved this to approved milestone, Gareth, let me know if I can help in any other way. Thx!

[kveroneau]

I think my error is related #56266 , but my issue is about something else. I also don't think I'll be upgrading any of my salt machines until this is resolved, as provisioning MySQL is something I use salt for, so staying on 2019.2.3 is a requirement until this is resolved. Any ETA on when we can expect 3000.1 to be generally available?

[sagetherage]

@kveroneau apologies for not following up to your question - we are working towards the date around 3/20 but have had trouble with failing tests. I will have more information tomorrow and will update here and in the appropriate slack and group channels.

[Ch3LL]

closing here since fixed by #56174

[sagetherage]

@kveroneau we are still working towards next week to release 3000.1 - more details will be posted in slack, IRC, and user groups. I apologize I don't have an exact date, but next week is better than soon.