CLI option to automatically start and stop a node #2383
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#2383
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.What prevents this being done by a shell script?
Replying to daira:
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.
#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.
Replying to zooko:
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.Oh, this interacts with #719, which makes it not a good idea to attempt operations immediately after node startup.
Replying to daira:
…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 [lpirl]comment:10:
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.
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.
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 forall 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.