Jenkins builds failing for CentOS 7

Hey all, Jenkins builds are now consistently failing for centos 7, withe the failure: checking value of Java system property 'java.home'... /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre configure: error: could not guess JAVA_HOME I ran into this problem a few days ago while build

Re: Jenkins builds failing for CentOS 7

ead of java-1.7.0-openjdk-devel, or move things around such that maven is installed AFTER we install java-1.7.0-openjdk-devel so that its dependence on java doesn't automatically pull in java-1.8.0-openjdk. On Wed, Dec 16, 2015 at 1:11 PM, Kevin Klues wrote: > Hey all, > > Jenkins

Re: Jenkins builds failing for CentOS 7

ersion-devel apr-utils-devel libevent-devel libev-devel" +append_dockerfile "RUN yum install -y clang git maven" # Add an unprivileged user. append_dockerfile "RUN adduser mesos" On Wed, Dec 16, 2015 at 1:34 PM, Kevin Klues wrote: > I'm assuming this is

Re: Jenkins builds failing for CentOS 7

I filed a JIRA for this: https://issues.apache.org/jira/browse/MESOS-4184 On Wed, Dec 16, 2015 at 1:59 PM, Kevin Klues wrote: > Verified that both solutions work. That is, either install > java-1.8.0-openjdk-devel instead of > java-1.7.0-openjdk-devel, or move things around such that

Re: Links in documentation

So by 2 you mean relative links to the *.md files vs 3 which is absolute (from the repos topdir). If so, +1 On Thu, Jan 14, 2016 at 11:39 AM, Joris Van Remoortere wrote: >> >> *In fact it seems that all links ending with .md are interpreted as >> relative links on the webpage, i.e. [label](https:

Re: .gitignore-template

+1 for Consistency! As a side note, I add custom .gitignore stuff in a global .gitignore file I install at ~/.gitignore. This is useful for ignoring things specific to editor temporary files (e.g. *.swo in vim), etc. you can make git aware of it via: $ git config --global core.excludesfile ~/.gi

Re: Follow up on the proposal for simulation tools for master and allocator

Count me in as well. On Thu, Jan 21, 2016 at 11:13 AM, Neil Conway wrote: > Hi Zhitao, > > There's a JIRA here: > > https://issues.apache.org/jira/browse/MESOS-3855 > > A few people who are interested in simulation of Mesos have been > meeting periodically, although due to the holidays we haven't

Re: Core affinity in Mesos

I agree. "Isolation" on it's own is too broad a term. However, since we are talking mostly about reducing interference, which typically implies performance isolation, my vote for the group name is the "Performance Isolation Working Group". On Fri, Jan 29, 2016 at 11:22 AM, Benjamin Mahler wrote:

Re: Inconsistent naming of support scripts

I prefer hyphens as well On Thu, Feb 11, 2016 at 1:28 PM, Jojy Varghese wrote: > hyphen++. Is google friendly apparently. Also less keys to press :) > > -Jojy > > > >> On Feb 11, 2016, at 12:43 PM, Greg Mann wrote: >> >> +1 >> >> On Thu, Feb 11, 2016 at 11:41 AM, Vinod Kone wrote: >> >>> S

Re: Inconsistent naming of support scripts

es in our repo use underscores. I would like us > to be consistent on how we name files in the repo. > > On Thu, Feb 11, 2016 at 1:40 PM, Kevin Klues wrote: > >> I prefer hyphens as well >> >> On Thu, Feb 11, 2016 at 1:28 PM, Jojy Varghese wrote: >> > hyphen++

Mesos binaries and shared library dependencies.

Hi all, A discussion came up recently around including rpaths in our mesos binaries to help resolve any shared library dependencies that don't exist in standard library paths (e.g. /lib, /usr/local/lib, etc.). By default, there are no shared library dependencies that exist in non-standard paths,

Re: Mesos binaries and shared library dependencies.

p in situations where we actually care about it. I'm curious what other people's thoughts are. On Fri, Feb 12, 2016 at 1:47 PM, Kevin Klues wrote: > Hi all, > > A discussion came up recently around including rpaths in our mesos > binaries to help resolve any shared libra

Re: Mesos binaries and shared library dependencies.

2016 at 2:34 PM, Jojy Varghese wrote: > Maybe have an opt-in (say —with-rpath)? > > -Jojy > >> On Feb 12, 2016, at 2:19 PM, Kevin Klues wrote: >> >> To be clear, I'm actually a bit torn both ways on this. >> >> On the one hand, including the

Re: Mesos binaries and shared library dependencies.

ather than setting the global LDFLAGS for all linked objects (as I was doing before). With this change, I can inspect libtools wrapper scripts to see that indeed it patches up the binary with the added rpaths, but libmesos itself has no rpath set. Pending any objections, a RR will be forthcoming. O

Re: Mesos binaries and shared library dependencies.

I was wrong. This unset the rpath in the binary, but left the rpath set in libmesos.so. I am going to leave this as an open issue for now, pending a better solution. On Fri, Feb 12, 2016 at 5:03 PM, Kevin Klues wrote: > Playing with this a bit more, I came up with a solution that bridges &g

Re: Enable compiler optimization by default?

+1 On Wed, Feb 17, 2016 at 4:24 PM, Neil Conway wrote: > Hi folks, > > At present, Mesos defaults to compiling with "-O0"; to enable compiler > optimizations, the user needs to specify "--enable-optimize". > > I'd like to propose we change the default, for a few reasons: > > (1) The autoconf defa

Re: Mesos binaries and shared library dependencies.

ion this is the proper way to do it. > > Regards, > Matthias > > Am 15.02.2016 um 00:31 schrieb Kevin Klues: >> I was wrong. This unset the rpath in the binary, but left the rpath >> set in libmesos.so. I am going to leave this as an open issue for >> now, pending a

Re: Reorganize 3rdparty directory

I am also a fan of git submodules in the long term, but avoiding them in the short term. We should get things organized as we want them first, and then start thinking about pulling libprocess/stout out into submodules later (while also preserving their history!) I disagree with moving libprocess

Re: Performance isolation working group meeting on Friday 10am PST

I'm having trouble joining the call. Keeps saying "Requesting to join the video call..." On Wed, Feb 24, 2016 at 12:12 PM, Niklas Nielsen wrote: > Hi all, > > We will meet and talk performance isolation on Friday 10am PST, with the > agenda: > > 1) New proposal for core affinity > 2) CFS configur

Re: [VOTE] Release Apache Mesos 0.27.2 (rc1)

://github.com/apache/mesos/commits/0.27.2-rc1/src/tests/master_tests.cpp On Tue, Mar 1, 2016 at 2:17 PM, Kevin Klues wrote: > Looks like this rc is missing this commit: > > https://github.com/apache/mesos/commit/d3108d776b6f7121e37176eda686ecc7245be4cd > > On Tue, Mar 1, 2016 at 2:0

Re: [VOTE] Release Apache Mesos 0.27.2 (rc1)

n >> MESOS-4518] > > This is supposed to be fixed in this release. It is concerning that this > came up. > Can you verify this and provide logs to Kevin Klues? > > > — > Joris Van Remoortere > Mesosphere > > On Tue, Mar 1, 2016 at 2:00 PM, Michael Browning > wrote:

Re: [VOTE] Release Apache Mesos 0.26.1 (rc1)

I committed a fix for this in: https://github.com/apache/mesos/commit/42f746937233349660c687ea7a66cc0a78871663 Looks like that's post 0.26 though, so maybe it should be included in the .1 rc On Mon, Feb 29, 2016 at 2:27 PM, Vinod Kone wrote: > Looks like the ASF CI builds for CentOS7 are failin

Re: [VOTE] Release Apache Mesos 0.27.2 (rc1)

; > On Tue, Mar 1, 2016 at 2:22 PM, Kevin Klues wrote: > > > The others all seem to have them though: > > > > > > > https://github.com/apache/mesos/commits/0.26.1-rc1/src/tests/master_tests.cpp > > > > > https://github.com/apache/mesos/commits/0.2

Re: [VOTE] Release Apache Mesos 0.27.2 (rc1)

- SSL >> > All green >> > >> > Centos 6 (+/- SSL) >> > * MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery (reopened >> > MESOS-4047) >> > >> > Debian 8 (+/- SSL) >> > * DockerContainerizerTest.ROOT_DOCKER_Kill (seem

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

Yes, will do. On Tue, Mar 8, 2016 at 10:26 AM, Vinod Kone wrote: > +kevin klues > > OK. I'm cancelling this vote since there are some show stopper issues that > we need to cherry-pick. I'll cut another RC on Thursday. > > @shepherds: can you please make sure the blo

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

ache.org/r/44468/ Implemented runtime isolator default cmd test (still under review). https://reviews.apache.org/r/44469/ Fixed a bug that causes the task stuck in staging state (still under review). https://reviews.apache.org/r/44435/ On Tue, Mar 8, 2016 at 10:30 AM, Kevin Klues wrote: > Yes, wi

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

1c >>> https://reviews.apache.org/r/44468/ >>> >>> Implemented runtime isolator default cmd test (still under review). >>> https://reviews.apache.org/r/44469/ >>> >>> Fixed a bug that causes the task stuck in staging state (still under >>> review)

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

k has been landed in docker for > quite a while and it is better to enable mesos docker containerizer support > this. > > Thanks, > > Guangya > > On Thu, Mar 10, 2016 at 2:00 AM, Kevin Klues wrote: >> >> Tim, >> >> Is there a review other than t

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

et past "Fix it, then ship it". >> >> Thanks, >> Dan >> >> >> -Original Message- >> From: Kevin Klues [mailto:klue...@gmail.com] >> Sent: Thursday, March 10, 2016 11:46 AM >> To: user ; dev >> Subject: Re: [VOTE] Relea

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

Can we be a bit more concrete here and try to build up a schema for this. Maybe something like: { [ { "service" : "docker", "registries" : [ "uri" : "", "default_credentials" : { "type" : "", "credential" : {

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

having a config file like the above? > > I think another downside of a per-agent config is that it's hard to > maintain this. What if a new framework joins and has a new credential for > the docker images. Do we need to restart the agent to reload the config? > > - Jie > > O

Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)

I respectfully disagree. The whole purpose of tags is to mark permanent things like releases, whereas branches are designed as temporary lines of development that come and go (and grow and shrink) dynamically all the time. On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu wrote: > I like the idea of using

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

this. What if a new framework joins and has a new credential >> > for >> > the docker images. Do we need to restart the agent to reload the config? >> > >> > - Jie >> > >> > On Tue, Mar 15, 2016 at 1:25 PM, Kevin Klues wrote:

Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)

fetch-not-getting-tags/ > > > > > > > > From the git manual (“git help fetch”): [1] > > > > > > > > -t, –tags Most of the tags are fetched automatically as branch heads > > are > > > > downloaded, but tags that do not point at objects rea

Re: Compile with CFLAGS=-DWITH_NETWORK_ISOLATOR

As haosdent said, the default libnl-3 that comes with ubuntu is not new enough. It will cause the following check in configure.ac to fail: AC_CHECK_LIB([nl-3], [nl_has_capability], ... because the default ubuntu version does not contain the function nl_has_capability. You need to install the ve

Re: Event bus for Mesos

There is this design doc that was circulating a few months back, but I'm not sure what the status of it is: https://docs.google.com/document/d/1b2gheqWPw4V-60RdKu-dGWTy-qLGL5p5xJwmUXteDYE/edit?pli=1#heading=h.86u1r3w05n13 On Fri, Mar 25, 2016 at 10:02 AM, Zhitao Li wrote: > Hi, > > Has anyone th

Re: Looking for Shepherd for MESOS-4033 (commit hook for non-ascii characters)

@vinod, @alexr. Neil and I had also suggested not excluding the doc directories (which Yong's current patch still does). What are your thoughts on this? On Fri, Apr 1, 2016 at 6:47 PM, Yong Tang wrote: > Hi Vinod, > > Thanks for the help. I updated the mesos-style.py and added the non-ascii >

Re: Looking for Shepherd for MESOS-4033 (commit hook for non-ascii characters)

tury! Alternatively, we can use numeric character references, > if folks think unicode in docs is a bad idea. > > On Sat, Apr 2, 2016 at 8:48 PM, Kevin Klues wrote: > >> @vinod, @alexr. Neil and I had also suggested not excluding the doc >> directories (which Yong's c

Re: Looking for Shepherd for MESOS-4033 (commit hook for non-ascii characters)

at 7:36 AM, Kevin Klues wrote: > @Alexr: That makes sense. I think we should enforce the check for > unicode in the docs though. Ascii in the code, unicode in the docs. I > can review the python. > > On Sun, Apr 3, 2016 at 2:42 AM, Alex Rukletsov wrote: >> @Vinod: I can take

Re: [Isolation][Containerization] - Add Intel Cache Allocation Technology(CAT) Isolator Support

Hi Fan, Thanks for putting this together. I have been looking into this quite a bit myself recently, and have been slowly preparing a design doc for both CAT and CMT support in Mesos. One of the biggest things I have been trying to figure out (which is why I haven't pushed my design doc out yet) i

Re: Typed Error Handling in Mesos

+1 This is also similar to how errors are typed in Go as well. On Wednesday, April 6, 2016, Alexander Rojas wrote: > +1 > > What I like is that it allows from some kind of type safety into the error > management beyond trying to parse error strings. > > > On 05 Apr 2016, at 03:48, Michael Park

Removing the External Containerizer

Hello all, The 'external' containerizer has been deprecated since August and we are now considering removing it permanently before the 0.29 release. Are there any objections to this? The following JIRA suggests that Hadoop on Mesos was still using the External containerizer format. https://issues

Re: [Performance Isolation] Meeting on Thursday April 21 2016 5pm PST

I tried calling into this last night, but no one was there. Was it post-poned again? On Mon, Apr 18, 2016 at 12:03 PM, Niklas Nielsen wrote: > Hi everyone, > > Per our conversation about Intel CAT enablement in Mesos, we are scheduling > a Performance Isolation Working Group meeting at Thursday

Re: [Performance Isolation] Meeting on Thursday April 21 2016 5pm PST

2016 at 10:06 AM, Ian Downes >> wrote: >> >>> Likewise, I tried calling but no one was hosting the meeting. >>> >>> On Fri, Apr 22, 2016 at 10:04 AM, Kevin Klues wrote: >>> >>> > I tried calling into this last night, but no one was ther

Re: Rename 'include/mesos/slave' to 'include/mesos/agent'

As of last week, such a symlink has been added. The plan is to leave the symlink in place until the deprecation cycle has ended. At that point, all references to "slave" in our external APIs will be removed. This email is just a warning that people should start migrating their include paths over t

Re: Should "read-only" HTTP endpoints allow other request methods than "GET"?

There was some discussion of this between mpark and I in relation to the v1 operator API. The idea was to have a base class for endpoints that implement GET/POST/DELETE/PUT/etc... functions that return an error by default. You can then override the specific subset of them that that each endpoint s

Re: [WEBSITE] Readme update

Yes, that is out of date. The recommended way of generating the website now is support/site-docker/ On Fri, May 20, 2016 at 7:45 AM, haosdent wrote: >> It doesn't mention mesos-website-container > I think it may forgot to update in https://reviews.apache.org/r/39194/ >> support/generate-help-sit

Re: [WEBSITE] Readme update

What was the error with docker? I use that all the time (even just yesterday) On Friday, May 20, 2016, haosdent wrote: > Let me include this in the pactch. ;-) > > On Sat, May 21, 2016 at 12:17 AM, Vinod Kone > wrote: > > > On Fri, May 20, 2016 at 9:00 AM, haosdent > wrote: > > > > > run ../su

Re: [WEBSITE] Readme update

/mesos.apache.org/api/latest/java/ and > https://mesos.apache.org/api/latest/c++ > > On Sat, May 21, 2016 at 12:22 AM, Kevin Klues > wrote: > > > What was the error with docker? I use that all the time (even just > > yesterday) > > > > On Friday, May 20, 2016,

[REVIEW PROCESS] Proposal for new review process working group

Hi all, I'd like to propose starting a dedicated "review process" working group. The goals of this working group will be to: 1) Discuss issues around the current review process 2) Propose improvements to the current review process 3) Implement / Monitor / Enforce the new process we come up with

Re: [REVIEW PROCESS] Proposal for new review process working group

te: >> >>> This sounds great, add me to the group please. >>> >>> On Sat, May 21, 2016 at 1:59 AM, Kevin Klues wrote: >>> >>>> Hi all, >>>> >>>> I'd like to propose starting a dedicated "review process" w

Re: mesos git commit: Updated quota endpoint help.

We had considered what Benjamin proposes (I think I even wrote the code to do it), but we decided it was better to commit them back since all of the other documentation is in the docs folder and is checked in. I don't have a strong opinion either way though, so I'm fine with not commtting them bac

Re: [Tech-debt] Introduce regex into Mesos

I've run into compiler errors using simple regex stuff from the standard library on our supported version of gcc. On Thu, Jun 9, 2016 at 7:30 PM, Klaus Ma wrote: > Hi team, > > > We're discussing to introduce regex into Mesos when investigating > MESOS-4627

Re: [Tech-debt] Introduce regex into Mesos

By compiler errors, I mean "internal compiler errors" On Fri, Jun 10, 2016 at 11:38 AM, Kevin Klues wrote: > I've run into compiler errors using simple regex stuff from the > standard library on our supported version of gcc. > > On Thu, Jun 9, 2016 at 7:30 PM,

New external dependency

Hello all, Just an FYI that the newest libmesos now has an external dependence on libelf on Linux. This dependence can be installed via the following packages: CentOS 6/7: yum install elfutils-libelf.x86_64 Ubuntu14.04: apt-get install libelf1 Alternatively you can install from source: htt

Re: New external dependency

n, >> >> Thanks for letting us know. It seems like this is not called out in >> upgrades.md, so can you please document this additional dependency there? >> >> Also, can you include the link to the JIRA or patch requiring this >> dependency so we can have some con

Re: New external dependency

to required dependency though? Could you summarize? > > > On Sun, Jun 19, 2016 at 12:33 PM, Kevin Klues wrote: >> >> Thanks Zhitao, >> >> I just pushed out a review for upgrades.md and added you as a reviewer. >> >> The new dependence was added in the

Re: New external dependency

figuration/external information). > > Thanks, > > JC > >> On Jun 20, 2016, at 2:30 PM, Kevin Klues wrote: >> >> Sorry, the ticket just links to the nvidia-docker project without much >> further explanation. The information at the link below should make it >>

Re: New external dependency

, purely from a number of volume statements), or it could be solved > externally as the docker volume container does with a more generic solution. > > Thanks, > > JC > >> On Jun 20, 2016, at 6:59 PM, Kevin Klues wrote: >> >> For now we've decided to actuall

Re: Mesos CLI

I've created an Epic to track this: https://issues.apache.org/jira/browse/MESOS-5676 There have been efforts on this that have failed in the past (e.g. https://github.com/mesosphere/mesos-cli) I'm curious what people's thoughts are in terms of keeping the CLI integrated into mesos itself vs. main

Re: [GPU] [Allocation] "Scarce" Resource Allocation

As an FYI, preliminary support to work around this issue for GPUs will appear in the 1.0 release https://reviews.apache.org/r/48914/ This doesn't solve the problem of scarce resources in general, but it will at least keep non-GPU workloads from starving out GPU-based workloads on GPU capable machi

Re: Mesos CLI

t; > >> > > On Tue, Jun 21, 2016 at 12:12 PM, Jie Yu wrote: >> > > >> > > > I personally prefer it being part of the Mesos repo so that when >> people >> > > > install our package, they'll get the command line too

Re: Mesos CLI

> > The best option may still be for it > to be in Python, this is why I'm asking if there are particular things that > our helper libraries don't provide which you are leveraging in python. > One thing we rely heavily on that is missing is `docopt`. We use docopt for convenient / standardized com

GPU channel on slack

If you are interested in the ongoing GPU work on Mesos, please join the #gpus channel at mesos.slack.com. The big announcements for the GPU work will still happen on this mailing list, but the day to day discussions will likely happen on the slack channel going forward.

Re: GPU channel on slack

https://reviews.apache.org/r/49456/ On Thu, Jun 30, 2016 at 8:55 AM Vinod Kone wrote: > Mind updating > https://github.com/apache/mesos/blob/master/docs/working-groups.md with > this info? > > On Thu, Jun 30, 2016 at 8:44 AM, Kevin Klues wrote: > > > If you are inter

Re: 1.0.1 release

Depends on if we want something to enable DC/OS 1.8 to configure easily for GPU use. On Tuesday, August 9, 2016, Benjamin Mahler wrote: > All of the issues I've been shepherding have been fixed. > > The only one I see remaining is this one, but doesn't look like a blocking > issue: https://issue

Re: Adding "syntax=proto2" to Mesos public protobuf files

I would promote doing the following as well if it doesn't break anything. https://issues.apache.org/jira/browse/MESOS-5186 It would unblock tfmesos (a distributed tensorflow framework on Mesos) from working with an unmodified Mesos. On Wed, Sep 7, 2016 at 2:13 AM Greg Mann wrote: > AFAICT, this

Re: mesos git commit: Fixed a bug in getRootContainerId due to protobuf copying issue.

Here is another problematic use case that I ran into a few weeks back: Running the following ends up enteringa recursive loop and blowing up the stack: ``` container.id.mutable_parent()->CopyFrom(container.id); ``` If you look at the body of `MergeFrom()`, which is called from `CopyFrom()`

Mesos Container Attach/Exec

Hello all, We recently started working on support for `docker attach` and `docker exec` like functionality in Mesos. Here is a link to the design doc: https://docs.google.com/document/d/1nAVr0sSSpbDLrgUlAEB5hKzCl482NSVk8V0D56sFMzU The design doc is not yet complete, but it is filled out enough

Re: Mesos Container Attach/Exec

+user list Hello all, We recently started working on support for `docker attach` and `docker exec` like functionality in Mesos. Here is a link to the design doc: https://docs.google.com/document/d/1nAVr0sSSpbDLrgUlAEB5hKzCl482NSVk8V0D56sFMzU The design doc is not yet complete, but it is filled

GPU Users -- Deprecation of GPU_RESOURCES capability

Hello GPU users, We are currently considering deprecating the requirement that frameworks register with the GPU _RESOURCES capability in order to receive offers that contain GPUs. Going forward, we will recommend that users rely on Mesos's builtin `reservation` mechanism to achieve similar results

Fwd: Question ablout "Attach/Exec Support in Mesos"

-- Forwarded message - From: Kevin Klues Date: Sun, May 21, 2017 at 9:14 AM Subject: Re: question ablout "Attach/Exec Support in Mesos" To: 唐亮 Hi Tangliang, Unfortunately we only have support for `task exec` in the DC/OS CLI at the moment. We have been planning to b

Re: GPU Users -- Deprecation of GPU_RESOURCES capability

in a > > > > complex cluster, it is possible that we have [R1, R2, ..., RN] which > > > wants > > > > to share the scarce resource among them but there is another set of > > roles > > > > which should never see the given resource. > > > &g

Re: Question ablout "Attach/Exec Support in Mesos"

just tried it on my Mac and it works well with our standalone Mesos 1.2.0 > cluster. Thanks for sharing this! > > Cheers, > Mao > > On Sun, May 21, 2017 at 9:16 AM, Kevin Klues wrote: > > > ------ Forwarded message - > > From: Kevin Klues > > Da

Re: [External] Re: docker containerizer with nvidia-docker

lag? Kevin On Fri, Apr 5, 2019 at 6:58 PM Benjamin Mahler wrote: > +Kevin Klues > > > On Fri, Apr 5, 2019 at 1:24 AM Huadong Liu wrote: > >> Hi Ben, thanks for pointing me to the docker containerizer ticket. I do >> see >> the value of UCR. >> >> Since

Re: Next Steps

Hello old friends. Long time no hear. +1 (binding) Haven't written that in a while... I also think moving it to the attic (as far as Apache is concerned) makes a lot of sense. It can have a life of its own on github (without the overhead of Apache PMC, requirements for voting, etc.) Kevin Am D

Re: [VOTE] Move Apache Mesos to Attic

+1 (binding) While it is of course sad to see things come to an end here, I do encourage those of you who wish to see Mesos live on to try and breath new life into it as a standalone project on github. In that sense, this is more of a new beginning than an end. The king is dead, long live the king