4 ms·

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?

linkdd 5y ago
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 like `(A|B)&(~C)`. What do you think ?
- 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
Hey, just FYI, v0.8.0 is out with the tag expressions "serve & backend" etc... :) On my way to the 1.0.0 by implementing the automated test suite!

linkdd 5y ago

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 like `(A|B)&(~C)`. What do you think ?

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

Hey, just FYI, v0.8.0 is out with the tag expressions "serve & backend" etc... :) On my way to the 1.0.0 by implementing the automated test suite!