You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 10, 2023. It is now read-only.
Although it would be hard to tell from the docs, the puppetserver class's provisions for managing puppetserver config files are very limited. Class parameter $puppetserver::config is the public gateway to what little it does provide, and contrary to initial appearances, that is limited to four Java arguments, two webserver.conf settings, and one puppetserver.conf setting.
Affected Puppet, Ruby, OS and module versions/distributions
Puppet: all
Ruby: all
Distribution: all
Module version: 3.0.0
How to reproduce (e.g Puppet code you use)
N/A
What are you seeing
The one parameter of class puppetserver, $puppetserver::config, lacks support for most puppetserver settings.
What behaviour did you expect instead
Every configuration setting recognized by puppetserver, in each of its configuration files, should be manageable by binding data to class puppetserver.
Output log
N/A
Any additional information you'd like to impart
The module provides defined type puppetserver::config::puppetserver by which it appears that any configuration setting can be managed, whether actually recognized by the puppetserver software or not. This provides for a workaround for the issue.
Overall, I don't care much for the approach implemented for $puppetserver::config, which basically sets up its own local vocabulary of structured setting names to be used with the module. This would be unnecessarily difficult to use even if the details were well documented, and they are not. It would be better for the data bound to class puppetserver for the purpose of managing configuration settings to map more directly onto the state to be managed: (relative) file name, section, setting, value. I'm sure the idea behind the current implementation was to make it easier to specify settings, but it is not easier for users to have to remember or look up two separate spaces of configuration names and the relationships between them than it would be to rely on just one.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Although it would be hard to tell from the docs, the
puppetserver
class's provisions for managing puppetserver config files are very limited. Class parameter$puppetserver::config
is the public gateway to what little it does provide, and contrary to initial appearances, that is limited to four Java arguments, twowebserver.conf
settings, and onepuppetserver.conf
setting.Affected Puppet, Ruby, OS and module versions/distributions
How to reproduce (e.g Puppet code you use)
N/A
What are you seeing
The one parameter of class
puppetserver
,$puppetserver::config
, lacks support for most puppetserver settings.What behaviour did you expect instead
Every configuration setting recognized by puppetserver, in each of its configuration files, should be manageable by binding data to class
puppetserver
.Output log
N/A
Any additional information you'd like to impart
The module provides defined type
puppetserver::config::puppetserver
by which it appears that any configuration setting can be managed, whether actually recognized by the puppetserver software or not. This provides for a workaround for the issue.Overall, I don't care much for the approach implemented for
$puppetserver::config
, which basically sets up its own local vocabulary of structured setting names to be used with the module. This would be unnecessarily difficult to use even if the details were well documented, and they are not. It would be better for the data bound to classpuppetserver
for the purpose of managing configuration settings to map more directly onto the state to be managed: (relative) file name, section, setting, value. I'm sure the idea behind the current implementation was to make it easier to specify settings, but it is not easier for users to have to remember or look up two separate spaces of configuration names and the relationships between them than it would be to rely on just one.The text was updated successfully, but these errors were encountered: