[jira] [Commented] (MESOS-1104) Move linux/fs.hpp out of `mesos` namespace in linux/fs.h

[Deshi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221179#comment-15221179
 ] 

Deshi Xiao commented on MESOS-1104:
---

patch updated, anyone can testing it?

https://reviews.apache.org/r/45500/

> Move linux/fs.hpp out of `mesos` namespace in linux/fs.h
> 
>
> Key: MESOS-1104
> URL: https://issues.apache.org/jira/browse/MESOS-1104
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Archana kumari
>  Labels: mesosphere, newbie
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3782) Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create symlinks)

[zhou xing (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221173#comment-15221173
 ] 

zhou xing commented on MESOS-3782:
--

yes, will do that

> Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create 
> symlinks)
> --
>
> Key: MESOS-3782
> URL: https://issues.apache.org/jira/browse/MESOS-3782
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: zhou xing
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3782) Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create symlinks)

[Kevin Klues (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221168#comment-15221168
 ] 

Kevin Klues commented on MESOS-3782:


I don't think you should copy the {noformat}bin/*slave*.in{noformat} files 
themselves, but rather use AC_CONFIG_FILES in configure.ac to generate them 
from the same input. i.e.,

{noformat}
AC_CONFIG_FILES([bin/mesos-agent.sh:bin/mesos-slave.in.sh], [chmod +x 
bin/mesos-agent.sh])
AC_CONFIG_FILES([bin/mesos-agent-flags.sh:bin/mesos-slave-flags.in.sh])
{noformat}

https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Configuration-Files.html

> Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create 
> symlinks)
> --
>
> Key: MESOS-3782
> URL: https://issues.apache.org/jira/browse/MESOS-3782
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: zhou xing
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3782) Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create symlinks)

[Jay Guo (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221165#comment-15221165
 ] 

Jay Guo commented on MESOS-3782:


Or we could copy it twice and change the name in the second copy.

> Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create 
> symlinks)
> --
>
> Key: MESOS-3782
> URL: https://issues.apache.org/jira/browse/MESOS-3782
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: zhou xing
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3782) Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create symlinks)

[zhou xing (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221166#comment-15221166
 ] 

zhou xing commented on MESOS-3782:
--

yeap, that could also be a solution

> Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create 
> symlinks)
> --
>
> Key: MESOS-3782
> URL: https://issues.apache.org/jira/browse/MESOS-3782
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: zhou xing
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5055) Replace Master/Slave Terminology Phase I - Update strings in the log message and standard output

[zhou xing (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221155#comment-15221155
 ] 

zhou xing commented on MESOS-5055:
--

[~darroyo], sure, will send a mail to collect the feedbacks

> Replace Master/Slave Terminology Phase I - Update strings in the log message 
> and standard output
> 
>
> Key: MESOS-5055
> URL: https://issues.apache.org/jira/browse/MESOS-5055
> Project: Mesos
>  Issue Type: Task
>Reporter: zhou xing
>Assignee: zhou xing
>
> This is a sub ticket of MESOS-3780. In this ticket, we will rename all the 
> slave to agent in the log messages and standard output.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3782) Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create symlinks)

[zhou xing (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221154#comment-15221154
 ] 

zhou xing commented on MESOS-3782:
--

[~vinodkone], those scripts are not very big, if we just duplicate the shell 
script the only disadvantage here is that if we need to change sth in the shell 
scripts, we need to copy the changes to the mess-agent.sh as well. For now, I 
will just duplicate everything and submit a patch then

> Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create 
> symlinks)
> --
>
> Key: MESOS-3782
> URL: https://issues.apache.org/jira/browse/MESOS-3782
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: zhou xing
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5075) Remain processes when running perf event related test cases

[haosdent (JIRA)]

haosdent created MESOS-5075:
---

 Summary: Remain processes when running perf event related test 
cases
 Key: MESOS-5075
 URL: https://issues.apache.org/jira/browse/MESOS-5075
 Project: Mesos
  Issue Type: Bug
Reporter: haosdent
Assignee: haosdent


Currently when running single perf event related test cases, I always saw
{code}
[--] Global test environment tear-down
../../src/tests/environment.cpp:790: Failure
Failed
Tests completed with child processes remaining:
-+- 22886 /home/haosdent/mesos/build/src/.libs/mesos-tests 
--gtest_filter=CgroupsIsolatorTest.ROOT_CGROUPS_PerfEventSubsystemSample 
--verbose
 \-+- 22963 /home/haosdent/mesos/build/src/.libs/mesos-tests 
--gtest_filter=CgroupsIsolatorTest.ROOT_CGROUPS_PerfEventSubsystemSample 
--verbose
   \-+- 22965 perf stat --all-cpus --field-separator , --log-fd 1 --event 
cycles --cgroup mesos/5f02f820-cc63-471b-98b9-37bbc4fde674 --event task-clock 
--cgroup mesos/5f02f820-cc63-471b-98b9-37bbc4fde674 -- sleep 0.25
 \--- 22966 sleep 0.25
[==] 1 test from 1 test case ran. (3165 ms total)
{code}

In {{PerfEventIsolatorTest.ROOT_CGROUPS_Sample}}, we add a sleep.
{code}
sleep(2);
{code}

This could avoid the remain processes in most cases, but a better approach is 
to discard and kill perf sample process before exit.

As discussion in [r43284 | https://reviews.apache.org/r/43284/], discard did't 
work as well except waiting for process exit. So need to investigate why 
discard didn't work and fix it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4705) Slave failed to sample container with perf event

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221068#comment-15221068
 ] 

haosdent commented on MESOS-4705:
-

Hi, [~idownes]][~bmahler] Could you help review the patch of [~fan.du] 
https://reviews.apache.org/r/44379/diff/ It works for me in CentOS 7.1 Thanks a 
lot!

> Slave failed to sample container with perf event
> 
>
> Key: MESOS-4705
> URL: https://issues.apache.org/jira/browse/MESOS-4705
> Project: Mesos
>  Issue Type: Bug
>  Components: cgroups, isolation
>Affects Versions: 0.27.1
>Reporter: Fan Du
>Assignee: Fan Du
>
> When sampling container with perf event on Centos7 with kernel 
> 3.10.0-123.el7.x86_64, slave complained with below error spew:
> {code}
> E0218 16:32:00.591181  8376 perf_event.cpp:408] Failed to get perf sample: 
> Failed to parse perf sample: Failed to parse perf sample line 
> '25871993253,,cycles,mesos/5f23ffca-87ed-4ff6-84f2-6ec3d4098ab8,10059827422,100.00':
>  Unexpected number of fields
> {code}
> it's caused by the current perf format [assumption | 
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob;f=src/linux/perf.cpp;h=1c113a2b3f57877e132bbd65e01fb2f045132128;hb=HEAD#l430]
>  with kernel version below 3.12 
> On 3.10.0-123.el7.x86_64 kernel, the format is with 6 tokens as below:
> value,unit,event,cgroup,running,ratio
> A local modification fixed this error on my test bed, please review this 
> ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4981) Framework (re-)register metric counters broken for calls made via scheduler driver

[Fan Du (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221062#comment-15221062
 ] 

Fan Du commented on MESOS-4981:
---

[~bmahler] & [~vinodkone]

How about not to distinguish {{messages_register_framework}} with 
{{messages_reregister_framework}} in such strict manner?
Update flow of {{subscribe}} by:
{code}
  1. bump messages_register_framework
  2. Various of sanity check
  3. Newborn framework?
 3a. Add new framework
 3b. Return
  4. Add messages_reregister_framework
  5. Otherwise framework is reregistering
 5a. Updating the framework
 5b. Return
{code}

> Framework (re-)register metric counters broken for calls made via scheduler 
> driver
> --
>
> Key: MESOS-4981
> URL: https://issues.apache.org/jira/browse/MESOS-4981
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Anand Mazumdar
>Assignee: Fan Du
>  Labels: mesosphere
>
> The counters {{master/messages_register_framework}} and 
> {{master/messages_reregister_framework}} are no longer being incremented 
> after the scheduler driver started sending {{Call}} messages to the master in 
> Mesos 0.23. We should correctly be incrementing these counters for PID based 
> frameworks as was the case previously.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4492) Add metrics for {RESERVE, UNRESERVE} and {CREATE, DESTROY} offer operation

[Fan Du (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221056#comment-15221056
 ] 

Fan Du commented on MESOS-4492:
---

[~jieyu] I'm wondering if you have any cycles for the final review?
thanks!

> Add metrics for {RESERVE, UNRESERVE} and {CREATE, DESTROY} offer operation
> --
>
> Key: MESOS-4492
> URL: https://issues.apache.org/jira/browse/MESOS-4492
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Fan Du
>Assignee: Fan Du
>Priority: Minor
>
> This ticket aims to enable user or operator to inspect operation statistics 
> such as RESERVE, UNRESERVE, CREATE and DESTROY, current implementation only 
> supports LAUNCH.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4759) Add network/cni isolator for Mesos containerizer.

[Jie Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220952#comment-15220952
 ] 

Jie Yu commented on MESOS-4759:
---

commit c6e26eb018457b28981c2cb17326925f51e102a0
Author: Qian Zhang 
Date:   Thu Mar 31 16:02:42 2016 -0700

Renamed 'getNetworkInfoDir' to 'getContainerDir'.

Review: https://reviews.apache.org/r/45532/

commit d564113e68d829afe72558790c0efd1ae8b9b7b4
Author: Qian Zhang 
Date:   Thu Mar 31 16:02:30 2016 -0700

Made 'ROOT_DIR' a shared mount.

Review: https://reviews.apache.org/r/45531/

commit 7c85517fad42c6bfa36be646ade2917d0f56973c
Author: Qian Zhang 
Date:   Thu Mar 31 16:02:18 2016 -0700

Implemented recover() method of "network/cni" isolator.

Review: https://reviews.apache.org/r/45383/

commit 75ee70466cbed2130019f0fa5207fc99331dad0a
Author: Qian Zhang 
Date:   Thu Mar 31 16:02:05 2016 -0700

Implemented cleanup() method of "network/cni" isolator.

Review: https://reviews.apache.org/r/45082/

> Add network/cni isolator for Mesos containerizer.
> -
>
> Key: MESOS-4759
> URL: https://issues.apache.org/jira/browse/MESOS-4759
> Project: Mesos
>  Issue Type: Task
>Reporter: Jie Yu
>Assignee: Qian Zhang
>
> See the design doc for more context (MESOS-4742).
> The isolator will interact with CNI plugins to create the network for the 
> container to join.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-2706) When the docker-tasks grow, the time spare between Queuing task and Starting container grows

[Timothy Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220889#comment-15220889
 ] 

Timothy Chen commented on MESOS-2706:
-

Btw we already changed stats reading to read from cgroups instead of 
perf/stats, so this should ideally been fixed. Can [~kairu1987] you help verify?

> When the docker-tasks grow, the time spare between Queuing task and Starting 
> container grows
> 
>
> Key: MESOS-2706
> URL: https://issues.apache.org/jira/browse/MESOS-2706
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.22.0
> Environment: My Environment info:
> Mesos 0.22.0 & Marathon 0.82-RC1 both running in one host-server.
> Every docker-task require 0.02 CPU and 128MB ,and the server has 8 cpus and 
> 24G mems.
> So Mesos can launch thousands of task in theory.
> And the docker-task is very light-weight to launch a sshd service .
>Reporter: chenqiuhao
>
> At the beginning, Marathon can launch docker-task very fast,but when the 
> number of tasks in the only-one mesos-slave host reached 50,It seemed 
> Marathon lauch docker-task slow.
> So I check the mesos-slave log,and I found that the time spare between 
> Queuing task and Starting container grew .
> For example, 
> launch the 1st docker task, it takes about 0.008s
> [root@CNSH231434 mesos-slave]# tail -f slave.out |egrep 'Queuing 
> task|Starting container'
> I0508 15:54:00.188350 225779 slave.cpp:1378] Queuing task 
> 'dev-rhel-sf.631d454d-f557-11e4-b4f4-628e0a30542b' for executor 
> dev-rhel-sf.631d454d-f557-11e4-b4f4-628e0a30542b of framework 
> '20150202-112355-2684495626-5050-26153-
> I0508 15:54:00.196832 225781 docker.cpp:581] Starting container 
> 'd0b0813a-6cb6-4dfd-bbce-f1b338744285' for task 
> 'dev-rhel-sf.631d454d-f557-11e4-b4f4-628e0a30542b' (and executor 
> 'dev-rhel-sf.631d454d-f557-11e4-b4f4-628e0a30542b') of framework 
> '20150202-112355-2684495626-5050-26153-'
> launch the 50th docker task, it takes about 4.9s
> I0508 16:12:10.908596 225781 slave.cpp:1378] Queuing task 
> 'dev-rhel-sf.ed3a6922-f559-11e4-ae87-628e0a30542b' for executor 
> dev-rhel-sf.ed3a6922-f559-11e4-ae87-628e0a30542b of framework 
> '20150202-112355-2684495626-5050-26153-
> I0508 16:12:15.801503 225778 docker.cpp:581] Starting container 
> '482dd47f-b9ab-4b09-b89e-e361d6f004a4' for task 
> 'dev-rhel-sf.ed3a6922-f559-11e4-ae87-628e0a30542b' (and executor 
> 'dev-rhel-sf.ed3a6922-f559-11e4-ae87-628e0a30542b') of framework 
> '20150202-112355-2684495626-5050-26153-'
> And when i launch the 100th docker task,it takes about 13s!
> And I did the same test in one 24 Cpus and 256G mems server-host, it got the 
> same result.
> Did somebody have the same experience , or Can help to do the same pressure 
> test ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-2369) Segfault when mesos-slave tries to clean up docker containers on startup

[Timothy Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220887#comment-15220887
 ] 

Timothy Chen commented on MESOS-2369:
-

This should already been fixed now, please re-open when it occurs again.

> Segfault when mesos-slave tries to clean up docker containers on startup
> 
>
> Key: MESOS-2369
> URL: https://issues.apache.org/jira/browse/MESOS-2369
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.21.1
> Environment: Debian Jessie, mesos package 0.21.1-1.2.debian77 
> docker 1.3.2 build 39fa2fa
>Reporter: Pas
>
> I did a gdb backtrace, it seems like a stack overflow due to a bit too much 
> recursion.
> The interesting aspect is that after running mesos-slave with strace -f -b 
> execve it successfully proceeded with the docker cleanup. However, there were 
> a few strace sessions (on other slaves) where I was able to observe the 
> SIGSEGV, and it was around (or a bit before) the "docker ps -a" call, because 
> docker got a broken pipe shortly, then got killed by the propagating SIGSEGV 
> signal.
> {code}
> 
> #59296 0x76e7cd98 in process::Future 
> process::Future long>::then(std::tr1::function (unsigned long const&)> const&) const () from 
> /usr/local/lib/libmesos-0.21.1.so
> #59297 0x76e4f5d3 in process::io::internal::_read(int, 
> std::tr1::shared_ptr const&, boost::shared_array const&, 
> unsigned long) () from /usr/local/lib/libmesos-0.21.1.so
> #59298 0x76e5012c in process::io::internal::__read(unsigned long, 
> int, std::tr1::shared_ptr const&, boost::shared_array 
> const&, unsigned long) () from /usr/local/lib/libmesos-0.21.1.so
> #59299 0x76e53000 in 
> std::tr1::_Function_handler const&), std::tr1::_Bind (*(std::tr1::_Placeholder<1>, int, std::tr1::shared_ptr, 
> boost::shared_array, unsigned long))(unsigned long, int, 
> std::tr1::shared_ptr const&, boost::shared_array const&, 
> unsigned long)> >::_M_invoke(std::tr1::_Any_data const&, unsigned long 
> const&) () from /usr/local/lib/libmesos-0.21.1.so
> #59300 0x76e7d23b in void process::internal::thenf std::string>(std::tr1::shared_ptr const&, 
> std::tr1::function 
> const&, process::Future const&) ()
>from /usr/local/lib/libmesos-0.21.1.so
> #59301 0x7689ee60 in process::Future long>::onAny(std::tr1::function const&)> 
> const&) const () from /usr/local/lib/libmesos-0.21.1.so
> #59302 0x76e7cd98 in process::Future 
> process::Future long>::then(std::tr1::function (unsigned long const&)> const&) const () from 
> /usr/local/lib/libmesos-0.21.1.so
> #59303 0x76e4f5d3 in process::io::internal::_read(int, 
> std::tr1::shared_ptr const&, boost::shared_array const&, 
> unsigned long) () from /usr/local/lib/libmesos-0.21.1.so
> #59304 0x76e5012c in process::io::internal::__read(unsigned long, 
> int, std::tr1::shared_ptr const&, boost::shared_array 
> const&, unsigned long) () from /usr/local/lib/libmesos-0.21.1.so
> #59305 0x76e53000 in 
> std::tr1::_Function_handler const&), std::tr1::_Bind (*(std::tr1::_Placeholder<1>, int, std::tr1::shared_ptr, 
> boost::shared_array, unsigned long))(unsigned long, int, 
> std::tr1::shared_ptr const&, boost::shared_array const&, 
> unsigned long)> >::_M_invoke(std::tr1::_Any_data const&, unsigned long 
> const&) () from /usr/local/lib/libmesos-0.21.1.so
> #59306 0x76e7d23b in void process::internal::thenf std::string>(std::tr1::shared_ptr const&, 
> std::tr1::function 
> const&, process::Future const&) ()
>from /usr/local/lib/libmesos-0.21.1.so
> #59307 0x7689ee60 in process::Future long>::onAny(std::tr1::function const&)> 
> const&) const () from /usr/local/lib/libmesos-0.21.1.so
> #59308 0x76e7cd98 in process::Future 
> process::Future long>::then(std::tr1::function (unsigned long const&)> const&) const () from 
> /usr/local/lib/libmesos-0.21.1.so
> #59309 0x76e4f5d3 in process::io::internal::_read(int, 
> std::tr1::shared_ptr const&, boost::shared_array const&, 
> unsigned long) () from /usr/local/lib/libmesos-0.21.1.so
> #59310 0x76e5012c in process::io::internal::__read(unsigned long, 
> int, std::tr1::shared_ptr const&, boost::shared_array 
> const&, unsigned long) () from /usr/local/lib/libmesos-0.21.1.so
> #59311 0x76e53000 in 
> std::tr1::_Function_handler const&), std::tr1::_Bind (*(std::tr1::_Placeholder<1>, int, std::tr1::shared_ptr, 
> 

[jira] [Commented] (MESOS-3558) Implement HTTPCommandExecutor that uses the Executor Library

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220848#comment-15220848
 ] 

Vinod Kone commented on MESOS-3558:
---

New review chain: https://reviews.apache.org/r/44423/

> Implement  HTTPCommandExecutor that uses the Executor Library 
> --
>
> Key: MESOS-3558
> URL: https://issues.apache.org/jira/browse/MESOS-3558
> Project: Mesos
>  Issue Type: Task
>Reporter: Anand Mazumdar
>Assignee: Qian Zhang
>  Labels: mesosphere
>
> Instead of using the {{MesosExecutorDriver}} , we should make the 
> {{CommandExecutor}} in {{src/launcher/executor.cpp}} use the new Executor 
> HTTP Library that we create in {{MESOS-3550}}. 
> This would act as a good validation of the {{HTTP API}} implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4982) Create a long running HTTP based framework

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220828#comment-15220828
 ] 

Vinod Kone commented on MESOS-4982:
---

Lets just update src/examples/long_lived_framework.cpp to use v1 API.

> Create a long running HTTP based framework
> --
>
> Key: MESOS-4982
> URL: https://issues.apache.org/jira/browse/MESOS-4982
> Project: Mesos
>  Issue Type: Task
>Reporter: Anand Mazumdar
>  Labels: mesosphere
>
> We need a long running test framework similar to 
> {{src/examples/long_lived_framework.cpp}} that uses the v1 Scheduler API.
> This would allow us to vet the v1 API and the scheduler library in test 
> clusters.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4612) Update vendored ZooKeeper to 3.4.8

[Vinod Kone (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vinod Kone updated MESOS-4612:
--
  Sprint: Mesosphere Sprint 32
Story Points: 3

> Update vendored ZooKeeper to 3.4.8
> --
>
> Key: MESOS-4612
> URL: https://issues.apache.org/jira/browse/MESOS-4612
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Cody Maloney
>Assignee: Chen Zhiwei
>  Labels: mesosphere, tech-debt, zookeeper
>
> See: http://zookeeper.apache.org/doc/r3.4.8/releasenotes.html for 
> improvements / bug fixes
> Added a new patch that solved 
> [ZOOKEEPER-1643](https://issues.apache.org/jira/browse/ZOOKEEPER-1643)
> The original patch: 
> 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4828) XFS disk quota isolator

[Jie Yu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jie Yu updated MESOS-4828:
--
Shepherd: Yan Xu  (was: Jie Yu)

> XFS disk quota isolator
> ---
>
> Key: MESOS-4828
> URL: https://issues.apache.org/jira/browse/MESOS-4828
> Project: Mesos
>  Issue Type: Improvement
>  Components: isolation
>Reporter: James Peach
>Assignee: James Peach
>
> Implement a disk resource isolator using XFS project quotas. Compared to the 
> {{posix/disk}} isolator, this doesn't need to scan the filesystem 
> periodically, and applications receive a {{EDQUOT}} error instead of being 
> summarily killed.
> This initial implementation only isolates sandbox directory resources, since 
> isolation doesn't have any visibility into the the lifecycle of volumes, 
> which is needed to assign and track project IDs.
> The build dependencies for this are XFS header (from xfsprogs-devel) and 
> libblkid. We need libblkid or the equivalent to map filesystem paths to block 
> devices in order to apply quota.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1797) Packaged Zookeeper does not compile on OSX Yosemite

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220703#comment-15220703
 ] 

ASF GitHub Bot commented on MESOS-1797:
---

Github user chenzhiwei commented on a diff in the pull request:

https://github.com/apache/mesos/pull/93#discussion_r58131254
  
--- Diff: 3rdparty/Makefile.am ---
@@ -51,7 +51,7 @@ EXTRA_DIST =  \
 EXTRA_DIST +=  \
   $(LEVELDB).patch
 
-# We need to patch ZooKeeper in order to get 3.4.5 to compile on
+# We need to patch ZooKeeper in order to get 3.4.8 to compile on
 # OS X 10.10. See: MESOS-1797.
--- End diff --

Thank your for pointing this, I will remove this comment. And for the 
zookeeper patch file I think I already removed it.


> Packaged Zookeeper does not compile on OSX Yosemite
> ---
>
> Key: MESOS-1797
> URL: https://issues.apache.org/jira/browse/MESOS-1797
> Project: Mesos
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 0.19.1, 0.20.0, 0.21.0
>Reporter: Dario Rexin
>Assignee: Benjamin Mahler
>Priority: Minor
> Fix For: 0.21.0
>
>
> I have been struggling with this for some time (due to my lack of knowledge 
> about C compiler error messages) and finally found a way to make it compile. 
> The problem is that Zookeeper defines a function `htonll` that is a builtin 
> function in Yosemite. For me it worked to just remove this function, but as 
> it needs to keep working on other systems as well, we would need some check 
> for the OS version or if the function is already defined.
> Here are the links to the source:
> https://github.com/apache/zookeeper/blob/trunk/src/c/include/recordio.h#L73
> https://github.com/apache/zookeeper/blob/trunk/src/c/src/recordio.c#L83-L97



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5064) Document avoiding using `/tmp` as agent’s work directory in production

[Greg Mann (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220643#comment-15220643
 ] 

Greg Mann commented on MESOS-5064:
--

Reviews here:
https://reviews.apache.org/r/45562/
https://reviews.apache.org/r/45563/

> Document avoiding using `/tmp` as agent’s work directory in production
> --
>
> Key: MESOS-5064
> URL: https://issues.apache.org/jira/browse/MESOS-5064
> Project: Mesos
>  Issue Type: Bug
>Reporter: Artem Harutyunyan
>Assignee: Greg Mann
>
> Following a crash report from the user we need to be more explicit about the 
> dangers of using {{/tmp}} as agent {{work_dir}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-3782) Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create symlinks)

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220626#comment-15220626
 ] 

Vinod Kone edited comment on MESOS-3782 at 3/31/16 8:38 PM:


-For step 2) are you suggesting to rename mesos-slave.sh to mesos-agent.sh or 
to make a copy? We can't just rename because operators might be depending on 
these scripts already.-

Instead of symlinks, lets just create copies of shell scripts. That will avoid 
running into any weird symlink issues. The shell scripts are small anyway?


was (Author: vinodkone):
For step 2) are you suggesting to rename mesos-slave.sh to mesos-agent.sh or to 
make a copy? We can't just rename because operators might be depending on these 
scripts already.

> Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create 
> symlinks)
> --
>
> Key: MESOS-3782
> URL: https://issues.apache.org/jira/browse/MESOS-3782
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: zhou xing
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3782) Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create symlinks)

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220626#comment-15220626
 ] 

Vinod Kone commented on MESOS-3782:
---

For step 2) are you suggesting to rename mesos-slave.sh to mesos-agent.sh or to 
make a copy? We can't just rename because operators might be depending on these 
scripts already.

> Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create 
> symlinks)
> --
>
> Key: MESOS-3782
> URL: https://issues.apache.org/jira/browse/MESOS-3782
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: zhou xing
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3781) Replace Master/Slave Terminology Phase I - Add duplicate agent flags

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220619#comment-15220619
 ] 

Vinod Kone commented on MESOS-3781:
---

Can you transition the tickets to reviewable once you post a review? I'll do it 
this time. Thanks.

> Replace Master/Slave Terminology Phase I - Add duplicate agent flags 
> -
>
> Key: MESOS-3781
> URL: https://issues.apache.org/jira/browse/MESOS-3781
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: Jay Guo
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4887) Design doc for Slave/Agent rename

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220612#comment-15220612
 ] 

Vinod Kone commented on MESOS-4887:
---

[~darroyo] Can you resolve the open issues in the design doc and resolve this 
ticket? Work has started on the individual tickets.

> Design doc for Slave/Agent rename
> -
>
> Key: MESOS-4887
> URL: https://issues.apache.org/jira/browse/MESOS-4887
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Diana Arroyo
>
> Design doc: 
> https://docs.google.com/document/d/1P8_4wdk29I6NoVTjbFkRl05-tfxV9PY4WLoRNvExupM/edit#heading=h.9g7fqjh6652v



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4766) Improve allocator performance.

[Michael Park (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Park updated MESOS-4766:

Sprint: Mesosphere Sprint 32

> Improve allocator performance.
> --
>
> Key: MESOS-4766
> URL: https://issues.apache.org/jira/browse/MESOS-4766
> Project: Mesos
>  Issue Type: Epic
>  Components: allocation
>Reporter: Benjamin Mahler
>Priority: Critical
>
> This is an epic to track the various tickets around improving the performance 
> of the allocator, including the following:
> * Preventing un-necessary backup of the allocator.
> * Reducing the cost of allocations and allocator state updates.
> * Improving performance of the DRF sorter.
> * More benchmarking to simulate scenarios with performance issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4770) Investigate performance improvements for 'Resources' class.

[Michael Park (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Park updated MESOS-4770:

Sprint: Mesosphere Sprint 32

> Investigate performance improvements for 'Resources' class.
> ---
>
> Key: MESOS-4770
> URL: https://issues.apache.org/jira/browse/MESOS-4770
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Benjamin Mahler
>Assignee: Michael Park
>Priority: Critical
>
> Currently we have some performance issues when we have heavy usage of the 
> {{Resources}} class. Currently, we tend to work around these issues (e.g. 
> reduce the amount of Resources arithmetic operations in the caller code).
> The implementation of {{Resources}} currently consists of wrapping underlying 
> {{Resource}} protobuf objects and manipulating them. This is fairly expensive 
> compared to doing things more directly with C++ objects.
> This ticket is to explore the performance improvements of using C++ objects 
> more directly instead of working off of {{Resource}} objects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-2331) MasterSlaveReconciliationTest.ReconcileRace is flaky

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220477#comment-15220477
 ] 

Vinod Kone commented on MESOS-2331:
---

Saw this on ASF CI when I committed the upgrade to protobuf 2.6.1 (not sure if 
it's just coincidental).

{code}
[ RUN  ] MasterSlaveReconciliationTest.ReconcileRace
I0331 18:41:04.018868  1701 cluster.cpp:139] Creating default 'local' authorizer
I0331 18:41:04.025219  1701 leveldb.cpp:174] Opened db in 6.145168ms
I0331 18:41:04.027966  1701 leveldb.cpp:181] Compacted db in 2.725315ms
I0331 18:41:04.028023  1701 leveldb.cpp:196] Created db iterator in 32098ns
I0331 18:41:04.028041  1701 leveldb.cpp:202] Seeked to beginning of db in 9050ns
I0331 18:41:04.028053  1701 leveldb.cpp:271] Iterated through 0 keys in the db 
in 7186ns
I0331 18:41:04.028097  1701 replica.cpp:779] Replica recovered with log 
positions 0 -> 0 with 1 holes and 0 unlearned
I0331 18:41:04.029259  1731 recover.cpp:447] Starting replica recovery
I0331 18:41:04.029541  1719 recover.cpp:473] Replica is in EMPTY status
I0331 18:41:04.030627  1720 replica.cpp:673] Replica in EMPTY status received a 
broadcasted recover request from (5660)@172.17.0.2:47086
I0331 18:41:04.031069  1723 recover.cpp:193] Received a recover response from a 
replica in EMPTY status
I0331 18:41:04.036355  1723 recover.cpp:564] Updating replica status to STARTING
I0331 18:41:04.038835  1729 master.cpp:376] Master 
2cabf4ec-31e0-4769-9e38-5581d3d8fdfd (ff176ecfc889) started on 172.17.0.2:47086
I0331 18:41:04.038995  1723 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 2.398241ms
I0331 18:41:04.039036  1723 replica.cpp:320] Persisted replica status to 
STARTING
I0331 18:41:04.038871  1729 master.cpp:378] Flags at startup: --acls="" 
--allocation_interval="1secs" --allocator="HierarchicalDRF" 
--authenticate="true" --authenticate_http="true" --authenticate_slaves="true" 
--authenticators="crammd5" --authorizers="local" 
--credentials="/tmp/3c2EEo/credentials" --framework_sorter="drf" --help="false" 
--hostname_lookup="true" --http_authenticators="basic" 
--initialize_driver_logging="true" --log_auto_initialize="true" 
--logbufsecs="0" --logging_level="INFO" --max_completed_frameworks="50" 
--max_completed_tasks_per_framework="1000" --max_slave_ping_timeouts="5" 
--quiet="false" --recovery_slave_removal_limit="100%" 
--registry="replicated_log" --registry_fetch_timeout="1mins" 
--registry_store_timeout="100secs" --registry_strict="true" 
--root_submissions="true" --slave_ping_timeout="15secs" 
--slave_reregister_timeout="10mins" --user_sorter="drf" --version="false" 
--webui_dir="/mesos/mesos-0.29.0/_inst/share/mesos/webui" 
--work_dir="/tmp/3c2EEo/master" --zk_session_timeout="10secs"
I0331 18:41:04.040617  1729 master.cpp:427] Master only allowing authenticated 
frameworks to register
I0331 18:41:04.040630  1729 master.cpp:432] Master only allowing authenticated 
slaves to register
I0331 18:41:04.040640  1729 credentials.hpp:37] Loading credentials for 
authentication from '/tmp/3c2EEo/credentials'
I0331 18:41:04.040983  1729 master.cpp:474] Using default 'crammd5' 
authenticator
I0331 18:41:04.041123  1729 master.cpp:545] Using default 'basic' HTTP 
authenticator
I0331 18:41:04.041169  1731 recover.cpp:473] Replica is in STARTING status
I0331 18:41:04.041245  1729 master.cpp:583] Authorization enabled
I0331 18:41:04.041767  1731 hierarchical.cpp:144] Initialized hierarchical 
allocator process
I0331 18:41:04.041832  1731 whitelist_watcher.cpp:77] No whitelist given
I0331 18:41:04.043683  1729 master.cpp:1826] The newly elected leader is 
master@172.17.0.2:47086 with id 2cabf4ec-31e0-4769-9e38-5581d3d8fdfd
I0331 18:41:04.043718  1729 master.cpp:1839] Elected as the leading master!
I0331 18:41:04.043731  1729 master.cpp:1526] Recovering from registrar
I0331 18:41:04.043979  1729 registrar.cpp:307] Recovering registrar
I0331 18:41:04.048002  1729 replica.cpp:673] Replica in STARTING status 
received a broadcasted recover request from (5662)@172.17.0.2:47086
I0331 18:41:04.048368  1729 recover.cpp:193] Received a recover response from a 
replica in STARTING status
I0331 18:41:04.048904  1729 recover.cpp:564] Updating replica status to VOTING
I0331 18:41:04.052000  1722 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 2.020256ms
I0331 18:41:04.052044  1722 replica.cpp:320] Persisted replica status to VOTING
I0331 18:41:04.052170  1722 recover.cpp:578] Successfully joined the Paxos group
I0331 18:41:04.052336  1722 recover.cpp:462] Recover process terminated
I0331 18:41:04.052865  1722 log.cpp:659] Attempting to start the writer
I0331 18:41:04.055016  1730 replica.cpp:493] Replica received implicit promise 
request from (5663)@172.17.0.2:47086 with proposal 1
I0331 18:41:04.056974  1730 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 1.935964ms
I0331 18:41:04.057008  1730 replica.cpp:342] 

[jira] [Commented] (MESOS-5074) SlaveTest.RemoveUnregisteredTerminatedExecutor is flaky

[Joseph Wu (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220445#comment-15220445
 ] 

Joseph Wu commented on MESOS-5074:
--

This appears to be a race between two operations on the {{TestContainerizer}}
* Here, the {{TestContainerizer}} creates a promise on a future termination.  
https://github.com/apache/mesos/blob/b2e6228378f93b4c21c22ae9a1b6fdd7c12b90a6/src/tests/slave_tests.cpp#L299
* Later in the test, we satisfy the promise and immediately delete it.  
https://github.com/apache/mesos/blob/b2e6228378f93b4c21c22ae9a1b6fdd7c12b90a6/src/tests/slave_tests.cpp#L311-L312
 

The {{TestContainerizer}} is unfortunately *not* a libprocess process, so it 
can be interleaved.
The following interleaving can lead to this failure:
| {{TestContainerizer::_wait}} | {{TestContainerizer::_destroy}} |
| {code}
  if (!promises.contains(containerId)) {
return Failure("Unknown container: " + stringify(containerId));
  }

  // ->




  

  return promises[containerId]->future();
{code} | {code}
  if (promises.contains(containerId)) {
containerizer::Termination termination;
termination.set_message("Killed executor");
termination.set_status(0);

promises[containerId]->set(termination);
promises.erase(containerId);

// <
  }
{code}

> SlaveTest.RemoveUnregisteredTerminatedExecutor is flaky
> ---
>
> Key: MESOS-5074
> URL: https://issues.apache.org/jira/browse/MESOS-5074
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.28.0
> Environment: Ubuntu 14.04, using clang, with libevent and SSL enabled
>Reporter: Greg Mann
>  Labels: mesosphere, tests
>
> Observed on the ASF CI:
> {code}
> [ RUN  ] SlaveTest.RemoveUnregisteredTerminatedExecutor
> I0331 17:09:45.304322  1299 cluster.cpp:139] Creating default 'local' 
> authorizer
> I0331 17:09:45.310246  1299 leveldb.cpp:174] Opened db in 5.653849ms
> I0331 17:09:45.311182  1299 leveldb.cpp:181] Compacted db in 897714ns
> I0331 17:09:45.311238  1299 leveldb.cpp:196] Created db iterator in 35116ns
> I0331 17:09:45.311264  1299 leveldb.cpp:202] Seeked to beginning of db in 
> 11547ns
> I0331 17:09:45.311280  1299 leveldb.cpp:271] Iterated through 0 keys in the 
> db in 8343ns
> I0331 17:09:45.311334  1299 replica.cpp:779] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0331 17:09:45.312374  1328 recover.cpp:447] Starting replica recovery
> I0331 17:09:45.312685  1327 recover.cpp:473] Replica is in EMPTY status
> I0331 17:09:45.313987  1318 replica.cpp:673] Replica in EMPTY status received 
> a broadcasted recover request from (12029)@172.17.0.2:47264
> I0331 17:09:45.314481  1321 recover.cpp:193] Received a recover response from 
> a replica in EMPTY status
> I0331 17:09:45.314913  1324 recover.cpp:564] Updating replica status to 
> STARTING
> I0331 17:09:45.315553  1319 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 527754ns
> I0331 17:09:45.315587  1319 replica.cpp:320] Persisted replica status to 
> STARTING
> I0331 17:09:45.315762  1326 recover.cpp:473] Replica is in STARTING status
> I0331 17:09:45.317013  1322 replica.cpp:673] Replica in STARTING status 
> received a broadcasted recover request from (12030)@172.17.0.2:47264
> I0331 17:09:45.317533  1322 recover.cpp:193] Received a recover response from 
> a replica in STARTING status
> I0331 17:09:45.317993  1319 recover.cpp:564] Updating replica status to VOTING
> I0331 17:09:45.318450  1322 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 354962ns
> I0331 17:09:45.318478  1322 replica.cpp:320] Persisted replica status to 
> VOTING
> I0331 17:09:45.318559  1319 recover.cpp:578] Successfully joined the Paxos 
> group
> I0331 17:09:45.318720  1319 recover.cpp:462] Recover process terminated
> I0331 17:09:45.320158  1317 master.cpp:376] Master 
> 9b06f6db-72f1-42be-b262-98eb1ddb86e2 (29ba6f7aca97) started on 
> 172.17.0.2:47264
> I0331 17:09:45.320196  1317 master.cpp:378] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_http="true" --authenticate_slaves="true" 
> --authenticators="crammd5" --authorizers="local" 
> --credentials="/tmp/HoiV0t/credentials" --framework_sorter="drf" 
> --help="false" --hostname_lookup="true" --http_authenticators="basic" 
> --initialize_driver_logging="true" --log_auto_initialize="true" 
> --logbufsecs="0" --logging_level="INFO" --max_completed_frameworks="50" 
> --max_completed_tasks_per_framework="1000" --max_slave_ping_timeouts="5" 
> --quiet="false" --recovery_slave_removal_limit="100%" 
> --registry="replicated_log" --registry_fetch_timeout="1mins" 
> --registry_store_timeout="100secs" --registry_strict="true" 
> --root_submissions="true" 

[jira] [Created] (MESOS-5074) SlaveTest.RemoveUnregisteredTerminatedExecutor is flaky

[Greg Mann (JIRA)]

Greg Mann created MESOS-5074:


 Summary: SlaveTest.RemoveUnregisteredTerminatedExecutor is flaky
 Key: MESOS-5074
 URL: https://issues.apache.org/jira/browse/MESOS-5074
 Project: Mesos
  Issue Type: Bug
Affects Versions: 0.28.0
 Environment: Ubuntu 14.04, using clang, with libevent and SSL enabled
Reporter: Greg Mann


Observed on the ASF CI:

{code}
[ RUN  ] SlaveTest.RemoveUnregisteredTerminatedExecutor
I0331 17:09:45.304322  1299 cluster.cpp:139] Creating default 'local' authorizer
I0331 17:09:45.310246  1299 leveldb.cpp:174] Opened db in 5.653849ms
I0331 17:09:45.311182  1299 leveldb.cpp:181] Compacted db in 897714ns
I0331 17:09:45.311238  1299 leveldb.cpp:196] Created db iterator in 35116ns
I0331 17:09:45.311264  1299 leveldb.cpp:202] Seeked to beginning of db in 
11547ns
I0331 17:09:45.311280  1299 leveldb.cpp:271] Iterated through 0 keys in the db 
in 8343ns
I0331 17:09:45.311334  1299 replica.cpp:779] Replica recovered with log 
positions 0 -> 0 with 1 holes and 0 unlearned
I0331 17:09:45.312374  1328 recover.cpp:447] Starting replica recovery
I0331 17:09:45.312685  1327 recover.cpp:473] Replica is in EMPTY status
I0331 17:09:45.313987  1318 replica.cpp:673] Replica in EMPTY status received a 
broadcasted recover request from (12029)@172.17.0.2:47264
I0331 17:09:45.314481  1321 recover.cpp:193] Received a recover response from a 
replica in EMPTY status
I0331 17:09:45.314913  1324 recover.cpp:564] Updating replica status to STARTING
I0331 17:09:45.315553  1319 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 527754ns
I0331 17:09:45.315587  1319 replica.cpp:320] Persisted replica status to 
STARTING
I0331 17:09:45.315762  1326 recover.cpp:473] Replica is in STARTING status
I0331 17:09:45.317013  1322 replica.cpp:673] Replica in STARTING status 
received a broadcasted recover request from (12030)@172.17.0.2:47264
I0331 17:09:45.317533  1322 recover.cpp:193] Received a recover response from a 
replica in STARTING status
I0331 17:09:45.317993  1319 recover.cpp:564] Updating replica status to VOTING
I0331 17:09:45.318450  1322 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 354962ns
I0331 17:09:45.318478  1322 replica.cpp:320] Persisted replica status to VOTING
I0331 17:09:45.318559  1319 recover.cpp:578] Successfully joined the Paxos group
I0331 17:09:45.318720  1319 recover.cpp:462] Recover process terminated
I0331 17:09:45.320158  1317 master.cpp:376] Master 
9b06f6db-72f1-42be-b262-98eb1ddb86e2 (29ba6f7aca97) started on 172.17.0.2:47264
I0331 17:09:45.320196  1317 master.cpp:378] Flags at startup: --acls="" 
--allocation_interval="1secs" --allocator="HierarchicalDRF" 
--authenticate="true" --authenticate_http="true" --authenticate_slaves="true" 
--authenticators="crammd5" --authorizers="local" 
--credentials="/tmp/HoiV0t/credentials" --framework_sorter="drf" --help="false" 
--hostname_lookup="true" --http_authenticators="basic" 
--initialize_driver_logging="true" --log_auto_initialize="true" 
--logbufsecs="0" --logging_level="INFO" --max_completed_frameworks="50" 
--max_completed_tasks_per_framework="1000" --max_slave_ping_timeouts="5" 
--quiet="false" --recovery_slave_removal_limit="100%" 
--registry="replicated_log" --registry_fetch_timeout="1mins" 
--registry_store_timeout="100secs" --registry_strict="true" 
--root_submissions="true" --slave_ping_timeout="15secs" 
--slave_reregister_timeout="10mins" --user_sorter="drf" --version="false" 
--webui_dir="/mesos/mesos-0.29.0/_inst/share/mesos/webui" 
--work_dir="/tmp/HoiV0t/master" --zk_session_timeout="10secs"
I0331 17:09:45.320572  1317 master.cpp:427] Master only allowing authenticated 
frameworks to register
I0331 17:09:45.320585  1317 master.cpp:432] Master only allowing authenticated 
slaves to register
I0331 17:09:45.320595  1317 credentials.hpp:37] Loading credentials for 
authentication from '/tmp/HoiV0t/credentials'
I0331 17:09:45.32  1317 master.cpp:474] Using default 'crammd5' 
authenticator
I0331 17:09:45.321318  1317 master.cpp:545] Using default 'basic' HTTP 
authenticator
I0331 17:09:45.321517  1317 master.cpp:583] Authorization enabled
I0331 17:09:45.321770  1325 hierarchical.cpp:144] Initialized hierarchical 
allocator process
I0331 17:09:45.321846  1325 whitelist_watcher.cpp:77] No whitelist given
I0331 17:09:45.325551  1317 master.cpp:1826] The newly elected leader is 
master@172.17.0.2:47264 with id 9b06f6db-72f1-42be-b262-98eb1ddb86e2
I0331 17:09:45.325592  1317 master.cpp:1839] Elected as the leading master!
I0331 17:09:45.325604  1317 master.cpp:1526] Recovering from registrar
I0331 17:09:45.325875  1331 registrar.cpp:307] Recovering registrar
I0331 17:09:45.326637  1331 log.cpp:659] Attempting to start the writer
I0331 17:09:45.328130  1324 replica.cpp:493] Replica received implicit promise 
request from (12032)@172.17.0.2:47264 with proposal 1
I0331 17:09:45.328989  

[jira] [Commented] (MESOS-1797) Packaged Zookeeper does not compile on OSX Yosemite

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220283#comment-15220283
 ] 

ASF GitHub Bot commented on MESOS-1797:
---

Github user vinodkone commented on a diff in the pull request:

https://github.com/apache/mesos/pull/93#discussion_r58094904
  
--- Diff: 3rdparty/Makefile.am ---
@@ -51,7 +51,7 @@ EXTRA_DIST =  \
 EXTRA_DIST +=  \
   $(LEVELDB).patch
 
-# We need to patch ZooKeeper in order to get 3.4.5 to compile on
+# We need to patch ZooKeeper in order to get 3.4.8 to compile on
 # OS X 10.10. See: MESOS-1797.
--- End diff --

Does this comment still apply? AFAICT MESOS-1797 doesn't apply to ZK 3.4.8 
since that issue has been resolved in ZK 3.4.7. Looks all the patch does is 
apply PPC specific fixes for which you already submitted a review 
https://reviews.apache.org/r/45376/.

I would recommend to kill the zookeper.patch stuff in this review 
altogether since 3.4.8 doesn't need any patches per se. Then in 
https://reviews.apache.org/r/45376/ you can add back the patch stuff and 
mention that you need the patch to compile it on PPC.



> Packaged Zookeeper does not compile on OSX Yosemite
> ---
>
> Key: MESOS-1797
> URL: https://issues.apache.org/jira/browse/MESOS-1797
> Project: Mesos
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 0.19.1, 0.20.0, 0.21.0
>Reporter: Dario Rexin
>Assignee: Benjamin Mahler
>Priority: Minor
> Fix For: 0.21.0
>
>
> I have been struggling with this for some time (due to my lack of knowledge 
> about C compiler error messages) and finally found a way to make it compile. 
> The problem is that Zookeeper defines a function `htonll` that is a builtin 
> function in Yosemite. For me it worked to just remove this function, but as 
> it needs to keep working on other systems as well, we would need some check 
> for the OS version or if the function is already defined.
> Here are the links to the source:
> https://github.com/apache/zookeeper/blob/trunk/src/c/include/recordio.h#L73
> https://github.com/apache/zookeeper/blob/trunk/src/c/src/recordio.c#L83-L97



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4610) MasterContender/MasterDetector should be loadable as modules

[Kapil Arya (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220271#comment-15220271
 ] 

Kapil Arya commented on MESOS-4610:
---

Hey [~anurag.prakash.singh], 

Just gave a pass at the RRs. Most of those are style related. I still need to 
ask for preferences about https://reviews.apache.org/r/44547 and will get back 
to you once I have more information.

> MasterContender/MasterDetector should be loadable as modules
> 
>
> Key: MESOS-4610
> URL: https://issues.apache.org/jira/browse/MESOS-4610
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Mark Cavage
>Assignee: Mark Cavage
>  Labels: mesosphere
>
> Currently mesos depends on Zookeeper for leader election and notification to 
> slaves, although there is a C++ hierarchy in the code to support alternatives 
> (e.g., unit tests use an in-memory implementation). From an operational 
> perspective, many organizations/users do not want to take a dependency on 
> Zookeeper, and use an alternative solution to implementing leader election. 
> Our organization in particular, very much wants this, and as a reference 
> there have been several requests from the community (see referenced tickets) 
> to replace with etcd/consul/etc.
> This ticket will serve as the work effort to modularize the 
> MasterContender/MasterDetector APIs such that integrators can build a 
> pluggable solution of their choice; this ticket will not fold in any 
> implementations such as etcd et al., but simply move this hierarchy to be 
> fully pluggable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4610) MasterContender/MasterDetector should be loadable as modules

[ANURAG SINGH (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220250#comment-15220250
 ] 

ANURAG SINGH commented on MESOS-4610:
-

Sure. I missed a space between the colon and the trailing slash. It's fixed now.

> MasterContender/MasterDetector should be loadable as modules
> 
>
> Key: MESOS-4610
> URL: https://issues.apache.org/jira/browse/MESOS-4610
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Mark Cavage
>Assignee: Mark Cavage
>  Labels: mesosphere
>
> Currently mesos depends on Zookeeper for leader election and notification to 
> slaves, although there is a C++ hierarchy in the code to support alternatives 
> (e.g., unit tests use an in-memory implementation). From an operational 
> perspective, many organizations/users do not want to take a dependency on 
> Zookeeper, and use an alternative solution to implementing leader election. 
> Our organization in particular, very much wants this, and as a reference 
> there have been several requests from the community (see referenced tickets) 
> to replace with etcd/consul/etc.
> This ticket will serve as the work effort to modularize the 
> MasterContender/MasterDetector APIs such that integrators can build a 
> pluggable solution of their choice; this ticket will not fold in any 
> implementations such as etcd et al., but simply move this hierarchy to be 
> fully pluggable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-4610) MasterContender/MasterDetector should be loadable as modules

[ANURAG SINGH (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15197665#comment-15197665
 ] 

ANURAG SINGH edited comment on MESOS-4610 at 3/31/16 5:16 PM:
--

We've proceeded further with the review and here's the updated list of changes:

https://reviews.apache.org/r/44287/ : Added MasterContender and MasterDetector 
abstract classes.
https://reviews.apache.org/r/44288/ : Changed MasterDetector/Contender 
namespace.
https://reviews.apache.org/r/44543/ : Removed unnecessary MasterContender and 
MasterDetector definitions.
https://reviews.apache.org/r/44544/ : Moved contender and detector definitions 
into separate directories.
https://reviews.apache.org/r/44545/ : Instead of keeping standalone and 
zookeper contender/detector class
definitions and implementations in the same file, separated them. Also
made the necessary changes in users of class headers to point to the
new locations.
https://reviews.apache.org/r/44546/ : Moved functions in promises to a common 
header file.
https://reviews.apache.org/r/44547/ : Added functions in promises to the 
collect header.
https://reviews.apache.org/r/44289/ : Added support for contender and detector 
modules.
https://reviews.apache.org/r/44669/ : Added createFromModule methods to 
MasterContender and MasterDetector.
https://reviews.apache.org/r/44670/ : Added master_detector and 
master_contender flags.


was (Author: anurag.prakash.singh):
We've proceeded further with the review and here's the updated list of changes:

https://reviews.apache.org/r/44287/: Added MasterContender and MasterDetector 
abstract classes.
https://reviews.apache.org/r/44288/: Changed MasterDetector/Contender namespace.
https://reviews.apache.org/r/44543/: Removed unnecessary MasterContender and 
MasterDetector definitions.
https://reviews.apache.org/r/44544/: Moved contender and detector definitions 
into separate directories.
https://reviews.apache.org/r/44545/: Instead of keeping standalone and zookeper 
contender/detector class
definitions and implementations in the same file, separated them. Also
made the necessary changes in users of class headers to point to the
new locations.
https://reviews.apache.org/r/44546/: Moved functions in promises to a common 
header file.
https://reviews.apache.org/r/44547/: Added functions in promises to the collect 
header.
https://reviews.apache.org/r/44289/: Added support for contender and detector 
modules.
https://reviews.apache.org/r/44669/: Added createFromModule methods to 
MasterContender and MasterDetector.
https://reviews.apache.org/r/44670/: Added master_detector and master_contender 
flags.

> MasterContender/MasterDetector should be loadable as modules
> 
>
> Key: MESOS-4610
> URL: https://issues.apache.org/jira/browse/MESOS-4610
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Mark Cavage
>Assignee: Mark Cavage
>  Labels: mesosphere
>
> Currently mesos depends on Zookeeper for leader election and notification to 
> slaves, although there is a C++ hierarchy in the code to support alternatives 
> (e.g., unit tests use an in-memory implementation). From an operational 
> perspective, many organizations/users do not want to take a dependency on 
> Zookeeper, and use an alternative solution to implementing leader election. 
> Our organization in particular, very much wants this, and as a reference 
> there have been several requests from the community (see referenced tickets) 
> to replace with etcd/consul/etc.
> This ticket will serve as the work effort to modularize the 
> MasterContender/MasterDetector APIs such that integrators can build a 
> pluggable solution of their choice; this ticket will not fold in any 
> implementations such as etcd et al., but simply move this hierarchy to be 
> fully pluggable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4587) Docker environment variables must be able to contain the equal sign

[Jie Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220102#comment-15220102
 ] 

Jie Yu commented on MESOS-4587:
---

[~gianlus] Yes, you're right. I removed the faulty fix version.
{noformat}
$ git tag --contains 889d7e1731173fd717d581df675177707060beea
0.28.0
0.28.0-rc1
0.28.0-rc2
{noformat}

> Docker environment variables must be able to contain the equal sign
> ---
>
> Key: MESOS-4587
> URL: https://issues.apache.org/jira/browse/MESOS-4587
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.25.0, 0.26.0, 0.27.0
>Reporter: Martin Tapp
>Assignee: Shuai Lin
>  Labels: containerizer
> Fix For: 0.28.0
>
>
> Note: Affects 0.26 and 0.27.
> The Jupyter Docker all-spark-notebook uses equal sign ('=') in Docker ENV 
> declarations (for instance, 
> https://github.com/jupyter/docker-stacks/blob/master/all-spark-notebook/Dockerfile#L51).
> This causes a mesos Unexpected Env format for 'ContainerConfig.Env' error.
> The problem is the tokenization code at 
> https://github.com/apache/mesos/blob/21e080c5ae6ef03556c7a2b588e034a916c7a05a/src/docker/docker.cpp#L386
>  which needs to only look at the first equal sign. Docker ENV declarations 
> can also be empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4587) Docker environment variables must be able to contain the equal sign

[Gianluca (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220091#comment-15220091
 ] 

Gianluca commented on MESOS-4587:
-

It is not fixed in 0.27.2

> Docker environment variables must be able to contain the equal sign
> ---
>
> Key: MESOS-4587
> URL: https://issues.apache.org/jira/browse/MESOS-4587
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.25.0, 0.26.0, 0.27.0
>Reporter: Martin Tapp
>Assignee: Shuai Lin
>  Labels: containerizer
> Fix For: 0.27.1, 0.28.0
>
>
> Note: Affects 0.26 and 0.27.
> The Jupyter Docker all-spark-notebook uses equal sign ('=') in Docker ENV 
> declarations (for instance, 
> https://github.com/jupyter/docker-stacks/blob/master/all-spark-notebook/Dockerfile#L51).
> This causes a mesos Unexpected Env format for 'ContainerConfig.Env' error.
> The problem is the tokenization code at 
> https://github.com/apache/mesos/blob/21e080c5ae6ef03556c7a2b588e034a916c7a05a/src/docker/docker.cpp#L386
>  which needs to only look at the first equal sign. Docker ENV declarations 
> can also be empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4587) Docker environment variables must be able to contain the equal sign

[Jie Yu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jie Yu updated MESOS-4587:
--
Fix Version/s: (was: 0.27.1)

> Docker environment variables must be able to contain the equal sign
> ---
>
> Key: MESOS-4587
> URL: https://issues.apache.org/jira/browse/MESOS-4587
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.25.0, 0.26.0, 0.27.0
>Reporter: Martin Tapp
>Assignee: Shuai Lin
>  Labels: containerizer
> Fix For: 0.28.0
>
>
> Note: Affects 0.26 and 0.27.
> The Jupyter Docker all-spark-notebook uses equal sign ('=') in Docker ENV 
> declarations (for instance, 
> https://github.com/jupyter/docker-stacks/blob/master/all-spark-notebook/Dockerfile#L51).
> This causes a mesos Unexpected Env format for 'ContainerConfig.Env' error.
> The problem is the tokenization code at 
> https://github.com/apache/mesos/blob/21e080c5ae6ef03556c7a2b588e034a916c7a05a/src/docker/docker.cpp#L386
>  which needs to only look at the first equal sign. Docker ENV declarations 
> can also be empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5066) Create an iptables interface in Mesos

[Avinash Sridharan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avinash Sridharan updated MESOS-5066:
-
Sprint: Mesosphere Sprint 32

> Create an iptables interface in Mesos
> -
>
> Key: MESOS-5066
> URL: https://issues.apache.org/jira/browse/MESOS-5066
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
>
> For support port mapping functionality in the network CNI isolator we need to 
> enable DNAT rules in iptables. We therefore need to create an iptables 
> interface in Mesos. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MESOS-5072) Add variadic constructor for Option

[Abhishek Dasgupta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Abhishek Dasgupta reassigned MESOS-5072:


Assignee: Abhishek Dasgupta

> Add variadic constructor for Option
> ---
>
> Key: MESOS-5072
> URL: https://issues.apache.org/jira/browse/MESOS-5072
> Project: Mesos
>  Issue Type: Improvement
>  Components: stout
>Reporter: Benjamin Bannier
>Assignee: Abhishek Dasgupta
>
> Currently an {{Option}} can be constructed from an {{U}} if in turn a 
> {{T}} is constructable from an {{U}}, e.g.,
> {code}
> // Construct a std::string from a string literal.
> Option s{"fnord"};
> {code}
> We should extend this to permit this kind of construct from more than one 
> parameter, i.e.,
> {code}
> // Construct a vector of strings from a string initializer list.
> Option v{"Browny", "Whitey", "Blacky"};
> {code}
> Currently users need to duplicate the type which e.g., poses the danger of
> inadvertently type conversions,
> {code}
> Option v{{"Browny", "Whitey", "Blacky"}};
> {code}
> It seems just making the {{U}} in the respective {{Option}} constructor
> variadic would already be enough to support this, but it would be highly
> desirable to remove explicit, redundant types in existing constructions of 
> {{Options}} in the code base.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-4909) Introduce kill policy for tasks.

[Alexander Rukletsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15210609#comment-15210609
 ] 

Alexander Rukletsov edited comment on MESOS-4909 at 3/31/16 3:15 PM:
-

{noformat}
Commit: 7ab6a478b9cef548a2470d18bd281aee5610b62a [7ab6a47]
Author: Alexander Rukletsov ruklet...@gmail.com
Date: 24 Mar 2016 17:30:31 CET
Committer: Alexander Rukletsov al...@apache.org
Commit Date: 24 Mar 2016 18:21:03 CET

Introduced KillPolicy protobuf.

Describes a kill policy for a task. Currently does not express
different policies (e.g. hitting HTTP endpoints), only controls
how long to wait between graceful and forcible task kill.

Review: https://reviews.apache.org/r/44656/
{noformat}
{noformat}
Commit: 1fe6221aa30f35f31378433412d8cb725009bd47 [1fe6221]
Author: Alexander Rukletsov ruklet...@gmail.com
Date: 24 Mar 2016 17:30:42 CET
Committer: Alexander Rukletsov al...@apache.org
Commit Date: 24 Mar 2016 18:21:03 CET

Added validation for task's kill policy.

Review: https://reviews.apache.org/r/44707/
{noformat}
{noformat}
Commit: d13de4c42b39037c8bd8f79122e7a9ac0d82317f [d13de4c]
Author: Alexander Rukletsov ruklet...@gmail.com
Date: 24 Mar 2016 17:30:52 CET
Committer: Alexander Rukletsov al...@apache.org
Commit Date: 24 Mar 2016 18:21:03 CET

Used KillPolicy and shutdown grace period in command executor.

The command executor determines how much time it allots the
underlying task to clean up (effectively how long to wait for
the task to comply to SIGTERM before sending SIGKILL) based
on both optional task's KillPolicy and optional
shutdown_grace_period field in ExecutorInfo.

Manual testing was performed to ensure newly introduced protobuf
fields are respected. To do that, "mesos-execute" was modified to
support KillPolicy and CommandInfo.shell=false. To simulate a
task that does not exit in the allotted period, a tiny app
(https://github.com/rukletsov/unresponsive-process) that ignores
SIGTERM was used. More details on testing in the review request.

Review: https://reviews.apache.org/r/44657/
{noformat}
{noformat}
Commit: 327f840a32a0c8e2cb05d313b5c5f4d43a206c85 [327f840]
Author: Alexander Rukletsov al...@apache.org
Date: 31 Mar 2016 13:27:20 CEST

Used KillPolicy and shutdown grace period in docker executor.

The docker executor determines how much time it allots the
underlying container to clean up (via passing the timeout to
the docker daemon) based on both optional task's KillPolicy
and optional shutdown_grace_period field in ExecutorInfo.

Review: https://reviews.apache.org/r/44660
{noformat}


was (Author: alexr):
{noformat}
Commit: 7ab6a478b9cef548a2470d18bd281aee5610b62a [7ab6a47]
Author: Alexander Rukletsov ruklet...@gmail.com
Date: 24 Mar 2016 17:30:31 CET
Committer: Alexander Rukletsov al...@apache.org
Commit Date: 24 Mar 2016 18:21:03 CET

Introduced KillPolicy protobuf.

Describes a kill policy for a task. Currently does not express
different policies (e.g. hitting HTTP endpoints), only controls
how long to wait between graceful and forcible task kill.

Review: https://reviews.apache.org/r/44656/
{noformat}
{noformat}
Commit: 1fe6221aa30f35f31378433412d8cb725009bd47 [1fe6221]
Author: Alexander Rukletsov ruklet...@gmail.com
Date: 24 Mar 2016 17:30:42 CET
Committer: Alexander Rukletsov al...@apache.org
Commit Date: 24 Mar 2016 18:21:03 CET

Added validation for task's kill policy.

Review: https://reviews.apache.org/r/44707/
{noformat}
{noformat}
Commit: d13de4c42b39037c8bd8f79122e7a9ac0d82317f [d13de4c]
Author: Alexander Rukletsov ruklet...@gmail.com
Date: 24 Mar 2016 17:30:52 CET
Committer: Alexander Rukletsov al...@apache.org
Commit Date: 24 Mar 2016 18:21:03 CET

Used KillPolicy and shutdown grace period in command executor.

The command executor determines how much time it allots the
underlying task to clean up (effectively how long to wait for
the task to comply to SIGTERM before sending SIGKILL) based
on both optional task's KillPolicy and optional
shutdown_grace_period field in ExecutorInfo.

Manual testing was performed to ensure newly introduced protobuf
fields are respected. To do that, "mesos-execute" was modified to
support KillPolicy and CommandInfo.shell=false. To simulate a
task that does not exit in the allotted period, a tiny app
(https://github.com/rukletsov/unresponsive-process) that ignores
SIGTERM was used. More details on testing in the review request.

Review: https://reviews.apache.org/r/44657/
{noformat}

> Introduce kill policy for tasks.
> 
>
> Key: MESOS-4909
> URL: https://issues.apache.org/jira/browse/MESOS-4909
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Alexander Rukletsov
>Assignee: Alexander Rukletsov
>  Labels: mesosphere
>
> A task may require some time to clean up or even a special mechanism to issue 
> a kill 

[jira] [Updated] (MESOS-4910) Deprecate the --docker_stop_timeout agent flag.

[Alexander Rukletsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-4910:
---
Fix Version/s: 0.29.0

> Deprecate the --docker_stop_timeout agent flag.
> ---
>
> Key: MESOS-4910
> URL: https://issues.apache.org/jira/browse/MESOS-4910
> Project: Mesos
>  Issue Type: Improvement
>  Components: docker
>Reporter: Alexander Rukletsov
>Assignee: Alexander Rukletsov
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> Instead, a combination of {{executor_shutdown_grace_period}}
> agent flag and optionally task kill policies should be used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4112) Clean up libprocess gtest macros

[Yong Tang (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219959#comment-15219959
 ] 

Yong Tang commented on MESOS-4112:
--

Hi, [~mcypark], any update to the review request:
https://reviews.apache.org/r/45356/
https://reviews.apache.org/r/45357/
Comments or feedback would be highly appreciated.

> Clean up libprocess gtest macros
> 
>
> Key: MESOS-4112
> URL: https://issues.apache.org/jira/browse/MESOS-4112
> Project: Mesos
>  Issue Type: Task
>  Components: libprocess, test
>Reporter: Michael Park
>Assignee: Yong Tang
>
> This ticket is regarding the libprocess gtest helpers in 
> {{3rdparty/libprocess/include/process/gtest.hpp}}.
> The pattern in this file seems to be a set of macros:
> * {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_ASSERT_}} -- default of 15 seconds
> * {{AWAIT_\_FOR}} -- alias for {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_}} -- alias for {{AWAIT_ASSERT_}}
> * {{AWAIT_EXPECT__FOR}}
> * {{AWAIT_EXPECT_}} -- default of 15 seconds
> (1) {{AWAIT_EQ_FOR}} should be added for completeness.
> (2) In {{gtest}}, we've got {{EXPECT_EQ}} as well as the {{bool}}-specific 
> versions: {{EXPECT_TRUE}} and {{EXPECT_FALSE}}.
> We should adopt this pattern in these helpers as well. Keeping the pattern 
> above in mind, the following are missing:
> * {{AWAIT_ASSERT_TRUE_FOR}}
> * {{AWAIT_ASSERT_TRUE}}
> * {{AWAIT_ASSERT_FALSE_FOR}}
> * {{AWAIT_ASSERT_FALSE}}
> * {{AWAIT_EXPECT_TRUE_FOR}}
> * {{AWAIT_EXPECT_FALSE_FOR}}
> (3) There are HTTP response related macros at the bottom of the file, e.g. 
> {{AWAIT_EXPECT_RESPONSE_STATUS_EQ}}, however these are missing their 
> {{ASSERT}} counterparts.
> (4) The reason for (3) presumably is because we reach for {{EXPECT}} over 
> {{ASSERT}} in general due to the test suite crashing behavior of {{ASSERT}}. 
> If this is the case, it would be worthwhile considering whether macros such 
> as {{AWAIT_READY}} should alias {{AWAIT_EXPECT_READY}} rather than 
> {{AWAIT_ASSERT_READY}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5073) Mesos allocator leaks role sorter and quota role sorters

[Benjamin Bannier (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bannier updated MESOS-5073:

Description: 
The Mesos allocator {{internal::HierarchicalAllocatorProcess}} owns two raw 
pointer members {{roleSorter}} and {{quotaRoleSorter}}, but fails to properly 
manage their lifetime; they are e.g., not cleaned up in the allocator process 
destructor.

Since currently we do not recreate an existing allocator in production code 
they seem to be unaffected by these leaks; they do affect tests though where we 
create allocators multiple times.

  was:The Mesos allocator {{internal::HierarchicalAllocatorProcess}} owns two 
raw pointer members {{roleSorter}} and {{quotaRoleSorter}}, but fails to 
properly manage their lifetime; they are e.g., not cleaned up in the allocator 
process destructor.


> Mesos allocator leaks role sorter and quota role sorters
> 
>
> Key: MESOS-5073
> URL: https://issues.apache.org/jira/browse/MESOS-5073
> Project: Mesos
>  Issue Type: Improvement
>  Components: allocation
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>  Labels: tech-debt
>
> The Mesos allocator {{internal::HierarchicalAllocatorProcess}} owns two raw 
> pointer members {{roleSorter}} and {{quotaRoleSorter}}, but fails to properly 
> manage their lifetime; they are e.g., not cleaned up in the allocator process 
> destructor.
> Since currently we do not recreate an existing allocator in production code 
> they seem to be unaffected by these leaks; they do affect tests though where 
> we create allocators multiple times.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5073) Mesos allocator leaks role sorter and quota role sorters

[Benjamin Bannier (JIRA)]

Benjamin Bannier created MESOS-5073:
---

 Summary: Mesos allocator leaks role sorter and quota role sorters
 Key: MESOS-5073
 URL: https://issues.apache.org/jira/browse/MESOS-5073
 Project: Mesos
  Issue Type: Improvement
Reporter: Benjamin Bannier


The Mesos allocator {{internal::HierarchicalAllocatorProcess}} owns two raw 
pointer members {{roleSorter}} and {{quotaRoleSorter}}, but fails to properly 
manage their lifetime; they are e.g., not cleaned up in the allocator process 
destructor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MESOS-5073) Mesos allocator leaks role sorter and quota role sorters

[Benjamin Bannier (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bannier reassigned MESOS-5073:
---

Assignee: Benjamin Bannier

> Mesos allocator leaks role sorter and quota role sorters
> 
>
> Key: MESOS-5073
> URL: https://issues.apache.org/jira/browse/MESOS-5073
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>  Labels: tech-debt
>
> The Mesos allocator {{internal::HierarchicalAllocatorProcess}} owns two raw 
> pointer members {{roleSorter}} and {{quotaRoleSorter}}, but fails to properly 
> manage their lifetime; they are e.g., not cleaned up in the allocator process 
> destructor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4719) Add allocator metric for number of offers each framework received

[Benjamin Bannier (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bannier updated MESOS-4719:

Sprint: Mesosphere Sprint 29, Mesosphere Sprint 30, Mesosphere Sprint 31  
(was: Mesosphere Sprint 29, Mesosphere Sprint 30, Mesosphere Sprint 31, 
Mesosphere Sprint 32)

> Add allocator metric for number of offers each framework received
> -
>
> Key: MESOS-4719
> URL: https://issues.apache.org/jira/browse/MESOS-4719
> Project: Mesos
>  Issue Type: Improvement
>  Components: allocation
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> A counter for the number of allocations to a framework can be used to monitor 
> allocation progress, e.g., when agents are added to a cluster, and as other 
> frameworks are added or removed.
> Currently, an offer by the hierarchical allocator to a framework consists of 
> a list of resources on possibly many agents. Resources might be offered in 
> order to satisfy outstanding quota or for fairness. To capture allocations on 
> fine granularity we should not count the number of offers, but instead the 
> pieces making up that offer, as such a metric would better resolve the effect 
> of changes (e.g., adding/removing a framework).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4718) Add allocator metric for number of completed allocation runs

[Benjamin Bannier (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bannier updated MESOS-4718:

Sprint: Mesosphere Sprint 29, Mesosphere Sprint 30, Mesosphere Sprint 31  
(was: Mesosphere Sprint 29, Mesosphere Sprint 30, Mesosphere Sprint 31, 
Mesosphere Sprint 32)

> Add allocator metric for number of completed allocation runs
> 
>
> Key: MESOS-4718
> URL: https://issues.apache.org/jira/browse/MESOS-4718
> Project: Mesos
>  Issue Type: Improvement
>  Components: allocation
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5072) Add variadic constructor for Option

[Benjamin Bannier (JIRA)]

Benjamin Bannier created MESOS-5072:
---

 Summary: Add variadic constructor for Option
 Key: MESOS-5072
 URL: https://issues.apache.org/jira/browse/MESOS-5072
 Project: Mesos
  Issue Type: Improvement
  Components: stout
Reporter: Benjamin Bannier


Currently an {{Option}} can be constructed from an {{U}} if in turn a {{T}} 
is constructable from an {{U}}, e.g.,
{code}
// Construct a std::string from a string literal.
Option s{"fnord"};
{code}

We should extend this to permit this kind of construct from more than one 
parameter, i.e.,
{code}
// Construct a vector of strings from a string initializer list.
Option v{"Browny", "Whitey", "Blacky"};
{code}

Currently users need to duplicate the type which e.g., poses the danger of
inadvertently type conversions,
{code}
Option v{{"Browny", "Whitey", "Blacky"}};
{code}

It seems just making the {{U}} in the respective {{Option}} constructor
variadic would already be enough to support this, but it would be highly
desirable to remove explicit, redundant types in existing constructions of 
{{Options}} in the code base.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5070) Introduce more flexible subprocess interface for child options.

[Joerg Schad (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joerg Schad updated MESOS-5070:
---
Sprint: Mesosphere Sprint 32

> Introduce more flexible subprocess interface for child options.
> ---
>
> Key: MESOS-5070
> URL: https://issues.apache.org/jira/browse/MESOS-5070
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> We introduced a number of parameters to the subprocess interface with 
> MESOS-5049.
> Adding all options explicitly to the subprocess interface makes it 
> inflexible. 
> We should investigate a flexible options, which still prevents arbitrary code 
> to be executed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5071) Refactor the clone option to subprocess.

[Joerg Schad (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joerg Schad updated MESOS-5071:
---
Sprint: Mesosphere Sprint 32

> Refactor the clone option to subprocess.
> 
>
> Key: MESOS-5071
> URL: https://issues.apache.org/jira/browse/MESOS-5071
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> The clone option in subprocess is only used (at least in the Mesos codebase) 
> to specify custom namespace flags to clone. It feels having the clone 
> function in the subprocess interface is too explicit for this functionality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5071) Refactor the clone option to subprocess.

[Joerg Schad (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219708#comment-15219708
 ] 

Joerg Schad commented on MESOS-5071:


We propose to replace the clone option by a namespaces options and allow 
subprocess to choose the right clone behavior internally. This would result in 
the following subprocess interface.

{code}
Try subprocess(
  const std::string& path,
  std::vector argv,
  const Subprocess::IO& in,
  const Subprocess::IO& out,
  const Subprocess::IO& err,
  const Option& flags,
  const Option>& environment,
  const std::vector& parent_hooks,
  const std::vector& child_hooks,
  const Watchdog watchdog,
  const Option& namespaces);
{code}


> Refactor the clone option to subprocess.
> 
>
> Key: MESOS-5071
> URL: https://issues.apache.org/jira/browse/MESOS-5071
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> The clone option in subprocess is only used (at least in the Mesos codebase) 
> to specify custom namespace flags to clone. It feels having the clone 
> function in the subprocess interface is too explicit for this functionality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5071) Refactor the clone option to subprocess.

[Joerg Schad (JIRA)]

Joerg Schad created MESOS-5071:
--

 Summary: Refactor the clone option to subprocess.
 Key: MESOS-5071
 URL: https://issues.apache.org/jira/browse/MESOS-5071
 Project: Mesos
  Issue Type: Improvement
Reporter: Joerg Schad
Assignee: Joerg Schad


The clone option in subprocess is only used (at least in the Mesos codebase) to 
specify custom namespace flags to clone. It feels having the clone function in 
the subprocess interface is too explicit for this functionality.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5070) Introduce more flexible subprocess interface for child options.

[Joerg Schad (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219695#comment-15219695
 ] 

Joerg Schad commented on MESOS-5070:


We propose the subprocess interface to change as shown below, which means to 
add a vector of so called ChildHooks and remove the setsid can chdir options.

{code}
Try subprocess(
const std::string& path,
std::vector argv,
const Subprocess::IO& in,
const Subprocess::IO& out,
const Subprocess::IO& err,
const Option& flags,
const Option>& environment,
const std::vector& parent_hooks,
const std::vector& child_hooks,
const Watchdog watchdog)
{code}

A ChildHook represents a predefined functions to be executed in the child 
process before exec.
In order to prevent arbitrary code, a ChildHook needs to be constructed via 
explicit factory methods.


> Introduce more flexible subprocess interface for child options.
> ---
>
> Key: MESOS-5070
> URL: https://issues.apache.org/jira/browse/MESOS-5070
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> We introduced a number of parameters to the subprocess interface with 
> MESOS-5049.
> Adding all options explicitly to the subprocess interface makes it 
> inflexible. 
> We should investigate a flexible options, which still prevents arbitrary code 
> to be executed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5070) Introduce more flexible subprocess interface for child options.

[Joerg Schad (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joerg Schad updated MESOS-5070:
---
Description: 
We introduced a number of parameters to the subprocess interface with 
MESOS-5049.
Adding all options explicitly to the subprocess interface makes it inflexible. 
We should investigate a flexible options, which still prevents arbitrary code 
to be executed.

  was:
We introduced a number of parameters to the subprocess interface with 
MESOS-5049.
Adding all options explicitly to the subprocess interface makes it inflexible. 
We should look for


> Introduce more flexible subprocess interface for child options.
> ---
>
> Key: MESOS-5070
> URL: https://issues.apache.org/jira/browse/MESOS-5070
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> We introduced a number of parameters to the subprocess interface with 
> MESOS-5049.
> Adding all options explicitly to the subprocess interface makes it 
> inflexible. 
> We should investigate a flexible options, which still prevents arbitrary code 
> to be executed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5070) Introduce more flexible subprocess interface for child options.

[Joerg Schad (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joerg Schad updated MESOS-5070:
---
Description: 
We introduced a number of parameters to the subprocess interface with 
MESOS-5049.
Adding all options explicitly to the subprocess interface makes it inflexible. 
We should look for

  was:We introduced a number 


> Introduce more flexible subprocess interface for child options.
> ---
>
> Key: MESOS-5070
> URL: https://issues.apache.org/jira/browse/MESOS-5070
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>
> We introduced a number of parameters to the subprocess interface with 
> MESOS-5049.
> Adding all options explicitly to the subprocess interface makes it 
> inflexible. 
> We should look for



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MESOS-5070) Introduce more flexible subprocess interface for child options.

[Joerg Schad (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joerg Schad reassigned MESOS-5070:
--

Assignee: Joerg Schad

> Introduce more flexible subprocess interface for child options.
> ---
>
> Key: MESOS-5070
> URL: https://issues.apache.org/jira/browse/MESOS-5070
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> We introduced a number of parameters to the subprocess interface with 
> MESOS-5049.
> Adding all options explicitly to the subprocess interface makes it 
> inflexible. 
> We should look for



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5070) Introduce more flexible subprocess interface for child options.

[Joerg Schad (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joerg Schad updated MESOS-5070:
---
Description: We introduced a number 

> Introduce more flexible subprocess interface for child options.
> ---
>
> Key: MESOS-5070
> URL: https://issues.apache.org/jira/browse/MESOS-5070
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>
> We introduced a number 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5070) Introduce more flexible subprocess interface for child options.

[Joerg Schad (JIRA)]

Joerg Schad created MESOS-5070:
--

 Summary: Introduce more flexible subprocess interface for child 
options.
 Key: MESOS-5070
 URL: https://issues.apache.org/jira/browse/MESOS-5070
 Project: Mesos
  Issue Type: Improvement
Reporter: Joerg Schad






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5069) Upgrade http-parser to v2.6.2

[Chen Zhiwei (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chen Zhiwei updated MESOS-5069:
---
Shepherd: Vinod Kone

> Upgrade http-parser to v2.6.2
> -
>
> Key: MESOS-5069
> URL: https://issues.apache.org/jira/browse/MESOS-5069
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Chen Zhiwei
>Assignee: Chen Zhiwei
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5069) Upgrade http-parser to v2.6.2

[Chen Zhiwei (JIRA)]

Chen Zhiwei created MESOS-5069:
--

 Summary: Upgrade http-parser to v2.6.2
 Key: MESOS-5069
 URL: https://issues.apache.org/jira/browse/MESOS-5069
 Project: Mesos
  Issue Type: Improvement
Reporter: Chen Zhiwei
Assignee: Chen Zhiwei






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1104) Move linux/fs.hpp out of `mesos` namespace in linux/fs.h

[Deshi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219557#comment-15219557
 ] 

Deshi Xiao commented on MESOS-1104:
---

have no linux to testing on it. please hold on on patched code udpate.

> Move linux/fs.hpp out of `mesos` namespace in linux/fs.h
> 
>
> Key: MESOS-1104
> URL: https://issues.apache.org/jira/browse/MESOS-1104
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Archana kumari
>  Labels: mesosphere, newbie
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-1104) Move linux/fs.hpp out of `mesos` namespace in linux/fs.h

[Deshi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219557#comment-15219557
 ] 

Deshi Xiao edited comment on MESOS-1104 at 3/31/16 8:08 AM:


have no linux box to testing on it. please hold on on patched code update.


was (Author: xds2000):
have no linux to testing on it. please hold on on patched code update.

> Move linux/fs.hpp out of `mesos` namespace in linux/fs.h
> 
>
> Key: MESOS-1104
> URL: https://issues.apache.org/jira/browse/MESOS-1104
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Archana kumari
>  Labels: mesosphere, newbie
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-1104) Move linux/fs.hpp out of `mesos` namespace in linux/fs.h

[Deshi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219557#comment-15219557
 ] 

Deshi Xiao edited comment on MESOS-1104 at 3/31/16 8:08 AM:


have no linux to testing on it. please hold on on patched code update.


was (Author: xds2000):
have no linux to testing on it. please hold on on patched code udpate.

> Move linux/fs.hpp out of `mesos` namespace in linux/fs.h
> 
>
> Key: MESOS-1104
> URL: https://issues.apache.org/jira/browse/MESOS-1104
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Archana kumari
>  Labels: mesosphere, newbie
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3421) Support sharing of resources across task instances

[Anindya Sinha (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219555#comment-15219555
 ] 

Anindya Sinha commented on MESOS-3421:
--

The design document has been updated as noted in MESOS-4390 based on the 
feedback received, and further discussions. Here is the link:

https://docs.google.com/document/d/18O4SH3H4BQriW6CTrg3TlQTiVC-rBRsMePhz99Y_bss/edit?usp=sharing

> Support sharing of resources across task instances
> --
>
> Key: MESOS-3421
> URL: https://issues.apache.org/jira/browse/MESOS-3421
> Project: Mesos
>  Issue Type: Epic
>  Components: isolation, volumes
>Affects Versions: 0.23.0
>Reporter: Anindya Sinha
>Assignee: Anindya Sinha
>  Labels: external-volumes, persistent-volumes
>
> A service that needs persistent volume needs to have access to the same 
> persistent volume (RW) from multiple task(s) instances on the same agent 
> node. Currently, a persistent volume once offered to the framework(s) can be 
> scheduled to a task and until that tasks terminates, that persistent volume 
> cannot be used by another task.
> Explore providing the capability of sharing persistent volumes across task 
> instances scheduled on a single agent node.
> Based on discussion within the community, we would allow sharing of resources 
> in general, and add support to enable shareability for persistent volumes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4390) Shared Volumes Design Doc

[Anindya Sinha (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219552#comment-15219552
 ] 

Anindya Sinha commented on MESOS-4390:
--

The design document has been updated based on feedback and discussion with a 
few folks in the community:

https://docs.google.com/document/d/18O4SH3H4BQriW6CTrg3TlQTiVC-rBRsMePhz99Y_bss/edit?usp=sharing


> Shared Volumes Design Doc
> -
>
> Key: MESOS-4390
> URL: https://issues.apache.org/jira/browse/MESOS-4390
> Project: Mesos
>  Issue Type: Task
>Reporter: Adam B
>Assignee: Anindya Sinha
>  Labels: mesosphere
>
> Review & Approve design doc



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)