Draft Board Report for Jan 2018

[Michael Wall]

The Apache Accumulo PMC decided to draft its quarterly board
reports on the dev list. Here is a draft of our report which is due
by Wednesday, Jan 10. Please let me know if you have any suggestions,
I plan to submit on the 9th.

Mike

--

## Description:
  - The Apache Accumulo sorted, distributed key/value
  store is a robust, scalable, high performance data storage system that
  features cell-based access control and customizable server-side
  processing.  It is based on Google's BigTable design and is built on
  top of Apache Hadoop, Zookeeper, and Thrift.

## Issues:
  - There are no issues requiring board attention at this time.

## Activity:
  - There were no new releases during the current reporting period.
  - There were 4 new contributors added since the last report.
  - Community is discussing a 1.9 release instead of going from 1.8 to 2.0.
  The release of Hadoop 3.0 and how Accumulo will support it started the
  discussion.

## Health report:
  - The project remains healthy.  Activity levels on mailing lists, git and
  JIRA remain constant.

## PMC changes:
  - Currently 30 PMC members.
  - No new committers added in the last 3 months
  - Last committer addition was Ivan Bella at Wed Jul 12 2017

## Committer base changes:
  - Currently 30 committers.
  - No new committers added in the last 3 months
  - Last committer addition was Ivan Bella at Wed Jul 12 2017

## Releases:
  - Last release was 1.7.3 on Sat Mar 25 2017

## Mailing list activity:
  - Nothing significant in the figures

## JIRA activity:
  - 60 JIRA tickets created in the last 3 months
  - 61 JIRA tickets closed/resolved in the last 3 months

Re: [DISCUSS] Any interest in separate client/server tarballs

[Christopher]

tl;dr : I would prefer not to add another tarball as part of our "official"
releases, but I'd be in favor of a blog instructions, script, or build
profile, which users could read/execute/activate to create a client-centric
package.

I've long believed that supporting different downstream packaging scenarios
should be prioritized over upstream binary packaging. I have argued in
favor of removing our current tarball entirely, while supporting efforts to
enable downstream packaging by modularizing the server code, supporting a
client-API jar (future work), and decoupling code from launch scripts. I
think we should continue to do these kinds of improvements to support
different packaging scenarios downstream, but I'd prefer to avoid
additional "official" binary releases.

Rather than provide additional packages, I'd prefer to work with downstream
to make the source more "packagable" to suit the needs of these downstream
vendor/community packagers. One way we can do that here is by either
documenting what would be needed in a client-centric package, or by
providing a script or build profile to create it from source, so that your
$dayjob or any other downstream packager doesn't have to figure that out
from scratch.

On Thu, Jan 4, 2018 at 7:17 PM Josh Elser  wrote:

> Hi,
>
> $dayjob presented me with a request to break up the current tarball into
> two: one suitable for "users" and another for the Accumulo services. The
> ultimate goal is to make upgrade scenarios a bit easier by having client
> and server centric packaging.
>
> The "client" tarball would be something suitable for most users
> providing the ability to do things like:
>
> * Launch a java app against Accumulo
> * Launch a MapReduce job against Accumulo
> * Launch the Accumulo shell
>
> Essentially, the client tarball is just a pared down version of our
> "current" tarball and the server-tarball is likely equivalent to our
> "current" tarball (given that we have little code which would be
> considered client-only).
>
> Obviously, there are many ways to go about this. If there is buy-in from
> other folks, adding some new assembly descriptors and making it a part
> of the Maven build (perhaps, optionally generated) would be the easiest
> in terms of maintenance. However, I don't want to push for that if it's
> just going to be ignored by folks. I'll be creating something to support
> this one way or another.
>
> Any thoughts/opinions? Would this have any value to other folks?
>
> - Josh
>

[DISCUSS] Any interest in separate client/server tarballs

[Josh Elser]

Hi,

$dayjob presented me with a request to break up the current tarball into 
two: one suitable for "users" and another for the Accumulo services. The 
ultimate goal is to make upgrade scenarios a bit easier by having client 
and server centric packaging.


The "client" tarball would be something suitable for most users 
providing the ability to do things like:


* Launch a java app against Accumulo
* Launch a MapReduce job against Accumulo
* Launch the Accumulo shell

Essentially, the client tarball is just a pared down version of our 
"current" tarball and the server-tarball is likely equivalent to our 
"current" tarball (given that we have little code which would be 
considered client-only).


Obviously, there are many ways to go about this. If there is buy-in from 
other folks, adding some new assembly descriptors and making it a part 
of the Maven build (perhaps, optionally generated) would be the easiest 
in terms of maintenance. However, I don't want to push for that if it's 
just going to be ignored by folks. I'll be creating something to support 
this one way or another.


Any thoughts/opinions? Would this have any value to other folks?

- Josh

Re: Test replication

[Josh Elser]

You can configure a replication peer which is the "local" Accumulo instance.

I think there are some ITs which do this.

On 1/4/18 4:13 PM, Mike Miller wrote:

Trying to test a fix for the 2.0 Monitor
https://issues.apache.org/jira/browse/ACCUMULO-4760 and I wanted to enable
replication.  Does anyone know if there is a way to enable it running a
single Uno instance?  I just need to "turn it on" so I can see if the
Monitor is reporting correctly.

Re: Test replication

[Christopher]

Oh, also, maybe it's possible to replicate to the current instance, but to
a different table?

On Thu, Jan 4, 2018 at 5:07 PM Christopher  wrote:

> I think it would be a good idea to create a null replication target for
> testing, if one doesn't already exist.
>
> On Thu, Jan 4, 2018 at 4:14 PM Mike Miller  wrote:
>
>> Trying to test a fix for the 2.0 Monitor
>> https://issues.apache.org/jira/browse/ACCUMULO-4760 and I wanted to
>> enable
>> replication.  Does anyone know if there is a way to enable it running a
>> single Uno instance?  I just need to "turn it on" so I can see if the
>> Monitor is reporting correctly.
>>
>

Re: Test replication

[Christopher]

I think it would be a good idea to create a null replication target for
testing, if one doesn't already exist.

On Thu, Jan 4, 2018 at 4:14 PM Mike Miller  wrote:

> Trying to test a fix for the 2.0 Monitor
> https://issues.apache.org/jira/browse/ACCUMULO-4760 and I wanted to enable
> replication.  Does anyone know if there is a way to enable it running a
> single Uno instance?  I just need to "turn it on" so I can see if the
> Monitor is reporting correctly.
>

Test replication

[Mike Miller]

Trying to test a fix for the 2.0 Monitor
https://issues.apache.org/jira/browse/ACCUMULO-4760 and I wanted to enable
replication.  Does anyone know if there is a way to enable it running a
single Uno instance?  I just need to "turn it on" so I can see if the
Monitor is reporting correctly.