4 ms·
> largely because I could imagine the tags being used in a way the example doesn't cover: DC/AZ/Region tags. I'll add this feature to the roadmap then :) > I
by linkdd 5y ago
> largely because I could imagine the tags being used in a way the example doesn't cover: DC/AZ/Region tags.
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
Maybe i'll make use of the `tinytemplate` crate and add a -D option for data that would be similar to the inventory (TOML static file or program/script outputting JSON).
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.
- stephenr 5y ago> 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... 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.
- linkdd 5y ago> how tricorder handles calls to multiple nodes 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.
- stephenr 5y agoMy approach to stuff like this is basically semver: the product is out, so any new capability (e.g. parallel operation) can't change the default at least until a major version change.
- linkdd 5y agoThis is true for post 1.0.0 versions. 0.Y.Z versions are experimental and the API has not been stabilized yet.
- gilcot 5y ago>> how tricorder handles calls to multiple nodes > 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-number-of-parallel.html https://ansiblefrombasics.blogspot.com/2017/09/serial-limit-...