[tahoe-dev] [tahoe-lafs] #68: implement distributed introduction, remove Introducer as a single point of failure

tahoe-lafs trac at tahoe-lafs.org
Tue Jul 13 05:49:03 UTC 2010 

#68: implement distributed introduction, remove Introducer as a single point of
failure
------------------------------+---------------------------------------------
     Reporter:  lvo           |       Owner:  writefaruq                                                   
         Type:  enhancement   |      Status:  new                                                          
     Priority:  major         |   Milestone:  1.8.0                                                        
    Component:  code-network  |     Version:  0.2.0                                                        
   Resolution:                |    Keywords:  scalability availability introduction gsoc review-needed docs
Launchpad Bug:                |  
------------------------------+---------------------------------------------

Comment (by zooko):

 Faruq:

 Great! Please go ahead and take my suggestions below then write
 documentation patches like these and attach a darcs patch to this ticket
 for just the documentation patches.

 The current plan is to finish the strategy from comment:38, except that
 for

 * Step 2A: If "basedir/introducers" found: a) load introducer furls from
 this file b) warn if there is any introducer_furl entry in tahoe.cfg

 change it to:

 * Step 2A: If "basedir/introducers" found: a) load introducer furls from
 this file b) warn unless there is exactly one introducer furl from this
 file and it is the same as the introducer_furl entry in tahoe.cfg

 (This is as described in my comment:40 and davidsarah's comment:42.)

 Also about your docs: consider that once your patches land in trunk then
 configuring the "introducers" file will be the preferred way to do it and
 the "introducer.furl" entry in tahoe.cfg will be supported ''only'' for
 backward-compatibility reasons and will not be recommended to new users.
 So the documentation should describe the "introducers" file as the way to
 configure it and mention the "introducer.furl" entry in tahoe.cfg ''only''
 when explaining that such an entry, if it exists, will be automatically
 written into the "introducers" file.

 Replying to [comment:44 writefaruq]:
 >
 > For configuration.txt:
 >  If a Tahoe grid has multiple introducers, each introducer's FURL must
 be placed in  "BASEDIR/introducers" file. Each line of this file contains
 exactly one FURL entry. Any FURL entry found in tahoe.cfg will be copied
 to that file.

 Don't say "If" here, just say that this is the way to configure any
 introducers (regardless of if it is one or more). It ''is'' necessary to
 mention the automatic copying of the FURL entry from tahoe.cfg so that
 readers of configuration.txt will have a complete understanding and
 understand the backward-compatibility implications.

 Also, please call it "Tahoe-LAFS" instead of "Tahoe" in docs. (For one
 thing, I don't want to have a name collision with
 http://sourceforge.net/projects/tahoe/ . For another thing, I think of
 "LAFS" as the protocol and the data formats and specification, and "Tahoe-
 LAFS" as the current Python implementation.)

 > For architecture.txt:
 >  By deploying multiple introducers in a Tahoe grid, the above SPoF
 challenge can be overcome. In that case if one introducer fails clients
 are still be  able to get announcement about new servers from remaining
 introducers. This is our first step towards implementing a fully
 distributed introduction.
 >  For future releases, we have plans to enhance our distributed
 introduction, allowing any server to tell a new client about all the
 others.

 Nice!

 > For running.html:
 >  To use multiple introducers, write all introducers' FURLs in
 "BASEDIR/introducers" file, one FURL per line.

 Again, edit running.html so that the "BASEDIR/introducers" is the only
 method of configuring introducers. It is not necessary to mention the
 automatic copying of introducer.furl from tahoe.cfg in running.html.

 Please for each patch that you submit write a descriptive patch name and
 description like these ones:
 [20100224043813-66853-cf82bb2faf1443ffdcd4758e425370210d1c4b77],
 [20100224044637-66853-c474e29974805ee2a5c933e5ddb737ea6fc794db],
 [20100515184344-b8d28-83abf8aeae7eba987611f627b803e52011f18053],
 [20100310025913-d77e5-0c56129b0614320a93ba326557d41e845e1b19e0],
 [20100609091120-c0148-3ddbb6405db9275a3e272739e029795f02440f86],
 [20100524003508-b8d28-0c82b8c3f31678f0bb6950124a14bad8da579599],
 [20100712050721-93fa1-ff98078cd3a65d6d930ec25bba771dea018bbf39].



 Okay, good work on this! I'm hoping that by the time I have to write a
 mid-term review for Google (which I guess I have to do by Friday), that I
 will be able to say that you've completed a working subset of your summer
 goal.

 Please post the doc patch as a darcs patch and I will review it right
 away. Now what about test patches. You've already posted
 attachment:test_root.py and attachment:test_multi_introducers.py . Are
 those the complete set of tests for the "comment:38" strategy?

 Oh no, looking at them I see that attachment:test_root.py is asking the
 code-under-test to look at the old {{{.introducer_furl}}} attribute. That
 is not right, it should instead be requiring the code-under-test to
 ''not'' look at the old {{{.introducer_furl}}} attribute and instead to
 look only at the {{{.introducer_furls}}} attribute.

 I see that attachment:test_multi_introducers.py is requiring the code-
 under-test to have 1 introducer for the "introducer.furl" entry in
 tahoe.cfg plus however many are in the "introducers" file. But what
 "introducers" file is used for this test? When this test code runs it will
 be inside a temporary directory (named "_trial_temp") which will not
 already have any "introducers" file present.

 Let's make the test code provide an introducers file to the code-under-
 test, something like this:

 {{{
 from allmydata.util.fileutil import write

 INTRODUCER_FURLS=['furl1', 'furl2']

 class T(unittest.TestCase):
     def test(self):
         write(MULTI_INTRODUCERS_CFG, '\n'.join(INTRODUCER_FURLS))
         # get a client and count of introducer_clients
         myclient = Client()
         ic_count = len(myclient.introducer_clients)
         self.failUnlessEqual(ic_count, 2)
 }}}

 That test would be testing that the {{{Client}}} discovers the two furls
 in the "introducers" file. Then we also need the following tests of the
 "comment:38" strategy:

 1. A test that makes sure that if there is a different furl in tahoe.cfg
 than what is in the "introducers" file that this different furl does
 ''not'' get used by Client but that instead a warning message is printed
 to stderr. (By the way, here is some test code for a different project
 that I wrote recently to make sure that the code under test writes a
 certain thing to stderr: http://tahoe-
 lafs.org/trac/trialcoverage/browser/trunk/trialcoverage/test/test_import_all.py?rev=32#L47
 )
 2. A test that makes sure the code under test is doing Step 2B: If no
 "basedir/introducers" found: a) create one "basedir/introducers" b) write
 introducer_furl entry from tahoe.cfg to this file. So this test would
 create a "basedir/tahoe.cfg" (with an introducer.furl entry in it) but not
 a "basedir/introducers" file, instantiate the {{{Client}}} object, and
 then check that it has an introducer client object for the furl entry from
 the tahoe.cfg file, and then check that a new "basedir/introducers" file
 has been created with that furl in it.
 3. A test similar to the current attachment:test_root.py to make sure that
 the code which generates the WUI pages queries the right attributes.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/68#comment:45>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized file storage grid

More information about the tahoe-dev mailing list