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

[lbdemv]

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 074067a 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:

voxpupuli/community-triage#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.