[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.

[Jay Guo (JIRA)]

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

Jay Guo commented on MESOS-5593:


OK.

BTW, do you guys do other forms of scale tests other than concurrency test in 
MESOS-5222?

> Devolve v1 operator protos before using them in Master/Agent.
> -
>
> Key: MESOS-5593
> URL: https://issues.apache.org/jira/browse/MESOS-5593
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: haosdent
>Priority: Critical
>  Labels: mesosphere
>
> We had adopted the following workflow for the Scheduler/Executor endpoints on 
> the Master/Agent.
> - The user makes a call to the versioned endpoint with a versioned protobuf. 
> e.g., {{v1::mesos::Call}}
> - We {{devolve}} the versioned protobuf into an unversioned protobuf before 
> using it internally.
> {code}
> scheduler::Call call = devolve(v1Call);
> {code}
> The above approach has the advantage that the internal Mesos code only has to 
> deal with unversioned protobufs. It looks like we have not been following 
> this idiom for the Operator API. We should create a unversioned protobuf file 
> similar to we did for the Scheduler/Executor API and then {{devolve}} the 
> versioned protobufs. (e.g., mesos/master/master.proto)
> The signature of some of the operator endpoints would then change to only be 
> dealing with unversioned protobufs:
> {code}
> Future Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}



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

[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.

[Jay Guo (JIRA)]

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

Jay Guo commented on MESOS-5593:


 [~haosd...@gmail.com] let me know when you are done with internal master.proto 
and I will rebase accordingly.

> Devolve v1 operator protos before using them in Master/Agent.
> -
>
> Key: MESOS-5593
> URL: https://issues.apache.org/jira/browse/MESOS-5593
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: haosdent
>Priority: Critical
>  Labels: mesosphere
>
> We had adopted the following workflow for the Scheduler/Executor endpoints on 
> the Master/Agent.
> - The user makes a call to the versioned endpoint with a versioned protobuf. 
> e.g., {{v1::mesos::Call}}
> - We {{devolve}} the versioned protobuf into an unversioned protobuf before 
> using it internally.
> {code}
> scheduler::Call call = devolve(v1Call);
> {code}
> The above approach has the advantage that the internal Mesos code only has to 
> deal with unversioned protobufs. It looks like we have not been following 
> this idiom for the Operator API. We should create a unversioned protobuf file 
> similar to we did for the Scheduler/Executor API and then {{devolve}} the 
> versioned protobufs. (e.g., mesos/master/master.proto)
> The signature of some of the operator endpoints would then change to only be 
> dealing with unversioned protobufs:
> {code}
> Future Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}



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

[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar commented on MESOS-5593:
---

Thanks [~haosd...@gmail.com] :-)

> Devolve v1 operator protos before using them in Master/Agent.
> -
>
> Key: MESOS-5593
> URL: https://issues.apache.org/jira/browse/MESOS-5593
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: haosdent
>Priority: Critical
>  Labels: mesosphere
>
> We had adopted the following workflow for the Scheduler/Executor endpoints on 
> the Master/Agent.
> - The user makes a call to the versioned endpoint with a versioned protobuf. 
> e.g., {{v1::mesos::Call}}
> - We {{devolve}} the versioned protobuf into an unversioned protobuf before 
> using it internally.
> {code}
> scheduler::Call call = devolve(v1Call);
> {code}
> The above approach has the advantage that the internal Mesos code only has to 
> deal with unversioned protobufs. It looks like we have not been following 
> this idiom for the Operator API. We should create a unversioned protobuf file 
> similar to we did for the Scheduler/Executor API and then {{devolve}} the 
> versioned protobufs. (e.g., mesos/master/master.proto)
> The signature of some of the operator endpoints would then change to only be 
> dealing with unversioned protobufs:
> {code}
> Future Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}



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

[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar commented on MESOS-5593:
---

The main problem with some of the past methods is that they did not have a 
corresponding protobuf message/schema or the schema is not analogous to the new 
API. Hopefully, this won't be the case when we move to {{v2}}.

Let's take an example:

For {{v2}}, a user would hit the {{/api/v2}} endpoint, we would {{devolve}} the 
request to a {{mesos::master}} unversioned protobuf and use it internally. 
While sending the response back to the client, it would be {{evolve}}'d back to 
{{v2}}. There should not be any noticeable performance degradations (at least 
we did not observe them while doing scale testing as part of MESOS-5222. 

Hope this helps.

> Devolve v1 operator protos before using them in Master/Agent.
> -
>
> Key: MESOS-5593
> URL: https://issues.apache.org/jira/browse/MESOS-5593
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: haosdent
>Priority: Critical
>  Labels: mesosphere
>
> We had adopted the following workflow for the Scheduler/Executor endpoints on 
> the Master/Agent.
> - The user makes a call to the versioned endpoint with a versioned protobuf. 
> e.g., {{v1::mesos::Call}}
> - We {{devolve}} the versioned protobuf into an unversioned protobuf before 
> using it internally.
> {code}
> scheduler::Call call = devolve(v1Call);
> {code}
> The above approach has the advantage that the internal Mesos code only has to 
> deal with unversioned protobufs. It looks like we have not been following 
> this idiom for the Operator API. We should create a unversioned protobuf file 
> similar to we did for the Scheduler/Executor API and then {{devolve}} the 
> versioned protobufs. (e.g., mesos/master/master.proto)
> The signature of some of the operator endpoints would then change to only be 
> dealing with unversioned protobufs:
> {code}
> Future Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}



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

[jira] [Comment Edited] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.

[Jay Guo (JIRA)]

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

Jay Guo edited comment on MESOS-5593 at 6/10/16 4:55 AM:
-

OK. However this evolving/devolving sound heavy and I wonder if we will 
encounter performance issue. Another thing is that we implement Operator APIs 
in different styles, some of them are implemented from scratch and others are 
reusing methods/logics from previous implementation. I imagine we would have 
similar problems at v2. Therefore, we end up with a very mixed and tedious 
codebase.

I don't really have a clear idea on this but my point is that we want to 
maintain performance while enhancing readability. For people who are not 
familiar with the history, first sight of current code is quite intimidating.

Backwards compatibility is always a pain.


was (Author: guoger):
OK. However this evolving/devolving sound heavy and I wonder if we will 
encounter performance issue. Another thing is that we implement Operator APIs 
in different styles, some of them are implemented from scratch and others are 
reusing methods/logics from previous implementation. I imagine we would have 
similar problems at v2. Therefore, we end up with a very mixed and tedious 
codebase.

> Devolve v1 operator protos before using them in Master/Agent.
> -
>
> Key: MESOS-5593
> URL: https://issues.apache.org/jira/browse/MESOS-5593
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: haosdent
>Priority: Critical
>  Labels: mesosphere
>
> We had adopted the following workflow for the Scheduler/Executor endpoints on 
> the Master/Agent.
> - The user makes a call to the versioned endpoint with a versioned protobuf. 
> e.g., {{v1::mesos::Call}}
> - We {{devolve}} the versioned protobuf into an unversioned protobuf before 
> using it internally.
> {code}
> scheduler::Call call = devolve(v1Call);
> {code}
> The above approach has the advantage that the internal Mesos code only has to 
> deal with unversioned protobufs. It looks like we have not been following 
> this idiom for the Operator API. We should create a unversioned protobuf file 
> similar to we did for the Scheduler/Executor API and then {{devolve}} the 
> versioned protobufs. (e.g., mesos/master/master.proto)
> The signature of some of the operator endpoints would then change to only be 
> dealing with unversioned protobufs:
> {code}
> Future Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}



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

[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.

[Jay Guo (JIRA)]

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

Jay Guo commented on MESOS-5593:


OK. However this evolving/devolving sound heavy and I wonder if we will 
encounter performance issue. Another thing is that we implement Operator APIs 
in different styles, some of them are implemented from scratch and others are 
reusing methods/logics from previous implementation. I imagine we would have 
similar problems at v2. Therefore, we end up with a very mixed and tedious 
codebase.

> Devolve v1 operator protos before using them in Master/Agent.
> -
>
> Key: MESOS-5593
> URL: https://issues.apache.org/jira/browse/MESOS-5593
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: haosdent
>Priority: Critical
>  Labels: mesosphere
>
> We had adopted the following workflow for the Scheduler/Executor endpoints on 
> the Master/Agent.
> - The user makes a call to the versioned endpoint with a versioned protobuf. 
> e.g., {{v1::mesos::Call}}
> - We {{devolve}} the versioned protobuf into an unversioned protobuf before 
> using it internally.
> {code}
> scheduler::Call call = devolve(v1Call);
> {code}
> The above approach has the advantage that the internal Mesos code only has to 
> deal with unversioned protobufs. It looks like we have not been following 
> this idiom for the Operator API. We should create a unversioned protobuf file 
> similar to we did for the Scheduler/Executor API and then {{devolve}} the 
> versioned protobufs. (e.g., mesos/master/master.proto)
> The signature of some of the operator endpoints would then change to only be 
> dealing with unversioned protobufs:
> {code}
> Future Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}



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

[jira] [Comment Edited] (MESOS-5544) Support running Mesos agent in a Docker container.

[Jie Yu (JIRA)]

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

Jie Yu edited comment on MESOS-5544 at 6/10/16 4:45 AM:


Worked on a prototype here:
https://github.com/jieyu/mesos/tree/agent_in_docker

Tested with the following docker container and run command. The agent recovery 
works well!
{noformat}
sudo docker run \
  --net=host \
  --pid=host \
  --privileged \
  -e GLOG_v=1 \
  -e LIBPROCESS_IP=10.0.2.15 \
  -e MESOS_MASTER=10.0.2.15:5050 \
  -e MESOS_HOSTNAME=localhost \
  -e MESOS_WORK_DIR=/var/lib/mesos \
  -e MESOS_DOCKER_STORE_DIR=/var/lib/mesos/store \
  -e MESOS_ISOLATION=cgroups/cpu,cgroups/mem,docker/runtime,filesystem/linux \
  -e MESOS_IMAGE_PROVIDERS=docker \
  -e MESOS_SYSTEMD_ENABLE_SUPPORT=false \
  -v /var/run/mesos:/var/run/mesos:shared \
  -v /var/lib/mesos:/var/lib/mesos:shared \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /cgroup:/cgroup \
  -v /sys:/sys \
  -v /usr/local/bin/docker:/usr/local/bin/docker \
  jieyu/mesos-from-source mesos-slave
{noformat}


