[jira] [Commented] (MESOS-6213) Build failure on macOS Sierra: Protobuf atomics deprecated.
[
https://issues.apache.org/jira/browse/MESOS-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627854#comment-15627854
]
Tim Harper commented on MESOS-6213:
---
As a workaround, you can run {{make CPPFLAGS="-Wno-deprecated-declarations"}}
> Build failure on macOS Sierra: Protobuf atomics deprecated.
> ---
>
> Key: MESOS-6213
> URL: https://issues.apache.org/jira/browse/MESOS-6213
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: Charles Allen
>
> Building on OSX is giving the following error.
> {code}
> In file included from
> ../3rdparty/protobuf-2.6.1/src/google/protobuf/stubs/atomicops.h:184:
> ../3rdparty/protobuf-2.6.1/src/google/protobuf/stubs/atomicops_internals_macosx.h:173:9:
> error: 'OSAtomicCompareAndSwap64Barrier' is deprecated: first
> deprecated in macOS 10.12 - Use std::atomic_compare_exchange_strong()
> from instead [-Werror,-Wdeprecated-declarations]
> if (OSAtomicCompareAndSwap64Barrier(
> ^
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/libkern/OSAtomicDeprecated.h:645:9:
> note:
> 'OSAtomicCompareAndSwap64Barrier' has been explicitly marked deprecated
> here
> boolOSAtomicCompareAndSwap64Barrier( int64_t __oldValue, int64_t
> __newValue,
> ^
> {code}
> Protobuf is not listed as a component so I just set it as {{build}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5662) Call parent class `SetUpTestCase` function in our test fixtures.
[
https://issues.apache.org/jira/browse/MESOS-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627820#comment-15627820
]
Manuwela Kanade commented on MESOS-5662:
Hi [~anandmazumdar]: Created a pull request for this:
https://reviews.apache.org/r/53372/
> Call parent class `SetUpTestCase` function in our test fixtures.
>
>
> Key: MESOS-5662
> URL: https://issues.apache.org/jira/browse/MESOS-5662
> Project: Mesos
> Issue Type: Bug
> Components: test
>Reporter: Anand Mazumdar
>Assignee: Manuwela Kanade
> Labels: mesosphere, newbie
>
> There are some occurrences in our code where we don't invoke the parent's
> {{SetUpTestCase}} method from a child test fixture. This can be a bit
> problematic if someone adds the method in the parent class sometime in the
> future. It would be good to do a sweep across the code and explicitly invoke
> the parent class's method.
> Some examples (there are more):
> https://github.com/apache/mesos/blob/master/src/tests/mesos.cpp#L80
> https://github.com/apache/mesos/blob/master/src/tests/module_tests.cpp#L59
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-6489) Better support for containers that want to manage their own cgroup.
[ https://issues.apache.org/jira/browse/MESOS-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anindya Sinha reassigned MESOS-6489: Assignee: Anindya Sinha > Better support for containers that want to manage their own cgroup. > --- > > Key: MESOS-6489 > URL: https://issues.apache.org/jira/browse/MESOS-6489 > Project: Mesos > Issue Type: Improvement > Components: cgroups >Reporter: Jie Yu >Assignee: Anindya Sinha > Labels: cgroups > > Some containers want to manage their cgroup by sub-dividing the cgroup that > Mesos allocates to them into multiple sub-cgroups and put subprocess into the > corresponding sub-cgroups. > For instance, someone wants to run Docker daemon in a Mesos container. Docker > daemon will manage the cgroup assigned to it by Mesos (with the help , for > example, cgroups namespace). > Problems arise during the teardown of the container because two entities > might be manipulating the same cgroup simultaneously. For example, the Mesos > cgroups::destroy might fail if the task running inside is trying to delete > the same nested cgroup at the same time. > To support that case, we should consider kill all the processes in the Mesos > cgroup first, making sure that no one will be creating sub-cgroups and moving > new processes into sub-cgroups. And then, destroy the cgroups recursively. > And we need freezer because we want to make sure all processes are stopped > while we are sending kill signals to avoid TOCTTOU race problem. I think it > makes more sense to freezer the cgroups (and sub-cgroups) from top down > (rather than bottom up because typically, processes in the parent cgroup > manipulate sub-cgroups). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6523) Agent cgroup assignment should precede agent initialization.
[ https://issues.apache.org/jira/browse/MESOS-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anindya Sinha updated MESOS-6523: - Shepherd: Yan Xu > Agent cgroup assignment should precede agent initialization. > > > Key: MESOS-6523 > URL: https://issues.apache.org/jira/browse/MESOS-6523 > Project: Mesos > Issue Type: Improvement > Components: cgroups >Reporter: Anindya Sinha >Assignee: Anindya Sinha >Priority: Minor > Labels: cgroups, initialization > > If mesos-slave is launched with agent_subsystems flag, it would be preferred > to move the agent process to its own cgroup for all the subsystems before the > mesos-slave starts accepting traffic, ie. before port 5051 is opened up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2952) Provide user namespaces for privileged access inside containers
[ https://issues.apache.org/jira/browse/MESOS-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627630#comment-15627630 ] Aaron Wood commented on MESOS-2952: --- This would be great to have. If there's anything I can help with please let me know! > Provide user namespaces for privileged access inside containers > --- > > Key: MESOS-2952 > URL: https://issues.apache.org/jira/browse/MESOS-2952 > Project: Mesos > Issue Type: Epic >Reporter: Paul Brett >Assignee: Vaibhav Khanduja > > User namespaces allow per-namespace mappings of user and group IDs. This > means that a process's user and group IDs inside a user namespace can be > different from its IDs outside of the namespace. Most notably, a process can > have a nonzero user ID outside a namespace while at the same time having a > user ID of zero inside the namespace; in other words, the process is > unprivileged for operations outside the user namespace but has root > privileges inside the namespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6518) Mesos dashboard: Symlinks not displayed in sandbox view
[ https://issues.apache.org/jira/browse/MESOS-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627612#comment-15627612 ] haosdent commented on MESOS-6518: - Hi, [~Makman2] It is expected behaviour. Because you execute symbol links in the docker container. Those symbol links only valid in the docker container. Although those symbol links exist in the host, but their target files are invalid. So Mesos would filter them out and don't display them in WebUI. > Mesos dashboard: Symlinks not displayed in sandbox view > --- > > Key: MESOS-6518 > URL: https://issues.apache.org/jira/browse/MESOS-6518 > Project: Mesos > Issue Type: Improvement > Components: webui >Reporter: Mischa Krüger >Assignee: haosdent >Priority: Minor > Attachments: sandbox.png, tmp.png > > > Soft symbolic links do not appear in the sandbox, though they exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-6530) Add support for incremental gzip decompression.
[
https://issues.apache.org/jira/browse/MESOS-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler reassigned MESOS-6530:
--
Assignee: Benjamin Mahler
> Add support for incremental gzip decompression.
> ---
>
> Key: MESOS-6530
> URL: https://issues.apache.org/jira/browse/MESOS-6530
> Project: Mesos
> Issue Type: Improvement
> Components: stout
>Reporter: Benjamin Mahler
>Assignee: Benjamin Mahler
>
> We currently only support compressing and decompressing based on the entire
> input being available at once. We can add a {{gzip::Decompressor}} to support
> incremental decompression.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6531) Add support for incremental gzip compression.
Benjamin Mahler created MESOS-6531:
--
Summary: Add support for incremental gzip compression.
Key: MESOS-6531
URL: https://issues.apache.org/jira/browse/MESOS-6531
Project: Mesos
Issue Type: Improvement
Components: stout
Reporter: Benjamin Mahler
We currently only support compression / decompression assuming the entire input
is available at once. We can add a {{gzip::Compressor}} to support incremental
compression.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6530) Add support for incremental gzip decompression.
Benjamin Mahler created MESOS-6530:
--
Summary: Add support for incremental gzip decompression.
Key: MESOS-6530
URL: https://issues.apache.org/jira/browse/MESOS-6530
Project: Mesos
Issue Type: Improvement
Components: stout
Reporter: Benjamin Mahler
We currently only support compressing and decompressing based on the entire
input being available at once. We can add a {{gzip::Decompressor}} to support
incremental decompression.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6522) Ability to set global maximum executor runtime for an agent
[ https://issues.apache.org/jira/browse/MESOS-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627454#comment-15627454 ] Benjamin Mahler commented on MESOS-6522: The current thinking w.r.t. to maintenance is that we ask for resources back from the schedulers (via inverse offers). Schedulers know the deadline and should co-operate with these requests. Once the maintenance window begins, the operator could force the draining of the agent but this will potentially cause SLA violations or data loss if the maintenance is destructive. Because of this, we'd like the operator to make this call. Also worth noting that it is to be expected that some attempts to do maintenance do not succeed since they would have led to SLA violations for the frameworks, or data loss in the case of destructive maintenance. In these cases the operator can follow up on the "stragglers" with a more suitable maintenance plan. A maximum executor lifetime is interesting in that it forces churn in the cluster, but it would make it very difficult to implement certain classes of workloads (e.g. data storage) and I suspect it would frustrate framework developers since they have no control over it. In general we try to give control to the frameworks, since only they understand the workload. > Ability to set global maximum executor runtime for an agent > --- > > Key: MESOS-6522 > URL: https://issues.apache.org/jira/browse/MESOS-6522 > Project: Mesos > Issue Type: Improvement > Components: slave >Reporter: Will Rouesnel >Priority: Minor > > With the developing concept of agent maintenance mode, it would be nice to > have some blunt-force ability to reason about the behavior of agents on > uncooperative frameworks. > Ideally there would be a new parameter --executor_maximum_lifetime which > would specify a maximum duration for which *any* executor on an agent can run > before being terminated. > Even when using persistent schedulers such as Marathon, the ability to > enforce reasonable gurantees about when an agent's tasks definitely must end > can help contribute to keeping the cluster turning over and prevent nodes > becoming "special" or jammed up with jobs which will not end. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6526) `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
[
https://issues.apache.org/jira/browse/MESOS-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627299#comment-15627299
]
Jie Yu commented on MESOS-6526:
---
That will be great! I can help review the code. Thanks!
> `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
> -
>
> Key: MESOS-6526
> URL: https://issues.apache.org/jira/browse/MESOS-6526
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.1.0
>Reporter: Yan Xu
>Priority: Critical
>
> With MESOS-6323, the helper {{mesos-containerizer launch}} takes a
> `--environment` flag for the env vars used by the executor. This is
> unpleasant because its a common practice that people use env vars to hide
> configs that are sensitive and now it's visible to non-root users on the host
> with a {{ps}} command.
> Given that we want to separate the environments of {{mesos-containerizer
> launch}} and the executor itself, perhaps we can just package and serialize
> the executor env vars in one env var {{MESOS_EXECUTOR_ENVIRONMENT}} and pass
> that to {{mesos-containerizer launch}} which could then get it through a flag
> the usual way.
> In general Mesos should do more to protect env vars but I'll file separate
> issues for them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-6526) `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
[
https://issues.apache.org/jira/browse/MESOS-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627289#comment-15627289
]
Yan Xu edited comment on MESOS-6526 at 11/2/16 1:24 AM:
Will you guys be able to get to this one soon? If not we can pick it up.
was (Author: xujyan):
Will you guys able to get to this one soon? If not we can pick it up.
> `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
> -
>
> Key: MESOS-6526
> URL: https://issues.apache.org/jira/browse/MESOS-6526
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.1.0
>Reporter: Yan Xu
>Priority: Critical
>
> With MESOS-6323, the helper {{mesos-containerizer launch}} takes a
> `--environment` flag for the env vars used by the executor. This is
> unpleasant because its a common practice that people use env vars to hide
> configs that are sensitive and now it's visible to non-root users on the host
> with a {{ps}} command.
> Given that we want to separate the environments of {{mesos-containerizer
> launch}} and the executor itself, perhaps we can just package and serialize
> the executor env vars in one env var {{MESOS_EXECUTOR_ENVIRONMENT}} and pass
> that to {{mesos-containerizer launch}} which could then get it through a flag
> the usual way.
> In general Mesos should do more to protect env vars but I'll file separate
> issues for them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6526) `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
[
https://issues.apache.org/jira/browse/MESOS-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627289#comment-15627289
]
Yan Xu commented on MESOS-6526:
---
Will you guys able to get to this one soon? If not we can pick it up.
> `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
> -
>
> Key: MESOS-6526
> URL: https://issues.apache.org/jira/browse/MESOS-6526
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.1.0
>Reporter: Yan Xu
>Priority: Critical
>
> With MESOS-6323, the helper {{mesos-containerizer launch}} takes a
> `--environment` flag for the env vars used by the executor. This is
> unpleasant because its a common practice that people use env vars to hide
> configs that are sensitive and now it's visible to non-root users on the host
> with a {{ps}} command.
> Given that we want to separate the environments of {{mesos-containerizer
> launch}} and the executor itself, perhaps we can just package and serialize
> the executor env vars in one env var {{MESOS_EXECUTOR_ENVIRONMENT}} and pass
> that to {{mesos-containerizer launch}} which could then get it through a flag
> the usual way.
> In general Mesos should do more to protect env vars but I'll file separate
> issues for them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6526) `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
[
https://issues.apache.org/jira/browse/MESOS-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627278#comment-15627278
]
Yan Xu commented on MESOS-6526:
---
Cool. Yeah you are right, what would you suggest?
{{MESOS_COMMAND_ENVIRONMENT}}? (Since it's all commands and there's a --command
flag to go with it)
> `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
> -
>
> Key: MESOS-6526
> URL: https://issues.apache.org/jira/browse/MESOS-6526
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.1.0
>Reporter: Yan Xu
>Priority: Critical
>
> With MESOS-6323, the helper {{mesos-containerizer launch}} takes a
> `--environment` flag for the env vars used by the executor. This is
> unpleasant because its a common practice that people use env vars to hide
> configs that are sensitive and now it's visible to non-root users on the host
> with a {{ps}} command.
> Given that we want to separate the environments of {{mesos-containerizer
> launch}} and the executor itself, perhaps we can just package and serialize
> the executor env vars in one env var {{MESOS_EXECUTOR_ENVIRONMENT}} and pass
> that to {{mesos-containerizer launch}} which could then get it through a flag
> the usual way.
> In general Mesos should do more to protect env vars but I'll file separate
> issues for them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6529) Support ZFS sandbox isolation
Will Rouesnel created MESOS-6529: Summary: Support ZFS sandbox isolation Key: MESOS-6529 URL: https://issues.apache.org/jira/browse/MESOS-6529 Project: Mesos Issue Type: Improvement Components: containerization Reporter: Will Rouesnel Priority: Minor ZFS has excellent support for filesystem quotas under Linux/BSD operating systems. It would be good to support to support isolating workloads on separate ZFS filesystems that are dynamically created when the task is executed, and which could have disk quotas properly and invidually enforced. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6527) Memory leak in the libprocess request decoder.
[
https://issues.apache.org/jira/browse/MESOS-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-6527:
---
Target Version/s: 0.28.3, 1.0.2, 1.1.0 (was: 0.28.3, 1.0.2, 1.1.1)
> Memory leak in the libprocess request decoder.
> --
>
> Key: MESOS-6527
> URL: https://issues.apache.org/jira/browse/MESOS-6527
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Anand Mazumdar
>Assignee: Anand Mazumdar
>Priority: Blocker
> Labels: mesosphere
>
> The libprocess decoder can leak a {{Request}} object in cases when a client
> disconnects while the request is in progress. In such cases, the decoder's
> destructor won't delete the active {{Request}} object that it had allocated
> on the heap.
> https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/decoder.hpp#L271
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6280) Task group executor should support command health checks.
[ https://issues.apache.org/jira/browse/MESOS-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-6280: --- Issue Type: Improvement (was: Bug) > Task group executor should support command health checks. > - > > Key: MESOS-6280 > URL: https://issues.apache.org/jira/browse/MESOS-6280 > Project: Mesos > Issue Type: Improvement >Reporter: Alexander Rukletsov >Priority: Critical > Labels: mesosphere > > Currently, the default (aka pod) executor supports only HTTP and TCP health > checks. We should also support command health checks as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3039) Allow executors binding IP to be different than Slave binding IP.
[ https://issues.apache.org/jira/browse/MESOS-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-3039: --- Issue Type: Improvement (was: Bug) Summary: Allow executors binding IP to be different than Slave binding IP. (was: Allow executors binding IP to be different than Slave binding IP) > Allow executors binding IP to be different than Slave binding IP. > - > > Key: MESOS-3039 > URL: https://issues.apache.org/jira/browse/MESOS-3039 > Project: Mesos > Issue Type: Improvement >Reporter: Kapil Arya >Assignee: Kapil Arya >Priority: Critical > Labels: mesosphere > > Currently, the Slave will bind either to the loopback IP (127.0.0.1) or to > the IP passed via the '--ip' flag. When it launches a containerized executor > (e.g, via Mesos Containerizer), the executor inherits the binding IP of the > Slave. This is due to the fact that the '--ip' flags sets the environment > variable `LIBPROCESS_IP` to the passed IP. The executor then inherits this > environment variable and is forced to bind to the Slave IP. > If an executor is running in its own containerized environment, with a > separate IP than that of the Slave, currently there is no way of forcing it > to bind to its own IP. A potential solution is to use the executor > environment decorator hooks to update LIBPROCESS_IP environment variable for > the executor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3000) Failing test - NsTest.ROOT_setns
[
https://issues.apache.org/jira/browse/MESOS-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-3000:
---
Priority: Major (was: Blocker)
> Failing test - NsTest.ROOT_setns
>
>
> Key: MESOS-3000
> URL: https://issues.apache.org/jira/browse/MESOS-3000
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.23.0
>Reporter: Ian Downes
>Assignee: Chris Lambert
>
> Appears to be the same issue plaguing MESOS-2199
> {noformat}
> [root@hostname build]# MESOS_VERBOSE=1 ./bin/mesos-tests.sh
> --gtest_filter=NsTest.ROOT_setns
> ...
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from NsTest
> [ RUN ] NsTest.ROOT_setns
> ABORT: (../../../3rdparty/libprocess/src/subprocess.cpp:163): Failed to
> os::execvpe in childMain: Permission denied*** Aborted at 1436292540 (unix
> time) try "date -d @1436292540" if you are using GNU date ***
> PC: @ 0x7f7a1229e625 __GI_raise
> *** SIGABRT (@0xfffe0001) received by PID 1 (TID 0x7f7a19afc820) from PID
> 1; stack trace: ***
> @ 0x7f7a13421710 (unknown)
> @ 0x7f7a1229e625 __GI_raise
> @ 0x7f7a1229fe05 __GI_abort
> @ 0x860ba1 (unknown)
> @ 0x860bcf (unknown)
> @ 0x7f7a1826f118 (unknown)
> @ 0x7f7a18274594 (unknown)
> @ 0x7f7a18273b88 (unknown)
> @ 0x7f7a18273098 (unknown)
> @ 0x1180720 (unknown)
> @ 0x117a5d7 (unknown)
> @ 0x7f7a123548fd clone
> ../../src/tests/ns_tests.cpp:121: Failure
> Failed to wait 15secs for status
> [ FAILED ] NsTest.ROOT_setns (15004 ms)
> [--] 1 test from NsTest (15004 ms total)
> [--] Global test environment tear-down
> ../../src/tests/environment.cpp:441: Failure
> Failed
> Tests completed with child processes remaining:
> -+- 40531 /home/idownes/workspace/mesos/build/src/.libs/lt-mesos-tests
> --gtest_filter=NsTest.ROOT_setns
> \--- 40565 /home/idownes/workspace/mesos/build/src/.libs/lt-mesos-tests
> --gtest_filter=NsTest.ROOT_setns
> [==] 1 test from 1 test case ran. (15034 ms total)
> [ PASSED ] 0 tests.
> [ FAILED ] 1 test, listed below:
> [ FAILED ] NsTest.ROOT_setns
> {noformat}
> Relevant strace for the forked child:
> {noformat}
> ...
> getpid()= 1
> dup2(6, 0) = 0
> dup2(7, 1) = 1
> dup2(8, 2) = 2
> close(6) = 0
> close(7) = 0
> close(8) = 0
> execve("/home/idownes/workspace/mesos/build/src/setns-test-helper",
> ["setns-test-helper", "SetnsTestHelper"], [/* 24 vars */]) = -1 EACCES
> (Permission denied)
> write(2, "ABORT: (../../../3rdparty/libpro"..., 62) = 62
> write(2, "Failed to os::execvpe in childMa"..., 53) = 53
> ...
> {noformat}
> Binary that it's trying to exec:
> {noformat}
> [root@hostname build]# stat
> /home/idownes/workspace/mesos/build/src/setns-test-helper
> File: `/home/idownes/workspace/mesos/build/src/setns-test-helper'
> Size: 7948Blocks: 16 IO Block: 4096 regular file
> Device: 801h/2049d Inode: 22949249Links: 1
> Access: (0755/-rwxr-xr-x) Uid: (13118/ idownes) Gid: ( 1500/employee)
> Access: 2015-07-07 17:58:09.569861237 +
> Modify: 2015-07-07 17:58:09.573861290 +
> Change: 2015-07-07 17:58:09.573861290 +
> [root@hostname build]#
> /home/idownes/workspace/mesos/build/src/setns-test-helper
> Usage: /home/idownes/workspace/mesos/build/src/.libs/lt-setns-test-helper
> [OPTIONS]
> Available subcommands:
> help
> SetnsTestHelper
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2759) Could not create MesosContainerizer: Could not create isolator network/port_mapping: Routing library check failed: Capability ROUTE_LINK_VETH_GET_PEER_OWN_REFERENCE is no
[ https://issues.apache.org/jira/browse/MESOS-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-2759: --- Target Version/s: 0.22.1, 0.22.0 (was: 0.22.0, 0.22.1) Priority: Major (was: Critical) > Could not create MesosContainerizer: Could not create isolator > network/port_mapping: Routing library check failed: Capability > ROUTE_LINK_VETH_GET_PEER_OWN_REFERENCE is not available > - > > Key: MESOS-2759 > URL: https://issues.apache.org/jira/browse/MESOS-2759 > Project: Mesos > Issue Type: Bug >Reporter: Anuj Gupta > > [root@localhost ~]# mesos-slave --master=127.0.0.1:5050 > --log_dir=/var/log/mesos --work_dir=/var/lib/mesos > --isolation=cgroups/cpu,cgroups/mem,network/port_mapping > --resources=ephemeral_ports:[32768-57344] --ephemeral_ports_per_container=1024 > mesos-slave: /usr/lib64/libnl-3.so.200: no version information available > (required by /usr/local/lib/libmesos-0.22.0.so) > mesos-slave: /usr/lib64/libnl-route-3.so.200: no version information > available (required by /usr/local/lib/libmesos-0.22.0.so) > mesos-slave: /usr/lib64/libnl-3.so.200: no version information available > (required by /lib/libnl-idiag-3.so.200) > I0521 14:10:16.727126 13214 logging.cpp:172] INFO level logging started! > I0521 14:10:16.727409 13214 main.cpp:156] Build: 2015-05-21 13:21:45 by root > I0521 14:10:16.727432 13214 main.cpp:158] Version: 0.22.0 > I0521 14:10:16.727727 13214 containerizer.cpp:110] Using isolation: > cgroups/cpu,cgroups/mem,network/port_mapping > Failed to create a containerizer: Could not create MesosContainerizer: Could > not create isolator network/port_mapping: Routing library check failed: > Capability ROUTE_LINK_VETH_GET_PEER_OWN_REFERENCE is not available -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2828) Refactor 'model' functions and use JSON::Protobuf instead
[
https://issues.apache.org/jira/browse/MESOS-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-2828:
---
Priority: Major (was: Critical)
Issue Type: Improvement (was: Bug)
> Refactor 'model' functions and use JSON::Protobuf instead
> -
>
> Key: MESOS-2828
> URL: https://issues.apache.org/jira/browse/MESOS-2828
> Project: Mesos
> Issue Type: Improvement
>Reporter: Alexander Rojas
> Labels: mesosphere
>
> The current patter used to serialize objects returned by endpoints requieres
> the use of a {{model}} function which receives the object to be serialized
> and returns a JSON object. (See slave.cpp and master.cpp).
> If possible, it would be better to use JSON::Protobuf to serialize protocol
> buffer objects, and if possible to write a jsonfy function similar to
> stringify.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1547) option --cgroups_enable_cfs - not working on Oracle Linux
[ https://issues.apache.org/jira/browse/MESOS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-1547: --- Priority: Major (was: Critical) > option --cgroups_enable_cfs - not working on Oracle Linux > -- > > Key: MESOS-1547 > URL: https://issues.apache.org/jira/browse/MESOS-1547 > Project: Mesos > Issue Type: Bug > Components: isolation >Affects Versions: 0.19.0 > Environment: Oracle Enterprise Linux - version > 2.6.39-400.215.3.el6uek.x86_64 >Reporter: Umesh Batra > > I am not able to make option "cgroups_enable_cfs" work with OEL? > > Couple of posts that I came across talks about, rebuilding the kernel with a > different configuration. > > Appreciate, if you can confirm or guide me on the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1256) Enable running all existing containerizer tests with different containerizer implementations.
[ https://issues.apache.org/jira/browse/MESOS-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-1256: --- Priority: Major (was: Critical) Issue Type: Improvement (was: Bug) > Enable running all existing containerizer tests with different containerizer > implementations. > - > > Key: MESOS-1256 > URL: https://issues.apache.org/jira/browse/MESOS-1256 > Project: Mesos > Issue Type: Improvement > Components: slave, test >Reporter: Benjamin Hindman > > Right now the tests get run with the MesosContainerizer but they should > really be pluggable so that new containerizer implementations can be plugged > in directly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-6528) Container status of a task in a pod is not correct.
[ https://issues.apache.org/jira/browse/MESOS-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu reassigned MESOS-6528: - Assignee: Jie Yu > Container status of a task in a pod is not correct. > --- > > Key: MESOS-6528 > URL: https://issues.apache.org/jira/browse/MESOS-6528 > Project: Mesos > Issue Type: Bug > Components: containerization, slave >Affects Versions: 1.1.0 >Reporter: Jie Yu >Assignee: Jie Yu > Labels: mesosphere > > Currently, the container status is for the top level executor container. This > is not ideal. Ideally, we should get the container status for the > corresponding nested container and report that with the task status update. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6528) Container status of a task in a pod is not correct.
[ https://issues.apache.org/jira/browse/MESOS-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-6528: -- Component/s: slave containerization > Container status of a task in a pod is not correct. > --- > > Key: MESOS-6528 > URL: https://issues.apache.org/jira/browse/MESOS-6528 > Project: Mesos > Issue Type: Bug > Components: containerization, slave >Affects Versions: 1.1.0 >Reporter: Jie Yu > Labels: mesosphere > > Currently, the container status is for the top level executor container. This > is not ideal. Ideally, we should get the container status for the > corresponding nested container and report that with the task status update. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6528) Container status of a task in a pod is not correct.
[ https://issues.apache.org/jira/browse/MESOS-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-6528: -- Affects Version/s: 1.1.0 > Container status of a task in a pod is not correct. > --- > > Key: MESOS-6528 > URL: https://issues.apache.org/jira/browse/MESOS-6528 > Project: Mesos > Issue Type: Bug > Components: containerization, slave >Affects Versions: 1.1.0 >Reporter: Jie Yu > Labels: mesosphere > > Currently, the container status is for the top level executor container. This > is not ideal. Ideally, we should get the container status for the > corresponding nested container and report that with the task status update. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6528) Container status of a task in a pod is not correct.
Jie Yu created MESOS-6528: - Summary: Container status of a task in a pod is not correct. Key: MESOS-6528 URL: https://issues.apache.org/jira/browse/MESOS-6528 Project: Mesos Issue Type: Bug Reporter: Jie Yu Currently, the container status is for the top level executor container. This is not ideal. Ideally, we should get the container status for the corresponding nested container and report that with the task status update. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6528) Container status of a task in a pod is not correct.
[ https://issues.apache.org/jira/browse/MESOS-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-6528: -- Labels: mesosphere (was: ) > Container status of a task in a pod is not correct. > --- > > Key: MESOS-6528 > URL: https://issues.apache.org/jira/browse/MESOS-6528 > Project: Mesos > Issue Type: Bug > Components: containerization, slave >Affects Versions: 1.1.0 >Reporter: Jie Yu > Labels: mesosphere > > Currently, the container status is for the top level executor container. This > is not ideal. Ideally, we should get the container status for the > corresponding nested container and report that with the task status update. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6526) `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
[
https://issues.apache.org/jira/browse/MESOS-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627103#comment-15627103
]
Jie Yu commented on MESOS-6526:
---
Yeah, i think we can use environment variable to pass the environment
variables. I think we should not call it `MESOS_EXECUTOR_ENVIRONMENT` because
it can be used for launching nested containers as well. I would use a different
name.
> `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
> -
>
> Key: MESOS-6526
> URL: https://issues.apache.org/jira/browse/MESOS-6526
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.1.0
>Reporter: Yan Xu
>Priority: Critical
>
> With MESOS-6323, the helper {{mesos-containerizer launch}} takes a
> `--environment` flag for the env vars used by the executor. This is
> unpleasant because its a common practice that people use env vars to hide
> configs that are sensitive and now it's visible to non-root users on the host
> with a {{ps}} command.
> Given that we want to separate the environments of {{mesos-containerizer
> launch}} and the executor itself, perhaps we can just package and serialize
> the executor env vars in one env var {{MESOS_EXECUTOR_ENVIRONMENT}} and pass
> that to {{mesos-containerizer launch}} which could then get it through a flag
> the usual way.
> In general Mesos should do more to protect env vars but I'll file separate
> issues for them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6247) Enable Framework to set weight.
[ https://issues.apache.org/jira/browse/MESOS-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-6247: --- Priority: Major (was: Critical) Issue Type: Wish (was: Bug) Summary: Enable Framework to set weight. (was: Enable Framework to set weight) > Enable Framework to set weight. > --- > > Key: MESOS-6247 > URL: https://issues.apache.org/jira/browse/MESOS-6247 > Project: Mesos > Issue Type: Wish > Components: allocation > Environment: all >Reporter: Klaus Ma > > We'd like to enable framework's weight when it register. So the framework can > share resources based on weight within the same role. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2018) Dynamic Reservation
[
https://issues.apache.org/jira/browse/MESOS-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-2018:
---
Priority: Major (was: Critical)
> Dynamic Reservation
> ---
>
> Key: MESOS-2018
> URL: https://issues.apache.org/jira/browse/MESOS-2018
> Project: Mesos
> Issue Type: Epic
> Components: allocation, framework, master, slave
>Reporter: Adam B
>Assignee: Michael Park
> Labels: mesosphere, offer, persistence, reservations, resource,
> stateful, storage
>
> h3. Overview
> This is a feature to provide better support for running stateful services on
> Mesos such as HDFS (Distributed Filesystem), Cassandra (Distributed
> Database), or MySQL (Local Database).
> Current resource reservations (henceforth called "static" reservations) are
> statically determined by the slave operator at slave start time, and
> individual frameworks have no authority to reserve resources themselves.
> Dynamic reservations allow a framework to dynamically reserve offered
> resources, such that those resources will only be re-offered to the same
> framework (or other frameworks with the same role).
> This is especially useful if the framework's task stored some state on the
> slave, and needs a guaranteed set of resources reserved so that it can
> re-launch a task on the same slave to recover that state.
> h3. Planned Stages
> 1. MESOS-2489: Enable a framework to perform reservation operations.
> The goal of this stage is to allow the framework to send back a
> Reserve/Unreserve operation which gets validated by the master and updates
> the allocator resources. The allocator's {{allocate}} logic is left unchanged
> and the resources get offered back to the framework's role as desired.
> 2. MESOS-2491: Persist the reservation state on the slave.
> The goal of this stage is to persist the reservation state on the slave.
> Currently the master knows to store the persistent volumes in the
> {{checkpointedResources}} data structure which gets sent to individual slaves
> to be checkpointed. We will update the master such that dynamically reserved
> resources are stored in the {{checkpointedResources}} as well. This stage
> also involves subtasks such as updating the slave re(register) logic to
> support slave re-starts.
> 3. MESOS-2600: Introduce reservation HTTP endpoints on the master.
> The goal of this stage is to enable operators to perform reservation
> operations via HTTP endpoints on the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6527) Memory leak in the libprocess request decoder.
Anand Mazumdar created MESOS-6527:
-
Summary: Memory leak in the libprocess request decoder.
Key: MESOS-6527
URL: https://issues.apache.org/jira/browse/MESOS-6527
Project: Mesos
Issue Type: Bug
Components: libprocess
Reporter: Anand Mazumdar
Assignee: Anand Mazumdar
Priority: Blocker
The libprocess decoder can leak a {{Request}} object in cases when a client
disconnects while the request is in progress. In such cases, the decoder's
destructor won't delete the active {{Request}} object that it had allocated on
the heap.
https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/decoder.hpp#L271
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6526) `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
[
https://issues.apache.org/jira/browse/MESOS-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626946#comment-15626946
]
Yan Xu commented on MESOS-6526:
---
Fetcher does it in a similar way:
https://github.com/apache/mesos/blob/fdd9304c414cbd8cfc47f8d575315c539e55843f/src/slave/containerizer/fetcher.cpp#L826
> `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
> -
>
> Key: MESOS-6526
> URL: https://issues.apache.org/jira/browse/MESOS-6526
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.1.0
>Reporter: Yan Xu
>Priority: Critical
>
> With MESOS-6323, the helper {{mesos-containerizer launch}} takes a
> `--environment` flag for the env vars used by the executor. This is
> unpleasant because its a common practice that people use env vars to hide
> configs that are sensitive and now it's visible to non-root users on the host
> with a {{ps}} command.
> Given that we want to separate the environments of {{mesos-containerizer
> launch}} and the executor itself, perhaps we can just package and serialize
> the executor env vars in one env var {{MESOS_EXECUTOR_ENVIRONMENT}} and pass
> that to {{mesos-containerizer launch}} which could then get it through a flag
> the usual way.
> In general Mesos should do more to protect env vars but I'll file separate
> issues for them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6526) `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
[
https://issues.apache.org/jira/browse/MESOS-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626939#comment-15626939
]
Yan Xu commented on MESOS-6526:
---
I mean we can have one {{MESOS_EXECUTOR_ENVIRONMENT}} to contain the
{{JSON::Object}} that has all the env vars the executor is supposed to use.
If it's passed over from {{mesos-agent}} to {{mesos-containerizer}} as an
environment variable, it's not shown in {{ps}}. Since Mesos flags can load
flags from env vars, the code in {{launch.cpp}} doesn't have to change much: it
can still get it as if it was passed in {{argv}}.
> `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
> -
>
> Key: MESOS-6526
> URL: https://issues.apache.org/jira/browse/MESOS-6526
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.1.0
>Reporter: Yan Xu
>Priority: Critical
>
> With MESOS-6323, the helper {{mesos-containerizer launch}} takes a
> `--environment` flag for the env vars used by the executor. This is
> unpleasant because its a common practice that people use env vars to hide
> configs that are sensitive and now it's visible to non-root users on the host
> with a {{ps}} command.
> Given that we want to separate the environments of {{mesos-containerizer
> launch}} and the executor itself, perhaps we can just package and serialize
> the executor env vars in one env var {{MESOS_EXECUTOR_ENVIRONMENT}} and pass
> that to {{mesos-containerizer launch}} which could then get it through a flag
> the usual way.
> In general Mesos should do more to protect env vars but I'll file separate
> issues for them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6526) `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
[
https://issues.apache.org/jira/browse/MESOS-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626929#comment-15626929
]
Gilbert Song commented on MESOS-6526:
-
Thanks [~xujyan], could you elaborate a little bit about serializing the
executor env var into {MESOS_EXECUTOR_ENVIRONMENT}? Isn't it still exposed to
'ps'?
> `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
> -
>
> Key: MESOS-6526
> URL: https://issues.apache.org/jira/browse/MESOS-6526
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.1.0
>Reporter: Yan Xu
>Priority: Critical
>
> With MESOS-6323, the helper {{mesos-containerizer launch}} takes a
> `--environment` flag for the env vars used by the executor. This is
> unpleasant because its a common practice that people use env vars to hide
> configs that are sensitive and now it's visible to non-root users on the host
> with a {{ps}} command.
> Given that we want to separate the environments of {{mesos-containerizer
> launch}} and the executor itself, perhaps we can just package and serialize
> the executor env vars in one env var {{MESOS_EXECUTOR_ENVIRONMENT}} and pass
> that to {{mesos-containerizer launch}} which could then get it through a flag
> the usual way.
> In general Mesos should do more to protect env vars but I'll file separate
> issues for them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6526) `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
[
https://issues.apache.org/jira/browse/MESOS-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yan Xu updated MESOS-6526:
--
Description:
With MESOS-6323, the helper {{mesos-containerizer launch}} takes a
`--environment` flag for the env vars used by the executor. This is unpleasant
because its a common practice that people use env vars to hide configs that are
sensitive and now it's visible to non-root users on the host with a {{ps}}
command.
Given that we want to separate the environments of {{mesos-containerizer
launch}} and the executor itself, perhaps we can just package and serialize the
executor env vars in one env var {{MESOS_EXECUTOR_ENVIRONMENT}} and pass that
to {{mesos-containerizer launch}} which could then get it through a flag the
usual way.
In general Mesos should do more to protect env vars but I'll file separate
issues for them.
was:
With MESOS-6323, the helper {{mesos-containerizer launch}} takes a
`--environment` flag for the env vars used by the executor. This is unpleasant
because its a common practice that people use env vars to hide configs that are
sensitive and not it's visible to non-root users on the host with a {{ps}}
command.
Given that we want to separate the environments of {{mesos-containerizer
launch}} and the executor itself, perhaps we can just package and serialize the
executor env vars in one env var {{MESOS_EXECUTOR_ENVIRONMENT}} and pass that
to {{mesos-containerizer launch}} which could then get it through a flag the
usual way.
In general Mesos should do more to protect env vars but I'll file separate
issues for them.
> `mesos-containerizer launch --environment` exposes executor env vars in `ps`.
> -
>
> Key: MESOS-6526
> URL: https://issues.apache.org/jira/browse/MESOS-6526
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.1.0
>Reporter: Yan Xu
>Priority: Critical
>
> With MESOS-6323, the helper {{mesos-containerizer launch}} takes a
> `--environment` flag for the env vars used by the executor. This is
> unpleasant because its a common practice that people use env vars to hide
> configs that are sensitive and now it's visible to non-root users on the host
> with a {{ps}} command.
> Given that we want to separate the environments of {{mesos-containerizer
> launch}} and the executor itself, perhaps we can just package and serialize
> the executor env vars in one env var {{MESOS_EXECUTOR_ENVIRONMENT}} and pass
> that to {{mesos-containerizer launch}} which could then get it through a flag
> the usual way.
> In general Mesos should do more to protect env vars but I'll file separate
> issues for them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6477) Build a standalone python client for connecting to our Mock HTTP Server that implements the new Debug APIs
[
https://issues.apache.org/jira/browse/MESOS-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-6477:
---
Assignee: Steven Locke (was: Kevin Klues)
> Build a standalone python client for connecting to our Mock HTTP Server that
> implements the new Debug APIs
> --
>
> Key: MESOS-6477
> URL: https://issues.apache.org/jira/browse/MESOS-6477
> Project: Mesos
> Issue Type: Task
>Reporter: Kevin Klues
>Assignee: Steven Locke
> Labels: debugging, mesosphere
>
> This client prototype should have a similar CLI to what we eventually want to
> build into the DC/OS CLI.
> {noformat}
> Streaming HTTP Client
> Usage:
> client task exec [--tty] [--interactive] [...]
> client task attach [--tty] [--interactive]
> Options:
> --tty Allocate a tty on the server before
> attaching to the container.
> --interactive Connect the stdin of the client to
> the stdin of the container.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6476) Build a Mock HTTP Server that implements the new Debugging API calls
[
https://issues.apache.org/jira/browse/MESOS-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-6476:
---
Assignee: Steven Locke (was: Kevin Klues)
> Build a Mock HTTP Server that implements the new Debugging API calls
>
>
> Key: MESOS-6476
> URL: https://issues.apache.org/jira/browse/MESOS-6476
> Project: Mesos
> Issue Type: Task
>Reporter: Kevin Klues
>Assignee: Steven Locke
> Labels: debugging, mesosphere
>
> The mock server should simply launch a process to run whatever command is
> passed to it, rather than attempt to launch an actual nested container in
> mesos. However, it should do everything necessary to deal with attaching a
> {{pty}} / redirecting {{stdin/stdout/stderr}} properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6525) Add API protos for managing debug containers
Vinod Kone created MESOS-6525: - Summary: Add API protos for managing debug containers Key: MESOS-6525 URL: https://issues.apache.org/jira/browse/MESOS-6525 Project: Mesos Issue Type: Task Reporter: Vinod Kone Assignee: Vinod Kone The API calls that we should add are: LAUNCH_NESTED_CONTAINER_SESSION ATTACH_CONTAINER_INPUT ATTACH_CONTAINER_OUTPUT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6471) Build support for LAUNCH_NESTED_CONTAINER_SESSION call into the Agent API in Mesos
[
https://issues.apache.org/jira/browse/MESOS-6471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-6471:
---
Sprint: (was: Mesosphere Sprint 46)
> Build support for LAUNCH_NESTED_CONTAINER_SESSION call into the Agent API in
> Mesos
> --
>
> Key: MESOS-6471
> URL: https://issues.apache.org/jira/browse/MESOS-6471
> Project: Mesos
> Issue Type: Task
>Reporter: Kevin Klues
>Assignee: Kevin Klues
> Labels: debugging, mesosphere
>
> This HTTP API call will launch a nested container whose life-cycle is tied to
> the lifetime of the connection used to make this call. Once the agent
> receives the request, it will hold onto it until the container runs to
> completion or there is an error. Upon success, a 200 response will be
> initiated with an “infinite” chunked response (but no data will ever be sent
> over this connection). On error, an appropriate 400 error will be returned.
> If the connection is ever broken by the client, the container will be
> destroyed.
> This will likely involve modifications to some existing existing protobuf
> messages. It will also involve changes to {{launch.cpp}} to satisfy the new
> namespace requirements.
> We will create subtickets as we figure out the details for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6472) Build support for ATTACH_CONTAINER_INPUT into the Agent API in Mesos
[ https://issues.apache.org/jira/browse/MESOS-6472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-6472: --- Sprint: (was: Mesosphere Sprint 46) > Build support for ATTACH_CONTAINER_INPUT into the Agent API in Mesos > > > Key: MESOS-6472 > URL: https://issues.apache.org/jira/browse/MESOS-6472 > Project: Mesos > Issue Type: Task >Reporter: Kevin Klues >Assignee: Kevin Klues > Labels: debugging, mesosphere > > Coupled with the ATTACH_CONTAINER_OUTPUT call, this call will attach a remote > client to the the input/output of the entrypoint of a container. All > input/output data will be packed into I/O messages and interleaved with > control messages sent between a client and the agent. A single chunked > request will be used to stream messages to the agent over the input stream, > and a single chunked response will be used to stream messages to the client > over the output stream. > This call will integrate with the Mesos internal support for "attaching" to > an already running container through the new logger interfaces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6476) Build a Mock HTTP Server that implements the new Debugging API calls
[
https://issues.apache.org/jira/browse/MESOS-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-6476:
---
Sprint: Mesosphere Sprint 46
> Build a Mock HTTP Server that implements the new Debugging API calls
>
>
> Key: MESOS-6476
> URL: https://issues.apache.org/jira/browse/MESOS-6476
> Project: Mesos
> Issue Type: Task
>Reporter: Kevin Klues
>Assignee: Kevin Klues
> Labels: debugging, mesosphere
>
> The mock server should simply launch a process to run whatever command is
> passed to it, rather than attempt to launch an actual nested container in
> mesos. However, it should do everything necessary to deal with attaching a
> {{pty}} / redirecting {{stdin/stdout/stderr}} properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6471) Build support for LAUNCH_NESTED_CONTAINER_SESSION call into the Agent API in Mesos
[
https://issues.apache.org/jira/browse/MESOS-6471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-6471:
---
Sprint: Mesosphere Sprint 46
> Build support for LAUNCH_NESTED_CONTAINER_SESSION call into the Agent API in
> Mesos
> --
>
> Key: MESOS-6471
> URL: https://issues.apache.org/jira/browse/MESOS-6471
> Project: Mesos
> Issue Type: Task
>Reporter: Kevin Klues
>Assignee: Kevin Klues
> Labels: debugging, mesosphere
>
> This HTTP API call will launch a nested container whose life-cycle is tied to
> the lifetime of the connection used to make this call. Once the agent
> receives the request, it will hold onto it until the container runs to
> completion or there is an error. Upon success, a 200 response will be
> initiated with an “infinite” chunked response (but no data will ever be sent
> over this connection). On error, an appropriate 400 error will be returned.
> If the connection is ever broken by the client, the container will be
> destroyed.
> This will likely involve modifications to some existing existing protobuf
> messages. It will also involve changes to {{launch.cpp}} to satisfy the new
> namespace requirements.
> We will create subtickets as we figure out the details for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6472) Build support for ATTACH_CONTAINER_INPUT into the Agent API in Mesos
[ https://issues.apache.org/jira/browse/MESOS-6472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-6472: --- Sprint: Mesosphere Sprint 46 > Build support for ATTACH_CONTAINER_INPUT into the Agent API in Mesos > > > Key: MESOS-6472 > URL: https://issues.apache.org/jira/browse/MESOS-6472 > Project: Mesos > Issue Type: Task >Reporter: Kevin Klues >Assignee: Kevin Klues > Labels: debugging, mesosphere > > Coupled with the ATTACH_CONTAINER_OUTPUT call, this call will attach a remote > client to the the input/output of the entrypoint of a container. All > input/output data will be packed into I/O messages and interleaved with > control messages sent between a client and the agent. A single chunked > request will be used to stream messages to the agent over the input stream, > and a single chunked response will be used to stream messages to the client > over the output stream. > This call will integrate with the Mesos internal support for "attaching" to > an already running container through the new logger interfaces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6465) Add a task_id -> container_id mapping in state.json
[
https://issues.apache.org/jira/browse/MESOS-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-6465:
---
Sprint: Mesosphere Sprint 46
> Add a task_id -> container_id mapping in state.json
> ---
>
> Key: MESOS-6465
> URL: https://issues.apache.org/jira/browse/MESOS-6465
> Project: Mesos
> Issue Type: Task
>Reporter: Kevin Klues
>Assignee: Jie Yu
> Labels: debugging, mesosphere
>
> Currently, there is no way to get the {{container-id}} of a task from hitting
> the mesos master alone. You must first hit the master to get the {{task_id
> -> agent_id}} and {{task_id -> executor_id}} mappings, then hit the
> corresponding agent with {{agent_id}} to get the {{executor_id ->
> container_id}} mapping.
> It would simplify things alot if the {{container_id}} information was
> immediately available in the {{/tasks}} and {{/state}} endpoints of the
> master itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6466) Add support for streaming HTTP requests in Mesos
[ https://issues.apache.org/jira/browse/MESOS-6466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-6466: --- Sprint: Mesosphere Sprint 46 > Add support for streaming HTTP requests in Mesos > > > Key: MESOS-6466 > URL: https://issues.apache.org/jira/browse/MESOS-6466 > Project: Mesos > Issue Type: Task >Reporter: Kevin Klues >Assignee: Anand Mazumdar > Labels: debugging, mesosphere > > We already have support for streaming HTTP responses in Mesos. We now also > need to add support for streaming HTTP requests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5900) Consider supporting Unix domain socket connections in libprocess
[ https://issues.apache.org/jira/browse/MESOS-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-5900: --- Assignee: Benjamin Hindman > Consider supporting Unix domain socket connections in libprocess > > > Key: MESOS-5900 > URL: https://issues.apache.org/jira/browse/MESOS-5900 > Project: Mesos > Issue Type: Improvement > Components: libprocess >Reporter: Neil Conway >Assignee: Benjamin Hindman > Labels: mesosphere > > We should consider allowing two programs on the same host using libprocess to > communicate via Unix domain sockets rather than TCP. This has a few > advantages: > * Security: remote hosts cannot connect to the Unix socket. Domain sockets > also offer additional support for > [authentication|https://docs.fedoraproject.org/en-US/Fedora_Security_Team/1/html/Defensive_Coding/sect-Defensive_Coding-Authentication-UNIX_Domain.html]. > * Performance: domain sockets are marginally faster than localhost TCP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6474) Add fine-grained ACLs for authorization with the new debugging APIs
[
https://issues.apache.org/jira/browse/MESOS-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-6474:
---
Assignee: Alexander Rojas (was: Kevin Klues)
> Add fine-grained ACLs for authorization with the new debugging APIs
> ---
>
> Key: MESOS-6474
> URL: https://issues.apache.org/jira/browse/MESOS-6474
> Project: Mesos
> Issue Type: Task
>Reporter: Kevin Klues
>Assignee: Alexander Rojas
> Labels: debugging, mesosphere, security
>
> We already have ACLs in place for determining if a user has access to see a
> certain task when querying {{state.json}} on the master/agent, or
> browse/download a task's sandbox. However, we will have to add similar ACLs
> for making sure they have the correct permissions to execute the new
> Debugging APs on behalf of those tasks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6465) Add a task_id -> container_id mapping in state.json
[
https://issues.apache.org/jira/browse/MESOS-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-6465:
---
Assignee: Jie Yu (was: Kevin Klues)
> Add a task_id -> container_id mapping in state.json
> ---
>
> Key: MESOS-6465
> URL: https://issues.apache.org/jira/browse/MESOS-6465
> Project: Mesos
> Issue Type: Task
>Reporter: Kevin Klues
>Assignee: Jie Yu
> Labels: debugging, mesosphere
>
> Currently, there is no way to get the {{container-id}} of a task from hitting
> the mesos master alone. You must first hit the master to get the {{task_id
> -> agent_id}} and {{task_id -> executor_id}} mappings, then hit the
> corresponding agent with {{agent_id}} to get the {{executor_id ->
> container_id}} mapping.
> It would simplify things alot if the {{container_id}} information was
> immediately available in the {{/tasks}} and {{/state}} endpoints of the
> master itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6524) Command health checks ignore some fields from CommandInfo.
Alexander Rukletsov created MESOS-6524:
--
Summary: Command health checks ignore some fields from CommandInfo.
Key: MESOS-6524
URL: https://issues.apache.org/jira/browse/MESOS-6524
Project: Mesos
Issue Type: Improvement
Reporter: Alexander Rukletsov
Priority: Minor
Command health are specified via {{CommandInfo}}, but ignore several fields:
{{user}} and {{uris}}. We should either respect these fields or advice users
not to use them, i.e. fail validation and/or print warnings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6229) Default to using hardened compilation flags
[ https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6229: -- Description: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9 which should be reasonable. Detect compiler support and use what we can but prefer -fstack-protector-strong) -pie -fPIE -fPIC -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now (currently not a part of the patch, this should be another JIRA) -fno-omit-frame-pointer https://reviews.apache.org/r/52645/ https://reviews.apache.org/r/52695/ https://reviews.apache.org/r/52696/ was: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9 which should be reasonable) -pie -fPIE -fPIC -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now (currently not a part of the patch) -fno-omit-frame-pointer https://reviews.apache.org/r/52645/ https://reviews.apache.org/r/52695/ https://reviews.apache.org/r/52696/ > Default to using hardened compilation flags > --- > > Key: MESOS-6229 > URL: https://issues.apache.org/jira/browse/MESOS-6229 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, security > > Provide a default set of hardened compilation flags to help protect against > overflows and other attacks. Apply to libprocess and stout as well. Current > set of flags that were discussed on slack to implement: > -Wformat-security > -Wstack-protector > -fstack-protector-strong (-fstack-protector-all might be overkill, it could > be more effective to use this. Requires gcc >= 4.9 which should be > reasonable. Detect compiler support and use what we can but prefer > -fstack-protector-strong) > -pie > -fPIE > -fPIC > -D_FORTIFY_SOURCE=2 > -Wl,-z,relro,-z,now (currently not a part of the patch, this should be > another JIRA) > -fno-omit-frame-pointer > https://reviews.apache.org/r/52645/ > https://reviews.apache.org/r/52695/ > https://reviews.apache.org/r/52696/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6523) Agent cgroup assignment should precede agent initialization.
Anindya Sinha created MESOS-6523: Summary: Agent cgroup assignment should precede agent initialization. Key: MESOS-6523 URL: https://issues.apache.org/jira/browse/MESOS-6523 Project: Mesos Issue Type: Improvement Components: cgroups Reporter: Anindya Sinha Assignee: Anindya Sinha Priority: Minor If mesos-slave is launched with agent_subsystems flag, it would be preferred to move the agent process to its own cgroup for all the subsystems before the mesos-slave starts accepting traffic, ie. before port 5051 is opened up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-6518) Mesos dashboard: Symlinks not displayed in sandbox view
[
https://issues.apache.org/jira/browse/MESOS-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626356#comment-15626356
]
Mischa Krüger edited comment on MESOS-6518 at 11/1/16 7:04 PM:
---
I'm using DC/OS to deploy a service. In my case I'm using a docker image to
spawn a flink instance:
https://github.com/Makman2/dcos-flink-docker/blob/d754767152e44ad81bff890ced9fba97d5ffd99c/Dockerfile
Also I'm using a custom command, in this case it contains the same `ln` command
like in the Dockerfile:
{code}
echo "";
ls $MESOS_SANDBOX;
echo "";
ln -s $(pwd)/mesos_sandbox/* $MESOS_SANDBOX/;
echo "ln -s $(pwd)/mesos_sandbox/* $MESOS_SANDBOX/";
ls $MESOS_SANDBOX;
sleep 60;
{code}
which write following into the stdout file:
{code}
--container="mesos-90e534a9-de1b-4a32-ac01-d7d9d54337f2-S0.4515a673-3baa-4af3-83b7-b0755fe4ad94"
--docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
--initialize_driver_logging="true"
--launcher_dir="/opt/mesosphere/packages/mesos--55e36b7783f1549d26b7567b11090ff93b89487a/libexec/mesos"
--logbufsecs="0" --logging_level="INFO"
--mapped_directory="/mnt/mesos/sandbox" --quiet="false"
--sandbox_directory="/var/lib/mesos/slave/slaves/90e534a9-de1b-4a32-ac01-d7d9d54337f2-S0/frameworks/90e534a9-de1b-4a32-ac01-d7d9d54337f2-/executors/container-test.24183a01-a064-11e6-a8e8-9278bb0b38e1/runs/4515a673-3baa-4af3-83b7-b0755fe4ad94"
--stop_timeout="20secs"
--container="mesos-90e534a9-de1b-4a32-ac01-d7d9d54337f2-S0.4515a673-3baa-4af3-83b7-b0755fe4ad94"
--docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
--initialize_driver_logging="true"
--launcher_dir="/opt/mesosphere/packages/mesos--55e36b7783f1549d26b7567b11090ff93b89487a/libexec/mesos"
--logbufsecs="0" --logging_level="INFO"
--mapped_directory="/mnt/mesos/sandbox" --quiet="false"
--sandbox_directory="/var/lib/mesos/slave/slaves/90e534a9-de1b-4a32-ac01-d7d9d54337f2-S0/frameworks/90e534a9-de1b-4a32-ac01-d7d9d54337f2-/executors/container-test.24183a01-a064-11e6-a8e8-9278bb0b38e1/runs/4515a673-3baa-4af3-83b7-b0755fe4ad94"
--stop_timeout="20secs"
Registered docker executor on 10.0.2.185
Starting task container-test.24183a01-a064-11e6-a8e8-9278bb0b38e1
stderr
stderr.logrotate.conf
stdout
stdout.logrotate.conf
ln -s /flink-1.2-SNAPSHOT/mesos_sandbox/* /mnt/mesos/sandbox/
flink-conf.yaml
flink-python_2.10-1.2-SNAPSHOT.jar
flink.jar
log4j-1.2.17.jar
log4j.properties
slf4j-log4j12-1.7.7.jar
stderr
stderr.logrotate.conf
stdout
stdout.logrotate.conf
{code}
But only following files are displayed in the sandbox view:
{code}
stderr
stderr.logrotate.conf
stdout
stdout.logrotate.conf
{code}
so like no linking ever happened. But as you see in the stdout file, the links
are there! :/
PS:
When I try to spawn a service with following command:
{code}
touch x.txt;
ln -s x.txt my-symlink;
{code}
I can indeed see the symlink appearing in the sandbox view. Very strange...
was (Author: makman2):
I'm using DC/OS to deploy a service. In my case I'm using a docker image to
spawn a flink instance:
https://github.com/Makman2/dcos-flink-docker/blob/d754767152e44ad81bff890ced9fba97d5ffd99c/Dockerfile
Also I'm using a custom command, in this case it contains the same `ln` command
like in the Dockerfile:
{code}
echo "";
ls $MESOS_SANDBOX;
echo "";
ln -s $(pwd)/mesos_sandbox/* $MESOS_SANDBOX/;
echo "ln -s $(pwd)/mesos_sandbox/* $MESOS_SANDBOX/";
ls $MESOS_SANDBOX;
sleep 60;
{code}
which write following into the stdout file:
{code}
--container="mesos-90e534a9-de1b-4a32-ac01-d7d9d54337f2-S0.4515a673-3baa-4af3-83b7-b0755fe4ad94"
--docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
--initialize_driver_logging="true"
--launcher_dir="/opt/mesosphere/packages/mesos--55e36b7783f1549d26b7567b11090ff93b89487a/libexec/mesos"
--logbufsecs="0" --logging_level="INFO"
--mapped_directory="/mnt/mesos/sandbox" --quiet="false"
--sandbox_directory="/var/lib/mesos/slave/slaves/90e534a9-de1b-4a32-ac01-d7d9d54337f2-S0/frameworks/90e534a9-de1b-4a32-ac01-d7d9d54337f2-/executors/container-test.24183a01-a064-11e6-a8e8-9278bb0b38e1/runs/4515a673-3baa-4af3-83b7-b0755fe4ad94"
--stop_timeout="20secs"
--container="mesos-90e534a9-de1b-4a32-ac01-d7d9d54337f2-S0.4515a673-3baa-4af3-83b7-b0755fe4ad94"
--docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
--initialize_driver_logging="true"
--launcher_dir="/opt/mesosphere/packages/mesos--55e36b7783f1549d26b7567b11090ff93b89487a/libexec/mesos"
--logbufsecs="0" --logging_level="INFO"
--mapped_directory="/mnt/mesos/sandbox" --quiet="false"
[jira] [Updated] (MESOS-6518) Mesos dashboard: Symlinks not displayed in sandbox view
[ https://issues.apache.org/jira/browse/MESOS-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mischa Krüger updated MESOS-6518: - Attachment: tmp.png > Mesos dashboard: Symlinks not displayed in sandbox view > --- > > Key: MESOS-6518 > URL: https://issues.apache.org/jira/browse/MESOS-6518 > Project: Mesos > Issue Type: Improvement > Components: webui >Reporter: Mischa Krüger >Assignee: haosdent >Priority: Minor > Attachments: sandbox.png, tmp.png > > > Soft symbolic links do not appear in the sandbox, though they exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6518) Mesos dashboard: Symlinks not displayed in sandbox view
[
https://issues.apache.org/jira/browse/MESOS-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626356#comment-15626356
]
Mischa Krüger commented on MESOS-6518:
--
I'm using DC/OS to deploy a service. In my case I'm using a docker image to
spawn a flink instance:
https://github.com/Makman2/dcos-flink-docker/blob/d754767152e44ad81bff890ced9fba97d5ffd99c/Dockerfile
Also I'm using a custom command, in this case it contains the same `ln` command
like in the Dockerfile:
{code}
echo "";
ls $MESOS_SANDBOX;
echo "";
ln -s $(pwd)/mesos_sandbox/* $MESOS_SANDBOX/;
echo "ln -s $(pwd)/mesos_sandbox/* $MESOS_SANDBOX/";
ls $MESOS_SANDBOX;
sleep 60;
{code}
which write following into the stdout file:
{code}
--container="mesos-90e534a9-de1b-4a32-ac01-d7d9d54337f2-S0.4515a673-3baa-4af3-83b7-b0755fe4ad94"
--docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
--initialize_driver_logging="true"
--launcher_dir="/opt/mesosphere/packages/mesos--55e36b7783f1549d26b7567b11090ff93b89487a/libexec/mesos"
--logbufsecs="0" --logging_level="INFO"
--mapped_directory="/mnt/mesos/sandbox" --quiet="false"
--sandbox_directory="/var/lib/mesos/slave/slaves/90e534a9-de1b-4a32-ac01-d7d9d54337f2-S0/frameworks/90e534a9-de1b-4a32-ac01-d7d9d54337f2-/executors/container-test.24183a01-a064-11e6-a8e8-9278bb0b38e1/runs/4515a673-3baa-4af3-83b7-b0755fe4ad94"
--stop_timeout="20secs"
--container="mesos-90e534a9-de1b-4a32-ac01-d7d9d54337f2-S0.4515a673-3baa-4af3-83b7-b0755fe4ad94"
--docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
--initialize_driver_logging="true"
--launcher_dir="/opt/mesosphere/packages/mesos--55e36b7783f1549d26b7567b11090ff93b89487a/libexec/mesos"
--logbufsecs="0" --logging_level="INFO"
--mapped_directory="/mnt/mesos/sandbox" --quiet="false"
--sandbox_directory="/var/lib/mesos/slave/slaves/90e534a9-de1b-4a32-ac01-d7d9d54337f2-S0/frameworks/90e534a9-de1b-4a32-ac01-d7d9d54337f2-/executors/container-test.24183a01-a064-11e6-a8e8-9278bb0b38e1/runs/4515a673-3baa-4af3-83b7-b0755fe4ad94"
--stop_timeout="20secs"
Registered docker executor on 10.0.2.185
Starting task container-test.24183a01-a064-11e6-a8e8-9278bb0b38e1
stderr
stderr.logrotate.conf
stdout
stdout.logrotate.conf
ln -s /flink-1.2-SNAPSHOT/mesos_sandbox/* /mnt/mesos/sandbox/
flink-conf.yaml
flink-python_2.10-1.2-SNAPSHOT.jar
flink.jar
log4j-1.2.17.jar
log4j.properties
slf4j-log4j12-1.7.7.jar
stderr
stderr.logrotate.conf
stdout
stdout.logrotate.conf
{code}
But only following files are displayed in the sandbox view:
{code}
stderr
stderr.logrotate.conf
stdout
stdout.logrotate.conf
{code}
so like no linking ever happened. But as you see in the stdout file, the links
are there! :/
PS:
When I try to spawn a service with following command:
{code}
touch x.txt;
ln -s x.txt my-symlink;
{code}
I can indeed see the symlink appearing in the sandbox view. Very strange...
> Mesos dashboard: Symlinks not displayed in sandbox view
> ---
>
> Key: MESOS-6518
> URL: https://issues.apache.org/jira/browse/MESOS-6518
> Project: Mesos
> Issue Type: Improvement
> Components: webui
>Reporter: Mischa Krüger
>Assignee: haosdent
>Priority: Minor
> Attachments: sandbox.png
>
>
> Soft symbolic links do not appear in the sandbox, though they exist.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5597) Document Mesos "health check" feature.
[ https://issues.apache.org/jira/browse/MESOS-5597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-5597: --- Shepherd: Till Toenshoff Assignee: Alexander Rukletsov Sprint: Mesosphere Sprint 46 Target Version/s: 1.2.0 Issue Type: Documentation (was: Bug) > Document Mesos "health check" feature. > -- > > Key: MESOS-5597 > URL: https://issues.apache.org/jira/browse/MESOS-5597 > Project: Mesos > Issue Type: Documentation > Components: documentation >Reporter: Neil Conway >Assignee: Alexander Rukletsov > Labels: documentation, health-check, mesosphere > > We don't talk about this feature at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5597) Document Mesos "health check" feature.
[ https://issues.apache.org/jira/browse/MESOS-5597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-5597: --- Summary: Document Mesos "health check" feature. (was: Document Mesos "health check" feature) > Document Mesos "health check" feature. > -- > > Key: MESOS-5597 > URL: https://issues.apache.org/jira/browse/MESOS-5597 > Project: Mesos > Issue Type: Bug > Components: documentation >Reporter: Neil Conway > Labels: documentation, health-check, mesosphere > > We don't talk about this feature at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-6518) Mesos dashboard: Symlinks not displayed in sandbox view
[ https://issues.apache.org/jira/browse/MESOS-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626219#comment-15626219 ] haosdent edited comment on MESOS-6518 at 11/1/16 6:15 PM: -- !sandbox.png|width=200! was (Author: haosd...@gmail.com): !sandbox.png! > Mesos dashboard: Symlinks not displayed in sandbox view > --- > > Key: MESOS-6518 > URL: https://issues.apache.org/jira/browse/MESOS-6518 > Project: Mesos > Issue Type: Improvement > Components: webui >Reporter: Mischa Krüger >Assignee: haosdent >Priority: Minor > Attachments: sandbox.png > > > Soft symbolic links do not appear in the sandbox, though they exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-6518) Mesos dashboard: Symlinks not displayed in sandbox view
[ https://issues.apache.org/jira/browse/MESOS-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626219#comment-15626219 ] haosdent edited comment on MESOS-6518 at 11/1/16 6:15 PM: -- !sandbox.png|width=600px! was (Author: haosd...@gmail.com): !sandbox.png|width=200! > Mesos dashboard: Symlinks not displayed in sandbox view > --- > > Key: MESOS-6518 > URL: https://issues.apache.org/jira/browse/MESOS-6518 > Project: Mesos > Issue Type: Improvement > Components: webui >Reporter: Mischa Krüger >Assignee: haosdent >Priority: Minor > Attachments: sandbox.png > > > Soft symbolic links do not appear in the sandbox, though they exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6457) Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
[
https://issues.apache.org/jira/browse/MESOS-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-6457:
---
Affects Version/s: 0.28.2
1.0.1
> Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
> -
>
> Key: MESOS-6457
> URL: https://issues.apache.org/jira/browse/MESOS-6457
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.28.2, 1.0.1
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
>Priority: Blocker
>
> A task can currently transition from {{TASK_KILLING}} to {{TASK_RUNNING}}, if
> for example it starts/stops passing a health check once it got into the
> {{TASK_KILLING}} state.
> I think that this behaviour is counterintuitive. It also makes the life of
> framework/tools developers harder, since they have to keep track of the
> complete task status history in order to know if a task is being killed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6518) Mesos dashboard: Symlinks not displayed in sandbox view
[ https://issues.apache.org/jira/browse/MESOS-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-6518: Attachment: sandbox.png !sandbox.png! > Mesos dashboard: Symlinks not displayed in sandbox view > --- > > Key: MESOS-6518 > URL: https://issues.apache.org/jira/browse/MESOS-6518 > Project: Mesos > Issue Type: Improvement > Components: webui >Reporter: Mischa Krüger >Assignee: haosdent >Priority: Minor > Attachments: sandbox.png > > > Soft symbolic links do not appear in the sandbox, though they exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6457) Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
[
https://issues.apache.org/jira/browse/MESOS-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-6457:
---
Target Version/s: 0.28.3, 1.0.2, 1.1.0 (was: 1.0.2, 1.1.0)
> Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
> -
>
> Key: MESOS-6457
> URL: https://issues.apache.org/jira/browse/MESOS-6457
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.28.2, 1.0.1
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
>Priority: Blocker
>
> A task can currently transition from {{TASK_KILLING}} to {{TASK_RUNNING}}, if
> for example it starts/stops passing a health check once it got into the
> {{TASK_KILLING}} state.
> I think that this behaviour is counterintuitive. It also makes the life of
> framework/tools developers harder, since they have to keep track of the
> complete task status history in order to know if a task is being killed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6518) Mesos dashboard: Symlinks not displayed in sandbox view
[
https://issues.apache.org/jira/browse/MESOS-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626210#comment-15626210
]
haosdent commented on MESOS-6518:
-
Hi, [~Makman2] Symbol links looks work for me. Would you elaborate how you
create symbol links in the sandbox?
The sandbox contains symbol links which works in in my environment
{code}
bash-3.2$ ls -l
total 24
drwxr-xr-x 3 haosdent staff 102 Nov 2 02:09 a
lrwxr-xr-x 1 haosdent staff1 Nov 2 02:09 b -> a
-rw-r--r-- 1 haosdent staff 171 Nov 2 02:08 stderr
-rw-r--r-- 1 haosdent staff 245 Nov 2 02:08 stdout
{code}
> Mesos dashboard: Symlinks not displayed in sandbox view
> ---
>
> Key: MESOS-6518
> URL: https://issues.apache.org/jira/browse/MESOS-6518
> Project: Mesos
> Issue Type: Improvement
> Components: webui
>Reporter: Mischa Krüger
>Assignee: haosdent
>Priority: Minor
>
> Soft symbolic links do not appear in the sandbox, though they exist.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6457) Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
[
https://issues.apache.org/jira/browse/MESOS-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joris Van Remoortere updated MESOS-6457:
Target Version/s: 1.0.2, 1.1.0 (was: 1.1.0)
> Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
> -
>
> Key: MESOS-6457
> URL: https://issues.apache.org/jira/browse/MESOS-6457
> Project: Mesos
> Issue Type: Bug
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
>Priority: Blocker
>
> A task can currently transition from {{TASK_KILLING}} to {{TASK_RUNNING}}, if
> for example it starts/stops passing a health check once it got into the
> {{TASK_KILLING}} state.
> I think that this behaviour is counterintuitive. It also makes the life of
> framework/tools developers harder, since they have to keep track of the
> complete task status history in order to know if a task is being killed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6457) Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
[
https://issues.apache.org/jira/browse/MESOS-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joris Van Remoortere updated MESOS-6457:
Target Version/s: 1.1.0 (was: 1.2.0)
> Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
> -
>
> Key: MESOS-6457
> URL: https://issues.apache.org/jira/browse/MESOS-6457
> Project: Mesos
> Issue Type: Bug
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
>Priority: Blocker
>
> A task can currently transition from {{TASK_KILLING}} to {{TASK_RUNNING}}, if
> for example it starts/stops passing a health check once it got into the
> {{TASK_KILLING}} state.
> I think that this behaviour is counterintuitive. It also makes the life of
> framework/tools developers harder, since they have to keep track of the
> complete task status history in order to know if a task is being killed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6457) Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
[
https://issues.apache.org/jira/browse/MESOS-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626095#comment-15626095
]
Neil Conway commented on MESOS-6457:
{{TASK_KILLING}} to {{TASK_LOST}} is definitely possible.
{{TASK_KILLING}} => {{TASK_LOST}} => {{TASK_RUNNING}} should be possible if
{{TASK_KILLING}} => {{TASK_RUNNING}} is possible (I haven't looked into whether
allowing the latter transition is a good idea or not...)
> Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
> -
>
> Key: MESOS-6457
> URL: https://issues.apache.org/jira/browse/MESOS-6457
> Project: Mesos
> Issue Type: Bug
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
>Priority: Blocker
>
> A task can currently transition from {{TASK_KILLING}} to {{TASK_RUNNING}}, if
> for example it starts/stops passing a health check once it got into the
> {{TASK_KILLING}} state.
> I think that this behaviour is counterintuitive. It also makes the life of
> framework/tools developers harder, since they have to keep track of the
> complete task status history in order to know if a task is being killed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6457) Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
[
https://issues.apache.org/jira/browse/MESOS-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626057#comment-15626057
]
Gastón Kleiman commented on MESOS-6457:
---
[~zhitao] yes, this behaviour only affect the default and the command executors.
I believe that it is still possible for a task in {{TASK_KILLING}} to
transition to {{TASK_LOST}}. Given that {{TASK_LOST}} is not a terminal state,
I don't know if it would then be possible for the task to transition to
{{TASK_RUNNING}} instead of to {{TASK_KILLING}}/{{TASK_KILLED}}. Maybe [~neilc]
knows.
> Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
> -
>
> Key: MESOS-6457
> URL: https://issues.apache.org/jira/browse/MESOS-6457
> Project: Mesos
> Issue Type: Bug
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
>Priority: Blocker
>
> A task can currently transition from {{TASK_KILLING}} to {{TASK_RUNNING}}, if
> for example it starts/stops passing a health check once it got into the
> {{TASK_KILLING}} state.
> I think that this behaviour is counterintuitive. It also makes the life of
> framework/tools developers harder, since they have to keep track of the
> complete task status history in order to know if a task is being killed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6522) Ability to set global maximum executor runtime for an agent
Will Rouesnel created MESOS-6522: Summary: Ability to set global maximum executor runtime for an agent Key: MESOS-6522 URL: https://issues.apache.org/jira/browse/MESOS-6522 Project: Mesos Issue Type: Improvement Components: slave Reporter: Will Rouesnel Priority: Minor With the developing concept of agent maintenance mode, it would be nice to have some blunt-force ability to reason about the behavior of agents on uncooperative frameworks. Ideally there would be a new parameter --executor_maximum_lifetime which would specify a maximum duration for which *any* executor on an agent can run before being terminated. Even when using persistent schedulers such as Marathon, the ability to enforce reasonable gurantees about when an agent's tasks definitely must end can help contribute to keeping the cluster turning over and prevent nodes becoming "special" or jammed up with jobs which will not end. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6494) Clean up the flags parsing in the executors.
[
https://issues.apache.org/jira/browse/MESOS-6494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15625362#comment-15625362
]
Alexander Rukletsov commented on MESOS-6494:
{noformat}
commit e802760c932e766775eba481d890d43232693815
Author: Gastón Kleiman gas...@mesosphere.com
Date: Mon Oct 31 16:07:42 2016 -0700
Removed outdated TODO in stout::flags.
Review: https://reviews.apache.org/r/52878/
{noformat}
{noformat}
commit 0d116e099b6568dd0b99a973df57f3581b81a8a4
Author: Gastón Kleiman gas...@mesosphere.com
Date: Mon Oct 31 16:09:04 2016 -0700
Added parsers for 'SlaveID', 'ExecutorID' and 'FrameworkID'.
Review: https://reviews.apache.org/r/53197/
{noformat}
> Clean up the flags parsing in the executors.
>
>
> Key: MESOS-6494
> URL: https://issues.apache.org/jira/browse/MESOS-6494
> Project: Mesos
> Issue Type: Improvement
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
> Labels: mesosphere
>
> The current executors and the executor libraries use a mix of `stout::flags`
> and `os::getenv` to parse flags, leading to a lot of unnecessary and
> sometimes duplicated code.
> This should be cleaned up, using only {{stout::flags}} to parse flags.
> Environment variables should be used for the flags that are common to ALL the
> executors (listed in the Executor HTTP API doc).
> Command line parameters should be used for flags that apply only to
> individual executors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6459) PosixRLimitsIsolatorTest.TaskExceedingLimit fails on OS X
[
https://issues.apache.org/jira/browse/MESOS-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bannier updated MESOS-6459:
Sprint: Mesosphere Sprint 46
> PosixRLimitsIsolatorTest.TaskExceedingLimit fails on OS X
> -
>
> Key: MESOS-6459
> URL: https://issues.apache.org/jira/browse/MESOS-6459
> Project: Mesos
> Issue Type: Bug
>Reporter: Gastón Kleiman
>Assignee: Benjamin Bannier
> Labels: mesosphere
> Fix For: 1.2.0
>
>
> This test consistently fails on OS X:
> {code}
> 31-7e9c-4248-acfd-21634150a657@172.28.128.1:64864 on agent
> 52cc4957-1a39-4d66-ace6-5622fac3b85e-S0
> ../../src/tests/containerizer/posix_rlimits_isolator_tests.cpp:120: Failure
> Value of: statusFailed->state()
> Actual: TASK_FINISHED
> Expected: TASK_FAILED
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6516) Parallel test running does not respect GTEST_FILTER
[
https://issues.apache.org/jira/browse/MESOS-6516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bannier updated MESOS-6516:
Sprint: Mesosphere Sprint 46
> Parallel test running does not respect GTEST_FILTER
> ---
>
> Key: MESOS-6516
> URL: https://issues.apache.org/jira/browse/MESOS-6516
> Project: Mesos
> Issue Type: Bug
> Components: tests
>Reporter: Neil Conway
>Assignee: Benjamin Bannier
> Labels: mesosphere
>
> Normally, you can use {{GTEST_FILTER}} to control which tests will be run by
> {{make check}}. However, this doesn't currently work if Mesos is configured
> with {{--enable-parallel-test-execution}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
