No Description

Steven Jacobs 4533a4662c go mod tidy 1 month ago
saltstack b22e559ffa add current work in progress 1 month ago
Jenkinsfile 7e9cf10c91 set home environment variable to current dir 2 years ago
README.md d7732932ad add best practices snippet for inspiration 2 years ago
docker-compose.yml dd859e62eb start over with clean slate 1 month ago
go.mod 4533a4662c go mod tidy 1 month ago
go.sum 4533a4662c go mod tidy 1 month ago
queryfile a4b1585f27 update queryfile with docker compose v2 1 month ago

README.md

go-saltstack

Golang SaltStack API Bindings

Currently only supports SaltStack CherryPy netapi module.

Using

TODO

Testing

go test ./...

Development

There is a docker-compose.yml for a quick, easy, and insecure Salt Master and API listening on https://localhost:8000/.

There is queryfile for quick query experimentation and reference with pashky/restclient.el.

Design

Best Practices

Given the performance overhead and HTTP timeouts for long-running operations described above, the most effective and most scalable way to use both Salt and salt-api is to run commands asynchronously using the local_async, runner_async, and wheel_async clients.

Running asynchronous jobs results in being able to process 3x more commands per second for LocalClient and 17x more commands per second for RunnerClient, in addition to much less network traffic and memory requirements. Job returns can be fetched from Salt's job cache via the /jobs/<jid> endpoint, or they can be collected into a data store using Salt's Returner system.

The /events endpoint is specifically designed to handle long-running HTTP connections and it exposes Salt's event bus which includes job returns. Watching this endpoint first, then executing asynchronous Salt commands second, is the most lightweight and scalable way to use rest_cherrypy while still receiving job returns in real-time. But this requires clients that can properly handle the inherent asynchronicity of that workflow.