was (Author: jieyu):
Worked on a prototype here:
https://github.com/jieyu/mesos/tree/agent_in_docker

Will update with a docker image soon

> Support running Mesos agent in a Docker container.
> --
>
> Key: MESOS-5544
> URL: https://issues.apache.org/jira/browse/MESOS-5544
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Jie Yu
>
> Currently, this does not work if one tries to use Mesos containerizer.
> The main problem is that we want to make sure the executor is not killed when 
> agent crashes. So we have to use --pid=host so that the agent is in the host 
> pid namespace.
> But that is not sufficient, Docker daemon will put agent into all cgroups 
> available on the host. We need to make sure we migrate the executor pid out 
> of those cgroups so that when agent crashes, executors are not killed.
> Also, when start the agent container, volumes need to be setup properly so 
> that any mounts under agent's work_dir will be propagate back to the host 
> mount table. This is to make sure we can recover those mounts after agent 
> restarts. This is also true for those mounts that are needed by some isolator 
> (e.g., network/cni isolator).



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

[jira] [Created] (MESOS-5594) Merge release-plan and download pages

[haosdent (JIRA)]

haosdent created MESOS-5594:
---

 Summary: Merge release-plan and download pages
 Key: MESOS-5594
 URL: https://issues.apache.org/jira/browse/MESOS-5594
 Project: Mesos
  Issue Type: Improvement
  Components: project website
Reporter: haosdent


Create this ticket according to the discussion in [ r48518| 
https://reviews.apache.org/r/48518/ ]

{quote}
>From [~janisz]
It duplicates data from Downloads, maybe it could be merged into one page.
{quote}

{quote}
>From [~jieyu]
This is slightly different from Downloads, because it might also contains 
information about a future release (e.g., what will be the major feature 
expected for a future release).

I agree with you that there's some duplication right now. Let's create a ticket 
to track the merge of these two pages. Once that's resolved, we can use the 
same link from the home page? An alternative is have a link in the download 
page to point to this page. But I like the idea of merging the Download page 
with this!
{quote}



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

[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.

[haosdent (JIRA)]

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

haosdent commented on MESOS-5593:
-

I think we always could change the unversioned protobuf message and make sure 
it could convert to v1 or v2 more easily because it is only used internally. 
But change v1 or v2 should be difficult because it have been public.

{quote}
Simply adding the new one?
{quote}

I think just need add a more evolve/devolve method. 

> Devolve v1 operator protos before using them in Master/Agent.
> -
>
> Key: MESOS-5593
> URL: https://issues.apache.org/jira/browse/MESOS-5593
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: haosdent
>Priority: Critical
>  Labels: mesosphere
>
> We had adopted the following workflow for the Scheduler/Executor endpoints on 
> the Master/Agent.
> - The user makes a call to the versioned endpoint with a versioned protobuf. 
> e.g., {{v1::mesos::Call}}
> - We {{devolve}} the versioned protobuf into an unversioned protobuf before 
> using it internally.
> {code}
> scheduler::Call call = devolve(v1Call);
> {code}
> The above approach has the advantage that the internal Mesos code only has to 
> deal with unversioned protobufs. It looks like we have not been following 
> this idiom for the Operator API. We should create a unversioned protobuf file 
> similar to we did for the Scheduler/Executor API and then {{devolve}} the 
> versioned protobufs. (e.g., mesos/master/master.proto)
> The signature of some of the operator endpoints would then change to only be 
> dealing with unversioned protobufs:
> {code}
> Future Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}



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

[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.

[Jay Guo (JIRA)]

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

Jay Guo commented on MESOS-5593:


Sounds reasonable. Just wanna understand it further, are we going to have 
versioned protobuf messages in {{mesos/v1/}} and unversioned protobuf message 
in {{mesos/}}? I suppose all versioned messages are aggregated in unversioned 
one? In this case, if we have structure change in v2, how do we maintain 
compatibility in unversioned one? Simply adding the new one?

/J

> Devolve v1 operator protos before using them in Master/Agent.
> -
>
> Key: MESOS-5593
> URL: https://issues.apache.org/jira/browse/MESOS-5593
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: haosdent
>Priority: Critical
>  Labels: mesosphere
>
> We had adopted the following workflow for the Scheduler/Executor endpoints on 
> the Master/Agent.
> - The user makes a call to the versioned endpoint with a versioned protobuf. 
> e.g., {{v1::mesos::Call}}
> - We {{devolve}} the versioned protobuf into an unversioned protobuf before 
> using it internally.
> {code}
> scheduler::Call call = devolve(v1Call);
> {code}
> The above approach has the advantage that the internal Mesos code only has to 
> deal with unversioned protobufs. It looks like we have not been following 
> this idiom for the Operator API. We should create a unversioned protobuf file 
> similar to we did for the Scheduler/Executor API and then {{devolve}} the 
> versioned protobufs. (e.g., mesos/master/master.proto)
> The signature of some of the operator endpoints would then change to only be 
> dealing with unversioned protobufs:
> {code}
> Future Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}



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

[jira] [Commented] (MESOS-5544) Support running Mesos agent in a Docker container.

[Jie Yu (JIRA)]

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

Jie Yu commented on MESOS-5544:
---

Worked on a prototype here:
https://github.com/jieyu/mesos/tree/agent_in_docker

Will update with a docker image soon

> Support running Mesos agent in a Docker container.
> --
>
> Key: MESOS-5544
> URL: https://issues.apache.org/jira/browse/MESOS-5544
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Jie Yu
>
> Currently, this does not work if one tries to use Mesos containerizer.
> The main problem is that we want to make sure the executor is not killed when 
> agent crashes. So we have to use --pid=host so that the agent is in the host 
> pid namespace.
> But that is not sufficient, Docker daemon will put agent into all cgroups 
> available on the host. We need to make sure we migrate the executor pid out 
> of those cgroups so that when agent crashes, executors are not killed.
> Also, when start the agent container, volumes need to be setup properly so 
> that any mounts under agent's work_dir will be propagate back to the host 
> mount table. This is to make sure we can recover those mounts after agent 
> restarts. This is also true for those mounts that are needed by some isolator 
> (e.g., network/cni isolator).



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

[jira] [Assigned] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.

[haosdent (JIRA)]

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

haosdent reassigned MESOS-5593:
---

Assignee: haosdent

> Devolve v1 operator protos before using them in Master/Agent.
> -
>
> Key: MESOS-5593
> URL: https://issues.apache.org/jira/browse/MESOS-5593
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: haosdent
>Priority: Critical
>  Labels: mesosphere
>
> We had adopted the following workflow for the Scheduler/Executor endpoints on 
> the Master/Agent.
> - The user makes a call to the versioned endpoint with a versioned protobuf. 
> e.g., {{v1::mesos::Call}}
> - We {{devolve}} the versioned protobuf into an unversioned protobuf before 
> using it internally.
> {code}
> scheduler::Call call = devolve(v1Call);
> {code}
> The above approach has the advantage that the internal Mesos code only has to 
> deal with unversioned protobufs. It looks like we have not been following 
> this idiom for the Operator API. We should create a unversioned protobuf file 
> similar to we did for the Scheduler/Executor API and then {{devolve}} the 
> versioned protobufs. (e.g., mesos/master/master.proto)
> The signature of some of the operator endpoints would then change to only be 
> dealing with unversioned protobufs:
> {code}
> Future Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}



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

[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.

[haosdent (JIRA)]

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

haosdent commented on MESOS-5593:
-

I think I could help on this.

> Devolve v1 operator protos before using them in Master/Agent.
> -
>
> Key: MESOS-5593
> URL: https://issues.apache.org/jira/browse/MESOS-5593
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Priority: Critical
>  Labels: mesosphere
>
> We had adopted the following workflow for the Scheduler/Executor endpoints on 
> the Master/Agent.
> - The user makes a call to the versioned endpoint with a versioned protobuf. 
> e.g., {{v1::mesos::Call}}
> - We {{devolve}} the versioned protobuf into an unversioned protobuf before 
> using it internally.
> {code}
> scheduler::Call call = devolve(v1Call);
> {code}
> The above approach has the advantage that the internal Mesos code only has to 
> deal with unversioned protobufs. It looks like we have not been following 
> this idiom for the Operator API. We should create a unversioned protobuf file 
> similar to we did for the Scheduler/Executor API and then {{devolve}} the 
> versioned protobufs. (e.g., mesos/master/master.proto)
> The signature of some of the operator endpoints would then change to only be 
> dealing with unversioned protobufs:
> {code}
> Future Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}



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

[jira] [Comment Edited] (MESOS-5578) Support static address allocation in CNI

[Avinash Sridharan (JIRA)]

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

Avinash Sridharan edited comment on MESOS-5578 at 6/10/16 2:47 AM:
---

Good point.

The only catch is that if we blindly specify the `ipaddress` in the CNI_ARGS it 
becomes a de-facto standard that any other plugin that supports static IP 
address allocation will require to follow in order to allocate static IP 
addresses. Would like to have this specified in the spec so that we don't have 
to do plugin specific support. 


was (Author: avin...@mesosphere.io):
Good point.

The only catch is that if blindly specify the `ipaddress` in the CNI_ARGS it 
becomes a de-facto standard that any other plugin that supports static IP 
address allocation will require to follow to. Would like to have this specified 
in the spec so that we don't have to do plugin specific support. 

> Support static address allocation in CNI
> 
>
> Key: MESOS-5578
> URL: https://issues.apache.org/jira/browse/MESOS-5578
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Affects Versions: 1.0.0
> Environment: Linux
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
>
> Currently a framework can't specify a static IP address for the container 
> when using the network/cni isolator.
> The `ipaddress` field in the `NetworkInfo` protobuf was designed for this 
> specific purpose but since the CNI spec does not specify a means to allocate 
> an IP address to the container the `network/cni` isolator cannot honor this 
> field even when it is filled in by the framework.
> Creating this ticket to act as a place holder to track this limitation. As 
> and when the CNI spec allows us to specify a static IP address for the 
> container, we can resolve this ticket. 



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

[jira] [Created] (MESOS-5592) Pass NetworkInfo.Labels to CNI Plugins

[Dan Osborne (JIRA)]

Dan Osborne created MESOS-5592:
--

 Summary: Pass NetworkInfo.Labels to CNI Plugins
 Key: MESOS-5592
 URL: https://issues.apache.org/jira/browse/MESOS-5592
 Project: Mesos
  Issue Type: Improvement
Reporter: Dan Osborne
 Fix For: 1.0.0


Mesos has adopted the Container Network Interface as a simple means of 
networking Mesos tasks launched by the Unified Containerizer. The CNI 
specification covers a minimum feature set, granting the flexibility to add 
customized networking functionality in the form of agreements made between the 
orchestrator and CNI plugin.

This proposal is to pass NetworkInfo.Labels to the CNI plugin by injecting it 
into the CNI network configuration json during plugin invocation.

Design Doc on this change: 
https://docs.google.com/document/d/1rxruCCcJqpppsQxQrzTbHFVnnW6CgQ2oTieYAmwL284/edit?usp=sharing

reviewboard: https://reviews.apache.org/r/48527/



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

[jira] [Commented] (MESOS-5578) Support static address allocation in CNI

[Qian Zhang (JIRA)]

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

Qian Zhang commented on MESOS-5578:
---

[~avin...@mesosphere.io], in [CNI spec | 
https://github.com/containernetworking/cni/blob/master/SPEC.md#parameters], 
there is parameter "CNI_ARGS" which can be used to pass extra argument to the 
CNI plugin, and I see the [host-local | 
https://github.com/containernetworking/cni/blob/master/Documentation/host-local.md#supported-arguments]
 IPAM plugin has already supported "CNI_ARGS" with which user can specify an IP 
that he/she wants to assign to the container.

So for any CNI networks which uses host-local IPAM plugin, they will support 
static IP address allocation.

> Support static address allocation in CNI
> 
>
> Key: MESOS-5578
> URL: https://issues.apache.org/jira/browse/MESOS-5578
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Affects Versions: 1.0.0
> Environment: Linux
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
>
> Currently a framework can't specify a static IP address for the container 
> when using the network/cni isolator.
> The `ipaddress` field in the `NetworkInfo` protobuf was designed for this 
> specific purpose but since the CNI spec does not specify a means to allocate 
> an IP address to the container the `network/cni` isolator cannot honor this 
> field even when it is filled in by the framework.
> Creating this ticket to act as a place holder to track this limitation. As 
> and when the CNI spec allows us to specify a static IP address for the 
> container, we can resolve this ticket. 



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

[jira] [Commented] (MESOS-5586) Move design docs from wiki to web page

[Tomasz Janiszewski (JIRA)]

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

Tomasz Janiszewski commented on MESOS-5586:
---

Done. I cloned and renamed this issue.

> Move design docs from wiki to web page
> --
>
> Key: MESOS-5586
> URL: https://issues.apache.org/jira/browse/MESOS-5586
> Project: Mesos
>  Issue Type: Documentation
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>Priority: Minor
>
> {quote}
> Hi folks,
> I am proposing moving our content in Wiki (e.g., working groups, release
> tracking, etc.) to our docs in the code repo. I personally found that wiki
> is hard to use and there's no reviewing process for changes in the Wiki.
> The content in Wiki historically received less attention than that in the
> docs.
> What do you think?
> - Jie
> {quote}
> http://www.mail-archive.com/dev@mesos.apache.org/msg35506.html



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

[jira] [Created] (MESOS-5591) Move working groups from wiki to web page

[Tomasz Janiszewski (JIRA)]

Tomasz Janiszewski created MESOS-5591:
-

 Summary: Move working groups from wiki to web page
 Key: MESOS-5591
 URL: https://issues.apache.org/jira/browse/MESOS-5591
 Project: Mesos
  Issue Type: Documentation
Reporter: Tomasz Janiszewski
Assignee: Tomasz Janiszewski
Priority: Minor


{quote}
Hi folks,

I am proposing moving our content in Wiki (e.g., working groups, release
tracking, etc.) to our docs in the code repo. I personally found that wiki
is hard to use and there's no reviewing process for changes in the Wiki.
The content in Wiki historically received less attention than that in the
docs.

What do you think?

- Jie
{quote}
http://www.mail-archive.com/dev@mesos.apache.org/msg35506.html



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

[jira] [Updated] (MESOS-4279) Docker executor truncates task's output when the task is killed.

[Benjamin Mahler (JIRA)]

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

Benjamin Mahler updated MESOS-4279:
---
Shepherd: Jie Yu  (was: Alexander Rukletsov)

> Docker executor truncates task's output when the task is killed.
> 
>
> Key: MESOS-4279
> URL: https://issues.apache.org/jira/browse/MESOS-4279
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization, docker
>Affects Versions: 0.25.0, 0.26.0, 0.27.2, 0.28.1
>Reporter: Martin Bydzovsky
>Assignee: Benjamin Mahler
>Priority: Critical
>  Labels: docker, mesosphere
> Fix For: 1.0.0
>
>
> I'm implementing a graceful restarts of our mesos-marathon-docker setup and I 
> came to a following issue:
> (it was already discussed on 
> https://github.com/mesosphere/marathon/issues/2876 and guys form mesosphere 
> got to a point that its probably a docker containerizer problem...)
> To sum it up:
> When i deploy simple python script to all mesos-slaves:
> {code}
> #!/usr/bin/python
> from time import sleep
> import signal
> import sys
> import datetime
> def sigterm_handler(_signo, _stack_frame):
> print "got %i" % _signo
> print datetime.datetime.now().time()
> sys.stdout.flush()
> sleep(2)
> print datetime.datetime.now().time()
> print "ending"
> sys.stdout.flush()
> sys.exit(0)
> signal.signal(signal.SIGTERM, sigterm_handler)
> signal.signal(signal.SIGINT, sigterm_handler)
> try:
> print "Hello"
> i = 0
> while True:
> i += 1
> print datetime.datetime.now().time()
> print "Iteration #%i" % i
> sys.stdout.flush()
> sleep(1)
> finally:
> print "Goodbye"
> {code}
> and I run it through Marathon like
> {code:javascript}
> data = {
>   args: ["/tmp/script.py"],
>   instances: 1,
>   cpus: 0.1,
>   mem: 256,
>   id: "marathon-test-api"
> }
> {code}
> During the app restart I get expected result - the task receives sigterm and 
> dies peacefully (during my script-specified 2 seconds period)
> But when i wrap this python script in a docker:
> {code}
> FROM node:4.2
> RUN mkdir /app
> ADD . /app
> WORKDIR /app
> ENTRYPOINT []
> {code}
> and run appropriate application by Marathon:
> {code:javascript}
> data = {
>   args: ["./script.py"],
>   container: {
>   type: "DOCKER",
>   docker: {
>   image: "bydga/marathon-test-api"
>   },
>   forcePullImage: yes
>   },
>   cpus: 0.1,
>   mem: 256,
>   instances: 1,
>   id: "marathon-test-api"
> }
> {code}
> The task during restart (issued from marathon) dies immediately without 
> having a chance to do any cleanup.



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

[jira] [Created] (MESOS-5590) Move release plan from wiki to web page

[Tomasz Janiszewski (JIRA)]

Tomasz Janiszewski created MESOS-5590:
-

 Summary: Move release plan from wiki to web page
 Key: MESOS-5590
 URL: https://issues.apache.org/jira/browse/MESOS-5590
 Project: Mesos
  Issue Type: Documentation
Reporter: Tomasz Janiszewski
Assignee: Tomasz Janiszewski
Priority: Minor


{quote}
Hi folks,

I am proposing moving our content in Wiki (e.g., working groups, release
tracking, etc.) to our docs in the code repo. I personally found that wiki
is hard to use and there's no reviewing process for changes in the Wiki.
The content in Wiki historically received less attention than that in the
docs.

What do you think?

- Jie
{quote}
http://www.mail-archive.com/dev@mesos.apache.org/msg35506.html



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

[jira] [Updated] (MESOS-5586) Move design docs from wiki to web page

[Tomasz Janiszewski (JIRA)]

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

Tomasz Janiszewski updated MESOS-5586:
--
Summary: Move design docs from wiki to web page  (was: Move from wiki to 
web page)

> Move design docs from wiki to web page
> --
>
> Key: MESOS-5586
> URL: https://issues.apache.org/jira/browse/MESOS-5586
> Project: Mesos
>  Issue Type: Documentation
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>Priority: Minor
>
> {quote}
> Hi folks,
> I am proposing moving our content in Wiki (e.g., working groups, release
> tracking, etc.) to our docs in the code repo. I personally found that wiki
> is hard to use and there's no reviewing process for changes in the Wiki.
> The content in Wiki historically received less attention than that in the
> docs.
> What do you think?
> - Jie
> {quote}
> http://www.mail-archive.com/dev@mesos.apache.org/msg35506.html



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

[jira] [Updated] (MESOS-5581) Guarantee ordering between Isolators

[Benjamin Mahler (JIRA)]

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

Benjamin Mahler updated MESOS-5581:
---
Shepherd: Benjamin Mahler  (was: Jie Yu)

> Guarantee ordering between Isolators
> 
>
> Key: MESOS-5581
> URL: https://issues.apache.org/jira/browse/MESOS-5581
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Kevin Klues
>Assignee: Kevin Klues
>  Labels: isolator, mesosphere
>
> Some isolators depend on other isolators. However, we currently do not have a 
> generic method of expressing these dependencies. We special case the 
> `filesystem/*` isolators to make sure that dependencies on them are 
> satisfied, but no other dependencies can be expressed.
> 
> Instead, we should use a vector to represent the pairing of isolator name to 
> isolator creator function. This way, the relative dependencies between each 
> isolator will be implicit in the ordering of the vector. Currently, a hashmap 
> is used to hold this pairing, but this is inadequate because hashmaps are 
> inherently unordered. The new implementation using a vector will ensure 
> everything is processed in the order it is listed.



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

[jira] [Commented] (MESOS-5588) Improve error handling when parsing acls.

[Adam B (JIRA)]

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

Adam B commented on MESOS-5588:
---

Looks related to https://issues.apache.org/jira/browse/MESOS-5406

> Improve error handling when parsing acls.
> -
>
> Key: MESOS-5588
> URL: https://issues.apache.org/jira/browse/MESOS-5588
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> During parsing of the authorizer errors are ignored. This can lead to 
> undetected security issues.
> Consider the following acl with an typo (usr instead of od user)
> {code}
>"view_frameworks": [
>   {
> "principals": { "type": "ANY" },
> "usr": { "type": "NONE" }
>   }
> ]
> {code}
> When the master is started with these flags it will interprete the acl int he 
> following way which gives any principal access to any framework.
> {noformat}
> view_frameworks {
>   principals {
> type: ANY
>   }
> }
> {noformat}



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

[jira] [Created] (MESOS-5588) Improve error handling when parsing acls.

[Joerg Schad (JIRA)]

Joerg Schad created MESOS-5588:
--

 Summary: Improve error handling when parsing acls.
 Key: MESOS-5588
 URL: https://issues.apache.org/jira/browse/MESOS-5588
 Project: Mesos
  Issue Type: Improvement
Reporter: Joerg Schad
Assignee: Joerg Schad


During parsing of the authorizer errors are ignored. This can lead to 
undetected security issues.

Consider the following acl with an typo (usr instead of od user)
{code}
   "view_frameworks": [
  {
"principals": { "type": "ANY" },
"usr": { "type": "NONE" }
  }
]
{code}

When the master is started with these flags it will interprete the acl int he 
following way which gives any principal access to any framework.

{noformat}
view_frameworks {
  principals {
type: ANY
  }
}
{noformat}



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

[jira] [Updated] (MESOS-5174) Update the balloon-framework to run on test clusters

[Joseph Wu (JIRA)]

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

Joseph Wu updated MESOS-5174:
-
Sprint: Mesosphere Sprint 33, Mesosphere Sprint 37  (was: Mesosphere Sprint 
33)

> Update the balloon-framework to run on test clusters
> 
>
> Key: MESOS-5174
> URL: https://issues.apache.org/jira/browse/MESOS-5174
> Project: Mesos
>  Issue Type: Improvement
>  Components: framework, technical debt
>Reporter: Joseph Wu
>Assignee: Joseph Wu
>  Labels: mesosphere, tech-debt
>
> There are a couple of problems with the balloon framework that prevent it 
> from being deployed (easily) on an actual cluster:
> * The framework accepts 100% of memory in an offer.  This means the expected 
> behavior (finish or OOM) is dependent on the offer size.
> * The framework assumes the {{balloon-executor}} binary is available on each 
> agent.  This is generally only true in the build environment or in 
> single-agent test environments.
> * The framework does not specify CPUs with the executor.  This is required by 
> many isolators.
> * The executor's {{TASK_FINISHED}} logic path was untested and is flaky.
> * The framework has no metrics.
> * The framework only launches a single task and then exits.  With this 
> behavior, we can't have useful metrics.



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

[jira] [Commented] (MESOS-5586) Move from wiki to web page

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-5586:
---

This could be an epic with tickets for each of the things (design docs, release 
planning, roadmap etc) that need movement

> Move from wiki to web page
> --
>
> Key: MESOS-5586
> URL: https://issues.apache.org/jira/browse/MESOS-5586
> Project: Mesos
>  Issue Type: Documentation
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>Priority: Minor
>
> {quote}
> Hi folks,
> I am proposing moving our content in Wiki (e.g., working groups, release
> tracking, etc.) to our docs in the code repo. I personally found that wiki
> is hard to use and there's no reviewing process for changes in the Wiki.
> The content in Wiki historically received less attention than that in the
> docs.
> What do you think?
> - Jie
> {quote}
> http://www.mail-archive.com/dev@mesos.apache.org/msg35506.html



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

[jira] [Commented] (MESOS-5145) protobuf vendored but its depencencies are not

[Ian Downes (JIRA)]

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

Ian Downes commented on MESOS-5145:
---

This has impacted me as well. My test machine does not have external network 
access and so building with python support now fails. Previously, building did 
not require internet access (last time I checked was 0.27.x).

> protobuf vendored but its depencencies are not
> --
>
> Key: MESOS-5145
> URL: https://issues.apache.org/jira/browse/MESOS-5145
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: David Robinson
>  Labels: mesosphere
>
> Updating [protobuf from 2.5 to 
> 2.6.1|https://github.com/apache/mesos/commit/51872fba7f94d80e55c9cc9b46f96780a938f626]
>  has caused Mesos builds to fail if pypi.python.org is unreachable. 
> Protobuf-2.6.1 requires 
> [google-apputils|https://pypi.python.org/pypi/google-apputils] and if it's 
> not available the build process will attempt to download it from pypi.
> Prior to this change it was possible to build Mesos without Internet access. 
> If the build process reaches out to arbitrary things on the Internet it's 
> impossible to guarantee build reproducibility.
> {noformat:title=snippet from setup.py in protobuf-2.6.1.tar.gz}
>   setup(name = 'protobuf',
> version = '2.6.1',
> ...
> setup_requires = ['google-apputils'],
> ...
> )
> {noformat}
> {noformat:title=snippet from build log}
> 08:20:49 DEBUG: Building protobuf Python egg ...
> 08:20:49 DEBUG: cd ../3rdparty/libprocess/3rdparty/protobuf-2.6.1/python &&   
> \
> 08:20:49 DEBUG: CC="gcc"  \
> 08:20:49 DEBUG: CXX="g++" \
> 08:20:49 DEBUG: CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic 
> -Wno-unused-local-typedefs"   \
> 08:20:49 DEBUG: CXXFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic 
> -Wno-unused-local-typedefs -Wno-maybe-uninitialized -std=c++11"   
>   \
> 08:20:49 DEBUG: 
> PYTHONPATH=/builddir/build/BUILD/mesos-0.29.0/3rdparty/distribute-0.6.26  
> \
> 08:20:49 DEBUG: /usr/bin/python2.7 setup.py build bdist_egg
> 08:20:49 DEBUG: Download error on 
> http://pypi.python.org/simple/google-apputils/: [Errno 111] Connection 
> refused -- Some packages may not be found!
> 08:20:49 DEBUG: Download error on 
> http://pypi.python.org/simple/google-apputils/: [Errno 111] Connection 
> refused -- Some packages may not be found!
> 08:20:49 DEBUG: Couldn't find index page for 'google-apputils' (maybe 
> misspelled?)
> 08:20:49 DEBUG: Download error on http://pypi.python.org/simple/: [Errno 111] 
> Connection refused -- Some packages may not be found!
> 08:20:49 DEBUG: No local packages or download links found for google-apputils
> 08:20:49 DEBUG: Traceback (most recent call last):
> 08:20:49 DEBUG:   File "setup.py", line 200, in 
> 08:20:49 DEBUG: "Protocol Buffers are Google's data interchange format.",
> 08:20:49 DEBUG:   File "/usr/lib64/python2.7/distutils/core.py", line 111, in 
> setup
> 08:20:49 DEBUG: _setup_distribution = dist = klass(attrs)
> 08:20:49 DEBUG:   File 
> "/builddir/build/BUILD/mesos-0.29.0/3rdparty/distribute-0.6.26/setuptools/dist.py",
>  line 221, in __init__
> 08:20:49 DEBUG: self.fetch_build_eggs(attrs.pop('setup_requires'))
> 08:20:49 DEBUG:   File 
> "/builddir/build/BUILD/mesos-0.29.0/3rdparty/distribute-0.6.26/setuptools/dist.py",
>  line 245, in fetch_build_eggs
> 08:20:49 DEBUG: parse_requirements(requires), 
> installer=self.fetch_build_egg
> 08:20:49 DEBUG:   File 
> "/builddir/build/BUILD/mesos-0.29.0/3rdparty/distribute-0.6.26/pkg_resources.py",
>  line 580, in resolve
> 08:20:49 DEBUG: dist = best[req.key] = env.best_match(req, self, 
> installer)
> 08:20:49 DEBUG:   File 
> "/builddir/build/BUILD/mesos-0.29.0/3rdparty/distribute-0.6.26/pkg_resources.py",
>  line 825, in best_match
> 08:20:49 DEBUG: return self.obtain(req, installer) # try and 
> download/install
> 08:20:49 DEBUG:   File 
> "/builddir/build/BUILD/mesos-0.29.0/3rdparty/distribute-0.6.26/pkg_resources.py",
>  line 837, in obtain
> 08:20:49 DEBUG: return installer(requirement)
> 08:20:49 DEBUG:   File 
> "/builddir/build/BUILD/mesos-0.29.0/3rdparty/distribute-0.6.26/setuptools/dist.py",
>  line 294, in fetch_build_egg
> 08:20:49 DEBUG: return cmd.easy_install(req)
> 08:20:49 DEBUG:   File 
> "/builddir/build/BUILD/mesos-0.29.0/3rdparty/distribute-0.6.26/setuptools/command/easy_install.py",
>  line 584, in easy_install
> 08:20:49 DEBUG: raise 

[jira] [Updated] (MESOS-5577) Modules using replicated log state API require zookeeper headers

[Avinash Sridharan (JIRA)]

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

Avinash Sridharan updated MESOS-5577:
-
Sprint: Mesosphere Sprint 36

> Modules using replicated log state API require zookeeper headers
> 
>
> Key: MESOS-5577
> URL: https://issues.apache.org/jira/browse/MESOS-5577
> Project: Mesos
>  Issue Type: Bug
>  Components: modules
>Affects Versions: 1.0.0
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
> Fix For: 1.0.0
>
>
> The state API uses zookeeper client headers and hence the bundled zookeeper 
> headers need to be installed during Mesos installation. 



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

[jira] [Updated] (MESOS-5561) Need to remove references to "messages/messages.hpp" from `State` API

[Jie Yu (JIRA)]

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

Jie Yu updated MESOS-5561:
--
  Sprint: Mesosphere Sprint 36
Story Points: 2

> Need to remove references to "messages/messages.hpp" from `State` API
> -
>
> Key: MESOS-5561
> URL: https://issues.apache.org/jira/browse/MESOS-5561
> Project: Mesos
>  Issue Type: Bug
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
> Fix For: 1.0.0
>
>
> In order to expose the `State` API for using replicated log in Mesos modules 
> it is necessary that the `State` API does not reference headers that are not 
> exposed as part of the Mesos installation. 
> Currently include/mesos/state/protobuf.hpp references 
> src/messages/messages.hpp making the `State` API unusable in a module. 
> We need to move the protobuf `serialize`/`deserialize` functions out of 
> messages.hpp and move them to `stout/protobuf.hpp`. This will help us remove 
> references to messages.hpp from the `State` API.



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

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

[Jie Yu (JIRA)]

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

Jie Yu commented on MESOS-5585:
---

Thanks for filing the ticket! Definitely make sense. Probably introduce an 
agent flag to allow operators to configure the pids.max for containers.

> 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
>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] [Commented] (MESOS-5586) Move from wiki to web page

[Jie Yu (JIRA)]

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

Jie Yu commented on MESOS-5586:
---

commit 6f970a7badacf16953ebbc2c72c6ae7eb5e662e2
Author: Tomasz Janiszewski 
Date:   Thu Jun 9 10:23:00 2016 -0700

Moved design docs from wiki to page.

Change was discussed at
http://www.mail-archive.com/dev@mesos.apache.org/msg35506.html

Review: https://reviews.apache.org/r/48499/

> Move from wiki to web page
> --
>
> Key: MESOS-5586
> URL: https://issues.apache.org/jira/browse/MESOS-5586
> Project: Mesos
>  Issue Type: Documentation
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>Priority: Minor
>
> {quote}
> Hi folks,
> I am proposing moving our content in Wiki (e.g., working groups, release
> tracking, etc.) to our docs in the code repo. I personally found that wiki
> is hard to use and there's no reviewing process for changes in the Wiki.
> The content in Wiki historically received less attention than that in the
> docs.
> What do you think?
> - Jie
> {quote}
> http://www.mail-archive.com/dev@mesos.apache.org/msg35506.html



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

[jira] [Created] (MESOS-5586) Move from wiki to web page

[Tomasz Janiszewski (JIRA)]

Tomasz Janiszewski created MESOS-5586:
-

 Summary: Move from wiki to web page
 Key: MESOS-5586
 URL: https://issues.apache.org/jira/browse/MESOS-5586
 Project: Mesos
  Issue Type: Documentation
Reporter: Tomasz Janiszewski
Assignee: Tomasz Janiszewski
Priority: Minor


{quote}
Hi folks,

I am proposing moving our content in Wiki (e.g., working groups, release
tracking, etc.) to our docs in the code repo. I personally found that wiki
is hard to use and there's no reviewing process for changes in the Wiki.
The content in Wiki historically received less attention than that in the
docs.

What do you think?

- Jie
{quote}
http://www.mail-archive.com/dev@mesos.apache.org/msg35506.html



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

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

[Jeffrey Schroeder (JIRA)]

Jeffrey Schroeder created MESOS-5585:


 Summary: 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
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] [Updated] (MESOS-2068) Add comments that explain framework, executor ID, and task life cycle in slave

[Adam B (JIRA)]

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

Adam B updated MESOS-2068:
--
Story Points:   (was: 0.25)

> Add comments that explain framework, executor ID, and task life cycle in slave
> --
>
> Key: MESOS-2068
> URL: https://issues.apache.org/jira/browse/MESOS-2068
> Project: Mesos
>  Issue Type: Improvement
>  Components: documentation, slave
>Reporter: Bernd Mathiske
>Assignee: Bernd Mathiske
>Priority: Minor
>  Labels: mesosphere
>
> Fixing MESOS-947 was relatively difficult because the source code is mostly 
> the only source of information with regard to the life cycle of frameworks, 
> executors, and tasks in the slave. In particular this leads to confusion 
> about whether there could be a task lost state  at the beginning of 
> _runTask() when the framework is NULL. This shall be explained to the best of 
> the assignees knowledge.
> For context see https://reviews.apache.org/r/27567
> with these comments:
> On Nov. 5, 2014, 7:50 p.m., Ben Mahler wrote:
> src/slave/slave.cpp, lines 1195-1200
> 
>A comment here as to why we don't need to send TASK_LOST would be much 
> appreciated! It's not obvious so someone might come along and add a TASK_LOST 
> to make sure we're not dropping the task on the floor, so context here would 
> be great!
> Bernd Mathiske wrote:
>Hah, thanks for sharing - I am not alone! :-) None of this was obvious to 
> me either, because there is no comment explaining the general life cycle of 
> anything. Once you understand the intended life cycle, there is now way there 
> can be a TASK_LOST situation here, though. Therefore I propose adding 
> comments describing the overall picture regarding frameworks, executor IDs 
> and task creation in the appropriate places, instead. I'll file a ticket if 
> you agree.
> Once you understand the intended life cycle, there is now way there can be a 
> TASK_LOST situation here, though.
> Phew! :)
> Could you distill your learnings into a comment here, and maybe make the log 
> message more informative? Even with an overall description as you mentioned, 
> dummies like me would still get confused here given the lack of _local_ 
> context. ;)
> - Ben



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

[jira] [Updated] (MESOS-2068) Add comments that explain framework, executor ID, and task life cycle in slave

[Adam B (JIRA)]

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

Adam B updated MESOS-2068:
--
Assignee: (was: Bernd Mathiske)

> Add comments that explain framework, executor ID, and task life cycle in slave
> --
>
> Key: MESOS-2068
> URL: https://issues.apache.org/jira/browse/MESOS-2068
> Project: Mesos
>  Issue Type: Improvement
>  Components: documentation, slave
>Reporter: Bernd Mathiske
>Priority: Minor
>  Labels: mesosphere
>
> Fixing MESOS-947 was relatively difficult because the source code is mostly 
> the only source of information with regard to the life cycle of frameworks, 
> executors, and tasks in the slave. In particular this leads to confusion 
> about whether there could be a task lost state  at the beginning of 
> _runTask() when the framework is NULL. This shall be explained to the best of 
> the assignees knowledge.
> For context see https://reviews.apache.org/r/27567
> with these comments:
> On Nov. 5, 2014, 7:50 p.m., Ben Mahler wrote:
> src/slave/slave.cpp, lines 1195-1200
> 
>A comment here as to why we don't need to send TASK_LOST would be much 
> appreciated! It's not obvious so someone might come along and add a TASK_LOST 
> to make sure we're not dropping the task on the floor, so context here would 
> be great!
> Bernd Mathiske wrote:
>Hah, thanks for sharing - I am not alone! :-) None of this was obvious to 
> me either, because there is no comment explaining the general life cycle of 
> anything. Once you understand the intended life cycle, there is now way there 
> can be a TASK_LOST situation here, though. Therefore I propose adding 
> comments describing the overall picture regarding frameworks, executor IDs 
> and task creation in the appropriate places, instead. I'll file a ticket if 
> you agree.
> Once you understand the intended life cycle, there is now way there can be a 
> TASK_LOST situation here, though.
> Phew! :)
> Could you distill your learnings into a comment here, and maybe make the log 
> message more informative? Even with an overall description as you mentioned, 
> dummies like me would still get confused here given the lack of _local_ 
> context. ;)
> - Ben



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

[jira] [Commented] (MESOS-2199) Failing test: SlaveTest.ROOT_RunTaskWithCommandInfoWithUser

[Adam B (JIRA)]

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

Adam B commented on MESOS-2199:
---

I haven't seen this test fail in a while. Anybody else seen a recent error with 
this test?

> Failing test: SlaveTest.ROOT_RunTaskWithCommandInfoWithUser
> ---
>
> Key: MESOS-2199
> URL: https://issues.apache.org/jira/browse/MESOS-2199
> Project: Mesos
>  Issue Type: Bug
>  Components: test
>Reporter: Ian Downes
>Assignee: haosdent
>  Labels: mesosphere
>
> Appears that running the executor as {{nobody}} is not supported.
> [~nnielsen] can you take a look?
> Executor log:
> {noformat}
> [root@hostname build]# cat 
> /tmp/SlaveTest_ROOT_RunTaskWithCommandInfoWithUser_cxF1dY/slaves/20141219-005206-2081170186-60487-11862-S0/frameworks/20141219-005206-2081170186-60
> 487-11862-/executors/1/runs/latest/std*
> sh: /home/idownes/workspace/mesos/build/src/mesos-executor: Permission denied
> {noformat}
> Test output:
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from SlaveTest
> [ RUN  ] SlaveTest.ROOT_RunTaskWithCommandInfoWithUser
> ../../src/tests/slave_tests.cpp:680: Failure
> Value of: statusRunning.get().state()
>   Actual: TASK_FAILED
> Expected: TASK_RUNNING
> ../../src/tests/slave_tests.cpp:682: Failure
> Failed to wait 10secs for statusFinished
> ../../src/tests/slave_tests.cpp:673: Failure
> Actual function call count doesn't match EXPECT_CALL(sched, 
> statusUpdate(, _))...
>  Expected: to be called twice
>Actual: called once - unsatisfied and active
> [  FAILED  ] SlaveTest.ROOT_RunTaskWithCommandInfoWithUser (10641 ms)
> [--] 1 test from SlaveTest (10641 ms total)
> [--] Global test environment tear-down
> [==] 1 test from 1 test case ran. (10658 ms total)
> {noformat}



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

[jira] [Updated] (MESOS-3787) Expand environment variables through the Docker executor.

[Adam B (JIRA)]

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

Adam B updated MESOS-3787:
--
Assignee: (was: Adam B)

> Expand environment variables through the Docker executor.
> -
>
> Key: MESOS-3787
> URL: https://issues.apache.org/jira/browse/MESOS-3787
> Project: Mesos
>  Issue Type: Wish
>Reporter: John Garcia
>  Labels: mesosphere
> Attachments: mesos.patch, test-example.json
>
>
> We'd like to have expanded variables usable in [the json files used to create 
> a Marathon app, hence] the Task's CommandInfo, so that the executor is able 
> to detect the correct values at runtime.



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

[jira] [Created] (MESOS-5584) ContainerLoggerTest.DefaultToSandbox is slow

[Neil Conway (JIRA)]

Neil Conway created MESOS-5584:
--

 Summary: ContainerLoggerTest.DefaultToSandbox is slow
 Key: MESOS-5584
 URL: https://issues.apache.org/jira/browse/MESOS-5584
 Project: Mesos
  Issue Type: Improvement
  Components: tests
Reporter: Neil Conway


{noformat}
[ RUN  ] ContainerLoggerTest.DefaultToSandbox
[   OK ] ContainerLoggerTest.DefaultToSandbox (4187 ms)
{noformat}




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

[jira] [Updated] (MESOS-5343) Behavior of custom HTTP authenticators with disabled HTTP authentication is inconsistent between master and agent

[Adam B (JIRA)]

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

Adam B updated MESOS-5343:
--
Sprint: Mesosphere Sprint 37

> Behavior of custom HTTP authenticators with disabled HTTP authentication is 
> inconsistent between master and agent
> -
>
> Key: MESOS-5343
> URL: https://issues.apache.org/jira/browse/MESOS-5343
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Benjamin Bannier
>Priority: Minor
>  Labels: mesosphere, security
>
> When setting a custom authenticator with {{http_authenticators}} and also 
> specifying {{authenticate_http=false}} currently agents refuse to start with
> {code}
> A custom HTTP authenticator was specified with the '--http_authenticators' 
> flag, but HTTP authentication was not enabled via '--authenticate_http'
> {code}
> Masters on the other hand accept this setting.
> Having differing behavior between master and agents is confusing, and we 
> should decide on whether we want to accept these settings or not, and make 
> the implementations consistent.



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

[jira] [Updated] (MESOS-2043) Framework auth fail with timeout error and never get authenticated

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-2043:
-
Assignee: Benjamin Bannier
 Summary: Framework auth fail with timeout error and never get 
authenticated  (was: framework auth fail with timeout error and never get 
authenticated)

> Framework auth fail with timeout error and never get authenticated
> --
>
> Key: MESOS-2043
> URL: https://issues.apache.org/jira/browse/MESOS-2043
> Project: Mesos
>  Issue Type: Bug
>  Components: master, scheduler driver, security, slave
>Affects Versions: 0.21.0
>Reporter: Bhuvan Arumugam
>Assignee: Benjamin Bannier
>Priority: Critical
>  Labels: mesosphere, security
> Attachments: aurora-scheduler.20141104-1606-1706.log, master.log, 
> mesos-master.20141104-1606-1706.log, slave.log
>
>
> I'm facing this issue in master as of 
> https://github.com/apache/mesos/commit/74ea59e144d131814c66972fb0cc14784d3503d4
> As [~adam-mesos] mentioned in IRC, this sounds similar to MESOS-1866. I'm 
> running 1 master and 1 scheduler (aurora). The framework authentication fail 
> due to time out:
> error on mesos master:
> {code}
> I1104 19:37:17.741449  8329 master.cpp:3874] Authenticating 
> scheduler-d2d4437b-d375-4467-a583-362152fe065a@SCHEDULER_IP:8083
> I1104 19:37:17.741585  8329 master.cpp:3885] Using default CRAM-MD5 
> authenticator
> I1104 19:37:17.742106  8336 authenticator.hpp:169] Creating new server SASL 
> connection
> W1104 19:37:22.742959  8329 master.cpp:3953] Authentication timed out
> W1104 19:37:22.743548  8329 master.cpp:3930] Failed to authenticate 
> scheduler-d2d4437b-d375-4467-a583-362152fe065a@SCHEDULER_IP:8083: 
> Authentication discarded
> {code}
> scheduler error:
> {code}
> I1104 19:38:57.885486 49012 sched.cpp:283] Authenticating with master 
> master@MASTER_IP:PORT
> I1104 19:38:57.885928 49002 authenticatee.hpp:133] Creating new client SASL 
> connection
> I1104 19:38:57.890581 49007 authenticatee.hpp:224] Received SASL 
> authentication mechanisms: CRAM-MD5
> I1104 19:38:57.890656 49007 authenticatee.hpp:250] Attempting to authenticate 
> with mechanism 'CRAM-MD5'
> W1104 19:39:02.891196 49005 sched.cpp:378] Authentication timed out
> I1104 19:39:02.891850 49018 sched.cpp:338] Failed to authenticate with master 
> master@MASTER_IP:PORT: Authentication discarded
> {code}
> Looks like 2 instances {{scheduler-20f88a53-5945-4977-b5af-28f6c52d3c94}} & 
> {{scheduler-d2d4437b-d375-4467-a583-362152fe065a}} of same framework is 
> trying to authenticate and fail.
> {code}
> W1104 19:36:30.769420  8319 master.cpp:3930] Failed to authenticate 
> scheduler-20f88a53-5945-4977-b5af-28f6c52d3c94@SCHEDULER_IP:8083: Failed to 
> communicate with authenticatee
> I1104 19:36:42.701441  8328 master.cpp:3860] Queuing up authentication 
> request from scheduler-d2d4437b-d375-4467-a583-362152fe065a@SCHEDULER_IP:8083 
> because authentication is still in progress
> {code}
> Restarting master and scheduler didn't fix it. 
> This particular issue happen with 1 master and 1 scheduler after MESOS-1866 
> is fixed.



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

[jira] [Updated] (MESOS-5232) Add capability information to ContainerInfo protobuf message.

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-5232:
-
Sprint: Mesosphere Sprint 33, Mesosphere Sprint 34, Mesosphere Sprint 35, 
Mesosphere Sprint 37  (was: Mesosphere Sprint 33, Mesosphere Sprint 34, 
Mesosphere Sprint 35)

> Add capability information to ContainerInfo protobuf message.
> -
>
> Key: MESOS-5232
> URL: https://issues.apache.org/jira/browse/MESOS-5232
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Jojy Varghese
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> To enable support for capability as first class framework entity, we need to 
> add capabilities related information to the ContainerInfo protobuf.



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

[jira] [Updated] (MESOS-5275) Add capabilities support for unified containerizer.

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-5275:
-
Sprint: Mesosphere Sprint 34, Mesosphere Sprint 35, Mesosphere Sprint 37  
(was: Mesosphere Sprint 34, Mesosphere Sprint 35)

> Add capabilities support for unified containerizer.
> ---
>
> Key: MESOS-5275
> URL: https://issues.apache.org/jira/browse/MESOS-5275
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Jojy Varghese
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> Add capabilities support for unified containerizer. 
> Requirements:
> 1. Use the mesos capabilities API.
> 2. Frameworks be able to add capability requests for containers.
> 3. Agents be able to add maximum allowed capabilities for all containers 
> launched.
> Design document: 
> https://docs.google.com/document/d/1YiTift8TQla2vq3upQr7K-riQ_pQ-FKOCOsysQJROGc/edit#heading=h.rgfwelqrskmd



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

[jira] [Updated] (MESOS-5228) Add tests for Capability API.

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-5228:
-
Sprint: Mesosphere Sprint 33, Mesosphere Sprint 34, Mesosphere Sprint 35, 
Mesosphere Sprint 37  (was: Mesosphere Sprint 33, Mesosphere Sprint 34, 
Mesosphere Sprint 35)

> Add tests for Capability API.
> -
>
> Key: MESOS-5228
> URL: https://issues.apache.org/jira/browse/MESOS-5228
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Jojy Varghese
>Assignee: Jojy Varghese
>  Labels: mesosphere, unified-containerizer-mvp
>
> Add basic tests for the capability API.



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

[jira] [Updated] (MESOS-5275) Add capabilities support for unified containerizer.

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-5275:
-
Sprint: Mesosphere Sprint 34, Mesosphere Sprint 35  (was: Mesosphere Sprint 
34, Mesosphere Sprint 35, Mesosphere Sprint 36)

> Add capabilities support for unified containerizer.
> ---
>
> Key: MESOS-5275
> URL: https://issues.apache.org/jira/browse/MESOS-5275
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Jojy Varghese
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> Add capabilities support for unified containerizer. 
> Requirements:
> 1. Use the mesos capabilities API.
> 2. Frameworks be able to add capability requests for containers.
> 3. Agents be able to add maximum allowed capabilities for all containers 
> launched.
> Design document: 
> https://docs.google.com/document/d/1YiTift8TQla2vq3upQr7K-riQ_pQ-FKOCOsysQJROGc/edit#heading=h.rgfwelqrskmd



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

[jira] [Updated] (MESOS-5232) Add capability information to ContainerInfo protobuf message.

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-5232:
-
Sprint: Mesosphere Sprint 33, Mesosphere Sprint 34, Mesosphere Sprint 35  
(was: Mesosphere Sprint 33, Mesosphere Sprint 34, Mesosphere Sprint 35, 
Mesosphere Sprint 36)

> Add capability information to ContainerInfo protobuf message.
> -
>
> Key: MESOS-5232
> URL: https://issues.apache.org/jira/browse/MESOS-5232
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Jojy Varghese
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> To enable support for capability as first class framework entity, we need to 
> add capabilities related information to the ContainerInfo protobuf.



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

[jira] [Updated] (MESOS-5228) Add tests for Capability API.

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-5228:
-
Sprint: Mesosphere Sprint 33, Mesosphere Sprint 34, Mesosphere Sprint 35  
(was: Mesosphere Sprint 33, Mesosphere Sprint 34, Mesosphere Sprint 35, 
Mesosphere Sprint 36)

> Add tests for Capability API.
> -
>
> Key: MESOS-5228
> URL: https://issues.apache.org/jira/browse/MESOS-5228
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Jojy Varghese
>Assignee: Jojy Varghese
>  Labels: mesosphere, unified-containerizer-mvp
>
> Add basic tests for the capability API.



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

[jira] [Updated] (MESOS-5303) Add capabilities support for mesos execute cli.

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-5303:
-
Sprint: Mesosphere Sprint 34, Mesosphere Sprint 35  (was: Mesosphere Sprint 
34, Mesosphere Sprint 35, Mesosphere Sprint 36)

> Add capabilities support for mesos execute cli.
> ---
>
> Key: MESOS-5303
> URL: https://issues.apache.org/jira/browse/MESOS-5303
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization
>Reporter: Jojy Varghese
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> Add support for `user` and `capabilities` to execute cli. This will help in 
> testing the `capabilities` feature for unified containerizer.



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

[jira] [Updated] (MESOS-5392) Design doc for adding resource limits support for Mesos containerizer

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-5392:
-
Sprint: Mesosphere Sprint 35  (was: Mesosphere Sprint 35, Mesosphere Sprint 
36)

> Design doc for adding resource limits support for Mesos containerizer
> -
>
> Key: MESOS-5392
> URL: https://issues.apache.org/jira/browse/MESOS-5392
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Jojy Varghese
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> This will be the design doc for MESOS-5391.



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

[jira] [Updated] (MESOS-5051) Create helpers for manipulating Linux capabilities.

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-5051:
-
Sprint: Mesosphere Sprint 32, Mesosphere Sprint 33, Mesosphere Sprint 34, 
Mesosphere Sprint 35  (was: Mesosphere Sprint 32, Mesosphere Sprint 33, 
Mesosphere Sprint 34, Mesosphere Sprint 35, Mesosphere Sprint 36)

> Create helpers for manipulating Linux capabilities.
> ---
>
> Key: MESOS-5051
> URL: https://issues.apache.org/jira/browse/MESOS-5051
> Project: Mesos
>  Issue Type: Task
>Reporter: Jie Yu
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> These helpers can either based on some existing library (e.g. libcap), or use 
> system calls directly.



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

[jira] [Updated] (MESOS-5051) Create helpers for manipulating Linux capabilities.

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-5051:
-
Sprint: Mesosphere Sprint 32, Mesosphere Sprint 33, Mesosphere Sprint 34, 
Mesosphere Sprint 35, Mesosphere Sprint 37  (was: Mesosphere Sprint 32, 
Mesosphere Sprint 33, Mesosphere Sprint 34, Mesosphere Sprint 35)

> Create helpers for manipulating Linux capabilities.
> ---
>
> Key: MESOS-5051
> URL: https://issues.apache.org/jira/browse/MESOS-5051
> Project: Mesos
>  Issue Type: Task
>Reporter: Jie Yu
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> These helpers can either based on some existing library (e.g. libcap), or use 
> system calls directly.



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

[jira] [Updated] (MESOS-5303) Add capabilities support for mesos execute cli.

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-5303:
-
Sprint: Mesosphere Sprint 34, Mesosphere Sprint 35, Mesosphere Sprint 37  
(was: Mesosphere Sprint 34, Mesosphere Sprint 35)

> Add capabilities support for mesos execute cli.
> ---
>
> Key: MESOS-5303
> URL: https://issues.apache.org/jira/browse/MESOS-5303
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization
>Reporter: Jojy Varghese
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> Add support for `user` and `capabilities` to execute cli. This will help in 
> testing the `capabilities` feature for unified containerizer.



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

[jira] [Updated] (MESOS-5570) Improve CHANGELOG and upgrades.md

[Joerg Schad (JIRA)]

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

Joerg Schad updated MESOS-5570:
---
Sprint: Mesosphere Sprint 37

> Improve CHANGELOG and upgrades.md
> -
>
> Key: MESOS-5570
> URL: https://issues.apache.org/jira/browse/MESOS-5570
> Project: Mesos
>  Issue Type: Documentation
>Reporter: Joerg Schad
>Assignee: Joerg Schad
> Fix For: 1.0.0
>
>
> Currently we have a lot of data duplication between the CHANGELOG and 
> upgrades.md. We should try to improve this and potentially make the CHANGLOG 
> a markdown file as well. For inspiration see the Hadoop changelog: 
> https://github.com/apache/hadoop/blob/2e1d0ff4e901b8313c8d71869735b94ed8bc40a0/hadoop-common-project/hadoop-common/src/site/markdown/release/1.2.0/CHANGES.1.2.0.md



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

[jira] [Updated] (MESOS-5583) Improve authorization documentation when setting permissive flag.

[Joerg Schad (JIRA)]

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

Joerg Schad updated MESOS-5583:
---
Sprint: Mesosphere Sprint 37

> Improve authorization documentation when setting permissive flag.
> -
>
> Key: MESOS-5583
> URL: https://issues.apache.org/jira/browse/MESOS-5583
> Project: Mesos
>  Issue Type: Documentation
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> A common problem for a users starting to use acls is that once they set 
> `permisse = false` and not add acls allowing common operations (e.g., 
> register_framework) their Mesos cluster don't
> behave as expected. 



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

[jira] [Commented] (MESOS-5535) Add usage examples to persistent volume docs

[Gianluca (JIRA)]

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

Gianluca commented on MESOS-5535:
-

A possible use case:

Two disk, of type MOUNT, in role (*):
- /mnt/volume0 -> mounted to ssd disk, small and fast disk
- /mnt/volume1 -> mounted to big and slow disk

Two frameworks:
- frameworkA to use /mnt/volume0 (eg. kafka)
- frameworkB to use /mnt/volume1 (eg. elasticsearch)

Explain how to constrain FrameworkA to use disk /mnt/volume0 with dynamic 
reservation

> Add usage examples to persistent volume docs
> 
>
> Key: MESOS-5535
> URL: https://issues.apache.org/jira/browse/MESOS-5535
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Reporter: Neil Conway
>  Labels: documentation, mesosphere, persistent-volumes
>
> In particular, we should document how to use persistent volumes with docker 
> containers.



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

[jira] [Updated] (MESOS-5537) http v1 SUBSCRIBED scheduler event always has nil http_interval_seconds

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar updated MESOS-5537:
--
Shepherd: Vinod Kone

> http v1 SUBSCRIBED scheduler event always has nil http_interval_seconds
> ---
>
> Key: MESOS-5537
> URL: https://issues.apache.org/jira/browse/MESOS-5537
> Project: Mesos
>  Issue Type: Bug
>Reporter: James DeFelice
>Assignee: Anand Mazumdar
>Priority: Blocker
>  Labels: mesosphere
> Fix For: 1.0.0
>
>
> I'm writing a controller in Go to monitor heartbeats. I'd like to use the 
> interval as communicated by the master, which should be specified in the 
> SUBSCRIBED event. But it's not.
> {code}
> 2016/06/03 18:34:04 {Type:SUBSCRIBED 
> Subscribed:_Subscribed{FrameworkID:{Value:ffdb6d6e-0167-4fa2-98f9-2c3f8157fc25-0004,},HeartbeatIntervalSeconds:nil,}
>  Offers:nil Rescind:nil Update:nil Message:nil Failure:nil Error:nil}
> {code}
> {code}
> $ dpkg -l |grep -e mesos
> ii  mesos   0.28.0-2.0.16.ubuntu1404 
> amd64Cluster resource manager with efficient resource isolation
> {code}
> I *am* seeing HEARTBEAT events. Just not seeing the interval specified in the 
> SUBSCRIBED event.



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

[jira] [Updated] (MESOS-5583) Improve authorization documentation when setting permissive flag.

[Joerg Schad (JIRA)]

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

Joerg Schad updated MESOS-5583:
---
   Shepherd: Adam B
Description: 
A common problem for a users starting to use acls is that once they set 
`permisse = false` and not add acls allowing common operations (e.g., 
register_framework) their Mesos cluster don't
behave as expected. 

  was:
A common problem for a users starting to use acls is that once they set 
`permisse = false` and
not add acls allowing common operations (e.g., register_framework) their Mesos 
cluster don't
behave as expected. 


> Improve authorization documentation when setting permissive flag.
> -
>
> Key: MESOS-5583
> URL: https://issues.apache.org/jira/browse/MESOS-5583
> Project: Mesos
>  Issue Type: Documentation
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> A common problem for a users starting to use acls is that once they set 
> `permisse = false` and not add acls allowing common operations (e.g., 
> register_framework) their Mesos cluster don't
> behave as expected. 



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

[jira] [Updated] (MESOS-5583) Improve authorization documentation when setting permissive flag.

[Joerg Schad (JIRA)]

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

Joerg Schad updated MESOS-5583:
---
Description: 
A common problem for a users starting to use acls is that once they set 
`permisse = false` and
not add acls allowing common operations (e.g., register_framework) their Mesos 
cluster don't
behave as expected. 

  was:
A common problem for a users starting to use
acls is that once they set `permisse = false` and
not add acls allowing common operations (e.g.,
register_framework) their Mesos cluster don't
behave as expected. 


> Improve authorization documentation when setting permissive flag.
> -
>
> Key: MESOS-5583
> URL: https://issues.apache.org/jira/browse/MESOS-5583
> Project: Mesos
>  Issue Type: Documentation
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> A common problem for a users starting to use acls is that once they set 
> `permisse = false` and
> not add acls allowing common operations (e.g., register_framework) their 
> Mesos cluster don't
> behave as expected. 



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

[jira] [Commented] (MESOS-5574) Missing dependency on libdl

[Kevin Klues (JIRA)]

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

Kevin Klues commented on MESOS-5574:


I don't think so. None of that has landed yet. The modules use this as well, so 
I thought there should already be a dependency on it (at least when building 
with module support).

