Grokbase Groups HBase dev July 2012
FAQ
Hi All,

I did a pass through all issues against 0.94.1, retargeted some, fixed some others.
There're still 13 Major and 1 Minor issue left. Please look through the issue that you have filed (or are working on),
and make a call whether you want this should hold up the next 0.94 release. If not, please retarget to 0.94.2
(Or mail me offline if you have questions).

Obviously we'll fix the Blocker/Critical issues before the next release.

Thanks.

-- Lars

Search Discussions

  • Roman Shaposhnik at Jul 9, 2012 at 3:36 pm

    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some, fixed some others.
    There're still 13 Major and 1 Minor issue left. Please look through the issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94 release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be validating
    RCs.

    Thanks,
    Roman.
  • Lars hofhansl at Jul 9, 2012 at 11:08 pm
    That's great, thanks for setting this up Roman!


    There're only three issues left against 0.94.1.
    I want to push it out quickly because of HBASE-6311.

    I am 90% sure there'll be a first RC this week.

    -- Lars



    ----- Original Message -----
    From: Roman Shaposhnik <rvs@apache.org>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 8:35 AM
    Subject: Re: HBase 0.94.1
    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some, fixed some others.
    There're still 13 Major and 1 Minor issue left. Please look through the issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94 release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be validating
    RCs.

    Thanks,
    Roman.
  • Ted Yu at Jul 9, 2012 at 11:39 pm
    If possible, can you wait for the poll on metrics2 framework to close ?
    If the poll passes, 0.94.1 RC would carry deprecation for (old) metric
    classes.

    Thanks
    On Mon, Jul 9, 2012 at 4:07 PM, lars hofhansl wrote:

    That's great, thanks for setting this up Roman!


    There're only three issues left against 0.94.1.
    I want to push it out quickly because of HBASE-6311.

    I am 90% sure there'll be a first RC this week.

    -- Lars



    ----- Original Message -----
    From: Roman Shaposhnik <rvs@apache.org>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 8:35 AM
    Subject: Re: HBase 0.94.1
    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some, fixed
    some others.
    There're still 13 Major and 1 Minor issue left. Please look through the
    issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94
    release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be validating
    RCs.

    Thanks,
    Roman.
  • Lars hofhansl at Jul 9, 2012 at 11:53 pm
    0.94 is already out and did not have these deprecated. So deprecating them now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If push comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?

    Lastly, I don't think we need to deprecate now in order in remove in 0.96.


    Thanks.

    -- Lars



    ----- Original Message -----
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 4:38 PM
    Subject: Re: HBase 0.94.1

    If possible, can you wait for the poll on metrics2 framework to close ?
    If the poll passes, 0.94.1 RC would carry deprecation for (old) metric
    classes.

    Thanks
    On Mon, Jul 9, 2012 at 4:07 PM, lars hofhansl wrote:

    That's great, thanks for setting this up Roman!


    There're only three issues left against 0.94.1.
    I want to push it out quickly because of HBASE-6311.

    I am 90% sure there'll be a first RC this week.

    -- Lars



    ----- Original Message -----
    From: Roman Shaposhnik <rvs@apache.org>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 8:35 AM
    Subject: Re: HBase 0.94.1
    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some, fixed
    some others.
    There're still 13 Major and 1 Minor issue left. Please look through the
    issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94
    release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be validating
    RCs.

    Thanks,
    Roman.
  • Ted Yu at Jul 10, 2012 at 12:05 am
    0.94.0 was not a stable release.
    I hope 0.94.1 would be stable. My rationale was that deprecating current
    metric classes in the first stable release of 0.94 should be acceptable.

    I would humbly listen to other people's opinions, of course.

    Cheers
    On Mon, Jul 9, 2012 at 4:46 PM, lars hofhansl wrote:

    0.94 is already out and did not have these deprecated. So deprecating them
    now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?

    Lastly, I don't think we need to deprecate now in order in remove in 0.96.


    Thanks.

    -- Lars



    ----- Original Message -----
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 4:38 PM
    Subject: Re: HBase 0.94.1

    If possible, can you wait for the poll on metrics2 framework to close ?
    If the poll passes, 0.94.1 RC would carry deprecation for (old) metric
    classes.

    Thanks
    On Mon, Jul 9, 2012 at 4:07 PM, lars hofhansl wrote:

    That's great, thanks for setting this up Roman!


    There're only three issues left against 0.94.1.
    I want to push it out quickly because of HBASE-6311.

    I am 90% sure there'll be a first RC this week.

    -- Lars



    ----- Original Message -----
    From: Roman Shaposhnik <rvs@apache.org>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 8:35 AM
    Subject: Re: HBase 0.94.1
    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some, fixed
    some others.
    There're still 13 Major and 1 Minor issue left. Please look through the
    issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94
    release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be validating
    RCs.

    Thanks,
    Roman.
  • Jesse Yates at Jul 10, 2012 at 12:28 am
    Its a little funky to deprecate at this point, but the stable release
    argument is completely valid, especially to get the metrics into the
    singularity.

    +1
    -------------------
    Jesse Yates
    @jesse_yates
    jyates.github.com

    On Mon, Jul 9, 2012 at 5:04 PM, Ted Yu wrote:

    0.94.0 was not a stable release.
    I hope 0.94.1 would be stable. My rationale was that deprecating current
    metric classes in the first stable release of 0.94 should be acceptable.

    I would humbly listen to other people's opinions, of course.

    Cheers
    On Mon, Jul 9, 2012 at 4:46 PM, lars hofhansl wrote:

    0.94 is already out and did not have these deprecated. So deprecating them
    now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?

    Lastly, I don't think we need to deprecate now in order in remove in 0.96.

    Thanks.

    -- Lars



    ----- Original Message -----
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 4:38 PM
    Subject: Re: HBase 0.94.1

    If possible, can you wait for the poll on metrics2 framework to close ?
    If the poll passes, 0.94.1 RC would carry deprecation for (old) metric
    classes.

    Thanks
    On Mon, Jul 9, 2012 at 4:07 PM, lars hofhansl wrote:

    That's great, thanks for setting this up Roman!


    There're only three issues left against 0.94.1.
    I want to push it out quickly because of HBASE-6311.

    I am 90% sure there'll be a first RC this week.

    -- Lars



    ----- Original Message -----
    From: Roman Shaposhnik <rvs@apache.org>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 8:35 AM
    Subject: Re: HBase 0.94.1

    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some,
    fixed
    some others.
    There're still 13 Major and 1 Minor issue left. Please look through
    the
    issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94
    release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be validating
    RCs.

    Thanks,
    Roman.
  • Andrew Purtell at Jul 10, 2012 at 12:52 am
    +1 on deprecating metrics1 in the point release. If we are yanking it in 0.96 then fair warning seems fair. However I also concur with Elliott's comment in a recent JIRA that we should still accept small fixes to our use of metrics1 by contributors rather than suggest they do our migration from metrics1 to metrics2 for us.

    - Andy
    On Jul 9, 2012, at 5:27 PM, Jesse Yates wrote:

    Its a little funky to deprecate at this point, but the stable release
    argument is completely valid, especially to get the metrics into the
    singularity.

    +1
    -------------------
    Jesse Yates
    @jesse_yates
    jyates.github.com

    On Mon, Jul 9, 2012 at 5:04 PM, Ted Yu wrote:

    0.94.0 was not a stable release.
    I hope 0.94.1 would be stable. My rationale was that deprecating current
    metric classes in the first stable release of 0.94 should be acceptable.

    I would humbly listen to other people's opinions, of course.

    Cheers
    On Mon, Jul 9, 2012 at 4:46 PM, lars hofhansl wrote:

    0.94 is already out and did not have these deprecated. So deprecating them
    now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?

    Lastly, I don't think we need to deprecate now in order in remove in 0.96.

    Thanks.

    -- Lars



    ----- Original Message -----
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 4:38 PM
    Subject: Re: HBase 0.94.1

    If possible, can you wait for the poll on metrics2 framework to close ?
    If the poll passes, 0.94.1 RC would carry deprecation for (old) metric
    classes.

    Thanks

    On Mon, Jul 9, 2012 at 4:07 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    That's great, thanks for setting this up Roman!


    There're only three issues left against 0.94.1.
    I want to push it out quickly because of HBASE-6311.

    I am 90% sure there'll be a first RC this week.

    -- Lars



    ----- Original Message -----
    From: Roman Shaposhnik <rvs@apache.org>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 8:35 AM
    Subject: Re: HBase 0.94.1

    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some,
    fixed
    some others.
    There're still 13 Major and 1 Minor issue left. Please look through
    the
    issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94
    release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be validating
    RCs.

    Thanks,
    Roman.
  • Andrew Purtell at Jul 10, 2012 at 12:43 am
    Ted,

    Please explain in more detail why 0.94.0 was not a stable release. And what about 0.94.1 is different that it should be considered stable now? And since 0.94.0 was, as you contend, an unstable release, how did it get by the RC process and what can we do to improve the RC process so that does not happen again? Thanks.

    - Andy
    On Jul 9, 2012, at 5:04 PM, Ted Yu wrote:

    0.94.0 was not a stable release.
    I hope 0.94.1 would be stable. My rationale was that deprecating current
    metric classes in the first stable release of 0.94 should be acceptable.

    I would humbly listen to other people's opinions, of course.

    Cheers
    On Mon, Jul 9, 2012 at 4:46 PM, lars hofhansl wrote:

    0.94 is already out and did not have these deprecated. So deprecating them
    now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?

    Lastly, I don't think we need to deprecate now in order in remove in 0.96.


    Thanks.

    -- Lars



    ----- Original Message -----
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 4:38 PM
    Subject: Re: HBase 0.94.1

    If possible, can you wait for the poll on metrics2 framework to close ?
    If the poll passes, 0.94.1 RC would carry deprecation for (old) metric
    classes.

    Thanks
    On Mon, Jul 9, 2012 at 4:07 PM, lars hofhansl wrote:

    That's great, thanks for setting this up Roman!


    There're only three issues left against 0.94.1.
    I want to push it out quickly because of HBASE-6311.

    I am 90% sure there'll be a first RC this week.

    -- Lars



    ----- Original Message -----
    From: Roman Shaposhnik <rvs@apache.org>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 8:35 AM
    Subject: Re: HBase 0.94.1

    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some, fixed
    some others.
    There're still 13 Major and 1 Minor issue left. Please look through the
    issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94
    release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be validating
    RCs.

    Thanks,
    Roman.
  • Ted Yu at Jul 10, 2012 at 1:10 am
    Andy:
    Good questions.

    The fact that HBASE-6311 is deemed by Lars to be an important fix adds
    support for my reasoning.

    I read the posts under 'ANN: The third hbase 0.94.0 release candidate is
    available for download' again.

    There was discussion on 'Dictionary WAL compression making replication not
    functional' which later was marked as experimental.
    This message from LarsH on May 13th is notable:

    'If there are no -1's by Wed, May 16th, I'll release RC4 as 0.94.0.'

    To answer the last question below, I think we should allow ample time for
    HBase users to try out the RC before declaration of the release.
    We're building something that one day would take away significant chunk of
    market share from traditional RDBMS vendors. Quality should always be our
    top priority.

    I would anticipate wider participation in validating 0.94.1 this time.
    To my knowledge, Cloudera, Huawei and Taobao have all been actively testing
    0.94 builds for some time. That was why critical issues were raised.
    This should have laid better foundation for the release of 0.94.1

    Cheers
    On Mon, Jul 9, 2012 at 5:43 PM, Andrew Purtell wrote:

    Ted,

    Please explain in more detail why 0.94.0 was not a stable release. And
    what about 0.94.1 is different that it should be considered stable now? And
    since 0.94.0 was, as you contend, an unstable release, how did it get by
    the RC process and what can we do to improve the RC process so that does
    not happen again? Thanks.

    - Andy
    On Jul 9, 2012, at 5:04 PM, Ted Yu wrote:

    0.94.0 was not a stable release.
    I hope 0.94.1 would be stable. My rationale was that deprecating current
    metric classes in the first stable release of 0.94 should be acceptable.

    I would humbly listen to other people's opinions, of course.

    Cheers
    On Mon, Jul 9, 2012 at 4:46 PM, lars hofhansl wrote:

    0.94 is already out and did not have these deprecated. So deprecating
    them
    now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?

    Lastly, I don't think we need to deprecate now in order in remove in
    0.96.

    Thanks.

    -- Lars



    ----- Original Message -----
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 4:38 PM
    Subject: Re: HBase 0.94.1

    If possible, can you wait for the poll on metrics2 framework to close ?
    If the poll passes, 0.94.1 RC would carry deprecation for (old) metric
    classes.

    Thanks
    On Mon, Jul 9, 2012 at 4:07 PM, lars hofhansl wrote:

    That's great, thanks for setting this up Roman!


    There're only three issues left against 0.94.1.
    I want to push it out quickly because of HBASE-6311.

    I am 90% sure there'll be a first RC this week.

    -- Lars



    ----- Original Message -----
    From: Roman Shaposhnik <rvs@apache.org>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 8:35 AM
    Subject: Re: HBase 0.94.1

    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some, fixed
    some others.
    There're still 13 Major and 1 Minor issue left. Please look through
    the
    issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94
    release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be validating
    RCs.

    Thanks,
    Roman.
  • Gregory Chanan at Jul 10, 2012 at 1:35 am
    If you go to one of the download mirrors and click "stable" it brings you
    to a 0.92.1 release, not a 0.94.0 release.
    For example: http://www.bizdirusa.com/mirrors/apache/hbase/stable/

    What is a user supposed to conclude from that? That 0.94 is not yet stable?
    Greg
    On Mon, Jul 9, 2012 at 6:09 PM, Ted Yu wrote:

    Andy:
    Good questions.

    The fact that HBASE-6311 is deemed by Lars to be an important fix adds
    support for my reasoning.

    I read the posts under 'ANN: The third hbase 0.94.0 release candidate is
    available for download' again.

    There was discussion on 'Dictionary WAL compression making replication not
    functional' which later was marked as experimental.
    This message from LarsH on May 13th is notable:

    'If there are no -1's by Wed, May 16th, I'll release RC4 as 0.94.0.'

    To answer the last question below, I think we should allow ample time for
    HBase users to try out the RC before declaration of the release.
    We're building something that one day would take away significant chunk of
    market share from traditional RDBMS vendors. Quality should always be our
    top priority.

    I would anticipate wider participation in validating 0.94.1 this time.
    To my knowledge, Cloudera, Huawei and Taobao have all been actively testing
    0.94 builds for some time. That was why critical issues were raised.
    This should have laid better foundation for the release of 0.94.1

    Cheers

    On Mon, Jul 9, 2012 at 5:43 PM, Andrew Purtell <andrew.purtell@gmail.com
    wrote:
    Ted,

    Please explain in more detail why 0.94.0 was not a stable release. And
    what about 0.94.1 is different that it should be considered stable now? And
    since 0.94.0 was, as you contend, an unstable release, how did it get by
    the RC process and what can we do to improve the RC process so that does
    not happen again? Thanks.

    - Andy
    On Jul 9, 2012, at 5:04 PM, Ted Yu wrote:

    0.94.0 was not a stable release.
    I hope 0.94.1 would be stable. My rationale was that deprecating
    current
    metric classes in the first stable release of 0.94 should be
    acceptable.
    I would humbly listen to other people's opinions, of course.

    Cheers

    On Mon, Jul 9, 2012 at 4:46 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    0.94 is already out and did not have these deprecated. So deprecating
    them
    now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If
    push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?

    Lastly, I don't think we need to deprecate now in order in remove in
    0.96.

    Thanks.

    -- Lars



    ----- Original Message -----
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 4:38 PM
    Subject: Re: HBase 0.94.1

    If possible, can you wait for the poll on metrics2 framework to close
    ?
    If the poll passes, 0.94.1 RC would carry deprecation for (old) metric
    classes.

    Thanks

    On Mon, Jul 9, 2012 at 4:07 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    That's great, thanks for setting this up Roman!


    There're only three issues left against 0.94.1.
    I want to push it out quickly because of HBASE-6311.

    I am 90% sure there'll be a first RC this week.

    -- Lars



    ----- Original Message -----
    From: Roman Shaposhnik <rvs@apache.org>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 8:35 AM
    Subject: Re: HBase 0.94.1

    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some,
    fixed
    some others.
    There're still 13 Major and 1 Minor issue left. Please look through
    the
    issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94
    release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be
    validating
    RCs.

    Thanks,
    Roman.
  • Andrew Purtell at Jul 10, 2012 at 6:39 am
    I can't follow issues@ volume and don't know what to make of dist/. The questions I asked were not rhetorical. What I remember about 0.94.0 was it passed RC, I've been working on issues with 0.94 against 2.0 (but that's tagged alpha) and was surprised by the flat assessment because it seems to cover 0.94 + 1.0 as well.
    On Jul 9, 2012, at 6:34 PM, Gregory Chanan wrote:

    If you go to one of the download mirrors and click "stable" it brings you
    to a 0.92.1 release, not a 0.94.0 release.
    For example: http://www.bizdirusa.com/mirrors/apache/hbase/stable/

    What is a user supposed to conclude from that? That 0.94 is not yet stable?
    Greg
    On Mon, Jul 9, 2012 at 6:09 PM, Ted Yu wrote:

    Andy:
    Good questions.

    The fact that HBASE-6311 is deemed by Lars to be an important fix adds
    support for my reasoning.

    I read the posts under 'ANN: The third hbase 0.94.0 release candidate is
    available for download' again.

    There was discussion on 'Dictionary WAL compression making replication not
    functional' which later was marked as experimental.
    This message from LarsH on May 13th is notable:

    'If there are no -1's by Wed, May 16th, I'll release RC4 as 0.94.0.'

    To answer the last question below, I think we should allow ample time for
    HBase users to try out the RC before declaration of the release.
    We're building something that one day would take away significant chunk of
    market share from traditional RDBMS vendors. Quality should always be our
    top priority.

    I would anticipate wider participation in validating 0.94.1 this time.
    To my knowledge, Cloudera, Huawei and Taobao have all been actively testing
    0.94 builds for some time. That was why critical issues were raised.
    This should have laid better foundation for the release of 0.94.1

    Cheers

    On Mon, Jul 9, 2012 at 5:43 PM, Andrew Purtell <andrew.purtell@gmail.com
    wrote:
    Ted,

    Please explain in more detail why 0.94.0 was not a stable release. And
    what about 0.94.1 is different that it should be considered stable now? And
    since 0.94.0 was, as you contend, an unstable release, how did it get by
    the RC process and what can we do to improve the RC process so that does
    not happen again? Thanks.

    - Andy
    On Jul 9, 2012, at 5:04 PM, Ted Yu wrote:

    0.94.0 was not a stable release.
    I hope 0.94.1 would be stable. My rationale was that deprecating
    current
    metric classes in the first stable release of 0.94 should be
    acceptable.
    I would humbly listen to other people's opinions, of course.

    Cheers

    On Mon, Jul 9, 2012 at 4:46 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    0.94 is already out and did not have these deprecated. So deprecating
    them
    now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If
    push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?

    Lastly, I don't think we need to deprecate now in order in remove in
    0.96.

    Thanks.

    -- Lars



    ----- Original Message -----
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 4:38 PM
    Subject: Re: HBase 0.94.1

    If possible, can you wait for the poll on metrics2 framework to close
    ?
    If the poll passes, 0.94.1 RC would carry deprecation for (old) metric
    classes.

    Thanks

    On Mon, Jul 9, 2012 at 4:07 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    That's great, thanks for setting this up Roman!


    There're only three issues left against 0.94.1.
    I want to push it out quickly because of HBASE-6311.

    I am 90% sure there'll be a first RC this week.

    -- Lars



    ----- Original Message -----
    From: Roman Shaposhnik <rvs@apache.org>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 8:35 AM
    Subject: Re: HBase 0.94.1

    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some,
    fixed
    some others.
    There're still 13 Major and 1 Minor issue left. Please look through
    the
    issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94
    release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be
    validating
    RCs.

    Thanks,
    Roman.
  • Michael Stack at Jul 10, 2012 at 4:37 pm

    On Tue, Jul 10, 2012 at 3:34 AM, Gregory Chanan wrote:
    If you go to one of the download mirrors and click "stable" it brings you
    to a 0.92.1 release, not a 0.94.0 release.
    For example: http://www.bizdirusa.com/mirrors/apache/hbase/stable/

    What is a user supposed to conclude from that? That 0.94 is not yet stable?
    I'd usually update the stable pointer to the new .0 release but didn't
    this time. It was part oversight and partly the fact that we've not
    brought 0.94 up fully at SU yet.

    St.Ack
  • Jean-Daniel Cryans at Jul 10, 2012 at 4:56 pm

    On Tue, Jul 10, 2012 at 9:37 AM, Stack wrote:
    I'd usually update the stable pointer to the new .0 release but didn't
    this time. It was part oversight and partly the fact that we've not
    brought 0.94 up fully at SU yet.
    To follow up on that, 0.94 is only on a dev cluster at the moment and
    we're about to deploy a new refresh. One issue that's really a blocker
    for us is:

    https://issues.apache.org/jira/browse/HBASE-6310 "-ROOT- corruption
    when .META. is using the old encoding scheme"

    I can't have my clusters fail to boot after some outage because .META.
    isn't reachable. We're still digging.

    Another issue that I haven't looked into too much yet is that the new
    hbck cannot be used on an old cluster.

    Right now what I'm getting is not what I usually get but it's:

    ERROR: .META. is found on more than one region.
    ERROR: Encountered fatal error. Exiting...
    Summary:
    2 inconsistencies detected.
    Status: INCONSISTENT

    Although:


    hbase(main):001:0> scan '-ROOT-'
    ROW COLUMN+CELL
    12/07/10 16:51:58 INFO security.UserGroupInformation: JAAS
    Configuration already set up for Hadoop, not re-installing.
    .META.,,1 column=info:regioninfo,
    timestamp=1331755381142, value={NAME => '.META.,,1', STARTKEY => '',
    ENDKEY => '', ENCODED => 1028785192,}
    .META.,,1 column=info:server,
    timestamp=1341618049327, value=sfor3s40:10304
    .META.,,1
    column=info:serverstartcode, timestamp=1341618049327,
    value=1341515423853
    .META.,,1 column=info:v,
    timestamp=1331755419291, value=\x00\x00
    1 row(s) in 0.5370 seconds


    So I guess it's something new we need to debug...
  • Lars hofhansl at Jul 10, 2012 at 5:41 pm
    I pulled HBASE-6310 into 0.94.1.
    Once that is fixed I'll release an RC.
    If metrics deprecation is not done by then it'll need to go into 0.94.2 (or potentially a future RC).


    -- Lars


    ----- Original Message -----
    From: Jean-Daniel Cryans <jdcryans@apache.org>
    To: dev@hbase.apache.org
    Cc:
    Sent: Tuesday, July 10, 2012 9:55 AM
    Subject: Re: HBase 0.94.1
    On Tue, Jul 10, 2012 at 9:37 AM, Stack wrote:
    I'd usually update the stable pointer to the new .0 release but didn't
    this time.  It was part oversight and partly the fact that we've not
    brought 0.94 up fully at SU yet.
    To follow up on that, 0.94 is only on a dev cluster at the moment and
    we're about to deploy a new refresh. One issue that's really a blocker
    for us is:

    https://issues.apache.org/jira/browse/HBASE-6310 "-ROOT- corruption
    when .META. is using the old encoding scheme"

    I can't have my clusters fail to boot after some outage because .META.
    isn't reachable. We're still digging.

    Another issue that I haven't looked into too much yet is that the new
    hbck cannot be used on an old cluster.

    Right now what I'm getting is not what I usually get but it's:

    ERROR: .META. is found on more than one region.
    ERROR: Encountered fatal error. Exiting...
    Summary:
    2 inconsistencies detected.
    Status: INCONSISTENT

    Although:


    hbase(main):001:0> scan '-ROOT-'
    ROW                                          COLUMN+CELL
    12/07/10 16:51:58 INFO security.UserGroupInformation: JAAS
    Configuration already set up for Hadoop, not re-installing.
    .META.,,1                                    column=info:regioninfo,
    timestamp=1331755381142, value={NAME => '.META.,,1', STARTKEY => '',
    ENDKEY => '', ENCODED => 1028785192,}
    .META.,,1                                    column=info:server,
    timestamp=1341618049327, value=sfor3s40:10304
    .META.,,1
    column=info:serverstartcode, timestamp=1341618049327,
    value=1341515423853
    .META.,,1                                    column=info:v,
    timestamp=1331755419291, value=\x00\x00
    1 row(s) in 0.5370 seconds


    So I guess it's something new we need to debug...
  • Lars hofhansl at Jul 10, 2012 at 4:16 am
    Whether 0.94.0 was stable or not is orthorgonal to whether an API can be deprecated in a point release or not, no?

    Since we appear to have critical mass of support to do that, can you file a jira w/ patch in the next two days?
    Holding up an 0.94.1RC to deprecate the old metric system seems counterproductive.

    Lastly, please refrain from personal attacks like the ones below. We're all doing our best to get HBase to the most stable point.


    -- Lars
    ________________________________
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org
    Sent: Monday, July 9, 2012 6:09 PM
    Subject: Re: HBase 0.94.1

    Andy:
    Good questions.

    The fact that HBASE-6311 is deemed by Lars to be an important fix adds
    support for my reasoning.

    I read the posts under 'ANN: The third hbase 0.94.0 release candidate is
    available for download' again.

    There was discussion on 'Dictionary WAL compression making replication not
    functional' which later was marked as experimental.
    This message from LarsH on May 13th is notable:

    'If there are no -1's by Wed, May 16th, I'll release RC4 as 0.94.0.'

    To answer the last question below, I think we should allow ample time for
    HBase users to try out the RC before declaration of the release.
    We're building something that one day would take away significant chunk of
    market share from traditional RDBMS vendors. Quality should always be our
    top priority.

    I would anticipate wider participation in validating 0.94.1 this time.
    To my knowledge, Cloudera, Huawei and Taobao have all been actively testing
    0.94 builds for some time. That was why critical issues were raised.
    This should have laid better foundation for the release of 0.94.1

    Cheers
    On Mon, Jul 9, 2012 at 5:43 PM, Andrew Purtell wrote:

    Ted,

    Please explain in more detail why 0.94.0 was not a stable release. And
    what about 0.94.1 is different that it should be considered stable now? And
    since 0.94.0 was, as you contend, an unstable release, how did it get by
    the RC process and what can we do to improve the RC process so that does
    not happen again? Thanks.

    - Andy
    On Jul 9, 2012, at 5:04 PM, Ted Yu wrote:

    0.94.0 was not a stable release.
    I hope 0.94.1 would be stable. My rationale was that deprecating current
    metric classes in the first stable release of 0.94 should be acceptable.

    I would humbly listen to other people's opinions, of course.

    Cheers
    On Mon, Jul 9, 2012 at 4:46 PM, lars hofhansl wrote:

    0.94 is already out and did not have these deprecated. So deprecating
    them
    now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?

    Lastly, I don't think we need to deprecate now in order in remove in
    0.96.

    Thanks.

    -- Lars



    ----- Original Message -----
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 4:38 PM
    Subject: Re: HBase 0.94.1

    If possible, can you wait for the poll on metrics2 framework to close ?
    If the poll passes, 0.94.1 RC would carry deprecation for (old) metric
    classes.

    Thanks
    On Mon, Jul 9, 2012 at 4:07 PM, lars hofhansl wrote:

    That's great, thanks for setting this up Roman!


    There're only three issues left against 0.94.1.
    I want to push it out quickly because of HBASE-6311.

    I am 90% sure there'll be a first RC this week.

    -- Lars



    ----- Original Message -----
    From: Roman Shaposhnik <rvs@apache.org>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 8:35 AM
    Subject: Re: HBase 0.94.1

    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some, fixed
    some others.
    There're still 13 Major and 1 Minor issue left. Please look through
    the
    issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94
    release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be validating
    RCs.

    Thanks,
    Roman.
  • Ted Yu at Jul 10, 2012 at 8:56 am
    bq. can you file a jira w/ patch in the next two days?

    Sure. I sent out request to close the poll early in another email thread.
    I will start preparing a patch today and am planning to run the test suite.
    If I don't get objection in the other thread, I will create the JIRA early
    Wednesday.

    Lastly I want to apologize for the misunderstanding my previous email might
    have caused.

    0.94.0 contains performance improvements no other releases have offered. I
    am positive on the prosperity of future 0.94 releases.

    Cheers
    On Mon, Jul 9, 2012 at 9:15 PM, lars hofhansl wrote:

    Whether 0.94.0 was stable or not is orthorgonal to whether an API can be
    deprecated in a point release or not, no?

    Since we appear to have critical mass of support to do that, can you file
    a jira w/ patch in the next two days?
    Holding up an 0.94.1RC to deprecate the old metric system seems
    counterproductive.

    Lastly, please refrain from personal attacks like the ones below. We're
    all doing our best to get HBase to the most stable point.


    -- Lars
    ________________________________
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org
    Sent: Monday, July 9, 2012 6:09 PM
    Subject: Re: HBase 0.94.1

    Andy:
    Good questions.

    The fact that HBASE-6311 is deemed by Lars to be an important fix adds
    support for my reasoning.

    I read the posts under 'ANN: The third hbase 0.94.0 release candidate is
    available for download' again.

    There was discussion on 'Dictionary WAL compression making replication not
    functional' which later was marked as experimental.
    This message from LarsH on May 13th is notable:

    'If there are no -1's by Wed, May 16th, I'll release RC4 as 0.94.0.'

    To answer the last question below, I think we should allow ample time for
    HBase users to try out the RC before declaration of the release.
    We're building something that one day would take away significant chunk of
    market share from traditional RDBMS vendors. Quality should always be our
    top priority.

    I would anticipate wider participation in validating 0.94.1 this time.
    To my knowledge, Cloudera, Huawei and Taobao have all been actively testing
    0.94 builds for some time. That was why critical issues were raised.
    This should have laid better foundation for the release of 0.94.1

    Cheers

    On Mon, Jul 9, 2012 at 5:43 PM, Andrew Purtell <andrew.purtell@gmail.com
    wrote:
    Ted,

    Please explain in more detail why 0.94.0 was not a stable release. And
    what about 0.94.1 is different that it should be considered stable now? And
    since 0.94.0 was, as you contend, an unstable release, how did it get by
    the RC process and what can we do to improve the RC process so that does
    not happen again? Thanks.

    - Andy
    On Jul 9, 2012, at 5:04 PM, Ted Yu wrote:

    0.94.0 was not a stable release.
    I hope 0.94.1 would be stable. My rationale was that deprecating
    current
    metric classes in the first stable release of 0.94 should be
    acceptable.
    I would humbly listen to other people's opinions, of course.

    Cheers

    On Mon, Jul 9, 2012 at 4:46 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    0.94 is already out and did not have these deprecated. So deprecating
    them
    now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If
    push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?

    Lastly, I don't think we need to deprecate now in order in remove in
    0.96.

    Thanks.

    -- Lars



    ----- Original Message -----
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 4:38 PM
    Subject: Re: HBase 0.94.1

    If possible, can you wait for the poll on metrics2 framework to close
    ?
    If the poll passes, 0.94.1 RC would carry deprecation for (old) metric
    classes.

    Thanks

    On Mon, Jul 9, 2012 at 4:07 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    That's great, thanks for setting this up Roman!


    There're only three issues left against 0.94.1.
    I want to push it out quickly because of HBASE-6311.

    I am 90% sure there'll be a first RC this week.

    -- Lars



    ----- Original Message -----
    From: Roman Shaposhnik <rvs@apache.org>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Cc:
    Sent: Monday, July 9, 2012 8:35 AM
    Subject: Re: HBase 0.94.1

    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some,
    fixed
    some others.
    There're still 13 Major and 1 Minor issue left. Please look through
    the
    issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94
    release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).
    Question: what's the likelihood of 0.94.1 release within next couple
    of weeks? We hooked it up to the trunk of Bigtop and will be
    validating
    RCs.

    Thanks,
    Roman.
  • Michael Stack at Jul 10, 2012 at 4:34 pm

    On Tue, Jul 10, 2012 at 2:04 AM, Ted Yu wrote:
    0.94.0 was not a stable release.
    The 0.94.0 is as 'stable' as any of our .0 releases have been.
    I hope 0.94.1 would be stable. My rationale was that deprecating current
    metric classes in the first stable release of 0.94 should be acceptable.
    An argument that we can deprecate in a point release because the .0 is
    not 'stable' -- or because a bad bug was found subsequent to release
    -- isn't one.

    St.Ack
  • Michael Stack at Jul 10, 2012 at 4:24 pm

    On Tue, Jul 10, 2012 at 1:46 AM, lars hofhansl wrote:
    0.94 is already out and did not have these deprecated. So deprecating them now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If push comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?
    In the past, we'd remove public APIs after deprecating them across a
    full major release: i.e. we'd deprecate something we want to remove in
    0.96.0 in 0.94.0 (not 0.94.1). Are the metrics changes to public
    "stable" APIs? If so, I'd ask why change our convention now? If
    they are "evolving", we might bend the rules.

    Regards, what goes into 0.94.1, its up to the release manager. They
    can entertain petitions regards what to include but ultimately its up
    to the RM when it happens and what is in it.

    St.Ack
  • Ted Yu at Jul 10, 2012 at 4:57 pm
    There is no annotation declaring whether the current metrics are stable API:

    public class MetricsHistogram extends MetricsBase {

    LarsH has endorsed marking the current metrics classes deprecated in his
    later reply to this thread.

    Correct me if my interpretation is wrong.
    On Tue, Jul 10, 2012 at 9:23 AM, Stack wrote:
    On Tue, Jul 10, 2012 at 1:46 AM, lars hofhansl wrote:
    0.94 is already out and did not have these deprecated. So deprecating
    them now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?
    In the past, we'd remove public APIs after deprecating them across a
    full major release: i.e. we'd deprecate something we want to remove in
    0.96.0 in 0.94.0 (not 0.94.1). Are the metrics changes to public
    "stable" APIs? If so, I'd ask why change our convention now? If
    they are "evolving", we might bend the rules.

    Regards, what goes into 0.94.1, its up to the release manager. They
    can entertain petitions regards what to include but ultimately its up
    to the RM when it happens and what is in it.

    St.Ack
  • Todd Lipcon at Jul 10, 2012 at 5:14 pm
    I think there's an important distinction between the Java API of
    metrics, and the implicit interface that the metrics themselves
    expose. IMO, we can completely change the implementation of metrics
    (e.g. class names and java APIs) so long as the actual names of the
    metrics exposed are kept consistent. If we make a change there, we
    should provide a deprecation path if at all possible - otherwise we
    need a big warning on upgrade so that operators know what they're
    getting themselves into.

    -Todd
    On Tue, Jul 10, 2012 at 9:57 AM, Ted Yu wrote:
    There is no annotation declaring whether the current metrics are stable API:

    public class MetricsHistogram extends MetricsBase {

    LarsH has endorsed marking the current metrics classes deprecated in his
    later reply to this thread.

    Correct me if my interpretation is wrong.
    On Tue, Jul 10, 2012 at 9:23 AM, Stack wrote:

    On Tue, Jul 10, 2012 at 1:46 AM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    0.94 is already out and did not have these deprecated. So deprecating
    them now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?
    In the past, we'd remove public APIs after deprecating them across a
    full major release: i.e. we'd deprecate something we want to remove in
    0.96.0 in 0.94.0 (not 0.94.1). Are the metrics changes to public
    "stable" APIs? If so, I'd ask why change our convention now? If
    they are "evolving", we might bend the rules.

    Regards, what goes into 0.94.1, its up to the release manager. They
    can entertain petitions regards what to include but ultimately its up
    to the RM when it happens and what is in it.

    St.Ack


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Ted Yu at Jul 10, 2012 at 5:32 pm
    Todd brought up a good point.

    MetricsBase class only exists in old metrics framework but not metrics2
    framework.
    So I am not sure whether the actual names of (all) the metrics exposed
    would be kept consistent.

    Since MetricsHistogram, etc, are public, we do need to deprecate them in
    0.94 in case some users extend these classes.

    Would listen to metrics experts' comments.
    On Tue, Jul 10, 2012 at 10:14 AM, Todd Lipcon wrote:

    I think there's an important distinction between the Java API of
    metrics, and the implicit interface that the metrics themselves
    expose. IMO, we can completely change the implementation of metrics
    (e.g. class names and java APIs) so long as the actual names of the
    metrics exposed are kept consistent. If we make a change there, we
    should provide a deprecation path if at all possible - otherwise we
    need a big warning on upgrade so that operators know what they're
    getting themselves into.

    -Todd
    On Tue, Jul 10, 2012 at 9:57 AM, Ted Yu wrote:
    There is no annotation declaring whether the current metrics are stable API:
    public class MetricsHistogram extends MetricsBase {

    LarsH has endorsed marking the current metrics classes deprecated in his
    later reply to this thread.

    Correct me if my interpretation is wrong.
    On Tue, Jul 10, 2012 at 9:23 AM, Stack wrote:

    On Tue, Jul 10, 2012 at 1:46 AM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    0.94 is already out and did not have these deprecated. So deprecating
    them now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If
    push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?
    In the past, we'd remove public APIs after deprecating them across a
    full major release: i.e. we'd deprecate something we want to remove in
    0.96.0 in 0.94.0 (not 0.94.1). Are the metrics changes to public
    "stable" APIs? If so, I'd ask why change our convention now? If
    they are "evolving", we might bend the rules.

    Regards, what goes into 0.94.1, its up to the release manager. They
    can entertain petitions regards what to include but ultimately its up
    to the RM when it happens and what is in it.

    St.Ack


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Todd Lipcon at Jul 10, 2012 at 5:35 pm
    I don't think we should be concerned with people directly extending
    the various metrics classes. They're not meant to be a "user API" IMO.
    We should annotate them as private. But the external-facing interface
    (ie the JMX output) should be treated as an interface.

    If we have to break them at some point without a deprecation path, +1
    for doing so in 0.96.
    On Tue, Jul 10, 2012 at 10:32 AM, Ted Yu wrote:
    Todd brought up a good point.

    MetricsBase class only exists in old metrics framework but not metrics2
    framework.
    So I am not sure whether the actual names of (all) the metrics exposed
    would be kept consistent.

    Since MetricsHistogram, etc, are public, we do need to deprecate them in
    0.94 in case some users extend these classes.

    Would listen to metrics experts' comments.
    On Tue, Jul 10, 2012 at 10:14 AM, Todd Lipcon wrote:

    I think there's an important distinction between the Java API of
    metrics, and the implicit interface that the metrics themselves
    expose. IMO, we can completely change the implementation of metrics
    (e.g. class names and java APIs) so long as the actual names of the
    metrics exposed are kept consistent. If we make a change there, we
    should provide a deprecation path if at all possible - otherwise we
    need a big warning on upgrade so that operators know what they're
    getting themselves into.

    -Todd
    On Tue, Jul 10, 2012 at 9:57 AM, Ted Yu wrote:
    There is no annotation declaring whether the current metrics are stable API:
    public class MetricsHistogram extends MetricsBase {

    LarsH has endorsed marking the current metrics classes deprecated in his
    later reply to this thread.

    Correct me if my interpretation is wrong.
    On Tue, Jul 10, 2012 at 9:23 AM, Stack wrote:

    On Tue, Jul 10, 2012 at 1:46 AM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    0.94 is already out and did not have these deprecated. So deprecating
    them now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If
    push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?
    In the past, we'd remove public APIs after deprecating them across a
    full major release: i.e. we'd deprecate something we want to remove in
    0.96.0 in 0.94.0 (not 0.94.1). Are the metrics changes to public
    "stable" APIs? If so, I'd ask why change our convention now? If
    they are "evolving", we might bend the rules.

    Regards, what goes into 0.94.1, its up to the release manager. They
    can entertain petitions regards what to include but ultimately its up
    to the RM when it happens and what is in it.

    St.Ack


    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Ted Yu at Jul 10, 2012 at 5:50 pm
    Please take a look at my tentative patch on HBASE-6365 and provide your
    feedback.

    Cheers
    On Tue, Jul 10, 2012 at 10:34 AM, Todd Lipcon wrote:

    I don't think we should be concerned with people directly extending
    the various metrics classes. They're not meant to be a "user API" IMO.
    We should annotate them as private. But the external-facing interface
    (ie the JMX output) should be treated as an interface.

    If we have to break them at some point without a deprecation path, +1
    for doing so in 0.96.
    On Tue, Jul 10, 2012 at 10:32 AM, Ted Yu wrote:
    Todd brought up a good point.

    MetricsBase class only exists in old metrics framework but not metrics2
    framework.
    So I am not sure whether the actual names of (all) the metrics exposed
    would be kept consistent.

    Since MetricsHistogram, etc, are public, we do need to deprecate them in
    0.94 in case some users extend these classes.

    Would listen to metrics experts' comments.
    On Tue, Jul 10, 2012 at 10:14 AM, Todd Lipcon wrote:

    I think there's an important distinction between the Java API of
    metrics, and the implicit interface that the metrics themselves
    expose. IMO, we can completely change the implementation of metrics
    (e.g. class names and java APIs) so long as the actual names of the
    metrics exposed are kept consistent. If we make a change there, we
    should provide a deprecation path if at all possible - otherwise we
    need a big warning on upgrade so that operators know what they're
    getting themselves into.

    -Todd
    On Tue, Jul 10, 2012 at 9:57 AM, Ted Yu wrote:
    There is no annotation declaring whether the current metrics are
    stable
    API:
    public class MetricsHistogram extends MetricsBase {

    LarsH has endorsed marking the current metrics classes deprecated in
    his
    later reply to this thread.

    Correct me if my interpretation is wrong.
    On Tue, Jul 10, 2012 at 9:23 AM, Stack wrote:

    On Tue, Jul 10, 2012 at 1:46 AM, lars hofhansl <lhofhansl@yahoo.com>
    wrote:
    0.94 is already out and did not have these deprecated. So
    deprecating
    them now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon. If
    push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?
    In the past, we'd remove public APIs after deprecating them across a
    full major release: i.e. we'd deprecate something we want to remove
    in
    0.96.0 in 0.94.0 (not 0.94.1). Are the metrics changes to public
    "stable" APIs? If so, I'd ask why change our convention now? If
    they are "evolving", we might bend the rules.

    Regards, what goes into 0.94.1, its up to the release manager. They
    can entertain petitions regards what to include but ultimately its up
    to the RM when it happens and what is in it.

    St.Ack


    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Elliott Clark at Jul 10, 2012 at 6:20 pm
    Metrics2 does place things in different jmx locations from metrics, so when
    we move over it will be a bigger deal for ops. We should do this in the
    singularity if it all possible.

    One possibility is that the classes in org.apache.hadoop.hbase.metrics can
    be deprecated in 94.1 and we can follow hadoop's lead and make a metrics2
    package in 0.96.


    - Deprecate PersistentMetricsTimeVaryingRate, MetricsString,
    ExactCounterMetric, MetricsHistogram
    in 0.94.1
    - These are currently public with no annotation
    - I can actually see people using the MetricsHistogram
    and PersistentMetricsTimeVaryingRate in external code.
    - Remove PersistentMetricsTimeVaryingRate, MetricsString,
    ExactCounterMetric, MetricsHistogram in
    0.98
    - Deprecate OperationMetrics, RegionServerDynamicMetrics, MasterMetrics,
    et al.
    - These are classes that actually wire our code up to the
    metrics infrastructure and publish numbers
    - There doesn't seem like all that much chance that people are using
    these classes in external code.
    - Remove OperationMetrics, RegionServerDynamicMetrics, MasterMetrics in
    0.96.0
    - Since these are very likely to be internal only removing in 0.96.0
    seems low impact.
    - In 0.96.0 create an org.apache.hadoop.hbase.metrics2 containing any
    needed Metric2 classes.
    - in 0.96.0 create replacement classes for publishing metrics to the
    metrics2 hadoop infra


    For my money that seems like a pretty safe path. Thoughts ?
    On Tue, Jul 10, 2012 at 10:50 AM, Ted Yu wrote:

    Please take a look at my tentative patch on HBASE-6365 and provide your
    feedback.

    Cheers
    On Tue, Jul 10, 2012 at 10:34 AM, Todd Lipcon wrote:

    I don't think we should be concerned with people directly extending
    the various metrics classes. They're not meant to be a "user API" IMO.
    We should annotate them as private. But the external-facing interface
    (ie the JMX output) should be treated as an interface.

    If we have to break them at some point without a deprecation path, +1
    for doing so in 0.96.
    On Tue, Jul 10, 2012 at 10:32 AM, Ted Yu wrote:
    Todd brought up a good point.

    MetricsBase class only exists in old metrics framework but not metrics2
    framework.
    So I am not sure whether the actual names of (all) the metrics exposed
    would be kept consistent.

    Since MetricsHistogram, etc, are public, we do need to deprecate them
    in
    0.94 in case some users extend these classes.

    Would listen to metrics experts' comments.
    On Tue, Jul 10, 2012 at 10:14 AM, Todd Lipcon wrote:

    I think there's an important distinction between the Java API of
    metrics, and the implicit interface that the metrics themselves
    expose. IMO, we can completely change the implementation of metrics
    (e.g. class names and java APIs) so long as the actual names of the
    metrics exposed are kept consistent. If we make a change there, we
    should provide a deprecation path if at all possible - otherwise we
    need a big warning on upgrade so that operators know what they're
    getting themselves into.

    -Todd
    On Tue, Jul 10, 2012 at 9:57 AM, Ted Yu wrote:
    There is no annotation declaring whether the current metrics are
    stable
    API:
    public class MetricsHistogram extends MetricsBase {

    LarsH has endorsed marking the current metrics classes deprecated in
    his
    later reply to this thread.

    Correct me if my interpretation is wrong.
    On Tue, Jul 10, 2012 at 9:23 AM, Stack wrote:

    On Tue, Jul 10, 2012 at 1:46 AM, lars hofhansl <
    lhofhansl@yahoo.com>
    wrote:
    0.94 is already out and did not have these deprecated. So
    deprecating
    them now in a point release is a bit strange.
    Not -1'ing it, just raising that thought here.

    As said below because of HBASE-6311 0.94.1 should get out soon.
    If
    push
    comes to shuff are folks ok with:
    1. deprecating in a point release
    2. maybe doing that in 0.94.2
    ?
    In the past, we'd remove public APIs after deprecating them across
    a
    full major release: i.e. we'd deprecate something we want to remove
    in
    0.96.0 in 0.94.0 (not 0.94.1). Are the metrics changes to public
    "stable" APIs? If so, I'd ask why change our convention now? If
    they are "evolving", we might bend the rules.

    Regards, what goes into 0.94.1, its up to the release manager.
    They
    can entertain petitions regards what to include but ultimately its
    up
    to the RM when it happens and what is in it.

    St.Ack


    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Ted Yu at Jul 10, 2012 at 4:00 am
    I think HBASE-6284 should go to 0.94.1
    It provides batching for Puts and Deletes. This is an important speedup and
    was requested by some users.

    Thanks
    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl wrote:

    Hi All,

    I did a pass through all issues against 0.94.1, retargeted some, fixed
    some others.
    There're still 13 Major and 1 Minor issue left. Please look through the
    issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94
    release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).

    Obviously we'll fix the Blocker/Critical issues before the next release.

    Thanks.

    -- Lars
  • Lars hofhansl at Jul 10, 2012 at 4:18 am
    Ted, you talk about the necessity of stable releases and then you keep adding delay to the release of 0.94.1 which has an important fix it.



    ________________________________
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    Sent: Monday, July 9, 2012 8:59 PM
    Subject: Re: HBase 0.94.1


    I think HBASE-6284 should go to 0.94.1
    It provides batching for Puts and Deletes. This is an important speedup and was requested by some users.

    Thanks


    On Thu, Jul 5, 2012 at 5:36 PM, lars hofhansl wrote:

    Hi All,
    I did a pass through all issues against 0.94.1, retargeted some, fixed some others.
    There're still 13 Major and 1 Minor issue left. Please look through the issue that you have filed (or are working on),
    and make a call whether you want this should hold up the next 0.94 release. If not, please retarget to 0.94.2
    (Or mail me offline if you have questions).

    Obviously we'll fix the Blocker/Critical issues before the next release.

    Thanks.

    -- Lars

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categorieshbase, hadoop
postedJul 6, '12 at 12:36a
activeJul 10, '12 at 6:20p
posts27
users10
websitehbase.apache.org

People

Translate

site design / logo © 2022 Grokbase