CLI option to automatically start and stop a node

[lpirl]

Use case: You have a node that is basically a client for doing backups. You run that client not continuously but only for doing backups.

Now, you wish to have a --startstop option (or similar) that starts the node, then does your requested action (i.e. tahoe backup something) and stops the node afterwards.

[daira]

What prevents this being done by a shell script?

[lpirl]

Replying to daira:

What prevents this being done by a shell script?

Yes, this would be equivalent (except that an integrated behavior may waits until the initial connection phase is done before running the requested action).

For me it would be simply an usability enhancement: I can still call the normal tahoe command (e.g. from cron) even if my node is not always online (a "true" client). This is an use case Tahoe would then offer more obviously and supportive to CLI users.

[zooko]

This is a duplicate of #2146.

[lpirl]

#2146 serves another use case, doesn't it? Or is it intended to also stop the node again after the requested action was taken?

The use case of --startstop would be to have a node that is only online for specific, rare actions (say, a backup once a day).

[zooko]

lpirl: You're right, #2146 doesn't say to stop the node after the command is one. So I guess they are different, but closely related, purposes.

[lpirl]

Replying to zooko:

lpirl: You're right, #2146 doesn't say to stop the node after the command is one.

What could serve both needs would be separate --autostart and --autostop - it is not that "clean" for the use case of this ticket but more explicit and generic, thought.

[daira]

Oh, this interacts with #719, which makes it not a good idea to attempt operations immediately after node startup.

[lpirl]

Replying to daira:

Oh, this interacts with #719, which makes it not a good idea to attempt operations immediately after node startup.

…another reason why an integrated behavior should be preferred over a shell script. As I mentioned in comment:4, the integrated behavior could wait for the initial connection phase to complete.

[daira]

Replying to lpirl:

…another reason why an integrated behavior should be preferred over a shell script.

Well, not necessarily. The point of #719 is that starting a node and then waiting for it to connect to a sufficient number of servers is quite expensive in terms of latency. Therefore, if you're going to do several operations then you should batch them and start the node only once, then (possibly; see below) stop it only once afterward. This lends itself more to a script.

I realize now that I've been expecting most users to leave a gateway node running semi-permanently, even though the docs don't actually say you're expected to do that.

[daira]

Also, note that if you have a scheduled operation that automatically starts and stops a node, then it had better be a different node than you're using as your gateway for ad-hoc CLI commands. If it is the same node then the scheduled operation will sometimes happen at the same time as an ad-hoc one, causing random failures as the node is stopped. On the other hand, using two nodes that both write to the same mutable objects will introduce write coordination problems.

[daira]

lpirl wrote on tahoe-dev:

I just wanted to reply to a ticket but this comment got a 95.19% spam rating?!

""" All true. But how can we improve the usability for the "programmatic ad-hoc use" (cron etc.)? I think the ad-hoc-gateway-use case is valid (very low-resource or production systems).

Latency (comment:11) is simply what one would have to accept when the node is not permanently up. Inferences with interactive CLI use (comment:12)… well, users would probably start and stop the node manually anyways for interactive operations because they are not expecting it to be up. So, the node should not stop automatically when it wasn't started automatically. But yes, interactive users may interrupt non-interactive operations then.

Another idea would be an idle timeout to let a gateway shutdown automatically or a switch for tahoe stop that makes the node wait for all queued operations to complete. """

[exarkun]

I would like to see a *daemonless* mode of operation for some CLI. Instead of automatically starting and stopping a deamon, it should just do whatever needs to be done itself and leave nothing behind when it is done.