[tahoe-lafs-trac-stream] [tahoe-lafs] #937: 'tahoe run' doesn't work for an introducer node

[tahoe-lafs]

#937: 'tahoe run' doesn't work for an introducer node
-------------------------+-------------------------------------------------
     Reporter:  Bryan    |      Owner:  zooko
  Larsen                 |     Status:  assigned
         Type:  defect   |  Milestone:  1.11.0
     Priority:  major    |    Version:  1.6.0
    Component:  code-    |   Keywords:  docs introducer tahoe-run review-
  frontend-cli           |  needed
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by warner):

 * keywords:  docs introducer tahoe-run => docs introducer tahoe-run review-
     needed


Comment:

 that patch should enable "tahoe run" for both client and introducer
 nodes. The specific issue was that "tahoe run" was hard-wired to load
 client nodes only; it lacked the code to look at the .tac file (to find
 out what kind of node was being started) and then load the appropriate
 code.

 I think we decided to switch away from .tac files a while ago, but only
 "tahoe run" had made any steps in that direction (by hard-coding
 {{{client.Client}}} instead of loading the .tac file). This moves us a
 little bit closer. To avoid relying too much on .tac files, at least
 upon their contents, both {{{tahoe start}}} and {{{tahoe run}}} must
 decide what nodetype is being started (by looking at the name of the
 .tac file, or perhaps from other clues): client, introducer,
 key-generator, stats-gatherer, etc. Then it must load in the appropriate
 class ({{{client.Client}}}, {{{introducer.server.IntroducerNode}}},
 etc), instantiate it, then start the instance.

 This patch includes a test for the "emit a nice error message when asked
 to 'tahoe run' a nodetype that we don't recognize", but it doesn't
 include a test for normal success of 'tahoe run', since 'run' launches
 the reactor, and that's not straightforward to do from within a unit
 test. (note that we didn't previously have coverage of 'tahoe run'
 either). I've run manual tests and things look ok.

 We might consider changing 'tahoe run' to use the "{{{twistd
 --nodaemon}}}"
 approach, which would make it look a lot closer to {{{tahoe start}}}.
 However, that would make it more dependent upon .tac files, not less. In
 the longer run, I think we should try the approach I came up with in my
 [https://github.com/warner/toolbed/blob/master/toolbed/scripts/startstop.py
 "toolbed" project],
 where I create a (in-memory) twistd plugin that creates the desired
 Node, then set up the twistd arguments that will invoke this plugin,
 then give control to {{{twistd.runApp}}} in a child process.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/937#comment:12>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage