[jira] [Created] (MESOS-5272) Support docker image labels.
Gilbert Song created MESOS-5272: --- Summary: Support docker image labels. Key: MESOS-5272 URL: https://issues.apache.org/jira/browse/MESOS-5272 Project: Mesos Issue Type: Task Components: containerization Reporter: Gilbert Song Assignee: Gilbert Song Docker image labels should be supported in unified containerizer, which can be used for applying custom metadata. Image labels are necessary for mesos features to support docker in unified containerizer (e.g., for mesos GPU device isolator). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5269) Replace Master/Slave Terminology Phase I - Update Metrics
[
https://issues.apache.org/jira/browse/MESOS-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255944#comment-15255944
]
Jay Guo commented on MESOS-5269:
If we take similar approach as multi-named flags, we could also have
multi-named metrics, which take vector of strings during construction and treat
them as aliases for the same metric.
e.g.
{code}
Gauge(const std::vector& names, const Deferred()>&
f)
: Metric(name, None()), data(new Data(f)) {}
{code}
> Replace Master/Slave Terminology Phase I - Update Metrics
> -
>
> Key: MESOS-5269
> URL: https://issues.apache.org/jira/browse/MESOS-5269
> Project: Mesos
> Issue Type: Task
>Reporter: Jay Guo
>
> process::metrics::Gauge slaves_connected;
> process::metrics::Gauge slaves_disconnected;
> process::metrics::Gauge slaves_active;
> process::metrics::Gauge slaves_inactive;
> process::metrics::Counter messages_register_slave;
> process::metrics::Counter messages_reregister_slave;
> process::metrics::Counter messages_unregister_slave;
> process::metrics::Counter messages_update_slave;
> process::metrics::Counter recovery_slave_removals;
> process::metrics::Counter slave_registrations;
> process::metrics::Counter slave_reregistrations;
> process::metrics::Counter slave_removals;
> process::metrics::Counter slave_removals_reason_unhealthy;
> process::metrics::Counter slave_removals_reason_unregistered;
> process::metrics::Counter slave_removals_reason_registered;
> process::metrics::Counter slave_shutdowns_scheduled;
> process::metrics::Counter slave_shutdowns_completed;
> process::metrics::Counter slave_shutdowns_canceled;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1739) Allow slave reconfiguration on restart
[ https://issues.apache.org/jira/browse/MESOS-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255926#comment-15255926 ] Deshi Xiao commented on MESOS-1739: --- hi yujie, Do you have seen the [design docs](https://docs.google.com/document/d/1PWv7YIdV3nN2l1oUW7Nybm4KdnxZ7Px2JGc5UM-PKoQ/edit#heading=h.joukcb7ohf8y), we have delegate the ability to framework. So you mentioned case can void from the design. when the framework receive the conflict, the framework can move the not_safe app to another hosts. > Allow slave reconfiguration on restart > -- > > Key: MESOS-1739 > URL: https://issues.apache.org/jira/browse/MESOS-1739 > Project: Mesos > Issue Type: Epic >Reporter: Patrick Reilly > Labels: external-volumes, mesosphere, myriad > > Make it so that either via a slave restart or a out of process "reconfigure" > ping, the attributes and resources of a slave can be updated to be a superset > of what they used to be. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5271) Add alias support for Flags
Vinod Kone created MESOS-5271: - Summary: Add alias support for Flags Key: MESOS-5271 URL: https://issues.apache.org/jira/browse/MESOS-5271 Project: Mesos Issue Type: Improvement Reporter: Vinod Kone Assignee: Vinod Kone Currently there is no support for a flag to have an alias. Such support would be useful to rename/deprecate a flag. For example, for MESOS-4386, we could let the flag have `--authenticate` name and a `--authenticate_frameworks` alias. The alias can be marked as deprecated (need to add support for this as well). This support will also be useful for slave/agent flag rename. See MESOS-3781 for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5060) Requesting /files/read.json with a negative length value causes subsequent /files requests to 404.
[ https://issues.apache.org/jira/browse/MESOS-5060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255838#comment-15255838 ] Greg Mann commented on MESOS-5060: -- [~dongdong], yea I think it's a great idea to open up another ticket for reworking this endpoint's logic in the new operator API. There's an Epic tracking the development of the operator HTTP API at MESOS-4791; perhaps you could link that to the new ticket? > Requesting /files/read.json with a negative length value causes subsequent > /files requests to 404. > -- > > Key: MESOS-5060 > URL: https://issues.apache.org/jira/browse/MESOS-5060 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.23.0 > Environment: Mesos 0.23.0 on CentOS 6, also Mesos 0.28.0 on OSX >Reporter: Tom Petr >Assignee: zhou xing >Priority: Minor > Fix For: 0.29.0 > > > I accidentally hit a slave's /files/read.json endpoint with a negative length > (ex. http://hostname:5051/files/read.json?path=XXX&offset=0&length=-100). The > HTTP request timed out after 30 seconds with nothing relevant in the slave > logs, and subsequent calls to any of the /files endpoints on that slave > immediately returned a HTTP 404 response. We ultimately got things working > again by restarting the mesos-slave process (checkpointing FTW!), but it'd be > wise to guard against negative lengths on the slave's end too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5265) Update mesos-execute to support docker volume isolator.
[
https://issues.apache.org/jira/browse/MESOS-5265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255822#comment-15255822
]
Guangya Liu commented on MESOS-5265:
[~jieyu] , what about adding a new parameter in mesos-execute such as
{{--volumes}} option which will specify a path of a JSON file for the volumes,
any comments?
{code}
[{
"container_path":"\/tmp\/abc1",
"mode":"RW",
"source":
{
"docker_volume":
{
"driver":"convoy",
"name":"dvd1"
},
"type":"DOCKER_VOLUME"
}
},
{
"container_path":"\/tmp\/abc2",
"mode":"RW",
"source":
{
"docker_volume":
{
"driver":"convoy",
"driver_options":
{"parameter":[
{
"key":"iops",
"value":"150"
}
]},
"name":"dvd2"
},
"type":"DOCKER_VOLUME"
}
}]
{code}
> Update mesos-execute to support docker volume isolator.
> ---
>
> Key: MESOS-5265
> URL: https://issues.apache.org/jira/browse/MESOS-5265
> Project: Mesos
> Issue Type: Bug
>Reporter: Guangya Liu
>
> The mesos-execute needs to be updated to support docker volume isolator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5270) Replace Master/Slave Terminology Phase I - Duplicate slave field in JSON responses.
Jay Guo created MESOS-5270: -- Summary: Replace Master/Slave Terminology Phase I - Duplicate slave field in JSON responses. Key: MESOS-5270 URL: https://issues.apache.org/jira/browse/MESOS-5270 Project: Mesos Issue Type: Task Reporter: Jay Guo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3783) Replace Master/Slave Terminology Phase I - Update documentation
[ https://issues.apache.org/jira/browse/MESOS-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255805#comment-15255805 ] Jay Guo commented on MESOS-3783: This should be the very last one to do since it refers to endpoints, metrics, etc. > Replace Master/Slave Terminology Phase I - Update documentation > > > Key: MESOS-3783 > URL: https://issues.apache.org/jira/browse/MESOS-3783 > Project: Mesos > Issue Type: Task >Reporter: Diana Arroyo >Assignee: Jay Guo > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5269) Replace Master/Slave Terminology Phase I - Update Metrics
Jay Guo created MESOS-5269: -- Summary: Replace Master/Slave Terminology Phase I - Update Metrics Key: MESOS-5269 URL: https://issues.apache.org/jira/browse/MESOS-5269 Project: Mesos Issue Type: Task Reporter: Jay Guo process::metrics::Gauge slaves_connected; process::metrics::Gauge slaves_disconnected; process::metrics::Gauge slaves_active; process::metrics::Gauge slaves_inactive; process::metrics::Counter messages_register_slave; process::metrics::Counter messages_reregister_slave; process::metrics::Counter messages_unregister_slave; process::metrics::Counter messages_update_slave; process::metrics::Counter recovery_slave_removals; process::metrics::Counter slave_registrations; process::metrics::Counter slave_reregistrations; process::metrics::Counter slave_removals; process::metrics::Counter slave_removals_reason_unhealthy; process::metrics::Counter slave_removals_reason_unregistered; process::metrics::Counter slave_removals_reason_registered; process::metrics::Counter slave_shutdowns_scheduled; process::metrics::Counter slave_shutdowns_completed; process::metrics::Counter slave_shutdowns_canceled; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5268) Cgroups CpushareIsolator don't take effect on SLES 11 SP2 SP3
AndyPang created MESOS-5268: --- Summary: Cgroups CpushareIsolator don't take effect on SLES 11 SP2 SP3 Key: MESOS-5268 URL: https://issues.apache.org/jira/browse/MESOS-5268 Project: Mesos Issue Type: Bug Components: isolation Affects Versions: 0.27.0 Environment: suse 3.0.101-0.47.71-default #1 SMP Thu Nov 12 12:22:22 UTC 2015 (b5b212e) x86_64 x86_64 x86_64 GNU/Linux Reporter: AndyPang Assignee: AndyPang meson run in SLES 11 sp2 sp3, kernel version 3.0.13/3.076, cpushareisolator don't take effect. Two framework cpushare proportion is 1:3, we find at last in mesos container cpu.shares value is right, but when we use "top" to see result, the cpu usage is not 1:3. Our Application is multithread and can fulfil the cpu quota when single run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3783) Replace Master/Slave Terminology Phase I - Update documentation
[ https://issues.apache.org/jira/browse/MESOS-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Guo updated MESOS-3783: --- Assignee: Jay Guo > Replace Master/Slave Terminology Phase I - Update documentation > > > Key: MESOS-3783 > URL: https://issues.apache.org/jira/browse/MESOS-3783 > Project: Mesos > Issue Type: Task >Reporter: Diana Arroyo >Assignee: Jay Guo > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5267) Check dvdcli version when create the DriverClient
Guangya Liu created MESOS-5267: -- Summary: Check dvdcli version when create the DriverClient Key: MESOS-5267 URL: https://issues.apache.org/jira/browse/MESOS-5267 Project: Mesos Issue Type: Bug Reporter: Guangya Liu The dvdcli version needs to be checked when create the DriverClient as now only 0.1.0 will be supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5222) Create a benchmark for scale testing HTTP frameworks
[ https://issues.apache.org/jira/browse/MESOS-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar updated MESOS-5222: -- Story Points: 3 > Create a benchmark for scale testing HTTP frameworks > > > Key: MESOS-5222 > URL: https://issues.apache.org/jira/browse/MESOS-5222 > Project: Mesos > Issue Type: Task >Reporter: Anand Mazumdar > Labels: mesosphere > > It would be good to add a benchmark for scale testing the HTTP frameworks wrt > driver based frameworks. The benchmark can be as simple as trying to launch N > tasks (parameterized) with the old/new API. We can then focus on fixing > performance issues that we find as a result of this exercise. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5266) add test cases for docker volume driver
Guangya Liu created MESOS-5266: -- Summary: add test cases for docker volume driver Key: MESOS-5266 URL: https://issues.apache.org/jira/browse/MESOS-5266 Project: Mesos Issue Type: Bug Reporter: Guangya Liu -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5265) Update mesos-execute to support docker volume isolator.
Guangya Liu created MESOS-5265: -- Summary: Update mesos-execute to support docker volume isolator. Key: MESOS-5265 URL: https://issues.apache.org/jira/browse/MESOS-5265 Project: Mesos Issue Type: Bug Reporter: Guangya Liu The mesos-execute needs to be updated to support docker volume isolator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5264) Add agent flag to control the reference counter when unmount
Guangya Liu created MESOS-5264: -- Summary: Add agent flag to control the reference counter when unmount Key: MESOS-5264 URL: https://issues.apache.org/jira/browse/MESOS-5264 Project: Mesos Issue Type: Bug Reporter: Guangya Liu Assignee: Guangya Liu The final goal is that dvd isolator do not depend on reference counter when doing unmount, so here just add a flag to make the reference as configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5241) Porting Mesos to System z (s390x)
[ https://issues.apache.org/jira/browse/MESOS-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar updated MESOS-5241: -- Assignee: Bing Li > Porting Mesos to System z (s390x) > - > > Key: MESOS-5241 > URL: https://issues.apache.org/jira/browse/MESOS-5241 > Project: Mesos > Issue Type: Epic >Reporter: Bing Li >Assignee: Bing Li > > The goal of this ticket is to make IBM System z (s390x) as a supported > architecture. > The latest Mesos release version or master branch didn't built successfully > on s390x. > We'll contribute our patches to make Mesos work on s390x . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5263) pivot_root is not available on ARM
[
https://issues.apache.org/jira/browse/MESOS-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255713#comment-15255713
]
Tomasz Janiszewski commented on MESOS-5263:
---
Review: https://reviews.apache.org/r/46610/
> pivot_root is not available on ARM
> --
>
> Key: MESOS-5263
> URL: https://issues.apache.org/jira/browse/MESOS-5263
> Project: Mesos
> Issue Type: Bug
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
> Fix For: 0.29.0
>
>
> When compile on ARM, it will through error.
> The current code logic in src/linux/fs.cpp is:
> {code}
> #ifdef __NR_pivot_root
> int ret = ::syscall(__NR_pivot_root, newRoot.c_str(), putOld.c_str());
> #elif __x86_64__
> // A workaround for systems that have an old glib but have a new
> // kernel. The magic number '155' is the syscall number for
> // 'pivot_root' on the x86_64 architecture, see
> // arch/x86/syscalls/syscall_64.tbl
> int ret = ::syscall(155, newRoot.c_str(), putOld.c_str());
> #elif __powerpc__ || __ppc__ || __powerpc64__ || __ppc64__
> // A workaround for powerpc. The magic number '203' is the syscall
> // number for 'pivot_root' on the powerpc architecture, see
> // https://w3challs.com/syscalls/?arch=powerpc_64
> int ret = ::syscall(203, newRoot.c_str(), putOld.c_str());
> #else
> #error "pivot_root is not available"
> #endif
> {code}
> Possible sollution is to add `unistd.h` header
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5263) pivot_root is not available on ARM
[
https://issues.apache.org/jira/browse/MESOS-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Janiszewski updated MESOS-5263:
--
Description:
When compile on ARM, it will through error.
The current code logic in src/linux/fs.cpp is:
{code}
#ifdef __NR_pivot_root
int ret = ::syscall(__NR_pivot_root, newRoot.c_str(), putOld.c_str());
#elif __x86_64__
// A workaround for systems that have an old glib but have a new
// kernel. The magic number '155' is the syscall number for
// 'pivot_root' on the x86_64 architecture, see
// arch/x86/syscalls/syscall_64.tbl
int ret = ::syscall(155, newRoot.c_str(), putOld.c_str());
#elif __powerpc__ || __ppc__ || __powerpc64__ || __ppc64__
// A workaround for powerpc. The magic number '203' is the syscall
// number for 'pivot_root' on the powerpc architecture, see
// https://w3challs.com/syscalls/?arch=powerpc_64
int ret = ::syscall(203, newRoot.c_str(), putOld.c_str());
#else
#error "pivot_root is not available"
#endif
{code}
Possible sollution is to add `unistd.h` header
was:
When compile on ARM, it will through error.
The current code logic in src/linux/fs.cpp is:
{code}
#ifdef __NR_pivot_root
int ret = ::syscall(__NR_pivot_root, newRoot.c_str(), putOld.c_str());
#elif __x86_64__
// A workaround for systems that have an old glib but have a new
// kernel. The magic number '155' is the syscall number for
// 'pivot_root' on the x86_64 architecture, see
// arch/x86/syscalls/syscall_64.tbl
int ret = ::syscall(155, newRoot.c_str(), putOld.c_str());
#elif __powerpc__ || __ppc__ || __powerpc64__ || __ppc64__
// A workaround for powerpc. The magic number '203' is the syscall
// number for 'pivot_root' on the powerpc architecture, see
// https://w3challs.com/syscalls/?arch=powerpc_64
int ret = ::syscall(203, newRoot.c_str(), putOld.c_str());
#else
#error "pivot_root is not available"
#endif
{code}
[~haosd...@gmail.com] proposed adding
> pivot_root is not available on ARM
> --
>
> Key: MESOS-5263
> URL: https://issues.apache.org/jira/browse/MESOS-5263
> Project: Mesos
> Issue Type: Bug
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
> Fix For: 0.29.0
>
>
> When compile on ARM, it will through error.
> The current code logic in src/linux/fs.cpp is:
> {code}
> #ifdef __NR_pivot_root
> int ret = ::syscall(__NR_pivot_root, newRoot.c_str(), putOld.c_str());
> #elif __x86_64__
> // A workaround for systems that have an old glib but have a new
> // kernel. The magic number '155' is the syscall number for
> // 'pivot_root' on the x86_64 architecture, see
> // arch/x86/syscalls/syscall_64.tbl
> int ret = ::syscall(155, newRoot.c_str(), putOld.c_str());
> #elif __powerpc__ || __ppc__ || __powerpc64__ || __ppc64__
> // A workaround for powerpc. The magic number '203' is the syscall
> // number for 'pivot_root' on the powerpc architecture, see
> // https://w3challs.com/syscalls/?arch=powerpc_64
> int ret = ::syscall(203, newRoot.c_str(), putOld.c_str());
> #else
> #error "pivot_root is not available"
> #endif
> {code}
> Possible sollution is to add `unistd.h` header
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5263) pivot_root is not available on ARM
[
https://issues.apache.org/jira/browse/MESOS-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Janiszewski updated MESOS-5263:
--
Shepherd: (was: Vinod Kone)
> pivot_root is not available on ARM
> --
>
> Key: MESOS-5263
> URL: https://issues.apache.org/jira/browse/MESOS-5263
> Project: Mesos
> Issue Type: Bug
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
> Fix For: 0.29.0
>
>
> When compile on ARM, it will through error.
> The current code logic in src/linux/fs.cpp is:
> {code}
> #ifdef __NR_pivot_root
> int ret = ::syscall(__NR_pivot_root, newRoot.c_str(), putOld.c_str());
> #elif __x86_64__
> // A workaround for systems that have an old glib but have a new
> // kernel. The magic number '155' is the syscall number for
> // 'pivot_root' on the x86_64 architecture, see
> // arch/x86/syscalls/syscall_64.tbl
> int ret = ::syscall(155, newRoot.c_str(), putOld.c_str());
> #elif __powerpc__ || __ppc__ || __powerpc64__ || __ppc64__
> // A workaround for powerpc. The magic number '203' is the syscall
> // number for 'pivot_root' on the powerpc architecture, see
> // https://w3challs.com/syscalls/?arch=powerpc_64
> int ret = ::syscall(203, newRoot.c_str(), putOld.c_str());
> #else
> #error "pivot_root is not available"
> #endif
> {code}
> [~haosd...@gmail.com] proposed adding
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5263) pivot_root is not available on ARM
[
https://issues.apache.org/jira/browse/MESOS-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Janiszewski updated MESOS-5263:
--
Description:
When compile on ARM, it will through error.
The current code logic in src/linux/fs.cpp is:
{code}
#ifdef __NR_pivot_root
int ret = ::syscall(__NR_pivot_root, newRoot.c_str(), putOld.c_str());
#elif __x86_64__
// A workaround for systems that have an old glib but have a new
// kernel. The magic number '155' is the syscall number for
// 'pivot_root' on the x86_64 architecture, see
// arch/x86/syscalls/syscall_64.tbl
int ret = ::syscall(155, newRoot.c_str(), putOld.c_str());
#elif __powerpc__ || __ppc__ || __powerpc64__ || __ppc64__
// A workaround for powerpc. The magic number '203' is the syscall
// number for 'pivot_root' on the powerpc architecture, see
// https://w3challs.com/syscalls/?arch=powerpc_64
int ret = ::syscall(203, newRoot.c_str(), putOld.c_str());
#else
#error "pivot_root is not available"
#endif
{code}
[~haosd...@gmail.com] proposed adding
was:
When compile on ppc64le, it will through error message: src/linux/fs.cpp:443:2:
error: #error "pivot_root is not available"
The current code logic in src/linux/fs.cpp is:
{code}
#ifdef __NR_pivot_root
int ret = ::syscall(__NR_pivot_root, newRoot.c_str(), putOld.c_str());
#elif __x86_64__
// A workaround for systems that have an old glib but have a new
// kernel. The magic number '155' is the syscall number for
// 'pivot_root' on the x86_64 architecture, see
// arch/x86/syscalls/syscall_64.tbl
int ret = ::syscall(155, newRoot.c_str(), putOld.c_str());
#else
#error "pivot_root is not available"
#endif
{code}
There is no old glib version and the new kernel version, it will never run code
in *#ifdef __NR_pivot_root* condition, and when I build on Ubuntu 16.04(It has
the latest linux kernel and glibc), it still can't step into the *#ifdef
__NR_pivot_root* condition.
For powerpc case, I added another condition:
{code}
#elif __powerpc__ || __ppc__ || __powerpc64__ || __ppc64__
// A workaround for powerpc. The magic number '203' is the syscall
// number for 'pivot_root' on the powerpc architecture, see
// https://w3challs.com/syscalls/?arch=powerpc_64
int ret = ::syscall(203, newRoot.c_str(), putOld.c_str());
{code}
> pivot_root is not available on ARM
> --
>
> Key: MESOS-5263
> URL: https://issues.apache.org/jira/browse/MESOS-5263
> Project: Mesos
> Issue Type: Bug
>Reporter: Tomasz Janiszewski
>Assignee: Chen Zhiwei
> Fix For: 0.29.0
>
>
> When compile on ARM, it will through error.
> The current code logic in src/linux/fs.cpp is:
> {code}
> #ifdef __NR_pivot_root
> int ret = ::syscall(__NR_pivot_root, newRoot.c_str(), putOld.c_str());
> #elif __x86_64__
> // A workaround for systems that have an old glib but have a new
> // kernel. The magic number '155' is the syscall number for
> // 'pivot_root' on the x86_64 architecture, see
> // arch/x86/syscalls/syscall_64.tbl
> int ret = ::syscall(155, newRoot.c_str(), putOld.c_str());
> #elif __powerpc__ || __ppc__ || __powerpc64__ || __ppc64__
> // A workaround for powerpc. The magic number '203' is the syscall
> // number for 'pivot_root' on the powerpc architecture, see
> // https://w3challs.com/syscalls/?arch=powerpc_64
> int ret = ::syscall(203, newRoot.c_str(), putOld.c_str());
> #else
> #error "pivot_root is not available"
> #endif
> {code}
> [~haosd...@gmail.com] proposed adding
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-5263) pivot_root is not available on ARM
[
https://issues.apache.org/jira/browse/MESOS-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Janiszewski reassigned MESOS-5263:
-
Assignee: Tomasz Janiszewski (was: Chen Zhiwei)
> pivot_root is not available on ARM
> --
>
> Key: MESOS-5263
> URL: https://issues.apache.org/jira/browse/MESOS-5263
> Project: Mesos
> Issue Type: Bug
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
> Fix For: 0.29.0
>
>
> When compile on ARM, it will through error.
> The current code logic in src/linux/fs.cpp is:
> {code}
> #ifdef __NR_pivot_root
> int ret = ::syscall(__NR_pivot_root, newRoot.c_str(), putOld.c_str());
> #elif __x86_64__
> // A workaround for systems that have an old glib but have a new
> // kernel. The magic number '155' is the syscall number for
> // 'pivot_root' on the x86_64 architecture, see
> // arch/x86/syscalls/syscall_64.tbl
> int ret = ::syscall(155, newRoot.c_str(), putOld.c_str());
> #elif __powerpc__ || __ppc__ || __powerpc64__ || __ppc64__
> // A workaround for powerpc. The magic number '203' is the syscall
> // number for 'pivot_root' on the powerpc architecture, see
> // https://w3challs.com/syscalls/?arch=powerpc_64
> int ret = ::syscall(203, newRoot.c_str(), putOld.c_str());
> #else
> #error "pivot_root is not available"
> #endif
> {code}
> [~haosd...@gmail.com] proposed adding
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5263) pivot_root is not available on ARM
Tomasz Janiszewski created MESOS-5263:
-
Summary: pivot_root is not available on ARM
Key: MESOS-5263
URL: https://issues.apache.org/jira/browse/MESOS-5263
Project: Mesos
Issue Type: Bug
Reporter: Tomasz Janiszewski
Assignee: Chen Zhiwei
Fix For: 0.29.0
When compile on ppc64le, it will through error message: src/linux/fs.cpp:443:2:
error: #error "pivot_root is not available"
The current code logic in src/linux/fs.cpp is:
{code}
#ifdef __NR_pivot_root
int ret = ::syscall(__NR_pivot_root, newRoot.c_str(), putOld.c_str());
#elif __x86_64__
// A workaround for systems that have an old glib but have a new
// kernel. The magic number '155' is the syscall number for
// 'pivot_root' on the x86_64 architecture, see
// arch/x86/syscalls/syscall_64.tbl
int ret = ::syscall(155, newRoot.c_str(), putOld.c_str());
#else
#error "pivot_root is not available"
#endif
{code}
There is no old glib version and the new kernel version, it will never run code
in *#ifdef __NR_pivot_root* condition, and when I build on Ubuntu 16.04(It has
the latest linux kernel and glibc), it still can't step into the *#ifdef
__NR_pivot_root* condition.
For powerpc case, I added another condition:
{code}
#elif __powerpc__ || __ppc__ || __powerpc64__ || __ppc64__
// A workaround for powerpc. The magic number '203' is the syscall
// number for 'pivot_root' on the powerpc architecture, see
// https://w3challs.com/syscalls/?arch=powerpc_64
int ret = ::syscall(203, newRoot.c_str(), putOld.c_str());
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5013) Add docker volume driver isolator for Mesos containerizer.
[ https://issues.apache.org/jira/browse/MESOS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255692#comment-15255692 ] Jie Yu commented on MESOS-5013: --- commit 8212770ff7142d730383195865bce3487aac5ba0 Author: Guangya Liu Date: Sun Apr 24 11:55:14 2016 -0700 Plugged in docker volume isolator. Review: https://reviews.apache.org/r/45265/ > Add docker volume driver isolator for Mesos containerizer. > -- > > Key: MESOS-5013 > URL: https://issues.apache.org/jira/browse/MESOS-5013 > Project: Mesos > Issue Type: Bug >Reporter: Guangya Liu >Assignee: Guangya Liu > Labels: mesosphere > > The isolator will interact with Docker Volume Driver Plugins to mount and > unmount external volumes to container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5013) Add docker volume driver isolator for Mesos containerizer.
[ https://issues.apache.org/jira/browse/MESOS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255691#comment-15255691 ] Jie Yu commented on MESOS-5013: --- commit 39a5d9459a862056d658ce0049cc299129172a2d Author: Guangya Liu Date: Sun Apr 24 11:53:10 2016 -0700 Enabled sequene for unmount() in docker volume isolator. Review: https://reviews.apache.org/r/44609 > Add docker volume driver isolator for Mesos containerizer. > -- > > Key: MESOS-5013 > URL: https://issues.apache.org/jira/browse/MESOS-5013 > Project: Mesos > Issue Type: Bug >Reporter: Guangya Liu >Assignee: Guangya Liu > Labels: mesosphere > > The isolator will interact with Docker Volume Driver Plugins to mount and > unmount external volumes to container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5013) Add docker volume driver isolator for Mesos containerizer.
[ https://issues.apache.org/jira/browse/MESOS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255689#comment-15255689 ] Jie Yu commented on MESOS-5013: --- commit e92cc460a7caf220bbb61941bb49e24e739f4b4a Author: Guangya Liu Date: Sun Apr 24 11:46:29 2016 -0700 Enabled Sequence mount for prepare() in docker volume isolator. Review: https://reviews.apache.org/r/44454 commit 65c35fdd5ae83e71c874c09911f58f036e7bfeb6 Author: Guangya Liu Date: Sun Apr 24 11:05:02 2016 -0700 Implemented recover() for the docker volume isolator. Review: https://reviews.apache.org/r/45674/ commit 3add364e10ea6dac116bc8102b37f0de9db8bf99 Author: Guangya Liu Date: Sun Apr 24 11:03:36 2016 -0700 Implemented cleanup() for docker volume isolator. Review: https://reviews.apache.org/r/45375 > Add docker volume driver isolator for Mesos containerizer. > -- > > Key: MESOS-5013 > URL: https://issues.apache.org/jira/browse/MESOS-5013 > Project: Mesos > Issue Type: Bug >Reporter: Guangya Liu >Assignee: Guangya Liu > Labels: mesosphere > > The isolator will interact with Docker Volume Driver Plugins to mount and > unmount external volumes to container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5013) Add docker volume driver isolator for Mesos containerizer.
[ https://issues.apache.org/jira/browse/MESOS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-5013: -- Sprint: Mesosphere Sprint 33 Story Points: 8 > Add docker volume driver isolator for Mesos containerizer. > -- > > Key: MESOS-5013 > URL: https://issues.apache.org/jira/browse/MESOS-5013 > Project: Mesos > Issue Type: Bug >Reporter: Guangya Liu >Assignee: Guangya Liu > Labels: mesosphere > > The isolator will interact with Docker Volume Driver Plugins to mount and > unmount external volumes to container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5013) Add docker volume driver isolator for Mesos containerizer.
[ https://issues.apache.org/jira/browse/MESOS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255657#comment-15255657 ] Jie Yu commented on MESOS-5013: --- commit e8e65535c8ee105e262662fde95aef2d93b289a5 Author: Guangya Liu Date: Sat Apr 23 22:30:23 2016 -0700 Implemented prepare() for volume isolator. Review: https://reviews.apache.org/r/45370/ > Add docker volume driver isolator for Mesos containerizer. > -- > > Key: MESOS-5013 > URL: https://issues.apache.org/jira/browse/MESOS-5013 > Project: Mesos > Issue Type: Bug >Reporter: Guangya Liu >Assignee: Guangya Liu > Labels: mesosphere > > The isolator will interact with Docker Volume Driver Plugins to mount and > unmount external volumes to container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1575) master sets failover timeout to 0 when framework requests a high value
[
https://issues.apache.org/jira/browse/MESOS-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255580#comment-15255580
]
José Guilherme Vanz commented on MESOS-1575:
OK. I'll do that.
> master sets failover timeout to 0 when framework requests a high value
> --
>
> Key: MESOS-1575
> URL: https://issues.apache.org/jira/browse/MESOS-1575
> Project: Mesos
> Issue Type: Bug
>Reporter: Kevin Sweeney
>Assignee: José Guilherme Vanz
> Labels: newbie, twitter
>
> In response to a registered RPC we observed the following behavior:
> {noformat}
> W0709 19:07:32.982997 11400 master.cpp:612] Using the default value for
> 'failover_timeout' becausethe input value is invalid: Argument out of the
> range that a Duration can represent due to int64_t's size limit
> I0709 19:07:32.983008 11404 hierarchical_allocator_process.hpp:408]
> Deactivated framework 20140709-184342-119646400-5050-11380-0003
> I0709 19:07:32.983013 11400 master.cpp:617] Giving framework
> 20140709-184342-119646400-5050-11380-0003 0ns to failover
> I0709 19:07:32.983271 11404 master.cpp:2201] Framework failover timeout,
> removing framework 20140709-184342-119646400-5050-11380-0003
> I0709 19:07:32.983294 11404 master.cpp:2688] Removing framework
> 20140709-184342-119646400-5050-11380-0003
> I0709 19:07:32.983678 11404 hierarchical_allocator_process.hpp:363] Removed
> framework 20140709-184342-119646400-5050-11380-0003
> {noformat}
> This was using the following frameworkInfo.
> {code}
> FrameworkInfo frameworkInfo = FrameworkInfo.newBuilder()
> .setUser("test")
> .setName("jvm")
> .setFailoverTimeout(Long.MAX_VALUE)
> .build();
> {code}
> Instead of silently defaulting large values to 0 the master should refuse to
> process the request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5121) pivot_root is not available on PowerPC
[
https://issues.apache.org/jira/browse/MESOS-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255549#comment-15255549
]
haosdent commented on MESOS-5121:
-
I take a look at [~RobinDong]'s [patch |
https://reviews.apache.org/r/34882/diff/1#index_header] for arm64 today. I
think the better way to make pivot_root works in different platforms are add
this line from his patch
{code}
#include
{code}
This header file contains the define for {{__NR_pivot_root}}
cc [~janisz]
> pivot_root is not available on PowerPC
> --
>
> Key: MESOS-5121
> URL: https://issues.apache.org/jira/browse/MESOS-5121
> Project: Mesos
> Issue Type: Bug
>Reporter: Chen Zhiwei
>Assignee: Chen Zhiwei
> Fix For: 0.29.0
>
>
> When compile on ppc64le, it will through error message:
> src/linux/fs.cpp:443:2: error: #error "pivot_root is not available"
> The current code logic in src/linux/fs.cpp is:
> {code}
> #ifdef __NR_pivot_root
> int ret = ::syscall(__NR_pivot_root, newRoot.c_str(), putOld.c_str());
> #elif __x86_64__
> // A workaround for systems that have an old glib but have a new
> // kernel. The magic number '155' is the syscall number for
> // 'pivot_root' on the x86_64 architecture, see
> // arch/x86/syscalls/syscall_64.tbl
> int ret = ::syscall(155, newRoot.c_str(), putOld.c_str());
> #else
> #error "pivot_root is not available"
> #endif
> {code}
> There is no old glib version and the new kernel version, it will never run
> code in *#ifdef __NR_pivot_root* condition, and when I build on Ubuntu
> 16.04(It has the latest linux kernel and glibc), it still can't step into the
> *#ifdef __NR_pivot_root* condition.
> For powerpc case, I added another condition:
> {code}
> #elif __powerpc__ || __ppc__ || __powerpc64__ || __ppc64__
> // A workaround for powerpc. The magic number '203' is the syscall
> // number for 'pivot_root' on the powerpc architecture, see
> // https://w3challs.com/syscalls/?arch=powerpc_64
> int ret = ::syscall(203, newRoot.c_str(), putOld.c_str());
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2022) Mesos does not compile on ARM architecture
[ https://issues.apache.org/jira/browse/MESOS-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255548#comment-15255548 ] haosdent commented on MESOS-2022: - Zookeper is not a blocker now. > Mesos does not compile on ARM architecture > -- > > Key: MESOS-2022 > URL: https://issues.apache.org/jira/browse/MESOS-2022 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.20.1 > Environment: Linux c1-10-1-2-103.cloud.online.net 3.17.0-85 #2 SMP > Wed Oct 15 15:31:27 CEST 2014 armv7l Marvell Armada 370/XP (Device Tree) > GNU/Linux >Reporter: Axel Etcheverry > > Hi, > The compilation is blocked by ZooKeeper <=3.4.6, fixed by >=3.5. > the patch for ZooKeeper 3.4.6 : > https://gist.github.com/euskadi31/2e5a2f9e9d7e94a621e0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
