CLI option to automatically start and stop a node #2383

Open
opened 2015-02-09 11:41:47 +00:00 by lpirl · 12 comments

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.
lpirl added the
unknown
normal
enhancement
1.10.0
labels 2015-02-09 11:41:47 +00:00
lpirl added this to the undecided milestone 2015-02-09 11:41:47 +00:00
daira commented 2015-02-09 17:16:07 +00:00
Owner

What prevents this being done by a shell script?

What prevents this being done by a shell script?
Author

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-96755): > 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.

This is a duplicate of #2146.

This is a duplicate of #2146.
zooko added the
duplicate
label 2015-02-10 17:53:08 +00:00
zooko closed this issue 2015-02-10 17:53:08 +00:00
Author

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

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: 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.
zooko removed the
duplicate
label 2015-02-10 18:53:32 +00:00
zooko reopened this issue 2015-02-10 18:53:32 +00:00
Author

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-96761): > 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
Owner

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

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

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-96765): > 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
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
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.

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

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.
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#2383
No description provided.