[volunteergrid2-l] Revisiting space contribution caps
Shawn Willden
shawn at willden.org
Thu Feb 3 08:45:14 PST 2011
On Thu, Feb 3, 2011 at 9:33 AM, Jody Harris <jharris at harrisdev.com> wrote:
> Thus, I think we can safely remove our max-size policy without any impact
> on the grid. Our concern then shifts to simply monitoring the smallest nodes
> and making sure those are upgraded to larger drives or removed from the grid
> as content grows.
>
If you read the version of the policy that I put on the Wiki, it actually
doesn't mention a maximum node size, just a maximum consumption level. I
didn't write it very clearly, I guess, but my intent is that you are allowed
to consume min(node_size, 1 TB). If you have multiple nodes, you take the
min for each and sum them
sum([ min(size, 1TB) for size in my_node_sizes ])
If you can think of a nice, compact way to write that Python expression in
English, I'd love to hear it. It's simple to express in Python, and very
simple to express in math, but harder to say clearly and concisely in
English.
However, that doesn't directly address your comment.
Allowing users to use whatever they provide could still get us in trouble if
we had a user join who wanted to deploy a node with, say 10 TB, and then
consume 10 TB in the grid. Since the rest of us probably aren't ready (or
interested) in upgrading to that level, allowing that person to join the
grid would create a situation where the grid cannot fulfill that person's
expectations and attempting to would make the grid useless for the rest of
us.
Thus, we want a policy that politely makes clear to that person that this
grid is not the grid he's looking for.
--
Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/cgi-bin/mailman/private/volunteergrid2-l/attachments/20110203/d0ca30c8/attachment-0001.html>
More information about the volunteergrid2-l
mailing list