[HN Gopher] The first release of OpenVox, the OSS implementation...
___________________________________________________________________
The first release of OpenVox, the OSS implementation of Puppet
Author : mooreds
Score : 69 points
Date : 2025-01-22 02:47 UTC (20 hours ago)
(HTM) web link (overlookinfratech.com)
(TXT) w3m dump (overlookinfratech.com)
| ValtteriL wrote:
| What's the story behind the name OpenVox? Hard to draw relation
| to Puppet from it.
| scarby2 wrote:
| Vox pupuli is a long running puppet related thing
| cbm-vic-20 wrote:
| Seems like the pupuli part is more relevant than the vox
| part.
| yjftsjthsd-h wrote:
| Per https://voxpupuli.org/openvox/ , this is a community fork of
| Puppet (the tool like ansible/chef/salt), not Puppet (the browser
| automation tool). In case anyone else was confused too.
| leosanchez wrote:
| > not Puppet (the browser automation tool)
|
| Puppet or Puppeteer ?
| ofrzeta wrote:
| I just wanted to comment that there is no browser automation
| tool called Puppet when I found out there's a scraper thing
| that allows entering natural language description for the
| task (probably using LLM and Puppeteer under the hood). Given
| that this is quite obscure I guess they indeed mixed it up
| with Puppeteer.
| NewJazz wrote:
| 1. I didn't realize puppet was open core.
|
| 2. OpenVox sounds like a text to speech engine.
|
| 3. What is the main use case of Puppet / OpenVox in 2025? Same as
| always? Isn't CM a lot less relevant in the age of platforms like
| Flatcar and Bottlerocket?
|
| 4. Why fork puppet instead of contributing to ansible or salt?
| haddonist wrote:
| Configuration Management of one form or another is a way to
| ensure consistency across a fleet of servers, and reduce
| administration overhead. VMs aren't going away any time soon,
| despite SaaS companies best efforts.
|
| Companies with 100s to 1000s of hours of investment in software
| like Puppet aren't going to rearchitect without being forced
| to. By the application becoming unsuitable for current needs,
| or due to cost.
|
| Broadcom bought out VMWare and jacked the price up by
| unworkable amounts. Puppet is now owned by a venture capital
| company and the non-zero possibility is they'll follow
| Broadcom's playbook. That's why Puppet is being forked.
|
| Why not contribute to Ansible or Salt? What individual
| programmers do in their spare time is irrelevant to the
| majority of users of those products.
| NewJazz wrote:
| VMs can be run as immutable prebaked images, with no
| configuration management needed. They may not be going away,
| but the way the tech is used is changing.
| ghaering wrote:
| Yeah, I have used that approach since around 2015. In order
| to create these prebaked images, you will usually want to
| use a CM tool anyway, though.
| baobun wrote:
| Sure. And some of us may want or need to do live changes at
| runtime across the fleet without needing a full rebuild and
| redeploy. It can certainly be more green. It's fine if you
| find it useful to be dogmatic and consistent but don't
| expect that to be the right approach everywhere or for
| everyone.
|
| CM is useful here. And usually in the bootstrapping of such
| architectures.
| oefrha wrote:
| Puppet is owned by Perforce which is owned by private equity,
| not venture capital, and worse than venture capital.
| nunez wrote:
| Salt is owned by VMware; I would think twice before using it
| given their situation.
| GuestFAUniverse wrote:
| I've used both. Ansible is abysmally slow compared to puppet.
| Loosing puppet would be bad -- I don't want to go back to
| ansible (I used it from the beginning, when Michel DeHaan was
| still onboard. I don't like the crude mixture of programming
| language and YAML it became)
| bane wrote:
| > OpenVox sounds like a text to speech engine.
|
| "There are 2 hard problems in computer science: cache
| invalidation, naming things, and off-by-1 errors."
|
| The names of things today is terrible. If I hadn't known what
| Puppet was, even vaguely, I would have thought this was some
| kind of speech recognition or TTS project as well. This may as
| well be called "FileDefrag" or "OpenSec".
| mrweasel wrote:
| > 4. Why fork puppet instead of contributing to ansible or
| salt?
|
| Puppet and Ansible (not sure about Salt) works very
| differently. Puppet is pull based, as in each client pulls
| their configuration from a central server at regular intervals,
| where as Ansible pushes a configuration when asked. Puppet is
| also more of a "Ensure that my client is in this state" while
| Ansible can be see as "Run these steps on the client", that's
| not a 100% accurate and people have also made Ansible work in a
| pull configuration, but I feel that makes picking one over the
| other a little simpler.
|
| In any case, Puppet is easier to scale to thousands of servers.
| Ansible is easier to develop for and easier to upgrade or run
| multiple versions simultaneously. It two different approaches
| to the same/similar problem, but they are fare from
| interchangeable.
| mdaniel wrote:
| I am glad you at least mentioned ansible-pull[1] since it's
| just _common_ to use push based setups, but not the only way.
| I don 't know exactly how puppet thinks of these things but
| ansible-pull is also still agentless (meaning one does not
| need to register the managed machine a priori). I also
| especially like "--only-if-changed"
| <https://docs.ansible.com/ansible/11/cli/ansible-
| pull.html#cm...> which can keep keeps the journalctl noise
| down if that option is appropriate to your setup
|
| 1: https://docs.ansible.com/ansible/11/cli/ansible-pull.html
| 0cf8612b2e1e wrote:
| > Puppet is easier to scale to thousands of servers
|
| I would have expected the opposite. Pushing changes as
| required seems easier when the head node is the only one with
| smarts deciding on what happens next. Unless Ansible has some
| hard cap on how many servers it can direct in parallel?
| everforward wrote:
| The head node has to do all the processing of what changes
| to make, for each server it runs against. Pull based
| systems have the destination server do that, making them
| scale horizontally natively.
|
| Presuming there's no need for orchestration between nodes
| (which pull-based configs make very hard/impossible), pull-
| based systems parallelize perfectly where push-based
| systems cannot parallelize.
|
| SSH is also very slow as far as these things go. At some
| point the head node just gets saturated on doing SSH
| encryption or the NIC.
| 20after4 wrote:
| Puppet is actually a very competent infrastructure-as-code
| tool. I never liked the typical architecture where you run a
| few central puppetmaster nodes with hundreds or thousands of
| puppet agents all syncing to that...
|
| There are other ways to use the tool, however. In contrast with
| a centralized infrastructure, it's also possible to just
| collect a few puppet manifests in git, then you simply clone
| the repo and run `puppet apply` on demand.
|
| Puppet is still a powerful language for declarative
| representation of system configuration. Works to apply a
| specific configuration at a specific time or as a way to
| automate the construction of VM images.
|
| One place puppet excels is when you want to reuse a bit of
| configuration in bare metal, virtual machine or container
| images. With puppet you can pretty easily generate all three
| from one source of truth with minimal special-cases for the
| config variants.
|
| All that being said, I haven't reached for puppet as my first
| choice tool in quite some time. Maybe time to change that and
| give OpenVox a look. It'll be a win if OpenVox saves me from
| further suffering through the indignity of working with
| Ansible.
| denkmoon wrote:
| I'm looking to introduce CM to my homelab, anyone got some good
| arguments why I should look at puppet/openvox instead of ansible?
| bionsystem wrote:
| Both are solid and will do the job.
|
| Ansible is a little bit easier to get started for a few reason
| (yaml instead of a DSL, ssh only...) ; it's also mostly tasks
| running through SSH which may feel a bit more "natural" when
| you are configuring machines initially.
|
| In terms of idempotency I find it is easier in ansible to mess
| up something but if you are careful they are on par. I've used
| mostly ansible over the past few years in various jobs but the
| first I got in touch with ~10 years ago was puppet and it felt
| very solid especially for heterogeneous environments (we had
| different archs and OSes to manage). Also puppet scales very
| well because it has agents as well as many tools to manage
| large infrastructures which I tried and were already quite
| convenient 10 years ago.
|
| TL;DR probably use ansible unless you have a very specific use
| case.
| danmur wrote:
| The DSL (and associated IDE support) is about the only thing
| I like about puppet
| mdaniel wrote:
| I am a pretty big proponent of ansible but I have given
| grave consideration to making a fork that uses Skylark
| instead of yaml because the "what can I type here?" story
| is terrible as is. Most of the jinja expressions are
| already basically python so it seems like a natural fit
| dark-star wrote:
| Ansible works best when you only have Linux/BSD systems to
| manage, due to its heritage and doing everything through SSH.
|
| If you have other systems to manage, like Windows or VMware ESX
| etc., it feels like a kludge with the delegation to localhost
| to get to the plugins.
|
| Also, it can be tricky to use if your Linux systems have
| different Python interpreter versions because it's not at all
| straightforward to override the python interpreter used.
|
| Looping constructs and sub-tasks etc. are also awkward to use,
| and the initial setup for a small automation project might be
| overwhelming for newcomers.
|
| On the other hand you get a massive community with plugins for
| almost every conceivable system/OS, so that's definitely a huge
| plus
| mdaniel wrote:
| > and doing everything through SSH.
|
| For sure not everything, I get a lot of mileage out of using
| SSM into ec2 hosts which doesn't even have Internet facing
| addresses
|
| I am thankful that I've never had to manage Windows but I
| don't believe they're managed as localhost since if nothing
| else ansible doesn't offer control node execution on Windows
| tzmudzin wrote:
| You may want to consider NixOS as yet another option.
| denkmoon wrote:
| Ha, I gave it a red hot go. I'm too dumb for NixOS sadly.
| wink wrote:
| I've repeatedly tried to make Puppet work for "small"
| installations, be it a single dev laptop, our fleet of default
| base VMs (before containers were a thing), or home use. You
| couldn't really do anything without community packages, and
| their update rate was kinda meh. A lot of churn.
|
| Puppet always seemed to me like a scalable enterprise solution,
| but you either need a team to keep it in check, or just never
| update.
|
| I'm not specifically recommending Ansible, but it's what I've
| been using for a couple years, and I would always recommend
| that for home use over Puppet.
|
| Disclaimer: I last used Puppet in 2017, but for like 7 years
| extensively before that and everything I mentioned happened
| several times.
|
| Second disclaimer: By now I think parametrizing everything is a
| huge mistake - the real worth is editing the config in one
| place and having it in SCM. if you only parametrize 2 lines out
| of a 100 line config file and basically copy it over with 2x
| `sed` - that's fine.
| baobun wrote:
| Word of advice: Whatever you use, try to be relatively
| consistent with commiting your changes. A traversable git
| history and clean enough state to keep track of what's fresh
| can be super helpful especially when troubleshooting or coming
| back after messing around with whatever.
|
| And never commit inline secrets. Find out one of the ways to
| inject/separate/template secrets that's workable for you to
| stick with it.
| mrweasel wrote:
| For home use definitively recommend Ansible. I've used/uses
| both and for a handful of servers/VM and for a single
| administrator I'd always pick Ansible. Realistically what you
| want is just a tool that store a configuration in some VCS and
| an a why to apply that configuration quickly.
|
| Ansible will allow you to do that with just "pip install
| ansible". Puppet requires you to setup so infrastructure, which
| you need to way of bootstrapping.
|
| Personally I also find Ansible easier to work with, in the
| sense that you can more easily do stuff in small increments.
| Upgrading Ansible is also a lot simpler. Puppet really cool and
| powerful, but for home stuff or a small business I'm not sure
| the overhead of managing Puppet itself is worth it.
| pnutjam wrote:
| Puppet is a project to implement. Once it's implemented, it's
| great. It requires dedicated infrastructure to work properly.
| Ansible is much easier to step into slowly if you don't have
| time to implement a full deployment project before you can
| use it. You can start without dedicated infrastructure and
| add later if you want more centralized management.
| mdaniel wrote:
| https://github.com/ansible/awx#readme is also helpful if
| one needs "runbook" behavior to allow arbitrary audiences
| to run playbooks without the headache of installing
| something and dealing with local cred management.
| Interestingly, it also offers a "callback" system to allow
| machines to _request_ a playbook upon themselves in cases
| where ansible-pull isn 't appropriate/helpful
| sliken wrote:
| Step #1 keep your CM files in Git.
|
| My favorite part of puppet is demonstrated well by the
| trifects: package { 'openssh-server':
| ensure => installed, } file {
| '/etc/ssh/sshd_config': source =>
| 'puppet:///modules/sshd/sshd_config', owner =>
| 'root', group => 'root', mode => '0640',
| notify => Service['sshd'], # sshd restarts whenever you edit
| this file. require => Package['openssh-server'],
| } service { 'sshd': ensure => running,
| enable => true, }
|
| That will keep SSH installed, a service running, and the puppet
| config file managed forever. If you accidentally replace the
| config file it will be fixed and the service restarted. If you
| remove the package it will be reinstalled, config file updated,
| and service started.
|
| Not a fan of ansible, it's more of a "run this playbook", which
| translates to reinstall and "run this playbook", which in
| environments that don't reinstall very often can be painful.
| Since ansible playbooks don't know the current machines state
| they never know exactly what commands to run.
|
| Generally if you spin up containers or similar short term
| servers I think ansible is fine. If it's a larger and more
| complicated environment with longer lived servers I'd use
| puppet.
|
| Oh, one other think I like about puppet is if you say apply X
| to all nodes, you can literally not run puppet (it will fail to
| compile the manifests) if you try to override it. Which
| security auditors _LOVE_.
| isThereClarity wrote:
| I am a user of puppet and have used many of the community puppet
| modules developed under the Vox Pupuli group ( They have 175
| modules on puppet forge: https://forge.puppet.com/modules/puppet
| ). Looks like I've missed the news and they're (soft) forking
| puppet as OpenVox; does the following appear right?
|
| Summary of what I can find: It seems Perforce have announced they
| will stop providing open source puppet's public binaries and the
| public package repositories. Private access to their binaries
| will require either developer license (with one of the limits
| being 25 nodes) or a commercial license. Secondly, they are
| reducing public source code contributions to Puppet. A response
| to this by Overlook InfraTech / Vox Pupuli has resulted in a fork
| called OpenVox.
|
| Regarding the first issue, Perforce's halt to providing open
| source puppet's public binaries / package repos: Posted on the
| "Puppet By Perforce" blog 2024-11-07
| https://www.puppet.com/blog/open-source-puppet-updates-2025
|
| > In early 2025, Puppet will begin to ship any new binaries and
| packages developed by our team to a private, hardened, and
| controlled location.
|
| > Community contributors will have free access to this private
| repo under the terms of an End-User License Agreement (EULA) for
| development use. There will be no license changes for the open
| source version of Puppet.
|
| This is backed up by nightlies suspended from 2024-11-06
| https://nightlies.puppet.com/apt/dists/index.html . From the blog
| post, it would appear that access to binaries is only going to be
| free for 25 nodes.
|
| > The new development license is an EULA that allows developers
| free access to our hardened Puppet releases (up to 25 nodes).
| Capacities higher than 25 nodes will require a Puppet Labs
| Support Commercial License.
|
| > Community developers will continue to have access to binaries
| and packages for development purposes under a new developer
| license (EULA).
|
| Releases prior to the annoucement appear available, but there is
| no statement suggesting that will remain in the blog post. I have
| a few dozen physicals and a few dozen VMs running puppet but
| don't have a commercial license, so this will impact me.
|
| Regarding the second issue, reducing public source code
| contributions to Puppet, there is this from the same blog post:
|
| > We will release hardened Puppet releases to a new location and
| will slow down the frequency of commits of source code to public
| repositories.
|
| Regarding the community response, it seemed to start with
| providing community packages and has become the "soft fork"? From
| https://voxpupuli.org/openvox/
|
| > OpenVox started life as a Puppet(tm) mirror by Overlook
| InfraTech to continue providing community packages when Perforce
| discontinued public packaging efforts in late Fall of 2024. It
| soon became clear that they were also moving all further
| Puppet(tm) development to internal forks and ceasing development
| on open source Puppet(tm). A community fork using Overlook
| InfraTech's packaging pipeline was the inevitable response.
|
| > We consider OpenVox a soft-fork because we intend to maintain
| downstream compatibility for as long as we are able. As such,
| we've created a Puppet(tm) Standards Steering Committee to set
| the direction of features and language evolutions and have
| invited Perforce to participate.
___________________________________________________________________
(page generated 2025-01-22 23:03 UTC)