Hi Vinod,
We prepared a design doc earlier.
>From your words it seems like the best way to proceed is to fork Apache
Mesos, show that it works well with liboffkv, then try to merge it back
into your master.
Removing all reference to ZooKeeper throughout the codebase is a good idea,
and we
Hi Samuel,
Sorry for the delay in responding to this. I think a design doc for how you
would modularize the ZooKeeperStorage interface would be a good start.
Regarding liboffkv based modules for contender and detector, a design doc
would be good as well. But since those modules will be out of the
Anything we can do to help expedite this? - We really want to contribute to
Mesos and its ecosystem. - It would be great to have them all decoupled
from any particular consensus and key/value store. - Some significant new
use-cases, IMHO, that will be facilitated by this.
Samuel Marks
Charity
Hey was just a little confused as to if I'm waiting for your next response
or if you wanted me to respond…
Besides leader election and network membership, ZooKeeper is also utilized
in some JNI code through ZooKeeperStorage. But I'm not sure if those JNI
libraries are actually used.
So if we
Ah yes I forgot, the other piece is network membership for the replicated
log, through our zookeeper::Group related code. Is that what you're
referring to?
We could put that behind a module interface as well.
On Fri, Jun 12, 2020 at 9:10 PM Benjamin Mahler wrote:
> > Apache ZooKeeper is used
> Apache ZooKeeper is used for a number of different things in Mesos, with
> only leader election being customisable with modules. Your existing
modular
> functionality is insufficient for decoupling from Apache ZooKeeper.
Can you clarify which other functionality you're referring to? Mesos only
Apache ZooKeeper is used for a number of different things in Mesos, with
only leader election being customisable with modules. Your existing modular
functionality is insufficient for decoupling from Apache ZooKeeper.
We are ready and waiting to develop here.
As mentioned over our
AndreiS just reminded me that we have module interfaces for the master
detector and contender:
https://github.com/apache/mesos/blob/1.9.0/include/mesos/module/detector.hpp
https://github.com/apache/mesos/blob/1.9.0/include/mesos/module/contender.hpp
Following on from the discussion on GitHub and here on the mailing-list,
here is the proposal from me and my team:
--
Choice of approach
The “mediator” of every interaction with ZooKeeper in Mesos is the ZooKeeper
class, declared in
So it sounds like:
Zookeeper: Official C library has an async API. Are we gaining a lot with
the third party C++ wrapper you pointed to? Maybe it "just works", but it
looks very inactive and it's hard to tell how maintained it is.
Consul: No official C or C++ library. Only some third party C++
In terms of asynchronous vs synchronous interfacing, when we started
liboffkv, it had an asynchronous interface. Then we decided to drop it and
implemented a synchronous one, due to the dependent libraries which
liboffkv uses under the hood.
Our ZooKeeper implementation uses the zookeeper-cpp
Samuel: One more thing I forgot to mention, we would prefer to use an
asynchronous client interface rather than a synchronous one. Is that
something you have considered?
On Fri, Apr 17, 2020 at 6:11 PM Vinod Kone wrote:
> Hi Samuel,
>
> Thanks for showing interest in contributing to the
Actually I would be happy with foundationdb if need some help :)
On 4/18/20 7:10 AM, Vinod Kone wrote:
Hi Samuel,
Thanks for showing interest in contributing to the project. Having
optionality between ZooKeeper and Etcd would be great for the project and
something that has been brought up a
Hi Samuel,
Thanks for showing interest in contributing to the project. Having
optionality between ZooKeeper and Etcd would be great for the project and
something that has been brought up a few times before, as you noted.
I echo everything that BenM said. As part of the design it would be great
Happy to build a design doc,
To answer your question on what Offscale.io is, it's my software and
biomedical engineering consultancy. Currently it's still rather small, with
only 8 engineers, but I'm expecting & preparing to grow rapidly.
My philosophy is always open-source and patent-free, so
Oh ok, could you tell us a little more about how you're using Mesos? And
what offscale.io is?
Strictly speaking, we don't really need packaging and releases as we can
bundle the dependency in our repo and that's what we do for many of our
dependencies.
To me, the most important thing is the
Dear Benjamin Mahler [and *Developers mailing-list for Apache Mesos*],
Thanks for responding so quickly.
Actually this entire project I invested—time & money, including a
development team—explicitly in order to contribute this to Apache Mesos. So
no releases yet, because I wanted to ensure it
Thanks for reaching out, a well maintained and well written wrapper
interface to the three backends would certainly make this easier for us vs
implementing such an interface ourselves.
Is this the client interface?
18 matches
Mail list logo
