It has a fast always-connected transport, is written in Python, and I've found pretty flexible, but it seems really really complicated if you look at the code and has probably hundreds of features you won't use.
So, having built some loosely msgpack-rpc based servers in the past, I wondered how quickly and how small I could build a functional prototype of something that works somewhat like Saltstack, but is easier to bootstrap, and very little code. Also, I'm kinda torn on yaml, I'd rather just write python, and I prefer Mako over Jinja2 (again, I already know python).
So this is a whack at that - self-contained single script client/server over tls deployment system with a built-in file server. It's more or less a toy, but I might continue to flesh it out and use it on some personal projects.
Comments welcome - the code is not really documented, but it's small and some of the interesting stuff happens around places you find 'exec(...)' ;)
* please "set -e" and ideally "-euo pipefail" in shell scripts, because encountering an error and defaulting to "this is fine" is usually not going to produce good outcomes in a server automation suite: https://github.com/mattbillenstein/salty/blob/master/example...
* if this had an "else: return 1" equivalent, it wouldn't cause the salty.py to exit(0) on a misunderstood mode: https://github.com/mattbillenstein/salty/blob/master/salty.p...
* maybe this is my ignorance of saltstack, but is there no mechanism through which a sane python editor could help one know what verbs and params are available here? https://github.com/mattbillenstein/salty/blob/master/example...
For example, if those were "from salty import copy" a sane python editor could help in all kinds of ways, but with them just being implicit, the editor doesn't know and now I have to maintain a whole api in my head
Yeah, I usually 'set -eo pipefail' as a habit
In saltstack there are a bunch of docs, so you sorta have to find the correct state, look up params and whatnot - I think it may be worthwhile separating those things into another file just so folks can easily know what is available.
Noted re arg handling - should probably use argparse - I've only spent an afternoon on it, so if it becomes a real tool, I'll end up doing that.
Carrying over the Ansible concept of roles a little strange. Python already has several means of packaging code for re-use (functions, functions as values, packages, modules), and executing packaged code is obvious. Ansible has to do something like that because of YAML, but Python's solution seems strictly superior here.
I've always wanted an Ansible-like tool that used and embraced Python directly. Effectively a series of interfaces designed to work with each other, with various backends fulfilling them.
I want to be able to do something like
app_hosts = inventory.find(runs_application='app', env='production')
app_hosts.map(lambda host: host.services.stop('app'))
for h in app_hosts:
app_hosts.map(lambda host: host.services.start('app'))
So a given host in the metadata will say that it has roles X, Y, Z - and there is a separate runable thing for each of those to configure each host that wants them.
I sorta want the config language to be python while still looking like a very simple playbook - so there shouldn't be like classes, functions, etc. Just a script you run top to bottom like salt states or ansible playbooks.
From your example, this is a bit closer to what I think Fabric is: http://www.fabfile.org/