Add possibility to override Mysql implementation

[carroarmato0]

In some cases a different flavour of Mysql is required.

Example: default on RHEL 7 is MariaDB, but Oracle Mysql is required due to support contracts.

Signed-off-by: Christophe Vanlancker christophe.vanlancker@inuits.eu

[bmjen]

I would be more comfortable with this if the conditional handled the provider_override case first and do some validation.

if $provider_override != undef {
  if $provider_override =~ /^(mariadb|mysql)$/ {
    $provider = $provider_override
  } else {
    # maybe error due to failed validation of $provider_override?
  }
}

I'm hesitant in keeping this vague, because for example on Fedora 19+ the default provider would be mariadb, but if the override were improperly set to foo, then according to this codepath, the block at line 72 would continue the setup as if it were mysql.

[bmjen]

This also needs tests for the new param and functionality.

[carroarmato0]

@bmjen sorry for the delay, will implement your suggestion and submit an updated pull request

[igalic]

i'm not sure what to think of a parameter to the params class…
although it seems marginally better than tripple indirection like with postgresql's globals → params → server

[bmjen]

@carroarmato0 Any progress on this PR?

[Denter-]

This doesn't solve whole problems, because, for example, in Centos 7 there are no mysql-server in standard repositories, and command "yum install mysql-server" installs mariadb anyway...
So, we have to add mysql-community-release repository and install mysql-community-server package.

[Floyd25]

ping.

I'd need this option to install mariadb on Debian Jessie

[aerostitch]

Hi,

Silly question, but as the params class is kind of here to provide default values, why wanting to modify the params class. You can still force the package name by overriding the $package_name (and the $default_options hash) value of the mysql::server class right?

I agree that the mariadb install needs some documentation but I'm not sure if we need to actually change the code. Is it to have fewer parameters when you use several classes on the same server?

I may be mistaken here, so if I do don't hesitate to explain me! ;)

Thanks
Joseph

[jostmart]

I can confirm what aerostitch wrote, it's fully possible to install whatever mysql-server package via the $package_name parameter. Also, I have enough control over the content in the configuration file, via the default_options hash.

[carroarmato0]

@jostmart @aerostitch: you've got a point, can't believe I haven't tried that in the first place, but that's community review for you. I'll try this as soon as possible and provide feedback if it solves my usecase.
If it does, this PR could just be discarded.

[NoodlesNZ]

I'm running into this problem on CentOS 7 installing Percona (which uses the default MySQL paths)

[aerostitch]

Hi @NoodlesNZ ,

Do you have the puppet manifest/profile you use so far and the issues you have?
Generally you can set the version directly with package_ensure (from the mysql::server class) if it's just that the version is not installed for example.

Just in case you are blocked:
There's a lot of ways that you can have yum install the mysql package from the repository you want (yum lock version, yum-priorities, etc). The problem here would be that the package has the same name. At least I guess it's your issue.
It is also possible to set the package_manage parameter set to false (from the mysql::server class) which would disable the installation using this puppet module and have it installed with a specific declaration.

But most of the 2 last ones, even if they should work fine, would be more of a bandaid compared to use the package_ensure, package_name and default_options parameters (from the mysql::server class).

Thanks
Joseph

[aerostitch]

@NoodlesNZ : I did the installation of Percona 5.7 on a CentOS 7, so I added a patch and documented the example in #819 . Don't hesitate to test it and provide your feedback.

Thanks
Joseph

[igalic]

with #819 merged, can we close this now?

[shollingsworth]

I'd like to see this feature as well. I'm specifying Percona as my package, but deps are getting stuck trying to input defaults for MariaDB.

[aerostitch]

@shollingsworth did you follow the example provided in the readme? https://github.com/puppetlabs/puppetlabs-mysql#install-percona-server-on-centos

This one is for Percona but there's not a lot of differences in the way to do it.
I have some Mariadb instances managed by this module on Ubuntu. I'll try to add the documentation example for this case in the afternoon if I get some time.

[shollingsworth]

@aerostitch I did follow those directions. The providor variable kept switching to mariaDB so it would continually fail on things like the log directory. Like I've seen commented elsewhere, being able to control the provider variable through parametrization would be the best solution IMO.

