[jira] [Commented] (MESOS-6098) Frameworks UI shows metrics for used resources plus offers

2016-08-26 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2016-08-26 Thread Miguel Bernadin (JIRA) 

 [ 
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

2016-08-26 Thread Miguel Bernadin (JIRA) 
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

2016-08-26 Thread Vinod Kone (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2016-08-26 Thread Charles Allen (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2016-08-26 Thread Joseph Wu (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2016-08-26 Thread Charles Allen (JIRA) 
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

2016-08-26 Thread Vinod Kone (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2016-08-26 Thread Vinod Kone (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2016-08-26 Thread Vinod Kone (JIRA) 
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.

2016-08-26 Thread Alexander Rukletsov (JIRA) 

 [ 
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.

2016-08-26 Thread Alexander Rukletsov (JIRA) 

 [ 
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.

2016-08-26 Thread Alexander Rukletsov (JIRA) 

 [ 
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.

2016-08-26 Thread Alexander Rukletsov (JIRA) 

 [ 
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.

2016-08-26 Thread Alexander Rukletsov (JIRA) 

 [ 
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

2016-08-26 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2016-08-26 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2016-08-26 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2016-08-26 Thread Felix Hupfeld (JIRA) 
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

2016-08-26 Thread Felix Hupfeld (JIRA) 
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] [Commented] (MESOS-5544) Support running Mesos agent in a Docker container.

2016-08-26 Thread Qian Zhang (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (MESOS-6087) Add master tests for TaskGroup

2016-08-26 Thread Guangya Liu (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15438557#comment-15438557
 ] 

Guangya Liu commented on MESOS-6087:


https://reviews.apache.org/r/51451/ Added test case 
MasterAuthorizationTest.KillPendingTaskInTaskGroup.

cc [~vinodkone]

> 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-4808) Allocation in batch instead of execute it every-time when addSlave/addFramework.

2016-08-26 Thread Klaus Ma (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15438538#comment-15438538
 ] 

Klaus Ma commented on MESOS-4808:
-

OK to close.

> Allocation in batch instead of execute it every-time when 
> addSlave/addFramework.
> 
>
> Key: MESOS-4808
> URL: https://issues.apache.org/jira/browse/MESOS-4808
> Project: Mesos
>  Issue Type: Bug
>  Components: allocation
>Reporter: Klaus Ma
>  Labels: master, tech-debt
>
> Currently, {{allocate()}} are executed every-time when a new slave/framework 
> are registered; if there're lots of agent start all most the same time, the 
> allocation will keep running for a while. It's acceptable behaviour to 
> allocate resources in next allocation cycle. But when a task is finished, 
> it's better to allocate ASAP although there's performances issues; refer to 
> MESOS-3078 for more detail on short running tasks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)