4 ms·

Last time I checked, ansible playbooks were also essentially just sequential steps to execute via ssh, albeit in yaml format. There was certainly no way to desc

by matrss 3y ago

Last time I checked, ansible playbooks were also essentially just sequential steps to execute via ssh, albeit in yaml format. There was certainly no way to describe a desired state nor did ansible accomplish consistently bringing a system into some desired state. Two executions of the same playbook could result in a very different system state for example, depending on what happened in between. The only systems I am aware of which are reliably capable of "solving for desired state" are nix and guix.

eigenvalue 3y ago
Ansible is definitely all about solving from a specified target state and ensuring that it is followed. It’s even at the level of syntax for ansible, which is how it can be used totally declaratively. And if you stick to the native idiomatic ansible way of doing everything (as opposed to doing hacky stuff with ad hoc shell commmands), you get automatic idempotence and other nice stuff “for free”.
- matrss 3y ago
  So, the last time I used ansible, which was quite a while ago to be fair, there was a builtin way to install packages with apt on the target system. You could add packages to a list to be installed and that would work. But removing them from that "declared state" would not remove them on the target system on the next playbook run. You would have to add an explicit uninstall command. And that is where ansible failed to be declarative. Did that change in the meantime? Ansible might provide idempotence for the builtin things (although I would argue it doesn't, at least not on a bit-by-bit level, since you can't pin down specific versions of package repositories and stuff like that), but to be declarative it would need to provide a 1-to-1 mapping from declared state to running system state. And if what I described above is still the case, then it simply does not do that. In my experience, ansible tries to build a declarative interface to an imperative mode of system management, which works to some extent, but breaks down in more complex cases because building this declarative interface can only be a leaky abstraction without the right foundation.
xorcist 3y ago
You can run sequential commands with ansible, but then you're just using it as a replacement for "ssh $host < script.sh". You would be missing out on most of the usefulness of the tool. It's meant to be used declaratively. The manual describes it quite well. In the same type of tools are puppet and indeed nix, but with one important difference for the latter: nix is also a package manager, which allows for more a fine grained state specification.
- matrss 3y ago
  True, nix is also a package manager, and that is the crucial step necessary to actually provide a declarative interface to system state. Without it you can only get the leaky abstraction that is ansible. To illustrate my point, imagine this playbook: --- - name: Bring system into some state hosts: localhost tasks: - name: Install hello ansible.builtin.apt: name: hello become: true Apply it and you get GNU hello installed. Now remove the package installation step, which really is just a glorified "ssh $host < script.sh": --- - name: Bring system into some state hosts: localhost tasks: Apply that and you will still have hello installed, even though it was removed from the "declared state". This just pretends to be declarative but really isn't, the tasks are still imperative steps. Not to blame ansible for this, it is just that ansible is build on a foundation that inherently makes declarative system management impossible to begin with and ansible is more or less the best thing you could do given the constraints.

by matrss 3y ago

eigenvalue 3y ago

Ansible is definitely all about solving from a specified target state and ensuring that it is followed. It’s even at the level of syntax for ansible, which is how it can be used totally declaratively. And if you stick to the native idiomatic ansible way of doing everything (as opposed to doing hacky stuff with ad hoc shell commmands), you get automatic idempotence and other nice stuff “for free”.

matrss 3y ago
So, the last time I used ansible, which was quite a while ago to be fair, there was a builtin way to install packages with apt on the target system. You could add packages to a list to be installed and that would work. But removing them from that "declared state" would not remove them on the target system on the next playbook run. You would have to add an explicit uninstall command. And that is where ansible failed to be declarative. Did that change in the meantime? Ansible might provide idempotence for the builtin things (although I would argue it doesn't, at least not on a bit-by-bit level, since you can't pin down specific versions of package repositories and stuff like that), but to be declarative it would need to provide a 1-to-1 mapping from declared state to running system state. And if what I described above is still the case, then it simply does not do that. In my experience, ansible tries to build a declarative interface to an imperative mode of system management, which works to some extent, but breaks down in more complex cases because building this declarative interface can only be a leaky abstraction without the right foundation.

xorcist 3y ago

You can run sequential commands with ansible, but then you're just using it as a replacement for "ssh $host < script.sh". You would be missing out on most of the usefulness of the tool. It's meant to be used declaratively. The manual describes it quite well. In the same type of tools are puppet and indeed nix, but with one important difference for the latter: nix is also a package manager, which allows for more a fine grained state specification.

matrss 3y ago
True, nix is also a package manager, and that is the crucial step necessary to actually provide a declarative interface to system state. Without it you can only get the leaky abstraction that is ansible. To illustrate my point, imagine this playbook: --- - name: Bring system into some state hosts: localhost tasks: - name: Install hello ansible.builtin.apt: name: hello become: true Apply it and you get GNU hello installed. Now remove the package installation step, which really is just a glorified "ssh $host < script.sh": --- - name: Bring system into some state hosts: localhost tasks: Apply that and you will still have hello installed, even though it was removed from the "declared state". This just pretends to be declarative but really isn't, the tasks are still imperative steps. Not to blame ansible for this, it is just that ansible is build on a foundation that inherently makes declarative system management impossible to begin with and ansible is more or less the best thing you could do given the constraints.