-
Notifications
You must be signed in to change notification settings - Fork 794
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
Use MariaDB for Ubuntu 20.04 #1449
Conversation
mysql::params is a classthat may have no external impact to Forge modules. mysql::server::config is a classthat may have no external impact to Forge modules. This module is declared in 140 of 578 indexed public
|
+1 tested that this is working |
@LukasAud This is another quick win that we have been using with a customer. |
Seems reasonable. @treydock Would you consider this a breaking change, or is the module effectively broken for Ubuntu 20 users without this? |
(and could someone restart the build so that we can see what the ubuntu 20.04 build failures were about?) |
This module was not working at all on Ubuntu 20.04 without this change, at least not without overriding package names. I think can wait till 22.04 can be tested. |
manifests/params.pp
Outdated
@@ -171,9 +171,10 @@ | |||
} | |||
|
|||
'Debian': { | |||
if $::operatingsystem == 'Debian' { | |||
if $::operatingsystem == 'Debian' or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate a lot of the existing code doesn't, but can we start using the $facts
hash here instead of using topscope variables?
eg.
if $::operatingsystem == 'Debian' or | |
if $facts['operatingsystem'] == 'Debian' or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I've not any strong opinion on continuing to use 'legacy facts', but you could use the newer ones like $facts['os']['name']
instead)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to use non-legacy facts from facts hash.
The acceptance test failure looks like that long standing issue with acceptance tests when services run as non-root. |
Hey @ghoneycutt, thanks for the ping, will be keeping a close eye on this one. On the other hand, @treydock could you elaborate a bit more on the failure? This issue is very similar to another one we are experiencing on a cloud testing level for Debian systems. Any information and/or solutions for this issue will be very appreciated and could speed up work on our side for this and other issues. |
@LukasAud I no longer have access to the systems where this was an issue but it was Azure based Ubuntu 20.04 so this could be something unique to Azure's Ubuntu repos. I also no longer have access to Azure based systems so not sure I'll be able to further test solutions and my normally deployed systems are all RHEL so can't test there either. |
@treydock That is okay, we are working on our side to troubleshoot a very similar issue on a different system. We will let you know if we find a reliable fix for the issue. |
Hi @treydock, there is a new release for our MySQL module which I think may affect your PR. Could you rebase it? |
I've rebased. |
Hi, @treydock. I have looked over the latest checks. The goods news is that the previous error, which would crash the test run, is no longer present. However, there are still two distinct failures in the acceptance run that need to be addressed before I can merge this PR. One seems to be a recurring problem over most of the logged failures. I have noticed this log which repeats over all failures and seems to point to the cause of the problem: The other failure affects a single test case and throws the following errors:
If you can take a look at the code and address these errors so that the acceptance runs pass, I will be happy to merge this. |
If I had to guess, MariaDB for Ubuntu doesn't default to utf8mb3 so the changes to use that charset would need to be removed and just go back to utf8. Does this sound acceptable?
Further down this is the actual error:
I think what's happening is the idempotent issue from charset is causing the test to refresh and try and import the SQL again. Let me know of changing the default charset to utf8 for Ubuntu 20.04 is acceptable and I'll make that change. |
Yes, as long as the change is necessary and it doesn't break any other functionality, we are happy to accept this sort of changes. Furthermore, it seems like the only instance of charset replacement occurs in a spec_helper (spec_helper_acceptance_local.rb) file, and thus, any change or code removal should only affect the test cases, and no other core module functionality. |
I made the changes to acceptance tests, now Ubuntu 20.04 are passing. The failure for OracleLinux-6 looks unrelated. |
That's perfect. Thanks for your contribution. |
Issues reported earlier installing MySQL on Ubuntu may be related to manifests that attempt to grant any rights to root@localhost. Several errors will occur when trying to apply ANY grants to the root@localhost MySQL user in a manifest using the forge MySQL module Version 11.03 and higher, this has happened on 6 hosts in my environment with the configuration below. Removing all grants to root@localhost allows MySQL to install AND OR continue operating, without error. Grants to root@% do not break the manifest. Additionally, abandoning MySQL for MariaDB on Ubuntu, as done here, breaks prior implementations of this manifest by attempting to install MariaDB over MySQL. Explicitly declaring "package name' and 'package_ensure' resource types, as recommended, does not properly override the MariaDB install issue. These issues cause significant problems for production systems running Ubuntu / MySQL and updating this module from previous versions, especially in concert with the issue listed above. Please reconsider making MariaDB the default, or, make overriding that an easier affair. |
The change to MariaDB as the default in 20.04 caused issues for me as well. I started installing mysql-server and mysql-client with a version of puppetlabs-mysql that predated the release of Ubuntu 20.04, and while the server installed as expected, the client failed. So I updated the module to the latest release, and couldn't understand why it was complaining about mariadb-server not being able to install. After looking at the change log, I figured I'd go ahead and remove mysql-server and let it install mariadb, and while it installed the mariadb server and client packages, it would not start (complaining about "/usr/sbin/mysqld: One can only use the --user switch if running as root". I spent 30 minutes trying to understand that error, finally noticed that the "user" setting was coming from puppet, and decided I needed to purge maridb and mysql, totally wipe out /etc/mysql and re-run puppet. After doing that, mariadb server still wouldn't start, but for some other reason. So this time I purged / deleted /etc/mysql, and then "downgraded" to v12.0.3 of puppetlab-mysql. Re-ran puppet and mysql server and client installed without issue, mysql server started fine, and puppet set up the 100+ users / databases as configured. I don't know what issue were originally encountered with Mysql 8.0 on Ubuntu 20.04, but running a pretty generic setup, I didn't encounter any major issues (there's a minor issue involving default charset and collate, but that was easy to address in my local module). A comment in another ticket (#1500 (comment)) possibly suggests (the wording is ambiguous enough that I'm not sure) that MariaDB is what gets installed on Ubuntu 20.04 when you install mysql-server, but I don't think that's the case. I know the switch to mariadb as the default in puppetlabs-mysql is nearly a year old now, so reverting this change may itself be breaking. If so, perhaps one or more of the following could be done:
|
Hi @daehnomel and @enkidushane, we always appreciate feedback. However, its hard for us to track community opinions, issues and suggestions when they are in dead/merged PRs. If you have an issue to report or a suggestion to improve the module, please feel free to open a discussion in our 'Issues' tab and, if relevant, link back to this PR for more information. That way, we will have better visibility on it. |
Ran into numerous issues when Puppet attempted to install MySQL 8.0. Not sure if maybe the repos on Azure Ubuntu 20.04 are the problem but using MariaDB solved the issues.