Comment by stephenr | Hacker News Reader

Comment by stephenr | Hacker News Reader

Parent Full thread

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

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

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 :)

Reply on news.ycombinator.com