date:20160517


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

Till Toenshoff commented on MESOS-5405:
---

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

> Make fields in authorization::Request protobuf optional.
> 
>
> Key: MESOS-5405
> URL: https://issues.apache.org/jira/browse/MESOS-5405
> Project: Mesos
>  Issue Type: Bug
>Reporter: Alexander Rukletsov
>Assignee: Till Toenshoff
>Priority: Blocker
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> Currently {{authorization::Request}} protobuf declares {{subject}} and 
> {{object}} as required fields. However, in the codebase we not always set 
> them, which renders the message in the uninitialized state, for example:
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/common/http.cpp#L603
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/master/http.cpp#L2057
> I believe that the reason why we don't see issues related to this is because 
> we never send authz requests over the wire, i.e., never serialize/deserialize 
> them. However, they are still invalid protobuf messages. Moreover, some 
> external authorizers may serialize these messages.
> We can either ensure all required fields are set or make both {{subject}} and 
> {{object}} fields optional. This will also require updating local authorizer, 
> which should properly handle the situation when these fields are absent. We 
> may also want to notify authors of external authorizers to update their code 
> accordingly.
> It looks like no deprecation is necessary, mainly because we 
> already—erroneously!—treat these fields as optional.



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

[jira] [Created] (MESOS-5410) Support cgroup namespace in unified container

2016-05-17 Thread Qian Zhang (JIRA)

Qian Zhang created MESOS-5410:
-

 Summary: Support cgroup namespace in unified container
 Key: MESOS-5410
 URL: https://issues.apache.org/jira/browse/MESOS-5410
 Project: Mesos
  Issue Type: Improvement
Reporter: Qian Zhang
Assignee: Qian Zhang


In Linux 4.6 kernel, a new namespace (cgroup namespace) was introduced to make 
a process can be created in its own cgroup namespace so that the global cgroup 
hierarchy will not be leaked to the process. See the following link for more 
details about this namespace:
http://man7.org/linux/man-pages/man7/cgroup_namespaces.7.html

We need to support this namespace in unified container to provide better 
isolation for the containers created by Mesos.



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

[jira] [Commented] (MESOS-5405) Make fields in authorization::Request protobuf optional.


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

Till Toenshoff commented on MESOS-5405:
---

Got a fix for the second variant at hand - reviewboard currently down - will 
upload ASAP.

Need a shepherd.

> Make fields in authorization::Request protobuf optional.
> 
>
> Key: MESOS-5405
> URL: https://issues.apache.org/jira/browse/MESOS-5405
> Project: Mesos
>  Issue Type: Bug
>Reporter: Alexander Rukletsov
>Assignee: Till Toenshoff
>Priority: Blocker
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> Currently {{authorization::Request}} protobuf declares {{subject}} and 
> {{object}} as required fields. However, in the codebase we not always set 
> them, which renders the message in the uninitialized state, for example:
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/common/http.cpp#L603
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/master/http.cpp#L2057
> I believe that the reason why we don't see issues related to this is because 
> we never send authz requests over the wire, i.e., never serialize/deserialize 
> them. However, they are still invalid protobuf messages. Moreover, some 
> external authorizers may serialize these messages.
> We can either ensure all required fields are set or make both {{subject}} and 
> {{object}} fields optional. This will also require updating local authorizer, 
> which should properly handle the situation when these fields are absent. We 
> may also want to notify authors of external authorizers to update their code 
> accordingly.
> It looks like no deprecation is necessary, mainly because we 
> already—erroneously!—treat these fields as optional.



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

[jira] [Comment Edited] (MESOS-5405) Make fields in authorization::Request protobuf optional.


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

Till Toenshoff edited comment on MESOS-5405 at 5/18/16 1:36 AM:


While my above approach would fix things, it would have a deep impact on the 
conceptual design of the authorizer. It would also make us lose the ability to 
add alternative {{value}} types - e.g. having a union styled {{object}}.

As an alternative, we could do the following:

1. fix all of those missing {{subject}} / {{object}} initializings. 
2. {{CHECK(request->has_subject())}} and {{CHECK(request->has_object())}} to 
{{authorizer:: authorized}} to make sure people do not fall into that trap 
anymore. 


was (Author: tillt):
While my above approach would fix things, it would have a deep impact on the 
conceptual design of the authorizer. It would also make us lose the ability to 
add alternative {{value}} types - e.g. having a union styled {{object}}.

As an alternative, we could do the following:

1. fix all of those missing {{subject}} / {{object}} initializings. 
2. {{CHECK(request->has_subject())}} and {{CHECK(request->has_object())}} to 
all {{authorizer:: authorized}} overloads to make sure people do not fall into 
that trap anymore. 

> Make fields in authorization::Request protobuf optional.
> 
>
> Key: MESOS-5405
> URL: https://issues.apache.org/jira/browse/MESOS-5405
> Project: Mesos
>  Issue Type: Bug
>Reporter: Alexander Rukletsov
>Assignee: Till Toenshoff
>Priority: Blocker
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> Currently {{authorization::Request}} protobuf declares {{subject}} and 
> {{object}} as required fields. However, in the codebase we not always set 
> them, which renders the message in the uninitialized state, for example:
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/common/http.cpp#L603
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/master/http.cpp#L2057
> I believe that the reason why we don't see issues related to this is because 
> we never send authz requests over the wire, i.e., never serialize/deserialize 
> them. However, they are still invalid protobuf messages. Moreover, some 
> external authorizers may serialize these messages.
> We can either ensure all required fields are set or make both {{subject}} and 
> {{object}} fields optional. This will also require updating local authorizer, 
> which should properly handle the situation when these fields are absent. We 
> may also want to notify authors of external authorizers to update their code 
> accordingly.
> It looks like no deprecation is necessary, mainly because we 
> already—erroneously!—treat these fields as optional.



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

[jira] [Created] (MESOS-5408) Delete the /observe HTTP endpoint

Vinod Kone created MESOS-5408:
-

 Summary: Delete the /observe HTTP endpoint
 Key: MESOS-5408
 URL: https://issues.apache.org/jira/browse/MESOS-5408
 Project: Mesos
  Issue Type: Bug
Reporter: Vinod Kone


The "/observe" endpoint was introduced a long time ago for supporting 
functionality that was never implemented. We should just kill this endpoint and 
associated code to avoid tech debt.



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

[jira] [Commented] (MESOS-5405) Make fields in authorization::Request protobuf optional.


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

Vinod Kone commented on MESOS-5405:
---

Fixing the call sites sgtm.

> Make fields in authorization::Request protobuf optional.
> 
>
> Key: MESOS-5405
> URL: https://issues.apache.org/jira/browse/MESOS-5405
> Project: Mesos
>  Issue Type: Bug
>Reporter: Alexander Rukletsov
>Assignee: Till Toenshoff
>Priority: Blocker
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> Currently {{authorization::Request}} protobuf declares {{subject}} and 
> {{object}} as required fields. However, in the codebase we not always set 
> them, which renders the message in the uninitialized state, for example:
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/common/http.cpp#L603
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/master/http.cpp#L2057
> I believe that the reason why we don't see issues related to this is because 
> we never send authz requests over the wire, i.e., never serialize/deserialize 
> them. However, they are still invalid protobuf messages. Moreover, some 
> external authorizers may serialize these messages.
> We can either ensure all required fields are set or make both {{subject}} and 
> {{object}} fields optional. This will also require updating local authorizer, 
> which should properly handle the situation when these fields are absent. We 
> may also want to notify authors of external authorizers to update their code 
> accordingly.
> It looks like no deprecation is necessary, mainly because we 
> already—erroneously!—treat these fields as optional.



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

[jira] [Commented] (MESOS-5405) Make fields in authorization::Request protobuf optional.


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

Till Toenshoff commented on MESOS-5405:
---

While my above approach would fix things, it would have a deep impact on the 
conceptual design of the authorizer. It would also make us lose the ability to 
add alternative {{value}} types - e.g. having a union styled {{object}}.

As an alternative, we could do the following:

1. fix all of those missing {{subject}} / {{object}} initializings. 
2. {{CHECK(request->has_subject())}} and {{CHECK(request->has_object())}} to 
all {{authorizer:: authorized}} overloads to make sure people do not fall into 
that trap anymore. 

> Make fields in authorization::Request protobuf optional.
> 
>
> Key: MESOS-5405
> URL: https://issues.apache.org/jira/browse/MESOS-5405
> Project: Mesos
>  Issue Type: Bug
>Reporter: Alexander Rukletsov
>Assignee: Till Toenshoff
>Priority: Blocker
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> Currently {{authorization::Request}} protobuf declares {{subject}} and 
> {{object}} as required fields. However, in the codebase we not always set 
> them, which renders the message in the uninitialized state, for example:
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/common/http.cpp#L603
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/master/http.cpp#L2057
> I believe that the reason why we don't see issues related to this is because 
> we never send authz requests over the wire, i.e., never serialize/deserialize 
> them. However, they are still invalid protobuf messages. Moreover, some 
> external authorizers may serialize these messages.
> We can either ensure all required fields are set or make both {{subject}} and 
> {{object}} fields optional. This will also require updating local authorizer, 
> which should properly handle the situation when these fields are absent. We 
> may also want to notify authors of external authorizers to update their code 
> accordingly.
> It looks like no deprecation is necessary, mainly because we 
> already—erroneously!—treat these fields as optional.



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

