Hello,
as already described in PR #6295 (https://github.com/ansible/ansible/pull/6295) I think the config file parsing in the MySQL modules is broken. These are the problems I see with the current code:
There was a reasonable amount of work done in that module, I believe, to deal with a lot of vague non-standardness in the MySQL parsing logic.
One of the problems is that only in Python 2.7 does config parser allow loading of options without an “equals” in it, so I think that’s why that magic was there.
That all being said, if you think there’s something that can’t be parsed, like a free option, I agree that needs to be fixed.
Ultimately the question here is if this is code cleanup, can you enumerate problems this resolves other than in the cleanliness of the implementation?
It certainly deletes a lot of code, what config file reading remains?
Hi there,
my original intention was not to clean up the code but to add the possibility to parse other config files than ~/.my.cnf. This was hardcoded and there was no possibility to override this. While adding the parameter “config_file” I came across the described problems. So this is in fact both: code cleanup and and added feature.
As stated by jctanner (https://github.com/ansible/ansible/issues/4454#issuecomment-26632326) in the issue that was originally related to the problem that ConfigParser can’t handle key-only entries the long-term solutions would be to use the parameter “read_default_file”. That is changed in my PR.
Best regards,
Sven
I definitely would like to see the ability to call other config_file’s if specified.
Hello,
I would like to bring this thread back to life. There are appearing issues, PRs and posts on the mailing list adressing issues with the config parsing from time to time.
For example:
This shows that there really is a need for this! And it’s a pity that there are PRs written doing nearly the same that is already in the queue. But neither my half year old nor the freshly written ones get accepted.
This is kind of frustrating, to be honest. Not only for me but also for those writing new approaches. Is there a way we can get this work and improve how ansible’s mysql modules work? I really see room for improvement here!
Best regards,
Sven
+1, Would be glad to assist with any suggestions to get this merged in.
“But neither my half year old nor the freshly written ones get accepted.”
It’s fine to resurrect bugs, but let’s understand what’s going on here - we have a priority system where everything is flagged P1, P2, P3 and so on. This was tagged a P3, so we’re tackling P2 items first.
The ticket https://github.com/ansible/ansible/pull/8819 is only 13 days old, which is well within standard, and has had very recent activity in the last few days.
https://github.com/ansible/ansible/issues/8915 is only 4 days old.
We’re not going to get to everything instantly, so please be patient.
We have some feature pull requests that have been in the queue for months, understand this project has over 870 contributors, lots of folks filing bug reports (many that require reproduction and alas sometimes are of poor quality) and we have to sort through all of this.
I don’t think you have an issue with MySQL being wholesale-broken, but have specific requests, and those will be gotten to in time.
–Michael
I’m not sure where the link to the older one is, feel free to link to it and we can take a look.
It probably wasn’t clear that X was a bug or an additional feature to the MySQL module, or how common a fringe case was in your instance.
On a related note, for those asking how to make things move along faster, we released a guide yesterday about helping to test pull requests.
It may be worth a read for those that want to get more involved with the project:
I think its both in this case. X is a bug for parsing, and to load a config other then ~/.my.cnf is a feature request, I do believe they are labeled correctly at the moment in their respective tickets.
Seems like I’m too clumsy to work with google mail, somehone the group didn’t make it to the recipient list. 
Thanks!
I’ve moved this one up to P3 and also tagged it with “bugfix_pr” so it can get some more attention a bit sooner - though we’re still going to continue to strike down the P2’s first. We do have some MySQL module integration tests now that should help validation a bit quicker.
–Michael