I encourage everyone to share your "splunk in 1kloc of Python" projects! Some of my own:
- https://github.com/rollcat/judo is Ansible without Python or YAML
- https://github.com/rollcat/zfs-autosnap manages rolling ZFS snapshots
I encourage everyone to share your "splunk in 1kloc of Python" projects! Some of my own:
- https://github.com/rollcat/judo is Ansible without Python or YAML
- https://github.com/rollcat/zfs-autosnap manages rolling ZFS snapshots
But people are actually being surprisingly nice and friendly! I guess people just really hate Splunk!
I hate this meme. It's as if cars, trains, and airplanes all use the same wheels. Or that wheels under my stove, my tiny filing dresser, and my shopping cart are all the same.
Oh yeah, re-inventing the wheel, what a stupid idea and something we obviously don't frequently do and for good reasons.
This meme is almost as bad as the horrible misquoted "premature optimisation is the root of all evil".
I'm currently using this for a small application to easily backup databases in docker containers.
Best things in life come through love and passion. Frustration can be a good motivator but don't let it guide you.
> I thought this would get a lot of hostile takes [...]
To be entirely honest with you, recognizing and praising the good parts is a lot easier than giving proper feedback on what needs to be improved;)
[0] https://github.com/olafal0/configinator
[1] https://github.com/olafal0/configinator/blob/0576a53970bcb4d...
[2] https://github.com/olafal0/configinator/blob/0576a53970bcb4d...
There's also a bunch of other purpose-built tiny utilities on that GitHub account: https://github.com/aaviator42?tab=repositories
The only systems I am aware of which are reliably capable of "solving for desired state" are nix and guix.
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.
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.
When I first created Judo, I envisioned some sort of a standard library as a sibling project, sort of an "executable rosetta stone" for Unix, where you could declaratively say things like "ensure this user exists", "ensure this package is installed".
In practice I found out it's fairly easy to just write your scripts to be idempotent. It was the secret "2. and do not overcomplicate things" step that most initially simple software seems to gradually forget about.
You would think. But no, there is lots of room to make it over complicated without the corresponding efforts to manage the complexity.