[jira] [Assigned] (MESOS-6703) Port `credentials_tests.cpp`

2017-09-13 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer reassigned MESOS-6703:
---

Assignee: John Kordich  (was: Andrew Schwartzmeyer)

> Port `credentials_tests.cpp`
> 
>
> Key: MESOS-6703
> URL: https://issues.apache.org/jira/browse/MESOS-6703
> Project: Mesos
>  Issue Type: Bug
>  Components: agent
>Reporter: Alex Clemmer
>Assignee: John Kordich
>  Labels: microsoft, windows-mvp
>




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

[jira] [Assigned] (MESOS-6697) Port `authentication_tests.cpp`

2017-09-13 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer reassigned MESOS-6697:
---

Assignee: John Kordich  (was: Andrew Schwartzmeyer)

> Port `authentication_tests.cpp`
> ---
>
> Key: MESOS-6697
> URL: https://issues.apache.org/jira/browse/MESOS-6697
> Project: Mesos
>  Issue Type: Bug
>  Components: agent
>Reporter: Alex Clemmer
>Assignee: John Kordich
>  Labels: microsoft, windows-mvp
>




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

[jira] [Assigned] (MESOS-6702) Port `cram_md5_authentication_tests.cpp`

2017-09-13 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer reassigned MESOS-6702:
---

Assignee: John Kordich  (was: Andrew Schwartzmeyer)

> Port `cram_md5_authentication_tests.cpp`
> 
>
> Key: MESOS-6702
> URL: https://issues.apache.org/jira/browse/MESOS-6702
> Project: Mesos
>  Issue Type: Bug
>  Components: agent
>Reporter: Alex Clemmer
>Assignee: John Kordich
>  Labels: microsoft, windows-mvp
>




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

[jira] [Commented] (MESOS-3107) Define CMake style guide

2017-09-13 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer commented on MESOS-3107:
-

This has kind of been started with my Mesos Hackathon project: 
https://github.com/andschwa/mesos/blob/cmake-docs/docs/cmake.md and 
https://github.com/andschwa/mesos/blob/cmake-docs/docs/cmake-examples.md

