accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@apache.org>
Subject Re: [DISCUSS] Hadoop3 support target?
Date Tue, 05 Dec 2017 19:53:18 GMT
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 introduce yet another way that 
clients have to connect (since it was introduced in 1.6-ish?). Working 
around the ClientConfig changes was irritating for the downstream 
integrations (Hive, most notably).

On 12/5/17 1:13 PM, Keith Turner wrote:
> 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