Description
Describe the Bug
If mpm_event
is enabled with apache::mod::event
, using apache::mpm::disable_mpm_event
will not disable it. Internally, at least on Debian 12, it looks like the event
and mpm_event
modules are identical, aside from the mpm_event
module specifically warning about conflicts with other MPM modules. As a result, I believe it is a bug that the module's method to enable the module is not compatible with the way to disable the module.
Note: I will add a pull request with a patch to fix this behavior; I wanted an issue to link it against.
Expected Behavior
The expected behavior is that the Puppet module can both enable or disable mpm_event
, based on variables such as host facts.
Steps to Reproduce
Steps to reproduce the behavior:
- Apply a manifest to a system that includes
mpm_event
:
include apache::mod::event
- Later, apply a different manifest to the same system that disables the same module:
include apache::mpm::disable_mpm_event
- Module will still be enabled, as the class to enable uses the name without the
mpm_
prefix, while the class to disable the module does use thempm_
prefix.
Environment
- Version 12.1
- Platform Debian 12
Additional Context
The inconsistency is caused by the module being enabled with ${mpm}
as `event``:
puppetlabs-apache/manifests/mpm.pp
Line 49 in 58dada6
puppetlabs-apache/manifests/mpm.pp
Line 57 in 58dada6
While the module is disabled with:
This is inconsistent with prefork and worker, which are enabled and disabled without the mpm_
prefix.