Re: IMPORTANT: automatic changelog creation

[Varun Vasudev]

+1

Many thanks to Allen and Andrew for driving this.

-Varun



On 7/3/15, 10:25 AM, "Vinayakumar B"  wrote:

>+1 for the auto generation.
>
>bq. Besides, after a release R1 is out, someone may (accidentally or
>intentionally) modify the JIRA summary.
>Is there any possibility that, we can restrict someone from editing the
>issue in jira once its marked as "closed" after release?
>
>Regards,
>Vinay
>
>On Fri, Jul 3, 2015 at 8:32 AM, Karthik Kambatla  wrote:
>
>> Huge +1
>>
>> On Thursday, July 2, 2015, Chris Nauroth  wrote:
>>
>> > +1
>> >
>> > Thank you to Allen for the script, and thank you to Andrew for
>> > volunteering to drive the conversion.
>> >
>> > --Chris Nauroth
>> >
>> >
>> >
>> >
>> > On 7/2/15, 2:01 PM, "Andrew Wang" > >
>> > wrote:
>> >
>> > >Hi all,
>> > >
>> > >I want to revive the discussion on this thread, since the overhead of
>> > >CHANGES.txt came up again in the context of backporting fixes for
>> > >maintenance releases.
>> > >
>> > >Allen's automatic generation script (HADOOP-11731) went into trunk but
>> not
>> > >branch-2, so we're still maintaining CHANGES.txt everywhere. What do
>> > >people
>> > >think about backporting this to branch-2 and then removing CHANGES.txt
>> > >from
>> > >trunk/branch-2 (HADOOP-11792)? Based on discussion on this thread and in
>> > >HADOOP-11731, we seem to agree that CHANGES.txt is an unreliable source
>> of
>> > >information, and JIRA is at least as reliable and probably much more so.
>> > >Thus I don't see any downsides to backporting it.
>> > >
>> > >Would like to hear everyone's thoughts on this, I'm willing to drive the
>> > >effort.
>> > >
>> > >Thanks,
>> > >Andrew
>> > >
>> > >On Thu, Apr 2, 2015 at 2:00 PM, Tsz Wo Sze 
>> > >wrote:
>> > >
>> > >> Generating change log from JIRA is a good idea.  It bases on an
>> > >>assumption
>> > >> that each JIRA has an accurate summary (a.k.a. JIRA title) to reflect
>> > >>the
>> > >> committed change. Unfortunately, the assumption is invalid for many
>> > >>cases
>> > >> since we never enforce that the JIRA summary must be the same as the
>> > >>change
>> > >> log.  We may compare the current CHANGES.txt with the generated change
>> > >> log.  I beg the diff is long.
>> > >> Besides, after a release R1 is out, someone may (accidentally or
>> > >> intentionally) modify the JIRA summary.  Then, the entry for the same
>> > >>item
>> > >> in a later release R2 could be different from the one in R1.
>> > >> I agree that manually editing CHANGES.txt is not a perfect solution.
>> > >> However, it works well in the past for many releases.  I suggest we
>> keep
>> > >> the current dev workflow.  Try using the new script provided by
>> > >> HADOOP-11731 to generate the next release.  If everything works well,
>> we
>> > >> shell remove CHANGES.txt and revise the dev workflow.  What do you
>> > >>think?
>> > >> Regards,Tsz-Wo
>> > >>
>> > >>
>> > >>  On Thursday, April 2, 2015 12:57 PM, Allen Wittenauer <
>> > >> a...@altiscale.com > wrote:
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli <
>> > >> vino...@hortonworks.com > wrote:
>> > >>
>> > >> >
>> > >> > We'd then doing two commits for every patch. Let's simply not remove
>> > >> CHANGES.txt from trunk, keep the existing dev workflow, but doc the
>> > >>release
>> > >> process to remove CHANGES.txt in trunk at the time of a release going
>> > >>out
>> > >> of trunk.
>> > >>
>> > >>
>> > >>
>> > >> Might as well copy branch-2¹s changes.txt into trunk then. (or 2.7¹s.
>> > >> Last I looked, people updated branch-2 and not 2.7¹s or vice versa for
>> > >>some
>> > >> patches that went into both branches.)  So that folks who are
>> > >>committing to
>> > >> both branches and want to cherry pick all changes can.
>> > >>
>> > >> I mean, trunk¹s is very very very wrong. Right now. Today. Borderline
>> > >> useless. See HADOOP-11718 (which I will now close out as won¹t fix)Š
>> and
>> > >> that jira is only what is miscategorized, not what is missing.
>> > >>
>> > >>
>> > >>
>> > >>
>> >
>> >
>>
>> --
>> Mobile
>>

Re: IMPORTANT: automatic changelog creation

[Vinayakumar B]

+1 for the auto generation.

bq. Besides, after a release R1 is out, someone may (accidentally or
intentionally) modify the JIRA summary.
Is there any possibility that, we can restrict someone from editing the
issue in jira once its marked as "closed" after release?

Regards,
Vinay

On Fri, Jul 3, 2015 at 8:32 AM, Karthik Kambatla  wrote:

> Huge +1
>
> On Thursday, July 2, 2015, Chris Nauroth  wrote:
>
> > +1
> >
> > Thank you to Allen for the script, and thank you to Andrew for
> > volunteering to drive the conversion.
> >
> > --Chris Nauroth
> >
> >
> >
> >
> > On 7/2/15, 2:01 PM, "Andrew Wang"  >
> > wrote:
> >
> > >Hi all,
> > >
> > >I want to revive the discussion on this thread, since the overhead of
> > >CHANGES.txt came up again in the context of backporting fixes for
> > >maintenance releases.
> > >
> > >Allen's automatic generation script (HADOOP-11731) went into trunk but
> not
> > >branch-2, so we're still maintaining CHANGES.txt everywhere. What do
> > >people
> > >think about backporting this to branch-2 and then removing CHANGES.txt
> > >from
> > >trunk/branch-2 (HADOOP-11792)? Based on discussion on this thread and in
> > >HADOOP-11731, we seem to agree that CHANGES.txt is an unreliable source
> of
> > >information, and JIRA is at least as reliable and probably much more so.
> > >Thus I don't see any downsides to backporting it.
> > >
> > >Would like to hear everyone's thoughts on this, I'm willing to drive the
> > >effort.
> > >
> > >Thanks,
> > >Andrew
> > >
> > >On Thu, Apr 2, 2015 at 2:00 PM, Tsz Wo Sze 
> > >wrote:
> > >
> > >> Generating change log from JIRA is a good idea.  It bases on an
> > >>assumption
> > >> that each JIRA has an accurate summary (a.k.a. JIRA title) to reflect
> > >>the
> > >> committed change. Unfortunately, the assumption is invalid for many
> > >>cases
> > >> since we never enforce that the JIRA summary must be the same as the
> > >>change
> > >> log.  We may compare the current CHANGES.txt with the generated change
> > >> log.  I beg the diff is long.
> > >> Besides, after a release R1 is out, someone may (accidentally or
> > >> intentionally) modify the JIRA summary.  Then, the entry for the same
> > >>item
> > >> in a later release R2 could be different from the one in R1.
> > >> I agree that manually editing CHANGES.txt is not a perfect solution.
> > >> However, it works well in the past for many releases.  I suggest we
> keep
> > >> the current dev workflow.  Try using the new script provided by
> > >> HADOOP-11731 to generate the next release.  If everything works well,
> we
> > >> shell remove CHANGES.txt and revise the dev workflow.  What do you
> > >>think?
> > >> Regards,Tsz-Wo
> > >>
> > >>
> > >>  On Thursday, April 2, 2015 12:57 PM, Allen Wittenauer <
> > >> a...@altiscale.com > wrote:
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli <
> > >> vino...@hortonworks.com > wrote:
> > >>
> > >> >
> > >> > We'd then doing two commits for every patch. Let's simply not remove
> > >> CHANGES.txt from trunk, keep the existing dev workflow, but doc the
> > >>release
> > >> process to remove CHANGES.txt in trunk at the time of a release going
> > >>out
> > >> of trunk.
> > >>
> > >>
> > >>
> > >> Might as well copy branch-2¹s changes.txt into trunk then. (or 2.7¹s.
> > >> Last I looked, people updated branch-2 and not 2.7¹s or vice versa for
> > >>some
> > >> patches that went into both branches.)  So that folks who are
> > >>committing to
> > >> both branches and want to cherry pick all changes can.
> > >>
> > >> I mean, trunk¹s is very very very wrong. Right now. Today. Borderline
> > >> useless. See HADOOP-11718 (which I will now close out as won¹t fix)Š
> and
> > >> that jira is only what is miscategorized, not what is missing.
> > >>
> > >>
> > >>
> > >>
> >
> >
>
> --
> Mobile
>