> Missing dependency on libdl
> ---
>
> Key: MESOS-5574
> URL: https://issues.apache.org/jira/browse/MESOS-5574
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 1.0.0
> Environment: CentOS5, devtoolset-2, gcc version 4.8.2 20140120 (Red 
> Hat 4.8.2-15) (GCC)
>Reporter: Ian Downes
>
> {noformat}
> $ make
> ...
> Making all in src
> make[1]: Entering directory `/home/idownes/workspace/mesos/build/src'
> make  all-am
> make[2]: Entering directory `/home/idownes/workspace/mesos/build/src'
> /bin/sh ../libtool --tag=CXX   --mode=link g++ -pthread -g1 -O0 
> -Wno-unused-local-typedefs -std=c++11 -Wl,--as-needed  -o mesos-local 
> local/mesos_local-main.o libmesos.la  -lz -lsvn_delta-1 -lsvn_subr-1 
> -lsasl2 -lcurl -lapr-1 -lz  -lrt
> libtool: link: g++ -pthread -g1 -O0 -Wno-unused-local-typedefs -std=c++11 
> -Wl,--as-needed -o .libs/mesos-local local/mesos_local-main.o  
> ./.libs/libmesos.so /usr/lib64/libsvn_delta-1.so /usr/lib64/libsvn_subr-1.so 
> /usr/lib64/libaprutil-1.so -lcrypt -lexpat -ldb-4.7 -lsasl2 -lcurl 
> /usr/lib64/libapr-1.so -lpthread -lz -lrt -pthread -Wl,-rpath -Wl,/usr/lib64
> ./.libs/libmesos.so: error: undefined reference to 'dlopen'
> ./.libs/libmesos.so: error: undefined reference to 'dlerror'
> ./.libs/libmesos.so: error: undefined reference to 'dlclose'
> ./.libs/libmesos.so: error: undefined reference to 'dlsym'
> collect2: error: ld returned 1 exit status
> make[2]: *** [mesos-local] Error 1
> make[2]: Leaving directory `/home/idownes/workspace/mesos/build/src'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/idownes/workspace/mesos/build/src'
> make: *** [all-recursive] Error 1
> {noformat}
> Builds correctly when libdl inclusion is forced:
> {noformat}
> $ LDFLAGS='-ldl' ../configure
> {noformat}



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

[jira] [Updated] (MESOS-5537) http v1 SUBSCRIBED scheduler event always has nil http_interval_seconds

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar updated MESOS-5537:
--
  Sprint: Mesosphere Sprint 36
Story Points: 1

> http v1 SUBSCRIBED scheduler event always has nil http_interval_seconds
> ---
>
> Key: MESOS-5537
> URL: https://issues.apache.org/jira/browse/MESOS-5537
> Project: Mesos
>  Issue Type: Bug
>Reporter: James DeFelice
>Assignee: Anand Mazumdar
>Priority: Blocker
>  Labels: mesosphere
> Fix For: 1.0.0
>
>
> I'm writing a controller in Go to monitor heartbeats. I'd like to use the 
> interval as communicated by the master, which should be specified in the 
> SUBSCRIBED event. But it's not.
> {code}
> 2016/06/03 18:34:04 {Type:SUBSCRIBED 
> Subscribed:_Subscribed{FrameworkID:{Value:ffdb6d6e-0167-4fa2-98f9-2c3f8157fc25-0004,},HeartbeatIntervalSeconds:nil,}
>  Offers:nil Rescind:nil Update:nil Message:nil Failure:nil Error:nil}
> {code}
> {code}
> $ dpkg -l |grep -e mesos
> ii  mesos   0.28.0-2.0.16.ubuntu1404 
> amd64Cluster resource manager with efficient resource isolation
> {code}
> I *am* seeing HEARTBEAT events. Just not seeing the interval specified in the 
> SUBSCRIBED event.



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

[jira] [Created] (MESOS-5583) Improve authorization documentation when setting permissive flag.

[Joerg Schad (JIRA)]

Joerg Schad created MESOS-5583:
--

 Summary: Improve authorization documentation when setting 
permissive flag.
 Key: MESOS-5583
 URL: https://issues.apache.org/jira/browse/MESOS-5583
 Project: Mesos
  Issue Type: Documentation
Reporter: Joerg Schad
Assignee: Joerg Schad


A common problem for a users starting to use
acls is that once they set `permisse = false` and
not add acls allowing common operations (e.g.,
register_framework) their Mesos cluster don't
behave as expected. 



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

[jira] [Commented] (MESOS-5574) Missing dependency on libdl

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-5574:
---

[~klueska] is this due to your recent changes?

> Missing dependency on libdl
> ---
>
> Key: MESOS-5574
> URL: https://issues.apache.org/jira/browse/MESOS-5574
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 1.0.0
> Environment: CentOS5, devtoolset-2, gcc version 4.8.2 20140120 (Red 
> Hat 4.8.2-15) (GCC)
>Reporter: Ian Downes
>
> {noformat}
> $ make
> ...
> Making all in src
> make[1]: Entering directory `/home/idownes/workspace/mesos/build/src'
> make  all-am
> make[2]: Entering directory `/home/idownes/workspace/mesos/build/src'
> /bin/sh ../libtool --tag=CXX   --mode=link g++ -pthread -g1 -O0 
> -Wno-unused-local-typedefs -std=c++11 -Wl,--as-needed  -o mesos-local 
> local/mesos_local-main.o libmesos.la  -lz -lsvn_delta-1 -lsvn_subr-1 
> -lsasl2 -lcurl -lapr-1 -lz  -lrt
> libtool: link: g++ -pthread -g1 -O0 -Wno-unused-local-typedefs -std=c++11 
> -Wl,--as-needed -o .libs/mesos-local local/mesos_local-main.o  
> ./.libs/libmesos.so /usr/lib64/libsvn_delta-1.so /usr/lib64/libsvn_subr-1.so 
> /usr/lib64/libaprutil-1.so -lcrypt -lexpat -ldb-4.7 -lsasl2 -lcurl 
> /usr/lib64/libapr-1.so -lpthread -lz -lrt -pthread -Wl,-rpath -Wl,/usr/lib64
> ./.libs/libmesos.so: error: undefined reference to 'dlopen'
> ./.libs/libmesos.so: error: undefined reference to 'dlerror'
> ./.libs/libmesos.so: error: undefined reference to 'dlclose'
> ./.libs/libmesos.so: error: undefined reference to 'dlsym'
> collect2: error: ld returned 1 exit status
> make[2]: *** [mesos-local] Error 1
> make[2]: Leaving directory `/home/idownes/workspace/mesos/build/src'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/idownes/workspace/mesos/build/src'
> make: *** [all-recursive] Error 1
> {noformat}
> Builds correctly when libdl inclusion is forced:
> {noformat}
> $ LDFLAGS='-ldl' ../configure
> {noformat}



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

[jira] [Commented] (MESOS-5547) Implement TASK_LOST_PENDING

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-5547:
---

Preliminary cleanups:

commit 7036548b9e5d25e32f1a3c573208aea7cdd0e464
Author: Neil Conway 
Date:   Thu Jun 9 10:44:07 2016 -0400

Parameterized partition tests with registry "strictness".

We should test that the same partition behavior is implemented
for both strict and non-strict registry configurations. A few
of the partition tests don't depend on registry strictness,
so move them to a separate test class to avoid needlessly
running them twice.

Review: https://reviews.apache.org/r/48344/

commit 623609bc5b0996d309b02fcc405ef101cf180136
Author: Neil Conway 
Date:   Thu Jun 9 10:44:02 2016 -0400

Added checks for `reason` field to task reconciliation tests.

This merits testing, because it is a significant part of the
task reconciliation interface.

Review: https://reviews.apache.org/r/48342/

commit 00cb1f4afb6470f53c8d37b54e311cfca531ba2a
Author: Neil Conway 
Date:   Thu Jun 9 10:43:57 2016 -0400

Cleaned up task state reconciliation tests.

Document that when doing task state reconciliation, the
`state` field in the input TaskStatus should be set to a
dummy value that will be ignored by Mesos.

Along the way, make use of C++11 initializer lists.

Review: https://reviews.apache.org/r/48250/

commit dc63f7db60093bbbcc6c9623ffce20cda8093049
Author: Neil Conway 
Date:   Thu Jun 9 10:43:52 2016 -0400

Checked metrics after slave removal in partition tests.

Review: https://reviews.apache.org/r/48249/

commit da465670405a9ece995b52cbf0110423c1e6b2a2
Author: Neil Conway 
Date:   Thu Jun 9 10:43:40 2016 -0400

Fixed typos in comments and log messages.

Review: https://reviews.apache.org/r/48248/


> Implement TASK_LOST_PENDING
> ---
>
> Key: MESOS-5547
> URL: https://issues.apache.org/jira/browse/MESOS-5547
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Neil Conway
>Assignee: Neil Conway
>  Labels: mesosphere
>




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

[jira] [Commented] (MESOS-2216) The "configure" phase breaks with the IBM JVM.

[Nirav (JIRA)]

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

Nirav commented on MESOS-2216:
--

I was facing similar issue on s390x, with IBM-JDK, while building Mesos.I tried 
the patch MESOS-2216_2.patch, and it works for me.
Are there any updates on supporting IBM-JDK ?


> The "configure" phase breaks with the IBM JVM.
> --
>
> Key: MESOS-2216
> URL: https://issues.apache.org/jira/browse/MESOS-2216
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.20.1, 1.0.0
> Environment: Ubuntu / x86_64
>Reporter: Tony Reix
>Assignee: Jihun Kang
> Attachments: MESOS-2216_1.patch, MESOS-2216_2.patch, config.log, 
> jniport.h, x86_64_traces
>
>
> ./configure does not work with IBM JVM, since it looks for a directory:
>/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server   x86_64
>/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE
> that does not exist for the IBM JVM.
> Though this directory does exist for Oracle JVM and Open JDK:
>/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server  Oracle JVM
>/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK
> However, the files:
>   libjsig.so
>   libjvm.so   (3 versions)
> do exist for IBM JVM.
> Anyway, creating the server directory and copying the files (tried with the 3 
> versions of libjvm.so) does not fix the issue:
> checking whether or not we can build with JNI... 
> /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined 
> reference to `dlopen'
> /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined 
> reference to `dlclose'
> /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined 
> reference to `dlerror'
> /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined 
> reference to `dlsym'
> /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined 
> reference to `dladdr'
> Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM.
> So, either the configure step relies on a feature that is not in the Java 
> standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of 
> the Java standard.
> I'm not an expert about this. So, I'd like Mesos people to experiment with 
> IBM JVM. Maybe there is another solution for this step of the Mesos configure 
> that would work with all 3 JVMs.



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

[jira] [Created] (MESOS-5582) Create a `cgroups/devices` isolator.

[Kevin Klues (JIRA)]

Kevin Klues created MESOS-5582:
--

 Summary: Create a `cgroups/devices` isolator.
 Key: MESOS-5582
 URL: https://issues.apache.org/jira/browse/MESOS-5582
 Project: Mesos
  Issue Type: Improvement
Reporter: Kevin Klues
Assignee: Kevin Klues


Currently, all the logic for the `cgroups/devices` isolator is bundled into the 
Nvidia GPU Isolator. We should abstract it out into it's own component and 
remove the redundant logic from the Nvidia GPU Isolator. Assuming the 
guaranteed ordering between isolators from MESOS-5581, we can be sure that the 
dependency order between the `cgroups/devices` and `gpu/nvidia` isolators is 
met.



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