[jira] [Assigned] (MESOS-6581) Add Seccomp support at Mesos Agent level
[ https://issues.apache.org/jira/browse/MESOS-6581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Guo reassigned MESOS-6581: -- Assignee: (was: Jay Guo) > Add Seccomp support at Mesos Agent level > > > Key: MESOS-6581 > URL: https://issues.apache.org/jira/browse/MESOS-6581 > Project: Mesos > Issue Type: Task > Environment: Linux Only >Reporter: Jay Guo >Priority: Major > > Operator of Mesos cluster should be able to enforce a set of Seccomp rules on > an Mesos Agent to defend against potential exploit attack through syscalls. > When enabled, every container launched on the Agent would comply with the > Seccomp filter otherwise being killed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-9004) Add unit tests for dropping operations during SLRP reconciliation.
Chun-Hung Hsiao created MESOS-9004:
--
Summary: Add unit tests for dropping operations during SLRP
reconciliation.
Key: MESOS-9004
URL: https://issues.apache.org/jira/browse/MESOS-9004
Project: Mesos
Issue Type: Task
Components: storage
Reporter: Chun-Hung Hsiao
Assignee: Chun-Hung Hsiao
We should add unit tests to verify that the SLRP will reject certain operations
and not others during reconciliation.
Note that this is currently not doable since there is no way to "pause" the
progress of a reconciliation. Once MESOS-9003 is done this becomes viable by
delaying the response of the {{GetCapacity}} CSI call though a mock plugin.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-9003) Allow storage resource providers to consume given CSI endpoints.
Chun-Hung Hsiao created MESOS-9003: -- Summary: Allow storage resource providers to consume given CSI endpoints. Key: MESOS-9003 URL: https://issues.apache.org/jira/browse/MESOS-9003 Project: Mesos Issue Type: Task Components: storage Reporter: Chun-Hung Hsiao Assignee: Chun-Hung Hsiao As designed in MESOS-8528, we need to be able to configure the SERP controller to consume a CSI endpoint, rather than launching a CSI plugin by itself. This is also beneficial to SLRP since the operator can set up a SLRP to consume a pre-launched CSI plugin that is managed out-of-band. Also this could improve SLRP testing since we can use a mock CSI plugin to control the progress of CSI calls. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-7479) Add explicit check on URI fetcher docker plugin to reject v1 registry.
[ https://issues.apache.org/jira/browse/MESOS-7479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16514233#comment-16514233 ] xiaowei commented on MESOS-7479: does this still need to be checked? > Add explicit check on URI fetcher docker plugin to reject v1 registry. > -- > > Key: MESOS-7479 > URL: https://issues.apache.org/jira/browse/MESOS-7479 > Project: Mesos > Issue Type: Improvement >Reporter: Gilbert Song >Priority: Major > > Currently, unified containerizer only supports v2 docker registry. The URI > fetcher docker plugin should explicitly check that the registry is v2, and > return failure for v1 with sufficient error message. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MESOS-9002) Mem access error in os::Fork::Tree
[
https://issues.apache.org/jira/browse/MESOS-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned MESOS-9002:
--
Assignee: James Peach
Priority: Minor (was: Major)
Fix Version/s: 1.7.0
| [r/67614|https://reviews.apache.org/r/67614] | Removed memcpy from
os::Fork::instantiate. |
> Mem access error in os::Fork::Tree
> --
>
> Key: MESOS-9002
> URL: https://issues.apache.org/jira/browse/MESOS-9002
> Project: Mesos
> Issue Type: Task
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 1.7.0
>
>
> Building Mesos with gcc 8.1 (Fedora 28)
> {noformat}
> ../../3rdparty/stout/include/stout/os/posix/fork.hpp: In member function
> ‘pid_t os::Fork::instantiate(const os::Fork::Tree&) const’:
> ../../3rdparty/stout/include/stout/os/posix/fork.hpp:354:61: error: ‘void*
> memcpy(void*, const void*, size_t)’ writing to an object of type ‘using
> element_type = std::remove_extent::type’ {aka ‘struct
> os::Fork::Tree::Memory’} with no trivial copy-assignment
> [-Werror=class-memaccess]
> memcpy(tree.memory.get(), , sizeof(Tree::Memory));
> ^
> ../../3rdparty/stout/include/stout/os/posix/fork.hpp:235:12: note: ‘using
> element_type = std::remove_extent::type’ {aka ‘struct
> os::Fork::Tree::Memory’} declared here
> struct Memory {
> ^~
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-9002) Mem access error in os::Fork::Tree
James Peach created MESOS-9002:
--
Summary: Mem access error in os::Fork::Tree
Key: MESOS-9002
URL: https://issues.apache.org/jira/browse/MESOS-9002
Project: Mesos
Issue Type: Task
Reporter: James Peach
Building Mesos with gcc 8.1 (Fedora 28)
{noformat}
../../3rdparty/stout/include/stout/os/posix/fork.hpp: In member function ‘pid_t
os::Fork::instantiate(const os::Fork::Tree&) const’:
../../3rdparty/stout/include/stout/os/posix/fork.hpp:354:61: error: ‘void*
memcpy(void*, const void*, size_t)’ writing to an object of type ‘using
element_type = std::remove_extent::type’ {aka ‘struct
os::Fork::Tree::Memory’} with no trivial copy-assignment
[-Werror=class-memaccess]
memcpy(tree.memory.get(), , sizeof(Tree::Memory));
^
../../3rdparty/stout/include/stout/os/posix/fork.hpp:235:12: note: ‘using
element_type = std::remove_extent::type’ {aka ‘struct
os::Fork::Tree::Memory’} declared here
struct Memory {
^~
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-8955) Manage Python2 and 3 in build steps
[
https://issues.apache.org/jira/browse/MESOS-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513820#comment-16513820
]
Kevin Klues commented on MESOS-8955:
{noformat}
commit 57091affe3380a01d516b03be2700db85c328ede
Author: Armand Grillet agril...@mesosphere.io
Date: Fri Jun 15 15:26:15 2018 +0200
Improved coverage with configure and `PYTHON` or `PYTHON_VERSION` set.
We set `PYTHON` and `PYTHON_VERSION` when configuring the build.
We now cover all possible cases (both variables set, only one, none).
This ensures that both variables are set after being checked.
Review: https://reviews.apache.org/r/67412/
{noformat}
> Manage Python2 and 3 in build steps
> ---
>
> Key: MESOS-8955
> URL: https://issues.apache.org/jira/browse/MESOS-8955
> Project: Mesos
> Issue Type: Improvement
>Reporter: Armand Grillet
>Assignee: Armand Grillet
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-9000) Operator API event stream can miss task status updates
[
https://issues.apache.org/jira/browse/MESOS-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513816#comment-16513816
]
Zhitao Li commented on MESOS-9000:
--
I believe the high level intention was to avoid sending unnecessary duplicate
status update messages, but I don't think we explicitly considered the multiple
event queued scenario you described.
I think if we have a counter to monitor rate of message on event stream, it
sounds fine to add this.
> Operator API event stream can miss task status updates
> --
>
> Key: MESOS-9000
> URL: https://issues.apache.org/jira/browse/MESOS-9000
> Project: Mesos
> Issue Type: Bug
>Reporter: Benno Evers
>Priority: Major
>
> As of now, the master only sends TaskUpdated messages to subscribers when the
> latest known task state on the agent changed:
> {noformat}
> // src/master/master.cpp
> if (!protobuf::isTerminalState(task->state())) {
> if (status.state() != task->state()) {
> sendSubscribersUpdate = true;
> }
> task->set_state(latestState.getOrElse(status.state()));
> }
> {noformat}
> The latest state is set like this:
> {noformat}
> // src/messages/messages.proto
> message StatusUpdate {
> [...]
> // This corresponds to the latest state of the task according to the
> // agent. Note that this state might be different than the state in
> // 'status' because task status update manager queues updates. In
> // other words, 'status' corresponds to the update at top of the
> // queue and 'latest_state' corresponds to the update at bottom of
> // the queue.
> optional TaskState latest_state = 7;
> }
> {noformat}
> However, the `TaskStatus` message included in an `TaskUpdated` event is the
> event at the bottom of the queue when the update was sent.
> So we can easily get in a situation where e.g. the first TaskUpdated has
> .status.state == TASK_STARTING and .state == TASK_RUNNING, and the second
> update with .status.state == TASK_RUNNNING and .state == TASK_RUNNING would
> not get delivered because the latest known state did not change.
> This implies that schedulers can not reliably wait for the status information
> corresponding to specific task state, since there is no guarantee that
> subscribers get notified during the time when this status update will be
> included in the status field.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-8955) Manage Python2 and 3 in build steps
[
https://issues.apache.org/jira/browse/MESOS-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513805#comment-16513805
]
Kevin Klues commented on MESOS-8955:
{noformat}
commit 3bf6eb7c88b7ea365c27fae2623322876ed2af45
Author: Armand Grillet
Date: Fri Jun 15 15:17:09 2018 +0200
Broadened check for Autotools Python environment variables.
The checks now also apply if we run configure with disabled Python
bindings but enabled new CLI. Another check regarding the Python
version has been kept separated as we will use different Python
versions for both components in a later commit.
Review: https://reviews.apache.org/r/67411/
{noformat}
> Manage Python2 and 3 in build steps
> ---
>
> Key: MESOS-8955
> URL: https://issues.apache.org/jira/browse/MESOS-8955
> Project: Mesos
> Issue Type: Improvement
>Reporter: Armand Grillet
>Assignee: Armand Grillet
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-9001) Support generic filtering by prefix in `FlagsBase`.
Alexander Rukletsov created MESOS-9001:
--
Summary: Support generic filtering by prefix in `FlagsBase`.
Key: MESOS-9001
URL: https://issues.apache.org/jira/browse/MESOS-9001
Project: Mesos
Issue Type: Task
Components: stout
Reporter: Alexander Rukletsov
Currently, some overrides of {{FlagsBase::load()}} can take a prefix which is
used to filter env vars read from the environment. Sometimes it is undesirable
to read the environment in {{FlagsBase}} and hence the env vars are passed by
the user, see e.g. MESOS-3475. In such cases it would be convenient if
{{FlagsBase}} supports filtering for provided environments as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-9000) Operator API event stream can miss task status updates
[
https://issues.apache.org/jira/browse/MESOS-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513740#comment-16513740
]
Benno Evers commented on MESOS-9000:
[~zhitao], since you added the .status field to the `TaskUpdated` message, can
you remember if this was the intended behaviour, or is this an oversight?
> Operator API event stream can miss task status updates
> --
>
> Key: MESOS-9000
> URL: https://issues.apache.org/jira/browse/MESOS-9000
> Project: Mesos
> Issue Type: Bug
>Reporter: Benno Evers
>Priority: Major
>
> As of now, the master only sends TaskUpdated messages to subscribers when the
> latest known task state on the agent changed:
> {noformat}
> // src/master/master.cpp
> if (!protobuf::isTerminalState(task->state())) {
> if (status.state() != task->state()) {
> sendSubscribersUpdate = true;
> }
> task->set_state(latestState.getOrElse(status.state()));
> }
> {noformat}
> The latest state is set like this:
> {noformat}
> // src/messages/messages.proto
> message StatusUpdate {
> [...]
> // This corresponds to the latest state of the task according to the
> // agent. Note that this state might be different than the state in
> // 'status' because task status update manager queues updates. In
> // other words, 'status' corresponds to the update at top of the
> // queue and 'latest_state' corresponds to the update at bottom of
> // the queue.
> optional TaskState latest_state = 7;
> }
> {noformat}
> However, the `TaskStatus` message included in an `TaskUpdated` event is the
> event at the bottom of the queue when the update was sent.
> So we can easily get in a situation where e.g. the first TaskUpdated has
> .status.state == TASK_STARTING and .state == TASK_RUNNING, and the second
> update with .status.state == TASK_RUNNNING and .state == TASK_RUNNING would
> not get delivered because the latest known state did not change.
> This implies that schedulers can not reliably wait for the status information
> corresponding to specific task state, since there is no guarantee that
> subscribers get notified during the time when this status update will be
> included in the status field.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-9000) Operator API event stream can miss task status updates
[
https://issues.apache.org/jira/browse/MESOS-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513680#comment-16513680
]
Benno Evers commented on MESOS-9000:
Review: https://reviews.apache.org/r/67575/
> Operator API event stream can miss task status updates
> --
>
> Key: MESOS-9000
> URL: https://issues.apache.org/jira/browse/MESOS-9000
> Project: Mesos
> Issue Type: Bug
>Reporter: Benno Evers
>Priority: Major
>
> As of now, the master only sends TaskUpdated messages
> to subscribers when the latest known task state on the agent changed.
> {noformat}
> // src/messages/messages.proto
> message StatusUpdate {
> [...]
> // This corresponds to the latest state of the task according to the
> // agent. Note that this state might be different than the state in
> // 'status' because task status update manager queues updates. In
> // other words, 'status' corresponds to the update at top of the
> // queue and 'latest_state' corresponds to the update at bottom of
> // the queue.
> optional TaskState latest_state = 7;
> }
> {noformat}
> This implied that schedulers could not reliably wait for the status
> information corresponding to specific state updates (i.e. TASK_RUNNING),
> since there is no guarantee that subscribers get notified during
> the time when this status update will be included in the status field.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-8999) Add default bodies for libprocess HTTP error responses.
Benno Evers created MESOS-8999: -- Summary: Add default bodies for libprocess HTTP error responses. Key: MESOS-8999 URL: https://issues.apache.org/jira/browse/MESOS-8999 Project: Mesos Issue Type: Improvement Reporter: Benno Evers By default on error libprocess would only return a response with the correct status code and no response body. However, most browsers do not visually indicate the response status code, so if any error occurs anyone using a browser will only see a blank page, making it hard to figure out what happened. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-9000) Operator API event stream can miss task status updates
Benno Evers created MESOS-9000:
--
Summary: Operator API event stream can miss task status updates
Key: MESOS-9000
URL: https://issues.apache.org/jira/browse/MESOS-9000
Project: Mesos
Issue Type: Bug
Reporter: Benno Evers
As of now, the master only sends TaskUpdated messages
to subscribers when the latest known task state on the agent changed.
{noformat}
// src/messages/messages.proto
message StatusUpdate {
[...]
// This corresponds to the latest state of the task according to the
// agent. Note that this state might be different than the state in
// 'status' because task status update manager queues updates. In
// other words, 'status' corresponds to the update at top of the
// queue and 'latest_state' corresponds to the update at bottom of
// the queue.
optional TaskState latest_state = 7;
}
{noformat}
This implied that schedulers could not reliably wait for the status
information corresponding to specific state updates (i.e. TASK_RUNNING),
since there is no guarantee that subscribers get notified during
the time when this status update will be included in the status field.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-8999) Add default bodies for libprocess HTTP error responses.
[ https://issues.apache.org/jira/browse/MESOS-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513673#comment-16513673 ] Benno Evers commented on MESOS-8999: Review: https://reviews.apache.org/r/67414/ > Add default bodies for libprocess HTTP error responses. > --- > > Key: MESOS-8999 > URL: https://issues.apache.org/jira/browse/MESOS-8999 > Project: Mesos > Issue Type: Improvement >Reporter: Benno Evers >Priority: Major > > By default on error libprocess would only return a response > with the correct status code and no response body. > However, most browsers do not visually indicate the response > status code, so if any error occurs anyone using a browser will only > see a blank page, making it hard to figure out what happened. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
