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

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

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

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 nvidia-docker

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

> Hi Kevin, > > I 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 <klue...@gmail.com> wrote: > > > ------ Forwarded message --

Re: GPU Users -- Deprecation of GPU_RESOURCES capability

ing this resource for the given role R". However, > > 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 > > > &

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

-- Forwarded message - From: Kevin Klues <klue...@gmail.com> Date: Sun, May 21, 2017 at 9:14 AM Subject: Re: question ablout "Attach/Exec Support in Mesos" To: 唐亮 <tangliang...@360.cn> Hi Tangliang, Unfortunately we only have support for `task exec` in the D

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

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

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 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

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

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 >

Re: GPU channel on slack

https://reviews.apache.org/r/49456/ On Thu, Jun 30, 2016 at 8:55 AM Vinod Kone <vinodk...@apache.org> 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 <

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: 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

Re: Mesos CLI

t;> > > Would be nice if the CLI can be written entirely in C++ though, to >> avoid >> > > supporting more languages. >> > > >> > > On Tue, Jun 21, 2016 at 12:12 PM, Jie Yu <yujie@gmail.com> wrote: >> > > >> > > >

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

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.

Re: New external dependency

in a > container, 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 <klue...@gmail.com> wrote: >

Re: New external dependency

ersus being a configuration/external information). > > Thanks, > > JC > >> On Jun 20, 2016, at 2:30 PM, Kevin Klues <klue...@gmail.com> wrote: >> >> Sorry, the ticket just links to the nvidia-docker project without much >> further explanation. The infor

Re: New external dependency

optional > dependency to required dependency though? Could you summarize? > > > On Sun, Jun 19, 2016 at 12:33 PM, Kevin Klues <klue...@gmail.com> wrote: >> >> Thanks Zhitao, >> >> I just pushed out a review for upgrades.md and added you as a reviewer. >>

Re: New external dependency

requiring this >> dependency so we can have some contexts? >> >> Thanks! >> >> On Sat, Jun 18, 2016 at 10:25 AM, Kevin Klues <klue...@gmail.com> wrote: >> >> > Hello all, >> > >> > Just an FYI that the newest libmesos now has an

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:

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 <klue...@gmail.com> wrote: > I've run into compiler errors using simple regex stuff from the > standard library on our supported version of gcc. > > On Thu, Jun

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 >

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

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

0, 2016 at 11:07 AM, haosdent <haosd...@gmail.com> wrote: >> >>> This sounds great, add me to the group please. >>> >>> On Sat, May 21, 2016 at 1:59 AM, Kevin Klues <klue...@gmail.com> wrote: >>> >>>> Hi all, >>>> >>&

[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: [WEBSITE] Readme update

c. > > https://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 <klue...@gmail.com > <javascript:;>> wrote: > > > What was the error with docker? I use that all the time (even

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

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/ >>

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

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

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

t;> On Fri, Apr 22, 2016 at 10:06 AM, Ian Downes <idow...@twitter.com.invalid> >> wrote: >> >>> Likewise, I tried calling but no one was hosting the meeting. >>> >>> On Fri, Apr 22, 2016 at 10:04 AM, Kevin Klues <klue...@gmail.com> wrote: >&

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

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

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)

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

ocs, > it's 21st century! 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 <klue...@gmail.com> wrote: > >> @vinod, @alexr. Neil and I had also suggested not excluding the d

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

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:

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

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

er-git-git-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

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

w: > > On Tue, Mar 15, 2016 at 5:39 PM, Kevin Klues <klue...@gmail.com> wrote: >> >> Yeah, option 2. >> >> I was trying to expand on Avinash's suggestion and make it a bit more >> concrete in terms of what was being proposed. Needing to reload the &

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

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

t; - Jie > > On Tue, Mar 15, 2016 at 1:25 PM, Kevin Klues <klue...@gmail.com> wrote: > >> Can we be a bit more concrete here and try to build up a schema for this. >> Maybe something like: >> >> { >> [ >> { >

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: [VOTE] Release Apache Mesos 0.28.0 (rc1)

to >> get 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 <u...@mesos.apache.org>

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

the user defined network 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 <klue...@gmail.com> wrote: >> >> Tim, >>

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

g MESOS-4888 and move the test to a >> separate JIRA. >> >> Thanks, >> Gilbert >> >> On Tue, Mar 8, 2016 at 2:43 PM, Kevin Klues <klue...@gmail.com> wrote: >> >>> Here are the list of reviews/patches that have been called out in

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

/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 <klue...@gmail.com>

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

Yes, will do. On Tue, Mar 8, 2016 at 10:26 AM, Vinod Kone <vinodk...@apache.org> 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 plea

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

> > MESOS-4423) >> > >> > Centos 7 - SSL >> > All green >> > >> > Centos 6 (+/- SSL) >> > * MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery (reopened >> > MESOS-4047) >> > >> > Debian 8 (+/- SSL) >&

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

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

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

kFlag [flaky, tracked in >> 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,

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 <klue...@gmail.com> wrote: > Looks like this rc is missing this commit: > > https://github.com/apache/mesos/commit/d3108d776b6f7121e37176eda686ecc7245be4cd > > On Tue

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: Mesos binaries and shared library dependencies.

e. In my > opinion 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 >>

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: >

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 <klue...@gmail.com> wrote: > Playing with this a bit more, I came up with a

Re: Mesos binaries and shared library dependencies.

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 <klue...@gmail.com> wrote: > Hi all, > > A discussion came up recently around including rpaths in our mesos > binaries to help resolve any shared library depen

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.

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

Re: Mesos binaries and shared library dependencies.

bal 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. On Fri, Feb 12, 2016 at 3:31 P

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

Re: Inconsistent naming of support scripts

the files 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 <klue...@gmail.com> wrote: > >> I prefer hyphens as well >> >> On Thu, Feb 11, 2016 at 1:28 PM, Jojy Var

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

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

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

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

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

Re: Jenkins builds failing for CentOS 7

ad 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 <klue...@gmail.com> wrote: > Hey all, > >

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 <klue...@gmail.com> 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 mov

Re: Jenkins builds failing for CentOS 7

ls-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 <klue...@gmail.com> wrote: > I'm assuming this is the sc