svn commit: r951934 - in /websites/staging/accumulo/trunk/content: ./ release_notes/1.7.0.html

[bu...@apache.org]

Author: buildbot
Date: Tue May 19 21:45:26 2015
New Revision: 951934

Log:
Staging update by buildbot for accumulo

Modified:
    websites/staging/accumulo/trunk/content/   (props changed)
    websites/staging/accumulo/trunk/content/release_notes/1.7.0.html

Propchange: websites/staging/accumulo/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Tue May 19 21:45:26 2015
@@ -1 +1 @@
-1680343
+1680399

Modified: websites/staging/accumulo/trunk/content/release_notes/1.7.0.html
==============================================================================
--- websites/staging/accumulo/trunk/content/release_notes/1.7.0.html (original)
+++ websites/staging/accumulo/trunk/content/release_notes/1.7.0.html Tue May 19 21:45:26 2015
@@ -410,6 +410,27 @@ to reduce the quantity of sockets we nee
 <a href="https://issues.apache.org/jira/browse/ACCUMULO-3597">ACCUMULO-3597</a> prevents this dealock by forcing a
 non-cached connection for the message requesting loads of metadata tablets,
 we can ensure that this deadlock won't occur.</p>
+<h2 id="other-changes">Other changes</h2>
+<h3 id="versions-file-present-in-binary-distribution">VERSIONS file present in binary distribution</h3>
+<p>In the pre-built binary distribution, or distributions built by users from the
+official source release, users will now see a <code>VERSIONS</code> file present in the lib
+directory alongside the Accumulo server-side jars. Because the created tarball
+strips off versions from the jar file names, it can be extra work to actually
+find what the version of the deployed jars is.</p>
+<p><a href="https://issues.apache.org/jira/browse/ACCUMULO-2863">ACCUMULO-2863</a> adds this <code>VERSIONS</code> file to the <code>lib/</code> directory
+which contains the Maven groupId, artifactId, and verison (GAV) information for
+each jar file.</p>
+<h3 id="per-table-volume-chooser">Per-Table Volume Chooser</h3>
+<p>The <code>VolumeChooser</code> interface is a server-side extension point that allows user
+tables to provide custom logic in choosing where its files are written when multiple
+HDFS instances are available. By default, a randomized volume chooser implementation
+is used to evenly balance files across all HDFS instances.</p>
+<p>Previously, this VolumeChooser logic was instance-wide which meant that it would
+affect system tables. This is potentially undesirable as it might unintentionally
+impact other users in a multi-tenant system. <a href="https://issues.apache.org/jira/browse/ACCUMULO-3177">ACCUMULO-3177</a> introduces
+a new per-table property which supports configuration of a <code>VolumeChooser</code>. This
+ensures that the implementation to choose how HDFS utilization happens when multiple
+are available is limited to the expected subset of all tables.</p>
 <h2 id="testing">Testing</h2>
 <p>Each unit and functional test only runs on a single node, while the RandomWalk and Continuous Ingest tests run 
 on any number of nodes. <em>Agitation</em> refers to randomly restarting Accumulo processes and Hadoop DataNode processes,