[jira] [Created] (MESOS-3086) Create cgroups TasksKiller for non freeze subsystems.
Joerg Schad created MESOS-3086: -- Summary: Create cgroups TasksKiller for non freeze subsystems. Key: MESOS-3086 URL: https://issues.apache.org/jira/browse/MESOS-3086 Project: Mesos Issue Type: Bug Reporter: Joerg Schad Assignee: Joerg Schad We have a number of test issues when we cannot remove cgroups (in case there are still related tasks running). Therefore we need a TasksKiller which doesn't rely on the freezer subsystem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3086) Create cgroups TasksKiller for non freeze subsystems.
[ https://issues.apache.org/jira/browse/MESOS-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633171#comment-14633171 ] Joerg Schad commented on MESOS-3086: https://reviews.apache.org/r/36612/ Create cgroups TasksKiller for non freeze subsystems. - Key: MESOS-3086 URL: https://issues.apache.org/jira/browse/MESOS-3086 Project: Mesos Issue Type: Bug Reporter: Joerg Schad Assignee: Joerg Schad Labels: mesosphere We have a number of test issues when we cannot remove cgroups (in case there are still related tasks running). Therefore we need a TasksKiller which doesn't rely on the freezer subsystem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3087) Typos in oversubscription doc
Brian Candler created MESOS-3087: Summary: Typos in oversubscription doc Key: MESOS-3087 URL: https://issues.apache.org/jira/browse/MESOS-3087 Project: Mesos Issue Type: Documentation Components: documentation Affects Versions: 0.23.0 Reporter: Brian Candler Priority: Trivial * In docs/oversubscription.md: there are three cases where revocable is written as recovable, including the name of a JSON field. ~~~ $ grep -niR recovable . ./docs/oversubscription.md:51:with revocable resources. Further more, recovable resources cannot be ./docs/oversubscription.md:95:Launching tasks using recovable resources is done through the existing ./docs/oversubscription.md:96:`launchTasks` API. Revocable resources will have the `recovable` field set. See ~~~ * Also in `docs/oversubscription.md`: the last sentence doesn't make sense ~~~ To select custom a resource estimator and QoS controller, please refer to the [modules documentation](modules.md). ~~~ Maybe should say To select a custom... or To install a custom... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3087) Typos in oversubscription doc
[
https://issues.apache.org/jira/browse/MESOS-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Candler updated MESOS-3087:
-
Description:
* In docs/oversubscription.md: there are three cases where revocable is
written as recovable, including the name of a JSON field.
{noformat}
$ grep -niR recovable .
./docs/oversubscription.md:51:with revocable resources. Further more,
recovable resources cannot be
./docs/oversubscription.md:95:Launching tasks using recovable resources is done
through the existing
./docs/oversubscription.md:96:`launchTasks` API. Revocable resources will have
the `recovable` field set. See
{noformat}
* Also in `docs/oversubscription.md`: the last sentence doesn't make sense
{noformat}
To select custom a resource estimator and QoS controller, please refer to the
[modules documentation](modules.md).
{noformat}
Maybe should say To select a custom... or To install a custom...
was:
* In docs/oversubscription.md: there are three cases where revocable is
written as recovable, including the name of a JSON field.
~~~
$ grep -niR recovable .
./docs/oversubscription.md:51:with revocable resources. Further more,
recovable resources cannot be
./docs/oversubscription.md:95:Launching tasks using recovable resources is done
through the existing
./docs/oversubscription.md:96:`launchTasks` API. Revocable resources will have
the `recovable` field set. See
~~~
* Also in `docs/oversubscription.md`: the last sentence doesn't make sense
~~~
To select custom a resource estimator and QoS controller, please refer to the
[modules documentation](modules.md).
~~~
Maybe should say To select a custom... or To install a custom...
Typos in oversubscription doc
-
Key: MESOS-3087
URL: https://issues.apache.org/jira/browse/MESOS-3087
Project: Mesos
Issue Type: Documentation
Components: documentation
Affects Versions: 0.23.0
Reporter: Brian Candler
Priority: Trivial
* In docs/oversubscription.md: there are three cases where revocable is
written as recovable, including the name of a JSON field.
{noformat}
$ grep -niR recovable .
./docs/oversubscription.md:51:with revocable resources. Further more,
recovable resources cannot be
./docs/oversubscription.md:95:Launching tasks using recovable resources is
done through the existing
./docs/oversubscription.md:96:`launchTasks` API. Revocable resources will
have the `recovable` field set. See
{noformat}
* Also in `docs/oversubscription.md`: the last sentence doesn't make sense
{noformat}
To select custom a resource estimator and QoS controller, please refer to the
[modules documentation](modules.md).
{noformat}
Maybe should say To select a custom... or To install a custom...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3023) Factoring out the pattern for URL generation
[ https://issues.apache.org/jira/browse/MESOS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633582#comment-14633582 ] Bernd Mathiske commented on MESOS-3023: --- [~klaus1982] I can shepherd if you like. Factoring out the pattern for URL generation - Key: MESOS-3023 URL: https://issues.apache.org/jira/browse/MESOS-3023 Project: Mesos Issue Type: Task Reporter: Artem Harutyunyan Assignee: Klaus Ma Priority: Minor Labels: beginner, mesosphere, newbie fetcher_test.cpp uses the following code for generating URLs: string url = http://; + net::getHostname(process.self().address.ip).get() + : + stringify(process.self().address.port) + / + process.self().id it would be good to isolate that code in a function, and replace the code above with something like: string url = http://; + endpoint_url(process, uri_test); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3009) Reproduce systemd cgroup behavior
[ https://issues.apache.org/jira/browse/MESOS-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-3009: --- Sprint: Mesosphere Sprint 14 Reproduce systemd cgroup behavior -- Key: MESOS-3009 URL: https://issues.apache.org/jira/browse/MESOS-3009 Project: Mesos Issue Type: Task Reporter: Artem Harutyunyan Assignee: Joris Van Remoortere Labels: mesosphere It has been noticed before that systemd reorganizes cgroup hierarchy created by mesos slave. Because of this mesos is no longer able to find the cgroup, and there is also a chance of undoing the isolation that mesos slave puts in place. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-2708) Design doc for the Executor HTTP API
[ https://issues.apache.org/jira/browse/MESOS-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar reassigned MESOS-2708: - Assignee: Anand Mazumdar (was: Alexander Rojas) Design doc for the Executor HTTP API Key: MESOS-2708 URL: https://issues.apache.org/jira/browse/MESOS-2708 Project: Mesos Issue Type: Bug Reporter: Alexander Rojas Assignee: Anand Mazumdar Labels: mesosphere This tracks the design of the Executor HTTP API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3074) Validate and Persist Quota Request
[ https://issues.apache.org/jira/browse/MESOS-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-3074: --- Sprint: (was: Mesosphere Sprint 14) Validate and Persist Quota Request -- Key: MESOS-3074 URL: https://issues.apache.org/jira/browse/MESOS-3074 Project: Mesos Issue Type: Improvement Reporter: Joerg Schad Labels: mesosphere We need to to validate and persist quota request in the Mesos Master as outlined in the Design Doc: https://docs.google.com/document/d/16iRNmziasEjVOblYp5bbkeBZ7pnjNlaIzPQqMTHQ-9I -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3016) Add task status update hooks for Master/Slave
[ https://issues.apache.org/jira/browse/MESOS-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-3016: --- Sprint: (was: Mesosphere Sprint 14) Add task status update hooks for Master/Slave - Key: MESOS-3016 URL: https://issues.apache.org/jira/browse/MESOS-3016 Project: Mesos Issue Type: Task Reporter: Kapil Arya Assignee: Kapil Arya Labels: mesosphere The task termination hooks are needed for doing task-specific cleanup in Master/Slave. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2226) HookTest.VerifySlaveLaunchExecutorHook is flaky
[
https://issues.apache.org/jira/browse/MESOS-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-2226:
---
Sprint: Mesosphere Q1 Sprint 2 - 2/6, Mesosphere Q1 Sprint 3 - 2/20,
Mesosphere Q1 Sprint 4 - 3/6, Mesosphere Q1 Sprint 5 - 3/20, Mesosphere Q1
Sprint 6 - 4/3, Mesosphere Q1 Sprint 7 - 4/17, Mesosphere Q2 Sprint 8 - 5/1,
Mesosphere Q1 Sprint 9 - 5/15, Mesosphere Sprint 10, Mesosphere Sprint 11
(was: Mesosphere Q1 Sprint 2 - 2/6, Mesosphere Q1 Sprint 3 - 2/20, Mesosphere
Q1 Sprint 4 - 3/6, Mesosphere Q1 Sprint 5 - 3/20, Mesosphere Q1 Sprint 6 - 4/3,
Mesosphere Q1 Sprint 7 - 4/17, Mesosphere Q2 Sprint 8 - 5/1, Mesosphere Q1
Sprint 9 - 5/15, Mesosphere Sprint 10, Mesosphere Sprint 11, Mesosphere Sprint
14)
HookTest.VerifySlaveLaunchExecutorHook is flaky
---
Key: MESOS-2226
URL: https://issues.apache.org/jira/browse/MESOS-2226
Project: Mesos
Issue Type: Bug
Components: test
Affects Versions: 0.22.0
Reporter: Vinod Kone
Assignee: Kapil Arya
Labels: flaky, flaky-test, mesosphere
Observed this on internal CI
{code}
[ RUN ] HookTest.VerifySlaveLaunchExecutorHook
Using temporary directory '/tmp/HookTest_VerifySlaveLaunchExecutorHook_GjBgME'
I0114 18:51:34.659353 4720 leveldb.cpp:176] Opened db in 1.255951ms
I0114 18:51:34.662112 4720 leveldb.cpp:183] Compacted db in 596090ns
I0114 18:51:34.662364 4720 leveldb.cpp:198] Created db iterator in 177877ns
I0114 18:51:34.662719 4720 leveldb.cpp:204] Seeked to beginning of db in
19709ns
I0114 18:51:34.663010 4720 leveldb.cpp:273] Iterated through 0 keys in the
db in 18208ns
I0114 18:51:34.663312 4720 replica.cpp:744] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I0114 18:51:34.664266 4735 recover.cpp:449] Starting replica recovery
I0114 18:51:34.664908 4735 recover.cpp:475] Replica is in EMPTY status
I0114 18:51:34.667842 4734 replica.cpp:641] Replica in EMPTY status received
a broadcasted recover request
I0114 18:51:34.669117 4735 recover.cpp:195] Received a recover response from
a replica in EMPTY status
I0114 18:51:34.677913 4735 recover.cpp:566] Updating replica status to
STARTING
I0114 18:51:34.683157 4735 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 137939ns
I0114 18:51:34.683507 4735 replica.cpp:323] Persisted replica status to
STARTING
I0114 18:51:34.684013 4735 recover.cpp:475] Replica is in STARTING status
I0114 18:51:34.685554 4738 replica.cpp:641] Replica in STARTING status
received a broadcasted recover request
I0114 18:51:34.696512 4736 recover.cpp:195] Received a recover response from
a replica in STARTING status
I0114 18:51:34.700552 4735 recover.cpp:566] Updating replica status to VOTING
I0114 18:51:34.701128 4735 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 115624ns
I0114 18:51:34.701478 4735 replica.cpp:323] Persisted replica status to
VOTING
I0114 18:51:34.701817 4735 recover.cpp:580] Successfully joined the Paxos
group
I0114 18:51:34.702569 4735 recover.cpp:464] Recover process terminated
I0114 18:51:34.716439 4736 master.cpp:262] Master
20150114-185134-2272962752-57018-4720 (fedora-19) started on
192.168.122.135:57018
I0114 18:51:34.716913 4736 master.cpp:308] Master only allowing
authenticated frameworks to register
I0114 18:51:34.717136 4736 master.cpp:313] Master only allowing
authenticated slaves to register
I0114 18:51:34.717488 4736 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/HookTest_VerifySlaveLaunchExecutorHook_GjBgME/credentials'
I0114 18:51:34.718077 4736 master.cpp:357] Authorization enabled
I0114 18:51:34.719238 4738 whitelist_watcher.cpp:65] No whitelist given
I0114 18:51:34.719755 4737 hierarchical_allocator_process.hpp:285]
Initialized hierarchical allocator process
I0114 18:51:34.722584 4736 master.cpp:1219] The newly elected leader is
master@192.168.122.135:57018 with id 20150114-185134-2272962752-57018-4720
I0114 18:51:34.722865 4736 master.cpp:1232] Elected as the leading master!
I0114 18:51:34.723310 4736 master.cpp:1050] Recovering from registrar
I0114 18:51:34.723760 4734 registrar.cpp:313] Recovering registrar
I0114 18:51:34.725229 4740 log.cpp:660] Attempting to start the writer
I0114 18:51:34.727893 4739 replica.cpp:477] Replica received implicit
promise request with proposal 1
I0114 18:51:34.728425 4739 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 114781ns
I0114 18:51:34.728662 4739 replica.cpp:345] Persisted promised to 1
I0114 18:51:34.731271 4741 coordinator.cpp:230] Coordinator attemping to
fill missing position
I0114 18:51:34.733223 4734 replica.cpp:378] Replica received explicit
promise request for position 0 with
[jira] [Updated] (MESOS-3073) Introduce HTTP endpoints for Quota
[ https://issues.apache.org/jira/browse/MESOS-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-3073: --- Sprint: (was: Mesosphere Sprint 14) Introduce HTTP endpoints for Quota -- Key: MESOS-3073 URL: https://issues.apache.org/jira/browse/MESOS-3073 Project: Mesos Issue Type: Improvement Reporter: Joerg Schad Labels: mesosphere We need to implement the HTTP endpoints for Quota as outlined in the Design Doc (https://docs.google.com/document/d/16iRNmziasEjVOblYp5bbkeBZ7pnjNlaIzPQqMTHQ-9I). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2923) fetcher.cpp - problem with certificates..?
[
https://issues.apache.org/jira/browse/MESOS-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-2923:
---
Sprint: (was: Mesosphere Sprint 14)
fetcher.cpp - problem with certificates..?
--
Key: MESOS-2923
URL: https://issues.apache.org/jira/browse/MESOS-2923
Project: Mesos
Issue Type: Bug
Affects Versions: 0.22.0, 0.22.1
Environment: Ubuntu 14.04 (build + test)
Reporter: Tomasz Mieszkowski
Assignee: Bernd Mathiske
Labels: bugs, fetcher, https, mesosphere
Mesos 0.22.0/0.22.1 built and installed from sources accordingly to the
instructions given [here|http://mesos.apache.org/gettingstarted/] has some
problem with certificates.
Every time I try to deploy something that requires downloading any resource
via HTTPS (with URI specified via Marathon), such deployment fails and I get
this message in failed app's sandbox:
{code}
E0617 09:58:44.339409 12380 fetcher.cpp:138] Error downloading resource:
Problem with the SSL CA cert (path? access rights?)
{code}
Trying to download the same resource on the same slave with {{curl}} or
{{wget}} works without problems.
Moreover, when I install exactly the same version of Mesos from Mesosphere's
debs on identical machines (i.e., set up by the same Ansible scripts),
everything works fine as well.
I guess it must be something related to the way how Mesos is built - maybe
some missing switch for {{configure}} or {{make}}..?
Any ideas..?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2073) Fetcher cache file verification, updating and invalidation
[ https://issues.apache.org/jira/browse/MESOS-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2073: --- Sprint: Mesosphere Sprint 10, Mesosphere Sprint 11 (was: Mesosphere Sprint 10, Mesosphere Sprint 11, Mesosphere Sprint 14) Fetcher cache file verification, updating and invalidation -- Key: MESOS-2073 URL: https://issues.apache.org/jira/browse/MESOS-2073 Project: Mesos Issue Type: Improvement Components: fetcher, slave Reporter: Bernd Mathiske Assignee: Bernd Mathiske Priority: Minor Labels: mesosphere Original Estimate: 96h Remaining Estimate: 96h The other tickets in the fetcher cache epic do not necessitate a check sum (e.g. MD5, SHA*) for files cached by the fetcher. Whereas such a check sum could be used to verify whether the file arrived without unintended alterations, it can first and foremost be employed to detect and trigger updates. Scenario: If a UIR is requested for fetching and the indicated download has the same check sum as the cached file, then the cache file will be used and the download forgone. If the check sum is different, then fetching proceeds and the cached file gets replaced. This capability will be indicated by an additional field in the URI protobuf. Details TBD, i.e. to be discussed in comments below. In addition to the above, even if the check sum is the same, we can support voluntary cache file invalidation: a fresh download can be requested, or the caching behavior can be revoked entirely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2850) Implement Docker image provisioner
[ https://issues.apache.org/jira/browse/MESOS-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2850: --- Sprint: (was: Mesosphere Sprint 14) Implement Docker image provisioner -- Key: MESOS-2850 URL: https://issues.apache.org/jira/browse/MESOS-2850 Project: Mesos Issue Type: Improvement Components: containerization Reporter: Timothy Chen Assignee: Lily Chen Labels: mesosphere, unified-prototype Provisions a Docker image (provisions all its dependent layers), fetch an image from persistent store, and also destroy an image. Done when tested for local discovery and copy backend. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2708) Design doc for the Executor HTTP API
[ https://issues.apache.org/jira/browse/MESOS-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2708: --- Sprint: (was: Mesosphere Sprint 14) Design doc for the Executor HTTP API Key: MESOS-2708 URL: https://issues.apache.org/jira/browse/MESOS-2708 Project: Mesos Issue Type: Bug Reporter: Alexander Rojas Assignee: Anand Mazumdar Labels: mesosphere This tracks the design of the Executor HTTP API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2851) Add Docker Image Type to protobuf API
[ https://issues.apache.org/jira/browse/MESOS-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2851: --- Sprint: (was: Mesosphere Sprint 14) Add Docker Image Type to protobuf API - Key: MESOS-2851 URL: https://issues.apache.org/jira/browse/MESOS-2851 Project: Mesos Issue Type: Improvement Components: containerization Reporter: Timothy Chen Assignee: Lily Chen Labels: mesosphere, unified-prototype -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2968) Implement Shared Copy backend
[ https://issues.apache.org/jira/browse/MESOS-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2968: --- Sprint: (was: Mesosphere Sprint 14) Implement Shared Copy backend - Key: MESOS-2968 URL: https://issues.apache.org/jira/browse/MESOS-2968 Project: Mesos Issue Type: Improvement Components: containerization Reporter: Timothy Chen Assignee: Timothy Chen Labels: mesosphere Currently Appc and Docker both implemented its own copy backend, but most of the logic is the same where the input is just a image name with its dependencies. We can refactor both so that we just have one implementation that is shared between both provisioners, so appc and docker can reuse the shared copy backend. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3001) Create a demo HTTP API client
[ https://issues.apache.org/jira/browse/MESOS-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-3001: --- Sprint: (was: Mesosphere Sprint 14) Create a demo HTTP API client --- Key: MESOS-3001 URL: https://issues.apache.org/jira/browse/MESOS-3001 Project: Mesos Issue Type: Bug Components: framework Reporter: Marco Massenzio Assignee: Marco Massenzio Labels: mesosphere We want to create a simple demo HTTP API Client (in Java or Python) that can serve as an example framework for people who will want to use the new API for their Frameworks. The scope should be fairly limited (eg, launching a simple Container task?) but sufficient to exercise most of the new API endpoint messages/capabilities. Scope: TBD Non-Goals: - create a best-of-breed Framework to deliver any specific functionality; - create an Integration Test for the HTTP API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3007) Support systemd with Mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Harutyunyan updated MESOS-3007: - Assignee: Joris Van Remoortere Support systemd with Mesos containerizer Key: MESOS-3007 URL: https://issues.apache.org/jira/browse/MESOS-3007 Project: Mesos Issue Type: Epic Reporter: Artem Harutyunyan Assignee: Joris Van Remoortere Fix For: 0.24.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3009) Reproduce systemd cgroup behavior
[ https://issues.apache.org/jira/browse/MESOS-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-3009: --- Sprint: (was: Mesosphere Sprint 14) Reproduce systemd cgroup behavior -- Key: MESOS-3009 URL: https://issues.apache.org/jira/browse/MESOS-3009 Project: Mesos Issue Type: Task Reporter: Artem Harutyunyan Assignee: Joris Van Remoortere Labels: mesosphere It has been noticed before that systemd reorganizes cgroup hierarchy created by mesos slave. Because of this mesos is no longer able to find the cgroup, and there is also a chance of undoing the isolation that mesos slave puts in place. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2504) Upgrade protobuf to 2.6.1
[ https://issues.apache.org/jira/browse/MESOS-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-2504: -- Summary: Upgrade protobuf to 2.6.1 (was: Upgrade protobuf to 2.6.0 ) Upgrade protobuf to 2.6.1 -- Key: MESOS-2504 URL: https://issues.apache.org/jira/browse/MESOS-2504 Project: Mesos Issue Type: Improvement Reporter: Vinod Kone The main feature I'm interested in exploiting is the oneof feature which would allow us to reduce a bunch of boilerplate validation code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2075) Add maintenance information to the replicated registry.
[ https://issues.apache.org/jira/browse/MESOS-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Wu updated MESOS-2075: - Description: To achieve fault-tolerance for the maintenance primitives, we will need to add the maintenance information to the registry. The registry currently stores all of the slave information, which is quite large (~ 17MB for 50,000 slaves from my testing), which results in a protobuf object that is extremely expensive to copy. As far as I can tell, reads / writes to maintenance information is independent of reads / writes to the existing 'registry' information. So there are two approach here: h4. Add maintenance information to 'maintenance' key: (This is the chosen method.) # The advantage of this approach is that we don't further grow the large Registry object. # This approach assumes that writes to 'maintenance' are independent of writes to the 'registry'. -If these writes are not independent, this approach requires that we add transactional support to the State abstraction.- # -This approach requires adding compaction to LogStorage.- # This approach likely requires some refactoring to the Registrar. h4. Add maintenance information to 'registry' key: # The advantage of this approach is that it's the easiest to implement. # This will further grow the single 'registry' object, but doesn't preclude it being split apart in the future. # This approach may require using the diff support in LogStorage and/or adding compression support to LogStorage snapshots to deal with the increased size of the registry. was: To achieve fault-tolerance for the maintenance primitives, we will need to add the maintenance information to the registry. The registry currently stores all of the slave information, which is quite large (~ 17MB for 50,000 slaves from my testing), which results in a protobuf object that is extremely expensive to copy. As far as I can tell, reads / writes to maintenance information is independent of reads / writes to the existing 'registry' information. So there are two approach here: h4. Add maintenance information to 'maintenance' key: (This is the chosen method.) # The advantage of this approach is that we don't further grow the large Registry object. # This approach assumes that writes to 'maintenance' are independent of writes to the 'registry'. If these writes are not independent, this approach requires that we add transactional support to the State abstraction. # This approach requires adding compaction to LogStorage. # This approach likely requires some refactoring to the Registrar. h4. Add maintenance information to 'registry' key: # The advantage of this approach is that it's the easiest to implement. # This will further grow the single 'registry' object, but doesn't preclude it being split apart in the future. # This approach may require using the diff support in LogStorage and/or adding compression support to LogStorage snapshots to deal with the increased size of the registry. Add maintenance information to the replicated registry. --- Key: MESOS-2075 URL: https://issues.apache.org/jira/browse/MESOS-2075 Project: Mesos Issue Type: Task Components: master Reporter: Benjamin Mahler Assignee: Joseph Wu Labels: mesosphere, twitter To achieve fault-tolerance for the maintenance primitives, we will need to add the maintenance information to the registry. The registry currently stores all of the slave information, which is quite large (~ 17MB for 50,000 slaves from my testing), which results in a protobuf object that is extremely expensive to copy. As far as I can tell, reads / writes to maintenance information is independent of reads / writes to the existing 'registry' information. So there are two approach here: h4. Add maintenance information to 'maintenance' key: (This is the chosen method.) # The advantage of this approach is that we don't further grow the large Registry object. # This approach assumes that writes to 'maintenance' are independent of writes to the 'registry'. -If these writes are not independent, this approach requires that we add transactional support to the State abstraction.- # -This approach requires adding compaction to LogStorage.- # This approach likely requires some refactoring to the Registrar. h4. Add maintenance information to 'registry' key: # The advantage of this approach is that it's the easiest to implement. # This will further grow the single 'registry' object, but doesn't preclude it being split apart in the future. # This approach may require using the diff support in LogStorage and/or adding compression support to LogStorage snapshots to deal with the increased size of the registry. -- This message was sent by Atlassian JIRA
[jira] [Updated] (MESOS-2075) Add maintenance information to the replicated registry.
[ https://issues.apache.org/jira/browse/MESOS-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Wu updated MESOS-2075: - Description: To achieve fault-tolerance for the maintenance primitives, we will need to add the maintenance information to the registry. The registry currently stores all of the slave information, which is quite large (~ 17MB for 50,000 slaves from my testing), which results in a protobuf object that is extremely expensive to copy. As far as I can tell, reads / writes to maintenance information is independent of reads / writes to the existing 'registry' information. So there are two approach here: h4. Add maintenance information to 'maintenance' key: (This is the chosen method.) # The advantage of this approach is that we don't further grow the large Registry object. # This approach assumes that writes to 'maintenance' are independent of writes to the 'registry'. If these writes are not independent, this approach requires that we add transactional support to the State abstraction. # This approach requires adding compaction to LogStorage. # This approach likely requires some refactoring to the Registrar. h4. Add maintenance information to 'registry' key: # The advantage of this approach is that it's the easiest to implement. # This will further grow the single 'registry' object, but doesn't preclude it being split apart in the future. # This approach may require using the diff support in LogStorage and/or adding compression support to LogStorage snapshots to deal with the increased size of the registry. was: To achieve fault-tolerance for the maintenance primitives, we will need to add the maintenance information to the registry. The registry currently stores all of the slave information, which is quite large (~ 17MB for 50,000 slaves from my testing), which results in a protobuf object that is extremely expensive to copy. As far as I can tell, reads / writes to maintenance information is independent of reads / writes to the existing 'registry' information. So there are two approach here: h4. Add maintenance information to 'maintenance' key: # The advantage of this approach is that we don't further grow the large Registry object. # This approach assumes that writes to 'maintenance' are independent of writes to the 'registry'. If these writes are not independent, this approach requires that we add transactional support to the State abstraction. # This approach requires adding compaction to LogStorage. # This approach likely requires some refactoring to the Registrar. h4. Add maintenance information to 'registry' key: # The advantage of this approach is that it's the easiest to implement. # This will further grow the single 'registry' object, but doesn't preclude it being split apart in the future. # This approach may require using the diff support in LogStorage and/or adding compression support to LogStorage snapshots to deal with the increased size of the registry. Add maintenance information to the replicated registry. --- Key: MESOS-2075 URL: https://issues.apache.org/jira/browse/MESOS-2075 Project: Mesos Issue Type: Task Components: master Reporter: Benjamin Mahler Assignee: Joseph Wu Labels: mesosphere, twitter To achieve fault-tolerance for the maintenance primitives, we will need to add the maintenance information to the registry. The registry currently stores all of the slave information, which is quite large (~ 17MB for 50,000 slaves from my testing), which results in a protobuf object that is extremely expensive to copy. As far as I can tell, reads / writes to maintenance information is independent of reads / writes to the existing 'registry' information. So there are two approach here: h4. Add maintenance information to 'maintenance' key: (This is the chosen method.) # The advantage of this approach is that we don't further grow the large Registry object. # This approach assumes that writes to 'maintenance' are independent of writes to the 'registry'. If these writes are not independent, this approach requires that we add transactional support to the State abstraction. # This approach requires adding compaction to LogStorage. # This approach likely requires some refactoring to the Registrar. h4. Add maintenance information to 'registry' key: # The advantage of this approach is that it's the easiest to implement. # This will further grow the single 'registry' object, but doesn't preclude it being split apart in the future. # This approach may require using the diff support in LogStorage and/or adding compression support to LogStorage snapshots to deal with the increased size of the registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2708) Design doc for the Executor HTTP API
[ https://issues.apache.org/jira/browse/MESOS-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633869#comment-14633869 ] Anand Mazumdar commented on MESOS-2708: --- My bad, I had missed this comment completely. I would take this up when we start to focus on the JIRA items for Executor HTTP API again. Design doc for the Executor HTTP API Key: MESOS-2708 URL: https://issues.apache.org/jira/browse/MESOS-2708 Project: Mesos Issue Type: Bug Reporter: Alexander Rojas Assignee: Alexander Rojas Labels: mesosphere This tracks the design of the Executor HTTP API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3023) Factoring out the pattern for URL generation
[ https://issues.apache.org/jira/browse/MESOS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633705#comment-14633705 ] Klaus Ma commented on MESOS-3023: - Hi [~bernd-mesos], That'll be great if you can help me on this. For now, I've updated the code in https://reviews.apache.org/r/36501/; but because of MESOS-2862, our code should be modified accordingly. Anyway, do you have suggestion to use URL to build testing url. If any comments, please let me know. Thanks Klaus Factoring out the pattern for URL generation - Key: MESOS-3023 URL: https://issues.apache.org/jira/browse/MESOS-3023 Project: Mesos Issue Type: Task Reporter: Artem Harutyunyan Assignee: Klaus Ma Priority: Minor Labels: beginner, mesosphere, newbie fetcher_test.cpp uses the following code for generating URLs: string url = http://; + net::getHostname(process.self().address.ip).get() + : + stringify(process.self().address.port) + / + process.self().id it would be good to isolate that code in a function, and replace the code above with something like: string url = http://; + endpoint_url(process, uri_test); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2294) Implement the Events stream on master for Call endpoint
[ https://issues.apache.org/jira/browse/MESOS-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634057#comment-14634057 ] Anand Mazumdar commented on MESOS-2294: --- The part in review is a very small part of the JIRA i.e. just handles subscribe-subscribed calls. Would send in more patches for other events once we agree on the design/code semantics of the review I sent out. Implement the Events stream on master for Call endpoint --- Key: MESOS-2294 URL: https://issues.apache.org/jira/browse/MESOS-2294 Project: Mesos Issue Type: Task Reporter: Vinod Kone Assignee: Anand Mazumdar Labels: mesosphere -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2552) C++ Scheduler library should send HTTP Calls to master
[
https://issues.apache.org/jira/browse/MESOS-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634055#comment-14634055
]
Marco Massenzio commented on MESOS-2552:
Again, should this be in {{Reviewable}}? can you please update on progress?
C++ Scheduler library should send HTTP Calls to master
--
Key: MESOS-2552
URL: https://issues.apache.org/jira/browse/MESOS-2552
Project: Mesos
Issue Type: Bug
Reporter: Vinod Kone
Assignee: Anand Mazumdar
Labels: mesosphere
Once the scheduler library sends Call messages, we should update it to send
Calls as HTTP requests to /call endpoint on master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2719) Removing '.json' extension in master endpoints url
[ https://issues.apache.org/jira/browse/MESOS-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634078#comment-14634078 ] Isabel Jimenez commented on MESOS-2719: --- [~marco-mesos] yes, this simply adds the endpoints without the .json extension and starts a deprecation cycle. Updating description and title Removing '.json' extension in master endpoints url -- Key: MESOS-2719 URL: https://issues.apache.org/jira/browse/MESOS-2719 Project: Mesos Issue Type: Improvement Reporter: Isabel Jimenez Assignee: Isabel Jimenez Labels: HTTP, mesosphere Remove the '.json' extension on endpoints such as `/master/stats.json` so it become `/master/stats` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-2132) Allow sending http::Request objects
[ https://issues.apache.org/jira/browse/MESOS-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio reassigned MESOS-2132: -- Assignee: (was: Cody Maloney) Allow sending http::Request objects --- Key: MESOS-2132 URL: https://issues.apache.org/jira/browse/MESOS-2132 Project: Mesos Issue Type: Improvement Components: libprocess Reporter: Cody Maloney Priority: Minor Labels: mesosphere Currently you can only send a collection of fields which more or less matches those in an http::Request object. http::Request objects are used when calling http handlers in libprocess. The motivation for being able to send these is then we can forward a request that is recieved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1113) Refactor cgroup interface in preparation for Systemd NWO.
[ https://issues.apache.org/jira/browse/MESOS-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634082#comment-14634082 ] Marco Massenzio commented on MESOS-1113: Hey [~tstclair], are you still working on this? or should we assign to someone else? thanks! Refactor cgroup interface in preparation for Systemd NWO. - Key: MESOS-1113 URL: https://issues.apache.org/jira/browse/MESOS-1113 Project: Mesos Issue Type: Bug Components: containerization Affects Versions: 0.19.0 Reporter: Timothy St. Clair Assignee: Timothy St. Clair Labels: cgroups, mesosphere In coming releases cgroups will no longer have it's own interface, all interactions will go through systemd's DBUS interface: http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ This ticket is to track and allow the refactoring and migration that will be required in order to support. - Original Message - From: Lennart Poettering mzerq...@0pointer.de To: Development discussions related to Fedora de...@lists.fedoraproject.org Cc: Fedora Big Data SIG bigd...@lists.fedoraproject.org Sent: Monday, March 17, 2014 8:18:37 PM Subject: Re: Systemd cgroups NWO Well, the nebulous choice of words is intended, since we don't want to make specific promises on time-frames... The APIs described (tersely) at the end of the wiki page describe the status quo with systemd 211. The single-writer cgroup tree stuff Tejun has been working on for the kernel is now working on his machine, but it's not pushed upstream and will take a while before it will hit Fedora. At this point in time you hence still may create cgroups directly yourself (but only if you follow the pax cgroup document), however, we strongly encourage you to instead use scopes/slices to create them, as discussed on the wiki page. This way the cgroups transition will be abstracted away from you. You have control of a number of knobs that systemd will expose for you, such as CPUShares=, BlockIOWeight= and so on, but this is not complete, and primarily so because it's not clear that those other properties will continue to exist the way they are in the kernel. To read statistics data or to write knobs that systemd doesn't cover you need to go directly to the cgroupfs. For that, simply read /proc/self/cgroup to find out your own cgroup, and then operate on that. However, as during the single-writer cgroup transition the kernel interface how we set things up will change, be prepared that things might break... Lennart -- Lennart Poettering, Red Hat -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2963) Configure Jenkins to build ssl
[ https://issues.apache.org/jira/browse/MESOS-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Van Remoortere updated MESOS-2963: Labels: jenkins mesosphere ssl (was: jenkins ssl) Configure Jenkins to build ssl -- Key: MESOS-2963 URL: https://issues.apache.org/jira/browse/MESOS-2963 Project: Mesos Issue Type: Improvement Reporter: Joris Van Remoortere Assignee: Joris Van Remoortere Labels: jenkins, mesosphere, ssl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2153) Add support for systemd journal for logging
[ https://issues.apache.org/jira/browse/MESOS-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2153: --- Labels: mesosphere (was: ) Add support for systemd journal for logging --- Key: MESOS-2153 URL: https://issues.apache.org/jira/browse/MESOS-2153 Project: Mesos Issue Type: Improvement Components: master, slave Reporter: Alexander Rukletsov Priority: Minor Labels: mesosphere We should be able to redirect master and slave logs to systemd journal on the systems where it's available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-2902) Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME
[ https://issues.apache.org/jira/browse/MESOS-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2902: --- Comment: was deleted (was: Moving this functionality out to a separate module.) Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME Key: MESOS-2902 URL: https://issues.apache.org/jira/browse/MESOS-2902 Project: Mesos Issue Type: Improvement Components: master, modules, slave Reporter: Cody Maloney Assignee: Marco Massenzio Priority: Critical Labels: mesosphere Currently Mesos tries to guess the IP, HOSTNAME by doing a reverse DNS lookup. This doesn't work on a lot of clouds as we want things like public IPs (which aren't the default DNS), there aren't FQDN names (Azure), or the correct way to figure it out is to call some cloud-specific endpoint. If Mesos / Libprocess could load a mesos-module (Or run a script) which is provided per-cloud, we can figure out perfectly the IP / Hostname for the given environment. It also means we can ship one identical set of files to all hosts in a given provider which doesn't happen to have the DNS scheme + hostnames that libprocess/Mesos expects. Currently we have to generate host-specific config files which Mesos uses to guess. The host-specific files break / fall apart if machines change IP / hostname without being reinstalled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3092) Configure Jenkins to run Docker tests
[ https://issues.apache.org/jira/browse/MESOS-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Chen updated MESOS-3092: Labels: mesosphere (was: ) Configure Jenkins to run Docker tests - Key: MESOS-3092 URL: https://issues.apache.org/jira/browse/MESOS-3092 Project: Mesos Issue Type: Improvement Components: docker Reporter: Timothy Chen Assignee: Timothy Chen Labels: mesosphere -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3092) Configure Jenkins to run Docker tests
[ https://issues.apache.org/jira/browse/MESOS-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Chen updated MESOS-3092: Description: Add a jenkin job to run the Docker tests Configure Jenkins to run Docker tests - Key: MESOS-3092 URL: https://issues.apache.org/jira/browse/MESOS-3092 Project: Mesos Issue Type: Improvement Components: docker Reporter: Timothy Chen Assignee: Timothy Chen Labels: mesosphere Add a jenkin job to run the Docker tests -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3067) Implement a streaming response decoder for events stream
[
https://issues.apache.org/jira/browse/MESOS-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-3067:
---
Story Points: 5
Implement a streaming response decoder for events stream
Key: MESOS-3067
URL: https://issues.apache.org/jira/browse/MESOS-3067
Project: Mesos
Issue Type: Task
Reporter: Anand Mazumdar
Assignee: Benjamin Mahler
We need a streaming response decoder to de-serialize chunks sent from the
master on the events stream.
From the HTTP API design doc:
Master encodes each Event in RecordIO format, i.e. a string representation of
length of the event in bytes followed by JSON or binary Protobuf (possibly
compressed) encoded event.
As of now for getting the basic features right , this is being done in the
test-cases:
{code}
auto reader = response.get().reader;
ASSERT_SOME(reader);
Futurestd::string eventFuture = reader.get().read();
AWAIT_READY(eventFuture);
Event event;
event.ParseFromString(eventFuture.get());
{code}
Two things need to happen:
- We need master to emit events in RecordIO format i.e. event size followed
by the serialized event instead of just the serialized events as is the case
now.
- The decoder class should then abstract away the logic of reading the
response and de-serializing events from the stream.
Ideally, the decoder should work with both json and protobuf responses.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3090) Calculated CPU should be rounded
[
https://issues.apache.org/jira/browse/MESOS-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634155#comment-14634155
]
Benjamin Mahler commented on MESOS-3090:
Where did the 3.9973 come from, an endpoint? Which version of mesos
are you running?
Can you post the very beginning of the slave log? (I'm looking for where we
log the slave resources at start-up).
Calculated CPU should be rounded
Key: MESOS-3090
URL: https://issues.apache.org/jira/browse/MESOS-3090
Project: Mesos
Issue Type: Bug
Reporter: Andrew Jorgensen
My mesos worker pool consists of 4 core machines in AWS. When I look at the
calculated amount of CPU that each machine is offering it looks like
{quote}
name:cpus,
scalar:3.9973
{quote}
It feels like this number should be rounded up to the nearest thousands so
that a job does not need to specify 3.9 CPU but can just specify the full 4.
This can be remedied by adding the following to the worker machines:
{quote}
--resources='cpus:4'
{quote}
But this would be hard to manage if the worker pool is at all heterogenous.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2719) Removing '.json' extension in master endpoints url
[
https://issues.apache.org/jira/browse/MESOS-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634060#comment-14634060
]
Marco Massenzio commented on MESOS-2719:
Is this still required?
as you can't simply remove the endpoint (will need a compatibility release
cycle).
Should this simply *add* the endpoints (without the {{.json}} extension)?
Please provide us an update?
Removing '.json' extension in master endpoints url
--
Key: MESOS-2719
URL: https://issues.apache.org/jira/browse/MESOS-2719
Project: Mesos
Issue Type: Improvement
Reporter: Isabel Jimenez
Assignee: Isabel Jimenez
Labels: HTTP, mesosphere
Remove the '.json' extension on endpoints such as `/master/stats.json` so it
become `/master/stats`
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3090) Calculated CPU should be rounded
Andrew Jorgensen created MESOS-3090:
---
Summary: Calculated CPU should be rounded
Key: MESOS-3090
URL: https://issues.apache.org/jira/browse/MESOS-3090
Project: Mesos
Issue Type: Bug
Reporter: Andrew Jorgensen
My mesos worker pool consists of 4 core machines in AWS. When I look at the
calculated amount of CPU that each machine is offering it looks like
{quote}
resources:[
{
name:cpus,
scalar:3.9973
},
{quote}
It feels like this number should be rounded up to the nearest thousands so that
a job does not need to specify 3.9 CPU but can just specify the full 4.
This can be remedied by adding the following to the worker machines:
{quote}
--resources='cpus:4'
{quote}
But this would be hard to manage if the worker pool is at all heterogenous.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3090) Calculated CPU should be rounded
[
https://issues.apache.org/jira/browse/MESOS-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Jorgensen updated MESOS-3090:
Description:
My mesos worker pool consists of 4 core machines in AWS. When I look at the
calculated amount of CPU that each machine is offering it looks like
{quote}
name:cpus,
scalar:3.9973
{quote}
It feels like this number should be rounded up to the nearest thousands so that
a job does not need to specify 3.9 CPU but can just specify the full 4.
This can be remedied by adding the following to the worker machines:
{quote}
--resources='cpus:4'
{quote}
But this would be hard to manage if the worker pool is at all heterogenous.
was:
My mesos worker pool consists of 4 core machines in AWS. When I look at the
calculated amount of CPU that each machine is offering it looks like
{quote}
resources:[
{
name:cpus,
scalar:3.9973
},
{quote}
It feels like this number should be rounded up to the nearest thousands so that
a job does not need to specify 3.9 CPU but can just specify the full 4.
This can be remedied by adding the following to the worker machines:
{quote}
--resources='cpus:4'
{quote}
But this would be hard to manage if the worker pool is at all heterogenous.
Calculated CPU should be rounded
Key: MESOS-3090
URL: https://issues.apache.org/jira/browse/MESOS-3090
Project: Mesos
Issue Type: Bug
Reporter: Andrew Jorgensen
My mesos worker pool consists of 4 core machines in AWS. When I look at the
calculated amount of CPU that each machine is offering it looks like
{quote}
name:cpus,
scalar:3.9973
{quote}
It feels like this number should be rounded up to the nearest thousands so
that a job does not need to specify 3.9 CPU but can just specify the full 4.
This can be remedied by adding the following to the worker machines:
{quote}
--resources='cpus:4'
{quote}
But this would be hard to manage if the worker pool is at all heterogenous.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2552) C++ Scheduler library should send HTTP Calls to master
[ https://issues.apache.org/jira/browse/MESOS-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634061#comment-14634061 ] Anand Mazumdar commented on MESOS-2552: --- I am pausing the progress on this one. It would be a better idea to resume work on this one once the master can understand calls/send events on the event stream. C++ Scheduler library should send HTTP Calls to master -- Key: MESOS-2552 URL: https://issues.apache.org/jira/browse/MESOS-2552 Project: Mesos Issue Type: Bug Reporter: Vinod Kone Assignee: Anand Mazumdar Labels: mesosphere Once the scheduler library sends Call messages, we should update it to send Calls as HTTP requests to /call endpoint on master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3077) Registry recovery does not recover the maintenance object.
[
https://issues.apache.org/jira/browse/MESOS-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Wu updated MESOS-3077:
-
Description:
Persisted info is fetched from the registry when a master is elected or after
failover. Currently, this process involves 3 steps:
* Fetch the registry.
* Start an operation to add the new master to the fetched registry.
* Check the success of the operation and finish recovering.
These methods can be found in src/master/registrar.cpp
{code}RegistrarProcess::recover, ::_recover, ::__recover{code}
Since the maintenance schedule is stored in a separate key, the recover process
must also fetch a new maintenance object. This object needs to be passed
along to the master along with the existing registry object.
Possible test(s):
* src/tests/registrar_tests.cpp
** Change the Recovery test to include checks for the new object.
was:
Persisted info is fetched from the registry when a master is elected or after
failover. Currently, this process involves 3 steps:
* Fetch the registry.
* Start an operation to add the new master to the fetched registry.
* Check the success of the operation and finish recovering.
These methods can be found in src/master/registrar.cpp
{code}RegistrarProcess::recover, ::_recover, ::__recover{code}.
Since the maintenance schedule is stored in a separate key, the recover process
must also fetch a new maintenance object. This object needs to be passed
along to the master along with the existing registry object.
Possible test(s):
* src/tests/registrar_tests.cpp
** Change the Recovery test to include checks for the new object.
Registry recovery does not recover the maintenance object.
--
Key: MESOS-3077
URL: https://issues.apache.org/jira/browse/MESOS-3077
Project: Mesos
Issue Type: Task
Components: master, replicated log
Reporter: Joseph Wu
Assignee: Joseph Wu
Persisted info is fetched from the registry when a master is elected or after
failover. Currently, this process involves 3 steps:
* Fetch the registry.
* Start an operation to add the new master to the fetched registry.
* Check the success of the operation and finish recovering.
These methods can be found in src/master/registrar.cpp
{code}RegistrarProcess::recover, ::_recover, ::__recover{code}
Since the maintenance schedule is stored in a separate key, the recover
process must also fetch a new maintenance object. This object needs to be
passed along to the master along with the existing registry object.
Possible test(s):
* src/tests/registrar_tests.cpp
** Change the Recovery test to include checks for the new object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2132) Allow sending http::Request objects
[ https://issues.apache.org/jira/browse/MESOS-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2132: --- Sprint: Mesosphere Q4 Sprint 3 - 12/7, Mesosphere Sprint 15 (was: Mesosphere Q4 Sprint 3 - 12/7) Allow sending http::Request objects --- Key: MESOS-2132 URL: https://issues.apache.org/jira/browse/MESOS-2132 Project: Mesos Issue Type: Improvement Components: libprocess Reporter: Cody Maloney Assignee: Cody Maloney Priority: Minor Labels: mesosphere Currently you can only send a collection of fields which more or less matches those in an http::Request object. http::Request objects are used when calling http handlers in libprocess. The motivation for being able to send these is then we can forward a request that is recieved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1992) Support launching executors with configured systemd
[ https://issues.apache.org/jira/browse/MESOS-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-1992: --- Sprint: Mesosphere Sprint 15 Target Version/s: 0.24.0 Support launching executors with configured systemd Key: MESOS-1992 URL: https://issues.apache.org/jira/browse/MESOS-1992 Project: Mesos Issue Type: Improvement Components: slave Reporter: Timothy Chen Labels: mesosphere Currently running mesos-slave in docker with systemd, the mesos-slave container cannot be upgraded while keeping all the tasks running since killing the docker container will kill all the processes that is launched with the mesos containerizer. If we can let the executor to be launched with systemd outside of the docker container, then we can let the tasks remain running and recover them when the slave is upgraded. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2984) Deprecating '.json' extension in files endpoints url
[ https://issues.apache.org/jira/browse/MESOS-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabel Jimenez updated MESOS-2984: -- Summary: Deprecating '.json' extension in files endpoints url (was: Removing '.json' extension in files endpoints url) Deprecating '.json' extension in files endpoints url Key: MESOS-2984 URL: https://issues.apache.org/jira/browse/MESOS-2984 Project: Mesos Issue Type: Improvement Reporter: Isabel Jimenez Assignee: Isabel Jimenez Labels: HTTP, mesosphere Remove the '.json' extension on endpoints such as `/files/browse.json` so it become `/files/browse` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2983) Deprecating '.json' extension in slave endpoints url
[ https://issues.apache.org/jira/browse/MESOS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabel Jimenez updated MESOS-2983: -- Summary: Deprecating '.json' extension in slave endpoints url (was: Removing '.json' extension in slave endpoints url) Deprecating '.json' extension in slave endpoints url Key: MESOS-2983 URL: https://issues.apache.org/jira/browse/MESOS-2983 Project: Mesos Issue Type: Improvement Reporter: Isabel Jimenez Assignee: Isabel Jimenez Labels: HTTP, mesosphere Remove the '.json' extension on endpoints such as `/slave/state.json` so it become `/slave/state` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1992) Support launching executors with configured systemd
[ https://issues.apache.org/jira/browse/MESOS-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-1992: --- Shepherd: Bernd Mathiske Support launching executors with configured systemd Key: MESOS-1992 URL: https://issues.apache.org/jira/browse/MESOS-1992 Project: Mesos Issue Type: Improvement Components: slave Reporter: Timothy Chen Labels: mesosphere Currently running mesos-slave in docker with systemd, the mesos-slave container cannot be upgraded while keeping all the tasks running since killing the docker container will kill all the processes that is launched with the mesos containerizer. If we can let the executor to be launched with systemd outside of the docker container, then we can let the tasks remain running and recover them when the slave is upgraded. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1113) Refactor cgroup interface in preparation for Systemd NWO.
[ https://issues.apache.org/jira/browse/MESOS-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-1113: --- Sprint: Mesosphere Sprint 15 Target Version/s: 0.24.0 Refactor cgroup interface in preparation for Systemd NWO. - Key: MESOS-1113 URL: https://issues.apache.org/jira/browse/MESOS-1113 Project: Mesos Issue Type: Bug Components: containerization Affects Versions: 0.19.0 Reporter: Timothy St. Clair Assignee: Timothy St. Clair Labels: cgroups, mesosphere In coming releases cgroups will no longer have it's own interface, all interactions will go through systemd's DBUS interface: http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ This ticket is to track and allow the refactoring and migration that will be required in order to support. - Original Message - From: Lennart Poettering mzerq...@0pointer.de To: Development discussions related to Fedora de...@lists.fedoraproject.org Cc: Fedora Big Data SIG bigd...@lists.fedoraproject.org Sent: Monday, March 17, 2014 8:18:37 PM Subject: Re: Systemd cgroups NWO Well, the nebulous choice of words is intended, since we don't want to make specific promises on time-frames... The APIs described (tersely) at the end of the wiki page describe the status quo with systemd 211. The single-writer cgroup tree stuff Tejun has been working on for the kernel is now working on his machine, but it's not pushed upstream and will take a while before it will hit Fedora. At this point in time you hence still may create cgroups directly yourself (but only if you follow the pax cgroup document), however, we strongly encourage you to instead use scopes/slices to create them, as discussed on the wiki page. This way the cgroups transition will be abstracted away from you. You have control of a number of knobs that systemd will expose for you, such as CPUShares=, BlockIOWeight= and so on, but this is not complete, and primarily so because it's not clear that those other properties will continue to exist the way they are in the kernel. To read statistics data or to write knobs that systemd doesn't cover you need to go directly to the cgroupfs. For that, simply read /proc/self/cgroup to find out your own cgroup, and then operate on that. However, as during the single-writer cgroup transition the kernel interface how we set things up will change, be prepared that things might break... Lennart -- Lennart Poettering, Red Hat -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2153) Add support for systemd journal for logging
[ https://issues.apache.org/jira/browse/MESOS-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2153: --- Sprint: Mesosphere Sprint 15 Target Version/s: 0.24.0 Add support for systemd journal for logging --- Key: MESOS-2153 URL: https://issues.apache.org/jira/browse/MESOS-2153 Project: Mesos Issue Type: Improvement Components: master, slave Reporter: Alexander Rukletsov Priority: Minor Labels: mesosphere We should be able to redirect master and slave logs to systemd journal on the systems where it's available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3092) Configure Jenkins to run Docker tests
Timothy Chen created MESOS-3092: --- Summary: Configure Jenkins to run Docker tests Key: MESOS-3092 URL: https://issues.apache.org/jira/browse/MESOS-3092 Project: Mesos Issue Type: Improvement Components: docker Reporter: Timothy Chen Assignee: Timothy Chen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-2902) Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME
[ https://issues.apache.org/jira/browse/MESOS-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2902: --- Comment: was deleted (was: We will probably move this functionality to a separate module - thanks everyone for your feedback!) Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME Key: MESOS-2902 URL: https://issues.apache.org/jira/browse/MESOS-2902 Project: Mesos Issue Type: Improvement Components: master, modules, slave Reporter: Cody Maloney Assignee: Marco Massenzio Priority: Critical Labels: mesosphere Currently Mesos tries to guess the IP, HOSTNAME by doing a reverse DNS lookup. This doesn't work on a lot of clouds as we want things like public IPs (which aren't the default DNS), there aren't FQDN names (Azure), or the correct way to figure it out is to call some cloud-specific endpoint. If Mesos / Libprocess could load a mesos-module (Or run a script) which is provided per-cloud, we can figure out perfectly the IP / Hostname for the given environment. It also means we can ship one identical set of files to all hosts in a given provider which doesn't happen to have the DNS scheme + hostnames that libprocess/Mesos expects. Currently we have to generate host-specific config files which Mesos uses to guess. The host-specific files break / fall apart if machines change IP / hostname without being reinstalled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2983) Removing '.json' extension in slave endpoints url
[ https://issues.apache.org/jira/browse/MESOS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2983: --- Sprint: (was: Mesosphere Sprint 15) Removing '.json' extension in slave endpoints url - Key: MESOS-2983 URL: https://issues.apache.org/jira/browse/MESOS-2983 Project: Mesos Issue Type: Improvement Reporter: Isabel Jimenez Assignee: Isabel Jimenez Labels: HTTP, mesosphere Remove the '.json' extension on endpoints such as `/slave/state.json` so it become `/slave/state` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2984) Removing '.json' extension in files endpoints url
[ https://issues.apache.org/jira/browse/MESOS-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2984: --- Sprint: (was: Mesosphere Sprint 15) Removing '.json' extension in files endpoints url - Key: MESOS-2984 URL: https://issues.apache.org/jira/browse/MESOS-2984 Project: Mesos Issue Type: Improvement Reporter: Isabel Jimenez Assignee: Isabel Jimenez Labels: HTTP, mesosphere Remove the '.json' extension on endpoints such as `/files/browse.json` so it become `/files/browse` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2719) Removing '.json' extension in master endpoints url
[ https://issues.apache.org/jira/browse/MESOS-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2719: --- Sprint: (was: Mesosphere Sprint 15) Removing '.json' extension in master endpoints url -- Key: MESOS-2719 URL: https://issues.apache.org/jira/browse/MESOS-2719 Project: Mesos Issue Type: Improvement Reporter: Isabel Jimenez Assignee: Isabel Jimenez Labels: HTTP, mesosphere Remove the '.json' extension on endpoints such as `/master/stats.json` so it become `/master/stats` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1992) Support launching executors with configured systemd
[ https://issues.apache.org/jira/browse/MESOS-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-1992: --- Labels: mesosphere (was: ) Support launching executors with configured systemd Key: MESOS-1992 URL: https://issues.apache.org/jira/browse/MESOS-1992 Project: Mesos Issue Type: Improvement Components: slave Reporter: Timothy Chen Labels: mesosphere Currently running mesos-slave in docker with systemd, the mesos-slave container cannot be upgraded while keeping all the tasks running since killing the docker container will kill all the processes that is launched with the mesos containerizer. If we can let the executor to be launched with systemd outside of the docker container, then we can let the tasks remain running and recover them when the slave is upgraded. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3091) Failed to build scheduler using C++ API: google/protobuf/stubs/common.h: No such file or directory
Mohamed created MESOS-3091: -- Summary: Failed to build scheduler using C++ API: google/protobuf/stubs/common.h: No such file or directory Key: MESOS-3091 URL: https://issues.apache.org/jira/browse/MESOS-3091 Project: Mesos Issue Type: Bug Components: c++ api Affects Versions: 0.22.1 Reporter: Mohamed When trying to build a scheduler against mesos, the following error is encountered: In file included from /bb/bin/mesos/include/mesos/mesos.hpp:22:0, from /bb/bin/mesos/include/mesos/executor.hpp:26, from mesosbe_BasExecutor.cpp:23: /bb/bin/mesos/include/mesos/mesos.pb.h:9:42: fatal error: google/protobuf/stubs/common.h: No such file or directory #include google/protobuf/stubs/common.h It seems that the problem is mainly mesos's install target only installs mesos's headers and libs but not the headers and libs for the 3rd party packages shipped with mesos -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1113) Refactor cgroup interface in preparation for Systemd NWO.
[ https://issues.apache.org/jira/browse/MESOS-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-1113: --- Labels: cgroups mesosphere (was: cgroups) Refactor cgroup interface in preparation for Systemd NWO. - Key: MESOS-1113 URL: https://issues.apache.org/jira/browse/MESOS-1113 Project: Mesos Issue Type: Bug Components: containerization Affects Versions: 0.19.0 Reporter: Timothy St. Clair Assignee: Timothy St. Clair Labels: cgroups, mesosphere In coming releases cgroups will no longer have it's own interface, all interactions will go through systemd's DBUS interface: http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ This ticket is to track and allow the refactoring and migration that will be required in order to support. - Original Message - From: Lennart Poettering mzerq...@0pointer.de To: Development discussions related to Fedora de...@lists.fedoraproject.org Cc: Fedora Big Data SIG bigd...@lists.fedoraproject.org Sent: Monday, March 17, 2014 8:18:37 PM Subject: Re: Systemd cgroups NWO Well, the nebulous choice of words is intended, since we don't want to make specific promises on time-frames... The APIs described (tersely) at the end of the wiki page describe the status quo with systemd 211. The single-writer cgroup tree stuff Tejun has been working on for the kernel is now working on his machine, but it's not pushed upstream and will take a while before it will hit Fedora. At this point in time you hence still may create cgroups directly yourself (but only if you follow the pax cgroup document), however, we strongly encourage you to instead use scopes/slices to create them, as discussed on the wiki page. This way the cgroups transition will be abstracted away from you. You have control of a number of knobs that systemd will expose for you, such as CPUShares=, BlockIOWeight= and so on, but this is not complete, and primarily so because it's not clear that those other properties will continue to exist the way they are in the kernel. To read statistics data or to write knobs that systemd doesn't cover you need to go directly to the cgroupfs. For that, simply read /proc/self/cgroup to find out your own cgroup, and then operate on that. However, as during the single-writer cgroup transition the kernel interface how we set things up will change, be prepared that things might break... Lennart -- Lennart Poettering, Red Hat -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2963) Configure Jenkins to build ssl
[ https://issues.apache.org/jira/browse/MESOS-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Van Remoortere updated MESOS-2963: Sprint: Mesosphere Sprint 13, Mesosphere Sprint 15 (was: Mesosphere Sprint 13) Configure Jenkins to build ssl -- Key: MESOS-2963 URL: https://issues.apache.org/jira/browse/MESOS-2963 Project: Mesos Issue Type: Improvement Reporter: Joris Van Remoortere Assignee: Joris Van Remoortere Labels: jenkins, mesosphere, ssl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3088) Update scheduler driver to send SUBSCRIBE call
[ https://issues.apache.org/jira/browse/MESOS-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-3088: -- Sprint: Twitter Mesos Q3 Sprint 2 Update scheduler driver to send SUBSCRIBE call -- Key: MESOS-3088 URL: https://issues.apache.org/jira/browse/MESOS-3088 Project: Mesos Issue Type: Task Reporter: Vinod Kone Assignee: Vinod Kone See MESOS-2913 for context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3037) Add a SUPPRESS call to the scheduler
[ https://issues.apache.org/jira/browse/MESOS-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-3037: -- Shepherd: Benjamin Mahler Sprint: Twitter Mesos Q3 Sprint 2 Add a SUPPRESS call to the scheduler Key: MESOS-3037 URL: https://issues.apache.org/jira/browse/MESOS-3037 Project: Mesos Issue Type: Improvement Reporter: Vinod Kone Assignee: Vinod Kone SUPPRESS call is the complement to the current REVIVE call i.e., it will inform Mesos to stop sending offers to the framework. For the scheduler driver to send only Call messages (MESOS-2913), DeactivateFrameworkMessage needs to be converted to Call(s). We can implement this by having the driver send a SUPPRESS call followed by a DECLINE call for outstanding offers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2061) Add InverseOffer protobuf message.
[
https://issues.apache.org/jira/browse/MESOS-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-2061:
---
Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14)
Add InverseOffer protobuf message.
--
Key: MESOS-2061
URL: https://issues.apache.org/jira/browse/MESOS-2061
Project: Mesos
Issue Type: Task
Reporter: Benjamin Mahler
Assignee: Joseph Wu
Labels: mesosphere
InverseOffer was defined as part of the maintenance work in MESOS-1474,
design doc here:
https://docs.google.com/document/d/16k0lVwpSGVOyxPSyXKmGC-gbNmRlisNEe4p-fAUSojk/edit?usp=sharing
{code}
// A request to deallocate or return any resources already
// being consumed by the framework.
message InverseOffer {
required OfferID id = 1;
required FrameworkID framework_id = 2;
repeated Resource resources = 3;
// The slave ID if the resources need to be released on a particular slave.
optional SlaveID slave_id = 4;
// The executor and task IDs if the resources need to be released on
specific
// executors and/or tasks.
optional ExecutorID executor_id = 6;
repeated TaskID task_ids = 6;
// The resources specified in this offer will become unavailable
// at the specified start time and for the specified duration. Any
// tasks running using these resources might get killed when
// these resources become unavailable.
required Unavailability unavailability = 7;
}
{code}
This ticket is to capture the addition of the InverseOffer protobuf to
mesos.proto, the necessary API changes for Event/Call and the language
bindings will be tracked separately.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3088) Update scheduler driver to send SUBSCRIBE call
Vinod Kone created MESOS-3088: - Summary: Update scheduler driver to send SUBSCRIBE call Key: MESOS-3088 URL: https://issues.apache.org/jira/browse/MESOS-3088 Project: Mesos Issue Type: Task Reporter: Vinod Kone Assignee: Vinod Kone See MESOS-2913 for context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2834) Support different perf output formats
[ https://issues.apache.org/jira/browse/MESOS-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Brett updated MESOS-2834: -- Sprint: Twitter Mesos Q2 Sprint 6, Twitter Mesos Q3 Sprint 1, Twitter Mesos Q3 Sprint 2 (was: Twitter Mesos Q2 Sprint 6, Twitter Mesos Q3 Sprint 1) Support different perf output formats - Key: MESOS-2834 URL: https://issues.apache.org/jira/browse/MESOS-2834 Project: Mesos Issue Type: Improvement Components: isolation Reporter: Ian Downes Assignee: Paul Brett Labels: twitter The output format of perf changes in 3.14 (inserting an additional field) and in again in 4.1 (appending additional) fields. See kernel commits: 410136f5dd96b6013fe6d1011b523b1c247e1ccb d73515c03c6a2706e088094ff6095a3abefd398b Update the perf::parse() function to understand all these formats. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3089) Update scheduler driver to send REQUESTS call
Vinod Kone created MESOS-3089: - Summary: Update scheduler driver to send REQUESTS call Key: MESOS-3089 URL: https://issues.apache.org/jira/browse/MESOS-3089 Project: Mesos Issue Type: Task Reporter: Vinod Kone Assignee: Vinod Kone See MESOS-2913 for context. From the dev list it looks like users depend on this call for their custom allocator, so we need to support it going forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-2911) Add an Event message handler to scheduler library
[ https://issues.apache.org/jira/browse/MESOS-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar reassigned MESOS-2911: - Assignee: Anand Mazumdar (was: Benjamin Mahler) Add an Event message handler to scheduler library - Key: MESOS-2911 URL: https://issues.apache.org/jira/browse/MESOS-2911 Project: Mesos Issue Type: Task Reporter: Vinod Kone Assignee: Anand Mazumdar Adding this handler lets master send Event messages to the library. See MESOS-2909 for additional context. This ticket only tracks the installation of the handler and maybe handling of a single event for testing. Additional events handling will be captured in a different ticket(s). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2742) Architecture doc on global resources
[ https://issues.apache.org/jira/browse/MESOS-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2742: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) Architecture doc on global resources Key: MESOS-2742 URL: https://issues.apache.org/jira/browse/MESOS-2742 Project: Mesos Issue Type: Task Reporter: Niklas Quarfot Nielsen Assignee: Joerg Schad Labels: mesosphere -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2294) Implement the Events stream on master for Call endpoint
[ https://issues.apache.org/jira/browse/MESOS-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2294: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) Implement the Events stream on master for Call endpoint --- Key: MESOS-2294 URL: https://issues.apache.org/jira/browse/MESOS-2294 Project: Mesos Issue Type: Task Reporter: Vinod Kone Assignee: Anand Mazumdar Labels: mesosphere -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2984) Removing '.json' extension in files endpoints url
[ https://issues.apache.org/jira/browse/MESOS-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2984: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) Removing '.json' extension in files endpoints url - Key: MESOS-2984 URL: https://issues.apache.org/jira/browse/MESOS-2984 Project: Mesos Issue Type: Improvement Reporter: Isabel Jimenez Assignee: Isabel Jimenez Labels: HTTP, mesosphere Remove the '.json' extension on endpoints such as `/files/browse.json` so it become `/files/browse` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2497) Create synchronous validations for Calls
[ https://issues.apache.org/jira/browse/MESOS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2497: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) Create synchronous validations for Calls Key: MESOS-2497 URL: https://issues.apache.org/jira/browse/MESOS-2497 Project: Mesos Issue Type: Bug Reporter: Isabel Jimenez Assignee: Isabel Jimenez Labels: HTTP, mesosphere /call endpoint will return a 202 accepted code but has to do some basic validations before. In case of invalidation it will return a 4xx code. We have to create a mechanism that will validate the 'request' and send back the appropriate code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2983) Removing '.json' extension in slave endpoints url
[ https://issues.apache.org/jira/browse/MESOS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2983: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) Removing '.json' extension in slave endpoints url - Key: MESOS-2983 URL: https://issues.apache.org/jira/browse/MESOS-2983 Project: Mesos Issue Type: Improvement Reporter: Isabel Jimenez Assignee: Isabel Jimenez Labels: HTTP, mesosphere Remove the '.json' extension on endpoints such as `/slave/state.json` so it become `/slave/state` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2849) Implement Docker image store
[ https://issues.apache.org/jira/browse/MESOS-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2849: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) Implement Docker image store Key: MESOS-2849 URL: https://issues.apache.org/jira/browse/MESOS-2849 Project: Mesos Issue Type: Improvement Components: containerization Reporter: Timothy Chen Assignee: Lily Chen Labels: mesosphere, unified-prototype Given a Docker image name and URI, fetches the image's dependent layers, untarring if necessary. It will also parse the image layers' configuration json and place the layers and image into persistent store. Done when a Docker image can be successfully stored and retrieved using 'put' and 'get' methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2552) C++ Scheduler library should send HTTP Calls to master
[ https://issues.apache.org/jira/browse/MESOS-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2552: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) C++ Scheduler library should send HTTP Calls to master -- Key: MESOS-2552 URL: https://issues.apache.org/jira/browse/MESOS-2552 Project: Mesos Issue Type: Bug Reporter: Vinod Kone Assignee: Anand Mazumdar Labels: mesosphere Once the scheduler library sends Call messages, we should update it to send Calls as HTTP requests to /call endpoint on master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2119) Add Socket tests
[ https://issues.apache.org/jira/browse/MESOS-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2119: --- Sprint: Mesosphere Q4 Sprint 3 - 12/7, Mesosphere Q1 Sprint 1 - 1/23, Mesosphere Q1 Sprint 2 - 2/6, Mesosphere Q1 Sprint 3 - 2/20, Mesosphere Q1 Sprint 4 - 3/6, Mesosphere Q1 Sprint 5 - 3/20, Mesosphere Q1 Sprint 6 - 4/3, Mesosphere Q1 Sprint 7 - 4/17, Mesosphere Q2 Sprint 8 - 5/1, Mesosphere Sprint 10, Mesosphere Sprint 11, Mesosphere Sprint 15 (was: Mesosphere Q4 Sprint 3 - 12/7, Mesosphere Q1 Sprint 1 - 1/23, Mesosphere Q1 Sprint 2 - 2/6, Mesosphere Q1 Sprint 3 - 2/20, Mesosphere Q1 Sprint 4 - 3/6, Mesosphere Q1 Sprint 5 - 3/20, Mesosphere Q1 Sprint 6 - 4/3, Mesosphere Q1 Sprint 7 - 4/17, Mesosphere Q2 Sprint 8 - 5/1, Mesosphere Sprint 10, Mesosphere Sprint 11, Mesosphere Sprint 14) Add Socket tests Key: MESOS-2119 URL: https://issues.apache.org/jira/browse/MESOS-2119 Project: Mesos Issue Type: Task Components: libprocess Reporter: Niklas Quarfot Nielsen Assignee: Joris Van Remoortere Labels: mesosphere Add more Socket specific tests to get coverage while doing libev to libevent (w and wo SSL) move -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2719) Removing '.json' extension in master endpoints url
[ https://issues.apache.org/jira/browse/MESOS-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2719: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) Removing '.json' extension in master endpoints url -- Key: MESOS-2719 URL: https://issues.apache.org/jira/browse/MESOS-2719 Project: Mesos Issue Type: Improvement Reporter: Isabel Jimenez Assignee: Isabel Jimenez Labels: HTTP, mesosphere Remove the '.json' extension on endpoints such as `/master/stats.json` so it become `/master/stats` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3013) Extend DiscoveryInfo to include NetworkRequirement message
[
https://issues.apache.org/jira/browse/MESOS-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-3013:
---
Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14)
Extend DiscoveryInfo to include NetworkRequirement message
Key: MESOS-3013
URL: https://issues.apache.org/jira/browse/MESOS-3013
Project: Mesos
Issue Type: Task
Reporter: Kapil Arya
Assignee: Kapil Arya
Labels: mesosphere
As per the [design
doc|https://docs.google.com/document/d/17mXtAmdAXcNBwp_JfrxmZcQrs7EO6ancSbejrqjLQ0g],
we need to enable frameworks to specify network requirements. The proposed
message could be along the lines of:
{code}
message NetworkRequirement {
enum Protocol {
IPv4,
IPv6
}
required Protocol protocol;
// A netgroup is the name given to a set of logically-related IPs that are
// allowed to communicate within themselves. For example, one might want
// to create separate netgroups for dev, testing, qa and prod deployment
// environments.
repeated string netgroups;
// Sticky IPs allow a framwork to re-launch a task with the same IP on a
// different Slave/Node.
optional bool sticky [default = false];
// A unique id that the framework uses to tag the assigned IP. This tag
// can be later used to reclaim IP while relaunching the task.
optional string id;
};
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2840) MesosContainerizer support multiple image provisioners
[ https://issues.apache.org/jira/browse/MESOS-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2840: --- Sprint: Mesosphere Sprint 12, Mesosphere Sprint 13, Mesosphere Sprint 14, Mesosphere Sprint 15 (was: Mesosphere Sprint 12, Mesosphere Sprint 13, Mesosphere Sprint 14) MesosContainerizer support multiple image provisioners -- Key: MESOS-2840 URL: https://issues.apache.org/jira/browse/MESOS-2840 Project: Mesos Issue Type: Epic Components: containerization, docker Affects Versions: 0.23.0 Reporter: Marco Massenzio Assignee: Timothy Chen Labels: mesosphere We want to utilize the Appc integration interfaces to further make MesosContainerizers to support multiple image formats. This allows our future work on isolators to support any container image format. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2200) bogus docker images result in bad error message to scheduler
[
https://issues.apache.org/jira/browse/MESOS-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-2200:
---
Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14)
bogus docker images result in bad error message to scheduler
Key: MESOS-2200
URL: https://issues.apache.org/jira/browse/MESOS-2200
Project: Mesos
Issue Type: Bug
Components: containerization, docker
Reporter: Jay Buffington
Assignee: Joerg Schad
Labels: mesosphere
When a scheduler specifies a bogus image in ContainerInfo mesos doesn't tell
the scheduler that the docker pull failed or why.
This error is logged in the mesos-slave log, but it isn't given to the
scheduler (as far as I can tell):
{noformat}
E1218 23:50:55.406230 8123 slave.cpp:2730] Container
'8f70784c-3e40-4072-9ca2-9daed23f15ff' for executor
'thermos-1418946354013-xxx-xxx-curl-0-f500cc41-dd0a-4338-8cbc-d631cb588bb1'
of framework '20140522-213145-1749004561-5050-29512-' failed to start:
Failed to 'docker pull
docker-registry.example.com/doesntexist/hello1.1:latest': exit status =
exited with status 1 stderr = 2014/12/18 23:50:55 Error: image
doesntexist/hello1.1 not found
{noformat}
If the docker image is not in the registry, the scheduler should give the
user an error message. If docker pull failed because of networking issues,
it should be retried. Mesos should give the scheduler enough information to
be able to make that decision.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2936) Create a design document for Quota support in Master
[ https://issues.apache.org/jira/browse/MESOS-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2936: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) Create a design document for Quota support in Master Key: MESOS-2936 URL: https://issues.apache.org/jira/browse/MESOS-2936 Project: Mesos Issue Type: Documentation Components: documentation Reporter: Alexander Rukletsov Assignee: Alexander Rukletsov Labels: mesosphere Create a design document for the Quota feature support in Mesos Master (excluding allocator) to be shared with the Mesos community. Design Doc: https://docs.google.com/document/d/16iRNmziasEjVOblYp5bbkeBZ7pnjNlaIzPQqMTHQ-9I/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3089) Update scheduler driver to send REQUESTS call
[ https://issues.apache.org/jira/browse/MESOS-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-3089: -- Sprint: Twitter Mesos Q3 Sprint 2 Story Points: 2 Update scheduler driver to send REQUESTS call - Key: MESOS-3089 URL: https://issues.apache.org/jira/browse/MESOS-3089 Project: Mesos Issue Type: Task Reporter: Vinod Kone Assignee: Vinod Kone See MESOS-2913 for context. From the dev list it looks like users depend on this call for their custom allocator, so we need to support it going forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3076) Add Labels to TaskStatus and expose them via state.json
[ https://issues.apache.org/jira/browse/MESOS-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-3076: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) Add Labels to TaskStatus and expose them via state.json --- Key: MESOS-3076 URL: https://issues.apache.org/jira/browse/MESOS-3076 Project: Mesos Issue Type: Task Reporter: Kapil Arya Assignee: Kapil Arya Priority: Critical Labels: mesosphere This would allow the executors and Slave modules to expose some meta-data to frameworks and Mesos-DNS via state.json. A typical use case is to allow the containers to expose their IP to framework/Mesos-DNS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2902) Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME
[ https://issues.apache.org/jira/browse/MESOS-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2902: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME Key: MESOS-2902 URL: https://issues.apache.org/jira/browse/MESOS-2902 Project: Mesos Issue Type: Improvement Components: master, modules, slave Reporter: Cody Maloney Assignee: Marco Massenzio Priority: Critical Labels: mesosphere Currently Mesos tries to guess the IP, HOSTNAME by doing a reverse DNS lookup. This doesn't work on a lot of clouds as we want things like public IPs (which aren't the default DNS), there aren't FQDN names (Azure), or the correct way to figure it out is to call some cloud-specific endpoint. If Mesos / Libprocess could load a mesos-module (Or run a script) which is provided per-cloud, we can figure out perfectly the IP / Hostname for the given environment. It also means we can ship one identical set of files to all hosts in a given provider which doesn't happen to have the DNS scheme + hostnames that libprocess/Mesos expects. Currently we have to generate host-specific config files which Mesos uses to guess. The host-specific files break / fall apart if machines change IP / hostname without being reinstalled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2830) Add an endpoint to slaves to allow launching system administration tasks
[ https://issues.apache.org/jira/browse/MESOS-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2830: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) Add an endpoint to slaves to allow launching system administration tasks Key: MESOS-2830 URL: https://issues.apache.org/jira/browse/MESOS-2830 Project: Mesos Issue Type: Wish Components: slave Reporter: Cody Maloney Assignee: Marco Massenzio Priority: Minor Labels: mesosphere Attachments: Screen Shot 2015-07-10 at 2.52.52 PM.png, Screen Shot 2015-07-10 at 2.58.34 PM.png, Screen Shot 2015-07-10 at 3.09.12 PM.png As a System Administrator often times I need to run a organization-mandated task on every machine in the cluster. Ideally I could do this within the framework of mesos resources if it is a cleanup or auditing task, but sometimes I just have to run something, and run it now, regardless if a machine has un-accounted resources (Ex: Adding/removing a user). Currently to do this I have to completely bypass Mesos and SSH to the box. Ideally I could tell a mesos slave (With proper authentication) to run a container with the limited special permissions needed to get the task done. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2860) Create the basic infrastructure to handle /call endpoint
[
https://issues.apache.org/jira/browse/MESOS-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-2860:
---
Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14)
Create the basic infrastructure to handle /call endpoint
Key: MESOS-2860
URL: https://issues.apache.org/jira/browse/MESOS-2860
Project: Mesos
Issue Type: Story
Components: master
Reporter: Marco Massenzio
Assignee: Isabel Jimenez
Labels: mesosphere
This is the first basic step in ensuring the basic {{/call}} functionality:
processing a
{noformat}
POST /call
{noformat}
and returning:
- {{202}} if all goes well;
- {{401}} if not authorized; and
- {{403}} if the request is malformed.
We'll get more sophisticated as the work progressed (eg, supporting {{415}}
if the content-type is not of the right kind).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2582) Create optional release step: update PyPi repositories
[ https://issues.apache.org/jira/browse/MESOS-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2582: --- Sprint: Mesosphere Q1 Sprint 7 - 4/17, Mesosphere Sprint 10, Mesosphere Sprint 11, Mesosphere Sprint 15 (was: Mesosphere Q1 Sprint 7 - 4/17, Mesosphere Sprint 10, Mesosphere Sprint 11, Mesosphere Sprint 14) Create optional release step: update PyPi repositories -- Key: MESOS-2582 URL: https://issues.apache.org/jira/browse/MESOS-2582 Project: Mesos Issue Type: Documentation Reporter: Niklas Quarfot Nielsen Assignee: Adam B Labels: mesosphere One of the build artifacts for a release is the python package `mesos.interface`. That needs to be uploaded to PyPi along with a release to allow for users of python frameworks to use that version of mesos. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2947) Authorizer Module: Implementation, Integration Tests
[
https://issues.apache.org/jira/browse/MESOS-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-2947:
---
Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14)
Authorizer Module: Implementation, Integration Tests
--
Key: MESOS-2947
URL: https://issues.apache.org/jira/browse/MESOS-2947
Project: Mesos
Issue Type: Improvement
Reporter: Till Toenshoff
Assignee: Alexander Rojas
Labels: mesosphere, module, security
h4.Motivation
Provide an example authorizer module based on the {{LocalAuthorizer}}
implementation. Make sure that such authorizer module can be fully unit- and
integration- tested within the mesos test suite.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2673) Follow Google Style Guide for header file include order completely.
[ https://issues.apache.org/jira/browse/MESOS-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-2673: --- Sprint: Mesosphere Sprint 10, Mesosphere Sprint 11, Mesosphere Sprint 15 (was: Mesosphere Sprint 10, Mesosphere Sprint 11, Mesosphere Sprint 14) Follow Google Style Guide for header file include order completely. --- Key: MESOS-2673 URL: https://issues.apache.org/jira/browse/MESOS-2673 Project: Mesos Issue Type: Improvement Reporter: Joerg Schad Assignee: Joerg Schad Priority: Minor Labels: mesosphere Fix For: 0.24.0 The header include order for Mesos actually follows the Google Styleguide but omits step 1 without mentioning this exception in the Mesos styleguide. This proposal suggests to adapt to the include order explained in the Google Styleguide i.e. include the direct headers first in the .cpp files implementing them. A gist of the proposal can be found here: https://gist.github.com/joerg84/65cb9611d24b2e35b69b The corresponding Review Board review can be found here: https://reviews.apache.org/r/33646/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1815) Create a guide to becoming a committer
[ https://issues.apache.org/jira/browse/MESOS-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-1815: --- Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14) Create a guide to becoming a committer -- Key: MESOS-1815 URL: https://issues.apache.org/jira/browse/MESOS-1815 Project: Mesos Issue Type: Documentation Components: documentation Reporter: Dominic Hamon Assignee: Bernd Mathiske Labels: mesosphere We have a committer's guide, but the process by which one becomes a committer is unclear. We should set some guidelines and a process by which we can grow contributors into committers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2964) libprocess io does not support peek()
[
https://issues.apache.org/jira/browse/MESOS-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-2964:
---
Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14)
libprocess io does not support peek()
-
Key: MESOS-2964
URL: https://issues.apache.org/jira/browse/MESOS-2964
Project: Mesos
Issue Type: Improvement
Components: libprocess
Reporter: Artem Harutyunyan
Assignee: Artem Harutyunyan
Priority: Minor
Labels: beginner, mesosphere, newbie
Finally, I so wish we could just do:
{code}
io::peek(request-socket, 6)
.then([request](const string data) {
// Comment about the rules ...
if (data.length() 2) { // Rule 1
} else if (...) { // Rule 2.
} else if (...) { // Rule 3.
}
if (ssl) {
accept_SSL_callback(request);
} else {
...;
}
});
{code}
from:
https://reviews.apache.org/r/31207/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2600) Add /reserve and /unreserve endpoints on the master for dynamic reservation
[
https://issues.apache.org/jira/browse/MESOS-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-2600:
---
Sprint: Mesosphere Sprint 10, Mesosphere Sprint 11, Mesosphere Sprint 15
(was: Mesosphere Sprint 10, Mesosphere Sprint 11, Mesosphere Sprint 14)
Add /reserve and /unreserve endpoints on the master for dynamic reservation
---
Key: MESOS-2600
URL: https://issues.apache.org/jira/browse/MESOS-2600
Project: Mesos
Issue Type: Task
Components: master
Reporter: Michael Park
Assignee: Michael Park
Priority: Critical
Labels: mesosphere
Enable operators to manage dynamic reservations by Introducing the
{{/reserve}} and {{/unreserve}} HTTP endpoints on the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2946) Authorizer Module: Interface design
[
https://issues.apache.org/jira/browse/MESOS-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-2946:
---
Sprint: Mesosphere Sprint 15 (was: Mesosphere Sprint 14)
Authorizer Module: Interface design
---
Key: MESOS-2946
URL: https://issues.apache.org/jira/browse/MESOS-2946
Project: Mesos
Issue Type: Improvement
Reporter: Till Toenshoff
Assignee: Alexander Rojas
Labels: mesosphere, module, security
h4.Motivation
Design an interface covering authorizer modules while staying minimally
invasive in regards to changes to the existing {{LocalAuthorizer}}
implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3108) Add autotools-style Mesos distributions to the CMake build system
Alex Clemmer created MESOS-3108: --- Summary: Add autotools-style Mesos distributions to the CMake build system Key: MESOS-3108 URL: https://issues.apache.org/jira/browse/MESOS-3108 Project: Mesos Issue Type: Task Components: build Reporter: Alex Clemmer Assignee: Alex Clemmer In the autoconf-based build system, we there is a notion of building a distribution of Mesos. Essentially, it is a version of Mesos that is configured for a specific platform (Ubuntu, say); so, if a consumer knows their platform, and there is a Mesos distribution, they need only run `make all` and Mesos builds. This allows the consumer to skip the configure step. In CMake, it should be possible to do this (should be!), and we should explore making it work after we complete the MVP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3109) Expand CMake build system to support building the containerizer and associated components
Alex Clemmer created MESOS-3109: --- Summary: Expand CMake build system to support building the containerizer and associated components Key: MESOS-3109 URL: https://issues.apache.org/jira/browse/MESOS-3109 Project: Mesos Issue Type: Task Components: build Reporter: Alex Clemmer Assignee: Alex Clemmer In other tasks in epic MESOS-898, we implement a CMake-based build system that allows us to build process library, the process tests, and the stout tests. For the CMake build system MVP, it's important that we expand this to build the containerizer, associated modules, and all related tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3110) Harden the CMake system-dependency-locating routines
Alex Clemmer created MESOS-3110: --- Summary: Harden the CMake system-dependency-locating routines Key: MESOS-3110 URL: https://issues.apache.org/jira/browse/MESOS-3110 Project: Mesos Issue Type: Task Components: build Reporter: Alex Clemmer Assignee: Alex Clemmer Currently the Mesos project has two flavors of dependency: (1) the dependencies we expect are already on the system (_e.g._, apr, libsvn), and (2) the dependencies that are historically bundled with Mesos (_e.g._, glog). Dependency type (1) requires solid modules that will locate them on any system: Linux, BSD, or Windows. This would come for free if we were using CMake 3.0, but we're using CMake 2.8 so that Ubuntu users can install it out of the box, instead of upgrading CMake first. This is additionally useful for dependency type (2), where we will expect to have to use these routines when we support both the rebundled dependencies in the `3rdparty/` folder, and system installations of those dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-3079:
--
Comment: was deleted
(was: Root tests failing everywhere.)
`sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
-
Key: MESOS-3079
URL: https://issues.apache.org/jira/browse/MESOS-3079
Project: Mesos
Issue Type: Bug
Affects Versions: 0.23.0
Reporter: Marco Massenzio
Assignee: Adam B
Priority: Blocker
Labels: mesosphere, tests
Attachments: test-results.log
Running tests as root causes a large number of failures.
{noformat}
$ lsb_release -a
LSB Version:
core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: Ubuntu
Description:Ubuntu 14.04.2 LTS
Release:14.04
Codename: trusty
$ sudo make -j12 V=0 check
[==] 712 tests from 116 test cases ran. (318672 ms total)
[ PASSED ] 676 tests.
[ FAILED ] 36 tests, listed below:
[ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
[ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
[ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
= mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
= mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
TypeParam = mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
= mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
TypeParam = mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.SchedulerFailover, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.PartitionedSlave, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.MasterFailover, where TypeParam =
[jira] [Updated] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-3079:
--
Target Version/s: (was: 0.23.0)
`sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
-
Key: MESOS-3079
URL: https://issues.apache.org/jira/browse/MESOS-3079
Project: Mesos
Issue Type: Bug
Affects Versions: 0.23.0
Reporter: Marco Massenzio
Assignee: Adam B
Priority: Blocker
Labels: mesosphere, tests
Attachments: test-results.log
Running tests as root causes a large number of failures.
{noformat}
$ lsb_release -a
LSB Version:
core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: Ubuntu
Description:Ubuntu 14.04.2 LTS
Release:14.04
Codename: trusty
$ sudo make -j12 V=0 check
[==] 712 tests from 116 test cases ran. (318672 ms total)
[ PASSED ] 676 tests.
[ FAILED ] 36 tests, listed below:
[ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
[ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
[ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
= mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
= mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
TypeParam = mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
= mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
TypeParam = mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.SchedulerFailover, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.PartitionedSlave, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.MasterFailover, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ]
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634415#comment-14634415
]
Adam B commented on MESOS-3079:
---
Just ran `sudo make check` on master on Ubuntu 14.04:
{code}
$ GTEST_FILTER=-*ROOT_DOCKER_Launch_Executor_Bridged* bin/mesos-tests.sh
...
[==] 672 tests from 98 test cases ran. (271494 ms total)
[ PASSED ] 672 tests.
{code}
I ran into a segfault in ROOT_DOCKER_Launch_Executor_Bridged, but everything
else passed.
Anybody else have anything to report? [~marco-mesos] [~hartem]
[~benjaminhindman] [~tnachen] [~js84] [~bernd-mesos]
Since the fixes above were just in the tests, I still don't think there's a
need to call for a 0.23.0-rc5.
`sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
-
Key: MESOS-3079
URL: https://issues.apache.org/jira/browse/MESOS-3079
Project: Mesos
Issue Type: Bug
Affects Versions: 0.23.0
Reporter: Marco Massenzio
Assignee: Adam B
Priority: Blocker
Labels: mesosphere, tests
Attachments: test-results.log
Running tests as root causes a large number of failures.
{noformat}
$ lsb_release -a
LSB Version:
core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: Ubuntu
Description:Ubuntu 14.04.2 LTS
Release:14.04
Codename: trusty
$ sudo make -j12 V=0 check
[==] 712 tests from 116 test cases ran. (318672 ms total)
[ PASSED ] 676 tests.
[ FAILED ] 36 tests, listed below:
[ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
[ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
[ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
= mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
= mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
TypeParam = mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ]
[jira] [Updated] (MESOS-3093) Support HTTPS requests in libprocess
[ https://issues.apache.org/jira/browse/MESOS-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lily Chen updated MESOS-3093: - Labels: mesosphere (was: ) Support HTTPS requests in libprocess Key: MESOS-3093 URL: https://issues.apache.org/jira/browse/MESOS-3093 Project: Mesos Issue Type: Improvement Reporter: Lily Chen Labels: mesosphere -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3093) Support HTTPS requests in libprocess
Lily Chen created MESOS-3093: Summary: Support HTTPS requests in libprocess Key: MESOS-3093 URL: https://issues.apache.org/jira/browse/MESOS-3093 Project: Mesos Issue Type: Improvement Reporter: Lily Chen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634176#comment-14634176
]
Adam B commented on MESOS-3079:
---
Several tests fixed by these (and other) commits.
commit b1a23d6a52c31b8c5c840ab01902dbe00cb1feef
Author: Benjamin Hindman benjamin.hind...@gmail.com
Date: Sun Jul 19 06:15:46 2015 +
Preemptively fail tests if previous invocations failed.
Review: https://reviews.apache.org/r/36604
commit ec6f9f8c4663f18055c01a118f3e4934107bf3bc
Author: Benjamin Hindman benjamin.hind...@gmail.com
Date: Sun Jul 19 06:14:20 2015 +
Cleaned up 'perf' related tests to work on Ubuntu 14.04.
Review: https://reviews.apache.org/r/36605
commit 4abb59ea4848c39d9f7f654ef74a326003d427c8
Author: Benjamin Hindman benjamin.hind...@gmail.com
Date: Sun Jul 19 02:06:54 2015 +
Fixed UserCgroupIsolatorTest to be more explicit.
Review: https://reviews.apache.org/r/36601
commit ff007d6a4148c9769650ddba5d067343f3834bd0
Author: Benjamin Hindman benjamin.hind...@gmail.com
Date: Sun Jul 19 00:53:04 2015 +
Fixes for NsTest on Ubuntu.
Review: https://reviews.apache.org/r/36600
`sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
-
Key: MESOS-3079
URL: https://issues.apache.org/jira/browse/MESOS-3079
Project: Mesos
Issue Type: Bug
Affects Versions: 0.23.0
Reporter: Marco Massenzio
Assignee: Adam B
Priority: Blocker
Labels: mesosphere, tests
Attachments: test-results.log
Running tests as root causes a large number of failures.
{noformat}
$ lsb_release -a
LSB Version:
core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: Ubuntu
Description:Ubuntu 14.04.2 LTS
Release:14.04
Codename: trusty
$ sudo make -j12 V=0 check
[==] 712 tests from 116 test cases ran. (318672 ms total)
[ PASSED ] 676 tests.
[ FAILED ] 36 tests, listed below:
[ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
[ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
[ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
= mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
= mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
TypeParam = mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
mesos::internal::slave::MesosContainerizer
[ FAILED ]
[jira] [Assigned] (MESOS-3096) Authentication for Communicating with Docker Registry
[ https://issues.apache.org/jira/browse/MESOS-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lily Chen reassigned MESOS-3096: Assignee: Lily Chen Authentication for Communicating with Docker Registry - Key: MESOS-3096 URL: https://issues.apache.org/jira/browse/MESOS-3096 Project: Mesos Issue Type: Improvement Reporter: Lily Chen Assignee: Lily Chen Labels: mesosphere In order to pull Docker images from Docker Hub and private Docker registries, the provisioner must support two primary authentication frameworks to authenticate with the registries, basic authentication and the OAuth2.0 authorization framework, as per the docker registry spec. A Docker registry can also operate in standalone mode and may not require authentication. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
