[jira] [Updated] (MESOS-5172) Registry puller cannot fetch blobs correctly from some private repos.
[ https://issues.apache.org/jira/browse/MESOS-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilbert Song updated MESOS-5172: Sprint: Mesosphere Sprint 33, Mesosphere Sprint 37 (was: Mesosphere Sprint 33, Mesosphere Sprint 37, Mesosphere Sprint 38) > Registry puller cannot fetch blobs correctly from some private repos. > - > > Key: MESOS-5172 > URL: https://issues.apache.org/jira/browse/MESOS-5172 > Project: Mesos > Issue Type: Bug > Components: containerization >Reporter: Gilbert Song >Assignee: Gilbert Song > Labels: containerizer, mesosphere > > When the registry puller is pulling a private repository from some private > registry (e.g., quay.io), errors may occur when fetching blobs, at which > point fetching the manifest of the repo is finished correctly. The error > message is `Unexpected HTTP response '400 Bad Request' when trying to > download the blob`. This may arise from the logic of fetching blobs, or > incorrect format of uri when requesting blobs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5781) Benchmark allocation with framework suppression.
[ https://issues.apache.org/jira/browse/MESOS-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361832#comment-15361832 ] Jacob Janco commented on MESOS-5781: https://reviews.apache.org/r/49616/ > Benchmark allocation with framework suppression. > > > Key: MESOS-5781 > URL: https://issues.apache.org/jira/browse/MESOS-5781 > Project: Mesos > Issue Type: Improvement >Reporter: Jacob Janco >Assignee: Jacob Janco > Labels: allocator, benchmark > > Benchmarks effects of framework suppression on allocation time. Frameworks > are suppressed and resources recovered each iteration and allocation time is > measured as we move to suppress all frameworks in the test case. Referencing > MESOS-4694. > Sample run at top of tree: > Using 2000 agents and 200 frameworks > round 0 allocate took 2.630963secs to make 199 offers > round 1 allocate took 2.640694secs to make 198 offers > round 2 allocate took 2.642664secs to make 197 offers > ... > round 197 allocate took 2.433047secs to make 2 offers > round 198 allocate took 2.409804secs to make 1 offers > round 199 allocate took 252270us to make 0 offers > Sample run with MESOS-4694 (https://reviews.apache.org/r/43666/): > Using 2000 agents and 200 frameworks > round 0 allocate took 2.626182secs to make 199 offers > round 1 allocate took 2.62286secs to make 198 offers > round 2 allocate took 2.591389secs to make 197 offers > ... > round 101 allocate took 1.494164secs to make 98 offers > round 102 allocate took 1.491371secs to make 97 offers > round 103 allocate took 1.491969secs to make 96 offers > ... > round 197 allocate took 534780us to make 2 offers > round 198 allocate took 501947us to make 1 offers > round 199 allocate took 24929us to make 0 offers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5781) Benchmark allocation with framework suppression.
[ https://issues.apache.org/jira/browse/MESOS-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Janco updated MESOS-5781: --- Description: Benchmarks effects of framework suppression on allocation time. Frameworks are suppressed and resources recovered each iteration and allocation time is measured as we move to suppress all frameworks in the test case. Referencing MESOS-4694. Sample run at top of tree: Using 2000 agents and 200 frameworks round 0 allocate took 2.630963secs to make 199 offers round 1 allocate took 2.640694secs to make 198 offers round 2 allocate took 2.642664secs to make 197 offers ... round 197 allocate took 2.433047secs to make 2 offers round 198 allocate took 2.409804secs to make 1 offers round 199 allocate took 252270us to make 0 offers Sample run with MESOS-4694 (https://reviews.apache.org/r/43666/): Using 2000 agents and 200 frameworks round 0 allocate took 2.626182secs to make 199 offers round 1 allocate took 2.62286secs to make 198 offers round 2 allocate took 2.591389secs to make 197 offers ... round 101 allocate took 1.494164secs to make 98 offers round 102 allocate took 1.491371secs to make 97 offers round 103 allocate took 1.491969secs to make 96 offers ... round 197 allocate took 534780us to make 2 offers round 198 allocate took 501947us to make 1 offers round 199 allocate took 24929us to make 0 offers was: Benchmarks effects of framework suppression on allocation time. Frameworks are suppressed and resources recovered each iteration and allocation time is measured as we move to suppress all frameworks in the test case. Referencing MESOS-4694. Sample run at top of tree: Using 2000 agents and 200 frameworks round 0 allocate took 2.630963secs to make 199 offers round 1 allocate took 2.640694secs to make 198 offers round 2 allocate took 2.642664secs to make 197 offers ... round 197 allocate took 2.433047secs to make 2 offers round 198 allocate took 2.409804secs to make 1 offers round 199 allocate took 252270us to make 0 offers Sample run with MESOS-4694 (https://reviews.apache.org/r/43666/): round 0 allocate took 2.626182secs to make 199 offers round 1 allocate took 2.62286secs to make 198 offers round 2 allocate took 2.591389secs to make 197 offers ... round 101 allocate took 1.494164secs to make 98 offers round 102 allocate took 1.491371secs to make 97 offers round 103 allocate took 1.491969secs to make 96 offers ... round 197 allocate took 534780us to make 2 offers round 198 allocate took 501947us to make 1 offers round 199 allocate took 24929us to make 0 offers > Benchmark allocation with framework suppression. > > > Key: MESOS-5781 > URL: https://issues.apache.org/jira/browse/MESOS-5781 > Project: Mesos > Issue Type: Improvement >Reporter: Jacob Janco >Assignee: Jacob Janco > Labels: allocator, benchmark > > Benchmarks effects of framework suppression on allocation time. Frameworks > are suppressed and resources recovered each iteration and allocation time is > measured as we move to suppress all frameworks in the test case. Referencing > MESOS-4694. > Sample run at top of tree: > Using 2000 agents and 200 frameworks > round 0 allocate took 2.630963secs to make 199 offers > round 1 allocate took 2.640694secs to make 198 offers > round 2 allocate took 2.642664secs to make 197 offers > ... > round 197 allocate took 2.433047secs to make 2 offers > round 198 allocate took 2.409804secs to make 1 offers > round 199 allocate took 252270us to make 0 offers > Sample run with MESOS-4694 (https://reviews.apache.org/r/43666/): > Using 2000 agents and 200 frameworks > round 0 allocate took 2.626182secs to make 199 offers > round 1 allocate took 2.62286secs to make 198 offers > round 2 allocate took 2.591389secs to make 197 offers > ... > round 101 allocate took 1.494164secs to make 98 offers > round 102 allocate took 1.491371secs to make 97 offers > round 103 allocate took 1.491969secs to make 96 offers > ... > round 197 allocate took 534780us to make 2 offers > round 198 allocate took 501947us to make 1 offers > round 199 allocate took 24929us to make 0 offers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5781) Benchmark allocation with framework suppression.
Jacob Janco created MESOS-5781: -- Summary: Benchmark allocation with framework suppression. Key: MESOS-5781 URL: https://issues.apache.org/jira/browse/MESOS-5781 Project: Mesos Issue Type: Improvement Reporter: Jacob Janco Assignee: Jacob Janco Benchmarks effects of framework suppression on allocation time. Frameworks are suppressed and resources recovered each iteration and allocation time is measured as we move to suppress all frameworks in the test case. Referencing MESOS-4694. Sample run at top of tree: Using 2000 agents and 200 frameworks round 0 allocate took 2.630963secs to make 199 offers round 1 allocate took 2.640694secs to make 198 offers round 2 allocate took 2.642664secs to make 197 offers ... round 197 allocate took 2.433047secs to make 2 offers round 198 allocate took 2.409804secs to make 1 offers round 199 allocate took 252270us to make 0 offers Sample run with MESOS-4694 (https://reviews.apache.org/r/43666/): round 0 allocate took 2.626182secs to make 199 offers round 1 allocate took 2.62286secs to make 198 offers round 2 allocate took 2.591389secs to make 197 offers ... round 101 allocate took 1.494164secs to make 98 offers round 102 allocate took 1.491371secs to make 97 offers round 103 allocate took 1.491969secs to make 96 offers ... round 197 allocate took 534780us to make 2 offers round 198 allocate took 501947us to make 1 offers round 199 allocate took 24929us to make 0 offers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5780) Benchmark framework failover.
[ https://issues.apache.org/jira/browse/MESOS-5780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Janco updated MESOS-5780: --- Description: Benchmarking disconnection and reconnection of all frameworks in cluster proves useful in gauging the efficiency of the allocator's handling of a flooded event queue. I'd also like to reference MESOS-3157. Sample run at top of tree: [ RUN ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 Allocator settled after 11.8424527mins for 5000 agents and 500 frameworks Sample run with MESOS-3157: [ RUN ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 Allocator settled after 5.98023secs for 5000 agents and 500 frameworks was: Benchmarking disconnection and reconnection of all frameworks in cluster proves useful in gauging the efficiency of the allocator's handling a flooded event queue. I'd also like to reference MESOS-3157. Sample run at top of tree: [ RUN ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 Allocator settled after 11.8424527mins for 5000 agents and 500 frameworks Sample run with MESOS-3157: [ RUN ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 Allocator settled after 5.98023secs for 5000 agents and 500 frameworks > Benchmark framework failover. > - > > Key: MESOS-5780 > URL: https://issues.apache.org/jira/browse/MESOS-5780 > Project: Mesos > Issue Type: Improvement >Reporter: Jacob Janco >Assignee: Jacob Janco > Labels: allocator, benchmark, framework > > Benchmarking disconnection and reconnection of all frameworks in cluster > proves useful in gauging the efficiency of the allocator's handling of a > flooded event queue. I'd also like to reference MESOS-3157. > Sample run at top of tree: > [ RUN ] > SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 > Allocator settled after 11.8424527mins for 5000 agents and 500 frameworks > Sample run with MESOS-3157: > [ RUN ] > SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 > Allocator settled after 5.98023secs for 5000 agents and 500 frameworks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5780) Benchmark framework failover.
[ https://issues.apache.org/jira/browse/MESOS-5780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Janco updated MESOS-5780: --- Description: Benchmarking disconnection and reconnection of all frameworks in cluster proves useful in gauging the efficiency of the allocator's handling a flooded event queue. I'd also like to reference MESOS-3157. Sample run at top of tree: [ RUN ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 Allocator settled after 11.8424527mins for 5000 agents and 500 frameworks Sample run with MESOS-3157: [ RUN ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 Allocator settled after 5.98023secs for 5000 agents and 500 frameworks was: Benchmarking disconnection and reconnection of all frameworks in cluster proves useful in gauging the efficiency of the allocator's efficiency in handling a flooded event queue. I'd also like to reference MESOS-3157. Sample run at top of tree: [ RUN ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 Allocator settled after 11.8424527mins for 5000 agents and 500 frameworks Sample run with MESOS-3157: [ RUN ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 Allocator settled after 5.98023secs for 5000 agents and 500 frameworks > Benchmark framework failover. > - > > Key: MESOS-5780 > URL: https://issues.apache.org/jira/browse/MESOS-5780 > Project: Mesos > Issue Type: Improvement >Reporter: Jacob Janco >Assignee: Jacob Janco > Labels: allocator, benchmark, framework > > Benchmarking disconnection and reconnection of all frameworks in cluster > proves useful in gauging the efficiency of the allocator's handling a flooded > event queue. I'd also like to reference MESOS-3157. > Sample run at top of tree: > [ RUN ] > SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 > Allocator settled after 11.8424527mins for 5000 agents and 500 frameworks > Sample run with MESOS-3157: > [ RUN ] > SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 > Allocator settled after 5.98023secs for 5000 agents and 500 frameworks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5780) Benchmark framework failover.
[ https://issues.apache.org/jira/browse/MESOS-5780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361828#comment-15361828 ] Jacob Janco commented on MESOS-5780: https://reviews.apache.org/r/49617 > Benchmark framework failover. > - > > Key: MESOS-5780 > URL: https://issues.apache.org/jira/browse/MESOS-5780 > Project: Mesos > Issue Type: Improvement >Reporter: Jacob Janco >Assignee: Jacob Janco > Labels: allocator, benchmark, framework > > Benchmarking disconnection and reconnection of all frameworks in cluster > proves useful in gauging the efficiency of the allocator's efficiency in > handling a flooded event queue. I'd also like to reference MESOS-3157. > Sample run at top of tree: > [ RUN ] > SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 > Allocator settled after 11.8424527mins for 5000 agents and 500 frameworks > Sample run with MESOS-3157: > [ RUN ] > SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 > Allocator settled after 5.98023secs for 5000 agents and 500 frameworks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5780) Benchmark framework failover.
Jacob Janco created MESOS-5780: -- Summary: Benchmark framework failover. Key: MESOS-5780 URL: https://issues.apache.org/jira/browse/MESOS-5780 Project: Mesos Issue Type: Improvement Reporter: Jacob Janco Assignee: Jacob Janco Benchmarking disconnection and reconnection of all frameworks in cluster proves useful in gauging the efficiency of the allocator's efficiency in handling a flooded event queue. I'd also like to reference MESOS-3157. Sample run at top of tree: [ RUN ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 Allocator settled after 11.8424527mins for 5000 agents and 500 frameworks Sample run with MESOS-3157: [ RUN ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.FrameworkFailover/10 Allocator settled after 5.98023secs for 5000 agents and 500 frameworks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5401) Add ability to inject a Volume of Nvidia GPU-related libraries into a docker container.
[ https://issues.apache.org/jira/browse/MESOS-5401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361796#comment-15361796 ] Kevin Klues commented on MESOS-5401: This patch adds support for deciding if we should inject a volume or not: https://reviews.apache.org/r/49615/ > Add ability to inject a Volume of Nvidia GPU-related libraries into a docker > container. > --- > > Key: MESOS-5401 > URL: https://issues.apache.org/jira/browse/MESOS-5401 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Assignee: Kevin Klues > Labels: gpu, mesosphere > Fix For: 1.0.0 > > > In order to support Nvidia GPUs with docker containers in Mesos, we need to > be able to consolidate all Nvidia libraries into a common volume and inject > that volume into the container. > More info on why this is necessary here: > https://github.com/NVIDIA/nvidia-docker/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5757) Authorize orphaned tasks
[ https://issues.apache.org/jira/browse/MESOS-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361699#comment-15361699 ] Joerg Schad commented on MESOS-5757: Extended install() to support 7 arguments. https://reviews.apache.org/r/49606/ Added support for recovered frameworks. https://reviews.apache.org/r/49607/ Added filtering for orphaned tasks in /state endpoint. https://reviews.apache.org/r/49609/ (test are almost ready and will follow tomorrow) > Authorize orphaned tasks > > > Key: MESOS-5757 > URL: https://issues.apache.org/jira/browse/MESOS-5757 > Project: Mesos > Issue Type: Bug > Components: security >Affects Versions: 1.0.0 >Reporter: Vinod Kone >Assignee: Joerg Schad > Labels: mesosphere, security > Fix For: 1.0.0 > > > Currently, orphaned tasks are not filtered (i.e., using authorization) when a > request is made to /state endpoint. This is inconsistent (and unexpected) > with how we filter un-orphaned tasks. > This is tricky because master and hence the authorizer do not have > FrameworkInfos for these orphaned tasks, until after the corresponding > frameworks re-register. > One option is for the agent to include FrameworkInfos of all its tasks and > executors in its re-registration message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5779) Allow Docker v1 ImageManifests to be parsed from the output of `docker inspect`
[ https://issues.apache.org/jira/browse/MESOS-5779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-5779: --- Summary: Allow Docker v1 ImageManifests to be parsed from the output of `docker inspect` (was: Allow Docker v1 ImageManifests to parsed from the output of `docker inspect`) > Allow Docker v1 ImageManifests to be parsed from the output of `docker > inspect` > --- > > Key: MESOS-5779 > URL: https://issues.apache.org/jira/browse/MESOS-5779 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Assignee: Kevin Klues > Fix For: 1.0.0 > > > The `docker::spec::v1::ImageManifest` protobuf implements the > official v1 image manifest specification found at: > > https://github.com/docker/docker/blob/master/image/spec/v1.md > > The field names in this spec are all written in snake_case as are the > field names of the JSON representing the image manifest when reading > it from disk (for example after performing a `docker save`). As such, > the protobuf for ImageManifest also provides these fields in > snake_case. Unfortunately, the `docker inspect` command also provides > a method of retrieving the JSON for an image manifest, with one major > caveat -- it represents all of its top level keys in CamelCase. > > To allow both representations to be parsed in the same way, we > should intercept the incoming JSON from either source (disk or `docker > inspect`) and convert it to a canonical snake_case representation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5779) Allow Docker v1 ImageManifests to parsed from the output of `docker inspect`
[
https://issues.apache.org/jira/browse/MESOS-5779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-5779:
---
Summary: Allow Docker v1 ImageManifests to parsed from the output of
`docker inspect` (was: Allow Docker v1 ImageManifests to parsed from the
output of {{docker inspect}})
> Allow Docker v1 ImageManifests to parsed from the output of `docker inspect`
>
>
> Key: MESOS-5779
> URL: https://issues.apache.org/jira/browse/MESOS-5779
> Project: Mesos
> Issue Type: Improvement
>Reporter: Kevin Klues
>Assignee: Kevin Klues
> Fix For: 1.0.0
>
>
> The `docker::spec::v1::ImageManifest` protobuf implements the
> official v1 image manifest specification found at:
>
> https://github.com/docker/docker/blob/master/image/spec/v1.md
>
> The field names in this spec are all written in snake_case as are the
> field names of the JSON representing the image manifest when reading
> it from disk (for example after performing a `docker save`). As such,
> the protobuf for ImageManifest also provides these fields in
> snake_case. Unfortunately, the `docker inspect` command also provides
> a method of retrieving the JSON for an image manifest, with one major
> caveat -- it represents all of its top level keys in CamelCase.
>
> To allow both representations to be parsed in the same way, we
> should intercept the incoming JSON from either source (disk or `docker
> inspect`) and convert it to a canonical snake_case representation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5779) Allow Docker v1 ImageManifests to parsed from the output of {{docker inspect}}
Kevin Klues created MESOS-5779:
--
Summary: Allow Docker v1 ImageManifests to parsed from the output
of {{docker inspect}}
Key: MESOS-5779
URL: https://issues.apache.org/jira/browse/MESOS-5779
Project: Mesos
Issue Type: Improvement
Reporter: Kevin Klues
Assignee: Kevin Klues
Fix For: 1.0.0
The `docker::spec::v1::ImageManifest` protobuf implements the
official v1 image manifest specification found at:
https://github.com/docker/docker/blob/master/image/spec/v1.md
The field names in this spec are all written in snake_case as are the
field names of the JSON representing the image manifest when reading
it from disk (for example after performing a `docker save`). As such,
the protobuf for ImageManifest also provides these fields in
snake_case. Unfortunately, the `docker inspect` command also provides
a method of retrieving the JSON for an image manifest, with one major
caveat -- it represents all of its top level keys in CamelCase.
To allow both representations to be parsed in the same way, we
should intercept the incoming JSON from either source (disk or `docker
inspect`) and convert it to a canonical snake_case representation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5708) Add authz to /files/debug
[ https://issues.apache.org/jira/browse/MESOS-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361635#comment-15361635 ] Abhishek Dasgupta commented on MESOS-5708: -- RR: https://reviews.apache.org/r/49600/ > Add authz to /files/debug > - > > Key: MESOS-5708 > URL: https://issues.apache.org/jira/browse/MESOS-5708 > Project: Mesos > Issue Type: Task > Components: security >Reporter: Adam B >Assignee: Abhishek Dasgupta >Priority: Minor > Labels: mesosphere, security > Fix For: 1.0.0 > > > The /files/debug endpoint exposes the attached master/agent log paths and > every attached sandbox path, which includes the frameworkId and executorId. > Even if sandboxes are protected, we still don't want to expose this > information to unauthorized users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5730) Sandbox access authorization should fail for non existing sandboxes.
[
https://issues.apache.org/jira/browse/MESOS-5730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361591#comment-15361591
]
Till Toenshoff commented on MESOS-5730:
---
We decided that the documentation enhancement would make this a non-blocker.
> Sandbox access authorization should fail for non existing sandboxes.
>
>
> Key: MESOS-5730
> URL: https://issues.apache.org/jira/browse/MESOS-5730
> Project: Mesos
> Issue Type: Bug
> Components: security
>Affects Versions: 1.0.0
>Reporter: Till Toenshoff
> Labels: authorization, mesosphere, security
> Fix For: 1.0.0
>
>
> The local authorizer currently tries to authorize {{ACCESS_SANDBOX}} even if
> no further object specification - e.g. {{framework_info}} or
> {{executor_info}}) where specified / available at that time.
> Given that there is likely no sandbox available if there was no
> {{executor_info}} provided, I think we should actually fail instead of allow
> or deny (403).
> A failure would result into an IMHO more appropriate ServiceUnavailable
> (503).
> See
> https://github.com/apache/mesos/commit/c8d67590064e35566274116cede9c6a733187b48#diff-dd692b1640b2628014feca01a94ba1e1R241
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5730) Sandbox access authorization should fail for non existing sandboxes.
[
https://issues.apache.org/jira/browse/MESOS-5730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-5730:
--
Priority: Major (was: Blocker)
> Sandbox access authorization should fail for non existing sandboxes.
>
>
> Key: MESOS-5730
> URL: https://issues.apache.org/jira/browse/MESOS-5730
> Project: Mesos
> Issue Type: Bug
> Components: security
>Affects Versions: 1.0.0
>Reporter: Till Toenshoff
> Labels: authorization, mesosphere, security
> Fix For: 1.0.0
>
>
> The local authorizer currently tries to authorize {{ACCESS_SANDBOX}} even if
> no further object specification - e.g. {{framework_info}} or
> {{executor_info}}) where specified / available at that time.
> Given that there is likely no sandbox available if there was no
> {{executor_info}} provided, I think we should actually fail instead of allow
> or deny (403).
> A failure would result into an IMHO more appropriate ServiceUnavailable
> (503).
> See
> https://github.com/apache/mesos/commit/c8d67590064e35566274116cede9c6a733187b48#diff-dd692b1640b2628014feca01a94ba1e1R241
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5730) Sandbox access authorization should fail for non existing sandboxes.
[
https://issues.apache.org/jira/browse/MESOS-5730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361590#comment-15361590
]
Till Toenshoff commented on MESOS-5730:
---
{noformat}
commit 97cc5b58c67930cc3d23eaefe14b5be3f84af4a2
Author: Joerg Schad
Date: Mon Jul 4 18:44:16 2016 +0200
Fixed incorrect comment on ACCESS_SANDBOX in authorizer.proto.
The current semantic is that these fields might not be set.
Review: https://reviews.apache.org/r/49319/
{noformat}
> Sandbox access authorization should fail for non existing sandboxes.
>
>
> Key: MESOS-5730
> URL: https://issues.apache.org/jira/browse/MESOS-5730
> Project: Mesos
> Issue Type: Bug
> Components: security
>Affects Versions: 1.0.0
>Reporter: Till Toenshoff
>Priority: Blocker
> Labels: authorization, mesosphere, security
> Fix For: 1.0.0
>
>
> The local authorizer currently tries to authorize {{ACCESS_SANDBOX}} even if
> no further object specification - e.g. {{framework_info}} or
> {{executor_info}}) where specified / available at that time.
> Given that there is likely no sandbox available if there was no
> {{executor_info}} provided, I think we should actually fail instead of allow
> or deny (403).
> A failure would result into an IMHO more appropriate ServiceUnavailable
> (503).
> See
> https://github.com/apache/mesos/commit/c8d67590064e35566274116cede9c6a733187b48#diff-dd692b1640b2628014feca01a94ba1e1R241
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-5294) Status updates after a health check are incomplete or invalid
[
https://issues.apache.org/jira/browse/MESOS-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Hegner reassigned MESOS-5294:
Assignee: haosdent (was: Travis Hegner)
> Status updates after a health check are incomplete or invalid
> -
>
> Key: MESOS-5294
> URL: https://issues.apache.org/jira/browse/MESOS-5294
> Project: Mesos
> Issue Type: Bug
> Environment: mesos 0.28.0, docker 1.11, marathon 0.15.3, mesos-dns,
> ubuntu 14.04
>Reporter: Travis Hegner
>Assignee: haosdent
>
> With command health checks enabled via marathon, mesos-dns will resolve the
> task correctly until the task is reported as "healthy". At that point,
> mesos-dns stops resolving the task correctly.
> -Digging through src/docker/executor.cpp, I found that in the
> {{taskHealthUpdated()}} function is attempting to copy the taskID to the new
> status instance with-
> {code}status.mutable_task_id()->CopyFrom(taskID);{code}
> -but other instances of status updates have a similar line-
> {code}status.mutable_task_id()->CopyFrom(taskID.get());{code}
> -My assumption is that this difference is causing the status update after a
> health check to not have a proper taskID, which in turn is causing an
> incorrect state.json output.-
> -I'll try to get a patch together soon.-
> UPDATE:
> None of the above assumption are correct. Something else is causing the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-5603) Improve test cases in ValueTest
[
https://issues.apache.org/jira/browse/MESOS-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klaus Ma reassigned MESOS-5603:
---
Assignee: Klaus Ma
> Improve test cases in ValueTest
> ---
>
> Key: MESOS-5603
> URL: https://issues.apache.org/jira/browse/MESOS-5603
> Project: Mesos
> Issue Type: Improvement
>Reporter: Klaus Ma
>Assignee: Klaus Ma
>
> In {{ValueTest.*}}, it did not include enough cases for positive & negative
> cases. It's better to add more cases to show which cases are allowed and
> which cases are disallowed.
> And the related document should be also updated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5596) Document agent signal handling behavior
[ https://issues.apache.org/jira/browse/MESOS-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Conway updated MESOS-5596: --- Summary: Document agent signal handling behavior (was: Document agent SIGTERM behavior) > Document agent signal handling behavior > --- > > Key: MESOS-5596 > URL: https://issues.apache.org/jira/browse/MESOS-5596 > Project: Mesos > Issue Type: Bug > Components: documentation >Reporter: Neil Conway >Priority: Minor > Labels: documentation, mesosphere, newbie++ > > Sending a SIGTERM to agents can be useful; we should document how > agents/masters handle this situation, versus a spontaneous agent > disconnection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5596) Document agent signal handling behavior
[ https://issues.apache.org/jira/browse/MESOS-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Conway updated MESOS-5596: --- Description: Sending a SIGUSR1 to cause agents to shutdown gracefully can be useful; we should document how agents/masters handle this situation, versus a spontaneous agent disconnection. (was: Sending a SIGTERM to agents can be useful; we should document how agents/masters handle this situation, versus a spontaneous agent disconnection.) > Document agent signal handling behavior > --- > > Key: MESOS-5596 > URL: https://issues.apache.org/jira/browse/MESOS-5596 > Project: Mesos > Issue Type: Bug > Components: documentation >Reporter: Neil Conway >Priority: Minor > Labels: documentation, mesosphere, newbie++ > > Sending a SIGUSR1 to cause agents to shutdown gracefully can be useful; we > should document how agents/masters handle this situation, versus a > spontaneous agent disconnection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5757) Authorize orphaned tasks
[ https://issues.apache.org/jira/browse/MESOS-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schad reassigned MESOS-5757: -- Assignee: Joerg Schad > Authorize orphaned tasks > > > Key: MESOS-5757 > URL: https://issues.apache.org/jira/browse/MESOS-5757 > Project: Mesos > Issue Type: Bug > Components: security >Affects Versions: 1.0.0 >Reporter: Vinod Kone >Assignee: Joerg Schad > Labels: mesosphere, security > Fix For: 1.0.0 > > > Currently, orphaned tasks are not filtered (i.e., using authorization) when a > request is made to /state endpoint. This is inconsistent (and unexpected) > with how we filter un-orphaned tasks. > This is tricky because master and hence the authorizer do not have > FrameworkInfos for these orphaned tasks, until after the corresponding > frameworks re-register. > One option is for the agent to include FrameworkInfos of all its tasks and > executors in its re-registration message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