[jira] [Updated] (MESOS-3011) Publish release documentation for major releases on website


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

Vinod Kone updated MESOS-3011:
--
Assignee: Tim Anderegg  (was: Joerg Schad)

[~js84] I'm assigning this to Tim as he is interested in working on it now and 
I know you are busy with other stuff for Mesoscon. 

> Publish release documentation for major releases on website
> ---
>
> Key: MESOS-3011
> URL: https://issues.apache.org/jira/browse/MESOS-3011
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation, project website
>Reporter: Paul Brett
>Assignee: Tim Anderegg
>  Labels: documentation, mesosphere
>
> Currently, the website only provides a single version of the documentation.  
> We should publish documentation for each release on the website independently 
> (for example as https://mesos.apache.org/documentation/0.22/index.html, 
> https://mesos.apache.org/documentation/0.23/index.html) and make latest 
> redirect to the current version.



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

[jira] [Commented] (MESOS-5407) Slave/Agent rename: diagrams in docs


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

Vinod Kone commented on MESOS-5407:
---

The images are in "docs/images" directory. I guess you are asking for .svg or 
such format of the images? Not sure who has them, maybe [~benjaminhindman]?

Is it possible to update the png/jpg images directly though?



> Slave/Agent rename: diagrams in docs
> 
>
> Key: MESOS-5407
> URL: https://issues.apache.org/jira/browse/MESOS-5407
> Project: Mesos
>  Issue Type: Bug
>  Components: documentation
>Reporter: Jay Guo
>Priority: Minor
>
> Rename 'slave' in diagrams



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

[jira] [Commented] (MESOS-3781) Replace Master/Slave Terminology Phase I - Rename flag names and deprecate old ones


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

Jay Guo commented on MESOS-3781:


here we go: https://reviews.apache.org/r/47507/

> Replace Master/Slave Terminology Phase I - Rename flag names and deprecate 
> old ones
> ---
>
> Key: MESOS-3781
> URL: https://issues.apache.org/jira/browse/MESOS-3781
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: Jay Guo
>




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

[jira] [Commented] (MESOS-3781) Replace Master/Slave Terminology Phase I - Rename flag names and deprecate old ones


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

Jay Guo commented on MESOS-3781:


here we go: https://reviews.apache.org/r/47507/

> Replace Master/Slave Terminology Phase I - Rename flag names and deprecate 
> old ones
> ---
>
> Key: MESOS-3781
> URL: https://issues.apache.org/jira/browse/MESOS-3781
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: Jay Guo
>




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

[jira] [Issue Comment Deleted] (MESOS-3781) Replace Master/Slave Terminology Phase I - Rename flag names and deprecate old ones


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

Jay Guo updated MESOS-3781:
---
Comment: was deleted

(was: here we go: https://reviews.apache.org/r/47507/)

> Replace Master/Slave Terminology Phase I - Rename flag names and deprecate 
> old ones
> ---
>
> Key: MESOS-3781
> URL: https://issues.apache.org/jira/browse/MESOS-3781
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: Jay Guo
>




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

[jira] [Updated] (MESOS-3781) Replace Master/Slave Terminology Phase I - Rename flag names and deprecate old ones


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

Jay Guo updated MESOS-3781:
---
Summary: Replace Master/Slave Terminology Phase I - Rename flag names and 
deprecate old ones  (was: Replace Master/Slave Terminology Phase I - Add 
duplicate agent flags )

> Replace Master/Slave Terminology Phase I - Rename flag names and deprecate 
> old ones
> ---
>
> Key: MESOS-3781
> URL: https://issues.apache.org/jira/browse/MESOS-3781
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: Jay Guo
>




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

[jira] [Commented] (MESOS-5407) Slave/Agent rename: diagrams in docs


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

Jay Guo commented on MESOS-5407:


[~vinodkone] who should we talk to in order to get the original file of these 
images?

> Slave/Agent rename: diagrams in docs
> 
>
> Key: MESOS-5407
> URL: https://issues.apache.org/jira/browse/MESOS-5407
> Project: Mesos
>  Issue Type: Bug
>  Components: documentation
>Reporter: Jay Guo
>Priority: Minor
>
> Rename 'slave' in diagrams



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

[jira] [Created] (MESOS-5407) Slave/Agent rename: diagrams in docs

Jay Guo created MESOS-5407:
--

 Summary: Slave/Agent rename: diagrams in docs
 Key: MESOS-5407
 URL: https://issues.apache.org/jira/browse/MESOS-5407
 Project: Mesos
  Issue Type: Bug
  Components: documentation
Reporter: Jay Guo
Priority: Minor


Rename 'slave' in diagrams



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

[jira] [Commented] (MESOS-3690) Make Apache Mesos' website mobile friendly

2016-05-17 Thread ASF GitHub Bot (JIRA)


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

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

Github user haosdent commented on the pull request:

https://github.com/apache/mesos/pull/75#issuecomment-219896230
  
@fayusohenson Are you still working on this? May you post it in 
reviewboard? https://reviews.apache.org/groups/mesos/


> Make Apache Mesos' website mobile friendly
> --
>
> Key: MESOS-3690
> URL: https://issues.apache.org/jira/browse/MESOS-3690
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Freddy Ayuso-Henson
>Priority: Minor
>
> Changes to the project website:
> - Support smaller screens/devices (mobile)
> - Limit images' max width when displayed
> - Update Bootstrap version
> - Other smaller changes



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

[jira] [Commented] (MESOS-5402) Mesos site does not render properly on small screens

2016-05-17 Thread haosdent (JIRA)


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

haosdent commented on MESOS-5402:
-

Seems https://issues.apache.org/jira/browse/MESOS-3690 change more completely. 
It refactor the navbar and make the document mobile friendly as well not only 
the home page.  

> Mesos site does not render properly on small screens
> 
>
> Key: MESOS-5402
> URL: https://issues.apache.org/jira/browse/MESOS-5402
> Project: Mesos
>  Issue Type: Bug
>  Components: project website
> Environment: mobile
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>Priority: Trivial
>  Labels: documentation
>
> Text on http://mesos.apache.org/ is not wrapped on small screens (mobile).



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

[jira] [Updated] (MESOS-3690) Make Apache Mesos' website mobile friendly

2016-05-17 Thread haosdent (JIRA)


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

haosdent updated MESOS-3690:

Summary: Make Apache Mesos' website mobile friendly  (was: Changes to 
Apache Mesos' website)

> Make Apache Mesos' website mobile friendly
> --
>
> Key: MESOS-3690
> URL: https://issues.apache.org/jira/browse/MESOS-3690
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Freddy Ayuso-Henson
>Priority: Minor
>
> Changes to the project website:
> - Support smaller screens/devices (mobile)
> - Limit images' max width when displayed
> - Update Bootstrap version
> - Other smaller changes



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

[jira] [Assigned] (MESOS-1495) Create separate local data file to manage releases

2016-05-17 Thread haosdent (JIRA)


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

haosdent reassigned MESOS-1495:
---

Assignee: haosdent

> Create separate local data file to manage releases
> --
>
> Key: MESOS-1495
> URL: https://issues.apache.org/jira/browse/MESOS-1495
> Project: Mesos
>  Issue Type: Bug
>  Components: project website
>Reporter: Dave Lester
>Assignee: haosdent
>
> Currently, release info is managed in multiple places on the website. This 
> ticket is to create and manage a local data file which contains a release 
> number, link to release notes, and an optional blog post so that we can 
> dynamically display (incl adding and removing) releases from the website by 
> editing a single file.
> Looks like we can achieve this with Middleman by creating a separate YAML 
> file: http://middlemanapp.com/advanced/local-data/, perhaps /releases.yml?



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

[jira] [Assigned] (MESOS-5405) Make fields in authorization::Request protobuf optional.


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

Till Toenshoff reassigned MESOS-5405:
-

Assignee: Till Toenshoff

> Make fields in authorization::Request protobuf optional.
> 
>
> Key: MESOS-5405
> URL: https://issues.apache.org/jira/browse/MESOS-5405
> Project: Mesos
>  Issue Type: Bug
>Reporter: Alexander Rukletsov
>Assignee: Till Toenshoff
>Priority: Blocker
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> Currently {{authorization::Request}} protobuf declares {{subject}} and 
> {{object}} as required fields. However, in the codebase we not always set 
> them, which renders the message in the uninitialized state, for example:
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/common/http.cpp#L603
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/master/http.cpp#L2057
> I believe that the reason why we don't see issues related to this is because 
> we never send authz requests over the wire, i.e., never serialize/deserialize 
> them. However, they are still invalid protobuf messages. Moreover, some 
> external authorizers may serialize these messages.
> We can either ensure all required fields are set or make both {{subject}} and 
> {{object}} fields optional. This will also require updating local authorizer, 
> which should properly handle the situation when these fields are absent. We 
> may also want to notify authors of external authorizers to update their code 
> accordingly.
> It looks like no deprecation is necessary, mainly because we 
> already—erroneously!—treat these fields as optional.



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

[jira] [Commented] (MESOS-5405) Make fields in authorization::Request protobuf optional.


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

Till Toenshoff commented on MESOS-5405:
---

Seems the correct solution here is to make {{subject}} and {{object}} optional 
within the proto definition.

Keeping them mandatory would e.g. mandate a rather ugly fix for the first 
example:
{noformat}
if (principal.isSome()) {
  authRequest.mutable_subject()->set_value(principal.get());
} else {
  authRequest.mutable_subject();
}
{noformat}
I firmly believe that this is not what we want for expressing {{ANY}} as used 
by our internal representation whenever an empty / missing {{subject}} or 
{{object}} got supplied.

> Make fields in authorization::Request protobuf optional.
> 
>
> Key: MESOS-5405
> URL: https://issues.apache.org/jira/browse/MESOS-5405
> Project: Mesos
>  Issue Type: Bug
>Reporter: Alexander Rukletsov
>Priority: Blocker
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> Currently {{authorization::Request}} protobuf declares {{subject}} and 
> {{object}} as required fields. However, in the codebase we not always set 
> them, which renders the message in the uninitialized state, for example:
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/common/http.cpp#L603
>  * 
> https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/master/http.cpp#L2057
> I believe that the reason why we don't see issues related to this is because 
> we never send authz requests over the wire, i.e., never serialize/deserialize 
> them. However, they are still invalid protobuf messages. Moreover, some 
> external authorizers may serialize these messages.
> We can either ensure all required fields are set or make both {{subject}} and 
> {{object}} fields optional. This will also require updating local authorizer, 
> which should properly handle the situation when these fields are absent. We 
> may also want to notify authors of external authorizers to update their code 
> accordingly.
> It looks like no deprecation is necessary, mainly because we 
> already—erroneously!—treat these fields as optional.



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

[jira] [Updated] (MESOS-5402) Mesos site does not render properly on small screens


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

Vinod Kone updated MESOS-5402:
--
Component/s: project website

> Mesos site does not render properly on small screens
> 
>
> Key: MESOS-5402
> URL: https://issues.apache.org/jira/browse/MESOS-5402
> Project: Mesos
>  Issue Type: Bug
>  Components: project website
> Environment: mobile
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>Priority: Trivial
>  Labels: documentation
>
> Text on http://mesos.apache.org/ is not wrapped on small screens (mobile).



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

[jira] [Updated] (MESOS-5402) Mesos site does not render properly on small screens


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

Vinod Kone updated MESOS-5402:
--
Summary: Mesos site does not render properly on small screens  (was: Mesos 
site is not responsive)

> Mesos site does not render properly on small screens
> 
>
> Key: MESOS-5402
> URL: https://issues.apache.org/jira/browse/MESOS-5402
> Project: Mesos
>  Issue Type: Bug
> Environment: mobile
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>Priority: Trivial
>  Labels: documentation
>
> Text on http://mesos.apache.org/ is not wrapped on small screens (mobile).



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

[jira] [Commented] (MESOS-5402) Mesos site is not responsive

2016-05-17 Thread Tomasz Janiszewski (JIRA)


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

Tomasz Janiszewski commented on MESOS-5402:
---

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

> Mesos site is not responsive
> 
>
> Key: MESOS-5402
> URL: https://issues.apache.org/jira/browse/MESOS-5402
> Project: Mesos
>  Issue Type: Bug
> Environment: mobile
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>Priority: Trivial
>  Labels: documentation
>
> Text on http://mesos.apache.org/ is not wrapped on small screens (mobile).



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

[jira] [Updated] (MESOS-5216) Document docker volume driver isolator.

2016-05-17 Thread Gilbert Song (JIRA)


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

Gilbert Song updated MESOS-5216:

   Sprint: Mesosphere Sprint 35
Affects Version/s: 0.29.0

> Document docker volume driver isolator.
> ---
>
> Key: MESOS-5216
> URL: https://issues.apache.org/jira/browse/MESOS-5216
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization
>Reporter: Gilbert Song
>Assignee: Guangya Liu
>  Labels: documentaion, mesosphere
> Fix For: 0.29.0
>
>
> Should include the followings:
> 1. What features (driver options) are supported in docker volume driver 
> isolator.
> 2. How to use docker volume driver isolator.
> *related agent flags introduction and usage.
> *isolator dependency clarification (e.g., filesystem/linux).
> *related driver daemon preprocess.
> *volumes pre-specified by users and volume cleanup.



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

[jira] [Updated] (MESOS-5216) Document docker volume driver isolator.

2016-05-17 Thread Gilbert Song (JIRA)


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

Gilbert Song updated MESOS-5216:

Assignee: Guangya Liu

> Document docker volume driver isolator.
> ---
>
> Key: MESOS-5216
> URL: https://issues.apache.org/jira/browse/MESOS-5216
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization
>Reporter: Gilbert Song
>Assignee: Guangya Liu
>  Labels: documentaion, mesosphere
>
> Should include the followings:
> 1. What features (driver options) are supported in docker volume driver 
> isolator.
> 2. How to use docker volume driver isolator.
> *related agent flags introduction and usage.
> *isolator dependency clarification (e.g., filesystem/linux).
> *related driver daemon preprocess.
> *volumes pre-specified by users and volume cleanup.



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

[jira] [Created] (MESOS-5406) Validate ACLs on creating an instance of local authorizer.

Alexander Rukletsov created MESOS-5406:
--

 Summary: Validate ACLs on creating an instance of local authorizer.
 Key: MESOS-5406
 URL: https://issues.apache.org/jira/browse/MESOS-5406
 Project: Mesos
  Issue Type: Improvement
Reporter: Alexander Rukletsov


Some combinations of ACLs are not allowed, for example, specifying both 
{{SetQuota}} and {{UpdateQuota}}. We should capture such issues and error out 
early. 

This ticket aims to add as many validations as possible to a dedicated 
{{validate()}} routine, instead of having them implicitly in the codebase.



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

[jira] [Commented] (MESOS-5357) Add a function to extract HTTP endpoints from an URL.

2016-05-17 Thread Adam B (JIRA)


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

Adam B commented on MESOS-5357:
---

cc: [~greggomann]

> Add a function to extract HTTP endpoints from an URL.
> -
>
> Key: MESOS-5357
> URL: https://issues.apache.org/jira/browse/MESOS-5357
> Project: Mesos
>  Issue Type: Improvement
>  Components: libprocess
>Reporter: Jan Schlicht
>Assignee: Jan Schlicht
>  Labels: libprocess, mesosphere, newbie, security
> Fix For: 0.29.0
>
>
> HTTP endpoints in Mesos receive a {{process::http::Request}} that includes a 
> {{process::http::URL}}. The {{path}} member of the URL instance is of the 
> form {{/master/endpoint}} or {{/slave\(n\)/endpoint}}. We want to implement 
> authorization of endpoints and need to extract the endpoint from that path 
> and that function should be accessible for masters as well as agents.
> This can be done by adding a method to {{process::http::URL}} that implements 
> the extraction logic.



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

[jira] [Created] (MESOS-5405) Make fields in authorization::Request protobuf optional.

Alexander Rukletsov created MESOS-5405:
--

Summary: Make fields in authorization::Request protobuf optional.
Key: MESOS-5405
URL: https://issues.apache.org/jira/browse/MESOS-5405
Project: Mesos
Issue Type: Bug
Reporter: Alexander Rukletsov
Priority: Blocker
Fix For: 0.29.0

Currently {{authorization::Request}} protobuf declares {{subject}} and
{{object}} as required fields. However, in the codebase we not always set them,
which renders the message in the uninitialized state, for example:
*
https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/common/http.cpp#L603
*
https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/master/http.cpp#L2057

I believe that the reason why we don't see issues related to this is because we
never send authz requests over the wire, i.e., never serialize/deserialize
them. However, they are still invalid protobuf messages. Moreover, some
external authorizers may serialize these messages.

We can either ensure all required fields are set or make both {{subject}} and
{{object}} fields optional. This will also require updating local authorizer,
which should properly handle the situation when these fields are absent. We may
also want to notify authors of external authorizers to update their code
accordingly.

It looks like no deprecation is necessary, mainly because we
already—erroneously!—treat these fields as optional.

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

[jira] [Created] (MESOS-5404) Allow `Task` to be authorized.

2016-05-17 Thread Joerg Schad (JIRA)

Joerg Schad created MESOS-5404:
--

 Summary: Allow `Task` to be authorized.
 Key: MESOS-5404
 URL: https://issues.apache.org/jira/browse/MESOS-5404
 Project: Mesos
  Issue Type: Improvement
Reporter: Joerg Schad
Assignee: Joerg Schad


As we need to be able to authorize `Tasks` (e.g., for deciding whether to 
include them in the /state endpoint when applying authorization based 
filtering) we need to expose it to the authorizer. Secondly we also need to 
include some additional information (`user` and `Env variables`) in order to 
provide the authorizer  with meaning information.



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

[jira] [Created] (MESOS-5403) Introduce ObjectFilter Interface to Authorizer.

2016-05-17 Thread Joerg Schad (JIRA)

Joerg Schad created MESOS-5403:
--

 Summary: Introduce ObjectFilter Interface to Authorizer.
 Key: MESOS-5403
 URL: https://issues.apache.org/jira/browse/MESOS-5403
 Project: Mesos
  Issue Type: Bug
Reporter: Joerg Schad
Assignee: Joerg Schad


As outlined here 
(https://docs.google.com/document/d/1FuS79P8uj5PIBycrBlkJSBKOtmeO8ezAuiNXxwIA3qA)
 we plan to add the option of retrieving a FilterObject from the Authorizer 
with the goal of allowing for efficient authorization of a large number of 
(potentially large) objects. 



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

[jira] [Created] (MESOS-5402) Mesos site is not responsive

2016-05-17 Thread Tomasz Janiszewski (JIRA)

Tomasz Janiszewski created MESOS-5402:
-

 Summary: Mesos site is not responsive
 Key: MESOS-5402
 URL: https://issues.apache.org/jira/browse/MESOS-5402
 Project: Mesos
  Issue Type: Bug
 Environment: mobile
Reporter: Tomasz Janiszewski
Assignee: Tomasz Janiszewski
Priority: Trivial


Text on http://mesos.apache.org/ is not wrapped on small screens (mobile).



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


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

Alexander Rukletsov updated MESOS-4279:
---
Assignee: Martin Bydzovsky  (was: Qian Zhang)
  Sprint: Mesosphere Sprint 35

> 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: Martin Bydzovsky
>Priority: Blocker
>  Labels: docker, mesosphere
> Fix For: 0.29.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] [Commented] (MESOS-4279) Docker executor truncates task's output when the task is killed.


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

Alexander Rukletsov commented on MESOS-4279:


I've reviewed the std stream review and I'm not convinced we should fix it this 
way. Anyway, I've marked this as a blocker for 0.29 so we do our best to make 
sure both bugs are fixed before the release.

> 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: Qian Zhang
>Priority: Blocker
>  Labels: docker, mesosphere
> Fix For: 0.29.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-5401) Add ability to inject a Volume of Nvidia GPU-related libraries into a docker container.

Kevin Klues created MESOS-5401:
--

 Summary: Add ability to inject a Volume of Nvidia GPU-related 
libraries into a docker container.
 Key: MESOS-5401
 URL: https://issues.apache.org/jira/browse/MESOS-5401
 Project: Mesos
  Issue Type: Improvement
Reporter: Kevin Klues
Assignee: Kevin Klues


In order to support Nvidia GPUs with docker containers in Mesos, we need to be 
able to consolidate all Nvidia libraries into a common volume and inject that 
volume into the container.

More info on why this is necessary here: 
https://github.com/NVIDIA/nvidia-docker/



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

[jira] [Created] (MESOS-5400) Add preliminary support for parsing ELF files in stout.

Kevin Klues created MESOS-5400:
--

 Summary: Add preliminary support for parsing ELF files in stout.
 Key: MESOS-5400
 URL: https://issues.apache.org/jira/browse/MESOS-5400
 Project: Mesos
  Issue Type: Improvement
Reporter: Kevin Klues
Assignee: Kevin Klues
Priority: Minor


The upcoming Nvidia GPU support for docker containers in Mesos relies on 
consolidating all Nvidia shared libraries into a common location for injecting 
a volume into a container.

As part of this, we need some preliminary parsing capabilities for ELF file to 
infer things about each shared library we are consolidating.



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

[jira] [Created] (MESOS-5399) Add utility for parsing ld.so.cache on linux.

Kevin Klues created MESOS-5399:
--

 Summary: Add utility for parsing ld.so.cache on linux.
 Key: MESOS-5399
 URL: https://issues.apache.org/jira/browse/MESOS-5399
 Project: Mesos
  Issue Type: Improvement
Reporter: Kevin Klues
Assignee: Kevin Klues
Priority: Minor


The /etc/ld.so.cache file on linux contains a mapping of dynamic library names 
to their fully resolved paths for use by ld when linking.

We should write a utility that knows how to parse this file so we can find the 
paths to these libraries as well.  This is especially important for collecting 
libraries into a common location for supporting Nvidia GPUs in mesos.



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

[jira] [Created] (MESOS-5398) Rewrite os::read() to be friendlier to reading binary files

Kevin Klues created MESOS-5398:
--

 Summary: Rewrite os::read() to be friendlier to reading binary 
files
 Key: MESOS-5398
 URL: https://issues.apache.org/jira/browse/MESOS-5398
 Project: Mesos
  Issue Type: Improvement
Reporter: Kevin Klues
Assignee: Kevin Klues
Priority: Minor


The existing read() implementation is based on calling getline() to
read in chunks of data from a file. This is fine for text-based files,
but is a little strange for binary files.



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

[jira] [Commented] (MESOS-3783) Replace Master/Slave Terminology Phase I - Update documentation


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

Vinod Kone commented on MESOS-3783:
---

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

> Replace Master/Slave Terminology Phase I - Update documentation 
> 
>
> Key: MESOS-3783
> URL: https://issues.apache.org/jira/browse/MESOS-3783
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: Jay Guo
>
> https://reviews.apache.org/r/47303/



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

[jira] [Updated] (MESOS-1478) Slave to Agent rename (Phase I).


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

Vinod Kone updated MESOS-1478:
--
Summary: Slave to Agent rename (Phase I).  (was: Slave to Agent rename.)

> Slave to Agent rename (Phase I).
> 
>
> Key: MESOS-1478
> URL: https://issues.apache.org/jira/browse/MESOS-1478
> Project: Mesos
>  Issue Type: Epic
>Reporter: Clark Breyman
>Priority: Minor
>  Labels: mesosphere
>
> Inspired by the comments on this PR:
> https://github.com/django/django/pull/2692
> TL;DR - Computers sharing work should be a good thing. Using the language of 
> human bondage and suffering is inappropriate in this context. It also has the 
> potential to alienate users and community members. 
> Working document: 
> https://docs.google.com/document/d/1P8_4wdk29I6NoVTjbFkRl05-tfxV9PY4WLoRNvExupM/edit#heading=h.9g7fqjh6652v



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

[jira] [Commented] (MESOS-3783) Replace Master/Slave Terminology Phase I - Update documentation


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

Vinod Kone commented on MESOS-3783:
---

Can you create a separate ticket for this?

> Replace Master/Slave Terminology Phase I - Update documentation 
> 
>
> Key: MESOS-3783
> URL: https://issues.apache.org/jira/browse/MESOS-3783
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: Jay Guo
> Fix For: 0.29.0
>
>
> https://reviews.apache.org/r/47303/



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

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

2016-05-17 Thread David Overcash (JIRA)


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

David Overcash commented on MESOS-4279:
---

Have the fixes for this made it into any branches yet?  Is there anything I can 
do to help move this forward?

> 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: Qian Zhang
>  Labels: docker, mesosphere
> Fix For: 0.29.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] [Commented] (MESOS-5395) Task getting stuck in staging state if launch it on a rebooted slave.

