accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <>
Subject Re: [DISCUSS] Hadoop3 support target?
Date Tue, 05 Dec 2017 17:18:11 GMT
If we are going to deprecate, then it would be nice to have a
replacement.  One thing that has irked me about the current Accumulo
entry point is that one can not specify everything needed to connect
to in a single props file.  Specifically, credentials can not be
specified.  It would be really nice to have a new entry point that
allows this.

We could release a 1.9 bridge version.  This version would be based on
1.8 and only include a new entry point. Base it on 1.8 in order to
allow a low risk upgrade for anyone currently using 1.8.  Once people
start using 1.9 they can have code that uses the old and new entry
point running at the same time.  In 2.0 we can drop the problematic
entry point.

Below is a commit to 1.8 where I was experimenting with a new entry point.

This new API would need review, its rough and there are some things I
don't like about it.  Just sharing for discussion of general concept,
not advocating for this specific API.

On Mon, Dec 4, 2017 at 6:27 PM, Dave Marion <> wrote:
> There is no reason that you can't mark the offending API methods as deprecated in a 1.8.x
release, then immediately branch off of that to create a 2.0 and remove the method. Alternatively,
we could decide to forego the semver rules for a specific release and make sure to point it
out in the release notes.
> -----Original Message-----
> From: Josh Elser []
> Sent: Monday, December 4, 2017 6:19 PM
> To:
> 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.0
is in a state of languish.
> This is a severe enough problem to me that I would consider breaking API compatibility
and fixing the API leak in 1.7/1.8. I'm curious 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 fact that code that we don't own has somehow been allowed
>>> to be public API is the smell. That's something that needs to be
>>> rectified sooner than later. By that measure, it can *only* land on
>>> Accumulo 2.0 (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 wrote:
>>>>> I don't think we can support it with 1.8 or earlier, because of
>>>>> some serious incompatibilities (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 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. This does raise the question: where do we want to say
>>>>>> we support Hadoop3? 1.8 or 2.0? (have we "officially" deprecated
>>>>>> 1.7?)
>>>>>> - Josh

View raw message