Skip to content
This repository has been archived by the owner on Jan 10, 2023. It is now read-only.

The puppeterver class's facilities for managing config files are rigid and limited #59

Open
jcbollinger opened this issue Apr 24, 2018 · 0 comments

Comments

@jcbollinger
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant