[jira] [Assigned] (MESOS-5397) Slave/Agent Rename Phase 1: Update terms in the website

[haosdent (JIRA)]

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

haosdent reassigned MESOS-5397:
---

Assignee: haosdent

> Slave/Agent Rename Phase 1: Update terms in the website
> ---
>
> Key: MESOS-5397
> URL: https://issues.apache.org/jira/browse/MESOS-5397
> Project: Mesos
>  Issue Type: Bug
>  Components: project website
>Reporter: Vinod Kone
>Assignee: haosdent
>
> The following files need to be updated
> site/source/index.html.md
> site/README.md



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

[jira] [Commented] (MESOS-970) Upgrade bundled leveldb to 1.18

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-970:
--

I didn't enable that CI job yet because some of our benchmark tests take a very 
long time to finish. Once we fix that (there's a ticket to fix this behavior I 
think), we can definitely use the benchmarks CI job.

> Upgrade bundled leveldb to 1.18
> ---
>
> Key: MESOS-970
> URL: https://issues.apache.org/jira/browse/MESOS-970
> Project: Mesos
>  Issue Type: Improvement
>  Components: replicated log
>Reporter: Benjamin Mahler
>Assignee: Tomasz Janiszewski
>
> We currently bundle leveldb 1.4, and the latest version is leveldb 1.18.
> Upgrade to 1.18 could solve the problems when build Mesos in some non-x86 
> architecture CPU.



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

[jira] [Commented] (MESOS-970) Upgrade bundled leveldb to 1.18

[Tomasz Janiszewski (JIRA)]

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

Tomasz Janiszewski commented on MESOS-970:
--

[~vinodkone] Can we run benchmarks on ASF CI 
(https://builds.apache.org/job/Mesos-Benchmarks/)?

> Upgrade bundled leveldb to 1.18
> ---
>
> Key: MESOS-970
> URL: https://issues.apache.org/jira/browse/MESOS-970
> Project: Mesos
>  Issue Type: Improvement
>  Components: replicated log
>Reporter: Benjamin Mahler
>Assignee: Tomasz Janiszewski
>
> We currently bundle leveldb 1.4, and the latest version is leveldb 1.18.
> Upgrade to 1.18 could solve the problems when build Mesos in some non-x86 
> architecture CPU.



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

[jira] [Updated] (MESOS-5453) CNI should not store subnet of address in NetworkInfo

[Jie Yu (JIRA)]

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

Jie Yu updated MESOS-5453:
--
Fix Version/s: 0.29.0

> CNI should not store subnet of address in NetworkInfo
> -
>
> Key: MESOS-5453
> URL: https://issues.apache.org/jira/browse/MESOS-5453
> Project: Mesos
>  Issue Type: Bug
>Reporter: Dan Osborne
> Fix For: 0.29.0
>
>
> When the CNI isolator executes the CNI plugin, that CNI plugin will return an 
> IP Address and Subnet (192.168.0.1/32). Mesos should strip the subnet before 
> storing the address in the Task.NetworkInfo.IPAddress.
> Reason being - most current mesos components are not expecting a subnet in 
> the Task's NetworkInfo.IPAddress, and instead expect just the IP address. 
> This can cause errors in those components, such as Mesos-DNS failing to 
> return a NetworkInfo address (and instead defaulting to the next configured 
> IPSource), and Marathon generating invalid links to tasks (as it includes /32 
> in the link)



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

[jira] [Updated] (MESOS-5453) CNI should not store subnet of address in NetworkInfo

[Jie Yu (JIRA)]

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

Jie Yu updated MESOS-5453:
--
Labels: mesosphere  (was: )

> CNI should not store subnet of address in NetworkInfo
> -
>
> Key: MESOS-5453
> URL: https://issues.apache.org/jira/browse/MESOS-5453
> Project: Mesos
>  Issue Type: Bug
>Reporter: Dan Osborne
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> When the CNI isolator executes the CNI plugin, that CNI plugin will return an 
> IP Address and Subnet (192.168.0.1/32). Mesos should strip the subnet before 
> storing the address in the Task.NetworkInfo.IPAddress.
> Reason being - most current mesos components are not expecting a subnet in 
> the Task's NetworkInfo.IPAddress, and instead expect just the IP address. 
> This can cause errors in those components, such as Mesos-DNS failing to 
> return a NetworkInfo address (and instead defaulting to the next configured 
> IPSource), and Marathon generating invalid links to tasks (as it includes /32 
> in the link)



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

[jira] [Updated] (MESOS-5453) CNI should not store subnet of address in NetworkInfo

[Jie Yu (JIRA)]

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

Jie Yu updated MESOS-5453:
--
  Sprint: Mesosphere Sprint 35
Story Points: 2

> CNI should not store subnet of address in NetworkInfo
> -
>
> Key: MESOS-5453
> URL: https://issues.apache.org/jira/browse/MESOS-5453
> Project: Mesos
>  Issue Type: Bug
>Reporter: Dan Osborne
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> When the CNI isolator executes the CNI plugin, that CNI plugin will return an 
> IP Address and Subnet (192.168.0.1/32). Mesos should strip the subnet before 
> storing the address in the Task.NetworkInfo.IPAddress.
> Reason being - most current mesos components are not expecting a subnet in 
> the Task's NetworkInfo.IPAddress, and instead expect just the IP address. 
> This can cause errors in those components, such as Mesos-DNS failing to 
> return a NetworkInfo address (and instead defaulting to the next configured 
> IPSource), and Marathon generating invalid links to tasks (as it includes /32 
> in the link)



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

[jira] [Comment Edited] (MESOS-5450) Make the SASL dependency optional.

[Till Toenshoff (JIRA)]

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

Till Toenshoff edited comment on MESOS-5450 at 5/25/16 9:38 PM:


Let's please adapt the above description and set straight that we do have a 
pluggable authentication layer -- in fact, we actually have it for both, V0 and 
V1 (HTTP) authentication.

The challenge is the "default" implementation (SASL CRAM-MD5) which we linked 
into libmesos for historical/transitional reasons. This default implementation 
creates a hard dependency of libmesos towards CyrusSASL as described within our 
`src/Makefile.am`
https://github.com/apache/mesos/blob/8be9b5b5decd9ec2bcad547b1dff29b777cbc438/src/Makefile.am#L1867,
 
https://github.com/apache/mesos/blob/8be9b5b5decd9ec2bcad547b1dff29b777cbc438/src/Makefile.am#L1868
 and 
https://github.com/apache/mesos/blob/8be9b5b5decd9ec2bcad547b1dff29b777cbc438/src/Makefile.am#L678

I would also like to propose adding a long term solution, minimizing the 
platform specifics within Mesos core.

How about this:

We remove the default implementation of the authentication which makes SASL a 
hard dependency of libmesos right now. We ship the CRAM-MD5 authenticator 
module with Mesos, allowing installation just like we already do with other 
modules. We disable installing and building of the CRAM-MD5 authentication for 
Windows. 

All of this only needs platform specific patches in our build env - not in the 
code.

Then, instead of disabling authentication within Mesos for Windows as it is now 
proposed in a short termed solution, we actually add a trivial, not perfectly 
flexible but usable authentication module. Please mind that one great advantage 
of using SASL is the mechanism negotiation. Lets call this new variant our 
“test-authentication" for now. That one will get included in all builds of 
Mesos, also within the Windows variant. For Windows, it would be the default 
authentication, for other platforms we stick with CRAM-MD5 by default but still 
offer the "test-authentication" as an option to be selected by the user when 
starting up the runnables (master, agent and framework).

Such authenticator / authenticatee pair might also pose as a great example and 
starting point for other developers, intending to add custom authentication 
variants not supported by SASL (or simply without SASL for any reason).



was (Author: tillt):
Let's please adapt the above description and set straight that we do have a 
pluggable authentication layer -- in fact, we actually have it for both, V0 and 
V1 (HTTP) authentication.

The challenge is the "default" implementation (SASL CRAM-MD5) which we linked 
into libmesos for historical/transitional reasons. This default implementation 
creates a hard dependency of libmesos towards CyrusSASL as described within our 
`src/Makefile.am`
https://github.com/apache/mesos/blob/8be9b5b5decd9ec2bcad547b1dff29b777cbc438/src/Makefile.am#L1867,
 
https://github.com/apache/mesos/blob/8be9b5b5decd9ec2bcad547b1dff29b777cbc438/src/Makefile.am#L1868
 and 
https://github.com/apache/mesos/blob/8be9b5b5decd9ec2bcad547b1dff29b777cbc438/src/Makefile.am#L678

I would also like to propose adding a long term solution, minimizing the 
platform specifics within Mesos core.

How about this:

We remove the default implementation of the authentication which makes SASL a 
hard dependency of libmesos right now. We ship the CRAM-MD5 authenticator 
module with Mesos, allowing installation just like we already do with other 
modules. We disable installing and building of the CRAM-MD5 authenticator for 
Windows. 

All of this only needs platform specific patches in our build env - not in the 
code.

Then, instead of disabling authentication within Mesos for Windows as it is now 
proposed in a short termed solution, we actually add a trivial, not perfectly 
flexible but usable authentication module. Please mind that one great advantage 
of using SASL is the mechanism negotiation. Lets call this new variant our 
“test-authentication" for now. That one will get included in all builds of 
Mesos, also within the Windows variant. For Windows, it would be the default 
authentication, for other platforms we stick with CRAM-MD5 by default but still 
offer the "test-authentication" as an option to be selected by the user when 
starting up the runnables (master, agent and framework).

Such authenticator / authenticatee pair might also pose as a great example and 
starting point for other developers, intending to add custom authentication 
variants not supported by SASL (or simply without SASL for any reason).


> Make the SASL dependency optional.
> --
>
> Key: MESOS-5450
> URL: https://issues.apache.org/jira/browse/MESOS-5450
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>  

[jira] [Commented] (MESOS-5450) Make the SASL dependency optional.

[Till Toenshoff (JIRA)]

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

Till Toenshoff commented on MESOS-5450:
---

Let's please adapt the above description and set straight that we do have a 
pluggable authentication layer -- in fact, we actually have it for both, V0 and 
V1 (HTTP) authentication.

I would also like to propose adding a long term solution, minimizing the 
platform specifics within Mesos core.

How about this:

We remove the default implementation of the authentication which makes SASL a 
hard dependency of libmesos right now. We ship the CRAM-MD5 authenticator 
module with Mesos, allowing installation just like we already do with other 
modules. We disable installing and building of the CRAM-MD5 authenticator for 
Windows. 

All of this only needs platform specific patches in our build env - not in the 
code.

Then, instead of disabling authentication within Mesos for Windows as it is now 
proposed in a short termed solution, we actually add a trivial, not perfectly 
flexible but usable authentication module. Please mind that one great advantage 
of using SASL is the mechanism negotiation. Lets call this new variant our 
“test-authentication" for now. That one will get included in all builds of 
Mesos, also within the Windows variant. For Windows, it would be the default 
authentication, for other platforms we stick with CRAM-MD5 by default but still 
offer the "test-authentication" as an option to be selected by the user when 
starting up the runnables (master, agent and framework).

Such authenticator / authenticatee pair might also pose as a great example and 
starting point for other developers, intending to add custom authentication 
variants not supported by SASL (or simply without SASL for any reason).


> Make the SASL dependency optional.
> --
>
> Key: MESOS-5450
> URL: https://issues.apache.org/jira/browse/MESOS-5450
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>  Labels: mesosphere
>
> Right now there is a hard dependency on SASL, which probably won't work well 
> on Windows (at least) in the near future for our use cases.
> In the future, it would be nice to have a pluggable authentication layer.



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

[jira] [Comment Edited] (MESOS-5450) Make the SASL dependency optional.

[Till Toenshoff (JIRA)]

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

Till Toenshoff edited comment on MESOS-5450 at 5/25/16 9:23 PM:


Let's please adapt the above description and set straight that we do have a 
pluggable authentication layer -- in fact, we actually have it for both, V0 and 
V1 (HTTP) authentication.

The challenge is the "default" implementation (SASL CRAM-MD5) which we linked 
into libmesos for historical/transitional reasons. This default implementation 
creates a hard dependency of libmesos towards CyrusSASL as described within our 
`src/Makefile.am`
https://github.com/apache/mesos/blob/8be9b5b5decd9ec2bcad547b1dff29b777cbc438/src/Makefile.am#L1867,
 
https://github.com/apache/mesos/blob/8be9b5b5decd9ec2bcad547b1dff29b777cbc438/src/Makefile.am#L1868
 and 
https://github.com/apache/mesos/blob/8be9b5b5decd9ec2bcad547b1dff29b777cbc438/src/Makefile.am#L678

I would also like to propose adding a long term solution, minimizing the 
platform specifics within Mesos core.

How about this:

We remove the default implementation of the authentication which makes SASL a 
hard dependency of libmesos right now. We ship the CRAM-MD5 authenticator 
module with Mesos, allowing installation just like we already do with other 
modules. We disable installing and building of the CRAM-MD5 authenticator for 
Windows. 

All of this only needs platform specific patches in our build env - not in the 
code.

Then, instead of disabling authentication within Mesos for Windows as it is now 
proposed in a short termed solution, we actually add a trivial, not perfectly 
flexible but usable authentication module. Please mind that one great advantage 
of using SASL is the mechanism negotiation. Lets call this new variant our 
“test-authentication" for now. That one will get included in all builds of 
Mesos, also within the Windows variant. For Windows, it would be the default 
authentication, for other platforms we stick with CRAM-MD5 by default but still 
offer the "test-authentication" as an option to be selected by the user when 
starting up the runnables (master, agent and framework).

Such authenticator / authenticatee pair might also pose as a great example and 
starting point for other developers, intending to add custom authentication 
variants not supported by SASL (or simply without SASL for any reason).



was (Author: tillt):
Let's please adapt the above description and set straight that we do have a 
pluggable authentication layer -- in fact, we actually have it for both, V0 and 
V1 (HTTP) authentication.

I would also like to propose adding a long term solution, minimizing the 
platform specifics within Mesos core.

How about this:

We remove the default implementation of the authentication which makes SASL a 
hard dependency of libmesos right now. We ship the CRAM-MD5 authenticator 
module with Mesos, allowing installation just like we already do with other 
modules. We disable installing and building of the CRAM-MD5 authenticator for 
Windows. 

All of this only needs platform specific patches in our build env - not in the 
code.

Then, instead of disabling authentication within Mesos for Windows as it is now 
proposed in a short termed solution, we actually add a trivial, not perfectly 
flexible but usable authentication module. Please mind that one great advantage 
of using SASL is the mechanism negotiation. Lets call this new variant our 
“test-authentication" for now. That one will get included in all builds of 
Mesos, also within the Windows variant. For Windows, it would be the default 
authentication, for other platforms we stick with CRAM-MD5 by default but still 
offer the "test-authentication" as an option to be selected by the user when 
starting up the runnables (master, agent and framework).

Such authenticator / authenticatee pair might also pose as a great example and 
starting point for other developers, intending to add custom authentication 
variants not supported by SASL (or simply without SASL for any reason).


> Make the SASL dependency optional.
> --
>
> Key: MESOS-5450
> URL: https://issues.apache.org/jira/browse/MESOS-5450
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>  Labels: mesosphere
>
> Right now there is a hard dependency on SASL, which probably won't work well 
> on Windows (at least) in the near future for our use cases.
> In the future, it would be nice to have a pluggable authentication layer.



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

[jira] [Commented] (MESOS-5450) Make the SASL dependency optional.

[Till Toenshoff (JIRA)]

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

Till Toenshoff commented on MESOS-5450:
---

How about we add another ticket using my proposal (or something with similar 
qualities) for the long-termed solution as another JIRA and make them link each 
other? 

> Make the SASL dependency optional.
> --
>
> Key: MESOS-5450
> URL: https://issues.apache.org/jira/browse/MESOS-5450
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>  Labels: mesosphere
>
> Right now there is a hard dependency on SASL, which probably won't work well 
> on Windows (at least) in the near future for our use cases.
> In the future, it would be nice to have a pluggable authentication layer.



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

[jira] [Updated] (MESOS-5453) CNI should not store subnet of address in NetworkInfo

[Dan Osborne (JIRA)]

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

Dan Osborne updated MESOS-5453:
---
Description: 
When the CNI isolator executes the CNI plugin, that CNI plugin will return an 
IP Address and Subnet (192.168.0.1/32). Mesos should strip the subnet before 
storing the address in the Task.NetworkInfo.IPAddress.

Reason being - most current mesos components are not expecting a subnet in the 
Task's NetworkInfo.IPAddress, and instead expect just the IP address. This can 
cause errors in those components, such as Mesos-DNS failing to return a 
NetworkInfo address (and instead defaulting to the next configured IPSource), 
and Marathon generating invalid links to tasks (as it includes /32 in the link)

  was:When the CNI isolator executes the CNI plugin, that CNI plugin will 
return an IP Address and Subnet (192.168.0.1/32). Mesos should strip the subnet 
before storing the address in the Task.NetworkInfo.IPAddress


> CNI should not store subnet of address in NetworkInfo
> -
>
> Key: MESOS-5453
> URL: https://issues.apache.org/jira/browse/MESOS-5453
> Project: Mesos
>  Issue Type: Bug
>Reporter: Dan Osborne
>
> When the CNI isolator executes the CNI plugin, that CNI plugin will return an 
> IP Address and Subnet (192.168.0.1/32). Mesos should strip the subnet before 
> storing the address in the Task.NetworkInfo.IPAddress.
> Reason being - most current mesos components are not expecting a subnet in 
> the Task's NetworkInfo.IPAddress, and instead expect just the IP address. 
> This can cause errors in those components, such as Mesos-DNS failing to 
> return a NetworkInfo address (and instead defaulting to the next configured 
> IPSource), and Marathon generating invalid links to tasks (as it includes /32 
> in the link)



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

[jira] [Assigned] (MESOS-2720) Publish the schema for operator endpoints

[Vinod Kone (JIRA)]

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

Vinod Kone reassigned MESOS-2720:
-

Assignee: Vinod Kone

> Publish the schema for operator endpoints
> -
>
> Key: MESOS-2720
> URL: https://issues.apache.org/jira/browse/MESOS-2720
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Isabel Jimenez
>Assignee: Vinod Kone
>  Labels: mesosphere
>
> We should define the schema of both requests and responses to the operator 
> endpoints.



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

[jira] [Created] (MESOS-5457) Create a small testing doc for the v1 Scheduler/Executor API

[Anand Mazumdar (JIRA)]

Anand Mazumdar created MESOS-5457:
-

 Summary: Create a small testing doc for the v1 Scheduler/Executor 
API
 Key: MESOS-5457
 URL: https://issues.apache.org/jira/browse/MESOS-5457
 Project: Mesos
  Issue Type: Improvement
Reporter: Anand Mazumdar
Assignee: Anand Mazumdar
 Fix For: 0.29.0


This is a follow up JIRA based on the comments from MESOS-3302 around testing 
the v1 Scheduler/Executor API. I created a small document that has the details 
of the manual testing done by me. The intent of this issue is to track  all the 
details on this ticket rather then on the epic.

Link to the doc: 
https://docs.google.com/document/d/1Z8_8pn-x-VYInm12_En-1oP-FxkLzpG8EgC1qQ0eDRY/edit



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

[jira] [Commented] (MESOS-3302) Scheduler API v1 improvements

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar commented on MESOS-3302:
---

Created https://issues.apache.org/jira/browse/MESOS-5457 to track this.

> Scheduler API v1 improvements
> -
>
> Key: MESOS-3302
> URL: https://issues.apache.org/jira/browse/MESOS-3302
> Project: Mesos
>  Issue Type: Epic
>Reporter: Marco Massenzio
>  Labels: mesosphere, twitter
>
> This Epic covers all the refinements that we may want to build on top of the 
> {{HTTP API}} MVP epic (MESOS-2288) which was released initially with Mesos 
> {{0.24.0}}.
> The tasks/stories here cover the necessary work to bring the API v1 to what 
> we would regard as "Production-ready" state in preparation for the {{1.0.0}} 
> release.



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

[jira] [Updated] (MESOS-5457) Create a small testing doc for the v1 Scheduler/Executor API

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar updated MESOS-5457:
--
Assignee: Jay Guo  (was: Anand Mazumdar)

> Create a small testing doc for the v1 Scheduler/Executor API
> 
>
> Key: MESOS-5457
> URL: https://issues.apache.org/jira/browse/MESOS-5457
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: Jay Guo
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> This is a follow up JIRA based on the comments from MESOS-3302 around testing 
> the v1 Scheduler/Executor API. I created a small document that has the 
> details of the manual testing done by me. The intent of this issue is to 
> track  all the details on this ticket rather then on the epic.
> Link to the doc: 
> https://docs.google.com/document/d/1Z8_8pn-x-VYInm12_En-1oP-FxkLzpG8EgC1qQ0eDRY/edit



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

[jira] [Updated] (MESOS-5456) Master anonymous modules should initialized before any other components.

[Avinash Sridharan (JIRA)]

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

Avinash Sridharan updated MESOS-5456:
-
Summary: Master anonymous modules should initialized before any other 
components.  (was: Master modules should initialized before any other 
components.)

> Master anonymous modules should initialized before any other components.
> 
>
> Key: MESOS-5456
> URL: https://issues.apache.org/jira/browse/MESOS-5456
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>
> Anonymous modules on the Master are by design supposed to be independent of 
> any Mesos components. However, there might be a dependency in the reverse 
> direction. For e.g., Anonymous modules might want to influence the behavior 
> of Mesos components (say by generating configuration, that might be consumed 
> later by the components). 
> The Anonymous modules on the Master therefore need to be initialized before 
> other Mesos components. 



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

[jira] [Updated] (MESOS-5456) Master anonymous modules should initialized before any other components.

[Avinash Sridharan (JIRA)]

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

Avinash Sridharan updated MESOS-5456:
-
   Sprint: Mesosphere Sprint 35
  Environment: Linux
   Labels: mesosphere  (was: )
Fix Version/s: 0.29.0

> Master anonymous modules should initialized before any other components.
> 
>
> Key: MESOS-5456
> URL: https://issues.apache.org/jira/browse/MESOS-5456
> Project: Mesos
>  Issue Type: Improvement
> Environment: Linux
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> Anonymous modules on the Master are by design supposed to be independent of 
> any Mesos components. However, there might be a dependency in the reverse 
> direction. For e.g., Anonymous modules might want to influence the behavior 
> of Mesos components (say by generating configuration, that might be consumed 
> later by the components). 
> The Anonymous modules on the Master therefore need to be initialized before 
> other Mesos components. 



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

[jira] [Created] (MESOS-5456) Master modules should initialized before any other components.

[Avinash Sridharan (JIRA)]

Avinash Sridharan created MESOS-5456:


 Summary: Master modules should initialized before any other 
components.
 Key: MESOS-5456
 URL: https://issues.apache.org/jira/browse/MESOS-5456
 Project: Mesos
  Issue Type: Improvement
Reporter: Avinash Sridharan
Assignee: Avinash Sridharan


Anonymous modules on the Master are by design supposed to be independent of any 
Mesos components. However, there might be a dependency in the reverse 
direction. For e.g., Anonymous modules might want to influence the behavior of 
Mesos components (say by generating configuration, that might be consumed later 
by the components). 

The Anonymous modules on the Master therefore need to be initialized before 
other Mesos components. 



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

[jira] [Updated] (MESOS-5452) Agent modules should be initialized before all components except firewall.

[Avinash Sridharan (JIRA)]

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

Avinash Sridharan updated MESOS-5452:
-
Description: On Mesos Agents Anonymous modules should not have any 
dependencies, by design, on any other Mesos components. This implies that 
Anonymous modules should be initialized before all other Mesos components other 
than `Firewall`. The dependency on `Firewall` is primarily to enforce any 
policies to secure endpoints that might be owned by the Anonymous module.  
(was: Anonymous modules should not have any dependencies, by design, on any 
other Mesos components. This implies that Anonymous modules should be 
initialized before all other Mesos components other than `Firewall`. The 
dependency on `Firewall` is primarily to enforce any policies to secure 
endpoints that might be owned by the Anonymous module.)

> Agent modules should be initialized before all components except firewall.
> --
>
> Key: MESOS-5452
> URL: https://issues.apache.org/jira/browse/MESOS-5452
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization
> Environment: Linux
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> On Mesos Agents Anonymous modules should not have any dependencies, by 
> design, on any other Mesos components. This implies that Anonymous modules 
> should be initialized before all other Mesos components other than 
> `Firewall`. The dependency on `Firewall` is primarily to enforce any policies 
> to secure endpoints that might be owned by the Anonymous module.



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

[jira] [Updated] (MESOS-5452) Agent modules should be initialized before all components except firewall.

[Avinash Sridharan (JIRA)]

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

Avinash Sridharan updated MESOS-5452:
-
Summary: Agent modules should be initialized before all components except 
firewall.  (was: Modules should be initialized before all components except 
firewall.)

> Agent modules should be initialized before all components except firewall.
> --
>
> Key: MESOS-5452
> URL: https://issues.apache.org/jira/browse/MESOS-5452
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization
> Environment: Linux
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> Anonymous modules should not have any dependencies, by design, on any other 
> Mesos components. This implies that Anonymous modules should be initialized 
> before all other Mesos components other than `Firewall`. The dependency on 
> `Firewall` is primarily to enforce any policies to secure endpoints that 
> might be owned by the Anonymous module.



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

[jira] [Created] (MESOS-5455) Transition away from temporary build variables

[Alex Clemmer (JIRA)]

Alex Clemmer created MESOS-5455:
---

 Summary: Transition away from temporary build variables
 Key: MESOS-5455
 URL: https://issues.apache.org/jira/browse/MESOS-5455
 Project: Mesos
  Issue Type: Bug
  Components: cmake
Reporter: Alex Clemmer
Assignee: Alex Clemmer


Right now the CMake build system has a bunch of stub values for variables like 
`BUILD_DATE`.

We should replace these with "real" values.



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

[jira] [Updated] (MESOS-5454) Slave to Agent rename (Phase II).

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-5454:
--
Epic Name: Agent Rename (Phase II)  (was: Agent Rename)

> Slave to Agent rename (Phase II).
> -
>
> Key: MESOS-5454
> URL: https://issues.apache.org/jira/browse/MESOS-5454
> Project: Mesos
>  Issue Type: Epic
>Reporter: Clark Breyman
>Priority: Minor
>  Labels: mesosphere
>
> This ticket tracks the work needed for Phase II according to 
> 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-5397) Slave/Agent Rename Phase 1: Update terms in the website

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-5397:
---

[~haosd...@gmail.com] is this something you want to take on?

> Slave/Agent Rename Phase 1: Update terms in the website
> ---
>
> Key: MESOS-5397
> URL: https://issues.apache.org/jira/browse/MESOS-5397
> Project: Mesos
>  Issue Type: Bug
>  Components: project website
>Reporter: Vinod Kone
>
> The following files need to be updated
> site/source/index.html.md
> site/README.md



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

[jira] [Commented] (MESOS-3302) Scheduler API v1 improvements

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-3302:
---

[~anandmazumdar] Why don't you create the ticket and start the doc? [~guoger] 
and others can add to it.

> Scheduler API v1 improvements
> -
>
> Key: MESOS-3302
> URL: https://issues.apache.org/jira/browse/MESOS-3302
> Project: Mesos
>  Issue Type: Epic
>Reporter: Marco Massenzio
>  Labels: mesosphere, twitter
>
> This Epic covers all the refinements that we may want to build on top of the 
> {{HTTP API}} MVP epic (MESOS-2288) which was released initially with Mesos 
> {{0.24.0}}.
> The tasks/stories here cover the necessary work to bring the API v1 to what 
> we would regard as "Production-ready" state in preparation for the {{1.0.0}} 
> release.



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

[jira] [Updated] (MESOS-5454) Slave to Agent rename (Phase II).

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-5454:
--
Description: This ticket tracks the work needed for Phase II according to 
https://docs.google.com/document/d/1P8_4wdk29I6NoVTjbFkRl05-tfxV9PY4WLoRNvExupM/edit#heading=h.9g7fqjh6652v
  (was: 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)

> Slave to Agent rename (Phase II).
> -
>
> Key: MESOS-5454
> URL: https://issues.apache.org/jira/browse/MESOS-5454
> Project: Mesos
>  Issue Type: Epic
>Reporter: Clark Breyman
>Priority: Minor
>  Labels: mesosphere
>
> This ticket tracks the work needed for Phase II according to 
> 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] [Created] (MESOS-5454) Slave to Agent rename (Phase II).

[Vinod Kone (JIRA)]

Vinod Kone created MESOS-5454:
-

 Summary: Slave to Agent rename (Phase II).
 Key: MESOS-5454
 URL: https://issues.apache.org/jira/browse/MESOS-5454
 Project: Mesos
  Issue Type: Epic
Reporter: Clark Breyman
Priority: Minor


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-5407) Slave/Agent rename: diagrams in docs

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-5407:
---

[~guoger] any updates on this?

> 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-2082) Update the webui to include maintenance information.

[haosdent (JIRA)]

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

haosdent commented on MESOS-2082:
-

I could help review and verify this as well. 

> Update the webui to include maintenance information.
> 
>
> Key: MESOS-2082
> URL: https://issues.apache.org/jira/browse/MESOS-2082
> Project: Mesos
>  Issue Type: Task
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Shuai Lin
>  Labels: mesosphere, twitter
>
> The simplest thing here would probably be to include another tab in the 
> header for maintenance information.
> We could also consider adding maintenance information inline to the slaves 
> table. Depending on how this is done, the maintenance tab could actually be a 
> subset of the slaves table; only those slaves for which there is maintenance 
> information.



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

[jira] [Commented] (MESOS-2082) Update the webui to include maintenance information.

[Benjamin Mahler (JIRA)]

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

Benjamin Mahler commented on MESOS-2082:


Happy to help get this committed if someone assists with reviewing. [~lins05] 
be sure to include some screenshots.

> Update the webui to include maintenance information.
> 
>
> Key: MESOS-2082
> URL: https://issues.apache.org/jira/browse/MESOS-2082
> Project: Mesos
>  Issue Type: Task
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Shuai Lin
>  Labels: mesosphere, twitter
>
> The simplest thing here would probably be to include another tab in the 
> header for maintenance information.
> We could also consider adding maintenance information inline to the slaves 
> table. Depending on how this is done, the maintenance tab could actually be a 
> subset of the slaves table; only those slaves for which there is maintenance 
> information.



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

[jira] [Commented] (MESOS-5430) Design the improvement of the home page of mesos.apache.org

[haosdent (JIRA)]

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

haosdent commented on MESOS-5430:
-

And for the code, it just a quick example. So once Jonathan finish reviewing 
the example, I would reorganize the code to make it ready to posted in review 
board. 

> Design the improvement of the home page of mesos.apache.org
> ---
>
> Key: MESOS-5430
> URL: https://issues.apache.org/jira/browse/MESOS-5430
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Vinod Kone
>Assignee: Jonathan Manalus
> Attachments: page_1.png, page_2.png
>
>
> The idea is to come up with a minimal improvement for the design of the home 
> page of mesos.apache.org.
> Proposed Redesign: https://invis.io/CV7DZF1JW#/159898819_Mesos-apache-org



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

[jira] [Commented] (MESOS-5430) Design the improvement of the home page of mesos.apache.org

[haosdent (JIRA)]

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

haosdent commented on MESOS-5430:
-

{quote}
Can the text wrapping fix be done without having to depend on the exact wording 
or length of the text?
{quote}

Yes, I make it not depends on length now.

> Design the improvement of the home page of mesos.apache.org
> ---
>
> Key: MESOS-5430
> URL: https://issues.apache.org/jira/browse/MESOS-5430
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Vinod Kone
>Assignee: Jonathan Manalus
> Attachments: page_1.png, page_2.png
>
>
> The idea is to come up with a minimal improvement for the design of the home 
> page of mesos.apache.org.
> Proposed Redesign: https://invis.io/CV7DZF1JW#/159898819_Mesos-apache-org



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

[jira] [Commented] (MESOS-5430) Design the improvement of the home page of mesos.apache.org

[haosdent (JIRA)]

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

haosdent commented on MESOS-5430:
-

Hi, [~jmanalus] Thanks a lot for your review, I send you a hangout request 
[send to jmana...@gmail.com] so that I would chat with you more quickly. :-) I 
just push a new version on http://blog.haosdent.me/mesos-site-demo/source/ 
which fix most issues you listed above except "make the twitter buttons appears 
the footer text". Sorry I could not get the point about it and would you 
provide more information about this? So that I could fix it as well. :-) 

> Design the improvement of the home page of mesos.apache.org
> ---
>
> Key: MESOS-5430
> URL: https://issues.apache.org/jira/browse/MESOS-5430
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Vinod Kone
>Assignee: Jonathan Manalus
> Attachments: page_1.png, page_2.png
>
>
> The idea is to come up with a minimal improvement for the design of the home 
> page of mesos.apache.org.
> Proposed Redesign: https://invis.io/CV7DZF1JW#/159898819_Mesos-apache-org



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

[jira] [Commented] (MESOS-2082) Update the webui to include maintenance information.

[Joseph Wu (JIRA)]

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

Joseph Wu commented on MESOS-2082:
--

I can help you do preliminary reviews and/or answer any questions you have.  
But I suspect many people (especially shepherds) will not have cycles to spare 
until some time after MesosCon.

> Update the webui to include maintenance information.
> 
>
> Key: MESOS-2082
> URL: https://issues.apache.org/jira/browse/MESOS-2082
> Project: Mesos
>  Issue Type: Task
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Shuai Lin
>  Labels: mesosphere, twitter
>
> The simplest thing here would probably be to include another tab in the 
> header for maintenance information.
> We could also consider adding maintenance information inline to the slaves 
> table. Depending on how this is done, the maintenance tab could actually be a 
> subset of the slaves table; only those slaves for which there is maintenance 
> information.



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

[jira] [Commented] (MESOS-5430) Design the improvement of the home page of mesos.apache.org

[Jonathan Manalus (JIRA)]

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

Jonathan Manalus commented on MESOS-5430:
-

@Vinod - Will need to wait until the final copy is added to the new page. We 
can work on it if need be once [~haosd...@gmail.com] code it committed 

> Design the improvement of the home page of mesos.apache.org
> ---
>
> Key: MESOS-5430
> URL: https://issues.apache.org/jira/browse/MESOS-5430
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Vinod Kone
>Assignee: Jonathan Manalus
> Attachments: page_1.png, page_2.png
>
>
> The idea is to come up with a minimal improvement for the design of the home 
> page of mesos.apache.org.
> Proposed Redesign: https://invis.io/CV7DZF1JW#/159898819_Mesos-apache-org



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

[jira] [Commented] (MESOS-5430) Design the improvement of the home page of mesos.apache.org

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-5430:
---

Thanks for the demo [~haosd...@gmail.com] and feedback [~jmanalus].

Regarding the last point, I was hoping we can change the text after we commit 
haosdent's code. Can the text wrapping fix be done without having to depend on 
the exact wording or length of the text?

> Design the improvement of the home page of mesos.apache.org
> ---
>
> Key: MESOS-5430
> URL: https://issues.apache.org/jira/browse/MESOS-5430
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Vinod Kone
>Assignee: Jonathan Manalus
> Attachments: page_1.png, page_2.png
>
>
> The idea is to come up with a minimal improvement for the design of the home 
> page of mesos.apache.org.
> Proposed Redesign: https://invis.io/CV7DZF1JW#/159898819_Mesos-apache-org



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

[jira] [Created] (MESOS-5453) CNI should not store subnet of address in NetworkInfo

[Dan Osborne (JIRA)]

Dan Osborne created MESOS-5453:
--

 Summary: CNI should not store subnet of address in NetworkInfo
 Key: MESOS-5453
 URL: https://issues.apache.org/jira/browse/MESOS-5453
 Project: Mesos
  Issue Type: Bug
Reporter: Dan Osborne


When the CNI isolator executes the CNI plugin, that CNI plugin will return an 
IP Address and Subnet (192.168.0.1/32). Mesos should strip the subnet before 
storing the address in the Task.NetworkInfo.IPAddress



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

[jira] [Commented] (MESOS-5430) Design the improvement of the home page of mesos.apache.org

[Jonathan Manalus (JIRA)]

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

Jonathan Manalus commented on MESOS-5430:
-

[~haosd...@gmail.com] It looks awesome!

A few minor tweaks 
- Below the sub header text it should be 48px and not 46px 
http://cl.ly/1d0D1l241J1f
- Wasn't on the the mockup, but on hover of the buttons and link. Can you have 
them change to #47ABE2
- Can you make sure the above and below margins of the main content section are 
96px http://cl.ly/1O2c2l0V3j12
- The content in the footer should have 48px above margin, and not 45px
- On mobile: Can you make sure there is 24px margins on the right and left side 
http://cl.ly/0G080z0J353i
- On mobile: Can you make the twitter buttons appears the footer text 
http://cl.ly/0g2p3m2v1035
- On mobile: Can you make this line disappear when the menu is open 
http://cl.ly/073J090C4523
- On mobile: Can you fix the text wrap, so it doesn't have this odd break 
http://cl.ly/1I3H3l3I2z3m - This might want to wait to fix if [~vinodkone] is 
going to change the text


> Design the improvement of the home page of mesos.apache.org
> ---
>
> Key: MESOS-5430
> URL: https://issues.apache.org/jira/browse/MESOS-5430
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Vinod Kone
>Assignee: Jonathan Manalus
> Attachments: page_1.png, page_2.png
>
>
> The idea is to come up with a minimal improvement for the design of the home 
> page of mesos.apache.org.
> Proposed Redesign: https://invis.io/CV7DZF1JW#/159898819_Mesos-apache-org



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

[jira] [Commented] (MESOS-5430) Design the improvement of the home page of mesos.apache.org

[haosdent (JIRA)]

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

haosdent commented on MESOS-5430:
-

Github page recovered, so could check out it from 
http://blog.haosdent.me/mesos-site-demo/source/ directly :-) . [~jmanalus] 
[~vinodkone] 

> Design the improvement of the home page of mesos.apache.org
> ---
>
> Key: MESOS-5430
> URL: https://issues.apache.org/jira/browse/MESOS-5430
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Vinod Kone
>Assignee: Jonathan Manalus
> Attachments: page_1.png, page_2.png
>
>
> The idea is to come up with a minimal improvement for the design of the home 
> page of mesos.apache.org.
> Proposed Redesign: https://invis.io/CV7DZF1JW#/159898819_Mesos-apache-org



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

[jira] [Commented] (MESOS-5272) Support docker image labels.

[Jie Yu (JIRA)]

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

Jie Yu commented on MESOS-5272:
---

commit 13d10ac859c632d080fe15ce980c77e1cef92625
Author: Gilbert Song 
Date:   Wed May 25 09:10:26 2016 -0700

Modified docker spec test for docker label support.

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

commit 4f0e9ae796e03c174af7ad95f1ee18665e30c029
Author: Gilbert Song 
Date:   Wed May 25 09:05:55 2016 -0700

Implemented parsing docker labels in v1 spec.

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

commit 5c383537c643bb4fbb742005cacb2085e32566b9
Author: Gilbert Song 
Date:   Wed May 25 09:05:52 2016 -0700

Added labels to docker v1 spec config.

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

> Support docker image labels.
> 
>
> Key: MESOS-5272
> URL: https://issues.apache.org/jira/browse/MESOS-5272
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Gilbert Song
>Assignee: Gilbert Song
>  Labels: containerizer, gpu, mesosphere
> Fix For: 0.29.0
>
>
> Docker image labels should be supported in unified containerizer, which can 
> be used for applying custom metadata. Image labels are necessary for mesos 
> features to support docker in unified containerizer (e.g., for mesos GPU 
> device isolator).



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

[jira] [Commented] (MESOS-2082) Update the webui to include maintenance information.

[Shuai Lin (JIRA)]

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

Shuai Lin commented on MESOS-2082:
--

Hi [~bmahler] I'd like to start work on this ticket, could you shepherd it, or 
recommend someone who can do that?

> Update the webui to include maintenance information.
> 
>
> Key: MESOS-2082
> URL: https://issues.apache.org/jira/browse/MESOS-2082
> Project: Mesos
>  Issue Type: Task
>  Components: webui
>Reporter: Benjamin Mahler
>  Labels: mesosphere, twitter
>
> The simplest thing here would probably be to include another tab in the 
> header for maintenance information.
> We could also consider adding maintenance information inline to the slaves 
> table. Depending on how this is done, the maintenance tab could actually be a 
> subset of the slaves table; only those slaves for which there is maintenance 
> information.



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

[jira] [Assigned] (MESOS-2082) Update the webui to include maintenance information.

[Shuai Lin (JIRA)]

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

Shuai Lin reassigned MESOS-2082:


Assignee: Shuai Lin

> Update the webui to include maintenance information.
> 
>
> Key: MESOS-2082
> URL: https://issues.apache.org/jira/browse/MESOS-2082
> Project: Mesos
>  Issue Type: Task
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Shuai Lin
>  Labels: mesosphere, twitter
>
> The simplest thing here would probably be to include another tab in the 
> header for maintenance information.
> We could also consider adding maintenance information inline to the slaves 
> table. Depending on how this is done, the maintenance tab could actually be a 
> subset of the slaves table; only those slaves for which there is maintenance 
> information.



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

[jira] [Commented] (MESOS-5430) Design the improvement of the home page of mesos.apache.org

[haosdent (JIRA)]

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

haosdent commented on MESOS-5430:
-

Hi, [~jmanalus][~vinodkone] Because the github page still down now, I could not 
show the live demo in http://blog.haosdent.me/mesos-site-demo/source/ . But I 
upload the screenshots to 
https://issues.apache.org/jira/secure/attachment/12806147/page_1.png and 
https://issues.apache.org/jira/secure/attachment/12806147/page_2.png which take 
from my local Mac. May you help review them? Thank you in advance. 
!https://issues.apache.org/jira/secure/attachment/12806147/page_1.png|width=800px!
!https://issues.apache.org/jira/secure/attachment/12806149/page_2.png|width=800px!

> Design the improvement of the home page of mesos.apache.org
> ---
>
> Key: MESOS-5430
> URL: https://issues.apache.org/jira/browse/MESOS-5430
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Vinod Kone
>Assignee: Jonathan Manalus
> Attachments: page_1.png, page_2.png
>
>
> The idea is to come up with a minimal improvement for the design of the home 
> page of mesos.apache.org.
> Proposed Redesign: https://invis.io/CV7DZF1JW#/159898819_Mesos-apache-org



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

[jira] [Updated] (MESOS-5430) Design the improvement of the home page of mesos.apache.org

[haosdent (JIRA)]

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

haosdent updated MESOS-5430:

Attachment: page_2.png

> Design the improvement of the home page of mesos.apache.org
> ---
>
> Key: MESOS-5430
> URL: https://issues.apache.org/jira/browse/MESOS-5430
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Vinod Kone
>Assignee: Jonathan Manalus
> Attachments: page_1.png, page_2.png
>
>
> The idea is to come up with a minimal improvement for the design of the home 
> page of mesos.apache.org.
> Proposed Redesign: https://invis.io/CV7DZF1JW#/159898819_Mesos-apache-org



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

[jira] [Updated] (MESOS-5430) Design the improvement of the home page of mesos.apache.org

[haosdent (JIRA)]

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

haosdent updated MESOS-5430:

Attachment: (was: page_2.png)

> Design the improvement of the home page of mesos.apache.org
> ---
>
> Key: MESOS-5430
> URL: https://issues.apache.org/jira/browse/MESOS-5430
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Vinod Kone
>Assignee: Jonathan Manalus
> Attachments: page_1.png
>
>
> The idea is to come up with a minimal improvement for the design of the home 
> page of mesos.apache.org.
> Proposed Redesign: https://invis.io/CV7DZF1JW#/159898819_Mesos-apache-org



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

[jira] [Updated] (MESOS-5430) Design the improvement of the home page of mesos.apache.org

[haosdent (JIRA)]

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

haosdent updated MESOS-5430:

Attachment: page_2.png
page_1.png

> Design the improvement of the home page of mesos.apache.org
> ---
>
> Key: MESOS-5430
> URL: https://issues.apache.org/jira/browse/MESOS-5430
> Project: Mesos
>  Issue Type: Improvement
>  Components: project website
>Reporter: Vinod Kone
>Assignee: Jonathan Manalus
> Attachments: page_1.png
>
>
> The idea is to come up with a minimal improvement for the design of the home 
> page of mesos.apache.org.
> Proposed Redesign: https://invis.io/CV7DZF1JW#/159898819_Mesos-apache-org



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

[jira] [Commented] (MESOS-3302) Scheduler API v1 improvements

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar commented on MESOS-3302:
---

Jay Guo Thanks for testing out the new API. Here are the answer to your queries:
* Restart leading master
** For a non HA cluster, the behavior is expected. The scheduler library does 
not currently follow a redirect but merely relies on the detector to let it 
know of a new master. So, the behavior is expected and correctly works for a HA 
cluster as you pointed out.
** We want to fix the behavior i.e. ensure there is a delay upon 
(re-)connection. https://issues.apache.org/jira/browse/MESOS-5359

* Restart agent
** Currently, the long lived framework does not support moving existing tasks 
across agents. However, it would be good to test that the executor is correctly 
recovered upon agent restart with checkpointing enabled. If checkpointing is 
disabled, it should kill itself.
** Also, restarting the agent with --http_command_executor enabled/disabled, 
should still successfully recover all the executors.

* Emulate network partitions
** I am assuming that when you say "the framework hangs", you just means that 
it does not have anything to do?
** "However there was once that agent keeps launching new tasks without 
framework being aware of it during partition."
This is expected. If a framework is partitioned from the master after sending 
LAUNCH messages, the agent would still go ahead and launch them. The framework 
would receive the status updates for the running tasks upon re-registering 
since then agent keeps retrying the updates every 10 mins. We currently do not 
implement any reconciliation in the long running framework.
** Also, it would be good to test the other one way partition, i.e. the 
framework is partitioned away from the master.

To reduce noise here on this improvement JIRA, we should create a google doc 
with the testing details and link it to the JIRA? I would also add the testing 
details done by me to that doc and consolidate them at one place. If it's 
easier for you, I can create the doc myself and you can then add the details to 
it. Let me know what works for you.

> Scheduler API v1 improvements
> -
>
> Key: MESOS-3302
> URL: https://issues.apache.org/jira/browse/MESOS-3302
> Project: Mesos
>  Issue Type: Epic
>Reporter: Marco Massenzio
>  Labels: mesosphere, twitter
>
> This Epic covers all the refinements that we may want to build on top of the 
> {{HTTP API}} MVP epic (MESOS-2288) which was released initially with Mesos 
> {{0.24.0}}.
> The tasks/stories here cover the necessary work to bring the API v1 to what 
> we would regard as "Production-ready" state in preparation for the {{1.0.0}} 
> release.



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

[jira] [Issue Comment Deleted] (MESOS-3302) Scheduler API v1 improvements

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar updated MESOS-3302:
--
Comment: was deleted

(was: [~guoger] Thanks for testing out the new API. Here are the answer to your 
queries:

- Restart leading master
  - For a non HA cluster, the behavior is expected. The scheduler library does 
not currently follow a redirect but merely relies on the {{detector}} to let it 
know of a new master. So, the behavior is expected and correctly works for a HA 
cluster as you pointed out.
  - We want to fix the behavior i.e. ensure there is a delay upon 
(re-)connection. https://issues.apache.org/jira/browse/MESOS-5359

- Restart agent
- Currently, the long lived framework does not support moving existing tasks 
across agents. However, it would be good to test that the executor is correctly 
recovered upon agent restart with checkpointing enabled. If checkpointing is 
disabled, it should kill itself.
- Also, restarting the agent with {{--http_command_executor}} enabled/disabled, 
should still successfully recover all the executors.

- Emulate network partitions
  -  I am assuming that when you say "the framework hangs", you just means that 
it does not have anything to do?
  - "However there was once that agent keeps launching new tasks without 
framework being aware of it during partition."
  This is expected. If a framework is partitioned from the master after 
sending  {{LAUNCH}} messages, the agent would still go ahead and launch them. 
The framework would receive the status updates for the running tasks upon 
re-registering since then agent keeps retrying the updates every 10 mins. We 
currently do not implement any reconciliation in the long running framework.
  - Also, it would be good to test the other one way partition, i.e. the 
framework is partitioned away from the master.

Also, to reduce noise here on this improvement JIRA, we should create a google 
doc with the testing details and link it to the JIRA? I would also add the 
testing details done by me to that doc and consolidate them at one place. If 
it's easier for you, I can create the doc myself and you can then add the 
details to it. Let me know what works for you.
)

> Scheduler API v1 improvements
> -
>
> Key: MESOS-3302
> URL: https://issues.apache.org/jira/browse/MESOS-3302
> Project: Mesos
>  Issue Type: Epic
>Reporter: Marco Massenzio
>  Labels: mesosphere, twitter
>
> This Epic covers all the refinements that we may want to build on top of the 
> {{HTTP API}} MVP epic (MESOS-2288) which was released initially with Mesos 
> {{0.24.0}}.
> The tasks/stories here cover the necessary work to bring the API v1 to what 
> we would regard as "Production-ready" state in preparation for the {{1.0.0}} 
> release.



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

[jira] [Commented] (MESOS-3302) Scheduler API v1 improvements

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar commented on MESOS-3302:
---

[~guoger] Thanks for testing out the new API. Here are the answer to your 
queries:

- Restart leading master
  - For a non HA cluster, the behavior is expected. The scheduler library does 
not currently follow a redirect but merely relies on the {{detector}} to let it 
know of a new master. So, the behavior is expected and correctly works for a HA 
cluster as you pointed out.
  - We want to fix the behavior i.e. ensure there is a delay upon 
(re-)connection. https://issues.apache.org/jira/browse/MESOS-5359

- Restart agent
- Currently, the long lived framework does not support moving existing tasks 
across agents. However, it would be good to test that the executor is correctly 
recovered upon agent restart with checkpointing enabled. If checkpointing is 
disabled, it should kill itself.
- Also, restarting the agent with {{--http_command_executor}} enabled/disabled, 
should still successfully recover all the executors.

- Emulate network partitions
  -  I am assuming that when you say "the framework hangs", you just means that 
it does not have anything to do?
  - "However there was once that agent keeps launching new tasks without 
framework being aware of it during partition."
  This is expected. If a framework is partitioned from the master after 
sending  {{LAUNCH}} messages, the agent would still go ahead and launch them. 
The framework would receive the status updates for the running tasks upon 
re-registering since then agent keeps retrying the updates every 10 mins. We 
currently do not implement any reconciliation in the long running framework.
  - Also, it would be good to test the other one way partition, i.e. the 
framework is partitioned away from the master.

Also, to reduce noise here on this improvement JIRA, we should create a google 
doc with the testing details and link it to the JIRA? I would also add the 
testing details done by me to that doc and consolidate them at one place. If 
it's easier for you, I can create the doc myself and you can then add the 
details to it. Let me know what works for you.


> Scheduler API v1 improvements
> -
>
> Key: MESOS-3302
> URL: https://issues.apache.org/jira/browse/MESOS-3302
> Project: Mesos
>  Issue Type: Epic
>Reporter: Marco Massenzio
>  Labels: mesosphere, twitter
>
> This Epic covers all the refinements that we may want to build on top of the 
> {{HTTP API}} MVP epic (MESOS-2288) which was released initially with Mesos 
> {{0.24.0}}.
> The tasks/stories here cover the necessary work to bring the API v1 to what 
> we would regard as "Production-ready" state in preparation for the {{1.0.0}} 
> release.



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

[jira] [Commented] (MESOS-3302) Scheduler API v1 improvements

[Jay Guo (JIRA)]

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

Jay Guo commented on MESOS-3302:


[~vinodkone]

We are manually testing HTTP APIs now and here are some observations:

*Cluster setup:*
* Bring up 3 masters, 3 agents, 3 zookeepers
* Agents should be started with --use_http_command_executor flag (which uses 
http command executor)
* Start long lived framework (which uses http scheduler api)

*Test cases:*
* Restart leading master
_The framework is started with {{--master=}}. Therefore, it always 
talks to fixed master no matter being leader or follower._ 
*Expected:* {{307 Temporary Redirect}} and scheduler actually handles redirect 
and talks to real leader master, and these should be transparent to framework
*Actual:* It reports this back to framework.
Is this intended behaviour? On the other hand, when framework is started with 
--master=zk://... it correctly handles master detection and resumes when new 
leader master is elected. Although master detection happens continuously 
without a break. Do we consider to introduce an interval?

* Restart agent
*Expected:* Workload is migrated to other agents if current agent is down for a 
period longer than timeout, therefore removed. If agent is resurrected within 
the timeout, it resumes the tasks.
*Actual:* Framework keeps waiting for the agent to recover. It does resume 
working if agent is back in time. Otherwise, it keeps waiting indefinitely.
I guess this is reasonable since that long-lived-framework declines other 
offers, which will not be offered again to this framework. I don't see there's 
an option to expire the decline-offer-filter though, or am I missing something?
There are also chances that the agent resumes running tasks for a little while 
and then _asked to terminate_ by master. This is somewhat flaky, need to 
investigate further.

* Restart long lived framework
*Expected:* Recover
*Actual:* Recover

* Restart all masters at once
Same behaviour as _restarting leading master_

* Emulate network partitions (1 way - 2 way) between long lived framework and 
master
_network partition is emulated at tcp layer using iptables rule {{iptables -A 
INPUT -p tcp -s  -dport 5050 -j DROP}}
** One-way: Master <--X-- Framework
For most cases it works as expected: framework simply hangs. Agent keeps 
resending messages since acknowledgements are blocked. When block is lifted, 
everything resumes to work. However there was once that agent keeps launching 
new tasks without framework being aware of it during partition. Need to find a 
way to reproduce it. I guess it has something to do with the status when 
network is cut.
** Two-way: WIP

* Restart leading Zookeeper
WIP

* Restart all Zookeepers at once
WIP

> Scheduler API v1 improvements
> -
>
> Key: MESOS-3302
> URL: https://issues.apache.org/jira/browse/MESOS-3302
> Project: Mesos
>  Issue Type: Epic
>Reporter: Marco Massenzio
>  Labels: mesosphere, twitter
>
> This Epic covers all the refinements that we may want to build on top of the 
> {{HTTP API}} MVP epic (MESOS-2288) which was released initially with Mesos 
> {{0.24.0}}.
> The tasks/stories here cover the necessary work to bring the API v1 to what 
> we would regard as "Production-ready" state in preparation for the {{1.0.0}} 
> release.



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

[jira] [Created] (MESOS-5452) Modules should be initialized before all components except firewall.

[Avinash Sridharan (JIRA)]

Avinash Sridharan created MESOS-5452:


 Summary: Modules should be initialized before all components 
except firewall.
 Key: MESOS-5452
 URL: https://issues.apache.org/jira/browse/MESOS-5452
 Project: Mesos
  Issue Type: Improvement
  Components: containerization
 Environment: Linux
Reporter: Avinash Sridharan
Assignee: Avinash Sridharan
 Fix For: 0.29.0


Anonymous modules should not have any dependencies, by design, on any other 
Mesos components. This implies that Anonymous modules should be initialized 
before all other Mesos components other than `Firewall`. The dependency on 
`Firewall` is primarily to enforce any policies to secure endpoints that might 
be owned by the Anonymous module.



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

[jira] [Commented] (MESOS-5414) configure failed on ubuntu and centos

[Till Toenshoff (JIRA)]

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

Till Toenshoff commented on MESOS-5414:
---

{noformat}
commit 9b2c2b201c809047f53f19289631366e8d836162
Author: Kevin Klues 
Date:   Wed May 25 12:30:33 2016 +0200

Reverted adding libelf as a default dynamic library in libprocess.

The libelf library is not a standard library installed on all Linux
systems, and it is not a library required to build libprocess in
general. It is only required for subsystems that happen to use the
 header. As such, we should only require this
dependency for those specific subsystems. If we ever decide to build
something into libprocess that depends on libelf by default, we can
revisit this issue then.

Review: https://reviews.apache.org/r/47609/
{noformat}

{noformat}

commit b771a90d97929fd97a803c3d6341d86313e3dd44
Author: Kevin Klues 
Date:   Wed May 25 12:30:40 2016 +0200

Reverted adding libelf as a default dynamic library in stout.

The libelf library is not a standard library installed on all Linux
systems, and it is not a library required to build stout in
general. It is only required for subsystems that happen to use the
 header. As such, we should only require this
dependency for those specific subsystems. If we ever decide to build
something into stout that depends on libelf by default, we can
revisit this issue then.

Review: https://reviews.apache.org/r/47610/
{noformat}


> configure failed on ubuntu and centos
> -
>
> Key: MESOS-5414
> URL: https://issues.apache.org/jira/browse/MESOS-5414
> Project: Mesos
>  Issue Type: Bug
>Reporter: Guangya Liu
>Assignee: Kevin Klues
>Priority: Blocker
> Fix For: 0.29.0
>
>
> Check out latest code.
> {code}
> ./bootstrap
> mkdir build
> cd build
> ../configure
> checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
> checking if more special flags are required for pthreads... no
> checking for PTHREAD_PRIO_INHERIT... yes
> configure: Setting up build environment for x86_64 linux-gnu
> checking for backtrace in -lunwind... no
> checking for main in -lgflags... no
> checking for gzread in -lz... no
> configure: error: cannot find libz
> ---
> libz is required for mesos to build.
> ---
> {code}
> Seems this was caused by https://reviews.apache.org/r/47484/ cc [~bmahler] 
> [~klueska]



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

[jira] [Commented] (MESOS-4909) Introduce kill policy for tasks.

[Jesada Gonkratoke (JIRA)]

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

Jesada Gonkratoke commented on MESOS-4909:
--

Hi, Mesos Team
I would like to know, when will you publish this version 0.29.0, I encountered 
with grateful shutdown problem on docker, I really need the resolving solution.

Thank you.
Jesada

> Introduce kill policy for tasks.
> 
>
> Key: MESOS-4909
> URL: https://issues.apache.org/jira/browse/MESOS-4909
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Alexander Rukletsov
>Assignee: Alexander Rukletsov
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> A task may require some time to clean up or even a special mechanism to issue 
> a kill request (currently it's a SIGTERM followed by SIGKILL). Introducing 
> kill policies per task will help address these issue.



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

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

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5293:
--

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

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



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

[jira] [Updated] (MESOS-5150) Authorize Agent HTTP Endpoints

[Adam B (JIRA)]

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

Adam B updated MESOS-5150:
--
Fix Version/s: 0.29.0

> Authorize Agent HTTP Endpoints
> --
>
> Key: MESOS-5150
> URL: https://issues.apache.org/jira/browse/MESOS-5150
> Project: Mesos
>  Issue Type: Epic
>  Components: security, slave
>Reporter: Adam B
>Assignee: Alexander Rojas
>  Labels: agent, authorization, mesosphere, security, slave
> Fix For: 0.29.0
>
>
> As we add authentication in agent http endpoint handlers in MESOS-4847, we 
> now have the opportunity to perform ACL-based authorization on these 
> endpoints.
> Most important is the authorization of the /files endpoints, as those allow 
> access to executor sandboxes (and agent logs), and the operator may wish to 
> control which users may access which sandboxes.
> Similarly, the operator may only want certain users to be able to view agent 
> flags, change logging level, enable the profiler, etc.



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

[jira] [Updated] (MESOS-5450) Make the SASL dependency optional.

[Alex Clemmer (JIRA)]

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

Alex Clemmer updated MESOS-5450:

Summary: Make the SASL dependency optional.  (was: Make authentication 
pluggable)

> Make the SASL dependency optional.
> --
>
> Key: MESOS-5450
> URL: https://issues.apache.org/jira/browse/MESOS-5450
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>  Labels: mesosphere
>
> Right now there is a hard dependency on SASL, which probably won't work well 
> on Windows (at least) in the near future for our use cases.
> In the future, it would be nice to have a pluggable authentication layer.



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

[jira] [Commented] (MESOS-5450) Make authentication pluggable

[Alex Clemmer (JIRA)]

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

Alex Clemmer commented on MESOS-5450:
-

Ah, yes, that's correct. What we're really trying to do is shed the hard SASL 
dependency. Thanks [~vinodkone]! :)

> Make authentication pluggable
> -
>
> Key: MESOS-5450
> URL: https://issues.apache.org/jira/browse/MESOS-5450
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>  Labels: mesosphere
>
> Right now there is a hard dependency on SASL, which probably won't work well 
> on Windows (at least) in the near future for our use cases.
> In the future, it would be nice to have a pluggable authentication layer.



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

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

[Adam B (JIRA)]

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

Adam B commented on MESOS-5406:
---

cc: [~vinodkone]

> 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
>  Components: security
>Reporter: Alexander Rukletsov
>Assignee: Jay Guo
>  Labels: mesosphere, security
>
> 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-5451) Show Framework ID in log for long-lived-framework

[Jay Guo (JIRA)]

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

Jay Guo commented on MESOS-5451:


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

> Show Framework ID in log for long-lived-framework
> -
>
> Key: MESOS-5451
> URL: https://issues.apache.org/jira/browse/MESOS-5451
> Project: Mesos
>  Issue Type: Bug
>  Components: framework
>Reporter: Jay Guo
>Assignee: Jay Guo
>Priority: Trivial
>
> In long-lived-framework, framework id is not shown if registered for the 
> first time.



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

[jira] [Created] (MESOS-5451) Show Framework ID in log for long-lived-framework

[Jay Guo (JIRA)]

Jay Guo created MESOS-5451:
--

 Summary: Show Framework ID in log for long-lived-framework
 Key: MESOS-5451
 URL: https://issues.apache.org/jira/browse/MESOS-5451
 Project: Mesos
  Issue Type: Bug
  Components: framework
Reporter: Jay Guo
Assignee: Jay Guo
Priority: Trivial


In long-lived-framework, framework id is not shown if registered for the first 
time.



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

[jira] [Comment Edited] (MESOS-5380) Killing a queued task can cause the corresponding command executor to never terminate.

[Vinod Kone (JIRA)]

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

Vinod Kone edited comment on MESOS-5380 at 5/25/16 6:30 AM:


Backported the fixes to 0.28.x.

commit b52a41df090fdf15c65e01805adbb6795bc34e78
Author: Vinod Kone 
Date:   Sun May 15 12:31:31 2016 -0700

Fixed agent to properly handle killTask during agent restart.

***Modified for 0.28.2***

If the agent restarts after handling killTask but before sending
shutdown message to the executor, we ensure the executor terminates.

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

commit 8f73932f851096a2d1fdcd72b239be1e2e53cc58
Author: Vinod Kone 
Date:   Fri May 13 16:06:49 2016 -0700

Fixed agent to properly handle killTask of unregistered executor.

***Modified for 0.28.2***

The agent now shuts down the executor during registration if it does not
have any queued tasks (e.g., framework sent a killTask before
registration).

Note that if the executor doesn't register at all, it will be cleaned up
anyway after the registration timeout value.

Also, note that this doesn't handle the case where the agent restarts
after processing the killTask() but before cleaning up the executor.

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



was (Author: vinodkone):
Backported the fix to 0.28.x.

