[ 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)