Re: 1.4.1 release

[Qian Zhang]

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

[Vinod Kone]

+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

[Benjamin Mahler]

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

[James Peach]

> 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

[Ilya Pronin]

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

[vinodkone]

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

[vinodkone]

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.

[andschwa]

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.

[mpereira]

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.

[andschwa]

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

[mpereira]

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

[Kapil Arya]

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

[asfgit]

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

[jdef]

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




---