[jira] [Commented] (MESOS-6082) Add scheduler Call and Event based metrics to the master.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6082:
--

PR: 
https://reviews.apache.org/r/54572/
https://reviews.apache.org/r/54573/
https://reviews.apache.org/r/54574/

> Add scheduler Call and Event based metrics to the master.
> -
>
> Key: MESOS-6082
> URL: https://issues.apache.org/jira/browse/MESOS-6082
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Benjamin Mahler
>Assignee: Abhishek Dasgupta
>
> Currently, the master only has metrics for the old-style messages and these 
> are re-used for calls unfortunately:
> {code}
>   // Messages from schedulers.
>   process::metrics::Counter messages_register_framework;
>   process::metrics::Counter messages_reregister_framework;
>   process::metrics::Counter messages_unregister_framework;
>   process::metrics::Counter messages_deactivate_framework;
>   process::metrics::Counter messages_kill_task;
>   process::metrics::Counter messages_status_update_acknowledgement;
>   process::metrics::Counter messages_resource_request;
>   process::metrics::Counter messages_launch_tasks;
>   process::metrics::Counter messages_decline_offers;
>   process::metrics::Counter messages_revive_offers;
>   process::metrics::Counter messages_suppress_offers;
>   process::metrics::Counter messages_reconcile_tasks;
>   process::metrics::Counter messages_framework_to_executor;
> {code}
> Now that we've introduced the Call/Event based API, we should have metrics 
> that reflect this. For example:
> {code}
> {
>   scheduler/calls: 100
>   scheduler/calls/decline: 90,
>   scheduler/calls/accept: 10,
>   scheduler/calls/accept/operations/create: 1,
>   scheduler/calls/accept/operations/destroy: 0,
>   scheduler/calls/accept/operations/launch: 4,
>   scheduler/calls/accept/operations/launch_group: 2,
>   scheduler/calls/accept/operations/reserve: 1,
>   scheduler/calls/accept/operations/unreserve: 0,
>   scheduler/calls/kill: 0,
>   // etc
> }
> {code}



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

[jira] [Commented] (MESOS-6742) Adding support for s390x architecture

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6742:
--

For dev contributors list, you may raise a pull request in github. Please, send 
a mail to the dev mailing list as well to have the contributors access 
mentioning your reviewboard id and jira id.

> Adding support for s390x architecture 
> --
>
> Key: MESOS-6742
> URL: https://issues.apache.org/jira/browse/MESOS-6742
> Project: Mesos
>  Issue Type: Bug
>Reporter: Ayanampudi Varsha
>
> There are 2 issues:
> 1. LdcacheTest.Parse test case fails on s390x machines.
> 2. From the value of flag docker_registry in slave.cpp, amd64 images get 
> downloaded due to which test cases fail on s390x with "Exec format Error"



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

[jira] [Commented] (MESOS-6082) Add scheduler Call and Event based metrics to the master.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6082:
--

Yeah..working on this.. Very soon wd post RRs..

> Add scheduler Call and Event based metrics to the master.
> -
>
> Key: MESOS-6082
> URL: https://issues.apache.org/jira/browse/MESOS-6082
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Benjamin Mahler
>Assignee: Abhishek Dasgupta
>
> Currently, the master only has metrics for the old-style messages and these 
> are re-used for calls unfortunately:
> {code}
>   // Messages from schedulers.
>   process::metrics::Counter messages_register_framework;
>   process::metrics::Counter messages_reregister_framework;
>   process::metrics::Counter messages_unregister_framework;
>   process::metrics::Counter messages_deactivate_framework;
>   process::metrics::Counter messages_kill_task;
>   process::metrics::Counter messages_status_update_acknowledgement;
>   process::metrics::Counter messages_resource_request;
>   process::metrics::Counter messages_launch_tasks;
>   process::metrics::Counter messages_decline_offers;
>   process::metrics::Counter messages_revive_offers;
>   process::metrics::Counter messages_suppress_offers;
>   process::metrics::Counter messages_reconcile_tasks;
>   process::metrics::Counter messages_framework_to_executor;
> {code}
> Now that we've introduced the Call/Event based API, we should have metrics 
> that reflect this. For example:
> {code}
> {
>   scheduler/calls: 100
>   scheduler/calls/decline: 90,
>   scheduler/calls/accept: 10,
>   scheduler/calls/accept/operations/create: 1,
>   scheduler/calls/accept/operations/destroy: 0,
>   scheduler/calls/accept/operations/launch: 4,
>   scheduler/calls/accept/operations/launch_group: 2,
>   scheduler/calls/accept/operations/reserve: 1,
>   scheduler/calls/accept/operations/unreserve: 0,
>   scheduler/calls/kill: 0,
>   // etc
> }
> {code}



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

[jira] [Commented] (MESOS-6336) SlaveTest.KillTaskGroupBetweenRunTaskParts is flaky

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6336:
--

cc [~greggomann]  any update??


> SlaveTest.KillTaskGroupBetweenRunTaskParts is flaky
> ---
>
> Key: MESOS-6336
> URL: https://issues.apache.org/jira/browse/MESOS-6336
> Project: Mesos
>  Issue Type: Bug
>  Components: agent
>Reporter: Greg Mann
>Assignee: Abhishek Dasgupta
>  Labels: mesosphere
>
> The test {{SlaveTest.KillTaskGroupBetweenRunTaskParts}} sometimes segfaults 
> during the agent's {{finalize()}} method. This was observed on our internal 
> CI, on Fedora with libev, without SSL:
> {code}
> [ RUN  ] SlaveTest.KillTaskGroupBetweenRunTaskParts
> I1007 14:12:57.973811 28630 cluster.cpp:158] Creating default 'local' 
> authorizer
> I1007 14:12:57.982128 28630 leveldb.cpp:174] Opened db in 8.195028ms
> I1007 14:12:57.982599 28630 leveldb.cpp:181] Compacted db in 446238ns
> I1007 14:12:57.982616 28630 leveldb.cpp:196] Created db iterator in 3650ns
> I1007 14:12:57.982622 28630 leveldb.cpp:202] Seeked to beginning of db in 
> 451ns
> I1007 14:12:57.982627 28630 leveldb.cpp:271] Iterated through 0 keys in the 
> db in 352ns
> I1007 14:12:57.982638 28630 replica.cpp:776] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1007 14:12:57.983024 28645 recover.cpp:451] Starting replica recovery
> I1007 14:12:57.983127 28651 recover.cpp:477] Replica is in EMPTY status
> I1007 14:12:57.983459 28644 replica.cpp:673] Replica in EMPTY status received 
> a broadcasted recover request from __req_res__(6234)@172.30.2.161:38776
> I1007 14:12:57.983543 28651 recover.cpp:197] Received a recover response from 
> a replica in EMPTY status
> I1007 14:12:57.983680 28650 recover.cpp:568] Updating replica status to 
> STARTING
> I1007 14:12:57.983990 28648 master.cpp:380] Master 
> 76d4d55f-dcc6-4033-85d9-7ec97ef353cb 
> (ip-172-30-2-161.ec2.internal.mesosphere.io) started on 172.30.2.161:38776
> I1007 14:12:57.984007 28648 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/rVbcaO/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="/usr/local/share/mesos/webui" 
> --work_dir="/tmp/rVbcaO/master" --zk_session_timeout="10secs"
> I1007 14:12:57.984127 28648 master.cpp:432] Master only allowing 
> authenticated frameworks to register
> I1007 14:12:57.984134 28648 master.cpp:446] Master only allowing 
> authenticated agents to register
> I1007 14:12:57.984139 28648 master.cpp:459] Master only allowing 
> authenticated HTTP frameworks to register
> I1007 14:12:57.984143 28648 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/rVbcaO/credentials'
> I1007 14:12:57.988487 28648 master.cpp:504] Using default 'crammd5' 
> authenticator
> I1007 14:12:57.988530 28648 http.cpp:883] Using default 'basic' HTTP 
> authenticator for realm 'mesos-master-readonly'
> I1007 14:12:57.988585 28648 http.cpp:883] Using default 'basic' HTTP 
> authenticator for realm 'mesos-master-readwrite'
> I1007 14:12:57.988648 28648 http.cpp:883] Using default 'basic' HTTP 
> authenticator for realm 'mesos-master-scheduler'
> I1007 14:12:57.988680 28648 master.cpp:584] Authorization enabled
> I1007 14:12:57.988757 28650 whitelist_watcher.cpp:77] No whitelist given
> I1007 14:12:57.988772 28646 hierarchical.cpp:149] Initialized hierarchical 
> allocator process
> I1007 14:12:57.988917 28651 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 5.186917ms
> I1007 14:12:57.988934 28651 replica.cpp:320] Persisted replica status to 
> STARTING
> I1007 14:12:57.989045 28651 recover.cpp:477] Replica is in STARTING status
> I1007 14:12:57.989316 28648 master.cpp:2013] 

[jira] [Commented] (MESOS-6336) SlaveTest.KillTaskGroupBetweenRunTaskParts is flaky

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6336:
--

RR: https://reviews.apache.org/r/53173/

> SlaveTest.KillTaskGroupBetweenRunTaskParts is flaky
> ---
>
> Key: MESOS-6336
> URL: https://issues.apache.org/jira/browse/MESOS-6336
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>Reporter: Greg Mann
>Assignee: Abhishek Dasgupta
>  Labels: mesosphere
>
> The test {{SlaveTest.KillTaskGroupBetweenRunTaskParts}} sometimes segfaults 
> during the agent's {{finalize()}} method. This was observed on our internal 
> CI, on Fedora with libev, without SSL:
> {code}
> [ RUN  ] SlaveTest.KillTaskGroupBetweenRunTaskParts
> I1007 14:12:57.973811 28630 cluster.cpp:158] Creating default 'local' 
> authorizer
> I1007 14:12:57.982128 28630 leveldb.cpp:174] Opened db in 8.195028ms
> I1007 14:12:57.982599 28630 leveldb.cpp:181] Compacted db in 446238ns
> I1007 14:12:57.982616 28630 leveldb.cpp:196] Created db iterator in 3650ns
> I1007 14:12:57.982622 28630 leveldb.cpp:202] Seeked to beginning of db in 
> 451ns
> I1007 14:12:57.982627 28630 leveldb.cpp:271] Iterated through 0 keys in the 
> db in 352ns
> I1007 14:12:57.982638 28630 replica.cpp:776] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1007 14:12:57.983024 28645 recover.cpp:451] Starting replica recovery
> I1007 14:12:57.983127 28651 recover.cpp:477] Replica is in EMPTY status
> I1007 14:12:57.983459 28644 replica.cpp:673] Replica in EMPTY status received 
> a broadcasted recover request from __req_res__(6234)@172.30.2.161:38776
> I1007 14:12:57.983543 28651 recover.cpp:197] Received a recover response from 
> a replica in EMPTY status
> I1007 14:12:57.983680 28650 recover.cpp:568] Updating replica status to 
> STARTING
> I1007 14:12:57.983990 28648 master.cpp:380] Master 
> 76d4d55f-dcc6-4033-85d9-7ec97ef353cb 
> (ip-172-30-2-161.ec2.internal.mesosphere.io) started on 172.30.2.161:38776
> I1007 14:12:57.984007 28648 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/rVbcaO/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="/usr/local/share/mesos/webui" 
> --work_dir="/tmp/rVbcaO/master" --zk_session_timeout="10secs"
> I1007 14:12:57.984127 28648 master.cpp:432] Master only allowing 
> authenticated frameworks to register
> I1007 14:12:57.984134 28648 master.cpp:446] Master only allowing 
> authenticated agents to register
> I1007 14:12:57.984139 28648 master.cpp:459] Master only allowing 
> authenticated HTTP frameworks to register
> I1007 14:12:57.984143 28648 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/rVbcaO/credentials'
> I1007 14:12:57.988487 28648 master.cpp:504] Using default 'crammd5' 
> authenticator
> I1007 14:12:57.988530 28648 http.cpp:883] Using default 'basic' HTTP 
> authenticator for realm 'mesos-master-readonly'
> I1007 14:12:57.988585 28648 http.cpp:883] Using default 'basic' HTTP 
> authenticator for realm 'mesos-master-readwrite'
> I1007 14:12:57.988648 28648 http.cpp:883] Using default 'basic' HTTP 
> authenticator for realm 'mesos-master-scheduler'
> I1007 14:12:57.988680 28648 master.cpp:584] Authorization enabled
> I1007 14:12:57.988757 28650 whitelist_watcher.cpp:77] No whitelist given
> I1007 14:12:57.988772 28646 hierarchical.cpp:149] Initialized hierarchical 
> allocator process
> I1007 14:12:57.988917 28651 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 5.186917ms
> I1007 14:12:57.988934 28651 replica.cpp:320] Persisted replica status to 
> STARTING
> I1007 14:12:57.989045 28651 recover.cpp:477] Replica is in STARTING status
> I1007 14:12:57.989316 28648 

[jira] [Assigned] (MESOS-6336) SlaveTest.KillTaskGroupBetweenRunTaskParts is flaky

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-6336:


Assignee: Abhishek Dasgupta

> SlaveTest.KillTaskGroupBetweenRunTaskParts is flaky
> ---
>
> Key: MESOS-6336
> URL: https://issues.apache.org/jira/browse/MESOS-6336
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>Reporter: Greg Mann
>Assignee: Abhishek Dasgupta
>  Labels: mesosphere
>
> The test {{SlaveTest.KillTaskGroupBetweenRunTaskParts}} sometimes segfaults 
> during the agent's {{finalize()}} method. This was observed on our internal 
> CI, on Fedora with libev, without SSL:
> {code}
> [ RUN  ] SlaveTest.KillTaskGroupBetweenRunTaskParts
> I1007 14:12:57.973811 28630 cluster.cpp:158] Creating default 'local' 
> authorizer
> I1007 14:12:57.982128 28630 leveldb.cpp:174] Opened db in 8.195028ms
> I1007 14:12:57.982599 28630 leveldb.cpp:181] Compacted db in 446238ns
> I1007 14:12:57.982616 28630 leveldb.cpp:196] Created db iterator in 3650ns
> I1007 14:12:57.982622 28630 leveldb.cpp:202] Seeked to beginning of db in 
> 451ns
> I1007 14:12:57.982627 28630 leveldb.cpp:271] Iterated through 0 keys in the 
> db in 352ns
> I1007 14:12:57.982638 28630 replica.cpp:776] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1007 14:12:57.983024 28645 recover.cpp:451] Starting replica recovery
> I1007 14:12:57.983127 28651 recover.cpp:477] Replica is in EMPTY status
> I1007 14:12:57.983459 28644 replica.cpp:673] Replica in EMPTY status received 
> a broadcasted recover request from __req_res__(6234)@172.30.2.161:38776
> I1007 14:12:57.983543 28651 recover.cpp:197] Received a recover response from 
> a replica in EMPTY status
> I1007 14:12:57.983680 28650 recover.cpp:568] Updating replica status to 
> STARTING
> I1007 14:12:57.983990 28648 master.cpp:380] Master 
> 76d4d55f-dcc6-4033-85d9-7ec97ef353cb 
> (ip-172-30-2-161.ec2.internal.mesosphere.io) started on 172.30.2.161:38776
> I1007 14:12:57.984007 28648 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/rVbcaO/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="/usr/local/share/mesos/webui" 
> --work_dir="/tmp/rVbcaO/master" --zk_session_timeout="10secs"
> I1007 14:12:57.984127 28648 master.cpp:432] Master only allowing 
> authenticated frameworks to register
> I1007 14:12:57.984134 28648 master.cpp:446] Master only allowing 
> authenticated agents to register
> I1007 14:12:57.984139 28648 master.cpp:459] Master only allowing 
> authenticated HTTP frameworks to register
> I1007 14:12:57.984143 28648 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/rVbcaO/credentials'
> I1007 14:12:57.988487 28648 master.cpp:504] Using default 'crammd5' 
> authenticator
> I1007 14:12:57.988530 28648 http.cpp:883] Using default 'basic' HTTP 
> authenticator for realm 'mesos-master-readonly'
> I1007 14:12:57.988585 28648 http.cpp:883] Using default 'basic' HTTP 
> authenticator for realm 'mesos-master-readwrite'
> I1007 14:12:57.988648 28648 http.cpp:883] Using default 'basic' HTTP 
> authenticator for realm 'mesos-master-scheduler'
> I1007 14:12:57.988680 28648 master.cpp:584] Authorization enabled
> I1007 14:12:57.988757 28650 whitelist_watcher.cpp:77] No whitelist given
> I1007 14:12:57.988772 28646 hierarchical.cpp:149] Initialized hierarchical 
> allocator process
> I1007 14:12:57.988917 28651 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 5.186917ms
> I1007 14:12:57.988934 28651 replica.cpp:320] Persisted replica status to 
> STARTING
> I1007 14:12:57.989045 28651 recover.cpp:477] Replica is in STARTING status
> I1007 14:12:57.989316 28648 master.cpp:2013] Elected as the leading master!
> 

[jira] [Assigned] (MESOS-6352) Expose information about unreachable agents via operator API

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-6352:


Assignee: Abhishek Dasgupta

> Expose information about unreachable agents via operator API
> 
>
> Key: MESOS-6352
> URL: https://issues.apache.org/jira/browse/MESOS-6352
> Project: Mesos
>  Issue Type: Bug
>  Components: HTTP API
>Reporter: Neil Conway
>Assignee: Abhishek Dasgupta
>  Labels: mesosphere
>
> Operators would probably find information about the set of unreachable agents 
> useful. Two main use cases I can see: (a) identifying which agents are 
> currently unreachable and when they were marked unreachable, (b) 
> understanding the size/content of the registry as a way to debug registry 
> perf issues.



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

[jira] [Assigned] (MESOS-6294) TaskInfo should allow CommandInfo and ExecutorInfo

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-6294:


Assignee: Abhishek Dasgupta

> TaskInfo should allow CommandInfo and ExecutorInfo
> --
>
> Key: MESOS-6294
> URL: https://issues.apache.org/jira/browse/MESOS-6294
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Gabriel Hartmann
>Assignee: Abhishek Dasgupta
>
> It is awkward and difficult to support development of a generic custom 
> executor when TaskInfos may not contain both a CommandInfo and an 
> ExecutorInfo.
> A generic CustomExecutor would like to be able to use the CommandInfo of a 
> TaskInfo in the launchTask call to determine what action to take.  The mutual 
> exclusion of those two elements of a TaskInfo is not a good way to indicate a 
> desire to use the CmdExecutor or a CustomExecutor.



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

[jira] [Updated] (MESOS-5368) Consider introducing persistent agent ID

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-5368:
-
Assignee: (was: Abhishek Dasgupta)

> Consider introducing persistent agent ID
> 
>
> Key: MESOS-5368
> URL: https://issues.apache.org/jira/browse/MESOS-5368
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Neil Conway
>  Labels: mesosphere
>
> Currently, agent IDs identify a single "session" by an agent: that is, an 
> agent receives an agent ID when it registers with the master; it reuses that 
> agent ID if it disconnects and successfully reregisters; if the agent shuts 
> down and restarts, it registers anew and receives a new agent ID.
> It would be convenient to have a "persistent agent ID" that remains the same 
> for the duration of a given agent {{work_dir}}. This would mean that a given 
> persistent volume would not migrate between different persistent agent IDs 
> over time, for example (see MESOS-4894). If we supported permanently removing 
> an agent from the cluster (i.e., the {{work_dir}} and any volumes used by the 
> agent will never be reused), we could use the persistent agent ID to report 
> which agent has been removed.



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

[jira] [Commented] (MESOS-6298) Queued task groups should not be stored as queued tasks on the agent.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6298:
--

https://reviews.apache.org/r/52486/

> Queued task groups should not be stored as queued tasks on the agent.
> -
>
> Key: MESOS-6298
> URL: https://issues.apache.org/jira/browse/MESOS-6298
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: Abhishek Dasgupta
>  Labels: mesosphere, tech-debt
>
> Currently, we store the tasks in queued task groups {{queuedTaskGroups}} also 
> in {{queuedTasks}}. It would be great to decouple them and only have 
> {{queuedTasks}} for individual tasks.



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

[jira] [Assigned] (MESOS-6298) Queued task groups should not be stored as queued tasks on the agent.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-6298:


Assignee: Abhishek Dasgupta

> Queued task groups should not be stored as queued tasks on the agent.
> -
>
> Key: MESOS-6298
> URL: https://issues.apache.org/jira/browse/MESOS-6298
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: Abhishek Dasgupta
>  Labels: mesosphere, tech-debt
>
> Currently, we store the tasks in queued task groups {{queuedTaskGroups}} also 
> in {{queuedTasks}}. It would be great to decouple them and only have 
> {{queuedTasks}} for individual tasks.



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

[jira] [Commented] (MESOS-6261) Update webui to display nested containers.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6261:
--

Are we mainly talking about '/containers' endpoint here?? As I see sub-tasks 
are displayed properly under the executor in the webui.

> Update webui to display nested containers.
> --
>
> Key: MESOS-6261
> URL: https://issues.apache.org/jira/browse/MESOS-6261
> Project: Mesos
>  Issue Type: Task
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Abhishek Dasgupta
>
> With the addition of nested containers, the webui needs to be updated to 
> display the containers running underneath the executor.



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

[jira] [Assigned] (MESOS-6261) Update webui to display nested containers.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-6261:


Assignee: Abhishek Dasgupta

> Update webui to display nested containers.
> --
>
> Key: MESOS-6261
> URL: https://issues.apache.org/jira/browse/MESOS-6261
> Project: Mesos
>  Issue Type: Task
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Abhishek Dasgupta
>
> With the addition of nested containers, the webui needs to be updated to 
> display the containers running underneath the executor.



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

[jira] [Created] (MESOS-6256) Make install should also install mesos as service

[Abhishek Dasgupta (JIRA)]

Abhishek Dasgupta created MESOS-6256:


 Summary: Make install should also install mesos as service
 Key: MESOS-6256
 URL: https://issues.apache.org/jira/browse/MESOS-6256
 Project: Mesos
  Issue Type: Improvement
  Components: build
Reporter: Abhishek Dasgupta


Currently, ```make install``` install mesos only as binary and library i.e 
after you run ```make install``` you can run mesos-master as command as it is 
installed on your PATH. But we need to have provision to create service files 
as well through ```make install``` so that mesos can be started as ```service 
mesos-master start```. So far, it is achieved only through mesos-deb-packaging 
project, But it will be a good practice to integrate it into main mesos project.



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

[jira] [Created] (MESOS-6255) Improve task group details collection from user in mesos-execute.

[Abhishek Dasgupta (JIRA)]

Abhishek Dasgupta created MESOS-6255:


 Summary: Improve task group details collection from user in 
mesos-execute.
 Key: MESOS-6255
 URL: https://issues.apache.org/jira/browse/MESOS-6255
 Project: Mesos
  Issue Type: Improvement
Reporter: Abhishek Dasgupta
Priority: Minor


Currently in mesos-execute, details of tasks to be run in a task group are 
collected as JSON file from users eg. ```mesos-execute 
--master=: --task_group=```

In the task group JSON file, user has to provide agent id for each task though 
it is left blank.
"agent_id": {
"value": ""
}

This issue is to track if we can improve this so that user may omit agent_id in 
her JSON file.



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

[jira] [Updated] (MESOS-5447) Configurable agent memory reservation

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-5447:
-
Assignee: (was: Abhishek Dasgupta)

> Configurable agent memory reservation
> -
>
> Key: MESOS-5447
> URL: https://issues.apache.org/jira/browse/MESOS-5447
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Karl Isenberg
>
> When deciding what memory to make available to tasks (if not explicitly 
> configured), mesos agents currently reserve 1GB or 1/2 of system memory. 
> I'd really like to be able to configure the reservation amount so that I 
> don't have to reproduce the system memory lookup and math in order to 
> configure "mem=(system memory - reservation)".
> Ideally this would be configurable with a command line argument and 
> environment variable like "--reserved-memory=512".



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

[jira] [Updated] (MESOS-5229) Mesos containerizer should support file mounts

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-5229:
-
Assignee: (was: Abhishek Dasgupta)

> Mesos containerizer should support file mounts
> --
>
> Key: MESOS-5229
> URL: https://issues.apache.org/jira/browse/MESOS-5229
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Joshua Cohen
>
> When using an image to represent a container's file system, it's currently 
> not possible to mount a single file into the filesystem. I had to resort to 
> adding {{RUN touch /path/to/my/file}} in my Dockerfile in order to get the 
> filesystem provisioned properly.
> It would be great if this wasn't necessary. Even better would be if Mesos 
> would create all mount points on demand, rather than requiring them to be 
> present in the container filesystem (c.f. 
> https://github.com/apache/mesos/blob/master/src/slave/containerizer/mesos/isolators/filesystem/linux.cpp#L522-L527)



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

[jira] [Updated] (MESOS-5054) Namespace the stout flags

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-5054:
-
Assignee: (was: Abhishek Dasgupta)

> Namespace the stout flags
> -
>
> Key: MESOS-5054
> URL: https://issues.apache.org/jira/browse/MESOS-5054
> Project: Mesos
>  Issue Type: Improvement
>  Components: stout
>Affects Versions: 0.28.0
>Reporter: Greg Mann
>  Labels: mesosphere, stout
>
> A recent name collision occurred when updating the 3rdparty http-parser 
> library: 
> https://github.com/apache/mesos/commit/94df63f72146501872a06c6487e94bdfd0f23025
> We should put stout's {{flags}} namespace within another suitable namespace 
> (perhaps {{stout::flags}}) to avoid such collisions.



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

[jira] [Commented] (MESOS-6096) Update mesos-execute to support launching task groups

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6096:
--

Discarded as the design is changed: https://reviews.apache.org/r/51622/

New Patches:
https://reviews.apache.org/r/51978/
https://reviews.apache.org/r/51990/
https://reviews.apache.org/r/51991/
https://reviews.apache.org/r/51623

> 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
>Assignee: Abhishek Dasgupta
>
> 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-5072) Add variadic constructor for Option

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-5072:
-
Assignee: (was: Abhishek Dasgupta)

> Add variadic constructor for Option
> ---
>
> Key: MESOS-5072
> URL: https://issues.apache.org/jira/browse/MESOS-5072
> Project: Mesos
>  Issue Type: Improvement
>  Components: stout
>Reporter: Benjamin Bannier
>
> Currently an {{Option}} can be constructed from an {{U}} if in turn a 
> {{T}} is constructable from an {{U}}, e.g.,
> {code}
> // Construct a std::string from a string literal.
> Option s{"fnord"};
> {code}
> We should extend this to permit this kind of construct from more than one 
> parameter, i.e.,
> {code}
> // Construct a vector of strings from a string initializer list.
> Option v{"Browny", "Whitey", "Blacky"};
> {code}
> Currently users need to duplicate the type which e.g., poses the danger of
> inadvertently type conversions,
> {code}
> Option v{{"Browny", "Whitey", "Blacky"}};
> {code}
> It seems just making the {{U}} in the respective {{Option}} constructor
> variadic would already be enough to support this, but it would be highly
> desirable to remove explicit, redundant types in existing constructions of 
> {{Options}} in the code base.



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

[jira] [Commented] (MESOS-6144) Validate that TaskGroup executor and tasks do not use DOCKER ContainerInfo

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6144:
--

Patch : https://reviews.apache.org/r/51771/

> Validate that TaskGroup executor and tasks do not use DOCKER ContainerInfo
> --
>
> Key: MESOS-6144
> URL: https://issues.apache.org/jira/browse/MESOS-6144
> Project: Mesos
>  Issue Type: Bug
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>
> Only MESOS ContainerInfo is supported for now.



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

[jira] [Assigned] (MESOS-6144) Validate that TaskGroup executor and tasks do not use DOCKER ContainerInfo

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-6144:


Assignee: Abhishek Dasgupta

> Validate that TaskGroup executor and tasks do not use DOCKER ContainerInfo
> --
>
> Key: MESOS-6144
> URL: https://issues.apache.org/jira/browse/MESOS-6144
> Project: Mesos
>  Issue Type: Bug
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>
> Only MESOS ContainerInfo is supported for now.



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

[jira] [Updated] (MESOS-4811) Reusable/Cacheable Offer

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-4811:
-
Assignee: (was: Abhishek Dasgupta)

> Reusable/Cacheable Offer
> 
>
> Key: MESOS-4811
> URL: https://issues.apache.org/jira/browse/MESOS-4811
> Project: Mesos
>  Issue Type: Bug
>  Components: allocation
>Reporter: Klaus Ma
>  Labels: tech-debt
>
> Currently, the resources are return back to allocator when task finished; and 
> those resources are not allocated to framework until next allocation cycle. 
> The performance is low for short running tasks (MESOS-3078). The proposed 
> solution is to let framework keep using the offer until allocator decide to 
> rescind it.



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

[jira] [Commented] (MESOS-6096) Update mesos-execute to support launching task groups

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6096:
--

Took liberty to introduce new `--commands` option in mesos-execute. Expectiong 
suggestions if this is not intended.
Draft patches are here and they will run properly after TaskGroup support is 
completely implemented in master, agent and executor :

https://reviews.apache.org/r/51622/
https://reviews.apache.org/r/51623/

> 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
>Assignee: Abhishek Dasgupta
>
> 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] [Commented] (MESOS-6080) Expose metrics in scheduler library.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6080:
--

RR: https://reviews.apache.org/r/51501/

> Expose metrics in scheduler library.
> 
>
> Key: MESOS-6080
> URL: https://issues.apache.org/jira/browse/MESOS-6080
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Abhishek Dasgupta
>Assignee: Abhishek Dasgupta
>
> We are collecting metrics for scheduler 
> driver(https://github.com/apache/mesos/blob/master/src/sched/sched.cpp#L207) 
> but currently there is no way to expose metrics in scheduler 
> library(https://github.com/apache/mesos/blob/master/src/scheduler/scheduler.cpp).
>  So we need to expose metrics in scheduler library as well.



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

[jira] [Assigned] (MESOS-6096) Update mesos-execute to support launching task groups

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-6096:


Assignee: Abhishek Dasgupta

> 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
>Assignee: Abhishek Dasgupta
>
> 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] [Assigned] (MESOS-6082) Add scheduler Call and Event based metrics to the master.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-6082:


Assignee: Abhishek Dasgupta

> Add scheduler Call and Event based metrics to the master.
> -
>
> Key: MESOS-6082
> URL: https://issues.apache.org/jira/browse/MESOS-6082
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Benjamin Mahler
>Assignee: Abhishek Dasgupta
>
> Currently, the master only has metrics for the old-style messages and these 
> are re-used for calls unfortunately:
> {code}
>   // Messages from schedulers.
>   process::metrics::Counter messages_register_framework;
>   process::metrics::Counter messages_reregister_framework;
>   process::metrics::Counter messages_unregister_framework;
>   process::metrics::Counter messages_deactivate_framework;
>   process::metrics::Counter messages_kill_task;
>   process::metrics::Counter messages_status_update_acknowledgement;
>   process::metrics::Counter messages_resource_request;
>   process::metrics::Counter messages_launch_tasks;
>   process::metrics::Counter messages_decline_offers;
>   process::metrics::Counter messages_revive_offers;
>   process::metrics::Counter messages_suppress_offers;
>   process::metrics::Counter messages_reconcile_tasks;
>   process::metrics::Counter messages_framework_to_executor;
> {code}
> Now that we've introduced the Call/Event based API, we should have metrics 
> that reflect this. For example:
> {code}
> {
>   scheduler/calls: 100
>   scheduler/calls/decline: 90,
>   scheduler/calls/accept: 10,
>   scheduler/calls/accept/operations/create: 1,
>   scheduler/calls/accept/operations/destroy: 0,
>   scheduler/calls/accept/operations/launch: 4,
>   scheduler/calls/accept/operations/launch_group: 2,
>   scheduler/calls/accept/operations/reserve: 1,
>   scheduler/calls/accept/operations/unreserve: 0,
>   scheduler/calls/kill: 0,
>   // etc
> }
> {code}



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

[jira] [Assigned] (MESOS-6083) Add executor Call and Event based metrics to the agent.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-6083:


Assignee: Abhishek Dasgupta

> Add executor Call and Event based metrics to the agent.
> ---
>
> Key: MESOS-6083
> URL: https://issues.apache.org/jira/browse/MESOS-6083
> Project: Mesos
>  Issue Type: Improvement
>  Components: slave
>Reporter: Benjamin Mahler
>Assignee: Abhishek Dasgupta
>
> Now that we've introduced the Call/Event based API for executors, we should 
> have metrics that reflect this. For example:
> {code}
> {
>   executor/calls: 100
>   executor/calls/message: 90,
>   executor/calls/update: 10,
>   // etc
> }
> {code}



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

[jira] [Created] (MESOS-6080) Expose metrics i.e SchedulerProcess::event_queue_messages, SchedulerProcess::event_queue_dispatches in scheduler library.

[Abhishek Dasgupta (JIRA)]

Abhishek Dasgupta created MESOS-6080:


 Summary: Expose metrics i.e 
SchedulerProcess::event_queue_messages, 
SchedulerProcess::event_queue_dispatches in scheduler library.
 Key: MESOS-6080
 URL: https://issues.apache.org/jira/browse/MESOS-6080
 Project: Mesos
  Issue Type: Improvement
Reporter: Abhishek Dasgupta
Assignee: Abhishek Dasgupta


We are collecting metrics for scheduler 
driver(https://github.com/apache/mesos/blob/master/src/sched/sched.cpp#L207) 
but currently there is no way to expose these metrics in scheduler 
library(https://github.com/apache/mesos/blob/master/src/scheduler/scheduler.cpp).
 So we need to expose these metrics in scheduler library as well.



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

[jira] [Commented] (MESOS-6041) Stream ID mismatch should print out expected and received stream ID

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6041:
--

Trivial Patch: https://reviews.apache.org/r/51342/

> Stream ID mismatch should print out expected and received stream ID
> ---
>
> Key: MESOS-6041
> URL: https://issues.apache.org/jira/browse/MESOS-6041
> Project: Mesos
>  Issue Type: Bug
>  Components: HTTP API
>Affects Versions: 1.0.0
>Reporter: Zameer Manji
>Assignee: Abhishek Dasgupta
>
> If you send an incorrect stream id via the HTTP API the master responds with:
> {noformat}
> The stream ID included in this request didn't match the stream ID currently 
> associated with framework ID '0dffbee9-a514-4ffa-87e1-2850dd4dcf00'`
> {noformat}
> This error message should be enhanced to include the expected and received 
> stream id to aide debugging. 



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

[jira] [Commented] (MESOS-6071) Validate that an explicitly specified DEFAULT executor has disk resources.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6071:
--

Is anyone actively working on this? I would like to take up this issue.
cc [~bmahler]

> Validate that an explicitly specified DEFAULT executor has disk resources.
> --
>
> Key: MESOS-6071
> URL: https://issues.apache.org/jira/browse/MESOS-6071
> Project: Mesos
>  Issue Type: Task
>  Components: master
>Reporter: Benjamin Mahler
>
> When the framework is explicitly specifying the DEFAULT executor (currently 
> only supported for task groups), we should consider validating that it 
> contains disk resources. Currently, we validate that explicitly specified 
> (DEFAULT or CUSTOM) executors only contain cpus and mem.
> We should also consider supporting the omission of DEFAULT executor resources 
> and injecting a default amount of resources. However, the difficulty here is 
> that the framework must know about these amounts since they need to be 
> available in the offer. We could expose these to the framework during 
> framework registration.



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

[jira] [Commented] (MESOS-6071) Validate that an explicitly specified DEFAULT executor has disk resources.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-6071:
--

Is anyone actively working on this? I would like to take up this issue.
cc [~bmahler]

> Validate that an explicitly specified DEFAULT executor has disk resources.
> --
>
> Key: MESOS-6071
> URL: https://issues.apache.org/jira/browse/MESOS-6071
> Project: Mesos
>  Issue Type: Task
>  Components: master
>Reporter: Benjamin Mahler
>
> When the framework is explicitly specifying the DEFAULT executor (currently 
> only supported for task groups), we should consider validating that it 
> contains disk resources. Currently, we validate that explicitly specified 
> (DEFAULT or CUSTOM) executors only contain cpus and mem.
> We should also consider supporting the omission of DEFAULT executor resources 
> and injecting a default amount of resources. However, the difficulty here is 
> that the framework must know about these amounts since they need to be 
> available in the offer. We could expose these to the framework during 
> framework registration.



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

[jira] [Assigned] (MESOS-6041) Stream ID mismatch should print out expected and received stream ID

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-6041:


Assignee: Abhishek Dasgupta

> Stream ID mismatch should print out expected and received stream ID
> ---
>
> Key: MESOS-6041
> URL: https://issues.apache.org/jira/browse/MESOS-6041
> Project: Mesos
>  Issue Type: Bug
>  Components: HTTP API
>Affects Versions: 1.0.0
>Reporter: Zameer Manji
>Assignee: Abhishek Dasgupta
>
> If you send an incorrect stream id via the HTTP API the master responds with:
> {noformat}
> The stream ID included in this request didn't match the stream ID currently 
> associated with framework ID '0dffbee9-a514-4ffa-87e1-2850dd4dcf00'`
> {noformat}
> This error message should be enhanced to include the expected and received 
> stream id to aide debugging. 



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

[jira] [Commented] (MESOS-5797) Use shared_ptr instead of raw pointer for mesos::Authorizer in slave and master initialization.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5797:
--

cc [~adam-mesos]

> Use shared_ptr instead of raw pointer for mesos::Authorizer in slave and 
> master initialization.
> ---
>
> Key: MESOS-5797
> URL: https://issues.apache.org/jira/browse/MESOS-5797
> Project: Mesos
>  Issue Type: Bug
>  Components: general
>Reporter: Abhishek Dasgupta
>Assignee: Abhishek Dasgupta
>
> Like in slave.hpp, to initialize Slave instance, we are using "const 
> Option& authorizer" raw pointer. Instead of a raw pointer, we 
> may use shared_ptr here as this pointer might be shared among other objects 
> also to support authorization in those. 
> Similarly, it can be done for master initialization also.



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

[jira] [Commented] (MESOS-5797) Use shared_ptr instead of raw pointer for mesos::Authorizer in slave and master initialization.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5797:
--

I am planning to start working on this.

So, just to confirm - should we change all raw pointers to shared_ptr for 
Authorizers starting from "include/mesos/authorizer/authorizer.hpp" ?

IMO, it doesn't look good design if we just try to change Authorizer from raw 
pointer to shared_ptr only in master, slave and files code because this would 
require many back-and-forth conversions from shared_ptr to raw (or raw pointers 
to shared_ptr).

> Use shared_ptr instead of raw pointer for mesos::Authorizer in slave and 
> master initialization.
> ---
>
> Key: MESOS-5797
> URL: https://issues.apache.org/jira/browse/MESOS-5797
> Project: Mesos
>  Issue Type: Bug
>  Components: general
>Reporter: Abhishek Dasgupta
>Assignee: Abhishek Dasgupta
>
> Like in slave.hpp, to initialize Slave instance, we are using "const 
> Option& authorizer" raw pointer. Instead of a raw pointer, we 
> may use shared_ptr here as this pointer might be shared among other objects 
> also to support authorization in those. 
> Similarly, it can be done for master initialization also.



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

[jira] [Commented] (MESOS-5992) Complete the list of API Calls on the Operator HTTP API Doc

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5992:
--

RR : https://reviews.apache.org/r/50974/

> Complete the list of API Calls on the Operator HTTP API Doc
> ---
>
> Key: MESOS-5992
> URL: https://issues.apache.org/jira/browse/MESOS-5992
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: Abhishek Dasgupta
>  Labels: documentation, mesosphere
>
> Currently, the Operator HTTP API doc only has limited information about the 
> different types of calls it supports. It would be a good exercise to complete 
> the doc with a list of all the supported calls for the Master/Agent API with 
> some description about them/relevant code snippets.



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

[jira] [Commented] (MESOS-5853) http v1 API should document behavior regarding generated content-type header in the presence of errors

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5853:
--

RR: https://reviews.apache.org/r/50713/

> http v1 API should document behavior regarding generated content-type header 
> in the presence of errors
> --
>
> Key: MESOS-5853
> URL: https://issues.apache.org/jira/browse/MESOS-5853
> Project: Mesos
>  Issue Type: Improvement
>  Components: documentation
>Reporter: James DeFelice
>Assignee: Abhishek Dasgupta
>  Labels: mesosphere
>
> Changes made as part of https://issues.apache.org/jira/browse/MESOS-3739 set 
> a default Content-Type header. This should be documented in the Mesos v1 HTTP 
> API literature so that devs implementing against the spec know what to expect.



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

[jira] [Commented] (MESOS-5790) Ensure all examples in Scheduler HTTP API docs are valid JSON

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5790:
--

RR: https://reviews.apache.org/r/50626/

> Ensure all examples in Scheduler HTTP API docs are valid JSON
> -
>
> Key: MESOS-5790
> URL: https://issues.apache.org/jira/browse/MESOS-5790
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: Abhishek Dasgupta
>  Labels: mesosphere, newbie
>
> Currently, there are a lot of JSON snippets in the [API Docs | 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ ] that are 
> not valid JSON i.e. have {{...}} to make the snippet succinct/easy to read. 
> e.g., 
> {code}
> {{"filters"   : {...}
> {code} 
> However, this is a problem for framework developers who are trying to use the 
> new API. Looking at the corresponding protobuf definitions can be a good 
> place to start but hardly ideal.
> It would be good to address the shortcomings and make the JSON snippets 
> complete.



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

[jira] [Commented] (MESOS-5732) MasterAPITest.UnreserveResources is slow

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5732:
--

A trivial RR to increase clarity of the test case: 
https://reviews.apache.org/r/50528/

> MasterAPITest.UnreserveResources is slow
> 
>
> Key: MESOS-5732
> URL: https://issues.apache.org/jira/browse/MESOS-5732
> Project: Mesos
>  Issue Type: Improvement
>  Components: tests
>Reporter: Neil Conway
>Assignee: Abhishek Dasgupta
>  Labels: mesosphere
> Fix For: 1.1.0
>
>
> {noformat}
> [ RUN  ] ContentType/MasterAPITest.UnreserveResources/0
> [   OK ] ContentType/MasterAPITest.UnreserveResources/0 (6033 ms)
> [ RUN  ] ContentType/MasterAPITest.UnreserveResources/1
> [   OK ] ContentType/MasterAPITest.UnreserveResources/1 (6041 ms)
> {noformat}



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

[jira] [Commented] (MESOS-5858) Operator API should accept the request with charset specified in Content-Type

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5858:
--

RR:
https://reviews.apache.org/r/50246/
https://reviews.apache.org/r/50249/

cc: [~dongdong] Please check if it meets your requirements.


> Operator API should accept the request with charset specified in Content-Type
> -
>
> Key: MESOS-5858
> URL: https://issues.apache.org/jira/browse/MESOS-5858
> Project: Mesos
>  Issue Type: Bug
>Reporter: zhou xing
>Assignee: Abhishek Dasgupta
>Priority: Minor
>
> When requesting from client like WebUI, the Content-Type of the request maybe 
> set to
> ```application/json; charset=utf-8```
> , the request will get 415 response code with message
> ```Expecting 'Content-Type' of application/json or application/x-protobuf```
> The following code in http.cpp just compare the content-type of the request 
> directly with “application/json” or “application/x-protobuf”:
> ```...
>   if (contentType.get() == APPLICATION_PROTOBUF) {
> if (!v1Call.ParseFromString(request.body)) {
>   return BadRequest("Failed to parse body into Call protobuf");
> }
>   } else if (contentType.get() == APPLICATION_JSON) {
> …
> We need to accept a request with charset set in Content-Type



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

[jira] [Assigned] (MESOS-5858) Operator API should accept the request with charset specified in Content-Type

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5858:


Assignee: Abhishek Dasgupta

> Operator API should accept the request with charset specified in Content-Type
> -
>
> Key: MESOS-5858
> URL: https://issues.apache.org/jira/browse/MESOS-5858
> Project: Mesos
>  Issue Type: Bug
>Reporter: zhou xing
>Assignee: Abhishek Dasgupta
>Priority: Minor
>
> When requesting from client like WebUI, the Content-Type of the request maybe 
> set to
> ```application/json; charset=utf-8```
> , the request will get 415 response code with message
> ```Expecting 'Content-Type' of application/json or application/x-protobuf```
> The following code in http.cpp just compare the content-type of the request 
> directly with “application/json” or “application/x-protobuf”:
> ```...
>   if (contentType.get() == APPLICATION_PROTOBUF) {
> if (!v1Call.ParseFromString(request.body)) {
>   return BadRequest("Failed to parse body into Call protobuf");
> }
>   } else if (contentType.get() == APPLICATION_JSON) {
> …
> We need to accept a request with charset set in Content-Type



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

[jira] [Assigned] (MESOS-3548) Investigate federations of Mesos masters

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-3548:


Assignee: Abhishek Dasgupta

> Investigate federations of Mesos masters
> 
>
> Key: MESOS-3548
> URL: https://issues.apache.org/jira/browse/MESOS-3548
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Neil Conway
>Assignee: Abhishek Dasgupta
>  Labels: federation, mesosphere, multi-dc
>
> In a large Mesos installation, the operator might want to ensure that even if 
> the Mesos masters are inaccessible or failed, new tasks can still be 
> scheduled (across multiple different frameworks). HA masters are only a 
> partial solution here: the masters might still be inaccessible due to a 
> correlated failure (e.g., Zookeeper misconfiguration/human error).
> To support this, we could support the notion of "hierarchies" or 
> "federations" of Mesos masters. In a Mesos installation with 10k machines, 
> the operator might configure 10 Mesos masters (each of which might be HA) to 
> manage 1k machines each. Then an additional "meta-Master" would manage the 
> allocation of cluster resources to the 10 masters. Hence, the failure of any 
> individual master would impact 1k machines at most. The meta-master might not 
> have a lot of work to do: e.g., it might be limited to occasionally 
> reallocating cluster resources among the 10 masters, or ensuring that newly 
> added cluster resources are allocated among the masters as appropriate. 
> Hence, the failure of the meta-master would not prevent any of the individual 
> masters from scheduling new tasks. A single framework instance probably 
> wouldn't be able to use more resources than have been assigned to a single 
> Master, but that seems like a reasonable restriction.
> This feature might also be a good fit for a multi-datacenter deployment of 
> Mesos: each Mesos master instance would manage a single DC. Naturally, 
> reducing the traffic between frameworks and the meta-master would be 
> important for performance reasons in a configuration like this.
> Operationally, this might be simpler if Mesos processes were self-hosting 
> ([MESOS-3547]).



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

[jira] [Updated] (MESOS-3548) Investigate federations of Mesos masters

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-3548:
-
Assignee: (was: Abhishek Dasgupta)

> Investigate federations of Mesos masters
> 
>
> Key: MESOS-3548
> URL: https://issues.apache.org/jira/browse/MESOS-3548
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Neil Conway
>  Labels: federation, mesosphere, multi-dc
>
> In a large Mesos installation, the operator might want to ensure that even if 
> the Mesos masters are inaccessible or failed, new tasks can still be 
> scheduled (across multiple different frameworks). HA masters are only a 
> partial solution here: the masters might still be inaccessible due to a 
> correlated failure (e.g., Zookeeper misconfiguration/human error).
> To support this, we could support the notion of "hierarchies" or 
> "federations" of Mesos masters. In a Mesos installation with 10k machines, 
> the operator might configure 10 Mesos masters (each of which might be HA) to 
> manage 1k machines each. Then an additional "meta-Master" would manage the 
> allocation of cluster resources to the 10 masters. Hence, the failure of any 
> individual master would impact 1k machines at most. The meta-master might not 
> have a lot of work to do: e.g., it might be limited to occasionally 
> reallocating cluster resources among the 10 masters, or ensuring that newly 
> added cluster resources are allocated among the masters as appropriate. 
> Hence, the failure of the meta-master would not prevent any of the individual 
> masters from scheduling new tasks. A single framework instance probably 
> wouldn't be able to use more resources than have been assigned to a single 
> Master, but that seems like a reasonable restriction.
> This feature might also be a good fit for a multi-datacenter deployment of 
> Mesos: each Mesos master instance would manage a single DC. Naturally, 
> reducing the traffic between frameworks and the meta-master would be 
> important for performance reasons in a configuration like this.
> Operationally, this might be simpler if Mesos processes were self-hosting 
> ([MESOS-3547]).



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

[jira] [Commented] (MESOS-5613) mesos-local fails to start if MESOS_WORK_DIR isn't set.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5613:
--

I may need another 3-4 days to start working on it but if [~ammar2] can start 
working in between, he may take up this issue.

> mesos-local fails to start if MESOS_WORK_DIR isn't set.
> ---
>
> Key: MESOS-5613
> URL: https://issues.apache.org/jira/browse/MESOS-5613
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jan Schlicht
>Assignee: Abhishek Dasgupta
>
> Running {{mesos-local}} fails with
> {noformat}
> Failed to start a local cluster while loading agent flags from the 
> environment: Flag 'work_dir' is required, but it was not provided
> {noformat}
> if {{MESOS_WORK_DIR}} isn't set.
> This seems to be due to the changed behavior of making the {{work_dir}} flag 
> mandatory (MESOS-5064). While {{MESOS_WORK_DIR}} is being set in a 
> development environment in {{./bin/mesos-local.sh}}, this isn't true if 
> {{mesos-local}} is installed on the system after a {{make install}}.



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

[jira] [Commented] (MESOS-4811) Reusable/Cacheable Offer

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-4811:
--

Anyone actively working on this?? I may take up this issue if not.

> Reusable/Cacheable Offer
> 
>
> Key: MESOS-4811
> URL: https://issues.apache.org/jira/browse/MESOS-4811
> Project: Mesos
>  Issue Type: Bug
>  Components: allocation
>Reporter: Klaus Ma
>Assignee: Abhishek Dasgupta
>  Labels: tech-debt
>
> Currently, the resources are return back to allocator when task finished; and 
> those resources are not allocated to framework until next allocation cycle. 
> The performance is low for short running tasks (MESOS-3078). The proposed 
> solution is to let framework keep using the offer until allocator decide to 
> rescind it.



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

[jira] [Assigned] (MESOS-4811) Reusable/Cacheable Offer

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-4811:


Assignee: Abhishek Dasgupta

> Reusable/Cacheable Offer
> 
>
> Key: MESOS-4811
> URL: https://issues.apache.org/jira/browse/MESOS-4811
> Project: Mesos
>  Issue Type: Bug
>  Components: allocation
>Reporter: Klaus Ma
>Assignee: Abhishek Dasgupta
>  Labels: tech-debt
>
> Currently, the resources are return back to allocator when task finished; and 
> those resources are not allocated to framework until next allocation cycle. 
> The performance is low for short running tasks (MESOS-3078). The proposed 
> solution is to let framework keep using the offer until allocator decide to 
> rescind it.



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

[jira] [Commented] (MESOS-5725) Move createFrameworkInfo() function definition to tests/mesos.hpp.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5725:
--

RR: https://reviews.apache.org/r/49913/

> Move createFrameworkInfo() function definition to tests/mesos.hpp.
> --
>
> Key: MESOS-5725
> URL: https://issues.apache.org/jira/browse/MESOS-5725
> Project: Mesos
>  Issue Type: Bug
>Reporter: Abhishek Dasgupta
>Assignee: Abhishek Dasgupta
>Priority: Minor
>
> createFrameworkInfo() is a function that is used by many tests but strangely 
> it is not present in the parent class MesosTest but every inherited class 
> defines it when in need ( eg. ReservationEndpointsTest in 
> src/tests/reservation_endpoints_tests.cpp). It is suggested to move this 
> function to parent class MesosTest.



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

[jira] [Commented] (MESOS-5708) Add authz to /files/debug

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5708:
--

We missed to update '/files/debug' endpoint document for authorization.
Posted a trivial patch for this : https://reviews.apache.org/r/49794/

> Add authz to /files/debug
> -
>
> Key: MESOS-5708
> URL: https://issues.apache.org/jira/browse/MESOS-5708
> Project: Mesos
>  Issue Type: Task
>  Components: security
>Reporter: Adam B
>Assignee: Abhishek Dasgupta
>Priority: Minor
>  Labels: mesosphere, security
> Fix For: 1.0.0
>
>
> The /files/debug endpoint exposes the attached master/agent log paths and 
> every attached sandbox path, which includes the frameworkId and executorId. 
> Even if sandboxes are protected, we still don't want to expose this 
> information to unauthorized users.



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

[jira] [Updated] (MESOS-5488) Implement READ_FILE Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-5488:
-
Assignee: (was: Abhishek Dasgupta)

> Implement READ_FILE Call in v1 master API.
> --
>
> Key: MESOS-5488
> URL: https://issues.apache.org/jira/browse/MESOS-5488
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>




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

[jira] [Created] (MESOS-5797) Use shared_ptr instead of raw pointer for mesos::Authorizer in slave and master initialization.

[Abhishek Dasgupta (JIRA)]

Abhishek Dasgupta created MESOS-5797:


 Summary: Use shared_ptr instead of raw pointer for 
mesos::Authorizer in slave and master initialization.
 Key: MESOS-5797
 URL: https://issues.apache.org/jira/browse/MESOS-5797
 Project: Mesos
  Issue Type: Bug
  Components: general
Reporter: Abhishek Dasgupta
Assignee: Abhishek Dasgupta


Like in slave.hpp, to initialize Slave instance, we are using "const 
Option& authorizer" raw pointer. Instead of a raw pointer, we may 
use shared_ptr here as this pointer might be shared among other objects also to 
support authorization in those. 
Similarly, it can be done for master initialization also.



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

[jira] [Commented] (MESOS-5708) Add authz to /files/debug

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5708:
--

RR: https://reviews.apache.org/r/49600/

> Add authz to /files/debug
> -
>
> Key: MESOS-5708
> URL: https://issues.apache.org/jira/browse/MESOS-5708
> Project: Mesos
>  Issue Type: Task
>  Components: security
>Reporter: Adam B
>Assignee: Abhishek Dasgupta
>Priority: Minor
>  Labels: mesosphere, security
> Fix For: 1.0.0
>
>
> The /files/debug endpoint exposes the attached master/agent log paths and 
> every attached sandbox path, which includes the frameworkId and executorId. 
> Even if sandboxes are protected, we still don't want to expose this 
> information to unauthorized users.



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

[jira] [Comment Edited] (MESOS-5514) Implement LIST_FILES Call in v1 agent API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta edited comment on MESOS-5514 at 7/2/16 7:53 AM:
--

Discarding my old reviews due to complete reorganization and design changes:

New Reviews are :
https://reviews.apache.org/r/49443/
https://reviews.apache.org/r/49444/
https://reviews.apache.org/r/49445/
https://reviews.apache.org/r/49529/
https://reviews.apache.org/r/49446/
https://reviews.apache.org/r/49447/
https://reviews.apache.org/r/49550/
https://reviews.apache.org/r/49551/
https://reviews.apache.org/r/49448/


was (Author: a10gupta):
Discarding my old reviews due to complete reorganization and design changes:

New Reviews are :
https://reviews.apache.org/r/49443/
https://reviews.apache.org/r/49444/
https://reviews.apache.org/r/49445/
https://reviews.apache.org/r/49446/
https://reviews.apache.org/r/49447/
https://reviews.apache.org/r/49448/

> Implement LIST_FILES Call in v1 agent API.
> --
>
> Key: MESOS-5514
> URL: https://issues.apache.org/jira/browse/MESOS-5514
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Comment Edited] (MESOS-5487) Implement LIST_FILES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta edited comment on MESOS-5487 at 7/2/16 7:52 AM:
--

Discarding old reviews due to complete reorganization and design changes:

New Reviews are :
https://reviews.apache.org/r/49443/
https://reviews.apache.org/r/49444/
https://reviews.apache.org/r/49445/
https://reviews.apache.org/r/49529/
https://reviews.apache.org/r/49446/
https://reviews.apache.org/r/49447/
https://reviews.apache.org/r/49550/
https://reviews.apache.org/r/49551/
https://reviews.apache.org/r/49448/


was (Author: a10gupta):
Discarding old reviews due to complete reorganization and design changes:

New Reviews are :
https://reviews.apache.org/r/49443/
https://reviews.apache.org/r/49444/
https://reviews.apache.org/r/49445/
https://reviews.apache.org/r/49446/
https://reviews.apache.org/r/49447/
https://reviews.apache.org/r/49448/

> Implement LIST_FILES Call in v1 master API.
> ---
>
> Key: MESOS-5487
> URL: https://issues.apache.org/jira/browse/MESOS-5487
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5487) Implement LIST_FILES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5487:
--

Discarding old reviews due to complete reorganization and design changes:

New Reviews are :
https://reviews.apache.org/r/49443/
https://reviews.apache.org/r/49444/
https://reviews.apache.org/r/49445/
https://reviews.apache.org/r/49446/
https://reviews.apache.org/r/49447/
https://reviews.apache.org/r/49448/

> Implement LIST_FILES Call in v1 master API.
> ---
>
> Key: MESOS-5487
> URL: https://issues.apache.org/jira/browse/MESOS-5487
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5514) Implement LIST_FILES Call in v1 agent API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5514:
--

Discarding my old reviews due to complete reorganization and design changes:

New Reviews are :
https://reviews.apache.org/r/49443/
https://reviews.apache.org/r/49444/
https://reviews.apache.org/r/49445/
https://reviews.apache.org/r/49446/
https://reviews.apache.org/r/49447/
https://reviews.apache.org/r/49448/

> Implement LIST_FILES Call in v1 agent API.
> --
>
> Key: MESOS-5514
> URL: https://issues.apache.org/jira/browse/MESOS-5514
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5708) Add authz to /files/debug

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5708:


Assignee: Abhishek Dasgupta

> Add authz to /files/debug
> -
>
> Key: MESOS-5708
> URL: https://issues.apache.org/jira/browse/MESOS-5708
> Project: Mesos
>  Issue Type: Task
>  Components: security
>Reporter: Adam B
>Assignee: Abhishek Dasgupta
>Priority: Minor
>  Labels: mesosphere, security
> Fix For: 1.0.0
>
>
> The /files/debug endpoint exposes the attached master/agent log paths and 
> every attached sandbox path, which includes the frameworkId and executorId. 
> Even if sandboxes are protected, we still don't want to expose this 
> information to unauthorized users.



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

[jira] [Assigned] (MESOS-5732) MasterAPITest.UnreserveResources is slow

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5732:


Assignee: Abhishek Dasgupta

> MasterAPITest.UnreserveResources is slow
> 
>
> Key: MESOS-5732
> URL: https://issues.apache.org/jira/browse/MESOS-5732
> Project: Mesos
>  Issue Type: Improvement
>  Components: tests
>Reporter: Neil Conway
>Assignee: Abhishek Dasgupta
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] ContentType/MasterAPITest.UnreserveResources/0
> [   OK ] ContentType/MasterAPITest.UnreserveResources/0 (6033 ms)
> [ RUN  ] ContentType/MasterAPITest.UnreserveResources/1
> [   OK ] ContentType/MasterAPITest.UnreserveResources/1 (6041 ms)
> {noformat}



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

[jira] [Commented] (MESOS-5499) Implement RESERVE_RESOURCES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5499:
--

Additional patch to validate resources for reserve/unreserve call - 
RR : https://reviews.apache.org/r/49296/

> Implement RESERVE_RESOURCES Call in v1 master API.
> --
>
> Key: MESOS-5499
> URL: https://issues.apache.org/jira/browse/MESOS-5499
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
> Fix For: 1.0.0
>
>




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

[jira] [Created] (MESOS-5725) Move createFrameworkInfo() function definition to tests/mesos.hpp.

[Abhishek Dasgupta (JIRA)]

Abhishek Dasgupta created MESOS-5725:


 Summary: Move createFrameworkInfo() function definition to 
tests/mesos.hpp.
 Key: MESOS-5725
 URL: https://issues.apache.org/jira/browse/MESOS-5725
 Project: Mesos
  Issue Type: Bug
Reporter: Abhishek Dasgupta
Assignee: Abhishek Dasgupta
Priority: Minor


createFrameworkInfo() is a function that is used by many tests but strangely it 
is not present in the parent class MesosTest but every inherited class defines 
it when in need ( eg. ReservationEndpointsTest in 
src/tests/reservation_endpoints_tests.cpp). It is suggested to move this 
function to parent class MesosTest.



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

[jira] [Comment Edited] (MESOS-5500) Implement UNRESERVE_RESOURCES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta edited comment on MESOS-5500 at 6/27/16 9:16 AM:
---

RR: 
https://reviews.apache.org/r/49226/
https://reviews.apache.org/r/49227/


was (Author: a10gupta):
RR: https://reviews.apache.org/r/49226/

> Implement UNRESERVE_RESOURCES Call in v1 master API.
> 
>
> Key: MESOS-5500
> URL: https://issues.apache.org/jira/browse/MESOS-5500
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5500) Implement UNRESERVE_RESOURCES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5500:
--

RR: https://reviews.apache.org/r/49226/

> Implement UNRESERVE_RESOURCES Call in v1 master API.
> 
>
> Key: MESOS-5500
> URL: https://issues.apache.org/jira/browse/MESOS-5500
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5510) Implement REMOVE_QUOTA Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5510:
--

RR : https://reviews.apache.org/r/49247/

> Implement REMOVE_QUOTA Call in v1 master API.
> -
>
> Key: MESOS-5510
> URL: https://issues.apache.org/jira/browse/MESOS-5510
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5508) Implement GET_QUOTA Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5508:
--

Sorry, Haosdent if I sounded a little rude. It was a sudden overflow of 
emotion!! Anyway, I made you reviewer of the patch I posted. I had Get_QUOTA 
ready but will take 2 days to post Remove_Quota, still if you want to take up 
REMOVE_QUOTA, you may. Thanks for your understanding.

> Implement GET_QUOTA Call in v1 master API.
> --
>
> Key: MESOS-5508
> URL: https://issues.apache.org/jira/browse/MESOS-5508
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5508) Implement GET_QUOTA Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5508:
--

RR: https://reviews.apache.org/r/49206

> Implement GET_QUOTA Call in v1 master API.
> --
>
> Key: MESOS-5508
> URL: https://issues.apache.org/jira/browse/MESOS-5508
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5508) Implement GET_QUOTA Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5508:
--

I had this patch ready and about to post it now. I was also dependent on 
SET_QUOTA or else I could not test GET_QUOTA. I knew I had to rebase SET_QUOTA 
multiple times, so i didn't post GET_QUOTA and REMOVE_QUOTA with SET_QUOTA. If 
this way, my assigned issues get assigned to others while I am asleep, I really 
lose any enthusiasm to work on any issue.

> Implement GET_QUOTA Call in v1 master API.
> --
>
> Key: MESOS-5508
> URL: https://issues.apache.org/jira/browse/MESOS-5508
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: haosdent
>




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

[jira] [Commented] (MESOS-5487) Implement LIST_FILES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5487:
--

RR : https://reviews.apache.org/r/48931/

> Implement LIST_FILES Call in v1 master API.
> ---
>
> Key: MESOS-5487
> URL: https://issues.apache.org/jira/browse/MESOS-5487
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-2717) Qemu/KVM containerizer

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-2717:
--

why can't we merge the two containerization techniques and make it one? And 
also if we accommodate hypervisorization, we should differentiate it than 
containerizations. As hypervisor acts differently than container and going 
forward, it would be highly difficult to maintain, if we try to merge 
hypervisor technique to container technique. Instead, I propose to merge two 
container technique ( docker and mesos) and a separate hypervisor technique. 
What do you say?

> Qemu/KVM containerizer
> --
>
> Key: MESOS-2717
> URL: https://issues.apache.org/jira/browse/MESOS-2717
> Project: Mesos
>  Issue Type: Wish
>  Components: containerization
>Reporter: Pierre-Yves Ritschard
>Assignee: Abhishek Dasgupta
>
> I think it would make sense for Mesos to have the ability to treat 
> hypervisors as containerizers and the most sensible one to start with would 
> probably be Qemu/KVM.
> There are a few workloads that can require full-fledged VMs (the most obvious 
> one being Windows workloads).
> The containerization code is well decoupled and seems simple enough, I can 
> definitely take a shot at it. VMs do bring some questions with them here is 
> my take on them:
> 1. Routing, network strategy
> ==
> The simplest approach here might very well be to go for bridged networks
> and leave the setup and inter slave routing up to the administrator
> 2. IP Address assignment
> 
> At first, it can be up to the Frameworks to deal with IP assignment.
> The simplest way to address this could be to have an executor running
> on slaves providing the qemu/kvm containerizer which would instrument a DHCP 
> server and collect IP + Mac address resources from slaves. While it may be up 
> to the frameworks to provide this, an example should most likely be provided.
> 3. VM Templates
> ==
> VM templates should probably leverage the fetcher and could thus be copied 
> locally or fetch from HTTP(s) / HDFS.
> 4. Resource limiting
> 
> Mapping resouce constraints to the qemu command line is probably the easiest 
> part, Additional command line should also be fetchable. For Unix VMs, the 
> sandbox could show the output of the serial console
> 5. Libvirt / plain Qemu
> =
> I tend to favor limiting the amount of necessary hoops to jump through and 
> would thus investigate working directly with Qemu, maintaining an open 
> connection to the monitor to assert status.



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

[jira] [Assigned] (MESOS-5585) Support the pids cgroup in the agent

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5585:


Assignee: Abhishek Dasgupta

> Support the pids cgroup in the agent
> 
>
> Key: MESOS-5585
> URL: https://issues.apache.org/jira/browse/MESOS-5585
> Project: Mesos
>  Issue Type: Improvement
>  Components: slave
>Affects Versions: 1.0.0
>Reporter: Jeffrey Schroeder
>Assignee: Abhishek Dasgupta
>Priority: Minor
>
> http://kernelnewbies.org/Linux_4.3#head-6d5a75f66376fbdc0a77e2386b5aa743d8f7aeb8
> For most fork-bomb style attacks, the memory limit should neutralize them, 
> but if the task requests a lot of memory, it could still impact the host. 
> This is a nice feature that gives cluster operators some flexibility in 
> multi-tenant scenarios.



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

[jira] [Assigned] (MESOS-5613) mesos-local fails to start if MESOS_WORK_DIR isn't set.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5613:


Assignee: Abhishek Dasgupta

> mesos-local fails to start if MESOS_WORK_DIR isn't set.
> ---
>
> Key: MESOS-5613
> URL: https://issues.apache.org/jira/browse/MESOS-5613
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jan Schlicht
>Assignee: Abhishek Dasgupta
>
> Running {{mesos-local}} fails with
> {noformat}
> Failed to start a local cluster while loading agent flags from the 
> environment: Flag 'work_dir' is required, but it was not provided
> {noformat}
> if {{MESOS_WORK_DIR}} isn't set.
> This seems to be due to the changed behavior of making the {{work_dir}} flag 
> mandatory (MESOS-5064). While {{MESOS_WORK_DIR}} is being set in a 
> development environment in {{./bin/mesos-local.sh}}, this isn't true if 
> {{mesos-local}} is installed on the system after a {{make install}}.



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

[jira] [Commented] (MESOS-5514) Implement LIST_FILES Call in v1 agent API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5514:
--

RR :
https://reviews.apache.org/r/48704/
https://reviews.apache.org/r/48705/

> Implement LIST_FILES Call in v1 agent API.
> --
>
> Key: MESOS-5514
> URL: https://issues.apache.org/jira/browse/MESOS-5514
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5447) Configurable agent memory reservation

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5447:


Assignee: Abhishek Dasgupta

> Configurable agent memory reservation
> -
>
> Key: MESOS-5447
> URL: https://issues.apache.org/jira/browse/MESOS-5447
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Karl Isenberg
>Assignee: Abhishek Dasgupta
>
> When deciding what memory to make available to tasks (if not explicitly 
> configured), mesos agents currently reserve 1GB or 1/2 of system memory. 
> I'd really like to be able to configure the reservation amount so that I 
> don't have to reproduce the system memory lookup and math in order to 
> configure "mem=(system memory - reservation)".
> Ideally this would be configurable with a command line argument and 
> environment variable like "--reserved-memory=512".



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

[jira] [Updated] (MESOS-5513) Implement SET_LOGGING_LEVEL Call in v1 agent API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-5513:
-
Assignee: haosdent  (was: Abhishek Dasgupta)

> Implement SET_LOGGING_LEVEL Call in v1 agent API.
> -
>
> Key: MESOS-5513
> URL: https://issues.apache.org/jira/browse/MESOS-5513
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: haosdent
>




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

[jira] [Commented] (MESOS-5509) Implement SET_QUOTA Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5509:
--

RR: https://reviews.apache.org/r/48268/

> Implement SET_QUOTA Call in v1 master API.
> --
>
> Key: MESOS-5509
> URL: https://issues.apache.org/jira/browse/MESOS-5509
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5509) Implement SET_QUOTA Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5509:
--

What would setQuota() return? Will it be v1::Response with no field set?

> Implement SET_QUOTA Call in v1 master API.
> --
>
> Key: MESOS-5509
> URL: https://issues.apache.org/jira/browse/MESOS-5509
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5513) Implement SET_LOGGING_LEVEL Call in v1 agent API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5513:


Assignee: Abhishek Dasgupta

> Implement SET_LOGGING_LEVEL Call in v1 agent API.
> -
>
> Key: MESOS-5513
> URL: https://issues.apache.org/jira/browse/MESOS-5513
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5511) Implement GET_METRICS Call in v1 agent API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5511:


Assignee: Abhishek Dasgupta

> Implement GET_METRICS Call in v1 agent API.
> ---
>
> Key: MESOS-5511
> URL: https://issues.apache.org/jira/browse/MESOS-5511
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5494) Implement GET_ROLES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5494:
--

RR: https://reviews.apache.org/r/48094

> Implement GET_ROLES Call in v1 master API.
> --
>
> Key: MESOS-5494
> URL: https://issues.apache.org/jira/browse/MESOS-5494
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5497) Implement GET_LEADING_MASTER Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5497:
--

RR: https://reviews.apache.org/r/48049/

Also made a minor change in the test case for GET_LOGGING_LEVEL. Was getting 
error if the change was not there. If that change is not needed, we can remove 
it.

> Implement GET_LEADING_MASTER Call in v1 master API.
> ---
>
> Key: MESOS-5497
> URL: https://issues.apache.org/jira/browse/MESOS-5497
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Updated] (MESOS-5501) Implement CREATE_VOLUMES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-5501:
-
Assignee: (was: Abhishek Dasgupta)

> Implement CREATE_VOLUMES Call in v1 master API.
> ---
>
> Key: MESOS-5501
> URL: https://issues.apache.org/jira/browse/MESOS-5501
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>




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

[jira] [Assigned] (MESOS-5510) Implement REMOVE_QUOTA Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5510:


Assignee: Abhishek Dasgupta

> Implement REMOVE_QUOTA Call in v1 master API.
> -
>
> Key: MESOS-5510
> URL: https://issues.apache.org/jira/browse/MESOS-5510
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5508) Implement GET_QUOTA Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5508:


Assignee: Abhishek Dasgupta

> Implement GET_QUOTA Call in v1 master API.
> --
>
> Key: MESOS-5508
> URL: https://issues.apache.org/jira/browse/MESOS-5508
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5509) Implement SET_QUOTA Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5509:


Assignee: Abhishek Dasgupta

> Implement SET_QUOTA Call in v1 master API.
> --
>
> Key: MESOS-5509
> URL: https://issues.apache.org/jira/browse/MESOS-5509
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Updated] (MESOS-5502) Implement DESTROY_VOLUMES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-5502:
-
Assignee: (was: Abhishek Dasgupta)

> Implement DESTROY_VOLUMES Call in v1 master API.
> 
>
> Key: MESOS-5502
> URL: https://issues.apache.org/jira/browse/MESOS-5502
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>




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

[jira] [Assigned] (MESOS-5502) Implement DESTROY_VOLUMES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5502:


Assignee: Abhishek Dasgupta

> Implement DESTROY_VOLUMES Call in v1 master API.
> 
>
> Key: MESOS-5502
> URL: https://issues.apache.org/jira/browse/MESOS-5502
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5501) Implement CREATE_VOLUMES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5501:


Assignee: Abhishek Dasgupta

> Implement CREATE_VOLUMES Call in v1 master API.
> ---
>
> Key: MESOS-5501
> URL: https://issues.apache.org/jira/browse/MESOS-5501
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5500) Implement UNRESERVE_RESOURCES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5500:


Assignee: Abhishek Dasgupta

> Implement UNRESERVE_RESOURCES Call in v1 master API.
> 
>
> Key: MESOS-5500
> URL: https://issues.apache.org/jira/browse/MESOS-5500
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5499) Implement RESERVE_RESOURCES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5499:


Assignee: Abhishek Dasgupta

> Implement RESERVE_RESOURCES Call in v1 master API.
> --
>
> Key: MESOS-5499
> URL: https://issues.apache.org/jira/browse/MESOS-5499
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5497) Implement GET_LEADING_MASTER Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5497:


Assignee: Abhishek Dasgupta

> Implement GET_LEADING_MASTER Call in v1 master API.
> ---
>
> Key: MESOS-5497
> URL: https://issues.apache.org/jira/browse/MESOS-5497
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5494) Implement GET_ROLES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5494:


Assignee: Abhishek Dasgupta

> Implement GET_ROLES Call in v1 master API.
> --
>
> Key: MESOS-5494
> URL: https://issues.apache.org/jira/browse/MESOS-5494
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5514) Implement LIST_FILES Call in v1 agent API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5514:


Assignee: Abhishek Dasgupta

> Implement LIST_FILES Call in v1 agent API.
> --
>
> Key: MESOS-5514
> URL: https://issues.apache.org/jira/browse/MESOS-5514
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5517) Implement GET_RESOURCE_STATISTICS Call in v1 agent API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5517:


Assignee: Abhishek Dasgupta

> Implement GET_RESOURCE_STATISTICS Call in v1 agent API.
> ---
>
> Key: MESOS-5517
> URL: https://issues.apache.org/jira/browse/MESOS-5517
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5293) Endpoint handlers for master and agent are implemented surprisingly differently.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5293:
--

Posted a RR on : 
https://reviews.apache.org/r/47822/

