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

[Jody Harris]

On Tue, Jan 18, 2011 at 9:35 AM, Shawn Willden <shawn at willden.org> wrote:

> 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.
>
> I need clarification on this. If I can guarantee node availability, why do
I need to have approval from the list before going forward with a
deployment? If I deploy a collocated node and it fails to satisfy the uptime
requirement, I can always take it off the grid.


> 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.
>
> Just as a note on this: One of my nodes is running on an Intel Atom
equipped nettop. When I attempted to upgrade the tahoe-lafs from the version
in the repositories, I found that the required build tools were not complete
for the version of Ubuntu running on the system. This system may be stuck at
the tahoe-lafs version currently running on it for the foreseeable future. I
would consider this an exception to the rule, with the rule being, "stay up
to date as possible."


> 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?
>
> Since I've already volunteered my introducer, I'll do so again. I'll be
happy to reinitialize my introducer for the volunteergrid2. Unless there are
objections to having the introducer run on my Rackspace Cloud server, I'll
move forward later today.

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