[jira] [Commented] (MESOS-3151) Reservation Test failed
[
https://issues.apache.org/jira/browse/MESOS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643935#comment-14643935
]
Jihun Kang commented on MESOS-3151:
---
Patch is available on reviewboard.
https://reviews.apache.org/r/36879/
> Reservation Test failed
> ---
>
> Key: MESOS-3151
> URL: https://issues.apache.org/jira/browse/MESOS-3151
> Project: Mesos
> Issue Type: Bug
> Environment: Ubuntu 14.04.2
> OpenJDK 1.7.0_79
> IBM JDK 1.7.0 SR8
>Reporter: Jihun Kang
>Assignee: Jihun Kang
>
> Here is the details.
> {noformat}
> [ RUN ]
> ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes
> ../../src/tests/reservation_tests.cpp:1055: Failure
> Value of: Resources(offer.resources()).contains(unreserved + unreservedDisk)
> Actual: false
> Expected: true
> 2015-07-27
> 17:31:16,280:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
> Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2015-07-27
> 17:31:19,617:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
> Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2015-07-27
> 17:31:22,951:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
> Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2015-07-27
> 17:31:26,288:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
> Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> ../../src/tests/reservation_tests.cpp:1076: Failure
> Failed to wait 15secs for message1
> *** Aborted at 1437985889 (unix time) try "date -d @1437985889" if you are
> using GNU date ***
> PC: @0x0 (unknown)
> ../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
> Actual function call count doesn't match EXPECT_CALL(filter->mock,
> filter(testing::A()))...
> Expected args: message matcher (8-byte object ,
> 1-byte object <61>, 1-byte object )
> Expected: to be called once
>Actual: never called - unsatisfied and active
> ../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
> Actual function call count doesn't match EXPECT_CALL(filter->mock,
> filter(testing::A()))...
> Expected args: message matcher (8-byte object ,
> 1-byte object <61>, 1-byte object )
> Expected: to be called once
>Actual: never called - unsatisfied and active
> [ FAILED ]
> ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes (15354
> ms)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2841) FrameworkInfo should include a Labels field to support arbitrary, lightweight metadata
[ https://issues.apache.org/jira/browse/MESOS-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-2841: -- Assignee: Neil Conway > FrameworkInfo should include a Labels field to support arbitrary, lightweight > metadata > -- > > Key: MESOS-2841 > URL: https://issues.apache.org/jira/browse/MESOS-2841 > Project: Mesos > Issue Type: Improvement >Reporter: James DeFelice >Assignee: Neil Conway > Labels: mesosphere > > A framework instance may offer specific capabilities to the cluster: storage, > smartly-balanced request handling across deployed tasks, access to 3rd party > services outside of the cluster, etc. These capabilities may or may not be > utilized by all, or even most mesos clusters. However, it should be possible > for processes running in the cluster to discover capabilities or features of > frameworks in order to achieve a higher level of functionality and a more > seamless integration experience across the cluster. > A rich discovery API attached to the FrameworkInfo could result in some form > of early lock-in: there are probably many ways to realize cross-framework > integration and external services integration that we haven't considered yet. > Rather than over-specify a discovery info message type at the framework level > I think FrameworkInfo should expose a **very generic** way to supply metadata > for interested consumers (other processes, tasks, etc). > Adding a Labels field to FrameworkInfo reuses an existing message type and > seems to fit well with the overall intent: attaching generic metadata to a > framework instance. These labels should be visible when querying a mesos > master's state.json endpoint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2559) Do not use RunTaskMessage.framework_id.
[ https://issues.apache.org/jira/browse/MESOS-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643922#comment-14643922 ] Adam B commented on MESOS-2559: --- [~karya] Do you want to revive this patch now that 0.23 has shipped? > Do not use RunTaskMessage.framework_id. > --- > > Key: MESOS-2559 > URL: https://issues.apache.org/jira/browse/MESOS-2559 > Project: Mesos > Issue Type: Bug > Components: framework >Reporter: Kapil Arya >Assignee: Kapil Arya > Labels: mesosphere > > Assume that FrameworkInfo.id is always set and so need to read/set > RunTaskMessage.framework_id. > This should land after https://issues.apache.org/jira/browse/MESOS-2558 has > been shipped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3070) Master CHECK failure if a framework uses duplicated task id.
[
https://issues.apache.org/jira/browse/MESOS-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klaus Ma updated MESOS-3070:
Component/s: master
> Master CHECK failure if a framework uses duplicated task id.
>
>
> Key: MESOS-3070
> URL: https://issues.apache.org/jira/browse/MESOS-3070
> Project: Mesos
> Issue Type: Bug
> Components: master
>Affects Versions: 0.22.1
>Reporter: Jie Yu
>
> We observed this in one of our testing cluster.
> One framework (under development) keeps launching tasks using the same
> task_id. We don't expect the master to crash even if the framework is not
> doing what it's supposed to do. However, under a series of events, this could
> happen and keeps crashing the master.
> 1) frameworkA launches task 'task_id_1' on slaveA
> 2) master fails over
> 3) slaveA has not re-registered yet
> 4) frameworkA re-registered and launches task 'task_id_1' on slaveB
> 5) slaveA re-registering and add task "task_id_1' to frameworkA
> 6) CHECK failure in addTask
> {noformat}
> I0716 21:52:50.759305 28805 master.hpp:159] Adding task 'task_id_1' with
> resources cpus(*):4; mem(*):32768 on slave
> 20150417-232509-1735470090-5050-48870-S25 (hostname)
> ...
> ...
> F0716 21:52:50.760136 28805 master.hpp:362] Check failed:
> !tasks.contains(task->task_id()) Duplicate task 'task_id_1' of framework
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2841) FrameworkInfo should include a Labels field to support arbitrary, lightweight metadata
[ https://issues.apache.org/jira/browse/MESOS-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-2841: -- Issue Type: Improvement (was: Epic) > FrameworkInfo should include a Labels field to support arbitrary, lightweight > metadata > -- > > Key: MESOS-2841 > URL: https://issues.apache.org/jira/browse/MESOS-2841 > Project: Mesos > Issue Type: Improvement >Reporter: James DeFelice > Labels: mesosphere > > A framework instance may offer specific capabilities to the cluster: storage, > smartly-balanced request handling across deployed tasks, access to 3rd party > services outside of the cluster, etc. These capabilities may or may not be > utilized by all, or even most mesos clusters. However, it should be possible > for processes running in the cluster to discover capabilities or features of > frameworks in order to achieve a higher level of functionality and a more > seamless integration experience across the cluster. > A rich discovery API attached to the FrameworkInfo could result in some form > of early lock-in: there are probably many ways to realize cross-framework > integration and external services integration that we haven't considered yet. > Rather than over-specify a discovery info message type at the framework level > I think FrameworkInfo should expose a **very generic** way to supply metadata > for interested consumers (other processes, tasks, etc). > Adding a Labels field to FrameworkInfo reuses an existing message type and > seems to fit well with the overall intent: attaching generic metadata to a > framework instance. These labels should be visible when querying a mesos > master's state.json endpoint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1476) Provide endpoints for deactivating / activating slaves.
[ https://issues.apache.org/jira/browse/MESOS-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643900#comment-14643900 ] Klaus Ma commented on MESOS-1476: - Should we re-open this ticket because of design changed? ACCEPTED status means we're going to do it; it makes people confused. > Provide endpoints for deactivating / activating slaves. > --- > > Key: MESOS-1476 > URL: https://issues.apache.org/jira/browse/MESOS-1476 > Project: Mesos > Issue Type: Improvement > Components: master >Reporter: Benjamin Mahler > Labels: gsoc2014, mesosphere, twitter > > When performing maintenance operations on slaves, it is important to allow > these slaves to be drained of their tasks. > The first essential primitive of draining slaves is to prevent them from > running more tasks. This can be achieved by "deactivating" them: stop sending > their resource offers to frameworks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3151) Reservation Test failed
[
https://issues.apache.org/jira/browse/MESOS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jihun Kang updated MESOS-3151:
--
Environment:
Ubuntu 14.04.2
OpenJDK 1.7.0_79
IBM JDK 1.7.0 SR8
was:
Ubuntu 14.04.2
IBM JDK 1.7.0 SR8
> Reservation Test failed
> ---
>
> Key: MESOS-3151
> URL: https://issues.apache.org/jira/browse/MESOS-3151
> Project: Mesos
> Issue Type: Bug
> Environment: Ubuntu 14.04.2
> OpenJDK 1.7.0_79
> IBM JDK 1.7.0 SR8
>Reporter: Jihun Kang
>Assignee: Jihun Kang
>
> Here is the details.
> {noformat}
> [ RUN ]
> ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes
> ../../src/tests/reservation_tests.cpp:1055: Failure
> Value of: Resources(offer.resources()).contains(unreserved + unreservedDisk)
> Actual: false
> Expected: true
> 2015-07-27
> 17:31:16,280:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
> Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2015-07-27
> 17:31:19,617:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
> Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2015-07-27
> 17:31:22,951:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
> Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2015-07-27
> 17:31:26,288:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
> Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> ../../src/tests/reservation_tests.cpp:1076: Failure
> Failed to wait 15secs for message1
> *** Aborted at 1437985889 (unix time) try "date -d @1437985889" if you are
> using GNU date ***
> PC: @0x0 (unknown)
> ../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
> Actual function call count doesn't match EXPECT_CALL(filter->mock,
> filter(testing::A()))...
> Expected args: message matcher (8-byte object ,
> 1-byte object <61>, 1-byte object )
> Expected: to be called once
>Actual: never called - unsatisfied and active
> ../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
> Actual function call count doesn't match EXPECT_CALL(filter->mock,
> filter(testing::A()))...
> Expected args: message matcher (8-byte object ,
> 1-byte object <61>, 1-byte object )
> Expected: to be called once
>Actual: never called - unsatisfied and active
> [ FAILED ]
> ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes (15354
> ms)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-527) Command Executors do not have Executor IDs in the master.
[ https://issues.apache.org/jira/browse/MESOS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643813#comment-14643813 ] haosdent commented on MESOS-527: Sorry for misunderstand this ticket #_#. Let me update again. > Command Executors do not have Executor IDs in the master. > - > > Key: MESOS-527 > URL: https://issues.apache.org/jira/browse/MESOS-527 > Project: Mesos > Issue Type: Bug >Reporter: Benjamin Mahler >Assignee: haosdent > Labels: twitter > > The webui is broken for command executors because the master does not know > the executor ID for the tasks using a command executor. This is because the > Task protobuf only has the executor_id field, no other field to indicate the > presence of the command executor. > It seems the slave also doesn't set the Task.executor_id for command > executors, thus relying on it being optionally set in executorTerminated() to > determine whether the task used a command executor. > This all seems pretty messy, a few things to consider: > 1) Should we simply always set the Task.executor_id for these tasks? The > master could do so currently, but there would be an implicit contract that > the slave and master both use the task id as the executor id. > 2) We can add a boolean is_command_executor to Task, so that both the master > and slave can set the field, and the slave can use the boolean in > executorTerminated() to determine whether the task used a command executor. > 3) Alternatively, we can add a /frameworks/FID/tasks/TID url format for the > broken links on the master webui, so that we can search for the task in the > slave state to locate its executor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-527) Command Executors do not have Executor IDs in the master.
[ https://issues.apache.org/jira/browse/MESOS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643809#comment-14643809 ] Adam B commented on MESOS-527: -- [~haosd...@gmail.com] Thanks for the attempt, but this ticket is not related to the `mesos-execute` CLI command. Instead, you should look into the `Master::_accept()` and `Master::addTask()` code path. See especially this block where we extract the executorId from an ExecutorInfo (custom executor): https://github.com/apache/mesos/blob/0.23.0/src/master/master.cpp#L2382 For a default/command executor, `has_executor()` will return false, so the master won't know an executorId for this task. After familiarizing yourself with this part of the code (and perhaps `Slave::runTask()`), it should be easier to understand the three options [~bmahler] suggested above. Either the master can set the executorId (to taskId?), we can use an explicit boolean to indicate that these tasks use the default/command executor, or we can workaround the webui issue with other links. > Command Executors do not have Executor IDs in the master. > - > > Key: MESOS-527 > URL: https://issues.apache.org/jira/browse/MESOS-527 > Project: Mesos > Issue Type: Bug >Reporter: Benjamin Mahler >Assignee: haosdent > Labels: twitter > > The webui is broken for command executors because the master does not know > the executor ID for the tasks using a command executor. This is because the > Task protobuf only has the executor_id field, no other field to indicate the > presence of the command executor. > It seems the slave also doesn't set the Task.executor_id for command > executors, thus relying on it being optionally set in executorTerminated() to > determine whether the task used a command executor. > This all seems pretty messy, a few things to consider: > 1) Should we simply always set the Task.executor_id for these tasks? The > master could do so currently, but there would be an implicit contract that > the slave and master both use the task id as the executor id. > 2) We can add a boolean is_command_executor to Task, so that both the master > and slave can set the field, and the slave can use the boolean in > executorTerminated() to determine whether the task used a command executor. > 3) Alternatively, we can add a /frameworks/FID/tasks/TID url format for the > broken links on the master webui, so that we can search for the task in the > slave state to locate its executor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3141) Compiler warning when mocking function type has an enum return type.
[
https://issues.apache.org/jira/browse/MESOS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643768#comment-14643768
]
haosdent commented on MESOS-3141:
-
[~mcypark] Seems rbt use git diff to generate patch, and git diff don't
contains binary data change.
> Compiler warning when mocking function type has an enum return type.
>
>
> Key: MESOS-3141
> URL: https://issues.apache.org/jira/browse/MESOS-3141
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Michael Park
>Assignee: haosdent
> Labels: mesosphere
>
> The purpose of this ticket is to document a very cryptic error message
> (actually a warning that gets propagated by {{-Werror}}) that gets generated
> by {{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
> innocent-looking function.
> h3. Problem
> The following code is attempting to mock a {{MesosExecutorDriver}}:
> {code}
> class MockMesosExecutorDriver : public MesosExecutorDriver {
> public:
> MockMesosExecutorDriver(mesos::Executor* executor)
> : MesosExecutorDriver(executor) {}
> MOCK_METHOD1(sendStatusUpdate, Status(const TaskStatus&));
> };
> {code}
> The above code generates the following error message:
> {noformat}
> In file included from
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58:
> In file included from
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46:
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
> error: indirection of non-volatile null pointer will be deleted, not trap
> [-Werror,-Wnull-dereference]
> return *static_cast::type*>(__null);
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:78:22:
> note: in instantiation of function template specialization
> 'testing::internal::Invalid' requested here
> return internal::Invalid();
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
> note: in instantiation of member function
> 'testing::internal::BuiltInDefaultValue::Get' requested here
> internal::BuiltInDefaultValue::Get() : *value_;
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
> note: in instantiation of member function
> 'testing::DefaultValue::Get' requested here
> return DefaultValue::Get();
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
> note: in instantiation of member function
> 'testing::internal::FunctionMockerBase &)>::PerformDefaultAction' requested here
> func_mocker->PerformDefaultAction(args, call_description));
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1448:26:
> note: in instantiation of function template specialization
> 'testing::internal::ActionResultHolder::PerformDefaultAction (const mesos::TaskStatus &)>' requested here
> return ResultHolder::PerformDefaultAction(this, args, call_description);
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-generated-function-mockers.h:81:7:
> note: in instantiation of member function
> 'testing::internal::FunctionMockerBase &)>::UntypedPerformDefaultAction' requested here
> class FunctionMocker : public
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
> note: consider using __builtin_trap() or qualifying pointer with 'volatile'
> return *static_cast::type*>(__null);
> ^
> {noformat}
> The source of the issue here is that {{Status}} is an {{enum}}. In
> {{gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h}} you can find
> the following function:
> {code}
> template
> T Invalid() {
> return *static_cast::type*>(NULL);
> }
> {code}
> This function gets called with the return type of a mocked function. In our
> case, the return type of the mocked function is {{Status}}.
> Attempting to compile the following minimal example with {{clang-3.5}}
> reproduces the error message:
> {code}
> #include
> template
> T invalid() {
> return *static_cast::type *>(nullptr);
> }
> enum E { A, B };
> int main() {
> invalid();
> }
> {code}
> * See it online on [GCC Explorer|https://goo.gl/t1FepZ]
> Note that if the type is not an {{enum}}, the warning is not generated. This
> is why existing mocked functions that return non-{{enum}} types such as
> {{Future}} does not encounter this issue.
> h3. Solutions
> The simplest solution is to add {{-Wno-null-deference}} to
> {{
[jira] [Commented] (MESOS-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643754#comment-14643754
]
haosdent commented on MESOS-3144:
-
Yes, only need update sha256 in your pull request.
> Update Homebrew formula for Mesos (Mac OSX)
> ---
>
> Key: MESOS-3144
> URL: https://issues.apache.org/jira/browse/MESOS-3144
> Project: Mesos
> Issue Type: Task
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Trivial
> Labels: mesosphere, newbie
>
> We have pushed a [pull
> request|https://github.com/Homebrew/homebrew/pull/42099] to Homebrew for the
> new 0.23 formula.
> Once accepted, we must verify that this works on a Mac OSX device.
> This would also be a great time to ensure our documentation is up-to-date.
> Currently, the Homebrew check fails, as they have deprecated SHA-1 checksums:
> {noformat}
> Error Message
> failed: brew audit mesos
> Stacktrace
> Error: 7 problems in 1 formula
> mesos:
> * Stable resource "protobuf": SHA1 checksums are deprecated, please use
> SHA256
> * Stable resource "python-gflags": SHA1 checksums are deprecated, please use
> SHA256
> * Stable resource "six": SHA1 checksums are deprecated, please use SHA256
> * Stable resource "google-apputils": SHA1 checksums are deprecated, please
> use SHA256
> * Stable resource "python-dateutil": SHA1 checksums are deprecated, please
> use SHA256
> * Stable resource "boto": SHA1 checksums are deprecated, please use SHA256
> * Stable resource "pytz": SHA1 checksums are deprecated, please use SHA256
> {noformat}
> Don't know enough about Homebrew to really figure out what is going on here;
> nor how to fix this.
> The Mesos SHA-256 has been correctly entered and computed via the [Online
> SHA/MD5 calculator|https://md5file.com/calculator].
> I guess, we should go download the packages and compute their SHA-256 and/or
> research from the respective download sites whether they publish the SHA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3162) Provide a means to check http connection equality for streaming connections.
Benjamin Mahler created MESOS-3162: -- Summary: Provide a means to check http connection equality for streaming connections. Key: MESOS-3162 URL: https://issues.apache.org/jira/browse/MESOS-3162 Project: Mesos Issue Type: Task Components: libprocess Reporter: Benjamin Mahler Assignee: Benjamin Mahler If one uses an http::Pipe::Writer to stream a response, one cannot compare the writer with another to see if the connection has changed. This is useful for example, in the master's http api when there is asynchronous disconnection logic. When we handle the disconnection, it's possible for the scheduler to have re-subscribed, and so the master needs to tell if the disconnection event is relevant for the current connection before taking action. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2757) Add -> operator for Option, Try, Result, Future.
[ https://issues.apache.org/jira/browse/MESOS-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-2757: --- Sprint: Twitter Mesos Q3 Sprint 2 > Add -> operator for Option, Try, Result, Future. > > > Key: MESOS-2757 > URL: https://issues.apache.org/jira/browse/MESOS-2757 > Project: Mesos > Issue Type: Improvement > Components: libprocess, stout >Reporter: Joris Van Remoortere >Assignee: Benjamin Mahler > Labels: c++11, mesosphere, option, stout, twitter > > Let's add operator overloads to Option to allow access to the underlying T > using the `->` operator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3161) Document using the gold linker for faster development on linux.
Benjamin Mahler created MESOS-3161:
--
Summary: Document using the gold linker for faster development on
linux.
Key: MESOS-3161
URL: https://issues.apache.org/jira/browse/MESOS-3161
Project: Mesos
Issue Type: Improvement
Components: build, documentation
Reporter: Benjamin Mahler
The [gold linker|https://en.wikipedia.org/wiki/Gold_(linker)] seems to provide
a decent speedup (about ~20%) on a parallel build. From a quick test:
{noformat: title=timings for make check -j24 w/ 24 hyperthreaded cores}
gold:
real7m18.526s
user81m21.213s
sys 5m17.224s
default ld:
real9m7.908s
user85m13.466s
sys 5m52.199s
{noformat}
On CentOS 5 w/ devtoolset-2:
{noformat}
sudo /usr/sbin/alternatives --altdir /opt/rh/devtoolset-2/root/etc/alternatives
--admindir /opt/rh/devtoolset-2/root/var/lib/alternatives --set ld
/opt/rh/devtoolset-2/root/usr/bin/ld.gold
{noformat}
Ideally we could this out on the website, with instructions for each OS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3161) Document using the gold linker for faster development on linux.
[
https://issues.apache.org/jira/browse/MESOS-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-3161:
---
Description:
The [gold linker|https://en.wikipedia.org/wiki/Gold_(linker)] seems to provide
a decent speedup (about ~20%) on a parallel build. From a quick test:
{noformat: title=timings for make check -j24 GTEST_FILTER="" w/ 24
hyperthreaded cores}
gold:
real7m18.526s
user81m21.213s
sys 5m17.224s
default ld:
real9m7.908s
user85m13.466s
sys 5m52.199s
{noformat}
On CentOS 5 w/ devtoolset-2:
{noformat}
sudo /usr/sbin/alternatives --altdir /opt/rh/devtoolset-2/root/etc/alternatives
--admindir /opt/rh/devtoolset-2/root/var/lib/alternatives --set ld
/opt/rh/devtoolset-2/root/usr/bin/ld.gold
{noformat}
Ideally we could this out on the website, with instructions for each OS.
was:
The [gold linker|https://en.wikipedia.org/wiki/Gold_(linker)] seems to provide
a decent speedup (about ~20%) on a parallel build. From a quick test:
{noformat: title=timings for make check -j24 w/ 24 hyperthreaded cores}
gold:
real7m18.526s
user81m21.213s
sys 5m17.224s
default ld:
real9m7.908s
user85m13.466s
sys 5m52.199s
{noformat}
On CentOS 5 w/ devtoolset-2:
{noformat}
sudo /usr/sbin/alternatives --altdir /opt/rh/devtoolset-2/root/etc/alternatives
--admindir /opt/rh/devtoolset-2/root/var/lib/alternatives --set ld
/opt/rh/devtoolset-2/root/usr/bin/ld.gold
{noformat}
Ideally we could this out on the website, with instructions for each OS.
> Document using the gold linker for faster development on linux.
> ---
>
> Key: MESOS-3161
> URL: https://issues.apache.org/jira/browse/MESOS-3161
> Project: Mesos
> Issue Type: Improvement
> Components: build, documentation
>Reporter: Benjamin Mahler
> Labels: newbie
>
> The [gold linker|https://en.wikipedia.org/wiki/Gold_(linker)] seems to
> provide a decent speedup (about ~20%) on a parallel build. From a quick test:
> {noformat: title=timings for make check -j24 GTEST_FILTER="" w/ 24
> hyperthreaded cores}
> gold:
> real 7m18.526s
> user 81m21.213s
> sys 5m17.224s
> default ld:
> real 9m7.908s
> user 85m13.466s
> sys 5m52.199s
> {noformat}
> On CentOS 5 w/ devtoolset-2:
> {noformat}
> sudo /usr/sbin/alternatives --altdir
> /opt/rh/devtoolset-2/root/etc/alternatives --admindir
> /opt/rh/devtoolset-2/root/var/lib/alternatives --set ld
> /opt/rh/devtoolset-2/root/usr/bin/ld.gold
> {noformat}
> Ideally we could this out on the website, with instructions for each OS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3151) Reservation Test failed
[
https://issues.apache.org/jira/browse/MESOS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jihun Kang reassigned MESOS-3151:
-
Assignee: Jihun Kang
> Reservation Test failed
> ---
>
> Key: MESOS-3151
> URL: https://issues.apache.org/jira/browse/MESOS-3151
> Project: Mesos
> Issue Type: Bug
> Environment: Ubuntu 14.04.2
> IBM JDK 1.7.0 SR8
>Reporter: Jihun Kang
>Assignee: Jihun Kang
>
> Here is the details.
> {noformat}
> [ RUN ]
> ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes
> ../../src/tests/reservation_tests.cpp:1055: Failure
> Value of: Resources(offer.resources()).contains(unreserved + unreservedDisk)
> Actual: false
> Expected: true
> 2015-07-27
> 17:31:16,280:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
> Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2015-07-27
> 17:31:19,617:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
> Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2015-07-27
> 17:31:22,951:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
> Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2015-07-27
> 17:31:26,288:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
> Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> ../../src/tests/reservation_tests.cpp:1076: Failure
> Failed to wait 15secs for message1
> *** Aborted at 1437985889 (unix time) try "date -d @1437985889" if you are
> using GNU date ***
> PC: @0x0 (unknown)
> ../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
> Actual function call count doesn't match EXPECT_CALL(filter->mock,
> filter(testing::A()))...
> Expected args: message matcher (8-byte object ,
> 1-byte object <61>, 1-byte object )
> Expected: to be called once
>Actual: never called - unsatisfied and active
> ../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
> Actual function call count doesn't match EXPECT_CALL(filter->mock,
> filter(testing::A()))...
> Expected args: message matcher (8-byte object ,
> 1-byte object <61>, 1-byte object )
> Expected: to be called once
>Actual: never called - unsatisfied and active
> [ FAILED ]
> ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes (15354
> ms)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-2757) Can't Use -> operator with Option, Try, Result, Future
[ https://issues.apache.org/jira/browse/MESOS-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler reassigned MESOS-2757: -- Assignee: Benjamin Mahler (was: Joris Van Remoortere) > Can't Use -> operator with Option, Try, Result, Future > -- > > Key: MESOS-2757 > URL: https://issues.apache.org/jira/browse/MESOS-2757 > Project: Mesos > Issue Type: Improvement > Components: stout >Reporter: Joris Van Remoortere >Assignee: Benjamin Mahler > Labels: c++11, mesosphere, option, stout > > Let's add operator overloads to Option to allow access to the underlying T > using the `->` operator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2880) Update Frameworkinfo.capabilities on framework re-registration
[ https://issues.apache.org/jira/browse/MESOS-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643643#comment-14643643 ] Vinod Kone commented on MESOS-2880: --- Part 1.1 has been committed. To complete Part 1, need a test for allocator changes. commit 0b2853d1bd59f9120c77c96f6fc208680fe1c19d Author: Aditi Dixit Date: Mon Jul 27 17:07:55 2015 -0700 Updated Frameworkinfo.capabilities on framework re-registration to support adding capabilities. This updates both the master as well as the allocator. Added test for master. Review: https://reviews.apache.org/r/35797 > Update Frameworkinfo.capabilities on framework re-registration > -- > > Key: MESOS-2880 > URL: https://issues.apache.org/jira/browse/MESOS-2880 > Project: Mesos > Issue Type: Improvement >Reporter: Vinod Kone >Assignee: Aditi Dixit > > Part 1: Add support for adding capabilities. This should be straightforward. > Part 2: Add support for removing capabilities. This is a bit tricky because > we need to deal with exiting tasks and allocations for revocable resources. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3160) CgroupsAnyHierarchyMemoryPressureTest.ROOT_IncreaseUnlockedRSS Flaky
Paul Brett created MESOS-3160: - Summary: CgroupsAnyHierarchyMemoryPressureTest.ROOT_IncreaseUnlockedRSS Flaky Key: MESOS-3160 URL: https://issues.apache.org/jira/browse/MESOS-3160 Project: Mesos Issue Type: Bug Affects Versions: 0.24.0 Reporter: Paul Brett Test will occasionally with: [ RUN ] CgroupsAnyHierarchyMemoryPressureTest.ROOT_IncreaseUnlockedRSS ../../src/tests/containerizer/cgroups_tests.cpp:1103: Failure helper.increaseRSS(getpagesize()): Failed to sync with the subprocess ../../src/tests/containerizer/cgroups_tests.cpp:1103: Failure helper.increaseRSS(getpagesize()): The subprocess has not been spawned yet [ FAILED ] CgroupsAnyHierarchyMemoryPressureTest.ROOT_IncreaseUnlockedRSS (223 ms) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3141) Compiler warning when mocking function type has an enum return type.
[
https://issues.apache.org/jira/browse/MESOS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643545#comment-14643545
]
Michael Park commented on MESOS-3141:
-
CC [~derekchiang]
> Compiler warning when mocking function type has an enum return type.
>
>
> Key: MESOS-3141
> URL: https://issues.apache.org/jira/browse/MESOS-3141
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Michael Park
>Assignee: haosdent
> Labels: mesosphere
>
> The purpose of this ticket is to document a very cryptic error message
> (actually a warning that gets propagated by {{-Werror}}) that gets generated
> by {{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
> innocent-looking function.
> h3. Problem
> The following code is attempting to mock a {{MesosExecutorDriver}}:
> {code}
> class MockMesosExecutorDriver : public MesosExecutorDriver {
> public:
> MockMesosExecutorDriver(mesos::Executor* executor)
> : MesosExecutorDriver(executor) {}
> MOCK_METHOD1(sendStatusUpdate, Status(const TaskStatus&));
> };
> {code}
> The above code generates the following error message:
> {noformat}
> In file included from
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58:
> In file included from
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46:
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
> error: indirection of non-volatile null pointer will be deleted, not trap
> [-Werror,-Wnull-dereference]
> return *static_cast::type*>(__null);
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:78:22:
> note: in instantiation of function template specialization
> 'testing::internal::Invalid' requested here
> return internal::Invalid();
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
> note: in instantiation of member function
> 'testing::internal::BuiltInDefaultValue::Get' requested here
> internal::BuiltInDefaultValue::Get() : *value_;
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
> note: in instantiation of member function
> 'testing::DefaultValue::Get' requested here
> return DefaultValue::Get();
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
> note: in instantiation of member function
> 'testing::internal::FunctionMockerBase &)>::PerformDefaultAction' requested here
> func_mocker->PerformDefaultAction(args, call_description));
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1448:26:
> note: in instantiation of function template specialization
> 'testing::internal::ActionResultHolder::PerformDefaultAction (const mesos::TaskStatus &)>' requested here
> return ResultHolder::PerformDefaultAction(this, args, call_description);
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-generated-function-mockers.h:81:7:
> note: in instantiation of member function
> 'testing::internal::FunctionMockerBase &)>::UntypedPerformDefaultAction' requested here
> class FunctionMocker : public
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
> note: consider using __builtin_trap() or qualifying pointer with 'volatile'
> return *static_cast::type*>(__null);
> ^
> {noformat}
> The source of the issue here is that {{Status}} is an {{enum}}. In
> {{gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h}} you can find
> the following function:
> {code}
> template
> T Invalid() {
> return *static_cast::type*>(NULL);
> }
> {code}
> This function gets called with the return type of a mocked function. In our
> case, the return type of the mocked function is {{Status}}.
> Attempting to compile the following minimal example with {{clang-3.5}}
> reproduces the error message:
> {code}
> #include
> template
> T invalid() {
> return *static_cast::type *>(nullptr);
> }
> enum E { A, B };
> int main() {
> invalid();
> }
> {code}
> * See it online on [GCC Explorer|https://goo.gl/t1FepZ]
> Note that if the type is not an {{enum}}, the warning is not generated. This
> is why existing mocked functions that return non-{{enum}} types such as
> {{Future}} does not encounter this issue.
> h3. Solutions
> The simplest solution is to add {{-Wno-null-deference}} to
> {{mesos_tests_CPPFLAGS}} in {{src/Makefile.am}}.
> {code}
> mesos_tests_CPPFLA
[jira] [Updated] (MESOS-3141) Compiler warning when mocking function type has an enum return type.
[
https://issues.apache.org/jira/browse/MESOS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Park updated MESOS-3141:
Description:
The purpose of this ticket is to document a very cryptic error message
(actually a warning that gets propagated by {{-Werror}}) that gets generated by
{{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
innocent-looking function.
h3. Problem
The following code is attempting to mock a {{MesosExecutorDriver}}:
{code}
class MockMesosExecutorDriver : public MesosExecutorDriver {
public:
MockMesosExecutorDriver(mesos::Executor* executor)
: MesosExecutorDriver(executor) {}
MOCK_METHOD1(sendStatusUpdate, Status(const TaskStatus&));
};
{code}
The above code generates the following error message:
{noformat}
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58:
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46:
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
error: indirection of non-volatile null pointer will be deleted, not trap
[-Werror,-Wnull-dereference]
return *static_cast::type*>(__null);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:78:22:
note: in instantiation of function template specialization
'testing::internal::Invalid' requested here
return internal::Invalid();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
note: in instantiation of member function
'testing::internal::BuiltInDefaultValue::Get' requested here
internal::BuiltInDefaultValue::Get() : *value_;
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
note: in instantiation of member function
'testing::DefaultValue::Get' requested here
return DefaultValue::Get();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
note: in instantiation of member function
'testing::internal::FunctionMockerBase::PerformDefaultAction' requested here
func_mocker->PerformDefaultAction(args, call_description));
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1448:26:
note: in instantiation of function template specialization
'testing::internal::ActionResultHolder::PerformDefaultAction' requested here
return ResultHolder::PerformDefaultAction(this, args, call_description);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-generated-function-mockers.h:81:7:
note: in instantiation of member function
'testing::internal::FunctionMockerBase::UntypedPerformDefaultAction' requested here
class FunctionMocker : public
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
note: consider using __builtin_trap() or qualifying pointer with 'volatile'
return *static_cast::type*>(__null);
^
{noformat}
The source of the issue here is that {{Status}} is an {{enum}}. In
{{gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h}} you can find the
following function:
{code}
template
T Invalid() {
return *static_cast::type*>(NULL);
}
{code}
This function gets called with the return type of a mocked function. In our
case, the return type of the mocked function is {{Status}}.
Attempting to compile the following minimal example with {{clang-3.5}}
reproduces the error message:
{code}
#include
template
T invalid() {
return *static_cast::type *>(nullptr);
}
enum E { A, B };
int main() {
invalid();
}
{code}
* See it online on [GCC Explorer|https://goo.gl/t1FepZ]
Note that if the type is not an {{enum}}, the warning is not generated. This is
why existing mocked functions that return non-{{enum}} types such as
{{Future}} does not encounter this issue.
h3. Solutions
The simplest solution is to add {{-Wno-null-deference}} to
{{mesos_tests_CPPFLAGS}} in {{src/Makefile.am}}.
{code}
mesos_tests_CPPFLAGS = $(MESOS_CPPFLAGS) -Wno-null-dereference
{code}
Another solution is to upgrade {{gmock}} from *1.6* to *1.7* to as I believe
this problem is solved in the newer versions.
was:
The purpose of this ticket is to document a very cryptic error message
(actually a warning that gets propagated by {{-Werror}}) that gets generated by
{{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
innocent-looking function.
h3. Problem
The following code is attempting to mock a {{MesosExecutorDriver}}:
{code}
class MockMesosExecutorDriver : public MesosExecutorDriver {
public:
MockMesosExecutorDriver(mesos::Executor* executor)
: MesosExecutorDriver(executor) {}
MOCK_METH
[jira] [Updated] (MESOS-3103) Separate OS-specific code in the libprocess library
[
https://issues.apache.org/jira/browse/MESOS-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Wu updated MESOS-3103:
-
Assignee: Alex Clemmer (was: Joseph Wu)
> Separate OS-specific code in the libprocess library
> ---
>
> Key: MESOS-3103
> URL: https://issues.apache.org/jira/browse/MESOS-3103
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Joseph Wu
>Assignee: Alex Clemmer
> Labels: mesosphere
>
> This issue tracks changes for all files under
> {{3rdparty/libprocess/include/}} and {{3rdparty/libprocess/src}}.
> The changes will be based on this commit:
> https://github.com/hausdorff/mesos/commit/b862f66c6ff58c115a009513621e5128cb734d52#diff-a6d038bad64b154996452bec020cfa7c
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643535#comment-14643535 ] Cody Roseborough commented on MESOS-3155: - Added more details to the description. I'd be interested to know what sorts of things you have discussed related to this. > Add a containerizer and executor that simulate the launching of tasks. > --- > > Key: MESOS-3155 > URL: https://issues.apache.org/jira/browse/MESOS-3155 > Project: Mesos > Issue Type: Improvement > Components: containerization, slave >Reporter: Cody Roseborough >Assignee: Cody Roseborough >Priority: Minor > > This could have a user-defined configuration file. This would allow users to > locally test frameworks against a large, simulated cluster using mesos-local. > The Simulator Containerizer (SC) is a containerizer that can be used in > conjunction with mesos-local to exercise frameworks at a large scale without > launching a large cluster. The SC launches a "fake" executor instead of the > one specified by the tasks, in order to avoid using actual resources. The SC > provides normal tasks updates as well as configurable task options via a > configuration JSON file. > Some of the options available for configuration might be length or failure > rate. > Other points of contact for this are: [~lukeleslie], [~derekchiang] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough updated MESOS-3155: Description: The Simulator Containerizer (SC) is a containerizer that can be used in conjunction with mesos-local to exercise frameworks at a large scale without launching a large cluster. The SC launches a "fake" executor instead of the one specified by the tasks, in order to avoid using actual resources. The SC provides normal tasks updates as well as configurable task options via a configuration JSON file. Some of the options available for configuration might be length or failure rate. Other points of contact for this are: [~lukeleslie], [~derekchiang] was: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. The Simulator Containerizer (SC) is a containerizer that can be used in conjunction with mesos-local to exercise frameworks at a large scale without launching a large cluster. The SC launches a "fake" executor instead of the one specified by the tasks, in order to avoid using actual resources. The SC provides normal tasks updates as well as configurable task options via a configuration JSON file. Some of the options available for configuration might be length or failure rate. Other points of contact for this are: [~lukeleslie], [~derekchiang] > Add a containerizer and executor that simulate the launching of tasks. > --- > > Key: MESOS-3155 > URL: https://issues.apache.org/jira/browse/MESOS-3155 > Project: Mesos > Issue Type: Improvement > Components: containerization, slave >Reporter: Cody Roseborough >Assignee: Cody Roseborough >Priority: Minor > > The Simulator Containerizer (SC) is a containerizer that can be used in > conjunction with mesos-local to exercise frameworks at a large scale without > launching a large cluster. The SC launches a "fake" executor instead of the > one specified by the tasks, in order to avoid using actual resources. The SC > provides normal tasks updates as well as configurable task options via a > configuration JSON file. > Some of the options available for configuration might be length or failure > rate. > Other points of contact for this are: [~lukeleslie], [~derekchiang] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough updated MESOS-3155: Description: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. The Simulator Containerizer (SC) is a containerizer that can be used in conjunction with mesos-local to exercise frameworks at a large scale without launching a large cluster. The SC launches a "fake" executor instead of the one specified by the tasks, in order to avoid using actual resources. The SC provides normal tasks updates as well as configurable task options via a configuration JSON file. Some of the options available for configuration might be length or failure rate. Other points of contact for this are: [~lukeleslie], [~derekchiang] was: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Other points of contact for this are: [~lukeleslie], [~derekchiang] > Add a containerizer and executor that simulate the launching of tasks. > --- > > Key: MESOS-3155 > URL: https://issues.apache.org/jira/browse/MESOS-3155 > Project: Mesos > Issue Type: Improvement > Components: containerization, slave >Reporter: Cody Roseborough >Assignee: Cody Roseborough >Priority: Minor > > This could have a user-defined configuration file. This would allow users to > locally test frameworks against a large, simulated cluster using mesos-local. > The Simulator Containerizer (SC) is a containerizer that can be used in > conjunction with mesos-local to exercise frameworks at a large scale without > launching a large cluster. The SC launches a "fake" executor instead of the > one specified by the tasks, in order to avoid using actual resources. The SC > provides normal tasks updates as well as configurable task options via a > configuration JSON file. > Some of the options available for configuration might be length or failure > rate. > Other points of contact for this are: [~lukeleslie], [~derekchiang] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3159) Add metrics counter for preempted executors (due to QoS corrections)
[ https://issues.apache.org/jira/browse/MESOS-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643493#comment-14643493 ] Niklas Quarfot Nielsen commented on MESOS-3159: --- [~jieyu] Does this make sense? And if so, can I get you to shepherd? > Add metrics counter for preempted executors (due to QoS corrections) > > > Key: MESOS-3159 > URL: https://issues.apache.org/jira/browse/MESOS-3159 > Project: Mesos > Issue Type: Improvement >Reporter: Niklas Quarfot Nielsen > > We should keep track of how many containers/executors has been > destroyed/killed due to preemption (due to QoS corrections). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3159) Add metrics counter for preempted executors (due to QoS corrections)
Niklas Quarfot Nielsen created MESOS-3159: - Summary: Add metrics counter for preempted executors (due to QoS corrections) Key: MESOS-3159 URL: https://issues.apache.org/jira/browse/MESOS-3159 Project: Mesos Issue Type: Improvement Reporter: Niklas Quarfot Nielsen We should keep track of how many containers/executors has been destroyed/killed due to preemption (due to QoS corrections). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-786) Update semantics of when framework registered()/reregistered() get called
[ https://issues.apache.org/jira/browse/MESOS-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643366#comment-14643366 ] Yan Xu edited comment on MESOS-786 at 7/27/15 9:41 PM: --- Fixed by MESOS-3088 and MESOS-2910. was (Author: xujyan): This issue is (indirectly) fixed by MESOS-3088. > Update semantics of when framework registered()/reregistered() get called > - > > Key: MESOS-786 > URL: https://issues.apache.org/jira/browse/MESOS-786 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Vinod Kone > > Current semantics: > 1) Framework connects w/ master very first time --> registered() > 2) Framework reconnects w/ same master after a zk blip --> reregistered() > 3) Framework reconnects w/ failed over master --> registered() > 4) Failed over framework connects w/ same master --> registered() > 5) Failed over framework connects w/ failed over master --> registered() > Updated semantics: > Everything same except > 3) Framework reconnects w/ failed over master --> reregistered() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2879) Random recursive_mutex errors in when running make check
[
https://issues.apache.org/jira/browse/MESOS-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joris Van Remoortere updated MESOS-2879:
Shepherd: Benjamin Hindman
Sprint: Mesosphere Sprint 15
Story Points: 1
Component/s: libprocess
> Random recursive_mutex errors in when running make check
>
>
> Key: MESOS-2879
> URL: https://issues.apache.org/jira/browse/MESOS-2879
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Alexander Rojas
>Assignee: Joris Van Remoortere
> Labels: mesosphere, tech-debt
>
> While running make check on OS X, from time to time {{recursive_mutex}}
> errors appear after running all the test successfully. Just one of the
> experience messages actually stops {{make check}} reporting an error.
> The following error messages have been experienced:
> {code}
> libc++abi.dylib: libc++abi.dylib: libc++abi.dylib: libc++abi.dylib:
> libc++abi.dylib: libc++abi.dylib: terminating with uncaught exception of type
> std::__1::system_error: recursive_mutex lock failed: Invalid
> argumentterminating with uncaught exception of type std::__1::system_error:
> recursive_mutex lock failed: Invalid argumentterminating with uncaught
> exception of type std::__1::system_error: recursive_mutex lock failed:
> Invalid argumentterminating with uncaught exception of type
> std::__1::system_error: recursive_mutex lock failed: Invalid
> argumentterminating with uncaught exception of type std::__1::system_error:
> recursive_mutex lock failed: Invalid argumentterminating with uncaught
> exception of type std::__1::system_error: recursive_mutex lock failed:
> Invalid argument
> *** Aborted at 1434553937 (unix time) try "date -d @1434553937" if you are
> using GNU date ***
> {code}
> {code}
> libc++abi.dylib: terminating with uncaught exception of type
> std::__1::system_error: recursive_mutex lock failed: Invalid argument
> *** Aborted at 1434557001 (unix time) try "date -d @1434557001" if you are
> using GNU date ***
> libc++abi.dylib: PC: @ 0x7fff93855286 __pthread_kill
> libc++abi.dylib: *** SIGABRT (@0x7fff93855286) received by PID 88060 (TID
> 0x10fc4) stack trace: ***
> @ 0x7fff8e1d6f1a _sigtramp
> libc++abi.dylib: @0x10fc3f1a8 (unknown)
> libc++abi.dylib: @ 0x7fff979deb53 abort
> libc++abi.dylib: libc++abi.dylib: libc++abi.dylib: terminating with uncaught
> exception of type std::__1::system_error: recursive_mutex lock failed:
> Invalid argumentterminating with uncaught exception of type
> std::__1::system_error: recursive_mutex lock failed: Invalid
> argumentterminating with uncaught exception of type std::__1::system_error:
> recursive_mutex lock failed: Invalid argumentterminating with uncaught
> exception of type std::__1::system_error: recursive_mutex lock failed:
> Invalid argumentterminating with uncaught exception of type
> std::__1::system_error: recursive_mutex lock failed: Invalid
> argumentterminating with uncaught exception of type std::__1::system_error:
> recursive_mutex lock failed: Invalid argumentMaking check in include
> {code}
> {code}
> Assertion failed: (e == 0), function ~recursive_mutex, file
> /SourceCache/libcxx/libcxx-120/src/mutex.cpp, line 82.
> *** Aborted at 1434555685 (unix time) try "date -d @1434555685" if you are
> using GNU date ***
> PC: @ 0x7fff93855286 __pthread_kill
> *** SIGABRT (@0x7fff93855286) received by PID 60235 (TID 0x7fff7ebdc300)
> stack trace: ***
> @ 0x7fff8e1d6f1a _sigtramp
> @0x10b512350 google::CheckNotNull<>()
> @ 0x7fff979deb53 abort
> @ 0x7fff979a6c39 __assert_rtn
> @ 0x7fff9bffdcc9 std::__1::recursive_mutex::~recursive_mutex()
> @0x10b881928 process::ProcessManager::~ProcessManager()
> @0x10b874445 process::ProcessManager::~ProcessManager()
> @0x10b874418 process::finalize()
> @0x10b2f7aec main
> @ 0x7fff98edc5c9 start
> make[5]: *** [check-local] Abort trap: 6
> make[4]: *** [check-am] Error 2
> make[3]: *** [check-recursive] Error 1
> make[2]: *** [check-recursive] Error 1
> make[1]: *** [check] Error 2
> make: *** [check-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-2879) Random recursive_mutex errors in when running make check
[
https://issues.apache.org/jira/browse/MESOS-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joris Van Remoortere reassigned MESOS-2879:
---
Assignee: Joris Van Remoortere
> Random recursive_mutex errors in when running make check
>
>
> Key: MESOS-2879
> URL: https://issues.apache.org/jira/browse/MESOS-2879
> Project: Mesos
> Issue Type: Bug
>Reporter: Alexander Rojas
>Assignee: Joris Van Remoortere
> Labels: mesosphere, tech-debt
>
> While running make check on OS X, from time to time {{recursive_mutex}}
> errors appear after running all the test successfully. Just one of the
> experience messages actually stops {{make check}} reporting an error.
> The following error messages have been experienced:
> {code}
> libc++abi.dylib: libc++abi.dylib: libc++abi.dylib: libc++abi.dylib:
> libc++abi.dylib: libc++abi.dylib: terminating with uncaught exception of type
> std::__1::system_error: recursive_mutex lock failed: Invalid
> argumentterminating with uncaught exception of type std::__1::system_error:
> recursive_mutex lock failed: Invalid argumentterminating with uncaught
> exception of type std::__1::system_error: recursive_mutex lock failed:
> Invalid argumentterminating with uncaught exception of type
> std::__1::system_error: recursive_mutex lock failed: Invalid
> argumentterminating with uncaught exception of type std::__1::system_error:
> recursive_mutex lock failed: Invalid argumentterminating with uncaught
> exception of type std::__1::system_error: recursive_mutex lock failed:
> Invalid argument
> *** Aborted at 1434553937 (unix time) try "date -d @1434553937" if you are
> using GNU date ***
> {code}
> {code}
> libc++abi.dylib: terminating with uncaught exception of type
> std::__1::system_error: recursive_mutex lock failed: Invalid argument
> *** Aborted at 1434557001 (unix time) try "date -d @1434557001" if you are
> using GNU date ***
> libc++abi.dylib: PC: @ 0x7fff93855286 __pthread_kill
> libc++abi.dylib: *** SIGABRT (@0x7fff93855286) received by PID 88060 (TID
> 0x10fc4) stack trace: ***
> @ 0x7fff8e1d6f1a _sigtramp
> libc++abi.dylib: @0x10fc3f1a8 (unknown)
> libc++abi.dylib: @ 0x7fff979deb53 abort
> libc++abi.dylib: libc++abi.dylib: libc++abi.dylib: terminating with uncaught
> exception of type std::__1::system_error: recursive_mutex lock failed:
> Invalid argumentterminating with uncaught exception of type
> std::__1::system_error: recursive_mutex lock failed: Invalid
> argumentterminating with uncaught exception of type std::__1::system_error:
> recursive_mutex lock failed: Invalid argumentterminating with uncaught
> exception of type std::__1::system_error: recursive_mutex lock failed:
> Invalid argumentterminating with uncaught exception of type
> std::__1::system_error: recursive_mutex lock failed: Invalid
> argumentterminating with uncaught exception of type std::__1::system_error:
> recursive_mutex lock failed: Invalid argumentMaking check in include
> {code}
> {code}
> Assertion failed: (e == 0), function ~recursive_mutex, file
> /SourceCache/libcxx/libcxx-120/src/mutex.cpp, line 82.
> *** Aborted at 1434555685 (unix time) try "date -d @1434555685" if you are
> using GNU date ***
> PC: @ 0x7fff93855286 __pthread_kill
> *** SIGABRT (@0x7fff93855286) received by PID 60235 (TID 0x7fff7ebdc300)
> stack trace: ***
> @ 0x7fff8e1d6f1a _sigtramp
> @0x10b512350 google::CheckNotNull<>()
> @ 0x7fff979deb53 abort
> @ 0x7fff979a6c39 __assert_rtn
> @ 0x7fff9bffdcc9 std::__1::recursive_mutex::~recursive_mutex()
> @0x10b881928 process::ProcessManager::~ProcessManager()
> @0x10b874445 process::ProcessManager::~ProcessManager()
> @0x10b874418 process::finalize()
> @0x10b2f7aec main
> @ 0x7fff98edc5c9 start
> make[5]: *** [check-local] Abort trap: 6
> make[4]: *** [check-am] Error 2
> make[3]: *** [check-recursive] Error 1
> make[2]: *** [check-recursive] Error 1
> make[1]: *** [check] Error 2
> make: *** [check-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3158) Libprocess Process: Join runqueue workers during finalization
Joris Van Remoortere created MESOS-3158: --- Summary: Libprocess Process: Join runqueue workers during finalization Key: MESOS-3158 URL: https://issues.apache.org/jira/browse/MESOS-3158 Project: Mesos Issue Type: Improvement Components: libprocess Reporter: Joris Van Remoortere The lack of synchronization between ProcessManager destruction and the thread pool threads running the queued processes means that the shared state that is part of the ProcessManager gets destroyed prematurely. Synchronizing the ProcessManager destructor with draining the work queues and stopping the workers will allow us to not require leaking the shared state to avoid use beyond destruction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3156) Inconsistency between mesos master UI and mesos slave /metrics/snapshot
[
https://issues.apache.org/jira/browse/MESOS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Otaegui updated MESOS-3156:
-
Description:
We recently began doing some tests with kibana to graph some of the stats of
the slaves and the masters.
We found something pretty odd:
Test case:
In my example my slave has 1840 mb free, of which mesos reserves 920mb for
tasks.
1. create N (in my case 14) marathon tasks with the following configuration
{noformat}
command: while true; do sleep 1 ; echo "heloo"; done
mem: 64mb
cpu: 0.1
{noformat}
2. check the mesos master web UI
{noformat}
Total 3 920 MB
Used1.4 896 MB
{noformat}
3. check the :5051/metrics/snapshot
{noformat}
"slave/mem_total":920,
"slave/mem_used”:1344
{noformat}
Is this correct? I discussed this issue on the DCOS community slack channel
with Adam and he told me that the correct numbers are in the #3 he explained
that for each task, there are about 32mb + 0.1 cpu that is assigned to a
default executor.
I also changed the slave to enable cgroups_limit_swap:
{noformat}
/etc/mesos-slave/
├── attributes
├── cgroups_limit_swap
├── containerizers
├── executor_registration_timeout
├── hostname
├── isolation
├── resources
└── work_dir
{noformat}
{noformat}
cat /etc/mesos-slave/cgroups_limit_swap
true
{noformat}
{noformat}
ps ax | grep slave
26810 ?Ssl0:02 /usr/sbin/mesos-slave
--master=zk://172.41.5.11:2181/mesos --ip=172.41.6.11 --cgroups_limit_swap=true
--containerizers=docker,mesos --executor_registration_timeout=30mins
--hostname=172.41.6.11 --isolation=cgroups/cpu,cgroups/mem --work_dir=/tmp/mesos
{noformat}
was:
We recently began doing some tests with kibana to graph some of the stats of
the slaves and the masters.
We found something pretty odd:
Test case:
In my example my slave has 1840 mb free, of which mesos reserves 920mb for
tasks.
1. create N (in my case 14) marathon tasks with the following configuration
{noformat}
command: while true; do sleep 1 ; echo "heloo"; done
mem: 64mb
cpu: 0.1
{noformat}
2. check the mesos master web UI
{noformat}
Total 3 920 MB
Used1.4 896 MB
{noformat}
3. check the :5051/metrics/snapshot
{noformat}
"slave/mem_total":920,
"slave/mem_used”:1344
{noformat}
> Inconsistency between mesos master UI and mesos slave /metrics/snapshot
> ---
>
> Key: MESOS-3156
> URL: https://issues.apache.org/jira/browse/MESOS-3156
> Project: Mesos
> Issue Type: Bug
> Components: master, slave, statistics, webui
>Affects Versions: 0.22.1
> Environment: Test environment runs on vagrant
> Master: Centos 7 + mesos 0.22.1 + marathon 0.9.0 = 1 vcpu + 1gb ram
> Slave: Centos 7 + mesos 0.22.1 = 3vcpus + 2048mb
> (1 master + 1 slave)
>Reporter: Sebastian Otaegui
>
> We recently began doing some tests with kibana to graph some of the stats of
> the slaves and the masters.
> We found something pretty odd:
> Test case:
> In my example my slave has 1840 mb free, of which mesos reserves 920mb for
> tasks.
> 1. create N (in my case 14) marathon tasks with the following configuration
> {noformat}
> command: while true; do sleep 1 ; echo "heloo"; done
> mem: 64mb
> cpu: 0.1
> {noformat}
> 2. check the mesos master web UI
> {noformat}
> Total 3 920 MB
> Used 1.4 896 MB
> {noformat}
> 3. check the :5051/metrics/snapshot
> {noformat}
> "slave/mem_total":920,
> "slave/mem_used”:1344
> {noformat}
> Is this correct? I discussed this issue on the DCOS community slack channel
> with Adam and he told me that the correct numbers are in the #3 he explained
> that for each task, there are about 32mb + 0.1 cpu that is assigned to a
> default executor.
> I also changed the slave to enable cgroups_limit_swap:
> {noformat}
> /etc/mesos-slave/
> ├── attributes
> ├── cgroups_limit_swap
> ├── containerizers
> ├── executor_registration_timeout
> ├── hostname
> ├── isolation
> ├── resources
> └── work_dir
> {noformat}
> {noformat}
> cat /etc/mesos-slave/cgroups_limit_swap
> true
> {noformat}
> {noformat}
> ps ax | grep slave
> 26810 ?Ssl0:02 /usr/sbin/mesos-slave
> --master=zk://172.41.5.11:2181/mesos --ip=172.41.6.11
> --cgroups_limit_swap=true --containerizers=docker,mesos
> --executor_registration_timeout=30mins --hostname=172.41.6.11
> --isolation=cgroups/cpu,cgroups/mem --work_dir=/tmp/mesos
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3157) only perform batch resource allocations
[
https://issues.apache.org/jira/browse/MESOS-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643395#comment-14643395
]
James Peach commented on MESOS-3157:
I can post a patch for this. I need a shepherd and advice on whether this
should be a configuration option, or whether the event-triggered allocation
should just be removed.
> only perform batch resource allocations
> ---
>
> Key: MESOS-3157
> URL: https://issues.apache.org/jira/browse/MESOS-3157
> Project: Mesos
> Issue Type: Bug
> Components: allocation
>Reporter: James Peach
>Assignee: James Peach
>
> Our deployment environments have a lot of churn, with many short-live
> frameworks that often revive offers. Running the allocator takes a long time
> (from seconds up to minutes).
> In this situation, event-triggered allocation causes the event queue in the
> allocator process to get very long, and the allocator effectively becomes
> unresponsive (eg. a revive offers message takes too long to come to the head
> of the queue).
> We have been running a patch to remove all the event-triggered allocations
> and only allocate from the batch task
> {{HierarchicalAllocatorProcess::batch}}. This works great and really improves
> responsiveness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3157) only perform batch resource allocations
James Peach created MESOS-3157:
--
Summary: only perform batch resource allocations
Key: MESOS-3157
URL: https://issues.apache.org/jira/browse/MESOS-3157
Project: Mesos
Issue Type: Bug
Components: allocation
Reporter: James Peach
Our deployment environments have a lot of churn, with many short-live
frameworks that often revive offers. Running the allocator takes a long time
(from seconds up to minutes).
In this situation, event-triggered allocation causes the event queue in the
allocator process to get very long, and the allocator effectively becomes
unresponsive (eg. a revive offers message takes too long to come to the head of
the queue).
We have been running a patch to remove all the event-triggered allocations and
only allocate from the batch task {{HierarchicalAllocatorProcess::batch}}. This
works great and really improves responsiveness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3157) only perform batch resource allocations
[
https://issues.apache.org/jira/browse/MESOS-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned MESOS-3157:
--
Assignee: James Peach
> only perform batch resource allocations
> ---
>
> Key: MESOS-3157
> URL: https://issues.apache.org/jira/browse/MESOS-3157
> Project: Mesos
> Issue Type: Bug
> Components: allocation
>Reporter: James Peach
>Assignee: James Peach
>
> Our deployment environments have a lot of churn, with many short-live
> frameworks that often revive offers. Running the allocator takes a long time
> (from seconds up to minutes).
> In this situation, event-triggered allocation causes the event queue in the
> allocator process to get very long, and the allocator effectively becomes
> unresponsive (eg. a revive offers message takes too long to come to the head
> of the queue).
> We have been running a patch to remove all the event-triggered allocations
> and only allocate from the batch task
> {{HierarchicalAllocatorProcess::batch}}. This works great and really improves
> responsiveness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3156) Inconsistency between mesos master UI and mesos slave /metrics/snapshot
Sebastian Otaegui created MESOS-3156:
Summary: Inconsistency between mesos master UI and mesos slave
/metrics/snapshot
Key: MESOS-3156
URL: https://issues.apache.org/jira/browse/MESOS-3156
Project: Mesos
Issue Type: Bug
Components: master, slave, statistics, webui
Affects Versions: 0.22.1
Environment: Test environment runs on vagrant
Master: Centos 7 + mesos 0.22.1 + marathon 0.9.0 = 1 vcpu + 1gb ram
Slave: Centos 7 + mesos 0.22.1 = 3vcpus + 2048mb
(1 master + 1 slave)
Reporter: Sebastian Otaegui
We recently began doing some tests with kibana to graph some of the stats of
the slaves and the masters.
We found something pretty odd:
Test case:
In my example my slave has 1840 mb free, of which mesos reserves 920mb for
tasks.
1. create N (in my case 14) marathon tasks with the following configuration
{noformat}
command: while true; do sleep 1 ; echo "heloo"; done
mem: 64mb
cpu: 0.1
{noformat}
2. check the mesos master web UI
{noformat}
Total 3 920 MB
Used1.4 896 MB
{noformat}
3. check the :5051/metrics/snapshot
{noformat}
"slave/mem_total":920,
"slave/mem_used”:1344
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643379#comment-14643379 ] James Peach commented on MESOS-3155: Any more details about this? We have been discussing the need for this (calling it the null mslave). > Add a containerizer and executor that simulate the launching of tasks. > --- > > Key: MESOS-3155 > URL: https://issues.apache.org/jira/browse/MESOS-3155 > Project: Mesos > Issue Type: Improvement > Components: containerization, slave >Reporter: Cody Roseborough >Assignee: Cody Roseborough >Priority: Minor > > This could have a user-defined configuration file. This would allow users to > locally test frameworks against a large, simulated cluster using mesos-local. > Other points of contact for this are: [~lukeleslie], [~derekchiang] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-786) Update semantics of when framework registered()/reregistered() get called
[ https://issues.apache.org/jira/browse/MESOS-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643366#comment-14643366 ] Yan Xu commented on MESOS-786: -- This issue is (indirectly) fixed by MESOS-3088. > Update semantics of when framework registered()/reregistered() get called > - > > Key: MESOS-786 > URL: https://issues.apache.org/jira/browse/MESOS-786 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Vinod Kone > > Current semantics: > 1) Framework connects w/ master very first time --> registered() > 2) Framework reconnects w/ same master after a zk blip --> reregistered() > 3) Framework reconnects w/ failed over master --> registered() > 4) Failed over framework connects w/ same master --> registered() > 5) Failed over framework connects w/ failed over master --> registered() > Updated semantics: > Everything same except > 3) Framework reconnects w/ failed over master --> reregistered() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough updated MESOS-3155: Description: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Other points of contact for this are: [~lukeleslie], [~derekchiang] was: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Other points of contact for this are: > Add a containerizer and executor that simulate the launching of tasks. > --- > > Key: MESOS-3155 > URL: https://issues.apache.org/jira/browse/MESOS-3155 > Project: Mesos > Issue Type: Improvement > Components: containerization, slave >Reporter: Cody Roseborough >Assignee: Cody Roseborough >Priority: Minor > > This could have a user-defined configuration file. This would allow users to > locally test frameworks against a large, simulated cluster using mesos-local. > Other points of contact for this are: [~lukeleslie], [~derekchiang] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough updated MESOS-3155: Description: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Other points of contact for this are: was:This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. > Add a containerizer and executor that simulate the launching of tasks. > --- > > Key: MESOS-3155 > URL: https://issues.apache.org/jira/browse/MESOS-3155 > Project: Mesos > Issue Type: Improvement > Components: containerization, slave >Reporter: Cody Roseborough >Assignee: Cody Roseborough >Priority: Minor > > This could have a user-defined configuration file. This would allow users to > locally test frameworks against a large, simulated cluster using mesos-local. > Other points of contact for this are: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3101) Standardize separation of Windows/Linux-specific OS code
[ https://issues.apache.org/jira/browse/MESOS-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643313#comment-14643313 ] Joseph Wu commented on MESOS-3101: -- You could say that the "review" is where we are doing the work. We're standardizing a refactor, and iterating on the refactor by using ReviewBoard; such that the 50+ files that do eventually get changed (MESOS-3102, MESOS-3103) will be easier. This review only touches about 10 files. Once we're happy with the refactor, then we'll open it up for general review. > Standardize separation of Windows/Linux-specific OS code > > > Key: MESOS-3101 > URL: https://issues.apache.org/jira/browse/MESOS-3101 > Project: Mesos > Issue Type: Task > Components: stout >Reporter: Joseph Wu >Assignee: Joseph Wu > Labels: mesosphere > > There are 50+ files that must be touched to separate OS-specific code. > First, we will standardize the changes by using stout/abort.hpp as an example. > The review/discussion can be found here: > https://reviews.apache.org/r/36625/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3141) Compiler warning when mocking function type has an enum return type.
[
https://issues.apache.org/jira/browse/MESOS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643300#comment-14643300
]
Michael Park commented on MESOS-3141:
-
[~marco-mesos] Unbundling our dependencies have been discussed in the past,
mostly driven by [~cmaloney] and [~benjaminhindman]. I'm not up to date with
the current status and what's coming, so I'll defer to them for a reply.
> Compiler warning when mocking function type has an enum return type.
>
>
> Key: MESOS-3141
> URL: https://issues.apache.org/jira/browse/MESOS-3141
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Michael Park
>Assignee: haosdent
> Labels: mesosphere
>
> The purpose of this ticket is to document a very cryptic error message
> (actually a warning that gets propagated by {{-Werror}}) that gets generated
> by {{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
> innocent-looking function.
> h3. Problem
> The following code is attempting to mock a {{MesosExecutorDriver}}:
> {code}
> class MockMesosExecutorDriver : public MesosExecutorDriver {
> public:
> MockMesosExecutorDriver(mesos::Executor* executor)
> : MesosExecutorDriver(executor) {}
> MOCK_METHOD1(sendStatusUpdate, Status(const TaskStatus&));
> };
> {code}
> The above code generates the following error message:
> {noformat}
> In file included from
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58:
> In file included from
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46:
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
> error: indirection of non-volatile null pointer will be deleted, not trap
> [-Werror,-Wnull-dereference]
> return *static_cast::type*>(__null);
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:78:22:
> note: in instantiation of function template specialization
> 'testing::internal::Invalid' requested here
> return internal::Invalid();
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
> note: in instantiation of member function
> 'testing::internal::BuiltInDefaultValue::Get' requested here
> internal::BuiltInDefaultValue::Get() : *value_;
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
> note: in instantiation of member function
> 'testing::DefaultValue::Get' requested here
> return DefaultValue::Get();
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
> note: in instantiation of member function
> 'testing::internal::FunctionMockerBase &)>::PerformDefaultAction' requested here
> func_mocker->PerformDefaultAction(args, call_description));
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1448:26:
> note: in instantiation of function template specialization
> 'testing::internal::ActionResultHolder::PerformDefaultAction (const mesos::TaskStatus &)>' requested here
> return ResultHolder::PerformDefaultAction(this, args, call_description);
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-generated-function-mockers.h:81:7:
> note: in instantiation of member function
> 'testing::internal::FunctionMockerBase &)>::UntypedPerformDefaultAction' requested here
> class FunctionMocker : public
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
> note: consider using __builtin_trap() or qualifying pointer with 'volatile'
> return *static_cast::type*>(__null);
> ^
> {noformat}
> The source of the issue here is that {{Status}} is an {{enum}}. In
> {{gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h}} you can find
> the following function:
> {code}
> template
> T Invalid() {
> return *static_cast::type*>(NULL);
> }
> {code}
> This function gets called with the return type of a mocked function. In our
> case, the return type of the mocked function is {{Status}}.
> Attempting to compile the following minimal example with {{clang-3.5}}
> reproduces the error message:
> {code}
> #include
> template
> T invalid() {
> return *static_cast::type *>(nullptr);
> }
> enum E { A, B };
> int main() {
> invalid();
> }
> {code}
> * See it online on [GCC Explorer|https://goo.gl/t1FepZ]
> Note that if the type is not an {{enum}}, the warning is not generated. This
> is why existing mocked functions that return non-{{enum}} types s
[jira] [Commented] (MESOS-3141) Compiler warning when mocking function type has an enum return type.
[
https://issues.apache.org/jira/browse/MESOS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643289#comment-14643289
]
Michael Park commented on MESOS-3141:
-
[~haosd...@gmail.com] Thanks for doing this! From what I see on Reviewboard, it
looks like the problem is only with {{Mesos ReviewBot}} and the fact that
{{./support/apply-review.sh}} doesn't support applying patches that involve
binary or something? I don't see any complaints from Reviewboard itself. Am I
missing something?
> Compiler warning when mocking function type has an enum return type.
>
>
> Key: MESOS-3141
> URL: https://issues.apache.org/jira/browse/MESOS-3141
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Michael Park
>Assignee: haosdent
> Labels: mesosphere
>
> The purpose of this ticket is to document a very cryptic error message
> (actually a warning that gets propagated by {{-Werror}}) that gets generated
> by {{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
> innocent-looking function.
> h3. Problem
> The following code is attempting to mock a {{MesosExecutorDriver}}:
> {code}
> class MockMesosExecutorDriver : public MesosExecutorDriver {
> public:
> MockMesosExecutorDriver(mesos::Executor* executor)
> : MesosExecutorDriver(executor) {}
> MOCK_METHOD1(sendStatusUpdate, Status(const TaskStatus&));
> };
> {code}
> The above code generates the following error message:
> {noformat}
> In file included from
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58:
> In file included from
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46:
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
> error: indirection of non-volatile null pointer will be deleted, not trap
> [-Werror,-Wnull-dereference]
> return *static_cast::type*>(__null);
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:78:22:
> note: in instantiation of function template specialization
> 'testing::internal::Invalid' requested here
> return internal::Invalid();
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
> note: in instantiation of member function
> 'testing::internal::BuiltInDefaultValue::Get' requested here
> internal::BuiltInDefaultValue::Get() : *value_;
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
> note: in instantiation of member function
> 'testing::DefaultValue::Get' requested here
> return DefaultValue::Get();
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
> note: in instantiation of member function
> 'testing::internal::FunctionMockerBase &)>::PerformDefaultAction' requested here
> func_mocker->PerformDefaultAction(args, call_description));
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1448:26:
> note: in instantiation of function template specialization
> 'testing::internal::ActionResultHolder::PerformDefaultAction (const mesos::TaskStatus &)>' requested here
> return ResultHolder::PerformDefaultAction(this, args, call_description);
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-generated-function-mockers.h:81:7:
> note: in instantiation of member function
> 'testing::internal::FunctionMockerBase &)>::UntypedPerformDefaultAction' requested here
> class FunctionMocker : public
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
> note: consider using __builtin_trap() or qualifying pointer with 'volatile'
> return *static_cast::type*>(__null);
> ^
> {noformat}
> The source of the issue here is that {{Status}} is an {{enum}}. In
> {{gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h}} you can find
> the following function:
> {code}
> template
> T Invalid() {
> return *static_cast::type*>(NULL);
> }
> {code}
> This function gets called with the return type of a mocked function. In our
> case, the return type of the mocked function is {{Status}}.
> Attempting to compile the following minimal example with {{clang-3.5}}
> reproduces the error message:
> {code}
> #include
> template
> T invalid() {
> return *static_cast::type *>(nullptr);
> }
> enum E { A, B };
> int main() {
> invalid();
> }
> {code}
> * See it online on [GCC Explorer|https://goo.gl/t1FepZ]
> Note that if the type is not an {{enum}},
[jira] [Commented] (MESOS-3101) Standardize separation of Windows/Linux-specific OS code
[ https://issues.apache.org/jira/browse/MESOS-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643256#comment-14643256 ] Marco Massenzio commented on MESOS-3101: You seem to have a review out for this one? care to move this to Reviewable and add a link to the review? > Standardize separation of Windows/Linux-specific OS code > > > Key: MESOS-3101 > URL: https://issues.apache.org/jira/browse/MESOS-3101 > Project: Mesos > Issue Type: Task > Components: stout >Reporter: Joseph Wu >Assignee: Joseph Wu > Labels: mesosphere > > There are 50+ files that must be touched to separate OS-specific code. > First, we will standardize the changes by using stout/abort.hpp as an example. > The review/discussion can be found here: > https://reviews.apache.org/r/36625/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3101) Standardize separation of Windows/Linux-specific OS code
[ https://issues.apache.org/jira/browse/MESOS-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643256#comment-14643256 ] Marco Massenzio edited comment on MESOS-3101 at 7/27/15 7:36 PM: - It's a bit confusing, I must admit. to have a story out with the review already in the description. Is the review a precursor to this story? is there a bigger/better review to be had? And should this be in "Reviewable" already? If the work spans such a large number of files in a non-trivial way, maybe (a) you probably are underestimating the points and (b) perhaps you want to chunk the work in smaller stories/tasks? I dread us ending in the same situation as MESOS-2860, where ONE Jira task spawned 10 reviews... was (Author: marco-mesos): You seem to have a review out for this one? care to move this to Reviewable and add a link to the review? > Standardize separation of Windows/Linux-specific OS code > > > Key: MESOS-3101 > URL: https://issues.apache.org/jira/browse/MESOS-3101 > Project: Mesos > Issue Type: Task > Components: stout >Reporter: Joseph Wu >Assignee: Joseph Wu > Labels: mesosphere > > There are 50+ files that must be touched to separate OS-specific code. > First, we will standardize the changes by using stout/abort.hpp as an example. > The review/discussion can be found here: > https://reviews.apache.org/r/36625/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3141) Compiler warning when mocking function type has an enum return type.
[
https://issues.apache.org/jira/browse/MESOS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643244#comment-14643244
]
Marco Massenzio commented on MESOS-3141:
That's probably because RB assumes sane behavior :)
This points to a larger issue (which I am not sure anyone ever looked into or
is there even a Jira for?) that we should not store binaries/libraries inside
Mesos repo (eg, protobuf; zookeeper; gmock; other stuff I forget now, I'm
sure...)
Before making this change, we should really ensure this doesn't cause build
failures on *all* supported OSes (Ubuntu/CentOS/RHEL) or we'll only find out at
release time, and that will be really A Bad Thing.
I'm all for upgrading gmock, but let's please proceed carefully here.
> Compiler warning when mocking function type has an enum return type.
>
>
> Key: MESOS-3141
> URL: https://issues.apache.org/jira/browse/MESOS-3141
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Michael Park
>Assignee: haosdent
> Labels: mesosphere
>
> The purpose of this ticket is to document a very cryptic error message
> (actually a warning that gets propagated by {{-Werror}}) that gets generated
> by {{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
> innocent-looking function.
> h3. Problem
> The following code is attempting to mock a {{MesosExecutorDriver}}:
> {code}
> class MockMesosExecutorDriver : public MesosExecutorDriver {
> public:
> MockMesosExecutorDriver(mesos::Executor* executor)
> : MesosExecutorDriver(executor) {}
> MOCK_METHOD1(sendStatusUpdate, Status(const TaskStatus&));
> };
> {code}
> The above code generates the following error message:
> {noformat}
> In file included from
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58:
> In file included from
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46:
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
> error: indirection of non-volatile null pointer will be deleted, not trap
> [-Werror,-Wnull-dereference]
> return *static_cast::type*>(__null);
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:78:22:
> note: in instantiation of function template specialization
> 'testing::internal::Invalid' requested here
> return internal::Invalid();
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
> note: in instantiation of member function
> 'testing::internal::BuiltInDefaultValue::Get' requested here
> internal::BuiltInDefaultValue::Get() : *value_;
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
> note: in instantiation of member function
> 'testing::DefaultValue::Get' requested here
> return DefaultValue::Get();
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
> note: in instantiation of member function
> 'testing::internal::FunctionMockerBase &)>::PerformDefaultAction' requested here
> func_mocker->PerformDefaultAction(args, call_description));
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1448:26:
> note: in instantiation of function template specialization
> 'testing::internal::ActionResultHolder::PerformDefaultAction (const mesos::TaskStatus &)>' requested here
> return ResultHolder::PerformDefaultAction(this, args, call_description);
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-generated-function-mockers.h:81:7:
> note: in instantiation of member function
> 'testing::internal::FunctionMockerBase &)>::UntypedPerformDefaultAction' requested here
> class FunctionMocker : public
> ^
> ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
> note: consider using __builtin_trap() or qualifying pointer with 'volatile'
> return *static_cast::type*>(__null);
> ^
> {noformat}
> The source of the issue here is that {{Status}} is an {{enum}}. In
> {{gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h}} you can find
> the following function:
> {code}
> template
> T Invalid() {
> return *static_cast::type*>(NULL);
> }
> {code}
> This function gets called with the return type of a mocked function. In our
> case, the return type of the mocked function is {{Status}}.
> Attempting to compile the following minimal example with {{clang-3.5}}
> reproduces the error message:
> {code}
>
[jira] [Commented] (MESOS-2757) Can't Use -> operator with Option, Try, Result, Future
[ https://issues.apache.org/jira/browse/MESOS-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643226#comment-14643226 ] Benjamin Mahler commented on MESOS-2757: Adding the operators sounds good to me. > Can't Use -> operator with Option, Try, Result, Future > -- > > Key: MESOS-2757 > URL: https://issues.apache.org/jira/browse/MESOS-2757 > Project: Mesos > Issue Type: Improvement > Components: stout >Reporter: Joris Van Remoortere >Assignee: Joris Van Remoortere > Labels: c++11, mesosphere, option, stout > > Let's add operator overloads to Option to allow access to the underlying T > using the `->` operator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough reassigned MESOS-3155: --- Assignee: Cody Roseborough > Add a containerizer and executor that simulate the launching of tasks. > --- > > Key: MESOS-3155 > URL: https://issues.apache.org/jira/browse/MESOS-3155 > Project: Mesos > Issue Type: Improvement > Components: containerization, slave >Reporter: Cody Roseborough >Assignee: Cody Roseborough >Priority: Minor > > This could have a user-defined configuration file. This would allow users to > locally test frameworks against a large, simulated cluster using mesos-local. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough updated MESOS-3155: Description: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. > Add a containerizer and executor that simulate the launching of tasks. > --- > > Key: MESOS-3155 > URL: https://issues.apache.org/jira/browse/MESOS-3155 > Project: Mesos > Issue Type: Improvement > Components: containerization, slave >Reporter: Cody Roseborough >Priority: Minor > > This could have a user-defined configuration file. This would allow users to > locally test frameworks against a large, simulated cluster using mesos-local. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough updated MESOS-3155: Summary: Add a containerizer and executor that simulate the launching of tasks. (was: Add a containerizer and executor that simulate the launching of tasks using a user-defined configuration file. Allows users to locally test frameworks against a large, simulated cluster using mesos-local) > Add a containerizer and executor that simulate the launching of tasks. > --- > > Key: MESOS-3155 > URL: https://issues.apache.org/jira/browse/MESOS-3155 > Project: Mesos > Issue Type: Improvement > Components: containerization, slave >Reporter: Cody Roseborough >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3046) Stout's UUID re-seeds a new random generator during each call to UUID::random.
[
https://issues.apache.org/jira/browse/MESOS-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-3046:
---
Labels: newbie twitter (was: twitter)
> Stout's UUID re-seeds a new random generator during each call to UUID::random.
> --
>
> Key: MESOS-3046
> URL: https://issues.apache.org/jira/browse/MESOS-3046
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Benjamin Mahler
> Labels: newbie, twitter
>
> Per [~StephanErb] and [~kevints]'s observations on MESOS-2940, stout's UUID
> abstraction is re-seeding the random generator during each call to
> {{UUID::random()}}, which is really expensive.
> This is confirmed in the perf graph from MESOS-2940.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks using a user-defined configuration file. Allows users to locally test frameworks against a large, si
Cody Roseborough created MESOS-3155: --- Summary: Add a containerizer and executor that simulate the launching of tasks using a user-defined configuration file. Allows users to locally test frameworks against a large, simulated cluster using mesos-local Key: MESOS-3155 URL: https://issues.apache.org/jira/browse/MESOS-3155 Project: Mesos Issue Type: Improvement Components: containerization, slave Reporter: Cody Roseborough Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3057) Mesos web ui sorting by Id results in non-intuitive order.
[ https://issues.apache.org/jira/browse/MESOS-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643185#comment-14643185 ] Cody Roseborough commented on MESOS-3057: - The one pictured is: [Mesosaurus| https://github.com/mesosphere/mesosaurus]. Came across it while testing other things and it seemed counter to what you would expect. It seems like it would effect orderings on any framework that used numbers as part of it's task_id's? > Mesos web ui sorting by Id results in non-intuitive order. > -- > > Key: MESOS-3057 > URL: https://issues.apache.org/jira/browse/MESOS-3057 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.23.0 >Reporter: Cody Roseborough >Priority: Trivial > Labels: newbie > Attachments: web ui sorted by ids.png > > > In the mesos webui sorting task by ID results in non-intuitive order. For > example with Id's task_0-task_200 sorted asc you get task_0, task_1, task_10, > task_100... task_109, task_11, task_110 etc. It happens if you use just > numbers as Id's also. > It seems like it should be sorted using natural sort order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1815) Create a guide to becoming a committer
[ https://issues.apache.org/jira/browse/MESOS-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643168#comment-14643168 ] Marco Massenzio commented on MESOS-1815: Hey [~bernd-mesos] - any progress on this one? What's missing/blocking? Last comment was 20days ago; any progress/blockers? > 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] [Created] (MESOS-3154) Enable Mesos Agent Node to use arbitrary script / module to figure out IP, HOSTNAME
Marco Massenzio created MESOS-3154:
--
Summary: Enable Mesos Agent Node to use arbitrary script / module
to figure out IP, HOSTNAME
Key: MESOS-3154
URL: https://issues.apache.org/jira/browse/MESOS-3154
Project: Mesos
Issue Type: Story
Components: slave
Reporter: Benjamin Hindman
Assignee: Marco Massenzio
Following from MESOS-2902 we want to enable the same functionality in the Mesos
Agents too.
This is probably best done once we implement the new {{os::shell}} semantics,
as described in MESOS-3142.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643140#comment-14643140
]
Marco Massenzio commented on MESOS-3144:
Uploaded a new PR: https://github.com/Homebrew/homebrew/pull/42177
> Update Homebrew formula for Mesos (Mac OSX)
> ---
>
> Key: MESOS-3144
> URL: https://issues.apache.org/jira/browse/MESOS-3144
> Project: Mesos
> Issue Type: Task
>Reporter: Marco Massenzio
>Priority: Trivial
> Labels: newbie
>
> We have pushed a [pull
> request|https://github.com/Homebrew/homebrew/pull/42099] to Homebrew for the
> new 0.23 formula.
> Once accepted, we must verify that this works on a Mac OSX device.
> This would also be a great time to ensure our documentation is up-to-date.
> Currently, the Homebrew check fails, as they have deprecated SHA-1 checksums:
> {noformat}
> Error Message
> failed: brew audit mesos
> Stacktrace
> Error: 7 problems in 1 formula
> mesos:
> * Stable resource "protobuf": SHA1 checksums are deprecated, please use
> SHA256
> * Stable resource "python-gflags": SHA1 checksums are deprecated, please use
> SHA256
> * Stable resource "six": SHA1 checksums are deprecated, please use SHA256
> * Stable resource "google-apputils": SHA1 checksums are deprecated, please
> use SHA256
> * Stable resource "python-dateutil": SHA1 checksums are deprecated, please
> use SHA256
> * Stable resource "boto": SHA1 checksums are deprecated, please use SHA256
> * Stable resource "pytz": SHA1 checksums are deprecated, please use SHA256
> {noformat}
> Don't know enough about Homebrew to really figure out what is going on here;
> nor how to fix this.
> The Mesos SHA-256 has been correctly entered and computed via the [Online
> SHA/MD5 calculator|https://md5file.com/calculator].
> I guess, we should go download the packages and compute their SHA-256 and/or
> research from the respective download sites whether they publish the SHA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-830) ExamplesTest.JavaFramework is flaky
[ https://issues.apache.org/jira/browse/MESOS-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-830: -- Sprint: Mesosphere Sprint 16 > ExamplesTest.JavaFramework is flaky > --- > > Key: MESOS-830 > URL: https://issues.apache.org/jira/browse/MESOS-830 > Project: Mesos > Issue Type: Bug > Components: test >Reporter: Vinod Kone >Assignee: Greg Mann > Labels: flaky, mesosphere > > [ RUN ] ExamplesTest.JavaFramework > Using temporary directory '/tmp/ExamplesTest_JavaFramework_wSc7u8' > Enabling authentication for the framework > I1120 15:13:39.820032 1681264640 master.cpp:285] Master started on > 172.25.133.171:52576 > I1120 15:13:39.820180 1681264640 master.cpp:299] Master ID: > 201311201513-2877626796-52576-3234 > I1120 15:13:39.820194 1681264640 master.cpp:302] Master only allowing > authenticated frameworks to register! > I1120 15:13:39.821197 1679654912 slave.cpp:112] Slave started on > 1)@172.25.133.171:52576 > I1120 15:13:39.821795 1679654912 slave.cpp:212] Slave resources: cpus(*):4; > mem(*):7168; disk(*):481998; ports(*):[31000-32000] > I1120 15:13:39.822855 1682337792 slave.cpp:112] Slave started on > 2)@172.25.133.171:52576 > I1120 15:13:39.823652 1682337792 slave.cpp:212] Slave resources: cpus(*):4; > mem(*):7168; disk(*):481998; ports(*):[31000-32000] > I1120 15:13:39.825330 1679118336 master.cpp:744] The newly elected leader is > master@172.25.133.171:52576 > I1120 15:13:39.825445 1679118336 master.cpp:748] Elected as the leading > master! > I1120 15:13:39.825907 1681264640 state.cpp:33] Recovering state from > '/tmp/ExamplesTest_JavaFramework_wSc7u8/0/meta' > I1120 15:13:39.826127 1681264640 status_update_manager.cpp:180] Recovering > status update manager > I1120 15:13:39.826331 1681801216 process_isolator.cpp:317] Recovering isolator > I1120 15:13:39.826738 1682874368 slave.cpp:2743] Finished recovery > I1120 15:13:39.827747 1682337792 state.cpp:33] Recovering state from > '/tmp/ExamplesTest_JavaFramework_wSc7u8/1/meta' > I1120 15:13:39.827945 1680191488 slave.cpp:112] Slave started on > 3)@172.25.133.171:52576 > I1120 15:13:39.828415 1682337792 status_update_manager.cpp:180] Recovering > status update manager > I1120 15:13:39.828608 1680728064 sched.cpp:260] Authenticating with master > master@172.25.133.171:52576 > I1120 15:13:39.828606 1680191488 slave.cpp:212] Slave resources: cpus(*):4; > mem(*):7168; disk(*):481998; ports(*):[31000-32000] > I1120 15:13:39.828680 1682874368 slave.cpp:497] New master detected at > master@172.25.133.171:52576 > I1120 15:13:39.828765 1682337792 process_isolator.cpp:317] Recovering isolator > I1120 15:13:39.829828 1680728064 sched.cpp:229] Detecting new master > I1120 15:13:39.830288 1679654912 authenticatee.hpp:100] Initializing client > SASL > I1120 15:13:39.831635 1680191488 state.cpp:33] Recovering state from > '/tmp/ExamplesTest_JavaFramework_wSc7u8/2/meta' > I1120 15:13:39.831991 1679118336 status_update_manager.cpp:158] New master > detected at master@172.25.133.171:52576 > I1120 15:13:39.832042 1682874368 slave.cpp:524] Detecting new master > I1120 15:13:39.832314 1682337792 slave.cpp:2743] Finished recovery > I1120 15:13:39.832309 1681264640 master.cpp:1266] Attempting to register > slave on vkone.local at slave(1)@172.25.133.171:52576 > I1120 15:13:39.832929 1680728064 status_update_manager.cpp:180] Recovering > status update manager > I1120 15:13:39.833371 1681801216 slave.cpp:497] New master detected at > master@172.25.133.171:52576 > I1120 15:13:39.833273 1681264640 master.cpp:2513] Adding slave > 201311201513-2877626796-52576-3234-0 at vkone.local with cpus(*):4; > mem(*):7168; disk(*):481998; ports(*):[31000-32000] > I1120 15:13:39.833595 1680728064 process_isolator.cpp:317] Recovering isolator > I1120 15:13:39.833859 1681801216 slave.cpp:524] Detecting new master > I1120 15:13:39.833861 1682874368 status_update_manager.cpp:158] New master > detected at master@172.25.133.171:52576 > I1120 15:13:39.834092 1680191488 slave.cpp:542] Registered with master > master@172.25.133.171:52576; given slave ID > 201311201513-2877626796-52576-3234-0 > I1120 15:13:39.834486 1681264640 master.cpp:1266] Attempting to register > slave on vkone.local at slave(2)@172.25.133.171:52576 > I1120 15:13:39.834549 1681264640 master.cpp:2513] Adding slave > 201311201513-2877626796-52576-3234-1 at vkone.local with cpus(*):4; > mem(*):7168; disk(*):481998; ports(*):[31000-32000] > I1120 15:13:39.834750 1680191488 slave.cpp:555] Checkpointing SlaveInfo to > '/tmp/ExamplesTest_JavaFramework_wSc7u8/0/meta/slaves/201311201513-2877626796-52576-3234-0/slave.info' > I1120 15:13:39.834875 1682874368 hierarchical_allocator_process.hpp:445] > Added slave 201311201513-2877626796-52576-3234-0 (vkone.local) with > cpus(*):4
[jira] [Updated] (MESOS-1010) Python extension build is broken if gflags-dev is installed
[
https://issues.apache.org/jira/browse/MESOS-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-1010:
---
Sprint: Mesosphere Sprint 16
> Python extension build is broken if gflags-dev is installed
> ---
>
> Key: MESOS-1010
> URL: https://issues.apache.org/jira/browse/MESOS-1010
> Project: Mesos
> Issue Type: Bug
> Components: build, python api
> Environment: Fedora 20, amd64. GCC: 4.8.2.
>Reporter: Nikita Vetoshkin
>Assignee: Greg Mann
> Labels: flaky-test, mesosphere
>
> In my environment mesos build from master results in broken python api module
> {{_mesos.so}}:
> {noformat}
> nekto0n@ya-darkstar ~/workspace/mesos/src/python $
> PYTHONPATH=build/lib.linux-x86_64-2.7/ python -c "import _mesos"
> Traceback (most recent call last):
> File "", line 1, in
> ImportError:
> /home/nekto0n/workspace/mesos/src/python/build/lib.linux-x86_64-2.7/_mesos.so:
> undefined symbol: _ZN6google14FlagRegistererC1EPKcS2_S2_S2_PvS3_
> {noformat}
> Unmangled version of symbol looks like this:
> {noformat}
> google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*,
> char const*, void*, void*)
> {noformat}
> During {{./configure}} step {{glog}} finds {{gflags}} development files and
> starts using them, thus *implicitly* adding dependency on {{libgflags.so}}.
> This breaks Python extensions module and perhaps can break other mesos
> subsystems when moved to hosts without {{gflags}} installed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-3144:
---
Sprint: Mesosphere Sprint 15
Labels: mesosphere newbie (was: newbie)
> Update Homebrew formula for Mesos (Mac OSX)
> ---
>
> Key: MESOS-3144
> URL: https://issues.apache.org/jira/browse/MESOS-3144
> Project: Mesos
> Issue Type: Task
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Trivial
> Labels: mesosphere, newbie
>
> We have pushed a [pull
> request|https://github.com/Homebrew/homebrew/pull/42099] to Homebrew for the
> new 0.23 formula.
> Once accepted, we must verify that this works on a Mac OSX device.
> This would also be a great time to ensure our documentation is up-to-date.
> Currently, the Homebrew check fails, as they have deprecated SHA-1 checksums:
> {noformat}
> Error Message
> failed: brew audit mesos
> Stacktrace
> Error: 7 problems in 1 formula
> mesos:
> * Stable resource "protobuf": SHA1 checksums are deprecated, please use
> SHA256
> * Stable resource "python-gflags": SHA1 checksums are deprecated, please use
> SHA256
> * Stable resource "six": SHA1 checksums are deprecated, please use SHA256
> * Stable resource "google-apputils": SHA1 checksums are deprecated, please
> use SHA256
> * Stable resource "python-dateutil": SHA1 checksums are deprecated, please
> use SHA256
> * Stable resource "boto": SHA1 checksums are deprecated, please use SHA256
> * Stable resource "pytz": SHA1 checksums are deprecated, please use SHA256
> {noformat}
> Don't know enough about Homebrew to really figure out what is going on here;
> nor how to fix this.
> The Mesos SHA-256 has been correctly entered and computed via the [Online
> SHA/MD5 calculator|https://md5file.com/calculator].
> I guess, we should go download the packages and compute their SHA-256 and/or
> research from the respective download sites whether they publish the SHA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio reassigned MESOS-3144:
--
Assignee: Marco Massenzio
> Update Homebrew formula for Mesos (Mac OSX)
> ---
>
> Key: MESOS-3144
> URL: https://issues.apache.org/jira/browse/MESOS-3144
> Project: Mesos
> Issue Type: Task
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Trivial
> Labels: newbie
>
> We have pushed a [pull
> request|https://github.com/Homebrew/homebrew/pull/42099] to Homebrew for the
> new 0.23 formula.
> Once accepted, we must verify that this works on a Mac OSX device.
> This would also be a great time to ensure our documentation is up-to-date.
> Currently, the Homebrew check fails, as they have deprecated SHA-1 checksums:
> {noformat}
> Error Message
> failed: brew audit mesos
> Stacktrace
> Error: 7 problems in 1 formula
> mesos:
> * Stable resource "protobuf": SHA1 checksums are deprecated, please use
> SHA256
> * Stable resource "python-gflags": SHA1 checksums are deprecated, please use
> SHA256
> * Stable resource "six": SHA1 checksums are deprecated, please use SHA256
> * Stable resource "google-apputils": SHA1 checksums are deprecated, please
> use SHA256
> * Stable resource "python-dateutil": SHA1 checksums are deprecated, please
> use SHA256
> * Stable resource "boto": SHA1 checksums are deprecated, please use SHA256
> * Stable resource "pytz": SHA1 checksums are deprecated, please use SHA256
> {noformat}
> Don't know enough about Homebrew to really figure out what is going on here;
> nor how to fix this.
> The Mesos SHA-256 has been correctly entered and computed via the [Online
> SHA/MD5 calculator|https://md5file.com/calculator].
> I guess, we should go download the packages and compute their SHA-256 and/or
> research from the respective download sites whether they publish the SHA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-3144:
---
Comment: was deleted
(was: Uploaded a new PR: https://github.com/Homebrew/homebrew/pull/42177)
> Update Homebrew formula for Mesos (Mac OSX)
> ---
>
> Key: MESOS-3144
> URL: https://issues.apache.org/jira/browse/MESOS-3144
> Project: Mesos
> Issue Type: Task
>Reporter: Marco Massenzio
>Priority: Trivial
> Labels: newbie
>
> We have pushed a [pull
> request|https://github.com/Homebrew/homebrew/pull/42099] to Homebrew for the
> new 0.23 formula.
> Once accepted, we must verify that this works on a Mac OSX device.
> This would also be a great time to ensure our documentation is up-to-date.
> Currently, the Homebrew check fails, as they have deprecated SHA-1 checksums:
> {noformat}
> Error Message
> failed: brew audit mesos
> Stacktrace
> Error: 7 problems in 1 formula
> mesos:
> * Stable resource "protobuf": SHA1 checksums are deprecated, please use
> SHA256
> * Stable resource "python-gflags": SHA1 checksums are deprecated, please use
> SHA256
> * Stable resource "six": SHA1 checksums are deprecated, please use SHA256
> * Stable resource "google-apputils": SHA1 checksums are deprecated, please
> use SHA256
> * Stable resource "python-dateutil": SHA1 checksums are deprecated, please
> use SHA256
> * Stable resource "boto": SHA1 checksums are deprecated, please use SHA256
> * Stable resource "pytz": SHA1 checksums are deprecated, please use SHA256
> {noformat}
> Don't know enough about Homebrew to really figure out what is going on here;
> nor how to fix this.
> The Mesos SHA-256 has been correctly entered and computed via the [Online
> SHA/MD5 calculator|https://md5file.com/calculator].
> I guess, we should go download the packages and compute their SHA-256 and/or
> research from the respective download sites whether they publish the SHA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643124#comment-14643124
]
Marco Massenzio commented on MESOS-3144:
Hi, thanks for looking into it.
You can probably make a pull request, but I think it's easier if I just copy
your stuff (the SHA-256 were the blocking issue) into my PR (it's already there
and the Homebrew folks are ready to merge it).
Thanks!
> Update Homebrew formula for Mesos (Mac OSX)
> ---
>
> Key: MESOS-3144
> URL: https://issues.apache.org/jira/browse/MESOS-3144
> Project: Mesos
> Issue Type: Task
>Reporter: Marco Massenzio
>Priority: Trivial
> Labels: newbie
>
> We have pushed a [pull
> request|https://github.com/Homebrew/homebrew/pull/42099] to Homebrew for the
> new 0.23 formula.
> Once accepted, we must verify that this works on a Mac OSX device.
> This would also be a great time to ensure our documentation is up-to-date.
> Currently, the Homebrew check fails, as they have deprecated SHA-1 checksums:
> {noformat}
> Error Message
> failed: brew audit mesos
> Stacktrace
> Error: 7 problems in 1 formula
> mesos:
> * Stable resource "protobuf": SHA1 checksums are deprecated, please use
> SHA256
> * Stable resource "python-gflags": SHA1 checksums are deprecated, please use
> SHA256
> * Stable resource "six": SHA1 checksums are deprecated, please use SHA256
> * Stable resource "google-apputils": SHA1 checksums are deprecated, please
> use SHA256
> * Stable resource "python-dateutil": SHA1 checksums are deprecated, please
> use SHA256
> * Stable resource "boto": SHA1 checksums are deprecated, please use SHA256
> * Stable resource "pytz": SHA1 checksums are deprecated, please use SHA256
> {noformat}
> Don't know enough about Homebrew to really figure out what is going on here;
> nor how to fix this.
> The Mesos SHA-256 has been correctly entered and computed via the [Online
> SHA/MD5 calculator|https://md5file.com/calculator].
> I guess, we should go download the packages and compute their SHA-256 and/or
> research from the respective download sites whether they publish the SHA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3126) Building mesos.jar, uses old javadoc plugin in maven.
[ https://issues.apache.org/jira/browse/MESOS-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643054#comment-14643054 ] Vinod Kone commented on MESOS-3126: --- [~hbogert] ASF CI builds and testsMesos using the following Dockerfile for ubuntu:14 and centos:7 https://github.com/apache/mesos/blob/master/support/jenkins_build.sh > Building mesos.jar, uses old javadoc plugin in maven. > - > > Key: MESOS-3126 > URL: https://issues.apache.org/jira/browse/MESOS-3126 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.23.0 > Environment: Centos 6.5. > Manually installed maven, version 3.3.3 > Manually installing mesos. >Reporter: Hans van den Bogert >Priority: Minor > > When building Mesos, including the mesos.jar. It errors when generating the > javadoc: > http://pastebin.com/TNRERS4p > It seems the javadoc plugin is also trying to parse .class files, though the > source directories are correct in the pom file. > Further investigation leads to think that the javadoc plugin version is to > blame. Setting a fixed version of 2.10.3 for the javadoc plugin, in the pom > file, successfully generates the javadoc. > In this environment, the default javadoc plugin being downloaded, is 2.8.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3153) Add tests for HTTPS SSL socket communication
[ https://issues.apache.org/jira/browse/MESOS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jojy Varghese updated MESOS-3153: - Description: Unit tests are lacking for the following cases: 1. HTTPS Post with "None" payload. 2. Verification of HTTPS payload on the SSL socket(maybe decode to a Request object) 3. http -> ssl socket 4. https -> raw socket. was: Unit tests are lacking for the following cases: 1. HTTPS Post with "None" payload. 2. http -> ssl socket 3. https -> raw socket. > Add tests for HTTPS SSL socket communication > > > Key: MESOS-3153 > URL: https://issues.apache.org/jira/browse/MESOS-3153 > Project: Mesos > Issue Type: Bug >Reporter: Jojy Varghese >Assignee: Jojy Varghese >Priority: Minor > Labels: mesosphere > > Unit tests are lacking for the following cases: > 1. HTTPS Post with "None" payload. > 2. Verification of HTTPS payload on the SSL socket(maybe decode to a Request > object) > 3. http -> ssl socket > 4. https -> raw socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3153) Add tests for HTTPS SSL socket communication
[ https://issues.apache.org/jira/browse/MESOS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jojy Varghese updated MESOS-3153: - Summary: Add tests for HTTPS SSL socket communication (was: Add tests for HTTPS SSL socket connection) > Add tests for HTTPS SSL socket communication > > > Key: MESOS-3153 > URL: https://issues.apache.org/jira/browse/MESOS-3153 > Project: Mesos > Issue Type: Bug >Reporter: Jojy Varghese >Assignee: Jojy Varghese >Priority: Minor > Labels: mesosphere > > Unit tests are lacking for the following cases: > 1. HTTPS Post with "None" payload. > 2. http -> ssl socket > 3. https -> raw socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3153) Add tests for HTTPS SSL socket connection
Jojy Varghese created MESOS-3153: Summary: Add tests for HTTPS SSL socket connection Key: MESOS-3153 URL: https://issues.apache.org/jira/browse/MESOS-3153 Project: Mesos Issue Type: Bug Reporter: Jojy Varghese Assignee: Jojy Varghese Priority: Minor Unit tests are lacking for the following cases: 1. HTTPS Post with "None" payload. 2. http -> ssl socket 3. https -> raw socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3126) Building mesos.jar, uses old javadoc plugin in maven.
[ https://issues.apache.org/jira/browse/MESOS-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642756#comment-14642756 ] haosdent commented on MESOS-3126: - You could try this docker image. https://registry.hub.docker.com/u/mesosphere/mesos/ > Building mesos.jar, uses old javadoc plugin in maven. > - > > Key: MESOS-3126 > URL: https://issues.apache.org/jira/browse/MESOS-3126 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.23.0 > Environment: Centos 6.5. > Manually installed maven, version 3.3.3 > Manually installing mesos. >Reporter: Hans van den Bogert >Priority: Minor > > When building Mesos, including the mesos.jar. It errors when generating the > javadoc: > http://pastebin.com/TNRERS4p > It seems the javadoc plugin is also trying to parse .class files, though the > source directories are correct in the pom file. > Further investigation leads to think that the javadoc plugin version is to > blame. Setting a fixed version of 2.10.3 for the javadoc plugin, in the pom > file, successfully generates the javadoc. > In this environment, the default javadoc plugin being downloaded, is 2.8.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3126) Building mesos.jar, uses old javadoc plugin in maven.
[ https://issues.apache.org/jira/browse/MESOS-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642745#comment-14642745 ] Hans van den Bogert commented on MESOS-3126: Well.. serves me right for not following the instructions to the letter. I was using the sun/oracle-jdk. Changing to sun-jdk-6, or openjdk-7 resolves this. Pretty weird though. I've made a proof of failure in Docker. Is a Dockerfile for Centos perhaps a good thing to have anyway in the git repo? > Building mesos.jar, uses old javadoc plugin in maven. > - > > Key: MESOS-3126 > URL: https://issues.apache.org/jira/browse/MESOS-3126 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.23.0 > Environment: Centos 6.5. > Manually installed maven, version 3.3.3 > Manually installing mesos. >Reporter: Hans van den Bogert >Priority: Minor > > When building Mesos, including the mesos.jar. It errors when generating the > javadoc: > http://pastebin.com/TNRERS4p > It seems the javadoc plugin is also trying to parse .class files, though the > source directories are correct in the pom file. > Further investigation leads to think that the javadoc plugin version is to > blame. Setting a fixed version of 2.10.3 for the javadoc plugin, in the pom > file, successfully generates the javadoc. > In this environment, the default javadoc plugin being downloaded, is 2.8.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3152) Need for HTTP delete requests
Joerg Schad created MESOS-3152: -- Summary: Need for HTTP delete requests Key: MESOS-3152 URL: https://issues.apache.org/jira/browse/MESOS-3152 Project: Mesos Issue Type: Improvement Reporter: Joerg Schad As we decided to create a more restful api for managing Quota request, we also want to use the HTTP Delete method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2697) Add a /teardown endpoint on master to teardown a framework
[ https://issues.apache.org/jira/browse/MESOS-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642691#comment-14642691 ] Till Toenshoff commented on MESOS-2697: --- commit 90f3fec71535bdf9c0cd5fc90c62e19a86b92470 Author: Joerg Schad Date: Mon Jul 27 14:17:12 2015 +0200 Updated Authorization documentation to use /teardown endpoint. With Mesos 0.23 the /shutdown endpoint has been deprecated in favor of the /teardown endpoint. See MESOS-2697 for details. Review: https://reviews.apache.org/r/36774 > Add a /teardown endpoint on master to teardown a framework > -- > > Key: MESOS-2697 > URL: https://issues.apache.org/jira/browse/MESOS-2697 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone >Assignee: Vinod Kone > Fix For: 0.23.0 > > > We plan to rename "/shutdown" endpoint to "/teardown" to be compatible with > the new API. "/shutdown" will be deprecated in 0.24.0 or later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3057) Mesos web ui sorting by Id results in non-intuitive order.
[ https://issues.apache.org/jira/browse/MESOS-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642556#comment-14642556 ] haosdent commented on MESOS-3057: - [~Croseborough] Could you give your framework name to me? Is it open source? > Mesos web ui sorting by Id results in non-intuitive order. > -- > > Key: MESOS-3057 > URL: https://issues.apache.org/jira/browse/MESOS-3057 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.23.0 >Reporter: Cody Roseborough >Priority: Trivial > Labels: newbie > Attachments: web ui sorted by ids.png > > > In the mesos webui sorting task by ID results in non-intuitive order. For > example with Id's task_0-task_200 sorted asc you get task_0, task_1, task_10, > task_100... task_109, task_11, task_110 etc. It happens if you use just > numbers as Id's also. > It seems like it should be sorted using natural sort order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3057) Mesos web ui sorting by Id results in non-intuitive order.
[ https://issues.apache.org/jira/browse/MESOS-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642550#comment-14642550 ] haosdent commented on MESOS-3057: - I think this ticket is not a problem. The task id maybe defined by your use framework, it could be "test_a", "test_b", "test_c" in other frameworks. The better way to fix it is let your use framwork use a fixed bit suffix. For example, like "test_1", "test_2". > Mesos web ui sorting by Id results in non-intuitive order. > -- > > Key: MESOS-3057 > URL: https://issues.apache.org/jira/browse/MESOS-3057 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.23.0 >Reporter: Cody Roseborough >Priority: Trivial > Labels: newbie > Attachments: web ui sorted by ids.png > > > In the mesos webui sorting task by ID results in non-intuitive order. For > example with Id's task_0-task_200 sorted asc you get task_0, task_1, task_10, > task_100... task_109, task_11, task_110 etc. It happens if you use just > numbers as Id's also. > It seems like it should be sorted using natural sort order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3081) Default configuration of google logging
[ https://issues.apache.org/jira/browse/MESOS-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642528#comment-14642528 ] haosdent commented on MESOS-3081: - This ticket seems duplicated with https://issues.apache.org/jira/browse/MESOS-2153 and https://issues.apache.org/jira/browse/MESOS-2153 > Default configuration of google logging > --- > > Key: MESOS-3081 > URL: https://issues.apache.org/jira/browse/MESOS-3081 > Project: Mesos > Issue Type: Wish >Affects Versions: 0.22.1 >Reporter: Rinaldo DiGiorgio >Priority: Minor > > The Google Logging api as configured requires that users look at many files > on many systems. When first using mesos log files are important. The idea > that having the log output categorized for you is a good idea for production > systems but there are many ways and better tools for doing that like logstash > and elasticsearch. It would be better if the default configuration was for > one logfile with standard conventions rather than many log files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-2960) Configure DiscoveryInfo and Visibility per port
[ https://issues.apache.org/jira/browse/MESOS-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent reassigned MESOS-2960: --- Assignee: haosdent > Configure DiscoveryInfo and Visibility per port > --- > > Key: MESOS-2960 > URL: https://issues.apache.org/jira/browse/MESOS-2960 > Project: Mesos > Issue Type: Improvement > Components: general >Affects Versions: 0.22.1 >Reporter: Frank Scholten >Assignee: haosdent > Labels: mesosphere > > For Mesos Elasticsearch I like to use DiscoveryInfo to advertise the client > port (9200) with Visibility=EXTERNAL so it can be discovered by load > balancers while advertising the transport port (9300) as Visibility=FRAMEWORK > because it is used by nodes to talk too each other and should not be load > balanced. > However, I can only set one DiscoveryInfo and one visibility, instead of one > per port. I suggest to allow multiple DiscoveryInfo's to be configured with > their own visibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3104) Add an endpoint that exposes component flags.
[ https://issues.apache.org/jira/browse/MESOS-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent reassigned MESOS-3104: --- Assignee: haosdent > Add an endpoint that exposes component flags. > - > > Key: MESOS-3104 > URL: https://issues.apache.org/jira/browse/MESOS-3104 > Project: Mesos > Issue Type: Task >Reporter: David Robinson >Assignee: haosdent >Priority: Minor > Labels: twitter > > Apparently there's an ongoing effort to break /state.json apart into separate > endpoints. As part of this effort it would be great if an endpoint was > created that only exposed the flags. Configuration management tools could use > the endpoint to determine whether the master/slave is correctly configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3151) Reservation Test failed
Jihun Kang created MESOS-3151:
-
Summary: Reservation Test failed
Key: MESOS-3151
URL: https://issues.apache.org/jira/browse/MESOS-3151
Project: Mesos
Issue Type: Bug
Environment: Ubuntu 14.04.2
IBM JDK 1.7.0 SR8
Reporter: Jihun Kang
Here is the details.
{noformat}
[ RUN ]
ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes
../../src/tests/reservation_tests.cpp:1055: Failure
Value of: Resources(offer.resources()).contains(unreserved + unreservedDisk)
Actual: false
Expected: true
2015-07-27
17:31:16,280:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-07-27
17:31:19,617:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-07-27
17:31:22,951:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-07-27
17:31:26,288:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
../../src/tests/reservation_tests.cpp:1076: Failure
Failed to wait 15secs for message1
*** Aborted at 1437985889 (unix time) try "date -d @1437985889" if you are
using GNU date ***
PC: @0x0 (unknown)
../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
Actual function call count doesn't match EXPECT_CALL(filter->mock,
filter(testing::A()))...
Expected args: message matcher (8-byte object ,
1-byte object <61>, 1-byte object )
Expected: to be called once
Actual: never called - unsatisfied and active
../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
Actual function call count doesn't match EXPECT_CALL(filter->mock,
filter(testing::A()))...
Expected args: message matcher (8-byte object ,
1-byte object <61>, 1-byte object )
Expected: to be called once
Actual: never called - unsatisfied and active
[ FAILED ]
ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes (15354 ms)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642408#comment-14642408 ] Jihun Kang commented on MESOS-2216: --- [~trex58], I fixed up these testing codes in MESOS-3150. IBM JDK returns the floating numbers with different value of exponent part, but google testing function, EXPECT_EQ, does not consider it. I finished up unit tests on x86_64 machines with IBM JDK, but I could not run test on i386 one because I don't have any available 32bit x86 machine. > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix >Assignee: Jihun Kang > Attachments: MESOS-2216_1.patch, MESOS-2216_2.patch, config.log, > jniport.h, x86_64_traces > > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3126) Building mesos.jar, uses old javadoc plugin in maven.
[ https://issues.apache.org/jira/browse/MESOS-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642377#comment-14642377 ] haosdent commented on MESOS-3126: - [~hbogert] I could build it successfully. Is it because our environment different? I use CenOS 6.5/maven 3.0.5/JDK 1.7.0_75 > Building mesos.jar, uses old javadoc plugin in maven. > - > > Key: MESOS-3126 > URL: https://issues.apache.org/jira/browse/MESOS-3126 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.23.0 > Environment: Centos 6.5. > Manually installed maven, version 3.3.3 > Manually installing mesos. >Reporter: Hans van den Bogert >Priority: Minor > > When building Mesos, including the mesos.jar. It errors when generating the > javadoc: > http://pastebin.com/TNRERS4p > It seems the javadoc plugin is also trying to parse .class files, though the > source directories are correct in the pom file. > Further investigation leads to think that the javadoc plugin version is to > blame. Setting a fixed version of 2.10.3 for the javadoc plugin, in the pom > file, successfully generates the javadoc. > In this environment, the default javadoc plugin being downloaded, is 2.8.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
