(#MODULES-1058) root_password.pp cannot create /root/.my.cnf due to depe...

[lodgenbd]

...ndency

The dependency of creating the root .my.cnf file is a command which requires
the .my.cnf file. This patch removes that dependency. Without removing the
dependency, if a user already has a mysql server installed with a root password
and no root .my.cnf file, the module application will fail.

[matthewfischer]

I tried similar but it seemed to cause other issues in my environment. I ran out of time to dive in more, but this does seem like the obvious fix. I will try it again hopefully this week.

[igalic]

@lodgenbd help me understand the use-case here:

i have a mysql-server installed, with a known root password, and i want to use puppetlabs-mysql to manage it?

how will this change affect the usecase of, i want to install a new mysql server?

[lodgenbd]

@igalic The use case you mentioned of already having a mysql server installed is one where the mysql server is already set up and in production setting, the user is trying to have puppet manage services for ease of configuration, and wants to apply mysql module to manage mysql server. In this case, the module will fail. With my code change, the module tested successful.

I tested my code change in the use case of "i want to install a new mysql server" with no issues, as well.

[igalic]

okay, thank you for the clarification, @lodgenbd, and for the patch!

[hogepodge]

igalic, fwiw, this patch broke my mysql use case.

[lodgenbd]

@hogepodge what's your use case?

[hogepodge]

I'm running the puppet-openstack module set. When I run the code from those modules to set up a variety of users and accounts the .my.cnf file is not handled properly, and I get locked out of mysql administration.

This is on both Ubuntu 14.04 (mysql) and CentOS 7 (mariadb).

[lodgenbd]

@hogepodge when you say the file isn't handled properly, what exactly is happening with the file?

[lodgenbd]

@cyberious can you share what you're seeing?

[hogepodge]

In a while I can post the error I'm seeing. I actually depend on this module for day to day work, so when it broke in my environment I pinned back to a stable version so I could stay productive. What I do know is that previously I could create new users and databases, and my ability to do that with the module broke. I'm not sure exactly what's going on, but if I recall correctly it's telling me that I can't log in as the root user.

[lodgenbd]

@cyberious can you confirm if the .my.cnf file was created before that error occurred?

[lodgenbd]

It sounds like we need an order relationship so that the .my.cnf file is created before anything that would run a mysql command requiring it. I'm going to assume that's what's happening, unless someone reports that their .my.cnf file is being incorrectly built, which would be another issue altogether.

[lodgenbd]

@igalic, Let me know what you think, but I see a couple of issues:

The root user and the .my.cnf file are in the same class, so when the below is called, it tries to take actions before making the .my.cnf file, and they fail. This is in the server.pp:

} else {
Anchor['mysql::server::start'] ->
Class['mysql::server::install'] ->
Class['mysql::server::config'] ->
Class['mysql::server::service'] ->
Class['mysql::server::root_password'] ->
Class['mysql::server::providers'] ->
Anchor['mysql::server::end']

If you move the root_password class higher in the order above the install class, it would also fail because the class would try to do two things:

1.) create the root user within mysql
2.) create the .my.cnf file

...before mysql is installed. In that case, step 1 above would fail because mysql isn't installed, but step 2 would succeed, because it's just a file and doesn't rely on anything.

I believe that step 2 should be pulled out, added to a class of its own, and placed in order before the "install" class, then made a requirement of any resource that would use a "mysql" command.

Having said all of that... after looking through almost all of the code for this module, I believe the module was written moreso with the idea that this is for installation of a mysql server and less in the mind of managing one that's already installed and running. If that's true, then the best plan may be just to remove and revert this code back before this merge, then add a note in the README that this module isn't meant for that use case, noting the above as a reason why.

Please update and let me know what you think.

[cyberious]

@lodgenbd @igalic for now we are reverting the change until a new one that address both use cases can be found.

[lodgenbd]

Agreed, thank you