[jira] [Comment Edited] (MESOS-7813) when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, devices,blkio,memory,cpuacct is changed. why?

[y123456yz (JIRA)]

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

y123456yz edited comment on MESOS-7813 at 7/20/17 5:07 AM:
---

[~jvanremoortere]
where the flowing config should be add to?
delegate=true

 cat /usr/lib/systemd/system/mesos-slave.service
[Unit]
Description=Mesos Slave
After=network.target
Wants=network.target
[Service]
delegate=true // add here??


only add "delegate=true" to mesos-slave.service's [Service]? 


whether need to add "KillMode=control-group" to  mesos-slave.service's 
[Service]? 

thanks again!



was (Author: y123456yz):
[~jvanremoortere]
where the flowing config should be add to?
delegate=true

 cat /usr/lib/systemd/system/mesos-slave.service
[Unit]
Description=Mesos Slave
After=network.target
Wants=network.target
[Service]
delegate=true   // add here??


only add "delegate=true" to mesos-slave.service's [Service]? 


whether need to add "KillMode=control-group" to  mesos-slave.service's 
[Service]? 

thanks again!


> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?
> --
>
> Key: MESOS-7813
> URL: https://issues.apache.org/jira/browse/MESOS-7813
> Project: Mesos
>  Issue Type: Bug
>  Components: agent, cgroups, executor, framework
> Environment: 1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 
> GNU/Linux
>Reporter: y123456yz
>
> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7813) when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, devices,blkio,memory,cpuacct is changed. why?

[y123456yz (JIRA)]

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

y123456yz commented on MESOS-7813:
--

[~jvanremoortere]
where the flowing config should be add to?
delegate=true

 cat /usr/lib/systemd/system/mesos-slave.service
[Unit]
Description=Mesos Slave
After=network.target
Wants=network.target
[Service]
delegate=true   // add here??


only add "delegate=true" to mesos-slave.service's [Service]? 


whether need to add "KillMode=control-group" to  mesos-slave.service's 
[Service]? 

thanks again!


> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?
> --
>
> Key: MESOS-7813
> URL: https://issues.apache.org/jira/browse/MESOS-7813
> Project: Mesos
>  Issue Type: Bug
>  Components: agent, cgroups, executor, framework
> Environment: 1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 
> GNU/Linux
>Reporter: y123456yz
>
> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7812) Request to add artifacts ( binary ) creation steps to the mesos-ppc64le jenkins job

[Amitkumar Ghatwal (JIRA)]

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

Amitkumar Ghatwal commented on MESOS-7812:
--

[~vinodkone]- Acknowledged and thanks  [~gstein] for moving this to MESOS 
project. Will await for any comments on the above request from Mesos project 
team . 

> Request to add artifacts ( binary ) creation steps to the mesos-ppc64le 
> jenkins job
> ---
>
> Key: MESOS-7812
> URL: https://issues.apache.org/jira/browse/MESOS-7812
> Project: Mesos
>  Issue Type: Wish
> Environment: OS - Ubuntu
> Platform - ppc64le
>Reporter: Amitkumar Ghatwal
>
> Hi All,
> In reference to the job re-enabled for ppc64le via this JIRA ticket  - 
> https://issues.apache.org/jira/browse/INFRA-14367 again . Wanted to know if 
> its possible to add steps to this jenkins job so that we can get artifacts 
> such as binary/installers ( *.deb) for mesos on ubuntu-ppc64le during the job 
> build.
> Job - https://builds.apache.org/job/Mesos-PPC64LE/.
> Binary installer ( *.deb) for mesos on ppc64le will come in handy for one 
> step installation on power.
> Requesting [~vinodkone] , to comment if you have any information to add 
> artifacts creation for this jenkins job. 
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7813) when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, devices,blkio,memory,cpuacct is changed. why?

[Joris Van Remoortere (JIRA)]

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

Joris Van Remoortere commented on MESOS-7813:
-

[~y123456yz]
Check out the delegate flag in systemd.
Here is an explanation of the problem:
https://issues.apache.org/jira/browse/MESOS-3425

> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?
> --
>
> Key: MESOS-7813
> URL: https://issues.apache.org/jira/browse/MESOS-7813
> Project: Mesos
>  Issue Type: Bug
>  Components: agent, cgroups, executor, framework
> Environment: 1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 
> GNU/Linux
>Reporter: y123456yz
>
> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MESOS-7813) when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, devices,blkio,memory,cpuacct is changed. why?

[y123456yz (JIRA)]

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

y123456yz edited comment on MESOS-7813 at 7/20/17 3:36 AM:
---

last time, as following:
[xxx@fd-mesos-xxx~]$ cat /proc/30115/cgroup 
10:perf_event:/lxc/c8cef9e2ff114e429cb845559c4a0dff
9:cpuset:/lxc/c8cef9e2ff114e429cb845559c4a0dff
8:net_cls:/lxc/c8cef9e2ff114e429cb845559c4a0dff
7:devices:/lxc/c8cef9e2ff114e429cb845559c4a0dff
6:hugetlb:/lxc/c8cef9e2ff114e429cb845559c4a0dff
5:blkio:/lxc/c8cef9e2ff114e429cb845559c4a0dff
4:memory:/lxc/c8cef9e2ff114e429cb845559c4a0dff
3:cpuacct,cpu:/lxc/c8cef9e2ff114e429cb845559c4a0dff
2:freezer:/lxc/c8cef9e2ff114e429cb845559c4a0dff
1:name=systemd:/user.slice/user-52321.slice/session-128207.scope


After a period of time， changed as folloing:
[yangyazhou@fd-mesos-slave21 ~]$ cat /proc/30115/cgroup 
10:perf_event:/lxc/c8cef9e2ff114e429cb845559c4a0dff
9:cpuset:/lxc/c8cef9e2ff114e429cb845559c4a0dff
8:net_cls:/lxc/c8cef9e2ff114e429cb845559c4a0dff
7:devices:/user.slice
6:hugetlb:/lxc/c8cef9e2ff114e429cb845559c4a0dff
5:blkio:/user.slice
4:memory:/user.slice
3:cpuacct,cpu:/user.slice
2:freezer:/lxc/c8cef9e2ff114e429cb845559c4a0dff
1:name=systemd:/user.slice/user-52321.slice/session-128207.scope




systemd version:
[xxx~]$ rpm -qa | grep systemd
systemd-sysv-219-30.el7.x86_64
oci-systemd-hook-0.1.4-4.git41491a3.el7.x86_64
systemd-libs-219-30.el7.x86_64
systemd-219-30.el7.x86_64
systemd-devel-219-30.el7.x86_64
systemd-python-219-30.el7.x86_64


