You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Sean Busbey <bu...@cloudera.com> on 2015/05/22 21:19:58 UTC
Planning for HBase 1.2
Hi folks!
I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
Here's an initial list of things I want to get out:
* MOB
* native crc
* incremental improvements for procedure v2
* adding Java 8 as supported
Anything else folks want to see called out?
--
Sean
Re: Planning for HBase 1.2
Posted by Andrew Purtell <ap...@apache.org>.
Just to clarify, at this point I am not tossing my hat in the ring as RM
for 1.2 since there is already a volunteer and I think we should spread the
RM role around as much as possible.
On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
wrote:
> I was also thinking about RMing for 1.2 as we try and bring something post
> 1.0 into production at my employer.
>
> Related, of the list of features proposed I would strongly prefer MOB not
> be included.
>
>
>
> On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> Hi folks!
>>
>> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
>>
>> Here's an initial list of things I want to get out:
>>
>> * MOB
>>
>> * native crc
>>
>> * incremental improvements for procedure v2
>>
>> * adding Java 8 as supported
>>
>>
>> Anything else folks want to see called out?
>>
>> --
>> Sean
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Planning for HBase 1.2
Posted by Ted Yu <yu...@gmail.com>.
w.r.t. MOB, there hasn't been a mega-patch for branch-1 yet - actually vote
on merging to master branch hasn't closed.
I tend to agree with Andrew's view.
Cheers
On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
wrote:
> I was also thinking about RMing for 1.2 as we try and bring something post
> 1.0 into production at my employer.
>
> Related, of the list of features proposed I would strongly prefer MOB not
> be included.
>
>
>
> On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > Hi folks!
> >
> > I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
> >
> > Here's an initial list of things I want to get out:
> >
> > * MOB
> >
> > * native crc
> >
> > * incremental improvements for procedure v2
> >
> > * adding Java 8 as supported
> >
> >
> > Anything else folks want to see called out?
> >
> > --
> > Sean
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: Planning for HBase 1.2
Posted by Ted Yu <yu...@gmail.com>.
+1 for Sean to be RM from me too.
On Fri, May 29, 2015 at 12:28 PM, Enis Söztutar <en...@apache.org> wrote:
> Belated +1 for Sean for the 1.2 RM. It will be good for having diversity
> for RMs.
>
> Enis
>
> On Fri, May 29, 2015 at 7:59 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > It sounds like we have plenty to get into a 1.2 release regardless of how
> > the discussion over MOB goes.
> >
> > It sounds like we're at consensus for me taking on release manager for
> the
> > 1.2 line? Presuming that's the case, I'll plan to cut a branch in
> mid-June
> > with a goal of getting our first release candidate ready at the start of
> > July.
> >
> > In general, for inclusion in the 1.2 release I'd like to ensure features
> we
> > include can meet a common standard.
> >
> > * ITBLL passes with feature off and on under duress
> > * ACID checks pass with feature off and on under duress
> > * Some kind of verification that we don't backslide on security features
> > * Feature docs in ref guide, presuming it is user facing at all
> > * Operability tools to handle correctness checks and recovery
> > * Perf analysis with feature off and on for both intended workloads and
> > baseline
> >
> > Presuming the above points are handled, I'd be comfortable including
> > features even if we currently want them labeled "experimental".
> >
> > Does this sound reasonable as a general gate for branch-1? Is there
> > anything else we should be insisting on?
> >
> > On Sat, May 23, 2015 at 4:57 PM, lars hofhansl <la...@apache.org> wrote:
> >
> > > It's a large new feature. We might not technically break anything, but
> > > we're introducing a lot of extra risk.
> > > As a case in point... At Salesforce we think the timing would work out
> to
> > > make 1.2 our next standard version. If MOBs were merged we'd likely
> stick
> > > with 1.1 instead.
> > >
> > > I guess it all depends how long we're planning to maintain branches. If
> > > 1.2 indicates the soon death of 1.1 we need to be more careful in 1.2.
> If
> > > we're planning to keep 1.1 (and 1.0) around as long as 0.98, we can be
> > more
> > > aggressive.
> > >
> > > It's a fluffy discussion :)
> > >
> > > -- Lars
> > >
> > > ------------------------------
> > > *From:* Sean Busbey <bu...@cloudera.com>
> > > *To:* dev <de...@hbase.apache.org>; lars hofhansl <la...@apache.org>
> > > *Sent:* Friday, May 22, 2015 9:45 PM
> > >
> > > *Subject:* Re: Planning for HBase 1.2
> > >
> > > So long as we can do it without breaking compatibility, what feels
> wrong
> > > about it? If our goal is to get to semver, we have to progress to
> > > descriptive numbers at some point.
> > >
> > >
> > >
> > > On Fri, May 22, 2015 at 11:39 PM, lars hofhansl <la...@apache.org>
> > wrote:
> > >
> > > Agreed. I'd add that shipping a major feature like MOB with a minor
> > branch
> > > "feels" wrong.
> > > From: Andrew Purtell <ap...@apache.org>
> > > To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> > > Sent: Friday, May 22, 2015 12:40 PM
> > > Subject: Re: Planning for HBase 1.2
> > >
> > > Another point of clarification, sorry, I hit the send button too early
> it
> > > seems: I don't believe MOB is fully integrated yet, for example the
> > feature
> > > is an extension to store that lacks support for encryption (this would
> > > technically be a feature regression); and HBCK. I have not been
> following
> > > MOB too closely so could be mistaken. These issues do not preclude a
> > merge
> > > of MOB into trunk, but do preclude a merge back of MOB from trunk to
> > > branch-1. I would veto the latter until such shortcomings in the
> > > implementation that could be described as regressions are addressed. I
> > > would also like to see a performance analysis of a range of workloads
> > > before and after in as much detail as can be mustered, and would be
> happy
> > > to volunteer to help out with that.
> > >
> > >
> > > On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
> > > wrote:
> > >
> > > > I was also thinking about RMing for 1.2 as we try and bring something
> > > post
> > > > 1.0 into production at my employer.
> > > >
> > > > Related, of the list of features proposed I would strongly prefer MOB
> > not
> > > > be included.
> > > >
> > > >
> > > >
> > > > On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com>
> > > wrote:
> > > >
> > > >> Hi folks!
> > > >>
> > > >> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in
> > July.
> > > >>
> > > >> Here's an initial list of things I want to get out:
> > > >>
> > > >> * MOB
> > > >>
> > > >> * native crc
> > > >>
> > > >> * incremental improvements for procedure v2
> > > >>
> > > >> * adding Java 8 as supported
> > > >>
> > > >>
> > > >> Anything else folks want to see called out?
> > > >>
> > > >> --
> > > >> Sean
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >
> > > > - Andy
> > > >
> > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > Hein
> > > > (via Tom White)
> > >
> > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > > - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Sean
> > >
> > >
> > >
> >
> >
> > --
> > Sean
> >
>
Re: Planning for HBase 1.2
Posted by Enis Söztutar <en...@apache.org>.
Belated +1 for Sean for the 1.2 RM. It will be good for having diversity
for RMs.
Enis
On Fri, May 29, 2015 at 7:59 AM, Sean Busbey <bu...@cloudera.com> wrote:
> It sounds like we have plenty to get into a 1.2 release regardless of how
> the discussion over MOB goes.
>
> It sounds like we're at consensus for me taking on release manager for the
> 1.2 line? Presuming that's the case, I'll plan to cut a branch in mid-June
> with a goal of getting our first release candidate ready at the start of
> July.
>
> In general, for inclusion in the 1.2 release I'd like to ensure features we
> include can meet a common standard.
>
> * ITBLL passes with feature off and on under duress
> * ACID checks pass with feature off and on under duress
> * Some kind of verification that we don't backslide on security features
> * Feature docs in ref guide, presuming it is user facing at all
> * Operability tools to handle correctness checks and recovery
> * Perf analysis with feature off and on for both intended workloads and
> baseline
>
> Presuming the above points are handled, I'd be comfortable including
> features even if we currently want them labeled "experimental".
>
> Does this sound reasonable as a general gate for branch-1? Is there
> anything else we should be insisting on?
>
> On Sat, May 23, 2015 at 4:57 PM, lars hofhansl <la...@apache.org> wrote:
>
> > It's a large new feature. We might not technically break anything, but
> > we're introducing a lot of extra risk.
> > As a case in point... At Salesforce we think the timing would work out to
> > make 1.2 our next standard version. If MOBs were merged we'd likely stick
> > with 1.1 instead.
> >
> > I guess it all depends how long we're planning to maintain branches. If
> > 1.2 indicates the soon death of 1.1 we need to be more careful in 1.2. If
> > we're planning to keep 1.1 (and 1.0) around as long as 0.98, we can be
> more
> > aggressive.
> >
> > It's a fluffy discussion :)
> >
> > -- Lars
> >
> > ------------------------------
> > *From:* Sean Busbey <bu...@cloudera.com>
> > *To:* dev <de...@hbase.apache.org>; lars hofhansl <la...@apache.org>
> > *Sent:* Friday, May 22, 2015 9:45 PM
> >
> > *Subject:* Re: Planning for HBase 1.2
> >
> > So long as we can do it without breaking compatibility, what feels wrong
> > about it? If our goal is to get to semver, we have to progress to
> > descriptive numbers at some point.
> >
> >
> >
> > On Fri, May 22, 2015 at 11:39 PM, lars hofhansl <la...@apache.org>
> wrote:
> >
> > Agreed. I'd add that shipping a major feature like MOB with a minor
> branch
> > "feels" wrong.
> > From: Andrew Purtell <ap...@apache.org>
> > To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> > Sent: Friday, May 22, 2015 12:40 PM
> > Subject: Re: Planning for HBase 1.2
> >
> > Another point of clarification, sorry, I hit the send button too early it
> > seems: I don't believe MOB is fully integrated yet, for example the
> feature
> > is an extension to store that lacks support for encryption (this would
> > technically be a feature regression); and HBCK. I have not been following
> > MOB too closely so could be mistaken. These issues do not preclude a
> merge
> > of MOB into trunk, but do preclude a merge back of MOB from trunk to
> > branch-1. I would veto the latter until such shortcomings in the
> > implementation that could be described as regressions are addressed. I
> > would also like to see a performance analysis of a range of workloads
> > before and after in as much detail as can be mustered, and would be happy
> > to volunteer to help out with that.
> >
> >
> > On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > I was also thinking about RMing for 1.2 as we try and bring something
> > post
> > > 1.0 into production at my employer.
> > >
> > > Related, of the list of features proposed I would strongly prefer MOB
> not
> > > be included.
> > >
> > >
> > >
> > > On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com>
> > wrote:
> > >
> > >> Hi folks!
> > >>
> > >> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in
> July.
> > >>
> > >> Here's an initial list of things I want to get out:
> > >>
> > >> * MOB
> > >>
> > >> * native crc
> > >>
> > >> * incremental improvements for procedure v2
> > >>
> > >> * adding Java 8 as supported
> > >>
> > >>
> > >> Anything else folks want to see called out?
> > >>
> > >> --
> > >> Sean
> > >>
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > > - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> >
> >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
> >
> >
> >
> >
> >
> >
> > --
> > Sean
> >
> >
> >
>
>
> --
> Sean
>
Re: Planning for HBase 1.2
Posted by Stack <st...@duboce.net>.
On Fri, May 29, 2015 at 7:59 AM, Sean Busbey <bu...@cloudera.com> wrote:
> It sounds like we have plenty to get into a 1.2 release regardless of how
> the discussion over MOB goes.
>
> It sounds like we're at consensus for me taking on release manager for the
> 1.2 line? Presuming that's the case, I'll plan to cut a branch in mid-June
> with a goal of getting our first release candidate ready at the start of
> July.
>
> In general, for inclusion in the 1.2 release I'd like to ensure features we
> include can meet a common standard.
>
> * ITBLL passes with feature off and on under duress
> * ACID checks pass with feature off and on under duress
> * Some kind of verification that we don't backslide on security features
> * Feature docs in ref guide, presuming it is user facing at all
> * Operability tools to handle correctness checks and recovery
> * Perf analysis with feature off and on for both intended workloads and
> baseline
>
> Presuming the above points are handled, I'd be comfortable including
> features even if we currently want them labeled "experimental".
>
> Does this sound reasonable as a general gate for branch-1? Is there
> anything else we should be insisting on?
>
> Sounds excellent and Amen to Sean as 1.2 RM.
St.Ack
> On Sat, May 23, 2015 at 4:57 PM, lars hofhansl <la...@apache.org> wrote:
>
> > It's a large new feature. We might not technically break anything, but
> > we're introducing a lot of extra risk.
> > As a case in point... At Salesforce we think the timing would work out to
> > make 1.2 our next standard version. If MOBs were merged we'd likely stick
> > with 1.1 instead.
> >
> > I guess it all depends how long we're planning to maintain branches. If
> > 1.2 indicates the soon death of 1.1 we need to be more careful in 1.2. If
> > we're planning to keep 1.1 (and 1.0) around as long as 0.98, we can be
> more
> > aggressive.
> >
> > It's a fluffy discussion :)
> >
> > -- Lars
> >
> > ------------------------------
> > *From:* Sean Busbey <bu...@cloudera.com>
> > *To:* dev <de...@hbase.apache.org>; lars hofhansl <la...@apache.org>
> > *Sent:* Friday, May 22, 2015 9:45 PM
> >
> > *Subject:* Re: Planning for HBase 1.2
> >
> > So long as we can do it without breaking compatibility, what feels wrong
> > about it? If our goal is to get to semver, we have to progress to
> > descriptive numbers at some point.
> >
> >
> >
> > On Fri, May 22, 2015 at 11:39 PM, lars hofhansl <la...@apache.org>
> wrote:
> >
> > Agreed. I'd add that shipping a major feature like MOB with a minor
> branch
> > "feels" wrong.
> > From: Andrew Purtell <ap...@apache.org>
> > To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> > Sent: Friday, May 22, 2015 12:40 PM
> > Subject: Re: Planning for HBase 1.2
> >
> > Another point of clarification, sorry, I hit the send button too early it
> > seems: I don't believe MOB is fully integrated yet, for example the
> feature
> > is an extension to store that lacks support for encryption (this would
> > technically be a feature regression); and HBCK. I have not been following
> > MOB too closely so could be mistaken. These issues do not preclude a
> merge
> > of MOB into trunk, but do preclude a merge back of MOB from trunk to
> > branch-1. I would veto the latter until such shortcomings in the
> > implementation that could be described as regressions are addressed. I
> > would also like to see a performance analysis of a range of workloads
> > before and after in as much detail as can be mustered, and would be happy
> > to volunteer to help out with that.
> >
> >
> > On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > I was also thinking about RMing for 1.2 as we try and bring something
> > post
> > > 1.0 into production at my employer.
> > >
> > > Related, of the list of features proposed I would strongly prefer MOB
> not
> > > be included.
> > >
> > >
> > >
> > > On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com>
> > wrote:
> > >
> > >> Hi folks!
> > >>
> > >> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in
> July.
> > >>
> > >> Here's an initial list of things I want to get out:
> > >>
> > >> * MOB
> > >>
> > >> * native crc
> > >>
> > >> * incremental improvements for procedure v2
> > >>
> > >> * adding Java 8 as supported
> > >>
> > >>
> > >> Anything else folks want to see called out?
> > >>
> > >> --
> > >> Sean
> > >>
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > > - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> >
> >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
> >
> >
> >
> >
> >
> >
> > --
> > Sean
> >
> >
> >
>
>
> --
> Sean
>
Re: Planning for HBase 1.2
Posted by Sean Busbey <bu...@cloudera.com>.
It sounds like we have plenty to get into a 1.2 release regardless of how
the discussion over MOB goes.
It sounds like we're at consensus for me taking on release manager for the
1.2 line? Presuming that's the case, I'll plan to cut a branch in mid-June
with a goal of getting our first release candidate ready at the start of
July.
In general, for inclusion in the 1.2 release I'd like to ensure features we
include can meet a common standard.
* ITBLL passes with feature off and on under duress
* ACID checks pass with feature off and on under duress
* Some kind of verification that we don't backslide on security features
* Feature docs in ref guide, presuming it is user facing at all
* Operability tools to handle correctness checks and recovery
* Perf analysis with feature off and on for both intended workloads and
baseline
Presuming the above points are handled, I'd be comfortable including
features even if we currently want them labeled "experimental".
Does this sound reasonable as a general gate for branch-1? Is there
anything else we should be insisting on?
On Sat, May 23, 2015 at 4:57 PM, lars hofhansl <la...@apache.org> wrote:
> It's a large new feature. We might not technically break anything, but
> we're introducing a lot of extra risk.
> As a case in point... At Salesforce we think the timing would work out to
> make 1.2 our next standard version. If MOBs were merged we'd likely stick
> with 1.1 instead.
>
> I guess it all depends how long we're planning to maintain branches. If
> 1.2 indicates the soon death of 1.1 we need to be more careful in 1.2. If
> we're planning to keep 1.1 (and 1.0) around as long as 0.98, we can be more
> aggressive.
>
> It's a fluffy discussion :)
>
> -- Lars
>
> ------------------------------
> *From:* Sean Busbey <bu...@cloudera.com>
> *To:* dev <de...@hbase.apache.org>; lars hofhansl <la...@apache.org>
> *Sent:* Friday, May 22, 2015 9:45 PM
>
> *Subject:* Re: Planning for HBase 1.2
>
> So long as we can do it without breaking compatibility, what feels wrong
> about it? If our goal is to get to semver, we have to progress to
> descriptive numbers at some point.
>
>
>
> On Fri, May 22, 2015 at 11:39 PM, lars hofhansl <la...@apache.org> wrote:
>
> Agreed. I'd add that shipping a major feature like MOB with a minor branch
> "feels" wrong.
> From: Andrew Purtell <ap...@apache.org>
> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> Sent: Friday, May 22, 2015 12:40 PM
> Subject: Re: Planning for HBase 1.2
>
> Another point of clarification, sorry, I hit the send button too early it
> seems: I don't believe MOB is fully integrated yet, for example the feature
> is an extension to store that lacks support for encryption (this would
> technically be a feature regression); and HBCK. I have not been following
> MOB too closely so could be mistaken. These issues do not preclude a merge
> of MOB into trunk, but do preclude a merge back of MOB from trunk to
> branch-1. I would veto the latter until such shortcomings in the
> implementation that could be described as regressions are addressed. I
> would also like to see a performance analysis of a range of workloads
> before and after in as much detail as can be mustered, and would be happy
> to volunteer to help out with that.
>
>
> On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > I was also thinking about RMing for 1.2 as we try and bring something
> post
> > 1.0 into production at my employer.
> >
> > Related, of the list of features proposed I would strongly prefer MOB not
> > be included.
> >
> >
> >
> > On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com>
> wrote:
> >
> >> Hi folks!
> >>
> >> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
> >>
> >> Here's an initial list of things I want to get out:
> >>
> >> * MOB
> >>
> >> * native crc
> >>
> >> * incremental improvements for procedure v2
> >>
> >> * adding Java 8 as supported
> >>
> >>
> >> Anything else folks want to see called out?
> >>
> >> --
> >> Sean
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
>
>
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
>
>
>
>
>
>
> --
> Sean
>
>
>
--
Sean
Re: Planning for HBase 1.2
Posted by lars hofhansl <la...@apache.org>.
It's a large new feature. We might not technically break anything, but we're introducing a lot of extra risk.As a case in point... At Salesforce we think the timing would work out to make 1.2 our next standard version. If MOBs were merged we'd likely stick with 1.1 instead.
I guess it all depends how long we're planning to maintain branches. If 1.2 indicates the soon death of 1.1 we need to be more careful in 1.2. If we're planning to keep 1.1 (and 1.0) around as long as 0.98, we can be more aggressive.
It's a fluffy discussion :)
-- Lars
From: Sean Busbey <bu...@cloudera.com>
To: dev <de...@hbase.apache.org>; lars hofhansl <la...@apache.org>
Sent: Friday, May 22, 2015 9:45 PM
Subject: Re: Planning for HBase 1.2
So long as we can do it without breaking compatibility, what feels wrong about it? If our goal is to get to semver, we have to progress to descriptive numbers at some point.
On Fri, May 22, 2015 at 11:39 PM, lars hofhansl <la...@apache.org> wrote:
Agreed. I'd add that shipping a major feature like MOB with a minor branch "feels" wrong.
From: Andrew Purtell <ap...@apache.org>
To: "dev@hbase.apache.org" <de...@hbase.apache.org>
Sent: Friday, May 22, 2015 12:40 PM
Subject: Re: Planning for HBase 1.2
Another point of clarification, sorry, I hit the send button too early it
seems: I don't believe MOB is fully integrated yet, for example the feature
is an extension to store that lacks support for encryption (this would
technically be a feature regression); and HBCK. I have not been following
MOB too closely so could be mistaken. These issues do not preclude a merge
of MOB into trunk, but do preclude a merge back of MOB from trunk to
branch-1. I would veto the latter until such shortcomings in the
implementation that could be described as regressions are addressed. I
would also like to see a performance analysis of a range of workloads
before and after in as much detail as can be mustered, and would be happy
to volunteer to help out with that.
On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
wrote:
> I was also thinking about RMing for 1.2 as we try and bring something post
> 1.0 into production at my employer.
>
> Related, of the list of features proposed I would strongly prefer MOB not
> be included.
>
>
>
> On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> Hi folks!
>>
>> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
>>
>> Here's an initial list of things I want to get out:
>>
>> * MOB
>>
>> * native crc
>>
>> * incremental improvements for procedure v2
>>
>> * adding Java 8 as supported
>>
>>
>> Anything else folks want to see called out?
>>
>> --
>> Sean
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
--
Sean
Re: Planning for HBase 1.2
Posted by Anoop John <an...@gmail.com>.
>Lack of support for HBase native at rest encryption is something that
could be documented.
FYI.. One defect is closed.. But we missed handling some cases (MOB sweep
tool) and for that also there is a patch available. It will get committed
in a day..
-Anoop-
On Sat, May 23, 2015 at 10:15 AM, Sean Busbey <bu...@cloudera.com> wrote:
> So long as we can do it without breaking compatibility, what feels wrong
> about it? If our goal is to get to semver, we have to progress to
> descriptive numbers at some point.
>
> On Fri, May 22, 2015 at 11:39 PM, lars hofhansl <la...@apache.org> wrote:
>
> > Agreed. I'd add that shipping a major feature like MOB with a minor
> branch
> > "feels" wrong.
> > From: Andrew Purtell <ap...@apache.org>
> > To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> > Sent: Friday, May 22, 2015 12:40 PM
> > Subject: Re: Planning for HBase 1.2
> >
> > Another point of clarification, sorry, I hit the send button too early it
> > seems: I don't believe MOB is fully integrated yet, for example the
> feature
> > is an extension to store that lacks support for encryption (this would
> > technically be a feature regression); and HBCK. I have not been following
> > MOB too closely so could be mistaken. These issues do not preclude a
> merge
> > of MOB into trunk, but do preclude a merge back of MOB from trunk to
> > branch-1. I would veto the latter until such shortcomings in the
> > implementation that could be described as regressions are addressed. I
> > would also like to see a performance analysis of a range of workloads
> > before and after in as much detail as can be mustered, and would be happy
> > to volunteer to help out with that.
> >
> >
> > On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > I was also thinking about RMing for 1.2 as we try and bring something
> > post
> > > 1.0 into production at my employer.
> > >
> > > Related, of the list of features proposed I would strongly prefer MOB
> not
> > > be included.
> > >
> > >
> > >
> > > On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com>
> > wrote:
> > >
> > >> Hi folks!
> > >>
> > >> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in
> July.
> > >>
> > >> Here's an initial list of things I want to get out:
> > >>
> > >> * MOB
> > >>
> > >> * native crc
> > >>
> > >> * incremental improvements for procedure v2
> > >>
> > >> * adding Java 8 as supported
> > >>
> > >>
> > >> Anything else folks want to see called out?
> > >>
> > >> --
> > >> Sean
> > >>
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > > - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> >
> >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
> >
> >
> >
>
>
>
> --
> Sean
>
Re: Planning for HBase 1.2
Posted by Sean Busbey <bu...@cloudera.com>.
So long as we can do it without breaking compatibility, what feels wrong
about it? If our goal is to get to semver, we have to progress to
descriptive numbers at some point.
On Fri, May 22, 2015 at 11:39 PM, lars hofhansl <la...@apache.org> wrote:
> Agreed. I'd add that shipping a major feature like MOB with a minor branch
> "feels" wrong.
> From: Andrew Purtell <ap...@apache.org>
> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> Sent: Friday, May 22, 2015 12:40 PM
> Subject: Re: Planning for HBase 1.2
>
> Another point of clarification, sorry, I hit the send button too early it
> seems: I don't believe MOB is fully integrated yet, for example the feature
> is an extension to store that lacks support for encryption (this would
> technically be a feature regression); and HBCK. I have not been following
> MOB too closely so could be mistaken. These issues do not preclude a merge
> of MOB into trunk, but do preclude a merge back of MOB from trunk to
> branch-1. I would veto the latter until such shortcomings in the
> implementation that could be described as regressions are addressed. I
> would also like to see a performance analysis of a range of workloads
> before and after in as much detail as can be mustered, and would be happy
> to volunteer to help out with that.
>
>
> On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > I was also thinking about RMing for 1.2 as we try and bring something
> post
> > 1.0 into production at my employer.
> >
> > Related, of the list of features proposed I would strongly prefer MOB not
> > be included.
> >
> >
> >
> > On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com>
> wrote:
> >
> >> Hi folks!
> >>
> >> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
> >>
> >> Here's an initial list of things I want to get out:
> >>
> >> * MOB
> >>
> >> * native crc
> >>
> >> * incremental improvements for procedure v2
> >>
> >> * adding Java 8 as supported
> >>
> >>
> >> Anything else folks want to see called out?
> >>
> >> --
> >> Sean
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
>
>
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
>
>
>
--
Sean
Re: Planning for HBase 1.2
Posted by lars hofhansl <la...@apache.org>.
Agreed. I'd add that shipping a major feature like MOB with a minor branch "feels" wrong.
From: Andrew Purtell <ap...@apache.org>
To: "dev@hbase.apache.org" <de...@hbase.apache.org>
Sent: Friday, May 22, 2015 12:40 PM
Subject: Re: Planning for HBase 1.2
Another point of clarification, sorry, I hit the send button too early it
seems: I don't believe MOB is fully integrated yet, for example the feature
is an extension to store that lacks support for encryption (this would
technically be a feature regression); and HBCK. I have not been following
MOB too closely so could be mistaken. These issues do not preclude a merge
of MOB into trunk, but do preclude a merge back of MOB from trunk to
branch-1. I would veto the latter until such shortcomings in the
implementation that could be described as regressions are addressed. I
would also like to see a performance analysis of a range of workloads
before and after in as much detail as can be mustered, and would be happy
to volunteer to help out with that.
On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
wrote:
> I was also thinking about RMing for 1.2 as we try and bring something post
> 1.0 into production at my employer.
>
> Related, of the list of features proposed I would strongly prefer MOB not
> be included.
>
>
>
> On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> Hi folks!
>>
>> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
>>
>> Here's an initial list of things I want to get out:
>>
>> * MOB
>>
>> * native crc
>>
>> * incremental improvements for procedure v2
>>
>> * adding Java 8 as supported
>>
>>
>> Anything else folks want to see called out?
>>
>> --
>> Sean
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Planning for HBase 1.2
Posted by Andrew Purtell <an...@gmail.com>.
A perf evaluation for dev use is what I am thinking. Needed: A showing there are not perf regressions when MOB is included but not enabled. Very nice to have: A showing there are not perf regressions for value sizes not in the MOB sweet spot when MOB is enabled. Nice to have: A showing of perf improvement for value sizes in the MOB sweet spot when MOB is enabled. Happy to pitch in on all of these.
> On May 22, 2015, at 1:34 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> Just to make sure I have the concerns correct for 1.2:
>
>
> MOB in 1.2 only if
> * HBCK works correctly
> * at rest encryption
> * perf analysis
>
> Can we get some more detail on the output of the analysis? Are you thinking
> something just for dev use, the ref guide, or a blog post?
>
>> On Fri, May 22, 2015 at 2:40 PM, Andrew Purtell <ap...@apache.org> wrote:
>>
>> Another point of clarification, sorry, I hit the send button too early it
>> seems: I don't believe MOB is fully integrated yet, for example the feature
>> is an extension to store that lacks support for encryption (this would
>> technically be a feature regression); and HBCK. I have not been following
>> MOB too closely so could be mistaken. These issues do not preclude a merge
>> of MOB into trunk, but do preclude a merge back of MOB from trunk to
>> branch-1. I would veto the latter until such shortcomings in the
>> implementation that could be described as regressions are addressed. I
>> would also like to see a performance analysis of a range of workloads
>> before and after in as much detail as can be mustered, and would be happy
>> to volunteer to help out with that.
>>
>>
>> On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>>> I was also thinking about RMing for 1.2 as we try and bring something
>> post
>>> 1.0 into production at my employer.
>>>
>>> Related, of the list of features proposed I would strongly prefer MOB not
>>> be included.
>>>
>>>
>>>
>>>> On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com>
>>> wrote:
>>>
>>>> Hi folks!
>>>>
>>>> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
>>>>
>>>> Here's an initial list of things I want to get out:
>>>>
>>>> * MOB
>>>>
>>>> * native crc
>>>>
>>>> * incremental improvements for procedure v2
>>>>
>>>> * adding Java 8 as supported
>>>>
>>>>
>>>> Anything else folks want to see called out?
>>>>
>>>> --
>>>> Sean
>>>
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> - Andy
>>>
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>> (via Tom White)
>>
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>
>
>
> --
> Sean
Re: Planning for HBase 1.2
Posted by Sean Busbey <bu...@cloudera.com>.
Just to make sure I have the concerns correct for 1.2:
MOB in 1.2 only if
* HBCK works correctly
* at rest encryption
* perf analysis
Can we get some more detail on the output of the analysis? Are you thinking
something just for dev use, the ref guide, or a blog post?
On Fri, May 22, 2015 at 2:40 PM, Andrew Purtell <ap...@apache.org> wrote:
> Another point of clarification, sorry, I hit the send button too early it
> seems: I don't believe MOB is fully integrated yet, for example the feature
> is an extension to store that lacks support for encryption (this would
> technically be a feature regression); and HBCK. I have not been following
> MOB too closely so could be mistaken. These issues do not preclude a merge
> of MOB into trunk, but do preclude a merge back of MOB from trunk to
> branch-1. I would veto the latter until such shortcomings in the
> implementation that could be described as regressions are addressed. I
> would also like to see a performance analysis of a range of workloads
> before and after in as much detail as can be mustered, and would be happy
> to volunteer to help out with that.
>
>
> On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > I was also thinking about RMing for 1.2 as we try and bring something
> post
> > 1.0 into production at my employer.
> >
> > Related, of the list of features proposed I would strongly prefer MOB not
> > be included.
> >
> >
> >
> > On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com>
> wrote:
> >
> >> Hi folks!
> >>
> >> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
> >>
> >> Here's an initial list of things I want to get out:
> >>
> >> * MOB
> >>
> >> * native crc
> >>
> >> * incremental improvements for procedure v2
> >>
> >> * adding Java 8 as supported
> >>
> >>
> >> Anything else folks want to see called out?
> >>
> >> --
> >> Sean
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Sean
Re: Planning for HBase 1.2
Posted by Andrew Purtell <an...@gmail.com>.
Lack of support for HBase native at rest encryption is something that could be documented. For me it's an important gap so I'd still have to think about it. Putting it in to a release headed for production would in effect commit me to fixing it if nobody else is working on it.
A lack of tooling to detect and repair corruption is more fundamental. Can't have that missing in a release meant for production.
Confirming no perf or stability regressions is also critical for prod.
None of these concerns are operative if we are happy to let MOB bake on trunk for a while, but since there's a rush to put it in a 1.x release, now the work has to happen.
> On May 22, 2015, at 1:33 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
> On Fri, May 22, 2015 at 12:40 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
>> Another point of clarification, sorry, I hit the send button too early it
>> seems: I don't believe MOB is fully integrated yet, for example the feature
>> is an extension to store that lacks support for encryption (this would
>> technically be a feature regression); and HBCK. I have not been following
>> MOB too closely so could be mistaken. These issues do not preclude a merge
>> of MOB into trunk, but do preclude a merge back of MOB from trunk to
>> branch-1. I would veto the latter until such shortcomings in the
>> implementation that could be described as regressions are addressed. I
>> would also like to see a performance analysis of a range of workloads
>> before and after in as much detail as can be mustered, and would be happy
>> to volunteer to help out with that.
> I agree that mob is close to ready for trunk merge and that there should be
> a higher bar for features merging into production 1.x branches. The items
> brought up should be addressed -- I'll address the specific mob concerns on
> the mob merge discuss thread.
>
> Like other new features that have been merged and committed into the the
> 1.x line, the mob feature is optional-to-use and should have negligible
> impact if not used. I'd use the same criteria as the other young features
> that have been called out in the 1.0.x and 1.1.x releases -- allow merge
> once concerns are addressed by code fixes or documentation (e.g. explicitly
> stating limitations).
>
> Nick Dimiduk initially wanted the feature in 1.1, but the feature missed
> the train when we found some acid violations in the feature. This blocking
> problem has since been fixed. Sean's list of suggestions is a reasonable
> wishlist, and given that July is 1.5 months away, I think there is
> reasonably sufficient time to make the 1.2 train.
>
>
>>
>> On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>>> I was also thinking about RMing for 1.2 as we try and bring something
>> post
>>> 1.0 into production at my employer.
>>>
>>> Related, of the list of features proposed I would strongly prefer MOB not
>>> be included.
>>>
>>>
>>>
>>>> On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com>
>>> wrote:
>>>
>>>> Hi folks!
>>>>
>>>> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
>>>>
>>>> Here's an initial list of things I want to get out:
>>>>
>>>> * MOB
>>>>
>>>> * native crc
>>>>
>>>> * incremental improvements for procedure v2
>>>>
>>>> * adding Java 8 as supported
>>>>
>>>>
>>>> Anything else folks want to see called out?
>>>>
>>>> --
>>>> Sean
>>>
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> - Andy
>>>
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>> (via Tom White)
>>
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>
>
>
> --
> // Jonathan Hsieh (shay)
> // HBase Tech Lead, Software Engineer, Cloudera
> // jon@cloudera.com // @jmhsieh
Re: Planning for HBase 1.2
Posted by Jonathan Hsieh <jo...@cloudera.com>.
On Fri, May 22, 2015 at 12:40 PM, Andrew Purtell <ap...@apache.org>
wrote:
> Another point of clarification, sorry, I hit the send button too early it
> seems: I don't believe MOB is fully integrated yet, for example the feature
> is an extension to store that lacks support for encryption (this would
> technically be a feature regression); and HBCK. I have not been following
> MOB too closely so could be mistaken. These issues do not preclude a merge
> of MOB into trunk, but do preclude a merge back of MOB from trunk to
> branch-1. I would veto the latter until such shortcomings in the
> implementation that could be described as regressions are addressed. I
> would also like to see a performance analysis of a range of workloads
> before and after in as much detail as can be mustered, and would be happy
> to volunteer to help out with that.
>
>
I agree that mob is close to ready for trunk merge and that there should be
a higher bar for features merging into production 1.x branches. The items
brought up should be addressed -- I'll address the specific mob concerns on
the mob merge discuss thread.
Like other new features that have been merged and committed into the the
1.x line, the mob feature is optional-to-use and should have negligible
impact if not used. I'd use the same criteria as the other young features
that have been called out in the 1.0.x and 1.1.x releases -- allow merge
once concerns are addressed by code fixes or documentation (e.g. explicitly
stating limitations).
Nick Dimiduk initially wanted the feature in 1.1, but the feature missed
the train when we found some acid violations in the feature. This blocking
problem has since been fixed. Sean's list of suggestions is a reasonable
wishlist, and given that July is 1.5 months away, I think there is
reasonably sufficient time to make the 1.2 train.
>
> On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > I was also thinking about RMing for 1.2 as we try and bring something
> post
> > 1.0 into production at my employer.
> >
> > Related, of the list of features proposed I would strongly prefer MOB not
> > be included.
> >
> >
> >
> > On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com>
> wrote:
> >
> >> Hi folks!
> >>
> >> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
> >>
> >> Here's an initial list of things I want to get out:
> >>
> >> * MOB
> >>
> >> * native crc
> >>
> >> * incremental improvements for procedure v2
> >>
> >> * adding Java 8 as supported
> >>
> >>
> >> Anything else folks want to see called out?
> >>
> >> --
> >> Sean
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// jon@cloudera.com // @jmhsieh
Re: Planning for HBase 1.2
Posted by Andrew Purtell <ap...@apache.org>.
Another point of clarification, sorry, I hit the send button too early it
seems: I don't believe MOB is fully integrated yet, for example the feature
is an extension to store that lacks support for encryption (this would
technically be a feature regression); and HBCK. I have not been following
MOB too closely so could be mistaken. These issues do not preclude a merge
of MOB into trunk, but do preclude a merge back of MOB from trunk to
branch-1. I would veto the latter until such shortcomings in the
implementation that could be described as regressions are addressed. I
would also like to see a performance analysis of a range of workloads
before and after in as much detail as can be mustered, and would be happy
to volunteer to help out with that.
On Fri, May 22, 2015 at 12:32 PM, Andrew Purtell <ap...@apache.org>
wrote:
> I was also thinking about RMing for 1.2 as we try and bring something post
> 1.0 into production at my employer.
>
> Related, of the list of features proposed I would strongly prefer MOB not
> be included.
>
>
>
> On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> Hi folks!
>>
>> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
>>
>> Here's an initial list of things I want to get out:
>>
>> * MOB
>>
>> * native crc
>>
>> * incremental improvements for procedure v2
>>
>> * adding Java 8 as supported
>>
>>
>> Anything else folks want to see called out?
>>
>> --
>> Sean
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Planning for HBase 1.2
Posted by Andrew Purtell <ap...@apache.org>.
I was also thinking about RMing for 1.2 as we try and bring something post
1.0 into production at my employer.
Related, of the list of features proposed I would strongly prefer MOB not
be included.
On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com> wrote:
> Hi folks!
>
> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
>
> Here's an initial list of things I want to get out:
>
> * MOB
>
> * native crc
>
> * incremental improvements for procedure v2
>
> * adding Java 8 as supported
>
>
> Anything else folks want to see called out?
>
> --
> Sean
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Planning for HBase 1.2
Posted by Stack <st...@duboce.net>.
On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com> wrote:
> Hi folks!
>
> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
>
> Here's an initial list of things I want to get out:
>
> * MOB
>
> * native crc
>
> * incremental improvements for procedure v2
>
> * adding Java 8 as supported
>
>
> Anything else folks want to see called out?
>
>
I'm working on nice-to-haves:
+ DLR on by default
+ Flush by column family on by default
St.Ack
> --
> Sean
>
Re: Planning for HBase 1.2
Posted by Matteo Bertozzi <th...@gmail.com>.
I have pending, some stuff for Procedure v2, I haven't jira opened yet.
but this is what is on my roadmap (the last 4 are mine, other people can
take the rest. otherwise I'll do them)
- HBASE-XXXX - Master WebUI for tracking what is going on procedure wise
- HBASE-XXXX - define a semantic for coprocessor rollback, and fix DDL
procedures.
- HBASE-13415 - Use nonces for double submits from client
- HBASE-13212 - master Create/Modify/Delete namespace
- Notification BUS - Phase 1 (still compatible with Procedure-v1)
- HBASE-13476 - Add Replay Order logic for child procedures
- HBASE-XXXX - Implement proc-v2 OnePhaseProcedure
- HBASE-XXXX - Rewrite Snapshot coordination with OnePhaseProc
- HBASE-XXXX - Rewrite Restore/Clone SnapshotHandlers
Matteo
On Fri, May 22, 2015 at 12:19 PM, Sean Busbey <bu...@cloudera.com> wrote:
> Hi folks!
>
> I'd like to volunteer to RM HBase 1.2 and aim for RCs starting in July.
>
> Here's an initial list of things I want to get out:
>
> * MOB
>
> * native crc
>
> * incremental improvements for procedure v2
>
> * adding Java 8 as supported
>
>
> Anything else folks want to see called out?
>
> --
> Sean
>