Maybe clarify on the "issues" section that a resolution in sight but
it's not done yet. You imply this in other words, but being clear that
the trademark issue is "acknowledged by the owner and the PMC is waiting
on a fix by that owner" is helpful for someone who is moving through the
report qu
Hadoop provided the CredentialsProviders API as a way to obfuscate
passwords from being stored in plaintext on your filesystem. This is
just done via an JCEKS file located somewhere on the local filesystem
or HDFS.
If I was to take a wag, I'd assume that the trace token
(username/principal and pas
I'm really upset that you think suggesting removal of the feature is
appropriate.
More installations than not of HBase (IMO which should be considered
Accumulo's biggest competitor) use replication. The only users of HBase
I see who without a disaster recovery plan is developer-focused
instan
Seems fine to me.
Any expectations on how upgrades work within an LTS release? How about
across LTS releases?
Some specific situations to mull over:
* Can rolling upgrade in an LTS release (to new patch version) with no
downtime. (e.g. 1.9.1 to 1.9.3)
* Can any LTS release (1.9.1) be guarant
Forking this off because I don't think it's related to Tushar's original
question.
HBase and Accumulo both implementation a WAL which can be said to
relying on a distributed FileSystem which:
1. Is API compatible with HDFS
2. Guarantees that data written prior to an hflush/hsync() is durable
Also, just in case you're feeling this way, any kind of contribution
that you want to put together is helpful, welcome and appreciated.
Please don't feel like you're unable to contribute because you can't get
something "substantial" together. Sometimes it's the smallest or
"silliest" changes t
Yeah, this has been sporadically failing since at least 1.7 days.
On 7/30/19 1:37 PM, Owens, Mark wrote:
Yep, after several continual failures it then started passing.
-Original Message-
From: Adam Lerman
Sent: Tuesday, July 30, 2019 1:26 PM
To: dev@accumulo.apache.org
Subject: Re: rc2
Would be better to add:
```
$ gem install bundler
$ bundler install # should automatically install Jekyll for you
```
Using gem to install Jekyll installs it "globally" instead of local to
your "bundle" (the accumulo website). This increases the likelihood that
you have some version clash of R
(Ensuring it goes out to all lists, thanks Artem)
Also thank you to CCRi! Missed them in the original message as a sponsor.
On 5/24/19 4:24 PM, Josh Elser wrote:
(pardon the cross-post -- please reply-list unless there's a good reason
to cross-post some more)
Hi,
While NoSQL day is fre
(pardon the cross-post -- please reply-list unless there's a good reason
to cross-post some more)
Hi,
While NoSQL day is fresh in my head, I wanted to share some general
information about the event this past Tuesday.
We got started around 9:30 AM in D.C., yours truly welcoming everyone,
fol
Coming back from vacation, I don't see any submissions from the pool of
developer's I'd normally expect to see. I was hoping that since this was
in the "backyard" for most folks that we'd have enough talks to fill a
room for a day.
Abstracts were set to close last Friday, but, best as I can se
Some general comments that I suspect the board will ask on their own. If
you want to proactively address them, it might keep away some
back-and-forth, but it's up to you.
* Any prospects on new C/PMC?
* An acknowledgement that no decisions are being made at the Hack Day
and there will be some
Again, like I included earlier:
> (Append ".sha1", ".md5", or ".asc" to download the signature/hash for
a given artifact.)
On 4/1/19 1:56 PM, Christopher wrote:
In what way?
On Mon, Apr 1, 2019 at 1:54 PM Josh Elser wrote:
Your email template is wrong.
On
Your email template is wrong.
On 4/1/19 1:33 PM, Christopher wrote:
Sorry, I don't understand what you mean by 'retelling of "checksums of old"'.
On Mon, Apr 1, 2019 at 12:30 PM Josh Elser wrote:
I think Mike's point was your VOTE template does not reflect the
I think Mike's point was your VOTE template does not reflect the
retelling of "checksums of old"
> (Append ".sha1", ".md5", or ".asc" to download the signature/hash for
a given artifact.)
On 3/31/19 10:54 PM, Christopher wrote:
Mike,
We already stopped using md5 and sha1 for the release artif
You cannot feasibly hold onto some intermediate batch of nodes in
memory. You're invalidating the general premise of how Accumulo
iterators are meant to work in doing this. Further, an Iterator can
_only_ safely operate within one row of a table. Two adjacent rows may
be located on two differen
Very rarely do JVM GC properties universally apply to all users and
workloads.
I think it would be better to document why these options helped in your
workload. Teach folks how to choose the correct JVM properties for their
workloads is a better way forward, than encouraging folks to treat the
I feel like trying to put the Jenkinsfile in a separate branch might
cause more headache than it's worth.
Happen to stumble on AW's write-up on a similar subject?
https://effectivemachines.com/2019/01/24/using-apache-yetus-with-jenkins-and-github-part-1/
On 2/5/19 2:35 PM, Michael Wall wrote:
Why are you trying to do this in the first place? When you write a new
version of a cell, you are essentially replacing the old value. Leaving
the old value in the table and lazily removing it (via compaction) is a
core optimization to the write-path for Accumulo (from BigTable itself).
I'm ha
YCSB is probably the easiest thing to do workload-specific comparisons.
On 1/16/19 11:19 AM, Mike Miller wrote:
I think we can start doing that now with the alpha release, I am just not
sure how. Did you have any ideas?
On Wed, Jan 16, 2019 at 12:31 AM Sean Busbey
wrote:
Has anyone gotten t
On 1/7/19 11:26 AM, Michael Wall wrote:
Hi Josh, thanks for reviewing.
The "PMC Changes" was copied directly from the reporter.apache.org
template. The "Committer base changes" was in response to feedback from
the board several reports ago asking if all committers were PMC members. I
could s
Thanks for putting a draft together, Mike. A few suggestions:
Please be a little more explicit that Nick was added as a committer. I
had to read it twice before realizing what you meant.
The report seems fine, perhaps a little light on what the project's
current trajectory actually is. Since
Just made one -- I only saw Mike Wall on slack so far (invited him).
On 12/10/18 4:31 PM, Michael Wall wrote:
Yeah, there are some Apache projects that use slack. Can you create an
Accumulo channel at https://the-asf.slack.com? I don't recall what I did
to set up my account there, but I did ha
It seems like commons-vfs2 is just a pile of crap.
It's been known to have bugs for years and we've seen zero progress from
them on making them better.
IMO, rip the whole damn thing out.
On 10/24/18 12:42 PM, Matthew Peterson wrote:
Hello Accumulo,
Summary: commons-vfs2 version 2.2 seems to
On 10/9/18 2:10 PM, Keith Turner wrote:
On Tue, Oct 9, 2018 at 1:52 PM Keith Turner wrote:
On Tue, Oct 9, 2018 at 12:53 PM Josh Elser wrote:
On 10/9/18 12:44 PM, Keith Turner wrote:
On Sat, Oct 6, 2018 at 12:27 AM Christopher wrote:
Hi Accumulo devs,
I'm thinking about initiat
On 10/9/18 12:44 PM, Keith Turner wrote:
On Sat, Oct 6, 2018 at 12:27 AM Christopher wrote:
Hi Accumulo devs,
I'm thinking about initiating a vote next week for a 2.0.0-alpha
release, so we can have an official ASF release (albeit without the
usual stability expectations as a normal releas
oth are similar and start
with S.
On Tue, Oct 9, 2018 at 12:03 PM Josh Elser wrote:
Thanks, Mike.
Didn't RFile summaries show up in 1.9 too? (maybe I'm inventing that)
On 10/9/18 11:39 AM, Mike Miller wrote:
I think once we collect all the changes in 2.0 (there are a lot) we will
rg/blog/2016/11/16/simpler-scripts-and-config.html
Rfile Summaries was a big change but happened a while ago. Recently, the
new Crypto service and new AccumuloClient builder are some other features
that come to mind.
On Mon, Oct 8, 2018 at 9:05 PM Josh Elser wrote:
Frankly, planning a release
nd testing, and answering some of these unknowns.
> On Mon, Oct 8, 2018 at 11:28 AM Josh Elser wrote:
> >
> > I would like to know what the scope of 2.0 is. Specifically:
> >
> > * What's new in this 2.0 alpha that people that is driving the release?
> > * Is th
I would like to know what the scope of 2.0 is. Specifically:
* What's new in this 2.0 alpha that people that is driving the release?
* Is there anything else expected to land post-alpha/pre-GA?
On 10/6/18 1:36 PM, Sean Busbey wrote:
yes alphas please. Do we want to talk about expectations on ti
Nevermind, Christopher has already fixed this it seems..
On 9/14/18 10:10 AM, Josh Elser wrote:
I'll tag you in a PR. Trivial fix. Don't sweat it :)
On 9/14/18 10:09 AM, Keith Turner wrote:
I will look into it. This branch was outstanding for a long time.
Yesterday I merged it
n Fri, Sep 14, 2018 at 9:11 AM, Josh Elser wrote:
Color me surprised: this fails for me out of the box on
7ef140ec40c3768859b848350db8c6d6d20f7a56
[INFO] Running org.apache.accumulo.core.data.LoadPlanTest
[ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
0.168 s <<
Nevermind, this is silly:
s/TABLET/TABLE/
On 9/14/18 9:11 AM, Josh Elser wrote:
Color me surprised: this fails for me out of the box on
7ef140ec40c3768859b848350db8c6d6d20f7a56
[INFO] Running org.apache.accumulo.core.data.LoadPlanTest
[ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0
Color me surprised: this fails for me out of the box on
7ef140ec40c3768859b848350db8c6d6d20f7a56
[INFO] Running org.apache.accumulo.core.data.LoadPlanTest
[ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
0.168 s <<< FAILURE! - in org.apache.accumulo.core.data.LoadPlanTest
On 7/9/18 4:54 PM, Michael Wall wrote:
Josh, I am not clear on what you are suggesting for another action item.
Are you suggesting a pass over contributors to add see if anyone should be
invited to become a committer or are you suggesting we revisit that every
committer becomes a PMC member?
+1 definitely. Especially since the organizers went through the proper
TM approval steps.
I'd suggest expanding that, in addition to no new committers/PMC
members, to include an action item. e.g. Should we make a pass over
contributors? Or, is participation "constant" (c=pmc makes this a bit
On 6/12/18 1:20 AM, Christopher wrote:
On Mon, Jun 11, 2018 at 10:46 PM Josh Elser wrote:
I'm just trying to point out the fallacy of meeting deadlines when the
criteria for "success" is undefined.
Why? I proposed the timeline to solicit opinions on it. Use whatever
subj
On 6/12/18 10:36 AM, Keith Turner wrote:
On Mon, Jun 11, 2018 at 10:46 PM, Josh Elser wrote:
I'm just trying to point out the fallacy of meeting deadlines when the
criteria for "success" is undefined.
If Jira is overburdened, move everything out and have people move thing
y, my summer is going to be very busy regardless. Initially, I was
> hoping we could release around September 1st... but then I figured add a
> month for dedicated testing and documentation might be nice... and we'd
> still release before the summit.
>
>
> On Mon, Jun 11, 2018
maintained in the draft release notes at
https://accumulo.apache.org/release/accumulo-2.0.0/
On Mon, Jun 11, 2018 at 5:02 PM Josh Elser wrote:
What are the current 2.0.0 features? (Outstanding and completed)
On 6/11/18 4:35 PM, Christopher wrote:
Hi Accumulo Devs,
I've been thinking
What are the current 2.0.0 features? (Outstanding and completed)
On 6/11/18 4:35 PM, Christopher wrote:
Hi Accumulo Devs,
I've been thinking about the 2.0.0 release timeline. I was thinking
something like this milestone timeline:
Feature Complete : mid-late August
Dedicated Testing, Documentat
Hi Marcus,
Via what means?
This information is present on the Accumulo Monitor UI already, lagging
only by a compaction happening on relevant Tablets. You can easily look
at this data for just about any installation.
If via code, I don't believe there is public API (stable) for requesting
t
Also see the xolstice protobuf-maven-plugin which marries up nicely with
the OS properties.
On 5/30/18 3:40 PM, Brian Loss wrote:
If I understand what you are asking correctly, os-maven-plugin [1] is what you
are looking for. It will determine the os name and arch (it puts them in
properties
On 5/30/18 12:41 PM, Christopher wrote:
On Wed, May 30, 2018 at 11:59 AM Josh Elser wrote:
On 5/30/18 9:08 AM, Keith Turner wrote:
On Wed, May 30, 2018 at 12:16 AM, Christopher
wrote:
I thought this was interesting:
https://www.infoworld.com/article/3275924/java/oracle-plans-to-dump
On 5/30/18 9:08 AM, Keith Turner wrote:
On Wed, May 30, 2018 at 12:16 AM, Christopher wrote:
I thought this was interesting:
https://www.infoworld.com/article/3275924/java/oracle-plans-to-dump-risky-java-serialization.html
If the long-term plan is to remove serialization from Java classes (in
Can you give some more context?
Strikes me as strange to be wanting to change a method which we want to
remove (being deprecated).
On 4/23/18 6:05 PM, Mike Miller wrote:
Quick Survey:
Does your project use the flush Table Operation in Accumulo? I am looking
into changing the default behavior
On 4/9/18 12:40 PM, Michael Wall wrote:
Thanks for reading this Josh.
1 - In my first draft I had no information about Tony but I felt like that
was going to prompt questions. I agree contributor is more relevant but he
is not listed on the people page. Do we think that matters?
I don't th
Two minor suggestions:
* Strike the "A member of the Apache Nifi PMC" part. The fact that Tony
was NiFi PMC member isn't really relevant to the request, is it? IMO, if
anything, it's more relevant that Tony is a contributor to Accumulo.
* There isn't any discussion about what is coming next --
e.
https://github.com/apache/accumulo/blob/b0016c3ca36e15ee4bdde727ea5b6a
18597de0ff/core/src/main/java/org/apache/accumulo/core/rpc/
ThriftUtil.java#L383
On Thu, Mar 22, 2018 at 4:00 PM Josh Elser wrote:
I don't have the time to look at these right now. There isn't much
speci
I don't have the time to look at these right now. There isn't much
special about how Accumulo uses Kerberos either. It's straightforward
use via SASL with Thrift. I haven't looked at it since it was passing
when I wrote it originally.
On 3/20/18 2:32 PM, Christopher wrote:
I'm currently lookin
?
On Fri, Mar 16, 2018 at 7:15 PM Josh Elser wrote:
I think I'm in agreement with this subset of Mikes.
I like the idea long-term. The tracing service is "add-on", and can live
outside Accumulo.
I don't like the idea of moving the code out and taking away code which
is functio
I think I'm in agreement with this subset of Mikes.
I like the idea long-term. The tracing service is "add-on", and can live
outside Accumulo.
I don't like the idea of moving the code out and taking away code which
is functional today. I am +1 on the idea of building the same
functionality o
+0 since there seems to be such a strong desire to use this that I just
don't quite understand :)
Thanks to those who worked to clarify the ambiguity/issues that I was
worried about previously.
On 3/13/18 12:53 PM, Keith Turner wrote:
Accumulo PMC,
Please vote on initiating the transition f
IIRC, as long as you have PMC approval and you're not profiting off of
the swag, it's ok from the ASF point of view. I can't find ASF
trademarks documentation on it at the moment, however.
On 3/11/18 12:52 PM, Tony Kurc wrote:
Hi,
I was wondering if anyone had ever designed and printed either
directly to ask
the question goes a long way..
On 3/7/18 10:55 AM, Keith Turner wrote:
On Mon, Mar 5, 2018 at 6:07 PM, Keith Turner wrote:
On Thu, Feb 15, 2018 at 12:52 PM, Josh Elser wrote:
-0 as an initial reaction because I'm still not convinced that GH issues
provides any addit
Yeah, if Hadoop has changed their stance, propagating a "use as your own
risk" would be sufficient from our end.
On 3/1/18 6:06 PM, Christopher wrote:
If there's a risk, I'd suggest calling things out as "experimental" in the
release notes, and encourage users to try it and give us feedback.
O
After the rest of the discussion, I feel like I need to be explicit (so,
I'm sorry if I'm being pedantic and we're already in agreement here):
You're planning to document how GitHub tech would be used to make
releases on these repositories? And, we're in agreement that JIRA would
not be used a
igure out why. I'm trying to think of alternative approaches
to using the traces, and honestly, doing a bunch of log aggregation is the
alternative I'd have to fall back to, and in some cases recompiling parts
of accumulo with new log messages in place.
Tony
On Tue, Feb 27, 2018 at 7:18
ly be disappointed to see it removed. There is a bit of a
learning curve and startup cost to use it now, but when diagnosing major
challenges, it has been an invaluable capability.
On Feb 27, 2018 3:15 PM, "Josh Elser" wrote:
Wow... that's, erm, quite the paper. Nothing like t
Wow... that's, erm, quite the paper. Nothing like taking some pot-shots
at another software project and quoting folks out of context.
Does it help to break down the problem some more?
* Is Accumulo getting benefit from tracing its library?
* Is Accumulo getting benefit from tracing context incl
+1
AFAIK, this wouldn't have to be anything more than build changes.
"Dropping hadoop2 support" wouldn't need to include any other changes
(as adding H3 support didn't require any Java changes). Getting in front
of the ball to help push people towards newer versions would be a
welcome change.
+1 to not changing min-Java on the release lines that supported Java 7.
Let's just cease activity on these branches instead :)
On 2/16/18 9:55 AM, Sean Busbey wrote:
I'm opposed to requiring Java 8 to build on branches that we claim support
running under Java 7. Historically relying on "compile
SGTM
On 2/15/18 11:10 PM, Ed Coleman wrote:
I'd like to propose that we start the release process for 1.7.4 and then
1.9.0. I'm willing to be the release manager for both if that would
facilitate things.
As a strawman - I propose:
March 1st - we start the formal release process of 1.
On 2/15/18 6:18 PM, Christopher wrote:
On Thu, Feb 15, 2018 at 5:08 PM Josh Elser wrote:
On 2/15/18 4:56 PM, Christopher wrote:
On Thu, Feb 15, 2018 at 4:55 PM Josh Elser wrote:
On 2/15/18 4:17 PM, Mike Drob wrote:
What do we do if the trial is wildly successful? Is there a migration
On 2/15/18 4:56 PM, Christopher wrote:
On Thu, Feb 15, 2018 at 4:55 PM Josh Elser wrote:
On 2/15/18 4:17 PM, Mike Drob wrote:
What do we do if the trial is wildly successful? Is there a migration
plan
for our currently open issues? We have almost 1000 of them.
As Keith said in the other
On 2/15/18 4:17 PM, Mike Drob wrote:
What do we do if the trial is wildly successful? Is there a migration
plan
for our currently open issues? We have almost 1000 of them.
As Keith said in the other thread, we don't need to have all the answers up
front.
You're right, we don't need to have
-0 as an initial reaction because I'm still not convinced that GH issues
provides any additional features or better experience than JIRA does,
and this change would only serve to fragment an already bare community.
My concerns that would push that -0 to a -1 include (but aren't limited to):
*
On 2/15/18 12:28 PM, Christopher wrote:
Want to spin out a DISCUSS on the desire to switch, Mike Walch? That
seems to me like it should be the next step.
I thought that's what we were doing.:)
This isn't tagged with DISCUSS in the subject (which I know some
subscribers of our list filter on)
On 2/15/18 11:26 AM, Keith Turner wrote:
On Thu, Feb 15, 2018 at 11:01 AM, Josh Elser wrote:
We tell users that try to file issues on the "unsupported" issue tracker
that they've created the issue in the wrong place and point them to the
right issue tracker.
Personally I t
er
finds the GH issues and creates an issue there? What action should the
developers take?
On Wed, Feb 14, 2018 at 10:27 PM Josh Elser wrote:
I didn't ask for automated controls here -- human controls are fine.
I have already said I am -1 on two concurrent issue trackers. If
developers w
) I think that makes sense since those are
already confusing when filed in the JIRA mixed in with the main repo's
issues.
On Wed, Feb 14, 2018 at 9:25 PM Josh Elser wrote:
I am OK with committers ONLY using GH issues on all repos (with clear
guidance as to what the heck the project is doing)
JIRA. This
period could be limited to a month or two.
On Wed, Feb 14, 2018 at 5:59 PM, Christopher wrote:
What if we had an interim transition period, tentatively using GitHub to
determine it's suitability for our workflows, and shut off JIRA later?
On Wed, Feb 14, 2018 at 5:51 PM Josh Elser
ed, Feb 14, 2018 at 3:26 PM, Josh Elser wrote:
I believe I already stated -1 the last time this was brought up.
Using two issue trackers is silly.
On 2/14/18 3:30 PM, Mike Walch wrote:
I want to enable GitHub issues for Accumulo's repos. This is not to
replace
JIRA but to give contributo
I believe I already stated -1 the last time this was brought up.
Using two issue trackers is silly.
On 2/14/18 3:30 PM, Mike Walch wrote:
I want to enable GitHub issues for Accumulo's repos. This is not to replace
JIRA but to give contributors more options for issue tracking. Unless there
are o
nt
jar?
On Fri, Jan 5, 2018 at 4:31 PM Josh Elser wrote:
MAC, in its common state, is probably not something we'd want to include
in this proposed tarball. The reasoning being that MAC (and related
classes) aren't something that people would need on your "Hadoop
Cluster" to ta
s of these
downstream
vendor/community packagers. One way we can do that here is by either
documenting what would be needed in a client-centric package, or by
providing a script or build profile to create it from source, so that
your
$dayjob or any other downstream packager doesn't hav
shorter would be
nice.
On Thu, Jan 4, 2018 at 7:16 PM, Josh Elser wrote:
Hi,
$dayjob presented me with a request to break up the current tarball into
two: one suitable for "users" and another for the Accumulo services. The
ultimate goal is to make upgrade scenarios a bit easier by
s of these downstream
vendor/community packagers. One way we can do that here is by either
documenting what would be needed in a client-centric package, or by
providing a script or build profile to create it from source, so that your
$dayjob or any other downstream packager doesn't have to f
On 1/5/18 9:55 AM, Keith Turner wrote:
Obviously, there are many ways to go about this. If there is buy-in from
other folks, adding some new assembly descriptors and making it a part of
the Maven build (perhaps, optionally generated) would be the easiest in
terms of maintenance. However, I don't
Hi,
$dayjob presented me with a request to break up the current tarball into
two: one suitable for "users" and another for the Accumulo services. The
ultimate goal is to make upgrade scenarios a bit easier by having client
and server centric packaging.
The "client" tarball would be something
You can configure a replication peer which is the "local" Accumulo instance.
I think there are some ITs which do this.
On 1/4/18 4:13 PM, Mike Miller wrote:
Trying to test a fix for the 2.0 Monitor
https://issues.apache.org/jira/browse/ACCUMULO-4760 and I wanted to enable
replication. Does any
On 12/5/17 6:43 PM, Christopher wrote:
I was wondering about Hadoop 3 shading and whether that would help us. It
would be really nice if it could, or if there was some other class path
solution that was easy.
I think there are two major issues in this thread. The first is the API
problems. The
On 12/6/17 2:06 PM, Christopher wrote:
On Wed, Dec 6, 2017 at 1:55 PM Keith Turner wrote:
On Wed, Dec 6, 2017 at 1:43 PM, Josh Elser wrote:
On 12/6/17 12:17 PM, Keith Turner wrote:
On Wed, Dec 6, 2017 at 11:56 AM, Josh Elser wrote:
Maybe a difference in interpretation:
I was
On 12/6/17 12:17 PM, Keith Turner wrote:
On Wed, Dec 6, 2017 at 11:56 AM, Josh Elser wrote:
Maybe a difference in interpretation:
I was seeing 1a as being source-compatible still. My assumption was that
"Deprecate ClientConfiguration" meant that it would remain in the codebase
-
he old ClientConfiguration and addition of a new
ClientConfig class.
On 12/6/17 11:29 AM, Keith Turner wrote:
On Wed, Dec 6, 2017 at 11:28 AM, Josh Elser wrote:
1.a sounds better to me.
why?
A would be the ideal solution, I think B is the next best if A doesn't work.
I need to get the H
stigation/experimentation into what works, and deal with it after
dealing with steps 1-3 above (but soon after, hopefully).
On Tue, Dec 5, 2017 at 3:58 PM Josh Elser wrote:
Another potential suggestion I forgot about: we try to just move to the
Hadoop shaded artifacts. This would invalidate t
stance zki = new ZooKeeperInstance(cc);
The following would not be source or binary compatible.
Configuration cc = new ClientConfiguration(file);
ZooKeeperInstance zki = new ZooKeeperInstance(cc);
On Tue, Dec 5, 2017 at 3:40 PM, Josh Elser wrote:
On 12/5/17 3:28 PM, Keith Turner wrote:
O
On 12/5/17 3:28 PM, Keith Turner wrote:
On Tue, Dec 5, 2017 at 2:53 PM, Josh Elser wrote:
Interesting. What makes you want to deprecate ClientConfig entirely?
I'd be worried about removing without sufficient thought of replacement
around. It would be a bit "churn-y" to introd
easing 1.8.x in favor of 1.9.x (they are the same except
for new API)
* Release 1.9 ASAP
* Drop clientconfig in 2.0.0
* Release 2.0.0 early next year... maybe target March
On Tue, Dec 5, 2017 at 12:51 PM, Josh Elser wrote:
Ok, a bridge version seems to be a general path forward. Generall
ssage-----
From: Josh Elser [mailto:els...@apache.org]
Sent: Monday, December 4, 2017 6:19 PM
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] Hadoop3 support target?
Also, just to be clear for everyone else:
This means that we have *no roadmap* at all for Hadoop 3 support because
Accumulo 2.
neously with Hadoop. I
kind of like that option, but I don't think it's realistic for our
audiences, as it doesn't allow them to manage their upgrade risks, so the
shaded "bridge" version seems like the better option.
On Mon, Dec 4, 2017 at 6:19 PM Josh Elser wrote:
This is
rious what
people other than Christopher think (assuming from his comments/JIRA
work that he disagrees with me).
On 12/4/17 6:12 PM, Christopher wrote:
Agreed.
On Mon, Dec 4, 2017 at 6:01 PM Josh Elser wrote:
Ah, I'm seeing now -- didn't check my inbox appropriately.
I think the
(which is going to be a major issue for the project).
On 12/4/17 5:58 PM, Josh Elser wrote:
Sorry, I don't follow. Why do you think 4611/4753 is a show-stopper?
Cuz, uh... I made it work already :)
Thanks for the JIRA cleanup. Forgot about that one.
On 12/4/17 5:55 PM, Christopher wro
tibilities (namely, ACCUMULO-4611/4753)
I think people are still patching 1.7, so I don't think we've "officially"
EOL'd it.
I think 2.0 could require Hadoop 3, if Hadoop 3 is sufficiently stable.
On Mon, Dec 4, 2017 at 1:14 PM Josh Elser wrote:
What branch do we want to
What branch do we want to consider Hadoop3 support?
There is a 3.0.0-beta1 release that's been out for a while, and Hadoop
PMC has already done a 3.0.0 RC0. I think it's the right time to start
considering this.
In my poking so far, I've filed ACCUMULO-4753 which I'm working through
now. Thi
On 11/17/17 10:32 AM, Christopher wrote:
On Fri, Nov 17, 2017 at 8:21 AM Josh Elser wrote:
Did you offer to make the release? See me with commons-vfs a time back.
The current issue with Thrift is not the point. The problems we've
encountered with Thrift were was provided as backg
Did you offer to make the release? See me with commons-vfs a time back.
Your proposal seems to me like you're blowing the situation out of
proportion.
On Nov 16, 2017 23:58, "Christopher" wrote:
> The current Thrift issue has already been fixed with a patch. Their PMC
> needs to release it, tho
Hey Mark,
Yup, we're still a CTR project. That should be captured on the website
on our governance page and would require a VOTE by the PMC to change.
We don't have any enforced means of mechanism to perform reviews. We
used to use Reviewboard a bit, but, as of late, more happens on Github
w
ogs the user in via
ugi
what you mean with side effects ?
Jorge Machado
jo...@jmachado.me<mailto:jo...@jmachado.me>
Am 27.10.2017 um 18:31 schrieb Josh Elser
mailto:els...@apache.org>>:
Nearly all components in the Hadoop ecosystem require you to perform a login
with your cr
Nearly all components in the Hadoop ecosystem require you to perform a
login with your credentials when writing Java code.
The only exception I'm aware of is ZooKeeper which can automatically
perform a login via JAAS.
Supporting automatic login via JAAS would be the best path forward here.
C
1 - 100 of 2049 matches
Mail list logo
