3 ms·

You're entirely right; I completely agree. And yet, sometimes you're working in an environment that already has a good ssh configuration for other reasons, and

by tene 10y ago

You're entirely right; I completely agree. And yet, sometimes you're working in an environment that already has a good ssh configuration for other reasons, and you're very low on engineering time that you can invest into something, and ssh is good enough for a first pass implementation. Alternately, you may be working on some kind of ad-hoc data collection or maintenance task that's not going to become part of any long-term infrastructure (or will be replaced by something better), and you don't yet have any better systems in place to run ad-hoc programs across the cluster. I completely agree with you that good RPC is a much better foundation to build reliable systems on. [edited to add]: HarpCaller looks like a pretty interesting project, and similar to several things I've considered building in the past. Nice work.

dozzie 10y ago
> sometimes you're working in an environment that already has a good ssh configuration for other reasons, and you're very low on engineering time that you can invest into something, and ssh is good enough for a first pass implementation. I would agree personally before I wrote xmlrpcd. After I wrote it, I, its author, have no excuses for using SSH as an RPC protocol. Though I'm not good on the marketing side, so I understand that people just don't know about such tools. > Alternately, you may be working on some kind of ad-hoc data collection or maintenance task that's not going to become part of any long-term infrastructure (or will be replaced by something better), and you don't yet have any better systems in place to run ad-hoc programs across the cluster. Honestly, this is yet another matter. To properly manage a set of servers, one needs three different services[&], each for different thing. One service is for running predefined procedures (that can possibly be parametrized) -- this is what HarpCaller and earlier xmlrpcd are for. Another service is for managing configuration and scheduled jobs -- this is a place for CFEngine and Puppet. Then there is what you just said: a tool for running commands defined in an ad-hoc manner and collecting their output synchronously. From the three, the first and second don't match how SSH works and is used, but for the last one it actually makes sense. [&] It doesn't have to be three services, but we don't have one that would cover all three in an uniform way. > [edited to add]: HarpCaller looks like a pretty interesting project, and similar to several things I've considered building in the past. Nice work. Thank you. I'm quite proud of how it turned out, and the middle part of it was an excellent pretext for me to write something for production use in Erlang.

by tene 10y ago

dozzie 10y ago

> sometimes you're working in an environment that already has a good ssh configuration for other reasons, and you're very low on engineering time that you can invest into something, and ssh is good enough for a first pass implementation. I would agree personally before I wrote xmlrpcd. After I wrote it, I, its author, have no excuses for using SSH as an RPC protocol. Though I'm not good on the marketing side, so I understand that people just don't know about such tools. > Alternately, you may be working on some kind of ad-hoc data collection or maintenance task that's not going to become part of any long-term infrastructure (or will be replaced by something better), and you don't yet have any better systems in place to run ad-hoc programs across the cluster. Honestly, this is yet another matter. To properly manage a set of servers, one needs three different services[&], each for different thing. One service is for running predefined procedures (that can possibly be parametrized) -- this is what HarpCaller and earlier xmlrpcd are for. Another service is for managing configuration and scheduled jobs -- this is a place for CFEngine and Puppet. Then there is what you just said: a tool for running commands defined in an ad-hoc manner and collecting their output synchronously. From the three, the first and second don't match how SSH works and is used, but for the last one it actually makes sense. [&] It doesn't have to be three services, but we don't have one that would cover all three in an uniform way. > [edited to add]: HarpCaller looks like a pretty interesting project, and similar to several things I've considered building in the past. Nice work. Thank you. I'm quite proud of how it turned out, and the middle part of it was an excellent pretext for me to write something for production use in Erlang.