[jira] [Commented] (SENTRY-1874) Do not require quiet HMS when taking initial HMS snapshot

2017-08-14 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/SENTRY-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125981#comment-16125981
 ] 

Hadoop QA commented on SENTRY-1874:
---

Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12881584/SENTRY-1874.02.patch 
against master.

{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/3154/console

This message is automatically generated.

> Do not require quiet HMS when taking initial HMS snapshot
> -
>
> Key: SENTRY-1874
> URL: https://issues.apache.org/jira/browse/SENTRY-1874
> Project: Sentry
>  Issue Type: Bug
>  Components: Sentry
>Affects Versions: 2.0.0
>Reporter: Alexander Kolbasov
>Assignee: Alexander Kolbasov
>  Labels: sentry-ha
> Fix For: 2.0.0
>
> Attachments: SENTRY-1874.02.patch
>
>
> When Sentry starts initially, it needs to get a full snapshot from HMS and 
> associate it with a specific notification ID. HMS does not provide any 
> mechanism to get a consistent snapshot with known notification ID. SO Sentry 
> does the following:
> 1) Read current notification ID_0
> 2) Obtain full snapshot from HMS
> 3) Read current notification ID_1
> 4) If (ID_0 != ID_1) goto 1.
> This creates a problem that the process may never converge when there is some 
> constant stream of HMS activity affecting notification IDs. We would like to 
> be able to use a problem that can converge in the presence of updates.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (SENTRY-1874) Do not require quiet HMS when taking initial HMS snapshot

2017-08-11 Thread Alexander Kolbasov (JIRA)

[ 
https://issues.apache.org/jira/browse/SENTRY-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16123583#comment-16123583
 ] 

Alexander Kolbasov commented on SENTRY-1874:


I moved it around trying to convince Jenkins to pick up the build.

> Do not require quiet HMS when taking initial HMS snapshot
> -
>
> Key: SENTRY-1874
> URL: https://issues.apache.org/jira/browse/SENTRY-1874
> Project: Sentry
>  Issue Type: Bug
>  Components: Sentry
>Affects Versions: 2.0.0
>Reporter: Alexander Kolbasov
>Assignee: Alexander Kolbasov
>  Labels: sentry-ha
> Fix For: 2.0.0
>
> Attachments: SENTRY-1874.02.patch
>
>
> When Sentry starts initially, it needs to get a full snapshot from HMS and 
> associate it with a specific notification ID. HMS does not provide any 
> mechanism to get a consistent snapshot with known notification ID. SO Sentry 
> does the following:
> 1) Read current notification ID_0
> 2) Obtain full snapshot from HMS
> 3) Read current notification ID_1
> 4) If (ID_0 != ID_1) goto 1.
> This creates a problem that the process may never converge when there is some 
> constant stream of HMS activity affecting notification IDs. We would like to 
> be able to use a problem that can converge in the presence of updates.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (SENTRY-1874) Do not require quiet HMS when taking initial HMS snapshot

2017-08-11 Thread Na Li (JIRA)

[ 
https://issues.apache.org/jira/browse/SENTRY-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16123477#comment-16123477
 ] 

Na Li commented on SENTRY-1874:
---

[~akolb] Can you make this issue a subtask of sentry-872, like other HA related 
issues? This may help on getting build from Jekins build. You seems to make 
sentry-872 the parent, but the display still does not show the change.

> Do not require quiet HMS when taking initial HMS snapshot
> -
>
> Key: SENTRY-1874
> URL: https://issues.apache.org/jira/browse/SENTRY-1874
> Project: Sentry
>  Issue Type: Bug
>  Components: Sentry
>Affects Versions: 2.0.0
>Reporter: Alexander Kolbasov
>Assignee: Alexander Kolbasov
>  Labels: sentry-ha
> Fix For: 2.0.0
>
> Attachments: SENTRY-1874.02.patch
>
>
> When Sentry starts initially, it needs to get a full snapshot from HMS and 
> associate it with a specific notification ID. HMS does not provide any 
> mechanism to get a consistent snapshot with known notification ID. SO Sentry 
> does the following:
> 1) Read current notification ID_0
> 2) Obtain full snapshot from HMS
> 3) Read current notification ID_1
> 4) If (ID_0 != ID_1) goto 1.
> This creates a problem that the process may never converge when there is some 
> constant stream of HMS activity affecting notification IDs. We would like to 
> be able to use a problem that can converge in the presence of updates.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (SENTRY-1874) Do not require quiet HMS when taking initial HMS snapshot

2017-08-10 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/SENTRY-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16121875#comment-16121875
 ] 

Hadoop QA commented on SENTRY-1874:
---

Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12881265/SENTRY-1874.patch 
against master.

{color:red}Overall:{color} -1 due to an error

{color:red}ERROR:{color} failed to build with patch (exit code 1)

Console output: 
https://builds.apache.org/job/PreCommit-SENTRY-Build/3138/console

This message is automatically generated.

> Do not require quiet HMS when taking initial HMS snapshot
> -
>
> Key: SENTRY-1874
> URL: https://issues.apache.org/jira/browse/SENTRY-1874
> Project: Sentry
>  Issue Type: Sub-task
>  Components: Sentry
>Affects Versions: 2.0.0
>Reporter: Alexander Kolbasov
>Assignee: Alexander Kolbasov
>  Labels: sentry-ha
> Fix For: 2.0.0
>
> Attachments: SENTRY-1874.patch
>
>
> When Sentry starts initially, it needs to get a full snapshot from HMS and 
> associate it with a specific notification ID. HMS does not provide any 
> mechanism to get a consistent snapshot with known notification ID. SO Sentry 
> does the following:
> 1) Read current notification ID_0
> 2) Obtain full snapshot from HMS
> 3) Read current notification ID_1
> 4) If (ID_0 != ID_1) goto 1.
> This creates a problem that the process may never converge when there is some 
> constant stream of HMS activity affecting notification IDs. We would like to 
> be able to use a problem that can converge in the presence of updates.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (SENTRY-1874) Do not require quiet HMS when taking initial HMS snapshot

2017-08-09 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/SENTRY-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16121153#comment-16121153
 ] 

Hadoop QA commented on SENTRY-1874:
---

Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12881148/SENTRY-1874.01.patch 
against master.

{color:red}Overall:{color} -1 due to an error

{color:red}ERROR:{color} failed to build with patch (exit code 1)

Console output: 
https://builds.apache.org/job/PreCommit-SENTRY-Build/3137/console

This message is automatically generated.

> Do not require quiet HMS when taking initial HMS snapshot
> -
>
> Key: SENTRY-1874
> URL: https://issues.apache.org/jira/browse/SENTRY-1874
> Project: Sentry
>  Issue Type: Sub-task
>  Components: Sentry
>Affects Versions: 2.0.0
>Reporter: Alexander Kolbasov
>Assignee: Alexander Kolbasov
>  Labels: sentry-ha
> Fix For: 2.0.0
>
> Attachments: SENTRY-1874.01.patch
>
>
> When Sentry starts initially, it needs to get a full snapshot from HMS and 
> associate it with a specific notification ID. HMS does not provide any 
> mechanism to get a consistent snapshot with known notification ID. SO Sentry 
> does the following:
> 1) Read current notification ID_0
> 2) Obtain full snapshot from HMS
> 3) Read current notification ID_1
> 4) If (ID_0 != ID_1) goto 1.
> This creates a problem that the process may never converge when there is some 
> constant stream of HMS activity affecting notification IDs. We would like to 
> be able to use a problem that can converge in the presence of updates.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)