[
https://issues.apache.org/jira/browse/MESOS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13884748#comment-13884748
]
Benjamin Mahler commented on MESOS-930:
---------------------------------------
Glad to see you're taking the initiative here, and that you experienced Kazoo
first hand. For the long term, I definitely agree that pure language bindings
would be great!
{quote}
I don't think is true. Even now you cannot break Slave<->Executor protocol,
because that would force rebuilding all executors and maybe even changing
custom executor implementations. Every change should be backwards compatible.
So go on, add something to the protocol, 3rd party implementations will catch
up eventually if they need.
{quote}
Here, there are a few things to take note of. There are actually three pieces
involved here: Slave, Executor Driver, Executor. The protocol exists between
the first two, and the latter two interact through an API.
You're right that we do not break the network protocol between the slave and
the _driver_ (since protobuf is used, we typically add fields and ensure that
an N version slave works with an N-1 version executor driver, but no further
than that typically). At the current time, when we do a new release, executors
/ schedulers can safely lag by 1 version in terms of the drivers they are
linked statically or dynamically against.
What I meant more about "updating the bindings" was that we've been leveraging
the fact that we control the driver to provide sane upgrade paths, mostly
around re-shaping messages coming from executors / schedulers. This isn't a
sane long term strategy and I agree that we should focus on protocol, but these
are some of the hacks in place right now that are good to take note of.
*Re: how to proceed*
A google doc or RB would be a good start for documenting the protocol as it
stands today. But a design would also be nice around what we should do in terms
of project supported bindings, what changes (if any) we need to make to
libprocess, how we'll add changes to the protocol, how project versioning will
interact with protocol versioning, how to deal with semantic changes to the
protocol (same network message but additional semantics), etc. We could make
use of the project wiki for this instead of a google doc.
As the project reaches a 1.0 release, support for pure bindings would be
amazing, I'm excited to see your interest in this!
> Provide slave<->executor protocol
> ---------------------------------
>
> Key: MESOS-930
> URL: https://issues.apache.org/jira/browse/MESOS-930
> Project: Mesos
> Issue Type: Improvement
> Components: general
> Reporter: Nikita Vetoshkin
> Priority: Minor
>
> This ticket is the result of the discussion started in mailing list
> (http://www.mail-archive.com/[email protected]/msg05477.html).
> It would be great if Mesos provided protocol for slave<->executor
> communication additionally to currently provided c++ based language bindings.
> ocumenting
> wire protocol could open ways to implement Executors in pure python or
> golang or any other language. It could provide some benefits:
> * in Python one could use gevent which is pretty popular
> * golang has it's own eventloop builtin
> * pure language binding could save a lot of trouble bridging with
> unfriendly C++
> * building and using pure language client could be performed using native
> tools like `pip install` or `go get` without need to establish c++ dev
> environment.
> Before moving any further we need to decide, if this is actually a good thing
> to do. According to discussion in mail list - looks like it's worth doing.
> So next logical thing is to decide:
> * should protocol be something utterly new
> * should we document current protocol used by libprocess
> * should libprocess protocol be brushed a little before documenting it for
> external implementation
> While waiting for discussion I'd like to start documenting current protocol.
> Where can one do it in a way suitable for comments? RB?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
