As a talking point and/or a suggestion of a kludge from a new user, the single
introducer was enough of an issue that I was actually
considering how to script a "multiple .cfg" setup where multiple
tahoeX.cfg files were present, each with a different prebuilt Introducer
(i.e.
the "you can just make a new Introducer if yours dies completely" DR
scenario, done in advance).
The next step would be to have a "starting script" where the first tahoeX.cfg
in sequence is called, and then the result is checked (though I don't see a
tahoe status to match tahoe start and tahoe stop?), and upon a failure to
connect to the introducer (kludge: any failure), the next tahoeX.cfg is tried;
repeat until a connection is made, or you're out of config files.
It is very crude, and it only properly handles the case where the introducer is
offline from the perspective of every other node (rather than different
introducers being visible to different nodes), but still better than a single
point of failure. More effective would be to have multiple introducers in
order of preference in the .cfg file, and have tahoe do this.
A slight improvement would be that every so often, if each node is not seeing
the primary introducer, it checks top-down again, to "walk back up the line" of
introducers back to the most preferred. This will result in disruption, but
disruption that's reduced over time if the grid returns to a stable state.
I don't claim this is a good idea, only that it is a workable kludge for the
interim.
_______________________________________________
tahoe-dev mailing list
[email protected]
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
