Re: new committer: Dominic Garguilo

[Billie Rinaldi]

Congrats and welcome, Dominic!

On Thu, Jul 29, 2021, 1:41 PM Christopher  wrote:

> The Project Management Committee (PMC) for Apache Accumulo has invited
> Dominic Garguilo to become a committer and PMC member and we are
> pleased to announce that they have accepted.
>
> Dominic has been contributing various fixes and improvements to
> Accumulo since Fall 2020.
>
> Being a committer enables easier contribution to the project since
> there is no need to go via the patch submission process. This should
> enable better productivity. A PMC member helps manage and guide the
> direction of the project.
>
> Welcome, Dominic!
>

Open Source Hackathon for Diversity

[Billie Rinaldi]

Hello Accumulo community, I am helping plan a virtual hackathon on April
29-30 with the hopeful goal of improving diversity in the open source
community. Information about the hackathon is below, including a
registration link for participants as well as an email address that you can
contact if you are interested in mentoring. Hope you can join us!

Billie

---
Looking to get more involved in an open-source project, have an idea of
your own to improve the project, or just want to learn about an OSS
project? Join our open-source hackathon to contribute to OSS projects. The
goal is to kick-start involvement in the OSS community and foster an
environment for contributions and increase the diversity of the OSS
communities.

What can you work on?
- Apache Accumulo
- Apache NiFi
- Helm
- GNU Radio
- Or bring your own!

Why join?
- Learn something new along with mentors from the OSS projects.
- Collaborate with others.
- Enhance your GitHub profile.
... and most importantly, have FUN!

All skill levels and contribution levels are welcomed. No prior open-source
contribution experience is required. All the participating open-source
projects will have a starting guide and a few items to start contributing
along with mentors to support you!

When? April 29th - 30th | Virtual via Microsoft Teams

Registration: https://tiny.cc/osshack

Questions? Want to mentor? Email hackathon...@gmail.com

Re: Nuances of Major Compactions

[Billie Rinaldi]

Yes, it is definitely possible for a major compaction to see only part of a
row. Only during a full major compaction will an iterator see all of the
tablet's files. Even then, the iterator would not see any k/v entries for
the row that were still in memory in the tablet server. Ingest would need
to be paused and the table would need to be flushed for a full major
compaction to be guaranteed to see entire rows.

The IteratorEnvironment passed into the iterator initialization has a
method isFullMajorCompaction that allows an iterator to tell if a full
major compaction is happening or not. Here is an example of its use:
https://github.com/apache/accumulo/blob/1dc72fce2c781dee597c8c11876a3bc6c321c199/core/src/main/java/org/apache/accumulo/core/iterators/user/RowDeletingIterator.java#L98

It seems like you are correct about reseeks not occurring during major
compaction, but I would need to double check that.

Billie

On Thu, Mar 25, 2021 at 12:43 PM Bradley Barber  wrote:

> Hi all!
>
> I'm looking for details on major compaction. Some of my colleagues and I
> have been working on an iterator which we are attaching at major compaction
> scope. The logic of this iterator requires that it always see entire rows -
> ie. iterates over all KV entries which make up all versions of a given row.
> From the Accumulo documentation, we had assumed this was guaranteed for
> major compactions since tablets are partitioned at row boundaries.
>
> However, we are seeing some intermittent (and fairly rare) occurrences of
> incorrect behaviour from our iterator. Having reviewed and tested the
> iterator logic, we are quite confident it works as intended. Were we
> incorrect in thinking that only entire rows will take part in major
> compactions? Are there instances where a major compaction within a tablet
> will see only partial rows? On reviewing the documentation, it seems this
> *may
> *be possible when a major compaction is called to merge a subset of RFiles
> in a given tablet, but it's not very clear. Would anyone be able to clarify
> this for us?
>
> Issues with our iterator logic may also occur if reseeks are performed
> during a major compaction. However, from our reading of the available
> documentation, we got the impression that reseeks do not occur during major
> compaction and we can't see why they would be. Is this guaranteed or are
> there cases where a reseek may in fact be called during major compaction?
>
> Sorry for the long, involved questions but any clarification would help us
> greatly and be very appreciated :)
>
> Hope you all are having a good week,
> Bradley Barber
>

Re: New committer/PMC member: Karthick Narendran

[Billie Rinaldi]

Congratulations and welcome, Karthick!

Billie

On Fri, Jan 22, 2021 at 3:13 AM Christopher  wrote:

> The Project Management Committee (PMC) for Apache Accumulo
> has invited Karthick Narendran to become a committer and PMC
> member and we are pleased to announce that they have accepted.
>
> Karthick has contributed several bug fixes and quality improvements
> to Accumulo, has written blog posts for our website, has been very
> helpful in engaging users with questions on various issues, and
> has helped in testing and providing feedback on release candidates.
> We are happy to have them contributing to the Accumulo
> community!
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
> Being a PMC member enables assistance with the management
> and to guide the direction of the project.
>
> Welcome Karthick!
>

[DRAFT][ANNOUNCE] Apache Accumulo 2.0.1

[Billie Rinaldi]

The following is a DRAFT announcement for the 2.0.1 release. Please review
and provide feedback. I intend to publish this announcement on Dec 28.
*

The Apache Accumulo project is pleased to announce the release
of Apache Accumulo 2.0.1! Apache Accumulo 2.0.1 contains critical
bug fixes for 2.0.0. (See the release notes linked below for details.)

Since 2.0 is a non-LTM release line, and since an LTM release line
has not yet been made available for 2.x, this patch backports important
bug fixes to 2.0 that could affect any existing 2.0.0 users. Users that
have already migrated to 2.0.0 are urged to upgrade to 2.0.1 as soon
as possible, and users of 1.10 who wish to upgrade to 2.0 should
upgrade directly to 2.0.1, bypassing 2.0.0.

***

Apache Accumulo® is a sorted, distributed key/value store that
provides robust, scalable data storage and retrieval. With
Apache Accumulo, users can store and manage large data sets
across a cluster. Accumulo uses Apache Hadoop's HDFS to store
its data and Apache ZooKeeper for consensus.

This version is now available in Maven Central, and at:
https://accumulo.apache.org/downloads/

The full release notes can be viewed at:
https://accumulo.apache.org/release/accumulo-2.0.1/

--
The Apache Accumulo Team

[DRAFT][ANNOUNCE] Apache Accumulo 1.10.1

[Billie Rinaldi]

The following is a DRAFT announcement for the 1.10.1 release. Please review
and provide feedback. I intend to publish this announcement on Dec 28.
*

The Apache Accumulo project is pleased to announce the release
of Apache Accumulo 1.10.1! Apache Accumulo 1.10.1 is a bug fix
release of the 1.10 LTM release line. (See the release notes linked
below for details.)

Users of 1.10.0 or earlier are urged to upgrade to 1.10.1 as soon as
possible, as this is a continuation of the 1.10 LTM release line with
important bug fixes. Users are also encouraged to consider migrating
to a 2.x version when one that is suitable for their needs becomes
available.

***

Apache Accumulo® is a sorted, distributed key/value store that
provides robust, scalable data storage and retrieval. With
Apache Accumulo, users can store and manage large data sets
across a cluster. Accumulo uses Apache Hadoop's HDFS to store
its data and Apache ZooKeeper for consensus.

This version is now available in Maven Central, and at:
https://accumulo.apache.org/downloads/

The full release notes can be viewed at:
https://accumulo.apache.org/release/accumulo-1.10.1/

--
The Apache Accumulo Team

Re: [accumulo] branch rel/1.9.3 created (now 74afbab)

[Billie Rinaldi]

Yeah, I think I was trying to search for the tag in the GitHub UI, but I
had branches selected instead of tags. The branch search box says "Find or
create branch."

Billie

On Thu, Nov 19, 2020 at 1:35 PM Christopher  wrote:

