Piggybacking on this thread, Bill Farner and I (from Aurora) have been
working on pure JVM bindings for Mesos.
The code is here [1]. It's currently in a pretty rough state but we have a
demo scheduler that connects, authenticates, registers and launches Hello
World tasks.
We'd love to get feedback, pull requests, etc. Once it's in a reasonable
state we hope to use it in Aurora (and hope to maintain it as a separate
library the whole community can use).
[1] https://github.com/kevints/mesos-framework-api
On Thu, Jul 17, 2014 at 12:11 PM, Tim St Clair tstcl...@redhat.com wrote:
--
*From: *Niklas Nielsen nik...@mesosphere.io
*To: *user@mesos.apache.org
*Sent: *Thursday, July 17, 2014 1:53:49 PM
*Subject: *Re: Mesos language bindings in the wild
-1 for git submodules. I am really not keen on those; worked with them
while working on Chromium and it was, to be frank, a mess to handle, update
and maintain.
Yeah... it can become unwieldy.
I am rooting for separate repos. Maybe worth a non-binding vote?
+1 (provided shared testing).
Niklas
On 17 July 2014 11:45, Tim St Clair tstcl...@redhat.com wrote:
Inline -
--
*From: *Vladimir Vivien vladimir.viv...@gmail.com
*To: *user@mesos.apache.org
*Sent: *Tuesday, July 15, 2014 1:34:37 PM
*Subject: *Re: Mesos language bindings in the wild
Hi all,
Apologies for being super late to this thread. To answer Niklas point
at the start of the thread: Yes, I am thrilled to contribute in anyway I
can. The project is moving forward and making progress (slower than I
want, but progress regardless).
Going Native
Implementing a native client for Mesos is an arduous process right now
since there's little doc to guide developers. Once I went through C++ code
and a few emails, it became easy (even easier than I thought). If the push
is for more native client, at some point we will need basic internals to be
documented.
Mesos-Certified
Maybe a Mesos test suite can be used to certify native clients. There
are tons of unit tests in the code that already validate the source code.
Maybe some of those test logic can be pulled out / copied into a small
stand-alone mesos test server that clients can communicate with to run a
test suite (just an idea). This along with some documentation would help
with quality of native clients.
+1.
In or Out of Core
Having native clients source hosted in core would be great since all code
would be in one location. Go code can certainly co-exist a subproject in
Mesos. Go's build workflow can be driven by Make. Go's dependency
management can work with repo subdirectories (at least according to 'go
help importpath', I haven't tested that myself). But, as Tom pointed out,
the thing that raises a flag for me is project velocity. If author wants
to move faster or slower than Mesos release cycles, there's no way to do so
once the code is part of core.
Anyway, I have gone on long enough. Looking for ward to feedback.
I usually don't tread here, but perhaps a git-submodule works in this
narrow case.
Thoughts?
On Tue, Jul 15, 2014 at 10:07 AM, Tim St Clair tstcl...@redhat.com
wrote:
Tom -
I understand the desire to create bindings outside the core. The point
I was trying to make earlier around version semantics and testing was to
'Hedge' the risk. It basically creates a contract between core
framework+bindings writers.
No one ever intends to break compatibility, but it happens all the time
and usually in some very subtle ways at first. A great example of this is
a patch I recently submitted to Mesos where the cgroup code was writing an
extra endln out. Earlier versions of the kernel had no issue with this,
but recent modifications would cause the cgroup code to fail. Very subtle,
and boom-goes-the-dynamite.
Below was an email I sent a while back, that outlines a possible
hedge/contract. Please let me know what you think.
--
Greetings!
I've conversed with folks about the idea of having a more formalized
release
and branching strategy, such that others who are downstream can rely on
certain version semantics when planning upgrades, etc. This becomes
doubly
important as we start to trend towards a 1.0 release, and folks will
depend
heavily on it for their core infrastructure, and APIs (Frameworks, and
EC).
Therefore, I wanted to propose a more formalized branching and release
strategy, and see what others think. I slightly modified this pattern
from
the Condor Kernel projects, which have well established processes.
--
Basic Idea:
1.) Create 2 Main Branches (Stable/Devel-Master based)
2.) Devel releases are cadence/time based and lightly tested.
3.) Stable series only accepts bug fixes. Merge path for all bug fixes
deemed worthy, are through the stable series up to master.
4.) @ some point devel
