Upgrade 16.0.0 -> 16.2.0 on Debian 11 fails because of double declared File ressource

[lbdemv]

trafficstars

Describe the Bug

After upgrading from module 16.0.0 the already installed server fails during the puppet agent run with the following Duplicate declaration Error:

~# puppet agent -t --noop --environment renovate_puppetlabs_mysql_16_x
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: File[/var/log/mysql] is already declared at (file: /etc/puppetlabs/code/environments/renovate_puppetlabs_mysql_16_x/.modules/mysql/manifests/server/managed_dirs.pp, line: 37); cannot redeclare (file: /etc/puppetlabs/code/environments/renovate_puppetlabs_mysql_16_x/.modules/mysql/manifests/server/installdb.pp, line: 34) (file: /etc/puppetlabs/code/environments/renovate_puppetlabs_mysql_16_x/.modules/mysql/manifests/server/installdb.pp, line: 34, column: 5) on node XXX

Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

The change introduced in https://github.com/puppetlabs/puppetlabs-mysql/pull/1653/commits/074067abaa57f132d900b41e484cd8e9e3c4d662 in the file manifests/server/installdb.pp to create the folder /var/log/mysql seem to break with the (debian specific) automatically managed dir permissions in the manifests/server/managed_dirs.pp file.

Expected Behavior

A clean puppet run with no changes, since the module had only a minor update 16.0.0 -> 16.2.0

The folder (creation and permissions) should be handled by the managed_dirs.pp manifest.

Steps to Reproduce

Steps to reproduce the behavior:

1. Install debian 11 server
2. Setup a mariadb server with the module in version 16.0.0
3. Upgrade the module version to 16.2.0
4. Initiate a Puppet agent run

Environment

• Version 16.2.0
• Platform Debian GNU/Linux 11 (bullseye)

Additional Context

[lbdemv]

This is probably relevant to #1599 and #1653

[lbdemv]

@shubhamshinde360 could you maybe review your changes in the mentioned commit, since the update to a version including this commit, effectively breaks the module functionality on Debian 11

[lbdemv]

Any comment on this issue?

@malikparvez you approved the PR that introduced this issues ( #1653 ). Maybe you have a suggestion on how to continue? Or revert the breaking change?

[Marmelatze]

I ran into the same issue. My current workaround is setting the log-bin param to /var/lib/mysql/mariadb-bin/mariadb-bin.log

[lbdemv]

@bastelfreak you were requested at the original PR #1653 , could you take a look at this issue?

[bastelfreak]

No, I won't provide free labour to Perforce until they figure out if we're actually allowed to use their software:

https://github.com/voxpupuli/community-triage/issues/29

[sagepe]

This affects us too, as we set log-bin to a file under /var/log/mysql/. We don't want to change this.

As the location of the error log is configurable, perhaps an improved solution over hardcoding a directory resource in installdb.pp would be a treatment of $options['mysqld']['log-error'] in managed_dirs.pp similar to that for log-bin?

That way any duplication could be detected and handled as well as a directory created if needed.

[rtuk]

We ran into the same issue, however for us the proposed changed doesn't work. We have /var/log/mysql symlinked to /database/log, would it not be better to have ensure on "present" instead of "directory"?

[timmooney]

I haven't seen it mentioned, but it's also not a great idea to hardcode 'mysql' as the log directory, since this module ostensibly supports MariaDB too. At least RHEL defaults to /var/log/mariadb/ , so with this change we now have /var/log/mariadb as the real log directory and /var/log/mysql as a new directory just to confuse the unwary.

[mburlic]

16.3.0 is out and this issue is still present :(