CLI option to automatically start and stop a node

lpirl commented

2015-02-09 11:41:47 +00:00

Owner

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.

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.

tahoe-lafs added the

labels 2015-02-09 11:41:47 +00:00

tahoe-lafs added this to the undecided milestone 2015-02-09 11:41:47 +00:00

daira commented

2015-02-09 17:16:07 +00:00

Author

Owner

What prevents this being done by a shell script?

lpirl commented

2015-02-10 12:43:29 +00:00

Author

Owner

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.

Replying to [daira](/tahoe-lafs/trac-2024-07-25/issues/2383#issuecomment-138158): > 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 commented

2015-02-10 17:53:08 +00:00

Author

Owner

This is a duplicate of #2146.

tahoe-lafs added the

duplicate

label 2015-02-10 17:53:08 +00:00

zooko closed this issue

2015-02-10 17:53:08 +00:00

lpirl commented

2015-02-10 18:07:43 +00:00

Author

Owner

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

#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 commented

2015-02-10 18:53:32 +00:00

Author

Owner

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.

tahoe-lafs removed the

duplicate

label 2015-02-10 18:53:32 +00:00

zooko reopened this issue

2015-02-10 18:53:32 +00:00

lpirl commented

2015-02-10 18:57:10 +00:00

Author

Owner

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.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/2383#issuecomment-138164): > 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 commented

2015-02-11 16:24:07 +00:00

Author

Owner

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

lpirl commented

2015-02-11 16:40:16 +00:00

Author

Owner

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.

Replying to [daira](/tahoe-lafs/trac-2024-07-25/issues/2383#issuecomment-138168): > 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 commented

2015-02-12 03:34:18 +00:00

Author

Owner

Replying to [lpirl]comment:10:

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

Replying to [lpirl]comment:10: > …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 commented

2015-02-12 03:40:25 +00:00

Author

Owner

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 commented

2015-02-12 12:15:36 +00:00

Author

Owner

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:138171)… 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.
"""

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:138171](/tahoe-lafs/trac-2024-07-25/issues/2383#issuecomment-138171))… 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 commented

2020-01-20 20:53:33 +00:00

Author

Owner

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.

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.

CLI option to automatically start and stop a node #2383