Switch getting-started guides to OpenVoxProject/control-repo-template

[miharp]

OpenVoxProject/control-repo-template now exists as the community's control-repo starting point: adapted from puppetlabs/control-repo (Apache-2.0, attributed), rebranded for OpenVox, module Gemfiles on the openvox/openfact/openbolt gems, working GitHub Actions CI, production as default branch, and the GitHub "Use this template" button enabled. The getting-started guides should point people at it instead of puppetlabs/control-repo.

Affected pages

• docs/_openvox_8x/getting_started.markdown (Step 3 "Set up a control repository")
• docs/_openvox_8x/getting_started_local.markdown (Prerequisites + Steps 1/3/4)
• The _openvox_9x copies of both pages are identical today; they only exist on the open OpenVox 9 cutover branch (Add OpenVox 9.x docs collection as a preview (latest stays on 8.x) #430), so the change lands on 8x and flows to 9x via the cutover runbook's content-drift port step (or directly once Add OpenVox 9.x docs collection as a preview (latest stays on 8.x) #430 merges).

Changes

getting_started.markdown

• Replace the "clone puppetlabs/control-repo" instructions with creating a repository from OpenVoxProject/control-repo-template — "Use this template" on GitHub, or clone-and-push for other Git hosts (the template README documents both flows).
• The template's default branch is already production, so the guide's branch-naming caveat can be simplified.
• Update the example r10k remote and surrounding wording as needed.

getting_started_local.markdown

• Replace the "fork puppetlabs/control-repo" prerequisite with creating a copy from the template (users still need their own copy so they can push changes in Step 4).
• Fix a real bug found while testing: the guide claims the crafty openvox/oss server container "runs r10k automatically on startup" via R10K_REMOTE. It does not — ghcr.io/openvoxproject/openvoxserver:latest has no r10k logic in its entrypoint, and the commented R10K_REMOTE line in the oss compose file is a dead leftover. crafty's r10k automation lives in its separate openvox/r10k example, which runs a dedicated ghcr.io/voxpupuli/r10k container to populate the code volume. The guide needs one of:
  1. a manual step that writes /etc/puppetlabs/r10k/r10k.yaml in the server container and runs r10k deploy environment -p (verified working, smallest change), or
  2. a retarget to crafty's openvox/r10k example, or
  3. an upstream fix adding R10K_REMOTE support to container-openvoxserver (out of scope here; would need its own issue).
• Add a note that after r10k first overwrites the image's default skeleton environments, the server serves a stale cached environment config (e.g. epoch config_version) until the environment cache is flushed or the server restarts.

Verification done

The template was tested end-to-end through the local guide's flow on 2026-08-10 (crafty oss stack, Docker): r10k deploys the template as production, a fresh agent enrolls via autosign and applies the catalog cleanly, pluginsync picks up the template's custom facts/types, and config_version reports puppet-production-<sha> after a server restart.

Related

• Pairs with the microsite phase-out (Port remaining content from the voxpupuli.org OpenVox install page before the microsite is phased out #442), which also touches install/getting-started pathways.
• Follow-up outside this repo: jig new control-repo scaffolding in voxpupuli/jig consuming the template.