Re: IMPORTANT: automatic changelog creation

[Karthik Kambatla]

Huge +1

On Thursday, July 2, 2015, Chris Nauroth  wrote:

> +1
>
> Thank you to Allen for the script, and thank you to Andrew for
> volunteering to drive the conversion.
>
> --Chris Nauroth
>
>
>
>
> On 7/2/15, 2:01 PM, "Andrew Wang" >
> wrote:
>
> >Hi all,
> >
> >I want to revive the discussion on this thread, since the overhead of
> >CHANGES.txt came up again in the context of backporting fixes for
> >maintenance releases.
> >
> >Allen's automatic generation script (HADOOP-11731) went into trunk but not
> >branch-2, so we're still maintaining CHANGES.txt everywhere. What do
> >people
> >think about backporting this to branch-2 and then removing CHANGES.txt
> >from
> >trunk/branch-2 (HADOOP-11792)? Based on discussion on this thread and in
> >HADOOP-11731, we seem to agree that CHANGES.txt is an unreliable source of
> >information, and JIRA is at least as reliable and probably much more so.
> >Thus I don't see any downsides to backporting it.
> >
> >Would like to hear everyone's thoughts on this, I'm willing to drive the
> >effort.
> >
> >Thanks,
> >Andrew
> >
> >On Thu, Apr 2, 2015 at 2:00 PM, Tsz Wo Sze 
> >wrote:
> >
> >> Generating change log from JIRA is a good idea.  It bases on an
> >>assumption
> >> that each JIRA has an accurate summary (a.k.a. JIRA title) to reflect
> >>the
> >> committed change. Unfortunately, the assumption is invalid for many
> >>cases
> >> since we never enforce that the JIRA summary must be the same as the
> >>change
> >> log.  We may compare the current CHANGES.txt with the generated change
> >> log.  I beg the diff is long.
> >> Besides, after a release R1 is out, someone may (accidentally or
> >> intentionally) modify the JIRA summary.  Then, the entry for the same
> >>item
> >> in a later release R2 could be different from the one in R1.
> >> I agree that manually editing CHANGES.txt is not a perfect solution.
> >> However, it works well in the past for many releases.  I suggest we keep
> >> the current dev workflow.  Try using the new script provided by
> >> HADOOP-11731 to generate the next release.  If everything works well, we
> >> shell remove CHANGES.txt and revise the dev workflow.  What do you
> >>think?
> >> Regards,Tsz-Wo
> >>
> >>
> >>  On Thursday, April 2, 2015 12:57 PM, Allen Wittenauer <
> >> a...@altiscale.com > wrote:
> >>
> >>
> >>
> >>
> >>
> >> On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli <
> >> vino...@hortonworks.com > wrote:
> >>
> >> >
> >> > We'd then doing two commits for every patch. Let's simply not remove
> >> CHANGES.txt from trunk, keep the existing dev workflow, but doc the
> >>release
> >> process to remove CHANGES.txt in trunk at the time of a release going
> >>out
> >> of trunk.
> >>
> >>
> >>
> >> Might as well copy branch-2¹s changes.txt into trunk then. (or 2.7¹s.
> >> Last I looked, people updated branch-2 and not 2.7¹s or vice versa for
> >>some
> >> patches that went into both branches.)  So that folks who are
> >>committing to
> >> both branches and want to cherry pick all changes can.
> >>
> >> I mean, trunk¹s is very very very wrong. Right now. Today. Borderline
> >> useless. See HADOOP-11718 (which I will now close out as won¹t fix)Š and
> >> that jira is only what is miscategorized, not what is missing.
> >>
> >>
> >>
> >>
>
>

-- 
Mobile

[jira] [Created] (HADOOP-12180) Move ResourceCalculatorPlugin from YARN to Common

[Chris Douglas (JIRA)]

Chris Douglas created HADOOP-12180:
--

 Summary: Move ResourceCalculatorPlugin from YARN to Common
 Key: HADOOP-12180
 URL: https://issues.apache.org/jira/browse/HADOOP-12180
 Project: Hadoop Common
  Issue Type: Improvement
  Components: util
Reporter: Chris Douglas


Some of the monitoring functions could be moved from YARN to Common for easier 
sharing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HADOOP-12179) Test Jira, please ignore

[Arpit Agarwal (JIRA)]

Arpit Agarwal created HADOOP-12179:
--

 Summary: Test Jira, please ignore
 Key: HADOOP-12179
 URL: https://issues.apache.org/jira/browse/HADOOP-12179
 Project: Hadoop Common
  Issue Type: Bug
  Components: tools
Reporter: Arpit Agarwal
Assignee: Arpit Agarwal






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HADOOP-12178) NPE during handling of SASL setup if problem with SASL resolver class

[Steve Loughran (JIRA)]

Steve Loughran created HADOOP-12178:
---

 Summary: NPE during handling of SASL setup if problem with SASL 
resolver class
 Key: HADOOP-12178
 URL: https://issues.apache.org/jira/browse/HADOOP-12178
 Project: Hadoop Common
  Issue Type: Bug
  Components: ipc
Affects Versions: 2.7.1
Reporter: Steve Loughran


If there's any problem in the constructor of {{SaslRpcClient}}, then IPC Client 
throws an NPE rather than forwarding the stack trace. This is because the 
exception handler assumes that {{saslRpcClient}} is not null, that the 
exception is related to the SASL setup itself.

The exception handler needs to check for {{saslRpcClient}} being null, and if 
so, rethrow the exception



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: IMPORTANT: automatic changelog creation

[Chris Nauroth]

+1

Thank you to Allen for the script, and thank you to Andrew for
volunteering to drive the conversion.

--Chris Nauroth




On 7/2/15, 2:01 PM, "Andrew Wang"  wrote:

>Hi all,
>
>I want to revive the discussion on this thread, since the overhead of
>CHANGES.txt came up again in the context of backporting fixes for
>maintenance releases.
>
>Allen's automatic generation script (HADOOP-11731) went into trunk but not
>branch-2, so we're still maintaining CHANGES.txt everywhere. What do
>people
>think about backporting this to branch-2 and then removing CHANGES.txt
>from
>trunk/branch-2 (HADOOP-11792)? Based on discussion on this thread and in
>HADOOP-11731, we seem to agree that CHANGES.txt is an unreliable source of
>information, and JIRA is at least as reliable and probably much more so.
>Thus I don't see any downsides to backporting it.
>
>Would like to hear everyone's thoughts on this, I'm willing to drive the
>effort.
>
>Thanks,
>Andrew
>
>On Thu, Apr 2, 2015 at 2:00 PM, Tsz Wo Sze 
>wrote:
>
>> Generating change log from JIRA is a good idea.  It bases on an
>>assumption
>> that each JIRA has an accurate summary (a.k.a. JIRA title) to reflect
>>the
>> committed change. Unfortunately, the assumption is invalid for many
>>cases
>> since we never enforce that the JIRA summary must be the same as the
>>change
>> log.  We may compare the current CHANGES.txt with the generated change
>> log.  I beg the diff is long.
>> Besides, after a release R1 is out, someone may (accidentally or
>> intentionally) modify the JIRA summary.  Then, the entry for the same
>>item
>> in a later release R2 could be different from the one in R1.
>> I agree that manually editing CHANGES.txt is not a perfect solution.
>> However, it works well in the past for many releases.  I suggest we keep
>> the current dev workflow.  Try using the new script provided by
>> HADOOP-11731 to generate the next release.  If everything works well, we
>> shell remove CHANGES.txt and revise the dev workflow.  What do you
>>think?
>> Regards,Tsz-Wo
>>
>>
>>  On Thursday, April 2, 2015 12:57 PM, Allen Wittenauer <
>> a...@altiscale.com> wrote:
>>
>>
>>
>>
>>
>> On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli <
>> vino...@hortonworks.com> wrote:
>>
>> >
>> > We'd then doing two commits for every patch. Let's simply not remove
>> CHANGES.txt from trunk, keep the existing dev workflow, but doc the
>>release
>> process to remove CHANGES.txt in trunk at the time of a release going
>>out
>> of trunk.
>>
>>
>>
>> Might as well copy branch-2¹s changes.txt into trunk then. (or 2.7¹s.
>> Last I looked, people updated branch-2 and not 2.7¹s or vice versa for
>>some
>> patches that went into both branches.)  So that folks who are
>>committing to
>> both branches and want to cherry pick all changes can.
>>
>> I mean, trunk¹s is very very very wrong. Right now. Today. Borderline
>> useless. See HADOOP-11718 (which I will now close out as won¹t fix)Š and
>> that jira is only what is miscategorized, not what is missing.
>>
>>
>>
>>

