[jira] [Commented] (MESOS-4925) Enhance Mesos filter to support filtering Mesos agent based on agent attribute
[ https://issues.apache.org/jira/browse/MESOS-4925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192833#comment-15192833 ] Klaus Ma commented on MESOS-4925: - Two more cases about the filter: 1. filter resources type; for example, if the tasks in framework only use cpu & memory, the master should only get the offer with cpu & memory 2. the framework decline resources instead of offers; if framework known its target tasks (e.g. only cpu & memory), it does not need to wait for offer and decline disk & port. Thanks Klaus > Enhance Mesos filter to support filtering Mesos agent based on agent attribute > -- > > Key: MESOS-4925 > URL: https://issues.apache.org/jira/browse/MESOS-4925 > Project: Mesos > Issue Type: Improvement > Components: allocation >Reporter: Qian Zhang >Assignee: Qian Zhang > > Currently Mesos supports framework to set a filter when it accept an offer > (i.e., filter the unused resources in the offer) or when it decline an offer > (i.e., filter all the resources in the offer), and then allocator will not > send the filtered resources to framework within the configurable duration. > This is great. > However, there are also some use cases that framework may want to set a > filter based on agent attribute, e.g., framework does not want to receive > offers for any agents which does not have a specific attribute (e.g., GPU, > SSD, etc.). So I think we may need to enhance the Mesos filter to support > this kind of attribute-based filtering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4926) We should add a list parser for comma separated integers in flags.
Kevin Klues created MESOS-4926: -- Summary: We should add a list parser for comma separated integers in flags. Key: MESOS-4926 URL: https://issues.apache.org/jira/browse/MESOS-4926 Project: Mesos Issue Type: Improvement Reporter: Kevin Klues Assignee: Kevin Klues Some flags require lists of integers to be passed in. We should have an explicit parser for this instead of relying on ad hoc solutions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4927) The flag parser for `hashmap` should live in stout, not mesos.
Kevin Klues created MESOS-4927: -- Summary: The flag parser for `hashmap` should live in stout, not mesos. Key: MESOS-4927 URL: https://issues.apache.org/jira/browse/MESOS-4927 Project: Mesos Issue Type: Improvement Reporter: Kevin Klues Assignee: Kevin Klues The title says it all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4928) We should remove all '.get().' calls on Option / Try variables in the resources abstraction.
Kevin Klues created MESOS-4928: -- Summary: We should remove all '.get().' calls on Option / Try variables in the resources abstraction. Key: MESOS-4928 URL: https://issues.apache.org/jira/browse/MESOS-4928 Project: Mesos Issue Type: Improvement Reporter: Kevin Klues Assignee: Kevin Klues When possible, .get() calls should be replaced by -> for Option / Try variables. This ticket only proposes a blanket change for this in the resource abstraction files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4929) WebUI does not correctly sort tasks when their TaskIds are of different length
Jay Guo created MESOS-4929: -- Summary: WebUI does not correctly sort tasks when their TaskIds are of different length Key: MESOS-4929 URL: https://issues.apache.org/jira/browse/MESOS-4929 Project: Mesos Issue Type: Bug Components: webui Affects Versions: 0.27.1 Environment: Safari, Firefox, Chrome Reporter: Jay Guo Priority: Trivial On completed tasks page, tasks with multiple length of TaskIds are not displayed in correct order when sorting by TaskId. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4929) WebUI does not correctly sort tasks when their TaskIds are of different length
[ https://issues.apache.org/jira/browse/MESOS-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Guo updated MESOS-4929: --- Attachment: (was: screenshot-1.png) > WebUI does not correctly sort tasks when their TaskIds are of different length > -- > > Key: MESOS-4929 > URL: https://issues.apache.org/jira/browse/MESOS-4929 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 0.27.1 > Environment: Safari, Firefox, Chrome >Reporter: Jay Guo >Priority: Trivial > Attachments: taskid.png > > > On completed tasks page, tasks with multiple length of TaskIds are not > displayed in correct order when sorting by TaskId. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4929) WebUI does not correctly sort tasks when their TaskIds are of different length
[ https://issues.apache.org/jira/browse/MESOS-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Guo updated MESOS-4929: --- Attachment: screenshot-1.png > WebUI does not correctly sort tasks when their TaskIds are of different length > -- > > Key: MESOS-4929 > URL: https://issues.apache.org/jira/browse/MESOS-4929 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 0.27.1 > Environment: Safari, Firefox, Chrome >Reporter: Jay Guo >Priority: Trivial > Attachments: taskid.png > > > On completed tasks page, tasks with multiple length of TaskIds are not > displayed in correct order when sorting by TaskId. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4929) WebUI does not correctly sort tasks when their TaskIds are of different length
[ https://issues.apache.org/jira/browse/MESOS-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Guo updated MESOS-4929: --- Attachment: taskid.png > WebUI does not correctly sort tasks when their TaskIds are of different length > -- > > Key: MESOS-4929 > URL: https://issues.apache.org/jira/browse/MESOS-4929 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 0.27.1 > Environment: Safari, Firefox, Chrome >Reporter: Jay Guo >Priority: Trivial > Attachments: taskid.png > > > On completed tasks page, tasks with multiple length of TaskIds are not > displayed in correct order when sorting by TaskId. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4929) WebUI does not correctly sort tasks when their TaskIds are of different length
[ https://issues.apache.org/jira/browse/MESOS-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192919#comment-15192919 ] haosdent commented on MESOS-4929: - TaskID could be a string, so it sorted by dictionary order. > WebUI does not correctly sort tasks when their TaskIds are of different length > -- > > Key: MESOS-4929 > URL: https://issues.apache.org/jira/browse/MESOS-4929 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 0.27.1 > Environment: Safari, Firefox, Chrome >Reporter: Jay Guo >Priority: Trivial > Attachments: taskid.png > > > On completed tasks page, tasks with multiple length of TaskIds are not > displayed in correct order when sorting by TaskId. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3057) Mesos web ui sorting by Id results in non-intuitive order.
[ https://issues.apache.org/jira/browse/MESOS-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192937#comment-15192937 ] Jay Guo commented on MESOS-3057: [~haosd...@gmail.com] Then should we at least fix this in example frameworks that come with Mesos? We came across this issue while trying long-lived-framework in /src/examples/long_lived_framework.cpp > Mesos web ui sorting by Id results in non-intuitive order. > -- > > Key: MESOS-3057 > URL: https://issues.apache.org/jira/browse/MESOS-3057 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.23.0 >Reporter: Cody Roseborough >Priority: Trivial > Labels: newbie > Attachments: web ui sorted by ids.png > > > In the mesos webui sorting task by ID results in non-intuitive order. For > example with Id's task_0-task_200 sorted asc you get task_0, task_1, task_10, > task_100... task_109, task_11, task_110 etc. It happens if you use just > numbers as Id's also. > It seems like it should be sorted using natural sort order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3057) Mesos web ui sorting by Id results in non-intuitive order.
[ https://issues.apache.org/jira/browse/MESOS-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192951#comment-15192951 ] haosdent commented on MESOS-3057: - Sure, so you means update the task id generation in long_lived_framework? Could you help update the title and description of this ticket and reopen it? > Mesos web ui sorting by Id results in non-intuitive order. > -- > > Key: MESOS-3057 > URL: https://issues.apache.org/jira/browse/MESOS-3057 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.23.0 >Reporter: Cody Roseborough >Priority: Trivial > Labels: newbie > Attachments: web ui sorted by ids.png > > > In the mesos webui sorting task by ID results in non-intuitive order. For > example with Id's task_0-task_200 sorted asc you get task_0, task_1, task_10, > task_100... task_109, task_11, task_110 etc. It happens if you use just > numbers as Id's also. > It seems like it should be sorted using natural sort order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4930) Update example frameworks in Mesos codebase to assign proper TaskId in order to be sorted correctly in WebUI
Jay Guo created MESOS-4930: -- Summary: Update example frameworks in Mesos codebase to assign proper TaskId in order to be sorted correctly in WebUI Key: MESOS-4930 URL: https://issues.apache.org/jira/browse/MESOS-4930 Project: Mesos Issue Type: Improvement Components: framework, webui Reporter: Jay Guo Priority: Trivial Frameworks should assign fixed number of digits to tasks as the TaskId, which will be lexically sorted by WebUI in correct order. For instance, `1`, `2`, `10`, `11` will be sorted to `1`, `10`, `11`, `2`. But `001`, `002`, `010`, `011` will be sorted in ascending order. /src/examples/long_lived_framework.cpp should be updated -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3057) Mesos web ui sorting by Id results in non-intuitive order.
[ https://issues.apache.org/jira/browse/MESOS-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192989#comment-15192989 ] Jay Guo commented on MESOS-3057: OK, I created another ticket https://issues.apache.org/jira/browse/MESOS-4930 instead of rewriting history here. I could work on it as well if anybody could shepherd it. > Mesos web ui sorting by Id results in non-intuitive order. > -- > > Key: MESOS-3057 > URL: https://issues.apache.org/jira/browse/MESOS-3057 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.23.0 >Reporter: Cody Roseborough >Priority: Trivial > Labels: newbie > Attachments: web ui sorted by ids.png > > > In the mesos webui sorting task by ID results in non-intuitive order. For > example with Id's task_0-task_200 sorted asc you get task_0, task_1, task_10, > task_100... task_109, task_11, task_110 etc. It happens if you use just > numbers as Id's also. > It seems like it should be sorted using natural sort order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-4891) Add a '/containers' endpoint to the agent to list all the active containers.
[ https://issues.apache.org/jira/browse/MESOS-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Guo reassigned MESOS-4891: -- Assignee: Jay Guo > Add a '/containers' endpoint to the agent to list all the active containers. > > > Key: MESOS-4891 > URL: https://issues.apache.org/jira/browse/MESOS-4891 > Project: Mesos > Issue Type: Improvement >Reporter: Jie Yu >Assignee: Jay Guo > > This endpoint will be similar to /monitor/statistics.json endpoint, but it'll > also contain the 'container_status' about the container (see ContainerStatus > in mesos.proto). We'll eventually deprecate the /monitor/statistics.json > endpoint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2281) Remove legacy Credential format
[
https://issues.apache.org/jira/browse/MESOS-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schad updated MESOS-2281:
---
Description:
Currently two formats of credentials are supported: JSON
{code}
"credentials": [
{
"principal": "sherman",
"secret": "kitesurf"
}
{code}
And a new line file:
{code}
principal1 secret1
pricipal2 secret2
{code}
We should deprecate the new line format and remove support for the old format.
was:
Currently two formats of credentials are supported: JSON
{code}
"credentials": [
{
"principal": "sherman",
"secret": "kitesurf"
}
{code}
And a new line file:
{code}
principal1 secret1
pricipal2 secret2
{code}
We should deprecate and remove support for the old format.
> Remove legacy Credential format
> ---
>
> Key: MESOS-2281
> URL: https://issues.apache.org/jira/browse/MESOS-2281
> Project: Mesos
> Issue Type: Improvement
> Components: master, slave
>Affects Versions: 0.21.1
>Reporter: Cody Maloney
> Labels: mesosphere, security, tech-debt
>
> Currently two formats of credentials are supported: JSON
> {code}
> "credentials": [
> {
> "principal": "sherman",
> "secret": "kitesurf"
> }
> {code}
> And a new line file:
> {code}
> principal1 secret1
> pricipal2 secret2
> {code}
> We should deprecate the new line format and remove support for the old format.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2281) Deprecate legacy Credential format.
[
https://issues.apache.org/jira/browse/MESOS-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schad updated MESOS-2281:
---
Summary: Deprecate legacy Credential format. (was: Remove legacy
Credential format)
> Deprecate legacy Credential format.
> ---
>
> Key: MESOS-2281
> URL: https://issues.apache.org/jira/browse/MESOS-2281
> Project: Mesos
> Issue Type: Improvement
> Components: master, slave
>Affects Versions: 0.21.1
>Reporter: Cody Maloney
> Labels: mesosphere, security, tech-debt
>
> Currently two formats of credentials are supported: JSON
> {code}
> "credentials": [
> {
> "principal": "sherman",
> "secret": "kitesurf"
> }
> {code}
> And a new line file:
> {code}
> principal1 secret1
> pricipal2 secret2
> {code}
> We should deprecate the new line format and remove support for the old format.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2281) Deprecate legacy Credential format.
[
https://issues.apache.org/jira/browse/MESOS-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-2281:
--
Assignee: Jan Schlicht
> Deprecate legacy Credential format.
> ---
>
> Key: MESOS-2281
> URL: https://issues.apache.org/jira/browse/MESOS-2281
> Project: Mesos
> Issue Type: Improvement
> Components: master, slave
>Affects Versions: 0.21.1
>Reporter: Cody Maloney
>Assignee: Jan Schlicht
> Labels: mesosphere, security, tech-debt
>
> Currently two formats of credentials are supported: JSON
> {code}
> "credentials": [
> {
> "principal": "sherman",
> "secret": "kitesurf"
> }
> {code}
> And a new line file:
> {code}
> principal1 secret1
> pricipal2 secret2
> {code}
> We should deprecate the new line format and remove support for the old format.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2281) Deprecate legacy Credential format.
[
https://issues.apache.org/jira/browse/MESOS-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-2281:
--
Shepherd: Adam B
Sprint: Mesosphere Sprint 31
[~js84] to do first-pass review once [~nfnt] has something ready.
> Deprecate legacy Credential format.
> ---
>
> Key: MESOS-2281
> URL: https://issues.apache.org/jira/browse/MESOS-2281
> Project: Mesos
> Issue Type: Improvement
> Components: master, slave
>Affects Versions: 0.21.1
>Reporter: Cody Maloney
>Assignee: Jan Schlicht
> Labels: mesosphere, security, tech-debt
>
> Currently two formats of credentials are supported: JSON
> {code}
> "credentials": [
> {
> "principal": "sherman",
> "secret": "kitesurf"
> }
> {code}
> And a new line file:
> {code}
> principal1 secret1
> pricipal2 secret2
> {code}
> We should deprecate the new line format and remove support for the old format.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4931) Authorization based filtering for endpoints.
[ https://issues.apache.org/jira/browse/MESOS-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schad updated MESOS-4931: --- Summary: Authorization based filtering for endpoints. (was: 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. ) > Authorization based filtering for endpoints. > > > Key: MESOS-4931 > URL: https://issues.apache.org/jira/browse/MESOS-4931 > Project: Mesos > Issue Type: Epic >Reporter: Joerg Schad > > 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] [Created] (MESOS-4931) 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
Joerg Schad created MESOS-4931: -- Summary: 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. Key: MESOS-4931 URL: https://issues.apache.org/jira/browse/MESOS-4931 Project: Mesos Issue Type: Epic Reporter: Joerg Schad -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4931) 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
[ https://issues.apache.org/jira/browse/MESOS-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schad updated MESOS-4931: --- Description: 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. > 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. > - > > Key: MESOS-4931 > URL: https://issues.apache.org/jira/browse/MESOS-4931 > Project: Mesos > Issue Type: Epic >Reporter: Joerg Schad > > 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] [Created] (MESOS-4932) Propose Design for Authorization based filtering for endpoints.
Joerg Schad created MESOS-4932: -- Summary: Propose Design for Authorization based filtering for endpoints. Key: MESOS-4932 URL: https://issues.apache.org/jira/browse/MESOS-4932 Project: Mesos Issue Type: Task Reporter: Joerg Schad Assignee: Joerg Schad -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4933) Registrar HTTP Authentication.
Joerg Schad created MESOS-4933: -- Summary: Registrar HTTP Authentication. Key: MESOS-4933 URL: https://issues.apache.org/jira/browse/MESOS-4933 Project: Mesos Issue Type: Task Reporter: Joerg Schad Assignee: Jan Schlicht Now that the master (and agents in progress) provide http authentication the registrar should do the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4933) Registrar HTTP Authentication.
[ https://issues.apache.org/jira/browse/MESOS-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schad updated MESOS-4933: --- Sprint: Mesosphere Sprint 31 Story Points: 2 Labels: mesosphere (was: ) > Registrar HTTP Authentication. > -- > > Key: MESOS-4933 > URL: https://issues.apache.org/jira/browse/MESOS-4933 > Project: Mesos > Issue Type: Task >Reporter: Joerg Schad >Assignee: Jan Schlicht > Labels: mesosphere > > Now that the master (and agents in progress) provide http authentication the > registrar should do the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4933) Registrar HTTP Authentication.
[ https://issues.apache.org/jira/browse/MESOS-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193109#comment-15193109 ] Joerg Schad commented on MESOS-4933: [~joerg84] will do the first review. > Registrar HTTP Authentication. > -- > > Key: MESOS-4933 > URL: https://issues.apache.org/jira/browse/MESOS-4933 > Project: Mesos > Issue Type: Task >Reporter: Joerg Schad >Assignee: Jan Schlicht > Labels: mesosphere > > Now that the master (and agents in progress) provide http authentication the > registrar should do the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4907) ClangTidy Integration
[
https://issues.apache.org/jira/browse/MESOS-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193114#comment-15193114
]
Benjamin Bannier commented on MESOS-4907:
-
[~lins05] One possible approach would be to integrate {{clang-tidy}} into the
build so that all needed files are present, e.g. by using a compiler wrapper
like [Bear|https://github.com/rizsotto/Bear] to create a compilation database
for {{clang-tidy}} to digest.
The advantage of this would be that we implicitly make sure that all of the
many compiler flags (like e.g., {{#defines}}) are always passed to
{{clang-tidy}} as well. In the past relative paths for include paths were [an
issue for clang tools|https://llvm.org/bugs/show_bug.cgi?id=24710], but this
was fixed for clang-3.8 which we seem to require now for {{clang-format}} at
least. It comes with the disadvantage that creating the compilation database
requires a full build without e.g., {{ccache}}, but this shouldn't be an issue
in e.g., CI builds. For developers it might be good enough to manually refresh
the database from time to time. This issue will disappear once a complete cmake
build becomes available which can create the needed database without requiring
a build.
> ClangTidy Integration
> -
>
> Key: MESOS-4907
> URL: https://issues.apache.org/jira/browse/MESOS-4907
> Project: Mesos
> Issue Type: Epic
> Components: technical debt
>Reporter: Michael Park
> Labels: gsoc, gsoc2016, mentor, mesosphere
>
> While {{cpplint}} has been a useful tool as a C++ linter for quite some time,
> It carries limitations since it does its best without actually parsing C++.
> [ClangTidy|http://clang.llvm.org/extra/clang-tidy/] is a clang tool that is
> based
> off of Clang, and has the advantage that it has access to a full AST.
> There are many checks that come built-in with {{clang-tidy}} which are very
> useful,
> but we can extend it to fit Mesos coding style and patterns as well.
> The initial phase of the project will be to create a basis with which to
> leverage
> the existing checks as applicable to Mesos, then to create a scaffolding to
> add
> custom checks, and ways to integrate the custom checks to infrastructure such
> as Mesos ReviewBot, or Apache CI.
> I've done some preliminary, experimental work for this for a Hackathon project
> and have given a
> [presentation|https://docs.google.com/presentation/d/1z_qGzpY7Mt46TXxuLRW6M5HcCWBLRz6UJfd4bPknYeg/edit?usp=sharing]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4931) Authorization based filtering for endpoints.
[ https://issues.apache.org/jira/browse/MESOS-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-4931: -- Labels: authorization mesosphere security (was: ) > Authorization based filtering for endpoints. > > > Key: MESOS-4931 > URL: https://issues.apache.org/jira/browse/MESOS-4931 > Project: Mesos > Issue Type: Epic >Reporter: Joerg Schad > Labels: authorization, mesosphere, security > > 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-4932) Propose Design for Authorization based filtering for endpoints.
[ https://issues.apache.org/jira/browse/MESOS-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-4932: -- Labels: authorization mesosphere security (was: ) > Propose Design for Authorization based filtering for endpoints. > --- > > Key: MESOS-4932 > URL: https://issues.apache.org/jira/browse/MESOS-4932 > Project: Mesos > Issue Type: Task >Reporter: Joerg Schad >Assignee: Joerg Schad > Labels: authorization, mesosphere, security > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4931) Authorization based filtering for endpoints.
[ https://issues.apache.org/jira/browse/MESOS-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-4931: -- Component/s: security > 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 > Labels: authorization, mesosphere, security > > 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-4932) Propose Design for Authorization based filtering for endpoints.
[ https://issues.apache.org/jira/browse/MESOS-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-4932: -- Component/s: security > Propose Design for Authorization based filtering for endpoints. > --- > > Key: MESOS-4932 > URL: https://issues.apache.org/jira/browse/MESOS-4932 > Project: Mesos > Issue Type: Task > Components: security >Reporter: Joerg Schad >Assignee: Joerg Schad > Labels: authorization, mesosphere, security > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4932) Propose Design for Authorization based filtering for endpoints.
[ https://issues.apache.org/jira/browse/MESOS-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-4932: -- Sprint: Mesosphere Sprint 31 Story Points: 5 I can imagine two different ACL formats, both of which we may want to support: 1. Adam can VIEW_TASKINFOS_WITH_ROLE "foo" 2. Bob can VIEW_TASKINFOS_WITH_OWNER "Adam" The former grants Adam permission to view all tasks/executors belonging to any framework in the "foo" role. This is rather coarse-grained, but allows a team to share access across all frameworks in their role. The latter allows all of Adam's tasks to be shared with another user, Bob. There is no easy way yet to share only some of Adam's tasks with Bob, unless we authorize based on taskId (won't scale), or wait until we have multi-role frameworks. We may consider allowing the owner of a TaskInfo to be able to access their own tasks without an explicit ACL set. > Propose Design for Authorization based filtering for endpoints. > --- > > Key: MESOS-4932 > URL: https://issues.apache.org/jira/browse/MESOS-4932 > Project: Mesos > Issue Type: Task > Components: security >Reporter: Joerg Schad >Assignee: Joerg Schad > Labels: authorization, mesosphere, security > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4933) Registrar HTTP Authentication.
[ https://issues.apache.org/jira/browse/MESOS-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-4933: -- Labels: authentication mesosphere security (was: mesosphere) > Registrar HTTP Authentication. > -- > > Key: MESOS-4933 > URL: https://issues.apache.org/jira/browse/MESOS-4933 > Project: Mesos > Issue Type: Task >Reporter: Joerg Schad >Assignee: Jan Schlicht > Labels: authentication, mesosphere, security > > Now that the master (and agents in progress) provide http authentication the > registrar should do the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4933) Registrar HTTP Authentication.
[ https://issues.apache.org/jira/browse/MESOS-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-4933: -- Description: Now that the master (and agents in progress) provide http authentication the registrar should do the same. See http://mesos.apache.org/documentation/latest/endpoints/registrar/registry/ was:Now that the master (and agents in progress) provide http authentication the registrar should do the same. > Registrar HTTP Authentication. > -- > > Key: MESOS-4933 > URL: https://issues.apache.org/jira/browse/MESOS-4933 > Project: Mesos > Issue Type: Task >Reporter: Joerg Schad >Assignee: Jan Schlicht > Labels: authentication, mesosphere, security > > Now that the master (and agents in progress) provide http authentication the > registrar should do the same. > See http://mesos.apache.org/documentation/latest/endpoints/registrar/registry/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4907) ClangTidy Integration
[
https://issues.apache.org/jira/browse/MESOS-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193165#comment-15193165
]
Shuai Lin commented on MESOS-4907:
--
Thanks for the reply! Yeah, using bear or cmake to get the compiler flags is
the way to go. And cmake with ninja backend would be perfect for this purpose.
But the problem I mentioned above is different: Even if we get the compiler
flags and pass it to clang-tidy, when a {{.proto}} file is changed (say
{{mesos.proto}}), e.g. a new field is added to a message, clang-tidy may still
report there are errors in the code where the new field is used, because the
{{mesos.pb.h}} is not updated yet thus the new field is not visible to
clang-tidy.
> ClangTidy Integration
> -
>
> Key: MESOS-4907
> URL: https://issues.apache.org/jira/browse/MESOS-4907
> Project: Mesos
> Issue Type: Epic
> Components: technical debt
>Reporter: Michael Park
> Labels: gsoc, gsoc2016, mentor, mesosphere
>
> While {{cpplint}} has been a useful tool as a C++ linter for quite some time,
> It carries limitations since it does its best without actually parsing C++.
> [ClangTidy|http://clang.llvm.org/extra/clang-tidy/] is a clang tool that is
> based
> off of Clang, and has the advantage that it has access to a full AST.
> There are many checks that come built-in with {{clang-tidy}} which are very
> useful,
> but we can extend it to fit Mesos coding style and patterns as well.
> The initial phase of the project will be to create a basis with which to
> leverage
> the existing checks as applicable to Mesos, then to create a scaffolding to
> add
> custom checks, and ways to integrate the custom checks to infrastructure such
> as Mesos ReviewBot, or Apache CI.
> I've done some preliminary, experimental work for this for a Hackathon project
> and have given a
> [presentation|https://docs.google.com/presentation/d/1z_qGzpY7Mt46TXxuLRW6M5HcCWBLRz6UJfd4bPknYeg/edit?usp=sharing]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4726) Document scheduler driver calls in framework development guide.
[ https://issues.apache.org/jira/browse/MESOS-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schad updated MESOS-4726: --- Sprint: Mesosphere Sprint 30 (was: Mesosphere Sprint 31) > Document scheduler driver calls in framework development guide. > --- > > Key: MESOS-4726 > URL: https://issues.apache.org/jira/browse/MESOS-4726 > Project: Mesos > Issue Type: Documentation >Reporter: Joerg Schad >Assignee: Joerg Schad > Labels: mesosphere > Fix For: 0.29.0 > > > The interface examples are slightly out of sync with scheduler.hpp, most > notably missing the new acceptOffers call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4934) Enable HELP to include authentication status of endpoint.
Joerg Schad created MESOS-4934: -- Summary: Enable HELP to include authentication status of endpoint. Key: MESOS-4934 URL: https://issues.apache.org/jira/browse/MESOS-4934 Project: Mesos Issue Type: Task Reporter: Joerg Schad Assignee: Joerg Schad As we enable authentication for more and more endpoints we should document which endpoints support authentication and which ones don't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4924) MAC OS build failed
[
https://issues.apache.org/jira/browse/MESOS-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinod Kone updated MESOS-4924:
--
Priority: Blocker (was: Major)
[~SteveNiemitz] Sounds like we should disable the "as-needed" option for OSX.
Can you send in a fix?
> MAC OS build failed
> ---
>
> Key: MESOS-4924
> URL: https://issues.apache.org/jira/browse/MESOS-4924
> Project: Mesos
> Issue Type: Bug
>Reporter: Guangya Liu
>Priority: Blocker
>
> Seems caused by https://reviews.apache.org/r/41049/ [~SteveNiemitz]
> {code}
> -std=c++11 -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11
> -Qunused-arguments -I/usr/local/opt/subversion/include/subversion-1
> -I/usr/include/apr-1 -I/usr/include/apr-1.0 -Qunused-arguments
> build/temp.macosx-10.10-intel-2.7/src/mesos/executor/mesos_executor_driver_impl.o
> build/temp.macosx-10.10-intel-2.7/src/mesos/executor/module.o
> build/temp.macosx-10.10-intel-2.7/src/mesos/executor/proxy_executor.o
> /Users/gyliu/git/mesos/build/src/.libs/libmesos_no_3rdparty.a
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/.libs/libprocess.a
> /Users/gyliu/git/mesos/build/3rdparty/leveldb-1.4/libleveldb.a
> /Users/gyliu/git/mesos/build/3rdparty/zookeeper-3.4.5/src/c/.libs/libzookeeper_mt.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/glog-0.3.3/.libs/libglog.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/protobuf-2.5.0/src/.libs/libprotobuf.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/libev-4.15/.libs/libev.a
> -o build/lib.macosx-10.10-intel-2.7/mesos/executor/_executor.so
> -Wl,--as-needed -L/usr/local/opt/subversion/lib -lsasl2 -lsvn_delta-1
> -lsvn_subr-1 -lapr-1 -lcurl -lz
> ld: unknown option: --as-needed
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> error: command 'g++' failed with exit status 1
> make[2]: *** [python/dist/mesos.executor-0.29.0-py2.7-macosx-10.10-intel.egg]
> Error 1
> make[2]: *** Waiting for unfinished jobs
> g++ -bundle -undefined dynamic_lookup -arch x86_64 -arch i386 -Wl,-F.
> -L/usr/local/opt/subversion/lib -g -O0 -g -O0 -Wno-unused-local-typedef
> -std=c++11 -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11
> -Qunused-arguments -I/usr/local/opt/subversion/include/subversion-1
> -I/usr/include/apr-1 -I/usr/include/apr-1.0 -Qunused-arguments
> build/temp.macosx-10.10-intel-2.7/src/mesos/scheduler/mesos_scheduler_driver_impl.o
> build/temp.macosx-10.10-intel-2.7/src/mesos/scheduler/module.o
> build/temp.macosx-10.10-intel-2.7/src/mesos/scheduler/proxy_scheduler.o
> /Users/gyliu/git/mesos/build/src/.libs/libmesos_no_3rdparty.a
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/.libs/libprocess.a
> /Users/gyliu/git/mesos/build/3rdparty/leveldb-1.4/libleveldb.a
> /Users/gyliu/git/mesos/build/3rdparty/zookeeper-3.4.5/src/c/.libs/libzookeeper_mt.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/glog-0.3.3/.libs/libglog.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/protobuf-2.5.0/src/.libs/libprotobuf.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/libev-4.15/.libs/libev.a
> -o build/lib.macosx-10.10-intel-2.7/mesos/scheduler/_scheduler.so
> -Wl,--as-needed -L/usr/local/opt/subversion/lib -lsasl2 -lsvn_delta-1
> -lsvn_subr-1 -lapr-1 -lcurl -lz
> ld: unknown option: --as-needed
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> error: command 'g++' failed with exit status 1
> make[2]: ***
> [python/dist/mesos.scheduler-0.29.0-py2.7-macosx-10.10-intel.egg] Error 1
> make[1]: *** [all] Error 2
> make: *** [all-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2858) FetcherCacheHttpTest.HttpMixed is flaky.
[
https://issues.apache.org/jira/browse/MESOS-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193281#comment-15193281
]
Bernd Mathiske commented on MESOS-2858:
---
FetcherCacheHttpTest.HttpCachedConcurrent exposes the same flaky behavior.
> FetcherCacheHttpTest.HttpMixed is flaky.
>
>
> Key: MESOS-2858
> URL: https://issues.apache.org/jira/browse/MESOS-2858
> Project: Mesos
> Issue Type: Bug
> Components: fetcher, test
>Reporter: Benjamin Mahler
>Assignee: Bernd Mathiske
> Labels: flaky-test, mesosphere
>
> From jenkins:
> {noformat}
> [ RUN ] FetcherCacheHttpTest.HttpMixed
> Using temporary directory '/tmp/FetcherCacheHttpTest_HttpMixed_qfpOOC'
> I0611 00:40:28.208909 26042 leveldb.cpp:176] Opened db in 3.831173ms
> I0611 00:40:28.209951 26042 leveldb.cpp:183] Compacted db in 997319ns
> I0611 00:40:28.210011 26042 leveldb.cpp:198] Created db iterator in 23917ns
> I0611 00:40:28.210032 26042 leveldb.cpp:204] Seeked to beginning of db in
> 2112ns
> I0611 00:40:28.210043 26042 leveldb.cpp:273] Iterated through 0 keys in the
> db in 392ns
> I0611 00:40:28.210095 26042 replica.cpp:744] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0611 00:40:28.210741 26067 recover.cpp:449] Starting replica recovery
> I0611 00:40:28.211144 26067 recover.cpp:475] Replica is in EMPTY status
> I0611 00:40:28.212210 26074 replica.cpp:641] Replica in EMPTY status received
> a broadcasted recover request
> I0611 00:40:28.212728 26071 recover.cpp:195] Received a recover response from
> a replica in EMPTY status
> I0611 00:40:28.213260 26069 recover.cpp:566] Updating replica status to
> STARTING
> I0611 00:40:28.214066 26073 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 590673ns
> I0611 00:40:28.214095 26073 replica.cpp:323] Persisted replica status to
> STARTING
> I0611 00:40:28.214350 26073 recover.cpp:475] Replica is in STARTING status
> I0611 00:40:28.214774 26061 master.cpp:363] Master
> 20150611-004028-1946161580-33349-26042 (658ddc752264) started on
> 172.17.0.116:33349
> I0611 00:40:28.214800 26061 master.cpp:365] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --credentials="/tmp/FetcherCacheHttpTest_HttpMixed_qfpOOC/credentials"
> --framework_sorter="drf" --help="false" --initialize_driver_logging="true"
> --log_auto_initialize="true" --logbufsecs="0" --logging_level="INFO"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_reregister_timeout="10mins"
> --user_sorter="drf" --version="false"
> --webui_dir="/mesos/mesos-0.23.0/_inst/share/mesos/webui"
> --work_dir="/tmp/FetcherCacheHttpTest_HttpMixed_qfpOOC/master"
> --zk_session_timeout="10secs"
> I0611 00:40:28.215342 26061 master.cpp:410] Master only allowing
> authenticated frameworks to register
> I0611 00:40:28.215361 26061 master.cpp:415] Master only allowing
> authenticated slaves to register
> I0611 00:40:28.215397 26061 credentials.hpp:37] Loading credentials for
> authentication from '/tmp/FetcherCacheHttpTest_HttpMixed_qfpOOC/credentials'
> I0611 00:40:28.215589 26064 replica.cpp:641] Replica in STARTING status
> received a broadcasted recover request
> I0611 00:40:28.215770 26061 master.cpp:454] Using default 'crammd5'
> authenticator
> I0611 00:40:28.215934 26061 master.cpp:491] Authorization enabled
> I0611 00:40:28.215932 26062 recover.cpp:195] Received a recover response from
> a replica in STARTING status
> I0611 00:40:28.216256 26070 whitelist_watcher.cpp:79] No whitelist given
> I0611 00:40:28.216310 26066 hierarchical.hpp:309] Initialized hierarchical
> allocator process
> I0611 00:40:28.216352 26067 recover.cpp:566] Updating replica status to VOTING
> I0611 00:40:28.216909 26070 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 374189ns
> I0611 00:40:28.216931 26070 replica.cpp:323] Persisted replica status to
> VOTING
> I0611 00:40:28.217052 26075 recover.cpp:580] Successfully joined the Paxos
> group
> I0611 00:40:28.217355 26063 master.cpp:1476] The newly elected leader is
> master@172.17.0.116:33349 with id 20150611-004028-1946161580-33349-26042
> I0611 00:40:28.217512 26063 master.cpp:1489] Elected as the leading master!
> I0611 00:40:28.217540 26063 master.cpp:1259] Recovering from registrar
> I0611 00:40:28.217753 26070 registrar.cpp:313] Recovering registrar
> I0611 00:40:28.217396 26075 recover.cpp:464] Recover process terminated
> I0611 00:40:28.218341 26065 log.cpp:661] Attempting to start the writer
> I0611 00:40:28.219391 26067
[jira] [Updated] (MESOS-2858) FetcherCacheHttpTest.HttpMixed is flaky.
[
https://issues.apache.org/jira/browse/MESOS-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Mathiske updated MESOS-2858:
--
Sprint: Mesosphere Sprint 31
> FetcherCacheHttpTest.HttpMixed is flaky.
>
>
> Key: MESOS-2858
> URL: https://issues.apache.org/jira/browse/MESOS-2858
> Project: Mesos
> Issue Type: Bug
> Components: fetcher, test
>Reporter: Benjamin Mahler
>Assignee: Bernd Mathiske
> Labels: flaky-test, mesosphere
>
> From jenkins:
> {noformat}
> [ RUN ] FetcherCacheHttpTest.HttpMixed
> Using temporary directory '/tmp/FetcherCacheHttpTest_HttpMixed_qfpOOC'
> I0611 00:40:28.208909 26042 leveldb.cpp:176] Opened db in 3.831173ms
> I0611 00:40:28.209951 26042 leveldb.cpp:183] Compacted db in 997319ns
> I0611 00:40:28.210011 26042 leveldb.cpp:198] Created db iterator in 23917ns
> I0611 00:40:28.210032 26042 leveldb.cpp:204] Seeked to beginning of db in
> 2112ns
> I0611 00:40:28.210043 26042 leveldb.cpp:273] Iterated through 0 keys in the
> db in 392ns
> I0611 00:40:28.210095 26042 replica.cpp:744] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0611 00:40:28.210741 26067 recover.cpp:449] Starting replica recovery
> I0611 00:40:28.211144 26067 recover.cpp:475] Replica is in EMPTY status
> I0611 00:40:28.212210 26074 replica.cpp:641] Replica in EMPTY status received
> a broadcasted recover request
> I0611 00:40:28.212728 26071 recover.cpp:195] Received a recover response from
> a replica in EMPTY status
> I0611 00:40:28.213260 26069 recover.cpp:566] Updating replica status to
> STARTING
> I0611 00:40:28.214066 26073 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 590673ns
> I0611 00:40:28.214095 26073 replica.cpp:323] Persisted replica status to
> STARTING
> I0611 00:40:28.214350 26073 recover.cpp:475] Replica is in STARTING status
> I0611 00:40:28.214774 26061 master.cpp:363] Master
> 20150611-004028-1946161580-33349-26042 (658ddc752264) started on
> 172.17.0.116:33349
> I0611 00:40:28.214800 26061 master.cpp:365] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --credentials="/tmp/FetcherCacheHttpTest_HttpMixed_qfpOOC/credentials"
> --framework_sorter="drf" --help="false" --initialize_driver_logging="true"
> --log_auto_initialize="true" --logbufsecs="0" --logging_level="INFO"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_reregister_timeout="10mins"
> --user_sorter="drf" --version="false"
> --webui_dir="/mesos/mesos-0.23.0/_inst/share/mesos/webui"
> --work_dir="/tmp/FetcherCacheHttpTest_HttpMixed_qfpOOC/master"
> --zk_session_timeout="10secs"
> I0611 00:40:28.215342 26061 master.cpp:410] Master only allowing
> authenticated frameworks to register
> I0611 00:40:28.215361 26061 master.cpp:415] Master only allowing
> authenticated slaves to register
> I0611 00:40:28.215397 26061 credentials.hpp:37] Loading credentials for
> authentication from '/tmp/FetcherCacheHttpTest_HttpMixed_qfpOOC/credentials'
> I0611 00:40:28.215589 26064 replica.cpp:641] Replica in STARTING status
> received a broadcasted recover request
> I0611 00:40:28.215770 26061 master.cpp:454] Using default 'crammd5'
> authenticator
> I0611 00:40:28.215934 26061 master.cpp:491] Authorization enabled
> I0611 00:40:28.215932 26062 recover.cpp:195] Received a recover response from
> a replica in STARTING status
> I0611 00:40:28.216256 26070 whitelist_watcher.cpp:79] No whitelist given
> I0611 00:40:28.216310 26066 hierarchical.hpp:309] Initialized hierarchical
> allocator process
> I0611 00:40:28.216352 26067 recover.cpp:566] Updating replica status to VOTING
> I0611 00:40:28.216909 26070 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 374189ns
> I0611 00:40:28.216931 26070 replica.cpp:323] Persisted replica status to
> VOTING
> I0611 00:40:28.217052 26075 recover.cpp:580] Successfully joined the Paxos
> group
> I0611 00:40:28.217355 26063 master.cpp:1476] The newly elected leader is
> master@172.17.0.116:33349 with id 20150611-004028-1946161580-33349-26042
> I0611 00:40:28.217512 26063 master.cpp:1489] Elected as the leading master!
> I0611 00:40:28.217540 26063 master.cpp:1259] Recovering from registrar
> I0611 00:40:28.217753 26070 registrar.cpp:313] Recovering registrar
> I0611 00:40:28.217396 26075 recover.cpp:464] Recover process terminated
> I0611 00:40:28.218341 26065 log.cpp:661] Attempting to start the writer
> I0611 00:40:28.219391 26067 replica.cpp:477] Replica received implicit
> promise request with proposal 1
> I0611 00:40:28.2196
[jira] [Commented] (MESOS-3902) The Location header when non-leading master redirects to leading master is incomplete.
[
https://issues.apache.org/jira/browse/MESOS-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193301#comment-15193301
]
Vinod Kone commented on MESOS-3902:
---
Are you still working on this?
> The Location header when non-leading master redirects to leading master is
> incomplete.
> --
>
> Key: MESOS-3902
> URL: https://issues.apache.org/jira/browse/MESOS-3902
> Project: Mesos
> Issue Type: Bug
> Components: HTTP API, master
>Affects Versions: 0.25.0
> Environment: 3 masters, 10 slaves
>Reporter: Ben Whitehead
>Assignee: Ashwin Murthy
> Labels: mesosphere
>
> The master now sets a location header, but it's incomplete. The path of the
> URL isn't set. Consider an example:
> {code}
> > cat /tmp/subscribe-1072944352375841456 | httpp POST
> > 127.1.0.3:5050/api/v1/scheduler Content-Type:application/x-protobuf
> POST /api/v1/scheduler HTTP/1.1
> Accept: application/json
> Accept-Encoding: gzip, deflate
> Connection: keep-alive
> Content-Length: 123
> Content-Type: application/x-protobuf
> Host: 127.1.0.3:5050
> User-Agent: HTTPie/0.9.0
> +-+
> | NOTE: binary data not shown in terminal |
> +-+
> HTTP/1.1 307 Temporary Redirect
> Content-Length: 0
> Date: Fri, 26 Feb 2016 00:54:41 GMT
> Location: //127.1.0.1:5050
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4630) Implement partition tests for the HTTP Scheduler API.
[ https://issues.apache.org/jira/browse/MESOS-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-4630: -- Assignee: Anand Mazumdar > Implement partition tests for the HTTP Scheduler API. > - > > Key: MESOS-4630 > URL: https://issues.apache.org/jira/browse/MESOS-4630 > Project: Mesos > Issue Type: Task >Reporter: Anand Mazumdar >Assignee: Anand Mazumdar > Labels: mesosphere > > Currently, the HTTP V1 API does not have partition tests similar to the one > in src/tests/partition_tests.cpp. > For more information see MESOS-3355. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4926) Add a list parser for comma separated integers in flags.
[ https://issues.apache.org/jira/browse/MESOS-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4926: --- Labels: mesosphere (was: ) > Add a list parser for comma separated integers in flags. > > > Key: MESOS-4926 > URL: https://issues.apache.org/jira/browse/MESOS-4926 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Assignee: Kevin Klues > Labels: mesosphere > > Some flags require lists of integers to be passed in. We should have an > explicit parser for this instead of relying on ad hoc solutions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4927) The flag parser for `hashmap` should live in stout, not mesos.
[ https://issues.apache.org/jira/browse/MESOS-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4927: --- Labels: mesosphere (was: ) > The flag parser for `hashmap` should live in stout, not mesos. > -- > > Key: MESOS-4927 > URL: https://issues.apache.org/jira/browse/MESOS-4927 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Assignee: Kevin Klues > Labels: mesosphere > > The title says it all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4928) We should remove all '.get().' calls on Option / Try variables in the resources abstraction.
[ https://issues.apache.org/jira/browse/MESOS-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4928: --- Labels: mesosphere (was: ) > We should remove all '.get().' calls on Option / Try variables in the > resources abstraction. > > > Key: MESOS-4928 > URL: https://issues.apache.org/jira/browse/MESOS-4928 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Assignee: Kevin Klues > Labels: mesosphere > > When possible, .get() calls should be replaced by -> for Option / Try > variables. This ticket only proposes a blanket change for this in the > resource abstraction files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4926) Add a list parser for comma separated integers in flags.
[ https://issues.apache.org/jira/browse/MESOS-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4926: --- Summary: Add a list parser for comma separated integers in flags. (was: We should add a list parser for comma separated integers in flags.) > Add a list parser for comma separated integers in flags. > > > Key: MESOS-4926 > URL: https://issues.apache.org/jira/browse/MESOS-4926 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Assignee: Kevin Klues > Labels: mesosphere > > Some flags require lists of integers to be passed in. We should have an > explicit parser for this instead of relying on ad hoc solutions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4928) We should remove all '.get().' calls on Option / Try variables in the resources abstraction.
[
https://issues.apache.org/jira/browse/MESOS-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-4928:
---
Description: When possible, {{.get()}} calls should be replaced by {{->}}
for {{Option}} / {{Try}} variables. This ticket only proposes a blanket change
for this in the resource abstraction files. (was: When possible, .get() calls
should be replaced by -> for Option / Try variables. This ticket only proposes
a blanket change for this in the resource abstraction files.)
> We should remove all '.get().' calls on Option / Try variables in the
> resources abstraction.
>
>
> Key: MESOS-4928
> URL: https://issues.apache.org/jira/browse/MESOS-4928
> Project: Mesos
> Issue Type: Improvement
>Reporter: Kevin Klues
>Assignee: Kevin Klues
> Labels: mesosphere
>
> When possible, {{.get()}} calls should be replaced by {{->}} for {{Option}} /
> {{Try}} variables. This ticket only proposes a blanket change for this in
> the resource abstraction files.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4623) Add a stub Nvidia GPU isolator.
[ https://issues.apache.org/jira/browse/MESOS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4623: --- Labels: gpu isolator mesosphere (was: gpu mesosphere) > Add a stub Nvidia GPU isolator. > --- > > Key: MESOS-4623 > URL: https://issues.apache.org/jira/browse/MESOS-4623 > Project: Mesos > Issue Type: Task > Components: isolation >Reporter: Benjamin Mahler >Assignee: Kevin Klues > Labels: gpu, isolator, mesosphere > > We'll first wire up a skeleton Nvidia GPU isolator, which needs to be guarded > by a configure flag due to the dependency on NVML. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4623) Add a stub Nvidia GPU isolator.
[ https://issues.apache.org/jira/browse/MESOS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4623: --- Labels: mesosphere (was: ) > Add a stub Nvidia GPU isolator. > --- > > Key: MESOS-4623 > URL: https://issues.apache.org/jira/browse/MESOS-4623 > Project: Mesos > Issue Type: Task > Components: isolation >Reporter: Benjamin Mahler >Assignee: Kevin Klues > Labels: gpu, mesosphere > > We'll first wire up a skeleton Nvidia GPU isolator, which needs to be guarded > by a configure flag due to the dependency on NVML. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4424) Initial support for GPU resources.
[ https://issues.apache.org/jira/browse/MESOS-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4424: --- Labels: mesosphere (was: ) > Initial support for GPU resources. > -- > > Key: MESOS-4424 > URL: https://issues.apache.org/jira/browse/MESOS-4424 > Project: Mesos > Issue Type: Epic > Components: isolation >Reporter: Benjamin Mahler >Assignee: Kevin Klues > Labels: mesosphere > > Mesos already has generic mechanisms for expressing / isolating resources, > and we'd like to expose GPUs as resources that can be consumed and isolated. > However, GPUs present unique challenges: > * Users may rely on vendor-specific libraries to interact with the device > (e.g. CUDA, HSA, etc), others may rely on portable libraries like OpenCL or > OpenGL. These libraries need to be available from within the container. > * GPU hardware has many attributes that may impose scheduling constraints > (e.g. core count, total memory, topology (via PCI-E, NVLINK, etc), driver > versions, etc). > * Obtaining utilization information requires vendor-specific approaches. > * Isolated sharing of a GPU device requires vendor-specific approaches. > As such, the focus is on supporting a narrow initial use case: homogenous > device-level GPU support: > * Fractional sharing of GPU devices across containers will not be supported > initially, unlike CPU cores. > * Heterogeneity will be supported via other means for now (e.g. using agent > attributes to differentiate hardware profiles, using portable libraries like > OpenCL, etc). > Working group email list: https://groups.google.com/forum/#!forum/mesos-gpus -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4623) Add a stub Nvidia GPU isolator.
[ https://issues.apache.org/jira/browse/MESOS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4623: --- Labels: gpu mesosphere (was: mesosphere) > Add a stub Nvidia GPU isolator. > --- > > Key: MESOS-4623 > URL: https://issues.apache.org/jira/browse/MESOS-4623 > Project: Mesos > Issue Type: Task > Components: isolation >Reporter: Benjamin Mahler >Assignee: Kevin Klues > Labels: gpu, mesosphere > > We'll first wire up a skeleton Nvidia GPU isolator, which needs to be guarded > by a configure flag due to the dependency on NVML. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4928) Remove all '.get().' calls on Option / Try variables in the resources abstraction.
[
https://issues.apache.org/jira/browse/MESOS-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-4928:
---
Summary: Remove all '.get().' calls on Option / Try variables in the
resources abstraction. (was: We should remove all '.get().' calls on Option /
Try variables in the resources abstraction.)
> Remove all '.get().' calls on Option / Try variables in the resources
> abstraction.
> --
>
> Key: MESOS-4928
> URL: https://issues.apache.org/jira/browse/MESOS-4928
> Project: Mesos
> Issue Type: Improvement
>Reporter: Kevin Klues
>Assignee: Kevin Klues
> Labels: mesosphere
>
> When possible, {{.get()}} calls should be replaced by {{->}} for {{Option}} /
> {{Try}} variables. This ticket only proposes a blanket change for this in
> the resource abstraction files, not the code base as a whole. This is in
> preparation for introducing the new GPU resource. Without this change, I
> would need to use the old {{.get()}} calls. Instead, I propose to fix the
> old code surrounding it so that consistency has me doing it the right way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4928) We should remove all '.get().' calls on Option / Try variables in the resources abstraction.
[
https://issues.apache.org/jira/browse/MESOS-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-4928:
---
Description: When possible, {{.get()}} calls should be replaced by {{->}}
for {{Option}} / {{Try}} variables. This ticket only proposes a blanket change
for this in the resource abstraction files, not the code base as a whole. This
is in preparation for introducing the new GPU resource. Without this change, I
would need to use the old {{.get()}} calls. Instead, I propose to fix the old
code surrounding it so that consistency has me doing it the right way.(was:
When possible, {{.get()}} calls should be replaced by {{->}} for {{Option}} /
{{Try}} variables. This ticket only proposes a blanket change for this in the
resource abstraction files.)
> We should remove all '.get().' calls on Option / Try variables in the
> resources abstraction.
>
>
> Key: MESOS-4928
> URL: https://issues.apache.org/jira/browse/MESOS-4928
> Project: Mesos
> Issue Type: Improvement
>Reporter: Kevin Klues
>Assignee: Kevin Klues
> Labels: mesosphere
>
> When possible, {{.get()}} calls should be replaced by {{->}} for {{Option}} /
> {{Try}} variables. This ticket only proposes a blanket change for this in
> the resource abstraction files, not the code base as a whole. This is in
> preparation for introducing the new GPU resource. Without this change, I
> would need to use the old {{.get()}} calls. Instead, I propose to fix the
> old code surrounding it so that consistency has me doing it the right way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4736) DockerContainerizerTest.ROOT_DOCKER_LaunchWithPersistentVolumes fails on CentOS 6
[
https://issues.apache.org/jira/browse/MESOS-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Mathiske updated MESOS-4736:
--
Sprint: Mesosphere Sprint 31
> DockerContainerizerTest.ROOT_DOCKER_LaunchWithPersistentVolumes fails on
> CentOS 6
> -
>
> Key: MESOS-4736
> URL: https://issues.apache.org/jira/browse/MESOS-4736
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.28.0
> Environment: Centos6 + GCC 4.9 on AWS
>Reporter: Joseph Wu
>Assignee: Joseph Wu
> Labels: flaky, mesosphere, test
>
> This test passes consistently on other OS's, but fails consistently on CentOS
> 6.
> Verbose logs from test failure:
> {code}
> [ RUN ] DockerContainerizerTest.ROOT_DOCKER_LaunchWithPersistentVolumes
> I0222 18:16:12.327957 26681 leveldb.cpp:174] Opened db in 7.466102ms
> I0222 18:16:12.330528 26681 leveldb.cpp:181] Compacted db in 2.540139ms
> I0222 18:16:12.330580 26681 leveldb.cpp:196] Created db iterator in 16908ns
> I0222 18:16:12.330592 26681 leveldb.cpp:202] Seeked to beginning of db in
> 1403ns
> I0222 18:16:12.330600 26681 leveldb.cpp:271] Iterated through 0 keys in the
> db in 315ns
> I0222 18:16:12.330634 26681 replica.cpp:779] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0222 18:16:12.331082 26698 recover.cpp:447] Starting replica recovery
> I0222 18:16:12.331289 26698 recover.cpp:473] Replica is in EMPTY status
> I0222 18:16:12.332162 26703 replica.cpp:673] Replica in EMPTY status received
> a broadcasted recover request from (13761)@172.30.2.148:35274
> I0222 18:16:12.332701 26701 recover.cpp:193] Received a recover response from
> a replica in EMPTY status
> I0222 18:16:12.333230 26699 recover.cpp:564] Updating replica status to
> STARTING
> I0222 18:16:12.334102 26698 master.cpp:376] Master
> 652149b4-3932-4d8b-ba6f-8c9d9045be70 (ip-172-30-2-148.mesosphere.io) started
> on 172.30.2.148:35274
> I0222 18:16:12.334116 26698 master.cpp:378] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_http="true" --authenticate_slaves="true"
> --authenticators="crammd5" --authorizers="local"
> --credentials="/tmp/QEhLBS/credentials" --framework_sorter="drf"
> --help="false" --hostname_lookup="true" --http_authenticators="basic"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_completed_frameworks="50"
> --max_completed_tasks_per_framework="1000" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="100secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/usr/local/share/mesos/webui" --work_dir="/tmp/QEhLBS/master"
> --zk_session_timeout="10secs"
> I0222 18:16:12.334354 26698 master.cpp:423] Master only allowing
> authenticated frameworks to register
> I0222 18:16:12.334363 26698 master.cpp:428] Master only allowing
> authenticated slaves to register
> I0222 18:16:12.334369 26698 credentials.hpp:35] Loading credentials for
> authentication from '/tmp/QEhLBS/credentials'
> I0222 18:16:12.335366 26698 master.cpp:468] Using default 'crammd5'
> authenticator
> I0222 18:16:12.335492 26698 master.cpp:537] Using default 'basic' HTTP
> authenticator
> I0222 18:16:12.335623 26698 master.cpp:571] Authorization enabled
> I0222 18:16:12.335752 26703 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 2.314693ms
> I0222 18:16:12.335769 26700 whitelist_watcher.cpp:77] No whitelist given
> I0222 18:16:12.335778 26703 replica.cpp:320] Persisted replica status to
> STARTING
> I0222 18:16:12.335821 26697 hierarchical.cpp:144] Initialized hierarchical
> allocator process
> I0222 18:16:12.335965 26701 recover.cpp:473] Replica is in STARTING status
> I0222 18:16:12.336771 26703 replica.cpp:673] Replica in STARTING status
> received a broadcasted recover request from (13763)@172.30.2.148:35274
> I0222 18:16:12.337191 26696 recover.cpp:193] Received a recover response from
> a replica in STARTING status
> I0222 18:16:12.337635 26700 recover.cpp:564] Updating replica status to VOTING
> I0222 18:16:12.337671 26703 master.cpp:1712] The newly elected leader is
> master@172.30.2.148:35274 with id 652149b4-3932-4d8b-ba6f-8c9d9045be70
> I0222 18:16:12.337698 26703 master.cpp:1725] Elected as the leading master!
> I0222 18:16:12.337713 26703 master.cpp:1470] Recovering from registrar
> I0222 18:16:12.337828 26696 registrar.cpp:307] Recovering registrar
> I0222 18:16:12.339972 26702 leveldb.cpp:304] Persisting metadata (
[jira] [Updated] (MESOS-4794) Add documentation around using the docker containerizer on CentOS 6.
[
https://issues.apache.org/jira/browse/MESOS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Mathiske updated MESOS-4794:
--
Sprint: Mesosphere Sprint 31
> Add documentation around using the docker containerizer on CentOS 6.
>
>
> Key: MESOS-4794
> URL: https://issues.apache.org/jira/browse/MESOS-4794
> Project: Mesos
> Issue Type: Documentation
> Components: docker, documentation
>Affects Versions: 0.28.0
>Reporter: Joseph Wu
> Labels: containerizer, docker, documentation
>
> Support for persistent volumes was added to the docker containerizer in
> [MESOS-3413]. However, this does not work on CentOS 6.
> On CentOS 6, the same {{docker run -v ...}} operation does not perform a
> recursive bind, whereas on every other OS supported by Mesos, docker does a
> recursive bind.
> Docker has already [dropped support for CentOS
> 6|https://github.com/docker/docker/issues/14365], so we should add
> precautionary documentation in case anyone tries to use the docker
> containerizer on CentOS 6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4794) Add documentation around using the docker containerizer on CentOS 6.
[
https://issues.apache.org/jira/browse/MESOS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Mathiske updated MESOS-4794:
--
Labels: containerizer docker documentation mesosphere (was: containerizer
docker documentation)
> Add documentation around using the docker containerizer on CentOS 6.
>
>
> Key: MESOS-4794
> URL: https://issues.apache.org/jira/browse/MESOS-4794
> Project: Mesos
> Issue Type: Documentation
> Components: docker, documentation
>Affects Versions: 0.28.0
>Reporter: Joseph Wu
> Labels: containerizer, docker, documentation, mesosphere
>
> Support for persistent volumes was added to the docker containerizer in
> [MESOS-3413]. However, this does not work on CentOS 6.
> On CentOS 6, the same {{docker run -v ...}} operation does not perform a
> recursive bind, whereas on every other OS supported by Mesos, docker does a
> recursive bind.
> Docker has already [dropped support for CentOS
> 6|https://github.com/docker/docker/issues/14365], so we should add
> precautionary documentation in case anyone tries to use the docker
> containerizer on CentOS 6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4312) Porting Mesos on Power (ppc64le)
[
https://issues.apache.org/jira/browse/MESOS-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen Zhiwei updated MESOS-4312:
---
Shepherd: Vinod Kone (was: Benjamin Mahler)
> Porting Mesos on Power (ppc64le)
>
>
> Key: MESOS-4312
> URL: https://issues.apache.org/jira/browse/MESOS-4312
> Project: Mesos
> Issue Type: Epic
>Reporter: Qian Zhang
>Assignee: Chen Zhiwei
>
> The goal of this ticket is to make IBM Power (ppc64le) as a supported
> hardware platform of Mesos. Currently the latest Mesos code can not be
> successfully built on ppc64le, we will resolve the build errors in this
> ticket, and also make sure Mesos test suite ("make check") can be ran
> successfully on ppc64le.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4810) ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand fails.
[
https://issues.apache.org/jira/browse/MESOS-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Mathiske updated MESOS-4810:
--
Labels: docker mesosphere test (was: docker test)
> ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand fails.
> --
>
> Key: MESOS-4810
> URL: https://issues.apache.org/jira/browse/MESOS-4810
> Project: Mesos
> Issue Type: Bug
> Components: docker
>Affects Versions: 0.28.0
> Environment: CentOS 7 on AWS, both with or without SSL.
>Reporter: Bernd Mathiske
>Assignee: Jie Yu
> Labels: docker, mesosphere, test
>
> {noformat}
> [09:46:46] : [Step 11/11] [ RUN ]
> ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand
> [09:46:46]W: [Step 11/11] I0229 09:46:46.628413 1166 leveldb.cpp:174]
> Opened db in 4.242882ms
> [09:46:46]W: [Step 11/11] I0229 09:46:46.629926 1166 leveldb.cpp:181]
> Compacted db in 1.483621ms
> [09:46:46]W: [Step 11/11] I0229 09:46:46.629966 1166 leveldb.cpp:196]
> Created db iterator in 15498ns
> [09:46:46]W: [Step 11/11] I0229 09:46:46.629977 1166 leveldb.cpp:202]
> Seeked to beginning of db in 1405ns
> [09:46:46]W: [Step 11/11] I0229 09:46:46.629984 1166 leveldb.cpp:271]
> Iterated through 0 keys in the db in 239ns
> [09:46:46]W: [Step 11/11] I0229 09:46:46.630015 1166 replica.cpp:779]
> Replica recovered with log positions 0 -> 0 with 1 holes and 0 unlearned
> [09:46:46]W: [Step 11/11] I0229 09:46:46.630470 1183 recover.cpp:447]
> Starting replica recovery
> [09:46:46]W: [Step 11/11] I0229 09:46:46.630702 1180 recover.cpp:473]
> Replica is in EMPTY status
> [09:46:46]W: [Step 11/11] I0229 09:46:46.631767 1182 replica.cpp:673]
> Replica in EMPTY status received a broadcasted recover request from
> (14567)@172.30.2.124:37431
> [09:46:46]W: [Step 11/11] I0229 09:46:46.632115 1183 recover.cpp:193]
> Received a recover response from a replica in EMPTY status
> [09:46:46]W: [Step 11/11] I0229 09:46:46.632450 1186 recover.cpp:564]
> Updating replica status to STARTING
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633476 1186 master.cpp:375]
> Master 3fbb2fb0-4f18-498b-a440-9acbf6923a13 (ip-172-30-2-124.mesosphere.io)
> started on 172.30.2.124:37431
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633491 1186 master.cpp:377] Flags
> at startup: --acls="" --allocation_interval="1secs"
> --allocator="HierarchicalDRF" --authenticate="true"
> --authenticate_http="true" --authenticate_slaves="true"
> --authenticators="crammd5" --authorizers="local"
> --credentials="/tmp/4UxXoW/credentials" --framework_sorter="drf"
> --help="false" --hostname_lookup="true" --http_authenticators="basic"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_completed_frameworks="50"
> --max_completed_tasks_per_framework="1000" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="100secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/usr/local/share/mesos/webui" --work_dir="/tmp/4UxXoW/master"
> --zk_session_timeout="10secs"
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633677 1186 master.cpp:422]
> Master only allowing authenticated frameworks to register
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633685 1186 master.cpp:427]
> Master only allowing authenticated slaves to register
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633692 1186 credentials.hpp:35]
> Loading credentials for authentication from '/tmp/4UxXoW/credentials'
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633851 1183 leveldb.cpp:304]
> Persisting metadata (8 bytes) to leveldb took 1.191043ms
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633873 1183 replica.cpp:320]
> Persisted replica status to STARTING
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633894 1186 master.cpp:467] Using
> default 'crammd5' authenticator
> [09:46:46]W: [Step 11/11] I0229 09:46:46.634003 1186 master.cpp:536] Using
> default 'basic' HTTP authenticator
> [09:46:46]W: [Step 11/11] I0229 09:46:46.634062 1184 recover.cpp:473]
> Replica is in STARTING status
> [09:46:46]W: [Step 11/11] I0229 09:46:46.634109 1186 master.cpp:570]
> Authorization enabled
> [09:46:46]W: [Step 11/11] I0229 09:46:46.634249 1187
> whitelist_watcher.cpp:77] No whitelist given
> [09:46:46]W: [Step 11/11] I0229 09:46:46.634255 1184 hierarchical.cpp:144]
> Initialized hierarchical allocator process
> [09:46:46]W: [Step 11/11] I0229 09:46:46.634884 1187 replica.cpp:673]
> Replica in STARTING stat
[jira] [Updated] (MESOS-4835) CgroupsAnyHierarchyWithFreezerTest.ROOT_CGROUPS_DestroyTracedProcess is flaky
[
https://issues.apache.org/jira/browse/MESOS-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Mathiske updated MESOS-4835:
--
Sprint: Mesosphere Sprint 31
> CgroupsAnyHierarchyWithFreezerTest.ROOT_CGROUPS_DestroyTracedProcess is flaky
> -
>
> Key: MESOS-4835
> URL: https://issues.apache.org/jira/browse/MESOS-4835
> Project: Mesos
> Issue Type: Bug
> Environment: Seen on Ubuntu 15 & Debian 8, GCC 4.9
>Reporter: Joseph Wu
> Labels: flaky, mesosphere, test
>
> Verbose logs:
> {code}
> [ RUN ]
> CgroupsAnyHierarchyWithFreezerTest.ROOT_CGROUPS_DestroyTracedProcess
> I0302 00:43:14.127846 11755 cgroups.cpp:2427] Freezing cgroup
> /sys/fs/cgroup/freezer/mesos_test
> I0302 00:43:14.267411 11758 cgroups.cpp:1409] Successfully froze cgroup
> /sys/fs/cgroup/freezer/mesos_test after 139.46496ms
> I0302 00:43:14.409395 11751 cgroups.cpp:2445] Thawing cgroup
> /sys/fs/cgroup/freezer/mesos_test
> I0302 00:43:14.551304 11751 cgroups.cpp:1438] Successfullly thawed cgroup
> /sys/fs/cgroup/freezer/mesos_test after 141.811968ms
> ../../src/tests/containerizer/cgroups_tests.cpp:949: Failure
> Value of: ::waitpid(pid, &status, 0)
> Actual: 23809
> Expected: -1
> ../../src/tests/containerizer/cgroups_tests.cpp:950: Failure
> Value of: (*__errno_location ())
> Actual: 0
> Expected: 10
> [ FAILED ]
> CgroupsAnyHierarchyWithFreezerTest.ROOT_CGROUPS_DestroyTracedProcess (1055 ms)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4835) CgroupsAnyHierarchyWithFreezerTest.ROOT_CGROUPS_DestroyTracedProcess is flaky
[
https://issues.apache.org/jira/browse/MESOS-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Mathiske updated MESOS-4835:
--
Labels: flaky mesosphere test (was: flaky test)
> CgroupsAnyHierarchyWithFreezerTest.ROOT_CGROUPS_DestroyTracedProcess is flaky
> -
>
> Key: MESOS-4835
> URL: https://issues.apache.org/jira/browse/MESOS-4835
> Project: Mesos
> Issue Type: Bug
> Environment: Seen on Ubuntu 15 & Debian 8, GCC 4.9
>Reporter: Joseph Wu
> Labels: flaky, mesosphere, test
>
> Verbose logs:
> {code}
> [ RUN ]
> CgroupsAnyHierarchyWithFreezerTest.ROOT_CGROUPS_DestroyTracedProcess
> I0302 00:43:14.127846 11755 cgroups.cpp:2427] Freezing cgroup
> /sys/fs/cgroup/freezer/mesos_test
> I0302 00:43:14.267411 11758 cgroups.cpp:1409] Successfully froze cgroup
> /sys/fs/cgroup/freezer/mesos_test after 139.46496ms
> I0302 00:43:14.409395 11751 cgroups.cpp:2445] Thawing cgroup
> /sys/fs/cgroup/freezer/mesos_test
> I0302 00:43:14.551304 11751 cgroups.cpp:1438] Successfullly thawed cgroup
> /sys/fs/cgroup/freezer/mesos_test after 141.811968ms
> ../../src/tests/containerizer/cgroups_tests.cpp:949: Failure
> Value of: ::waitpid(pid, &status, 0)
> Actual: 23809
> Expected: -1
> ../../src/tests/containerizer/cgroups_tests.cpp:950: Failure
> Value of: (*__errno_location ())
> Actual: 0
> Expected: 10
> [ FAILED ]
> CgroupsAnyHierarchyWithFreezerTest.ROOT_CGROUPS_DestroyTracedProcess (1055 ms)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4912) LinuxFilesystemIsolatorTest.ROOT_MultipleContainers fails.
[
https://issues.apache.org/jira/browse/MESOS-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Mathiske updated MESOS-4912:
--
Labels: mesosphere (was: )
> LinuxFilesystemIsolatorTest.ROOT_MultipleContainers fails.
> --
>
> Key: MESOS-4912
> URL: https://issues.apache.org/jira/browse/MESOS-4912
> Project: Mesos
> Issue Type: Bug
> Components: isolation
>Affects Versions: 0.28.0
> Environment: CenOS 7, SSL
>Reporter: Bernd Mathiske
> Labels: mesosphere
>
> Observed on our CI:
> {noformat}
> [09:34:15] : [Step 11/11] [ RUN ]
> LinuxFilesystemIsolatorTest.ROOT_MultipleContainers
> [09:34:19]W: [Step 11/11] I0309 09:34:19.906719 2357 linux.cpp:81] Making
> '/tmp/MLVLnv' a shared mount
> [09:34:19]W: [Step 11/11] I0309 09:34:19.923548 2357
> linux_launcher.cpp:101] Using /sys/fs/cgroup/freezer as the freezer hierarchy
> for the Linux launcher
> [09:34:19]W: [Step 11/11] I0309 09:34:19.924705 2376
> containerizer.cpp:666] Starting container
> 'da610f7f-a709-4de8-94d3-74f4a520619b' for executor 'test_executor1' of
> framework ''
> [09:34:19]W: [Step 11/11] I0309 09:34:19.925355 2371 provisioner.cpp:285]
> Provisioning image rootfs
> '/tmp/MLVLnv/provisioner/containers/da610f7f-a709-4de8-94d3-74f4a520619b/backends/copy/rootfses/0d7e047a-50f1-490b-bb58-00e9c49628d0'
> for container da610f7f-a709-4de8-94d3-74f4a520619b
> [09:34:19]W: [Step 11/11] I0309 09:34:19.925881 2377 copy.cpp:127] Copying
> layer path '/tmp/MLVLnv/test_image1' to rootfs
> '/tmp/MLVLnv/provisioner/containers/da610f7f-a709-4de8-94d3-74f4a520619b/backends/copy/rootfses/0d7e047a-50f1-490b-bb58-00e9c49628d0'
> [09:34:30]W: [Step 11/11] I0309 09:34:30.835127 2376 linux.cpp:355] Bind
> mounting work directory from
> '/tmp/MLVLnv/slaves/test_slave/frameworks/executors/test_executor1/runs/da610f7f-a709-4de8-94d3-74f4a520619b'
> to
> '/tmp/MLVLnv/provisioner/containers/da610f7f-a709-4de8-94d3-74f4a520619b/backends/copy/rootfses/0d7e047a-50f1-490b-bb58-00e9c49628d0/mnt/mesos/sandbox'
> for container da610f7f-a709-4de8-94d3-74f4a520619b
> [09:34:30]W: [Step 11/11] I0309 09:34:30.835392 2376 linux.cpp:683]
> Changing the ownership of the persistent volume at
> '/tmp/MLVLnv/volumes/roles/test_role/persistent_volume_id' with uid 0 and gid > 0
> [09:34:30]W: [Step 11/11] I0309 09:34:30.840425 2376 linux.cpp:723]
> Mounting '/tmp/MLVLnv/volumes/roles/test_role/persistent_volume_id' to
> '/tmp/MLVLnv/provisioner/containers/da610f7f-a709-4de8-94d3-74f4a520619b/backends/copy/rootfses/0d7e047a-50f1-490b-bb58-00e9c49628d0/mnt/mesos/sandbox/volume'
> for persistent volume disk(test_role)[persistent_volume_id:volume]:32 of
> container da610f7f-a709-4de8-94d3-74f4a520619b
> [09:34:30]W: [Step 11/11] I0309 09:34:30.843878 2374
> linux_launcher.cpp:304] Cloning child process with flags = CLONE_NEWNS
> [09:34:30]W: [Step 11/11] I0309 09:34:30.848302 2371
> containerizer.cpp:666] Starting container
> 'fe4729c5-1e63-4cc6-a2e3-fe5006ffe087' for executor 'test_executor2' of
> framework ''
> [09:34:30]W: [Step 11/11] I0309 09:34:30.848758 2371
> containerizer.cpp:1392] Destroying container
> 'da610f7f-a709-4de8-94d3-74f4a520619b'
> [09:34:30]W: [Step 11/11] I0309 09:34:30.848865 2373 provisioner.cpp:285]
> Provisioning image rootfs
> '/tmp/MLVLnv/provisioner/containers/fe4729c5-1e63-4cc6-a2e3-fe5006ffe087/backends/copy/rootfses/518b2464-43dd-47b0-9648-e78aedde6917'
> for container fe4729c5-1e63-4cc6-a2e3-fe5006ffe087
> [09:34:30]W: [Step 11/11] I0309 09:34:30.849449 2375 copy.cpp:127] Copying
> layer path '/tmp/MLVLnv/test_image2' to rootfs
> '/tmp/MLVLnv/provisioner/containers/fe4729c5-1e63-4cc6-a2e3-fe5006ffe087/backends/copy/rootfses/518b2464-43dd-47b0-9648-e78aedde6917'
> [09:34:30]W: [Step 11/11] I0309 09:34:30.854038 2374 cgroups.cpp:2427]
> Freezing cgroup
> /sys/fs/cgroup/freezer/mesos/da610f7f-a709-4de8-94d3-74f4a520619b
> [09:34:30]W: [Step 11/11] I0309 09:34:30.856693 2372 cgroups.cpp:1409]
> Successfully froze cgroup
> /sys/fs/cgroup/freezer/mesos/da610f7f-a709-4de8-94d3-74f4a520619b after
> 2.608128ms
> [09:34:30]W: [Step 11/11] I0309 09:34:30.859237 2377 cgroups.cpp:2445]
> Thawing cgroup
> /sys/fs/cgroup/freezer/mesos/da610f7f-a709-4de8-94d3-74f4a520619b
> [09:34:30]W: [Step 11/11] I0309 09:34:30.861454 2377 cgroups.cpp:1438]
> Successfullly thawed cgroup
> /sys/fs/cgroup/freezer/mesos/da610f7f-a709-4de8-94d3-74f4a520619b after 2176us
> [09:34:30]W: [Step 11/11] I0309 09:34:30.934608 2378
> containerizer.cpp:1608] Executor for container
> 'da610f7f-a709-4de8-94d3-74f4a520619b' has exited
> [09:34:30]W: [Step 11/11] I0309 09:34:30.937692 2372 linux.cpp:798]
> Unmounting volume
> '/tmp/MLVLnv/provisioner/containers/da610f7f-a7
[jira] [Updated] (MESOS-4912) LinuxFilesystemIsolatorTest.ROOT_MultipleContainers fails.
[
https://issues.apache.org/jira/browse/MESOS-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Mathiske updated MESOS-4912:
--
Sprint: Mesosphere Sprint 31
> LinuxFilesystemIsolatorTest.ROOT_MultipleContainers fails.
> --
>
> Key: MESOS-4912
> URL: https://issues.apache.org/jira/browse/MESOS-4912
> Project: Mesos
> Issue Type: Bug
> Components: isolation
>Affects Versions: 0.28.0
> Environment: CenOS 7, SSL
>Reporter: Bernd Mathiske
> Labels: mesosphere
>
> Observed on our CI:
> {noformat}
> [09:34:15] : [Step 11/11] [ RUN ]
> LinuxFilesystemIsolatorTest.ROOT_MultipleContainers
> [09:34:19]W: [Step 11/11] I0309 09:34:19.906719 2357 linux.cpp:81] Making
> '/tmp/MLVLnv' a shared mount
> [09:34:19]W: [Step 11/11] I0309 09:34:19.923548 2357
> linux_launcher.cpp:101] Using /sys/fs/cgroup/freezer as the freezer hierarchy
> for the Linux launcher
> [09:34:19]W: [Step 11/11] I0309 09:34:19.924705 2376
> containerizer.cpp:666] Starting container
> 'da610f7f-a709-4de8-94d3-74f4a520619b' for executor 'test_executor1' of
> framework ''
> [09:34:19]W: [Step 11/11] I0309 09:34:19.925355 2371 provisioner.cpp:285]
> Provisioning image rootfs
> '/tmp/MLVLnv/provisioner/containers/da610f7f-a709-4de8-94d3-74f4a520619b/backends/copy/rootfses/0d7e047a-50f1-490b-bb58-00e9c49628d0'
> for container da610f7f-a709-4de8-94d3-74f4a520619b
> [09:34:19]W: [Step 11/11] I0309 09:34:19.925881 2377 copy.cpp:127] Copying
> layer path '/tmp/MLVLnv/test_image1' to rootfs
> '/tmp/MLVLnv/provisioner/containers/da610f7f-a709-4de8-94d3-74f4a520619b/backends/copy/rootfses/0d7e047a-50f1-490b-bb58-00e9c49628d0'
> [09:34:30]W: [Step 11/11] I0309 09:34:30.835127 2376 linux.cpp:355] Bind
> mounting work directory from
> '/tmp/MLVLnv/slaves/test_slave/frameworks/executors/test_executor1/runs/da610f7f-a709-4de8-94d3-74f4a520619b'
> to
> '/tmp/MLVLnv/provisioner/containers/da610f7f-a709-4de8-94d3-74f4a520619b/backends/copy/rootfses/0d7e047a-50f1-490b-bb58-00e9c49628d0/mnt/mesos/sandbox'
> for container da610f7f-a709-4de8-94d3-74f4a520619b
> [09:34:30]W: [Step 11/11] I0309 09:34:30.835392 2376 linux.cpp:683]
> Changing the ownership of the persistent volume at
> '/tmp/MLVLnv/volumes/roles/test_role/persistent_volume_id' with uid 0 and gid > 0
> [09:34:30]W: [Step 11/11] I0309 09:34:30.840425 2376 linux.cpp:723]
> Mounting '/tmp/MLVLnv/volumes/roles/test_role/persistent_volume_id' to
> '/tmp/MLVLnv/provisioner/containers/da610f7f-a709-4de8-94d3-74f4a520619b/backends/copy/rootfses/0d7e047a-50f1-490b-bb58-00e9c49628d0/mnt/mesos/sandbox/volume'
> for persistent volume disk(test_role)[persistent_volume_id:volume]:32 of
> container da610f7f-a709-4de8-94d3-74f4a520619b
> [09:34:30]W: [Step 11/11] I0309 09:34:30.843878 2374
> linux_launcher.cpp:304] Cloning child process with flags = CLONE_NEWNS
> [09:34:30]W: [Step 11/11] I0309 09:34:30.848302 2371
> containerizer.cpp:666] Starting container
> 'fe4729c5-1e63-4cc6-a2e3-fe5006ffe087' for executor 'test_executor2' of
> framework ''
> [09:34:30]W: [Step 11/11] I0309 09:34:30.848758 2371
> containerizer.cpp:1392] Destroying container
> 'da610f7f-a709-4de8-94d3-74f4a520619b'
> [09:34:30]W: [Step 11/11] I0309 09:34:30.848865 2373 provisioner.cpp:285]
> Provisioning image rootfs
> '/tmp/MLVLnv/provisioner/containers/fe4729c5-1e63-4cc6-a2e3-fe5006ffe087/backends/copy/rootfses/518b2464-43dd-47b0-9648-e78aedde6917'
> for container fe4729c5-1e63-4cc6-a2e3-fe5006ffe087
> [09:34:30]W: [Step 11/11] I0309 09:34:30.849449 2375 copy.cpp:127] Copying
> layer path '/tmp/MLVLnv/test_image2' to rootfs
> '/tmp/MLVLnv/provisioner/containers/fe4729c5-1e63-4cc6-a2e3-fe5006ffe087/backends/copy/rootfses/518b2464-43dd-47b0-9648-e78aedde6917'
> [09:34:30]W: [Step 11/11] I0309 09:34:30.854038 2374 cgroups.cpp:2427]
> Freezing cgroup
> /sys/fs/cgroup/freezer/mesos/da610f7f-a709-4de8-94d3-74f4a520619b
> [09:34:30]W: [Step 11/11] I0309 09:34:30.856693 2372 cgroups.cpp:1409]
> Successfully froze cgroup
> /sys/fs/cgroup/freezer/mesos/da610f7f-a709-4de8-94d3-74f4a520619b after
> 2.608128ms
> [09:34:30]W: [Step 11/11] I0309 09:34:30.859237 2377 cgroups.cpp:2445]
> Thawing cgroup
> /sys/fs/cgroup/freezer/mesos/da610f7f-a709-4de8-94d3-74f4a520619b
> [09:34:30]W: [Step 11/11] I0309 09:34:30.861454 2377 cgroups.cpp:1438]
> Successfullly thawed cgroup
> /sys/fs/cgroup/freezer/mesos/da610f7f-a709-4de8-94d3-74f4a520619b after 2176us
> [09:34:30]W: [Step 11/11] I0309 09:34:30.934608 2378
> containerizer.cpp:1608] Executor for container
> 'da610f7f-a709-4de8-94d3-74f4a520619b' has exited
> [09:34:30]W: [Step 11/11] I0309 09:34:30.937692 2372 linux.cpp:798]
> Unmounting volume
> '/tmp/MLVLnv/provisioner/containers/da610f7f-a
[jira] [Updated] (MESOS-4312) Porting Mesos on Power (ppc64le)
[
https://issues.apache.org/jira/browse/MESOS-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen Zhiwei updated MESOS-4312:
---
Shepherd: Vinod Kone (was: Vinod Kone)
> Porting Mesos on Power (ppc64le)
>
>
> Key: MESOS-4312
> URL: https://issues.apache.org/jira/browse/MESOS-4312
> Project: Mesos
> Issue Type: Epic
>Reporter: Qian Zhang
>Assignee: Chen Zhiwei
>
> The goal of this ticket is to make IBM Power (ppc64le) as a supported
> hardware platform of Mesos. Currently the latest Mesos code can not be
> successfully built on ppc64le, we will resolve the build errors in this
> ticket, and also make sure Mesos test suite ("make check") can be ran
> successfully on ppc64le.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4312) Porting Mesos on Power (ppc64le)
[
https://issues.apache.org/jira/browse/MESOS-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen Zhiwei updated MESOS-4312:
---
Description:
The goal of this ticket is to make IBM Power (ppc64le) as a supported hardware
platform of Mesos. Currently the latest Mesos code can not be successfully
built on ppc64le, we will resolve the build errors in this ticket, and also
make sure Mesos test suite ("make check") can be ran successfully on ppc64le.
The review list:
* Protobuf: https://reviews.apache.org/r/44257/
* Glog: https://reviews.apache.org/r/44252/
* Libev: https://reviews.apache.org/r/44378/
* Http-parser: https://reviews.apache.org/r/44372/
* Zookeeper: https://reviews.apache.org/r/44376/
* Leveldb: https://reviews.apache.org/r/44382/
* Mesos: https://reviews.apache.org/r/42551/
was:The goal of this ticket is to make IBM Power (ppc64le) as a supported
hardware platform of Mesos. Currently the latest Mesos code can not be
successfully built on ppc64le, we will resolve the build errors in this ticket,
and also make sure Mesos test suite ("make check") can be ran successfully on
ppc64le.
> Porting Mesos on Power (ppc64le)
>
>
> Key: MESOS-4312
> URL: https://issues.apache.org/jira/browse/MESOS-4312
> Project: Mesos
> Issue Type: Epic
>Reporter: Qian Zhang
>Assignee: Chen Zhiwei
>
> The goal of this ticket is to make IBM Power (ppc64le) as a supported
> hardware platform of Mesos. Currently the latest Mesos code can not be
> successfully built on ppc64le, we will resolve the build errors in this
> ticket, and also make sure Mesos test suite ("make check") can be ran
> successfully on ppc64le.
> The review list:
> * Protobuf: https://reviews.apache.org/r/44257/
> * Glog: https://reviews.apache.org/r/44252/
> * Libev: https://reviews.apache.org/r/44378/
> * Http-parser: https://reviews.apache.org/r/44372/
> * Zookeeper: https://reviews.apache.org/r/44376/
> * Leveldb: https://reviews.apache.org/r/44382/
> * Mesos: https://reviews.apache.org/r/42551/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4312) Porting Mesos on Power (ppc64le)
[
https://issues.apache.org/jira/browse/MESOS-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinod Kone updated MESOS-4312:
--
Epic Name: Power
> Porting Mesos on Power (ppc64le)
>
>
> Key: MESOS-4312
> URL: https://issues.apache.org/jira/browse/MESOS-4312
> Project: Mesos
> Issue Type: Epic
>Reporter: Qian Zhang
>Assignee: Chen Zhiwei
>
> The goal of this ticket is to make IBM Power (ppc64le) as a supported
> hardware platform of Mesos. Currently the latest Mesos code can not be
> successfully built on ppc64le, we will resolve the build errors in this
> ticket, and also make sure Mesos test suite ("make check") can be ran
> successfully on ppc64le.
> The review list:
> * Protobuf: https://reviews.apache.org/r/44257/
> * Glog: https://reviews.apache.org/r/44252/
> * Libev: https://reviews.apache.org/r/44378/
> * Http-parser: https://reviews.apache.org/r/44372/
> * Zookeeper: https://reviews.apache.org/r/44376/
> * Leveldb: https://reviews.apache.org/r/44382/
> * Mesos: https://reviews.apache.org/r/42551/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4803) Update vendored libev to 4.22
[ https://issues.apache.org/jira/browse/MESOS-4803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-4803: -- Shepherd: Vinod Kone (was: Benjamin Mahler) > Update vendored libev to 4.22 > - > > Key: MESOS-4803 > URL: https://issues.apache.org/jira/browse/MESOS-4803 > Project: Mesos > Issue Type: Improvement >Reporter: Qian Zhang >Assignee: Chen Zhiwei > > The motivation is that libev 4.22 has officially supported IBM Power > (ppc64le), so this is needed by > [MESOS-4312|https://issues.apache.org/jira/browse/MESOS-4312]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4802) Update leveldb patch file to suport PowerPC LE
[ https://issues.apache.org/jira/browse/MESOS-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-4802: -- Shepherd: Vinod Kone (was: Benjamin Mahler) > Update leveldb patch file to suport PowerPC LE > -- > > Key: MESOS-4802 > URL: https://issues.apache.org/jira/browse/MESOS-4802 > Project: Mesos > Issue Type: Improvement >Reporter: Qian Zhang >Assignee: Chen Zhiwei > > See: https://github.com/google/leveldb/releases/tag/v1.18 for improvements / > bug fixes. > The motivation is that leveldb 1.18 has officially supported IBM Power > (ppc64le), so this is needed by > [MESOS-4312|https://issues.apache.org/jira/browse/MESOS-4312]. > Update: Since someone updated leveldb to 1.4, so I only update the patch file > to support PowerPC LE. Because I don't think upgrade 3rdparty library > frequently is a good thing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4678) Upgrade vendored Protobuf to 2.6.1
[
https://issues.apache.org/jira/browse/MESOS-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinod Kone updated MESOS-4678:
--
Shepherd: Vinod Kone
Summary: Upgrade vendored Protobuf to 2.6.1 (was: Upgrade vendored
Protobuf)
> Upgrade vendored Protobuf to 2.6.1
> --
>
> Key: MESOS-4678
> URL: https://issues.apache.org/jira/browse/MESOS-4678
> Project: Mesos
> Issue Type: Improvement
> Components: general
>Reporter: Neil Conway
>Assignee: Chen Zhiwei
> Labels: 3rdParty, mesosphere, protobuf, tech-debt
>
> We currently vendor Protobuf 2.5.0. We should upgrade to Protobuf 2.6.1. This
> introduces various bugfixes, performance improvements, and at least one new
> feature we might want to eventually take advantage of ({{map}} data type).
> AFAIK there should be no backward compatibility concerns.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4612) Update vendored ZooKeeper to 3.4.8
[ https://issues.apache.org/jira/browse/MESOS-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-4612: -- Shepherd: Vinod Kone > Update vendored ZooKeeper to 3.4.8 > -- > > Key: MESOS-4612 > URL: https://issues.apache.org/jira/browse/MESOS-4612 > Project: Mesos > Issue Type: Improvement >Reporter: Cody Maloney >Assignee: Chen Zhiwei > Labels: mesosphere, tech-debt, zookeeper > > See: http://zookeeper.apache.org/doc/r3.4.8/releasenotes.html for > improvements / bug fixes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4897) Update test cases to support PowerPC LE
[ https://issues.apache.org/jira/browse/MESOS-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-4897: -- Shepherd: Vinod Kone > Update test cases to support PowerPC LE > --- > > Key: MESOS-4897 > URL: https://issues.apache.org/jira/browse/MESOS-4897 > Project: Mesos > Issue Type: Improvement >Reporter: Chen Zhiwei >Assignee: Chen Zhiwei > > Some docker related test cases will be failed on PowerPC LE, since the Docker > image 'alpine' can't be able to run on PowerPC LE platform. > On PowerPC LE platform, the test cases can use Docker image 'ppc64le/busybox'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4879) Update glog patch to suport PowerPC LE
[ https://issues.apache.org/jira/browse/MESOS-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-4879: -- Shepherd: Vinod Kone > Update glog patch to suport PowerPC LE > -- > > Key: MESOS-4879 > URL: https://issues.apache.org/jira/browse/MESOS-4879 > Project: Mesos > Issue Type: Improvement >Reporter: Chen Zhiwei >Assignee: Chen Zhiwei > > This is a part of PowerPC LE porting -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4312) Porting Mesos on Power (ppc64le)
[
https://issues.apache.org/jira/browse/MESOS-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinod Kone updated MESOS-4312:
--
Epic Name: PowerPC (was: Power)
> Porting Mesos on Power (ppc64le)
>
>
> Key: MESOS-4312
> URL: https://issues.apache.org/jira/browse/MESOS-4312
> Project: Mesos
> Issue Type: Epic
>Reporter: Qian Zhang
>Assignee: Chen Zhiwei
>
> The goal of this ticket is to make IBM Power (ppc64le) as a supported
> hardware platform of Mesos. Currently the latest Mesos code can not be
> successfully built on ppc64le, we will resolve the build errors in this
> ticket, and also make sure Mesos test suite ("make check") can be ran
> successfully on ppc64le.
> The review list:
> * Protobuf: https://reviews.apache.org/r/44257/
> * Glog: https://reviews.apache.org/r/44252/
> * Libev: https://reviews.apache.org/r/44378/
> * Http-parser: https://reviews.apache.org/r/44372/
> * Zookeeper: https://reviews.apache.org/r/44376/
> * Leveldb: https://reviews.apache.org/r/44382/
> * Mesos: https://reviews.apache.org/r/42551/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4312) Porting Mesos on Power (ppc64le)
[
https://issues.apache.org/jira/browse/MESOS-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193344#comment-15193344
]
Vinod Kone commented on MESOS-4312:
---
I updated the linked tickets to issue tickets instead. Can you update *each*
ticket to its correct state (e.g., Reviewable) and add the required details
(e.g., review link)?
> Porting Mesos on Power (ppc64le)
>
>
> Key: MESOS-4312
> URL: https://issues.apache.org/jira/browse/MESOS-4312
> Project: Mesos
> Issue Type: Epic
>Reporter: Qian Zhang
>Assignee: Chen Zhiwei
>
> The goal of this ticket is to make IBM Power (ppc64le) as a supported
> hardware platform of Mesos. Currently the latest Mesos code can not be
> successfully built on ppc64le, we will resolve the build errors in this
> ticket, and also make sure Mesos test suite ("make check") can be ran
> successfully on ppc64le.
> The review list:
> * Protobuf: https://reviews.apache.org/r/44257/
> * Glog: https://reviews.apache.org/r/44252/
> * Libev: https://reviews.apache.org/r/44378/
> * Http-parser: https://reviews.apache.org/r/44372/
> * Zookeeper: https://reviews.apache.org/r/44376/
> * Leveldb: https://reviews.apache.org/r/44382/
> * Mesos: https://reviews.apache.org/r/42551/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2043) framework auth fail with timeout error and never get authenticated
[
https://issues.apache.org/jira/browse/MESOS-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193349#comment-15193349
]
Vinod Kone commented on MESOS-2043:
---
[~kevincox] Can you attach the logs with 0.27.1?
> framework auth fail with timeout error and never get authenticated
> --
>
> Key: MESOS-2043
> URL: https://issues.apache.org/jira/browse/MESOS-2043
> Project: Mesos
> Issue Type: Bug
> Components: master, scheduler driver, security, slave
>Affects Versions: 0.21.0
>Reporter: Bhuvan Arumugam
>Priority: Critical
> Labels: mesosphere, security
> Attachments: aurora-scheduler.20141104-1606-1706.log,
> mesos-master.20141104-1606-1706.log
>
>
> I'm facing this issue in master as of
> https://github.com/apache/mesos/commit/74ea59e144d131814c66972fb0cc14784d3503d4
> As [~adam-mesos] mentioned in IRC, this sounds similar to MESOS-1866. I'm
> running 1 master and 1 scheduler (aurora). The framework authentication fail
> due to time out:
> error on mesos master:
> {code}
> I1104 19:37:17.741449 8329 master.cpp:3874] Authenticating
> scheduler-d2d4437b-d375-4467-a583-362152fe065a@SCHEDULER_IP:8083
> I1104 19:37:17.741585 8329 master.cpp:3885] Using default CRAM-MD5
> authenticator
> I1104 19:37:17.742106 8336 authenticator.hpp:169] Creating new server SASL
> connection
> W1104 19:37:22.742959 8329 master.cpp:3953] Authentication timed out
> W1104 19:37:22.743548 8329 master.cpp:3930] Failed to authenticate
> scheduler-d2d4437b-d375-4467-a583-362152fe065a@SCHEDULER_IP:8083:
> Authentication discarded
> {code}
> scheduler error:
> {code}
> I1104 19:38:57.885486 49012 sched.cpp:283] Authenticating with master
> master@MASTER_IP:PORT
> I1104 19:38:57.885928 49002 authenticatee.hpp:133] Creating new client SASL
> connection
> I1104 19:38:57.890581 49007 authenticatee.hpp:224] Received SASL
> authentication mechanisms: CRAM-MD5
> I1104 19:38:57.890656 49007 authenticatee.hpp:250] Attempting to authenticate
> with mechanism 'CRAM-MD5'
> W1104 19:39:02.891196 49005 sched.cpp:378] Authentication timed out
> I1104 19:39:02.891850 49018 sched.cpp:338] Failed to authenticate with master
> master@MASTER_IP:PORT: Authentication discarded
> {code}
> Looks like 2 instances {{scheduler-20f88a53-5945-4977-b5af-28f6c52d3c94}} &
> {{scheduler-d2d4437b-d375-4467-a583-362152fe065a}} of same framework is
> trying to authenticate and fail.
> {code}
> W1104 19:36:30.769420 8319 master.cpp:3930] Failed to authenticate
> scheduler-20f88a53-5945-4977-b5af-28f6c52d3c94@SCHEDULER_IP:8083: Failed to
> communicate with authenticatee
> I1104 19:36:42.701441 8328 master.cpp:3860] Queuing up authentication
> request from scheduler-d2d4437b-d375-4467-a583-362152fe065a@SCHEDULER_IP:8083
> because authentication is still in progress
> {code}
> Restarting master and scheduler didn't fix it.
> This particular issue happen with 1 master and 1 scheduler after MESOS-1866
> is fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-4935) Docker executor does not track containers killed out-of-band.
Alexander Rukletsov created MESOS-4935:
--
Summary: Docker executor does not track containers killed
out-of-band.
Key: MESOS-4935
URL: https://issues.apache.org/jira/browse/MESOS-4935
Project: Mesos
Issue Type: Improvement
Components: docker
Reporter: Alexander Rukletsov
If a docker container is killed out-of-band (using docker CLI), the docker
executor does not exit and hence does not report a terminal state to Mesos. It
happens because the docker executor does not monitor the state of the
underlying container and waits for an explicit {{killTask()}} or
{{shutdown()}}:
https://github.com/apache/mesos/blob/69b2ad528dd79979a8ee113a8edbbab2669e32e6/src/docker/executor.cpp#L278
We should consider introducing a container observer actor, similar to
{{ReaperProcess}} we have for command executor-based tasks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4924) MAC OS build failed
[
https://issues.apache.org/jira/browse/MESOS-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193354#comment-15193354
]
Steve Niemitz commented on MESOS-4924:
--
Review up at https://reviews.apache.org/r/44785/
> MAC OS build failed
> ---
>
> Key: MESOS-4924
> URL: https://issues.apache.org/jira/browse/MESOS-4924
> Project: Mesos
> Issue Type: Bug
>Reporter: Guangya Liu
>Priority: Blocker
>
> Seems caused by https://reviews.apache.org/r/41049/ [~SteveNiemitz]
> {code}
> -std=c++11 -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11
> -Qunused-arguments -I/usr/local/opt/subversion/include/subversion-1
> -I/usr/include/apr-1 -I/usr/include/apr-1.0 -Qunused-arguments
> build/temp.macosx-10.10-intel-2.7/src/mesos/executor/mesos_executor_driver_impl.o
> build/temp.macosx-10.10-intel-2.7/src/mesos/executor/module.o
> build/temp.macosx-10.10-intel-2.7/src/mesos/executor/proxy_executor.o
> /Users/gyliu/git/mesos/build/src/.libs/libmesos_no_3rdparty.a
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/.libs/libprocess.a
> /Users/gyliu/git/mesos/build/3rdparty/leveldb-1.4/libleveldb.a
> /Users/gyliu/git/mesos/build/3rdparty/zookeeper-3.4.5/src/c/.libs/libzookeeper_mt.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/glog-0.3.3/.libs/libglog.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/protobuf-2.5.0/src/.libs/libprotobuf.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/libev-4.15/.libs/libev.a
> -o build/lib.macosx-10.10-intel-2.7/mesos/executor/_executor.so
> -Wl,--as-needed -L/usr/local/opt/subversion/lib -lsasl2 -lsvn_delta-1
> -lsvn_subr-1 -lapr-1 -lcurl -lz
> ld: unknown option: --as-needed
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> error: command 'g++' failed with exit status 1
> make[2]: *** [python/dist/mesos.executor-0.29.0-py2.7-macosx-10.10-intel.egg]
> Error 1
> make[2]: *** Waiting for unfinished jobs
> g++ -bundle -undefined dynamic_lookup -arch x86_64 -arch i386 -Wl,-F.
> -L/usr/local/opt/subversion/lib -g -O0 -g -O0 -Wno-unused-local-typedef
> -std=c++11 -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11
> -Qunused-arguments -I/usr/local/opt/subversion/include/subversion-1
> -I/usr/include/apr-1 -I/usr/include/apr-1.0 -Qunused-arguments
> build/temp.macosx-10.10-intel-2.7/src/mesos/scheduler/mesos_scheduler_driver_impl.o
> build/temp.macosx-10.10-intel-2.7/src/mesos/scheduler/module.o
> build/temp.macosx-10.10-intel-2.7/src/mesos/scheduler/proxy_scheduler.o
> /Users/gyliu/git/mesos/build/src/.libs/libmesos_no_3rdparty.a
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/.libs/libprocess.a
> /Users/gyliu/git/mesos/build/3rdparty/leveldb-1.4/libleveldb.a
> /Users/gyliu/git/mesos/build/3rdparty/zookeeper-3.4.5/src/c/.libs/libzookeeper_mt.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/glog-0.3.3/.libs/libglog.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/protobuf-2.5.0/src/.libs/libprotobuf.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/libev-4.15/.libs/libev.a
> -o build/lib.macosx-10.10-intel-2.7/mesos/scheduler/_scheduler.so
> -Wl,--as-needed -L/usr/local/opt/subversion/lib -lsasl2 -lsvn_delta-1
> -lsvn_subr-1 -lapr-1 -lcurl -lz
> ld: unknown option: --as-needed
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> error: command 'g++' failed with exit status 1
> make[2]: ***
> [python/dist/mesos.scheduler-0.29.0-py2.7-macosx-10.10-intel.egg] Error 1
> make[1]: *** [all] Error 2
> make: *** [all-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4924) MAC OS build failed
[
https://issues.apache.org/jira/browse/MESOS-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Niemitz reassigned MESOS-4924:
Assignee: Steve Niemitz
> MAC OS build failed
> ---
>
> Key: MESOS-4924
> URL: https://issues.apache.org/jira/browse/MESOS-4924
> Project: Mesos
> Issue Type: Bug
>Reporter: Guangya Liu
>Assignee: Steve Niemitz
>Priority: Blocker
>
> Seems caused by https://reviews.apache.org/r/41049/ [~SteveNiemitz]
> {code}
> -std=c++11 -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11
> -Qunused-arguments -I/usr/local/opt/subversion/include/subversion-1
> -I/usr/include/apr-1 -I/usr/include/apr-1.0 -Qunused-arguments
> build/temp.macosx-10.10-intel-2.7/src/mesos/executor/mesos_executor_driver_impl.o
> build/temp.macosx-10.10-intel-2.7/src/mesos/executor/module.o
> build/temp.macosx-10.10-intel-2.7/src/mesos/executor/proxy_executor.o
> /Users/gyliu/git/mesos/build/src/.libs/libmesos_no_3rdparty.a
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/.libs/libprocess.a
> /Users/gyliu/git/mesos/build/3rdparty/leveldb-1.4/libleveldb.a
> /Users/gyliu/git/mesos/build/3rdparty/zookeeper-3.4.5/src/c/.libs/libzookeeper_mt.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/glog-0.3.3/.libs/libglog.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/protobuf-2.5.0/src/.libs/libprotobuf.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/libev-4.15/.libs/libev.a
> -o build/lib.macosx-10.10-intel-2.7/mesos/executor/_executor.so
> -Wl,--as-needed -L/usr/local/opt/subversion/lib -lsasl2 -lsvn_delta-1
> -lsvn_subr-1 -lapr-1 -lcurl -lz
> ld: unknown option: --as-needed
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> error: command 'g++' failed with exit status 1
> make[2]: *** [python/dist/mesos.executor-0.29.0-py2.7-macosx-10.10-intel.egg]
> Error 1
> make[2]: *** Waiting for unfinished jobs
> g++ -bundle -undefined dynamic_lookup -arch x86_64 -arch i386 -Wl,-F.
> -L/usr/local/opt/subversion/lib -g -O0 -g -O0 -Wno-unused-local-typedef
> -std=c++11 -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11
> -Qunused-arguments -I/usr/local/opt/subversion/include/subversion-1
> -I/usr/include/apr-1 -I/usr/include/apr-1.0 -Qunused-arguments
> build/temp.macosx-10.10-intel-2.7/src/mesos/scheduler/mesos_scheduler_driver_impl.o
> build/temp.macosx-10.10-intel-2.7/src/mesos/scheduler/module.o
> build/temp.macosx-10.10-intel-2.7/src/mesos/scheduler/proxy_scheduler.o
> /Users/gyliu/git/mesos/build/src/.libs/libmesos_no_3rdparty.a
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/.libs/libprocess.a
> /Users/gyliu/git/mesos/build/3rdparty/leveldb-1.4/libleveldb.a
> /Users/gyliu/git/mesos/build/3rdparty/zookeeper-3.4.5/src/c/.libs/libzookeeper_mt.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/glog-0.3.3/.libs/libglog.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/protobuf-2.5.0/src/.libs/libprotobuf.a
>
> /Users/gyliu/git/mesos/build/3rdparty/libprocess/3rdparty/libev-4.15/.libs/libev.a
> -o build/lib.macosx-10.10-intel-2.7/mesos/scheduler/_scheduler.so
> -Wl,--as-needed -L/usr/local/opt/subversion/lib -lsasl2 -lsvn_delta-1
> -lsvn_subr-1 -lapr-1 -lcurl -lz
> ld: unknown option: --as-needed
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> error: command 'g++' failed with exit status 1
> make[2]: ***
> [python/dist/mesos.scheduler-0.29.0-py2.7-macosx-10.10-intel.egg] Error 1
> make[1]: *** [all] Error 2
> make: *** [all-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4053) MemoryPressureMesosTest tests fail on CentOS 6.6
[
https://issues.apache.org/jira/browse/MESOS-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Mathiske updated MESOS-4053:
--
Sprint: Mesosphere Sprint 26, Mesosphere Sprint 27, Mesosphere Sprint 31
(was: Mesosphere Sprint 26, Mesosphere Sprint 27)
> MemoryPressureMesosTest tests fail on CentOS 6.6
>
>
> Key: MESOS-4053
> URL: https://issues.apache.org/jira/browse/MESOS-4053
> Project: Mesos
> Issue Type: Bug
> Environment: CentOS 6.6
>Reporter: Greg Mann
>Assignee: Benjamin Hindman
> Labels: mesosphere, test-failure
>
> {{MemoryPressureMesosTest.CGROUPS_ROOT_Statistics}} and
> {{MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery}} fail on CentOS 6.6. It
> seems that mounted cgroups are not properly cleaned up after previous tests,
> so multiple hierarchies are detected and thus an error is produced:
> {code}
> [ RUN ] MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
> ../../src/tests/mesos.cpp:849: Failure
> Value of: _baseHierarchy.get()
> Actual: "/cgroup"
> Expected: baseHierarchy
> Which is: "/tmp/mesos_test_cgroup"
> -
> Multiple cgroups base hierarchies detected:
> '/tmp/mesos_test_cgroup'
> '/cgroup'
> Mesos does not support multiple cgroups base hierarchies.
> Please unmount the corresponding (or all) subsystems.
> -
> ../../src/tests/mesos.cpp:932: Failure
> (cgroups::destroy(hierarchy, cgroup)).failure(): Failed to remove cgroup
> '/tmp/mesos_test_cgroup/perf_event/mesos_test': Device or resource busy
> [ FAILED ] MemoryPressureMesosTest.CGROUPS_ROOT_Statistics (12 ms)
> [ RUN ] MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
> ../../src/tests/mesos.cpp:849: Failure
> Value of: _baseHierarchy.get()
> Actual: "/cgroup"
> Expected: baseHierarchy
> Which is: "/tmp/mesos_test_cgroup"
> -
> Multiple cgroups base hierarchies detected:
> '/tmp/mesos_test_cgroup'
> '/cgroup'
> Mesos does not support multiple cgroups base hierarchies.
> Please unmount the corresponding (or all) subsystems.
> -
> ../../src/tests/mesos.cpp:932: Failure
> (cgroups::destroy(hierarchy, cgroup)).failure(): Failed to remove cgroup
> '/tmp/mesos_test_cgroup/perf_event/mesos_test': Device or resource busy
> [ FAILED ] MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery (7 ms)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4610) MasterContender/MasterDetector should be loadable as modules
[ https://issues.apache.org/jira/browse/MESOS-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Hindman updated MESOS-4610: Sprint: Mesosphere Sprint 29 (was: Mesosphere Sprint 29, Mesosphere Sprint 30) > MasterContender/MasterDetector should be loadable as modules > > > Key: MESOS-4610 > URL: https://issues.apache.org/jira/browse/MESOS-4610 > Project: Mesos > Issue Type: Improvement > Components: master >Reporter: Mark Cavage >Assignee: Mark Cavage > > Currently mesos depends on Zookeeper for leader election and notification to > slaves, although there is a C++ hierarchy in the code to support alternatives > (e.g., unit tests use an in-memory implementation). From an operational > perspective, many organizations/users do not want to take a dependency on > Zookeeper, and use an alternative solution to implementing leader election. > Our organization in particular, very much wants this, and as a reference > there have been several requests from the community (see referenced tickets) > to replace with etcd/consul/etc. > This ticket will serve as the work effort to modularize the > MasterContender/MasterDetector APIs such that integrators can build a > pluggable solution of their choice; this ticket will not fold in any > implementations such as etcd et al., but simply move this hierarchy to be > fully pluggable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4810) ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand fails.
[
https://issues.apache.org/jira/browse/MESOS-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193573#comment-15193573
]
Jie Yu commented on MESOS-4810:
---
{noformat}
[09:46:48]W: [Step 11/11] Failed to exec: No such file or directory
{noformat}
The above is the suspicious logging. Looks like the command executor cannot
find the command in its path.
> ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand fails.
> --
>
> Key: MESOS-4810
> URL: https://issues.apache.org/jira/browse/MESOS-4810
> Project: Mesos
> Issue Type: Bug
> Components: docker
>Affects Versions: 0.28.0
> Environment: CentOS 7 on AWS, both with or without SSL.
>Reporter: Bernd Mathiske
>Assignee: Jie Yu
> Labels: docker, mesosphere, test
>
> {noformat}
> [09:46:46] : [Step 11/11] [ RUN ]
> ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand
> [09:46:46]W: [Step 11/11] I0229 09:46:46.628413 1166 leveldb.cpp:174]
> Opened db in 4.242882ms
> [09:46:46]W: [Step 11/11] I0229 09:46:46.629926 1166 leveldb.cpp:181]
> Compacted db in 1.483621ms
> [09:46:46]W: [Step 11/11] I0229 09:46:46.629966 1166 leveldb.cpp:196]
> Created db iterator in 15498ns
> [09:46:46]W: [Step 11/11] I0229 09:46:46.629977 1166 leveldb.cpp:202]
> Seeked to beginning of db in 1405ns
> [09:46:46]W: [Step 11/11] I0229 09:46:46.629984 1166 leveldb.cpp:271]
> Iterated through 0 keys in the db in 239ns
> [09:46:46]W: [Step 11/11] I0229 09:46:46.630015 1166 replica.cpp:779]
> Replica recovered with log positions 0 -> 0 with 1 holes and 0 unlearned
> [09:46:46]W: [Step 11/11] I0229 09:46:46.630470 1183 recover.cpp:447]
> Starting replica recovery
> [09:46:46]W: [Step 11/11] I0229 09:46:46.630702 1180 recover.cpp:473]
> Replica is in EMPTY status
> [09:46:46]W: [Step 11/11] I0229 09:46:46.631767 1182 replica.cpp:673]
> Replica in EMPTY status received a broadcasted recover request from
> (14567)@172.30.2.124:37431
> [09:46:46]W: [Step 11/11] I0229 09:46:46.632115 1183 recover.cpp:193]
> Received a recover response from a replica in EMPTY status
> [09:46:46]W: [Step 11/11] I0229 09:46:46.632450 1186 recover.cpp:564]
> Updating replica status to STARTING
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633476 1186 master.cpp:375]
> Master 3fbb2fb0-4f18-498b-a440-9acbf6923a13 (ip-172-30-2-124.mesosphere.io)
> started on 172.30.2.124:37431
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633491 1186 master.cpp:377] Flags
> at startup: --acls="" --allocation_interval="1secs"
> --allocator="HierarchicalDRF" --authenticate="true"
> --authenticate_http="true" --authenticate_slaves="true"
> --authenticators="crammd5" --authorizers="local"
> --credentials="/tmp/4UxXoW/credentials" --framework_sorter="drf"
> --help="false" --hostname_lookup="true" --http_authenticators="basic"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_completed_frameworks="50"
> --max_completed_tasks_per_framework="1000" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="100secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/usr/local/share/mesos/webui" --work_dir="/tmp/4UxXoW/master"
> --zk_session_timeout="10secs"
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633677 1186 master.cpp:422]
> Master only allowing authenticated frameworks to register
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633685 1186 master.cpp:427]
> Master only allowing authenticated slaves to register
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633692 1186 credentials.hpp:35]
> Loading credentials for authentication from '/tmp/4UxXoW/credentials'
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633851 1183 leveldb.cpp:304]
> Persisting metadata (8 bytes) to leveldb took 1.191043ms
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633873 1183 replica.cpp:320]
> Persisted replica status to STARTING
> [09:46:46]W: [Step 11/11] I0229 09:46:46.633894 1186 master.cpp:467] Using
> default 'crammd5' authenticator
> [09:46:46]W: [Step 11/11] I0229 09:46:46.634003 1186 master.cpp:536] Using
> default 'basic' HTTP authenticator
> [09:46:46]W: [Step 11/11] I0229 09:46:46.634062 1184 recover.cpp:473]
> Replica is in STARTING status
> [09:46:46]W: [Step 11/11] I0229 09:46:46.634109 1186 master.cpp:570]
> Authorization enabled
> [09:46:46]W: [Step 11/11] I0229 09:46:46.634249 1187
> whitelist_watcher.cpp:77] No whitelist given
> [09:46:46]W: [Step 11/11] I0229 09:
[jira] [Commented] (MESOS-3902) The Location header when non-leading master redirects to leading master is incomplete.
[
https://issues.apache.org/jira/browse/MESOS-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193585#comment-15193585
]
Ashwin Murthy commented on MESOS-3902:
--
Not actively, since busy with higher priority work. If this is blocking, please
reassign. If not, would be interested in looking at this soon.
> The Location header when non-leading master redirects to leading master is
> incomplete.
> --
>
> Key: MESOS-3902
> URL: https://issues.apache.org/jira/browse/MESOS-3902
> Project: Mesos
> Issue Type: Bug
> Components: HTTP API, master
>Affects Versions: 0.25.0
> Environment: 3 masters, 10 slaves
>Reporter: Ben Whitehead
>Assignee: Ashwin Murthy
> Labels: mesosphere
>
> The master now sets a location header, but it's incomplete. The path of the
> URL isn't set. Consider an example:
> {code}
> > cat /tmp/subscribe-1072944352375841456 | httpp POST
> > 127.1.0.3:5050/api/v1/scheduler Content-Type:application/x-protobuf
> POST /api/v1/scheduler HTTP/1.1
> Accept: application/json
> Accept-Encoding: gzip, deflate
> Connection: keep-alive
> Content-Length: 123
> Content-Type: application/x-protobuf
> Host: 127.1.0.3:5050
> User-Agent: HTTPie/0.9.0
> +-+
> | NOTE: binary data not shown in terminal |
> +-+
> HTTP/1.1 307 Temporary Redirect
> Content-Length: 0
> Date: Fri, 26 Feb 2016 00:54:41 GMT
> Location: //127.1.0.1:5050
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4781) Executor env variables should not be leaked to the command task.
[ https://issues.apache.org/jira/browse/MESOS-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4781: -- Summary: Executor env variables should not be leaked to the command task. (was: Forbid command executor to inherit environment variables from slave.) > Executor env variables should not be leaked to the command task. > > > Key: MESOS-4781 > URL: https://issues.apache.org/jira/browse/MESOS-4781 > Project: Mesos > Issue Type: Bug > Components: containerization >Reporter: Gilbert Song >Assignee: Gilbert Song > Labels: mesosphere > > Currently mesos command executor just inherits all environment variables from > the slave. This could be problematic because when unified containerizer > launches the docker images like mongo or jenkins. Some of the environment > variables are duplicated (such as `PATH` etc.), which causes those docker > images not executing properly. We should prevents those slave environments > exposed to command line executor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4781) Executor env variables should not be leaked to the command task.
[ https://issues.apache.org/jira/browse/MESOS-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4781: -- Description: Currently, command task inherits the env variables of the command executor. This is less ideal because the command executor environment variables include some Mesos internal env variables like MESOS_XXX and LIBPROCESS_XXX. Also, this behavior does not match what Docker containerizer does. We should construct the env variables from scratch for the command task, rather than relying on inheriting the env variables from the command executor. (was: Currently mesos command executor just inherits all environment variables from the slave. This could be problematic because when unified containerizer launches the docker images like mongo or jenkins. Some of the environment variables are duplicated (such as `PATH` etc.), which causes those docker images not executing properly. We should prevents those slave environments exposed to command line executor.) > Executor env variables should not be leaked to the command task. > > > Key: MESOS-4781 > URL: https://issues.apache.org/jira/browse/MESOS-4781 > Project: Mesos > Issue Type: Bug > Components: containerization >Reporter: Gilbert Song >Assignee: Gilbert Song > Labels: mesosphere > > Currently, command task inherits the env variables of the command executor. > This is less ideal because the command executor environment variables include > some Mesos internal env variables like MESOS_XXX and LIBPROCESS_XXX. Also, > this behavior does not match what Docker containerizer does. We should > construct the env variables from scratch for the command task, rather than > relying on inheriting the env variables from the command executor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4814) Implement private registry test with ssl.
[ https://issues.apache.org/jira/browse/MESOS-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193629#comment-15193629 ] Jie Yu commented on MESOS-4814: --- SSL is still needed, but 'curl' will handle it automatically. So Mesos does not have to be built with ssl enabled. > Implement private registry test with ssl. > - > > Key: MESOS-4814 > URL: https://issues.apache.org/jira/browse/MESOS-4814 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Gilbert Song >Assignee: Gilbert Song > Labels: containerizer > > Test unified containerizer using docker images, have ssl enabled to test the > private registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4814) Test private registry with ssl enabled/disabled.
[ https://issues.apache.org/jira/browse/MESOS-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4814: -- Summary: Test private registry with ssl enabled/disabled. (was: Implement private registry test with ssl.) > Test private registry with ssl enabled/disabled. > > > Key: MESOS-4814 > URL: https://issues.apache.org/jira/browse/MESOS-4814 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Gilbert Song >Assignee: Gilbert Song > Labels: containerizer > > Test unified containerizer using docker images, have ssl enabled to test the > private registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4936) Improve container security for Mesos containerizer.
Jie Yu created MESOS-4936: - Summary: Improve container security for Mesos containerizer. Key: MESOS-4936 URL: https://issues.apache.org/jira/browse/MESOS-4936 Project: Mesos Issue Type: Epic Reporter: Jie Yu We should investigate the following to improve the container security for Mesos containerizer: 1) Capabilities 2) User namespace 3) Seccomp 4) SELinux 5) AppArmor We should investigate what other container systems are doing regarding security: 1) [k8s| https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L2905] 2) [docker|https://docs.docker.com/engine/security/security/] 3) [oci|https://github.com/opencontainers/specs/blob/master/config.md] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4937) Investigate container security options for Mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4937: -- Component/s: containerization > Investigate container security options for Mesos containerizer > -- > > Key: MESOS-4937 > URL: https://issues.apache.org/jira/browse/MESOS-4937 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Jie Yu > Labels: mesosphere > > We should investigate the following to improve the container security for > Mesos containerizer and come up with a list of features that we want to > support in MVP. > 1) Capabilities > 2) User namespace > 3) Seccomp > 4) SELinux > 5) AppArmor > We should investigate what other container systems are doing regarding > security: > 1) [k8s| > https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L2905] > 2) [docker|https://docs.docker.com/engine/security/security/] > 3) [oci|https://github.com/opencontainers/specs/blob/master/config.md] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4937) Investigate container security options for Mesos containerizer
Jie Yu created MESOS-4937: - Summary: Investigate container security options for Mesos containerizer Key: MESOS-4937 URL: https://issues.apache.org/jira/browse/MESOS-4937 Project: Mesos Issue Type: Task Reporter: Jie Yu We should investigate the following to improve the container security for Mesos containerizer and come up with a list of features that we want to support in MVP. 1) Capabilities 2) User namespace 3) Seccomp 4) SELinux 5) AppArmor We should investigate what other container systems are doing regarding security: 1) [k8s| https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L2905] 2) [docker|https://docs.docker.com/engine/security/security/] 3) [oci|https://github.com/opencontainers/specs/blob/master/config.md] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4937) Investigate container security options for Mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4937: -- Labels: mesosphere (was: ) > Investigate container security options for Mesos containerizer > -- > > Key: MESOS-4937 > URL: https://issues.apache.org/jira/browse/MESOS-4937 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Jie Yu > Labels: mesosphere > > We should investigate the following to improve the container security for > Mesos containerizer and come up with a list of features that we want to > support in MVP. > 1) Capabilities > 2) User namespace > 3) Seccomp > 4) SELinux > 5) AppArmor > We should investigate what other container systems are doing regarding > security: > 1) [k8s| > https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L2905] > 2) [docker|https://docs.docker.com/engine/security/security/] > 3) [oci|https://github.com/opencontainers/specs/blob/master/config.md] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4936) Improve container security for Mesos containerizer.
[ https://issues.apache.org/jira/browse/MESOS-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4936: -- Labels: mesosphere (was: ) > Improve container security for Mesos containerizer. > --- > > Key: MESOS-4936 > URL: https://issues.apache.org/jira/browse/MESOS-4936 > Project: Mesos > Issue Type: Epic > Components: containerization >Reporter: Jie Yu > Labels: mesosphere > > We should investigate the following to improve the container security for > Mesos containerizer: > 1) Capabilities > 2) User namespace > 3) Seccomp > 4) SELinux > 5) AppArmor > We should investigate what other container systems are doing regarding > security: > 1) [k8s| > https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L2905] > 2) [docker|https://docs.docker.com/engine/security/security/] > 3) [oci|https://github.com/opencontainers/specs/blob/master/config.md] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4936) Improve container security for Mesos containerizer.
[ https://issues.apache.org/jira/browse/MESOS-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4936: -- Component/s: containerization > Improve container security for Mesos containerizer. > --- > > Key: MESOS-4936 > URL: https://issues.apache.org/jira/browse/MESOS-4936 > Project: Mesos > Issue Type: Epic > Components: containerization >Reporter: Jie Yu > Labels: mesosphere > > We should investigate the following to improve the container security for > Mesos containerizer: > 1) Capabilities > 2) User namespace > 3) Seccomp > 4) SELinux > 5) AppArmor > We should investigate what other container systems are doing regarding > security: > 1) [k8s| > https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L2905] > 2) [docker|https://docs.docker.com/engine/security/security/] > 3) [oci|https://github.com/opencontainers/specs/blob/master/config.md] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4937) Investigate container security options for Mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4937: -- Shepherd: Jie Yu > Investigate container security options for Mesos containerizer > -- > > Key: MESOS-4937 > URL: https://issues.apache.org/jira/browse/MESOS-4937 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Jie Yu >Assignee: Jojy Varghese > Labels: mesosphere > > We should investigate the following to improve the container security for > Mesos containerizer and come up with a list of features that we want to > support in MVP. > 1) Capabilities > 2) User namespace > 3) Seccomp > 4) SELinux > 5) AppArmor > We should investigate what other container systems are doing regarding > security: > 1) [k8s| > https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L2905] > 2) [docker|https://docs.docker.com/engine/security/security/] > 3) [oci|https://github.com/opencontainers/specs/blob/master/config.md] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4937) Investigate container security options for Mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4937: -- Sprint: Mesosphere Sprint 31 > Investigate container security options for Mesos containerizer > -- > > Key: MESOS-4937 > URL: https://issues.apache.org/jira/browse/MESOS-4937 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Jie Yu > Labels: mesosphere > > We should investigate the following to improve the container security for > Mesos containerizer and come up with a list of features that we want to > support in MVP. > 1) Capabilities > 2) User namespace > 3) Seccomp > 4) SELinux > 5) AppArmor > We should investigate what other container systems are doing regarding > security: > 1) [k8s| > https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L2905] > 2) [docker|https://docs.docker.com/engine/security/security/] > 3) [oci|https://github.com/opencontainers/specs/blob/master/config.md] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4937) Investigate container security options for Mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4937: -- Assignee: Jojy Varghese > Investigate container security options for Mesos containerizer > -- > > Key: MESOS-4937 > URL: https://issues.apache.org/jira/browse/MESOS-4937 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Jie Yu >Assignee: Jojy Varghese > Labels: mesosphere > > We should investigate the following to improve the container security for > Mesos containerizer and come up with a list of features that we want to > support in MVP. > 1) Capabilities > 2) User namespace > 3) Seccomp > 4) SELinux > 5) AppArmor > We should investigate what other container systems are doing regarding > security: > 1) [k8s| > https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L2905] > 2) [docker|https://docs.docker.com/engine/security/security/] > 3) [oci|https://github.com/opencontainers/specs/blob/master/config.md] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4937) Investigate container security options for Mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4937: -- Story Points: 5 > Investigate container security options for Mesos containerizer > -- > > Key: MESOS-4937 > URL: https://issues.apache.org/jira/browse/MESOS-4937 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Jie Yu >Assignee: Jojy Varghese > Labels: mesosphere > > We should investigate the following to improve the container security for > Mesos containerizer and come up with a list of features that we want to > support in MVP. > 1) Capabilities > 2) User namespace > 3) Seccomp > 4) SELinux > 5) AppArmor > We should investigate what other container systems are doing regarding > security: > 1) [k8s| > https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L2905] > 2) [docker|https://docs.docker.com/engine/security/security/] > 3) [oci|https://github.com/opencontainers/specs/blob/master/config.md] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4815) Implement private registry test with authentication.
[ https://issues.apache.org/jira/browse/MESOS-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4815: -- Sprint: (was: Mesosphere Sprint 30) > Implement private registry test with authentication. > > > Key: MESOS-4815 > URL: https://issues.apache.org/jira/browse/MESOS-4815 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Gilbert Song >Assignee: Gilbert Song > Labels: containerizer > > Unified containerizer using docker images, with authentication to test > private registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4814) Test private registry with ssl enabled/disabled.
[ https://issues.apache.org/jira/browse/MESOS-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4814: -- Sprint: (was: Mesosphere Sprint 30) > Test private registry with ssl enabled/disabled. > > > Key: MESOS-4814 > URL: https://issues.apache.org/jira/browse/MESOS-4814 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Gilbert Song >Assignee: Gilbert Song > Labels: containerizer > > Test unified containerizer using docker images, have ssl enabled to test the > private registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4877) Mesos containerizer can't handle top level docker image like "alpine" (must use "library/alpine")
[
https://issues.apache.org/jira/browse/MESOS-4877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jie Yu updated MESOS-4877:
--
Sprint: Mesosphere Sprint 31
> Mesos containerizer can't handle top level docker image like "alpine" (must
> use "library/alpine")
> -
>
> Key: MESOS-4877
> URL: https://issues.apache.org/jira/browse/MESOS-4877
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker
>Affects Versions: 0.27.0, 0.27.1
>Reporter: Shuai Lin
>Assignee: Shuai Lin
>
> This can be demonstrated with the {{mesos-execute}} command:
> # Docker containerizer with image {{alpine}}: success
> {code}
> sudo ./build/src/mesos-execute --docker_image=alpine --containerizer=docker
> --name=just-a-test --command="sleep 1000" --master=localhost:5050
> {code}
> # Mesos containerizer with image {{alpine}}: failure
> {code}
> sudo ./build/src/mesos-execute --docker_image=alpine --containerizer=mesos
> --name=just-a-test --command="sleep 1000" --master=localhost:5050
> {code}
> # Mesos containerizer with image {{library/alpine}}: success
> {code}
> sudo ./build/src/mesos-execute --docker_image=library/alpine
> --containerizer=mesos --name=just-a-test --command="sleep 1000"
> --master=localhost:5050
> {code}
> In the slave logs:
> {code}
> ea-4460-83
> 9c-838da86af34c-0007'
> I0306 16:32:41.418269 3403 metadata_manager.cpp:159] Looking for image
> 'alpine:latest'
> I0306 16:32:41.418699 3403 registry_puller.cpp:194] Pulling image
> 'alpine:latest' from
> 'docker-manifest://registry-1.docker.io:443alpine?latest#https' to
> '/tmp/mesos-test
> /store/docker/staging/ka7MlQ'
> E0306 16:32:43.098131 3400 slave.cpp:3773] Container
> '4bf9132d-9a57-4baa-a78c-e7164e93ace6' for executor 'just-a-test' of
> framework 4f055c6f-1bea-4460-839c-838da86af34c-0
> 007 failed to start: Collect failed: Unexpected HTTP response '401
> Unauthorized
> {code}
> curl command executed:
> {code}
> $ sudo sysdig -A -p "*%evt.time %proc.cmdline" evt.type=execve and
> proc.name=curl
>16:42:53.198998042 curl -s -S -L -D -
> https://registry-1.docker.io:443/v2/alpine/manifests/latest
> 16:42:53.784958541 curl -s -S -L -D -
> https://auth.docker.io/token?service=registry.docker.io&scope=repository:alpine:pull
> 16:42:54.294192024 curl -s -S -L -D - -H Authorization: Bearer
> eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlDTHpDQ0FkU2dBd0lCQWdJQkFEQUtCZ2dxaGtqT1BRUURBakJHTVVRd1FnWURWUVFERXp0Uk5Gb3pPa2RYTjBrNldGUlFSRHBJVFRSUk9rOVVWRmc2TmtGRlF6cFNUVE5ET2tGU01rTTZUMFkzTnpwQ1ZrVkJPa2xHUlVrNlExazFTekFlRncweE5UQTJNalV4T1RVMU5EWmFGdzB4TmpBMk1qUXhPVFUxTkRaYU1FWXhSREJDQmdOVkJBTVRPMGhHU1UwNldGZFZWam8yUVZkSU9sWlpUVEk2TTFnMVREcFNWREkxT2s5VFNrbzZTMVExUmpwWVRsSklPbFJMTmtnNlMxUkxOanBCUVV0VU1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRXl2UzIvdEI3T3JlMkVxcGRDeFdtS1NqV1N2VmJ2TWUrWGVFTUNVMDByQjI0akNiUVhreFdmOSs0MUxQMlZNQ29BK0RMRkIwVjBGZGdwajlOWU5rL2pxT0JzakNCcnpBT0JnTlZIUThCQWY4RUJBTUNBSUF3RHdZRFZSMGxCQWd3QmdZRVZSMGxBREJFQmdOVkhRNEVQUVE3U0VaSlRUcFlWMVZXT2paQlYwZzZWbGxOTWpveldEVk1PbEpVTWpVNlQxTktTanBMVkRWR09saE9Va2c2VkVzMlNEcExWRXMyT2tGQlMxUXdSZ1lEVlIwakJEOHdQWUE3VVRSYU16cEhWemRKT2xoVVVFUTZTRTAwVVRwUFZGUllPalpCUlVNNlVrMHpRenBCVWpKRE9rOUdOemM2UWxaRlFUcEpSa1ZKT2tOWk5Vc3dDZ1lJS29aSXpqMEVBd0lEU1FBd1JnSWhBTXZiT2h4cHhrTktqSDRhMFBNS0lFdXRmTjZtRDFvMWs4ZEJOVGxuWVFudkFpRUF0YVJGSGJSR2o4ZlVSSzZ4UVJHRURvQm1ZZ3dZelR3Z3BMaGJBZzNOUmFvPSJdfQ.eyJhY2Nlc3MiOltdLCJhdWQiOiJyZWdpc3RyeS5kb2NrZXIuaW8iLCJleHAiOjE0NTcyODI4NzQsImlhdCI6MTQ1NzI4MjU3NCwiaXNzIjoiYXV0aC5kb2NrZXIuaW8iLCJqdGkiOiJaOGtyNXZXNEJMWkNIRS1IcVJIaCIsIm5iZiI6MTQ1NzI4MjU3NCwic3ViIjoiIn0.C2wtJq_P-m0buPARhmQjDfh6ztIAhcvgN3tfWIZEClSgXlVQ_sAQXAALNZKwAQL2Chj7NpHX--0GW-aeL_28Aw
> https://registry-1.docker.io:443/v2/alpine/manifests/latest
> {code}
> Also got the same result with {{ubuntu}} docker image.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-4938) Support docker registry authentication
Jie Yu created MESOS-4938: - Summary: Support docker registry authentication Key: MESOS-4938 URL: https://issues.apache.org/jira/browse/MESOS-4938 Project: Mesos Issue Type: Task Reporter: Jie Yu -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4938) Support docker registry authentication
[ https://issues.apache.org/jira/browse/MESOS-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4938: -- Assignee: Gilbert Song Sprint: Mesosphere Sprint 31 We first need to implement the authentication (HTTP Basic) for getting the auth token. Then, we need to figure out how to pass the credentials. > Support docker registry authentication > -- > > Key: MESOS-4938 > URL: https://issues.apache.org/jira/browse/MESOS-4938 > Project: Mesos > Issue Type: Task >Reporter: Jie Yu >Assignee: Gilbert Song > Labels: mesosphere > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4938) Support docker registry authentication
[ https://issues.apache.org/jira/browse/MESOS-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4938: -- Story Points: 5 > Support docker registry authentication > -- > > Key: MESOS-4938 > URL: https://issues.apache.org/jira/browse/MESOS-4938 > Project: Mesos > Issue Type: Task >Reporter: Jie Yu >Assignee: Gilbert Song > Labels: mesosphere > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