was (Author: y123456yz):
last time, as following:
[xxx@fd-mesos-xxx~]$ cat /proc/30115/cgroup 
10:perf_event:/lxc/c8cef9e2ff114e429cb845559c4a0dff
9:cpuset:/lxc/c8cef9e2ff114e429cb845559c4a0dff
8:net_cls:/lxc/c8cef9e2ff114e429cb845559c4a0dff
7:devices:/lxc/c8cef9e2ff114e429cb845559c4a0dff
6:hugetlb:/lxc/c8cef9e2ff114e429cb845559c4a0dff
5:blkio:/lxc/c8cef9e2ff114e429cb845559c4a0dff
4:memory:/lxc/c8cef9e2ff114e429cb845559c4a0dff
3:cpuacct,cpu:/lxc/c8cef9e2ff114e429cb845559c4a0dff
2:freezer:/lxc/c8cef9e2ff114e429cb845559c4a0dff
1:name=systemd:/user.slice/user-52321.slice/session-128207.scope


After a period of time， changed as folloing:
[yangyazhou@fd-mesos-slave21 ~]$ cat /proc/30115/cgroup 
10:perf_event:/lxc/c8cef9e2ff114e429cb845559c4a0dff
9:cpuset:/lxc/c8cef9e2ff114e429cb845559c4a0dff
8:net_cls:/lxc/c8cef9e2ff114e429cb845559c4a0dff
7:devices:/user.slice
6:hugetlb:/lxc/c8cef9e2ff114e429cb845559c4a0dff
5:blkio:/user.slice
4:memory:/user.slice
3:cpuacct,cpu:/user.slice
2:freezer:/lxc/c8cef9e2ff114e429cb845559c4a0dff
1:name=systemd:/user.slice/user-52321.slice/session-128207.scope

> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?
> --
>
> Key: MESOS-7813
> URL: https://issues.apache.org/jira/browse/MESOS-7813
> Project: Mesos
>  Issue Type: Bug
>  Components: agent, cgroups, executor, framework
> Environment: 1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 
> GNU/Linux
>Reporter: y123456yz
>
> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MESOS-7813) when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, devices,blkio,memory,cpuacct is changed. why?

[y123456yz (JIRA)]

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

y123456yz edited comment on MESOS-7813 at 7/20/17 3:07 AM:
---

configure as following:

$ cat /usr/lib/systemd/system/mesos-slave.service
[Unit]
Description=Mesos Slave
After=network.target
Wants=network.target

[Service]
ExecStart=/usr/bin/mesos-init-wrapper slave
KillMode=process
Restart=always
RestartSec=20
LimitNOFILE=16384
CPUAccounting=true
MemoryAccounting=true

[Install]
WantedBy=multi-user.target


was (Author: y123456yz):
$ cat /usr/lib/systemd/system/mesos-slave.service
[Unit]
Description=Mesos Slave
After=network.target
Wants=network.target

[Service]
ExecStart=/usr/bin/mesos-init-wrapper slave
KillMode=process
Restart=always
RestartSec=20
LimitNOFILE=16384
CPUAccounting=true
MemoryAccounting=true

[Install]
WantedBy=multi-user.target

> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?
> --
>
> Key: MESOS-7813
> URL: https://issues.apache.org/jira/browse/MESOS-7813
> Project: Mesos
>  Issue Type: Bug
>  Components: agent, cgroups, executor, framework
> Environment: 1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 
> GNU/Linux
>Reporter: y123456yz
>
> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7813) when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, devices,blkio,memory,cpuacct is changed. why?

[y123456yz (JIRA)]

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

y123456yz commented on MESOS-7813:
--

$ cat /usr/lib/systemd/system/mesos-slave.service
[Unit]
Description=Mesos Slave
After=network.target
Wants=network.target

[Service]
ExecStart=/usr/bin/mesos-init-wrapper slave
KillMode=process
Restart=always
RestartSec=20
LimitNOFILE=16384
CPUAccounting=true
MemoryAccounting=true

[Install]
WantedBy=multi-user.target

> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?
> --
>
> Key: MESOS-7813
> URL: https://issues.apache.org/jira/browse/MESOS-7813
> Project: Mesos
>  Issue Type: Bug
>  Components: agent, cgroups, executor, framework
> Environment: 1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 
> GNU/Linux
>Reporter: y123456yz
>
> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7813) when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, devices,blkio,memory,cpuacct is changed. why?

[y123456yz (JIRA)]

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

y123456yz commented on MESOS-7813:
--

[~haosdent huang]
[~jvanremoortere]
[~jvanremoortere]
[~hartem]

can you help me , what happen for this, what's the reason. 
thans.


some lxc that Manually created by me(not through mesos) also have the problem, 
I don,t know who change this.

thans.

> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?
> --
>
> Key: MESOS-7813
> URL: https://issues.apache.org/jira/browse/MESOS-7813
> Project: Mesos
>  Issue Type: Bug
>  Components: agent, cgroups, executor, framework
> Environment: 1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 
> GNU/Linux
>Reporter: y123456yz
>
> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-4992) sandbox uri does not work outisde mesos http server

[Benjamin Mahler (JIRA)]

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

Benjamin Mahler commented on MESOS-4992:


[~haosdent huang] can you backport this to previous releases?

[~skonto] you can test against the tip of master.

> sandbox uri does not work outisde mesos http server
> ---
>
> Key: MESOS-4992
> URL: https://issues.apache.org/jira/browse/MESOS-4992
> Project: Mesos
>  Issue Type: Bug
>  Components: webui
>Affects Versions: 0.27.1
>Reporter: Stavros Kontopoulos
>Assignee: haosdent
>  Labels: mesosphere
> Fix For: 1.4.0
>
>
> The SandBox uri of a framework does not work if i just copy paste it to the 
> browser.
> For example the following sandbox uri:
> http://172.17.0.1:5050/#/slaves/50f87c73-79ef-4f2a-95f0-b2b4062b2de6-S0/frameworks/50f87c73-79ef-4f2a-95f0-b2b4062b2de6-0009/executors/driver-20160321155016-0001/browse
> should redirect to:
> http://172.17.0.1:5050/#/slaves/50f87c73-79ef-4f2a-95f0-b2b4062b2de6-S0/browse?path=%2Ftmp%2Fmesos%2Fslaves%2F50f87c73-79ef-4f2a-95f0-b2b4062b2de6-S0%2Fframeworks%2F50f87c73-79ef-4f2a-95f0-b2b4062b2de6-0009%2Fexecutors%2Fdriver-20160321155016-0001%2Fruns%2F60533483-31fb-4353-987d-f3393911cc80
> yet it fails with the message:
> "Failed to find slaves.
> Navigate to the slave's sandbox via the Mesos UI."
> and redirects to:
> http://172.17.0.1:5050/#/
> It is an issue for me because im working on expanding the mesos spark ui with 
> sandbox uri, The other option is to get the slave info and parse the json 
> file there and get executor paths not so straightforward or elegant though.
> Moreover i dont see the runs/container_id in the Mesos Proto Api. I guess 
> this is hidden info, this is the needed piece of info to re-write the uri 
> without redirection.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7813) when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, devices,blkio,memory,cpuacct is changed. why?

[y123456yz (JIRA)]

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

y123456yz updated MESOS-7813:
-
Component/s: framework
 executor
 agent

> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?
> --
>
> Key: MESOS-7813
> URL: https://issues.apache.org/jira/browse/MESOS-7813
> Project: Mesos
>  Issue Type: Bug
>  Components: agent, cgroups, executor, framework
>Reporter: y123456yz
>
> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7813) when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, devices,blkio,memory,cpuacct is changed. why?

[y123456yz (JIRA)]

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

y123456yz updated MESOS-7813:
-
Environment: 1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 
GNU/Linux

> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?
> --
>
> Key: MESOS-7813
> URL: https://issues.apache.org/jira/browse/MESOS-7813
> Project: Mesos
>  Issue Type: Bug
>  Components: agent, cgroups, executor, framework
> Environment: 1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 
> GNU/Linux
>Reporter: y123456yz
>
> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7813) when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, devices,blkio,memory,cpuacct is changed. why?

[y123456yz (JIRA)]

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

y123456yz commented on MESOS-7813:
--

last time, as following:
[xxx@fd-mesos-xxx~]$ cat /proc/30115/cgroup 
10:perf_event:/lxc/c8cef9e2ff114e429cb845559c4a0dff
9:cpuset:/lxc/c8cef9e2ff114e429cb845559c4a0dff
8:net_cls:/lxc/c8cef9e2ff114e429cb845559c4a0dff
7:devices:/lxc/c8cef9e2ff114e429cb845559c4a0dff
6:hugetlb:/lxc/c8cef9e2ff114e429cb845559c4a0dff
5:blkio:/lxc/c8cef9e2ff114e429cb845559c4a0dff
4:memory:/lxc/c8cef9e2ff114e429cb845559c4a0dff
3:cpuacct,cpu:/lxc/c8cef9e2ff114e429cb845559c4a0dff
2:freezer:/lxc/c8cef9e2ff114e429cb845559c4a0dff
1:name=systemd:/user.slice/user-52321.slice/session-128207.scope


After a period of time， changed as folloing:
[yangyazhou@fd-mesos-slave21 ~]$ cat /proc/30115/cgroup 
10:perf_event:/lxc/c8cef9e2ff114e429cb845559c4a0dff
9:cpuset:/lxc/c8cef9e2ff114e429cb845559c4a0dff
8:net_cls:/lxc/c8cef9e2ff114e429cb845559c4a0dff
7:devices:/user.slice
6:hugetlb:/lxc/c8cef9e2ff114e429cb845559c4a0dff
5:blkio:/user.slice
4:memory:/user.slice
3:cpuacct,cpu:/user.slice
2:freezer:/lxc/c8cef9e2ff114e429cb845559c4a0dff
1:name=systemd:/user.slice/user-52321.slice/session-128207.scope

> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?
> --
>
> Key: MESOS-7813
> URL: https://issues.apache.org/jira/browse/MESOS-7813
> Project: Mesos
>  Issue Type: Bug
>  Components: cgroups
>Reporter: y123456yz
>
> when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
> devices,blkio,memory,cpuacct is changed. why?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7813) when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, devices,blkio,memory,cpuacct is changed. why?

[y123456yz (JIRA)]

y123456yz created MESOS-7813:


 Summary: when lxc run after a period of time, the 
file(/proc/pid/cgroup) is modified, devices,blkio,memory,cpuacct is changed. 
why?
 Key: MESOS-7813
 URL: https://issues.apache.org/jira/browse/MESOS-7813
 Project: Mesos
  Issue Type: Bug
  Components: cgroups
Reporter: y123456yz


when lxc run after a period of time, the file(/proc/pid/cgroup) is modified, 
devices,blkio,memory,cpuacct is changed. why?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7709) Add --dns flag to the agent.

[Gilbert Song (JIRA)]

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

Gilbert Song updated MESOS-7709:

Sprint: Mesosphere Sprint 58, Mesosphere Sprint 59  (was: Mesosphere Sprint 
58)

> Add --dns flag to the agent.
> 
>
> Key: MESOS-7709
> URL: https://issues.apache.org/jira/browse/MESOS-7709
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Avinash Sridharan
>Assignee: Qian Zhang
>  Labels: mesosphere
>
> Mesos support both CNI (through `network/cni` isolator) and CNM (through 
> docker) specification. Both these specifications allow for DNS entries for 
> containers to be set on a per-container, and per-network basis. 
> Currently, the behavior of the agent is to use the DNS nameservers set in 
> /etc/resolv.conf when the CNI or CNM plugin that is used to attached the 
> container to the CNI/CNM network doesnt' explicitly set the DNS for the 
> container. This is a bit inflexible especially when we have a mix of v4 and 
> v6 networks. 
> The operator should be able to specify DNS nameservers for the networks he 
> installs either the override the ones provided by the plugin or as defaults 
> when the plugins are not going to specify DNS name servers.
> In order to achieve the above goal we need to introduce a `\--dns` flag to 
> the agent. The `\--dns` flag should support a JSON (or a JSON file) with the 
> following schema:
> {code}
> {
>   "mesos": [
> {
>   "network" : ,
>   "nameservers": []
> }
>   ],
>   "docker": [
> {
>   "network" : ,
>   "nameservers": []
> }
>   ]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7794) Mesos failed with error c2102 when build in conformance mode (/permissive-)

[PhoebeHui (JIRA)]

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

PhoebeHui commented on MESOS-7794:
--

Any updates for this?

> Mesos failed with error c2102 when build in conformance mode (/permissive-)
> ---
>
> Key: MESOS-7794
> URL: https://issues.apache.org/jira/browse/MESOS-7794
> Project: Mesos
>  Issue Type: Bug
>Reporter: PhoebeHui
>
> I try to build mesos with Debug|x64 configuration on Windows with VS2017.2
> Here is repro steps:
> 1. git clone -c core.autocrlf=true https://github.com/apache/mesos 
> F:\mesos\src
> 2. Open a VS amd64 command prompt as admin and browse to F:\mesos\src
> 3. Set _CL_=/permissive-
> 4. bootstrap.bat
> 5. mkdir build_x64 && pushd build_x64
> 6. cmake ..\src -G "Visual Studio 15 2017 Win64" -DENABLE_LIBEVENT=1 
> -DHAS_AUTHENTICATION=0 -DPATCHEXE_PATH="C:\gnuwin32\bin -T host=x64"
> 7. msbuild Mesos.sln /p:Configuration=Debug /p:Platform=x64 /m /t:Rebuild
> Error message:
> D:\Mesos\src\3rdparty\stout\include\stout/os/windows/shell.hpp(355): error 
> C2102: '&' requires l-value (compiling source file 
> D:\Mesos\src\3rdparty\libprocess\src\time.cpp) 
> [D:\Mesos\build_x64\3rdparty\libprocess\src\process-0.0.1.vcxproj]
> Smaller repro code like this:
> void test(unsigned long *a){}
> int main()
> {
> int i;
> test(_cast(i));
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Moved] (MESOS-7812) Request to add artifacts ( binary ) creation steps to the mesos-ppc64le jenkins job

[Greg Stein (JIRA)]

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

Greg Stein moved INFRA-14646 to MESOS-7812:
---

INFRA-Members:   (was: [infrastructure-team])
Fix Version/s: (was: May 2017)
  Component/s: (was: Jenkins)
 Workflow: Copy of Mesos workflow  (was: INFRA Workflow)
  Key: MESOS-7812  (was: INFRA-14646)
  Project: Mesos  (was: Infrastructure)

> Request to add artifacts ( binary ) creation steps to the mesos-ppc64le 
> jenkins job
> ---
>
> Key: MESOS-7812
> URL: https://issues.apache.org/jira/browse/MESOS-7812
> Project: Mesos
>  Issue Type: Wish
> Environment: OS - Ubuntu
> Platform - ppc64le
>Reporter: Amitkumar Ghatwal
>
> Hi All,
> In reference to the job re-enabled for ppc64le via this JIRA ticket  - 
> https://issues.apache.org/jira/browse/INFRA-14367 again . Wanted to know if 
> its possible to add steps to this jenkins job so that we can get artifacts 
> such as binary/installers ( *.deb) for mesos on ubuntu-ppc64le during the job 
> build.
> Job - https://builds.apache.org/job/Mesos-PPC64LE/.
> Binary installer ( *.deb) for mesos on ppc64le will come in handy for one 
> step installation on power.
> Requesting [~vinodkone] , to comment if you have any information to add 
> artifacts creation for this jenkins job. 
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7812) Request to add artifacts ( binary ) creation steps to the mesos-ppc64le jenkins job

[Greg Stein (JIRA)]

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

Greg Stein commented on MESOS-7812:
---

Done.

> Request to add artifacts ( binary ) creation steps to the mesos-ppc64le 
> jenkins job
> ---
>
> Key: MESOS-7812
> URL: https://issues.apache.org/jira/browse/MESOS-7812
> Project: Mesos
>  Issue Type: Wish
> Environment: OS - Ubuntu
> Platform - ppc64le
>Reporter: Amitkumar Ghatwal
>
> Hi All,
> In reference to the job re-enabled for ppc64le via this JIRA ticket  - 
> https://issues.apache.org/jira/browse/INFRA-14367 again . Wanted to know if 
> its possible to add steps to this jenkins job so that we can get artifacts 
> such as binary/installers ( *.deb) for mesos on ubuntu-ppc64le during the job 
> build.
> Job - https://builds.apache.org/job/Mesos-PPC64LE/.
> Binary installer ( *.deb) for mesos on ppc64le will come in handy for one 
> step installation on power.
> Requesting [~vinodkone] , to comment if you have any information to add 
> artifacts creation for this jenkins job. 
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7796) LIBPROCESS_IP isn't passed on to the fetcher

[Jie Yu (JIRA)]

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

Jie Yu commented on MESOS-7796:
---

commit f78a5822b838fe9ad361cbeba9611992c2225551
Author: Gastón Kleiman 
Date:   Wed Jul 19 14:13:17 2017 -0700

Set the `LIBPROCESS_IP` env variable before starting the fetcher.

This patch updates the containerizer to manually set the `LIBPROCESS_IP`
environment variable to `127.0.0.1` when launching the fetcher POSIX
process.

This environment variable is needed so that libprocess can be
initialized without depending on an external environment.

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

> LIBPROCESS_IP isn't passed on to the fetcher
> 
>
> Key: MESOS-7796
> URL: https://issues.apache.org/jira/browse/MESOS-7796
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization, fetcher, network
>Affects Versions: 1.2.0, 1.2.1
>Reporter: Gastón Kleiman
>  Labels: mesosphere
>
> {{LIBPROCESS_IP}} is not passed on to the fetcher.
> The fetcher program uses libprocess, which depending on the DNS configuration 
> might fail during initialization:
> {noformat}
> I0710 17:40:36.866606  8157 fetcher.cpp:531] Fetcher Info: 
> {"cache_directory":"\/tmp\/mesos\/fetch\/slaves\/1f5cf498-82db-4976-8ba1-f2be90af3496-S1\/nobody","items":[{"action":"BYPASS_CACHE","uri":{"cache":false,"executable":false,"extract":true,"value":"REDACTED"}},{"action":"BYPASS_CACHE","uri":{"cache":false,"executable":false,"extract":true,"value":"REDACTED"}},{"action":"BYPASS_CACHE","uri":{"cache":false,"executable":false,"extract":true,"value":"REDACTED"}}],"sandbox_directory":"\/var\/lib\/mesos\/slave\/slaves\/1f5cf498-82db-4976-8ba1-f2be90af3496-S1\/frameworks\/1f5cf498-82db-4976-8ba1-f2be90af3496-\/executors\/cassandra.e1e042ef-6596-11e7-adc9-a6ba31bb9f5f\/runs\/5728acc2-33fc-4c39-ba7c-55908cbe5862","user":"nobody"}
> I0710 17:40:36.869302  8157 fetcher.cpp:442] Fetching URI 'REDACTED'
> I0710 17:40:36.869319  8157 fetcher.cpp:283] Fetching directly into the 
> sandbox directory
> I0710 17:40:36.869343  8157 fetcher.cpp:220] Fetching URI 'REDACTED'
> I0710 17:40:36.869359  8157 fetcher.cpp:163] Downloading resource from 
> 'REDACTED' to 
> '/var/lib/mesos/slave/slaves/1f5cf498-82db-4976-8ba1-f2be90af3496-S1/frameworks/1f5cf498-82db-4976-8ba1-f2be90af3496-/executors/cassandra.e1e042ef-6596-11e7-adc9-a6ba31bb9f5f/runs/5728acc2-33fc-4c39-ba7c-55908cbe5862/REDACTED'
> Failed to obtain the IP address for 
> 'ip-10-0-5-78.us-west-2.compute.internal'; the DNS service may not be able to 
> resolve it: Name or service not known
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7796) LIBPROCESS_IP isn't passed on to the fetcher

[JIRA]

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

Gastón Kleiman updated MESOS-7796:
--
Shepherd: Jie Yu

> LIBPROCESS_IP isn't passed on to the fetcher
> 
>
> Key: MESOS-7796
> URL: https://issues.apache.org/jira/browse/MESOS-7796
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization, fetcher, network
>Affects Versions: 1.2.0, 1.2.1
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
>  Labels: mesosphere
>
> {{LIBPROCESS_IP}} is not passed on to the fetcher.
> The fetcher program uses libprocess, which depending on the DNS configuration 
> might fail during initialization:
> {noformat}
> I0710 17:40:36.866606  8157 fetcher.cpp:531] Fetcher Info: 
> {"cache_directory":"\/tmp\/mesos\/fetch\/slaves\/1f5cf498-82db-4976-8ba1-f2be90af3496-S1\/nobody","items":[{"action":"BYPASS_CACHE","uri":{"cache":false,"executable":false,"extract":true,"value":"REDACTED"}},{"action":"BYPASS_CACHE","uri":{"cache":false,"executable":false,"extract":true,"value":"REDACTED"}},{"action":"BYPASS_CACHE","uri":{"cache":false,"executable":false,"extract":true,"value":"REDACTED"}}],"sandbox_directory":"\/var\/lib\/mesos\/slave\/slaves\/1f5cf498-82db-4976-8ba1-f2be90af3496-S1\/frameworks\/1f5cf498-82db-4976-8ba1-f2be90af3496-\/executors\/cassandra.e1e042ef-6596-11e7-adc9-a6ba31bb9f5f\/runs\/5728acc2-33fc-4c39-ba7c-55908cbe5862","user":"nobody"}
> I0710 17:40:36.869302  8157 fetcher.cpp:442] Fetching URI 'REDACTED'
> I0710 17:40:36.869319  8157 fetcher.cpp:283] Fetching directly into the 
> sandbox directory
> I0710 17:40:36.869343  8157 fetcher.cpp:220] Fetching URI 'REDACTED'
> I0710 17:40:36.869359  8157 fetcher.cpp:163] Downloading resource from 
> 'REDACTED' to 
> '/var/lib/mesos/slave/slaves/1f5cf498-82db-4976-8ba1-f2be90af3496-S1/frameworks/1f5cf498-82db-4976-8ba1-f2be90af3496-/executors/cassandra.e1e042ef-6596-11e7-adc9-a6ba31bb9f5f/runs/5728acc2-33fc-4c39-ba7c-55908cbe5862/REDACTED'
> Failed to obtain the IP address for 
> 'ip-10-0-5-78.us-west-2.compute.internal'; the DNS service may not be able to 
> resolve it: Name or service not known
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (MESOS-7796) LIBPROCESS_IP isn't passed on to the fetcher

[JIRA]

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

Gastón Kleiman reassigned MESOS-7796:
-

Assignee: Gastón Kleiman

> LIBPROCESS_IP isn't passed on to the fetcher
> 
>
> Key: MESOS-7796
> URL: https://issues.apache.org/jira/browse/MESOS-7796
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization, fetcher, network
>Affects Versions: 1.2.0, 1.2.1
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
>  Labels: mesosphere
>
> {{LIBPROCESS_IP}} is not passed on to the fetcher.
> The fetcher program uses libprocess, which depending on the DNS configuration 
> might fail during initialization:
> {noformat}
> I0710 17:40:36.866606  8157 fetcher.cpp:531] Fetcher Info: 
> {"cache_directory":"\/tmp\/mesos\/fetch\/slaves\/1f5cf498-82db-4976-8ba1-f2be90af3496-S1\/nobody","items":[{"action":"BYPASS_CACHE","uri":{"cache":false,"executable":false,"extract":true,"value":"REDACTED"}},{"action":"BYPASS_CACHE","uri":{"cache":false,"executable":false,"extract":true,"value":"REDACTED"}},{"action":"BYPASS_CACHE","uri":{"cache":false,"executable":false,"extract":true,"value":"REDACTED"}}],"sandbox_directory":"\/var\/lib\/mesos\/slave\/slaves\/1f5cf498-82db-4976-8ba1-f2be90af3496-S1\/frameworks\/1f5cf498-82db-4976-8ba1-f2be90af3496-\/executors\/cassandra.e1e042ef-6596-11e7-adc9-a6ba31bb9f5f\/runs\/5728acc2-33fc-4c39-ba7c-55908cbe5862","user":"nobody"}
> I0710 17:40:36.869302  8157 fetcher.cpp:442] Fetching URI 'REDACTED'
> I0710 17:40:36.869319  8157 fetcher.cpp:283] Fetching directly into the 
> sandbox directory
> I0710 17:40:36.869343  8157 fetcher.cpp:220] Fetching URI 'REDACTED'
> I0710 17:40:36.869359  8157 fetcher.cpp:163] Downloading resource from 
> 'REDACTED' to 
> '/var/lib/mesos/slave/slaves/1f5cf498-82db-4976-8ba1-f2be90af3496-S1/frameworks/1f5cf498-82db-4976-8ba1-f2be90af3496-/executors/cassandra.e1e042ef-6596-11e7-adc9-a6ba31bb9f5f/runs/5728acc2-33fc-4c39-ba7c-55908cbe5862/REDACTED'
> Failed to obtain the IP address for 
> 'ip-10-0-5-78.us-west-2.compute.internal'; the DNS service may not be able to 
> resolve it: Name or service not known
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7798) Improve libprocess message passing performance

[Benjamin Hindman (JIRA)]

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

Benjamin Hindman commented on MESOS-7798:
-

Benchmark I've been using: {{https://reviews.apache.org/r/60983}}

> Improve libprocess message passing performance
> --
>
> Key: MESOS-7798
> URL: https://issues.apache.org/jira/browse/MESOS-7798
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Benjamin Hindman
>Assignee: Benjamin Hindman
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7798) Improve libprocess message passing performance

[Benjamin Hindman (JIRA)]

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

Benjamin Hindman commented on MESOS-7798:
-

First collection of optimizations here:

{code}
commit 8f42d0c112748e138cc607b945455045fdac4b20
Author: Benjamin Hindman 
Date:   Fri Jul 14 09:16:03 2017 -0700

Added double-checked locking for filter.

When running in"production" a filter will not be (likely) be set yet
with the current code the threads will experience head-of-line
blocking becaues they'll all queue up on the mutex. Test code will
still queue up but we don't care about the performance in these
situations!

Note that this patch also moves the filter into ProcessManager in the
effort towards eliminating globals.

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

commit 102e86946d1f467cf30da7bd3f0fb89440866456
Author: Benjamin Hindman 
Date:   Fri Jul 14 16:40:29 2017 -0700

Changes for libprocess Message optimization.

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

commit 7413a3c43a82287519712f24151126453f0d82f6
Author: Benjamin Hindman 
Date:   Tue Jul 11 17:38:01 2017 -0700

Removed extra/unnecessary allocations of Message.

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

commit c1b6d978d0193ff34c28b83228f85c3e4a348153
Author: Benjamin Hindman 
Date:   Fri Jun 23 00:15:52 2017 -0700

Replaced std::map with hashmap for ProcessBase::handlers.

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

commit 4936a32bcf4bbd0b74778d327d047cb8fe17e4f2
Author: Benjamin Hindman 
Date:   Tue Jul 18 22:26:46 2017 -0700

Added --enable-lock-free-run-queue configuration to Mesos.

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

commit 6076dbc226de80d597a8e21ea392ecf4ef3027c1
Author: Benjamin Hindman 
Date:   Sun Jun 18 13:34:45 2017 -0700

Performance optimizations for message passing.

Optimizations include:

* Factored out run queue and introduced lock free implementation. This
  also required adding the concept of an `epoch` to support proper
  settling and refactoring the increments/decrements of `running` to
  make it easier to reason about.

* Replaced the use of a condition variable (the `Gate`) with a
  semaphore.

Review: https://reviews.apache.org/r/60825
{code}

> Improve libprocess message passing performance
> --
>
> Key: MESOS-7798
> URL: https://issues.apache.org/jira/browse/MESOS-7798
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Benjamin Hindman
>Assignee: Benjamin Hindman
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7492) Introduce a daemon manager in the agent.

[Joseph Wu (JIRA)]

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

Joseph Wu updated MESOS-7492:
-
Shepherd: Jie Yu
  Sprint: Mesosphere Sprint 60
Story Points: 5

> Introduce a daemon manager in the agent.
> 
>
> Key: MESOS-7492
> URL: https://issues.apache.org/jira/browse/MESOS-7492
> Project: Mesos
>  Issue Type: Task
>Reporter: Jie Yu
>Assignee: Joseph Wu
>  Labels: mesosphere, storage
>
> Once we have standalone container support from the containerizer, we should 
> consider adding a daemon manager inside the agent. It'll be like 'monit', 
> 'upstart' or 'systemd', but with very limited functionalities. For instance, 
> as a start, the manager will simply always restart the daemons if the daemon 
> fails. It'll also try to cleanup unknown daemons.
> This feature will be used to manage CSI plugin containers on the agent.
> The daemon manager should have an interface allowing operators to "register" 
> a daemon with a name and a config of the daemon. The daemon manager is 
> responsible for restarting the daemon if it crashes until some one explicitly 
> "unregister" it. Some simple backoff and health check functionality should be 
> provided.
> We probably need a small design doc for this.
> {code}
> message DaemonConfig {
>   optional ContainerInfo container;
>   optional CommandInfo command;
>   optional uint32 poll_interval;
>   optional uint32 initial_delay;
>   optional CheckInfo check; // For health check.
> }
> class DaemonManager
> {
> public:
>   Future register(
> const ContainerID& containerId,
> const DaemonConfig& config;
>   Future unregister(const ContainerID& containerId);
>   Future ps();
>   Future status(const ContainerID& containerId);
> };
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7810) gRPC support in libprocess

[Chun-Hung Hsiao (JIRA)]

Chun-Hung Hsiao created MESOS-7810:
--

 Summary: gRPC support in libprocess
 Key: MESOS-7810
 URL: https://issues.apache.org/jira/browse/MESOS-7810
 Project: Mesos
  Issue Type: Improvement
Reporter: Chun-Hung Hsiao
Assignee: Chun-Hung Hsiao


We would like to introduce a grpc wrapper in libprocess. The wrapper provides a 
clean interface for gRPC asynchronous calls and returns a {{Future}}, so others 
can easily use actor-based programming with libprocess to support grpc 
communications.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7809) Building gRPC with Autotools

[Chun-Hung Hsiao (JIRA)]

Chun-Hung Hsiao created MESOS-7809:
--

 Summary: Building gRPC with Autotools
 Key: MESOS-7809
 URL: https://issues.apache.org/jira/browse/MESOS-7809
 Project: Mesos
  Issue Type: Improvement
Reporter: Chun-Hung Hsiao
Assignee: Chun-Hung Hsiao


grpc does not come with an autotools script and have a hand-written makefile 
which assumes certain libraries pre-installed in the system. We need to write 
proper rules that override the default path options in grpc's Makefile in our 
autotools configurations to support grpc in autotools.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-6390) Ensure Python support scripts are linted

[Armand Grillet (JIRA)]

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

Armand Grillet updated MESOS-6390:
--
Sprint: Mesosphere Sprint 59

> Ensure Python support scripts are linted
> 
>
> Key: MESOS-6390
> URL: https://issues.apache.org/jira/browse/MESOS-6390
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Benjamin Bannier
>Assignee: Armand Grillet
>  Labels: newbie, python
>
> Currently {{support/mesos-style.py}} does not lint files under {{support/}}. 
> This is mostly due to the fact that these scripts are too inconsistent 
> style-wise that they wouldn't even pass the linter now.
> We should clean up all Python scripts under {{support/}} so they pass the 
> Python linter, and activate that directory in the linter for future 
> additions. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7808) Bundling gRPC into 3rdparty with CMake under Linux

[Chun-Hung Hsiao (JIRA)]

Chun-Hung Hsiao created MESOS-7808:
--

 Summary: Bundling gRPC into 3rdparty with CMake under Linux
 Key: MESOS-7808
 URL: https://issues.apache.org/jira/browse/MESOS-7808
 Project: Mesos
  Issue Type: Improvement
Reporter: Chun-Hung Hsiao
Assignee: Chun-Hung Hsiao


gRPC comes with a hand-written makefile and cmake file, but no autotool 
configuration scripts. As a first step to support gRPC in mesos, we could 
integrate gRPC into our cmake build process under Linux, and make it a 
dependency of libprocess.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7808) Bundling gRPC into 3rdparty with CMake under Linux

[Chun-Hung Hsiao (JIRA)]

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

Chun-Hung Hsiao updated MESOS-7808:
---
Description: grpc comes with a hand-written makefile and cmake file, but no 
autotool configuration scripts. As a first step to support grpc in mesos, we 
could integrate gRPC into our cmake build process under Linux, and make it a 
dependency of libprocess. Since it also depends on protobuf, this will create a 
triangular dependency between protobuf, grpc and libprocess, so the existing 
build configurations needs to be adjusted as well.  (was: gRPC comes with a 
hand-written makefile and cmake file, but no autotool configuration scripts. As 
a first step to support gRPC in mesos, we could integrate gRPC into our cmake 
build process under Linux, and make it a dependency of libprocess.)

> Bundling gRPC into 3rdparty with CMake under Linux
> --
>
> Key: MESOS-7808
> URL: https://issues.apache.org/jira/browse/MESOS-7808
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Chun-Hung Hsiao
>Assignee: Chun-Hung Hsiao
>
> grpc comes with a hand-written makefile and cmake file, but no autotool 
> configuration scripts. As a first step to support grpc in mesos, we could 
> integrate gRPC into our cmake build process under Linux, and make it a 
> dependency of libprocess. Since it also depends on protobuf, this will create 
> a triangular dependency between protobuf, grpc and libprocess, so the 
> existing build configurations needs to be adjusted as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7807) Docker executor needs to return multiple IP addresses for the container

[Avinash Sridharan (JIRA)]

Avinash Sridharan created MESOS-7807:


 Summary: Docker executor needs to return multiple IP addresses for 
the container
 Key: MESOS-7807
 URL: https://issues.apache.org/jira/browse/MESOS-7807
 Project: Mesos
  Issue Type: Task
Reporter: Avinash Sridharan
Assignee: Avinash Sridharan


`Docker executor` currently returns only a single IP address for each docker 
container. In a world where container has a v4 and v6 address the executor 
needs to return all the addresses it sees for the container else we won't be 
able to support dual-stack containers.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7806) Add copy assignment operator to `net::IP::Network`

[Avinash Sridharan (JIRA)]

Avinash Sridharan created MESOS-7806:


 Summary: Add copy assignment operator to `net::IP::Network`
 Key: MESOS-7806
 URL: https://issues.apache.org/jira/browse/MESOS-7806
 Project: Mesos
  Issue Type: Task
  Components: stout
Reporter: Avinash Sridharan
Assignee: Avinash Sridharan


Currently, we can't extend the class `net::IP::Network` with out adding a copy 
assignment operator in the derived class, due to the use of `std::unique_ptr` 
in the base class. Hence, need to introduce a copy assignment operator into the 
base class.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7769) libprocess initializes to bind to random port if --ip is not specified

[Avinash Sridharan (JIRA)]

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

Avinash Sridharan commented on MESOS-7769:
--

commit 78671375662f286128cd80d3b1f6586d0ec35cf8
Author: Avinash sridharan avin...@mesosphere.io
Date:   Fri Jul 7 16:34:23 2017 -0700

Fixed initialization of __address__ in the abscense of --ip flag.

When we introduced the __address6__ optional IPv6 storage into
libprocess we also introduced a regression because of which the port
doesn't get initialized to whatever is specified in the --port flag
until the --ip flag is specified.

This change fixes the initialization of the __address__ in the
absence of the --ip flag.

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

> libprocess initializes to bind to random port if --ip is not specified
> --
>
> Key: MESOS-7769
> URL: https://issues.apache.org/jira/browse/MESOS-7769
> Project: Mesos
>  Issue Type: Bug
>  Components: libprocess
>Affects Versions: 1.4.0
>Reporter: Yan Xu
>Assignee: Avinash Sridharan
>Priority: Blocker
>  Labels: mesosphere
> Fix For: 1.4.0
>
>
> When running current 
> [HEAD|https://github.com/apache/mesos/commit/c90bea80486c089e933bef64aca341e4cfaaef25],
> {noformat:title=without --ip}
> ./mesos-master.sh --work_dir=/tmp/mesos-test1
> ...
> I0707 14:14:05.927870  5820 master.cpp:438] Master 
> db2a2d26-a9a9-4e6f-9909-b9eca47a2862 () started on :36839
> {noformat}
> {noformat:title=with --ip}
> ./mesos-master.sh --ip= --work_dir=/tmp/mesos-test1
> I0707 14:09:56.851483  5729 master.cpp:438] Master 
> 963e0f42-9767-4629-8e3d-02c6ab6ad225 () started on :5050
> {noformat}
> It would be great this is caught by tests/CI.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7805) mesos-execute has incorrect example TaskInfo in help string

[Benjamin Bannier (JIRA)]

Benjamin Bannier created MESOS-7805:
---

 Summary: mesos-execute has incorrect example TaskInfo in help 
string
 Key: MESOS-7805
 URL: https://issues.apache.org/jira/browse/MESOS-7805
 Project: Mesos
  Issue Type: Bug
  Components: documentation
Affects Versions: 1.4.0
Reporter: Benjamin Bannier


{{mesos-execute}} documents that a task can be defined via JSON as
{noformat}
{
  "name": "Name of the task",
  "task_id": {"value" : "Id of the task"},
  "agent_id": {"value" : ""},
  "resources": [
{
  "name": "cpus",
  "type": "SCALAR",
  "scalar": {
"value": 0.1
  },
  "role": "*"
},
{
  "name": "mem",
  "type": "SCALAR",
  "scalar": {
"value": 32
  },
  "role": "*"
}
  ],
  "command": {
"value": "sleep 1000"
  }
}
{noformat}

If one actually uses that example task definition one gets
{noformat}
% ./build/src/mesos-execute --master=127.0.0.1:5050 --task=task.json
WARNING: Logging before InitGoogleLogging() is written to STDERR
W0719 17:08:17.909696 3291313088 parse.hpp:114] Specifying an absolute filename 
to read a command line option out of without using 'file:// is deprecated and 
will be removed in a future release. Simply adding 'file://' to the beginning 
of the path should eliminate this warning.
[warn] kq_init: detected broken kqueue; not using.: Undefined error: 0
I0719 17:08:17.919190 119246848 scheduler.cpp:184] Version: 1.4.0
I0719 17:08:17.923991 119783424 scheduler.cpp:470] New master detected at 
master@127.0.0.1:5050
Subscribed with ID bb0d36b4-fee0-4412-9cd9-1fa4e330355c-
F0719 17:08:18.137984 119783424 resources.cpp:1081] Check failed: 
!resource.has_role()
*** Check failure stack trace: ***
@0x101d65f5f  google::LogMessageFatal::~LogMessageFatal()
@0x101d62609  google::LogMessageFatal::~LogMessageFatal()
@0x1016ef3a3  mesos::v1::Resources::isEmpty()
@0x1016ed267  mesos::v1::Resources::add()
@0x1016f05af  mesos::v1::Resources::operator+=()
@0x1016f08fb  mesos::v1::Resources::Resources()
@0x100c0d89f  CommandScheduler::offers()
@0x100c085e4  CommandScheduler::received()
@0x100c0ae06  
_ZZN7process8dispatchI16CommandSchedulerNSt3__15queueIN5mesos2v19scheduler5EventENS2_5dequeIS7_NS2_9allocatorIS7_EESC_EEvRKNS_3PIDIT_EEMSE_FvT0_ET1_ENKUlPNS_11ProcessBaseEE_clESN_
@0x101ce5a21  process::ProcessBase::visit()
@0x101ce3747  process::ProcessManager::resume()
@0x101d0e243  
_ZNSt3__114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_ZN7process14ProcessManager12init_threadsEvE3$_0EPvSB_
@ 0x7fffbb5d693b  _pthread_body
@ 0x7fffbb5d6887  _pthread_start
@ 0x7fffbb5d608d  thread_start
[1]73521 abort  ./build/src/mesos-execute --master=127.0.0.1:5050 
--task=task.json
{noformat}

Removing the resource role field allows the task to execute.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7491) Build a CSI client to talk to a CSI plugin.

[Chun-Hung Hsiao (JIRA)]

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

Chun-Hung Hsiao updated MESOS-7491:
---
  Sprint: Mesosphere Sprint 59
Story Points: 3

