-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MySQL state and module broken after upgrade to 3000 #56124
Comments
I can confirm this also happens on CentOS 7. I can't get any mysql modules or states to execute successfully. sls
output:
|
I don't know why, but if i print salt-minion 2019.2.3
salt-minion 3000
When it is past to MySQLdb, |
Here is a small patch that I believe will get past the above error:
|
Not quite... different error:
|
yes, it is different
|
Getting the same error in Ubuntu 16.04:
|
Thanks. Will take a look at the new error. |
Apologies for not adding this originally, but i'm on Ubuntu 18.04, all other configurations are the same as @ymasson. Found this on a fresh install of 10.4.12 @garethgreenaway i propose this small change, sorry that its not a diff, but on line 390 of
Because of the following in
There is no documentation about what to put in EDIT: Change to |
And a diff in case anyone, like myself wants to patch before highstates, i spin these up quite often
|
MySQLdb/connections.py (python3-mysqldb) checks conv in different way to use builtin conversions: if 'conv' in kwargs:
conv = kwargs['conv']
else:
conv = conversions So I would propose connargs.pop('conv'). Anyway, it's not the only error. I have checked 2019.2.3 and connargs didn't have any None or '' value. However 3000 has many '' values, because config.option changed and it changes default when is None: if default is None:
default = '' if not wildcard else {} So I would change _connarg to check '' instead of None: - if val is not None:
+ if val != '':
connargs[key] = val |
Patch
{% if grains.saltversion == "3000" %}
patch:
pkg.installed
mysql_module_patch:
file.patch:
- name: '{{ grains.saltpath }}'
- source: salt://patches/files/3000-mysql.diff
- strip: 2
- require:
- pkg: patch
restart_salt_minion:
cmd.run:
- name: 'salt-call service.restart salt-minion'
- bg: true
- onchanges:
- file: mysql_module_patch
{%- endif %}
diff --git a/salt/modules/mysql.py b/salt/modules/mysql.py
index 87e2361e28..37436206d4 100644
--- a/salt/modules/mysql.py
+++ b/salt/modules/mysql.py
@@ -355,7 +355,7 @@ def _connect(**kwargs):
except IndexError:
return
val = __salt__['config.option']('mysql.{0}'.format(name), None)
- if val is not None:
+ if val != '':
connargs[key] = val
# If a default file is explicitly passed to kwargs, don't grab the Run |
I'll open another issue, but thought here was appropriate as well. With 10.4 and 3000, you need to have a default set of parameters for the minion, i've added this to our custom bootstrap to avoid restarting during a highstate
I'm not sure if this should be solved as another part of the salt code, likely not, but I spin up shared environments quite often and found that having it run during the highstate showed its edge cases. If this is not there before a restart salt 3K still trys an empty root password, so all clean highstates will fail. The |
Apologies for the delay on this one, I ended up addressing the initial issue with |
That PR looks good - all of my test cases are now passing. Additionally, a few older issues that I've been having (e.g. mysql_user insisting that a mysql user password was incorrect and setting it again even though no change was actually needed) are now also gone. Good fix. |
thanks for confirming the fix. closing with fix here #56174 |
This issue was marked as fixed in "3000.1 Release" planning, but salt 3000.1 was just released and we are still seeing the issue after an upgrade. In which version will the fix be included?
|
Oh, turns out we actually had #54702... a python package was missing but the salt error message was not giving any indication of that being the source of the problem. |
@garethgreenaway Happy to open a new issue if needed, my testing of 3000.1 shows this isn't completely fixed. Of note, we are using the python3 packages, not the python2 packages, so maybe that's a factor?
|
ping @garethgreenaway can you take a look here ^ |
@timwsuqld I haven't been able to reproduce this one with a clean Ubuntu 18.04 install and 3000.1 installed from the packages, using Python 3. This was using a fairly simple state to add a user into MySQL. |
States in MySQL Formula are working for me. |
Sigh. @garethgreenaway please close. I got bitten by my module override from #52045, we'd removed it with 2019.2.1 but when that was pulled we reapplied it, so we were still using the old module (and no longer had our ticket open to remove it). |
I personally think an INFO message on startup would be good for anything in |
@boltronics As a bonus, salt-version detecting and alerting to overrides would help when opening a ticket. Maybe I should open a new feature request. |
@timwsuqld @boltronics That would be a very useful feature to have, would one of you mind adding a new issue with the feature request? Thanks! Since everything is looking good on this, I'm going to go ahead and close this issue out. |
Description of Issue
MySQL module can't connect to MySQL socket.
Context
Debian 9 and MariaDB 10.4.
Module configuration:
mysql.default_file: '/etc/mysql/debian.cnf'
salt-minion 2019.2.3
salt-minion 3000
Versions Report
The text was updated successfully, but these errors were encountered: