[jira] [Commented] (MESOS-8810) Grant non-root task user the permissions to access the SANDBOX_PATH volume of PARENT type
[ https://issues.apache.org/jira/browse/MESOS-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780181#comment-16780181 ] Gilbert Song commented on MESOS-8810: - commit 1003935e1c4021cecf3af637faa1588509a64065 Author: Qian Zhang Date: Wed Feb 27 22:22:47 2019 -0800 Added a test `ROOT_UNPRIVILEGED_USER_TaskSandboxLocalPersistentVolume`. Review: https://reviews.apache.org/r/69579/ > Grant non-root task user the permissions to access the SANDBOX_PATH volume of > PARENT type > - > > Key: MESOS-8810 > URL: https://issues.apache.org/jira/browse/MESOS-8810 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Qian Zhang >Assignee: Qian Zhang >Priority: Major > Fix For: 1.8.0 > > > See [design > doc|https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE-v4KWwjmnCR0l8V4Tq2U/edit#heading=h.s6f8rmu65g2p] > for why we need to do this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MESOS-8813) Make multiple tasks with different users can access a shared persistent volume
[ https://issues.apache.org/jira/browse/MESOS-8813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780175#comment-16780175 ] Gilbert Song edited comment on MESOS-8813 at 2/28/19 6:46 AM: -- commit cb706719975dc1c8ec34a8411d083c6d348779cf Author: Qian Zhang Date: Wed Feb 27 22:22:44 2019 -0800 Added a test `ROOT_UNPRIVILEGED_USER_TaskSandboxSharedPersistentVolume`. Review: https://reviews.apache.org/r/69547/ commit 114569fed4f92f7394e4a8aad7077b7084bb94e9 Author: Qian Zhang Date: Wed Feb 27 22:22:41 2019 -0800 Added a test `UNPRIVILEGED_USER_SharedPersistentVolume`. Review: https://reviews.apache.org/r/68163/ commit d0405160e60f60b3e3416e4a4bb7afb2b7e2907b Author: Qian Zhang Date: Wed Feb 27 22:22:36 2019 -0800 Added a test `ROOT_UNPRIVILEGED_USER_SharedPersistentVolume`. Review: https://reviews.apache.org/r/68162/ was (Author: gilbert): commit d0405160e60f60b3e3416e4a4bb7afb2b7e2907b Author: Qian Zhang Date: Wed Feb 27 22:22:36 2019 -0800 Added a test `ROOT_UNPRIVILEGED_USER_SharedPersistentVolume`. Review: https://reviews.apache.org/r/68162/ > Make multiple tasks with different users can access a shared persistent volume > -- > > Key: MESOS-8813 > URL: https://issues.apache.org/jira/browse/MESOS-8813 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Qian Zhang >Assignee: Qian Zhang >Priority: Major > Fix For: 1.8.0 > > > See [design > doc|https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE-v4KWwjmnCR0l8V4Tq2U/edit#heading=h.f4x59l41lxwx] > for why we need to do this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-8813) Make multiple tasks with different users can access a shared persistent volume
[ https://issues.apache.org/jira/browse/MESOS-8813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780175#comment-16780175 ] Gilbert Song commented on MESOS-8813: - commit d0405160e60f60b3e3416e4a4bb7afb2b7e2907b Author: Qian Zhang Date: Wed Feb 27 22:22:36 2019 -0800 Added a test `ROOT_UNPRIVILEGED_USER_SharedPersistentVolume`. Review: https://reviews.apache.org/r/68162/ > Make multiple tasks with different users can access a shared persistent volume > -- > > Key: MESOS-8813 > URL: https://issues.apache.org/jira/browse/MESOS-8813 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Qian Zhang >Assignee: Qian Zhang >Priority: Major > Fix For: 1.8.0 > > > See [design > doc|https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE-v4KWwjmnCR0l8V4Tq2U/edit#heading=h.f4x59l41lxwx] > for why we need to do this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-8810) Grant non-root task user the permissions to access the SANDBOX_PATH volume of PARENT type
[ https://issues.apache.org/jira/browse/MESOS-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780174#comment-16780174 ] Gilbert Song commented on MESOS-8810: - commit 9c44b31e73783a220e43098a1b117e83e6074fdc Author: Qian Zhang Date: Wed Feb 27 22:22:34 2019 -0800 Added a test `ROOT_UNPRIVILEGED_USER_ParentTypeDifferentUser`. Review: https://reviews.apache.org/r/67997/ commit 16fd7e74b2dc6176d418ebcc1608b94a1159cb15 Author: Qian Zhang Date: Wed Feb 27 22:22:29 2019 -0800 Implemented recovery for volume gid manager. Review: https://reviews.apache.org/r/69676/ > Grant non-root task user the permissions to access the SANDBOX_PATH volume of > PARENT type > - > > Key: MESOS-8810 > URL: https://issues.apache.org/jira/browse/MESOS-8810 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Qian Zhang >Assignee: Qian Zhang >Priority: Major > Fix For: 1.8.0 > > > See [design > doc|https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE-v4KWwjmnCR0l8V4Tq2U/edit#heading=h.s6f8rmu65g2p] > for why we need to do this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-9617) Lint to catch uses of get where operator* should be used.
Meng Zhu created MESOS-9617: --- Summary: Lint to catch uses of get where operator* should be used. Key: MESOS-9617 URL: https://issues.apache.org/jira/browse/MESOS-9617 Project: Mesos Issue Type: Improvement Components: stout Reporter: Meng Zhu Once MESOS-7124 is resolved, we should write a linter to catch uses of `get` where operator* should be used (this could be modeled based on the existing mesos-redundant-get linter). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MESOS-7124) Replace monadic type get() functions with operator*
[
https://issues.apache.org/jira/browse/MESOS-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Meng Zhu reassigned MESOS-7124:
---
Assignee: Meng Zhu
> Replace monadic type get() functions with operator*
> ---
>
> Key: MESOS-7124
> URL: https://issues.apache.org/jira/browse/MESOS-7124
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess, stout
>Reporter: Benjamin Bannier
>Assignee: Meng Zhu
>Priority: Major
> Labels: tech-debt
>
> In MESOS-2757 we introduced {{T* operator->}} for {{Option}}, {{Future}} and
> {{Try}}. This provided a convenient short-hand for existing member functions
> {{T& get}} providing identical functionality.
> To finalize the work of MESOS-2757 we should replace the existing {{T&
> get()}} member functions with functions {{T& operator*}}.
> This is desirable as having both {{operator->}} and {{get}} in the code base
> at the same time lures developers into using the old-style {{get}} instead of
> {{operator->}} where it is not needed, e.g.,
> {code}
> m.get().fun();
> {code}
> instead of
> {code}
> m->fun();
> {code}
> We still require the functionality of {{get}} to directly access the
> contained value, but the current API unnecessarily conflates two (at least
> from a usage perspective) unrelated aspects; in these instances, we should
> use an {{operator*}} instead,
> {code}
> void f(const T&);
>
> Try m = ..;
> f(*m); // instead of: f(m.get());
> {code}
> Using {{operator*}} in these instances makes it much less likely that users
> would use it in instances when they wanted to call functions of the wrapped
> value, i.e.,
> {code}
> m->fun();
> {code}
> appears more natural than
> {code}
> (*m).fun();
> {code}
>
> Note that this proposed change is in line with the interface of
> {{std::optional}}. Also, {{std::shared_ptr}}'s {{get}} is a useful function
> and implements an unrelated interface: it surfaces the wrapped pointer as
> opposed to its {{operator*}} which dereferences the wrapped pointer.
> Similarly, our current {{get}} also produce values, and are unrelated to
> {{std::shared_ptr}}'s {{get}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-9607) Removing a resource provider with users breaks resource publishing
[ https://issues.apache.org/jira/browse/MESOS-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779945#comment-16779945 ] Chun-Hung Hsiao commented on MESOS-9607: As a first step, let's not block task launching if it does not use resources from a failed resource provider. And we can further improve this through MESOS-9387. > Removing a resource provider with users breaks resource publishing > -- > > Key: MESOS-9607 > URL: https://issues.apache.org/jira/browse/MESOS-9607 > Project: Mesos > Issue Type: Bug > Components: agent, resource provider >Reporter: Benjamin Bannier >Priority: Major > Labels: mesosphere-dss-ga > > Currently, the agent publishes all resources considered "used" via the > resource provider manager whenever it is asked to publish a subportion. If a > resource provider with active users (e.g., tasks or even just executors) was > removed, but a user stays around this will fail _any resource publishing_ on > that node since a "used" resource provider is not subscribed. > We should either update the agent code to just deltas, or provide a > workaround of the same effect in the resource provider manager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MESOS-9607) Removing a resource provider with users breaks resource publishing
[ https://issues.apache.org/jira/browse/MESOS-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chun-Hung Hsiao reassigned MESOS-9607: -- Assignee: Chun-Hung Hsiao > Removing a resource provider with users breaks resource publishing > -- > > Key: MESOS-9607 > URL: https://issues.apache.org/jira/browse/MESOS-9607 > Project: Mesos > Issue Type: Bug > Components: agent, resource provider >Reporter: Benjamin Bannier >Assignee: Chun-Hung Hsiao >Priority: Major > Labels: mesosphere-dss-ga > > Currently, the agent publishes all resources considered "used" via the > resource provider manager whenever it is asked to publish a subportion. If a > resource provider with active users (e.g., tasks or even just executors) was > removed, but a user stays around this will fail _any resource publishing_ on > that node since a "used" resource provider is not subscribed. > We should either update the agent code to just deltas, or provide a > workaround of the same effect in the resource provider manager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MESOS-9509) Benchmark command health checks in default executor
[ https://issues.apache.org/jira/browse/MESOS-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779877#comment-16779877 ] Gastón Kleiman edited comment on MESOS-9509 at 2/27/19 11:36 PM: - Attached some recent agent perf traces, agent logs and default executor logs from a Mesos (sha 3886e2a0b77a8f8233d95f785ddb55403e638677) agent (EC2 r4.16xlarge) running a pod with 200 tasks with health checks. was (Author: gkleiman): Attached some recent agent perf traces, agent logs and default executor logs from a Mesos (sha 3886e2a0b77a8f8233d95f785ddb55403e638677) agent running a pod with 200 tasks with health checks. > Benchmark command health checks in default executor > --- > > Key: MESOS-9509 > URL: https://issues.apache.org/jira/browse/MESOS-9509 > Project: Mesos > Issue Type: Task > Components: executor >Reporter: Vinod Kone >Assignee: Greg Mann >Priority: Major > Labels: default-executor, foundations, mesosphere, perfomance > Attachments: check-rate.png, check-responsiveness.png, > mesos-mwstpublicagent1-soak113s.testing.mesosphe.re-22-37.stacks.gz, > multi-healthcheck-large-pod-executor-logs.tar.gz, > mwstpublicagent1-soak113s.testing.mesosphe.re.mesos-agent.log.gz > > > TCP/HTTP health checks were extensively scale tested as part of > https://mesosphere.com/blog/introducing-mesos-native-health-checks-apache-mesos-part-2/. > > We should do the same for command checks by default executor because it uses > a very different mechanism (agent fork/execs the check command as a nested > container) and will have very different scalability characteristics. > We should also use these benchmarks as an opportunity to produce perf traces > of the Mesos agent (both with and without process inheritance) so that a > thorough analysis of the performance can be done as part of MESOS-9513. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-9616) `Filters.refuse_seconds` declines resources not in offers.
[
https://issues.apache.org/jira/browse/MESOS-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779897#comment-16779897
]
Chun-Hung Hsiao commented on MESOS-9616:
It seems an unexpected behavior when a reserved resource or created PV gets
declined just because a framework is not ready to use the resource yet. This
might not be a big problem in the past, but with resource providers capable of
adding resources dynamically, frameworks might want to first reserve one
resource and wait for another to show up before launching a task to consume
both.
> `Filters.refuse_seconds` declines resources not in offers.
> --
>
> Key: MESOS-9616
> URL: https://issues.apache.org/jira/browse/MESOS-9616
> Project: Mesos
> Issue Type: Bug
> Components: allocation
>Reporter: Chun-Hung Hsiao
>Priority: Major
> Labels: mesosphere, resource-management
>
> The
> [documentation|http://mesos.apache.org/documentation/latest/scheduler-http-api/#accept]
> of {{Filters.refuse_seconds}} says:
> {quote}
> Also, any of the offer’s resources not used in the ACCEPT call (e.g., to
> launch a task or task group) are considered declined and might be reoffered
> to other frameworks, meaning that they will not be reoffered to the scheduler
> for the amount of time defined by the filter.
> {quote}
> Consider an {{ACCEPT}} call with just a {{CREATE}} operation, but no
> {{LAUNCH}} or {{LAUNCH_GROUP}}. The {{CREATE}} call will generate a
> persistent volume resource that is *not* in the offer's resources, but it
> will still not be reoffered to the scheduler for the amount of time defined
> by the filter.
> Also, the term *used* is vague here. If we have an {{ACCEPT}} call with a
> {{CREATE}} on a disk followed by a {{DESTROY}} on the created persistent
> volume, would the disk be considered *used*?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-9509) Benchmark command health checks in default executor
[ https://issues.apache.org/jira/browse/MESOS-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779877#comment-16779877 ] Gastón Kleiman commented on MESOS-9509: --- Attached some recent agent perf traces, agent logs and default executor logs from a Mesos (sha 3886e2a0b77a8f8233d95f785ddb55403e638677) agent running a pod with 200 tasks with health checks. > Benchmark command health checks in default executor > --- > > Key: MESOS-9509 > URL: https://issues.apache.org/jira/browse/MESOS-9509 > Project: Mesos > Issue Type: Task > Components: executor >Reporter: Vinod Kone >Assignee: Greg Mann >Priority: Major > Labels: default-executor, foundations, mesosphere, perfomance > Attachments: check-rate.png, check-responsiveness.png, > mesos-mwstpublicagent1-soak113s.testing.mesosphe.re-22-37.stacks.gz, > multi-healthcheck-large-pod-executor-logs.tar.gz, > mwstpublicagent1-soak113s.testing.mesosphe.re.mesos-agent.log.gz > > > TCP/HTTP health checks were extensively scale tested as part of > https://mesosphere.com/blog/introducing-mesos-native-health-checks-apache-mesos-part-2/. > > We should do the same for command checks by default executor because it uses > a very different mechanism (agent fork/execs the check command as a nested > container) and will have very different scalability characteristics. > We should also use these benchmarks as an opportunity to produce perf traces > of the Mesos agent (both with and without process inheritance) so that a > thorough analysis of the performance can be done as part of MESOS-9513. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-9616) `Filters.refuse_seconds` declines resources not in offers.
Chun-Hung Hsiao created MESOS-9616:
--
Summary: `Filters.refuse_seconds` declines resources not in offers.
Key: MESOS-9616
URL: https://issues.apache.org/jira/browse/MESOS-9616
Project: Mesos
Issue Type: Bug
Components: allocation
Reporter: Chun-Hung Hsiao
The
[documentation|http://mesos.apache.org/documentation/latest/scheduler-http-api/#accept]
of {{Filters.refuse_seconds}} says:
{quote}
Also, any of the offer’s resources not used in the ACCEPT call (e.g., to launch
a task or task group) are considered declined and might be reoffered to other
frameworks, meaning that they will not be reoffered to the scheduler for the
amount of time defined by the filter.
{quote}
Consider an {{ACCEPT}} call with just a {{CREATE}} operation, but no {{LAUNCH}}
or {{LAUNCH_GROUP}}. The {{CREATE}} call will generate a persistent volume
resource that is *not* in the offer's resources, but it will still not be
reoffered to the scheduler for the amount of time defined by the filter.
Also, the term *used* is vague here. If we have an {{ACCEPT}} call with a
{{CREATE}} on a disk followed by a {{DESTROY}} on the created persistent
volume, would the disk be considered *used*?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-6840) Tests for quota capacity heuristic.
[ https://issues.apache.org/jira/browse/MESOS-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler reassigned MESOS-6840: -- Assignee: (was: Zhitao Li) > Tests for quota capacity heuristic. > --- > > Key: MESOS-6840 > URL: https://issues.apache.org/jira/browse/MESOS-6840 > Project: Mesos > Issue Type: Task > Components: allocation, test >Reporter: Alexander Rukletsov >Priority: Major > Labels: mesosphere, quota, resource-management > > We need more tests to ensure capacity heuristic works as expected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-7883) Quota heuristic check not accounting for mount volumes
[
https://issues.apache.org/jira/browse/MESOS-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779689#comment-16779689
]
Benjamin Mahler commented on MESOS-7883:
Linking in quota "capacity heuristic" testing work.
> Quota heuristic check not accounting for mount volumes
> --
>
> Key: MESOS-7883
> URL: https://issues.apache.org/jira/browse/MESOS-7883
> Project: Mesos
> Issue Type: Bug
> Components: allocation
>Reporter: Vincent Roy
>Priority: Major
> Labels: resource-management
>
> This may be expected but came as a surprise to us. We are unable to create a
> quota bigger than the root disk space on slaves.
> Given two clusters with the same number of slaves and root disk size, but one
> that also has mount volumes, is what the disk resources look like:
> {noformat}
> [root@fin-fang-foom-master-1 ~]# curl -s master.mesos:5050/state | jq
> '.slaves[] .resources .disk'
> 28698
> 28699
> 28698
> 28698
> 28697
> {noformat}
> {noformat}
> [root@hydra-master-1 ~]# curl -s master.mesos:5050/state | jq '.slaves[]
> .resources .disk'
> 50817
> 50817
> 50814
> 50819
> 50817
> {noformat}
> In {{fin-fang-foom}}, I was able to create a quota for {{143490mb}} which is
> the total of available disk resources, root in this case, as reported by
> Mesos. For {{hydra}}, I am only able to create a quota for {{143489mb}}. This
> is equivalent to the total of root disks available in {{hydra}} rather than
> the total available disks reported by Mesos resources which is {{254084mb}}.
> With a modified Mesos that adds logging to {{quota_handler}}, we can see that
> only the {{disk(*)}} number increases in {{nonStaticClusterResources}} after
> every iteration. The final iteration is {{disk(*):143489}} which is the
> maximum quota I was able to create on {{hydra}}. We expected that quota
> heuristic check would also include resources such as
> {{disk(*)[MOUNT:/dcos/volume2]:7373}}
> {noformat}
> Aug 11 12:54:18 hydra-master-1 mesos-master[24896]: I0811 12:54:18.763764
> 24902 quota_handler.cpp:71] Performing capacity heuristic check for a set
> quota request
> Aug 11 12:54:18 hydra-master-1 mesos-master[24896]: I0811 12:54:18.763783
> 24902 quota_handler.cpp:87] heuristic: total quota 'disk(*):143489'
> Aug 11 12:54:18 hydra-master-1 mesos-master[24896]: I0811 12:54:18.763870
> 24902 quota_handler.cpp:111] heuristic: nonStaticAgentResources =
> 'ports(*):[1025-2180, 2182-3887, 3889-5049, 5052-8079, 8082-8180,
> 8182-32000]; disk(*)[MOUNT:/dcos/volume0]:7373;
> disk(*)[MOUNT:/dcos/volume1]:7373; disk(*)[MOUNT:/dcos/volume2]:7373;
> disk(*):28698; cpus(*):4; mem(*):15023'
> Aug 11 12:54:18 hydra-master-1 mesos-master[24896]: I0811 12:54:18.763923
> 24902 quota_handler.cpp:113] heuristic: nonStaticClusterResources =
> 'ports(*):[1025-2180, 2182-3887, 3889-5049, 5052-8079, 8082-8180,
> 8182-32000]; disk(*)[MOUNT:/dcos/volume0]:7373;
> disk(*)[MOUNT:/dcos/volume1]:7373; disk(*)[MOUNT:/dcos/volume2]:7373;
> disk(*):28698; cpus(*):4; mem(*):15023'
> Aug 11 12:54:18 hydra-master-1 mesos-master[24896]: I0811 12:54:18.763989
> 24902 quota_handler.cpp:111] heuristic: nonStaticAgentResources =
> 'ports(*):[1025-2180, 2182-3887, 3889-5049, 5052-8079, 8082-8180,
> 8182-32000]; disk(*)[MOUNT:/dcos/volume0]:7373;
> disk(*)[MOUNT:/dcos/volume1]:7373; disk(*)[MOUNT:/dcos/volume2]:7373;
> disk(*):28698; cpus(*):4; mem(*):15023'
> Aug 11 12:54:18 hydra-master-1 mesos-master[24896]: I0811 12:54:18.764022
> 24902 quota_handler.cpp:113] heuristic: nonStaticClusterResources =
> 'ports(*):[1025-2180, 2182-3887, 3889-5049, 5052-8079, 8082-8180,
> 8182-32000]; disk(*)[MOUNT:/dcos/volume0]:7373;
> disk(*)[MOUNT:/dcos/volume1]:7373; disk(*)[MOUNT:/dcos/volume2]:7373;
> disk(*):57396; cpus(*):8; mem(*):30046; disk(*)[MOUNT:/dcos/volume0]:7373;
> disk(*)[MOUNT:/dcos/volume1]:7373; disk(*)[MOUNT:/dcos/volume2]:7373'
> Aug 11 12:54:18 hydra-master-1 mesos-master[24896]: I0811 12:54:18.764077
> 24902 quota_handler.cpp:111] heuristic: nonStaticAgentResources =
> 'ports(*):[1025-2180, 2182-3887, 3889-5049, 5052-8079, 8082-8180,
> 8182-32000]; disk(*)[MOUNT:/dcos/volume0]:7373;
> disk(*)[MOUNT:/dcos/volume1]:7373; disk(*)[MOUNT:/dcos/volume2]:7373;
> disk(*):28695; cpus(*):4; mem(*):15023'
> Aug 11 12:54:18 hydra-master-1 mesos-master[24896]: I0811 12:54:18.764119
> 24902 quota_handler.cpp:113] heuristic: nonStaticClusterResources =
> 'ports(*):[1025-2180, 2182-3887, 3889-5049, 5052-8079, 8082-8180,
> 8182-32000]; disk(*)[MOUNT:/dcos/volume0]:7373;
> disk(*)[MOUNT:/dcos/volume1]:7373; disk(*)[MOUNT:/dcos/volume2]:7373;
> disk(*):86091; cpus(*):12; mem(*):45069; disk(*)[MOUNT:/dcos/volume0]:7373;
> disk(*)[MOUNT:/dcos/volume1]:7373; disk(*)[MOUNT:/dcos/volume2]:7373;
>
[jira] [Assigned] (MESOS-6840) Tests for quota capacity heuristic.
[ https://issues.apache.org/jira/browse/MESOS-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler reassigned MESOS-6840: -- Shepherd: (was: Alexander Rukletsov) Assignee: Benjamin Mahler Sprint: Resource Mgmt RI11 Sp 41 > Tests for quota capacity heuristic. > --- > > Key: MESOS-6840 > URL: https://issues.apache.org/jira/browse/MESOS-6840 > Project: Mesos > Issue Type: Task > Components: allocation, test >Reporter: Alexander Rukletsov >Assignee: Benjamin Mahler >Priority: Major > Labels: mesosphere, quota, resource-management > > We need more tests to ensure capacity heuristic works as expected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-6840) Tests for quota capacity heuristic.
[ https://issues.apache.org/jira/browse/MESOS-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779681#comment-16779681 ] Benjamin Mahler commented on MESOS-6840: As part of testing the capacity heuristic, we'd like to refactor the code to make it unit-testable. > Tests for quota capacity heuristic. > --- > > Key: MESOS-6840 > URL: https://issues.apache.org/jira/browse/MESOS-6840 > Project: Mesos > Issue Type: Task > Components: allocation, test >Reporter: Alexander Rukletsov >Priority: Major > Labels: mesosphere, quota, resource-management > > We need more tests to ensure capacity heuristic works as expected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MESOS-9615) Example framework for feedback on agent default resources
[ https://issues.apache.org/jira/browse/MESOS-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Mann reassigned MESOS-9615: Assignee: Benno Evers > Example framework for feedback on agent default resources > - > > Key: MESOS-9615 > URL: https://issues.apache.org/jira/browse/MESOS-9615 > Project: Mesos > Issue Type: Task >Reporter: Greg Mann >Assignee: Benno Evers >Priority: Major > Labels: foundations, mesosphere > > We need a framework that can be used to test operations on agent default > resources which request operation feedback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MESOS-9610) Fetcher vulnerability - escaping from sandbox
[
https://issues.apache.org/jira/browse/MESOS-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Mann reassigned MESOS-9610:
Assignee: Joseph Wu
> Fetcher vulnerability - escaping from sandbox
> -
>
> Key: MESOS-9610
> URL: https://issues.apache.org/jira/browse/MESOS-9610
> Project: Mesos
> Issue Type: Bug
> Components: fetcher
>Affects Versions: 1.7.2
>Reporter: Mariusz Derela
>Assignee: Joseph Wu
>Priority: Blocker
> Labels: bug, foundations, security-issue, vulnerabilities
>
> I have noticed that there is a possibility to exploit fetcher and overwrite
> any file on the agent host.
> scenario to reproduce:
> 1) prepare a file with any content and name a file like "../../../etc/test"
> and archive it. We can use python and zipfile module to achieve that:
> {code:java}
> >>> import zipfile
> >>> zip = zipfile.ZipFile("exploit.zip", "w")
> >>> zip.writestr("../../../../../../../../../../../../etc/mariusz_was_here.txt",
> >>> "some content")
> >>> zip.close()
> {code}
> 2) prepare a service that will use our artifact (exploit.zip)
> 3) run service
> at the end in /etc we will get our file. As you can imagine there is a lot
> possibility how we can use it.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-9615) Example framework for feedback on agent default resources
Greg Mann created MESOS-9615: Summary: Example framework for feedback on agent default resources Key: MESOS-9615 URL: https://issues.apache.org/jira/browse/MESOS-9615 Project: Mesos Issue Type: Task Reporter: Greg Mann We need a framework that can be used to test operations on agent default resources which request operation feedback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MESOS-8241) Add metrics for offer operation feedback
[ https://issues.apache.org/jira/browse/MESOS-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Mann reassigned MESOS-8241: Assignee: Benno Evers > Add metrics for offer operation feedback > > > Key: MESOS-8241 > URL: https://issues.apache.org/jira/browse/MESOS-8241 > Project: Mesos > Issue Type: Task >Reporter: Greg Mann >Assignee: Benno Evers >Priority: Major > Labels: foundations, mesosphere, operation-feedback > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-9610) Fetcher vulnerability - escaping from sandbox
[
https://issues.apache.org/jira/browse/MESOS-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779365#comment-16779365
]
Mariusz Derela commented on MESOS-9610:
---
I have checked the newest version of libarchive. It seems that issue is still
there.
> Fetcher vulnerability - escaping from sandbox
> -
>
> Key: MESOS-9610
> URL: https://issues.apache.org/jira/browse/MESOS-9610
> Project: Mesos
> Issue Type: Bug
> Components: fetcher
>Affects Versions: 1.7.2
>Reporter: Mariusz Derela
>Priority: Blocker
> Labels: bug, security-issue, vulnerabilities
>
> I have noticed that there is a possibility to exploit fetcher and overwrite
> any file on the agent host.
> scenario to reproduce:
> 1) prepare a file with any content and name a file like "../../../etc/test"
> and archive it. We can use python and zipfile module to achieve that:
> {code:java}
> >>> import zipfile
> >>> zip = zipfile.ZipFile("exploit.zip", "w")
> >>> zip.writestr("../../../../../../../../../../../../etc/mariusz_was_here.txt",
> >>> "some content")
> >>> zip.close()
> {code}
> 2) prepare a service that will use our artifact (exploit.zip)
> 3) run service
> at the end in /etc we will get our file. As you can imagine there is a lot
> possibility how we can use it.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-9614) Implement filtering of Seccomp rules by kernel version.
Andrei Budnik created MESOS-9614:
Summary: Implement filtering of Seccomp rules by kernel version.
Key: MESOS-9614
URL: https://issues.apache.org/jira/browse/MESOS-9614
Project: Mesos
Issue Type: Task
Components: containerization
Reporter: Andrei Budnik
The most recent Docker profile allows specify filtering by kernel version, e.g:
{code:java}
{
"names": [
"ptrace"
],
"action": "SCMP_ACT_ALLOW",
"args": null,
"comment": "",
"includes": {
"minKernel": "4.8"
},
"excludes": {}
},
{code}
We need to add support for `minKernel` filter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-4809) Allow parallel execution of tests
[ https://issues.apache.org/jira/browse/MESOS-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bannier reassigned MESOS-4809: --- Assignee: (was: Benjamin Bannier) > Allow parallel execution of tests > - > > Key: MESOS-4809 > URL: https://issues.apache.org/jira/browse/MESOS-4809 > Project: Mesos > Issue Type: Epic >Reporter: Benjamin Bannier >Priority: Minor > Labels: mesosphere > > We should allow parallel execution of tests. There are two flavors to this: > (a) tests are run in parallel in the same process, or > (b) tests are run in parallel with separate processes (e.g., with > gtest-parallel). > While (a) likely has overall better performance, it depends on tests being > independent of global state (e.g., current directory, and others). On the > other hand, already (b) improves execution time, and has much smaller > requirements. > This epic tracks efforts to fix test to allow scenario (b) above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
