6 ms·

Thank you for the feedback. This is an OR, if either tag is present, it will be selected. I'm not set on this, maybe I will add a simple parser for something l

• stephenr 5y ago
  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!
  • 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 ago
          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.
          • linkdd 5y ago
            This 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
    > 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_patterns.html#common-patterns https://docs.ansible.com/ansible/latest/user_guide/intro_pat...