Opened at 2010-02-20T06:29:54Z
Last modified at 2010-03-31T16:30:35Z
#963 new enhancement
configure default installation of tahoe to point at a working grid
Reported by: | secorp | Owned by: | somebody |
---|---|---|---|
Priority: | major | Milestone: | eventually |
Component: | code-frontend-cli | Version: | 1.6.1 |
Keywords: | install testgrid usability | Cc: | |
Launchpad Bug: |
Description
After a discussion on IRC, it seems that it might be very useful to point a new installation of Tahoe at a default, working grid so that the new user can immediately be up and running. There are several ways this might take shape, ranging from pointing them at a quick cycle time grid maintained by .org, to having a default grid that provides them with a free xyGB, to pointing them at a default, public RO directory so they can browse and download, but then have to activate an account to get RW access (or build their own grid), or ...
Change History (6)
comment:1 Changed at 2010-02-21T01:47:34Z by imhavoc
comment:2 follow-up: ↓ 3 Changed at 2010-02-22T23:53:50Z by warner
Hm, so this is suggesting that the tahoe create-client (or create-node) command should have a default value for its --introducer argument?
Maybe if we just modify the docs, where it shows an example of typing create-client, so make it show create-client --introducer $TESTGRIDINTRODUCER .
comment:3 in reply to: ↑ 2 Changed at 2010-02-23T00:10:18Z by secorp
I think part of the goal would be to have a working system immediately after installation that showed. I'm trying to come up with analogous examples that might show that as one form of standard behavior. Maybe it's not, or maybe it should be.
What might be some reasons to not have it point at a default grid?
comment:4 Changed at 2010-02-23T00:27:51Z by imhavoc
As Tahoe moves toward the "mainstream," the percentage of users who want to test the water and are willing to "read the docs" is going to asymptotically approach statistical zero.
The Tahoe developers will have to (at some point) make a decision about whether or they want to cater to this user. If the decision is to support the non-document reading user, *I think* the best option is to put them on a default grid, then remind them that they are on a default grid until they either switch to a non-default grid, or change the configuration file to not alert them of the default grid status.
(The default grid could turn into the largest, most stable distributed grid on the net as long as users are not encouraged to abandon it. If the default grid turns out to be large and stable, the alert message about the default grid could be removed in future versions.)
comment:5 Changed at 2010-03-30T21:36:09Z by zooko
Talking to people who are installing Tahoe-LAFS for the first time, I'm increasingly interested in this idea. Let's at least make the default installation point at the public Test Grid (once Peter puts the test grid back up).
comment:6 Changed at 2010-03-31T16:30:35Z by davidsarah
- Component changed from packaging to code-frontend-cli
- Keywords install testgrid usability added
- Type changed from task to enhancement
- Version changed from unknown to 1.6.1
Does having a working system "immediately after installation" mean creating a gateway (i.e. tahoe create-client) as part of installation, or just having the testgrid introducer be the default introducer for a manually invoked create-client?
Po: A notice could be printed on on the WUI as well as on every CLI usage indicating "This node is attached to the [GridName?] default grid. See [document.txt] for information and instructions for pointing at a different grid."
It should be clear that: