Hadoop Common
  1. Hadoop Common
  2. HADOOP-8152

Expand public APIs for security library classes

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-alpha
    • Fix Version/s: 2.0.0-alpha
    • Component/s: security
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      Currently projects like Hive and HBase use UserGroupInformation and SecurityUtil methods. Both of these classes are marked LimitedPrivate(HDFS,MR) but should probably be marked more generally public.

      1. HADOOP-8152.patch
        8 kB
        Aaron T. Myers
      2. HADOOP-8152.patch
        7 kB
        Aaron T. Myers
      3. HADOOP-8152.patch
        5 kB
        Aaron T. Myers

        Issue Links

          Activity

          Hide
          Ashutosh Chauhan added a comment -

          +1. Hive uses them. Either make it public or LimitedPrivate(HDFS,MR,Hive,HBase) will be fine.

          Show
          Ashutosh Chauhan added a comment - +1. Hive uses them. Either make it public or LimitedPrivate(HDFS,MR,Hive,HBase) will be fine.
          Hide
          Harsh J added a comment -

          We also have public docs on letting users use UserGroupInformation for secure impersonation, at http://hadoop.apache.org/common/docs/r1.0.0/Secure_Impersonation.html (for example).

          Show
          Harsh J added a comment - We also have public docs on letting users use UserGroupInformation for secure impersonation, at http://hadoop.apache.org/common/docs/r1.0.0/Secure_Impersonation.html (for example).
          Hide
          Daryn Sharp added a comment -

          Do you think the entire class apis should be exposed, or just certain methods? Opening up the methods will essentially set them in stone so we should carefully consider if the apis are exactly how we want them.

          Show
          Daryn Sharp added a comment - Do you think the entire class apis should be exposed, or just certain methods? Opening up the methods will essentially set them in stone so we should carefully consider if the apis are exactly how we want them.
          Hide
          Jitendra Nath Pandey added a comment -

          I agree with Daryn, we should figure out a way to selectively open the APIs.

          Show
          Jitendra Nath Pandey added a comment - I agree with Daryn, we should figure out a way to selectively open the APIs.
          Hide
          Andrew Purtell added a comment -

          +1 on promoting these interfaces to public, at least the methods in common use across subprojects now.

          This was sent to user@hbase:

          At least on the HBase side, I'll [Andrew Purtell] take the pain once to rework our related sources if the APIs on their way to stability make one more change. However, it would be preferable to avoid further need for hacks. Use of reflection can ride over an API in transition, but it can also punt breakage due to API change to runtime, where we'd least like to see it for the first time.

          Relevant here I think.

          Show
          Andrew Purtell added a comment - +1 on promoting these interfaces to public, at least the methods in common use across subprojects now. This was sent to user@hbase: At least on the HBase side, I'll [Andrew Purtell] take the pain once to rework our related sources if the APIs on their way to stability make one more change. However, it would be preferable to avoid further need for hacks. Use of reflection can ride over an API in transition, but it can also punt breakage due to API change to runtime, where we'd least like to see it for the first time. Relevant here I think.
          Hide
          Enis Soztutar added a comment -

          HBase also has it's own delegation tokens, so we should consider all of the Token-related interfaces. An HBase-like project will definitely need its own Tokens, TokenIdentifiers, TokenRenewers, etc.

          Show
          Enis Soztutar added a comment - HBase also has it's own delegation tokens, so we should consider all of the Token-related interfaces. An HBase-like project will definitely need its own Tokens, TokenIdentifiers, TokenRenewers, etc.
          Hide
          Aaron T. Myers added a comment -

          Do you think the entire class apis should be exposed, or just certain methods? Opening up the methods will essentially set them in stone so we should carefully consider if the apis are exactly how we want them.

          That seems reasonable to me. Is it acceptable to just leave the class InterfaceAudience annotations in place, and add more visible annotations to certain methods? Or is it that the least-visible annotation is the one that applies? Or would folks prefer that we create a new class or two which just selectively expose these interfaces?

          Show
          Aaron T. Myers added a comment - Do you think the entire class apis should be exposed, or just certain methods? Opening up the methods will essentially set them in stone so we should carefully consider if the apis are exactly how we want them. That seems reasonable to me. Is it acceptable to just leave the class InterfaceAudience annotations in place, and add more visible annotations to certain methods? Or is it that the least-visible annotation is the one that applies? Or would folks prefer that we create a new class or two which just selectively expose these interfaces?
          Hide
          Aaron T. Myers added a comment -

          Here's a patch which addresses the issue. Let me summarize the changes:

          • Both UserGroupInformation and SecurityUtil are currently marked InterfaceAudience.LimitedPrivate("HDFS", "MapReduce") and InterfaceStability.Evolving. This is unchanged.
          • This patch adds InterfaceAudience.Public and InterfaceStability.Evolving annotations to getCurrentUser, getLoginUser, createRemoteUser, createProxyUser, and both variants of doAs in UserGroupInformation.
          • This patch adds InterfaceAudience.Public and InterfaceStability.Evolving annotations to both variants of the method "login" in SecurityUtil.
          • This patch removes two cases of individual methods being marked InterfaceAudience.LimitedPrivate("HDFS", "MapReduce") in UserGroupInformation. Since the class is already annotated the same way, these seemed redundant.

          My understanding of the nature of the InterfaceAudience and InterfaceStability annotations is that the most-specific annotation is what applies. Thus, just increasing the InterfaceAudience visibility of these methods should be sufficient for the purposes of dependent projects.

          The methods that I chose here are the ones that I'm aware of dependent projects using. If others are aware of more, I'd be happy to add them to this patch.

          Show
          Aaron T. Myers added a comment - Here's a patch which addresses the issue. Let me summarize the changes: Both UserGroupInformation and SecurityUtil are currently marked InterfaceAudience.LimitedPrivate("HDFS", "MapReduce") and InterfaceStability.Evolving. This is unchanged. This patch adds InterfaceAudience.Public and InterfaceStability.Evolving annotations to getCurrentUser, getLoginUser, createRemoteUser, createProxyUser, and both variants of doAs in UserGroupInformation. This patch adds InterfaceAudience.Public and InterfaceStability.Evolving annotations to both variants of the method "login" in SecurityUtil. This patch removes two cases of individual methods being marked InterfaceAudience.LimitedPrivate("HDFS", "MapReduce") in UserGroupInformation. Since the class is already annotated the same way, these seemed redundant. My understanding of the nature of the InterfaceAudience and InterfaceStability annotations is that the most-specific annotation is what applies. Thus, just increasing the InterfaceAudience visibility of these methods should be sufficient for the purposes of dependent projects. The methods that I chose here are the ones that I'm aware of dependent projects using. If others are aware of more, I'd be happy to add them to this patch.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12521709/HADOOP-8152.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          -1 tests included. The patch doesn't appear to include any new or modified tests.
          Please justify why no new tests are needed for this patch.
          Also please list what manual steps were performed to verify this patch.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in .

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/838//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/838//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12521709/HADOOP-8152.patch against trunk revision . +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 eclipse:eclipse. The patch built with eclipse:eclipse. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed unit tests in . +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/838//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/838//console This message is automatically generated.
          Hide
          Aaron T. Myers added a comment -

          No tests are included since this just changes some audience/stability annotations.

          Show
          Aaron T. Myers added a comment - No tests are included since this just changes some audience/stability annotations.
          Hide
          Todd Lipcon added a comment -

          Looking at HBase, it seems like it's also using the following which aren't marked public by this patch:

          • SecurityUtil.getServerPrincipal
          • enum UGI.AuthenticationMethod (marked evolving but not marked public)
          • UGI.getRealUser
          • UGI.isLoginKeytabBased
          • UGI.reloginFromKeytab
          • UGI.reloginFromTicketCache
          • UGI.getUserName
          • UGI.createUserForTesting
          Show
          Todd Lipcon added a comment - Looking at HBase, it seems like it's also using the following which aren't marked public by this patch: SecurityUtil.getServerPrincipal enum UGI.AuthenticationMethod (marked evolving but not marked public) UGI.getRealUser UGI.isLoginKeytabBased UGI.reloginFromKeytab UGI.reloginFromTicketCache UGI.getUserName UGI.createUserForTesting
          Hide
          Allen Wittenauer added a comment -

          Many parts of UGI are pretty broken when multiple keytabs are in play. They should probably be fixed before marking them public. The fact that HBase uses them even though they aren't marked Public is HBase's problem.

          Show
          Allen Wittenauer added a comment - Many parts of UGI are pretty broken when multiple keytabs are in play. They should probably be fixed before marking them public. The fact that HBase uses them even though they aren't marked Public is HBase's problem.
          Hide
          Aaron T. Myers added a comment -

          Thanks a lot for the input, Todd. Here's an updated patch which adds the methods you mentioned HBase makes use of.

          Many parts of UGI are pretty broken when multiple keytabs are in play. They should probably be fixed before marking them public.

          Note that this patch is marking the interfaces evolving, not stable, so if we have a good reason to change them between releases (e.g. fixing multi-keytab support) then we certainly can.

          Show
          Aaron T. Myers added a comment - Thanks a lot for the input, Todd. Here's an updated patch which adds the methods you mentioned HBase makes use of. Many parts of UGI are pretty broken when multiple keytabs are in play. They should probably be fixed before marking them public. Note that this patch is marking the interfaces evolving, not stable, so if we have a good reason to change them between releases (e.g. fixing multi-keytab support) then we certainly can.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12521917/HADOOP-8152.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          -1 tests included. The patch doesn't appear to include any new or modified tests.
          Please justify why no new tests are needed for this patch.
          Also please list what manual steps were performed to verify this patch.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in .

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/840//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/840//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12521917/HADOOP-8152.patch against trunk revision . +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 eclipse:eclipse. The patch built with eclipse:eclipse. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed unit tests in . +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/840//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/840//console This message is automatically generated.
          Hide
          Allen Wittenauer added a comment -

          Even marking something as Public+Evolving has certain implications. I don't know if I'm comfortable with some of these being marked public. Will the impacted parties understand when we break them? (It is inevitable we're going to change reloginFromKeytab and likely even remove it as part of reworking UGI.)

          Show
          Allen Wittenauer added a comment - Even marking something as Public+Evolving has certain implications. I don't know if I'm comfortable with some of these being marked public. Will the impacted parties understand when we break them? (It is inevitable we're going to change reloginFromKeytab and likely even remove it as part of reworking UGI.)
          Hide
          Aaron T. Myers added a comment -

          Even marking something as Public+Evolving has certain implications. I don't know if I'm comfortable with some of these being marked public. Will the impacted parties understand when we break them?

          I'd like to think that the impacted parties would understand. Perhaps one of the HBase folk watching this JIRA could comment? Andrew? Todd?

          (It is inevitable we're going to change reloginFromKeytab and likely even remove it as part of reworking UGI.)

          Is it also inevitable that maintaining backward compatibility will be impossible? If it is, then we can still break them. Hence the "Evolving" annotation.

          Also, could you point me toward the JIRA discussing reworking UGI? I'm not familiar with it.

          Show
          Aaron T. Myers added a comment - Even marking something as Public+Evolving has certain implications. I don't know if I'm comfortable with some of these being marked public. Will the impacted parties understand when we break them? I'd like to think that the impacted parties would understand. Perhaps one of the HBase folk watching this JIRA could comment? Andrew? Todd? (It is inevitable we're going to change reloginFromKeytab and likely even remove it as part of reworking UGI.) Is it also inevitable that maintaining backward compatibility will be impossible? If it is, then we can still break them. Hence the "Evolving" annotation. Also, could you point me toward the JIRA discussing reworking UGI? I'm not familiar with it.
          Hide
          Allen Wittenauer added a comment -

          Actually, I've been thinking a lot about this. It is pretty clear that the interested parties are sort of ignoring our interface stability markings and are willing to live with the risk of future breakage. With the strict exception of the ones documented in secure impersonation (which should obviously be public+stable) is there any actual benefit to marking these public (in any form) for those that do want to play by the rules?

          Also, could you point me toward the JIRA discussing reworking UGI? I'm not familiar with it.

          It doesn't exist yet because I think we're the only ones to hit it and haven't had a chance to work up a patch since we've developed a somewhat nasty workaround.

          The basic problem is that the UGI code assumes there is only one keytab in play so when there are two or more, calling reloginFromKeytab (amongst other routines) can have unpredictable results. What we've been hypothesizing is changing it such that it requires saying which keytab you actually want to relogin from... which means there is a good chance that backward compatibility isn't going to be possible.

          Show
          Allen Wittenauer added a comment - Actually, I've been thinking a lot about this. It is pretty clear that the interested parties are sort of ignoring our interface stability markings and are willing to live with the risk of future breakage. With the strict exception of the ones documented in secure impersonation (which should obviously be public+stable) is there any actual benefit to marking these public (in any form) for those that do want to play by the rules? Also, could you point me toward the JIRA discussing reworking UGI? I'm not familiar with it. It doesn't exist yet because I think we're the only ones to hit it and haven't had a chance to work up a patch since we've developed a somewhat nasty workaround. The basic problem is that the UGI code assumes there is only one keytab in play so when there are two or more, calling reloginFromKeytab (amongst other routines) can have unpredictable results. What we've been hypothesizing is changing it such that it requires saying which keytab you actually want to relogin from... which means there is a good chance that backward compatibility isn't going to be possible.
          Hide
          Todd Lipcon added a comment -

          I generally agree that the static "loginUser" concept is a mess and should probably be killed in favor of using methods like loginFromKeytabAndReturnUGI everywhere. But I also agree with Aaron that we can mark these as evolving and it doesn't force our hand down the road.

          Show
          Todd Lipcon added a comment - I generally agree that the static "loginUser" concept is a mess and should probably be killed in favor of using methods like loginFromKeytabAndReturnUGI everywhere. But I also agree with Aaron that we can mark these as evolving and it doesn't force our hand down the road.
          Hide
          Aaron T. Myers added a comment -

          The basic problem is that the UGI code assumes there is only one keytab in play so when there are two or more, calling reloginFromKeytab (amongst other routines) can have unpredictable results.

          Makes sense. Thanks for the explanation. Would you mind filing a JIRA describing the issue? Even if you don't intend to work on it, having the problem described will be helpful to facilitate discussion.

          What we've been hypothesizing is changing it such that it requires saying which keytab you actually want to relogin from... which means there is a good chance that backward compatibility isn't going to be possible.

          Sounds like backward compatibility could perhaps be achieved for the single-keytab case by retaining the no-arg routines, checking how many keytabs are in play, and throwing an error if a no-arg routine is called when there's more than one keytab.

          Show
          Aaron T. Myers added a comment - The basic problem is that the UGI code assumes there is only one keytab in play so when there are two or more, calling reloginFromKeytab (amongst other routines) can have unpredictable results. Makes sense. Thanks for the explanation. Would you mind filing a JIRA describing the issue? Even if you don't intend to work on it, having the problem described will be helpful to facilitate discussion. What we've been hypothesizing is changing it such that it requires saying which keytab you actually want to relogin from... which means there is a good chance that backward compatibility isn't going to be possible. Sounds like backward compatibility could perhaps be achieved for the single-keytab case by retaining the no-arg routines, checking how many keytabs are in play, and throwing an error if a no-arg routine is called when there's more than one keytab.
          Hide
          Eli Collins added a comment -

          I agree the UGI methods should be annotated public since, per Harsh, we provide user-facing documentation on how to use them. I would extend the @InterfaceAudience for UGI to include HBase, Hive and Oozie since these are "closely related projects" that use UGI that we don't want to break, or alternatively add a class-level comment to this effect so people understand why we're calling out specific methods as public in a limited private class. I agree w/ the overall approach, and otherwise the patch looks good to me.

          Show
          Eli Collins added a comment - I agree the UGI methods should be annotated public since, per Harsh, we provide user-facing documentation on how to use them. I would extend the @InterfaceAudience for UGI to include HBase, Hive and Oozie since these are "closely related projects" that use UGI that we don't want to break, or alternatively add a class-level comment to this effect so people understand why we're calling out specific methods as public in a limited private class. I agree w/ the overall approach, and otherwise the patch looks good to me.
          Hide
          Allen Wittenauer added a comment -

          We should only mark the methods that are specifically called out in the documentation, not nearly as many as this patch does. I'm pretty much -1 on any patch that marks undocumented methods as public.

          Additionally, since HBase, Hive, and Oozie are using methods that are private without communicating their need beforehand, I see no reason to change the InterfaceAudience. Using the methods, doing a release, and then asking for forgiveness is inexcusable. They could have easily have asked us to change prior to them doing a release. Since they didn't, they clearly don't care about the stability levels.

          Show
          Allen Wittenauer added a comment - We should only mark the methods that are specifically called out in the documentation, not nearly as many as this patch does. I'm pretty much -1 on any patch that marks undocumented methods as public. Additionally, since HBase, Hive, and Oozie are using methods that are private without communicating their need beforehand, I see no reason to change the InterfaceAudience. Using the methods, doing a release, and then asking for forgiveness is inexcusable. They could have easily have asked us to change prior to them doing a release. Since they didn't, they clearly don't care about the stability levels.
          Hide
          Eli Collins added a comment -

          @Allen, these projects started using these classes when they were just public, before we added the interface annotations. Ie these methods weren't private when they started using them. And all the methods are documented via javadoc. So you can't infer these projects don't care about stability, and therefore it's OK to break them. Given this, I think we should include these closely-related projects, that we don't want to break, in the limited private set.

          Show
          Eli Collins added a comment - @Allen, these projects started using these classes when they were just public, before we added the interface annotations. Ie these methods weren't private when they started using them. And all the methods are documented via javadoc. So you can't infer these projects don't care about stability, and therefore it's OK to break them. Given this, I think we should include these closely-related projects, that we don't want to break, in the limited private set.
          Hide
          Allen Wittenauer added a comment -

          Lots of things are documented via javadoc that we likely wouldn't want anyone to use. There are also lots of things that are not documented (properly) in javadoc that we actually want people to use. See the compression codec interfaces, for example.

          I'm speaking specifically of http://hadoop.apache.org/common/docs/r1.0.0/Secure_Impersonation.html as pointed out by Harsh.

          Show
          Allen Wittenauer added a comment - Lots of things are documented via javadoc that we likely wouldn't want anyone to use. There are also lots of things that are not documented (properly) in javadoc that we actually want people to use. See the compression codec interfaces, for example. I'm speaking specifically of http://hadoop.apache.org/common/docs/r1.0.0/Secure_Impersonation.html as pointed out by Harsh.
          Hide
          Andrew Purtell added a comment -

          I think we would like to work together here. Nobody is doing obviously dumb things and asking for forgiveness later IMHO. We'd like our projects to integrate with Hadoop when its security features are enabled. Unfortunately to do so requires use of classes/methods now marked as private or whatever. This area is obviously still a work in progress and not conducive to easy reuse or extension. We can be blamed for wanting to do the right thing, but that seems counterproductive.

          Show
          Andrew Purtell added a comment - I think we would like to work together here. Nobody is doing obviously dumb things and asking for forgiveness later IMHO. We'd like our projects to integrate with Hadoop when its security features are enabled. Unfortunately to do so requires use of classes/methods now marked as private or whatever. This area is obviously still a work in progress and not conducive to easy reuse or extension. We can be blamed for wanting to do the right thing, but that seems counterproductive.
          Hide
          Alejandro Abdelnur added a comment -

          Oozie uses the following from Hadoop security:

          • UserGroupInformation class:
            • UserGroupInformation.setConfiguration()
            • UserGroupInformation.loginUserFromKeytab()
            • UserGroupInformation.createProxyUser()
            • UserGroupInformation.createUserForTesting()
            • UserGroupInformation.doAs()
          • hadoop-auth packages:
            • org.apache.hadoop.security.authentication.client
            • org.apache.hadoop.security.authentication.server
          Show
          Alejandro Abdelnur added a comment - Oozie uses the following from Hadoop security: UserGroupInformation class: UserGroupInformation.setConfiguration() UserGroupInformation.loginUserFromKeytab() UserGroupInformation.createProxyUser() UserGroupInformation.createUserForTesting() UserGroupInformation.doAs() hadoop-auth packages: org.apache.hadoop.security.authentication.client org.apache.hadoop.security.authentication.server
          Hide
          Aaron T. Myers added a comment -

          Thanks a lot for the reviews, Eli and Alejandro. Here's an updated patch which incorporates your feedback.

          hadoop-auth packages:

          Mind if we address this in a separate JIRA? Seems like a distinct issue to me.

          Show
          Aaron T. Myers added a comment - Thanks a lot for the reviews, Eli and Alejandro. Here's an updated patch which incorporates your feedback. hadoop-auth packages: Mind if we address this in a separate JIRA? Seems like a distinct issue to me.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12523428/HADOOP-8152.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          -1 tests included. The patch doesn't appear to include any new or modified tests.
          Please justify why no new tests are needed for this patch.
          Also please list what manual steps were performed to verify this patch.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests:
          org.apache.hadoop.fs.viewfs.TestViewFsTrash

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/871//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/871//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12523428/HADOOP-8152.patch against trunk revision . +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 eclipse:eclipse. The patch built with eclipse:eclipse. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed these unit tests: org.apache.hadoop.fs.viewfs.TestViewFsTrash +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/871//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/871//console This message is automatically generated.
          Hide
          Eli Collins added a comment -

          +1 looks good to me, agree we can address hadoop-auth in another jira. The test failure is unrelated.

          Show
          Eli Collins added a comment - +1 looks good to me, agree we can address hadoop-auth in another jira. The test failure is unrelated.
          Hide
          Eli Collins added a comment -

          I've committed this and merged to branch-2, thanks ATM.

          @Tucu, please file a jira for the hadoop-auth follow on change.

          Show
          Eli Collins added a comment - I've committed this and merged to branch-2, thanks ATM. @Tucu, please file a jira for the hadoop-auth follow on change.
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Common-trunk-Commit #2123 (See https://builds.apache.org/job/Hadoop-Common-trunk-Commit/2123/)
          HADOOP-8152. Expand public APIs for security library classes. Contributed by Aaron T. Myers (Revision 1329541)

          Result = SUCCESS
          eli : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1329541
          Files :

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SecurityUtil.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java
          Show
          Hudson added a comment - Integrated in Hadoop-Common-trunk-Commit #2123 (See https://builds.apache.org/job/Hadoop-Common-trunk-Commit/2123/ ) HADOOP-8152 . Expand public APIs for security library classes. Contributed by Aaron T. Myers (Revision 1329541) Result = SUCCESS eli : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1329541 Files : /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SecurityUtil.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Hdfs-trunk-Commit #2197 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Commit/2197/)
          HADOOP-8152. Expand public APIs for security library classes. Contributed by Aaron T. Myers (Revision 1329541)

          Result = SUCCESS
          eli : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1329541
          Files :

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SecurityUtil.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java
          Show
          Hudson added a comment - Integrated in Hadoop-Hdfs-trunk-Commit #2197 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Commit/2197/ ) HADOOP-8152 . Expand public APIs for security library classes. Contributed by Aaron T. Myers (Revision 1329541) Result = SUCCESS eli : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1329541 Files : /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SecurityUtil.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Mapreduce-trunk-Commit #2139 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Commit/2139/)
          HADOOP-8152. Expand public APIs for security library classes. Contributed by Aaron T. Myers (Revision 1329541)

          Result = SUCCESS
          eli : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1329541
          Files :

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SecurityUtil.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java
          Show
          Hudson added a comment - Integrated in Hadoop-Mapreduce-trunk-Commit #2139 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Commit/2139/ ) HADOOP-8152 . Expand public APIs for security library classes. Contributed by Aaron T. Myers (Revision 1329541) Result = SUCCESS eli : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1329541 Files : /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SecurityUtil.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Hdfs-trunk #1024 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1024/)
          HADOOP-8152. Expand public APIs for security library classes. Contributed by Aaron T. Myers (Revision 1329541)

          Result = FAILURE
          eli : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1329541
          Files :

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SecurityUtil.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java
          Show
          Hudson added a comment - Integrated in Hadoop-Hdfs-trunk #1024 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1024/ ) HADOOP-8152 . Expand public APIs for security library classes. Contributed by Aaron T. Myers (Revision 1329541) Result = FAILURE eli : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1329541 Files : /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SecurityUtil.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Mapreduce-trunk #1059 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1059/)
          HADOOP-8152. Expand public APIs for security library classes. Contributed by Aaron T. Myers (Revision 1329541)

          Result = FAILURE
          eli : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1329541
          Files :

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SecurityUtil.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java
          Show
          Hudson added a comment - Integrated in Hadoop-Mapreduce-trunk #1059 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1059/ ) HADOOP-8152 . Expand public APIs for security library classes. Contributed by Aaron T. Myers (Revision 1329541) Result = FAILURE eli : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1329541 Files : /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SecurityUtil.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java

            People

            • Assignee:
              Aaron T. Myers
              Reporter:
              Aaron T. Myers
            • Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development