5 ms·

I think you can think of these tools on a spectrum from pull-based to push-based. I say spectrum, because many of them are in reality hybrid. Tools running agen

by sbt 13y ago

I think you can think of these tools on a spectrum from pull-based to push-based. I say spectrum, because many of them are in reality hybrid. Tools running agents are naturally pull-based, where as with push you don't necessarily need an agent (consider sand blasting ssh commands). CFEngine is by far the most pull-based tool as it is underpinned by a theory mandating this behavior. Puppet is pull-based but with more push, Chef is even more push based, and Ansible and Salt are (I guess) mostly push. In the end it depends on what is more practical for your situation. If you have a few machines, then more push will be practical, but the more machines you have, pull-based solutions scale better.

mpdehaan2 13y ago
Slight correction, ansible has a pull based mode, called ansible-pull, which simply scales with git. It's there if you want it! ansible-pull can also be easily deployed with regular ansible as well, if you want to do that, there's an example playbook. If you want solid reporting with pull mode, we're going to have a product release in the next month that has a cool callback based feature, where you get centralized reporting and nodes can still phone in any time and request configuration of themselves. Easy to bootstrap, it will just require a one-line wget to invoke a configuration request. I would not characterize SS as being push based in the same way, one of the things Ansible is really good at doing is orchestrating things "like an orchestra", so if you want to talk to the woodwinds, brass, percussion, and then go BACK to the woodwinds, you can. It's not simply saying this-than-that, etc. This enables things like the rolling update feature, and doing some pretty intricate multi-tier work. One of the major inspirations for Ansible was when I was building Func at Red Hat and wanting to build a multi-tier architecture management system. I still strongly believe you need a push based system for that, because you don't want to wait 30 minutes + 30 minutes + 30 minutes for all of those changes to stack up. Some other tools try to solve this by glueing layers on top, with Ansible, at least the intent is to build that in. So yeah, I think there are definitely times when you need both.
- sbt 13y ago
  Yes, I think you need both pull and push, the ratio depending on the situation at hand. A senior sysadmin once told me that he asked all incoming recruits about what this proportion generally should be. The answer: 1/6 (16.6%) push and 5/6 pull (83.3%). I found that answer slightly amusing as it seemed overly general. On the other hand, he felt very strongly about that point and was quite annoyed with juniors' natural inclination to use push by default when pull could practically be used.

by sbt 13y ago

mpdehaan2 13y ago

Slight correction, ansible has a pull based mode, called ansible-pull, which simply scales with git. It's there if you want it! ansible-pull can also be easily deployed with regular ansible as well, if you want to do that, there's an example playbook. If you want solid reporting with pull mode, we're going to have a product release in the next month that has a cool callback based feature, where you get centralized reporting and nodes can still phone in any time and request configuration of themselves. Easy to bootstrap, it will just require a one-line wget to invoke a configuration request. I would not characterize SS as being push based in the same way, one of the things Ansible is really good at doing is orchestrating things "like an orchestra", so if you want to talk to the woodwinds, brass, percussion, and then go BACK to the woodwinds, you can. It's not simply saying this-than-that, etc. This enables things like the rolling update feature, and doing some pretty intricate multi-tier work. One of the major inspirations for Ansible was when I was building Func at Red Hat and wanting to build a multi-tier architecture management system. I still strongly believe you need a push based system for that, because you don't want to wait 30 minutes + 30 minutes + 30 minutes for all of those changes to stack up. Some other tools try to solve this by glueing layers on top, with Ansible, at least the intent is to build that in. So yeah, I think there are definitely times when you need both.

sbt 13y ago
Yes, I think you need both pull and push, the ratio depending on the situation at hand. A senior sysadmin once told me that he asked all incoming recruits about what this proportion generally should be. The answer: 1/6 (16.6%) push and 5/6 pull (83.3%). I found that answer slightly amusing as it seemed overly general. On the other hand, he felt very strongly about that point and was quite annoyed with juniors' natural inclination to use push by default when pull could practically be used.