4 ms·

First time I heard about CFEngine in ~2004. Version of that time didn't impress me. However CFEngine3 is a totally different story. I have been using it since 2

by betaby 3y ago

First time I heard about CFEngine in ~2004. Version of that time didn't impress me. However CFEngine3 is a totally different story. I have been using it since 2012 and have not plans to switch. Even though CFEngine is not the most popular one it's one of the subjectively 'best'. Agent-less or kind-of-agent-less options like Ansible are not good enough feature-wise. Chef and Puppet are less convenient to me because of dependency on ruby.

NewJazz 3y ago
Have you used Salt? I've heard very good things about it, and it is an agent-based tool. I'm curious how it compares.
- chronid 3y ago
  Salt is unfortunately (in my two year old experience) full of features and strange bugs related to them - I do remember encountering a bunch of memory leaks master side for example. Deployment had the classic issues of python applications. The core was (mostly) solid, but if you need anything done on it do buy the time of some consultant working on it already. It's not as accessible as ansible, but definitely more accessible than cfengine. At least coming from Ansible.
- anonacct37 3y ago
  I used it and even took a class taught by salt stack employees. I really was not a fan. I think one of the core problems I ran into was that the tool attempted to layer on rpc behavior to what was fundamentally a broadcast. So you'd apply something to everything with a web role. The tool would attempt to make it appear as if you executed apply on n nodes and return after n responses. But since this was all just a broadcast what really happened is the tool dropped a message on the bus and then guessed how many responses it would get. If it guessed wrong the cli invocation would just hang.
- everforward 3y ago
  I used Salt ~5 years ago, so things may have changed, but I wasn't impressed. In theory, it is an immensely powerful system. The broadcast system offers ways to orchestrate things in a way that's hard with eg Ansible. The reality was that it was unstable, and use cases that needed the broadcast system were rare and often contrived. Agents crashed or hung constantly. We ended up mostly using the same features Ansible already had. I might PoC it if I was going to deploy at a scale large enough where Ansible being centralized was an issue (i.e. there are so many hosts that it takes hours for Ansible to run). I'd have to see whether the pain of managing agents was better or worse than trying to shard Ansible. My suspicion is that it isn't too hard to shard Ansible deployments, but I could well be wrong, I haven't tried.

by betaby 3y ago

NewJazz 3y ago

Have you used Salt? I've heard very good things about it, and it is an agent-based tool. I'm curious how it compares.

chronid 3y ago
Salt is unfortunately (in my two year old experience) full of features and strange bugs related to them - I do remember encountering a bunch of memory leaks master side for example. Deployment had the classic issues of python applications. The core was (mostly) solid, but if you need anything done on it do buy the time of some consultant working on it already. It's not as accessible as ansible, but definitely more accessible than cfengine. At least coming from Ansible.
anonacct37 3y ago
I used it and even took a class taught by salt stack employees. I really was not a fan. I think one of the core problems I ran into was that the tool attempted to layer on rpc behavior to what was fundamentally a broadcast. So you'd apply something to everything with a web role. The tool would attempt to make it appear as if you executed apply on n nodes and return after n responses. But since this was all just a broadcast what really happened is the tool dropped a message on the bus and then guessed how many responses it would get. If it guessed wrong the cli invocation would just hang.
everforward 3y ago
I used Salt ~5 years ago, so things may have changed, but I wasn't impressed. In theory, it is an immensely powerful system. The broadcast system offers ways to orchestrate things in a way that's hard with eg Ansible. The reality was that it was unstable, and use cases that needed the broadcast system were rare and often contrived. Agents crashed or hung constantly. We ended up mostly using the same features Ansible already had. I might PoC it if I was going to deploy at a scale large enough where Ansible being centralized was an issue (i.e. there are so many hosts that it takes hours for Ansible to run). I'd have to see whether the pain of managing agents was better or worse than trying to shard Ansible. My suspicion is that it isn't too hard to shard Ansible deployments, but I could well be wrong, I haven't tried.