[aerostitch]

Hm, what's in the params.pp are just default values, so that means some parameters are missing. Could you paste the manifest you're using?

I'll try to do a PR on the readme this afternoon with the mariadb installlation example.

[beyerz]

I have the same issue, I use centos7, but would like to use MySQL and not MariaDB. But the params file defines the logs based on the OS and not the package.

I implemented this change (with a slight difference) and it worked great.

case $::osfamily {
    'RedHat': {
      if $provider == undef {
        case $::operatingsystem {
          'Fedora': {
            if versioncmp($::operatingsystemrelease, '19') >= 0 or $::operatingsystemrelease == 'Rawhide' {
              $provider = 'mariadb'
            } else {
              $provider = 'mysql'
            }
          }
          /^(RedHat|CentOS|Scientific|OracleLinux)$/: {
            if versioncmp($::operatingsystemmajrelease, '7') >= 0 {
              $provider = 'mariadb'
            } else {
              $provider = 'mysql'
            }
          }
          default: {
            $provider = 'mysql'
          }
        }
      }

[aerostitch]

Again, mysql::params is a private class where the module stores its default values.
You're not supposed to set variables on the mysql::params class directly.
All the variables set in mysql::params should be ovewritable via parameters of public classes. See the list on: https://github.com/puppetlabs/puppetlabs-mysql#public-classes It's a really bad idea to try to overwrite this class.

[beyerz]

@aerostitch, that's fair, but then we should be able to expose and define log directories in the public MySQL class and only use the os based decision making in the Params class if they are not defined. Right now my situation is I successfully install MySQL on C7 but log files are attempted to be created under the mariadb log route. If you have a potential solution I would be happy to implement it.

[aerostitch]

The log files you are talking about are the log-error parameter in the my.cnf @beyerz ?

In this case, you just need to pass the following parameter to your mysql::server class call (or declare that in hiera) as showned in the readme example:

override_options => {
    mysqld => {
      log-error => '/var/log/mysqld.log',
    },
    mysqld_safe => {
      log-error => '/var/log/mysqld.log',
    },
  }

The override_options parameter is a hash containing the values of the my.cnf that you want to customize. It overrides the default values set inside the params.pp.
Did you try that?

[beyerz]

I didn't realise this was an option, (must have missed it in the docs when I read through them) Ill give it try, I hope it works.

[aerostitch]

I've did some tests and it works fine.
I created the example for the README.md in #857

@carroarmato0 were you able to do your tests with the Oracle version of MySQL? If not, how far are you? Can you post your manifest please?
I can dig and provide the corresponding example if necessary, but it should work without any modifcations (other modifications than setting the usual class parameters).

Thanks
Joseph

[cfiehe]

It would be quite nice to extend this feature to allow. e.g. installation of MariaDB on Debian systems via this module.

What are your thoughts?

[aerostitch]

Hi @cfiehe,

Did you read the documentation of this module?
There's an example on how to install mariadb with this module on Ubuntu which is a Debian-based system.
You can use this same example for any Debian-based system. It's already built-in. You just have to read the readme.

Joseph

[cfiehe]

Oh, I am sorry. I just missed that section in the readme (https://github.com/puppetlabs/puppetlabs-mysql#install-mariadb-on-ubuntu). Thanks for clarifying that.

[cjtoolseram]

When is this PR going to be merge?

[aerostitch]

Hi,
It seems you haven't read the full thread or the documentation otherwise you would know that it seems not to be the right approach.
What are you trying to accomplish that has not been explained in the readme and that doesn't work @cjtoolseram ?

Thanks

[fwdIT]

@aerostitch, since I needed to do some changes to the code @carroarmato0 was talking about above, I successfully eliminated the usage of provider_override by using the suggested overrides similar to what is shown (by you) and documented on the url mentioned above (https://github.com/puppetlabs/puppetlabs-mysql#install-mariadb-on-ubuntu)
so this issue is solved in the code @carroarmato0 was working on here at this customer. I think this PR can be dismissed now

[igalic]

thank you very @fwdIT & @carroarmato0