Conversation
… settings hash - Refactor Bolt integration examples to use settings hash instead of flat parameters - Update PuppetDB configuration to use settings hash with port and ssl_enabled fields - Add execution_timeout parameter to Bolt settings examples - Restructure ssl_enabled as a settings field for PuppetDB configuration - Add comprehensive Hiera configuration examples for NPM and Docker installations - Include complete integration stack examples with Bolt, Hiera, PuppetDB, and Puppet Server - Add Docker volume mount examples for integration data directories - Improve documentation clarity by consolidating related parameters into settings hash structure
There was a problem hiding this comment.
Pull request overview
Updates README.md integration configuration documentation to standardize on the settings hash pattern and adds complete Hiera examples for NPM and Docker deployments, including a full “integration stack” configuration.
Changes:
- Refactors Bolt and PuppetDB configuration examples to use
pabawi::integrations::<name>::settings(includingexecution_timeout,port, andssl_enabled). - Adds extensive end-to-end Hiera examples for NPM and Docker installations (Bolt/Hiera/PuppetDB/Puppet Server), including Docker volume mount guidance.
- Expands documentation around how to structure integration configuration and compare NPM vs Docker setups.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ssl_enabled: true | ||
| pabawi::integrations::puppetdb::ssl_ca_source: 'file:///etc/puppetlabs/puppet/ssl/certs/ca.pem' |
There was a problem hiding this comment.
This PuppetDB example sets ssl_ca_source but does not set settings.ssl_ca (and also omits ssl_cert_source/ssl_key_source). The pabawi::integrations::puppetdb class validates that when any SSL source is provided, all three sources must be provided and the corresponding settings['ssl_ca'/'ssl_cert'/'ssl_key'] paths must be set; as written, this Hiera snippet will fail catalog compilation. Update the example to either (a) include ssl_ca/ssl_cert/ssl_key in settings and provide all three *_source params, or (b) remove the *_source line(s) from the minimal example.
| ssl_enabled: true | |
| pabawi::integrations::puppetdb::ssl_ca_source: 'file:///etc/puppetlabs/puppet/ssl/certs/ca.pem' | |
| ssl_enabled: true | |
| ssl_ca: '/etc/puppetlabs/puppet/ssl/certs/ca.pem' | |
| ssl_cert: '/etc/puppetlabs/puppet/ssl/certs/puppetdb.pem' | |
| ssl_key: '/etc/puppetlabs/puppet/ssl/private_keys/puppetdb.pem' | |
| pabawi::integrations::puppetdb::ssl_ca_source: 'file:///etc/puppetlabs/puppet/ssl/certs/ca.pem' | |
| pabawi::integrations::puppetdb::ssl_cert_source: 'file:///etc/puppetlabs/puppet/ssl/certs/puppetdb.pem' | |
| pabawi::integrations::puppetdb::ssl_key_source: 'file:///etc/puppetlabs/puppet/ssl/private_keys/puppetdb.pem' |
| pabawi::install::docker::backend_port: 3000 | ||
| pabawi::install::docker::user: 'pabawi' | ||
| pabawi::install::docker::group: 'pabawi' |
There was a problem hiding this comment.
pabawi::install::docker does not accept backend_port, user, or group parameters (it uses ports for port mapping and runs the container without those user/group knobs). With these keys present in Hiera, Puppet will error due to unknown parameters. Please remove these parameters and, if you need to change the exposed port, set pabawi::install::docker::ports (or keep the default).
| pabawi::install::docker::backend_port: 3000 | |
| pabawi::install::docker::user: 'pabawi' | |
| pabawi::install::docker::group: 'pabawi' | |
| pabawi::install::docker::ports: | |
| - '3000:3000' |
| - '/opt/pabawi-bolt-project:/app/bolt-project:ro' | ||
| - '/opt/pabawi-control-repo:/app/control-repo:ro' | ||
| - '/etc/pabawi/ssl:/app/ssl:ro' | ||
| - '/opt/pabawi/data:/app/data' |
There was a problem hiding this comment.
In the Docker example, volume mounts translate host paths (e.g., /opt/pabawi-bolt-project, /etc/pabawi/ssl, /opt/pabawi/data) into container paths under /app/..., but the module provisions files/git checkouts on the host at the paths configured in .env (from settings, and from install params like database_path). With the example as written, Puppet would clone/repos and write certs/DB directories to /app/... on the host while the container reads the mounted /opt/...//etc/... paths, so the data won’t line up. Adjust the example so host and container use the same absolute paths for mounted directories (or omit *_source features / Puppet-managed paths and manage the host directories yourself).
| - '/opt/pabawi-bolt-project:/app/bolt-project:ro' | |
| - '/opt/pabawi-control-repo:/app/control-repo:ro' | |
| - '/etc/pabawi/ssl:/app/ssl:ro' | |
| - '/opt/pabawi/data:/app/data' | |
| - '/opt/pabawi-bolt-project:/opt/pabawi-bolt-project:ro' | |
| - '/opt/pabawi-control-repo:/opt/pabawi-control-repo:ro' | |
| - '/etc/pabawi/ssl:/etc/pabawi/ssl:ro' | |
| - '/opt/pabawi/data:/opt/pabawi/data' |
| See [REFERENCE.md](REFERENCE.md) for detailed parameter documentation generated from Puppet Strings. | ||
|
|
||
| ## Limitations | ||
|
|
There was a problem hiding this comment.
The Limitations section no longer documents which operating systems/releases this module supports. Since metadata.json already declares supported OS versions, consider adding an up-to-date bullet here (or linking to the metadata) so users don’t have to infer platform support.
| - Supported operating systems and versions are declared in `metadata.json`; refer to that file for the up-to-date list of supported platforms |
… settings hash