[jira] [Commented] (MESOS-5962) Support multiple health checks per task.

[Deshi Xiao (JIRA)]

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

Deshi Xiao commented on MESOS-5962:
---

[~alexr]  i have review the docs, could you please highlight the reason to hold 
on the proposal. i don't understand at all.

> Support multiple health checks per task.
> 
>
> Key: MESOS-5962
> URL: https://issues.apache.org/jira/browse/MESOS-5962
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Alexander Rukletsov
>  Labels: check, health-check, mesosphere
>
> Currently, only a single check and a single health check per task is 
> supported. Consider supporting multiple checks and/or health checks. There 
> are various approaches how to treat them:
> * do health aggregation in Mesos or delegate it to a frameworks,
> * have a single or multiple restart policies (one per health check),
> * introduce health check ids or not.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7671) Let frameworks specify the task bounding capabilities.

[James Peach (JIRA)]

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

James Peach updated MESOS-7671:
---
Description: 
Following on from MESOS-7476, we should allow frameworks to specify a 
capabilities bounding set in the {{CapabilityInfo}} by adding a {{repeated 
Capability bounding_capabilities}} field.

I'm a little torn on making more churn, but we probably should consider the 
{{capabilities}} field to {{effective_capabilities}}.

  was:
Following on from MESOS-7476, we should allow frameworks to specify a 
capabilities bounding set in the `CapabilityInfo` by adding a `repeated 
Capability bounding_capabilities` field.

I'm a little torn on making more churn, but we probably should consider the 
`capabilities` field to `effective_capabilities`.


> Let frameworks specify the task bounding capabilities.
> --
>
> Key: MESOS-7671
> URL: https://issues.apache.org/jira/browse/MESOS-7671
> Project: Mesos
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: James Peach
>
> Following on from MESOS-7476, we should allow frameworks to specify a 
> capabilities bounding set in the {{CapabilityInfo}} by adding a {{repeated 
> Capability bounding_capabilities}} field.
> I'm a little torn on making more churn, but we probably should consider the 
> {{capabilities}} field to {{effective_capabilities}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7671) Let frameworks specify the task bounding capabilities.

[James Peach (JIRA)]

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

James Peach commented on MESOS-7671:


Thanks! I won't be able to get to it for about 2 weeks. Let me know whether you 
think we should to the {{capabilities}} field deprecation/rename.

> Let frameworks specify the task bounding capabilities.
> --
>
> Key: MESOS-7671
> URL: https://issues.apache.org/jira/browse/MESOS-7671
> Project: Mesos
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: James Peach
>
> Following on from MESOS-7476, we should allow frameworks to specify a 
> capabilities bounding set in the `CapabilityInfo` by adding a `repeated 
> Capability bounding_capabilities` field.
> I'm a little torn on making more churn, but we probably should consider the 
> `capabilities` field to `effective_capabilities`.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7671) Let frameworks specify the task bounding capabilities.

[Jie Yu (JIRA)]

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

Jie Yu commented on MESOS-7671:
---

[~jpe...@apache.org], yes

> Let frameworks specify the task bounding capabilities.
> --
>
> Key: MESOS-7671
> URL: https://issues.apache.org/jira/browse/MESOS-7671
> Project: Mesos
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: James Peach
>
> Following on from MESOS-7476, we should allow frameworks to specify a 
> capabilities bounding set in the `CapabilityInfo` by adding a `repeated 
> Capability bounding_capabilities` field.
> I'm a little torn on making more churn, but we probably should consider the 
> `capabilities` field to `effective_capabilities`.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7669) Update the test utilities to produce the resources in the new format

[Michael Park (JIRA)]

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

Michael Park updated MESOS-7669:

Summary: Update the test utilities to produce the resources in the new 
format  (was: Update the tests to produce the resources in the new format)

> Update the test utilities to produce the resources in the new format
> 
>
> Key: MESOS-7669
> URL: https://issues.apache.org/jira/browse/MESOS-7669
> Project: Mesos
>  Issue Type: Bug
>  Components: test
>Reporter: Michael Park
>
> With reservation refinement, the `Resource.reservations` field is used to 
> express the notion of reservations rather than the old `Resource.role`, 
> `Resource.reservation` pair. The test utilities in {{tests/mesos.hpp}} need 
> to be updated to reflect this change.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7669) Update the tests to produce the resources in the new format

[Michael Park (JIRA)]

Michael Park created MESOS-7669:
---

 Summary: Update the tests to produce the resources in the new 
format
 Key: MESOS-7669
 URL: https://issues.apache.org/jira/browse/MESOS-7669
 Project: Mesos
  Issue Type: Bug
  Components: test
Reporter: Michael Park


With reservation refinement, the `Resource.reservations` field is used to 
express the notion of reservations rather than the old `Resource.role`, 
`Resource.reservation` pair. The test utilities in {{tests/mesos.hpp}} need to 
be updated to reflect this change.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7668) Update authorization to handle reservation refinement.

[Benjamin Mahler (JIRA)]

Benjamin Mahler created MESOS-7668:
--

 Summary: Update authorization to handle reservation refinement.
 Key: MESOS-7668
 URL: https://issues.apache.org/jira/browse/MESOS-7668
 Project: Mesos
  Issue Type: Task
Reporter: Benjamin Mahler


With reservation refinement, the local authorizer needs to be updated to 
retrieve the role and principal via the {{Resource.reservations}} field.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7667) Update the master to use the new resource format.

[Michael Park (JIRA)]

Michael Park created MESOS-7667:
---

 Summary: Update the master to use the new resource format.
 Key: MESOS-7667
 URL: https://issues.apache.org/jira/browse/MESOS-7667
 Project: Mesos
  Issue Type: Bug
  Components: master
Reporter: Michael Park


With reservation refinement, the `Resource.reservations` field is used to 
express the notion of reservations rather than the old `Resource.role`, 
`Resource.reservation` pair. The master code needs to be updated to reflect 
this change.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7666) Update the agent to use the new resource format

[Michael Park (JIRA)]

Michael Park created MESOS-7666:
---

 Summary: Update the agent to use the new resource format
 Key: MESOS-7666
 URL: https://issues.apache.org/jira/browse/MESOS-7666
 Project: Mesos
  Issue Type: Bug
  Components: agent
Reporter: Michael Park


With reservation refinement, the `Resource.reservations` field is used to 
express the notion of reservations rather than the old `Resource.role`, 
`Resource.reservation` pair. The agent code needs to be updated to reflect this 
change.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7665) v0 Operator API update for reservation refinement.

[Benjamin Mahler (JIRA)]

Benjamin Mahler created MESOS-7665:
--

 Summary: v0 Operator API update for reservation refinement.
 Key: MESOS-7665
 URL: https://issues.apache.org/jira/browse/MESOS-7665
 Project: Mesos
  Issue Type: Task
Reporter: Benjamin Mahler


In order to preserve backwards compatibility, the v0 endpoints (e.g. /state) 
should expose the old format using `Resource.role` and `Resource.reservation` 
if the resources do not contain a refined reservation.

If the resource contains a refined reservation, then we need to ensure the v0 
endpoints reflect that in the JSON.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7664) Framework API update for reservation refinement.

[Benjamin Mahler (JIRA)]

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

Benjamin Mahler updated MESOS-7664:
---
Issue Type: Task  (was: Documentation)

> Framework API update for reservation refinement.
> 
>
> Key: MESOS-7664
> URL: https://issues.apache.org/jira/browse/MESOS-7664
> Project: Mesos
>  Issue Type: Task
>Reporter: Benjamin Mahler
>Assignee: Michael Park
>
> In order to add reservation refinement, the framework API needs:
> * A way to express the "stack" of reservations.
> * A new capability to gate the feature, since the resource format has to 
> change.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7663) Update the documentation to reflect the addition of reservation refinement.

[Benjamin Mahler (JIRA)]

Benjamin Mahler created MESOS-7663:
--

 Summary: Update the documentation to reflect the addition of 
reservation refinement.
 Key: MESOS-7663
 URL: https://issues.apache.org/jira/browse/MESOS-7663
 Project: Mesos
  Issue Type: Documentation
  Components: documentation
Reporter: Benjamin Mahler


There are a few things we need to be sure to document:

* What reservation refinement is.
* The new "format" for Resource, when using the RESERVATION_REFINEMENT 
capability.
* The filtering of resources if a framework is not RESERVATION_REFINEMENT 
capable.
* The current limitations that only a single reservation can be pushed / popped 
within a single RESERVE / UNRESERVE operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MESOS-7575) Support reservation refinement for hierarchical roles.

[Benjamin Mahler (JIRA)]

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

Benjamin Mahler edited comment on MESOS-7575 at 6/14/17 1:24 AM:
-

Moving this to an epic so that we can capture all of the work needed here.


was (Author: bmahler):
Moving this to an epic so that capture all of the work needed here.

> Support reservation refinement for hierarchical roles.
> --
>
> Key: MESOS-7575
> URL: https://issues.apache.org/jira/browse/MESOS-7575
> Project: Mesos
>  Issue Type: Epic
>Reporter: Michael Park
>Assignee: Michael Park
>
> With the introduction of hierarchical roles, Mesos provides a mechanism to 
> delegate resources down a hierarchy.
> To complement this, we'll introduce a mechanism to *refine* the reservations 
> down the hierarchy.
> For example, given resources allocated to role {{foo}}, it can be further 
> reserved for {{foo/bar}}.
> When the resources allocated to {{foo/bar}} is unreserved, it goes back to 
> where it came from. In this case, back to role {{foo}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7575) Support reservation refinement for hierarchical roles.

[Benjamin Mahler (JIRA)]

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

Benjamin Mahler updated MESOS-7575:
---
Epic Name: reservation refinement

> Support reservation refinement for hierarchical roles.
> --
>
> Key: MESOS-7575
> URL: https://issues.apache.org/jira/browse/MESOS-7575
> Project: Mesos
>  Issue Type: Epic
>Reporter: Michael Park
>Assignee: Michael Park
>
> With the introduction of hierarchical roles, Mesos provides a mechanism to 
> delegate resources down a hierarchy.
> To complement this, we'll introduce a mechanism to *refine* the reservations 
> down the hierarchy.
> For example, given resources allocated to role {{foo}}, it can be further 
> reserved for {{foo/bar}}.
> When the resources allocated to {{foo/bar}} is unreserved, it goes back to 
> where it came from. In this case, back to role {{foo}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7575) Support reservation refinement for hierarchical roles.

[Benjamin Mahler (JIRA)]

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

Benjamin Mahler updated MESOS-7575:
---
   Summary: Support reservation refinement for hierarchical roles.  (was: 
Support reservation refinement)
Issue Type: Epic  (was: Task)

Moving this to an epic so that capture all of the work needed here.

> Support reservation refinement for hierarchical roles.
> --
>
> Key: MESOS-7575
> URL: https://issues.apache.org/jira/browse/MESOS-7575
> Project: Mesos
>  Issue Type: Epic
>Reporter: Michael Park
>Assignee: Michael Park
>
> With the introduction of hierarchical roles, Mesos provides a mechanism to 
> delegate resources down a hierarchy.
> To complement this, we'll introduce a mechanism to *refine* the reservations 
> down the hierarchy.
> For example, given resources allocated to role {{foo}}, it can be further 
> reserved for {{foo/bar}}.
> When the resources allocated to {{foo/bar}} is unreserved, it goes back to 
> where it came from. In this case, back to role {{foo}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7662) Documentation regarding TASK_LOST is misleading

[JIRA]

Gastón Kleiman created MESOS-7662:
-

 Summary: Documentation regarding TASK_LOST is misleading
 Key: MESOS-7662
 URL: https://issues.apache.org/jira/browse/MESOS-7662
 Project: Mesos
  Issue Type: Bug
  Components: documentation
Reporter: Gastón Kleiman
Assignee: Gastón Kleiman


Our protos describe {{TASK_LOST}} as a terminal state 
[\[1\]|https://github.com/apache/mesos/blob/fb54d469dcadf762e9c3f8a2fed78ed7b306120a/include/mesos/mesos.proto#L1722]
 
[\[2\]|https://github.com/apache/mesos/blob/fb54d469dcadf762e9c3f8a2fed78ed7b306120a/include/mesos/mesos.proto#L64-L73].

A task might go from {{TASK_LOST}} to {{TASK_RUNNING}} or another state if 
Mesos is not using a strict register, so the documentation is misleading.

Marathon used to assume that {{TASK_LOST}} was a terminal past and that 
resulted in production pain for some users.

We should update the documentation to make the life of frameworks developers a 
bit better =).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7661) Libprocess timers with long durations trigger immediately

[Greg Mann (JIRA)]

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

Greg Mann updated MESOS-7661:
-
Summary: Libprocess timers with long durations trigger immediately  (was: 
Libprocess runs long timers right ahead)

