[jira] [Commented] (MESOS-6098) Frameworks UI shows metrics for used resources plus offers
[ https://issues.apache.org/jira/browse/MESOS-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15440229#comment-15440229 ] ASF GitHub Bot commented on MESOS-6098: --- GitHub user bernadinm opened a pull request: https://github.com/apache/mesos/pull/162 Frameworks UI shows metrics for used resources plus offers https://issues.apache.org/jira/browse/MESOS-6098 When a framework is receiving many offers and it is denying them, the frameworks UI will show the metrics fluctuating for mem, cpu, gpu, and disk. From a mesos perspective, those offers are given to the framework until the framework declines them, so depending on the time the mesos UI gets updated, its has combined all the used resources and offers (that have not been accepted) to the framework and is reflected on the framework UI. If a framework does not implement suppressiveOffers(), it will continue to deny offers from mesos, which leads to the sporadic changes of metrics on the framework UI. From the operator's perspective, the user would expect to see used resources consumed by the framework. Any offered resources can be viewed instead by Mesos's Offers tab. cc: @kaysoky You can merge this pull request into a Git repository by running: $ git pull https://github.com/bernadinm/mesos master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mesos/pull/162.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #162 commit b4296aeaf0e219885e62490f98cf2aed976f7984 Author: Miguel Bernadin Date: 2016-08-26T23:06:09Z update Mesos UI to reflect used resources commit b0bc9ce7f1c18bdc024c8bc5f16373cc1acb191f Author: Miguel Bernadin Date: 2016-08-26T23:21:09Z Update Mesos UI to reflect used resources > Frameworks UI shows metrics for used resources plus offers > -- > > Key: MESOS-6098 > URL: https://issues.apache.org/jira/browse/MESOS-6098 > Project: Mesos > Issue Type: Improvement > Components: webui >Affects Versions: 1.0.1 >Reporter: Miguel Bernadin >Assignee: Miguel Bernadin >Priority: Minor > > When a framework is receiving many offers and it is denying them, the > frameworks UI will show the metrics fluctuating for mem, cpu, gpu, and disk. > From a mesos perspective, those offers are given to the framework until the > framework declines them, so depending on the time the mesos UI gets updated, > its has combined all the used resources and offers (that have not been > accepted) to the framework and is reflected on the framework UI. If a > framework does not implement suppressiveOffers(), it will continue to deny > offers from mesos, which leads to the sporadic changes of metrics on the > framework UI. > From the operator's perspective, the user would expect to see used resources > consumed by the framework. Any offered resources can be viewed instead by > Mesos's Offers tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6098) Frameworks UI shows metrics for used resources plus offers
[ https://issues.apache.org/jira/browse/MESOS-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miguel Bernadin updated MESOS-6098: --- Summary: Frameworks UI shows metrics for used resources plus offers (was: Frameworks UI shows metrics for used plus offers) > Frameworks UI shows metrics for used resources plus offers > -- > > Key: MESOS-6098 > URL: https://issues.apache.org/jira/browse/MESOS-6098 > Project: Mesos > Issue Type: Improvement > Components: webui >Affects Versions: 1.0.1 >Reporter: Miguel Bernadin >Assignee: Miguel Bernadin >Priority: Minor > > When a framework is receiving many offers and it is denying them, the > frameworks UI will show the metrics fluctuating for mem, cpu, gpu, and disk. > From a mesos perspective, those offers are given to the framework until the > framework declines them, so depending on the time the mesos UI gets updated, > its has combined all the used resources and offers (that have not been > accepted) to the framework and is reflected on the framework UI. If a > framework does not implement suppressiveOffers(), it will continue to deny > offers from mesos, which leads to the sporadic changes of metrics on the > framework UI. > From the operator's perspective, the user would expect to see used resources > consumed by the framework. Any offered resources can be viewed instead by > Mesos's Offers tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6098) Frameworks UI shows metrics for used plus offers
Miguel Bernadin created MESOS-6098: -- Summary: Frameworks UI shows metrics for used plus offers Key: MESOS-6098 URL: https://issues.apache.org/jira/browse/MESOS-6098 Project: Mesos Issue Type: Improvement Components: webui Affects Versions: 1.0.1 Reporter: Miguel Bernadin Assignee: Miguel Bernadin Priority: Minor When a framework is receiving many offers and it is denying them, the frameworks UI will show the metrics fluctuating for mem, cpu, gpu, and disk. >From a mesos perspective, those offers are given to the framework until the >framework declines them, so depending on the time the mesos UI gets updated, >its has combined all the used resources and offers (that have not been >accepted) to the framework and is reflected on the framework UI. If a >framework does not implement suppressiveOffers(), it will continue to deny >offers from mesos, which leads to the sporadic changes of metrics on the >framework UI. >From the operator's perspective, the user would expect to see used resources >consumed by the framework. Any offered resources can be viewed instead by >Mesos's Offers tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4049) Allow user to control behavior of partitioned agents/tasks
[ https://issues.apache.org/jira/browse/MESOS-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15439996#comment-15439996 ] Vinod Kone commented on MESOS-4049: --- Author: Neil Conway Date: Fri Aug 26 14:48:47 2016 -0700 Made a few minor tweaks to comments. Review: https://reviews.apache.org/r/50704/ commit 0b90cccaca0069a2e2fff54d1424d205659346a3 Author: Neil Conway Date: Fri Aug 26 14:48:39 2016 -0700 Removed a no-longer-relevant test. The behavior this test is trying to validate (slaves receive a `ShutdownMessage` if they attempt to reregister after failing health checks) will be changed shortly. Moreover, the new behavior is already covered by other test cases. Review: https://reviews.apache.org/r/50703/ commit 93016d37bf8833d7a78ada9c4ec59a374419ba35 Author: Neil Conway Date: Fri Aug 26 14:48:16 2016 -0700 Renamed metrics from "slave_shutdowns" to "slave_unreachable". The master will shortly be changed to no longer shutdown unhealthy agents, so the previous metric name is no longer accurate. The old metric names have been kept for backwards compatibility, but they are no longer updated (i.e., they will always be set to zero). Review: https://reviews.apache.org/r/50702/ commit af496f3a80da9a8e7961fb62f839aacf1658222e Author: Neil Conway Date: Fri Aug 26 14:48:07 2016 -0700 Added registrar operations for marking agents (un-)reachable. Review: https://reviews.apache.org/r/50701/ commit 540591407729ae9eaf81f68cb025b181782c5b99 Author: Neil Conway Date: Fri Aug 26 14:48:03 2016 -0700 Added a list of "unreachable" agents to the registry. These are agents that have failed health checks. Review: https://reviews.apache.org/r/50700/ commit c3268cad3621a6373ff331d882393b2ada064f4b Author: Neil Conway Date: Fri Aug 26 14:47:53 2016 -0700 Added new TaskState values and PARTITION_AWARE capability. TASK_DROPPED, TASK_UNREACHABLE, TASK_GONE, TASK_GONE_BY_OPERATOR, and TASK_UNKNOWN. These values are intended to replace the existing TASK_LOST state by offering more fine-grained information on the current state of a task. These states will only be sent to frameworks that opt into this new behavior via the PARTITION_AWARE capability. Note that this commit doesn't add a master metric for the TASK_UNKNOWN status, because this is a "default" status reported when the master has no knowledge of a particular task/agent ID. Hence the number of "unknown" tasks at any given time is not a well-defined metric. Review: https://reviews.apache.org/r/50699/ > Allow user to control behavior of partitioned agents/tasks > -- > > Key: MESOS-4049 > URL: https://issues.apache.org/jira/browse/MESOS-4049 > Project: Mesos > Issue Type: Improvement > Components: master, slave >Reporter: Neil Conway >Assignee: Neil Conway > Labels: mesosphere > > At present, if an agent is partitioned away from the master, the master waits > for a period of time (see MESOS-4048) before deciding that the agent is dead. > Then it marks the agent as lost, sends {{TASK_LOST}} messages for all the > tasks running on the agent, and instructs the agent to shutdown. > Although this behavior is desirable for some/many users, it is not ideal for > everyone. For example: > * Some users might want to aggressively start a new replacement task (e.g., > after one or two ping timeouts are missed); then when the old copy of the > task comes back, they might want to make an intelligent decision about how to > reconcile this situation (e.g., kill old, kill new, allow both to continue > running). > * Some frameworks might want different behavior from other frameworks, or to > treat some tasks differently from other tasks. For example, if a task has a > huge amount of state that would need to be regenerated to spin up another > instance, the user might want to wait longer before starting a new task to > increase the chance that the old task will reappear. > To do this, we'd need to change task state so that a task can go from > {{RUNNING}} to a new state (say {{UNKNOWN}} or {{WANDERING}}), and then from > that state back to {{RUNNING}} (or perhaps we could keep the current > "mark-lost-after-timeout" behavior as an option, in which case {{UNKNOWN}} > could also transition to {{LOST}}). The agent would also keep its old > {{slaveId}} when it reconnects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6097) Empty /etc/mesos-slave/hostname causes strange registration behavior
[ https://issues.apache.org/jira/browse/MESOS-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15439975#comment-15439975 ] Charles Allen commented on MESOS-6097: -- Filed https://github.com/mesosphere/mesos-deb-packaging/issues/89 , thanks! > Empty /etc/mesos-slave/hostname causes strange registration behavior > > > Key: MESOS-6097 > URL: https://issues.apache.org/jira/browse/MESOS-6097 > Project: Mesos > Issue Type: Bug > Components: cli >Reporter: Charles Allen > > Using the mesosphere packaged Mesos 1.0.0 I had a node that ended up with a > blank /etc/mesos-slave/hostname due to something going wrong during the > auto-config process. > When the agent registered with the master, it ended up reporting very > strangely, including reporting the agent IP as the master's and having a > master IP blank. > The following items are in the /etc config: > {code} > $ ls /etc/mesos-slave/ > attributes cgroups_hierarchy cgroups_limit_swap gc_delay hostname > isolation resources slave_subsystems work_dir > {code} > Not sure if this is the right place to report mesosphere package config > problems, but it seems odd the agent would start under such a broken config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6097) Empty /etc/mesos-slave/hostname causes strange registration behavior
[ https://issues.apache.org/jira/browse/MESOS-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15439933#comment-15439933 ] Joseph Wu commented on MESOS-6097: -- Try your luck here: https://github.com/mesosphere/mesos-deb-packaging/issues This has recently been managed by [~karya]. > Empty /etc/mesos-slave/hostname causes strange registration behavior > > > Key: MESOS-6097 > URL: https://issues.apache.org/jira/browse/MESOS-6097 > Project: Mesos > Issue Type: Bug > Components: cli >Reporter: Charles Allen > > Using the mesosphere packaged Mesos 1.0.0 I had a node that ended up with a > blank /etc/mesos-slave/hostname due to something going wrong during the > auto-config process. > When the agent registered with the master, it ended up reporting very > strangely, including reporting the agent IP as the master's and having a > master IP blank. > The following items are in the /etc config: > {code} > $ ls /etc/mesos-slave/ > attributes cgroups_hierarchy cgroups_limit_swap gc_delay hostname > isolation resources slave_subsystems work_dir > {code} > Not sure if this is the right place to report mesosphere package config > problems, but it seems odd the agent would start under such a broken config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6097) Empty /etc/mesos-slave/hostname causes strange registration behavior
Charles Allen created MESOS-6097: Summary: Empty /etc/mesos-slave/hostname causes strange registration behavior Key: MESOS-6097 URL: https://issues.apache.org/jira/browse/MESOS-6097 Project: Mesos Issue Type: Bug Components: cli Reporter: Charles Allen Using the mesosphere packaged Mesos 1.0.0 I had a node that ended up with a blank /etc/mesos-slave/hostname due to something going wrong during the auto-config process. When the agent registered with the master, it ended up reporting very strangely, including reporting the agent IP as the master's and having a master IP blank. The following items are in the /etc config: {code} $ ls /etc/mesos-slave/ attributes cgroups_hierarchy cgroups_limit_swap gc_delay hostname isolation resources slave_subsystems work_dir {code} Not sure if this is the right place to report mesosphere package config problems, but it seems odd the agent would start under such a broken config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6087) Add master tests for TaskGroup
[ https://issues.apache.org/jira/browse/MESOS-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15439649#comment-15439649 ] Vinod Kone commented on MESOS-6087: --- commit 2d7bb9dfd99e370790aa10a4a657c4848a1b533b Author: Vinod Kone Date: Thu Aug 25 10:39:24 2016 -0700 Added validation test for task group task using NetworkInfos. NetworkInfos can only be set on the task group executor. Review: https://reviews.apache.org/r/51437 > Add master tests for TaskGroup > -- > > Key: MESOS-6087 > URL: https://issues.apache.org/jira/browse/MESOS-6087 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Guangya Liu > > Some of the tests we want to write: > -- If a pending task in a task group is killed, the entire group is killed. > -- If a task in a task group is invalid, the whole group is considered > invalid. > -- If a task in a task group is unauthorized, the whole group is considered > unauthorized. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6087) Add master tests for TaskGroup
[ https://issues.apache.org/jira/browse/MESOS-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15439617#comment-15439617 ] Vinod Kone commented on MESOS-6087: --- commit 7429846df717b3b84a2d1dd08b17496e6f828818 Author: Guangya Liu Date: Fri Aug 26 12:08:34 2016 -0700 Fixed typo for the comments of UnauthorizedTaskGroup. Review: https://reviews.apache.org/r/51455/ commit 60aedf79a5a475f164a9943bbf1389621df2dc9f Author: Guangya Liu Date: Fri Aug 26 12:08:29 2016 -0700 Added test case MasterAuthorizationTest.KillPendingTaskInTaskGroup. Review: https://reviews.apache.org/r/51451/ > Add master tests for TaskGroup > -- > > Key: MESOS-6087 > URL: https://issues.apache.org/jira/browse/MESOS-6087 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Guangya Liu > > Some of the tests we want to write: > -- If a pending task in a task group is killed, the entire group is killed. > -- If a task in a task group is invalid, the whole group is considered > invalid. > -- If a task in a task group is unauthorized, the whole group is considered > unauthorized. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6096) Update mesos-execute to support launching task groups
Vinod Kone created MESOS-6096: - Summary: Update mesos-execute to support launching task groups Key: MESOS-6096 URL: https://issues.apache.org/jira/browse/MESOS-6096 Project: Mesos Issue Type: Improvement Reporter: Vinod Kone This would be useful to do end to end tests of the TaskGroup support. Ideally this should be done after the TaskGroup support is completely implemented in master, agent and executor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5961) HTTP and TCP health checks should support docker executor and bridged mode.
[ https://issues.apache.org/jira/browse/MESOS-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-5961: --- Story Points: 8 (was: 3) > HTTP and TCP health checks should support docker executor and bridged mode. > --- > > Key: MESOS-5961 > URL: https://issues.apache.org/jira/browse/MESOS-5961 > Project: Mesos > Issue Type: Improvement >Reporter: Alexander Rukletsov >Assignee: haosdent > Labels: health-check, mesosphere > > If an executor and a task, e.g. the docker executor and docker container in > bridged mode, exist in different network namespaces, HTTP and TCP health > checks using {{localhost}} may not work properly. One solution would be to > enter the container's network in the health check binary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-5954) Docker executor does not use HealthChecker library.
[ https://issues.apache.org/jira/browse/MESOS-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-5954: --- Comment: was deleted (was: In order to support MESOS-5961, we decided to re-use the binary to enter the container's namespace.) > Docker executor does not use HealthChecker library. > --- > > Key: MESOS-5954 > URL: https://issues.apache.org/jira/browse/MESOS-5954 > Project: Mesos > Issue Type: Improvement >Reporter: Alexander Rukletsov >Assignee: haosdent > Labels: mesosphere > Fix For: 1.1.0 > > > https://github.com/apache/mesos/commit/1556d9a3a02de4e8a90b5b64d268754f95b12d77 > refactored health checks into a library. Command executor uses the library > instead of the "mesos-health-check" binary, docker executor should do the > same for consistency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5955) The "mesos-health-check" binary is not used anymore.
[ https://issues.apache.org/jira/browse/MESOS-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-5955: --- Sprint: Mesosphere Sprint 41 > The "mesos-health-check" binary is not used anymore. > > > Key: MESOS-5955 > URL: https://issues.apache.org/jira/browse/MESOS-5955 > Project: Mesos > Issue Type: Improvement >Reporter: Alexander Rukletsov >Assignee: haosdent > Labels: mesosphere > Fix For: 1.1.0 > > > MESOS-5727 and MESOS-5954 refactored the health check code into the > {{HealthChecker}} library, hence the "mesos-health-check" binary became > unused. > While the command and docker executors could just use the library to avoid > the subprocess complexity, we may want to consider keeping a binary version > that ships with the installation, because the intention of the binary was to > allow other executors to re-use our implementation. On the other side, this > binary is ill suited to this since it uses libprocess message passing, so if > we do not have code that requires the binary it seems ok to remove it for > now. Custom executors may use the {{HealthChecker}} library directly, it is > not much more complex than using the binary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-5955) The "mesos-health-check" binary is not used anymore.
[ https://issues.apache.org/jira/browse/MESOS-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-5955: --- Comment: was deleted (was: In order to support MESOS-5961, we decided to re-use the binary to enter the container's namespace.) > The "mesos-health-check" binary is not used anymore. > > > Key: MESOS-5955 > URL: https://issues.apache.org/jira/browse/MESOS-5955 > Project: Mesos > Issue Type: Improvement >Reporter: Alexander Rukletsov >Assignee: haosdent > Labels: mesosphere > Fix For: 1.1.0 > > > MESOS-5727 and MESOS-5954 refactored the health check code into the > {{HealthChecker}} library, hence the "mesos-health-check" binary became > unused. > While the command and docker executors could just use the library to avoid > the subprocess complexity, we may want to consider keeping a binary version > that ships with the installation, because the intention of the binary was to > allow other executors to re-use our implementation. On the other side, this > binary is ill suited to this since it uses libprocess message passing, so if > we do not have code that requires the binary it seems ok to remove it for > now. Custom executors may use the {{HealthChecker}} library directly, it is > not much more complex than using the binary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5954) Docker executor does not use HealthChecker library.
[ https://issues.apache.org/jira/browse/MESOS-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-5954: --- Sprint: Mesosphere Sprint 41 > Docker executor does not use HealthChecker library. > --- > > Key: MESOS-5954 > URL: https://issues.apache.org/jira/browse/MESOS-5954 > Project: Mesos > Issue Type: Improvement >Reporter: Alexander Rukletsov >Assignee: haosdent > Labels: mesosphere > Fix For: 1.1.0 > > > https://github.com/apache/mesos/commit/1556d9a3a02de4e8a90b5b64d268754f95b12d77 > refactored health checks into a library. Command executor uses the library > instead of the "mesos-health-check" binary, docker executor should do the > same for consistency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1209) Latest build fails
[ https://issues.apache.org/jira/browse/MESOS-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15438899#comment-15438899 ] ASF GitHub Bot commented on MESOS-1209: --- Github user jfarrell closed the pull request at: https://github.com/apache/mesos/pull/14 > Latest build fails > -- > > Key: MESOS-1209 > URL: https://issues.apache.org/jira/browse/MESOS-1209 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.19.0 > Environment: debian sid > #define PACKAGE_STRING "mesos 0.19.0" > #define PACKAGE "mesos" > #define STDC_HEADERS 1 > #define HAVE_SYS_TYPES_H 1 > #define HAVE_SYS_STAT_H 1 > #define HAVE_STDLIB_H 1 > #define HAVE_STRING_H 1 > #define HAVE_MEMORY_H 1 > #define HAVE_STRINGS_H 1 > #define HAVE_INTTYPES_H 1 > #define HAVE_STDINT_H 1 > #define HAVE_UNISTD_H 1 > #define HAVE_DLFCN_H 1 > #define HAVE_PTHREAD 1 > #define MESOS_HAS_JAVA 1 > #define HAVE_PYTHON "2.7" > #define MESOS_HAS_PYTHON 1 > #define HAVE_LIBZ 1 > #define HAVE_LIBCURL 1 > #define HAVE_LIBSASL2 1 >Reporter: james michael dupont >Assignee: james michael dupont > > make check fails > [ FAILED ] OsTest.release > [ RUN ] OsTest.release > stout/tests/os_tests.cpp:279: Failure > info: Failed to parse: 3.10-1-amd64 > [ FAILED ] OsTest.release (0 ms) > Output of : uname -a > Linux mdupont-Aspire-7750G 3.10-1-amd64 #1 SMP Debian 3.10.3-1 (2013-07-27) > x86_64 GNU/Linux -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-987) Wire up a code coverage tool
[ https://issues.apache.org/jira/browse/MESOS-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15438900#comment-15438900 ] ASF GitHub Bot commented on MESOS-987: -- Github user jfarrell closed the pull request at: https://github.com/apache/mesos/pull/15 > Wire up a code coverage tool > > > Key: MESOS-987 > URL: https://issues.apache.org/jira/browse/MESOS-987 > Project: Mesos > Issue Type: Improvement > Components: technical debt >Reporter: Vinod Kone >Assignee: Dominic Hamon > Fix For: 0.20.0 > > Attachments: lcov.png > > > Some options are gcov (works only with gcc afaict) and optionally lcov. > It would be nice to hook this up with Jenkins too. > http://meekrosoft.wordpress.com/2010/06/02/continuous-code-coverage-with-gcc-googletest-and-hudson/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1209) Latest build fails
[ https://issues.apache.org/jira/browse/MESOS-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15438898#comment-15438898 ] ASF GitHub Bot commented on MESOS-1209: --- Github user jfarrell commented on the issue: https://github.com/apache/mesos/pull/14 Closing as requested in https://s.apache.org/V8r3 > Latest build fails > -- > > Key: MESOS-1209 > URL: https://issues.apache.org/jira/browse/MESOS-1209 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.19.0 > Environment: debian sid > #define PACKAGE_STRING "mesos 0.19.0" > #define PACKAGE "mesos" > #define STDC_HEADERS 1 > #define HAVE_SYS_TYPES_H 1 > #define HAVE_SYS_STAT_H 1 > #define HAVE_STDLIB_H 1 > #define HAVE_STRING_H 1 > #define HAVE_MEMORY_H 1 > #define HAVE_STRINGS_H 1 > #define HAVE_INTTYPES_H 1 > #define HAVE_STDINT_H 1 > #define HAVE_UNISTD_H 1 > #define HAVE_DLFCN_H 1 > #define HAVE_PTHREAD 1 > #define MESOS_HAS_JAVA 1 > #define HAVE_PYTHON "2.7" > #define MESOS_HAS_PYTHON 1 > #define HAVE_LIBZ 1 > #define HAVE_LIBCURL 1 > #define HAVE_LIBSASL2 1 >Reporter: james michael dupont >Assignee: james michael dupont > > make check fails > [ FAILED ] OsTest.release > [ RUN ] OsTest.release > stout/tests/os_tests.cpp:279: Failure > info: Failed to parse: 3.10-1-amd64 > [ FAILED ] OsTest.release (0 ms) > Output of : uname -a > Linux mdupont-Aspire-7750G 3.10-1-amd64 #1 SMP Debian 3.10.3-1 (2013-07-27) > x86_64 GNU/Linux -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6095) Fix build process dependencies
Felix Hupfeld created MESOS-6095: Summary: Fix build process dependencies Key: MESOS-6095 URL: https://issues.apache.org/jira/browse/MESOS-6095 Project: Mesos Issue Type: Bug Reporter: Felix Hupfeld Running make after a successful build should not result in another build if nothing has changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6094) Build should not do concurrent builds per default
Felix Hupfeld created MESOS-6094: Summary: Build should not do concurrent builds per default Key: MESOS-6094 URL: https://issues.apache.org/jira/browse/MESOS-6094 Project: Mesos Issue Type: Bug Reporter: Felix Hupfeld Priority: Minor A make seems to run concurrent builds (-j) as a default. This is annoying when intending to do a background build on a workstation. I'd say the default build should be -j 1 and people can set their MAKEFLAGS accordingly if they want concurrency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6093) Build needs be independent from host packages
Felix Hupfeld created MESOS-6093: Summary: Build needs be independent from host packages Key: MESOS-6093 URL: https://issues.apache.org/jira/browse/MESOS-6093 Project: Mesos Issue Type: Bug Reporter: Felix Hupfeld As Mesos ships its 3rdparty dependencies in the repo, the build must not fail if some of these dependencies are installed on the host, in the same or other versions. For example, on CentOS 7, the build fails if glog is installed. I previously had problems with protobuf aswell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5544) Support running Mesos agent in a Docker container.
[ https://issues.apache.org/jira/browse/MESOS-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15438587#comment-15438587 ] Qian Zhang commented on MESOS-5544: --- [~jieyu], Can you please let me know why the executor will be killed when the agent is crashes (even the agent is running in a Docker container with --pid=host)? I thought if the executor is launched by a framework with checkpoint enabled, it will be still there when the agent crashes. > Support running Mesos agent in a Docker container. > -- > > Key: MESOS-5544 > URL: https://issues.apache.org/jira/browse/MESOS-5544 > Project: Mesos > Issue Type: Improvement >Reporter: Jie Yu > > Currently, this does not work if one tries to use Mesos containerizer. > The main problem is that we want to make sure the executor is not killed when > agent crashes. So we have to use --pid=host so that the agent is in the host > pid namespace. > But that is not sufficient, Docker daemon will put agent into all cgroups > available on the host. We need to make sure we migrate the executor pid out > of those cgroups so that when agent crashes, executors are not killed. > Also, when start the agent container, volumes need to be setup properly so > that any mounts under agent's work_dir will be propagate back to the host > mount table. This is to make sure we can recover those mounts after agent > restarts. This is also true for those mounts that are needed by some isolator > (e.g., network/cni isolator). -- This message was sent by Atlassian JIRA (v6.3.4#6332)