[volunteergrid2-l] testing new mailing list and Hello.

[Shawn Willden]

On Tue, Jan 18, 2011 at 9:02 AM, Billy Earney <billy.earney at gmail.com>wrote:

> Even though last week I said I’d spare 100GB for the grid, I can easily
> spare 500GB if that is required for entry..   I’ve moved some files around
> on a 1TB drive I have, so I should have about 500GB allocated for the grid.
>

Excellent!  I think we've got a consensus, then, that 500 GB is a good
minimum requirement.

On the maximum node size, shall we set that at 1 TB?


>  By the way,  I don’t mean to rush into things, but when do we want to
> start putting the grid together and requirements for entry?  Do we need 20
> participants before putting it together or can we start when we have a dozen
> or so?
>

I don't think we need to wait.  Having fewer just means picking some
different encoding parameters.  I don't want to overstate the value of the
particular parameters I was recommending.  The key is that the most
effective parameters are with H close to the size of the grid and K chosen
to achieve the desired level of reliability based on H -- and with H close
to the size of the grid, poor individual server availability will mean the
grid will be unavailable for writes.

I suggest that we go ahead and set the grid up now, and see where we're at.
Personally, I'll probably wait until we have about a dozen or 15 nodes
before I start using it, but I can make 500 GB available for it now.

Also, assuming we can get enough people who are willing to commit the
storage and the uptime, I don't think we should cap the grid at 20 nodes.
I'd like to see double that.

Assuming there are no contrary opinions (and if there are, by all means
speak up!  We need to operate by consensus if this is to be successful),
should we start with these rules in addition to the ones Zooko mentioned?

1.  Each node shall provide no less than 500 GB of storage, and shall
consume no more than min(node_size, 1000 GB).

2.  Each node shall maintain an uptime of at least 95% (eventually we may
even build some tools to monitor uptime).

3.  Nodes shall not be co-located without consensus approval by the group.

4.  Each node's nickname shall include the operator's e-mail address.  The
recommended form is "<e-mail address>-<hostname>", though operators who
provide only one node may omit the hostname.

5.  Each node shall generally be no more than two releases behind the
current Tahoe-LAFS version.  Node operators are encouraged to delay 1-2
weeks before deploying a new release.

6.  All node operators shall be nice to one another when addressing any
violations of the above rules ;-)

Anything else?  Any objections?

Who wants to set up the introducer?

-- 
Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/volunteergrid2-l/attachments/20110118/8282cf63/attachment.html>