No Description

Steven Jacobs d7732932ad add best practices snippet for inspiration 1 year ago
saltstack 1c98bc5f96 init repo 1 year ago
Jenkinsfile 7e9cf10c91 set home environment variable to current dir 1 year ago
README.md d7732932ad add best practices snippet for inspiration 1 year ago
docker-compose.yml 3c36911b82 init devtools 1 year ago
go.mod 1c98bc5f96 init repo 1 year ago
queryfile 325cc25371 fix wheel rpc call 1 year 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.