> No problem. I was just a bit confused how it happened. I assumed you did
> something on the command-line, but I have no idea how it could happen in
> the UI.
> I see you created https://issues.apache.org/jira/browse/INFRA-21127
> Thanks!
>
> On Thu, Nov 19, 2020 at 12:45 PM Billie Rinaldi  wrote:
>
> > Oops, sorry about that. I must have clicked on the wrong thing in the
> UI. I
> > wonder if it's possible to disable creating branches through the UI ...
> >
> > Billie
> >
> > On Thu, Nov 19, 2020 at 12:06 PM Christopher 
> wrote:
> >
> > > Hi Billie, you seem to have unintentionally created a branch with the
> > same
> > > name as one of our tags (rel/1.9.3), but pointing to our current main
> > > branch's HEAD commit. I tried to delete it with `git push --delete
> > upstream
> > > refs/heads/rel/1.9.3` (the name is ambiguous, so you have to specify
> the
> > > full ref name), but it was rejected, because it matches a protected
> > branch
> > > name pattern, I guess.
> > >
> > > I think we'll need to put in an INFRA ticket to remove this branch.
> > >
> > >
> > > On Thu, Nov 19, 2020 at 10:37 AM  wrote:
> > >
> > > > This is an automated email from the ASF dual-hosted git repository.
> > > >
> > > > billie pushed a change to branch rel/1.9.3
> > > > in repository https://gitbox.apache.org/repos/asf/accumulo.git.
> > > >
> > > >
> > > >   at 74afbab  Fix warning and simplify ScannerBaseTest
> > > >
> > > > No new revisions were added by this update.
> > > >
> > > >
> > >
> >
>

Re: [accumulo] branch rel/1.9.3 created (now 74afbab)

[Billie Rinaldi]

Oops, sorry about that. I must have clicked on the wrong thing in the UI. I
wonder if it's possible to disable creating branches through the UI ...

Billie

On Thu, Nov 19, 2020 at 12:06 PM Christopher  wrote:

> Hi Billie, you seem to have unintentionally created a branch with the same
> name as one of our tags (rel/1.9.3), but pointing to our current main
> branch's HEAD commit. I tried to delete it with `git push --delete upstream
> refs/heads/rel/1.9.3` (the name is ambiguous, so you have to specify the
> full ref name), but it was rejected, because it matches a protected branch
> name pattern, I guess.
>
> I think we'll need to put in an INFRA ticket to remove this branch.
>
>
> On Thu, Nov 19, 2020 at 10:37 AM  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > billie pushed a change to branch rel/1.9.3
> > in repository https://gitbox.apache.org/repos/asf/accumulo.git.
> >
> >
> >   at 74afbab  Fix warning and simplify ScannerBaseTest
> >
> > No new revisions were added by this update.
> >
> >
>

Re: [LAZY][VOTE] change default branch to 'main'

[Billie Rinaldi]

On Mon, Aug 10, 2020, 5:48 PM Christopher  wrote:

> I believe this action is pretty much complete. I have updated the
> website to fix broken links/references to the old 'master' branches,
> and am working through the other repos for other, now broken,
> references to any master branch.
>

Thanks, Christopher!


> On Thu, Aug 6, 2020 at 8:01 AM Christopher  wrote:
> >
> > This decision passes unanimously.
> >
> > * I have prepared all 11 of our repos by creating a 'main' branch in
> > each one, based on their 'master' branch, and have updated all open
> > PRs whose base branch was 'master' to now be 'main'.
> > * I have also created an INFRA request
> > (https://issues.apache.org/jira/browse/INFRA-20647) to change the
> > default branch.
> > * After that action is completed by INFRA, I will double check the
> > 'master' branch in each repo to ensure all its commits are in 'main',
> > and will ensure there are no new PRs against any 'master' branch,
> > before deleting the old branches.
> > * After that, I will do a pass through our documentation/website to
> > ensure links aren't broken and that .asf.yaml is still correctly
> > configured to stage our website.
> >
> > What you can do to help is: update your local clones and your forks,
> > so that the 'master' branch is fully gone.
> >
> > You can update your local clones by doing:
> > git remote update --prune && git checkout -t upstream/main && git
> > branch -d master
> >
> > After the default branch is changed by INFRA, you can also do the
> > following if you wish:
> > git remote set-head upstream -a
> >
> > (Both of these lines assume "upstream" is the name of your upstream
> remote).
> >
> > It is also possible to delete your forked copies of the branch named
> > 'master'. Let me know if you need help with that.
> >
> > Thanks,
> > Christopher
> >
> > On Tue, Aug 4, 2020 at 7:21 PM Nathaniel Freeman 
> wrote:
> > >
> > > +1
> > >
> > > > On 3 Aug 2020, at 07:58, Christopher  wrote:
> > > >
> > > > p from our previous conversation on this issue, I have
> > > > already started a new branch named 'main' for my own future
> > > > contributions (that name because it appears to be the trending
> > > > alternative to 'master'), and for others who wish to use it as an
> > > > alternative to the current 'master' branch. I intend to discontinue
> > > > merging contributions (my own or others) to any 'master' branch owned
> > > > by the Accumulo PMC.
> > > >
> > > > In conjunction with that practice that I intend to follow, I would
> > > > like to propose the following as a lazy vote (by that, I mean I'm
> just
> > > > going to do it if nobody votes; if somebody objects, this turns into
> a
> > > > majority vote):
> > > >
> > > > 1. Submit an INFRA ticket to change the default branch to 'main' for
> > > > all our repos (I'll make sure one is created in each before then),
> and
> > > > 2. Update all our PRs against 'master' to be based on 'main'
> instead, and
> > > > 3. Delete the branch currently named 'master' (after the first two
> > > > steps and ensuring 'main' contains all of its commits)
> > > >
> > > > This effectively results in a rename
> > >
>

Re: [VOTE] "Manager" as new name for "master" service

[Billie Rinaldi]

+1

On Mon, Aug 3, 2020, 9:55 AM Christopher  wrote:

> Based on the feedback on
> https://github.com/apache/accumulo/issues/1638 , the following two
> names have taken a clear lead in popularity for the new name for the
> service currently known as "master": Manager and Coordinator. Of the
> two, "Manager" is more popular by a very narrow margin.
>
> Please vote on whether to accept "Manager" as the new name for the
> service currently known as "master" to work towards. Remember, we're
> only voting on a target name at this time, not a migration path,
> release plan, or any specific code changes. Those details can be
> worked out in future actions.
>
> My vote is +1
>
> This vote will end after Thu 06 Aug 2020 02:00:00 PM UTC
> (Thu 06 Aug 2020 10:00:00 AM EDT / Thu 06 Aug 2020 07:00:00 AM PDT)
>
> Thanks,
>
> Christopher
>

Re: [LAZY][VOTE] change default branch to 'main'

[Billie Rinaldi]

+1

On Mon, Aug 3, 2020, 7:58 AM Christopher  wrote:

> As a follow-up from our previous conversation on this issue, I have
> already started a new branch named 'main' for my own future
> contributions (that name because it appears to be the trending
> alternative to 'master'), and for others who wish to use it as an
> alternative to the current 'master' branch. I intend to discontinue
> merging contributions (my own or others) to any 'master' branch owned
> by the Accumulo PMC.
>
> In conjunction with that practice that I intend to follow, I would
> like to propose the following as a lazy vote (by that, I mean I'm just
> going to do it if nobody votes; if somebody objects, this turns into a
> majority vote):
>
> 1. Submit an INFRA ticket to change the default branch to 'main' for
> all our repos (I'll make sure one is created in each before then), and
> 2. Update all our PRs against 'master' to be based on 'main' instead, and
> 3. Delete the branch currently named 'master' (after the first two
> steps and ensuring 'main' contains all of its commits)
>
> This effectively results in a rename of our primary development
> branches. Upon completion of these steps, I would send an email
> reminder to update any forks or local clones.
>
> This vote will end after Thu 06 Aug 2020 12:00:00 PM UTC
> (Thu 06 Aug 2020 08:00:00 AM EDT / Thu 06 Aug 2020 05:00:00 AM PDT)
>
> Thanks,
> Christopher
>

[DISCUSS] Rename Accumulo master

[Billie Rinaldi]

Hi Accumulo folks! I would like to start a discussion about renaming the
Accumulo master. Previous discussions were held a few years ago [1]. Some
things have changed since we started that discussion, in the world and in
our project governance, so I think it is worth revisiting this topic.

If people agree that a rename would be worthwhile, we can start identifying
the many changes that would need to be made (probably a GitHub issue would
be a good place for that). This will be a big change and I am happy to help
work on it. If anyone else is interested in helping out too, I think we
should be able to break the work down into several discrete tasks.

I believe the best replacement names we came up with on the original ticket
were Coordinator and Conductor. I also wanted to suggest another
possibility that I don't think we considered: Admin / AdminServer. Admin is
generic, but at least it's short. Feel free to share your thoughts and
other ideas, if you have them.

Billie

[1]: https://issues.apache.org/jira/browse/ACCUMULO-2844

Re: New committer/PMC member: Arvind Shyamsundar

[Billie Rinaldi]

Welcome, Arvind! Thanks for your contributions.

Billie

On Thu, Apr 16, 2020 at 2:32 PM Keith Turner  wrote:

> The Apache Accumulo Project Management Committee (PMC) invited Arvind
> Shyamsundar to become a committer/PMC member and we are pleased to
> announce that he accepted.  Arvind has fixed multiple bugs in Accumulo
> recently and added support for running multiple tservers per node to
> the scripts.
>
> Welcome Arvind!
>

Re: Video chat this week

[Billie Rinaldi]

Sounds good to me!

Billie

On Tue, Mar 24, 2020 at 9:25 AM Keith Turner  wrote:

> Slack has a call feature, but I have never used it.  I can do 11 Wed
> or Thur this week.
>
> On Mon, Mar 23, 2020 at 10:14 PM Christopher  wrote:
> >
> > Accumulo Devs,
> >
> > I happen to have some extra time on my hands this week at home, and
> > thought it might be nice to set up a video meeting to chat with
> > anybody who might be interested in discussing Accumulo development.
> > This came up as part of the conversation on
> > https://github.com/apache/accumulo/pull/1568 , but we can discuss
> > anything.
> >
> > I'm most familiar with Google Hangouts, and 1100, New York time, is
> > probably the earliest I could do it... but I can also probably do
> > early afternoon or late evening. If somebody wants to set up using
> > another service, that's probably fine too, but I haven't really used
> > anything else.
>

Demopalooza

[Billie Rinaldi]

Hi Accumulo Folks,

We are excited to be hosting a Demopalooza event the evening of Tuesday,
February 11th at Jailbreak Brewing Company in Laurel, MD [1]. We currently
have 1.5 demos lined up and have room for a couple more, so contact Marc
and me if you are interested in sharing something. Hope to see you there!

Billie

[1]: https://www.eventbrite.com/e/demopalooza-tickets-91722395153

Re: Multiple instance volumes

[Billie Rinaldi]

I think it would be a good idea to have the PreferredVolumeChooser select
volumes during init. Looks like there is already an issue open for this:
https://github.com/apache/accumulo/issues/1373

I imagine you could move a table to a different volume by changing the
preferred volume configuration and then compacting the table. But as Keith
mentions in the issue, it would be easier if this weren't necessary.

Billie

On Tue, Nov 19, 2019, 3:45 PM karthick rn 
wrote:

> Hi,
>
> When provisioning multiple volumes, for ex. HDFS & Azure Data Lake storage,
> it would be good to choose which volume we want the system tables like
> metadata, root, replication tables to be created. Currently, Accumulo
> randomly creates these tables on multiple volumes and the only way to
> control this is to run Accumulo init on 1st volume so all system tables get
> created on this volume and then add the other volumes.
>
> I have also tried running 'config -t accumulo.metadata -s
> table.custom.volume.preferred=hdfs://accucluster/accumulo' in an attempt to
> move the metadata table to a preferred volume, in this case HDFS, but I
> don’t see metadata table under HDFS. Also, ‘config -f
> table.custom.volume.preferred’ does not show anything!
> In short, I was wondering if there is any provision to "move" these system
> tables across volumes, or is that a non-goal by design?
>
> Many thanks
>
> Regards,
> Karthick
>

Re: New committer/PMC member: Adam Lerman

[Billie Rinaldi]

Welcome, Adam!

On Wed, Aug 7, 2019 at 3:22 PM Christopher  wrote:

> Devs,
>
> The Project Management Committee (PMC) for Apache Accumulo
> has invited Adam Lerman to become a committer and we are pleased
> to announce that he has accepted.
>
> Adam has contributed several pull requests in the last year to enhance
> features in the accumulo-shell and the VolumeChooser in 1.9 and 2.0,
> as well as other user experience enhancements. Most recently, he
> worked with Keith Turner to incorporate some additional logging to
> help administrators find busy tablets causing hotspotting.
>
> Being a committer comes with write access to the Accumulo
> repositories, to accept code changes and merges from other
> contributors, and to merge their own contributions more easily. This
> should enable better productivity.
> Being a PMC member enables assistance with the management and
> direction of the project, such as binding votes for releases.
>
> Please join me in welcoming Adam!
>

Re: New committer/PMC member: Holly Keebler

[Billie Rinaldi]

Welcome, Holly!

On Fri, Aug 9, 2019 at 12:21 PM Christopher  wrote:

> Devs,
>
> The Project Management Committee (PMC) for Apache Accumulo
> has invited Holly Keebler to become a committer and we are pleased
> to announce that she has accepted.
>
> Holly started with contributions fixing some smaller issues, like
> removing a premature "Master is down" message from the monitor during
> startup, and making use of NewTableConfiguration in some ITs, to
> improve the quality of the tests for the 2.0.0 release. Not only has
> she continued making changes to fix smaller issues like those, but has
> since also moved on to significantly more complicated issues helping
> refactor the metadata internals for future Accumulo 2.1.x releases.
>
> Being a committer comes with write access to the Accumulo
> repositories, to accept code changes and merges from other
> contributors, and to merge their own contributions more easily. This
> should enable better productivity.
> Being a PMC member enables assistance with the management and
> direction of the project, such as binding votes for releases.
>
> Please join me in welcoming Holly!
>

Re: Export control disclaimer in README

[Billie Rinaldi]

The instructions say "PMCs considering including cryptographic
functionality within their products or specially designing their products
to use other software with cryptographic functionality should take the
following steps." It seems like we fall under the "specially designed"
category.

On Tue, Apr 3, 2018 at 8:58 AM, Mike Walch  wrote:

> The reason I asked this question is I don't see any crypto-related jars in
> the binay distribution of Accumulo
> and I don't think our source contains any cryptographic software. Does
> anyone know of any case where
> we include cryptographic software in the source or binary distribution?
>
> While Accumulo can be used with crypto libraries to encrypt data at rest,
> it looks like we don't distribute
> any cryptographic software so I would think the disclaimer could be
> removed.
>
> On Mon, Apr 2, 2018 at 6:06 PM, Mike Drob  wrote:
>
> > We need it for the crypto libraries used for encryption at rest stuff. If
> > you want to remove the disclaimer then you have to tear out those pieces
> as
> > well.
> >
> > Maybe this is not necessary any more with java 8 and changed default
> > security policies? Would be good to check with Apache Legal before making
> > changes.
> >
> > On Mon, Apr 2, 2018 at 10:01 PM, Mike Walch  wrote:
> >
> > > The Accumulo README.md[1] has an export control disclaimer. Does anyone
> > > know the reasoning for it? Would anyone be opposed if it was removed?
> > >
> > > [1]: https://github.com/apache/accumulo/blob/master/README.md
> > >
> >
>

Re: [VOTE] Accumulo 1.7.4-rc1

[Billie Rinaldi]

On Thu, Mar 22, 2018 at 2:31 PM, Christopher  wrote:

> Josh, I know you said you didn't have much time, but just in case you get a
> moment: do you know why `UserGroupInformation.isLoginKeytabBased()` might
> be false on the server side? This seems to be the root cause of the
> problems.
>

I recall running into HADOOP-10786 a while ago ("in java 8 isKeyTab is
always false given the current UGI implementation"). Not sure if that would
be relevant here.


>
> https://github.com/apache/accumulo/blob/b0016c3ca36e15ee4bdde727ea5b6a
> 18597de0ff/core/src/main/java/org/apache/accumulo/core/rpc/
> ThriftUtil.java#L383
>
>
> On Thu, Mar 22, 2018 at 4:00 PM Josh Elser  wrote:
>
> > I don't have the time to look at these right now. There isn't much
> > special about how Accumulo uses Kerberos either. It's straightforward
> > use via SASL with Thrift. I haven't looked at it since it was passing
> > when I wrote it originally.
> >
> > On 3/20/18 2:32 PM, Christopher wrote:
> > > I'm currently looking at the KerberosRenewalIT failures that seem to be
> > > persisting across branches. From the logs, it looks like the accumulo
> > > services are trying to do ticket-cache based login renewals, instead of
> > > keytab-based renewals. This has been a problematic test for me before,
> > > and as such, I've gotten into the habit of ignoring it, but since I've
> > > not been able to get it to work on reruns, and it fails nearly 100% of
> > > the time (if not 100%) for me now, I decided to take a closer look. If
> > > it is doing ticket-cache based renewals, that could indicate a bug in
> > > the Kerberos authentication, and that would probably warrant a -1 from
> > > me... but I will continue to investigate first.
> > >
> > > Josh, you know more about the Kerberos stuff than anyone here, so if
> you
> > > have time/interest, I wouldn't mind getting your feedback on why this
> > > test might be failing for me.
> > >
> > > On Mon, Mar 19, 2018 at 3:44 PM Christopher  > > > wrote:
> > >
> > > Accumulo Developers,
> > >
> > > Please consider the following candidate for Accumulo 1.7.4.
> > >
> > > Git Commit:
> > >  b2a59189108d736729432e81b3d5717000c6b891
> > > Branch:
> > >  1.7.4-rc1
> > >
> > > If this vote passes, a gpg-signed tag will be created using:
> > >  git tag -f -m 'Apache Accumulo 1.7.4' -s rel/1.7.4 \
> > >  b2a59189108d736729432e81b3d5717000c6b891
> > >
> > > Staging repo:
> > >
> > https://repository.apache.org/content/repositories/
> orgapacheaccumulo-1068
> > > Source (official release artifact):
> > >
> > https://repository.apache.org/content/repositories/
> orgapacheaccumulo-1068/org/apache/accumulo/accumulo/1.7.
> 4/accumulo-1.7.4-src.tar.gz
> > > Binary:
> > >
> > https://repository.apache.org/content/repositories/
> orgapacheaccumulo-1068/org/apache/accumulo/accumulo/1.7.
> 4/accumulo-1.7.4-bin.tar.gz
> > > (Append ".sha1", ".md5", or ".asc" to download the signature/hash
> > > for a given artifact.)
> > >
> > > All artifacts were built and staged with:
> > >  mvn release:prepare && mvn release:perform
> > >
> > > Signing keys are available at
> > https://www.apache.org/dist/accumulo/KEYS
> > > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> > >
> > > Release notes (in progress) can be found at:
> > > https://accumulo.apache.org/release/accumulo-1.7.4/
> > >
> > > Please vote one of:
> > > [ ] +1 - I have verified and accept...
> > > [ ] +0 - I have reservations, but not strong enough to vote
> > against...
> > > [ ] -1 - Because..., I do not accept...
> > > ... these artifacts as the 1.7.4 release of Apache Accumulo.
> > >
> > > This vote will remain open until at least Thu Mar 22 20:00:00 UTC
> > 2018
> > > (Thu Mar 22 16:00:00 EDT 2018 / Thu Mar 22 13:00:00 PDT 2018).
> > > Voting continues until the release manager sends an email closing
> > > the vote.
> > >
> > > Thanks!
> > >
> > > P.S. Hint: download the whole staging repo with
> > >  wget -erobots=off -r -l inf -np -nH \
> > >
> > https://repository.apache.org/content/repositories/
> orgapacheaccumulo-1068/
> > >  # note the trailing slash is needed
> > >
> >
>

Re: [DISCUSS] Remove tracer service (not instrumentation)

[Billie Rinaldi]

I am +0 for this proposal and agree that putting it in a separate repo
would be preferable to dropping it. I tend to think that a better eventual
home for the Accumulo span receiver would be in HTrace itself -- that would
solve a lot of our version compatibility issues. That said, I wanted to
mention a few things we should keep in mind during this process.
- The Accumulo span receiver and the tracing display in the monitor have
been tweaked to handle the volume of traces produced by HDFS. Specifically,
the span receiver is configured by default to drop spans of length 0ms, and
the monitor page is able to display children of those spans in a useful
way. I don't know how other tracing backends and UIs would deal with this.
- For systems that produce a large amount / high rate of tracing data,
Accumulo may be the only viable storage for traces.
- One advantage of Accumulo's tracing system is that it is on by default.

On Fri, Mar 16, 2018 at 2:09 PM, Christopher  wrote:

> Devs,
>
> (This discussion is somewhat of a spinoff of our previous recent
> conversation about HTrace, but I'd like to narrow the discussion to one
> specific topic regarding our tracer service.)
>
> I'd like to remove Accumulo's tracer service and corresponding
> presentations in the monitor for 2.0.
>
> The tracer service currently acts as a sink for the traces from Accumulo.
>
> While there is interest in tracing Accumulo, and Accumulo may itself be
> suitable (with the right schema) for storing traces, I do not think acting
> as a "trace sink" is really the kind of thing we should be doing as part of
> Accumulo's out-of-the-box core functionality.
>
> Also, the presentation and search capabilities of the traces found in the
> trace table (by convention, and assumed by the monitor) is far from an
> ideal presentation of this data, and I don't think the Accumulo project
> should continue maintaining that inside the core project's monitor, either.
>
> I think we should encourage interested volunteers to contribute to other
> trace presentation software (wherever they may exist) any necessary
> "backing store" implementation based on Accumulo.
>
> None of this would remove tracing instrumentation from Accumulo... it would
> just require users interested in trace data from Accumulo to configure an
> appropriate sink to collect that data in some other integrated component of
> their overall architecture.
>
> Decoupling the integrated trace sink from the instrumentation in Accumulo
> like this could even be a step towards providing support for multiple
> different tracing libraries. (I guess we could do this now, but it would be
> easier if we were not also trying to provide a sink implementation for one
> specific version of one specific instrumentation library.)
>
> Thoughts?
>

Re: Draft Board Report for Jan 2018

[Billie Rinaldi]

How about the Accumulo docker image?

On Fri, Jan 5, 2018 at 10:23 AM, Mike Walch  wrote:

> Could mention an Accumulo tour was created for the website
> https://accumulo.apache.org/tour/
>
> On Thu, Jan 4, 2018 at 8:38 PM, Michael Wall  wrote:
>
> > 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: Draft Board Report for Jul 2017

[Billie Rinaldi]

We should mention that the PMC approved the use of the Apache Accumulo
trademark for the 4th annual Accumulo Summit, to be held on October 16th,
2017 in Columbia, MD.

On Mon, Jul 10, 2017 at 5:38 AM, Michael Wall  wrote:

> 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, Jul 12 . Please let me know if you have any suggestions,
> I plan to submit on the 12th.
>
> 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.
>  - Since the last report, there has been a focus on documentation clean up
>and paying down some technical debt in our integration test suite.
>
> ## Health report:
>  - The project remains healthy.  Activity levels on mailing lists, git and
>JIRA remain constant.
>
> ## PMC changes:
>
>  - Currently 29 PMC members.
>  - No new PMC members added in the last 3 months.  We have invited a long
> time
>contributor to become both a committer and PMC member.
>  - Last PMC addition was Mike Walch on Wed Nov 02 2016.
>
> ## Committer base changes:
>
>  - Currently 29 committers.
>  - No new committers added in the last 3 months
>  - Last committer addition was Mike Walch at Thu Nov 03 2016
>
> ## Releases:
>
>  - Last release was 1.7.3 on Sat Mar 25 2017
>
> ## Mailing list activity:
>
>  - dev@accumulo.apache.org:
> - 232 subscribers (up 3 in the last 3 months):
> - 997 emails sent to list (1012 in previous quarter)
>
>  - notificati...@accumulo.apache.org:
> - 63 subscribers (down -2 in the last 3 months):
> - 573 emails sent to list (589 in previous quarter)
>
>  - u...@accumulo.apache.org:
> - 398 subscribers (up 1 in the last 3 months):
> - 107 emails sent to list (120 in previous quarter)
>
>
> ## JIRA activity:
>
>  - 57 JIRA tickets created in the last 3 months
>  - 52 JIRA tickets closed/resolved in the last 3 months
>

Re: [DISCUSS] any blockers on current release lines?

[Billie Rinaldi]

On Wed, Jun 14, 2017 at 5:10 AM, Michael Wall  wrote:

> I have one (https://issues.apache.org/jira/browse/ACCUMULO-4615) but it is
> not a blocker, so nevermind.
>
> Anyone jira savvy know what's up with the landing page for
> https://issues.apache.org/jira/projects/ACCUMULO.  For me, it goes to a
> kanban board Billie created for an Accumulo Hackathon in 2016.  I don't
> really care where the landing page page, I just think it shouldn't be some
> from 2016.
>

I noticed this with YARN as well; the default YARN page goes to some random
kanban board now. I guess they must have changed some default setting for
the entire JIRA. I am not sure which setting, so we'll have to look into it.


>
> On Tue, Jun 13, 2017 at 5:37 PM Michael Wall  wrote:
>
> > I've got one maybe two for 1.8, but right now jira seems funky.
> > https://issues.apache.org/jira/browse/ACCUMULO is going to some Accumulo
> > Hackathon 2016 kanban board.  Any know anything about that.  I'll look
> > again tonight and try to find those tickets
> >
> > I have been wanting to talk about the tickets in general and how many are
> > currently open.  Many haven't been looked at in some time and just get
> > moved from "next release" to "next release".  I'll wait until this
> > discussion is done though.
> >
> > On Tue, Jun 13, 2017 at 5:22 PM Christopher  wrote:
> >
> >> Usually such discussions are in the context of an anticipated release.
> Are
> >> you planning to champion a release soon? I'd be in favor of a
> maintenance
> >> release or two.
> >>
> >> On Tue, Jun 13, 2017 at 4:57 PM Sean Busbey 
> wrote:
> >>
> >> > Right, I believe we'd be pushing out any non-completed issues to a
> >> > future release. Presumably if any of those TODOs required waiting for
> >> > a release they'd be marked blocker, or someone here would have them in
> >> > mind?
> >> >
> >> > On Tue, Jun 13, 2017 at 12:45 PM, Christopher 
> >> wrote:
> >> > > Link to issues, by release branch:
> >> > >
> >> >
> >> https://issues.apache.org/jira/projects/ACCUMULO?
> selectedItem=com.atlassian.jira.jira-projects-plugin:release-page
> >> > >
> >> > > On Tue, Jun 13, 2017 at 3:09 PM Sean Busbey 
> >> wrote:
> >> > >
> >> > >> Here's how we're doing on lag for releases:
> >> > >>
> >> > >> * branch-1.7, last maintenance release March 25th 2017, 9 issues
> >> marked
> >> > >> done, no blockers
> >> > >> * branch-1.8, last maintenance release Feb 26th 2017, 14 issues
> >> marked
> >> > >> done, no blockers
> >> > >> * master, last minor release September 6th 2016, last major release
> >> May
> >> > >> 2014, 80 issues marked done, 3 things marked blocker
> >> > >>
> >> > >> Anyone know of any other blockers on releases right now?
> >> > >>
> >> > >> Folks have time for a discussion about wether or not we should keep
> >> > things
> >> > >> currently marked blocker as blocker?
> >> > >>
> >> >
> >> >
> >> >
> >> > --
> >> > busbey
> >> >
> >>
> >
>

Re: [DISCUSS] Remove ShellServlet

[Billie Rinaldi]

+1

On Thu, Mar 30, 2017 at 5:56 PM, Christopher  wrote:

> After reviewing Luis' code for ACCUMULO-3005 (at
> https://github.com/lstav/accumulo in his ACCUMULO-MONITOR branch), I took
> a
> look at the remaining servlet code which he has not migrated to the
> freemarker templates. In particular, ShellServlet.
>
> After some inspection, I've become even more convinced that we should get
> rid of ShellServlet in 2.0.0.
> I've created https://issues.apache.org/jira/browse/ACCUMULO-4617 where I
> list some reasons why we should do this.
>
> Feel free to discuss there or here.
>

[ANNOUNCE] New PMC Chair!

[Billie Rinaldi]

Dear Apache Accumulo Community,

The PMC has recently voted to adopt a new PMC Chair, Michael Wall.
Thanks for stepping up, Mike!

Re: [DISCUSS] Rethinking monitor log receiver

[Billie Rinaldi]

On Tue, Feb 7, 2017 at 8:40 AM, Christopher <ctubb...@apache.org> wrote:

> On Tue, Feb 7, 2017 at 11:02 AM Billie Rinaldi <billie.rina...@gmail.com>
> wrote:
>
> > I am a fan of the log-forwarding feature. I wouldn't mind if there were
> an
> > option to turn it off for users that don't want it. I also wouldn't mind
> if
> > someone wanted to improve how the log-forwarding mechanism is
> implemented.
> > Option (2) doesn't work for me, though. I need the log-forwarding
> > destination(s) to be discovered automatically rather than requiring it to
> > be known in advance / configured manually by the user.
> >
> >
> Using DNS (CNAME) for the monitor destination might be a better solution
> for auto-routing to the current monitor, rather than the auto-discovery
> happening inside Accumulo. The DNS solution won't work for random ports...
> but I'm not sure what the use is for a monitor that isn't served to a
> well-known location.


Past uses of auto-discovering a random port have been for running on YARN
and for ITs. I don't think this is necessary for YARN/Slider anymore.


> A custom appender which does the logic (rather than
> the standard socket appender, custom properties, and tserver logic) would
> also work, if the services are properly advertised.
>

I think a custom appender would be fine.


>
> What are your thoughts on these?
>
>
> > Seems like improving log forwarding is a separate (but related) issue
> from
> > whether we want to add the feature of supporting multiple monitors. To
> > implement that feature, we'd have to decide whether we'd want to forward
> to
> > all monitors, or just forward to the first monitor, or whatever. If we do
> > implement the multiple monitors feature, I think we should add a
> "Monitors"
> > tab to the monitor, so that users will be able to monitor their monitors.
> > :) (Seriously.)
> >
> >
> I'm leaning toward thinking that we shouldn't try to get into the business
> of supporting the logic of how many, and which ones, to forward to.
>
> From this discussion, I'm thinking:
>
> 1. Make the service discovery specifically for the log4j service, and make
> it optional. Turning off log4j service will also prevent registration in
> ZK. This would also make log4j an optional dependency of the monitor. When
> the feature is disabled, /log in the monitor will document that it is
> disabled.
>
2. Create a custom log4j appender which does the logic of looking up the
> advertised monitors, and decides whether to send to one or them all.
> 3. Disable all these by default with the example configs, but provide blog
> post explaining how to enable.
>

I'd prefer enabled by default. :)


>
> Does that sound reasonable?
>
>
> > On Mon, Feb 6, 2017 at 2:04 PM, Christopher <ctubb...@apache.org> wrote:
> >
> > > On Mon, Feb 6, 2017 at 12:15 PM Josh Elser <josh.el...@gmail.com>
> wrote:
> > >
> > > -1 for removal of the log-forwarding which does not include an
> > > out-of-the-box replacement. I'm going to avoid saying any more on this
> > > unless necessary.
> > >
> > >
> > > If we were to opt for removal (perhaps by agreeing that it were out of
> > > scope), I'd personally prefer it be phased out gradually, as users
> gained
> > > more experience integrating with superior tooling for distributed log
> > > aggregation. I think too many people rely on it right now to remove it
> > > abruptly.
> > >
> > >
> > > Most of the other things you bring up seem like you poking holes in how
> > > the log aggregation works presently. I don't think anyone would
> disagree
> > > that this could be made better. Instead of focusing on this, why not
> > > approach your issues by instead suggesting how you'd like to see it
> work
> > > and weigh the pros/cons?
> > >
> > >
> > > Yes, this discussion is about both whether, and how, we might be able
> to
> > > make it better. I haven't proposed a solution, because I don't have one
> > at
> > > this time. Hence, my desire to [DISCUSS] it.
> > >
> > >
> > > Christopher wrote:
> > > > Currently, the monitor has an HA-standby behavior as a side-effect of
> > the
> > > > way it handles logging.
> > > >
> > > > The way this works is that the other services read the monitor's lock
> > in
> > > ZK
> > > > to get the current active monitor's host and port. They use this to
> set
> > > > some system properties, which are referenced in 

Re: [DISCUSS] Rethinking monitor log receiver

[Billie Rinaldi]

I am a fan of the log-forwarding feature. I wouldn't mind if there were an
option to turn it off for users that don't want it. I also wouldn't mind if
someone wanted to improve how the log-forwarding mechanism is implemented.
Option (2) doesn't work for me, though. I need the log-forwarding
destination(s) to be discovered automatically rather than requiring it to
be known in advance / configured manually by the user.

Seems like improving log forwarding is a separate (but related) issue from
whether we want to add the feature of supporting multiple monitors. To
implement that feature, we'd have to decide whether we'd want to forward to
all monitors, or just forward to the first monitor, or whatever. If we do
implement the multiple monitors feature, I think we should add a "Monitors"
tab to the monitor, so that users will be able to monitor their monitors.
:) (Seriously.)

On Mon, Feb 6, 2017 at 2:04 PM, Christopher  wrote:

> On Mon, Feb 6, 2017 at 12:15 PM Josh Elser  wrote:
>
> -1 for removal of the log-forwarding which does not include an
> out-of-the-box replacement. I'm going to avoid saying any more on this
> unless necessary.
>
>
> If we were to opt for removal (perhaps by agreeing that it were out of
> scope), I'd personally prefer it be phased out gradually, as users gained
> more experience integrating with superior tooling for distributed log
> aggregation. I think too many people rely on it right now to remove it
> abruptly.
>
>
> Most of the other things you bring up seem like you poking holes in how
> the log aggregation works presently. I don't think anyone would disagree
> that this could be made better. Instead of focusing on this, why not
> approach your issues by instead suggesting how you'd like to see it work
> and weigh the pros/cons?
>
>
> Yes, this discussion is about both whether, and how, we might be able to
> make it better. I haven't proposed a solution, because I don't have one at
> this time. Hence, my desire to [DISCUSS] it.
>
>
> Christopher wrote:
> > Currently, the monitor has an HA-standby behavior as a side-effect of the
> > way it handles logging.
> >
> > The way this works is that the other services read the monitor's lock in
> ZK
> > to get the current active monitor's host and port. They use this to set
> > some system properties, which are referenced in the default example
> > generic_logger.xml config file. They set these system properties and
> reset
> > the log4j system whenever they detect a change in the active monitor.
> This
> > has the effect of forcing all the logging to go to a particular socket
> open
> > on the monitor, wherever it is currently running.
>
> If you'd like to change the implementation, great.
>
>
> Right. So, this is a discuss thread about how we might want to change it. I
> don't have a good sense about what avenues are going to cause headaches.
>
>
> As a point of reference, the Master's ZK lock is also used for service
> discovery as well as distributed exclusion (a lock). I'm not sure why
> you find an issue with this.
>
>
> I don't find an issue with it. I recognize it does both. I stated that. I
> also recognize that it must do both for certain services. My point was that
> only one of those aspects (service discovery), rather than both, was needed
> for the monitor service. The other aspect (distributed exclusion) is an
> unnecessary side-effect which cripples redundant monitors because of this
> (optional) log receiving feature.
>
>
> > The ZK lock is currently being used to restrict monitor functionality to
> a
> > single monitor instance. But, this isn't really necessary. There isn't
> any
> > reason to restrict concurrent monitors. The real purpose of the ZK lock,
> as
> > I've described, is to hijack the ZK lock mechanism because it's also a
> > service-advertisement feature.
>
> The use of the ZK lock is to prevent users from accessing an instance of
> the Monitor which is not actually receiving the forwarded logs from the
> server. It would be terrible if half of an Ops team saw no errors on the
> monitor they went to while the other half saw the real errors.
>
>
> Yes. One solution would be to limit the distributed exclusion to just the
> log feature (along with any relevant messages), and leave the rest of the
> redundant monitor functional.
>
>
> > This is a bit convoluted and makes a lot of assumptions, and has a lot of
> > issues. It is also could be impeding some possible avenues of
> > simplification under ACCUMULO-3005.
> >
> > 1. It locks us in to using Log4J (probably a specific range of versions).
> > 2. It sends logs across the network insecurely.
>
> These seem like implementation details to me.
>
>
> Yes, but it's an inherent problem with the asynchronous log appender, which
> speaks directly to its suitability for running a custom log receiver.
>
>
>
> > 3. It assumes that you only want a single monitor service running.
>
> Again, an incorrect assumption.
>
>
> It 

january 2017 board report draft

[Billie Rinaldi]

Hello all,

The Apache Accumulo PMC has decided to start drafting its quarterly board
reports on the dev list. Here is a draft of our report which is due on
Wednesday. Let me know if you have any suggestions!

Billie

--
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.

Summary
The project is active and there are no Board-level issues at this time.
We have made no new releases since the previous report and have
added two committers/PMC members. We forgot to mention in our last
report that our trademark registration for ACCUMULO in the US has
been granted! We also amicably resolved a trademark issue with the
GitHub organization "accumulo" [1].

Releases
There have been no new releases since the last report.
The latest release was version 1.6.6 on 9/18/2016.

Activity
The number of subscribers to the dev list and the user list has
decreased slightly. User list activity has increased slightly, while
activity for other mailing lists has decreased from the previous quarter.
Activity is still generally strong.

In the past 3 months, there have been 81 commits to the master branch
from 14 authors, 5 of whom are not yet committers.

We have not begun release planning for our next release, but have
63 of 122 issues resolved towards a 1.7.3 release, 31 issues resolved
for the 1.8 branch, and 58 issues resolved for the master (2.0) branch.

Community
Mike Miller was added as a committer and PMC member on 10/24/2016.
Mike Walch was added as a committer and PMC member on 11/3/2016.

Branding
We noticed that the "accumulo" organization on GitHub did not meet third
party branding guidelines. After we discussed this with the owners of the
organization, they transferred control of the organization to the Apache
Accumulo PMC and moved all third party repositories that had been
associated with the organization.

[1]: https://github.com/accumulo

Re: Wikisearch Updates

[Billie Rinaldi]

Exciting! :-)

On Thu, Dec 15, 2016 at 5:31 AM, Mike Miller  wrote:

> FYI Mike Walch and I pushed updates to the Accumulo-Wikisearch repo. It now
> compiles with 1.8.0 and the ingest part works.  I haven't gotten to the
> search part but hope to soon. I also got INFRA to turn on github
> notifications.
>
> https://github.com/apache/accumulo-wikisearch/
>

Re: Please remove me as a mailing list moderator

[Billie Rinaldi]

The ticket has been resolved!

On Wed, Dec 14, 2016 at 12:21 PM, Billie Rinaldi <billie.rina...@gmail.com>
wrote:

> No dice on HipChat. I created INFRA-13110.
>
> On Wed, Dec 14, 2016 at 10:49 AM, Josh Elser <josh.el...@gmail.com> wrote:
>
>> Hey Benson,
>>
>> Sorry about that. I saw the note that Billie sent to apmail -- it would
>> seem like this process is no longer working. Let me ping infra in hipchat
>> and see what they have to say.
>>
>> - Josh
>>
>>
>> Benson Margulies wrote:
>>
>>> I'm still getting mod email, could you all please take me off the mod
>>> list?
>>>
>>>
>

Re: Please remove me as a mailing list moderator

[Billie Rinaldi]

No dice on HipChat. I created INFRA-13110.

On Wed, Dec 14, 2016 at 10:49 AM, Josh Elser  wrote:

> Hey Benson,
>
> Sorry about that. I saw the note that Billie sent to apmail -- it would
> seem like this process is no longer working. Let me ping infra in hipchat
> and see what they have to say.
>
> - Josh
>
>
> Benson Margulies wrote:
>
>> I'm still getting mod email, could you all please take me off the mod
>> list?
>>
>>

Re: [DISCUSS] Official release dates / DOAP out-of-date

[Billie Rinaldi]

I prefer SVN dist date, but I know that isn't the easiest to come by ... I
recall approximating the date on a couple of occasions when i couldn't
figure it out readily. Another possibility is to use the archive,
https://archive.apache.org/dist/accumulo/, assuming that a release hits the
archive on approximately the same date that it is released to dist. Archive
is down sometimes, though.

Anyway, announce date would be fine too if we can't find a way to use the
actual distribution date.

On Tue, Sep 6, 2016 at 4:36 PM, Christopher  wrote:

> I noticed that there were a few missing releases in our DOAP file, and I
> also noticed lots of discrepancies between what's in JIRA as the release
> date, when the tag was created, when the announcement was made (and on
> which list), what the date was in reporter.apache.org, and what the date
> was in DOAP.
>
> There are 3 places we record the "official" release date:
>  * doap_Accumulo.rdf
>  * JIRA
>  * reporter.apache.org
>
> Reporter actually has a sync-to-JIRA feature (but it's off-by-one... I'm
> investigating that), and I'd like to just use that feature rather than try
> to manually keep things sync'd up there also, so that leaves just 2 places
> to update.
>
> There are several sources we can use for the "official" release date:
>  * SCM tag date
>  * Date uploaded to SVN dist
>  * Announce email date
>  * Vote date
>
> I don't like using the vote date, because that doesn't say when the release
> occurred, just when we agreed on what will comprise the release. SVN dist
> might technically be the best date to use, but it's a pain to track that
> down, and it typically precedes the announcement by at least 24 hours. I
> think I like announce date the best, but we actually forgot to announce on
> at least one occasion, and we sometimes announce on different lists (dev@
> user@ announce@).
>
> Even if they are wrong, I'd like to sync up these different locations, so
> they don't show different dates for a release... and I'd like to decide on
> a standard from now on, so we know what a date means, and it doesn't vary
> so much.
>

Re: New Committers/PMC members!

[Billie Rinaldi]

Welcome, Mike and Marc!

On Wed, Aug 31, 2016 at 7:58 AM, Josh Elser  wrote:

> Hiya folks,
>
> I wanted to take a moment to publicly announce some recent additions to
> the Apache Accumulo family (committers and PMC).
>
> We had Mike Wall join the ranks back in April (sorry for the delayed
> announcement!) and Marc Parisi has just joined us this week.
>
> Thank you both for your continued contributions to the project and we all
> look forward to working with you more!
>
> - Josh (on behalf of Apache Accumulo)
>

Re: [DISCUSS] Time for a 1.8.0 release?

[Billie Rinaldi]

On Thu, Aug 4, 2016 at 9:41 AM, Michael Wall  wrote:

> Sean,
>
> I'm interested.  How do I get granted more permissions?  I can't see the
> configuration you used, but I can launch a new build.
>

Mike, I have added you to the appropriate group. You should be able to log
in to Jenkins with your Apache account and view the job configurations now.


>
> Mike
>
> On Thu, Aug 4, 2016 at 12:24 PM, Sean Busbey  wrote:
>
> > On Wed, Aug 3, 2016 at 5:17 PM, Christopher  wrote:
> > > On Wed, Aug 3, 2016 at 5:47 PM Sean Busbey 
> wrote:
> > >
> > >> My understanding was that maintenance releases (aka double dot, e.g.
> > >> 1.7.2) had relaxed criteria because we expected the scope of changes
> > >> in them to be more limited. Even so, the release notes for 1.7.2,
> > >> 1.7.1, and 1.7.0 all claim the ITs passed.
> > >>
> > >>
> > > Even those releases have periodic IT failure.
> > >
> > >
> > >> Is there a reason we can't parallelize the ITs?
> > >
> > >
> > > We can. Eric's mrit effort was all intended towards that. But, that's
> not
> > > the same as CI passing. I don't know what it would take to parallelize
> > them
> > > in a CI server.
> > >
> > >
> > >> What's stopping
> > >> builds.a.o from running them? Specific requests from projects to asf
> > >> infra can get us resources if that's the problem.
> > >>
> > >>
> > > I spoke to infra in HipChat about this a a few weeks ago, and
> mentioned a
> > > few things which impact builds on ASF jenkins (builds.apache.org):
> > >
> > > 1. Accumulo has an excessive number of tests to run.
> > > 2. Build timeouts with Jenkins can abort builds.
> > > 3. Tests are timing sensitive, and are affected by VM/host
> configuration
> > > and contention with other concurrent builds from other projects.
> > > 4. Tests need lots of RAM and storage (at least 4GB RAM, but ideally no
> > > less than 16GB, and at least 6 GB for a workspace)
> > > 5. Tests need specialized system configuration, (increasing ulimits,
> > > optimizing kernel settings for swappiness, etc.)
> > >
> > > What we really need for reliable IT passing in CI, is exclusive use of
> > > dedicated, bare-metal beefy build machines, for 6+ hours per build x 4
> > > branches minimum, plus another 6+ hours for each pull request and other
> > > builds which skipITs, so we can get immediate feedback on unit tests
> and
> > > compilation errors.
> > >
> >
> > I took a first pass at a nightly (~once per 12 hours) job on asf build
> for
> > master and it did okay, considering that I haven't spent any time trying
> to
> > tune anything:
> >
> > https://builds.apache.org/job/Accumulo-master-IT/1/
> >
> > 2 hr 9 min, 7 failures out of 202 tests.
> >
> > I think we can do this; if anyone else is interested I'll start a new
> > thread
> > where we can discuss.
> >
> >
> >
> > --
> > busbey
> >
>

Re: Board report draft July 2016

[Billie Rinaldi]

Sounds good. I'll add something about the Accumulo Summit, and mention that
we might be retiring the 1.6 branch after the next release.

On Wed, Jul 13, 2016 at 8:24 AM, Michael Wall <mjw...@gmail.com> wrote:

> +1 from me
>
> You mention the Accumulo meetup, would it be worth mentioning that
> registration (http://accumulosummit.com) and a call for talks (
> http://accumulosummit.com/program/submit-talk/) is now open for the
> AccumuloSummit?
>
>
>
> On Wed, Jul 13, 2016 at 11:04 AM, Billie Rinaldi <billie.rina...@gmail.com
> >
> wrote:
>
> > I found one parenthetical mention of the idea of a 1.6.6 release, but
> don't
> > see any other discussion of this. Am I missing anything?
> >
> > On Wed, Jul 13, 2016 at 6:37 AM, Mike Drob <md...@mdrob.com> wrote:
> >
> > > Wasn't there also talk of a 1.6.x release coming?
> > >
> > > On Tue, Jul 12, 2016, 2:08 PM <dlmar...@comcast.net> wrote:
> > >
> > > > +1 LGTM.
> > > >
> > > > - Original Message -
> > > >
> > > > From: "Billie Rinaldi" <bil...@apache.org>
> > > > To: "Accumulo Dev List" <dev@accumulo.apache.org>
> > > > Sent: Tuesday, July 12, 2016 12:48:51 PM
> > > > Subject: Board report draft July 2016
> > > >
> > > > Hello Apache Accumulo community,
> > > >
> > > > The Apache Accumulo PMC has decided to start drafting our quarterly
> ASF
> > > > board reports in the dev community. The next board report is due
> > > tomorrow,
> > > > and our draft is included below. If you have any suggestions, let us
> > > know!
> > > >
> > > > Billie
> > > > ---
> > > >
> > > > 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.
> > > >
> > > > Summary
> > > > The project is active and there are no Board-level issues at this
> time.
> > > > We have made one new release since the previous report and have
> > > > not added any committers/PMC members.
> > > >
> > > > Releases
> > > > Version 1.7.2 was released on 6/20/2016.
> > > >
> > > > Activity
> > > > The number of subscribers to the user and dev lists has increased
> > > > slightly and mailing list / commit activity is up slightly over the
> > > > previous
> > > > quarter.
> > > >
> > > > In the past 3 months, there have been 211 commits to the master
> branch
> > > > from 13 authors, 4 of whom are not yet committers.
> > > >
> > > > Version 1.7.2 has been released and we are wrapping up a handful of
> > > > issues for the 1.8.0 release.
> > > >
> > > > Around 15 people attended an Accumulo meetup in San Jose, where
> > > > Josh Elser spoke about features that have been completed for 1.8.0
> > > > and Bill Slacum discussed how to build resilient applications on
> > > > Accumulo.
> > > >
> > > > Community
> > > > Michael Wall was added as a committer and PMC member on 4/11/2016.
> > > > No new committers or PMC members have been added since the last
> > > > report.
> > > >
> > > >
> > >
> >
>

Board report draft July 2016

[Billie Rinaldi]

Hello Apache Accumulo community,

The Apache Accumulo PMC has decided to start drafting our quarterly ASF
board reports in the dev community. The next board report is due tomorrow,
and our draft is included below. If you have any suggestions, let us know!

Billie
---

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.

Summary
The project is active and there are no Board-level issues at this time.
We have made one new release since the previous report and have
not added any committers/PMC members.

Releases
Version 1.7.2 was released on 6/20/2016.

Activity
The number of subscribers to the user and dev lists has increased
slightly and mailing list / commit activity is up slightly over the previous
quarter.

In the past 3 months, there have been 211 commits to the master branch
from 13 authors, 4 of whom are not yet committers.

Version 1.7.2 has been released and we are wrapping up a handful of
issues for the 1.8.0 release.

Around 15 people attended an Accumulo meetup in San Jose, where
Josh Elser spoke about features that have been completed for 1.8.0
and Bill Slacum discussed how to build resilient applications on
Accumulo.

Community
Michael Wall was added as a committer and PMC member on 4/11/2016.
No new committers or PMC members have been added since the last
report.

Re: [DISCUSS] Htrace4, Hadoop 2.7

[Billie Rinaldi]

I'm in favor of bumping our Hadoop version to 2.7. We are already on the
same htrace version as Hadoop 2.7. (The discussion in ACCUMULO-4171 is
relevant to Hadoop 2.8 and later.)

Billie

On Thu, Jul 7, 2016 at 2:20 PM, Christopher  wrote:

> Thinking about https://issues.apache.org/jira/browse/ACCUMULO-4171, I'm of
> the opinion that we should probably bump our Hadoop version to 2.7 and
> HTrace version to what Hadoop is using, to keep them in sync.
>
> Does anybody disagree?
>

Re: Bigger Jenkins

[Billie Rinaldi]

On Fri, Jun 3, 2016 at 6:20 PM, Chris Rigano 
wrote:

> How can I be dropped from this list?
>

To unsubscribe, send an email to dev-unsubscr...@accumulo.apache.org.

Billie


>
> Thanks,
>
> Chris
>
> On Fri, Jun 3, 2016 at 2:43 PM, Christopher  wrote:
>
> > Devs,
> >
> > I set up a slightly beefier Jenkins than the one Josh had running
> > (hopefully, it's big enough to have tests consistently pass). I don't
> have
> > much set up on it right now, just one job.
> >
> > Things to do:
> >
> > 1. create more jobs for various branches
> > 2. Determine appropriate scheduling
> > 3. figure out some convenient credential management stuff, so other
> > committers can update jobs
> > 4. set up notifications
> >
> > Things I've done:
> >
> > 1. Started Jenkins
> > 2. Installed Maven, java, git, LaTeX, g++, make
> > 3. Configured httpd as an SSL proxy (using LetsEncrypt certs)
> > 4. Watched a job called "Accumulo-1.6-ITs" fail or hang (my fault;
> hostname
> > issue) 4 times in a row.
> >
> > In the meantime, you can view the progress of the one job which currently
> > exists, by going to:
> > https://jenkins.revelc.net
> >
> > AWS specs: m4.xlarge (HVM, 16GB, 4xCPU, 32GB EBS-optimized general
> purpose
> > SSD)
> >
>
>
>
> --
>
> =
>
> Christopher P. Rigano
>
>
> WWGD? Namaste
>

Re: Jira/GitHub spam reduction thoughts

[Billie Rinaldi]

On Thu, May 26, 2016 at 5:19 PM, Christopher <ctubb...@apache.org> wrote:

> Billie, are you able to make this change, or should I file an INFRA ticket?
>

No, I don't have the karma, so you'll have to open an INFRA ticket. +1 for
the change, though.


>
> On Tue, May 24, 2016 at 4:10 PM Christopher <ctubb...@apache.org> wrote:
>
> > On Tue, May 24, 2016 at 10:46 AM Billie Rinaldi <
> billie.rina...@gmail.com>
> > wrote:
> >
> >> On Mon, May 23, 2016 at 9:43 PM, Christopher <ctubb...@apache.org>
> wrote:
> >>
> >> > Okay, so after all that work I did on
> >> > https://issues.apache.org/jira/browse/INFRA-11675 , we were able to
> get
> >> > the
> >> > duplicate messages on the notifications list to stop, which came from
> >> > comments on GitHub pull requests which also triggered emails about
> >> comments
> >> > from JIRA.
> >> >
> >> > However, it now appears that watchers are still getting these. While
> >> JIRA
> >> > is not sending notifications to the mailing list, it is sending it to
> >> > watchers, reporters, and assignees.
> >> >
> >> > I believe the relevant setting is "Work Logged On Issue":
> >> >
> >> >
> >>
> https://issues.apache.org/jira/plugins/servlet/project-config/ACCUMULO/notifications
> >> >
> >> > I think this is a recent thing. I don't recall ever getting extra
> emails
> >> > about work being logged on issues I was watching before. Was this
> >> related
> >> > to the switch from the Hadoop permissions model to the default
> >> permissions
> >> > model as part of the JIRA mitigation?
> >> >
> >>
> >> As far as I am aware, the notifications scheme was not changed due to
> JIRA
> >> spam. Yes, I think notification settings are one of things only INFRA
> can
> >> change. On the bright side, it appears we are on the "Accumulo
> >> Notifications Scheme," which makes it sound like it wouldn't be as hard
> to
> >> get custom changes for notifications as it is for permissions (INFRA
> >> really
> >> wants projects to use an existing permissions scheme). Are you
> suggesting
> >> we try to get watchers removed from the Work Logged On Issue
> >> notifications?
> >> What about the assignee and reporter?
> >>
> >>
> > Yes, I think all 3 should be removed. The only things publishing to the
> > worklog are things we already get notified of on the mailing list (git
> > commits and pull request activity, for example). It's only useful in the
> > timeline view of all the activity on the issue, retrospectively... it's
> not
> > really useful to be actively notified. (At least, that's true today... in
> > the future, people could start publishing other activity to the worklog
> > where we don't already have email notifications for, but I don't
> anticipate
> > that).
> >
> >
>

Accumulo Meetup in San Jose 6/27/16

[Billie Rinaldi]

Hello all,

We've gotten space for an Accumulo meetup at the San Jose Convention Center
on Monday June 27th, 6:00 - 8:00 pm.  Conference attendance is not
required.  Join us if you can!
http://www.meetup.com/Accumulo-Users-DC/events/231397927/

Also, if you are interested in speaking at this meetup, contact me off list.

Billie

Re: Jira/GitHub spam reduction thoughts

[Billie Rinaldi]

On Mon, May 23, 2016 at 9:43 PM, Christopher  wrote:

> Okay, so after all that work I did on
> https://issues.apache.org/jira/browse/INFRA-11675 , we were able to get
> the
> duplicate messages on the notifications list to stop, which came from
> comments on GitHub pull requests which also triggered emails about comments
> from JIRA.
>
> However, it now appears that watchers are still getting these. While JIRA
> is not sending notifications to the mailing list, it is sending it to
> watchers, reporters, and assignees.
>
> I believe the relevant setting is "Work Logged On Issue":
>
> https://issues.apache.org/jira/plugins/servlet/project-config/ACCUMULO/notifications
>
> I think this is a recent thing. I don't recall ever getting extra emails
> about work being logged on issues I was watching before. Was this related
> to the switch from the Hadoop permissions model to the default permissions
> model as part of the JIRA mitigation?
>

As far as I am aware, the notifications scheme was not changed due to JIRA
spam. Yes, I think notification settings are one of things only INFRA can
change. On the bright side, it appears we are on the "Accumulo
Notifications Scheme," which makes it sound like it wouldn't be as hard to
get custom changes for notifications as it is for permissions (INFRA really
wants projects to use an existing permissions scheme). Are you suggesting
we try to get watchers removed from the Work Logged On Issue notifications?
What about the assignee and reporter?


>
> Who can even edit these notification settings normally? Is that an
> INFRA-only thing? Is there any way we can get more control over configuring
> these notifications? I'd think the PMC should probably be able to do some
> self-service here, but as far as I can tell, it's pretty locked down, and
> it's actually getting pretty annoying.
>
> If we can't get a handle on these notifications, I have two options left:
>
> 1. We switch to "linkonly" instead of "worklog" (see INFRA-11675) for
> GitHub PR integration.
> 2. I get better at filtering my email.
>
> #1 makes me sad, because I like seeing the PR activity in the timeline with
> the comments on the "All" tab in JIRA.
> #2 doesn't solve anything for anybody else
>

Re: Accumulo folks at Hadoop Summit San Jose

[Billie Rinaldi]

I'll be there! I'm looking into getting space for an Accumulo meetup
(details TBD).

On Thu, May 19, 2016 at 11:01 AM, Josh Elser  wrote:

> Out of curiosity, are there going to be any Accumulo-folks at Hadoop
> Summit in San Jose, CA at the end of June?
>
> - Josh
>

Re: using Range.prefix

[Billie Rinaldi]

On Tue, May 3, 2016 at 6:55 AM, z11373  wrote:

> Hi,
> I have a table that contains following rows:
>
> 20160421_a484869 cf: [public]
> 20160421_f109973 cf: [public]
>
> And I have following code:
>
> Authorizations publicAuthz = new Authorizations("public");
> Scanner scanner = connector.createScanner(TABLE,
> publicAuthz);
> Text rowPrefix = new Text("20160421");
> Range range = Range.prefix(rowPrefix, new Text("cf"));
>

This usage of Range.prefix will find all the column families beginning with
"cf" in the "20160421" row.  To find rows with the given prefix, use
Range.prefix(rowPrefix).  You can add scanner.fetchColumnFamily to specify
which column family to fetch.


> scanner.setRange(range);
> for (Entry entry : scanner) {
> String key = entry.getKey().toString();
> System.out.println(key);
> }
>
>
> The loop is not entered, which is unexpected to me. If I comment the
> setRange code, then it'll print out both row ids. Can you tell me what I
> missed here?
>
> Thanks,
> Z
>
>
>
> --
> View this message in context:
> http://apache-accumulo.1065345.n5.nabble.com/using-Range-prefix-tp16835.html
> Sent from the Developers mailing list archive at Nabble.com.
>

Re: Can someone review the change I made to the project RDF before I push to asf-site

[Billie Rinaldi]

Sounds good.  Thanks, Mike!

On Thu, Apr 28, 2016 at 7:41 AM, Michael Wall <mjw...@gmail.com> wrote:

> Category link back to http.  Our doap appears correct at
> http://accumulo.apache.org/doap_Accumulo.rdf.  It is at least valid RDF,
>
> http://www.w3.org/RDF/Validator/rdfval?URI=http%3A%2F%2Faccumulo.apache.org%2Fdoap_Accumulo.rdf=Parse+URI%3A+_AND_GRAPH=PRINT_TRIPLES=PNG_EMBED
>
> Seems like there is a cronjob to update the project data stored at
> https://projects.apache.org/json/projects/accumulo.json.  If the crons are
> setup as shown in this file
>
> http://svn.apache.org/viewvc/comdev/projects.apache.org/STRUCTURE.txt?view=markup#l55
> ,
> the project data will be updated tonight.
>
> Mike
>
> On Thu, Apr 28, 2016 at 10:25 AM, Drew Farris <d...@apache.org> wrote:
>
> > It is unfortunate that the category list (linked from the doap guidelines
> > is 404:
> > https://projects.apache.org/categories.html
> >
> > There's also this - not sure if anyone's tried it.
> > https://maven.apache.org/plugins/maven-doap-plugin/
> >
> >
> > On Thu, Apr 28, 2016 at 10:23 AM Michael Wall <mjw...@gmail.com> wrote:
> >
> > > Ok, I'll fix it.  Should have read this before
> > > https://projects.apache.org/guidelines.html
> > >
> > > Just pushed with the https, not sure how long the current project doap
> > info
> > > is cached, but it doesn't seem to have updated yet.  Not sure if there
> is
> > > something else I need to do.
> > >
> > > Thanks
> > >
> > > On Thu, Apr 28, 2016 at 10:17 AM, Drew Farris <d...@apache.org> wrote:
> > >
> > > > Billie has it right - I missed this - I also believe it should be
> http,
> > > not
> > > > https for the rdf categories.
> > > >
> > > > On Thu, Apr 28, 2016 at 10:08 AM Billie Rinaldi <
> > > billie.rina...@gmail.com>
> > > > wrote:
> > > >
> > > > > I spot-checked four of the projects listed in the database
> category,
> > > and
> > > > > they all used http rather than https.  Did you see any examples
> that
> > > used
> > > > > https?  Since our category is already broken, I'd be okay with
> > pushing
> > > to
> > > > > see if it works, and if it doesn't then we could revert 0554092; or
> > we
> > > > > could just revert that now to match the other projects.  In any
> case,
> > > +1
> > > > > for 3154c1d.
> > > > >
> > > > > On Thu, Apr 28, 2016 at 5:24 AM, Michael Wall <mjw...@gmail.com>
> > > wrote:
> > > > >
> > > > > > I noticed our category was not parsing correctly at
> > > > > >
> > > > > > https://projects.apache.org/projects.html?category
> > > > > >
> > > > > > Search Accumulo.
> > > > > >
> > > > > > I updated it in the gh-pages branch with
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/accumulo/commit/3154c1dc1386850aa9bdcee27b71045bad01623b
> > > > > > and
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/accumulo/commit/0554092a5fe2b69bee0071130e69e9f42fa5ecde
> > > > > >
> > > > > > Can someone else review this before I push to the asf-site
> branch?
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Mike
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Can someone review the change I made to the project RDF before I push to asf-site

[Billie Rinaldi]

I spot-checked four of the projects listed in the database category, and
they all used http rather than https.  Did you see any examples that used
https?  Since our category is already broken, I'd be okay with pushing to
see if it works, and if it doesn't then we could revert 0554092; or we
could just revert that now to match the other projects.  In any case, +1
for 3154c1d.

On Thu, Apr 28, 2016 at 5:24 AM, Michael Wall  wrote:

> I noticed our category was not parsing correctly at
>
> https://projects.apache.org/projects.html?category
>
> Search Accumulo.
>
> I updated it in the gh-pages branch with
>
> https://github.com/apache/accumulo/commit/3154c1dc1386850aa9bdcee27b71045bad01623b
> and
>
> https://github.com/apache/accumulo/commit/0554092a5fe2b69bee0071130e69e9f42fa5ecde
>
> Can someone else review this before I push to the asf-site branch?
>
> Thanks
>
> Mike
>

Re: Pros and Cons of moving SKVI to public API

[Billie Rinaldi]

On Thu, Mar 24, 2016 at 1:15 PM, Christopher  wrote:

> We do have the opportunity to move to a new improved API, if somebody were
> to put time into it. I guess that's true whether we put this in the public
> API officially or not.


Agreed.  Even if we do create a new API, we can't change or drop the
existing API without breaking a lot of people's code.  I feel like SKVI is
in a category of things that we treat as though they're in the public API,
so we might as well say it is.


> I think maybe the hardest part is that we don't
> really want to put just the interface in the API... but it exists in a
> package with a bunch of other classes which probably shouldn't be public
> API. So, some thought needs to be put into *how* we're going to do it, too.
>
> On Thu, Mar 24, 2016 at 3:27 PM William Slacum  wrote:
>
> > It should be public API. It's one of the core reasons for choosing
> Accumulo
> > over a similar project like HBase or Cassandra. Allegedly, Jeff "Mean
> Gene"
> > Dean said we got the concept correct as well :)
> >
> > Personally I hate the current API from a usability standpoint (ie, the
> > generic types are useless and already encoded in the name, it needlessly
> > diverges from the standard java Iterator calling standards), but it's a
> > strong, identifying feature we have.
> >
> > On Thu, Mar 24, 2016 at 2:50 PM, Christopher 
> wrote:
> >
> > > Accumulators,
> > >
> > > What are the pros and cons that you can see for moving the
> > > SortedKeyValueIterator into the public API?
> > >
> > > Right now, I think there's still some need for improvement in the
> > Iterator
> > > API, and many of the iterators may not be stable enough to really
> > recommend
> > > people use without some serious caveats (because we may not be able to
> > keep
> > > their API stable very easily). So, there's a con.
> > >
> > > In the pros side, iterators are a core feature of Accumulo, and nearly
> > all
> > > of Accumulo's distributed processing capabilities are dependent upon
> > them.
> > > It is reasonable to expect users to take advantage of them, and we've
> at
> > > least tried to be cautious about changing the iterators in incompatible
> > > ways, even if they aren't in the public API.
> > >
> > > Recently, this came up when we stripped out all the non-public API
> > javadocs
> > > from the website. (reported by Dan Blum on the user list on March 4th:
> > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/accumulo-user/201603.mbox/%3C066a01d17658%24bc9dc1b0%2435d94510%24%40bbn.com%3E
> > > )
> > >
> > > What would it take for us to feel comfortable moving them to the public
> > > API? Do we need a better interface first, or should we isolate the
> other
> > > iterators into another package (some of that has already been done), or
> > > should we wait for a proper public API package (2.0?) to provide this
> > > interface in?
> > >
> >
>

Re: git-based site and jekyll

[Billie Rinaldi]

Wow, that's looking great.  Thanks, Christopher!

Billie

On Thu, Mar 10, 2016 at 10:38 PM, Christopher  wrote:

> Thanks Josh! I fixed all the issues you saw, except the screenshots one,
> since that's currently just how our layout is (looks the same at
> accumulo.apache.org).
>
> Most of the bugs you saw were existing bugs with either our HTML or our
> Markdown... but whatever CMS is doing is a bit more tolerant than Kramdown
> is apparently.
>
> Biggest problem I saw was that people keep forgetting quotes around HTML
> attributes. Example, it should be , not  href=location>.
>
> On Thu, Mar 10, 2016 at 9:57 PM Josh Elser  wrote:
>
> > * Some companies on http://ctubbsii.github.io/accumulo/people.html are
> > goofed as are the timezones.
> > * Some broken links on http://ctubbsii.github.io/accumulo/source.html.
> > Coding practices are also messed up.
> > * http://ctubbsii.github.io/accumulo/contrib.html contrib project
> > entries are a little wacky.
> > * http://ctubbsii.github.io/accumulo/screenshots.html is weird with the
> > monitor screenshot (should be beneath the text?)
> > * Just noticed that Other and Documentation both have a link to the
> > papers/presentations. That might actually be how the site is now, just
> > realized it's duplicative.
> >
> > Thanks again for doing this. It's great!
> >
> > Christopher wrote:
> > > Actually, I now have it all working (as far as I can tell) with
> > everything
> > > pretty much the same as it looks with CMS today. After people have
> taken
> > > the time to give it a glance, I'll push it to the ASF repo, and then
> push
> > > the generated site to a separate branch. Then we can put in the INFRA
> > > ticket to switch from svn to git.
> > >
> > > On Thu, Mar 10, 2016 at 6:42 PM Christopher
> wrote:
> > >
> > >> I'm working on converting our current site contents over to jekyll at
> > >> https://github.com/ctubbsii/accumulo/tree/gh-pages
> > >> (view at http://ctubbsii.github.io/accumulo)
> > >>
> > >> Yes, it's terrible right now... it's in progress. :)
> > >>
> > >> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser
> wrote:
> > >>
> > >>> Lazy consensus is fine. If there are no objections, I don't want to
> > hold
> > >>> things up. I feel like I've adequately expressed my concerns. Silence
> > >>> can and should be treated as acknowledgement for this, IMO.
> > >>>
> > >>> Christopher wrote:
> >  Another reason we probably shouldn't worry about this: anybody can
> > >>> create a
> >  DNS name at their leisure which transparently redirects to
> >  accumulo.apache.org and serves its contents. This is perfectly
> > >>> legitimate
> >  for a number of reasons, including corporate proxies/mirrors,
> >  URL-shortening services, caching services, archiving services,
> >  vision-impaired accessibility services, foreign-language DNS
> mappings,
> > >>> and
> >  so-on.
> > 
> >  I think when it comes to trademarks and our website, our area of
> > concern
> >  should mostly focus on when people misrepresent our trademark in the
> > >>> course
> >  of their mirroring/archiving. There's no risk of that for a mirror
> > that
> > >>> is
> >  explicitly under our control, but I'm really leaning towards the
> > >>> javascript
> >  to detect and display a message about the canonical location just to
> >  mitigate any possibility for concern.
> > 
> >  If you still have concerns, I'd be happy to put it up for a formal
> > vote
> >  from the PMC, or to get feedback from ASF trademarks folks before we
> >  proceed.
> > 
> >  On Tue, Mar 8, 2016 at 3:22 PM Josh Elser
> >  wrote:
> > 
> > > Well, I think the difference is that archive.org (and others --
> > google
> > > cached pages come to mind) are devoted/known for that specific
> > purpose.
> > > The fact that Github ends up being a "de-facto" location for
> software
> > > projects, I'm just nervous about the expecting good faith from the
> > > denizens of the internet. Maybe I'm just worrying too much. If
> > there's
> > > sufficient "it'll be ok" opinion coming from the PMC, it's fine by
> > me.
> > >
> > > Christopher wrote:
> > >> I can't imagine there's a trademark issue since it's really just
> > >>> acting
> > > as
> > >> a mirror. If there were trademark issues, I imagine sites like
> > >> http://archive.org would be in big trouble. But, it certainly
> > >>> couldn't
> > > hurt
> > >> to find out.
> > >>
> > >> Another option to sabotage the GH-rendered site is to add some
> > >>> javascript
> > >> which detects the location and displays an informative link back
> to
> > >>> the
> > >> canonical location for the site. That should be simple enough to
> do.
> > >>
> > >> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser
> > >>>   wrote:
> > 

Re: [DRAFT][ANNOUNCE] Apache Accumulo 1.7.1

[Billie Rinaldi]

+1

On Fri, Feb 26, 2016 at 11:53 AM, Christopher  wrote:

> The Accumulo team is proud to announce the release of Accumulo version
> 1.7.1!
>
> This release contains over 150 bugfixes and improvements over 1.7.0, and is
> backwards-compatible with 1.7.0. Existing users of 1.7.0 are encouraged to
> upgrade immediately.
>
> This version is now available in Maven Central, and at:
> https://accumulo.apache.org/downloads/
>
> The full release notes can be viewed at:
> https://accumulo.apache.org/release_notes/1.7.1.html
>
> 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, Apache
> ZooKeeper, and Apache Thrift.
>
> --
> The Apache Accumulo Team
>

Re: [VOTE] Accumulo 1.6.5-rc2

[Billie Rinaldi]

+1
verified signatures and checksums
verified licenses
verified tag and tarball contents
ran unit tests

On Fri, Feb 12, 2016 at 3:19 PM, Christopher  wrote:

> Accumulo Developers,
>
> Please consider the following candidate for Accumulo 1.6.5.
>
> Git Commit:
> c8ad82dbcd0994a37956a2be407de56ad26a562f
> Branch:
> 1.6.5-rc2
>
> If this vote passes, a gpg-signed tag will be created using:
> git tag -f -m 'Apache Accumulo 1.6.5' -s rel/1.6.5
> c8ad82dbcd0994a37956a2be407de56ad26a562f
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1048
> Source (official release artifact):
>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1048/org/apache/accumulo/accumulo/1.6.5/accumulo-1.6.5-src.tar.gz
> Binary:
>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1048/org/apache/accumulo/accumulo/1.6.5/accumulo-1.6.5-bin.tar.gz
> (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
> given artifact.)
>
> All artifacts were built and staged with:
> mvn release:prepare && mvn release:perform
>
> Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
>
> Release notes (in progress) can be found at:
> https://accumulo.apache.org/release_notes/1.6.5
>
> Please vote one of:
> [ ] +1 - I have verified and accept...
> [ ] +0 - I have reservations, but not strong enough to vote against...
> [ ] -1 - Because..., I do not accept...
> ... these artifacts as the 1.6.5 release of Apache Accumulo.
>
> This vote will end on Tue Feb 16 23:30:00 UTC 2016
> (Tue Feb 16 18:30:00 EST 2016 / Tue Feb 16 15:30:00 PST 2016)
>
> Thanks!
>
> P.S. Hint: download the whole staging repo with
> wget -erobots=off -r -l inf -np -nH \
>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1048/
> # note the trailing slash is needed
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>

new committers!

[Billie Rinaldi]

Join me in welcoming Dylan Hutchison and Russ Weeks as new Apache Accumulo
committers and PMC members!  Dylan and Russ, feel free to tell us about
yourselves and your development interests.

Billie

Re: scan command hung

[Billie Rinaldi]

Yes.  In this case, I would suggest configuring the column families that
have very few rows to be in a separate locality group.  You should be able
to do this in the shell with the command:
setgroups groupname=colf1,colf2,colf3 -t tablename

Here, groupname is an arbitrary name for the group; colf1, colf2, and colf3
are the column families with few rows; and tablename is the table name.
After you create the locality group, you will need to compact the table for
the change to take effect:
compact -t tablename -w

For each table, you can create multiple locality groups tailored to the
access patterns of your data.  There is some additional information about
locality groups in the user manual:
http://accumulo.apache.org/1.7/accumulo_user_manual.html#_locality_groups

On Mon, Oct 5, 2015 at 8:25 AM, z11373  wrote:

> Hi Josh,
> I see there are 4 tablet files for that table, and all of them are in range
> from 730MB to 860MB in size.
> For those column families that have problem, they are in 2 of those 4
> tablets.
> They are only a few rows, but for those column families which have no
> problem, they have millions of rows.
> This makes me thinking if the slowness because it has to find those 'few'
> rows among those 'gigantic' rows in that physical tablet file?
>
> Thanks,
> Z
>
>
>
> --
> View this message in context:
> http://apache-accumulo.1065345.n5.nabble.com/scan-command-hung-tp15286p15320.html
> Sent from the Developers mailing list archive at Nabble.com.
>

Re: [VOTE] Accumulo 1.6.4-rc1

[Billie Rinaldi]

+1 checked src and bin tarball, verified licenses, ran unit tests ... it
looks like the bloom filter and JQuery license info is in bin-LICENSE
twice, but that's not a big issue.

On Mon, Sep 28, 2015 at 9:07 PM, Josh Elser  wrote:

> Accumulo Developers,
>
> Please consider the following candidate for Accumulo 1.6.4.
>
> Git Commit:
> edba4f4ca95d9e8ec0299a631234e5c9a319f9ec
> Branch:
> 1.6.4-rc1
>
> If this vote passes, a gpg-signed tag will be created using:
> git tag -f -m 'Apache Accumulo 1.6.4' -s 1.6.4
> edba4f4ca95d9e8ec0299a631234e5c9a319f9ec
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1043
> Source (official release artifact):
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1043/org/apache/accumulo/accumulo/1.6.4/accumulo-1.6.4-src.tar.gz
> Binary:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1043/org/apache/accumulo/accumulo/1.6.4/accumulo-1.6.4-bin.tar.gz
> (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
> given artifact.)
>
> All artifacts were built and staged with:
> mvn release:prepare && mvn release:perform
>
> Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> (Expected fingerprint: ABC8914C675FAD3FA74F39B2D146D62CAB471AE9)
>
> Release notes have not yet been started, but the primary purpose for this
> release is to provide a 1.6 release for the bulk-load dataloss bug.
>
> Please vote one of:
> [ ] +1 - I have verified and accept...
> [ ] +0 - I have reservations, but not strong enough to vote against...
> [ ] -1 - Because..., I do not accept...
> ... these artifacts as the 1.6.4 release of Apache Accumulo.
>
> This vote will end on Fri Oct  2 04:30:00 UTC 2015
> (Fri Oct  2 00:30:00 EDT 2015 / Thu Oct  1 21:30:00 PDT 2015)
>
> Thanks!
>
> P.S. Hint: download the whole staging repo with
> wget -erobots=off -r -l inf -np -nH \
>
>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-orgapacheaccumulo-1043/
> # note the trailing slash is needed
>

Re: [VOTE] Accumulo 1.5.4-rc1

[Billie Rinaldi]

Agreed.

On Thu, Sep 10, 2015 at 9:47 AM, Christopher  wrote:

> I think the license issues are relatively small compared to the bugfixes,
> especially since we're really trying to close out 1.5.x development. So,
> given the options, I'd prefer to pass RC1, and make the license fixes in
> 1.6.x and later, as applicable.
>
> On Thu, Sep 10, 2015 at 12:28 PM Josh Elser  wrote:
>
> > Thanks again for taking the time to inspect things so thoroughly, Sean.
> >
> > Others who have already voted, I'd ask for your opinion on whether we
> > should sink this release (instead of me blindly going by majority rule).
> >
> > Personally, I'm presently of the opinion that, given the severity of the
> > bug(s) fixed in this release already, RC1 should pass. Considering that
> > we've been making releases like this for quite some time w/o issue and
> > 1.5 is all but dead, let's push this release out, (again) table 1.5 and
> > then make these improvements to 1.6 before we cut an RC there there when
> > we have time to thoroughly vet the changes (instead of the 11th hour of
> > a vote).
> >
> > If there's a need for lengthy discussion, let's break this off the VOTE
> > thread (I leave this message here for visibility).
> >
> > - Josh
> >
> > Sean Busbey wrote:
> > > -1
> > >
> > > * signatures check out
> > > * checksums match
> > > * licensing errors noted in ACCUMULO-3988
> > >
> > > On Sat, Sep 5, 2015 at 4:27 PM, Josh Elser  wrote:
> > >
> > >> Accumulo Developers,
> > >>
> > >> Please consider the following candidate for Accumulo 1.5.4.
> > >>
> > >> Git Commit:
> > >>  12a1041dcbb7f3b10543c305f27ece4b0d65ab9c
> > >> Branch:
> > >>  1.5.4-rc1
> > >>
> > >> If this vote passes, a gpg-signed tag will be created using:
> > >>  git tag -f -m 'Apache Accumulo 1.5.4' -s 1.5.4
> > >> 12a1041dcbb7f3b10543c305f27ece4b0d65ab9c
> > >>
> > >> Staging repo:
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1039
> > >> Source (official release artifact):
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1039/org/apache/accumulo/accumulo/1.5.4/accumulo-1.5.4-src.tar.gz
> > >> Binary:
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1039/org/apache/accumulo/accumulo/1.5.4/accumulo-1.5.4-bin.tar.gz
> > >> (Append ".sha1", ".md5", or ".asc" to download the signature/hash for
> a
> > >> given artifact.)
> > >>
> > >> All artifacts were built and staged with:
> > >>  mvn release:prepare&&  mvn release:perform
> > >>
> > >> Signing keys are available at
> https://www.apache.org/dist/accumulo/KEYS
> > >> (Expected fingerprint: ABC8914C675FAD3FA74F39B2D146D62CAB471AE9)
> > >>
> > >> Release notes (in progress) can be found at
> > >> https://accumulo.apache.org/release_notes/1.5.4
> > >>
> > >> Please vote one of:
> > >> [ ] +1 - I have verified and accept...
> > >> [ ] +0 - I have reservations, but not strong enough to vote against...
> > >> [ ] -1 - Because..., I do not accept...
> > >> ... these artifacts as the 1.5.4 release of Apache Accumulo.
> > >>
> > >> This vote will end on Thurs Sep  10 23:00:00 UTC 2015
> > >> (Thurs Sep  10 20:00:00 EDT 2015 / Thurs Sep  10 17:00:00 PDT 2015)
> > >>
> > >> Thanks!
> > >>
> > >> P.S. Hint: download the whole staging repo with
> > >>  wget -erobots=off -r -l inf -np -nH \
> > >>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1039/
> > >>  # note the trailing slash is needed
> > >>
> > >
> > >
> > >
> >
>

Re: [VOTE] Accumulo 1.5.4-rc1

[Billie Rinaldi]

+1
test/src/test/java/org/apache/accumulo/test/DeleteRowsTest.java has a
botched license header, but I wouldn't consider that a blocker since most
of it is intact.  Otherwise the licenses look good, the tarball contents
look good, and the source tarball matches the git branch.  I verified the
checksums and signatures, built from source and ran mvn verify.

On Sat, Sep 5, 2015 at 2:27 PM, Josh Elser  wrote:

> Accumulo Developers,
>
> Please consider the following candidate for Accumulo 1.5.4.
>
> Git Commit:
> 12a1041dcbb7f3b10543c305f27ece4b0d65ab9c
> Branch:
> 1.5.4-rc1
>
> If this vote passes, a gpg-signed tag will be created using:
> git tag -f -m 'Apache Accumulo 1.5.4' -s 1.5.4
> 12a1041dcbb7f3b10543c305f27ece4b0d65ab9c
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1039
> Source (official release artifact):
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1039/org/apache/accumulo/accumulo/1.5.4/accumulo-1.5.4-src.tar.gz
> Binary:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1039/org/apache/accumulo/accumulo/1.5.4/accumulo-1.5.4-bin.tar.gz
> (Append ".sha1", ".md5", or ".asc" to download the signature/hash for a
> given artifact.)
>
> All artifacts were built and staged with:
> mvn release:prepare && mvn release:perform
>
> Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> (Expected fingerprint: ABC8914C675FAD3FA74F39B2D146D62CAB471AE9)
>
> Release notes (in progress) can be found at
> https://accumulo.apache.org/release_notes/1.5.4
>
> Please vote one of:
> [ ] +1 - I have verified and accept...
> [ ] +0 - I have reservations, but not strong enough to vote against...
> [ ] -1 - Because..., I do not accept...
> ... these artifacts as the 1.5.4 release of Apache Accumulo.
>
> This vote will end on Thurs Sep  10 23:00:00 UTC 2015
> (Thurs Sep  10 20:00:00 EDT 2015 / Thurs Sep  10 17:00:00 PDT 2015)
>
> Thanks!
>
> P.S. Hint: download the whole staging repo with
> wget -erobots=off -r -l inf -np -nH \
>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1039/
> # note the trailing slash is needed
>

Re: [VOTE] Accumulo 1.6.3-rc2

[Billie Rinaldi]

+1

verified tarball matches tag
verified hashes and signatures
ran unit tests and most ITs
verified license headers

On Mon, Jun 29, 2015 at 1:31 PM, Christopher ctubb...@apache.org wrote:

 Accumulo Developers,

 Please consider the following candidate for Accumulo 1.6.3.

 Git Commit:
 741f4b3ea8c6f153606b322282fa302c14cf6fd9
 Branch:
 1.6.3-rc2

 If this vote passes, a gpg-signed tag will be created using:
 git tag -f -m 'Apache Accumulo 1.6.3' -s 1.6.3
 741f4b3ea8c6f153606b322282fa302c14cf6fd9

 Staging repo:
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1038
 Source (official release artifact):

 https://repository.apache.org/content/repositories/orgapacheaccumulo-1038/org/apache/accumulo/accumulo/1.6.3/accumulo-1.6.3-src.tar.gz
 Binary:
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1038/org/apache/accumulo/accumulo/1.6.3/accumulo-1.6.3-bin.tar.gz
 (Append .sha1, .md5, or .asc to download the signature/hash for
 a given artifact.)

 All artifacts were built and staged with:
 mvn release:prepare  mvn release:perform

 Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
 (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)

 Release notes (in progress) can be found at
 https://accumulo.apache.org/release_notes/1.6.3

 Please vote one of:
 [ ] +1 - I have verified and accept...
 [ ] +0 - I have reservations, but not strong enough to vote against...
 [ ] -1 - Because..., I do not accept...
 ... these artifacts as the 1.6.3 release of Apache Accumulo.

 This vote will end on Thu Jul  2 21:00:00 UTC 2015
 (Thu Jul  2 17:00:00 EDT 2015 / Thu Jul  2 14:00:00 PDT 2015)

 Thanks!

 P.S. Hint: download the whole staging repo with
 wget -erobots=off -r -l inf -np -nH \

 https://repository.apache.org/content/repositories/orgapacheaccumulo-1038/
 # note the trailing slash is needed



 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

Re: [VOTE] Accumulo 1.5.3-rc1

[Billie Rinaldi]

+1
verified tarball matches tag
verified hashes and signatures
ran mvn verify with hadoop 1 and hadoop 2 profile
verified license headers and license and notice are correct

On Wed, Jun 17, 2015 at 4:12 PM, Christopher ctubb...@apache.org wrote:

 Accumulo Developers,

 Please consider the following candidate for Accumulo 1.5.3.

 Git Commit:
 9009d4897800a6a85e6a35297f9dd9880415a187
 Branch:
 1.5.3-rc1

 If this vote passes, a gpg-signed tag will be created using:
 git tag -f -m 'Apache Accumulo 1.5.3' -s 1.5.3
 9009d4897800a6a85e6a35297f9dd9880415a187

 Staging repo:
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1036
 Source (official release artifact):

 https://repository.apache.org/content/repositories/orgapacheaccumulo-1036/org/apache/accumulo/accumulo/1.5.3/accumulo-1.5.3-src.tar.gz
 Binary:
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1036/org/apache/accumulo/accumulo/1.5.3/accumulo-1.5.3-bin.tar.gz
 (Append .sha1, .md5, or .asc to download the signature/hash for
 a given artifact.)

 All artifacts were built and staged with:
 mvn release:prepare  mvn release:perform

 Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
 (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)

 Release notes (in progress) can be found at
 https://accumulo.apache.org/release_notes/1.5.3

 Please vote one of:
 [ ] +1 - I have verified and accept...
 [ ] +0 - I have reservations, but not strong enough to vote against...
 [ ] -1 - Because..., I do not accept...
 ... these artifacts as the 1.5.3 release of Apache Accumulo.

 This vote will end on Sat Jun 20 23:30:00 UTC 2015
 (Sat Jun 20 19:30:00 EDT 2015 / Sat Jun 20 16:30:00 PDT 2015)

 Thanks!

 P.S. Hint: download the whole staging repo with
 wget -erobots=off -r -l inf -np -nH \

 https://repository.apache.org/content/repositories/orgapacheaccumulo-1036/
 # note the trailing slash is needed


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

Accumulo Meetup in San Jose 6/11

[Billie Rinaldi]

Hello all,

Is anyone attending the Hadoop Summit in San Jose, or going to be in the
Bay Area next week?  There will be an Accumulo meetup on Thursday, June 11
at 4:00 pm.  Conference attendance is not required.  Hope to see some of
you there!

http://www.meetup.com/Hadoop-Summit-Community-San-Jose/events/222467421/

Billie

Re: New committers!

[Billie Rinaldi]

Welcome! =)
On May 15, 2015 4:48 PM, Josh Elser els...@apache.org wrote:

 I'd like to extend an official welcome to both Sean Hickey and Ed Coleman
 as Apache Accumulo committers!

 The Apache Accumulo PMC recently voted to add both Sean and Ed as
 committers (and PMC members) in acknowledgement of their contributions to
 the project.

 Please give them a hearty welcome!

 - Josh

Re: New committer: Vikram

[Billie Rinaldi]

Welcome! =)
On May 15, 2015 5:09 PM, Sean Busbey bus...@cloudera.com wrote:

 Hi Accumulo!

 The Apache Accumulo PMC recently voted in Vikram Srivastava as a committer
 and PMC in cognition of his past contributions to the project.

 Please give him a good welcome. Vikram, feel free to give everyone a brief
 introduction on yourself and your interests.


 --
 Sean

Re: [jira] [Resolved] (ACCUMULO-3809) Table problem report has bogus table name for user table

[Billie Rinaldi]

I mentioned us on INFRA-9646.  Hopefully they'll just resolve the issue for
all projects.

On Thu, May 14, 2015 at 8:41 AM, Josh Elser josh.el...@gmail.com wrote:

 FYI, for those that haven't yet noticed, something changed in JIRA this
 week that alters the default Resolved state from Fixed to Pending
 Close. Keep an alert eye.

 I've seen some other projects start filing infra tickets about switching
 it back. We may eventually want to do the same.


  Original Message 
 Subject: [jira] [Resolved] (ACCUMULO-3809) Table problem report has bogus
 table name for user table
 Date: Thu, 14 May 2015 13:15:59 + (UTC)
 From: Eric Newton (JIRA) j...@apache.org
 Reply-To: j...@apache.org
 To: notificati...@accumulo.apache.org


  [
 https://issues.apache.org/jira/browse/ACCUMULO-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

 Eric Newton resolved ACCUMULO-3809.
 ---
 Resolution: Pending Closed
   Assignee: Eric Newton

  Table problem report has bogus table name for user table
 

 Key: ACCUMULO-3809
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3809
 Project: Accumulo
  Issue Type: Bug
  Components: monitor
Reporter: Josh Elser
Assignee: Eric Newton
Priority: Minor
 Fix For: 1.8.0, 1.7.1

  Time Spent: 0.5h
  Remaining Estimate: 0h

 {noformat}
 %28ID%3A3et%3B6%3B5%29  FILE_READ   172.18.128.21   2015/05/12
 14:28:38 PDT hdfs://cn020:8020/accumulo/tables/3et/t-00036x1/F00036or.rf
  Could not obtain block:
 BP-794412849-172.18.128.20-1430953890459:blk_1074098046_357320
 file=/accumulo/tables/3et/t-00036x1/F00036or.rf  clear this problem
 {noformat}
 The first element should be a table name but instead appears to be the
 extent for the tablet. Maybe we're just not unwrapping it properly all of
 the time?




 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)

Re: Review Request 32986: ACCUMULO-3715 Decrease sampling percentage for tracing

[Billie Rinaldi]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32986/
---

(Updated April 9, 2015, 3:57 p.m.)


Review request for accumulo, Eric Newton and Josh Elser.


Changes
---

This updated patch contains all the previous changes and also makes some 
modifications to the ShowTrace servlet and TraceDump to handle unrooted spans 
better (since they are now considered normal).  I've kept all the sampling 
configuration because I think it could still be useful, even though just 
dropping 0ms spans is sufficient to get tracing down to a reasonable amount.  
Also TraceDump's main method appears to have been broken since 2012, so I tried 
to fix that.


Repository: accumulo


Description
---

Make sampling of traces configurable; clean up and standardize config 
parameters; update documentation


Diffs (updated)
-

  core/src/main/java/org/apache/accumulo/core/conf/Property.java 9dceb1e 
  core/src/main/java/org/apache/accumulo/core/trace/DistributedTrace.java 
c5b6eac 
  core/src/main/java/org/apache/accumulo/core/trace/ProbabilitySampler.java 
PRE-CREATION 
  docs/src/main/asciidoc/chapters/administration.txt 0382934 
  server/gc/src/main/java/org/apache/accumulo/gc/SimpleGarbageCollector.java 
04f21a1 
  
server/master/src/main/java/org/apache/accumulo/master/replication/ReplicationDriver.java
 63c6b20 
  
server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/trace/ShowTrace.java
 4e05b89 
  server/tracer/src/main/java/org/apache/accumulo/tracer/AsyncSpanReceiver.java 
dbcb335 
  server/tracer/src/main/java/org/apache/accumulo/tracer/TraceDump.java e4eb70e 
  server/tracer/src/main/java/org/apache/accumulo/tracer/TraceTableStats.java 
PRE-CREATION 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/replication/AccumuloReplicaSystem.java
 cb8ae13 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/MinorCompactionTask.java
 0f6a98d 
  server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Tablet.java 
43bd9d9 

Diff: https://reviews.apache.org/r/32986/diff/


Testing
---


Thanks,

Billie Rinaldi

Re: Review Request 32986: ACCUMULO-3715 Decrease sampling percentage for tracing

[Billie Rinaldi]

 On April 9, 2015, 3 a.m., Mike Drob wrote:
  core/src/main/java/org/apache/accumulo/core/conf/Property.java, line 385
  https://reviews.apache.org/r/32986/diff/1/?file=921041#file921041line385
 
  If this property name changes, should we provide some level of support 
  for the old name?

I introduced this property in 1.7.  When I came back to it, I found it 
confusing because trace.span.receiver. properties are passed down automatically 
to the span receiver, but this path property is read in DistributedTrace and 
translated to trace.span.receiver.tracer.zookeeper.path when passed to the span 
receiver.  I figured I should either change its name to 
trace.span.receiver.tracer.zookeeper.path so it would not need special 
handling, or remove it from the t.s.r. naming convention so it's clear that it 
is handled specially.


- Billie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32986/#review79472
---


On April 9, 2015, 3:57 p.m., Billie Rinaldi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32986/
 ---
 
 (Updated April 9, 2015, 3:57 p.m.)
 
 
 Review request for accumulo, Eric Newton and Josh Elser.
 
 
 Repository: accumulo
 
 
 Description
 ---
 
 Make sampling of traces configurable; clean up and standardize config 
 parameters; update documentation
 
 
 Diffs
 -
 
   core/src/main/java/org/apache/accumulo/core/conf/Property.java 9dceb1e 
   core/src/main/java/org/apache/accumulo/core/trace/DistributedTrace.java 
 c5b6eac 
   core/src/main/java/org/apache/accumulo/core/trace/ProbabilitySampler.java 
 PRE-CREATION 
   docs/src/main/asciidoc/chapters/administration.txt 0382934 
   server/gc/src/main/java/org/apache/accumulo/gc/SimpleGarbageCollector.java 
 04f21a1 
   
 server/master/src/main/java/org/apache/accumulo/master/replication/ReplicationDriver.java
  63c6b20 
   
 server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/trace/ShowTrace.java
  4e05b89 
   
 server/tracer/src/main/java/org/apache/accumulo/tracer/AsyncSpanReceiver.java 
 dbcb335 
   server/tracer/src/main/java/org/apache/accumulo/tracer/TraceDump.java 
 e4eb70e 
   server/tracer/src/main/java/org/apache/accumulo/tracer/TraceTableStats.java 
 PRE-CREATION 
   
 server/tserver/src/main/java/org/apache/accumulo/tserver/replication/AccumuloReplicaSystem.java
  cb8ae13 
   
 server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/MinorCompactionTask.java
  0f6a98d 
   server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Tablet.java 
 43bd9d9 
 
 Diff: https://reviews.apache.org/r/32986/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Billie Rinaldi
 

Re: Review Request 32986: ACCUMULO-3715 Decrease sampling percentage for tracing

[Billie Rinaldi]

I am going to experiment with leaving out the sampling and only dropping
0ms spans to see if that is a sufficient solution.  Feel free to hold off
on further review until I post the results.

On Wed, Apr 8, 2015 at 8:00 PM, Mike Drob md...@mdrob.com wrote:


 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32986/#review79472
 ---



 core/src/main/java/org/apache/accumulo/core/conf/Property.java
 https://reviews.apache.org/r/32986/#comment128875

 If this property name changes, should we provide some level of support
 for the old name?


 - Mike Drob


 On April 8, 2015, 7:41 p.m., Billie Rinaldi wrote:
 
  ---
  This is an automatically generated e-mail. To reply, visit:
  https://reviews.apache.org/r/32986/
  ---
 
  (Updated April 8, 2015, 7:41 p.m.)
 
 
  Review request for accumulo, Eric Newton and Josh Elser.
 
 
  Repository: accumulo
 
 
  Description
  ---
 
  Make sampling of traces configurable; clean up and standardize config
 parameters; update documentation
 
 
  Diffs
  -
 
core/src/main/java/org/apache/accumulo/core/conf/Property.java 9dceb1e
 
  core/src/main/java/org/apache/accumulo/core/trace/DistributedTrace.java
 c5b6eac
 
  core/src/main/java/org/apache/accumulo/core/trace/ProbabilitySampler.java
 PRE-CREATION
docs/src/main/asciidoc/chapters/administration.txt 0382934
 
  server/gc/src/main/java/org/apache/accumulo/gc/SimpleGarbageCollector.java
 04f21a1
 
  
 server/master/src/main/java/org/apache/accumulo/master/replication/ReplicationDriver.java
 63c6b20
 
  server/tracer/src/main/java/org/apache/accumulo/tracer/AsyncSpanReceiver.java
 dbcb335
 
  server/tracer/src/main/java/org/apache/accumulo/tracer/TraceTableStats.java
 PRE-CREATION
 
  
 server/tserver/src/main/java/org/apache/accumulo/tserver/replication/AccumuloReplicaSystem.java
 cb8ae13
 
  
 server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/MinorCompactionTask.java
 0f6a98d
 
  server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Tablet.java
 43bd9d9
 
  Diff: https://reviews.apache.org/r/32986/diff/
 
 
  Testing
  ---
 
 
  Thanks,
 
  Billie Rinaldi
 
 

Review Request 32986: ACCUMULO-3715 Decrease sampling percentage for tracing

[Billie Rinaldi]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32986/
---

Review request for accumulo, Eric Newton and Josh Elser.


Repository: accumulo


Description
---

Make sampling of traces configurable; clean up and standardize config 
parameters; update documentation


Diffs
-

  core/src/main/java/org/apache/accumulo/core/conf/Property.java 9dceb1e 
  core/src/main/java/org/apache/accumulo/core/trace/DistributedTrace.java 
c5b6eac 
  core/src/main/java/org/apache/accumulo/core/trace/ProbabilitySampler.java 
PRE-CREATION 
  docs/src/main/asciidoc/chapters/administration.txt 0382934 
  server/gc/src/main/java/org/apache/accumulo/gc/SimpleGarbageCollector.java 
04f21a1 
  
server/master/src/main/java/org/apache/accumulo/master/replication/ReplicationDriver.java
 63c6b20 
  server/tracer/src/main/java/org/apache/accumulo/tracer/AsyncSpanReceiver.java 
dbcb335 
  server/tracer/src/main/java/org/apache/accumulo/tracer/TraceTableStats.java 
PRE-CREATION 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/replication/AccumuloReplicaSystem.java
 cb8ae13 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/MinorCompactionTask.java
 0f6a98d 
  server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Tablet.java 
43bd9d9 

Diff: https://reviews.apache.org/r/32986/diff/


Testing
---


Thanks,

Billie Rinaldi

Re: MockAccumulo with MiniMRCluster

[Billie Rinaldi]

You might be able to do this by using
AccumuloInputFormat/AccumuloOutputFormat.setMockInstance instead of
setZooKeeperInstance.  If you want to see some examples, look for usages of
setMockInstance in
core/src/test/java/org/apache/accumulo/core/client/mapreduce/.

On Mon, Apr 6, 2015 at 5:59 AM, Vincent Russell vincent.russ...@gmail.com
wrote:

 Does anyone have any suggestions or maybe a solution for getting MapReduce
 to work with the MiniMRCluster and MockAccumulo (Maybe some type of
 client/server solution with thrift and zookeeper?).  I am already using the
 MiniDFSCluster and MiniMRCluster and I just don't want to add the
 MiniAccumuloCluster to the mix in terms of memory consumption for my
 integration tests.


 Thanks,
 Vincent

ApacheCon North America April 13-17, 2015

[Billie Rinaldi]

From Rich Bowen:

Dear Apache Accumulo enthusiast,

In just a few weeks, we'll be holding ApacheCon in Austin, Texas, and we'd
love to have you in attendance. You can save $300 on admission by
registering NOW, since the early bird price ends on the 21st.

Register at http://s.apache.org/acna2015-reg

ApacheCon this year celebrates the 20th birthday of the Apache HTTP Server,
and we'll have Brian Behlendorf, who started this whole thing, keynoting
for us, and you'll have a chance to meet some of the original Apache Group,
who will be there to celebrate with us.

We've got 7 tracks of great talks, as well as BOFs, the Apache BarCamp,
project-specific hack events, and evening events where you can deepen your
connection with the larger Apache community. See the full schedule at
http://apacheconna2015.sched.org/

And if you have any questions, comments, or just want to hang out with us
before and during the event, follow us on Twitter - @apachecon - or drop by
#apachecon on the Freenode IRC network.

Hope to see you in Austin!

Re: More jenkins results

[Billie Rinaldi]

I've added the address to the allow list for notifications.  There appears
to be some secondary check that prevents the mail from getting through
since it's not from apache.org.  I don't know if there is another whitelist
beyond the allow list that moderators can control.

On Fri, Mar 20, 2015 at 1:45 PM, Christopher ctubb...@apache.org wrote:

 So, I don't think you'd have to use your ASF password unless you
 wanted to send using the ASF SMTP. That may not be necessary, unless
 the mailing lists check the origin to prevent spam, or something
 (would probably need to check with INFRA for info on that). The From
 line is not actually part of the SMTP protocol itself, so you should
 be able to just tell Jenkins to use anything. If there is a check in
 place, I *think* all you'd really need to do is subscribe to the list
 with the email address you wish to use, and ensure that the MX record
 is properly set up for your domain.

 Best thing to do is probably to create an INFRA ticket explaining what
 you're trying to do (with the from address you want to use and host
 you are trying to send from) and see if they can just whitelist the
 address.

 FWIW, I did see your test message from els...@apache.org to the
 notifcations list...

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Fri, Mar 20, 2015 at 2:24 PM, Josh Elser josh.el...@gmail.com wrote:
  I do not want to configure my server to do that, as it would require me
 to
  share my ASF password there. I haven't spent enough time to convince
 myself
  that it's secure enough to do that.
 
  If you can find why exactly it isn't working (I can't even mail from
  els...@apache.org), I'm all ears. I've just spent too much time already
 (in
  addition to wasting some of Billie's) to continue trying to figure out
 why.
 
 
  Christopher wrote:
 
  I'm not a fan of putting it on the dev@ list. There must be a way to
  add the email to a whitelist. Or... can you configure Jenkins to just
  send as your from address as elserj-bui...@apache.org?
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
 
  On Fri, Mar 20, 2015 at 1:21 PM, Josh Elserjosh.el...@gmail.com
 wrote:
 
  So, posts to notifications@ requires an apache.org email addr. I've
 lost
  interest in trying to make it work any further.
 
  Are people interested in getting the notifications to this list
  (dev@a.a.o)
  instead of notifications@? I figure most people probably use filters
 of
  some
  form to move things around anyways.
 
  LMK, I won't set this up without a general ack from everyone since it
  would
  increase the traffic here dramatically.
 
 
  Josh Elser wrote:
 
  Update on this: I had worked with Billie and little bit to try to get
  ezmlm to accept message from my server (as it's not subscribed through
  normal means).
 
  We haven't figured it out yet, but we're both a bit swamped this week.
  Hopefully we'll get it figured out eventually.
 
  Meanwhile, 1.6 ITs were blue last night and we only have 7 test
 failures
  on master!
 
  (big ty to Christopher and Eric as they helped those numbers)
 
  Josh Elser wrote:
 
  Frak.
 
  Realized that I need to make sure ezmlm accepts the emails I send
 from
  my server...
 
  Josh Elser wrote:
 
  Ugh, brain didn't catch up beforeenter  was hit.
 
  Send me a ping if you'd like to have control to configure the
 Accumulo
  jobs and I can add an account for you.
 
  Christopher, I'll send you an email shortly with your credentials
  since
  you brought up this discussion.
 
  Josh Elser wrote:
 
  Ok, I figured out how to do jenkins roles so that I can limit
 things
  down to a specific set of jobs.
 
  I'll change my nightly 1.6 and master branch IT jobs to send to
  notifications@ and we can go from there. I won't duplicate normal
 UT
  jobs from apache jenkins.
 
  Mike Drob wrote:
 
  If it goes to notifications@ that is inherently a noisy list and
 I'm
  not
  worried about Josh taking a week off and a nightly build failing
 and
  sending an email.
 
  Christopher, would a set of keys held in escrow cover your
 concerns?
 
  Josh, thanks for doing this and keeping it running on your own
 dime.
  A
  real
  mensch!
  On Mar 13, 2015 2:43 PM, Christopherctubb...@apache.org
 wrote:
 
  I'm not suggesting to impose external control. I just think it'd
 be
  nice to know that, if the worst were to happen, and the service
  started behaving badly while you were on vacation, we'd have some
  recourse to control the automated notices to the email lists.
 
  [ If you do get hit by a truck, I *will* call you out on it ;) ]
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
 
  On Fri, Mar 13, 2015 at 3:32 PM, Josh Elserjosh.el...@gmail.com
 
  wrote:
 
  If I wasn't clear the first time, anyone can view the results
  right
  now.
 
  I'm still not sure why you feel the need to impose external
  control
  over
 
  a
 
  system that I'm paying for and offering to provide as a service
 to
  the
  project. Unless 

Re: [VOTE] Establishing a contrib repo for upgrade testing

[Billie Rinaldi]

+1
On Mar 10, 2015 2:48 AM, Sean Busbey bus...@cloudera.com wrote:

 Hi Accumulo!

 This is the VOTE thread following our DISCUSS thread on establishing a new
 contrib for upgrade testing. For more details, please see the prior DISCUSS
 thread on this topic[1].

 Cloudera has recently made public some code used for doing correctness
 testing for Accumulo installations across upgrades[2]. The project contains
 simple data load and verification tools as well as a rudimentary upgrade
 test automation script. Cloudera would like to donate this code to the ASF
 and use it as a starting place for a contrib repository focused on testing
 Accumulo across versions generally.

 Upon passage of this vote, the Accumulo PMC will adopt this repo as a code
 base for the new project contrib accumulo-upgrade-tests subject to the
 ASF IP clearance process[3].

 Either as a part of the IP clearance process or immediately thereafter the
 repo's docs, artifacts, and packages will be updated to make use of ASF
 releases ad naming conventions rather than vendor specific materials.

 I (Sean Busbey) have volunteered to shepherd the paperwork in the IP
 clearance process, handle the updates to ASF releases, and serve as
 component lead for a new Jira component to cover the contrib.

 Note that as a contrib repository, the artifacts from this repo will be
 versioned independently from the primary Accumulo codebase. While this repo
 seeks to be useful for testing across Accumulo releases, this proposal does
 not establish any requirement for its use on release candidates of the
 primary codebase.

 Per our bylaws, this vote will require consensus approval (at least 3
 binding +1 votes and no binding vetoes). Though only PMC votes are binding,
 all community members are encouraged to vote.

 The vote will remain open until 0700 GMT Tuesday March 17 2015 (0300 EDT).

 Please vote one of:

 [ ] +1: Establish the 'accumulo-upgrade-tests' contrib by adopting the
 codebase as described
 [ ] -1: Do not adopt the codebase because ...


 [1]: http://s.apache.org/MsR
 [2]: https://github.com/cloudera/accumulo-upgrade-test/
 [3]: http://incubator.apache.org/ip-clearance/

 --
 Sean

Re: Re: data Versions

[Billie Rinaldi]

Yes, it should work with the WholeRowIterator.

On Wed, Feb 25, 2015 at 5:05 PM, panqing...@163.com panqing...@163.com
wrote:

 HI
Once the configuration of this place, but I use WholeRowIterator query,
 there will be multiple data



 panqing...@163.com

 From: Billie Rinaldi-2 [via Apache Accumulo]
 Date: 2015-02-25 23:35
 To: panqing...@163.com
 Subject: Re: data Versions
 Here is an example of how to configure the number of versions:

 http://accumulo.apache.org/1.6/accumulo_user_manual.html#_versioning_iterators_and_timestamps
 If you want to age off data, here is an example (note there's a typo; the
 example says it deletes after 30 seconds, but it is set to 3 seconds):
 http://accumulo.apache.org/1.6/accumulo_user_manual.html#_filters

 On Tue, Feb 24, 2015 at 11:03 PM, [hidden email] [hidden email]
 wrote:

  Hi
 
  
 
 http://apache-accumulo.1065345.n5.nabble.com/file/n13350/QQ%E5%9B%BE%E7%89%8720150225150133.png
  
   I found an article on the Internet, the number can be configured data
  version, but what should be configured?
 
 
 
  --
  View this message in context:
 
 http://apache-accumulo.1065345.n5.nabble.com/data-Versions-tp12997p13350.html
  Sent from the Developers mailing list archive at Nabble.com.
 




 If you reply to this email, your message will be added to the discussion
 below:

 http://apache-accumulo.1065345.n5.nabble.com/data-Versions-tp12997p13351.html
 To unsubscribe from data Versions, click here.
 NAML




 --
 View this message in context:
 http://apache-accumulo.1065345.n5.nabble.com/data-Versions-tp12997p13352.html
 Sent from the Developers mailing list archive at Nabble.com.

Re: data Versions

[Billie Rinaldi]

Here is an example of how to configure the number of versions:
http://accumulo.apache.org/1.6/accumulo_user_manual.html#_versioning_iterators_and_timestamps
If you want to age off data, here is an example (note there's a typo; the
example says it deletes after 30 seconds, but it is set to 3 seconds):
http://accumulo.apache.org/1.6/accumulo_user_manual.html#_filters

On Tue, Feb 24, 2015 at 11:03 PM, panqing...@163.com panqing...@163.com
wrote:

 Hi

 
 http://apache-accumulo.1065345.n5.nabble.com/file/n13350/QQ%E5%9B%BE%E7%89%8720150225150133.png
 
  I found an article on the Internet, the number can be configured data
 version, but what should be configured?



 --
 View this message in context:
 http://apache-accumulo.1065345.n5.nabble.com/data-Versions-tp12997p13350.html
 Sent from the Developers mailing list archive at Nabble.com.

Re: Deploying Accumulo with Slider View Ambari 1.7 Question

[Billie Rinaldi]

Moving this to the Slider dev list.  I am not seeing the cause of the error
in the AM log.  The Accumulo master process keeps failing to start, so
there may be a configuration problem.  Would you be able to track down logs
for one of the failed Accumulo master containers to see what they say?

On Tue, Jan 27, 2015 at 6:08 AM, Avellanet, Tatiana (HP Technology Center) 
tatiana.avella...@hp.com wrote:

  Good morning:



 My name is Tatiana Avellanet and I worked for Hewlett-Packard Technology
 Center in Puerto Rico. I have been trying to deploy Accumulo using Slider
 View in Ambari 1.7 unsuccessfully for some time. I am using package in
 http://public-repo-1.hortonworks.com/HDP/centos6/2.x/GA/2.2.0.0/slider-app-packages/accumulo/slider-accumulo-app-package-1.6.1.2.2.0.0-2041.zip.
 I create the /user/yarn folder in hdfs and assigned rights to yarn user.
 Then I proceed to the Slider View interface and select Create App, then
 select ACCUMULO as the application type and used accumulo as the name with
 all defaults configurations and then create the application:









 The application goes from Accepted to Running and then after about 10
 minute it fails with error:



 Unstable Application Instance : - failed with component ACCUMULO_MASTER
 failing 6 times (0 in startup); threshold is 5 - last failure: Failure
 container_1422305155071_0001_01_14 on host ambariServer: http://
 ambariServer:19888/jobhistory/logs/
 ambariServer:45454/container_1422305155071_0001_01_14/ctx/yarn



 Attached is the slider-out.txt log from Yarn. I can successfully deploy
 storm using this same environment but Accumulo keeps failing. This is a
 small cluster, with only 3 nodes (all of them are NodeManagers and Slider
 Clients).



 I can’t figure out what is wrong. Can you help me with this?



 Thanks,



 *Tatiana Avellanet*

 Software Designer V

 ESSN SC PuertoRico - Hewlett-Packard Company

 Tel. : 1 787 658 4039

 email : tatiana.avella...@hp.com

 Hwy 110 North KM 5.1, Bld 1 Aguadilla, PR 00603

Re: Google analytics summaries

[Billie Rinaldi]

Sounds good to me.
On Dec 11, 2014 11:15 AM, Sean Busbey bus...@cloudera.com wrote:

 I just got the mail summary of our google analytics stats for
 accumulo.apache.org.

 Anyone opposed to me starting to forward the summary email to dev@accumulo
 ?
 It contains summary info like visitor count, countries, bounce rate, etc.

 I figure it's an easy starting point to make more of our community stats
 accessible.

 --
 Sean

Re: Official Guidance to users regarding removal of functions

[Billie Rinaldi]

To clarify John's question: if our vote to adopt semver 2.0.0 passes, our
intention will be to no longer have breaking public API changes unless the
major version number is incremented, i.e. 1.x.x - 2.x.x. An important
aspect of semantic versioning is defining what is considered part of the
public API. So if there are things you need to remain consistent that are
not covered by Section 9 of the README, we should discuss adding them.
Actually, strengthening what we consider to be the public API is likely to
be a separate conversation in which (I hope) we will engage the user list.
On Dec 11, 2014 11:51 AM, John Vines vi...@apache.org wrote:

 Wouldn't this be resolved with our SemVer sqwitch?

 On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MITLL 
 kep...@ll.mit.edu wrote:

  When we remove functions, do we have any official guidance to our users
  who may have built applications that use those functions?
 
  Right now, the official position is that the Accumulo developers can
  remove based on a consensus vote. However, this provides no guidance to
  users as to what they are suppose to do? As it stands, our guidance is
 that
  they have the following choices:
 
  (0) Diligently watch the Accumulo e-mail list and aggressively weigh in
 on
  any vote to remove functions that may impact them.
 
  (1) Find someone to modify the original source code of their
 applications,
  build it, and *re-verify* the application. I emphasise the re-verify
  because that is usually the most costly part of the process that often
  won't get approved by management.
 
  (2) Don't upgrade Accumulo.
 

Re: Official Guidance to users regarding removal of functions

[Billie Rinaldi]

Actually, I wasn't suggesting anything.  I was providing elaboration on
what John was referring to.  I imagine that stronger API guarantees will be
cold comfort in the face of a 1.0 - 2.0 upgrade.  However, if we had been
using semver all along, there would have been much less pain for users in
the 1.x series.  Also, adopting semver would mean that going from 1.6 to a
hypothetical 1.7 would not suffer from the same upgrade issues.  I doubt
that we could retroactively mitigate the differences in minor versions,
though, so going from 1.3/1.4/1.5 to 1.7 would still be hard.

On Thu, Dec 11, 2014 at 9:11 AM, Mike Drob mad...@cloudera.com wrote:

 Billie,

 Not to be glib, but it reads like your suggestion to Jeremy for when we
 have a 2.0.0 release (assuming semver passes) is to take option (2) Don't
 upgrade Accumulo.

 Please correct my misunderstanding.

 Mike

 On Thu, Dec 11, 2014 at 11:07 AM, Billie Rinaldi bil...@apache.org
 wrote:

  To clarify John's question: if our vote to adopt semver 2.0.0 passes, our
  intention will be to no longer have breaking public API changes unless
 the
  major version number is incremented, i.e. 1.x.x - 2.x.x. An important
  aspect of semantic versioning is defining what is considered part of the
  public API. So if there are things you need to remain consistent that are
  not covered by Section 9 of the README, we should discuss adding them.
  Actually, strengthening what we consider to be the public API is likely
 to
  be a separate conversation in which (I hope) we will engage the user
 list.
  On Dec 11, 2014 11:51 AM, John Vines vi...@apache.org wrote:
 
   Wouldn't this be resolved with our SemVer sqwitch?
  
   On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MITLL 
   kep...@ll.mit.edu wrote:
  
When we remove functions, do we have any official guidance to our
 users
who may have built applications that use those functions?
   
Right now, the official position is that the Accumulo developers can
remove based on a consensus vote. However, this provides no guidance
 to
users as to what they are suppose to do? As it stands, our guidance
 is
   that
they have the following choices:
   
(0) Diligently watch the Accumulo e-mail list and aggressively weigh
 in
   on
any vote to remove functions that may impact them.
   
(1) Find someone to modify the original source code of their
   applications,
build it, and *re-verify* the application. I emphasise the re-verify
because that is usually the most costly part of the process that
 often
won't get approved by management.
   
(2) Don't upgrade Accumulo.
   
  
 

[VOTE] adoption of semver

[Billie Rinaldi]

I would like to call a vote on adopting semantic versioning (
http://semver.org/) for future releases.

This vote is subject to majority approval and will remain open for 72 hours.

+1: Adopt semantic versioning for all future releases
+0: Don't care
-1: Do not adopt semantic versioning because ...

Here is my +1.

Billie

Re: [VOTE] adoption of semver

[Billie Rinaldi]

On Tue, Dec 9, 2014 at 11:22 AM, Sean Busbey bus...@cloudera.com wrote:

 +0

 Just for clarification, this vote isn't defining what the semver applies
 to? I presume that means the same things already covered in Section 9 API
 from the README[1]?

 [1]:

 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob;f=README;h=a9f4645186c6431a0b68d115c7a92d18753c36f1;hb=HEAD


The vote applies to whatever we determine to be the public API, which is
currently defined in Section 9 of the README.



 On Tue, Dec 9, 2014 at 1:07 PM, John Vines vi...@apache.org wrote:

  +1
 
  On Tue, Dec 9, 2014 at 1:30 PM, Keith Turner ke...@deenlo.com wrote:
 
   +1
  
   On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi bil...@apache.org
  wrote:
  
I would like to call a vote on adopting semantic versioning (
http://semver.org/) for future releases.
   
This vote is subject to majority approval and will remain open for 72
hours.
   
+1: Adopt semantic versioning for all future releases
+0: Don't care
-1: Do not adopt semantic versioning because ...
   
Here is my +1.
   
Billie
   
  
 



 --
 Sean

Re: Review Request 27106: ACCUMULO-898 convert to htrace

[Billie Rinaldi]

 On Oct. 25, 2014, 6:18 a.m., Josh Elser wrote:
  core/src/main/java/org/apache/accumulo/core/trace/TraceFormatter.java, line 
  95
  https://reviews.apache.org/r/27106/diff/1/?file=730957#file730957line95
 
  Two concerns: the array from the ByteBuffer would only be valid between 
  the arrayOffset() and the limit(). Having an array() from a ByteBuffer is 
  optional. Can we assume that the span's data will always have an array we 
  can use?

I think we can assume the latter.  I'll fix the offset and limit.


 On Oct. 25, 2014, 6:18 a.m., Josh Elser wrote:
  core/src/main/java/org/apache/accumulo/core/trace/TraceFormatter.java, line 
  83
  https://reviews.apache.org/r/27106/diff/1/?file=730957#file730957line83
 
  Re-use the ThreadLocalSimpleDateFormatter?

I'd rather fix this in another ticket, since this was just copied from the 
existing formatter.


 On Oct. 25, 2014, 6:18 a.m., Josh Elser wrote:
  test/src/test/java/org/apache/accumulo/test/VolumeIT.java, line 518
  https://reviews.apache.org/r/27106/diff/1/?file=730996#file730996line518
 
  Use ZooReader instead of ZooKeeper. You'll inherit the implicit retry 
  logic we have.
 
 Josh Elser wrote:
 Oops, just noticed that was an IT and not server code. Not a big deal 
 then.

I'll just drop these changes to VolumeIT, since they're not essential to the 
patch.  (Jim said they improved this test's pass rate for him.)


- Billie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27106/#review58494
---


On Oct. 23, 2014, 8:16 p.m., Billie Rinaldi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/27106/
 ---
 
 (Updated Oct. 23, 2014, 8:16 p.m.)
 
 
 Review request for accumulo and Eric Newton.
 
 
 Repository: accumulo
 
 
 Description
 ---
 
 Main diff is ACCUMULO-898-4-base.patch.  Additional files attached have the 
 rest of the diffs that make up ACCUMULO-898-4.patch.
 
 
 Diffs
 -
 
   assemble/bin/stop-all.sh 4bf06c0 
   assemble/pom.xml 89a3747 
   assemble/src/main/assemblies/component.xml 599d26c 
   core/pom.xml 10e7d71 
   core/src/main/java/org/apache/accumulo/core/client/ClientConfiguration.java 
 39b460d 
   core/src/main/java/org/apache/accumulo/core/conf/Property.java ad4fe92 
   core/src/main/java/org/apache/accumulo/core/conf/PropertyType.java fc20535 
   core/src/main/java/org/apache/accumulo/core/trace/DistributedTrace.java 
 83f5c26 
   core/src/main/java/org/apache/accumulo/core/trace/Span.java PRE-CREATION 
   core/src/main/java/org/apache/accumulo/core/trace/Trace.java PRE-CREATION 
   core/src/main/java/org/apache/accumulo/core/trace/TraceDump.java b44cc3e 
   core/src/main/java/org/apache/accumulo/core/trace/TraceFormatter.java 
 9d860d9 
   core/src/main/java/org/apache/accumulo/core/trace/ZooTraceClient.java 
 4c8b837 
   core/src/main/java/org/apache/accumulo/core/util/ThriftUtil.java da4e567 
   core/src/main/scripts/generate-thrift.sh 9fe743d 
   docs/src/main/asciidoc/chapters/administration.txt d5e73f0 
   docs/src/main/resources/distributedTracing.html 54c9095 
   examples/simple/pom.xml 37adc00 
   
 examples/simple/src/main/java/org/apache/accumulo/examples/simple/client/TracingExample.java
  a542263 
   
 minicluster/src/main/java/org/apache/accumulo/minicluster/MiniAccumuloInstance.java
  54897cb 
   pom.xml ebc2f2f 
   server/base/pom.xml 60762be 
   server/base/src/main/java/org/apache/accumulo/server/Accumulo.java ac7ad60 
   server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java 
 602f214 
   
 server/base/src/main/java/org/apache/accumulo/server/util/AccumuloStatus.java 
 7e1cc97 
   server/base/src/main/java/org/apache/accumulo/server/util/ZooZap.java 
 1f59531 
   server/gc/pom.xml 8194121 
   server/gc/src/main/java/org/apache/accumulo/gc/SimpleGarbageCollector.java 
 84ad28b 
   server/master/pom.xml 3b9684c 
   server/master/src/main/java/org/apache/accumulo/master/Master.java 42495f4 
   
 server/master/src/main/java/org/apache/accumulo/master/replication/ReplicationDriver.java
  a52f743 
   server/monitor/pom.xml a847183 
   server/monitor/src/main/java/org/apache/accumulo/monitor/Monitor.java 
 7a724f8 
   
 server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/trace/ShowTrace.java
  a476201 
   
 server/monitor/src/test/java/org/apache/accumulo/monitor/ShowTraceLinkTypeTest.java
  a630434 
   server/tracer/pom.xml e1f61e6 
   server/tracer/src/main/java/org/apache/accumulo/tracer/TraceServer.java 
 189bb39 
   server/tserver/pom.xml 65c33ec 
   
 server/tserver/src/main/java/org/apache/accumulo/tserver/BulkFailedCopyProcessor.java
  ff0097a 
   server/tserver/src/main/java/org/apache/accumulo/tserver/InMemoryMap.java

Re: Review Request 27106: ACCUMULO-898 convert to htrace

[Billie Rinaldi]

/main/java/org/apache/accumulo/trace/instrument/Tracer.java d70aeea 
  trace/src/main/java/org/apache/accumulo/trace/instrument/impl/MilliSpan.java 
b641a2c 
  trace/src/main/java/org/apache/accumulo/trace/instrument/impl/NullSpan.java 
916b6cf 
  
trace/src/main/java/org/apache/accumulo/trace/instrument/impl/RootMilliSpan.java
 c25e644 
  
trace/src/main/java/org/apache/accumulo/trace/instrument/receivers/AsyncSpanReceiver.java
 4eebd69 
  
trace/src/main/java/org/apache/accumulo/trace/instrument/receivers/LogSpans.java
 dfed660 
  
trace/src/main/java/org/apache/accumulo/trace/instrument/receivers/SendSpansViaThrift.java
 4967d97 
  
trace/src/main/java/org/apache/accumulo/trace/instrument/receivers/SpanReceiver.java
 b44e51e 
  
trace/src/main/java/org/apache/accumulo/trace/instrument/receivers/ZooSpanClient.java
 84e3204 
  trace/src/main/java/org/apache/accumulo/trace/thrift/Annotation.java 
PRE-CREATION 
  trace/src/main/java/org/apache/accumulo/trace/thrift/RemoteSpan.java 416ae17 
  trace/src/main/thrift/trace.thrift 76bcafe 
  trace/src/test/java/org/apache/accumulo/trace/instrument/TracerTest.java 
f338bd8 

Diff: https://reviews.apache.org/r/27106/diff/


Testing
---


File Attachments (updated)


ACCUMULO-898-5-additional-refactoring.patch
  
https://reviews.apache.org/media/uploaded/files/2014/11/06/ba7f147e-3918-4376-92ec-6feeb82ef31a__ACCUMULO-898-5-additional-refactoring.patch


Thanks,

Billie Rinaldi

Re: Review Request 26572: ACCUMULO-898

[Billie Rinaldi]

 On Oct. 10, 2014, 8:42 p.m., Eric Newton wrote:
  Missed updating the instructions in 
  docs/src/main/resources/distributedTracing.html

Also administration.txt in the user manual.  Documentation is forthcoming.


- Billie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26572/#review56209
---


On Oct. 10, 2014, 7:12 p.m., Eric Newton wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/26572/
 ---
 
 (Updated Oct. 10, 2014, 7:12 p.m.)
 
 
 Review request for accumulo.
 
 
 Repository: accumulo
 
 
 Description
 ---
 
 Switch to HTrace
 
 
 Diffs
 -
 
   core/pom.xml 086ebc0 
   core/src/main/java/org/apache/accumulo/core/cli/ClientOpts.java e582160 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/ConditionalWriterImpl.java
  e8af187 
   core/src/main/java/org/apache/accumulo/core/client/impl/ConnectorImpl.java 
 62ab6a4 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/InstanceOperationsImpl.java
  c5f7634 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/NamespaceOperationsImpl.java
  7087ac5 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/ReplicationOperationsImpl.java
  f820aa4 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/SecurityOperationsImpl.java
  e9c057e 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/TableOperationsImpl.java
  e46b9c9 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchReaderIterator.java
  d2ca60e 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchWriter.java
  5eec397 
   core/src/main/java/org/apache/accumulo/core/client/impl/ThriftScanner.java 
 c49330e 
   core/src/main/java/org/apache/accumulo/core/client/impl/Writer.java 0358a88 
   core/src/main/java/org/apache/accumulo/core/trace/DistributedTrace.java 
 83f5c26 
   core/src/main/java/org/apache/accumulo/core/trace/SpanTree.java 772a133 
   core/src/main/java/org/apache/accumulo/core/trace/TraceDump.java b44cc3e 
   core/src/main/java/org/apache/accumulo/core/trace/TraceFormatter.java 
 9d860d9 
   core/src/main/java/org/apache/accumulo/core/trace/ZooTraceClient.java 
 4c8b837 
   core/src/main/java/org/apache/accumulo/core/util/ThriftUtil.java da4e567 
   
 examples/simple/src/main/java/org/apache/accumulo/examples/simple/client/TracingExample.java
  a542263 
   
 minicluster/src/main/java/org/apache/accumulo/minicluster/impl/MiniAccumuloClusterImpl.java
  1fb5901 
   pom.xml ebc2f2f 
   server/base/pom.xml 60762be 
   server/base/src/main/java/org/apache/accumulo/server/Accumulo.java 7bb3d71 
   
 server/base/src/main/java/org/apache/accumulo/server/client/BulkImporter.java 
 7097079 
   
 server/base/src/main/java/org/apache/accumulo/server/master/LiveTServerSet.java
  3dbc6ba 
   
 server/base/src/main/java/org/apache/accumulo/server/master/balancer/TabletBalancer.java
  59d3e0b 
   
 server/base/src/main/java/org/apache/accumulo/server/trace/TraceFSDataInputStream.java
  5162e01 
   
 server/base/src/main/java/org/apache/accumulo/server/trace/TraceFileSystem.java
  d3fbad7 
   server/base/src/main/java/org/apache/accumulo/server/util/Admin.java 
 d85d61e 
   
 server/base/src/main/java/org/apache/accumulo/server/util/VerifyTabletAssignments.java
  0fbeb6b 
   
 server/gc/src/main/java/org/apache/accumulo/gc/GarbageCollectWriteAheadLogs.java
  9646be9 
   
 server/gc/src/main/java/org/apache/accumulo/gc/GarbageCollectionAlgorithm.java
  0f5cada 
   server/gc/src/main/java/org/apache/accumulo/gc/SimpleGarbageCollector.java 
 10fd7f5 
   
 server/gc/src/main/java/org/apache/accumulo/gc/replication/CloseWriteAheadLogReferences.java
  74da72d 
   server/master/src/main/java/org/apache/accumulo/master/Master.java b435b0f 
   
 server/master/src/main/java/org/apache/accumulo/master/metrics/ReplicationMetrics.java
  06a653d 
   
 server/master/src/main/java/org/apache/accumulo/master/replication/ReplicationDriver.java
  a52f743 
   
 server/master/src/main/java/org/apache/accumulo/master/replication/StatusMaker.java
  68dd005 
   
 server/master/src/main/java/org/apache/accumulo/master/replication/WorkMaker.java
  da17bba 
   
 server/master/src/main/java/org/apache/accumulo/master/tableOps/BulkImport.java
  b55b315 
   
 server/master/src/main/java/org/apache/accumulo/master/tableOps/TraceRepo.java
  9b1a735 
   server/monitor/src/main/java/org/apache/accumulo/monitor/Monitor.java 
 7a724f8 
   
 server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/TServersServlet.java
  452f790 
   
 server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/trace/ShowTrace.java
  a476201 
   
 

Re: Review Request 26572: ACCUMULO-898

[Billie Rinaldi]

 On Oct. 10, 2014, 8:33 p.m., Eric Newton wrote:
  minicluster/src/main/java/org/apache/accumulo/minicluster/impl/MiniAccumuloClusterImpl.java,
   line 269
  https://reviews.apache.org/r/26572/diff/1/?file=717641#file717641line269
 
  Why add the IPv4Stack change?  Is this related to tracing?

When testing I noticed it was using 0:0:0:0:0:0:0:0 for the trace server, so I 
switched it.  But that was early on, so I'll see if it can be removed now.


 On Oct. 10, 2014, 8:33 p.m., Eric Newton wrote:
  minicluster/src/main/java/org/apache/accumulo/minicluster/impl/MiniAccumuloClusterImpl.java,
   line 382
  https://reviews.apache.org/r/26572/diff/1/?file=717641#file717641line382
 
  What's the reason for this change?

file:// isn't a valid dfsUri.  But I think it isn't actually used, so I could 
switch it back.


 On Oct. 10, 2014, 8:33 p.m., Eric Newton wrote:
  test/src/test/java/org/apache/accumulo/test/ConditionalWriterIT.java, line 
  94
  https://reviews.apache.org/r/26572/diff/1/?file=717690#file717690line94
 
  Is this related to tracing changes?

Yes, tests that use tracing need to configure it beforehand.  I'll revisit 
whether this is necessary after moving tracing configuration out the hadoop 
conf.


 On Oct. 10, 2014, 8:33 p.m., Eric Newton wrote:
  server/tserver/src/main/java/org/apache/accumulo/tserver/replication/AccumuloReplicaSystem.java,
   line 342
  https://reviews.apache.org/r/26572/diff/1/?file=717671#file717671line342
 
  Why not make a version of TraceUtil.data that takes a TraceScope?

Will do.


- Billie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26572/#review56204
---


On Oct. 10, 2014, 7:12 p.m., Eric Newton wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/26572/
 ---
 
 (Updated Oct. 10, 2014, 7:12 p.m.)
 
 
 Review request for accumulo.
 
 
 Repository: accumulo
 
 
 Description
 ---
 
 Switch to HTrace
 
 
 Diffs
 -
 
   core/pom.xml 086ebc0 
   core/src/main/java/org/apache/accumulo/core/cli/ClientOpts.java e582160 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/ConditionalWriterImpl.java
  e8af187 
   core/src/main/java/org/apache/accumulo/core/client/impl/ConnectorImpl.java 
 62ab6a4 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/InstanceOperationsImpl.java
  c5f7634 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/NamespaceOperationsImpl.java
  7087ac5 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/ReplicationOperationsImpl.java
  f820aa4 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/SecurityOperationsImpl.java
  e9c057e 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/TableOperationsImpl.java
  e46b9c9 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchReaderIterator.java
  d2ca60e 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchWriter.java
  5eec397 
   core/src/main/java/org/apache/accumulo/core/client/impl/ThriftScanner.java 
 c49330e 
   core/src/main/java/org/apache/accumulo/core/client/impl/Writer.java 0358a88 
   core/src/main/java/org/apache/accumulo/core/trace/DistributedTrace.java 
 83f5c26 
   core/src/main/java/org/apache/accumulo/core/trace/SpanTree.java 772a133 
   core/src/main/java/org/apache/accumulo/core/trace/TraceDump.java b44cc3e 
   core/src/main/java/org/apache/accumulo/core/trace/TraceFormatter.java 
 9d860d9 
   core/src/main/java/org/apache/accumulo/core/trace/ZooTraceClient.java 
 4c8b837 
   core/src/main/java/org/apache/accumulo/core/util/ThriftUtil.java da4e567 
   
 examples/simple/src/main/java/org/apache/accumulo/examples/simple/client/TracingExample.java
  a542263 
   
 minicluster/src/main/java/org/apache/accumulo/minicluster/impl/MiniAccumuloClusterImpl.java
  1fb5901 
   pom.xml ebc2f2f 
   server/base/pom.xml 60762be 
   server/base/src/main/java/org/apache/accumulo/server/Accumulo.java 7bb3d71 
   
 server/base/src/main/java/org/apache/accumulo/server/client/BulkImporter.java 
 7097079 
   
 server/base/src/main/java/org/apache/accumulo/server/master/LiveTServerSet.java
  3dbc6ba 
   
 server/base/src/main/java/org/apache/accumulo/server/master/balancer/TabletBalancer.java
  59d3e0b 
   
 server/base/src/main/java/org/apache/accumulo/server/trace/TraceFSDataInputStream.java
  5162e01 
   
 server/base/src/main/java/org/apache/accumulo/server/trace/TraceFileSystem.java
  d3fbad7 
   server/base/src/main/java/org/apache/accumulo/server/util/Admin.java 
 d85d61e 
   
 server/base/src/main/java/org/apache/accumulo/server/util/VerifyTabletAssignments.java
  0fbeb6b 
   
 

Re: 1.7 release timeline

[Billie Rinaldi]

Zipkin is a possible replacement for our trace collection system.  It does
not provide instrumentation like cloudtrace or htrace, so even if we make
zipkin the default collection system we will still need instrumentation.
Anyway, we can discuss the details and approach elsewhere.  I'd certainly
want the trace work to be in 2.0, but if we decide not to put it in 1.7
that would be okay.

On Mon, Oct 6, 2014 at 5:59 PM, Christopher ctubb...@apache.org wrote:

 Would replacing cloudtrace be part of 1.7? I'm not sure about that. I'd
 like to see where that's headed before we decide on that. Personally, I'd
 prefer Zipkin, since htrace is basically a copy of
 cloudtrace/accumulo-trace, and it has some of the same issues (millis time,
 for instance, instead of relative nanos, which is independent of the system
 clock and actually intended for time spans).

 I think the upgrade guarantees are more a 2.0.0 thing, but I think we can
 be a bit more conservative in 1.x to move towards that. I wouldn't mind
 dropping Hadoop 1 support in 1.7.0. (I guess we should just vote on that).

 I'd really like to include the VolumeChooser improvements (in particular
 ACCUMULO-3177, which depends on ACCUMULO-3176).


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Mon, Oct 6, 2014 at 8:38 PM, Josh Elser josh.el...@gmail.com wrote:

  Thanks, John.
 
  I was thinking about trying to gun for January time-frame for a release.
  I'd love to say before 2014 is over, but that probably just won't happen
  for a major release with the holidays.
 
  For 1.7 right now, I see the following bigger items (correct me where
  I'm wrong):
 
  * Replication (done)
  * Upgrade rules/guarantees (proposed)
  * Replace cloudtrace (in-progress)
  * Rewrite monitor, include REST service (in-progress)
  * Drop Hadoop 1 support (proposed)
  * Decouple MiniAccumulo from ITs (in-progress)
  * Other minicluster types: in-process, shim to real instance
 (in-progress)
  * Support Hadoop metrics2 (proposed)
  * A few WAL/metadata related performance improvements (in-progress)
 
  Also, would be good to check the In-Progress state issues on JIRA. What
 do
  people think?
 
 
  John Vines wrote:
 
  Moving this to it's own thread...
 
  On Mon, Oct 6, 2014 at 5:54 PM, Mike Drobmad...@cloudera.com  wrote:
 
   Related: Do we have a release timeline for 1.7?
 
 

Re: Accumulo Powered By Logo

[Billie Rinaldi]

I would argue that the a logo is one of our official logos. It is in use
as the favicon of the Accumulo monitor page, and on our Twitter account.
On Oct 2, 2014 3:49 PM, Keith Turner ke...@deenlo.com wrote:

 On Thu, Oct 2, 2014 at 3:39 PM, Mike Drob mad...@cloudera.com wrote:

  Yea, as an outside observer, I would have no idea what Apache A is, nor
  any idea how to get more information. Maybe we just need a different
 logo,
 

 One mitigating factor, is that if anyone used the logo on a web site I
 think they would normally make the image link to the Accumulo web site.
 This would give some context.

 I suppose the biggest problem is that its not the official logo of
 Accumulo.  Many logos completely out of context convey no information (like
 hadoop's elephant).   Since the 'a' by itself is not the official logo, we
 can not really use it.


  altogether, given the context of putting it in the PBA circle.
 
  On Thu, Oct 2, 2014 at 2:36 PM, Keith Turner ke...@deenlo.com wrote:
 
   I was a looking at the new Accumulo powered logo [1] and thought that
  just
   an A[2] may be better.  Any other thoughts on how to improve this?
  
   Someone mentioned that just the A[2] isn't as informative in the case
  where
   someone is completely unfamiliar w/ Accumulo.
  
   [1]: http://apache.org/foundation/press/kit/poweredBy/pb-accumulo.jpg
   [2]: http://people.apache.org/~kturner/pb-accumulo.png
  
 

Re: web master?

[Billie Rinaldi]

Any committer can update that page.
On Jul 11, 2014 10:01 PM, Kepner, Jeremy - 0553 - MITLL kep...@ll.mit.edu
wrote:

 Who is in charge of keeping http://accumulo.apache.org/papers.html up to
 date?

 Regards.  -Jeremy

Re: web master?

[Billie Rinaldi]

Oops, sorry for the repeated response. My internet is questionable at the
moment. I'll be back to civilization on Monday. =)
On Jul 12, 2014 1:48 PM, billie.rina...@gmail.com wrote:

 Any committer can update that page.
 On Jul 11, 2014 10:01 PM, Kepner, Jeremy - 0553 - MITLL 
 kep...@ll.mit.edu wrote:

 Who is in charge of keeping http://accumulo.apache.org/papers.html up to
 date?

 Regards.  -Jeremy

Re: [VOTE][BLOG] New Blog Entry - Scaling Accumulo with Multi-Volume Support

[Billie Rinaldi]

Yes, I think they strip attachments.
On Jun 20, 2014 9:35 PM, dlmar...@comcast.net wrote:

 I tried from two different accounts, must be the Apache mail servers?


 - Original Message -

 From: dlmar...@comcast.net
 To: dev@accumulo.apache.org
 Sent: Friday, June 20, 2014 9:30:05 PM
 Subject: Re: [VOTE][BLOG] New Blog Entry - Scaling Accumulo with
 Multi-Volume Support

 Sean said the attachment didn't make it, let's try this again.

 - Original Message -

 From: dlmar...@comcast.net
 To: dev@accumulo.apache.org
 Sent: Friday, June 20, 2014 9:12:30 PM
 Subject: Re: [VOTE][BLOG] New Blog Entry - Scaling Accumulo with
 Multi-Volume Support


 For those without a blog account, see attached.

 - Original Message -

 From: dlmar...@comcast.net
 To: dev@accumulo.apache.org
 Sent: Friday, June 20, 2014 9:04:04 PM
 Subject: [VOTE][BLOG] New Blog Entry - Scaling Accumulo with Multi-Volume
 Support

 All,

 Eric and I authored a new blog post on how the benefits of multi-volume
 support in 1.6.0. I will be accepting feedback on typo's and grammar
 errors. The entry is located at:


 https://blogs.apache.org/roller-ui/authoring/preview/accumulo/?previewEntry=scaling_accumulo_with_multi_volume

 This vote will be open for feedback for 3 days (24 June 2014 0100 GMT) and
 then I will promote to the blog site. Thanks,

 Dave

Re: moving rat to a profile?

[Billie Rinaldi]

I'm not thrilled about turning it off by default.  How about putting it in
a profile that would be enabled by default, but could be disabled with a
flag for those who don't understand why it's failing?


On Tue, Jun 17, 2014 at 11:44 AM, Sean Busbey bus...@cloudera.com wrote:

 I've had a few different new-to-Accumulo contributors recently run into the
 issue of Rat failing the build after changing branches.

 I know we already have a warning about this[1], but AFAICT it's over the
 threshold for consumable information.

 Even after pointing people to the warning, the existing workaround tripped
 up atleast one of them. Despite the warning about using git clean, the
 destruction of their local IDE changes were surprising.

 For contributions to Accumulo that aren't coming from committers, the Rat
 plugin seems much more likely to give a false positive than to catch an
 error. Additionally, whatever committer is reviewing the contribution
 should be checking for license compliance anyways.

 In the interests of reducing the surprise for new contributors, I'd like to
 move our use of Rat to a profile that is only default enabled during a
 release run.

 The profile would still let those who want rat to run on every build to
 enable it and we could update the guide for handling new contributions to
 say committers should enable the rat profile to help guard against errors.

 Any objections?

 [1]: http://accumulo.apache.org/source.html#running-a-build

 --
 Sean

Re: moving rat to a profile?

[Billie Rinaldi]

On Tue, Jun 17, 2014 at 12:14 PM, Michael Allen mich...@sqrrl.com wrote:

 In my not so humble opinion, adding licenses to a small set of missing
 files really isn't that hard for a release manager (or other random
 committer) to do periodically.  On the other hand, the barrier that the RAT
 checks throw up to new developers is quite real, and quite annoying.


The problem is not the actual adding of licenses, but that this encourages
a lack of understanding of committer responsibilities.  From our bylaws,
Under the terms of the CLA that all committers must sign, a committer's
primary responsibility is to ensure that all code committed to Apache
Accumulo is licensed appropriately and meets those criteria set forth in
the CLA (including both original works and patches committed on behalf of
other contributors).  It doesn't matter if contributors check the license
headers, but committers should be checking them for every commit, not just
periodically or at release time.






 On Tue, Jun 17, 2014 at 3:09 PM, Billie Rinaldi billie.rina...@gmail.com
 wrote:

  I'm not thrilled about turning it off by default.  How about putting it
 in
  a profile that would be enabled by default, but could be disabled with a
  flag for those who don't understand why it's failing?
 
 
  On Tue, Jun 17, 2014 at 11:44 AM, Sean Busbey bus...@cloudera.com
 wrote:
 
   I've had a few different new-to-Accumulo contributors recently run into
  the
   issue of Rat failing the build after changing branches.
  
   I know we already have a warning about this[1], but AFAICT it's over
 the
   threshold for consumable information.
  
   Even after pointing people to the warning, the existing workaround
  tripped
   up atleast one of them. Despite the warning about using git clean,
 the
   destruction of their local IDE changes were surprising.
  
   For contributions to Accumulo that aren't coming from committers, the
 Rat
   plugin seems much more likely to give a false positive than to catch an
   error. Additionally, whatever committer is reviewing the contribution
   should be checking for license compliance anyways.
  
   In the interests of reducing the surprise for new contributors, I'd
 like
  to
   move our use of Rat to a profile that is only default enabled during a
   release run.
  
   The profile would still let those who want rat to run on every build to
   enable it and we could update the guide for handling new contributions
 to
   say committers should enable the rat profile to help guard against
  errors.
  
   Any objections?
  
   [1]: http://accumulo.apache.org/source.html#running-a-build
  
   --
   Sean
  
 



 --

 *Michael Allen*
 Security Architect | Sqrrl---130
 Prospect Street | Cambridge, MA 02139415.699.0106 | www.sqrrl.com
 ---

 The information contained in this communication may be confidential,
 subject to legal privilege, or otherwise protected from disclosure,
 and is intended solely for the use of the intended recipient(s). If
 you are not the intended recipient of this communication, please
 destroy all copies in your possession, notify the sender that you have
 received this communication in error, and note that any review or
 dissemination of, or the taking of any action in reliance on, this
 communication is expressly prohibited.  Please note that sqrrl data,
 INC. reserves the right to intercept, monitor, and retain e-mail
 messages to and from its systems as permitted by applicable law.

Re: moving rat to a profile?

[Billie Rinaldi]

How about recommending a mvn clean before checking out a new branch?


On Tue, Jun 17, 2014 at 12:19 PM, Sean Busbey bus...@cloudera.com wrote:

 My concern with a default-on profile is the same one I have with
 Christopher's suggestion that we recommend -Drat.ignoreErrors=true.

 It's going to make the easy path one where things aren't checked. That's
 going to necessitate we check things periodically and during release.

 We can just as easily do those checks by activating the profile, e.g. in a
 jenkins build and in the release script.


 On Tue, Jun 17, 2014 at 3:09 PM, Billie Rinaldi billie.rina...@gmail.com
 wrote:

  I'm not thrilled about turning it off by default.  How about putting it
 in
  a profile that would be enabled by default, but could be disabled with a
  flag for those who don't understand why it's failing?
 
 
  On Tue, Jun 17, 2014 at 11:44 AM, Sean Busbey bus...@cloudera.com
 wrote:
 
   I've had a few different new-to-Accumulo contributors recently run into
  the
   issue of Rat failing the build after changing branches.
  
   I know we already have a warning about this[1], but AFAICT it's over
 the
   threshold for consumable information.
  
   Even after pointing people to the warning, the existing workaround
  tripped
   up atleast one of them. Despite the warning about using git clean,
 the
   destruction of their local IDE changes were surprising.
  
   For contributions to Accumulo that aren't coming from committers, the
 Rat
   plugin seems much more likely to give a false positive than to catch an
   error. Additionally, whatever committer is reviewing the contribution
   should be checking for license compliance anyways.
  
   In the interests of reducing the surprise for new contributors, I'd
 like
  to
   move our use of Rat to a profile that is only default enabled during a
   release run.
  
   The profile would still let those who want rat to run on every build to
   enable it and we could update the guide for handling new contributions
 to
   say committers should enable the rat profile to help guard against
  errors.
  
   Any objections?
  
   [1]: http://accumulo.apache.org/source.html#running-a-build
  
   --
   Sean
  
 



 --
 Sean

Re: moving rat to a profile?

[Billie Rinaldi]

Also, is there a reason clean -xdf is recommended instead of -df?  I think
the latter is sufficient to get rid of the offending target directories.


On Tue, Jun 17, 2014 at 12:37 PM, Sean Busbey bus...@cloudera.com wrote:

 I don't know that this will help much.

 We already have a *lot* for new contributors to keep track of. If they miss
 the step of running maven clean, they end up exactly where we are now.

 The output from the Rat plugin doesn't make it easy to figure out how they
 got into that state, nor how to back out of it. They're likely at a point
 where they can't easily go back to the branch that could do the clean, so
 they're back to add your files and use git clean. Which we already know
 isn't going great for people.


 On Tue, Jun 17, 2014 at 3:31 PM, Billie Rinaldi billie.rina...@gmail.com
 wrote:

  How about recommending a mvn clean before checking out a new branch?
 
 
  On Tue, Jun 17, 2014 at 12:19 PM, Sean Busbey bus...@cloudera.com
 wrote:
 
   My concern with a default-on profile is the same one I have with
   Christopher's suggestion that we recommend -Drat.ignoreErrors=true.
  
   It's going to make the easy path one where things aren't checked.
  That's
   going to necessitate we check things periodically and during release.
  
   We can just as easily do those checks by activating the profile, e.g.
 in
  a
   jenkins build and in the release script.
  
  
   On Tue, Jun 17, 2014 at 3:09 PM, Billie Rinaldi 
  billie.rina...@gmail.com
   wrote:
  
I'm not thrilled about turning it off by default.  How about putting
 it
   in
a profile that would be enabled by default, but could be disabled
 with
  a
flag for those who don't understand why it's failing?
   
   
On Tue, Jun 17, 2014 at 11:44 AM, Sean Busbey bus...@cloudera.com
   wrote:
   
 I've had a few different new-to-Accumulo contributors recently run
  into
the
 issue of Rat failing the build after changing branches.

 I know we already have a warning about this[1], but AFAICT it's
 over
   the
 threshold for consumable information.

 Even after pointing people to the warning, the existing workaround
tripped
 up atleast one of them. Despite the warning about using git
 clean,
   the
 destruction of their local IDE changes were surprising.

 For contributions to Accumulo that aren't coming from committers,
 the
   Rat
 plugin seems much more likely to give a false positive than to
 catch
  an
 error. Additionally, whatever committer is reviewing the
 contribution
 should be checking for license compliance anyways.

 In the interests of reducing the surprise for new contributors, I'd
   like
to
 move our use of Rat to a profile that is only default enabled
 during
  a
 release run.

 The profile would still let those who want rat to run on every
 build
  to
 enable it and we could update the guide for handling new
  contributions
   to
 say committers should enable the rat profile to help guard against
errors.

 Any objections?

 [1]: http://accumulo.apache.org/source.html#running-a-build

 --
 Sean

   
  
  
  
   --
   Sean
  
 



 --
 Sean

Re: moving rat to a profile?

[Billie Rinaldi]

On Tue, Jun 17, 2014 at 12:52 PM, Sean Busbey bus...@cloudera.com wrote:

 On Tue, Jun 17, 2014 at 3:43 PM, Billie Rinaldi billie.rina...@gmail.com
 wrote:

  Also, is there a reason clean -xdf is recommended instead of -df?  I
 think
  the latter is sufficient to get rid of the offending target directories.
 
 
 If we don't say -x then the target directories of the previous-branch
 modules are in the wildcard matching for git ignore, and they don't get
 touched.


You're right, -df is sufficient for some branch switches, but not for
example 1.5 to 1.6.


 --
 Sean

ApacheCon CFP closes June 25

[Billie Rinaldi]

Dear Accumulo enthusiast,

As you may be aware, ApacheCon will be held this year in Budapest, on
November 17-23. (See http://apachecon.eu for more info.)

The Call For Papers for that conference is still open, but will be
closing soon. We need all kinds of talks - deep technical talks, hands-on
tutorials, introductions for beginners, or case studies about the
awesome stuff you're doing with Accumulo.

Please consider submitting a proposal, at
http://events.linuxfoundation.org//events/apachecon-europe/program/cfp

Thanks!

Re: Email list search links

[Billie Rinaldi]

It might be okay, as long as you note that isn't the official mail
archive.  I think some projects use Nabble.  I've had decent luck just
doing a google search of the archive, e.g. site:
mail-archives.apache.org/mod_mbox/accumulo-dev 1.6.0 release


On Fri, Jun 13, 2014 at 10:27 AM, Bill Havanki bhava...@clouderagovt.com
wrote:

 Hey everybody,

 I'd like to add search links to our mailing list page [1]. The ASF mailing
 list archives don't offer search, and the ASF's search capability [2] is
 only for ASF members (maybe - I can't even log in).

 Does anyone mind if I link to The Mail Archive? It is external to Apache,
 which might matter. You can check out a couple of their list pages [3][4]
 if you're curious.

 Thanks,
 Bill

 [1] http://accumulo.apache.org/mailing_list.html
 [2] https://mail-search.apache.org/
 [3] http://www.mail-archive.com/dev@accumulo.apache.org/
 [4] http://www.mail-archive.com/user@accumulo.apache.org

 --
 // Bill Havanki
 // Solutions Architect, Cloudera Govt Solutions
 // 443.686.9283

Re: Deploying SNAPSHOTs to nexus

[Billie Rinaldi]

I think snapshots are okay.  This link [1] on release distribution says
there is also a dev release area for things like snapshots and release
candidates.  So I would imagine maven snapshots are okay too, as long as
we're deploying to the snapshots repo and not the releases repo.  We just
aren't allowed to link to or direct people to download snapshot versions as
if they were releases.

[1]: http://www.apache.org/dev/release.html#upload-ci


On Wed, Jun 11, 2014 at 7:31 AM, Christopher ctubb...@apache.org wrote:

 I don't know for sure about what was done in the past, but we should
 consider the ASF policy about not making non releases generally available
 to non devs before we make this change. Can try to find link to policy
 later.
 Before we released 1.6.0, I got a request to upload some new 1.6.0-SNAPSHOT
 jars. After thinking about it some more, I convinced myself that we, at one
 point, had SNAPSHOTs being automatically deployed by Jenkins.

 Does anyone remember for sure? Was it lost in the svn-git transition? Any
 arguments against not trying to make this work again?

Re: Overuse of depth=1 on calls to Accumulo's Jenkins jobs' /api/json

[Billie Rinaldi]

Anyone know what is causing these queries to builds.a.o?

On Sat, May 31, 2014 at 12:32 PM, Andrew Bayer andrew.ba...@gmail.com
wrote:

 Hey Accumulo devs -

 I'm noticing a lot of calls to builds.apache.org for the JSON API data
 for Accumulo jobs like /job/Accumulo-1.6/api/json?depth=1 - specifying
 depth=1 means you're pulling a *LOT* of data, especially considering
 that's hitting every job every few minutes. Jenkins hung today and had
 a huge number of apparently hung threads trying to populate this data,
 and I think these calls may have induced the overall Jenkins UI hang -
 please take a look into the more granular control you can get over
 depth/tree on https://builds.apache.org/job/Accumulo-1.6/api/ and
 consider limiting your queries to just the data you need. Thanks.

 A.

Re: Overuse of depth=1 on calls to Accumulo's Jenkins jobs' /api/json

[Billie Rinaldi]

That was the only thing I could think of, but the links look like the
following, so I wasn't sure they were the culprit. We could get rid of them
just in case.
https://builds.apache.org/job/Accumulo-Master/lastBuild/buildStatus
On May 31, 2014 8:23 PM, Mike Drob md...@mdrob.com wrote:

 Is it the Jenkins balls under http://accumulo.apache.org/source.html ? I'm
 on my phone so I can't actually verify source code, but that is a likely
 suspect.
 On May 31, 2014 2:01 PM, Billie Rinaldi billie.rina...@gmail.com
 wrote:

  Anyone know what is causing these queries to builds.a.o?
 
  On Sat, May 31, 2014 at 12:32 PM, Andrew Bayer andrew.ba...@gmail.com
  wrote:
 
   Hey Accumulo devs -
  
   I'm noticing a lot of calls to builds.apache.org for the JSON API data
   for Accumulo jobs like /job/Accumulo-1.6/api/json?depth=1 - specifying
   depth=1 means you're pulling a *LOT* of data, especially considering
   that's hitting every job every few minutes. Jenkins hung today and had
   a huge number of apparently hung threads trying to populate this data,
   and I think these calls may have induced the overall Jenkins UI hang -
   please take a look into the more granular control you can get over
   depth/tree on https://builds.apache.org/job/Accumulo-1.6/api/ and
   consider limiting your queries to just the data you need. Thanks.
  
   A.
  
 

Re: [DISCUSS] Majority voting without prior discussion

[Billie Rinaldi]

I definitely agree with #1.  Still pondering #2.


On Tue, May 6, 2014 at 1:58 PM, Christopher ctubb...@apache.org wrote:

 Devs,

 As something that came out of the vote thread about EOL'ing 1.4, I was
 thinking:

 The purpose of a majority vote seems to be when we've already
 discussed and planned, and we just need things to come down to a final
 vote. Things like releasing, for example, occur after discussions,
 planning, and aren't a surprise in any way. It seems to me that there
 are two main points I want to make:

 1) Prior discussion/planning should be a prerequisite for things which
 are majority vote.
 2) The default for any ambiguous or arbitrary vote item that does not
 fall into a predetermined type, should require consensus.

 The problem with majority votes without discussion is that there may
 be serious concerns a minority of persons voting have about something,
 that could be resolved with compromise where there is plenty of
 room for gathering consensus. Coming together as a community to move
 forward with a mutually agreed upon path should always be preferred
 where possible. In some cases, differences are irreconcilable and
 action just needs to be taken to move forward (releasing, for
 instance) on a majority decision, but even here, there is up front
 discussion about those differences (code development, release
 planning, etc.) prior to such a vote.

 Binding actions to a majority vote that has insufficient prior
 discussion, especially when there is no mechanism to extend a vote, or
 sane way to alter the contents of the majority vote while in progress,
 leads to actions that don't have the consensus of the community, even
 in circumstances where consensus was possible to achieve.

 I think our bylaws should be updated to reflect the two ideas above.
 I'm not sure the exact wording needed *(please submit proposals in
 response to this), but I think it should declare that any voting that
 does not clearly fall into a vote category explicitly enumerated, or
 if there's any doubt, should default to consensus. Before we had
 bylaws, this appeared to be the precedent... as we often took great
 care to respond to any objections, delaying, canceling, or extending
 the vote to do so. We should continue to operate with that same sense
 of community in future decisions as well, and I think consensus voting
 whenever possible is the way to do that.

 It was also discussed that it may be helpful to enumerate end of life
 procedures in the bylaws as well. I'm not sure this is as important of
 an issue if we agree that the default should be consensus... but I'm
 willing to entertain that discussion in this thread as well.

 Thanks for your time and input.

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

Re: [DISCUSS] Majority voting without prior discussion

[Billie Rinaldi]

On Wed, May 7, 2014 at 9:07 AM, Sean Busbey bus...@cloudera.com wrote:

 We should not require an explicit discussion period prior to a majority
 vote, especially in our bylaws. Discussion and conflict resolution should
 happen as a part of our normal community interactions. If these things are
 not already happening, a mandated warm up period isn't going to fix
 that. Procedures are no substitute for community.


Discussion is already mentioned in our governance docs: Before calling a
vote it is important to ensure that the community is given time to discuss
the upcoming vote. This will be done by posting an email to the list
indicating the intention to call a vote and the options available. By the
time a vote is called there should already be consensus in the
communityhttp://accumulo.apache.org/governance/consensusBuilding.html.
The vote itself is, normally, a formality. (
http://accumulo.apache.org/governance/voting.html)

Apache community is built around mailing list discussion, so it's hard for
me to see this as procedure over community.  Certainly discussion is more
important for some issues than others.  I personally was surprised by the
1.4 eol vote being called without prior discussion -- in my opinion, this
was clearly something that warranted a discussion prior to a vote.  Sean, I
think you did a good job of salvaging the situation, and I agree that we
should be prepared to handle new concerns expressed during votes, but I
also think we can usually do better than salvaging.



 Generally, vote callers should have an easier time if they try to lead a
 discussion period first. Certainly if there isn't consensus over the
 fundamental matter of the vote, a DISCUSS thread is preferable to using a
 VOTE thread for discussion.

 However, there's no way to ensure that all concerns get hashed out prior to
 a vote. It is the responsibility of each person who votes to make a good
 faith effort. For those against that means explaining their concerns and
 how they can be met, especially during consensus votes. For those who are
 for the proposition it means attempting to address the concerns of those
 against and they must be particularly mindful in majority votes.

 While reflecting on how to phrase this message, I kept coming back to the
 ASF reasoning on voting[1]:

  Reasons for Votes
 
  People tend to avoid conflict and thrash around looking for something to
 substitute - somebody in
  charge, a rule, a process, stagnation. None of these tend to be very good
 substitutes for doing the hard
  work of resolving the conflict.

 If more discussion is needed or modifications to the proposal are
 necessary, we always have the option of failing the vote and trying again.
 There's no need to add rules to draw the vote out either though altering
 vote periods or mandating a discussion period. It should be sufficient for
 concerned individuals to include the need in their vote of -1. A well
 functioning community should be looking for consensus. If you can't get
 enough people to join in on voting for more discussion, that discussion
 isn't likely to result in consensus.

 I would like to see us gain more rigor around sunsetting major releases. I
 don't think adding an additional vote type is the way to go about that.
 Instead, I'd like to see the discussion around how we're going to handle
 things in 2.0.0+ include setting up the whole lifecycle for major release
 development around release planning.

 -Sean

 [1]: http://www.apache.org/foundation/voting.html


 On Tue, May 6, 2014 at 6:49 PM, dlmar...@comcast.net wrote:

 
   Your comments suggest that we need to tailor our model to follow the
 U.S.
  Senate. We will need a vote to end debate, so that we can vote on the
  measure. Can I filibuster? Just kidding, I wouldn't wish that on anyone.
 
   In all seriousness, I agree with your statements. I did the same thing
  with the blog thread, discuss, gather feedback, vote on text that was
  agreed upon. I went back and looked at the bylaws, which specify majority
  approval for ending a planned release and for an official release. What
 if
  they were consensus approval instead? Or, maybe a modification to the
  bylaws that states certain types of votes cannot be started without a
  discussion first.
 
  -Original Message-
  From: Christopher [mailto:ctubb...@apache.org]
  Sent: Tuesday, May 06, 2014 4:59 PM
  To: Accumulo Dev List
  Subject: [DISCUSS] Majority voting without prior discussion
 
  Devs,
 
  As something that came out of the vote thread about EOL'ing 1.4, I was
  thinking:
 
  The purpose of a majority vote seems to be when we've already discussed
  and planned, and we just need things to come down to a final vote. Things
  like releasing, for example, occur after discussions, planning, and
 aren't
  a surprise in any way. It seems to me that there are two main points I
 want
  to make:
 
  1) Prior discussion/planning should be a prerequisite for things which
 are
  majority vote.
  2) 

[ANNOUNCE] Apache Accumulo 1.6.0 Release

[Billie Rinaldi]

The Apache Accumulo project is especially pleased to announce its 1.6.0
release.

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.

Download the 1.6.0 release:
http://accumulo.apache.org/downloads

Read the release notes:
http://accumulo.apache.org/release_notes/1.6.0.html

Report issues:
https://issues.apache.org/jira/browse/ACCUMULO

Find more information at the Apache Accumulo website:
http://accumulo.apache.org

-- The Apache Accumulo Team

Re: [VOTE] Website update

[Billie Rinaldi]

Nevermind!  I was worried for no reason.  Apparently my browser had done
some weird partial caching.


On Mon, May 5, 2014 at 9:55 AM, Billie Rinaldi billie.rina...@gmail.comwrote:

 The website is in a bad state and does not match the beautiful site
 generated by Bill (actually I've never been able to generate a site that
 looked exactly like our real website myself, so I don't know what is
 different about the real CMS process).  We need to fix this ASAP, and
 probably shouldn't announce 1.6.0 until it's ready.


 On Sun, May 4, 2014 at 10:40 AM, Bill Havanki 
 bhava...@clouderagovt.comwrote:

 This vote passes with 6 +1 and 1 non-binding +1.

 Thanks to everyone for looking over the new site and helping to improve
 it,
 both before and during the vote.

 I have merged the redesign14 Subversion branch of the site with the
 trunk
 and deployed it to production. You should be able to browse to it normally
 at http://accumulo.apache.org. Please feel free to give it a once-over to
 make sure the merge went correctly.

 Josh: the 1.6 apidocs are reachable through the new site, so that part of
 the deploy worked out fine.

 Please consider the website freeze over and proceed to make changes to it
 as needed. Most edits should not require fiddling with Bootstrap, but if
 you need help, send me a note, or visit getbootstrap.com.

 Bill


 On Fri, May 2, 2014 at 9:13 PM, Bill Havanki bhava...@clouderagovt.com
 wrote:

  Vote update: As 1.6.0 rc5 was approved today, this vote shall close
  tomorrow, Saturday May 3, at 2130 UTC / 1730 EDT.
 
  On Tue, Apr 22, 2014 at 9:55 AM, Alex Moundalexis 
 al...@clouderagovt.comwrote:
 
  +1 non-binding
 
  Side-note: In reviewing, noticed some of the glossary terms for
 processes
  weren't defined (nor on live site). Proposed edits in CMS per Accumulo
  design documentation, should be a patch distributed shortly per
  ACCUMULO-2710.
 
  http://people.apache.org/~bhavanki/accumulo-bootstrapped/glossary.html
 
 
 
 
  On Wed, Apr 16, 2014 at 9:06 AM, Bill Havanki 
 bhava...@clouderagovt.com
  wrote:
 
   The repositioning you see is the behavior I added for smaller
 displays
  like
   phones and tablets; it's also triggered when you narrow the browser
  window
   enough. Bootstrap is too reactive to go with a horizontal scrollbar;
   instead it'll just cram the layout into the skinny screen.
  
   The white space margins around the right pane (main content) do get
  pretty
   wide for a very wide display, and it's because Bootstrap scales them
  with
   the view width. They are absent in a mobile display, so that the
 whole
   screen is used. They are present for the large displays to avoid long
  lines
   of text in the main content. I don't know an easy way to improve
 that at
   the moment.
  
  
   On Wed, Apr 16, 2014 at 2:04 AM, Arshak Navruzyan arsh...@gmail.com
 
   wrote:
  
Very nice!
   
Some minor resizing issues (on Mac with Chrome 34.0.1847.116).  If
 my
browser window is too narrow, looks like the right pane wraps down
 and
   left
pane goes 100%.  I would expect everything to stay put and to just
  get a
horizontally scrollbar instead.
   
If the window is too wide, margin between left and right panes
 looks
  kind
of big.   I would expect it to stay somewhat consistent in terms of
   margin
size and the additional real-estate becomes white space to the
 right
  of
   the
main content pane.
   
   
[image: Inline image 2][image: Inline image 1]
   
   
On Tue, Apr 15, 2014 at 1:08 PM, Bill Havanki 
  bhava...@clouderagovt.com
   wrote:
   
The purpose of this vote is to consider a site-wide update to the
   Accumulo
website at accumulo.apache.org. The site is hosted for review at
 the
following URL:
   
http://people.apache.org/~bhavanki/accumulo-bootstrapped/
   
The updated site should agree in *content* with the current site,
 but
varies in navigation and look-and-feel. It is expected that the
  content
   of
the current site will be updated during the vote period, and so
 the
updated
site will merge in those updates to match. The initial site under
consideration is at rev 1587700 of
   
   
 https://svn.apache.org/repos/asf/accumulo/site/branches/redesign14
   
Upon approval, the updated site shall be deployed with or shortly
  after
the
1.6.0 release, in coordination with the release manager.
   
This vote is via lazy approval / lazy consensus in accordance with
  our
bylaws [1] for a general voting action. The vote period begins
 with
  the
posting of this message and ends 24 hours after the 1.6.0 release
 is
approved.
   
[+1] = I approve of replacing the Accumulo website with the
 updated
version.
[+0] = I neither approve nor disapprove of replacing the website,
 but
   have
no objection to it going ahead.
[-0] = I neither approve nor disapprove of replacing the website,
  and my
reservations about it are not enough