Assuming the following config for tsa: https://gist.github.com/blakethepatton/6d830d3dbd0e51400e6675b47a7c86aa
What would the expected response from the /get_config_v1/shaping.toml be? Would the daemon respond with an effectively empty file ie:
# Generated by tsa-daemon
# Number of entries: 0
Or would it be expected that the data contained within the toml files loaded in be also part of the response?
For reference, this is effectively following the docker-swarm example for deployment. With TSA running as its own service.
It is telling you the active automation actions, so until something triggers a rule you’ll have an empty set.
the tsa endpoints will return configuration overrides based on the rules that have triggered. If none have triggered, or those rules that have triggered have expired, then what it returns will be empty
(for whatever reason, discord didn’t show me Mikes prior message until I hit enter!)
Okay, thanks. Looking at the lua implementation, it looks like the tsa daemon receives post requests of logs (except for filtered out types) are there any example bodies that I could tweak slightly to trick tsa into activating on a rule?
that depends on the rules you have defined; you can just send in JsonLogRecord shaped data that matches those rules
Also, according to https://docs.kumomta.com/userguide/clustering/trafficshapingautomation/, you can have multiple tsa daemons, do those somehow talk to eachother or is the expectation to send the logs to all of the tsa daemons?
or you can define a really broad rule that matches everything
the tsa daemons do not talk to each other. You need to send the same data to all of the tsa nodes, so that they all see the same inputs and arrive at the same decisions
Deployment Architecture - KumoMTA Docs illustrates the relationships of the various components
Yeah, my bad that was the page I had been meaning to link to
And from what I’ve seen, it looks like the daemon is storing everything just in its own ram then, it’s not using redis for any persistence correct?
it uses a local sqlite database and local memory; there’s no state it shares with other nodes
Was perusing the rust implementation but I’ve never programmed in rust so I’m unfamiliar yet with how things get passed around.
Is that a in-memory sqlite database or is it in the filesystem? What I’m getting at is, if I were to deploy that as a stateful set, would there be a file worth keeping around between any reboots
yes, the tsa.db file is stored in the filesystem, see: configure_tsa_db_path - KumoMTA Docs
Fantastic!
(there’s some inconsistency with the name in the side bar, the title, and the actual name of the function. I believe that the example shown in tsa_init - KumoMTA Docs is accurate)