'tahoe run' doesn't work for an introducer node

[Bryan Larsen]

I tried following the instructions (running.html) for creating an introducer, and it didn't work. With some help from secorp on IRC, we determined that I should use "tahoe start dirname" rather than "tahoe run". There's may be an underlying bug that should be fixed, but the install instructions should be fixed irregardless because people use the current install instructions on old versions.

This problem occurred with both 1.5 and 1.6

[duck]

Update of install instructions warning against using tahoe run for an introducer.

[davidsarah]

running.html was corrected in 8f3246430bc0a17b.

[davidsarah]

937.dpatch.txt was applied in 49912c106e3dc3de.

[davidsarah]

a7c474a09893b9aa makes the error message more explicit, e.g.:

'<dir>' looks like it contains a non-client node (tahoe-introducer.tac).
Use 'tahoe start' instead of 'tahoe run'.

[davidsarah]

Oh, to debug why tahoe run doesn't work for an introducer (or key-generator or stats-gatherer), you'll now have to disable the check at src/allmydata/scripts/startstop_node.py@4641#L206.

[davidsarah]

On #tahoe-lafs:

(00:26:41) makefu|EUER: hi, i am trying to run tahoe in the foreground to let supervisord handle startup. i found the magic line "tahoe run -C /path/to/dir" but when trying to start an introducer i get /path looks like it contains a non-client node (tahoe-introducer.tac).

(00:27:15) makefu|EUER: is there a way to keep tahoe in foreground even for the introducer?

[davidsarah]

This seems to be a workaround, assuming Twisted is installed system-wide (replace TAHOE_SOURCE_DIR and X as necessary):

• cd to the introducer directory
• export PYTHONPATH=TAHOE_SOURCE_DIR/support/lib/python2.X/site-packages
• twistd --nodaemon -y tahoe-introducer.tac

[warner]

enable 'tahoe run' for introducer nodes

[warner]

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 ​"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.

[davidsarah]

Will review.

[davidsarah]

The other tac types are tahoe-key-generator.tac and tahoe-stats-gatherer.tac. Shall we support those while we're about it?

[davidsarah]

Replying to warner:

... (note that we didn't previously have coverage of 'tahoe run' either).

That's #1121.

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 ​"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.

... or use the approach I suggested in ticket:1159#comment:17 of using a .tac in the source tree. That solves the main version-skew problems with .tac files, and is possibly less disruptive to the existing code.

[warner]

(note, if we land my patch from #1159, then this one becomes moot)

(also, #1159 would handle key-generator and stats-gatherer too)

[davidsarah]

Will be fixed by #1159.