> Define CMake style guide
> 
>
> Key: MESOS-3107
> URL: https://issues.apache.org/jira/browse/MESOS-3107
> Project: Mesos
>  Issue Type: Task
>  Components: cmake
>Reporter: Alex Clemmer
>Assignee: Andrew Schwartzmeyer
>  Labels: build, cmake
>
> The short story is that it is important to be principled about how the CMake 
> build system is maintained, because there CMake language makes it difficult 
> to statically verify that a configuration is correct. It is not unique in 
> this regard, but (make is arguably even worse) but it is something that's 
> important to make sure we get right.
> The longer story is, CMake's language is dynamically scoped and often has 
> somewhat odd defaults for variable values (_e.g._, IIRC, target names passed 
> to ExternalProject_Add default to "PREFIX" instead of erroring out). This 
> means that it is rare to get a configuration-time error (_i.e._, CMake 
> usually doesn't say something like "hey this variable isn't defined"), and in 
> large projects, this can make it very difficult to know where definitions 
> come from, or whether it's important that one config routine runs before 
> another. Dynamic scoping also makes it particularly easy to write spaghetti 
> code, which is clearly undesirable for something as important as a build 
> system.
> Thus, it is particularly important that we lay down our expectations for how 
> the CMake system is to be structured. This might include:
> * Function naming (_e.g._, making it easy to tell whether a function was 
> defined by us, and where it was defined; so we might say that we want our 
> functions to have an underscore to start, and start with the package the come 
> from, like libprocess, so that we know where to look for the definition.)
> * What assertions we want to check variable values against, so that we can 
> replace subtle errors (_e.g._, a library is accidentally named something 
> silly like "PREFIX.0.0.1") with an obvious ones (_e.g._, "You have failed to 
> define your target name, so CMake has defaulted to 'PREFIX'; please check 
> your configuration routines")
> * Decisions of what goes where. (_e.g._, the most complex parts of the CMake 
> MVPs is in the configuration routines, like `MesosConfigure.cmake`; to curb 
> this, we should have strict rules about what goes in that file vs other 
> files, and how we know what is to be run before what. Part of this should 
> probably be prominent comments explaining the structure of the project, so 
> that people aren't confused!)
> * And so on.



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

[jira] [Created] (MESOS-7976) v1/scheduler: Revive/Suppress role field should be marked experimental for 1.2.x branch

2017-09-13 Thread James DeFelice (JIRA) 
James DeFelice created MESOS-7976:
-

 Summary: v1/scheduler: Revive/Suppress role field should be marked 
experimental for 1.2.x branch
 Key: MESOS-7976
 URL: https://issues.apache.org/jira/browse/MESOS-7976
 Project: Mesos
  Issue Type: Bug
Affects Versions: 1.2.2, 1.2.1, 1.2.0
Reporter: James DeFelice
Assignee: Benjamin Mahler


The role field of the v1 scheduler API's Revive and Suppress call should have 
been marked as experimental since it was part of the experimental MULTI-ROLE 
feature. The field has replaced in 1.3.x by a "repeated string roles" field.



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

[jira] [Created] (MESOS-7975) The command/default executor can incorrectly send a TASK_FINISHED update even when the task is killed

2017-09-13 Thread Anand Mazumdar (JIRA) 
Anand Mazumdar created MESOS-7975:
-

 Summary: The command/default executor can incorrectly send a 
TASK_FINISHED update even when the task is killed
 Key: MESOS-7975
 URL: https://issues.apache.org/jira/browse/MESOS-7975
 Project: Mesos
  Issue Type: Bug
Reporter: Anand Mazumdar
Assignee: Anand Mazumdar
Priority: Critical


Currently, when a task is killed, the default and the command executor 
incorrectly send a {{TASK_FINISHED}} status update instead of {{TASK_KILLED}}. 
This is due to an unfortunate missed conditional check when the task exits with 
a zero status code.

{code}
  if (WSUCCEEDED(status)) {
taskState = TASK_FINISHED;
  } else if (killed) {
// Send TASK_KILLED if the task was killed as a result of
// kill() or shutdown().
taskState = TASK_KILLED;
  } else {
taskState = TASK_FAILED;
  }
{code}

We should modify the code to correctly send {{TASK_KILLED}} status updates when 
a task is killed.



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

[jira] [Commented] (MESOS-7962) Display task state counters in the framework page of the webui.

2017-09-13 Thread ASF GitHub Bot (JIRA) 

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

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

GitHub user janisz opened a pull request:

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

Display task state counters in the framework page.

Fixes: [MESOS-7962](https://issues.apache.org/jira/browse/MESOS-7962)


![screencapture-localhost-5050-1505334897521](https://user-images.githubusercontent.com/1616386/30399457-10e15dd2-98d4-11e7-92bb-502a1f87c3df.png)


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

$ git pull https://github.com/janisz/mesos 
MESOS-7962/Display_task_state_counters_in_the_framework_page_of_the_webui

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

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

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

This closes #234


commit c5906b08a62ade1442d435f5b7465a4031780f0d
Author: Tomasz Janiszewski 
Date:   2017-09-13T20:35:42Z

Display task state counters in the framework page.

Fixes: MESOS-7962




> Display task state counters in the framework page of the webui.
> ---
>
> Key: MESOS-7962
> URL: https://issues.apache.org/jira/browse/MESOS-7962
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Tomasz Janiszewski
>
> Currently the webui displays task state counters across all frameworks on the 
> home page, but it does not display the per-framework task state counters when 
> you click in to a particular framework. We should add the task state counters 
> to the per-framework page.



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

[jira] [Assigned] (MESOS-7962) Display task state counters in the framework page of the webui.

2017-09-13 Thread Tomasz Janiszewski (JIRA) 

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

Tomasz Janiszewski reassigned MESOS-7962:
-

Assignee: Tomasz Janiszewski

> Display task state counters in the framework page of the webui.
> ---
>
> Key: MESOS-7962
> URL: https://issues.apache.org/jira/browse/MESOS-7962
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Tomasz Janiszewski
>
> Currently the webui displays task state counters across all frameworks on the 
> home page, but it does not display the per-framework task state counters when 
> you click in to a particular framework. We should add the task state counters 
> to the per-framework page.



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

[jira] [Commented] (MESOS-7961) Display task health in the webui.

2017-09-13 Thread Tomasz Janiszewski (JIRA) 

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

Tomasz Janiszewski commented on MESOS-7961:
---

Patch: https://github.com/apache/mesos/pull/233

> Display task health in the webui.
> -
>
> Key: MESOS-7961
> URL: https://issues.apache.org/jira/browse/MESOS-7961
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Tomasz Janiszewski
>
> Currently the webui does not display task health based on the latest status 
> update. Since this information is in the protobuf, it is within the webui's 
> scope to display health information.



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

[jira] [Issue Comment Deleted] (MESOS-7961) Display task health in the webui.

2017-09-13 Thread Tomasz Janiszewski (JIRA) 

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

Tomasz Janiszewski updated MESOS-7961:
--
Comment: was deleted

(was: Patch: https://github.com/apache/mesos/pull/233)

> Display task health in the webui.
> -
>
> Key: MESOS-7961
> URL: https://issues.apache.org/jira/browse/MESOS-7961
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Tomasz Janiszewski
>
> Currently the webui does not display task health based on the latest status 
> update. Since this information is in the protobuf, it is within the webui's 
> scope to display health information.



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

[jira] [Updated] (MESOS-7968) Handle `/proc/self/ns/pid_for_children` when parsing available namespace.

2017-09-13 Thread Kapil Arya (JIRA) 

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

Kapil Arya updated MESOS-7968:
--
Summary: Handle `/proc/self/ns/pid_for_children` when parsing available 
namespace.  (was: Handle `/proc/self/ns/pid_for_children` when parsing 
available namespace)

> Handle `/proc/self/ns/pid_for_children` when parsing available namespace.
> -
>
> Key: MESOS-7968
> URL: https://issues.apache.org/jira/browse/MESOS-7968
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 1.2.3, 1.3.2, 1.5.0, 1.4.1
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>
> Since Linux 4.12, /proc/self/ns/pid_for_children is a handle for the PID 
> namespace of child processes created by this process. Since this is not a 
> namespace type in its own, we should ignore this file when listing namespaces 
> via `ls /proc/self/ns`.



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

[jira] [Commented] (MESOS-7961) Display task health in the webui.

2017-09-13 Thread ASF GitHub Bot (JIRA) 

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

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

GitHub user janisz opened a pull request:

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

Display task health in the Web UI.

Fixes: MESOS-7961


![screencapture-localhost-5050-1505329729249](https://user-images.githubusercontent.com/1616386/30395983-54332de2-98c8-11e7-8e57-a1d744bb2381.png)


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

$ git pull https://github.com/janisz/mesos 
MESOS-7961/disaply_task_health_state_in_web_UI

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

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

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

This closes #233


commit c9faf8ced314860a77a8f2742ee1db4677d0075a
Author: Tomasz Janiszewski 
Date:   2017-09-13T19:10:39Z

Display task health in the Web UI.

Fixes: MESOS-7961




> Display task health in the webui.
> -
>
> Key: MESOS-7961
> URL: https://issues.apache.org/jira/browse/MESOS-7961
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Tomasz Janiszewski
>
> Currently the webui does not display task health based on the latest status 
> update. Since this information is in the protobuf, it is within the webui's 
> scope to display health information.



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

[jira] [Assigned] (MESOS-7961) Display task health in the webui.

2017-09-13 Thread Tomasz Janiszewski (JIRA) 

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

Tomasz Janiszewski reassigned MESOS-7961:
-

Assignee: Tomasz Janiszewski

> Display task health in the webui.
> -
>
> Key: MESOS-7961
> URL: https://issues.apache.org/jira/browse/MESOS-7961
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Tomasz Janiszewski
>
> Currently the webui does not display task health based on the latest status 
> update. Since this information is in the protobuf, it is within the webui's 
> scope to display health information.



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

[jira] [Updated] (MESOS-7974) Accept "application/recordio" type is rejected for master operator API SUBSCRIBE call

2017-09-13 Thread Anand Mazumdar (JIRA) 

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

Anand Mazumdar updated MESOS-7974:
--
Target Version/s: 1.5.0

> Accept "application/recordio" type is rejected for master operator API 
> SUBSCRIBE call
> -
>
> Key: MESOS-7974
> URL: https://issues.apache.org/jira/browse/MESOS-7974
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 1.2.1
>Reporter: James DeFelice
>  Labels: mesosphere
>
> The agent operator API supports for "application/recordio" for things like 
> attach-container-output, which streams objects back to the caller. I expected 
> the master operator API SUBSCRIBE call to work the same way, w/ 
> Accept/Content-Type headers for "recordio" and 
> Message-Accept/Message-Content-Type headers for json (or protobuf). This was 
> not the case.
> Looking again at the master operator API documentation, SUBSCRIBE docs 
> illustrate usage Accept and Content-Type headers for the "application/json" 
> type. Not a "recordio" type. So my experience, as per the docs, seems 
> expected. However, this is counter-intuitive since the whole point of adding 
> the new Message-prefixed headers was to help callers consistently request 
> (and differentiate) streaming responses from non-streaming responses in the 
> v1 API.
> Please fix the master operator API implementation to also support the 
> Message-prefixed headers w/ Accept/Content-Type set to "recordio".
> Observed on ubuntu w/ mesos package version 1.2.1-2.0.1



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

[jira] [Commented] (MESOS-7916) Improve the test coverage of the DefaultExecutor.

2017-09-13 Thread Greg Mann (JIRA) 

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

Greg Mann commented on MESOS-7916:
--

{code}
commit e7df335a484131450ff15bcd2ee325ea40dc8155
Author: Gastón Kleiman gas...@mesosphere.io
Date:   Wed Sep 13 09:21:23 2017 -0700

Cleaned up DefaultExecutor tests.

Updated the DefaultExecutor tests to use test helpers where possible.
Also made the boilerplate initialization code consistent across tests.

Review: https://reviews.apache.org/r/61982/
{code}

> Improve the test coverage of the DefaultExecutor.
> -
>
> Key: MESOS-7916
> URL: https://issues.apache.org/jira/browse/MESOS-7916
> Project: Mesos
>  Issue Type: Improvement
>  Components: executor
>Reporter: Gastón Kleiman
>Assignee: Gastón Kleiman
>  Labels: mesosphere
>
> We should write tests for the {{DefaultExecutor}} to cover the following 
> common scenarios:
> # -Start a task that uses a GPU, and make sure that it is made available to 
> the task.-
> # -Launch a Docker task with a health check.-
> # -Launch two tasks and verify that they can access a volume owned by the 
> Executor via {{sandbox_path}} volumes.-
> # -Launch two tasks, each one in its own task group, and verify that they can 
> access a volume owned by the Executor via {{sandbox_path}} volumes.-
> # -Launch a task that uses an env secret, make sure that it is accessible.-
> # Launch a task using a URI and make sure that the artifact is accessible.
> # Launch a task using a Docker image + URIs, make sure that the fetched 
> artifact is accessible.
> # Launch one task and ensure that (health) checks can read from a persistent 
> volume.
> # Ensure that the executor's env is NOT inherited by the nested tasks.



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

[jira] [Commented] (MESOS-7877) Audit test code for undefined behavior in accessing container elements

2017-09-13 Thread Greg Mann (JIRA) 

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

Greg Mann commented on MESOS-7877:
--

{code}
commit 1f4d7ef27e0e4936c1ea15d4e56d778e35a92507
Author: Gastón Kleiman gas...@mesosphere.io
Date:   Wed Sep 13 09:21:20 2017 -0700

Added new overloads for the `createExecutorInfo` test helper method.

These new overloads make it possible to specify framework ID, executor
resources, and executor ID as a protobuf message rather than a string.

Review: https://reviews.apache.org/r/62197/
{code}
{code}
commit 2a6f6b7aedf05b23ae0fe04364159c87f6c5cea8
Author: Gastón Kleiman gas...@mesosphere.io
Date:   Wed Sep 13 09:21:25 2017 -0700

Changed `EXPECT` to `ASSERT` when relying on the assertion afterwards.

A common pattern in our tests is to check that at least one offer is
received using:

'EXPECT_FALSE(offers->offers().empty())'

The test then accesses the first element of the array returned by
`offers->offers()` to extract information such as the agent ID.

This patch makes the tests that follow this pattern use `ASSERT_FALSE`
instead of `EXPECT_FALSE` to avoid invalid memory accesses when the
array is empty.

Review: https://reviews.apache.org/r/62042/
{code}

> Audit test code for undefined behavior in accessing container elements
> --
>
> Key: MESOS-7877
> URL: https://issues.apache.org/jira/browse/MESOS-7877
> Project: Mesos
>  Issue Type: Bug
>  Components: test
>Reporter: Benjamin Bannier
>Assignee: Gastón Kleiman
>Priority: Minor
>  Labels: mesosphere, newbie, tech-debt, test
>
> We do not always make sure we never access elements from empty containers, 
> e.g., we use patterns like the following
> {code}
> Future offers;
> // Satisfy offers.
> EXPECT_FALSE(offers.empty());
> const auto& offer = (*offers)[0];
> {code}
> While the intention here is to diagnose an empty {{offers}}, the code still 
> exhibits undefined behavior in the element access if {{offers}} was indeed 
> empty (compilers might aggressively exploit undefined behavior to e.g., 
> remove "impossible" code). Instead one should prevent accessing any elements 
> of an empty container, e.g.,
> {code}
> ASSERT_FALSE(offers.empty()); // Prevent execution of rest of test body.
> {code}
> We should audit and fix existing test code for such incorrect checks and 
> variations involving e.g., {{EXPECT_NE}}.



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

[jira] [Commented] (MESOS-7974) Accept "application/recordio" type is rejected for master operator API SUBSCRIBE call

2017-09-13 Thread James DeFelice (JIRA) 

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

James DeFelice commented on MESOS-7974:
---

xref MESOS-6936

> Accept "application/recordio" type is rejected for master operator API 
> SUBSCRIBE call
> -
>
> Key: MESOS-7974
> URL: https://issues.apache.org/jira/browse/MESOS-7974
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 1.2.1
>Reporter: James DeFelice
>  Labels: mesosphere
>
> The agent operator API supports for "application/recordio" for things like 
> attach-container-output, which streams objects back to the caller. I expected 
> the master operator API SUBSCRIBE call to work the same way, w/ 
> Accept/Content-Type headers for "recordio" and 
> Message-Accept/Message-Content-Type headers for json (or protobuf). This was 
> not the case.
> Looking again at the master operator API documentation, SUBSCRIBE docs 
> illustrate usage Accept and Content-Type headers for the "application/json" 
> type. Not a "recordio" type. So my experience, as per the docs, seems 
> expected. However, this is counter-intuitive since the whole point of adding 
> the new Message-prefixed headers was to help callers consistently request 
> (and differentiate) streaming responses from non-streaming responses in the 
> v1 API.
> Please fix the master operator API implementation to also support the 
> Message-prefixed headers w/ Accept/Content-Type set to "recordio".
> Observed on ubuntu w/ mesos package version 1.2.1-2.0.1



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

[jira] [Created] (MESOS-7974) Accept "application/recordio" type is rejected for master operator API SUBSCRIBE call

2017-09-13 Thread James DeFelice (JIRA) 
James DeFelice created MESOS-7974:
-

 Summary: Accept "application/recordio" type is rejected for master 
operator API SUBSCRIBE call
 Key: MESOS-7974
 URL: https://issues.apache.org/jira/browse/MESOS-7974
 Project: Mesos
  Issue Type: Bug
Affects Versions: 1.2.1
Reporter: James DeFelice


The agent operator API supports for "application/recordio" for things like 
attach-container-output, which streams objects back to the caller. I expected 
the master operator API SUBSCRIBE call to work the same way, w/ 
Accept/Content-Type headers for "recordio" and 
Message-Accept/Message-Content-Type headers for json (or protobuf). This was 
not the case.

Looking again at the master operator API documentation, SUBSCRIBE docs 
illustrate usage Accept and Content-Type headers for the "application/json" 
type. Not a "recordio" type. So my experience, as per the docs, seems expected. 
However, this is counter-intuitive since the whole point of adding the new 
Message-prefixed headers was to help callers consistently request (and 
differentiate) streaming responses from non-streaming responses in the v1 API.

Please fix the master operator API implementation to also support the 
Message-prefixed headers w/ Accept/Content-Type set to "recordio".

Observed on ubuntu w/ mesos package version 1.2.1-2.0.1



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

[jira] [Created] (MESOS-7973) Non-leading VOTING replica catch-up

2017-09-13 Thread Ilya Pronin (JIRA) 
Ilya Pronin created MESOS-7973:
--

 Summary: Non-leading VOTING replica catch-up
 Key: MESOS-7973
 URL: https://issues.apache.org/jira/browse/MESOS-7973
 Project: Mesos
  Issue Type: Improvement
  Components: replicated log
Reporter: Ilya Pronin
Assignee: Ilya Pronin


Currently it is not possible to perform consistent reads from non-leading 
replicas due to the fact that if a non-leading replica is partitioned it may 
miss some log positions and will not make any attempt to “fill” those holes.

If a non-leading replica could catch-up missing log positions it would be able 
to serve eventually consistent reads to the framework. This would make it 
possible to do additional work on non-leading framework replicas (e.g. offload 
some reading from a leader to standbys or reduce failover time by keeping 
in-memory storage represented by the log “hot”).

Design doc: 
https://docs.google.com/document/d/1dERXJeAsi3Lnq9Akt82JGWK4pKNeJ6k7PTVCpM9ic_8/edit?usp=sharing



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

[jira] [Commented] (MESOS-7914) Replace usage of `ObjectApprover` with `AuthorizationAcceptor`

2017-09-13 Thread Till Toenshoff (JIRA) 

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

Till Toenshoff commented on MESOS-7914:
---

@greggomann +1!

> Replace usage of `ObjectApprover` with `AuthorizationAcceptor`
> --
>
> Key: MESOS-7914
> URL: https://issues.apache.org/jira/browse/MESOS-7914
> Project: Mesos
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 1.4.0
>Reporter: Greg Mann
>Assignee: Greg Mann
>  Labels: authorization, mesosphere
>
> Now that the {{AuthorizationAcceptor}} class has been added, we can replace 
> all occurrences of {{getObjectApprover}} with 
> {{AuthorizationAcceptor::create}}.



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

[jira] [Commented] (MESOS-7927) The composing containerizer leaks memory in some scenarios.

2017-09-13 Thread Qian Zhang (JIRA) 

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

Qian Zhang commented on MESOS-7927:
---

commit 257ee17400dcf66f69d526d768c8fdc1b1740004
Author: Qian Zhang zhq527...@gmail.com
Date:   Tue Sep 12 15:17:43 2017 +0800

Fixed a memory leak in composing containerizer.

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

src/slave/containerizer/composing.cpp | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

> The composing containerizer leaks memory in some scenarios.
> ---
>
> Key: MESOS-7927
> URL: https://issues.apache.org/jira/browse/MESOS-7927
> Project: Mesos
>  Issue Type: Bug
>Reporter: Anand Mazumdar
>Assignee: Qian Zhang
>Priority: Critical
> Fix For: 1.5.0
>
>
> The composing containerizer does not remove an active containers from its 
> internal {{containers}} hashmap containing the known active containers in 
> some cases. This can happen when the container terminates on its own. This 
> means that {{destroy()}} is not invoked for such containers.
> Ideally, we should chain the {{destroy}} callback when launching the 
> container itself.



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