> Libprocess timers with long durations trigger immediately
> -
>
> Key: MESOS-7661
> URL: https://issues.apache.org/jira/browse/MESOS-7661
> Project: Mesos
>  Issue Type: Bug
>  Components: libprocess
>Reporter: Gastón Kleiman
>  Labels: mesosphere
>
> {{process::delay()}} will schedule a method to be run right ahead when called 
> with a vry long {{Duration}}.
> This happens because [{{Timeout}} tries to add two long 
> durations|https://github.com/apache/mesos/blob/13cae29e7832d8bb879c68847ad0df449d227f17/3rdparty/libprocess/include/process/timeout.hpp#L33-L38],
>  leading to an [integer overflow in 
> {{Duration}}|https://github.com/apache/mesos/blob/13cae29e7832d8bb879c68847ad0df449d227f17/3rdparty/stout/include/stout/duration.hpp#L116].
> I'd expect libprocess to either:
>   1. Never run the method.
>   2. Schedule it in the longest possible {{Duration}}.
> {{Duration::operator+=()}} should probably also handle integer overflows 
> differently. If an addition leads to an integer overflow, it might make more 
> sense to return {{Duration::max()}} than a negative duration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7661) Libprocess runs long timers right ahead

[Greg Mann (JIRA)]

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

Greg Mann commented on MESOS-7661:
--

I could imagine something like:
{code}
Duration& operator+=(const Duration& that)
{
  if (max() - that < *this) {
nanos = max().nanos;
  } else {
nanos += that.nanos;
  }

  return *this;
}
{code}

cc [~bmahler] [~kaysoky]

> Libprocess runs long timers right ahead
> ---
>
> Key: MESOS-7661
> URL: https://issues.apache.org/jira/browse/MESOS-7661
> Project: Mesos
>  Issue Type: Bug
>  Components: libprocess
>Reporter: Gastón Kleiman
>  Labels: mesosphere
>
> {{process::delay()}} will schedule a method to be run right ahead when called 
> with a vry long {{Duration}}.
> This happens because [{{Timeout}} tries to add two long 
> durations|https://github.com/apache/mesos/blob/13cae29e7832d8bb879c68847ad0df449d227f17/3rdparty/libprocess/include/process/timeout.hpp#L33-L38],
>  leading to an [integer overflow in 
> {{Duration}}|https://github.com/apache/mesos/blob/13cae29e7832d8bb879c68847ad0df449d227f17/3rdparty/stout/include/stout/duration.hpp#L116].
> I'd expect libprocess to either:
>   1. Never run the method.
>   2. Schedule it in the longest possible {{Duration}}.
> {{Duration::operator+=()}} should probably also handle integer overflows 
> differently. If an addition leads to an integer overflow, it might make more 
> sense to return {{Duration::max()}} than a negative duration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7514) ReservationTest.PreventUnreservingAlienResources is flaky

[JIRA]

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

Gastón Kleiman commented on MESOS-7514:
---

The tests are flaky, because Mesos will clear a filter right away if 
{{Filter::refuse_seconds}} is set to a very large number.

Fixing MESOS-7660 and MESOS-7661 should make the bugs stable.

> ReservationTest.PreventUnreservingAlienResources is flaky
> -
>
> Key: MESOS-7514
> URL: https://issues.apache.org/jira/browse/MESOS-7514
> Project: Mesos
>  Issue Type: Bug
>Reporter: Neil Conway
>Assignee: Gastón Kleiman
>  Labels: mesosphere
>
> This repros consistently for me on a many-core box:
> {noformat}
> [ RUN  ] ReservationTest.PreventUnreservingAlienResources
> I0516 11:15:51.562351 26940 cluster.cpp:162] Creating default 'local' 
> authorizer
> I0516 11:15:51.656114 26996 master.cpp:436] Master 
> 0495c63b-8319-43fb-809c-6a18c7005548 (core-dev) started on 10.0.49.2:33500
> I0516 11:15:51.656159 26996 master.cpp:438] Flags at startup: --acls="" 
> --agent_ping_timeout="15secs" --agent_reregister_timeout="10mins" 
> --allocation_interval="5ms" --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/PGp9GX/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" 
> --max_unreachable_tasks_per_framework="1000" --port="5050" --quiet="false" 
> --recovery_agent_removal_limit="100%" --registry="in_memory" 
> --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/PGp9GX/master" 
> --zk_session_timeout="10secs"
> I0516 11:15:51.658516 26996 master.cpp:488] Master only allowing 
> authenticated frameworks to register
> I0516 11:15:51.658540 26996 master.cpp:502] Master only allowing 
> authenticated agents to register
> I0516 11:15:51.658597 26996 master.cpp:515] Master only allowing 
> authenticated HTTP frameworks to register
> I0516 11:15:51.658615 26996 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/PGp9GX/credentials'
> I0516 11:15:51.659363 26996 master.cpp:560] Using default 'crammd5' 
> authenticator
> I0516 11:15:51.659560 26996 authenticator.cpp:519] Initializing server SASL
> I0516 11:15:51.660568 26996 http.cpp:975] Creating default 'basic' HTTP 
> authenticator for realm 'mesos-master-readonly'
> I0516 11:15:51.660923 26996 http.cpp:975] Creating default 'basic' HTTP 
> authenticator for realm 'mesos-master-readwrite'
> I0516 11:15:51.661057 26996 http.cpp:975] Creating default 'basic' HTTP 
> authenticator for realm 'mesos-master-scheduler'
> I0516 11:15:51.661219 26996 master.cpp:640] Authorization enabled
> I0516 11:15:51.672745 26976 master.cpp:2161] Elected as the leading master!
> I0516 11:15:51.672835 26976 master.cpp:1700] Recovering from registrar
> I0516 11:15:51.676582 26987 registrar.cpp:389] Successfully fetched the 
> registry (0B) in 3.4112ms
> I0516 11:15:51.676875 26987 registrar.cpp:493] Applied 1 operations in 
> 56756ns; attempting to update the registry
> I0516 11:15:51.680197 26987 registrar.cpp:550] Successfully updated the 
> registry in 3.24608ms
> I0516 11:15:51.680672 26987 registrar.cpp:422] Successfully recovered 
> registrar
> I0516 11:15:51.681761 26964 master.cpp:1799] Recovered 0 agents from the 
> registry (119B); allowing 10mins for agents to re-register
> I0516 11:15:51.779008 26940 containerizer.cpp:221] Using isolation: 
> posix/cpu,posix/mem,filesystem/posix,network/cni
> W0516 11:15:51.779985 26940 backend.cpp:76] Failed to create 'overlay' 
> backend: OverlayBackend requires root privileges
> W0516 11:15:51.780287 26940 backend.cpp:76] Failed to create 'bind' backend: 
> BindBackend requires root privileges
> I0516 11:15:51.780387 26940 provisioner.cpp:249] Using default backend 'copy'
> I0516 11:15:51.783296 26940 cluster.cpp:448] Creating default 'local' 
> authorizer
> I0516 11:15:51.785317 26971 slave.cpp:225] Mesos agent started on 
> (1)@10.0.49.2:33500
> I0516 11:15:51.785373 26971 slave.cpp:226] Flags at startup: --acls="" 
> 

[jira] [Created] (MESOS-7661) Libprocess runs long timers right ahead

[JIRA]

Gastón Kleiman created MESOS-7661:
-

 Summary: Libprocess runs long timers right ahead
 Key: MESOS-7661
 URL: https://issues.apache.org/jira/browse/MESOS-7661
 Project: Mesos
  Issue Type: Bug
  Components: libprocess
Reporter: Gastón Kleiman


{{process::delay()}} will schedule a method to be run right ahead when called 
with a vry long {{Duration}}.

This happens because [{{Timeout}} tries to add two long 
durations|https://github.com/apache/mesos/blob/13cae29e7832d8bb879c68847ad0df449d227f17/3rdparty/libprocess/include/process/timeout.hpp#L33-L38],
 leading to an [integer overflow in 
{{Duration}}|https://github.com/apache/mesos/blob/13cae29e7832d8bb879c68847ad0df449d227f17/3rdparty/stout/include/stout/duration.hpp#L116].

I'd expect libprocess to either:

  1. Never run the method.
  2. Schedule it in the longest possible {{Duration}}.

{{Duration::operator+=()}} should probably also handle integer overflows 
differently. If an addition leads to an integer overflow, it might make more 
sense to return {{Duration::max()}} than a negative duration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7660) HierarchicalAllocator uses the default filter instead of a very long one

[JIRA]

Gastón Kleiman created MESOS-7660:
-

 Summary: HierarchicalAllocator uses the default filter instead of 
a very long one
 Key: MESOS-7660
 URL: https://issues.apache.org/jira/browse/MESOS-7660
 Project: Mesos
  Issue Type: Bug
  Components: allocation
Reporter: Gastón Kleiman


If a framework accepts/refuses an offer using a very long filter, [the 
{{HierarchicalAllocator}} will use the default {{Filter}} 
instead|https://github.com/apache/mesos/blob/master/src/master/allocator/mesos/hierarchical.cpp#L1046-L1052].
 Meaning that it will filter the resources for only 5 seconds.

This can happen when a framework sets {{Filter::refuse_seconds}} to a number of 
seconds [larger than what fits in 
{{Duration}}|https://github.com/apache/mesos/blob/13cae29e7832d8bb879c68847ad0df449d227f17/3rdparty/stout/include/stout/duration.hpp#L401-L405].

The following [tests are 
flaky|https://issues.apache.org/jira/browse/MESOS-7514] because of this: 
{{ReservationTest.ReserveShareWithinRole}} and 
{{ReservationTest.PreventUnreservingAlienResources}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7659) Metric for refused/ignored agent registrations

[Neil Conway (JIRA)]

Neil Conway created MESOS-7659:
--

 Summary: Metric for refused/ignored agent registrations
 Key: MESOS-7659
 URL: https://issues.apache.org/jira/browse/MESOS-7659
 Project: Mesos
  Issue Type: Bug
Reporter: Neil Conway


The master will ignore agent registration attempts in some cases (see 
MESOS-7615). When this happens, a master log message is emitted, but it would 
be nice to also increment a master metric.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7658) apply-reviews.py fails with Unicode characters on Windows

[Andrew Schwartzmeyer (JIRA)]

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

Andrew Schwartzmeyer commented on MESOS-7658:
-

It looks like the correct solution is to use Python 3, as it has Unicode 
support on Windows, whereas [Python 2 does not, and will 
not|https://stackoverflow.com/questions/1910275/unicode-filenames-on-windows-with-python-subprocess-popen].

> apply-reviews.py fails with Unicode characters on Windows
> -
>
> Key: MESOS-7658
> URL: https://issues.apache.org/jira/browse/MESOS-7658
> Project: Mesos
>  Issue Type: Bug
> Environment: Windows 10
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>
> This prevents commits from being applied if the name or message contains 
> non-ASCII characters, and so can break the Windows ReviewBot.
> {code}
> > git checkout b2801f0012535e29609f603b4324a9ca693f70cb~
> > python .\support\apply-reviews.py -r 59874
> Traceback (most recent call last):
>   File ".\support\apply-reviews.py", line 381, in 
> reviewboard()
>   File ".\support\apply-reviews.py", line 360, in reviewboard
> apply_review()
>   File ".\support\apply-reviews.py", line 126, in apply_review
> commit_patch()
>   File ".\support\apply-reviews.py", line 225, in commit_patch
> shell(cmd, options['dry_run'])
>   File ".\support\apply-reviews.py", line 111, in shell
> error_code = subprocess.call(command, stderr=subprocess.STDOUT, 
> shell=True)
>   File "C:\Python27\lib\subprocess.py", line 168, in call
> return Popen(*popenargs, **kwargs).wait()
>   File "C:\Python27\lib\subprocess.py", line 390, in __init__
> errread, errwrite)
>   File "C:\Python27\lib\subprocess.py", line 610, in _execute_child
> args = '{} /c "{}"'.format (comspec, args)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in position 
> 25: ordinal not in range(128)
> ~\src\mesos-copy2 |-/
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7505) Enable hierarchical roles

[Michael Park (JIRA)]

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

Michael Park commented on MESOS-7505:
-

{noformat}
commit 2ef06aec4ac69a869ab0dc40a4de191e6e08bb3f
Author: Michael Park 
Date:   Mon May 22 14:28:18 2017 -0700

Revert "Disabled support for hierarchical roles."

This reverts commit e0d8cc7c4ef7a0905044159ca47f64b0923e9788.
{noformat}

> Enable hierarchical roles
> -
>
> Key: MESOS-7505
> URL: https://issues.apache.org/jira/browse/MESOS-7505
> Project: Mesos
>  Issue Type: Task
>Reporter: Neil Conway
>Assignee: Neil Conway
>  Labels: mesosphere
> Fix For: 1.4.0
>
>
> Support for hierarchical roles is currently disabled. It should be re-enabled 
> for the 1.4.0 release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7658) apply-reviews.py fails with Unicode characters on Windows

[Andrew Schwartzmeyer (JIRA)]

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

Andrew Schwartzmeyer commented on MESOS-7658:
-

So, unfortunately, this is a problem with `subprocess` itself. I got around it 
erroring during the internal args.format it does when `shell=True` (by setting 
it to false), but it uses the short version of `CreateProcess`, so you get this 
anyway:

{code}
  File "C:\Python27\lib\subprocess.py", line 168, in call
return Popen(*popenargs, **kwargs).wait()
  File "C:\Python27\lib\subprocess.py", line 390, in __init__
errread, errwrite)
  File "C:\Python27\lib\subprocess.py", line 640, in _execute_child
startupinfo)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in position 
25: ordinal not in range(128)
{code}

It dies when making the (non-Unicode) startupinfo.

> apply-reviews.py fails with Unicode characters on Windows
> -
>
> Key: MESOS-7658
> URL: https://issues.apache.org/jira/browse/MESOS-7658
> Project: Mesos
>  Issue Type: Bug
> Environment: Windows 10
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>
> This prevents commits from being applied if the name or message contains 
> non-ASCII characters, and so can break the Windows ReviewBot.
> {code}
> > git checkout b2801f0012535e29609f603b4324a9ca693f70cb~
> > python .\support\apply-reviews.py -r 59874
> Traceback (most recent call last):
>   File ".\support\apply-reviews.py", line 381, in 
> reviewboard()
>   File ".\support\apply-reviews.py", line 360, in reviewboard
> apply_review()
>   File ".\support\apply-reviews.py", line 126, in apply_review
> commit_patch()
>   File ".\support\apply-reviews.py", line 225, in commit_patch
> shell(cmd, options['dry_run'])
>   File ".\support\apply-reviews.py", line 111, in shell
> error_code = subprocess.call(command, stderr=subprocess.STDOUT, 
> shell=True)
>   File "C:\Python27\lib\subprocess.py", line 168, in call
> return Popen(*popenargs, **kwargs).wait()
>   File "C:\Python27\lib\subprocess.py", line 390, in __init__
> errread, errwrite)
>   File "C:\Python27\lib\subprocess.py", line 610, in _execute_child
> args = '{} /c "{}"'.format (comspec, args)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in position 
> 25: ordinal not in range(128)
> ~\src\mesos-copy2 |-/
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7658) apply-reviews.py fails with Unicode characters on Windows

[Andrew Schwartzmeyer (JIRA)]

Andrew Schwartzmeyer created MESOS-7658:
---

 Summary: apply-reviews.py fails with Unicode characters on Windows
 Key: MESOS-7658
 URL: https://issues.apache.org/jira/browse/MESOS-7658
 Project: Mesos
  Issue Type: Bug
 Environment: Windows 10
Reporter: Andrew Schwartzmeyer
Assignee: Andrew Schwartzmeyer


This prevents commits from being applied if the name or message contains 
non-ASCII characters, and so can break the Windows ReviewBot.
{code}
> git checkout b2801f0012535e29609f603b4324a9ca693f70cb~
> python .\support\apply-reviews.py -r 59874
Traceback (most recent call last):
  File ".\support\apply-reviews.py", line 381, in 
reviewboard()
  File ".\support\apply-reviews.py", line 360, in reviewboard
apply_review()
  File ".\support\apply-reviews.py", line 126, in apply_review
commit_patch()
  File ".\support\apply-reviews.py", line 225, in commit_patch
shell(cmd, options['dry_run'])
  File ".\support\apply-reviews.py", line 111, in shell
error_code = subprocess.call(command, stderr=subprocess.STDOUT, shell=True)
  File "C:\Python27\lib\subprocess.py", line 168, in call
return Popen(*popenargs, **kwargs).wait()
  File "C:\Python27\lib\subprocess.py", line 390, in __init__
errread, errwrite)
  File "C:\Python27\lib\subprocess.py", line 610, in _execute_child
args = '{} /c "{}"'.format (comspec, args)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in position 
25: ordinal not in range(128)
~\src\mesos-copy2 |-/
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7631) DefautlExecutor needs to inform tasks about IP addresses

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7631:
--
Sprint: Mesosphere Sprint 57, Mesosphere Sprint 58  (was: Mesosphere Sprint 
57)