> Killing a queued task can cause the corresponding command executor to never 
> terminate.
> --
>
> Key: MESOS-5380
> URL: https://issues.apache.org/jira/browse/MESOS-5380
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>Affects Versions: 0.28.0, 0.28.1
>Reporter: Jie Yu
>Assignee: Vinod Kone
>Priority: Blocker
>  Labels: mesosphere
> Fix For: 0.29.0, 0.28.2
>
>
> We observed this in our testing environment. Sequence of events:
> 1) A command task is queued since the executor has not registered yet.
> 2) The framework issues a killTask.
> 3) Since executor is in REGISTERING state, agent calls 
> `statusUpdate(TASK_KILLED, UPID())`
> 4) `statusUpdate` now will call `containerizer->status()` before calling 
> `executor->terminateTask(status.task_id(), status);` which will remove the 
> queued task. (Introduced in this patch: https://reviews.apache.org/r/43258).
> 5) Since the above is async, it's possible that the task is still in queued 
> task when we trying to see if we need to kill unregistered executor in 
> `killTask`:
> {code}
>   // TODO(jieyu): Here, we kill the executor if it no longer has
>   // any task to run and has not yet registered. This is a
>   // workaround for those single task executors that do not have a
>   // proper self terminating logic when they haven't received the
>   // task within a timeout.
>   if (executor->queuedTasks.empty()) {
> CHECK(executor->launchedTasks.empty())
> << " Unregistered executor '" << executor->id
> << "' has launched tasks";
> LOG(WARNING) << "Killing the unregistered executor " << *executor
>  << " because it has no tasks";
> executor->state = Executor::TERMINATING;
> containerizer->destroy(executor->containerId);
>   }
> {code}
> 6) Consequently, the executor will never be terminated by Mesos.
> Attaching the relevant agent log:
> {noformat}
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal mesos-slave[1304]: 
> I0513 15:36:13.640527  1342 slave.cpp:1361] Got assigned task 
> mesosvol.6ccd993c-1920-11e6-a722-9648cb19afd6 for framework 
> a3ad8418-cb77-4705-b353-4b514ceca52c-
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal mesos-slave[1304]: 
> I0513 15:36:13.641034  1342 slave.cpp:1480] Launching task 
> mesosvol.6ccd993c-1920-11e6-a722-9648cb19afd6 for framework 
> a3ad8418-cb77-4705-b353-4b514ceca52c-
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal mesos-slave[1304]: 
> I0513 15:36:13.641440  1342 paths.cpp:528] Trying to chown 
> '/var/lib/mesos/slave/slaves/a3ad8418-cb77-4705-b353-4b514ceca52c-S0/frameworks/a3ad8418-cb77-4705-b353-4b514ceca52c-/executors/mesosvol.6ccd993c-1920-11e6-a722-9648cb19afd6/runs/24762d43-2134-475e-b724-caa72110497a'
>  to user 'root'
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal mesos-slave[1304]: 
> I0513 15:36:13.644664  1342 slave.cpp:5389] Launching executor 
> mesosvol.6ccd993c-1920-11e6-a722-9648cb19afd6 of framework 
> a3ad8418-cb77-4705-b353-4b514ceca52c- with resources cpus(*):0.1; 
> mem(*):32 in work directory 
> 

[jira] [Commented] (MESOS-5380) Killing a queued task can cause the corresponding command executor to never terminate.

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-5380:
---

Backported the fix to 0.28.x.

> Killing a queued task can cause the corresponding command executor to never 
> terminate.
> --
>
> Key: MESOS-5380
> URL: https://issues.apache.org/jira/browse/MESOS-5380
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>Affects Versions: 0.28.0, 0.28.1
>Reporter: Jie Yu
>Assignee: Vinod Kone
>Priority: Blocker
>  Labels: mesosphere
> Fix For: 0.29.0, 0.28.2
>
>
> We observed this in our testing environment. Sequence of events:
> 1) A command task is queued since the executor has not registered yet.
> 2) The framework issues a killTask.
> 3) Since executor is in REGISTERING state, agent calls 
> `statusUpdate(TASK_KILLED, UPID())`
> 4) `statusUpdate` now will call `containerizer->status()` before calling 
> `executor->terminateTask(status.task_id(), status);` which will remove the 
> queued task. (Introduced in this patch: https://reviews.apache.org/r/43258).
> 5) Since the above is async, it's possible that the task is still in queued 
> task when we trying to see if we need to kill unregistered executor in 
> `killTask`:
> {code}
>   // TODO(jieyu): Here, we kill the executor if it no longer has
>   // any task to run and has not yet registered. This is a
>   // workaround for those single task executors that do not have a
>   // proper self terminating logic when they haven't received the
>   // task within a timeout.
>   if (executor->queuedTasks.empty()) {
> CHECK(executor->launchedTasks.empty())
> << " Unregistered executor '" << executor->id
> << "' has launched tasks";
> LOG(WARNING) << "Killing the unregistered executor " << *executor
>  << " because it has no tasks";
> executor->state = Executor::TERMINATING;
> containerizer->destroy(executor->containerId);
>   }
> {code}
> 6) Consequently, the executor will never be terminated by Mesos.
> Attaching the relevant agent log:
> {noformat}
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal mesos-slave[1304]: 
> I0513 15:36:13.640527  1342 slave.cpp:1361] Got assigned task 
> mesosvol.6ccd993c-1920-11e6-a722-9648cb19afd6 for framework 
> a3ad8418-cb77-4705-b353-4b514ceca52c-
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal mesos-slave[1304]: 
> I0513 15:36:13.641034  1342 slave.cpp:1480] Launching task 
> mesosvol.6ccd993c-1920-11e6-a722-9648cb19afd6 for framework 
> a3ad8418-cb77-4705-b353-4b514ceca52c-
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal mesos-slave[1304]: 
> I0513 15:36:13.641440  1342 paths.cpp:528] Trying to chown 
> '/var/lib/mesos/slave/slaves/a3ad8418-cb77-4705-b353-4b514ceca52c-S0/frameworks/a3ad8418-cb77-4705-b353-4b514ceca52c-/executors/mesosvol.6ccd993c-1920-11e6-a722-9648cb19afd6/runs/24762d43-2134-475e-b724-caa72110497a'
>  to user 'root'
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal mesos-slave[1304]: 
> I0513 15:36:13.644664  1342 slave.cpp:5389] Launching executor 
> mesosvol.6ccd993c-1920-11e6-a722-9648cb19afd6 of framework 
> a3ad8418-cb77-4705-b353-4b514ceca52c- with resources cpus(*):0.1; 
> mem(*):32 in work directory 
> '/var/lib/mesos/slave/slaves/a3ad8418-cb77-4705-b353-4b514ceca52c-S0/frameworks/a3ad8418-cb77-4705-b353-4b514ceca52c-/executors/mesosvol.6ccd993c-1920-11e6-a722-9648cb19afd6/runs/24762d43-2134-475e-b724-caa72110497a'
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal mesos-slave[1304]: 
> I0513 15:36:13.645195  1342 slave.cpp:1698] Queuing task 
> 'mesosvol.6ccd993c-1920-11e6-a722-9648cb19afd6' for executor 
> 'mesosvol.6ccd993c-1920-11e6-a722-9648cb19afd6' of framework 
> a3ad8418-cb77-4705-b353-4b514ceca52c-
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal mesos-slave[1304]: 
> I0513 15:36:13.645491  1338 containerizer.cpp:671] Starting container 
> '24762d43-2134-475e-b724-caa72110497a' for executor 
> 'mesosvol.6ccd993c-1920-11e6-a722-9648cb19afd6' of framework 
> 'a3ad8418-cb77-4705-b353-4b514ceca52c-'
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal mesos-slave[1304]: 
> I0513 15:36:13.647897  1345 cpushare.cpp:389] Updated 'cpu.shares' to 1126 
> (cpus 1.1) for container 24762d43-2134-475e-b724-caa72110497a
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal mesos-slave[1304]: 
> I0513 15:36:13.648619  1345 cpushare.cpp:411] Updated 'cpu.cfs_period_us' to 
> 100ms and 'cpu.cfs_quota_us' to 110ms (cpus 1.1) for container 
> 24762d43-2134-475e-b724-caa72110497a
> May 13 15:36:13 ip-10-0-2-74.us-west-2.compute.internal 

[jira] [Commented] (MESOS-5450) Make authentication pluggable

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-5450:
---

Authentication is pluggable. But I guess we still depend on SASL? cc [~tillt]

> Make authentication pluggable
> -
>
> Key: MESOS-5450
> URL: https://issues.apache.org/jira/browse/MESOS-5450
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>  Labels: mesosphere
>
> Right now there is a hard dependency on SASL, which probably won't work well 
> on Windows (at least) in the near future for our use cases.
> In the future, it would be nice to have a pluggable authentication layer.



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

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

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5293:


Assignee: Abhishek Dasgupta

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



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

[jira] [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:
--
Shepherd: Adam B

> 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: 0.29.0
>Reporter: Benjamin Bannier
>Priority: Minor
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> 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-4931) Authorization based filtering for endpoints.

[Adam B (JIRA)]

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

Adam B updated MESOS-4931:
--
Shepherd: Michael Park  (was: Adam B)

> Authorization based filtering for endpoints.
> 
>
> Key: MESOS-4931
> URL: https://issues.apache.org/jira/browse/MESOS-4931
> Project: Mesos
>  Issue Type: Epic
>  Components: security
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>  Labels: authorization, mesosphere, security
> Fix For: 0.29.0
>
>
> Some endpoints such as /state should be filtered depending on which 
> information the user is authorized to see. For example a user should be only 
> able to see tasks he is authorized to see.



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

[jira] [Updated] (MESOS-5168) Benchmark overhead of authorization based filtering.

[Adam B (JIRA)]

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

Adam B updated MESOS-5168:
--
Shepherd: Michael Park  (was: Adam B)

> Benchmark overhead of authorization based filtering.
> 
>
> Key: MESOS-5168
> URL: https://issues.apache.org/jira/browse/MESOS-5168
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>  Labels: authorization, mesosphere, security
> Fix For: 0.29.0
>
>
> When adding authorization based filtering as outlined in MESOS-4931 we need 
> to be careful especially for performance critical endpoints such as /state.
> We should ensure via a benchmark that performance does not degreade below an 
> acceptable state.



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

[jira] [Updated] (MESOS-5169) Introduce new Authorizer Actions for Authorized based filtering of endpoints.

[Adam B (JIRA)]

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

Adam B updated MESOS-5169:
--
Shepherd: Michael Park  (was: Adam B)

> Introduce new Authorizer Actions for Authorized based filtering of endpoints.
> -
>
> Key: MESOS-5169
> URL: https://issues.apache.org/jira/browse/MESOS-5169
> Project: Mesos
>  Issue Type: Improvement
>  Components: security
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>  Labels: authorization, mesosphere, security
> Fix For: 0.29.0
>
>
> For authorization based endpoint filtering we need to introduce the 
> authorizer actions outlined via MESOS-4932.



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