> Build a CSI client to talk to a CSI plugin.
> ---
>
> Key: MESOS-7491
> URL: https://issues.apache.org/jira/browse/MESOS-7491
> Project: Mesos
>  Issue Type: Task
>Reporter: Jie Yu
>Assignee: Chun-Hung Hsiao
>  Labels: mesosphere, storage
>
> The abstraction should be something like the following:
> {code}
> namespace csi {
> public Client
> {
> public:
>   Future CreateVolume(const CreateVolumeRequest& 
> request);
>   Future DeleteVolume(const DeleteVolumeRequest& 
> request);
>   ...
> };
> } // namespace csi {
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7007) filesystem/shared and --default_container_info broken since 1.1

[Adam B (JIRA)]

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

Adam B updated MESOS-7007:
--
Sprint: Mesosphere Sprint 57, Mesosphere Sprint 58  (was: Mesosphere Sprint 
57, Mesosphere Sprint 58, Mesosphere Sprint 59)

> filesystem/shared and --default_container_info broken since 1.1
> ---
>
> Key: MESOS-7007
> URL: https://issues.apache.org/jira/browse/MESOS-7007
> Project: Mesos
>  Issue Type: Bug
>  Components: agent
>Affects Versions: 1.1.0, 1.2.0
>Reporter: Pierre Cheynier
>Assignee: Chun-Hung Hsiao
>  Labels: storage
>
> I face this issue, that prevent me to upgrade to 1.1.0 (and the change was 
> consequently introduced in this version):
> I'm using default_container_info to mount a /tmp volume in the container's 
> mount namespace from its current sandbox, meaning that each container have a 
> dedicated /tmp, thanks to the {{filesystem/shared}} isolator.
> I noticed through our automation pipeline that integration tests were failing 
> and found that this is because /tmp (the one from the host!) contents is 
> trashed each time a container is created.
> Here is my setup: 
> * 
> {{--isolation='cgroups/cpu,cgroups/mem,namespaces/pid,*disk/du,filesystem/shared,filesystem/linux*,docker/runtime'}}
> * 
> {{--default_container_info='\{"type":"MESOS","volumes":\[\{"host_path":"tmp","container_path":"/tmp","mode":"RW"\}\]\}'}}
> I discovered this issue in the early days of 1.1 (end of Nov, spoke with 
> someone on Slack), but had unfortunately no time to dig into the symptoms a 
> bit more.
> I found nothing interesting even using GLOGv=3.
> Maybe it's a bad usage of isolators that trigger this issue ? If it's the 
> case, then at least a documentation update should be done.
> Let me know if more information is needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7007) filesystem/shared and --default_container_info broken since 1.1

[Adam B (JIRA)]

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

Adam B updated MESOS-7007:
--
Sprint: Mesosphere Sprint 57, Mesosphere Sprint 58, Mesosphere Sprint 60  
(was: Mesosphere Sprint 57, Mesosphere Sprint 58)

> filesystem/shared and --default_container_info broken since 1.1
> ---
>
> Key: MESOS-7007
> URL: https://issues.apache.org/jira/browse/MESOS-7007
> Project: Mesos
>  Issue Type: Bug
>  Components: agent
>Affects Versions: 1.1.0, 1.2.0
>Reporter: Pierre Cheynier
>Assignee: Chun-Hung Hsiao
>  Labels: storage
>
> I face this issue, that prevent me to upgrade to 1.1.0 (and the change was 
> consequently introduced in this version):
> I'm using default_container_info to mount a /tmp volume in the container's 
> mount namespace from its current sandbox, meaning that each container have a 
> dedicated /tmp, thanks to the {{filesystem/shared}} isolator.
> I noticed through our automation pipeline that integration tests were failing 
> and found that this is because /tmp (the one from the host!) contents is 
> trashed each time a container is created.
> Here is my setup: 
> * 
> {{--isolation='cgroups/cpu,cgroups/mem,namespaces/pid,*disk/du,filesystem/shared,filesystem/linux*,docker/runtime'}}
> * 
> {{--default_container_info='\{"type":"MESOS","volumes":\[\{"host_path":"tmp","container_path":"/tmp","mode":"RW"\}\]\}'}}
> I discovered this issue in the early days of 1.1 (end of Nov, spoke with 
> someone on Slack), but had unfortunately no time to dig into the symptoms a 
> bit more.
> I found nothing interesting even using GLOGv=3.
> Maybe it's a bad usage of isolators that trigger this issue ? If it's the 
> case, then at least a documentation update should be done.
> Let me know if more information is needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7195) Use C++11 variadic templates for process::dispatch/defer/delay/async/run

[Dmitry Zhuk (JIRA)]

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

Dmitry Zhuk commented on MESOS-7195:


[~mcypark] sounds good. Let's proceed with the patches then.

> Use C++11 variadic templates for process::dispatch/defer/delay/async/run
> 
>
> Key: MESOS-7195
> URL: https://issues.apache.org/jira/browse/MESOS-7195
> Project: Mesos
>  Issue Type: Improvement
>  Components: libprocess
>Reporter: Yan Xu
>
> These methods are currently implemented using {{REPEAT_FROM_TO}} (i.e., 
> {{BOOST_PP_REPEAT_FROM_TO}}):
> {code:title=}
> REPEAT_FROM_TO(1, 11, TEMPLATE, _) // Args A0 -> A9.
> {code}
> This means we have to bump up the number of repetition whenever we have a new 
> method with more args.
> Seems like we can replace this with C++11 variadic templates.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7780) Add `SUBSCRIBE` call handling to the resource provider manager

[Jan Schlicht (JIRA)]

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

Jan Schlicht updated MESOS-7780:

Story Points: 5

> Add `SUBSCRIBE` call handling to the resource provider manager
> --
>
> Key: MESOS-7780
> URL: https://issues.apache.org/jira/browse/MESOS-7780
> Project: Mesos
>  Issue Type: Task
>Reporter: Jan Schlicht
>Assignee: Jan Schlicht
>  Labels: storage
>
> Resource providers will use the HTTP API to subscribe to the 
> {{ResourceProviderManager}}. Handling these calls needs to be implemented. On 
> subscription, a unique resource provider ID will be assigned to the resource 
> provider and a {{SUBSCRIBED}} event will be sent.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7792) Add support for ECDH ciphers

[Jan-Philip Gehrcke (JIRA)]

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

Jan-Philip Gehrcke commented on MESOS-7792:
---

The precise goal of this ticket really is to support TLS handshakes which use 
an ephemeral elliptic curve Diffie-Hellman key exchange, usually abbreviated 
with ECDHE.

> Add support for ECDH ciphers
> 
>
> Key: MESOS-7792
> URL: https://issues.apache.org/jira/browse/MESOS-7792
> Project: Mesos
>  Issue Type: Bug
>  Components: libprocess
>Affects Versions: 1.3.0
>Reporter: Alexander Rojas
>Assignee: Alexander Rojas
>  Labels: security
>
> [Elliptic curve 
> ciphers|https://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography] are a 
> family of ciphers supported by OpenSSL. They allow to have smaller keys, but 
> require an extra configuration parameter, the actual curve to be used, which 
> can't be done through libprocess as it is.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)