[jira] [Assigned] (MESOS-6703) Port `credentials_tests.cpp`
[ 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`
[ 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`
[ 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
[ https://issues.apache.org/jira/browse/MESOS-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
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.
[ https://issues.apache.org/jira/browse/MESOS-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ 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.
[ https://issues.apache.org/jira/browse/MESOS-7961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ 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.
[ 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.
[ https://issues.apache.org/jira/browse/MESOS-7961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ 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
[ 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.
[ https://issues.apache.org/jira/browse/MESOS-7916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MESOS-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MESOS-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
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`
[ https://issues.apache.org/jira/browse/MESOS-7914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/MESOS-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)