[jira] [Assigned] (MESOS-5543) /dev/fd is missing in the Mesos containerizer environment
[ https://issues.apache.org/jira/browse/MESOS-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Silas Snider reassigned MESOS-5543: --- Assignee: Silas Snider > /dev/fd is missing in the Mesos containerizer environment > - > > Key: MESOS-5543 > URL: https://issues.apache.org/jira/browse/MESOS-5543 > Project: Mesos > Issue Type: Bug > Components: containerization >Reporter: Silas Snider >Assignee: Silas Snider > > I have launched a task using the mesos containerizer with a docker image as > the rootfs. However, inside the environment the bash invocation I'm using > fails with an error about /dev/fd/63. > When I nsenter the container, I can see that the /dev/fd entry (should be a > link to /proc/self/fd) is not present, which apparently prevents bash from > doing subshell redirection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5543) /dev/fd is missing in the Mesos containerizer environment
Silas Snider created MESOS-5543: --- Summary: /dev/fd is missing in the Mesos containerizer environment Key: MESOS-5543 URL: https://issues.apache.org/jira/browse/MESOS-5543 Project: Mesos Issue Type: Bug Components: containerization Reporter: Silas Snider I have launched a task using the mesos containerizer with a docker image as the rootfs. However, inside the environment the bash invocation I'm using fails with an error about /dev/fd/63. When I nsenter the container, I can see that the /dev/fd entry (should be a link to /proc/self/fd) is not present, which apparently prevents bash from doing subshell redirection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5540) Support building with non-GNU libc
[
https://issues.apache.org/jira/browse/MESOS-5540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Conway reassigned MESOS-5540:
--
Assignee: Neil Conway
> Support building with non-GNU libc
> --
>
> Key: MESOS-5540
> URL: https://issues.apache.org/jira/browse/MESOS-5540
> Project: Mesos
> Issue Type: Improvement
> Components: general
>Reporter: Neil Conway
>Assignee: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> Some Linux distributions don't use glibc -- e.g., Alpine Linux uses musl.
> Mesos currently fails to compile using musl for at least the following two
> reasons:
> 1. {{linux/fs.hpp}} includes {{fstab.h}}, which isn't provided by musl.
> 2. various places use {{fts.h}}, which isn't provided by musl
> For (1), it seems this functionality is only needed by
> {{FsTest.FileSystemTableRead}}, so I think it can be safely removed.
> For (2), there are standalone implementations of the FTS functions, e.g.,
> https://github.com/pullmoll/musl-fts/ . We could either vendor such an
> implementation or require the user to install an FTS implementation as a
> library (e.g., https://pkgs.alpinelinux.org/package/edge/main/x86_64/fts). If
> we do the latter, we'd need to be prepared to link against {{libfts.a}} if
> needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5540) Support building with non-GNU libc
[
https://issues.apache.org/jira/browse/MESOS-5540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-5540:
--
Shepherd: Till Toenshoff
> Support building with non-GNU libc
> --
>
> Key: MESOS-5540
> URL: https://issues.apache.org/jira/browse/MESOS-5540
> Project: Mesos
> Issue Type: Improvement
> Components: general
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> Some Linux distributions don't use glibc -- e.g., Alpine Linux uses musl.
> Mesos currently fails to compile using musl for at least the following two
> reasons:
> 1. {{linux/fs.hpp}} includes {{fstab.h}}, which isn't provided by musl.
> 2. various places use {{fts.h}}, which isn't provided by musl
> For (1), it seems this functionality is only needed by
> {{FsTest.FileSystemTableRead}}, so I think it can be safely removed.
> For (2), there are standalone implementations of the FTS functions, e.g.,
> https://github.com/pullmoll/musl-fts/ . We could either vendor such an
> implementation or require the user to install an FTS implementation as a
> library (e.g., https://pkgs.alpinelinux.org/package/edge/main/x86_64/fts). If
> we do the latter, we'd need to be prepared to link against {{libfts.a}} if
> needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5540) Support building with non-GNU libc
[
https://issues.apache.org/jira/browse/MESOS-5540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Conway updated MESOS-5540:
---
Summary: Support building with non-GNU libc (was: Consider supporting
building with non-GNU libc)
> Support building with non-GNU libc
> --
>
> Key: MESOS-5540
> URL: https://issues.apache.org/jira/browse/MESOS-5540
> Project: Mesos
> Issue Type: Improvement
> Components: general
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> Some Linux distributions don't use glibc -- e.g., Alpine Linux uses musl.
> Mesos currently fails to compile using musl for at least the following two
> reasons:
> 1. {{linux/fs.hpp}} includes {{fstab.h}}, which isn't provided by musl.
> 2. various places use {{fts.h}}, which isn't provided by musl
> For (1), it seems this functionality is only needed by
> {{FsTest.FileSystemTableRead}}, so I think it can be safely removed.
> For (2), there are standalone implementations of the FTS functions, e.g.,
> https://github.com/pullmoll/musl-fts/ . We could either vendor such an
> implementation or require the user to install an FTS implementation as a
> library (e.g., https://pkgs.alpinelinux.org/package/edge/main/x86_64/fts). If
> we do the latter, we'd need to be prepared to link against {{libfts.a}} if
> needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5542) Add support for wrapping of move-only types in Future
Benjamin Bannier created MESOS-5542: --- Summary: Add support for wrapping of move-only types in Future Key: MESOS-5542 URL: https://issues.apache.org/jira/browse/MESOS-5542 Project: Mesos Issue Type: Improvement Components: libprocess Reporter: Benjamin Bannier -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5325) Mesos can't determine if task IP is reachable
[ https://issues.apache.org/jira/browse/MESOS-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314793#comment-15314793 ] Dan Osborne commented on MESOS-5325: My last two comments are invalid. Since CNI was introduced, the presence of the IpAddress field no longer indicates that a task will be receiving a routable IP address. Prime use case: users can specify `NetworkInfo` to launch a bridged task using CNI. This will result in a unroutable container IP. So there is indeed no flag for Mesos to be able to tell if a task is routable via its Container IP or not. > Mesos can't determine if task IP is reachable > - > > Key: MESOS-5325 > URL: https://issues.apache.org/jira/browse/MESOS-5325 > Project: Mesos > Issue Type: Bug >Reporter: Dan Osborne > > I have uncovered a design flaw that affects ip-per-container tasks when run > in a cluster alongside non ip-per-container tasks. This affects > docker-libnetwork, netmodules, and I suspect it will also affect CNI. > After Mesos launches a docker bridge task, it fills the task's networkinfo > field with the docker bridge IP assigned to that task. Because of this > behavior, when a launched task's NetworkInfo is later utilized by Mesos > components, it is unknown if it is filled with an IP address accessible > throughout the cluster, or if it is not. > A common use case where this is a problem can be encountered when using Mesos > DNS. Mesos-DNS has a configuration setting that tells it which information to > respond to a query with: NetworkInfo, or HostIP. If it has been configured to > prefer NetworkInfo, it correctly resolves ip-per-container containers to > their unique IP. But, because the docker bridge IP is also stored in > NetworkInfo, it will incorrectly resolve docker-bridge containers to an IP > address not accessible from anywhere besides the slave they are on. This > breaks DNS resolutions in Mesos. > I believe Mesos needs a way to distinguish between tasks which are accessible > via their IP and tasks that are not. > One fix would be to prevent Mesos from filling in NetworkInfo for a task if > it is known that the task is not reachable throughout the cluster via that > address. Essentially, NetworkInfo could be interpreted as a boolean - Its > presence means this task is addressable. Its absence means the task is not. > In practice, this would mean it gets filled in for CNI tasks, netmodules > tasks, and docker tasks bound to the host networking namespace. It would not > get filled in for docker bridge tasks. > I believe this change would be fairly minimum in scope. To implement it, > Mesos would need to be changed to not store Docker Bridge IP's in NetworkInfo. > I'm also open to discussion and other suggestions on how to resolve this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5541) OSX 10.10.5 and mesos 0.28.1 -- 10 to 20 X difference in sleep() method compared to non mesos
Rinaldo DiGiorgio created MESOS-5541:
Summary: OSX 10.10.5 and mesos 0.28.1 -- 10 to 20 X difference in
sleep() method compared to non mesos
Key: MESOS-5541
URL: https://issues.apache.org/jira/browse/MESOS-5541
Project: Mesos
Issue Type: Bug
Components: cgroups
Reporter: Rinaldo DiGiorgio
We are running the following Java application and we are getting
unreasonable deltas in the actual amount time slept. On linux the results are
as expected 10, 11, 12 but mostly 10ms. Can you suggest any changes we can
make or is this a known issue or a new issue to be investigated? When we run
the same code on the same instance of OSX 10.10.5 without mesos -- we get the
expected results.
public class SleepLatency {
static final int COUNT = 100;
static final long DELAY = 10L;
public static void main(String[] args) throws Exception {
long tstart = System.currentTimeMillis();
for (int i = 0; i < COUNT; i++) {
long t0 = System.currentTimeMillis();
Thread.sleep(DELAY);
long t1 = System.currentTimeMillis();
System.out.printf("loop %3d delay %4d ms%n", i, t1 - t0);
}
long tfinish = System.currentTimeMillis();
System.out.printf("total time = %5d ms%n", tfinish - tstart);
}
}
== OSX RESULTS are 10 to 20 times larger than LINUX Results below =
sh -c '/opt/jdk/bin/java -cp ./mach5-mesos-support-1.0-SNAPSHOT.jar
SleepLatency'
loop 0 delay 141 ms
loop 1 delay 201 ms
loop 2 delay 81 ms
loop 3 delay 14 ms
loop 4 delay 194 ms
loop 5 delay 149 ms
loop 6 delay 172 ms
loop 7 delay 203 ms
loop 8 delay 203 ms
loop 9 delay 204 ms
loop 10 delay 204 ms
== LINUX RESULTS are as expected ==
sh -c '/opt/jdk/bin/java -cp ./mach5-mesos-support-1.0-SNAPSHOT.jar
SleepLatency'
Forked command at 6125
loop 0 delay 10 ms
loop 1 delay 11 ms
loop 2 delay 10 ms
loop 3 delay 10 ms
loop 4 delay 10 ms
loop 5 delay 10 ms
loop 6 delay 10 ms
loop 7 delay 10 ms
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5539) Allow discovery of configuration flags used to produce Mesos binaries
Neil Conway created MESOS-5539:
--
Summary: Allow discovery of configuration flags used to produce
Mesos binaries
Key: MESOS-5539
URL: https://issues.apache.org/jira/browse/MESOS-5539
Project: Mesos
Issue Type: Improvement
Components: build
Reporter: Neil Conway
Priority: Minor
It would be useful to have a way to find the configuration flags and important
environmental variables (e.g., CXXFLAGS, LDFLAGS) that were used to build a set
of Mesos binaries. e.g., this can make it easier to diagnose whether a set of
binaries were built with compiler optimizations enabled.
Something like {{pg_config}}:
https://www.postgresql.org/docs/9.5/static/app-pgconfig.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4091) Mesos protobuf message definition ContainerInfo skipped an index.
[
https://issues.apache.org/jira/browse/MESOS-4091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314676#comment-15314676
]
Neil Conway commented on MESOS-4091:
Not sure this qualifies as a bug. Maybe it would have been better to use index
6 (if indeed it was never used in the past), but (a) should be harmless (b) not
much we can do about it now, without breaking backward compatibility.
> Mesos protobuf message definition ContainerInfo skipped an index.
> -
>
> Key: MESOS-4091
> URL: https://issues.apache.org/jira/browse/MESOS-4091
> Project: Mesos
> Issue Type: Bug
>Reporter: Till Toenshoff
>
> Looking at {{include/mesos/mesos.proto}}:
> {noformat}
> /**
> * Describes a container configuration and allows extensible
> * configurations for different container implementations.
> */
> message ContainerInfo {
> // All container implementation types.
> enum Type {
> DOCKER = 1;
> MESOS = 2;
> }
> message DockerInfo {
> // The docker image that is going to be passed to the registry.
> required string image = 1;
> // Network options.
> enum Network {
> HOST = 1;
> BRIDGE = 2;
> NONE = 3;
> }
> optional Network network = 2 [default = HOST];
> message PortMapping {
> required uint32 host_port = 1;
> required uint32 container_port = 2;
> // Protocol to expose as (ie: tcp, udp).
> optional string protocol = 3;
> }
> repeated PortMapping port_mappings = 3;
> optional bool privileged = 4 [default = false];
> // Allowing arbitrary parameters to be passed to docker CLI.
> // Note that anything passed to this field is not guaranteed
> // to be supported moving forward, as we might move away from
> // the docker CLI.
> repeated Parameter parameters = 5;
> // With this flag set to true, the docker containerizer will
> // pull the docker image from the registry even if the image
> // is already downloaded on the slave.
> optional bool force_pull_image = 6;
> }
> message MesosInfo {
> optional Image image = 1;
> }
> required Type type = 1;
> repeated Volume volumes = 2;
> optional string hostname = 4;
> // Only one of the following *Info messages should be set to match
> // the type.
> optional DockerInfo docker = 3;
> optional MesosInfo mesos = 5;
> // A list of network requests. A framework can request multiple IP addresses
> // for the container.
> repeated NetworkInfo network_infos = 7;
> }
> {noformat}
> Seems we are missing index 6 here.
> A quick history check revealed no intension to remove a former field 6 -
> hence this appears to be a bug. Checked via;
> {noformat}
> $ git log -L 1500,1515:include/mesos/mesos.proto
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5237) The windows version of `os::access` has differing behavior than the POSIX version.
[
https://issues.apache.org/jira/browse/MESOS-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bannier updated MESOS-5237:
Labels: mesosphere windows (was: mesosphere, windows)
> The windows version of `os::access` has differing behavior than the POSIX
> version.
> --
>
> Key: MESOS-5237
> URL: https://issues.apache.org/jira/browse/MESOS-5237
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Michael Park
>Assignee: Michael Park
> Labels: mesosphere, windows
> Fix For: 1.0.0
>
>
> The POSIX version of {{os::access}} looks like this:
> {code}
> inline Try access(const std::string& path, int how)
> {
> if (::access(path.c_str(), how) < 0) {
> if (errno == EACCES) {
> return false;
> } else {
> return ErrnoError();
> }
> }
> return true;
> }
> {code}
> Compare this to the Windows version of {{os::access}} which looks like this
> following:
> {code}
> inline Try access(const std::string& fileName, int how)
> {
> if (::_access(fileName.c_str(), how) != 0) {
> return ErrnoError("access: Could not access path '" + fileName + "'");
> }
> return true;
> }
> {code}
> As we can see, the case where {{errno}} is set to {{EACCES}} is handled
> differently between the 2 functions.
> We can actually consolidate the 2 functions by simply using the POSIX
> version. The challenge is that on POSIX, we should use {{::access}} and
> {{::_access}} on Windows. Note however, that this problem is already solved,
> as we have an implementation of {{::access}} for Windows in
> {{3rdparty/libprocess/3rdparty/stout/include/stout/windows.hpp}} which simply
> defers to {{::_access}}.
> Thus, I propose to simply consolidate the 2 implementations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5538) Add support for movable types inside Option/Try
Benjamin Bannier created MESOS-5538:
---
Summary: Add support for movable types inside Option/Try
Key: MESOS-5538
URL: https://issues.apache.org/jira/browse/MESOS-5538
Project: Mesos
Issue Type: Improvement
Components: stout
Reporter: Benjamin Bannier
We should add support for {{Option}}/{{Try}} of movable {{T}}s.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5537) http v1 SUBSCRIBED scheduler event always has nil http_interval_seconds
[
https://issues.apache.org/jira/browse/MESOS-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Mazumdar updated MESOS-5537:
--
Priority: Blocker (was: Major)
> http v1 SUBSCRIBED scheduler event always has nil http_interval_seconds
> ---
>
> Key: MESOS-5537
> URL: https://issues.apache.org/jira/browse/MESOS-5537
> Project: Mesos
> Issue Type: Bug
>Reporter: James DeFelice
>Priority: Blocker
> Labels: mesosphere
> Fix For: 1.0.0
>
>
> I'm writing a controller in Go to monitor heartbeats. I'd like to use the
> interval as communicated by the master, which should be specified in the
> SUBSCRIBED event. But it's not.
> {code}
> 2016/06/03 18:34:04 {Type:SUBSCRIBED
> Subscribed:_Subscribed{FrameworkID:{Value:ffdb6d6e-0167-4fa2-98f9-2c3f8157fc25-0004,},HeartbeatIntervalSeconds:nil,}
> Offers:nil Rescind:nil Update:nil Message:nil Failure:nil Error:nil}
> {code}
> {code}
> $ dpkg -l |grep -e mesos
> ii mesos 0.28.0-2.0.16.ubuntu1404
> amd64Cluster resource manager with efficient resource isolation
> {code}
> I *am* seeing HEARTBEAT events. Just not seeing the interval specified in the
> SUBSCRIBED event.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5537) http v1 SUBSCRIBED scheduler event always has nil http_interval_seconds
James DeFelice created MESOS-5537:
-
Summary: http v1 SUBSCRIBED scheduler event always has nil
http_interval_seconds
Key: MESOS-5537
URL: https://issues.apache.org/jira/browse/MESOS-5537
Project: Mesos
Issue Type: Bug
Reporter: James DeFelice
Fix For: 1.0.0
I'm writing a controller in Go to monitor heartbeats. I'd like to use the
interval as communicated by the master, which should be specified in the
SUBSCRIBED event. But it's not.
{code}
2016/06/03 18:34:04 {Type:SUBSCRIBED
Subscribed:_Subscribed{FrameworkID:{Value:ffdb6d6e-0167-4fa2-98f9-2c3f8157fc25-0004,},HeartbeatIntervalSeconds:nil,}
Offers:nil Rescind:nil Update:nil Message:nil Failure:nil Error:nil}
{code}
{code}
$ dpkg -l |grep -e mesos
ii mesos 0.28.0-2.0.16.ubuntu1404 amd64
Cluster resource manager with efficient resource isolation
{code}
I *am* seeing HEARTBEAT events. Just not seeing the interval specified in the
SUBSCRIBED event.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4901) Build fails on some systems due to unportable use of time.h
[ https://issues.apache.org/jira/browse/MESOS-4901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Conway updated MESOS-4901: --- Shepherd: Michael Park > Build fails on some systems due to unportable use of time.h > --- > > Key: MESOS-4901 > URL: https://issues.apache.org/jira/browse/MESOS-4901 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.25.1 >Reporter: Jim Carroll >Assignee: Neil Conway > > The 3rdparty library header file: > 3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp > uses #include but then assumes "struct timevar" is defined. "struct > timevar" is defined in not in . This works on most > systems but not on all. > Notably, it doesn't work on Alpine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-4901) Build fails on some systems due to unportable use of time.h
[ https://issues.apache.org/jira/browse/MESOS-4901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Conway reassigned MESOS-4901: -- Assignee: Neil Conway > Build fails on some systems due to unportable use of time.h > --- > > Key: MESOS-4901 > URL: https://issues.apache.org/jira/browse/MESOS-4901 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.25.1 >Reporter: Jim Carroll >Assignee: Neil Conway > > The 3rdparty library header file: > 3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp > uses #include but then assumes "struct timevar" is defined. "struct > timevar" is defined in not in . This works on most > systems but not on all. > Notably, it doesn't work on Alpine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5536) Completed executors presented as alive
[
https://issues.apache.org/jira/browse/MESOS-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15313946#comment-15313946
]
Tomasz Janiszewski commented on MESOS-5536:
---
I doulbe checked and I found that executor process is still running.
> Completed executors presented as alive
> --
>
> Key: MESOS-5536
> URL: https://issues.apache.org/jira/browse/MESOS-5536
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.28.0
> Environment: Ubuntu 14.04.3 LTS
>Reporter: Tomasz Janiszewski
>
> I'm running Mesos 0.28.0. Mesos {{slave(1)/state}} endpoint returns some
> completed executors not in frameworks.completed_executors but in
> frameworks.executors. Alsa this executor presents in {{monitor/statistics}}
> {code:JavaScript:title=slave(1)/state}
> {
> "attributes": {...},
> "completed_frameworks": [],
> "flags": {...},
> "frameworks": [
> {
> "checkpoint": true,
> "completed_executors": [...],
> "executors": [
> {
> "queued_tasks": [],
> "tasks": [],
> "completed_tasks": [
> {
> "discovery": {...},
> "executor_id": "",
> "framework_id":
> "f65b163c-0faf-441f-ac14-91739fa4394c-",
> "id":
> "service.a3b609b8-27ec-11e6-8044-02c89eb9127e",
> "labels": [...],
> "name": "service",
> "resources": {...},
> "slave_id":
> "ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13",
> "state": "TASK_KILLED",
> "statuses": []
> }
> ],
> "container": "ead42e63-ac92-4ad0-a99c-4af9c3fa5e31",
> "directory": "...",
> "id": "service.a3b609b8-27ec-11e6-8044-02c89eb9127e",
> "name": "Command Executor (Task:
> service.a3b609b8-27ec-11e6-8044-02c89eb9127e) (Command: sh -c 'cd
> service...')",
> "resources": {...},
> "source": "service.a3b609b8-27ec-11e6-8044-02c89eb9127e"
>
> },
> ...
> ],
> }
> ],
> "git_sha": "961edbd82e691a619a4c171a7aadc9c32957fa73",
> "git_tag": "0.28.0",
> "version": "0.28.0",
> ...
> }
> {code}
> {code:title="var/log/mesos/mesos-slave.INFO"}
> 13:33:19.479182 [slave.cpp:1361] Got assigned task
> service.a3b609b8-27ec-11e6-8044-02c89eb9127e for framework
> f65b163c-0faf-441f-ac14-91739fa4394c-
> 13:33:19.482566 [slave.cpp:1480] Launching task
> service.a3b609b8-27ec-11e6-8044-02c89eb9127e for framework
> f65b163c-0faf-441f-ac14-91739fa4394c-
> 13:33:19.483921 [paths.cpp:528] Trying to chown
> '/tmp/mesos/slaves/ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13/frameworks/f65b163c-0faf-441f-ac14-91739fa4394c-/executors/service.a3b609b8-27ec-11e6-8044-02c89eb9127e/runs/ead42e63-ac92-4ad0-a99c-4af9c3fa5e31'
> to user 'mesosuser'
> 13:33:19.504173 [slave.cpp:5367] Launching executor
> service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
> f65b163c-0faf-441f-ac14-91739fa4394c- with resources cpus(*):0.1;
> mem(*):32 in work directory
> '/tmp/mesos/slaves/ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13/frameworks/f65b163c-0faf-441f-ac14-91739fa4394c-/executors/service.a3b609b8-27ec-11e6-8044-02c89eb9127e/runs/ead42e63-ac92-4ad0-a99c-4af9c3fa5e31'
> 13:33:19.505537 [containerizer.cpp:666] Starting container
> 'ead42e63-ac92-4ad0-a99c-4af9c3fa5e31' for executor
> 'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' of framework
> 'f65b163c-0faf-441f-ac14-91739fa4394c-'
> 13:33:19.505734 [slave.cpp:1698] Queuing task
> 'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' for executor
> 'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' of framework
> f65b163c-0faf-441f-ac14-91739fa4394c-
> ...
> 13:33:19.977483 [containerizer.cpp:1118] Checkpointing executor's forked pid
> 25576 to
> '/tmp/mesos/meta/slaves/ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13/frameworks/f65b163c-0faf-441f-ac14-91739fa4394c-/executors/service.a3b609b8-27ec-11e6-8044-02c89eb9127e/runs/ead42e63-ac92-4ad0-a99c-4af9c3fa5e31/pids/forked.pid'
> 13:33:35.775195 [slave.cpp:1891] Asked to kill task
> service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
> f65b163c-0faf-441f-ac14-91739fa4394c-
> 13:33:35.775645 [slave.cpp:3002] Handling status update TASK_KILLED (UUID:
> eba64915-7df2-483d-8982-a9a46a48a81b) for task
> service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
> f65b163c-0faf-441f-ac14-91739fa4394c- f
> rom @0.0.0.0:0
> 13:33:35.778105 [cpushare.cpp:389] Updated
[jira] [Updated] (MESOS-5536) Completed executors presented as alive
[
https://issues.apache.org/jira/browse/MESOS-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Janiszewski updated MESOS-5536:
--
Description:
I'm running Mesos 0.28.0. Mesos {{slave(1)/state}} endpoint returns some
completed executors not in frameworks.completed_executors but in
frameworks.executors. Alsa this executor presents in {{monitor/statistics}}
{code:JavaScript:title=slave(1)/state}
{
"attributes": {...},
"completed_frameworks": [],
"flags": {...},
"frameworks": [
{
"checkpoint": true,
"completed_executors": [...],
"executors": [
{
"queued_tasks": [],
"tasks": [],
"completed_tasks": [
{
"discovery": {...},
"executor_id": "",
"framework_id":
"f65b163c-0faf-441f-ac14-91739fa4394c-",
"id": "service.a3b609b8-27ec-11e6-8044-02c89eb9127e",
"labels": [...],
"name": "service",
"resources": {...},
"slave_id":
"ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13",
"state": "TASK_KILLED",
"statuses": []
}
],
"container": "ead42e63-ac92-4ad0-a99c-4af9c3fa5e31",
"directory": "...",
"id": "service.a3b609b8-27ec-11e6-8044-02c89eb9127e",
"name": "Command Executor (Task:
service.a3b609b8-27ec-11e6-8044-02c89eb9127e) (Command: sh -c 'cd
service...')",
"resources": {...},
"source": "service.a3b609b8-27ec-11e6-8044-02c89eb9127e"
},
...
],
}
],
"git_sha": "961edbd82e691a619a4c171a7aadc9c32957fa73",
"git_tag": "0.28.0",
"version": "0.28.0",
...
}
{code}
{code:title="var/log/mesos/mesos-slave.INFO"}
13:33:19.479182 [slave.cpp:1361] Got assigned task
service.a3b609b8-27ec-11e6-8044-02c89eb9127e for framework
f65b163c-0faf-441f-ac14-91739fa4394c-
13:33:19.482566 [slave.cpp:1480] Launching task
service.a3b609b8-27ec-11e6-8044-02c89eb9127e for framework
f65b163c-0faf-441f-ac14-91739fa4394c-
13:33:19.483921 [paths.cpp:528] Trying to chown
'/tmp/mesos/slaves/ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13/frameworks/f65b163c-0faf-441f-ac14-91739fa4394c-/executors/service.a3b609b8-27ec-11e6-8044-02c89eb9127e/runs/ead42e63-ac92-4ad0-a99c-4af9c3fa5e31'
to user 'mesosuser'
13:33:19.504173 [slave.cpp:5367] Launching executor
service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
f65b163c-0faf-441f-ac14-91739fa4394c- with resources cpus(*):0.1; mem(*):32
in work directory
'/tmp/mesos/slaves/ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13/frameworks/f65b163c-0faf-441f-ac14-91739fa4394c-/executors/service.a3b609b8-27ec-11e6-8044-02c89eb9127e/runs/ead42e63-ac92-4ad0-a99c-4af9c3fa5e31'
13:33:19.505537 [containerizer.cpp:666] Starting container
'ead42e63-ac92-4ad0-a99c-4af9c3fa5e31' for executor
'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' of framework
'f65b163c-0faf-441f-ac14-91739fa4394c-'
13:33:19.505734 [slave.cpp:1698] Queuing task
'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' for executor
'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' of framework
f65b163c-0faf-441f-ac14-91739fa4394c-
...
13:33:19.977483 [containerizer.cpp:1118] Checkpointing executor's forked pid
25576 to
'/tmp/mesos/meta/slaves/ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13/frameworks/f65b163c-0faf-441f-ac14-91739fa4394c-/executors/service.a3b609b8-27ec-11e6-8044-02c89eb9127e/runs/ead42e63-ac92-4ad0-a99c-4af9c3fa5e31/pids/forked.pid'
13:33:35.775195 [slave.cpp:1891] Asked to kill task
service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
f65b163c-0faf-441f-ac14-91739fa4394c-
13:33:35.775645 [slave.cpp:3002] Handling status update TASK_KILLED (UUID:
eba64915-7df2-483d-8982-a9a46a48a81b) for task
service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
f65b163c-0faf-441f-ac14-91739fa4394c- f
rom @0.0.0.0:0
13:33:35.778105 [cpushare.cpp:389] Updated 'cpu.shares' to 102 (cpus 0.1) for
container ead42e63-ac92-4ad0-a99c-4af9c3fa5e31
13:33:35.778488 [disk.cpp:169] Updating the disk resources for container
ead42e63-ac92-4ad0-a99c-4af9c3fa5e31 to cpus(*):0.1; mem(*):32
13:33:35.780349 [mem.cpp:353] Updated 'memory.soft_limit_in_bytes' to 32MB for
container ead42e63-ac92-4ad0-a99c-4af9c3fa5e3
1
13:33:35.782573 [status_update_manager.cpp:320] Received status update
TASK_KILLED (UUID: eba64915-7df2-483d-8982-a9a46a48a8
1b) for task service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
f65b163c-0faf-441f-ac14-9173
9fa4394c-
13:33:35.783860
[jira] [Created] (MESOS-5536) Completed executors presented as alive
Tomasz Janiszewski created MESOS-5536:
-
Summary: Completed executors presented as alive
Key: MESOS-5536
URL: https://issues.apache.org/jira/browse/MESOS-5536
Project: Mesos
Issue Type: Bug
Affects Versions: 0.28.0
Environment: Ubuntu 14.04.3 LTS
Reporter: Tomasz Janiszewski
I'm running Mesos 0.28.0. Mesos slave(1)/state endpoint returns some completed
executors not in frameworks.completed_executors but in frameworks.executors.
{code:JavaScript:title=slave(1)/state}
{
"attributes": {...},
"completed_frameworks": [],
"flags": {...},
"frameworks": [
{
"checkpoint": true,
"completed_executors": [...],
"executors": [
{
"queued_tasks": [],
"tasks": [],
"completed_tasks": [
{
"discovery": {...},
"executor_id": "",
"framework_id":
"f65b163c-0faf-441f-ac14-91739fa4394c-",
"id": "service.a3b609b8-27ec-11e6-8044-02c89eb9127e",
"labels": [...],
"name": "service",
"resources": {...},
"slave_id":
"ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13",
"state": "TASK_KILLED",
"statuses": []
}
],
"container": "ead42e63-ac92-4ad0-a99c-4af9c3fa5e31",
"directory": "...",
"id": "service.a3b609b8-27ec-11e6-8044-02c89eb9127e",
"name": "Command Executor (Task:
service.a3b609b8-27ec-11e6-8044-02c89eb9127e) (Command: sh -c 'cd
service...')",
"resources": {...},
"source": "service.a3b609b8-27ec-11e6-8044-02c89eb9127e"
},
...
],
}
],
"git_sha": "961edbd82e691a619a4c171a7aadc9c32957fa73",
"git_tag": "0.28.0",
"version": "0.28.0",
...
}
{code}
{code:title="var/log/mesos/mesos-slave.INFO"}
13:33:19.479182 [slave.cpp:1361] Got assigned task
service.a3b609b8-27ec-11e6-8044-02c89eb9127e for framework
f65b163c-0faf-441f-ac14-91739fa4394c-
13:33:19.482566 [slave.cpp:1480] Launching task
service.a3b609b8-27ec-11e6-8044-02c89eb9127e for framework
f65b163c-0faf-441f-ac14-91739fa4394c-
13:33:19.483921 [paths.cpp:528] Trying to chown
'/tmp/mesos/slaves/ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13/frameworks/f65b163c-0faf-441f-ac14-91739fa4394c-/executors/service.a3b609b8-27ec-11e6-8044-02c89eb9127e/runs/ead42e63-ac92-4ad0-a99c-4af9c3fa5e31'
to user 'mesosuser'
13:33:19.504173 [slave.cpp:5367] Launching executor
service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
f65b163c-0faf-441f-ac14-91739fa4394c- with resources cpus(*):0.1; mem(*):32
in work directory
'/tmp/mesos/slaves/ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13/frameworks/f65b163c-0faf-441f-ac14-91739fa4394c-/executors/service.a3b609b8-27ec-11e6-8044-02c89eb9127e/runs/ead42e63-ac92-4ad0-a99c-4af9c3fa5e31'
13:33:19.505537 [containerizer.cpp:666] Starting container
'ead42e63-ac92-4ad0-a99c-4af9c3fa5e31' for executor
'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' of framework
'f65b163c-0faf-441f-ac14-91739fa4394c-'
13:33:19.505734 [slave.cpp:1698] Queuing task
'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' for executor
'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' of framework
f65b163c-0faf-441f-ac14-91739fa4394c-
...
13:33:19.977483 [containerizer.cpp:1118] Checkpointing executor's forked pid
25576 to
'/tmp/mesos/meta/slaves/ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13/frameworks/f65b163c-0faf-441f-ac14-91739fa4394c-/executors/service.a3b609b8-27ec-11e6-8044-02c89eb9127e/runs/ead42e63-ac92-4ad0-a99c-4af9c3fa5e31/pids/forked.pid'
13:33:35.775195 [slave.cpp:1891] Asked to kill task
service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
f65b163c-0faf-441f-ac14-91739fa4394c-
13:33:35.775645 [slave.cpp:3002] Handling status update TASK_KILLED (UUID:
eba64915-7df2-483d-8982-a9a46a48a81b) for task
service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
f65b163c-0faf-441f-ac14-91739fa4394c- f
rom @0.0.0.0:0
13:33:35.778105 [cpushare.cpp:389] Updated 'cpu.shares' to 102 (cpus 0.1) for
container ead42e63-ac92-4ad0-a99c-4af9c3fa5e31
13:33:35.778488 [disk.cpp:169] Updating the disk resources for container
ead42e63-ac92-4ad0-a99c-4af9c3fa5e31 to cpus(*):0.1; mem(*):32
13:33:35.780349 [mem.cpp:353] Updated 'memory.soft_limit_in_bytes' to 32MB for
container ead42e63-ac92-4ad0-a99c-4af9c3fa5e3
1
13:33:35.782573 [status_update_manager.cpp:320] Received status update
TASK_KILLED (UUID: eba64915-7df2-483d-8982-a9a46a48a8
1b) for task
[jira] [Commented] (MESOS-5509) Implement SET_QUOTA Call in v1 master API.
[ https://issues.apache.org/jira/browse/MESOS-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15313808#comment-15313808 ] Abhishek Dasgupta commented on MESOS-5509: -- What would setQuota() return? Will it be v1::Response with no field set? > Implement SET_QUOTA Call in v1 master API. > -- > > Key: MESOS-5509 > URL: https://issues.apache.org/jira/browse/MESOS-5509 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone >Assignee: Abhishek Dasgupta > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5513) Implement SET_LOGGING_LEVEL Call in v1 agent API.
[ https://issues.apache.org/jira/browse/MESOS-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Dasgupta reassigned MESOS-5513: Assignee: Abhishek Dasgupta > Implement SET_LOGGING_LEVEL Call in v1 agent API. > - > > Key: MESOS-5513 > URL: https://issues.apache.org/jira/browse/MESOS-5513 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone >Assignee: Abhishek Dasgupta > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