Re: IMPORTANT: automatic changelog creation

[Andrew Wang]

Hi all,

I want to revive the discussion on this thread, since the overhead of
CHANGES.txt came up again in the context of backporting fixes for
maintenance releases.

Allen's automatic generation script (HADOOP-11731) went into trunk but not
branch-2, so we're still maintaining CHANGES.txt everywhere. What do people
think about backporting this to branch-2 and then removing CHANGES.txt from
trunk/branch-2 (HADOOP-11792)? Based on discussion on this thread and in
HADOOP-11731, we seem to agree that CHANGES.txt is an unreliable source of
information, and JIRA is at least as reliable and probably much more so.
Thus I don't see any downsides to backporting it.

Would like to hear everyone's thoughts on this, I'm willing to drive the
effort.

Thanks,
Andrew

On Thu, Apr 2, 2015 at 2:00 PM, Tsz Wo Sze 
wrote:

> Generating change log from JIRA is a good idea.  It bases on an assumption
> that each JIRA has an accurate summary (a.k.a. JIRA title) to reflect the
> committed change. Unfortunately, the assumption is invalid for many cases
> since we never enforce that the JIRA summary must be the same as the change
> log.  We may compare the current CHANGES.txt with the generated change
> log.  I beg the diff is long.
> Besides, after a release R1 is out, someone may (accidentally or
> intentionally) modify the JIRA summary.  Then, the entry for the same item
> in a later release R2 could be different from the one in R1.
> I agree that manually editing CHANGES.txt is not a perfect solution.
> However, it works well in the past for many releases.  I suggest we keep
> the current dev workflow.  Try using the new script provided by
> HADOOP-11731 to generate the next release.  If everything works well, we
> shell remove CHANGES.txt and revise the dev workflow.  What do you think?
> Regards,Tsz-Wo
>
>
>  On Thursday, April 2, 2015 12:57 PM, Allen Wittenauer <
> a...@altiscale.com> wrote:
>
>
>
>
>
> On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli <
> vino...@hortonworks.com> wrote:
>
> >
> > We'd then doing two commits for every patch. Let's simply not remove
> CHANGES.txt from trunk, keep the existing dev workflow, but doc the release
> process to remove CHANGES.txt in trunk at the time of a release going out
> of trunk.
>
>
>
> Might as well copy branch-2’s changes.txt into trunk then. (or 2.7’s.
> Last I looked, people updated branch-2 and not 2.7’s or vice versa for some
> patches that went into both branches.)  So that folks who are committing to
> both branches and want to cherry pick all changes can.
>
> I mean, trunk’s is very very very wrong. Right now. Today. Borderline
> useless. See HADOOP-11718 (which I will now close out as won’t fix)… and
> that jira is only what is miscategorized, not what is missing.
>
>
>
>

[jira] [Created] (HADOOP-12177) [Umbrella] Update and extend filesystem specification

[Masatake Iwasaki (JIRA)]

Masatake Iwasaki created HADOOP-12177:
-

 Summary: [Umbrella] Update and extend filesystem specification
 Key: HADOOP-12177
 URL: https://issues.apache.org/jira/browse/HADOOP-12177
 Project: Hadoop Common
  Issue Type: Improvement
