This is interesting. Is the tag mode an or match or an and match? Ie does “server,backend” in the example match those with both tags or either tag?
On my way to the 1.0.0 by implementing the automated test suite!
I'm not set on this, maybe I will add a simple parser for something like `(A|B)&(~C)`. What do you think ?
I don't know that a full parser for Boolean logic is necessary - even having a complimentary `-T` option that takes mandatory tag names might be enough.
I'm curious about the ability to upload stuff too. Right now I mostly use a tool I wrote in shell several years ago (unimaginatively called `remote-install.sh`) that basically tars up a directory (minus exclude rules), sends it to the remote host, untars it to a tmp dir, and then runs the specified command (via sudo if specified).
But it's very much a one-at-a-time process.
Meanwhile a deployment helper script I wrote is very much a multiple-at-once process, and so it's multiple background SSH processes.
I could see both of these likely being candidates for using tricorder.
One interesting thing I don't see on your roadmap would be some way to have per-host data sent (i.e. a way to perhaps set some args to a command/script on a per-host basis, or perhaps a way to define environment variables to set per-host, and the script invocation could reference those)... Maybe this is part of the 'send data' stage, and it just has the ability to substitute a few vars when determining what so send. So e.g. `--send-file "%id%.env" --send-file "script.sh --send-file "data.foo"` would interpolate the `%id%` substring with the target's ID from the TOML file, allowing to send a customised file per-host.. Anyway. Just a thought!
I'll add this feature to the roadmap then :)
> I don't know that a full parser for Boolean logic is necessary - even having a complimentary `-T` option that takes mandatory tag names might be enough.
I truly dislike command lines with hundreds of arguments. IMHO, A boolean logic would be clearer on the intent than a combination of -t -T -not-T etc...
> so it's multiple background SSH processes.
I'm not sure yet if parallelization should be the default or not. Also I've not yet learned Tokio and Async programming in Rust :P
> some way to have per-host data sent
Yes, just like Ansible evaluates very variable per host. At the moment you can do it manually:
res=$(tricorder -i inventory -- echo "available")
host_ids=$(echo $res | jq "some jq black magic")
for host_id in $host_ids
do
tricorder -i inventory -H $host_id -- echo "specific data sent to $host_id"
done
I'm not sure yet on how it should look.
I mean to keep tricorder KISS so it can be integrated easily in a bash script as a standalone command, and not a full-on folder structure like ansible playbooks.
I get that. I guess its a case of where the complexity is, which is going to be subjective. One has potentially confusingly similar CLI options, but with simple value form for each option. The other has a single clear CLI option, but the value form it takes is more complex.
`tricorder -i foo -t 'RoleA&(DC1|DC2)'` or
`tricorder -i foo -t 'DC1,DC2' -T 'Role'`
Ultimately if the capability is there, that's a great positive IMO, regardless of how you choose to expose it.
> I'm not sure yet if parallelization should be the default or not. Also I've not yet learned Tokio and Async programming in Rust :P
Right, I hadn't actually got to looking into how tricorder handles calls to multiple nodes - if it's not concurrent it actually wouldn't be able to replace the deployment helper I mentioned, but that doesn't mean it's bad or wrong. Every tool doesn't have have solve every problem.
Sequentially, one after the other, then it aggregates the `Result<(exit_code, output), Error>` type into a JSON.
Once I take a look at async programming in Rust, it should be trivial to add the concurrent option: just start them all, wait for them, and aggregate as before.
Still not sure if it should be the default or not, should it be a `--sequential` or a `--parallel` flag? IIRC, Ansible does things sequentially too.
> Sequentially, one after the other,
> […] Ansible does things sequentially too.
No, call to nodes aren't sequential, but by parallel batches where tasks are sequential. Here's an interesting reading on those aspects: https://ansiblefrombasics.blogspot.com/2017/09/serial-limit-...
> I don't know that a full parser for Boolean logic is necessary - even having a complimentary `-T` option that takes mandatory tag names might be enough.
Here's how the targeted concurrent is doing it: https://docs.ansible.com/ansible/latest/user_guide/intro_pat...