[jira] [Commented] (HADOOP-14445) Delegation tokens are not shared between KMS instances
[
https://issues.apache.org/jira/browse/HADOOP-14445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413343#comment-16413343
]
Xiao Chen commented on HADOOP-14445:
Thanks [~shahrs87], will work on the review comments this week.
{quote}Daryn Sharp shared his concerns offline that this patch is dependent on
config key and we will live with the baggage of 2 tokens forever. ... I will
request him to review asap.
{quote}
It feels to me the config is unavoidable if we want it to be both compatible
and new format (be it changing existing uri of kms-dt, aka. patch 3, or adding
new token kind, aka. patch 8).
I also thought about further complicate code but ease deployment, by adding yet
another config to yarn's {{DelegationTokenRenewer#handleAppSubmitEvent}} to
_not_ renew old tokens. This means once you're sure everyone has upgraded, you
don't have to deploy all configs, but just the RM configs. Hesitant to go this
direction though due to the added complexity, on top of an already messy area.
Better approach welcome of course.
> Delegation tokens are not shared between KMS instances
> --
>
> Key: HADOOP-14445
> URL: https://issues.apache.org/jira/browse/HADOOP-14445
> Project: Hadoop Common
> Issue Type: Bug
> Components: kms
>Affects Versions: 2.8.0, 3.0.0-alpha1
> Environment: CDH5.7.4, Kerberized, SSL, KMS-HA, at rest encryption
>Reporter: Wei-Chiu Chuang
>Assignee: Xiao Chen
>Priority: Major
> Attachments: HADOOP-14445-branch-2.8.002.patch,
> HADOOP-14445-branch-2.8.patch, HADOOP-14445.002.patch,
> HADOOP-14445.003.patch, HADOOP-14445.004.patch, HADOOP-14445.05.patch,
> HADOOP-14445.06.patch, HADOOP-14445.07.patch, HADOOP-14445.08.patch
>
>
> As discovered in HADOOP-14441, KMS HA using LoadBalancingKMSClientProvider do
> not share delegation tokens. (a client uses KMS address/port as the key for
> delegation token)
> {code:title=DelegationTokenAuthenticatedURL#openConnection}
> if (!creds.getAllTokens().isEmpty()) {
> InetSocketAddress serviceAddr = new InetSocketAddress(url.getHost(),
> url.getPort());
> Text service = SecurityUtil.buildTokenService(serviceAddr);
> dToken = creds.getToken(service);
> {code}
> But KMS doc states:
> {quote}
> Delegation Tokens
> Similar to HTTP authentication, KMS uses Hadoop Authentication for delegation
> tokens too.
> Under HA, A KMS instance must verify the delegation token given by another
> KMS instance, by checking the shared secret used to sign the delegation
> token. To do this, all KMS instances must be able to retrieve the shared
> secret from ZooKeeper.
> {quote}
> We should either update the KMS documentation, or fix this code to share
> delegation tokens.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-14831) Über-jira: S3a phase IV: Hadoop 3.1 features
[ https://issues.apache.org/jira/browse/HADOOP-14831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413188#comment-16413188 ] Steve Loughran commented on HADOOP-14831: - For people watching this, I'd really like HADOOP-14937 in, which corrects errors in the docs, improves one test and improves some exception unwlnding in callables. But I can postpone that to 3.1.1 if you like, and then we can close this > Über-jira: S3a phase IV: Hadoop 3.1 features > > > Key: HADOOP-14831 > URL: https://issues.apache.org/jira/browse/HADOOP-14831 > Project: Hadoop Common > Issue Type: Improvement > Components: fs/s3 >Affects Versions: 3.1.0 >Reporter: Steve Loughran >Priority: Blocker > > All the S3/S3A features targeting Hadoop 3.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-15335) Support xxxxxxx:xxx/stacks print lock info and more useful attribute of thread info
[
https://issues.apache.org/jira/browse/HADOOP-15335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yiran Wu updated HADOOP-15335:
--
Status: Patch Available (was: Open)
add unit test
> Support xxx:xxx/stacks print lock info and more useful attribute of
> thread info
> ---
>
> Key: HADOOP-15335
> URL: https://issues.apache.org/jira/browse/HADOOP-15335
> Project: Hadoop Common
> Issue Type: Improvement
> Components: common
>Affects Versions: 3.0.0
>Reporter: Yiran Wu
>Priority: Major
> Attachments: HADOOP-15335.001.patch, HADOOP-15335.002.patch
>
>
> Print stack information and other info show in WebUI
> http://namenode:50070/stacks?contentionTracing=true
> {code:java}
> Thread 2 (Reference Handler):
> State: WAITING
> Blocked count: 8
> Waited count: 5
> Thread CpuTime: 591
> Thread UserTime: 5754000
> Thread allocatedBytes: 0
> Waiting on java.lang.ref.Reference$Lock@4b3ed2f0
> Blocked by -1
> Stack:
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:502)
> java.lang.ref.Reference.tryHandlePending(Reference.java:191)
> java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
> Thread 1 (main):
> State: WAITING
> Blocked count: 4
> Waited count: 2
> Thread CpuTime: 2563937000
> Thread UserTime: 977000
> Thread allocatedBytes: 229115520
> Waiting on org.apache.hadoop.ipc.ProtobufRpcEngine$Server@442a2e48
> Blocked by -1
> Stack:
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:502)
> org.apache.hadoop.ipc.Server.join(Server.java:2498)
>
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.join(NameNodeRpcServer.java:442)
> org.apache.hadoop.hdfs.server.namenode.NameNode.join(NameNode.java:865)
> org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1573)
> -
> Locks info:
> -
> java.util.concurrent.locks.ReentrantReadWriteLock$FairSync@cd6c71a lockedBy
> Thread 43 (IPC Server handler 7 on 8020)
> Waiting thread num: 6
> Stack:
>
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameTo(FSNamesystem.java:3665)
>
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.rename(NameNodeRpcServer.java:868)
>
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.rename(ClientNamenodeProtocolServerSideTranslatorPB.java:583)
>
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
>
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
> org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969)
> org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2076)
> org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2072)
> java.security.AccessController.doPrivileged(Native Method)
> javax.security.auth.Subject.doAs(Subject.java:422)
>
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1803)
> org.apache.hadoop.ipc.Server$Handler.run(Server.java:2072)
> java.lang.ref.ReferenceQueue$Lock@31bcf236 lockedBy UNKNOW
> java.lang.ref.Reference$Lock@4b3ed2f0 lockedBy UNKNOW
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server@442a2e48 lockedBy UNKNOW
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Assigned] (HADOOP-14756) S3Guard: expose capability query in MetadataStore and add tests of authoritative mode
[
https://issues.apache.org/jira/browse/HADOOP-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Bota reassigned HADOOP-14756:
---
Assignee: Gabor Bota
> S3Guard: expose capability query in MetadataStore and add tests of
> authoritative mode
> -
>
> Key: HADOOP-14756
> URL: https://issues.apache.org/jira/browse/HADOOP-14756
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 3.0.0-beta1
>Reporter: Steve Loughran
>Assignee: Gabor Bota
>Priority: Major
>
> {{MetadataStoreTestBase.testListChildren}} would be improved with the ability
> to query the features offered by the store, and the outcome of {{put()}}, so
> probe the correctness of the authoritative mode
> # Add predicate to MetadataStore interface
> {{supportsAuthoritativeDirectories()}} or similar
> # If #1 is true, assert that directory is fully cached after changes
> # Add "isNew" flag to MetadataStore.put(DirListingMetadata); use to verify
> when changes are made
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-15335) Support xxxxxxx:xxx/stacks print lock info and more useful attribute of thread info
[
https://issues.apache.org/jira/browse/HADOOP-15335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yiran Wu updated HADOOP-15335:
--
Description:
Print stack information and other info show in WebUI
http://namenode:50070/stacks?contentionTracing=true
{code:java}
Thread 2 (Reference Handler):
State: WAITING
Blocked count: 8
Waited count: 5
Thread CpuTime: 591
Thread UserTime: 5754000
Thread allocatedBytes: 0
Waiting on java.lang.ref.Reference$Lock@4b3ed2f0
Blocked by -1
Stack:
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:502)
java.lang.ref.Reference.tryHandlePending(Reference.java:191)
java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
Thread 1 (main):
State: WAITING
Blocked count: 4
Waited count: 2
Thread CpuTime: 2563937000
Thread UserTime: 977000
Thread allocatedBytes: 229115520
Waiting on org.apache.hadoop.ipc.ProtobufRpcEngine$Server@442a2e48
Blocked by -1
Stack:
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:502)
org.apache.hadoop.ipc.Server.join(Server.java:2498)
org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.join(NameNodeRpcServer.java:442)
org.apache.hadoop.hdfs.server.namenode.NameNode.join(NameNode.java:865)
org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1573)
-
Locks info:
-
java.util.concurrent.locks.ReentrantReadWriteLock$FairSync@cd6c71a lockedBy
Thread 43 (IPC Server handler 7 on 8020)
Waiting thread num: 6
Stack:
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameTo(FSNamesystem.java:3665)
org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.rename(NameNodeRpcServer.java:868)
org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.rename(ClientNamenodeProtocolServerSideTranslatorPB.java:583)
org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969)
org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2076)
org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2072)
java.security.AccessController.doPrivileged(Native Method)
javax.security.auth.Subject.doAs(Subject.java:422)
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1803)
org.apache.hadoop.ipc.Server$Handler.run(Server.java:2072)
java.lang.ref.ReferenceQueue$Lock@31bcf236 lockedBy UNKNOW
java.lang.ref.Reference$Lock@4b3ed2f0 lockedBy UNKNOW
org.apache.hadoop.ipc.ProtobufRpcEngine$Server@442a2e48 lockedBy UNKNOW
{code}
was:
Print stack information and other info show in WebUI
http://namenode:50070/stacks?contentionTracing=true
```
Thread 2 (Reference Handler):
State: WAITING
Blocked count: 8
Waited count: 5
Thread CpuTime: 591
Thread UserTime: 5754000
Thread allocatedBytes: 0
Waiting on java.lang.ref.Reference$Lock@4b3ed2f0
Blocked by -1
Stack:
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:502)
java.lang.ref.Reference.tryHandlePending(Reference.java:191)
java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
Thread 1 (main):
State: WAITING
Blocked count: 4
Waited count: 2
Thread CpuTime: 2563937000
Thread UserTime: 977000
Thread allocatedBytes: 229115520
Waiting on org.apache.hadoop.ipc.ProtobufRpcEngine$Server@442a2e48
Blocked by -1
Stack:
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:502)
org.apache.hadoop.ipc.Server.join(Server.java:2498)
org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.join(NameNodeRpcServer.java:442)
org.apache.hadoop.hdfs.server.namenode.NameNode.join(NameNode.java:865)
org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1573)
-
Locks info:
-
java.util.concurrent.locks.ReentrantReadWriteLock$FairSync@cd6c71a lockedBy
Thread 43 (IPC Server handler 7 on 8020)
Waiting thread num: 6
Stack:
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameTo(FSNamesystem.java:3665)
org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.rename(NameNodeRpcServer.java:868)
org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.rename(ClientNamenodeProtocolServerSideTranslatorPB.java:583)
org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
[jira] [Updated] (HADOOP-15335) Support xxxxxxx:xxx/stacks print lock info and more useful attribute of thread info
[ https://issues.apache.org/jira/browse/HADOOP-15335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yiran Wu updated HADOOP-15335: -- Status: Open (was: Patch Available) > Support xxx:xxx/stacks print lock info and more useful attribute of > thread info > --- > > Key: HADOOP-15335 > URL: https://issues.apache.org/jira/browse/HADOOP-15335 > Project: Hadoop Common > Issue Type: Improvement > Components: common >Affects Versions: 3.0.0 >Reporter: Yiran Wu >Priority: Major > Attachments: HADOOP-15335.001.patch, HADOOP-15335.002.patch > > > Print stack information and other info show in WebUI > http://namenode:50070/stacks?contentionTracing=true > ``` > Thread 2 (Reference Handler): > State: WAITING > Blocked count: 8 > Waited count: 5 > Thread CpuTime: 591 > Thread UserTime: 5754000 > Thread allocatedBytes: 0 > Waiting on java.lang.ref.Reference$Lock@4b3ed2f0 > Blocked by -1 > Stack: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:502) > java.lang.ref.Reference.tryHandlePending(Reference.java:191) > java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153) > Thread 1 (main): > State: WAITING > Blocked count: 4 > Waited count: 2 > Thread CpuTime: 2563937000 > Thread UserTime: 977000 > Thread allocatedBytes: 229115520 > Waiting on org.apache.hadoop.ipc.ProtobufRpcEngine$Server@442a2e48 > Blocked by -1 > Stack: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:502) > org.apache.hadoop.ipc.Server.join(Server.java:2498) > > org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.join(NameNodeRpcServer.java:442) > org.apache.hadoop.hdfs.server.namenode.NameNode.join(NameNode.java:865) > org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1573) > - > Locks info: > - > java.util.concurrent.locks.ReentrantReadWriteLock$FairSync@cd6c71a lockedBy > Thread 43 (IPC Server handler 7 on 8020) > Waiting thread num: 6 > Stack: > > org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameTo(FSNamesystem.java:3665) > > org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.rename(NameNodeRpcServer.java:868) > > org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.rename(ClientNamenodeProtocolServerSideTranslatorPB.java:583) > > org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java) > > org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616) > org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969) > org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2076) > org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2072) > java.security.AccessController.doPrivileged(Native Method) > javax.security.auth.Subject.doAs(Subject.java:422) > > org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1803) > org.apache.hadoop.ipc.Server$Handler.run(Server.java:2072) > java.lang.ref.ReferenceQueue$Lock@31bcf236 lockedBy UNKNOW > java.lang.ref.Reference$Lock@4b3ed2f0 lockedBy UNKNOW > org.apache.hadoop.ipc.ProtobufRpcEngine$Server@442a2e48 lockedBy UNKNOW > ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-15335) Support xxxxxxx:xxx/stacks print lock info and more useful attribute of thread info
[ https://issues.apache.org/jira/browse/HADOOP-15335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yiran Wu updated HADOOP-15335: -- Attachment: HADOOP-15335.002.patch > Support xxx:xxx/stacks print lock info and more useful attribute of > thread info > --- > > Key: HADOOP-15335 > URL: https://issues.apache.org/jira/browse/HADOOP-15335 > Project: Hadoop Common > Issue Type: Improvement > Components: common >Affects Versions: 3.0.0 >Reporter: Yiran Wu >Priority: Major > Attachments: HADOOP-15335.001.patch, HADOOP-15335.002.patch > > > Print stack information and other info show in WebUI > http://namenode:50070/stacks?contentionTracing=true > ``` > Thread 2 (Reference Handler): > State: WAITING > Blocked count: 8 > Waited count: 5 > Thread CpuTime: 591 > Thread UserTime: 5754000 > Thread allocatedBytes: 0 > Waiting on java.lang.ref.Reference$Lock@4b3ed2f0 > Blocked by -1 > Stack: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:502) > java.lang.ref.Reference.tryHandlePending(Reference.java:191) > java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153) > Thread 1 (main): > State: WAITING > Blocked count: 4 > Waited count: 2 > Thread CpuTime: 2563937000 > Thread UserTime: 977000 > Thread allocatedBytes: 229115520 > Waiting on org.apache.hadoop.ipc.ProtobufRpcEngine$Server@442a2e48 > Blocked by -1 > Stack: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:502) > org.apache.hadoop.ipc.Server.join(Server.java:2498) > > org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.join(NameNodeRpcServer.java:442) > org.apache.hadoop.hdfs.server.namenode.NameNode.join(NameNode.java:865) > org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1573) > - > Locks info: > - > java.util.concurrent.locks.ReentrantReadWriteLock$FairSync@cd6c71a lockedBy > Thread 43 (IPC Server handler 7 on 8020) > Waiting thread num: 6 > Stack: > > org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameTo(FSNamesystem.java:3665) > > org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.rename(NameNodeRpcServer.java:868) > > org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.rename(ClientNamenodeProtocolServerSideTranslatorPB.java:583) > > org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java) > > org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616) > org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969) > org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2076) > org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2072) > java.security.AccessController.doPrivileged(Native Method) > javax.security.auth.Subject.doAs(Subject.java:422) > > org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1803) > org.apache.hadoop.ipc.Server$Handler.run(Server.java:2072) > java.lang.ref.ReferenceQueue$Lock@31bcf236 lockedBy UNKNOW > java.lang.ref.Reference$Lock@4b3ed2f0 lockedBy UNKNOW > org.apache.hadoop.ipc.ProtobufRpcEngine$Server@442a2e48 lockedBy UNKNOW > ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-14445) Delegation tokens are not shared between KMS instances
[
https://issues.apache.org/jira/browse/HADOOP-14445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412915#comment-16412915
]
Rushabh S Shah commented on HADOOP-14445:
-
Thanks [~xiaochen] for the revision.
[~daryn] shared his concerns offline that this patch is dependent on config
key and we will live with the baggage of 2 tokens forever.
I will request him to review asap.
But below are my review comments Mostly all are minor.
+KMSClientProvider.java+
1. {{KMSCP#addTokenToCredentials}}
I don't agree with the method name. The method name suggests that we are just
adding token to credentials object.
But we are doing much more in this method.
I would add {{credentials.addToken}} line to calling method
{{addDelegationTokens}} and rename method {{addTokenToCredentials}} to
something like {{createLegacyKmsToken}}
and add some javadoc to it saying that creating this token is dependent on
conf key {{KMS_CLIENT_COPY_LEGACY_TOKEN_KEY}}.
+DelegationTokenAuthenticatedURL.java+
1. Lets change the {{selectDelegationToken}} to {{getDelegationToken}}.
In the base implementation, we are not implementing any Selector.
We are just getting the token based on the service field.
In {{KMSCP}} we can change the method name {{getKMSToken}} to
{{selectKMSToken}} because there we are implementing {{TokenSelector}}.
+core-default.xml+
{quote}With the default value set to true, the client will locally duplicate
the KMS_DELEGATION_TOKEN token and create a kms-dt token, all other parts of
the token remain the same.
{quote}
Technically this is not true. The service is also changed.
I am sorry I _should have_ mentioned all the above comments in the previous
review.
+TestKMS.java+
1. This is unrelated to patch.
Do we really want to stop kdc after every test ?
2. {{providersCreated}}: Should this be a list or just {{KeyProvider}} ?
It will always create {{LoadBalancingKeyProivder}} which internally is a set
of {{KeyProvider}}.
{{LoadBalancingKMSCP}} never throws IOException back. It just swallows all the
{{IOException}} and just logs it.
Maybe we might want to return MultipleIOException from
{{LoadBalancingKMSCP#close}}. Totally fine if we want to do it as a separate
jira.
But as far as this jira is concerned, we can get rid of
{{MultipleIOException}} related changes and can just change it to
{{IOException}}.
3. {{testKMSHAZKDelegationTokenRenewCancel(final Text tokenKind)}}
Unable to understand why were are calling {{setupConfForToken}} multiple times.
If we filter out all tokens other than passed {{tokenKind}}, then we can just
call {{setupConfForToken}} once at the start.
That way the code will be more clean and _will only_ work on {{token ==
tokenKind}}.
In short just one for loop, filter out the token at the start and test renew,
cancel and again renew(which should fail) in sequence.
4. {{testTokenCompatibilityOldRenewer}}
This test ran for {{34.887}} on my local machine.
I am sure majority of time was spent in sleeping for token to expire.
Can we decrease the {{renewInterval}} period to less than 30 seconds (maybe 5
seconds or so).
Also the test renewed the token 30 times. Is that expected ?
Did you mean to renew after while the code came out of while loop ?
{quote}LOG.info("Rolling key {} via provider {} with tokenUGi.",keyName);
kp.createKey("newkey", new KeyProvider.Options(conf));
{quote}
The log line should be {{creating a new key}} instead of {{Rolling key}}.
Let me know if any part is unclear.
> Delegation tokens are not shared between KMS instances
> --
>
> Key: HADOOP-14445
> URL: https://issues.apache.org/jira/browse/HADOOP-14445
> Project: Hadoop Common
> Issue Type: Bug
> Components: kms
>Affects Versions: 2.8.0, 3.0.0-alpha1
> Environment: CDH5.7.4, Kerberized, SSL, KMS-HA, at rest encryption
>Reporter: Wei-Chiu Chuang
>Assignee: Xiao Chen
>Priority: Major
> Attachments: HADOOP-14445-branch-2.8.002.patch,
> HADOOP-14445-branch-2.8.patch, HADOOP-14445.002.patch,
> HADOOP-14445.003.patch, HADOOP-14445.004.patch, HADOOP-14445.05.patch,
> HADOOP-14445.06.patch, HADOOP-14445.07.patch, HADOOP-14445.08.patch
>
>
> As discovered in HADOOP-14441, KMS HA using LoadBalancingKMSClientProvider do
> not share delegation tokens. (a client uses KMS address/port as the key for
> delegation token)
> {code:title=DelegationTokenAuthenticatedURL#openConnection}
> if (!creds.getAllTokens().isEmpty()) {
> InetSocketAddress serviceAddr = new InetSocketAddress(url.getHost(),
> url.getPort());
> Text service = SecurityUtil.buildTokenService(serviceAddr);
> dToken = creds.getToken(service);
> {code}
> But KMS doc states:
> {quote}
> Delegation Tokens
> Similar to HTTP authentication, KMS uses Hadoop
