[volunteergrid2-l] Should we increase the node minimum capacity?

Sat Nov 5 00:35:20 UTC 2011

Yeah, that kinda puts us back to some of the early discussions we had about
access control.... yay.

Wording:
"In the event that the VG2 community elects to increase the minimum node
capacity requirement, all members will be given a [6 months] to comply with
the new guideline. New members and new nodes will be required to commit to
the new guideline upon joining."

I think we should vote on a guideline period for changes, then we can
override that (by vote or special vote) later if we decide that our initial
window was too small or two large. I chose "6 months" based on projected
grid use based on the fact that it took us 8 months to create a usable grid
and many of us aren't even using it yet, and will use much less than our
allotment.

I do like the polling solution you have tossed in. I am unsure about
multiple votes for those contributing multiple nodes. (I currently have two
nodes and will soon have a third. I have an offer for a good home for a
fourth.) If I can clarify my concerns I'll address that in a separate
message later.

I would love to see the developers give us a way to control access to the
introducer, but I understand that it is a painful technological issue to
address gracefully.

"A new introducer" is really rather more simple than setting up a new
introducer. I can delete the configuration file on the introducer and
restart it -- that would force a generation of a new furl, then distribute
the furl to the existing members. Migrating to the new furl will take
several hours for most admins.

We could add a sub-clause to 4b (4.b.i?, 4.b.1?) which stated that members
who refused or were unable to comply with the new grid requirements would
loose their rights and privileges (and access) in [X months] (another vote
required).

jody
----
Ph. 575-208-4567
- Think carefully.

On Fri, Nov 4, 2011 at 5:31 PM, Shawn Willden <shawn at willden.org> wrote:

