The template only describes the agent-server path. manifests/site.pp introduces itself as "the main entry point used when an agent connects to the server", and the README has no puppet apply invocation or bootstrap guidance (its only "standalone" mentions are about standalone modules). Three audiences use a control repo without a server: disposable test environments (lab VMs, containers, CI jobs) that apply the repo directly, bootstrapping the first node of a fleet before any server exists, and small single-node setups. Someone in those situations gets no signal that the template supports their path.
It does support it, as shipped and with no workarounds. Verified on OpenVox 8.28.1 against a fresh clone:
r10k puppetfile install --verbose
puppet apply --hiera_config hiera.yaml --modulepath site-modules:modules manifests/site.pp
The catalog compiles and applies, and the template's own plug-ins load: $facts['rubypath'] (from site-modules/profile/lib/facter/simple_custom_fact.rb) resolves during compilation. No pluginsync emulation (the $settings::libdir file resource some control repos carry) is needed; puppet apply loads custom facts, external facts, functions, and types/providers directly from the modulepath. Background and verification details: OpenVoxProject/openvox-docs#449. (The only noise in the run was Facter attempting to execute windows_external_fact.ps1 on Unix, which is #9.)
Suggested fix, two small changes:
- A short README section ("Using this repo without a server" or similar) with the invocation above, noting r10k must run first so Puppetfile modules are on the modulepath, and that
--detailed-exitcodes exit code 2 means changes were applied.
- Reword the
site.pp header comment so it doesn't read as agent-only, e.g. "the main entry point when a node requests a catalog, whether from OpenVox Server or via puppet apply".
A standalone-apply how-to is being contributed to openvox-docs (OpenVoxProject/openvox-docs#449); once it lands the README section can link to it rather than explain much itself.
Drafted with Claude (Claude Code), per the AI usage policy. The apply run above was executed on macOS with the openvox gem; a Linux AIO run should behave identically but was not part of this verification.
The template only describes the agent-server path.
manifests/site.ppintroduces itself as "the main entry point used when an agent connects to the server", and the README has nopuppet applyinvocation or bootstrap guidance (its only "standalone" mentions are about standalone modules). Three audiences use a control repo without a server: disposable test environments (lab VMs, containers, CI jobs) that apply the repo directly, bootstrapping the first node of a fleet before any server exists, and small single-node setups. Someone in those situations gets no signal that the template supports their path.It does support it, as shipped and with no workarounds. Verified on OpenVox 8.28.1 against a fresh clone:
The catalog compiles and applies, and the template's own plug-ins load:
$facts['rubypath'](fromsite-modules/profile/lib/facter/simple_custom_fact.rb) resolves during compilation. No pluginsync emulation (the$settings::libdirfile resource some control repos carry) is needed;puppet applyloads custom facts, external facts, functions, and types/providers directly from the modulepath. Background and verification details: OpenVoxProject/openvox-docs#449. (The only noise in the run was Facter attempting to executewindows_external_fact.ps1on Unix, which is #9.)Suggested fix, two small changes:
--detailed-exitcodesexit code 2 means changes were applied.site.ppheader comment so it doesn't read as agent-only, e.g. "the main entry point when a node requests a catalog, whether from OpenVox Server or via puppet apply".A standalone-apply how-to is being contributed to openvox-docs (OpenVoxProject/openvox-docs#449); once it lands the README section can link to it rather than explain much itself.
Drafted with Claude (Claude Code), per the AI usage policy. The apply run above was executed on macOS with the openvox gem; a Linux AIO run should behave identically but was not part of this verification.