https://issues.apache.org/jira/browse/HBASE-19397
We aim to move the peer modification framework from zk watcher to procedure v2 in this issue and the work is done now. Copy the release note here: Introduce 5 procedures to do peer modifications: > AddPeerProcedure > RemovePeerProcedure > UpdatePeerConfigProcedure > EnablePeerProcedure > DisablePeerProcedure > > The procedures are all executed with the following stage: > 1. Call pre CP hook, if an exception is thrown then give up > 2. Check whether the operation is valid, if not then give up > 3. Update peer storage. Notice that if we have entered this stage, then we > can not rollback any more. > 4. Schedule sub procedures to refresh the peer config on every RS. > 5. Do post cleanup if any. > 6. Call post CP hook. The exception thrown will be ignored since we have > already done the work. > > The procedure will hold an exclusive lock on the peer id, so now there is > no concurrent modifications on a single peer. > > And now it is guaranteed that once the procedure is done, the peer > modification has already taken effect on all RSes. > > Abstracte a storage layer for replication peer/queue manangement, and > refactored the upper layer to remove zk related naming/code/comment. > > Add pre/postExecuteProcedures CP hooks to RegionServerObserver, and add > permission check for executeProcedures method which requires the caller to > be system user or super user. > > On rolling upgrade: just do not do any replication peer modifications > during the rolling upgrading. There is no pb/layout changes on the > peer/queue storage on zk. > And there are other benefits. First, we have introduced a general procedure framework to send tasks to RS and report the report back to Master. It can be used to implement other operations such as ACL change. Second, zk is used as a external storage now since we do not depend on zk watcher any more, it will be much easier to implement a 'table based' replication peer/queue storage. Please vote: [+1] Agree [-1] Disagree [0] Neutral Thanks.