> DefautlExecutor needs to inform tasks about IP addresses
> 
>
> Key: MESOS-7631
> URL: https://issues.apache.org/jira/browse/MESOS-7631
> Project: Mesos
>  Issue Type: Task
>  Components: executor
>Reporter: Avinash Sridharan
>Assignee: Anand Mazumdar
>
> Currently, when the DefaultExecutor launches tasks it doesn’t pass any 
> networking information (host or CNI network IP addresses) to the tasks that 
> it launches. This becomes problematic for the applications which need to know 
> the IP address that they need to bind to and cannot rely on binding to 
> INADDR_ANY. The tasks launched by the DefaultExecutor can potentially look at 
> all the available interface IP addresses and select a non-loopback IP address 
> but this is very error prone when there are multiple interfaces on a host or 
> a container is attached to multiple networks.
> Possible solution:
> The DefaultExecutor sets a variable MESOS_TASK_IP into the task’s shell. The 
> task will always read the variable to determine the IP address it should use. 
> Below we describe the algorithm to set MESOS_CONTAINER_IP for various cases.
> Setting MESOS_CONTAINER_IP for `host` network:
> For host network the `LIBPROCESS_IP` in the DefaultExecutor is always set to 
> the agent IP. The DefaultExecutor can therefore set `MESOS_TASK_IP` to the 
> `LIBPROCESS_IP` whenever it sees that the LIBPROCESS_IP is anything other 
> than “0.0.0.0” or “::” (for IPv6).
> Setting MESOS_TASK_IP for a single “CNI” network:
> For CNI network the `LIBPROCESS_IP` is set to “0.0.0.0” and the `hostname` of 
> the container is set to the CNI ip address. The DefaultExecutor already 
> resolves the hostname for CNI network (to register with agent), so it can 
> just set MESOS_TASK_IP to the IP address it learnt by resolving the hostname.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7374) Running DOCKER images in Mesos Container Runtime without `linux/filesystem` isolation enabled renders host unusable

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7374:
--
Sprint: Mesosphere Sprint 57, Mesosphere Sprint 58  (was: Mesosphere Sprint 
57)

> Running DOCKER images in Mesos Container Runtime without `linux/filesystem` 
> isolation enabled renders host unusable
> ---
>
> Key: MESOS-7374
> URL: https://issues.apache.org/jira/browse/MESOS-7374
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization
>Affects Versions: 1.2.0
>Reporter: Tim Harper
>Assignee: Chun-Hung Hsiao
>Priority: Critical
>  Labels: containerizer, mesosphere
>
> If I run the pod below (using Marathon 1.4.2) against a mesos agent that has 
> the flags (also below), then the overlay filesystem replaces the system root 
> mount, effectively rendering the host unusable until reboot.
> flags:
> - {{--containerizers mesos,docker}}
> - {{--image_providers APPC,DOCKER}}
> - {{--isolation cgroups/cpu,cgroups/mem,docker/runtime}}
> pod definition for Marathon:
> {code:java}
> {
>   "id": "/simplepod",
>   "scaling": { "kind": "fixed", "instances": 1 },
>   "containers": [
> {
>   "name": "sleep1",
>   "exec": { "command": { "shell": "sleep 1000" } },
>   "resources": { "cpus": 0.1, "mem": 32 },
>   "image": {
> "id": "alpine",
> "kind": "DOCKER"
>   }
> }
>   ],
>   "networks": [ {"mode": "host"} ]
> }
> {code}
> Mesos should probably check for this and avoid replacing the system root 
> mount point at startup or launch time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7327) Add a test with multiple tasks and checks for the default executor.

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7327:
--
Sprint: Mesosphere Sprint 54, Mesosphere Sprint 55, Mesosphere Sprint 56, 
Mesosphere Sprint 57, Mesosphere Sprint 58  (was: Mesosphere Sprint 54, 
Mesosphere Sprint 55, Mesosphere Sprint 56, Mesosphere Sprint 57)

> Add a test with multiple tasks and checks for the default executor.
> ---
>
> Key: MESOS-7327
> URL: https://issues.apache.org/jira/browse/MESOS-7327
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Alexander Rukletsov
>Assignee: Gastón Kleiman
>  Labels: health-check, mesosphere
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7488) Add `--ip6` and `--ip6_discovery_command` flag to Mesos agent

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7488:
--
Sprint: Mesosphere Sprint 57, Mesosphere Sprint 58  (was: Mesosphere Sprint 
57)

> Add `--ip6` and `--ip6_discovery_command` flag to Mesos agent
> -
>
> Key: MESOS-7488
> URL: https://issues.apache.org/jira/browse/MESOS-7488
> Project: Mesos
>  Issue Type: Task
>  Components: agent
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
> Fix For: 1.4.0
>
>
> As a first step to support IPv6 containers on Mesos, we need to provide 
> `--ip6` and `--ip6_discovery_command` flags to the agent so that the operator 
> can  specify an IPv6 address for the `libprocess` actor on the agent. In this 
> ticket we will not aim to add IPv6 communication support for Mesos but will 
> aim to use the IPv6 address provided by the operator to fill in the v6 
> address for any containers running on the host network in a dual stack 
> environment.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7415) Add authorization to master's operator maintenance API in v0 and v1

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7415:
--
Sprint: Mesosphere Sprint 56, Mesosphere Sprint 57, Mesosphere Sprint 58  
(was: Mesosphere Sprint 56, Mesosphere Sprint 57)

> Add authorization to master's operator maintenance API in v0 and v1
> ---
>
> Key: MESOS-7415
> URL: https://issues.apache.org/jira/browse/MESOS-7415
> Project: Mesos
>  Issue Type: Task
>  Components: c++ api, HTTP API, master
>Reporter: Alexander Rojas
>Assignee: Alexander Rojas
>  Labels: authorization, mesosphere, security
>
> None of the maintenance primitives in either API v0 or API v1 have any kind 
> of authorization, which allows any user with valid credentials to do things 
> such as shutting down a machine, schedule time off on an agent, modify 
> maintenance schedule, etc.
> The authorization support needs to be added to the v0 endpoints:
> * {{/master/machine/up}}
> * {{/master/machine/down}}
> * {{/master/maintenance/schedule}}
> * {{/master/maintenance/status}}
> as well as to the v1 calls:
> * {{GET_MAINTENANCE_STATUS}}
> * {{GET_MAINTENANCE_SCHEDULE}}
> * {{UPDATE_MAINTENANCE_SCHEDULE}}
> * {{START_MAINTENANCE}}
> * {{STOP_MAINTENANCE}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7416) Filter results of `/master/slaves` and the v1 call GET_AGENTS

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7416:
--
Sprint: Mesosphere Sprint 56, Mesosphere Sprint 57, Mesosphere Sprint 58  
(was: Mesosphere Sprint 56, Mesosphere Sprint 57)

> Filter results of `/master/slaves` and the v1 call GET_AGENTS
> -
>
> Key: MESOS-7416
> URL: https://issues.apache.org/jira/browse/MESOS-7416
> Project: Mesos
>  Issue Type: Task
>  Components: HTTP API, master
>Reporter: Alexander Rojas
>Assignee: Alexander Rojas
>  Labels: mesosphere, security
>
> The results returned by both the endpoint {{/master/slaves}} and the API v1 
> {{GET_AGENTS}} return full information about the agent state which probably 
> need to be filtered for certain uses, particularly in a multi-tenancy 
> scenario.
> The kind of leaked data includes specific role names and their specific 
> allocations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7443) Add the MARK_AGENT_GONE call to the Operator v1 API protos.

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7443:
--
Sprint: Mesosphere Sprint 56, Mesosphere Sprint 57, Mesosphere Sprint 58  
(was: Mesosphere Sprint 56, Mesosphere Sprint 57)

> Add the MARK_AGENT_GONE call to the Operator v1 API protos.
> ---
>
> Key: MESOS-7443
> URL: https://issues.apache.org/jira/browse/MESOS-7443
> Project: Mesos
>  Issue Type: Task
>Reporter: Anand Mazumdar
>Assignee: Anand Mazumdar
>  Labels: mesosphere
>
> We need to add the relevant call to the v1 Operator API protos to mark an 
> agent as GONE. The actual handler implementation on the master would be done 
> in a separate ticket.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7444) Add support for storing gone agents to the master registry.

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7444:
--
Sprint: Mesosphere Sprint 56, Mesosphere Sprint 57, Mesosphere Sprint 58  
(was: Mesosphere Sprint 56, Mesosphere Sprint 57)

> Add support for storing gone agents to the master registry.
> ---
>
> Key: MESOS-7444
> URL: https://issues.apache.org/jira/browse/MESOS-7444
> Project: Mesos
>  Issue Type: Task
>Reporter: Anand Mazumdar
>Assignee: Anand Mazumdar
>  Labels: mesosphere
>
> We need to add the {{MarkSlaveGone}} registry operation to the master 
> allowing it to store agents that have been marked as gone. The relevant 
> changes to {{registry.proto}} would also be done as part of this issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7414) Enable authorization for master's logging API calls: GET_LOGGING_LEVEL and SET_LOGGING_LEVEL

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7414:
--
Sprint: Mesosphere Sprint 56, Mesosphere Sprint 57, Mesosphere Sprint 58  
(was: Mesosphere Sprint 56, Mesosphere Sprint 57)

> Enable authorization for master's logging API calls: GET_LOGGING_LEVEL  and 
> SET_LOGGING_LEVEL
> -
>
> Key: MESOS-7414
> URL: https://issues.apache.org/jira/browse/MESOS-7414
> Project: Mesos
>  Issue Type: Task
>  Components: HTTP API, master
>Reporter: Alexander Rojas
>Assignee: Alexander Rojas
>  Labels: mesosphere, operator, security
>
> The Operator API calls {{GET_LOGGING_LEVEL}}  and {{SET_LOGGING_LEVEL}} lack 
> authorization so any recognized user will be able to change the logging level 
> of a given master.
> The v0 endpoint {{/logging/toggle}} has authorization through the 
> {{GET_ENDPOINT_WITH_PATH}} action. We need to decide whether it should also 
> use additional authorization.
> Note that there are already actions defined for authorization of these 
> actions as they were already implemented in the agent.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7305) Adjust the recover logic of MesosContainerizer to allow standalone containers.

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7305:
--
Sprint: Mesosphere Sprint 57, Mesosphere Sprint 58  (was: Mesosphere Sprint 
57)

> Adjust the recover logic of MesosContainerizer to allow standalone containers.
> --
>
> Key: MESOS-7305
> URL: https://issues.apache.org/jira/browse/MESOS-7305
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Jie Yu
>Assignee: Joseph Wu
>  Labels: mesosphere
>
> The current recovery logic in MesosContainerizer assumes that all top level 
> containers are tied to some Mesos executors. Adding standalone containers 
> will invalid this assumption. The recovery logic must be changed to adapt to 
> that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7007) filesystem/shared and --default_container_info broken since 1.1

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7007:
--
Sprint: Mesosphere Sprint 57, Mesosphere Sprint 58  (was: Mesosphere Sprint 
57)

> filesystem/shared and --default_container_info broken since 1.1
> ---
>
> Key: MESOS-7007
> URL: https://issues.apache.org/jira/browse/MESOS-7007
> Project: Mesos
>  Issue Type: Bug
>  Components: agent
>Affects Versions: 1.1.0, 1.2.0
>Reporter: Pierre Cheynier
>Assignee: Chun-Hung Hsiao
>
> I face this issue, that prevent me to upgrade to 1.1.0 (and the change was 
> consequently introduced in this version):
> I'm using default_container_info to mount a /tmp volume in the container's 
> mount namespace from its current sandbox, meaning that each container have a 
> dedicated /tmp, thanks to the {{filesystem/shared}} isolator.
> I noticed through our automation pipeline that integration tests were failing 
> and found that this is because /tmp (the one from the host!) contents is 
> trashed each time a container is created.
> Here is my setup: 
> * 
> {{--isolation='cgroups/cpu,cgroups/mem,namespaces/pid,*disk/du,filesystem/shared,filesystem/linux*,docker/runtime'}}
> * 
> {{--default_container_info='\{"type":"MESOS","volumes":\[\{"host_path":"tmp","container_path":"/tmp","mode":"RW"\}\]\}'}}
> I discovered this issue in the early days of 1.1 (end of Nov, spoke with 
> someone on Slack), but had unfortunately no time to dig into the symptoms a 
> bit more.
> I found nothing interesting even using GLOGv=3.
> Maybe it's a bad usage of isolators that trigger this issue ? If it's the 
> case, then at least a documentation update should be done.
> Let me know if more information is needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7423) Add s390x builds to Mesos CI

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7423:
--
Sprint: Mesosphere Sprint 57, Mesosphere Sprint 58  (was: Mesosphere Sprint 
57)

> Add s390x builds to Mesos CI
> 
>
> Key: MESOS-7423
> URL: https://issues.apache.org/jira/browse/MESOS-7423
> Project: Mesos
>  Issue Type: Task
>Reporter: Nayana Thorat
>Assignee: Vinod Kone
>
> Hi Vinod,
> We had raised an issue to add s390x support for mesos which was fixed and 
> resolved.
> https://issues.apache.org/jira/browse/MESOS-6742
> We also want to know about Mesos CI. 
> We need following details about current Mesos CI:
> 1. How is the current Mesos CI infrastructure? Travis/Jenkins?
> 2. Can Mesos CI extended to support s390x systems?
> We are not sure if this is right channel to discuss this topic. 
> Please let us know if you want to start this discussion on some other channel.
> Thanks,



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7314) Add offer operations for converting disk resources

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-7314:
--
Sprint: Mesosphere Sprint 55, Mesosphere Sprint 56, Mesosphere Sprint 57, 
Mesosphere Sprint 58  (was: Mesosphere Sprint 55, Mesosphere Sprint 56, 
Mesosphere Sprint 57)

> Add offer operations for converting disk resources
> --
>
> Key: MESOS-7314
> URL: https://issues.apache.org/jira/browse/MESOS-7314
> Project: Mesos
>  Issue Type: Task
>  Components: master
>Reporter: Jan Schlicht
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> One should be able to convert {{RAW}} and {{BLOCK}} disk resources into a 
> different types by applying operations to them. The offer operations and the 
> related validation and resource handling needs to be implemented.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7514) ReservationTest.PreventUnreservingAlienResources is flaky

[JIRA]

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

Gastón Kleiman commented on MESOS-7514:
---

This test is based on {{ReservationTest.ReserveShareWithinRole}}, which 
apparently has been flaky since it was introduced on May 2015.

Both tests have a bug, they do the following to create a {{Filter}} to decline 
resources "forever":

{noformat}
filtersForever.set_refuse_seconds(std::numeric_limits::max());
{noformat}

