Restore the pre-codavox dev repo, keeping only the yumrepo_core fix

[miharp]

Reverts #63, #64, and #65. The tree is now identical to 0a7c5f8 apart from one Puppetfile line.

Why

This repo is a dev environment: an edit to production has to appear on the next agent run with no deploy step. codavox distributes sealed, immutable, content-addressed versions. Those models are structurally opposed, and everything added to reconcile them was paying for the mismatch:

• codavox-basedir/ was a directory of environments nested inside an environment, so the publisher had something other than the working tree to seal.
• The working tree cannot be sealed at all. .onceover/ holds rspec-puppet fixture symlinks pointing at absolute macOS host paths, which codavox rightly refuses to unpack — and it returns every time anyone runs onceover.
• The compiler could never serve production, because codavox replaces environmentpath rather than adding to it. Exercising it meant giving up the only node compiling against the primary.
• Static catalogs had to come off the primary — a real capability lost purely to the conflict.

The compiler VM goes too. Without codavox it had no code — no synced mount, stock empty production skeleton — so role::compiler installed openvox-server on a node that could only compile empty catalogs. codavox was the only thing that ever fed it.

codavox validation moves to a control repo built for it, where r10k deploys a clean tree and static catalogs stay on.

What's kept, and why only this

puppetlabs/yumrepo_core — the one change in that range with nothing to do with codavox.

yumrepo left Puppet core. site-modules/profile/.fixtures.yml already declared it for the module's own specs, but the control repo never shipped it, so onceover could not compile any RedHat role:

Evaluation Error: Unknown resource type: 'yumrepo'
  file: site-modules/profile/manifests/base.pp  line: 53
  factsets: puppet.example.com, compiler.example.com, agent01.example.com

Real nodes were unaffected because openvox-agent bundles it, which is why it went unnoticed. I confirmed it was pre-existing by stashing and reproducing the identical four failures on a clean tree.

The two other things I'd called fixes are gone with their subjects, correctly: the site.pp compiler classification has no compiler to classify, and codavox::package_source has no codavox to install.

pp_role in csr_attributes.yaml also goes, since it arrived with #63 — 0a7c5f8 never had it. Worth re-adding on its own merits later if you want role-based auth; it isn't a codavox dependency.

Verified

• onceover passes all four remaining roles (role::puppet_master, role::database_server, role::webserver, role::example)
• profile suite back to 96 examples, 0 failures
• git diff --stat 0a7c5f8 is exactly Puppetfile | 6 ++++++

Note

The running VMs still have codavox installed from testing — package, /etc/codavox, /opt/puppetlabs/codavox, and the publisher unit on puppet. Puppet only removes what it manages, so unmanaging it leaves it in place. Simplest cleanup is vagrant destroy && vagrant up, which also drops the compiler VM.

🤖 Generated with Claude Code