Two speculative ideas, both explicitly out of scope for now - "depositing" them here per direct request so they're not lost, not proposing either as committed work.
1. buildbox: packer vs. Dockerfile-based image building
Explore using Packer or a Dockerfile, with Podman or Docker, to build actual artifacts/images rather than just provisioning a running VM in place. This would need real image-building plus a registry to push to, which is meaningfully more infrastructure than the rest of configbox needs (see #21/#23's own "Rejected" sections - chef_client/puppet_server/similar were rejected specifically for requiring more than simple package installation). If pursued, this would live in its own buildbox area, separate from configbox.
2. consul-template - dynamic configuration from a local dev Consul
Reference: hashicorp/consul-template, Consul-Template docs.
Idea: a local dev Consul instance (not a robust production client-server setup - explicitly out of scope) storing key-values that get fetched dynamically and used to drive configuration - e.g. an ansible-consul-dynamic-playbook, a puppet-enc-consul (custom ENC backed by Consul), or reusing the existing hiera-consul project rather than writing one from scratch. Would use the shell provisioner and run external to Vagrant's own built-in provisioners. Possibly its own configuration group on par with ansible/puppet/etc., rather than a variant of an existing one - undecided.
Explicitly flagged with self-doubt in the original brainstorm: "If this can be used, maybe it is not appropriate" - worth a real feasibility pass before committing to it as a tracked tool, not just building it because the pieces exist.
Out of scope for now
Both ideas - this issue exists to record them, not to schedule them.
Two speculative ideas, both explicitly out of scope for now - "depositing" them here per direct request so they're not lost, not proposing either as committed work.
1. buildbox: packer vs. Dockerfile-based image building
Explore using Packer or a Dockerfile, with Podman or Docker, to build actual artifacts/images rather than just provisioning a running VM in place. This would need real image-building plus a registry to push to, which is meaningfully more infrastructure than the rest of configbox needs (see #21/#23's own "Rejected" sections -
chef_client/puppet_server/similar were rejected specifically for requiring more than simple package installation). If pursued, this would live in its ownbuildboxarea, separate fromconfigbox.2. consul-template - dynamic configuration from a local dev Consul
Reference: hashicorp/consul-template, Consul-Template docs.
Idea: a local dev Consul instance (not a robust production client-server setup - explicitly out of scope) storing key-values that get fetched dynamically and used to drive configuration - e.g. an
ansible-consul-dynamic-playbook, apuppet-enc-consul(custom ENC backed by Consul), or reusing the existing hiera-consul project rather than writing one from scratch. Would use the shell provisioner and run external to Vagrant's own built-in provisioners. Possibly its own configuration group on par with ansible/puppet/etc., rather than a variant of an existing one - undecided.Explicitly flagged with self-doubt in the original brainstorm: "If this can be used, maybe it is not appropriate" - worth a real feasibility pass before committing to it as a tracked tool, not just building it because the pieces exist.
Out of scope for now
Both ideas - this issue exists to record them, not to schedule them.