[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3925: revamp "tahoe run"

[Tahoe-LAFS]

#3925: revamp "tahoe run"
-----------------------------+-----------------------
     Reporter:  meejah       |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  undecided
    Component:  unknown      |    Version:  n/a
   Resolution:               |   Keywords:
Launchpad Bug:               |
-----------------------------+-----------------------

Comment (by exarkun):

 It seems like refactoring away from twistd and adding the creation time
 information should be separate tasks.  It makes sense that implementing
 the creation time recording might be simpler without having to worry about
 the specific factoring twistd imposes on us so I can see the motivation to
 do the refactoring first.  I'd still try to land that independently of any
 behavior changes.

 As far as what functionality we're comfortable dropping from twistd, the
 following options seem useful and it seems reasonable that we'd want to
 still have them (or equivalents) with our new command-line runner:

 * debug
 * reactor
 * help-reactors
 * profile
 * profiler
 * savestats
 * pidfile (or equivalent for "pid and creation time file")

 Profiling does work via twistd with the tahoe cli but the UI is wonky: the
 default profiler is the bad one so you always want `--profiler cprofile`;
 by default the text report is written, ordered by _name_, which is almost
 never what you want, so you almost certainly also want `--savestats`; and
 tahoe changes its working directory to the node directory before profiling
 is set up so the path you pass to `--profile` is interpreted relative to
 that directory (which I guess is why you didn't see a profile report
 written where you were looking).

 These are tempting but not really critical:

 * rundir
 * uid, gid, euid
 * umask

 These all have to do with process-global state that you often want to
 control in a careful deployment - but they're also all things that
 whatever process launches tahoe can initialize so at best they would be a
 convenience for folks without tools to control them some other way (which
 is probably not anyone doing a careful deployment).

 Assuming we're going to keep going with "just write all your logs to
 stdout", we don't need:

 * logfile
 * logger
 * syslog
 * prefix

 (Presumably we keep *our* options for configuring the eliot log though.)

 These are silly and Tahoe certainly doesn't need them:

 * chroot
 * encrypted
 * file
 * nodaemon
 * no_save
 * originalname
 * source
 * spew
 * python

 As far as backwards compatibility, the path might be to not do the
 refactoring in-place but instead just implement the new cli (maybe just
 new subcommand) and provide it along-side the existing one.  I think the
 main downside of this approach is it requires thinking of a new name.
 Aside from that, it has good properties: it lets us deprecate the old cli
 over whatever timeline we like while giving early adopters the new stuff
 right away; if there's a problem with the new stuff in some environment,
 people can always stay on the old stuff while they wait for fixes, etc.
 This also lets us develop and release the work incrementally.  We don't
 have to finish the _whole_ replacement CLI before landing _any_ of it in
 master.  That's probably good since this looks like a big chunk of code,
 even with the fairly limited set of options.

 Given all of that, I wonder if -- for the sake of expediency -- we want to
 implement the pid-and-creation-time file feature within the current
 framework first.  Otherwise it seems like we would be looking at quite a
 bit of development effort before that feature becomes usable by the first
 anticipated audience (GridSync).

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3925#comment:1>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage