[GitHub] mesos pull request #268: Don't mention the deceased mesos-health-check binar...

GitHub user benjaminp opened a pull request: https://github.com/apache/mesos/pull/268 Don't mention the deceased mesos-health-check binary in docs for --launcher_dir. You can merge this pull request into a Git repository by running: $ git pull

Re: Tasks may be explicitly dropped by agent in Mesos 1.5

Meng, Could you double check if this is really an issue in Mesos 1.5.0 release? MESOS-1720 was resolved after the 1.5 release (rc-2) and it seems like it is only at the master branch and 1.5.x branch (not 1.5.0). Did I miss anything? - Gilbert

Re: Tasks may be explicitly dropped by agent in Mesos 1.5

Put another way, we currently don't guarantee in-order task delivery to the executor. Due to the changes for MESOS-1720, one special case of task re-ordering now leads to the re-ordered task being dropped (rather than delivered out-of-order as before). Technically, this is strictly better.

Tasks may be explicitly dropped by agent in Mesos 1.5

Hi all: TLDR: In Mesos 1.5, tasks may be explicitly dropped by the agent if all three conditions are met: (1) Several `LAUNCH_TASK` or `LAUNCH_GROUP` calls use the same executor. (2) The executor currently does not exist on the agent. (3) Due to some race conditions, these tasks are trying to

Re: Collecting futures in the same actor in libprocess

Chatted offline with Chun and Meng and suggested we take an explicit approach of using process::Sequence to ensure ordered task delivery (this would need to be done both in the master and agent). On Thu, Mar 1, 2018 at 1:17 PM, Chun-Hung Hsiao wrote: > Some background for

Re: Collecting futures in the same actor in libprocess

Some background for the bug AlexR and Meng found: In https://issues.apache.org/jira/browse/MESOS-1720, we introduce an ordering dependency between two `LAUNCH`/`LAUNCH_GROUP` calls to a new executor. The master would specify that the first call is the one to launch a new executor through the

Re: Collecting futures in the same actor in libprocess

Could you explain the problem in more detail? On Thu, Mar 1, 2018 at 12:15 PM Chun-Hung Hsiao wrote: > Hi all, > > Meng found a bug in `slave.cpp`, where the proper fix requires collecting > futures in order. Currently every `collect` call spawns it's own actor, so > for

Collecting futures in the same actor in libprocess

Hi all, Meng found a bug in `slave.cpp`, where the proper fix requires collecting futures in order. Currently every `collect` call spawns it's own actor, so for two `collect` calls, even though their futures are satisfied in order, they may finish out-of-order. So we need some libprocess changes

Re: Anyone using a custom Sorter?

if your intention is to kill sorter interface, i am +100 On Wed, Feb 28, 2018 at 2:12 PM, Michael Park wrote: > I'm not even sure if anyone's using a custom Allocator, but > is anyone using a custom Sorter? It doesn't seem like there's > even a module for it so it wouldn't be

Re: Authorization Logging

This is a good question on where to do the audit, should it happen in the authorization module itself, or in the caller. It doesn’t help that you can authorize using approvers or the authorizer or the not so long ago introuced acceptors. There are also function wrappers that help to do so.