> Endpoint handlers for master and agent are implemented surprisingly 
> differently.
> 
>
> Key: MESOS-5293
> URL: https://issues.apache.org/jira/browse/MESOS-5293
> Project: Mesos
>  Issue Type: Bug
>  Components: master, slave
>Reporter: Benjamin Bannier
>Assignee: Abhishek Dasgupta
>  Labels: tech-debt
>
> The way endpoints are routed is inconsistent between master and agent code 
> which makes adding or extending handlers error prone.
> In the master we route like this:
> {code}
> // Setup HTTP routes.
> route("/api/v1/scheduler",
>   DEFAULT_HTTP_FRAMEWORK_AUTHENTICATION_REALM,
>   Http::SCHEDULER_HELP(),
>   [this](const process::http::Request& request,
>  const Option& principal) {
> Http::log(request);
> return http.scheduler(request, principal);
>   });
> {code}
> We capture a pointer to the current {{Master}} in the callback which allows 
> us to access master state from an endpoint handler. The handler is a 
> (probably non-static) member function of the master's member variable 
> {{http}} which outlives the callback.
> Routing in the agent looks like this:
> {code}
> // Setup HTTP routes.
> Http http = Http(this);
> route("/api/v1/executor",
>   Http::EXECUTOR_HELP(),
>   [http](const process::http::Request& request) {
> Http::log(request);
> return http.executor(request);
>   });
> {code}
> In contrast to the master code we here copy a {{Http}} by value into the 
> callback. Since the callback is currently treated like a value and might 
> e.g., be freely copied around we are only guaranteed that {{http}} lives long 
> enough for the handler (here {{Http::executor}}) to return. In particular, 
> since endpoint handlers return a {{Future}} there is no guarantee 
> that the used {{http}} lives long enough to be still valid once a 
> conventional (e.g., non-static member) continuation is executed.
> Both models have their merit:
> * capturing a pointer to the master simplifies reasoning about lifetimes,
> * capturing just a {{Http}} with very short lifetime minimizes interactions
>   among (e.g., concurrent) invocations of endpoint handlers.
> This great inconsistency comes with a cost though, as employing patterns 
> borrowed from master endpoint handlers in agent code will lead to potentially 
> subtle bugs where a developer assuming that {{http}} would outlive a 
> handler's execution might introduce code invoking member functions of already 
> destructed variables. This is especially likely in code employing multiple 
> layers of {{delay}} or {{defer}} for which compilers seem unable to detect 
> lifetime problems and emit diagnostics.
> It would be great if we could to use  just one of the patterns to minimize 
> confusion, e.g., the more straight-forward master pattern.



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

[jira] [Assigned] (MESOS-5293) Endpoint handlers for master and agent are implemented surprisingly differently.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5293:


Assignee: Abhishek Dasgupta

> Endpoint handlers for master and agent are implemented surprisingly 
> differently.
> 
>
> Key: MESOS-5293
> URL: https://issues.apache.org/jira/browse/MESOS-5293
> Project: Mesos
>  Issue Type: Bug
>  Components: master, slave
>Reporter: Benjamin Bannier
>Assignee: Abhishek Dasgupta
>  Labels: tech-debt
>
> The way endpoints are routed is inconsistent between master and agent code 
> which makes adding or extending handlers error prone.
> In the master we route like this:
> {code}
> // Setup HTTP routes.
> route("/api/v1/scheduler",
>   DEFAULT_HTTP_FRAMEWORK_AUTHENTICATION_REALM,
>   Http::SCHEDULER_HELP(),
>   [this](const process::http::Request& request,
>  const Option& principal) {
> Http::log(request);
> return http.scheduler(request, principal);
>   });
> {code}
> We capture a pointer to the current {{Master}} in the callback which allows 
> us to access master state from an endpoint handler. The handler is a 
> (probably non-static) member function of the master's member variable 
> {{http}} which outlives the callback.
> Routing in the agent looks like this:
> {code}
> // Setup HTTP routes.
> Http http = Http(this);
> route("/api/v1/executor",
>   Http::EXECUTOR_HELP(),
>   [http](const process::http::Request& request) {
> Http::log(request);
> return http.executor(request);
>   });
> {code}
> In contrast to the master code we here copy a {{Http}} by value into the 
> callback. Since the callback is currently treated like a value and might 
> e.g., be freely copied around we are only guaranteed that {{http}} lives long 
> enough for the handler (here {{Http::executor}}) to return. In particular, 
> since endpoint handlers return a {{Future}} there is no guarantee 
> that the used {{http}} lives long enough to be still valid once a 
> conventional (e.g., non-static member) continuation is executed.
> Both models have their merit:
> * capturing a pointer to the master simplifies reasoning about lifetimes,
> * capturing just a {{Http}} with very short lifetime minimizes interactions
>   among (e.g., concurrent) invocations of endpoint handlers.
> This great inconsistency comes with a cost though, as employing patterns 
> borrowed from master endpoint handlers in agent code will lead to potentially 
> subtle bugs where a developer assuming that {{http}} would outlive a 
> handler's execution might introduce code invoking member functions of already 
> destructed variables. This is especially likely in code employing multiple 
> layers of {{delay}} or {{defer}} for which compilers seem unable to detect 
> lifetime problems and emit diagnostics.
> It would be great if we could to use  just one of the patterns to minimize 
> confusion, e.g., the more straight-forward master pattern.



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

[jira] [Commented] (MESOS-5446) NsTest.ROOT_setns and NsTest.ROOT_getns failed in Linux 4.6

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5446:
--

Even after disabling lxcfs on ubuntu 16.04, these tests are still failing.

> NsTest.ROOT_setns and NsTest.ROOT_getns failed in Linux 4.6
> ---
>
> Key: MESOS-5446
> URL: https://issues.apache.org/jira/browse/MESOS-5446
> Project: Mesos
>  Issue Type: Bug
>Reporter: haosdent
>Assignee: haosdent
>Priority: Minor
>
> From [~nthakkar%40us.ibm.com]
> {quote}
> Currently because "cgroup" namespace is not supported, following two 
> test-case are failing:
> 1. NsTest.ROOT_setns
> 2. NsTest.ROOT_getns
> The error observed is : "nstype: Unknown namespace 'cgroup'"
> This is because the contents of the directory "/proc/self/ns" has been 
> changed in kernel version 4.6 (cgroup is added).
> {quote}



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

[jira] [Commented] (MESOS-5317) Authorize the agent's '/containers' endpoint

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5317:
--

RR:
https://reviews.apache.org/r/47530/

> Authorize the agent's '/containers' endpoint
> 
>
> Key: MESOS-5317
> URL: https://issues.apache.org/jira/browse/MESOS-5317
> Project: Mesos
>  Issue Type: Improvement
>  Components: security, slave
>Reporter: Greg Mann
>Assignee: Abhishek Dasgupta
>  Labels: authorization, mesosphere
> Fix For: 0.29.0
>
>
> After the agent's {{/containers}} endpoint is authenticated, we should 
> enabled authorization as well.



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

[jira] [Assigned] (MESOS-5317) Authorize the agent's '/containers' endpoint

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5317:


Assignee: Abhishek Dasgupta

> Authorize the agent's '/containers' endpoint
> 
>
> Key: MESOS-5317
> URL: https://issues.apache.org/jira/browse/MESOS-5317
> Project: Mesos
>  Issue Type: Improvement
>  Components: security, slave
>Reporter: Greg Mann
>Assignee: Abhishek Dasgupta
>  Labels: authorization, mesosphere
> Fix For: 0.29.0
>
>
> After the agent's {{/containers}} endpoint is authenticated, we should 
> enabled authorization as well.



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

[jira] [Commented] (MESOS-3435) Add containerizer support for hyper

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-3435:
--

Thanks, I m checking it.

> Add containerizer support for hyper
> ---
>
> Key: MESOS-3435
> URL: https://issues.apache.org/jira/browse/MESOS-3435
> Project: Mesos
>  Issue Type: Story
>Reporter: Deshi Xiao
>Assignee: haosdent
>
> Secure as hypervisor, fast and easily used as Docker. This is hyper. 
> https://docs.hyper.sh/Introduction/what_is_hyper_.html We could implement 
> this through module way once MESOS-3709 finished.



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

[jira] [Commented] (MESOS-5316) Authenticate the agent's '/containers' endpoint

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5316:
--

Another RR has been added:
https://reviews.apache.org/r/47340/

> Authenticate the agent's '/containers' endpoint
> ---
>
> Key: MESOS-5316
> URL: https://issues.apache.org/jira/browse/MESOS-5316
> Project: Mesos
>  Issue Type: Improvement
>  Components: security, slave
>Reporter: Greg Mann
>Assignee: Abhishek Dasgupta
>  Labels: authentication, mesosphere
> Fix For: 0.29.0
>
>
> The {{/containers}} endpoint was recently added to the agent. Authentication 
> should be enabled on this endpoint.



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

[jira] [Commented] (MESOS-5368) Consider introducing persistent agent ID

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5368:
--

+1

> Consider introducing persistent agent ID
> 
>
> Key: MESOS-5368
> URL: https://issues.apache.org/jira/browse/MESOS-5368
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Neil Conway
>Assignee: Abhishek Dasgupta
>  Labels: mesosphere
>
> Currently, agent IDs identify a single "session" by an agent: that is, an 
> agent receives an agent ID when it registers with the master; it reuses that 
> agent ID if it disconnects and successfully reregisters; if the agent shuts 
> down and restarts, it registers anew and receives a new agent ID.
> It would be convenient to have a "persistent agent ID" that remains the same 
> for the duration of a given agent {{work_dir}}. This would mean that a given 
> persistent volume would not migrate between different agent IDs over time, 
> for example (see MESOS-4894). If we supported permanently removing an agent 
> from the cluster (i.e., the {{work_dir}} and any volumes used by the agent 
> will never be reused), we could use the persistent agent ID to report which 
> agent has been removed.



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

[jira] [Assigned] (MESOS-5368) Consider introducing persistent agent ID

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5368:


Assignee: Abhishek Dasgupta

> Consider introducing persistent agent ID
> 
>
> Key: MESOS-5368
> URL: https://issues.apache.org/jira/browse/MESOS-5368
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Neil Conway
>Assignee: Abhishek Dasgupta
>  Labels: mesosphere
>
> Currently, agent IDs identify a single "session" by an agent: that is, an 
> agent receives an agent ID when it registers with the master; it reuses that 
> agent ID if it disconnects and successfully reregisters; if the agent shuts 
> down and restarts, it registers anew and receives a new agent ID.
> It would be convenient to have a "persistent agent ID" that remains the same 
> for the duration of a given agent {{work_dir}}. This would mean that a given 
> persistent volume would not migrate between different agent IDs over time, 
> for example (see MESOS-4894). If we supported permanently removing an agent 
> from the cluster (i.e., the {{work_dir}} and any volumes used by the agent 
> will never be reused), we could use the persistent agent ID to report which 
> agent has been removed.



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