[haddonist]

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.

[oefrha]

Puppet is owned by Perforce which is owned by private equity, not venture capital, and worse than venture capital.

[nunez]

Salt is owned by VMware; I would think twice before using it given their situation.

[NewJazz]

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.

[citrin_ru]

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.

[baobun]

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]

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]

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?

[ghaering]

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.

[GuestFAUniverse]

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]

Salt is a pull based model like puppet, fwiw.