But that doesn't work as expected, because the maximum value for 
{{Filter::refuse_seconds}} is {{Duration::max().ns() / Seconds(1).ns()}}, so 
the allocator uses the default {{Filter}} instead (5 seconds).

Both tests consistently fail once I fix the "forever" filter.

I have to do some more digging to find out if there's a bug/race in the 
allocator or if the tests should be fixed.

> ReservationTest.PreventUnreservingAlienResources is flaky
> -
>
> Key: MESOS-7514
> URL: https://issues.apache.org/jira/browse/MESOS-7514
> Project: Mesos
>  Issue Type: Bug
>Reporter: Neil Conway
>Assignee: Gastón Kleiman
>  Labels: mesosphere
>
> This repros consistently for me on a many-core box:
> {noformat}
> [ RUN  ] ReservationTest.PreventUnreservingAlienResources
> I0516 11:15:51.562351 26940 cluster.cpp:162] Creating default 'local' 
> authorizer
> I0516 11:15:51.656114 26996 master.cpp:436] Master 
> 0495c63b-8319-43fb-809c-6a18c7005548 (core-dev) started on 10.0.49.2:33500
> I0516 11:15:51.656159 26996 master.cpp:438] Flags at startup: --acls="" 
> --agent_ping_timeout="15secs" --agent_reregister_timeout="10mins" 
> --allocation_interval="5ms" --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/PGp9GX/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" 
> --max_unreachable_tasks_per_framework="1000" --port="5050" --quiet="false" 
> --recovery_agent_removal_limit="100%" --registry="in_memory" 
> --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/PGp9GX/master" 
> --zk_session_timeout="10secs"
> I0516 11:15:51.658516 26996 master.cpp:488] Master only allowing 
> authenticated frameworks to register
> I0516 11:15:51.658540 26996 master.cpp:502] Master only allowing 
> authenticated agents to register
> I0516 11:15:51.658597 26996 master.cpp:515] Master only allowing 
> authenticated HTTP frameworks to register
> I0516 11:15:51.658615 26996 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/PGp9GX/credentials'
> I0516 11:15:51.659363 26996 master.cpp:560] Using default 'crammd5' 
> authenticator
> I0516 11:15:51.659560 26996 authenticator.cpp:519] Initializing server SASL
> I0516 11:15:51.660568 26996 http.cpp:975] Creating default 'basic' HTTP 
> authenticator for realm 'mesos-master-readonly'
> I0516 11:15:51.660923 26996 http.cpp:975] Creating default 'basic' HTTP 
> authenticator for realm 'mesos-master-readwrite'
> I0516 11:15:51.661057 26996 http.cpp:975] Creating default 'basic' HTTP 
> authenticator for realm 'mesos-master-scheduler'
> I0516 11:15:51.661219 26996 master.cpp:640] Authorization enabled
> I0516 11:15:51.672745 26976 master.cpp:2161] Elected as the leading master!
> I0516 11:15:51.672835 26976 master.cpp:1700] Recovering from registrar
> I0516 11:15:51.676582 26987 registrar.cpp:389] Successfully fetched the 
> registry (0B) in 3.4112ms
> I0516 11:15:51.676875 26987 registrar.cpp:493] Applied 1 operations in 
> 56756ns; attempting to update the registry
> I0516 11:15:51.680197 26987 registrar.cpp:550] Successfully updated the 
> registry in 3.24608ms
> I0516 11:15:51.680672 26987 registrar.cpp:422] Successfully recovered 
> registrar
> I0516 11:15:51.681761 26964 master.cpp:1799] Recovered 0 agents from the 
> registry (119B); allowing 10mins for agents to re-register
> I0516 11:15:51.779008 26940 containerizer.cpp:221] Using isolation: 
> posix/cpu,posix/mem,filesystem/posix,network/cni
> W0516 11:15:51.779985 26940 backend.cpp:76] Failed to create 'overlay' 

[jira] [Commented] (MESOS-7639) Oversubscription could crash the master due to CHECK failure in the allocator

[Zhitao Li (JIRA)]

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

Zhitao Li commented on MESOS-7639:
--

So, I've created a test in 
https://github.com/zhitaoli/mesos/tree/zhitao/1.1.2/drf_sorter_crash_test which 
reliably crashes with the matching condition. 

However, when applying the same test to current master (with minimal 
modification), this does not crash the master anymore (the branch is at 
https://github.com/zhitaoli/mesos/tree/zhitao/public/revocable_drf_crash_test)

With a bit more logging analysis, it seems like the change to 
{{HierarchicalAllocatorProcess::updateAllocation()}} in [r/55359 | 
https://reviews.apache.org/r/55359/diff/6#index_header] might have taken out 
the crashing scenario because it now updates the {{frameworkSorter}} by 
{{offeredResources}} rather than {{frameworkAllocation}}, so the 
{{frameworkSorter}} stays in an over-allocated situation during the race 
condition, until {{Master::_accept}} calls {{allocator->recoverResources}} from 
the offer, in which the over allocation gets corrected.

[~bmahler][~xujyan], can you please comment on whether my reading of above is 
correct? If so, I suspect we don't have a verified way to trigger a master 
crash due to over-allocation after 1.2.0 release?

> Oversubscription could crash the master due to CHECK failure in the allocator
> -
>
> Key: MESOS-7639
> URL: https://issues.apache.org/jira/browse/MESOS-7639
> Project: Mesos
>  Issue Type: Bug
>Reporter: Yan Xu
>
> As I described in MESOS-7566, the following scenario is possible when the 
> agent sends updated oversubscribed resources to the master:
> - The agent's {{UpdateSlaveMessage}} reduces the the oversubscribed resources.
> - {{Master::updateSlave}} upon receiving the update would first call 
> {{HierarchicalAllocatorProcess::updateSlave}}, followed by 
> {{allocator->recoverResources}}.
> - {{HierarchicalAllocatorProcess::updateSlave}} would update 
> {{roleSorter.total_}} to reduce to total so the total could go below the 
> allocation.
> - In the subsequent {{allocator->recoverResources}} call the attempt to 
> remove outstanding allocation may fail to reduce it to below the total 
> because some allocation may not be in outstanding offers. It could be in 
> offered resources pending between {{Master::accept}} and {{Master::_accept}}. 
> So the end result could still be {{total < allocation}}.
> - Then when {{Master::_accept}} is executed, it will then call 
> {{allocator->updateAllocation}}, in which the {{total < allocation}} 
> condition could trigger such crash.
> The gist is that there are resources that are neither in master's {{offers}} 
> or tracked in the allocator when {{Master::updateSlave}} is called.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7634) OsTest.ChownNoAccess fails on s390x machines

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-7634:
---

The above docker build command will run `make check` which will build and 
execute test cases as well.

> OsTest.ChownNoAccess fails on s390x machines
> 
>
> Key: MESOS-7634
> URL: https://issues.apache.org/jira/browse/MESOS-7634
> Project: Mesos
>  Issue Type: Bug
>Reporter: Vinod Kone
>
> Running a custom branch of Mesos (with some fixes in docker build scripts for 
> s390x) on s390x based CI machines throws the following error when running 
> stout tests.
> {code}
> [ RUN  ] OsTest.ChownNoAccess
> ../../../../3rdparty/stout/tests/os_tests.cpp:839: Failure
> Value of: os::chown(uid.get(), gid.get(), "one", true).isError()
>   Actual: false
> Expected: true
> ../../../../3rdparty/stout/tests/os_tests.cpp:840: Failure
> Value of: os::chown(uid.get(), gid.get(), "one/two", true).isError()
>   Actual: false
> {code}
> One can repro this by building Mesos from my custom branch here: 
> https://github.com/vinodkone/mesos/tree/vinod/s390x



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7654) mesos fetcher download files with incorrect permission

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7654:
---

