[jira] [Updated] (SENTRY-1703) Solr-Sentry in kerberos mode makes too many KDC requests and returns unauthorized on KDC timeout
[
https://issues.apache.org/jira/browse/SENTRY-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tushar I updated SENTRY-1703:
-
Attachment: solr-sentry-test-master.zip
> Solr-Sentry in kerberos mode makes too many KDC requests and returns
> unauthorized on KDC timeout
>
>
> Key: SENTRY-1703
> URL: https://issues.apache.org/jira/browse/SENTRY-1703
> Project: Sentry
> Issue Type: Bug
> Components: Solr Plugin
>Affects Versions: 1.5.1
>Reporter: Tushar I
>Priority: Blocker
> Attachments: kdc.log.txt, solr-sentry-test-master.zip,
> stacktrace1.log.txt, stacktrace2.log.txt, stacktrace3.log.txt
>
>
> Sentry Version: 1.5.1-cdh5.8.0
> We are seeing intermittent authorization failures with Sentry Solr plugin in
> a Kerberos environment.
> 1. We are writing to Solr using the SolrJ client from within Spark jobs in a
> multi-node Spark/Hadoop cluster and frequently get authorization errors from
> Solr in individual spark tasks saying "User XX does not have privileges for
> YYcollection" which are generated by the Solr-Sentry plugin. (The user very
> well has access to the collection and it works fine rest of the times).
> 2. The root cause seems to be that on every Solr call from the client, Sentry
> reaches out to KDC on behalf of solr/hostname, thereby drowning the KDC in
> tons of requests per second, and at some point fails on a KDC timeout,
> throwing the exception:
> {{org.apache.sentry.binding.solr.authz.SentrySolrAuthorizationException: User
> XX does not have privileges for YYcollection}} to the calling client.
> I didn't get enough time to investigate why Sentry is making so many KDC
> calls, maybe it's doing it for each document in a batched Solr operation, or
> it logs in using keytab each time and doesn't cache the ticket, etc.
> Caching the result of {{authProvider.hasAccess()}} in SolrAuthzBinding.java
> for a reasonably short time might not be a bad idea.
> My question in the meantime is: Are there any tuning knobs to somehow reduce
> the load on KDC, or increase the KDC request timeout value, or anything along
> these lines?
> Relevant stacktraces captured from Solr Admin are attached:
> 1. stacktrace1.log : The timeout from KDC for sentry call
> 2. stacktrace2.log: When Sentry cannot authenticate with KDC due to # 1 above
> 3. stacktrace3.log: SolrException when {{authProvider.hasAccess()}} returns
> false due to # 2 above.
> Also attached is a _snippet_ from the KDC log - the full log bloats to 17 MB
> within a minute, full of messages like:
> {code}
> Apr 10 17:06:37 a0 krb5kdc[20427](info): TGS_REQ (1 etypes {23}) 10.0.0.1:
> ISSUE: authtime 1491818430, etypes {rep=23 tkt=23 ses=23},
> solr/a...@realm.com for sentry/a...@realm.com
> {code}
> This is reproducible in two separate clusters with different environments:
> CDH 5.10.1 and
> CDH 5.8.0
> Please let me know if I've left out any key information.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1703) Solr-Sentry in kerberos mode makes too many KDC requests and returns unauthorized on KDC timeout
[
https://issues.apache.org/jira/browse/SENTRY-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tushar I updated SENTRY-1703:
-
Attachment: solr-sentry-test.zip
> Solr-Sentry in kerberos mode makes too many KDC requests and returns
> unauthorized on KDC timeout
>
>
> Key: SENTRY-1703
> URL: https://issues.apache.org/jira/browse/SENTRY-1703
> Project: Sentry
> Issue Type: Bug
> Components: Solr Plugin
>Affects Versions: 1.5.1
>Reporter: Tushar I
>Priority: Blocker
> Attachments: kdc.log.txt, stacktrace1.log.txt, stacktrace2.log.txt,
> stacktrace3.log.txt
>
>
> Sentry Version: 1.5.1-cdh5.8.0
> We are seeing intermittent authorization failures with Sentry Solr plugin in
> a Kerberos environment.
> 1. We are writing to Solr using the SolrJ client from within Spark jobs in a
> multi-node Spark/Hadoop cluster and frequently get authorization errors from
> Solr in individual spark tasks saying "User XX does not have privileges for
> YYcollection" which are generated by the Solr-Sentry plugin. (The user very
> well has access to the collection and it works fine rest of the times).
> 2. The root cause seems to be that on every Solr call from the client, Sentry
> reaches out to KDC on behalf of solr/hostname, thereby drowning the KDC in
> tons of requests per second, and at some point fails on a KDC timeout,
> throwing the exception:
> {{org.apache.sentry.binding.solr.authz.SentrySolrAuthorizationException: User
> XX does not have privileges for YYcollection}} to the calling client.
> I didn't get enough time to investigate why Sentry is making so many KDC
> calls, maybe it's doing it for each document in a batched Solr operation, or
> it logs in using keytab each time and doesn't cache the ticket, etc.
> Caching the result of {{authProvider.hasAccess()}} in SolrAuthzBinding.java
> for a reasonably short time might not be a bad idea.
> My question in the meantime is: Are there any tuning knobs to somehow reduce
> the load on KDC, or increase the KDC request timeout value, or anything along
> these lines?
> Relevant stacktraces captured from Solr Admin are attached:
> 1. stacktrace1.log : The timeout from KDC for sentry call
> 2. stacktrace2.log: When Sentry cannot authenticate with KDC due to # 1 above
> 3. stacktrace3.log: SolrException when {{authProvider.hasAccess()}} returns
> false due to # 2 above.
> Also attached is a _snippet_ from the KDC log - the full log bloats to 17 MB
> within a minute, full of messages like:
> {code}
> Apr 10 17:06:37 a0 krb5kdc[20427](info): TGS_REQ (1 etypes {23}) 10.0.0.1:
> ISSUE: authtime 1491818430, etypes {rep=23 tkt=23 ses=23},
> solr/a...@realm.com for sentry/a...@realm.com
> {code}
> This is reproducible in two separate clusters with different environments:
> CDH 5.10.1 and
> CDH 5.8.0
> Please let me know if I've left out any key information.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1703) Solr-Sentry in kerberos mode makes too many KDC requests and returns unauthorized on KDC timeout
[
https://issues.apache.org/jira/browse/SENTRY-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tushar I updated SENTRY-1703:
-
Attachment: (was: solr-sentry-test-master.zip)
> Solr-Sentry in kerberos mode makes too many KDC requests and returns
> unauthorized on KDC timeout
>
>
> Key: SENTRY-1703
> URL: https://issues.apache.org/jira/browse/SENTRY-1703
> Project: Sentry
> Issue Type: Bug
> Components: Solr Plugin
>Affects Versions: 1.5.1
>Reporter: Tushar I
>Priority: Blocker
> Attachments: kdc.log.txt, stacktrace1.log.txt, stacktrace2.log.txt,
> stacktrace3.log.txt
>
>
> Sentry Version: 1.5.1-cdh5.8.0
> We are seeing intermittent authorization failures with Sentry Solr plugin in
> a Kerberos environment.
> 1. We are writing to Solr using the SolrJ client from within Spark jobs in a
> multi-node Spark/Hadoop cluster and frequently get authorization errors from
> Solr in individual spark tasks saying "User XX does not have privileges for
> YYcollection" which are generated by the Solr-Sentry plugin. (The user very
> well has access to the collection and it works fine rest of the times).
> 2. The root cause seems to be that on every Solr call from the client, Sentry
> reaches out to KDC on behalf of solr/hostname, thereby drowning the KDC in
> tons of requests per second, and at some point fails on a KDC timeout,
> throwing the exception:
> {{org.apache.sentry.binding.solr.authz.SentrySolrAuthorizationException: User
> XX does not have privileges for YYcollection}} to the calling client.
> I didn't get enough time to investigate why Sentry is making so many KDC
> calls, maybe it's doing it for each document in a batched Solr operation, or
> it logs in using keytab each time and doesn't cache the ticket, etc.
> Caching the result of {{authProvider.hasAccess()}} in SolrAuthzBinding.java
> for a reasonably short time might not be a bad idea.
> My question in the meantime is: Are there any tuning knobs to somehow reduce
> the load on KDC, or increase the KDC request timeout value, or anything along
> these lines?
> Relevant stacktraces captured from Solr Admin are attached:
> 1. stacktrace1.log : The timeout from KDC for sentry call
> 2. stacktrace2.log: When Sentry cannot authenticate with KDC due to # 1 above
> 3. stacktrace3.log: SolrException when {{authProvider.hasAccess()}} returns
> false due to # 2 above.
> Also attached is a _snippet_ from the KDC log - the full log bloats to 17 MB
> within a minute, full of messages like:
> {code}
> Apr 10 17:06:37 a0 krb5kdc[20427](info): TGS_REQ (1 etypes {23}) 10.0.0.1:
> ISSUE: authtime 1491818430, etypes {rep=23 tkt=23 ses=23},
> solr/a...@realm.com for sentry/a...@realm.com
> {code}
> This is reproducible in two separate clusters with different environments:
> CDH 5.10.1 and
> CDH 5.8.0
> Please let me know if I've left out any key information.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SENTRY-1643) AutoIncrement ChangeID of MSentryPermChange/MSentryPathChange may be error-prone
[
https://issues.apache.org/jira/browse/SENTRY-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975833#comment-15975833
]
Lei (Eddy) Xu commented on SENTRY-1643:
---
Looks promising. Thanks for this information, [~LinaAtAustin]
I will run some tests with this configuration to see how it works. Thanks.
> AutoIncrement ChangeID of MSentryPermChange/MSentryPathChange may be
> error-prone
>
>
> Key: SENTRY-1643
> URL: https://issues.apache.org/jira/browse/SENTRY-1643
> Project: Sentry
> Issue Type: Sub-task
> Components: Hdfs Plugin
>Affects Versions: sentry-ha-redesign
>Reporter: Hao Hao
>Assignee: Lei (Eddy) Xu
>Priority: Critical
> Fix For: sentry-ha-redesign
>
> Attachments: SENTRY-1643.00-sentry-ha-redesign.patch,
> SENTRY-1643.01-sentry-ha-redesign.patch,
> SENTRY-1643.02-sentry-ha-redesign.patch
>
>
> In MSentryPermChange/MSentryPathChange table, the changeID field is
> auto-increment.
> {noformat}
>
>
> {noformat}
> However, found through the integration unit test TestHDFSIntegration, the
> value does not seem to be correctly auto increased. e.g Instead of increasing
> by one for each new entry, it increased by some unexpected number.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SENTRY-1643) AutoIncrement ChangeID of MSentryPermChange/MSentryPathChange may be error-prone
[
https://issues.apache.org/jira/browse/SENTRY-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975820#comment-15975820
]
Na Li commented on SENTRY-1643:
---
based on
"http://www.datanucleus.org/products/accessplatform_2_1/datanucleus-accessplatform.pdf;
page 101, could setting "key-cache-size" to 1 solve this issue, instead of
letting application manage the Change_ID?
key-cache-size: number of unique identifiers to cache. The keys are
pre-allocated, cached and used on demand. If key-cache-size is greater than 1,
it may generate holes in the object keys in the database, if not all keys are
used. Refer to persistence property
datanucleus.valuegeneration.increment.allocationSize. No. Defaults to 10
...
> AutoIncrement ChangeID of MSentryPermChange/MSentryPathChange may be
> error-prone
>
>
> Key: SENTRY-1643
> URL: https://issues.apache.org/jira/browse/SENTRY-1643
> Project: Sentry
> Issue Type: Sub-task
> Components: Hdfs Plugin
>Affects Versions: sentry-ha-redesign
>Reporter: Hao Hao
>Assignee: Lei (Eddy) Xu
>Priority: Critical
> Fix For: sentry-ha-redesign
>
> Attachments: SENTRY-1643.00-sentry-ha-redesign.patch,
> SENTRY-1643.01-sentry-ha-redesign.patch,
> SENTRY-1643.02-sentry-ha-redesign.patch
>
>
> In MSentryPermChange/MSentryPathChange table, the changeID field is
> auto-increment.
> {noformat}
>
>
> {noformat}
> However, found through the integration unit test TestHDFSIntegration, the
> value does not seem to be correctly auto increased. e.g Instead of increasing
> by one for each new entry, it increased by some unexpected number.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1649) Initialize HMSFollower when sentry server actually starts
[ https://issues.apache.org/jira/browse/SENTRY-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Na Li updated SENTRY-1649: -- Attachment: SENTRY-1649.023-sentry-ha-redesign.patch create HMSFollower in startHMSFollower and await termination after HMSFollower executor shutdownNow(). V23 > Initialize HMSFollower when sentry server actually starts > - > > Key: SENTRY-1649 > URL: https://issues.apache.org/jira/browse/SENTRY-1649 > Project: Sentry > Issue Type: Sub-task > Components: Hdfs Plugin >Affects Versions: sentry-ha-redesign >Reporter: Hao Hao >Assignee: Na Li >Priority: Critical > Fix For: sentry-ha-redesign > > Attachments: lina_test.patch, > SENTRY-1649.001-sentry-ha-redesign.patch, > SENTRY-1649.002-sentry-ha-redesign.patch, > SENTRY-1649.003-sentry-ha-redesign.patch, > SENTRY-1649.004-sentry-ha-redesign.patch, > SENTRY-1649.005-sentry-ha-redesign.patch, > SENTRY-1649.006-sentry-ha-redesign.patch, > SENTRY-1649.007-sentry-ha-redesign.patch, > SENTRY-1649.008-sentry-ha-redesign.patch, > SENTRY-1649.009-sentry-ha-redesign.patch, > SENTRY-1649.010-sentry-ha-redesign.patch, > SENTRY-1649.011-sentry-ha-redesign.patch, > SENTRY-1649.012-sentry-ha-redesign.patch, > SENTRY-1649.013-sentry-ha-redesign.patch, > SENTRY-1649.014-sentry-ha-redesign.patch, > SENTRY-1649.015-sentry-ha-redesign.patch, > SENTRY-1649.016-sentry-ha-redesign.patch, > SENTRY-1649.017-sentry-ha-redesign.patch, > SENTRY-1649.018-sentry-ha-redesign.patch, > SENTRY-1649.019-sentry-ha-redesign.patch, > SENTRY-1649.020-sentry-ha-redesign.patch, > SENTRY-1649.021-sentry-ha-redesign.patch, > SENTRY-1649.022-sentry-ha-redesign.patch, > SENTRY-1649.023-sentry-ha-redesign.patch > > > Now HMSFollower has been initialized at the constructor of SentryService. It > would be better to initialize it when the service starts, e.g runServer(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1706) Remove value-strategy for delta change tables.
[
https://issues.apache.org/jira/browse/SENTRY-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975777#comment-15975777
]
Lei (Eddy) Xu commented on SENTRY-1706:
---
It is interesting that, after removing the value strategy of
{{MSentryPermChange}} and {{MSentryPathChange}}, it raises plenty of dead lock
exception:
{code}
java.sql.SQLTransactionRollbackException: A lock could not be obtained due to a
deadlock, cycle of locks and waiters is:
Lock : ROW, SENTRY_PERM_CHANGE, (1,19)
Waiting XID : {1793, S} , SENTRY, SELECT MAX(A0.CHANGE_ID) FROM
SENTRY_PERM_CHANGE A0
Granted XID : {1769, S} , {1770, S} , {1771, S}
Lock : ROW, SENTRY_PERM_CHANGE, (1,15)
Waiting XID : {1771, X} , SENTRY, INSERT INTO SENTRY_PERM_CHANGE
(PERM_CHANGE,CREATE_TIME_MS,CHANGE_ID) VALUES (?,?,?)
Lock : ROW, SENTRY_PERM_CHANGE, (1,15)
Waiting XID : {1770, X} , SENTRY, INSERT INTO SENTRY_PERM_CHANGE
(PERM_CHANGE,CREATE_TIME_MS,CHANGE_ID) VALUES (?,?,?)
Granted XID : {1761, S} , {1763, S} , {1764, S} , {1769, S} , {1770, S} ,
{1771, S} , {1780, S} , {1783, S} , {1785, S} , {1787, S} , {1792, S} , {1793,
S}
. The selected victim is XID : 1793.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
Source)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
Source)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown Source)
at
com.jolbox.bonecp.PreparedStatementHandle.executeQuery(PreparedStatementHandle.java:172)
at
org.datanucleus.store.rdbms.ParamLoggingPreparedStatement.executeQuery(ParamLoggingPreparedStatement.java:381)
at
org.datanucleus.store.rdbms.SQLController.executeStatementQuery(SQLController.java:559)
at
org.datanucleus.store.rdbms.query.JDOQLQuery.performExecute(JDOQLQuery.java:644)
at org.datanucleus.store.query.Query.executeQuery(Query.java:1786)
at org.datanucleus.store.query.Query.executeWithArray(Query.java:1672)
at org.datanucleus.store.query.Query.execute(Query.java:1654)
at org.datanucleus.api.jdo.JDOQuery.execute(JDOQuery.java:221)
at
org.apache.sentry.provider.db.service.persistent.SentryStore.getLastProcessedChangeIDCore(SentryStore.java:3113)
at
org.apache.sentry.provider.db.service.persistent.DeltaTransactionBlock.persistUpdate(DeltaTransactionBlock.java:86)
at
org.apache.sentry.provider.db.service.persistent.DeltaTransactionBlock.execute(DeltaTransactionBlock.java:52)
at
org.apache.sentry.provider.db.service.persistent.TransactionManager.executeTransaction(TransactionManager.java:151)
at
org.apache.sentry.provider.db.service.persistent.TestSentryStore$1.run(TestSentryStore.java:2826)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
Does it ring any bells for you, [~kkalyan], [~akolb], [~hahao].
> Remove value-strategy for delta change tables.
> --
>
> Key: SENTRY-1706
> URL: https://issues.apache.org/jira/browse/SENTRY-1706
> Project: Sentry
> Issue Type: Improvement
> Components: Sentry
>Affects Versions: sentry-ha-redesign
>Reporter: Lei (Eddy) Xu
>Assignee: Lei (Eddy) Xu
>Priority: Minor
>
> SENTRY-1643 introduces the logic of updating CHANGE ID in application logic,
> we dont need to specify its as auto increment field.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SENTRY-1669) HMSFollower should read current processed notification ID from database every time it runs
[ https://issues.apache.org/jira/browse/SENTRY-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975698#comment-15975698 ] Na Li commented on SENTRY-1669: --- [~kkalyan] Can you be more specific on what else to change to make sure the update-to-date notification ID will be used by the Sentry server as leader? Seems to me, it is sufficient to move "currentEventID = getLastProcessedNotificationID();" from constructor to run() > HMSFollower should read current processed notification ID from database every > time it runs > -- > > Key: SENTRY-1669 > URL: https://issues.apache.org/jira/browse/SENTRY-1669 > Project: Sentry > Issue Type: Sub-task > Components: Hdfs Plugin >Reporter: Hao Hao >Assignee: kalyan kumar kalvagadda >Priority: Blocker > Fix For: sentry-ha-redesign > > > Instead of using in-memory current processed notification ID, HMSFollower > should read the processed notification ID info from database every time it > runs. Otherwise, after failover, the new leader cannot get the correct > up-to-date processed notification ID. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1669) HMSFollower should read current processed notification ID from database every time it runs
[ https://issues.apache.org/jira/browse/SENTRY-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975688#comment-15975688 ] kalyan kumar kalvagadda commented on SENTRY-1669: - There will be some more changes need for this to be fool proof. > HMSFollower should read current processed notification ID from database every > time it runs > -- > > Key: SENTRY-1669 > URL: https://issues.apache.org/jira/browse/SENTRY-1669 > Project: Sentry > Issue Type: Sub-task > Components: Hdfs Plugin >Reporter: Hao Hao >Assignee: kalyan kumar kalvagadda >Priority: Blocker > Fix For: sentry-ha-redesign > > > Instead of using in-memory current processed notification ID, HMSFollower > should read the processed notification ID info from database every time it > runs. Otherwise, after failover, the new leader cannot get the correct > up-to-date processed notification ID. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (SENTRY-1669) HMSFollower should read current processed notification ID from database every time it runs
[ https://issues.apache.org/jira/browse/SENTRY-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975688#comment-15975688 ] kalyan kumar kalvagadda edited comment on SENTRY-1669 at 4/19/17 10:45 PM: --- There will be some more changes needed for this to be fool proof. was (Author: kkalyan): There will be some more changes need for this to be fool proof. > HMSFollower should read current processed notification ID from database every > time it runs > -- > > Key: SENTRY-1669 > URL: https://issues.apache.org/jira/browse/SENTRY-1669 > Project: Sentry > Issue Type: Sub-task > Components: Hdfs Plugin >Reporter: Hao Hao >Assignee: kalyan kumar kalvagadda >Priority: Blocker > Fix For: sentry-ha-redesign > > > Instead of using in-memory current processed notification ID, HMSFollower > should read the processed notification ID info from database every time it > runs. Otherwise, after failover, the new leader cannot get the correct > up-to-date processed notification ID. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (SENTRY-1362) add sentry ha e2e test back accommodating to the re-design
[ https://issues.apache.org/jira/browse/SENTRY-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda reassigned SENTRY-1362: --- Assignee: kalyan kumar kalvagadda > add sentry ha e2e test back accommodating to the re-design > -- > > Key: SENTRY-1362 > URL: https://issues.apache.org/jira/browse/SENTRY-1362 > Project: Sentry > Issue Type: Test > Components: Sentry, Test >Reporter: Anne Yu >Assignee: kalyan kumar kalvagadda > Fix For: sentry-ha-redesign > > > The old > [TestHaEnd2End.java|https://issues.apache.org/jira/secure/attachment/12812648/SENTRY-1316.008-sentry-ha-redesign.patch#file-20] > seems out of dated. Will need to add a new one to e2e framework. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (SENTRY-1424) Sentry HA client tests: master jira for all client related tests (retry, concurrency, correct exceptions etc.)
[ https://issues.apache.org/jira/browse/SENTRY-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda reassigned SENTRY-1424: --- Assignee: kalyan kumar kalvagadda > Sentry HA client tests: master jira for all client related tests (retry, > concurrency, correct exceptions etc.) > -- > > Key: SENTRY-1424 > URL: https://issues.apache.org/jira/browse/SENTRY-1424 > Project: Sentry > Issue Type: Bug > Components: Sentry, Test >Reporter: Anne Yu >Assignee: kalyan kumar kalvagadda > Fix For: sentry-ha-redesign > > > 1. client can connect to active; > 2. client can retry; > 3. multiple clients can concurrent connect; > 4. client can retry until find one active server; > 5. client throws correct exceptions; > 6. test pool client, not sure about the old client apis ? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1674) HMSFollower shouldn't print the same value of notification ID multiple times
[ https://issues.apache.org/jira/browse/SENTRY-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975452#comment-15975452 ] Na Li commented on SENTRY-1674: --- There are two things to clarify. "Let's focus on this issue. This issue is about avoiding logs in cases where there is update in HMS data. Do you agree that changes done for Sentry-1587 would this issue?" 1. This issue can be fixed simply and safely by changes for this issue. 2. The focus of SENTRY-1587 is not about this issue. Its code change that fixes this issue is a work around for a bug in HIVE-15761, and it introduces overhead and delay. I am OK to keep it temporarily before HIVE issue is fixed. I am NOT OK to take this approach to fix this issue permanently while we have a simple and safe alternative to fix it. "There is another JIRA (SENTRY-1669) for looking up the database to get the current notification id which will address the scenario you mentioned in your comment above." Changes in SENTRY-1649 has to make such change in order to allow start()/stop() HMSFollower multiple times in test. And it also fixes the issue in SENTRY-1669. Sorry for distracting the discussion with this scenario. I just thought about it and put it in writing. > HMSFollower shouldn't print the same value of notification ID multiple times > > > Key: SENTRY-1674 > URL: https://issues.apache.org/jira/browse/SENTRY-1674 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Affects Versions: sentry-ha-redesign >Reporter: Alexander Kolbasov >Assignee: Na Li >Priority: Minor > Labels: bite-sized, newbie > Fix For: sentry-ha-redesign > > Attachments: SENTRY-1674.002-sentry-ha-redesign.patch, > SENTRY-1674.004-sentry-ha-redesign.patch, > SENTRY-1674.005-sentry-ha-redesign.patch > > > HMSFollower currently prints current value of notification ID which usually > stays the same. This just pollutes logs. It should only print changes to the > value. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1669) HMSFollower should read current processed notification ID from database every time it runs
[ https://issues.apache.org/jira/browse/SENTRY-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975436#comment-15975436 ] Na Li commented on SENTRY-1669: --- Can be solved by changes in SENTRY-1649 > HMSFollower should read current processed notification ID from database every > time it runs > -- > > Key: SENTRY-1669 > URL: https://issues.apache.org/jira/browse/SENTRY-1669 > Project: Sentry > Issue Type: Sub-task > Components: Hdfs Plugin >Reporter: Hao Hao >Assignee: kalyan kumar kalvagadda >Priority: Blocker > Fix For: sentry-ha-redesign > > > Instead of using in-memory current processed notification ID, HMSFollower > should read the processed notification ID info from database every time it > runs. Otherwise, after failover, the new leader cannot get the correct > up-to-date processed notification ID. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1671) Provide HMSFollower healthcheck (metric)
[ https://issues.apache.org/jira/browse/SENTRY-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975430#comment-15975430 ] Mathew Crocker commented on SENTRY-1671: [~akolb] is there a specific metric you're trying to measure, or more of a yes/no canary ? > Provide HMSFollower healthcheck (metric) > > > Key: SENTRY-1671 > URL: https://issues.apache.org/jira/browse/SENTRY-1671 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Affects Versions: sentry-ha-redesign >Reporter: Alexander Kolbasov > Labels: metrics, observability, supportability > Fix For: sentry-ha-redesign > > > We can have a Sentry which doesn't communicate properly with HMS. We need to > expose a heal-thcheck that shows whether HMSFollower is functioning. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1674) HMSFollower shouldn't print the same value of notification ID multiple times
[ https://issues.apache.org/jira/browse/SENTRY-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975410#comment-15975410 ] kalyan kumar kalvagadda commented on SENTRY-1674: - [~lina...@cloudera.com] You are taking about a completely different issue. There is another JIRA (SENTRY-1669) for looking up the database to get the current notification id which will address the scenario you mentioned in your comment above. I will be submitting the changes for this once changes for Sentry-1587 are committed. Let's focus on this issue. This issue is about avoiding logs in cases where there is update in HMS data. Do you agree that changes done for Sentry-1587 would this issue? > HMSFollower shouldn't print the same value of notification ID multiple times > > > Key: SENTRY-1674 > URL: https://issues.apache.org/jira/browse/SENTRY-1674 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Affects Versions: sentry-ha-redesign >Reporter: Alexander Kolbasov >Assignee: Na Li >Priority: Minor > Labels: bite-sized, newbie > Fix For: sentry-ha-redesign > > Attachments: SENTRY-1674.002-sentry-ha-redesign.patch, > SENTRY-1674.004-sentry-ha-redesign.patch, > SENTRY-1674.005-sentry-ha-redesign.patch > > > HMSFollower currently prints current value of notification ID which usually > stays the same. This just pollutes logs. It should only print changes to the > value. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SENTRY-1686) Port SENTRY-1548 to sentry-ha-redesign branch
[ https://issues.apache.org/jira/browse/SENTRY-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda updated SENTRY-1686: Resolution: Fixed Status: Resolved (was: Patch Available) > Port SENTRY-1548 to sentry-ha-redesign branch > - > > Key: SENTRY-1686 > URL: https://issues.apache.org/jira/browse/SENTRY-1686 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Reporter: Alexander Kolbasov >Assignee: kalyan kumar kalvagadda >Priority: Critical > Fix For: sentry-ha-redesign > > Attachments: SENTRY-1548.002-sentry-ha-redesign.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1674) HMSFollower shouldn't print the same value of notification ID multiple times
[ https://issues.apache.org/jira/browse/SENTRY-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975382#comment-15975382 ] Na Li commented on SENTRY-1674: --- There is no conflict between Sentry-1674 and the work around by Hao at Sentry-1587. Right now, we can accept both changes. Once HIVE-15761 is done, we can remove the extra RPC in Hao's work around safely. Hao's change alone does not handle the following scenario: There are two Sentry servers. 1. Sentry_A was leader and processed events until EventID_3. 2. Then zookeeper elected Sentry_B as leader, and Sentry_B processed events until EventID_5. 3. Then zookeeper elected Sentry_A as leader again. Now, the latest EventId from HMS meta store is EventID_5, and Sentry_A wants to process the Events 4 and 5 (which are already processed by Sentry_B). Therefore, we need to commit my changes in SENTRY_1649 soon, so the currentEventID is polled from DB in each run (not just in HMSFollower constructor) > HMSFollower shouldn't print the same value of notification ID multiple times > > > Key: SENTRY-1674 > URL: https://issues.apache.org/jira/browse/SENTRY-1674 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Affects Versions: sentry-ha-redesign >Reporter: Alexander Kolbasov >Assignee: Na Li >Priority: Minor > Labels: bite-sized, newbie > Fix For: sentry-ha-redesign > > Attachments: SENTRY-1674.002-sentry-ha-redesign.patch, > SENTRY-1674.004-sentry-ha-redesign.patch, > SENTRY-1674.005-sentry-ha-redesign.patch > > > HMSFollower currently prints current value of notification ID which usually > stays the same. This just pollutes logs. It should only print changes to the > value. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1593) Implement client failover for Generic and NN clients
[
https://issues.apache.org/jira/browse/SENTRY-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975374#comment-15975374
]
Hadoop QA commented on SENTRY-1593:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12864069/SENTRY-1593.009-sentry-ha-redesign.patch
against sentry-ha-redesign.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to apply patch (exit code 1):
The patch does not appear to apply with p0, p1, or p2
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/2539/console
This message is automatically generated.
> Implement client failover for Generic and NN clients
>
>
> Key: SENTRY-1593
> URL: https://issues.apache.org/jira/browse/SENTRY-1593
> Project: Sentry
> Issue Type: Sub-task
> Components: Sentry
>Affects Versions: sentry-ha-redesign
>Reporter: Alexander Kolbasov
>Assignee: kalyan kumar kalvagadda
>Priority: Blocker
> Labels: HA
> Fix For: sentry-ha-redesign
>
> Attachments: old_service_client_class_diagram.png,
> SENTRY-1593.001-sentry-ha-redesign.patch,
> SENTRY-1593.002-sentry-ha-redesign.patch,
> SENTRY-1593.003-sentry-ha-redesign.patch,
> SENTRY-1593.004-sentry-ha-redesign.patch,
> SENTRY-1593.005-sentry-ha-redesign.patch,
> SENTRY-1593.006-sentry-ha-redesign.patch,
> SENTRY-1593.007-sentry-ha-redesign.patch,
> SENTRY-1593.009-sentry-ha-redesign.patch,
> service_client_class_diagram_latest_v1.png, service_client_class_diagram.png
>
>
> We need to have client failover logic for Generic service clients and Name
> Node clients. Currently only db policy clients have it implemented.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1593) Implement client failover for Generic and NN clients
[ https://issues.apache.org/jira/browse/SENTRY-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda updated SENTRY-1593: Attachment: (was: SENTRY-1593.009-sentry-ha-redesign.patch) > Implement client failover for Generic and NN clients > > > Key: SENTRY-1593 > URL: https://issues.apache.org/jira/browse/SENTRY-1593 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Affects Versions: sentry-ha-redesign >Reporter: Alexander Kolbasov >Assignee: kalyan kumar kalvagadda >Priority: Blocker > Labels: HA > Fix For: sentry-ha-redesign > > Attachments: old_service_client_class_diagram.png, > SENTRY-1593.001-sentry-ha-redesign.patch, > SENTRY-1593.002-sentry-ha-redesign.patch, > SENTRY-1593.003-sentry-ha-redesign.patch, > SENTRY-1593.004-sentry-ha-redesign.patch, > SENTRY-1593.005-sentry-ha-redesign.patch, > SENTRY-1593.006-sentry-ha-redesign.patch, > SENTRY-1593.007-sentry-ha-redesign.patch, > SENTRY-1593.009-sentry-ha-redesign.patch, > service_client_class_diagram_latest_v1.png, service_client_class_diagram.png > > > We need to have client failover logic for Generic service clients and Name > Node clients. Currently only db policy clients have it implemented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SENTRY-1593) Implement client failover for Generic and NN clients
[ https://issues.apache.org/jira/browse/SENTRY-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda updated SENTRY-1593: Attachment: SENTRY-1593.009-sentry-ha-redesign.patch > Implement client failover for Generic and NN clients > > > Key: SENTRY-1593 > URL: https://issues.apache.org/jira/browse/SENTRY-1593 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Affects Versions: sentry-ha-redesign >Reporter: Alexander Kolbasov >Assignee: kalyan kumar kalvagadda >Priority: Blocker > Labels: HA > Fix For: sentry-ha-redesign > > Attachments: old_service_client_class_diagram.png, > SENTRY-1593.001-sentry-ha-redesign.patch, > SENTRY-1593.002-sentry-ha-redesign.patch, > SENTRY-1593.003-sentry-ha-redesign.patch, > SENTRY-1593.004-sentry-ha-redesign.patch, > SENTRY-1593.005-sentry-ha-redesign.patch, > SENTRY-1593.006-sentry-ha-redesign.patch, > SENTRY-1593.007-sentry-ha-redesign.patch, > SENTRY-1593.009-sentry-ha-redesign.patch, > service_client_class_diagram_latest_v1.png, service_client_class_diagram.png > > > We need to have client failover logic for Generic service clients and Name > Node clients. Currently only db policy clients have it implemented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1678) Add test class to test refactored refactored config code
[
https://issues.apache.org/jira/browse/SENTRY-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975176#comment-15975176
]
Hadoop QA commented on SENTRY-1678:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12864033/SENTRY-1678.001-sentry-ha-redesign.patch
against sentry-ha-redesign.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/2537/console
This message is automatically generated.
> Add test class to test refactored refactored config code
>
>
> Key: SENTRY-1678
> URL: https://issues.apache.org/jira/browse/SENTRY-1678
> Project: Sentry
> Issue Type: Bug
>Reporter: kalyan kumar kalvagadda
>Assignee: kalyan kumar kalvagadda
> Attachments: SENTRY-1678.001-sentry-ha-redesign.patch
>
>
> Add test classes for SentryPolicyClientTransportConfig and
> SentryHdfsClientTransportConfig classes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SENTRY-1593) Implement client failover for Generic and NN clients
[
https://issues.apache.org/jira/browse/SENTRY-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975035#comment-15975035
]
Hadoop QA commented on SENTRY-1593:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12864040/SENTRY-1593.009-sentry-ha-redesign.patch
against sentry-ha-redesign.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to apply patch (exit code 1):
The patch does not appear to apply with p0, p1, or p2
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/2538/console
This message is automatically generated.
> Implement client failover for Generic and NN clients
>
>
> Key: SENTRY-1593
> URL: https://issues.apache.org/jira/browse/SENTRY-1593
> Project: Sentry
> Issue Type: Sub-task
> Components: Sentry
>Affects Versions: sentry-ha-redesign
>Reporter: Alexander Kolbasov
>Assignee: kalyan kumar kalvagadda
>Priority: Blocker
> Labels: HA
> Fix For: sentry-ha-redesign
>
> Attachments: old_service_client_class_diagram.png,
> SENTRY-1593.001-sentry-ha-redesign.patch,
> SENTRY-1593.002-sentry-ha-redesign.patch,
> SENTRY-1593.003-sentry-ha-redesign.patch,
> SENTRY-1593.004-sentry-ha-redesign.patch,
> SENTRY-1593.005-sentry-ha-redesign.patch,
> SENTRY-1593.006-sentry-ha-redesign.patch,
> SENTRY-1593.007-sentry-ha-redesign.patch,
> SENTRY-1593.009-sentry-ha-redesign.patch,
> service_client_class_diagram_latest_v1.png, service_client_class_diagram.png
>
>
> We need to have client failover logic for Generic service clients and Name
> Node clients. Currently only db policy clients have it implemented.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1593) Implement client failover for Generic and NN clients
[ https://issues.apache.org/jira/browse/SENTRY-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda updated SENTRY-1593: Attachment: (was: SENTRY-1593.009-sentry-ha-redesign.patch) > Implement client failover for Generic and NN clients > > > Key: SENTRY-1593 > URL: https://issues.apache.org/jira/browse/SENTRY-1593 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Affects Versions: sentry-ha-redesign >Reporter: Alexander Kolbasov >Assignee: kalyan kumar kalvagadda >Priority: Blocker > Labels: HA > Fix For: sentry-ha-redesign > > Attachments: old_service_client_class_diagram.png, > SENTRY-1593.001-sentry-ha-redesign.patch, > SENTRY-1593.002-sentry-ha-redesign.patch, > SENTRY-1593.003-sentry-ha-redesign.patch, > SENTRY-1593.004-sentry-ha-redesign.patch, > SENTRY-1593.005-sentry-ha-redesign.patch, > SENTRY-1593.006-sentry-ha-redesign.patch, > SENTRY-1593.007-sentry-ha-redesign.patch, > service_client_class_diagram_latest_v1.png, service_client_class_diagram.png > > > We need to have client failover logic for Generic service clients and Name > Node clients. Currently only db policy clients have it implemented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1593) Implement client failover for Generic and NN clients
[ https://issues.apache.org/jira/browse/SENTRY-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975028#comment-15975028 ] kalyan kumar kalvagadda commented on SENTRY-1593: - [~akolb] Attached the latest class diagram > Implement client failover for Generic and NN clients > > > Key: SENTRY-1593 > URL: https://issues.apache.org/jira/browse/SENTRY-1593 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Affects Versions: sentry-ha-redesign >Reporter: Alexander Kolbasov >Assignee: kalyan kumar kalvagadda >Priority: Blocker > Labels: HA > Fix For: sentry-ha-redesign > > Attachments: old_service_client_class_diagram.png, > SENTRY-1593.001-sentry-ha-redesign.patch, > SENTRY-1593.002-sentry-ha-redesign.patch, > SENTRY-1593.003-sentry-ha-redesign.patch, > SENTRY-1593.004-sentry-ha-redesign.patch, > SENTRY-1593.005-sentry-ha-redesign.patch, > SENTRY-1593.006-sentry-ha-redesign.patch, > SENTRY-1593.007-sentry-ha-redesign.patch, > SENTRY-1593.009-sentry-ha-redesign.patch, > service_client_class_diagram_latest_v1.png, service_client_class_diagram.png > > > We need to have client failover logic for Generic service clients and Name > Node clients. Currently only db policy clients have it implemented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SENTRY-1593) Implement client failover for Generic and NN clients
[ https://issues.apache.org/jira/browse/SENTRY-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda updated SENTRY-1593: Attachment: service_client_class_diagram_latest_v1.png > Implement client failover for Generic and NN clients > > > Key: SENTRY-1593 > URL: https://issues.apache.org/jira/browse/SENTRY-1593 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Affects Versions: sentry-ha-redesign >Reporter: Alexander Kolbasov >Assignee: kalyan kumar kalvagadda >Priority: Blocker > Labels: HA > Fix For: sentry-ha-redesign > > Attachments: old_service_client_class_diagram.png, > SENTRY-1593.001-sentry-ha-redesign.patch, > SENTRY-1593.002-sentry-ha-redesign.patch, > SENTRY-1593.003-sentry-ha-redesign.patch, > SENTRY-1593.004-sentry-ha-redesign.patch, > SENTRY-1593.005-sentry-ha-redesign.patch, > SENTRY-1593.006-sentry-ha-redesign.patch, > SENTRY-1593.007-sentry-ha-redesign.patch, > SENTRY-1593.009-sentry-ha-redesign.patch, > service_client_class_diagram_latest_v1.png, service_client_class_diagram.png > > > We need to have client failover logic for Generic service clients and Name > Node clients. Currently only db policy clients have it implemented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1649) Initialize HMSFollower when sentry server actually starts
[
https://issues.apache.org/jira/browse/SENTRY-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975004#comment-15975004
]
Hadoop QA commented on SENTRY-1649:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12864020/SENTRY-1649.022-sentry-ha-redesign.patch
against sentry-ha-redesign.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/2536/console
This message is automatically generated.
> Initialize HMSFollower when sentry server actually starts
> -
>
> Key: SENTRY-1649
> URL: https://issues.apache.org/jira/browse/SENTRY-1649
> Project: Sentry
> Issue Type: Sub-task
> Components: Hdfs Plugin
>Affects Versions: sentry-ha-redesign
>Reporter: Hao Hao
>Assignee: Na Li
>Priority: Critical
> Fix For: sentry-ha-redesign
>
> Attachments: lina_test.patch,
> SENTRY-1649.001-sentry-ha-redesign.patch,
> SENTRY-1649.002-sentry-ha-redesign.patch,
> SENTRY-1649.003-sentry-ha-redesign.patch,
> SENTRY-1649.004-sentry-ha-redesign.patch,
> SENTRY-1649.005-sentry-ha-redesign.patch,
> SENTRY-1649.006-sentry-ha-redesign.patch,
> SENTRY-1649.007-sentry-ha-redesign.patch,
> SENTRY-1649.008-sentry-ha-redesign.patch,
> SENTRY-1649.009-sentry-ha-redesign.patch,
> SENTRY-1649.010-sentry-ha-redesign.patch,
> SENTRY-1649.011-sentry-ha-redesign.patch,
> SENTRY-1649.012-sentry-ha-redesign.patch,
> SENTRY-1649.013-sentry-ha-redesign.patch,
> SENTRY-1649.014-sentry-ha-redesign.patch,
> SENTRY-1649.015-sentry-ha-redesign.patch,
> SENTRY-1649.016-sentry-ha-redesign.patch,
> SENTRY-1649.017-sentry-ha-redesign.patch,
> SENTRY-1649.018-sentry-ha-redesign.patch,
> SENTRY-1649.019-sentry-ha-redesign.patch,
> SENTRY-1649.020-sentry-ha-redesign.patch,
> SENTRY-1649.021-sentry-ha-redesign.patch,
> SENTRY-1649.022-sentry-ha-redesign.patch
>
>
> Now HMSFollower has been initialized at the constructor of SentryService. It
> would be better to initialize it when the service starts, e.g runServer().
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1678) Add test class to test refactored refactored config code
[ https://issues.apache.org/jira/browse/SENTRY-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda updated SENTRY-1678: Status: Patch Available (was: In Progress) > Add test class to test refactored refactored config code > > > Key: SENTRY-1678 > URL: https://issues.apache.org/jira/browse/SENTRY-1678 > Project: Sentry > Issue Type: Bug >Reporter: kalyan kumar kalvagadda >Assignee: kalyan kumar kalvagadda > Attachments: SENTRY-1678.001-sentry-ha-redesign.patch > > > Add test classes for SentryPolicyClientTransportConfig and > SentryHdfsClientTransportConfig classes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SENTRY-1678) Add test class to test refactored refactored config code
[ https://issues.apache.org/jira/browse/SENTRY-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda updated SENTRY-1678: Attachment: SENTRY-1678.001-sentry-ha-redesign.patch > Add test class to test refactored refactored config code > > > Key: SENTRY-1678 > URL: https://issues.apache.org/jira/browse/SENTRY-1678 > Project: Sentry > Issue Type: Bug >Reporter: kalyan kumar kalvagadda >Assignee: kalyan kumar kalvagadda > Attachments: SENTRY-1678.001-sentry-ha-redesign.patch > > > Add test classes for SentryPolicyClientTransportConfig and > SentryHdfsClientTransportConfig classes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SENTRY-1649) Initialize HMSFollower when sentry server actually starts
[ https://issues.apache.org/jira/browse/SENTRY-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Na Li updated SENTRY-1649: -- Attachment: SENTRY-1649.022-sentry-ha-redesign.patch move start HMSFollower at the start of runServer(). v22 > Initialize HMSFollower when sentry server actually starts > - > > Key: SENTRY-1649 > URL: https://issues.apache.org/jira/browse/SENTRY-1649 > Project: Sentry > Issue Type: Sub-task > Components: Hdfs Plugin >Affects Versions: sentry-ha-redesign >Reporter: Hao Hao >Assignee: Na Li >Priority: Critical > Fix For: sentry-ha-redesign > > Attachments: lina_test.patch, > SENTRY-1649.001-sentry-ha-redesign.patch, > SENTRY-1649.002-sentry-ha-redesign.patch, > SENTRY-1649.003-sentry-ha-redesign.patch, > SENTRY-1649.004-sentry-ha-redesign.patch, > SENTRY-1649.005-sentry-ha-redesign.patch, > SENTRY-1649.006-sentry-ha-redesign.patch, > SENTRY-1649.007-sentry-ha-redesign.patch, > SENTRY-1649.008-sentry-ha-redesign.patch, > SENTRY-1649.009-sentry-ha-redesign.patch, > SENTRY-1649.010-sentry-ha-redesign.patch, > SENTRY-1649.011-sentry-ha-redesign.patch, > SENTRY-1649.012-sentry-ha-redesign.patch, > SENTRY-1649.013-sentry-ha-redesign.patch, > SENTRY-1649.014-sentry-ha-redesign.patch, > SENTRY-1649.015-sentry-ha-redesign.patch, > SENTRY-1649.016-sentry-ha-redesign.patch, > SENTRY-1649.017-sentry-ha-redesign.patch, > SENTRY-1649.018-sentry-ha-redesign.patch, > SENTRY-1649.019-sentry-ha-redesign.patch, > SENTRY-1649.020-sentry-ha-redesign.patch, > SENTRY-1649.021-sentry-ha-redesign.patch, > SENTRY-1649.022-sentry-ha-redesign.patch > > > Now HMSFollower has been initialized at the constructor of SentryService. It > would be better to initialize it when the service starts, e.g runServer(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1649) Initialize HMSFollower when sentry server actually starts
[ https://issues.apache.org/jira/browse/SENTRY-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15974749#comment-15974749 ] Na Li commented on SENTRY-1649: --- After moving starting HMSfollower to end of runServer(). the following test fail Regression org.apache.sentry.tests.e2e.metastore.TestDbNotificationListenerSentryDeserializer.testAlterPartition Failing for the past 1 build (Since Failed#2535 ) Took 0.61 sec. Error Message Database N_db17 already exists Stacktrace org.apache.hadoop.hive.metastore.api.AlreadyExistsException: Database N_db17 already exists Standard Output 2017-04-19 04:54:17,617 (Thread-0) [INFO - org.apache.sentry.tests.e2e.hive.AbstractTestWithStaticConfiguration.setupTestStaticConfiguration(AbstractTestWithStaticConfiguration.java:284)] AbstractTestWithStaticConfiguration setupTestStaticConfiguration 2017-04-19 04:54:17,634 (Thread-0) [INFO - org.apache.sentry.tests.e2e.hive.AbstractTestWithStaticConfiguration.setupTestStaticConfiguration(AbstractTestWithStaticConfiguration.java:293)] BaseDir = /tmp/1492577657634-0 2017-04-19 04:54:18,329 (Thread-0) [INFO - org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:446)] starting cluster: numNameNodes=1, numDataNodes=2 Formatting using clusterid: testClusterID 2017-04-19 04:54:18,948 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.namenode.FSNamesystem.(FSNamesystem.java:716)] No KeyProvider found. 2017-04-19 04:54:18,948 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.namenode.FSNamesystem.(FSNamesystem.java:726)] fsLock is fair:true 2017-04-19 04:54:18,999 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager.(DatanodeManager.java:239)] dfs.block.invalidate.limit=1000 2017-04-19 04:54:19,000 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager.(DatanodeManager.java:245)] dfs.namenode.datanode.registration.ip-hostname-check=true 2017-04-19 04:54:19,001 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.blockmanagement.InvalidateBlocks.printBlockDeletionTime(InvalidateBlocks.java:71)] dfs.namenode.startup.delay.block.deletion.sec is set to 000:00:00:00.000 2017-04-19 04:54:19,003 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.blockmanagement.InvalidateBlocks.printBlockDeletionTime(InvalidateBlocks.java:76)] The block deletion will start around 2017 Apr 19 04:54:19 2017-04-19 04:54:19,006 (Thread-0) [INFO - org.apache.hadoop.util.LightWeightGSet.computeCapacity(LightWeightGSet.java:354)] Computing capacity for map BlocksMap 2017-04-19 04:54:19,006 (Thread-0) [INFO - org.apache.hadoop.util.LightWeightGSet.computeCapacity(LightWeightGSet.java:355)] VM type = 64-bit 2017-04-19 04:54:19,008 (Thread-0) [INFO - org.apache.hadoop.util.LightWeightGSet.computeCapacity(LightWeightGSet.java:356)] 2.0% max memory 1.8 GB = 36.4 MB 2017-04-19 04:54:19,009 (Thread-0) [INFO - org.apache.hadoop.util.LightWeightGSet.computeCapacity(LightWeightGSet.java:361)] capacity = 2^22 = 4194304 entries 2017-04-19 04:54:19,045 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.createBlockTokenSecretManager(BlockManager.java:358)] dfs.block.access.token.enable=false 2017-04-19 04:54:19,046 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.(BlockManager.java:344)] defaultReplication = 2 2017-04-19 04:54:19,046 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.(BlockManager.java:345)] maxReplication = 512 2017-04-19 04:54:19,048 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.(BlockManager.java:346)] minReplication = 1 2017-04-19 04:54:19,049 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.(BlockManager.java:347)] maxReplicationStreams = 2 2017-04-19 04:54:19,049 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.(BlockManager.java:348)] replicationRecheckInterval = 3000 2017-04-19 04:54:19,049 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.(BlockManager.java:349)] encryptDataTransfer= false 2017-04-19 04:54:19,049 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.(BlockManager.java:350)] maxNumBlocksToLog = 1000 2017-04-19 04:54:19,056 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.namenode.FSNamesystem.(FSNamesystem.java:746)] fsOwner = jenkins (auth:SIMPLE) 2017-04-19 04:54:19,057 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.namenode.FSNamesystem.(FSNamesystem.java:747)] supergroup = supergroup 2017-04-19 04:54:19,057 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.namenode.FSNamesystem.(FSNamesystem.java:748)] isPermissionEnabled = true 2017-04-19 04:54:19,057 (Thread-0) [INFO - org.apache.hadoop.hdfs.server.namenode.FSNamesystem.(FSNamesystem.java:759)] HA Enabled:
[jira] [Commented] (SENTRY-1674) HMSFollower shouldn't print the same value of notification ID multiple times
[ https://issues.apache.org/jira/browse/SENTRY-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15974572#comment-15974572 ] kalyan kumar kalvagadda commented on SENTRY-1674: - [~lina...@cloudera.com] I'm fine with fixing this either of the jira's. I'm concerned about the fix. As we know that ObjectStore.getNextNotification can return exception until HIVE-15761, I would prefer the change made by Hao. It's a safe solution. You had an opinion that it is not optimal. I would say, it if fine. HMSfollower is a background thread that runs periodically to get the updates from HMS. Most of times it might not see any updates. Situations where HMSfollower sees that there is an update, there will be two requests sent. That is not big deal. As HA is a new feature and lot of new functionality in place, I would prefer a change which is consistent. More over fixing HIVE-15761 upstream and backporting it to CDH is an additional effort that we have put. At this point we are not sure which version of Hive would be compatible with the new notification log mechanism that sentry is using for HA. There are a lot of variables there. Let's not depend on the fix for HIVE-15761. > HMSFollower shouldn't print the same value of notification ID multiple times > > > Key: SENTRY-1674 > URL: https://issues.apache.org/jira/browse/SENTRY-1674 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Affects Versions: sentry-ha-redesign >Reporter: Alexander Kolbasov >Assignee: Na Li >Priority: Minor > Labels: bite-sized, newbie > Fix For: sentry-ha-redesign > > Attachments: SENTRY-1674.002-sentry-ha-redesign.patch, > SENTRY-1674.004-sentry-ha-redesign.patch, > SENTRY-1674.005-sentry-ha-redesign.patch > > > HMSFollower currently prints current value of notification ID which usually > stays the same. This just pollutes logs. It should only print changes to the > value. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
