accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Hadoop3 support target?
Date Tue, 05 Dec 2017 18:13:25 GMT
I was thinking of a slightly different path forward.

 * Add new entry point and deprecate clientconfig in 1.9
 * Branch 1.9 off 1.8
 * Stop releasing 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 <elserj@apache.org> wrote:
> Ok, a bridge version seems to be a general path forward. Generally this
> would be...
>
> * 1.8 gets relevant commons-config classes/methods deprecated
> * 1.9 is 1.8 with those deprecation points removed
> * 1.9 has commons-config shaded (maybe?)
>
> IMO, it's critical that we remove the commons-config stuff from our public
> API (shame this somehow was let in to begin).
>
> I think shading our use of commons-config would be a good idea and lessen
> our ClientConfiguration scope to being able to read from a file. Trying to
> support the breadth of what commons-configuration can do will just get us
> into more trouble.
>
>
> On 12/5/17 12:18 PM, Keith Turner wrote:
>>
>> 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.
>>
>>
>> https://github.com/keith-turner/accumulo/commit/1c07fa62e9c57bde7e60907595d50f898d03c9d5
>>
>> 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 <dmarion18@gmail.com> 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 [mailto:elserj@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.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 <elserj@apache.org> 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 <elserj@apache.org>
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
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/ACCUMULO-4753
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>

Mime
View raw message