[
https://issues.apache.org/jira/browse/HBASE-9864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13964275#comment-13964275
]
Andrew Purtell commented on HBASE-9864:
---------------------------------------
{quote}
bq. I'm a lot more concerned about a "revoke user" that doesn't get applied for
hours because someone was napping.
What you thinking Andrew? Chatting w/ Matteo, if a RS fails to update its
local cache, it should abort as we would not being able to update our WAL. No
napping allowed.
{quote}
I'm worried about missed notifications, and more generally about proving at the
time the update is done that it was applied everywhere, because security guys
like proof.
bq. You need something in the 0.98 timeframe too boss?
Thinking about it yes. We have other security fixes and refinements on deck.
Thinking is 0.98 is the security proving ground ahead of 1.0+.
> Notifications bus for use by cluster members keeping up-to-date on changes
> --------------------------------------------------------------------------
>
> Key: HBASE-9864
> URL: https://issues.apache.org/jira/browse/HBASE-9864
> Project: HBase
> Issue Type: Brainstorming
> Reporter: stack
> Priority: Blocker
> Fix For: 1.0.0
>
>
> In namespaces and acls, zk callbacks are used so all participating servers
> are notified when there is a change in acls/namespaces list.
> The new visibility tags feature coming in copies the same model of using zk
> with listeners for the features' particular notifications.
> Three systems each w/ their own implementation of the notifications all using
> zk w/ their own feature-specific watchers.
> Should probably unify.
> Do we have to go via zk? Seems like all want to be notified when an hbase
> table is updated. Could we tell servers directly rather than go via zk?
--
This message was sent by Atlassian JIRA
(v6.2#6252)