hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: deprecating (old) metrics in favor of metrics2 framework
Date Tue, 10 Jul 2012 23:14:12 GMT
Thanks for sharing this, Elliot.

7734 is marked blocked by HADOOP-7742: Evolve metrics2 in 0.23 and trunk to
allow coexistence with 0.20-security releases

On Tue, Jul 10, 2012 at 3:33 PM, Elliott Clark <eclark@stumbleupon.com>wrote:

> https://issues.apache.org/jira/browse/HADOOP-7734
>
> As far as I can tell this basically sinks all Metrics2 usage in HBase.
>
> On Tue, Jul 10, 2012 at 3:24 PM, Alex Baranau <alex.baranov.v@gmail.com
> >wrote:
>
> > > If there's considerable pain or overhead in having both
> > > implementations live in parallel, maybe it's worth doing a straight
> > > switch over in 0.96.
> >
> > As far as I can tell, they can live together easily. This should not be a
> > big issue. E.g. it should be much smaller issue than the fact that code
> > implemented on top of metrics2 will not compile against 1.0+, 2.0+ and
> 3.0+
> > hadoop at the same time because class names, etc. changed between 1.0 and
> > 2.0. But that's a separate story, will look at it tomorrow (Ted pointed
> me
> > to smth to look at).
> >
> > Alex Baranau
> >
> > On Tue, Jul 10, 2012 at 5:03 PM, Ted Yu <yuzhihong@gmail.com> wrote:
> >
> > > Points taken.
> > >
> > > Thanks for the education of metrics framework history.
> > >
> > > On Tue, Jul 10, 2012 at 1:55 PM, Gary Helmling <ghelmling@gmail.com>
> > > wrote:
> > >
> > > > I agree that having a new metrics2 implementation in 0.96 would be
> > > > great to see and seems like a natural fit.  I'm 100% for that.  But I
> > > > do think that having metrics2 and (deprecated) metrics v1 in the same
> > > > release would be very helpful to users making the transition.  So to
> > > > me it seems more natural for 0.96 to be that release with both
> > > > implementations, since that's where it seems like the metrics2
> > > > implementation will land.
> > > >
> > > > Otherwise it seems like we risk introducing the same disruptions that
> > > > Hadoop did when metrics2 initially replaced the metrics v1
> > > > implementation, instead of living along side.  This did cause us as a
> > > > project some trouble until metrics v1 was added back in.  So it would
> > > > be unfortunate to repeat the same mistake ourselves.
> > > >
> > > > If there's considerable pain or overhead in having both
> > > > implementations live in parallel, maybe it's worth doing a straight
> > > > switch over in 0.96.  I haven't looked at the differences enough
> > > > myself to know.  But otherwise it seems like an easier migration path
> > > > to deprecate v1 in 0.96 and remove the release after.
> > > >
> > > >
> > > > On Tue, Jul 10, 2012 at 1:35 PM, Ted Yu <yuzhihong@gmail.com> wrote:
> > > > > Gary:
> > > > > Your comment makes sense.
> > > > >
> > > > > Part of this poll originates from the fact that 0.96 is our
> > singularity
> > > > > release. RPC, coprocessor, etc have undergone considerable changes.
> > > > > Users migrating to 0.96 would have to deal with a lot of updates
in
> > > their
> > > > > codebase.
> > > > >
> > > > > It seems to me that doing all upgrades in one shot is almost the
> same
> > > as
> > > > > upgrading components other than metrics framework.
> > > > >
> > > > > Cheers
> > > > >
> > > > > On Tue, Jul 10, 2012 at 1:29 PM, Gary Helmling <
> ghelmling@gmail.com>
> > > > wrote:
> > > > >
> > > > >> >
> > > > >> > Whether we support 2 (actually more than 2) metrics frameworks
> in
> > > 0.96
> > > > >> can
> > > > >> > be debated in the next 2 months.
> > > > >> >
> > > > >>
> > > > >> I'm not sure I agree that deprecating without having something
in
> > > > >> place for users to move to makes sense.
> > > > >>
> > > > >> > As Todd mentioned in the thread 'HBase 0.94.1', we will
try our
> > best
> > > > to
> > > > >> > keep JMX interface the same across 0.94 and 0.96. Does this
> > somehow
> > > > >> reduce
> > > > >> > the concern you raised ?
> > > > >> >
> > > > >>
> > > > >> I think that maintaining consistency with the existing JMX naming
> > > > >> conventions (to the extent possible) is important for operational
> > > > >> concerns, but it's independent of the MetricsContext question
and
> > the
> > > > >> question of whether other metrics classes of our own need a proper
> > > > >> deprecation cycle.
> > > > >>
> > > > >> > As for using MetricsContext, I assume the user also uses
hadoop
> in
> > > > his /
> > > > >> > her deployment. Then he / she should be aware of the deprecation
> > of
> > > > >> > metrics.* classes in both hadoop 1.0 and 2.0
> > > > >> > Meaning he / she should be prepared to endorse metrics2
> framework.
> > > > >> >
> > > > >>
> > > > >> Hadoop deprecating metrics in favor of metrics2 is independent
of
> us
> > > > >> deprecating HBase metrics classes.  TimeStampingFileContext is
one
> > > > >> MetricsContext implementation in HBase that would need to be
> > > > >> deprecated and could be used or possibly extended by current
> users.
> > > > >>
> > > > >> Ultimately it's up to Lars H as RM for 0.94 to decide what he
> wants
> > to
> > > > >> include.  It just feels to me like we're rushing to deprecate
> > metrics
> > > > >> in 0.94 so that it can be removed in 0.96, instead of what seems
> to
> > me
> > > > >> like the more standard path of deprecating metrics in 0.96, while
> > also
> > > > >> including new metrics2 implementations, which would give users
a
> > > > >> smoother path to actually switch over.  I'm just not sure I
> > understand
> > > > >> the motivation for deprecating in 0.94 instead of 0.96.
> > > > >>
> > > >
> > >
> >
>

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