If adding support for etcd I also think that Zookeeper should be supported
as it is similar but is Apache and Java based.

On Thu, Jan 15, 2026 at 10:50 AM Clebert Suconic <[email protected]>
wrote:

> I am working on a feature that would allow the leader/follower usage
> on acceptors.
>
> An acceptor would be waiting for a lock, and it would start the
> acceptor when the lock is acquired, and stop when the lock is lost.
>
>
> I am working to add a few types of locks:
>
> - etcd
> - fileShared
> - JDBC
>
>
>
> I have a few questions on the implementation:
>
>
> i - is etcd useful on the openshift world?
>
> it seems that the PODs will not have access to etcd directly and an
> operator is supposed to prepare the lock in some indirect way. ETCD
> might still be useful for standalone, but perhaps this is not a good
> fit for the openshift world.
>
>
>
>
> ii - netty and vertx implementation.
>
> I am playing https://github.com/etcd-io/jetcd, and it is bring vertx and
> netty.
> Currently I had to revert back one version as the netty version is
> clashing with our current netty usage. What brings me to think.. is
> this the right approach since it will bring vertx and netty as
> external dependencies from the library.
>
>
>
> iii - Perhaps I should skip the etcd option for now and only support
> fileLock and JDBC.
>
> iv - how to configure this.
>
>
> I'm planning to add something like leadership in the XML
>
>
> <leadership>
>    <leader lock-name="myLock" type="Type"> <!-- type being file, jdbc,
> or etcd (if we are still going for it) -->
>          <properties>
>           </properties>
>    </leader>
> </leadership>
>
>
> and on either acceptor or server
>
> <server leader="myLock"> ...
>
>
> <acceptor leader="myLock">
>
>
>
> the idea is that one leader choice could be able to start or stop
> multiple objects (in this case for now, server or acceptors).. you
> could have multiple acceptors towards the same leadership ellection.
>
>
>
> any feedback is appreciated.
>
>
>
> --
> Clebert Suconic
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to