4 ms·

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 al

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 2y ago
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 2y ago
  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 2y ago
    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 2y ago
    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.
    - NewJazz 2y ago
      I don't know if I'd describe the approach as dogmatic so much as deterministic. Live patching is certainly faster than the alternative, but you have to make sure you e.g. restart services when the underlying libraries get updated, as one example. Otherwise a naive vulnerability scanner might see that the OS package for e.g. openssl is up to date, meanwhile the version loaded by nginx, which is now removed on disk, is vulnerable.
  - sliken 2y ago
    Er, and how to you make the images? Or a family of tweaked images for different use cases. The make sure security standards, access to centralized services, etc is working? Doesn't that just move where you need CM a bit?
  - citrin_ru 2y ago
    Configuration changes. With immutable image every time any parameter changes you have to rebuild and re-deploy image which looks like a waste of resources - to change even 1 byte you need to re-build and re-push an image (which could be a multi Gb one). Then restart a whole cluster which depending on the application can be either costly or disruptive (in case of long lived network connection, on in case if you have a database). And sometimes you need to change configuration parameters many times per day. What developers tend to do when forced to use immutable infra is to move configuration from on-disk files to RAM and query it using network API from a central system. The problem is that it makes systems less reliable. If a VM/server restarted it can practically always read a config form disk but if you service relies on an external system to get runtime configuration it would not work if this external system is down, overloaded, misconfigured, returns wrong config because of a bug e. t. c. And it does happen in practice even when system designers tell they configuration API is very reliable (in theory). After seeing such systems fail I like simple on-disk configs more and more.
- oefrha 2y ago
  Puppet is owned by Perforce which is owned by private equity, not venture capital, and worse than venture capital.
- nunez 2y ago
  Salt is owned by VMware; I would think twice before using it given their situation.
- GuestFAUniverse 2y ago
  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)
  - NewJazz 2y ago
    Salt is a pull based model like puppet, fwiw.
bane 2y ago
> 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 2y ago
> 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 2y ago
  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#cmdoption-ansible-pull-o 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 https://docs.ansible.com/ansible/11/cli/ansible-pull.html
- 0cf8612b2e1e 2y ago
  > 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 2y ago
    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 2y ago
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.
computer23 2y ago
> OpenVox sounds like a text to speech engine. Reminds me of the (bad) plot element from Star Trek: Picard where Picard's son became "Vox" and was able to control people on behalf of the Borg.

haddonist 2y ago

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 2y ago
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 2y ago
  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 2y ago
  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.
  - NewJazz 2y ago
    I don't know if I'd describe the approach as dogmatic so much as deterministic. Live patching is certainly faster than the alternative, but you have to make sure you e.g. restart services when the underlying libraries get updated, as one example. Otherwise a naive vulnerability scanner might see that the OS package for e.g. openssl is up to date, meanwhile the version loaded by nginx, which is now removed on disk, is vulnerable.
- sliken 2y ago
  Er, and how to you make the images? Or a family of tweaked images for different use cases. The make sure security standards, access to centralized services, etc is working? Doesn't that just move where you need CM a bit?
- citrin_ru 2y ago
  Configuration changes. With immutable image every time any parameter changes you have to rebuild and re-deploy image which looks like a waste of resources - to change even 1 byte you need to re-build and re-push an image (which could be a multi Gb one). Then restart a whole cluster which depending on the application can be either costly or disruptive (in case of long lived network connection, on in case if you have a database). And sometimes you need to change configuration parameters many times per day. What developers tend to do when forced to use immutable infra is to move configuration from on-disk files to RAM and query it using network API from a central system. The problem is that it makes systems less reliable. If a VM/server restarted it can practically always read a config form disk but if you service relies on an external system to get runtime configuration it would not work if this external system is down, overloaded, misconfigured, returns wrong config because of a bug e. t. c. And it does happen in practice even when system designers tell they configuration API is very reliable (in theory). After seeing such systems fail I like simple on-disk configs more and more.
oefrha 2y ago
Puppet is owned by Perforce which is owned by private equity, not venture capital, and worse than venture capital.
nunez 2y ago
Salt is owned by VMware; I would think twice before using it given their situation.
GuestFAUniverse 2y ago
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)
- NewJazz 2y ago
  Salt is a pull based model like puppet, fwiw.

bane 2y ago

> 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 2y ago

> 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 2y ago
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#cmdoption-ansible-pull-o 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 https://docs.ansible.com/ansible/11/cli/ansible-pull.html
0cf8612b2e1e 2y ago
> 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 2y ago
  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 2y ago

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.

computer23 2y ago

> OpenVox sounds like a text to speech engine. Reminds me of the (bad) plot element from Star Trek: Picard where Picard's son became "Vox" and was able to control people on behalf of the Borg.