[jira] [Commented] (MESOS-6010) Docker registry puller shows decode error "No response decoded".
[
https://issues.apache.org/jira/browse/MESOS-6010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584458#comment-15584458
]
Jie Yu commented on MESOS-6010:
---
An initial investigation indicates that this might be related to proxy. Are you
guys using proxy for docker hub? [~abhat], [~Sunzhe]
> Docker registry puller shows decode error "No response decoded".
>
>
> Key: MESOS-6010
> URL: https://issues.apache.org/jira/browse/MESOS-6010
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker
>Affects Versions: 1.0.0, 1.0.1
>Reporter: Sunzhe
> Labels: Docker, mesos-containerizer
>
> The {{mesos-agent}} flags:
> {code}
> GLOG_v=1 ./bin/mesos-agent.sh \
> --master=zk://${MESOS_MASTER_IP}:2181/mesos \
> --ip=10.100.3.3 \
> --work_dir=${MESOS_WORK_DIR} \
>
> --isolation=cgroups/devices,gpu/nvidia,disk/du,docker/runtime,filesystem/linux
> \
> --enforce_container_disk_quota \
> --containerizers=mesos \
> --image_providers=docker \
> --executor_environment_variables="{}"
> {code}
> And the {{mesos-execute}} flags:
> {code}
> ./src/mesos-execute \
>--master=${MESOS_MASTER_IP}:5050 \
>--name=${INSTANCE_NAME} \
>--docker_image=${DOCKER_IMAGE} \
>--framework_capabilities=GPU_RESOURCES \
>--shell=false
> {code}
> But when {{./src/mesos-execute}}, the errors like below:
> {code}
> I0809 16:11:46.207875 25583 scheduler.cpp:172] Version: 1.0.0
> I0809 16:11:46.212442 25582 scheduler.cpp:461] New master detected at
> master@10.103.0.125:5050
> Subscribed with ID '168ab900-ee7e-4829-a59a-d16de956637e-0009'
> Submitted task 'test' to agent '168ab900-ee7e-4829-a59a-d16de956637e-S1'
> Received status update TASK_FAILED for task 'test'
> message: 'Failed to launch container: Failed to decode HTTP responses: No
> response decoded
> HTTP/1.1 200 Connection established
> HTTP/1.1 401 Unauthorized
> Content-Type: application/json; charset=utf-8
> Docker-Distribution-Api-Version: registry/2.0
> Www-Authenticate: Bearer
> realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:library/redis:pull;
> Date: Tue, 09 Aug 2016 08:10:32 GMT
> Content-Length: 145
> Strict-Transport-Security: max-age=31536000
> {"errors":[{"code":"UNAUTHORIZED","message":"authentication
> required","detail":[{"Type":"repository","Name":"library/redis","Action":"pull"}]}]}
> ; Container destroyed while provisioning images'
> source: SOURCE_AGENT
> reason: REASON_CONTAINER_LAUNCH_FAILED
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-6409) mesos-ps - Invalid header value
[ https://issues.apache.org/jira/browse/MESOS-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584435#comment-15584435 ] Ronald Petty edited comment on MESOS-6409 at 10/18/16 4:42 AM: --- Also noticed this code is repeated in the cli tools, could use some DRY'ing up. If someone with more knowledge than me agrees (or has other advice) I am happy to jump in and work on this. I still assume its me (user error) but unclear how at the moment. was (Author: ronald.petty): Also noticed this code is repeated in the cli tools, could use some DRY'ing up. > mesos-ps - Invalid header value > --- > > Key: MESOS-6409 > URL: https://issues.apache.org/jira/browse/MESOS-6409 > Project: Mesos > Issue Type: Bug > Components: master >Affects Versions: 1.0.1 > Environment: Linux >Reporter: Ronald Petty > > Fresh install on Ubuntu 16.04. Follow posix instructions then install libz. > user@nodea:~$ mesos-ps --master=127.0.0.1:5050 > Failed to get the master state: Invalid header value '127.0.0.1:5050\n' > Master log shows: > I1017 21:08:28.685926 70112 http.cpp:381] HTTP GET for /master/state from > 127.0.0.1:50526 with User-Agent='Mozilla/5.0 (X11; Ubuntu; Linux x86_64; > rv:49.0) Gecko/20100101 Firefox/49.0' > If you use 'curl' it works: > curl localhost:5050/state.json > I also tried 127.0.0.1 and http, also errors out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6409) mesos-ps - Invalid header value
[ https://issues.apache.org/jira/browse/MESOS-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584435#comment-15584435 ] Ronald Petty commented on MESOS-6409: - Also noticed this code is repeated in the cli tools, could use some DRY'ing up. > mesos-ps - Invalid header value > --- > > Key: MESOS-6409 > URL: https://issues.apache.org/jira/browse/MESOS-6409 > Project: Mesos > Issue Type: Bug > Components: master >Affects Versions: 1.0.1 > Environment: Linux >Reporter: Ronald Petty > > Fresh install on Ubuntu 16.04. Follow posix instructions then install libz. > user@nodea:~$ mesos-ps --master=127.0.0.1:5050 > Failed to get the master state: Invalid header value '127.0.0.1:5050\n' > Master log shows: > I1017 21:08:28.685926 70112 http.cpp:381] HTTP GET for /master/state from > 127.0.0.1:50526 with User-Agent='Mozilla/5.0 (X11; Ubuntu; Linux x86_64; > rv:49.0) Gecko/20100101 Firefox/49.0' > If you use 'curl' it works: > curl localhost:5050/state.json > I also tried 127.0.0.1 and http, also errors out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6409) mesos-ps - Invalid header value
[
https://issues.apache.org/jira/browse/MESOS-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584421#comment-15584421
]
Ronald Petty commented on MESOS-6409:
-
I dug around a little, a fix seems to be to string the newline.
sudo vi $(which mesos-ps)
# Get master info.
try:
#was master = resolve(options.master)
master = str.strip(resolve(options.master))
except Exception as e:
fatal('Failed to get the master: %s' % str(e))
I am on Ubuntu 16.04.1. Unclear what the cause is. Should I do a PR for this?
Anyone else having a similar issue?
Regards.
Ron
> mesos-ps - Invalid header value
> ---
>
> Key: MESOS-6409
> URL: https://issues.apache.org/jira/browse/MESOS-6409
> Project: Mesos
> Issue Type: Bug
> Components: master
>Affects Versions: 1.0.1
> Environment: Linux
>Reporter: Ronald Petty
>
> Fresh install on Ubuntu 16.04. Follow posix instructions then install libz.
> user@nodea:~$ mesos-ps --master=127.0.0.1:5050
> Failed to get the master state: Invalid header value '127.0.0.1:5050\n'
> Master log shows:
> I1017 21:08:28.685926 70112 http.cpp:381] HTTP GET for /master/state from
> 127.0.0.1:50526 with User-Agent='Mozilla/5.0 (X11; Ubuntu; Linux x86_64;
> rv:49.0) Gecko/20100101 Firefox/49.0'
> If you use 'curl' it works:
> curl localhost:5050/state.json
> I also tried 127.0.0.1 and http, also errors out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6400) Not able to remove Orphan Tasks
[
https://issues.apache.org/jira/browse/MESOS-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kasim updated MESOS-6400:
-
Description:
The problem maybe cause by Mesos and Marathon out of sync
https://github.com/mesosphere/marathon/issues/616
When I found Orphan Tasks happen, I
1. restart marathon
2. marathon do not sync Orphan Tasks, but start new tasks.
3. Orphan Tasks still taked the resource, I have to delete them.
4. I find all Orphan Tasks are under framework
`ef169d8a-24fc-41d1-8b0d-c67718937a48-`,
curl -XGET `http://c196:5050/master/frameworks` shows that framework is
`unregistered_frameworks`
{code}
{
"frameworks": [
.
],
"completed_frameworks": [ ],
"unregistered_frameworks": [
"ef169d8a-24fc-41d1-8b0d-c67718937a48-",
"ef169d8a-24fc-41d1-8b0d-c67718937a48-",
"ef169d8a-24fc-41d1-8b0d-c67718937a48-"
]
}
{code}
5.Try {code}curl -XPOST http://c196:5050/master/teardown -d
'frameworkId=ef169d8a-24fc-41d1-8b0d-c67718937a48-' {code}
， but get `No framework found with specified ID`
So I have no idea to delete Orphan Tasks
was:
The problem maybe cause by Mesos and Marathon out of sync
https://github.com/mesosphere/marathon/issues/616
When I found Orphan Tasks happen, I
1. restart marathon
2. marathon do not sync Orphan Tasks, but start new tasks.
3. Orphan Tasks still taked the resource, I have to delete them.
4. all Orphan Tasks is under `ef169d8a-24fc-41d1-8b0d-c67718937a48-`
curl -XGET `http://c196:5050/master/frameworks` shows that framework is
`unregistered_frameworks`
{code}
{
"frameworks": [
.
],
"completed_frameworks": [ ],
"unregistered_frameworks": [
"ef169d8a-24fc-41d1-8b0d-c67718937a48-",
"ef169d8a-24fc-41d1-8b0d-c67718937a48-",
"ef169d8a-24fc-41d1-8b0d-c67718937a48-"
]
}
{code}
5.Try {code}curl -XPOST http://c196:5050/master/teardown -d
'frameworkId=ef169d8a-24fc-41d1-8b0d-c67718937a48-' {code}
， but get `No framework found with specified ID`
So I have no idea to delete Orphan Tasks
> Not able to remove Orphan Tasks
> ---
>
> Key: MESOS-6400
> URL: https://issues.apache.org/jira/browse/MESOS-6400
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: centos 7 x64
>Reporter: kasim
>
> The problem maybe cause by Mesos and Marathon out of sync
> https://github.com/mesosphere/marathon/issues/616
> When I found Orphan Tasks happen, I
> 1. restart marathon
> 2. marathon do not sync Orphan Tasks, but start new tasks.
> 3. Orphan Tasks still taked the resource, I have to delete them.
> 4. I find all Orphan Tasks are under framework
> `ef169d8a-24fc-41d1-8b0d-c67718937a48-`,
> curl -XGET `http://c196:5050/master/frameworks` shows that framework is
> `unregistered_frameworks`
> {code}
> {
> "frameworks": [
> .
> ],
> "completed_frameworks": [ ],
> "unregistered_frameworks": [
> "ef169d8a-24fc-41d1-8b0d-c67718937a48-",
> "ef169d8a-24fc-41d1-8b0d-c67718937a48-",
> "ef169d8a-24fc-41d1-8b0d-c67718937a48-"
> ]
> }
> {code}
> 5.Try {code}curl -XPOST http://c196:5050/master/teardown -d
> 'frameworkId=ef169d8a-24fc-41d1-8b0d-c67718937a48-' {code}
> ， but get `No framework found with specified ID`
> So I have no idea to delete Orphan Tasks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-6408) Changelog for `mesos-cni-port-mapper` to 1.1.0
[ https://issues.apache.org/jira/browse/MESOS-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avinash Sridharan updated MESOS-6408: - Comment: was deleted (was: commit 1091d471991701d65c69e8fb6e6a586d84676c7a Author: Avinash sridharan avin...@mesosphere.io Date: Mon Oct 17 17:59:32 2016 -0700 Added `mesos-cni-port-mapper` to the CHANGELOG. Review: https://reviews.apache.org/r/52968/) > Changelog for `mesos-cni-port-mapper` to 1.1.0 > -- > > Key: MESOS-6408 > URL: https://issues.apache.org/jira/browse/MESOS-6408 > Project: Mesos > Issue Type: Task >Reporter: Avinash Sridharan >Assignee: Avinash Sridharan > Fix For: 1.1.0 > > > Update changelog for 1.1.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6408) Changelog for `mesos-cni-port-mapper` to 1.1.0
[ https://issues.apache.org/jira/browse/MESOS-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584048#comment-15584048 ] Avinash Sridharan commented on MESOS-6408: -- commit 1091d471991701d65c69e8fb6e6a586d84676c7a Author: Avinash sridharan avin...@mesosphere.io Date: Mon Oct 17 17:59:32 2016 -0700 Added `mesos-cni-port-mapper` to the CHANGELOG. Review: https://reviews.apache.org/r/52968/ > Changelog for `mesos-cni-port-mapper` to 1.1.0 > -- > > Key: MESOS-6408 > URL: https://issues.apache.org/jira/browse/MESOS-6408 > Project: Mesos > Issue Type: Task >Reporter: Avinash Sridharan >Assignee: Avinash Sridharan > > Update changelog for 1.1.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6282) CNI isolator should print plugin's stderr
[ https://issues.apache.org/jira/browse/MESOS-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-6282: -- Target Version/s: 1.1.0 (was: 1.2.0) > CNI isolator should print plugin's stderr > - > > Key: MESOS-6282 > URL: https://issues.apache.org/jira/browse/MESOS-6282 > Project: Mesos > Issue Type: Improvement > Components: containerization, isolation, network >Reporter: Dan Osborne >Assignee: Avinash Sridharan > Fix For: 1.1.0 > > > It's quite difficult for both Operators and CNI plugin developers to diagnose > CNI plugin errors in production or in test when the only error information > available is the stdout error string returned by the plugin (assuming it > managed to even print its correctly formatted text to stdout). > Many CNI plugins print logging information to stderr, [as per the CNI > spec|https://github.com/containernetworking/cni/blob/master/SPEC.md#result]: > bq. In addition, stderr can be used for unstructured output such as logs. > Therefore, I propose the Mesos CNI Isolator capture the CNI plugin's stderr > output and log it to the Agent Logs, for easier diagnosis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6023) Create a binary for the port-mapper plugin
[ https://issues.apache.org/jira/browse/MESOS-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-6023: -- Target Version/s: 1.1.0 (was: 1.1.1) > Create a binary for the port-mapper plugin > -- > > Key: MESOS-6023 > URL: https://issues.apache.org/jira/browse/MESOS-6023 > Project: Mesos > Issue Type: Task > Components: containerization > Environment: Linux >Reporter: Avinash Sridharan >Assignee: Avinash Sridharan >Priority: Blocker > Fix For: 1.1.0 > > > The CNI port mapper plugin needs to be a separate binary that will be invoked > by the `network/cni` isolator as a CNI plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6310) Remove or define non-POSIX function
[
https://issues.apache.org/jira/browse/MESOS-6310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583669#comment-15583669
]
Till Toenshoff commented on MESOS-6310:
---
Closed now as per chat with [~klueska].
> Remove or define non-POSIX function
> ---
>
> Key: MESOS-6310
> URL: https://issues.apache.org/jira/browse/MESOS-6310
> Project: Mesos
> Issue Type: Improvement
> Components: containerization
>Affects Versions: 1.0.2
>Reporter: Marc Villacorta
>Assignee: Kevin Klues
>Priority: Minor
> Fix For: 1.1.0
>
>
> I was trying to compile Mesos using _musl_ inside Alpine Linux 3.4.
> But this [commit|
> https://github.com/apache/mesos/commit/498d14e934233e4501597b43da3924bfe8b2de20]
> introduced the {{W_EXITCODE()}} macro which is not defined in _musl_ and
> seems to be non-POSIX.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-6310) Remove or define non-POSIX function
[
https://issues.apache.org/jira/browse/MESOS-6310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-6310:
--
Comment: was deleted
(was: Closed now as per chat with [~klueska].)
> Remove or define non-POSIX function
> ---
>
> Key: MESOS-6310
> URL: https://issues.apache.org/jira/browse/MESOS-6310
> Project: Mesos
> Issue Type: Improvement
> Components: containerization
>Affects Versions: 1.0.2
>Reporter: Marc Villacorta
>Assignee: Kevin Klues
>Priority: Minor
> Fix For: 1.1.0
>
>
> I was trying to compile Mesos using _musl_ inside Alpine Linux 3.4.
> But this [commit|
> https://github.com/apache/mesos/commit/498d14e934233e4501597b43da3924bfe8b2de20]
> introduced the {{W_EXITCODE()}} macro which is not defined in _musl_ and
> seems to be non-POSIX.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6310) Remove or define non-POSIX function
[
https://issues.apache.org/jira/browse/MESOS-6310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583668#comment-15583668
]
Till Toenshoff commented on MESOS-6310:
---
Closed now as per chat with [~klueska].
> Remove or define non-POSIX function
> ---
>
> Key: MESOS-6310
> URL: https://issues.apache.org/jira/browse/MESOS-6310
> Project: Mesos
> Issue Type: Improvement
> Components: containerization
>Affects Versions: 1.0.2
>Reporter: Marc Villacorta
>Assignee: Kevin Klues
>Priority: Minor
> Fix For: 1.1.0
>
>
> I was trying to compile Mesos using _musl_ inside Alpine Linux 3.4.
> But this [commit|
> https://github.com/apache/mesos/commit/498d14e934233e4501597b43da3924bfe8b2de20]
> introduced the {{W_EXITCODE()}} macro which is not defined in _musl_ and
> seems to be non-POSIX.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6310) Remove or define non-POSIX function
[
https://issues.apache.org/jira/browse/MESOS-6310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583575#comment-15583575
]
Till Toenshoff commented on MESOS-6310:
---
The ticket got reopened and hence now again shows in queries that try to
identify issues that are not "resolved" but have a fix version set. Would it be
a good idea to file an additional JIRA covering those new changes. [~klueska] ?
> Remove or define non-POSIX function
> ---
>
> Key: MESOS-6310
> URL: https://issues.apache.org/jira/browse/MESOS-6310
> Project: Mesos
> Issue Type: Improvement
> Components: containerization
>Affects Versions: 1.0.2
>Reporter: Marc Villacorta
>Assignee: Kevin Klues
>Priority: Minor
> Fix For: 1.1.0
>
>
> I was trying to compile Mesos using _musl_ inside Alpine Linux 3.4.
> But this [commit|
> https://github.com/apache/mesos/commit/498d14e934233e4501597b43da3924bfe8b2de20]
> introduced the {{W_EXITCODE()}} macro which is not defined in _musl_ and
> seems to be non-POSIX.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6374) CREATE operation shouldn't require the client to specify how the persistent volume should be mounted
[
https://issues.apache.org/jira/browse/MESOS-6374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yan Xu updated MESOS-6374:
--
Description:
Because CREATE doesn't mount it and there is no container.
Currently in {{Resource}} protobuf [if 'persistence' is set, 'volume' must be
set|https://github.com/apache/mesos/blob/af2d406282d8da0ed93eacf997bf8f94aa77b492/include/mesos/v1/mesos.proto#L831-L832],
this requires frameworks to specify a {{volume}} field with a dummy
{{container_path}} because it's a required field.
The lifecycle management of persistent "volumes" is so different from regular
volumes that we should use the {{volume}} field only in the context of
tasks/containers.
We should put everything related to the management of persistent volumes into
{{Persistence}} and not require {{volume}} to be set when we are
creating/destroying a persistent volume.
In doing so, the user doesn't have to specify the RW vs. RO mode when creating
a persistent volume, it really only matters when the volume is used.
was:
Because CREATE doesn't mount it and there is no container.
Currently in {{Resource}} protobuf [if 'persistence' is set, 'volume' must be
set|https://github.com/apache/mesos/blob/af2d406282d8da0ed93eacf997bf8f94aa77b492/include/mesos/v1/mesos.proto#L831-L832],
this requires frameworks to specify a {{volume}} field with a dummy
{{container_path}} because it's a required field.
The lifecycle management of persistent "volumes" is so different from regular
volumes that we should use the {{volume}} field only in the context of
tasks/containers.
We should put everything related to the management of persistent volumes into
{{Persistence}} and not require {{volume}} to be set when we are
creating/destroying a persistent volume.
> CREATE operation shouldn't require the client to specify how the persistent
> volume should be mounted
>
>
> Key: MESOS-6374
> URL: https://issues.apache.org/jira/browse/MESOS-6374
> Project: Mesos
> Issue Type: Bug
>Reporter: Yan Xu
>
> Because CREATE doesn't mount it and there is no container.
> Currently in {{Resource}} protobuf [if 'persistence' is set, 'volume' must be
> set|https://github.com/apache/mesos/blob/af2d406282d8da0ed93eacf997bf8f94aa77b492/include/mesos/v1/mesos.proto#L831-L832],
> this requires frameworks to specify a {{volume}} field with a dummy
> {{container_path}} because it's a required field.
> The lifecycle management of persistent "volumes" is so different from regular
> volumes that we should use the {{volume}} field only in the context of
> tasks/containers.
> We should put everything related to the management of persistent volumes into
> {{Persistence}} and not require {{volume}} to be set when we are
> creating/destroying a persistent volume.
> In doing so, the user doesn't have to specify the RW vs. RO mode when
> creating a persistent volume, it really only matters when the volume is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6407) Move DEFAULT_v1_xxx macros to the v1 namespace.
Anand Mazumdar created MESOS-6407:
-
Summary: Move DEFAULT_v1_xxx macros to the v1 namespace.
Key: MESOS-6407
URL: https://issues.apache.org/jira/browse/MESOS-6407
Project: Mesos
Issue Type: Improvement
Reporter: Anand Mazumdar
Assignee: Joris Van Remoortere
We should clean up the existing {{DEFAULT_v1_*}} macros and bring it under the
{{v1}} namespace e.g., {{v1::DEFAULT_FRAMEWORK_INFO}}. This is necessary for
doing a larger cleanup i.e., we would like to introduce {{createXXX}} for the
{{v1}} API and would not like to add {{createV1XXX}} functions eventually.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6404) My program cannot access a .so file while being run with mesos containerization on a docker image.
[
https://issues.apache.org/jira/browse/MESOS-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583256#comment-15583256
]
Mark Hammons commented on MESOS-6404:
-
tomorrow I will make an image based off a pure docker file (no deletions or
anything), and post the dockerfile here if I'm still having the issue.
> My program cannot access a .so file while being run with mesos
> containerization on a docker image.
> --
>
> Key: MESOS-6404
> URL: https://issues.apache.org/jira/browse/MESOS-6404
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: CentOS Linux release 7.2.1511 (Core)
>Reporter: Mark Hammons
>Priority: Minor
> Attachments: IUWT_140926aR_t000_ch00.log
>
>
> I have an application compiled within a docker environment called
> ubuntu-mesos:0.11-17102016-IUWT. I've defined the executor for said
> application with the following code:
> val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://***/
> IUWT.tar.gz").setExtract(true).setCache(false).build()
> val iuwtjURI = CommandInfo.URI.newBuilder().setValue("http://***/
> iuwtExecutor-assembly-0.1-
> SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> val iuwtExec = "java -jar iuwtExecutor-assembly-0.1-SNAPSHOT.jar -
> Xmx1024M -Xmx128M"
> val iuwtCommand =
> CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
> iuwtURI).asJava).setShell(true).build()
> val iuwtImageInfo =
> Image.newBuilder().setType(Image.Type.DOCKER).setDocker(Image.Docker.newBuilder.setName("ubuntu-
> mesos:0.11-17102016-IUWT").build()).build()
> val iuwtContInfo =
> ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
> val iuwtContainer = ContainerInfo.newBuilder()
> .setMesos(iuwtContInfo)
> .setType(ContainerInfo.Type.MESOS)
> .build()
> val iuwtExecutor = ExecutorInfo.newBuilder()
> .setCommand(iuwtCommand)
> .setContainer(iuwtContainer)
>
> .setExecutorId(ExecutorID.newBuilder().setValue("iuwt-executor"))
> .setName("iuwt-executor").build()
> My executor then downloads some additional data and then tries to launch the
> application with the input data. Unfortunately, the application fails to
> launch because "exec: error while loading shared libraries: libtiff.so.5:
> cannot open shared object file: No such file or directory". I've attached
> logs showing libtiff.so.5 is both in /usr/lib/x86_64-linux-gnu, but also in
> /usr/lib.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6404) My program cannot access a .so file while being run with mesos containerization on a docker image.
[
https://issues.apache.org/jira/browse/MESOS-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583252#comment-15583252
]
Mark Hammons commented on MESOS-6404:
-
I do not use rm in the original docker file, but I do use apt-get remove and my
current docker image is made based off commits that have had rm in them I'm
pretty sure. Would that be related?
> My program cannot access a .so file while being run with mesos
> containerization on a docker image.
> --
>
> Key: MESOS-6404
> URL: https://issues.apache.org/jira/browse/MESOS-6404
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: CentOS Linux release 7.2.1511 (Core)
>Reporter: Mark Hammons
>Priority: Minor
> Attachments: IUWT_140926aR_t000_ch00.log
>
>
> I have an application compiled within a docker environment called
> ubuntu-mesos:0.11-17102016-IUWT. I've defined the executor for said
> application with the following code:
> val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://***/
> IUWT.tar.gz").setExtract(true).setCache(false).build()
> val iuwtjURI = CommandInfo.URI.newBuilder().setValue("http://***/
> iuwtExecutor-assembly-0.1-
> SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> val iuwtExec = "java -jar iuwtExecutor-assembly-0.1-SNAPSHOT.jar -
> Xmx1024M -Xmx128M"
> val iuwtCommand =
> CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
> iuwtURI).asJava).setShell(true).build()
> val iuwtImageInfo =
> Image.newBuilder().setType(Image.Type.DOCKER).setDocker(Image.Docker.newBuilder.setName("ubuntu-
> mesos:0.11-17102016-IUWT").build()).build()
> val iuwtContInfo =
> ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
> val iuwtContainer = ContainerInfo.newBuilder()
> .setMesos(iuwtContInfo)
> .setType(ContainerInfo.Type.MESOS)
> .build()
> val iuwtExecutor = ExecutorInfo.newBuilder()
> .setCommand(iuwtCommand)
> .setContainer(iuwtContainer)
>
> .setExecutorId(ExecutorID.newBuilder().setValue("iuwt-executor"))
> .setName("iuwt-executor").build()
> My executor then downloads some additional data and then tries to launch the
> application with the input data. Unfortunately, the application fails to
> launch because "exec: error while loading shared libraries: libtiff.so.5:
> cannot open shared object file: No such file or directory". I've attached
> logs showing libtiff.so.5 is both in /usr/lib/x86_64-linux-gnu, but also in
> /usr/lib.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-6405) Benchmark call ingestion path on the Mesos master.
[ https://issues.apache.org/jira/browse/MESOS-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar reassigned MESOS-6405: - Assignee: Anand Mazumdar > Benchmark call ingestion path on the Mesos master. > -- > > Key: MESOS-6405 > URL: https://issues.apache.org/jira/browse/MESOS-6405 > Project: Mesos > Issue Type: Improvement >Reporter: Anand Mazumdar >Assignee: Anand Mazumdar >Priority: Critical > Labels: mesosphere > > [~drexin] reported on the user mailing > [list|http://mail-archives.apache.org/mod_mbox/mesos-user/201610.mbox/%3C6B42E374-9AB7--A315-A6558753E08B%40apple.com%3E] > that there seems to be a significant regression in performance on the call > ingestion path on the Mesos master wrt to the scheduler driver (v0 API). > We should create a benchmark to first get a sense of the numbers and then go > about fixing the performance issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6405) Benchmark call ingestion path on the Mesos master.
[ https://issues.apache.org/jira/browse/MESOS-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar updated MESOS-6405: -- Shepherd: Vinod Kone Sprint: Mesosphere Sprint 45 Story Points: 3 Labels: mesosphere (was: ) > Benchmark call ingestion path on the Mesos master. > -- > > Key: MESOS-6405 > URL: https://issues.apache.org/jira/browse/MESOS-6405 > Project: Mesos > Issue Type: Improvement >Reporter: Anand Mazumdar >Assignee: Anand Mazumdar >Priority: Critical > Labels: mesosphere > > [~drexin] reported on the user mailing > [list|http://mail-archives.apache.org/mod_mbox/mesos-user/201610.mbox/%3C6B42E374-9AB7--A315-A6558753E08B%40apple.com%3E] > that there seems to be a significant regression in performance on the call > ingestion path on the Mesos master wrt to the scheduler driver (v0 API). > We should create a benchmark to first get a sense of the numbers and then go > about fixing the performance issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4065) slave FD for ZK tcp connection leaked to executor process
[
https://issues.apache.org/jira/browse/MESOS-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583152#comment-15583152
]
Till Toenshoff commented on MESOS-4065:
---
So far noone seems to have taken any note of that issue within the Zookeeper
dev community.
> slave FD for ZK tcp connection leaked to executor process
> -
>
> Key: MESOS-4065
> URL: https://issues.apache.org/jira/browse/MESOS-4065
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.24.1, 0.25.0
>Reporter: James DeFelice
> Labels: mesosphere, security
>
> {code}
> core@ip-10-0-0-45 ~ $ ps auxwww|grep -e etcd
> root 1432 99.3 0.0 202420 12928 ?Rsl 21:32 13:51
> ./etcd-mesos-executor -log_dir=./
> root 1450 0.4 0.1 38332 28752 ?Sl 21:32 0:03 ./etcd
> --data-dir=etcd_data --name=etcd-1449178273
> --listen-peer-urls=http://10.0.0.45:1025
> --initial-advertise-peer-urls=http://10.0.0.45:1025
> --listen-client-urls=http://10.0.0.45:1026
> --advertise-client-urls=http://10.0.0.45:1026
> --initial-cluster=etcd-1449178273=http://10.0.0.45:1025,etcd-1449178271=http://10.0.2.95:1025,etcd-1449178272=http://10.0.2.216:1025
> --initial-cluster-state=existing
> core 1651 0.0 0.0 6740 928 pts/0S+ 21:46 0:00 grep
> --colour=auto -e etcd
> core@ip-10-0-0-45 ~ $ sudo lsof -p 1432|grep -e 2181
> etcd-meso 1432 root 10u IPv4 21973 0t0TCP
> ip-10-0-0-45.us-west-2.compute.internal:54016->ip-10-0-5-206.us-west-2.compute.internal:2181
> (ESTABLISHED)
> core@ip-10-0-0-45 ~ $ ps auxwww|grep -e slave
> root 1124 0.2 0.1 900496 25736 ?Ssl 21:11 0:04
> /opt/mesosphere/packages/mesos--52cbecde74638029c3ba0ac5e5ab81df8debf0fa/sbin/mesos-slave
> core 1658 0.0 0.0 6740 832 pts/0S+ 21:46 0:00 grep
> --colour=auto -e slave
> core@ip-10-0-0-45 ~ $ sudo lsof -p 1124|grep -e 2181
> mesos-sla 1124 root 10u IPv4 21973 0t0TCP
> ip-10-0-0-45.us-west-2.compute.internal:54016->ip-10-0-5-206.us-west-2.compute.internal:2181
> (ESTABLISHED)
> {code}
> I only tested against mesos 0.24.1 and 0.25.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6406) Send latest status for partition-aware tasks when agent reregisters
Neil Conway created MESOS-6406: -- Summary: Send latest status for partition-aware tasks when agent reregisters Key: MESOS-6406 URL: https://issues.apache.org/jira/browse/MESOS-6406 Project: Mesos Issue Type: Bug Components: general Reporter: Neil Conway Assignee: Neil Conway When an agent reregisters, we should notify frameworks about the current status of any partition-aware tasks that were/are running on the agent -- i.e., report the current state of the task at the agent to the framework. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5344) Partition-aware Mesos frameworks.
[
https://issues.apache.org/jira/browse/MESOS-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Conway updated MESOS-5344:
---
Description:
This epic covers three related tasks:
1. Allowing partitioned agents to reregister with the master. This allows
frameworks to control how tasks running on partitioned agents should be dealt
with.
2. Replacing the TASK_LOST task state with a set of more granular states with
more precise semantics: UNREACHABLE, DROPPED, UNKNOWN, GONE, and
GONE_BY_OPERATOR.
3. Allow frameworks to be informed when a task that was running on a
partitioned agent has been terminated (GONE and GONE_BY_OPERATOR states).
These new behaviors will be guarded by the {{PARTITION_AWARE}} framework
capability.
This epic contains the features that landed in Mesos 1.1; remaining work is in
MESOS-6394.
was:
This epic covers three related tasks:
1. Allowing partitioned agents to reregister with the master. This allows
frameworks to control how tasks running on partitioned agents should be dealt
with.
2. Replacing the TASK_LOST task state with a set of more granular states with
more precise semantics: UNREACHABLE, DROPPED, UNKNOWN, GONE, and
GONE_BY_OPERATOR.
3. Allow frameworks to be informed when a task that was running on a
partitioned agent has been terminated (GONE and GONE_BY_OPERATOR states).
These new behaviors will be guarded by the {{PARTITION_AWARE}} framework
capability.
> Partition-aware Mesos frameworks.
> -
>
> Key: MESOS-5344
> URL: https://issues.apache.org/jira/browse/MESOS-5344
> Project: Mesos
> Issue Type: Epic
> Components: master
>Reporter: Neil Conway
>Assignee: Neil Conway
>Priority: Blocker
> Labels: mesosphere
> Fix For: 1.1.0
>
>
> This epic covers three related tasks:
> 1. Allowing partitioned agents to reregister with the master. This allows
> frameworks to control how tasks running on partitioned agents should be dealt
> with.
> 2. Replacing the TASK_LOST task state with a set of more granular states with
> more precise semantics: UNREACHABLE, DROPPED, UNKNOWN, GONE, and
> GONE_BY_OPERATOR.
> 3. Allow frameworks to be informed when a task that was running on a
> partitioned agent has been terminated (GONE and GONE_BY_OPERATOR states).
> These new behaviors will be guarded by the {{PARTITION_AWARE}} framework
> capability.
> This epic contains the features that landed in Mesos 1.1; remaining work is
> in MESOS-6394.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6405) Benchmark call ingestion path on the Mesos master.
[ https://issues.apache.org/jira/browse/MESOS-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar updated MESOS-6405: -- Priority: Critical (was: Major) > Benchmark call ingestion path on the Mesos master. > -- > > Key: MESOS-6405 > URL: https://issues.apache.org/jira/browse/MESOS-6405 > Project: Mesos > Issue Type: Improvement >Reporter: Anand Mazumdar >Priority: Critical > > [~drexin] reported on the user mailing > [list|http://mail-archives.apache.org/mod_mbox/mesos-user/201610.mbox/%3C6B42E374-9AB7--A315-A6558753E08B%40apple.com%3E] > that there seems to be a significant regression in performance on the call > ingestion path on the Mesos master wrt to the scheduler driver (v0 API). > We should create a benchmark to first get a sense of the numbers and then go > about fixing the performance issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6405) Benchmark call ingestion path on the Mesos master.
Anand Mazumdar created MESOS-6405: - Summary: Benchmark call ingestion path on the Mesos master. Key: MESOS-6405 URL: https://issues.apache.org/jira/browse/MESOS-6405 Project: Mesos Issue Type: Improvement Reporter: Anand Mazumdar [~drexin] reported on the user mailing [list|http://mail-archives.apache.org/mod_mbox/mesos-user/201610.mbox/%3C6B42E374-9AB7--A315-A6558753E08B%40apple.com%3E] that there seems to be a significant regression in performance on the call ingestion path on the Mesos master wrt to the scheduler driver (v0 API). We should create a benchmark to first get a sense of the numbers and then go about fixing the performance issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6404) My program cannot access a .so file while being run with mesos containerization on a docker image.
[
https://issues.apache.org/jira/browse/MESOS-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582640#comment-15582640
]
Jie Yu commented on MESOS-6404:
---
Does your Dockerfile has 'rm' (deletion of files)?
There is a known issue related to whiteout handling, which we're fixing right
now.
> My program cannot access a .so file while being run with mesos
> containerization on a docker image.
> --
>
> Key: MESOS-6404
> URL: https://issues.apache.org/jira/browse/MESOS-6404
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: CentOS Linux release 7.2.1511 (Core)
>Reporter: Mark Hammons
>Priority: Minor
> Attachments: IUWT_140926aR_t000_ch00.log
>
>
> I have an application compiled within a docker environment called
> ubuntu-mesos:0.11-17102016-IUWT. I've defined the executor for said
> application with the following code:
> val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://***/
> IUWT.tar.gz").setExtract(true).setCache(false).build()
> val iuwtjURI = CommandInfo.URI.newBuilder().setValue("http://***/
> iuwtExecutor-assembly-0.1-
> SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> val iuwtExec = "java -jar iuwtExecutor-assembly-0.1-SNAPSHOT.jar -
> Xmx1024M -Xmx128M"
> val iuwtCommand =
> CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
> iuwtURI).asJava).setShell(true).build()
> val iuwtImageInfo =
> Image.newBuilder().setType(Image.Type.DOCKER).setDocker(Image.Docker.newBuilder.setName("ubuntu-
> mesos:0.11-17102016-IUWT").build()).build()
> val iuwtContInfo =
> ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
> val iuwtContainer = ContainerInfo.newBuilder()
> .setMesos(iuwtContInfo)
> .setType(ContainerInfo.Type.MESOS)
> .build()
> val iuwtExecutor = ExecutorInfo.newBuilder()
> .setCommand(iuwtCommand)
> .setContainer(iuwtContainer)
>
> .setExecutorId(ExecutorID.newBuilder().setValue("iuwt-executor"))
> .setName("iuwt-executor").build()
> My executor then downloads some additional data and then tries to launch the
> application with the input data. Unfortunately, the application fails to
> launch because "exec: error while loading shared libraries: libtiff.so.5:
> cannot open shared object file: No such file or directory". I've attached
> logs showing libtiff.so.5 is both in /usr/lib/x86_64-linux-gnu, but also in
> /usr/lib.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6404) My program cannot access a .so file while being run with mesos containerization on a docker image.
[
https://issues.apache.org/jira/browse/MESOS-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hammons updated MESOS-6404:
Attachment: IUWT_140926aR_t000_ch00.log
> My program cannot access a .so file while being run with mesos
> containerization on a docker image.
> --
>
> Key: MESOS-6404
> URL: https://issues.apache.org/jira/browse/MESOS-6404
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: CentOS Linux release 7.2.1511 (Core)
>Reporter: Mark Hammons
>Priority: Minor
> Attachments: IUWT_140926aR_t000_ch00.log
>
>
> I have an application compiled within a docker environment called
> ubuntu-mesos:0.11-17102016-IUWT. I've defined the executor for said
> application with the following code:
> val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://***/
> IUWT.tar.gz").setExtract(true).setCache(false).build()
> val iuwtjURI = CommandInfo.URI.newBuilder().setValue("http://***/
> iuwtExecutor-assembly-0.1-
> SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> val iuwtExec = "java -jar iuwtExecutor-assembly-0.1-SNAPSHOT.jar -
> Xmx1024M -Xmx128M"
> val iuwtCommand =
> CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
> iuwtURI).asJava).setShell(true).build()
> val iuwtImageInfo =
> Image.newBuilder().setType(Image.Type.DOCKER).setDocker(Image.Docker.newBuilder.setName("ubuntu-
> mesos:0.11-17102016-IUWT").build()).build()
> val iuwtContInfo =
> ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
> val iuwtContainer = ContainerInfo.newBuilder()
> .setMesos(iuwtContInfo)
> .setType(ContainerInfo.Type.MESOS)
> .build()
> val iuwtExecutor = ExecutorInfo.newBuilder()
> .setCommand(iuwtCommand)
> .setContainer(iuwtContainer)
>
> .setExecutorId(ExecutorID.newBuilder().setValue("iuwt-executor"))
> .setName("iuwt-executor").build()
> My executor then downloads some additional data and then tries to launch the
> application with the input data. Unfortunately, the application fails to
> launch because "exec: error while loading shared libraries: libtiff.so.5:
> cannot open shared object file: No such file or directory". I've attached
> logs showing libtiff.so.5 is both in /usr/lib/x86_64-linux-gnu, but also in
> /usr/lib.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6404) My program cannot access a .so file while being run with mesos containerization on a docker image.
Mark Hammons created MESOS-6404:
---
Summary: My program cannot access a .so file while being run with
mesos containerization on a docker image.
Key: MESOS-6404
URL: https://issues.apache.org/jira/browse/MESOS-6404
Project: Mesos
Issue Type: Bug
Affects Versions: 1.0.1
Environment: CentOS Linux release 7.2.1511 (Core)
Reporter: Mark Hammons
Priority: Minor
Attachments: IUWT_140926aR_t000_ch00.vtk.gz(2).log
I have an application compiled within a docker environment called
ubuntu-mesos:0.11-17102016-IUWT. I've defined the executor for said application
with the following code:
val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://***/
IUWT.tar.gz").setExtract(true).setCache(false).build()
val iuwtjURI = CommandInfo.URI.newBuilder().setValue("http://***/
iuwtExecutor-assembly-0.1-
SNAPSHOT.jar").setExecutable(false).setCache(false).build()
val iuwtExec = "java -jar iuwtExecutor-assembly-0.1-SNAPSHOT.jar -
Xmx1024M -Xmx128M"
val iuwtCommand =
CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
iuwtURI).asJava).setShell(true).build()
val iuwtImageInfo =
Image.newBuilder().setType(Image.Type.DOCKER).setDocker(Image.Docker.newBuilder.setName("ubuntu-
mesos:0.11-17102016-IUWT").build()).build()
val iuwtContInfo =
ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
val iuwtContainer = ContainerInfo.newBuilder()
.setMesos(iuwtContInfo)
.setType(ContainerInfo.Type.MESOS)
.build()
val iuwtExecutor = ExecutorInfo.newBuilder()
.setCommand(iuwtCommand)
.setContainer(iuwtContainer)
.setExecutorId(ExecutorID.newBuilder().setValue("iuwt-executor"))
.setName("iuwt-executor").build()
My executor then downloads some additional data and then tries to launch the
application with the input data. Unfortunately, the application fails to launch
because "exec: error while loading shared libraries: libtiff.so.5: cannot open
shared object file: No such file or directory". I've attached logs showing
libtiff.so.5 is both in /usr/lib/x86_64-linux-gnu, but also in /usr/lib.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6404) My program cannot access a .so file while being run with mesos containerization on a docker image.
[
https://issues.apache.org/jira/browse/MESOS-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hammons updated MESOS-6404:
Attachment: (was: IUWT_140926aR_t000_ch00.vtk.gz(2).log)
> My program cannot access a .so file while being run with mesos
> containerization on a docker image.
> --
>
> Key: MESOS-6404
> URL: https://issues.apache.org/jira/browse/MESOS-6404
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: CentOS Linux release 7.2.1511 (Core)
>Reporter: Mark Hammons
>Priority: Minor
>
> I have an application compiled within a docker environment called
> ubuntu-mesos:0.11-17102016-IUWT. I've defined the executor for said
> application with the following code:
> val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://***/
> IUWT.tar.gz").setExtract(true).setCache(false).build()
> val iuwtjURI = CommandInfo.URI.newBuilder().setValue("http://***/
> iuwtExecutor-assembly-0.1-
> SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> val iuwtExec = "java -jar iuwtExecutor-assembly-0.1-SNAPSHOT.jar -
> Xmx1024M -Xmx128M"
> val iuwtCommand =
> CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
> iuwtURI).asJava).setShell(true).build()
> val iuwtImageInfo =
> Image.newBuilder().setType(Image.Type.DOCKER).setDocker(Image.Docker.newBuilder.setName("ubuntu-
> mesos:0.11-17102016-IUWT").build()).build()
> val iuwtContInfo =
> ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
> val iuwtContainer = ContainerInfo.newBuilder()
> .setMesos(iuwtContInfo)
> .setType(ContainerInfo.Type.MESOS)
> .build()
> val iuwtExecutor = ExecutorInfo.newBuilder()
> .setCommand(iuwtCommand)
> .setContainer(iuwtContainer)
>
> .setExecutorId(ExecutorID.newBuilder().setValue("iuwt-executor"))
> .setName("iuwt-executor").build()
> My executor then downloads some additional data and then tries to launch the
> application with the input data. Unfortunately, the application fails to
> launch because "exec: error while loading shared libraries: libtiff.so.5:
> cannot open shared object file: No such file or directory". I've attached
> logs showing libtiff.so.5 is both in /usr/lib/x86_64-linux-gnu, but also in
> /usr/lib.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6404) My program cannot access a .so file while being run with mesos containerization on a docker image.
[
https://issues.apache.org/jira/browse/MESOS-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hammons updated MESOS-6404:
Attachment: IUWT_140926aR_t000_ch00.vtk.gz(2).log
> My program cannot access a .so file while being run with mesos
> containerization on a docker image.
> --
>
> Key: MESOS-6404
> URL: https://issues.apache.org/jira/browse/MESOS-6404
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: CentOS Linux release 7.2.1511 (Core)
>Reporter: Mark Hammons
>Priority: Minor
> Attachments: IUWT_140926aR_t000_ch00.vtk.gz(2).log
>
>
> I have an application compiled within a docker environment called
> ubuntu-mesos:0.11-17102016-IUWT. I've defined the executor for said
> application with the following code:
> val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://***/
> IUWT.tar.gz").setExtract(true).setCache(false).build()
> val iuwtjURI = CommandInfo.URI.newBuilder().setValue("http://***/
> iuwtExecutor-assembly-0.1-
> SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> val iuwtExec = "java -jar iuwtExecutor-assembly-0.1-SNAPSHOT.jar -
> Xmx1024M -Xmx128M"
> val iuwtCommand =
> CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
> iuwtURI).asJava).setShell(true).build()
> val iuwtImageInfo =
> Image.newBuilder().setType(Image.Type.DOCKER).setDocker(Image.Docker.newBuilder.setName("ubuntu-
> mesos:0.11-17102016-IUWT").build()).build()
> val iuwtContInfo =
> ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
> val iuwtContainer = ContainerInfo.newBuilder()
> .setMesos(iuwtContInfo)
> .setType(ContainerInfo.Type.MESOS)
> .build()
> val iuwtExecutor = ExecutorInfo.newBuilder()
> .setCommand(iuwtCommand)
> .setContainer(iuwtContainer)
>
> .setExecutorId(ExecutorID.newBuilder().setValue("iuwt-executor"))
> .setName("iuwt-executor").build()
> My executor then downloads some additional data and then tries to launch the
> application with the input data. Unfortunately, the application fails to
> launch because "exec: error while loading shared libraries: libtiff.so.5:
> cannot open shared object file: No such file or directory". I've attached
> logs showing libtiff.so.5 is both in /usr/lib/x86_64-linux-gnu, but also in
> /usr/lib.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6403) Draft design doc for rlimit support for Mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-6403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bannier updated MESOS-6403: Sprint: Mesosphere Sprint 45 > Draft design doc for rlimit support for Mesos containerizer > --- > > Key: MESOS-6403 > URL: https://issues.apache.org/jira/browse/MESOS-6403 > Project: Mesos > Issue Type: Task >Reporter: Benjamin Bannier >Assignee: Benjamin Bannier > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6402) Add rlimit support to Mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bannier updated MESOS-6402: Component/s: containerization > Add rlimit support to Mesos containerizer > - > > Key: MESOS-6402 > URL: https://issues.apache.org/jira/browse/MESOS-6402 > Project: Mesos > Issue Type: Epic > Components: containerization >Reporter: Benjamin Bannier >Assignee: Benjamin Bannier > > We should allow containers to expose their rlimit requirements so that their > environment can be set up via Mesos abstractions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6403) Draft design doc for rlimit support for Mesos containerizer
Benjamin Bannier created MESOS-6403: --- Summary: Draft design doc for rlimit support for Mesos containerizer Key: MESOS-6403 URL: https://issues.apache.org/jira/browse/MESOS-6403 Project: Mesos Issue Type: Task Reporter: Benjamin Bannier Assignee: Benjamin Bannier -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6402) Add rlimit support to Mesos containerizer
Benjamin Bannier created MESOS-6402: --- Summary: Add rlimit support to Mesos containerizer Key: MESOS-6402 URL: https://issues.apache.org/jira/browse/MESOS-6402 Project: Mesos Issue Type: Epic Reporter: Benjamin Bannier Assignee: Benjamin Bannier We should allow containers to expose their rlimit requirements so that their environment can be set up via Mesos abstractions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6393) Deprecated SSL_ environment variables are non functional already.
[
https://issues.apache.org/jira/browse/MESOS-6393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-6393:
--
Fix Version/s: 1.0.2
> Deprecated SSL_ environment variables are non functional already.
> -
>
> Key: MESOS-6393
> URL: https://issues.apache.org/jira/browse/MESOS-6393
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.0.2, 1.1.0
>Reporter: Till Toenshoff
>Assignee: Till Toenshoff
>Priority: Blocker
> Labels: SSL, libprocess, security
> Fix For: 1.0.2, 1.1.0
>
>
> {noformat}
> $ SSL_ENABLED=true SSL_SUPPORT_DOWNGRADE=true
> SSL_KEY_FILE=~/Development/ssl/snakeoil.key
> SSL_CERT_FILE=~/Development/ssl/snakeoil.crt ./bin/mesos-master.sh
> --work_dir=/tmp/mesos
> {noformat}
> {noformat}
> $ curl -k https://127.0.0.1:5050/master/state.json
> curl: (35) Server aborted the SSL handshake
> {noformat}
> Only when using the new prefix, {{LIBPROCESS_SSL}} are the variables actually
> being respected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6401) Authorizer interface should behave more uniform
[
https://issues.apache.org/jira/browse/MESOS-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rojas updated MESOS-6401:
---
Issue Type: Improvement (was: Bug)
> Authorizer interface should behave more uniform
> ---
>
> Key: MESOS-6401
> URL: https://issues.apache.org/jira/browse/MESOS-6401
> Project: Mesos
> Issue Type: Improvement
>Reporter: Alexander Rojas
>Assignee: Alexander Rojas
>
> As currently implemented, the Authorizer interface distinguish between two
> types of authorizations, those suffixed with either {{_WITH_PRINCIPAL}} and
> {{_WITH_ROLE}} and almost all other actions. While the former expect a single
> value to perform authorization, the latter allow for multiple fields based on
> whole protobuf messages.
> Since protobuf messages are associated with almost all authorization actions
> (exceptions are {{VIEW_ROLES}} and {{GET_ENDPOINT_WITH_PATH}}, it makes sense
> to standardize the way authorization is performed by using protobuf messages
> for all actions that have one available.
> This will also help module writers which desire to create complex rules when
> an action can be performed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6401) Authorizer interface should behave more uniform
Alexander Rojas created MESOS-6401:
--
Summary: Authorizer interface should behave more uniform
Key: MESOS-6401
URL: https://issues.apache.org/jira/browse/MESOS-6401
Project: Mesos
Issue Type: Bug
Reporter: Alexander Rojas
Assignee: Alexander Rojas
As currently implemented, the Authorizer interface distinguish between two
types of authorizations, those suffixed with either {{_WITH_PRINCIPAL}} and
{{_WITH_ROLE}} and almost all other actions. While the former expect a single
value to perform authorization, the latter allow for multiple fields based on
whole protobuf messages.
Since protobuf messages are associated with almost all authorization actions
(exceptions are {{VIEW_ROLES}} and {{GET_ENDPOINT_WITH_PATH}}, it makes sense
to standardize the way authorization is performed by using protobuf messages
for all actions that have one available.
This will also help module writers which desire to create complex rules when an
action can be performed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3335) FlagsBase copy-ctor leads to dangling pointer.
[
https://issues.apache.org/jira/browse/MESOS-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15581776#comment-15581776
]
Michael Park commented on MESOS-3335:
-
{noformat}
commit 82c520eb0d83710e3f0ed4514348f893c2b44455
Author: Benjamin Bannier
Date: Fri Oct 14 18:56:07 2016 -0400
Consistently used virtual inheritance for Flags classes in mesos.
In order for different `Flags` classes to be composable classes should
always use virtual inheritance.
Review: https://reviews.apache.org/r/49829/
{noformat}
{noformat}
commit bb903381fa8b98c1f16bd8af69c727d501ba99e9
Author: Benjamin Bannier
Date: Fri Oct 14 18:56:04 2016 -0400
Consistently used virtual inheritance for Flags classes in libprocess.
In order for different `Flags` classes to be composable classes should
always use virtual inheritance.
Review: https://reviews.apache.org/r/52387/
{noformat}
{noformat}
commit 16914ae87b999223e26d63415b56d5aca4bf8b2b
Author: Benjamin Bannier
Date: Fri Oct 14 18:56:02 2016 -0400
Consistently used virtual inheritance for Flags classes in stout.
In order for different `Flags` classes to be composable classes should
always use virtual inheritance.
Review: https://reviews.apache.org/r/49833/
{noformat}
{noformat}
commit 5d491eb77a9268feaec0587e79808e7805907317
Author: Benjamin Bannier
Date: Mon Oct 17 05:33:17 2016 -0400
Deleted potentially implicitly generated functions.
Here we explicitly disable rvalue constructors and assignment
operators for `flags::FlagsBase` since we plan for this class to be
used in virtual inheritance scenarios. Here e.g., constructing from
an rvalue will be problematic since we can potentially have multiple
lineages leading to the same base class, and could then potentially
use a moved from base object.
These functions would be implicitly generated only for C++14, but in
C++11 only the versions taking lvalue references should be. GCC seems
to create all of these even in C++11 mode so we need to explicitly
disable them.
Review: https://reviews.apache.org/r/52386/
{noformat}
{noformat}
commit da2aa2c14796b64b19002b86b3b6b9a443479ba8
Author: Benjamin Bannier
Date: Fri Oct 14 18:55:55 2016 -0400
Removed `flags::Flags` helper template.
The template `flags::Flags` allowed to compose flags classes on the
fly, e.g.,
flags::Flags flags;
which would create a class inheriting virtually from both `MyFlags1`
and `MyFlags2`.
This class was not used in the code.
Review: https://reviews.apache.org/r/52604/
{noformat}
> FlagsBase copy-ctor leads to dangling pointer.
> --
>
> Key: MESOS-3335
> URL: https://issues.apache.org/jira/browse/MESOS-3335
> Project: Mesos
> Issue Type: Bug
>Reporter: Neil Conway
>Assignee: Benjamin Bannier
> Labels: mesosphere
> Attachments: lambda_capture_bug.cpp
>
>
> Per [#3328], ubsan detects the following problem:
> [ RUN ] FaultToleranceTest.ReregisterCompletedFrameworks
> /mesos/3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp:303:25:
> runtime error: load of value 33, which is not a valid value for type 'bool'
> I believe what is going on here is the following:
> * The test calls StartMaster(), which does MesosTest::CreateMasterFlags()
> * MesosTest::CreateMasterFlags() allocates a new master::Flags on the stack,
> which is subsequently copy-constructed back to StartMaster()
> * The FlagsBase constructor is:
> bq. {{FlagsBase() { add(, "help", "...", false); }}}
> where "help" is a member variable -- i.e., it is allocated on the stack in
> this case.
> * {{FlagsBase()::add}} captures {{}}, e.g.:
> {noformat}
> flag.stringify = [t1](const FlagsBase&) -> Option {
> return stringify(*t1);
> };}}
> {noformat}
> * The implicit copy constructor for FlagsBase is just going to copy the
> lambda above, i.e., the result of the copy constructor will have a lambda
> that points into MesosTest::CreateMasterFlags()'s stack frame, which is bad
> news.
> Not sure the right fix -- comments welcome. You could define a copy-ctor for
> FlagsBase that does something gross (basically remove the old help flag and
> define a new one that points into the target of the copy), but that seems,
> well, gross.
> Probably not a pressing-problem to fix -- AFAICS worst symptom is that we end
> up reading one byte from some random stack location when serving
> {{state.json}}, for example.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-6357) `NestedMesosContainerizerTest.ROOT_CGROUPS_ParentExit` is flaky in Debian 8.
[
https://issues.apache.org/jira/browse/MESOS-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15581706#comment-15581706
]
Benjamin Bannier edited comment on MESOS-6357 at 10/17/16 9:33 AM:
---
The test code looks innocent to me, and makes me wonder if this is a true race
in the {{mesos-containerizer}}.
[~klueska] [~benjaminhindman]
was (Author: bbannier):
The test code looks innocent to me, and makes me wonder if this a true race in
the {{mesos-containerizer}}.
[~klueska] [~benjaminhindman]
> `NestedMesosContainerizerTest.ROOT_CGROUPS_ParentExit` is flaky in Debian 8.
>
>
> Key: MESOS-6357
> URL: https://issues.apache.org/jira/browse/MESOS-6357
> Project: Mesos
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.1.0
> Environment: Debian 8 with SSL enabled
>Reporter: Gilbert Song
> Labels: flaky-test
>
> {noformat}
> [00:21:51] : [Step 10/10] [ RUN ]
> NestedMesosContainerizerTest.ROOT_CGROUPS_ParentExit
> [00:21:51]W: [Step 10/10] I1008 00:21:51.357839 23530
> containerizer.cpp:202] Using isolation:
> cgroups/cpu,filesystem/linux,namespaces/pid,network/cni,volume/image
> [00:21:51]W: [Step 10/10] I1008 00:21:51.361143 23530
> linux_launcher.cpp:150] Using /sys/fs/cgroup/freezer as the freezer hierarchy
> for the Linux launcher
> [00:21:51]W: [Step 10/10] I1008 00:21:51.366930 23547
> containerizer.cpp:557] Recovering containerizer
> [00:21:51]W: [Step 10/10] I1008 00:21:51.367962 23551 provisioner.cpp:253]
> Provisioner recovery complete
> [00:21:51]W: [Step 10/10] I1008 00:21:51.368253 23549
> containerizer.cpp:954] Starting container
> 42589936-56b2-4e41-86d8-447bfaba4666 for executor 'executor' of framework
> [00:21:51]W: [Step 10/10] I1008 00:21:51.368577 23548 cgroups.cpp:404]
> Creating cgroup at
> '/sys/fs/cgroup/cpu,cpuacct/mesos_test_458f8018-67e7-4cc6-8126-a535974db35d/42589936-56b2-4e41-86d8-447bfaba4666'
> for container 42589936-56b2-4e41-86d8-447bfaba4666
> [00:21:51]W: [Step 10/10] I1008 00:21:51.369863 23544 cpu.cpp:103] Updated
> 'cpu.shares' to 1024 (cpus 1) for container
> 42589936-56b2-4e41-86d8-447bfaba4666
> [00:21:51]W: [Step 10/10] I1008 00:21:51.370384 23545
> containerizer.cpp:1443] Launching 'mesos-containerizer' with flags
> '--command="{"shell":true,"value":"read key <&30"}" --help="false"
> --pipe_read="30" --pipe_write="34"
> --pre_exec_commands="[{"arguments":["mesos-containerizer","mount","--help=false","--operation=make-rslave","--path=\/"],"shell":false,"value":"\/mnt\/teamcity\/work\/4240ba9ddd0997c3\/build\/src\/mesos-containerizer"},{"shell":true,"value":"mount
> -n -t proc proc \/proc -o nosuid,noexec,nodev"}]"
> --runtime_directory="/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_sEbtvQ/containers/42589936-56b2-4e41-86d8-447bfaba4666"
> --unshare_namespace_mnt="false"
> --working_directory="/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_MqjHi0"'
> [00:21:51]W: [Step 10/10] I1008 00:21:51.370483 23544
> linux_launcher.cpp:421] Launching container
> 42589936-56b2-4e41-86d8-447bfaba4666 and cloning with namespaces CLONE_NEWNS
> | CLONE_NEWPID
> [00:21:51]W: [Step 10/10] I1008 00:21:51.374867 23545
> containerizer.cpp:1480] Checkpointing container's forked pid 14139 to
> '/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_gzjeKG/meta/slaves/frameworks/executors/executor/runs/42589936-56b2-4e41-86d8-447bfaba4666/pids/forked.pid'
> [00:21:51]W: [Step 10/10] I1008 00:21:51.376519 23551
> containerizer.cpp:1648] Starting nested container
> 42589936-56b2-4e41-86d8-447bfaba4666.a5bc9913-c32c-40c6-ab78-2b08910847f8
> [00:21:51]W: [Step 10/10] I1008 00:21:51.377296 23549
> containerizer.cpp:1443] Launching 'mesos-containerizer' with flags
> '--command="{"shell":true,"value":"sleep 1000"}" --help="false"
> --pipe_read="30" --pipe_write="34"
> --pre_exec_commands="[{"arguments":["mesos-containerizer","mount","--help=false","--operation=make-rslave","--path=\/"],"shell":false,"value":"\/mnt\/teamcity\/work\/4240ba9ddd0997c3\/build\/src\/mesos-containerizer"},{"shell":true,"value":"mount
> -n -t proc proc \/proc -o nosuid,noexec,nodev"}]"
> --runtime_directory="/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_sEbtvQ/containers/42589936-56b2-4e41-86d8-447bfaba4666/containers/a5bc9913-c32c-40c6-ab78-2b08910847f8"
> --unshare_namespace_mnt="false"
> --working_directory="/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_MqjHi0/containers/a5bc9913-c32c-40c6-ab78-2b08910847f8"'
> [00:21:51]W: [Step 10/10] I1008 00:21:51.377424 23548
> linux_launcher.cpp:421] Launching nested
[jira] [Commented] (MESOS-6357) `NestedMesosContainerizerTest.ROOT_CGROUPS_ParentExit` is flaky in Debian 8.
[
https://issues.apache.org/jira/browse/MESOS-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15581706#comment-15581706
]
Benjamin Bannier commented on MESOS-6357:
-
The test code looks innocent to me, and makes me wonder if this a true race in
the {{mesos-containerizer}}.
[~klueska] [~benjaminhindman]
> `NestedMesosContainerizerTest.ROOT_CGROUPS_ParentExit` is flaky in Debian 8.
>
>
> Key: MESOS-6357
> URL: https://issues.apache.org/jira/browse/MESOS-6357
> Project: Mesos
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.1.0
> Environment: Debian 8 with SSL enabled
>Reporter: Gilbert Song
> Labels: flaky-test
>
> {noformat}
> [00:21:51] : [Step 10/10] [ RUN ]
> NestedMesosContainerizerTest.ROOT_CGROUPS_ParentExit
> [00:21:51]W: [Step 10/10] I1008 00:21:51.357839 23530
> containerizer.cpp:202] Using isolation:
> cgroups/cpu,filesystem/linux,namespaces/pid,network/cni,volume/image
> [00:21:51]W: [Step 10/10] I1008 00:21:51.361143 23530
> linux_launcher.cpp:150] Using /sys/fs/cgroup/freezer as the freezer hierarchy
> for the Linux launcher
> [00:21:51]W: [Step 10/10] I1008 00:21:51.366930 23547
> containerizer.cpp:557] Recovering containerizer
> [00:21:51]W: [Step 10/10] I1008 00:21:51.367962 23551 provisioner.cpp:253]
> Provisioner recovery complete
> [00:21:51]W: [Step 10/10] I1008 00:21:51.368253 23549
> containerizer.cpp:954] Starting container
> 42589936-56b2-4e41-86d8-447bfaba4666 for executor 'executor' of framework
> [00:21:51]W: [Step 10/10] I1008 00:21:51.368577 23548 cgroups.cpp:404]
> Creating cgroup at
> '/sys/fs/cgroup/cpu,cpuacct/mesos_test_458f8018-67e7-4cc6-8126-a535974db35d/42589936-56b2-4e41-86d8-447bfaba4666'
> for container 42589936-56b2-4e41-86d8-447bfaba4666
> [00:21:51]W: [Step 10/10] I1008 00:21:51.369863 23544 cpu.cpp:103] Updated
> 'cpu.shares' to 1024 (cpus 1) for container
> 42589936-56b2-4e41-86d8-447bfaba4666
> [00:21:51]W: [Step 10/10] I1008 00:21:51.370384 23545
> containerizer.cpp:1443] Launching 'mesos-containerizer' with flags
> '--command="{"shell":true,"value":"read key <&30"}" --help="false"
> --pipe_read="30" --pipe_write="34"
> --pre_exec_commands="[{"arguments":["mesos-containerizer","mount","--help=false","--operation=make-rslave","--path=\/"],"shell":false,"value":"\/mnt\/teamcity\/work\/4240ba9ddd0997c3\/build\/src\/mesos-containerizer"},{"shell":true,"value":"mount
> -n -t proc proc \/proc -o nosuid,noexec,nodev"}]"
> --runtime_directory="/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_sEbtvQ/containers/42589936-56b2-4e41-86d8-447bfaba4666"
> --unshare_namespace_mnt="false"
> --working_directory="/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_MqjHi0"'
> [00:21:51]W: [Step 10/10] I1008 00:21:51.370483 23544
> linux_launcher.cpp:421] Launching container
> 42589936-56b2-4e41-86d8-447bfaba4666 and cloning with namespaces CLONE_NEWNS
> | CLONE_NEWPID
> [00:21:51]W: [Step 10/10] I1008 00:21:51.374867 23545
> containerizer.cpp:1480] Checkpointing container's forked pid 14139 to
> '/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_gzjeKG/meta/slaves/frameworks/executors/executor/runs/42589936-56b2-4e41-86d8-447bfaba4666/pids/forked.pid'
> [00:21:51]W: [Step 10/10] I1008 00:21:51.376519 23551
> containerizer.cpp:1648] Starting nested container
> 42589936-56b2-4e41-86d8-447bfaba4666.a5bc9913-c32c-40c6-ab78-2b08910847f8
> [00:21:51]W: [Step 10/10] I1008 00:21:51.377296 23549
> containerizer.cpp:1443] Launching 'mesos-containerizer' with flags
> '--command="{"shell":true,"value":"sleep 1000"}" --help="false"
> --pipe_read="30" --pipe_write="34"
> --pre_exec_commands="[{"arguments":["mesos-containerizer","mount","--help=false","--operation=make-rslave","--path=\/"],"shell":false,"value":"\/mnt\/teamcity\/work\/4240ba9ddd0997c3\/build\/src\/mesos-containerizer"},{"shell":true,"value":"mount
> -n -t proc proc \/proc -o nosuid,noexec,nodev"}]"
> --runtime_directory="/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_sEbtvQ/containers/42589936-56b2-4e41-86d8-447bfaba4666/containers/a5bc9913-c32c-40c6-ab78-2b08910847f8"
> --unshare_namespace_mnt="false"
> --working_directory="/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_MqjHi0/containers/a5bc9913-c32c-40c6-ab78-2b08910847f8"'
> [00:21:51]W: [Step 10/10] I1008 00:21:51.377424 23548
> linux_launcher.cpp:421] Launching nested container
> 42589936-56b2-4e41-86d8-447bfaba4666.a5bc9913-c32c-40c6-ab78-2b08910847f8 and
> cloning with namespaces CLONE_NEWNS | CLONE_NEWPID
> [00:21:51] : [Step 10/10] Executing pre-exec command
>
[jira] [Updated] (MESOS-6357) `NestedMesosContainerizerTest.ROOT_CGROUPS_ParentExit` is flaky in Debian 8.
[
https://issues.apache.org/jira/browse/MESOS-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bannier updated MESOS-6357:
Affects Version/s: 1.1.0
> `NestedMesosContainerizerTest.ROOT_CGROUPS_ParentExit` is flaky in Debian 8.
>
>
> Key: MESOS-6357
> URL: https://issues.apache.org/jira/browse/MESOS-6357
> Project: Mesos
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.1.0
> Environment: Debian 8 with SSL enabled
>Reporter: Gilbert Song
> Labels: flaky-test
>
> {noformat}
> [00:21:51] : [Step 10/10] [ RUN ]
> NestedMesosContainerizerTest.ROOT_CGROUPS_ParentExit
> [00:21:51]W: [Step 10/10] I1008 00:21:51.357839 23530
> containerizer.cpp:202] Using isolation:
> cgroups/cpu,filesystem/linux,namespaces/pid,network/cni,volume/image
> [00:21:51]W: [Step 10/10] I1008 00:21:51.361143 23530
> linux_launcher.cpp:150] Using /sys/fs/cgroup/freezer as the freezer hierarchy
> for the Linux launcher
> [00:21:51]W: [Step 10/10] I1008 00:21:51.366930 23547
> containerizer.cpp:557] Recovering containerizer
> [00:21:51]W: [Step 10/10] I1008 00:21:51.367962 23551 provisioner.cpp:253]
> Provisioner recovery complete
> [00:21:51]W: [Step 10/10] I1008 00:21:51.368253 23549
> containerizer.cpp:954] Starting container
> 42589936-56b2-4e41-86d8-447bfaba4666 for executor 'executor' of framework
> [00:21:51]W: [Step 10/10] I1008 00:21:51.368577 23548 cgroups.cpp:404]
> Creating cgroup at
> '/sys/fs/cgroup/cpu,cpuacct/mesos_test_458f8018-67e7-4cc6-8126-a535974db35d/42589936-56b2-4e41-86d8-447bfaba4666'
> for container 42589936-56b2-4e41-86d8-447bfaba4666
> [00:21:51]W: [Step 10/10] I1008 00:21:51.369863 23544 cpu.cpp:103] Updated
> 'cpu.shares' to 1024 (cpus 1) for container
> 42589936-56b2-4e41-86d8-447bfaba4666
> [00:21:51]W: [Step 10/10] I1008 00:21:51.370384 23545
> containerizer.cpp:1443] Launching 'mesos-containerizer' with flags
> '--command="{"shell":true,"value":"read key <&30"}" --help="false"
> --pipe_read="30" --pipe_write="34"
> --pre_exec_commands="[{"arguments":["mesos-containerizer","mount","--help=false","--operation=make-rslave","--path=\/"],"shell":false,"value":"\/mnt\/teamcity\/work\/4240ba9ddd0997c3\/build\/src\/mesos-containerizer"},{"shell":true,"value":"mount
> -n -t proc proc \/proc -o nosuid,noexec,nodev"}]"
> --runtime_directory="/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_sEbtvQ/containers/42589936-56b2-4e41-86d8-447bfaba4666"
> --unshare_namespace_mnt="false"
> --working_directory="/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_MqjHi0"'
> [00:21:51]W: [Step 10/10] I1008 00:21:51.370483 23544
> linux_launcher.cpp:421] Launching container
> 42589936-56b2-4e41-86d8-447bfaba4666 and cloning with namespaces CLONE_NEWNS
> | CLONE_NEWPID
> [00:21:51]W: [Step 10/10] I1008 00:21:51.374867 23545
> containerizer.cpp:1480] Checkpointing container's forked pid 14139 to
> '/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_gzjeKG/meta/slaves/frameworks/executors/executor/runs/42589936-56b2-4e41-86d8-447bfaba4666/pids/forked.pid'
> [00:21:51]W: [Step 10/10] I1008 00:21:51.376519 23551
> containerizer.cpp:1648] Starting nested container
> 42589936-56b2-4e41-86d8-447bfaba4666.a5bc9913-c32c-40c6-ab78-2b08910847f8
> [00:21:51]W: [Step 10/10] I1008 00:21:51.377296 23549
> containerizer.cpp:1443] Launching 'mesos-containerizer' with flags
> '--command="{"shell":true,"value":"sleep 1000"}" --help="false"
> --pipe_read="30" --pipe_write="34"
> --pre_exec_commands="[{"arguments":["mesos-containerizer","mount","--help=false","--operation=make-rslave","--path=\/"],"shell":false,"value":"\/mnt\/teamcity\/work\/4240ba9ddd0997c3\/build\/src\/mesos-containerizer"},{"shell":true,"value":"mount
> -n -t proc proc \/proc -o nosuid,noexec,nodev"}]"
> --runtime_directory="/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_sEbtvQ/containers/42589936-56b2-4e41-86d8-447bfaba4666/containers/a5bc9913-c32c-40c6-ab78-2b08910847f8"
> --unshare_namespace_mnt="false"
> --working_directory="/mnt/teamcity/temp/buildTmp/NestedMesosContainerizerTest_ROOT_CGROUPS_ParentExit_MqjHi0/containers/a5bc9913-c32c-40c6-ab78-2b08910847f8"'
> [00:21:51]W: [Step 10/10] I1008 00:21:51.377424 23548
> linux_launcher.cpp:421] Launching nested container
> 42589936-56b2-4e41-86d8-447bfaba4666.a5bc9913-c32c-40c6-ab78-2b08910847f8 and
> cloning with namespaces CLONE_NEWNS | CLONE_NEWPID
> [00:21:51] : [Step 10/10] Executing pre-exec command
>
[jira] [Updated] (MESOS-6376) Add documentation for capabilities support of the mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-6376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-6376: --- Target Version/s: 1.2.0 (was: 1.1.0) Priority: Major (was: Blocker) > Add documentation for capabilities support of the mesos containerizer > - > > Key: MESOS-6376 > URL: https://issues.apache.org/jira/browse/MESOS-6376 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Benjamin Bannier >Assignee: Benjamin Bannier > Labels: mesosphere > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
