3 ms·

> If the stateless way would work better, these tools take over the cloud infrastructure space. The tools are not comparable in what they do.

m1keil 4y ago
In what way? All these tools are "DSLs to API calls with idempotency guards" engines. This is exactly what a stateless TF would be. They all been extended with DSLs that allowed them to manage resources in AWS and other cloud providers. These are in use but far cry away from popularity of tools such as Terraform, Cloudformation and others.
- Too 4y ago
  Ansible, despite its declarative syntax, is actually just running actions imperatively from top to bottom. Each tiny action itself may be idempotent but removing one action will not undo it on the server. Even within single modules, modifications only add and don’t remove. Consider apt install module, this just keeps installing listed packages but never removes any unlisted, unless you set parameters like apt autoclean, which nobody dares to do. Terraform defines and end-state and uses dependencies between resources to reach that state. Removing a resource from a tf file will remove it from the infra.
- outsomnia 4y ago
  From the article: Ansible, Puppet, etc. don’t have intermediate stores of the hosts’ configuration, but then again they are used for different things.
  - inferiorhuman 4y ago
    Last I checked Ansible can cache facts to a persistent store like a file.
    - InvertedRhodium 4y ago
      Puppet also has PuppetDB, which is functionally similar.
      - Rapzid 4y ago
        Chef too. VERY common to store state in Chef server to pass info between executions.
      - raffraffraff 4y ago
        I might be wrong here but I think Puppet DB is more like an eventually consistent database that stores the last known state of potentially thousands of machines that may not be reachable or even turned on. The use case is totally different. Puppet runs on each machine "in isolation", and before Puppet DB, the agent had no way to know about anything external to the local machine. It can be used while assembling the manifest that gets passed to a machine, but when the puppet agent actually runs on that machine it doesn't ask Puppet DB what state the local machine is in, it just looks directly at the resources because they're local - there's no performance penalty.

m1keil 4y ago

In what way? All these tools are "DSLs to API calls with idempotency guards" engines. This is exactly what a stateless TF would be. They all been extended with DSLs that allowed them to manage resources in AWS and other cloud providers. These are in use but far cry away from popularity of tools such as Terraform, Cloudformation and others.

Too 4y ago
Ansible, despite its declarative syntax, is actually just running actions imperatively from top to bottom. Each tiny action itself may be idempotent but removing one action will not undo it on the server. Even within single modules, modifications only add and don’t remove. Consider apt install module, this just keeps installing listed packages but never removes any unlisted, unless you set parameters like apt autoclean, which nobody dares to do. Terraform defines and end-state and uses dependencies between resources to reach that state. Removing a resource from a tf file will remove it from the infra.
outsomnia 4y ago
From the article: Ansible, Puppet, etc. don’t have intermediate stores of the hosts’ configuration, but then again they are used for different things.
- inferiorhuman 4y ago
  Last I checked Ansible can cache facts to a persistent store like a file.
  - InvertedRhodium 4y ago
    Puppet also has PuppetDB, which is functionally similar.
    - Rapzid 4y ago
      Chef too. VERY common to store state in Chef server to pass info between executions.
    - raffraffraff 4y ago
      I might be wrong here but I think Puppet DB is more like an eventually consistent database that stores the last known state of potentially thousands of machines that may not be reachable or even turned on. The use case is totally different. Puppet runs on each machine "in isolation", and before Puppet DB, the agent had no way to know about anything external to the local machine. It can be used while assembling the manifest that gets passed to a machine, but when the puppet agent actually runs on that machine it doesn't ask Puppet DB what state the local machine is in, it just looks directly at the resources because they're local - there's no performance penalty.