<div class="gmail_quote">On Tue, Jan 18, 2011 at 10:16 AM, Jody Harris <span dir="ltr"><<a href="mailto:jharris@harrisdev.com">jharris@harrisdev.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>


3.  Nodes shall not be co-located without consensus approval by the group.<br></div></div></blockquote><br></div><div>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.</div>
</div></blockquote><div><br>Very valid point; this is something I haven't really brought up previously.<br>
<br>
My rationale here is just disaster-proofing -- and it may be overboard; I take a belt, suspenders and both hands approach to my data reliability.<br><br>If multiple nodes are in the same location, they're subject to being 
destroyed together, or at least becoming temporarily unavailable together.  Also, I think it does become quite difficult to maintain the 95% independent-node uptime standard with co-located nodes, since the odds of two independent 95% nodes going down at the same time is only 0.25%, which equates to at least a 99.75% uptime requirement on the Internet connection and other factors which could take them both out at once.<br>
<br>Because of these risks to the grid availability, I'd like the list to discuss and approved proposed co-located deployments.<br><br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div class="im">

<div> 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.<br><br></div></div><div>

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."</div>
</div></blockquote><div><br>I think that's reasonable.  In general, I think we can always discuss and agree upon reasonable exceptions to the rules.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div class="im">

</div><div>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. </div>
</div></blockquote><div><br>Perfect! <br></div></div><br>-- <br>Shawn<br>