Comment by stephenr | Hacker News Reader

Comment by stephenr | Hacker News Reader

Parent Full thread

I think the ability to target more restrictively would be a fantastic addition, largely because I could imagine the tags being used in a way the example doesn't cover: DC/AZ/Region tags.

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!

> 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.

> 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.

> 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.

My 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.

This is true for post 1.0.0 versions. 0.Y.Z versions are experimental and the API has not been stabilized yet.

Ah right. I didn't even look at the current version number I must admit (and my own practice is that stuff starts at 1.0.0), so I didn't consider the pre-1.0 clause.

I always start at 0.1.0 until I figure things out :)

>> 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-...

> I think the ability to target more restrictively would be a fantastic addition, largely because I could imagine the tags being used in a way the example doesn't cover: DC/AZ/Region tags.

> 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...

Reply on news.ycombinator.com