Mysql config file must be written before mysql server package is installed

[tobixen]

Found yet another obscure "bug". This time I'm on Ubuntu 14.04 (this may be a problem at RHEL7 as well - will check that up eventually).

We're populating the mysql config file through the mysql::template and mysql::options class parameters. innodb_log_file_size is among the parameters we set there.

Mysql won't start if the innodb_log_file_size config differs from the real size of the innodb_log_file - and mysql will create the innodb_log_file using the default file size if the config file doesn't exist when the package is installed. (we're explicitly setting it in the config now as we crashed with another weird bug in production the other day - in percona xtradb cluster the default innodb_log_file_size is 48M, while in the xtradbbackup tool the default size is 5M).

Today, the mysql config file requires the mysql package. I'll try to switch it around, unless there is a good reason for this dependency?

[tobixen]

Got everything up and running ... on Ubuntu 14.04. I'll do some more testing before sending a pull request though.

Of course, the $mysql::config_file_owner and $mysql::config_file_group may depend on the package to be defined at some setups, though it's defined to be either root or wheel in params.pp.

[tobixen]

I'm so fed up with dependencies now ... (not only this problem ... but also with percona and percona-xtradb-cluster on rhel7, it's very easy to indirectly get the wrong client libraries or client installed, even installing postfix will by default cause mariadb-libs to be installed, which blocks for percona, etc).

This seems non-trivial, not only because we cannot know if $mysql::config_file_group is dependent on the package, but also because we need to ensure the /etc/mysql directory is created if the config file is located there. Almost whatever I'll do, the risk that my changes will break something for someone is significant. So I'll try to find another workaround on this silly-stupid problem.

[tobixen]

Apparently only an issue with Percona on Ubuntu.

I did this crazy workaround locally as for now:

    exec { 'delete-pesky-innodb-log-file':
        path        => '/bin:/usr/bin',
        refreshonly => true,
        command     => "mv ${mysql::data_dir}/ib_logfile* /tmp || true",
        before      => Service['mysql'],
        subscribe   => Package['mysql']
    }

... as the innodb log file will be rebuilt with the correct file size if it's missing.

I believe that this issue is so obscure (only percona, only ubuntu and only if the config variable innodb_log_file_size is set in the config file) that it most likely can be ignored.

[alvagante]

Well, thanks for the report and the explanations.
The file dependency on the package is needed to avoid to try to configure the file before installing the package. Your exec is a bit risky, as you surely know, if for whatever reason the package is reinstalled, the command is executed, this should not generally happen.
Having parameters that change according to the values of other parameters (like file owners on different package names) is always a pain to handle, as you have to place all the logic in the main class, and can't safely stay in params class.