[jira] [Commented] (MESOS-6422) cgroups_tests not correctly tearing down testing hierarchies

2016-10-31 Thread Yan Xu (JIRA) 

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

Yan Xu commented on MESOS-6422:
---

Yes. Or we can change the test to only create a single hierarchy.

> cgroups_tests not correctly tearing down testing hierarchies
> 
>
> Key: MESOS-6422
> URL: https://issues.apache.org/jira/browse/MESOS-6422
> Project: Mesos
>  Issue Type: Bug
>  Components: cgroups, containerization
>Reporter: Yan Xu
>Assignee: Yan Xu
>  Labels: cgroups
>
> We currently do the following in 
> [CgroupsTest::TearDownTestCase()|https://github.com/apache/mesos/blob/5e850a362edbf494921fedff4037cf4b53088c10/src/tests/containerizer/cgroups_tests.cpp#L83]
> {code:title=}
> static void TearDownTestCase()
> {
>   AWAIT_READY(cgroups::cleanup(TEST_CGROUPS_HIERARCHY));
> }
> {code}
> One of its derived test {{CgroupsNoHierarchyTest}} treats 
> {{TEST_CGROUPS_HIERARCHY}} as a hierarchy so it's able to clean it up as a 
> hierarchy.
> However another derived test {{CgroupsAnyHierarchyTest}} would create new 
> hierarchies (if none is available) using {{TEST_CGROUPS_HIERARCHY}} as a 
> parent directory (i.e., base hierarchy) and not as a hierarchy, so when it's 
> time to clean up, it fails:
> {noformat:title=}
> [   OK ] CgroupsAnyHierarchyTest.ROOT_CGROUPS_Subsystems (1 ms)
> ../../src/tests/containerizer/cgroups_tests.cpp:88: Failure
> (cgroups::cleanup(TEST_CGROUPS_HIERARCHY)).failure(): Operation not permitted
> {noformat}



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

[jira] [Assigned] (MESOS-6518) Mesos dashboard: Symlinks not displayed in sandbox view

2016-10-31 Thread haosdent (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

haosdent reassigned MESOS-6518:
---

Assignee: haosdent

> Mesos dashboard: Symlinks not displayed in sandbox view
> ---
>
> Key: MESOS-6518
> URL: https://issues.apache.org/jira/browse/MESOS-6518
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Mischa Krüger
>Assignee: haosdent
>Priority: Minor
>
> Soft symbolic links do not appear in the sandbox, though they exist.



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

[jira] [Updated] (MESOS-6521) MasterTest.RecoverResourcesOrphanedTask is flaky

2016-10-31 Thread Vinod Kone (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vinod Kone updated MESOS-6521:
--
Description: 
Observed this on ASF CI.

Looks like the acknowledgement of TASK_RUNNING update was never received by the 
executor. Not sure why. 
{code}
[ RUN  ] MasterTest.RecoverResourcesOrphanedTask
I1031 14:55:42.624336 30664 cluster.cpp:158] Creating default 'local' authorizer
I1031 14:55:42.627467 30664 leveldb.cpp:174] Opened db in 2.723103ms
I1031 14:55:42.628058 30664 leveldb.cpp:181] Compacted db in 560866ns
I1031 14:55:42.628105 30664 leveldb.cpp:196] Created db iterator in 17967ns
I1031 14:55:42.628128 30664 leveldb.cpp:202] Seeked to beginning of db in 2025ns
I1031 14:55:42.628139 30664 leveldb.cpp:271] Iterated through 0 keys in the db 
in 355ns
I1031 14:55:42.628175 30664 replica.cpp:776] Replica recovered with log 
positions 0 -> 0 with 1 holes and 0 unlearned
I1031 14:55:42.628563 30696 recover.cpp:451] Starting replica recovery
I1031 14:55:42.629137 30694 recover.cpp:477] Replica is in EMPTY status
I1031 14:55:42.630564 30693 replica.cpp:673] Replica in EMPTY status received a 
broadcasted recover request from __req_res__(3298)@172.17.0.3:45279
I1031 14:55:42.631057 30695 recover.cpp:197] Received a recover response from a 
replica in EMPTY status
I1031 14:55:42.631556 30694 recover.cpp:568] Updating replica status to STARTING
I1031 14:55:42.631809 30698 master.cpp:380] Master 
598309b4-b22f-47d3-9a90-7afc2df0d89f (169c0a15c915) started on 172.17.0.3:45279
I1031 14:55:42.632272 30687 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 423123ns
I1031 14:55:42.631837 30698 master.cpp:382] Flags at startup: --acls="" 
--agent_ping_timeout="15secs" --agent_reregister_timeout="10mins" 
--allocation_interval="1secs" --allocator="HierarchicalDRF" 
--authenticate_agents="true" --authenticate_frameworks="true" --
authenticate_http_frameworks="true" --authenticate_http_readonly="true" 
--authenticate_http_readwrite="true" --authenticators="crammd5" 
--authorizers="local" --credentials="/tmp/oUy0jO/credentials" 
--framework_sorter="drf" --help="false" --hostname_lookup="true"
 --http_authenticators="basic" --http_framework_authenticators="basic" 
--initialize_driver_logging="true" --log_auto_initialize="true" 
--logbufsecs="0" --logging_level="INFO" --max_agent_ping_timeouts="5" 
--max_completed_frameworks="50" --max_completed_tasks_per
_framework="1000" --quiet="false" --recovery_agent_removal_limit="100%" 
--registry="replicated_log" --registry_fetch_timeout="1mins" 
--registry_gc_interval="15mins" --registry_max_agent_age="2weeks" 
--registry_max_agent_count="102400" --registry_store_timeout="1
00secs" --registry_strict="false" --root_submissions="true" --user_sorter="drf" 
--version="false" --webui_dir="/mesos/mesos-1.2.0/_inst/share/mesos/webui" 
--work_dir="/tmp/oUy0jO/master" --zk_session_timeout="10secs"
I1031 14:55:42.632298 30687 replica.cpp:320] Persisted replica status to 
STARTING
I1031 14:55:42.632345 30698 master.cpp:432] Master only allowing authenticated 
frameworks to register
I1031 14:55:42.632359 30698 master.cpp:446] Master only allowing authenticated 
agents to register
I1031 14:55:42.632367 30698 master.cpp:459] Master only allowing authenticated 
HTTP frameworks to register
I1031 14:55:42.632375 30698 credentials.hpp:37] Loading credentials for 
authentication from '/tmp/oUy0jO/credentials'
I1031 14:55:42.632555 30686 recover.cpp:477] Replica is in STARTING status
I1031 14:55:42.632690 30698 master.cpp:504] Using default 'crammd5' 
authenticator
I1031 14:55:42.632850 30698 http.cpp:887] Using default 'basic' HTTP 
authenticator for realm 'mesos-master-readonly'
I1031 14:55:42.633018 30698 http.cpp:887] Using default 'basic' HTTP 
authenticator for realm 'mesos-master-readwrite'
I1031 14:55:42.633174 30698 http.cpp:887] Using default 'basic' HTTP 
authenticator for realm 'mesos-master-scheduler'
I1031 14:55:42.65 30698 master.cpp:584] Authorization enabled
I1031 14:55:42.633500 30697 hierarchical.cpp:149] Initialized hierarchical 
allocator process
I1031 14:55:42.633513 30683 whitelist_watcher.cpp:77] No whitelist given
I1031 14:55:42.633719 30683 replica.cpp:673] Replica in STARTING status 
received a broadcasted recover request from __req_res__(3299)@172.17.0.3:45279
I1031 14:55:42.634234 30689 recover.cpp:197] Received a recover response from a 
replica in STARTING status
I1031 14:55:42.634668 30694 recover.cpp:568] Updating replica status to VOTING
I1031 14:55:42.635254 30697 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 338613ns
I1031 14:55:42.635290 30697 replica.cpp:320] Persisted replica status to VOTING
I1031 14:55:42.635447 30683 recover.cpp:582] Successfully joined the Paxos group
I1031 14:55:42.635709 30683 recover.cpp:466] Recover process terminated
I1031 14:55:42.636854 30697 master.cpp:2033] Elected as the leading master!
I1031

[jira] [Created] (MESOS-6521) MasterTest.RecoverResourcesOrphanedTask is flaky

2016-10-31 Thread Vinod Kone (JIRA) 
Vinod Kone created MESOS-6521:
-

 Summary: MasterTest.RecoverResourcesOrphanedTask is flaky
 Key: MESOS-6521
 URL: https://issues.apache.org/jira/browse/MESOS-6521
 Project: Mesos
  Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Vinod Kone


Observed this on ASF CI.

Looks like the acknowledgement of TASK_RUNNING update was never received by the 
executor. Not sure why. 
{code}
[ RUN  ] MasterTest.RecoverResourcesOrphanedTask
I1031 14:55:42.624336 30664 cluster.cpp:158] Creating default 'local' authorizer
I1031 14:55:42.627467 30664 leveldb.cpp:174] Opened db in 2.723103ms
I1031 14:55:42.628058 30664 leveldb.cpp:181] Compacted db in 560866ns
I1031 14:55:42.628105 30664 leveldb.cpp:196] Created db iterator in 17967ns
I1031 14:55:42.628128 30664 leveldb.cpp:202] Seeked to beginning of db in 2025ns
I1031 14:55:42.628139 30664 leveldb.cpp:271] Iterated through 0 keys in the db 
in 355ns
I1031 14:55:42.628175 30664 replica.cpp:776] Replica recovered with log 
positions 0 -> 0 with 1 holes and 0 unlearned
I1031 14:55:42.628563 30696 recover.cpp:451] Starting replica recovery
I1031 14:55:42.629137 30694 recover.cpp:477] Replica is in EMPTY status
I1031 14:55:42.630564 30693 replica.cpp:673] Replica in EMPTY status received a 
broadcasted recover request from __req_res__(3298)@172.17.0.3:45279
I1031 14:55:42.631057 30695 recover.cpp:197] Received a recover response from a 
replica in EMPTY status
I1031 14:55:42.631556 30694 recover.cpp:568] Updating replica status to STARTING
I1031 14:55:42.631809 30698 master.cpp:380] Master 
598309b4-b22f-47d3-9a90-7afc2df0d89f (169c0a15c915) started on 172.17.0.3:45279
I1031 14:55:42.632272 30687 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 423123ns
I1031 14:55:42.631837 30698 master.cpp:382] Flags at startup: --acls="" 
--agent_ping_timeout="15secs" --agent_reregister_timeout="10mins" 
--allocation_interval="1secs" --allocator="HierarchicalDRF" 
--authenticate_agents="true" --authenticate_frameworks="true" --
authenticate_http_frameworks="true" --authenticate_http_readonly="true" 
--authenticate_http_readwrite="true" --authenticators="crammd5" 
--authorizers="local" --credentials="/tmp/oUy0jO/credentials" 
--framework_sorter="drf" --help="false" --hostname_lookup="true"
 --http_authenticators="basic" --http_framework_authenticators="basic" 
--initialize_driver_logging="true" --log_auto_initialize="true" 
--logbufsecs="0" --logging_level="INFO" --max_agent_ping_timeouts="5" 
--max_completed_frameworks="50" --max_completed_tasks_per
_framework="1000" --quiet="false" --recovery_agent_removal_limit="100%" 
--registry="replicated_log" --registry_fetch_timeout="1mins" 
--registry_gc_interval="15mins" --registry_max_agent_age="2weeks" 
--registry_max_agent_count="102400" --registry_store_timeout="1
00secs" --registry_strict="false" --root_submissions="true" --user_sorter="drf" 
--version="false" --webui_dir="/mesos/mesos-1.2.0/_inst/share/mesos/webui" 
--work_dir="/tmp/oUy0jO/master" --zk_session_timeout="10secs"
I1031 14:55:42.632298 30687 replica.cpp:320] Persisted replica status to 
STARTING
I1031 14:55:42.632345 30698 master.cpp:432] Master only allowing authenticated 
frameworks to register
I1031 14:55:42.632359 30698 master.cpp:446] Master only allowing authenticated 
agents to register
I1031 14:55:42.632367 30698 master.cpp:459] Master only allowing authenticated 
HTTP frameworks to register
I1031 14:55:42.632375 30698 credentials.hpp:37] Loading credentials for 
authentication from '/tmp/oUy0jO/credentials'
I1031 14:55:42.632555 30686 recover.cpp:477] Replica is in STARTING status
I1031 14:55:42.632690 30698 master.cpp:504] Using default 'crammd5' 
authenticator
I1031 14:55:42.632850 30698 http.cpp:887] Using default 'basic' HTTP 
authenticator for realm 'mesos-master-readonly'
I1031 14:55:42.633018 30698 http.cpp:887] Using default 'basic' HTTP 
authenticator for realm 'mesos-master-readwrite'
I1031 14:55:42.633174 30698 http.cpp:887] Using default 'basic' HTTP 
authenticator for realm 'mesos-master-scheduler'
I1031 14:55:42.65 30698 master.cpp:584] Authorization enabled
I1031 14:55:42.633500 30697 hierarchical.cpp:149] Initialized hierarchical 
allocator process
I1031 14:55:42.633513 30683 whitelist_watcher.cpp:77] No whitelist given
I1031 14:55:42.633719 30683 replica.cpp:673] Replica in STARTING status 
received a broadcasted recover request from __req_res__(3299)@172.17.0.3:45279
I1031 14:55:42.634234 30689 recover.cpp:197] Received a recover response from a 
replica in STARTING status
I1031 14:55:42.634668 30694 recover.cpp:568] Updating replica status to VOTING
I1031 14:55:42.635254 30697 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 338613ns
I1031 14:55:42.635290 30697 replica.cpp:320] Persisted replica status to VOTING
I1031 14:55:42.635447 30683 recover.cpp:582] Successfully joined the Paxos group
I1031

[jira] [Commented] (MESOS-6465) Add a task_id -> container_id mapping in state.json

2016-10-31 Thread Jie Yu (JIRA) 

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

Jie Yu commented on MESOS-6465:
---

Relying on TaskStatus.ContainerStatus does not work for nested container 
because it's always a 1-1 mapping between task and container.

> Add a task_id -> container_id mapping in state.json
> ---
>
> Key: MESOS-6465
> URL: https://issues.apache.org/jira/browse/MESOS-6465
> Project: Mesos
>  Issue Type: Task
>Reporter: Kevin Klues
>Assignee: Kevin Klues
>  Labels: debugging, mesosphere
>
> Currently, there is no way to get the {{container-id}} of a task from hitting 
> the mesos master alone.  You must first hit the master to get the {{task_id 
> -> agent_id}} and {{task_id -> executor_id}} mappings, then hit the 
> corresponding agent with {{agent_id}} to get the {{executor_id -> 
> container_id}} mapping.
> It would simplify things alot if the {{container_id}} information was 
> immediately available in the {{/tasks}} and {{/state}} endpoints of the 
> master itself.



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

[jira] [Commented] (MESOS-6518) Mesos dashboard: Symlinks not displayed in sandbox view

2016-10-31 Thread Vinod Kone (JIRA) 

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

Vinod Kone commented on MESOS-6518:
---

cc [~haosd...@gmail.com]

> Mesos dashboard: Symlinks not displayed in sandbox view
> ---
>
> Key: MESOS-6518
> URL: https://issues.apache.org/jira/browse/MESOS-6518
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Mischa Krüger
>Priority: Minor
>
> Soft symbolic links do not appear in the sandbox, though they exist.



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

[jira] [Created] (MESOS-6520) Make errno an explicit argument for ErrnoError.

2016-10-31 Thread James Peach (JIRA) 
James Peach created MESOS-6520:
--

 Summary: Make errno an explicit argument for ErrnoError.
 Key: MESOS-6520
 URL: https://issues.apache.org/jira/browse/MESOS-6520
 Project: Mesos
  Issue Type: Bug
  Components: technical debt
Reporter: James Peach
Priority: Minor


Make {{errno}} an explicit argument to {{ErrnoError}}. Right now, the 
constructor to {{ErrnoError}} references {{errno}} directly, which makes it 
awkward to pass a custom {{errno}} value (you have to set {{errno}} globally).



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

[jira] [Comment Edited] (MESOS-6369) Add a column for FrameworkID when displaying tasks in the WebUI

2016-10-31 Thread Miguel Bernadin (JIRA) 

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

Miguel Bernadin edited comment on MESOS-6369 at 10/31/16 10:21 PM:
---

[~kaysoky], Submitted for review https://reviews.apache.org/r/53324/ to this 
that changes that look like this with modified field names: 

|| Framework ID || Task ID || Task Name || State || Started || Host || ||
| 179b5436-30ec-45e9-b324-fa5c5a1dd756- | 1 | My ambiguously named task | 
RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
| 179b5436-30ec-45e9-b324-fa5c5a1dd756-0001 | 1 | My ambiguously named task | 
RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
| 179b5436-30ec-45e9-b324-fa5c5a1dd756-0001 | 2 | My ambiguously named task | 
RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |



was (Author: bernadinm):
[~kaysoky], Sumbitted for review https://reviews.apache.org/r/53324/ to this 
that changes that look like this with modified field names: 

|| Framework ID || Task ID || Task Name || State || Started || Host || ||
| 179b5436-30ec-45e9-b324-fa5c5a1dd756- | 1 | My ambiguously named task | 
RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
| 179b5436-30ec-45e9-b324-fa5c5a1dd756-0001 | 1 | My ambiguously named task | 
RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
| 179b5436-30ec-45e9-b324-fa5c5a1dd756-0001 | 2 | My ambiguously named task | 
RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |


> Add a column for FrameworkID when displaying tasks in the WebUI
> ---
>
> Key: MESOS-6369
> URL: https://issues.apache.org/jira/browse/MESOS-6369
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Joseph Wu
>Assignee: Miguel Bernadin
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The Mesos Web UI home page shows a list of active/completed/orphan tasks 
> tasks like this:
> || ID || Name || State || Started || Host || ||
> | 1 | My ambiguously named task | RUNNING | 1 minute ago | 10.10.0.1 | 
> Sandbox |
> | 1 | My ambiguously named task | RUNNING | 1 minute ago | 10.10.0.1 | 
> Sandbox |
> | 2 | My ambiguously named task | RUNNING | 1 minute ago | 10.10.0.1 | 
> Sandbox |
> When you start multiple frameworks, the task IDs and names show in the UI may 
> be ambiguous, requiring extra clicks/investigation to disambiguate.  
> In the above case, to disambiguate between the two tasks with ID {{1}}, the 
> user would need to navigate to each sandbox and check the associated 
> frameworkID in the {{/browse}} view.  
> We could add a column showing the {{FrameworkID}} next to each task:
> || Framework || ID || Name || State || Started || Host || ||
> | 179b5436-30ec-45e9-b324-fa5c5a1dd756- | 1 | My ambiguously named task | 
> RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
> | 179b5436-30ec-45e9-b324-fa5c5a1dd756-0001 | 1 | My ambiguously named task | 
> RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
> | 179b5436-30ec-45e9-b324-fa5c5a1dd756-0001 | 2 | My ambiguously named task | 
> RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
> The {{FrameworkID}} s could be links to the associated framework
> {code}
> 
>   {{framework.id | truncateMesosID}}
> 
> {code}
> -
> This involves additions to three tables:
> https://github.com/apache/mesos/blob/1.0.x/src/webui/master/static/home.html#L152-L157
> https://github.com/apache/mesos/blob/1.0.x/src/webui/master/static/home.html#L199-L205
> https://github.com/apache/mesos/blob/1.0.x/src/webui/master/static/home.html#L246-L252



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

[jira] [Commented] (MESOS-6369) Add a column for FrameworkID when displaying tasks in the WebUI

2016-10-31 Thread Miguel Bernadin (JIRA) 

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

Miguel Bernadin commented on MESOS-6369:


[~kaysoky], Sumbitted for review https://reviews.apache.org/r/53324/ to this 
that changes that look like this with modified field names: 

|| Framework ID || Task ID || Task Name || State || Started || Host || ||
| 179b5436-30ec-45e9-b324-fa5c5a1dd756- | 1 | My ambiguously named task | 
RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
| 179b5436-30ec-45e9-b324-fa5c5a1dd756-0001 | 1 | My ambiguously named task | 
RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
| 179b5436-30ec-45e9-b324-fa5c5a1dd756-0001 | 2 | My ambiguously named task | 
RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |


> Add a column for FrameworkID when displaying tasks in the WebUI
> ---
>
> Key: MESOS-6369
> URL: https://issues.apache.org/jira/browse/MESOS-6369
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Joseph Wu
>Assignee: Miguel Bernadin
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The Mesos Web UI home page shows a list of active/completed/orphan tasks 
> tasks like this:
> || ID || Name || State || Started || Host || ||
> | 1 | My ambiguously named task | RUNNING | 1 minute ago | 10.10.0.1 | 
> Sandbox |
> | 1 | My ambiguously named task | RUNNING | 1 minute ago | 10.10.0.1 | 
> Sandbox |
> | 2 | My ambiguously named task | RUNNING | 1 minute ago | 10.10.0.1 | 
> Sandbox |
> When you start multiple frameworks, the task IDs and names show in the UI may 
> be ambiguous, requiring extra clicks/investigation to disambiguate.  
> In the above case, to disambiguate between the two tasks with ID {{1}}, the 
> user would need to navigate to each sandbox and check the associated 
> frameworkID in the {{/browse}} view.  
> We could add a column showing the {{FrameworkID}} next to each task:
> || Framework || ID || Name || State || Started || Host || ||
> | 179b5436-30ec-45e9-b324-fa5c5a1dd756- | 1 | My ambiguously named task | 
> RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
> | 179b5436-30ec-45e9-b324-fa5c5a1dd756-0001 | 1 | My ambiguously named task | 
> RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
> | 179b5436-30ec-45e9-b324-fa5c5a1dd756-0001 | 2 | My ambiguously named task | 
> RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
> The {{FrameworkID}} s could be links to the associated framework
> {code}
> 
>   {{framework.id | truncateMesosID}}
> 
> {code}
> -
> This involves additions to three tables:
> https://github.com/apache/mesos/blob/1.0.x/src/webui/master/static/home.html#L152-L157
> https://github.com/apache/mesos/blob/1.0.x/src/webui/master/static/home.html#L199-L205
> https://github.com/apache/mesos/blob/1.0.x/src/webui/master/static/home.html#L246-L252



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

[jira] [Commented] (MESOS-6519) MasterTest.OrphanTasksMultipleAgents

2016-10-31 Thread Vinod Kone (JIRA) 

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

Vinod Kone commented on MESOS-6519:
---

This is due to the fact that we don't properly wait for both the agents to 
finish re-registration before querying the state endpoint.  If one of the 
agents re-tries the re-registration (e.g., auth timeout) master sends 2 
`SlaveReregisteredMessage` messages the following test code finishes which is 
incorrect.

{code}
  Future slaveReregisteredMessage1 =
FUTURE_PROTOBUF(SlaveReregisteredMessage(), _, _);

  Future slaveReregisteredMessage2 =
FUTURE_PROTOBUF(SlaveReregisteredMessage(), _, _);

  // Failover the master.
  master->reset();
  master = StartMaster();
  ASSERT_SOME(master);

  // Simulate a new master detected event to the slaves (but not the scheduler).
  slavesDetector.appoint(master.get()->pid);

  AWAIT_READY(slaveReregisteredMessage1);
  AWAIT_READY(slaveReregisteredMessage2);
{code}

Fix is to include the correct PID in the `FUTURE_PROTOBUF` calls.

> MasterTest.OrphanTasksMultipleAgents
> 
>
> Key: MESOS-6519
> URL: https://issues.apache.org/jira/browse/MESOS-6519
> Project: Mesos
>  Issue Type: Bug
>  Components: tests
>Reporter: Vinod Kone
>Assignee: Vinod Kone
>  Labels: flaky-test
>
> Observed this on ASF CI.
> {code}
> [ RUN  ] MasterTest.OrphanTasksMultipleAgents
> I1031 14:54:18.459671 31623 cluster.cpp:158] Creating default 'local' 
> authorizer
> I1031 14:54:18.462911 31623 leveldb.cpp:174] Opened db in 2.965951ms
> I1031 14:54:18.464269 31623 leveldb.cpp:181] Compacted db in 1.31548ms
> I1031 14:54:18.464326 31623 leveldb.cpp:196] Created db iterator in 13188ns
> I1031 14:54:18.464341 31623 leveldb.cpp:202] Seeked to beginning of db in 
> 1625ns
> I1031 14:54:18.464349 31623 leveldb.cpp:271] Iterated through 0 keys in the 
> db in 150ns
> I1031 14:54:18.464380 31623 replica.cpp:776] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1031 14:54:18.465016 31646 recover.cpp:451] Starting replica recovery
> I1031 14:54:18.465349 31646 recover.cpp:477] Replica is in EMPTY status
> I1031 14:54:18.466303 31647 replica.cpp:673] Replica in EMPTY status received 
> a broadcasted recover request from __req_res__(2991)@172.17.0.3:46956
> I1031 14:54:18.466681 31653 recover.cpp:197] Received a recover response from 
> a replica in EMPTY status
> I1031 14:54:18.467151 31649 recover.cpp:568] Updating replica status to 
> STARTING
> I1031 14:54:18.467964 31655 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 578744ns
> I1031 14:54:18.467994 31655 replica.cpp:320] Persisted replica status to 
> STARTING
> I1031 14:54:18.468024 31651 master.cpp:380] Master 
> 5098f7d2-2044-4dcd-b97f-9bd7c3dd1e27 (173b586c223f) started on 
> 172.17.0.3:46956
> I1031 14:54:18.468204 31655 recover.cpp:477] Replica is in STARTING status
> I1031 14:54:18.468040 31651 master.cpp:382] Flags at startup: --acls="" 
> --agent_ping_timeout="15secs" --agent_reregister_timeout="10mins" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate_agents="true" --authenticate_frameworks="true" 
> --authenticate_http_frameworks="true" --authenticate_http_readonly="true" 
> --authenticate_http_readwrite="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/ClEWj4/credentials" 
> --framework_sorter="drf" --help="false" --hostname_lookup="true" 
> --http_authenticators="basic" --http_framework_authenticators="basic" 
> --initialize_driver_logging="true" --log_auto_initialize="true" 
> --logbufsecs="0" --logging_level="INFO" --max_agent_ping_timeouts="5" 
> --max_completed_frameworks="50" --max_completed_tasks_per_framework="1000" 
> --quiet="false" --recovery_agent_removal_limit="100%" 
> --registry="replicated_log" --registry_fetch_timeout="1mins" 
> --registry_gc_interval="15mins" --registry_max_agent_age="2weeks" 
> --registry_max_agent_count="102400" --registry_store_timeout="100secs" 
> --registry_strict="false" --root_submissions="true" --user_sorter="drf" 
> --version="false" --webui_dir="/mesos/mesos-1.2.0/_inst/share/mesos/webui" 
> --work_dir="/tmp/ClEWj4/master" --zk_session_timeout="10secs"
> I1031 14:54:18.468483 31651 master.cpp:432] Master only allowing 
> authenticated frameworks to register
> I1031 14:54:18.468504 31651 master.cpp:446] Master only allowing 
> authenticated agents to register
> I1031 14:54:18.468520 31651 master.cpp:459] Master only allowing 
> authenticated HTTP frameworks to register
> I1031 14:54:18.468533 31651 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/ClEWj4/credentials'
> I1031 14:54:18.468837 31651 master.cpp:504] Using default 'crammd5' 
> authenticator
> I1031 14:54:18.469027 31651 http.cpp:887] Using

[jira] [Created] (MESOS-6519) MasterTest.OrphanTasksMultipleAgents

2016-10-31 Thread Vinod Kone (JIRA) 
Vinod Kone created MESOS-6519:
-

 Summary: MasterTest.OrphanTasksMultipleAgents
 Key: MESOS-6519
 URL: https://issues.apache.org/jira/browse/MESOS-6519
 Project: Mesos
  Issue Type: Bug
  Components: tests
Reporter: Vinod Kone
Assignee: Vinod Kone






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

[jira] [Assigned] (MESOS-6369) Add a column for FrameworkID when displaying tasks in the WebUI

2016-10-31 Thread Miguel Bernadin (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Miguel Bernadin reassigned MESOS-6369:
--

Assignee: Miguel Bernadin

> Add a column for FrameworkID when displaying tasks in the WebUI
> ---
>
> Key: MESOS-6369
> URL: https://issues.apache.org/jira/browse/MESOS-6369
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Joseph Wu
>Assignee: Miguel Bernadin
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The Mesos Web UI home page shows a list of active/completed/orphan tasks 
> tasks like this:
> || ID || Name || State || Started || Host || ||
> | 1 | My ambiguously named task | RUNNING | 1 minute ago | 10.10.0.1 | 
> Sandbox |
> | 1 | My ambiguously named task | RUNNING | 1 minute ago | 10.10.0.1 | 
> Sandbox |
> | 2 | My ambiguously named task | RUNNING | 1 minute ago | 10.10.0.1 | 
> Sandbox |
> When you start multiple frameworks, the task IDs and names show in the UI may 
> be ambiguous, requiring extra clicks/investigation to disambiguate.  
> In the above case, to disambiguate between the two tasks with ID {{1}}, the 
> user would need to navigate to each sandbox and check the associated 
> frameworkID in the {{/browse}} view.  
> We could add a column showing the {{FrameworkID}} next to each task:
> || Framework || ID || Name || State || Started || Host || ||
> | 179b5436-30ec-45e9-b324-fa5c5a1dd756- | 1 | My ambiguously named task | 
> RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
> | 179b5436-30ec-45e9-b324-fa5c5a1dd756-0001 | 1 | My ambiguously named task | 
> RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
> | 179b5436-30ec-45e9-b324-fa5c5a1dd756-0001 | 2 | My ambiguously named task | 
> RUNNING | 1 minute ago | 10.10.0.1 | Sandbox |
> The {{FrameworkID}} s could be links to the associated framework
> {code}
> 
>   {{framework.id | truncateMesosID}}
> 
> {code}
> -
> This involves additions to three tables:
> https://github.com/apache/mesos/blob/1.0.x/src/webui/master/static/home.html#L152-L157
> https://github.com/apache/mesos/blob/1.0.x/src/webui/master/static/home.html#L199-L205
> https://github.com/apache/mesos/blob/1.0.x/src/webui/master/static/home.html#L246-L252



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

[jira] [Created] (MESOS-6518) Mesos dashboard: Symlinks not displayed in sandbox view

2016-10-31 Thread JIRA 
Mischa Krüger created MESOS-6518:


 Summary: Mesos dashboard: Symlinks not displayed in sandbox view
 Key: MESOS-6518
 URL: https://issues.apache.org/jira/browse/MESOS-6518
 Project: Mesos
  Issue Type: Improvement
  Components: webui
Reporter: Mischa Krüger
Priority: Minor


Soft symbolic links do not appear in the sandbox, though they exist.



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

[jira] [Commented] (MESOS-6489) Better support for containers that want to manage their own cgroup.

2016-10-31 Thread Yan Xu (JIRA) 

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

Yan Xu commented on MESOS-6489:
---

+1 on passing a single cgroup to Destroyer.

> Better support for containers that want to manage their own cgroup.
> ---
>
> Key: MESOS-6489
> URL: https://issues.apache.org/jira/browse/MESOS-6489
> Project: Mesos
>  Issue Type: Improvement
>  Components: cgroups
>Reporter: Jie Yu
>  Labels: cgroups
>
> Some containers want to manage their cgroup by sub-dividing the cgroup that 
> Mesos allocates to them into multiple sub-cgroups and put subprocess into the 
> corresponding sub-cgroups.
> For instance, someone wants to run Docker daemon in a Mesos container. Docker 
> daemon will manage the cgroup assigned to it by Mesos (with the help , for 
> example, cgroups namespace).
> Problems arise during the teardown of the container because two entities 
> might be manipulating the same cgroup simultaneously. For example, the Mesos 
> cgroups::destroy might fail if the task running inside is trying to delete 
> the same nested cgroup at the same time.
> To support that case, we should consider kill all the processes in the Mesos 
> cgroup first, making sure that no one will be creating sub-cgroups and moving 
> new processes into sub-cgroups. And then, destroy the cgroups recursively.
> And we need freezer because we want to make sure all processes are stopped 
> while we are sending kill signals to avoid TOCTTOU race problem. I think it 
> makes more sense to freezer the cgroups (and sub-cgroups) from top down 
> (rather than bottom up because typically, processes in the parent cgroup 
> manipulate sub-cgroups).



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

[jira] [Updated] (MESOS-6349) JSON Generation breaks if other locale than C is used.

2016-10-31 Thread Alexander Rukletsov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-6349:
---
Target Version/s: 1.2.0

> JSON Generation breaks if other locale than C is used.
> --
>
> Key: MESOS-6349
> URL: https://issues.apache.org/jira/browse/MESOS-6349
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
>Reporter: Alexander Rojas
>
> In locales where the decimal separator is different from a {{.}}, i.e. Latin 
> American locales, Europe locales and most of asia, the JSON generated is 
> invalid, since it uses the system locale.
> Example, the following code will be generated:
> {code}
> {
>   "float_number" : 1234567,9871
> }
> {code}
> Instead of the expected:
> {code}
> {
>   "float_number" : 1234567.9871
> }
> {code}
> This problem doesn't affect Mesos executables since they completely ignore 
> the system's locale, but it does affect applications built in Java upon stout 
> and libprocess since the JVM does set the process locale to the system one.



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

[jira] [Updated] (MESOS-6349) JSON Generation breaks if other locale than C is used.

2016-10-31 Thread Alexander Rukletsov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-6349:
---
Summary: JSON Generation breaks if other locale than C is used.  (was: JSON 
Generation breaks if other locale than C is used)

> JSON Generation breaks if other locale than C is used.
> --
>
> Key: MESOS-6349
> URL: https://issues.apache.org/jira/browse/MESOS-6349
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
>Reporter: Alexander Rojas
>
> In locales where the decimal separator is different from a {{.}}, i.e. Latin 
> American locales, Europe locales and most of asia, the JSON generated is 
> invalid, since it uses the system locale.
> Example, the following code will be generated:
> {code}
> {
>   "float_number" : 1234567,9871
> }
> {code}
> Instead of the expected:
> {code}
> {
>   "float_number" : 1234567.9871
> }
> {code}
> This problem doesn't affect Mesos executables since they completely ignore 
> the system's locale, but it does affect applications built in Java upon stout 
> and libprocess since the JVM does set the process locale to the system one.



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

[jira] [Created] (MESOS-6517) Health checking only on 127.0.0.1 is limiting.

2016-10-31 Thread Alexander Rukletsov (JIRA) 
Alexander Rukletsov created MESOS-6517:
--

 Summary: Health checking only on 127.0.0.1 is limiting.
 Key: MESOS-6517
 URL: https://issues.apache.org/jira/browse/MESOS-6517
 Project: Mesos
  Issue Type: Improvement
Reporter: Alexander Rukletsov


As of Mesos 1.1.0, HTTP and TCP health checks always use 127.0.0.1 as the 
target IP. This is not configurable. As a result, tasks should listen on all 
interfaces if they want to support HTTP and TCP health checks. However, there 
might be some cases where tasks or containers will end up binding to a specific 
IP address. 

To make health checking more robust we can:
* look at all interfaces in a given network namespace and do health check on 
all the IP addresses;
* allow users to specify the IP to health check;
* deduce the target IP from task's discovery information.



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

[jira] [Commented] (MESOS-6457) Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.

2016-10-31 Thread Zhitao Li (JIRA) 

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

Zhitao Li commented on MESOS-6457:
--

Is this behavior only possible when framework opt-in to use Mesos's own health 
check (aka custom executors which do not use Mesos health check should not 
affected)?

> Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
> -
>
> Key: MESOS-6457
> URL: https://issues.apache.org/jira/browse/MESOS-6457
> Project: Mesos
>  Issue Type: Bug
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
>Priority: Blocker
>
> A task can currently transition from {{TASK_KILLING}} to {{TASK_RUNNING}}, if 
> for example it starts/stops passing a health check once it got into the 
> {{TASK_KILLING}} state.
> I think that this behaviour is counterintuitive. It also makes the life of 
> framework/tools developers harder, since they have to keep track of the 
> complete task status history in order to know if a task is being killed.



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

[jira] [Updated] (MESOS-6494) Clean up the flags parsing in the executors.

2016-10-31 Thread Alexander Rukletsov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-6494:
---
Summary: Clean up the flags parsing in the executors.  (was: Clean up the 
flags parsing in the executors)

> Clean up the flags parsing in the executors.
> 
>
> Key: MESOS-6494
> URL: https://issues.apache.org/jira/browse/MESOS-6494
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
>  Labels: mesosphere
>
> The current executors and the executor libraries use a mix of `stout::flags` 
> and `os::getenv` to parse flags, leading to a lot of unnecessary and 
> sometimes duplicated code.
> This should be cleaned up, using only {{stout::flags}} to parse flags.
> Environment variables should be used for the flags that are common to ALL the 
> executors (listed in the Executor HTTP API doc).
> Command line parameters should be used for flags that apply only to 
> individual executors.



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

[jira] [Updated] (MESOS-6396) Hooks should allow sandbox dependent environment variables.

2016-10-31 Thread Till Toenshoff (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Till Toenshoff updated MESOS-6396:
--
Shepherd: Kapil Arya
Assignee: Till Toenshoff

> Hooks should allow sandbox dependent environment variables.
> ---
>
> Key: MESOS-6396
> URL: https://issues.apache.org/jira/browse/MESOS-6396
> Project: Mesos
>  Issue Type: Improvement
>Affects Versions: 1.1.0
>Reporter: Till Toenshoff
>Assignee: Till Toenshoff
>  Labels: containerizer, docker, hooks, module
>
> The {{slaveExecutorEnvironmentDecorator}} hook is the only one that allows 
> mutating the executor environment of a Docker container. That callback has no 
> means of getting the location of the sandbox. That in turn means that it is 
> not possible for a hook to create files and respective environment variables 
> listing  paths within the sandbox for the executor to access.



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

[jira] [Updated] (MESOS-6457) Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.

2016-10-31 Thread Alexander Rukletsov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-6457:
---
Priority: Blocker  (was: Major)
 Summary: Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.  
(was: Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING)

> Tasks shouldn't transition from TASK_KILLING to TASK_RUNNING.
> -
>
> Key: MESOS-6457
> URL: https://issues.apache.org/jira/browse/MESOS-6457
> Project: Mesos
>  Issue Type: Bug
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
>Priority: Blocker
>
> A task can currently transition from {{TASK_KILLING}} to {{TASK_RUNNING}}, if 
> for example it starts/stops passing a health check once it got into the 
> {{TASK_KILLING}} state.
> I think that this behaviour is counterintuitive. It also makes the life of 
> framework/tools developers harder, since they have to keep track of the 
> complete task status history in order to know if a task is being killed.



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

[jira] [Updated] (MESOS-6516) Parallel test running does not respect GTEST_FILTER

2016-10-31 Thread Benjamin Bannier (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bannier updated MESOS-6516:

Shepherd: Till Toenshoff

> Parallel test running does not respect GTEST_FILTER
> ---
>
> Key: MESOS-6516
> URL: https://issues.apache.org/jira/browse/MESOS-6516
> Project: Mesos
>  Issue Type: Bug
>  Components: tests
>Reporter: Neil Conway
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> Normally, you can use {{GTEST_FILTER}} to control which tests will be run by 
> {{make check}}. However, this doesn't currently work if Mesos is configured 
> with {{--enable-parallel-test-execution}}.



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

[jira] [Assigned] (MESOS-6516) Parallel test running does not respect GTEST_FILTER

2016-10-31 Thread Benjamin Bannier (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bannier reassigned MESOS-6516:
---

Assignee: Benjamin Bannier

> Parallel test running does not respect GTEST_FILTER
> ---
>
> Key: MESOS-6516
> URL: https://issues.apache.org/jira/browse/MESOS-6516
> Project: Mesos
>  Issue Type: Bug
>  Components: tests
>Reporter: Neil Conway
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> Normally, you can use {{GTEST_FILTER}} to control which tests will be run by 
> {{make check}}. However, this doesn't currently work if Mesos is configured 
> with {{--enable-parallel-test-execution}}.



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

[jira] [Commented] (MESOS-6515) Parallel test runner + python3

2016-10-31 Thread Benjamin Bannier (JIRA) 

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

Benjamin Bannier commented on MESOS-6515:
-

It looks like our documentation might be lacking here as we almost never 
document that we assume only Python2 (the new cli being the only exception). 
Currently e.g., the getting started guides install Python2 which makes most 
tooling Python work implicitly. We as developers assume a certain runtime, but 
do not educate users on these assumptions.

Re:{{sys.maxsize}}, its value is too big to represent a time delta, but some 
defined max out of {{datetime}} might do the job.

> Parallel test runner + python3
> --
>
> Key: MESOS-6515
> URL: https://issues.apache.org/jira/browse/MESOS-6515
> Project: Mesos
>  Issue Type: Improvement
>  Components: tests
>Reporter: Neil Conway
>  Labels: mesosphere
>
> {noformat}
> [...]
> make[4]: Leaving directory '/home/vagrant/build-mesos-clang/src'
> /home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py 
> --sequential=*ROOT_* ./mesos-tests
> Traceback (most recent call last):
>   File 
> "/home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py", 
> line 218, in 
> timeout=sys.maxint))
> AttributeError: module 'sys' has no attribute 'maxint'
> $ python --version
> Python 3.5.2
> $ head config.log
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> It was created by mesos configure 1.2.0, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
>   $ ../mesos/configure --disable-python --enable-parallel-test-execution 
> --enable-silent-rules CXX=ccache clang++ CC=ccache clang
> {noformat}



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

[jira] [Commented] (MESOS-6515) Parallel test runner + python3

2016-10-31 Thread Neil Conway (JIRA) 

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

Neil Conway commented on MESOS-6515:


This is a test VM in which I don't usually use other {{support/}} scripts. At a 
minimum it would be nice to report an error during {{configure}}, rather than a 
cryptic runtime error.

For this particular problem, using {{sys.maxsize}} instead seems like an easy 
workaround.

> Parallel test runner + python3
> --
>
> Key: MESOS-6515
> URL: https://issues.apache.org/jira/browse/MESOS-6515
> Project: Mesos
>  Issue Type: Improvement
>  Components: tests
>Reporter: Neil Conway
>  Labels: mesosphere
>
> {noformat}
> [...]
> make[4]: Leaving directory '/home/vagrant/build-mesos-clang/src'
> /home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py 
> --sequential=*ROOT_* ./mesos-tests
> Traceback (most recent call last):
>   File 
> "/home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py", 
> line 218, in 
> timeout=sys.maxint))
> AttributeError: module 'sys' has no attribute 'maxint'
> $ python --version
> Python 3.5.2
> $ head config.log
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> It was created by mesos configure 1.2.0, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
>   $ ../mesos/configure --disable-python --enable-parallel-test-execution 
> --enable-silent-rules CXX=ccache clang++ CC=ccache clang
> {noformat}



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

[jira] [Updated] (MESOS-6515) Parallel test runner + python3

2016-10-31 Thread Benjamin Bannier (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bannier updated MESOS-6515:

Assignee: (was: Benjamin Bannier)

> Parallel test runner + python3
> --
>
> Key: MESOS-6515
> URL: https://issues.apache.org/jira/browse/MESOS-6515
> Project: Mesos
>  Issue Type: Improvement
>  Components: tests
>Reporter: Neil Conway
>  Labels: mesosphere
>
> {noformat}
> [...]
> make[4]: Leaving directory '/home/vagrant/build-mesos-clang/src'
> /home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py 
> --sequential=*ROOT_* ./mesos-tests
> Traceback (most recent call last):
>   File 
> "/home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py", 
> line 218, in 
> timeout=sys.maxint))
> AttributeError: module 'sys' has no attribute 'maxint'
> $ python --version
> Python 3.5.2
> $ head config.log
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> It was created by mesos configure 1.2.0, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
>   $ ../mesos/configure --disable-python --enable-parallel-test-execution 
> --enable-silent-rules CXX=ccache clang++ CC=ccache clang
> {noformat}



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

[jira] [Updated] (MESOS-6515) Parallel test runner + python3

2016-10-31 Thread Benjamin Bannier (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bannier updated MESOS-6515:

Issue Type: Improvement  (was: Bug)

> Parallel test runner + python3
> --
>
> Key: MESOS-6515
> URL: https://issues.apache.org/jira/browse/MESOS-6515
> Project: Mesos
>  Issue Type: Improvement
>  Components: tests
>Reporter: Neil Conway
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> {noformat}
> [...]
> make[4]: Leaving directory '/home/vagrant/build-mesos-clang/src'
> /home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py 
> --sequential=*ROOT_* ./mesos-tests
> Traceback (most recent call last):
>   File 
> "/home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py", 
> line 218, in 
> timeout=sys.maxint))
> AttributeError: module 'sys' has no attribute 'maxint'
> $ python --version
> Python 3.5.2
> $ head config.log
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> It was created by mesos configure 1.2.0, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
>   $ ../mesos/configure --disable-python --enable-parallel-test-execution 
> --enable-silent-rules CXX=ccache clang++ CC=ccache clang
> {noformat}



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

[jira] [Commented] (MESOS-6515) Parallel test runner + python3

2016-10-31 Thread Benjamin Bannier (JIRA) 

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

Benjamin Bannier commented on MESOS-6515:
-

Since we do not support using Python3 for scripts under {{support/}} I wonder 
how any of that infrastructure is useful in your environment. My guess is that 
we likely need to address this in a broader sense.

> Parallel test runner + python3
> --
>
> Key: MESOS-6515
> URL: https://issues.apache.org/jira/browse/MESOS-6515
> Project: Mesos
>  Issue Type: Bug
>  Components: tests
>Reporter: Neil Conway
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> {noformat}
> [...]
> make[4]: Leaving directory '/home/vagrant/build-mesos-clang/src'
> /home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py 
> --sequential=*ROOT_* ./mesos-tests
> Traceback (most recent call last):
>   File 
> "/home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py", 
> line 218, in 
> timeout=sys.maxint))
> AttributeError: module 'sys' has no attribute 'maxint'
> $ python --version
> Python 3.5.2
> $ head config.log
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> It was created by mesos configure 1.2.0, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
>   $ ../mesos/configure --disable-python --enable-parallel-test-execution 
> --enable-silent-rules CXX=ccache clang++ CC=ccache clang
> {noformat}



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

[jira] [Created] (MESOS-6516) Parallel test running does not respect GTEST_FILTER

2016-10-31 Thread Neil Conway (JIRA) 
Neil Conway created MESOS-6516:
--

 Summary: Parallel test running does not respect GTEST_FILTER
 Key: MESOS-6516
 URL: https://issues.apache.org/jira/browse/MESOS-6516
 Project: Mesos
  Issue Type: Bug
  Components: tests
Reporter: Neil Conway


Normally, you can use {{GTEST_FILTER}} to control which tests will be run by 
{{make check}}. However, this doesn't currently work if Mesos is configured 
with {{--enable-parallel-test-execution}}.



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

[jira] [Updated] (MESOS-6515) Parallel test runner + python3

2016-10-31 Thread Neil Conway (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neil Conway updated MESOS-6515:
---
Summary: Parallel test runner + python3  (was: Parallel test running + 
python3)

> Parallel test runner + python3
> --
>
> Key: MESOS-6515
> URL: https://issues.apache.org/jira/browse/MESOS-6515
> Project: Mesos
>  Issue Type: Bug
>  Components: tests
>Reporter: Neil Conway
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> {noformat}
> [...]
> make[4]: Leaving directory '/home/vagrant/build-mesos-clang/src'
> /home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py 
> --sequential=*ROOT_* ./mesos-tests
> Traceback (most recent call last):
>   File 
> "/home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py", 
> line 218, in 
> timeout=sys.maxint))
> AttributeError: module 'sys' has no attribute 'maxint'
> $ python --version
> Python 3.5.2
> $ head config.log
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> It was created by mesos configure 1.2.0, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
>   $ ../mesos/configure --disable-python --enable-parallel-test-execution 
> --enable-silent-rules CXX=ccache clang++ CC=ccache clang
> {noformat}



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

[jira] [Created] (MESOS-6515) Parallel test running + python3

2016-10-31 Thread Neil Conway (JIRA) 
Neil Conway created MESOS-6515:
--

 Summary: Parallel test running + python3
 Key: MESOS-6515
 URL: https://issues.apache.org/jira/browse/MESOS-6515
 Project: Mesos
  Issue Type: Bug
  Components: tests
Reporter: Neil Conway
Assignee: Benjamin Bannier


{noformat}
[...]
make[4]: Leaving directory '/home/vagrant/build-mesos-clang/src'
/home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py 
--sequential=*ROOT_* ./mesos-tests
Traceback (most recent call last):
  File 
"/home/vagrant/build-mesos-clang/../mesos/support/mesos-gtest-runner.py", line 
218, in 
timeout=sys.maxint))
AttributeError: module 'sys' has no attribute 'maxint'
$ python --version
Python 3.5.2
$ head config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by mesos configure 1.2.0, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ../mesos/configure --disable-python --enable-parallel-test-execution 
--enable-silent-rules CXX=ccache clang++ CC=ccache clang
{noformat}




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

[jira] [Assigned] (MESOS-6459) PosixRLimitsIsolatorTest.TaskExceedingLimit fails on OS X

2016-10-31 Thread Benjamin Bannier (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bannier reassigned MESOS-6459:
---

Assignee: Benjamin Bannier

> PosixRLimitsIsolatorTest.TaskExceedingLimit fails on OS X
> -
>
> Key: MESOS-6459
> URL: https://issues.apache.org/jira/browse/MESOS-6459
> Project: Mesos
>  Issue Type: Bug
>Reporter: Gastón Kleiman
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> This test consistently fails on OS X:
> {code}
> 31-7e9c-4248-acfd-21634150a657@172.28.128.1:64864 on agent 
> 52cc4957-1a39-4d66-ace6-5622fac3b85e-S0
> ../../src/tests/containerizer/posix_rlimits_isolator_tests.cpp:120: Failure
> Value of: statusFailed->state()
>   Actual: TASK_FINISHED
> Expected: TASK_FAILED
> {code}



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

[jira] [Assigned] (MESOS-6484) Memory leak in `Future::after()`

2016-10-31 Thread Alexander Rojas (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rojas reassigned MESOS-6484:
--

Assignee: Alexander Rojas

> Memory leak in `Future::after()`
> ---
>
> Key: MESOS-6484
> URL: https://issues.apache.org/jira/browse/MESOS-6484
> Project: Mesos
>  Issue Type: Bug
>  Components: libprocess
>Affects Versions: 1.1.0
>Reporter: Alexander Rojas
>Assignee: Alexander Rojas
>  Labels: libprocess, mesosphere
>
> The problem arises when one tries to associate an {{after()}} call to copied 
> futures. The following test case is enough to reproduce the issue:
> {code}
> TEST(FutureTest, After3)
> {
>   auto policy = std::make_shared(0);
>   {
> auto generator = []() {
>   return Future();
> };
> Future future = generator()
>   .after(Milliseconds(1),
> [policy](const Future&) {
>return Nothing();
> });
> AWAIT_READY(future);
>   }
>   EXPECT_EQ(1, policy.use_count());
> }
> {code}
> In the test, one would expect that there is only one active reference to 
> {{policy}}, therefore the expectation {{EXPECT_EQ(1, policy.use_count())}}. 
> However, if after is triggered more than once, each extra call adds one 
> undeleted reference to {{policy}}.



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

[jira] [Updated] (MESOS-6142) Frameworks may RESERVE for an arbitrary role.

2016-10-31 Thread Alexander Rukletsov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-6142:
---
Affects Version/s: 1.1.0
 Target Version/s: 1.2.0

> Frameworks may RESERVE for an arbitrary role.
> -
>
> Key: MESOS-6142
> URL: https://issues.apache.org/jira/browse/MESOS-6142
> Project: Mesos
>  Issue Type: Bug
>  Components: allocation, master
>Affects Versions: 1.0.0, 1.1.0
>Reporter: Alexander Rukletsov
>Assignee: Gastón Kleiman
>  Labels: mesosphere, reservations
>
> The master does not validate that resources from a reservation request have 
> the same role the framework is registered with. As a result, frameworks may 
> reserve resources for arbitrary roles.
> I've modified the role in [the {{ReserveThenUnreserve}} 
> test|https://github.com/apache/mesos/blob/bca600cf5602ed8227d91af9f73d689da14ad786/src/tests/reservation_tests.cpp#L117]
>  to "yoyo" and observed the following in the test's log:
> {noformat}
> I0908 18:35:43.379122 2138112 master.cpp:3362] Processing ACCEPT call for 
> offers: [ dfaf67e6-7c1c-4988-b427-c49842cb7bb7-O0 ] on agent 
> dfaf67e6-7c1c-4988-b427-c49842cb7bb7-S0 at slave(1)@10.200.181.237:60116 
> (alexr.railnet.train) for framework dfaf67e6-7c1c-4988-b427-c49842cb7bb7- 
> (default) at 
> scheduler-ca12a660-9f08-49de-be4e-d452aa3aa6da@10.200.181.237:60116
> I0908 18:35:43.379170 2138112 master.cpp:3022] Authorizing principal 
> 'test-principal' to reserve resources 'cpus(yoyo, test-principal):1; 
> mem(yoyo, test-principal):512'
> I0908 18:35:43.379678 2138112 master.cpp:3642] Applying RESERVE operation for 
> resources cpus(yoyo, test-principal):1; mem(yoyo, test-principal):512 from 
> framework dfaf67e6-7c1c-4988-b427-c49842cb7bb7- (default) at 
> scheduler-ca12a660-9f08-49de-be4e-d452aa3aa6da@10.200.181.237:60116 to agent 
> dfaf67e6-7c1c-4988-b427-c49842cb7bb7-S0 at slave(1)@10.200.181.237:60116 
> (alexr.railnet.train)
> I0908 18:35:43.379767 2138112 master.cpp:7341] Sending checkpointed resources 
> cpus(yoyo, test-principal):1; mem(yoyo, test-principal):512 to agent 
> dfaf67e6-7c1c-4988-b427-c49842cb7bb7-S0 at slave(1)@10.200.181.237:60116 
> (alexr.railnet.train)
> I0908 18:35:43.380273 3211264 slave.cpp:2497] Updated checkpointed resources 
> from  to cpus(yoyo, test-principal):1; mem(yoyo, test-principal):512
> I0908 18:35:43.380574 2674688 hierarchical.cpp:760] Updated allocation of 
> framework dfaf67e6-7c1c-4988-b427-c49842cb7bb7- on agent 
> dfaf67e6-7c1c-4988-b427-c49842cb7bb7-S0 from cpus(*):1; mem(*):512; 
> disk(*):470841; ports(*):[31000-32000] to ports(*):[31000-32000]; cpus(yoyo, 
> test-principal):1; disk(*):470841; mem(yoyo, test-principal):512 with RESERVE 
> operation
> {noformat}



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

[jira] [Updated] (MESOS-6184) Health checks should use a general mechanism to enter namespaces of the task.

2016-10-31 Thread Alexander Rukletsov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-6184:
---
Target Version/s: 1.2.0

> Health checks should use a general mechanism to enter namespaces of the task.
> -
>
> Key: MESOS-6184
> URL: https://issues.apache.org/jira/browse/MESOS-6184
> Project: Mesos
>  Issue Type: Improvement
>Reporter: haosdent
>Assignee: haosdent
>Priority: Blocker
>  Labels: health-check, mesosphere
>
> To perform health checks for tasks, we need to enter the corresponding 
> namespaces of the container. For now health check use custom clone to 
> implement this
> {code}
>   return process::defaultClone([=]() -> int {
> if (taskPid.isSome()) {
>   foreach (const string& ns, namespaces) {
> Try setns = ns::setns(taskPid.get(), ns);
> if (setns.isError()) {
>   ...
> }
>   }
> }
> return func();
>   });
> {code}
> After the childHooks patches merged, we could change the health check to use 
> childHooks to call {{setns}} and make {{process::defaultClone}} private 
> again.  



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

[jira] [Updated] (MESOS-5656) Incomplete modelling of 3rdparty dependencies in cmake build

2016-10-31 Thread Benjamin Bannier (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bannier updated MESOS-5656:

Assignee: (was: Benjamin Bannier)

> Incomplete modelling of 3rdparty dependencies in cmake build
> 
>
> Key: MESOS-5656
> URL: https://issues.apache.org/jira/browse/MESOS-5656
> Project: Mesos
>  Issue Type: Bug
>  Components: build, cmake
>Affects Versions: 1.0.0
>Reporter: Benjamin Bannier
>  Labels: mesosphere
>
> The cmake build incompletely models dependencies on 3rdparty components. This 
> leads to incomplete and unusable build files generated for e.g., ninja.
> When generating a build file for ninja the build fails to start
> {code}
> % ninja
> ninja: error: 
> '3rdparty/zookeeper-3.4.8/src/zookeeper-3.4.8/src/c/lib/libzookeeper_mt.a', 
> needed by 'src/slave/mesos-agent', missing and no known rule to make it
> {code}
> An identical problem exists with leveldb (apparent after working around the 
> zookeeper dep issue)
> {code}
> % ninja
> ninja: error: '3rdparty/leveldb-1.4/src/leveldb-1.4/libleveldb.a', needed by 
> 'src/slave/mesos-agent', missing and no known rule to make it
> {code}
> The problem here is that a number of targets depend on library files produced 
> implicitly via some {{ExternalProject}} library (via {{AGENT_LIBS}}), but we 
> fail to declare rules for these targets (I could imagine: via e.g., 
> {{add_library}} with {{IMPORTED}}). This appears to be no problem for build 
> files generate for {{make}} as it doesn't require rules for all dependency 
> nodes.
> It appears that one should be able to use {{ExternalProject_Add}}'s 
> {{BUILD_BYPRODUCTS}}, e.g.,
> {code}
> ExternalProject_Add(
>${ZOOKEEPER_TARGET}
>BUILD_BYPRODUCTS  ${ZOOKEEPER_LIB}/lib/libzookeeper_mt.a
>PREFIX${ZOOKEEPER_CMAKE_ROOT}
>PATCH_COMMAND ${ZOOKEEPER_PATCH_CMD}
>CONFIGURE_COMMAND ${ZOOKEEPER_CONFIG_CMD}
>...
> {code}
> to declare rules for these files, but this was only added in cmake-3.2 while 
> we at least formally require only cmake-2.8,
> {code}
> cmake_minimum_required(VERSION 2.8)
> {code}
> {{git bisect}} points to the recent 
> {{6e199cc255cbf561fac575568b0594ac2b2c14f9}} for surfacing this.



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

[jira] [Commented] (MESOS-5656) Incomplete modelling of 3rdparty dependencies in cmake build

2016-10-31 Thread Benjamin Bannier (JIRA) 

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

Benjamin Bannier commented on MESOS-5656:
-

Unassigning myself as there is no clear way forward.

> Incomplete modelling of 3rdparty dependencies in cmake build
> 
>
> Key: MESOS-5656
> URL: https://issues.apache.org/jira/browse/MESOS-5656
> Project: Mesos
>  Issue Type: Bug
>  Components: build, cmake
>Affects Versions: 1.0.0
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> The cmake build incompletely models dependencies on 3rdparty components. This 
> leads to incomplete and unusable build files generated for e.g., ninja.
> When generating a build file for ninja the build fails to start
> {code}
> % ninja
> ninja: error: 
> '3rdparty/zookeeper-3.4.8/src/zookeeper-3.4.8/src/c/lib/libzookeeper_mt.a', 
> needed by 'src/slave/mesos-agent', missing and no known rule to make it
> {code}
> An identical problem exists with leveldb (apparent after working around the 
> zookeeper dep issue)
> {code}
> % ninja
> ninja: error: '3rdparty/leveldb-1.4/src/leveldb-1.4/libleveldb.a', needed by 
> 'src/slave/mesos-agent', missing and no known rule to make it
> {code}
> The problem here is that a number of targets depend on library files produced 
> implicitly via some {{ExternalProject}} library (via {{AGENT_LIBS}}), but we 
> fail to declare rules for these targets (I could imagine: via e.g., 
> {{add_library}} with {{IMPORTED}}). This appears to be no problem for build 
> files generate for {{make}} as it doesn't require rules for all dependency 
> nodes.
> It appears that one should be able to use {{ExternalProject_Add}}'s 
> {{BUILD_BYPRODUCTS}}, e.g.,
> {code}
> ExternalProject_Add(
>${ZOOKEEPER_TARGET}
>BUILD_BYPRODUCTS  ${ZOOKEEPER_LIB}/lib/libzookeeper_mt.a
>PREFIX${ZOOKEEPER_CMAKE_ROOT}
>PATCH_COMMAND ${ZOOKEEPER_PATCH_CMD}
>CONFIGURE_COMMAND ${ZOOKEEPER_CONFIG_CMD}
>...
> {code}
> to declare rules for these files, but this was only added in cmake-3.2 while 
> we at least formally require only cmake-2.8,
> {code}
> cmake_minimum_required(VERSION 2.8)
> {code}
> {{git bisect}} points to the recent 
> {{6e199cc255cbf561fac575568b0594ac2b2c14f9}} for surfacing this.



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

[jira] [Comment Edited] (MESOS-6401) Authorizer interface should behave more uniform

2016-10-31 Thread Alexander Rojas (JIRA) 

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

Alexander Rojas edited comment on MESOS-6401 at 10/31/16 9:07 AM:
--

[r/52600/|https://reviews.apache.org/r/52600/]: Enable multiple field based 
authorization in the authorizer interface.
[r/53057/|https://reviews.apache.org/r/53057/]: Updates calls to the authorizer 
to use whole protobuf messages.
[r/53058/|https://reviews.apache.org/r/53058/]: Added tests for whole protobuf 
message based authorization.


was (Author: arojas):
[r/52600/|https://reviews.apache.org/r/52600/]: Enable multiple field based 
authorization in the authorizer interface.

> Authorizer interface should behave more uniform
> ---
>
> Key: MESOS-6401
> URL: https://issues.apache.org/jira/browse/MESOS-6401
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Alexander Rojas
>Assignee: Alexander Rojas
>
> As currently implemented, the Authorizer interface distinguish between two 
> types of authorizations, those suffixed with either {{_WITH_PRINCIPAL}} and 
> {{_WITH_ROLE}} and almost all other actions. While the former expect a single 
> value to perform authorization, the latter allow for multiple fields based on 
> whole protobuf messages.
> Since protobuf messages are associated with almost all authorization actions 
> (exceptions are {{VIEW_ROLES}} and {{GET_ENDPOINT_WITH_PATH}}, it makes sense 
> to standardize the way authorization is performed by using protobuf messages 
> for all actions that have one available.
> This will also help module writers which desire to create complex rules when 
> an action can be performed.



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

[jira] [Updated] (MESOS-3938) Consider allowing setting quotas for the default '*' role.

2016-10-31 Thread Alexander Rukletsov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-3938:
---
Shepherd:   (was: Joris Van Remoortere)
Assignee: (was: Alexander Rukletsov)
 Summary: Consider allowing setting quotas for the default '*' role.  (was: 
Allow setting quotas for the default '*' role)

> Consider allowing setting quotas for the default '*' role.
> --
>
> Key: MESOS-3938
> URL: https://issues.apache.org/jira/browse/MESOS-3938
> Project: Mesos
>  Issue Type: Task
>Reporter: Alexander Rukletsov
>
> Investigate use cases and implications of the possibility to set quota for 
> the '*' role. For example, having quota for '*' set can effectively reduce 
> the scope of the quota capacity heuristic.



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

[jira] [Updated] (MESOS-3875) Account dynamic reservations towards quota.

2016-10-31 Thread Alexander Rukletsov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-3875:
---
Shepherd:   (was: Joris Van Remoortere)
Assignee: (was: Alexander Rukletsov)

> Account dynamic reservations towards quota.
> ---
>
> Key: MESOS-3875
> URL: https://issues.apache.org/jira/browse/MESOS-3875
> Project: Mesos
>  Issue Type: Task
>  Components: allocation, master
>Reporter: Alexander Rukletsov
>  Labels: mesosphere
>
> Dynamic reservations—whether allocated or not—should be accounted towards 
> role's quota. This requires update in at least two places:
> * The built-in allocator, which actually satisfies quota;
> * The sanity check in the master.



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

[jira] [Updated] (MESOS-3875) Account dynamic reservations towards quota.

2016-10-31 Thread Alexander Rukletsov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-3875:
---
Summary: Account dynamic reservations towards quota.  (was: Account dynamic 
reservations towards quota)

> Account dynamic reservations towards quota.
> ---
>
> Key: MESOS-3875
> URL: https://issues.apache.org/jira/browse/MESOS-3875
> Project: Mesos
>  Issue Type: Task
>  Components: allocation, master
>Reporter: Alexander Rukletsov
>Assignee: Alexander Rukletsov
>  Labels: mesosphere
>
> Dynamic reservations—whether allocated or not—should be accounted towards 
> role's quota. This requires update in at least two places:
> * The built-in allocator, which actually satisfies quota;
> * The sanity check in the master.



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

[jira] [Updated] (MESOS-1791) Introduce Master / Offer Resource Reservations aka Quota.

2016-10-31 Thread Alexander Rukletsov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-1791:
---
Summary: Introduce Master / Offer Resource Reservations aka Quota.  (was: 
Introduce Master / Offer Resource Reservations aka Quota)

> Introduce Master / Offer Resource Reservations aka Quota.
> -
>
> Key: MESOS-1791
> URL: https://issues.apache.org/jira/browse/MESOS-1791
> Project: Mesos
>  Issue Type: Epic
>  Components: allocation, master, replicated log
>Reporter: Tom Arnfeld
>Assignee: Alexander Rukletsov
>  Labels: mesosphere
>
> Currently Mesos supports the ability to reserve resources (for a given role) 
> on a per-slave basis, as introduced in MESOS-505. This allows you to almost 
> statically partition off a set of resources on a set of machines, to 
> guarantee certain types of frameworks get some resources.
> This is very useful, though it is also very useful to be able to control 
> these reservations through the master (instead of per-slave) for when I don't 
> care which nodes I get on, as long as I get X cpu and Y RAM, or Z sets of 
> (X,Y).
> I'm not sure what structure this could take, but apparently it has already 
> been discussed. Would this be a CLI flag? Could there be a (authenticated) 
> web interface to control these reservations?
> Follow up epic: MESOS-6514.



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

[jira] [Updated] (MESOS-1791) Introduce Master / Offer Resource Reservations aka Quota

2016-10-31 Thread Alexander Rukletsov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-1791:
---
Description: 
Currently Mesos supports the ability to reserve resources (for a given role) on 
a per-slave basis, as introduced in MESOS-505. This allows you to almost 
statically partition off a set of resources on a set of machines, to guarantee 
certain types of frameworks get some resources.

This is very useful, though it is also very useful to be able to control these 
reservations through the master (instead of per-slave) for when I don't care 
which nodes I get on, as long as I get X cpu and Y RAM, or Z sets of (X,Y).

I'm not sure what structure this could take, but apparently it has already been 
discussed. Would this be a CLI flag? Could there be a (authenticated) web 
interface to control these reservations?

Follow up epic: MESOS-6514.

  was:
Currently Mesos supports the ability to reserve resources (for a given role) on 
a per-slave basis, as introduced in MESOS-505. This allows you to almost 
statically partition off a set of resources on a set of machines, to guarantee 
certain types of frameworks get some resources.

This is very useful, though it is also very useful to be able to control these 
reservations through the master (instead of per-slave) for when I don't care 
which nodes I get on, as long as I get X cpu and Y RAM, or Z sets of (X,Y).

I'm not sure what structure this could take, but apparently it has already been 
discussed. Would this be a CLI flag? Could there be a (authenticated) web 
interface to control these reservations?


> Introduce Master / Offer Resource Reservations aka Quota
> 
>
> Key: MESOS-1791
> URL: https://issues.apache.org/jira/browse/MESOS-1791
> Project: Mesos
>  Issue Type: Epic
>  Components: allocation, master, replicated log
>Reporter: Tom Arnfeld
>Assignee: Alexander Rukletsov
>  Labels: mesosphere
>
> Currently Mesos supports the ability to reserve resources (for a given role) 
> on a per-slave basis, as introduced in MESOS-505. This allows you to almost 
> statically partition off a set of resources on a set of machines, to 
> guarantee certain types of frameworks get some resources.
> This is very useful, though it is also very useful to be able to control 
> these reservations through the master (instead of per-slave) for when I don't 
> care which nodes I get on, as long as I get X cpu and Y RAM, or Z sets of 
> (X,Y).
> I'm not sure what structure this could take, but apparently it has already 
> been discussed. Would this be a CLI flag? Could there be a (authenticated) 
> web interface to control these reservations?
> Follow up epic: MESOS-6514.



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

[jira] [Created] (MESOS-6514) Improvements to quota.

2016-10-31 Thread Alexander Rukletsov (JIRA) 
Alexander Rukletsov created MESOS-6514:
--

 Summary: Improvements to quota.
 Key: MESOS-6514
 URL: https://issues.apache.org/jira/browse/MESOS-6514
 Project: Mesos
  Issue Type: Epic
  Components: allocation, master
Reporter: Alexander Rukletsov


This is a follow up epic to MESOS-1791 to capture further improvements and 
changes that need to be made after the MVP.



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