Re: 1.4.1 release
We want to backport https://reviews.apache.org/r/62518/ to 1.2.x, 1.3.x and 1.4.x, James will work on it. Regards, Qian Zhang On Fri, Nov 3, 2017 at 12:11 AM, Kapil Arya wrote: > Please reply to this email if you have pending patches to be backported to > 1.4.x as we are aiming to cut a release candidate for 1.4.1 early next week. > > Thanks, > Anand and Kapil >
Re: TASK_UNKNOWN status ambiguousness
+1 On Thu, Nov 2, 2017 at 1:15 PM, Ilya Pronin wrote: > Hey everyone, > > Currently, TASK_UNKNOWN task status covers 2 different cases that should be > handled differently by frameworks: > 1. Task is unknown, agent is unknown: the fate of the task is unknown, the > framework may elect to wait until its agent comes back (network partition > resolves, etc.); > 2. Task is unknown, agent in registered: the task is definitely in the > terminal state and will not come back, the framework should reschedule it. > > I'd like to resolve this ambiguity and replace TASK_UNKNOWN with TASK_GONE > in the second case. The ticket to track this issue is > https://issues.apache.org/jira/browse/MESOS-8165. > > Any objections? > > -- > Ilya Pronin >
Re: 1.3.2 Release
Great! I cherry picked Gaston's fix for https://issues.apache.org/ jira/browse/MESOS-8135. On Wed, Nov 1, 2017 at 6:57 PM, Michael Park wrote: > Please reply to this email if you have pending patches to be backported to > 1.3.x, I'm aiming to cut a 1.3.2 on Friday. > > Thanks, > > MPark >
Re: clearing the executor authentication token from the task environment
> On Nov 1, 2017, at 2:28 PM, James Peach wrote: > > Hi all, > > In https://issues.apache.org/jira/browse/MESOS-8140, I'm proposing that we > clear the MESOS_EXECUTOR_AUTHENTICATION_TOKEN environment variable > immediately after consuming it in the built-in executors. This protects it > from observation by other tasks in the same PID namespace, however I wanted > to verify that no-one currently has a use case that depends on this. > Currently, the token is inherited to the environment of tasks running under > the command executor (i.e. not to task group tasks). > > Eventually we would add a formal API for tasks to access the executor token > in MESOS-8018. Ok, we will be landing this change for Mesos 1.5 thanks, James
TASK_UNKNOWN status ambiguousness
Hey everyone, Currently, TASK_UNKNOWN task status covers 2 different cases that should be handled differently by frameworks: 1. Task is unknown, agent is unknown: the fate of the task is unknown, the framework may elect to wait until its agent comes back (network partition resolves, etc.); 2. Task is unknown, agent in registered: the task is definitely in the terminal state and will not come back, the framework should reschedule it. I'd like to resolve this ambiguity and replace TASK_UNKNOWN with TASK_GONE in the second case. The ticket to track this issue is https://issues.apache.org/jira/browse/MESOS-8165. Any objections? -- Ilya Pronin
[GitHub] mesos pull request #247: Fixed reference to Mesos paper in the documentation...
Github user vinodkone commented on a diff in the pull request: https://github.com/apache/mesos/pull/247#discussion_r148613763 --- Diff: docs/architecture.md --- @@ -34,4 +34,4 @@ In addition, this resource offer process repeats when tasks finish and new resou While the thin interface provided by Mesos allows it to scale and allows the frameworks to evolve independently, one question remains: how can the constraints of a framework be satisfied without Mesos knowing about these constraints? For example, how can a framework achieve data locality without Mesos knowing which nodes store the data required by the framework? Mesos answers these questions by simply giving frameworks the ability to **reject** offers. A framework will reject the offers that do not satisfy its constraints and accept the ones that do. In particular, we have found that a simple policy called delay scheduling, in which frameworks wait for a limited time to acquire nodes storing the input data, yields nearly optimal data locality. -You can also read much more about the Mesos architecture in this [technical paper](http://mesos.berkeley.edu/mesos_tech_report.pdf). +You can also read much more about the Mesos architecture in this [technical paper](http://mesos.apache.org/assets/papers/nsdi_mesos.pdf). --- End diff -- https://www.usenix.org/conference/nsdi11/mesos-platform-fine-grained-resource-sharing-data-center is even better because it has links to video, audio, slides and the paper. ---
[GitHub] mesos pull request #247: Fixed reference to Mesos paper in the documentation...
Github user vinodkone commented on a diff in the pull request: https://github.com/apache/mesos/pull/247#discussion_r148613391 --- Diff: docs/architecture.md --- @@ -34,4 +34,4 @@ In addition, this resource offer process repeats when tasks finish and new resou While the thin interface provided by Mesos allows it to scale and allows the frameworks to evolve independently, one question remains: how can the constraints of a framework be satisfied without Mesos knowing about these constraints? For example, how can a framework achieve data locality without Mesos knowing which nodes store the data required by the framework? Mesos answers these questions by simply giving frameworks the ability to **reject** offers. A framework will reject the offers that do not satisfy its constraints and accept the ones that do. In particular, we have found that a simple policy called delay scheduling, in which frameworks wait for a limited time to acquire nodes storing the input data, yields nearly optimal data locality. -You can also read much more about the Mesos architecture in this [technical paper](http://mesos.berkeley.edu/mesos_tech_report.pdf). +You can also read much more about the Mesos architecture in this [technical paper](http://mesos.apache.org/assets/papers/nsdi_mesos.pdf). --- End diff -- I think you can use "https://www.usenix.org/legacy/events/nsdi11/tech/full_papers/Hindman.pdf"; ---
[GitHub] mesos issue #247: Fixed reference to Mesos paper in the documentation.
Github user andschwa commented on the issue: https://github.com/apache/mesos/pull/247 You can use Autotools too, I just don't know what the target is, and don't like to wait around for the entire build ð ---
[GitHub] mesos issue #247: Fixed reference to Mesos paper in the documentation.
Github user mpereira commented on the issue: https://github.com/apache/mesos/pull/247 @andschwa thanks for clarifying. I'll try that again soon, it looks like I'm missing a few dependencies for this cmake build. ---
[GitHub] mesos issue #247: Fixed reference to Mesos paper in the documentation.
Github user andschwa commented on the issue: https://github.com/apache/mesos/pull/247 @mpereira Oh I know what's going on: > Please make sure Java proto files are generated in ../build/src/java/generated folder. The site generator expects the build to have been run, at least to the point of proto files being generated. Try ``` mkdir build cd build cmake -DENABLE_JAVA=ON .. cmake --build . --target mesos-protobufs ``` And then try generating the site again, I think it'll work. ---
[GitHub] mesos pull request #247: Fixed reference to Mesos paper in the documentation...
GitHub user mpereira opened a pull request: https://github.com/apache/mesos/pull/247 Fixed reference to Mesos paper in the documentation. The paper is also available at https://people.eecs.berkeley.edu/~alig/papers/mesos.pdf but I noticed it was already included in the site's assets so I just linked that instead. By the way I wasn't able to generate the website with `./site/mesos-websiste-dev.sh`. I didn't generate the help endpoint beforehand so maybe that's the issue? This is what I'm seeing: ``` $ ./site/mesos-websiste-dev.sh ... ... Generating example index... finalizing index lists... lookup cache used 35887/65536 hits=301982 misses=40583 finished... rake aborted! Please make sure Java proto files are generated in ../build/src/java/generated folder. /mesos/site/Rakefile:77:in `block in ' /usr/local/share/gems/gems/rake-12.0.0/exe/rake:27:in `' /usr/local/share/gems/gems/bundler-1.16.0/lib/bundler/cli/exec.rb:75:in `load' /usr/local/share/gems/gems/bundler-1.16.0/lib/bundler/cli/exec.rb:75:in `kernel_load' /usr/local/share/gems/gems/bundler-1.16.0/lib/bundler/cli/exec.rb:28:in `run' /usr/local/share/gems/gems/bundler-1.16.0/lib/bundler/cli.rb:424:in `exec' /usr/local/share/gems/gems/bundler-1.16.0/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run' /usr/local/share/gems/gems/bundler-1.16.0/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command' /usr/local/share/gems/gems/bundler-1.16.0/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch' /usr/local/share/gems/gems/bundler-1.16.0/lib/bundler/cli.rb:27:in `dispatch' /usr/local/share/gems/gems/bundler-1.16.0/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start' /usr/local/share/gems/gems/bundler-1.16.0/lib/bundler/cli.rb:18:in `start' /usr/local/share/gems/gems/bundler-1.16.0/exe/bundle:30:in `block in ' /usr/local/share/gems/gems/bundler-1.16.0/lib/bundler/friendly_errors.rb:122:in `with_friendly_errors' /usr/local/share/gems/gems/bundler-1.16.0/exe/bundle:22:in `' /usr/local/bin/bundle:23:in `load' /usr/local/bin/bundle:23:in `' Tasks: TOP => default => javadoc (See full trace by running task with --trace) Untagged: mesos/website-1509639317-18148:latest Deleted: sha256:24242decc28e6222d42a24f8f9e8947ce15fcaecb3d94235cd3664b1ade968f4 Deleted: sha256:e7180c9d482f664089b4e441c6df77fda2da2788fa068dd564eab51fa299332f Deleted: sha256:a75cc639c15951a46d23d5844cee39bc80c6d5bed41523e761cb259857793e26 Deleted: sha256:a5a6c2a58189c9375f80d22982da293ac18214c836cd1596a326838e47a984db Deleted: sha256:53180dac52d5167d83dd7af08b455b0a5321e01bd660cbcff1646e116cf10a8d Deleted: sha256:8fc4522bd32a0b5b72f51e2f058a0f19ee0a974ff67903999342da316fb1eeb6 Deleted: sha256:33f70af6654b772ba267987aa23a58d5e5196379bce211be96e8070d2dc19bba Deleted: sha256:aad2585e5e2bfe7222d6fd38bf8921e7e2ca6ddd63fb66f18ac0dc7ee63b0851 Deleted: sha256:c2441f453bf9135a50005eac91ea64a953bc64a7317b2beb2f9a4e230b7c4303 Deleted: sha256:b6298626e1ee07795ac25ebf0bd0d556792ece844e2b991a086c90fefcb8fd6a Deleted: sha256:c5930ca7fccd8dcd6bcb12683f6235666c73b91ec04db100469d8dd1fe0680d2 Deleted: sha256:68d1b400d2fd25e919536e1d2f0b4bb5b63538383a19c1faa9a96fb096a41b52 Deleted: sha256:cf2f163eb99cf1ada0a2d75dfc4e98b09a63ffdb20b8649a8089baa6eba91607 ``` I also noticed that [some websites](https://www.google.com/search?q="mesos.berkeley.edu/mesos_tech_report.pdf"&oq="mesos.berkeley.edu/mesos_tech_report.pdf";) reference the original URL `http://mesos.berkeley.edu/mesos_tech_report.pdf`, so maybe it could also make sense to get that working again? You can merge this pull request into a Git repository by running: $ git pull https://github.com/mpereira/mesos fix-doc-reference-to-paper Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mesos/pull/247.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #247 commit 9db097044d76846ef366aed54fef450ae593a4cf Author: Murilo Pereira Date: 2017-11-02T16:14:08Z Fixed reference to Mesos paper in the documentation. The paper is also available at https://people.eecs.berkeley.edu/~alig/papers/mesos.pdf but I noticed it was already included in the site's assets so I just linked that instead. ---
1.4.1 release
Please reply to this email if you have pending patches to be backported to 1.4.x as we are aiming to cut a release candidate for 1.4.1 early next week. Thanks, Anand and Kapil
[GitHub] mesos pull request #246: sched-http-api: fix example JSON
Github user asfgit closed the pull request at: https://github.com/apache/mesos/pull/246 ---
[GitHub] mesos pull request #246: sched-http-api: fix example JSON
GitHub user jdef opened a pull request: https://github.com/apache/mesos/pull/246 sched-http-api: fix example JSON You can merge this pull request into a Git repository by running: $ git pull https://github.com/jdef/mesos patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mesos/pull/246.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #246 commit 033a651080ba27e69ced01b0f2434b698d04fb20 Author: James DeFelice Date: 2017-11-02T12:38:43Z sched-http-api: fix example JSON ---