> Good questions... and made even better by the fact that kicking someone
> off the grid is actually not very easy to do.  Migrating the data isn't so
> much of a problem... it's just like having a node (or some nodes) die, so
> the normal repair process will fix things up.  But kicking someone off a
> grid basically requires starting a new grid and moving all the storage
> nodes over to it.  More precisely, you have to set up a new introducer,
> publish the FURL to everyone (except those being ejected) and then change
> all of the nodes to use the new introducer.  After first giving the
> ejectees a reasonable grace period to download their data, of course.
>
> However, if someone were to announce that they refuse to upgrade, I would
> hope that many of us would vote against the policy change rather than
> create a situation where we have to exercise that "nuclear option".  I
> certainly would.
>
> On Fri, Nov 4, 2011 at 4:11 PM, Brad Rupp <bradrupp at gmail.com> wrote:
>
>> Six months seems reasonable to me too.  The CIVS process is also fine
>> with me.
>>
>> One question I have.  Say we decide a 3/4 majority wins.  What happens to
>> the 1/4 that voted against something?  In the case of hard drive sizes, we
>> certainly can't force them to upgrade to a bigger hard drive.  They might
>> not have funds to do so.  At that point what happens?  Are  they kicked off
>> the grid and we have to migrate their data?  We certainly need to explore
>> what will happen to those with a dissenting vote.
>>
>> I realize that not all policy decisions will be so rash.  But hard drive
>> sizing could get that way.
>>
>> Brad
>>
>>
>> On 11/4/2011 3:37 PM, Shawn Willden wrote:
>>
>>> Six months seems perfectly reasonable to me.  I'm not sure what it
>>> means to give a "minimum" of six months, though... perhaps what you
>>> mean would be more clearly expressed as:
>>>
>>> "In the event that the VG2 community elects to increase the minimum
>>> node capacity requirement, the community will also choose a timeframe
>>> within which all existing members must meet the new requirement.  The
>>> timeframe will be no sooner than six months after the requirement
>>> change is approved.  New members and new nodes will be required to
>>> commit to the new guideline upon joining."
>>>
>>> If that's what you meant, that the six months is a binding minimum on
>>> the community, that we cannot make a change faster than that, I wonder
>>> if it should be a little tighter; maybe three months.  Keep in mind
>>> that although our 2:1 ratio does help keep us from getting to the
>>> effectively full state, it doesn't absolutely prevent it.
>>>
>>> This also points out another question... how do we know when the
>>> community has made a decision to change a policy?  It seems like we
>>> need to define a voting process, and a voting standard.  Do we want to
>>> formally state that all policy changes must be by consensus -- by
>>> which I mean "general accord", or 100% approval?  A simple majority
>>> seems to me not to be a sufficient basis on which to change policies,
>>> but 100% approval is problematic.  A 2/3 or 3/4 supermajority?  That
>>> seems like a good approach to me.
>>>
>>> As for process, there's also the question of whether we want balloting
>>> to be secret or public, and how to go about it.  I started to type out
>>> a proposal and then thought... someone has to have created a nice,
>>> free on-line service for this, so I searched and found
>>> http://www.cs.cornell.edu/**andru/civs.html<http://www.cs.cornell.edu/andru/civs.html>.
>>>  It seems perfect, to me.
>>>
>>> I propose we use CIVS for policy decisions.  We can have a list
>>> discussion to get general consensus on the question and the choices,
>>> and then we'll use the service, giving one vote to each NODE.  The
>>> list of voter e-mail addresses will be from the list of active,
>>> operational nodes.  Operators who have multiple nodes will have to
>>> provide the vote supervisor with additional addresses they can use to
>>> submit their other votes if they want to exercise their multi-voting
>>> prerogative.
>>>
>>> Just as a test, I've created a CIVS vote on this node increase
>>> question.  Everyone who receives an invitation should please vote, but
>>> we won't consider the result binding.  It's mostly just a test, and I
>>> figure it might also be informative.
>>>
>>> On Fri, Nov 4, 2011 at 3:01 PM, Jody Harris<jharris at harrisdev.com>
>>>  wrote:
>>>
>>>> A policy proposal:
>>>> "In the event that the VG2 community elects to increase the minimum node
>>>> requirement, all members will be given a minimum of 6 months to comply
>>>> with
>>>> the new guideline. New members and new nodes will be required to commit
>>>> to
>>>> the new guideline upon joining."
>>>> I guess this would go in as "4b" in the policies
>>>> (http://bigpig.org/twiki/bin/**view/Main/**VolunteerGrid2Policies<http://bigpig.org/twiki/bin/view/Main/VolunteerGrid2Policies>
>>>> ).
>>>> Thoughts?
>>>> 6 months?
>>>> jody
>>>> ----
>>>> Ph. 575-208-4567
>>>> - Think carefully.
>>>>
>>>>
>>>> On Fri, Nov 4, 2011 at 3:28 PM, Shawn Willden<shawn at willden.org>
>>>>  wrote:
>>>>
>>>>>
>>>>> So far all of the responses have been pretty positive.
>>>>>
>>>>> So... is there anyone who objects to increasing the minimum node side
>>>>> from 500 GB to 1 TB (and the maximum size from 1 TB to 2 TB)?  I don't
>>>>> want anyone to feel like they're being railroaded.
>>>>>
>>>>> On Fri, Nov 4, 2011 at 2:20 PM, Marco Tedaldi<marco.tedaldi at gmail.**
>>>>> com <marco.tedaldi at gmail.com>>
>>>>> wrote:
>>>>>
>>>>>> Hello everyone
>>>>>>
>>>>>> Okay... I've just upgraded my server to 1TB about a year ago... Seems
>>>>>> to
>>>>>> be time to do it again.
>>>>>>
>>>>>> Good to have a good reason to do so.
>>>>>>
>>>>>> best
>>>>>>
>>>>>> Marco
>>>>>>
>>>>>> Am 03.11.2011 21:30, schrieb Christoph Langguth:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> this is just to let you know that we just ordered the new 2TB disk
>>>>>>> today. I hope to be joining the grid within the next 2 weeks or so.
>>>>>>>
>>>>>>> In any case, I'm perfecly fine with increasing the minimum -- the new
>>>>>>> disk will be used for VG2 and local backups exclusively, so 1TB is no
>>>>>>> problem at all.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ______________________________**_________________
>>>>>>> volunteergrid2-l mailing list
>>>>>>> volunteergrid2-l at tahoe-lafs.**org <volunteergrid2-l at tahoe-lafs.org>
>>>>>>> http://tahoe-lafs.org/cgi-bin/**mailman/listinfo/**volunteergrid2-l<http://tahoe-lafs.org/cgi-bin/mailman/listinfo/volunteergrid2-l>
>>>>>>> http://bigpig.org/twiki/bin/**view/Main/WebHome<http://bigpig.org/twiki/bin/view/Main/WebHome>
>>>>>>>
>>>>>>
>>>>>> ______________________________**_________________
>>>>>> volunteergrid2-l mailing list
>>>>>> volunteergrid2-l at tahoe-lafs.**org <volunteergrid2-l at tahoe-lafs.org>
>>>>>> http://tahoe-lafs.org/cgi-bin/**mailman/listinfo/**volunteergrid2-l<http://tahoe-lafs.org/cgi-bin/mailman/listinfo/volunteergrid2-l>
>>>>>> http://bigpig.org/twiki/bin/**view/Main/WebHome<http://bigpig.org/twiki/bin/view/Main/WebHome>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Shawn
>>>>> ______________________________**_________________
>>>>> volunteergrid2-l mailing list
>>>>> volunteergrid2-l at tahoe-lafs.**org <volunteergrid2-l at tahoe-lafs.org>
>>>>> http://tahoe-lafs.org/cgi-bin/**mailman/listinfo/**volunteergrid2-l<http://tahoe-lafs.org/cgi-bin/mailman/listinfo/volunteergrid2-l>
>>>>> http://bigpig.org/twiki/bin/**view/Main/WebHome<http://bigpig.org/twiki/bin/view/Main/WebHome>
>>>>>
>>>>
>>>>
>>>> ______________________________**_________________
>>>> volunteergrid2-l mailing list
>>>> volunteergrid2-l at tahoe-lafs.**org <volunteergrid2-l at tahoe-lafs.org>
>>>> http://tahoe-lafs.org/cgi-bin/**mailman/listinfo/**volunteergrid2-l<http://tahoe-lafs.org/cgi-bin/mailman/listinfo/volunteergrid2-l>
>>>> http://bigpig.org/twiki/bin/**view/Main/WebHome<http://bigpig.org/twiki/bin/view/Main/WebHome>
>>>>
>>>>
>>>
>>>
>>>  ______________________________**_________________
>> volunteergrid2-l mailing list
>> volunteergrid2-l at tahoe-lafs.**org <volunteergrid2-l at tahoe-lafs.org>
>> http://tahoe-lafs.org/cgi-bin/**mailman/listinfo/**volunteergrid2-l<http://tahoe-lafs.org/cgi-bin/mailman/listinfo/volunteergrid2-l>
>> http://bigpig.org/twiki/bin/**view/Main/WebHome<http://bigpig.org/twiki/bin/view/Main/WebHome>
>>
>
>
>
> --
> Shawn
>
> _______________________________________________
> volunteergrid2-l mailing list
> volunteergrid2-l at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/volunteergrid2-l
> http://bigpig.org/twiki/bin/view/Main/WebHome
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/cgi-bin/mailman/private/volunteergrid2-l/attachments/20111104/07089e39/attachment.html>