hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: [DISCUSSION] Items to purge from branch-2 before we cut hbase-2.0.0-beta1.
Date Thu, 02 Nov 2017 03:30:02 GMT
On Wed, Nov 1, 2017 at 7:45 PM, Josh Elser <elserj@apache.org> wrote:

> (This one has been sitting on my mind while doing some non-computer-y
> things this evening; admittedly, in an attempt to NOT think about it. Go
> figure. Let me add to Vlad's previous)
>
> I want to say I still respect that it's the RM's prerogative to be the
> hammer on what makes a release and what doesn't. I don't want to undermine
> that.
>
> I know we are saying "Bug fixes ONLY" for beta-1, I'm pretty sure we
> already have some stuff ear-marked to do that doesn't meet that bar. Is
> writing a test and collecting docs (as Vlad suggests) worthwhile to try to
> do? In other words, if it's not de-stabilizing the rest of the code and not
> holding up beta-1, will a request to add said docs+test be accepted to
> avoid a revert from 2.0.0?
>
> If the 4-5 weeks original estimated is possible, we'd need to get
> something in place in more like 3-4 weeks. Again, a question of how strict
> we are going to be as we get closer and closer.
>
>
We can revisit in 3-4 weeks, of course. December 1st at the outside?

That said, going by just this thread alone, I'll be really surprised if
backup makes beta-1. There seems to be a gap in understanding when we talk
of 'feature complete'. And the bar is higher for a feature like backup as
has been said often enough before because it requires a large, ongoing user
investment with the payoff down the line, some weekend, under duress, when
the operator needs the restore. It has to work.

Good on you Josh,
St.Ack


>
> On 11/1/17 9:13 PM, Vladimir Rodionov wrote:
>
>> Pulling B&R off 2.0 release 5-6 weeks in advance (beta1 timeframe)?
>>
>> I would say that we have enough time to run scalability tests and finish
>> doc before beta1 release.
>>
>> Can we return to this discussion in  a 4-5 weeks and then, based on the
>> B&R
>> state, make a decision?
>>
>> -Vlad
>>
>> On Wed, Nov 1, 2017 at 5:57 PM, Sean Busbey <busbey@apache.org> wrote:
>>
>> Hurm. Operator facing documentation is a blocker, IMHO, on a feature
>>> being ready to ship. Incomplete documentation is part of why we're
>>> pulling the Spark integration from 2.0. Good documentation takes a
>>> large amount of work. The fact that there's no docs in the guide
>>> already makes me think this needs more bake time. (I'm presuming I
>>> haven't just ended up in the wrong part of the ref guide, please let
>>> me know if I have.)
>>>
>>> Ideally, we'd also have an appendix explaining how things work
>>> internally for folks digging in as contributors on the project. But
>>> that'd be a nice to have.
>>>
>>>
>>>
>>> On Wed, Nov 1, 2017 at 7:39 PM, Vladimir Rodionov
>>> <vladrodionov@gmail.com> wrote:
>>>
>>>> Sean
>>>>
>>>> No, this is not our backup description, it is pre-backup era guideline
>>>>
>>> how
>>>
>>>> to do backup in HBase, using snapshots, copy table etc.
>>>>
>>>>
>>>>
>>>> On Wed, Nov 1, 2017 at 5:28 PM, Sean Busbey <busbey@apache.org> wrote:
>>>>
>>>> Vlad,
>>>>>
>>>>> As someone who hasn't spent much time with the backup/restore feature
>>>>> yet, could you help me out on getting a foothold?
>>>>>
>>>>> Which of these Backup/Restore options is it we're specifically talking
>>>>> about:
>>>>>
>>>>> http://hbase.apache.org/book.html#ops.backup
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Nov 1, 2017 at 1:33 PM, Vladimir Rodionov
>>>>> <vladrodionov@gmail.com> wrote:
>>>>>
>>>>>> hbase-backup: Not done and it doesn't look like it will be done for
>>>>>>>>
>>>>>>> beta-1.
>>>>>>
>>>>>>> It can come in later in a 2.1 or 3.0 when it is finished.
>>>>>>>>
>>>>>>>
>>>>>> That is not correct. All blockers have been resolved, the last one
>>>>>>
>>>>> has a
>>>
>>>> patch which is ready to be commited.
>>>>>>
>>>>>> Salesforce team has conducted independent testing and found no issues
>>>>>>
>>>>> with
>>>>>
>>>>>> a functionality to my best knowledge.
>>>>>>
>>>>>> Explain please, Stack.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 1, 2017 at 10:32 AM, Stack <stack@duboce.net> wrote:
>>>>>>
>>>>>> I want to purge the below list of modules, features, and abandoned
>>>>>>>
>>>>>> code
>>>
>>>> from branch-2 before we make a beta-1 (4-5 weeks I'm thinking). Lets
>>>>>>> discuss. Some are already scheduled for removal but listing anyways
>>>>>>>
>>>>>> for
>>>
>>>> completeness sake. Pushback or other suggestions on what else we
>>>>>>>
>>>>>> should
>>>
>>>> remove are welcome.
>>>>>>>
>>>>>>> Distributed Log Replay: Just last week, I heard of someone scheduling
>>>>>>> testing of DLR. We need to better message that this never worked
and
>>>>>>>
>>>>>> was/is
>>>>>
>>>>>> not supported. It's a good idea that we should implement but built
>>>>>>>
>>>>>> on a
>>>
>>>> different chasis (procedurev2?). Meantime, DLR is still scattered
>>>>>>>
>>>>>> about
>>>
>>>> the
>>>>>
>>>>>> codebase as an optional code path. Lets remove it.
>>>>>>>
>>>>>>> hbase-native-client: It is not done and won't be for 2.0.0. It
can
>>>>>>>
>>>>>> come
>>>
>>>> in
>>>>>
>>>>>> later when it is done (2.1 or 3.0).
>>>>>>>
>>>>>>> hbase-prefix-tree: A visionary effort that unfortunately has
had no
>>>>>>>
>>>>>> uptake
>>>>>
>>>>>> since its original wizard-author moved on. I don't believe it is
used
>>>>>>> anywhere. It has become a drag as global changes need to be applied
>>>>>>>
>>>>>> in
>>>
>>>> here
>>>>>
>>>>>> too by folks who are not up on how it works probably doing damage
>>>>>>>
>>>>>> along
>>>
>>>> the
>>>>>
>>>>>> way. This is like DLR in it should be first class but we've not done
>>>>>>>
>>>>>> the
>>>
>>>> work to keep it up.
>>>>>>>
>>>>>>> hbase-backup: Not done and it doesn't look like it will be done
for
>>>>>>>
>>>>>> beta-1.
>>>>>
>>>>>> It can come in later in a 2.1 or 3.0 when it is finished.
>>>>>>>
>>>>>>> hbase-spark: Purging this makes me tear-up.
>>>>>>>
>>>>>>> What else?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> St.Ack
>>>>>>>
>>>>>>>
>>>>>
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message