Re: Accumulo Quarterly Report - Due Wednesday, April 10th.

[Christopher]

I agree with Dave that it could be moved out of Other and into the
Project activity and Releases sections. But I don't know that it
matters much.

On Fri, Apr 5, 2024 at 4:21 PM Daniel Roberts  wrote:
>
> Report looks good!
>
> On Fri, Apr 5, 2024 at 3:41 PM Dave Marion  wrote:
>
> > I'm fine with leaving it as-is, like I said, was just curious.
> >
> > On Fri, Apr 5, 2024 at 3:33 PM Ed Coleman  wrote:
> >
> > > I don't recall mentioning them at all.  But the access library seems
> > > significant because it is designed for re-use outside of Accumulo.  The
> > > others seem to be "here are some things you may find helpful" - maybe the
> > > proxy is more than that? But I don't recall ever mention the proxy
> > > specifically in a project report.
> > >
> > > Would if help if the sub-heading (it's at the same level as releases)
> > read
> > > "Other Releases:" ?
> > >
> > > On 2024/04/05 19:22:22 Dave Marion wrote:
> > > > And I have no issue if that's what we do for other sub-projects (I was
> > > > asking because I don't know / remember).
> > > >
> > > > On Fri, Apr 5, 2024 at 3:20 PM Ed Coleman 
> > wrote:
> > > >
> > > > > "Just curious why the Accumulo Access library mentions is in "Other".
> > > > >
> > > > > It was an arbitrary decision on my part.  I wanted to make sure that
> > it
> > > > > was noted as an achievement / project activity. But, it did not seem
> > > (to
> > > > > me) to be an Accumulo release - reserving those for 2.x, 3,x 
> > > > >
> > > > > I used other to actually highlight it - I could place it under
> > project
> > > > > activity if that is the consensus.  Same as considering it as a
> > > release -
> > > > > but as you mentioned we don't seem to treat other sub-projects that
> > > way.
> > > > >
> > > > >
> > > > > On 2024/04/05 17:59:22 Dave Marion wrote:
> > > > > > Just curious why the Accumulo Access library mentions is in
> > "Other".
> > > I
> > > > > > think an alternate version of this could describe Accumulo Access
> > in
> > > the
> > > > > > "Project Status" or "Project Activity" section and then add the
> > > release
> > > > > to
> > > > > > the "Releases" section. Does it get relegated to "Other" because
> > > it's a
> > > > > > sub-project (is that what would happen to testing, docker, etc.)?
> > > > > >
> > > > > > On Tue, Apr 2, 2024 at 10:34 AM Ed Coleman 
> > > wrote:
> > > > > >
> > > > > > > The Accumulo community decided to draft the Apache community
> > > reports
> > > > > on the
> > > > > > > Accumulo dev list – and this is a draft of the April report for
> > > review
> > > > > /
> > > > > > > comments. The report is due by Wednesday, April 10th. I'd like to
> > > > > submit
> > > > > > > the report on Friday, April 5th.
> > > > > > >
> > > > > > > The text below is copied from the reporting tool and may not
> > > reflect
> > > > > the
> > > > > > > final formatting of the final report when submitted.
> > > > > > >
> > > > > > > Ed Coleman
> > > > > > >
> > > > > > > --- begin report text from report tool ---
> > > > > > >
> > > > > > > ## Description:
> > > > > > > The mission of Apache Accumulo is the creation and maintenance of
> > > > > software
> > > > > > > related to a robust, scalable, distributed key/value store with
> > > > > cell-based
> > > > > > > access control and customizable server-side processing.
> > > > > > >
> > > > > > > ## Project Status:
> > > > > > > - Current project status: Ongoing with high activity.
> > > > > > > - Issues for the board: None.
> > > > > > >
> > > > > > > Accumulo is currently working on some significant development
> > > efforts.
> > > > > > > Improving
> > > > > > > the performance and stability of the 2.1.x line, adding new
> > > features
> > > > > and
> > > > > > > performance improvements to 3.1 line, and the evolution of the
> > > > > processing
> > > > > > > model to support dynamic scaling and provide elasticity.
> > > > > > >
> > > > > > > ## Membership Data:
> > > > > > > Apache Accumulo was founded 2012-03-21 (12 years ago) There are
> > > > > currently
> > > > > > > 42
> > > > > > > committers and 39 PMC members in this project. The
> > Committer-to-PMC
> > > > > ratio
> > > > > > > is
> > > > > > > roughly 1:1. It is our practice to invite committers to be PMC
> > > members
> > > > > at
> > > > > > > the
> > > > > > > same time. The difference between committers and PMC members is
> > > because
> > > > > > > some
> > > > > > > PMC members have elected to go emeritus.
> > > > > > >
> > > > > > > Community changes, past quarter:
> > > > > > > - No new PMC members. Last addition was Daniel Roberts on
> > > 2023-08-09.
> > > > > > > - No new committers. Last addition was Daniel Roberts on
> > > 2023-08-10.
> > > > > > >
> > > > > > > ## Project Activity:
> > > > > > >
> > > > > > > ### Releases:
> > > > > > > - accumulo-1.10.4 was released on 2023-11-16.
> > > > > > > - accumulo-2.1.2 was released on 2023-08-21.
> > > > > > > - accumulo-3.0.0 was released on 2023-08-21.
> > > > > > >
> > > > > > > 

Re: Accumulo Quarterly Report - Due Wednesday, April 10th.

[Christopher Shannon]

LGTM

On Tue, Apr 2, 2024 at 11:09 AM Ed Coleman  wrote:
>
> Thanks - I incorporated the suggestions.
>
> On 2024/04/02 14:57:56 Mark Owens wrote:
> > LGTM
> >
> > I have two small grammatical suggestions you can consider if you'd like.
> >
> > > The difference between committers and PMC members is because some
> > > PMC members have elected to go emeritus.
> >
> > The difference between committers and PMC members is due to some PMC
> > members electing to go emeritus.
> >
> >
> > > We continue to use the mailing list for official Apache business and
> > remains a channel
> > > for users to contact us.
> >
> > Perhaps change the last sentence to one of the following:
> >
> > We continue to use the mailing list for official Apache business and it
> > remains a channel
> > for users to contact us.
> >
> > or
> >
> > We continue to use the mailing list for official Apache business and as a
> > channel for users
> > to contact us.
> >
> > On Tue, Apr 2, 2024 at 2:34 PM Ed Coleman  wrote:
> >
> > > The Accumulo community decided to draft the Apache community reports on 
> > > the
> > > Accumulo dev list – and this is a draft of the April report for review /
> > > comments. The report is due by Wednesday, April 10th. I'd like to submit
> > > the report on Friday, April 5th.
> > >
> > > The text below is copied from the reporting tool and may not reflect the
> > > final formatting of the final report when submitted.
> > >
> > > Ed Coleman
> > >
> > > --- begin report text from report tool ---
> > >
> > > ## Description:
> > > The mission of Apache Accumulo is the creation and maintenance of software
> > > related to a robust, scalable, distributed key/value store with cell-based
> > > access control and customizable server-side processing.
> > >
> > > ## Project Status:
> > > - Current project status: Ongoing with high activity.
> > > - Issues for the board: None.
> > >
> > > Accumulo is currently working on some significant development efforts.
> > > Improving
> > > the performance and stability of the 2.1.x line, adding new features and
> > > performance improvements to 3.1 line, and the evolution of the processing
> > > model to support dynamic scaling and provide elasticity.
> > >
> > > ## Membership Data:
> > > Apache Accumulo was founded 2012-03-21 (12 years ago) There are currently
> > > 42
> > > committers and 39 PMC members in this project. The Committer-to-PMC ratio
> > > is
> > > roughly 1:1. It is our practice to invite committers to be PMC members at
> > > the
> > > same time. The difference between committers and PMC members is because
> > > some
> > > PMC members have elected to go emeritus.
> > >
> > > Community changes, past quarter:
> > > - No new PMC members. Last addition was Daniel Roberts on 2023-08-09.
> > > - No new committers. Last addition was Daniel Roberts on 2023-08-10.
> > >
> > > ## Project Activity:
> > >
> > > ### Releases:
> > > - accumulo-1.10.4 was released on 2023-11-16.
> > > - accumulo-2.1.2 was released on 2023-08-21.
> > > - accumulo-3.0.0 was released on 2023-08-21.
> > >
> > > The Accumulo 1-10.x line reached end-of-life and Accumulo-1.10.4 is the
> > > final release. The vote thread can be found at [1]
> > >
> > > Activity on the next release of 2.1.3, has been very active with bug-fixes
> > > and
> > > performance improvements that are being driven by community adoption of
> > > 2.1.x. Currently 174 PRs have been merged, and there are 21 open issues
> > > with 1
> > > labeled as a blocker for the release.
> > >
> > > Work is actively proceeding on 3.1.0 that will contain new features and
> > > performance improvements. Currently, 3.1.0 has 266 merged PRs.
> > >
> > > In parallel to 3.1, work continues on the evolution of the Accumulo
> > > processing
> > > model to support dynamic scaling and provide elasticity [2]. The goal for
> > > Accumulo is to move from a model where active table metadata and table 
> > > data
> > > management is hosted in active processes to a model that can dynamically
> > > scale
> > > server components on-demand to provide configurable latency and higher
> > > scalability.
> > >
> > > ### Other:
> > > 2024-02-17 Released Accumulo Access Library.  The library provides a
> > > stand-alone java library with an AccessExpression syntax and an ANTLRv4
> > > grammar that enables reuse separate from Accumulo.  Within Accumulo, the
> > > AccessExpression is used in the ColumnVisibility and VisibilityEvaluator 
> > > to
> > > provide column-level authorization for data access. The vote thread is
> > > available at [3]
> > >
> > >
> > > ## Community Health:
> > > Overall community health is good and GitHub activity remains consistent.
> > >
> > > The email traffic reflects the community preference of using GitHub
> > > projects
> > > and issues for planning and PRs for code discussions. We also use our 
> > > slack
> > > channel for day-to-day communications. We continue to use the mailing list
> > > for
> > > official Apache business and remains a 

Re: [VOTE] Apache Accumulo-Access 1.0.0-beta-rc4

[Christopher]

Seems reasonable! Thanks for the explanation.

1. Next time I recommend testing with as many rc0's as you need, then
starting at rc1, because it only really becomes a release candidate once
it's presented to the mailing list for a vote. If that turns out to be
inconvenient or impossible for some technical reason, it's not really a big
deal, but a brief explanation on the vote thread would be helpful to
clarify, so people know what happened to the earlier numbers, and don't
think they got lost in their Inbox or something.
2. Ah, that makes sense. I think it's helpful to have it in a central place
so somebody else can easily help with wrapping up the post-vote tasks, if
you were unavailable for some reason. It can also be useful for review of
the release candidate creation process, if somebody were looking at that
during their vote checks.

On Fri, Feb 16, 2024 at 7:53 AM Dave Marion  wrote:

> Christopher,
>
>   Regarding your issues, notes, etc.:
>
>   1. IIRC versions 1 and 2 were not built correctly and I did not restart
> the numbering for the first good build.
>   2. The build script gave me the option of where to put the branches and I
> wasn't sure what the correct answer was. They are in my repo and I pushed
> the one branch upstream. I can push the other if needed.
>
> On Fri, Feb 16, 2024 at 1:29 AM Christopher  wrote:
>
> > +1, I verified:
> >
> > * source-release artifact content matches contents of git checkout at the
> > commit that will be tagged
> > * signatures match and are signed by the key with the specified
> fingerprint
> > * nexus-generated md5 and sha1 hashes exist in the staging repo and match
> > the artifacts
> > * the jar, the pom, the source-release tarball, the javadoc.jar, and the
> > source.jar all have expected content
> > * the LICENSE and NOTICE files all exist and appear correct
> > * manifest includes the expected git commit ID and the jar is sealed
> > * the sha512 in the vote thread matches the source-release artifact
> > * full build with tests pass
> >
> > Note: I made a change to the staging repo. I deleted the .sha512 file
> > automatically created by the checksum-maven-plugin in the apache-release
> > profile in the parent POM, as well as the .sha512.md5 and .sha512.sha1
> > files that went with it that Nexus created. These are created with the
> > intent to be removed from the staging repo before a release, along with
> the
> > source-release tarball itself, by some projects' workflows, and the
> > checksum-maven-plugin was added to the parent POM (poorly, IMO) to
> support
> > those specific use cases. However, for Accumulo, we usually go ahead and
> > publish the source-release tarball... because that's a perfectly
> acceptable
> > distribution mechanism (Maven2-style repos are designed for artifacts
> > beyond just jar artifacts). There are many issues with the
> > checksum-maven-plugin (see
> https://issues.apache.org/jira/browse/MPOM-468
> > which discusses this in more detail). I will work to try to find a bypass
> > for our projects' POM files, but in the meantime, the workaround (which I
> > have already done) is to remove the 3 extra files (.sha512, .sha512.md5,
> > and .sha512.sha1) for the source-release artifact (but leave the
> > source-release.tar.gz, along with that tarball's .md5 and .sha1 generated
> > by Nexus). Note that this doesn't affect the main accumulo release,
> because
> > we override the source-release artifact creation and create an artifact
> > with a -src classifier instead, and the plugin is not configured to
> create
> > sha512 files for artifacts that have that classifier.
> >
> >
> > Other issues, notes, and questions about the RC prep process:
> >
> > 1. It's not a big deal, but I'm a little confused about the release
> > candidate numbering. The last one was 3, and this one is 4, but I think
> > there's only been two? Curious what happened to the first two. Also, if
> it
> > helps future release candidate preparation, I typically do a non-voting
> > test of the release candidate process and call it rc0 (even if I do it
> more
> > than once).
> >
> > 2. My next question is about the `-next` branch. In the core Accumulo
> > project, the release candidate script creates a -next branch to be merged
> > into the main (or maintenance) branch after the release vote passes. I
> > don't see that one here, and I'm wondering if that's a difference in the
> > script, or if you're doing something different for this library, and what
> > the reasoning is behind it. The reason we typically create two branches,
> is
> > because the maven-release-plugin creates

Re: [VOTE] Apache Accumulo-Access 1.0.0-beta-rc4

[Christopher Shannon]

+1 (binding)

* Validated signatures and checksums
* Verified license and notice files in archives
* Verified license headers in soue with mvn apache-rat:check
* Ran the full build and tests
* Tested out the project with a bunch of examples with different input
using the instructions on the wiki
On Fri, Feb 16, 2024 at 10:57 AM Dominic Garguilo 
wrote:

> +1 (binding)
>
> * full build passes. built from source using `mvn clean package verify
> -Perrorprone`
> * verified tests pass
> * verified the sha512 in the vote thread matches the source-release
> artifact
> * ran the example and both benchmarks using the instructions in the readme
>
>
>
> On Fri, Feb 16, 2024 at 7:53 AM Dave Marion  wrote:
>
> > Christopher,
> >
> >   Regarding your issues, notes, etc.:
> >
> >   1. IIRC versions 1 and 2 were not built correctly and I did not restart
> > the numbering for the first good build.
> >   2. The build script gave me the option of where to put the branches
> and I
> > wasn't sure what the correct answer was. They are in my repo and I pushed
> > the one branch upstream. I can push the other if needed.
> >
> > On Fri, Feb 16, 2024 at 1:29 AM Christopher  wrote:
> >
> > > +1, I verified:
> > >
> > > * source-release artifact content matches contents of git checkout at
> the
> > > commit that will be tagged
> > > * signatures match and are signed by the key with the specified
> > fingerprint
> > > * nexus-generated md5 and sha1 hashes exist in the staging repo and
> match
> > > the artifacts
> > > * the jar, the pom, the source-release tarball, the javadoc.jar, and
> the
> > > source.jar all have expected content
> > > * the LICENSE and NOTICE files all exist and appear correct
> > > * manifest includes the expected git commit ID and the jar is sealed
> > > * the sha512 in the vote thread matches the source-release artifact
> > > * full build with tests pass
> > >
> > > Note: I made a change to the staging repo. I deleted the .sha512 file
> > > automatically created by the checksum-maven-plugin in the
> apache-release
> > > profile in the parent POM, as well as the .sha512.md5 and .sha512.sha1
> > > files that went with it that Nexus created. These are created with the
> > > intent to be removed from the staging repo before a release, along with
> > the
> > > source-release tarball itself, by some projects' workflows, and the
> > > checksum-maven-plugin was added to the parent POM (poorly, IMO) to
> > support
> > > those specific use cases. However, for Accumulo, we usually go ahead
> and
> > > publish the source-release tarball... because that's a perfectly
> > acceptable
> > > distribution mechanism (Maven2-style repos are designed for artifacts
> > > beyond just jar artifacts). There are many issues with the
> > > checksum-maven-plugin (see
> > https://issues.apache.org/jira/browse/MPOM-468
> > > which discusses this in more detail). I will work to try to find a
> bypass
> > > for our projects' POM files, but in the meantime, the workaround
> (which I
> > > have already done) is to remove the 3 extra files (.sha512,
> .sha512.md5,
> > > and .sha512.sha1) for the source-release artifact (but leave the
> > > source-release.tar.gz, along with that tarball's .md5 and .sha1
> generated
> > > by Nexus). Note that this doesn't affect the main accumulo release,
> > because
> > > we override the source-release artifact creation and create an artifact
> > > with a -src classifier instead, and the plugin is not configured to
> > create
> > > sha512 files for artifacts that have that classifier.
> > >
> > >
> > > Other issues, notes, and questions about the RC prep process:
> > >
> > > 1. It's not a big deal, but I'm a little confused about the release
> > > candidate numbering. The last one was 3, and this one is 4, but I think
> > > there's only been two? Curious what happened to the first two. Also, if
> > it
> > > helps future release candidate preparation, I typically do a non-voting
> > > test of the release candidate process and call it rc0 (even if I do it
> > more
> > > than once).
> > >
> > > 2. My next question is about the `-next` branch. In the core Accumulo
> > > project, the release candidate script creates a -next branch to be
> merged
> > > into the main (or maintenance) branch after the release vote passes. I
> > > don't see that one here, and I'm wondering if

Re: [VOTE] Apache Accumulo-Access 1.0.0-beta-rc4

[Christopher]

+1, I verified:

* source-release artifact content matches contents of git checkout at the
commit that will be tagged
* signatures match and are signed by the key with the specified fingerprint
* nexus-generated md5 and sha1 hashes exist in the staging repo and match
the artifacts
* the jar, the pom, the source-release tarball, the javadoc.jar, and the
source.jar all have expected content
* the LICENSE and NOTICE files all exist and appear correct
* manifest includes the expected git commit ID and the jar is sealed
* the sha512 in the vote thread matches the source-release artifact
* full build with tests pass

Note: I made a change to the staging repo. I deleted the .sha512 file
automatically created by the checksum-maven-plugin in the apache-release
profile in the parent POM, as well as the .sha512.md5 and .sha512.sha1
files that went with it that Nexus created. These are created with the
intent to be removed from the staging repo before a release, along with the
source-release tarball itself, by some projects' workflows, and the
checksum-maven-plugin was added to the parent POM (poorly, IMO) to support
those specific use cases. However, for Accumulo, we usually go ahead and
publish the source-release tarball... because that's a perfectly acceptable
distribution mechanism (Maven2-style repos are designed for artifacts
beyond just jar artifacts). There are many issues with the
checksum-maven-plugin (see https://issues.apache.org/jira/browse/MPOM-468
which discusses this in more detail). I will work to try to find a bypass
for our projects' POM files, but in the meantime, the workaround (which I
have already done) is to remove the 3 extra files (.sha512, .sha512.md5,
and .sha512.sha1) for the source-release artifact (but leave the
source-release.tar.gz, along with that tarball's .md5 and .sha1 generated
by Nexus). Note that this doesn't affect the main accumulo release, because
we override the source-release artifact creation and create an artifact
with a -src classifier instead, and the plugin is not configured to create
sha512 files for artifacts that have that classifier.


Other issues, notes, and questions about the RC prep process:

1. It's not a big deal, but I'm a little confused about the release
candidate numbering. The last one was 3, and this one is 4, but I think
there's only been two? Curious what happened to the first two. Also, if it
helps future release candidate preparation, I typically do a non-voting
test of the release candidate process and call it rc0 (even if I do it more
than once).

2. My next question is about the `-next` branch. In the core Accumulo
project, the release candidate script creates a -next branch to be merged
into the main (or maintenance) branch after the release vote passes. I
don't see that one here, and I'm wondering if that's a difference in the
script, or if you're doing something different for this library, and what
the reasoning is behind it. The reason we typically create two branches, is
because the maven-release-plugin creates two commits to bump the version.
The first bumps to the release version (drops "-SNAPSHOT"), and the second
bumps to the next anticipated version (and re-adds the "-SNAPSHOT"). This
is the version that the script prompts you for. It also does some other
important things like changing the `` back to HEAD, which is what
it should be during development. We tag the first commit, but the second
commit (which carries the first) is what we merge into the branch. This is
the branch that is referred to in the post-vote release checklist on
line 13 (See
https://github.com/apache/accumulo-access/pull/44/files#diff-b5bd1459153d0ed1c92644d562eeb14e3e974891fefa43ea21aa5ac73d42f25fR13
)

3. The issue with the .sha512 file mentioned above should be addressed
either upstream in the parent POM (hopefully; see
https://issues.apache.org/jira/browse/MPOM-468) or as some kind of
workaround in the accumulo-access POM, so we don't have to do any manual
modification to the staging repo when doing releases. It's late tonight as
I write this, but I created the upstream issue. We'll see if it gains
traction, and if a solution arises upstream. If not, I have an idea for a
workaround locally in our project that might work for the next release or
release candidate.


On Thu, Feb 15, 2024 at 8:21 AM Dave Marion  wrote:

> +1 (binding)
>
> I did the following:
>
> verified hashes
> verified signatures
> confirmed no difference between source release tar contents and rc4 branch
> (sans dotfiles in the branch)
> confirmed LICENSE file contents are correct
> confirmed NOTICE file contents are correct and copyright date is correct
> confirmed DEPENDENCIES file contents are correct
> built the source using `mvn clean package verify -Perrorprone`
> ran the AccessExample using the commands in the README
> ran the AccessExpressionBenchmark using the commands in the README
> ran the AccessExpressionAntlrBenchmark using the commands in the README
>
> On Wed, Feb 14, 2024 at 

Re: Personal feedback on your last release vote-thread

[Christopher]

On Mon, Jan 15, 2024 at 2:18 AM Christofer Dutz
 wrote:
>
> Hi Christopher,
>
> I do understand that some of the things Apache requires from its projects may 
> seem obsolete and outdated.

I hope I didn't give the impression that that's what I think. I know
it's a common sentiment, but not one I hold.

[snip]
> So, the thing is … the “binding” is important. One of the main pillars of 
> Apache is the legal shield. This protects our contributors from prosecution.

I understand and agree. But the important bit (and the requirement) is
to *be* binding, not to use the word "binding". Merely using the word
has no effect other than to give the impression that whoever used it
understands what it means, which might not be the case. My point was
just that the release manager (and anybody else who wishes to audit
the tally) still has to check that votes are, in fact, binding,
regardless of what they say. So, *using* the word "binding" doesn't
actually seem to save anybody any work... you still gotta check, and
that's what we do.

[snip]
> I didn’t start doing these very thorough checks every month because I wanted 
> to invest so much time. Initially I started reading the board reports, maybe 
> asking a question or two and then signing them off … however did I learn 
> quite quickly that these board reports don’t always reflect reality.
[snip]
> So please forgive me, that I don’t blindly trust every project that they are 
> doing everything right. I think I would be doing a bad job if I was doing 
> that. That’s also why I started writing hopefully friendly “personal 
> feedback” emails.
>
> By simply adding a “binding” in the result email you at least tell me that 
> you have paid attention to the difference of binding and non-binding votes 
> (believe me … there are projects that don’t understand the difference) and in 
> that case, I usually don’t validate the correctness if I don’t have a reason 
> to doubt it. You are just making things easier for people doing unpleasant 
> jobs like investing 2-3 full working days (mostly on the weekend and after 
> work) each month with nothing else than having 2-3 coffee and reviewing the 
> projects activity.
>

I appreciate that you're doing that extra quality control and
oversight work. I can imagine it's a lot. I just don't see how having
the word "binding" anywhere would have helped you reduce your audit
workload. This is because I would be wary about "blindly trusting"
that projects who use the word "binding" are actually using it
correctly. A project can still add the word "binding" with a
misunderstanding of what that word means, or worse, they could be lazy
and just add the word because they know you're looking for it, without
actually doing any due diligence to check that the votes were, in
fact, binding ones. In order to properly audit that votes are being
tallied correctly, you still have to dig just as deep to verify.

If anything, I think it'd be better to say something like "x +1 votes
from PMC members" rather than "x binding +1 votes". The former doesn't
use the word "binding", but still demonstrates what it means for the
votes to *be* binding, better than merely using the word.

In any case, I hope I've at least reassured you that our project does,
in fact, know the difference, and are tallying our votes correctly. In
future, we can try to include wording in our RESULT emails that makes
it more clear that the votes we've tallied represent binding ones.

>
>
> Thanks, and sorry for the many words in this email ;-)
>

No worries. I understand the feeling. I write long emails too. I
composed this response in 5 minutes, and spent 3 hours trying to edit
it down. I hope you were more efficient with your time! LOL

>
>
>
>
> Chris
>
>
>
>
>
> Von: Christopher 
> Datum: Montag, 15. Januar 2024 um 00:21
> An: accumulo-dev 
> Cc: cd...@apache.org 
> Betreff: Re: Personal feedback on your last release vote-thread
>
> Hi Christofer,
>
>
>
> I've seen other projects do this and I disagree that it's useful for us to do 
> that on each vote.
>
>
>
> First, we are a relatively small community of active committers and typically 
> already aware of who among us is in the PMC and who isn't.
>
>
>
> Second, aside from a few emeritus PMC members, all our committers are also 
> PMC members. And we have a relatively low barrier to entry. So we only have a 
> handful of active contributors who aren't PMC members at any given time, and 
> we'd notice if they voted, or if somebody we didn't recognize tried to vote.
>
>
>
> Third, on the rare occasion when a non-committer votes, they usually specify 
> non-binding.
>
>
>
> Fourth, and most importantly, specifying that a vote is b

Re: Personal feedback on your last release vote-thread

[Christopher]

Hi Christofer,

I've seen other projects do this and I disagree that it's useful for us to
do that on each vote.

First, we are a relatively small community of active committers and
typically already aware of who among us is in the PMC and who isn't.

Second, aside from a few emeritus PMC members, all our committers are also
PMC members. And we have a relatively low barrier to entry. So we only have
a handful of active contributors who aren't PMC members at any given time,
and we'd notice if they voted, or if somebody we didn't recognize tried to
vote.

Third, on the rare occasion when a non-committer votes, they usually
specify non-binding.

Fourth, and most importantly, specifying that a vote is binding doesn't
make it binding. What makes it binding is if the voter is a PMC member. If
the release manager who tallies the vote isn't already aware of who is a
PMC member or not, it would be their responsibility to check, regardless of
what the voter said about their own vote, and the tally is subject to
review by all for correction. So, specifying it doesn't actually help at
all. It just adds noise. I actually think that specifying it is counter
productive, because the release manager could start relying on what the
user said instead of doing their due diligence to verify when they tally.

Speaking frankly, I don't personally find it useful, and I'm most often the
one lately who steps up to be a release manager for our votes. I verify
every time who is on the PMC list, regardless of what people say in their
vote, as I consider it the responsibility of whoever tallies the vote to
get an accurate count, and I would do the same to verify the tally if
somebody else were to do it. I think this practice of declaring a vote
binding is one of those strange customs that has worked its way into some
projects because somebody did it once and others copied it without
questioning it's value. But I have questioned its value and find it to be
without any.

As for mentioning it in the RESULT email, if there are both kinds of votes,
we do mention the non-binding ones separately. In our last RESULT email,
however, I merely said that it "passes with 6 +1s". Since we are aware that
only binding votes can cause a vote to pass, it is clearly implied that
they were binding. Ultimately, this comes down to trust. If you trust that
we tallied the vote correctly, then mentioning they were binding votes is
merely redundant. However, if you don't trust that we did it correctly, or
just want to double check, then you should not merely accept what we said
and should check each vote regardless of what we said, just as you did. In
either case, explicitly specifying that they were binding doesn't actually
help, I think

Regardless, thank you for double checking our tally and for providing this
feedback. If it helps, we can try to be more clear in the RESULT emails
with some redundancy, but I think it's strange to trust a count more just
because of the presence of redundant phrasing. If I were to audit a vote,
I'd check the count, regardless of how it was phrased. I also don't think
it's useful at all to ask all voters to specify it in their individual
votes, for the reasons stated above, especially that it's a potentially
harmful custom if the release manager relies on it.

Kind regards,
Christopher


On Sun, Jan 14, 2024, 10:14 Christofer Dutz  wrote:

> Hi all,
>
> while reviewing the project's activity as part of me preparing for the
> upcoming board meeting, i noticed that in the last vote thread, there were
> only simple +1 votes and no mentions of them being binding votes or not.
> Even if this is quite common throughout project, it would be good, if in
> the result email they would explicitly be mentioned as binding votes, if
> they were counted as such.
>
> I currently had to check each name with the PMC list in order to check
> that they were all actually binding votes.
>
> Chris
>
> PS: If you reply to this email, please make sure I'm in CC, as I'm not
> subscribed to this list.
>

Re: Accumulo Board Report - due by Wed Jan 10th

[Christopher Shannon]

LGTM as well

On Fri, Jan 5, 2024 at 10:45 AM Christopher  wrote:

> Looks good to me.
>
> On Fri, Jan 5, 2024 at 10:43 AM Dave Marion  wrote:
> >
> > Looks good Ed. Thanks!
> >
> > On Fri, Jan 5, 2024 at 10:20 AM dev1  wrote:
> >
> > >
> > >
> > > The Accumulo community decided to draft the Apache community reports on
> > > the Accumulo dev list – and this is a draft of the January report for
> > > review / comments.  The report is due by Jan 10th.
> > >
> > > The text below is copied from the reporting tool and may not reflect
> the
> > > final formatting of the final report when submitted.
> > >
> > > Ed Coleman
> > >
> > > --- report tool text ---
> > >
> > > ## Description:
> > > The mission of Apache Accumulo is the creation and maintenance of
> software
> > > related to a robust, scalable, distributed key/value store with
> cell-based
> > > access control and customizable server-side processing.
> > >
> > > ## Project Status:
> > > - Current project status: Ongoing with high activity.
> > > - Issues for the board: None.
> > >
> > > Accumulo is currently working some significant development efforts.
> > > Improving
> > > the performance and stability of the 2.1.x line, adding new features
> and
> > > performance improvements to 3.1 line, and the evolution of the
> processing
> > > model to support dynamic scaling and provide elasticity.
> > >
> > > ## Membership Data:
> > > Apache Accumulo was founded 2012-03-21 (12 years ago) There are
> currently
> > > 42
> > > committers and 39 PMC members in this project. The Committer-to-PMC
> ratio
> > > is
> > > roughly 1:1. It is our practice to invite committers to be PMC members
> at
> > > the
> > > same time. The difference between committer and PMC members is because
> some
> > > PMC members have elected to go emeritus.
> > >
> > > Community changes, past quarter:
> > > - No new PMC members. Last addition was Daniel Roberts on 2023-08-09.
> > > - No new committers. Last addition was Daniel Roberts on 2023-08-10.
> > >
> > > ## Project Activity:
> > >
> > > ### Releases:
> > >
> > > - accumulo-1.10.4 was released on 2023-11-16.
> > > - accumulo-2.1.2 was released on 2023-08-21.
> > > - accumulo-3.0.0 was released on 2023-08-21.
> > >
> > > The Accumulo 1-10.x line has reached end-of-life and Accumulo-1.10.4
> is the
> > > final release. The vote thread can be found at [1]
> > >
> > > Activity on the next release of 2.1.3, has been very active with
> bug-fixes
> > > and performance improvements that are being driven by community
> adoption of
> > > 2.1.x. It is expected that we will release 2.1.3 in this quarter.
> Currently
> > > 106 PRs have been merged, and there are 18 open issues with 2 labeled
> as a
> > > blocker for the release.
> > >
> > > Work is actively proceeding on 3.1.0 that will contain new features and
> > > performance improvements.  Currently, 3.1.0 has 187 merged PRs.
> > >
> > > In parallel to 3.1, work continues on the evolution of the Accumulo
> > > processing
> > > model to support dynamic scaling and provide elasticity [2]. The goal
> for
> > > Accumulo is to move from a model where active table metadata and table
> data
> > > management is hosted in active processes to a model that can
> dynamically
> > > scale
> > > server components on-demand to provide configurable latency and higher
> > > scalability.
> > >
> > > ## Community Health:
> > >
> > > Overall community health is good and GitHub activity remains
> consistent.
> > >
> > > The low email traffic reflects the community preference of using GitHub
> > > projects and issues for planning and PRs for code discussions.  We
> also use
> > > our slack channel for day-to-day communications.  We continue to use
> the
> > > mailing list for official Apache business and remains a channel for
> users
> > > to
> > > contact us.
> > >
> > > ## Links
> > > [1] https://lists.apache.org/thread/6jy0v0qk14163xx19ocz4l3xxc1rzr3z
> > > [2] https://github.com/orgs/apache/projects/164/views/1
> > >
> > > --- end report tool text
> > >
>

Re: Accumulo Board Report - due by Wed Jan 10th

[Christopher]

Looks good to me.

On Fri, Jan 5, 2024 at 10:43 AM Dave Marion  wrote:
>
> Looks good Ed. Thanks!
>
> On Fri, Jan 5, 2024 at 10:20 AM dev1  wrote:
>
> >
> >
> > The Accumulo community decided to draft the Apache community reports on
> > the Accumulo dev list – and this is a draft of the January report for
> > review / comments.  The report is due by Jan 10th.
> >
> > The text below is copied from the reporting tool and may not reflect the
> > final formatting of the final report when submitted.
> >
> > Ed Coleman
> >
> > --- report tool text ---
> >
> > ## Description:
> > The mission of Apache Accumulo is the creation and maintenance of software
> > related to a robust, scalable, distributed key/value store with cell-based
> > access control and customizable server-side processing.
> >
> > ## Project Status:
> > - Current project status: Ongoing with high activity.
> > - Issues for the board: None.
> >
> > Accumulo is currently working some significant development efforts.
> > Improving
> > the performance and stability of the 2.1.x line, adding new features and
> > performance improvements to 3.1 line, and the evolution of the processing
> > model to support dynamic scaling and provide elasticity.
> >
> > ## Membership Data:
> > Apache Accumulo was founded 2012-03-21 (12 years ago) There are currently
> > 42
> > committers and 39 PMC members in this project. The Committer-to-PMC ratio
> > is
> > roughly 1:1. It is our practice to invite committers to be PMC members at
> > the
> > same time. The difference between committer and PMC members is because some
> > PMC members have elected to go emeritus.
> >
> > Community changes, past quarter:
> > - No new PMC members. Last addition was Daniel Roberts on 2023-08-09.
> > - No new committers. Last addition was Daniel Roberts on 2023-08-10.
> >
> > ## Project Activity:
> >
> > ### Releases:
> >
> > - accumulo-1.10.4 was released on 2023-11-16.
> > - accumulo-2.1.2 was released on 2023-08-21.
> > - accumulo-3.0.0 was released on 2023-08-21.
> >
> > The Accumulo 1-10.x line has reached end-of-life and Accumulo-1.10.4 is the
> > final release. The vote thread can be found at [1]
> >
> > Activity on the next release of 2.1.3, has been very active with bug-fixes
> > and performance improvements that are being driven by community adoption of
> > 2.1.x. It is expected that we will release 2.1.3 in this quarter. Currently
> > 106 PRs have been merged, and there are 18 open issues with 2 labeled as a
> > blocker for the release.
> >
> > Work is actively proceeding on 3.1.0 that will contain new features and
> > performance improvements.  Currently, 3.1.0 has 187 merged PRs.
> >
> > In parallel to 3.1, work continues on the evolution of the Accumulo
> > processing
> > model to support dynamic scaling and provide elasticity [2]. The goal for
> > Accumulo is to move from a model where active table metadata and table data
> > management is hosted in active processes to a model that can dynamically
> > scale
> > server components on-demand to provide configurable latency and higher
> > scalability.
> >
> > ## Community Health:
> >
> > Overall community health is good and GitHub activity remains consistent.
> >
> > The low email traffic reflects the community preference of using GitHub
> > projects and issues for planning and PRs for code discussions.  We also use
> > our slack channel for day-to-day communications.  We continue to use the
> > mailing list for official Apache business and remains a channel for users
> > to
> > contact us.
> >
> > ## Links
> > [1] https://lists.apache.org/thread/6jy0v0qk14163xx19ocz4l3xxc1rzr3z
> > [2] https://github.com/orgs/apache/projects/164/views/1
> >
> > --- end report tool text
> >

[DRAFT][ANNOUNCE] Apache Accumulo 1.10.4

[Christopher]

The following is the draft of the announcement for 1.10.4
***

The Apache Accumulo project is pleased to announce the release of
Apache Accumulo 1.10.4! Apache Accumulo 1.10.4 is the final bug fix
release of the 1.10 LTM release line. After this release, the 1.10
release line will be considered end-of-life. Future bugs reported
against this version are expected to only be fixed in newer release
series, such as the current LTM version, 2.1.

Users of any 1.x version are encouraged to upgrade to a newer,
supported release series, such as 2.1, but this version is still being
made available for users who are unable to upgrade beyond 1.10 at this
time, and represents the last few bug fixes available from the PMC for
1.10.

***

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

[RESULT][VOTE] Apache Accumulo 1.10.4-rc1

[Christopher]

This vote passes with 6 +1s and no other votes.

Thanks all.

The post-vote release steps are being tracked at:
https://github.com/apache/accumulo/issues/3947

On Thu, Nov 16, 2023 at 3:59 PM Christopher  wrote:
>
> I offer my +1 as well.
> I checked the signatures and and checksums, and verified the contents
> match the expected git checkout, and verified all the ITs pass using
> Java 11.
>
> On Wed, Nov 15, 2023 at 5:33 PM Keith Turner  wrote:
> >
> > +1
> >
> > Looked over the diffs between 1.10.3 and 1.10.4-rc1
> >
> > On Mon, Nov 13, 2023 at 9:42 AM Christopher  wrote:
> >
> > > Accumulo Developers,
> > >
> > > Please consider the following candidate for Apache Accumulo 1.10.4 (a
> > > closeout final release for 1.10)
> > >
> > > Git Commit:
> > > 47ac68d1a220a90bc80618f9684252b243df6b27
> > > Branch:
> > > 1.10.4-rc1
> > >
> > > If this vote passes, a gpg-signed tag will be created using:
> > > git tag -f -s -m 'Apache Accumulo 1.10.4' rel/1.10.4 \
> > > 47ac68d1a220a90bc80618f9684252b243df6b27
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/orgapacheaccumulo-1107
> > > Source (official release artifact):
> > >
> > > https://repository.apache.org/content/repositories/orgapacheaccumulo-1107/org/apache/accumulo/accumulo/1.10.4/accumulo-1.10.4-src.tar.gz
> > > Binary:
> > > https://repository.apache.org/content/repositories/orgapacheaccumulo-1107/org/apache/accumulo/accumulo/1.10.4/accumulo-1.10.4-bin.tar.gz
> > >
> > > Append ".asc" to download the cryptographic signature for a given 
> > > artifact.
> > > (You can also append ".sha1" or ".md5" instead in order to verify the
> > > checksums
> > > generated by Maven to verify the integrity of the Nexus repository
> > > staging area.)
> > >
> > > Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> > > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> > >
> > > In addition to the tarballs and their signatures, the following checksum
> > > files will be added to the dist/release SVN area after release:
> > > accumulo-1.10.4-src.tar.gz.sha512 will contain:
> > > SHA512 (accumulo-1.10.4-src.tar.gz) =
> > >
> > > 78233784261031a3f6bf18f5c503ad1c9b52098b443291ffcd491785c49f3cc9f8ea2c0904719bf82b52d668ae35025c5b63d23729135120ade367e9c457
> > > accumulo-1.10.4-bin.tar.gz.sha512 will contain:
> > > SHA512 (accumulo-1.10.4-bin.tar.gz) =
> > >
> > > fbd7b7449c2ddd438ec966e6e13835cd85e11a349991ab7ca47bc4f7f84b8844ca5e5933f8068bd166c121f65fe4f35afaa8182787fd83589f458e96009bd2f6
> > >
> > > Release notes (in progress) can be found at:
> > > https://accumulo.apache.org/release/accumulo-1.10.4
> > >
> > > Release testing instructions:
> > > https://accumulo.apache.org/contributor/verifying-release
> > >
> > > 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.10.4 release of Apache Accumulo.
> > >
> > > This vote will remain open until at least Thu Nov 16 03:00:00 PM UTC 2023.
> > > (Thu Nov 16 10:00:00 AM EST 2023 / Thu Nov 16 07:00:00 AM PST 2023)
> > > Voting can continue after this deadline until the release manager
> > > sends an email ending 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-1107/
> > > # note the trailing slash is needed
> > >

Re: [VOTE] Apache Accumulo 1.10.4-rc1

[Christopher]

I offer my +1 as well.
I checked the signatures and and checksums, and verified the contents
match the expected git checkout, and verified all the ITs pass using
Java 11.

On Wed, Nov 15, 2023 at 5:33 PM Keith Turner  wrote:
>
> +1
>
> Looked over the diffs between 1.10.3 and 1.10.4-rc1
>
> On Mon, Nov 13, 2023 at 9:42 AM Christopher  wrote:
>
> > Accumulo Developers,
> >
> > Please consider the following candidate for Apache Accumulo 1.10.4 (a
> > closeout final release for 1.10)
> >
> > Git Commit:
> > 47ac68d1a220a90bc80618f9684252b243df6b27
> > Branch:
> > 1.10.4-rc1
> >
> > If this vote passes, a gpg-signed tag will be created using:
> > git tag -f -s -m 'Apache Accumulo 1.10.4' rel/1.10.4 \
> > 47ac68d1a220a90bc80618f9684252b243df6b27
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapacheaccumulo-1107
> > Source (official release artifact):
> >
> > https://repository.apache.org/content/repositories/orgapacheaccumulo-1107/org/apache/accumulo/accumulo/1.10.4/accumulo-1.10.4-src.tar.gz
> > Binary:
> > https://repository.apache.org/content/repositories/orgapacheaccumulo-1107/org/apache/accumulo/accumulo/1.10.4/accumulo-1.10.4-bin.tar.gz
> >
> > Append ".asc" to download the cryptographic signature for a given artifact.
> > (You can also append ".sha1" or ".md5" instead in order to verify the
> > checksums
> > generated by Maven to verify the integrity of the Nexus repository
> > staging area.)
> >
> > Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> >
> > In addition to the tarballs and their signatures, the following checksum
> > files will be added to the dist/release SVN area after release:
> > accumulo-1.10.4-src.tar.gz.sha512 will contain:
> > SHA512 (accumulo-1.10.4-src.tar.gz) =
> >
> > 78233784261031a3f6bf18f5c503ad1c9b52098b443291ffcd491785c49f3cc9f8ea2c0904719bf82b52d668ae35025c5b63d23729135120ade367e9c457
> > accumulo-1.10.4-bin.tar.gz.sha512 will contain:
> > SHA512 (accumulo-1.10.4-bin.tar.gz) =
> >
> > fbd7b7449c2ddd438ec966e6e13835cd85e11a349991ab7ca47bc4f7f84b8844ca5e5933f8068bd166c121f65fe4f35afaa8182787fd83589f458e96009bd2f6
> >
> > Release notes (in progress) can be found at:
> > https://accumulo.apache.org/release/accumulo-1.10.4
> >
> > Release testing instructions:
> > https://accumulo.apache.org/contributor/verifying-release
> >
> > 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.10.4 release of Apache Accumulo.
> >
> > This vote will remain open until at least Thu Nov 16 03:00:00 PM UTC 2023.
> > (Thu Nov 16 10:00:00 AM EST 2023 / Thu Nov 16 07:00:00 AM PST 2023)
> > Voting can continue after this deadline until the release manager
> > sends an email ending 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-1107/
> > # note the trailing slash is needed
> >

Re: [VOTE] Apache Accumulo 1.10.4-rc1

[Christopher Shannon]

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Verified source license headers with 'mvn apache-rat:check'
* Built and ran all the sunny integration tests
* Started up using Uno to make sure everything started correctly (also ran
a couple scans, etc)

On Wed, Nov 15, 2023 at 11:46 AM Dominic Garguilo 
wrote:

> +1
>
>
>- Verified signatures
>- built from source
>- ran sunny day tests
>- ran ingest and verify with the following stats:
>org.apache.accumulo.test.continuous.ContinuousVerify$Counts
>REFERENCED=146147488
>UNREFERENCED=105
>
>
> On Mon, Nov 13, 2023 at 9:42 AM Christopher  wrote:
>
> > Accumulo Developers,
> >
> > Please consider the following candidate for Apache Accumulo 1.10.4 (a
> > closeout final release for 1.10)
> >
> > Git Commit:
> > 47ac68d1a220a90bc80618f9684252b243df6b27
> > Branch:
> > 1.10.4-rc1
> >
> > If this vote passes, a gpg-signed tag will be created using:
> > git tag -f -s -m 'Apache Accumulo 1.10.4' rel/1.10.4 \
> > 47ac68d1a220a90bc80618f9684252b243df6b27
> >
> > Staging repo:
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1107
> > Source (official release artifact):
> >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1107/org/apache/accumulo/accumulo/1.10.4/accumulo-1.10.4-src.tar.gz
> > Binary:
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1107/org/apache/accumulo/accumulo/1.10.4/accumulo-1.10.4-bin.tar.gz
> >
> > Append ".asc" to download the cryptographic signature for a given
> artifact.
> > (You can also append ".sha1" or ".md5" instead in order to verify the
> > checksums
> > generated by Maven to verify the integrity of the Nexus repository
> > staging area.)
> >
> > Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> >
> > In addition to the tarballs and their signatures, the following checksum
> > files will be added to the dist/release SVN area after release:
> > accumulo-1.10.4-src.tar.gz.sha512 will contain:
> > SHA512 (accumulo-1.10.4-src.tar.gz) =
> >
> >
> 78233784261031a3f6bf18f5c503ad1c9b52098b443291ffcd491785c49f3cc9f8ea2c0904719bf82b52d668ae35025c5b63d23729135120ade367e9c457
> > accumulo-1.10.4-bin.tar.gz.sha512 will contain:
> > SHA512 (accumulo-1.10.4-bin.tar.gz) =
> >
> >
> fbd7b7449c2ddd438ec966e6e13835cd85e11a349991ab7ca47bc4f7f84b8844ca5e5933f8068bd166c121f65fe4f35afaa8182787fd83589f458e96009bd2f6
> >
> > Release notes (in progress) can be found at:
> > https://accumulo.apache.org/release/accumulo-1.10.4
> >
> > Release testing instructions:
> > https://accumulo.apache.org/contributor/verifying-release
> >
> > 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.10.4 release of Apache Accumulo.
> >
> > This vote will remain open until at least Thu Nov 16 03:00:00 PM UTC
> 2023.
> > (Thu Nov 16 10:00:00 AM EST 2023 / Thu Nov 16 07:00:00 AM PST 2023)
> > Voting can continue after this deadline until the release manager
> > sends an email ending 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-1107/
> > # note the trailing slash is needed
> >
>

[VOTE] Apache Accumulo 1.10.4-rc1

[Christopher]

Accumulo Developers,

Please consider the following candidate for Apache Accumulo 1.10.4 (a
closeout final release for 1.10)

Git Commit:
47ac68d1a220a90bc80618f9684252b243df6b27
Branch:
1.10.4-rc1

If this vote passes, a gpg-signed tag will be created using:
git tag -f -s -m 'Apache Accumulo 1.10.4' rel/1.10.4 \
47ac68d1a220a90bc80618f9684252b243df6b27

Staging repo: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1107
Source (official release artifact):
https://repository.apache.org/content/repositories/orgapacheaccumulo-1107/org/apache/accumulo/accumulo/1.10.4/accumulo-1.10.4-src.tar.gz
Binary: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1107/org/apache/accumulo/accumulo/1.10.4/accumulo-1.10.4-bin.tar.gz

Append ".asc" to download the cryptographic signature for a given artifact.
(You can also append ".sha1" or ".md5" instead in order to verify the checksums
generated by Maven to verify the integrity of the Nexus repository
staging area.)

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

In addition to the tarballs and their signatures, the following checksum
files will be added to the dist/release SVN area after release:
accumulo-1.10.4-src.tar.gz.sha512 will contain:
SHA512 (accumulo-1.10.4-src.tar.gz) =
78233784261031a3f6bf18f5c503ad1c9b52098b443291ffcd491785c49f3cc9f8ea2c0904719bf82b52d668ae35025c5b63d23729135120ade367e9c457
accumulo-1.10.4-bin.tar.gz.sha512 will contain:
SHA512 (accumulo-1.10.4-bin.tar.gz) =
fbd7b7449c2ddd438ec966e6e13835cd85e11a349991ab7ca47bc4f7f84b8844ca5e5933f8068bd166c121f65fe4f35afaa8182787fd83589f458e96009bd2f6

Release notes (in progress) can be found at:
https://accumulo.apache.org/release/accumulo-1.10.4

Release testing instructions:
https://accumulo.apache.org/contributor/verifying-release

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.10.4 release of Apache Accumulo.

This vote will remain open until at least Thu Nov 16 03:00:00 PM UTC 2023.
(Thu Nov 16 10:00:00 AM EST 2023 / Thu Nov 16 07:00:00 AM PST 2023)
Voting can continue after this deadline until the release manager
sends an email ending 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-1107/
# note the trailing slash is needed

Re: accumulo upgrade from 2.0.1 to 2.1.1

[Christopher]

On Sat, Oct 14, 2023 at 9:41 AM Vincent Russell
 wrote:
>
> Christopher,
>
> I don't remember configuring anything with regards to commons-vfs.  How do
> I disable this?

There's some VFS stuff enabled by default, for backwards
compatibility. There isn't an explicit way to disable it. It's being
phased out, so that it's entirely optional, via a pluggable mechanism,
if somebody wants to use it. But I've never seen the default stuff
cause any errors like what you're seeing if you're not using it to
specify any non-local paths in your classpath properties.

>
> After continuously hitting refresh on either monitor they just continuously
> say the manager is down.
>
> I"ll dig some more on Monday.
>
> Thanks for the response.
>
> -Vincent
>
> On Fri, Oct 13, 2023 at 5:39 PM Christopher  wrote:
>
> > I am not sure what's up with the VFS error. I generally recommend
> > against using commons-vfs, because of the lack of any known good
> > versions, and the fact that most of what it is used for can be done
> > better in other ways. We have taken steps in recent versions to make
> > sure that the classloader stuff is more pluggable, so people do not
> > have to rely on commons-vfs, if they don't want to use it. One thing
> > that's concerning is that VFS is using some temp file in /tmp, which
> > could be wiped at any time by the OS, so if you do have need of VFS,
> > you may want to consider customizing it to use a different directory,
> > that isn't going to be wiped periodically by the OS. I believe the
> > relevant Accumulo property is: general.vfs.cache.dir
> >
> > The manager is down message is expected on initial startup if the
> > monitor starts faster than the manager, but refreshing the page should
> > make it work eventually if the manager is actually running. If that
> > doesn't happen eventually, I'm not sure what could be happening
> > without further troubleshooting.
> >
> > On Thu, Oct 12, 2023 at 12:36 PM Vincent Russell
> >  wrote:
> > >
> > > Christopher,
> > >
> > > I have run through an upgrade with a bit more data than I did previously
> > > and monitors with high availability just don't seem as consistent as they
> > > were with 2.0.1.
> > >
> > > After upgrading both accumulo monitors are reporting "Manager is Down"
> > and
> > > I was only able to achieve that after restarting both of the monitors and
> > > managers multiple times.
> > >
> > > The only ERROR log that I see in the manager logs are (at startup):
> > >
> > > java.nio.File.NoSuchFileException: /tmp/accumulo-vfs-cache-410@hostname
> > > 
> > > at
> > >
> > org.accumulo.start.classloader.vfs.AccumuloVFSClassLoader.close(AccumuloVFSClassloader.java:453)
> > >
> > > I see this on both managers.
> > >
> > > Any ideas?
> > >
> > > Thanks,
> > >
> > > On Mon, Sep 25, 2023 at 12:21 PM Christopher 
> > wrote:
> > >
> > > > I'm not sure about the monitor behavior. I've never had a reason to
> > > > run more than one, and I don't think we have any well-defined behavior
> > > > for trying to run more than one (I could see an argument for both). It
> > > > would be weird if one incorrectly reported "Master[now Manager] is
> > > > down" because another monitor was running, though. I would expect the
> > > > 2.1 behavior you described over that 2.0 behavior.
> > > >
> > > > On Mon, Sep 25, 2023 at 11:59 AM Vincent Russell
> > > >  wrote:
> > > > >
> > > > > Thank you Christopher,
> > > > >
> > > > > I did neglect to update the log4j2 files.
> > > > >
> > > > > One thing that is weird is that the monitors appear to work
> > differently
> > > > > with high availability.
> > > > >
> > > > > With 2.0.1 the accumulo monitors both work and you can hit them both
> > (one
> > > > > just says 'Master is down'; however, with 2.1.1, it appears that
> > only one
> > > > > works.Is this expected?
> > > > >
> > > > > Thank you,
> > > > >
> > > > > On Thu, Sep 14, 2023 at 4:28 PM Christopher 
> > wrote:
> > > > >
> > > > > > I do not know about the error message you saw.
> > StatusConsoleListener
> > > > > > is not an Accumulo class, but it looks like it's a log4j one. My
> > best
> &

Re: TLS Support in Accumulo

[Christopher]

I think a performance hit is expected, due to the expected overhead of the
TLS handshake, and the number of connections Accumulo requires in order to
distribute work across a cluster. I think whether the overhead is tolerable
is a per user decision, and may also be dependent upon the details of your
application, table content, query patterns, hardware, and JVM support. I'm
sure it's not suitable for everybody's use case, but could be a useful
option in some circumstances. It's really hard to make general statements
about whether it's worthwhile, though, because of different people having
different requirements and environments.

I am curious, though, if you could characterize the overhead you saw, as a
point of comparison.

On Mon, Oct 16, 2023, 23:18 Logan Jones  wrote:

> Hello:
>
> I know that Accumulo has support for TLS. When turning on TLS support, we
> noticed some pretty serious performance hits as a result of turning this on
> in 1.10.2. Does anyone actually have TLS turned on for larger clusters? Are
> there any known performance problems with turning on TLS?
>
> Thanks in advance,
>
> - Logan
>

Re: accumulo upgrade from 2.0.1 to 2.1.1

[Christopher]

I am not sure what's up with the VFS error. I generally recommend
against using commons-vfs, because of the lack of any known good
versions, and the fact that most of what it is used for can be done
better in other ways. We have taken steps in recent versions to make
sure that the classloader stuff is more pluggable, so people do not
have to rely on commons-vfs, if they don't want to use it. One thing
that's concerning is that VFS is using some temp file in /tmp, which
could be wiped at any time by the OS, so if you do have need of VFS,
you may want to consider customizing it to use a different directory,
that isn't going to be wiped periodically by the OS. I believe the
relevant Accumulo property is: general.vfs.cache.dir

The manager is down message is expected on initial startup if the
monitor starts faster than the manager, but refreshing the page should
make it work eventually if the manager is actually running. If that
doesn't happen eventually, I'm not sure what could be happening
without further troubleshooting.

On Thu, Oct 12, 2023 at 12:36 PM Vincent Russell
 wrote:
>
> Christopher,
>
> I have run through an upgrade with a bit more data than I did previously
> and monitors with high availability just don't seem as consistent as they
> were with 2.0.1.
>
> After upgrading both accumulo monitors are reporting "Manager is Down" and
> I was only able to achieve that after restarting both of the monitors and
> managers multiple times.
>
> The only ERROR log that I see in the manager logs are (at startup):
>
> java.nio.File.NoSuchFileException: /tmp/accumulo-vfs-cache-410@hostname
> 
> at
> org.accumulo.start.classloader.vfs.AccumuloVFSClassLoader.close(AccumuloVFSClassloader.java:453)
>
> I see this on both managers.
>
> Any ideas?
>
> Thanks,
>
> On Mon, Sep 25, 2023 at 12:21 PM Christopher  wrote:
>
> > I'm not sure about the monitor behavior. I've never had a reason to
> > run more than one, and I don't think we have any well-defined behavior
> > for trying to run more than one (I could see an argument for both). It
> > would be weird if one incorrectly reported "Master[now Manager] is
> > down" because another monitor was running, though. I would expect the
> > 2.1 behavior you described over that 2.0 behavior.
> >
> > On Mon, Sep 25, 2023 at 11:59 AM Vincent Russell
> >  wrote:
> > >
> > > Thank you Christopher,
> > >
> > > I did neglect to update the log4j2 files.
> > >
> > > One thing that is weird is that the monitors appear to work differently
> > > with high availability.
> > >
> > > With 2.0.1 the accumulo monitors both work and you can hit them both (one
> > > just says 'Master is down'; however, with 2.1.1, it appears that only one
> > > works.Is this expected?
> > >
> > > Thank you,
> > >
> > > On Thu, Sep 14, 2023 at 4:28 PM Christopher  wrote:
> > >
> > > > I do not know about the error message you saw. StatusConsoleListener
> > > > is not an Accumulo class, but it looks like it's a log4j one. My best
> > > > guess is that during your upgrade, you did not migrate your log4j
> > > > config files over to be based on the log4j2 ones we have as an example
> > > > in the 2.1 tarball. It's possible that there's some log4j
> > > > configuration issue that's preventing you from seeing the reason why
> > > > the Monitor failed to start.
> > > >
> > > > To troubleshoot, I would compare your log4j config with what we ship
> > > > in the 2.1 tarball and also check to see if you've done any log4j
> > > > config overrides in the system properties or environment variables
> > > > that control log4j.
> > > >
> > > > On Tue, Sep 12, 2023 at 8:10 PM Vincent Russell
> > > >  wrote:
> > > > >
> > > > > Thank you Christopher,
> > > > >
> > > > > Don't worry.  I definitely planned on testing an upgrade on a test
> > > > > cluster.   :)
> > > > >
> > > > > I just upgraded a test cluster and everything appeared to go smoothly
> > > > > except for one thing.
> > > > >
> > > > > I am able to login to the accumulo shell and I can see the table
> > that I
> > > > > created before the upgrade exists and I can scan that table.
> > > > >
> > > > > Before the upgrade the monitor was running on port 9995, but now
> > nothing
> > > > > appears to be running on that port.Nothing in the monitor lo

Re: Accumulo Board Report - due by Oct 11th

[Christopher]

Hacktoberfest registration started yesterday. I signed up. However, they
are not giving away T-shirts or stickers this year. Only planting trees and
even then only for the first x participants. So there's not a huge
incentive for people to participate like there has been in previous years,
unless you're into digital badges as rewards, which I personally think are
kind of meaningless.

All of our repos are labeled appropriately though so people can find them
and contribute if they want. We'll see if we get any new people from that
this year.

On Wed, Sep 27, 2023, 21:18 dev1  wrote:

> They do suggest a few options, but it is all subjective.  I changed it to
> high and am comfortable with that.  Pro for high (in my opinion)
>
>
>   *   Very active with releases and bug fixes for 2.1.2 and well on the
> way to releasing 2.1.3. and 1.10.4
>   *   Major things in the works, no-chop, elasticity…
>   *   Active discussions and responsive to user’s needs.
>   *   Quickly addressing reported CVEs with dependencies.
>
> All which point to an active, healthy project.
>
> My initial choice of moderate was more from an ASF community perspective.
> In the past we used to have a wider set of contributions from different
> entities. While we do get the occasional inquiry, none of those recently
> have chosen to engage enough to provide contributions.  I mention this as
> something we need to be aware of as a community.
>
> If nothing else, it provides an opportunity to have these discussions on
> the dev list.
>
> It also occurs to me that October and hence Hacktober may soon be upon
> us.  We may want to make sure that we state that we are participating
> (assuming that we are) and maybe make sure that we have some good
> first-issues identified.
>
> Ed Coleman
>
>
> From: Christopher 
> Date: Wednesday, September 27, 2023 at 8:09 PM
> To: dev@accumulo.apache.org 
> Subject: Re: Accumulo Board Report - due by Oct 11th
> Now that I think about it, I wonder if "Moderate" was a drop-down
> selection from the reporter tool. I seem to remember having a similar
> observation for the last report. If that's the case, then it probably
> doesn't matter what you select. Sorry if my feedback on that point was
> misplaced. I'll trust you to leave it whichever way you think is best,
> even if you decide that it's better to change it back to Moderate.
>
> On Wed, Sep 27, 2023 at 5:29 PM dev1  wrote:
> >
> > I included Christopher’s and Dan’s suggestions.  The current report text
> reads:
> >
> > --- text pasted from report tool ---
> >
> > ## Description:
> > The mission of Apache Accumulo is the creation and maintenance of
> software
> > related to a robust, scalable, distributed key/value store with
> cell-based
> > access control and customizable server-side processing.
> >
> > ## Project Status:
> > - Current project status: Ongoing with high activity.
> > - Issues for the board: None.
> >
> > Accumulo is currently working some significant development efforts.
> Improving
> > the performance and stability of the 2.1.x line, adding new features and
> > performance improvements to 3.1 line, and the evolution of the processing
> > model to support dynamic scaling and provide elasticity.
> >
> > The issue concerning accumulodata.com domain was raised at the last
> board
> > meeting. We have not been reporting on the issue because there has been
> no
> > progress and we stopped actively pursuing the issue (see past reports for
> > details.) The domain was registered and is owned by an Accumulo PMC
> member,
> > but the domain was registered using an account that is not longer
> accessible.
> > Without access to that account, the registrar will not take any action.
> For
> > some reason, the domain continues to be auto-renewed.  The domain clearly
> > provides historical information and points to the official Accumulo ASF
> site
> > for downloads. There seems little incentive to use volunteer's time to
> pursue
> > the issue at this time.  Unless things change, we will not continue to
> report
> > on this issue in future reports.
> >
> > ## Membership Data:
> > Apache Accumulo was founded 2012-03-21 (12 years ago) There are
> currently 42
> > committers and 39 PMC members in this project. Our committer and PMC
> ratio is
> > roughly 1:1. It is our practice to invite committers to be PMC members
> at the
> > same time. The difference between committer and PMC members is because
> some
> > PMC members have elected to go emeritus.
> >
> > Community changes, past quarter:
> > - Daniel Roberts was added to the PMC on 2023-08-09

Re: Accumulo Board Report - due by Oct 11th

[Christopher]

Now that I think about it, I wonder if "Moderate" was a drop-down
selection from the reporter tool. I seem to remember having a similar
observation for the last report. If that's the case, then it probably
doesn't matter what you select. Sorry if my feedback on that point was
misplaced. I'll trust you to leave it whichever way you think is best,
even if you decide that it's better to change it back to Moderate.

On Wed, Sep 27, 2023 at 5:29 PM dev1  wrote:
>
> I included Christopher’s and Dan’s suggestions.  The current report text 
> reads:
>
> --- text pasted from report tool ---
>
> ## Description:
> The mission of Apache Accumulo is the creation and maintenance of software
> related to a robust, scalable, distributed key/value store with cell-based
> access control and customizable server-side processing.
>
> ## Project Status:
> - Current project status: Ongoing with high activity.
> - Issues for the board: None.
>
> Accumulo is currently working some significant development efforts. Improving
> the performance and stability of the 2.1.x line, adding new features and
> performance improvements to 3.1 line, and the evolution of the processing
> model to support dynamic scaling and provide elasticity.
>
> The issue concerning accumulodata.com domain was raised at the last board
> meeting. We have not been reporting on the issue because there has been no
> progress and we stopped actively pursuing the issue (see past reports for
> details.) The domain was registered and is owned by an Accumulo PMC member,
> but the domain was registered using an account that is not longer accessible.
> Without access to that account, the registrar will not take any action.  For
> some reason, the domain continues to be auto-renewed.  The domain clearly
> provides historical information and points to the official Accumulo ASF site
> for downloads. There seems little incentive to use volunteer's time to pursue
> the issue at this time.  Unless things change, we will not continue to report
> on this issue in future reports.
>
> ## Membership Data:
> Apache Accumulo was founded 2012-03-21 (12 years ago) There are currently 42
> committers and 39 PMC members in this project. Our committer and PMC ratio is
> roughly 1:1. It is our practice to invite committers to be PMC members at the
> same time. The difference between committer and PMC members is because some
> PMC members have elected to go emeritus.
>
> Community changes, past quarter:
> - Daniel Roberts was added to the PMC on 2023-08-09
> - Daniel Roberts was added as committer on 2023-08-10
>
> ## Project Activity:
>
> ### Releases:
>
> - accumulo-2.1.2 was released on 2023-08-21.
> - accumulo-3.0.0 was released on 2023-08-21.
> - accumulo-1.10.3 was released on 2023-04-13.
>
> Activity on 2.1.3 has been very active with bug-fixes and performance
> improvements that are being driven by community adoption of 2.1.x as
> 1.10.x approaches end of life.
>
> Accumulo is planning on a 2.1.3 release [1] this quarter with additional bug
> fixes and performance improvements. As of 2023-09-27, there have been 40
> issues / PR closed since 2.1.2 was released.  There are just a few items that
> have been marked as blockers for 2.1.3, and they are actively being worked.
>
> Accumulo is planning on a 1.10.4 release [2] this quarter as the last release
> of the 1.10 line that reaches declared end-of-life 2023-11-01.
>
> Accumulo 3.0.0 release was a removal of deprecated items as permitted by
> semver. Work is actively proceeding on 3.1 that will contain new features and
> performance improvements.
>
> In parallel to 3.1, work on the evolution of the Accumulo processing model to
> support dynamic scaling and provide elasticity [3]. The goal for Accumulo is
> to move from a model where active table metadata and table data management is
> hosted in active processes to a model that can dynamically scale server
> components on-demand to provide configurable latency and higher scalability.
> The working being perfumed on elasticity will likely be a 4.0 release, but
> that has not been formally decided by the community.
>
> ## Community Health:
>
> Overall community health is good and GitHub activity remains consistent.
>
> - The current variations in GitHub activity are due to quiet post-release
>   activity and work concentrating on a redesign efforts, including activity
>   occurring on Confluence
>
> - Accumulo has transitioned from Jira to GitHub issues. The remaining Jira
>   activity reflects closing obsolete issues.
>
> ## Links
> [1] https://github.com/apache/accumulo/projects/30
> [2] https://github.com/apache/accumulo/projects/27
> [3] https://github.com/orgs/apache/projects/164/views/1
>
> From:

Re: Accumulo Board Report - due by Oct 11th

[Christopher]

I wouldn't describe the ongoing activity as "moderate". It seems
pretty busy, at least as busy as ever, anyway. Maybe that's what you
meant, but it feels like the word "moderate" carries the connotation
of "mediocre" to me. I think we've been pretty active addressing the
2.1 issues. Not everything being investigated results in a commit,
though, and you've explained that already when you talk about a
decline in GitHub activity... although I don't think that decline is
really that significant. You also went on to describe work planned
towards a final 1.10 release, work on multiple 2.1 releases, a 3.0
release, work on 3.1, and we also have work on the elasticity branch.
This is all happening concurrently, so I don't think "moderate" is a
good descriptor.

"metatdata" is misspelled. Should be metadata.

While we haven't formally voted or anything, it seems likely that the
elasticity work will be a 4.0 release, and that seems like the current
plan. Saying we haven't decided yet makes it seem like it could still
be a 3.x release, and while that's technically true in that no version
number is final until we vote on it, I don't think any of us believe
that it will be a 3.x release. I would either omit this entirely, or
just mention that it's likely to be a 4.0.

You mention the committer and PMC ratio is roughly 1:1. I think it
would be good to explain that the discrepancy is due to PMC members
voluntarily electing to go emeritus. You could say something like "It
is our practice to invite committers to be PMC members at the same
time, but some PMC members have subsequently elected to go emeritus".
(Even better if you can say that more succinctly than I did.)

You say we're working on "two significant development efforts". I
would say "*at least* two significant development efforts", as some of
us are also working on things that are outside of that (like the
no-chop merge feature for 3.1, and some other things like that, which
are not dependent on elasticity). Maybe those other things aren't as
"significant", but that's subjective, so I think adding "at least"
makes it more accurate.

On Wed, Sep 27, 2023 at 12:24 PM dev1  wrote:
>
> Thanks – fixed in tool.
>
> FYI: The reason for the caution is that formatting / wrapping / whitespace 
> with text pasted into the email may differ than what the tool will submit.
>
> Ed Coleman
>
> From: Daniel Roberts 
> Date: Wednesday, September 27, 2023 at 10:53 AM
> To: dev@accumulo.apache.org 
> Subject: Re: Accumulo Board Report - due by Oct 11th
> I know you mentioned that this draft may not be the submitted version,
> but "current project status" is duplicated in the same line.
>

Re: accumulo upgrade from 2.0.1 to 2.1.1

[Christopher]

I'm not sure about the monitor behavior. I've never had a reason to
run more than one, and I don't think we have any well-defined behavior
for trying to run more than one (I could see an argument for both). It
would be weird if one incorrectly reported "Master[now Manager] is
down" because another monitor was running, though. I would expect the
2.1 behavior you described over that 2.0 behavior.

On Mon, Sep 25, 2023 at 11:59 AM Vincent Russell
 wrote:
>
> Thank you Christopher,
>
> I did neglect to update the log4j2 files.
>
> One thing that is weird is that the monitors appear to work differently
> with high availability.
>
> With 2.0.1 the accumulo monitors both work and you can hit them both (one
> just says 'Master is down'; however, with 2.1.1, it appears that only one
> works.Is this expected?
>
> Thank you,
>
> On Thu, Sep 14, 2023 at 4:28 PM Christopher  wrote:
>
> > I do not know about the error message you saw. StatusConsoleListener
> > is not an Accumulo class, but it looks like it's a log4j one. My best
> > guess is that during your upgrade, you did not migrate your log4j
> > config files over to be based on the log4j2 ones we have as an example
> > in the 2.1 tarball. It's possible that there's some log4j
> > configuration issue that's preventing you from seeing the reason why
> > the Monitor failed to start.
> >
> > To troubleshoot, I would compare your log4j config with what we ship
> > in the 2.1 tarball and also check to see if you've done any log4j
> > config overrides in the system properties or environment variables
> > that control log4j.
> >
> > On Tue, Sep 12, 2023 at 8:10 PM Vincent Russell
> >  wrote:
> > >
> > > Thank you Christopher,
> > >
> > > Don't worry.  I definitely planned on testing an upgrade on a test
> > > cluster.   :)
> > >
> > > I just upgraded a test cluster and everything appeared to go smoothly
> > > except for one thing.
> > >
> > > I am able to login to the accumulo shell and I can see the table that I
> > > created before the upgrade exists and I can scan that table.
> > >
> > > Before the upgrade the monitor was running on port 9995, but now nothing
> > > appears to be running on that port.Nothing in the monitor log
> > exception:
> > >
> > > ERROR StatusConsoleListener Unable to send HTTP in appender [MonitorLog]
> > > IllegalARgumentException: invalid URI schema <>
> > >
> > >
> > > This seems not great, but I am not sure if it's related.
> > >
> > > It doesn't look like the monitor is running on another port.   Any
> > > suggestions for debugging this?
> > >
> > > Thanks,
> > > Vincent
> > >
> > >
> > >
> > > On Wed, Aug 30, 2023 at 7:09 PM Christopher  wrote:
> > >
> > > > My understanding is that the upgrade of ZK is pretty easy... but I
> > > > would consult the ZooKeeper community for advice on that, since they
> > > > are the experts. For Accumulo's part, I believe 2.0 worked fine with
> > > > newer versions of ZK (3.5+), so you should be able to update ZK first
> > > > if you didn't want to do them at the same time. There may be some
> > > > things you might need to do to ensure your classpath is set up
> > > > correctly for Accumulo if using it with 2.0, since 2.0 might assume ZK
> > > > 3.4 jar locations. I don't recall the specifics, but I remember it
> > > > wasn't that bad. fluo-uno had used newer ZK versions with 2.0 for a
> > > > while. The necessary config changes to support that might even still
> > > > be scripted in its repo.
> > > >
> > > > I'm really not familiar with Hadoop upgrades, but as far as Accumulo
> > > > is concerned, it would probably treat both 3.3.1 and 3.3.5 as
> > > > essentially equivalent. I don't think anything substantially changed
> > > > that would cause Accumulo to even notice a difference. Seems like it
> > > > would just be a quick shutdown, update the classpath, restart, for
> > > > Accumulo. For Hadoop, you may have some upgrade tasks... I'd check
> > > > with the Hadoop community first. You could probably upgrade Hadoop
> > > > before or after you upgrade Accumulo for this one. I don't think it's
> > > > going to matter much.
> > > >
> > > > If you're concerned about problems you might encounter, I would run
> > > > through the upgrades on a small test instance first, just to pract

Re: accumulo upgrade from 2.0.1 to 2.1.1

[Christopher]

I do not know about the error message you saw. StatusConsoleListener
is not an Accumulo class, but it looks like it's a log4j one. My best
guess is that during your upgrade, you did not migrate your log4j
config files over to be based on the log4j2 ones we have as an example
in the 2.1 tarball. It's possible that there's some log4j
configuration issue that's preventing you from seeing the reason why
the Monitor failed to start.

To troubleshoot, I would compare your log4j config with what we ship
in the 2.1 tarball and also check to see if you've done any log4j
config overrides in the system properties or environment variables
that control log4j.

On Tue, Sep 12, 2023 at 8:10 PM Vincent Russell
 wrote:
>
> Thank you Christopher,
>
> Don't worry.  I definitely planned on testing an upgrade on a test
> cluster.   :)
>
> I just upgraded a test cluster and everything appeared to go smoothly
> except for one thing.
>
> I am able to login to the accumulo shell and I can see the table that I
> created before the upgrade exists and I can scan that table.
>
> Before the upgrade the monitor was running on port 9995, but now nothing
> appears to be running on that port.Nothing in the monitor log exception:
>
> ERROR StatusConsoleListener Unable to send HTTP in appender [MonitorLog]
> IllegalARgumentException: invalid URI schema <>
>
>
> This seems not great, but I am not sure if it's related.
>
> It doesn't look like the monitor is running on another port.   Any
> suggestions for debugging this?
>
> Thanks,
> Vincent
>
>
>
> On Wed, Aug 30, 2023 at 7:09 PM Christopher  wrote:
>
> > My understanding is that the upgrade of ZK is pretty easy... but I
> > would consult the ZooKeeper community for advice on that, since they
> > are the experts. For Accumulo's part, I believe 2.0 worked fine with
> > newer versions of ZK (3.5+), so you should be able to update ZK first
> > if you didn't want to do them at the same time. There may be some
> > things you might need to do to ensure your classpath is set up
> > correctly for Accumulo if using it with 2.0, since 2.0 might assume ZK
> > 3.4 jar locations. I don't recall the specifics, but I remember it
> > wasn't that bad. fluo-uno had used newer ZK versions with 2.0 for a
> > while. The necessary config changes to support that might even still
> > be scripted in its repo.
> >
> > I'm really not familiar with Hadoop upgrades, but as far as Accumulo
> > is concerned, it would probably treat both 3.3.1 and 3.3.5 as
> > essentially equivalent. I don't think anything substantially changed
> > that would cause Accumulo to even notice a difference. Seems like it
> > would just be a quick shutdown, update the classpath, restart, for
> > Accumulo. For Hadoop, you may have some upgrade tasks... I'd check
> > with the Hadoop community first. You could probably upgrade Hadoop
> > before or after you upgrade Accumulo for this one. I don't think it's
> > going to matter much.
> >
> > If you're concerned about problems you might encounter, I would run
> > through the upgrades on a small test instance first, just to practice.
> > If you run into a specific problem doing that, we could probably offer
> > more specific insight, having probably seen it before.
> >
> >
> > On Wed, Aug 30, 2023 at 4:50 PM Vincent Russell
> >  wrote:
> > >
> > > Thank you Christopher.
> > >
> > > Does there exist some documentation for upgrading zookeeper from 3.4.14
> > to
> > > 3.8.1?   Is there a preferred upgrade path?
> > >
> > > Also...Is there any documentation on how this affects hadoop when using
> > > high availability?   We are using hadoop 3.3.1.  I want to upgrade to
> > > hadoop 3.3.5, but I didn't know if that should be done as part of
> > upgrading
> > > accumulo or later.
> > >
> > > Any experience folks have would be greatly appreciated.
> > >
> > > Thank you,
> > > Vincent
> > >
> > > On Thu, Aug 24, 2023 at 12:58 PM Christopher 
> > wrote:
> > >
> > > > The correct link seems to be
> > > >
> > > >
> > https://accumulo.apache.org/docs/2.x/troubleshooting/zookeeper#zookeeper-acls
> > > >
> > > > It looks like both `bin/accumulo dump-zoo` and `bin/accumulo-util
> > > > dump-zoo` will do the same thing. It was originally a disconnected
> > > > utility that existed for convenience, but was incorporated into our
> > > > regular tooling recently as part of an effort to make all these
> > > > utilities more easily discoverabl

Re: New Accumulo git repository

[Christopher]

I'm not 100% certain about the name, but a new repo is a really low risk
thing. I say go for it.

On Thu, Sep 7, 2023, 08:54 Marc P.  wrote:

> Out of curiosity, what is the benefit of having a new repo over a release
> target of accumulo-visibility ?
>
> I've used VisibilityEvaluator on non Accumulo projects, so I can see some
> perceived benefit, but in those projects I wanted to support a visibility
> expression or ColumnVisibility "as Accumulo does".
>
> Marc
>
> On Thu, Sep 7, 2023 at 8:33 AM Dave Marion  wrote:
>
> > I don't think the risk of not creating a release from the new repo
> exists.
> > I believe we have to use non-snapshot dependencies when creating an
> > Accumulo release. Right? I have no issue with creating the repo now and
> no
> > issue with the name, since we can rename it.
> >
> > On Wed, Sep 6, 2023 at 3:18 PM Keith Turner  wrote:
> >
> > > I would like to create a new git repository named accumulo-access in
> the
> > > ASF and want to know if anyone has thoughts about creating this repo.
> > This
> > > new repo would be a home for the Accumulo access module being created
> in
> > > 3715[1].
> > >
> > > Once this repository is created, then the following could happen.
> > >
> > >  1. Finish creating the stand alone library that offers Accumulo's
> > current
> > > visibility functionality.
> > >  2. Release the new library.
> > >  3. Adapt Accumulo 3.1 or later to use this new library for its
> > > implementation of ColumnVisibility, adding it as a new dependency to
> > > Accumulo.
> > >
> > > One risk with creating this repository is that a release never happens
> > from
> > > it and we are left with an unused git repo hanging around.  Another
> risk
> > is
> > > that the name could change before release, it seems this can be handled
> > > with a Jira issue to INFRA to rename the git repo.  Are there any other
> > > risks?
> > >
> > > I looked into creating a new git repo and ASF offers self service tools
> > > that make this easy. Renaming is not self service as far as I can tell,
> > but
> > > I did find Jira issues where other projects requested a rename w/o
> > problem.
> > >
> > > [1]: https://github.com/apache/accumulo/pull/3715
> > >
> >
>

Re: accumulo upgrade from 2.0.1 to 2.1.1

[Christopher]

My understanding is that the upgrade of ZK is pretty easy... but I
would consult the ZooKeeper community for advice on that, since they
are the experts. For Accumulo's part, I believe 2.0 worked fine with
newer versions of ZK (3.5+), so you should be able to update ZK first
if you didn't want to do them at the same time. There may be some
things you might need to do to ensure your classpath is set up
correctly for Accumulo if using it with 2.0, since 2.0 might assume ZK
3.4 jar locations. I don't recall the specifics, but I remember it
wasn't that bad. fluo-uno had used newer ZK versions with 2.0 for a
while. The necessary config changes to support that might even still
be scripted in its repo.

I'm really not familiar with Hadoop upgrades, but as far as Accumulo
is concerned, it would probably treat both 3.3.1 and 3.3.5 as
essentially equivalent. I don't think anything substantially changed
that would cause Accumulo to even notice a difference. Seems like it
would just be a quick shutdown, update the classpath, restart, for
Accumulo. For Hadoop, you may have some upgrade tasks... I'd check
with the Hadoop community first. You could probably upgrade Hadoop
before or after you upgrade Accumulo for this one. I don't think it's
going to matter much.

If you're concerned about problems you might encounter, I would run
through the upgrades on a small test instance first, just to practice.
If you run into a specific problem doing that, we could probably offer
more specific insight, having probably seen it before.


On Wed, Aug 30, 2023 at 4:50 PM Vincent Russell
 wrote:
>
> Thank you Christopher.
>
> Does there exist some documentation for upgrading zookeeper from 3.4.14 to
> 3.8.1?   Is there a preferred upgrade path?
>
> Also...Is there any documentation on how this affects hadoop when using
> high availability?   We are using hadoop 3.3.1.  I want to upgrade to
> hadoop 3.3.5, but I didn't know if that should be done as part of upgrading
> accumulo or later.
>
> Any experience folks have would be greatly appreciated.
>
> Thank you,
> Vincent
>
> On Thu, Aug 24, 2023 at 12:58 PM Christopher  wrote:
>
> > The correct link seems to be
> >
> > https://accumulo.apache.org/docs/2.x/troubleshooting/zookeeper#zookeeper-acls
> >
> > It looks like both `bin/accumulo dump-zoo` and `bin/accumulo-util
> > dump-zoo` will do the same thing. It was originally a disconnected
> > utility that existed for convenience, but was incorporated into our
> > regular tooling recently as part of an effort to make all these
> > utilities more easily discoverable and executable. I don't think we
> > realized that it already had a convenient and documented entry point.
> > We were just looking for utilities with a "main" method. Either should
> > work fine. They call the same code.
> >
> > On Thu, Aug 24, 2023 at 11:04 AM Vincent Russell
> >  wrote:
> > >
> > > Also the link to:
> > >
> > > https://accumulo.apache.org/docs/2.x/troubleshooting/ZooKeeper#ACLs
> > >
> > > is not resolving.
> > >
> > > What needs to be done at this step?
> > >
> > >
> > > Thanks,
> > > Vincent
> > >
> > >
> > > On Thu, Aug 24, 2023 at 10:36 AM Vincent Russell <
> > vincent.russ...@gmail.com>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > I'm practicing going to the upgrade instructions from 2.0.1 to 2.1.1
> > and I
> > > > wanted to confirm that the zoo-dump command is run via the
> > accumulo-util
> > > > command and not via accumulo.
> > > >
> > > > The instructions say:
> > > >
> > > > $ACCUMULO_HOME/bin/accumulo dump-zoo --xml --root /accumulo | tee
> > > > PATH_TO_SNAPSHOT
> > > >
> > > > Thank you,
> > > > Vincent
> > > >
> >

Re: accumulo upgrade from 2.0.1 to 2.1.1

[Christopher]

The correct link seems to be
https://accumulo.apache.org/docs/2.x/troubleshooting/zookeeper#zookeeper-acls

It looks like both `bin/accumulo dump-zoo` and `bin/accumulo-util
dump-zoo` will do the same thing. It was originally a disconnected
utility that existed for convenience, but was incorporated into our
regular tooling recently as part of an effort to make all these
utilities more easily discoverable and executable. I don't think we
realized that it already had a convenient and documented entry point.
We were just looking for utilities with a "main" method. Either should
work fine. They call the same code.

On Thu, Aug 24, 2023 at 11:04 AM Vincent Russell
 wrote:
>
> Also the link to:
>
> https://accumulo.apache.org/docs/2.x/troubleshooting/ZooKeeper#ACLs
>
> is not resolving.
>
> What needs to be done at this step?
>
>
> Thanks,
> Vincent
>
>
> On Thu, Aug 24, 2023 at 10:36 AM Vincent Russell 
> wrote:
>
> > Hello,
> >
> > I'm practicing going to the upgrade instructions from 2.0.1 to 2.1.1 and I
> > wanted to confirm that the zoo-dump command is run via the accumulo-util
> > command and not via accumulo.
> >
> > The instructions say:
> >
> > $ACCUMULO_HOME/bin/accumulo dump-zoo --xml --root /accumulo | tee
> > PATH_TO_SNAPSHOT
> >
> > Thank you,
> > Vincent
> >

[DRAFT][ANNOUNCE] Apache Accumulo 2.1.2 and 3.0.0

[Christopher]

See below for the draft consolidated release announcement for 2.1.2
and 3.0.0. I intend to send this out on Tuesday evening to the apache
announce list and our own user list, but am presenting it here for
review while I polish up the release notes.
***

The Apache Accumulo project is pleased to announce the
concurrent release of versions 2.1.2 and 3.0.0.

Apache Accumulo 2.1.2 is a bug fix release of the 2.1 LTM
release line. This release includes several critical and
minor bug fixes and performance improvements. See the
release notes linked below for details.

Apache Accumulo 3.0.0 is a new major release, based on the
earlier 2.1 code base, and containing all patches of 2.1
through 2.1.2. It is primarily a "clean up" release,
removing deprecated APIs and features. It additionally
contains some minor improvements and features. It is a
non-LTM release, so it is not expected to see regular patch
releases. Instead, patches to 3.0.0 will be rolled into the
next release.

Users of 2.1.1 and earlier are encouraged to upgrade to one
of these releases to take advantage of the included bugfixes
and improvements. Please note that version 3.0.0 only
supports upgrading from a 2.1 version, but 2.1.2 supports
upgrading from 1.10 or a previous 2.1 release. Users wishing
to stay on the LTM release to continue to receive subsequent
patches on a stable release line should upgrade to 2.1.2.

Reminder: 1.10 will be end-of-life in November 2023, and we
encourage all users to migrate to 2.1 (or later) by then.

***

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.1.1/
https://accumulo.apache.org/release/accumulo-3.0.0/

[RESULT][VOTE] Apache Accumulo 2.1.2-rc1

[Christopher]

This vote passes with 6 +1s and no other votes.
The post-vote release tasks are tracked at
https://github.com/apache/accumulo/issues/3713

On Mon, Aug 21, 2023 at 4:53 PM Christopher  wrote:
>
> +1
>
> I checked:
>
> * signatures, hashes
> * full ITs
> * bin tarball's lib directory matches what's in the Maven repo
> * src tarball matches git commit
>
> Will close the vote momentarily.
>
> On Tue, Aug 15, 2023 at 1:50 PM Dominic Garguilo  
> wrote:
> >
> > +1
> >
> > I have:
> >
> > * verified hashes
> > * verified psunny passes successfully
> >
> > On Mon, Aug 14, 2023 at 4:08 AM Christopher  wrote:
> >
> > > Accumulo Developers,
> > >
> > > Please consider the following candidate for Apache Accumulo 2.1.2.
> > >
> > > Git Commit:
> > > ee7ae63a823477b557aa9415a92653e95aa64cb1
> > > Branch:
> > > 2.1.2-rc1
> > >
> > > If this vote passes, a gpg-signed tag will be created using:
> > > git tag -f -s -m 'Apache Accumulo 2.1.2' rel/2.1.2 \
> > > ee7ae63a823477b557aa9415a92653e95aa64cb1
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/orgapacheaccumulo-1105
> > > Source (official release artifact):
> > >
> > > https://repository.apache.org/content/repositories/orgapacheaccumulo-1105/org/apache/accumulo/accumulo/2.1.2/accumulo-2.1.2-src.tar.gz
> > > Binary:
> > > https://repository.apache.org/content/repositories/orgapacheaccumulo-1105/org/apache/accumulo/accumulo/2.1.2/accumulo-2.1.2-bin.tar.gz
> > >
> > > Append ".asc" to download the cryptographic signature for a given 
> > > artifact.
> > > (You can also append ".sha1" or ".md5" instead in order to verify the
> > > checksums
> > > generated by Maven to verify the integrity of the Nexus repository
> > > staging area.)
> > >
> > > Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> > > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> > >
> > > In addition to the tarballs and their signatures, the following checksum
> > > files will be added to the dist/release SVN area after release:
> > > accumulo-2.1.2-src.tar.gz.sha512 will contain:
> > > SHA512 (accumulo-2.1.2-src.tar.gz) =
> > >
> > > ce27a7bc1892c93300a687ac335a5db5968d1718298acb38dccfb5eb53d2d9f5d912d70c0aa981351afdf7b3e5c5bc7f8bf80ecf0af1ab70634561b86be9f2ca
> > > accumulo-2.1.2-bin.tar.gz.sha512 will contain:
> > > SHA512 (accumulo-2.1.2-bin.tar.gz) =
> > >
> > > 27778c1c3f1d88ab128649fd0671d3be97ba052216ab43f1169395960e8c7d16375a51f940c2262437b836ea31f83f73f08f7a3d8cadda443e5e8bb31d9b23c5
> > >
> > > Release notes (in progress) can be found at:
> > > https://accumulo.apache.org/release/accumulo-2.1.2
> > >
> > > Release testing instructions:
> > > https://accumulo.apache.org/contributor/verifying-release
> > >
> > > 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 2.1.2 release of Apache Accumulo.
> > >
> > > This vote will remain open until at least Thu Aug 17 08:30:00 AM UTC 2023.
> > > (Thu Aug 17 04:30:00 AM EDT 2023 / Thu Aug 17 01:30:00 AM PDT 2023)
> > > Voting can continue after this deadline until the release manager
> > > sends an email ending 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-1105/
> > > # note the trailing slash is needed
> > >

[RESULT][VOTE] Apache Accumulo 3.0.0-rc1

[Christopher]

This vote passes with 6 +1s and no other votes.
The post-vote release tasks are tracked at
https://github.com/apache/accumulo/issues/3714

On Mon, Aug 21, 2023 at 4:54 PM Christopher  wrote:
>
> +1
>
> I checked:
>
> * signatures, hashes
> * full ITs
> * bin tarball's lib directory matches what's in the Maven repo
> * src tarball matches git commit
>
> Will close the vote momentarily.
>
> On Fri, Aug 18, 2023 at 10:41 AM Dominic Garguilo
>  wrote:
> >
> > +1
> >
> > * verified hashes
> > * built from tar with no errors
> > * ran all tests and ITs (only failure was the known
> > flaky MemoryStarvedScanIT)
> >
> > On Mon, Aug 14, 2023 at 4:18 AM Christopher  wrote:
> >
> > > Accumulo Developers,
> > >
> > > Please consider the following candidate for Apache Accumulo 3.0.0.
> > >
> > > Git Commit:
> > > fcf3192f27935ee3c66426fb89799ee0850944f2
> > > Branch:
> > > 3.0.0-rc1
> > >
> > > If this vote passes, a gpg-signed tag will be created using:
> > > git tag -f -s -m 'Apache Accumulo 3.0.0' rel/3.0.0 \
> > > fcf3192f27935ee3c66426fb89799ee0850944f2
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/orgapacheaccumulo-1106
> > > Source (official release artifact):
> > >
> > > https://repository.apache.org/content/repositories/orgapacheaccumulo-1106/org/apache/accumulo/accumulo/3.0.0/accumulo-3.0.0-src.tar.gz
> > > Binary:
> > > https://repository.apache.org/content/repositories/orgapacheaccumulo-1106/org/apache/accumulo/accumulo/3.0.0/accumulo-3.0.0-bin.tar.gz
> > >
> > > Append ".asc" to download the cryptographic signature for a given 
> > > artifact.
> > > (You can also append ".sha1" or ".md5" instead in order to verify the
> > > checksums
> > > generated by Maven to verify the integrity of the Nexus repository
> > > staging area.)
> > >
> > > Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> > > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> > >
> > > In addition to the tarballs and their signatures, the following checksum
> > > files will be added to the dist/release SVN area after release:
> > > accumulo-3.0.0-src.tar.gz.sha512 will contain:
> > > SHA512 (accumulo-3.0.0-src.tar.gz) =
> > >
> > > 02df744722e65ea65d86a8c89615b9a08435f32a66750e302b392ba9050708dc0fd246a240450f3226cbb64934fa490775264fc748bf941254ddd47c4b484a31
> > > accumulo-3.0.0-bin.tar.gz.sha512 will contain:
> > > SHA512 (accumulo-3.0.0-bin.tar.gz) =
> > >
> > > c992e7ce8073862057173bd1005af2c6b617e6ba2a1fb7f7f3e3aed0876dca6c87794257fe511863ffb9b7a641597bedad730673d4c504abc0ee88c78ecfed01
> > >
> > > Release notes (in progress) can be found at:
> > > https://accumulo.apache.org/release/accumulo-3.0.0
> > >
> > > Release testing instructions:
> > > https://accumulo.apache.org/contributor/verifying-release
> > >
> > > 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 3.0.0 release of Apache Accumulo.
> > >
> > > This vote will remain open until at least Thu Aug 17 08:30:00 AM UTC 2023.
> > > (Thu Aug 17 04:30:00 AM EDT 2023 / Thu Aug 17 01:30:00 AM PDT 2023)
> > > Voting can continue after this deadline until the release manager
> > > sends an email ending 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-1106/
> > > # note the trailing slash is needed
> > >

Re: [VOTE] Apache Accumulo 3.0.0-rc1

[Christopher]

+1

I checked:

* signatures, hashes
* full ITs
* bin tarball's lib directory matches what's in the Maven repo
* src tarball matches git commit

Will close the vote momentarily.

On Fri, Aug 18, 2023 at 10:41 AM Dominic Garguilo
 wrote:
>
> +1
>
> * verified hashes
> * built from tar with no errors
> * ran all tests and ITs (only failure was the known
> flaky MemoryStarvedScanIT)
>
> On Mon, Aug 14, 2023 at 4:18 AM Christopher  wrote:
>
> > Accumulo Developers,
> >
> > Please consider the following candidate for Apache Accumulo 3.0.0.
> >
> > Git Commit:
> > fcf3192f27935ee3c66426fb89799ee0850944f2
> > Branch:
> > 3.0.0-rc1
> >
> > If this vote passes, a gpg-signed tag will be created using:
> > git tag -f -s -m 'Apache Accumulo 3.0.0' rel/3.0.0 \
> > fcf3192f27935ee3c66426fb89799ee0850944f2
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapacheaccumulo-1106
> > Source (official release artifact):
> >
> > https://repository.apache.org/content/repositories/orgapacheaccumulo-1106/org/apache/accumulo/accumulo/3.0.0/accumulo-3.0.0-src.tar.gz
> > Binary:
> > https://repository.apache.org/content/repositories/orgapacheaccumulo-1106/org/apache/accumulo/accumulo/3.0.0/accumulo-3.0.0-bin.tar.gz
> >
> > Append ".asc" to download the cryptographic signature for a given artifact.
> > (You can also append ".sha1" or ".md5" instead in order to verify the
> > checksums
> > generated by Maven to verify the integrity of the Nexus repository
> > staging area.)
> >
> > Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> >
> > In addition to the tarballs and their signatures, the following checksum
> > files will be added to the dist/release SVN area after release:
> > accumulo-3.0.0-src.tar.gz.sha512 will contain:
> > SHA512 (accumulo-3.0.0-src.tar.gz) =
> >
> > 02df744722e65ea65d86a8c89615b9a08435f32a66750e302b392ba9050708dc0fd246a240450f3226cbb64934fa490775264fc748bf941254ddd47c4b484a31
> > accumulo-3.0.0-bin.tar.gz.sha512 will contain:
> > SHA512 (accumulo-3.0.0-bin.tar.gz) =
> >
> > c992e7ce8073862057173bd1005af2c6b617e6ba2a1fb7f7f3e3aed0876dca6c87794257fe511863ffb9b7a641597bedad730673d4c504abc0ee88c78ecfed01
> >
> > Release notes (in progress) can be found at:
> > https://accumulo.apache.org/release/accumulo-3.0.0
> >
> > Release testing instructions:
> > https://accumulo.apache.org/contributor/verifying-release
> >
> > 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 3.0.0 release of Apache Accumulo.
> >
> > This vote will remain open until at least Thu Aug 17 08:30:00 AM UTC 2023.
> > (Thu Aug 17 04:30:00 AM EDT 2023 / Thu Aug 17 01:30:00 AM PDT 2023)
> > Voting can continue after this deadline until the release manager
> > sends an email ending 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-1106/
> > # note the trailing slash is needed
> >

Re: [VOTE] Apache Accumulo 2.1.2-rc1

[Christopher]

+1

I checked:

* signatures, hashes
* full ITs
* bin tarball's lib directory matches what's in the Maven repo
* src tarball matches git commit

Will close the vote momentarily.

On Tue, Aug 15, 2023 at 1:50 PM Dominic Garguilo  wrote:
>
> +1
>
> I have:
>
> * verified hashes
> * verified psunny passes successfully
>
> On Mon, Aug 14, 2023 at 4:08 AM Christopher  wrote:
>
> > Accumulo Developers,
> >
> > Please consider the following candidate for Apache Accumulo 2.1.2.
> >
> > Git Commit:
> > ee7ae63a823477b557aa9415a92653e95aa64cb1
> > Branch:
> > 2.1.2-rc1
> >
> > If this vote passes, a gpg-signed tag will be created using:
> > git tag -f -s -m 'Apache Accumulo 2.1.2' rel/2.1.2 \
> > ee7ae63a823477b557aa9415a92653e95aa64cb1
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapacheaccumulo-1105
> > Source (official release artifact):
> >
> > https://repository.apache.org/content/repositories/orgapacheaccumulo-1105/org/apache/accumulo/accumulo/2.1.2/accumulo-2.1.2-src.tar.gz
> > Binary:
> > https://repository.apache.org/content/repositories/orgapacheaccumulo-1105/org/apache/accumulo/accumulo/2.1.2/accumulo-2.1.2-bin.tar.gz
> >
> > Append ".asc" to download the cryptographic signature for a given artifact.
> > (You can also append ".sha1" or ".md5" instead in order to verify the
> > checksums
> > generated by Maven to verify the integrity of the Nexus repository
> > staging area.)
> >
> > Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> >
> > In addition to the tarballs and their signatures, the following checksum
> > files will be added to the dist/release SVN area after release:
> > accumulo-2.1.2-src.tar.gz.sha512 will contain:
> > SHA512 (accumulo-2.1.2-src.tar.gz) =
> >
> > ce27a7bc1892c93300a687ac335a5db5968d1718298acb38dccfb5eb53d2d9f5d912d70c0aa981351afdf7b3e5c5bc7f8bf80ecf0af1ab70634561b86be9f2ca
> > accumulo-2.1.2-bin.tar.gz.sha512 will contain:
> > SHA512 (accumulo-2.1.2-bin.tar.gz) =
> >
> > 27778c1c3f1d88ab128649fd0671d3be97ba052216ab43f1169395960e8c7d16375a51f940c2262437b836ea31f83f73f08f7a3d8cadda443e5e8bb31d9b23c5
> >
> > Release notes (in progress) can be found at:
> > https://accumulo.apache.org/release/accumulo-2.1.2
> >
> > Release testing instructions:
> > https://accumulo.apache.org/contributor/verifying-release
> >
> > 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 2.1.2 release of Apache Accumulo.
> >
> > This vote will remain open until at least Thu Aug 17 08:30:00 AM UTC 2023.
> > (Thu Aug 17 04:30:00 AM EDT 2023 / Thu Aug 17 01:30:00 AM PDT 2023)
> > Voting can continue after this deadline until the release manager
> > sends an email ending 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-1105/
> > # note the trailing slash is needed
> >

Re: [VOTE] Apache Accumulo 3.0.0-rc1

[Christopher Shannon]

+1 (binding)

Some of the things I did for verification/testing locally:

* Validated signatures and checksums
* Verified license and notice files in archives
* Verified source license headers with 'mvn apache-rat:check'
* Built and ran all the sunny integration tests
* Started up using Uno to make sure everything started correctly

On Tue, Aug 15, 2023 at 3:27 PM Dave Marion  wrote:

> +1
>
> * verified signatures and hashes
> * built from source tarball with no issues
> * Sunny day tests passed
> * Started instance locally. Ran ci until the disk was almost full. Ran
> scan, walk, batchwalk with no issues.
> * Looked at diff between 3.0 and 2.1 to look for changes that were not in
> the release notes
>
> On Mon, Aug 14, 2023 at 7:38 PM dev1  wrote:
>
> > +1
> >
> >
> >   *   Verified signatures
> >   *   Built from tar with no errors (including errorprone)
> >   *   Sunny tests passed
> >   *   Started an uno instances and did some spot checks
> >  *   Verified no unexpected exception in the log files
> >
> > Ed Coleman
> >
> > From: Christopher 
> > Date: Monday, August 14, 2023 at 4:26 AM
> > To: accumulo-dev 
> > Subject: [VOTE] Apache Accumulo 3.0.0-rc1
> > Accumulo Developers,
> >
> > Please consider the following candidate for Apache Accumulo 3.0.0.
> >
> > Git Commit:
> > fcf3192f27935ee3c66426fb89799ee0850944f2
> > Branch:
> > 3.0.0-rc1
> >
> > If this vote passes, a gpg-signed tag will be created using:
> > git tag -f -s -m 'Apache Accumulo 3.0.0' rel/3.0.0 \
> > fcf3192f27935ee3c66426fb89799ee0850944f2
> >
> > Staging repo:
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1106
> > Source (official release artifact):
> >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1106/org/apache/accumulo/accumulo/3.0.0/accumulo-3.0.0-src.tar.gz
> > Binary:
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1106/org/apache/accumulo/accumulo/3.0.0/accumulo-3.0.0-bin.tar.gz
> >
> > Append ".asc" to download the cryptographic signature for a given
> artifact.
> > (You can also append ".sha1" or ".md5" instead in order to verify the
> > checksums
> > generated by Maven to verify the integrity of the Nexus repository
> > staging area.)
> >
> > Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> >
> > In addition to the tarballs and their signatures, the following checksum
> > files will be added to the dist/release SVN area after release:
> > accumulo-3.0.0-src.tar.gz.sha512 will contain:
> > SHA512 (accumulo-3.0.0-src.tar.gz) =
> >
> >
> 02df744722e65ea65d86a8c89615b9a08435f32a66750e302b392ba9050708dc0fd246a240450f3226cbb64934fa490775264fc748bf941254ddd47c4b484a31
> > accumulo-3.0.0-bin.tar.gz.sha512 will contain:
> > SHA512 (accumulo-3.0.0-bin.tar.gz) =
> >
> >
> c992e7ce8073862057173bd1005af2c6b617e6ba2a1fb7f7f3e3aed0876dca6c87794257fe511863ffb9b7a641597bedad730673d4c504abc0ee88c78ecfed01
> >
> > Release notes (in progress) can be found at:
> > https://accumulo.apache.org/release/accumulo-3.0.0
> >
> > Release testing instructions:
> > https://accumulo.apache.org/contributor/verifying-release
> >
> > 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 3.0.0 release of Apache Accumulo.
> >
> > This vote will remain open until at least Thu Aug 17 08:30:00 AM UTC
> 2023.
> > (Thu Aug 17 04:30:00 AM EDT 2023 / Thu Aug 17 01:30:00 AM PDT 2023)
> > Voting can continue after this deadline until the release manager
> > sends an email ending 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-1106/
> > # note the trailing slash is needed
> >
>

Re: [VOTE] Apache Accumulo 2.1.2-rc1

[Christopher Shannon]

+1 (binding)

Some of the things I did for verification/testing locally:

* Validated signatures and checksums
* Verified license and notice files in archives
* Verified source license headers with 'mvn apache-rat:check'
* Built and ran all the sunny integration tests
* Started up using Uno to make sure everything started correctly

On Mon, Aug 14, 2023 at 6:23 PM dev1  wrote:

> +1
>
> Verified signatures and successfully ran sunny tests.  Errorprone does
> fail with a minor error with assert usages that is fixed in PR 3691.
>
> Ed Coleman
>
> From: Christopher 
> Date: Monday, August 14, 2023 at 4:16 AM
> To: accumulo-dev 
> Subject: [VOTE] Apache Accumulo 2.1.2-rc1
> Accumulo Developers,
>
> Please consider the following candidate for Apache Accumulo 2.1.2.
>
> Git Commit:
> ee7ae63a823477b557aa9415a92653e95aa64cb1
> Branch:
> 2.1.2-rc1
>
> If this vote passes, a gpg-signed tag will be created using:
> git tag -f -s -m 'Apache Accumulo 2.1.2' rel/2.1.2 \
> ee7ae63a823477b557aa9415a92653e95aa64cb1
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1105
> Source (official release artifact):
>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1105/org/apache/accumulo/accumulo/2.1.2/accumulo-2.1.2-src.tar.gz
> Binary:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1105/org/apache/accumulo/accumulo/2.1.2/accumulo-2.1.2-bin.tar.gz
>
> Append ".asc" to download the cryptographic signature for a given artifact.
> (You can also append ".sha1" or ".md5" instead in order to verify the
> checksums
> generated by Maven to verify the integrity of the Nexus repository
> staging area.)
>
> Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
>
> In addition to the tarballs and their signatures, the following checksum
> files will be added to the dist/release SVN area after release:
> accumulo-2.1.2-src.tar.gz.sha512 will contain:
> SHA512 (accumulo-2.1.2-src.tar.gz) =
>
> ce27a7bc1892c93300a687ac335a5db5968d1718298acb38dccfb5eb53d2d9f5d912d70c0aa981351afdf7b3e5c5bc7f8bf80ecf0af1ab70634561b86be9f2ca
> accumulo-2.1.2-bin.tar.gz.sha512 will contain:
> SHA512 (accumulo-2.1.2-bin.tar.gz) =
>
> 27778c1c3f1d88ab128649fd0671d3be97ba052216ab43f1169395960e8c7d16375a51f940c2262437b836ea31f83f73f08f7a3d8cadda443e5e8bb31d9b23c5
>
> Release notes (in progress) can be found at:
> https://accumulo.apache.org/release/accumulo-2.1.2
>
> Release testing instructions:
> https://accumulo.apache.org/contributor/verifying-release
>
> 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 2.1.2 release of Apache Accumulo.
>
> This vote will remain open until at least Thu Aug 17 08:30:00 AM UTC 2023.
> (Thu Aug 17 04:30:00 AM EDT 2023 / Thu Aug 17 01:30:00 AM PDT 2023)
> Voting can continue after this deadline until the release manager
> sends an email ending 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-1105/
> # note the trailing slash is needed
>

[VOTE] Apache Accumulo 3.0.0-rc1

[Christopher]

Accumulo Developers,

Please consider the following candidate for Apache Accumulo 3.0.0.

Git Commit:
fcf3192f27935ee3c66426fb89799ee0850944f2
Branch:
3.0.0-rc1

If this vote passes, a gpg-signed tag will be created using:
git tag -f -s -m 'Apache Accumulo 3.0.0' rel/3.0.0 \
fcf3192f27935ee3c66426fb89799ee0850944f2

Staging repo: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1106
Source (official release artifact):
https://repository.apache.org/content/repositories/orgapacheaccumulo-1106/org/apache/accumulo/accumulo/3.0.0/accumulo-3.0.0-src.tar.gz
Binary: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1106/org/apache/accumulo/accumulo/3.0.0/accumulo-3.0.0-bin.tar.gz

Append ".asc" to download the cryptographic signature for a given artifact.
(You can also append ".sha1" or ".md5" instead in order to verify the checksums
generated by Maven to verify the integrity of the Nexus repository
staging area.)

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

In addition to the tarballs and their signatures, the following checksum
files will be added to the dist/release SVN area after release:
accumulo-3.0.0-src.tar.gz.sha512 will contain:
SHA512 (accumulo-3.0.0-src.tar.gz) =
02df744722e65ea65d86a8c89615b9a08435f32a66750e302b392ba9050708dc0fd246a240450f3226cbb64934fa490775264fc748bf941254ddd47c4b484a31
accumulo-3.0.0-bin.tar.gz.sha512 will contain:
SHA512 (accumulo-3.0.0-bin.tar.gz) =
c992e7ce8073862057173bd1005af2c6b617e6ba2a1fb7f7f3e3aed0876dca6c87794257fe511863ffb9b7a641597bedad730673d4c504abc0ee88c78ecfed01

Release notes (in progress) can be found at:
https://accumulo.apache.org/release/accumulo-3.0.0

Release testing instructions:
https://accumulo.apache.org/contributor/verifying-release

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 3.0.0 release of Apache Accumulo.

This vote will remain open until at least Thu Aug 17 08:30:00 AM UTC 2023.
(Thu Aug 17 04:30:00 AM EDT 2023 / Thu Aug 17 01:30:00 AM PDT 2023)
Voting can continue after this deadline until the release manager
sends an email ending 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-1106/
# note the trailing slash is needed

[VOTE] Apache Accumulo 2.1.2-rc1

[Christopher]

Accumulo Developers,

Please consider the following candidate for Apache Accumulo 2.1.2.

Git Commit:
ee7ae63a823477b557aa9415a92653e95aa64cb1
Branch:
2.1.2-rc1

If this vote passes, a gpg-signed tag will be created using:
git tag -f -s -m 'Apache Accumulo 2.1.2' rel/2.1.2 \
ee7ae63a823477b557aa9415a92653e95aa64cb1

Staging repo: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1105
Source (official release artifact):
https://repository.apache.org/content/repositories/orgapacheaccumulo-1105/org/apache/accumulo/accumulo/2.1.2/accumulo-2.1.2-src.tar.gz
Binary: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1105/org/apache/accumulo/accumulo/2.1.2/accumulo-2.1.2-bin.tar.gz

Append ".asc" to download the cryptographic signature for a given artifact.
(You can also append ".sha1" or ".md5" instead in order to verify the checksums
generated by Maven to verify the integrity of the Nexus repository
staging area.)

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

In addition to the tarballs and their signatures, the following checksum
files will be added to the dist/release SVN area after release:
accumulo-2.1.2-src.tar.gz.sha512 will contain:
SHA512 (accumulo-2.1.2-src.tar.gz) =
ce27a7bc1892c93300a687ac335a5db5968d1718298acb38dccfb5eb53d2d9f5d912d70c0aa981351afdf7b3e5c5bc7f8bf80ecf0af1ab70634561b86be9f2ca
accumulo-2.1.2-bin.tar.gz.sha512 will contain:
SHA512 (accumulo-2.1.2-bin.tar.gz) =
27778c1c3f1d88ab128649fd0671d3be97ba052216ab43f1169395960e8c7d16375a51f940c2262437b836ea31f83f73f08f7a3d8cadda443e5e8bb31d9b23c5

Release notes (in progress) can be found at:
https://accumulo.apache.org/release/accumulo-2.1.2

Release testing instructions:
https://accumulo.apache.org/contributor/verifying-release

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 2.1.2 release of Apache Accumulo.

This vote will remain open until at least Thu Aug 17 08:30:00 AM UTC 2023.
(Thu Aug 17 04:30:00 AM EDT 2023 / Thu Aug 17 01:30:00 AM PDT 2023)
Voting can continue after this deadline until the release manager
sends an email ending 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-1105/
# note the trailing slash is needed

Re: New committer - Dan Roberts

[Christopher Shannon]

Congrats Dan!

On Thu, Aug 10, 2023 at 12:08 AM Christopher  wrote:

> Welcome Dan, and congrats
>
> On Wed, Aug 9, 2023, 18:27 dev1  wrote:
>
> > The Project Management Committee (PMC) for Apache Accumulo has invited
> Dan
> > Roberts to become a committer / PMC member and we are pleased to announce
> > that they have accepted.
> >
> > 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.
> >
> > Ed Coleman
> > Accumulo PMC chair
> >
> >
> >
> >
> >
>

Re: New committer - Dan Roberts

[Christopher]

Welcome Dan, and congrats

On Wed, Aug 9, 2023, 18:27 dev1  wrote:

> The Project Management Committee (PMC) for Apache Accumulo has invited Dan
> Roberts to become a committer / PMC member and we are pleased to announce
> that they have accepted.
>
> 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.
>
> Ed Coleman
> Accumulo PMC chair
>
>
>
>
>

[TEST][VOTE] Apache Accumulo 3.0.0-rc0

[Christopher]

Accumulo Developers,

***
NOTE: This is just a TEST release candidate to verify the release
process, and to establish a milestone as a baseline for testing. There
is no need to actually vote, because this is not a real vote.
***

Please consider the following candidate for Apache Accumulo 3.0.0.

Git Commit:
733ea1a5391f86894743347ba50866f7153b0c88
Branch:
3.0.0-rc0

If this vote passes, a gpg-signed tag will be created using:
git tag -f -s -m 'Apache Accumulo 3.0.0' rel/3.0.0 \
733ea1a5391f86894743347ba50866f7153b0c88

Staging repo: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1104
Source (official release artifact):
https://repository.apache.org/content/repositories/orgapacheaccumulo-1104/org/apache/accumulo/accumulo/3.0.0/accumulo-3.0.0-src.tar.gz
Binary: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1104/org/apache/accumulo/accumulo/3.0.0/accumulo-3.0.0-bin.tar.gz

Append ".asc" to download the cryptographic signature for a given artifact.
(You can also append ".sha1" or ".md5" instead in order to verify the checksums
generated by Maven to verify the integrity of the Nexus repository
staging area.)

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

In addition to the tarballs and their signatures, the following checksum
files will be added to the dist/release SVN area after release:
accumulo-3.0.0-src.tar.gz.sha512 will contain:
SHA512 (accumulo-3.0.0-src.tar.gz) =
8f19726ee2b4942f96e5538874a27fe767d40f5d13f8fc97763f721714d91a6e733b41c82e0f040880c19eabbab6330256360c3fd0744bc07b351b759ea86d01
accumulo-3.0.0-bin.tar.gz.sha512 will contain:
SHA512 (accumulo-3.0.0-bin.tar.gz) =
17211146839c593dabdaa3bdecd85899878011df65315c8cee3a2582cba15b426ac06917416e86b0cdd21821b8201be043c464fe7cdb0fac248d0cff43582fc2

Release notes (in progress) can be found at:
https://accumulo.apache.org/release/accumulo-3.0.0

Release testing instructions:
https://accumulo.apache.org/contributor/verifying-release

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 3.0.0 release of Apache Accumulo.

This vote will remain open until at least Mon Jul  3 10:30:00 PM UTC 2023.
(Mon Jul  3 06:30:00 PM EDT 2023 / Mon Jul  3 03:30:00 PM PDT 2023)
Voting can continue after this deadline until the release manager
sends an email ending 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-1104/
# note the trailing slash is needed

[RESULTS][VOTE] Apache Accumulo 2.1.1-rc2

[Christopher]

Thanks all.

This vote passes with 8 "+1" and no other votes.

I will work on the post-vote tasks, which I'm tracking at
https://github.com/apache/accumulo/issues/3507

On Mon, Jun 19, 2023, 10:43 Christopher  wrote:

> +1
>
> Verified:
> * Hashes/sigs
> * Full ITs (some typical flakes)
> * Ran instance in fluo-uno
> * Jars in lib dir in binary match staged in Maven repo
> * Jars have sources/javadocs
> * Source artifact matches git commit
>
> On Sat, Jun 17, 2023, 12:20 Mark Owens  wrote:
>
>> +1
>>
>> * Verified hashes
>> * Ran unit tests
>> * Ran Sunny ITs
>> * Opened shell and tested basic functionality
>> * Went through the JShell tour successfully
>> * Ran several random examples from the Accumulo-Examples repo successfully
>>
>>
>> On Sat, Jun 17, 2023 at 10:23 AM Jeffrey Manno 
>> wrote:
>>
>> > +1
>> >
>> > Verified checksums. Initiated ingest testing with fluo-uno and
>> > accumulo-testing.
>> > Ran ITs.
>> >
>> > On Fri, Jun 16, 2023 at 7:04 PM Keith Turner  wrote:
>> >
>> > > +1
>> > >
>> > > Ran CI test w/ agitation on a 10 node cluster for a few hours.
>> Ingested
>> > > and verified ~8B entries.   Used the default accumuo-testing agitation
>> > > settings.
>> > > Ran 10x random walkers running the bulk test on a 10 node cluster
>> using a
>> > > modification[1] to the test graph. Ran this for a few hours.  Saw 149
>> > > successful completions of the test across the 10 walkers.
>> > >
>> > > [1]:
>> > >
>> https://github.com/apache/accumulo/issues/2667#issuecomment-1269905344
>> > >
>> > > On Wed, Jun 14, 2023 at 1:49 AM Christopher 
>> wrote:
>> > >
>> > > > Accumulo Developers,
>> > > >
>> > > > Please consider the following candidate for Apache Accumulo 2.1.1.
>> > > >
>> > > > Stuff that's changed since RC1:
>> > > > * Fix flaky gc tests: https://github.com/apache/accumulo/pull/3490
>> > > > * Fix hung compactions:
>> https://github.com/apache/accumulo/pull/3492
>> > > > * Show lowercase table names better in monitor:
>> > > > https://github.com/apache/accumulo/pull/3493
>> > > >
>> > > > Git Commit:
>> > > > 9edc2b7cd764c190172076244689ae7c1129db70
>> > > > Branch:
>> > > > 2.1.1-rc2
>> > > >
>> > > > If this vote passes, a gpg-signed tag will be created using:
>> > > > git tag -f -s -m 'Apache Accumulo 2.1.1' rel/2.1.1 \
>> > > > 9edc2b7cd764c190172076244689ae7c1129db70
>> > > >
>> > > > Staging repo:
>> > > >
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapacheaccumulo-1102
>> > > > Source (official release artifact):
>> > > >
>> > > >
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapacheaccumulo-1102/org/apache/accumulo/accumulo/2.1.1/accumulo-2.1.1-src.tar.gz
>> > > > Binary:
>> > > >
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapacheaccumulo-1102/org/apache/accumulo/accumulo/2.1.1/accumulo-2.1.1-bin.tar.gz
>> > > >
>> > > > Append ".asc" to download the cryptographic signature for a given
>> > > artifact.
>> > > > (You can also append ".sha1" or ".md5" instead in order to verify
>> the
>> > > > checksums
>> > > > generated by Maven to verify the integrity of the Nexus repository
>> > > > staging area.)
>> > > >
>> > > > Signing keys are available at
>> > https://www.apache.org/dist/accumulo/KEYS
>> > > > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
>> > > >
>> > > > In addition to the tarballs and their signatures, the following
>> > checksum
>> > > > files will be added to the dist/release SVN area after release:
>> > > > accumulo-2.1.1-src.tar.gz.sha512 will contain:
>> > > > SHA512 (accumulo-2.1.1-src.tar.gz) =
>> > > >
>> > > >
>> > >
>> >
>> 62634f8c36f28aa13bfc3f76a44bad67cf664594a716da5c0a0bb7948d4825c4bb8c296c9cb50a838722e2c74244debe2a88374bfaaf174b89bc41a761f07065
>> > > > a

Re: [VOTE] Apache Accumulo 2.1.1-rc2

[Christopher]

+1

Verified:
* Hashes/sigs
* Full ITs (some typical flakes)
* Ran instance in fluo-uno
* Jars in lib dir in binary match staged in Maven repo
* Jars have sources/javadocs
* Source artifact matches git commit

On Sat, Jun 17, 2023, 12:20 Mark Owens  wrote:

> +1
>
> * Verified hashes
> * Ran unit tests
> * Ran Sunny ITs
> * Opened shell and tested basic functionality
> * Went through the JShell tour successfully
> * Ran several random examples from the Accumulo-Examples repo successfully
>
>
> On Sat, Jun 17, 2023 at 10:23 AM Jeffrey Manno 
> wrote:
>
> > +1
> >
> > Verified checksums. Initiated ingest testing with fluo-uno and
> > accumulo-testing.
> > Ran ITs.
> >
> > On Fri, Jun 16, 2023 at 7:04 PM Keith Turner  wrote:
> >
> > > +1
> > >
> > > Ran CI test w/ agitation on a 10 node cluster for a few hours.
> Ingested
> > > and verified ~8B entries.   Used the default accumuo-testing agitation
> > > settings.
> > > Ran 10x random walkers running the bulk test on a 10 node cluster
> using a
> > > modification[1] to the test graph. Ran this for a few hours.  Saw 149
> > > successful completions of the test across the 10 walkers.
> > >
> > > [1]:
> > > https://github.com/apache/accumulo/issues/2667#issuecomment-1269905344
> > >
> > > On Wed, Jun 14, 2023 at 1:49 AM Christopher 
> wrote:
> > >
> > > > Accumulo Developers,
> > > >
> > > > Please consider the following candidate for Apache Accumulo 2.1.1.
> > > >
> > > > Stuff that's changed since RC1:
> > > > * Fix flaky gc tests: https://github.com/apache/accumulo/pull/3490
> > > > * Fix hung compactions: https://github.com/apache/accumulo/pull/3492
> > > > * Show lowercase table names better in monitor:
> > > > https://github.com/apache/accumulo/pull/3493
> > > >
> > > > Git Commit:
> > > > 9edc2b7cd764c190172076244689ae7c1129db70
> > > > Branch:
> > > > 2.1.1-rc2
> > > >
> > > > If this vote passes, a gpg-signed tag will be created using:
> > > > git tag -f -s -m 'Apache Accumulo 2.1.1' rel/2.1.1 \
> > > > 9edc2b7cd764c190172076244689ae7c1129db70
> > > >
> > > > Staging repo:
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1102
> > > > Source (official release artifact):
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1102/org/apache/accumulo/accumulo/2.1.1/accumulo-2.1.1-src.tar.gz
> > > > Binary:
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1102/org/apache/accumulo/accumulo/2.1.1/accumulo-2.1.1-bin.tar.gz
> > > >
> > > > Append ".asc" to download the cryptographic signature for a given
> > > artifact.
> > > > (You can also append ".sha1" or ".md5" instead in order to verify the
> > > > checksums
> > > > generated by Maven to verify the integrity of the Nexus repository
> > > > staging area.)
> > > >
> > > > Signing keys are available at
> > https://www.apache.org/dist/accumulo/KEYS
> > > > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> > > >
> > > > In addition to the tarballs and their signatures, the following
> > checksum
> > > > files will be added to the dist/release SVN area after release:
> > > > accumulo-2.1.1-src.tar.gz.sha512 will contain:
> > > > SHA512 (accumulo-2.1.1-src.tar.gz) =
> > > >
> > > >
> > >
> >
> 62634f8c36f28aa13bfc3f76a44bad67cf664594a716da5c0a0bb7948d4825c4bb8c296c9cb50a838722e2c74244debe2a88374bfaaf174b89bc41a761f07065
> > > > accumulo-2.1.1-bin.tar.gz.sha512 will contain:
> > > > SHA512 (accumulo-2.1.1-bin.tar.gz) =
> > > >
> > > >
> > >
> >
> adb23e56362c2e3e813d07791389b8ca2d5976df8b00a29b607e6ae05ea465eff80ada6d1ec9a9c596df8b4066c51078cd5a4006dc78568ac38f638a1d3895be
> > > >
> > > > Release notes (in progress) can be found at:
> > > > https://accumulo.apache.org/release/accumulo-2.1.1
> > > >
> > > > Release testing instructions:
> > > > https://accumulo.apache.org/contributor/verifying-release
> > > >
> > > > 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 2.1.1 release of Apache Accumulo.
> > > >
> > > > This vote will remain open until at least Sat Jun 17 06:00:00 AM UTC
> > > 2023.
> > > > (Sat Jun 17 02:00:00 AM EDT 2023 / Fri Jun 16 11:00:00 PM PDT 2023)
> > > > Voting can continue after this deadline until the release manager
> > > > sends an email ending 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-1102/
> > > > # note the trailing slash is needed
> > > >
> > >
> >
>

Re: [VOTE] Apache Accumulo 2.1.1-rc2

[Christopher Shannon]

+1 (binding)

* Validated signatures and checksums
* Verified license and notice files in archives
* Verified source license headers with 'mvn apache-rat:check'
* Built and ran all the sunny integration tests
* Ran a few tests using Uno

On Fri, Jun 16, 2023 at 7:59 AM Dave Marion  wrote:

> +1
>
> Verified signatures (asc, md5, sha1 and sha512) match expected
> Ran SunnyDay ITs
> Ran CI for 6+ hours with no issues on a 10-node cluster
>
>
> On Thu, Jun 15, 2023 at 2:15 PM dev1  wrote:
>
> > +1
> >
> > Verified signatures (asc, md5, sha1 and sha512) match expected
> > Sunny tests passed with no failures.
> >
> > Ed Coleman
> >
> > From: Christopher 
> > Date: Wednesday, June 14, 2023 at 1:49 AM
> > To: accumulo-dev 
> > Subject: [VOTE] Apache Accumulo 2.1.1-rc2
> > Accumulo Developers,
> >
> > Please consider the following candidate for Apache Accumulo 2.1.1.
> >
> > Stuff that's changed since RC1:
> > * Fix flaky gc tests: https://github.com/apache/accumulo/pull/3490
> > * Fix hung compactions: https://github.com/apache/accumulo/pull/3492
> > * Show lowercase table names better in monitor:
> > https://github.com/apache/accumulo/pull/3493
> >
> > Git Commit:
> > 9edc2b7cd764c190172076244689ae7c1129db70
> > Branch:
> > 2.1.1-rc2
> >
> > If this vote passes, a gpg-signed tag will be created using:
> > git tag -f -s -m 'Apache Accumulo 2.1.1' rel/2.1.1 \
> > 9edc2b7cd764c190172076244689ae7c1129db70
> >
> > Staging repo:
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1102
> > Source (official release artifact):
> >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1102/org/apache/accumulo/accumulo/2.1.1/accumulo-2.1.1-src.tar.gz
> > Binary:
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1102/org/apache/accumulo/accumulo/2.1.1/accumulo-2.1.1-bin.tar.gz
> >
> > Append ".asc" to download the cryptographic signature for a given
> artifact.
> > (You can also append ".sha1" or ".md5" instead in order to verify the
> > checksums
> > generated by Maven to verify the integrity of the Nexus repository
> > staging area.)
> >
> > Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> >
> > In addition to the tarballs and their signatures, the following checksum
> > files will be added to the dist/release SVN area after release:
> > accumulo-2.1.1-src.tar.gz.sha512 will contain:
> > SHA512 (accumulo-2.1.1-src.tar.gz) =
> >
> >
> 62634f8c36f28aa13bfc3f76a44bad67cf664594a716da5c0a0bb7948d4825c4bb8c296c9cb50a838722e2c74244debe2a88374bfaaf174b89bc41a761f07065
> > accumulo-2.1.1-bin.tar.gz.sha512 will contain:
> > SHA512 (accumulo-2.1.1-bin.tar.gz) =
> >
> >
> adb23e56362c2e3e813d07791389b8ca2d5976df8b00a29b607e6ae05ea465eff80ada6d1ec9a9c596df8b4066c51078cd5a4006dc78568ac38f638a1d3895be
> >
> > Release notes (in progress) can be found at:
> > https://accumulo.apache.org/release/accumulo-2.1.1
> >
> > Release testing instructions:
> > https://accumulo.apache.org/contributor/verifying-release
> >
> > 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 2.1.1 release of Apache Accumulo.
> >
> > This vote will remain open until at least Sat Jun 17 06:00:00 AM UTC
> 2023.
> > (Sat Jun 17 02:00:00 AM EDT 2023 / Fri Jun 16 11:00:00 PM PDT 2023)
> > Voting can continue after this deadline until the release manager
> > sends an email ending 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-1102/
> > # note the trailing slash is needed
> >
>

[VOTE] Apache Accumulo 2.1.1-rc2

[Christopher]

Accumulo Developers,

Please consider the following candidate for Apache Accumulo 2.1.1.

Stuff that's changed since RC1:
* Fix flaky gc tests: https://github.com/apache/accumulo/pull/3490
* Fix hung compactions: https://github.com/apache/accumulo/pull/3492
* Show lowercase table names better in monitor:
https://github.com/apache/accumulo/pull/3493

Git Commit:
9edc2b7cd764c190172076244689ae7c1129db70
Branch:
2.1.1-rc2

If this vote passes, a gpg-signed tag will be created using:
git tag -f -s -m 'Apache Accumulo 2.1.1' rel/2.1.1 \
9edc2b7cd764c190172076244689ae7c1129db70

Staging repo: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1102
Source (official release artifact):
https://repository.apache.org/content/repositories/orgapacheaccumulo-1102/org/apache/accumulo/accumulo/2.1.1/accumulo-2.1.1-src.tar.gz
Binary: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1102/org/apache/accumulo/accumulo/2.1.1/accumulo-2.1.1-bin.tar.gz

Append ".asc" to download the cryptographic signature for a given artifact.
(You can also append ".sha1" or ".md5" instead in order to verify the checksums
generated by Maven to verify the integrity of the Nexus repository
staging area.)

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

In addition to the tarballs and their signatures, the following checksum
files will be added to the dist/release SVN area after release:
accumulo-2.1.1-src.tar.gz.sha512 will contain:
SHA512 (accumulo-2.1.1-src.tar.gz) =
62634f8c36f28aa13bfc3f76a44bad67cf664594a716da5c0a0bb7948d4825c4bb8c296c9cb50a838722e2c74244debe2a88374bfaaf174b89bc41a761f07065
accumulo-2.1.1-bin.tar.gz.sha512 will contain:
SHA512 (accumulo-2.1.1-bin.tar.gz) =
adb23e56362c2e3e813d07791389b8ca2d5976df8b00a29b607e6ae05ea465eff80ada6d1ec9a9c596df8b4066c51078cd5a4006dc78568ac38f638a1d3895be

Release notes (in progress) can be found at:
https://accumulo.apache.org/release/accumulo-2.1.1

Release testing instructions:
https://accumulo.apache.org/contributor/verifying-release

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 2.1.1 release of Apache Accumulo.

This vote will remain open until at least Sat Jun 17 06:00:00 AM UTC 2023.
(Sat Jun 17 02:00:00 AM EDT 2023 / Fri Jun 16 11:00:00 PM PDT 2023)
Voting can continue after this deadline until the release manager
sends an email ending 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-1102/
# note the trailing slash is needed

Re: [VOTE] Apache Accumulo 2.1.1-rc1

[Christopher]

Given the building consensus around #3491, and the fact that a patch
is already merged in, I will withdraw this vote, and cut an RC2 soon
with the updates.

On Tue, Jun 13, 2023 at 7:33 PM Adam Lerman  wrote:
>
> -1 because of #3491
>
> On Mon, Jun 12, 2023 at 8:06 PM Christopher  wrote:
>
> > Accumulo Developers,
> >
> > Please consider the following candidate for Apache Accumulo 2.1.1.
> >
> > Git Commit:
> > 4937a2739f2a9f27e99bd6105cad644a9b868e8b
> > Branch:
> > 2.1.1-rc1
> >
> > If this vote passes, a gpg-signed tag will be created using:
> > git tag -f -s -m 'Apache Accumulo 2.1.1' rel/2.1.1 \
> > 4937a2739f2a9f27e99bd6105cad644a9b868e8b
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapacheaccumulo-1101
> > Source (official release artifact):
> >
> > https://repository.apache.org/content/repositories/orgapacheaccumulo-1101/org/apache/accumulo/accumulo/2.1.1/accumulo-2.1.1-src.tar.gz
> > Binary:
> > https://repository.apache.org/content/repositories/orgapacheaccumulo-1101/org/apache/accumulo/accumulo/2.1.1/accumulo-2.1.1-bin.tar.gz
> >
> > Append ".asc" to download the cryptographic signature for a given artifact.
> > (You can also append ".sha1" or ".md5" instead in order to verify the
> > checksums
> > generated by Maven to verify the integrity of the Nexus repository
> > staging area.)
> >
> > Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> >
> > In addition to the tarballs and their signatures, the following checksum
> > files will be added to the dist/release SVN area after release:
> > accumulo-2.1.1-src.tar.gz.sha512 will contain:
> > SHA512 (accumulo-2.1.1-src.tar.gz) =
> >
> > b17ebc3efbfe096dbcb43b4ce28bc498e3742190f8678cf19e5f305e21ce006f019e4e9e7c1a1b53c2ddac865eb784ca7e1f7bfb2494a34a109d8ac7392d1786
> > accumulo-2.1.1-bin.tar.gz.sha512 will contain:
> > SHA512 (accumulo-2.1.1-bin.tar.gz) =
> >
> > 2d81a8437c09236aa5c58483b84d4a0b31e83d48aefcabfd33545a64546234d0905a943302c6e175b5422589cbb5f1717c21eadec8c17116d419e9bb1a6c6580
> >
> > Release notes (in progress) can be found at:
> > https://accumulo.apache.org/release/accumulo-2.1.1
> >
> > Release testing instructions:
> > https://accumulo.apache.org/contributor/verifying-release
> >
> > 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 2.1.1 release of Apache Accumulo.
> >
> > This vote will remain open until at least Fri Jun 16 12:30:00 AM UTC 2023.
> > (Thu Jun 15 08:30:00 PM EDT 2023 / Thu Jun 15 05:30:00 PM PDT 2023)
> > Voting can continue after this deadline until the release manager
> > sends an email ending 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-1101/
> > # note the trailing slash is needed
> >

[VOTE] Apache Accumulo 2.1.1-rc1

[Christopher]

Accumulo Developers,

Please consider the following candidate for Apache Accumulo 2.1.1.

Git Commit:
4937a2739f2a9f27e99bd6105cad644a9b868e8b
Branch:
2.1.1-rc1

If this vote passes, a gpg-signed tag will be created using:
git tag -f -s -m 'Apache Accumulo 2.1.1' rel/2.1.1 \
4937a2739f2a9f27e99bd6105cad644a9b868e8b

Staging repo: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1101
Source (official release artifact):
https://repository.apache.org/content/repositories/orgapacheaccumulo-1101/org/apache/accumulo/accumulo/2.1.1/accumulo-2.1.1-src.tar.gz
Binary: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1101/org/apache/accumulo/accumulo/2.1.1/accumulo-2.1.1-bin.tar.gz

Append ".asc" to download the cryptographic signature for a given artifact.
(You can also append ".sha1" or ".md5" instead in order to verify the checksums
generated by Maven to verify the integrity of the Nexus repository
staging area.)

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

In addition to the tarballs and their signatures, the following checksum
files will be added to the dist/release SVN area after release:
accumulo-2.1.1-src.tar.gz.sha512 will contain:
SHA512 (accumulo-2.1.1-src.tar.gz) =
b17ebc3efbfe096dbcb43b4ce28bc498e3742190f8678cf19e5f305e21ce006f019e4e9e7c1a1b53c2ddac865eb784ca7e1f7bfb2494a34a109d8ac7392d1786
accumulo-2.1.1-bin.tar.gz.sha512 will contain:
SHA512 (accumulo-2.1.1-bin.tar.gz) =
2d81a8437c09236aa5c58483b84d4a0b31e83d48aefcabfd33545a64546234d0905a943302c6e175b5422589cbb5f1717c21eadec8c17116d419e9bb1a6c6580

Release notes (in progress) can be found at:
https://accumulo.apache.org/release/accumulo-2.1.1

Release testing instructions:
https://accumulo.apache.org/contributor/verifying-release

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 2.1.1 release of Apache Accumulo.

This vote will remain open until at least Fri Jun 16 12:30:00 AM UTC 2023.
(Thu Jun 15 08:30:00 PM EDT 2023 / Thu Jun 15 05:30:00 PM PDT 2023)
Voting can continue after this deadline until the release manager
sends an email ending 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-1101/
# note the trailing slash is needed

Re: [DRAFT][ANNOUNCE] Apache Accumulo 1.10.3

[Christopher]

Thanks, that's at least two more pairs of eyes. I'll go ahead and send
it out while it's still early in the day, so people have a chance to
see it before the weekend.

On Fri, Apr 28, 2023 at 8:33 AM Mark Owens  wrote:
>
> LGTM
>
> On Fri, Apr 28, 2023 at 6:49 AM Brian Loss  wrote:
>
> > LGTM. Thanks Christopher.
> >
> > > On Apr 28, 2023, at 2:18 AM, Christopher  wrote:
> > >
> > > Accumulo Devs,
> > >
> > > See the below draft release announcement that will be sent to the
> > > users list and the Apache announce list. I intend to submit this later
> > > today, and am requesting a second pair of eyes to check for typos,
> > > errors, omissions. Thanks!
> > >
> > > ***
> > > The Apache Accumulo project is pleased to announce the release
> > > of Apache Accumulo 1.10.3! Apache Accumulo 1.10.3 is a bug fix
> > > release of the 1.10 LTM release line. This release includes several
> > > minor bug fixes and performance improvements.
> > > See the release notes linked below for details.
> > >
> > > Users of 1.10.2 or earlier are encouraged to upgrade to take
> > > advantage of these included bug fixes and improvements prior to
> > > upgrading to the newer 2.1 LTM release series, to ensure the best
> > > upgrade experience.
> > >
> > > Please note that 1.10 will be end-of-life in November 2023, and we
> > > encourage all users to migrate to 2.1 (or later) by then.
> > >
> > > ***
> > >
> > > 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.3/
> >

Re: jdk 17 and accumulo testing

[Christopher]

There's a few outstanding issues. Notably, the issue mentioned on
https://github.com/apache/accumulo/issues/3346
There's also ensuring some stuff is marked as deprecated in 2.1.1 that
is mentioned in
https://github.com/apache/accumulo/pull/3265#discussion_r1177315428
(but that's really minor).

The project tracker is at
https://github.com/apache/accumulo/projects/25 and there's a few
things in flight.

I'm bad at estimating time (there was a time I thought we'd have 3.0
out in December 2022 and I thought we'd have 2.1.1 sometime around
February). Technically, we could put together a release candidate now,
but if it doesn't include some important things, we'll want to do
anther one right away, and that rapid churn is tiring for both devs
and users. I would watch #3346, as that seems to be the most critical
issue right now. Once that's figured out, releasing should be able to
follow shortly after.

I'm curious if the issue addressed in
https://github.com/apache/accumulo/pull/3134 actually fixes your
issue. Have you tried a recent snapshot version to see if the problem
is fixed for you? I looked for, but didn't see, any comment from you
about that.

On Fri, Apr 28, 2023 at 7:07 AM Vincent Russell
 wrote:
>
> Hello,
>
> Just checking in on if there is a timeframe for 2.1.1.
>
> This has been delaying our upgrade to jdk 17 for almost 5 month now.
>
>
> Thanks,
> Vincent
>
>
>
> On Fri, Dec 30, 2022, 12:57 PM Vincent Russell 
> wrote:
>
> > Ok.. Thank you for the update.
> >
> > On Fri, Dec 30, 2022 at 11:55 AM Christopher  wrote:
> >
> >> For reference, here's the PR working on the fix for 2.1.1:
> >> https://github.com/apache/accumulo/pull/3134
> >>
> >> On Fri, Dec 30, 2022 at 11:39 AM Christopher Shannon
> >>  wrote:
> >> >
> >> > Version 2.1.1 will be released with bug fixes and this fix (when
> >> finished
> >> > and merged) is planned to be included as part of that release. I don't
> >> know
> >> > the exact time frame yet though.
> >> >
> >> > On Fri, Dec 30, 2022 at 11:04 AM Vincent Russell <
> >> vincent.russ...@gmail.com>
> >> > wrote:
> >> >
> >> > > Hello,
> >> > >
> >> > > Are there any plans to release an accumulo 2.1 patch to fix this
> >> issue?
> >> > >
> >> > > Thanks,
> >> > >
> >> > > On Sat, Dec 17, 2022 at 7:36 PM Vincent Russell <
> >> vincent.russ...@gmail.com
> >> > > >
> >> > > wrote:
> >> > >
> >> > > > No worries.  I'm glad I was able to help in some small way.
> >> > > >
> >> > > > Thank you for fixing the issue.
> >> > > >
> >> > > > On Sat, Dec 17, 2022 at 11:49 AM Christopher Shannon <
> >> > > > christopher.l.shan...@gmail.com> wrote:
> >> > > >
> >> > > >> I created https://github.com/apache/accumulo/pull/3134 and that
> >> should
> >> > > >> fix
> >> > > >> this issue.
> >> > > >>
> >> > > >> Thanks Vincent for pointing out the issue in TServerUtils, your
> >> testing
> >> > > >> made this easy to track down and fix.
> >> > > >>
> >> > > >>
> >> > > >> On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
> >> > > >> christopher.l.shan...@gmail.com> wrote:
> >> > > >>
> >> > > >> > I was able to reproduce the issue by setting the value size for a
> >> > > >> mutation
> >> > > >> > to size 16384001 to make sure it's greater than the default
> >> value for
> >> > > >> > Thrift and it fails immediately. I will work on a fix now that
> >> we know
> >> > > >> how
> >> > > >> > to reproduce it.
> >> > > >> >
> >> > > >> > On Fri, Dec 16, 2022 at 2:31 PM Christopher  >> >
> >> > > >> wrote:
> >> > > >> >
> >> > > >> >> I don't think it's intentional. This might be the source of the
> >> > > >> problem.
> >> > > >> >>
> >> > > >> >> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
> >> > > >> >>  wrote:
> >> > > >> >> >
> >&

[DRAFT][ANNOUNCE] Apache Accumulo 1.10.3

[Christopher]

Accumulo Devs,

See the below draft release announcement that will be sent to the
users list and the Apache announce list. I intend to submit this later
today, and am requesting a second pair of eyes to check for typos,
errors, omissions. Thanks!

***
The Apache Accumulo project is pleased to announce the release
of Apache Accumulo 1.10.3! Apache Accumulo 1.10.3 is a bug fix
release of the 1.10 LTM release line. This release includes several
minor bug fixes and performance improvements.
See the release notes linked below for details.

Users of 1.10.2 or earlier are encouraged to upgrade to take
advantage of these included bug fixes and improvements prior to
upgrading to the newer 2.1 LTM release series, to ensure the best
upgrade experience.

Please note that 1.10 will be end-of-life in November 2023, and we
encourage all users to migrate to 2.1 (or later) by then.

***

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

Re: [DISCUSS] Should we have Jekyll build directly to asf-site branch?

[Christopher]

We're still polishing up the README and other changes in the latest
version of that PR, through some iterations of code review, but I
think we'll be ready to merge it soon. That will provide one more
option for people to do jekyll development locally for the website.

Dave also had some reservations about removing the staging site (his
last comment was a bit ambiguous "IIRC the local build is likely
sufficient"). Before I do anything to streamline website publication
by removing the mandatory staging site, I would like consensus from
everybody who had reservations. So, Dave, what do you think about
having the Docker build as an option for local staging? Would that be
enough for you to get on board with removing the mandatory staging
site step?

On Thu, Apr 20, 2023 at 12:01 AM Christopher  wrote:
>
> I reviewed your PR. It includes changes that are likely to break in my
> dev environment (the gem updates, due to errors building the native
> extensions for transitive dependencies in my environment) and make it
> harder for me to finish the 1.10.3 release changes, instead of make it
> easier... which is what my original goal was in streamlining this. I'm
> okay with having a Dockerfile... but the other changes are probably
> going to cause more problems for us in the short term than they solve.
>
> On Mon, Apr 17, 2023 at 6:11 PM Daniel Roberts  wrote:
> >
> > Christopher,
> >
> > I added a containerized dev environment in #384 which uses Jekyll's polling
> > option to dynamically pick up changes.
> >
> > Based on that change being included, I'm ok with removing the staging site
> > as PRs can be reviewed locally with minimal concern for dev environment
> > drift.
> >
> > Thanks,
> >
> > - Dan
> >
> > On Mon, Apr 17, 2023, 4:07 PM Christopher  wrote:
> >
> > > Keith - If we made the change, the README would still exist, but it
> > > would get a bit smaller, as there would be fewer mandatory things to
> > > do.
> > >
> > > Dan - Streamlining would just remove the staging site as a mandatory
> > > step. It will still remain an optional step, following steps similar
> > > to what you describe for feature branches. It's already available as
> > > an optional step today for feature branches, but we haven't had a need
> > > to use it that way. For a long time, staging sites weren't even an
> > > option, and we got along just fine without them. Like Keith, I can't
> > > think of a single time a staging site played any kind of influential
> > > role. But still, the feature would still be available after
> > > streamlining... just optional instead of mandatory.
> > >
> > > Regarding link validation, I agree that *might* be a useful QA build
> > > step (depending on how much effort it is, return on value it provides,
> > > how it's implemented, false positives due to network conditions and
> > > outages, etc.). But, I think that's a separate issue, and we can look
> > > into options to run some checks in the GitHub Actions, or as a
> > > periodic Jenkins job that crawls our website looking for broken links,
> > > independently from the streamlining proposal.
> > >
> > > On Mon, Apr 17, 2023 at 1:33 PM Daniel Roberts  wrote:
> > > >
> > > > Christopher,
> > > >
> > > > In your breakdown of my proposal, I think there's a miscommunication in
> > > > regard to the number of build steps and branches needed to maintain.
> > > >
> > > > Looking back I should have used descriptors like Branch C, Branch S,
> > > Branch
> > > > P vs main and staging due to the collision with the current branch names
> > > in
> > > > use.
> > > >
> > > > Feature branches would feed into staging and staging would be a direct
> > > > merge into the site branch for a total of three branches. One of those
> > > > branches is deleted after merge, resulting in two long-lived branches.
> > > One
> > > > for the staging site, and one for the production site.
> > > >
> > > > The number of build job runs should remain exactly the same as our
> > > current
> > > > implementation.
> > > > The only change would be an additional PR and the migration of the
> > > publish
> > > > operation from a  local action to a github deploy action.
> > > >
> > > > Unless link paths need to be regenerated for the new site location, 
> > > > there
> > > > shouldn't need to be an additional jekyll build run on the merge f

Re: [DISCUSS] Should we have Jekyll build directly to asf-site branch?

[Christopher]

I reviewed your PR. It includes changes that are likely to break in my
dev environment (the gem updates, due to errors building the native
extensions for transitive dependencies in my environment) and make it
harder for me to finish the 1.10.3 release changes, instead of make it
easier... which is what my original goal was in streamlining this. I'm
okay with having a Dockerfile... but the other changes are probably
going to cause more problems for us in the short term than they solve.

On Mon, Apr 17, 2023 at 6:11 PM Daniel Roberts  wrote:
>
> Christopher,
>
> I added a containerized dev environment in #384 which uses Jekyll's polling
> option to dynamically pick up changes.
>
> Based on that change being included, I'm ok with removing the staging site
> as PRs can be reviewed locally with minimal concern for dev environment
> drift.
>
> Thanks,
>
> - Dan
>
> On Mon, Apr 17, 2023, 4:07 PM Christopher  wrote:
>
> > Keith - If we made the change, the README would still exist, but it
> > would get a bit smaller, as there would be fewer mandatory things to
> > do.
> >
> > Dan - Streamlining would just remove the staging site as a mandatory
> > step. It will still remain an optional step, following steps similar
> > to what you describe for feature branches. It's already available as
> > an optional step today for feature branches, but we haven't had a need
> > to use it that way. For a long time, staging sites weren't even an
> > option, and we got along just fine without them. Like Keith, I can't
> > think of a single time a staging site played any kind of influential
> > role. But still, the feature would still be available after
> > streamlining... just optional instead of mandatory.
> >
> > Regarding link validation, I agree that *might* be a useful QA build
> > step (depending on how much effort it is, return on value it provides,
> > how it's implemented, false positives due to network conditions and
> > outages, etc.). But, I think that's a separate issue, and we can look
> > into options to run some checks in the GitHub Actions, or as a
> > periodic Jenkins job that crawls our website looking for broken links,
> > independently from the streamlining proposal.
> >
> > On Mon, Apr 17, 2023 at 1:33 PM Daniel Roberts  wrote:
> > >
> > > Christopher,
> > >
> > > In your breakdown of my proposal, I think there's a miscommunication in
> > > regard to the number of build steps and branches needed to maintain.
> > >
> > > Looking back I should have used descriptors like Branch C, Branch S,
> > Branch
> > > P vs main and staging due to the collision with the current branch names
> > in
> > > use.
> > >
> > > Feature branches would feed into staging and staging would be a direct
> > > merge into the site branch for a total of three branches. One of those
> > > branches is deleted after merge, resulting in two long-lived branches.
> > One
> > > for the staging site, and one for the production site.
> > >
> > > The number of build job runs should remain exactly the same as our
> > current
> > > implementation.
> > > The only change would be an additional PR and the migration of the
> > publish
> > > operation from a  local action to a github deploy action.
> > >
> > > Unless link paths need to be regenerated for the new site location, there
> > > shouldn't need to be an additional jekyll build run on the merge from the
> > > staging site to the production site branch.
> > >
> > > Since the additional PR is what would be used for formal review, the
> > amount
> > > of work generated for additional team members remains the same, with the
> > > benefit that changes are deployed directly to the production site once
> > the
> > > review is complete.
> > >
> > > I agree with the downside of merge commits in my proposal and
> > > that fast-forward merges are better in terms of git history management.
> > >
> > > While this could be solved with changing the merge strategy of the
> > > repository, I understand the desire to not involve the infra team.
> > >
> > > However, the majority of change tracking problems that come from extra
> > > merge commits being introduced don't exist in this scenario as multiple
> > > versions of the website aren't supported.
> > >
> > > My personal opinion is that fast-forward merges do not provide enough
> > > benefit in this scenario to outway a build pipeline that eliminates
> > >

Re: [DISCUSS] Should we have Jekyll build directly to asf-site branch?

[Christopher]

Keith - If we made the change, the README would still exist, but it
would get a bit smaller, as there would be fewer mandatory things to
do.

Dan - Streamlining would just remove the staging site as a mandatory
step. It will still remain an optional step, following steps similar
to what you describe for feature branches. It's already available as
an optional step today for feature branches, but we haven't had a need
to use it that way. For a long time, staging sites weren't even an
option, and we got along just fine without them. Like Keith, I can't
think of a single time a staging site played any kind of influential
role. But still, the feature would still be available after
streamlining... just optional instead of mandatory.

Regarding link validation, I agree that *might* be a useful QA build
step (depending on how much effort it is, return on value it provides,
how it's implemented, false positives due to network conditions and
outages, etc.). But, I think that's a separate issue, and we can look
into options to run some checks in the GitHub Actions, or as a
periodic Jenkins job that crawls our website looking for broken links,
independently from the streamlining proposal.

On Mon, Apr 17, 2023 at 1:33 PM Daniel Roberts  wrote:
>
> Christopher,
>
> In your breakdown of my proposal, I think there's a miscommunication in
> regard to the number of build steps and branches needed to maintain.
>
> Looking back I should have used descriptors like Branch C, Branch S, Branch
> P vs main and staging due to the collision with the current branch names in
> use.
>
> Feature branches would feed into staging and staging would be a direct
> merge into the site branch for a total of three branches. One of those
> branches is deleted after merge, resulting in two long-lived branches. One
> for the staging site, and one for the production site.
>
> The number of build job runs should remain exactly the same as our current
> implementation.
> The only change would be an additional PR and the migration of the publish
> operation from a  local action to a github deploy action.
>
> Unless link paths need to be regenerated for the new site location, there
> shouldn't need to be an additional jekyll build run on the merge from the
> staging site to the production site branch.
>
> Since the additional PR is what would be used for formal review, the amount
> of work generated for additional team members remains the same, with the
> benefit that changes are deployed directly to the production site once the
> review is complete.
>
> I agree with the downside of merge commits in my proposal and
> that fast-forward merges are better in terms of git history management.
>
> While this could be solved with changing the merge strategy of the
> repository, I understand the desire to not involve the infra team.
>
> However, the majority of change tracking problems that come from extra
> merge commits being introduced don't exist in this scenario as multiple
> versions of the website aren't supported.
>
> My personal opinion is that fast-forward merges do not provide enough
> benefit in this scenario to outway a build pipeline that eliminates
> maintaining a local development environment for site updates.
>
>
> *Current thoughts*
> I agree with the desire to streamline the build pipeline and move the
> production publish stage from a manual step to an automated build action.
>
> Having a staging area is useful in the event any large scale changes need
> to be made to the site like major rendering version updates. But I do agree
> that it provides little benefit when introducing minor changes outside of
> the possibility of discovering link/navigation issues.
>
> Regardless of what we do with the staging site, I don't think the answer is
> do nothing.
> I think one of the things we've identified in this discussion is the need
> for link validation to run in our QA build step.
>
> That seems to be the most common bug that makes it into the production site
> so identifying and eliminating those errors reduces the need for staging to
> exist.
>
> - Dan R.
>
> On Mon, Apr 17, 2023 at 11:22 AM Keith Turner  wrote:
>
> > On Wed, Apr 12, 2023 at 12:34 PM Christopher  wrote:
> > >
> > > I don't think Dan's suggested flow is much different than what we have
> > > now. In both cases, the steps are:
> > >
> > > 1. Initial PR to a branch (currently against main; Dan's approach
> > > would be against a separate main-like staging branch)
> > > 2. Auto build on PR merge (currently, that's main -> asf-staging;
> > > Dan's approach would build staging -> asf-staging)
> > > 3. View on staging site to evaluate for needed changes (auto-publish
> > > of asf-st

[RESULT][VOTE] Apache Accumulo 1.10.3-rc1

[Christopher]

This vote passes with:

5 +1s, and no other votes

I will track the release tasks on https://github.com/apache/accumulo/issues/3295


On Wed, Apr 12, 2023 at 1:44 PM Christopher  wrote:
>
> +1 to this release
>
> I checked:
>
> * Hashes/signatures
> * Source and javadoc jars exist for jars in staging repo
> * The jars in the binary tarball match the jars in the staging repo,
> and were built with the specified commit
> * The source tarball matches the contents of the git branch
> * Unit tests and ITs all pass
>
> I did notice that the source tarball includes the .gitignore files. I
> don't think that used to be the case. I had thought the source tarball
> was built without those files, but it seems not anymore. I don't think
> that's a problem, though... just unexpected to see .gitignore files
> outside the git tree. I wonder if this is a change in the
> apache-source-release-assembly-descriptor that is executed in the
> parent POM, or if it's a change in the default behavior of
> maven-assembly-plugin. I'm not sure.
>
> On Wed, Apr 12, 2023 at 12:58 PM Christopher  wrote:
> >
> > https://github.com/apache/accumulo/issues/3287 was identified as a
> > known issue in the documentation. This can be noted in the release
> > notes and fixed along with any 1.10.4 fixes. I'm wrapping up my own
> > testing, and will close the vote soon.
> >
> > On Wed, Apr 12, 2023 at 7:36 AM Dave Marion  wrote:
> > >
> > > Thanks Christopher for setting me straight. This information did enable 
> > > the
> > > build to move beyond the CredentialProviderFactoryShimTest. I'm unable to
> > > get past MiniAccumuloClusterTest though. Two tests timeout for me every
> > > time even when increasing the timeout factor (they both specify a timeout
> > > in the Test annotation). I was able to verify hashes and keys, but I'm
> > > going to refrain from voting as I was really unable to test anything
> > > because of my various issues. I think we should move forward though based
> > > on others' testing and votes.
> > >
> > > On Tue, Apr 11, 2023 at 7:01 PM Christopher  wrote:
> > >
> > > > I think a lot of you are getting bugs because you're trying to build
> > > > with both the "hadoop-default" / "hadoop2" and the "hadoop3" profile
> > > > active at the same time, and that's causing dependency resolution
> > > > issues because the classpath is polluted with a bunch of extra stuff
> > > > (which you can see by adding in a `dependency:tree` to the maven
> > > > command).
> > > >
> > > > If you're building using `-Phadoop3`, you should be aware that won't
> > > > de-activate the default profile, which is set up for Hadoop 2. The
> > > > correct way to build using the Hadoop 3 profile is with
> > > > `-Dhadoop.profile=3`, which activates the Hadoop 3 profile and
> > > > de-activates the default (Hadoop 2) profile at the same time:
> > > >
> > > > `mvn clean package -Dtest=CredentialProviderFactoryShimTest
> > > > -Dhadoop.profile=3`
> > > >
> > > > When built correctly, I cannot reproduce the errors seen, but I can
> > > > reproduce it when I use the incorrect command.
> > > >
> > > > Hadoop itself ships with commons-beanutils, and this credential
> > > > provider code is a Hadoop-specific feature. We don't have a dependency
> > > > on it for our code and don't ship beanutils in our tarball. This isn't
> > > > an issue in production, as long as you have your Hadoop libs on your
> > > > classpath correctly. The reason we use commons-configuration 1.6 is
> > > > because that converges with what Hadoop uses for [2.6.5,3.0). So, I
> > > > don't think we should change the version of that. We do ship it in our
> > > > tarball, because Hadoop 3.0.3 and later use commons-configuration2, so
> > > > commons-configuration needs to be on the classpath when using Hadoop
> > > > 3, but we don't want the version to conflict with what Hadoop 2 is
> > > > using, so we ship the same version. We can expect commons-beanutils to
> > > > be there, though, since Hadoop ships that in all its releases.
> > > >
> > > > We have enough votes that I could close the vote now, but I'll give it
> > > > another day for anybody who ran into issues to re-test with the
> > > > correct command, if they want, now that they have the updated
> > > > information.
> > > >
> > > > On T

Re: [VOTE] Apache Accumulo 1.10.3-rc1

[Christopher]

+1 to this release

I checked:

* Hashes/signatures
* Source and javadoc jars exist for jars in staging repo
* The jars in the binary tarball match the jars in the staging repo,
and were built with the specified commit
* The source tarball matches the contents of the git branch
* Unit tests and ITs all pass

I did notice that the source tarball includes the .gitignore files. I
don't think that used to be the case. I had thought the source tarball
was built without those files, but it seems not anymore. I don't think
that's a problem, though... just unexpected to see .gitignore files
outside the git tree. I wonder if this is a change in the
apache-source-release-assembly-descriptor that is executed in the
parent POM, or if it's a change in the default behavior of
maven-assembly-plugin. I'm not sure.

On Wed, Apr 12, 2023 at 12:58 PM Christopher  wrote:
>
> https://github.com/apache/accumulo/issues/3287 was identified as a
> known issue in the documentation. This can be noted in the release
> notes and fixed along with any 1.10.4 fixes. I'm wrapping up my own
> testing, and will close the vote soon.
>
> On Wed, Apr 12, 2023 at 7:36 AM Dave Marion  wrote:
> >
> > Thanks Christopher for setting me straight. This information did enable the
> > build to move beyond the CredentialProviderFactoryShimTest. I'm unable to
> > get past MiniAccumuloClusterTest though. Two tests timeout for me every
> > time even when increasing the timeout factor (they both specify a timeout
> > in the Test annotation). I was able to verify hashes and keys, but I'm
> > going to refrain from voting as I was really unable to test anything
> > because of my various issues. I think we should move forward though based
> > on others' testing and votes.
> >
> > On Tue, Apr 11, 2023 at 7:01 PM Christopher  wrote:
> >
> > > I think a lot of you are getting bugs because you're trying to build
> > > with both the "hadoop-default" / "hadoop2" and the "hadoop3" profile
> > > active at the same time, and that's causing dependency resolution
> > > issues because the classpath is polluted with a bunch of extra stuff
> > > (which you can see by adding in a `dependency:tree` to the maven
> > > command).
> > >
> > > If you're building using `-Phadoop3`, you should be aware that won't
> > > de-activate the default profile, which is set up for Hadoop 2. The
> > > correct way to build using the Hadoop 3 profile is with
> > > `-Dhadoop.profile=3`, which activates the Hadoop 3 profile and
> > > de-activates the default (Hadoop 2) profile at the same time:
> > >
> > > `mvn clean package -Dtest=CredentialProviderFactoryShimTest
> > > -Dhadoop.profile=3`
> > >
> > > When built correctly, I cannot reproduce the errors seen, but I can
> > > reproduce it when I use the incorrect command.
> > >
> > > Hadoop itself ships with commons-beanutils, and this credential
> > > provider code is a Hadoop-specific feature. We don't have a dependency
> > > on it for our code and don't ship beanutils in our tarball. This isn't
> > > an issue in production, as long as you have your Hadoop libs on your
> > > classpath correctly. The reason we use commons-configuration 1.6 is
> > > because that converges with what Hadoop uses for [2.6.5,3.0). So, I
> > > don't think we should change the version of that. We do ship it in our
> > > tarball, because Hadoop 3.0.3 and later use commons-configuration2, so
> > > commons-configuration needs to be on the classpath when using Hadoop
> > > 3, but we don't want the version to conflict with what Hadoop 2 is
> > > using, so we ship the same version. We can expect commons-beanutils to
> > > be there, though, since Hadoop ships that in all its releases.
> > >
> > > We have enough votes that I could close the vote now, but I'll give it
> > > another day for anybody who ran into issues to re-test with the
> > > correct command, if they want, now that they have the updated
> > > information.
> > >
> > > On Tue, Apr 11, 2023 at 3:21 PM Mark Owens  wrote:
> > > >
> > > > If I update the pom's with the commons-configuration changes suggested 
> > > > by
> > > > Dave in a previous post, I can successfully run the Sunny profile tests
> > > > with both Hadoop 2 and Hadoop 3.
> > > >
> > > > On Tue, Apr 11, 2023 at 1:16 PM Daniel Roberts 
> > > wrote:
> > > >
> > > > > Yes, I changed the memory settings last week and was able to pass the
> > > > > ExamplesIT.testScans

Re: [VOTE] Apache Accumulo 1.10.3-rc1

[Christopher]

https://github.com/apache/accumulo/issues/3287 was identified as a
known issue in the documentation. This can be noted in the release
notes and fixed along with any 1.10.4 fixes. I'm wrapping up my own
testing, and will close the vote soon.

On Wed, Apr 12, 2023 at 7:36 AM Dave Marion  wrote:
>
> Thanks Christopher for setting me straight. This information did enable the
> build to move beyond the CredentialProviderFactoryShimTest. I'm unable to
> get past MiniAccumuloClusterTest though. Two tests timeout for me every
> time even when increasing the timeout factor (they both specify a timeout
> in the Test annotation). I was able to verify hashes and keys, but I'm
> going to refrain from voting as I was really unable to test anything
> because of my various issues. I think we should move forward though based
> on others' testing and votes.
>
> On Tue, Apr 11, 2023 at 7:01 PM Christopher  wrote:
>
> > I think a lot of you are getting bugs because you're trying to build
> > with both the "hadoop-default" / "hadoop2" and the "hadoop3" profile
> > active at the same time, and that's causing dependency resolution
> > issues because the classpath is polluted with a bunch of extra stuff
> > (which you can see by adding in a `dependency:tree` to the maven
> > command).
> >
> > If you're building using `-Phadoop3`, you should be aware that won't
> > de-activate the default profile, which is set up for Hadoop 2. The
> > correct way to build using the Hadoop 3 profile is with
> > `-Dhadoop.profile=3`, which activates the Hadoop 3 profile and
> > de-activates the default (Hadoop 2) profile at the same time:
> >
> > `mvn clean package -Dtest=CredentialProviderFactoryShimTest
> > -Dhadoop.profile=3`
> >
> > When built correctly, I cannot reproduce the errors seen, but I can
> > reproduce it when I use the incorrect command.
> >
> > Hadoop itself ships with commons-beanutils, and this credential
> > provider code is a Hadoop-specific feature. We don't have a dependency
> > on it for our code and don't ship beanutils in our tarball. This isn't
> > an issue in production, as long as you have your Hadoop libs on your
> > classpath correctly. The reason we use commons-configuration 1.6 is
> > because that converges with what Hadoop uses for [2.6.5,3.0). So, I
> > don't think we should change the version of that. We do ship it in our
> > tarball, because Hadoop 3.0.3 and later use commons-configuration2, so
> > commons-configuration needs to be on the classpath when using Hadoop
> > 3, but we don't want the version to conflict with what Hadoop 2 is
> > using, so we ship the same version. We can expect commons-beanutils to
> > be there, though, since Hadoop ships that in all its releases.
> >
> > We have enough votes that I could close the vote now, but I'll give it
> > another day for anybody who ran into issues to re-test with the
> > correct command, if they want, now that they have the updated
> > information.
> >
> > On Tue, Apr 11, 2023 at 3:21 PM Mark Owens  wrote:
> > >
> > > If I update the pom's with the commons-configuration changes suggested by
> > > Dave in a previous post, I can successfully run the Sunny profile tests
> > > with both Hadoop 2 and Hadoop 3.
> > >
> > > On Tue, Apr 11, 2023 at 1:16 PM Daniel Roberts 
> > wrote:
> > >
> > > > Yes, I changed the memory settings last week and was able to pass the
> > > > ExamplesIT.testScansWithInterference and
> > > > ExamplesIT.testIsolatedScansWithInterference
> > > > without issue. Given these environmental tweaks, do we have a
> > documented
> > > > minimum machine spec that we expect the release tests to pass on?
> > > >
> > > > On Tue, Apr 11, 2023 at 1:00 PM Christopher Shannon <
> > > > christopher.l.shan...@gmail.com> wrote:
> > > >
> > > > > The test failure for ExamplesIT.testScansWithInterference is likely
> > from
> > > > > out of memory. See https://github.com/apache/accumulo/issues/3281
> > > > >
> > > > > On Tue, Apr 11, 2023 at 12:21 PM Dominic Garguilo <
> > > > > dominic.gargu...@gmail.com> wrote:
> > > > >
> > > > > > After running
> > > > > > mvn clean verify -Phadoop3,sunny
> > > > > > I am consistently seeing the following:
> > > > > >
> > > > > > [ERROR]
> > > > > > >
> > > > > >
> > > > >
> > >

Re: [DISCUSS] Should we have Jekyll build directly to asf-site branch?

[Christopher]

I don't think Dan's suggested flow is much different than what we have
now. In both cases, the steps are:

1. Initial PR to a branch (currently against main; Dan's approach
would be against a separate main-like staging branch)
2. Auto build on PR merge (currently, that's main -> asf-staging;
Dan's approach would build staging -> asf-staging)
3. View on staging site to evaluate for needed changes (auto-publish
of asf-staging branch) and repeat steps 1-3
4. Then decision to publish (currently, that's fast-forward git merge
from asf-staging to asf-site branch; in Dan's approach, it would be a
merge from the staging branch to the main branch, which triggers
another Jekyll build to the asf-site branch)
5. View on published site to evaluate for needed changes and repeat steps 1-5

In Dan's approach, we would be maintaining two source branches and two
build branches, and there's an extra Jekyll build, and the possibility
of introducing extra merge commits if we fail to do a FF merge from
the staging branch to the main branch.

Overall, I don't think the approach gets us anything we don't already
have, and it uses a bit more resources.
If we really need the extra staging step, then I'd prefer to keep the
current flow.

For comparison, the streamlined process I'm proposing is:

1. Initial PR to main branch
2. Auto build and publish on PR merge
3. View on published site to evaluate if additional changes need to be
made and repeat steps 1-3

We could delete the asf-staging branch, operating only with the main
and asf-site branches. In all cases, current and proposed, there are
alternate ways to view/evaluate a change:

1. As rendered Markdown in the GitHub PR (navigation and Jekyll
templated code won't work)
2. As local build (requires user to set up a local environment)
3. As built artifacts from GitHub Actions (slow download; best viewed
in a local webserver, but can also be viewed directly in a browser,
with some navigation limitations)
4. Temporarily create a new staging branch to stage to a separate
named staging site
5. Just view it published at the main site and fix it in a subsequent
change because it's fine if the site is broken slightly for a brief
moment (we can always revert the change if a fix isn't quick)

So, to recap the positions of this discussion's participants:

- Chris and I are in favor of streamlining by getting rid of the staging step.
- Dave and Dan were interested in leaving in a staging step.
- Dan suggested an alternate staging flow.

Unless others weigh in to lean one way or another, or Dave or Dan
switch their opinions, it's kind of a toss-up (no consensus), and I
guess we'll just keep things as they are now.



On Sun, Apr 9, 2023 at 9:56 AM Dave Marion  wrote:
>
> Christopher,
>
>   IIRC the local build is likely sufficient. It may have been that I failed
> to use it in all cases. I do remember in the past merging some PR's then
> noticing on the staging site that the links or formatting were not right. I
> think Dan's suggested change to the git workflow might also be useful
> (Auto-deply to staging on merge to staging branch, auto-deploy to apache.org
> on merge to main).
>
> On Fri, Apr 7, 2023 at 10:03 PM Christopher  wrote:
>
> > Hi Dave,
> >
> > How often would you estimate the diff in the PR is insufficient, and
> > you need a full site build to get a sense of how the change is viewed?
> > I imagine this might come up with some longer blog posts with a lot of
> > complex layout and references to docs, etc., but that doesn't happen
> > very frequently. I don't know if there are other times you feel it
> > would be helpful or how often those occur.
> >
> > Aside from local builds, are your concerns mitigated in any way by the
> > following?
> >
> > 1. Code reviewers checking the proposed changes for layout-related
> > mistakes before merging, or
> > 2. Subsequent commits to correct initial publication mistakes would
> > also be streamlined.
> >
> > (For reference, the local build is documented in the website README at
> >
> > https://github.com/apache/accumulo-website/blob/main/README.md#local-builds-for-testing
> > )
> >
> > On Fri, Apr 7, 2023 at 7:24 PM Dave Marion  wrote:
> > >
> > > I find the staging site useful for reviewing changes before publishing.
> > > There are some things that are not the easiest to review in a markdown
> > > diff. Especially since the markdown is transformed to what is ultimately
> > > displayed. I have no issue with streamlining this, I'll just need to
> > > remember to be more careful. There is a way to deploy locally IIRC, I'll
> > > just have to use that.
> > >
> > > On Fri, Apr 7, 2023 at 6:34 PM Christopher Shannon <
> > > christopher.l.shan...@gmail.com> wrote:
> >

Re: [VOTE] Apache Accumulo 1.10.3-rc1

[Christopher]

I think a lot of you are getting bugs because you're trying to build
with both the "hadoop-default" / "hadoop2" and the "hadoop3" profile
active at the same time, and that's causing dependency resolution
issues because the classpath is polluted with a bunch of extra stuff
(which you can see by adding in a `dependency:tree` to the maven
command).

If you're building using `-Phadoop3`, you should be aware that won't
de-activate the default profile, which is set up for Hadoop 2. The
correct way to build using the Hadoop 3 profile is with
`-Dhadoop.profile=3`, which activates the Hadoop 3 profile and
de-activates the default (Hadoop 2) profile at the same time:

`mvn clean package -Dtest=CredentialProviderFactoryShimTest -Dhadoop.profile=3`

When built correctly, I cannot reproduce the errors seen, but I can
reproduce it when I use the incorrect command.

Hadoop itself ships with commons-beanutils, and this credential
provider code is a Hadoop-specific feature. We don't have a dependency
on it for our code and don't ship beanutils in our tarball. This isn't
an issue in production, as long as you have your Hadoop libs on your
classpath correctly. The reason we use commons-configuration 1.6 is
because that converges with what Hadoop uses for [2.6.5,3.0). So, I
don't think we should change the version of that. We do ship it in our
tarball, because Hadoop 3.0.3 and later use commons-configuration2, so
commons-configuration needs to be on the classpath when using Hadoop
3, but we don't want the version to conflict with what Hadoop 2 is
using, so we ship the same version. We can expect commons-beanutils to
be there, though, since Hadoop ships that in all its releases.

We have enough votes that I could close the vote now, but I'll give it
another day for anybody who ran into issues to re-test with the
correct command, if they want, now that they have the updated
information.

On Tue, Apr 11, 2023 at 3:21 PM Mark Owens  wrote:
>
> If I update the pom's with the commons-configuration changes suggested by
> Dave in a previous post, I can successfully run the Sunny profile tests
> with both Hadoop 2 and Hadoop 3.
>
> On Tue, Apr 11, 2023 at 1:16 PM Daniel Roberts  wrote:
>
> > Yes, I changed the memory settings last week and was able to pass the
> > ExamplesIT.testScansWithInterference and
> > ExamplesIT.testIsolatedScansWithInterference
> > without issue. Given these environmental tweaks, do we have a documented
> > minimum machine spec that we expect the release tests to pass on?
> >
> > On Tue, Apr 11, 2023 at 1:00 PM Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > > The test failure for ExamplesIT.testScansWithInterference is likely from
> > > out of memory. See https://github.com/apache/accumulo/issues/3281
> > >
> > > On Tue, Apr 11, 2023 at 12:21 PM Dominic Garguilo <
> > > dominic.gargu...@gmail.com> wrote:
> > >
> > > > After running
> > > > mvn clean verify -Phadoop3,sunny
> > > > I am consistently seeing the following:
> > > >
> > > > [ERROR]
> > > > >
> > > >
> > >
> > org.apache.accumulo.core.conf.CredentialProviderFactoryShimTest.extractFromHdfs
> > > > >  Time elapsed: 3.605 s  <<< ERROR!
> > > > > java.lang.NoClassDefFoundError:
> > > > > org/apache/commons/beanutils/BeanIntrospector
> > > > > at
> > > > >
> > > >
> > >
> > org.apache.accumulo.core.conf.CredentialProviderFactoryShimTest.extractFromHdfs(CredentialProviderFactoryShimTest.java:185)
> > > > > Caused by: java.lang.ClassNotFoundException:
> > > > > org.apache.commons.beanutils.BeanIntrospector
> > > > > at
> > > > >
> > > >
> > >
> > org.apache.accumulo.core.conf.CredentialProviderFactoryShimTest.extractFromHdfs(CredentialProviderFactoryShimTest.java:185)
> > > >
> > > >
> > > > This test passes consistently when run in my IDE but fails every time
> > > when
> > > > running the mentioned maven command.
> > > >
> > > > On Mon, Apr 10, 2023 at 6:04 PM Dave Marion 
> > wrote:
> > > >
> > > > > *mvn clean verify -Phadoop3,sunny* failed in ExamplesIT with the
> > > > > aforementioned changes. Specifically,
> > > > ExamplesIT.testScansWithInterference
> > > > > failed with a server error when closing the batch writer. No further
> > > > > information in the logs.
> > > > >
> > > > > On Mon, Apr 10, 2023 at 5:06 PM Dave Marion 
> > > wrote:
> >

Re: [VOTE] Apache Accumulo 1.10.3-rc1

[Christopher Shannon]

DefFoundError:
> > >>> org/apache/commons/beanutils/BeanIntrospector
> > >>> at
> > >>>
> >
> org.apache.accumulo.core.conf.CredentialProviderFactoryShimTest.extractFromHdfs(CredentialProviderFactoryShimTest.java:185)
> > >>> Caused by: java.lang.ClassNotFoundException:
> > >>> org.apache.commons.beanutils.BeanIntrospector
> > >>> at
> > >>>
> >
> org.apache.accumulo.core.conf.CredentialProviderFactoryShimTest.extractFromHdfs(CredentialProviderFactoryShimTest.java:185)
> > >>>
> > >>> On Sun, Apr 9, 2023 at 11:41 AM Jeffrey Manno <
> > jeffreymann...@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> +1
> > >>>>
> > >>>> I did run into a few flaky tests but none seem to warrant a stoppage
> > to
> > >>>> this release candidate. Two common ones are SuspendTabletsIT and
> > >>>> DeleteTableDuringSplitIT.
> > >>>>
> > >>>> Other checks I did:
> > >>>>
> > >>>>- Ran the entire test suite, along with sunny day tests.
> > >>>>- Verified checksums.
> > >>>>- Did some small ingest testing with agitation.
> > >>>>
> > >>>>
> > >>>> On Sat, Apr 8, 2023 at 9:18 AM Christopher Shannon <
> > >>>> christopher.l.shan...@gmail.com> wrote:
> > >>>>
> > >>>> > +1 (binding), LGTM
> > >>>> >
> > >>>> > Some of the things I did for verification/testing locally:
> > >>>> >
> > >>>> > * Validated signatures and checksums
> > >>>> > * Verified license and notice files in archives
> > >>>> > * Verified source license headers with 'mvn apache-rat:check'
> > >>>> > * Built and ran all the sunny integration tests
> > >>>> > * Started up using Uno to make sure everything started correctly
> > >>>> (also ran
> > >>>> > a couple scans, etc)
> > >>>> >
> > >>>> > On Fri, Apr 7, 2023 at 4:23 PM Christopher 
> > >>>> wrote:
> > >>>> >
> > >>>> > > Accumulo Developers,
> > >>>> > >
> > >>>> > > Please consider the following candidate for Apache Accumulo
> > 1.10.3.
> > >>>> > >
> > >>>> > > Git Commit:
> > >>>> > > 733863638d85d0109d217da7ea5f36f5e483e207
> > >>>> > > Branch:
> > >>>> > > 1.10.3-rc1
> > >>>> > >
> > >>>> > > If this vote passes, a gpg-signed tag will be created using:
> > >>>> > > git tag -f -s -m 'Apache Accumulo 1.10.3' rel/1.10.3 \
> > >>>> > > 733863638d85d0109d217da7ea5f36f5e483e207
> > >>>> > >
> > >>>> > > Staging repo:
> > >>>> > >
> > >>>> >
> > >>>>
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1100
> > >>>> > > Source (official release artifact):
> > >>>> > >
> > >>>> > >
> > >>>> >
> > >>>>
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1100/org/apache/accumulo/accumulo/1.10.3/accumulo-1.10.3-src.tar.gz
> > >>>> > > Binary:
> > >>>> > >
> > >>>> >
> > >>>>
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1100/org/apache/accumulo/accumulo/1.10.3/accumulo-1.10.3-bin.tar.gz
> > >>>> > >
> > >>>> > > Append ".asc" to download the cryptographic signature for a
> given
> > >>>> > artifact.
> > >>>> > > (You can also append ".sha1" or ".md5" instead in order to
> verify
> > >>>> the
> > >>>> > > checksums
> > >>>> > > generated by Maven to verify the integrity of the Nexus
> repository
> > >>>> > > staging area.)
> > >>>> > >
> > >>>> > > Signing keys are available at
> > >>>> https://www.apache.org/dist/accumulo/KEYS
> > >>>> > > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> > >>>> > >
> > >>>> > > In addition to the tarballs and their signatures, the following
> > >>>> checksum
> > >>>> > > files will be added to the dist/release SVN area after release:
> > >>>> > > accumulo-1.10.3-src.tar.gz.sha512 will contain:
> > >>>> > > SHA512 (accumulo-1.10.3-src.tar.gz) =
> > >>>> > >
> > >>>> > >
> > >>>> >
> > >>>>
> >
> 436707da7424ea1b7993355d70747068264276234a4772f9da3866a638ad7860a754436f34ab2108e54801cced67f00ca2cfe0f46dfb80f2d7609b7b7112045e
> > >>>> > > accumulo-1.10.3-bin.tar.gz.sha512 will contain:
> > >>>> > > SHA512 (accumulo-1.10.3-bin.tar.gz) =
> > >>>> > >
> > >>>> > >
> > >>>> >
> > >>>>
> >
> 36e6795ad3720ba72fc9f4ddabf45f6d67cdc77658a181733fa2c47bfd3799f123b8840a79b538b8504a7b4bdc97fd0b52efab790395a5e022a897bc18405d0c
> > >>>> > >
> > >>>> > > Release notes (in progress) can be found at:
> > >>>> > > https://accumulo.staged.apache.org/release/accumulo-1.10.3
> > >>>> > >
> > >>>> > > Release testing instructions:
> > >>>> > > https://accumulo.apache.org/contributor/verifying-release
> > >>>> > >
> > >>>> > > 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.10.3 release of Apache Accumulo.
> > >>>> > >
> > >>>> > > This vote will remain open until at least Mon Apr 10 08:30:00 PM
> > UTC
> > >>>> > 2023.
> > >>>> > > (Mon Apr 10 04:30:00 PM EDT 2023 / Mon Apr 10 01:30:00 PM PDT
> > 2023)
> > >>>> > > Voting can continue after this deadline until the release
> manager
> > >>>> > > sends an email ending 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-1100/
> > >>>> > > # note the trailing slash is needed
> > >>>> > >
> > >>>> >
> > >>>>
> > >>>
> >
>

Re: [VOTE] Apache Accumulo 1.10.3-rc1

[Christopher Shannon]

+1 (binding), LGTM

Some of the things I did for verification/testing locally:

* Validated signatures and checksums
* Verified license and notice files in archives
* Verified source license headers with 'mvn apache-rat:check'
* Built and ran all the sunny integration tests
* Started up using Uno to make sure everything started correctly (also ran
a couple scans, etc)

On Fri, Apr 7, 2023 at 4:23 PM Christopher  wrote:

> Accumulo Developers,
>
> Please consider the following candidate for Apache Accumulo 1.10.3.
>
> Git Commit:
> 733863638d85d0109d217da7ea5f36f5e483e207
> Branch:
> 1.10.3-rc1
>
> If this vote passes, a gpg-signed tag will be created using:
> git tag -f -s -m 'Apache Accumulo 1.10.3' rel/1.10.3 \
> 733863638d85d0109d217da7ea5f36f5e483e207
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1100
> Source (official release artifact):
>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1100/org/apache/accumulo/accumulo/1.10.3/accumulo-1.10.3-src.tar.gz
> Binary:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1100/org/apache/accumulo/accumulo/1.10.3/accumulo-1.10.3-bin.tar.gz
>
> Append ".asc" to download the cryptographic signature for a given artifact.
> (You can also append ".sha1" or ".md5" instead in order to verify the
> checksums
> generated by Maven to verify the integrity of the Nexus repository
> staging area.)
>
> Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
>
> In addition to the tarballs and their signatures, the following checksum
> files will be added to the dist/release SVN area after release:
> accumulo-1.10.3-src.tar.gz.sha512 will contain:
> SHA512 (accumulo-1.10.3-src.tar.gz) =
>
> 436707da7424ea1b7993355d70747068264276234a4772f9da3866a638ad7860a754436f34ab2108e54801cced67f00ca2cfe0f46dfb80f2d7609b7b7112045e
> accumulo-1.10.3-bin.tar.gz.sha512 will contain:
> SHA512 (accumulo-1.10.3-bin.tar.gz) =
>
> 36e6795ad3720ba72fc9f4ddabf45f6d67cdc77658a181733fa2c47bfd3799f123b8840a79b538b8504a7b4bdc97fd0b52efab790395a5e022a897bc18405d0c
>
> Release notes (in progress) can be found at:
> https://accumulo.staged.apache.org/release/accumulo-1.10.3
>
> Release testing instructions:
> https://accumulo.apache.org/contributor/verifying-release
>
> 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.10.3 release of Apache Accumulo.
>
> This vote will remain open until at least Mon Apr 10 08:30:00 PM UTC 2023.
> (Mon Apr 10 04:30:00 PM EDT 2023 / Mon Apr 10 01:30:00 PM PDT 2023)
> Voting can continue after this deadline until the release manager
> sends an email ending 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-1100/
> # note the trailing slash is needed
>

Re: [DISCUSS] Should we have Jekyll build directly to asf-site branch?

[Christopher]

Hi Dave,

How often would you estimate the diff in the PR is insufficient, and
you need a full site build to get a sense of how the change is viewed?
I imagine this might come up with some longer blog posts with a lot of
complex layout and references to docs, etc., but that doesn't happen
very frequently. I don't know if there are other times you feel it
would be helpful or how often those occur.

Aside from local builds, are your concerns mitigated in any way by the
following?

1. Code reviewers checking the proposed changes for layout-related
mistakes before merging, or
2. Subsequent commits to correct initial publication mistakes would
also be streamlined.

(For reference, the local build is documented in the website README at
https://github.com/apache/accumulo-website/blob/main/README.md#local-builds-for-testing)

On Fri, Apr 7, 2023 at 7:24 PM Dave Marion  wrote:
>
> I find the staging site useful for reviewing changes before publishing.
> There are some things that are not the easiest to review in a markdown
> diff. Especially since the markdown is transformed to what is ultimately
> displayed. I have no issue with streamlining this, I'll just need to
> remember to be more careful. There is a way to deploy locally IIRC, I'll
> just have to use that.
>
> On Fri, Apr 7, 2023 at 6:34 PM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > +1 to make the change. I agree that when PRs are merged we generally just
> > want to publish immediately.
> >
> > FWIW, this is how we do things for the ActiveMQ website
> > <https://github.com/apache/activemq-website> and it works fine, we just
> > publish and there is no staging.
> >
> > On Fri, Apr 7, 2023 at 3:49 PM Christopher  wrote:
> >
> > > Hi Accumulo Devs,
> > >
> > > When I first set up the automation using .asf.yaml for Jekyll builds
> > > to go to the asf-staging branch, I expected us to get a bit more use
> > > out of the staging site at https://accumulo.staged.apache.org/
> > > However, that really hasn't happened, and it seems that we basically
> > > almost always want to publish to the https://accumulo.apache.org once
> > > we've approved a PR against the main branch and have a successful
> > > Jekyll build.
> > > Having the staging site is now just an unnecessary extra step to
> > > publish (that we sometimes forget to do for a while, even though it's
> > > trivial to run ./_scripts/publish.sh). I'm not sure it's adding any
> > > value.
> > >
> > > Perhaps we should just have Jekyll build directly to the asf-site
> > > branch and get rid of the asf-staging branch?
> > >
> > > The one benefit to the staging site is that, in theory, it's a
> > > conscientious decision to publish. But, I don't think we've ever come
> > > across any kind of situation where we wanted to stage the site, but
> > > then didn't immediately want to publish it. So, I'm not convinced that
> > > extra step is adding any value, especially since we're almost always
> > > making the conscientious decision in GitHub when approving a PR to
> > > update the site already.
> > >
> > > Any thoughts or opinions on this? I'm leaning slightly towards
> > > streamlining this.
> > >
> > > Regards,
> > > Christopher
> > >
> >

Re: [DISCUSS] Should we have Jekyll build directly to asf-site branch?

[Christopher]

Hi Dan,

Auto-publishing a PR to a staging branch is probably not a good idea
(I can see how it could be abused to put malicious content on the
apache.org domain).

Having some on-demand staging that is manually triggered could work,
but I'm pretty sure that would lead to more complexity than what we
have now, and right now it's very minimal.

I'm not sure if this helps, but I've already implemented auto-building
each PR, which you could view locally if you want. Check the
https://github.com/apache/accumulo-website/actions for recently built
site artifacts from PRs. Maybe that is a good option for some people
that would make this proposed streamlining easier to accept?


On Fri, Apr 7, 2023 at 7:39 PM Daniel Roberts  wrote:
>
> +1 I definitely agree that merges to main should deploy to asf-site.
> However, I think staging still has a place in the build pipeline, just not
> where it currently lives.
>
> The staging branch provides a way to review rendered changes and does
> remove the "worked on my machine" factor.
> Reviews can cover both the markdown source and rendered code.
>
> So, could auto publishing to the staging branch be part of the QA build
> step? Or maybe a manual build step being triggered?
> I could see the latter being useful if multiple PRs were open at the same
> time to avoid artifact publishing collisions.
>
> On Fri, Apr 7, 2023 at 6:34 PM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > +1 to make the change. I agree that when PRs are merged we generally just
> > want to publish immediately.
> >
> > FWIW, this is how we do things for the ActiveMQ website
> > <https://github.com/apache/activemq-website> and it works fine, we just
> > publish and there is no staging.
> >
> > On Fri, Apr 7, 2023 at 3:49 PM Christopher  wrote:
> >
> > > Hi Accumulo Devs,
> > >
> > > When I first set up the automation using .asf.yaml for Jekyll builds
> > > to go to the asf-staging branch, I expected us to get a bit more use
> > > out of the staging site at https://accumulo.staged.apache.org/
> > > However, that really hasn't happened, and it seems that we basically
> > > almost always want to publish to the https://accumulo.apache.org once
> > > we've approved a PR against the main branch and have a successful
> > > Jekyll build.
> > > Having the staging site is now just an unnecessary extra step to
> > > publish (that we sometimes forget to do for a while, even though it's
> > > trivial to run ./_scripts/publish.sh). I'm not sure it's adding any
> > > value.
> > >
> > > Perhaps we should just have Jekyll build directly to the asf-site
> > > branch and get rid of the asf-staging branch?
> > >
> > > The one benefit to the staging site is that, in theory, it's a
> > > conscientious decision to publish. But, I don't think we've ever come
> > > across any kind of situation where we wanted to stage the site, but
> > > then didn't immediately want to publish it. So, I'm not convinced that
> > > extra step is adding any value, especially since we're almost always
> > > making the conscientious decision in GitHub when approving a PR to
> > > update the site already.
> > >
> > > Any thoughts or opinions on this? I'm leaning slightly towards
> > > streamlining this.
> > >
> > > Regards,
> > > Christopher
> > >
> >

Re: [DISCUSS] Should we have Jekyll build directly to asf-site branch?

[Christopher Shannon]

+1 to make the change. I agree that when PRs are merged we generally just
want to publish immediately.

FWIW, this is how we do things for the ActiveMQ website
<https://github.com/apache/activemq-website> and it works fine, we just
publish and there is no staging.

On Fri, Apr 7, 2023 at 3:49 PM Christopher  wrote:

> Hi Accumulo Devs,
>
> When I first set up the automation using .asf.yaml for Jekyll builds
> to go to the asf-staging branch, I expected us to get a bit more use
> out of the staging site at https://accumulo.staged.apache.org/
> However, that really hasn't happened, and it seems that we basically
> almost always want to publish to the https://accumulo.apache.org once
> we've approved a PR against the main branch and have a successful
> Jekyll build.
> Having the staging site is now just an unnecessary extra step to
> publish (that we sometimes forget to do for a while, even though it's
> trivial to run ./_scripts/publish.sh). I'm not sure it's adding any
> value.
>
> Perhaps we should just have Jekyll build directly to the asf-site
> branch and get rid of the asf-staging branch?
>
> The one benefit to the staging site is that, in theory, it's a
> conscientious decision to publish. But, I don't think we've ever come
> across any kind of situation where we wanted to stage the site, but
> then didn't immediately want to publish it. So, I'm not convinced that
> extra step is adding any value, especially since we're almost always
> making the conscientious decision in GitHub when approving a PR to
> update the site already.
>
> Any thoughts or opinions on this? I'm leaning slightly towards
> streamlining this.
>
> Regards,
> Christopher
>

[VOTE] Apache Accumulo 1.10.3-rc1

[Christopher]

Accumulo Developers,

Please consider the following candidate for Apache Accumulo 1.10.3.

Git Commit:
733863638d85d0109d217da7ea5f36f5e483e207
Branch:
1.10.3-rc1

If this vote passes, a gpg-signed tag will be created using:
git tag -f -s -m 'Apache Accumulo 1.10.3' rel/1.10.3 \
733863638d85d0109d217da7ea5f36f5e483e207

Staging repo: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1100
Source (official release artifact):
https://repository.apache.org/content/repositories/orgapacheaccumulo-1100/org/apache/accumulo/accumulo/1.10.3/accumulo-1.10.3-src.tar.gz
Binary: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1100/org/apache/accumulo/accumulo/1.10.3/accumulo-1.10.3-bin.tar.gz

Append ".asc" to download the cryptographic signature for a given artifact.
(You can also append ".sha1" or ".md5" instead in order to verify the checksums
generated by Maven to verify the integrity of the Nexus repository
staging area.)

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

In addition to the tarballs and their signatures, the following checksum
files will be added to the dist/release SVN area after release:
accumulo-1.10.3-src.tar.gz.sha512 will contain:
SHA512 (accumulo-1.10.3-src.tar.gz) =
436707da7424ea1b7993355d70747068264276234a4772f9da3866a638ad7860a754436f34ab2108e54801cced67f00ca2cfe0f46dfb80f2d7609b7b7112045e
accumulo-1.10.3-bin.tar.gz.sha512 will contain:
SHA512 (accumulo-1.10.3-bin.tar.gz) =
36e6795ad3720ba72fc9f4ddabf45f6d67cdc77658a181733fa2c47bfd3799f123b8840a79b538b8504a7b4bdc97fd0b52efab790395a5e022a897bc18405d0c

Release notes (in progress) can be found at:
https://accumulo.staged.apache.org/release/accumulo-1.10.3

Release testing instructions:
https://accumulo.apache.org/contributor/verifying-release

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.10.3 release of Apache Accumulo.

This vote will remain open until at least Mon Apr 10 08:30:00 PM UTC 2023.
(Mon Apr 10 04:30:00 PM EDT 2023 / Mon Apr 10 01:30:00 PM PDT 2023)
Voting can continue after this deadline until the release manager
sends an email ending 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-1100/
# note the trailing slash is needed

[DISCUSS] Should we have Jekyll build directly to asf-site branch?

[Christopher]

Hi Accumulo Devs,

When I first set up the automation using .asf.yaml for Jekyll builds
to go to the asf-staging branch, I expected us to get a bit more use
out of the staging site at https://accumulo.staged.apache.org/
However, that really hasn't happened, and it seems that we basically
almost always want to publish to the https://accumulo.apache.org once
we've approved a PR against the main branch and have a successful
Jekyll build.
Having the staging site is now just an unnecessary extra step to
publish (that we sometimes forget to do for a while, even though it's
trivial to run ./_scripts/publish.sh). I'm not sure it's adding any
value.

Perhaps we should just have Jekyll build directly to the asf-site
branch and get rid of the asf-staging branch?

The one benefit to the staging site is that, in theory, it's a
conscientious decision to publish. But, I don't think we've ever come
across any kind of situation where we wanted to stage the site, but
then didn't immediately want to publish it. So, I'm not convinced that
extra step is adding any value, especially since we're almost always
making the conscientious decision in GitHub when approving a PR to
update the site already.

Any thoughts or opinions on this? I'm leaning slightly towards
streamlining this.

Regards,
Christopher

Re: [DISCUSS] Accumulo quarterly report (due Saturday 4/8)

[Christopher Shannon]

Report looks good, I don't' think there's anything else to add.

On Wed, Apr 5, 2023 at 7:58 AM Dave Marion  wrote:

> LGTM. Thanks for putting this together Ed.
>
> On Tue, Apr 4, 2023 at 4:27 PM dev1  wrote:
>
> > The Accumulo community decided to draft the Apache community reports on
> > the Accumulo dev list – and this is a draft of the January report for
> > review / comments.
> >
> > The text below is copied from the reporting tool and may not reflect the
> > final formatting of the final report when submitted.
> >
> > Ed Coleman
> >
> > --- report tool text ---
> >
> > ## Description:
> > The mission of Apache Accumulo is the creation and maintenance of
> software
> > related to a robust, scalable, distributed key/value store with
> cell-based
> > access control and customizable server-side processing.
> >
> > ## Issues:
> > There are no issues requiring board attention.
> >
> > ## Membership Data:
> > Apache Accumulo was founded 2012-03-21 (11 years ago)
> > There are currently 41 committers and 39 PMC members in this project.
> > The Committer-to-PMC ratio is roughly 6:5.
> >
> > Community changes, past quarter:
> > - No new PMC members. Last addition was Christopher L. Shannon on
> > 2022-09-27.
> > - No new committers. Last addition was Christopher L. Shannon on
> > 2022-09-27.
> >
> > Members transitioned to emeritus:
> > - Arvind Shyamsundar (arvindsh)
> > - David Medinets (medined)
> >
> > ## Project Activity:
> > Accumulo has started discussions and work to change the processing model
> to
> > support dynamic scaling and provide elasticity. The Accumulo Confluence
> > space[1] was activated to host the design documents and provide a
> > collaboration platform for developers and users. The goal is to move
> from a
> > model where active table metatdata and table data management is hosted in
> > active processes to a model that can dynamically scale server components
> > on-demand to provide configurable latency and higher scalability.
> >
> > Upcoming planned releases expected in the next quarter.
> > - Maintenance releases of 1.10.3 and 2.1.1, (The legacy 1.x line will
> reach
> >   end-of-life on 2022-11-01)
> > - The 3.0 release is planned to be a removal of deprecated items as
> > permitted
> >   by semver, but with minimal other changes. The 3.0 release will be a
> >   baseline for redesign work but the community has not decided if the
> > redesign
> >   would be a 3.1 or a 4.0 release. Those discussions will occur as the
> > design
> >   continues to evolve
> >
> > ## Community Health:
> > Overall community health is good and GitHub activity remains consistent.
> >
> > - The current decline in GitHub activity is due to quiet post-release
> > activity
> >   and work concentrating on a redesign efforts, including activity
> >   occurring on Confluence
> >
> > - Accumulo has transitioned from Jira to GitHub issues. The remaining
> Jira
> >   activity reflects closing obsolete issues.
> >
> > ## Links
> > [1]
> >
> https://cwiki.apache.org/confluence/display/ACCUMULO/Apache+Accumulo+Home
> >
>

Re: [TEST][VOTE] Apache Accumulo 1.10.3-rc0

[Christopher]

I got the same error in Eclipse when I ran the test there, and by
running that command that you did. But, when I run the test by itself,
it only gets the error *sometimes*.

mvn clean package -Phadoop3 -Dtest=VfsClassLoaderTest

I found a discussion online that led me down a rabbit hole looking at
the Jetty dependency. It turns out Hadoop 2 (which Accumulo 1.10 still
supports) still depends on the old Mortbay Jetty, but Hadoop 3.0.3
actually uses Eclipse Jetty 9.3, not the 9.2 we were using to avoid
requiring Java 8. Since we now require Java 8 for 1.10, I think
bumping to 9.3 will fix this issue with hadoop-minicluster and the
Hadoop3 profile in the least disruptive way (will still need to run
all tests using both profiles to be sure).

https://github.com/apache/accumulo/pull/3280

(Also note that `-Psunny` constrains the ITs, not the unit tests, so
using it with `package` is meaningless here. It would only be useful
if you used `verify` instead of `package` to run ITs in addition to
UTs)

On Thu, Apr 6, 2023 at 1:48 PM Dave Marion  wrote:
>
> `mvn -Dtimeout.factor=2 clean package -Psunny` works, but `mvn
> -Dtimeout.factor=2 clean package -Psunny,hadoop3` fails with:
>
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 1.153 s <<< FAILURE! - in
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest
> [ERROR]
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest
>  Time elapsed: 1.15 s  <<< ERROR!
> java.lang.NoSuchMethodError: 'boolean
> org.eclipse.jetty.servlet.ServletMapping.containsPathSpec(java.lang.String)'
>
> On Thu, Apr 6, 2023 at 1:36 PM Dave Marion  wrote:
>
> > `mvn -Dtimeout.factor=2 clean package` worked. Thanks!
> >
> > On Thu, Apr 6, 2023 at 1:19 PM Christopher  wrote:
> >
> >> Might just be a coincidence. If it's still failing with a higher timeout,
> >> I
> >> can look into it.
> >>
> >> On Thu, Apr 6, 2023, 12:51 Dave Marion  wrote:
> >>
> >> > I just thought it was odd that it was working in one place (git
> >> workspace),
> >> > but not from the source tarball.
> >> >
> >> > On Thu, Apr 6, 2023 at 12:48 PM Christopher 
> >> wrote:
> >> >
> >> > > Those are timeouts. The tests are passing in Jenkins. I suspect your
> >> > > machine is a little slower, but would finish with more time. You can
> >> set
> >> > > -Dtimeout.factor=2 to try to work around it for a local build on a
> >> > machine
> >> > > with more constrained resources. I wouldn't be surprised if 1.10 tests
> >> > were
> >> > > a bit more flaky than newer branches, also, just because of test
> >> > > improvements over time, but timeouts can happen for any of our
> >> branches.
> >> > So
> >> > > overriding the arbitrary timeout by some factor can help.
> >> > >
> >> > > On Thu, Apr 6, 2023, 12:41 Dave Marion  wrote:
> >> > >
> >> > > > Verified sha1 & md5 signatures
> >> > > > Verified signing key
> >> > > >
> >> > > > Ran into an issue trying to build from the source tarball. I tried 3
> >> > > times
> >> > > > with the command `mvn clean package` and the build failed in the
> >> same
> >> > > spot
> >> > > > every time (see below). Note that on the same machine I ran `mvn
> >> clean
> >> > > > package` on my local git workspace copy of the 1.10 branch (at
> >> > > > commit fb09e7e2594c451317ce6294b9dd27bd0c5e6c05) with no issues.
> >> > > >
> >> > > > [ERROR] Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time
> >> elapsed:
> >> > > > 96.173 s <<< FAILURE! - in
> >> > > > org.apache.accumulo.minicluster.MiniAccumuloClusterTest
> >> > > > [ERROR]
> >> > > >
> >> > > >
> >> > >
> >> >
> >> org.apache.accumulo.minicluster.MiniAccumuloClusterTest.testPerTableClasspath
> >> > > >  Time elapsed: 60.009 s  <<< ERROR!
> >> > > > org.junit.runners.model.TestTimedOutException: test timed out after
> >> > 6
> >> > > > milliseconds
> >> > > > at
> >> > > >
> >> > > >
> >> > >
> >> >
> >> app//org.apache.accumulo.minicluster.MiniAccumuloClusterTest.testPerTableClasspath(MiniAccumuloClusterTest.java:169)
> >> 

Re: [TEST][VOTE] Apache Accumulo 1.10.3-rc0

[Christopher]

>
> OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated
> in version 9.0 and will likely be removed in a future release.
>
> Starting tserver on localhost
>
>
> WARNING: An illegal reflective access operation has occurred
>
>
> WARNING: Illegal reflective access by
> org.apache.hadoop.security.authentication.util.KerberosUtil
> (file:/home/mark/dev/fluo-uno/install/hadoop-2.6.5/share/hadoop/common
> /lib/hadoop-auth-2.6.5.jar) to method
> sun.security.krb5.Config.getInstance()
>
> WARNING: Please consider reporting this to the maintainers of
> org.apache.hadoop.security.authentication.util.KerberosUtil
>
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
>
> WARNING: All illegal access operations will be denied in a future release
>
>
> 2023-04-06 15:21:02,511 [start.Main] ERROR: Thread
> 'org.apache.accumulo.master.state.SetGoalState' died.
> java.lang.ExceptionInInitializerError
>
> at org.apache.hadoop.util.StringUtils.(StringUtils.java:79)
>
> at
> org.apache.hadoop.security.Groups.parseStaticMapping(Groups.java:116)
> at org.apache.hadoop.security.Groups.(Groups.java:93)
> at org.apache.hadoop.security.Groups.(Groups.java:73)
> at
> org.apache.hadoop.security.Groups.getUserToGroupsMappingService(Groups.java:293)
> at
> org.apache.hadoop.security.UserGroupInformation.initialize(UserGroupInformation.java:283)
> at
> org.apache.hadoop.security.UserGroupInformation.ensureInitialized(UserGroupInformation.java:260)
> at
> org.apache.hadoop.security.UserGroupInformation.loginUserFromSubject(UserGroupInformation.java:789)
> at
> org.apache.hadoop.security.UserGroupInformation.getLoginUser(UserGroupInformation.java:774)
> at
> org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:647)
> at
> org.apache.hadoop.fs.FileSystem$Cache$Key.(FileSystem.java:2755)
> at
> org.apache.hadoop.fs.FileSystem$Cache$Key.(FileSystem.java:2747)
> at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2613)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:370)
> at org.apache.hadoop.fs.Path.getFileSystem(Path.java:296)
> at
> org.apache.accumulo.core.volume.VolumeImpl.(VolumeImpl.java:45)
> at
> org.apache.accumulo.core.volume.VolumeConfiguration.create(VolumeConfiguration.java:161)
> at
> org.apache.accumulo.server.fs.VolumeManagerImpl.get(VolumeManagerImpl.java:357)
> at
> org.apache.accumulo.server.fs.VolumeManagerImpl.get(VolumeManagerImpl.java:339)
> at
> org.apache.accumulo.server.fs.VolumeManagerImpl.get(VolumeManagerImpl.java:333)
> at
> org.apache.accumulo.master.state.SetGoalState.main(SetGoalState.java:46)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.apache.accumulo.start.Main$2.run(Main.java:170)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3,
> length 2
> at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3319)
> at java.base/java.lang.String.substring(String.java:1874)
> at org.apache.hadoop.util.Shell.(Shell.java:50)
> ... 27 more
>
>
>
> On Thu, Apr 6, 2023 at 3:09 PM Christopher  wrote:
>
> > I think we need more of that stack trace to be able to interpret it at all.
> >
> > On Thu, Apr 6, 2023, 13:57 Mark Owens  wrote:
> >
> > > I'm also running into an issue with the VfsClassLoaderTest.
> > >
> > > java.lang.ExceptionInInitializerError
> > >
> > >
> > > Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3,
> > > length 2
> > >
> > > I've seen this error message before but can't recall the details. May be
> > > some misconfiguration on my machine perhaps, but I'm not sure.
> > >
> > > On Thu, Apr 6, 2023 at 1:48 PM Dave Marion  wrote:
> > >
> > > > `mvn -Dtimeout.factor=2 clean package -Psunny` works, but `mvn
> > > > -Dtimeout.factor=2 clean package -Psunny,hadoop3` fails with:
> > > >
> > > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> &g

Re: [TEST][VOTE] Apache Accumulo 1.10.3-rc0

[Christopher]

I think we need more of that stack trace to be able to interpret it at all.

On Thu, Apr 6, 2023, 13:57 Mark Owens  wrote:

> I'm also running into an issue with the VfsClassLoaderTest.
>
> java.lang.ExceptionInInitializerError
>
>
> Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3,
> length 2
>
> I've seen this error message before but can't recall the details. May be
> some misconfiguration on my machine perhaps, but I'm not sure.
>
> On Thu, Apr 6, 2023 at 1:48 PM Dave Marion  wrote:
>
> > `mvn -Dtimeout.factor=2 clean package -Psunny` works, but `mvn
> > -Dtimeout.factor=2 clean package -Psunny,hadoop3` fails with:
> >
> > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> > 1.153 s <<< FAILURE! - in
> > org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest
> > [ERROR]
> > org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest
> >  Time elapsed: 1.15 s  <<< ERROR!
> > java.lang.NoSuchMethodError: 'boolean
> >
> >
> org.eclipse.jetty.servlet.ServletMapping.containsPathSpec(java.lang.String)'
> >
> > On Thu, Apr 6, 2023 at 1:36 PM Dave Marion  wrote:
> >
> > > `mvn -Dtimeout.factor=2 clean package` worked. Thanks!
> > >
> > > On Thu, Apr 6, 2023 at 1:19 PM Christopher 
> wrote:
> > >
> > >> Might just be a coincidence. If it's still failing with a higher
> > timeout,
> > >> I
> > >> can look into it.
> > >>
> > >> On Thu, Apr 6, 2023, 12:51 Dave Marion  wrote:
> > >>
> > >> > I just thought it was odd that it was working in one place (git
> > >> workspace),
> > >> > but not from the source tarball.
> > >> >
> > >> > On Thu, Apr 6, 2023 at 12:48 PM Christopher 
> > >> wrote:
> > >> >
> > >> > > Those are timeouts. The tests are passing in Jenkins. I suspect
> your
> > >> > > machine is a little slower, but would finish with more time. You
> can
> > >> set
> > >> > > -Dtimeout.factor=2 to try to work around it for a local build on a
> > >> > machine
> > >> > > with more constrained resources. I wouldn't be surprised if 1.10
> > tests
> > >> > were
> > >> > > a bit more flaky than newer branches, also, just because of test
> > >> > > improvements over time, but timeouts can happen for any of our
> > >> branches.
> > >> > So
> > >> > > overriding the arbitrary timeout by some factor can help.
> > >> > >
> > >> > > On Thu, Apr 6, 2023, 12:41 Dave Marion 
> wrote:
> > >> > >
> > >> > > > Verified sha1 & md5 signatures
> > >> > > > Verified signing key
> > >> > > >
> > >> > > > Ran into an issue trying to build from the source tarball. I
> > tried 3
> > >> > > times
> > >> > > > with the command `mvn clean package` and the build failed in the
> > >> same
> > >> > > spot
> > >> > > > every time (see below). Note that on the same machine I ran `mvn
> > >> clean
> > >> > > > package` on my local git workspace copy of the 1.10 branch (at
> > >> > > > commit fb09e7e2594c451317ce6294b9dd27bd0c5e6c05) with no issues.
> > >> > > >
> > >> > > > [ERROR] Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time
> > >> elapsed:
> > >> > > > 96.173 s <<< FAILURE! - in
> > >> > > > org.apache.accumulo.minicluster.MiniAccumuloClusterTest
> > >> > > > [ERROR]
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> org.apache.accumulo.minicluster.MiniAccumuloClusterTest.testPerTableClasspath
> > >> > > >  Time elapsed: 60.009 s  <<< ERROR!
> > >> > > > org.junit.runners.model.TestTimedOutException: test timed out
> > after
> > >> > 6
> > >> > > > milliseconds
> > >> > > > at
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> app//org.apache.accumulo.minicluster.MiniAccumuloClusterTest.testPerTableClasspath(MiniAccumuloClusterTest.java:169

Re: [TEST][VOTE] Apache Accumulo 1.10.3-rc0

[Christopher]

Might just be a coincidence. If it's still failing with a higher timeout, I
can look into it.

On Thu, Apr 6, 2023, 12:51 Dave Marion  wrote:

> I just thought it was odd that it was working in one place (git workspace),
> but not from the source tarball.
>
> On Thu, Apr 6, 2023 at 12:48 PM Christopher  wrote:
>
> > Those are timeouts. The tests are passing in Jenkins. I suspect your
> > machine is a little slower, but would finish with more time. You can set
> > -Dtimeout.factor=2 to try to work around it for a local build on a
> machine
> > with more constrained resources. I wouldn't be surprised if 1.10 tests
> were
> > a bit more flaky than newer branches, also, just because of test
> > improvements over time, but timeouts can happen for any of our branches.
> So
> > overriding the arbitrary timeout by some factor can help.
> >
> > On Thu, Apr 6, 2023, 12:41 Dave Marion  wrote:
> >
> > > Verified sha1 & md5 signatures
> > > Verified signing key
> > >
> > > Ran into an issue trying to build from the source tarball. I tried 3
> > times
> > > with the command `mvn clean package` and the build failed in the same
> > spot
> > > every time (see below). Note that on the same machine I ran `mvn clean
> > > package` on my local git workspace copy of the 1.10 branch (at
> > > commit fb09e7e2594c451317ce6294b9dd27bd0c5e6c05) with no issues.
> > >
> > > [ERROR] Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed:
> > > 96.173 s <<< FAILURE! - in
> > > org.apache.accumulo.minicluster.MiniAccumuloClusterTest
> > > [ERROR]
> > >
> > >
> >
> org.apache.accumulo.minicluster.MiniAccumuloClusterTest.testPerTableClasspath
> > >  Time elapsed: 60.009 s  <<< ERROR!
> > > org.junit.runners.model.TestTimedOutException: test timed out after
> 6
> > > milliseconds
> > > at
> > >
> > >
> >
> app//org.apache.accumulo.minicluster.MiniAccumuloClusterTest.testPerTableClasspath(MiniAccumuloClusterTest.java:169)
> > >
> > > [ERROR] org.apache.accumulo.minicluster.MiniAccumuloClusterTest.test
> > Time
> > > elapsed: 30.001 s  <<< ERROR!
> > > org.junit.runners.model.TestTimedOutException: test timed out after
> 3
> > > milliseconds
> > > at
> > >
> > >
> >
> app//org.apache.accumulo.minicluster.MiniAccumuloClusterTest.test(MiniAccumuloClusterTest.java:157)
> > >
> > > On Wed, Apr 5, 2023 at 7:24 PM dev1  wrote:
> > >
> > > > I did some quick checks and all looks good.
> > > >
> > > > - verified sha512 signatures
> > > > - verified signing key
> > > > - sunny tests pass.
> > > >
> > > > Ed Coleman
> > > >
> > > > -Original Message-
> > > > From: Christopher 
> > > > Sent: Wednesday, April 5, 2023 4:25 PM
> > > > To: accumulo-dev 
> > > > Subject: [TEST][VOTE] Apache Accumulo 1.10.3-rc0
> > > >
> > > > Accumulo Developers,
> > > >
> > > > This is not an actual vote.
> > > > I have prepared the following release candidate as a test build for
> > > > 1.10.3. If there are no immediate objections or issues, I intend to
> > > create
> > > > an RC1 release candidate in the next day or so, to vote on.
> > > >
> > > > Git Commit:
> > > > ed75b4521094faa6f6e1037a444747390a120068
> > > > Branch:
> > > > 1.10.3-rc0
> > > >
> > > > If this vote passes, a gpg-signed tag will be created using:
> > > > git tag -f -s -m 'Apache Accumulo 1.10.3' rel/1.10.3 \
> > > > ed75b4521094faa6f6e1037a444747390a120068
> > > >
> > > > Staging repo:
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1099
> > > > Source (official release artifact):
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1099/org/apache/accumulo/accumulo/1.10.3/accumulo-1.10.3-src.tar.gz
> > > > Binary:
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1099/org/apache/accumulo/accumulo/1.10.3/accumulo-1.10.3-bin.tar.gz
> > 

Re: [TEST][VOTE] Apache Accumulo 1.10.3-rc0

[Christopher]

Those are timeouts. The tests are passing in Jenkins. I suspect your
machine is a little slower, but would finish with more time. You can set
-Dtimeout.factor=2 to try to work around it for a local build on a machine
with more constrained resources. I wouldn't be surprised if 1.10 tests were
a bit more flaky than newer branches, also, just because of test
improvements over time, but timeouts can happen for any of our branches. So
overriding the arbitrary timeout by some factor can help.

On Thu, Apr 6, 2023, 12:41 Dave Marion  wrote:

> Verified sha1 & md5 signatures
> Verified signing key
>
> Ran into an issue trying to build from the source tarball. I tried 3 times
> with the command `mvn clean package` and the build failed in the same spot
> every time (see below). Note that on the same machine I ran `mvn clean
> package` on my local git workspace copy of the 1.10 branch (at
> commit fb09e7e2594c451317ce6294b9dd27bd0c5e6c05) with no issues.
>
> [ERROR] Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed:
> 96.173 s <<< FAILURE! - in
> org.apache.accumulo.minicluster.MiniAccumuloClusterTest
> [ERROR]
>
> org.apache.accumulo.minicluster.MiniAccumuloClusterTest.testPerTableClasspath
>  Time elapsed: 60.009 s  <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 6
> milliseconds
> at
>
> app//org.apache.accumulo.minicluster.MiniAccumuloClusterTest.testPerTableClasspath(MiniAccumuloClusterTest.java:169)
>
> [ERROR] org.apache.accumulo.minicluster.MiniAccumuloClusterTest.test  Time
> elapsed: 30.001 s  <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 3
> milliseconds
> at
>
> app//org.apache.accumulo.minicluster.MiniAccumuloClusterTest.test(MiniAccumuloClusterTest.java:157)
>
> On Wed, Apr 5, 2023 at 7:24 PM dev1  wrote:
>
> > I did some quick checks and all looks good.
> >
> > - verified sha512 signatures
> > - verified signing key
> > - sunny tests pass.
> >
> > Ed Coleman
> >
> > -Original Message-
> > From: Christopher 
> > Sent: Wednesday, April 5, 2023 4:25 PM
> > To: accumulo-dev 
> > Subject: [TEST][VOTE] Apache Accumulo 1.10.3-rc0
> >
> > Accumulo Developers,
> >
> > This is not an actual vote.
> > I have prepared the following release candidate as a test build for
> > 1.10.3. If there are no immediate objections or issues, I intend to
> create
> > an RC1 release candidate in the next day or so, to vote on.
> >
> > Git Commit:
> > ed75b4521094faa6f6e1037a444747390a120068
> > Branch:
> > 1.10.3-rc0
> >
> > If this vote passes, a gpg-signed tag will be created using:
> > git tag -f -s -m 'Apache Accumulo 1.10.3' rel/1.10.3 \
> > ed75b4521094faa6f6e1037a444747390a120068
> >
> > Staging repo:
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1099
> > Source (official release artifact):
> >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1099/org/apache/accumulo/accumulo/1.10.3/accumulo-1.10.3-src.tar.gz
> > Binary:
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1099/org/apache/accumulo/accumulo/1.10.3/accumulo-1.10.3-bin.tar.gz
> >
> > Append ".asc" to download the cryptographic signature for a given
> artifact.
> > (You can also append ".sha1" or ".md5" instead in order to verify the
> > checksums generated by Maven to verify the integrity of the Nexus
> > repository staging area.)
> >
> > Signing keys are available at https://www.apache.org/dist/accumulo/KEYS
> > (Expected fingerprint: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D)
> >
> > In addition to the tarballs and their signatures, the following checksum
> > files will be added to the dist/release SVN area after release:
> > accumulo-1.10.3-src.tar.gz.sha512 will contain:
> > SHA512 (accumulo-1.10.3-src.tar.gz) =
> >
> >
> 5ec3baab85a0338b273fb5bd79bf2146c855077333f8a170c9e7093810f8591c458479bcebb5d57a4134a00f02b1c060db159e6ff086241aac6532d0e3e033f2
> > accumulo-1.10.3-bin.tar.gz.sha512 will contain:
> > SHA512 (accumulo-1.10.3-bin.tar.gz) =
> >
> >
> f8465b81c37067001b31ee109648760d51b78d91cff7ac93735af1735c2b6ee4f37e58cbd64253e257590fdc03fe784ef85782cc5b5039a8db170ca965c8628c
> >
> > Release notes (in progress) can be found at:
> > https://accumulo.staged.apache.org/release/accumulo-1.10.3
> >
> > Release testing instructions:
> > https://accumulo.apache.org/contributor/verifying-release
> >
> > Please vote one o

[TEST][VOTE] Apache Accumulo 1.10.3-rc0

[Christopher]

Accumulo Developers,

This is not an actual vote.
I have prepared the following release candidate as a test build for
1.10.3. If there are no immediate objections or issues, I intend to
create an RC1 release candidate in the next day or so, to vote on.

Git Commit:
ed75b4521094faa6f6e1037a444747390a120068
Branch:
1.10.3-rc0

If this vote passes, a gpg-signed tag will be created using:
git tag -f -s -m 'Apache Accumulo 1.10.3' rel/1.10.3 \
ed75b4521094faa6f6e1037a444747390a120068

Staging repo: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1099
Source (official release artifact):
https://repository.apache.org/content/repositories/orgapacheaccumulo-1099/org/apache/accumulo/accumulo/1.10.3/accumulo-1.10.3-src.tar.gz
Binary: 
https://repository.apache.org/content/repositories/orgapacheaccumulo-1099/org/apache/accumulo/accumulo/1.10.3/accumulo-1.10.3-bin.tar.gz

Append ".asc" to download the cryptographic signature for a given artifact.
(You can also append ".sha1" or ".md5" instead in order to verify the checksums
generated by Maven to verify the integrity of the Nexus repository
staging area.)

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

In addition to the tarballs and their signatures, the following checksum
files will be added to the dist/release SVN area after release:
accumulo-1.10.3-src.tar.gz.sha512 will contain:
SHA512 (accumulo-1.10.3-src.tar.gz) =
5ec3baab85a0338b273fb5bd79bf2146c855077333f8a170c9e7093810f8591c458479bcebb5d57a4134a00f02b1c060db159e6ff086241aac6532d0e3e033f2
accumulo-1.10.3-bin.tar.gz.sha512 will contain:
SHA512 (accumulo-1.10.3-bin.tar.gz) =
f8465b81c37067001b31ee109648760d51b78d91cff7ac93735af1735c2b6ee4f37e58cbd64253e257590fdc03fe784ef85782cc5b5039a8db170ca965c8628c

Release notes (in progress) can be found at:
https://accumulo.staged.apache.org/release/accumulo-1.10.3

Release testing instructions:
https://accumulo.apache.org/contributor/verifying-release

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.10.3 release of Apache Accumulo.

This vote will remain open until at least Sat Apr  8 08:30:00 PM UTC 2023.
(Sat Apr  8 04:30:00 PM EDT 2023 / Sat Apr  8 01:30:00 PM PDT 2023)
Voting can continue after this deadline until the release manager
sends an email ending 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-1099/
# note the trailing slash is needed

Re: [DISCUSS] Accumulo quarterly report (due Saturday 4/8)

[Christopher]

You should clarify that the members transitions to emeritus is for the PMC
only. One way to word this:

The following individuals stepped down from the PMC and are now considered
PMC Emeritus.

On Tue, Apr 4, 2023, 16:26 dev1  wrote:

> The Accumulo community decided to draft the Apache community reports on
> the Accumulo dev list – and this is a draft of the January report for
> review / comments.
>
> The text below is copied from the reporting tool and may not reflect the
> final formatting of the final report when submitted.
>
> Ed Coleman
>
> --- report tool text ---
>
> ## Description:
> The mission of Apache Accumulo is the creation and maintenance of software
> related to a robust, scalable, distributed key/value store with cell-based
> access control and customizable server-side processing.
>
> ## Issues:
> There are no issues requiring board attention.
>
> ## Membership Data:
> Apache Accumulo was founded 2012-03-21 (11 years ago)
> There are currently 41 committers and 39 PMC members in this project.
> The Committer-to-PMC ratio is roughly 6:5.
>
> Community changes, past quarter:
> - No new PMC members. Last addition was Christopher L. Shannon on
> 2022-09-27.
> - No new committers. Last addition was Christopher L. Shannon on
> 2022-09-27.
>
> Members transitioned to emeritus:
> - Arvind Shyamsundar (arvindsh)
> - David Medinets (medined)
>
> ## Project Activity:
> Accumulo has started discussions and work to change the processing model to
> support dynamic scaling and provide elasticity. The Accumulo Confluence
> space[1] was activated to host the design documents and provide a
> collaboration platform for developers and users. The goal is to move from a
> model where active table metatdata and table data management is hosted in
> active processes to a model that can dynamically scale server components
> on-demand to provide configurable latency and higher scalability.
>
> Upcoming planned releases expected in the next quarter.
> - Maintenance releases of 1.10.3 and 2.1.1, (The legacy 1.x line will reach
>   end-of-life on 2022-11-01)
> - The 3.0 release is planned to be a removal of deprecated items as
> permitted
>   by semver, but with minimal other changes. The 3.0 release will be a
>   baseline for redesign work but the community has not decided if the
> redesign
>   would be a 3.1 or a 4.0 release. Those discussions will occur as the
> design
>   continues to evolve
>
> ## Community Health:
> Overall community health is good and GitHub activity remains consistent.
>
> - The current decline in GitHub activity is due to quiet post-release
> activity
>   and work concentrating on a redesign efforts, including activity
>   occurring on Confluence
>
> - Accumulo has transitioned from Jira to GitHub issues. The remaining Jira
>   activity reflects closing obsolete issues.
>
> ## Links
> [1]
> https://cwiki.apache.org/confluence/display/ACCUMULO/Apache+Accumulo+Home
>

Re: Avro Vulnerability Update

[Christopher]

Oh, I just had a thought. We do use jackson, so if that's being upgraded
and is on Accumulo's classpath, there might be a small chance of it
affecting it. But we frequently update our jackson dependency without
problems, so I wouldn't expect to see any issues. As always, if you're
concerned about the risks, try it on a test environment first.

On Thu, Mar 30, 2023, 20:55 Christopher  wrote:

> Accumulo doesn't use AVRO directly, so it shouldn't affect Accumulo if you
> upgrade it for Hadoop.
>
> On Thu, Mar 30, 2023, 14:56 Logan Jones  wrote:
>
>> Hello:
>>
>> Hadoop 3.3.4 has some critical vulnerabilities that it pulls in from avro
>> 1.7.7 -> jackson-mapper-asl 1.9.13
>>
>> The only thing in my HDFS cluster is Accumulo. Can I safely upgrade my
>> cluster to use Avro 1.11.X or will this break Accumulo?
>>
>> Thanks,
>>
>> - Logan
>>
>

Re: Avro Vulnerability Update

[Christopher]

Accumulo doesn't use AVRO directly, so it shouldn't affect Accumulo if you
upgrade it for Hadoop.

On Thu, Mar 30, 2023, 14:56 Logan Jones  wrote:

> Hello:
>
> Hadoop 3.3.4 has some critical vulnerabilities that it pulls in from avro
> 1.7.7 -> jackson-mapper-asl 1.9.13
>
> The only thing in my HDFS cluster is Accumulo. Can I safely upgrade my
> cluster to use Avro 1.11.X or will this break Accumulo?
>
> Thanks,
>
> - Logan
>

Re: Dynamic Scaling of Accumulo

[Christopher]

mits added a new property for the user to specify
> which tablet unloader class[1] to use, with the default being [2]. We could
> add a new default implementation that does not unload and users would have
> to opt-in to unloading by setting the property for their online tables.
> However this is some code surrounding the new ondemand state that we would
> need to address. For example, when a TabletServer is low on memory it
> doesn't call the specified TabletUnloader, it just unloads a Tablet.
>
> [1]
> https://github.com/apache/accumulo/blob/elasticity/core/src/main/java/org/apache/accumulo/core/spi/ondemand/OnDemandTabletUnloader.java
> [2]
> https://github.com/apache/accumulo/blob/elasticity/core/src/main/java/org/apache/accumulo/core/spi/ondemand/DefaultOnDemandTabletUnloader.java
>
> On Tue, Mar 28, 2023 at 10:27 AM Christopher  wrote:
>
> > I think we should deprecate support for offline table scanning, since
> > it shouldn't be needed with the availability of ScanServers. Any
> > MapReduce that previously relied on scanning offline tables could be
> > made to use that instead.
> >
> > I agree there is a need to have an immutable table state, for which it
> > is possible to read, but no changes can be made. However, even in that
> > "locked" state, one should still be able to perform surgery on its
> > metadata, or manually / surgically compact files (with the
> > understanding that doing so will interfere with any concurrent export
> > or scan operations that are relying on it being immutable, which I
> > think is a tolerable amount of risk, when actually in a situation
> > where such surgery is needed).
> >
> > As for "ondemand" table state, from a user perspective, I'm not sure
> > what it means... is the "on-demand availability" applicable only for
> > live ingest / immediate consistency? Is it still "always available"
> > for bulk import / ScanServers? Or does "on-demand availability"
> > somehow apply to all interactions, including bulk import and
> > ScanServer reads?
> >
> > I think the "ondemand" state is confusing, because it's exposing
> > internal state through to the user, and in a way that isn't as clear
> > as the simple "online/offline" states used to be. Previously, users
> > didn't need to understand what was going on internally... "online"
> > just meant "I can interact with this table", and "offline" meant "I
> > can't interact with this table". The user wasn't required to
> > understand what a tablet was, or how it was hosted, or anything of
> > that nature. As we started adding support for "offline" features, the
> > lines separating "online and offline" meaning "available and
> > unavailable" became blurred. As we proceed adding elasticity, I think
> > we should work to make things more clear and explicit again... and I
> > think "ondemand" as a table state, makes things even less clear when
> > the concept is exposed to the user as a separate table state.
> >
> > I do think we need some kind of on-demand availability for live-ingest
> > and immediate consistency in order to be more elastic, and from the
> > discussion, it's obvious we need an immutable table state, but I think
> > it's a mistake to expose the on-demand availability for live-ingest
> > and immediate consistency as a new table state. I think that should be
> > left as either some kind of automatic internal behavior, or as a
> > secondary fine-grained control over an online table (like pinned
> > tablets, either permanently pinned or temporally pinned, based on
> > activity).
> >
> > On Tue, Mar 28, 2023 at 9:51 AM Drew Farris  wrote:
> > >
> > > On Mon, Mar 27, 2023 at 2:16 PM Keith Turner  wrote:
> > >
> > > > One realization that came out examining the different table states is
> > > > that export table currently relies on the fact that offline tables
> > > > will not delete files.  If we enable compactions on offline tables
> > > > then that could cause files to be deleted which would break the
> > > > expectation of export table.
> > > >
> > >
> > > This is a good point. I hadn't considered the potential breakage to
> > export
> > > table. I suspect another concern could be the hadoop input format that
> > > operates over the rfiles in an offline table - and can do so relatively
> > > safely
> > > because the table is not expected to change while it is offline.
> > >
> > > So, it would seem that there is value in having an 'immutable' table
> > state
> > > in
> > > the form of an offline table. Perhaps 'ondemand' is the alternate state
> > > that
> > > lets us do things like import, split, compact, merge, etc.
> >

Re: Dynamic Scaling of Accumulo

[Christopher]

I think we should deprecate support for offline table scanning, since
it shouldn't be needed with the availability of ScanServers. Any
MapReduce that previously relied on scanning offline tables could be
made to use that instead.

I agree there is a need to have an immutable table state, for which it
is possible to read, but no changes can be made. However, even in that
"locked" state, one should still be able to perform surgery on its
metadata, or manually / surgically compact files (with the
understanding that doing so will interfere with any concurrent export
or scan operations that are relying on it being immutable, which I
think is a tolerable amount of risk, when actually in a situation
where such surgery is needed).

As for "ondemand" table state, from a user perspective, I'm not sure
what it means... is the "on-demand availability" applicable only for
live ingest / immediate consistency? Is it still "always available"
for bulk import / ScanServers? Or does "on-demand availability"
somehow apply to all interactions, including bulk import and
ScanServer reads?

I think the "ondemand" state is confusing, because it's exposing
internal state through to the user, and in a way that isn't as clear
as the simple "online/offline" states used to be. Previously, users
didn't need to understand what was going on internally... "online"
just meant "I can interact with this table", and "offline" meant "I
can't interact with this table". The user wasn't required to
understand what a tablet was, or how it was hosted, or anything of
that nature. As we started adding support for "offline" features, the
lines separating "online and offline" meaning "available and
unavailable" became blurred. As we proceed adding elasticity, I think
we should work to make things more clear and explicit again... and I
think "ondemand" as a table state, makes things even less clear when
the concept is exposed to the user as a separate table state.

I do think we need some kind of on-demand availability for live-ingest
and immediate consistency in order to be more elastic, and from the
discussion, it's obvious we need an immutable table state, but I think
it's a mistake to expose the on-demand availability for live-ingest
and immediate consistency as a new table state. I think that should be
left as either some kind of automatic internal behavior, or as a
secondary fine-grained control over an online table (like pinned
tablets, either permanently pinned or temporally pinned, based on
activity).

On Tue, Mar 28, 2023 at 9:51 AM Drew Farris  wrote:
>
> On Mon, Mar 27, 2023 at 2:16 PM Keith Turner  wrote:
>
> > One realization that came out examining the different table states is
> > that export table currently relies on the fact that offline tables
> > will not delete files.  If we enable compactions on offline tables
> > then that could cause files to be deleted which would break the
> > expectation of export table.
> >
>
> This is a good point. I hadn't considered the potential breakage to export
> table. I suspect another concern could be the hadoop input format that
> operates over the rfiles in an offline table - and can do so relatively
> safely
> because the table is not expected to change while it is offline.
>
> So, it would seem that there is value in having an 'immutable' table state
> in
> the form of an offline table. Perhaps 'ondemand' is the alternate state
> that
> lets us do things like import, split, compact, merge, etc.

Re: Dynamic Scaling of Accumulo

[Christopher]

In that case, I think it's probably sufficient to let the users know the
risks of bulk importing and never bringing it online for compactions. It
seems like that's a risk some users might be okay with for their use case.

On Thu, Mar 23, 2023, 19:38 Dave Marion  wrote:

> Yes, if the table is never brought online. I believe that Keith said that
> the table could still be scanned when offline with existing MapReduce code
> or the OfflineScanner, which presents an issue that is not currently
> handled. I think we discussed today that the same thing could be achieved
> with tables in the on demand state. The reason to not modify an offline
> table is the export case, where the table needs to be immutable until the
> files are copied.
>
> On Thu, Mar 23, 2023, 6:58 PM Christopher  wrote:
>
>> What do you mean by "when not used in this manner"? What other way is
>> there to use that feature? Do you mean simply never being brought
>> online?
>>
>> Would it be possible to support (external) compactions for an offline
>> table?
>>
>> I feel like that's a pretty useful feature to revert, and would want
>> to consider alternatives.
>>
>> On Thu, Mar 23, 2023 at 6:39 PM Dave Marion  wrote:
>> >
>> > Keith and I had a discussion today (that included some user input)
>> > regarding table operations with the new OnDemand table concept. I have
>> put
>> > the notes up on the wiki at:
>> >
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=247828052
>> .
>> > One thing that came out of that is that we may want to revert the
>> change in
>> > the new bulk import code that allows a user to import into an offline
>> > table. The feature allows a user to create a table that is initially
>> > offline, bulk import data into it, then bring it online. However, when
>> not
>> > used in this manner the number of bulk import files would continue to
>> grow
>> > because compactions are never run on the table.
>> >
>> > On Mon, Mar 20, 2023 at 9:37 AM Dave Marion 
>> wrote:
>> >
>> > > Following up on this. Discussion and design documents are up on the
>> > > wiki[1]. There is a GitHub project[2] for planning out some of the
>> tasks,
>> > > which are then turned into issues. Some of the issues have draft PRs
>> > > submitted for them.
>> > >
>> > > [1] https://cwiki.apache.org/confluence/display/ACCUMULO/Elasticity
>> > > [2] https://github.com/orgs/apache/projects/164
>> > >
>> > > On Wed, Feb 22, 2023 at 2:35 PM Dave Marion 
>> wrote:
>> > >
>> > >> Except for the new bulk import code, Accumulo requires that tables
>> are in
>> > >> an online state to work with them (ingest, scan, compact, split,
>> etc.). In
>> > >> some cases this could become cost prohibitive and resource
>> inefficient as
>> > >> resources necessary to keep the tables online might be unused. I'd
>> like to
>> > >> propose a new capability for Accumulo - the ability to work with
>> tables
>> > >> that are not online. This could either mean working with tables in an
>> > >> offline state, or maybe the ability to assign/host tables/tablets on
>> > >> demand.
>> > >>
>> > >> At a high level the two ideas currently being discussed are below. I
>> > >> think in both cases the root and metadata tables must be online,
>> table
>> > >> management functions move to manager components, and compactions of
>> offline
>> > >> tables move to the external compaction processes. In addition, new
>> metrics
>> > >> would need to be emitted so that an external resource scheduler
>> could spin
>> > >> up/down server processes as demand changes.
>> > >>
>> > >>
>> > >> *Offline Operations*
>> > >>
>> > >> This approach allows all operations to occur on offline tables at the
>> > >> cost of having eventual consistency to the data at scan time (via
>> Scan
>> > >> Servers only). Live ingest could be supported through the creation
>> of an
>> > >> ingest server component that just receives mutations and minor
>> compacts.
>> > >>
>> > >>
>> > >>
>> > >> *On-demand Tables*
>> > >> This approach allows for user tables to be offline and un-hosted, but
>> > >> hosts them on demand for the purpose of live ingest and immediate
>> scans at
>> > >> the latency cost of possibly assigning and hosting the tablet.
>> > >>
>> > >> We have a few releases (1.10.3, 2.1.1, and 3.0.0) coming up in
>> likely the
>> > >> next month or two, but after that I'd like to start implementing
>> something
>> > >> to address this. Please contribute to the discussion if you have
>> thoughts
>> > >> on requirements, design, etc.
>> > >>
>> > >>
>> > >>
>> > >>
>>
>

Re: Dynamic Scaling of Accumulo

[Christopher]

What do you mean by "when not used in this manner"? What other way is
there to use that feature? Do you mean simply never being brought
online?

Would it be possible to support (external) compactions for an offline table?

I feel like that's a pretty useful feature to revert, and would want
to consider alternatives.

On Thu, Mar 23, 2023 at 6:39 PM Dave Marion  wrote:
>
> Keith and I had a discussion today (that included some user input)
> regarding table operations with the new OnDemand table concept. I have put
> the notes up on the wiki at:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=247828052.
> One thing that came out of that is that we may want to revert the change in
> the new bulk import code that allows a user to import into an offline
> table. The feature allows a user to create a table that is initially
> offline, bulk import data into it, then bring it online. However, when not
> used in this manner the number of bulk import files would continue to grow
> because compactions are never run on the table.
>
> On Mon, Mar 20, 2023 at 9:37 AM Dave Marion  wrote:
>
> > Following up on this. Discussion and design documents are up on the
> > wiki[1]. There is a GitHub project[2] for planning out some of the tasks,
> > which are then turned into issues. Some of the issues have draft PRs
> > submitted for them.
> >
> > [1] https://cwiki.apache.org/confluence/display/ACCUMULO/Elasticity
> > [2] https://github.com/orgs/apache/projects/164
> >
> > On Wed, Feb 22, 2023 at 2:35 PM Dave Marion  wrote:
> >
> >> Except for the new bulk import code, Accumulo requires that tables are in
> >> an online state to work with them (ingest, scan, compact, split, etc.). In
> >> some cases this could become cost prohibitive and resource inefficient as
> >> resources necessary to keep the tables online might be unused. I'd like to
> >> propose a new capability for Accumulo - the ability to work with tables
> >> that are not online. This could either mean working with tables in an
> >> offline state, or maybe the ability to assign/host tables/tablets on
> >> demand.
> >>
> >> At a high level the two ideas currently being discussed are below. I
> >> think in both cases the root and metadata tables must be online, table
> >> management functions move to manager components, and compactions of offline
> >> tables move to the external compaction processes. In addition, new metrics
> >> would need to be emitted so that an external resource scheduler could spin
> >> up/down server processes as demand changes.
> >>
> >>
> >> *Offline Operations*
> >>
> >> This approach allows all operations to occur on offline tables at the
> >> cost of having eventual consistency to the data at scan time (via Scan
> >> Servers only). Live ingest could be supported through the creation of an
> >> ingest server component that just receives mutations and minor compacts.
> >>
> >>
> >>
> >> *On-demand Tables*
> >> This approach allows for user tables to be offline and un-hosted, but
> >> hosts them on demand for the purpose of live ingest and immediate scans at
> >> the latency cost of possibly assigning and hosting the tablet.
> >>
> >> We have a few releases (1.10.3, 2.1.1, and 3.0.0) coming up in likely the
> >> next month or two, but after that I'd like to start implementing something
> >> to address this. Please contribute to the discussion if you have thoughts
> >> on requirements, design, etc.
> >>
> >>
> >>
> >>

Re: [DISCUSS] Enable Github wiki in asf.yaml?

[Christopher]

Those aren't differences (either not a difference at all, or not a
meaningful one).

1. Immediate availability. GitHub already renders the content
immediately... this is why we can view Markdown files like README and
other file types directly in the repo navigation. The non-immediate
view on the website is a secondary view... but even that takes mere
seconds to build and render.

2. Not publishing draft/WIP design documents on the website: whether
we have the rendered files accessible at
confluence.apache.org/accumulo/designs or accumulo.apache.org/designs,
we're still publishing to the exact same extent. The files are being
made publicly available to developers / potential contributors, but
not promoted to users in draft form. It's the same thing. Presumably,
in our developer docs, we would link to the confluence/GitHub wiki so
other devs can find it. This is the same as linking to our
accumulo-website repo or to the /designs folder on our website. The
only difference that matters for publication is whether we make it
available to developers or if we promote it to users. But, linking to
one site for developers vs. another site for developers is not a
difference in any way that is meaningful.

Again, I will point to an existing precedent for precisely the same
thing (working document for a feature design) at
https://github.com/apache/accumulo-website/blob/main/design/system-snapshot.md
; This was added using a PR
https://github.com/apache/accumulo-website/pull/163 with
comments/discussion that triggered notifications to our mailing lists
for participation opportunity, was rendered in Markdown immediately,
and ultimately got merged to a folder that does not have a link
anywhere on the website, so we don't promote it in draft form to
users. The workflow followed for that hits *all* of the stated
requirements, is an existing precedent, was quite convenient, *and*
has the added benefit of being consolidated in the same repo as other
docs. It also is mirrored to ASF's gitbox and would have notifications
triggered to the mailing list for any non-GitHub users, so it doesn't
require any separate accounts like Confluence or GitHub to
participate. It also matches our existing collaboration workflow,
which I think is important for a small project like ours, so we don't
spread ourselves too thin.

As for the downsides of putting the Wiki in a subfolder in the project:
1. The .asf.yaml doesn't seem to support configuring it to be based on
a subfolder, so this would require getting INFRA involved for
changes... which I'd rather not do. I'd rather do things that are
self-serve as much as possible. I did briefly look into this, and I
also can't find GitHub documentation for how to put a wiki in a
subfolder. I found the docs for putting the GitHub Pages website in a
subfolder, but that's different, and not what anybody has proposed.
2. It would have to be put in a separate repo, rather than the main
accumulo repo, because putting it in the main repo would mean we'd
have to work around it for the build environment (it would also
undermine the whole effort to strip the docs/ directory out of the
main repo). If we put it in an existing repo, then the best candidate
would be the accumulo-website repo anyway, and we'd have to either
ignore that directory during the website build, or it would end up on
the website anyway... which is what I proposed, but with the extra
complexity of having a separate wiki feature tied to it.

I'm not saying the website repo as I've proposed is a 100% perfect
solution... but I think of all the options, it's the best for the
project long term. I don't think we need a specialty product or
tailored platform to get what we want. I know people have their own
preferences... but on the technical merits, I still think this is the
best option.


On Thu, Mar 16, 2023 at 8:23 AM Dave Marion  wrote:
>
> This was just something I found to answer the issue of notifications,
> issues, and PRs. I think the main difference is that it's immediately
> available on the GitHub site for viewing vs having to wait for it to be
> published to the website and that we're not publishing draft or WIP design
> documents to the website. I still think that Confluence is a better option
> regarding comments and discussion, hopefully infra can figure that out.
>
> On Thu, Mar 16, 2023 at 7:51 AM Christopher  wrote:
>
> > Isn't that basically the same as how the website repo works? How would
> > that be different then?
> >
> > On Wed, Mar 15, 2023 at 2:55 PM Dave Marion  wrote:
> > >
> > > It looks like we could generate the GH wiki from a folder in the source
> > > code. This would allow for issues and PRs. Just a thought.
> > >
> > > Ref: https://nimblehq.co/blog/create-github-wiki-pull-request and
> > >
> > https://stackoverflow.com/questions/10642928/how-can-i-make-a-pull-request-for-a-wiki-page-on-github
> &

Re: [DISCUSS] Enable Github wiki in asf.yaml?

[Christopher]

Isn't that basically the same as how the website repo works? How would
that be different then?

On Wed, Mar 15, 2023 at 2:55 PM Dave Marion  wrote:
>
> It looks like we could generate the GH wiki from a folder in the source
> code. This would allow for issues and PRs. Just a thought.
>
> Ref: https://nimblehq.co/blog/create-github-wiki-pull-request and
> https://stackoverflow.com/questions/10642928/how-can-i-make-a-pull-request-for-a-wiki-page-on-github
>
> On Wed, Mar 15, 2023 at 2:16 PM Christopher  wrote:
>
> > It seems like there's a majority consensus of those engaged. No need for a
> > vote, but I think the question about notifications should be addressed
> > first.
> >
> > On Wed, Mar 15, 2023, 13:47 Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > > I'm +1 to using some kind of wiki so if we can't use Confluence then GH
> > > sounds fine to me. Do we need to take a formal vote for using the Github
> > > wiki or is there enough consensus already?
> > >
> > > On Wed, Mar 15, 2023 at 1:43 PM Daniel Roberts 
> > wrote:
> > >
> > > > +1 for the GH wiki with major discussions still being fed into, or
> > > > originated on the mailing lists.
> > > >
> > > > As a side question, if there is a lengthy discussion on a GH issue, is
> > it
> > > > standard practice to just recap that in a mailing list message?
> > > > Or is there a more "formal" inclusion process to follow?
> > > >
> > > >
> > > > On Wed, Mar 15, 2023 at 1:39 PM Christopher 
> > wrote:
> > > >
> > > > > I don't think the workflow I proposed about using PRs and discussion
> > on
> > > > > tickets, etc. and the accompanying arguments about keeping things
> > > > > consolidated and accessible to potential contributors not
> > participating
> > > > on
> > > > > GitHub, were really challenged at all. However, since I seem to be
> > the
> > > > only
> > > > > one advocating for using the website, to keep things centralized, as
> > > per
> > > > > previous attempts to consolidate documentation, I won't fight the use
> > > of
> > > > > GitHub wiki. But I do want to make it clear that we're proceeding in
> > > that
> > > > > direction under my objection (-0), and that I'm not convinced this is
> > > the
> > > > > best path forward. Hopefully, I will be proven wrong in time.
> > > > >
> > > > > On Wed, Mar 15, 2023, 11:58 Dave Marion  wrote:
> > > > >
> > > > > > > At this point, I think we should move forward with a GH wiki and
> > > then
> > > > > we
> > > > > > can re-evaluate things once the Apache confluence issue is sorted
> > > out.
> > > > > >
> > > > > > Agreed.
> > > > > >
> > > > > > On Wed, Mar 15, 2023 at 11:57 AM dev1  wrote:
> > > > > >
> > > > > > > I just tried (Wed, 3/15) and still received the same error.  I
> > > asked
> > > > on
> > > > > > > the infra slack channel and they replied that they are still
> > > working
> > > > to
> > > > > > > determine what the issue is - signs are pointing to something
> > > inside
> > > > of
> > > > > > > confluence, but no progress.
> > > > > > >
> > > > > > > At this point, I think we should move forward with a GH wiki and
> > > then
> > > > > we
> > > > > > > can re-evaluate things once the Apache confluence issue is sorted
> > > > out.
> > > > > > >
> > > > > > > Ed Coleman
> > > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Dave Marion 
> > > > > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > > > > To: dev@accumulo.apache.org
> > > > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > > >
> > > > > > > Looking at the Infra slack channel response, one of the responses
> > > in
> > > > > the
> > > > > > > channel said that "it's some sort of db corruption according to
> > > > > > Atlassian".
> > > > >

Re: [DISCUSS] Enable Github wiki in asf.yaml?

[Christopher]

It seems like there's a majority consensus of those engaged. No need for a
vote, but I think the question about notifications should be addressed
first.

On Wed, Mar 15, 2023, 13:47 Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> I'm +1 to using some kind of wiki so if we can't use Confluence then GH
> sounds fine to me. Do we need to take a formal vote for using the Github
> wiki or is there enough consensus already?
>
> On Wed, Mar 15, 2023 at 1:43 PM Daniel Roberts  wrote:
>
> > +1 for the GH wiki with major discussions still being fed into, or
> > originated on the mailing lists.
> >
> > As a side question, if there is a lengthy discussion on a GH issue, is it
> > standard practice to just recap that in a mailing list message?
> > Or is there a more "formal" inclusion process to follow?
> >
> >
> > On Wed, Mar 15, 2023 at 1:39 PM Christopher  wrote:
> >
> > > I don't think the workflow I proposed about using PRs and discussion on
> > > tickets, etc. and the accompanying arguments about keeping things
> > > consolidated and accessible to potential contributors not participating
> > on
> > > GitHub, were really challenged at all. However, since I seem to be the
> > only
> > > one advocating for using the website, to keep things centralized, as
> per
> > > previous attempts to consolidate documentation, I won't fight the use
> of
> > > GitHub wiki. But I do want to make it clear that we're proceeding in
> that
> > > direction under my objection (-0), and that I'm not convinced this is
> the
> > > best path forward. Hopefully, I will be proven wrong in time.
> > >
> > > On Wed, Mar 15, 2023, 11:58 Dave Marion  wrote:
> > >
> > > > > At this point, I think we should move forward with a GH wiki and
> then
> > > we
> > > > can re-evaluate things once the Apache confluence issue is sorted
> out.
> > > >
> > > > Agreed.
> > > >
> > > > On Wed, Mar 15, 2023 at 11:57 AM dev1  wrote:
> > > >
> > > > > I just tried (Wed, 3/15) and still received the same error.  I
> asked
> > on
> > > > > the infra slack channel and they replied that they are still
> working
> > to
> > > > > determine what the issue is - signs are pointing to something
> inside
> > of
> > > > > confluence, but no progress.
> > > > >
> > > > > At this point, I think we should move forward with a GH wiki and
> then
> > > we
> > > > > can re-evaluate things once the Apache confluence issue is sorted
> > out.
> > > > >
> > > > > Ed Coleman
> > > > >
> > > > > -Original Message-
> > > > > From: Dave Marion 
> > > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > > To: dev@accumulo.apache.org
> > > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > >
> > > > > Looking at the Infra slack channel response, one of the responses
> in
> > > the
> > > > > channel said that "it's some sort of db corruption according to
> > > > Atlassian".
> > > > > Doesn't sound good
> > > > >
> > > > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion 
> > > wrote:
> > > > >
> > > > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> > > unresolved
> > > > > > and the only comment on the ticket is one that Ed added two days
> > ago
> > > > > > requesting an ACCUMULO wiki space.
> > > > > >
> > > > > > On Fri, Mar 3, 2023 at 12:26 PM dev1  wrote:
> > > > > >
> > > > > >> I do not see any comments in the infa slack channel - so no
> > updates
> > > > > >> for now.
> > > > > >>
> > > > > >> -Original Message-
> > > > > >> From: Dave Marion 
> > > > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > > > >> To: dev@accumulo.apache.org
> > > > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > > >>
> > > > > >> Right, I was just curious if there was any follow-up as I think
> Ed
> > > > > >> said that it was going to be discussed by the INFRA team
> > yesterday.
> > > > > >> There is a

Re: [DISCUSS] Enable Github wiki in asf.yaml?

[Christopher]

All discussions in GitHub issues go to the notifications list so people can
follow. We don't usually need to recap, but if somebody wanted to, they
could reply to the dev list in response to a message sent to notifications.

The wiki doesn't have issues, discussions, or l etc., and I don't know what
kind of notifications it has to help others follow it. It seems like it'd
be important to ensure there are notifications of activity to the
notifications list for that.


On Wed, Mar 15, 2023, 13:43 Daniel Roberts  wrote:

> +1 for the GH wiki with major discussions still being fed into, or
> originated on the mailing lists.
>
> As a side question, if there is a lengthy discussion on a GH issue, is it
> standard practice to just recap that in a mailing list message?
> Or is there a more "formal" inclusion process to follow?
>
>
> On Wed, Mar 15, 2023 at 1:39 PM Christopher  wrote:
>
> > I don't think the workflow I proposed about using PRs and discussion on
> > tickets, etc. and the accompanying arguments about keeping things
> > consolidated and accessible to potential contributors not participating
> on
> > GitHub, were really challenged at all. However, since I seem to be the
> only
> > one advocating for using the website, to keep things centralized, as per
> > previous attempts to consolidate documentation, I won't fight the use of
> > GitHub wiki. But I do want to make it clear that we're proceeding in that
> > direction under my objection (-0), and that I'm not convinced this is the
> > best path forward. Hopefully, I will be proven wrong in time.
> >
> > On Wed, Mar 15, 2023, 11:58 Dave Marion  wrote:
> >
> > > > At this point, I think we should move forward with a GH wiki and then
> > we
> > > can re-evaluate things once the Apache confluence issue is sorted out.
> > >
> > > Agreed.
> > >
> > > On Wed, Mar 15, 2023 at 11:57 AM dev1  wrote:
> > >
> > > > I just tried (Wed, 3/15) and still received the same error.  I asked
> on
> > > > the infra slack channel and they replied that they are still working
> to
> > > > determine what the issue is - signs are pointing to something inside
> of
> > > > confluence, but no progress.
> > > >
> > > > At this point, I think we should move forward with a GH wiki and then
> > we
> > > > can re-evaluate things once the Apache confluence issue is sorted
> out.
> > > >
> > > > Ed Coleman
> > > >
> > > > -Original Message-
> > > > From: Dave Marion 
> > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > To: dev@accumulo.apache.org
> > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > >
> > > > Looking at the Infra slack channel response, one of the responses in
> > the
> > > > channel said that "it's some sort of db corruption according to
> > > Atlassian".
> > > > Doesn't sound good
> > > >
> > > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion 
> > wrote:
> > > >
> > > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> > unresolved
> > > > > and the only comment on the ticket is one that Ed added two days
> ago
> > > > > requesting an ACCUMULO wiki space.
> > > > >
> > > > > On Fri, Mar 3, 2023 at 12:26 PM dev1  wrote:
> > > > >
> > > > >> I do not see any comments in the infa slack channel - so no
> updates
> > > > >> for now.
> > > > >>
> > > > >> -Original Message-
> > > > >> From: Dave Marion 
> > > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > > >> To: dev@accumulo.apache.org
> > > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > >>
> > > > >> Right, I was just curious if there was any follow-up as I think Ed
> > > > >> said that it was going to be discussed by the INFRA team
> yesterday.
> > > > >> There is at least one other recent ticket (
> > > > >> https://issues.apache.org/jira/browse/INFRA-24216) where
> selfserve
> > > > >> had an issue and the INFRA team created the space manually.
> > > > >>
> > > > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher 
> > > > wrote:
> > > > >>
> > > > >> > You can track that issue at
> > > > >> > htt

Re: [DISCUSS] Enable Github wiki in asf.yaml?

[Christopher Shannon]

I'm +1 to using some kind of wiki so if we can't use Confluence then GH
sounds fine to me. Do we need to take a formal vote for using the Github
wiki or is there enough consensus already?

On Wed, Mar 15, 2023 at 1:43 PM Daniel Roberts  wrote:

> +1 for the GH wiki with major discussions still being fed into, or
> originated on the mailing lists.
>
> As a side question, if there is a lengthy discussion on a GH issue, is it
> standard practice to just recap that in a mailing list message?
> Or is there a more "formal" inclusion process to follow?
>
>
> On Wed, Mar 15, 2023 at 1:39 PM Christopher  wrote:
>
> > I don't think the workflow I proposed about using PRs and discussion on
> > tickets, etc. and the accompanying arguments about keeping things
> > consolidated and accessible to potential contributors not participating
> on
> > GitHub, were really challenged at all. However, since I seem to be the
> only
> > one advocating for using the website, to keep things centralized, as per
> > previous attempts to consolidate documentation, I won't fight the use of
> > GitHub wiki. But I do want to make it clear that we're proceeding in that
> > direction under my objection (-0), and that I'm not convinced this is the
> > best path forward. Hopefully, I will be proven wrong in time.
> >
> > On Wed, Mar 15, 2023, 11:58 Dave Marion  wrote:
> >
> > > > At this point, I think we should move forward with a GH wiki and then
> > we
> > > can re-evaluate things once the Apache confluence issue is sorted out.
> > >
> > > Agreed.
> > >
> > > On Wed, Mar 15, 2023 at 11:57 AM dev1  wrote:
> > >
> > > > I just tried (Wed, 3/15) and still received the same error.  I asked
> on
> > > > the infra slack channel and they replied that they are still working
> to
> > > > determine what the issue is - signs are pointing to something inside
> of
> > > > confluence, but no progress.
> > > >
> > > > At this point, I think we should move forward with a GH wiki and then
> > we
> > > > can re-evaluate things once the Apache confluence issue is sorted
> out.
> > > >
> > > > Ed Coleman
> > > >
> > > > -Original Message-
> > > > From: Dave Marion 
> > > > Sent: Wednesday, March 8, 2023 11:09 AM
> > > > To: dev@accumulo.apache.org
> > > > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > >
> > > > Looking at the Infra slack channel response, one of the responses in
> > the
> > > > channel said that "it's some sort of db corruption according to
> > > Atlassian".
> > > > Doesn't sound good
> > > >
> > > > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion 
> > wrote:
> > > >
> > > > > https://issues.apache.org/jira/browse/INFRA-24291 is still
> > unresolved
> > > > > and the only comment on the ticket is one that Ed added two days
> ago
> > > > > requesting an ACCUMULO wiki space.
> > > > >
> > > > > On Fri, Mar 3, 2023 at 12:26 PM dev1  wrote:
> > > > >
> > > > >> I do not see any comments in the infa slack channel - so no
> updates
> > > > >> for now.
> > > > >>
> > > > >> -Original Message-
> > > > >> From: Dave Marion 
> > > > >> Sent: Friday, March 3, 2023 12:06 PM
> > > > >> To: dev@accumulo.apache.org
> > > > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > > > >>
> > > > >> Right, I was just curious if there was any follow-up as I think Ed
> > > > >> said that it was going to be discussed by the INFRA team
> yesterday.
> > > > >> There is at least one other recent ticket (
> > > > >> https://issues.apache.org/jira/browse/INFRA-24216) where
> selfserve
> > > > >> had an issue and the INFRA team created the space manually.
> > > > >>
> > > > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher 
> > > > wrote:
> > > > >>
> > > > >> > You can track that issue at
> > > > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > > > >> >
> > > > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion <
> dmario...@gmail.com>
> > > > >> wrote:
> > > > >> &

Re: [DISCUSS] Enable Github wiki in asf.yaml?

[Christopher]

I don't think the workflow I proposed about using PRs and discussion on
tickets, etc. and the accompanying arguments about keeping things
consolidated and accessible to potential contributors not participating on
GitHub, were really challenged at all. However, since I seem to be the only
one advocating for using the website, to keep things centralized, as per
previous attempts to consolidate documentation, I won't fight the use of
GitHub wiki. But I do want to make it clear that we're proceeding in that
direction under my objection (-0), and that I'm not convinced this is the
best path forward. Hopefully, I will be proven wrong in time.

On Wed, Mar 15, 2023, 11:58 Dave Marion  wrote:

> > At this point, I think we should move forward with a GH wiki and then we
> can re-evaluate things once the Apache confluence issue is sorted out.
>
> Agreed.
>
> On Wed, Mar 15, 2023 at 11:57 AM dev1  wrote:
>
> > I just tried (Wed, 3/15) and still received the same error.  I asked on
> > the infra slack channel and they replied that they are still working to
> > determine what the issue is - signs are pointing to something inside of
> > confluence, but no progress.
> >
> > At this point, I think we should move forward with a GH wiki and then we
> > can re-evaluate things once the Apache confluence issue is sorted out.
> >
> > Ed Coleman
> >
> > -Original Message-
> > From: Dave Marion 
> > Sent: Wednesday, March 8, 2023 11:09 AM
> > To: dev@accumulo.apache.org
> > Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> >
> > Looking at the Infra slack channel response, one of the responses in the
> > channel said that "it's some sort of db corruption according to
> Atlassian".
> > Doesn't sound good
> >
> > On Wed, Mar 8, 2023 at 10:55 AM Dave Marion  wrote:
> >
> > > https://issues.apache.org/jira/browse/INFRA-24291 is still unresolved
> > > and the only comment on the ticket is one that Ed added two days ago
> > > requesting an ACCUMULO wiki space.
> > >
> > > On Fri, Mar 3, 2023 at 12:26 PM dev1  wrote:
> > >
> > >> I do not see any comments in the infa slack channel - so no updates
> > >> for now.
> > >>
> > >> -Original Message-
> > >> From: Dave Marion 
> > >> Sent: Friday, March 3, 2023 12:06 PM
> > >> To: dev@accumulo.apache.org
> > >> Subject: Re: [DISCUSS] Enable Github wiki in asf.yaml?
> > >>
> > >> Right, I was just curious if there was any follow-up as I think Ed
> > >> said that it was going to be discussed by the INFRA team yesterday.
> > >> There is at least one other recent ticket (
> > >> https://issues.apache.org/jira/browse/INFRA-24216) where selfserve
> > >> had an issue and the INFRA team created the space manually.
> > >>
> > >> On Fri, Mar 3, 2023 at 11:57 AM Christopher 
> > wrote:
> > >>
> > >> > You can track that issue at
> > >> > https://issues.apache.org/jira/browse/INFRA-24291
> > >> >
> > >> > On Fri, Mar 3, 2023 at 10:31 AM Dave Marion 
> > >> wrote:
> > >> > >
> > >> > > Ed,
> > >> > >
> > >> > >   Any update from INFRA on being able to create confluence pages?
> > >> > >
> > >> > > On Thu, Mar 2, 2023 at 4:07 PM Christopher 
> > >> wrote:
> > >> > >
> > >> > > > We've definitely used the website for more than that. We use it
> > >> > > > to document things for users, help developers know how to
> > >> > > > contribute, store drafts of designs, share user stories via
> > >> > > > blogs, do release announcements, and more. There's definitely
> > >> > > > space on the website to do this kind of thing, if we want to.
> > >> > > > We've used it that way before. If you only see it as a place
> > >> > > > "for user consumption after everything has been finalized",
> > >> > > > then you're missing out on the other ways we currently use the
> > >> > > > site, and the ways we've used it in
> > >> the past.
> > >> > > >
> > >> > > > With the website, most of the collaboration would happen in the
> > >> > > > GH issues about proposed designs or changes to designs, just
> > >> > > > like we do today with code or other documentation, which
> > >&

Re: [DISCUSS] Enable Github wiki in asf.yaml?

[Christopher]

You can track that issue at https://issues.apache.org/jira/browse/INFRA-24291

On Fri, Mar 3, 2023 at 10:31 AM Dave Marion  wrote:
>
> Ed,
>
>   Any update from INFRA on being able to create confluence pages?
>
> On Thu, Mar 2, 2023 at 4:07 PM Christopher  wrote:
>
> > We've definitely used the website for more than that. We use it to
> > document things for users, help developers know how to contribute,
> > store drafts of designs, share user stories via blogs, do release
> > announcements, and more. There's definitely space on the website to do
> > this kind of thing, if we want to. We've used it that way before. If
> > you only see it as a place "for user consumption after everything has
> > been finalized", then you're missing out on the other ways we
> > currently use the site, and the ways we've used it in the past.
> >
> > With the website, most of the collaboration would happen in the GH
> > issues about proposed designs or changes to designs, just like we do
> > today with code or other documentation, which everybody is used to. I
> > agree it's not as good as Google Docs for on-the-fly
> > comments/annotations, but I don't think Confluence or Wiki are as good
> > as that either, and Google Docs isn't really an option... unless you
> > just want to link to it in the mailing list and stick to Google Docs
> > from your personal Google account, until it's ready for publication,
> > which would also be fine (any interested persons can simply request
> > write access by replying to the message where you shared the link)..
> >
> > We are a much smaller project than many others, and we have previously
> > suffered from having stuff too spread out. Even if other projects find
> > a separate space valuable for them, I'm not sure it's best for the
> > Accumulo project. While I think it's useful to examine what other
> > projects do, I do think we should be careful to adopt anything just
> > because others find it convenient for them.
> >
> > Confluence is my second choice, but with a big gap between it and my
> > first choice.
> >
> > On a personal note: I hate using Confluence, because I think the
> > navigation is highly unintuitive, as is the permissions model, and I
> > don't like the idea of learning yet another wiki-syntax (though I've
> > read Confluence supports some limited Markdown, but probably not the
> > same as GitHub/Jekyll). I also do not want to set up custom
> > notifications for watching yet another space. If we use Confluence, I
> > will probably contribute very infrequently there because of my
> > frustrations with having used it before. However, that would be my
> > choice, and should not be a reason the project chooses one over
> > another. I'm sharing my personal opinion only because it is
> > influencing my opinion about the website being more accessible, via
> > our current GitHub PR/issue/Markdown workflows, and I wonder how many
> > other potential contributors would feel similarly. It's hard to know,
> > since it seems like a lot of this is subjective, and is going to come
> > down to a consensus of personal preferences.
> >
> > On Thu, Mar 2, 2023 at 3:46 PM Dave Marion  wrote:
> > >
> > > I don't see the website as an area where we would have collaborative
> > > discussions about an idea. For example, making comments and suggestions
> > on
> > > a document like you can do in Google Docs. I see the website as a place
> > > where items are documented for user consumption after everything has been
> > > finalized. I'm not trying to create a private discussion area, I think
> > > anyone can see the wiki (but I think anonymous comments are disabled due
> > to
> > > spam issues). I see no issue with putting work-in-progress documents on a
> > > wiki and referencing them via emails to the dev list. I think this is
> > done
> > > in a lot of other projects. Non-committers that don't have access to the
> > > wiki and want to make comments, suggestions, and ask questions can do so
> > > via the mailing list. I think it's also possible that people can get
> > > confluence accounts (see
> > https://issues.apache.org/jira/browse/INFRA-7058),
> > > so if a non-committer wanted to participate they could.
> > >
> > > On Thu, Mar 2, 2023 at 2:53 PM Christopher  wrote:
> > >
> > > > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion 
> > wrote:
> > > > >
> > > > > I'm opposed to using the website for the reasons I specified
> > earlier, so
> > > > it
> 

Re: [DISCUSS] Enable Github wiki in asf.yaml?

[Christopher]

We've definitely used the website for more than that. We use it to
document things for users, help developers know how to contribute,
store drafts of designs, share user stories via blogs, do release
announcements, and more. There's definitely space on the website to do
this kind of thing, if we want to. We've used it that way before. If
you only see it as a place "for user consumption after everything has
been finalized", then you're missing out on the other ways we
currently use the site, and the ways we've used it in the past.

With the website, most of the collaboration would happen in the GH
issues about proposed designs or changes to designs, just like we do
today with code or other documentation, which everybody is used to. I
agree it's not as good as Google Docs for on-the-fly
comments/annotations, but I don't think Confluence or Wiki are as good
as that either, and Google Docs isn't really an option... unless you
just want to link to it in the mailing list and stick to Google Docs
from your personal Google account, until it's ready for publication,
which would also be fine (any interested persons can simply request
write access by replying to the message where you shared the link)..

We are a much smaller project than many others, and we have previously
suffered from having stuff too spread out. Even if other projects find
a separate space valuable for them, I'm not sure it's best for the
Accumulo project. While I think it's useful to examine what other
projects do, I do think we should be careful to adopt anything just
because others find it convenient for them.

Confluence is my second choice, but with a big gap between it and my
first choice.

On a personal note: I hate using Confluence, because I think the
navigation is highly unintuitive, as is the permissions model, and I
don't like the idea of learning yet another wiki-syntax (though I've
read Confluence supports some limited Markdown, but probably not the
same as GitHub/Jekyll). I also do not want to set up custom
notifications for watching yet another space. If we use Confluence, I
will probably contribute very infrequently there because of my
frustrations with having used it before. However, that would be my
choice, and should not be a reason the project chooses one over
another. I'm sharing my personal opinion only because it is
influencing my opinion about the website being more accessible, via
our current GitHub PR/issue/Markdown workflows, and I wonder how many
other potential contributors would feel similarly. It's hard to know,
since it seems like a lot of this is subjective, and is going to come
down to a consensus of personal preferences.

On Thu, Mar 2, 2023 at 3:46 PM Dave Marion  wrote:
>
> I don't see the website as an area where we would have collaborative
> discussions about an idea. For example, making comments and suggestions on
> a document like you can do in Google Docs. I see the website as a place
> where items are documented for user consumption after everything has been
> finalized. I'm not trying to create a private discussion area, I think
> anyone can see the wiki (but I think anonymous comments are disabled due to
> spam issues). I see no issue with putting work-in-progress documents on a
> wiki and referencing them via emails to the dev list. I think this is done
> in a lot of other projects. Non-committers that don't have access to the
> wiki and want to make comments, suggestions, and ask questions can do so
> via the mailing list. I think it's also possible that people can get
> confluence accounts (see https://issues.apache.org/jira/browse/INFRA-7058),
> so if a non-committer wanted to participate they could.
>
> On Thu, Mar 2, 2023 at 2:53 PM Christopher  wrote:
>
> > On Thu, Mar 2, 2023 at 1:34 PM Dave Marion  wrote:
> > >
> > > I'm opposed to using the website for the reasons I specified earlier, so
> > it
> >
> > Your reasons that I saw were:
> >
> > > 1. I don't think internal design discussions should go on the project
> > website.
> >
> > That doesn't look to me like a reason. That appears to just be stating
> > the conclusion. Did I miss your reason here?
> >
> > > 2. Changes to the design documents could not be seen by others right
> > away (IIRC changes to the website are built and available at
> > https://accumulo.staged.apache.org/, but human intervention is required
> > to publish it at https://accumulo.apache.org/).
> >
> > What do you mean by "others" here? Do you mean "users", as opposed to
> > "developers/contributors"? The ASF draws a distinction between
> > "developers/contributors" and "users" as it pertains to official
> > releases. Releases are intended to be consumed by users, and
> > pre-release stuff is intended to be 

Re: [DISCUSS] Enable Github wiki in asf.yaml?

[Christopher]

ase.

As for the pre-decision collaboration space we're discussing, I just
want to be careful that we're not creating such a space in an
exclusionary way that allows only existing committers to participate,
that excludes other potential contributors. This is still an
openly-developed project, and we should collaborate in a space that is
not exclusive to existing committers, but open to non-committer
contributors and potential contributors as well. So, while we may want
to keep a line separating dev activity from user consumption (an
important separation that relates to official ASF releases), we should
not be drawing a line between committer-devs as "internal" and
contributor-devs as "external". The website, with its own issue
tracker, the ability to render markdown, do reviews, and
collaboratively edit, seems like the ideal place to me. We've used it
before for the same purpose, and I think we should continue to do so.


>
> On Thu, Mar 2, 2023 at 12:56 PM Christopher  wrote:
>
> > So, I agree a space would be helpful. Although it's old school and
> > inconvenient, the mailing list is the canonical place for discussion.
> > We currently use GitHub issues a lot, but that's copied to a mailing
> > list (as is our old JIRA space), so if people want to participate
> > without a GitHub account, they can still do that. There are certain
> > options that are perhaps less convenient, such as just using the
> > mailing list and our dev SVN space, but still more appropriate than
> > options that would be less ubiquitous for potential participants.
> >
> > I think the ASF Confluence is probably fine, for storing, editing, and
> > collaborating on shared documents, but decisions about those would
> > still need to be done on the mailing list. If I remember correctly, we
> > used to have a Wiki space, prior to it being transferred to
> > Confluence, but it was poorly maintained, so we abandoned it in favor
> > of using the website for docs. I could be mis-remembering, but I think
> > this is the case. It might explain why you can't create a Confluence
> > space.
> >
> > My preference would be to just use the website. I think it's fine to
> > have a dev / design area of the website, and we can discuss on GitHub
> > issues for the accumulo-website repo. That is a bit less convenient
> > than Confluence if it's used heavily, but it's more convenient in the
> > sense that it's more accessible and fits more in line with our current
> > mode of operation. Plus, when a document is final, it's easy to link
> > to from our documentation, without making users jump to another
> > service to view docs.
> >
> > I would be opposed to using GitHub wiki or a new git repo. We have
> > enough repos. Although it seems like they are free, there is still a
> > lot of boilerplate work to maintain them, from managing
> > .github/workflows, .github/CONTRIBUTING.md, etc., to .asf.yaml, to
> > README, to keeping copyright dates updated in the NOTICE file, and
> > more.
> >
> > In summary, my preference:
> >
> > 1. Keep a space in accumulo-website, discuss on GH issues and mailing
> > list (strongly preferred)
> > 2. Confluence, discuss on mailing list (prefer over other options, but
> > not a fan)
> > 3. GitHub wiki, discuss on mailing list (strongly prefer not to use this
> > option)
> > 4. New GitHub repo, discuss on GH issues and mailing list (strongly
> > prefer not to use this option)
> >
> > On Thu, Mar 2, 2023 at 12:30 PM Ed Coleman  wrote:
> > >
> > > Currently, asf cannot create new wiki's because of a Confluence issue (
> > https://issues.apache.org/jira/browse/INFRA-24291) I chatted with infra
> > and in response they created that issue.
> > >
> > > To expand on this discussion, I would like to toss out another
> > alternative to discuss / explore.  What if we used a separate GitHub
> > project, something like  Accumulo-Design, just like accumulo-proxy and
> > accumulo-examples.  As a separate project, it would be available for
> > collaboration for the community, but remain separate from main project and
> > the website to keep current code / documentation / design clearly separate
> > from speculative design discussions.  As a project:
> > >
> > > - document history would be preserved with git commit history.
> > > - document collaboration could be done with normal PR submissions /
> > reviews.
> > > - issues could be used to discuss design aspects, capturing the comment
> > history.
> > >
> > > The biggest downside is that it would be yet another project to follow /
> > tra

Re: [DISCUSS] Enable Github wiki in asf.yaml?

[Christopher]

 them.
> >
> > However, GH wikis lack some features that I feel are important to support 
> > collaborative authoring. For example, the ability to comment and discuss 
> > specific passages in a document is a feature that's present in Cwiki, but 
> > not in GH wikis. I've come appreciate this this in my google docs and 
> > office workflows, so expect that it would be useful for Accumulo design 
> > discussions too.
> >
> >
> >
> >
> >
> >
> > On Sat, Feb 25, 2023 at 2:54 PM Keith Turner  wrote:
> >
> > > I would like to try a wiki for design documents, I think it would be
> > > less cumbersome than the website and we can always link from the
> > > website and issues to the wiki.  I think its ok to give it a try and
> > > abandon it in the future, if abandoned would just need to properly
> > > communicate that.  The content should be archived in Apache
> > > infrastructure, so if GH wiki does not do that then we should not use
> > > it.  If GH wiki is not an option then could try cwiki.
> > >
> > > On Sat, Feb 25, 2023 at 7:55 AM  wrote:
> > > >
> > > > I reverted the change. I didn't think it would be a big deal, but if
> > > > it
> > > requires discussion, then let's discuss it.
> > > >
> > > > I'm looking for a place to host information related to internal
> > > > design
> > > discussions. I envision these to be living documents that will be
> > > updated over time as the design/implementation progresses and that
> > > other committers will be able to comment on and edit. I don't feel
> > > that the website is the correct place for this because:
> > > >
> > > >   1. I don't think internal design discussions should go on the
> > > > project
> > > website.
> > > >   2. Changes to the design documents could not be seen by others
> > > > right
> > > away (IIRC changes to the website are built and available at
> > > https://accumulo.staged.apache.org/, but human intervention is
> > > required to publish it at https://accumulo.apache.org/).
> > > >
> > > > I looked in the INFRA issues and other projects are using the GH
> > > > Wiki
> > > feature and I saw no mention of backing it up or the requirement to do
> > > so (maybe they rely on GitHub backing it up?). It does appear that we
> > > would need an INFRA ticket so that they can modify the GitHub project
> > > settings to lock the GitHub wiki down so that only committers can
> > > modify it. If GitHub Wiki is not acceptable, then I think Apache
> > > Confluence (
> > > https://cwiki.apache.org) might be an acceptable alternative.
> > > >
> > > > -Original Message-
> > > > From: Christopher 
> > > > Sent: Saturday, February 25, 2023 4:41 AM
> > > > To: accumulo-dev 
> > > > Cc: comm...@accumulo.apache.org
> > > > Subject: Re: [accumulo] branch main updated: Enable Github wiki in
> > > asf.yaml
> > > >
> > > > I don't recall a discussion about this change, but I think it goes
> > > against previous efforts to make the website the one canonical
> > > location for our documentation. I don't even think infra is backing up
> > > wiki repos, so there wouldn't even be a record of the wiki contents in
> > > ASF spaces (vs. the main repo, which is backed up to GitBox and the
> > > issue tracker, which CCs the notifications list).
> > > >
> > > > In short, I think this should be reverted and we should not use the
> > > GitHub wiki. If we need to store documents in a version controlled
> > > way, we can store them on the website, or in our project's SVN dev
> > > space. The wiki is just another place people would have to follow if
> > > they want to participate, and I don't think that serves us. Therefore,
> > > I think we shouldn't use it.
> > > >
> > > >
> > > > On Fri, Feb 24, 2023, 15:59  wrote:
> > > >
> > > > > This is an automated email from the ASF dual-hosted git repository.
> > > > >
> > > > > dlmarion pushed a commit to branch main in repository
> > > > > https://gitbox.apache.org/repos/asf/accumulo.git
> > > > >
> > > > >
> > > > > The following commit(s) were added to refs/heads/main by this push:
> > > > >  new ae8a817e7b Enable Github wiki in asf.yaml ae8a817e7b is
> > > > > described below
> > > > >
> > > > > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > > > > Author: Dave Marion 
> > > > > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> > > > >
> > > > > Enable Github wiki in asf.yaml
> > > > > ---
> > > > >  .asf.yaml | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/.asf.yaml b/.asf.yaml index bc2c943e82..08aa357082
> > > > > 100644
> > > > > --- a/.asf.yaml
> > > > > +++ b/.asf.yaml
> > > > > @@ -27,7 +27,7 @@ github:
> > > > >  - big-data
> > > > >  - hacktoberfest
> > > > >features:
> > > > > -wiki: false
> > > > > +wiki: true
> > > > >  issues: true
> > > > >  projects: true
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> >

Re: Libthrift Update

[Christopher]

You would need to upgrade both.

On Sat, Feb 25, 2023, 07:08 Logan Jones  wrote:

> Christopher,
>
> Understood. For an Accumulo upgrade, do I need to upgrade clients and
> servers simultaneously? Or are the 1.10 clients compatible with 2.1
> servers?
>
> -Logan
>
> On Sat, Feb 25, 2023 at 4:48 AM Christopher  wrote:
>
> > Thrift makes a lot of breaking changes between releases. It is not a
> simple
> > operation to bump it. We have already made the change to do it and
> included
> > updates in 2.0 and 2.1. 1.10 is the legacy version that is to remain
> stable
> > until it is EOL in November. If libthrift bugs are a concern to you, I
> > advise upgrading to 2.1. Upgrading to 2.1 is a much easier jump than
> > putting in lots of development hours to bump it in a 1.10 release, which
> > you'd have to upgrade to anyway. If you're going to upgrade anyway, just
> go
> > to 2.1 which already has the updates you want.
> >
> > On Fri, Feb 24, 2023, 15:57 Logan Jones  wrote:
> >
> > > Hello:
> > >
> > > Is there any chance that Accumulo 1.10 could get a libthrift update?
> > There
> > > are several security vulnerabilities with the current version of
> > libthrift
> > > (0.9.3-1), and I wasn't sure if this is something we could actually
> > > accomplish in 1.10.
> > >
> > > - Logan
> > >
> >
>

Re: [DISCUSS] Enable Github wiki in asf.yaml?

[Christopher Shannon]

I am +1 on the idea of using some sort of Wiki (either Github or
Apache confluence cwiki) for design discussions and related docs. A
wiki is so much easier to update information quickly rather than
trying to use SVN or the website repo and when working on design
changes as document updates can happen pretty quickly when
collaborating. It's also super easier to view the edit history, etc.

In terms of the web site, I've always viewed a project's website as
more customer facing than for core project developers. Obviously the
website can host whatever we want but in my opinion I think a website
is best served as a place that gives information about the project,
official documentation, news/updates, contact information, etc. which
is what most projects (not just Apache) do. We can always have a link
on the website for the wiki for development.

If there is a concern about github wiki not being backed up then as
Dave mentioned I think the Apache wiki is  a good alternative. For
example, Kafka hosts all of their design proposals and discussion on
Cwiki: 
https://cwiki.apache.org/confluence/display/kafka/kafka+improvement+proposals
which makes it easier to track history and edit quickly.

On Sat, Feb 25, 2023 at 7:55 AM  wrote:
>
> I reverted the change. I didn't think it would be a big deal, but if it 
> requires discussion, then let's discuss it.
>
> I'm looking for a place to host information related to internal design 
> discussions. I envision these to be living documents that will be updated 
> over time as the design/implementation progresses and that other committers 
> will be able to comment on and edit. I don't feel that the website is the 
> correct place for this because:
>
>   1. I don't think internal design discussions should go on the project 
> website.
>   2. Changes to the design documents could not be seen by others right away 
> (IIRC changes to the website are built and available at 
> https://accumulo.staged.apache.org/, but human intervention is required to 
> publish it at https://accumulo.apache.org/).
>
> I looked in the INFRA issues and other projects are using the GH Wiki feature 
> and I saw no mention of backing it up or the requirement to do so (maybe they 
> rely on GitHub backing it up?). It does appear that we would need an INFRA 
> ticket so that they can modify the GitHub project settings to lock the GitHub 
> wiki down so that only committers can modify it. If GitHub Wiki is not 
> acceptable, then I think Apache Confluence (https://cwiki.apache.org) might 
> be an acceptable alternative.
>
> -Original Message-
> From: Christopher 
> Sent: Saturday, February 25, 2023 4:41 AM
> To: accumulo-dev 
> Cc: comm...@accumulo.apache.org
> Subject: Re: [accumulo] branch main updated: Enable Github wiki in asf.yaml
>
> I don't recall a discussion about this change, but I think it goes against 
> previous efforts to make the website the one canonical location for our 
> documentation. I don't even think infra is backing up wiki repos, so there 
> wouldn't even be a record of the wiki contents in ASF spaces (vs. the main 
> repo, which is backed up to GitBox and the issue tracker, which CCs the 
> notifications list).
>
> In short, I think this should be reverted and we should not use the GitHub 
> wiki. If we need to store documents in a version controlled way, we can store 
> them on the website, or in our project's SVN dev space. The wiki is just 
> another place people would have to follow if they want to participate, and I 
> don't think that serves us. Therefore, I think we shouldn't use it.
>
>
> On Fri, Feb 24, 2023, 15:59  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > dlmarion pushed a commit to branch main in repository
> > https://gitbox.apache.org/repos/asf/accumulo.git
> >
> >
> > The following commit(s) were added to refs/heads/main by this push:
> >  new ae8a817e7b Enable Github wiki in asf.yaml ae8a817e7b is
> > described below
> >
> > commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> > Author: Dave Marion 
> > AuthorDate: Fri Feb 24 15:59:10 2023 -0500
> >
> > Enable Github wiki in asf.yaml
> > ---
> >  .asf.yaml | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/.asf.yaml b/.asf.yaml
> > index bc2c943e82..08aa357082 100644
> > --- a/.asf.yaml
> > +++ b/.asf.yaml
> > @@ -27,7 +27,7 @@ github:
> >  - big-data
> >  - hacktoberfest
> >features:
> > -wiki: false
> > +wiki: true
> >  issues: true
> >  projects: true
> >
> >
> >
>

Re: Libthrift Update

[Christopher]

Thrift makes a lot of breaking changes between releases. It is not a simple
operation to bump it. We have already made the change to do it and included
updates in 2.0 and 2.1. 1.10 is the legacy version that is to remain stable
until it is EOL in November. If libthrift bugs are a concern to you, I
advise upgrading to 2.1. Upgrading to 2.1 is a much easier jump than
putting in lots of development hours to bump it in a 1.10 release, which
you'd have to upgrade to anyway. If you're going to upgrade anyway, just go
to 2.1 which already has the updates you want.

On Fri, Feb 24, 2023, 15:57 Logan Jones  wrote:

> Hello:
>
> Is there any chance that Accumulo 1.10 could get a libthrift update? There
> are several security vulnerabilities with the current version of libthrift
> (0.9.3-1), and I wasn't sure if this is something we could actually
> accomplish in 1.10.
>
> - Logan
>

Re: [accumulo] branch main updated: Enable Github wiki in asf.yaml

[Christopher]

I don't recall a discussion about this change, but I think it goes against
previous efforts to make the website the one canonical location for our
documentation. I don't even think infra is backing up wiki repos, so there
wouldn't even be a record of the wiki contents in ASF spaces (vs. the main
repo, which is backed up to GitBox and the issue tracker, which CCs the
notifications list).

In short, I think this should be reverted and we should not use the GitHub
wiki. If we need to store documents in a version controlled way, we can
store them on the website, or in our project's SVN dev space. The wiki is
just another place people would have to follow if they want to participate,
and I don't think that serves us. Therefore, I think we shouldn't use it.


On Fri, Feb 24, 2023, 15:59  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> dlmarion pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/accumulo.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
>  new ae8a817e7b Enable Github wiki in asf.yaml
> ae8a817e7b is described below
>
> commit ae8a817e7b2af8c64096ed1a4274eaef44c0e677
> Author: Dave Marion 
> AuthorDate: Fri Feb 24 15:59:10 2023 -0500
>
> Enable Github wiki in asf.yaml
> ---
>  .asf.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.asf.yaml b/.asf.yaml
> index bc2c943e82..08aa357082 100644
> --- a/.asf.yaml
> +++ b/.asf.yaml
> @@ -27,7 +27,7 @@ github:
>  - big-data
>  - hacktoberfest
>features:
> -wiki: false
> +wiki: true
>  issues: true
>  projects: true
>
>
>

Re: Deletion / restoration of 2.1 branch.

[Christopher]

In trying to understand what happened, I took a closer look, and added
a comment to that ticket.

Here's what I understand is a rough timeline of what happened:

1. Ed created a PR to merge 2.1 forward into main (believing he was
creating a PR from his fork)
2. Ed reached out to me to ask about how to merge 2.1 forward, since
it's not a frequent enough thing for him to be super familiar with the
process (this may have occurred before item 1, but I didn't respond
before item 1)
3. I saw the main branch was not up-to-date with the latest additions
to 2.1, so I merged 2.1 into main from the command-line, which caused
GitHub to close the PR and suggest deleting the originating branch,
since all commits were merged into main
4. Ed clicked the Delete button, thinking GitHub was offering to
delete a branch in his fork
5. Chris S. restored the 2.1 branch at the commit that was deleted

So, I think GitHub is partially to blame here for making the UI not
very intuitive (it really needs to show the originating branch
location more clearly, and shouldn't offer the delete button for local
maintenance branches... but not sure how it would know). We could add
branch protections, but would rely on GitHub to enforce, and this
would be a hassle to customize our preferences with INFRA, and would
be another hassle when we wanted to clean up old branches later. I'm
not sure that's worth the trouble.

Ultimately, though, I think step 1 isn't necessary. If I hadn't merged
from the command-line, and we merged from the UI instead using our
normal squash, then it would have created a duplicate commit, not
linked to the one in the first branch. This is not what we want. So,
creating the PR for a merge forward isn't necessary. In this case, it
was a conflict-free merge forward from the command-line. Most merges
forward are conflict free or require trivial conflict resolution and
don't need to be re-reviewed. In the case where the merge forward will
be complex with conflicts, I think it might be better to either start
with the main branch, then create a separate PR to backport to the old
branch, or just merge forward using `-s ours` to create a NOOP merge
that merges the history, but doesn't change anything in the main
branch, and then create a new PR to re-apply the changes tailored to
the newer branch. I'd prefer the "backport" method instead of the
"reapply" method, personally, but either would work. In any case, that
only matters for merges forward with complex merge conflict
resolution. For trivial conflict resolution, this isn't necessary at
all.

Anyway, I hope this helps people when merging forward in future. In
general, it's better to do it from the command-line, and not using the
GitHub UI.

Thanks,
Christopher

On Mon, Jan 23, 2023 at 1:48 PM dev1  wrote:
>
> The 2.1 branch on Accumulo GiHub repo was inadvertently deleted (Friday 1/20) 
> and then was restored Sat (1/21).  The activity occurred due to 
> https://github.com/apache/accumulo/pull/3165.  Posting this here in case 
> anyone was impacted and to preserve a record in the archive.
>
> Ed Coleman
>

Re: [DISCUSS] Accumulo quarterly report (due Wednesday 1/18)

[Christopher]

Works for me

On Mon, Jan 16, 2023, 10:29 dev1  wrote:

> The Accumulo community decided to draft the Apache community reports on
> the Accumulo dev list – and this is a draft of the January report for
> review / comments.
>
> I received a notice yesterday that the Accumulo quarterly report is
> overdue and it needs to be submitted before the board meeting on Wednesday
> – not sure how I missed earlier notices that are normally send out.  I
> intended to send this out in a few hours, and I apologize for not getting
> this draft out earlier.
>
> The text below is copied from the reporting tool and may not reflect the
> final formatting of the final report when submitted.
>
> Ed Coleman
>
>  report text 
>
> ## Description:
> The Apache Accumulo is a robust, scalable, 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.
>
> ## Issues:
> There are no new issues requiring board attention.
>
> ## Membership Data:
> Apache Accumulo was founded 2012-03-20 (11 years ago)
> There are currently 41 committers and 41 PMC members in this project.
> The Committer-to-PMC ratio is 1:1.
>
> Community changes, past quarter:
> - No new PMC members. Last addition was Christopher L. Shannon on
> 2022-09-26.
> - No new committers. Last addition was Christopher L. Shannon on
> 2022-09-27.
>
> ## Project Activity:
> Apache Accumulo 2.1 was released on Nov 1, 2022 as a Long-Term Maintenance
> (LTM) release. The release contains numerous features and improvements with
> over 1200 contributions from over 50 contributors. [1]
>
> Work on version 3.0 is in progress [2]. The 3.0 release plan release is to
> provide a quick turn-around release to remove deprecated code that was
> maintained in 2.1, in compliance with semver requirements.  This will
> complete
> the removal of terms that have been identified as being potentially
> offensive.
>
> ## Community Health:
> Overall community health is good and GitHub activity remains consistent.
>
> - Community activity remains healthy and centers on GitHub. The decline in
>   GitHub activity this quarter reflects a return to normal activity after
>   increased activity in the prior quarter due to the 2.1 release. This
>   reporting quarter also includes reduced activity during the US
> Thanksgiving
>   and Christmas holiday periods.
>
> - Accumulo has transitioned from Jira to GitHub issues. The remaining Jira
>   activity reflects closing obsolete issues.
>
> ## Links
> [1] https://accumulo.apache.org/release/accumulo-2.1.0/
> [2] https://github.com/apache/accumulo/projects/11
>
> From: Mark Owens 
> Sent: Thursday, November 17, 2022 8:11 AM
> To: apache/accumulo 
> Cc: Subscribed 
> Subject: Re: [apache/accumulo] Remove deprecated replication (PR #3080)
>
>
> @jmark99 approved this pull request.
>
> I didn't see any issues with the changes. LGTM.
>
> —
> Reply to this email directly, view it on GitHub<
> https://github.com/apache/accumulo/pull/3080#pullrequestreview-1184276899>,
> or unsubscribe<
> https://github.com/notifications/unsubscribe-auth/ABVYUFDQULYCIP6NSVRWBR3WIYVE5ANCNFSM6AASB4KUOQ
> >.
> You are receiving this because you are subscribed to this thread.Message
> ID: mailto:apache
> /accumulo/pull/3080/review/1184276...@github.com>>
>

Re: jdk 17 and accumulo testing

[Christopher]

For reference, here's the PR working on the fix for 2.1.1:
https://github.com/apache/accumulo/pull/3134

On Fri, Dec 30, 2022 at 11:39 AM Christopher Shannon
 wrote:
>
> Version 2.1.1 will be released with bug fixes and this fix (when finished
> and merged) is planned to be included as part of that release. I don't know
> the exact time frame yet though.
>
> On Fri, Dec 30, 2022 at 11:04 AM Vincent Russell 
> wrote:
>
> > Hello,
> >
> > Are there any plans to release an accumulo 2.1 patch to fix this issue?
> >
> > Thanks,
> >
> > On Sat, Dec 17, 2022 at 7:36 PM Vincent Russell  > >
> > wrote:
> >
> > > No worries.  I'm glad I was able to help in some small way.
> > >
> > > Thank you for fixing the issue.
> > >
> > > On Sat, Dec 17, 2022 at 11:49 AM Christopher Shannon <
> > > christopher.l.shan...@gmail.com> wrote:
> > >
> > >> I created https://github.com/apache/accumulo/pull/3134 and that should
> > >> fix
> > >> this issue.
> > >>
> > >> Thanks Vincent for pointing out the issue in TServerUtils, your testing
> > >> made this easy to track down and fix.
> > >>
> > >>
> > >> On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
> > >> christopher.l.shan...@gmail.com> wrote:
> > >>
> > >> > I was able to reproduce the issue by setting the value size for a
> > >> mutation
> > >> > to size 16384001 to make sure it's greater than the default value for
> > >> > Thrift and it fails immediately. I will work on a fix now that we know
> > >> how
> > >> > to reproduce it.
> > >> >
> > >> > On Fri, Dec 16, 2022 at 2:31 PM Christopher 
> > >> wrote:
> > >> >
> > >> >> I don't think it's intentional. This might be the source of the
> > >> problem.
> > >> >>
> > >> >> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
> > >> >>  wrote:
> > >> >> >
> > >> >> > Also in TserverUtils:270, when the TNonblockingServerSocket is
> > >> created
> > >> >> it
> > >> >> > looks like it ends up using the default frame size.  I am not sure
> > if
> > >> >> this
> > >> >> > is intentional or not.
> > >> >> >
> > >> >> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
> > >> >> vincent.russ...@gmail.com>
> > >> >> > wrote:
> > >> >> >
> > >> >> > > Christopher,
> > >> >> > >
> > >> >> > > I am not sure if this issue is related to 3042 or not.
> > >> >> > >
> > >> >> > > On the client side it does look like TConfiguration ends up being
> > >> >> called
> > >> >> > > with the default constructor.  I am not sure if this is
> > intentional
> > >> >> or not.
> > >> >> > >
> > >> >> > > On the server side I see this stack, so it also looks like:
> > >> >> > >
> > >> >> > > at
> > org.apache.thrift.TConfiguration.(TConfiguration.java:36)
> > >> >> > > at
> > >> >>
> > org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> > >> >> > > at
> > >> org.apache.thrift.TConfiguration.(TConfiguration.java:65)
> > >> >> > > at
> > >> >> > >
> > >> >>
> > >>
> > org.apache.thrift.transport.TNonblockingSocket.(TNonblockingSocket.java:74)
> > >> >> > > at
> > >> >> > >
> > >> >>
> > >>
> > org.apache.thrift.transport.TNonblockingSocket.(TNonblockingSocket.java:68)
> > >> >> > > at
> > >> >> > >
> > >> >>
> > >>
> > org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> > >> >> > > at
> > >> >> > >
> > >> >>
> > >>
> > org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> > >> >> > > at
> > >> >> > >
> > >> >>
> &g

Re: jdk 17 and accumulo testing

[Christopher Shannon]

Version 2.1.1 will be released with bug fixes and this fix (when finished
and merged) is planned to be included as part of that release. I don't know
the exact time frame yet though.

On Fri, Dec 30, 2022 at 11:04 AM Vincent Russell 
wrote:

> Hello,
>
> Are there any plans to release an accumulo 2.1 patch to fix this issue?
>
> Thanks,
>
> On Sat, Dec 17, 2022 at 7:36 PM Vincent Russell  >
> wrote:
>
> > No worries.  I'm glad I was able to help in some small way.
> >
> > Thank you for fixing the issue.
> >
> > On Sat, Dec 17, 2022 at 11:49 AM Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> >> I created https://github.com/apache/accumulo/pull/3134 and that should
> >> fix
> >> this issue.
> >>
> >> Thanks Vincent for pointing out the issue in TServerUtils, your testing
> >> made this easy to track down and fix.
> >>
> >>
> >> On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
> >> christopher.l.shan...@gmail.com> wrote:
> >>
> >> > I was able to reproduce the issue by setting the value size for a
> >> mutation
> >> > to size 16384001 to make sure it's greater than the default value for
> >> > Thrift and it fails immediately. I will work on a fix now that we know
> >> how
> >> > to reproduce it.
> >> >
> >> > On Fri, Dec 16, 2022 at 2:31 PM Christopher 
> >> wrote:
> >> >
> >> >> I don't think it's intentional. This might be the source of the
> >> problem.
> >> >>
> >> >> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
> >> >>  wrote:
> >> >> >
> >> >> > Also in TserverUtils:270, when the TNonblockingServerSocket is
> >> created
> >> >> it
> >> >> > looks like it ends up using the default frame size.  I am not sure
> if
> >> >> this
> >> >> > is intentional or not.
> >> >> >
> >> >> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
> >> >> vincent.russ...@gmail.com>
> >> >> > wrote:
> >> >> >
> >> >> > > Christopher,
> >> >> > >
> >> >> > > I am not sure if this issue is related to 3042 or not.
> >> >> > >
> >> >> > > On the client side it does look like TConfiguration ends up being
> >> >> called
> >> >> > > with the default constructor.  I am not sure if this is
> intentional
> >> >> or not.
> >> >> > >
> >> >> > > On the server side I see this stack, so it also looks like:
> >> >> > >
> >> >> > > at
> org.apache.thrift.TConfiguration.(TConfiguration.java:36)
> >> >> > > at
> >> >>
> org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> >> >> > > at
> >> org.apache.thrift.TConfiguration.(TConfiguration.java:65)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.transport.TNonblockingSocket.(TNonblockingSocket.java:74)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.transport.TNonblockingSocket.(TNonblockingSocket.java:68)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> >> >> > >
> >> >> > >
> >> >> > > I see this in the server log so it does look like it should be
> >> usin

Re: jdk 17 and accumulo testing

[Christopher Shannon]

I created https://github.com/apache/accumulo/pull/3134 and that should fix
this issue.

Thanks Vincent for pointing out the issue in TServerUtils, your testing
made this easy to track down and fix.


On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> I was able to reproduce the issue by setting the value size for a mutation
> to size 16384001 to make sure it's greater than the default value for
> Thrift and it fails immediately. I will work on a fix now that we know how
> to reproduce it.
>
> On Fri, Dec 16, 2022 at 2:31 PM Christopher  wrote:
>
>> I don't think it's intentional. This might be the source of the problem.
>>
>> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
>>  wrote:
>> >
>> > Also in TserverUtils:270, when the TNonblockingServerSocket is created
>> it
>> > looks like it ends up using the default frame size.  I am not sure if
>> this
>> > is intentional or not.
>> >
>> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
>> vincent.russ...@gmail.com>
>> > wrote:
>> >
>> > > Christopher,
>> > >
>> > > I am not sure if this issue is related to 3042 or not.
>> > >
>> > > On the client side it does look like TConfiguration ends up being
>> called
>> > > with the default constructor.  I am not sure if this is intentional
>> or not.
>> > >
>> > > On the server side I see this stack, so it also looks like:
>> > >
>> > > at org.apache.thrift.TConfiguration.(TConfiguration.java:36)
>> > > at
>> org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
>> > > at org.apache.thrift.TConfiguration.(TConfiguration.java:65)
>> > > at
>> > >
>> org.apache.thrift.transport.TNonblockingSocket.(TNonblockingSocket.java:74)
>> > > at
>> > >
>> org.apache.thrift.transport.TNonblockingSocket.(TNonblockingSocket.java:68)
>> > > at
>> > >
>> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
>> > > at
>> > >
>> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
>> > > at
>> > >
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
>> > > at
>> > >
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
>> > > at
>> > >
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>> > >
>> > >
>> > > I see this in the server log so it does look like it should be using
>> 1G:
>> > > 2022-09-01 16:59:41 INFO  [org.apache.accumulo.tserver.TabletServer]
>> > > ServerUtil:124 - general.server.message.size.max = 1G
>> > >
>> > > Thanks,
>> > > Vincent
>> > >
>> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
>> > > vincent.russ...@gmail.com> wrote:
>> > >
>> > >>
>> > >>
>> > >> I had to make a stack trace with hacking together a remote debug
>> instance:
>> > >>
>> > >> at
>> > >>
>> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
>> > >> at
>> > >>
>> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
>> > >> at
>> > >>
>> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
>> > >> at
>> > >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
>> > >> at
>> > >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>> > >>
>> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher 
>> wrote:
>> > >>
>> > >>> From the numbers in the message, it looks like you're sending an
>> 18MB
>> > >>> payload but something in Thrift is limiting things to 16384000
>> > >>> (16000KB). I doubt you've overridden the default
>> > >>> general.server.message.size.max to be anything that low (the default
>> > >>> is 1G). Unless you're flu

Re: jdk 17 and accumulo testing

[Christopher Shannon]

I was able to reproduce the issue by setting the value size for a mutation
to size 16384001 to make sure it's greater than the default value for
Thrift and it fails immediately. I will work on a fix now that we know how
to reproduce it.

On Fri, Dec 16, 2022 at 2:31 PM Christopher  wrote:

> I don't think it's intentional. This might be the source of the problem.
>
> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
>  wrote:
> >
> > Also in TserverUtils:270, when the TNonblockingServerSocket is created it
> > looks like it ends up using the default frame size.  I am not sure if
> this
> > is intentional or not.
> >
> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
> vincent.russ...@gmail.com>
> > wrote:
> >
> > > Christopher,
> > >
> > > I am not sure if this issue is related to 3042 or not.
> > >
> > > On the client side it does look like TConfiguration ends up being
> called
> > > with the default constructor.  I am not sure if this is intentional or
> not.
> > >
> > > On the server side I see this stack, so it also looks like:
> > >
> > > at org.apache.thrift.TConfiguration.(TConfiguration.java:36)
> > > at
> org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> > > at org.apache.thrift.TConfiguration.(TConfiguration.java:65)
> > > at
> > >
> org.apache.thrift.transport.TNonblockingSocket.(TNonblockingSocket.java:74)
> > > at
> > >
> org.apache.thrift.transport.TNonblockingSocket.(TNonblockingSocket.java:68)
> > > at
> > >
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> > > at
> > >
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> > > at
> > >
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
> > > at
> > >
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
> > > at
> > >
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> > >
> > >
> > > I see this in the server log so it does look like it should be using
> 1G:
> > > 2022-09-01 16:59:41 INFO  [org.apache.accumulo.tserver.TabletServer]
> > > ServerUtil:124 - general.server.message.size.max = 1G
> > >
> > > Thanks,
> > > Vincent
> > >
> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
> > > vincent.russ...@gmail.com> wrote:
> > >
> > >>
> > >>
> > >> I had to make a stack trace with hacking together a remote debug
> instance:
> > >>
> > >> at
> > >>
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
> > >> at
> > >>
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
> > >> at
> > >>
> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
> > >> at
> > >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
> > >> at
> > >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> > >>
> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher 
> wrote:
> > >>
> > >>> From the numbers in the message, it looks like you're sending an 18MB
> > >>> payload but something in Thrift is limiting things to 16384000
> > >>> (16000KB). I doubt you've overridden the default
> > >>> general.server.message.size.max to be anything that low (the default
> > >>> is 1G). Unless you're flushing after every mutation, it would not be
> > >>> surprising to exceed the 16MB max frame size indicated in the error
> > >>> message quite quickly.
> > >>>
> > >>> This value of 16384000 seemed weird. It looks like it's not using our
> > >>> configuration, but using the built-in default value of
> > >>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It looks
> like
> > >>> this can happen whenever `new TConfiguration()` is called without
> > >>> parameters... and there's a fair amount of internal code, mostly in
> > >>> libthrift itself, that does that. It's a

Re: jdk 17 and accumulo testing

[Christopher]

I don't think it's intentional. This might be the source of the problem.

On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
 wrote:
>
> Also in TserverUtils:270, when the TNonblockingServerSocket is created it
> looks like it ends up using the default frame size.  I am not sure if this
> is intentional or not.
>
> On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell 
> wrote:
>
> > Christopher,
> >
> > I am not sure if this issue is related to 3042 or not.
> >
> > On the client side it does look like TConfiguration ends up being called
> > with the default constructor.  I am not sure if this is intentional or not.
> >
> > On the server side I see this stack, so it also looks like:
> >
> > at org.apache.thrift.TConfiguration.(TConfiguration.java:36)
> > at org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> > at org.apache.thrift.TConfiguration.(TConfiguration.java:65)
> > at
> > org.apache.thrift.transport.TNonblockingSocket.(TNonblockingSocket.java:74)
> > at
> > org.apache.thrift.transport.TNonblockingSocket.(TNonblockingSocket.java:68)
> > at
> > org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> > at
> > org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> > at
> > org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
> > at
> > org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
> > at
> > org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> >
> >
> > I see this in the server log so it does look like it should be using 1G:
> > 2022-09-01 16:59:41 INFO  [org.apache.accumulo.tserver.TabletServer]
> > ServerUtil:124 - general.server.message.size.max = 1G
> >
> > Thanks,
> > Vincent
> >
> > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
> > vincent.russ...@gmail.com> wrote:
> >
> >>
> >>
> >> I had to make a stack trace with hacking together a remote debug instance:
> >>
> >> at
> >> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
> >> at
> >> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
> >> at
> >> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
> >> at
> >> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
> >> at
> >> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> >>
> >> On Thu, Dec 15, 2022 at 12:52 AM Christopher  wrote:
> >>
> >>> From the numbers in the message, it looks like you're sending an 18MB
> >>> payload but something in Thrift is limiting things to 16384000
> >>> (16000KB). I doubt you've overridden the default
> >>> general.server.message.size.max to be anything that low (the default
> >>> is 1G). Unless you're flushing after every mutation, it would not be
> >>> surprising to exceed the 16MB max frame size indicated in the error
> >>> message quite quickly.
> >>>
> >>> This value of 16384000 seemed weird. It looks like it's not using our
> >>> configuration, but using the built-in default value of
> >>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It looks like
> >>> this can happen whenever `new TConfiguration()` is called without
> >>> parameters... and there's a fair amount of internal code, mostly in
> >>> libthrift itself, that does that. It's a bit tricky to track down the
> >>> one causing this particular issue. If you have a full stack trace, it
> >>> could help.
> >>>
> >>> Also, this might be the same issue seen reported in
> >>> https://github.com/apache/accumulo/issues/3042
> >>>
> >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
> >>>  wrote:
> >>> >
> >>> > I was able to work out all of my compilation issues; however when I
> >>> run an
> >>> > integration test with the Mini Accumulo Cluster that tests writing
> >>> > mutations with values of 5mb the flush hangs forever
> >>> > and I see  the following logs in the TabletServer logs:
> >>> >
> >>&

Re: Recommended Permissions

[Christopher]

These could be better documented. It's been awhile since I've thought
about these, but I think:

SystemPermission.SYSTEM - basically permits superuser access to
perform most operations. However, this does not allow automatic access
to tables. A user with this permission, however, can grant themselves
permissions to do so.
SystemPermission.GRANT - this is a special permission that allows the
bearer to grant system permissions to other users. This supports the
case where an admin user is granted system permission, but is not
allowed to share those elevated privileges with other users. At one
point, I think this permission could not be granted... so only the
root user could have this, but I think it can be granted now... but it
must be done so explicitly... either way, the important bit is that it
doesn't come with the SYSTEM permission automatically.
SystemPermission.OBTAIN_DELEGATION_TOKEN - that's a special permission
that allows the user to request delegation tokens, which are
time-limited alternatives to Kerberos credentials when you need to
perform an operation... like MapReduce... across a cluster, and don't
want to (or can't) share your user's authentication credentials. This
is because you probably don't want to share your keytab everywhere, or
run kinit interactively on each MapReduce node in a cluster, in order
to run a MapReduce job. Because these allow impersonation of the
requesting user, they are time-limited, and require explicit
permission to obtain.

For your scenario, the root user is already set up that way. You could
create another user and grant them SYSTEM permissions to do the same.
However, any user you create with SYSTEM permissions will be able to
grant themselves READ and/or WRITE permission on any table they like.
If you need more fine-grained access controls, you could plug in your
own `instance.security.permissionHandler`, but that pluggable
component predates our attempt to create stable SPI endpoints, so it
might not be a stable interface, and you may need to update it for new
releases. Stabilizing that as a proper SPI is a medium term goal of
mine, personally, but I'm not sure when it will happen.

On Thu, Dec 15, 2022 at 1:56 PM Logan Jones  wrote:
>
> Hello:
>
> I'm working on updating our security posture for our various Accumulo
> users. I took a look at the Permissions Page
>  along with the
> Java docs for SystemPermission
> 
> , NamespacePermission
> ,
> and TablePermission
> 
> but
> still have some questions. Specifically, I would like to know what the
> following Permissions are used for:
>
>
>- SystemPermssion.GRANT - My assumption is that this means a user with
>these permissions can grant other users various system permissions.
>Effectively if you have this permission you have the ability to have all
>other system permissions.
>- SystemPermission.SYSTEM
>- SystemPermission.OBTAIN_DELEGATION_TOKEN
>
> Also, I'd be interested in your opinions on what permissions I should set
> up for the following scenario. I would like to create a root user that can
> only manage user/authorizations but cannot read data from any tables, the
> root user would be responsible for creating application users which can do
> everything but create users and alter authorizations. What permissions
> should I set up to make that happen?
>
> Thanks,
>
> - Logan

Re: jdk 17 and accumulo testing

[Christopher]

>From the numbers in the message, it looks like you're sending an 18MB
payload but something in Thrift is limiting things to 16384000
(16000KB). I doubt you've overridden the default
general.server.message.size.max to be anything that low (the default
is 1G). Unless you're flushing after every mutation, it would not be
surprising to exceed the 16MB max frame size indicated in the error
message quite quickly.

This value of 16384000 seemed weird. It looks like it's not using our
configuration, but using the built-in default value of
org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It looks like
this can happen whenever `new TConfiguration()` is called without
parameters... and there's a fair amount of internal code, mostly in
libthrift itself, that does that. It's a bit tricky to track down the
one causing this particular issue. If you have a full stack trace, it
could help.

Also, this might be the same issue seen reported in
https://github.com/apache/accumulo/issues/3042

On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
 wrote:
>
> I was able to work out all of my compilation issues; however when I run an
> integration test with the Mini Accumulo Cluster that tests writing
> mutations with values of 5mb the flush hangs forever
> and I see  the following logs in the TabletServer logs:
>
> 20:41:02.306 [Thread-7] ERROR
> o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size of
> 18874697, which is bigger than the maximum allowable frame size 16384000
> for ALL connections.
> 20:41:03.582 [Thread-7] ERROR
> o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size of
> 18874697, which is bigger than the maximum allowable frame size 16384000
> for ALL connections.
> 20:41:05.079 [Thread-7] ERROR
> o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size of
> 18874697, which is bigger than the maximum allowable frame size 16384000
> for ALL connections.
>
> Other tests that write smaller amounts of data appear to work fine.
>
> Any idea what the issue might be?
>
> Thank you,
> Vincent
>
> On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell 
> wrote:
>
> > Thank you both for your responses.
> >
> > We are using an event store library from a sister project that was written
> > for accumulo 1.10., which I have already upgraded to 2.0.
> >
> > I'll spend some time investigating how bad the usage of the internal
> > packages are and get back to you.
> >
> > Thanks again,
> >
> > On Tue, Dec 13, 2022 at 3:20 PM Christopher  wrote:
> >
> >> To add to Dave's answer, the public API is defined at
> >> https://accumulo.apache.org/api/
> >> Anything else is not public and is subject to change without notice on
> >> any release without any attempt to retain compatibility.
> >>
> >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion  wrote:
> >> >
> >> > There is no guide. You are using implementation classes (see clientImpl
> >> in
> >> > the package name) vs. using the client api. If you can use the client
> >> api
> >> > directly, then this should insulate you from changes in the future
> >> (except
> >> > during major versions). We can try and find where things might have
> >> moved,
> >> > but a class may have been split into multiple pieces. If you could
> >> provide
> >> > class and method, that would be easier.
> >> >
> >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
> >> vincent.russ...@gmail.com>
> >> > wrote:
> >> >
> >> > > Is there a guide that shows where classes may have been moved with
> >> moving
> >> > > from 2.0 to 2.1?  For instance, I am having issues compiling, because
> >> the
> >> > > following class doesn't exist:
> >> > > import org.apache.accumulo.core.clientImpl.Tables;
> >> > >
> >> > > I'm just getting started so I'm sure there are others.
> >> > >
> >> > > Thanks,
> >> > > Vincent
> >> > >
> >> > >
> >> > >
> >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
> >> vincent.russ...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > I mean Christopher.
> >> > > >
> >> > > > Thanks again.
> >> > > >
> >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> >> > > vincent.russ...@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > >

Re: jdk 17 and accumulo testing

[Christopher]

To add to Dave's answer, the public API is defined at
https://accumulo.apache.org/api/
Anything else is not public and is subject to change without notice on
any release without any attempt to retain compatibility.

On Tue, Dec 13, 2022 at 3:10 PM Dave Marion  wrote:
>
> There is no guide. You are using implementation classes (see clientImpl in
> the package name) vs. using the client api. If you can use the client api
> directly, then this should insulate you from changes in the future (except
> during major versions). We can try and find where things might have moved,
> but a class may have been split into multiple pieces. If you could provide
> class and method, that would be easier.
>
> On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell 
> wrote:
>
> > Is there a guide that shows where classes may have been moved with moving
> > from 2.0 to 2.1?  For instance, I am having issues compiling, because the
> > following class doesn't exist:
> > import org.apache.accumulo.core.clientImpl.Tables;
> >
> > I'm just getting started so I'm sure there are others.
> >
> > Thanks,
> > Vincent
> >
> >
> >
> > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell 
> > wrote:
> >
> > > I mean Christopher.
> > >
> > > Thanks again.
> > >
> > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> > vincent.russ...@gmail.com>
> > > wrote:
> > >
> > >> Thank you Chris.
> > >>
> > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or later as soon as
> > >> possible.
> > >>
> > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher  wrote:
> > >>
> > >>> Hi Vincent,
> > >>>
> > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM release, and 2.0 is
> > >>> not expected to receive any further updates. Version 2.1.0 may work
> > >>> with ZooKeeper 3.4, but was developed and tested against 3.5 and later
> > >>> versions. I believe the ZooKeeper community is currently considering
> > >>> whether to make 3.6 end-of-life themselves, so I would recommend using
> > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to have the best
> > >>> chance of any kind of support, including JDK 17 support.
> > >>>
> > >>> As for your specific issues:
> > >>>
> > >>> 1. This is already fixed in 2.1.0
> > >>> 2/3. These issues are likely fixed in newer ZooKeeper versions. I
> > >>> haven't seen them anytime recently, anyway. Bugs in ZooKeeper itself
> > >>> are out of scope for the Accumulo developers, but I have tried
> > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and haven't
> > >>> observed any unresolved issues. However, it's difficult to actually
> > >>> run it because I don't think Hadoop has good JDK 17 support yet. So,
> > >>> MiniAccumuloCluster seems to work with JDK 17, as does Accumulo and ZK
> > >>> 3.8, but I don't think a full Hadoop cluster would (yet).
> > >>>
> > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
> > >>>  wrote:
> > >>> >
> > >>> > Hello,
> > >>> >
> > >>> > We are currently using accumulo 2.0.1.
> > >>> >
> > >>> > We are in the process of upgrading our source code to use jdk 17
> > >>> however we
> > >>> > are running into some problems with our tests and the
> > >>> MiniAccumuloCluster.
> > >>> >
> > >>> > One of our developer encountered the following issues:
> > >>> >
> > >>> >1. The MiniAccumumluoClusterImpl._exec is hardcoded with the JVM
> > arg
> > >>> >-XX:+IUseConcMarkSweepGC, which is no longer tolerated with JDK17.
> > >>> >2. In Zookeeper 3.4.14, ConetStringParser uses createUnresolved to
> > >>> >make IPAddresses.
> > >>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> > >>> >uses InetSocketAddess.getAddress, which returns null because it's
> > >>> not
> > >>> >resolved, resulting in a failure to connect to the newly-started
> > >>> zookeeper.
> > >>> >3. StaticHostProvider.getHostString() tries to extract he hostname
> > >>> by
> > >>> >calling toString on the address and taking everything before the
> > >>> colon, but
> > >>> >in JDK17, the string format changed to
> > "localhost/:xx"
> > >>> (where
> > >>> >XX is still the port number).  That's incorrect and it can't
> > >>> resolve the
> > >>> >names.
> > >>> >
> > >>> >
> > >>> > Has anyone come across/resolved these kinds of issues?  Is it not
> > >>> possible
> > >>> > to use java17 from a client perspective?  Will upgrading to accumulo
> > >>> 2.1
> > >>> > help?
> > >>> >
> > >>> > Thanks,
> > >>> > Vincent
> > >>>
> > >>
> >

Re: jdk 17 and accumulo testing

[Christopher]

Hi Vincent,

Version 2.0.1 is end of life as of the 2.1.0 LTM release, and 2.0 is
not expected to receive any further updates. Version 2.1.0 may work
with ZooKeeper 3.4, but was developed and tested against 3.5 and later
versions. I believe the ZooKeeper community is currently considering
whether to make 3.6 end-of-life themselves, so I would recommend using
Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to have the best
chance of any kind of support, including JDK 17 support.

As for your specific issues:

1. This is already fixed in 2.1.0
2/3. These issues are likely fixed in newer ZooKeeper versions. I
haven't seen them anytime recently, anyway. Bugs in ZooKeeper itself
are out of scope for the Accumulo developers, but I have tried
building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and haven't
observed any unresolved issues. However, it's difficult to actually
run it because I don't think Hadoop has good JDK 17 support yet. So,
MiniAccumuloCluster seems to work with JDK 17, as does Accumulo and ZK
3.8, but I don't think a full Hadoop cluster would (yet).

On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
 wrote:
>
> Hello,
>
> We are currently using accumulo 2.0.1.
>
> We are in the process of upgrading our source code to use jdk 17 however we
> are running into some problems with our tests and the MiniAccumuloCluster.
>
> One of our developer encountered the following issues:
>
>1. The MiniAccumumluoClusterImpl._exec is hardcoded with the JVM arg
>-XX:+IUseConcMarkSweepGC, which is no longer tolerated with JDK17.
>2. In Zookeeper 3.4.14, ConetStringParser uses createUnresolved to
>make IPAddresses.  SaslServerPrincipal.WrapperInetSocketAddress.getAddress
>uses InetSocketAddess.getAddress, which returns null because it's not
>resolved, resulting in a failure to connect to the newly-started zookeeper.
>3. StaticHostProvider.getHostString() tries to extract he hostname by
>calling toString on the address and taking everything before the colon, but
>in JDK17, the string format changed to "localhost/:xx" (where
>XX is still the port number).  That's incorrect and it can't resolve the
>names.
>
>
> Has anyone come across/resolved these kinds of issues?  Is it not possible
> to use java17 from a client perspective?  Will upgrading to accumulo 2.1
> help?
>
> Thanks,
> Vincent