[
https://issues.apache.org/jira/browse/NIFI-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969957#comment-15969957
]
Joseph Niemiec commented on NIFI-3681:
--------------------------------------
I have a base implementation of the runnable thread for the leader process
done, and converting it into a CS now.
Looking for thoughts on what to do with the ZK Election to best secure it. I
could place it under /nifi/leadershipElections/$electionName/$voters and then
reuse the existing NiFi Kerberos Security ACLs on that to protect the elections
from other non-NiFi ZK users. It appears that ZK Clients are expecting a
typical JaaS config but named Client which worries me about the ability to
implement multiple users under differing ACLs as they will be subjected to the
same boot.properties jvm configuration and have JaaS name colision if we cant
specific a service name easily...
In the least if we move under using the /nifi/ root znode we can move away from
OPEN_ACL_UNSAFE on the znode creates easily. And move toward, CREATOR_ALL_ACL.
Then the worst thing would be someone creating multiple elections under the
same $electionName with their controller service. (//dreaming of a place where
there could be multiple implementations of leadership CS services living at
once.//)
> Controller Service for Processor Leader Elections
> --------------------------------------------------
>
> Key: NIFI-3681
> URL: https://issues.apache.org/jira/browse/NIFI-3681
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Joseph Niemiec
> Assignee: Joseph Niemiec
>
> Today I find a need for NiFi Cluster to allow a specific set of processors to
> perform a 'LeaderElection' of sorts to allow for a single processor to
> update the process shared cluster state with assignments (both initial and
> recovery.) The CS would be responsible for joining a Zookeeper group, the
> logic itself, performing new elections should an leader die, etc...
> At its core I envision a simple API provided by the CS
> * String - whoIsLeader
> * List[String] - aliveElectors
> * Long- LastElectionEpoch ? - Not sure about this, but would it be good to
> detect if an election occurred and the leader did not change but the election
> occured. Maybe a UUID-4?
> While thinking ZK is best as Clustered NiFi already requires it would there
> be value in implementing a standalone RAFT or PAXOS that runs at the cluster
> level?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