2016-05-17 Thread Joseph Wu (JIRA)


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

Joseph Wu commented on MESOS-5395:
--

The log messages you're seeing come from the framework telling Mesos to kill 
said tasks.  There might be something else going on that's preventing your task 
from launching after an agent failover.

Can you also share:
* The resources of your agents
* Full master/agent/Marathon logs before/during/after the event
* Full stdout/stderr files for the task in question
* Your Marathon app definition

> Task getting stuck in staging state if launch it on a rebooted slave.
> -
>
> Key: MESOS-5395
> URL: https://issues.apache.org/jira/browse/MESOS-5395
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.28.0
> Environment: mesos/marathon cluster,  3 maters/4 slaves
> Mesos: 0.28.0 ,  Marathon 0.15.2
>Reporter: Mengkui gong
>
> if rebooting a slave, after that,  using Marathon to launch a task,  the task 
> can start on other slaves without problem.  But if launch it on the rebooted 
> slave, the task will be stuck. From Mesos UI shows it in staging state from 
> active tasks list.  From Marathon UI shows it in deploying state. It can 
> keeping in stuck state for more than 2 hours.  After that time, Marathon will 
> automatically launch the task on this rebooted slave or other slave as 
> normal. So the rebooted slave be recovered as well after that time.   
> From Mesos log,  I can see "telling slave to kill task" all the time.
> I0517 15:25:27.207237 20568 master.cpp:3826] Telling slave 
> 282745ab-423a-4350-a449-3e8cdfccfb93-S1 at slave(1)@10.254.234.236:5050 
> (mesos-slave-3) to kill task 
> project-hub_project-hub-frontend.b645f24b-1c1f-11e6-bb25-d00d2cce797e of 
> framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730- (marathon) at 
> scheduler-fe615b72-ab92-49ca-89e6-e74e600c7e15@10.254.228.3:56757.
> From rebooted slave log, I can see:
> May 17 15:28:37 euca-10-254-234-236 mesos-slave[829]: I0517 15:28:37.206831   
> 916 slave.cpp:1891] Asked to kill task 
> project-hub_project-hub-frontend.b645f24b-1c1f-11e6-bb25-d00d2cce797e of 
> framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730-
> May 17 15:28:37 euca-10-254-234-236 mesos-slave[829]: W0517 15:28:37.206866   
> 916 slave.cpp:2018] Ignoring kill task 
> project-hub_project-hub-frontend.b645f24b-1c1f-11e6-bb25-d00d2cce797e because 
> the executor 
> 'project-hub_project-hub-frontend.b645f24b-1c1f-11e6-bb25-d00d2cce797e' of 
> framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730- is terminating/terminated.



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

[jira] [Commented] (MESOS-3781) Replace Master/Slave Terminology Phase I - Add duplicate agent flags