Sounds good to me. This effort [to make coordination engine that HBase uses pluggable] was started and work was done towards making dependency of ZK separated into the set of defined interfaces, but subsequent phases never were completed.
The proposed cleanup sounds good to me. Thanks for taking that up! -Mikhail On Mon, Oct 23, 2017 at 1:15 PM, Andrew Purtell <[email protected]> wrote: > Sounds good to me. > > > On Mon, Oct 23, 2017 at 1:00 PM, Apekshit Sharma <[email protected]> > wrote: > > > Thanks Andrew! > > > > How does the following cleanup sounds? > > > > - Remove the configuration hbase.coordinated.state.manager.class > > - Keep following interface since they nicely separate ZK based > > implementation: SplitLogWorkerCoordination, SplitLogManagerCoordination, > > ProcedureCoordinatorRpcs, ProcedureMemberRpcs > > - Replace CSM (interface) + BCSM (unnecessary middle hierarchy) with > single > > CSM interface. > > > > @InterfaceAudience.Private > > public interface CoordinatedStateManager { > > void initialize(Server server) > > SplitLogWorkerCoordination getSplitLogWorkerCoordination(); > > SplitLogManagerCoordination getSplitLogManagerCoordination(); > > ProcedureCoordinatorRpcs getProcedureCoordinatorRpcs(String procType, > > String coordNode) throws IOException; > > ProcedureMemberRpcs getProcedureMemberRpcs(String procType) throws > > KeeperException; > > } > > > > On Mon, Oct 23, 2017 at 12:37 PM, Andrew Purtell <[email protected]> > > wrote: > > > > > This work was done by a small development group at WANDisco. The intent > > was > > > to allow substitution of a proprietary consensus and state replication > > > service for ZooKeeper. There hasn't been progress on this for a long > > time. > > > I think it is safe for us to clean it up. No need necessarily to > abandon > > > the idea of abstraction between our coordination needs and the > > > implementation. > > > > > > > > > On Mon, Oct 23, 2017 at 12:16 PM, Apekshit Sharma <[email protected]> > > > wrote: > > > > > > > Hi everyone, > > > > > > > > Am coming from limited knowledge here, so pardon me if it seems > > > outrageous. > > > > I guess this effort (HBASE-10909 > > > > <https://issues.apache.org/jira/browse/HBASE-10909>) was to separate > > out > > > > state into an interface which was then made pluggable via the config > > > > hbase.coordinated.state.manager.class. > > > > > > > > - Is this effort complete? Can someone use it to completely switch > out > > ZK > > > > based state with something else? I see all tasks in HBASE-10909 > > > > <https://issues.apache.org/jira/browse/HBASE-10909> are complete, > but > > > it's > > > > named 'phase1' and i don't see a phase2. > > > > > > > > - Is anyone aware of any use cases where it's actually being used to > > > > replace zk? > > > > > > > > ** If yes, I think that at the very least, we should clean it up > (more > > on > > > > it further down) and made these relevant interfaced IA.Public. > > > > > > > > ** If not, can we get rid of the (incomplete??) 'feature' and do more > > > > rigorous cleanup? I'll sign up for it. > > > > --------- > > > > > > > > Cleanup: > > > > Our internal class hierarchy is: > > > > CoordinatedStateManager -> BaseCoordinatedStateManager -> > > > > ZkCoordinatedStateManager. > > > > > > > > - We carry around CSM objects but cast them to BCSM in so many > places! > > If > > > > anyone implements CSM and plugs it in, it won't work. Better to just > > > unify > > > > them and make it easier to understand. > > > > > > > > > > > > -- Appy > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Andrew > > > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > > decrepit hands > > > - A23, Crosstalk > > > > > > > > > > > -- > > > > -- Appy > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk > -- Thanks, Michael Antonov
