[ 
https://issues.apache.org/jira/browse/SENTRY-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sravya Tirukkovalur updated SENTRY-1329:
----------------------------------------
    Description: 
After some preliminary testing of HMS NotificationLog in Sentry (SENTRY-1324), 
we see that NotificationLog does not capture some information today. See this 
[comment| 
https://issues.apache.org/jira/browse/SENTRY-1324?focusedCommentId=15330859&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15330859]
 for more information. 

So with respect to capturing this information, the minimally invasive approach 
is to just implement a custom MessageFactory 
(hcatalog.message.factory.impl.json), which takes care of the serialization and 
deseriazation of the message. We can just add additional information without 
causing disruption to other clients.

As I was implementing this, I encountered the problem that there is a small 
bug(in Hive trunk) which makes the MessageFactory not truly pluggable 
(HIVE-14011 - Attached a fix). But it would be a while before Hive can make a 
release with this fix and Sentry can move to this fixed version. 

So in the interim, we can implement the Listener in Sentry and use custom 
MessageFactory as well. I have done some testing on my side to make sure it 
does not break other clients.

  was:
After some preliminary testing of HMS NotificationLog in Sentry (SENTRY-1324), 
we see that NotificationLog does not capture some information today. See this 
[comment| ] for more information. 

Some of these, we might get by doing another getTable() call, but some of these 
are lost - For example in "alter table location", the only way to capture old 
location information is at the notification log. And we need this in Sentry to 
be able to properly revoke privileges on the old location. We might be able to 
relax this requirement if we make some architectural changes on how we store 
this HMS info in Sentry, but for now we need this information. Also, having 
this information will avoid the round trip.

So with respect to capturing this information, the minimally invasive approach 
is to just implement a custom MessageFactory 
(hcatalog.message.factory.impl.json), which takes care of the serialization and 
deseriazation of the message. We can just add additional information without 
causing disruption to other clients(BDR)

As I was implementing this, I encountered the problem that there is a small 
bug(in Hive trunk) which makes the MessageFactory not truly pluggable 
(HIVE-14011 - Attached a fix). But it would be while before Hive can make a 
release and Sentry can move to this fixed version. We need a backup plan.

So the next back plan is to implement the Listener in Sentry and use custom 
MessageFactory as well. I have done some testing on my side to make sure it 
does not break BDR- you should still be able to access the notification log and 
fields in the original message as is. But would be great if you (BDR folks) can 
give it a shot as well.



> Add additional information in the NotificationLog entry
> -------------------------------------------------------
>
>                 Key: SENTRY-1329
>                 URL: https://issues.apache.org/jira/browse/SENTRY-1329
>             Project: Sentry
>          Issue Type: Sub-task
>          Components: Hdfs Plugin
>            Reporter: Sravya Tirukkovalur
>            Assignee: Sravya Tirukkovalur
>             Fix For: sentry-ha-redesign
>
>         Attachments: SENTRY-1329.0.patch
>
>
> After some preliminary testing of HMS NotificationLog in Sentry 
> (SENTRY-1324), we see that NotificationLog does not capture some information 
> today. See this [comment| 
> https://issues.apache.org/jira/browse/SENTRY-1324?focusedCommentId=15330859&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15330859]
>  for more information. 
> So with respect to capturing this information, the minimally invasive 
> approach is to just implement a custom MessageFactory 
> (hcatalog.message.factory.impl.json), which takes care of the serialization 
> and deseriazation of the message. We can just add additional information 
> without causing disruption to other clients.
> As I was implementing this, I encountered the problem that there is a small 
> bug(in Hive trunk) which makes the MessageFactory not truly pluggable 
> (HIVE-14011 - Attached a fix). But it would be a while before Hive can make a 
> release with this fix and Sentry can move to this fixed version. 
> So in the interim, we can implement the Listener in Sentry and use custom 
> MessageFactory as well. I have done some testing on my side to make sure it 
> does not break other clients.



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

Reply via email to