Github user lycing commented on the issue:

https://github.com/apache/mesos/pull/218
  
this bug is fixed already, close it.


> mesos fetcher download files with incorrect permission
> --
>
> Key: MESOS-7654
> URL: https://issues.apache.org/jira/browse/MESOS-7654
> Project: Mesos
>  Issue Type: Bug
>  Components: docker, fetcher
>Affects Versions: 1.2.0
>Reporter: chenmingjie
>Priority: Minor
>
> mesos fectcher download uri file as root permission in docker 
> container,though  we have pointed out a common user in CommandInfo  or Task



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7654) mesos fetcher download files with incorrect permission

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7654:
---

Github user bbannier commented on the issue:

https://github.com/apache/mesos/pull/218
  
For code changes like this one we prefer working with our JIRA and 
reviewboard, https://mesos.apache.org/documentation/latest/submitting-a-patch/. 
Could you submit a review request to reviewboard? You probably also want to 
assign the issue to you.


> mesos fetcher download files with incorrect permission
> --
>
> Key: MESOS-7654
> URL: https://issues.apache.org/jira/browse/MESOS-7654
> Project: Mesos
>  Issue Type: Bug
>  Components: docker, fetcher
>Affects Versions: 1.2.0
>Reporter: chenmingjie
>Priority: Minor
>
> mesos fectcher download uri file as root permission in docker 
> container,though  we have pointed out a common user in CommandInfo  or Task



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7654) mesos fetcher download files with incorrect permission

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7654:
---

GitHub user lycing opened a pull request:

https://github.com/apache/mesos/pull/218

MESOS-7654 Fix owner of fetched files in docker containerizer

Fix the wrong owner while mesos-fetcher downloading files，and test passed 
in our production environment，from issue 
[MESOS-7654](https://issues.apache.org/jira/browse/MESOS-7654)
@jieyu @Gilbert88 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/lycing/mesos master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/218.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #218


commit 8f740dc28a06b055572311ffef8f59aba0ea0eac
Author: lycing 
Date:   2017-06-13T10:43:05Z

Update docker.cpp

fix the wrong owner while mesos-fetcher download files

commit 0a07fed19017b21d5d448746f0870dd374f3a76d
Author: LiuYanchun 
Date:   2017-06-13T14:15:51Z

Fix owner of fetched files in docker containerizer




> mesos fetcher download files with incorrect permission
> --
>
> Key: MESOS-7654
> URL: https://issues.apache.org/jira/browse/MESOS-7654
> Project: Mesos
>  Issue Type: Bug
>  Components: docker, fetcher
>Affects Versions: 1.2.0
>Reporter: chenmingjie
>Priority: Minor
>
> mesos fectcher download uri file as root permission in docker 
> container,though  we have pointed out a common user in CommandInfo  or Task



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7634) OsTest.ChownNoAccess fails on s390x machines

[vandita (JIRA)]

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

vandita commented on MESOS-7634:


Hi Vinod,

Thanks for the details.The build has now gone ahead with the above 
commands.once build is successful will be executing the test cases. Could you 
please give me datails of the commands used to execute test cases?

> OsTest.ChownNoAccess fails on s390x machines
> 
>
> Key: MESOS-7634
> URL: https://issues.apache.org/jira/browse/MESOS-7634
> Project: Mesos
>  Issue Type: Bug
>Reporter: Vinod Kone
>
> Running a custom branch of Mesos (with some fixes in docker build scripts for 
> s390x) on s390x based CI machines throws the following error when running 
> stout tests.
> {code}
> [ RUN  ] OsTest.ChownNoAccess
> ../../../../3rdparty/stout/tests/os_tests.cpp:839: Failure
> Value of: os::chown(uid.get(), gid.get(), "one", true).isError()
>   Actual: false
> Expected: true
> ../../../../3rdparty/stout/tests/os_tests.cpp:840: Failure
> Value of: os::chown(uid.get(), gid.get(), "one/two", true).isError()
>   Actual: false
> {code}
> One can repro this by building Mesos from my custom branch here: 
> https://github.com/vinodkone/mesos/tree/vinod/s390x



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7657) Consider setting the initial delay of 0 for agent registration in tests.

[Michael Park (JIRA)]

Michael Park created MESOS-7657:
---

 Summary: Consider setting the initial delay of 0 for agent 
registration in tests.
 Key: MESOS-7657
 URL: https://issues.apache.org/jira/browse/MESOS-7657
 Project: Mesos
  Issue Type: Task
  Components: test
Reporter: Michael Park


Consider setting the initial delay of 0 for agent registration in tests, so 
that we don't have to do the following.

{code}
  Clock::advance(slaveFlags.authentication_backoff_factor);
579 
  Clock::advance(slaveFlags.registration_backoff_factor);
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7656) Update the JSON <=> protobuf message conversion for map support

[Qian Zhang (JIRA)]

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

Qian Zhang commented on MESOS-7656:
---

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

> Update the JSON <=> protobuf message conversion for map support
> ---
>
> Key: MESOS-7656
> URL: https://issues.apache.org/jira/browse/MESOS-7656
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Qian Zhang
>Assignee: Qian Zhang
>
> [Map|https://developers.google.com/protocol-buffers/docs/proto#maps] is a 
> feature starting from proto2 syntax, but it can only be compiled with proto3 
> compiler, see the following discussion for details:
> https://groups.google.com/forum/#\!topic/protobuf/p4WxcplrlA4
> We have already upgraded the protobuf compiler from 2.6.1 to 3.3.0 in 
> [MESOS-7228|https://issues.apache.org/jira/browse/MESOS-7228], however, to 
> use protobuf map in Mesos code, we also need to add the protobuf map support 
> to the code in Mesos for converting protobuf message to JSON object and 
> parsing JSON object as protobuf message, that is what we plan to handle in 
> this ticket.
> With map support added, the following field in the protobuf message can be 
> replaced by the native protobuf map field, and we do not have to manually 
> parse it anymore.
> https://github.com/apache/mesos/blob/1.3.0/include/mesos/docker/v1.proto#L68



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7656) Update the JSON <=> protobuf message conversion for map support

[Qian Zhang (JIRA)]

Qian Zhang created MESOS-7656:
-

 Summary: Update the JSON <=> protobuf message conversion for map 
support
 Key: MESOS-7656
 URL: https://issues.apache.org/jira/browse/MESOS-7656
 Project: Mesos
  Issue Type: Improvement
Reporter: Qian Zhang
Assignee: Qian Zhang


[Map|https://developers.google.com/protocol-buffers/docs/proto#maps] is a 
feature starting from proto2 syntax, but it can only be compiled with proto3 
compiler, see the following discussion for details:
https://groups.google.com/forum/#\!topic/protobuf/p4WxcplrlA4
We have already upgraded the protobuf compiler from 2.6.1 to 3.3.0 in 
[MESOS-7228|https://issues.apache.org/jira/browse/MESOS-7228], however, to use 
protobuf map in Mesos code, we also need to add the protobuf map support to the 
code in Mesos for converting protobuf message to JSON object and parsing JSON 
object as protobuf message, that is what we plan to handle in this ticket.

With map support added, the following field in the protobuf message can be 
replaced by the native protobuf map field, and we do not have to manually parse 
it anymore.
https://github.com/apache/mesos/blob/1.3.0/include/mesos/docker/v1.proto#L68



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)