IMHO the only advantage of a master/agent pull architecture is that it can be used in a firewalled network when( the actual configuration is located outside that network) without opening up holes in the firewall, while the push architecture cannot.

In terms of flexibility, I think the most important issue is the minimal setup required on a node to become remotely manageable. Once this requirement is met both architectures can handle updates. A master/agent architecture needs the agent installed, configured and running. On one hand Puppet and Chef aren't (yet) by default installed on most systems, while sshd (needed by Ansible) is. On the other hand even Ansible needs sshd running and credentials configured on the node to be accessible, so I'd say there's not much of a difference from this perspective - especially if the minimal setup is achieved via customized system images.

In terms of scalability, I'd consider the master/agent architecture less scalable (but just a bit):

• if the master attempts to actively keep a live system state (i.e. the map of all the agents and their states) that would chew up some time/resources. Without a master, Ansible isn't susceptible to such scalability issue. Granted, even master/agent architectures can offer a scalable approach to providing an overall system state similar to Ansible's (and probably they all do nowadays).

• in the old days, when the master would actually drive the agent configuration tasks (as mentioned in the post you referenced in your answer), the scalability of such architecture could suffer a lot. But this is not a big deal anymore since for all the tools mentioned in your question the configuration is just transferred to the local node which then performs the tasks.

• when it comes to transferring the configs to the local nodes, a pull architecture is limited only by the capacity of serving those configurations (common to both architectures), but a master/agent one needs to also run the logic driving transfers and actually making the transfers, if applicable (it's possible to just instruct the agents to pull their own configs), which limits how fast the master can propagate configs to a large number of agents.

IMHO the only advantage of a master/agent pull architecture is that it can be used in a firewalled network (when the actual configuration is located outside that network) without opening up holes in the firewall, while the push architecture cannot.

In terms of flexibility, I think the most important issue is the minimal setup required on a node to become remotely manageable. Once this requirement is met both architectures can handle updates. A master/agent architecture needs the agent installed, configured and running. On one hand Puppet and Chef aren't (yet) by default installed on most systems, while sshd (needed by Ansible) is. On the other hand even Ansible needs sshd running and credentials configured on the node to be accessible, so I'd say there's not much of a difference from this perspective - especially if the minimal setup is achieved via customized system images.

In terms of scalability, I'd consider the master/agent architecture less scalable (but just a bit):

• if the master attempts to actively keep a live system state (i.e. the map of all the agents and their states) that would chew up some time/resources. Without a master, Ansible isn't susceptible to such scalability issue. Granted, even master/agent architectures can offer a scalable approach to providing an overall system state similar to Ansible's (and probably they all do nowadays).

• in the old days, when the master would actually drive the agent configuration tasks (as mentioned in the post you referenced in your answer), the scalability of such architecture could suffer a lot. But this is not a big deal anymore since for all the tools mentioned in your question the configuration is just transferred to the local node which then performs the tasks.

• when it comes to transferring the configs to the local nodes, a pull architecture is limited only by the capacity of serving those configurations (common to both architectures), but a master/agent one needs to also run the logic driving transfers and actually making the transfers, if applicable (it's possible to just instruct the agents to pull their own configs), which limits how fast the master can propagate configs to a large number of agents.