Reporter: Masatake Iwasaki






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Hadoop 2.7.1 RC0

[Masatake Iwasaki]

+1 (non-binding)

+ verified mds of source and binary tarball
+ built from source tarball
+ deployed binary tarball to 4 nodes cluster and run some 
hadoop-mapreduce-examples jobs


Thanks,
Masatake Iwasaki


On 6/29/15 17:45, Vinod Kumar Vavilapalli wrote:

Hi all,

I've created a release candidate RC0 for Apache Hadoop 2.7.1.

As discussed before, this is the next stable release to follow up 2.6.0,
and the first stable one in the 2.7.x line.

The RC is available for validation at:
*http://people.apache.org/~vinodkv/hadoop-2.7.1-RC0/
*

The RC tag in git is: release-2.7.1-RC0

The maven artifacts are available via repository.apache.org at
*https://repository.apache.org/content/repositories/orgapachehadoop-1019/
*

Please try the release and vote; the vote will run for the usual 5 days.

Thanks,
Vinod

PS: It took 2 months instead of the planned [1] 2 weeks in getting this
release out: post-mortem in a separate thread.

[1]: A 2.7.1 release to follow up 2.7.0
http://markmail.org/thread/zwzze6cqqgwq4rmw

Re: [VOTE] Release Apache Hadoop 2.7.1 RC0

[Eric Payne]

+1 (non-binding)
+ Downloaded and built source+ Installed on one-node cluster+ Ran simple manual 
tests+ spot-checked unit tests
Thanks, Vinod, for managing this release!-Eric Payne
 
  From: Vinod Kumar Vavilapalli 
 To: common-dev@hadoop.apache.org; hdfs-...@hadoop.apache.org; 
yarn-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org 
Cc: vino...@apache.org 
 Sent: Monday, June 29, 2015 3:45 AM
 Subject: [VOTE] Release Apache Hadoop 2.7.1 RC0
   
Hi all,

I've created a release candidate RC0 for Apache Hadoop 2.7.1.

As discussed before, this is the next stable release to follow up 2.6.0,
and the first stable one in the 2.7.x line.

The RC is available for validation at:
*http://people.apache.org/~vinodkv/hadoop-2.7.1-RC0/
*

The RC tag in git is: release-2.7.1-RC0

The maven artifacts are available via repository.apache.org at
*https://repository.apache.org/content/repositories/orgapachehadoop-1019/
*

Please try the release and vote; the vote will run for the usual 5 days.

Thanks,
Vinod

PS: It took 2 months instead of the planned [1] 2 weeks in getting this
release out: post-mortem in a separate thread.

[1]: A 2.7.1 release to follow up 2.7.0
http://markmail.org/thread/zwzze6cqqgwq4rmw


   

[jira] [Created] (HADOOP-12176) smart-apply-patch.sh fails to identify git patch prefixes in some cases

[Vinayakumar B (JIRA)]

Vinayakumar B created HADOOP-12176:
--

 Summary: smart-apply-patch.sh fails to identify git patch prefixes 
in some cases
 Key: HADOOP-12176
 URL: https://issues.apache.org/jira/browse/HADOOP-12176
 Project: Hadoop Common
  Issue Type: Bug
Reporter: Vinayakumar B
Assignee: Vinayakumar B


after HADOOP-12018, git apply supported with --no-prefix.

But for some patches this detection will identify git patch with prefix as 
no-prefix patch and fails to apply.

Example case is ; If patch contains a line changed with '+++' or '---' 
somewhere in between. May be a javadoc update. This makes detection wrong and 
git apply will fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HADOOP-12175) FsShell must load SpanReceierHost to support tracing

[Masatake Iwasaki (JIRA)]

Masatake Iwasaki created HADOOP-12175:
-

 Summary: FsShell must load SpanReceierHost to support tracing
 Key: HADOOP-12175
 URL: https://issues.apache.org/jira/browse/HADOOP-12175
 Project: Hadoop Common
  Issue Type: Bug
  Components: tracing
Affects Versions: 2.8.0
Reporter: Masatake Iwasaki
Assignee: Masatake Iwasaki


FsShell need to load SpanReceierHost to support tracing in addition to 
HADOOP-12124.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)